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

このページでは、内部パススルー ネットワーク ロードバランサがトラフィックを分散する方法に関するコンセプトについて説明します。

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

バックエンドの選択と接続トラッキングは、複数の接続を異なるバックエンド間で分散し、各接続のすべてのパケットを同じバックエンドに転送するように連携して機能します。これは、2 部構成の戦略で実現されます。まず、コンシステント ハッシュ法を使用してバックエンドが選択されます。その後、この選択が接続トラッキング テーブルに記録されます。

以下のステップは、バックエンドの選択と接続トラッキングのプロセスを示したものです。

1. 以前に選択されたバックエンドを使用するために接続トラッキング テーブルのエントリを確認する。

既存の接続の場合、ロードバランサは接続トラッキング テーブルを使用して、その接続用に以前に選択されたバックエンドを識別します。

ロードバランサは、次のプロセスを使用して、ロードバランスされた各パケットと接続トラッキング テーブルのエントリとの照合を試みます。

• SYN フラグが付いた TCP パケットの場合は次のようになります。

  • ロードバランサの接続トラッキング モードが PER_CONNECTION の場合は、適格なバックエンドを識別するのステップに進みます。PER_CONNECTION トラッキング モードでは、SYN フラグが付いた TCP パケットは、セッション アフィニティの設定に関係なく常に新しい接続を表します。

  • ロードバランサの接続トラッキング モードが PER_SESSION で、セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO のいずれかである場合は、適格なバックエンドを識別するのステップに進みます。PER_SESSION トラッキング モードでは、SYN フラグが付いた TCP パケットは、5 タプルのセッション アフィニティ オプション（NONE または CLIENT_IP_PORT_PROTO）のいずれかを使用している場合にのみ新しい接続を表します。

• 他のすべてのパケットについて、ロードバランサはパケットが接続トラッキング テーブルの既存のエントリと一致するかどうかを確認します。パケットを接続トラッキング テーブルの既存のエントリと比較するために使用される接続タプル（パケット特性のセット）は、接続トラッキング モードとセッション アフィニティの設定によって異なります。接続トラッキングに使用される接続タプルの詳細については、接続トラッキング モードのセクションにある表をご覧ください。

  • パケットが接続トラッキング テーブルのエントリと一致する場合、ロードバランサは以前に選択されたバックエンドにパケットを送信します。

  • パケットが接続トラッキング テーブルのエントリと一致しない場合は、適格なバックエンドを識別するのステップに進みます。

  接続トラッキング テーブルのエントリの存続期間とその条件については、接続トラッキング テーブルのエントリを作成するのステップをご覧ください。

2. 新しい接続用の適格なバックエンドを選択する。

新しい接続の場合、ロードバランサはコンシステント ハッシュ法のアルゴリズムを使用して、アクティブ プール内の適格なバックエンドの中からバックエンドを選択します。

以下のステップは、新しい接続用の適格なバックエンドを選択し、その接続を接続トラッキング テーブルに記録するプロセスの概要を示したものです。

2.1 適格なバックエンドを識別する。

このステップでは、健全性とフェイルオーバー ポリシーの設定を考慮して、新しい接続を受信する候補となるバックエンドをモデル化します。

• フェイルオーバー ポリシーなし: ヘルスチェックのみに基づいて適格なバックエンドのセットが決まります。

  • 少なくとも 1 つのバックエンドが正常な場合、すべての正常なバックエンドで適格なバックエンドのセットが構成されます。

  • すべてのバックエンドが異常な場合、すべてのバックエンドで適格なバックエンドのセットが構成されます。

• フェイルオーバー ポリシーが設定されている: ヘルスチェックとフェイルオーバー ポリシーの設定に基づいて適格なバックエンドのセットが決まります。

  • 少なくとも 1 つのバックエンドが正常な場合、アクティブ プール内のすべての正常なバックエンドで適格なバックエンドのセットが構成されます。

    • アクティブ プールは、すべての正常なプライマリ バックエンドで構成される場合と、すべての正常なフェイルオーバー バックエンドで構成される場合があります。アクティブ プールのメンバーシップは、フェイルオーバー率の設定、正常なプライマリ バックエンドの数、プライマリ バックエンドの総数によって決まります。

    • 正常なフェイルオーバー バックエンドが存在せず、正常なプライマリ バックエンドが少なくとも 1 つ存在する場合は、フェイルオーバー率に関係なく、すべての正常なプライマリ バックエンドでアクティブ プールが構成されます。

  • 正常なバックエンドがなく、ロードバランサのフェイルオーバー ポリシーが新しい接続をドロップするように構成されている場合、適格なバックエンドのセットは空になります。接続のパケットはロードバランサでドロップされます。

  • 正常なバックエンドがなく、ロードバランサのフェイルオーバー ポリシーが新しい接続をドロップするように構成されていない場合、ヘルスチェックは考慮されません。すべてのプライマリ バックエンドで適格なバックエンドが構成されます。

2.2 適格なバックエンドを選択する。

ロードバランサは、コンシステント ハッシュ法を使用して適格なバックエンドを選択します。ロードバランサは、単位円にマッピングされた適格なバックエンドのハッシュを保持します。接続トラッキング テーブルにない接続のパケットを処理する場合、ロードバランサはパケットの特性のハッシュを計算し、そのハッシュを同じ単位円にマッピングして、円の円周上の適格なバックエンドを選択します。パケットのハッシュの計算に使用されるパケットの特性のセットは、セッション アフィニティの設定で定義されます。

• セッション アフィニティが明示的に設定されていない場合、NONE セッション アフィニティがデフォルトになります。

• ロードバランサは、適格なバックエンドの数が変化しても、可能な限り一貫した方法で新しい接続を適格なバックエンドに割り当てます。コンシステント ハッシュ法には次のような利点があります。これは、接続トラッキング テーブルのエントリがない新しい接続の候補に対して、ロードバランサが適格なバックエンドをどのように選択するかを示しています。

  • セッション アフィニティで定義されているパケットの特性が同じすべての新しい接続の候補に対して、適格なバックエンドのセットが変わらなければ、ロードバランサは同じバックエンドを選択します。

  • 新しい適格なバックエンドが追加されると、約 1/N 個の新しい接続の候補が、新しく追加されたバックエンドにマッピングされます。この場合、N は、新しいバックエンドが追加された後の適格なバックエンドの数です。

  • 適格なバックエンドが削除されると、約 1/N 個の新しい接続の候補が、残りの N-1 個のバックエンドのいずれかにマッピングされます。この場合、N は、適格なバックエンドが削除される前のバックエンドの数です。

2.3 接続トラッキング テーブルのエントリを作成する。

バックエンドの選択後、ロードバランサは接続トラッキング テーブルのエントリを作成します。接続トラッキング テーブルのエントリにより、選択されたバックエンドにパケットの特性がマッピングされます。このマッピングに使用されるパケット ヘッダー フィールドは、接続トラッキング モードとセッション アフィニティの設定によって異なります。

ロードバランサは、次のルールに従って接続トラッキング テーブルのエントリを削除します。

• 接続トラッキング テーブルのエントリは、接続がアイドル状態になった後に削除されます。カスタムのアイドル タイムアウトが設定されていない限り、ロードバランサはデフォルトのアイドル タイムアウト（600 秒）を使用します。詳細については、アイドル タイムアウトをご覧ください。

• TCP 接続が FIN パケットまたは RST パケットで閉じられた場合、接続トラッキング テーブルのエントリは削除されません。新しい TCP 接続には常に SYN フラグが付けられ、いずれも接続トラッキング テーブルのエントリを確認するのステップで説明されているように処理されます。

• フェイルオーバー ポリシーが構成されていて、フェイルオーバーとフェイルバックでのコネクション ドレインの設定が無効になっている場合、フェイルオーバーまたはフェイルバック中にアクティブ プールが変更されると、ロードバランサは接続トラッキング テーブルのすべてのエントリを削除します。詳細については、フェイルオーバーとフェイルバックでのコネクション ドレインをご覧ください。

• バックエンドが異常な状態になった場合、接続トラッキング テーブルのエントリが削除されることがあります。この動作は、接続トラッキング モード、プロトコル、異常なバックエンドでの接続の永続性の設定によって異なります。詳細については、異常なバックエンドでの接続の永続性をご覧ください。

• 接続トラッキング テーブルのエントリは、バックエンド VM の削除やインスタンス グループまたは NEG からのバックエンド VM の削除などのイベント後に発生するコネクション ドレインのタイムアウト後に削除されます。詳細については、コネクション ドレインを有効にするをご覧ください。

セッション アフィニティ

セッション アフィニティは、クライアントからロードバランサのバックエンドへの新しい接続の分散を制御します。内部パススルー ネットワーク ロードバランサは、バックエンドの選択と接続トラッキングのセクションの適格なバックエンドを識別すると適格なバックエンドを選択するのステップで説明されているように、適格なバックエンドのセットからバックエンドを選択するためにセッション アフィニティを使用します。セッション アフィニティは、それぞれのバックエンドのインスタンス グループや NEG ではなく、バックエンド サービスで設定します。

内部パススルー ネットワーク ロードバランサでサポートされるセッション アフィニティの設定を次に示します。それぞれのセッション アフィニティの設定で、コンシステント ハッシュ法を使用して適格なバックエンドが選択されます。セッション アフィニティの設定により、ハッシュの計算に使用される IP ヘッダーとレイヤ 4 ヘッダーのフィールドが決まります。

バックエンド選択のハッシュ方法	セッション アフィニティの設定
ポート情報を含む断片化されていないパケット（TCP パケットや断片化されていない UDP パケットなど）の場合は 5 タプルハッシュ（送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成） または 断片化された UDP パケットや他のプロトコルのパケットの場合は 3 タプルハッシュ（送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成）	NONE^1
ポート情報を含む断片化されていないパケット（TCP パケットや断片化されていない UDP パケットなど）の場合は 5 タプルハッシュ（送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成） または 断片化された UDP パケットや他のプロトコルのパケットの場合は 3 タプルハッシュ（送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成）	CLIENT_IP_PORT_PROTO
3 タプルハッシュ （送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成）	CLIENT_IP_PROTO
2 タプルハッシュ （送信元 IP アドレスと宛先 IP アドレスで構成）	CLIENT_IP
1 タプルハッシュ （送信元 IP のみで構成）	CLIENT_IP_NO_DESTINATION^2

¹ セッション アフィニティの設定 NONE は、セッション アフィニティがないことを意味するわけではありません。これは、セッション アフィニティ オプションが明示的に設定されていないことを意味します。

ハッシュは、バックエンドを選択するために常に実行されます。セッション アフィニティの設定が NONE の場合、ロードバランサは 5 タプルハッシュまたは 3 タプルハッシュを使用してバックエンドを選択します。これは、CLIENT_IP_PORT_PROTO が設定されている場合と機能的に同じ動作になります。

² CLIENT_IP_NO_DESTINATION は、受信した各パケットの送信元 IP アドレスのみに基づく 1 タプルハッシュです。この設定は、パケットの宛先 IP アドレスに関係なく、パケットの送信元 IP アドレスのみに基づいて、クライアントからのすべてのパケットを同じバックエンド VM で処理する必要がある場合に便利です。このような状況は通常、内部パススルー ネットワーク ロードバランサが静的ルートのネクストホップである場合に発生します。 詳細については、セッション アフィニティとネクストホップの内部パススルー ネットワーク ロードバランサをご覧ください。

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

注: 内部 UDP ロードバランサの場合、セッション アフィニティの設定は、gcloud CLI と API でサポートされています。 Google Cloud コンソールを使用して UDP トラフィックにセッション アフィニティを設定することはできません。

セッション アフィニティとネクストホップの内部パススルー ネットワーク ロードバランサ

ネクストホップの内部パススルー ネットワーク ロードバランサを使用するように静的ルートを構成すると、ロードバランサはバックエンド選択と接続のトラッキングの同じ方法を使用します。バックエンドの選択は、構成されたセッション アフィニティに従ってハッシュを計算することで引き続き行われます。CLIENT_IP_NO_DESTINATION セッション アフィニティ（1 タプルハッシュ）を除き、バックエンド選択ハッシュは、パケットの宛先 IP アドレスに部分的に依存します。

内部パススルー ネットワーク ロードバランサが静的ルートのネクストホップの場合、宛先 IP アドレスはロードバランサの転送ルールの IP アドレスに限定されません。代わりに、パケットの宛先 IP アドレスは、静的ルートの宛先範囲内に収まる任意の IP アドレスにできます。

構成済みで正常なバックエンド VM の数が一定の場合（フェイルオーバーが構成されていない場合、またはフェイルオーバーが構成されていても、フェイルオーバー イベントまたはフェイルバック イベントが発生しない場合）、ロードバランサは次のように動作します。

• 構成済みで正常なバックエンド VM が 1 つだけある場合（フェイルオーバーが構成されている場合はアクティブ プール内）、すべてのハッシュが 1 つのバックエンド VM にマッピングされるため、使用するセッション アフィニティは重要ではありません。

• 構成済みで正常なバックエンド VM が 2 つ以上ある場合（フェイルオーバーが構成されている場合はアクティブ プール内）、セッション アフィニティの選択が重要になります。

  • パケットの宛先 IP アドレスに関係なく、パケットの送信元 IP アドレスのみに基づいて、クライアントからのすべてのパケットを同じバックエンド VM で処理する必要がある場合は、CLIENT_IP_NO_DESTINATION セッション アフィニティを使用します。トラフィック パターンによっては、一部のバックエンド VM が他のバックエンド VM よりも多くのパケットまたは接続を受信する場合があります。

  • CLIENT_IP_NO_DESTINATION 以外のセッション アフィニティ オプションを使用する場合、ロードバランサは、少なくともパケットの送信元 IP アドレスと宛先 IP アドレスの両方を含む情報に基づいてバックエンド VM を選択します。送信元 IP アドレスが同じでも宛先 IP アドレスが異なれば、同じクライアントから送信されたパケットが異なるバックエンド VM にルーティングされる場合があります。

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

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

• 接続トラッキング モード
• 異常なバックエンドでの接続の永続性
• アイドル タイムアウト

接続トラッキング モード

ロードバランサの接続トラッキング テーブルにより、接続タプルがハッシュ テーブル内の以前に選択されたバックエンドにマッピングされます。各接続タプルを構成するパケットの特性のセットは、接続トラッキング モードとセッション アフィニティによって決まります。

内部パススルー ネットワーク ロードバランサは、サポートされるすべてのプロトコルの接続をトラッキングします。

接続トラッキング モードは、ロードバランサの接続トラッキング テーブル内の各接続タプルの粒度を指します。接続タプルは 5 タプルまたは 3 タプルにできます（PER_CONNECTION モード）。また、セッション アフィニティの設定と一致させることもできます（PER_SESSION モード）。

• PER_CONNECTION。これはデフォルトの接続トラッキング モードです。この接続トラッキング モードでは、5 タプルハッシュまたは 3 タプルハッシュが使用されます。TCP パケットや断片化されていない UDP パケットなど、ポート情報を含む断片化されていないパケットは、5 タプルハッシュでトラッキングされます。他のすべてのパケットは 3 タプルハッシュでトラッキングされます。

• PER_SESSION。この接続トラッキング モードでは、セッション アフィニティのハッシュで使用されるのと同じパケットの特性で構成されるハッシュが使用されます。選択するセッション アフィニティによっては、PER_SESSION により、接続が接続トラッキング テーブルの既存のエントリと一致する頻度が増え、バックエンドをセッション アフィニティのハッシュで選択しなければならない頻度を減らすことができます。

次の表は、接続トラッキング モードとセッション アフィニティが連携して、各接続のすべてのパケットを同じバックエンドに転送する方法をまとめたものです。

セッション アフィニティを使用したバックエンドの選択		接続トラッキング モード
セッション アフィニティの設定	バックエンド選択のハッシュ方法	PER_CONNECTION（デフォルト）	PER_SESSION
NONE	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ
CLIENT_IP_NO_DESTINATION	すべてのプロトコル: 1 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	すべてのプロトコル: 1 タプルハッシュ
CLIENT_IP	すべてのプロトコル: 2 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	すべてのプロトコル: 2 タプルハッシュ
CLIENT_IP_PROTO	すべてのプロトコル: 3 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	すべてのプロトコル: 3 タプルハッシュ
CLIENT_IP_PORT_PROTO	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ	TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ

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

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

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

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

• DEFAULT_FOR_PROTOCOL（デフォルト）
• NEVER_PERSIST
• ALWAYS_PERSIST

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

異常なバックエンド オプションでの接続の永続性	接続トラッキング モード
	PER_CONNECTION	PER_SESSION
DEFAULT_FOR_PROTOCOL	TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） UDP: 異常なバックエンドで接続が持続することはありません	TCP: セッション アフィニティが NONE または CLIENT_IP_PORT_PROTO の場合に、異常なバックエンドで接続が維持されます UDP: 異常なバックエンドで接続が持続することはありません
NEVER_PERSIST	TCP、UDP: 異常なバックエンドで接続が持続することはありません
ALWAYS_PERSIST	TCP、UDP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） このオプションは、高度なユースケースにのみ使用してください。	構成が不可能

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

注: バックエンドが異常な状態になると、ロードバランサは、パケットのプロトコルと異常なバックエンドでの接続の永続性の選択されたオプションに従って、接続トラッキング テーブルの既存のエントリを削除します。エントリが削除された接続の後続のパケットは、新しい接続として扱われます。ロードバランサは、各接続に対して、適格なバックエンドを選択した後、接続トラッキング テーブルの置換エントリを作成します。接続トラッキング テーブルの置換エントリは、接続トラッキング テーブルの他のエントリと同じ条件で有効な状態を維持します。異常なバックエンドが正常な状態に戻っても、そのイベントだけでは接続トラッキング テーブルの置換エントリは削除されません。ただし、そのイベントによってフェイルバックがトリガーされ、フェイルオーバーとフェイルバックでのコネクション ドレインが無効になる場合は除きます。

アイドル タイムアウト

デフォルトでは、接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 600 秒後に失効します。このデフォルトのアイドル タイムアウト値は、接続トラッキングが 5 タプル未満の場合（つまり、セッション アフィニティが CLIENT_IP または CLIENT_IP_PROTO に構成されている場合）にのみ変更できます。トラッキング モードは PER_SESSION です）。

構成可能なアイドル タイムアウトの最大値は 57,600 秒（16 時間）です。

アイドル タイムアウト値を変更する方法については、接続トラッキング ポリシーの構成をご覧ください。

単一クライアントのデプロイの接続

クライアントが 1 つのみ存在する内部パススルー ネットワーク ロードバランサの IP アドレスへの接続をテストする場合は、次の点に注意してください。

• クライアント VM がロード バランシング対象外の VM、つまりバックエンド VM でない場合、新しい接続がロードバランサの正常なバックエンド VM に配信されます。ただし、すべてのセッション アフィニティのオプションが、少なくともクライアント システムの IP アドレスに依存するため、同じクライアントからの接続は、予測より頻繁に同じバックエンド VM に分散されることがあります。

  実地面では、単一クライアントから内部パススルー ネットワーク ロードバランサに接続した場合、これを介したトラフィック分散を正確にモニタリングできないことになります。トラフィック分散のモニタリングに必要なクライアント数は、ロードバランサの種類、トラフィックの種類、正常なバックエンドの数によって異なります。

• クライアント VM がロードバランサのバックエンド VM でもある場合、ロードバランサの転送ルールの IP アドレスに送信される接続には、常に同じバックエンド VM（クライアント VM でもある）が応答します。この現象は、バックエンド VM が正常であるかどうかにかかわらず、ロードバランサの内部転送ルールで指定されたプロトコルとポート上のトラフィックだけではなく、ロードバランサの IP アドレスに送信されたすべてのトラフィックで発生します。

  詳細については、ロードバランスされた VM からのリクエストを送信するをご覧ください。

コネクション ドレイン

コネクション ドレインを使用すると、次のいずれかのアクションが行われたときにロードバランサの接続トラッキング テーブルで確立済みの接続を維持する追加時間を構成できます。

• 仮想マシン（VM）インスタンスがバックエンド インスタンス グループから削除された（バックエンド マネージド インスタンス グループ内のインスタンスの放棄を含む）
• VM が停止または削除された（ローリング アップデートやバックエンド マネージド インスタンス グループのスケールダウンなどの自動アクションを含む）
• エンドポイントがバックエンド ネットワーク エンドポイント グループ（NEG）から削除された

デフォルトでは、前述のアクションのコネクション ドレインは無効になっています。コネクション ドレインのトリガーとコネクション ドレインを有効にする方法については、コネクション ドレインを有効にするをご覧ください。

UDP の断片化

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

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

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

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

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

フェイルオーバー

内部パススルー ネットワーク ロードバランサを使用すると、一部のバックエンドをフェイルオーバー バックエンドとして指定できます。これらのバックエンドは、プライマリ バックエンド インスタンス グループの正常な VM の数が、構成可能なしきい値を下回る場合にのみ使用されます。デフォルトでは、すべてのプライマリ VM とフェイルオーバー VM が異常な状態になると、最後の手段として、Google Cloud はすべてのプライマリ VM 間でのみ新しい接続トラフィックを分散します。

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

バックエンドの選択と接続トラッキングにフェイルオーバーがどのように使用されるかについては、バックエンドの選択と接続トラッキングのセクションの適格なバックエンドを識別すると接続トラッキング テーブルのエントリを作成するのステップをご覧ください。

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

次のステップ

• フェイルオーバーを使用する内部パススルー ネットワーク ロードバランサを構成してテストする。内部パススルー ネットワーク ロードバランサにフェイルオーバーを構成するをご覧ください。
• 内部パススルー ネットワーク ロードバランサを構成してテストする。内部パススルー ネットワーク ロードバランサを設定するをご覧ください。