Il fattore principale per considerare continuazione aziendale dei sistemi mission critical è aiutare un'organizzazione a essere resiliente durante e dopo gli eventi di errore. Di di replicare sistemi e dati su più regioni geografiche ed evitare i single point of failure, è possibile ridurre al minimo i rischi di una calamità naturale che influisce sull'infrastruttura locale. Altri scenari di errore includono un grave guasto del sistema, un attacco di cybersicurezza o persino un errore di configurazione del sistema.
L'ottimizzazione di un sistema per resistere agli errori è fondamentale per stabilire una continuità aziendale efficace. L'affidabilità del sistema può essere influenzata da tra cui, a titolo esemplificativo, prestazioni, resilienza, disponibilità di uptime, sicurezza e Esperienza utente. Per ulteriori informazioni su come progettare e gestire servizi affidabili per Google Cloud, consulta affidabilità pilastro di Google Cloud Framework dell'architettura e 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. In questo pattern, esegui il deployment delle stesse applicazioni in più ambienti di calcolo allo scopo 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 che ha interrotto le attività.
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 tornino operativi il prima possibile dopo un'interruzione. In generale, le strategie e i piani di RP spesso aiutano a formare una strategia di continuità aziendale più ampia. Da un dal punto di vista tecnologico, quando inizi a creare strategie di ripristino di emergenza, l'analisi dell'impatto sulla tua attività dovrebbe definire due metriche chiave: RPO (Recovery Point Objective) e ai RTO (Recovery Time Objective). Per ulteriori indicazioni sull'utilizzo di Google Cloud per il ripristino di emergenza, consulta la Guida alla pianificazione del ripristino di emergenza.
Minore è il valore dei valori di destinazione RPO e RTO, maggiore sarà la velocità di recupero dei servizi da un'interruzione con una perdita di dati minima. Tuttavia, ciò comporta costi più elevati perché significa creare sistemi ridondanti. Sistemi ridondanti in grado di di eseguire la replica dei dati quasi in tempo reale e che operano sulla stessa scala a seguito di un evento di errore, aumentano la complessità, il sovraccarico amministrativo ad accesso meno frequente per ridurre i costi di archiviazione.
La decisione di selezionare un pattern o una strategia di RP deve essere basata su un'analisi dell'impatto sull'attività. Ad esempio, le perdite finanziarie derivanti anche da pochi minuti di tempo di riposo per un'organizzazione di servizi finanziari potrebbero superare di gran lunga il costo di implementazione di un sistema di RP. Tuttavia, le aziende di altri settori potrebbero subire ore di inattività senza un notevole effetto sull'attività.
Quando esegui sistemi mission critical in un data center on-premise, è quello di mantenere i sistemi di standby in un secondo data center in una posizione regione. Un approccio più conveniente, tuttavia, è quello di utilizzare un ambiente basato su cloud pubblico nell'ambiente di computing a scopi di failover. Questo approccio è il principale motore modello ibrido di continuità aziendale. Il cloud può essere particolarmente interessante dal punto di vista dei costi, perché ti permette di disattivare parte l'infrastruttura quando non è in uso. Per ottenere una soluzione di RE a un costo inferiore, una soluzione cloud consente a un'azienda di accettare il potenziale aumento dei valori RPO e RTO.
Il diagramma precedente illustra l'uso del cloud come un failover o un'emergenza di ripristino in un ambiente on-premise.
Una variante meno comune (e raramente richiesta) di questo modello è il con continuità multi-cloud. In questo modello, l'ambiente di produzione utilizza un fornitore cloud e l'ambiente di ripristino dei dati dopo un disastro un altro fornitore cloud. Se esegui il deployment di copie dei carichi di lavoro su più cloud provider, potresti aumentare la disponibilità oltre a quanto offre un deployment multi-regione.
Valutazione di un RE su più cloud rispetto all’utilizzo di un solo provider cloud regioni diverse richiede un'analisi approfondita di varie considerazioni, tra cui:
- Gestibilità
- Sicurezza
- La fattibilità complessiva.
- Costo
- I potenziali costi di trasferimento dei dati in uscita da più di un fornitore cloud potrebbero essere elevati con la comunicazione inter-cloud continua.
- 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 tuoi dati devono rimanere nel tuo paese per soddisfare i requisiti normativi, l'utilizzo di un secondo provider cloud che si trovi anche nel tuo paese come DR può essere un'opzione. L'uso di un secondo cloud provider presuppone l'assenza di un'opzione usa un ambiente on-premise per creare una configurazione ibrida. Per evitare di dover riprogettare la tua soluzione cloud, idealmente il tuo secondo cloud provider dovrebbe offrire tutte le le funzionalità e i servizi richiesti di cui hai bisogno nella regione.
Note sul layout
- Aspettativa RE: l'RPO e l'RTO target che l'azienda vuole raggiungere dovrebbe 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. È quindi necessario valutare la fattibilità possibilità di rehosting, refactoring o riprogettazione delle applicazioni Offrire le stesse (o più ottimizzate) funzioni e prestazioni nel cloud completamente gestito di Google Cloud.
- Progettazione e costruzione: la creazione di una zona di destinazione è quasi sempre prerequisito per il deployment dei carichi di lavoro aziendali in un ambiente cloud. Per ulteriori informazioni, vedi Progettazione della zona di destinazione in Google Cloud.
Chiamata RE: è importante che la progettazione e il processo di RE rispondi alle seguenti domande:
- Che cosa scatena uno scenario di RE? Ad esempio, un piano di RE potrebbe essere attivato dal guasto di funzioni o sistemi specifici nel sito principale.
- Come viene invocato il failover nell'ambiente di DR? È un processo di approvazione manuale oppure è possibile automatizzare il processo per raggiungere un target RTO ridotto?
- Come dovrebbero comportarsi i meccanismi di rilevamento e notifica dei guasti del sistema essere progettato per richiamare il failover in linea con l'RTO previsto?
- Come viene reindirizzato il traffico all'ambiente di DR dopo il rilevamento dell'errore?
Convalida le risposte a queste domande tramite test.
Test: testa e valuta a fondo il failover al RE. Assicurati che 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 aggiornamento alla procedura o alla soluzione tecnologica, esegui di nuovo i test.
Competenze di gruppo: uno o più team tecnici devono avere le competenze e Competenza per la creazione, il funzionamento e la risoluzione dei 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 la replica dei dati su un altro sito all'interno dello stesso continente. Puoi anche eseguire il backup di replicare i dati in 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 aree geografiche separate
regioni. I dati archiviati nei bucket dual-region e multi-region vengono replicati
tra regioni geografiche utilizzando la replica predefinita.
- I bucket a due regioni forniscono la ridondanza geografica per supportare le attività piani di continuità e RE. Inoltre, per replicare più velocemente, con RPO inferiore, gli oggetti archiviati in regioni doppie possono facoltativamente utilizzare replica turbo in quelle regioni.
- Analogamente, la replica multiregione fornisce ridondanza in 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 spese operative per costruire una RE:
- Le istanze VM arrestate comportano solo costi di archiviazione e sono molto più economico rispetto all'esecuzione di istanze VM. Ciò significa che puoi ridurre al minimo il costo di manutenzione dei sistemi cold standby.
- Il modello di pagamento per utilizzo di Google Cloud ti consente di pagare solo per la capacità di archiviazione e di calcolo effettivamente utilizzata.
- Le funzionalità di elasticità, come la scalabilità automatica, ti consentono di eseguire lo scale up o lo scale down dell'ambiente di DR in base alle esigenze.
Ad esempio, il seguente diagramma mostra un'applicazione in esecuzione in un ambiente on-premise (di produzione) che utilizza componenti di recupero su Google Cloud con Compute Engine, Cloud SQL e Cloud Load Balancing. In questo scenario, il database viene preconfigurato utilizzando un database basato su VM o un database gestito di Google Cloud, come Cloud SQL, per un recupero più rapido con la replica continua dei dati. Puoi avviare VM Compute Engine da snapshot precreati per ridurre i costi durante le normali operazioni. Con questa configurazione e a seguito di un evento di errore, il DNS deve indicare l'indirizzo IP esterno di Cloud Load Balancing.
Per fare in modo che l'applicazione sia operativa nel cloud, devi eseguire il provisioning del e VM delle applicazioni. A seconda del livello RTO target e delle norme 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 velocizzare e automatizzare il provisioning dell'infrastruttura, valuta la possibilità e la gestione dell'Infrastructure as Code. Puoi utilizzare Cloud Build, uno strumento di integrazione continua, per applicare automaticamente i manifest Terraform del tuo ambiente. Per saperne di più, consulta Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Best practice
Quando utilizzi il modello di continuità aziendale, considera quanto segue: pratiche:
- Crea un piano di ripristino di emergenza che documenta l'infrastruttura, insieme alle procedure di failover e ripristino.
- Valuta le seguenti azioni in base all'analisi dell'impatto aziendale e ai target RPO e RTO obbligatori identificati:
- Decidi se il backup dei dati su Google Cloud è sufficiente o se devi prendere in considerazione un'altra strategia di RE (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.
- Definisci gli scenari di RE applicabili per il tuo applicazioni e dati nell'ambito della strategia di RE selezionata.
- Valuta la possibilità di utilizzare il pattern di trasferimento quando esegui il backup solo dei dati. In caso contrario, motivo mesh potrebbe essere una buona opzione per replicare l'ambiente esistente dell'architettura di rete.
- Riduci 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 diminuire la disponibilità complessiva.
Evita il problema di sdoppiato. Se replichi i dati in modo bidirezionale tra 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 suddivisione può portare alla conclusione che i sistemi in entrambi gli ambienti che l'altro ambiente non è disponibile e che dispone di servizi l'accesso ai dati. Questo può portare a modifiche dei dati in conflitto. Esistono due modi comuni per evitare il problema di split-brain:
- Utilizza un terzo ambiente di calcolo. Questo ambiente consente ai sistemi di verificare la presenza del quorum prima di modificare i dati.
Consenti la riconciliazione delle modifiche ai dati in conflitto dopo la connettività viene ripristinato.
Con i database SQL, puoi evitare il problema dello "split-brain" rendendo l'istanza principale originale inaccessibile prima dell'avvio dei client utilizzando la nuova istanza principale. Per ulteriori informazioni, consulta Ripristino di emergenza per database Cloud SQL.
Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un singolo punto di errore. Quando un ambiente non è disponibile, devi essere ancora 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 (se supportati dalle applicazioni e fattibili) in modo che i sistemi rimangano coerenti tra gli ambienti. Puoi adottare questo approccio considerando i container e Kubernetes. Utilizzando Google Kubernetes Engine (GKE) Enterprise, puoi semplificare la build e le operazioni.
Integra il deployment dei sistemi di riserva nella tua pipeline CI/CD. Questa integrazione contribuisce a garantire che le versioni e le configurazioni delle applicazioni siano coerenti in tutti gli ambienti.
Assicurati che le modifiche al DNS vengano propagate rapidamente configurando il DNS con un numero ragionevolmente breve valore della durata per consentirti di reindirizzare gli utenti ai sistemi in standby in caso di emergenza.
Seleziona i criteri DNS e di routing che si allineano all'architettura e al 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, inclusa 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 che hanno dipendenze tra ambienti on-premise e cloud con una configurazione DNS multi-provider.
Google Cloud offre una soluzione open source basata su octoDNS per per configurare e gestire un ambiente con più provider DNS. Per ulteriori informazioni, consulta DNS pubblico multiprovider utilizzando Cloud DNS.
Usa i bilanciatori del carico quando si usano sistemi in standby per creare un'istanza il failover automatico. Tieni presente che l'hardware del bilanciatore del carico può presentare errori.
Utilizza Cloud Load Balancing invece di bilanciatori del carico hardware per supportare alcuni scenari che si verificano quando si utilizza questo pattern di architettura. Le richieste dei client interni o le richieste dei client esterni possono essere reindirizzate all'ambiente principale o all'ambiente DR in base a metriche diverse, ad esempio la suddivisione del traffico in base al peso. Per ulteriori informazioni, vedi Panoramica della gestione del traffico per il bilanciatore del carico delle applicazioni esterno globale.
Prendi in considerazione l'utilizzo di Cloud Interconnect Cross-Cloud Interconnect se il volume di trasferimento di dati in uscita da Google Cloud all'altro ambiente è elevata. Cloud Interconnect può contribuire a ottimizzare le prestazioni della connettività e potrebbe ridurre gli addebiti per il trasferimento di dati in uscita per il traffico che soddisfa determinate condizioni. Per ulteriori informazioni, vedi Prezzi di Cloud Interconnect.
Valuta la possibilità di utilizzare la soluzione del partner che preferisci su Google Cloud Marketplace per semplificare i backup, le repliche e altre attività dei dati che soddisfano i tuoi requisiti, inclusi i target RPO e RTO.
Testa e valuta gli scenari di chiamata del piano di ripristino di emergenza per capire quanto facilmente l'applicazione può riprendersi da un evento di disastro rispetto al valore RTO target.
Crittografare le comunicazioni in transito. Per proteggere le informazioni sensibili, consiglia di crittografare tutte le comunicazioni in transito. Se è richiesta la crittografia a livello di connettività, sono disponibili varie opzioni in base la soluzione di connettività ibrida selezionata. Queste opzioni includono i tunnel VPN, la VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.