Scenari di ripristino di emergenza per le applicazioni

Last reviewed 2024-08-05 UTC

Questo documento fa parte di una serie che tratta Ripristino di emergenza (RE) in Google Cloud. Questa parte illustra gli scenari di ripristino di emergenza comuni per le applicazioni.

La serie è composta dai seguenti componenti:

Introduzione

Questo documento presenta scenari di RE per le applicazioni in termini di: Pattern DR che indicano la facilità con cui l'applicazione può eseguire il ripristino da un evento di emergenza. Utilizza i concetti descritti nel documento Componenti di base del RE per descrivere come implementare un piano di RE end-to-end appropriato per i tuoi obiettivi di recupero.

Per iniziare, considera alcuni carichi di lavoro tipici per illustrare come pensare gli obiettivi e l'architettura di ripristino hanno un'influenza diretta sul piano di RE.

Carichi di lavoro di elaborazione batch

I carichi di lavoro di elaborazione batch tendono a non essere mission critical, quindi in genere non devono sostenere i costi di progettazione di un'architettura ad alta disponibilità per massimizzare l'uptime; in generale, i carichi di lavoro di elaborazione batch possono e interruzioni. Questo tipo di carico di lavoro può sfruttare come VM spot e istanze VM prerilasciabili, ovvero un'istanza che puoi creare ed eseguire a un prezzo di molto inferiore rispetto alle istanze normali. Tuttavia, Compute Engine potrebbe interrompere o eliminare preventivamente queste istanze se ha bisogno di accedere alle loro risorse per altre attività.

Se implementi checkpoint regolari nell'ambito dell'attività di elaborazione, il job di elaborazione può riprendere dal punto di errore quando vengono lanciate nuove VM. Se utilizzi Dataproc, la procedura di avvio di nodi worker preemptibili è gestita da un gruppo di istanze gestite. Questo può essere considerato un modello caldo, in cui c'è una breve pausa mentre attende che le VM sostitutive 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 la procedura di invio delle notifiche degli ordini ai clienti può tollerare un ritardo di alcune ore. I clienti sono a conoscenza del loro acquisto, pertanto, anche se si aspettano un'email di conferma, la notifica non è una parte fondamentale della procedura. Questo è un mix di modelli caldi (acquisto) e caldi e freddi (notifica).

La parte transazionale dell'applicazione richiede un elevato tempo di attività con un RTO minimo valore. Pertanto, utilizzi l'HA, che massimizza la disponibilità di questa parte dell'applicazione. Questo approccio può essere preso in considerazione un modello caldo.

Lo scenario di e-commerce illustra come poter avere valori RTO variabili all'interno la stessa applicazione.

Streaming video

Una soluzione di streaming video ha molti componenti che devono essere altamente disponibili, dalla ricerca all'effettiva procedura di streaming dei contenuti all'utente. Inoltre, il sistema richiede una bassa latenza per creare un utente soddisfacente un'esperienza senza intervento manuale. Se un aspetto della soluzione non offre un'esperienza ottimale, è un male sia per il fornitore che per il cliente. Inoltre, i clienti di oggi possono rivolgersi a un prodotto competitivo.

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

Architetture DR e HA per la produzione on-premise

Questa sezione esamina come implementare tre pattern (cold, warm e hot) quando la tua applicazione viene eseguita on-premise e la tua soluzione di DR è su Google Cloud.

Modello a freddo: ripristino in Google Cloud

In un pattern a freddo, il progetto Google Cloud per il RE ha risorse minime, sufficienti per attivare uno scenario di recupero. Quando si verifica un problema che impedisce all'ambiente di produzione di eseguire i carichi di lavoro di produzione, la strategia di failover richiede l'avvio di un'immagine speculare dell'ambiente di produzione in Google Cloud. I clienti iniziano quindi a utilizzare i servizi dall'ambiente di DR.

In questa sezione esamineremo un esempio di questo pattern. Nell'esempio, Cloud Interconnect è configurato con una soluzione VPN autogestita (non Google 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 del DR:

  • 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 spiegano come puoi 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 chi può accedere al bucket e ai suoi oggetti. Includi e un account di servizio creato appositamente per questo scopo. Aggiungi anche account o gruppo utente ai criteri per il tuo operatore o sistema amministratore, concedendo a tutte queste identità le autorizzazioni pertinenti. Per maggiori dettagli sulle autorizzazioni per l'accesso a Cloud Storage, vedi Autorizzazioni IAM per Cloud Storage.
  6. Utilizza il furto d'identità degli account di servizio per fornire l'accesso al tuo account Google Cloud locale utente (o account di servizio) per simulare l'identità dell'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 dati.
  9. Crea un'attività pianificata per eseguire lo script. Puoi utilizzare strumenti come Linuxcrontab e l'Utilità di pianificazione di Windows.

  10. Crea immagini personalizzate configurate per ciascun server nell'ambiente di produzione. Ciascuna deve avere la stessa configurazione dell'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 chiamerà il processo di recupero.

  11. Configura Cloud DNS per indirizzare ai servizi web rivolti a internet.

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

Devi implementare processi per garantire che le immagini personalizzate abbiano lo stesso dell'applicazione come on-premise. Assicurati di incorporare gli upgrade alle immagini personalizzate nell'ambito del ciclo di upgrade standard e di utilizzare nel tuo modello Deployment Manager l'immagine personalizzata più recente.

Processo di failover e attività di post-riavvio

In caso di emergenza, puoi ripristinare il sistema in esecuzione in Google Cloud. Per farlo, avvia il processo di recupero per creare l'ambiente di recupero utilizzando il modello Deployment Manager che hai creato. Quando le istanze nell'ambiente di ripristino sono pronte ad accettare il traffico di produzione, modifica il DNS in modo che rimandi al server web in Google Cloud.

Una tipica sequenza di ripristino è questa:

  1. Usare il modello Deployment Manager per crea un deployment nel in Google Cloud.
  2. Applica il backup del database più recente in Cloud Storage al server del 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. Una volta superati i test, Configura Cloud DNS per puntare al server web su Google Cloud. Ad esempio, puoi utilizzare un indirizzo IP anycast dietro un bilanciatore del carico Google Cloud, con più server web dietro al bilanciatore del carico).

Il seguente diagramma mostra l'ambiente recuperato:

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

Quando l'ambiente di produzione è di nuovo in esecuzione on-premise e può supportare i carichi di lavoro di produzione, esegui i passaggi in ordine inverso 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: impedire le connessioni al bilanciatore del carico globale. Da questo momento, la tua applicazione non sarà disponibile finché non avrai completato il ripristino dell'ambiente di produzione.
  5. Copia eventuali 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 la procedura che avevi implementato per copiare i dati su Cloud Storage funzioni come previsto.
  8. Elimina il deployment.

Hot standby: ripristino in Google Cloud

In genere viene implementato un modello caldo per mantenere i valori RTO e RPO al minimo è possibile senza gli sforzi e i costi di una configurazione completamente ad alta disponibilità. Quanto più bassi sono i valori di RTO e RPO, più elevati saranno 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 modello caldo per lo scenario 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 e utilizza una suite di recupero minima su Google Cloud. La suite di ripristino è composta da un sistema operativo di un server di database su Google Cloud. Questa istanza deve essere in esecuzione in qualsiasi momento in modo da 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 lungo termine, verranno applicati gli 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 consentono di eseguire il rollback dei backup a uno stato precedente. In questo esempio vengono utilizzati gli snapshot perché le pagine web aggiornate e i file binari delle applicazioni vengono scritti di frequente sul web di produzione e sui server delle applicazioni. Questi aggiornamenti vengono replicati regolarmente fare riferimento a istanze di server web e server di applicazioni su Google Cloud. (La i server di riferimento non accettano traffico di produzione; utilizzate per creare snapshots.)

Il seguente diagramma illustra un'architettura che implementa questo approccio. I target di replica non sono mostrati nel diagramma.

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

I seguenti passaggi spiegano come puoi 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 in istanze VM di Google Cloud. Un'opzione è utilizzare una soluzione di un partner; il metodo che utilizzi dipende dalle tue circostanze.
  4. Crea un immagine personalizzata del tuo server di database su Google Cloud che abbia lo stesso configurazione come server di database on-premise.
  5. Crea snapshot del server web e delle istanze del server delle applicazioni.
  6. Avvia un'istanza di database in Google Cloud utilizzando l'immagine personalizzata creata in precedenza. Utilizza il tipo di macchina più piccolo in grado di accettare dati replicati dal database di produzione on-premise.
  7. Collega i dischi permanenti all'istanza del database Google Cloud per i database e i log delle transazioni.
  8. Configura la replica tra il server di database on-premise e server di database in Google Cloud seguendo le istruzioni per software di database.
  9. Imposta il parametro eliminazione automatica sui dischi permanenti collegati all'istanza di database no-auto-delete.
  10. Configura un'attività pianificata per creare snapshot regolari dell'istanza dell'istanza di database su Google Cloud.
  11. Creare prenotazioni per assicurare capacità per il tuo server web e la tua applicazione a seconda delle esigenze.
  12. Testa la procedura di creazione di istanze da snapshot e di acquisizione di snapshot dei dischi permanenti.
  13. Crea istanze del server web e del server delle applicazioni utilizzando gli screenshot creati in precedenza.
  14. Crea uno script che copia gli aggiornamenti nell'applicazione web e nel server dell'applicazione ogni volta che i server on-premise corrispondenti vengono aggiornati. Scrivi lo script per creare uno snapshot dei server aggiornati.
  15. Configura Cloud DNS per indirizzare al tuo servizio web on-premise per internet.

Processo di failover e attività di post-riavvio

Per gestire un failover, in genere usi il sistema di monitoraggio e avviso per richiamare un processo di failover automatico. Quando è necessario eseguire il failover dell'applicazione on-premise, configura il sistema di database su Google Cloud in modo che possa accettare il traffico di produzione. Puoi anche avviare istanze del web un server delle applicazioni.

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

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

Una sequenza di recupero tipica è la seguente:

  1. Ridimensiona dell'istanza del server del database in modo che possa gestire i carichi di produzione.
  2. Utilizza il server web e gli snapshot delle applicazioni su Google Cloud per creare un nuovo server web e nuove istanze dell'applicazione.
  3. Verifica che l'applicazione funzioni come previsto simulando scenari utente sull'ambiente recuperato.
  4. Se i test vanno a buon fine, configura Cloud DNS in modo che rimandi 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, esegui i passaggi precedenti in ordine inverso per eseguire il failover nell'ambiente di ripristino Google Cloud. Una sequenza tipica per tornare all'ambiente di produzione è la seguente:

  1. Esegui il 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. A questo punto la tua applicazione non sarà disponibile fino al termine ripristinare l'ambiente di produzione.
  5. Copia eventuali 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 il server web e le istanze del server delle applicazioni in esecuzione in Google Cloud. Lascia in esecuzione i server di riferimento.
  9. Ridimensiona del server di database su Google Cloud tornando alla dimensione minima dell'istanza in grado di accettare dati replicati dal database di produzione on-premise.
  10. Configura la replica tra il server di database on-premise e server di database in Google Cloud seguendo le istruzioni per software di database.

Alta disponibilità elevata in ambienti on-premise e su Google Cloud

Se i valori RTO e RPO sono ridotti, puoi ottenerli solo eseguendo alta disponibilità nell'ambiente di produzione e in Google Cloud contemporaneamente. Questo approccio ti fornisce un pattern caldo, perché sia l'ambiente on-premise sia Google Cloud pubblicano traffico di produzione.

La differenza principale rispetto al pattern di produzione è 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. Se implementi questa architettura, hai un piano di RE che richiede un intervento minimo in caso di emergenza.

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

I seguenti passaggi spiegano come puoi 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 immagini personalizzate configurate per ciascun server nell'infrastruttura on-premise nell'ambiente di produzione. Ogni immagine Google Cloud deve avere lo stesso configurazione come equivalente on-premise.

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

    Molti sistemi di database consentono solo una singola istanza di database scrivibile quando configurerai la replica. Pertanto, potrebbe essere necessario assicurarsi che uno dei le repliche del database operano come server di sola lettura.

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

  6. Configura gruppi di istanze gestite a livello di regione per l'applicazione e i server web.

  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 l'ambiente on-premise e l'ambiente Google Cloud.

Con questo approccio ibrido, devi usare un servizio DNS che supporti il routing ai due ambienti di produzione in modo da poter offrire l'applicazione da entrambe.

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

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 come principale scrivibile quando il heartbeat tra il database scrivibile originale e la replica di lettura perde il contatto. Assicurati di capire questo aspetto della replica del database nel caso in cui intervenire dopo un disastro.

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

Processo di failover e attività di post-riavvio

Nella configurazione qui descritta per uno scenario caldo, un'emergenza significa che uno dei due ambienti non è disponibile. Non esiste un processo di failover esattamente come negli scenari caldi o freddi, in cui è necessario spostare dati o elaborare dati nel secondo ambiente. Tuttavia, potrebbe essere necessario gestire le seguenti modifiche di configurazione:

  • Se il servizio DNS non reindirizza automaticamente il traffico in base a un errore di controllo dell'integrità, devi configurare manualmente il routing DNS per inviare il traffico al sistema ancora attivo.
  • Se il sistema del database non promuove automaticamente una replica di sola lettura come principale scrivibile in caso di errore, devi intervenire per assicurarti promosso dalla replica.

Quando il secondo ambiente è nuovamente in esecuzione e può 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 modificare il database principale. Dopo aver sincronizzato i database, puoi consentire nuovamente la distribuzione del traffico di produzione in entrambi gli ambienti modificando 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à di HA della piattaforma hanno un'influenza diretta sull'architettura di DR.

Il servizio di backup e RE è una soluzione cloud-native centralizzata per il backup e il recupero dei carichi di lavoro cloud e ibridi. Offre dati rapidi ripristino e facilita la rapida ripresa delle operazioni aziendali essenziali.

Per ulteriori informazioni sull'utilizzo del servizio di backup e RE per gli scenari applicativi su Google Cloud, consulta quanto segue:

A freddo: server delle applicazioni recuperabile

In uno scenario di failover a freddo in cui è necessaria una singola istanza di server attiva, solo un'istanza deve scrivere sul disco. In un ambiente on-premise, usano un cluster attivo / passivo. Quando esegui un ambiente di produzione Google Cloud, puoi creare una VM 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 nella seguente architettura di esempio immagine:

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

I passaggi riportati di seguito 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 dell'applicazione vengano scritto in un file allegato disco permanente.
  3. Crea uno snapshot dal disco permanente collegato.
  4. Crea un modello di istanza che fa riferimento all'immagine VM personalizzata per il server web.
    1. Configura uno script di avvio per creare un disco permanente dall'ultimo snapshot e montarlo. Questo script deve essere in grado di ottenere l'ultimo snapshot del disco.
  5. Crea un gruppo di istanze gestite e controlli di integrità con una dimensione target pari a uno che fa riferimento all'istanza modello.
  6. Crea un l'attività pianificata per creare snapshot regolari del disco permanente.
  7. Configura un Application Load Balancer esterno
  8. Configurare 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à di HA disponibili su Google Cloud. In caso di errore di una VM, il gruppo di istanze gestite tenta di ricreare automaticamente la VM. Non è necessario avviare questo passaggio di failover. La il bilanciatore del carico delle applicazioni esterno assicura che, anche quando è necessaria una VM sostitutiva, lo stesso indirizzo IP viene usato davanti al server delle applicazioni. Il modello di istanza e l'immagine personalizzata assicurano che la VM sostitutiva sia configurata in modo identico all'istanza che sostituisce.

Il RPO viene determinato dall'ultimo snapshot acquisito. Più spesso acquisisci screenshot, minore sarà il valore RPO.

Il gruppo di istanze gestite fornisce HA in modo approfondito. Il gruppo di istanze gestite fornisce 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 uno rende accertati di avere sempre una sola istanza attiva in esecuzione nello gruppo di istanze gestite e gestisce il traffico.

I dischi permanenti sono a livello di zona, quindi devi creare snapshot per ricreare i dischi si è verificato un errore a livello di zona. Gli snapshot sono disponibili anche tra 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 zonale, 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 ricrearla nella stessa zona. Lo script di avvio nel modello di istanza crea un'istanza un disco permanente dall'ultimo snapshot e lo collega alla nuova VM.

Tuttavia, un gruppo di istanze gestite di dimensione 1 non viene ripristinato se è presente zona in cui si verifica un errore di zona. Nel caso in cui si verifichi un errore in una zona, è necessario reagire alla o un'altra piattaforma di monitoraggio, quando il servizio un errore e creare manualmente un gruppo di istanze in un'altra zona.

Una variante di questa configurazione è l'utilizzo di dischi permanenti a livello di regione anziché i dischi permanenti a livello di zona. Con questo approccio, non è necessario utilizzare gli snapshot ripristinare il disco permanente durante il passaggio di ripristino. Tuttavia, questo di spazio di archiviazione consuma il doppio dello spazio di archiviazione ed è necessario un budget sufficiente.

L'approccio scelto dipende dal budget e dai valori RTO e RPO.

A caldo: failover del sito statico

Se le istanze di Compute Engine hanno errori, puoi mitigare l'interruzione del servizio grazie a un Sito statico in standby basato su Cloud Storage. Questo pattern è appropriato quando la tua applicazione web è per lo più statica.

In questo scenario, l'applicazione principale viene eseguita sulle istanze Compute Engine. Queste istanze sono raggruppate in gruppi di istanze gestite e i gruppi di istanze servono 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 ogni 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 a caldo a un sito statico quando la produzione è su Google Cloud

I passaggi riportati di seguito descrivono come configurare questo scenario:

  1. Crea una rete VPC.
  2. Crea un immagine personalizzata configurato 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. Configurare i controlli di integrità utilizzando Monitoring.
  6. Configura il bilanciamento del carico utilizzando i gruppi di istanze gestite configurati in precedenza.
  7. Crea un Sito statico basato su Cloud Storage.

Nella configurazione di produzione, Cloud DNS è configurato per puntare a questa applicazione principale e il sito statico in standby rimane inattivo. Se l'applicazione Compute Engine non funziona, devi configurare Cloud DNS affinché punti a questo sito statico.

Procedura di failover

Se uno o più server delle applicazioni non sono disponibili, la sequenza di ripristino prevede Configura Cloud DNS in modo che rimandino al tuo sito web statico. Il seguente diagramma mostra l'architettura nella modalità di recupero:

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

Quando le istanze dell'applicazione Compute Engine vengono nuovamente eseguite e possono i carichi di lavoro di produzione, invertirai il passaggio di ripristino: Configura Cloud DNS in modo che punti al bilanciatore del carico che fronta le istanze.

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

Hot: applicazione web ad alta disponibilità

Un pattern caldo quando il tuo ambiente di produzione è in esecuzione su Google Cloud è creare un deployment ad alta disponibilità ben progettato.

Questo pattern utilizza i seguenti componenti di base del DR:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Il seguente diagramma illustra questa architettura di esempio:

Architettura di un pattern attivo quando la produzione è su Google Cloud

Questo scenario sfrutta le funzionalità di HA in Google Cloud: non devi avviare alcun passaggio di failover, perché verranno eseguiti automaticamente in caso di disastro.

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 qui utilizza un gruppo di istanze gestite a livello di regione, pertanto le istanze sono distribuite tre zone.

Con questo approccio, puoi ottenere HA in modo approfondito. Gruppi di istanze gestite a livello di regione forniscono meccanismi per reagire agli errori nell'applicazione, nell'istanza o nella zona senza dover intervenire manualmente in caso di situazioni simili .

Per gestire il recupero a livello di applicazione, durante la configurazione del gruppo di istanze gestite, devi configurare i controlli di integrità HTTP che verificano che i servizi funzionino correttamente nelle istanze del gruppo. Se un controllo di integrità determina che un servizio ha avuto esito negativo in un'istanza, il gruppo la ricrea automaticamente.

Per ulteriori informazioni sulla creazione di applicazioni scalabili e resilienti su Google Cloud, consulta Pattern per app scalabili e resilienti.

Passaggi successivi