Il motivo principale per cui si prende in considerazione la continuità aziendale per i sistemi mission-critical è aiutare un'organizzazione a essere resiliente e a continuare le proprie operazioni aziendali durante e dopo gli eventi di errore. Grazie alla replica di sistemi e dati in più regioni geografiche ed evitando single point of failure, puoi ridurre al minimo i rischi di un disastro naturale che interessa l'infrastruttura locale. Altri scenari di errore includono un grave errore del sistema, un attacco informatico o persino un errore di configurazione del sistema.
L'ottimizzazione di un sistema per resistere ai guasti è essenziale per stabilire una continuità aziendale efficace. L'affidabilità del sistema può essere influenzata da diversi fattori, tra cui, a titolo esemplificativo, prestazioni, resilienza, disponibilità di uptime, sicurezza ed esperienza utente. Per saperne di più su come progettare e gestire servizi affidabili suGoogle Cloud, consulta il pilastro dell'affidabilità del Google Cloud Well-Architected Framework e gli elementi costitutivi dell'affidabilità in Google Cloud.
Questo pattern di architettura si basa su un deployment ridondante delle applicazioni in più ambienti di computing. In questo pattern, esegui il deployment delle stesse applicazioni in più ambienti di computing con l'obiettivo di aumentare l'affidabilità. La continuità aziendale può essere definita come la capacità di un'organizzazione di continuare le sue funzioni o i suoi servizi aziendali chiave a livelli accettabili predefiniti in seguito a un evento dirompente.
Il ripristino di emergenza (RE) è considerato un sottoinsieme della continuità aziendale, incentrato esplicitamente sull'assicurare che i sistemi IT che supportano le funzioni aziendali critiche siano operativi il prima possibile dopo un'interruzione. In generale, le strategie e i pianiREa spesso aiutano a formare una strategia di continuità aziendale più ampia. Dal punto di vista tecnologico, quando inizi a creare strategie di ripristino di emergenza, l'analisi dell'impatto aziendale deve definire due metriche chiave: il Recovery Point Objective (RPO) e il Recovery Time Objective (RTO). Per ulteriori istruzioni sull'utilizzo di Google Cloud per il disaster recovery, consulta la Guida alla pianificazione del disaster recovery.
Più piccoli sono i valori target RPO e RTO, più velocemente i servizi possono riprendersi da un'interruzione con una perdita di dati minima. Tuttavia, ciò implica costi più elevati perché significa creare sistemi ridondanti. I sistemi ridondanti in grado di eseguire la replica dei dati quasi in tempo reale e che operano alla stessa scala dopo un evento di errore aumentano la complessità, il sovraccarico amministrativo e i costi.
La decisione di selezionare una strategia di recupero di emergenza o un pattern deve essere basata su un'analisi dell'impatto sull'attività. Ad esempio, le perdite finanziarie subite anche per pochi minuti di inattività per un'organizzazione di servizi finanziari potrebbero superare di gran lunga il costo di implementazione di un sistema di RE. Tuttavia, le attività in altri settori potrebbero subire ore di inattività senza un impatto significativo sull'attività.
Quando esegui sistemi mission-critical in un data center on-premise, un approccio di RE consiste nel mantenere sistemi di standby in un secondo data center in un'altra regione. Un approccio più conveniente, tuttavia, consiste nell'utilizzare un ambiente di computing basato su cloud pubblico per scopi di failover. Questo approccio è il principale motore del pattern ibrido di business continuity. Il cloud può essere particolarmente interessante dal punto di vista dei costi, perché ti consente di disattivare parte dell'infrastruttura di RE quando non è in uso. Per ottenere una soluzione di RE a costi inferiori, una soluzione cloud consente a un'azienda di accettare il potenziale aumento dei valori di RPO e RTO.
Il diagramma precedente illustra l'utilizzo del cloud come ambiente di failover o di ripristino di emergenza per un ambiente on-premise.
Una variante meno comune (e raramente richiesta) di questo pattern è il pattern multicloud per la continuità operativa. In questo pattern, l'ambiente di produzione utilizza un cloud provider e l'ambiente di ripristino di emergenza ne utilizza un altro. Se esegui il deployment di copie dei carichi di lavoro su più cloud provider, potresti aumentare la disponibilità oltre a quanto offerto da un deployment multiregionale.
La valutazione di un RE in più cloud rispetto all'utilizzo di un solo fornitore di servizi cloud con regioni diverse richiede un'analisi approfondita di diverse considerazioni, tra cui le seguenti:
- Gestibilità
- Sicurezza
- Fattibilità complessiva.
- Costo
- I potenziali costi per il trasferimento di dati in uscita da più di un cloud provider potrebbero essere elevati con la comunicazione inter-cloud continua.
- Durante la replica dei database, il volume di traffico può essere elevato.
- TCO e costo della gestione dell'infrastruttura di rete intercloud.
Se i tuoi dati devono rimanere nel tuo paese per soddisfare i requisiti normativi, l'utilizzo di un secondo provider di servizi cloud che si trova anche nel tuo paese come RE può essere un'opzione. L'utilizzo di un secondo cloud provider presuppone che non esista un'opzione per utilizzare un ambiente on-premise per creare una configurazione ibrida. Per evitare di riprogettare la tua soluzione cloud, idealmente il secondo provider cloud dovrebbe offrire tutte le funzionalità e i servizi richiesti di cui hai bisogno nella regione.
Considerazioni sulla progettazione
- Aspettativa di DR: gli obiettivi RPO e RTO che la tua attività vuole raggiungere devono guidare la pianificazione della creazione e dell'architettura diRER.
- Architettura della soluzione: con questo pattern, devi replicare le funzioni e le funzionalità esistenti del tuo ambiente on-premise per soddisfare le tue aspettative di RE. Pertanto, devi valutare la fattibilità e la praticabilità del rehosting, del refactoring o della riprogettazione delle tue applicazioni per fornire le stesse funzioni (o più ottimizzate) e lo stesso rendimento nell'ambiente cloud.
- Progettazione e creazione: la creazione di una landing zone è quasi sempre un prerequisito per il deployment di carichi di lavoro aziendali in un ambiente cloud. Per maggiori informazioni, consulta Progettazione della landing zone in Google Cloud.
Richiamo del ripristino di emergenza: è importante che la progettazione e la procedura di RE prendano in considerazione le seguenti domande:
- Cosa attiva uno scenario di RE? Ad esempio, un RE potrebbe essere attivato dal malfunzionamento di funzioni o sistemi specifici nel sito principale.
- Come viene richiamato il failover nell'ambiente di RE? Si tratta di una procedura di approvazione manuale o può essere automatizzata per raggiungere un RTO target basso?
- Come devono essere progettati i meccanismi di rilevamento e notifica degli errori di sistema per richiamare il failover in linea con l'RTO previsto?
- Come viene reindirizzato il traffico all'ambiente di RE dopo il rilevamento dell'errore?
Convalida le risposte a queste domande tramite i test.
Test: testa e valuta attentamente il failover al RE. Assicurati che soddisfi le tue aspettative di RPO e RTO. In questo modo, potrai invocare RE con maggiore sicurezza quando necessario. Ogni volta che viene apportata una nuova modifica o un nuovo aggiornamento alla soluzione di processo o tecnologica, esegui nuovamente i test.
Competenze del team: uno o più team tecnici devono disporre delle competenze e dell'esperienza necessarie per creare, gestire e risolvere i problemi relativi al workload di produzione nell'ambiente cloud, a meno che l'ambiente non sia gestito da una terza parte.
Vantaggi
L'utilizzo di Google Cloud per la continuità operativa offre diversi vantaggi:
- Poiché Google Cloud dispone di molte regioni in tutto il mondo tra cui scegliere, puoi utilizzarlo per eseguire il backup o la replica dei dati in un sito diverso all'interno dello stesso continente. Puoi anche eseguire il backup o la replica dei dati in un sito su un altro continente.
- Google Cloud offre la possibilità di archiviare i dati in Cloud Storage
in un bucket
a due o più regioni. I dati vengono archiviati in modo ridondante in almeno due regioni geografiche separate. I dati archiviati nei bucket multiregionali e a due regioni vengono replicati
in più regioni geografiche utilizzando la replica predefinita.
- I bucket a due regioni forniscono la ridondanza geografica per supportare la continuità aziendale e i piani di RE. Inoltre, per eseguire la replica più rapidamente, con un RPO inferiore, gli oggetti archiviati in due regioni possono utilizzare facoltativamente la replica turbo in queste regioni.
- Allo stesso modo, la replica multiregionale fornisce ridondanza in più regioni, archiviando i dati all'interno del confine geografico della multiregione.
- Fornisce una o più delle seguenti opzioni per ridurre le spese di capitale
e le spese operative per creare un RE:
- Le istanze VM arrestate comportano solo costi di archiviazione e sono notevolmente più economiche rispetto alle istanze VM in esecuzione. Ciò significa che puoi ridurre al minimo il costo di manutenzione dei sistemi di standby a freddo.
- Il modello pay-per-use di Google Cloud significa che paghi solo per la capacità di archiviazione e di calcolo che utilizzi effettivamente.
- Le funzionalità di elasticità, come la scalabilità automatica, ti consentono di scalare o ridurre automaticamente l'ambiente di RE in base alle esigenze.
Ad esempio, il seguente diagramma mostra un'applicazione in esecuzione in un ambiente on-premise (produzione) che utilizza componenti di ripristino suGoogle Cloud con Compute Engine, Cloud SQL e Cloud Load Balancing. In questo scenario, il database viene sottoposto a provisioning preliminare utilizzando un database basato su VM o un database gestito, come Cloud SQL, per un ripristino più rapido con replica continua dei dati. Google Cloud Puoi avviare le VM Compute Engine da snapshot pre-creati per ridurre i costi durante le normali operazioni. Con questa configurazione e dopo un evento di errore, il DNS deve puntare all'indirizzo IP esterno diCloud Load Balancingd.
Per rendere operativa l'applicazione nel cloud, devi eseguire il provisioning delle VM web e delle applicazioni. A seconda del livello RTO target e delle norme aziendali, l'intero processo per richiamare un RE, eseguire il provisioning del workload nel cloud e reindirizzare il traffico può essere completato manualmente o automaticamente.
Per velocizzare e automatizzare il provisioning dell'infrastruttura, valuta la possibilità di gestirla come codice. Puoi utilizzare Cloud Build, un servizio di integrazione continua, per applicare automaticamente i manifest Terraform al tuo ambiente. Per saperne di più, consulta Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Best practice
Quando utilizzi il pattern di continuità operativa, tieni presenti le seguenti best practice:
- Crea un piano di ripristino di emergenza che documenti la tua infrastruttura insieme alle procedure di failover e ripristino.
- Prendi in considerazione le seguenti azioni in base all'analisi dell'impatto sull'attività e
agli RPO e RTO target identificati:
- Decidi se il backup dei dati su Google Cloud è sufficiente o se devi prendere in considerazione un'altra strategiaREa (sistemi di standby freddo, tiepido o caldo).
- Definisci i servizi e i prodotti che puoi utilizzare come componenti di base per il tuo piano di RE.
- Inquadra gli scenari di RE applicabili per le tue applicazioni e dati nell'ambito della strategia di RE selezionata.
- Valuta la possibilità di utilizzare il pattern di trasferimento quando esegui solo il backup dei dati. In caso contrario, il pattern mesh potrebbe essere una buona opzione per replicare l'architettura di rete dell'ambiente esistente.
- Ridurre al minimo le dipendenze tra i sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni e ridurre la disponibilità complessiva.
Evita il problema di split-brain. Se replichi i dati in modo bidirezionale tra gli ambienti, potresti essere esposto al problema di split-brain. Il problema di split-brain si verifica quando due ambienti che replicano i dati in modo bidirezionale perdono la comunicazione tra loro. Questa divisione può indurre i sistemi di entrambi gli ambienti a concludere che l'altro ambiente non è disponibile e che hanno accesso esclusivo ai dati. Ciò può portare a modifiche in conflitto dei dati. Esistono due modi comuni per evitare il problema di split-brain:
- Utilizza un terzo ambiente di computing. Questo ambiente consente ai sistemi di verificare la presenza di un quorum prima di modificare i dati.
Consenti la riconciliazione delle modifiche ai dati in conflitto dopo il ripristino della connettività.
Con i database SQL, puoi evitare il problema di split-brain rendendo inaccessibile l'istanza primaria originale prima che i client inizino a utilizzare la nuova istanza primaria. Per saperne di più, consulta la sezione Ripristino di emergenza per database Cloud SQL.
Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un unico punto di errore. Quando un ambiente non è disponibile, devi comunque essere in grado di eseguire il deployment di nuove release o applicare modifiche alla configurazione.
Rendi tutti i workload portabili quando utilizzi sistemi di standby. Tutti i carichi di lavoro devono essere portabili (se supportati dalle applicazioni e fattibili) in modo che i sistemi rimangano coerenti tra gli ambienti. Puoi ottenere questo approccio prendendo in considerazione i container e Kubernetes. Utilizzando Google Kubernetes Engine (GKE), puoi semplificare la creazione e le operazioni.
Integra il deployment dei sistemi di standby nella tua pipeline CI/CD. Questa integrazione contribuisce a garantire che le versioni e le configurazioni delle applicazioni siano coerenti nei vari ambienti.
Assicurati che le modifiche al DNS vengano propagate rapidamente configurando il DNS con un valore Time to Live ragionevolmente breve in modo da poter reindirizzare gli utenti ai sistemi di standby in caso di emergenza.
Seleziona i criteri DNS e di routing che corrispondono al comportamento dell'architettura e della soluzione. Inoltre, puoi combinare più bilanciatori del carico regionali con norme di routing DNS per creare architetture di bilanciamento del carico globali per diversi casi d'uso, inclusa la configurazione ibrida.
Utilizza più provider DNS. Quando utilizzi più provider DNS, puoi:
- Migliora la disponibilità e la resilienza delle tue applicazioni e dei tuoi servizi.
Semplifica il deployment o la migrazione delle applicazioni ibride con dipendenze tra ambienti on-premise e cloud con una configurazione DNS multi-provider.
Google Cloud offre una soluzione open source basata su octoDNS per aiutarti a configurare e gestire un ambiente con più provider DNS. Per saperne di più, consulta DNS pubblico multi-provider con Cloud DNS.
Utilizza i bilanciatori del carico quando utilizzi sistemi di standby per creare un failover automatico. Tieni presente che l'hardware del bilanciatore del carico può non funzionare.
Utilizza Cloud Load Balancing anziché i bilanciatori del carico hardware per gestire alcuni scenari che si verificano quando utilizzi questo pattern di architettura. Le richieste dei client interni o le richieste dei client esterni possono essere reindirizzate all'ambiente principale o all'ambiente di RE in base a metriche diverse, ad esempio la divisione del traffico basata sul peso. Per saperne di più, consulta Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.
Prendi in considerazione l'utilizzo di Cloud Interconnect o Cross-Cloud Interconnect se il volume di trasferimento di dati in uscita da Google Cloud verso l'altro ambiente è elevato. Cloud Interconnect può contribuire a ottimizzare le prestazioni di connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, consulta i prezzi di Cloud Interconnect.
Valuta la possibilità di utilizzare la tua soluzione partner preferita su Google Cloud Marketplace per facilitare i backup, le repliche e altre attività che soddisfano i tuoi requisiti, inclusi gli obiettivi RPO e RTO.
Testa e valuta gli scenari di chiamata RE per capire con quale facilità l'applicazione può ripristinarsi da un evento di disastro rispetto al valore RTO target.
Crittografare le comunicazioni in transito. Per proteggere le informazioni sensibili, ti consigliamo di criptare tutte le comunicazioni in transito. Se è necessaria la crittografia a livello di connettività, sono disponibili varie opzioni in base alla soluzione di connettività ibrida selezionata. Queste opzioni includono tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.