Questo articolo fa parte di una serie che illustra il ripristino di emergenza (RE) in Google Cloud. Questa parte esplora scenari comuni di ripristino di emergenza per le applicazioni.
La serie è composta dai seguenti componenti:
- Guida alla pianificazione del ripristino di emergenza
- Componenti di base per il ripristino di emergenza
- Scenari di ripristino di emergenza per i dati
- Scenari di ripristino di emergenza per le applicazioni (questo articolo)
- Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località
- Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati limitate a livello di località
- Architettura del ripristino di emergenza per eventuali interruzioni dell'infrastruttura cloud
Introduzione
Questo articolo descrive gli scenari di RE per le applicazioni in termini di pattern di ripristino di emergenza, che indicano con quanta rapidità l'applicazione può recuperare da un evento di emergenza. Utilizza i concetti illustrati nell'articolo sui componenti di base di RE per descrivere come implementare un piano di ripristino di emergenza end-to-end appropriato per i tuoi obiettivi di ripristino.
Per iniziare, considera alcuni carichi di lavoro tipici per illustrare come la valutazione degli obiettivi e dell'architettura di recupero abbia un'influenza diretta sul piano di RE.
Carichi di lavoro per l'elaborazione batch
I carichi di lavoro di elaborazione batch tendono a non essere mission critical, quindi in genere non è necessario sostenere i costi di progettazione di un'architettura ad alta disponibilità (HA) per massimizzare l'uptime. In generale, i carichi di lavoro di elaborazione batch sono in grado di gestire le interruzioni. Questo tipo di carico di lavoro può sfruttare prodotti economici come le istanze VM prerilasciabili, ovvero un'istanza che puoi creare ed eseguire a un prezzo molto inferiore rispetto alle istanze normali. Tuttavia, Compute Engine terminerà (prerilasciando) queste istanze se richiede l'accesso alle risorse per altre attività e verranno terminate fino a 24 ore dopo l'avvio.
Se implementi checkpoint regolari come parte dell'attività di elaborazione, il job di elaborazione può riprendere dal punto di errore quando vengono avviate le nuove VM. Se utilizzi Dataproc, il processo di avvio dei nodi worker prerilasciabili è gestito da un gruppo di istanze gestite. Questo può essere considerato un pattern caldo, con una breve pausa in cui la VM sostitutiva continua l'elaborazione.
Siti di e-commerce
Nei siti di e-commerce, alcune parti dell'applicazione possono avere valori RTO più elevati. Ad esempio, l'effettiva pipeline di acquisto deve avere un'alta disponibilità, ma il processo email che invia le notifiche degli ordini ai clienti può tollerare un ritardo di alcune ore. I clienti sono a conoscenza dell'acquisto e, sebbene si aspettino un'email di conferma, la notifica non è una parte cruciale della procedura. Si tratta di una combinazione di modelli caldi (di acquisto) e caldi/freddi (notifiche).
La parte transazionale dell'applicazione richiede un uptime elevato con un valore RTO minimo. Pertanto, utilizzerai l'alta disponibilità, che massimizza la disponibilità di questa parte dell'applicazione. Questo approccio può essere considerato un modello caldo.
Lo scenario di e-commerce mostra come avere valori RTO variabili all'interno della stessa applicazione.
Streaming video
Una soluzione di streaming video include molti componenti che devono garantire un'elevata disponibilità, dall'esperienza di ricerca al processo effettivo di streaming di contenuti per l'utente. Inoltre, il sistema richiede una bassa latenza per creare un'esperienza utente soddisfacente. Se un qualsiasi aspetto della soluzione non riesce a garantire un'esperienza ottimale, è negativo sia per il fornitore che per il cliente. Inoltre, i clienti oggi possono scegliere un prodotto competitivo.
In questo scenario, un'architettura ad alta disponibilità è un must e sono necessari piccoli valori RTO. Questo scenario richiede un pattern a caldo nell'intera architettura dell'applicazione per garantire un impatto minimo in caso di emergenza.
Architetture di RE e ad alta disponibilità per la produzione on-premise
Questa sezione esamina come implementare tre pattern (freddo, caldo e caldo) quando l'applicazione viene eseguita on-premise e la soluzione di RE si trova su Google Cloud.
Modello a freddo: ripristino in Google Cloud
In un pattern a freddo, hai risorse minime nel progetto Google Cloud di ripristino di emergenza, solo quanto basta per abilitare uno scenario di ripristino. Quando si verifica un problema che impedisce all'ambiente di produzione di eseguire carichi di lavoro di produzione, la strategia di failover richiede l'avvio di un mirroring dell'ambiente di produzione in Google Cloud. I client iniziano a utilizzare i servizi dall'ambiente di ripristino di emergenza.
In questa sezione esaminiamo un esempio di questo modello. Nell'esempio, Cloud Interconnect è configurato con una soluzione VPN autogestita (non Google Cloud) per fornire la connettività a Google Cloud. I dati vengono copiati in Cloud Storage come parte dell'ambiente di produzione.
Componenti di base per RE:
- Cloud DNS
- Cloud Interconnect
- Soluzione VPN autogestita
- Cloud Storage
- Compute Engine
- Cloud Load Balancing
- Deployment Manager
Il seguente diagramma illustra questa architettura di esempio:
I passaggi seguenti spiegano come configurare l'ambiente:
- Crea una rete VPC.
- Configura la connettività tra la tua rete on-premise e la rete Google Cloud.
- Crea un bucket Cloud Storage come destinazione per il backup dei dati.
- Genera una chiave dell'account di servizio per un account di servizio dedicato. Questo file viene utilizzato per passare le credenziali a uno script automatico.
Copia la chiave dell'account di servizio nella macchina on-premise in cui eseguirai lo script che carica i backup del database. Potrebbe essere il server del tuo database, ma i tuoi criteri di sicurezza potrebbero non consentirti di installare software aggiuntivo sul server di database.
Crea un criterio IAM per limitare l'accesso al bucket e ai suoi oggetti. Includi l'account di servizio creato appositamente per questo scopo. Puoi anche aggiungere l'account utente o il gruppo al criterio per l'operatore o l'amministratore di sistema, concedendo a tutte queste identità le autorizzazioni pertinenti. Per maggiori dettagli sulle autorizzazioni per l'accesso a Cloud Storage, consulta Autorizzazioni IAM per Cloud Storage.
Verifica di poter caricare e scaricare file nel bucket di destinazione.
Crea uno script di trasferimento dei dati.
Crea un'attività pianificata per eseguire lo script.
Crea immagini personalizzate configurate per ogni server nell'ambiente di produzione. Ogni immagine deve avere la stessa configurazione dell'equivalente on-premise.
Come parte della configurazione delle immagini personalizzate del server di database, crea uno script di avvio che copierà automaticamente l'ultimo backup da un bucket Cloud Storage all'istanza, quindi richiamerà il processo di ripristino.
Configura Cloud DNS per puntare ai servizi web per internet.
Crea un modello Deployment Manager per creare server delle applicazioni nella tua rete Google Cloud utilizzando le immagini personalizzate configurate in precedenza. Questo modello dovrebbe anche configurare le regole firewall appropriate richieste.
Devi implementare i processi per garantire che le immagini personalizzate abbiano la stessa versione dell'applicazione dell'applicazione on-premise. Assicurati di incorporare gli upgrade alle immagini personalizzate come parte del tuo ciclo di upgrade standard e verifica che il tuo modello Deployment Manager utilizzi l'immagine personalizzata più recente.
Processo di failover e attività post-riavvio
In caso di emergenza, puoi eseguire il ripristino nel sistema in esecuzione su Google Cloud. A questo scopo, avvia il processo di recupero per creare l'ambiente di ripristino utilizzando il modello di Deployment Manager che hai creato. Quando le istanze nell'ambiente di ripristino sono pronte per accettare il traffico di produzione, puoi modificare il DNS in modo che rimandi al server web in Google Cloud.
Una sequenza di recupero tipica è la seguente:
- Utilizza il modello Deployment Manager per creare un deployment in Google Cloud.
- Applica il backup del database più recente in Cloud Storage al server di database in esecuzione in Google Cloud seguendo le istruzioni fornite dal tuo sistema di database per recuperare i file di backup.
- Applica i log delle transazioni più recenti in Cloud Storage.
- Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente recuperato.
- Una volta riusciti i test, configura Cloud DNS in modo che punti al server web su Google Cloud. Ad esempio, puoi utilizzare un indirizzo IP anycast dietro un bilanciatore del carico Google Cloud, mentre più server web sono dietro il bilanciatore del carico.
Il seguente diagramma mostra l'ambiente recuperato:
Quando l'ambiente di produzione è di nuovo in esecuzione on-premise e l'ambiente è in grado di supportare i carichi di lavoro di produzione, inverti i passaggi seguiti per eseguire il failover nell'ambiente di ripristino di Google Cloud. Una sequenza tipica per tornare all'ambiente di produzione è questa:
- Esegui un backup del database in esecuzione su Google Cloud.
- Copia il file di backup nell'ambiente di produzione.
- Applica il file di backup al sistema di database di produzione.
- Impedisci le connessioni all'applicazione in Google Cloud. Ad esempio, impedire le connessioni al bilanciatore del carico globale. Da questo momento in poi, l'applicazione non sarà disponibile finché non avrai completato il ripristino dell'ambiente di produzione.
- Copia tutti i file di log delle transazioni nell'ambiente di produzione e applicali al server di database.
- Configura Cloud DNS per puntare al tuo servizio web on-premise.
- Assicurati che il processo adottato per copiare i dati in Cloud Storage funzioni come previsto.
- Eliminare il deployment.
Caldo standby: ripristino a Google Cloud
In genere viene implementato un pattern caldo per mantenere i valori RTO e RPO il più ridotti possibile, senza lo sforzo e i costi di una configurazione completamente ad alta disponibilità. Minore è il valore dell'RTO e dell'RPO, maggiori sono i costi man mano che ti avvicini ad avere un ambiente completamente ridondante in grado di gestire il traffico da due ambienti. Pertanto, l'implementazione di un pattern caldo per lo scenario di RE è un buon compromesso tra budget e disponibilità.
Un esempio di questo approccio è l'utilizzo di Cloud Interconnect configurato con una soluzione VPN autogestita per fornire connettività a Google Cloud. Un'applicazione a più livelli viene eseguita on-premise con una suite di ripristino minima su Google Cloud. La suite di ripristino è composta da un'istanza del server di database operativa su Google Cloud. Questa istanza deve essere eseguita sempre, in modo da poter ricevere transazioni replicate tramite tecniche di replica asincrone o semisincrone. Per ridurre i costi, puoi eseguire il database sul tipo di macchina più piccolo in grado di eseguire il servizio di database. Poiché puoi utilizzare un'istanza a lunga esecuzione, verranno applicati gli sconti per utilizzo sostenuto.
Componenti di base per RE:
- Cloud DNS
- Cloud Interconnect
- Soluzione VPN autogestita
- Compute Engine
- Deployment Manager
Gli snapshot di Compute Engine offrono un modo per eseguire backup di cui puoi eseguire il rollback a uno stato precedente. In questo esempio vengono utilizzati gli snapshot perché le pagine web aggiornate e i programmi binari delle applicazioni vengono scritti spesso sul web di produzione e sui server delle applicazioni. Questi aggiornamenti vengono regolarmente replicati nelle istanze del server web e del server applicazioni di riferimento su Google Cloud. I server di riferimento non accettano traffico di produzione, ma vengono utilizzati per creare gli snapshot.
Il seguente diagramma illustra un'architettura che implementa questo approccio. Le destinazioni di replica non sono mostrate nel diagramma.
I passaggi seguenti spiegano come configurare l'ambiente:
- Crea una rete VPC.
- Configura la connettività tra la tua rete on-premise e la rete Google Cloud.
- Replica i tuoi server on-premise nelle istanze VM di Google Cloud. Un'opzione consiste nell'utilizzare una soluzione partner; il metodo da utilizzare dipende dalle circostanze.
- Crea un'immagine personalizzata del tuo server di database su Google Cloud con la stessa configurazione del server di database on-premise.
- Crea snapshot delle istanze del server web e del server applicazioni.
- Avvia un'istanza di database in Google Cloud utilizzando l'immagine personalizzata che hai creato in precedenza. Utilizza il tipo di macchina più piccolo in grado di accettare dati replicati dal database di produzione on-premise.
- Collega dischi permanenti all'istanza del database Google Cloud per i log delle transazioni e dei database.
- Configura la replica tra il server di database on-premise e il server di database in Google Cloud seguendo le istruzioni del software del database.
- Imposta il flag autodelete sui dischi permanenti collegati all'istanza del database su
no-auto-delete. - Configura un'attività pianificata per creare snapshot regolari dei dischi permanenti dell'istanza di database su Google Cloud.
- Crea prenotazioni per garantire la capacità del tuo server web e dei server di applicazioni in base alle esigenze.
- Verifica il processo di creazione di istanze dagli snapshot e di creazione di snapshot dei dischi permanenti.
- Crea istanze del server web e del server applicazioni utilizzando gli snapshot creati in precedenza.
- Crea uno script che copi gli aggiornamenti dell'applicazione web e del server delle applicazioni ogni volta che i server on-premise corrispondenti vengono aggiornati. Scrivi lo script per creare uno snapshot dei server aggiornati.
- Configura Cloud DNS per puntare al tuo servizio web per internet on-premise.
Processo di failover e attività post-riavvio
Per gestire un failover, in genere viene usato il sistema di monitoraggio e avviso per richiamare un processo di failover automatico. Quando l'applicazione on-premise deve eseguire il failover, devi configurare il sistema di database su Google Cloud in modo che possa accettare il traffico di produzione. Avvia anche le istanze del server web e delle applicazioni.
Il seguente diagramma mostra la configurazione dopo il failover a Google Cloud che consente la gestione dei carichi di lavoro di produzione da Google Cloud:
Una sequenza di recupero tipica è la seguente:
- Ridimensiona l'istanza del server di database in modo che possa gestire i carichi di produzione.
- Utilizza il server web e gli snapshot delle applicazioni su Google Cloud per creare nuovi server web e istanze di applicazioni.
- Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente recuperato.
- Se i test hanno esito positivo, configura Cloud DNS in modo che punti al tuo servizio web su Google Cloud.
Quando l'ambiente di produzione è di nuovo in esecuzione on-premise e può supportare i carichi di lavoro di produzione, inverti i passaggi seguiti per eseguire il failover nell'ambiente di ripristino di Google Cloud. Una sequenza tipica per tornare all'ambiente di produzione è la seguente:
- Esegui un backup del database in esecuzione su Google Cloud.
- Copia il file di backup nell'ambiente di produzione.
- Applica il file di backup al sistema di database di produzione.
- Impedisci le connessioni all'applicazione in Google Cloud. Un modo per farlo è impedire le connessioni al server web modificando le regole firewall. Da questo momento in poi, l'applicazione non sarà disponibile finché non avrai completato il ripristino dell'ambiente di produzione.
- Copia tutti i file di log delle transazioni nell'ambiente di produzione e applicali al server di database.
- Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente di produzione.
- Configura Cloud DNS per puntare al tuo servizio web on-premise.
- Elimina le istanze del server web e del server applicazioni in esecuzione in Google Cloud. Lascia in esecuzione i server di riferimento.
- Ridimensiona il server di database su Google Cloud riportandolo alla dimensione minima dell'istanza che può accettare dati replicati dal database di produzione on-premise.
- Configura la replica tra il server di database on-premise e il server di database in Google Cloud seguendo le istruzioni del software del database.
Alta disponibilità elevata in ambienti on-premise e Google Cloud
Se disponi di valori RTO e RPO ridotti, puoi ottenerli solo eseguendo l'alta disponibilità nel tuo ambiente di produzione e su Google Cloud contemporaneamente. Questo approccio prevede un modello ad accesso frequente, perché sia il traffico on-premise che Google Cloud gestiscono il traffico di produzione.
La differenza fondamentale rispetto al pattern caldo è che le risorse in entrambi gli ambienti vengono eseguite in modalità di produzione e gestiscono il traffico di produzione.
Componenti di base per RE:
- Cloud Interconnect
- Cloud VPN
- Compute Engine
- gruppi di istanze gestite
- Cloud Monitoring
- Cloud Load Balancing
Il seguente diagramma illustra questa architettura di esempio. Se implementi questa architettura, hai un piano di RE che richiede un intervento minimo in caso di emergenza.
I passaggi seguenti spiegano come configurare l'ambiente:
- Crea una rete VPC.
- Configura la connettività tra la tua rete on-premise e la rete Google Cloud.
- Crea in Google Cloud immagini personalizzate configurate per ciascun server nell'ambiente di produzione on-premise. Ogni immagine Google Cloud deve avere la stessa configurazione dell'equivalente on-premise.
Configura la replica tra il server di database on-premise e il server di database in Google Cloud seguendo le istruzioni del software del database.
Molti sistemi di database consentono una sola istanza di database scrivibile quando configuri la replica. Pertanto, potresti dover assicurarti che una delle repliche del database agisca da server di sola lettura.
Creare singoli modelli di istanza che utilizzano le immagini per i server delle applicazioni e i server web.
Configura i gruppi di istanze gestite a livello di regione per l'applicazione e i server web.
Configura i controlli di integrità utilizzando Cloud Monitoring.
Configura il bilanciamento del carico utilizzando i gruppi di istanze gestite a livello di regione configurati in precedenza.
Configura un'attività pianificata per creare snapshot regolari dei dischi permanenti.
Configura un servizio DNS per distribuire il traffico tra il tuo ambiente on-premise e l'ambiente Google Cloud.
Con questo approccio ibrido, devi utilizzare un servizio DNS che supporti il routing ponderato verso i due ambienti di produzione, in modo da poter gestire la stessa applicazione da entrambi.
Devi progettare il sistema per individuare errori che potrebbero verificarsi solo in una parte di un ambiente (errori parziali). In questo caso, il traffico deve essere reindirizzato al servizio equivalente nell'altro ambiente di backup. Ad esempio, se i server web on-premise non sono più disponibili, puoi disattivare il routing DNS verso quell'ambiente. Se il tuo servizio DNS supporta i controlli di integrità, ciò avverrà automaticamente quando il controllo di integrità determina che i server web in uno degli ambienti non possono essere raggiunti.
Se utilizzi un sistema di database che consente una sola istanza scrivibile, in molti casi il sistema di database promuoverà automaticamente la replica di sola lettura a principale scrivibile quando l'heartbeat tra il database originale scrivibile e la replica di lettura perde il contatto. Assicurati di comprendere questo aspetto della replica del database nel caso in cui sia necessario intervenire dopo un'emergenza.
Devi implementare i processi per garantire che le immagini VM personalizzate in Google Cloud abbiano la stessa versione dell'applicazione delle versioni on-premise. Incorpora upgrade alle immagini personalizzate come parte del tuo ciclo di upgrade standard e assicurati che il tuo modello Deployment Manager utilizzi l'immagine personalizzata più recente.
Processo di failover e attività post-riavvio
Nella configurazione descritta qui per uno scenario caldo, un'emergenza significa che uno dei due ambienti non è disponibile. Non esiste un processo di failover come negli scenari a caldo o a freddo, in cui è necessario spostare i dati o l'elaborazione nel secondo ambiente. Tuttavia, potrebbe essere necessario gestire le seguenti modifiche alla configurazione:
- Se il tuo servizio DNS non reindirizza automaticamente il traffico in base a un errore del controllo di integrità, devi riconfigurare manualmente il routing DNS per inviare il traffico al sistema ancora attivo.
- Se il tuo sistema di database non promuove automaticamente una replica di sola lettura come principale scrivibile in caso di errore, devi intervenire per assicurarti che la replica venga promossa.
Quando il secondo ambiente è di nuovo in esecuzione ed è in grado di gestire il traffico di produzione, devi risincronizzare i database. Poiché entrambi gli ambienti supportano i carichi di lavoro di produzione, non devi intraprendere ulteriori azioni per cambiare il database principale. Dopo aver sincronizzato i database, puoi consentire la distribuzione del traffico di produzione tra entrambi gli ambienti regolando le impostazioni DNS.
Architetture di RE e ad alta disponibilità per la produzione su Google Cloud
Quando progetti l'architettura dell'applicazione per il carico di lavoro di produzione su Google Cloud, le funzionalità ad alta disponibilità della piattaforma hanno un'influenza diretta sull'architettura di RE.
A freddo: server applicazioni recuperabili
In uno scenario di failover a freddo in cui è necessaria una singola istanza server attiva, solo un'istanza deve scrivere su disco. In un ambiente on-premise, spesso utilizzi un cluster attivo / passivo. Quando esegui un ambiente di produzione su Google Cloud, puoi creare una VM in un gruppo di istanze gestite che esegue una sola istanza.
Componenti di base per RE:
- Compute Engine
- gruppi di istanze gestite
Questo scenario di failover a freddo è mostrato nell'immagine di architettura di esempio riportata di seguito:
Per una panoramica completa su come eseguire il deployment di questo scenario di esempio e testare il ripristino da errore, consulta Eseguire il deployment di un server web recuperabile a freddo con disco permanente permanenti.
I passaggi seguenti spiegano come configurare questo scenario di failover a freddo:
- Crea una rete VPC.
- Crea un'immagine VM personalizzata configurata con il servizio web della tua applicazione.
- Configura la VM in modo che i dati elaborati dal servizio dell'applicazione vengano scritti su un disco permanente collegato.
- Crea uno snapshot dal disco permanente collegato.
- Crea un modello di istanza che faccia riferimento all'immagine VM personalizzata per il server web.
- Configura uno script di avvio per creare un disco permanente dallo snapshot più recente e per montare il disco. Questo script deve essere in grado di ottenere lo snapshot più recente del disco.
- Crea un gruppo di istanze gestite e i controlli di integrità con una dimensione di destinazione pari a uno che fa riferimento al modello di istanza.
- Crea un'attività pianificata per creare snapshot regolari del disco permanente.
- Configura un Application Load Balancer esterno.
- Configura gli avvisi utilizzando Cloud Monitoring per inviare un avviso in caso di errore del servizio.
Questo scenario di failover a freddo sfrutta alcune delle funzionalità ad alta disponibilità disponibili in Google Cloud. Se si verifica un errore in una VM, il gruppo di istanze gestite tenta di ricrearla automaticamente. Non è necessario avviare questo passaggio di failover. L'Application Load Balancer esterno garantisce che, anche quando è necessaria una VM sostitutiva, venga utilizzato lo stesso indirizzo IP davanti al server delle applicazioni. Il modello di istanza e l'immagine personalizzata assicurano che la VM sostitutiva sia configurata in modo identico per l'istanza che sostituisce.
L'RPO è determinato dall'ultimo snapshot acquisito. Più spesso crei snapshot, minore è il valore dell'RPO.
Il gruppo di istanze gestite fornisce informazioni approfondite sull'alta disponibilità. Il gruppo di istanze gestite offre modi per reagire agli errori a livello di applicazione o VM. Non intervenire manualmente se si verifica uno di questi scenari. Una dimensione target pari a 1 garantisce di avere sempre e solo un'unica istanza attiva che viene eseguita nel gruppo di istanze gestite e che gestisce il traffico.
I dischi permanenti operano a livello di zona, quindi è necessario creare snapshot per ricrearli in caso di errore a livello di zona. Gli snapshot sono disponibili anche in più regioni, il che ti consente di ripristinare un disco in una regione diversa, in modo simile al ripristino nella stessa regione.
Nell'improbabile caso di errore a livello di zona, devi intervenire manualmente per il ripristino, come descritto nella sezione successiva.
Processo di failover
Se si verifica un errore in una VM, il gruppo di istanze gestite tenta automaticamente di ricreare una VM nella stessa zona. Lo script di avvio nel modello di istanza crea un disco permanente dallo snapshot più recente e lo collega alla nuova VM.
Tuttavia, un gruppo di istanze gestite di dimensione 1 non può essere ripristinato in caso di errore della zona. Nel caso di errore di una zona, devi reagire all'avviso di Cloud Monitoring o a un'altra piattaforma di monitoraggio quando il servizio ha esito negativo e devi creare manualmente un gruppo di istanze in un'altra zona.
Una variante di questa configurazione prevede l'utilizzo di dischi permanenti a livello di regione anziché di dischi permanenti di zona. Con questo approccio, non è necessario utilizzare gli snapshot per ripristinare il disco permanente nell'ambito della fase di ripristino. Tuttavia, questa variante consuma il doppio dello spazio di archiviazione e devi budget. Per eseguire il deployment di questo scenario alternativo e testare il ripristino in seguito a un errore, vedi Eseguire il deployment di un server web recuperabile a freddo con dischi permanenti a livello di regione.
L'approccio che scegli è dettato dal tuo budget e dai valori RTO e RPO.
Failover a livello di sito statico
In caso di errore delle istanze di Compute Engine, puoi mitigare l'interruzione del servizio impostando un sito statico basato su Cloud Storage in standby. L'utilizzo di un sito statico è un'opzione quando l'applicazione web è prevalentemente statica. In questo scenario, l'applicazione principale viene eseguita su istanze di Compute Engine. Queste istanze sono raggruppate in gruppi di istanze gestite, i cui gruppi fungono da servizi di backend per un bilanciatore del carico HTTPS. Il bilanciatore del carico HTTP indirizza il traffico in entrata alle istanze in base alla configurazione del bilanciatore del carico, alla configurazione di ciascun gruppo di istanze e all'integrità di ciascuna istanza.
Componenti di base per RE:
- Compute Engine
- Cloud Storage
- Cloud Load Balancing
- Cloud DNS
Il seguente diagramma illustra questa architettura di esempio:
Per una panoramica completa su come eseguire il deployment di questo scenario di esempio e testare il ripristino da errore, consulta Eseguire il deployment di un server web recuperabile tramite modalità tiepida utilizzando Cloud DNS con Compute Engine e Cloud Storage.
I passaggi seguenti spiegano come configurare questo scenario:
- Crea una rete VPC.
- Crea un'immagine personalizzata configurata con il servizio web dell'applicazione.
- Crea un modello di istanza che utilizzi l'immagine per i server web.
- Configura un gruppo di istanze gestite per i server web.
- Configurare i controlli di integrità utilizzando Monitoring.
- Configura il bilanciamento del carico utilizzando i gruppi di istanze gestite che hai configurato in precedenza.
- Crea un sito statico basato su Cloud Storage.
Nella configurazione di produzione, Cloud DNS è configurato in modo da puntare a questa applicazione principale e il sito statico in standby è inattivo. Se l'applicazione Compute Engine non funziona, devi configurare Cloud DNS in modo che punti a questo sito statico.
Processo di failover
Se il server o i server delle applicazioni non funzionano, la sequenza di ripristino consiste nel configurare Cloud DNS in modo che rimandi al tuo sito web statico. Il seguente diagramma mostra l'architettura in modalità di ripristino:
Quando le istanze di Compute Engine vengono eseguite di nuovo e possono supportare i carichi di lavoro di produzione, puoi invertire il passaggio del ripristino: devi configurare Cloud DNS in modo che punti al bilanciatore del carico che gestisce le istanze.
Per un approccio alternativo che utilizza un bilanciatore del carico delle applicazioni esterno anziché Cloud DNS per controllare il failover, consulta Eseguire il deployment di un server web recuperabile a caldo con Compute Engine e Cloud Storage. Questo pattern è utile se non hai o non vuoi utilizzare Cloud DNS.
Hot: applicazione web ad alta disponibilità
Un modello a caldo quando l'ambiente di produzione è in esecuzione su Google Cloud è definire un deployment ad alta disponibilità ben progettato.
Componenti di base per RE:
- Compute Engine
- Cloud Load Balancing
- Cloud SQL
Il seguente diagramma illustra questa architettura di esempio:
Questo scenario sfrutta le funzionalità ad alta disponibilità in Google Cloud: non è necessario avviare passaggi di failover perché avvengono automaticamente in caso di emergenza.
Come mostrato nel diagramma, l'architettura utilizza un gruppo di istanze gestite a livello di regione insieme al bilanciamento del carico globale e a Cloud SQL. Questo esempio utilizza un gruppo di istanze gestite a livello di regione, in modo che le istanze siano distribuite tra tre zone.
Con questo approccio, l'alta disponibilità viene approfondita. I gruppi di istanze gestite a livello di regione forniscono meccanismi per reagire agli errori a livello di applicazione, istanza o zona e non è necessario intervenire manualmente se si verifica uno di questi scenari.
Per gestire il recupero a livello di applicazione, nell'ambito della configurazione del gruppo di istanze gestite, devi configurare i controlli di integrità HTTP che verificano che i servizi vengano eseguiti correttamente sulle istanze del gruppo. Se un controllo di integrità determina che un servizio non è riuscito su un'istanza, il gruppo ricrea automaticamente l'istanza.
Per la procedura dettagliata su un solo modo per configurare un'applicazione web ad alta disponibilità su Google Cloud, consulta Applicazione web scalabile e resiliente su Google Cloud.
Passaggi successivi
- Scopri di più sull'area geografica e sulle regioni di Google Cloud.
Leggi altri articoli in questa serie di RE:
- Guida alla pianificazione del ripristino di emergenza
- Componenti di base per il ripristino di emergenza
- Scenari di ripristino di emergenza per i dati
- Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località
- Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati limitate a livello di località
- Architettura del ripristino di emergenza per eventuali interruzioni dell'infrastruttura cloud
Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Dai un'occhiata al nostro Cloud Architecture Center.