このページでは、外部パススルー ネットワーク ロードバランサがトラフィックを分散する方法に関するコンセプトについて説明します。
バックエンドの選択と接続トラッキング
バックエンドの選択と接続トラッキングは、複数の接続を異なるバックエンド間で分散し、各接続のすべてのパケットを同じバックエンドに転送するように連携して機能します。これは、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 つのバックエンドが正常な場合、適格なバックエンドのセットは、この順序付きリストで最初に満たした条件に従って次のように定義されます。
- 正常なプライマリ バックエンドがない場合、適格なバックエンドはすべての正常なフェイルオーバー バックエンドです。
- 正常なフェイルオーバー バックエンドがない場合、適格なバックエンドはすべての正常なプライマリ バックエンドです。
- フェイルオーバー率が
0.0（デフォルト値）に設定されている場合、適格なバックエンドは正常なすべてのプライマリ バックエンドです。 - プライマリ バックエンドの総数に対する正常なプライマリ バックエンドの数の比率が、構成されたフェイルオーバー率以上の場合、適格なバックエンドはすべての正常なプライマリ バックエンドです。
- 適格なバックエンドは、すべての正常なフェイルオーバー バックエンドで構成されます。
正常なバックエンドがない場合、適格なバックエンドのセットは次のように定義されます。
- 正常なバックエンドがないと新しい接続をドロップするようにロードバランサのフェイルオーバー ポリシーが構成されている場合、適格なバックエンドのセットは空になります。新しい接続のパケットはロードバランサでドロップされます。
- 正常なバックエンドがないと新しい接続をドロップするようにロードバランサのフェイルオーバー ポリシーが構成されていない場合、ヘルスチェックは考慮されません。すべてのプライマリ バックエンドで適格なバックエンドが構成されます。
フェイルオーバー ポリシーが構成され、重み付きロード バランシングが有効
適格なバックエンドのセットは、ヘルスチェック、重み、フェイルオーバー ポリシーの構成によって決まります。
少なくとも 1 つのバックエンドが正常で、重みがゼロ以外の場合、適格なバックエンドのセットは、この順序付きリストで最初に満たした条件に従って次のように定義されます。
- 正常で重みがゼロ以外のプライマリ バックエンドがない場合、適格なバックエンドは、正常で重みがゼロ以外のすべてのフェイルオーバー バックエンドです。
- 正常で重みがゼロ以外のフェイルオーバー バックエンドがない場合、適格なバックエンドは、正常で重みがゼロ以外のすべてのプライマリ バックエンドです。
- フェイルオーバー率が
0.0（デフォルト値）に設定されている場合、適格なバックエンドは、重みがゼロ以外の正常なすべてのプライマリ バックエンドです。 - プライマリ バックエンドの総数に対する正常で重みがゼロ以外のプライマリ バックエンドの数の比率が、構成済みのフェイルオーバー率以上の場合、適格なバックエンドは、正常で重みがゼロ以外のすべてのプライマリ バックエンドで構成されます。
- 適格なバックエンドは、重みがゼロ以外の正常なすべてのフェイルオーバー バックエンドで構成されます。
正常なバックエンドで重みが 0 以外のバックエンドがない場合、適格なバックエンドのセットは次のように定義されます。
- 正常なバックエンドがないと新しい接続をドロップするようにロードバランサのフェイルオーバー ポリシーが構成されている場合、適格なバックエンドのセットは空になります。新しい接続のパケットはロードバランサでドロップされます。
バックエンドが正常でない場合に新しい接続をドロップするようにロードバランサのフェイルオーバー ポリシーが構成されていない場合、適格なバックエンドのセットは、次の中で空でない最初のセットになります。
- 異常で重みがゼロ以外のすべてのプライマリ バックエンド
- 異常で重みがゼロ以外のすべてのフェイルオーバー バックエンド
- 正常で重みがゼロのすべてのプライマリ バックエンド
- 正常で重みがゼロのすべてのフェイルオーバー バックエンド
- 異常で重みがゼロのすべてのプライマリ バックエンド
- 異常で重みがゼロのすべてのフェイルオーバー バックエンド
2.2 適格なバックエンドを選択する
ロードバランサは、コンシステント ハッシュ法を使用して適格なバックエンドを選択します。ロードバランサは、単位円にマッピングされた適格なバックエンドのハッシュを保持します。重み付きロード バランシングでは、重みの大きいバックエンドが重みに比例して選択される可能性が高くなるように、適格なバックエンドが円にマッピングされる方法が変更されます。
接続トラッキング テーブルにない接続のパケットを処理する場合、ロードバランサはパケットの特性のハッシュを計算し、そのハッシュを同じ単位円にマッピングして、円の円周上の適格なバックエンドを選択します。パケットのハッシュの計算に使用されるパケットの特性のセットは、セッション アフィニティの設定で定義されます。
セッション アフィニティが明示的に構成されていない場合、
NONEセッション アフィニティがデフォルトになります。次の 2 つの例は、適格なバックエンドの選択に重み付きロード バランシングがどのように影響するかを示しています。
バックエンド サービスに 2 つの適格なバックエンド（1 つ目のバックエンドの重みが
1で、2 つ目は4）がある場合、1 つ目の適格なバックエンドが選択される確率は 20%（1÷(1+4)）で、2 つ目の適格なバックエンドが選択される確率は 80%（4÷(1+4)）になります。バックエンド サービスに 3 つの適格なバックエンド（重みが
0のa、重みが2のb、重みが6のc）がある場合、バックエンドaが選択される確率は 0%（0÷(0+2+6)）、バックエンドbが選択される確率は 25%（2÷(0+2+6)）、バックエンドcが選択される確率は 75%（6÷(0+2+6)）になります。
ロードバランサは、適格なバックエンドの数や重みが変化しても、可能な限り一貫した方法で新しい接続を適格なバックエンドに割り当てます。コンシステント ハッシュ法には次のような利点があります。これは、接続トラッキング テーブルのエントリがない新しい接続の候補に対して、ロードバランサが適格なバックエンドをどのように選択するかを示しています。
ロードバランサは、セッション アフィニティで定義されているパケットの特性が同じすべての新しい接続の候補に対して、次の状況で同じバックエンドを選択します。
重み付きロード バランシングが構成されず、適格なバックエンドのセットが変更されない場合。
重み付きロード バランシングが構成され、適格なバックエンドのセットが変更されず、適格なバックエンドの重みに変化がない場合。
ロードバランサは、可能な限り公平に、適格なバックエンド間で新しい接続を分散します。
重み付けロード バランシングが構成されていない場合、約
1/N個の新しい接続の候補が適格なバックエンドにマッピングされます。ここで、Nは適格なバックエンドの数です。重み付きロード バランシングが構成されている場合、適格なバックエンドにマッピングされる新しい接続の候補の比率は、適格なバックエンドの重みをすべての適格なバックエンドの重みの合計で割った値にほぼ等しくなります。
適格なバックエンドが追加または削除された場合、あるいは重みが変更された場合、コンシステント ハッシュ法により、他の適格なバックエンドへのマッピングの中断が最小限に抑えられます。つまり、他の適格なバックエンドにマッピングされるほとんどの接続は、同じ適格なバックエンドにマッピングされ続けます。
2.3 接続トラッキング テーブルのエントリを作成する
バックエンドを選択した後、構成されたセッション アフィニティでパケットのプロトコルの接続トラッキングがサポートされている場合、ロードバランサは接続トラッキング テーブルにエントリを作成します。
構成されたセッション アフィニティでパケットのプロトコルの接続トラッキングがサポートされていない場合は、この手順をスキップします。
構成されたセッション アフィニティでパケットのプロトコルの接続トラッキングがサポートされている場合、接続トラッキング テーブルに作成されたエントリにより、パケットの特性と選択されたバックエンドがマッピングされます。このマッピングに使用されるパケット ヘッダー フィールドは、接続トラッキング モードとセッション アフィニティの構成によって異なります。
構成の選択に基づいて接続をトラッキングできるプロトコルと、ハッシュに使用されるパケット特性については、接続トラッキング モードのセクションをご覧ください。
ロードバランサは、次のルールに従って接続トラッキング テーブルのエントリを削除します。
接続トラッキング テーブルのエントリは、接続が 60 秒間アイドル状態になった後に削除されます。詳細については、アイドル タイムアウトをご覧ください。
TCP 接続が
FINパケットまたはRSTパケットで閉じられた場合、接続トラッキング テーブルのエントリは削除されません。新しい TCP 接続には常にSYNフラグが付けられ、いずれも接続トラッキング テーブルのエントリを確認するのステップで説明されているように処理されます。フェイルオーバー ポリシーが構成されていて、フェイルオーバーとフェイルバックでのコネクション ドレインの設定が無効になっている場合、適格なバックエンドがプライマリ バックエンドからフェイルオーバー バックエンドに切り替わる（フェイルオーバー）か、フェイルオーバー バックエンドからプライマリ バックエンドに切り替わる（フェイルバック）と、ロードバランサは接続トラッキング テーブルのすべてのエントリを削除します。詳細については、フェイルオーバーとフェイルバックでのコネクション ドレインをご覧ください。
バックエンドが異常な状態になった場合、接続トラッキング テーブルのエントリが削除されることがあります。この動作は、接続トラッキング モード、プロトコル、異常なバックエンドでの接続の永続性の設定によって異なります。詳細については、異常なバックエンドでの接続の永続性をご覧ください。
接続トラッキング テーブルのエントリは、バックエンド VM の削除やインスタンス グループまたは NEG からのバックエンド VM の削除などのイベント後に発生するコネクション ドレインのタイムアウト後に削除されます。詳細については、コネクション ドレインを有効にするをご覧ください。
セッション アフィニティ
セッション アフィニティは、クライアントからロードバランサのバックエンドへの新しい接続の分散を制御します。外部パススルー ネットワーク ロードバランサは、バックエンドの選択と接続トラッキングのセクションの適格なバックエンドを識別すると適格なバックエンドを選択するのステップで説明されているように、適格なバックエンドのセットからバックエンドを選択するためにセッション アフィニティを使用します。セッション アフィニティは、それぞれのバックエンドのインスタンス グループや NEG ではなく、バックエンド サービスで構成します。
外部パススルー ネットワーク ロードバランサでサポートされるセッション アフィニティの設定を次に示します。それぞれのセッション アフィニティの設定で、コンシステント ハッシュ法を使用して適格なバックエンドが選択されます。セッション アフィニティの設定により、ハッシュの計算に使用される IP ヘッダーと TCP / UDP ヘッダーのフィールドが決まります。
| バックエンド選択のハッシュ方法 | セッション アフィニティの設定1 |
|---|---|
|
ポート情報を含む断片化されていないパケット（TCP パケットや断片化されていない UDP パケットなど）の場合は 5 タプルハッシュ（送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成） または断片化された UDP パケットや他のプロトコルのパケットの場合は 3 タプルハッシュ（送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成） |
NONE2 |
|
ポート情報を含む断片化されていないパケット（TCP パケットや断片化されていない UDP パケットなど）の場合は 5 タプルハッシュ（送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成） または断片化された UDP パケットや他のプロトコルのパケットの場合は 3 タプルハッシュ（送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成） |
CLIENT_IP_PORT_PROTO |
| 3 タプルハッシュ （送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成） |
CLIENT_IP_PROTO |
| 2 タプルハッシュ （送信元 IP アドレスと宛先 IP アドレスで構成） |
CLIENT_IP |
session affinity パラメータを設定します。2 セッション アフィニティの設定 NONE は、セッション アフィニティがないことを意味するわけではありません。これは、セッション アフィニティ オプションが明示的に構成されていないことを意味します。
ハッシュは、バックエンドを選択するために常に実行されます。セッション アフィニティの設定が NONE の場合、ロードバランサは 5 タプルハッシュまたは 3 タプルハッシュを使用してバックエンドを選択します。これは、CLIENT_IP_PORT_PROTO が設定されている場合と機能的に同じ動作になります。
さまざまなセッション アフィニティの設定がバックエンドの選択と接続トラッキングの方法に与える影響については、接続トラッキング モードのセクションにある表をご覧ください。
接続トラッキング ポリシー
このセクションでは、外部パススルー ネットワーク ロードバランサの接続トラッキング動作を制御する設定について説明します。接続トラッキング ポリシーには次の設定が含まれます。
接続トラッキング モード
接続トラッキングが可能な場合、ロードバランサの接続トラッキング テーブルにより、接続タプルがハッシュ テーブル内の以前に選択されたバックエンドにマッピングされます。接続タプルを構成するパケットの特性のセットは、接続トラッキング モードとセッション アフィニティによって異なります。
外部パススルー ネットワーク ロードバランサは、プロトコルとセッション アフィニティ オプションに基づく接続トラッキングをサポートしています。
TCP 接続は、すべてのセッション アフィニティ オプションで常に接続を追跡できます。
UDP、ESP、GRE 接続は、
NONE以外のすべてのセッション アフィニティ オプションで接続を追跡できます。ICMP や ICMPv6 などの他のプロトコルは、接続をトラッキングできません。
接続トラッキング モードは、ロードバランサの接続トラッキング テーブル内の各接続タプルの粒度を指します。接続タプルは 5 タプルまたは 3 タプルにできます（PER_CONNECTION モード）。また、セッション アフィニティの設定と一致させることもできます（PER_SESSION モード）。
PER_CONNECTION。これはデフォルトの接続トラッキング モードです。この接続トラッキング モードでは、5 タプルハッシュまたは 3 タプルハッシュが使用されます。TCP パケットや断片化されていない UDP パケットなど、ポート情報を含む断片化されていないパケットは、5 タプルハッシュでトラッキングされます。他のすべてのパケットは 3 タプルハッシュでトラッキングされます。PER_SESSION。この接続トラッキング モードでは、セッション アフィニティのハッシュで使用されるのと同じパケットの特性で構成されるハッシュが使用されます。選択するセッション アフィニティによっては、PER_SESSIONにより、接続が接続トラッキング テーブルの既存のエントリと一致する頻度が増え、バックエンドをセッション アフィニティのハッシュで選択しなければならない頻度を減らすことができます。
次の表は、接続トラッキング モードとセッション アフィニティが連携して、各接続のすべてのパケットを同じバックエンドに転送する方法をまとめたものです。
| セッション アフィニティを使用したバックエンドの選択 | 接続トラッキング モード | ||
|---|---|---|---|
| セッション アフィニティの設定 | バックエンド選択のハッシュ方法 | PER_CONNECTION（デフォルト） |
PER_SESSION |
| デフォルト （ |
TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ |
|
|
| クライアント IP、宛先 IP （ |
すべてのプロトコル: 2 タプルハッシュ |
|
|
| クライアント IP、宛先 IP、プロトコル （ |
すべてのプロトコル: 3 タプルハッシュ |
|
|
| クライアント IP、クライアント ポート、宛先 IP、宛先ポート、プロトコル （ |
TCP と断片化されていない UDP: 5 タプルハッシュ 断片化された UDP と他のすべてのプロトコル: 3 タプルハッシュ |
|
|
接続トラッキング モードを変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。
異常なバックエンドでの接続の永続性
バックエンドが異常な状態になった後も、選択した VM またはバックエンドで既存の接続を維持するかどうかは、バックエンドがロードバランサの構成済みバックエンド インスタンス グループ（インスタンス グループまたは NEG）に残っている限り、接続の永続性の設定で制御します。
使用できる接続の永続性に関するオプションは次のとおりです。
DEFAULT_FOR_PROTOCOL（デフォルト）NEVER_PERSISTALWAYS_PERSIST
次の表には、接続の永続性に関するオプションと、さまざまなプロトコル、セッション アフィニティのオプション、トラッキング モードに対して接続を維持する方法をまとめています。
| 異常なバックエンド オプションでの接続の永続性 | 接続トラッキング モード | |
|---|---|---|
PER_CONNECTION |
PER_SESSION |
|
DEFAULT_FOR_PROTOCOL |
TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） 他のすべてのプロトコル: 異常なバックエンドで接続が維持されることはありません |
TCP: セッション アフィニティが 他のすべてのプロトコル: 異常なバックエンドで接続が維持されることはありません |
NEVER_PERSIST |
すべてのプロトコル: 異常なバックエンドで接続が維持されることはありません | |
ALWAYS_PERSIST |
TCP: 異常なバックエンドで接続が維持されます（すべてのセッション アフィニティ） ESP、GRE、UDP: セッション アフィニティが ICMP、ICMPv6: 接続トラッキングできないため、対象外です。 このオプションは、高度なユースケースにのみ使用してください。 |
構成が不可能 |
異常なバックエンドでの TCP 接続の永続性の動作
正常でないバックエンドで 5 タプル トラッキングの TCP 接続が維持される場合は常時:
- 異常なバックエンドがパケットに引き続き応答する場合、接続がリセットされるか、（異常なバックエンドまたはクライアントによって）クローズされるまで、接続は維持されます。
- 正常でないバックエンドが TCP リセット（RST）パケットを送信するか、パケットに応答しない場合、クライアントは新しい接続で再試行するため、ロードバランサは別の正常なバックエンドを選択できます。TCP SYN パケットは常に新しい正常なバックエンドを選択します。
接続の永続性の動作を変更する方法については、接続トラッキング ポリシーを構成するをご覧ください。
アイドル タイムアウト
接続トラッキング テーブル内のエントリは、ロードバランサがエントリに一致した最後のパケットを処理してから 60 秒後に失効します。このアイドル タイムアウト値は変更できません。
重み付きロード バランシング
外部パススルー ネットワーク ロードバランサの重み付きロード バランシングでは、HTTP ヘルスチェックによって報告された重み情報が使用されます。重み付きロード バランシングでは、次のすべてを構成する必要があります。
- バックエンド サービスのロードバランサ局所性ポリシー（
localityLbPolicy）はWEIGHTED_MAGLEVである必要があります。 - バックエンド サービスでは、HTTP ヘルスチェックを使用する必要があります。
- 各バックエンド VM またはバックエンド エンドポイントからのヘルスチェック レスポンスには、カスタム HTTP レスポンス ヘッダーが含まれている必要があります。レスポンス ヘッダー フィールド名は
X-Load-Balancing-Endpoint-Weightで、有効なフィールド値の範囲は0～1000までです。
同じインスタンス グループまたは NEG を 2 つ以上のバックエンド サービスのバックエンドとして使用する必要がある場合は、共通のバックエンド インスタンスまたはエンドポイントが各バックエンド サービスに一意の重み情報を提供できるように、次の戦略をおすすめします。
- バックエンド サービスごとに一意の HTTP ヘルスチェックを使用します。たとえば、一意の
request-pathヘルスチェック パラメータを使用します。 - 各ヘルスチェックに対して適切な重み情報で応答するようにバックエンド インスタンスまたはエンドポイントを構成します。
重み付きロード バランシングを使用する場合、ロードバランサは、バックエンド VM またはエンドポイントをまず重みがゼロより大きいか、ゼロに等しいかでランク付けし、さらにヘルスチェックに基づいてランク付けします。ヘルスチェックのステータスは、HTTP、HTTPS、HTTP/2 ヘルスチェックの成功基準によって決まります。
| 重み | 正常か異常か | ランク |
|---|---|---|
| 重みが 0 より大きい | 正常 | 第 1 候補 |
| 重みが 0 より大きい | 異常 | 第 2 候補 |
| 重みが 0 に等しい | 正常 | 第 3 候補 |
| 重みが 0 に等しい | 異常 | 第 4 候補（最後） |
重み付きロード バランシングが適格なバックエンドにどのように影響するのかについては、バックエンドの選択と接続トラッキングのセクションの適格なバックエンドを識別すると適格なバックエンドを選択するのステップをご覧ください。
重み付きロード バランシングは、次のシナリオで使用できます。
一部の接続が他の接続よりも多くのデータを処理する場合や、一部の接続が他の接続よりも長く存続する場合、バックエンドのロード バランシングが不均等になる可能性があります。インスタンスごとの重みが低いことを通知することで、既存の接続の処理を継続しながら、負荷の高いインスタンスで新しい接続のシェアを下げることができます。
バックエンドが過負荷状態のときに、より多くの接続を割り当てると、既存の接続が切断される可能性があります。このようなバックエンドには重み 0 を割り当てます。重み 0 を通知することで、バックエンド インスタンスは新しい接続の処理を停止しますが、既存の接続の処理は継続します。
メンテナンスの前にバックエンドで既存の接続がドレインされると、バックエンドには重み 0 が割り当てられます。重み 0 を通知することで、バックエンド インスタンスは新しい接続の処理を停止しますが、既存の接続の処理は継続します。
詳細については、重み付きロード バランシングを構成するをご覧ください。
コネクション ドレイン
コネクション ドレインを使用すると、次のいずれかのアクションが行われたときにロードバランサの接続トラッキング テーブルで確立済みの接続を維持する追加時間を構成できます。
- 仮想マシン（VM）インスタンスがバックエンド インスタンス グループから削除された（バックエンド マネージド インスタンス グループ内のインスタンスの放棄を含む）
- VM が停止または削除された（ローリング アップデートやバックエンド マネージド インスタンス グループのスケールダウンなどの自動アクションを含む）
- エンドポイントがバックエンド ネットワーク エンドポイント グループ（NEG）から削除された
デフォルトでは、前述のアクションのコネクション ドレインは無効になっています。コネクション ドレインのトリガーとコネクション ドレインを有効にする方法については、コネクション ドレインを有効にするをご覧ください。
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 を使用してallPortsをTrueに設定します。バックエンド サービスの構成: バックエンド サービスのセッション アフィニティを
CLIENT_IP（2 タプルハッシュ）またはCLIENT_IP_PROTO（3 タプルハッシュ）に設定し、ポート情報を含む UDP パケットとポート情報がない UDP フラグメント（最初のフラグメント以外）に同じポートが選択されるようにします。バックエンド サービスの接続トラッキング モードをPER_SESSIONに設定して、接続トラッキング テーブルのエントリが同じ 2 タプルハッシュまたは 3 タプルハッシュを使用して作成されるようにします。
フェイルオーバー
プライマリ バックエンド（インスタンス グループまたは NEG）の VM インスタンスまたはエンドポイント間で接続を分散し、必要に応じてフェイルオーバー バックエンドを使用するように、外部パススルー ネットワーク ロードバランサを構成できます。フェイルオーバーにより可用性を向上させるだけでなく、プライマリ バックエンドが正常に動作していない場合にワークロードをより効率的に管理できます。
デフォルトでは、外部パススルー ネットワーク ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドはプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。
バックエンドの選択と接続トラッキングにフェイルオーバーがどのように使用されるかについては、バックエンドの選択と接続トラッキングのセクションの適格なバックエンドを識別すると接続トラッキング テーブルのエントリを作成するのステップをご覧ください。
フェイルオーバーの仕組みの詳細については、外部パススルー ネットワーク ロードバランサのフェイルオーバーの概要をご覧ください。
次のステップ
- TCP または UDP トラフィックのみを対象とするバックエンド サービスを使用して外部パススルー ネットワーク ロードバランサを構成する（IPv4 および IPv6 トラフィックをサポート）。バックエンド サービスを使用して外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- 複数の IP プロトコルに外部パススルー ネットワーク ロードバランサを構成する（IPv4 と IPv6 のトラフィックをサポート）。複数の IP プロトコルへの外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- ゾーン NEG バックエンドを使用して外部パススルー ネットワーク ロードバランサを構成する。ゾーン NEG を使用して外部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- 外部パススルー ネットワーク ロードバランサをターゲット プール バックエンドからリージョン バックエンド サービスに移行する。外部パススルー ネットワーク ロードバランサをターゲット プールからバックエンド サービスに移行するをご覧ください。