Dokumen ini bertujuan untuk arkitek dan orang yang bekerja dalam pasukan operasi dan pentadbiran. Dokumen ini menerangkan corak contoh yang boleh anda gunakan untuk penempatan anda sendiri dalam Google Cloud

Dalam corak ini, Cloud DNS menghalakan trafik ke tika Enjin Kira dalam kumpulan tika terurus yang menyediakan kandungan. Dalam gangguan, anda mengemas kini zon DNS Awan dan gagal ke tapak statik dalam Storan Awan

Untuk melengkapkan tutorial ini, anda memerlukan nama domain berdaftar yang anda kawal dan ingin gunakan dengan dokumen ini

Dalam penggunaan pengeluaran, tapak web anda mungkin termasuk lebih banyak fail dan kod aplikasi tambahan pada mesin maya kumpulan contoh terurus (VM) anda daripada yang ditunjukkan dalam dokumen ini. Storan Awan kemudian menjadi hos versi statik yang lebih terhad yang menyediakan kefungsian minimum. Dalam senario failover yang hangat, pengguna melihat tapak web terhad ini sehingga kumpulan contoh terurus pulih dan boleh menyampaikan trafik untuk pengalaman penuh tapak web

Dalam tutorial ini, anda menggunakan sumber untuk mencipta persekitaran seperti yang ditunjukkan dalam imej berikut:
Apabila anda perlu gagal, anda mengemas kini konfigurasi Cloud DNS untuk mengarahkan trafik ke Cloud Storage, seperti yang ditunjukkan dalam imej berikut:
Corak failover hangat ini mengimbangi kos menjalankan kumpulan contoh terurus lain di rantau lain yang anda hanya gunakan apabila rantau utama gagal. Kos tapak statik menggunakan Cloud Storage adalah lebih rendah daripada menjalankan kumpulan contoh terurus yang lain, tetapi terdapat kelewatan yang singkat semasa anda mengemas kini Cloud DNS antara pilihan pengehosan. Pengalaman laman web yang terhad dalam Cloud Storage adalah lebih baik daripada tapak web yang tidak tersedia sepenuhnya dan pengalaman pelanggan yang lemah

Untuk pendekatan alternatif yang menggunakan HTTP(S) Load Balancing dan bukannya Cloud DNS untuk mengawal failover, lihat Gunakan pelayan web boleh pulih yang hangat dengan Compute Engine dan Cloud Storage. Corak ini berguna jika anda tidak mempunyai, atau tidak mahu menggunakan, Cloud DNS

Untuk menjalankan aplikasi yang boleh dipercayai dalam Google Cloud, kami mengesyorkan anda mereka bentuk infrastruktur aplikasi anda untuk mengendalikan gangguan. Bergantung pada aplikasi dan keperluan perniagaan anda, anda mungkin memerlukan corak failover sejuk, failover hangat atau corak failover panas. Untuk mendapatkan maklumat lanjut tentang cara menentukan pendekatan terbaik untuk aplikasi anda sendiri, lihat panduan perancangan pemulihan Bencana

Dokumen ini menggunakan pelayan web Apache asas, tetapi pendekatan yang sama untuk penggunaan infrastruktur digunakan untuk persekitaran aplikasi lain yang anda perlu buat

## Objektif

- Buat kumpulan contoh terurus serantau dengan imej VM tersuai

- Buat baldi Storan Awan

- Buat dan konfigurasi zon DNS Awan

- Uji failover pelayan web yang hangat dengan rekod Cloud DNS yang dikemas kini

- Uji pemulihan dan failback dengan rekod Cloud DNS yang dikemas kini

## Kos
Tutorial ini menggunakan komponen Google Cloud yang boleh dibilkan berikut:
Untuk menjana anggaran kos berdasarkan unjuran penggunaan anda,
gunakan kalkulator harga

## Sebelum awak bermula
Beberapa langkah dalam dokumen ini mungkin tidak berfungsi dengan betul jika organisasi anda menggunakan kekangan pada persekitaran Google Cloud anda. Dalam kes itu, anda mungkin tidak dapat menyelesaikan tugas seperti membuat alamat IP awam atau kunci akaun perkhidmatan. Jika anda membuat permintaan yang mengembalikan ralat tentang kekangan, lihat cara Membangunkan aplikasi dalam persekitaran Google Cloud yang terhad

- Log masuk ke akaun Google Cloud anda. Jika anda baru menggunakan Google Cloud, buat akaun untuk menilai prestasi produk kami dalam senario dunia sebenar. Pelanggan baharu juga mendapat kredit percuma $300 untuk menjalankan, menguji dan menggunakan beban kerja

-
Dalam konsol Google Cloud, pada halaman pemilih projek, pilih atau buat projek Google Cloud

-
Pastikan pengebilan didayakan untuk projek Awan anda. Ketahui cara menyemak sama ada pengebilan didayakan pada projek

-
Dayakan Compute Engine API

- Pasang dan mulakan CLI Awan Google

-
Dalam konsol Google Cloud, pada halaman pemilih projek, pilih atau buat projek Google Cloud

-
Pastikan pengebilan didayakan untuk projek Awan anda. Ketahui cara menyemak sama ada pengebilan didayakan pada projek

-
Dayakan Compute Engine API

- Pasang dan mulakan CLI Awan Google

Anda boleh menjalankan Google Cloud CLI dalam konsol Google Cloud tanpa memasang Google Cloud CLI. Untuk menjalankan CLI gcloud dalam konsol Google Cloud, gunakan Cloud Shell

## Sediakan persekitaran
Dalam bahagian ini, anda mentakrifkan beberapa pembolehubah untuk nama dan lokasi sumber anda. Pembolehubah ini digunakan oleh arahan Google Cloud CLI semasa anda menggunakan sumber

Sepanjang tutorial ini, melainkan dinyatakan sebaliknya, anda memasukkan semua arahan dalam Cloud Shell atau persekitaran pembangunan setempat anda

Gantikan
dengan ID projek anda sendiri. Jika mahu, berikan akhiran nama anda sendiri untuk sumber untuk membantu mencari dan mengenal pastinya, seperti
PROJECT_ID


aplikasi
Nyatakan dua wilayah, seperti
dan
kami-barat1
, dan zon dalam salah satu wilayah tersebut, seperti
kami-barat2
. Zon ini menentukan tempat VM asas awal dicipta yang digunakan untuk mencipta imej bagi kumpulan contoh terurus

kami-barat1-a
Akhir sekali, tetapkan domain yang digunakan untuk tapak web statik anda, seperti
example.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Buat VPC dan subnet
Untuk menyediakan akses rangkaian kepada VM, anda membuat Awan Peribadi Maya (VPC) dan subnet. Memandangkan anda memerlukan kumpulan contoh terurus dalam dua wilayah, anda membuat satu subnet dalam setiap rantau. Untuk mendapatkan maklumat lanjut tentang kelebihan mod subnet tersuai untuk mengurus julat alamat IP yang digunakan dalam persekitaran anda, lihat Gunakan rangkaian VPC mod tersuai

Buat VPC dengan mod subnet tersuai:
rangkaian pengiraan gcloud mencipta rangkaian-$NAME_SUFFIX --subnet-mode=custom
Sekarang buat dua subnet dalam VPC baharu, satu untuk setiap rantau. Tentukan julat alamat anda sendiri, seperti
dan
10.1.0.0/20
, yang sesuai dalam julat rangkaian anda:
10.2.0.0/20
gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 gcloud compute networks subnets create \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ WILAYAH2
## Buat peraturan firewall
Untuk membenarkan trafik rangkaian mengalir dengan betul dalam VPC, gunakan peraturan tembok api

Buat peraturan tembok api untuk membenarkan trafik web dan semakan kesihatan untuk pengimbang beban dan kumpulan contoh terurus:
gcloud compute firewall-rules buat 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
Peraturan HTTP membenarkan trafik ke mana-mana VM di mana
http-servertag digunakan, dan dari mana-mana sumber menggunakan
0.0.0.0/0julat. Untuk peraturan semakan kesihatan, julat lalai untuk Google Cloud ditetapkan untuk membolehkan platform menyemak kesihatan sumber dengan betul

Untuk membenarkan trafik SSH untuk konfigurasi awal imej VM asas, skop peraturan tembok api ke persekitaran anda menggunakan
--source-rangeparameter. Anda mungkin perlu bekerjasama dengan pasukan rangkaian anda untuk menentukan julat sumber yang digunakan oleh organisasi anda

Gantikan
dengan skop alamat IP anda sendiri:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules buat allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- julat sumber=
IP_ADDRESS_SCOPE
Selepas anda mencipta peraturan firewall, sahkan bahawa tiga peraturan telah ditambahkan:
gcloud mengira senarai peraturan firewall \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Contoh output berikut menunjukkan tiga peraturan telah dibuat dengan betul:
NAMA RANGKAIAN ARAH KEUTAMAAN BENARKAN benarkan-semak-kesihatan-apl rangkaian-apl INGRESS 1000 tcp:80 benarkan-apl rangkaian-http-apl INGRESS 1000 tcp:80 benarkan-apl rangkaian-aplikasi-ssh INGRESS 1000 tcp:22
## Cipta dan konfigurasikan imej VM asas
Untuk membuat VM serupa yang anda gunakan tanpa konfigurasi tambahan, anda menggunakan imej VM tersuai. Imej ini menangkap konfigurasi OS dan Apache, dan digunakan untuk mencipta setiap VM dalam kumpulan contoh terurus dalam langkah seterusnya

Pada VM, anda mencipta asas
index.html fail pada cakera berterusan dan
lekapkannya ke
/var/www/example.com. Fail konfigurasi Apache di
/etc/apache2/sites-available/example.com.conf menyajikan kandungan web daripada
lokasi cakera berterusan yang dipasang

Rajah berikut menunjukkan halaman HTML asas yang disediakan oleh Apache yang disimpan pada cakera berterusan:
Anda membina persekitaran ini dalam langkah berikut

Buat VM asas dengan cakera berterusan yang dilampirkan:
contoh pengiraan gcloud mencipta vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standard-1 \ --subnet=subnet-$NAME_SUFFIX-$REGION1 \ --tags=http-server \ --image=debian-10-buster-v20210420 \ --image-project=debian-cloud \ --boot-disk-size=10GB \ --boot-disk-type=pd-balanced \ --boot-disk- device-name=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
Anda menggunakan parameter yang ditakrifkan pada permulaan dokumen ini untuk menamakan VM dan menyambung ke subnet yang betul. Nama juga diberikan daripada parameter untuk cakera but dan cakera data

Untuk memasang dan mengkonfigurasi tapak web mudah, mula-mula sambung ke VM asas menggunakan SSH:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Dalam sesi SSH anda kepada VM, buat skrip untuk mengkonfigurasi VM dalam editor pilihan anda. Contoh berikut menggunakan Nano sebagai editor:
konfigurasi nano-vm.
Tampalkan skrip konfigurasi berikut ke dalam fail:
bin/bash NAME_SUFFIX=
app# Cipta direktori untuk fail tapak web asas sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Cari nama cakera, kemudian format dan lekapkannya DISK_NAME="google-disk-base-$NAME_SUFFIX"DISK_PATHfind /dev/disk/by-id -name DISK_NAME}"| xargs -Ireadlink -fsudo mkfs.ext4 -m 0 - E lazy_itable_init=0,lazy_journal_init=0,buang $DISK_PATH sudo mount -o buang, lalai $DISK_PATH /var/www/example.com # Pasang Apache sudo apt-get update&& sudo apt-get -y install apache2 # Tulis fail HTML asas ke yang dipasang cakera berterusan sudo tee -a /var/www/example.com/index.html >/dev/null EOF'    Contoh HA / DR   
Selamat datang ke tapak web Compute Engine dengan failover hangat ke Cloud Storagep>#
*: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 # Dayakan fail konfigurasi Apache dan muat semula perkhidmatan sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Kemas kini
pembolehubah untuk memadankan nilai yang ditetapkan pada permulaan dokumen ini, seperti
Apl NAME_SUFFIX

Tulis fail dan keluar dari editor anda. Sebagai contoh, dalam Nano yang anda gunakan
Ctrl-Oto menulis fail, kemudian keluar dengan
Ctrl-X

Jadikan skrip konfigurasi boleh laku, kemudian jalankannya:
chmod +x configure-vm../configure-vm.
Keluar dari sesi SSH ke VM:
keluar
Dapatkan alamat IP VM dan gunakan
curl untuk melihat halaman web asas:
curl $(gcloud compute instance describe vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Laman web asas dikembalikan, seperti yang ditunjukkan dalam contoh output berikut:
    Contoh HA / DR   
Selamat datang ke tapak web Compute Engine dengan failover hangat ke Cloud Storagep>#

# Cipta imej VM asas gcloud compute imej cipta imej-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud compute imej cipta imej-disk-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Cipta templat contoh gcloud compute instance-templates buat templat-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standard- 1 \ --subnet=projects/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-server \ --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 \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=ya gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-standard-1 \ --subnet=projects/$PROJECT_ID/regions/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-server \ --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 \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Buat pemeriksaan kesihatan untuk kejadian VM gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Buat kumpulan instance terurus gcloud compute instance-groups managed create instance-group-$NAME_SUFFIX-$REGION1 \ --template=template-$NAME_SUFFIX-$REGION1 \ --size=2 \ --region=$REGION1 \ --health-check=http-basic-check-$NAME_SUFFIX gcloud compute instance-groups berjaya mencipta instance-group -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Buat dan konfigurasikan pengimbang beban
Untuk pengguna mengakses tapak web anda, anda perlu membenarkan trafik melalui VM yang dijalankan dalam kumpulan contoh terurus. Anda juga mahu mengubah hala trafik secara automatik ke VM baharu jika terdapat kegagalan zon dalam kumpulan contoh terurus

Dalam bahagian berikut, anda mencipta pengimbang beban HTTPS luaran dengan perkhidmatan hujung belakang untuk trafik HTTP pada port 80, gunakan pemeriksaan kesihatan yang dibuat dalam langkah sebelumnya dan petakan alamat IP luaran melalui perkhidmatan hujung belakang.

Untuk mendapatkan maklumat lanjut, lihat Cara menyediakan pengimbang beban HTTP luaran yang mudah

Cipta dan konfigurasikan pengimbang beban untuk aplikasi anda:
# Konfigurasikan peraturan port untuk port HTTP 80 gcloud compute instance-groups set-named-ports \ instance-group-$NAME_SUFFIX-$REGION1 \ --named-ports http:80 \ --region $REGION1 gcloud compute instance-groups set- named-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Buat perkhidmatan hujung belakang dan tambahkan kumpulan contoh terurus padanya gcloud compute backend-services create \ web- backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --gcloud compute backend-services add-backend \ web- backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --gcloud compute global backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Buat peta URL untuk perkhidmatan backend gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Konfigurasikan pemajuan untuk trafik HTTP gcloud compute target-http-proxyes create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- Peraturan pemajuan pengiraan gcloud $NAME_SUFFIX buat \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Dapatkan alamat IP peraturan pemajuan untuk trafik web:
IP_ADDRESSgcloud compute forwarding-rules menerangkan http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
guna
curl, atau buka penyemak imbas web anda, untuk melihat tapak web menggunakan alamat IP pengimbang beban dari langkah sebelumnya:
curl $IP_ADDRESS
Pengimbang beban mengambil masa beberapa minit untuk menyelesaikan penggunaan dan mengarahkan trafik dengan betul ke hujung belakang anda. Ralat HTTP 404 dikembalikan jika pengimbang beban masih digunakan. Jika perlu, tunggu beberapa minit dan cuba akses tapak web sekali lagi

Laman web asas dikembalikan, seperti yang ditunjukkan dalam contoh output berikut:
    Contoh HA / DR   
Selamat datang ke tapak web Compute Engine dengan failover hangat ke Cloud Storagep>#
< index.html     HA / DR example   
Welcome to a test static web server with warm failover from Cloud Storagep> 

example.com
Get the details of the Cloud DNS zone:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

Cloud DNS must be authoritative for your domain. Create nameserver (NS) records with your domain registrar that point to your Cloud DNS zone. Use the nameserver addresses returned in the previous step

For more information and an example using Google Domains, see How to update name servers

In your Cloud DNS zone, add a record for
wwwusing the load balancer IP address obtained in a previous section:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
This record directs user requests for the website through the load balancer to the managed instance groups. A TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user

Create a record to be used by the Cloud Storage bucket for the static website:
gcloud dns record-sets transaction add c.storage.googleapis.com. \ --name=static-web.$DOMAIN \ --ttl=300 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
This example uses
static-webas the subdomain. Leave the
c.storage.googleapis.com.Again, a TTL of 300 seconds is set to reduce the length of time the cached DNS record exists for a user
Finally,the DNS record additions to the zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
## Verify and test the DNS zone and records
Let's review the resource deployments before simulating a zone failure. All of the resources have been created to support the environment, as shown in the following image:
- Cloud DNS zone records direct users to the load balancer for distribution across the managed instance group VMs

- A Cloud Storage bucket is configured to host static web pages if there's an outage with the managed instance groups

- The Cloud DNS zone is configured to use the static site in Cloud Storage, but doesn't currently resolve requests to the storage bucket

To view the DNS records and test resolution, you must resolve addresses against the Cloud DNS servers. In production deployments, make sure you test and verify the addresses resolve correctly, then update your own DNS servers to resolve appropriately. This document doesn't detail the steps to update your own DNS servers, only how to verify traffic flows correctly under normal and failover conditions

Get the details of the Cloud DNS zone again:
gcloud dns managed-zones describe zone-$NAME_SUFFIX
The following example output shows the
nameServersfor the zone, such as
ns-cloud-b1.googledomains.com

 kind: dns#managedZone name: zone-app nameServers: - ns-cloud-b1.googledomains.com. - ns-cloud-b2.googledomains.com. - ns-cloud-b3.googledomains.com. - ns-cloud-b4.googledomains.com

To resolve the
wwwrecord for your Cloud DNS zone against one of these name servers, use the
digcommand:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
This example uses the
ns-cloud-b1.googledomains.comnameserver address returned from the previous
describecommand. Provide your own nameserver address shown in the output of the previous command
The following example output shows that the record resolves to the IP address of the load balancer. If you used this nameserver to access the address, such as using
curland the
--resolveparameter with the Cloud DNS nameserver, the default page would be displayed from one of the managed instance groups behind the load balancer

;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
Use the
digcommand again to verify the DNS record for the static website in Cloud Storage:
dig @ns-cloud-b1.googledomains.com static-web.$DOMAIN
The following example output shows that the record resolves to Cloud Storage that can serve the static content from the storage bucket:
;DiG [email protected] static-web.example.com ; (1 server found);; QUESTION SECTION: ;static-web.example.com. IN A ;; ANSWER SECTION: static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail over to the Cloud Storage bucket
In a production environment, you might get an alert using Cloud Monitoring or other monitoring solution when there's a problem with the managed instance groups. This alert prompts a human to understand the scope of the failure before you update the Cloud DNS records to redirect traffic to the Cloud Storage-hosted static website. An alternative approach is to use your monitoring solution to automatically respond to outages with the managed instance groups

When you fail over, Cloud DNS resolves traffic to the Cloud Storage-hosted static website, as shown in the following image:
When you or your monitoring solution determine the most appropriate action

is to update the Cloud DNS records to direct traffic to Cloud Storage,
update the existing DNS
A record. In this document, you manually update the
Cloud DNS records to redirect traffic to the Cloud Storage-hosted
static website

To fail over the Cloud DNS records, remove the existing
Arecord that resolves to the load balancer:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
Create a
CNAMErecord for
wwwthat points to the Cloud Storage-hosted content:
gcloud dns record-sets transaction add static-web.$DOMAIN \ --name=www.$DOMAIN. \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand to confirm the
wwwrecord now resolves to the address of the Cloud Storage static website:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the
www.example.comrecord resolves to the CNAME record of the Cloud Storage static website. Requests to access
www.example.comare redirected to the Cloud Storage bucket, which displays the static website:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 30 IN CNAME static-web.example.com. static-web.example.com. 300 IN CNAME c.storage.googleapis.com

## Fail back to the managed instance groups
After issues with the managed instance groups are resolved, you can fail back to serving content from the load-balanced managed instance groups by updating the Cloud DNS records again. Again, a human might make this decision using Cloud Monitoring insights for the health of the managed instance groups. Or, you could use automation to respond to the restored health of the managed instance group. In this document, you manually update the Cloud DNS records

When you fail back, Cloud DNS resolves traffic to the managed instance groups again, as shown in the following image:
Remove the
wwwCNAME record that redirects traffic to the Cloud Storage-hosted content:
gcloud dns record-sets transaction start \ --zone=zone-$NAME_SUFFIX gcloud dns record-sets transaction remove static-web.$DOMAIN \ --name=www.$DOMAIN \ --ttl=30 \ --type=CNAME \ --zone=zone-$NAME_SUFFIX
Add an
Arecord to point to the load balancer in front of the managed instance groups again:

gcloud dns record-sets transaction add $IP_ADDRESS \ --name=www.$DOMAIN \ --ttl=300 \ --type=A \ --zone=zone-$NAME_SUFFIX
the updates to the Cloud DNS zone:
gcloud dns record-sets transaction execute \ --zone=zone-$NAME_SUFFIX
Use the
digcommand one more time to confirm the
wwwrecord resolves to the address of the load balancer in front of the managed instance groups again:
dig @ns-cloud-b1.googledomains.com www.$DOMAIN
The following example output shows that the record resolves to the IP address of the load balancer and traffic would be served from one of the managed instance groups:
;DiG [email protected] www.example.com ; (1 server found);; QUESTION SECTION: ;www.example.com. IN A ;; ANSWER SECTION: www.example.com. 300 IN A 35.227.253.90
## 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 DNS zone and records:
touch empty-file gcloud dns record-sets import -z zone-$NAME_SUFFIX \ --delete-all-existing \ empty-file rm empty-file gcloud dns managed-zones delete zone-$NAME_SUFFIX
Delete the Cloud Storage bucket:
gsutil rm -r gsstatic-web.$DOMAIN
Delete the load balancer configuration:
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
Delete the managed instance groups and health check:
gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 --quiet gcloud compute instance-groups managed delete \ instance-group-$NAME_SUFFIX-$REGION2 \ --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 \ template-$NAME_SUFFIX-$REGION1 --quiet gcloud compute instance-templates delete \ 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 \ --zone=$ZONE --quiet
Delete the firewall rules


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
Delete the subnet and VPC

gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION1 --region=$REGION1 --quiet gcloud compute networks subnets delete \ subnet-$NAME_SUFFIX-$REGION2 --region=$REGION2 --quiet gcloud compute networks delete network-$NAME_SUFFIX --quiet
## What's next
- For an alternative approach that uses external HTTP(S) Load Balancing instead of Cloud DNS to control the failover, see Deploy a warm recoverable web server with Compute Engine and Cloud Storage. This pattern is useful if you don't have, or don't 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.