Modelli di business continuity ibridi e multi-cloud

Last reviewed 2025-01-23 UTC

L'elemento principale che spinge a prendere in considerazione la continuità aziendale per i sistemi mission-critical è aiutare un'organizzazione a essere resiliente e a continuare le sue operazioni aziendali durante e dopo gli eventi di errore. Se repliche i sistemi e i dati in più regioni geografiche ed eviti i single point of failure, puoi ridurre al minimo i rischi di una calamità naturale che colpisce l'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 diversi fattori, tra cui, a titolo esemplificativo, prestazioni, resilienza, disponibilità del tempo di attività, sicurezza ed esperienza utente. Per saperne di più su come progettare e gestire servizi affidabili su Google Cloud, consulta il pilastro della affidabilità del Google Cloud Framework dell'architettura e gli elementi costitutivi dell'affidabilità in Google Cloud.

Questo pattern di architettura si basa su un deployment ridondante delle applicazioni su più ambienti di calcolo. 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 normali 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. Dal punto di vista della tecnologia, 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 indicazioni sull'utilizzo di Google Cloud per il ripristino di emergenza, consulta la Guida alla pianificazione del ripristino di emergenza.

Più piccoli sono i valori target di RPO e RTO, più velocemente i servizi potrebbero riprendersi da un'interruzione con una perdita minima di dati. Tuttavia, ciò comporta un costo più elevato perché implica la creazione di sistemi ridondanti. I sistemi ridondanti in grado di eseguire la replica dei dati quasi in tempo reale e che operano alla stessa scala in seguito a un evento di errore aumentano la complessità, il sovraccarico amministrativo e i costi.

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 dell'implementazione di un sistema di RP. Tuttavia, le attività di altri settori potrebbero subire ore di inattività senza effetti significativi sull'attività.

Quando esegui sistemi mission-critical in un data center on-premise, un approccio di RP consiste nel gestire sistemi di riserva in un secondo data center in un'altra regione. Un approccio più economico, tuttavia, è utilizzare un ambiente di calcolo basato su cloud pubblico per il failover. Questo approccio è il motore principale del pattern ibrido di continuità aziendale. 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 un costo inferiore, una soluzione cloud consente a un'azienda di accettare il potenziale aumento dei valori RPO e RTO.

Dati in entrata da un ambiente on-premise a un'istanza di disaster recovery ospitata in Google Cloud.

Il diagramma precedente illustra l'utilizzo del cloud come ambiente di failover o di recupero in caso di disastro per un ambiente on-premise.

Una variante meno comune (e raramente richiesta) di questo pattern è il pattern multicloud per la continuità aziendale. In questo modello, l'ambiente di produzione utilizza un fornitore cloud e l'ambiente di DR 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.

La valutazione di un piano di ripristino dei dati su più cloud rispetto all'utilizzo di un fornitore di servizi cloud con regioni diverse richiede un'analisi approfondita di diversi fattori, tra cui:

  • Gestibilità
  • Sicurezza
  • La fattibilità complessiva.
  • Costo
    • I potenziali costi di trasferimento di dati in uscita da più di un fornitore cloud potrebbero essere elevati con la comunicazione inter-cloud continua.
    • Quando si esegue la replica dei database, può verificarsi un volume elevato di traffico.
    • TCO e il costo della 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 RE può essere un'opzione. L'utilizzo di un secondo provider cloud presuppone che non sia possibile 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 necessari in-region.

Note sul layout

  • Aspettative relative al DR: i target RPO e RTO che la tua attività vuole raggiungere devono guidare l'architettura di DR e la pianificazione della creazione.
  • 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 RP. Pertanto, devi valutare la fattibilità e la fattibilità del rehosting, del refactoring o della riprogettazione delle tue applicazioni per fornire le stesse funzioni e prestazioni (o più ottimizzate) nell'ambiente cloud.
  • Progettazione e creazione: la creazione di una landing zone è quasi sempre un prerequisito per il deployment dei carichi di lavoro aziendali in un ambiente cloud. Per maggiori informazioni, consulta Progettazione della zona di destinazione in Google Cloud.
  • Richiesta di RE: per la progettazione e la procedura di RE, è importante rispondere alle seguenti domande:

    • Che cosa attiva 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? Si tratta di una procedura di approvazione manuale o può essere automatizzata per raggiungere un target RTO basso?
    • Come devono essere progettati i meccanismi di rilevamento e notifica degli errori di sistema per invocare il failover in linea con il 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 attentamente il failover al DR. Assicurati che sia in linea con le tue aspettative di RPO e RTO. In questo modo, avrai più fiducia nell'eseguire il ripristino dei dati 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 del team: uno o più team tecnici devono disporre delle competenze e delle conoscenze necessarie per creare, gestire e risolvere i problemi relativi al carico di lavoro di produzione nell'ambiente cloud, a meno che l'ambiente non sia gestito da terze parti.

Vantaggi

L'utilizzo di Google Cloud per la continuità aziendale offre diversi vantaggi:

  • Poiché Google Cloud ha molte regioni in tutto il mondo tra cui scegliere, puoi utilizzarlo per eseguire il backup o la replica dei dati in un altro sito all'interno dello stesso continente. Puoi anche eseguire il backup o la replica dei 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 nei bucket dual-region e multi-region vengono replicati tra regioni geografiche utilizzando la replica predefinita.
    • I bucket a due regioni forniscono ridondanza geografica per supportare la continuità aziendale e i piani di RE. Inoltre, per eseguire la replica più velocemente, con un RPO più basso, gli oggetti archiviati in regioni con due o più regioni possono facoltativamente utilizzare la replica turbo in queste regioni.
    • Analogamente, la replica multiregione 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 piano di RE:
    • Le istanze VM arrestate comportano solo costi di archiviazione e sono molto più economiche delle istanze VM in esecuzione. Ciò significa che puoi ridurre al minimo il costo della manutenzione dei sistemi in standby a freddo.
    • 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 RE 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 suGoogle Cloud con Compute Engine, Cloud SQL e bilanciamento del carico Cloud. In questo scenario, il database viene preconfigurato utilizzando un database basato su VM o un Google Cloud database gestito, 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.

Un'applicazione in esecuzione in un ambiente di produzione on-premise che utilizza componenti di recupero su Google Cloud con Compute Engine, Cloud SQL e Cloud Load Balancing.

Per rendere operativa l'applicazione nel cloud, devi eseguire il provisioning delle VM web e di applicazione. A seconda del livello RTO target e delle norme aziendali, l'intera procedura per invocare un piano di RE, eseguire il provisioning del carico di lavoro nel cloud e ripristinare il traffico può essere completata 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 di 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à aziendale, tieni presenti le seguenti best practice:

  • Crea un piano di ripristino di emergenza che documenti l'infrastruttura insieme alle procedure di failover e di recupero.
  • Valuta le seguenti azioni in base all'analisi dell'impatto sull'attività e ai target RPO e RTO obbligatori identificati:
    • Decidi se eseguire il backup dei dati su Google Cloud è sufficiente o se devi prendere in considerazione un'altra strategia di RP (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.
    • Delinea gli scenari di DR applicabili per le tue applicazioni e per i tuoi dati nell'ambito della strategia di DR selezionata.
  • Valuta la possibilità di utilizzare il pattern di trasferimento quando esegui il backup solo dei dati. In caso contrario, il pattern a maglia 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 viene gestita in modo sincrono. Queste dipendenze possono rallentare le prestazioni e ridurre la disponibilità complessiva.
  • Evita il problema del cervello diviso. 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ò causare la conclusione da parte dei sistemi in entrambi gli ambienti che l'altro ambiente non è disponibile e che hanno accesso esclusivo ai dati. Ciò può comportare modifiche in conflitto dei dati. 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 il ripristino della connettività.

      Con i database SQL, puoi evitare il problema di 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 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 comunque essere in grado di eseguire il deployment di nuove release o applicare modifiche alla configurazione.

  • Rendi portabili tutti i workload quando utilizzi sistemi di riserva. 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 la versione Enterprise di Google Kubernetes Engine (GKE), puoi semplificare la compilazione 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 DNS vengano propagate rapidamente configurando il DNS con un valore TTL ragionevolmente breve in modo da poter reindirizzare gli utenti ai sistemi di riserva in caso di emergenza.

  • Seleziona i policy DNS e di routing che si allineano all'architettura e al comportamento della soluzione. Inoltre, puoi combinare più bilanciatori del carico regionali con i criteri di routing DNS per creare architetture di bilanciamento del carico globale 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 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 aiutarti a configurare e gestire un ambiente con più provider DNS. Per ulteriori informazioni, consulta DNS pubblico multiprovider utilizzando Cloud DNS.

  • Utilizza i bilanciatori del carico quando utilizzi sistemi di riserva per creare un failover automatico. Tieni presente che l'hardware del bilanciatore del carico può guastarsi.

  • 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, consulta la 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ò 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, consulta i 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, 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.