従来のADCデプロイメントプロジェクトで最大のコストは通常、製品自体ではなく — 製品に合わせるための既存ネットワークの再構築です。バックエンドのデフォルトゲートウェイの変更、IPプランの再設計、ルート動作の見直し、またはメンテナンスウィンドウを開くことはすべて本番環境で重大なリスクをもたらします。
何百、何千ものバックエンドを持つ環境では、「すべてのサーバーのゲートウェイを変更する」アプローチは実行可能ではありません。一部のバックエンドにはゲートウェイがまったく定義されていないかもしれず、他はスタティックルートに依存し、さらに他は変更が難しいまたは不可能なレガシーシステム上で動作しているかもしれません。このような場合、ADCを挿入することは完全なネットワーク再設計プロジェクトになります。
強制的なネットワークセグメント統合も別の問題です。VIPはDMZに置く必要があり、バックエンドは内部ネットワークに留まる必要があり、テナントネットワークは分離されたまま、管理プレーンは分離されて維持される必要があります。ADCがこれらのドメイン間で制御された方法でトラフィックを運べない場合、セキュリティセグメンテーションが崩れるか、アプリケーションチームが不必要なIP移行作業を強いられます。
単一のリバースプロキシモデルもすべてのニーズをカバーできません。一部のアプリケーションはバックエンドが実際のクライアントIPを見ることを要求し、一部のL4サービスはリターントラフィックがADCを完全にバイパスする必要があり、一部のインラインシナリオではIPを変更したりゲートウェイに触れたりせずにADCを挿入する必要があります。単一のNATベースのモデルはこの要件の範囲に対応できません。
TR7デプロイメントトポロジーモードはこの柔軟性を提供します：バックエンドのIPアドレス、ゲートウェイ、Route Table割り当てに触れずに、各サービスに適したトラフィック配置を選択できます。
TR7はデプロイメントトポロジーをサービスタイプ、ネットワーク配置、移行リスクに合わせて調整できるアーキテクチャ上の決定に変えます。
クラシックなリバースプロキシモデルでは、クライアントがTR7に接続し、TR7がバックエンドに接続します。透過型バインドシナリオでは、バックエンドがソースアドレスとして実際のクライアントIPを見えるようにトラフィックフローが保持されます。
NATモードでは宛先と送信元の両方の変換が一緒に管理されます。SNATモードでは送信元側のみが調整されます。DRモードでは、リターントラフィックがクライアントに直接向かい、大容量L4ワークロードに対してより効率的なパスを提供します。
VIPをホストするRoute TableとバックエンドをホストするRoute Tableは異なる場合があります。TR7は2つのネットワークドメイン間で制御された方法でトラフィックを運び、DMZ、内部、テナント、管理セグメントをフラット化せずに接続します。
TR7は特定のバックエンドIPに向かうトラフィックの所有権を取得し、インラインで動作できます。バックエンドのIPアドレス、ゲートウェイ、アプリケーション設定はADCがパスに挿入される間も変更されません。
デプロイメントトポロジーモードは、迅速な単一インターフェースのセットアップから高スループットL4フォワーディングまでのネットワーク配置をカバーします。
One-armモードでは、クライアントとバックエンドのトラフィックを同一のネットワーク側で処理できます。TR7は単一インターフェースを通じてサービストラフィックを受信し、ルーティングルールを使用して関連するバックエンドに転送します。このモデルは最小限のネットワーク変更で迅速なADCデプロイに適しています。パイロットデプロイメント、一時的なトランジション、または低リスクのロールアウトシナリオの実践的な出発点です。
Two-armモードでは、TR7は2つの異なるネットワークセグメント間に位置します。一方はクライアントまたはDMZネットワーク、他方はバックエンドネットワークです。これによりADCは単なるトラフィックフォワーダーではなく、ネットワーク境界でポリシーを適用するトランジットポイントになります。セキュリティとセグメンテーションを必要とするエンタープライズアーキテクチャに適しています。
リバースプロキシモードでは、クライアントはTR7上のVIPまたはvServiceに接続し、TR7はバックエンドへの別の接続を開きます。TLS終端、WAAP、ヘッダー操作、cookieセキュリティ、コンテンツ認識ルール、AAM統合はすべてこのモードで完全に適用可能です。これはHTTPおよびAPIトラフィックの最も一般的なアプリケーション配信トポロジーです。バックエンドはインターネットや外部ネットワークに直接公開されることはありません。
透過型L7シナリオでは、バックエンドに見えるソースIPはADCアドレスではなく実際のクライアントアドレスです。このモードはヘッダーベースのクライアントIPフォワーディングのみに依存できないアプリケーションに有用です。ログ、アクセス制御、アプリケーション内IPベースの決定がより自然に機能します。ネットワークリターンパスを適切に計画する必要があります。
ブリッジモードはTR7がLayer 2ブリッジとしてトラフィックパスに位置することを可能にします。このシナリオでは追加のIP番号付けや広範なルーティング変更の必要性が軽減されます。VM、コンテナ、またはセグメント間でトラフィックパスに入る際に既存のアドレッシングを保持できます。ブリッジモードはネットワーク変更を最小限に抑える必要がある環境で有用です。
透過型ゲートウェイモードでは、TR7はバックエンドネットワークのトランジットポイントに配置されます。ソースIPが保持され、NATは必要ありません。このモードはバックエンドがクライアントIPを自然に見る必要があるシナリオに有用です。デフォルトルートの変更は慎重に計画し、リターンパスを明示的に制御する必要があります。
TR7は指定されたバックエンドIPのトラフィック所有権を取得し、インラインで動作できます。このモードはバックエンドのIPアドレス、デフォルトゲートウェイ、またはルート設定が変更できない場合に特に有用です。バックエンドにゲートウェイが設定されていない場合でも、TR7は関連するトラフィックパスのコントロールポイントとして位置できます。大規模な環境では、数百のバックエンドを個別に変更する必要なしに制御されたインライン挿入が可能です。
TR7はあるRoute TableのVIPをリッスンし、別のRoute Tableのバックエンドにトラフィックを転送できます。これにより、DMZ、内部、テナント、管理、および個別のサービスゾーンが同一のネットワークプレーンに移動させられることなく制御された方法で互いに接続できます。オペレーターはバックエンドの番号付けを変えたりネットワークをフラット化したりする必要はありません。TR7はRoute Table間のセキュリティポリシーを適用できる制御されたトランジットポイントになります。
L4 NATモードでは、TR7を通じたリターンパスを保証するために宛先と送信元の変換が一緒に使用されます。SNATモードでは送信元側のみが調整され、バックエンドの既存のリターンパス設計が尊重されます。これら2つのモードはL4トラフィックをネットワークトポロジーに合った方法で運ぶことを可能にします。UDP、TCPまたは特定のポート範囲に対して別々の動作を選択できます。
DRモードでは、リクエストトラフィックはTR7を通じてバックエンドに転送され、レスポンストラフィックはクライアントに直接返ります。このモデルは大容量ストリーミング、ゲーミング、DNS、またはレイテンシに敏感なL4サービスに有利です。ADCがリターントラフィックを運ばないため、データパスがより効率的になります。DRシナリオではバックエンドとネットワークリターン動作を正しく準備する必要があります。
L4永続性は特定のクライアントからのトラフィックが同じバックエンドターゲットに留まるようにするのに役立ちます。CONNMARK、最近のレコード、設定可能な永続性ウィンドウがフロー継続性を維持します。SIP永続性はSIPトラフィックなどのセッション感度の高いプロトコルに特化した動作を提供します。これにより基本的な負荷分散に加えてL4レベルのセッション一貫性が得られます。
L4とvService定義に必要なイングレスパーミッションは自動的に生成できます。各フロントエンドIP、ポート、プロトコルに対して適切なアクセプトルールが作成され、手動のファイアウォールエラーを軽減します。自動ルール生成はインラインとL4シナリオで特に重要です。オペレーターはトポロジーを選択し、TR7は関連するトラフィックパスの基本的なパーミッションを一貫して生成します。
トポロジーモードはL4デフォルト、インラインプロセス動作、TR7 Route Table、クラスターロール、エラー可視性とともに運用されます。
Round-robinアルゴリズム、NATモード、UDPプロトコルは新しいL4プールのデフォルト開始値として利用可能です。オペレーターはサービス要件に基づいてこれらをTCP、UDP、任意のプロトコル、ポート範囲、または別のL4アルゴリズムに変更できます。デフォルトは高速な開始のためのものです；本番動作は明示的にレビューする必要があります。
Round-robinや重み付きround-robinなどのアルゴリズムをL4分散に使用できます。重み付きモデルは容量が異なるバックエンド間でよりバランスの取れたトラフィック分散を提供します。アルゴリズム選択はサービスタイプ、容量、セッション動作とともに計画する必要があります。
IP引き継ぎインラインモードは関連するインターフェース、バックエンドIP、ゲートウェイ情報に基づいて動作します。ゲートウェイが明示的に指定されていない場合、既存のネットワーク情報から適切なパスを導出できます。プロセスが予期せず停止した場合、自動再起動を適用できます。
インラインモードでは、noBackendIp、ipUsed、noZoneId、noMatchingIp、noSpoofingIp、inactiveClusterDevice、inactiveClusterIpなどの状態を明示的なエラー理由として表示できます。これにより運用チームは単に何かが機能していないのではなく、なぜ機能していないのかを正確に把握できます。エラー可視性はインライントポロジーを安全に運用するために重要です。
クラスター環境では、インライン引き継ぎプロセスはアクティブロールを持つデバイスのみで実行する必要があります。アクティブデバイスが変更されると、インライントラフィックの所有権が関連するノードに移動します。このモデルは2つのノードが同時に同一IPの所有権を主張するのを防ぐのに役立ちます。
インライン透過型モードはバックエンドのデフォルトゲートウェイ設定への依存性を軽減します。バックエンドにゲートウェイがない場合やゲートウェイを変更できない場合、TR7はIP引き継ぎメソッドを使用して関連するトラフィックパスを引き継ぐことができます。この機能はメンテナンスウィンドウを開かずにバックエンドを変更せずに制御されたADCデプロイメントを可能にします。
VIPがリッスンするTR7 Route TableとバックエンドがあるTR7 Route Tableは異なる場合があります。TR7はこれら2つのネットワークドメイン間でトラフィックを運び、トポロジー変更の必要性を軽減します。この動作は特にDMZから内部ネットワーク、テナントネットワークから共有サービスネットワーク、または移行中の古いネットワークドメインと新しいネットワークドメイン間の制御されたトランジションに有用です。
大規模な組織では、数百のバックエンドのIP、ルート、ゲートウェイを変更することはリスクが高いです。IP引き継ぎインラインモードにより、既存のアドレッシングを保持しながらTR7 ADCをトラフィックパスに挿入できます。
一部のレガシーまたは孤立したバックエンドにはデフォルトゲートウェイが設定されていないかもしれません。インライン透過型モードでは、TR7はバックエンドのゲートウェイ設定に触れずに関連するトラフィックを引き継ぐことができます。
組織はDMZ Route TableでVIPをリッスンしながら、内部Route Tableにバックエンドを保持できます。TR7はネットワークを統合したりサービスIPの番号付けを変えたりせずに、2つのドメイン間で制御されたトラフィックトランジットを提供します。
ゲーミングまたはストリーミングチームはDRモードを使用してレスポンストラフィックをクライアントに直接送ることができます。TR7がフォワーディング決定を行う間、リターンデータパスの負荷が軽減され、高スループットシナリオがより効率的になります。
One-armから透過型インライン、L4 DRからクロスRoute Tableフォワーディングまで — ライブセットアップで正しいトポロジーをご案内します。