Questo documento illustra i comportamenti e le interazioni tra un'applicazione con stato, un agente di controllo dell'integrità e un piano di controllo regionale specifico per l'applicazione utilizzato per monitorare e orchestrare un failover zonale tramite il deployment di dischi regionali replicati in modo sincrono.
Questo documento è rivolto agli sviluppatori di applicazioni come follow-up di Creare servizi HA utilizzando i dischi a livello di area geografica, e approfondisce il design e l'architettura descritti nella sezione Creare servizi di database HA utilizzando i dischi a livello di area geografica. Ti consigliamo di leggere prima questo documento, in particolare le sezioni relative alle considerazioni di progettazione e al confronto dei costi, al rendimento e alla resilienza.
Un'applicazione senza stato aumenta la resilienza disponendo di almeno un'istanza Compute Engine secondaria in esecuzione in una zona diversa. Quando l'istanza principale non va a buon fine, l'applicazione continua a funzionare sull'istanza secondaria. Un'applicazione con stato può mantenere costante il proprio stato su un disco zonale o su un disco disponibile in una sola zona per recuperare il suo stato da un riavvio dell'istanza. Per essere resiliente, un'applicazione stateful deve anche mantenere persistente lo stato dell'applicazione in un'istanza secondaria.
La Figura 1 mostra una tipica applicazione stateful a due nodi che viene replicata in due zone. L'applicazione in ogni zona ha un disco zonale per acquisire lo stato dell'applicazione e una connessione di rete tra le istanze per sincronizzare le modifiche dello stato dell'applicazione tra i nodi.
Figura 1. Applicazione stateful a due nodi senza dischi a livello di area geografica
Aggiunta di un disco regionale
Un altro modo per sincronizzare lo stato di un'applicazione stateful è aggiungere un disco regionale. Quando un'applicazione scrive il proprio stato su un disco regionale, Google Cloud sincronizza automaticamente lo spazio di archiviazione a blocchi con un'altra zona.
La Figura 2 mostra l'architettura di un'applicazione di database stateful.
Figura 2. Applicazione di database stateful
Come mostrato nella figura 2, sono ancora presenti due istanze di calcolo delle applicazioni, una principale e una secondaria, di cui è stato eseguito il deployment in due zone. Oltre all'utilizzo di un disco regionale per l'archiviazione dello stato dell'applicazione, ora è presente un'entità aggiuntiva, il piano di controllo regionale specifico per l'applicazione. Il piano di controllo regionale specifico per l'applicazione decide a quale istanza è collegato il disco regionale e quale istanza è l'istanza principale corrente. Questa architettura è una configurazione attiva-passiva perché solo l'istanza principale può eseguire il commit di uno stato dell'applicazione sul disco regionale.
Istanze di calcolo e l'applicazione stateful
La Figura 2 mostra un'applicazione di database attivo/passivo caldo. Sono possibili anche le seguenti configurazioni:
- Se il tuo obiettivo di tempo di recupero (RTO) può permettersi la latenza aggiuntiva dell'avvio di un'istanza secondaria, puoi risparmiare sui costi di Compute Engine eseguendo solo l'istanza attiva. In caso di failover, il piano di controllo regionale specifico per l'applicazione avvia l'istanza secondaria e collega il disco regionale a quell'istanza.
- Carichi di lavoro di elaborazione batch o in streaming che eseguono il checkpoint del loro avanzamento sul disco regionale. In caso di failover, l'applicazione riprende l'elaborazione dall'ultimo checkpoint.
Gestione delle avviamenti delle istanze Compute Engine
Poiché a una sola istanza di calcolo può essere collegato un disco regionale alla volta, devi avviare le istanze e collegare il disco regionale in modo sistematico. Una best practice consiste nel separare l'istanza di calcolo e l'avvio dell'applicazione dall'attacco del disco regionale. Gli script di avvio dell'istanza non devono avviare il collegamento del disco regionale. Gli script di avvio dovrebbero invece avviare l'agente di controllo di integrità e attendere che il disco regionale venga collegato.
All'avvio, l'istanza di calcolo deve eseguire i seguenti passaggi sequenziali:
- Avvia l'agente di controllo di integrità.
- Attendi che il disco a livello di regione venga collegato.
- Dopo aver collegato il disco regionale, monta il file system.
- Dopo aver montato il file system, avvia l'applicazione.
Questi passaggi riguardano l'avvio del sistema, ma è previsto anche un failover. Durante un failover, il disco regionale viene collegato forzatamente all'istanza secondaria. Anche il disco regionale viene rimosso forzatamente dall'istanza principale e le operazioni di I/O sul file system non vanno a buon fine. A questo punto, devi spegnere o riavviare l'istanza di calcolo.
Eseguire l'agente di controllo di integrità e i controlli di integrità
Come descritto nella sezione precedente, l'istanza di calcolo attende che il disco regionale venga collegato prima di avviare l'applicazione. Il piano di controllo regionale specifico per l'applicazione collega il disco regionale, ma solo a un'istanza di calcolo in attesa del collegamento del disco. Quando un disco è collegato, il piano di controllo specifico dell'applicazione monitora lo stato di salute dell'applicazione e avvia un failover se l'applicazione diventa non integra.
Ogni istanza di calcolo ha uno dei seguenti stati:
- Giù
- In fase di avvio
- In attesa di un disco
- Applicazione in esecuzione
L'agente di controllo di integrità segnala lo stato corrente dell'istanza. Anziché segnalare questi due stati tramite un singolo controllo di integrità, puoi eseguire due controlli di integrità binari. Se l'istanza di calcolo è pronta per il collegamento del disco regionale o se il disco regionale è collegato e scrivibile, il controllo di integrità dell'istanza segnala uno stato di integrità. Se l'applicazione è in esecuzione e riesce a scrivere lo stato dell'applicazione sul disco regionale, il controllo di integrità dell'applicazione segnala uno stato di integrità.
L'utilizzo di due controlli di integrità dei binari presenta diversi vantaggi:
- Puoi utilizzare il servizio di controllo di integrità gestito di Compute Engine, che esegue il polling dell'agente di controllo di integrità e risolve anche gli errori temporanei tramite conteggi delle soglie.
- Un gruppo di istanze gestite può monitorare il controllo di integrità dell'istanza e eseguire la riparazione automatica di un'istanza di calcolo non integra.
- Il bilanciatore del carico può monitorare il controllo di integrità dell'applicazione e instradare il traffico all'istanza dell'applicazione attiva.
Puoi impedire al sistema di reagire a un errore transitorio diminuendo la frequenza dei report di controllo di integrità dell'integrità o aumentando la soglia degli indicatori ripetuti necessari per passare da un livello all'altro. Entrambi gli approcci ritardano la reazione del sistema a un'interruzione e aumentano il tempo di recupero. Testando e misurando questi parametri, puoi aggiustare i parametri di controllo di integrità dell'integrità per bilanciare il tempo di recupero del sistema.
Informazioni sul piano di controllo regionale specifico per l'applicazione
L'elemento finale dell'architettura è il piano di controllo regionale specifico per l'applicazione, responsabile delle seguenti due funzioni:
- Gestione del ciclo di vita delle istanze di calcolo principali e secondarie.
- Decidere se è necessario un failover monitorando lo stato del controllo di integrità dell'applicazione.
Se è necessario un failover, il piano di controllo regionale specifico per l'applicazione orchestrerà il failover con i seguenti passaggi:
- Verifica che un'istanza secondaria sia in esecuzione e in attesa del collegamento del disco regionale.
- Forza il collegamento del disco a livello di regione all'istanza secondaria.
- Monitora e riavvia l'istanza principale non riuscita. Quando l'istanza principale viene riavviata, il control plane avvia un failback in base alle esigenze.
Il piano di controllo regionale specifico per l'applicazione deve essere altamente disponibile nelle due zone in cui è in esecuzione l'applicazione. Nei data center on-premise, l'alta disponibilità (HA) viene spesso raggiunta implementando server aggiuntivi per creare un quorum, decidere quale istanza di calcolo è l'istanza principale e orchestrare il failover. Questo approccio utilizza spesso strumenti di monitoraggio ad alta disponibilità come Heartbeat, Pacemaker o Keepalived.
Sebbene tu possa utilizzare il control plane regionale specifico per l'applicazione ovunque nel cloud, Google Cloud offre i seguenti servizi gestiti e disponibili a livello regionale che semplificano l'implementazione di questo approccio:
- Prodotti serverless di Google Cloud come App Engine, Cloud Run e funzioni Cloud Run, che sono facili da gestire ed eseguire il deployment.
- Controlli di integrità gestiti che offrono il monitoraggio delle istanze di calcolo che eseguono l'applicazione.
- Gruppi di istanze gestite che gestiscono il ciclo di vita delle istanze di calcolo.
La Figura 3 illustra l'utilizzo delle funzioni Cloud Run per il control plane regionale specifico dell'applicazione, insieme a un gruppo di istanze gestite con stato e a controlli di integrità gestiti.
Figura 3. Control plane regionale specifico per l'applicazione
La Figura 3 mostra due istanze di calcolo dell'applicazione, principale e secondaria. Ogni istanza viene eseguita in una zona separata ed è gestita da un MIG regionale stateful. Un disco regionale è disponibile nelle stesse due zone. Sono in esecuzione due servizi di controllo di integrità gestiti. Un servizio di controllo di integrità gestito monitora lo stato di integrità delle istanze e viene utilizzato dal MIG stateful. L'altro servizio di controllo di integrità monitora lo stato di salute dell'applicazione e viene utilizzato dal pool di destinazione del bilanciatore del carico.
Un piano di controllo regionale specifico per l'applicazione interagisce con lo stato di salute dell'applicazione del pool di destinazione e con il gruppo di istanze gestite regionale stateful per monitorare lo stato dell'applicazione e avviare l'attacco del disco regionale all'istanza di calcolo attualmente integra.
Passaggi successivi
- Leggi la sezione Provisioning dei dischi a livello di area geografica nella documentazione di Google Kubernetes Engine.
- Per scoprire come adattare gli strumenti di HA on-premise per l'utilizzo in Google Cloud, consulta Modelli per l'utilizzo di indirizzi IP flottanti.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.