ゲートウェイロードバランサー（GWLB）は、ファイアウォール、侵入検知、トラフィックミラーリング、ディープパケットインスペクション（DPI）などのシナリオで、サードパーティの仮想ネットワークアプライアンス（NVA）をデプロイ、拡張、または管理するのに最適です。 GWLB は、Open Systems Interconnection（OSI）<リファレンス>参照モデルのレイヤー 3 で透過モードで動作します。そのため、GWLB を使用して NVA をデプロイする前に準備を行う必要があります。このトピックでは、GWLB のしくみと、NVA を GWLB と統合する方法について説明します。
GWLB とは
GWLB は、OSI 参照モデルのネットワークレイヤーとも呼ばれるレイヤー 3 で動作するロードバランサーです。 GWLB は、エンタープライズ アプリケーションがファイアウォール、侵入検知、トラフィックミラーリング、DPI などのシナリオでさまざまなタイプのサードパーティ NVA をデプロイ、拡張、および管理するのに役立ちます。 GWLB は次の機能を提供します。
GWLB は、複数のサードパーティ NVA のデプロイをサポートしています。
GWLB は、サードパーティ NVA のより信頼性の高いデプロイを提供します。
GWLB は、サードパーティ NVA のゾーン間の可用性をサポートしています。
GWLB は PrivateLink と連携して、仮想プライベートクラウド（VPC）およびアカウント全体でサードパーティ NVA の可用性を維持できます。
GWLB は、サードパーティ NVA プロバイダーのサービスとしてのソフトウェア（SaaS）サービスと互換性があります。
しくみ
ワークフロー
次の図に示すように、GWLB インスタンスは別の VPC の GWLB エンドポイントに接続されています。 GWLB エンドポイントは、特殊なタイプの VPC エンドポイントです。 1 つの GWLB インスタンスを複数の GWLB エンドポイントに接続できます。
次の表は、GWLB インスタンスのしくみについて説明しています。
番号 | 説明 |
① | クライアントからサーバーへのネットワーク トラフィックは、GWLB エンドポイントにルーティングされます。 |
② | GWLB エンドポイントは、PrivateLink 経由で、ネットワーク トラフィックを関連付けられた GWLB インスタンスに転送します。 |
③ | GWLB インスタンスは、GENEVE を使用して元のパケットをカプセル化し、トラフィック スケジューリング アルゴリズムに基づいて、バックエンドの正常な NVA にトラフィックを転送します。 NVA は、GENEVE によって伝送される 64 ビット GWLB エンドポイント ID などの情報に基づいてトラフィック ソースを識別します。 |
④ | NVA はパケットを処理した後、GENEVE を使用してパケットを GWLB インスタンスに転送します。 |
⑤ | GWLB インスタンスは、PrivateLink 経由で、トラフィックを対応する GWLB エンドポイントに転送します。 |
⑥ | GWLB エンドポイントは、宛先アドレスに基づいてルートをクエリし、トラフィックを宛先サーバーに転送します。 |
トラフィック スケジューリングの方法
GWLB は、5 タプル、3 タプル、または 2 タプル パケットの一貫性のあるハッシュアルゴリズムに基づくトラフィック スケジューリングをサポートしています。 5 タプル パケットには、送信元 IP アドレス、宛先 IP アドレス、プロトコル、送信元ポート、および宛先ポートが含まれています。 3 タプル パケットには、送信元 IP アドレス、宛先 IP アドレス、およびプロトコルが含まれています。 2 タプル パケットには、送信元 IP アドレスと宛先 IP アドレスが含まれています。 GWLB は、同じタプルを持つトラフィックを同じバックエンドサーバーにルーティングします。
一般的なケース:
TCP または UDP 経由で送信されるトラフィックの場合、5 タプル パケットに基づくハッシュアルゴリズムを選択できます。
TCP および UDP 以外のプロトコル経由で送信されるトラフィックの場合、3 タプル パケットに基づくハッシュアルゴリズムを選択できます。
ヘルスチェックメカニズム
GWLB は、特定の間隔で定期的にヘルスチェックを実行します。 GWLB は、TCP、HTTP、または HTTPS パケットをバックエンド NVA に送信し、バックエンド NVA の<レスポンス>に基づいて、バックエンド NVA が正常かどうかを確認します。
TCP: GWLB がバックエンド NVA と TCP <接続>を確立できる場合、GWLB はバックエンド NVA を正常と見なします。
HTTP または HTTPS: GWLB が HTTP または HTTPS <リクエスト>をバックエンド NVA に送信した後に HTTP ステータスコード 2xx または 3xx が返された場合、GWLB はバックエンド NVA を正常と見なします。 それ以外の場合、GWLB はバックエンド NVA を異常と見なします。 GWLB は、渡された<証明書>のホスト名検証を実行しません。 そのため、自己署名<証明書>を含む<証明書>は、期限切れでない限り有効になります。
ヘルスチェックパケットは GENEVE によってカプセル化されていません。
ヘルスチェックのタイムアウト期間が終了する前に NVA が<応答>しない場合、NVA はヘルスチェックに失敗します。
GWLB と NVA の統合
統合方法
GWLB は、GENEVE プロトコルを介してバックエンド NVA と通信します。 GWLB は、GWLB エンドポイント ID やフロー Cookie などの追加情報を NVA に送信するために、各パケットに GENEVE タイプ-長さ-値（TLV）をカプセル化します。 NVA が受信する GENEVE パケットには、1 つ以上の GENEVE TLV が含まれている場合があります。
GWLB エンドポイント ID: GWLB エンドポイントに割り当てられた 64 ビット ID。 NVA は、GWLB エンドポイント ID を使用してパケットを<構成>に関連付けることができます。 GWLB エンドポイント ID は、トラフィックの<ソース>を特定するためにも使用されます。
フロー Cookie: GWLB がフローテーブルにフローエントリを作成するときにフローに対して生成される 32 ビットの<乱数>。 各フローには一意の Cookie があります。 NVA は元の Cookie を返す必要があります。 GWLB が NVA からパケットを受信すると、パケット内の Cookie がフローに割り当てられた Cookie と一致する場合にのみ、GWLB はパケットを転送します。 Cookie が割り当てられた Cookie と一致しない場合、または Cookie が存在しない場合、パケットは破棄されます。
次の<プロセス>は、NVA が<リクエスト>に<応答>する方法について説明しています。
元のパケットを GENEVE <ヘッダー>にカプセル化します。
外部 IPv4 <ヘッダー>の送信元 IP アドレスと宛先 IP アドレスを交換します。 送信元 IP アドレスは NVA の IP アドレスであり、宛先 IP アドレスは GWLB の IP アドレスです。
元のポートを保存し、外部 IPv4 <ヘッダー>の送信元ポートと宛先ポートを交換しないでください。
外部 IPv4 <ヘッダー>の IP チェックサムを更新します。
GENEVE <ヘッダー>のすべての元のフィールドを返します。
GWLB エンドポイント ID とフロー Cookie を含む、GENEVE オプションのすべての元の TLV を返します。
GENEVE パケット<フォーマット>
次の例は、GENEVE パケットの<フォーマット>を示しています。 GENEVE の詳細については、「RFC 8926」をご参照ください。
Outer IPv4 Header: // 外部 IPv4 ヘッダー
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |Protocol=17 UDP| Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = xxxx | Dest Port = 6081 Geneve |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Geneve Header: // 外部 Geneve ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=0|Opt Len = 8|O|C| Rsvd. | EtherType = 0x0800 or 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Network Identifier (VNI) = 0 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer Geneve Options: Alibaba Cloud Gateway Load Balancer TLVs // 外部 Geneve オプション: Alibaba Cloud ゲートウェイロードバランサー TLV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = 0x0139 (Ali)| Type = 1 |R|R|R| Len = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 64-bit GWLB endpoint ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Class = 0x0139 (Ali)| Type = 3 |R|R|R| Len = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit Flow Cookie |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Customer payload follows... // 顧客ペイロードが続きます
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Customer payload identified by EtherType in Geneve header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+