Questo documento spiega i comportamenti e le interazioni tra un'applicazione stateful, un agente di controllo dell'integrità e un control plane regionale specifico per l'applicazione utilizzato per monitorare e orchestrare un failover a livello di zona tramite il deployment di dischi regionali replicati in modo sincrono.
Questo documento è rivolto agli sviluppatori di applicazioni e riprende quanto introdotto in Crea servizi ad alta affidabilità utilizzando i dischi a livello di regione, e approfondisce il design e l'architettura descritti nella sezione Creazione di servizi di database ad alta affidabilità utilizzando i dischi a livello di regione. Ti consigliamo di consultare prima suddetto documento, in particolare le sezioni relative alle considerazioni sulla progettazione e al confronto dei costi, alle prestazioni e alla resilienza.
Un'applicazione stateless aumenta la resilienza, in quanto dispone di almeno un'istanza Compute Engine secondaria in esecuzione in una zona diversa. Quando l'istanza principale non funziona correttamente, l'esecuzione dell'applicazione continua sull'istanza secondaria. Un'applicazione stateful può conservare il proprio stato su un disco a livello di zona o su un disco disponibile in una sola zona, così da ripristinare lo stato da un riavvio dell'istanza. Per essere resiliente, un'applicazione stateful deve anche conservare 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 dispone di un disco a livello di zona per acquisire lo stato e una connessione di rete tra le istanze per sincronizzare tra i nodi le modifiche di stato dell'applicazione.
Figura 1. Applicazione stateful a due nodi senza dischi a livello di regione
Aggiunta di un disco a livello di regione
Un altro modo per sincronizzare lo stato di un'applicazione stateful è aggiungere un disco a livello di regione. Quando un'applicazione scrive il proprio stato su un disco a livello di regione, 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 computing dell'applicazione, una principale e una secondaria, di cui è stato eseguito il deployment in due zone. Oltre a utilizzare un disco a livello di regione per l'archiviazione dello stato dell'applicazione, ora è presente un'entità aggiuntiva, il control plane regionale specifico per l'applicazione. Il control plane regionale specifico per l'applicazione decide a quale istanza è collegato il disco a livello di regione e qual è l'istanza principale corrente. Si tratta di un'architettura con configurazione attiva/passiva perché solo l'istanza principale può eseguire il commit di uno stato dell'applicazione sul disco a livello di regione.
Istanze di computing e applicazione stateful
La Figura 2 mostra un'applicazione di database attivo/passivo hot. Sono possibili anche le seguenti configurazioni:
- Se in base al tuo Recovery Time Objective (RTO) puoi disporre di una latenza aggiuntiva dovuta all'avvio di un'istanza secondaria, puoi risparmiare sui costi di Compute Engine eseguendo solo l'istanza attiva. In caso di failover, il control plane regionale specifico per l'applicazione avvia l'istanza secondaria e vi collega il disco a livello di regione.
- Workload di elaborazione batch o dei flussi che creano checkpoint del proprio avanzamento nel disco a livello di regione. In caso di failover, l'applicazione riprende l'elaborazione dall'ultimo checkpoint.
Gestione degli avvii delle istanze di Compute Engine
Poiché a un'unica istanza di computing può essere collegato un disco a livello di regione alla volta, devi avviare le istanze e collegare il disco regionale in modo sistematico. Una best practice consiste nel separare la fase di avvio dell'istanza di computing e dell'applicazione dal collegamento del disco a livello di regione. Gli script di avvio dell'istanza non devono avviare il collegamento del disco a livello di regione, ma dovrebbero invece avviare l'agente di controllo di integrità e attendere il collegamento del disco a livello di regione.
All'avvio, l'istanza di computing deve eseguire i seguenti passaggi sequenziali:
- Avviare l'agente di controllo di integrità.
- Attendere che il disco a livello di regione venga collegato.
- Dopo il collegamento, montare il file system.
- Dopo aver montato il file system, avviare l'applicazione.
Questi passaggi riguardano l'avvio del sistema, ma è previsto anche un failover. Durante un failover, il disco a livello di regione viene collegato forzatamente all'istanza secondaria. Anche il disco a livello di regione viene rimosso forzatamente dall'istanza principale e le operazioni di I/O sul file system non vanno a buon fine. A questo punto, devi arrestare o riavviare l'istanza di computing.
Esecuzione dell'agente di controllo di integrità e dei controlli di integrità
Come descritto nella sezione precedente, l'istanza di computing attende che il disco a livello di regione venga collegato prima di avviare l'applicazione. Il control plane regionale specifico per l'applicazione collega il disco regionale, ma solo a un'istanza di computing in attesa del collegamento. Quando un disco viene collegato, il control plane specifico dell'applicazione monitora lo stato di salute dell'applicazione e avvia un failover se questa diventa non integra.
Ogni istanza di computing ha uno dei seguenti stati:
- Non attivo
- 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é registrare questi due stati tramite un singolo controllo di integrità, puoi eseguire due controlli di integrità binari. Se l'istanza di computing è pronta per il collegamento del disco a livello di regione o se quest'ultimo è collegato e scrivibile, il controllo di integrità dell'istanza segnala uno stato integro. Se l'applicazione è in esecuzione e riesce a scrivere lo stato dell'applicazione sul disco a livello di regione, il controllo di integrità dell'applicazione segnala uno stato integro.
L'utilizzo di due controlli di integrità dei file 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 (MIG) può monitorare il controllo di integrità dell'istanza e eseguire la riparazione automatica di un'istanza di computing non integra.
- Il bilanciatore del carico può monitorare il controllo di integrità dell'applicazione e instradare il traffico verso l'istanza dell'applicazione attiva.
Puoi impedire al sistema di reagire a un errore transitorio diminuendo la frequenza delle segnalazioni di controllo 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 del servizio e aumentano il tempo di recupero. Testando e misurando questi parametri, puoi regolare i parametri di controllo di integrità in modo da trovare il giusto equilibrio per il tempo di recupero del sistema.
Informazioni sul control plane regionale specifico per l'applicazione
L'elemento finale dell'architettura è il control plane regionale specifico per l'applicazione, che si occupa delle seguenti due funzioni:
- Gestione del ciclo di vita delle istanze di computing principali e secondarie.
- Decidere se è necessario un failover attraverso il monitoraggio dello stato del controllo di integrità dell'applicazione.
In tal caso, il control plane 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 a livello di regione.
- Forza il collegamento del disco a livello di regione all'istanza secondaria.
- Monitora e riavvia l'istanza principale in errore. Quando l'istanza principale viene riavviata, il control plane avvia un failback in base alle esigenze.
Il control plane 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 affidabilità (HA) viene spesso raggiunta eseguendo il deployment di server aggiuntivi per creare un quorum, decidere quale istanza di computing è quella principale e orchestrare il failover. Questo approccio utilizza spesso strumenti di monitoraggio ad alta affidabilità come Heartbeat, Pacemaker o Keepalived.
Sebbene sia possibile 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 serverlessGoogle Cloud come App Engine, Cloud Run e Cloud Run Functions, la cui gestione e deployment non presentano difficoltà.
- Controlli di integrità gestiti che permettono di monitorare le istanze di computing che eseguono l'applicazione.
- Gruppi di istanze gestite che gestiscono il ciclo di vita delle istanze di computing.
La Figura 3 illustra l'utilizzo delle Cloud Run Functions per il control plane regionale specifico dell'applicazione, insieme a un gruppo di istanze gestite stateful e a controlli di integrità gestiti.
Figura 3. Control plane regionale specifico per l'applicazione
La Figura 3 mostra due istanze di computing dell'applicazione, principale e secondaria. Ogni istanza viene eseguita in una zona separata ed è gestita da un MIG regionale stateful. Un disco a livello di regione è 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 control plane regionale specifico per l'applicazione interagisce con lo stato di salute dell'applicazione nel pool di destinazione e con il MIG regionale stateful per monitorare lo stato dell'applicazione e avviare il collegamento del disco a livello di regione all'istanza di computing che attualmente è integra.
Passaggi successivi
- Leggi la sezione Provisioning dei dischi a livello di regione nella documentazione di Google Kubernetes Engine.
- Per scoprire come adattare gli strumenti ad alta affidabilità on-premise per l'utilizzo in Google Cloud, consulta Modelli per l'utilizzo di indirizzi IP mobili.
- Esplora architetture di riferimento, diagrammi e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.