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

Last reviewed 2024-01-29 UTC

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

Chiamati anche indirizzi IP virtuali o condivisi, gli indirizzi IP mobili sono spesso utilizzati per rendere altamente disponibili gli ambienti di rete on-premise. Utilizzando indirizzi IP mobili, puoi passare 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 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 di cui puoi eseguire il deployment automatico tramite Terraform.

Indirizzi IP mobili in ambienti on-premise

Gli indirizzi IP mobili sono comunemente utilizzati in ambienti on-premise. Ecco alcuni casi d'uso di esempio:

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

Una volta avviato un failover dell'indirizzo IP, il server che acquisisce il controllo dell'indirizzo IP mobile aggiunge l'indirizzo alla propria interfaccia di rete. Il server annuncia questo takeover ad altri dispositivi che utilizzano il livello 2 inviando un frame gratuito ARP (Address Resolution Protocol). 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 in che modo un server principale e un server secondario connessi allo stesso switch scambiano informazioni sulla reattività tramite un meccanismo Heartbeat. In caso di errore del server principale, il server secondario invia un frame ARP gratuito allo switch per assumere il controllo dell'indirizzo IP mobile.

Utilizzi una configurazione leggermente diversa con soluzioni di bilanciamento del carico on-premise come il bilanciamento del carico di rete di Windows o un bilanciamento del carico di 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 prende il controllo dell'indirizzo IP di origine di un altro server.

Questa azione viene eseguita per distribuire il carico per un indirizzo IP tra server diversi. Tuttavia, questo tipo di configurazione non rientra nell'ambito di questo documento. Nella maggior parte dei casi, quando gli indirizzi IP mobili vengono utilizzati per il bilanciamento del carico on-premise, è preferibile eseguire la migrazione a Cloud Load Balancing.

Sfide della migrazione di indirizzi IP mobili a Compute Engine

Compute Engine utilizza uno stack di rete virtualizzato in una rete Virtual Private Cloud (VPC), per cui i tipici meccanismi di implementazione non funzionano senza modifiche in Google Cloud. Ad esempio, la rete VPC gestisce le richieste ARP nella rete software-defined 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 sulle richieste ARP gestite dal cambio di infrastruttura oppure su reti programmabili da OSPF o BGP. Di conseguenza, gli indirizzi IP non eseguono il failover utilizzando questi meccanismi in Google Cloud. Se esegui la migrazione di un'immagine di macchina virtuale (VM) utilizzando un indirizzo IP mobile on-premise, non puoi eseguire il failover dell'indirizzo IP mobile senza modificare l'applicazione.

Puoi utilizzare una rete in overlay per creare una configurazione che consenta la comunicazione completa di livello 2 e l'acquisizione dell'IP tramite richieste ARP. La configurazione di una rete overlay è però complessa e complica la gestione delle risorse di rete di Compute Engine. Anche 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 di Compute Engine senza creare reti overlay.

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

Questo documento descrive più pattern per la migrazione di un'applicazione esistente utilizzando indirizzi IP mobili da on-premise a Compute Engine, tra cui:

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

Selezione di un pattern per il tuo caso d'uso

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

Considera i seguenti fattori quando decidi quale pattern ti consente di utilizzare meglio un'applicazione:

  • Indirizzo IP interno mobile 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é di solito il traffico verso applicazioni esterne deve essere bilanciato.

    La tabella più avanti in questa sezione consiglia 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, ognuno di questi pattern potrebbe essere adatto alle tue esigenze. Tuttavia, ti consigliamo di eseguire la migrazione dei casi d'uso che utilizzano indirizzi IP esterni mobili a uno dei pattern che utilizzano il bilanciamento del carico.

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

  • Compatibilità del deployment attivo-attivo: alcune applicazioni, pur utilizzando indirizzi IP mobili on-premise, possono funzionare in una modalità di deployment attivo-attivo. Questa funzionalità significa che non richiedono necessariamente il failover dal server principale a quello secondario. Per spostare questi tipi di applicazioni in Compute Engine, hai a disposizione più scelte di pattern per spostare applicazioni. 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 failover dopo il ripristino della VM principale: quando la VM principale originale esegue il ripristino dopo un failover, a seconda del pattern utilizzato, il traffico esegue una delle due operazioni seguenti. Viene ripristinata immediatamente la VM principale originale o rimane nella nuova VM principale finché l'operazione di failover non viene avviata manualmente o fino a quando la nuova VM principale ha esito negativo. In tutti i casi, vengono ripristinate soltanto le connessioni avviate. Le connessioni esistenti rimangono nella nuova VM principale finché non vengono chiuse.

  • Compatibilità con 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 dei pattern descritti nella seguente tabella.

  • Gruppi di istanze: qualsiasi pattern con compatibilità con 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 VM mantengono lo stato, puoi utilizzare un gruppo di istanze gestite stateful. Se non è possibile ricreare automaticamente le VM o se hai richiesto il failover manuale, utilizza un gruppo di istanze non gestite e ricrea manualmente le VM durante il failover.

  • Meccanismi di heartbeat esistenti: se la configurazione ad alta disponibilità per l'applicazione utilizza già un meccanismo di heartbeat per attivare il failover, ad esempio Heartbeat, Pacemaker o Keepa attivato, puoi utilizzare alcuni pattern descritti nella tabella seguente.

Nella tabella seguente sono elencate le funzionalità per i pattern. Ogni pattern è descritto nelle seguenti sezioni:

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

La scelta dello schema da utilizzare per il tuo caso d'uso potrebbe dipendere da diversi fattori. La seguente struttura decisionale può aiutarti a restringere le scelte a un'opzione più adatta.

Un albero decisionale che consente di scegliere un bilanciatore del carico.

Il diagramma precedente illustra i seguenti passaggi:

  1. Una singola istanza di riparazione automatica offre una disponibilità sufficiente per le tue esigenze?
    1. In caso affermativo, consulta Utilizzo di una singola istanza con 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 con errore.
    2. In caso contrario, vai al punto decisionale successivo.
  2. La tua applicazione ha bisogno di protocolli oltre a IPv4 diversi da TCP e UDP?
    1. In caso affermativo, passa al punto decisionale successivo.
    2. In caso contrario, passa al punto decisionale successivo.
  3. La tua applicazione può funzionare in modalità attivo-attivo?
    1. Se la risposta è affermativa, sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, consulta la sezione Utilizzare le route ECMP (a uguale costo) più avanti in questo documento. Le route ECMP distribuiscono il traffico tra gli hop successivi di tutti i percorsi candidati.
    2. Se sì e non ha bisogno di protocolli oltre a IPv4 diversi da TCP e UDP, consulta la sezione 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, in entrambi i casi passa al punto decisionale successivo.
  4. La tua applicazione può esporre i controlli di integrità di Google Cloud?
    1. Se la risposta è affermativa, sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, consulta la sezione Bilanciamento del carico con failover e controlli di integrità esposti dall'applicazione più avanti in questo documento. Il bilanciamento del carico con failover e controlli di integrità esposti dall'applicazione utilizza le VM come backend per un bilanciatore del carico TCP/UDP interno. Utilizza inoltre l'indirizzo IP di bilanciamento del carico TCP/UDP interno come indirizzo IP virtuale.
    2. Se sì e non ha bisogno di protocolli oltre a IPv4 diversi da TCP e UDP, consulta Utilizzo di route con priorità diverse più avanti in questo documento. L'utilizzo di route con priorità diverse consente di garantire che il traffico passi sempre a un'istanza principale, a meno che l'istanza non presenti errori.
    3. In caso contrario, se sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, consulta Bilanciamento del carico con failover e controlli di integrità esposti a battito cardiaco più avanti in questo documento. Nel pattern di bilanciamento del carico con failover e controlli di integrità esposti a battito cardiaco esposti, 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 SERVE BISOGNO di protocolli oltre a IPv4 diversi da TCP e UDP, consulta Utilizzo di un meccanismo di heartbeat per cambiare l'hop successivo di una route più avanti in questo documento. L'uso di un meccanismo 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

Di solito, è possibile eseguire la migrazione dell'applicazione utilizzando indirizzi IP mobili in un'architettura in Google Cloud che utilizza Cloud Load Balancing. Puoi utilizzare un bilanciatore del carico di rete passthrough interno, poiché questa opzione è 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 oltre a IPv4, diversi da TCP o UDP, devi scegliere un pattern che non utilizza il bilanciamento del carico. Questi pattern sono descritti più avanti in questo documento.

Se l'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 attivi attivi, puoi anche utilizzare un Application Load Balancer esterno, un proxy TCP o un proxy SSL se l'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 su bilanciamento del carico:

  • Tempo di failover: l'associazione di Keepa fondamentale con ARP gratuito in un ambiente on-premise potrebbe eseguire il failover su un indirizzo IP in pochi secondi. Nell'ambiente Compute Engine, il tempo medio di ripristino da failover dipende dai parametri impostati. In caso di errore dell'istanza della macchina virtuale (VM) o del servizio dell'istanza VM, il traffico medio per il failover dipende dai parametri per il controllo di integrità come Check Interval e Unhealthy Threshold. Con questi parametri impostati sui valori predefiniti, il failover richiede in genere 15-20 secondi. Per ridurre il tempo, diminuisci i valori parametro.

    In Compute Engine, i failover all'interno di zone o tra 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 della porta nella regola di forwarding interno 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 una combinazione di traffico TCP e UDP o per utilizzare più di cinque porte con un singolo indirizzo IP:
      • Solo TCP o UDP e da 1 a 5 porte: utilizza una sola regola di forwarding.
      • TCP e UDP e da 1 a 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 verificare la reattività dell'applicazione su una macchina nei modi indicati di seguito.

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 è distribuito equamente tra le due istanze di backend. Il traffico appartenente alla stessa sessione va alla stessa istanza di backend definita nelle impostazioni di affinità della sessione.

Utilizza il pattern di bilanciamento del carico attivo-attivo se l'applicazione utilizza solo protocolli basati su TCP e UDP e non richiede il failover tra macchine. Utilizza il pattern in uno scenario in cui le applicazioni possono rispondere alle richieste in base ai contenuti della richiesta stessa. Se esiste uno stato di una macchina che non è costantemente sincronizzato, 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:

Modalità di navigazione di un client interno nel pattern di bilanciamento del carico attivo-attivo.

Il diagramma precedente mostra come un client interno accede a un servizio eseguito su due VM mediante 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 adattabili ricevano traffico.

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

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

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

Questo pattern è consigliato se l'applicazione riceve solo traffico TCP o UDP, ma non supporta un deployment attivo-attivo. Quando applichi questo pattern, tutto il traffico passa alla VM principale o alla VM di failover.

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

In che modo un client interno naviga in un servizio dietro un bilanciatore del carico di rete passthrough interno.

Il diagramma precedente mostra in che modo 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. Quando 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 il deployment di esempio con Terraform su GitHub.

Bilanciamento del carico con failover e controlli di integrità esposti a battito cardiaco

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

Il seguente diagramma mostra un'implementazione del bilanciamento del carico con pattern dei controlli di integrità esposti a failover e 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 in che modo 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. KeepaDuration è usato come meccanismo di battito cardiaco tra i nodi VM.

I nodi VM scambiano informazioni sullo stato del servizio utilizzando il meccanismo di battito cardiaco 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, viene eletto un nodo come primario e un altro come nodo di backup. Puoi utilizzare queste informazioni sullo stato per esporre il risultato di un controllo di integrità che garantisce che il nodo considerato primario nel meccanismo Heartbeat riceva anche il traffico dal bilanciatore del carico di rete passthrough interno.

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

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

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

Pattern con l'utilizzo delle route Google Cloud

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

In questa sezione, i riferimenti alle route fanno sempre riferimento a route Google 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, puoi impostare 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 essere al di fuori di tutti gli intervalli di indirizzi IP di subnet VPC, perché le route statiche non possono sostituire le route di subnet esistenti. Devi attivare l'inoltro degli indirizzi IP sulle istanze di destinazione. L'abilitazione dell'inoltro degli indirizzi 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 di indirizzi IP mobili siano disponibili dalle reti VPC in peering, esporta le route personalizzate in modo che le route con indirizzi IP mobili 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 routing degli indirizzi IP personalizzati per fare in modo che l'indirizzo IP mobile sia pubblicizzato 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 su 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 su route presentano i seguenti svantaggi rispetto ai pattern basati su bilanciamento del carico:

  • Controllo di integrità: i controlli di integrità non possono essere collegati alle route di Google 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 un criterio di riparazione automatica a queste istanze, le istanze vengono sostituite dopo un periodo di tempo non integro specificato da te. Tuttavia, una volta riavviate le istanze, il traffico riprende immediatamente, anche prima dell'attivazione del servizio. Questa lacuna del servizio può causare potenziali errori del servizio quando le istanze in stato non integro continuano a gestire il traffico o sono in fase di riavvio.
  • Tempo di failover: dopo l'eliminazione o l'arresto di un'istanza VM, Compute Engine ignora qualsiasi route statica che punta a questa istanza. Tuttavia, poiché non vengono eseguiti controlli di integrità sulle route, Compute Engine utilizza comunque la route statica finché l'istanza è ancora disponibile. Inoltre, l'arresto dell'istanza richiede tempo, per cui il tempo di failover è notevolmente superiore a quello dei pattern basati sul bilanciamento del carico.
  • Solo indirizzi IP mobili interni: sebbene sia possibile 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 gli indirizzi IP mobili interni.
  • Selezione dell'indirizzo IP mobile: puoi impostare le route solo verso indirizzi IP mobili interni che non fanno parte di nessuna subnet. Le route delle subnet non possono essere sovrascritte in Google Cloud. Monitora questi indirizzi IP mobili per evitare di assegnarli per errore a un'altra rete.
  • Connettività delle route: per rendere gli indirizzi IP mobili interni raggiungibili da reti on-premise o in peering, devi distribuire queste route statiche come descritto in precedenza.

Utilizzo di route ECMP (a costo uguale)

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

Puoi implementare questo pattern creando due route statiche di priorità uguale con le istanze Compute Engine come hop successivi.

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

Il modo in cui un client interno accede a un servizio utilizzando una delle due route ECMP.

Il diagramma precedente mostra in che modo 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. Quando 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 puntata a questa istanza viene utilizzata immediatamente automaticamente e il traffico viene distribuito equamente tra le istanze.

Il pattern di route ECMP richiede che il servizio esponga i controlli di integrità utilizzando i protocolli supportati, per cui la riparazione automatica può 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.

Utilizzo di route prioritarie diverse

Il diverso pattern delle route con priorità è simile al pattern precedente, ad eccezione del fatto che utilizza route statiche con priorità diverse in modo che il traffico passi sempre a un'istanza principale, a meno che l'istanza non presenti errori.

Per implementare questo pattern, segui gli stessi passaggi del pattern delle route ECMP. Quando crei 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 dei diversi pattern di route prioritarie: In che modo un client interno che accede a un servizio utilizza una route principale o secondaria in base alle circostanze della rete.

Il diagramma precedente mostra in che modo un client interno che accede a un servizio utilizza una route principale con un valore di priorità pari a 500 che indica la VM 1 come hop successivo in circostanze normali. È disponibile una seconda route con un valore di priorità pari a 1000 che indirizza 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 poi la route con l'istanza secondaria come hop successivo. Una volta visualizzata la nuova istanza principale, la route principale diventa di nuovo attiva e tutto il traffico passa all'istanza principale.

Come il pattern precedente, il diverso pattern di route a priorità richiede che il tuo 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 di 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 Keepaworthy, per monitorarne la reattività, puoi applicare il modello di meccanismo heartbeat per modificare l'hop successivo della route statica. In questo caso, utilizzerai solo una singola route statica con l'hop successivo che punta all'istanza VM principale. In caso di failover, il meccanismo Heartbeat punta l'hop successivo della route alla VM secondaria.

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

Modalità di accesso di un client interno a un servizio in cui la VM primaria e la VM secondaria scambiano informazioni sull'heartbeat.

Il diagramma precedente mostra in che modo un client interno accede a un servizio utilizzando una route con l'hop successivo che punta alla VM principale. La VM principale scambia le informazioni sul battito cardiaco con la VM secondaria tramite Keepalive. In caso di failover, KeepaDuration chiama una Cloud Function che utilizza le chiamate API per indirizzare l'hop successivo alla VM secondaria.

I nodi utilizzano il meccanismo di battito cardiaco scelto per scambiare 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 selezionato come nodo principale e un altro nodo VM come nodo di backup. Quando un nodo diventa primario, punta verso se stesso l'hop successivo della route per l'indirizzo IP mobile. Se utilizzi KeepaDuration, puoi richiamare uno script utilizzando la variabile di configurazione notify_master 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.

La chiamata della seguente procedura sul failover garantisce che il tempo di failover venga ridotto perché il traffico ha esito negativo dopo il completamento di una singola chiamata API nel Passaggio 1:

  1. Creare una nuova route statica con l'indirizzo IP mobile come destinazione e la nuova istanza principale come hop successivo. La nuova route dovrebbe avere un nome diverso e una priorità di route inferiore (ad esempio 400) rispetto a quella originale.
  2. Elimina la route originale alla VM principale precedente.
  3. Crea una route con lo stesso nome e la stessa priorità della route appena eliminata. Punta alla nuova VM principale come hop successivo.
  4. Elimina la nuova route statica che hai creato. Non è necessario per garantire il flusso del traffico verso la nuova VM principale.

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

L'utilizzo del meccanismo Heartbeat per cambiare il pattern di priorità della 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. Offre inoltre un maggiore controllo su quando eseguire il failover al server principale originale in seguito a una nuova risposta.

Uno svantaggio di questo schema è che devi gestire personalmente il meccanismo del battito cardiaco. 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 KeepaDuration, consulta il deployment di esempio con Terraform su GitHub.

Sequenza con riparazione automatica

A seconda dei requisiti dei tempi di ripristino, potrebbe essere possibile eseguire la migrazione a una singola istanza VM quando si utilizza Compute Engine. Questa opzione è vera anche se on-premise sono stati utilizzati più server che utilizzano un indirizzo IP mobile. Il motivo per cui questo pattern può essere utilizzato a volte nonostante il numero di VM in fase di riduzione è che è possibile creare una nuova istanza di Compute Engine in pochi secondi o minuti, mentre la risoluzione degli errori on-premise richiede in genere ore o persino giorni.

Utilizzo di una singola istanza con riparazione automatica

Utilizzando questo pattern ti affidi al meccanismo di riparazione automatica in un gruppo di istanze VM per sostituire automaticamente un'istanza VM con errore. L'applicazione espone un controllo di integrità e, quando non è integro, la riparazione automatica sostituisce automaticamente la VM.

Il seguente diagramma mostra un'implementazione del pattern di riparazione automatica a istanza singola:

Modalità di connessione diretta di un client interno a un'istanza Compute Engine.

Il diagramma precedente mostra in che modo un client interno si connette direttamente a un'istanza di Compute Engine posizionata in un gruppo di istanze gestite con una dimensione pari a 1 e con la riparazione automatica attivata.

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

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

Tuttavia, il pattern presenta i seguenti svantaggi:

  • Tempo di failover:questo processo è molto più lento rispetto ai pattern basati sul bilanciamento del carico. Dopo che i controlli di integrità hanno rilevato un guasto della macchina, l'eliminazione e la nuova creazione dell'istanza non riuscita richiede almeno un minuto, ma spesso richiede 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 l'aggiunta di un avviso Cloud Monitoring quando il servizio non funziona e, in caso di errore di una zona, crea un gruppo di istanze in un'altra zona. Poiché in questo caso non puoi utilizzare lo stesso indirizzo IP, utilizza una zona privata di Cloud DNS per indirizzare la VM e cambia il nome DNS sul nuovo indirizzo IP.

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

Passaggi successivi