企業トラフィックはHTTPアプリケーションだけで構成されるわけではありません。DNS、SIP、RADIUS、NTP、生のTCPサービス、トンネルプロトコル、高ボリュームのstreamingフローは異なる振る舞いをします。これらのサービスでは、コンテンツ処理よりも低レイテンシ、低CPU消費、高速な判断、正しいリターン経路がより重要です。
L4とL7のロードバランシングが別個の製品、別個のコンソール、別個のライセンス層のように管理されると、運用が複雑になります。あるチームはDNSとUDPサービスのために別個のネットワークコンポーネント、Webアプリケーションのために別個のADC、セキュリティのために別個の層を管理せざるを得なくなります。問題が起きたとき、どのトラフィックがどの製品を通過したかという問いだけでも時間を浪費させます。
UDPトラフィックは特別な注意を要します。接続状態がTCPほど明確でないため、persistence、ソースIPの振る舞い、NATの影響、backendの応答経路を正しく設計する必要があります。SIPのようなプロトコルではセッションが同じサービス上に留まる必要がある一方、DNSやNTPのようなサービスでは可能な限り低いレイテンシが前面に出ます。
direct returnやIPトンネルのようなモードは正しく構築されれば大きな利点をもたらします;しかしネットワーク要件が明確に把握されていなければ問題を生みます。direct routingモードでは、backend上でVIP loopback alias、ARPの振る舞い、リターン経路の設定が正しく行われる必要があります。さもなければ、性能向上ではなく可用性の問題が発生します。
TR7のL4モードは、カーネルレベルの低レイテンシトラフィック分散、異なるネットワークトポロジーに適したモード選択、L4+L7の混在動作を、単一のADC管理モデルの下にまとめます。
TR7は、L4トラフィックをカーネルレベルで処理しながら、モード、アルゴリズム、ヘルスチェック、混在サービス管理を集中的に提供します。
TR7はL4ロードバランシングのためにLinux LVS/IPVSインフラを活用します。このアプローチは、ユーザー空間の処理コストを削減することで、TCPおよびUDPトラフィックでの高速な判断を可能にします。
各L4サービスプールについて、プロトコル、アルゴリズム、backendリスト、重み、接続制限、ヘルスチェックが設定されます。TR7のL4オーケストレーション層が、この設定を実行可能なL4バランシングの振る舞いに変換します。
NAT、SNAT、direct routing、IPトンネル、汎用プロトコル転送モードは異なるニーズに対応します。オペレーターは、トラフィックのリターン経路、ソースIPの保存、backendの配置に応じて適切なモードを選択します。
同じTR7上でHTTP/TCPベースのL7サービスとIPVSベースのL4サービスが並んで動作できます。これにより、単一のVIP上で異なるポートを異なる処理エンジンにルーティングできます。
TR7 L4モードは、異なるプロトコル、ネットワークトポロジー、サービスの振る舞いのために柔軟なバランシングオプションを提供します。
TR7はNAT、SNAT、direct routing、IPトンネル、汎用プロトコル転送モードをサポートします。NATモードではリターントラフィックがロードバランサーを経由します。direct routingモードではリターン経路がbackendからクライアントへ直接流れます。IPトンネルモードはリモートロケーションや異なるネットワーク越えを必要とするシナリオで使用できます。
L4サービスプールはTCPまたはUDPプロトコルで定義できます。DNS、SIP、RADIUS、NTPのようなUDPサービスは、L7処理パイプラインに強制されることなくバランシングできます。TCPサービスはポートベースの低レイテンシ分散のために使用できます。各プールは単一プロトコルのロジックでシンプルかつ予測可能に動作します。
TR7はround robin、weighted round robin、least connection、weighted least connection、source hash、destination hashアルゴリズムをサポートします。重み付きアルゴリズムは、より強力なbackendにより多くのトラフィックを送るために使用できます。ハッシュベースのアルゴリズムは、同じソースまたは宛先が同じサービスにルーティングされることを容易にします。これらのアルゴリズムはL7アルゴリズムとは独立してL4プールで動作します。
ソースIPベースのpersistenceのためにtimeout値を定義できます。デフォルトのアプローチは、一定時間にわたって同じソースが同じbackendにルーティングされることを保証します。SIPトラフィックではcall-idベースのpersistenceエンジンが使用できます。この構造は、UDPベースのセッションの振る舞いが切断されることを防ぐのに役立ちます。
L4サービスプールはヘルスチェックとともに管理できます。L4ヘルスチェックメカニズムは、適切でないbackendを分散から外すことができます。HTTPベースのチェック経由で管理APIや専用のヘルスエンドポイントを監視できます。これにより、L4判断は単なるポート定義ではなく、実際のサービス可用性に基づいて行われます。
各backendについてweight値を定義でき、重み付きアルゴリズムではトラフィック比率がそれに応じて決定されます。接続制限により、単一のbackendの過負荷を制限できます。この機能により、容量の異なるサービスが同じプールでよりバランスよく使用されます。運用チームはサービスの追加と容量拡張のプロセスをより制御された形で管理します。
VRRP failoverメカニズムにより、VIPがHAペア間で移動します。あるADCノードの喪失時に、VIPは他のノード上で引き継がれます。UDPサービスでは短時間のセッション喪失が多くのシナリオで許容できる一方、TCPサービスではfailoverの振る舞いをアプリケーションとセッションの構造に応じて評価する必要があります。このモデルにより、L4サービスを高可用性アーキテクチャに紐づけられます。
IPVS統計経由で接続、パケット、帯域幅の比率を監視できます。瞬間のCPS、入出力パケット比率、入出力帯域幅の値を追跡できます。TR7はこれらの統計をプラットフォームの監視構造に適合する形で生成できます。運用チームはL4プールが実際にどのようにトラフィックを運んでいるかを確認できます。
汎用プロトコルモードは、TCPおよびUDP以外のプロトコルのための汎用L3転送シナリオで使用できます。ESP、GRE、ICMPのようなトラフィックタイプでは、クラシックなポートベースのL4モデルでは不十分な場合があります。このモードでは詳細な接続統計は限定的です;基本的なバイトカウンタ経由で可視性が提供されます。特殊なネットワーク越えのための実用的な転送オプションになります。
L4 namespace設定により、L4サービスプールを別個のネットワークnamespaceのコンテキストで動作させられます。この構造は、異なるテナントやネットワークゾーンの間で区別したい組織にとって重要です。同じデバイス上で複数のネットワークコンテキストをより制御された形で管理できます。分離は、混在展開設計において運用上のセキュリティを高めます。
L4モードを正しく動作させるには、接続追跡、failoverの振る舞い、direct routingの要件、統計の制限、サービス管理を明確に計画する必要があります。
IPVSベースのL4ロードバランシングは、低レイテンシと高throughputを必要とするサービスに適しています。direct routingモードではリターントラフィックがロードバランサーをバイパスするため、特に高ボリュームの応答を生成するサービスで利点をもたらします。実際の容量はネットワークカード、CPU、モード選択、backendトポロジーに依存します。
UDPおよび高負荷のL4サービスでは、Linux conntrackテーブルのサイズが重要になります。デフォルト値は大規模なトラフィックには不十分な場合があります;トラフィックボリュームに応じて計画する必要があります。
VIPはVRRPでHAペア間を移動できます。ノード喪失時にはサービスが他のノード上で継続します。UDPサービスは多くの場合statelessであるためより簡単に回復する一方、TCPセッションでは中断の振る舞いをアプリケーションの許容度に応じて評価する必要があります。
direct routingモードでは、backendがVIPをloopback aliasとして認識する必要があります。ARPの振る舞いのためにarp_ignoreとarp_announceの設定を正しく行うことが重要です。これらの要件が満たされないと、リターン経路の利点ではなくアクセスの問題が発生する可能性があります。
汎用プロトコル転送モードではper-connectionの詳細が限定的です。このモードはむしろ特殊なL3転送のニーズを満たし、基本的なバイトカウンタで監視されます。深い接続分析が必要なサービスでは、TCPまたはUDPモードがより適している場合があります。
L4プール統計は収集されてプラットフォームの一般的な監視形式に適合させられます。接続、パケット、帯域幅の値は履歴記録システムに書き込めます。これにより、L4サービスをL7サービスと同じ運用パネルで監視することが容易になります。
SIP UDPトラフィックでのNATの使用は、ソースIPとリターン経路の振る舞いに影響する可能性があります。backendがクライアントに直接応答を生成したい場合、モード選択を慎重に行う必要があります。SIP persistenceとdirect routingのオプションは、この種のシナリオでより適した設計を提供できます。
各L4プールについて、関連するL4オーケストレーションサービスを監視できます。サービスの状態、稼働時間、最後の状態変化は運用監査の観点で価値があります。これらの情報は、L4設定の変更とfailoverの調査において支援を提供します。
通信事業者やサービスプロバイダーは、UDP 53上で複数のDNS recursor backendをバランシングできます。persistenceをオフにすることで、低レイテンシかつバランスの取れたDNS分散が実現されます。
企業は、UDP 1812と1813のトラフィックをsource hashアルゴリズムで同じクライアントを同じ認証サービスにルーティングできます。この構造は、認証フローにおいて一貫したサービス選択を提供します。
通信環境でUDP 5060のSIPトラフィックをcall-idベースのpersistenceでバランシングできます。同じ通話フローが同じbackendに行くことが、セッションの振る舞いの保持に役立ちます。
メディアやCDNのシナリオで、TCP 80/443のトラフィックをdirect routingモードで動作させられます。リターントラフィックがbackendからクライアントへ直接流れるため、ロードバランサー上のリターン負荷が軽減されます。
インフラサービスでUDP 123のNTPトラフィックをround robinでバランスよく低レイテンシにbackendへ分散できます。persistenceの必要がないこのトラフィックタイプには、シンプルなプール定義で十分です。
同じVIP上で80と443のポートをL7処理エンジンに、53のポートをL4 IPVSエンジンにルーティングできます。単一ライセンスかつ単一コンソール下で、混在トラフィックタイプに向けた個別の最適化が提供されます。
DNS、SIP、RADIUS、NTP、streamingのようなサービスのための、低レイテンシでモードベースのL4ロードバランシング。お客様自身のサービスでライブ環境をご案内します。