バックエンド サービスベースの外部パススルー ネットワーク ロードバランサを構成して、プライマリ バックエンドの仮想マシン（VM）インスタンス間で接続を分散し、必要に応じてフェイルオーバー バックエンドを使用するように変更できます。フェイルオーバーにより可用性を向上させることができる一方、メインのバックエンド VM が正常に動作していない場合にワークロードをより効率的に管理できます。
このページでは、外部パススルー ネットワーク ロードバランサのフェイルオーバーに固有のコンセプトと要件について説明します。外部パススルー ネットワーク ロードバランサのフェイルオーバーを構成する前に、次の記事のコンセプトの情報についてよくご確認ください。
フェイルオーバーを構成すると、ロードバランサの標準のトラフィック分散アルゴリズムが変更されるため、これらのコンセプトを理解しておく必要があります。
デフォルトでは、外部パススルー ネットワーク ロードバランサのバックエンド サービスにバックエンドを追加すると、そのバックエンドはプライマリ バックエンドになります。バックエンドは、ロードバランサのバックエンド サービスに追加するときに指定できます。また、後でバックエンド サービスを編集して、フェイルオーバー バックエンドに指定することもできます。フェイルオーバー バックエンドは、構成可能なプライマリ VM の割合がヘルスチェックの基準を満たさなかったときにのみ、ロードバランサからの接続を受信します。
サポートされているバックエンド
インスタンス グループ（マネージドおよび非マネージド）とゾーン NEG（GCE_VM_IP エンドポイントを含む）はバックエンドとしてサポートされます。このページでは、非マネージド インスタンス グループの例について説明します。
自動スケーリングとフェイルオーバーでマネージド インスタンス グループを使用すると、アクティブ プールがプライマリ バックエンドとフェイルオーバー バックエンドの間でフェイルオーバーとフェイルバックを繰り返す可能性があります。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 の数は、割合として構成できます。
上限
- インスタンス グループ。最大 50 個のプライマリ バックエンド インスタンス グループと最大 50 個のフェイルオーバー バックエンド インスタンス グループを設定できます。
アクティブ プール
アクティブ プールは、外部パススルー ネットワーク ロードバランサが新しい接続トラフィックを送信する先となるバックエンド 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 が異常な場合に新しい接続トラフィックをドロップするように、外部パススルー ネットワーク ロードバランサを構成できます。
フェイルオーバーとフェイルバックでのコネクション ドレイン
フェイルオーバー ポリシーでコネクション ドレインを有効にすると、プライマリ インスタンス グループまたはフェイルオーバー インスタンス グループ内のインスタンスへの確立済みの接続は、フェイルオーバーまたはフェイルバック後であっても確立済みのインスタンスに送信され、接続の切断を回避できます。フェイルオーバー ポリシーでコネクション ドレインを無効にすると、既存の接続はフェイルオーバーまたはフェイルバック中に直ちに切断されます。
ロードバランサのプロトコルが TCP の場合は、次のことが当てはまります。
デフォルトでは、コネクション ドレインが有効になっています。バックエンド VM がロードバランサのアクティブ プールに存在しない場合でも、既存の TCP セッションは現在のバックエンド 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）に設定し、新しい接続トラフィックを分散します。
次のステップ
- フェイルオーバーを使用する外部パススルー ネットワーク ロードバランサを構成してテストする。外部パススルー ネットワーク ロードバランサのフェイルオーバーの構成をご覧ください。
- バックエンド サービスを使用する外部パススルー ネットワーク ロードバランサを構成してテストする。外部パススルー ネットワーク ロードバランサの設定をご覧ください。