Scenari di ripristino di emergenza per le applicazioni

Last reviewed 2024-08-05 UTC

Questo documento fa parte di una serie che illustra il 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 definisce gli scenari di RE per le applicazioni in termini di pattern di RE che indicano la facilità con cui l'applicazione può riprendersi 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, prendi in considerazione alcuni carichi di lavoro tipici per illustrare in che modo la scelta degli obiettivi e dell'architettura di recupero influisce direttamente 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 è necessario sostenere il costo della progettazione di un'architettura di alta disponibilità (HA) per massimizzare il tempo di attività. In generale, i carichi di lavoro di elaborazione batch possono gestire interruzioni. Questo tipo di carico di lavoro 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 interrompere o eliminare preventivamente queste istanze se ha bisogno di accedere alle 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 pattern caldo, in cui si verifica una breve pausa in attesa 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. Si tratta di un mix di modelli caldi (acquisto) e tiepidi e freddi (notifica).

La parte transazionale dell'applicazione richiede un'elevata disponibilità con un valore RTO minimo. Pertanto, utilizzi l'HA, che massimizza la disponibilità di questa parte dell'applicazione. Questo approccio può essere considerato un pattern di tendenza.

Lo scenario di e-commerce illustra come puoi avere valori RTO diversi all'interno della 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 latenza ridotta per creare un'esperienza utente satisfactoria. Se un aspetto della soluzione non offre un'esperienza ottimale, è un male sia per il fornitore sia per il cliente. Inoltre, oggi i clienti possono rivolgersi a un prodotto della concorrenza.

In questo scenario, un'architettura HA è un must e sono necessari valori RTO ridotti. Questo scenario richiede un pattern attivo nell'intera architettura dell'applicazione per garantire un impatto minimo in caso di disastro.

Architetture RE 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 RE è 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 RE.

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 RE:

  • Cloud DNS
  • Cloud Interconnect
  • Soluzione VPN self-managed
  • Cloud Storage
  • Compute Engine
  • Cloud Load Balancing
  • Deployment Manager

Il seguente diagramma illustra questo esempio di architettura:

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

I passaggi riportati di seguito 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 chi può accedere 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'appropriazione di identità dell'account di servizio per consentire all'utente (o all'account di servizio) Google Cloud locale di assumere l'identità dell'account di servizio 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 ogni server nell'ambiente di produzione. Ogni immagine 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 in modo che punti ai tuoi 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 configurare le regole firewall appropriate richieste.

Devi implementare procedure per assicurarti che le immagini personalizzate abbiano la stessa versione dell'applicazione di quella on-premise. Assicurati di incorporare gli upgrade alle immagini personalizzate nell'ambito del ciclo di upgrade standard e di utilizzare nel modello Deployment Manager l'immagine personalizzata più recente.

Processo di failover e attività di post-riavvio

In caso di disastro, puoi eseguire il recupero sul sistema in esecuzione su 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 sequenza di recupero tipica è 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 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. Se i test vanno a buon fine, 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ù server web dietro il 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 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. Ad esempio, impedisci 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 in Cloud Storage funzioni come previsto.
  8. Elimina il deployment.

Hot standby: ripristino in Google Cloud

In genere, viene implementato un modello di warm per mantenere i valori di RTO e RPO il più ridotti possibile senza lo sforzo e la spesa di una configurazione completamente HA. 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 pattern di preriscaldamento 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 self-managed 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 recupero è costituita da un'istanza di server di database operativo 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 RE:

  • Cloud DNS
  • Cloud Interconnect
  • Soluzione VPN self-managed
  • 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 nel web di produzione e nei server delle applicazioni. Questi aggiornamenti vengono replicati regolarmente alle istanze del server web e del server di applicazioni di riferimento su Google Cloud. I server di riferimento non accettano il traffico di produzione, ma vengono utilizzati per creare gli snapshot.

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

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

I passaggi riportati di seguito 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 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 server di database su Google Cloud con 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 creata in precedenza. Utilizza il tipo di macchina più piccolo in grado di accettare i 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 database on-premise e il server database in Google Cloud seguendo le istruzioni per il software del database.
  9. Imposta il no-auto-delete sul flag di eliminazione automatica sui dischi permanenti collegati all'istanza del database.
  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à del server web e dei server di applicazioni in base alle 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 in modo che punti al tuo servizio web on-premise rivolto a internet.

Processo di failover e attività di post-riavvio

Per gestire un failover, in genere utilizzi il sistema di monitoraggio e invio di avvisi per invocare 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. Avvia anche istanze del server web e dell'applicazione.

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

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

Una sequenza di recupero tipica è la seguente:

  1. Ridimensiona l'istanza del server del 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 di server web e applicazioni.
  3. Verifica che l'applicazione funzioni come previsto simulando scenari utente nell'ambiente recuperato.
  4. Se i test sono riusciti, 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. Da questo momento, l'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. 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 su Google Cloud. Lascia in esecuzione i server di riferimento.
  9. Ridimensiona il server di database su Google Cloud alle dimensioni minime dell'istanza che può accettare i dati replicati dal database di produzione on-premise.
  10. Configura la replica tra il server database on-premise e il server database in Google Cloud seguendo le istruzioni per il software del database.

Hot HA on-premise e su Google Cloud

Se hai valori RTO e RPO ridotti, puoi raggiungerli solo eseguendo la disponibilità elevata contemporaneamente nell'ambiente di produzione e in Google Cloud. 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 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 passaggi riportati di seguito 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 immagini personalizzate in Google Cloud configurate per ogni server nell'ambiente di produzione on-premise. Ogni immagine Google Cloud deve avere la stessa configurazione dell'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, potresti dover assicurarti che una delle repliche del database agisca 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 utilizzare un servizio DNS che supporti il routing ponderato verso i due ambienti di produzione in modo da poter pubblicare la stessa applicazione da entrambi.

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

Devi implementare procedure 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 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 descritta qui per uno scenario hot, un disastro significa che uno dei due ambienti non è disponibile. Non esiste un processo di failover come accade negli scenari warm o cold, in cui è necessario spostare i dati o l'elaborazione 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 di integrità dell'integrità, devi configurare manualmente il routing DNS per inviare il traffico al sistema ancora attivo.
  • Se il 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 e può gestire il traffico di produzione, devi sincronizzare nuovamente 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 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 hanno un'influenza diretta sull'architettura di RE.

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 un rapido recupero dei dati e facilita la rapida ripresa delle operazioni aziendali essenziali.

Per ulteriori informazioni sull'utilizzo del servizio di backup e RE per scenari di applicazioni su Google Cloud, consulta le seguenti risorse:

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, spesso si utilizza 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 RE:

  • Compute Engine
  • Gruppi di istanze gestite

Questo scenario di failover a freddo è mostrato nell'immagine di architettura di esempio che segue:

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 scritti su un disco permanente collegato.
  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 lo snapshot più recente del disco.
  5. Crea un gruppo di istanze gestite e controlli di integrità con una dimensione target di 1 che fa riferimento al modello di istanza.
  6. Crea una 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 in caso di errore del servizio.

Questo scenario di failover a freddo sfrutta alcune delle funzionalità di HA disponibili su 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 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 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 pari a 1 garantisce che venga eseguita una sola istanza attiva nel gruppo di istanze gestite e che venga servito il traffico.

I dischi permanenti sono a livello di zona, quindi devi acquisire snapshot per ricreare i dischi in caso di 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.

Procedura 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 disco permanente dall'ultimo snapshot e lo collega alla nuova VM.

Tuttavia, un gruppo di istanze gestite con una dimensione non si ripristina in caso di guasto della zona. Se una zona non funziona, devi reagire all'alert 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 è l'utilizzo di dischi permanenti regionali anziché di dischi permanenti zonali. Con questo approccio, non è necessario utilizzare gli snapshot per recuperare il disco permanente durante il passaggio di recupero. Tuttavia, questa variazione consuma il doppio dello spazio di archiviazione e devi tenere conto di questo aspetto nel budget.

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

Calda: failover del sito statico

Se le istanze Compute Engine non funzionano, puoi ridurre l'interruzione del servizio mantenendo attivo un sito statico basato su Cloud Storage in standby. Questo pattern è appropriato quando l'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, che 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 ogni istanza.

Questo pattern utilizza i seguenti componenti di base RE:

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

Il seguente diagramma illustra questo esempio di architettura:

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 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 il monitoraggio.
  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 si arresta in modo anomalo, devi configurare Cloud DNS in modo che punti a questo sito statico.

Procedura di failover

Se il server o i server dell'applicazione non sono disponibili, la sequenza di recupero consiste nel configurare Cloud DNS in modo che rimandi 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 Compute Engine dell'applicazione sono di nuovo in esecuzione e possono supportare i workload di produzione, esegui il passaggio di ripristino inverso: 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 il RE 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 di tendenza quando l'ambiente di produzione è in esecuzione su Google Cloud è stabilire un deployment HA ben progettato.

Questo pattern utilizza i seguenti componenti di base RE:

  • Compute Engine
  • Cloud Load Balancing
  • Cloud SQL

Il seguente diagramma illustra questo esempio di architettura:

Architettura di un pattern caldo 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 su tre zone.

Con questo approccio, puoi ottenere 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 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 non è riuscito 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