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

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

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

バックエンドの選択と接続トラッキングは、複数の接続を異なるバックエンド間で分散し、各接続のすべてのパケットを同じバックエンドに転送するように連携して機能します。これは、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 つのバックエンドが正常な場合、適格なバックエンドは、この順序付きリストで最初に true になる条件を使用して、次のように定義されます。

    • 正常なプライマリ バックエンドがない場合、適格なバックエンドはすべての正常なフェイルオーバー バックエンドです。
    • 正常なフェイルオーバー バックエンドがない場合、適格なバックエンドはすべての正常なプライマリ バックエンドです。
    • フェイルオーバー比率が 0.0（デフォルト値）に設定されている場合、適格なバックエンドは正常なすべてのプライマリ バックエンドです。
    • プライマリ バックエンドの総数に対する正常なプライマリ バックエンドの数の比率が、構成されたフェイルオーバー率以上の場合、適格なバックエンドはすべての正常なプライマリ バックエンドです。
    • 適格なバックエンドは、すべての正常なフェイルオーバー バックエンドです。

  • 正常なバックエンドがない場合、適格なバックエンドは次のように定義されます。

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

2.2 ゾーン アフィニティの適格なバックエンドを調整する

次のいずれかに該当する場合、この手順はスキップされます。

ゾーン アフィニティが有効になっていて、クライアントがゾーン アフィニティと互換性があり、ゾーンの一致が発生した場合、クライアントからの新しい接続は、調整された一連の適格なバックエンドに転送されます。詳しくは以下をご覧ください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

セッション アフィニティ

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

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

バックエンド選択のハッシュ方法 セッション アフィニティの設定

ポート情報を含む断片化されていないパケット（TCP パケットや断片化されていない UDP パケットなど）の場合は 5 タプルハッシュ（送信元 IP アドレス、送信元ポート、プロトコル、宛先 IP アドレス、宛先ポートで構成）

または

断片化された UDP パケットや他のプロトコルのパケットの場合は 3 タプルハッシュ（送信元 IP アドレス、宛先 IP アドレス、プロトコルで構成）

 NONE1

ポート情報を含む断片化されていないパケット（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_DESTINATION2

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

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

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

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

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

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

適格なバックエンドの選択は、パケットの特性のハッシュの計算によって異なります。CLIENT_IP_NO_DESTINATION セッション アフィニティ（1 タプルハッシュ）を除き、ハッシュはパケットの宛先 IP アドレスに部分的に依存します。

セッション アフィニティで定義されているパケットの特性が同じすべての新しい接続の候補に対して、適格なバックエンドのセットが変わらなければ、ロードバランサは同じバックエンドを選択します。宛先 IP アドレスに関係なく、送信元 IP アドレスのみに基づいて、クライアントからのすべてのパケットを同じバックエンド VM で処理する必要がある場合は、CLIENT_IP_NO_DESTINATION セッション アフィニティを使用します。

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

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

接続トラッキング モード

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

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

接続トラッキング モードは、ロードバランサの接続トラッキング テーブル内の各接続タプルの粒度を指します。接続タプルは 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 秒（10 分）を使用します。

次の表に、セッション アフィニティ設定と接続トラッキング モード設定のさまざまな組み合わせで構成可能なアイドル タイムアウトの最小値と最大値を示します。

セッション アフィニティ 接続トラッキング モード デフォルトのアイドル タイムアウト 構成可能な最小のアイドル タイムアウト 構成可能な最大のアイドル タイムアウト
任意の接続タプル PER_CONNECTION 600 秒 60 秒 600 秒
  • 1 タプル（CLIENT_IP_NO_DESTINATION）
  • 2 タプル（CLIENT_IP）
  • 3 タプル（CLIENT_IP_PROTO）
 PER_SESSION 600 秒 60 秒 57,600 秒
5 タプル（NONE、CLIENT_IP_PORT_PROTO） PER_SESSION 600 秒 60 秒 600 秒

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

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

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

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

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

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

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

コネクション ドレイン

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

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

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

UDP の断片化

内部パススルー ネットワーク ロードバランサは、断片化された UDP パケットと断片化されていない UDP パケットの両方を処理できます。断片化された UDP パケットをアプリケーションで使用する場合は、次の点に留意してください。
  • UDP パケットは、 Cloud de ConfianceVPC ネットワークに到達する前に断片化される場合があります。
  • Cloud de Confiance VPC ネットワークでは、到達した UDP フラグメントが（すべてのフラグメントの到達を待たずに）転送されます。
  • Cloud de Confiance 以外のネットワークとオンプレミス ネットワーク機器では、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 が異常な状態になると、最後の手段として、Cloud de Confiance はすべてのプライマリ VM 間でのみ新しい接続トラフィックを分散します。

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

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

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

次のステップ