このソリューションでは、アプリケーションをオンプレミス ネットワーク環境から Google Compute Engine に移行する際に、フローティング IP アドレスを使用しない方法の概要を示します。「共有」IP アドレスまたは「仮想」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 フレームを偽装して、別のサーバーの送信元アドレスを引き継ぎます。この種の設定は、このソリューションの対象外です。ほとんどすべての場合、負荷分散への移行が優先されます。
Compute Engine へのフローティング IP の移行に伴う課題
Compute Engine は Virtual Private Cloud（VPC）ネットワークで仮想化されたネットワーク スタックを使用するため、一般的な実装メカニズムはそのままでは機能しません。たとえば、VPC ネットワークは、構成されたルーティング トポロジに基づいて ARP リクエストを処理し、Gratuitous ARP フレームを無視します。加えて、OSPF や境界ゲートウェイ プロトコル（BGP）などの標準のルーティング プロトコルを使用して VPC ネットワーク ルーティング テーブルを直接変更することができません。
オーバーレイ ネットワークを使用すれば、ARP リクエストを使用した完全なレイヤ 2 通信と IP 引き継ぎを可能にする構成を作成できます。ただし、オーバーレイ ネットワークの設定は複雑なため、Compute Engine ネットワーク リソースの管理が難しくなります。このアプローチもこのソリューションの対象外です。代わりに、このソリューションは、ネイティブの Compute Engine ネットワーキング環境でフェイルオーバー シナリオを実装するための代替アプローチを提供します。
このソリューションでは、前述のユースケースの大部分を Compute Engine に移行する方法について説明します。
より具体的なユースケースについては、次のように詳しい手順がすでに公開されています。
- Windows Server フェイルオーバー クラスタリングを実行する
- Google Compute Engine で Microsoft SQL Server Always On 可用性グループを作成する
移行するユースケースの例
このソリューションでは、オンプレミス フローティング IP から Compute Engine に移行するための 4 つの異なる移行オプションについて説明します。
このユースケースでは、複雑なレイヤ 7 ヘッダーの照合と交換に応じて異なるバックエンドにトラフィックをルーティングする 2 つの内部 HAProxy サーバーを移行します。ルールが複雑なため、このサーバーのセットを内部負荷分散に置き換えることはできず、HTTP 負荷分散にも置き換えられません。次の図は、このユースケースの概要を示しています。
HAProxy サーバーは、keepalived ソフトウェアをオンプレミスで使用し、別の相互接続を使用して可用性をチェックし、2 つのサーバー間でフローティング IP をやり取りします。
このユースケースでは、以降のセクションで説明する 4 つのオプションすべてが、フローティング IP の有効なオンプレミス代替手段になります。ユースケースが複雑になるほど、適用可能なオプションの数が減る傾向があります。これらのオプションの説明に続いて、このソリューションでは、特定のユースケースに基づく推奨オプションのガイダンスを提供します。
次のセクションでは、このユースケース シナリオを Compute Engine に移行する方法について説明します。
Compute Engine を使用した実装
このセクションでは、オンプレミス シナリオを Compute Engine に移行するいくつかの方法について説明します。複雑さを軽減するために、前述のヘッダーベースの照合を使用する代わりに、すべてのリクエストが、最小バックエンド構成を使用した NGINX バックエンドの単一のグループに転送されます。
すべての例において、トラフィックは、HAProxy から自動スケーリング インスタンス グループに配置された Compute Engine バックエンドの 1 つのグループにルーティングされます。これらのバックエンドは、内部ロードバランサを使用してアクセスされます。構成例では、これらのバックエンドが 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）を持つ内部ロードバランサをこのインスタンス グループに接続します。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コマンドを使用してそのインスタンスに接続して、内部負荷分散 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: 内部負荷分散の使用
次の図に示すように、2 つの HAProxy サーバーを内部負荷分散の背後にあるマネージド インスタンス グループに配置し、内部負荷分散 IP を仮想 IP として使用することによって、オンプレミス シナリオを Compute Engine に実装できます。
オンプレミス設定との違い
内部負荷分散 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 がすべてのトラフィックを受け入れるのに対して、内部負荷分散では、転送が最大 5 つのポートに制限されます。
オプション 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ヘルスチェックを使用して、内部ロードバランサを複数の 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内部負荷分散を通して 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 の比較: 内部負荷分散
オプション 2 には、オプション 1 と比較して大きなメリットとデメリットがあります。
メリット:
トラフィック分散
インスタンスは 1 つしか存在しないため、オンプレミス マスター / スレーブ シナリオと同様に、すべてのトラフィックが 1 つのインスタンスに送られます。
コストの節約
2 つではなく 1 つの VM インスタンスを使用することによって、実装コストを半減させることができます。
シンプル
このソリューションは実装が容易で、オーバーヘッドがほとんどありません。
デメリット:
フェイルオーバー時間
ヘルスチェックでマシン障害が検出されてから、障害が発生したインスタンスを削除して再作成するのに少なくとも 1 分はかかりますが、もっと長い時間がかかることもあります。このプロセスには、内部負荷分散からインスタンスを削除するよりもはるかに長い時間がかかります。
ゾーン障害への対応
サイズが 1 のマネージド インスタンス グループは、ゾーン障害に対する耐性がありません。ゾーン障害に対応するには、サービスの失敗時の Stackdriver Monitoring アラートの追加を検討し、ゾーン障害の発生時に別のゾーンに手動でインスタンス グループを作成します。
オプション 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内部負荷分散 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 インスタンス プロセスを停止すると、インスタンスは少し遅れて同じ IP アドレスとインスタンス名で自動的に回復するはずです。
オプション 3: 優先順位が異なるルートを使用したフェイルオーバー
優先順位が異なる 2 つの Compute Engine ルートは、内部負荷分散を使用できない場合に、2 つのインスタンス間のトラフィック フェイルオーバーを可能にするもう 1 つの方法を提供します。
このセクションでは、2 つの VM インスタンスを作成して、静的サイズが 1 の自動修復マネージド インスタンス グループに配置し、システムが自動的に修復できるようにします。
この両方のインスタンスで IP 転送を有効にする必要があります。その後、インスタンスを作成してから、トラフィックを処理するための優先順位が異なる 2 つのルートを設定することによって、すべてのフローティング IP トラフィックをこの 2 つのインスタンスに振り向けます。
オプション 3 とオプション 1 の比較: 内部負荷分散
オプション 3 を使用すると、内部負荷分散を簡単に利用できないユースケースを移行できます。このオプションには、以下のような利点があります。
トラフィック分散
トラフィックは、常に、最も優先順位の低い VM インスタンスに流れます。この VM インスタンスが利用できない場合、トラフィックは次の最適ルートを使用します。このアーキテクチャは、特定の時間に 1 つのサーバーだけがアクティブなオンプレミス環境に似ています。
プロトコル
内部負荷分散は特定のプロトコルまたはポートのセットにしか適用されませんが、ルートは特定の宛先へのすべてのトラフィックに適用されます。
地域性
内部負荷分散はリージョン内でしか使用できませんが、ルートはグローバルに作成できます。
オプション 3 には、内部負荷分散を使用するオプション 1 と比較して次のようなデメリットがあります。
ヘルスチェック
オプション 3 を使用すると、2 つのルートのどちらにもヘルスチェックが接続されません。ルートは、基礎となる VM サービスの正常性に関係なく使用されます。サービスが正常でない場合でも、トラフィックがインスタンスに送られます。このようなインスタンスに自動修復ポリシーを付加すると、特定の異常期間の経過後にインスタンスが強制終了されますが、それらのインスタンスが再起動されると、サービスが起動する前でもトラフィックが再開されるため、異常なインスタンスがまだトラフィックを処理中の場合または再起動中にサービスエラーが発生する可能性があります。
フェイルオーバー時間
VM インスタンスを削除または停止すると、ルートが自動的に取り消されます。ただし、ヘルスチェックが存在しないため、インスタンスが利用可能な間は、ルートが使用され続けます。加えて、インスタンスの停止には時間がかかるため、フェイルオーバー時間は、内部負荷分散アプローチよりかなり長くなります。
フローティング 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 の違いの比較: 内部負荷分散
内部負荷分散を使用する場合とは対照的に、オプション 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: 内部負荷分散です。これは、VM インスタンスがステートレスなためで、アクティブ-アクティブ シナリオで簡単に動作できます。加えて、Compute Engine のヘルスチェックを使用できます。他のユースケースでは、オプション 1 が最適なオプションではない場合があります。
前述の各オプションのメリットとデメリットに加えて、次のディシジョン ツリーを使用すると、実装スキームの決定に役立ちます。
可用性と信頼性の高いアプリケーションは、水平スケーリング アーキテクチャを使用して、単一ノードの障害の影響を最小限に抑えて Compute Engine に実装するのが最善です。フローティング IP を使用した 2 つのサーバーなど、一般的なオンプレミス シナリオを移行するのは困難です。これは、このようなシナリオを Compute Engine で再現することができないためです。前述したように、仮想ルーティング インフラストラクチャの特性上、Gratuitous ARP を使用して数秒間のうちに別々のマシン間で IP アドレスを移動することはできません。
内部負荷分散を使用すれば、さまざまなユースケースを簡単かつ確実に Compute Engine に移行できます。内部ロードバランサを使用できない場合は、複雑なオーバーレイ ルーティング メカニズムを必要としない他のいくつかのオプションを実装できます。
