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 di applicazioni su Compute Engine da un ambiente dell'ambiente di rete. Questo documento è rivolto a ingegneri di rete, amministratori di sistema e ingegneri delle operazioni che eseguono la migrazione delle applicazioni in Google Cloud.

Chiamati anche indirizzi IP condivisi o virtuali, gli indirizzi IP dinamici 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 indirizzi IP in un ambiente Compute Engine senza modificare un'architettura di modello a uno dei pattern descritti in questo documento.

La Repository GitHub che accompagna il documento include deployment di esempio per ogni pattern che di cui puoi eseguire il deployment Terraform.

Indirizzi IP mobili in ambienti on-premise

Gli indirizzi IP mobili sono comunemente utilizzati negli ambienti on-premise. Esempio di utilizzo sono i seguenti:

Esistono diversi modi per implementare gli indirizzi IP mobili in un ambiente on-premise. In genere anche i server che condividono indirizzi IP mobili condividono lo stato informazioni tramite un meccanismo del battito cardiaco. Questo meccanismo consente ai server di comunicare il loro stato di integrità a ciascuno altro; consente 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 protocollo di ridondanza del router virtuale, ma puoi anche usare altri meccanismi simili.

Una volta avviato il failover di un indirizzo IP, il server prenderà il controllo dell'IP di rete lo aggiunge alla sua 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 Apri per prima cosa il percorso più breve (OSPF) annuncia l'indirizzo IP al router di livello 3 a monte.

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. In caso di errore del server principale, il server secondario invia una notifica frame ARP gratuito allo switch per assumere il controllo dell'indirizzo IP mobile.

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 inoltre frame ARP, ma con l'indirizzo MAC di un altro server come ARP gratuito sorgente. 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 un Virtual Private Cloud (VPC) rete, per cui i tipici meccanismi di implementazione non funzionano senza modifiche in Google Cloud. Ad esempio, la rete VPC gestisce le richieste ARP nella 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). Il tipico i meccanismi per gli indirizzi IP mobili si basano sulla gestione delle richieste ARP o si affidano a reti programmabili tramite OSPF o BGP. Pertanto, gli indirizzi IP non eseguono il failover utilizzando questi meccanismi in Google Cloud. Se esegui la migrazione di un'immagine della 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. Questo non rientra nell'ambito di questo documento. Questo documento descrive i pattern per l'implementazione degli scenari di failover in un di networking senza creare reti overlay.

Per implementare applicazioni ad alta disponibilità e affidabilità in Compute Engine, usare 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.

Selezionare un pattern per il tuo caso d'uso

A seconda dei requisiti, uno o più dei pattern descritti in potrebbe essere utile implementare indirizzi IP mobili completamente gestito di Google Cloud.

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

  • 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 mobili, perché in genere il traffico verso applicazioni esterne deve essere bilanciato.

    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, 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 variabili a uno dei pattern che utilizzano il bilanciamento del carico.

  • Protocolli delle applicazioni: se la tua VM utilizza solo TCP e UDP, puoi utilizza tutti i pattern della 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 più scelte di pattern per trasferire 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 di failover dopo il recupero della VM principale: quando viene eseguita la VM principale viene ripristinata dopo un failover, a seconda del pattern utilizzato, per il traffico fa uno di questi due aspetti. o torna immediatamente alla VM principale originale o rimane sulla nuova VM principale fino a quando il failover non viene eseguito manualmente o con un errore della nuova VM principale. In tutti i casi, solo le connessioni appena avviate non vengono ripristinate. Le connessioni esistenti rimangono al nuovo una 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 i controlli di integrità è anche compatibile con i gruppi di istanze. Per rievocare 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 richiedono il failover manuale, di ricreare le VM durante il failover.

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

La tabella seguente elenca le funzionalità per i pattern. Ogni pattern viene descritto nelle seguenti sezioni:

Nome pattern Indirizzo IP Protocolli supportati Modalità di deployment Failback È richiesta la compatibilità del controllo di integrità dell'applicazione 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 controlli di integrità esposti all'applicazione e failover Interno o esterno Solo TCP/UDP Attivo-passivo 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 Attivo-passivo 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 heartbeat per cambiare l'hop successivo della route Interno Tutti i protocolli IP Attivo-passivo Configurabile No Sì
Sequenza con la riparazione automatica
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. Il seguente albero decisionale può aiutarti a restringere le scelte a un l'opzione più 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 offre una disponibilità sufficiente? per le tue esigenze?
    1. Se la risposta è sì, consulta la sezione 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 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 sì e necessita di protocolli su IPv4 diversi da TCP e UDP, consulta Utilizzo delle 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 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 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 integrità di Google Cloud?
    1. Se sì e necessita di protocolli su IPv4 diversi da TCP e UDP, consulta Bilanciamento del carico con controlli di integrità esposti alle applicazioni e failover più avanti in questo documento. Il bilanciamento del carico con failover e controlli di integrità esposti all'applicazione 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 Bilanciamento del carico con controlli di integrità esposti a failover e heartbeat più avanti in questo documento. Nel bilanciamento del carico con failover e nel pattern dei 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. Se no e NON SERVONO protocolli su IPv4 diversi da TCP e UDP, vedi Uso di un meccanismo 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

Di solito, puoi eseguire la migrazione dell'applicazione utilizzando indirizzi IP mobili 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 clienti che accede all'indirizzo IP mobile da altre regioni, seleziona 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 Application Load Balancer esterno, un proxy TCP, o un proxy SSL se la tua applicazione utilizza protocolli e porte supportati da questi bilanciatori del carico le opzioni di CPU e memoria disponibili.

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

  • Tempo di failover: viene associato KeepaLive con l'ARP gratuito in una dell'ambiente on-premise potrebbe eseguire il failover di un indirizzo IP in pochi secondi. Nella nell'ambiente Compute Engine, il tempo medio di ripristino il failover dipende dai parametri impostati. Nel caso in cui la macchina virtuale dell'istanza (VM) o del servizio delle istanze VM, si verifica il tempo medio di failover del traffico dipende da 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 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, l'IP mobile di indirizzi IP accettano tutto il traffico. Scegli una delle seguenti porte specifiche 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 le funzionalità di 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 1-5 porte: utilizza una regola di inoltro.
      • Porte TCP e UDP e da 1 a 5: utilizza più regole di forwarding.
      • 6 o più porte e TCP o UDP: utilizza più regole di inoltro.

  • Controllo di integrità: in locale, puoi verificare 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 uno stato della macchina non è costantemente sincronizzati, non utilizzare questo pattern, ad esempio in un'istanza principale un database secondario.

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

Modalità di navigazione nel pattern di bilanciamento del carico di un client interno 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 esponi l'integrità dei controlli mediante uno dei protocolli per il controllo di integrità supportati per assicurarti che solo le VM adattabili ricevano traffico.

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

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

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 anche l'indirizzo IP del bilanciatore del carico di rete passthrough interno come un indirizzo IP virtuale. Per assicurarti che solo una VM riceva traffico alla volta, questo pattern si applica 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, il traffico passa alla VM principale o alla VM di failover.

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

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 il 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 a 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 deployment di esempio con Terraform su GitHub.

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

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

Il seguente diagramma mostra un'implementazione del bilanciamento del carico con il pattern di 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 come un client interno accede a un servizio dietro un con il bilanciatore del carico di rete passthrough esterno regionale. 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. KeepaLive è un meccanismo che funge da battito cardiaco tra i nodi della VM.

I nodi delle VM scambiano informazioni sullo stato del servizio utilizzando meccanismo di battito cardiaco. Ogni nodo VM controlla il proprio stato e comunica che al nodo remoto. In base allo stato del nodo locale e ricevuto dal nodo remoto, viene eletto un nodo come nodo primario un nodo viene scelto come nodo di backup. 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 KeepaLive puoi richiamare gli script utilizzando l'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 si chiama master), puoi avviare un'applicazione che ascolta su una porta TCP personalizzata. Durante la transizione a uno stato di backup o di errore, puoi interrompere questa applicazione. Il controllo di integrità può quindi essere un controllo di integrità TCP riesce se la porta TCP personalizzata è aperta.

Questo pattern è più complesso di quello che utilizza il failover di controllo di integrità esposti alle applicazioni. Tuttavia, ti offre un maggiore controllo. Per Ad esempio, puoi configurare il failover immediato o manuale nell'ambito l'implementazione del meccanismo di heartbeat.

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

Pattern che utilizzano le route 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 di Google Cloud che fanno parte di una rete VPC. I riferimenti alle route statiche si riferiscono sempre route statiche su Google Cloud.

Utilizzando uno di questi pattern, imposti più route statiche per un IP specifico con le varie istanze come hop successivi. Questo indirizzo IP diventa l'indirizzo IP dinamico utilizzato da tutti i client. Deve essere esterna a tutti Intervalli di indirizzi IP delle subnet VPC poiché 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 degli indirizzi IP mobili siano disponibili reti VPC in peering, esporta route personalizzate in modo che le route degli indirizzi IP mobili si propagano a tutte le reti VPC peer.

Per avere la connettività da una rete on-premise connessa tramite Cloud Interconnect o Cloud VPN è necessario utilizza annunci di route degli indirizzi IP personalizzati in modo che l'indirizzo IP mobile venga pubblicizzato on-premise.

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

  • 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 per TCP e traffico UDP.

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

  • Controllo di integrità: i controlli di integrità non possono essere collegati ai percorsi Google 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. Collegare un criterio di riparazione automatica a queste istanze le sostituisce dopo un periodo di tempo non integro da te specificati. Tuttavia, una volta riavviate le istanze, il traffico riprende immediatamente, anche prima che il servizio sia attivo. Questa lacuna nel servizio può comportare potenziali errori di servizio quando le istanze non integre continuano a gestire traffico o che si riavviano.
  • Tempo di failover: dopo aver eliminato o arrestato un'istanza VM, Compute Engine ignora le route statiche che puntano a questo in esecuzione in un'istanza Compute Engine. 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, il tempo di failover è notevolmente superiore a quello registrato con pattern.
  • 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 e gli indirizzi IP mobili interni.
  • Selezione dell'indirizzo IP mobile: puoi impostare le route solo come indirizzo interno. indirizzi IP mobili che non fanno parte di nessuna subnet: le route di subnet non possono essere sovrascritto 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 route statiche, ECMP distribuisce il traffico tra gli hop successivi di tutte le route candidati utilizzando una hash a cinque tuple per l'affinità.

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

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

In che modo 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 che non risponde. 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 tuo servizio esponga i controlli di integrità utilizzando protocolli supportati in modo che la riparazione automatica possa sostituire 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 con priorità diverse

I diversi pattern di route prioritarie sono simili a quelli precedenti. usa route statiche di priorità diverse, quindi il traffico passa sempre è un'istanza principale, a meno che non si verifichi un errore nell'istanza.

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

Il seguente diagramma mostra un'implementazione delle diverse route di priorità motivo: In che modo un client interno che accede a un servizio utilizza una route primaria o secondaria 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. Il pattern utilizza quindi il percorso con il come hop successivo. Quando viene visualizzata la nuova istanza principale, diventa di nuovo attiva e tutto il traffico passa all'istanza principale.

Come per il pattern precedente, il diverso pattern di percorso prioritario richiede per esporre i controlli di integrità utilizzando protocolli supportati in modo che la riparazione automatica possa le VM che non rispondono automaticamente.

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, 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 heartbeat per cambia il pattern di hop successivo di una route:

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

Il diagramma precedente mostra come un client interno accede a un servizio utilizzando un con l'hop successivo che punta alla VM principale. La VM principale scambia informazioni sul battito cardiaco con la VM secondaria tramite Keepalived. Al momento del failover, KeepaLive chiama una funzione Cloud Run che utilizza le chiamate API per puntare con l'hop successivo nella VM secondaria.

I nodi utilizzano il meccanismo di heartbeat scelto per scambiare informazioni con sullo stato del servizio. Ogni nodo VM controlla il proprio stato lo comunica al nodo VM remoto. In base allo stato della VM locale nodo e lo stato ricevuto dal nodo remoto, viene scelto il nodo VM e un nodo VM viene scelto come nodo di backup. Quando un nodo diventa principale, punta l'hop successivo della route per l'indirizzo IP mobile a per trovare le regole. 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 di 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.

La chiamata alla seguente procedura sul failover garantisce che il tempo di failover minimizzata perché il failover del traffico avviene dopo il completamento di una singola chiamata API Passaggio 1 –

  1. Creare una nuova route statica con l'indirizzo IP mobile come destinazione e la nuova istanza principale come hop successivo. Il nuovo percorso deve avere un indirizzo nome di percorso e una priorità di route inferiore (ad esempio 400) rispetto alla route originale percorso.
  2. Elimina la route originale alla vecchia VM principale.
  3. Crea un percorso con lo stesso nome e la stessa priorità del percorso che hai appena eliminati. 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.

Dato che il percorso originale è stato sostituito, deve essere attivo un solo percorso alla volta. anche in presenza di una rete divisa.

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 è necessario eliminare e sostituire le VM tramite il ripristino automatico per il failover. Inoltre, offre una maggiore controllo su quando eseguire il failover sul server principale originale una volta di nuovo in grado di rispondere.

Uno svantaggio di questo pattern è che devi gestire autonomamente il meccanismo di heartbeat. Gestire il 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 di heartbeat o a una funzione serverless invocata dal processo di heartbeat. Modifica della tabella di routing globale in una funzione serverless è più sicura in quanto può ridurre l'ambito i privilegi concessi alle VM. Tuttavia, questo approccio è più complesso da implementare.

Per un'implementazione di esempio completa di questo pattern con Keepa Aggiornato, vedi 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 è true anche se sono stati utilizzati più server con un indirizzo IP mobile. Il motivo per cui a volte questo pattern può essere utilizzato nonostante il numero di VM è la possibilità di creare una nuova istanza Compute Engine secondi o minuti, mentre gli errori on-premise di solito richiedono ore o anche giorni per risolvere il problema.

Utilizzo di una singola istanza 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, la riparazione automatica presenta i seguenti vantaggi:

  • Distribuzione del traffico: esiste una sola istanza, che quindi riceve sempre tutto il traffico.
  • Facilità di utilizzo: poiché esiste una sola istanza, questo pattern è i meno complicati da implementare.
  • Risparmio sui costi: l'utilizzo di una sola istanza VM anziché due può ridurre e il costo dell'implementazione a metà.

Tuttavia, il pattern presenta i seguenti svantaggi:

  • Tempo di failover:questo processo è molto più lento rispetto al 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 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 di dimensioni pari a 1 non sopravvive a un errore di zona. Per reagire agli errori di zona, valuta la possibilità di aggiungere a Cloud Monitoring avvisa in caso di errore del servizio e crea un gruppo di istanze in un'altra zona in caso di guasto di una zona. 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