Per proteggerti da interruzioni dell'infrastruttura o errori di configurazione, puoi progettare strategie di failover per i bilanciatori del carico delle applicazioni esterni globali. Queste strategie utilizzano bilanciatori del carico delle applicazioni esterni regionali e indirizzano il traffico da un bilanciatore del carico delle applicazioni esterno globale per mantenere l'alta affidabilità durante le interruzioni dell'infrastruttura globale o gli errori di configurazione.
In un'architettura di failover, implementi un bilanciatore del carico principale e uno o più bilanciatori del carico di backup:
- Il bilanciatore del carico principale è il bilanciatore del carico delle applicazioni esterno globale che gestisce il traffico client durante le normali operazioni.
- Il bilanciatore del carico di backup è un bilanciatore del carico delle applicazioni esterno regionale che riceve il traffico quando il bilanciatore del carico principale non supera i controlli di integrità.
Il failover e il failback sono processi di routing del traffico automatici:
- Il failover si verifica quando Cloud DNS rileva un'interruzione e instrada il traffico dal bilanciatore del carico principale ai bilanciatori del carico di backup.
- Il failback si verifica quando Cloud DNS inverte questo routing e reindirizza il traffico al bilanciatore del carico principale dopo che i controlli di integrità sono stati superati.
Questo documento descrive il failover da un bilanciatore del carico delle applicazioni esterno globale ai bilanciatori del carico di backup regionali. Se vuoi configurare il failover tra bilanciatori del carico delle applicazioni esterni regionali in regioni diverse, consulta Alta affidabilità per i bilanciatori del carico delle applicazioni esterni regionali.
Perché utilizzare i bilanciatori del carico a livello di regione per il failover
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 grazie alle seguenti proprietà:
- I bilanciatori del carico delle applicazioni esterni regionali sono autonomi all'interno delle singole regioniGoogle Cloud e sono isolati anche da qualsiasi infrastruttura del bilanciatore del carico delle applicazioni esterno globale in esecuzione nella stessa regione.
- I bilanciatori del carico delle applicazioni esterni regionali e globali si basano entrambi su proxy Envoy ed elaborano il traffico in modo simile.
Per implementare il failover da globale a regionale per i bilanciatori del carico delle applicazioni esterni globali, crea due o più bilanciatori del carico delle applicazioni esterni regionali nelle regioni in cui vuoi che il traffico venga sottoposto a failover.
Strategie di failover
Puoi implementare il failover per i bilanciatori del carico delle applicazioni esterni globali utilizzando le seguenti strategie:
- Active-passive (global-to-regional failover): implementi uno o più bilanciatori del carico delle applicazioni esterni regionali solo a scopo di backup. In stato stazionario, Cloud DNS viene risolto nell'indirizzo IP del bilanciatore del carico delle applicazioni esterno globale. Se il bilanciatore del carico globale non funziona, Cloud DNS instrada il traffico ai bilanciatori del carico regionali di backup. Questa configurazione utilizza una policy di routing di failover di Cloud DNS.
- Active-active (bypass da globale a regionale): un bilanciatore del carico delle applicazioni esterno globale funge da frontend edge che fornisce funzioni Cloud CDN come la memorizzazione in una cache perimetrale che inoltra le richieste ai bilanciatori del carico delle applicazioni esterni regionali utilizzando i gruppi di endpoint di rete (NEG) internet con nomi di dominio completi (FQDN). In stato stazionario, il traffico scorre in sequenza attraverso entrambi i livelli di bilanciamento del carico. Questa operazione può essere configurata utilizzando una policy di routing basata sulla geolocalizzazione di Cloud DNS. Se il bilanciatore del carico globale subisce un'interruzione, le policy di routing DNS bypassano il livello globale e indirizzano il traffico client direttamente ai bilanciatori del carico regionali.
Come best practice, se la tua architettura non si basa sul bilanciamento del carico del backend globale in base alla capacità, preferisci la strategia attivo-attivo. Tuttavia, se la tua applicazione richiede esplicitamente il bilanciamento del carico del backend globale per distribuire e riversare il traffico tra le regioni in base alla capacità del backend, implementa la strategia attivo-passivo.
Confronto tra le strategie di failover
La seguente tabella confronta le strategie di failover attiva/passiva e attiva/attiva:
| Attributo strategia | Attivo-passivo | Active-active |
|---|---|---|
| Flusso di traffico in regime stazionario | Client → Bilanciatore del carico delle applicazioni esterno globale → Backend | Client → Bilanciatore del carico delle applicazioni esterno globale → Bilanciatore del carico delle applicazioni esterno regionale → Backend |
| Flusso di traffico con stato di errore | Client → Bilanciatore del carico delle applicazioni esterno regionale → Backend. Il servizio rimane disponibile, ma potrebbe subire una latenza maggiore a causa della perdita dei vantaggi in termini di prestazioni dell'edge. |
Client → Bilanciatore del carico delle applicazioni esterno regionale → Backend (ignorando il bilanciatore del carico delle applicazioni esterno globale). Il servizio rimane disponibile, ma potrebbe subire una latenza maggiore a causa della perdita dei vantaggi in termini di prestazioni dell'edge. |
| Gestione della configurazione | Richiede la sincronizzazione di configurazioni indipendenti tra bilanciatori del carico globali e regionali. | Il livello globale richiede una configurazione minima perché la maggior parte della logica dell'applicazione risiede nei bilanciatori del carico regionali. Tuttavia, devi duplicare le policy di sicurezza edge (Cloud Armor) e la configurazione di terminazione della connessione (certificati TLS) su entrambi i livelli. |
| Verifica dell'affidabilità | Il bilanciatore del carico delle applicazioni esterno regionale è inattivo in stato stazionario. Sono consigliati test periodici o flusso limitato di traffico DNS. | Il traffico in stato stazionario testa continuamente il bilanciatore del carico delle applicazioni esterno regionale. È consigliabile eseguire test periodici o inviare un flusso limitato di traffico direttamente al bilanciatore del carico regionale. |
| Sicurezza del deployment progressivo | Le modifiche alla configurazione del bilanciatore del carico delle applicazioni esterno globale vengono applicate a livello globale. Le modifiche al bilanciatore del carico delle applicazioni esterno regionale sono isolate, ma il traffico in stato stazionario non le testa. | Puoi applicare le modifiche al bilanciatore del carico delle applicazioni esterno regionale in modo progressivo, regione per regione. Se una regione non funziona, il livello globale indirizza automaticamente il traffico verso le regioni integre. |
| Bilanciamento del carico del backend globale | Supportato Il bilanciatore del carico delle applicazioni esterno globale può bilanciare il traffico tra i backend in regioni diverse in base alla capacità. |
Limitata Il bilanciatore del carico delle applicazioni esterno globale indirizza il traffico al bilanciatore del carico delle applicazioni esterno regionale più vicino. Il bilanciatore del carico a livello di regione bilancia il traffico solo a livello locale e non distribuisce il traffico tra le regioni in base alla capacità del backend. |
| Costo e fatturazione | Le tariffe per l'elaborazione dei dati si applicano a un singolo livello di bilanciamento del carico. In stato stazionario, i costi derivano dal bilanciatore del carico delle applicazioni esterno globale; gli addebiti per il bilanciatore del carico delle applicazioni esterno regionale si applicano solo durante i test o gli eventi di failover. | Entrambi i livelli di bilanciamento del carico generano contemporaneamente costi per l'elaborazione dei dati perché il traffico scorre sia attraverso i livelli globali che quelli regionali in stato stazionario. |
| Caso d'uso consigliato | Carichi di lavoro che richiedono il bilanciamento del carico globale avanzato del backend e lo spillover del traffico basato sulla capacità tra le regioni. | Carichi di lavoro progettati in base all'isolamento regionale che utilizzano il livello globale per le prestazioni e la memorizzazione nella cache perimetrale. |
Strategia attiva/passiva
In una configurazione active-passive, implementi bilanciatori del carico delle applicazioni esterni regionali indipendenti in una o più regioni insieme al bilanciatore del carico delle applicazioni esterno globale o al bilanciatore del carico delle applicazioni classico principale.
Come funziona il failover attivo-passivo
La seguente configurazione mostra il failover da un bilanciatore del carico delle applicazioni esterno globale a due bilanciatori del carico delle applicazioni esterni regionali di backup, uno in ogni regione in cui il bilanciatore del carico globale ha eseguito il deployment dei backend.
Il failover attivo-passivo segue questo flusso di lavoro:
- Stato stazionario: Cloud DNS instrada tutto il traffico client al bilanciatore del carico delle applicazioni esterno globale.
- Rilevamento dei guasti: Google Cloud utilizza i controlli di integrità configurati con tre regioni di origine per rilevare se il bilanciatore del carico principale è integro. Se i controlli di integrità provenienti da due o più regioni di origine non vanno a buon fine, Cloud DNS attiva il failover.
- Failover: le policy di routing di failover di Cloud DNS indirizzano il traffico client direttamente ai bilanciatori del carico delle applicazioni esterni regionali di backup. Impatto della latenza durante il failover:poiché i bilanciatori del carico delle applicazioni esterni regionali terminano le connessioni all'interno di una regione Google Cloud specifica, i client che si trovano lontano dalla regione di destinazione potrebbero riscontrare un aumento della latenza e dei tempi di round trip (RTT) mentre il failover è attivo.
- Failback: dopo che i controlli di integrità hanno esito positivo, Cloud DNS ripristina automaticamente il traffico al bilanciatore del carico primario senza tempi di inattività perché entrambi i bilanciatori del carico gestiscono il traffico.
Strategia attiva/attiva (bypass da globale a regionale)
In una strategia attiva-attiva, il bilanciatore del carico delle applicazioni esterno globale utilizza un NEG internet FQDN (INTERNET_FQDN_PORT) per inviare traffico ai bilanciatori del carico delle applicazioni esterni regionali in due o più regioni.
Come funziona il bypass attivo/attivo
La seguente configurazione mostra il failover da un bilanciatore del carico delle applicazioni esterno globale a due bilanciatori del carico delle applicazioni esterni regionali di backup, uno in ogni regione in cui il bilanciatore del carico globale ha eseguito il deployment dei backend.
Il failover attivo-attivo segue questo flusso di lavoro:
- Stato stazionario: il traffico scorre dal client al bilanciatore del carico delle applicazioni esterno globale.
Il bilanciatore del carico globale utilizza un gruppo di endpoint di rete (NEG) FQDN internet di tipo
INTERNET_FQDN_PORTper inoltrare il traffico ai bilanciatori del carico delle applicazioni esterni regionali più vicini. I bilanciatori del carico regionali distribuiscono il traffico ai backend locali. - Rilevamento degli errori: in stato stazionario, se un singolo bilanciatore del carico delle applicazioni esterno regionale o la relativa regione non funziona, il bilanciatore del carico delle applicazioni esterno globale rileva l'errore utilizzando la policy di controllo di integrità Cloud DNS sul NEG internet. Il bilanciatore del carico globale indirizza automaticamente il traffico dalla regione non integra ai bilanciatori del carico regionali integri.
- Bypass: se il bilanciatore del carico delle applicazioni esterno globale subisce un'interruzione, i criteri di failover di Cloud DNS rilevano l'errore e indirizzano il traffico direttamente ai bilanciatori del carico delle applicazioni esterni regionali, bypassando completamente il livello globale. Impatto della latenza durante il bypass: il bilanciatore del carico delle applicazioni esterno globale offre vantaggi in termini di prestazioni edge, ad esempio la terminazione delle connessioni più vicine agli utenti e la memorizzazione nella cache edge. Quando il traffico bypassa il bilanciatore del carico globale, le connessioni client vengono stabilite direttamente con i VIP regionali, il che può aumentare la latenza di connessione e l'RTT per i client geograficamente distanti.
- Failback: quando il bilanciatore del carico globale supera controlli di integrità consecutivi, Cloud DNS riprende automaticamente a restituire il VIP anycast globale nelle risposte DNS, ripristinando il livello di routing edge globale.
Rivedi la configurazione del bilanciatore del carico principale
Prima di configurare il failover, verifica che il bilanciatore del carico delle applicazioni esterno regionale di backup supporti le funzionalità utilizzate dal bilanciatore del carico primario.
- In modalità attivo-passivo, il bilanciatore del carico regionale di backup deve supportare funzionalità simili per gestire il traffico senza problemi durante un'interruzione.
- In modalità active-active, le regole di routing e sicurezza principali devono essere configurate direttamente sul livello regionale, mentre le funzionalità perimetrali globali, come Cloud CDN, vengono ignorate durante un'interruzione globale.
| Funzionalità | Requisiti di compatibilità |
|---|---|
| Deployment di Google Kubernetes Engine | Utilizza GKE Gateway per eseguire il deployment dei bilanciatori del carico primario e di backup. Questo perché 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. Il controller GKE Ingress supporta solo il bilanciatore del carico delle applicazioni classico. |
| Cloud CDN | I bilanciatori del carico delle applicazioni esterni regionali non supportano Cloud CDN. Se si verifica un failover, le operazioni che si basano su Cloud CDN vengono interessate. |
| Cloud Armor | Se utilizzi Cloud Armor sul bilanciatore del carico principale, configura policy di sicurezza di Cloud Armor regionali equivalenti sui bilanciatori del carico di backup. Cloud Armor ha funzionalità diverse disponibili nell'ambito regionale rispetto a quello globale. Per saperne di più, consulta Policy di sicurezza Cloud Armor regionali e Policy di sicurezza Cloud Armor globali. |
| Certificati SSL | Verifica che il tipo di certificato SSL utilizzato dal 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 saperne di più, consulta Certificati SSL di Compute Engine e Certificati SSL di Certificate Manager. |
Considerazioni per i bilanciatori del carico a livello di regione
Configura e implementa i bilanciatori del carico delle applicazioni esterni regionali nella regione in cui vuoi che il traffico venga reindirizzato in caso di errore.
Tieni presente le seguenti considerazioni per le architetture di failover o bypass durante la configurazione del bilanciatore del carico regionale:
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 di confronto delle funzionalità dei bilanciatori 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 principali che in quelli di backup.
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.
Assicurati che le dimensioni della subnet solo proxy siano sufficienti per gestire l'aumento del traffico durante un evento di failover senza interrompere altri bilanciatori del carico regionali nella stessa regione e rete. Per maggiori 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 un evento 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. La prenotazione di una capacità proxy sufficiente garantisce 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.
Per assicurarti che la capacità sia sempre disponibile per i bilanciatori del carico di backup, controlla 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 aumentare la capacità, se necessario. Per saperne di più sui limiti di capacità e sui calcoli di dimensionamento del proxy, consulta la sezione Addebito per istanza proxy in "Prezzi di Cloud Load Balancing".
Se utilizzi le norme DNS per dividere il traffico tra 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 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 principali 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.
Se scegli invece di utilizzare gli stessi backend per i bilanciatori del carico primario e di backup, devi creare ogni bilanciatore del carico delle applicazioni esterno regionale di backup nella regione in cui si trovano questi backend. Inoltre, se la scalabilità automatica è abilitata per i gruppi di istanze, devi soddisfare i seguenti requisiti per garantire che si verifichi il failover corretto:
- Configura il gestore della scalabilità automatica solo con la scalabilità basata sulla CPU. La scalabilità automatica basata sull'utilizzo del bilanciatore del carico non è supportata.
- Sia i servizi di backend globali sia quelli regionali devono utilizzare solo la modalità di bilanciamento del carico
UTILIZATION. Non utilizzare la modalità di bilanciamentoRATEperché le tue istanze potrebbero ricevere il doppio del traffico sia dai bilanciatori del carico globali che da quelli regionali durante il processo di failover. - Configura i controlli di scale in per impedire al gestore della scalabilità automatica di ridurre prematuramente le dimensioni del 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 (time to live) del DNS più l'intervallo di controllo dell'integrità configurato.
Se la scalabilità automatica non viene configurata correttamente, può verificarsi 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 prima che il bilanciatore del carico regionale prenda il controllo.
Configurare il failover attivo-passivo
Per configurare il failover attivo-passivo:
- Esamina le considerazioni sull'architettura: prima di creare risorse, esamina le considerazioni per i bilanciatori del carico regionali per verificare la compatibilità delle funzionalità, la capacità del proxy e i requisiti di scalabilità automatica del backend condiviso.
- Configura il bilanciatore del carico principale: configura il bilanciatore del carico delle applicazioni esterno globale con servizi di backend distribuiti in una o più regioni. Per saperne di più su come configurare un bilanciatore del carico delle applicazioni esterno globale, consulta Configura un bilanciatore del carico delle applicazioni esterno globale.
- Esamina la configurazione del bilanciatore del carico principale: verifica che le funzionalità (come quelle di sicurezza, gestione e routing del traffico e Cloud 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.
- Configura i bilanciatori del carico delle applicazioni esterni regionali di backup: configura bilanciatori del carico delle applicazioni esterni regionali indipendenti nelle regioni in cui vuoi che il traffico esegua il failover. Per informazioni su 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.
- Configura il routing DNS e i controlli di integrità: crea un controllo di integrità per il bilanciatore del carico principale e configura una policy di routing di failover di Cloud DNS per rilevare le interruzioni e indirizzare il traffico client ai bilanciatori del carico regionali di backup.
Configurare il bypass attivo-attivo
Per configurare l'architettura active-active:
Esamina le considerazioni sull'architettura: prima di creare risorse, esamina le considerazioni per i bilanciatori del carico regionali per verificare la compatibilità delle funzionalità e assicurarti che la capacità della subnet solo proxy possa gestire il traffico in stato stazionario e di failover.
Configura i bilanciatori del carico delle applicazioni esterni regionali: prima di configurare i bilanciatori del carico regionali, esamina Compatibilità e limitazioni delle funzionalità. Esegui il deployment di bilanciatori del carico delle applicazioni esterni regionali in due o più regioni con i tuoi servizi di backend, indirizzi IP esterni, certificati SSL e policy di sicurezza Cloud Armor regionali. Per istruzioni di configurazione, consulta Configura un bilanciatore del carico delle applicazioni esterno regionale con backend di gruppi di istanze VM.
Configura il DNS per i bilanciatori del carico regionali: crea un record DNS (ad esempio
regional-api.example.com) che rimandi agli indirizzi IP esterni dei bilanciatori del carico delle applicazioni esterni regionali utilizzando una policy di routing in base alla geolocalizzazione o alla latenza. Abilita il controllo di integrità DNS su questo record per rilevare un errore in una regione specifica e indirizzare automaticamente il traffico verso altre regioni integre.Configura il bilanciatore del carico delle applicazioni esterno globale: riserva un indirizzo IP esterno globale e crea un gruppo di endpoint di rete (NEG) internet globale di tipo
INTERNET_FQDN_PORT. Aggiungi un endpoint al NEG internet che punta al FQDN del record DNS regionale, ad esempioregional-api.example.com. Configura un servizio di backend per il bilanciatore del carico delle applicazioni esterno globale, collega il NEG internet e abilita Cloud CDN o Cloud Armor, se necessario. Configura la mappa URL, il proxy HTTP(S) di destinazione e la regola di forwarding globale.Configura il DNS per il failover e i controlli di integrità: crea il record DNS del servizio principale (ad esempio
api.example.com) utilizzando una policy di routingFAILOVER. Assicurati che il set di record abbia un endpoint principale che punta all'indirizzo IP del bilanciatore del carico delle applicazioni esterno globale e endpoint di backup che puntano agli indirizzi IP degli indirizzi IP esterni dei bilanciatori del carico delle applicazioni esterni regionali. Configura un controllo di integrità DNS per monitorare il bilanciatore del carico delle applicazioni esterno globale.
Best practice
Tieni presente le seguenti best practice quando configuri il record Cloud DNS e i controlli di integrità:
Calcola la durata dell'interruzione: il tempo necessario per il failover del traffico dai bilanciatori del carico principali a quelli di backup dipende dal TTL DNS, dall'intervallo del controllo di integrità e dal parametro soglia non integro 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 ThresholdImposta il TTL DNS su 30-60 secondi. Valori TTL più elevati comportano tempi di failover più lunghi perché il client su internet continua ad accedere ai bilanciatori del carico delle applicazioni esterni primari anche dopo il failover del DNS sul bilanciatore del carico delle applicazioni esterno regionale di backup.
Configura le soglie del controllo di integrità: imposta i parametri soglia di integrità e non integrità per evitare failover causati da errori di rete temporanei. Soglie più elevate aumentano il tempo necessario per il failover del traffico ai bilanciatori del carico di backup.
Utilizza il flusso limitato di traffico per la convalida: configura il flag
--backup-data-trickle-ratioper inviare continuamente una piccola percentuale di traffico ai bilanciatori del carico di backup anche quando i bilanciatori del carico principali sono integri. In questo modo, l'infrastruttura di backup è attiva e pronta a gestire il traffico. Puoi configurare la percentuale di traffico inviata ai bilanciatori del carico di 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.Esegui periodicamente il test del failover e del failback: includi il test del failover nel tuo piano diripristino di emergenzay. Verifica gli spostamenti graduali e improvvisi del traffico dai bilanciatori del carico principali a quelli di backup e verifica che il traffico torni senza problemi al bilanciatore del carico principale dopo il failback.