Progettazione del disaster recovery per i workload con limitazioni a livello di località

Last reviewed 2024-07-20 UTC

Questo documento illustra come utilizzare Google Cloud per progettare il disaster recovery (RE) in modo da soddisfare i requisiti specifici della località. Per alcuni settori regolamentati, i workload devono rispettare questi requisiti. In questo scenario, si applicano uno o più dei seguenti requisiti:

  • I dati inattivi devono essere limitati a una località specificata.
  • I dati devono essere elaborati nella località in cui si trovano.
  • I carichi di lavoro sono accessibili solo da posizioni predefinite.
  • I dati devono essere criptati utilizzando chiavi gestite dal cliente.
  • Se utilizzi servizi cloud, ogni servizio cloud deve fornire un minimo di due località ridondanti tra loro. Per un esempio di requisiti di ridondanza della località, consulta il Cloud Computing Compliance Criteria Catalogue (C5).

La serie è composta dalle seguenti parti:

Terminologia

Prima di iniziare a progettare il RE per i workload con limitazioni a livello di località, è consigliabile esaminare la terminologia relativa alla località utilizzata in Google Cloud.

Google Cloud fornisce servizi in regioni in tutte le Americhe, in Europa, in Medio Oriente e nell'Asia Pacifico. Ad esempio, Londra (europe-west2) è una regione in Europa e Oregon (us-west1) è una regione in Nord America. Alcuni Google Cloud prodotti raggruppano più regioni in una località multiregionale specifica, accessibile allo stesso modo in cui utilizzeresti una regione.

Le regioni sono ulteriormente suddivise in zone in cui esegui il deployment di determinate Google Cloud risorse, come macchine virtuali, cluster Kubernetes o database Cloud SQL. Le risorse su Google Cloud sono multiregionali, regionali o di zona. Alcune risorse e alcuni prodotti designati per impostazione predefinita come multiregionali possono anche essere limitati a una regione. I diversi tipi di risorse sono spiegati di seguito:

  • Le risorse multiregionali sono progettate da Google Cloud per essere ridondanti e distribuite all'interno e tra le regioni. Le risorse multiregionali sono resilienti all'errore di una singola regione.

  • Le risorse regionali vengono distribuite in modo ridondante in più zone di una regione e sono resilienti al guasto di una zona all'interno della regione.

  • Le risorse di zona operano in una singola zona. Se una zona diventa non disponibile, tutte le risorse di zona in quella zona non saranno disponibili fino al ripristino del servizio. Considera una zona come un dominio single point of failure. Devi progettare le tue applicazioni per mitigare gli effetti della mancata disponibilità di una singola zona.

Per saperne di più, consulta Geografia e regioni.

Pianificazione del RE per i workload con limitazioni a livello di località

L'approccio che adotti per progettare la tua applicazione dipende dal tipo di carico di lavoro e dai requisiti di località che devi soddisfare. Considera anche il motivo per cui devi soddisfare questi requisiti, perché ciò che decidi influisce direttamente sull'architettura dREDR.

Inizia leggendo la Google Cloud guida alla pianificazione del disaster recovery. Quando prendi in considerazione i carichi di lavoro con limitazioni di località, concentrati sui requisiti descritti in questa sezione di pianificazione.

Definisci i requisiti di località

Prima di iniziare la progettazione, definisci i requisiti di località rispondendo a queste domande:

  • Dove si trovano i dati at-rest? La risposta determina quali servizi puoi utilizzare e quali metodi di alta affidabilità (HA) e RE puoi impiegare per raggiungere i valori RTO/RPO. Utilizza la pagina Località cloud per determinare quali prodotti sono inclusi nell'ambito.
  • Puoi utilizzare tecniche di crittografia per mitigare il requisito? Se riesci a mitigare i requisiti di località utilizzando tecniche di crittografia con Cloud External Key Manager e Cloud Key Management Service, puoi utilizzare servizi multiregionali e dual-region e seguire le tecniche standard di HA/RE descritte in Scenari di ripristino di emergenza per i dati.

  • I dati possono essere trattati al di fuori della loro posizione? Puoi utilizzare prodotti come GKE Enterprise per fornire un ambiente ibrido per soddisfare i tuoi requisiti o implementare controlli specifici del prodotto, ad esempio bilanciare il carico delle istanze Compute Engine in più zone di una regione. Utilizza il vincolo Località delle risorse della policy dell'organizzazione per limitare i luoghi di deployment delle risorse .

    Se i dati possono essere elaborati al di fuori della posizione in cui devono essere at-rest, puoi progettare le parti di "elaborazione" della tua applicazione seguendo le indicazioni riportate in Elementi costitutivi del disaster recovery e Scenari di disaster recovery per le applicazioni.

    Configura un perimetro dei Controlli di servizio VPC per controllare chi può accedere ai dati e per limitare le risorse che possono elaborarli.

  • Puoi utilizzare più di una regione? Se puoi utilizzare più di una regione, puoi utilizzare molte delle tecniche descritte nella serie Disaster Recovery. Controlla i vincoli multiregionali e regionali per i prodotti Google Cloud .

  • Devi limitare l'accesso alla tua applicazione? Google Cloud offre diversi prodotti e funzionalità che ti aiutano a limitare l'accesso alle tue applicazioni:

    • Identity-Aware Proxy (IAP). Verifica l'identità di un utente e poi determina se deve essere autorizzato ad accedere a un'applicazione. I criteri dell'organizzazione utilizzano il vincolo condivisione con limitazioni del dominio per definire gli ID Cloud Identity o Google Workspace consentiti nelle policy IAM.
    • Controlli specifici per località del prodotto. Fai riferimento a ogni prodotto che vuoi utilizzare nella tua architettura per i vincoli di località appropriati. Ad esempio, se utilizzi Cloud Storage, crea bucket in regioni specifiche.

Identificare i servizi che puoi utilizzare

Identifica i servizi che possono essere utilizzati in base ai requisiti di granularità locali e regionali. La progettazione di applicazioni soggette a limitazioni di località richiede di comprendere quali prodotti possono essere limitati a quale regione e quali controlli possono essere applicati per far rispettare i requisiti di limitazione della località.

Identifica la granularità regionale per l'applicazione e i dati

Identifica la granularità regionale per la tua applicazione e i tuoi dati rispondendo a queste domande:

  • Puoi utilizzare servizi multiregionali nel tuo design? Utilizzando servizi multiregionali, puoi creare architetture resilienti ad alta disponibilità.
  • L'accesso alla tua applicazione ha limitazioni di posizione? Utilizza questi Google Cloud prodotti per contribuire a far rispettare i luoghi da cui è possibile accedere alle tue applicazioni:
  • I tuoi dati at-rest sono limitati a una regione specifica? Se utilizzi servizi gestiti, assicurati che i servizi che utilizzi possano essere configurati in modo che i dati archiviati nel servizio siano limitati a una regione specifica. Ad esempio, utilizza le limitazioni di località di BigQuery per stabilire dove archiviare e eseguire il backup dei set di dati.
  • A quali regioni devi limitare la tua applicazione? Alcuni Google Cloud prodotti non hanno limitazioni regionali. Utilizza la pagina Località cloud e le pagine specifiche del prodotto per verificare in quali regioni puoi utilizzare il prodotto e quali funzionalità di mitigazione, se presenti, sono disponibili per limitare l'applicazione a una regione specifica.

Rispetto delle limitazioni relative alla località della riunione utilizzando i prodotti Google Cloud

Questa sezione descrive in dettaglio le funzionalità e le tecniche di mitigazione per l'utilizzo dei prodottiGoogle Cloud nell'ambito della strategia di RE per i carichi di lavoro con limitazioni di località. Ti consigliamo di leggere questa sezione insieme a Componenti di base per il ripristino di emergenza.

Criteri dell'organizzazione

Il servizio Criteri dell'organizzazione ti offre un controllo centralizzato sulle tue risorse Google Cloud . Utilizzando i criteri dell'organizzazione, puoi configurare le limitazioni nell'intera gerarchia delle risorse. Quando progetti workload con limitazioni a livello di località, tieni presente i seguenti vincoli dei criteri:

  • Condivisione limitata per i domini: Per impostazione predefinita, è consentito aggiungere tutte le identità utente ai criteri IAM. L'elenco delle identità consentite/negate deve specificare una o più identità cliente di Cloud Identity o Google Workspace. Se questo vincolo è attivo, solo le identità nell'elenco consentito possono essere aggiunte ai criteri IAM.

  • Risorse con limitazioni geografiche: Questo vincolo si riferisce all'insieme di località in cui è possibile creare risorseGoogle Cloud basate sulla località. I criteri per questo vincolo possono specificare come località consentite o negate una delle seguenti: più regioni come Asia ed Europa, regioni come us-east1 o europe-west1 o singole zone come europe-west1-b. Per un elenco dei servizi supportati, consulta Servizi supportati dalle località delle risorse.

Crittografia

Se i tuoi requisiti di località dei dati riguardano la limitazione dell'accesso ai dati, l'implementazione di metodi di crittografia potrebbe essere una strategia applicabile. Se utilizzi sistemi di gestione delle chiavi esterne per gestire le chiavi fornite al di fuori diGoogle Cloud, potresti essere in grado di eseguire il deployment di un'architettura multiregionale per soddisfare i requisiti di località. Senza le chiavi disponibili, i dati non possono essere decriptati.

Google Cloud offre due prodotti che ti consentono di utilizzare le chiavi che gestisci:

  • Cloud External Key Manager (Cloud EKM): Cloud EKM consente di criptare i dati di BigQuery e Compute Engine mediante chiavi di crittografia archiviate e gestite in un sistema di gestione delle chiavi di terze parti di cui viene eseguito il deployment al di fuori dell'infrastruttura di Google.

  • Chiavi di crittografia fornite dal cliente (CSEK): puoi utilizzare le CSEK con Cloud Storage e Compute Engine. Google utilizza la tua chiave per proteggere le chiavi generate da Google utilizzate per criptare e decriptare i tuoi dati.

    Se fornisci una chiave di crittografia fornita dal cliente, Google non archivia permanentemente la chiave sui suoi server né la gestisce in altro modo. Fornisci invece la chiave per ogni operazione e la chiave viene eliminata dai server di Google al termine dell'operazione.

Quando gestisci la tua infrastruttura di chiavi, devi considerare attentamente i problemi di latenza e affidabilità e assicurarti di implementare processi di HA e ripristino appropriati per il gestore di chiavi esterno. Devi anche comprendere i requisiti RTO. Le chiavi sono fondamentali per la scrittura dei dati, quindi l'RPO non è il problema principale perché nessun dato può essere scritto in modo sicuro senza le chiavi. Il vero problema è il RTO perché senza le chiavi non puoi decriptare o scrivere dati in modo sicuro.

Archiviazione

Quando progetti RE per i workload con limitazioni a livello di località, devi assicurarti che i dati at-rest si trovino nella regione che ti serve. Puoi configurare i servizi di archiviazione di oggetti e fileGoogle Cloud per soddisfare i tuoi requisiti

Cloud Storage

Puoi creare bucket Cloud Storage che soddisfino i limiti di località.

Oltre alle funzionalità descritte nella sezione Cloud Storage dell'articolo Elementi costitutivi del disaster recovery, quando progetti il RE per carichi di lavoro con limitazioni di località, valuta se la ridondanza tra regioni è un requisito: gli oggetti archiviati in più regioni e due regioni vengono archiviati in almeno due aree geografiche separate, indipendentemente dalla classe di archiviazione. Questa ridondanza garantisce la massima disponibilità dei dati, anche durante interruzioni su larga scala, come i disastri naturali. Le regioni duali raggiungono questa ridondanza utilizzando una coppia di regioni a tua scelta. Le regioni multiple raggiungono questa ridondanza utilizzando qualsiasi combinazione di data center nella regione multipla specificata, che potrebbe includere data center non elencati esplicitamente come regioni disponibili.

La sincronizzazione dei dati tra i bucket avviene in modo asincrono. Se hai bisogno di un alto grado di certezza che i dati siano stati scritti in una regione alternativa per soddisfare i valori RTO e RPO, una strategia consiste nell'utilizzare due bucket monoregionali. Puoi quindi scrivere l'oggetto in entrambi i bucket o in uno solo e fare in modo che Cloud Storage lo copi nel secondo bucket.

Strategie di mitigazione a singola regione quando utilizzi Cloud Storage

Se i tuoi requisiti ti impediscono di utilizzare una singola regione, non puoi implementare un'architettura ridondante in più località geografiche utilizzando solo Google Cloud . In questo scenario, valuta la possibilità di utilizzare una o più delle seguenti tecniche:

  • Adotta una strategia multi-cloud o ibrida. Questo approccio ti consente di scegliere un'altra soluzione cloud o on-premise nella stessa area geografica della tua regioneGoogle Cloud . Puoi archiviare copie dei tuoi dati in bucket Cloud Storage on-premise oppure utilizzare Cloud Storage come destinazione per i dati di backup.

    Per utilizzare questo approccio:

    • Assicurati che i requisiti di distanza siano soddisfatti.
    • Se utilizzi AWS come altro provider di servizi cloud, consulta la guida all'interoperabilità di Cloud Storage per scoprire come configurare l'accesso ad Amazon S3 utilizzando gli strumenti Google Cloud .
    • Per altri cloud e soluzioni on-premise, valuta soluzioni open source come minIO e Ceph per fornire un archivio di oggetti on-premise.
    • Prendi in considerazione l'utilizzo di Cloud Composer con l'utilità a riga di comando gcloud storage per trasferire dati da un object store on-premise a Cloud Storage.
    • Utilizza il servizio di trasferimento per dati on-premise per copiare i dati archiviati on-premise in Cloud Storage.

  • Implementa tecniche di crittografia. Se i requisiti di località consentono di utilizzare tecniche di crittografia come soluzione alternativa, puoi utilizzare bucket multiregionali o a doppia regione.

Filestore

Filestore fornisce uno spazio di archiviazione file gestito che puoi implementare in regioni e zone in base ai tuoi requisiti di limitazione della località.

Database gestiti

Scenari di ripristino di emergenza dei dati descrive i metodi per implementare strategie di backup e ripristino per iGoogle Cloud servizi di database gestiti. Oltre a utilizzare questi metodi, devi anche considerare le limitazioni di località per ogni servizio di database gestito che utilizzi nella tua architettura, ad esempio:

  • Bigtable è disponibile in località zonali di una regione. Le istanze di produzione hanno un minimo di due cluster, che devono trovarsi in zone uniche della regione. La replica tra i cluster in un'istanza Bigtable viene gestita automaticamente da Google. Bigtable sincronizza i dati tra i cluster, creando una copia separata e indipendente dei dati in ogni zona in cui l'istanza ha un cluster. La replica consente il failover del traffico in entrata su un altro cluster nella stessa istanza.

  • BigQuery ha limitazioni di località che stabiliscono dove vengono archiviati i set di dati. Le località dei set di dati possono essere regionali o multiregionali. Per garantire la resilienza durante un disastro regionale, devi eseguire il backup dei dati in un'altra posizione geografica. Nel caso di più regioni BigQuery, ti consigliamo di evitare di eseguire il backup nelle regioni incluse nell'ambito della multiregione. Se selezioni la multiregione UE, escludi Zurigo e Londra dalla configurazione multiregionale. Per indicazioni sull'implementazione di una soluzione di RE per BigQuery che risolva l'improbabile evento di una perdita regionale fisica, consulta Perdita della regione.

    Per comprendere le implicazioni dell'adozione di configurazioni BigQuery a una o più regioni, consulta la documentazione di BigQuery.

  • Puoi utilizzare Firestore per archiviare i tuoi dati Firestore in una località multiregionale o in una località regionale. I dati in una località multiregionale operano in una configurazione replicata multizona e multiregionale. Seleziona una località multiregionale se i tuoi requisiti di limitazione della località lo consentono e vuoi massimizzare la disponibilità e la durabilità del tuo database. Le località multiregionali possono far fronte alla perdita di intere regioni e mantenere la disponibilità senza perdita di dati. I dati in una posizione regionale operano in una configurazione replicata multizona.

  • Puoi configurare Cloud SQL per l'alta disponibilità. Un'istanza Cloud SQL configurata per l'alta disponibilità è chiamata anche istanza regionale e si trova in una zona principale e secondaria nella regione configurata. In un'istanza regionale, la configurazione include un'istanza principale e un'istanza in standby. Assicurati di comprendere il tempo di failover tipico dall'istanza principale a quella di standby.

    Se i tuoi requisiti lo consentono, puoi configurare Cloud SQL con repliche cross-region. In caso di emergenza, la replica di lettura in un'altra regione può essere promossa. Poiché le repliche di lettura possono essere configurate in anticipo per la HA, non devono subire modifiche aggiuntive dopo la promozione per la HA. Puoi anche configurare le repliche di lettura in modo che abbiano le proprie repliche tra regioni, che possono offrire una protezione immediata da errori regionali dopo la promozione della replica.

  • Puoi configurare Spanner come regionale o multiregionale. Per qualsiasi configurazione regionale, Spanner gestisce tre repliche di lettura e scrittura, ciascuna in una Google Cloud zona diversa in quella regione. Ogni replica di lettura/scrittura contiene una copia completa del tuo database operativo in grado di gestire richieste di lettura/scrittura e di sola lettura.

    Spanner utilizza repliche in zone diverse in modo che, in caso di errore in una singola zona, il database rimanga disponibile. Un deployment multiregionale di Spanner fornisce un ambiente coerente in più regioni, tra cui due regioni di lettura/scrittura e una regione di testimonianza contenente una replica di testimonianza. Devi verificare che le località di tutte le regioni soddisfino i requisiti di limitazione della località.

Compute Engine

Le risorse di Compute Engine sono globali, regionali o di zona. Le risorse Compute Engine come le istanze di macchine virtuali o i dischi permanenti a livello di zona sono definite risorse di zona. Altre risorse, come gli indirizzi IP esterni statici, sono a livello di regione. Le risorse a livello di regione possono essere utilizzate da qualsiasi risorsa di quella regione, indipendentemente dalla zona, mentre le risorse di zona possono essere utilizzate solo da altre risorse della stessa zona.

Il posizionamento delle risorse in zone diverse di una regione le isola dalla maggior parte dei tipi di errori dell'infrastruttura fisica e dei servizi software dell'infrastruttura. Inoltre, il posizionamento delle risorse in regioni diverse offre un livello ancora più elevato di indipendenza dagli errori. Questo approccio ti consente di progettare sistemi robusti con risorse distribuite su diversi domini di errore.

Per saperne di più, consulta Regioni e zone.

Utilizzo di on-premise o di un altro cloud come sito di produzione

Potresti utilizzare una regione Google Cloud che ti impedisce di utilizzare combinazioni di due o più regioni per l'architettura di RE. Per rispettare le limitazioni di località in questo caso, valuta la possibilità di utilizzare il tuo data center o un altro cloud come sito di produzione o di failover.

Questa sezione illustra i prodotti Google Cloud ottimizzati per i carichi di lavoro ibridi. Le architetture di RE che utilizzano on-premise e Google Cloud sono descritte in Scenari di ripristino di emergenza per le applicazioni.

GKE Enterprise

GKE Enterprise è la piattaforma di applicazioni ibride e multi-cloud di Google Cloudche ti aiuta a eseguire in sicurezza i tuoi carichi di lavoro basati su container ovunque. GKE Enterprise consente la coerenza tra gli ambienti on-premise e cloud, offrendo un modello operativo coerente e una singola visualizzazione dei cluster Google Kubernetes Engine (GKE), indipendentemente da dove li esegui.

Nell'ambito della tua strategia di RE, GKE Enterprise semplifica la configurazione e il funzionamento delle architetture HA e di failover in ambienti diversi (tra Google Cloud e on-premise o un altro cloud). Puoi eseguire i tuoi cluster GKE Enterprise di produzione on-premise e, in caso di emergenza, puoi eseguire il failover per eseguire gli stessi carichi di lavoro sui cluster GKE Enterprise inGoogle Cloud.

GKE Enterprise su Google Cloud ha tre tipi di cluster:

  • Cluster a zona singola. Un cluster a zona singola ha un unico control plane in esecuzione in una zona. Questo piano di controllo gestisce i carichi di lavoro sui nodi in esecuzione nella stessa zona.
  • Cluster multizona. Un cluster multi-zona ha una singola replica del control plane in esecuzione in un'unica zona e nodi in esecuzione in più zone
  • Cluster a livello di regione. I cluster regionali replicano i nodi e i primari del cluster in più zone di una singola regione. Ad esempio, un cluster regionale nella regione us-east1 crea repliche del control plane e dei nodi in tre zone us-east1: us-east1-b, us-east1-c e us-east1-d.

I cluster a livello di regione sono i più resilienti alle interruzioni a livello di zona.

Google Cloud VMware Engine

Google Cloud VMware Engine ti consente di eseguire i carichi di lavoro VMware nel cloud. Se i tuoi carichi di lavoro on-premise sono basati su VMware, puoi progettare la tua soluzione di RE in modo che venga eseguita sulla stessa soluzione di virtualizzazione che utilizzi on-premise. Puoi selezionare la regione che soddisfa i requisiti della tua località.

Networking

Se il tuo piano di RE si basa sullo spostamento dei dati da on-premise a Google Cloud o da un altro cloud provider a Google Cloud, devi affrontare la tua strategia di networking. Per saperne di più, consulta la sezione Trasferimento dei dati da e verso Google Cloud del documento "Elementi costitutivi del disaster recovery".

Controlli di servizio VPC

Quando pianifichi la tua strategia di RE, devi assicurarti che i controlli di sicurezza che si applicano al tuo ambiente di produzione si estendano anche al tuo ambiente di failover. Utilizzando Controlli di servizio VPC, puoi definire un perimetro di sicurezza dalle reti on-premise ai tuoi progetti in Google Cloud.

I Controlli di servizio VPC consentono di adottare un approccio di accesso sensibile al contesto per controllare le tue risorse cloud. Puoi creare criteri granulari di controllo degli accessi in Google Cloud in base ad attributi come identità dell'utente e indirizzo IP. Questi criteri aiutano a garantire che vengano implementati i controlli di sicurezza appropriati nei tuoi ambienti on-premise e Google Cloud .

Passaggi successivi