Acest document este destinat arhitecților și persoanelor care lucrează în operațiuni și echipe administrative. Documentul descrie un exemplu de model pe care îl puteți utiliza pentru propriile implementări în Google Cloud

În acest model, Cloud DNS direcționează traficul către instanțele Compute Engine din grupurile de instanțe gestionate care difuzează conținutul. Într-o întrerupere, actualizați zona Cloud DNS și treceți la un site static în Cloud Storage

Pentru a finaliza acest tutorial, aveți nevoie de un nume de domeniu înregistrat pe care îl controlați și pe care doriți să îl utilizați cu acest document

În implementările de producție, site-ul dvs. web include probabil mult mai multe fișiere și cod de aplicație suplimentar pe mașinile virtuale (VM) ale grupului de instanțe gestionate decât se arată în acest document. Cloud Storage găzduiește apoi o versiune statică mai limitată, care oferă funcționalitate minimă. Într-un scenariu de failover cald, utilizatorii văd acest site limitat până când grupurile de instanțe gestionate își revin și pot furniza trafic pentru experiența completă a site-ului

În acest tutorial, implementați resurse pentru a crea un mediu așa cum se arată în imaginea următoare:
Când trebuie să faceți un failover, actualizați configurația Cloud DNS pentru a direcționa traficul către Cloud Storage, așa cum se arată în următoarea imagine:
Acest model de failover la cald echilibrează costul rulării unui alt grup de instanțe gestionat într-o regiune diferită pe care o utilizați numai atunci când regiunea principală eșuează. Costul unui site static care utilizează Cloud Storage este mai mic decât rularea unui alt grup de instanțe gestionat, dar există o scurtă întârziere când actualizați Cloud DNS între opțiunile de găzduire. Experiența limitată a site-ului în Cloud Storage este mai bună decât un site web complet indisponibil și o experiență slabă pentru clienți

Pentru o abordare alternativă care utilizează echilibrarea încărcăturii HTTP(S) externă în loc de Cloud DNS pentru a controla failover-ul, consultați Implementarea unui server web recuperabil la cald cu Compute Engine și Cloud Storage. Acest model este util dacă nu aveți sau nu doriți să utilizați Cloud DNS

Pentru a rula aplicații de încredere în Google Cloud, vă recomandăm să vă proiectați infrastructura aplicației pentru a gestiona întreruperile. În funcție de aplicația dvs. și de nevoile de afaceri, este posibil să aveți nevoie de un model de failover la rece, de failover la cald sau de un model de failover la cald. Pentru mai multe informații despre cum să determinați cea mai bună abordare pentru propriile aplicații, consultați ghidul de planificare a recuperării în caz de dezastru

Acest document folosește un server web Apache de bază, dar aceeași abordare a implementării infrastructurii se aplică și altor medii de aplicații pe care trebuie să le creați.

## Obiective

- Creați grupuri regionale de instanțe gestionate cu o imagine VM personalizată

- Creați o găleată de stocare în cloud

- Creați și configurați o zonă Cloud DNS

- Testați failover-ul serverului web cald cu înregistrări actualizate Cloud DNS

- Testați recuperarea și failback-ul cu înregistrările Cloud DNS actualizate

## Cheltuieli
Acest tutorial folosește următoarele componente facturabile ale Google Cloud:
Pentru a genera o estimare a costurilor bazată pe utilizarea proiectată,
utilizați calculatorul de prețuri

## Înainte de a începe
Este posibil ca unii dintre pașii din acest document să nu funcționeze corect dacă organizația dvs. aplică constrângeri mediului dvs. Google Cloud. În acest caz, este posibil să nu puteți finaliza sarcini precum crearea de adrese IP publice sau chei de cont de serviciu. Dacă faceți o solicitare care returnează o eroare despre constrângeri, vedeți cum să dezvoltați aplicații într-un mediu Google Cloud limitat

- Conectați-vă la contul dvs. Google Cloud. Dacă sunteți nou în Google Cloud, creați un cont pentru a evalua modul în care produsele noastre funcționează în scenarii din lumea reală. Clienții noi primesc, de asemenea, 300 USD în credite gratuite pentru a rula, a testa și a implementa sarcini de lucru

-
În consola Google Cloud, pe pagina de selectare a proiectelor, selectați sau creați un proiect Google Cloud

-
Asigurați-vă că facturarea este activată pentru proiectul dvs. Cloud. Aflați cum să verificați dacă facturarea este activată într-un proiect

-
Activați API-ul Compute Engine

- Instalați și inițializați CLI Google Cloud

-
În consola Google Cloud, pe pagina de selectare a proiectelor, selectați sau creați un proiect Google Cloud

-
Asigurați-vă că facturarea este activată pentru proiectul dvs. Cloud. Aflați cum să verificați dacă facturarea este activată într-un proiect

-
Activați API-ul Compute Engine

- Instalați și inițializați CLI Google Cloud

Puteți rula CLI Google Cloud în consola Google Cloud fără a instala CLI Google Cloud. Pentru a rula CLI gcloud în consola Google Cloud, utilizați Cloud Shell

## Pregătiți mediul
În această secțiune, definiți câteva variabile pentru numele și locațiile resurselor dvs. Aceste variabile sunt folosite de comenzile CLI Google Cloud pe măsură ce implementați resursele

Pe parcursul acestui tutorial, dacă nu se menționează altfel, introduceți toate comenzile în Cloud Shell sau în mediul dvs. de dezvoltare local

A inlocui
cu propriul ID de proiect. Dacă doriți, furnizați propriul sufix de nume pentru resurse care să vă ajute să le căutați și să le identificați, cum ar fi
PROJECT_ID


aplicația
Specificați două regiuni, cum ar fi
și
noi-vest1
, și o zonă din cadrul uneia dintre acele regiuni, cum ar fi
noi-vest2
. Această zonă definește locul unde este creată VM de bază inițială care este utilizată pentru a crea o imagine pentru grupul de instanțe gestionat

noi-vest1-a
În cele din urmă, setați un domeniu care este utilizat pentru site-ul dvs. static, cum ar fi
exemplu.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Creați un VPC și o subrețea
Pentru a oferi acces la rețea la VM, creați Virtual Private Cloud (VPC) și subrețele. Deoarece aveți nevoie de grupuri de instanțe gestionate în două regiuni, creați o subrețea în fiecare regiune. Pentru mai multe informații despre avantajele modului de subrețea personalizat pentru a gestiona intervalele de adrese IP utilizate în mediul dvs., consultați Utilizarea rețelelor VPC în mod personalizat

Creați VPC-ul cu un mod de subrețea personalizat:
rețelele de calcul gcloud creează rețea-$NAME_SUFFIX --subnet-mode=custom
Acum creați două subrețele în noul VPC, câte una pentru fiecare regiune. Definiți-vă propriile intervale de adrese, cum ar fi
și
10.1.0.0/20
, care se încadrează în domeniul dvs. de rețea:
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=$ REGIUNEA2
## Creați reguli de firewall
Pentru a permite traficului de rețea să circule corect în VPC, utilizați regulile de firewall

Creați reguli de firewall pentru a permite traficul web și verificări de sănătate pentru echilibratorul de încărcare și grupurile de instanțe gestionate:
gcloud compute firewall-rules create allow-http-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALOW \ --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
Regula HTTP permite traficul către orice VM unde
Se aplică http-servertag și din orice sursă folosind
0.0.0.0/0interval. Pentru regula de verificare a stării de sănătate, intervalele implicite pentru Google Cloud sunt setate pentru a permite platformei să verifice corect starea de sănătate a resurselor

Pentru a permite traficul SSH pentru configurația inițială a unei imagini de bază VM, aplicați regula firewall-ului la mediul dvs. utilizând
--source-rangeparameter. Este posibil să fie necesar să colaborați cu echipa de rețea pentru a determina ce intervale de surse folosește organizația dvs

A inlocui
cu propriile domenii de adresă IP:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALOW \ --rules=tcp:22 \ -- intervale-sursă=
IP_ADDRESS_SCOPE
După ce creați regulile firewall, verificați dacă cele trei reguli au fost adăugate:
Lista de reguli de firewall gcloud compute \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Următorul exemplu de ieșire arată că cele trei reguli au fost create corect:
NUME 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
## Creați și configurați o imagine de bază VM
Pentru a crea VM-uri identice pe care le implementați fără configurație suplimentară, utilizați o imagine VM personalizată. Această imagine surprinde sistemul de operare și configurația Apache și este utilizată pentru a crea fiecare VM din grupul de instanțe gestionate în următorii pași

Pe VM, creați un element de bază
index.html de pe discul persistent și
montați-l pe
/var/www/example.com. Un fișier de configurare Apache la
/etc/apache2/sites-available/example.com.conf servește conținut web din
locația discului persistent montat

Următoarea diagramă arată pagina HTML de bază deservită de Apache care este stocată pe discul persistent:
Construiți acest mediu în următorii pași

Creați o mașină virtuală de bază cu un disc persistent atașat:
Instanțele de calcul gcloud creează 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
Utilizați parametri definiți la începutul acestui document pentru a denumi VM-ul și pentru a vă conecta la subrețeaua corectă. Numele sunt, de asemenea, atribuite din parametrii discului de pornire și discului de date

Pentru a instala și configura site-ul web simplu, mai întâi conectați-vă la VM de bază folosind SSH:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
În sesiunea SSH către VM, creați un script pentru a configura VM într-un editor la alegere. Următorul exemplu folosește Nano ca editor:
nano configure-vm.
Lipiți următorul script de configurare în fișier:
bin/bash NAME_SUFFIX=
app# Creați directorul pentru fișierele de bază ale site-ului 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 # Găsiți numele discului, apoi formatați-l și montați-l 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,scard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Instalează Apache sudo apt-get update&& sudo apt-get -y install apache2 # Scrieți un fișier HTML de bază în fișierul montat disc persistent sudo tee -a /var/www/example.com/index.html >/dev/null EOF'    Exemplu HA/DR   
Bun venit pe un site web Compute Engine cu failover cald la 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 # Activați fișierul de configurare Apache și reîncărcați serviciul sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Actualizați
variabilă pentru a se potrivi cu valoarea setată la începutul acestui document, cum ar fi
Aplicația NAME_SUFFIX

Scrieți fișierul și părăsiți editorul. De exemplu, în Nano utilizați
Ctrl-Opentru a scrie fișierul, apoi ieșiți cu
Ctrl-X

Faceți executabil scriptul de configurare, apoi rulați-l:
chmod +x configure-vm../configure-vm.
Ieșiți din sesiunea SSH pe VM:
Ieșire
Obțineți adresa IP a VM-ului și utilizați
curlpentru a vedea pagina web de bază:
curl $(instanțele de calcul gcloud descriu vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP).
Site-ul web de bază este returnat, așa cum se arată în următorul exemplu de rezultat:
    Exemplu HA/DR   
Bun venit pe un site web Compute Engine cu failover cald la Cloud Storagep>

# Creați imaginile de bază VM gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE gcloud compute images create image-disk-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Creați șabloane de instanță gcloud compute instance-templates creați șablon-$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=da gcloud compute instanță-șabloane creează șablon-$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 # Creați o verificare a stării de sănătate pentru instanțele VM gcloud compute health-checks create http-basic-check-$NAME_SUFFIX \ --port 80 # Creați grupurile de instanțe gestionate 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 grupuri de instanțe gestionate creați grup de instanțe -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Creați și configurați un echilibrator de încărcare
Pentru ca utilizatorii să vă acceseze site-ul web, trebuie să permiteți traficul către mașinile virtuale care rulează în grupurile de instanțe gestionate. De asemenea, doriți să redirecționați automat traficul către noi VM dacă există o eroare de zonă într-un grup de instanțe gestionat

În secțiunea următoare, creați un echilibrator de încărcare HTTPS extern cu un serviciu backend pentru traficul HTTP pe portul 80, utilizați verificarea de sănătate creată în pașii anteriori și mapați o adresă IP externă către serviciul backend.

Pentru mai multe informații, consultați Cum să configurați un echilibrator de încărcare HTTP simplu extern

Creați și configurați echilibrul de încărcare pentru aplicația dvs.:
# Configurați regulile de port pentru portul 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 # Creați un serviciu backend și adăugați-i grupurile de instanțe gestionate gcloud compute backend-services create \ web- backend-service-$NAME_SUFFIX \ --protocol=HTTP \ --port-name=http \ --health-checks=http-basic-check-$NAME_SUFFIX \ --global gcloud compute backend-services add-backend \ web- backend-service-$NAME_SUFFIX \ --instance-group=grup-de-instanțe-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=grup-de-instanțe-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Creați o hartă URL pentru serviciul de backend gcloud compute url-maps create hartă-web-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Configurați redirecționarea pentru traficul HTTP gcloud compute target-http-proxies create \ http-lb-proxy-$NAME_SUFFIX \ --url-map web-map-http- $NAME_SUFFIX gcloud compute forwarding-rules create \ http-content-rule-$NAME_SUFFIX \ --global \ --target-http-proxy=http-lb-proxy-$NAME_SUFFIX \ --ports=80
Obțineți adresa IP a regulii de redirecționare pentru traficul web:
IP_ADDRESSgcloud compute forwarding-rules descriu http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress)
Utilizare
curl sau deschide browserul web pentru a vizualiza site-ul web folosind adresa IP a echilibratorului de încărcare de la pasul anterior:
curl $IP_ADDRESS
Este nevoie de câteva minute pentru ca echilibratorul de încărcare să termine implementarea și să direcționeze corect traficul către backend. O eroare HTTP 404 este returnată dacă echilibrul de încărcare este încă implementat. Dacă este necesar, așteptați câteva minute și încercați să accesați din nou site-ul web

Site-ul web de bază este returnat, așa cum se arată în următorul exemplu de rezultat:
    Exemplu HA/DR   
Bun venit pe un site web Compute Engine cu failover cald la 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.