Niniejszy dokument jest przeznaczony dla architektów oraz osób pracujących w zespołach operacyjnych i administracyjnych. Dokument opisuje przykładowy wzorzec, którego możesz użyć do własnych wdrożeń w Google Cloud

W tym wzorcu Cloud DNS kieruje ruch do instancji Compute Engine w zarządzanych grupach instancji, które udostępniają zawartość. W przypadku awarii aktualizujesz strefę Cloud DNS i przełączasz się awaryjnie do lokacji statycznej w Cloud Storage

Aby ukończyć ten samouczek, potrzebujesz zarejestrowanej nazwy domeny, którą kontrolujesz i chcesz używać z tym dokumentem

W przypadku wdrożeń produkcyjnych Twoja witryna prawdopodobnie zawiera o wiele więcej plików i dodatkowego kodu aplikacji na zarządzanych maszynach wirtualnych grupy instancji niż pokazano w tym dokumencie. Cloud Storage obsługuje wtedy bardziej ograniczoną wersję statyczną, która zapewnia minimalną funkcjonalność. W scenariuszu ciepłego przełączania awaryjnego użytkownicy widzą tę ograniczoną witrynę, dopóki zarządzane grupy instancji nie odzyskają sprawności i nie będą mogły obsługiwać ruchu w całej witrynie

W tym samouczku wdrażasz zasoby w celu utworzenia środowiska, jak pokazano na poniższej ilustracji:
Gdy musisz przełączyć się awaryjnie, zaktualizuj konfigurację Cloud DNS, aby kierować ruch do Cloud Storage, jak pokazano na poniższym obrazku:
Ten gorący wzorzec przełączania awaryjnego równoważy koszt uruchamiania innej zarządzanej grupy instancji w innym regionie, którego używasz tylko w przypadku awarii regionu podstawowego. Koszt witryny statycznej korzystającej z Cloud Storage jest niższy niż w przypadku korzystania z innej zarządzanej grupy instancji, ale aktualizacja Cloud DNS między opcjami hostingu jest krótka. Ograniczone korzystanie z witryny w Cloud Storage jest lepsze niż całkowicie niedostępna witryna i słabe wrażenia klienta

Aby zapoznać się z alternatywnym podejściem, które wykorzystuje zewnętrzne równoważenie obciążenia HTTP(S) zamiast Cloud DNS do kontrolowania przełączania awaryjnego, zobacz Wdrażanie serwera WWW z możliwością przywracania podczas pracy za pomocą Compute Engine i Cloud Storage. Ten wzorzec jest przydatny, jeśli nie masz Cloud DNS lub nie chcesz go używać

Aby uruchamiać niezawodne aplikacje w Google Cloud, zalecamy zaprojektowanie infrastruktury aplikacji do obsługi przestojów. W zależności od aplikacji i potrzeb biznesowych może być potrzebny wzorzec zimnego przełączania awaryjnego, ciepłego przełączania awaryjnego lub gorącego przełączania awaryjnego. Aby uzyskać więcej informacji na temat określania najlepszego podejścia do własnych aplikacji, zobacz Przewodnik planowania odzyskiwania po awarii

Ten dokument wykorzystuje podstawowy serwer WWW Apache, ale to samo podejście do wdrażania infrastruktury dotyczy innych środowisk aplikacji, które należy utworzyć

## Cele

- Twórz zarządzane regionalnie grupy instancji z niestandardowym obrazem maszyny wirtualnej

- Utwórz zasobnik Cloud Storage

- Utwórz i skonfiguruj strefę Cloud DNS

- Przetestuj przełączanie awaryjne ciepłego serwera internetowego za pomocą zaktualizowanych rekordów Cloud DNS

- Przetestuj odzyskiwanie i powrót po awarii przy użyciu zaktualizowanych rekordów Cloud DNS

## Koszty
W tym samouczku są używane następujące płatne komponenty usługi Google Cloud:
Aby wygenerować kosztorys na podstawie przewidywanego użycia,
skorzystaj z kalkulatora cen

## Zanim zaczniesz
Niektóre czynności opisane w tym dokumencie mogą nie działać poprawnie, jeśli Twoja organizacja stosuje ograniczenia w środowisku Google Cloud. W takim przypadku możesz nie być w stanie ukończyć zadań, takich jak tworzenie publicznych adresów IP lub kluczy konta usługi. Jeśli wysyłasz żądanie, które zwraca błąd dotyczący ograniczeń, zobacz, jak tworzyć aplikacje w ograniczonym środowisku Google Cloud

- Zaloguj się na swoje konto Google Cloud. Jeśli dopiero zaczynasz korzystać z Google Cloud, utwórz konto, aby ocenić skuteczność naszych produktów w rzeczywistych sytuacjach. Nowi klienci otrzymują również darmowe kredyty w wysokości 300 USD na uruchamianie, testowanie i wdrażanie obciążeń

-
W konsoli Google Cloud na stronie wyboru projektu wybierz lub utwórz projekt Google Cloud

-
Upewnij się, że rozliczenia są włączone dla Twojego projektu Cloud. Dowiedz się, jak sprawdzić, czy rozliczenia są włączone w projekcie

-
Włącz interfejs API Compute Engine

- Zainstaluj i zainicjuj Google Cloud CLI

-
W konsoli Google Cloud na stronie wyboru projektu wybierz lub utwórz projekt Google Cloud

-
Upewnij się, że rozliczenia są włączone dla Twojego projektu Cloud. Dowiedz się, jak sprawdzić, czy rozliczenia są włączone w projekcie

-
Włącz interfejs API Compute Engine

- Zainstaluj i zainicjuj Google Cloud CLI

Możesz uruchomić Google Cloud CLI w konsoli Google Cloud bez instalowania Google Cloud CLI. Aby uruchomić interfejs wiersza polecenia gcloud w konsoli Google Cloud, użyj Cloud Shell

## Przygotuj środowisko
W tej sekcji zdefiniujesz niektóre zmienne dla nazw zasobów i lokalizacji. Te zmienne są używane przez polecenia Google Cloud CLI podczas wdrażania zasobów

W tym samouczku, o ile nie zaznaczono inaczej, wszystkie polecenia wprowadzasz w Cloud Shell lub lokalnym środowisku programistycznym

Zastąpić
z własnym identyfikatorem projektu. W razie potrzeby podaj własny sufiks nazwy zasobów, aby ułatwić ich wyszukiwanie i identyfikowanie, na przykład
ID_PROJEKTU


aplikacja
Określ dwa regiony, np
oraz
us-zachód1
oraz strefę w obrębie jednego z tych regionów, np
us-zachód2
. Ta strefa określa, gdzie jest tworzona początkowa podstawowa maszyna wirtualna, która jest używana do tworzenia obrazu dla zarządzanej grupy instancji

us-west1-a
Na koniec ustaw domenę używaną dla Twojej statycznej witryny, np
przyklad.com
PROJECT_ID=
PROJECT_IDNAME_SUFFIX= appREGION1= us-west1REGION2= us-west2ZONE= us-west1-aDOMAIN= example.com
## Utwórz VPC i podsieć
Aby zapewnić dostęp sieciowy do maszyn wirtualnych, tworzysz wirtualną chmurę prywatną (VPC) i podsieci. Ponieważ potrzebujesz zarządzanych grup instancji w dwóch regionach, tworzysz po jednej podsieci w każdym regionie. Aby uzyskać więcej informacji na temat zalet niestandardowego trybu podsieci do zarządzania zakresami adresów IP używanych w Twoim środowisku, zobacz Korzystanie z sieci VPC w trybie niestandardowym

Utwórz VPC z niestandardowym trybem podsieci:
sieci obliczeniowe gcloud tworzą network-$NAME_SUFFIX --subnet-mode=custom
Teraz utwórz dwie podsieci w nowym VPC, po jednej dla każdego regionu. Zdefiniuj własne zakresy adresów, np
oraz
10.1.0.0/20
, które mieszczą się w Twoim zasięgu sieci:
10.2.0.0/20
Tworzenie podsieci sieci gcloud Compute \ subnet-$NAME_SUFFIX-$REGION1 \ --network=network-$NAME_SUFFIX \ --range=
10.1.0.0/20\ --region=$REGION1 tworzenie podsieci sieci gcloud compute \ subnet-$NAME_SUFFIX-$REGION2 \ --network=network-$NAME_SUFFIX \ --range= 10.2.0.0/20\ --region=$ REGION2
## Utwórz reguły zapory
Aby umożliwić prawidłowy przepływ ruchu sieciowego w VPC, użyj reguł zapory sieciowej

Utwórz reguły zapory sieciowej, aby umożliwić kontrole ruchu sieciowego i stanu systemu równoważenia obciążenia i zarządzanych grup instancji:
reguły zapory sieciowej gcloud compute tworzą 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
Reguła HTTP zezwala na ruch do dowolnej maszyny wirtualnej, w której
stosowany jest tag serwera http, a z dowolnego źródła korzystającego z
0.0.0.0/0zakres. W przypadku reguły sprawdzania stanu ustawione są domyślne zakresy dla Google Cloud, aby umożliwić platformie prawidłowe sprawdzanie stanu zasobów

Aby zezwolić na ruch SSH dla początkowej konfiguracji podstawowego obrazu maszyny wirtualnej, określ zakres reguły zapory dla swojego środowiska przy użyciu
--source-rangeparametr. Może być konieczna współpraca z zespołem ds. sieci w celu ustalenia, jakich zakresów źródeł używa Twoja organizacja

Zastąpić
z własnymi zakresami adresów 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 \ -- zakresy-źródeł=
IP_ADDRESS_SCOPE
Po utworzeniu reguł zapory sieciowej sprawdź, czy zostały dodane trzy reguły:
lista reguł zapory gcloud compute \ --project=$PROJECT_ID \ --filter="NETWORK=network-$NAME_SUFFIX"Poniższe przykładowe dane wyjściowe pokazują, że trzy reguły zostały utworzone poprawnie:
NAZWA KIERUNEK SIECI PRIORYTET 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
## Utwórz i skonfiguruj podstawowy obraz maszyny wirtualnej
Aby utworzyć identyczne maszyny wirtualne, które wdrażasz bez dodatkowej konfiguracji, użyj niestandardowego obrazu maszyny wirtualnej. Ten obraz przechwytuje konfigurację systemu operacyjnego i serwera Apache oraz służy do tworzenia każdej maszyny wirtualnej w zarządzanej grupie instancji w kolejnych krokach

Na maszynie wirtualnej tworzysz plik basic
plik index.html na dysku trwałym i
zamontować go do
/var/www/example.com. Plik konfiguracyjny Apache pod adresem
/etc/apache2/sites-available/example.com.conf obsługuje treści internetowe z
zamontowana lokalizacja dysku trwałego

Poniższy diagram przedstawia podstawową stronę HTML obsługiwaną przez Apache, która jest przechowywana na dysku trwałym:
Tworzysz to środowisko w następujących krokach

Utwórz podstawową maszynę wirtualną z dołączonym dyskiem trwałym:
tworzenie instancji gcloud compute 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
Używasz parametrów zdefiniowanych na początku tego dokumentu, aby nazwać maszynę wirtualną i połączyć się z odpowiednią podsiecią. Nazwy są również przypisywane na podstawie parametrów dysku rozruchowego i dysku z danymi

Aby zainstalować i skonfigurować prostą stronę internetową, najpierw połącz się z bazową maszyną wirtualną za pomocą SSH:
gcloud compute ssh vm-base-$NAME_SUFFIX --zone=$STREFA
W sesji SSH z maszyną wirtualną utwórz skrypt do konfigurowania maszyny wirtualnej w wybranym przez siebie edytorze. Poniższy przykład używa Nano jako edytora:
nano konfiguracja maszyny wirtualnej.
Wklej następujący skrypt konfiguracyjny do pliku:
bin/bash NAME_SUFFIX=
app# Utwórz katalog dla podstawowych plików witryny sudo mkdir -p /var/www/example.com sudo chmod a+w /var/www/example.com sudo chown -R www-data: /var/www/example.com # Znajdź nazwę dysku, a następnie sformatuj go i zamontuj 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 odrzuć,defaults $DISK_PATH /var/www/example.com # Zainstaluj Apache sudo apt-get update&& sudo apt-get -y install apache2 # Zapisz podstawowy plik HTML na zamontowanym dysku trwałym sudo tee -a /var/ www/example.com/index.html >/dev/null EOF'    Przykład HA / DR   
Witamy w witrynie Compute Engine z ciepłym przełączaniem awaryjnym do 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 # Włącz plik konfiguracyjny Apache i przeładuj usługę sudo a2dissite 000-default sudo a2ensite example.com.conf sudo systemctl przeładuj apache2
Zaktualizuj
zmiennej, aby pasowała do wartości ustawionej na początku tego dokumentu, na przykład
Aplikacja NAME_SUFFIX

Zapisz plik i zamknij edytor. Na przykład w Nano używasz
Ctrl-Oto wypisz plik, a następnie wyjdź za pomocą
Ctrl-X

Ustaw skrypt konfiguracyjny jako wykonywalny, a następnie uruchom go:
chmod +x configure-vm../configure-vm.
Wyjdź z sesji SSH do maszyny wirtualnej:
Wyjście
Uzyskaj adres IP maszyny wirtualnej i użyj
curl, aby zobaczyć podstawową stronę internetową:
curl $(gcloud compute instancje opisują vm-base-$NAME_SUFFIX \ --zone $ZONE \ --format="value(networkInterfaces.accessConfigs.[0].natIP
Zostanie zwrócona podstawowa witryna sieci Web, jak pokazano w poniższym przykładowym wyniku:
    Przykład HA / DR   
Witamy w witrynie Compute Engine z ciepłym przełączaniem awaryjnym do Cloud Storagep>

# Utwórz podstawowe obrazy maszyn wirtualnych gcloud compute images create image-$NAME_SUFFIX \ --source-disk=vm-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE obrazy gcloud compute create image-disk-$NAME_SUFFIX \ - -source-disk=disk-base-$NAME_SUFFIX \ --source-disk-zone=$ZONE # Tworzenie szablonów instancji 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\ wartość\ /dev/sdb /var/www/example.com\ ext4\ odrzuć,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\ wartość\ /dev/sdb /var/www/example.com\ ext4\ disc,defaults ,nofail\ 0\ 2 ee\ -a\ /etc/fstabn'mount\ -a \ --image=image-$NAZWA_SUFFIX \ --create-disk=image=image-disk-$NAME_SUFFIX,auto-delete=yes # Utwórz kontrolę stanu instancji maszyn wirtualnych gcloud compute health-checks create http http-basic-check-$NAME_SUFFIX \ --port 80 # Utwórz zarządzane grupy instancji 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 zarządzane grupy instancji tworzenie grupy instancji -$NAZWA_SUFFIX-$REGION2 \ --template=template-$NAZWA_SUFFIX-$REGION2 \ --size=2 \ --region=$REGION2 \ --health-check=http-basic-check-$NAME_SUFFIX
## Utwórz i skonfiguruj system równoważenia obciążenia
Aby użytkownicy mogli uzyskać dostęp do Twojej witryny, musisz zezwolić na ruch do maszyn wirtualnych działających w zarządzanych grupach instancji. Chcesz również automatycznie przekierować ruch do nowych maszyn wirtualnych, jeśli wystąpi awaria strefy w zarządzanej grupie instancji

W poniższej sekcji utworzysz zewnętrzny system równoważenia obciążenia HTTPS z usługą zaplecza dla ruchu HTTP na porcie 80, użyjesz kontroli stanu utworzonej w poprzednich krokach i zmapujesz zewnętrzny adres IP do usługi zaplecza

Aby uzyskać więcej informacji, zobacz Jak skonfigurować prosty zewnętrzny moduł równoważenia obciążenia HTTP

Utwórz i skonfiguruj moduł równoważenia obciążenia dla swojej aplikacji:
# Skonfiguruj reguły portów dla portu 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- nazwany-ports \ instance-group-$NAME_SUFFIX-$REGION2 \ --named-ports http:80 \ --region $REGION2 # Utwórz usługę zaplecza i dodaj do niej zarządzane grupy instancji 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 # Utwórz mapę URL dla usługi zaplecza gcloud compute url-maps create mapa-internetowa-http-$NAME_SUFFIX \ --default-service web-backend-service-$NAME_SUFFIX # Skonfiguruj przekazywanie ruchu HTTP gcloud compute target-http-proxy 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
Uzyskaj adres IP reguły przekierowania dla ruchu sieciowego:
IP_ADDRESSgcloud compute forwarding-rules opisują http-content-rule-$NAME_SUFFIX \ --global \ --format="value(IPAddress
Posługiwać się
curl lub otwórz przeglądarkę internetową, aby wyświetlić stronę internetową przy użyciu adresu IP modułu równoważenia obciążenia z poprzedniego kroku:
zwiń $IP_ADDRESS
Zakończenie wdrażania systemu równoważenia obciążenia i prawidłowe przekierowanie ruchu do backendu zajmuje kilka minut. Błąd HTTP 404 jest zwracany, jeśli moduł równoważenia obciążenia jest nadal wdrażany. W razie potrzeby poczekaj kilka minut i spróbuj ponownie uzyskać dostęp do witryny

Zostanie zwrócona podstawowa witryna sieci Web, jak pokazano w poniższym przykładowym wyniku:
    Przykład HA / DR   
Witamy w witrynie Compute Engine z ciepłym przełączaniem awaryjnym do 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.