Dieses Dokument richtet sich an Architekten und Personen, die in Betriebs- und Verwaltungsteams arbeiten. Das Dokument beschreibt ein Beispielmuster, das Sie für Ihre eigenen Bereitstellungen in Google Cloud verwenden können

Bei diesem Muster leitet Cloud DNS den Datenverkehr an Compute Engine-Instanzen in verwalteten Instanzgruppen weiter, die den Inhalt bereitstellen. Bei einem Ausfall aktualisieren Sie die Cloud-DNS-Zone und führen ein Failover zu einer statischen Site in Cloud Storage durch

Um dieses Lernprogramm abzuschließen, benötigen Sie einen registrierten Domänennamen, den Sie kontrollieren und mit diesem Dokument verwenden möchten

In Produktionsbereitstellungen enthält Ihre Website wahrscheinlich viel mehr Dateien und zusätzlichen Anwendungscode auf Ihren verwalteten virtuellen Maschinen (VMs) der Instanzgruppe als in diesem Dokument gezeigt. Cloud Storage hostet dann eine eingeschränktere statische Version mit minimaler Funktionalität. In einem warmen Failover-Szenario sehen Benutzer diese eingeschränkte Website, bis die verwalteten Instanzgruppen wiederhergestellt sind und Datenverkehr für das vollständige Website-Erlebnis bereitstellen können

In diesem Lernprogramm stellen Sie Ressourcen bereit, um eine Umgebung zu erstellen, wie in der folgenden Abbildung gezeigt:
Wenn Sie ein Failover durchführen müssen, aktualisieren Sie die Cloud-DNS-Konfiguration, um den Datenverkehr an Cloud Storage weiterzuleiten, wie in der folgenden Abbildung gezeigt:
Dieses Warm-Failover-Muster gleicht die Kosten für die Ausführung einer anderen verwalteten Instanzgruppe in einer anderen Region aus, die Sie nur verwenden, wenn die primäre Region ausfällt. Die Kosten für eine statische Website mit Cloud Storage sind niedriger als für die Ausführung einer anderen verwalteten Instanzgruppe, aber es gibt eine kurze Verzögerung, wenn Sie Cloud DNS zwischen den Hosting-Optionen aktualisieren. Das eingeschränkte Website-Erlebnis in Cloud Storage ist besser als eine vollständig nicht verfügbare Website und ein schlechtes Kundenerlebnis

Einen alternativen Ansatz, der externes HTTP(S)-Load-Balancing anstelle von Cloud DNS verwendet, um das Failover zu steuern, finden Sie unter Bereitstellen eines warm wiederherstellbaren Webservers mit Compute Engine und Cloud Storage. Dieses Muster ist nützlich, wenn Sie Cloud DNS nicht haben oder nicht verwenden möchten

Um zuverlässige Anwendungen in Google Cloud auszuführen, empfehlen wir Ihnen, Ihre Anwendungsinfrastruktur so zu gestalten, dass Ausfälle bewältigt werden können. Abhängig von Ihren Anwendungs- und Geschäftsanforderungen benötigen Sie möglicherweise ein Cold-Failover-, Warm-Failover- oder Hot-Failover-Muster. Weitere Informationen zur Bestimmung des besten Ansatzes für Ihre eigenen Anwendungen finden Sie im Planungsleitfaden für die Notfallwiederherstellung

Dieses Dokument verwendet einen einfachen Apache-Webserver, aber derselbe Ansatz für die Infrastrukturbereitstellung gilt für andere Anwendungsumgebungen, die Sie erstellen müssen

## Ziele

– Erstellen Sie regional verwaltete Instanzgruppen mit einem benutzerdefinierten VM-Image

- Erstellen Sie einen Cloud Storage-Bucket

- Erstellen und konfigurieren Sie eine Cloud-DNS-Zone

– Testen Sie das Failover des warmen Webservers mit aktualisierten Cloud-DNS-Einträgen

- Testen Sie die Wiederherstellung und das Failback mit aktualisierten Cloud-DNS-Einträgen

## Kosten
In dieser Anleitung werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:
Um einen Kostenvoranschlag basierend auf Ihrer voraussichtlichen Nutzung zu erstellen,
nutzen Sie den Preisrechner

## Bevor Sie beginnen
Einige der Schritte in diesem Dokument funktionieren möglicherweise nicht richtig, wenn Ihre Organisation Einschränkungen für Ihre Google Cloud-Umgebung anwendet. In diesem Fall können Sie Aufgaben wie das Erstellen öffentlicher IP-Adressen oder Dienstkontoschlüssel möglicherweise nicht ausführen. Wenn Sie eine Anfrage stellen, die einen Fehler zu Einschränkungen zurückgibt, lesen Sie Anwendungen in einer eingeschränkten Google Cloud-Umgebung entwickeln

- Melden Sie sich bei Ihrem Google Cloud-Konto an. Wenn Sie neu bei Google Cloud sind, erstellen Sie ein Konto, um die Leistung unserer Produkte in realen Szenarien zu bewerten. Neukunden erhalten außerdem 300 US-Dollar an kostenlosen Credits zum Ausführen, Testen und Bereitstellen von Workloads

-
Wählen Sie in der Google Cloud-Konsole auf der Projektauswahlseite ein Google Cloud-Projekt aus oder erstellen Sie es

-
Stellen Sie sicher, dass die Abrechnung für Ihr Cloud-Projekt aktiviert ist. Erfahren Sie, wie Sie prüfen, ob die Abrechnung für ein Projekt aktiviert ist

-
Aktivieren Sie die Compute Engine-API

- Installieren und initialisieren Sie die Google Cloud CLI

-
Wählen Sie in der Google Cloud-Konsole auf der Projektauswahlseite ein Google Cloud-Projekt aus oder erstellen Sie es

-
Stellen Sie sicher, dass die Abrechnung für Ihr Cloud-Projekt aktiviert ist. Erfahren Sie, wie Sie prüfen, ob die Abrechnung für ein Projekt aktiviert ist

-
Aktivieren Sie die Compute Engine-API

- Installieren und initialisieren Sie die Google Cloud CLI

Sie können die Google Cloud-Befehlszeilenschnittstelle in der Google Cloud-Konsole ausführen, ohne die Google Cloud-Befehlszeilenschnittstelle zu installieren. Verwenden Sie zum Ausführen der gcloud-Befehlszeilenschnittstelle in der Google Cloud-Konsole die Cloud Shell

## Bereiten Sie die Umgebung vor
In diesem Abschnitt definieren Sie einige Variablen für Ihre Ressourcennamen und Standorte. Diese Variablen werden von den Google Cloud CLI-Befehlen verwendet, wenn Sie die Ressourcen bereitstellen

Sofern nicht anders angegeben, geben Sie in dieser Anleitung alle Befehle in Cloud Shell oder Ihrer lokalen Entwicklungsumgebung ein

Ersetzen
mit Ihrer eigenen Projekt-ID. Geben Sie bei Bedarf Ihren eigenen Namenszusatz für Ressourcen an, um die Suche und Identifizierung zu erleichtern, z
PROJEKT_ID


App
Geben Sie zwei Regionen an, z
und
us-west1
, und eine Zone innerhalb einer dieser Regionen, wie z
us-west2
. Diese Zone definiert, wo die anfängliche Basis-VM erstellt wird, die zum Erstellen eines Images für die verwaltete Instanzgruppe verwendet wird

us-west1-a
Legen Sie abschließend eine Domain fest, die für Ihre statische Website verwendet wird, z
beispiel.com
PROJEKT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Erstellen Sie eine VPC und ein Subnetz
Um Netzwerkzugriff auf die VMs bereitzustellen, erstellen Sie Virtual Private Cloud (VPC) und Subnetze. Da Sie verwaltete Instanzgruppen in zwei Regionen benötigen, erstellen Sie in jeder Region ein Subnetz. Weitere Informationen zu den Vorteilen des benutzerdefinierten Subnetzmodus zum Verwalten von IP-Adressbereichen, die in Ihrer Umgebung verwendet werden, finden Sie unter Verwenden von VPC-Netzwerken im benutzerdefinierten Modus

Erstellen Sie die VPC mit einem benutzerdefinierten Subnetzmodus:
gcloud compute networks create network-$NAME_SUFFIX --subnet-mode=custom
Erstellen Sie nun zwei Subnetze in der neuen VPC, eines für jede Region. Definieren Sie eigene Adressbereiche, wie z
und
10.1.0.0/20
, die in Ihren Netzwerkbereich passen:
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=$ REGION2
## Firewallregeln erstellen
Verwenden Sie Firewallregeln, damit der Netzwerkdatenverkehr in der VPC korrekt fließen kann

Erstellen Sie Firewallregeln, um Webdatenverkehr und Zustandsprüfungen für den Load Balancer und verwaltete Instanzgruppen zuzulassen:
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=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=allow-health-check \ --rules=tcp:80
Die HTTP-Regel lässt Datenverkehr zu jeder VM zu, auf der die
http-servertag angewendet wird, und von jeder Quelle mit dem
0.0.0.0/0 Bereich. Für die Integritätsprüfungsregel werden Standardbereiche für Google Cloud festgelegt, damit die Plattform den Zustand von Ressourcen korrekt überprüfen kann

Um SSH-Datenverkehr für die Erstkonfiguration eines VM-Basisimages zuzulassen, richten Sie die Firewallregel mithilfe von auf Ihre Umgebung aus
--source-rangeparameter. Möglicherweise müssen Sie mit Ihrem Netzwerkteam zusammenarbeiten, um festzustellen, welche Quellbereiche Ihre Organisation verwendet

Ersetzen
mit eigenen IP-Adressbereichen:
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 \ -- Quellbereiche=
IP_ADDRESS_SCOPE
Überprüfen Sie nach dem Erstellen der Firewall-Regeln, ob die drei Regeln hinzugefügt wurden:
gcloud compute firewall-rules list \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Die folgende Beispielausgabe zeigt, dass die drei Regeln korrekt erstellt wurden:
NAME NETZWERKRICHTUNG PRIORITÄT ERLAUBEN-Gesundheitscheck-App Netzwerk-App EINGANG 1000 TCP:80 http-App zulassen Netzwerk-App EINGANG 1000 TCP:80 SSH-App zulassen Netzwerk-App EINGANG 1000 TCP:22
## Erstellen und konfigurieren Sie ein Basis-VM-Image
Um identische VMs zu erstellen, die Sie ohne zusätzliche Konfiguration bereitstellen, verwenden Sie ein benutzerdefiniertes VM-Image. Dieses Image erfasst die Betriebssystem- und Apache-Konfiguration und wird verwendet, um in den nächsten Schritten jede VM in der verwalteten Instanzgruppe zu erstellen

Auf der VM erstellen Sie eine Basic
index.html-Datei auf der persistenten Festplatte und
montieren Sie es an
/var/www/example.com. Eine Apache-Konfigurationsdatei unter
/etc/apache2/sites-available/example.com.conf stellt Webinhalte von bereit
Eingehängter persistenter Speicherort

Das folgende Diagramm zeigt die von Apache bereitgestellte grundlegende HTML-Seite, die auf der persistenten Festplatte gespeichert ist:
Sie erstellen diese Umgebung in den folgenden Schritten

Erstellen Sie eine Basis-VM mit einer angehängten persistenten Festplatte:
gcloud compute-Instanzen erstellen 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- Gerätename=vm-base-$NAME_SUFFIX \ --create-disk=type=pd-ssd,name=disk-base-$NAME_SUFFIX,size=10GB,device-name=disk-base-$NAME_SUFFIX
Sie verwenden die am Anfang dieses Dokuments definierten Parameter, um die VM zu benennen und eine Verbindung mit dem richtigen Subnetz herzustellen. Namen werden auch aus den Parametern für Bootdisk und Datendisk vergeben

Um die einfache Website zu installieren und zu konfigurieren, verbinden Sie sich zunächst mit SSH mit der Basis-VM:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$ZONE
Erstellen Sie in Ihrer SSH-Sitzung mit der VM ein Skript, um die VM in einem Editor Ihrer Wahl zu konfigurieren. Das folgende Beispiel verwendet Nano als Editor:
nano configure-vm.
Fügen Sie das folgende Konfigurationsskript in die Datei ein:
bin/bash NAME_SUFFIX=
app# Verzeichnis für die grundlegenden Website-Dateien erstellen sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Suchen Sie den Festplattennamen, formatieren und mounten Sie ihn dann 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,discard $DISK_PATH sudo mount -o discard,defaults $DISK_PATH /var/www/example.com # Apache sudo apt-get update installieren&& sudo apt-get -y install apache2 # Schreiben Sie eine grundlegende HTML-Datei auf die gemountete persistente Festplatte sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'    HA/DR-Beispiel   
Willkommen auf einer Compute Engine-Website mit warmem Failover zu 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 # Aktivieren Sie die Apache-Konfigurationsdatei und laden Sie den Dienst neu sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl reload apache2
Aktualisieren Sie die
Variable so, dass sie mit dem am Anfang dieses Dokuments festgelegten Wert übereinstimmt, z
NAME_SUFFIX-App

Schreiben Sie die Datei aus und beenden Sie Ihren Editor. Zum Beispiel verwenden Sie in Nano
Strg-O, um die Datei zu schreiben, dann mit beenden
Strg-X

Machen Sie das Konfigurationsskript ausführbar und führen Sie es dann aus:
chmod +x configure-vm../configure-vm.
Beenden Sie die SSH-Sitzung zur VM:
Ausfahrt
Rufen Sie die IP-Adresse der VM ab und verwenden Sie sie
curlum die grundlegende Webseite anzuzeigen:
curl $(gcloud compute-Instanzen beschreiben vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Die grundlegende Website wird zurückgegeben, wie in der folgenden Beispielausgabe gezeigt:
    HA/DR-Beispiel   
Willkommen auf einer Compute Engine-Website mit warmem Failover zu Cloud Storagep>

# Basis-VM-Images erstellen 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 # Instanzvorlagen erstellen gcloud compute instance-templates create template-$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=yes 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 # Erstellen Sie eine Systemdiagnose für VM-Instanzen gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Erstellen Sie die verwalteten Instanzgruppen 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 -$NAME_SUFFIX-$REGION2 \ --template=template-$NAME_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Erstellen und konfigurieren Sie einen Load Balancer
Damit Benutzer auf Ihre Website zugreifen können, müssen Sie Datenverkehr zu den VMs zulassen, die in den verwalteten Instanzgruppen ausgeführt werden. Sie möchten den Datenverkehr auch automatisch auf neue VMs umleiten, wenn in einer verwalteten Instanzgruppe ein Zonenfehler auftritt

Im folgenden Abschnitt erstellen Sie einen externen HTTPS-Load-Balancer mit einem Back-End-Dienst für HTTP-Datenverkehr auf Port 80, verwenden die in den vorherigen Schritten erstellte Zustandsprüfung und ordnen dem Back-End-Dienst eine externe IP-Adresse zu

Weitere Informationen finden Sie unter So richten Sie einen einfachen externen HTTP-Load-Balancer ein

Erstellen und konfigurieren Sie den Load Balancer für Ihre Anwendung:
# Portregeln für HTTP-Port 80 konfigurieren 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 # Erstellen Sie einen Back-End-Dienst und fügen Sie ihm die verwalteten Instanzgruppen hinzu 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 # Erstellen Sie eine URL-Zuordnung für den Backend-Dienst gcloud compute url-maps create web-map-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Weiterleitung für den HTTP-Traffic konfigurieren gcloud compute target-http-proxys 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
Rufen Sie die IP-Adresse der Weiterleitungsregel für den Webdatenverkehr ab:
IP_ADDRESSgcloud compute forwarding-rules beschreiben http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Verwenden
curl oder öffnen Sie Ihren Webbrowser, um die Website mit der IP-Adresse des Load Balancers aus dem vorherigen Schritt anzuzeigen:
curl $IP_ADDRESS
Es dauert einige Minuten, bis der Load-Balancer die Bereitstellung abgeschlossen hat und den Datenverkehr korrekt an Ihr Back-End weiterleitet. Ein HTTP 404-Fehler wird zurückgegeben, wenn der Load Balancer noch bereitgestellt wird. Warten Sie bei Bedarf einige Minuten und versuchen Sie erneut, auf die Website zuzugreifen

Die grundlegende Website wird zurückgegeben, wie in der folgenden Beispielausgabe gezeigt:
    HA/DR-Beispiel   
Willkommen auf einer Compute Engine-Website mit warmem Failover zu 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.