Puoi configurare un bilanciatore del carico di rete passthrough interno per distribuire le connessioni tra le istanze di macchine virtuali (VM) nei backend principali e, se necessario, passare all'utilizzo dei backend di failover. Il failover fornisce un metodo per aumentare la disponibilità, offrendo al contempo un maggiore controllo su come gestire il carico di lavoro quando le VM di backend principali non sono in stato di esecuzione.
Questa pagina descrive i concetti e i requisiti specifici per il failover per i bilanciatori del carico di rete passthrough interni. Prima di configurare il failover per i bilanciatori del carico di rete passthrough interni, assicurati di conoscere le informazioni concettuali riportate nei seguenti articoli:
- Panoramica del bilanciatore del carico di rete passthrough interno
- Panoramica dei controlli di integrità
È importante comprendere questi concetti perché la configurazione del failover modifica l'algoritmo di distribuzione del traffico standard del bilanciatore del carico di rete passthrough interno.
Per impostazione predefinita, quando aggiungi un backend al servizio di backend di un bilanciatore del carico di rete passthrough interno, il backend è un backend principale. Puoi designare un backend come backend di failover quando lo aggiungi al servizio di backend del bilanciatore del carico o modificandolo in un secondo momento. I backend di failover ricevono connessioni dal bilanciatore del carico solo dopo che una percentuale configurabile di VM principali non supera i controlli di integrità.
Gruppi di istanze supportati
I gruppi di istanze gestite e non gestite sono supportati come backend. Per semplicità, gli esempi in questa pagina mostrano gruppi di istanze non gestite.
L'utilizzo di gruppi di istanze gestite con la scalabilità automatica e il failover potrebbe causare ripetuti failover e failback del pool attivo tra i backend principali e di failover. Google Cloud non ti impedisce di configurare il failover con i gruppi di istanze gestite perché il tuo deployment potrebbe trarre vantaggio da questa configurazione.
Architettura
Il seguente semplice esempio mostra un bilanciatore del carico di rete passthrough interno con un backend principale e un backend di failover.
- Il backend principale è un gruppo di istanze non gestite in
us-west1-a. - Il backend di failover è un altro gruppo di istanze non gestite in
us-west1-c.
L'esempio seguente mostra un bilanciatore del carico di rete passthrough interno con due backend principali e due backend di failover, entrambi distribuiti tra due zone nella regione us-west1. Questa configurazione aumenta l'affidabilità perché non dipende da una singola zona per tutti i backend principali o di failover.
- I backend principali sono i gruppi di istanze non gestite
ig-aeig-d. - I backend di failover sono i gruppi di istanze non gestite
ig-beig-c.
Durante il failover, entrambi i backend principali diventano inattivi, mentre le VM integre in entrambi i backend di failover diventano attive. Per una spiegazione completa di come funziona il failover in questo esempio, consulta l'esempio di failover.
Gruppi di istanze e VM di backend
I gruppi di istanze non gestiti nei bilanciatori del carico di rete passthrough interni sono backend principali o di failover. Puoi designare un backend come backend di failover al momento dell'aggiunta al servizio di backend o modificando il backend dopo averlo aggiunto. In caso contrario, i gruppi di istanze non gestite sono primari per impostazione predefinita.
Puoi configurare più backend principali e più backend di failover in un singolo bilanciatore del carico di rete passthrough interno aggiungendoli al servizio di backend del bilanciatore del carico.
Una VM principale è un membro di un gruppo di istanze che hai definito come backend principale. Le VM in un backend principale fanno parte del pool attivo del bilanciatore del carico (descritto nella sezione successiva), a meno che il bilanciatore del carico non inizi a utilizzare i suoi backend di failover.
Una VM di backup è un membro di un gruppo di istanze che hai definito come backend di failover. Le VM in un backend di failover partecipano al pool attivo del bilanciatore del carico quando le VM principali non sono più integre. Il numero di VM non integre che attivano il failover è una percentuale configurabile.
Limiti
VM. Puoi avere fino a 250 VM nel pool attivo. In altre parole, i gruppi di istanza di backend principali possono avere un totale di massimo 250 VM principali e i gruppi di istanza di backend di failover possono avere un totale di massimo 250 VM di backup.
Gruppi di istanze non gestite. Puoi avere fino a 50 gruppi di istanza di backend principali e fino a 50 gruppi di istanza di backend di failover.
Ad esempio, un deployment massimo potrebbe avere 5 backend principali e 5 backend di failover, con ogni gruppo di istanze contenente 50 VM.
Pool attivo
Il pool attivo è la raccolta di VM di backend a cui un bilanciatore del carico di rete passthrough interno invia nuove connessioni. L'appartenenza delle VM di backend al pool attivo viene calcolata automaticamente in base ai backend integri e alle condizioni che puoi specificare, come descritto in Rapporto di failover.
Il pool attivo non combina mai VM principali e VM di backup. I seguenti esempi chiariscono le possibilità di adesione. Durante il failover, il pool attivo contiene solo VM di backup. Durante il normale funzionamento (failback), il pool attivo contiene solo VM principali.
Failover e failback
Il failover e il failback sono i processi automatici che inseriscono o tolgono le VM di backend dal pool attivo del bilanciatore del carico. Quando Google Cloud rimuove le VM principali dal pool attivo e aggiunge VM di failover integre al pool attivo, il processo si chiama failover. Quando Google Cloud esegue l'operazione inversa, il processo è noto come failback.
Policy di failover
Un criterio di failover è un insieme di parametri utilizzati da Google Cloud per il failover e il failback. Ogni bilanciatore del carico di rete passthrough interno ha un criterio di failover con più impostazioni:
- Rapporto di failover
- Eliminazione del traffico quando tutte le VM di backend non sono integre
- Svuotamento delle connessioni al failover e al failback
Rapporto di failover
Un rapporto di failover configurabile determina quando Google Cloud esegue un failover o un failback, modificando l'appartenenza al pool attivo. Il rapporto può essere compreso tra 0.0 e 1.0, inclusi.
Se non specifichi un rapporto di failover, Google Cloud utilizza un valore predefinito di 0.0. È consigliabile impostare il rapporto di failover su un numero adatto al tuo caso d'uso anziché utilizzare questo valore predefinito.
| Condizioni | VM nel pool attivo |
|---|---|
|
Tutte le VM principali in buono stato |
Se almeno una VM di backup è integra e:
|
Tutte le VM di backup in stato integro |
| Quando tutte le VM principali e tutte le VM di backup non sono integre e non hai configurato il bilanciatore del carico in modo da eliminare il traffico in questa situazione | Tutte le VM principali, come ultima risorsa |
I seguenti esempi chiariscono l'appartenenza al pool attivo. Per un esempio con i calcoli, consulta l'esempio di failover.
- Un rapporto di failover pari a
1.0richiede che tutte le VM principali siano integre. Quando almeno una VM principale non è più integra, Google Cloud esegue un failover spostando le VM di backup nel pool attivo. - Un rapporto di failover pari a
0.1richiede che almeno il 10% delle VM principali sia integra; in caso contrario, Google Cloud esegue un failover. - Un rapporto di failover pari a
0.0indica che Google Cloud esegue un failover solo quando tutte le VM principali non sono integre. Il failover non avviene se almeno una VM principale è integra.
Un bilanciatore del carico di rete passthrough interno distribuisce le connessioni tra le VM nel pool attivo in base all'algoritmo di distribuzione del traffico.
Eliminazione del traffico quando tutte le VM di backend non sono integre
Per impostazione predefinita, quando tutte le VM principali e di backup non sono integre, Google Cloud distribuisce le nuove connessioni solo tra le VM principali. Lo fa come ultima risorsa. Le VM di backup sono escluse da questa distribuzione di ultima istanza delle connessioni.
Se preferisci, puoi configurare il bilanciatore del carico di rete passthrough interno in modo da eliminare le nuove connessioni quando tutte le VM principali e di backup non sono operative.
Svuotamento delle connessioni al failover e al failback
Lo svuotamento delle connessioni consente alle sessioni TCP esistenti di rimanere attive per un periodo di tempo configurabile anche dopo che le VM di backend non sono più in stato integro. Se il protocollo del bilanciatore del carico è TCP, vale quanto segue:
Per impostazione predefinita, lo svuotamento della connessione è attivo. Le sessioni TCP esistenti possono persistere su una VM di backend per un massimo di 300 secondi (5 minuti), anche se la VM di backend non è più in stato operativo o non è nel pool attivo del bilanciatore del carico.
Puoi disattivare lo svuotamento della connessione durante gli eventi di failover e failback. La disattivazione dello svuotamento della connessione durante il failover e il failback garantisce che tutte le sessioni TCP, incluse quelle stabilite, vengano terminate rapidamente. Le connessioni alle VM di backend potrebbero essere chiuse con un pacchetto di reimpostazione TCP.
La disattivazione svuotamento della connessione al failover e al failback è utile per scenari come i seguenti:
Applicare patch alle VM di backend. Prima di applicare i patch, configura le VM principali in modo che non superino i controlli di integrità in modo che il bilanciatore del carico esegua un failover. La disattivazione svuotamento della connessione garantisce che tutte le connessioni vengano spostate nelle VM di backup in modo rapido e pianificato. In questo modo puoi installare gli aggiornamenti e riavviare le VM principali senza che le connessioni esistenti vengano mantenute. Dopo l'applicazione del patch, Google Cloud può eseguire un failback quando un numero sufficiente di VM principali (come definito dal rapporto di failover) supera i controlli di integrità.
Singola VM di backend per la coerenza dei dati. Se devi assicurarti che solo una VM primaria sia la destinazione di tutte le connessioni, disattiva svuotamento della connessione in modo che il passaggio da una VM principale a una VM di backup non consenta alle connessioni esistenti di persistere su entrambe. In questo modo si riduce la possibilità di incoerenze dei dati mantenendo attiva una sola VM di backend alla volta.
Esempio di failover
L'esempio seguente descrive il comportamento di failover per l'esempio di bilanciatore del carico di rete passthrough interno multizona presentato nella sezione Architettura.
I backend principali per questo bilanciatore del carico sono i gruppi di istanze non gestite ig-a in us-west1-a e ig-d in us-west1-c. Ogni gruppo di istanze contiene
due VM. Tutte e quattro le VM di entrambi i gruppi di istanze sono VM principali:
vm-a1inig-avm-a2inig-avm-d1inig-dvm-d2inig-d
I backend di failover per questo bilanciatore del carico sono i gruppi di istanze non gestite ig-b in us-west1-a e ig-c in us-west1-c. Ogni gruppo di istanze contiene
due VM. Tutte e quattro le VM di entrambi i gruppi di istanze sono VM di backup:
vm-b1inig-bvm-b2inig-bvm-c1inig-cvm-c2inig-c
Supponiamo che tu voglia configurare un criterio di failover per questo bilanciatore del carico in modo che le nuove connessioni vengano inviate alle VM di backup quando il numero di VM principali integre è inferiore a due. Per farlo, imposta il rapporto di failover su 0.5
(50%). Google Cloud utilizza il rapporto di failover per calcolare il numero minimo di VM principali che devono essere in stato integro moltiplicando il rapporto di failover per il numero di VM principali: 4 × 0.5 = 2
Quando tutte e quattro le VM principali sono integre, Google Cloud distribuisce le nuove connessioni a tutte. Quando le VM principali non superano i controlli di integrità:
Se
vm-a1evm-d1non sono più in stato di salute, Google Cloud distribuisce le nuove connessioni tra le due VM principali integre rimanenti,vm-a2evm-d2, perché il numero di VM principali integre è almeno pari al numero minimo.Se anche
vm-a2non supera i controlli di integrità, rimane solo una VM principale integra,vm-d2Google Cloud riconosce che il numero di VM principali integrate è inferiore al minimo, quindi esegue un failover. Il pool attivo è impostato sulle quattro VM di backup integre e le nuove connessioni vengono distribuite tra queste quattro (nei gruppi di istanzeig-beig-c). Anche sevm-d2rimane integra, viene rimossa dal pool attivo e non riceve nuove connessioni.Se
vm-a2si riprende e supera il controllo di integrità, Google Cloud riconosce che il numero di VM principali integre è almeno pari al numero minimo di due, quindi esegue un failback. Il pool attivo è impostato sulle due VM principali integre,vm-a2evm-d2, e le nuove connessioni vengono distribuite tra di esse. Tutte le VM di backup vengono rimosse dal pool attivo.Quando le altre VM principali si riprendono e superano i controlli di integrità, Google Cloud li aggiunge al pool attivo. Ad esempio, se
vm-a1diventa integra, Google Cloud imposta il pool attivo sulle tre VM principali integre,vm-a1,vm-a2evm-d2, e distribuisce le nuove connessioni tra di esse.
Passaggi successivi
- Per configurare e testare un bilanciatore del carico di rete passthrough interno che utilizza il failover, consulta Configurare il failover per i bilanciatori del carico di rete passthrough interni.
- Per configurare e testare un bilanciatore del carico di rete passthrough interno, consulta Configura un bilanciatore del carico di rete passthrough interno.
- Per risolvere i problemi di failover del bilanciatore del carico di rete passthrough interno, consulta Risolvere i problemi relativi ai bilanciatori del carico di rete passthrough interni.