Pattern 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 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 di applicazioni inGoogle Cloud.

Chiamati anche indirizzi IP condivisi o virtuali, gli indirizzi IP flottanti vengono spesso utilizzati per rendere altamente disponibili gli ambienti di rete on-premise. Con gli indirizzi IP dinamici, 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 gli indirizzi IP dinamici 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 in ambienti on-premise

Gli indirizzi IP mobili sono 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 variabili in genere condividono anche informazioni sullo stato tramite un meccanismo di heartbeat. Questo meccanismo consente ai server di comunicare il proprio stato di salute tra di loro e al server secondario di assumere l'indirizzo IP dinamico dopo il guasto del server principale. 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 assume l'indirizzo IP dinamico lo aggiunge alla propria interfaccia di rete. Il server annuncia questo attacco agli altri dispositivi che utilizzano 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 a monte.

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

Ambiente on-premise tipico.

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 assumere l'indirizzo IP dinamico.

Utilizzi una configurazione leggermente diversa con le 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 del server diretta 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 essenzialmente falsifica i frame ARP e assume l'indirizzo IP di origine di un altro server.

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

Problemi di migrazione degli 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 dinamici si basano sul fatto che le richieste ARP vengano gestite dall'infrastruttura di commutazione o su reti programmabili da OSPF o BGP. Pertanto, gli indirizzi IP non eseguono il failover utilizzando questi meccanismi in Google Cloud. Se esegui la migrazione di un'immagine di una macchina virtuale (VM) utilizzando un indirizzo IP flottante on-premise, l'indirizzo IP flottante non può eseguire il failover senza modificare l'applicazione.

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

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

Questo documento descrive più pattern per eseguire la migrazione di un'applicazione esistente dall'ambiente on-premise a Compute Engine utilizzando indirizzi IP mobili, 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. Di conseguenza, potresti non essere in grado di aggiungerlo a un'altra istanza, rendendo impossibile il failover.

Selezione di 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 dinamici in un ambiente on-premise.

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

  • Indirizzo IP interno o esterno dinamico:la maggior parte delle applicazioni che richiedono indirizzi IP dinamici utilizza indirizzi IP interni dinamici. Poche applicazioni utilizzano indirizzi IP esterni variabili, perché tipicamente il traffico verso le applicazioni esterne deve essere bilanciato in base al carico.

    La tabella di questa sezione consiglia i pattern che puoi utilizzare per gli indirizzi IP interni e esterni variabili. Per i casi d'uso che si basano su indirizzi IP interni variabili, uno 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 variabili 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 IPv4 per la connessione, sono appropriati solo alcuni pattern.

  • Compatibilità con il deployment attivo-attivo:alcune applicazioni, pur utilizzando indirizzi IP fluttuanti on-premise, possono funzionare in una modalità di deployment attivo-attivo. Ciò significa che non richiedono necessariamente il failover dal server principale al server secondario. Hai a disposizione più pattern per eseguire il trasferimento di questi tipi di applicazioni in Compute Engine. Le applicazioni che richiedono un solo server di applicazioni per ricevere traffico in qualsiasi momento non sono compatibili con il deployment attivo-attivo. Puoi implementare queste applicazioni solo con alcuni pattern riportati nella tabella seguente.

  • Comportamento del failback dopo il recupero della VM principale:quando la VM principale originale si riprende dopo un failover, a seconda del pattern utilizzato, il traffico può comportarsi in due modi. Torna immediatamente alla VM principale originale o rimane nella nuova VM principale finché il failback non viene avviato manualmente o la nuova VM principale non si arresta in modo anomalo. In tutti i casi, solo le connessioni appena avviate non vengono ripristinate. Le connessioni esistenti rimangono nella nuova VM principale finché non vengono chiuse.

  • Compatibilità con i controlli di integrità:se non riesci a verificare se la tua applicazione è reattiva 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à con controllo di integrità è anche compatibile con i gruppi di istanze. Per rieseguire automaticamente le istanze non riuscite, puoi utilizzare un gruppo di istanze gestite con la riparazione automatica. Se le VM mantengono lo stato, puoi utilizzare un gruppo di istanze gestite con stato. Se le VM non possono essere ricreate automaticamente o se hai bisogno di un failover manuale, utilizza un gruppo di istanze non gestite e ri crea manualmente le VM durante il failover.

  • Meccanismi di heartbeat esistenti: se la configurazione dell'alta disponibilità 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 seguenti sezioni:

Nome pattern Indirizzo IP Protocolli supportati Modalità di deployment Failback Compatibilità richiesta per controllo di integrità delle applicazioni Può integrare il meccanismo di heartbeat
Modelli 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 Attiva-passiva Immediata (tranne le connessioni esistenti) Sì No
Bilanciamento del carico con controlli di integrità esposti a failover e heartbeat Interno o esterno Solo TCP/UDP Attiva-passiva Configurabile No Sì
Modelli che utilizzano i percorsi Google Cloud
Utilizzo delle route ECMP Interno Tutti i protocolli IP Attivo-attivo N/D Sì No
Utilizzare route con priorità diverse Interno Tutti i protocolli IP Attiva-passiva Immediata (tranne le connessioni esistenti) Sì No
Utilizzo di un meccanismo di heartbeat per cambiare l'hop successivo della route Interno Tutti i protocolli IP Attiva-passiva Configurabile No Sì
Pattern che utilizzano il ripristino automatico
Utilizzo di un'istanza singola con 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. La seguente struttura 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 con riparazione automatica offre una disponibilità sufficiente per le tue esigenze?
    1. In caso affermativo, consulta la sezione Utilizzare un'istanza singola 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 difettosa.
    2. In caso contrario, vai al punto di decisione successivo.
  2. La tua applicazione ha bisogno di protocolli oltre a IPv4 diversi da TCP e UDP?
    1. In caso affermativo, vai al punto di decisione successivo.
    2. In caso contrario, vai al punto di decisione successivo.
  3. La tua applicazione può funzionare in modalità attiva-attiva?
    1. Se la risposta è sì e sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, consulta la sezione Utilizzare le route ECMP (equal-cost multipath) di seguito 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 oltre a TCP e UDP su IPv4, 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 di decisione successivo.
  4. La tua applicazione può esporre i controlli di salute di Google Cloud ?
    1. Se la risposta è sì e sono necessari protocolli oltre a TCP e UDP su IPv4, consulta la sezione Bilanciamento del carico con failover e controlli di integrità esposti all'applicazione di questo documento. Il bilanciamento del carico con failover e controlli di integrità esposti alle applicazioni utilizza le VM come backend per un bilanciatore del carico TCP/UDP interno. Utilizza inoltre l'indirizzo IP del bilanciamento del carico TCP/UDP interno come indirizzo IP virtuale.
    2. Se la risposta è sì e non sono necessari protocolli oltre a TCP e UDP su IPv4, consulta la sezione Utilizzare route con priorità diverse di questo documento. L'utilizzo di percorsi con priorità diverse contribuisce a garantire che il traffico venga sempre indirizzato a un'istanza principale, a meno che quest'ultima non abbia esito negativo.
    3. In caso contrario e sono necessari protocolli oltre a TCP e UDP su IPv4, consulta la sezione Bilanciamento del carico con controlli di integrità esposti a failover e heartbeat di questo documento. Nel bilanciamento del carico con failover e nel pattern di controlli di integrità esposti tramite heartbeat, i controlli di integrità non sono esposti dall'applicazione stessa, ma da un meccanismo di heartbeat in esecuzione tra entrambe le VM.
    4. In caso contrario e NON SONO NECESSARI protocolli aggiuntivi su IPv4 oltre a TCP e UDP, consulta Utilizzare 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 prevede una singola route statica con l'hop successivo che rimanda all'istanza VM principale.

Pattern che utilizzano il bilanciamento del carico

In genere, puoi eseguire la migrazione dell'applicazione utilizzando indirizzi IP fluttuanti a 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 è exposto 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 uno schema 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 gli schemi descritti in questa sezione utilizzando un bilanciatore del carico di rete passthrough esterno. Per i deployment attivi-attivi, puoi anche utilizzare 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 dinamici 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 di recupero medio dal failover dipende dai parametri impostati. Se l'istanza della macchina virtuale (VM) o il servizio dell'istanza VM non va a buon fine, il traffico del tempo medio di failover dipende dai parametri di 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 di questi parametri.

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

  • Protocolli e porte:in una configurazione on-premise, gli indirizzi IP dinamici accettano tutto il traffico. Scegli una delle seguenti specifiche della 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 inoltro 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 inoltro.
      • 6 o più porte e TCP o UDP: utilizza più regole di inoltro.

  • Controllo di integrità:in locale, puoi controllare la risposta dell'applicazione su un computer nei seguenti modi:

Bilanciamento del carico attivo-attivo

Nel pattern di bilanciamento del carico attivo-attivo, le VM sono i backend di un bilanciatore del carico di rete passthrough interno. L'indirizzo IP del bilanciatore del carico di rete passthrough interno viene utilizzato 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 in base ai contenuti 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:

In che modo un client interno gestisce il 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 il deployment di esempio 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 il failover e il pattern di controlli di integrità esposti all'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 un indirizzo IP virtuale. Per garantire che una sola VM riceva il traffico alla volta, questo pattern applica il 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 principale o alla VM di failover.

Il seguente diagramma mostra un'implementazione del bilanciamento del carico con il pattern di controllo di integrità esposto al failover e all'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 è di nuovo in stato di risposta, il traffico ripassa 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 controlli di integrità esposti a failover e heartbeat

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

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

In che modo 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 altro come nodo di riserva. Puoi utilizzare queste informazioni sullo stato per mostrare un risultato del controllo di integrità che garantisca che il nodo considerato principale nel meccanismo di heartbeat riceva anche il traffico dal bilanciatore del carico di rete passthrough interno.

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

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

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

Pattern che utilizzano i percorsi di Google Cloud

Se la tua applicazione utilizza protocolli diversi da TCP o UDP su IPv4, puoi eseguire la migrazione dell'indirizzo IP dinamico a un pattern basato su route.

In questa sezione, le menzioni delle route fanno sempre riferimento alle route che fanno parte di una rete VPC. I riferimenti alle route statiche fanno sempre riferimento 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 dinamico utilizzato da tutti i client. Deve essere esterno a tutti gli intervalli di indirizzi IP delle subnet VPC perché le route statiche non possono sostituire le route di subnet esistenti. Devi attivare l'inoltro degli indirizzi IP nelle istanze di destinazione. L'attivazione dell'inoltro degli indirizzi IP ti consente di accettare il traffico per gli indirizzi IP non assegnati alle istanze, in questo caso l'indirizzo IP dinamico.

Se vuoi che le route con indirizzi IP flottanti siano disponibili dalle reti VPC in peering, esporta le route personalizzate in modo che le route con indirizzi IP flottanti vengano propagate a tutte le reti VPC peer.

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

I pattern basati su route hanno 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 sul bilanciamento del carico:

  • Controllo di integrità: i controlli di integrità non possono essere associati ai percorsiGoogle Cloud . I percorsi vengono utilizzati indipendentemente dall'integrità dei servizi VM sottostanti. Ogni volta che la VM è in esecuzione, inoltra il traffico diretto alle istanze anche se il servizio non è integro. L'applicazione di un criterio di riparazione automatica a queste istanze ne sostituisce altre dopo un periodo di tempo non corretto da te specificato. Tuttavia, una volta riavviate queste istanze, il traffico riprende immediatamente, anche prima che il servizio sia attivo. Questo intervallo di servizio può comportare potenziali errori di servizio quando le istanze non sane continuano a gestire il traffico o si riavviano.
  • Tempo di failover: dopo aver eliminato o arrestato un'istanza VM, Compute Engine ignora qualsiasi route statico che rimandi 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'interruzione dell'istanza richiede tempo, pertanto il tempo di failover è notevolmente superiore rispetto ai pattern basati sul bilanciamento del carico.
  • Solo indirizzi IP flottanti interni:anche se puoi implementare i pattern utilizzando il bilanciamento del carico con un bilanciatore del carico di rete passthrough esterno per creare un indirizzo IP flottante esterno, i pattern basati su route funzionano solo con indirizzi IP flottanti interni.
  • Selezione dell'indirizzo IP dinamico: puoi impostare route solo per gli indirizzi IP dinamici interni che non fanno parte di alcuna subnet. I route delle subnet non possono essere sostituiti in Google Cloud. Monitora questi indirizzi IP mobili in modo da non assegnarli accidentalmente a un'altra rete.
  • Raggiungibilità delle route: per rendere raggiungibili gli indirizzi IP interni variabili dalle reti on-premise o dalle reti con peering, devi distribuire queste route statiche come descritto in precedenza.

Utilizzo dei percorsi ECMP (Equal-cost multipath)

Il pattern di route 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 tutte le route candidate utilizzando un hash di cinque tuple per l'affinità.

Implementa questo pattern creando due route statici di pari priorità con le istanze Compute Engine come next-hop.

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 di 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 non rispondente. Una volta che la riparazione automatica elimina l'istanza, il percorso che rimanda all'istanza diventa inattivo prima che venga creata la nuova istanza. Una volta creata la nuova istanza, il percorso a cui rimanda viene utilizzato immediatamente e 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 protocolli supportati in modo che la riparazione automatica possa sostituire automaticamente le VM non rispondenti.

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

Utilizzare route con priorità diverse

Il pattern di percorsi con priorità diverse è simile al pattern precedente, tranne per il fatto che utilizza percorsi statici con priorità diverse, in modo che il traffico venga sempre indirizzato a un'istanza principale, a meno che questa non abbia esito negativo.

Per implementare questo pattern, segui gli stessi passaggi descritti nel pattern di route ECMP. Quando crei le route statiche, assegna alla route con l'hop successivo che rimanda all'istanza principale un valore di priorità inferiore (route principale). Assegna all'istanza con il next-hop che rimanda all'istanza secondaria un valore di priorità più elevato (route secondaria).

Il seguente diagramma mostra un'implementazione del diverso pattern di route di priorità: In che modo un client interno che accede a un servizio utilizza un percorso principale o secondario in base alle circostanze della rete.

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

Se il servizio sulla VM principale non risponde, la riparazione automatica tenta di rievocare l'istanza. Una volta che la riparazione automatica elimina l'istanza e prima che venga visualizzata la nuova istanza creata, la route principale, con l'istanza principale come hop successivo, diventa inattiva. Lo schema utilizza quindi la route con l'istanza secondaria come hop successivo. Una volta avviata la nuova istanza principale, il percorso principale diventa di nuovo attivo e tutto il traffico viene indirizzato all'istanza principale.

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

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

Utilizzo di un meccanismo di 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, utilizza solo una singola route statica con l'hop successivo che rimanda all'istanza VM principale. In caso di failover, il meccanismo di heartbeat indirizza l'hop successivo della route alla VM secondaria.

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

In che modo un client interno accede a un servizio in cui le VM principali e secondarie scambiano informazioni di 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 principale scambia informazioni sul battito cardiaco con la VM secondaria tramite Keepalived. In caso di failover, Keepalived chiama una funzione Cloud Run che utilizza le chiamate API per indirizzare il 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 comunicate 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 principale e un altro nodo VM viene eletto come nodo di backup. Una volta che un nodo diventa primario, indirizza l'hop successivo della route per l'indirizzo IP dinamico 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 il comando Google Cloud CLI.

Il meccanismo di heartbeat per cambiare il pattern dell'hop successivo di una route non richiede che le VM appartengano a 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 non rispondenti.

L'attivazione della procedura seguente per il failover garantisce che il tempo di failover sia minimizzato perché il traffico viene eseguito in failover al termine di una singola chiamata API nel passaggio 1:

  1. Crea una nuova route statica con l'indirizzo IP dinamico 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 principale.
  3. Crea un route con lo stesso nome e la stessa priorità del route appena eliminato. Indica la 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é il percorso originale viene sostituito, deve essere attivo un solo percorso alla volta anche se è presente una rete suddivisa.

L'utilizzo del meccanismo di heartbeat per cambiare il pattern di priorità della route anziché gli altri pattern basati su route può ridurre il tempo di failover. Non devi eliminare e sostituire le VM tramite il ripristino automatico per il failover. Inoltre, ti offre un maggiore controllo su quando eseguire il failback al server principale originale dopo che è nuovamente in grado di rispondere.

Uno svantaggio di questo pattern è che devi gestire autonomamente il meccanismo di heartbeat. La gestione del meccanismo può comportare una maggiore complessità. Un altro svantaggio è che devi concedere i privilegi per modificare la tabella di routing globale alle VM che eseguono il processo di heartbeat o a una funzione serverless invocata dal processo di 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 il deployment di esempio con Terraform su GitHub.

Pattern che utilizza la riparazione automatica

A seconda dei requisiti relativi al tempo di recupero, la migrazione a una singola istanza VM potrebbe essere un'opzione fattibile quando si utilizza Compute Engine. Questa opzione è valida anche se sono stati utilizzati più server on-premise che utilizzano un indirizzo IP dinamico. Il motivo per cui questo modello può essere utilizzato a volte nonostante il numero di VM sia ridotto è che puoi creare una nuova istanza Compute Engine in pochi secondi o minuti, mentre la correzione degli errori on-premise richiede in genere ore o addirittura giorni.

Utilizzo di un'istanza singola con riparazione automatica

Con questo pattern, ti affidi 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 non è integra, la riparazione automatica sostituisce automaticamente la VM.

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

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 Compute Engine inserita in un gruppo di istanze gestite di dimensione 1 e con la riparazione automatica attivata.

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

  • Distribuzione del traffico: esiste una sola istanza, che quindi 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 rispetto ai pattern basati sul bilanciamento del carico. Dopo che i controlli di integrità rilevano un errore della macchina, l'eliminazione e la ricreazione dell'istanza in errore richiede almeno un minuto, ma spesso richiede più tempo. Questo modello 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 di dimensioni pari a 1 non sopravvive a un errore di zona. Per reagire ai guasti delle zone, ti consigliamo di aggiungere un avviso di Cloud Monitoring quando il servizio non funziona e di creare un gruppo di istanze in un'altra zona in caso di guasto. Poiché in questo caso non puoi utilizzare lo stesso indirizzo IP, utilizza una zona privata Cloud DNS per indirizzare la VM e imposta il nome DNS sul nuovo indirizzo IP.

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

Passaggi successivi