Failover in più regioni utilizzando i criteri di routing e i controlli di integrità di Cloud DNS per il bilanciatore del carico TCP/UDP interno

1. Introduzione

Ultimo aggiornamento: 22/09/2022

Che cos'è una policy di routing DNS

Le policy di routing DNS di Cloud DNS consentono agli utenti di configurare l'indirizzamento del traffico basato su DNS in base a criteri specifici come peso, posizione geografica o controlli di integrità.

Cloud DNS supporta le seguenti policy di routing:

• Policy di routing round robin ponderata
• Policy di routing basata sulla geolocalizzazione
• Policy di routing con geofencing
• Policy di routing di failover

In questo lab configurerai e testerai il criterio di routing di failover.

Nota: al momento della stesura di questo lab, sia la policy di failover sia il supporto dei controlli di integrità sono in anteprima pubblica.

Policy di routing di failover

Cloud DNS supporta i controlli di integrità per i bilanciatori del carico TCP/UDP interni per cui è abilitato l'accesso globale. Con una policy di routing di failover, puoi configurare IP primari e di backup per un record di risorse. Durante il normale funzionamento, Cloud DNS risponderà alle query con gli indirizzi IP di cui è stato eseguito il provisioning nel set principale. Quando tutti gli indirizzi IP nel set principale non superano il controllo (lo stato di integrità cambia in non integro), Cloud DNS inizia a pubblicare gli indirizzi IP nel set di backup.

Nota:affinché Cloud DNS funzioni come previsto con i controlli di integrità, è necessario abilitare l'accesso globale sul bilanciatore del carico. Gli utenti potranno creare criteri di routing per i bilanciatori del carico interni con accesso globale disattivato, ma il failover di Cloud DNS non funzionerà.

Controlli di integrità

La policy di routing DNS dipende dai controlli di integrità unificati(UHC) del bilanciatore del carico interno nativo. Un bilanciatore del carico interno è considerato integro se il 20% (o più) dei backend è integro. I controlli di integrità per i bilanciatori del carico TCP/UDP interni e HTTP(S) interni forniscono informazioni diverse. Per un bilanciatore del carico HTTP(S) interno, il controllo di integrità utente fornisce lo stato di integrità di tutti i proxy Envoy, mentre per un bilanciatore del carico TCP/UDP interno, Cloud DNS riceve segnali di integrità diretti dalle singole istanze di backend. I dettagli dei controlli di integrità sono disponibili qui .

Cosa creerai

In questo Codelab, creerai un sito web in esecuzione in due regioni e gli assocerai una policy di routing DNS di failover. La configurazione prevede:

Risorse attive:

• Bilanciatore del carico interno L4 in REGION_1
• Una VM che esegue il server web Apache in REGION_1

Risorse di backup:

• Bilanciatore del carico interno L4 in REGION_2
• Una VM che esegue il server web Apache in REGION_2

La configurazione è mostrata di seguito:

Nota:per semplificare questo codelab, avremo un unico bilanciatore del carico in ciascuna delle regioni configurato come insieme attivo e di backup della policy di routing di failover.

Cosa imparerai a fare

• Come creare un criterio di routing di failover
• Attiva failover DNS
• Come distribuire gradualmente il traffico al set di backup

Che cosa ti serve

• Conoscenza di base del DNS
• Conoscenza di base di Google Compute Engine
• Conoscenza di base del bilanciatore del carico interno L4

2. Configurazione e requisiti

1. 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 aggiornarlo in qualsiasi momento.
• L'ID progetto deve essere univoco in tutti i progetti Google Cloud ed è immutabile (non può essere modificato dopo essere stato impostato). La console Cloud genera automaticamente una stringa univoca, di solito non ti interessa di cosa si tratta. Nella maggior parte dei codelab, devi fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se non ti piace l'ID generato, puoi generarne un altro casuale. In alternativa, puoi provare a crearne uno e vedere se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà 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.

Attenzione:un ID progetto deve essere univoco a livello globale e non può essere utilizzato da altri dopo che lo hai selezionato. Sei l'unico utente di questo ID. Anche se un progetto viene eliminato, l'ID non potrà mai più essere utilizzato

Nota:se utilizzi un account Gmail, puoi lasciare la posizione predefinita impostata su Nessuna organizzazione. Se utilizzi un account Google Workspace, scegli una posizione adatta alla tua organizzazione.

2. Successivamente, devi abilitare la fatturazione in Cloud Console per utilizzare le risorse/API Cloud. L'esecuzione di questo codelab non dovrebbe costare molto, se non nulla. Per arrestare le risorse in modo da non incorrere in costi di fatturazione al termine di questo tutorial, puoi eliminare le risorse che hai creato o l'intero 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:

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

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.

3. Versione di Google Cloud SDK

Al momento della stesura di questo documento, 401.0.0 è l'ultima versione di Google Cloud SDK. Tutti i comandi di questo lab sono stati testati utilizzando l'ultima versione di Google Cloud SDK. Prima di procedere, assicurati che Cloud Shell utilizzi l'ultima versione dell'SDK.

Controllare la versione dell'SDK

Utilizza il comando gcloud version per controllare la versione dell'SDK. Esegui questi comandi in Cloud Shell

Comando

gcloud version | grep "Google Cloud SDK"

Esempio di output

Google Cloud SDK 401.0.0

Passaggi successivi

Attenzione:seleziona l'opzione 1 o 2 in base all'output del comando gcloud version

1. Se la versione dell'SDK è 401.0.0 o successive, vai alla sezione successiva.
2. Se la versione dell'SDK è precedente alla 401.0.0, esegui il comando elencato di seguito per aggiornare l'SDK.

Optional Command

sudo apt-get update && sudo apt-get install google-cloud-sdk

4. Prima di iniziare

Prima di iniziare a eseguire il deployment dell'architettura che abbiamo spiegato sopra, assicuriamoci che Cloud Shell sia configurata correttamente e che tutte le API richieste siano abilitate.

Configurare l'ID progetto

In Cloud Shell, assicurati che l'ID progetto sia configurato. Se il prompt di Cloud Shell è simile all'output riportato di seguito e non prevedi di modificare l'ID progetto, puoi passare al passaggio successivo (Imposta le variabili di ambiente).

USER@cloudshell:~ (PROJECT_ID)$

Se vuoi comunque modificare l'ID progetto, utilizza il comando elencato di seguito. Il prompt di Cloud Shell cambierà da (PROJECT_ID) a (YOUR-PROJECT-ID)

Optional Command

gcloud config set project [YOUR-PROJECT-ID]

Esempio di output

Updated property [core/project].
USER@cloudshell:~ (YOUR-PROJECT-ID)$

Imposta le variabili di ambiente

Imposta le variabili di ambiente

Utilizzeremo il comando export per impostare le variabili di ambiente. Esegui questi comandi in Cloud Shell

Comandi

export REGION_1=us-west1

export REGION_1_ZONE=us-west1-a

export REGION_2=us-east4

export REGION_2_ZONE=us-east4-a

Nota: in questo lab utilizziamo le regioni us-west1 e us-east4. La capacità di calcolo può essere limitata in una zona. Se visualizzi errori di capacità durante la creazione delle VM, utilizza una regione/zona diversa. Un elenco delle regioni e delle zone disponibili è disponibile qui.

Verifica

Ora che le variabili di ambiente sono impostate, verifichiamo utilizzando il comando echo. L'output di ogni comando deve essere il valore che abbiamo configurato in precedenza utilizzando il comando export. Esegui questi comandi in Cloud Shell

Comandi

echo $REGION_1

echo $REGION_1_ZONE

echo $REGION_2

echo $REGION_2_ZONE

Attivare tutti i servizi necessari

Utilizza il comando gcloud services enable per abilitare le API Compute e DNS. Esegui questi comandi in Cloud Shell

Abilita l'API Compute

Comando

gcloud services enable compute.googleapis.com

Abilita l'API DNS

Comando

gcloud services enable dns.googleapis.com

Verifica

Ora che i servizi sono abilitati, verifichiamo utilizzando il comando gcloud services list per elencare tutte le API abilitate.

Comando

gcloud services list | grep -E 'compute|dns'

Esempio di output

NAME: compute.googleapis.com
NAME: dns.googleapis.com

5. Crea rete VPC, subnet e regole firewall

In questa sezione creeremo la rete VPC, due subnet (una in ogni regione) e le regole firewall richieste.

Crea rete VPC

Utilizza il comando gcloud compute networks create per creare la rete VPC. Impostiamo la modalità subnet come personalizzata perché creeremo le nostre subnet nel passaggio successivo. Esegui questi comandi in Cloud Shell.

Comando

gcloud compute networks create my-vpc --subnet-mode custom

Crea subnet

Utilizza il comando gcloud compute networks subnets create per creare due subnet, una in REGION_1 e una in REGION_2. Esegui questi comandi in Cloud Shell

Subnet REGION_1

Comando

gcloud compute networks subnets create ${REGION_1}-subnet \
--network my-vpc \
--range 10.1.0.0/24 \
--region $REGION_1

Subnet REGION_2

Comando

gcloud compute networks subnets create ${REGION_2}-subnet \
--network my-vpc \
--range 10.2.0.0/24 \
--region $REGION_2

Crea regole firewall

Devi consentire il traffico sulla porta 80 dalle subnet VPC e dagli intervalli IP del controllo di integrità del bilanciatore del carico.

Inoltre, devi creare una regola firewall per consentire il traffico SSH sulle VM client.

Utilizza il comando gcloud compute firewall-rules create per creare le regole firewall. Esegui questi comandi in Cloud Shell

Consenti traffico sulla porta 80

Comando

gcloud compute firewall-rules create allow-http-lb-hc \
--allow tcp:80 --network my-vpc \
--source-ranges 10.1.0.0/24,10.2.0.0/24,35.191.0.0/16,130.211.0.0/22 \
--target-tags=allow-http

Consenti il traffico SSH sulla VM client

Comando

gcloud compute firewall-rules create allow-ssh \
--allow tcp:22 --network my-vpc \
--source-ranges 0.0.0.0/0 \
--target-tags=allow-ssh

6. Crea Cloud NAT

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

Utilizza il comando gcloud compute routers create per creare router Cloud nelle regioni us-west1 e us-east4. Esegui questi comandi in Cloud Shell.

Router Cloud Regione_1

Comandi

gcloud compute routers create "${REGION_1}-cloudrouter" \
--region $REGION_1 --network=my-vpc --asn=65501

Router Cloud Region_2

Comandi

gcloud compute routers create "${REGION_2}-cloudrouter" \
--region $REGION_2 --network=my-vpc --asn=65501

Crea i gateway NAT

Utilizza il comando gcloud compute routers nat create per creare i gateway NAT nelle regioni us-west1 e us-east4. Esegui questi comandi in Cloud Shell.

Gateway NAT Region_1

Comandi

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

Gateway NAT Region_2

Comandi

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

7. Crea VM Compute Engine

In questa sezione creerai i server web, i gruppi di istanze non gestite per i server web e la VM client.

Nota: in questo lab utilizziamo le regioni us-west1 e us-east4. La capacità di calcolo può essere limitata in una zona. Se visualizzi errori di capacità durante la creazione delle VM, utilizza una regione/zona diversa. Un elenco delle regioni e delle zone disponibili è disponibile qui.

Crea VM server web

Utilizza il comando gcloud compute instances create per creare i server web. Dobbiamo creare due server web, uno in REGION_1 e l'altro in REGION_2. Utilizziamo script di avvio per installare e configurare Apache sui server web.

Server web REGION_1

Esegui questo comando in Cloud Shell:

Comando

gcloud compute instances create "${REGION_1}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Server web REGION_2

Esegui questo comando in Cloud Shell:

Comando

gcloud compute instances create "${REGION_2}-instance" \
--image-family=debian-11 --image-project=debian-cloud \
--zone=$REGION_2_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_2}-subnet,no-address \
--tags=allow-http \
--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://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Crea gruppi di istanze non gestite

In questa sezione, creiamo due gruppi di istanze non gestite. Utilizzeremo questi gruppi di istanze nella sezione successiva per configurare i servizi di backend del bilanciamento del carico interno. Una volta creati i gruppi di istanze, aggiungeremo le VM del server web a questi gruppi di istanze.

Crea i gruppi di istanze non gestite

Utilizza il comando gcloud compute instance-groups unmanaged create per creare due gruppi di istanze non gestite, uno per il server web us-west1 e uno per il server web us-east4.

Gruppo di istanze Region_1

Comandi

gcloud compute instance-groups unmanaged create \
"${REGION_1}-instance-group" --zone=$REGION_1_ZONE

Gruppo di istanze Region_2

Comandi

gcloud compute instance-groups unmanaged create \
"${REGION_2}-instance-group" --zone=$REGION_2_ZONE

Aggiungi VM ai gruppi di istanze

Utilizza il comando gcloud compute instance-groups unmanaged add-instances per aggiungere le istanze ai gruppi di istanze che abbiamo appena creato. Aggiungi il server web REGION_1 al gruppo di istanze REGION_1 e il server web REGION_2 al gruppo di istanze REGION_2

Gruppo di istanze Region_1

Comandi

gcloud compute instance-groups unmanaged add-instances \
"${REGION_1}-instance-group" --instances $REGION_1-instance \
--zone=$REGION_1_ZONE

Gruppo di istanze Region_2

Comandi

gcloud compute instance-groups unmanaged add-instances \
"${REGION_2}-instance-group" --instances $REGION_2-instance \
--zone=$REGION_2_ZONE

Crea una VM client

Utilizzeremo questa VM per eseguire test e verificare la nostra configurazione DNS. Utilizziamo uno script di avvio per installare il pacchetto dnsutils. Esegui questi comandi in Cloud Shell.

Comando

gcloud compute instances create client-instance --image-family=debian-11 \
--image-project=debian-cloud \
--zone=$REGION_1_ZONE \
--network-interface=network=my-vpc,subnet=${REGION_1}-subnet,no-address \
--tags=allow-ssh \
--metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install dnsutils -y'

8. Crea bilanciatori del carico interni L4

Per creare il bilanciatore del carico interno di livello 4, dobbiamo creare un controllo di integrità, un servizio di backend e una regola di forwarding.

Crea controllo di integrità

Utilizza il comando gcloud compute health-checks create per creare il controllo di integrità. Stiamo creando un controllo di integrità HTTP di base e la porta di destinazione è la porta 80. Esegui questi comandi in Cloud Shell

Comando

gcloud compute health-checks create http http-hc --port 80

Configura servizi di backend

Utilizza il comando gcloud compute backend-services create per creare il servizio di backend. Una volta creati i servizi di backend, aggiungeremo i gruppi di istanze non gestite ai servizi di backend utilizzando il comando gcloud compute backend-services add-backend. Esegui questi comandi in Cloud Shell.

Crea servizio di backend

Comandi

gcloud compute backend-services create $REGION_1-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_1

gcloud compute backend-services create $REGION_2-backend-service \
--load-balancing-scheme=INTERNAL --protocol=TCP \
--health-checks=http-hc --region=$REGION_2

Aggiungi backend

Comando

gcloud compute backend-services add-backend $REGION_1-backend-service \
--instance-group=$REGION_1-instance-group \
--region=$REGION_1 \
--instance-group-zone=$REGION_1_ZONE

gcloud compute backend-services add-backend $REGION_2-backend-service \
--instance-group=$REGION_2-instance-group \
--region=$REGION_2 \
--instance-group-zone=$REGION_2_ZONE

Creare regole di forwarding

Utilizza il comando gcloud compute forwarding-rules create per creare le regole di forwarding in entrambe le regioni. Esegui questi comandi in Cloud Shell

Regola di forwarding REGION_1

Comandi

gcloud compute forwarding-rules create $REGION_1-ilb \
    --region=$REGION_1 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_1-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_1-backend-service \
    --backend-service-region=$REGION_1 \
    --allow-global-access

Regola di forwarding REGION_2

gcloud compute forwarding-rules create $REGION_2-ilb \
    --region=$REGION_2 \
    --load-balancing-scheme=internal \
    --network=my-vpc \
    --subnet=$REGION_2-subnet \
    --ip-protocol=TCP \
    --ports=80 \
    --backend-service=$REGION_2-backend-service \
    --backend-service-region=$REGION_2 \
    --allow-global-access

9. Configura il DNS

In questa sezione creeremo la zona privata e un set di record DNS con la policy di routing di failover.

Crea una zona DNS privata

Utilizza il comando gcloud dns managed-zones create per creare una zona privata per example.com. Utilizzeremo questa zona per creare un set di record di risorse con policy di routing di failover. Esegui questo comando in Cloud Shell:

Comandi

gcloud dns managed-zones create example-com \
--dns-name example.com. --description="My private zone" \
--visibility=private --networks my-vpc 

Crea un record DNS con policy di routing di failover

Utilizza il comando gcloud dns record-sets create per creare un record DNS con la policy di routing di failover. La destinazione principale è il bilanciatore del carico in REGION_1. Cloud DNS supporta solo target di backup basati su dati geografici. Il set di backup è una policy di geolocalizzazione con il bilanciatore del carico REGION_2 come target sia per REGION_1 sia per REGION_2. Esegui questi comandi in Cloud Shell

Comando

gcloud dns record-sets create failover.example.com --ttl 5 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com \
--enable-health-checking

Esempio di output

NAME: failover.example.com.
TYPE: A
TTL: 5
DATA: Primary: "10.1.0.4, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-west1, regionalL4ilb" Backup: us-west1: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb";us-east4: "10.2.0.3, 80, tcp, https://www.googleapis.com/compute/v1/projects/my-clouddns-codelab/global/networks/my-vpc, my-clouddns-codelab, us-east4, regionalL4ilb"

10. Testare la risoluzione DNS

Prima di testare la configurazione di failover, annota gli indirizzi IP di entrambi i bilanciatori del carico interni. Esegui questi comandi in Cloud Shell.

Comando

gcloud compute forwarding-rules list --filter="name:($REGION_1-ilb $REGION_2-ilb)"

Esempio di output

In questo esempio, us-west1-ilb ha un indirizzo IP 10.1.0.4 e us-east4-ilb ha un indirizzo IP 10.2.0.3

NAME: us-west1-ilb
REGION: us-west1
IP_ADDRESS: 10.1.0.4
IP_PROTOCOL: TCP
TARGET: us-west1/backendServices/us-west1-backend-service

NAME: us-east4-ilb
REGION: us-east4
IP_ADDRESS: 10.2.0.3
IP_PROTOCOL: TCP
TARGET: us-east4/backendServices/us-east4-backend-service

Ora accediamo all'istanza client e testiamo la risoluzione DNS. Nella console web, vai a "Compute Engine | Istanze VM".

Fai clic sul pulsante SSH per accedere a client-instance dalla console.

Ora che ci troviamo nella VM client, utilizza il comando dig per risolvere il nome di dominio failover.example.com.

Il ciclo è configurato per eseguire il comando dieci volte con un timer di sospensione di 6 secondi.

Comando

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Poiché il TTL del record DNS è impostato su 5 secondi, è stato aggiunto un timer di sospensione di 6 secondi. Il timer di sospensione assicura di ricevere una risposta DNS non memorizzata nella cache per ogni richiesta DNS. L'esecuzione di questo comando richiede circa un minuto.

Nell'output vedrai l'indirizzo IP del bilanciatore del carico nel set principale del record di risorse. Nella nostra configurazione, questo sarà l'IP del bilanciatore del carico nella regione us-west1.

11. Testa il failover

Simuleremo un failover rimuovendo il tag di rete dalla VM REGION_1. In questo modo, l'accesso alla porta 80 verrà bloccato e, di conseguenza, i controlli di integrità inizieranno a non riuscire.

Rimuovere il tag di rete

Utilizza il comando gcloud compute instances remove-tags per rimuovere il tag di rete dalla VM. Esegui questo comando in Cloud Shell:

Comando

gcloud compute instances remove-tags $REGION_1-instance \
--zone=$REGION_1_ZONE --tags=allow-http

Il controllo di integrità avrà esito negativo tra 10 secondi. Esegui di nuovo il test di risoluzione DNS.

Risoluzione DNS

Dall'istanza client, esegui questo comando

Comando

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

Nell'output vedrai l'indirizzo IP del bilanciatore del carico nel set di backup del record di risorse. Nella nostra configurazione, questo sarà l'IP del bilanciatore del carico nella regione us-east4.

12. Testare il traffico incrementale

Per impostazione predefinita, la policy di failover restituisce l'IP dell'endpoint primario per tutte le richieste DNS e restituisce gli IP di backup solo se il primario non supera i controlli di integrità. Cloud DNS consente agli utenti di configurare il rapporto di distribuzione graduale, che consente a Cloud DNS di inviare una parte del traffico ai target di backup, anche quando i target principali sono integri. Il rapporto deve essere un valore compreso tra 0 e 1. Il valore predefinito è 0

Per testare questa funzionalità, aggiungiamo di nuovo il tag di rete al server web REGION_1.

Aggiungi tag di rete

Aggiungi di nuovo il tag alla VM del server web per consentire il traffico HTTP alla VM della regione primaria. Esegui questo comando in Cloud Shell.

Comando

gcloud compute instances add-tags $REGION_1-instance \
--zone $REGION_1_ZONE --tags allow-http

I controlli di integrità verranno superati in 10 secondi

Verifica che la risoluzione DNS punti al bilanciatore del carico principale. Nella nostra configurazione, questo sarà l'indirizzo IP del bilanciatore del carico nella regione us-west1.

Dall'istanza client, esegui questo comando

Comando

dig +short failover.example.com

Aggiorna il record DNS

Ora modificheremo il record DNS per failover.example.com in modo da inviare il 30% del traffico al set di backup anche quando l'istanza principale è integra. Esegui questo comando in Cloud Shell:

Comando

gcloud dns record-sets update failover.example.com --ttl 30 --type A \
--routing-policy-type=FAILOVER \
--routing-policy-primary-data=$REGION_1-ilb \
--routing-policy-backup-data="${REGION_1}=${REGION_2}-ilb;${REGION_2}=${REGION_2}-ilb" \
--routing-policy-backup-data-type=GEO \
--zone=example-com --enable-health-checking \
--backup-data-trickle-ratio=0.3

Risoluzione DNS

Esegui questo comando dalla VM client. Noterai che il record DNS failover.example.com verrà risolto nell'IP del bilanciatore del carico principale circa il 70% delle volte e nell'IP del bilanciatore del carico di backup circa il 30% delle volte.

for i in {1..10}; do echo $i; dig failover.example.com +short; sleep 6; done

13. Procedura di pulizia

Per pulire le risorse utilizzate in questo lab, esegui questi comandi da Cloud Shell

gcloud dns record-sets delete failover.example.com --type=A \
--zone=example-com --quiet

gcloud dns managed-zones delete example-com --quiet

gcloud compute forwarding-rules delete $REGION_1-ilb \
--region=$REGION_1 --quiet

gcloud compute forwarding-rules delete $REGION_2-ilb \
--region=$REGION_2 --quiet

gcloud compute backend-services delete $REGION_1-backend-service \
--region=$REGION_1 --quiet

gcloud compute backend-services delete $REGION_2-backend-service \
--region=$REGION_2 --quiet

gcloud compute health-checks delete http-hc --quiet

gcloud compute instances delete client-instance --zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_1-instance-group \
--zone=$REGION_1_ZONE --quiet

gcloud compute instance-groups unmanaged delete $REGION_2-instance-group \
--zone=$REGION_2_ZONE --quiet

gcloud compute instances delete $REGION_1-instance \
--zone=$REGION_1_ZONE --quiet

gcloud compute instances delete $REGION_2-instance \
--zone=$REGION_2_ZONE --quiet

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

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

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

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

gcloud compute firewall-rules delete allow-ssh allow-http-lb-hc --quiet

gcloud compute networks subnets delete $REGION_1-subnet \
--region=$REGION_1 --quiet

gcloud compute networks subnets delete $REGION_2-subnet \
--region=$REGION_2 --quiet

gcloud compute networks delete my-vpc --quiet

14. Complimenti

Congratulazioni, hai eseguito il deployment e il test della policy di routing di failover di Cloud DNS

Argomenti trattati

• Come configurare la policy di routing di failover di Cloud DNS
• Testa il failover DNS
• Come distribuire gradualmente il traffico al set di backup

Passaggi successivi

• Prova a configurare più indirizzi IP per i set attivi e di backup
• Prova ad aggiungere più VM di backend ai gruppi di istanze non gestite
• Prova a configurare più bilanciatori del carico in regioni diverse per il criterio di geolocalizzazione nel set di backup.

Scopri di più

https://cloud.google.com/dns/docs/zones/manage-routing-policies