Failover per i bilanciatori del carico delle applicazioni esterni globali

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 instradano 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, esegui il deployment di un bilanciatore del carico principale e di 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 dei 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 automatici di routing del traffico:

  • 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 il superamento dei controlli di integrità.

Questo documento illustra 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 per le seguenti proprietà:

  • I bilanciatori del carico delle applicazioni esterni regionali sono autonomi all'interno delle singole regioniGoogle Cloud e sono anche isolati da qualsiasi infrastruttura di bilanciatori del carico delle applicazioni esterni globali in esecuzione nella stessa regione.
  • I bilanciatori del carico delle applicazioni esterni regionali e i bilanciatori del carico delle applicazioni esterni globali si basano entrambi su proxy Envoy ed elaborano il traffico in modi simili.

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 eseguire il failover del traffico.

Strategie di failover

Puoi implementare il failover per i bilanciatori del carico delle applicazioni esterni globali utilizzando le seguenti strategie:

  • Attivo-passivo (failover da globale a regionale): esegui il deployment di uno o più bilanciatori del carico delle applicazioni esterni regionali esclusivamente per scopi di backup. In stato stabile, Cloud DNS risolve l'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.
  • Attivo-attivo (bypass da globale a regionale): un bilanciatore del carico delle applicazioni esterno globale funge da frontend perimetrale che fornisce funzioni Cloud CDN come l'memorizzazione in una cache perimetrale che inoltra le richieste ai bilanciatori del carico delle applicazioni esterni regionali utilizzando gruppi di endpoint di rete (NEG) internet con nomi di dominio completi (FQDN). In stato stazionario, il traffico passa in sequenza attraverso entrambi i livelli di bilanciamento del carico. Puoi configurarlo utilizzando una policy di routing di geolocalizzazione di Cloud DNS. Se il bilanciatore del carico globale subisce un'interruzione, le policy di routing DNS bypassano il livello globale e instradano 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 sensibile alla capacità, preferisci la strategia attivo-attivo. Tuttavia, se la tua applicazione richiede esplicitamente il bilanciamento del carico del backend globale per distribuire e trasferire il traffico tra le regioni in base alla capacità del backend, implementa la strategia attivo-passivo.

Confronto delle strategie di failover

La tabella seguente mette a confronto le strategie di failover attivo/passivo e attivo/attivo:

Attributo Strategy Attivo-passivo Attivo-attivo
Flusso di traffico in stato stabile 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 in stato di errore

Client → Bilanciatore del carico delle applicazioni esterno regionale → Backend.

Il servizio rimane disponibile, ma potrebbe riscontrare una latenza maggiore a causa della perdita dei vantaggi in termini di prestazioni della rete perimetrale.

Client → Bilanciatore del carico delle applicazioni esterno regionale → Backend (bypassando il bilanciatore del carico delle applicazioni esterno globale).

Il servizio rimane disponibile, ma potrebbe riscontrare una latenza maggiore a causa della perdita dei vantaggi in termini di prestazioni della rete perimetrale.

Gestione delle configurazioni Richiede la sincronizzazione di configurazioni indipendenti tra i bilanciatori del carico globali e regionali. Il livello globale richiede una configurazione minima perché la maggior parte della logica dell'applicazione risiede sui bilanciatori del carico regionali. Tuttavia, devi duplicare le policy di sicurezza perimetrale (Cloud Armor) e la configurazione della terminazione della connessione (certificati TLS) su entrambi i livelli.
Verifica dell'affidabilità Il bilanciatore del carico delle applicazioni esterno regionale è inattivo in stato stabile. Ti consigliamo di eseguire test periodici o di utilizzare il flusso limitato di traffico DNS. Il traffico in stato stabile testa continuamente il bilanciatore del carico delle applicazioni esterno regionale. Ti consigliamo di eseguire test periodici o di 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 stabile 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 instrada il traffico al bilanciatore del carico delle applicazioni esterno regionale più vicino. Il bilanciatore del carico a livello di regione bilancia il traffico solo localmente e non lo distribuisce 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 stabile, 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 il trattamento dati, perché il traffico passa attraverso i livelli globale e regionale in stato stabile.
Caso d'uso consigliato Workload che richiedono un bilanciamento del carico del backend globale avanzato e uno spillover del traffico basato sulla capacità tra le regioni. Workload progettati in base all'isolamento regionale che utilizzano il livello globale per le prestazioni perimetrali e la memorizzazione nella cache.

Strategia attiva/passiva

In una configurazione attivo-passivo, esegui il deployment di 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.

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

Il failover attivo-passivo segue questo flusso di lavoro:

  1. Stato stabile: Cloud DNS instrada tutto il traffico client al bilanciatore del carico delle applicazioni esterno globale.
  2. Rilevamento degli errori: 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.
  3. Failover: le policy di routing di failover di Cloud DNS instradano il traffico client direttamente ai bilanciatori del carico delle applicazioni esterni regionali di backup. Impatto sulla 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 situati lontano dalla regione di destinazione potrebbero riscontrare una latenza e tempi di round trip (RTT) maggiori mentre il failover è attivo.
  4. Failback: dopo che i controlli di integrità hanno nuovamente esito positivo, Cloud DNS ripristina automaticamente il traffico verso il bilanciatore del carico principale senza tempi di inattività, perché entrambi i bilanciatori del carico gestiscono il traffico.

Strategia attiva/attiva (bypass da globale a regionale)

In una strategia attivo-attivo, il bilanciatore del carico delle applicazioni esterno globale utilizza un NEG FQDN internet (INTERNET_FQDN_PORT) per inviare il 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.

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

Il failover attivo-attivo segue questo flusso di lavoro:

  1. Stato stabile: il traffico fluisce 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_PORT per inoltrare il traffico ai bilanciatori del carico delle applicazioni esterni regionali più vicini. I bilanciatori del carico regionali inviano quindi il traffico ai backend locali.
  2. Rilevamento degli errori: in stato stabile, se un singolo bilanciatore del carico delle applicazioni esterno regionale o la relativa regione non funzionano, il bilanciatore del carico delle applicazioni esterno globale rileva l'errore utilizzando la policy di controllo di integrità di Cloud DNS sul NEG internet. Il bilanciatore del carico globale allontana automaticamente il traffico dalla regione non integra verso i bilanciatori del carico regionali integri.
  3. Bypass: se il bilanciatore del carico delle applicazioni esterno globale subisce un'interruzione, le policy di failover di Cloud DNS rilevano l'errore e instradano 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 perimetrali, come la terminazione delle connessioni più vicine agli utenti e l'edge caching. 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.
  4. Failback: quando il bilanciatore del carico globale supera i controlli di integrità consecutivi, Cloud DNS riprende automaticamente a restituire il VIP anycast globale nelle risposte DNS, ripristinando il livello di routing perimetrale 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 principale.

  • In modalità attiva/passiva, il bilanciatore del carico regionale di backup deve supportare funzionalità simili per subentrare al traffico senza problemi durante un'interruzione.
  • In modalità attiva/attiva, le regole di routing e sicurezza di base 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 il gateway GKE per eseguire il deployment dei bilanciatori del carico principali e di backup. Questo perché i bilanciatori del carico di cui è stato eseguito il deployment utilizzando il gateway GKE sono più compatibili con questo meccanismo di failover rispetto ai bilanciatori del carico di cui è stato eseguito il deployment utilizzando il controller GKE Ingress. 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 sono 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 offre funzionalità diverse nell'ambito regionale rispetto a quello globale. Per saperne di più, consulta Policy di sicurezza di Cloud Armor regionali e Policy di sicurezza di 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 sui bilanciatori del carico a livello di regione

Configura ed esegui il deployment dei bilanciatori del carico delle applicazioni esterni regionali nella regione in cui vuoi che il traffico venga reindirizzato in caso di errore.

Quando configuri il bilanciatore del carico regionale, tieni presente le seguenti considerazioni per le architetture di failover o bypass:

  • 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 l'ottenimento dell'equivalenza tra i bilanciatori del carico principale e di backup.

    • Bilanciatore del carico delle applicazioni classico. Con il bilanciatore del carico delle applicazioni classico, la parità delle funzionalità tra il bilanciatore del carico principale 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 accuratamente il failover e il failback prima di eseguire il deployment in produzione.

    Per visualizzare le funzionalità specifiche dei bilanciatori del carico delle applicazioni regionali, globali e classici, consulta la pagina 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 principale preoccupazione 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 la subnet solo proxy sia di dimensioni sufficienti per gestire l'aumento del traffico durante un evento di failover senza interrompere altri bilanciatori del carico regionali nella stessa regione e nella stessa rete. Per maggiori dettagli, consulta Prenota capacità aggiuntiva per la 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.

Prenota capacità aggiuntiva della subnet solo proxy

Tutti i bilanciatori del carico basati su Envoy regionali 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 registrano 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, esamina 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. Per saperne di più sui limiti di capacità del proxy e sui calcoli di dimensionamento, consulta la sezione Addebito per l'istanza proxy in "Prezzi di Cloud Load Balancing".

Se utilizzi policy DNS per suddividere 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 aGoogle Cloud di 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 lo 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 Modifica le dimensioni o l'intervallo di indirizzi di una subnet solo proxy.

Condivisione dei backend tra i bilanciatori del carico principale 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 principali.

Se invece scegli di utilizzare gli stessi backend per i bilanciatori del carico primari e di backup, devi creare ogni bilanciatore del carico delle applicazioni esterno regionale di backup nella regione in cui si trovano i backend. Inoltre, se la scalabilità automatica è attivata per i gruppi di istanze, devi soddisfare i seguenti requisiti per garantire che il failover avvenga correttamente:

  • Configura il gestore della scalabilità automatica solo con la scalabilità basata sulla CPU. La scalabilità automatica in base all'utilizzo del bilanciatore del carico non è supportata.
  • Sia i servizi di backend globali che quelli regionali devono utilizzare solo la modalità di bilanciamento UTILIZATION. Non utilizzare la modalità di bilanciamento RATE perché le tue istanze potrebbero ricevere il doppio del traffico dai bilanciatori del carico globali e regionali durante il processo di failover.
  • Configura i controlli di scale in per impedire al gestore della scalabilità automatica di fare lo scale down prematuro 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 di integrità configurato.

La mancata configurazione corretta della scalabilità automatica può causare un'interruzione secondaria durante il failover, perché la perdita di traffico dal bilanciatore del carico globale causa una rapida riduzione del gruppo di istanze prima che il bilanciatore del carico regionale subentri.

Configura il failover attivo-passivo

Per configurare il failover attivo-passivo, segui questi passaggi:

  1. Esamina le considerazioni sull'architettura: prima di creare le risorse, esamina le considerazioni sui bilanciatori del carico regionali per verificare la compatibilità delle funzionalità, la capacità del proxy e i requisiti di scalabilità automatica del backend condiviso.
  2. 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.
  3. Esamina la configurazione del bilanciatore del carico principale: verifica che le funzionalità (come quelle di sicurezza, gestione del traffico e routing e Cloud CDN) utilizzate dal bilanciatore del carico principale 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.
  4. 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 eseguire il failover del traffico. 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.
  5. 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 instradare il traffico client ai bilanciatori del carico regionali di backup.

Configura il bypass attivo-attivo

Per configurare l'architettura attivo-attivo, segui questi passaggi:

  1. Esamina le considerazioni sull'architettura: prima di creare le 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 sia in grado di gestire il traffico in stato stabile e di failover.

  2. Configura i bilanciatori del carico delle applicazioni esterni regionali: prima di configurare i bilanciatori del carico regionali, consulta Compatibilità e limitazioni delle funzionalità. Esegui il deployment dei bilanciatori del carico delle applicazioni esterni regionali in due o più regioni con i servizi di backend, gli indirizzi IP esterni, i certificati SSL e le policy di sicurezza Cloud Armor regionali. Per le istruzioni di configurazione, consulta Configura un bilanciatore del carico delle applicazioni esterno regionale con backend di gruppi di istanze VM.

  3. Configura il DNS per i bilanciatori del carico regionali: crea un record DNS (ad esempio regional-api.example.com) che punti agli indirizzi IP esterni dei bilanciatori del carico delle applicazioni esterni regionali utilizzando una policy di routing basata sulla geolocalizzazione o sulla 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.

  4. Configura il bilanciatore del carico delle applicazioni esterno globale: prenota 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 all'FQDN del record DNS regionale, ad esempio regional-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.

  5. 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 routing FAILOVER. Assicurati che il set di record abbia un endpoint principale che punti all'indirizzo IP del bilanciatore del carico delle applicazioni esterno globale e gli endpoint di backup che puntino agli 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 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
    

    Imposta il TTL DNS su 30-60 secondi. Valori TTL più elevati comportano tempi di failover più lunghi perché i client su internet continuano ad accedere ai bilanciatori del carico delle applicazioni esterni principali 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 stato integro e Soglia stato non integro 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-ratio per 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 consente di inviare il 100% del traffico agli indirizzi VIP di backup per attivare manualmente un failover.

  • Esegui periodicamente test di failover e failback: includi i test di failover nel tuo piano di ripristino di emergenza. Verifica i cambiamenti 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.