このドキュメントは、アーキテクトおよび運用に携わる人々を対象としています。
管理チーム。このドキュメントでは、使用できるパターンの例について説明しています
Google Cloud での独自のデプロイ用。


このパターンでは、ロード バランサーはトラフィックを
Compute Engine
インスタンス
マネージド インスタンス グループ
コンテンツを提供します。停止中は、
外部 HTTP(S) 負荷分散
の構成と静的サイトへのフェイルオーバー
クラウドストレージ。


このチュートリアルを完了するには、管理する登録済みのドメイン名が必要です
このドキュメントで使用したい。


実稼働環境では、Web サイトにはさらに多くのファイルとファイルが含まれる可能性があります。
マネージド インスタンス グループの仮想マシンでの追加のアプリケーション コード
(VM) よりも、このドキュメントに示されています。その後、Cloud Storage はさらにホストします
最小限の機能を提供する限定的な静的バージョン。ウォーム フェイルオーバーの場合
シナリオでは、マネージド インスタンス グループが
完全な Web サイト エクスペリエンスのトラフィックを処理できます。


このチュートリアルでは、リソースをデプロイして環境を作成します。
次の画像:





フェイルオーバーが必要な場合は、ロード バランサーの構成を直接に更新します。
次の図に示すように、Cloud Storage へのトラフィック:





このウォーム フェールオーバー パターンは、別の管理対象を実行するコストのバランスをとります
プライマリ リージョンの場合にのみ使用する別のリージョンのインスタンス グループ
失敗。 Cloud Storage を使用した静的サイトのコストは、実行中のサイトよりも低い
別のマネージド インスタンス グループをロードしますが、負荷を更新するときに少し遅延があります
ホスティング オプション間のバランサー構成。限定サイト
Cloud Storage でのエクスペリエンスは、利用できないウェブサイトよりも優れており、貧弱です
顧客体験。


外部の代わりに Cloud DNS を使用する代替アプローチの場合
フェイルオーバーを制御するための HTTP(S) 負荷分散については、次を参照してください。
Cloud DNS と Compute Engine および Cloud Storage を使用して、復元可能なウォーム ウェブサーバーをデプロイします。
このパターンは、Cloud DNS を持っているか、使用したい場合に役立ちます。


Google Cloud で信頼性の高いアプリケーションを実行するには、次のように設計することをおすすめします
停止を処理するためのアプリケーション インフラストラクチャ。お申し込み内容に応じて
ビジネス ニーズによっては、コールド フェールオーバー、ウォーム フェールオーバー、またはホット フェールオーバーが必要になる場合があります。
フェイルオーバーパターン。最適なアプローチを決定する方法の詳細については、
独自のアプリケーションについては、
災害復旧計画ガイド。


このドキュメントでは、基本的な
Apache ウェブサーバー、
ただし、インフラストラクチャの展開に対する同じアプローチは、他のものにも適用されます。
作成する必要があるアプリケーション環境。
## 目的
 


-

- カスタム VM イメージを使用してリージョン マネージド インスタンス グループを作成します。

- Cloud Storage バケットを作成します。

- 外部 HTTP(S) 負荷分散を作成して構成します。

- 更新されたロード バランサーを使用して、ウォーム Web サーバーのフェールオーバーをテストします
構成。

- 更新されたロード バランサー構成で回復とフェイルバックをテストします。

## 費用
 








 


 

 このチュートリアルでは、Google Cloud の次の課金対象コンポーネントを使用します。
 

 


-

- 計算エンジン

- ネットワーキング

- クラウドストレージ


 

 
 予測される使用量に基づいて費用を見積もるには、
 料金計算ツールを使用してください。

＃＃ あなたが始める前に
 





-













-
 
 
 
 Google Cloud アカウントにログインします。初めての方は
 Google クラウド、
 アカウントを作成して、当社の製品がどのように機能するかを評価します
 現実世界のシナリオ。新規のお客様は、$300 の無料クレジットも獲得できます。
 ワークロードを実行、テスト、デプロイします。
 
 
 
 
 
 

 
 

 
 

 
 
 

 
 










 
 
 

-
 
 

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

 
 
 
 



 
 
 








 

-
 


 Cloud プロジェクトで課金が有効になっていることを確認してください。やり方を学ぶ
 プロジェクトで課金が有効になっているかどうかを確認します。

 
 
 


 
 
 
 











 
 

-
 
 
 


 
 
 
 Compute Engine API を有効にします。
 
 
 

 



 
 
 
 

 
 









 





 





 

-
 
 Google Cloud CLI をインストールして初期化します。

 

 
 
 
 
 
 






 
 
 


-
 
 

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

 
 
 
 



 
 
 








 

-
 


 Cloud プロジェクトで課金が有効になっていることを確認してください。やり方を学ぶ
 プロジェクトで課金が有効になっているかどうかを確認します。

 
 
 


 
 
 
 











 
 

-
 
 
 


 
 
 
 Compute Engine API を有効にします。
 
 
 

 



 
 
 
 

 
 









 





 





 

-
 
 Google Cloud CLI をインストールして初期化します。

 

 
 
 
 
 
 






 
 
 


Google Cloud CLI は
インストールせずにコンソール
Google クラウド CLI。で gcloud CLI を実行するには
コンソール、Cloud Shell を使用

## 環境を整える


このセクションでは、リソース名のいくつかの変数を定義し、
場所。これらの変数は、Google Cloud CLI コマンドで使用されます。
リソースをデプロイします。


このドキュメントでは、特に断りのない限り、すべてのコマンドを
クラウド シェル
またはローカル開発環境。


-

交換


独自のプロジェクト ID を使用します。必要に応じて、
リソースの検索と識別に役立つ独自の名前サフィックスを提供する
などのそれら
PROJECT_ID


アプリ
次のように、2 つのリージョンを指定します。


と

us-west1
、およびこれらのリージョンのいずれか内のゾーン (次のような)

us-west2
.このゾーンは、最初のベース VM がどこにあるかを定義します。
マネージド インスタンス グループのイメージを作成するために使用される

us-west1-a
最後に、次のような静的 Web サイトに使用されるドメインを設定します。




example.com
PROJECT_ID=
PROJECT_ID
NAME_SUFFIX= アプリ
REGION1= 米国西部 1
REGION2= us-west2
ZONE= us-west1-a
ドメイン= example.com
 

## VPC とサブネットを作成する


VM へのネットワーク アクセスを提供するには、Virtual Private Cloud (VPC) を作成します。
およびサブネット。 2 つのリージョンでマネージド インスタンス グループが必要なため、1 つを作成します。
各リージョンのサブネット。カスタムの利点の詳細については、
環境で使用されている IP アドレス範囲を管理するためのサブネット モードについては、を参照してください。
カスタム モードの VPC ネットワークを使用します。


-

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

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


次に、新しい VPC に 2 つのサブネットを作成します (それぞれに 1 つずつ)。
領域。次のように、独自のアドレス範囲を定義します。


と
10.1.0.0/20
、 それか
あなたのネットワーク範囲に収まります:
10.2.0.0/20
gcloud compute networks subnets create n subnet-$NAME_SUFFIX-$REGION1 n --network=network-$NAME_SUFFIX n --range=
10.1.0.0/20n --地域=$REGION1

gcloud compute networks subnets create n subnet-$NAME_SUFFIX-$REGION2 n --network=network-$NAME_SUFFIX n --range= 10.2.0.0/20n --region=$REGION2
 

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


VPC でネットワーク トラフィックが正しく流れるようにするには、次を使用します。
ファイアウォール ルール。


-

負荷のウェブ トラフィックとヘルス チェックを許可するファイアウォール ルールを作成する
バランサとマネージド インスタンス グループ:



gcloud compute firewall-rules create allow-http-$NAME_SUFFIX n --network=network-$NAME_SUFFIX n --direction=INGRESS n --priority=1000 n --action=ALLOW n --rules=tcp:80 n -- source-ranges=0.0.0.0/0 n --target-tags=http-server

gcloud compute firewall-rules create allow-health-check-$NAME_SUFFIX n --network=network-$NAME_SUFFIX n --action=allow n --direction=ingress n --source-ranges=130.211.0.0/22,35.191. 0.0/16 n --target-tags=allow-health-check n --rules=tcp:80

HTTP ルールは、任意の VM へのトラフィックを許可します。
http-servertag が適用され、
およびを使用する任意のソースから
0.0.0.0/0 範囲。のために
ヘルスチェック ルール、
Google Cloud のデフォルトの範囲は、プラットフォームが正しく動作できるように設定されています
リソースの状態を確認します。

ベース VM イメージの初期構成で SSH トラフィックを許可するには、スコープ
を使用して環境にファイアウォール ルールを追加します。


--source-range パラメータ。
ネットワーク チームと協力して、ソース範囲を決定する必要がある場合があります。
あなたの組織は

交換

独自の IP アドレス スコープを使用:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX n --network=network-$NAME_SUFFIX n --direction=INGRESS n --priority=1000 n --action=ALLOW n --rules=tcp:22 n --ソース範囲=
IP_ADDRESS_SCOPE
 

ファイアウォール ルールを作成したら、3 つのルールが設定されていることを確認します。
追加した：
gcloud compute firewall-rules list n --project=$PROJECT_ID n --filter="NETWORK=network-$NAME_SUFFIX"次の出力例は、3 つのルールが正しく行われたことを示しています。
作成した：

名前 ネットワーク 方向 優先度 許可
allow-health-check-app network-app イングレス 1000 tcp:80
allow-http-app network-app イングレス 1000 tcp:80
allow-ssh-app network-app イングレス 1000 tcp:22


## 基本 VM イメージを作成して構成する


追加の構成なしで展開する同一の VM を作成するには、次のようにします。
カスタム VM イメージを使用します。このイメージは、OS と Apache の構成をキャプチャし、
は、次の手順でマネージド インスタンス グループに各 VM を作成するために使用されます。


VM で、基本的な
永続ディスク上の index.html ファイルと
にマウントします
/var/www/example.com. Apache 構成ファイル

/etc/apache2/sites-available/example.com.conf は、
マウントされた永続ディスクの場所

次の図は、保存されている Apache によって提供される基本的な HTML ページを示しています。
永続ディスク:





この環境は、次の手順で構築します。


-

永続ディスクが接続されたベース VM を作成します。



gcloud compute instances create vm-base-$NAME_SUFFIX n --zone=$ZONE n --machine-type=n1-standard-1 n --subnet=subnet-$NAME_SUFFIX-$REGION1 n --tags=http-server n --image=debian-10-buster-v20210420 n --image-project=debian-cloud n --boot-disk-size=10GB n --boot-disk-type=pd-balanced n --boot-disk- device-name=vm-base-$NAME_SUFFIX n --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX

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

シンプルな Web サイトをインストールして構成するには、次を使用してベース VM に接続します。
SSH:

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


VM への SSH セッションで、VM を構成するスクリプトを作成します。
あなたの選択したエディター。次の例では、
ナノ
編集者として:



ナノ構成-vm。
次の構成スクリプトをファイルに貼り付けます。



ビン/バッシュ

NAME_SUFFIX=
アプリ

# 基本的な Web サイト ファイルのディレクトリを作成します
sudo mkdir -p /var/www/example.com
sudo chmod a+w /var/www/example.com
sudo chown -R www-data: /var/www/example.com

# ディスク名を見つけて、フォーマットしてマウントします
DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATHfind /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -f n
sudo mkfs.ext4 -m 0 -E lazy_itable_init=0,lazy_journal_init=0,discard $DISK_PATH
sudo マウント -o 破棄、デフォルト $DISK_PATH /var/www/example.com

# アパッチをインストール
sudo apt-get アップデート&& sudo apt-get -y install apache2

# マウントされた永続ディスクに基本的な HTML ファイルを書き出す
sudo ティー -a /var/www/example.com/index.html >/dev/null EOF'



  HA/DRの例


 
Cloud Storage へのウォーム フェイルオーバーを備えた Compute Engine ウェブサイトへようこそp>
*: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

EOF

# Apache 構成ファイルとリロード サービスを有効にする
sudo a2dissite 000-デフォルト
sudo a2ensite example.com.conf
sudo systemctl reload apache2

更新する
に設定された値に一致する変数
など、このドキュメントの先頭

NAME_SUFFIX アプリ。

ファイルを書き出して、エディターを終了します。たとえば、Nano では次のように使用します。

Ctrl-Oto でファイルを書き出し、次のコマンドで終了します
Ctrl+X。

構成スクリプトを実行可能にしてから実行します。

chmod +x configure-vm../configure-vm.
VM への SSH セッションを終了します。

出口


VM の IP アドレスを取得して使用する

curl で基本的な Web ページを表示:


curl $(gcloud compute instances describe vm-base-$NAME_SUFFIX n --zone $ZONE n --format="value(networkInterfaces.accessConfigs.[0].natIPn
次の出力例に示すように、基本的な Web サイトが返されます。








  HA/DRの例


 
Cloud Storage へのウォーム フェイルオーバーを備えた Compute Engine ウェブサイトへようこそp>

gcloud compute images create image-disk-$NAME_SUFFIX n --source-disk=disk-base-$NAME_SUFFIX n --source-disk-zone=$ZONE

# インスタンス テンプレートの作成
gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 n --machine-type=n1-standard-1 n --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 n --region=$REGION1 n --tags=http-server n --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example. com\ ext4\ discard,defaults,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a n --image=image-$NAME_SUFFIX n --create-disk=image=image-disk-$NAME_SUFFIX ,自動削除=はい

gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 n --machine-type=n1-standard-1 n --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 n --region=$REGION2 n --tags=http-server n --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ value\ /dev/sdb /var/www/example. com\ ext4\ discard,defaults,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a n --image=image-$NAME_SUFFIX n --create-disk=image=image-disk-$NAME_SUFFIX ,自動削除=はい

# VM インスタンスのヘルスチェックを作成する
gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX n --port 80

# マネージド インスタンス グループを作成する
gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 n --template=template-$NAME_SUFFIX-$REGION1 n --size=2 n --region=$REGION1 n --health-check=http-基本チェック-$NAME_SUFFIX

gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION2 n --template=template-$NAME_SUFFIX-$REGION2 n --size=2 n --region=$REGION2 n --health-check=http-基本チェック-$NAME_SUFFIX


## ロード バランサーを作成して構成する


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


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


詳細については、次を参照してください。
シンプルな外部 HTTP ロードバランサを設定する方法。


-

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

# HTTP ポート 80 のポート規則を構成する
gcloud compute instance-groups set-named-ports n instance-group-$NAME_SUFFIX-$REGION1 n --named-ports http:80 n --region $REGION1


gcloud compute instance-groups set-named-ports n instance-group-$NAME_SUFFIX-$REGION2 n --named-ports http:80 n --region $REGION2

# バックエンド サービスを作成し、それにマネージド インスタンス グループを追加します
gcloud compute backend-services create n web-backend-service-$NAME_SUFFIX n --protocol=HTTP n --port-name=http n --health-checks=http-basic-check-$NAME_SUFFIX n --global

gcloud compute backend-services add-backend n web-backend-service-$NAME_SUFFIX n --instance-group=instance-group-$NAME_SUFFIX-$REGION1 n --instance-group-region=$REGION1 n --global

gcloud compute backend-services add-backend n web-backend-service-$NAME_SUFFIX n --instance-group=instance-group-$NAME_SUFFIX-$REGION2 n --instance-group-region=$REGION2 n --global

# バックエンド サービスの URL マップを作成する
gcloud compute url-maps create web-map-http-$NAME_SUFFIX n --default-service web-backend-service-$NAME_SUFFIX

# HTTP トラフィックの転送を構成する
gcloud compute target-http-proxies create n http-lb-proxy-$NAME_SUFFIX n --url-map web-map-http-$NAME_SUFFIX

gcloud compute forwarding-rules create n http-content-rule-$NAME_SUFFIX n --global n --target-http-proxy=http-lb-proxy-$NAME_SUFFIX n --ports=80


Web トラフィックの転送ルールの IP アドレスを取得します。

IP_ADDRESSgcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX n --global n --format="value(IPAddressn

使用

curl するか、Web ブラウザーを開いて、IP を使用して Web サイトを表示します。
前のステップからのロードバランサーのアドレス:


カール $IP_ADDRESS

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


次の出力例に示すように、基本的な Web サイトが返されます。




  HA/DRの例


 
Cloud Storage へのウォーム フェイルオーバーを備えた Compute Engine ウェブサイトへようこそp>

マネージド インスタンス グループが回復し、ウェブサイト全体のトラフィックを処理できるようになります
経験。


-

ドメインを確認する
Cloud Storage バケットで使用する

所有しているドメインの名前と一致する Cloud Storage バケットを作成する
使用したい：



gsutil mb gsstatic-web.$DOMAIN

の
このドキュメントの冒頭で定義された DOMAIN 変数が使用されます。

.この例では、静的ファイルを次の場所に保存します。

example.com
static-web.example.com.

の Cloud Storage バケットにコピーするローカル ファイルを作成します。
次のステップ：

cat< index.html




 HA / DR example


 
Welcome to a test static web server with warm failover from Cloud Storagep>





 HA / DR example


 
Welcome to a test static web server with warm failover from Cloud Storagep>


curlagain, or open your web browser, to access the IP address of the
load balancer:


curl $IP_ADDRESS

It might take a few minutes for the load balancer to update the configuration
and to correctly direct traffic back to your managed instance groups. If
needed, wait a few minutes and try to access the website again.


The main website from the managed instance groups is returned, as shown in the
following example output:





 HA / DR example


 p>Welcome to a Compute Engine website with warm failover to Cloud Storagep>




## Clean up
 


 To avoid incurring charges to your Google Cloud account for the resources used in this
 tutorial, either delete the project that contains the resources, or keep the project and
 delete the individual resources.

 
 


To delete the individual resources created in this document, complete the
following steps:


- 

Delete the Cloud Storage bucket:

gsutil rm -r gsstatic-web.$DOMAIN


Delete the load balancer configuration:

gcloud compute forwarding-rules delete n http-content-rule-$NAME_SUFFIX --global --quiet

gcloud compute target-http-proxies delete n http-lb-proxy-$NAME_SUFFIX --quiet

gcloud compute url-maps delete web-map-http-$NAME_SUFFIX --quiet

gcloud compute url-maps delete web-map-http-bucket-$NAME_SUFFIX --quiet

gcloud compute backend-services delete n web-backend-service-$NAME_SUFFIX --global --quiet

gcloud compute backend-buckets delete web-bucket-$NAME_SUFFIX --quiet


Delete the managed instance groups and health check:

gcloud compute instance-groups managed delete n instance-group-$NAME_SUFFIX-$REGION1 n --region=$REGION1 --quiet

gcloud compute instance-groups managed delete n instance-group-$NAME_SUFFIX-$REGION2 n --region=$REGION2 --quiet

gcloud compute health-checks delete http-basic-check-$NAME_SUFFIX --quiet


Delete the instance templates, images, base VM, and persistent disks:

gcloud compute instance-templates delete n template-$NAME_SUFFIX-$REGION1 --quiet

gcloud compute instance-templates delete n template-$NAME_SUFFIX-$REGION2 --quiet

gcloud compute images delete image-$NAME_SUFFIX --quiet

gcloud compute images delete image-disk-$NAME_SUFFIX --quiet

gcloud compute instances delete vm-base-$NAME_SUFFIX n --zone=$ZONE --quiet


Delete the firewall rules.

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

gcloud compute firewall-rules delete n allow-ssh-$NAME_SUFFIX --quiet

gcloud compute firewall-rules delete n allow-http-$NAME_SUFFIX --quiet


Delete the subnet and VPC.


gcloud compute networks subnets delete n subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet

gcloud compute networks subnets delete n subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet

gcloud compute networks delete network-$NAME_SUFFIX --quiet


## What's next
 


- 

- For an alternative approach that uses Cloud DNS instead of external
HTTP(S) Load Balancing to control the failover, see
Deploy a warm recoverable web server using Cloud DNS with Compute Engine and Cloud Storage.
This pattern is useful if you have, or want to use, Cloud DNS. 

- To learn how how to determine the best approach for your own applications and
which recovery method to use, see the
Disaster recovery planning guide. 

- To see other patterns for applications, such as cold and hot failover, see
Disaster recovery scenarios for applications. 

- For more ways to handle scale and availability, see the
Patterns for scalable and resilient apps. 

- 

Explore reference architectures, diagrams, tutorials, and best practices about Google Cloud.
Take a look at our
Cloud Architecture Center.