Questo documento spiega i comportamenti e le interazioni tra un un'applicazione, un agente per il controllo di integrità e un controllo regionale specifico per l'applicazione utilizzato per monitorare e orchestrare un failover a livello di zona dischi permanenti a livello di regione.
Questo documento è rivolto agli sviluppatori di applicazioni come follow-up per Opzioni di alta disponibilità che utilizzano dischi permanenti a livello di regione sulla progettazione e l'architettura descritte nella sezione Creazione di servizi di database ad alta disponibilità utilizzando dischi permanenti a livello di regione. Ti consigliamo di leggere prima questo documento, in particolare le sezioni su Considerazioni sulla progettazione e confronto di costi, prestazioni e resilienza.
Un'applicazione stateless aumenta la resilienza avendo almeno un di un'istanza di macchina virtuale (VM) in esecuzione in un'altra zona di Compute Engine. Se la VM principale non funziona, l'applicazione continua a essere eseguita sulla VM secondaria. Un'applicazione stateful può mantenere il proprio stato su un disco permanente zonale per recuperarlo da un riavvio dell'istanza VM. Per essere resiliente, un'applicazione stateful deve anche mantenere costante lo stato dell'applicazione in una VM secondaria.
Il seguente diagramma illustra una tipica applicazione stateful a due nodi che viene replicato in due zone. L'applicazione in ogni zona ha una un disco permanente per acquisire lo stato dell'applicazione e una connessione di rete tra le istanze VM per sincronizzare le modifiche dello stato dell'applicazione nodi.
Aggiunta di un disco permanente a livello di regione
Un altro modo per sincronizzare lo stato di un'applicazione stateful è aggiungere un disco permanente a livello di regione. Quando un'applicazione scrive il proprio stato disco permanente regionale, Google Cloud sincronizza automaticamente archiviazione con un'altra zona.
Il seguente diagramma mostra l'architettura di un database stateful un'applicazione.
Come mostra il diagramma precedente, ci sono ancora due istanze VM dell'applicazione: principale e secondaria, di cui è stato eseguito il deployment in due zone. Oltre a utilizzare un disco permanente regionale per lo 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 VM è associato il disco permanente regionale e quale istanza VM è l'istanza VM principale corrente. Questa architettura è una configurazione attiva-passiva perché l'istanza VM principale può eseguire il commit di uno stato dell'applicazione nell'istanza un disco permanente standard.
Istanze VM e l'applicazione stateful
Il diagramma dell'architettura precedente illustra un database attivo, attivo e passivo un'applicazione. Sono possibili anche le seguenti configurazioni:
- Se il tuo RTO (Recovery Time Objective) può permettersi la latenza aggiuntiva di avviare un'istanza VM secondaria, puoi risparmiare sui Compute Engine eseguendo solo l'istanza VM attiva. In caso di failover, il piano di controllo regionale specifico per l'applicazione avvia l'istanza VM secondaria e collega il disco permanente regionale.
- Carichi di lavoro di elaborazione batch o in streaming che eseguono il checkpoint dell'avanzamento sul disco permanente regionale. In un failover, l'applicazione riprende l'elaborazione da quell'ultimo checkpoint.
Gestione degli avvii delle istanze VM
Perché è possibile collegare un disco permanente a livello di regione solo a una singola istanza VM devi avviare le istanze VM e collegare il cluster disco permanente in modo sistematico. Una best practice è 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 regionale permanente. Gli script di avvio dovrebbero invece avviare l'agente di controllo di integrità e attendere che il disco permanente regionale venga collegato.
All'avvio, l'istanza VM deve eseguire i seguenti passaggi sequenziali:
- Avvia l'agente per il controllo di integrità.
- Attendi che il disco permanente a livello di regione venga collegato.
- Dopo aver collegato il disco permanente a livello di regione, 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 permanente a livello di regione viene collegato forzatamente all'istanza VM secondaria. Il disco permanente regionale viene rimosso forzatamente anche dall'istanza VM principale e le operazioni di I/O sul file system non riescono. A questo punto, devi arrestare o riavviare l'istanza VM.
Eseguire l'agente di controllo di integrità e i controlli di integrità
Come descritto nella sezione precedente, l'istanza VM attende il parametro disco permanente da collegare prima di avviare l'applicazione. Il piano di controllo regionale specifico per l'applicazione collega il disco permanente regionale, ma solo a un'istanza VM in attesa del collegamento del disco. Quando viene collegato un disco, il piano di controllo specifico dell'applicazione ne monitora l'integrità e avvia un failover se l'applicazione diventa non integra.
Ogni istanza VM ha uno dei seguenti stati:
- Giù
- In fase di avvio
- In attesa di un disco
- Applicazione in esecuzione
L'agente del controllo di integrità segnala lo stato attuale dell'istanza VM. Invece di questi due stati tramite un singolo controllo di integrità, puoi eseguire due e controlli di integrità. Se l'istanza VM è pronta per l'attacco del disco permanente regionale o se il disco permanente regionale è collegato e scrivibile, il controllo di integrità dell'istanza VM segnala uno stato di integrità. Se l'applicazione è in esecuzione ed è in grado di scrivere lo stato dell'applicazione sul disco permanente a livello di regione, il controllo di integrità dell'applicazione segnala uno stato di integrità.
L'uso di due controlli di integrità binari offre diversi vantaggi:
- Puoi utilizzare l'API Compute Engine servizio di controllo di integrità gestito, che esegue il polling dell'agente per il controllo di integrità e risolve anche gli errori temporanei tramite i conteggi delle soglie.
- R gruppo di istanze gestite puoi monitorare il controllo di integrità dell'istanza riparazione automatica di 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.
Puoi impedire al sistema di reagire a un errore transitorio diminuendo la frequenza dei report 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 e aumentano il tempo di recupero. Testando e misurando questi parametri, puoi aggiustare i parametri di controllo dell'integrità per bilanciare il tempo di recupero del sistema.
Informazioni sul piano di controllo regionale specifico per l'applicazione
L'ultimo elemento dell'architettura è la copertura regionale di controllo, che è responsabile delle due funzioni seguenti:
- Gestione del ciclo di vita delle istanze VM principali e secondarie.
- Per decidere se è necessario un failover, monitorando lo stato 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 VM secondaria sia in esecuzione e in attesa dell'associazione del disco permanente regionale.
- Forza il collegamento del disco permanente a livello di regione all'istanza VM secondaria.
- Monitora e riavvia l'istanza VM principale in errore. Quando l'istanza VM viene riavviata, il piano di controllo avvia un failback in base alle esigenze.
Il piano di controllo regionale specifico dell'applicazione deve essere ad alta disponibilità tra le due zone in cui è in esecuzione l'applicazione. Nei dati on-premise center, l'alta disponibilità (HA) viene spesso ottenuta eseguendo il deployment per creare un quorum, decidere quale istanza VM è l'istanza VM principale e orchestrare il failover. Questo approccio utilizza spesso strumenti di monitoraggio HA come Heartbeat, Pacemaker o Keepalived.
Sebbene sia possibile utilizzare il piano di controllo a livello di regione specifico dell'applicazione nel cloud, Google Cloud offre le seguenti funzionalità disponibili 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 limitano il monitoraggio dell'applicazione di Compute Engine.
- Gruppi di istanze gestite che gestiscono il ciclo di vita delle istanze server.
Il seguente diagramma illustra l'utilizzo delle funzioni di Cloud Run per il un piano di controllo regionale specifico per l'applicazione, insieme gruppo di istanze gestite stateful e controlli di integrità gestiti.
Il diagramma precedente mostra due istanze VM dell'applicazione, principale e secondaria. Ogni istanza VM viene eseguita in una zona separata ed è gestita da un MIG regionale con stato. Un disco permanente 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 VM e viene utilizzato dal gruppo di istanze gestite stateful. L'altro servizio di controllo di integrità monitora l'applicazione, di integrità e viene utilizzato dal pool di destinazione del bilanciatore del carico.
Un piano di controllo regionale specifico per l'applicazione interagisce con 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 della richiesta e iniziare il collegamento il disco permanente a livello di regione all'istanza VM integro attuale.
Passaggi successivi
- Leggi l'articolo Provisioning di dischi permanenti a livello di area geografica in 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 fluttuanti.
- Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.