Puoi configurare un bilanciatore del carico di rete passthrough esterno basato su un servizio di backend per distribuire le connessioni tra le istanze di macchine virtuali (VM) nei backend primari e poi passare, se necessario, all'utilizzo dei backend di failover. Il failover fornisce un metodo per aumentare la disponibilità, offrendoti al contempo un maggiore controllo su come gestire il carico di lavoro quando le VM di backend principali non sono integre.
Questa pagina descrive i concetti e i requisiti specifici per il failover per i bilanciatori del carico di rete passthrough esterni. Prima di configurare il failover per il bilanciatore del carico di rete passthrough esterno, assicurati di avere familiarità con le informazioni concettuali contenute nei seguenti articoli:
- Panoramica del bilanciatore del carico di rete passthrough esterno
- 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.
Per impostazione predefinita, quando aggiungi un backend a un servizio di backend di un bilanciatore del carico di rete passthrough esterno, questo backend è un backend principale. Puoi designare un backend come backend di failover quando lo aggiungi al servizio di backend del bilanciatore del carico o modificando il servizio di backend 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à.
Backend supportati
Sono supportati come backend i gruppi di istanze (gestiti e non gestiti) e i NEG di zona (con endpoint GCE_VM_IP). Per semplicità, gli esempi in questa pagina
mostrano gruppi di istanze non gestite.
L'utilizzo di gruppi di istanze gestite con scalabilità automatica e failover potrebbe causare il failover e il failback ripetuti del pool attivo tra i backend primario 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
L'esempio seguente mostra un bilanciatore del carico di rete passthrough esterno 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 gruppo di istanze non gestite diverso in
us-west1-c.
L'esempio successivo mostra un bilanciatore del carico di rete passthrough esterno 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 primari o di failover.
- I backend primari sono gruppi di istanze non gestite
ig-aeig-d. - I backend di failover sono gruppi di istanze non gestite
ig-beig-c.
Durante il failover, entrambi i backend primari 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 Esempio di failover.
Gruppi di istanze e VM di backend
I gruppi di istanze nei bilanciatori del carico di rete passthrough esterni 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 l'aggiunta. In caso contrario, i gruppi di istanze sono primari per impostazione predefinita.
Puoi configurare più backend principali e più backend di failover in un unico bilanciatore del carico di rete passthrough esterno 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 partecipano al pool attivo del bilanciatore del carico (descritto nella sezione successiva), a meno che il bilanciatore del carico non passi all'utilizzo dei 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 primarie non sono più integre. Il numero di VM principali non integre che attiva il failover è una percentuale configurabile.
Limiti
- Gruppi di istanze. Puoi avere fino a 50 gruppi di istanza di backend primari e fino a 50 gruppi diistanza di backendd di failover.
Pool attivo
Il pool attivo è l'insieme di VM di backend a cui un bilanciatore del carico di rete passthrough esterno 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 Policy di failover.
Il pool attivo non combina mai VM principali e VM di backup. Gli esempi seguenti chiariscono le possibilità di abbonamento. Durante il failover, il pool attivo contiene solo VM di backup. Durante il normale funzionamento (failback), il pool attivo contiene solo VM primarie.
Failover e failback
Il failover e il failback sono i processi automatici che attivano o disattivano le VM di backend nel pool attivo del bilanciatore del carico. Quando Google Cloud rimuove le VM primarie dal pool attivo e aggiunge VM di failover integre al pool attivo, il processo viene chiamato failover. Quando Google Cloud inverte questa operazione, il processo è chiamato failback.
Policy di failover
Un criterio di failover è un insieme di parametri che Google Cloud utilizza per il failover e il failback. Ogni bilanciatore del carico di rete passthrough esterno ha una policy di failover con più impostazioni:
- Rapporto di failover
- Eliminazione del traffico quando tutte le VM di backend non sono integre
- Svuotamento della connessione 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ò variare da 0.0 a 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é fare affidamento su questo valore predefinito.
| Condizioni | VM nel pool attivo |
|---|---|
|
Tutte le VM primarie integre |
Se almeno una VM di backup è integra e:
|
Tutte le VM di backup integre |
| Quando tutte le VM principali e di backup non sono integre e non hai configurato il bilanciatore del carico per eliminare il traffico in questa situazione | Tutte le VM principali, come ultima risorsa |
Gli esempi seguenti chiariscono l'appartenenza al pool attivo. Per un esempio con i calcoli, vedi Esempio di failover.
- Un rapporto di failover pari a
1.0richiede che tutte le VM primarie siano integre. Quando almeno una VM primaria 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 primarie sia integro; in caso contrario, Google Cloud esegue un failover. - Un rapporto di failover pari a
0.0significa che Google Cloud esegue un failover solo quando tutte le VM primarie non sono integre. Il failover non si verifica se almeno una VM primaria è integra.
Un bilanciatore del carico di rete passthrough esterno 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 primarie e di backup non sono integre, Google Cloud distribuisce le nuove connessioni tra tutte le VM primarie. Lo fa come ultima risorsa.
Se preferisci, puoi configurare il bilanciatore del carico di rete passthrough esterno in modo che elimini le nuove connessioni quando tutte le VM primarie e di backup non sono integre.
Svuotamento della connessione al failover e al failback
Quando svuotamento della connessione è attivato per la policy di failover, le connessioni stabilite alle istanze nei gruppi di istanze principali o di failover continuano a essere inviate alle istanze con cui sono state stabilite, anche dopo il failover o il failback, impedendo così l'interruzione della connessione. Quando lo svuotamento della connessione è disattivato per il criterio di failover, tutte le connessioni esistenti vengono terminate immediatamente durante il failover o il failback.
Se il protocollo per il bilanciatore del carico è TCP, vale quanto segue:
Per impostazione predefinita, lo svuotamento della connessione è attivo. Le sessioni TCP esistenti possono essere mantenute sulle VM di backend attuali anche se la VM di backend non si trova nel pool attivo del bilanciatore del carico.
Puoi disattivare lo svuotamento della connessione durante gli eventi di failover e failback. La disattivazione 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 svuotamento della connessione al failover e al failback è utile per scenari come i seguenti:
Applicazione di patch alle VM di backend. Prima di applicare le 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 rapidamente e in modo pianificato alle VM di backup. In questo modo puoi installare gli aggiornamenti e riavviare le VM primarie senza che le connessioni esistenti persistano. Dopo l'applicazione della 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 sia la destinazione di tutte le connessioni, disattiva svuotamento della connessione in modo che il passaggio da una VM primaria a una 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 esterno 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 di voler configurare una policy di failover per questo bilanciatore del carico in modo che
le nuove connessioni vengano inviate alle VM di backup quando il numero di VM primarie 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 primarie che devono essere integre moltiplicando il rapporto di failover per
il numero di VM primarie: 4 × 0.5 = 2
Quando tutte e quattro le VM primarie sono integre, Google Cloud distribuisce le nuove connessioni a tutte. Quando le VM primarie non superano i controlli di integrità:
Se
vm-a1evm-d1diventano non integri, Google Cloud distribuisce le nuove connessioni tra le due VM primarie integre rimanenti,vm-a2evm-d2, perché il numero di VM primarie integre è almeno pari al minimo.Se anche
vm-a2non supera i controlli di integrità, lasciando una sola VM primaria integra,vm-d2, Google Cloud riconosce che il numero di VM primarie integre è 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 integro, viene rimosso dal pool attivo e non riceve nuove connessioni.Se
vm-a2viene ripristinato e supera il controllo di integrità, Google Cloud riconosce che il numero di VM primarie integre è almeno il minimo di due, quindi esegue un failback. Il pool attivo è impostato sulle due VM primarie integre,vm-a2evm-d2, e le nuove connessioni vengono distribuite tra queste. Tutte le VM di backup vengono rimosse dal pool attivo.Man mano che le altre VM principali vengono ripristinate e superano i controlli di integrità, Google Cloud le aggiunge al pool attivo. Ad esempio, se
vm-a1diventa integro, Google Cloud imposta il pool attivo sulle tre VM primarie integre,vm-a1,vm-a2evm-d2, e distribuisce le nuove connessioni tra queste.
Passaggi successivi
- Per configurare e testare un bilanciatore del carico di rete passthrough esterno che utilizza il failover, consulta Configurazione del failover per i bilanciatori del carico di rete passthrough esterni.
- Per configurare e testare un bilanciatore del carico di rete passthrough esterno con un servizio di backend, consulta Configura un bilanciatore del carico di rete passthrough esterno.