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: 2022-09-22

Che cos'è un criterio di routing DNS

I criteri di routing di Cloud DNS consentono agli utenti di configurare il reindirizzamento del traffico basato su DNS in base a criteri specifici come peso, geolocalizzazione o controlli di integrità.

Cloud DNS supporta i seguenti criteri di routing:

• Criterio di routing Round Robin ponderato
• Criterio di routing della geolocalizzazione
• Criterio di routing in geofencing
• Criterio di routing del failover

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

Nota:alla data di stesura di questo lab, sia i criteri di failover sia il supporto per i controlli di integrità sono in anteprima pubblica.

Criterio di routing del failover

Cloud DNS supporta i controlli di integrità per i bilanciatori del carico TCP/UDP interni in cui è abilitato l'accesso globale. Con un criterio di routing di failover puoi configurare indirizzi IP principali 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 hanno esito negativo (lo stato di integrità diventa non integro), Cloud DNS inizia a gestire 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 gli bilanciatore del carico interno con accesso globale disabilitato, ma il failover di Cloud DNS non funzionerà.

Controlli di integrità

Il criterio di routing del DNS dipenderà 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, UHC fornisce lo stato di integrità di tutti i proxy Envoy, ma per un bilanciatore del carico TCP/UDP interno, Cloud DNS riceve indicatori 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 a cui assocerai un criterio di routing DNS di failover. La configurazione prevede:

Risorse attive -

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

Risorse di backup -

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

La procedura di configurazione è quella illustrata di seguito:

Nota: per semplificare questo codelab, avremo un singolo bilanciatore del carico in ciascuna delle regioni configurate come set attivo e di backup del criterio di routing di failover.

Cosa imparerai a fare

• Creare un criterio di routing di failover
• Attiva failover DNS
• Come trasferire 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 progetto è il nome visualizzato dei partecipanti del progetto. Si tratta di una stringa di caratteri non utilizzata dalle API di Google. Puoi aggiornarla 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 importa cosa sia. Nella maggior parte dei codelab, dovrai fare riferimento all'ID progetto (in genere è identificato come PROJECT_ID). Se l'ID generato non ti soddisfa, puoi generarne un altro casuale. In alternativa, puoi provarne una personalizzata per verificare se è disponibile. Non può essere modificato dopo questo passaggio e rimarrà per tutta la durata del progetto.
• Per informazione, c'è 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 nessun altro utente dopo essere stato selezionato. Sei l'unico utente di quell'ID. Anche se un progetto viene eliminato, l'ID non può più essere riutilizzato

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

2. Successivamente, dovrai abilitare la fatturazione nella console Cloud per utilizzare risorse/API Cloud. Eseguire questo codelab non dovrebbe costare molto. Per arrestare le risorse in modo da non incorrere in fatturazione oltre questo tutorial, puoi eliminare le risorse che hai creato o eliminare l'intero progetto. I nuovi utenti di Google Cloud sono idonei al programma prova senza costi di 300$.

Avvia Cloud Shell

Anche se Google Cloud può essere utilizzato da remoto dal tuo laptop, in questo codelab utilizzerai Google Cloud Shell, un ambiente a riga di comando in esecuzione nel cloud.

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

Dovrebbe richiedere solo qualche istante per eseguire il provisioning e connettersi all'ambiente. Al termine, dovresti vedere una schermata simile al seguente:

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

3. Versione Google Cloud SDK

Al momento della scrittura, 401.0.0 è la versione più recente dell'SDK Google Cloud. Tutti i comandi in questo lab sono stati testati utilizzando l'ultima versione di Google Cloud SDK. Prima di procedere, assicurati che Cloud Shell stia utilizzando la versione più recente dell'SDK.

Controllare la versione dell'SDK

Utilizza il comando gcloud version per verificare 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 successiva, vai alla sezione successiva.
2. Se la versione dell'SDK è precedente a 401.0.0, esegui il comando indicato di seguito per aggiornare l'SDK.

Comando facoltativo

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

4. Prima di iniziare

Prima di iniziare a eseguire il deployment dell'architettura descritta in precedenza, assicurati che Cloud Shell sia configurato correttamente e che tutte le API richieste siano abilitate.

Configura ID progetto

All'interno di Cloud Shell, assicurati che l'ID progetto sia configurato. Se il prompt di Cloud Shell è simile all'output seguente e non prevedi di modificare l'ID progetto, puoi andare al passaggio successivo (Imposta 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)

Comando facoltativo

gcloud config set project [YOUR-PROJECT-ID]

Esempio di output

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

Impostare le variabili di ambiente

Impostare 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 vengono utilizzate le regioni us-west1 e us-east4. La capacità di calcolo può essere limitata in una zona. Se riscontri errori di capacità durante la creazione delle VM, utilizza una regione o una zona diversa. Un elenco delle regioni e delle zone disponibili è disponibile qui.

Verifica

Ora che le variabili di ambiente sono impostate, eseguiamo la verifica utilizzando il comando echo. L'output di ogni comando deve corrispondere al valore 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

Abilita 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, verifica 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 regole firewall, subnet e rete VPC

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

Crea rete VPC

Utilizza il comando gcloud compute networks create per creare la rete VPC. Stiamo impostando la modalità subnet come personalizzata perché nel passaggio successivo creeremo le nostre subnet. 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.

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

Consenti il 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 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

Affinché le VM private possano scaricare e installare i pacchetti da internet, sono necessari gateway Cloud NAT in entrambe le regioni.

• Le VM del nostro 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. Quindi, prima di creare i gateway NAT, dobbiamo creare 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 regione_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 regione_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 regione_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. Creazione di VM di 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 vengono utilizzate le regioni us-west1 e us-east4. La capacità di calcolo può essere limitata in una zona. Se riscontri errori di capacità durante la creazione delle VM, utilizza una regione o una zona diversa. Un elenco delle regioni e delle zone disponibili è disponibile qui.

Creare VM del 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 creeremo due gruppi di istanze non gestite. Utilizzeremo questi gruppi di istanze nella sezione successiva per configurare i servizi di backend del bilanciatore 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

Usa 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 regione_1

Comandi

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

Gruppo di istanze regione_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 appena creati. 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 regione_1

Comandi

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

Gruppo di istanze regione_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 configurazione DNS. Stiamo utilizzando 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 L4, 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 80. Esegui questi comandi in Cloud Shell

Comando

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

Configura i 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 un 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 DNS

In questa sezione creeremo la zona privata e un record DNS impostato con il criterio 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 un criterio 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 un criterio di routing di failover

Usa il comando gcloud dns record-sets create per creare un record DNS con il criterio di routing di failover. Il target principale è il bilanciatore del carico in REGION_1. Cloud DNS supporta solo target di backup basati su dati geografici, il set di backup è un criterio di geolocalizzazione con bilanciatore del carico REGION_2 come destinazione sia per REGION_1 che 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. Testa la risoluzione DNS

Prima di testare la configurazione del failover, prendiamo nota degli 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 accederai all'istanza client e testeremo la risoluzione DNS. Nella console web, vai a "Compute Engine | "Istanze VM"

Fai clic sul pulsante SSH per accedere all'istanza client dalla console.

Ora che siamo nella VM client, usa il comando dig per risolvere il nome di dominio failover.example.com.

Il loop è 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 nel record DNS è impostato su 5 secondi, è stato aggiunto un timer di sospensione di 6 secondi. Il timer di sospensione garantisce che tu riceva una risposta DNS non memorizzata nella cache per ogni richiesta DNS. L'esecuzione di questo comando richiederà 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 failover

Simuleremo un failover rimuovendo il tag di rete dalla VM REGION_1. Questa operazione bloccherà l'accesso alla porta 80 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. Testa traffico scorrevole

Per impostazione predefinita, il criterio di failover restituisce l'IP dell'endpoint principale per tutte le richieste DNS e restituisce gli IP di backup solo se quello principale non supera i controlli di integrità. Cloud DNS consente agli utenti di configurare Trickle Ratio che permette a Cloud DNS di inviare una parte del traffico alle destinazioni di backup, anche quando le destinazioni primarie sono integre. La razione deve essere un valore compreso tra 0 e 1. Il valore predefinito è 0

Per verificarlo, aggiungi di nuovo il tag di rete al server web REGION_1.

Aggiungi tag di rete

Aggiungi di nuovo il tag alla VM server web per consentire il traffico http verso la VM della regione principale. 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 tra 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

Aggiornare il record DNS

Ora modificheremo il record DNS per failover.example.com in modo da trasferire il 30% del traffico al set di backup anche quando quello principale è integro. 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 all'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. Passaggi per la pulizia

Per eseguire la pulizia delle risorse utilizzate in questo lab, esegui questi comandi da CloudShell

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

Complimenti, hai eseguito il deployment e testato il criterio di routing di failover di Cloud DNS

Argomenti trattati

• Come configurare il criterio di routing di failover di Cloud DNS
• Testa il failover DNS
• Come trasferire il traffico al set di backup

Passaggi successivi

• Prova a configurare più IP per i set attivi e di backup
• Prova ad aggiungere più VM di backend ai tuoi 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