内部 TCP/UDP 負荷分散のフェイルオーバーの概要

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

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

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

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

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

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

自動スケーリングとフェイルオーバーでマネージド インスタンス グループを使用すると、アクティブ プールがプライマリ バックエンドとフェイルオーバー バックエンドの間でフェイルオーバーとフェイルバックを繰り返す可能性があります。Google Cloud では、マネージド インスタンス グループによるフェイルオーバー構成を禁じていません。貴社でのデプロイがこの構成から恩恵を受けている可能性があるためです。

アーキテクチャ

次の例は、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 の台数は、割合として構成できます。

上限

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

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

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

アクティブ プール

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

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

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

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

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

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

フェイルオーバー ポリシーは、Google Cloud がフェイルオーバーとフェイルバックに使用するパラメータのコレクションです。それぞれの内部 TCP / UDP ロードバランサには、複数の設定を持つ 1 つのフェイルオーバー ポリシーがあります。

  • フェイルオーバー率
  • すべてのバックエンド VM が正常でない場合のトラフィックのドロップ
  • フェイルオーバーとフェイルバックでのコネクション ドレイン

フェイルオーバー率

構成可能なフェイルオーバー率により、Google Cloud がフェイルオーバーまたはフェイルバックを実行してアクティブ プールのメンバーを変更するタイミングが決まります。この比率は変更可能です。設定できる値は 0.0 から 1.0 までです(両端を含みます)。 フェイルオーバー率を指定しない場合、Google Cloud はデフォルト値の 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 が異常終了すると、Google Cloud はフェイルオーバーを実行し、バックアップ VM をアクティブ プールに移動します。
  • フェイルオーバー率が 0.1 の場合、正常なプライマリ VM の割合が 10% を下回ると、Google Cloud はフェイルオーバーを実行します。
  • フェイルオーバー率を 0.0 に設定すると、すべてのプライマリ VM が異常な状態になった場合に限り、Google Cloud がフェイルオーバーを実行します。正常なプライマリ VM が 1 つでもあれば、フェイルオーバーは実行されません。

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

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

デフォルトでは、すべてのプライマリ VM とバックアップ VM が正常でない場合は、Google Cloud は新しい接続をプライマリ VM だけに分散します。これは最後の手段です。バックアップ VM は、この最後の手段の接続分散から除外されます。

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

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

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

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

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

フェイルオーバーとフェイルバックでコネクション ドレインを無効にすると、次のような場合に役立ちます。

  • バックエンド VM にパッチを適用する。 パッチを適用する前に、ヘルスチェックの条件を満たさないプライマリ VM を構成します。これにより、ロードバランサがフェイルオーバーを実行します。接続ドレインを無効にすると、すべての接続が計画どおり迅速にバックアップ VM に移動します。 これにより、既存の接続を維持したまま、アップデートをインストールしてプライマリ VM を再起動できます。 パッチの適用後、一定台数のプライマリ VM(フェイルオーバー率を参照)がヘルスチェックの条件を満たすと、Google Cloud がフェイルバックを実行します。

  • 1 台のバックエンド VM でデータの整合性を維持する。 プライマリ VM 1 台のみをすべての接続トラフィックの宛先にしなければならない場合は、コネクション ドレインを無効にします。これにより、プライマリ VM からバックアップ VM への切り替え時に、既存の接続トラフィックを両方の VM で維持できなくなります。この場合、1 つのバックエンド VM のみを常にアクティブにすることで、データの不整合を回避できます。

フェイルオーバーの例

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

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

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

  • ig-a にある vm-a1
  • ig-a にある vm-a2
  • ig-d にある vm-d1
  • vm-d2ig-d

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

  • ig-b にある vm-b1
  • ig-b にある vm-b2
  • ig-c にある vm-c1
  • vm-c2ig-c

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

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

  • vm-a1vm-d1 が正常に動作していない場合、残りの 2 台の正常なプライマリ VM(vm-a2vm-d2)に新しい接続トラフィックが分散されます。これは、正常なプライマリ VM が最低台数以上存在するためです。

  • vm-a2 もヘルスチェックの条件を満たさず、正常なプライマリ VM が vm-d2 1 台だけになった場合、Google Cloud は、正常なプライマリ VM の数が最低台数より少ないことを認識して、フェイルオーバーを実行します。アクティブ プールは 4 つの正常なバックアップ VM に設定されます。新しい接続トラフィックは 4 つのインスタンス グループに分散されます(インスタンス グループ ig-big-cvm-d2 は正常ですが、アクティブ プールから削除されるので、新しい接続トラフィックは受信しません。

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

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

次のステップ