Il fattore principale per prendere 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 in seguito a eventi di errore. Replicando sistemi e dati in più regioni geografiche ed evitando single point of failure, puoi ridurre al minimo i rischi di una calamità naturale che colpisce l'infrastruttura locale. Altri scenari di errore includono grave guasto del sistema, un attacco di cybersicurezza o persino un errore di configurazione del sistema.
L'ottimizzazione di un sistema per far fronte agli errori è essenziale per stabilire una continuità aziendale efficace. L'affidabilità del sistema può essere influenzata da diversi fattori, inclusi, a titolo esemplificativo, prestazioni, resilienza, disponibilità dell'uptime, sicurezza ed esperienza utente. Per ulteriori informazioni su come progettare e gestire servizi affidabili su Google Cloud, consulta il pilastro dell'affidabilità del framework dell'architettura di Google Cloud e i componenti di base per l'affidabilità in Google Cloud.
Questo pattern di architettura si basa su un deployment ridondante di applicazioni in più ambienti di elaborazione. Con questo pattern, esegui il deployment delle stesse applicazioni in più ambienti di elaborazione con l'obiettivo di aumentare l'affidabilità. La continuità aziendale può essere definita come la capacità di un'organizzazione di continuare le proprie funzioni o i propri servizi aziendali chiave a livelli accettabili predefiniti dopo un evento dirompente.
Il ripristino di emergenza (RE) è considerato un sottoinsieme della continuità aziendale, concentrandosi esplicitamente sul garantire che i sistemi IT che supportano le funzioni aziendali critiche siano operativi il prima possibile dopo un'interruzione. In generale, le strategie e i piani di RE spesso contribuiscono a formare una strategia di continuità aziendale Da un punto di vista tecnologico, quando inizi a creare strategie di ripristino di emergenza, l'analisi dell'impatto aziendale deve definire due metriche chiave: l'RPO (Recovery Point Objective) e l'RTO (Recovery Time Objective). Per ulteriori indicazioni sull'utilizzo di Google Cloud per gestire il ripristino di emergenza, consulta la Guida alla pianificazione del ripristino di emergenza.
Più piccoli sono i valori target RPO e RTO, più veloci potrebbero essere i servizi di recupero a seguito di un'interruzione con una perdita di dati minima. Ciò comporta però costi maggiori, perché comporta la creazione di sistemi ridondanti. I sistemi ridondanti in grado di eseguire la replica dei dati quasi in tempo reale e che operano sulla stessa scala dopo un evento di errore aumentano la complessità, l'overhead amministrativo e i costi.
La decisione di selezionare una strategia o modello di RE dovrebbe essere guidata da un'analisi dell'impatto aziendale. Ad esempio, le perdite finanziarie subite anche da pochi minuti di inattività per un'organizzazione di servizi finanziari potrebbero superare di gran lunga il costo dell'implementazione di un sistema di RE. Tuttavia, le aziende di altri settori potrebbero subire ore di inattività senza un impatto significativo sul business.
Quando si eseguono sistemi mission-critical in un data center on-premise, un approccio di RE è quello di mantenere i sistemi in standby in un secondo data center in un'altra regione. Tuttavia, un approccio più conveniente consiste nell'utilizzare un ambiente di computing pubblico basato su cloud per scopi di failover. Questo approccio è il principale motore del modello ibrido di continuità aziendale. Il cloud può essere particolarmente interessante dal punto di vista dei costi, perché ti consente di disattivare parte della tua infrastruttura di RE quando non è in uso. Per ottenere una soluzione RE a un costo inferiore, una soluzione cloud consente all'azienda di accettare il potenziale aumento dei valori RPO e RTO.
Il diagramma precedente illustra l'utilizzo del cloud come ambiente di failover o di ripristino di emergenza in un ambiente on-premise.
Una variante meno comune (e raramente richiesta) di questo pattern è il pattern multi-cloud di continuità aziendale. In questo pattern, l'ambiente di produzione usa un cloud provider e l'ambiente di RE usa un altro. Eseguendo il deployment di copie dei carichi di lavoro su più cloud provider, puoi aumentare la disponibilità oltre ciò che offre un deployment multiregionale.
La valutazione di un RE su più cloud rispetto all'utilizzo di un solo cloud provider con regioni diverse richiede un'analisi approfondita di diverse considerazioni, tra cui:
- Gestibilità
- Sicurezza
- Fattibilità complessiva.
- Costo
- I potenziali addebiti per il trasferimento di dati in uscita da più di un cloud provider potrebbero essere costosi con una comunicazione continua tra cloud.
- Può esserci un volume elevato di traffico durante la replica dei database.
- TCO e costo di gestione dell'infrastruttura di rete inter-cloud.
Se i dati devono rimanere nel tuo paese per soddisfare i requisiti normativi, puoi utilizzare un secondo cloud provider presente nel tuo paese come RE. L'utilizzo di un secondo cloud provider presuppone che non ci sia la possibilità di utilizzare un ambiente on-premise per creare una configurazione ibrida. Per evitare di riprogettare la tua soluzione cloud, idealmente il tuo secondo cloud provider dovrebbe offrire tutte le funzionalità e i servizi necessari nella regione.
Note sul layout
- Aspettativa di RE: l'RPO e l'RTO che l'azienda vuole raggiungere dovrebbero guidare l'architettura di RE e costruire la pianificazione.
- Architettura della soluzione: con questo pattern, devi replicare le funzioni e le capacità esistenti dell'ambiente on-premise per soddisfare le tue aspettative di RE. Pertanto, devi valutare la fattibilità e la fattibilità del rehosting, del refactoring o riprogettazione delle applicazioni per fornire le stesse funzioni e prestazioni (o più ottimizzate) nell'ambiente cloud.
- Progettazione e creazione: la creazione di una zona di destinazione è quasi sempre un prerequisito per il deployment dei carichi di lavoro aziendali in un ambiente cloud. Per maggiori informazioni, consulta Progettazione delle zone di destinazione in Google Cloud.
Chiamata RE: è importante che la progettazione e il processo di RE prenda in considerazione le seguenti domande:
- Che cosa scatena uno scenario di RE? Ad esempio, un RE potrebbe essere attivato da un errore di funzioni o sistemi specifici nel sito principale.
- Come viene richiamato il failover all'ambiente RE? È una procedura di approvazione manuale o può essere automatizzata per raggiungere un target RTO ridotto?
- Come dovrebbero essere progettati i meccanismi di rilevamento e notifica dei guasti per invocare il failover
- In che modo il traffico viene reindirizzato all'ambiente di RE dopo il rilevamento dell'errore?
Convalida le risposte a queste domande attraverso test.
Test: testa e valuta a fondo il failover alla RE. Assicurati che soddisfi le aspettative di RPO e RTO. In questo modo avrai più sicurezza di richiamare la RE quando necessario. Ogni volta che viene apportata una nuova modifica o un nuovo aggiornamento al processo o alla soluzione tecnologica, esegui nuovamente i test.
Competenze dei team: uno o più team tecnici devono avere le competenze e le competenze per creare, gestire e risolvere i problemi del carico di lavoro 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à aziendale offre diversi vantaggi:
- Poiché Google Cloud offre molte regioni in tutto il mondo tra cui scegliere, puoi utilizzarlo per eseguire il backup o replicare i dati in un sito diverso all'interno dello stesso continente. Puoi anche eseguire il backup o replicare i dati su un sito in 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 in bucket a due e più regioni vengono replicati
tra regioni geografiche utilizzando la replica predefinita.
- I bucket a due regioni offrono la ridondanza geografica per supportare piani di continuità aziendale e RE. Inoltre, per replicare più velocemente, con un RPO inferiore, gli oggetti archiviati in due regioni possono facoltativamente utilizzare la replica turbo in queste regioni.
- Allo stesso modo, la replica multiregionale fornisce ridondanza tra più regioni, archiviando i dati all'interno del confine geografico della multiregione.
- Offre una o più delle seguenti opzioni per ridurre le spese in conto capitale
e le spese operative al fine di creare un RE:
- Le istanze VM arrestate comportano solo costi di archiviazione e sono sostanzialmente più economiche rispetto alle istanze VM in esecuzione. Ciò significa che puoi ridurre al minimo il costo di manutenzione dei sistemi cold standby.
- Il modello di pagamento in base al consumo di Google Cloud prevede che paghi solo per la capacità di archiviazione e di calcolo che utilizzi effettivamente.
- Le funzionalità di elasticità, come la scalabilità automatica, consentono di scalare o ridurre automaticamente l'ambiente di RE in base alle necessità.
Ad esempio, il seguente diagramma mostra un'applicazione in esecuzione in un ambiente on-premise (produzione) che utilizza componenti di ripristino su Google Cloud con Compute Engine, Cloud SQL e Cloud Load Balancing. In questo scenario, viene eseguito il pre-provisioning del database utilizzando un database basato su VM o utilizzando un database gestito da Google Cloud, come Cloud SQL, per un ripristino più rapido con la replica continua dei dati. Puoi avviare le VM di Compute Engine da snapshot creati in precedenza per ridurre i costi durante le normali operazioni. Con questa configurazione e in seguito a un evento di errore, il DNS deve puntare all'indirizzo IP esterno di Cloud Load Balancing.
Per fare in modo che l'applicazione sia operativa nel cloud, devi eseguire il provisioning delle VM web e dell'applicazione. A seconda del livello di RTO target e dei criteri aziendali, l'intero processo per richiamare un RE, eseguire il provisioning del carico di lavoro nel cloud e reindirizzare il traffico può essere completato manualmente o automaticamente.
Per accelerare e automatizzare il provisioning dell'infrastruttura, valuta la possibilità di gestire l'infrastruttura come codice. Puoi utilizzare Cloud Build, un servizio di integrazione continua, per applicare automaticamente i manifest Terraform al tuo ambiente. Per maggiori informazioni, consulta Gestire l'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Best practice
Quando utilizzi il pattern di continuità aziendale, considera le seguenti best practice:
- Crea un piano di ripristino di emergenza che documenti l'infrastruttura insieme alle procedure di failover e ripristino.
- Prendi in considerazione le seguenti azioni in base all'analisi dell'impatto aziendale e agli obiettivi RPO e RTO identificati:
- Decidi se il backup dei dati in Google Cloud è sufficiente o se devi prendere in considerazione un'altra strategia di RE (sistemi a freddo, caldo o hot standby).
- Definisci i servizi e i prodotti che puoi utilizzare come componenti di base per il tuo piano di RE.
- Configura gli scenari di RE applicabili per le tue applicazioni e i tuoi dati nell'ambito della strategia di RE selezionata.
- Prendi in considerazione l'utilizzo del pattern di consegna 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.
- Riduci al minimo le dipendenze tra i sistemi in esecuzione in ambienti diversi, in particolare quando la comunicazione è gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni e diminuire la disponibilità complessiva.
Evita il problema di sdoppiato. Se replichi i dati in modo bidirezionale tra gli ambienti, potresti essere esposta a il problema di "split-brain". Questo problema si verifica quando due ambienti che replicano i dati in modo bidirezionale perdono la comunicazione tra loro. Questa suddivisione può indurre i sistemi in entrambi gli ambienti a concludere che l'altro ambiente non è disponibile e che hanno accesso esclusivo ai dati. Questo può portare a modifiche dei dati in conflitto. Esistono due modi comuni per evitare il problema di divisione del cervello:
- Utilizza un terzo ambiente di calcolo. Questo ambiente consente ai sistemi di verificare il 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 tipo split-brain rendendo inaccessibile l'istanza principale originale prima che i client inizino a utilizzare la nuova istanza principale. Per ulteriori informazioni, consulta Ripristino di emergenza del database Cloud SQL.
Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un single point of failure. Quando un ambiente non è disponibile, devi comunque essere in grado di eseguire il deployment di nuove release o applicare modifiche alla configurazione.
Rendi portabili tutti i carichi di lavoro quando utilizzi sistemi in standby. Tutti i carichi di lavoro devono essere portatili (laddove supportati dalle applicazioni e fattibile) in modo che i sistemi rimangano coerenti tra gli ambienti. Puoi ottenere questo approccio considerando i container e Kubernetes. Utilizzando Google Kubernetes Engine (GKE) Enterprise, puoi semplificare la creazione e le operazioni.
Integra il deployment dei sistemi in standby nella tua pipeline CI/CD. Grazie a questa integrazione, le versioni e le configurazioni dell'applicazione sono coerenti in tutti gli ambienti.
Assicurati che le modifiche al DNS vengano propagate rapidamente configurando il tuo DNS con un valore di durata (TTL) ragionevolmente breve, in modo da poter reindirizzare gli utenti ai sistemi in standby quando si verifica un'emergenza.
Seleziona il criterio DNS e il criterio di routing in linea con l'architettura e il comportamento della soluzione. Inoltre, puoi combinare più bilanciatori del carico regionali con criteri di routing DNS per creare architetture di bilanciamento del carico globale per diversi casi d'uso, compresa la configurazione ibrida.
Usa 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 di applicazioni ibride con dipendenze in 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 maggiori informazioni, consulta DNS pubblico multi-provider utilizzando Cloud DNS.
Usa i bilanciatori del carico quando si usano i sistemi in standby per creare un failover automatico. Tieni presente che l'hardware del bilanciatore del carico può presentare errori.
Utilizza Cloud Load Balancing anziché i bilanciatori del carico hardware per supportare alcuni scenari che si verificano quando si utilizza questo pattern di architettura. Le richieste client interne o le richieste client esterne possono essere reindirizzate all'ambiente principale o all'ambiente di RE in base a diverse metriche, tra cui la suddivisione del traffico basata sui pesi. Per maggiori informazioni, consulta Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.
Valuta la possibilità di utilizzare 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ò aiutare a ottimizzare le prestazioni di connettività e potrebbe ridurre i costi 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 semplificare i backup dei dati, le repliche e le altre attività che soddisfano i tuoi requisiti, tra cui le destinazioni RPO e RTO.
Testa e valuta gli scenari di chiamata RE per capire la facilità di ripristino da un evento di emergenza rispetto al valore RTO di destinazione.
Cripta le comunicazioni in transito. Per proteggere le informazioni sensibili, consigliamo di criptare tutte le comunicazioni in transito. Se è richiesta 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.