Il fattore principale per considerare continuità 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 single point of failure, è possibile ridurre al minimo i rischi di una calamità naturale che influisce sull'infrastruttura locale. Altri scenari di errore includono sistemi un errore di sicurezza, un attacco di cybersicurezza o perfino 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 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 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 sue funzioni o i suoi servizi aziendali chiave a livelli accettabili predefiniti, un evento dirompente.
Ripristino RE emergenza è considerata un sottoinsieme della business continuity, concentrandosi esplicitamente sui assicurando che i sistemi IT a supporto di funzioni aziendali critiche operativo il prima possibile dopo un'interruzione. In generale, le strategie di RE e piani 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 affrontare le emergenze il ripristino dei dati di fabbrica, consulta 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 Strategia DR o dovrebbe essere determinato da un'analisi dell'impatto aziendale. Ad esempio, perdite finanziarie derivanti anche da pochi minuti di inattività per un potrebbe 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 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, consiste nell'utilizzare una piattaforma basata 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 basso costo, una soluzione cloud consente alle aziende di accettare il potenziale aumento di RPO e RTO e i relativi valori.
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 pattern, l'ambiente di produzione utilizza da un cloud provider e l'ambiente di RE utilizza un altro cloud provider. Di eseguendo il deployment di copie dei carichi di lavoro su più cloud provider, aumentano la disponibilità oltre l'offerta di un deployment multiregionale.
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
- Fattibilità complessiva.
- Costo
- I potenziali addebiti per il trasferimento di dati in uscita da più di un il cloud provider potrebbe essere costoso 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 tuoi dati devono rimanere nel tuo paese per soddisfare i requisiti normativi, utilizzare un secondo cloud provider presente nel vostro paese, come RE, può essere . 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 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. È 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 prova a rispondere alle seguenti domande:
- Che cosa scatena uno scenario di RE? Ad esempio, RE potrebbe essere causati da errori di funzioni o sistemi specifici nel sito principale.
- Come viene richiamato il failover all'ambiente RE? È 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 RE dopo l'errore viene rilevata?
Convalida le risposte a queste domande attraverso 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 nuovo aggiornamento al processo o alla soluzione tecnologica, esegui nuovamente 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 ha molte regioni in tutto il mondo, puoi utilizzarlo per eseguire il backup o a 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
due o più regioni
di sincronizzare la directory di una VM
con un bucket. I dati vengono archiviati in modo ridondante in almeno due aree geografiche separate
regioni. I dati archiviati in bucket a due e più regioni vengono replicati
in più regioni usando la replica predefinita.
- I bucket a due regioni offrono la ridondanza geografica per supportare le attività la continuità e i piani di 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 multiregionale 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 in base al consumo di Google Cloud significa che l'archiviazione e la capacità di calcolo effettivamente utilizzate.
- Le funzionalità di elasticità, come la scalabilità automatica, ti consentono scalare o ridurre l'ambiente di RE in base alle esigenze.
Ad esempio, il seguente diagramma mostra un'applicazione in esecuzione in ambiente on-premise (produzione) che utilizza componenti di ripristino Google Cloud con Compute Engine, Cloud SQL e e Cloud Load Balancing. In questo scenario, viene eseguito il pre-provisioning del database utilizzando una un database basato su VM o l'utilizzo di un database gestito di Google Cloud, come Cloud SQL, per un ripristino più rapido grazie alla replica continua dei dati. Puoi avviare le VM di Compute Engine da snapshot creati in precedenza per ridurre i costi durante normali operazioni. Con questa configurazione e in seguito a un evento di errore, il DNS deve puntano all'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 di 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 ulteriori informazioni, vedi Gestione dell'infrastruttura come codice con Terraform, Cloud Build e GitOps.
Best practice
Quando utilizzi il modello di continuità aziendale, considera i seguenti aspetti pratiche:
- Crea un piano di ripristino di emergenza che documenta l'infrastruttura, insieme alle procedure di failover e ripristino.
- Prendi in considerazione le seguenti azioni in base all'analisi dell'impatto della tua attività e
i target RPO e RTO richiesti identificati:
- Decidere se eseguire il backup dei dati in Google Cloud sufficienti o se sia necessario prendere in considerazione un'altra strategia di RE (freddo, sistemi caldi o hot standby).
- 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 l'uso della classe modello passo quando esegui solo il backup 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 sistemi in esecuzione in diversi ambienti, in particolare quando le comunicazioni sono gestite 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 ambienti, è possibile che esposto al problema dello "split-cervello". Il problema dello "sdoppiato del cervello" si verifica quando che replicano i dati in modo bidirezionale perdono 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 divisione del cervello:
- Utilizza un terzo ambiente di calcolo. Questo ambiente consente ai sistemi verificare il 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, vedi Ripristino di emergenza del database Cloud SQL.
Assicurati che i sistemi CI/CD e i repository di artefatti non diventino un il single point of failure. Quando un ambiente non è disponibile, devi poter comunque 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 portabilità (se supportata dalle applicazioni e fattibile), in modo che i sistemi rimangono coerenti tra i diversi ambienti. Puoi ottenere questo approccio prendendo in considerazione container e Kubernetes. Utilizzando Google Kubernetes Engine (GKE) Enterprise, puoi semplificare la build e le operazioni.
Integra il deployment dei sistemi in standby nella tua pipeline CI/CD. Questa integrazione aiuta a garantire che le versioni e le configurazioni dell'applicazione sono coerenti tra i vari ambienti.
Assicurati che le modifiche al DNS vengano propagate rapidamente configurando il DNS con un numero ragionevolmente breve valore della durata in modo da poter reindirizzare gli utenti ai sistemi in standby quando si verifica un'emergenza.
Seleziona il criteri DNS e di routing che devono essere in linea con l'architettura e il comportamento della soluzione. Inoltre, puoi combinare più bilanciatori del carico regionali con criteri di routing DNS a 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 servizi.
Semplificare il deployment o la migrazione di applicazioni ibride hanno dipendenze in ambienti cloud e on-premise 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, vedi DNS pubblico multifornitore tramite 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 le funzionalità di Cloud Load Balancing anziché i bilanciatori del carico hardware per supportare alcuni scenari quando si utilizza questo pattern di architettura. Richieste interne del cliente o richieste di client esterne può essere reindirizzato all'ambiente principale o all'ambiente di RE in base a diverse metriche, suddivisione del traffico basata sulle ponderazioni. 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ò aiutare a ottimizzare le prestazioni di connettività e ridurre i costi per il trasferimento di dati in uscita per il traffico che soddisfa determinati conditions. Per ulteriori informazioni, vedi Prezzi di Cloud Interconnect.
Valuta la possibilità di utilizzare la soluzione del tuo partner preferito su Google Cloud Marketplace per facilitare backup dei dati, repliche e altre attività Soddisfare i requisiti, tra cui i target RPO e RTO.
Testa e valuta gli scenari di chiamata RE per capire con quanta facilità l'applicazione può eseguire il ripristino da un evento di emergenza rispetto alla Valore RTO.
Cripta 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 tunnel VPN, VPN ad alta disponibilità su Cloud Interconnect e MACsec per Cloud Interconnect.