Failover per i bilanciatori del carico delle applicazioni esterni

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

Il failover e il failback sono i processi automatici che instradano il traffico da e verso un bilanciatore del carico. Quando Cloud DNS rileva un'interruzione e instrada il traffico dal bilanciatore del carico principale a quello di backup, la procedura è chiamata failover. Quando Cloud DNS inverte questa operazione e reindirizza il traffico al bilanciatore del carico principale, il processo è chiamato 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 che il traffico venga sottoposto a failover. Solo i bilanciatori del carico delle applicazioni esterni regionali possono essere utilizzati come bilanciatori del carico di backup. I bilanciatori del carico delle applicazioni esterni regionali non sono solo autonomi all'interno delle singole regioni, ma sono anche isolati da qualsiasi bilanciatore del carico delle applicazioni esterno globale o bilanciatore del carico delle applicazioni classico in esecuzione nella stessa regione.Google Cloud

I bilanciatori del carico delle applicazioni esterni regionali funzionano meglio come bilanciatori del carico di failover per i bilanciatori del carico delle applicazioni esterni globali perché si basano entrambi su proxy Envoy ed elaborano il traffico in modo molto simile. Ciò è in contrasto con un bilanciatore del carico delle applicazioni classico, che presenta differenze notevoli nel modo in cui viene gestito il 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 bilanciatore del carico delle applicazioni esterno regionale
• Da un bilanciatore del carico delle applicazioni classico a un bilanciatore del carico delle applicazioni esterno regionale

Importante: la configurazione di failover descritta in questa pagina è una configurazione di failover attiva/passiva in cui il traffico esegue il failover su un bilanciatore del carico di backup solo quando il bilanciatore del carico principale non è disponibile. Ciò si ottiene utilizzando un criterio di routing di failover di Cloud DNS. I bilanciatori del carico delle applicazioni esterni regionali supportano anche una configurazione active-active, in cui puoi eseguire il deployment di più bilanciatori del carico in diverse regioni che gestiscono tutto il traffico contemporaneamente. Questa operazione può essere configurata utilizzando un criterio di routing in base alla geolocalizzazione di Cloud DNS. Per i dettagli, consulta Alta affidabilità per i bilanciatori del carico delle applicazioni esterni regionali.

Workflow 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 eseguito il deployment dei backend.

Failover da un bilanciatore del carico delle applicazioni esterno globale a due bilanciatori del carico delle applicazioni esterni regionali (fai clic per ingrandire).

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

1. Rileva errori nel bilanciatore del carico principale

   Google Cloud utilizza i controlli di integrità per rilevare se il bilanciatore del carico delle applicazioni esterno principale è integro. Configura questi controlli di integrità per 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 client proviene dal Nord America e dall'Europa, puoi configurare probe provenienti da due regioni del Nord America e una regione dell'Europa.

   Se i controlli di integrità provenienti da due o più di queste regioni non vanno a buon fine, viene attivato il failover al bilanciatore del carico delle applicazioni 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 probe del controllo di integrità provengono da un Point of Presence (PoP) su internet a una piccola distanza dalla regione di origine Google Cloudconfigurata.

2. Instradare il traffico ai bilanciatori del carico di backup

   Se il bilanciatore del carico primario 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 backup.

   La durata dell'interruzione o il tempo necessario per il failover del traffico dai bilanciatori del carico principali a quelli di backup è determinata dal valore TTL del 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. Esegui il failback al bilanciatore del carico principale

   Una volta che i controlli di integrità iniziano a superare di nuovo i test, il failback al bilanciatore del carico principale è automatico. Non sono previsti tempi di inattività durante il failback perché sia il bilanciatore del carico di backup sia quello primario gestiscono il traffico.

4. Testa il failover periodicamente

   Ti consigliamo di testare periodicamente il flusso di lavoro di failover nell'ambito del tuo piano di continuità aziendale. Assicurati di testare sia gli spostamenti graduali che 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, segui questi passaggi:

1. Esamina la configurazione del bilanciatore del carico principale esistente e verifica che le funzionalità (come quelle di sicurezza, gestione e routing del traffico e CDN) utilizzate dal bilanciatore del carico principale siano disponibili con il bilanciatore del carico delle applicazioni esterno regionale di backup. Se funzionalità simili non sono disponibili, questo bilanciatore del carico potrebbe non essere un buon candidato 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 i criteri di routing DNS per rilevare le interruzioni e indirizzare 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 backup 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 GKE devono notare 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 in entrata GKE. Questo perché GKE Gateway supporta la configurazione dei bilanciatori del carico delle applicazioni esterni sia globali che regionali. Tuttavia, il controller Ingress di GKE supporta solo il bilanciatore del carico delle applicazioni classico.

  Per ottenere risultati ottimali, utilizza GKE Gateway per eseguire il deployment dei bilanciatori del carico primario e di backup.

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

• Cloud Armor. Se utilizzi Cloud Armor per il bilanciatore del carico principale, assicurati di configurare le stesse funzionalità di Cloud Armor anche quando configuri il bilanciatore del carico delle applicazioni esterno regionale di backup. Cloud Armor offre funzionalità diverse nell'ambito regionale rispetto a quello globale. Per saperne di più, consulta le seguenti sezioni della documentazione di Cloud Armor:

  • Policy di sicurezza regionali di Cloud Armor
  • Criteri di sicurezza globali di Cloud Armor

• Certificati SSL. Se vuoi utilizzare un certificato SSL comune sia per i bilanciatori del carico principali che per quelli di backup, 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 backup. 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 che utilizzano bucket di backend.

Configura il bilanciatore del carico di backup

Il bilanciatore del carico di backup è 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 backup:

• Devi configurare le funzionalità del bilanciatore del carico delle applicazioni esterno regionale di backup in modo che siano il più simili possibile al 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 stesse funzionalità dei bilanciatori del carico delle applicazioni esterni globali, con alcune eccezioni. Il bilanciatore del carico regionale 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 primario e di backup.

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

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

  Ti consigliamo di utilizzare un framework di automazione come Terraform per ottenere e mantenere la coerenza nelle configurazioni del bilanciatore del carico nei deployment primari e di backup.

• Ti consigliamo di configurare bilanciatori del carico delle applicazioni esterni regionali di backup 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 in sole 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 che utilizzi criteri round robin ponderato durante il reindirizzamento del failover dal bilanciatore del carico globale primario a questi bilanciatori del carico regionali di backup. Assegna pesi a ogni bilanciatore del carico di backup tenendo conto delle dimensioni massime dei gruppi di istanza di backend in diverse regioni.

• 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 preoccupazione principale durante il failover, ti consigliamo di configurare i bilanciatori del carico delle applicazioni esterni regionali di backup utilizzando il livello Standard. L'utilizzo dell'infrastruttura del livello Standard offre un isolamento aggiuntivo dall'infrastruttura del livello Premium utilizzata dai bilanciatori del carico delle applicazioni esterni globali.

• Se vuoi utilizzare gli stessi backend sia per i bilanciatori del carico primari che per quelli di backup, crea il bilanciatore del carico delle applicazioni esterno regionale di backup nella regione in cui si trovano i backend. Se hai abilitato la scalabilità automatica per i gruppi di istanze di backend, devi soddisfare i requisiti per la condivisione dei backend tra le implementazioni.

• Se necessario, riserva proxy Envoy aggiuntivi per i bilanciatori del carico delle applicazioni esterni regionali per assicurarti che, in caso di failover, il traffico aggiuntivo non interrompa altri deployment di bilanciatori del carico nella stessa regione. Per i dettagli, vedi Riserva capacità aggiuntiva della subnet solo proxy.

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

Riservare capacità aggiuntiva della subnet solo proxy

Tutti i bilanciatori del carico basati su Envoy a livello di regione in una regione e in una rete VPC condividono lo stesso pool di proxy Envoy. In caso di failover, i bilanciatori del carico delle applicazioni esterni regionali di backup vedono un aumento dell'utilizzo del proxy per gestire il traffico di failover dal bilanciatore del carico principale. Per garantire che la capacità sia sempre disponibile per i bilanciatori del carico di backup, ti consigliamo di rivedere le dimensioni della tua subnet solo proxy. Ti consigliamo di calcolare il numero stimato di proxy necessari per gestire il traffico in una determinata regione e aumentare la capacità se necessario. Ciò contribuisce anche 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 le norme DNS per distribuire il traffico su più bilanciatori del carico di backup in regioni diverse, devi tenerne conto quando stimi i requisiti del 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 primario (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 i bilanciatori del carico primario e di backup

Per ottenere una ridondanza completa dell'infrastruttura, 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 regionali di backup 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 garantire che si verifichi un failover corretto:

• Il gestore della scalabilità automatica deve essere configurato solo con la scalabilità basata sulla CPU. Il metodo di scalabilità basato sull'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 globali e regionali durante il processo di failover.
• I controlli di scale in devono essere configurati per impedire al gestore della scalabilità automatica di ridurre prematuramente le dimensioni del gruppo durante il downtime quando il traffico passa dal bilanciatore del carico globale a quello regionale. Questo tempo di inattività può essere pari alla somma del TTL DNS più l'intervallo di controllo di integrità configurato.

Se non configuri correttamente la scalabilità automatica, si potrebbe verificare un'interruzione secondaria durante il failover perché la perdita di traffico dal bilanciatore del carico globale fa sì che il gruppo di istanze si riduca rapidamente.

Configura Cloud DNS e i controlli di integrità

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

Per configurare il controllo di integrità e le norme di routing richiesti:

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

   gcloud 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 Google Cloud regioni da cui vengono eseguiti i controlli di integrità. 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 successivo emesso dallo stesso prober. Il valore minimo supportato è 30 secondi. Per i valori consigliati, consulta Best practice.
   • HEALTHY_THRESHOLD e UNHEALTHY_THRESHOLD: il numero di probe sequenziali che devono riuscire o non riuscire affinché l'istanza VM sia considerata integra o non integra. Se uno dei due viene omesso, Google Cloud utilizza una soglia predefinita di 2.
   • REQUEST_PATH: il percorso dell'URL a cui Google Cloud invia le richieste di probe di controllo di integrità. Se omesso, Google Cloud invia richieste di probe al percorso principale, /. Se gli endpoint sottoposti a controllo di integrità sono privati, il che non è tipico per gli indirizzi IP regola di forwarding esterno, puoi impostare questo percorso su /afhealthz.

2. Crea un set di record Cloud DNS in Cloud DNS e applica un criterio di routing. La policy di routing deve essere configurata per risolvere il tuo nome di dominio nell'indirizzo IP della regola di forwarding del bilanciatore del carico primario oppure, in caso di errore del controllo di integrità, in uno degli indirizzi IP della regola di forwarding dei bilanciatori del carico di backup.

   gcloud 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 set di record da aggiungere, ad esempio test.example.com
   • TIME_TO_LIVE: la durata (TTL) del record impostata in 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 record set, 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 vengono implementati i bilanciatori del carico di backup
   • BACKUP_LOAD_BALANCER_IP_ADDRESS: gli indirizzi IP delle regola di forwarding dei bilanciatori del carico di backup corrispondenti a ogni regione
   • BACKUP_DATA_TRICKLE_RATIO: il rapporto tra il traffico da inviare ai bilanciatori del carico di backup, anche quando il bilanciatore del carico primario è integro. 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 Cloud DNS e i controlli di integrità:

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

  Con Cloud DNS di Google, il limite superiore di 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 inattività più lunghi perché i client su internet continuano ad accedere ai bilanciatori del carico delle applicazioni esterni principali anche dopo il failover del DNS al bilanciatore del carico delle applicazioni esterno regionale di backup.

• 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 temporanei. Soglie più elevate aumentano il tempo necessario per il failover del traffico ai bilanciatori del carico di backup.

• Per assicurarti che la configurazione del failover funzioni come previsto, puoi configurare la policy di routing DNS in modo che invii sempre una piccola percentuale di traffico ai bilanciatori del carico di backup anche quando i bilanciatori del carico principali sono integri. Questa operazione può essere eseguita utilizzando 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 ti consente di inviare il 100% del traffico agli indirizzi VIP di backup per attivare manualmente un failover.