Dokumen iki ditrapake kanggo arsitek lan wong sing kerja ing tim operasi lan administratif. Dokumen kasebut nggambarake pola conto sing bisa digunakake kanggo panyebaran dhewe ing Google Cloud

Ing pola iki, Cloud DNS ngarahake lalu lintas menyang conto Compute Engine ing grup conto sing dikelola sing nyedhiyakake konten kasebut. Yen ana gangguan, sampeyan nganyari zona DNS Cloud lan gagal menyang situs statis ing Cloud Storage

Kanggo ngrampungake tutorial iki, sampeyan butuh jeneng domain kadhaptar sing sampeyan kontrol lan pengin digunakake karo dokumen iki

Ing panyebaran produksi, situs web sampeyan bisa uga kalebu luwih akeh file lan kode aplikasi tambahan ing mesin virtual grup instan (VM) sing dikelola tinimbang sing ditampilake ing dokumen iki. Cloud Storage banjur dadi tuan rumah versi statis sing luwih winates sing nyedhiyakake fungsi minimal. Ing skenario failover anget, pangguna ndeleng situs web winates iki nganti grup conto sing dikelola pulih lan bisa nglayani lalu lintas kanggo pengalaman situs web lengkap

Ing tutorial iki, sampeyan nggunakake sumber daya kanggo nggawe lingkungan kaya sing ditampilake ing gambar ing ngisor iki:
Yen sampeyan kudu gagal, nganyari konfigurasi Cloud DNS kanggo ngarahake lalu lintas menyang Cloud Storage, kaya sing ditampilake ing gambar ing ngisor iki:
Pola failover anget iki ngimbangi biaya kanggo mbukak grup conto liyane sing dikelola ing wilayah liyane sing mung sampeyan gunakake nalika wilayah utama gagal. Biaya situs statis nggunakake Cloud Storage luwih murah tinimbang mbukak grup conto liyane sing dikelola, nanging ana wektu tundha sing cendhak nalika sampeyan nganyari Cloud DNS ing antarane opsi hosting. Pengalaman situs web winates ing Cloud Storage luwih apik tinimbang situs web sing ora kasedhiya lan pengalaman pelanggan sing ora apik

Kanggo pendekatan alternatif sing nggunakake HTTP(S) Load Balancing tinimbang Cloud DNS kanggo ngontrol failover, deleng Nyebarake server web sing bisa dibalekake kanthi anget karo Compute Engine lan Cloud Storage. Pola iki migunani yen sampeyan ora duwe, utawa ora pengin nggunakake, Cloud DNS

Kanggo mbukak aplikasi sing dipercaya ing Google Cloud, disaranake sampeyan ngrancang infrastruktur aplikasi kanggo nangani gangguan. Gumantung ing aplikasi lan kabutuhan bisnis, sampeyan bisa uga mbutuhake failover kadhemen, failover anget, utawa pola failover panas. Kanggo informasi luwih lengkap babagan carane nemtokake pendekatan sing paling apik kanggo aplikasi sampeyan dhewe, waca Pandhuan perencanaan pemulihan bencana

Dokumen iki nggunakake server web Apache dhasar, nanging pendekatan sing padha kanggo panyebaran infrastruktur ditrapake kanggo lingkungan aplikasi liyane sing kudu sampeyan gawe.

## Tujuan

- Gawe klompok conto sing dikelola regional kanthi gambar VM khusus

- Nggawe ember Cloud Storage

- Nggawe lan ngatur zona DNS Cloud

- Tes failover server web sing anget kanthi cathetan Cloud DNS sing dianyari

- Tes pemulihan lan gagal maneh kanthi cathetan Cloud DNS sing dianyari

## Biaya
Tutorial iki nggunakake komponen Google Cloud sing bisa ditagih ing ngisor iki:
Kanggo nggawe prakiraan biaya adhedhasar proyeksi panggunaan sampeyan,
nggunakake kalkulator rega

## Sadurunge miwiti
Sawetara langkah ing dokumen iki bisa uga ora bisa digunakake kanthi bener yen organisasi sampeyan ngetrapake kendala ing lingkungan Google Cloud sampeyan. Yen ngono, sampeyan bisa uga ora bisa ngrampungake tugas kaya nggawe alamat IP umum utawa kunci akun layanan. Yen sampeyan nggawe panjalukan sing ngasilake kesalahan babagan kendala, deleng carane Ngembangake aplikasi ing lingkungan Google Cloud sing diwatesi

- Mlebu menyang akun Google Cloud. Yen sampeyan anyar karo Google Cloud, gawe akun kanggo ngevaluasi kinerja produk ing skenario nyata. Pelanggan anyar uga entuk kridit gratis $300 kanggo mbukak, nyoba, lan masang beban kerja

-
Ing konsol Google Cloud, ing kaca pamilih proyek, pilih utawa gawe proyek Google Cloud

-
Priksa manawa tagihan diaktifake kanggo proyek Cloud sampeyan. Sinau carane mriksa yen tagihan diaktifake ing proyek

-
Aktifake Compute Engine API

- Instal lan miwiti Google Cloud CLI

-
Ing konsol Google Cloud, ing kaca pamilih proyek, pilih utawa gawe proyek Google Cloud

-
Priksa manawa tagihan diaktifake kanggo proyek Cloud sampeyan. Sinau carane mriksa yen tagihan diaktifake ing proyek

-
Aktifake Compute Engine API

- Instal lan miwiti Google Cloud CLI

Sampeyan bisa mbukak Google Cloud CLI ing Google Cloud console tanpa nginstal Google Cloud CLI. Kanggo mbukak CLI gcloud ing konsol Google Cloud, gunakake Cloud Shell

## Siapke lingkungan
Ing bagean iki, sampeyan nemtokake sawetara variabel kanggo jeneng sumber daya lan lokasi. Variabel iki digunakake dening perintah Google Cloud CLI nalika sampeyan nggunakake sumber daya

Sajrone tutorial iki, kajaba dicathet, sampeyan ngetik kabeh printah ing Cloud Shell utawa lingkungan pangembangan lokal

Ganti
karo ID project dhewe. Yen dikarepake, wenehake seselan jeneng sampeyan dhewe kanggo sumber daya kanggo mbantu nggoleki lan ngenali, kayata
PROJECT_ID


app
Nemtokake rong wilayah, kayata
lan
us-kulon1
, lan zona ing salah sawijining wilayah kasebut, kayata
us-kulon2
. Zona iki nemtokake endi VM basis wiwitan digawe sing digunakake kanggo nggawe gambar kanggo grup conto sing dikelola

us-kulon1-a
Pungkasan, setel domain sing digunakake kanggo situs web statis, kayata
contone.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Nggawe VPC lan subnet
Kanggo nyedhiyakake akses jaringan menyang VM, sampeyan nggawe Virtual Private Cloud (VPC) lan subnet. Yen sampeyan mbutuhake grup conto sing dikelola ing rong wilayah, sampeyan nggawe subnet ing saben wilayah. Kanggo informasi luwih lengkap babagan kaluwihan mode subnet khusus kanggo ngatur kisaran alamat IP sing digunakake ing lingkungan sampeyan, deleng Gunakake jaringan VPC mode khusus.

Gawe VPC nganggo mode subnet khusus:
jaringan komputasi gcloud nggawe jaringan-$NAME_SUFFIX --subnet-mode=custom
Saiki gawe rong subnet ing VPC anyar, siji kanggo saben wilayah. Nemtokake kisaran alamat sampeyan dhewe, kayata
lan
10.1.0.0/20
, sing cocog karo jangkauan jaringan sampeyan:
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=$ WILAYAH 2
## Nggawe aturan firewall
Supaya lalu lintas jaringan mili kanthi bener ing VPC, gunakake aturan firewall

Gawe aturan firewall kanggo ngidini lalu lintas web lan mriksa kesehatan kanggo load balancer lan grup conto sing dikelola:
gcloud compute firewall-rules nggawe 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
Aturan HTTP ngidini lalu lintas menyang VM apa wae
http-servertag ditrapake, lan saka sumber apa wae nggunakake
0.0.0.0/0 sawetara. Kanggo aturan mriksa kesehatan, kisaran standar kanggo Google Cloud disetel supaya platform mriksa kesehatan sumber daya kanthi bener

Kanggo ngidini lalu lintas SSH kanggo konfigurasi awal saka gambar VM dhasar, orane katrangan aturan firewall kanggo lingkungan nggunakake
--source-rangeparameter. Sampeyan bisa uga kudu nggarap tim jaringan kanggo nemtokake kisaran sumber apa sing digunakake organisasi sampeyan

Ganti
karo skop alamat IP sampeyan dhewe:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules nggawe allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- sumber-rentang =
IP_ADDRESS_SCOPE
Sawise nggawe aturan firewall, verifikasi yen telung aturan wis ditambahake:
daftar aturan firewall komputasi gcloud \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Output conto ing ngisor iki nuduhake telung aturan wis digawe kanthi bener:
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
## Nggawe lan ngatur gambar VM dhasar
Kanggo nggawe VMs podho rupo sing masang tanpa konfigurasi tambahan, sampeyan nggunakake gambar VM adat. Gambar iki njupuk konfigurasi OS lan Apache, lan digunakake kanggo nggawe saben VM ing grup conto sing dikelola ing langkah sabanjure.

Ing VM, sampeyan nggawe dhasar
file index.html ing disk ngengkel lan
pasang menyang
/var/www/example.com. File konfigurasi Apache ing
/etc/apache2/sites-available/example.com.conf nyedhiyakake konten web saka
lokasi disk persisten sing dipasang

Diagram ing ngisor iki nuduhake kaca HTML dhasar sing dilayani dening Apache sing disimpen ing disk sing terus-terusan:
Sampeyan mbangun lingkungan iki ing langkah-langkah ing ngisor iki

Gawe VM dhasar kanthi disk persisten sing dipasang:
conto komputasi gcloud nggawe vm-base-$NAME_SUFFIX \ --zone=$ZONE \ --machine-type=n1-standar-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- jeneng piranti=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
Sampeyan nggunakake paramèter sing ditetepake ing wiwitan dokumen iki kanggo jeneng VM lan nyambung menyang subnet sing bener. Jeneng uga diutus saka paramèter kanggo boot disk lan data disk

Kanggo nginstal lan ngatur situs web sing prasaja, sambungake menyang VM dhasar nggunakake SSH:
gcloud ngitung ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Ing sesi SSH sampeyan menyang VM, gawe skrip kanggo ngatur VM ing editor sing dipilih. Conto ing ngisor iki nggunakake Nano minangka editor:
nano configure-vm.
Tempel skrip konfigurasi ing ngisor iki menyang file:
bin/bash NAME_SUFFIX=
app# Gawe direktori kanggo file situs web dhasar sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Temokake jeneng disk, banjur format lan pasang 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 discard,defaults $DISK_PATH /var/www/example.com # Instal Apache sudo apt-get update&& sudo apt-get -y install apache2 # Tulis file HTML dhasar menyang disk persisten sing dipasang sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'    HA / DR conto   
Sugeng rawuh ing situs web Compute Engine kanthi failover anget menyang 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 # Aktifake file konfigurasi Apache lan muat ulang layanan sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Nganyari ing
variabel sing cocog karo nilai sing disetel ing wiwitan dokumen iki, kayata
Aplikasi NAME_SUFFIX

Tulis file lan metu saka editor sampeyan. Contone, ing Nano sampeyan nggunakake
Ctrl-Oto nulis file kasebut, banjur metu nganggo
Ctrl-X

Gawe skrip konfigurasi bisa dieksekusi, banjur jalanake:
chmod +x configure-vm../configure-vm.
Metu sesi SSH menyang VM:
metu
Entuk alamat IP VM lan gunakake
curl kanggo ndeleng kaca web dhasar:
curl $(gcloud compute instance njlèntrèhaké vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Situs web dhasar bali, kaya sing ditampilake ing conto output ing ngisor iki:
    HA / DR conto   
Sugeng rawuh ing situs web Compute Engine kanthi failover anget menyang Cloud Storagep>

# Gawe gambar VM dhasar gambar komputasi gcloud nggawe gambar-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gambar komputasi gcloud nggawe disk gambar-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Gawe cithakan conto gcloud compute instance-templates gawe cithakan-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standar- 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,otomatis mbusak=ya gcloud compute instance-templates nggawe cithakan-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-standar-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 # Gawe priksa kesehatan kanggo instance VM gcloud compute health-checks create http-basic-check-$NAME_SUFFIX \ --port 80 # Gawe grup instance sing dikelola gcloud compute instance-groups sing dikelola nggawe 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 ngatur nggawe instance-group -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Nggawe lan ngatur imbangan beban
Kanggo pangguna ngakses situs web sampeyan, sampeyan kudu ngidini lalu lintas menyang VM sing mlaku ing grup conto sing dikelola. Sampeyan uga pengin ngarahake lalu lintas kanthi otomatis menyang VM anyar yen ana kegagalan zona ing grup conto sing dikelola

Ing bagean ing ngisor iki, sampeyan nggawe pangimbang beban HTTPS eksternal kanthi layanan backend kanggo lalu lintas HTTP ing port 80, gunakake pemeriksaan kesehatan sing digawe ing langkah sadurunge, lan peta alamat IP eksternal menyang layanan backend.

Kanggo informasi luwih lengkap, waca Cara nyiyapake imbangan beban HTTP eksternal sing prasaja

Gawe lan konfigurasi load balancer kanggo aplikasi sampeyan:
# Konfigurasi aturan port kanggo 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 # Gawe layanan backend lan tambahake grup conto sing dikelola menyang gcloud compute backend-services create \ web- backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global compute backend-services add-backend \ web- backend-service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global compute backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Gawe peta URL kanggo layanan backend gcloud compute url-maps nggawe peta-web-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Konfigurasi penerusan kanggo lalu lintas HTTP gcloud ngitung target-http-proxies nggawe \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud compute forwarding-rules nggawe \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Entuk alamat IP aturan penerusan kanggo lalu lintas web:
IP_ADDRESSgcloud compute forwarding-aturan nggambarake http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Gunakake
curl, utawa bukak browser web, kanggo ndeleng situs web nggunakake alamat IP load balancer saka langkah sadurunge:
nggulung $IP_ADDRESS
Butuh sawetara menit kanggo load balancer rampung nyebarake lan ngarahake lalu lintas menyang mburi sampeyan kanthi bener. Kesalahan HTTP 404 bali yen load balancer isih digunakake. Yen perlu, ngenteni sawetara menit lan coba ngakses situs web maneh

Situs web dhasar bali, kaya sing ditampilake ing conto output ing ngisor iki:
    HA / DR conto   
Sugeng rawuh ing situs web Compute Engine kanthi failover anget menyang 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.