Cloud DNS ヘルスチェックを使用したリージョン外部エンドポイントのマルチリージョンフェイルオーバー

1. はじめに

Cloud DNS サービスは、高パフォーマンスで復元力のあるグローバルドメインネームシステム（DNS）ソリューションを提供します。これにより、セルフマネージド DNS インフラストラクチャを必要とせずに、ゾーンとレコードを公開できます。

最も重要なのは、Cloud DNS が外部エンドポイントのルーティングポリシー内でヘルスチェックと自動フェイルオーバー機能をサポートしていることです。ただし、これらの外部エンドポイントのヘルスチェックはパブリックゾーンでのみ使用でき、エンドポイント自体はインターネット経由で一般公開されている必要があります。

学習内容

非マネージドインスタンスグループを使用してリージョン外部アプリケーションロードバランサを作成する方法。
外部 DNS ルーティング用に Cloud DNS ヘルスチェックを構成する方法。
フェイルオーバールーティングポリシーを作成する方法。

必要なもの

DNS に関する基本的な知識。
Google Compute Engine に関する基本的な知識。
アプリケーションロードバランサに関する基本的な知識。
オーナー権限を持つ Google Cloud プロジェクト
所有している一般公開ドメイン。このドメインに対して Cloud DNS 一般公開ゾーンを作成できます。
現在、Google Cloud プロジェクト内では、次の組織のポリシーは適用されていません。シールドされた VM とインターネットネットワークエンドポイントグループ。

2. Codelab のトポロジ

この Codelab では、外部エンドポイントの Cloud DNS ヘルスチェックを使用して、プライマリロードバランサのバックエンドが異常になった場合に、トラフィックをバックアップリージョン外部アプリケーションロードバランサに再ルーティングします。

2 つのリージョンにウェブサイトを構築します。各リージョンは、外部アプリケーションロードバランサによってフロントエンド処理されます。次に、フェイルオーバールーティングポリシーを使用して Cloud DNS ヘルスチェックを構成します。

3. 設定と要件

セルフペース型の環境設定

Google Cloud Console にログインして、プロジェクトを新規作成するか、既存のプロジェクトを再利用します。Gmail アカウントも Google Workspace アカウントもまだお持ちでない場合は、アカウントを作成してください。

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。いつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常は、この内容を意識する必要はありません。ほとんどの Codelab では、プロジェクト ID（通常は PROJECT_ID と識別されます）を参照する必要があります。生成された ID が好みではない場合は、ランダムに別の ID を生成できます。または、ご自身で試して、利用可能かどうかを確認することもできます。このステップ以降は変更できず、プロジェクトを通して同じ ID になります。
なお、3 つ目の値として、一部の API が使用するプロジェクト番号があります。これら 3 つの値について詳しくは、こちらのドキュメントをご覧ください。

次に、Cloud のリソースや API を使用するために、Cloud コンソールで課金を有効にする必要があります。この Codelab の操作をすべて行って、費用が生じたとしても、少額です。このチュートリアルの終了後に請求が発生しないようにリソースをシャットダウンするには、作成したリソースを削除するか、プロジェクトを削除します。Google Cloud の新規ユーザーは、300 米ドル分の無料トライアルプログラムをご利用いただけます。

Cloud Shell を起動する

Google Cloud はノートパソコンからリモートで操作できますが、この Codelab では、Google Cloud Shell（Cloud 上で動作するコマンドライン環境）を使用します。

Google Cloud Console で、右上のツールバーにある Cloud Shell アイコンをクリックします。

Cloud Shell をアクティブにする

プロビジョニングと環境への接続にはそれほど時間はかかりません。完了すると、次のように表示されます。

環境が接続されていることを示す Google Cloud Shell ターミナルのスクリーンショット

この仮想マシンには、必要な開発ツールがすべて用意されています。永続的なホームディレクトリが 5 GB 用意されており、Google Cloud で稼働します。そのため、ネットワークのパフォーマンスと認証機能が大幅に向上しています。この Codelab での作業はすべて、ブラウザ内から実行できます。インストールは不要です。

4. 始める前に

API を有効にする

Cloud Shell で、プロジェクトが設定されていることを確認し、変数を構成します。

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]

# Define variables for regions and the domain
export REGION_A=us-central1
export REGION_B=us-west1
export DNS_ZONE=dnscodelab-zone
Export DNS_DOMAIN=gcp.<yourpublicdomain>.com
echo $projectid
echo $REGION_A
echo $REGION_B
echo $DNS_ZONE
echo $DNS_DOMAIN

必要なサービスをすべて有効にする

gcloud services enable compute.googleapis.com 
gcloud services enable dns.googleapis.com

5. Cloud Load Balancing インフラストラクチャを作成する

このセクションでは、プライマリロードバランサとバックアップロードバランサをサポートするために、2 つの異なるリージョンに必要な VPC、サブネット、ファイアウォールルール、VM、非マネージドインスタンスグループを作成します。

VPC ネットワーク

Cloud Shell から

gcloud compute networks create external-lb-vpc --subnet-mode=custom

バックエンドウェブサーバーをホストするために、REGION_A（プライマリ）と REGION_B（バックアップ）に 2 つのサブネットを作成します。

サブネットを作成する

Cloud Shell から

gcloud compute networks subnets create subnet-a --network=external-lb-vpc --region=$REGION_A --range=10.10.1.0/24

gcloud compute networks subnets create subnet-b --network=external-lb-vpc --region=$REGION_B --range=10.20.1.0/24

後で作成するリージョン外部アプリケーションロードバランサごとに、各リージョンにプロキシ専用サブネットを作成します。

この専用のプロキシ専用サブネットは、external-lb-vpc ネットワークの同じリージョン内にデプロイされたすべての Envoy ベースのリージョンロードバランサの必須要件です。これらのプロキシは、クライアントの接続を効果的に終了し、バックエンドサービスへの新しい接続を確立します。

Cloud Shell から

gcloud compute networks subnets create proxy-only-subnet-a \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_A \
--network=external-lb-vpc \
--range=10.129.0.0/23

gcloud compute networks subnets create proxy-only-subnet-b \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_B \
--network=external-lb-vpc \
--range=10.130.0.0/23

ネットワークファイアウォールルールを作成する

fw-allow-health-check. ロードバランスされているインスタンスに適用される上り（内向き）ルール。Google Cloud ヘルスチェックシステム（130.211.0.0/22 と 35.191.0.0/16）からのすべての TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォールルールが適用される VM を識別します。

fw-allow-proxies。ロードバランスされているインスタンスに適用される上り（内向き）ルール。リージョン外部アプリケーションロードバランサが管理するプロキシからポート 80 への TCP トラフィックを許可します。この例では、ターゲットタグ load-balanced-backend を使用して、ファイアウォールルールが適用される VM を識別します。

Cloud Shell から

gcloud compute firewall-rules create fw-allow-health-check \
    --network=external-lb-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
gcloud compute firewall-rules create fw-allow-proxies \
  --network=external-lb-vpc \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23,10.130.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80

IAP に VM インスタンスへの接続を許可するには、次のファイアウォールルールを作成します。

IAP を使用してアクセス可能にするすべての VM インスタンスに適用されます。
IP 範囲 35.235.240.0/20 からの上り（内向き）トラフィックを許可します。この範囲には、IAP が TCP 転送に使用するすべての IP アドレスが含まれています。

Cloud Shell から

gcloud compute firewall-rules create allow-ssh \
    --allow tcp:22 --network external-lb-vpc \
    --source-ranges 35.235.240.0/20  \
    --description "SSH with IAP" \
    --target-tags=allow-ssh

6. Cloud NAT と Cloud Router を作成する

プライベート VM がインターネットからパッケージをダウンロードしてインストールできるようにするには、両方のリージョンに Cloud NAT ゲートウェイが必要です。

ウェブサーバー VM は、Apache ウェブサーバーをダウンロードしてインストールする必要があります。
クライアント VM は、テストに使用する dnsutils パッケージをダウンロードしてインストールする必要があります。

各 Cloud NAT ゲートウェイは、1 つの VPC ネットワーク、リージョン、Cloud Router に関連付けられます。そのため、NAT ゲートウェイを作成する前に、各リージョンに Cloud Router を作成する必要があります。

クラウドルーターを作成する

Cloud Shell から

gcloud compute routers create "$REGION_A-cloudrouter" \
--region $REGION_A --network=external-lb-vpc --asn=65501

gcloud compute routers create "$REGION_B-cloudrouter" \
--region $REGION_B --network=external-lb-vpc --asn=65501

NAT ゲートウェイを作成する

Cloud Shell から

gcloud compute routers nats create "$REGION_A-nat-gw" \
--router="$REGION_A-cloudrouter" \
--router-region=$REGION_A \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

gcloud compute routers nats create "$REGION_B-nat-gw" \
--router="$REGION_B-cloudrouter" \
--router-region=$REGION_B \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

バックエンド VM と非マネージドインスタンスグループを作成する

各リージョンに VM を作成し、ウェブサーバー（Apache など）をインストールします。

Cloud Shell から

# Primary (Region A)
gcloud compute instances create vm-a \
--zone=$REGION_A-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-a \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_A Primary Backend |\
tee /var/www/html/index.html
systemctl restart apache2'


# Backup (Region B)
gcloud compute instances create vm-b \
--zone=$REGION_B-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-b \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_B Backup Backend |\
tee /var/www/html/index.html
systemctl restart apache2'

非マネージドインスタンスグループを作成し、リージョンごとに VM インスタンスを追加します。

Cloud Shell から

# Primary (Region A)
gcloud compute instance-groups unmanaged create ig-a --zone=$REGION_A-a

gcloud compute instance-groups unmanaged add-instances ig-a --zone=$REGION_A-a --instances=vm-a

# Backup (Region B)
gcloud compute instance-groups unmanaged create ig-b --zone=$REGION_B-a

gcloud compute instance-groups unmanaged add-instances ig-b --zone=$REGION_B-a --instances=vm-b

7. リージョン外部アプリケーションロードバランサを構成する

REGION_A（プライマリ）と REGION_B（バックアップ）の両方に完全なリージョン外部アプリケーションロードバランサを構成します。

ヘルスチェックとバックエンドサービスを作成する

リージョン外部アプリケーションロードバランサは Envoy ベースであり、リージョンヘルスチェックを構成する必要があります。

HTTP ヘルスチェックを作成します（ロードバランサがインスタンスの健全性を確認するために使用します）。

Cloud Shell で次の処理を行います。

gcloud compute health-checks create http http-lb-hc-primary-region \
--port 80 \
--region=$REGION_A

gcloud compute health-checks create http http-lb-hc-backup-region \
--port 80 \
--region=$REGION_B

リージョンバックエンドサービスを作成し、各リージョンのインスタンスグループをアタッチします。

Cloud Shell で次の処理を行います。

# Primary (Region A)
gcloud compute backend-services create be-svc-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-primary-region \
--health-checks-region=$REGION_A \
--region=$REGION_A

gcloud compute backend-services add-backend be-svc-a \
--instance-group=ig-a \
--instance-group-zone=$REGION_A-a \
--region=$REGION_A

# Backup (Region B)
gcloud compute backend-services create be-svc-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-backup-region \
--health-checks-region=$REGION_B \
--region=$REGION_B

gcloud compute backend-services add-backend be-svc-b --instance-group=ig-b --instance-group-zone=$REGION_B-a --region=$REGION_B

フロントエンドコンポーネントを作成する

両方のリージョンに URL マップとターゲット HTTP プロキシを作成します。

Cloud Shell で次の処理を行います。

#Primary (Region A)
gcloud compute url-maps create url-map-a \
--default-service=be-svc-a \
--region=$REGION_A
gcloud compute target-http-proxies create http-proxy-a \
--url-map=url-map-a \
--url-map-region=$REGION_A \
--region=$REGION_A
#Backup (Region B)
gcloud compute url-maps create url-map-b \
--default-service=be-svc-b \
--region=$REGION_B

gcloud compute target-http-proxies create http-proxy-b \
--url-map=url-map-b \
--url-map-region=$REGION_B \
--region=$REGION_B

転送ルールに静的 IP アドレス（外部）を予約します。

Cloud Shell で次の処理を行います。

# Primary IP (Region A)
gcloud compute addresses create rxlb-ip-a --region=$REGION_A

# Backup IP (Region B)
gcloud compute addresses create rxlb-ip-b --region=$REGION_B

2 つのロードバランサの転送ルールを作成します。

Cloud Shell で次の処理を行います。

# Primary (Region A)
gcloud compute forwarding-rules create http-fwd-rule-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_A \
--target-http-proxy-region=$REGION_A \
--address=rxlb-ip-a \
--target-http-proxy=http-proxy-a \
--ports=80

# Backup (Region B)
gcloud compute forwarding-rules create http-fwd-rule-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_B \
--target-http-proxy-region=$REGION_B \
--address=rxlb-ip-b \
--target-http-proxy=http-proxy-b \
--ports=80

フェイルオーバー用に Cloud DNS を構成する

外部エンドポイントの Cloud DNS ヘルスチェックを作成する

ロードバランサのパブリック IP アドレス専用のグローバルヘルスチェックを作成する必要があります。これは、ロードバランサの内部ヘルスチェックとは異なります。

まず、フェイルオーバーポリシーを構成するロードバランサの外部 IP アドレスを特定し、変数としてエクスポートします。

Cloud Shell で次の処理を行います。

PRIMARY_IP=$(gcloud compute addresses describe rxlb-ip-a --region=$REGION_A --format='get(address)')

BACKUP_IP=$(gcloud compute addresses describe rxlb-ip-b --region=$REGION_B --format='get(address)')

グローバル DNS ヘルスチェックを作成します（3 つのソースリージョンが必要です）。

Cloud Shell で次の処理を行います。

gcloud beta compute health-checks create http dns-failover-health-check \
    --global \
    --source-regions=$REGION_A,$REGION_B,europe-west1 \
    --request-path=/ \
    --check-interval=30s \
    --port=80 \
    --enable-logging

一般公開マネージドゾーンとフェイルオーバールーティングポリシーを作成します。

一般公開マネージドゾーンを作成します（所有している DNS ドメインを使用します）。

Cloud Shell で次の処理を行います。

gcloud dns managed-zones create codelab-publiczone --dns-name=$DNS_DOMAIN --description="Codelab DNS Failover Zone"

フェイルオーバールーティングポリシーを使用して A レコードを作成します。このポリシーはプライマリ IP を指し、ヘルスチェックを使用してバックアップ IP にフェイルオーバーするタイミングを決定します。

次のコマンドでは、ロードバランサの転送ルール名を使用して、ルーティングポリシーの IP アドレスを参照します。

gcloud beta dns record-sets create codelab.gcp.axiszulu.com. \
--type=A \
--ttl=5 \
--zone=codelab-publiczone \
--routing_policy_type=FAILOVER \
--routing-policy-primary-data=$PRIMARY_IP \
--routing-policy-backup-data-type=GEO \
--routing-policy-backup-item=location=$REGION_B,external_endpoints=$BACKUP_IP \
--health-check=dns-failover-health-check

8. リージョンフェイルオーバーのテスト

初期検証: ツール（dig やウェブブラウザなど）を使用してドメインをクエリします。プライマリ IP（$PRIMARY_IP）に解決され、「Region A - Primary Backend」ページが返されます。

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <PRIMARY_IP>

ブラウザからの出力

フェイルオーバーをシミュレートする: プライマリ VM（vm-a）にログインし、Apache をシャットダウンして停止をシミュレートします。

Cloud Shell で次の処理を行います。

gcloud compute ssh vm-a --zone=$REGION_A-a --command="sudo systemctl stop apache2"

異常ステータスを確認する: DNS ヘルスチェックでプライマリエンドポイントが異常とマークされるまで 2 ～ 3 分待ちます。

# check health status
gcloud compute backend-services get-health be-svc-a --region=${REGION_A}

Output:
backend: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instanceGroups/ig-a
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instances/vm-a
    ipAddress: 10.10.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

フェイルオーバーを検証する: ドメインを再クエリします。これで、バックアップ IP（$BACKUP_IP）に解決され、「Region B - Backup Backend」ページが返されます。

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <BACKUP_IP>

ブラウザからの出力

フェイルバックをシミュレートする（省略可）: SSH でプライマリ VM に接続し、Apache を起動して、DNS ヘルスチェックでプライマリエンドポイントが正常とマークされるまで待ちます。トラフィックは自動的にプライマリ IP に戻ります。
省略可: Cloud Shell で次のコマンドを実行して、Cloud DNS ヘルスチェックのロギングを分析できます。

gcloud logging read "logName=projects/${projectid}/logs/compute.googleapis.com%2Fhealthchecks" \
--limit=10 \
--project=${projectid} \
--freshness=1d \
--format="table(timestamp:label=TIME, \
jsonPayload.healthCheckProbeResult.ipAddress:label=BACKEND_IP, \
jsonPayload.healthCheckProbeResult.previousDetailedHealthState:label=PREVIOUS_STATE, \
jsonPayload.healthCheckProbeResult.detailedHealthState:label=CURRENT_STATE, \
jsonPayload.healthCheckProbeResult.probeResultText:label=RESULT_TEXT)"

9. クリーンアップ手順

これ以上の料金が発生しないように、すべてのコンポーネントを削除します。

Cloud Shell から

# Delete VMs
gcloud compute instances delete vm-a --zone=$REGION_A-a --quiet
gcloud compute instances delete vm-b --zone=$REGION_B-a --quiet
# Delete Load Balancer Components (Primary)
gcloud compute forwarding-rules delete http-fwd-rule-a --region=$REGION_A --quiet
gcloud compute target-http-proxies delete http-proxy-a --region=$REGION_A --quiet
gcloud compute url-maps delete url-map-a --region=$REGION_A --quiet
gcloud compute backend-services delete be-svc-a --region=$REGION_A --quiet
gcloud compute addresses delete rxlb-ip-a --region=$REGION_A --quiet
# Delete Load Balancer Components (Backup)
gcloud compute forwarding-rules delete http-fwd-rule-b --region=$REGION_B --quiet
gcloud compute target-http-proxies delete http-proxy-b --region=$REGION_B --quiet
gcloud compute url-maps delete url-map-b --region=$REGION_B --quiet
gcloud compute backend-services delete be-svc-b --region=$REGION_B --quiet
gcloud compute addresses delete rxlb-ip-b --region=$REGION_B --quiet
# Delete Instance Groups and LB Health Checks
gcloud compute instance-groups unmanaged delete ig-a --zone=$REGION_A-a --quiet
gcloud compute instance-groups unmanaged delete ig-b --zone=$REGION_B-a --quiet
gcloud compute health-checks delete http-lb-hc-primary-region --region=$REGION_A --quiet
gcloud compute health-checks delete http-lb-hc-backup-region --region=$REGION_B --quiet

# Delete Cloud DNS Records Zone and DNS Heath Checks
gcloud dns record-sets delete $DNS_DOMAIN --type=A --zone=codelab-publiczone --quiet
gcloud dns managed-zones delete codelab-publiczone --quiet

gcloud compute health-checks delete dns-failover-health-check --global --quiet

# Delete Cloud NAT and Cloud Routers
gcloud compute routers nats delete $REGION_A-nat-gw \
--router=$REGION_A-cloudrouter --region=$REGION_A --quiet

gcloud compute routers nats delete $REGION_B-nat-gw \
--router=$REGION_B-cloudrouter --region=$REGION_B --quiet

gcloud compute routers delete $REGION_A-cloudrouter \
--region=$REGION_A --quiet

gcloud compute routers delete $REGION_B-cloudrouter \
--region=$REGION_B --quiet


# Delete Subnets and Firewall Rules
gcloud compute firewall-rules delete fw-allow-health-check --quiet
gcloud compute firewall-rules delete fw-allow-proxies --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
gcloud compute networks subnets delete subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete subnet-b \
--region=$REGION_B --quiet
gcloud compute networks subnets delete proxy-only-subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete proxy-only-subnet-b \
--region=$REGION_B --quiet

gcloud compute networks delete external-lb-vpc --quiet

10. 完了

以上で、この Codelab は完了です。

Cloud DNS ヘルスチェックとリージョン外部アプリケーションロードバランサを使用して、マルチリージョンアクティブ / パッシブフェイルオーバーを構成して検証しました。

Cloud DNS ヘルスチェックを使用したリージョン外部エンドポイントのマルチリージョン フェイルオーバー

1. はじめに

学習内容

必要なもの

2. Codelab のトポロジ

3. 設定と要件

セルフペース型の環境設定

Cloud Shell を起動する

4. 始める前に

API を有効にする

5. Cloud Load Balancing インフラストラクチャを作成する

VPC ネットワーク

サブネットを作成する

ネットワーク ファイアウォール ルールを作成する

6. Cloud NAT と Cloud Router を作成する

クラウド ルーターを作成する

NAT ゲートウェイを作成する

バックエンド VM と非マネージド インスタンス グループを作成する

7. リージョン外部アプリケーション ロードバランサを構成する

ヘルスチェックとバックエンド サービスを作成する

リージョン バックエンド サービスを作成し、各リージョンのインスタンス グループをアタッチします。

フロントエンド コンポーネントを作成する

フェイルオーバー用に Cloud DNS を構成する

外部エンドポイントの Cloud DNS ヘルスチェックを作成する

一般公開マネージド ゾーンとフェイルオーバー ルーティング ポリシーを作成します。

8. リージョン フェイルオーバーのテスト

9. クリーンアップ手順

10. 完了

Cloud DNS ヘルスチェックを使用したリージョン外部エンドポイントのマルチリージョンフェイルオーバー

ネットワークファイアウォールルールを作成する

クラウドルーターを作成する

バックエンド VM と非マネージドインスタンスグループを作成する

7. リージョン外部アプリケーションロードバランサを構成する

ヘルスチェックとバックエンドサービスを作成する

リージョンバックエンドサービスを作成し、各リージョンのインスタンスグループをアタッチします。

フロントエンドコンポーネントを作成する

一般公開マネージドゾーンとフェイルオーバールーティングポリシーを作成します。

8. リージョンフェイルオーバーのテスト