リージョン永続ディスクを使用した復元可能なコールド ウェブサーバーのデプロイ

Last reviewed 2021-08-04 UTC

---

このドキュメントでは、マネージド インスタンス グループとリージョン永続ディスクを使用して、ウェブサーバーのコールド フェイルオーバー トポロジをデプロイする方法について説明します。このドキュメントは、運用チームと管理チームで作業するアーキテクトと担当者を対象としています。

データを格納するリージョン永続ディスクを持つ単一の VM を実行する、マネージド インスタンス グループを作成します。次の図に示すように、外部アプリケーション ロードバランサは、マネージド インスタンス グループで実行されている VM にユーザーを転送します。

インスタンスに障害が発生した場合、マネージド インスタンス グループが同じゾーンに VM の再作成を試みます。ゾーンレベルで障害が発生した場合、Cloud Monitoring などから問題の発生を通知して、別のマネージド ゾーンに別のマネージド インスタンス グループを手動で作成できます。どちらのフェイルオーバー シナリオでも、プラットフォームはインスタンス グループ内の新しい VM にリージョン永続ディスクをアタッチします。

このドキュメントでは、VM またはロードバランサの外部 IP アドレスを使用して、ウェブサーバーの基本ページを表示します。このアプローチでは、ドメイン名が登録されておらず、DNS の変更が不要な場合に、コールド フェイルオーバーのパターンをテストできます。本番環境では、ロードバランサに割り当てられた外部 IP アドレスに解決される Cloud DNS ゾーンとレコードを作成して構成します。

このシナリオでは、一定レベルのデータ保護を維持しつつ、複数の VM を実行する費用のバランスを取ります。リージョン内の 2 つのゾーン間でデータの継続的なレプリケーションを実施するリージョン永続ディスクを使用すると、費用が増大しますが、ゾーンレベルで障害が発生した場合のデータ損失のリスクは最小限に抑えられます。ストレージの費用を削減するには、代わりに永続ディスクのスナップショットを使用して復元可能なコールド ウェブサーバーをデプロイすることを検討してください。

次の表は、リージョン永続ディスクまたは永続ディスクのスナップショットを使用する復元可能なコールド アプローチのデータ保護オプションの大まかな違いをまとめたものです。詳細については、永続ディスクを使用した高可用性オプションをご覧ください。

	リージョン永続ディスク	永続ディスクのスナップショット
データ損失 - リカバリ ポイント目標（RPO）	単一障害（ゾーンの継続的なサービス停止またはネットワークの切断など）の場合は 0。	最後のスナップショット取得（通常、1 時間以上）以降のデータ。 データ損失の可能性は、スナップショットの取得頻度を制御するスナップショット スケジュールによって異なります。
目標復旧時間（RTO）	新しい VM のデプロイ時間とリージョン永続ディスクの再アタッチのかかる秒数。	新しい VM のデプロイ時間、および最新のスナップショットから新しい永続ディスクを作成する時間。 ディスクの作成時間は、スナップショットのサイズによって異なり、数十分から数時間かかることがあります。
費用	リージョン永続ディスクが別のゾーンに継続的に複製されると、ストレージ費用が倍増します。	費用は、消費したスナップショットの容量に対してのみ発生します。
	詳細については、ディスクとイメージの料金をご覧ください。

目標

• マネージド インスタンス グループを作成し、リージョン永続ディスクを使用して VM を実行する。
• インスタンス テンプレートと起動スクリプトを作成する。
• 外部アプリケーション ロードバランサを作成して構成する。
• 代わりのマネージド インスタンス グループで、コールド ウェブサーバーのフェイルオーバーをテストする。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

• Compute Engine
• ネットワーキング
• Persistent Disk

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。 新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

3. Google Cloud プロジェクトで課金が有効になっていることを確認します。

4. Compute Engine API を有効にします。

   API を有効にする

5. Google Cloud CLI をインストールします。

6. gcloud CLI を初期化するには:

   gcloud init

7. Google Cloud Console の [プロジェクト セレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   プロジェクト セレクタに移動

8. Google Cloud プロジェクトで課金が有効になっていることを確認します。

9. Compute Engine API を有効にします。

   API を有効にする

10. Google Cloud CLI をインストールします。

11. gcloud CLI を初期化するには:

    gcloud init

Google Cloud CLI をインストールせずに、Google Cloud コンソールで Google Cloud CLI を実行できます。Google Cloud コンソールで gcloud CLI を実行するには、Cloud Shell を使用します。

環境を準備する

このセクションでは、リソース名とロケーションの変数を定義します。これらの変数は、リソースをデプロイするときに Google Cloud CLI コマンドによって使用されます。

このドキュメントを通じて、特に断りのない限り、Cloud Shell またはローカル開発環境ですべてのコマンドを入力します。

1. PROJECT_ID は実際のプロジェクト ID に置き換えます。必要に応じて、リソースに独自の名前の接尾辞を指定します（app など）。

   リージョン（us-central1 など）と、そのリージョン内の 2 つのゾーン（us-central1-a や us-central1-f など）を指定します。これらのゾーンにより、リージョン永続ディスクと最初のマネージド インスタンス グループがデプロイされる場所、必要に応じて手動でフェイルオーバーできる場所を定義します。

   PROJECT_ID=PROJECT_ID
   NAME_SUFFIX=app
   REGION=us-central1
   ZONE1=us-central1-a
   ZONE2=us-central1-f
   

VPC とサブネットの作成

VM へのネットワーク アクセスを許可するには、Virtual Private Cloud（VPC）とサブネットを作成します。マネージド インスタンス グループは、1 つのリージョン内にある複数のゾーン間で動作するため、作成されるサブネットは 1 つだけです。お客様の環境で使用されている IP アドレスの範囲を管理するためのカスタム サブネット モードの利点については、カスタムモードの VPC ネットワークを使用するをご覧ください。

1. カスタム サブネット モードで VPC を作成します。

   gcloud compute networks create network-$NAME_SUFFIX \
       --subnet-mode=custom
   

   Cloud Shell プロンプトが表示された場合は、この最初のリクエストを承認して API 呼び出しを行います。

2. 新しい VPC にサブネットを作成します。ネットワーク範囲に適した独自のアドレス範囲（10.1.0.0/20 など）を定義します。

   gcloud compute networks subnets create subnet-$NAME_SUFFIX-$REGION \
       --network=network-$NAME_SUFFIX \
       --range=10.1.0.0/20 \
       --region=$REGION
   

ファイアウォール ルールの作成

1. ロードバランサおよびマネージド インスタンス グループ用のウェブ トラフィックとヘルスチェックを許可するファイアウォール ルールを作成します。

   gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:80 \
       --source-ranges=0.0.0.0/0 \
       --target-tags=http-server
   
   gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=allow-health-check \
       --rules=tcp:80
   

   HTTP ルールでは、http-serverタグが適用されている VM や、0.0.0.0/0 範囲を使用している送信元からのトラフィックを許可します。ヘルスチェック ルールでは、Google Cloud のデフォルトが設定されており、プラットフォームがリソースの健全性を正しくチェックできるようになっています。

2. ベース VM イメージの初期設定で SSH トラフィックを許可するには、--source-rangeパラメータを使用してファイアウォール ルールを環境に合わせて適用します。組織で使用するソース範囲を決定するには、ネットワーク チームの協力が必要な場合があります。

   注意: すべてのトラフィックを許可するような広い 0.0.0.0/0 範囲の使用はおすすめしません。トラフィックを単一の IP アドレスに限定するには、/32 ネットワーク マスク（35.230.62.163/32 など）を使用します。

   IP_ADDRESS_SCOPE を独自の IP アドレス スコープに置き換えます。

   gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \
       --network=network-$NAME_SUFFIX \
       --direction=INGRESS \
       --priority=1000 \
       --action=ALLOW \
       --rules=tcp:22 \
       --source-ranges=IP_ADDRESS_SCOPE
   

3. ファイアウォール ルールを作成したら、3 つのルールが追加されていることを確認します。

   gcloud compute firewall-rules list \
       --project=$PROJECT_ID \
       --filter="NETWORK=network-$NAME_SUFFIX"
   

   次の出力例は、3 つのルールが正しく作成されたことを示しています。

   NAME                    NETWORK      DIRECTION  PRIORITY  ALLOW
   allow-health-check-app  network-app  INGRESS    1000      tcp:80
   allow-http-app          network-app  INGRESS    1000      tcp:80
   allow-ssh-app           network-app  INGRESS    1000      tcp:22
   

リージョン永続ディスクと VM の作成

リージョン永続ディスクでは、リージョン内の 2 つのゾーン間でデータを継続的に複製できます。リージョン永続ディスクと同じ 2 つのゾーンで実行されるマネージド インスタンス グループは、ディスクを VM にアタッチできます。

注: このドキュメントでは、ベース VM とイメージを手動で作成して構成します。実際のデプロイでは、既存のデプロイツールとパイプラインを使用して、このプロセスを可能な限り自動化します。詳細については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。

1. 10 GiB の SSD を作成します。ストレージの要件とそれに関連する費用（使用される容量ではなくプロビジョニングされる容量）を把握します。詳細については、永続ディスクの料金をご覧ください。

   gcloud compute disks create disk-$NAME_SUFFIX \
       --region $REGION \
       --replica-zones $ZONE1,$ZONE2 \
       --size=10 \
       --type=pd-ssd
   

2. リージョン永続ディスクがアタッチされたベース VM を作成します。

   gcloud compute instances create vm-base-$NAME_SUFFIX \
       --zone=$ZONE1 \
       --machine-type=n1-standard-1 \
       --subnet=subnet-$NAME_SUFFIX-$REGION \
       --tags=http-server \
       --image=debian-10-buster-v20210721 \
       --image-project=debian-cloud \
       --boot-disk-size=10GB \
       --boot-disk-type=pd-balanced \
       --boot-disk-device-name=vm-base-$NAME_SUFFIX \
       --disk=mode=rw,name=disk-$NAME_SUFFIX,device-name=disk-$NAME_SUFFIX,scope=regional
   

   このドキュメントの冒頭で定義したパラメータを使用して VM に名前を付け、正しいサブネットに接続します。名前はブートディスクとデータディスクのパラメータからも割り当てられます。

3. シンプルなウェブサイトをインストールして構成するには、まず SSH を使用してベース VM に接続します。

   gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE1
   

4. VM への SSH セッションで、任意のエディタで VM を構成するスクリプトを作成します。次の例では、Nano をエディタとして使用しています。

   nano configure-vm.sh
   

   このファイルに次の構成スクリプトを貼り付けます。このドキュメントの冒頭で設定した値（app など）と一致するように NAME_SUFFIX 変数を更新します。

   #!/bin/bash
   
   NAME_SUFFIX=app
   
   # Create directory for the basic website files
   sudo mkdir -p /var/www/example.com
   sudo chmod a+w /var/www/example.com
   sudo chown -R www-data: /var/www/example.com
   
   # Find the disk name, then format and mount it
   DISK_NAME="google-disk-$NAME_SUFFIX"
   DISK_PATH="$(find /dev/disk/by-id -name "${DISK_NAME}" | xargs -I '{}' readlink -f '{}')"
   
   sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
   sudo mount -o discard,defaults $DISK_PATH /var/www/example.com
   
   # Install Apache
   sudo apt-get update && sudo apt-get -y install apache2
   
   # Write out a basic HTML file to the mounted persistent disk
   sudo tee -a /var/www/example.com/index.html >/dev/null <<'EOF'
   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   EOF
   
   # Write out an Apache configuration file
   sudo tee -a /etc/apache2/sites-available/example.com.conf >/dev/null <<'EOF'
   <VirtualHost *:80>
           ServerName www.example.com
   
           ServerAdmin webmaster@localhost
           DocumentRoot /var/www/example.com
   
           ErrorLog ${APACHE_LOG_DIR}/error.log
           CustomLog ${APACHE_LOG_DIR}/access.log combined
   </VirtualHost>
   EOF
   
   # Enable the Apache configuration file and reload service
   sudo a2dissite 000-default
   sudo a2ensite example.com.conf
   sudo systemctl reload apache2
   

5. ファイルを書き出してエディタを終了します。たとえば、Nano では、Ctrl-O を使用してファイルを書き出してから Ctrl-X で終了します。

6. 構成スクリプトを実行可能にして、実行します。

   chmod +x configure-vm.sh
   ./configure-vm.sh
   

7. VM への SSH セッションを終了します。

   exit
   

8. VM の IP アドレスを取得し、curl を使用して基本的なウェブページを表示します。

   curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX \
       --zone $ZONE1 \
       --format="value(networkInterfaces.accessConfigs.[0].natIP)")
   

   次の出力例に示すように、基本のウェブサイトが返されます。

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

   このステップでは、Apache が正しく構成され、アタッチされたリージョン永続ディスクからページが読み込まれることを確認します。以降のセクションでは、このベース VM を使用してイメージを作成し、起動スクリプトでインスタンス テンプレートを構成します。

VM イメージとインスタンス テンプレートの作成

追加の構成を必要とせずに自動的にデプロイ可能な同一の VM を作成するには、カスタム VM イメージを使用します。このイメージでは、OS と Apache の構成がキャプチャされます。このイメージは、次の手順でマネージド インスタンス グループに作成する各 VM によって使用されます。

1. イメージを作成する前に、VM を停止する必要があります。

   gcloud compute instances stop vm-base-$NAME_SUFFIX --zone=$ZONE1
   

2. 次に、前のセクションで構成したベース VM のイメージを作成します。

   gcloud compute images create image-$NAME_SUFFIX \
       --source-disk=vm-base-$NAME_SUFFIX \
       --source-disk-zone=$ZONE1 \
       --storage-location=$REGION
   

3. 各 VM の構成を定義するインスタンス テンプレートを作成します。

   gcloud compute instance-templates create template-$NAME_SUFFIX \
       --machine-type=n1-standard-1 \
       --subnet=projects/$PROJECT_ID/regions/$REGION/subnetworks/subnet-$NAME_SUFFIX-$REGION \
       --tags=http-server \
       --image=image-$NAME_SUFFIX \
       --region=$REGION \
       --metadata=^,@^startup-script=\!\#\ /bin/bash$'\n'echo\ UUID=\`blkid\ -s\ UUID\ -o\ value\ /dev/sdb\`\ /var/www/example.com\ ext4\ discard,defaults,nofail\ 0\ 2\ \|\ tee\ -a\ /etc/fstab$'\n'mount\ -a
   

   前の手順で作成されたイメージが各 VM のソースとして定義されます。また、リージョン永続ディスクをマウントする起動スクリプトも定義されます。

マネージド インスタンス グループの作成

マネージド インスタンス グループが VM を実行します。このマネージド インスタンス グループは定義されたゾーンで実行され、VM の状態をモニタリングします。インスタンスが停止し、VM が動作しなくなった場合、マネージド インスタンス グループは、同じゾーン内に別の VM を作成してリージョン永続ディスクをアタッチしようとします。ゾーンレベルで障害が発生した場合は、コールド フェイルオーバーを手動で実行し、別のゾーンに別のマネージド インスタンス グループを作成する必要があります。同じカスタム イメージとインスタンス テンプレートを使用して、同じ方法で VM が自動的に構成されます。

1. マネージド インスタンス グループ内の VM をモニタリングするヘルスチェックを作成します。このヘルスチェックは、VM がポート 80 で応答していることを確認します。独自のアプリケーションの場合は、適切なポートをモニタリングして VM の状態を確認します。

   gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX --port 80
   

2. 前の手順で作成したインスタンス テンプレートを使用するマネージド インスタンス グループを作成します（最初は、ゼロ個の VM から始めます）。

   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE1 \
       --base-instance-name=instance-vm-$NAME_SUFFIX \
       --template=template-$NAME_SUFFIX \
       --size=0 \
       --zone=$ZONE1 \
       --health-check=http-basic-check-$NAME_SUFFIX
   

3. マネージド インスタンス グループで単一の VM を作成し、リージョン永続ディスクをアタッチします。この VM に障害が発生すると、マネージド インスタンス グループは同じゾーンに VM を再作成し、永続ディスクを再アタッチしようとします。

   gcloud compute instance-groups managed create-instance instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance instance-vm-$NAME_SUFFIX \
       --zone=$ZONE1\
       --stateful-disk device-name=disk-$NAME_SUFFIX,source=projects/$PROJECT_ID/regions/$REGION/disks/disk-$NAME_SUFFIX
   

   注: マネージド インスタンス グループで複数の VM を同時に実行することはできません。リージョン永続ディスクは、同時に 1 つの VM にのみアタッチできます。

この復元可能コールド アプリケーションのシナリオでは、マネージド インスタンス グループで実行する VM の数を増やすための自動スケーリング ルールを作成しないでください。

ロードバランサの作成と構成

ユーザーがお客様のウェブサイトにアクセスできるようにするには、マネージド インスタンス グループで実行されている VM へのトラフィックを許可する必要があります。また、マネージド インスタンス グループにゾーン障害がある場合、トラフィックを新しい VM に自動的にリダイレクトする必要もあります。

次のセクションでは、80 番ポートの HTTP トラフィック用のバックエンド サービスを備えた外部ロードバランサを作成し、前のステップで作成したヘルスチェックを使用して、外部 IP アドレスをバックエンド サービスにマッピングします。

詳細については、シンプルな外部 HTTP ロードバランサの設定方法をご覧ください。

1. アプリケーション用のロードバランサを作成して構成します

   # Configure port rules for HTTP port 80
   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$ZONE1 \
       --named-ports http:80 \
       --zone $ZONE1
   
   # Create a backend service and add the managed instance group to it
   gcloud compute backend-services create \
       web-backend-service-$NAME_SUFFIX \
       --protocol=HTTP \
       --port-name=http \
       --health-checks=http-basic-check-$NAME_SUFFIX \
       --global
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance-group-zone=$ZONE1 \
       --global
   
   # Create a URL map for the backend service
   gcloud compute url-maps create web-map-http-$NAME_SUFFIX \
       --default-service web-backend-service-$NAME_SUFFIX
   
   # Configure forwarding for the HTTP traffic
   gcloud compute target-http-proxies create \
       http-lb-proxy-$NAME_SUFFIX \
       --url-map web-map-http-$NAME_SUFFIX
   
   gcloud compute forwarding-rules create \
       http-content-rule-$NAME_SUFFIX \
       --global \
       --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \
       --ports=80
   

2. ウェブ トラフィックの転送ルールの IP アドレスを取得します。

   IP_ADDRESS=$(gcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \
       --global \
       --format="value(IPAddress)")
   

3. curl を使用するか、ウェブブラウザを開いて、前のステップで作成したロードバランサの IP アドレスを使用してウェブサイトを表示します。

   curl $IP_ADDRESS
   

   ロードバランサがデプロイを完了し、バックエンドにトラフィックが正しく転送されるまでに数分かかります。ロードバランサがまだデプロイ中の場合は、HTTP 404 または 502 エラーが返されます。必要に応じて、数分待ってからもう一度ウェブサイトにアクセスしてください。

   次の出力例に示すように、基本のウェブサイトが返されます。

   <!doctype html>
   
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

ゾーン障害と復旧をシミュレーションする

ゾーンレベルで障害をシミュレーションする前に、リソースのデプロイメントを確認します。次の図に示すように、すべてのリソースが環境をサポートするために作成されました。

• 基本ウェブサイトを格納する 1 つの VM にアタッチされたリージョン永続ディスクを使用して、マネージド インスタンス グループで実行中の 1 つの VM。
• 起動スクリプトがインスタンス テンプレートに適用されるため、マネージド インスタンス グループで作成された VM によって、リージョン永続ディスクがマウントされます。
• ヘルスチェックでは、マネージド インスタンス グループ内の VM のステータスがモニタリングされます。
• 外部アプリケーション ロードバランサは、マネージド インスタンス グループで実行されている VM にユーザーを転送します。
• VM に障害が発生すると、マネージド インスタンス グループは同じゾーンで VM の再作成を試みます。ゾーンレベルで障害が発生した場合は、別の作業ゾーンに代替のマネージド インスタンス グループを手動で作成する必要があります。

本番環境では、Cloud Monitoring または他のモニタリング ソリューションを使用して、問題発生時にアラートが表示されることがあります。このアラートは、別の作業ゾーンで代替マネージド インスタンス グループを手動で作成する前に、障害の範囲を理解するように促します。別の方法としては、モニタリング ソリューションを使用して、マネージド インスタンス グループの障害に自動的に対応する方法があります。

ユーザーまたはモニタリング ソリューションで、フェイルオーバーが最適なアクションと判断されると、代替マネージド インスタンス グループが作成されます。このドキュメントでは、この代替リソースを手動で作成します。

1. ゾーンレベルでの障害をシミュレートするには、ロードバランサのバックエンドとマネージド インスタンス グループを削除します。

   gcloud compute backend-services remove-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE1 \
       --instance-group-zone=$ZONE1 \
       --global
   
   gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE1 \
         --zone=$ZONE1
   

   プロンプトが表示されたら、マネージド インスタンス グループの削除リクエストを確定します。

   本番環境では、モニタリング システムによってコールド フェイルオーバーのアクションを直ちに促すアラートが生成されます。

2. curl またはウェブブラウザを再度使用して、ロードバランサの IP アドレスにアクセスします。

   curl $IP_ADDRESS --max-time 5
   

   ロードバランサ用の正常なターゲットがないため、curl リクエストは失敗します。

3. コールド フェイルオーバーをシミュレートするには、別のゾーンにマネージド インスタンス グループを作成します。

   gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$ZONE2 \
       --base-instance-name=instance-vm-$NAME_SUFFIX \
       --template=template-$NAME_SUFFIX \
       --size=0 \
       --zone=$ZONE2 \
       --health-check=http-basic-check-$NAME_SUFFIX
   
   gcloud compute instance-groups managed create-instance instance-group-$NAME_SUFFIX-$ZONE2 \
       --instance instance-vm-$NAME_SUFFIX \
       --zone=$ZONE2 \
       --stateful-disk device-name=disk-$NAME_SUFFIX,source=projects/$PROJECT_ID/regions/$REGION/disks/disk-$NAME_SUFFIX
   

   VM イメージ、インスタンス テンプレート、リージョン永続ディスクによって、アプリケーション インスタンスの構成がすべて保持されます。

4. ロードバランサを更新して、新しいマネージド インスタンス グループと VM を追加します。

   gcloud compute instance-groups set-named-ports \
       instance-group-$NAME_SUFFIX-$ZONE2 \
       --named-ports http:80 \
       --zone $ZONE2
   
   gcloud compute backend-services add-backend \
       web-backend-service-$NAME_SUFFIX \
       --instance-group=instance-group-$NAME_SUFFIX-$ZONE2 \
       --instance-group-zone=$ZONE2 \
       --global
   

5. curl またはウェブブラウザをもう一度使用して、マネージド インスタンス グループで実行されている VM にトラフィックを転送するロードバランサの IP アドレスにアクセスします。

   curl $IP_ADDRESS
   

   VM がリージョン永続ディスクのデプロイとアタッチを完了するまでに数分かかります。必要に応じて、数分待ってからもう一度ウェブサイトにアクセスしてください。

   次のレスポンス例は、再作成された VM で正しく動作しているウェブページを示しています。

   <!doctype html>
   <html lang=en>
   <head>
   <meta charset=utf-8>
       <title>HA / DR example</title>
   </head>
   <body>
       <p>Welcome to a test web server with regional persistent disks!</p>
   </body>
   </html>
   

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

このドキュメントで作成した個別のリソースを削除するには、次の手順を行います。

1. ロードバランサの構成を削除します。

   gcloud compute forwarding-rules delete \
       http-content-rule-$NAME_SUFFIX --global --quiet
   
   gcloud compute target-http-proxies delete \
       http-lb-proxy-$NAME_SUFFIX --quiet
   
   gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet
   
   gcloud compute backend-services delete \
       web-backend-service-$NAME_SUFFIX --global --quiet
   

2. マネージド インスタンス グループとヘルスチェックを削除します。

   gcloud compute instance-groups managed delete instance-group-$NAME_SUFFIX-$ZONE2 \
       --zone=$ZONE2 --quiet
   
   gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet
   

3. インスタンス テンプレート、イメージ、ベース VM、永続ディスクを削除します。

   gcloud compute instance-templates delete template-$NAME_SUFFIX --quiet
   
   gcloud compute images delete image-$NAME_SUFFIX --quiet
   
   gcloud compute instances delete vm-base-$NAME_SUFFIX --zone=$ZONE1 --quiet
   
   gcloud compute disks delete disk-$NAME_SUFFIX --region=$REGION --quiet
   

4. ファイアウォール ルールを削除します。

   gcloud compute firewall-rules delete allow-health-check-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete allow-ssh-$NAME_SUFFIX --quiet
   
   gcloud compute firewall-rules delete allow-http-$NAME_SUFFIX --quiet
   

5. 静的外部 IP アドレス、サブネット、VPC を削除します。

   gcloud compute networks subnets delete \
       subnet-$NAME_SUFFIX-$REGION --region=$REGION --quiet
   
   gcloud compute networks delete network-$NAME_SUFFIX --quiet
   

次のステップ

• ストレージ費用を削減する別の方法について、永続ディスクのスナップショットを使用して、復元可能なウェブサーバーをデプロイするを読む。
• 独自のアプリケーションに最適なアプローチや、使用する復旧メソッドを決定する方法について、障害復旧計画ガイドで確認する。
• コールド フェイルオーバーやホット フェイルオーバーなど、アプリケーションのその他のパターンについて、アプリケーションの障害復旧シナリオで確認する。
• スケールと可用性を扱うその他の方法について、スケーラブルで復元性の高いアプリのパターンで確認する。
• Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud Architecture Center を確認する。