このソリューションでは、フローティング IP アドレスを使用せずにオンプレミス ネットワーク環境から Compute Engine にアプリケーションを移行する方法について説明します。フローティング IP アドレスは、共有または仮想 IP アドレスとも呼ばれ、オンプレミス ネットワーク環境の可用性を高めるために使用されています。フローティング IP アドレスを使用すると、同一構成の複数の物理サーバーまたは仮想サーバー間で IP アドレスを渡すことにより、本番環境ソフトウェアのフェイルオーバーまたはアップグレードが可能になります。ただし、Compute Engine 環境ではフローティング IP アドレスを直接実装することができません。
オンプレミス環境でのフローティング IP アドレス
フローティング IP アドレスはオンプレミス環境でよく使用されます。次のリストは、フローティング IP アドレスのユースケースのほんの一例です。
- 複数のファイアウォールやロードバランサのセットなどの可用性の高い物理アプライアンスでは、フェイルオーバーのためにフローティング IP アドレスがよく使用されます。
- 高可用性を必要とするサーバーでは通常、フローティング IP アドレスが使用されます（Always On 可用性グループを使用する Microsoft SQL Server などのマスター / スレーブ リレーショナル データベースなど）。
- ロードバランサまたはリバース プロキシを実装している Linux 環境では、IPVS、HAProxy、NGINX などのフローティング IP アドレスが使用されます。また、ノード障害の検出やインスタンス間のフローティング IP アドレスの移動では、heartbeat、pacemaker、keepalived などのデーモンが使用されます。
- フローティング IP アドレスでは、Windows Server フェイルオーバー クラスタリングを使用する Windows サービスによって高可用性を実現できます。
オンプレミス環境でフローティング IP アドレスを実装する方法は、いくつかあります。いずれの場合も、IP アドレスを共有しているサーバーは、ハートビート メカニズムを通してお互いの状態も共有する必要があります。このメカニズムにより、サーバーは、お互いのヘルス ステータスをやり取りできます。リンク先のサーバーで障害が発生した場合にセカンダリ サーバーがフローティング IP アドレスを引き継ぐこともできます。このスキームは、ほとんどの場合、Virtual Router Redundancy Protocol（VRRP）を使用して実装されますが、他の同様のメカニズムを使用することもできます。
IP フェイルオーバーが開始されると、フローティング IP アドレスを引き継いだサーバーがそのアドレスをネットワーク インターフェースに追加します。サーバーは、Gratuitous Address Resolution Protocol（ARP）フレームを送信することで、レイヤ 2 を使用している他のデバイスにこの引き継ぎを通知します。代替アプローチとして、IP アドレスが Open Shortest Path First（OSPF）などのルーティング プロトコルによって上流のレイヤ 3 ルーターに通知される場合もあります。
次の図は、オンプレミス環境での一般的な設定を示しています。
IP Virtual Server（IPVS）などの直接サーバー レスポンスを使用した Windows ネットワーク負荷分散や Linux 負荷分散などのオンプレミス負荷分散ソリューションとは若干異なる設定を使用します。この場合、サービスは、Gratuitous ARP フレームも送出しますが、別のサーバーの MAC アドレスを Gratuitous ARP 送信元として使用し、本質的には ARP フレームを偽装して、別のサーバーの送信元アドレスを引き継ぎます。この種の設定は、このソリューションの対象外です。ほとんどすべての場合、負荷分散への移行が優先されます。
フローティング IP アドレスを Compute Engine に移行する際の課題
Compute Engine は Virtual Private Cloud（VPC）ネットワークで仮想化されたネットワーク スタックを使用するため、一般的な実装メカニズムはそのままでは機能しません。たとえば、VPC ネットワークは、構成されたルーティング トポロジに基づいて ARP リクエストを処理し、Gratuitous ARP フレームを無視します。また、OSPF や境界ゲートウェイ プロトコル（BGP）などの標準のルーティング プロトコルを使用して VPC ネットワーク ルーティング テーブルを直接変更することができません。
オーバーレイ ネットワークを使用すれば、ARP リクエストを使用した完全なレイヤ 2 通信と IP 引き継ぎを可能にする構成を作成できます。ただし、オーバーレイ ネットワークの設定は複雑なため、Compute Engine ネットワーク リソースの管理が難しくなります。このアプローチもこのソリューションの対象外です。代わりに、このソリューションは、ネイティブの Compute Engine ネットワーキング環境でフェイルオーバー シナリオを実装するための代替アプローチを提供します。
このソリューションでは、前述のユースケースの大部分を Compute Engine に移行する方法について説明します。
より具体的なユースケースについては、次のように詳しい手順がすでに公開されています。
移行するユースケースの例
このソリューションでは、オンプレミス フローティング IP アドレスから Compute Engine に移行するための 4 つの異なる移行オプションについて説明します。
このユースケースでは、複雑なレイヤ 7 ヘッダーの照合と交換に応じて異なるバックエンドにトラフィックをルーティングする 2 つの内部 HAProxy サーバーを移行します。ルールが複雑なため、このサーバーのセットを内部 TCP / UDP 負荷分散に置き換えることはできず、HTTP 負荷分散にも置き換えられません。次の図は、このユースケースの概要を示しています。
HAProxy サーバーは、keepalived ソフトウェアをオンプレミスで使用して、別の相互接続で可用性をチェックし、2 つのサーバー間でフローティング IP アドレスをやり取りします。
このユースケースの場合、次のセクションで説明する 4 つのオプションはすべて、オンプレミスのフローティング IP アドレスに代わる有効なオプションとなります。ユースケースが複雑になるほど、適用可能なオプションの数が減る傾向があります。これらのオプションの説明に続いて、このソリューションでは、特定のユースケースに基づく推奨オプションのガイダンスを提供します。
次のセクションでは、このユースケース シナリオを Compute Engine に移行する方法について説明します。
Compute Engine を使用した実装
このセクションでは、オンプレミスのシナリオを Compute Engine に移行するいくつかの方法について説明します。複雑さを軽減するために、前述のヘッダーベースの照合を使用する代わりに、すべてのリクエストが、最小バックエンド構成を使用した NGINX バックエンドの単一のグループに転送されます。
すべての例で、トラフィックは、HAProxy から、自動スケーリング インスタンス グループに配置された Compute Engine バックエンドの 1 つのグループにルーティングされます。これらのバックエンドへのアクセスは、内部 TCP / UDP ロードバランサを使用して行われます。構成例では、これらのバックエンドが NGINX デフォルト構成を処理します。
ユースケースの例を実装するために、テスト専用のプロジェクトを使用します。
バックエンドの構成
このセクションでは、HAProxy ノードからアクセスされる NGINX バックエンドを構成します。ベスト プラクティスとして、これらのバックエンドは、デフォルトのネットワークではなく、このデプロイ専用の VPC 内に作成します。
バックエンドを設定する手順は次のとおりです。
次のように、デフォルト ゾーンを設定します。
gcloud config set compute/zone us-central1-fテスト用のネットワークを設定した後、内部トラフィックを許可するファイアウォール ルールを設定し、
sshコマンドを使用してネットワークと通信します。gcloud compute networks create ip-failover gcloud compute firewall-rules create failover-internal \ --network ip-failover --allow all --source-ranges 10.128.0.0/11 gcloud compute firewall-rules create failover-ssh \ --network ip-failover --allow tcp:22 --source-ranges 0.0.0.0/0NGINX バックエンド用のインスタンス テンプレートを作成します。
gcloud compute instance-templates create www \ --machine-type n1-standard-1 --network ip-failover \ --metadata startup-script="apt-get -y install nginx"テンプレートに基づいて、自動スケーリング ゾーン マネージド インスタンス グループを作成します。
gcloud compute instance-groups managed create www \ --template www --size 1 --zone us-central1-f gcloud compute instance-groups managed set-autoscaling www \ --max-num-replicas 10 --min-num-replicas 1 \ --target-cpu-utilization 0.8 --zone us-central1-f固定 IP アドレス（
10.128.2.2）を持つ内部 TCP / UDP ロードバランサをこのインスタンス グループに接続します。gcloud compute health-checks create http simple-check gcloud compute backend-services create www-lb \ --load-balancing-scheme internal \ --region us-central1 \ --health-checks simple-check \ --protocol tcp gcloud compute backend-services add-backend www-lb\ --instance-group www \ --instance-group-zone us-central1-f \ --region us-central1 gcloud compute forwarding-rules create www-rule \ --load-balancing-scheme internal \ --ports 80 \ --network ip-failover \ --region us-central1 \ --address 10.128.2.2 \ --backend-service www-lbテスト用のインスタンスを作成して
sshコマンドで接続し、内部 TCP / UDP 負荷分散 IP アドレスに到達できるかどうかを確認します。gcloud compute instances create testing \ --machine-type n1-standard-1 --zone us-central1-f \ --network ip-failover --scopes compute-ro gcloud compute ssh testing --zone us-central1-fusername@testing:~$ curl 10.128.2.2
<!DOCTYPE html> [...]
username@testing:~$ exit
この構成例では、n1-standard-1 インスタンスを使用します。このインスタンスは、インスタンスあたり 2 ギガバイト/秒のネットワーク スループットに制限されます。実際のデプロイでは、必要に応じてインスタンスのサイズを変更します。
加えて、インスタンスは、外部 IP アドレスを使用して作成されるため、起動スクリプトを使用して必要なパッケージをダウンロードできます。本番環境設定では、カスタム イメージを作成し、外部 IP アドレスを使用せずにインスタンスを作成します。
オプション 1: 内部 TCP / UDP 負荷分散の使用
次の図のように、2 つの HAProxy サーバーを内部 TCP / UDP 負荷分散の背後にあるマネージド インスタンス グループに配置し、内部 TCP / UDP 負荷分散 IP アドレスを仮想 IP アドレスとして使用することにより、Compute Engine でオンプレミス シナリオを実装できます。
オンプレミス移行対象サービスは内部的にのみ公開されると想定しています。移行しようとしているサービスが外部から利用可能な場合は、HTTP(S) 負荷分散、TCP プロキシ、SSL プロキシ、ネットワーク負荷分散を使用して同様の方法でこのシナリオを実装できます。
次のベータ版のみのオプションも利用できます。
オンプレミス設定との違い
内部 TCP / UDP 負荷分散 IP アドレスは、オンプレミス環境のフローティング IP アドレスと同様に機能しますが、いくつかの違いがあります。
トラフィック分散
最も顕著な違いは、トラフィックが 2 つのノード間で共有されることです。オリジナルの設定では、トラフィックが一度に 1 つのノードにしか到達しません。このアプローチは、リクエスト自体の内容に応じてトラフィックがルーティングされるシナリオでは問題ありませんが、マスター / スレーブ データベースなど、常に同期されていないマシン状態が存在する場合は機能しません。
フェイルオーバー時間
Gratuitous ARP を使用してペア化されたオンプレミス環境で keepalived を使用すると、数秒で IP アドレスがフェイルオーバーする場合があります。Compute Engine 環境では、平均復旧時間が障害モードによって異なります。仮想マシン（VM）インスタンスまたは VM インスタンス サービスに障害が発生した場合、平均フェイルオーバー トラフィックは、
Check Interval、Unhealthy Thresholdなどのヘルスチェック パラメータに依存します。これらのパラメータをデフォルト値に設定すると、フェイルオーバーには 15～20 秒程度かかりますが、これらのパラメータを調整することによってこの時間を短縮できます。Compute Engine では、ゾーン内またはゾーン間のフェイルオーバーにかかる時間は同じです。ヘルスチェック
オンプレミスで使用された場合、keepalived は、アライブ信号を待つことに加えて、HAProxy プロセスの可用性のモニタリングなど、さまざまな方法でホストマシンの正常性をチェックできます。Compute Engine では、HTTP / HTTPS / TCP または SSL ポートを使用して、ホストの外部からヘルスチェックにアクセスできる必要があります。ホストの詳細をチェックする必要がある場合は、インスタンスに単純なサービスをインストールしてその詳細を公開するか、代替オプションを選択する必要があります。
ポート
オンプレミス設定では、フローティング IP アドレスはすべてのトラフィックを受け入れます。内部 TCP / UDP ロードバランサの場合、内部転送ルールで次のポート指定のいずれかを選択する必要があります。
- 1 個から 5 個までのポートを番号で指定します
- すべてのポートにトラフィックを転送するには
ALLを指定する。
オプション 1 の実装
このソリューションを実装する手順は次のとおりです。
リクエストを転送する HAProxy サーバー用のインスタンス テンプレートを作成します。
gcloud compute instance-templates create haproxy \ --machine-type n1-standard-1 --network ip-failover \ --metadata "startup-script= sudo apt-get install -y haproxy cat << EOF >> /etc/haproxy/haproxy.cfg frontend www bind :80 option http-server-close default_backend web-backend backend web-backend server web-1 10.128.2.2:80 check EOF service haproxy restart"静的サイズが 2 のインスタンス テンプレートに基づいてゾーン インスタンス グループを作成します。以前作成したヘルスチェックを使用して、自動修復ポリシーをインスタンスに接続します。
gcloud compute instance-groups managed create haproxy \ --template haproxy --size 2 --zone us-central1-f gcloud compute instance-groups managed update \ haproxy --health-check simple-check --zone us-central1-fヘルスチェックを使用して、内部 TCP / UDP ロードバランサを複数の HAProxy サーバーに接続します。
gcloud compute backend-services create haproxy-lb \ --load-balancing-scheme internal \ --region us-central1 \ --health-checks simple-check \ --protocol tcp gcloud compute backend-services add-backend haproxy-lb\ --instance-group haproxy \ --instance-group-zone us-central1-f \ --region us-central1 gcloud compute forwarding-rules create haproxy-rule \ --load-balancing-scheme internal \ --ports 80 \ --network ip-failover \ --region us-central1 \ --address 10.128.1.1 \ --backend-service haproxy-lb内部 TCP / UDP 負荷分散を通して HAProxy に到達できるかどうかをテストします。
gcloud compute ssh testing --zone us-central1-fusername@testing:~$ curl 10.128.1.1
<!DOCTYPE html> [...]
username@testing:~$ exit
コンソールから HAProxy インスタンスの 1 つを削除した場合や、インスタンスの 1 つで HAProxy プロセスを停止した場合でも、短いフェイルオーバー時間後に curl が成功します。
オプション 2: 単一のマネージド インスタンスの使用
復旧時間の要件によっては、オンプレミスで複数のサーバーが使用されていた場合でも、単一の VM インスタンスを使用した移行が Compute Engine の実行可能なオプションになる場合があります。これは、新しい Compute Engine インスタンスは数分でスピンアップできますが、オンプレミス障害は、通常、修正に数時間から数日かかるためです。
オプション 2 とオプション 1 の比較: 内部 TCP / UDP 負荷分散
オプション 2 には、オプション 1 と比較して大きなメリットとデメリットがあります。
メリット:
トラフィック分散
インスタンスは 1 つしか存在しないため、オンプレミス マスター / スレーブ シナリオと同様に、すべてのトラフィックが 1 つのインスタンスに送られます。
コストの節約
2 つではなく 1 つの VM インスタンスを使用することによって、実装コストを半減させることができます。
シンプル
このソリューションは実装が容易で、オーバーヘッドがほとんどありません。
デメリット:
フェイルオーバー時間
ヘルスチェックでマシン障害が検出されてから、障害が発生したインスタンスを削除して再作成するのに少なくとも 1 分はかかりますが、もっと長い時間がかかることもあります。このプロセスには、内部 TCP / UDP 負荷分散からインスタンスを削除するよりもはるかに長い時間がかかります。
ゾーン障害への対応
サイズが 1 のマネージド インスタンス グループは、ゾーン障害に対する耐性がありません。ゾーン障害に対応するには、サービスの失敗時の Stackdriver Monitoring アラートの追加を検討し、ゾーン障害の発生時に別のゾーンに手動でインスタンス グループを作成します。
IP アドレスの不安定性
失敗後にインスタンスが再作成されると、インスタンス名はそのままですが、IP アドレスは変わることがあります。クライアントは、インスタンス名を使用してアプリケーションに接続する必要があります。
オプション 2 の実装
オプション 2 を実装する手順は次のとおりです。
HAProxy VM インスタンス用のインスタンス テンプレートを作成します。
gcloud compute instance-templates create haproxy-single \ --machine-type n1-standard-1 --network ip-failover \ --metadata "startup-script= sudo apt-get install -y haproxy cat << EOF >> /etc/haproxy/haproxy.cfg frontend www bind :80 option http-server-close default_backend web-backend backend web-backend server web-1 10.128.2.2:80 check EOF service haproxy restart"HAProxy VM 用にサイズが 1 のマネージド インスタンス グループを作成し、自動修復ポリシーを接続します。
gcloud compute instance-groups managed create haproxy-single \ --template haproxy-single --size 1 --zone us-central1-f gcloud compute instance-groups managed update \ haproxy-single --health-check simple-check --zone us-central1-f内部 TCP / UDP 負荷分散 IP アドレス経由で HAProxy に到達できるかどうかをテストします。
gcloud compute ssh testing --zone us-central1-fusername@testing:~$ instance=$(gcloud compute instances list |awk '$1 ~ /^haproxy-single/ { print $1 }') username@testing:~$ curl $instance
<!DOCTYPE html> [...]
username@testing:~$ exitコンソールを使用して HAProxy インスタンスを削除するか、HAProxy インスタンス プロセスを停止すると、インスタンスは少し遅れて同じインスタンス名で自動的に回復するはずです。
オプション 3: 優先順位が異なるルートを使用したフェイルオーバー
優先順位が異なる 2 つの Compute Engine ルートを使用すると、内部 TCP / UDP 負荷分散を使用できない場合に 2 つのインスタンス間でトラフィックのフェイルオーバーが可能になります。
このセクションでは、2 つの VM インスタンスを作成して、静的サイズが 1 の自動修復マネージド インスタンス グループに配置し、システムが自動的に修復できるようにします。
この両方のインスタンスで IP 転送を有効にする必要があります。その後、インスタンスを作成してから、トラフィックを処理するための優先順位が異なる 2 つのルートを設定することによって、すべてのフローティング IP トラフィックをこの 2 つのインスタンスに振り向けます。
オプション 3 とオプション 1 の比較: 内部 TCP / UDP 負荷分散
オプション 3 を使用すると、内部 TCP / UDP 負荷分散を簡単に利用できないユースケースを移行できます。このオプションには、以下のような利点があります。
トラフィック分散
トラフィックは、常に、最も優先順位の低い VM インスタンスに流れます。この VM インスタンスが利用できない場合、トラフィックは次の最適ルートを使用します。このアーキテクチャは、特定の時間に 1 つのサーバーだけがアクティブなオンプレミス環境に似ています。
プロトコル
内部 TCP / UDP 負荷分散は特定のプロトコルまたはポートのセットにしか適用されませんが、ルートは特定の宛先へのすべてのトラフィックに適用されます。
地域性
内部 TCP / UDP 負荷分散はリージョン内でしか使用できませんが、ルートはグローバルに作成できます。
オプション 3 には、内部 TCP / UDP 負荷分散を使用するオプション 1 と比較して次のようなデメリットがあります。
ヘルスチェック
オプション 3 を使用すると、2 つのルートのどちらにもヘルスチェックが接続されません。 ルートは、基礎となる VM サービスの正常性に関係なく使用されます。サービスが正常でない場合でも、トラフィックがインスタンスに送られます。このようなインスタンスに自動修復ポリシーを付加すると、特定の異常期間の経過後にインスタンスが強制終了されますが、それらのインスタンスが再起動されると、サービスが起動する前でもトラフィックが再開されるため、異常なインスタンスがまだトラフィックを処理中の場合または再起動中にサービスエラーが発生する可能性があります。
フェイルオーバー時間
VM インスタンスを削除または停止すると、ルートが自動的に取り消されます。ただし、ヘルスチェックが存在しないため、インスタンスが利用可能な間は、ルートが使用され続けます。加えて、インスタンスの停止には時間がかかるため、フェイルオーバー時間は、内部 TCP / UDP 負荷分散アプローチよりかなり長くなります。
フローティング IP アドレスの選択
ルートは、サブネットの一部ではない IP アドレスにだけ設定できます。フローティング IP アドレスは、既存のすべてのサブネット範囲の外側で選択する必要があります。
VPC ネットワーク ピアリング
VM インスタンスは独自の VPC ネットワークからのルートのみを使用でき、ピア VPC ネットワークからのルートは使用できません。
オプション 3 の実装
実装する際には、IP アドレス 10.191.1.1 を使用します。このアドレスは、ip-failover ネットワークのすべての有効なサブネットの外側にあります。手順は次のとおりです。
リクエストを転送する HAProxy サーバー用のインスタンス テンプレートを作成します。
gcloud compute instance-templates create haproxy-route \ --machine-type n1-standard-1 --network ip-failover \ --metadata "startup-script= apt-get update apt-get install -y haproxy cat << EOF >> /etc/haproxy/haproxy.cfg frontend www bind :80 option http-server-close default_backend web-backend backend web-backend server web-1 10.128.2.2:80 check EOF cat << EOF >> /etc/network/interfaces auto eth0:0 iface eth0:0 inet static address 10.191.1.1 netmask 255.255.255.255 EOF service haproxy restart service networking restart" --can-ip-forwardHAProxy VM インスタンス用に、サイズが 1 のマネージド インスタンス グループを 2 つ作成し、自動修復ポリシーを接続します。
gcloud compute instance-groups managed create haproxy-r1 \ --template haproxy-route --size 1 --zone us-central1-f gcloud compute instance-groups managed update \ haproxy-r1 --health-check simple-check --zone us-central1-f gcloud compute instance-groups managed create haproxy-r2 \ --template haproxy-route --size 1 --zone us-central1-b gcloud compute instance-groups managed update \ haproxy-r2 --health-check simple-check --zone us-central1-bこれらの VM インスタンスへのプライマリ ルートとバックアップ ルートをインスタンス起動後に作成します。
haproxy1=$(gcloud compute instances list |awk '$1 \ ~ /^haproxy-r1/ { print $1 }') #save the instance name of the first HAproxy instance haproxy2=$(gcloud compute instances list |awk '$1 \ ~ /^haproxy-r2/ { print $1 }') #save the instance name of the second HAproxy instance gcloud compute routes create haproxy-route1 \ --destination-range 10.191.1.1/32 --network ip-failover \ --priority 500 --next-hop-instance-zone us-central1-f \ --next-hop-instance $haproxy1 gcloud compute routes create haproxy-route2 \ --destination-range 10.191.1.1/32 --network ip-failover \ --priority 600 --next-hop-instance-zone us-central1-b \ --next-hop-instance $haproxy2ルート経由で HAProxy に到達できるかどうかをテストします。
gcloud compute ssh testing --zone us-central1-fusername@testing:~$ curl 10.191.1.1
<!DOCTYPE html> [...]
username@testing:~$ exitコンソール経由でプライマリ HAProxy インスタンスを削除すると、インスタンスが完全に停止した直後にセカンダリ インスタンスへのルートが使用されるはずです。
オプション 4: ルート API 呼び出しを使用したフェイルオーバー
オプション 3 と同様に、オプション 4 もルートを使用しますが、重要な違いがあります。インスタンスの自動修復と自動再作成の代わりに、keepalived などのスクリプトで API 呼び出しを使用して、新しい正常なインスタンスにルートを追加したり、異常なインスタンスからルートを削除したりできます。このアプローチは、Compute Engine ヘルスチェックを使用してアプリケーションの正常性の追跡やプライマリにする仮想マシンの決定を行えない場合に役立ちます。任意のアプリケーション ロジックでルートの動的再プログラミングをトリガーできます。
ルート API 呼び出しをフェイルオーバー方式として使用すると、アプリケーションの障害を手動で調査し、インスタンスを手動でオンラインに戻すときにも便利です。 ただし、VM はすべての障害を記録して正常に戻ったら自動的に交換できる必要があるため、Compute Engine で手動で障害を調査しないでください。
オプション 4 の違い: 内部 TCP / UDP 負荷分散
内部 TCP / UDP 負荷分散を使用する場合とは対照的に、オプション 4 は次のようなメリットを提供します。
トラフィック分散
オプション 2 とオプション 3 の場合と同様、トラフィックは一度に 1 つの VM インスタンスにしか送られません。
Compute Engine のヘルスチェックに依存しない
フェイルオーバーは、どのカスタム アプリケーション ロジックからでもトリガーできます。オプション 4 では、スクリプトを使用して、プライマリ HAProxy とセカンダリ HAProxy 間の通信障害に対する keepalived の反応を管理します。これは、Compute Engine のヘルスチェックを使用できない、または、使用したくない場合に機能する唯一のオプションです。
オプション 4 にも大きなデメリットがあります。
複雑さ
このオプションの場合、Compute Engine API を使用してカスタムビルドする必要があります。
gcloudで取り消してから、Compute Engine API を使用して新しいルートを設定します。このロジックを信頼性の高い方法で構築する作業は、しばしば複雑なものになります。フェイルオーバー時間
Compute Engine で現在のルートを取り消して新しいルートを作成するには、カスタム スクリプトによる少なくとも 2 回の Compute Engine API 呼び出しが必要なため、フェイルオーバーが内部ロードバランサを使用した場合よりもわずかに遅くなります。
フローティング IP アドレスの選択
ルートは、サブネットの一部ではない IP アドレスにだけ設定できます。フローティング IP アドレスは、既存のすべてのサブネット範囲の外側で選択する必要があります。
VPC ネットワーク ピアリング
VM インスタンスは独自の VPC ネットワークからのルートのみを使用でき、ピア VPC ネットワークからのルートは使用できません。
オプション 4 の実装
この実装では、IP アドレス 10.190.1.1 は、ip-failover ネットワークの有効なサブネットの外にあります。このアドレスのルートは keepalived によって自動的に作成され削除されます。
まず、両方のインスタンスの静的内部 IP アドレスを使用して、haproxy と keepalived がインストールされた 2 つの HAProxy インスタンスを作成します。また、IP 転送を有効にしてルートを終端できる必要があり、Compute Engine API へのアクセス権も必要です。単純にするために、この例ではインスタンス テンプレートとグループを使用しません。
次の手順でオプション 4 を作成します。
静的 IP アドレスが
10.128.4.100のプライマリ インスタンスを作成します。gcloud compute instances create haproxy-a \ --machine-type n1-standard-1 --network ip-failover \ --can-ip-forward --private-network-ip=10.128.4.100 \ --scopes compute-rw --zone us-central1-f \ --metadata 'startup-script= apt-get update apt-get install -y haproxy keepalived cat << EOF >> /etc/haproxy/haproxy.cfg frontend www bind :80 option http-server-close default_backend web-backend backend web-backend server web-1 10.128.2.2:80 check EOF cat << EOF >> /etc/network/interfaces auto eth0:0 iface eth0:0 inet static address 10.190.1.1 netmask 255.255.255.255 EOF cat << EOF >> /etc/keepalived/keepalived.conf vrrp_script haproxy { script "/bin/pidof haproxy" interval 2 } vrrp_instance floating_ip { state MASTER interface eth0 track_script { haproxy } unicast_src_ip 10.128.4.100 unicast_peer { 10.128.4.200 } virtual_router_id 50 priority 100 authentication { auth_type PASS auth_pass yourpassword } notify_master /etc/keepalived/takeover.sh } EOF cat << EOF >> /etc/keepalived/takeover.sh #!/bin/bash gcloud compute routes delete floating --quiet gcloud compute routes create floating \ --destination-range 10.190.1.1/32 --network ip-failover \ --priority 500 --next-hop-instance-zone us-central1-f \ --next-hop-instance haproxy-a --quiet EOF chmod +x /etc/keepalived/takeover.sh service haproxy restart service networking restart service keepalived start'静的 IP アドレスが
10.128.4.200のセカンダリ インスタンスを作成します。gcloud compute instances create haproxy-b \ --machine-type n1-standard-1 --network ip-failover \ --can-ip-forward --private-network-ip=10.128.4.200 \ --scopes compute-rw --zone us-central1-c \ --metadata 'startup-script= apt-get update apt-get install -y haproxy keepalived cat << EOF >> /etc/haproxy/haproxy.cfg frontend www bind :80 option http-server-close default_backend web-backend backend web-backend server web-1 10.128.2.2:80 check EOF cat << EOF >> /etc/network/interfaces auto eth0:0 iface eth0:0 inet static address 10.190.1.1 netmask 255.255.255.255 EOF cat << EOF >> /etc/keepalived/keepalived.conf vrrp_script haproxy { script "/bin/pidof haproxy" interval 2 } vrrp_instance floating_ip { state BACKUP interface eth0 track_script { haproxy } unicast_src_ip 10.128.4.200 unicast_peer { 10.128.4.100 } virtual_router_id 50 priority 50 authentication { auth_type PASS auth_pass yourpassword } notify_master /etc/keepalived/takeover.sh } EOF cat << EOF >> /etc/keepalived/takeover.sh #!/bin/bash gcloud compute routes delete floating --quiet gcloud compute routes create floating \ --destination-range 10.190.1.1/32 --network ip-failover \ --priority 500 --next-hop-instance-zone us-central1-c \ --next-hop-instance haproxy-b --quiet EOF chmod +x /etc/keepalived/takeover.sh service haproxy restart service networking restart service keepalived start'ルート経由で HAProxy に到達できるかどうかをテストします。
gcloud compute ssh testing --zone us-central1-fusername@testing:~$ curl 10.190.1.1
<!DOCTYPE html> [...]
username@testing:~$ exitインスタンス haproxy-a 上の HAProxy が強制終了されるかそのインスタンスがロックアップすると、VRRP ハートビートが失われ、haproxy-b インスタンスが takeover.sh スクリプトを呼び出します。このスクリプトは、10.190.1.1 のルートを haproxy-a から haproxy-b に移動します。テストは引き続き動作します。
ユースケースに最適なオプションの選択
複雑なルーティングを決定する一連の HAProxy ノードを使用するユースケースの場合、Compute Engine の優先実装はオプション 1: 内部 TCP / UDP 負荷分散になります。これは、VM インスタンスがステートレスなためで、アクティブ-アクティブ シナリオで簡単に動作できます。加えて、Compute Engine のヘルスチェックを使用できます。他のユースケースでは、オプション 1 が最適なオプションではない場合があります。
前述の各オプションのメリットとデメリットに加えて、次のディシジョン ツリーを使用すると、実装スキームの決定に役立ちます。
可用性と信頼性の高いアプリケーションは、水平スケーリング アーキテクチャを使用して、単一ノードの障害の影響を最小限に抑えて Compute Engine に実装するのが最善です。フローティング IP アドレスを使用した 2 つのサーバーなど、一般的なオンプレミス シナリオを移行するのは困難です。これは、このようなシナリオを Compute Engine で再現することができないためです。前述したように、仮想ルーティング インフラストラクチャの特性上、Gratuitous ARP を使用して数秒間のうちに別々のマシン間で IP アドレスを移動することはできません。
内部 TCP / UDP 負荷分散を使用すれば、さまざまなユースケースを簡単かつ確実に Compute Engine に移行できます。内部ロードバランサを使用できない場合は、複雑なオーバーレイ ルーティング メカニズムを必要としない他のいくつかのオプションを実装できます。