Failover per i bilanciatori del carico delle applicazioni esterni

Questa pagina descrive il funzionamento del failover per i bilanciatori del carico delle applicazioni esterni. La configurazione del failover prevede due bilanciatori del carico: uno principale e uno di riserva. Ai fini di questa discussione, il bilanciatore del carico principale è il bilanciatore del carico per cui vuoi configurare il failover. Il bilanciatore del carico di backup è il bilanciatore del carico che riceve le connessioni quando il bilanciatore del carico principale inizia a non superare i controlli di integrità.

Il failover e il failback sono i processi automatici che indirizzano il traffico verso e da un bilanciatore del carico. Quando Cloud DNS rileva un'interruzione e instrada il traffico dal bilanciatore del carico principale a quello di riserva, il processo è noto come failover. Quando Cloud DNS esegue l'operazione inversa e reindirizza il traffico al bilanciatore del carico principale, il processo è noto come failback.

Come funziona il failover

Il failover da globale a regionale per i bilanciatori del carico delle applicazioni esterni viene gestito creando due o più bilanciatori del carico delle applicazioni esterni regionali nelle regioni in cui vuoi eseguire il failover del traffico. Solo i bilanciatori del carico delle applicazioni esterni regionali possono essere utilizzati come bilanciatori del carico di riserva. I bilanciatori del carico delle applicazioni esterni a livello di regione non sono solo autosufficienti all'interno delle singole regioni Google Cloud, ma sono anche isolati da qualsiasi bilanciatore del carico delle applicazioni esterno globale o dall'infrastruttura del bilanciatore del carico delle applicazioni classico in esecuzione nella stessa regione.

I bilanciatori del carico delle applicazioni esterni regionali funzionano al meglio come bilanciatori del carico di failover per i bilanciatori del carico delle applicazioni esterni globali perché entrambi si basano su proxy Envoy e trattano il traffico in modi molto simili. Ciò è in contrasto con un bilanciatore del carico delle applicazioni classico, che presenta notevoli differenze nella modalità di gestione del traffico.

In sintesi, sono supportati i seguenti scenari di failover:

• Da un bilanciatore del carico delle applicazioni esterno globale a un bilanciatore del carico delle applicazioni esterno regionale
• Da un bilanciatore del carico delle applicazioni esterno regionale a un altro bilanciatore del carico delle applicazioni esterno regionale
• Da un bilanciatore del carico delle applicazioni classico a un bilanciatore del carico delle applicazioni esterno regionale

Flusso di lavoro di failover e failback

La seguente configurazione mostra il failover da un bilanciatore del carico delle applicazioni esterno globale a due bilanciatori del carico delle applicazioni esterni regionali, uno in ogni regione in cui il bilanciatore del carico globale ha implementato i backend.

Le sezioni seguenti descrivono un flusso di lavoro tipico con i diversi componenti coinvolti in una configurazione di failover.

1. Rileva gli errori nel bilanciatore del carico principale

   Google Cloud utilizza i controlli di integrità per rilevare se il bilanciatore del carico delle applicazioni esterno principale è in stato di esecuzione. Configura questi controlli di integrità in modo da inviare probe da tre regioni di origine. Queste tre regioni di origine devono essere rappresentative delle regioni da cui i tuoi clienti accederanno al bilanciatore del carico. Ad esempio, se hai un bilanciatore del carico delle applicazioni esterno globale e la maggior parte del traffico dei clienti proviene dal Nord America e dall'Europa, puoi configurare i controlli provenienti da due regioni del Nord America e da una regione in Europa.

   Se i controlli di integrità provenienti da due o più di queste regioni non vanno a buon fine, viene attivato il failover all'Application Load Balancer esterno regionale di backup.

   Note aggiuntive:

   • Devi specificare esattamente tre regioni di origine quando crei il controllo di integrità. Solo i controlli di integrità globali possono specificare le regioni di origine.
   • Sono supportati i controlli di integrità HTTP, HTTPS e TCP.
   • I controlli di integrità provengono in realtà da un punto di presenza (PoP) su internet a breve distanza dalla regione di origine Google Cloud configurata.

2. Instradare il traffico ai bilanciatori del carico di riserva

   Se il bilanciatore del carico principale inizia a non superare i controlli di integrità, Google Cloud utilizza i criteri di routing di failover di Cloud DNS per determinare come instradare il traffico ai bilanciatori del carico di riserva.

   La durata dell'interruzione o il tempo necessario per il failover del traffico dal bilanciatore del carico principale a quello di riserva è determinata dal valore TTL DNS, dall'intervallo del controllo di integrità e dalla soglia di stato non integro del controllo di integrità. Per le impostazioni consigliate, consulta Best practice.

3. Ripristino del failover al bilanciatore del carico principale

   Quando i controlli di integrità iniziano a superare di nuovo, il failover al bilanciatore del carico principale è automatico. Non sono previsti tempi di inattività durante il failback perché i bilanciatori del carico di riserva e principali gestiscono il traffico.

4. Esegui periodicamente il test del failover

   Ti consigliamo di testare periodicamente il flusso di lavoro di failover nell'ambito del tuo piano di continuità aziendale. Assicurati di testare sia i cambiamenti graduali sia quelli istantanei del traffico dai bilanciatori del carico principali a quelli di backup. Dopo aver verificato che il failover funzioni, attiva un failback per verificare che il traffico venga reindirizzato al bilanciatore del carico principale come previsto.

Configurazione del failover

Per configurare il failover, svolgi i seguenti passaggi:

1. Esamina la configurazione del bilanciatore del carico principale esistente e controlla che le funzionalità (ad esempio le funzionalità di sicurezza, di gestione e instradamento del traffico e le CDN) utilizzate dal bilanciatore del carico principale siano disponibili con il bilanciatore del carico delle applicazioni esterno regionale di riserva. Se funzionalità simili non sono disponibili, questo bilanciatore del carico potrebbe non essere una buona scelta per il failover.
2. Crea il bilanciatore del carico delle applicazioni esterno regionale di backup con una configurazione che rispecchi il più possibile il bilanciatore del carico principale.
3. Crea il controllo di integrità e il criterio di routing DNS per rilevare le interruzioni e instradare il traffico dal bilanciatore del carico principale a quello di backup durante il failover.

Esamina la configurazione del bilanciatore del carico principale

Prima di iniziare, verifica che il bilanciatore del carico delle applicazioni esterno regionale di riserva supporti tutte le funzionalità attualmente utilizzate con il bilanciatore del carico principale.

Per evitare interruzioni del traffico, esamina le seguenti differenze:

• Deployment GKE. Gli utenti di GKE devono tenere presente che i bilanciatori del carico di cui è stato eseguito il deployment utilizzando GKE Gateway sono più compatibili con questo meccanismo di failover rispetto ai bilanciatori del carico di cui è stato eseguito il deployment utilizzando il controller GKE Ingress. Questo perché GKE Gateway supporta la configurazione sia dei bilanciatori del carico delle applicazioni esterni globali sia di quelli regionali. Tuttavia, il controller Ingress di GKE supporta solo l'Application Load Balancer classico.

  Per ottenere risultati ottimali, utilizza GKE Gateway per eseguire il deployment sia dei bilanciatori del carico principali sia di quelli di riserva.

• Cloud CDN. I bilanciatori del carico delle applicazioni esterni regionali non supportano Cloud CDN. Pertanto, in caso di guasto, sono interessate anche le operazioni che si basano su Cloud CDN. Per una maggiore ridondanza, ti consigliamo di configurare una soluzione CDN di terze parti che possa fungere da alternativa a Cloud CDN.

• Google Cloud Armor. Se utilizzi Google Cloud Armor per il bilanciatore del carico principale, assicurati di configurare le stesse funzionalità di Google Cloud Armor anche quando configuri il bilanciatore del carico delle applicazioni esterno regionale di riserva. Google Cloud Armor offre funzionalità diverse nel contesto regionale rispetto a quello globale. Per ulteriori informazioni, consulta le seguenti sezioni della documentazione di Google Cloud Armor:

  • Criteri di sicurezza di Google Cloud Armor a livello di regione
  • Criteri di sicurezza globali di Google Cloud Armor

• Certificati SSL. Se vuoi utilizzare un certificato SSL comune sia per il bilanciatore del carico principale sia per quello di riserva, verifica che il tipo di certificato SSL utilizzato con il bilanciatore del carico principale sia compatibile con il bilanciatore del carico delle applicazioni esterno regionale di riserva. Esamina le differenze tra i certificati SSL disponibili con i bilanciatori del carico globali, regionali e classici. Per maggiori dettagli, consulta le sezioni seguenti:

  • Certificati SSL di Compute Engine
  • Certificati SSL di Certificate Manager

• Bucket di backend. I bilanciatori del carico delle applicazioni esterni regionali non supportano i bucket Cloud Storage come backend. Non puoi configurare il failover per i bilanciatori del carico utilizzando i bucket di backend.

Configura il bilanciatore del carico di riserva

Il bilanciatore del carico di riserva è un bilanciatore del carico delle applicazioni esterno regionale che configuri nella regione in cui vuoi che il traffico venga reindirizzato in caso di errore.

Tieni presenti le seguenti considerazioni durante la configurazione del bilanciatore del carico di riserva:

• Devi configurare le funzionalità del bilanciatore del carico delle applicazioni esterno regionale di backup in modo che siano il più possibile simili a quelle del bilanciatore del carico principale, in modo che il traffico venga elaborato in modo simile in entrambi i deployment.

  • Bilanciatore del carico delle applicazioni esterno globale. I bilanciatori del carico delle applicazioni esterni regionali supportano la maggior parte delle funzionalità dei bilanciatori del carico delle applicazioni esterni globali, con poche eccezioni. Il bilanciatore del carico a livello di regione supporta anche le stesse funzionalità avanzate di gestione del traffico del bilanciatore del carico globale, il che semplifica il raggiungimento dell'equivalenza tra i bilanciatori del carico principali e di riserva.

  • Bilanciatore del carico delle applicazioni classico. Con l'Application Load Balancer classico, la parità di funzionalità tra il bilanciatore del carico principale e quello di riserva è più difficile da ottenere perché l'Application Load Balancer esterno regionale è un bilanciatore del carico basato su Envoy che elabora il traffico in modo diverso. Assicurati di testare accuratamente il failover e il failback prima di eseguire il deployment in produzione.

  Per visualizzare le funzionalità specifiche dei bilanciatori del carico delle applicazioni regionali, globali e classici, consulta la pagina Confronto delle funzionalità dei bilanciatori del carico.

  Ti consigliamo di utilizzare un framework di automazione come Terraform per contribuire a ottenere e mantenere la coerenza delle configurazioni dei bilanciatori del carico nei deployment principali e di backup.

• Ti consigliamo di configurare bilanciatori del carico delle applicazioni esterni regionali di riserva in ogni regione in cui hai backend. Ad esempio, se esegui il failover da un deployment globale con gruppi di istanze in cinque regioni a bilanciatori del carico regionali di backup solo in tre regioni, rischi di sovraccaricare i servizi di backend in queste tre regioni mentre i servizi di backend nelle due regioni rimanenti sono inattivi.

  Inoltre, ti consigliamo di configurare Cloud DNS in modo da utilizzare i criteri di round robin ponderato quando reindirizzi il traffico di failover da un bilanciatore del carico globale principale a questi bilanciatori del carico regionali di riserva. Assegna pesi a ogni bilanciatore del carico di backup tenendo conto delle dimensioni massime dei gruppi di istanza di backend in regioni diverse.

• I bilanciatori del carico delle applicazioni esterni regionali supportano sia il livello Premium che Standard di Network Service Tiers. Se la latenza non è la tua principale preoccupazione durante il failover, ti consigliamo di configurare i bilanciatori del carico delle applicazioni esterni regionali di riserva utilizzando il livello Standard. L'utilizzo dell'infrastruttura di livello Standard offre un'ulteriore isolamento rispetto all'infrastruttura di livello Premium utilizzata dagli Application Load Balancer esterni globali.

• Se vuoi utilizzare gli stessi backend sia per il bilanciatore del carico principale sia per quello di backup, crea il bilanciatore del carico delle applicazioni esterno regionale di backup nella regione in cui si trovano i backend. Se hai attivato la scalabilità automatica per i gruppi di istanze di backend, devi soddisfare i requisiti per la condivisione dei backend nei vari implementazioni.

• Se necessario, riserva proxy Envoy aggiuntivi per i bilanciatori del carico delle applicazioni esterni regionali per contribuire a garantire che, in caso di evento di failover, il traffico aggiuntivo non interrompa gli altri implementazioni di bilanciatori del carico nella stessa regione. Per maggiori dettagli, consulta Prenotare capacità aggiuntiva per le subnet solo proxy.

Per scoprire come configurare un bilanciatore del carico delle applicazioni esterno regionale, consulta Configurare un bilanciatore del carico delle applicazioni esterno regionale con backend di gruppi di istanze VM.

Riservare capacità aggiuntiva per le subnet solo proxy

Tutti i bilanciatori del carico basati su Envoy a livello di regione in una regione e nella rete VPC condividono lo stesso pool di proxy Envoy. In caso di failover, i bilanciatori del carico delle applicazioni esterni regionali di riserva registrano un aumento dell'utilizzo del proxy per gestire il traffico di failover dal bilanciatore del carico principale. Per assicurarti che la capacità sia sempre disponibile per i bilanciatori del carico di riserva, ti consigliamo di esaminare le dimensioni della subnet solo proxy. Ti consigliamo di calcolare il numero stimato di proxy necessari per gestire il traffico in una determinata regione e di aumentare la capacità, se necessario. Ciò contribuisce inoltre a garantire che gli eventi di failover non interrompano altri bilanciatori del carico basati su Envoy a livello di regione nella stessa regione e nella stessa rete.

In genere, un proxy del bilanciatore del carico delle applicazioni esterno regionale può gestire fino a:

• 600 (HTTP) o 150 (HTTPS) nuove connessioni al secondo
• 3000 connessioni attive
• 1400 richieste al secondo

Se utilizzi i criteri DNS per suddividere il traffico su più bilanciatori di carico di backup in regioni diverse, devi tenerne conto quando stimi i requisiti dei proxy per regione e rete. Una subnet solo proxy più grande consente a Google Cloud di assegnare un numero maggiore di proxy Envoy al bilanciatore del carico quando necessario.

Non puoi espandere una subnet solo proxy nello stesso modo in cui faresti per un intervallo di indirizzi principale (con il comando expand-ip-range). Devi invece creare una subnet solo proxy di backup che soddisfi le tue esigenze e poi promuoverla al ruolo attivo.

Per scoprire come modificare le dimensioni della subnet solo proxy, consulta Modificare le dimensioni o l'intervallo di indirizzi di una subnet solo proxy.

Condivisione dei backend tra bilanciatori del carico principali e di backup

Per ottenere una ridondanza infrastrutturale completa, devi introdurre la ridondanza sia a livello di bilanciatore del carico sia a livello di backend. Ciò significa che devi configurare i bilanciatori del carico delle applicazioni esterni di riserva a livello di regione con backend (gruppi di istanze o gruppi di endpoint di rete) che non si sovrappongono ai bilanciatori del carico principali.

Tuttavia, se vuoi condividere un gruppo di istanza di backend tra i bilanciatori del carico principali e secondari e la scalabilità automatica è abilitata per i gruppi di istanze, devi soddisfare i seguenti requisiti per contribuire a garantire un corretto funzionamento del failover:

• Il gestore della scalabilità automatica deve essere configurato solo con il ridimensionamento basato sulla CPU. Il metodo di scalabilità in base all'utilizzo del bilanciatore del carico non è supportato.
• Sia i servizi di backend globali sia quelli regionali devono utilizzare solo la modalità di bilanciamento UTILIZATION. L'utilizzo della modalità di bilanciamento RATE non è consigliato perché le istanze potrebbero ricevere il doppio del traffico dai bilanciatori del carico sia globali che regionali durante il processo di failover.
• I controlli di scalabilità verso il basso devono essere configurati per impedire al gestore della scalabilità automatica di eseguire prematuramente la scalabilità verso il basso del gruppo durante il tempo di riposo quando il traffico passa dal bilanciatore del carico globale a quello regionale. Questo tempo di riposo può essere pari alla somma del TTL DNS più l'intervallo di controllo di integrità configurato.

La mancata configurazione corretta della scalabilità automatica può comportare un'interruzione secondaria durante il failover perché la perdita di traffico dal bilanciatore del carico globale comporta un rapido calo del gruppo di istanze.

Configura Cloud DNS e i controlli di integrità

Questa sezione descrive come utilizzare Cloud DNS e i controlli di integrità di Google Cloud per configurare l'ambiente di Cloud Load Balancing in modo da rilevare gli arresti anomali e instradare il traffico ai bilanciatori del carico di riserva.

Per configurare i criteri di routing e controllo di integrità richiesti:

1. Crea un controllo di integrità per l'indirizzo IP della regola di forwarding del bilanciatore del carico principale.

   gcloud beta compute health-checks create http HEALTH_CHECK_NAME \
       --global \
       --source-regions=SOURCE_REGION_1,SOURCE_REGION_2,SOURCE_REGION_3 \
       --use-serving-port \
       --check-interval=HEALTH_CHECK_INTERVAL \
       --healthy-threshold=HEALTHY_THRESHOLD \
       --unhealthy-threshold=UNHEALTHY_THRESHOLD \
       --request-path=REQUEST_PATH
   

   Sostituisci quanto segue:

   • HEALTH_CHECK_NAME: il nome del controllo di integrità
   • SOURCE_REGION: le tre regioni Google Cloud da cui vengono eseguiti i controlli di stato. Devi specificare esattamente tre regioni di origine.
   • HEALTH_CHECK_INTERVAL: il tempo in secondi dall'inizio di un probe emesso da un prober all'inizio del probe successivo emesso dallo stesso prober. Il valore minimo supportato è 30 secondi. Per i valori consigliati, consulta le best practice.
   • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: il numero di verifiche sequenziali che devono essere riuscite o non riuscite affinché l'istanza VM sia considerata in stato di integrità o non integrità. Se uno dei due valori viene omesso, Google Cloud utilizza una soglia predefinita di 2.
   • REQUEST_PATH: il percorso dell'URL a cui Google Cloud invia richieste di sonde di controllo di integrità dell'integrità. Se omesso, Google Cloud invia richieste di controllo al percorso principale, /. Se gli endpoint sottoposti a controllo di stato sono privati, il che non è tipico per gli indirizzi IP regola di forwarding esterne, puoi impostare questo percorso su /afhealthz.

2. Crea un insieme di record Cloud DNS in Cloud DNS e applica un criterio di routing. Il criterio di routing deve essere configurato in modo da risolvere il nome di dominio nell'indirizzo IP della regola di forwarding del bilanciatore del carico principale o, in caso di errore del controllo di integrità, in uno degli indirizzi IP della regola di forwarding di inoltro dei bilanciatori del carico di riserva.

   gcloud beta dns record-sets create DNS_RECORD_SET_NAME \
       --ttl=TIME_TO_LIVE \
       --type=RECORD_TYPE \
       --zone="MANAGED_ZONE_NAME" \
       --routing-policy-type=FAILOVER \
       --routing-policy-primary-data=PRIMARY_LOAD_BALANCER_FORWARDING_RULE \
       --routing-policy-backup-data_type=GEO \
       --routing-policy-backup-data="BACKUP_REGION_1=BACKUP_LOAD_BALANCER_1_IP_ADDRESS[;BACKUP_REGION_2=BACKUP_LOAD_BALANCER_2_IP_ADDRESS;BACKUP_REGION_3=BACKUP_LOAD_BALANCER_3_IP_ADDRESS]" \
       --health-check=HEALTH_CHECK_NAME \
       --backup-data-trickle-ratio=BACKUP_DATA_TRICKLE_RATIO
   

   Sostituisci quanto segue:

   • DNS_RECORD_SET_NAME: il nome DNS o di dominio del record impostato per l'aggiunta, ad esempio test.example.com
   • TIME_TO_LIVE: il valore durata (TTL) per il record impostato in numero di secondi. Per i valori consigliati, consulta le best practice.
   • RECORD_TYPE: il tipo di record, ad esempio A
   • MANAGED_ZONE_NAME: il nome della zona gestita di cui vuoi gestire i set di record, ad esempio my-zone-name
   • PRIMARY_LOAD_BALANCER_FORWARDING_RULE: il nome della regola di forwarding del bilanciatore del carico principale
   • BACKUP_REGION: le regioni in cui sono di cui è stato eseguito il deployment dei bilanciatori del carico di riserva
   • BACKUP_LOAD_BALANCER_IP_ADDRESS: la regola di forwarding Indirizzi IP dei bilanciatori del carico di riserva corrispondenti a ogni regione
   • BACKUP_DATA_TRICKLE_RATIO: il rapporto tra il traffico da inviare ai bilanciatori del carico di riserva, anche quando il bilanciatore del carico principale è in stato attivo. Il rapporto deve essere compreso tra 0 e 1, ad esempio 0,1. Il valore predefinito è impostato su 0.

Best practice

Ecco alcune best practice da tenere a mente quando configuri il record e i controlli di integrità di Cloud DNS:

• Il tempo necessario per il failover del traffico dai bilanciatori del carico principali a quelli di backup (ovvero la durata dell'interruzione) dipende dal valore TTL DNS, dall'intervallo del controllo di integrità e dal parametro soglia di stato non corretto del controllo di integrità.

  Con Cloud DNS di Google, il limite superiore per questo periodo può essere calcolato utilizzando la seguente formula:

  Duration of outage = DNS TTL + Health Check Interval * Unhealthy Threshold
  

  Per la configurazione del failover, ti consigliamo di impostare il TTL DNS su 30-60 secondi. TTL più elevati comportano tempi di riposo più lunghi perché i client su internet continuano ad accedere ai bilanciatori del carico delle applicazioni esterni principali anche dopo il trasferimento del DNS al bilanciatore del carico delle applicazioni esterno regionale di riserva.

• Configura i parametri di soglia di stato integro e non integro nei controlli di integrità in modo da evitare failover non necessari causati da errori transitori. Soglie più elevate aumentano il tempo necessario per il failover del traffico ai bilanciatori del carico di riserva.

• Per contribuire ad assicurare che la configurazione del failover funzioni come previsto, puoi configurare il criterio di routing DNS in modo da inviare sempre una piccola percentuale di traffico ai bilanciatori del carico di riserva anche quando quelli principali sono operativi. Per farlo, puoi utilizzare il parametro --backup-data-trickle-ratio quando crei il set di record DNS.

  Puoi configurare la percentuale di traffico inviato al backup come frazione da 0 a 1. Il valore tipico è 0, 1, anche se Cloud DNS consente di inviare il 100% del traffico agli indirizzi VIP di backup per attivare manualmente un failover.