Failover multiregionale per endpoint esterni regionali utilizzando i controlli di integrità di Cloud DNS

1. Introduzione

Il servizio Cloud DNS offre una soluzione DNS (Domain Name System) globale, resiliente e ad alte prestazioni, che ti consente di pubblicare zone e record senza la necessità di un'infrastruttura DNS autogestita.

Ancora più importante, Cloud DNS incorpora il supporto per i controlli di integrità e le funzionalità di failover automatico all'interno delle sue policy di routing per gli endpoint esterni. Tuttavia, tieni presente che i controlli di integrità per questi endpoint esterni sono disponibili esclusivamente nelle zone pubbliche e gli endpoint stessi devono essere accessibili pubblicamente tramite internet.

Cosa imparerai a fare

Come creare un bilanciatore del carico delle applicazioni esterno regionale con un gruppo di istanze non gestite.
Come configurare i controlli di integrità di Cloud DNS per il routing DNS esterno.
Come creare una policy di routing di failover.

Che cosa ti serve

Conoscenza di base del DNS.
Conoscenza di base di Google Compute Engine.
Conoscenza di base del bilanciatore del carico delle applicazioni.
Un progetto Google Cloud con autorizzazioni di proprietario
Un dominio pubblico di tua proprietà, per il quale puoi creare una zona pubblica Cloud DNS.
Le seguenti norme dell'organizzazione attualmente non vengono applicate nel progetto Google Cloud: VM schermate e gruppi di endpoint di rete internet.

2. Topologia del codelab

In questo codelab, utilizzerai i controlli di integrità di Cloud DNS per gli endpoint esterni per reindirizzare il traffico a un bilanciatore del carico delle applicazioni esterno regionale di backup se il backend del bilanciatore del carico principale non è integro.

Creerai un sito web in due regioni, ciascuna con un bilanciatore del carico delle applicazioni esterno. Dopodiché, configurerai i controlli di integrità di Cloud DNS con una policy di routing di failover.

3. Configurazione e requisiti

Configurazione dell'ambiente autonomo

Accedi alla console Google Cloud e crea un nuovo progetto o riutilizzane uno esistente. Se non hai ancora un account Gmail o Google Workspace, devi crearne uno.

Il nome del progetto è il nome visualizzato per i partecipanti a questo progetto. È una stringa di caratteri non utilizzata dalle API di Google. Puoi sempre aggiornarlo.
L'ID progetto è univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo l'impostazione). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere identificato come PROJECT_ID). Se l'ID generato non ti piace, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimane per tutta la durata del progetto.
Per tua informazione, esiste un terzo valore, un numero di progetto, utilizzato da alcune API. Scopri di più su tutti e tre questi valori nella documentazione.

Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. Completare questo codelab non costa molto, se non nulla. Per arrestare le risorse ed evitare addebiti oltre a quelli previsti in questo tutorial, puoi eliminare le risorse che hai creato o il progetto. I nuovi utenti di Google Cloud possono beneficiare del programma prova senza costi di 300$.

Avvia Cloud Shell

Sebbene Google Cloud possa essere gestito da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

Nella console Google Cloud, fai clic sull'icona di Cloud Shell nella barra degli strumenti in alto a destra:

Attiva Cloud Shell

Bastano pochi istanti per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere un risultato simile a questo:

Screenshot del terminale Google Cloud Shell che mostra che l'ambiente è connesso

Questa macchina virtuale è caricata con tutti gli strumenti per sviluppatori di cui avrai bisogno. Offre una home directory permanente da 5 GB e viene eseguita su Google Cloud, migliorando notevolmente le prestazioni e l'autenticazione della rete. Tutto il lavoro in questo codelab può essere svolto all'interno di un browser. Non devi installare nulla.

4. Prima di iniziare

Abilita API

In Cloud Shell, assicurati che il progetto sia configurato e configura le variabili.

gcloud auth login
gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
export projectid=[YOUR-PROJECT-ID]

# Define variables for regions and the domain
export REGION_A=us-central1
export REGION_B=us-west1
export DNS_ZONE=dnscodelab-zone
Export DNS_DOMAIN=gcp.<yourpublicdomain>.com
echo $projectid
echo $REGION_A
echo $REGION_B
echo $DNS_ZONE
echo $DNS_DOMAIN

Attiva tutti i servizi necessari

gcloud services enable compute.googleapis.com 
gcloud services enable dns.googleapis.com

5. Crea l'infrastruttura Cloud Load Balancing

In questa sezione, creerai il VPC, le subnet, le regole firewall, le VM e i gruppi di istanze non gestite necessari in due regioni diverse per supportare i bilanciatori del carico primario e di backup.

Rete VPC

Da Cloud Shell

gcloud compute networks create external-lb-vpc --subnet-mode=custom

Crea due subnet in REGION_A (principale) e REGION_B (backup) per ospitare i server web di backend

Crea subnet

Da Cloud Shell

gcloud compute networks subnets create subnet-a --network=external-lb-vpc --region=$REGION_A --range=10.10.1.0/24

gcloud compute networks subnets create subnet-b --network=external-lb-vpc --region=$REGION_B --range=10.20.1.0/24

Crea subnet solo proxy in ogni regione per il rispettivo bilanciatore del carico delle applicazioni esterno regionale che verrà creato in un secondo momento.

Questa subnet solo proxy dedicata è un requisito obbligatorio per tutti i bilanciatori del carico regionali basati su Envoy di cui è stato eseguito il deployment nella stessa regione della rete external-lb-vpc. Questi proxy terminano effettivamente la connessione del client e successivamente stabiliscono nuove connessioni ai servizi di backend.

Da Cloud Shell

gcloud compute networks subnets create proxy-only-subnet-a \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_A \
--network=external-lb-vpc \
--range=10.129.0.0/23

gcloud compute networks subnets create proxy-only-subnet-b \
--purpose=REGIONAL_MANAGED_PROXY \
--role=ACTIVE \
--region=$REGION_B \
--network=external-lb-vpc \
--range=10.130.0.0/23

Crea regole firewall di rete

fw-allow-health-check. Una regola in entrata, applicabile alle istanze con bilanciamento del carico, che consente tutto il traffico TCP proveniente dai sistemi di controllo di integrità di Google Cloud (in 130.211.0.0/22 e 35.191.0.0/16). Questo esempio utilizza il tag di destinazione load-balanced-backend per identificare le VM a cui si applica la regola firewall.

fw-allow-proxies. Una regola in entrata, applicabile alle istanze sottoposte a bilanciamento del carico, che consente il traffico TCP sulle porte 80 dai proxy gestiti del bilanciatore del carico delle applicazioni esterno regionale. Questo esempio utilizza il tag di destinazione load-balanced-backend per identificare le VM a cui si applica la regola firewall.

Da Cloud Shell

gcloud compute firewall-rules create fw-allow-health-check \
    --network=external-lb-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp
gcloud compute firewall-rules create fw-allow-proxies \
  --network=external-lb-vpc \
  --action=allow \
  --direction=ingress \
  --source-ranges=10.129.0.0/23,10.130.0.0/23 \
  --target-tags=load-balanced-backend \
  --rules=tcp:80

Per consentire a IAP di connettersi alle tue istanze VM, crea una regola firewall che:

Si applichi a tutte le istanze VM a cui vuoi accedere tramite IAP.
Consente il traffico in entrata dall'intervallo IP 35.235.240.0/20. Questo intervallo contiene tutti gli indirizzi IP che utilizzati da IAP per l'inoltro TCP.

Da Cloud Shell

gcloud compute firewall-rules create allow-ssh \
    --allow tcp:22 --network external-lb-vpc \
    --source-ranges 35.235.240.0/20  \
    --description "SSH with IAP" \
    --target-tags=allow-ssh

6. Crea Cloud NAT e router Cloud

Per consentire alle VM private di scaricare e installare pacchetti da internet, sono necessari gateway Cloud NAT in entrambe le regioni.

Le nostre VM del server web dovranno scaricare e installare il server web Apache.
La VM client dovrà scaricare e installare il pacchetto dnsutils, che utilizzeremo per i nostri test.

Ogni gateway Cloud NAT è associato a una singola rete VPC, regione e router Cloud. Pertanto, prima di creare i gateway NAT, dobbiamo creare i router cloud in ogni regione.

Crea router Cloud

Da Cloud Shell

gcloud compute routers create "$REGION_A-cloudrouter" \
--region $REGION_A --network=external-lb-vpc --asn=65501

gcloud compute routers create "$REGION_B-cloudrouter" \
--region $REGION_B --network=external-lb-vpc --asn=65501

Crea gateway NAT

Da Cloud Shell

gcloud compute routers nats create "$REGION_A-nat-gw" \
--router="$REGION_A-cloudrouter" \
--router-region=$REGION_A \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

gcloud compute routers nats create "$REGION_B-nat-gw" \
--router="$REGION_B-cloudrouter" \
--router-region=$REGION_B \
--nat-all-subnet-ip-ranges --auto-allocate-nat-external-ips

Crea VM di backend e gruppi di istanze non gestite

Crea una VM in ogni regione e installa il server web (ad es.Apache):

Da Cloud Shell

# Primary (Region A)
gcloud compute instances create vm-a \
--zone=$REGION_A-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-a \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_A Primary Backend |\
tee /var/www/html/index.html
systemctl restart apache2'


# Backup (Region B)
gcloud compute instances create vm-b \
--zone=$REGION_B-a \
--image-family=debian-12 --image-project=debian-cloud \
--subnet=subnet-b \
--no-address \
--tags=load-balanced-backend,allow-ssh \
--metadata=startup-script='#! /bin/bash
apt-get update
apt-get install apache2 -y
a2ensite default-ssl
a2enmod ssl
vm_hostname="$(curl -H "Metadata-Flavor:Google" \
http://metadata.google.internal/computeMetadata/v1/instance/name)"
echo "Page served from: $vm_hostname" - $REGION_B Backup Backend |\
tee /var/www/html/index.html
systemctl restart apache2'

Crea un gruppo di istanze non gestite e aggiungi l'istanza VM per ogni regione:

Da Cloud Shell

# Primary (Region A)
gcloud compute instance-groups unmanaged create ig-a --zone=$REGION_A-a

gcloud compute instance-groups unmanaged add-instances ig-a --zone=$REGION_A-a --instances=vm-a

# Backup (Region B)
gcloud compute instance-groups unmanaged create ig-b --zone=$REGION_B-a

gcloud compute instance-groups unmanaged add-instances ig-b --zone=$REGION_B-a --instances=vm-b

7. Configura i bilanciatori del carico delle applicazioni esterni regionali

Configurerai un bilanciatore del carico delle applicazioni esterno regionale completo sia in REGION_A (principale) che in REGION_B (backup).

Crea controlli di integrità e servizi di backend

I bilanciatori del carico delle applicazioni esterni regionali sono basati su Envoy e richiedono la configurazione di controlli di integrità regionali.

Crea un controllo di integrità HTTP (utilizzato dai bilanciatori del carico per controllare l'integrità delle istanze):

In Cloud Shell

gcloud compute health-checks create http http-lb-hc-primary-region \
--port 80 \
--region=$REGION_A

gcloud compute health-checks create http http-lb-hc-backup-region \
--port 80 \
--region=$REGION_B

Crea un servizio di backend regionale e collega il gruppo di istanze in ogni regione.

In Cloud Shell

# Primary (Region A)
gcloud compute backend-services create be-svc-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-primary-region \
--health-checks-region=$REGION_A \
--region=$REGION_A

gcloud compute backend-services add-backend be-svc-a \
--instance-group=ig-a \
--instance-group-zone=$REGION_A-a \
--region=$REGION_A

# Backup (Region B)
gcloud compute backend-services create be-svc-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--protocol=HTTP \
--port-name=http \
--health-checks=http-lb-hc-backup-region \
--health-checks-region=$REGION_B \
--region=$REGION_B

gcloud compute backend-services add-backend be-svc-b --instance-group=ig-b --instance-group-zone=$REGION_B-a --region=$REGION_B

Crea componenti frontend

Crea mappe URL e proxy HTTP di destinazione in entrambe le regioni:

In Cloud Shell

#Primary (Region A)
gcloud compute url-maps create url-map-a \
--default-service=be-svc-a \
--region=$REGION_A
gcloud compute target-http-proxies create http-proxy-a \
--url-map=url-map-a \
--url-map-region=$REGION_A \
--region=$REGION_A
#Backup (Region B)
gcloud compute url-maps create url-map-b \
--default-service=be-svc-b \
--region=$REGION_B

gcloud compute target-http-proxies create http-proxy-b \
--url-map=url-map-b \
--url-map-region=$REGION_B \
--region=$REGION_B

Prenota indirizzi IP statici (esterni) per le regole di forwarding:

In Cloud Shell

# Primary IP (Region A)
gcloud compute addresses create rxlb-ip-a --region=$REGION_A

# Backup IP (Region B)
gcloud compute addresses create rxlb-ip-b --region=$REGION_B

Crea le regole di forwarding per i due bilanciatori del carico:

In Cloud Shell

# Primary (Region A)
gcloud compute forwarding-rules create http-fwd-rule-a \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_A \
--target-http-proxy-region=$REGION_A \
--address=rxlb-ip-a \
--target-http-proxy=http-proxy-a \
--ports=80

# Backup (Region B)
gcloud compute forwarding-rules create http-fwd-rule-b \
--load-balancing-scheme=EXTERNAL_MANAGED \
--network=external-lb-vpc \
--region=$REGION_B \
--target-http-proxy-region=$REGION_B \
--address=rxlb-ip-b \
--target-http-proxy=http-proxy-b \
--ports=80

Configura Cloud DNS per il failover

Crea il controllo di integrità di Cloud DNS per gli endpoint esterni

Devi creare un controllo di integrità globale dedicato per gli indirizzi IP pubblici del bilanciatore del carico. Questo è diverso dal controllo di integrità interno del bilanciatore del carico.

Innanzitutto, determiniamo gli indirizzi IP esterni dei bilanciatori del carico per configurare la policy di failover ed esportarli come variabile.

In Cloud Shell

PRIMARY_IP=$(gcloud compute addresses describe rxlb-ip-a --region=$REGION_A --format='get(address)')

BACKUP_IP=$(gcloud compute addresses describe rxlb-ip-b --region=$REGION_B --format='get(address)')

Crea il controllo di integrità DNS globale (richiede tre regioni di origine):

In Cloud Shell

gcloud beta compute health-checks create http dns-failover-health-check \
    --global \
    --source-regions=$REGION_A,$REGION_B,europe-west1 \
    --request-path=/ \
    --check-interval=30s \
    --port=80 \
    --enable-logging

Crea una zona gestita pubblica e una policy di routing di failover.

Crea una zona pubblica gestita (utilizza il dominio DNS di tua proprietà):

In Cloud Shell

gcloud dns managed-zones create codelab-publiczone --dns-name=$DNS_DOMAIN --description="Codelab DNS Failover Zone"

Crea il record A con una policy di routing di failover. Questo criterio punta all'IP primario e utilizza il controllo di integrità per determinare quando eseguire il failover all'IP di backup.

Il comando riportato di seguito utilizza i nomi delle regole di forwarding del bilanciatore del carico per fare riferimento agli indirizzi IP per la policy di routing.

gcloud beta dns record-sets create codelab.gcp.axiszulu.com. \
--type=A \
--ttl=5 \
--zone=codelab-publiczone \
--routing_policy_type=FAILOVER \
--routing-policy-primary-data=$PRIMARY_IP \
--routing-policy-backup-data-type=GEO \
--routing-policy-backup-item=location=$REGION_B,external_endpoints=$BACKUP_IP \
--health-check=dns-failover-health-check

8. Test del failover regionale

Convalida iniziale:utilizza uno strumento (come dig o un browser web) per eseguire query sul tuo dominio. Dovrebbe essere risolto nell'IP principale ($PRIMARY_IP) e restituire la pagina "Regione A - Backend principale".

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <PRIMARY_IP>

Output dal browser

Simula il failover:accedi alla VM primaria (vm-a) e arresta Apache per simulare un'interruzione del servizio:

In Cloud Shell

gcloud compute ssh vm-a --zone=$REGION_A-a --command="sudo systemctl stop apache2"

Verifica lo stato non integro:attendi 2-3 minuti affinché il controllo di integrità DNS contrassegni l'endpoint primario come non integro.

# check health status
gcloud compute backend-services get-health be-svc-a --region=${REGION_A}

Output:
backend: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instanceGroups/ig-a
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://www.googleapis.com/compute/v1/projects/precise-airship-466617-c3/zones/us-central1-a/instances/vm-a
    ipAddress: 10.10.1.2
    port: 80
  kind: compute#backendServiceGroupHealth

Convalida del failover:esegui di nuovo la query del dominio. Ora dovrebbe essere risolto con l'IP di backup ($BACKUP_IP) e restituire la pagina "Region B - Backup Backend".

dig codelab.gcp.axiszulu.com

OUTPUT
; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> codelab.gcp.axiszulu.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;codelab.gcp.axiszulu.com.      IN      A

;; ANSWER SECTION:
codelab.gcp.axiszulu.com. 5     IN      A   <BACKUP_IP>

Output dal browser

(Facoltativo) Simula il failback: esegui SSH e avvia Apache sulla VM principale e attendi che il controllo di integrità DNS contrassegni l'endpoint principale come integro. Il traffico dovrebbe essere reindirizzato automaticamente all'IP principale.
(Facoltativo) Puoi analizzare la registrazione del controllo di integrità di Cloud DNS eseguendo il comando riportato di seguito in Cloud Shell.

gcloud logging read "logName=projects/${projectid}/logs/compute.googleapis.com%2Fhealthchecks" \
--limit=10 \
--project=${projectid} \
--freshness=1d \
--format="table(timestamp:label=TIME, \
jsonPayload.healthCheckProbeResult.ipAddress:label=BACKEND_IP, \
jsonPayload.healthCheckProbeResult.previousDetailedHealthState:label=PREVIOUS_STATE, \
jsonPayload.healthCheckProbeResult.detailedHealthState:label=CURRENT_STATE, \
jsonPayload.healthCheckProbeResult.probeResultText:label=RESULT_TEXT)"

9. Procedura di pulizia

Elimina tutti i componenti per evitare ulteriori addebiti.

Da Cloud Shell

# Delete VMs
gcloud compute instances delete vm-a --zone=$REGION_A-a --quiet
gcloud compute instances delete vm-b --zone=$REGION_B-a --quiet
# Delete Load Balancer Components (Primary)
gcloud compute forwarding-rules delete http-fwd-rule-a --region=$REGION_A --quiet
gcloud compute target-http-proxies delete http-proxy-a --region=$REGION_A --quiet
gcloud compute url-maps delete url-map-a --region=$REGION_A --quiet
gcloud compute backend-services delete be-svc-a --region=$REGION_A --quiet
gcloud compute addresses delete rxlb-ip-a --region=$REGION_A --quiet
# Delete Load Balancer Components (Backup)
gcloud compute forwarding-rules delete http-fwd-rule-b --region=$REGION_B --quiet
gcloud compute target-http-proxies delete http-proxy-b --region=$REGION_B --quiet
gcloud compute url-maps delete url-map-b --region=$REGION_B --quiet
gcloud compute backend-services delete be-svc-b --region=$REGION_B --quiet
gcloud compute addresses delete rxlb-ip-b --region=$REGION_B --quiet
# Delete Instance Groups and LB Health Checks
gcloud compute instance-groups unmanaged delete ig-a --zone=$REGION_A-a --quiet
gcloud compute instance-groups unmanaged delete ig-b --zone=$REGION_B-a --quiet
gcloud compute health-checks delete http-lb-hc-primary-region --region=$REGION_A --quiet
gcloud compute health-checks delete http-lb-hc-backup-region --region=$REGION_B --quiet

# Delete Cloud DNS Records Zone and DNS Heath Checks
gcloud dns record-sets delete $DNS_DOMAIN --type=A --zone=codelab-publiczone --quiet
gcloud dns managed-zones delete codelab-publiczone --quiet

gcloud compute health-checks delete dns-failover-health-check --global --quiet

# Delete Cloud NAT and Cloud Routers
gcloud compute routers nats delete $REGION_A-nat-gw \
--router=$REGION_A-cloudrouter --region=$REGION_A --quiet

gcloud compute routers nats delete $REGION_B-nat-gw \
--router=$REGION_B-cloudrouter --region=$REGION_B --quiet

gcloud compute routers delete $REGION_A-cloudrouter \
--region=$REGION_A --quiet

gcloud compute routers delete $REGION_B-cloudrouter \
--region=$REGION_B --quiet


# Delete Subnets and Firewall Rules
gcloud compute firewall-rules delete fw-allow-health-check --quiet
gcloud compute firewall-rules delete fw-allow-proxies --quiet
gcloud compute firewall-rules delete allow-ssh --quiet
gcloud compute networks subnets delete subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete subnet-b \
--region=$REGION_B --quiet
gcloud compute networks subnets delete proxy-only-subnet-a \
--region=$REGION_A --quiet

gcloud compute networks subnets delete proxy-only-subnet-b \
--region=$REGION_B --quiet

gcloud compute networks delete external-lb-vpc --quiet

10. Complimenti!

Congratulazioni per aver completato il codelab.

Hai configurato e convalidato correttamente un failover attivo/passivo multiregionale utilizzando i controlli di integrità di Cloud DNS e il bilanciatore del carico delle applicazioni esterno regionale

Failover multiregionale per endpoint esterni regionali utilizzando i controlli di integrità di Cloud DNS

1. Introduzione

Cosa imparerai a fare

Che cosa ti serve

2. Topologia del codelab

3. Configurazione e requisiti

Configurazione dell'ambiente autonomo

Avvia Cloud Shell

4. Prima di iniziare

Abilita API

5. Crea l'infrastruttura Cloud Load Balancing

Rete VPC

Crea subnet

Crea regole firewall di rete

6. Crea Cloud NAT e router Cloud

Crea router Cloud

Crea gateway NAT

Crea VM di backend e gruppi di istanze non gestite

7. Configura i bilanciatori del carico delle applicazioni esterni regionali

Crea controlli di integrità e servizi di backend

Crea un servizio di backend regionale e collega il gruppo di istanze in ogni regione**.**

Crea componenti frontend

Configura Cloud DNS per il failover

Crea il controllo di integrità di Cloud DNS per gli endpoint esterni

Crea una zona gestita pubblica e una policy di routing di failover.

8. Test del failover regionale

9. Procedura di pulizia

10. Complimenti!

Crea un servizio di backend regionale e collega il gruppo di istanze in ogni regione.