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, sistemi amministratori e tecnici delle operazioni che eseguono la migrazione delle applicazioni in Google Cloud.

Chiamati anche indirizzi IP virtuali o condivisi, gli indirizzi IP mobili sono spesso utilizzati per garantire l'alta disponibilità degli ambienti di rete on-premise. Utilizzo indirizzi IP mobili, puoi passare un indirizzo IP tra più indirizzi IP server fisici o virtuali configurati. Questa pratica consente il failover 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 completamente gestito di Google Cloud. 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 lo comunica takeover ad altri dispositivi utilizzando 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 collegato allo stesso switch. Scambia informazioni sulla reattività tramite un meccanismo di battito cardiaco. 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.

La 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 diretto Risposta del server come IPVS. In questi casi, il servizio invia anche frame ARP, ma con l'indirizzo MAC di un altro server come ARP gratuito sorgente. Questa azione sostanzialmente falsifica i frame ARP e acquisisce la fonte Indirizzo IP di un altro server.

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

Sfide della migrazione degli indirizzi IP mobili in 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 come OSPF o BGP (Border Gateway Protocol). 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. Di conseguenza, gli indirizzi IP non eseguono il failover utilizzando questi meccanismi in Google Cloud. Se esegui la migrazione dell'immagine di una macchina virtuale (VM) utilizzando un un indirizzo IP mobile on-premise, non è possibile eseguire il failover dell'indirizzo IP mobile senza la modifica dell'applicazione.

Puoi utilizzare un rete overlay per creare una configurazione che consenta la comunicazione completa prendono il controllo tramite le richieste ARP. Tuttavia, configurare una rete overlay è complesso e complica 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 minimizza l'effetto dell'errore di un singolo nodo.

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

Utilizzo Indirizzi IP alias che si spostano tra istanze VM è sconsigliato come meccanismo di attenzione perché non soddisfa i requisiti di alta disponibilità. In alcune ad esempio un evento di errore a livello di zona, potresti non essere in grado di rimuovere un indirizzo IP alias di un'istanza. Di conseguenza, potresti non riuscire ad 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 può 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 esterno mobile o interno mobile: la maggior parte Le applicazioni che richiedono indirizzi IP mobili utilizzano un indirizzo IP interno mobile indirizzi IP esterni. Poche applicazioni utilizzano indirizzi IP esterni mobili, perché in genere il traffico verso applicazioni esterne deve essere bilanciato.

    La tabella più avanti in questa sezione consiglia i pattern da utilizzare per per gli indirizzi IP interni e per gli indirizzi IP esterni mobili. Per casi d'uso che si basano su indirizzi IP interni mobili, uno qualsiasi di questi pattern attuabili per le tue esigenze. Tuttavia, consigliamo i casi d'uso che si basano gli indirizzi IP esterni mobili devono essere migrati in uno dei dei pattern con 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à del deployment attivo-attivo:alcune applicazioni, mentre indirizzi IP mobili on-premise, possono funzionare in modalità di deployment attivo-attivo. Questa funzionalità 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. Applicazioni che richiedono un solo server delle applicazioni per ricevere il traffico in qualsiasi momento non sono compatibili con il deployment active-active. Puoi implementare solo per queste applicazioni con alcuni pattern 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 nuove delle connessioni avviate non viene eseguito. Le connessioni esistenti rimangono al nuovo una VM principale finché non vengono chiuse.

  • Compatibilità del controllo di integrità:se non puoi controllare se il tuo l'applicazione è reattiva usando Compute Engine controlli di integrità, senza difficoltà, non puoi utilizzare alcuni pattern descritti .

  • Gruppi di istanze: qualsiasi pattern con compatibilità del controllo di integrità viene ed è compatibile anche con i gruppi di istanze. A automaticamente per ricreare le istanze non riuscite, puoi utilizzare un gruppo di istanze gestite con riparazione automatica. Se le tue VM mantengono lo stato, puoi utilizzare un ambiente gruppo di istanze gestite. 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 KeepaLifetime, 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 dell'heartbeat
Pattern che utilizzano il bilanciamento del carico
Bilanciamento del carico attivo-attivo Interno o esterno Solo TCP/UDP Attivo-attivo N/D Sì No
Bilanciamento del carico con failover e controlli di integrità esposti alle applicazioni 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ì
Pattern che utilizzano le route di Google Cloud
Utilizzo delle route ECMP Interno Tutti i protocolli IP Attivo-attivo N/D Sì No
Utilizzo di route prioritarie diverse Interno Tutti i protocolli IP Attivo-passivo 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 una singola istanza con riparazione automatica Interno Tutti i protocolli IP N/D N/D Sì No

Decidere quale pattern utilizzare per il tuo caso d'uso può dipendere 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'istanza VM per sostituire automaticamente un'istanza VM errata.
    2. In caso contrario, passa al punto decisionale successivo.
  2. La tua applicazione ha bisogno di protocolli oltre a IPv4 diversi da TCP e UDP?
    1. Se sì, passa al punto decisionale successivo.
    2. In caso contrario, vai al prossimo punto decisionale.
  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 hop di tutti i candidati di percorso.
    2. Se sì e non sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, vedi 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, in entrambi i casi, passa al punto decisionale 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. Bilanciamento del carico con failover i controlli di integrità esposti alle applicazioni utilizzano le tue VM come backend per con il bilanciatore del carico TCP/UDP interno. Utilizza anche il carico TCP/UDP interno Bilanciamento dell'indirizzo IP come indirizzo IP virtuale.
    2. Se sì e non sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, consulta l'articolo Utilizzo di route di priorità diverse. più avanti in questo documento. L'utilizzo di percorsi prioritari diversi aiuta a garantire il traffico passa sempre a un'istanza principale, a meno che quest'ultima non riesce.
    3. In caso contrario, sono necessari protocolli oltre a IPv4 diversi da TCP e UDP, vedi Bilanciamento del carico con controlli di integrità esposti a failover e heartbeat più avanti in questo documento. Nel bilanciamento del carico con failover pattern di controlli di integrità esposti a heartbeat, i controlli di integrità non sono esposti dall'applicazione stessa, ma tramite un meccanismo heartbeat in esecuzione tra su 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'uso di un meccanismo heartbeat per cambiare l'hop successivo della 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, 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 esposti solo internamente. Questa opzione di bilanciamento del carico viene utilizzata per tutti gli esempi in 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 su IPv4, diversi da TCP o UDP, devi scegliere un pattern che non utilizzi il bilanciamento del carico. Quelli vengono descritti più avanti in questo documento.

Se la tua applicazione utilizza HTTP(S), puoi utilizzare 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 a 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 Application Load Balancer esterno, un proxy TCP, o un proxy SSL se l'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: associazione di KeepaLive con 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 in genere richiede 15-20 secondi. Puoi ridurre il tempo riducendo i valori dei parametri.

    In Compute Engine, i failover all'interno di zone o tra zone richiedono la stessa quantità di tempo.

  • Protocolli e porte: in una configurazione on-premise, l'IP mobile di indirizzi IP accettano tutto il traffico. Scegli una delle seguenti porte 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 da 1 a 5 porte: utilizza una sola regola di forwarding.
      • Porte TCP e UDP e da 1 a 5: utilizza più regole di forwarding.
      • Sei o più porte e TCP o UDP: utilizza più regole di forwarding.

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

Bilanciamento del carico attivo-attivo

Nel pattern di bilanciamento del carico attivo-attivo, le VM sono backend per un il bilanciatore del carico di rete passthrough interno. Puoi utilizzare l'indirizzo IP del bilanciatore del carico di rete passthrough interno come con un indirizzo IP virtuale. Il traffico è distribuito equamente tra i due backend di Compute Engine. Il traffico appartenente alla stessa sessione va allo stesso backend come definito nell'istanza impostazioni di affinità 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 a seconda sui 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 carico attivo-attivo di bilanciamento del carico:

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

Il diagramma precedente mostra come un client interno accede a un servizio che viene eseguito 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 failover e controlli di integrità esposti alle applicazioni

In modo simile al pattern attivo-attivo, il bilanciamento del carico tramite failover il pattern dei controlli di integrità esposto alle applicazioni usa le tue VM come backend per il 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 l'applicazione ha solo traffico TCP o UDP, ma non supporta un deployment active-active. 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:

Modalità con cui 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 sono in gruppi di istanze separati. Un gruppo di istanze è impostato come backend principale. L'altro gruppo di istanze è impostato come 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 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 come un client interno accede a un servizio dietro un con il bilanciatore del carico di rete passthrough esterno regionale. Due VM sono 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 esporre un risultato del controllo di integrità che garantisca che il nodo sia considerato principale in il meccanismo heartbeat riceve 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à. Al momento della transizione allo stato principale (in Lo stato viene mantenuto master), puoi avviare un'applicazione rimane in ascolto su una porta TCP personalizzata. Durante la transizione a uno stato di backup o di errore, può arrestare l'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 dell'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

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

In questa sezione, le menzioni dei percorsi si riferiscono sempre a 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 mobile utilizzato da tutti i client. Deve essere esterna a tutti Intervalli di indirizzi IP delle subnet VPC perché le route statiche non possono sostituire quelle di subnet esistenti. Devi attivare l'inoltro dell'indirizzo IP sulle istanze di destinazione. Se abiliti l'inoltro dell'indirizzo IP, puoi accettare il traffico per gli indirizzi IP non assegnati alle istanze, in questo caso .

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 per raggiungere 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à: non è possibile collegare i controlli di integrità a delle route di Google Cloud. Le route vengono utilizzate a prescindere dall'integrità dai servizi VM sottostanti. Ogni volta che la VM è in esecuzione, instrada 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 ci sono 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 creare indirizzi IP mobili interni raggiungibili da reti on-premise o in peering, devi a distribuire le route statiche come descritto in precedenza.

Utilizzo di route ECMP (Equal-cost multipath)

La Route ECMP (equal-cost multipath) è simile al pattern di bilanciamento del carico sportivo-attivo: il traffico equamente distribuiti 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:

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

Il diagramma precedente mostra come un client interno accede a un servizio utilizzando uno di due route con l'hop successivo che punta alle istanze VM che implementano completamente gestito di Google Cloud.

Se il servizio su una VM non risponde, la riparazione automatica tenta di ricreare che non risponde. Quando la riparazione automatica elimina l'istanza, la route all'istanza diventa inattiva prima della creazione della nuova istanza. Una volta che la nuova istanza esiste, il percorso che punta a questa istanza è utilizzata immediatamente e automaticamente e il traffico viene distribuito equamente di Compute Engine.

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 associati a questo documento.

Utilizzo di route prioritarie 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 utilizza un route principale con un valore di priorità 500 che punta alla VM 1 come hop in condizioni normali. È disponibile una seconda route con un valore di priorità pari a 1000 che punta alla VM 2, la VM secondaria, come hop successivo.

Se il servizio sulla VM principale non risponde, la riparazione automatica tenta di ricreare l'istanza. Quando la riparazione automatica elimina l'istanza e prima del nuovo viene generata dall'istanza principale creata, ovvero la route principale nell'hop successivo, diventa inattivo. 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 il presente documento.

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

Se la tua applicazione implementa un meccanismo di heartbeat, come KeepaLive, per per monitorare la reattività dell'applicazione, puoi applicare il meccanismo per modificare l'hop successivo della route statica. In questo caso, utilizzi solo singola route statica con l'hop successivo che punta all'istanza VM principale. Attivato il failover, il meccanismo di heartbeat punta l'hop successivo della route una 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. Gli scambi di VM principali con la VM secondaria tramite KeepaLifetime. Al momento del failover, KeepaLifetime chiama una Cloud Function 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 un 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 KeepaLifetime, puoi richiamare uno script utilizzando l'notify_master variabile di configurazione che sostituisce la route statica utilizzando Chiamata API o il Google Cloud CLI.

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

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 VM principale precedente.
  3. Crea un percorso con lo stesso nome e la stessa priorità del percorso che hai appena eliminati. Puntala alla nuova VM principale come hop successivo.
  4. Elimina la nuova route statica creata. Non è necessario per garantire di 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.

Utilizzo del meccanismo di heartbeat per cambiare il pattern di priorità della route anziché gli altri pattern basati su route possono ridurre i tempi di failover. Non è necessario di eliminazione e sostituzione delle VM tramite la riparazione automatica 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 il battito cardiaco direttamente il meccanismo. Gestire il meccanismo può portare a una maggiore complessità. Un altro lo svantaggio è che devi concedere i privilegi per modificare il routing globale alle VM che eseguono il processo heartbeat o a un ambiente funzione chiamata dal processo 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 KeepaLifetime, vedi il deployment di esempio con Terraform su GitHub.

Sequenza con riparazione automatica

A seconda dei requisiti relativi al tempo di recupero, la migrazione a una singola istanza VM un'opzione praticabile 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

Utilizzando questo pattern, ci affiderai al meccanismo di riparazione automatica in un gruppo di istanze VM per sostituire automaticamente un'istanza VM difettosa. L'applicazione espone uno stato e quando l'applicazione non è integro, la riparazione automatica sostituisce la VM.

Il seguente diagramma mostra un'implementazione della singola istanza con riparazione automatica motivo:

Modalità di connessione di un client interno 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 con una dimensione pari a 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, 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 i controlli di integrità, errore, l'eliminazione e la ricreazione dell'istanza non riuscita richiede almeno minuto, ma spesso richiede più tempo. Questo pattern non è comune in produzione ambienti cloud-native. Tuttavia, il tempo di failover potrebbe essere sufficiente per servizi interni o sperimentali
  • Reazione agli errori di zona: un gruppo di istanze gestite con una dimensione pari a 1 non sopravvive a un guasto di una zona. Per reagire agli errori di zona, valuta la possibilità di aggiungere un 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é non puoi utilizzare lo stesso indirizzo IP utilizza un Zona privata Cloud DNS per indirizzare la VM e cambiare il nome DNS con il nuovo indirizzo IP.

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

Passaggi successivi