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: un bilanciatore del carico primario 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 primario al bilanciatore del carico di backup, il processo viene chiamato failover. Quando Cloud DNS inverte questa operazione e reindirizza il traffico al bilanciatore del carico primario, il processo viene 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 esegua il 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 Google Cloud 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.

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é entrambi sono basati su proxy Envoy ed elaborano il traffico in modi molto simili. Questo è 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

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

Failover da un bilanciatore del carico delle applicazioni esterno globale a due bilanciatori del carico delle applicazioni esterni regionali.
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. Rilevare gli errori nel bilanciatore del carico primario

    Google Cloud utilizza i controlli di integrità per rilevare se il bilanciatore del carico delle applicazioni esterno primario è 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 client 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 i 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:

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

  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 le policy 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 primari a quelli di backup è 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. Failback al bilanciatore del carico primario

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

  4. Testare periodicamente il failover

    Ti consigliamo di testare periodicamente il flusso di lavoro di failover nell'ambito del tuo piano di continuità operativa. Assicurati di testare sia i cambiamenti graduali sia quelli istantanei del traffico dai bilanciatori del carico primari 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 primario come previsto.

Configurazione del failover

Per configurare il failover, segui questi passaggi:

  1. Esamina la configurazione del bilanciatore del carico primario esistente e verifica che le funzionalità (come le funzionalità di sicurezza, le funzionalità di gestione e routing del traffico e la CDN) utilizzate dal bilanciatore del carico primario siano disponibili con il bilanciatore del carico delle applicazioni esterno regionale di backup. Se non sono disponibili funzionalità simili, 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 primario.
  3. Crea il controllo di integrità e la policy di routing DNS per rilevare le interruzioni e instradare il traffico dal bilanciatore del carico primario a quello di backup durante il failover.

Esaminare la configurazione del bilanciatore del carico primario

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 primario.

Per evitare interruzioni del traffico, esamina le seguenti differenze:

  • Deployment GKE. Gli utenti 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 Ingress di GKE. Questo perché GKE Gateway supporta la configurazione sia del bilanciatore del carico delle applicazioni esterno globale sia di quello regionale. Tuttavia, il controller Ingress di GKE supporta solo il bilanciatore del carico delle applicazioni classico.

    Per risultati ottimali, utilizza GKE Gateway per eseguire il deployment sia del bilanciatore del carico primario sia di quello di backup.

  • Cloud CDN. I bilanciatori del carico delle applicazioni esterni regionali non supportano Cloud CDN. Pertanto, in caso di errore, vengono interessate anche tutte 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 fallback a Cloud CDN.

  • Cloud Armor. Se utilizzi Cloud Armor per il bilanciatore del carico primario, 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 maggiori informazioni, consulta le seguenti sezioni della documentazione di Cloud Armor:

  • Certificati SSL. Se vuoi utilizzare un certificato SSL comune sia per il bilanciatore del carico primario sia per quello di backup, verifica che il tipo di certificato SSL utilizzato con il bilanciatore del carico primario 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 i dettagli, consulta le seguenti sezioni:

  • 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 i bucket di backend.

Configurare 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 presente 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 primario, 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 primari e di backup.

    • Bilanciatore del carico delle applicazioni classico. Con il bilanciatore del carico delle applicazioni classico, la parità di funzionalità tra il bilanciatore del carico primario e quello di backup è più difficile da ottenere 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 attentamente 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à 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 sia nei deployment primari sia in quelli di backup.

  • Ti consigliamo di configurare i bilanciatori del carico delle applicazioni esterni regionali di backup in ogni regione in cui hai i 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 che utilizzi policy di round robin ponderato quando reindirizza il traffico di failover da un bilanciatore del carico globale primario a questi bilanciatori del carico regionali di backup. Assegna i 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 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 di livello Standard offre un isolamento aggiuntivo dall'infrastruttura di livello Premium utilizzata dai bilanciatori del carico delle applicazioni esterni globali.

  • Se vuoi utilizzare gli stessi backend sia per i bilanciatori del carico primari sia 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 i deployment.

  • Se necessario, prenota proxy Envoy aggiuntivi per i bilanciatori del carico delle applicazioni esterni regionali per assicurarti che, in caso di evento di failover, il traffico aggiuntivo non interrompa altri deployment di bilanciatori del carico nella stessa regione. Per i dettagli, consulta Prenotare capacità aggiuntiva della 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.

Prenotare capacità aggiuntiva della subnet solo proxy

Tutti i bilanciatori del carico regionali basati su Envoy 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 registrano un aumento dell'utilizzo dei proxy per gestire il traffico di failover dal bilanciatore del carico primario. Per assicurarti che la capacità sia sempre disponibile per i bilanciatori del carico di backup, ti consigliamo di esaminare 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 di aumentare la capacità, se necessario. In questo modo, gli eventi di failover non interrompono altri bilanciatori del carico regionali basati su Envoy nella stessa regione e 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 policy DNS per suddividere il traffico tra più bilanciatori del 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 di Google Cloud assegnare un numero maggiore di proxy Envoy al bilanciatore del carico se 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.

Condividere i backend tra i bilanciatori del carico primari 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 regionali di backup con backend (gruppi di istanze o gruppi di endpoint di rete) che non si sovrappongono ai bilanciatori del carico primari.

Tuttavia, se vuoi condividere un gruppo di istanza di backend tra i bilanciatori del carico primari e secondari e la scalabilità automatica è abilitata per i gruppi di istanze, devi soddisfare i seguenti requisiti per assicurarti 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 il gruppo durante il tempo di inattività 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 del controllo di integrità configurato.

Se non configuri correttamente la scalabilità automatica, si può 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.

Configurare Cloud DNS e i controlli di integrità

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

Segui questi passaggi per configurare il controllo di integrità e le policy di routing richiesti:

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

    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: l'intervallo di 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 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 le richieste di probe al percorso principale, /. Se gli endpoint di cui viene controllata l'integrità sono privati, il che non è tipico per gli indirizzi IP regola di forwarding esterni, puoi impostare questo percorso su /afhealthz.

  2. Crea un set di record Cloud DNS in Cloud DNS e applica una policy di routing. La policy di routing deve essere configurata per risolvere il nome di dominio nell'indirizzo IP della regola di forwarding del bilanciatore del carico primario o, in caso di errore del controllo di integrità, in uno degli indirizzi IP delle regole 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 set di record in secondi. Per i valori consigliati, consulta 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 primario
    • BACKUP_REGION: le regioni in cui è stato eseguito il deployment dei 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: la proporzione di traffico da inviare ai bilanciatori del carico di backup, anche quando il bilanciatore del carico primario è integro. La proporzione deve essere compresa tra 0 e 1, ad esempio 0,1. Il valore predefinito è 0.

Best practice

Ecco alcune best practice da tenere presente 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 della soglia di stato non integro 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. I TTL più elevati comportano tempi di inattività più lunghi perché i client su internet continuano ad accedere ai bilanciatori del carico delle applicazioni esterni primari anche dopo che il DNS ha eseguito il failover al bilanciatore del carico delle applicazioni esterno regionale di backup.

  • Configura i parametri della soglia di stato integro e non integro nei controlli di integrità in modo da evitare failover non necessari causati da errori temporanei. Le 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 primari sono integri. Puoi farlo 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.