このページは Cloud Translation API によって翻訳されました。

Cloud DNS ルーティングポリシーと内部 TCP/UDP ロードバランサのヘルスチェックを使用したマルチリージョンフェイルオーバー

1. はじめに

最終更新日: 2022 年 9 月 22 日

DNS ルーティングポリシーとは

Cloud DNS ルーティングポリシーを使用すると、重み、位置情報、ヘルスチェックなどの特定の基準に応じて DNS ベースのトラフィックステアリングを構成できます。

Cloud DNS でサポートされるルーティングポリシーは次のとおりです。

重み付きラウンドロビンルーティングポリシー
位置情報に基づくルーティングポリシー
ジオフェンスルーティングポリシー
フェイルオーバールーティングポリシー

このラボでは、フェイルオーバールーティングポリシーを構成してテストします。

フェイルオーバールーティングポリシー

Cloud DNS は、グローバルアクセスが有効になっている内部 TCP/UDP ロードバランサのヘルスチェックをサポートしています。フェイルオーバールーティングポリシーでは、リソースレコードにプライマリ IP とバックアップ IP を構成できます。通常のオペレーションでは、Cloud DNS はプライマリセットでプロビジョニングされた IP アドレスを使用してクエリに応答します。プライマリセット内のすべての IP アドレスに障害が発生した（健全性が異常に変わった）場合、Cloud DNS はバックアップセット内の IP アドレスの提供を開始します。

ヘルスチェック

DNS ルーティングポリシーは、ネイティブの内部ロードバランサの統合ヘルスチェック（UHC）に依存します。内部ロードバランサは、20%（またはそれ以上）のバックエンドが正常である場合、正常とみなされます。内部 TCP/UDP ロードバランサのヘルスチェックと内部 HTTP(S) ロードバランサのヘルスチェックでは、異なる情報が提供されます。内部 HTTP(S) ロードバランサの場合、UHC はすべての Envoy プロキシのヘルスステータスを提供しますが、内部 TCP/UDP ロードバランサの場合、Cloud DNS は個々のバックエンドインスタンスから直接ヘルスシグナルを取得します。ヘルスチェックの詳細については、こちらをご覧ください。

作成するアプリの概要

この Codelab では、2 つのリージョンで動作するウェブサイトを構築し、フェイルオーバー DNS ルーティングポリシーをそのウェブサイトに関連付けます。セットアップの内容:

アクティブなリソース -

REGION_1 の L4 内部ロードバランサ
REGION_1 で Apache ウェブサーバーを実行している VM

バックアップリソース -

REGION_2 の L4 内部ロードバランサ
REGION_2 で Apache ウェブサーバーを実行している VM

設定は次のとおりです。

学習内容

フェイルオーバールーティングポリシーの作成方法
DNS フェイルオーバーをトリガーする
トラフィックをバックアップセットにトリクリングする方法

必要なもの

DNS の基礎知識
Google Compute Engine に関する基本的な知識
L4 内部ロードバランサに関する基本的な知識

2. 設定と要件

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

プロジェクト名は、このプロジェクトの参加者に表示される名称です。Google API では使用されない文字列です。この値はいつでも更新できます。
プロジェクト ID は、すべての Google Cloud プロジェクトにおいて一意でなければならず、不変です（設定後は変更できません）。Cloud コンソールでは一意の文字列が自動生成されます。通常、それが何であるかは関係ありません。ほとんどの Codelab では、プロジェクト ID を参照する必要があります（通常は PROJECT_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 アイコンをクリックします。

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

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

3. Google Cloud SDK のバージョン

このドキュメントの作成時点では、401.0.0 が最新の Google Cloud SDK バージョンです。このラボのすべてのコマンドは、最新バージョンの Google Cloud SDK を使用してテストされています。続行する前に、Cloud Shell が最新バージョンの SDK を使用していることを確認してください。

SDK バージョンの確認

gcloud version コマンドを使用して SDK のバージョンを確認します。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud version | grep "Google Cloud SDK"

出力例

Google Cloud SDK 401.0.0

次のステップ

SDK のバージョンが 401.0.0 以降の場合は、次のセクションに進みます。
SDK バージョンが 401.0.0 より前の場合は、次のコマンドを実行して SDK を更新します。

オプションのコマンド

sudo apt-get update && sudo apt-get install google-cloud-sdk

4. 始める前に

前述したアーキテクチャのデプロイを開始する前に、Cloud Shell が正しく構成され、必要な API がすべて有効になっていることを確認してください。

プロジェクト ID の設定

Cloud Shell 内で、プロジェクト ID が設定されていることを確認します。Cloud Shell プロンプトが次の出力のようになり、プロジェクト ID を変更しない場合は、次のステップ（環境変数を設定する）に進みます。

USER@cloudshell:~ (PROJECT_ID)$

プロジェクト ID を変更する場合は、以下のコマンドを使用します。Cloud Shell プロンプトが (PROJECT_ID) から (YOUR-PROJECT-ID) に変わります。

オプションのコマンド

gcloud config set project [YOUR-PROJECT-ID]

出力例

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

環境変数を設定する

export コマンドを使用して環境変数を設定します。Cloud Shell で次のコマンドを実行します。

コマンド

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

確認

環境変数が設定されたので、echo コマンドを使用して確認しましょう。各コマンドの出力は、先ほど export コマンドを使用して構成した値になります。Cloud Shell で次のコマンドを実行します。

コマンド

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

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

gcloud services enable コマンドを使用して、Compute API と DNS API を有効にします。Cloud Shell で次のコマンドを実行します。

Compute API を有効にする

コマンド

gcloud services enable compute.googleapis.com

DNS API を有効にする

コマンド

gcloud services enable dns.googleapis.com

確認

サービスが有効になったので、gcloud services list コマンドを使用して、有効になっているすべての API を一覧表示することを確認してみましょう。

コマンド

gcloud services list | grep -E 'compute|dns'

出力例

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. VPC ネットワーク、サブネット、ファイアウォールルールを作成する

このセクションでは、VPC ネットワーク、2 つのサブネット（各リージョンに 1 つ）、必要なファイアウォールルールを作成します。

VPC ネットワークを作成

gcloud compute networks create コマンドを使用して VPC ネットワークを作成します。次のステップで独自のサブネットを作成するため、サブネットモードをカスタムに設定します。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute networks create my-vpc --subnet-mode custom

サブネットの作成

gcloud compute networks subnets create コマンドを使用して、REGION_1 と REGION_2 の 2 つのサブネットを作成します。Cloud Shell で次のコマンドを実行します。

REGION_1 サブネット

コマンド

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

REGION_2 サブネット

コマンド

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

ファイアウォールルールを作成する

VPC サブネットとロードバランサのヘルスチェック IP 範囲からのポート 80 でトラフィックを許可するには、

さらに、クライアント VM での SSH トラフィックを許可するファイアウォールルールも作成する必要があります。

gcloud compute firewall-rules create コマンドを使用してファイアウォールルールを作成します。Cloud Shell で次のコマンドを実行します。

ポート 80 でトラフィックを許可する

コマンド

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

クライアント VM で SSH トラフィックを許可する

コマンド

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Cloud NAT の作成

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

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

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

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

gcloud compute routers create コマンドを使用して、us-west1 リージョンと us-east4 リージョンに Cloud Router を作成します。Cloud Shell で次のコマンドを実行します。

リージョン 1 の Cloud Router

コマンド

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

リージョン 2 の Cloud Router

コマンド

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

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

gcloud compute routers nat create コマンドを使用して、us-west1 リージョンと us-east4 リージョンに NAT ゲートウェイを作成します。Cloud Shell で次のコマンドを実行します。

Region_1 NAT ゲートウェイ

コマンド

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

Region_2 NAT ゲートウェイ

コマンド

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

7. Compute Engine VM を作成する

このセクションでは、ウェブサーバー、ウェブサーバーの非マネージドインスタンスグループ、クライアント VM を作成します。

ウェブサーバー VM を作成する

gcloud compute instances create コマンドを使用してウェブサーバーを作成します。2 つのウェブサーバーを作成する必要があります。1 つは REGION_1 に、もう 1 つは REGION_2 に作成します。起動スクリプトを使用して、ウェブサーバーに Apache をインストールして構成します。

REGION_1 ウェブサーバー

Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

REGION_2 ウェブサーバー

Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

非マネージドインスタンスグループを作成する

このセクションでは、非マネージドインスタンスグループを 2 つ作成します。次のセクションでは、これらのインスタンスグループを使用して ILB バックエンドサービスを構成します。インスタンスグループが作成されたら、これらのインスタンスグループにウェブサーバー VM を追加します。

非マネージドインスタンスグループを作成する

gcloud compute instance-groups unmanaged create コマンドを使用して、2 つの非マネージドインスタンスグループを作成します。1 つは us-west1 ウェブサーバー用、もう 1 つは us-east4 ウェブサーバー用です。

Region_1 インスタンスグループ

コマンド

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Region_2 インスタンスグループ

コマンド

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

インスタンスグループに VM を追加する

gcloud compute instance-groups unmanaged add-instances コマンドを使用して、作成したインスタンスグループにインスタンスを追加します。REGION_1 ウェブサーバーを REGION_1 インスタンスグループに追加し、REGION_2 ウェブサーバーを REGION_2 インスタンスグループに追加します

Region_1 インスタンスグループ

コマンド

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Region_2 インスタンスグループ

コマンド

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

クライアント VM を作成する

この VM を使用してテストを実行し、DNS 構成を検証します。起動スクリプトを使用して dnsutils パッケージをインストールします。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. L4 内部ロードバランサを作成する

L4 ILB を作成するには、ヘルスチェック、バックエンドサービス、転送ルールを作成する必要があります。

ヘルスチェックを作成

gcloud compute health-checks create コマンドを使用してヘルスチェックを作成します。基本的な HTTP ヘルスチェックを作成しています。ターゲットポートはポート 80 です。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute health-checks create http http-hc --port 80

バックエンドサービスを構成する

gcloud compute backend-services create コマンドを使用してバックエンドサービスを作成します。バックエンドサービスが作成されたら、gcloud compute backend-services add-backend コマンドを使用して、非マネージドインスタンスグループをバックエンドサービスに追加します。Cloud Shell で次のコマンドを実行します。

バックエンドサービスの作成

コマンド

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

バックエンドの追加

コマンド

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

転送ルールを作成する

gcloud compute forwarding-rules create コマンドを使用して、両方のリージョンに転送ルールを作成します。Cloud Shell で次のコマンドを実行します。

REGION_1 転送ルール

コマンド

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

REGION_2 転送ルール

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. DNS を構成する

このセクションでは、限定公開ゾーンと、フェイルオーバールーティングポリシーを含む DNS レコードセットを作成します。

限定公開 DNS ゾーンを作成する

gcloud dns managed-zones create コマンドを使用して、example.com の限定公開ゾーンを作成します。このゾーンを使用して、フェイルオーバールーティングポリシーを含むリソースレコードセットを作成します。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc

フェイルオーバールーティングポリシーを使用して DNS レコードを作成する

gcloud dns record-sets create コマンドを使用して、フェイルオーバールーティングポリシーを含む DNS レコードを作成します。プライマリターゲットは REGION_1 内のロードバランサです。Cloud DNS は位置情報ベースのバックアップターゲットのみをサポートしています。バックアップセットは、REGION_1 と REGION_2 のターゲットとして REGION_2 ロードバランサを使用する位置情報ポリシーです。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

出力例

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. DNS 解決をテストする

フェイルオーバーの設定をテストする前に、両方の内部ロードバランサの IP アドレスをメモしておきます。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

出力例

この例では、us-west1-ilb の IP アドレスは 10.1.0.4 で、us-east4-ilb の IP アドレスは 10.2.0.3 です。

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

クライアントインスタンスにログインして、DNS の解決をテストします。ウェブコンソールで、[Compute Engine |VM インスタンス」が表示されます。

[SSH] ボタンをクリックして、コンソールからクライアントインスタンスにログインします。

クライアント VM にログインしたので、dig コマンドを使用して failover.example.com ドメイン名を解決します。

このコマンドを 10 回実行するようにループを構成し、6 秒のスリープタイマーを設定しています。

コマンド

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

6 秒のスリープタイマーが追加されているのは、DNS レコードの TTL が 5 秒に設定されているからです。スリープタイマーにより、各 DNS リクエストに対してキャッシュされていない DNS レスポンスが返されます。このコマンドの実行には 1 分ほどかかります。

出力で、リソースレコードのプライマリセットにあるロードバランサの IP アドレスを確認できます。この設定では、us-west1 リージョン内のロードバランサの IP になります。

11. フェイルオーバーをテストする

REGION_1 VM からネットワークタグを削除して、フェイルオーバーをシミュレートします。これにより、ポート 80 へのアクセスがブロックされ、その結果としてヘルスチェックが失敗します。

ネットワークタグを削除する

gcloud compute instances remove-tags コマンドを使用して、VM からネットワークタグを削除します。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

ヘルスチェックは 10 秒後に失敗します。DNS 解決テストを再度実行します。

DNS 解決

クライアントインスタンスから、次のコマンドを実行します。

コマンド

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

出力に、リソースレコードのバックアップセットに含まれるロードバランサの IP アドレスが表示されます。この設定では、us-east4 リージョン内のロードバランサの IP になります。

12. トラフィックのトリクリングをテストする

デフォルトでは、フェイルオーバーポリシーはすべての DNS リクエストのプライマリエンドポイント IP を返し、プライマリがヘルスチェックに失敗した場合にのみバックアップ IP を返します。Cloud DNS では、トリクル比率を構成できます。これにより、プライマリターゲットが正常な場合でも、Cloud DNS がトラフィックの一部をバックアップターゲットに送信できます。割合は 0～1 の値にする必要があります。デフォルト値は 0 です。

これをテストするために、ネットワークタグを REGION_1 ウェブサーバーに追加しましょう。

ネットワークタグを追加

ウェブサーバー VM にタグを再度追加して、プライマリリージョンの VM への HTTP トラフィックを許可する。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

ヘルスチェックは 10 秒で合格します

DNS 解決がプライマリロードバランサを指していることを確認します。この設定では、us-west1 リージョン内のロードバランサの IP アドレスになります。

クライアントインスタンスから、次のコマンドを実行します。

コマンド

dig +short failover.example.com

DNS レコードを更新する

次に、プライマリが正常な場合でもトラフィックの 30% がバックアップセットにトリクリングされるように、failover.example.com の DNS レコードを変更します。Cloud Shell で次のコマンドを実行します。

コマンド

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

DNS 解決

クライアント VM から次のコマンドを実行します。DNS レコード failover.example.com がプライマリロードバランサの IP 約に解決されることがわかります。バックアップロードバランサの IP アドレスに約 70% の30% の割合です

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. クリーンアップ手順

このラボで使用したリソースをクリーンアップするために、CloudShell から次のコマンドを実行します。

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

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

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

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

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

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. 完了

Cloud DNS フェイルオーバールーティングポリシーのデプロイとテストが完了しました

学習した内容

Cloud DNS フェイルオーバールーティングポリシーを構成する方法
DNS フェイルオーバーをテストする
トラフィックをバックアップセットにトリクリングする方法

次のステップ

アクティブセットとバックアップセットに複数の IP を設定してみる
非マネージドインスタンスグループに複数のバックエンド VM を追加してみてください
バックアップセットの位置情報ポリシー用に、異なるリージョンに複数のロードバランサを設定してみます。

その他の情報

https://cloud.google.com/dns/docs/zones/manage-routing-policies

Cloud DNS ルーティング ポリシーと内部 TCP/UDP ロードバランサのヘルスチェックを使用したマルチリージョン フェイルオーバー

1. はじめに

DNS ルーティング ポリシーとは

フェイルオーバー ルーティング ポリシー

ヘルスチェック

作成するアプリの概要

学習内容

必要なもの

2. 設定と要件

Cloud Shell の起動

3. Google Cloud SDK のバージョン

SDK バージョンの確認

次のステップ

4. 始める前に

プロジェクト ID の設定

環境変数を設定する

環境変数を設定する

確認

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

Compute API を有効にする

DNS API を有効にする

確認

5. VPC ネットワーク、サブネット、ファイアウォール ルールを作成する

VPC ネットワークを作成

サブネットの作成

REGION_1 サブネット

REGION_2 サブネット

ファイアウォール ルールを作成する

ポート 80 でトラフィックを許可する

クライアント VM で SSH トラフィックを許可する

6. Cloud NAT の作成

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

リージョン 1 の Cloud Router

リージョン 2 の Cloud Router

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

Region_1 NAT ゲートウェイ

Region_2 NAT ゲートウェイ

7. Compute Engine VM を作成する

ウェブサーバー VM を作成する

REGION_1 ウェブサーバー

REGION_2 ウェブサーバー

非マネージド インスタンス グループを作成する

非マネージド インスタンス グループを作成する

Region_1 インスタンス グループ

Region_2 インスタンス グループ

インスタンス グループに VM を追加する

Region_1 インスタンス グループ

Region_2 インスタンス グループ

クライアント VM を作成する

8. L4 内部ロードバランサを作成する

ヘルスチェックを作成

バックエンド サービスを構成する

バックエンド サービスの作成

バックエンドの追加

転送ルールを作成する

REGION_1 転送ルール

REGION_2 転送ルール

9. DNS を構成する

限定公開 DNS ゾーンを作成する

フェイルオーバー ルーティング ポリシーを使用して DNS レコードを作成する

10. DNS 解決をテストする

11. フェイルオーバーをテストする

ネットワーク タグを削除する

DNS 解決

12. トラフィックのトリクリングをテストする

ネットワーク タグを追加

DNS レコードを更新する

DNS 解決

13. クリーンアップ手順

14. 完了

学習した内容

次のステップ

その他の情報

Cloud DNS ルーティングポリシーと内部 TCP/UDP ロードバランサのヘルスチェックを使用したマルチリージョンフェイルオーバー

DNS ルーティングポリシーとは

フェイルオーバールーティングポリシー

5. VPC ネットワーク、サブネット、ファイアウォールルールを作成する

ファイアウォールルールを作成する

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

非マネージドインスタンスグループを作成する

非マネージドインスタンスグループを作成する

Region_1 インスタンスグループ

Region_2 インスタンスグループ

インスタンスグループに VM を追加する

Region_1 インスタンスグループ

Region_2 インスタンスグループ

バックエンドサービスを構成する

バックエンドサービスの作成

フェイルオーバールーティングポリシーを使用して DNS レコードを作成する

ネットワークタグを削除する

ネットワークタグを追加