内部 TCP / UDP 負荷分散のフェイルオーバーのコンセプト

内部 TCP / UDP ロードバランサを構成して、プライマリ バックエンドの仮想マシン(VM)インスタンス間で接続を分散し、必要に応じてフェイルオーバー バックエンドを使用するように変更できます。フェイルオーバーは、可用性を向上させる 1 つの方法を提供し、メインのバックエンド VM が正常でない場合にワークロードを管理する方法も強化します。

このページでは、内部 TCP / UDP ロードバランサのフェイルオーバーに固有のコンセプトと要件について説明します。内部 TCP / UDP 負荷分散のフェイルオーバーを構成する前に、次のドキュメントのコンセプトを理解しておいてください。

フェイルオーバーを構成すると、内部 TCP / UDP ロードバランサの標準のトラフィック分散アルゴリズムが変更されるため、これらのコンセプトを理解しておく必要があります。

概要

デフォルトでは、内部 TCP / UDP ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドはプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。フェイルオーバー バックエンドは、構成可能なプライマリ仮想マシンの割合がヘルスチェックの基準を満たさなかったときにのみ、ロードバランサからの接続を受信します。

サポートされているインスタンス グループ

マネージド インスタンス グループと非マネージド インスタンス グループはバックエンドとしてサポートされます。このページでは、非マネージド インスタンス グループの例について説明します。

自動スケーリングとフェイルオーバーでマネージド インスタンス グループを使用すると、アクティブ プールがプライマリ バックエンドとフェイルオーバー バックエンドの間でフェイルオーバーとフェイルバックを繰り返す可能性があります。GCP では、マネージド インスタンス グループでフェイルオーバーを設定することは可能です。ユーザーのデプロイメントがこの設定から恩恵を受けている可能性があるからです。

アーキテクチャ

次の例は、1 つのプライマリ バックエンドと 1 つのフェイルオーバー バックエンドが存在する内部 TCP / UDP ロードバランサを示しています。プライマリ バックエンドは us-west1-a の非マネージド インスタンス グループで、フェイルオーバー バックエンドは us-west1-c の別の非マネージド インスタンス グループです。

内部 TCP / UDP 負荷分散の簡単なフェイルオーバーの例(クリックして拡大)
内部 TCP / UDP 負荷分散の簡単なフェイルオーバーの例(クリックして拡大)

次の例は、2 つのプライマリ バックエンドと 2 つのフェイルオーバー バックエンドが存在する内部 TCP / UDP ロードバランサで、us-west1 リージョンの 2 つのゾーンに分散しています。この構成では、どのプライマリ バックエンドもフェイルオーバー バックエンドも 1 つのゾーンに依存しないため、信頼性が向上します。

  • プライマリ バックエンドは、非マネージド インスタンス グループの ig-aig-d です。
  • フェイルオーバー バックエンドは、非マネージド インスタンス グループの ig-big-c です。
マルチゾーンの内部 TCP / UDP 負荷分散フェイルオーバー(クリックして拡大)
マルチゾーンの内部 TCP / UDP 負荷分散フェイルオーバー(クリックして拡大)

フェイルオーバーが発生すると、両方のプライマリ バックエンドが非アクティブになり、両方のフェイルバック バックエンドの正常な VM がアクティブになります。この例のフェイルオーバーの詳しい説明については、フェイルオーバーの例をご覧ください。

バックエンド インスタンス グループと VM について

内部 TCP / UDP 負荷分散の非マネージド インスタンス グループは、プライマリ バックエンドまたはフェイルオーバー バックエンドです。バックエンドは、バックエンド サービスに追加するときにフェイルオーバー バックエンドに指定できます。また、追加した後にバックエンドを編集して指定することもできます。それ以外の場合、非マネージド インスタンス グループはデフォルトでプライマリに設定されます。

1 つの内部 TCP / UDP ロードバランサで複数のプライマリ バックエンドと複数のフェイルオーバー バックエンドを設定するには、これらのバックエンドをロードバランサのバックエンド サービスに追加します。

プライマリ VM は、プライマリ バックエンドとして定義したインスタンス グループのメンバーです。ロードバランサがフェイルオーバー バックエンドを使用しない限り、メインのバックエンドの VM はロードバランサのアクティブ プールに参加します。

バックアップ VM は、フェイルオーバー バックエンドとして定義したインスタンス グループのメンバーです。プライマリ VM が不安定になると、フェイルオーバー バックエンドの VM がロードバランサのアクティブ プールに参加します。

上限

  • VM - アクティブ プールには最大 250 台の VM を設定できます。つまり、プライマリ バックエンド インスタンス グループは最大 250 台のプライマリ VM を設定できます。また、フェイルオーバー バックエンド インスタンス グループには 250 台までのバックアップ VM を設定可能です。

  • 非マネージド インスタンス グループ - 最大 50 個のプライマリ バックエンド インスタンス グループと最大 50 個のフェイルオーバー バックエンド インスタンス グループを設定できます。

たとえば、最大限のデプロイを行った場合、5 つのプライマリ バックエンドと 5 つのフェイルオーバー バックエンドを設定し、それぞれのインスタンス グループに 50 台の VM を追加できます。

アクティブ プール

アクティブ プールは、内部 TCP / UDP ロードバランサが新しい接続を送信するバックエンド VM のコレクションです。アクティブ プールのバックエンド VM のメンバーシップはバックエンドの健全性と条件に基づいて自動的に計算されます。フェイルオーバー率で説明するように、これらの条件や健全性は必要に応じて変更可能です。

アクティブ プール内では、プライマリ VM とバックアップ VM が混在することはありません。次の図に、メンバーシップの例を示します。フェイルオーバーでは、アクティブ プールにはバックアップ VM のみが存在します。通常のオペレーション(フェイルバック)では、アクティブ プールにはプライマリ VM のみが存在します。

フェイルオーバーとフェイルバックでのアクティブ プール(クリックして拡大)
フェイルオーバーとフェイルバックでのアクティブ プール(クリックして拡大)

フェイルオーバーとフェイルバック

フェイルオーバーとフェイルバックは、バックエンド VM をロードバランサのアクティブ プールに切り替える自動プロセスです。GCP がアクティブ プールからプライマリ VM を削除し、正常なフェイルオーバー VM をアクティブ プールに追加した場合、このプロセスはフェイルオーバーといいます。GCP がこの逆の処理を行った場合、このプロセスをフェイルバックといいます。

フェイルオーバー ポリシー

フェイルオーバー ポリシーは、GCP がフェイルオーバーとフェイルバックに使用するパラメータのコレクションです。1 つの内部 TCP / UDP ロードバランサには 1 つのフェイルオーバー ポリシーがあります。フェイルオーバー ポリシーでは、次のような項目を定義します。

  • フェイルオーバー率
  • すべてのバックエンド VM が正常でない場合のトラフィックの廃棄
  • フェイルオーバーとフェイルバックでの接続ドレイン

フェイルオーバー率

フェイルオーバー率により、GCP がフェイルオーバーまたはフェイルバックを実行してアクティブ プールのメンバーを変更するタイミングが決まります。この比率は変更可能です。設定できる値は 0.0 から 1.0 までです(両端を含みます)。フェイルオーバー率を指定しない場合、GCP はデフォルト値の 0.0 を使用します。このデフォルト値ではなく、ユースケースに合わせてフェイルオーバー率を設定することをおすすめします。

条件 アクティブ プール内の VM
  1. フェイルオーバー率:(x)!= 0.0
    正常なプライマリ VM の比率: >= x
  2. フェイルオーバー率:(x)= 0.0
    正常なプライマリ VM の数: > 0
すべて正常なプライマリ VM
少なくとも 1 つのバックアップ VM が正常で、かつ
  1. フェイルオーバー率:(x)!= 0.0
    正常なプライマリ VM の割合 < x
  2. フェイルオーバー率 = 0.0
    正常なプライマリ VM の数: = 0
正常なすべてのバックアップ VM
すべてのプライマリ VM とすべてのバックアップ VM が正常でない、かつこの状況でロードバランサがトラフィックをドロップするように構成されていない。 すべてプライマリ VM(最後の手段として使用)

次の例に、アクティブ プールのメンバーシップを示しています。具体的な計算については、フェイルオーバーの例をご覧ください。

  • フェイルオーバー率が 1.0 の場合、すべてのプライマリ VM が正常に動作しています。少なくとも 1 つのプライマリ VM が異常終了すると、GCP はフェイルオーバーを実行し、バックアップ VM をアクティブ プールに移動します。
  • フェイルオーバー率が 0.1 の場合、正常なプライマリ VM の割合が 10% を下回ると、GCP はフェイルオーバーを実行します。
  • フェイルオーバー率を 0.0 に設定すると、すべてのプライマリ VM が異常な状態になった場合に限り、GCP がフェイルオーバーを実行します。正常なプライマリ VM が 1 つでもあれば、フェイルオーバーは実行されません。

内部 TCP / UDP ロードバランサは、トラフィック分散アルゴリズムに従ってアクティブ プール内の VM 間で接続を分散します。

すべてのバックエンド VM が正常でない場合のトラフィックの廃棄

デフォルトでは、すべてのプライマリ VM とバックアップ VM が異常な状態になると、GCP はすべてのプライマリ VM 間で新しい接続を確立します。これは最後の手段です。

すべてのプライマリ VM とバックアップ VM が異常な場合に新しい接続をドロップするように、内部 TCP / UDP ロードバランサを構成できます。

フェイルオーバーとフェイルバックでの接続ドレイン

接続ドレインを使用すると、バックエンド VM が異常な状態になってから所定の時間が経過するまで、既存の TCP セッションをアクティブな状態で維持できます。ロードバランサのプロトコルが TCP の場合、次のようになります。

  • デフォルトでは、接続のドレインが有効になっています。バックエンド VM が正常に動作しない場合や、ロードバランサのアクティブ プールに存在しない場合でも、既存の TCP セッションは最大で 300 秒間(10 分)バックエンド VM で持続します。

  • フェイルオーバー イベントとフェイルバック イベントが発生すると、接続が切断されます。フェイルオーバーやフェイルバックで接続のドレインを使用すると、確立された TCP セッションがすべて即座に停止します。バックエンド VM への接続が TCP リセット パケットで終了することもあります。

フェイルオーバーとフェイルバックで接続ドレインを使用すると、次のような場合に役立ちます。

  • バックエンド VM にパッチを適用する: パッチを適用する前に、ヘルスチェックに失敗するプライマリ VM を構成します。これにより、負荷分散がフェイルオーバーを実行します。接続ドレインを無効にすると、すべての接続が計画どおり迅速にバックアップ VM に移動します。これにより、既存の接続を維持したまま、アップデートをインストールしてプライマリ VM を再起動できます。パッチの適用後、所定の数のプライマリ VM(フェイルオーバー率を参照)がヘルスチェックに合格すると、GCP がフェイルバックを実行します。

  • 1 つのバックエンド VM でデータの整合性を維持する: すべての接続の宛先に 1 つのプライマリ VM を使用する必要がある場合は、プライマリ VM からバックアップ VM への切り替えはできません。この場合、1 つのバックエンド VM のみを常にアクティブにすることで、データの不整合を回避できます。

フェイルオーバーの例

次の例は、アーキテクチャのセクションで説明したマルチゾーンの内部 TCP / UDP ロードバランサのフェイルオーバー動作を表しています。

マルチゾーンの内部 TCP / UDP 負荷分散フェイルオーバー(クリックして拡大)
マルチゾーンの内部 TCP / UDP 負荷分散フェイルオーバー(クリックして拡大)

このロードバランサの主なバックエンドは us-west1-aig-aus-west1-cig-d で、いずれも非マネージド インスタンス グループです。それぞれのインスタンス グループには 2 つの VM が存在し、どちらのインスタンス グループの VM もすべてプライマリ VM です。

  • ig-avm-a1
  • ig-avm-a2
  • ig-dvm-d1
  • ig-dvm-d2

このロードバランサのフェイルオーバー バックエンドは us-west1-aig-bus-west1-cig-c で、これらも非マネージド インスタンス グループです。それぞれのインスタンス グループには 2 つの VM が存在し、どちらのインスタンス グループの VM もすべてバックアップ VM です。

  • ig-bvm-b1
  • ig-bvm-b2
  • ig-cvm-c1
  • ig-cvm-c2

正常なプライマリ VM の数が 2 未満の場合に、この接続がバックアップ VM に配信されるように、ロードバランサのフェイルオーバー ポリシーを構成するとします。まず、フェイルオーバー率を 0.550%)に設定します。GCP は、フェイルオーバー率にプライマリ VM の数を掛けて、正常なプライマリ VM の最小数を計算します(計算式: 4 × 0.5 = 2)。

4 台のプライマリ VM がすべて正常な場合、GCP はすべてのホストに新しい接続を割り当てます。プライマリ VM がヘルスチェックに失敗した場合は、次のように処理されます。

  • vm-a1vm-d1 が正常に動作していない場合、残りの 2 つの正常なプライマリ VM(vm-a2vm-d2)も間で新しい接続が確立されます。

  • vm-a2 もヘルスチェックに失敗し、正常なプライマリ VM(vm-d2) が 1 台だけ存在します。GCP は正常なプライマリ VM の数が最小数より少ないことを認識し、フェイルオーバーを実行します。アクティブ プールは 4 つの正常なバックアップ VM に設定されます。新しい接続は 4 つのインスタンス グループに分散します(インスタンス グループ ig-big-c)。vm-d2 は正常な状態ですが、アクティブ プールから削除されるので、新しい接続は確立しません。

  • vm-a2 が復旧してヘルスチェックに合格すると、GCP は正常なプライマリ VM が 2 台以上存在することを認識し、フェイルバックを実行します。アクティブ プールは 2 つのプライマリ VM(vm-a2vm-d2)に設定され、新しい接続が分散されます。バックアップ VM はすべてアクティブ プールから削除されます。

  • 他のプライマリ VM が復旧し、ヘルスチェックに合格すると、GCP はこの VM をアクティブ プールに追加します。たとえば、vm-a1 が正常な状態になると、GCP は 3 台の正常なプライマリ VM(vm-a1vm-a2vm-d2)にアクティブ プールを設定し、新しい接続を分散します。

次のステップ