Scenari di ripristino di emergenza per le applicazioni

Last reviewed 2024-08-05 UTC

Questo documento fa parte di una serie che illustra il disaster recovery (RE) in Google Cloud. Questa parte esplora scenari comuni di ripristino di emergenza per le applicazioni.

La serie è composta dalle seguenti parti:

Introduzione

Questo documento inquadra gli scenari di RE per le applicazioni in termini di pattern di DR che indicano la facilità con cui l'applicazione può ripristinarsi da un evento di disastro. Utilizza i concetti descritti nel documento Componenti di base del DR per descrivere come implementare un piano di RE end-to-end appropriato per i tuoi obiettivi di ripristino.

Per iniziare, considera alcuni carichi di lavoro tipici per illustrare come la riflessione sugli obiettivi e sull'architettura di ripristino influenzi direttamente il tuo piano di RE.

Carichi di lavoro di elaborazione batch

I workload di elaborazione batch tendono a non essere mission critical, quindi in genere non è necessario sostenere il costo della progettazione di un'architettura ad alta disponibilità per massimizzare l'uptime; in generale, i workload di elaborazione batch possono gestire le interruzioni. Questo tipo di workload può sfruttare prodotti convenienti come le VM spot e le istanze VM prerilasciabili, ovvero istanze che puoi creare ed eseguire a un prezzo molto inferiore rispetto alle istanze normali. Tuttavia, Compute Engine potrebbe arrestare o eliminare in modo preventivo queste istanze se ha bisogno di accedere alle loro risorse per altre attività.

Implementando checkpoint regolari nell'ambito dell'attività di elaborazione, il job di elaborazione può riprendere dal punto di errore quando vengono avviate nuove VM. Se utilizzi Dataproc, la procedura di avvio dei nodi di lavoro preemptive è gestita da un gruppo di istanze gestite. Questo può essere considerato un pattern caldo, in cui c'è una breve pausa in attesa che le VM di sostituzione continuino l'elaborazione.

Siti di e-commerce

Nei siti di e-commerce, alcune parti dell'applicazione possono avere valori RTO più elevati. Ad esempio, la pipeline di acquisto effettiva deve avere un'alta disponibilità, ma il processo di invio di email che invia le notifiche degli ordini ai clienti può tollerare un ritardo di alcune ore. I clienti sono a conoscenza del loro acquisto, quindi, anche se si aspettano un'email di conferma, la notifica non è una parte fondamentale della procedura. Si tratta di un mix di pattern caldi (acquisto), tiepidi e freddi (notifica).

La parte transazionale dell'applicazione deve avere un uptime elevato con un valore RTO minimo. Pertanto, utilizzi HA, che massimizza la disponibilità di questa parte dell'applicazione. Questo approccio può essere considerato un pattern caldo.

Lo scenario di e-commerce illustra come è possibile avere valori RTO diversi all'interno della stessa applicazione.

Streaming video

Una soluzione di streaming video ha molti componenti che devono essere altamente disponibili, dall'esperienza di ricerca al processo effettivo di streaming dei contenuti per l'utente. Inoltre, il sistema richiede una bassa latenza per creare un'esperienza utente soddisfacente. Se un aspetto della soluzione non offre un'esperienza ottimale, è negativo sia per il fornitore che per il cliente. Inoltre, oggi i clienti possono rivolgersi a un prodotto della concorrenza.

In questo scenario, un'architettura HA è indispensabile e sono necessari valori RTO ridotti. Questo scenario richiede un pattern caldo in tutta l'architettura dell'applicazione per contribuire a garantire un impatto minimo in caso di disastro.

Architetture di RE e HA per la produzione on-premise

Questa sezione esamina come implementare tre pattern (cold, warm e hot) quando l'applicazione viene eseguita on-premise e la soluzioneRER si trova su Google Cloud.

Pattern freddo: recupero fino a Google Cloud

In un pattern freddo, hai risorse minime nel progetto DR Google Cloud, quanto basta per attivare uno scenario di ripristino. Quando si verifica un problema che impedisce all'ambiente di produzione di eseguire i workload di produzione, la strategia di failover richiede l'avvio di un mirror dell'ambiente di produzione in Google Cloud. I client iniziano quindi a utilizzare i servizi dall'ambiente di ripristino di emergenza.

In questa sezione esaminiamo un esempio di questo pattern. Nell'esempio, Cloud Interconnect è configurato con una soluzione VPN autogestita (nonGoogle Cloud) per fornire connettività a Google Cloud. I dati vengono copiati in Cloud Storage come parte dell'ambiente di produzione.

Questo pattern utilizza i seguenti 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:

Architettura per il pattern freddo quando la produzione è on-premise

I seguenti passaggi descrivono come configurare l'ambiente:

  1. Crea una rete VPC.
  2. Configura la connettività tra la tua rete on-premise e la rete Google Cloud .
  3. Crea un bucket Cloud Storage come destinazione per il backup dei dati.
  4. Crea un account di servizio.
  5. Crea un criterio IAM per limitare l'accesso al bucket e ai relativi oggetti. Includi l'account di servizio creato appositamente per questo scopo. Aggiungi anche 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 informazioni dettagliate sulle autorizzazioni per l'accesso a Cloud Storage, consulta Autorizzazioni IAM per Cloud Storage.
  6. Utilizza l'Impersonificazione dell'account di servizio per fornire l'accesso al tuo utente Google Cloud locale (o all'account di servizio) per impersonare l'account di servizio che hai creato in precedenza. In alternativa, puoi creare un nuovo utente appositamente per questo scopo.
  7. Verifica di poter caricare e scaricare file nel bucket di destinazione.
  8. Crea uno script di trasferimento dei dati.
  9. Crea un'attività pianificata per eseguire lo script. Puoi utilizzare strumenti come Linux crontab e l'Utilità di pianificazione di Windows.

  10. Crea immagini personalizzate configurate per ogni server nell'ambiente di produzione. Ogni immagine deve avere la stessa configurazione della sua equivalente on-premise.

    Nell'ambito della configurazione dell'immagine personalizzata per il server di database, crea uno script di avvio che copierà automaticamente l'ultimo backup da un bucket Cloud Storage all'istanza e poi richiamerà la procedura di ripristino.

  11. Configura Cloud DNS in modo che punti ai tuoi servizi web rivolti a internet.

  12. Crea un modello Deployment Manager che creerà server delle applicazioni nella tua rete Google Cloud utilizzando le immagini personalizzate configurate in precedenza. Questo modello deve anche configurare le regole firewall appropriate richieste.

Devi implementare processi per garantire che le immagini personalizzate abbiano la stessa versione dell'applicazione di quelle on-premise. Assicurati di incorporare gli upgrade alle immagini personalizzate nell'ambito del ciclo di upgrade standard e assicurati che il modello Deployment Manager utilizzi l'ultima immagine personalizzata.

Processo di failover e attività post-riavvio

In caso di emergenza, puoi eseguire il ripristino del sistema in esecuzione su Google Cloud. Per farlo, avvia il processo di ripristino per creare l'ambiente di ripristino utilizzando il modello di Deployment Manager che crei. Quando le istanze nell'ambiente di ripristino sono pronte per accettare il traffico di produzione, modifichi il DNS in modo che punti al web server in Google Cloud.

Una tipica sequenza di recupero è la seguente:

  1. Utilizza il modello Deployment Manager per creare un deployment in Google Cloud.
  2. Applica il backup del database più recente in Cloud Storage al server di database in esecuzione in Google Cloud seguendo le istruzioni del sistema di database per il recupero dei file di backup.
  3. Applica i log delle transazioni più recenti in Cloud Storage.
  4. Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente recuperato.
  5. Se i test hanno esito positivo, 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 , con più web server dietro il bilanciatore del carico.)

Il seguente diagramma mostra l'ambiente recuperato:

Configurazione del pattern freddo per il recupero quando la produzione è on-premise

Quando l'ambiente di produzione viene eseguito di nuovo on-premise e l'ambiente può supportare i carichi di lavoro di produzione, inverti i passaggi che hai seguito per eseguire il failover nell'ambiente di ripristino Google Cloud . Una sequenza tipica per tornare all'ambiente di produzione è la seguente:

  1. Esegui un backup del database in esecuzione su Google Cloud.
  2. Copia il file di backup nell'ambiente di produzione.
  3. Applica il file di backup al sistema di database di produzione.
  4. Impedisci le connessioni all'applicazione in Google Cloud. Ad esempio, impedisci le connessioni al bilanciatore del carico globale. Da questo momento la tua applicazione non sarà disponibile finché non avrai terminato il ripristino dell'ambiente di produzione.
  5. Copia tutti i file di log delle transazioni nell'ambiente di produzione e applicali al server di database.
  6. Configura Cloud DNS in modo che punti al tuo servizio web on-premise.
  7. Assicurati che il processo in atto per copiare i dati in Cloud Storage funzioni come previsto.
  8. Elimina il deployment.

Warm standby: recupero a Google Cloud

Un pattern caldo viene in genere implementato per mantenere i valori RTO e RPO il più piccoli possibile senza lo sforzo e le spese di una configurazione HA completa. Più piccoli sono i valori di RTO e RPO, più elevati sono i costi man mano che ti avvicini a 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 la connettività a Google Cloud. Un'applicazione multilivello viene eseguita on-premise utilizzando una suite di ripristino minima su Google Cloud. La suite di recupero è costituita da un'istanza del server di database operativo su Google Cloud. Questa istanza deve essere sempre in esecuzione per poter ricevere le transazioni replicate tramite tecniche di replica asincrona o semisincrona. 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 sconti per utilizzo sostenuto.

Questo pattern utilizza i seguenti componenti di base per RE:

  • Cloud DNS
  • Cloud Interconnect
  • Soluzione VPN autogestita
  • Compute Engine
  • Deployment Manager

Gli snapshot di Compute Engine forniscono un modo per eseguire backup a cui puoi eseguire il rollback a uno stato precedente. In questo esempio vengono utilizzati gli snapshot perché le pagine web e i binari dell'applicazione aggiornati vengono scritti di frequente sul web di produzione e sui server delle applicazioni. Questi aggiornamenti vengono replicati regolarmente nelle istanze del server web e del server delle applicazioni di riferimento su Google Cloud. (I server di riferimento non accettano il traffico di produzione; vengono utilizzati per creare gli snapshot.)

Il seguente diagramma illustra un'architettura che implementa questo approccio. Le destinazioni di replica non vengono mostrate nel diagramma.

Architettura per un pattern warm quando la produzione è on-premise

I seguenti passaggi descrivono come configurare l'ambiente:

  1. Crea una rete VPC.
  2. Configura la connettività tra la tua rete on-premise e la rete Google Cloud .
  3. Replica i server on-premise nelle istanze VM. Google Cloud Un'opzione è utilizzare una soluzione partner; il metodo che utilizzi dipende dalle tue circostanze.
  4. Crea un'immagine personalizzata del server di database su Google Cloud che abbia la stessa configurazione del server di database on-premise.
  5. Crea snapshot delle istanze del server web e del server delle applicazioni.
  6. 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 i dati replicati dal database di produzione on-premise.
  7. Collega dischi permanenti all'istanza di database Google Cloud per i database e i log delle transazioni.
  8. Configura la replica tra il server di database on-premise e il server di database in Google Cloud seguendo le istruzioni per il software del database.
  9. Imposta il flag eliminazione automatica sui dischi permanenti collegati all'istanza del database su no-auto-delete.
  10. Configura un'attività pianificata per creare snapshot regolari dei dischi permanenti dell'istanza del database su Google Cloud.
  11. Crea prenotazioni per garantire la capacità dei server web e delle applicazioni in base alle esigenze.
  12. Testa la procedura di creazione di istanze da snapshot e di creazione di snapshot dei dischi permanenti.
  13. Crea istanze del server web e del server delle applicazioni utilizzando gli snapshot creati in precedenza.
  14. Crea uno script che copi gli aggiornamenti nell'applicazione web e nel server delle applicazioni ogni volta che i server on-premise corrispondenti vengono aggiornati. Scrivi lo script per creare uno snapshot dei server aggiornati.
  15. Configura Cloud DNS in modo che punti al tuo servizio web accessibile da internet on-premise.

Processo di failover e attività post-riavvio

Per gestire un failover, in genere utilizzi il sistema di monitoraggio e avviso per richiamare un processo di failover automatizzato. Quando l'applicazione on-premise deve eseguire il failover, configura il sistema di database su Google Cloud in modo che sia in grado di accettare il traffico di produzione. Avvii anche le istanze del server web e dell'applicazione.

Il seguente diagramma mostra la configurazione dopo il failover a Google Cloud , che consente di gestire i carichi di lavoro di produzione da Google Cloud:

Configurazione del pattern caldo per il recupero quando la produzione è on-premise

Una tipica sequenza di recupero è la seguente:

  1. Ridimensiona l'istanza del server di database in modo che possa gestire i carichi di produzione.
  2. Utilizza gli snapshot del server web e dell'applicazione su Google Cloud per creare nuove istanze del server web e dell'applicazione.
  3. Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente recuperato.
  4. Se i test hanno esito positivo, configura Cloud DNS in modo che rimandi al tuo servizio web su Google Cloud.

Quando l'ambiente di produzione viene eseguito di nuovo on-premise e può supportare i carichi di lavoro di produzione, inverti i passaggi che hai seguito per eseguire il failover nell'ambiente Google Cloud di recupero. Una sequenza tipica per tornare all'ambiente di produzione è la seguente:

  1. Esegui un backup del database in esecuzione su Google Cloud.
  2. Copia il file di backup nell'ambiente di produzione.
  3. Applica il file di backup al sistema di database di produzione.
  4. Impedisci le connessioni all'applicazione in Google Cloud. Un modo per farlo è impedire le connessioni al server web modificando le regole del firewall. Da questo momento in poi, la tua applicazione non sarà disponibile finché non avrai terminato il ripristino dell'ambiente di produzione.
  5. Copia tutti i file di log delle transazioni nell'ambiente di produzione e applicali al server di database.
  6. Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente di produzione.
  7. Configura Cloud DNS in modo che punti al tuo servizio web on-premise.
  8. Elimina le istanze del server web e del server delle applicazioni in esecuzione in Google Cloud. Lascia in esecuzione i server di riferimento.
  9. Ridimensiona il server di database su Google Cloud alla dimensione minima dell'istanza che può accettare i dati replicati dal database di produzione on-premise.
  10. Configura la replica tra il server di database on-premise e il server di database in Google Cloud seguendo le istruzioni per il software del database.

HA attivo in locale e in Google Cloud

Se hai valori RTO e RPO piccoli, puoi ottenerli solo eseguendo HA nel tuo ambiente di produzione e Google Cloud contemporaneamente. Questo approccio ti offre un pattern caldo, perché sia on-premise che Google Cloud pubblicano il traffico di produzione.

La differenza principale rispetto al pattern caldo è che le risorse in entrambi gli ambienti vengono eseguite in modalità di produzione e gestiscono il traffico di produzione.

Questo pattern utilizza i seguenti 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. Implementando questa architettura, hai un piano di RE che richiede un intervento minimo in caso di emergenza.

Architettura per un pattern caldo quando la produzione è on-premise

I seguenti passaggi descrivono come configurare l'ambiente:

  1. Crea una rete VPC.
  2. Configura la connettività tra la tua rete on-premise e la tua rete Google Cloud .
  3. Crea immagini personalizzate in Google Cloud che sono configurate per ogni server nell'ambiente di produzione on-premise. Ogni Google Cloud immagine deve avere la stessa configurazione della sua equivalente on-premise.

  4. Configura la replica tra il server di database on-premise e il server di database in Google Cloud seguendo le istruzioni per il software del database.

    Molti sistemi di database consentono una sola istanza di database scrivibile quando configuri la replica. Pertanto, potrebbe essere necessario assicurarsi che una delle repliche del database funga da server di sola lettura.

  5. Crea modelli di istanza individuali che utilizzano le immagini per i server delle applicazioni e i server web.

  6. Configura gruppi di istanze gestite a livello di regione per i server web e delle applicazioni.

  7. Configura i controlli di integrità utilizzando Cloud Monitoring.

  8. Configura il bilanciamento del carico utilizzando i gruppi di istanze gestite a livello di regione configurati in precedenza.

  9. Configura un'attività pianificata per creare snapshot regolari dei dischi permanenti.

  10. 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 ai due ambienti di produzione in modo da poter pubblicare la stessa applicazione da entrambi.

Devi progettare il sistema per gli 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 diventano non disponibili, puoi disattivare il routing DNS a quell'ambiente. Se il tuo servizio DNS supporta i controlli di integrità, questo avverrà automaticamente quando il controllo di integrità determina che i server web in uno degli ambienti non sono raggiungibili.

Se utilizzi un sistema di database che consente una sola istanza scrivibile, in molti casi il sistema di database promuove automaticamente la replica di sola lettura a istanza principale scrivibile quando la comunicazione heartbeat tra il database scrivibile originale e la replica di lettura viene interrotta. Assicurati di comprendere questo aspetto della replica del database nel caso in cui tu debba intervenire dopo un disastro.

Devi implementare processi per assicurarti che le immagini VM personalizzate in Google Cloud abbiano la stessa versione dell'applicazione delle versioni on-premise. Incorpora gli upgrade alle immagini personalizzate nel ciclo di upgrade standard e assicurati che il modello Deployment Manager utilizzi l'immagine personalizzata più recente.

Processo di failover e attività post-riavvio

Nella configurazione descritta qui per uno scenario attivo, un'emergenza significa che uno dei due ambienti non è disponibile. Non esiste un processo di failover come negli scenari warm o cold, in cui devi spostare i dati o l'elaborazione nel secondo ambiente. Tuttavia, potresti dover gestire le seguenti modifiche alla configurazione:

  • Se il tuo servizio DNS non reindirizza automaticamente il traffico in base a un controllo di integrità non riuscito, devi configurare 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 perché diventi la principale scrivibile in caso di errore, devi intervenire per assicurarti che la replica venga promossa.

Quando il secondo ambiente è di nuovo in esecuzione e può gestire il traffico di produzione, devi sincronizzare nuovamente i database. Poiché entrambi gli ambienti supportano i workload di produzione, non devi eseguire ulteriori azioni per modificare il database principale. Una volta sincronizzati i database, puoi consentire di nuovo la distribuzione del traffico di produzione in entrambi gli ambienti modificando le impostazioni DNS.

Architetture di RE e HA per la produzione su Google Cloud

Quando progetti l'architettura dell'applicazione per il carico di lavoro di produzione su Google Cloud, le funzionalità di HA della piattaforma influiscono direttamente sulla tua architettura di RE.

Backup and DR Service è una soluzione cloud-native centralizzata per il backup e il ripristino di carichi di lavoro cloud e ibridi. Offre un rapido recupero dei dati e facilita la rapida ripresa delle operazioni aziendali essenziali.

Per saperne di più sull'utilizzo del servizio di backup e DR per scenari di applicazioni su Google Cloud, consulta quanto segue:

Cold: server delle applicazioni recuperabile

In uno scenario di failover a freddo in cui è necessaria una singola istanza del server attiva, solo un'istanza deve scrivere sul 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.

Questo pattern utilizza i seguenti componenti di base per RE:

  • Compute Engine
  • Gruppi di istanze gestite

Questo scenario di failover a freddo è mostrato nell'immagine dell'architettura di esempio seguente:

Configurazione del pattern freddo per il recupero quando la produzione è su Google Cloud

I seguenti passaggi descrivono come configurare questo scenario di failover a freddo:

  1. Crea una rete VPC.
  2. Crea un'immagine VM personalizzata configurata con il servizio web dell'applicazione.
    1. Configura la VM in modo che i dati elaborati dal servizio applicazione vengano scritti su un disco permanente collegato.
  3. Crea uno snapshot dal disco permanente collegato.
  4. Crea un modello di istanza che faccia riferimento all'immagine VM personalizzata per il server web.
    1. Configura uno script di avvio per creare un disco permanente dall'ultimo snapshot e per montare il disco. Questo script deve essere in grado di ottenere lo snapshot più recente del disco.
  5. Crea un gruppo di istanze gestite e controlli di integrità con una dimensione target di uno che fa riferimento al modello di istanza.
  6. Crea un'attività pianificata per creare snapshot regolari del disco permanente.
  7. Configura un bilanciatore del carico delle applicazioni esterno.
  8. Configura gli avvisi utilizzando Cloud Monitoring per inviare un avviso quando il servizio non funziona.

Questo scenario di failover a freddo sfrutta alcune delle funzionalità di HA disponibili in Google Cloud. Se una VM non funziona, il gruppo di istanze gestite tenta di ricrearla automaticamente. Non devi avviare questo passaggio di failover. Il bilanciatore del carico delle applicazioni esterno assicura 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 di sostituzione sia configurata in modo identico all'istanza che sostituisce.

Il RPO è determinato dall'ultimo snapshot acquisito. Più spesso esegui gli snapshot, minore è il valore RPO.

Il gruppo di istanze gestite fornisce l'alta disponibilità in modo approfondito. Il gruppo di istanze gestite offre modi per reagire agli errori a livello di applicazione o VM. Non devi intervenire manualmente se si verifica uno di questi scenari. Una dimensione target di 1 assicura che tu abbia sempre una sola istanza attiva che viene eseguita nel gruppo di istanze gestite e che gestisce il traffico.

I dischi permanenti sono zonali, quindi devi creare snapshot per ricrearli in caso di errore zonale. Gli snapshot sono disponibili anche in diverse regioni, il che ti consente di ripristinare un disco in una regione diversa in modo simile al ripristino nella stessa regione.

Nell'improbabile eventualità di un errore di zona, devi intervenire manualmente per eseguire il recupero, come descritto nella sezione successiva.

Processo di failover

Se una VM non funziona, 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 dall'ultimo snapshot e lo collega alla nuova VM.

Tuttavia, un gruppo di istanze gestite di dimensioni pari a 1 non viene recuperato in caso di errore di zona. Nello scenario in cui una zona non funziona, devi reagire all'avviso di Cloud Monitoring o di un'altra piattaforma di monitoraggio quando il servizio non funziona e creare manualmente un gruppo di istanze in un'altra zona.

Una variante di questa configurazione consiste nell'utilizzare dischi permanenti regionali anziché dischi permanenti zonali. Con questo approccio, non è necessario utilizzare gli snapshot per ripristinare il disco permanente nell'ambito del passaggio di ripristino. Tuttavia, questa variante consuma il doppio dello spazio di archiviazione e devi tenerne conto nel budget.

L'approccio che scegli è dettato dal budget e dai valori RTO e RPO.

Warm: failover del sito statico

Se le istanze Compute Engine non funzionano, puoi ridurre l'interruzione del servizio disponendo di un sito statico basato su Cloud Storage in standby. Questo pattern è appropriato quando la tua applicazione web è per lo più statica.

In questo scenario, l'applicazione principale viene eseguita su istanze Compute Engine. Queste istanze sono raggruppate in gruppi di istanze gestite e i gruppi di istanze 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.

Questo pattern utilizza i seguenti componenti di base per RE:

  • Compute Engine
  • Cloud Storage
  • Cloud Load Balancing
  • Cloud DNS

Il seguente diagramma illustra questa architettura di esempio:

Architettura per un failover caldo a un sito statico quando la produzione è su Google Cloud

I seguenti passaggi descrivono come configurare questo scenario:

  1. Crea una rete VPC.
  2. Crea un'immagine personalizzata configurata con il servizio web dell'applicazione.
  3. Crea un modello di istanza che utilizza l'immagine per i server web.
  4. Configura un gruppo di istanze gestite per i server web.
  5. Configura i controlli di integrità utilizzando Monitoring.
  6. Configura il bilanciamento del carico utilizzando i gruppi di istanze gestite che hai configurato in precedenza.
  7. 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 rimane inattivo. Se l'applicazione Compute Engine non funziona, configurerai 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 punti al tuo sito web statico. Il seguente diagramma mostra l'architettura in modalità di recupero:

Configurazione dopo il failover a un sito statico quando la produzione è su Google Cloud.

Quando le istanze Compute Engine dell'applicazione sono di nuovo in esecuzione e possono supportare i carichi di lavoro di produzione, inverti il passaggio di ripristino: configura Cloud DNS in modo che punti al bilanciatore del carico che si trova davanti alle istanze.

In alternativa, puoi utilizzare la replica asincrona di Persistent Disk. Offre la replica dell'archiviazione a blocchi con RPO (Recovery Point Objective) e RTO (Recovery Time Objective) bassi per ilREa attivo-passivo tra regioni. Questa opzione di archiviazione ti consente di gestire la replica per i carichi di lavoro di Compute Engine a livello di infrastruttura, anziché a livello di carico di lavoro.

Hot: applicazione web HA

Un pattern comune quando l'ambiente di produzione è in esecuzione su Google Cloud è stabilire un deployment HA ben progettato.

Questo pattern utilizza i seguenti componenti di base per RE:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Il seguente diagramma illustra questa architettura di esempio:

Architettura di un pattern caldo quando la produzione è attiva Google Cloud

Questo scenario sfrutta le funzionalità di alta affidabilità in Google Cloud. Non devi avviare alcun passaggio di failover, perché si verificheranno automaticamente in caso di emergenza.

Come mostrato nel diagramma, l'architettura utilizza un gruppo di istanze gestite regionale insieme al bilanciamento del carico globale e a Cloud SQL. L'esempio riportato di seguito utilizza un gruppo di istanze gestite a livello di regione, quindi le istanze sono distribuite su tre zone.

Con questo approccio, ottieni la HA in modo approfondito. I gruppi di istanze gestite a livello di regione forniscono meccanismi per reagire agli errori a livello di applicazione, istanza o zona e non devi intervenire manualmente se si verifica uno di questi scenari.

Per risolvere il problema del recupero a livello di applicazione, durante la configurazione del gruppo di istanze gestite, configura 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 ulteriori informazioni sulla creazione di applicazioni scalabili e resilienti su Google Cloud, consulta Pattern per app scalabili e resilienti .

Passaggi successivi