Questo documento illustra i comportamenti e le interazioni tra un'applicazione stateful, un agente per il controllo di integrità e un piano di controllo a livello di regione specifico dell'applicazione, che viene utilizzato per monitorare e orchestrare un failover a livello di zona eseguendo il deployment dei dischi permanenti a livello di regione.
Questo documento è destinato agli sviluppatori di applicazioni come follow-up delle opzioni di alta disponibilità che utilizzano dischi permanenti a livello di regione, ampliando il design e l'architettura descritti nella sezione Creare servizi di database ad alta disponibilità utilizzando dischi permanenti a livello di regione. Ti consigliamo di leggere prima questo documento, in particolare le sezioni sulle considerazioni sulla progettazione e su confronto dei costi, prestazioni e resilienza.
Un'applicazione stateless aumenta la resilienza in quanto almeno un'istanza di macchina virtuale (VM) secondaria è in esecuzione in una zona di Compute Engine diversa. In caso di errore dell'istanza VM principale, l'applicazione continua a essere eseguita sull'istanza VM secondaria. Un'applicazione stateful può mantenere il suo stato su un disco permanente di zona per ripristinarne lo stato dal riavvio di un'istanza VM. Per essere resiliente, un'applicazione stateful deve anche mantenere lo stato dell'applicazione su un'istanza VM secondaria.
Il seguente diagramma illustra una tipica applicazione stateful a due nodi che viene replicata tra due zone. L'applicazione in ogni zona dispone di un disco permanente a livello di zona per acquisire lo stato dell'applicazione e di una connessione di rete tra le istanze VM per sincronizzare le modifiche di stato dell'applicazione tra i nodi.
Aggiunta di un disco permanente a livello di regione
Un altro modo per sincronizzare lo stato dell'applicazione di un'applicazione stateful consiste nell'aggiungere un disco permanente a livello di regione. Quando un'applicazione scrive il proprio stato in un disco permanente a livello di regione, Google Cloud sincronizza automaticamente l'archiviazione a blocchi con un'altra zona. L'archiviazione su disco permanente a livello di regione contribuisce inoltre a garantire che al disco permanente a livello di regione sia collegata una sola istanza VM in entrambe le zone.
Il seguente diagramma mostra l'architettura di un'applicazione di database stateful.
Come mostra il diagramma precedente, sono ancora presenti due istanze VM dell'applicazione: un'istanza VM principale e un'istanza VM secondaria, di cui è stato eseguito il deployment in due zone. Oltre all'utilizzo di un disco permanente a livello di regione per l'archiviazione dello stato dell'applicazione, è ora disponibile un'entità aggiuntiva, il piano di controllo regionale specifico per l'applicazione. Il piano di controllo regionale specifico dell'applicazione decide a quale istanza VM è collegato il disco permanente a livello di regione e quale istanza VM è l'istanza VM principale attuale. Questa architettura è una configurazione attiva-passiva perché solo l'istanza VM principale può eseguire il commit di uno stato dell'applicazione sul disco permanente a livello di regione.
Istanze VM e applicazione stateful
Il diagramma dell'architettura precedente illustra un'applicazione di database attiva e passiva. Sono possibili anche le seguenti configurazioni:
- Se l'RTO (Recovery Time Objective) può consentirti la latenza aggiuntiva dell'avvio di un'istanza VM secondaria, puoi risparmiare sui costi di Compute Engine eseguendo solo l'istanza VM attiva. In un failover, il piano di controllo regionale specifico dell'applicazione avvia l'istanza VM secondaria e collega il disco permanente a livello di regione.
- Carichi di lavoro di elaborazione batch o flusso che verificano il loro avanzamento nel disco permanente a livello di regione. In un failover, l'applicazione riprende l'elaborazione dall'ultimo checkpoint.
Gestione degli avvii di istanze VM
Poiché alla volta è possibile collegare un disco permanente a livello di regione a una sola istanza VM, devi avviare le istanze VM e collegare il disco permanente a livello di regione in modo sistematico. Una best practice consiste nel separare l'istanza VM e l'avvio dell'applicazione dal collegamento del disco permanente a livello di regione. Gli script di avvio dell'istanza VM non devono avviare il collegamento del disco permanente a livello di regione. Gli script di avvio dovrebbero invece avviare l'agente per il controllo di integrità e attendere il collegamento del disco permanente a livello di regione.
All'avvio, l'istanza VM deve eseguire i seguenti passaggi sequenziali:
- Avvia l'agente per il controllo di integrità.
- Attendi il collegamento del disco permanente a livello di regione.
- Dopo aver collegato il disco permanente a livello di regione, monta il file system.
- Una volta montato il file system, avvia l'applicazione.
Questi passaggi riguardano l'avvio del sistema, ma è previsto anche un failover. Durante un failover, il disco permanente a livello di regione viene collegato forzatamente all'istanza VM secondaria. Il disco permanente a livello di regione viene inoltre rimosso forzatamente dall'istanza VM principale e le operazioni di I/O nel file system non riescono. A questo punto, devi arrestare o riavviare l'istanza VM.
Esecuzione dell'agente per il controllo di integrità e dei controlli di integrità
Come descritto nella sezione precedente, l'istanza VM attende che venga collegato il disco permanente a livello di regione prima di avviare l'applicazione. Il piano di controllo a livello di regione specifico dell'applicazione collega il disco permanente a livello di regione, ma solo a un'istanza VM in attesa del collegamento del disco. Quando viene collegato un disco, il piano di controllo specifico per l'applicazione monitora l'integrità dell'applicazione e avvia un failover se l'applicazione non è integro.
Ogni istanza VM ha uno dei seguenti stati:
- Giù
- In fase di avvio
- In attesa di un disco
- Applicazione in esecuzione
L'agente per il controllo di integrità segnala lo stato attuale dell'istanza VM. Anziché segnalare questi due stati tramite un singolo controllo di integrità, puoi eseguire due controlli di integrità binari. Se l'istanza VM è pronta per essere collegato al disco permanente a livello di regione o se il disco permanente a livello di regione è collegato e scrivibile, il controllo di integrità dell'istanza VM segnala uno stato integro. Se l'applicazione è in esecuzione e è in grado di scrivere lo stato dell'applicazione sul disco permanente a livello di regione, il controllo di integrità dell'applicazione segnala uno stato integro.
L'utilizzo di due controlli di integrità binaria presenta diversi vantaggi:
- Puoi utilizzare il servizio di controllo di integrità gestito di Compute Engine, che esegue il polling dell'agente per il controllo di integrità e risolve anche gli errori temporanei tramite il numero di soglie.
- Un gruppo di istanze gestite può monitorare il controllo di integrità dell'istanza e riparare automaticamente un'istanza VM in stato non integro.
- Il bilanciatore del carico può monitorare il controllo di integrità dell'applicazione e instradare il traffico all'istanza dell'applicazione attiva.
Per evitare che il sistema reagisca a un errore temporaneo, diminuisci la frequenza di segnalazione controllo di integrità o aumenta la soglia dei segnali ripetuti necessari per la transizione da un livello all'altro. Entrambi gli approcci ritardano la reazione del sistema a un'interruzione e aumentano i tempi di ripristino. Testando e misurando questi parametri, puoi regolare i parametri del controllo di integrità per bilanciare i tempi di recupero del sistema.
Informazioni sul piano di controllo a livello di regione specifico per l'applicazione
L'ultimo elemento dell'architettura è il piano di controllo per regione specifico dell'applicazione, responsabile delle due funzioni seguenti:
- Gestione del ciclo di vita delle istanze VM primarie 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 dell'applicazione orchestra il failover con i seguenti passaggi:
- Verifica che un'istanza VM secondaria sia in esecuzione e in attesa del collegamento del disco permanente a livello di regione.
- Forza il collegamento del disco permanente a livello di regione all'istanza VM secondaria.
- Monitora e riavvia l'istanza VM principale non riuscita. Quando l'istanza VM viene riavviata, il piano di controllo avvia un failover in base alle esigenze.
Il piano di controllo a livello di regione specifico dell'applicazione deve essere ad alta disponibilità nelle due zone in cui è in esecuzione l'applicazione. Nei data center on-premise, l'alta disponibilità (HA) viene spesso ottenuta eseguendo il deployment di server aggiuntivi per creare un quorum, decidere quale istanza VM sia l'istanza VM principale e orchestrare il failover. Questo approccio spesso utilizza strumenti di monitoraggio dell'alta disponibilità come Heartbeat, Pacemaker o Keepabeing.
Sebbene sia possibile utilizzare il piano di controllo 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 Cloud Functions, facili da gestire e distribuire.
- Controlli di integrità gestiti che riducono il carico del monitoraggio delle istanze dell'applicazione.
- Gruppi di istanze gestite che gestiscono il ciclo di vita delle istanze server.
Il seguente diagramma illustra l'utilizzo di Cloud Functions per il piano di controllo a livello di regione specifico dell'applicazione, insieme a un gruppo di istanze gestite stateful e ai controlli di integrità gestiti.
Il diagramma precedente mostra due istanze VM dell'applicazione, primarie e secondarie. Ogni istanza VM viene eseguita in una zona separata ed è gestita da un gruppo di istanze gestite a livello di regione stateful. Un disco permanente a livello di regione è disponibile nelle stesse due zone. Sono in esecuzione due servizi di controllo di integrità gestiti. Un servizio gestito di controllo di integrità monitora lo stato di integrità dell'istanza VM e viene utilizzato dal gruppo di istanze gestite stateful. L'altro servizio di controllo di integrità monitora lo stato di integrità dell'applicazione e viene utilizzato dal pool di destinazione del bilanciatore del carico.
Un piano di controllo a livello di regione specifico dell'applicazione interagisce con lo stato di integrità dell'applicazione del pool di destinazione e con il gruppo di istanze gestite a livello di regione stateful per monitorare lo stato dell'applicazione e per avviare il collegamento del disco permanente a livello di regione all'istanza VM in stato integro corrente.
Passaggi successivi
- Leggi Provisioning di dischi permanenti a livello di regione in Google Kubernetes Engine.
- Per informazioni su come adattare gli strumenti ad alta disponibilità on-premise per l'utilizzo in Google Cloud, consulta Pattern per l'utilizzo di indirizzi IP mobili.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.