Failover per i bilanciatori del carico delle applicazioni esterni

Anteprima

Questo prodotto o funzionalità è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini generali del servizio dei Termini specifici del servizio. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per saperne di più, consulta le descrizioni della fase di lancio.

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

Il failover e il failover sono processi automatici che instradano il traffico da e verso un bilanciatore del carico. Quando Cloud DNS rileva un'interruzione del servizio e instrada il traffico dalla principale al bilanciatore del carico di backup, il processo è chiamato failover. Quando Cloud DNS inverte questa operazione e reindirizza il traffico alla bilanciatore del carico principale, il processo è chiamato failback.

Come funziona il failover

Il failover globale a regionale per i bilanciatori del carico delle applicazioni esterni viene gestito creando due o Altri bilanciatori del carico delle applicazioni esterni regionali nelle regioni in cui vuoi che il traffico di 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 autosufficienti all'interno delle singole regioni Google Cloud, ma sono anche isolati da qualsiasi bilanciatore del carico delle applicazioni esterno globale o infrastruttura di 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. È in contrasto con il bilanciatore del carico delle applicazioni classico che presenta differenze significative nel modo in cui il traffico gestiti.

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 è un'impostazione attivo-passivo configurazione di failover in cui il failover del traffico viene eseguito solo su un bilanciatore del carico di backup se il bilanciatore del carico principale non è disponibile. Ciò si ottiene utilizzando un Criterio di routing del failover di Cloud DNS. I bilanciatori del carico delle applicazioni esterni regionali supportano anche una configurazione active-active, in cui puoi implementare più bilanciatori del carico in regioni diverse che tutti gestiscono il traffico contemporaneamente. Può essere configurato utilizzando un Routing di geolocalizzazione di Cloud DNS . Per maggiori dettagli, vedi Disponibilità elevata per Application Load Balancer esterni regionali.

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 (fai clic per ingrandire).

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

1. Rilevare gli errori nel bilanciatore del carico principale

   Google Cloud utilizza l'integrità controlla per rilevare se le tue il bilanciatore del carico delle applicazioni esterno principale è integro. Configuri questi controlli di integrità per inviare probe da tre regioni di origine. Queste tre regioni di origine devono essere rappresentativo delle regioni da cui i clienti accedono al carico con il bilanciatore del carico di rete passthrough esterno regionale. Ad esempio, se hai un bilanciatore del carico delle applicazioni esterno globale e la maggior parte dei il traffico dei clienti proviene da Nord America ed Europa, puoi configurare i probe provenienti da due regioni del Nord America e 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 l'origine regioni.
   • Sono supportati i controlli di integrità HTTP, HTTPS e TCP.
   • I probe del controllo di integrità provengono effettivamente da un POP (POP) su a internet a una certa distanza da Google Cloud configurato regione di origine.

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

   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 impostazioni consigliate, consulta le 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 è previsto alcun tempo di riposo durante il failback perché i bilanciatori del carico di backup e principale 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 trasferimenti 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 del traffico e di instradamento e la CDN) utilizzate dal bilanciatore del carico principale siano disponibili con il bilanciatore del carico delle applicazioni esterno regionale di riserva. Se caratteristiche simili sono non disponibile, questo bilanciatore del carico potrebbe non essere adatto per di 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 backup supporti tutti attualmente utilizzate con il bilanciatore del carico principale.

Per evitare interruzioni del traffico, esamina le seguenti differenze:

• Deployment di 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é Il gateway GKE supporta la configurazione sia dell'ambiente di Application Load Balancer esterni regionali. Tuttavia, il traffico GKE Ingress supporta solo il bilanciatore del carico delle applicazioni classico.

  Per ottenere risultati ottimali, utilizza GKE Gateway per eseguire il deployment sia del bilanciatore del carico principale sia di quello di riserva.

• Cloud CDN. I bilanciatori del carico delle applicazioni esterni regionali non supportano Cloud CDN. Pertanto, in caso di in caso di errore, saranno interessate anche tutte le operazioni che si basano su Cloud CDN. Per una migliore ridondanza, consigliamo di configurare una soluzione CDN di terze parti che possono fungere da riserva 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 backup. Google Cloud Armor ha diverse funzionalità disponibili sia a livello regionale che globale. Per ulteriori informazioni, consulta le 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 desideri utilizzare un certificato SSL comune sia per il bilanciatore del carico principale e di backup, verifica che il tipo il certificato utilizzato con il bilanciatore del carico principale sia compatibile con Esegui il backup del bilanciatore del carico delle applicazioni esterno regionale. Esamina le differenze tra il protocollo SSL certificati disponibili con 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 bilanciatori del carico tramite 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 viene configurato nel 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 sia più simile 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 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 il failover e il failover del deployment in produzione.

  Per visualizzare le funzionalità specifiche delle reti regionali, globali e classiche Bilanciatori del carico delle applicazioni, consulta il confronto tra le 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 backup in ogni regione in cui sono presenti i backend. Ad esempio, se esegui il failover da un deployment globale con gruppi di istanze in cinque regioni per eseguire il backup dei bilanciatori del carico a livello di regione in tre regioni, rischi di sovraccaricare i tuoi servizi di backend 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 assegnazione in ordine di precedenza ponderata 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 istanze 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 è il tuo problema principale durante il failover, ti consigliamo di configurare i bilanciatori del carico delle applicazioni esterni regionali di backup utilizzando al 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 per i bilanciatori del carico principali e di riserva, crea il bilanciatore del carico delle applicazioni esterno regionale di riserva nella regione in cui si trovano i backend. Se hai abilitato la scalabilità automatica per il backend di gruppi di istanze, devi soddisfare i requisiti per la condivisione e i backend nei vari deployment.

• Se necessario, prenota proxy Envoy aggiuntivi per bilanciatori del carico delle applicazioni esterni regionali assicura che, in caso di evento di failover, il traffico aggiuntivo non interrompere qualsiasi altro deployment del bilanciatore del carico nella stessa regione. Per maggiori dettagli, consulta Prenotare capacità aggiuntiva solo per le subnet proxy.

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

Riserva capacità subnet solo proxy aggiuntiva

Tutti i bilanciatori del carico basati su Envoy a livello di regione in una regione e in 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 contribuire a garantire che la capacità sia sempre disponibili per i bilanciatori del carico di backup, ti consigliamo di esaminare le dimensioni della tua subnet solo proxy. Me ti consigliamo di calcolare il numero stimato di proxy necessari per gestire il traffico in una determinata regione e, se necessario, aumenta la capacità. 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 Google Cloud assegna un numero maggiore di proxy Envoy al tuo bilanciatore del carico se necessario.

Non puoi espandere una subnet solo proxy come faresti per una di indirizzi principali (con il parametro 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 il bilanciatore del carico principale e quello 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 istanze 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.
• Entrambi i servizi di backend globali e regionali devono utilizzare solo l'UTILIZATION e la modalità di bilanciamento del carico. L'utilizzo della modalità di bilanciamento di RATE non è consigliato perché le istanze potrebbero ricevere il doppio del traffico sia dal carico globale sia da quello a livello di regione tramite i bilanciatori del carico durante il processo di failover.
• I controlli di scale in devono essere configurati per impedire al gestore della scalabilità automatica fare lo scale down prematuramente del gruppo durante il tempo di inattività quando il traffico cambia 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ò causare un'interruzione secondaria durante il failover a causa della perdita di traffico il gruppo di istanze si riduce rapidamente.

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 bilanciamento del carico Cloud in modo da rilevare gli arresti anomali e instradare il traffico ai bilanciatori del carico di riserva.

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

1. Crea un controllo di integrità per l'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 funzionalità di Google Cloud delle regioni da cui vengono eseguiti i controlli di integrità. Devi specificare esattamente tre regioni di origine.
   • HEALTH_CHECK_INTERVAL: la quantità di tempo in secondi dall'inizio di una sonda emessa da un prober all'inizio della successiva sonda emessa 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 parole probe che devono avere esito positivo o negativo affinché l'istanza VM venga considerata sano o meno. Se uno dei due viene omesso, Google Cloud utilizza un'istanza soglia predefinita di 2.
   • REQUEST_PATH: il percorso dell'URL a cui Google Cloud invia richieste di sonde di controllo dell'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 indirizzi IP regola di forwarding esterni, 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 inoltro del bilanciatore del carico principale o, in caso di errore del controllo di integrità, in uno degli indirizzi IP della regola 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 set di record da aggiungere, ad esempio test.example.com
   • TIME_TO_LIVE: durata (TTL) del record impostato in un numero di secondi. Per i valori consigliati, consulta le best practice.
   • RECORD_TYPE: il record type, 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: la regola di forwarding nome del bilanciatore del carico principale
   • BACKUP_REGION: le regioni dove vengono di cui è stato eseguito il deployment dei bilanciatori del carico di riserva
   • BACKUP_LOAD_BALANCER_IP_ADDRESS: la regola di inoltro 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. L'impostazione predefinita è impostato su 0.

Best practice

Di seguito sono riportate alcune best practice da tenere presenti quando configuri Record e controlli di integrità 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, consigliamo di impostare il TTL del DNS su 30-60 secondi. TTL più elevati portano a tempi di inattività più lunghi perché i client su internet continuerà ad accedere ai bilanciatori del carico delle applicazioni esterni primari 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 transitori. Soglie più alte aumenta il tempo necessario per il failover del traffico verso i bilanciatori del carico di backup.

• Per assicurarti che la configurazione del failover funzioni come previsto, puoi configurare criterio di routing DNS per inviare sempre una piccola percentuale di traffico al backup dei bilanciatori del carico anche quando i bilanciatori del carico primari sono in stato integro. 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.