内部パススルー ネットワーク ロードバランサを構成して、プライマリ バックエンドの仮想マシン（VM）インスタンス間で接続トラフィックを分散し、必要に応じてフェイルオーバー バックエンドを使用するように変更できます。フェイルオーバーにより可用性を向上させることができる一方、メインのバックエンド VM が正常に動作していない場合にワークロードをより効率的に管理できます。
このページでは、内部パススルー ネットワーク ロードバランサのフェイルオーバーに固有のコンセプトと要件について説明します。内部パススルー ネットワーク ロードバランサのフェイルオーバーを構成する前に、次の記事のコンセプトを理解しておいてください。
フェイルオーバーを構成すると、内部パススルー ネットワーク ロードバランサの標準のトラフィック分散アルゴリズムが変更されるため、これらのコンセプトを理解しておく必要があります。
デフォルトでは、内部パススルー ネットワーク ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドはプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。フェイルオーバー バックエンドは、構成可能なプライマリ仮想マシンの割合がヘルスチェックの基準を満たさなかったときにのみ、ロードバランサからの接続を受信します。
サポートされているインスタンス グループ
マネージド インスタンス グループと非マネージド インスタンス グループはバックエンドとしてサポートされます。このページでは、非マネージド インスタンス グループの例について説明します。
自動スケーリングとフェイルオーバーでマネージド インスタンス グループを使用すると、アクティブ プールがプライマリ バックエンドとフェイルオーバー バックエンドの間でフェイルオーバーとフェイルバックを繰り返す可能性があります。Google Cloud では、マネージド インスタンス グループによるフェイルオーバー構成を禁じていません。貴社でのデプロイがこの構成から恩恵を受けている可能性があるためです。
アーキテクチャ
次の簡単な例は、1 つのプライマリ バックエンドと 1 つのフェイルオーバー バックエンドがある内部パススルー ネットワーク ロードバランサを示しています。
- プライマリ バックエンドは、
us-west1-aにある非マネージド インスタンス グループです。 - フェイルオーバー バックエンドは、
us-west1-cにある別の非マネージド インスタンス グループです。
次の例は、2 つのプライマリ バックエンドと 2 つのフェイルオーバー バックエンドが存在する内部パススルー ネットワーク ロードバランサを示しており、両方のバックエンドが us-west1 リージョンの 2 つのゾーンに分散されています。この構成では、どのプライマリ バックエンドもフェイルオーバー バックエンドも 1 つのゾーンに依存しないため、信頼性が向上します。
- プライマリ バックエンドは、非マネージド インスタンス グループの
ig-aとig-dです。 - フェイルオーバー バックエンドは、非マネージド インスタンスグループの
ig-bとig-cです。
フェイルオーバーが発生すると、両方のプライマリ バックエンドが非アクティブになり、両方のフェイルオーバー バックエンドの正常な VM がアクティブになります。この例のフェイルオーバーの詳しい説明については、フェイルオーバーの例をご覧ください。
バックエンド インスタンス グループと VM
内部パススルー ネットワーク ロードバランサの非マネージド インスタンス グループは、プライマリ バックエンドまたはフェイルオーバー バックエンドのいずれかです。バックエンドは、バックエンド サービスに追加するときにフェイルオーバー バックエンドに指定できます。また、追加した後にバックエンドを編集して指定することもできます。それ以外の場合、非マネージド インスタンス グループはデフォルトでプライマリに設定されます。
1 つの内部パススルー ネットワーク ロードバランサで複数のプライマリ バックエンドと複数のフェイルオーバー バックエンドを構成するには、これらのバックエンドをロードバランサのバックエンド サービスに追加します。
プライマリ VM は、プライマリ バックエンドとして定義したインスタンス グループのメンバーです。ロードバランサがフェイルオーバー バックエンドを使用しない限り、メインのバックエンドの VM はロードバランサのアクティブ プールに参加します。
バックアップ VM は、フェイルオーバー バックエンドとして定義したインスタンス グループのメンバーです。プライマリ VM が異常になると、フェイルオーバー バックエンドの VM がロードバランサのアクティブ プールに参加します。フェイルオーバーをトリガーする異常な VM の台数は、割合として構成できます。
上限
VM アクティブ プールには、最大 250 台の VM を設定できます。つまり、プライマリ バックエンド インスタンス グループは最大 250 台のプライマリ VM を設定できます。また、フェイルオーバー バックエンド インスタンス グループには 250 台までのバックアップ VM を設定可能です。
非マネージド インスタンス グループ: 最大 50 個のプライマリ バックエンド インスタンス グループと最大 50 個のフェイルオーバー バックエンド インスタンス グループを設定できます。
たとえば、最大限のデプロイを行った場合、5 つのプライマリ バックエンドと 5 つのフェイルオーバー バックエンドを設定し、それぞれのインスタンス グループに 50 台の VM を追加できます。
アクティブ プール
アクティブ プールは、内部パススルー ネットワーク ロードバランサが新しい接続トラフィックを送信する先となるバックエンド VM のコレクションです。アクティブ プールのバックエンド VM のメンバーシップはバックエンドの健全性と条件に基づいて自動的に計算されます。フェイルオーバー率で説明するように、これらの条件や健全性は必要に応じて変更可能です。
アクティブ プール内で、プライマリ VM とバックアップ VM が混在することはありません。次の図に、メンバーシップの例を示します。フェイルオーバーでは、アクティブ プールにバックアップ VM のみが存在します。通常のオペレーション（フェイルバック）では、アクティブ プールにプライマリ VM のみが存在します。
フェイルオーバーとフェイルバック
フェイルオーバーとフェイルバックは、バックエンド VM をロードバランサのアクティブ プールに切り替える自動プロセスです。Google Cloud がアクティブ プールからプライマリ VM を削除し、正常なフェイルオーバー VM をアクティブ プールに追加するプロセスをフェイルオーバーといいます。Google Cloud がこの逆の処理を行うプロセスをフェイルバックといいます。
フェイルオーバー ポリシー
フェイルオーバー ポリシーは、Google Cloud がフェイルオーバーとフェイルバックに使用するパラメータのコレクションです。各内部パススルー ネットワーク ロードバランサには、複数の設定を持つ 1 つのフェイルオーバー ポリシーがあります。
- フェイルオーバー率
- すべてのバックエンド VM が正常でない場合のトラフィックのドロップ
- フェイルオーバーとフェイルバックでのコネクション ドレイン
フェイルオーバー率
構成可能なフェイルオーバー率により、Google Cloud がフェイルオーバーまたはフェイルバックを実行してアクティブ プールのメンバーを変更するタイミングが決まります。この比率は変更可能です。この比率は 0.0 から 1.0 までの範囲で設定できます（両端を含みます）。フェイルオーバー率を指定しない場合、Google Cloud はデフォルト値の 0.0 を使用します。このデフォルト値ではなく、ユースケースに合わせてフェイルオーバー率を設定することをおすすめします。
| 条件 | アクティブ プール内の VM |
|---|---|
|
すべて正常なプライマリ VM |
少なくとも 1 つのバックアップ VM が正常で、かつ:
|
正常なすべてのバックアップ 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 つでもあれば、フェイルオーバーは実行されません。
内部パススルー ネットワーク ロードバランサは、トラフィック分散アルゴリズムに従ってアクティブ プール内の VM 間で接続トラフィックを分散します。
すべてのバックエンド VM が正常でない場合のトラフィックのドロップ
デフォルトでは、すべてのプライマリ VM とバックアップ VM が異常な状態になると、Google Cloud はプライマリ VM のみに新しい接続を分散します。これは最後の手段です。バックアップ VM は、この最後の接続分散から除外されます。
すべてのプライマリ VM とバックアップ VM が異常な場合に新しい接続トラフィックをドロップするように、内部パススルー ネットワーク ロードバランサを構成できます。
フェイルオーバーとフェイルバックでのコネクション ドレイン
コネクション ドレインを使用すると、バックエンド VM が異常な状態になってから所定の時間が経過するまで、既存の TCP セッションをアクティブな状態で維持できます。ロードバランサのプロトコルが TCP の場合は、次のことが当てはまります。
デフォルトでは、コネクション ドレインが有効になっています。 バックエンド VM が正常に動作しない場合や、ロードバランサのアクティブ プールに存在しない場合でも、既存の TCP セッションは最大で 300 秒（5 分）間バックエンド VM で持続します。
フェイルオーバー イベントとフェイルバック イベントの発生中は、コネクション ドレインを無効にすることができます。フェイルオーバーやフェイルバック中にコネクション ドレインを無効にすると、確立済みの TCP セッションを含むすべての TCP セッションが即座に終了します。バックエンド VM への接続が TCP リセット パケットで終了することもあります。
フェイルオーバーとフェイルバックでコネクション ドレインを無効にすると、次のような場合に役立ちます。
バックエンド VM にパッチを適用する。パッチを適用する前に、ヘルスチェックの条件を満たさないプライマリ VM を構成します。これにより、ロードバランサがフェイルオーバーを実行します。コネクション ドレインを無効にすると、すべての接続トラフィックが想定どおり迅速にバックアップ VM に移動します。これにより、既存の接続を維持したまま、アップデートをインストールしてプライマリ VM を再起動できます。パッチの適用後、一定台数のプライマリ VM（フェイルオーバー率を参照）がヘルスチェックの条件を満たすと、Google Cloud がフェイルバックを実行します。
1 台のバックエンド VM でデータの整合性を維持する。プライマリ VM 1 台のみをすべての接続トラフィックの宛先にしなければならない場合は、コネクション ドレインを無効にします。これにより、プライマリ VM からバックアップ VM への切り替え時に、既存の接続トラフィックを両方の VM で維持できなくなります。この場合、1 つのバックエンド VM のみを常にアクティブにすることで、データの不整合を回避できます。
フェイルオーバーの例
次の例は、アーキテクチャのセクションで説明したマルチゾーン内部パススルー ネットワーク ロードバランサのフェイルオーバー動作を示しています。
このロードバランサのプライマリ バックエンドは、us-west1-a にある ig-a と us-west1-c にある ig-d であり、いずれも非マネージド インスタンス グループです。それぞれのインスタンス グループには 2 台の VM が存在します。どちらのインスタンス グループの VM もすべてプライマリ VM です。
ig-aにあるvm-a1ig-aにあるvm-a2ig-dにあるvm-d1ig-dにあるvm-d2
このロードバランサのフェイルオーバー バックエンドは、us-west1-a にある ig-b と us-west1-c にある ig-c であり、いずれも非マネージド インスタンス グループです。それぞれのインスタンス グループには 2 台の VM が存在します。どちらのインスタンス グループの VM もすべてバックアップ VM です。
ig-bにあるvm-b1ig-bにあるvm-b2ig-cにあるvm-c1ig-cにあるvm-c2
正常なプライマリ VM の台数が 2 未満の場合に、この接続がバックアップ VM に配信されるように、ロードバランサのフェイルオーバー ポリシーを構成するとします。まず、フェイルオーバー率を 0.5（50%）に設定します。Google Cloud は、フェイルオーバー率にプライマリ VM の台数を掛けて、正常なプライマリ VM の最低台数を計算します（計算式: 4 × 0.5 = 2）。
4 台のプライマリ VM がすべて正常な場合、Google Cloud はすべてのホストに新しい接続トラフィックを分散します。プライマリ VM がヘルスチェックの条件を満たさない場合は、次のように処理されます。
vm-a1とvm-d1が正常に動作していない場合、残りの 2 台の正常なプライマリ VM（vm-a2とvm-d2）に新しい接続トラフィックが分散されます。これは、正常なプライマリ VM が最低台数以上存在するためです。vm-a2もヘルスチェックの条件を満たさず、正常なプライマリ VM がvm-d21 台だけになった場合、Google Cloud は、正常なプライマリ VM の数が最低台数より少ないことを認識して、フェイルオーバーを実行します。アクティブ プールは 4 つの正常なバックアップ VM に設定されます。新しい接続トラフィックは 4 つのインスタンス グループに分散されます（インスタンス グループig-bとig-c。vm-d2は正常ですが、アクティブ プールから削除されるため、新しい接続トラフィックは受信しません。vm-a2が復旧してヘルスチェックの条件を満たすと、Google Cloud は正常なプライマリ VM が 2 台以上存在することを認識し、フェイルバックを実行します。アクティブ プールは 2 つのプライマリ VM（vm-a2とvm-d2）に設定され、新しい接続トラフィックが分散されます。バックアップ VM はすべてアクティブ プールから削除されます。他のプライマリ VM が復旧し、ヘルスチェックの条件を満たすと、Google Cloud はこの VM をアクティブ プールに追加します。たとえば、
vm-a1が正常な状態になると、Google Cloud はアクティブ プールを 3 台の正常なプライマリ VM（vm-a1、vm-a2、vm-d2）に設定し、新しい接続トラフィックを分散します。
次のステップ
- フェイルオーバーを使用する内部パススルー ネットワーク ロードバランサを構成してテストする。内部パススルー ネットワーク ロードバランサにフェイルオーバーを構成するをご覧ください。
- 内部パススルー ネットワーク ロードバランサを構成してテストする。内部パススルー ネットワーク ロードバランサを設定するをご覧ください。
- 内部パススルー ネットワーク ロードバランサの問題をトラブルシューティングする。内部パススルー ネットワーク ロードバランサをトラブルシューティングするをご覧ください。