Questo documento è destinato agli architetti e alle persone che lavorano nei team operativi e amministrativi. Il documento descrive un modello di esempio che puoi utilizzare per i tuoi deployment in Google Cloud

In questo modello, Cloud DNS indirizza il traffico alle istanze di Compute Engine nei gruppi di istanze gestite che gestiscono i contenuti. In caso di interruzione, aggiorni la zona Cloud DNS ed esegui il failover su un sito statico in Cloud Storage

Per completare questo tutorial, è necessario un nome di dominio registrato che controlli e desideri utilizzare con questo documento

Nelle distribuzioni di produzione, è probabile che il tuo sito web includa molti più file e codice dell'applicazione aggiuntivo sulle tue macchine virtuali (VM) del gruppo di istanze gestite rispetto a quanto mostrato in questo documento. Cloud Storage ospita quindi una versione statica più limitata che fornisce funzionalità minime. In uno scenario di failover a caldo, gli utenti visualizzano questo sito Web limitato finché i gruppi di istanze gestite non vengono ripristinati e possono gestire il traffico per l'esperienza completa del sito Web

In questo tutorial, distribuisci le risorse per creare un ambiente come mostrato nell'immagine seguente:
Quando devi eseguire il failover, aggiorna la configurazione di Cloud DNS per indirizzare il traffico a Cloud Storage, come mostrato nell'immagine seguente:
Questo modello di failover a caldo compensa il costo dell'esecuzione di un altro gruppo di istanze gestite in un'area geografica diversa che utilizzi solo in caso di errore dell'area primaria. Il costo di un sito statico che utilizza Cloud Storage è inferiore rispetto all'esecuzione di un altro gruppo di istanze gestite, ma c'è un breve ritardo durante l'aggiornamento di Cloud DNS tra le opzioni di hosting. L'esperienza limitata del sito Web in Cloud Storage è migliore di un sito Web completamente non disponibile e di una scarsa esperienza del cliente

Per un approccio alternativo che utilizza il bilanciamento del carico HTTP(S) esterno invece di Cloud DNS per controllare il failover, consulta Implementazione di un server Web recuperabile a caldo con Compute Engine e Cloud Storage. Questo pattern è utile se non hai o non vuoi usare Cloud DNS

Per eseguire applicazioni affidabili in Google Cloud, ti consigliamo di progettare la tua infrastruttura applicativa per gestire le interruzioni. A seconda dell'applicazione e delle esigenze aziendali, potrebbe essere necessario un modello di failover a freddo, a caldo o a caldo. Per ulteriori informazioni su come determinare l'approccio migliore per le proprie applicazioni, consultare la Guida alla pianificazione del ripristino di emergenza

Questo documento utilizza un server Web Apache di base, ma lo stesso approccio alla distribuzione dell'infrastruttura si applica ad altri ambienti applicativi che è necessario creare

## Obiettivi

- Crea gruppi di istanze gestite a livello di area geografica con un'immagine VM personalizzata

- Crea un bucket Cloud Storage

- Crea e configura una zona Cloud DNS

- Testare il failover del server Web a caldo con i record Cloud DNS aggiornati

- Testa il ripristino e il failback con i record Cloud DNS aggiornati

## Costi
Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:
Per generare una stima dei costi basata sull'utilizzo previsto,
utilizzare il calcolatore dei prezzi

## Prima di iniziare
Alcuni passaggi in questo documento potrebbero non funzionare correttamente se la tua organizzazione applica vincoli al tuo ambiente Google Cloud. In tal caso, potresti non essere in grado di completare attività come la creazione di indirizzi IP pubblici o chiavi dell'account di servizio. Se effettui una richiesta che restituisce un errore sui vincoli, vedi come sviluppare applicazioni in un ambiente Google Cloud vincolato

- Accedi al tuo account Google Cloud. Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche $ 300 in crediti gratuiti per eseguire, testare e distribuire carichi di lavoro

-
Nella console di Google Cloud, nella pagina di selezione del progetto, seleziona o crea un progetto Google Cloud

-
Assicurati che la fatturazione sia abilitata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto

-
Abilita l'API di Compute Engine

- Installa e inizializza l'interfaccia a riga di comando di Google Cloud

-
Nella console di Google Cloud, nella pagina di selezione del progetto, seleziona o crea un progetto Google Cloud

-
Assicurati che la fatturazione sia abilitata per il tuo progetto Cloud. Scopri come verificare se la fatturazione è abilitata su un progetto

-
Abilita l'API di Compute Engine

- Installa e inizializza l'interfaccia a riga di comando di Google Cloud

Puoi eseguire l'interfaccia a riga di comando di Google Cloud nella console di Google Cloud senza installare l'interfaccia a riga di comando di Google Cloud. Per eseguire l'interfaccia a riga di comando di gcloud nella console di Google Cloud, utilizza Cloud Shell

## Preparare l'ambiente
In questa sezione, definisci alcune variabili per i nomi e le ubicazioni delle tue risorse. Queste variabili vengono utilizzate dai comandi dell'interfaccia a riga di comando di Google Cloud durante il deployment delle risorse

In questo tutorial, se non diversamente specificato, immetti tutti i comandi in Cloud Shell o nel tuo ambiente di sviluppo locale

Sostituire
con il tuo ID progetto. Se lo desideri, fornisci il suffisso del tuo nome per le risorse per aiutarti a cercarle e identificarle, ad esempio
ID_PROGETTO


app
Specificare due regioni, ad esempio
e
noi-ovest1
e una zona all'interno di una di queste regioni, ad esempio
noi-ovest2
. Questa zona definisce dove viene creata la VM di base iniziale usata per creare un'immagine per il gruppo di istanze gestite

noi-ovest1-a
Infine, imposta un dominio utilizzato per il tuo sito Web statico, ad esempio
esempio.com
ID_PROGETTO=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Crea un VPC e una sottorete
Per fornire l'accesso di rete alle VM, crei il Virtual Private Cloud (VPC) e le sottoreti. Poiché hai bisogno di gruppi di istanze gestite in due aree geografiche, devi creare una sottorete in ciascuna area geografica. Per ulteriori informazioni sui vantaggi della modalità subnet personalizzata per gestire gli intervalli di indirizzi IP in uso nel tuo ambiente, consulta Utilizzare reti VPC in modalità personalizzata

Crea il VPC con una modalità di sottorete personalizzata:
le reti di calcolo gcloud creano network-$NAME_SUFFIX --subnet-mode=custom
Ora crea due sottoreti nel nuovo VPC, una per ogni regione. Definisci i tuoi intervalli di indirizzi, ad esempio
e
10.1.0.0/20
, che rientrano nell'intervallo di rete:
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 subnet create \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ REGIONE2
## Crea regole firewall
Per consentire il corretto flusso del traffico di rete nel VPC, utilizza le regole del firewall

Crea regole firewall per consentire il traffico web e i controlli di integrità per il bilanciatore del carico e i gruppi di istanze gestite:
gcloud compute firewall-rules create 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=ingresso \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
La regola HTTP consente il traffico verso qualsiasi macchina virtuale in cui il file
http-servertag viene applicato e da qualsiasi origine che utilizza il file
0.0.0.0/0intervallo. Per la regola di controllo dello stato, gli intervalli predefiniti per Google Cloud sono impostati per consentire alla piattaforma di controllare correttamente lo stato delle risorse

Per consentire il traffico SSH per la configurazione iniziale di un'immagine di macchina virtuale di base, definire l'ambito della regola del firewall per il proprio ambiente utilizzando il file
--source-rangeparameter. Potrebbe essere necessario collaborare con il team di rete per determinare quali intervalli di origine utilizza la tua organizzazione

Sostituire
con i tuoi ambiti di indirizzi IP:
IP_ADDRESS_SCOPE
gcloud compute firewall-rules create allow-ssh-$NAME_SUFFIX \ --network=network-$NAME_SUFFIX \ --direction=INGRESS \ --priority=1000 \ --action=ALLOW \ --rules=tcp:22 \ -- sorgenti-intervalli=
IP_ADDRESS_SCOPE
Dopo aver creato le regole del firewall, verifica che le tre regole siano state aggiunte:
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"L'output di esempio seguente mostra che le tre regole sono state create correttamente:
NOME RETE DIREZIONE PRIORITÀ CONSENTI allow-health-check-app network-app INGRESSO 1000 tcp:80 allow-http-app network-app INGRESSO 1000 tcp:80 allow-ssh-app network-app INGRESSO 1000 tcp:22
## Crea e configura un'immagine VM di base
Per creare macchine virtuali identiche che distribuisci senza configurazione aggiuntiva, usa un'immagine di macchina virtuale personalizzata. Questa immagine acquisisce la configurazione del sistema operativo e di Apache e viene utilizzata per creare ogni VM nel gruppo di istanze gestite nei passaggi successivi

Nella macchina virtuale crei un file basic
index.html sul disco permanente e
montarlo su
/var/www/esempio.com. Un file di configurazione di Apache su
/etc/apache2/sites-available/example.com.conf fornisce contenuti web da
posizione del disco permanente montata

Il diagramma seguente mostra la pagina HTML di base servita da Apache memorizzata sul disco persistente:
Si crea questo ambiente nei passaggi seguenti

Crea una VM di base con un disco persistente collegato:
istanze di calcolo gcloud create 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
Usare i parametri definiti all'inizio di questo documento per assegnare un nome alla macchina virtuale e connettersi alla subnet corretta. I nomi vengono assegnati anche dai parametri per il disco di avvio e il disco dati

Per installare e configurare il sito Web semplice, connettiti prima alla VM di base tramite SSH:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONA
Nella tua sessione SSH alla VM, crea uno script per configurare la VM in un editor di tua scelta. L'esempio seguente utilizza Nano come editor:
nano configure-vm.
Incolla il seguente script di configurazione nel file:
bin/bash NAME_SUFFIX=
app# Crea una directory per i file del sito web di base sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Trova il nome del disco, quindi formattalo e montalo 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,scarta $DISK_PATH sudo mount -o scarta,default $DISK_PATH /var/www/example.com # Installa Apache sudo apt-get update&& sudo apt-get -y install apache2 # Scrive un file HTML di base sul disco persistente montato sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'    Esempio HA/DR   
Benvenuto in un sito Web di Compute Engine con warm failover su 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 # Abilita il file di configurazione di Apache e ricarica il servizio sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Aggiorna il
variabile in modo che corrisponda al valore impostato all'inizio di questo documento, ad esempio
NAME_SUFFIX app

Scrivi il file ed esci dall'editor. Ad esempio, in Nano usi
Ctrl-Oper scrivere il file, quindi uscire con
Ctrl-X

Rendi eseguibile lo script di configurazione, quindi eseguilo:
chmod +x configure-vm../configure-vm.
Uscire dalla sessione SSH sulla VM:
Uscita
Ottenere l'indirizzo IP della VM e utilizzare
curlper vedere la pagina web di base:
curl $(le istanze di calcolo gcloud descrivono vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Viene restituito il sito Web di base, come mostrato nel seguente output di esempio:
    Esempio HA/DR   
Benvenuto in un sito Web di Compute Engine con warm failover su Cloud Storagep>

# Crea le immagini della VM di base 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 modelli di istanza gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION1 \ --machine-type=n1-standard- 1 \ --subnet=progetti/$PROJECT_ID/regions/$REGION1/subnetworks/subnet-$NAME_SUFFIX-$REGION1 \ --region=$REGION1 \ --tags=http-server \ --metadatastartup-script /bin/bashn 'echo\ UUIDblkid\ -s\ UUID\ -o\ valore\ /dev/sdb /var/www/example.com\ ext4\ scarta,predefiniti,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount \ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes gcloud compute instance-templates create template-$NAME_SUFFIX-$REGION2 \ --machine -type=n1-standard-1 \ --subnet=progetti/$PROJECT_ID/regioni/$REGION2/subnetworks/subnet-$NAME_SUFFIX-$REGION2 \ --region=$REGION2 \ --tags=http-server \ --metadatastartup-script /bin/bashn'echo\ UUIDblkid\ -s\ UUID\ -o\ valore\ /dev/sdb /var/www/example.com\ ext4\ scarta, valori predefiniti ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAME_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Crea un controllo dello stato per le istanze VM gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Crea i gruppi di istanze gestite 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 managed create instance-group -$SUFFIX_NOME-$REGIONE2 \ --template=template-$SUFFIX_NOME-$REGIONE2 \ --size=2 \ --region=$REGIONE2 \ --health-check=http-basic-check-$SUFFIX_NOME
## Crea e configura un bilanciatore del carico
Affinché gli utenti possano accedere al tuo sito web, devi consentire il traffico verso le VM in esecuzione nei gruppi di istanze gestite. Vuoi anche reindirizzare automaticamente il traffico alle nuove macchine virtuali se si verifica un errore di zona in un gruppo di istanze gestite

Nella sezione seguente, crei un bilanciatore del carico HTTPS esterno con un servizio di back-end per il traffico HTTP sulla porta 80, utilizzi il controllo dello stato creato nei passaggi precedenti e mappi un indirizzo IP esterno tramite il servizio di back-end

Per ulteriori informazioni, consulta Come configurare un semplice bilanciatore del carico HTTP esterno

Crea e configura il bilanciamento del carico per la tua applicazione:
# Configurare le regole di porta per la porta 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 un servizio di backend e aggiungi i gruppi di istanze gestite 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=instance-group-$NAME_SUFFIX-$REGION1 \ --instance-group-region=$REGION1 \ --global gcloud compute backend-services add-backend \ web-backend- service-$NAME_SUFFIX \ --instance-group=instance-group-$NAME_SUFFIX-$REGION2 \ --instance-group-region=$REGION2 \ --global # Crea una mappa URL per il servizio di backend gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Configura l'inoltro per il traffico 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
Ottieni l'indirizzo IP della regola di inoltro per il traffico web:
IP_ADDRESSgcloud compute forwarding-rules describe http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Utilizzo
curl o aprire il browser Web per visualizzare il sito Web utilizzando l'indirizzo IP del sistema di bilanciamento del carico del passaggio precedente:
arriccia $IP_ADDRESS
Il bilanciatore del carico impiega alcuni minuti per completare la distribuzione e indirizzare correttamente il traffico al tuo back-end. Viene restituito un errore HTTP 404 se il bilanciamento del carico è ancora in fase di distribuzione. Se necessario, attendi qualche minuto e riprova ad accedere al sito web

Viene restituito il sito Web di base, come mostrato nel seguente output di esempio:
    Esempio HA/DR   
Benvenuto in un sito Web di Compute Engine con warm failover su 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.