外部パススルー ネットワーク ロードバランサのトラフィック分散

このページでは、外部パススルー ネットワーク ロードバランサがトラフィックを分散する方法の詳細を理解し、カスタマイズするために役立つ次のコンセプトについて説明します。セッション アフィニティ、接続トラッキング、重み付けロード バランシング、接続ドレイン、UDP フラグメンテーション、フェイルオーバー。

外部パススルー ネットワーク ロードバランサによる新しい接続の分散方法は、フェイルオーバーを構成しているかどうかによって異なります。

  • フェイルオーバーを構成していない場合、少なくとも 1 つのバックエンド VM が正常であれば、外部パススルー ネットワーク ロードバランサによって正常なバックエンド VM に新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、最後の手段としてロードバランサによりすべてのバックエンドの間で新しい接続が分散されます。この場合、ロードバランサにより正常でないバックエンド VM にそれぞれ新しい接続が転送されます。
  • フェイルオーバーを構成している場合は、構成したフェイルオーバー ポリシーに従って、外部パススルー ネットワーク ロードバランサによってアクティブ プール内の正常なバックエンド VM 間での新しい接続が分散されます。すべてのバックエンド VM が正常でない場合は、次の動作の中からいずれかを選択できます。
    • (デフォルト)ロードバランサは、プライマリ VM にのみトラフィックを分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
    • ロードバランサはトラフィックをドロップします。

接続の分散方法の詳細については、次のセクションのバックエンドの選択と接続トラッキングをご覧ください。

フェイルオーバーの機能の詳細については、フェイルオーバーのセクションをご覧ください。

バックエンドの選択と接続トラッキング

外部パススルー ネットワーク ロードバランサでは、構成可能なバックエンドの選択と接続トラッキング アルゴリズムを使用して、トラフィックをバックエンド VM に分散する方法が決定されます。

外部パススルー ネットワーク ロードバランサでは、次のアルゴリズムを使用して、(フェイルオーバーを構成している場合は、アクティブ プール内の)バックエンド VM 間にパケットが分散されます。

  1. ロードバランサに、受信パケットの特性と一致する接続トラッキング テーブルがある場合、パケットは接続トラッキング テーブルのエントリで指定されたバックエンドに送信されます。パケットは、以前に確立した接続の一部と見なされるため、ロードバランサによって接続トラッキング テーブルに以前に決定され記録されたバックエンド VM に送信されます。
  2. ロードバランサで対応する接続トラッキング エントリがないパケットを受信した場合、ロードバランサでは次が行われます。

    1. ロードバランサでバックエンドが選択されます。 ロードバランサは、構成されたセッション アフィニティに基づいてハッシュを計算します。ロードバランサは、このハッシュを使用して、正常な状態のバックエンドの中からバックエンドを 1 つ選択します(ただし、すべてのバックエンドが異常な状態である場合を除きます。その場合は、この状況でフェイルオーバー ポリシーがトラフィックをドロップするように構成されていない限り、すべてのバックエンドが考慮されます)。デフォルトのセッション アフィニティ NONE では、次のハッシュ アルゴリズムが使用されます。

      • TCP パケットと断片化されていない UDP パケットの場合、パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュ
      • 断片化された UDP パケットと他のすべてのプロトコルの場合、パケットの送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ

      バックエンドの選択は、使用する情報が少ないハッシュ アルゴリズムを使用してカスタマイズできます。サポートされているすべてのオプションについては、セッション アフィニティのオプションをご覧ください。

      さらに、次の点に留意してください。

      重み付き負荷分散を有効にすると、ハッシュベースのバックエンド選択はバックエンド インスタンスから報告された重みに基づいて重み付けされます。次に例を示します。

      • セッション アフィニティが NONE に構成されたバックエンド サービスと、プロトコル UDP の転送ルールについて考えてみましょう。重み 1 と 4 の正常なバックエンド インスタンスが 2 つある場合、バックエンドはそれぞれ UDP パケットの 20% と 80% を受信します。
      • 3 タプルのセッション アフィニティと接続トラッキングで構成されているバックエンド サービスについて考えてみましょう。セッション アフィニティは CLIENT_IP_PROTO で、接続トラッキング モードは PER_SESSION です。重みが 0、2、6 の正常なバックエンド インスタンスが 3 つある場合、バックエンドはそれぞれ新しいソース IP アドレス (既存の接続トラッキングテーブルエントリがないソース IP アドレス) の 0%、25%、75% のトラフィックを取得します。既存の接続トラフィックは、以前に割り当てられたバックエンドに送信されます。
    2. ロードバランサにより、接続トラッキング テーブルにエントリが追加されます。このエントリによって、パケット接続用に選択されたバックエンドが記録されるため、この接続からの以降のパケットがすべて同じバックエンドに送信されます。接続トラッキングを使用するかどうかは、プロトコルによって異なります。

      • TCP パケット。接続トラッキングは常に有効になっています。オフにすることはできません。デフォルトでは、接続トラッキングは 5 タプルですが、5 タプル未満に構成することもできます。5 タプルの場合、TCP SYN パケットは異なる方法で処理されます。SYN 以外のパケットとは異なり、一致する接続トラッキング エントリを破棄し、常に新しいバックエンドを選択します。

        デフォルトの 5 タプル接続トラッキングは、次の場合に使用されます。

        • トラッキング モードが PER_CONNECTION(すべてのセッション アフィニティ)の場合。または
        • トラッキング モードが PER_SESSIONでセッション アフィニティが NONEの場合。または
        • トラッキング モードが PER_SESSION であり、セッション アフィニティが CLIENT_IP_PORT_PROTO の場合。
      • UDP、ESP、GRE パケット。接続トラッキングは、セッション アフィニティが NONE 以外に設定されている場合にのみ有効になります。

      • ICMP パケットと ICMPv6 パケット。接続トラッキングは使用できません。

      接続トラッキングが有効にされている場合と、接続トラッキングが有効な場合のトラッキング方法の詳細については、接続トラッキング モードをご覧ください。

      さらに、次の点に留意してください。

      • 接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 60 秒後に失効します。詳細については、アイドル タイムアウトをご覧ください。
      • プロトコルによっては、バックエンドが正常な状態ではなくなると、ロードバランサによって接続トラッキング テーブルのエントリが削除される場合があります。この動作の詳細とカスタマイズ方法については、異常なバックエンドでの接続の永続性をご覧ください。

セッション アフィニティのオプション

セッション アフィニティは、クライアントからロードバランサのバックエンド VM への新しい接続の分散を制御します。セッション アフィニティは、バックエンドごとではなく、リージョン外部バックエンド サービス全体に対して指定されます。

外部パススルー ネットワーク ロードバランサは、次のセッション アフィニティ オプションをサポートしています。

  • なし(NONE。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ
  • クライアント IP、宛先 IP(CLIENT_IP)。送信元 IP アドレスと宛先 IP アドレスの 2 タプルハッシュ
  • クライアント IP、宛先 IP、プロトコル(CLIENT_IP_PROTO)。送信元 IP アドレス、宛先 IP アドレス、プロトコルの 3 タプルハッシュ
  • クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル(CLIENT_IP_PORT_PROTO)。送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートの 5 タプルハッシュ

これらのセッション アフィニティのオプションがバックエンドの選択と接続トラッキング方法に与える影響については、この表をご覧ください。

接続トラッキング ポリシー

このセクションでは、外部パススルー ネットワーク ロードバランサの接続トラッキング動作を制御する設定について説明します。接続トラッキング ポリシーには次の設定が含まれます。

接続トラッキング モード

接続トラッキングを有効にするかどうかは、負荷分散されたトラフィックのプロトコルとセッション アフィニティの設定のみによって決定されます。トラッキング モードでは、接続トラッキングが有効な場合に使用される接続トラッキング アルゴリズムを指定します。トラッキング モードには、PER_CONNECTION(デフォルト)と PER_SESSION の 2 つがあります。

  • PER_CONNECTION(デフォルト)。これはデフォルトのトラッキング モードです。この接続トラッキング モードでは、セッション アフィニティの設定に関係なく、TCP トラフィックが常に 5 タプルごとに追跡されます。UDP、ESP、GRE トラフィックで、選択したセッション アフィニティが NONE 以外の場合は、接続トラッキングが有効になります。UDP、ESP、GRE パケットは、こちらので説明されているトラッキング方法で追跡されます。

  • PER_SESSIONセッション アフィニティが CLIENT_IP または CLIENT_IP_PROTO の場合にこのモードを構成すると、(トラッキング可能な接続ではない ICMP と ICMPv6 を除く)すべてのプロトコルに対して、それぞれ 2 タプルと 3 タプルの接続トラッキングが行われます。他のセッション アフィニティの設定の場合、PER_SESSION モードの動作は PER_CONNECTION モードとまったく同じです。

プロトコルごとに異なるセッション アフィニティが設定されているこれらのトラッキング モードの動作については、次の表をご覧ください。

バックエンドの選択 接続トラッキング モード
セッション アフィニティの設定 バックエンド選択のハッシュ方法 PER_CONNECTION(デフォルト) PER_SESSION
デフォルト: セッション アフィニティなし

NONE

TCP と断片化されていない UDP: 5 タプルハッシュ

断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ

  • TCP: 5 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP: 5 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
クライアント IP、宛先 IP

CLIENT_IP

すべてのプロトコル: 2 タプルハッシュ
  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP、ESP、GRE: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP、UDP、ESP、GRE: 2 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
クライアント IP、宛先 IP、プロトコル

CLIENT_IP_PROTO

すべてのプロトコル: 3 タプルハッシュ
  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP、ESP、GRE: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP、UDP、ESP、GRE: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル

CLIENT_IP_PORT_PROTO

TCP と断片化されていない UDP: 5 タプルハッシュ

断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ

  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP、ESP、GRE: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ
  • TCP と断片化されていない UDP: 5 タプル接続トラッキング
  • 断片化された UDP、ESP、GRE: 3 タプル接続トラッキング
  • 他のすべてのプロトコル: 接続トラッキングがオフ

接続トラッキング モードを変更する方法については、接続トラッキング ポリシーの設定をご覧ください。

異常なバックエンドでの接続の永続性

バックエンドが異常な状態になった後も、選択した VM またはバックエンドで既存の接続を維持するかどうかは、バックエンドがロードバランサの構成済みバックエンド インスタンス グループ(インスタンス グループまたは NEG)に残っている限り、接続の永続性の設定で制御します。

このセクションで説明する動作は、インスタンス グループからバックエンド インスタンスを削除する場合、NEG からバックエンド エンドポイントを削除する場合、バックエンド サービスからインスタンス グループまたは NEG を削除する場合には該当しません。このような場合、確立された接続はコネクション ドレインで説明されている内容に基づいてのみ維持されます。

使用できる接続の永続性に関するオプションは次のとおりです。

  • DEFAULT_FOR_PROTOCOL(デフォルト)
  • NEVER_PERSIST
  • ALWAYS_PERSIST

次の表には、接続の永続性のオプションと、さまざまなプロトコル、セッション アフィニティのオプション、トラッキング モードのために接続を維持する方法がまとめられています。

異常なバックエンド オプションでの接続の永続性 接続トラッキング モード
PER_CONNECTION PER_SESSION
DEFAULT_FOR_PROTOCOL

TCP: 異常なバックエンドで接続が維持されます(すべてのセッション アフィニティ)

他のすべてのプロトコル: 異常なバックエンドでは接続が維持されることはありません

TCP: セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO の場合、異常なバックエンドで接続が維持されます

他のすべてのプロトコル: 異常なバックエンドでは接続が維持されることはありません

NEVER_PERSIST すべてのプロトコル: 異常なバックエンドでは接続が維持されることはありません
ALWAYS_PERSIST

TCP: 異常なバックエンドで接続が維持されます(すべてのセッション アフィニティ)

ESP、GRE、UDP: セッション アフィニティが NONE でない場合に、異常なバックエンドで接続が維持されます。

ICMP、ICMPv6: 接続トラッキングできないため、対象外です。

このオプションは、高度なユースケースにのみ使用してください。

設定が不可能

異常なバックエンドでの TCP 接続の永続性の動作

正常でないバックエンドで 5 タプル トラッキングの TCP 接続が維持される場合は常時:

  • 異常なバックエンドがパケットに引き続き応答する場合、接続がリセットされるか、(異常なバックエンドまたはクライアントによって)クローズされるまで、接続は維持されます。
  • 正常でないバックエンドが TCP リセット(RST)パケットを送信するか、パケットに応答しない場合、クライアントは新しい接続で再試行するため、ロードバランサは別の正常なバックエンドを選択できます。TCP SYN パケットは常に新しい正常なバックエンドを選択します。

接続の永続性の動作を変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。

アイドル タイムアウト

接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 60 秒後に失効します。このアイドル タイムアウト値は変更できません。

重み付きロード バランシング

重み付きロード バランシングを使用して、HTTP ヘルスチェックから報告された重みに基づいてロードバランサのバックエンド インスタンス間でトラフィックを分散するようにネットワーク ロードバランサを構成できます。

重み付き負荷分散では、次の両方を構成する必要があります。

  • バックエンド サービスの局所的なロードバランサ ポリシー(localityLbPolicy)を WEIGHTED_MAGLEV に設定する必要があります。
  • バックエンド サービスで HTTP ヘルスチェックを構成する必要があります。HTTP ヘルスチェック レスポンスには、カスタム HTTP レスポンス ヘッダー フィールド X-Load-Balancing-Endpoint-Weight が含まれている必要があります。これにより、0 から 1000 までの値を使用して、各バックエンド インスタンスの重み付けを指定できます。

重み付きロード バランシングを使用して、バックエンド サービスベースの複数のバックエンド サービスベースの外部パススルー ネットワーク ロードバランサに同じバックエンド(インスタンス グループまたは NEG)を使用する場合は、バックエンド サービスのヘルスチェックごとに一意の request-path を使用することをおすすめします。これにより、エンドポイント インスタンスは異なるバックエンド サービスに異なる重みを割り当てることができます。詳細については、HTTP、HTTPS、HTTP/2 ヘルスチェックの成功基準をご覧ください。

新しい接続のバックエンドを選択する場合、次の表に示すように、バックエンドには重みとヘルス ステータスに基づいて、厳密な優先順位が割り当てられます。

重み 正常 バックエンド選択の優先度
重みが 0 より大きい 4
重みが 0 より大きい × 3
重みが 0 に等しい 2
重みが 0 に等しい × 1

優先度が最も高いバックエンドのみがバックエンドの選択対象となります。対象となるすべてのバックエンドの重みが 0 の場合、ロードバランサはすべての適格なバックエンド間で新しい接続を分散し、同等の重みで扱います。重み付き負荷分散の例については、バックエンドの選択と接続トラッキングをご覧ください。

重み付き負荷分散は、次のシナリオで使用できます。

  • 一部の接続が他の接続よりも多くのデータを処理する場合や、一部の接続が他の接続よりも長く存続する場合、バックエンドのロード バランシングが不均等になる可能性があります。インスタンスごとの重みが低いことを通知することで、既存の接続の処理を継続しながら、負荷の高いインスタンスで新しい接続のシェアを下げることができます。

  • バックエンドが過負荷状態になり、より多くの接続を割り当てると既存の接続が切断される可能性があります。このようなバックエンドは、ゼロの重みを割り当てます。重み 0 を通知することで、バックエンド インスタンスは新しい接続の処理を停止しますが、既存の接続の処理は継続します。

  • メンテナンスの前にバックエンドで既存の接続がドレインされると、バックエンドには重み 0 が割り当てられます。重みゼロを通知することで、バックエンド インスタンスは新しい接続の処理を停止しますが、既存の接続の処理は継続します。

詳細については、重み付き負荷分散を構成するをご覧ください。

コネクション ドレイン

コネクション ドレインは、次の場合に確立済みの接続に適用されるプロセスです。

  • VM またはエンドポイントがバックエンド(インスタンス グループまたは NEG)から削除された場合。
  • バックエンドが VM またはエンドポイントを削除する場合(置換、放棄、ローリング アップグレード、スケールダウンにより)。
  • バックエンドがバックエンド サービスから削除された場合。

デフォルトでは、コネクション ドレインは無効になっています。無効にすると、確立された接続はできる限り早く終了します。コネクション ドレインを有効にすると、確立された接続は設定可能なタイムアウトまで維持され、その時間が経過するとバックエンド VM インスタンスは終端されます。

コネクション ドレインのトリガーとコネクション ドレインを有効にする方法の詳細については、コネクション ドレインの有効化をご覧ください。

UDP の断片化

バックエンド サービスベースの外部パススルー ネットワーク ロードバランサは、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理できます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。

  • UDP パケットは、 Google CloudVPC ネットワークに到達する前に断片化される場合があります。
  • Google Cloud VPC ネットワークでは、到達した UDP フラグメントが(すべてのフラグメントの到達を待たずに)転送されます。
  • Google Cloud 以外のネットワークとオンプレミス ネットワーク機器では、UDP フラグメントが到達すると転送される可能性、すべてのフラグメントが到達するまで断片化された UDP パケットが遅延される可能性、または断片化された UDP パケットが破棄される可能性があります。詳しくは、ネットワーク プロバイダまたはネットワーク機器のドキュメントをご覧ください。

断片化された UDP パケットを処理する可能性があり、それを同じバックエンドにルーティングする必要がある場合は、次の転送ルールとバックエンド サービスの構成パラメータを使用します。

  • 転送ルールの構成: 負荷分散された IP アドレスごとに UDP または L3_DEFAULT 転送ルールを 1 つだけ使用し、すべてのポートでトラフィックを受信するように転送ルールを構成します。これで、すべてのフラグメントが同じ転送ルールに渡されるようになります。断片化されたパケット(最初のフラグメント以外)には宛先ポートがありませんが、すべてのポートのトラフィックを処理する転送ルールを構成すると、ポート情報がない UDP フラグメントも受信するように構成されます。すべてのポートを構成するには、Google Cloud CLI を使用して --ports=ALL を設定するか、API を使用して allPortsTrue に設定します。

  • バックエンド サービスの構成: バックエンド サービスのセッション アフィニティCLIENT_IP(2 タプルハッシュ)または CLIENT_IP_PROTO(3 タプルハッシュ)に設定し、ポート情報を含む UDP パケットとポート情報がない UDP フラグメント(最初のフラグメント以外)に同じポートが選択されるようにします。バックエンド サービスの接続トラッキング モードPER_SESSION に設定して、接続トラッキング テーブルのエントリが同じ 2 タプルハッシュまたは 3 タプルハッシュを使用して構築されるようにします。

フェイルオーバー

プライマリ バックエンド(インスタンス グループまたは NEG)の VM インスタンスまたはエンドポイント間で接続を分散し、必要に応じてフェイルオーバー バックエンドを使用するように、外部パススルー ネットワーク ロードバランサを構成できます。フェイルオーバーにより可用性を向上させるだけでなく、プライマリ バックエンドが正常に動作していない場合にワークロードをより効率的に管理できます。

デフォルトでは、外部パススルー ネットワーク ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドはプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。

フェイルオーバーの詳細については、外部パススルー ネットワーク ロードバランサのフェイルオーバーの概要をご覧ください。

次のステップ