Puoi configurare un bilanciatore del carico di rete passthrough esterno basato su servizio di backend per distribuire le connessioni tra le istanze di macchine virtuali (VM) nei backend primari e quindi passare, se necessario, all'utilizzo dei backend failover. Il failover offre un metodo per aumentare la disponibilità e allo stesso tempo offre un maggiore controllo su come gestire il carico di lavoro quando le VM di backend principali non sono integri.
Questa pagina descrive concetti e requisiti specifici del failover per i bilanciatori del carico di rete passthrough esterni. Assicurati di conoscere le informazioni concettuali riportate nei seguenti articoli prima di configurare il failover per il bilanciatore del carico di rete passthrough esterno:
- Panoramica del bilanciatore del carico di rete passthrough esterno
- Panoramica dei controlli di integrità
È importante comprendere questi concetti, poiché 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 è un backend principale. Puoi designare un backend come backend di failover aggiungendolo 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 un rapporto configurabile di VM primarie non ha superato i controlli di integrità.
Backend supportati
I gruppi di istanze (gestite e non gestite) e i NEG a livello di zona (con GCE_VM_IP endpoint) sono supportati come backend. Per semplicità, gli esempi in questa pagina mostrano
i gruppi di istanze non gestite.
L'utilizzo di gruppi di istanze gestite con scalabilità automatica e failover potrebbe causare ripetuti failover e failover del pool attivo tra il backend primario e quello 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 illustra 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 primari 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 principali 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 di entrambi i backend di failover diventano attive. Per una spiegazione completa di come funziona il failover in questo esempio, consulta l'esempio di failover.
VM e gruppi di istanze di backend
I gruppi di istanze nei bilanciatori del carico di rete passthrough esterni sono backend primari o di failover. Puoi designare un backend come failover nel momento in cui lo aggiungi al servizio di backend o modificando il backend dopo averlo aggiunto. In caso contrario, i gruppi di istanze sono principali per impostazione predefinita.
Puoi configurare più backend primari e più backend di failover in un singolo 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 da te definito come backend principale. Le VM in un backend principale partecipano al pool attivo del bilanciatore del carico (descritto nella prossima sezione), a meno che il bilanciatore del carico non passi ai propri backend di failover.
Una VM di backup è un membro di un gruppo di istanze da te definito come backend di failover. Le VM in un backend di failover partecipano al pool attivo del bilanciatore del carico quando le VM principali sono in stato non integro. Il numero di VM primarie in stato non integro 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 di istanza di backend di failover.
Pool attivo
Il pool attivo è la raccolta di VM di backend a cui un bilanciatore del carico di rete passthrough esterno invia nuove connessioni. L'appartenenza alle VM di backend nel pool attivo viene calcolata automaticamente in base ai backend in stato integro e alle condizioni che puoi specificare, come descritto in Criterio di failover.
Il pool attivo non combina mai le VM principali e le VM di backup. I seguenti esempi chiariscono le possibilità di appartenenza. 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 failover
Failover e failback sono i processi automatici che spostano le VM di backend all'interno o all'esterno del 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 è chiamato failover. Quando Google Cloud la inverte, il processo è chiamato failback.
Criterio di failover
Un criterio di failover è una raccolta di parametri che Google Cloud utilizza per il failover e il failover. Ogni bilanciatore del carico di rete passthrough esterno 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 della connessione 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 l'appartenenza 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 consiste nel impostare il rapporto di failover su un numero adatto al tuo caso d'uso anziché utilizzare questo valore predefinito.
| Condizioni | VM in pool attivo |
|---|---|
|
Tutte le VM primarie in stato integro |
Se almeno una VM di backup è integro e:
|
Tutte le VM di backup integri |
| Quando tutte le VM principali e tutte le VM di backup sono in stato non integro e non hai configurato il bilanciatore del carico in modo da interrompere il traffico durante questa situazione | Tutte le VM principali, come ultima risorsa |
I seguenti esempi chiariscono l'appartenenza al pool attivo. Per un esempio di calcolo, vedi l'esempio di failover.
- Un rapporto di failover
1.0richiede che tutte le VM primarie siano integri. Quando almeno una VM principale non è integro, Google Cloud esegue un failover, spostando le VM di backup nel pool attivo. - Un rapporto di failover
0.1richiede che almeno il 10% delle VM principali sia integro, altrimenti Google Cloud esegue un failover. - Un rapporto di failover
0.0indica che Google Cloud esegue un failover solo quando tutte le VM principali non sono integri. Il failover non si verifica se almeno una VM principale è integro.
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 sono in stato non integro
Per impostazione predefinita, quando tutte le VM principali e di backup non sono integri, Google Cloud distribuisce le nuove connessioni su tutte le VM principali. Lo fa come ultima risorsa.
Se preferisci, puoi configurare il bilanciatore del carico di rete passthrough esterno in modo da rimuovere le nuove connessioni quando tutte le VM principali e di backup sono in stato non integro.
Svuotamento della connessione in caso di failover e failover
Se svuotamento della connessione è abilitato per il criterio di failover, le connessioni stabilite alle istanze dei gruppi di istanze primarie o di failover continuano a essere inviate alle istanze con cui sono state stabilite, anche dopo il failover o il failover, impedendo così l'interruzione della connessione. Se lo svuotamento della connessione è disabilitato per il criterio di failover, tutte le connessioni esistenti vengono terminate immediatamente durante il failover o il failover.
Se il protocollo del bilanciatore del carico è TCP, si verifica quanto segue:
Lo svuotamento della connessione è abilitato per impostazione predefinita. Le sessioni TCP esistenti possono persistere sulle VM di backend attuali anche se la VM di backend non si trova nel 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 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 dello svuotamento della connessione in caso di failover e failover è 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à affinché il bilanciatore del carico esegua un failover. La disabilitazione svuotamento della connessione garantisce che tutte le connessioni vengano spostate rapidamente e in modo pianificato nelle VM di backup. In questo modo puoi installare aggiornamenti e riavviare le VM principali senza che le connessioni esistenti rimangano. Dopo l'applicazione di patch, Google Cloud può eseguire un failover quando un numero sufficiente di VM primarie (come definito dal rapporto di failover) supera i controlli di integrità.
Singolo VM di backend per coerenza dei dati. Se devi assicurarti che una sola VM sia la destinazione per tutte le connessioni, disabilita svuotamento della connessione in modo che il passaggio da una VM principale a una VM di backup non consenta la persistenza delle connessioni esistenti su entrambe. Questo riduce la possibilità di incoerenze nei dati mantenendo attiva una sola VM di backend in un determinato momento.
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 architecture.
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
Supponi di voler configurare un criterio di failover per questo bilanciatore del carico in modo che le nuove connessioni vengano consegnate alle VM di backup quando il numero di VM primarie integre è inferiore a due. A questo scopo, imposta il rapporto di failover su 0.5
(50%). Google Cloud utilizza questo rapporto per calcolare il numero minimo
di VM primarie che devono essere in stato integro moltiplicando il rapporto di failover per il
numero di VM primarie: 4 × 0.5 = 2
Se tutte e quattro le VM principali sono integri, Google Cloud distribuisce a tutte le nuove connessioni. Quando le VM principali non superano i controlli di integrità:
Se
vm-a1evm-d1non sono integri, Google Cloud distribuisce nuove connessioni tra le due VM principali in stato integro,vm-a2evm-d2, perché il numero di VM primarie in stato integro è almeno il minimo.Se anche
vm-a2non supera i controlli di integrità, lasciando una sola VM principale in stato integro,vm-d2, Google Cloud riconosce che il numero di VM primarie integre è inferiore al minimo, perciò esegue un failover. Il pool attivo è impostato sulle quattro VM di backup integri 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-a2recupera e supera il controllo di integrità, Google Cloud riconosce che il numero di VM primarie in stato integro è almeno il minimo di due, quindi esegue un failover. Il pool attivo è impostato sulle due VM principali in stato integro,vm-a2evm-d2, e le nuove connessioni vengono distribuite tra loro. Tutte le VM di backup vengono rimosse dal pool attivo.Man mano che 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 in stato integro,vm-a1,vm-a2evm-d2, e distribuisce tra di loro le nuove connessioni.
Passaggi successivi
- Per configurare e testare un bilanciatore del carico di rete passthrough esterno che utilizza il failover, consulta Configurazione del failover per bilanciatori del carico di rete passthrough esterni.
- Per configurare e testare un bilanciatore del carico di rete passthrough esterno con un servizio di backend, vedi Configurare un bilanciatore del carico di rete passthrough esterno.