Puoi configurare un bilanciatore del carico di rete passthrough interno per distribuire le connessioni tra VM di Compute Engine nei backend primari e, se necessario, di passare alle istanze utilizzando backend di failover. Il failover offre un metodo per aumentare e al tempo stesso ti offre un maggiore controllo su come gestire i tuoi del carico di lavoro quando le VM di backend principali non sono integre.
In questa pagina vengono descritti concetti e requisiti specifici del failover per bilanciatori del carico di rete passthrough interni. Assicurati di conoscere bene i concetti informazioni nei seguenti articoli prima di configurare il failover per bilanciatori del carico di rete passthrough interni:
- Panoramica del bilanciatore del carico di rete passthrough interno
- Panoramica dei controlli di integrità
È importante comprendere questi concetti, in quanto la configurazione del failover la distribuzione standard del traffico del bilanciatore del carico di rete passthrough interno algoritmo.
Per impostazione predefinita, quando aggiungi un backend al 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, oppure in un secondo momento. I backend di failover ricevono connessioni solo dal bilanciatore del carico dopo che un rapporto configurabile di VM primarie 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 i gruppi di istanze non gestite.
L'uso dei gruppi di istanze gestite con scalabilità automatica e failover potrebbe causare pool attivo per failover e failover ripetuti tra il backend principale e quello di failover. Google Cloud non ti impedisce configurando il failover con gruppi di istanze gestite, perché il deployment vantaggi di questa configurazione.
Architettura
Il seguente semplice esempio mostra un bilanciatore del carico di rete passthrough interno con uno principale e uno di failover.
- Il backend principale è un gruppo di istanze non gestite in
us-west1-a. - Il backend di failover è un diverso gruppo di istanze non gestite in
us-west1-c.
L'esempio seguente mostra un bilanciatore del carico di rete passthrough interno con due
e due backend di failover, entrambi distribuiti tra due zone
Regione us-west1. Questa configurazione aumenta l'affidabilità perché
dipendono da una singola zona per tutti i backend primari o per tutti i backend di failover.
- I backend principali sono i 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 diventano attivi entrambi i backend di failover. Per una spiegazione completa di come il failover vedi l'esempio di failover.
Gruppi di istanze di backend e VM
I gruppi di istanze non gestite nei bilanciatori del carico di rete passthrough interni sono o di failover primari. Puoi designare un backend come al backend di failover nel momento in cui lo aggiungi al servizio di backend di modificare il backend dopo l'aggiunta. In caso contrario, i gruppi di istanze non gestite principale per impostazione predefinita.
Puoi configurare più backend primari e più backend di failover in un 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 un il backend principale. Le VM in un backend principale partecipano pool attivo (descritto nella sezione successiva), a meno che il bilanciatore del carico non cambi all'uso dei suoi backend di failover.
Una VM di backup è un membro di un gruppo di istanze che hai definito come un di failover. Le VM in un backend di failover partecipano al carico pool attivo del bilanciatore quando le VM principali non sono integre. Il numero di per VM non integre che attivano il failover è una percentuale configurabile.
Limiti
VM. Nel pool attivo possono essere presenti fino a 250 VM. In altre parole, i gruppi di istanza di backend principali possono avere un totale di 250 VM principali e i gruppi di istanza di backend di failover possono avere un totale fino a 250 VM di backup.
Gruppi di istanze non gestite. Puoi avere fino a 50 istanza di backend principali gruppi di istanze VM e fino a 50 gruppi di istanza di backend di failover.
Ad esempio, un deployment massimo può avere 5 backend primari e 5 backend di failover, in cui ogni gruppo di istanze conteneva 50 VM.
Pool attivo
Il pool attivo è la raccolta di VM di backend a cui il bilanciatore del carico di rete passthrough interno invia nuove connessioni. Appartenenza delle VM di backend nel attivo viene calcolato automaticamente in base ai backend in stato integro e che puoi specificare, come descritto in Rapporto di failover.
Il pool attivo non combina mai VM principali e VM di backup. Le seguenti gli esempi chiariscono le possibilità di appartenenza. Durante il failover, contiene solo VM di backup. Durante il normale funzionamento (failback), il pool attivo contiene solo VM primarie.
Failover e failover
Failover e failback sono i processi automatici che cambiano le VM di backend dentro o fuori dal pool attivo del bilanciatore del carico. Quando Google Cloud rimuove VM primarie del pool attivo e aggiunge VM di failover integre alle VM un pool, il processo è chiamato failover. Quando Google Cloud inverte, il processo è chiamato failback.
Criterio di failover
Un criterio di failover è una raccolta di parametri che Google Cloud per il failover e il failover. 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 sono in stato non integro
- Svuotamento connessioni in caso di failover e failover
Rapporto di failover
Un rapporto di failover configurabile
determina quando Google Cloud esegue un failover o un failover, modificando
nel 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. Una best practice prevede di impostare il rapporto di failover su un valore accettabile
per il tuo caso d'uso anziché fare affidamento su questa impostazione predefinita.
| Condizioni | VM nel pool attivo |
|---|---|
|
Tutte le VM principali integre |
Se almeno una VM di backup è integro e:
|
Tutte le VM di backup integre |
| Quando tutte le VM principali e tutte le VM di backup sono in stato non integro e non hai configurato il carico in modo da rilasciare il traffico durante questa operazione situazione | Tutte le VM principali, come ultima risorsa |
I seguenti esempi chiariscono l'appartenenza al pool attivo. Ad esempio, con i calcoli, vedi l'esempio di failover.
- Un rapporto di failover
1.0richiede che tutte le VM principali siano integre. Quando alle ore almeno una VM principale non è integro, Google Cloud esegue con il failover, spostando le VM di backup nel pool attivo. - Un rapporto di failover
0.1richiede che almeno il 10% delle VM principali sano; altrimenti Google Cloud esegue un failover. - Un rapporto di failover di
0.0indica che Google Cloud esegue a un failover solo se tutte le VM primarie sono in stato non integro. Il failover non se almeno una VM principale è integro.
Un bilanciatore del carico di rete passthrough interno distribuisce le connessioni tra le VM pool attivo in base alla distribuzione del traffico algoritmo.
Eliminazione del traffico quando tutte le VM di backend sono in stato non integro
Per impostazione predefinita, quando tutte le VM principali e di backup sono in stato non integro, Google Cloud distribuisce le nuove connessioni solo tra le VM principali. Lo fa come un ultima risorsa. Le VM di backup sono escluse da questa distribuzione dell'ultima istanza di e connessioni a Internet.
Se preferisci, puoi configurare il bilanciatore del carico di rete passthrough interno per ridurre nuove connessioni quando tutte le connessioni principali le VM di backup sono in stato non integro.
Svuotamento connessioni in caso di failover e failover
Lo svuotamento della connessione consente sessioni TCP esistenti affinché rimangano attive per un periodo di tempo configurabile anche quando le VM di backend sono in stato non integro. Se il protocollo per il bilanciatore del carico è TCP, quanto segue:
Per impostazione predefinita, lo svuotamento della connessione è abilitato. Le sessioni TCP esistenti possono essere persistenti su una VM di backend per un massimo di 300 secondi (5 minuti), anche se la VM non è integro o non fa parte del pool attivo del bilanciatore del carico.
Puoi disabilitare lo svuotamento della connessione durante gli eventi di failover e di failover. La disabilitazione dello svuotamento della connessione durante il failover e il failover garantisce che tutti Le sessioni TCP, incluse quelle consolidate, vengono rapidamente terminate. Connessioni alle VM di backend potrebbe essere chiuso con un pacchetto di reimpostazione TCP.
La disattivazione dello svuotamento della connessione in caso di failover e failover è utile in scenari quali:
Patch delle VM di backend. Prima di applicare la patch, configura le VM principali non superino i controlli di integrità per far sì che il bilanciatore del carico esegua un failover. La disabilitazione dello svuotamento della connessione assicura che tutte le connessioni vengano spostate eseguire il backup delle VM in modo rapido e pianificato. Ciò ti consente di installare aggiorna e riavvia le VM principali senza che le connessioni esistenti vengano mantenute. Dopo l'applicazione delle patch, Google Cloud può eseguire un failover quando è Numero di VM primarie (come definito dal rapporto di failover) che superano l'integrità controlli.
VM di backend singola per la coerenza dei dati. Se devi assicurarti che solo uno la VM principale è la destinazione per tutte le connessioni; disabilita lo svuotamento della connessione in modo che il passaggio da una VM principale a una VM di backup non consenta le connessioni in modo che rimangano su entrambi. Questo riduce la possibilità che mantenendo attiva una sola VM di backend in un determinato momento.
Esempio di failover
L'esempio seguente descrive il comportamento di failover per l'ambiente multizona esempio di bilanciatore del carico di rete passthrough interno presentato nell'architettura .
I backend primari per questo bilanciatore del carico sono i gruppi di istanze non gestite
ig-a a us-west1-a e ig-d a us-west1-c. Ogni gruppo di istanze contiene
due VM. Tutte e quattro le VM di entrambi i gruppi di istanze sono VM primarie:
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 a us-west1-a e ig-c a 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 un criterio di failover per questo bilanciatore del carico in modo che
le nuove connessioni vengono consegnate alle VM di backup quando
il numero di istanze primarie integre
è inferiore a due. A questo scopo, imposta il rapporto di failover su 0.5
(50%). Google Cloud usa il rapporto di failover per calcolare il numero minimo
numero di VM primarie che devono essere in stato integro moltiplicando il rapporto di failover per
il numero di VM principali: 4 × 0.5 = 2
Se tutte e quattro le VM principali sono in stato integro, Google Cloud distribuisce nuovi a ciascuno di loro. Quando le VM principali non superano i controlli di integrità:
Se
vm-a1evm-d1non sono integri, Google Cloud distribuisce nuovi delle connessioni tra le restanti due VM principali integre,vm-a2evm-d2, perché il numero di VM primarie integre è almeno il minimo.Se anche
vm-a2non supera i controlli di integrità, lasciando solo una VM principale integro,vm-d2, Google Cloud riconosce che il numero di VM primarie integre è inferiore al minimo, perciò esegue un failover. Il pool attivo è impostato alle quattro VM di backup integre e le nuove connessioni sono 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-a2recupera e supera il controllo di integrità, Google Cloud riconosce che il numero di VM primarie integre sia almeno pari a due, quindi esegue un failover. Il pool attivo è impostato sulle due VM principali integre,vm-a2evm-d2e le nuove connessioni sono distribuite tra di loro. Tutti le VM di backup vengono rimosse dal pool attivo.Mentre le altre VM principali recuperano 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 principali integre,vm-a1,vm-a2evm-d2e distribuisce le nuove connessioni tra di loro.
Passaggi successivi
- Per configurare e testare un bilanciatore del carico di rete passthrough interno che utilizza il failover, consulta Configura 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 con il bilanciatore del carico di rete passthrough interno, consulta Risolvi i problemi dei bilanciatori del carico di rete passthrough interni.