Pattern per l'utilizzo di indirizzi IP mobili in Compute Engine

Questo documento descrive come utilizzare i pattern di implementazione degli indirizzi IP mobili durante la migrazione delle applicazioni a Compute Engine da un ambiente di rete on-premise. Questo documento è rivolto a ingegneri di rete, amministratori di sistema e ingegneri delle operazioni che eseguono la migrazione delle applicazioni aGoogle Cloud.

Chiamati anche indirizzi IP condivisi o virtuali, gli indirizzi IP mobili vengono spesso utilizzati per rendere gli ambienti di rete on-premise a disponibilità elevata. Utilizzando indirizzi IP mobili, puoi trasferire un indirizzo IP tra più server fisici o virtuali configurati in modo identico. Questa pratica consente il failover o l'upgrade del software di produzione. Tuttavia, non puoi implementare direttamente gli indirizzi IP mobili in un ambiente Compute Engine senza modificare l'architettura in uno dei pattern descritti in questo documento.

Il repository GitHub che accompagna questo documento include deployment di esempio per ogni pattern che puoi eseguire automaticamente utilizzando Terraform.

Indirizzi IP mobili negli ambienti on-premise

Gli indirizzi IP mobili vengono comunemente utilizzati negli ambienti on-premise. Ecco alcuni esempi di casi d'uso:

Esistono diversi modi per implementare gli indirizzi IP mobili in un ambiente on-premise. I server che condividono indirizzi IP mobili in genere condividono anche le informazioni sullo stato tramite un meccanismo heartbeat. Questo meccanismo consente ai server di comunicare tra loro il proprio stato di integrità e al server secondario di assumere il controllo dell'indirizzo IP mobile dopo l'errore del server primario. Questo schema viene spesso implementato utilizzando il Virtual Router Redundancy Protocol, ma puoi utilizzare anche altri meccanismi simili.

Una volta avviato il failover dell'indirizzo IP, il server che acquisisce l'indirizzo IP mobile lo aggiunge alla propria interfaccia di rete. Il server annuncia questa acquisizione ad altri dispositivi utilizzando il livello 2 inviando un frame ARP (Address Resolution Protocol) gratuito. In alternativa, a volte un protocollo di routing come Open Shortest Path First (OSPF) annuncia l'indirizzo IP al router di livello 3 upstream.

Il seguente diagramma mostra una configurazione tipica in un ambiente on-premise.

Tipico ambiente on-premise.

Il diagramma precedente mostra come un server principale e un server secondario collegati allo stesso switch scambiano informazioni sulla reattività tramite un meccanismo di heartbeat. Se il server principale non funziona, il server secondario invia un frame ARP gratuito allo switch per acquisire l'indirizzo IP mobile.

Utilizzi una configurazione leggermente diversa con soluzioni di bilanciamento del carico on-premise, come Windows Network Load Balancing o un bilanciamento del carico Linux con risposta diretta del server come IPVS. In questi casi, il servizio invia anche frame ARP gratuiti, ma con l'indirizzo MAC di un altro server come origine ARP gratuita. Questa azione esegue essenzialmente lo spoofing dei frame ARP e assume il controllo dell'indirizzo IP di origine di un altro server.

Questa azione viene eseguita per distribuire il carico di un indirizzo IP tra server diversi. Tuttavia, questo tipo di configurazione non rientra nell'ambito di questo documento. In quasi tutti i casi in cui gli indirizzi IP mobili vengono utilizzati per il bilanciamento del carico on-premise, è preferibile la migrazione a Cloud Load Balancing.

Sfide relative alla migrazione di indirizzi IP mobili a Compute Engine

Compute Engine utilizza uno stack di rete virtualizzato in una rete Virtual Private Cloud (VPC), pertanto i meccanismi di implementazione tipici non funzionano senza modifiche inGoogle Cloud. Ad esempio, la rete VPC gestisce le richieste ARP nella rete definita dal software e ignora i frame ARP gratuiti. Inoltre, è impossibile modificare direttamente la tabella di routing della rete VPC con protocolli di routing standard come OSPF o Border Gateway Protocol (BGP). I meccanismi tipici per gli indirizzi IP mobili si basano sulla gestione delle richieste ARP da parte dell'infrastruttura di commutazione oppure su reti programmabili da OSPF o BGP. Pertanto, il failover degli indirizzi IP non viene eseguito utilizzando questi meccanismi in Google Cloud. Se esegui la migrazione di un'immagine di macchina virtuale (VM) utilizzando un indirizzo IP mobile on-premise, il failover dell'indirizzo IP mobile non può essere eseguito senza modificare l'applicazione.

Puoi utilizzare una rete di overlay per creare una configurazione che consenta la comunicazione completa di livello 2 e l'acquisizione IP tramite richieste ARP. Tuttavia, la configurazione di una rete di overlay è complessa e rende difficile la gestione delle risorse di rete di Compute Engine. Questo approccio non rientra nell'ambito di questo documento. Questo documento descrive invece i pattern per l'implementazione di scenari di failover in un ambiente di rete Compute Engine senza creare reti overlay.

Per implementare applicazioni affidabili e a disponibilità elevata in Compute Engine, utilizza architetture di scalabilità orizzontale. Questo tipo di architettura riduce al minimo l'effetto di un errore di un singolo nodo.

Questo documento descrive diversi pattern per eseguire la migrazione di un'applicazione esistente utilizzando indirizzi IP mobili dall'ambiente on-premise a Compute Engine, tra cui:

L'utilizzo di indirizzi IP alias che si spostano tra le istanze VM è sconsigliato come meccanismo di failover perché non soddisfa i requisiti di alta disponibilità. In alcuni scenari di errore, ad esempio un evento di errore zonale, potresti non essere in grado di rimuovere un indirizzo IP alias da un'istanza. Pertanto, potresti non essere in grado di aggiungerlo a un'altra istanza, rendendo impossibile il failover.

Selezionare un pattern per il tuo caso d'uso

A seconda dei tuoi requisiti, uno o più dei pattern descritti in questa soluzione potrebbero essere utili per implementare indirizzi IP mobili in un ambiente on-premise.

Quando decidi quale pattern ti consente di utilizzare al meglio un'applicazione, prendi in considerazione i seguenti fattori:

  • Indirizzo IP interno o esterno mobile:la maggior parte delle applicazioni che richiedono indirizzi IP mobili utilizza indirizzi IP interni mobili. Poche applicazioni utilizzano indirizzi IP esterni mobili, perché in genere il traffico verso le applicazioni esterne deve essere bilanciato del carico.

    La tabella più avanti in questa sezione consiglia i pattern che puoi utilizzare per gli indirizzi IP interni mobili e per gli indirizzi IP esterni mobili. Per i casi d'uso che si basano su indirizzi IP interni mobili, uno qualsiasi di questi pattern potrebbe essere adatto alle tue esigenze. Tuttavia, consigliamo di eseguire la migrazione dei casi d'uso che si basano su indirizzi IP esterni mobili a uno dei pattern che utilizzano il bilanciamento del carico.

  • Protocolli applicativi:se la tua VM utilizza solo TCP e UDP, puoi utilizzare tutti i pattern nella tabella. Se utilizza altri protocolli oltre a IPv4 per connettersi, sono appropriati solo alcuni pattern.

  • Compatibilità con il deployment active-active:alcune applicazioni, durante l'utilizzo di indirizzi IP mobili on-premise, possono funzionare in una modalità di deployment active-active. Questa funzionalità significa che non è necessario il failover dal server principale a quello secondario. Hai più scelte di pattern per spostare questi tipi di applicazioni su Compute Engine. Le applicazioni che richiedono un solo server delle applicazioni per ricevere traffico in qualsiasi momento non sono compatibili con il deployment attivo-attivo. Puoi implementare queste applicazioni solo con alcuni pattern nella tabella seguente.

  • Comportamento di failback dopo il ripristino della VM primaria: quando la VM primaria originale viene ripristinata dopo un failover, a seconda del pattern utilizzato, il traffico esegue una delle due operazioni. Torna immediatamente alla VM primaria originale o rimane sulla nuova VM primaria finché non viene avviato manualmente il failback o la nuova VM primaria non funziona. In tutti i casi, solo le connessioni avviate di recente vengono sottoposte a failback. Le connessioni esistenti rimangono nella nuova VM primaria finché non vengono chiuse.

  • Compatibilità del controllo di integrità:se non riesci a verificare se la tua applicazione risponde utilizzando i controlli di integrità di Compute Engine senza difficoltà, non puoi utilizzare alcuni pattern descritti nella tabella seguente.

  • Gruppi di istanze:qualsiasi pattern con compatibilità del controllo di integrità è compatibile anche con i gruppi di istanze. Per ricreare automaticamente le istanze non riuscite, puoi utilizzare un gruppo di istanze gestite con riparazione automatica. Se le tue VM mantengono lo stato, puoi utilizzare un gruppo di istanze gestite stateful. Se le VM non possono essere ricreate automaticamente o se è necessario un failover manuale, utilizza un gruppo di istanze non gestite e ricrea manualmente le VM durante il failover.

  • Meccanismi di heartbeat esistenti: se la configurazione di alta affidabilità per la tua applicazione utilizza già un meccanismo di heartbeat per attivare il failover, come Heartbeat, Pacemaker o Keepalived, puoi utilizzare alcuni pattern descritti nella tabella seguente.

La tabella seguente elenca le funzionalità dei pattern. Ogni pattern è descritto nelle sezioni seguenti:

Nome pattern Indirizzo IP Protocolli supportati Modalità di deployment Failback Compatibilità del controllo di integrità delle applicazioni richiesta Può integrare il meccanismo heartbeat
Pattern che utilizzano il bilanciamento del carico
Bilanciamento del carico attivo-attivo Interno o esterno Solo TCP/UDP Attivo-attivo N/D Sì No
Bilanciamento del carico con failover e controlli di integrità esposti all'applicazione Interno o esterno Solo TCP/UDP Attivo-passivo Immediato (tranne le connessioni esistenti) Sì No
Bilanciamento del carico con failover e controlli di integrità esposti heartbeat Interno o esterno Solo TCP/UDP Attivo-passivo Configurabile No Sì
Pattern che utilizzano Google Cloud le route
Utilizzo delle route ECMP Interno Tutti i protocolli IP Attivo-attivo N/D Sì No
Utilizzare route prioritarie diverse Interno Tutti i protocolli IP Attivo-passivo Immediato (tranne le connessioni esistenti) Sì No
Utilizzo di un meccanismo di heartbeat per cambiare l'hop successivo della route Interno Tutti i protocolli IP Attivo-passivo Configurabile No Sì
Pattern che utilizza l'autoriparazione
Utilizzo di una singola istanza con funzionalità di riparazione automatica Interno Tutti i protocolli IP N/D N/D Sì No

La scelta del pattern da utilizzare per il tuo caso d'uso potrebbe dipendere da diversi fattori. Il seguente albero decisionale può aiutarti a restringere le scelte a un'opzione adatta.

Un albero decisionale che ti aiuta a scegliere un bilanciatore del carico.

Il diagramma precedente illustra i seguenti passaggi:

  1. Una singola istanza di riparazione automatica fornisce una disponibilità sufficiente per le tue esigenze?
    1. In caso affermativo, consulta Utilizzo di una singola istanza con funzionalità di riparazione automatica più avanti in questo documento. La riparazione automatica utilizza un meccanismo in un gruppo di istanze VM per sostituire automaticamente un'istanza VM difettosa.
    2. In caso contrario, vai al punto decisionale successivo.
  2. La tua applicazione ha bisogno di protocolli diversi da TCP e UDP su IPv4?
    1. In caso affermativo, vai al punto decisionale successivo.
    2. In caso contrario, vai al punto decisionale successivo.
  3. La tua applicazione può funzionare in modalità active-active?
    1. Se la risposta è sì e sono necessari protocolli diversi da TCP e UDP su IPv4, consulta Utilizzo di route ECMP (Equal-Cost Multipath) più avanti in questo documento. Le route ECMP distribuiscono il traffico tra gli hop successivi di tutte le route candidate.
    2. Se la risposta è sì e non sono necessari protocolli aggiuntivi a IPv4 oltre a TCP e UDP, consulta Bilanciamento del carico attivo-attivo più avanti in questo documento. Il bilanciamento del carico attivo-attivo utilizza le VM come backend per un bilanciatore del carico TCP/UDP interno.
    3. In caso contrario, vai al punto decisionale successivo.
  4. La tua applicazione può esporre controlli di integrità Google Cloud ?
    1. In caso affermativo e se non sono necessari protocolli aggiuntivi a IPv4 oltre a TCP e UDP, consulta Bilanciamento del carico con failover e controlli di integrità esposti all'applicazione più avanti in questo documento. Il bilanciamento del carico con failover e i controlli di integrità esposti all'applicazione utilizzano le tue VM come backend per un bilanciatore del carico TCP/UDP interno. Utilizza anche l'indirizzo IP del bilanciamento del carico TCP/UDP interno come indirizzo IP virtuale.
    2. In caso affermativo e se sono necessari protocolli diversi da TCP e UDP su IPv4, consulta la sezione Utilizzo di route con priorità diverse più avanti in questo documento. L'utilizzo di route con priorità diverse contribuisce a garantire che il traffico venga sempre indirizzato a un'istanza principale, a meno che non si verifichi un errore.
    3. In caso contrario, se sono necessari protocolli diversi da TCP e UDP su IPv4, consulta Bilanciamento del carico con failover e controlli di integrità esposti heartbeat più avanti in questo documento. Nel pattern di bilanciamento del carico con failover e controlli di integrità esposti tramite heartbeat, i controlli di integrità non vengono esposti dall'applicazione stessa, ma da un meccanismo di heartbeat in esecuzione tra entrambe le VM.
    4. Se la risposta è no e NON HA BISOGNO di protocolli aggiuntivi su IPv4 diversi da TCP e UDP, vedi Utilizzo di un meccanismo di heartbeat per cambiare l'hop successivo di una route più avanti in questo documento. L'utilizzo di un meccanismo di heartbeat per cambiare l'hop successivo di una route utilizza una singola route statica con l'hop successivo che punta all'istanza VM principale.

Pattern che utilizzano il bilanciamento del carico

In genere, puoi eseguire la migrazione della tua applicazione utilizzando indirizzi IP mobili a un'architettura in Google Cloud che utilizza Cloud Load Balancing. Puoi utilizzare un bilanciatore del carico di rete passthrough interno, in quanto questa opzione si adatta alla maggior parte dei casi d'uso in cui il servizio di cui è stata eseguita la migrazione on-premise è esposto solo internamente. Questa opzione di bilanciamento del carico viene utilizzata per tutti gli esempi in questa sezione e nei deployment di esempio su GitHub. Se hai client che accedono all'indirizzo IP mobile da altre regioni, seleziona l'opzione di accesso globale.

Se la tua applicazione comunica utilizzando protocolli basati su IPv4 diversi da TCP o UDP, devi scegliere un pattern che non utilizzi il bilanciamento del carico. Questi pattern sono descritti più avanti in questo documento.

Se la tua applicazione utilizza HTTP(S), puoi utilizzare un bilanciatore del carico delle applicazioni interno per implementare il pattern attivo-attivo.

Se il servizio di cui stai tentando di eseguire la migrazione è disponibile esternamente, puoi implementare tutti i pattern descritti in questa sezione utilizzando un bilanciatore del carico di rete passthrough esterno. Per i deployment active-active, puoi utilizzare anche un bilanciatore del carico delle applicazioni esterno, un proxy TCP o un proxy SSL se la tua applicazione utilizza protocolli e porte supportati da queste opzioni di bilanciamento del carico.

Considera le seguenti differenze tra le implementazioni on-premise basate su indirizzi IP mobili e tutti i pattern basati sul bilanciamento del carico:

  • Tempo di failover: l'accoppiamento di Keepalived con ARP gratuito in un ambiente on-premise potrebbe eseguire il failover di un indirizzo IP in pochi secondi. Nell'ambiente Compute Engine, il tempo medio di ripristino dal failover dipende dai parametri che imposti. Nel caso in cui l'istanza di macchina virtuale (VM) o il servizio di istanza VM non vada a buon fine, il tempo medio al failover del traffico dipende dai parametri del controllo di integrità, come Check Interval e Unhealthy Threshold. Con questi parametri impostati sui valori predefiniti, il failover richiede in genere 15-20 secondi. Puoi ridurre il tempo diminuendo i valori dei parametri.

    In Compute Engine, i failover all'interno delle zone o tra le zone richiedono lo stesso tempo.

  • Protocolli e porte:in una configurazione on-premise, gli indirizzi IP mobili accettano tutto il traffico. Scegli una delle seguenti specifiche di porta nella regola di forwarding interna per il bilanciatore del carico di rete passthrough interno:

    • Specifica almeno una porta e fino a cinque porte per numero.
    • Specifica ALL per inoltrare il traffico su tutte le porte per TCP o UDP.
    • Utilizza più regole di forwarding con lo stesso indirizzo IP per inoltrare un mix di traffico TCP e UDP o per utilizzare più di cinque porte con un singolo indirizzo IP:
      • Solo TCP o UDP e 1-5 porte: utilizza una regola di forwarding.
      • TCP e UDP e 1-5 porte: utilizza più regole di forwarding.
      • 6 o più porte e TCP o UDP: utilizza più regole di forwarding.

  • Controllo di integrità:on-premise, puoi controllare la reattività dell'applicazione su una macchina nei seguenti modi:

Bilanciamento del carico attivo-attivo

Nel pattern di bilanciamento del carico attivo-attivo, le VM sono backend per un bilanciatore del carico di rete passthrough interno. Utilizzi l'indirizzo IP del bilanciatore del carico di rete passthrough interno come indirizzo IP virtuale. Il traffico viene distribuito equamente tra le due istanze di backend. Il traffico appartenente alla stessa sessione viene indirizzato alla stessa istanza di backend come definito nelle impostazioni di affinità sessione.

Utilizza il pattern di bilanciamento del carico attivo-attivo se la tua applicazione utilizza solo protocolli basati su TCP e UDP e non richiede il failover tra le macchine. Utilizza il pattern in uno scenario in cui le applicazioni possono rispondere alle richieste a seconda del contenuto della richiesta stessa. Se esiste uno stato della macchina che non viene sincronizzato costantemente, non utilizzare il pattern, ad esempio in un database principale o secondario.

Il seguente diagramma mostra un'implementazione del pattern di bilanciamento del carico attivo-attivo:

Come un client interno naviga nel pattern di bilanciamento del carico attivo-attivo.

Il diagramma precedente mostra come un client interno accede a un servizio in esecuzione su due VM tramite un bilanciatore del carico di rete passthrough interno. Entrambe le VM fanno parte di un gruppo di istanze.

Il pattern di bilanciamento del carico attivo-attivo richiede che il servizio esponga i controlli di integrità utilizzando uno dei protocolli di controllo di integrità supportati per garantire che solo le VM reattive ricevano traffico.

Per un'implementazione di esempio completa di questo pattern, consulta l'esempio di deployment con Terraform su GitHub.

Bilanciamento del carico con failover e controlli di integrità esposti all'applicazione

Analogamente al pattern attivo-attivo, il bilanciamento del carico tramite failover e il pattern di controlli di integrità esposti all'applicazione utilizzano le VM come backend per un bilanciatore del carico di rete passthrough interno. Utilizza anche l'indirizzo IP del bilanciatore del carico di rete passthrough interno come indirizzo IP virtuale. Per garantire che solo una VM riceva il traffico alla volta, questo pattern si applica al failover per i bilanciatori del carico di rete passthrough interni.

Questo pattern è consigliato se la tua applicazione ha solo traffico TCP o UDP, ma non supporta un deployment attivo-attivo. Quando applichi questo pattern, tutto il traffico viene indirizzato alla VM primaria o alla VM di failover.

Il seguente diagramma mostra un'implementazione del bilanciamento del carico con failover e pattern di controlli di integrità esposti dall'applicazione:

Come un client interno naviga in un servizio dietro un bilanciatore del carico di rete passthrough interno.

Il diagramma precedente mostra come un client interno accede a un servizio dietro un bilanciatore del carico di rete passthrough interno. Due VM si trovano in gruppi di istanze separati. Un gruppo di istanze è impostato come backend principale. L'altro gruppo di istanze è impostato come backend di failover per un bilanciatore del carico di rete passthrough interno.

Se il servizio sulla VM principale non risponde, il traffico passa al gruppo di istanze di failover. Una volta che la VM principale risponde di nuovo, il traffico torna automaticamente al servizio di backend principale.

Per un'implementazione di esempio completa di questo pattern, consulta l'esempio di deployment con Terraform su GitHub.

Bilanciamento del carico con failover e controlli di integrità esposti heartbeat

Il pattern di bilanciamento del carico con failover e controlli di integrità esposti heartbeat è lo stesso del pattern precedente. La differenza è che i controlli di integrità non sono esposti dall'applicazione stessa, ma da un meccanismo di heartbeat in esecuzione tra le due VM.

Il seguente diagramma mostra un'implementazione del bilanciamento del carico con failover e controlli di integrità esposti heartbeat:

Come un client interno accede a un servizio dietro un bilanciatore del carico interno con due VM in gruppi di istanze separati.

Questo diagramma mostra come un client interno accede a un servizio dietro un bilanciatore del carico interno. Due VM si trovano in gruppi di istanze separati. Un gruppo di istanze è impostato come backend principale. L'altro gruppo di istanze è impostato come backend di failover per un bilanciatore del carico di rete passthrough interno. Keepalived viene utilizzato come meccanismo di heartbeat tra i nodi VM.

I nodi VM scambiano informazioni sullo stato del servizio utilizzando il meccanismo di heartbeat scelto. Ogni nodo VM controlla il proprio stato e lo comunica al nodo remoto. A seconda dello stato del nodo locale e dello stato ricevuto dal nodo remoto, un nodo viene eletto come nodo principale e un nodo viene eletto come nodo di backup. Puoi utilizzare queste informazioni sullo stato per esporre un risultato del controllo di integrità che garantisca che il nodo considerato primario nel meccanismo heartbeat riceva anche il traffico dal bilanciatore del carico di rete passthrough interno.

Ad esempio, con Keepalived puoi richiamare script utilizzando le notify_master, notify_backup e notify_fault variabili di configurazione che modificano lo stato del controllo di integrità. Durante la transizione allo stato principale (in Keepalived questo stato è chiamato master), puoi avviare un'applicazione che ascolta su una porta TCP personalizzata. Quando passi a uno stato di backup o di errore, puoi arrestare questa applicazione. Il controllo di integrità può quindi essere un controllo di integrità TCP che ha esito positivo se questa porta TCP personalizzata è aperta.

Questo pattern è più complesso di quello che utilizza il failover con controlli di integrità esposti all'applicazione. Tuttavia, ti offre un maggiore controllo. Ad esempio, puoi configurarlo in modo che esegua il failback immediatamente o manualmente nell'ambito dell'implementazione del meccanismo heartbeat.

Per un'implementazione di esempio completa di questo pattern che utilizza Keepalived, consulta l'esempio di deployment con Terraform su GitHub.

Pattern che utilizzano le Google Cloud route

Nei casi in cui l'applicazione utilizza protocolli diversi da TCP o UDP su IPv4, puoi eseguire la migrazione dell'indirizzo IP mobile a un pattern basato sulle route.

In questa sezione, i riferimenti alle route si riferiscono sempre alle routeGoogle Cloud che fanno parte di una rete VPC. I riferimenti alle route statiche si riferiscono sempre alle route statiche su Google Cloud.

Utilizzando uno di questi pattern, imposti più route statiche per un indirizzo IP specifico con le diverse istanze come hop successivi. Questo indirizzo IP diventa l'indirizzo IP mobile utilizzato da tutti i client. Deve trovarsi al di fuori di tutti gli intervalli di indirizzi IP delle subnet VPC perché le route statiche non possono ignorare le route di subnet esistenti. Devi attivare l'inoltro dell'indirizzo IP sulle istanze di destinazione. L'attivazione dell'inoltro dell'indirizzo IP consente di accettare il traffico per gli indirizzi IP non assegnati alle istanze, in questo caso l'indirizzo IP mobile.

Se vuoi che le route dell'indirizzo IP mobile siano disponibili dalle reti VPC in peering, esporta le route personalizzate in modo che le route dell'indirizzo IP mobile si propaghino a tutte le reti VPC peer.

Per avere la connettività da una rete on-premise connessa tramite Cloud Interconnect o Cloud VPN, devi utilizzare annunci di route di indirizzi IP personalizzati per fare in modo che l'indirizzo IP mobile venga annunciato on-premise.

I pattern basati su route presentano il seguente vantaggio rispetto ai pattern basati sul bilanciamento del carico:

  • Protocolli e porte:i pattern basati sulle route si applicano a tutto il traffico inviato a una destinazione specifica. I pattern basati sul bilanciamento del carico consentono solo il traffico TCP e UDP.

I pattern basati sul percorso presentano i seguenti svantaggi rispetto ai pattern basati sul bilanciamento del carico:

  • Controllo di integrità:i controlli di integrità non possono essere collegati alle routeGoogle Cloud . Le route vengono utilizzate indipendentemente dall'integrità dei servizi VM sottostanti. Ogni volta che la VM è in esecuzione, le route indirizzano il traffico alle istanze anche se il servizio non è integro. Se colleghi una policy di autoriparazione a queste istanze, le istanze vengono sostituite dopo un periodo di tempo non integro che specifichi. Tuttavia, una volta riavviate, il traffico riprende immediatamente, anche prima che il servizio sia attivo. Questo gap di servizio può portare a potenziali errori del servizio quando le istanze non integre continuano a gestire il traffico o vengono riavviate.
  • Tempo di failover: dopo aver eliminato o arrestato un'istanza VM, Compute Engine ignora qualsiasi route statica che punta a questa istanza. Tuttavia, poiché non sono presenti controlli di integrità sulle route, Compute Engine utilizza comunque la route statica finché l'istanza è ancora disponibile. Inoltre, l'arresto dell'istanza richiede tempo, quindi il tempo di failover è notevolmente superiore rispetto a quello dei pattern basati sul bilanciamento del carico.
  • Solo indirizzi IP mobili interni:anche se puoi implementare pattern utilizzando il bilanciamento del carico con un bilanciatore del carico di rete passthrough esterno per creare un indirizzo IP mobile esterno, i pattern basati su route funzionano solo con indirizzi IP mobili interni.
  • Selezione dell'indirizzo IP mobile:puoi impostare route solo per indirizzi IP mobili interni che non fanno parte di alcuna subnet. Le route di subnet non possono essere sovrascritte in Google Cloud. Tieni traccia di questi indirizzi IP mobili per non assegnarli accidentalmente a un'altra rete.
  • Raggiungibilità delle route:per rendere raggiungibili gli indirizzi IP mobili interni dalle reti on-premise o dalle reti in peering, devi distribuire queste route statiche come descritto in precedenza.

Utilizzo di route ECMP (Equal-cost multipath)

Il pattern ECMP (Equal-cost multipath) è simile al pattern di bilanciamento del carico attivo-attivo: il traffico viene distribuito equamente tra le due istanze di backend. Quando utilizzi le route statiche, ECMP distribuisce il traffico tra gli hop successivi di tutti i candidati di route utilizzando un hash a cinque tuple per l'affinità.

Implementa questo pattern creando due route statiche di uguale priorità con le istanze Compute Engine come hop successivo.

Il seguente diagramma mostra un'implementazione del pattern delle route ECMP:

Come un client interno accede a un servizio utilizzando uno dei due percorsi ECMP.

Il diagramma precedente mostra come un client interno accede a un servizio utilizzando una delle due route con l'hop successivo che punta alle istanze VM che implementano il servizio.

Se il servizio su una VM non risponde, la riparazione automatica tenta di ricreare l'istanza che non risponde. Una volta che la riparazione automatica elimina l'istanza, la route che punta all'istanza diventa inattiva prima della creazione della nuova istanza. Una volta creata la nuova istanza, la route che punta a questa istanza viene utilizzata immediatamente in modo automatico e il traffico viene distribuito equamente tra le istanze.

Il pattern delle route ECMP richiede che il servizio esponga i controlli di integrità utilizzando i protocolli supportati in modo che la riparazione automatica possa sostituire automaticamente le VM che non rispondono.

Puoi trovare un'implementazione di esempio di questo pattern utilizzando Terraform nel repository GitHub associato a questo documento.

Utilizzare route prioritarie diverse

Il pattern di route con priorità diverse è simile al precedente, ma utilizza route statiche con priorità diverse, in modo che il traffico venga sempre indirizzato a un'istanza principale, a meno che non si verifichi un errore.

Per implementare questo pattern, segui gli stessi passaggi del pattern delle route ECMP. Quando crei le route statiche, assegna alla route con l'hop successivo che punta all'istanza principale un valore di priorità inferiore (route principale). Assegna all'istanza con l'hop successivo che punta all'istanza secondaria un valore di priorità più alto (route secondaria).

Il seguente diagramma mostra un'implementazione del pattern delle diverse route di priorità: In che modo un client interno che accede a un servizio utilizza una route principale o secondaria in base alle circostanze di rete.

Il diagramma precedente mostra come un client interno che accede a un servizio utilizza una route principale con un valore di priorità di 500 che punta alla VM 1 come hop successivo in circostanze normali. Una seconda route con un valore di priorità di 1000 è disponibile e punta alla VM 2, la VM secondaria, come hop successivo.

Se il servizio sulla VM principale non risponde, la riparazione automatica tenta di ricreare l'istanza. Una volta che la riparazione automatica elimina l'istanza e prima che venga creata la nuova istanza, la route principale, con l'istanza principale come hop successivo, diventa inattiva. Il pattern utilizza quindi la route con l'istanza secondaria come hop successivo. Una volta che la nuova istanza primaria è attiva, la route primaria torna attiva e tutto il traffico viene indirizzato all'istanza primaria.

Come il pattern precedente, il pattern di route con priorità diversa richiede che il servizio esponga i controlli di integrità utilizzando protocolli supportati in modo che il ripristino automatico possa sostituire automaticamente le VM che non rispondono.

Puoi trovare un'implementazione di esempio di questo pattern utilizzando Terraform nel repository GitHub che accompagna questo documento.

Utilizzo di un meccanismo heartbeat per cambiare l'hop successivo di una route

Se la tua applicazione implementa un meccanismo di heartbeat, come Keepalived, per monitorare la reattività dell'applicazione, puoi applicare il pattern del meccanismo di heartbeat per modificare l'hop successivo della route statica. In questo caso, utilizzi solo una singola route statica con l'hop successivo che punta all'istanza VM principale. In caso di failover, il meccanismo heartbeat indirizza l'hop successivo della route alla VM secondaria.

Il seguente diagramma mostra un'implementazione del meccanismo heartbeat per cambiare il pattern dell'hop successivo di una route:

In che modo un client interno accede a un servizio in cui la VM principale e quella secondaria scambiano informazioni heartbeat.

Il diagramma precedente mostra come un client interno accede a un servizio utilizzando una route con l'hop successivo che punta alla VM principale. La VM primaria scambia informazioni heartbeat con la VM secondaria tramite Keepalived. In caso di failover, Keepalived chiama una funzione Cloud Run che utilizza chiamate API per indirizzare l'hop successivo alla VM secondaria.

I nodi utilizzano il meccanismo di heartbeat scelto per scambiarsi informazioni sullo stato del servizio. Ogni nodo VM controlla il proprio stato e lo comunica al nodo VM remoto. A seconda dello stato del nodo VM locale e dello stato ricevuto dal nodo remoto, un nodo VM viene eletto come nodo primario e un nodo VM viene eletto come nodo di backup. Una volta che un nodo diventa primario, punta l'hop successivo della route per l'indirizzo IP mobile a se stesso. Se utilizzi Keepalived, puoi richiamare uno script utilizzando la notify_master variabile di configurazione che sostituisce la route statica utilizzando una chiamata API o Google Cloud CLI.

Il meccanismo heartbeat per cambiare il pattern di hop successivo di una route non richiede che le VM facciano parte di un gruppo di istanze. Se vuoi che le VM vengano sostituite automaticamente in caso di errore, puoi inserirle in un gruppo di istanze con riparazione automatica. Puoi anche riparare e ricreare manualmente le VM che non rispondono.

L'invocazione della seguente procedura in caso di failover garantisce che il tempo di failover sia ridotto al minimo perché il traffico esegue il failover dopo il completamento di una singola chiamata API nel passaggio 1:

  1. Crea una nuova route statica con l'indirizzo IP mobile come destinazione e la nuova istanza principale come hop successivo. La nuova route deve avere un nome diverso e una priorità inferiore (ad esempio, 400) rispetto alla route originale.
  2. Elimina la route originale alla vecchia VM primaria.
  3. Crea una route con lo stesso nome e la stessa priorità della route che hai appena eliminato. Puntalo alla nuova VM primaria come hop successivo.
  4. Elimina la nuova route statica che hai creato. Non è necessario per garantire che il traffico venga indirizzato alla nuova VM primaria.

Poiché la route originale viene sostituita, deve essere attiva una sola route alla volta, anche in presenza di una rete suddivisa.

L'utilizzo del meccanismo heartbeat per cambiare il pattern di priorità delle route anziché gli altri pattern basati sulle route può ridurre il tempo di failover. Non è necessario eliminare e sostituire le VM tramite la riparazione automatica per il failover. Inoltre, ti offre un maggiore controllo su quando eseguire il failback al server principale originale dopo che è tornato a rispondere.

Uno svantaggio del pattern è che devi gestire autonomamente il meccanismo di heartbeat. La gestione del meccanismo può portare a una maggiore complessità. Un altro svantaggio è che devi concedere i privilegi per modificare la tabella di routing globale alle VM che eseguono il processo heartbeat o a una funzione serverless chiamata dal processo heartbeat. La modifica della tabella di routing globale in una funzione serverless è più sicura in quanto può ridurre l'ambito dei privilegi concessi alle VM. Tuttavia, questo approccio è più complesso da implementare.

Per un'implementazione di esempio completa di questo pattern con Keepalived, consulta l'esempio di deployment con Terraform su GitHub.

Pattern che utilizza la riparazione automatica

A seconda dei requisiti di tempo di ripristino, la migrazione a una singola istanza VM potrebbe essere un'opzione fattibile quando utilizzi Compute Engine. Questa opzione è vera anche se sono stati utilizzati più server che utilizzano un indirizzo IP mobile on-premise. Il motivo per cui questo pattern può essere utilizzato a volte nonostante il numero di VM sia ridotto è che puoi creare una nuova istanza Compute Engine in secondi o minuti, mentre i guasti on-premise in genere richiedono ore o persino giorni per essere risolti.

Utilizzo di una singola istanza con funzionalità di riparazione automatica

Utilizzando questo pattern, fai affidamento al meccanismo di riparazione automatica in un gruppo di istanze VM per sostituire automaticamente un'istanza VM difettosa. L'applicazione espone un controllo di integrità e, quando l'applicazione non è integra, la riparazione automatica sostituisce automaticamente la VM.

Il seguente diagramma mostra un'implementazione del pattern di ripristino automatico a singola istanza:

Come un client interno si connette direttamente a un'istanza Compute Engine.

Il diagramma precedente mostra come un client interno si connette direttamente a un'istanza di Compute Engine inserita in un gruppo di istanze gestite di dimensioni 1 e con la riparazione automatica attivata.

Rispetto ai pattern che utilizzano il bilanciamento del carico, il pattern di riparazione automatica di una singola istanza presenta i seguenti vantaggi:

  • Distribuzione del traffico:esiste una sola istanza, quindi l'istanza riceve sempre tutto il traffico.
  • Facilità d'uso: poiché esiste una sola istanza, questo pattern è il meno complicato da implementare.
  • Risparmio sui costi:l'utilizzo di una singola istanza VM anziché due può dimezzare il costo dell'implementazione.

Tuttavia, il pattern presenta i seguenti svantaggi:

  • Tempo di failover:questo processo è molto più lento dei pattern basati sul bilanciamento del carico. Dopo che i controlli di integrità rilevano un errore della macchina, l'eliminazione e la ricreazione dell'istanza non riuscita richiedono almeno un minuto, ma spesso più tempo. Questo pattern non è comune negli ambienti di produzione. Tuttavia, il tempo di failover potrebbe essere sufficiente per alcuni servizi interni o sperimentali.
  • Reazione agli errori di zona: un gruppo di istanze gestite con una dimensione pari a 1 non sopravvive a un errore di zona. Per reagire agli errori di zona, valuta la possibilità di aggiungere un avviso di Cloud Monitoring quando il servizio non funziona e crea un gruppo di istanze in un'altra zona in caso di errore di zona. Poiché in questo caso non puoi utilizzare lo stesso indirizzo IP, utilizza una zona privata di Cloud DNS per indirizzare la VM e passare il nome DNS al nuovo indirizzo IP.

Puoi trovare un'implementazione di esempio di questo pattern utilizzando Terraform nel repository GitHub.

Passaggi successivi