Progettazione del ripristino di emergenza per i carichi di lavoro 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 carichi di lavoro devono rispettare questi requisiti. In questo scenario, si applicano uno o più dei seguenti requisiti:

  • I dati at-rest devono essere limitati a una località specifica.
  • I dati devono essere elaborati nella posizione in cui si trovano.
  • I carichi di lavoro sono accessibili solo da località predefinite.
  • I dati devono essere criptati utilizzando chiavi gestite dal cliente.
  • Se utilizzi servizi cloud, ogni servizio cloud deve fornire almeno 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 dai seguenti componenti:

Terminologia

Prima di iniziare a progettare il RE per i carichi di lavoro con limitazioni di località, è buona prassi esaminare la terminologia delle località utilizzata in Google Cloud.

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

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

  • Le risorse multi-regione sono progettate da Google Cloud per essere ridondanti e distribuite all'interno e tra le regioni. Le risorse multiregionali sono resilienti al guasto di una singola regione.
  • Le risorse regionali vengono distribuite tramite deployment 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 un'unica zona. Se una zona diventa non disponibile, tutte le risorse di zona al suo interno non saranno disponibili fino al ripristino del servizio. Considera una zona come un dominio con un solo errore. Devi progettare le tue applicazioni per attenuare gli effetti della mancata disponibilità di una singola zona.

Per ulteriori informazioni, consulta Geografia e regioni.

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

L'approccio che scegli per progettare l'applicazione dipende dal tipo di carico di lavoro e dai requisiti di località che devi soddisfare. Valuta anche il motivo per cui devi soddisfare questi requisiti, perché le tue decisioni influiscono direttamente sull'architettura di RE.

Inizia leggendo la guida alla pianificazione del ripristino di emergenza di Google Cloud. Quando valuti i carichi di lavoro con limitazioni di località, concentrati sui requisiti discussi in questa sezione di pianificazione.

Definisci i requisiti relativi alla località

Prima di iniziare a progettare, definisci i requisiti della località rispondendo a queste domande:

  • Dove si trovano i dati at-rest? La risposta indica quali servizi puoi utilizzare e i metodi di alta disponibilità (HA) e RE che 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 ad attenuare i requisiti di località utilizzando tecniche di crittografia con Cloud External Key Manager e Cloud Key Management Service, puoi utilizzare servizi multiregionali e dual-regionali e seguire le tecniche HA/RE standard 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 in grado di soddisfare i tuoi requisiti o implementare controlli specifici del prodotto, come il bilanciamento del carico delle istanze Compute Engine su più zone in una regione. Utilizza il vincolo Località della risorsa del criterio dell'organizzazione per limitare i luoghi in cui è possibile eseguire il deployment delle risorse .

    Se i dati possono essere elaborati al di fuori della posizione in cui devono essere inattivi, puoi progettare le parti di "elaborazione" dell'applicazione seguendo le indicazioni riportate in Componenti di base del piano di ripristino dei disastri e Scenari di ripristino dei disastri per le applicazioni.

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

  • È possibile utilizzare più di una regione? Se puoi utilizzare più regioni, puoi utilizzare molte delle tecniche descritte nella serie sul recupero di emergenza. Controlla i vincoli per le regioni multiple e le regioni per i prodotti Google Cloud.

  • Devi limitare chi può accedere alla tua applicazione? Google Cloud offre diversi prodotti e funzionalità che ti aiutano a limitare chi può accedere alle tue applicazioni:

    • Identity-Aware Proxy (IAP). Verifica l'identità di un utente e poi determina se l'utente deve essere autorizzato ad accedere a un'applicazione. Il criterio dell'organizzazione utilizza il vincolo di condivisione con limitazioni al dominio per definire gli ID Cloud Identity o Google Workspace consentiti nei criteri IAM.
    • Controlli della località specifici per i prodotti. 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 nelle regioni specificate.

Identificare i servizi che puoi utilizzare

Identifica i servizi che puoi utilizzare in base alla tua località e ai requisiti di granularità regionale. La progettazione di applicazioni soggette a limitazioni per località richiede di comprendere quali prodotti possono essere limitati a quali regioni e quali controlli possono essere applicati per applicare 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 i servizi multiregionali, puoi creare architetture resilienti ad alta disponibilità.
  • L'accesso alla tua applicazione è soggetto a limitazioni geografiche? Utilizza questi prodotti Google Cloud per contribuire a stabilire da dove è possibile accedere alle tue applicazioni:
  • I tuoi dati at-rest sono limitati a una regione specifica? Se utilizzi servizi gestiti, assicurati che 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 specificare dove vengono archiviati i set di dati e dove viene eseguito il backup.
  • A quali regioni devi limitare la tua applicazione? Alcuni prodotti Google Cloud 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 disponibili, sono disponibili per limitare l'applicazione a una regione specifica.

Soddisfare le restrizioni relative alla località utilizzando i prodotti Google Cloud

Questa sezione descrive in dettaglio le funzionalità e le tecniche di mitigazione per l'utilizzo dei prodotti Google Cloud nell'ambito della tua strategia di RE per i carichi di lavoro soggetti a limitazioni locali. Ti consigliamo di leggere questa sezione insieme ai componenti di base per il ripristino di emergenza.

Criteri dell'organizzazione

Il servizio Criteri dell'organizzazione offre un controllo centralizzato sulle tue risorse Google Cloud. Con i criteri dell'organizzazione, puoi configurare le restrizioni nell'intera gerarchia delle risorse. Tieni presenti i seguenti vincoli delle norme quando progetti l'architettura per i workload con limitazioni a livello di località:

  • Condivisione limitata al dominio: 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 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 risorse Google Cloud basate sulla località. I criteri di questo vincolo possono specificare come località consentite o negate una delle seguenti opzioni: regioni con 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 requisiti relativi alla località dei dati riguardano la limitazione di chi può accedere ai dati, l'implementazione di metodi di crittografia potrebbe essere una strategia applicabile. Se utilizzi sistemi di gestione delle chiavi esterni per gestire le chiavi fornite al di fuori di Google Cloud, potresti essere in grado di implementare un'architettura multi-regione per soddisfare i tuoi 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 chiavi 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 la archivia permanentemente sui suoi server né la gestisce in altro modo. Fornisci invece la chiave per ogni operazione, che viene eliminata dai server di Google al termine dell'operazione.

Quando gestisci la tua infrastruttura delle chiavi, devi valutare attentamente i problemi di latenza e affidabilità e assicurarti di implementare procedure di HA e recupero appropriate per il tuo gestore delle chiavi esterno. Devi anche conoscere i tuoi requisiti RTO. Le chiavi sono fondamentali per la scrittura dei dati, pertanto il RPO non è un problema critico perché nessun dato può essere scritto in sicurezza senza le chiavi. Il problema principale è il RTO, perché senza le chiavi non puoi decriptare o scrivere i dati in sicurezza.

Archiviazione

Quando progetti RE per i workload con limitazioni a livello di località, devi assicurarti che i dati at-rest si trovino nella regione richiesta. Puoi configurare i servizi di archiviazione di oggetti e file di Google Cloud in base alle tue esigenze

Cloud Storage

Puoi creare bucket Cloud Storage che rispettino le limitazioni di località.

Oltre alle funzionalità discusse nella sezione Cloud Storage dell'articolo Elementi costitutivi del disaster recovery, quando progetti un'architettura per il RE per i 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 calamità naturali. L'archiviazione a due regioni ottiene questa ridondanza utilizzando una coppia di regioni scelte da te. Le regioni multiple ottengono 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 grado elevato di certezza che i dati siano stati scritti in una regione alternativa per soddisfare i valori RTO e RPO, una strategia è utilizzare due bucket con una sola regione. Puoi quindi eseguire la scrittura duale dell'oggetto o scrivere in un bucket e lasciare che sia Cloud Storage a copiarlo nel secondo bucket.

Strategie di mitigazione per una singola regione quando si utilizza Cloud Storage

Se i tuoi requisiti ti limitano all'utilizzo di 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 regione Google Cloud. Puoi archiviare copie dei tuoi dati in bucket Cloud Storage on-premise oppure, in alternativa, 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 cloud, consulta la guida sull'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 object store on-premise.
    • Valuta la possibilità di utilizzare Cloud Composer con l'utility gcloud storage a riga di comando per trasferire dati da un object store on-premise a Cloud Storage.
    • Utilizza il servizio di trasferimento per i dati on-premise per copiare i dati archiviati on-premise in Cloud Storage.

  • Implementare tecniche di crittografia. Se i requisiti relativi alla località consentono di utilizzare tecniche di crittografia come soluzione alternativa, puoi utilizzare bucket multiregione o con doppia regione.

Filestore

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

Database gestiti

Scenari di ripristino di emergenza per i dati descrive i metodi per implementare strategie di backup e recupero per i servizi di database gestiti di Google Cloud. Oltre a utilizzare questi metodi, devi anche prendere in considerazione le limitazioni di località per ogni servizio di database gestito che utilizzi nell'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 diverse della regione. La replica tra i cluster di un'istanza Bigtable è gestita automaticamente da Google. Bigtable sincronizza i dati tra i cluster, creando una copia separata e indipendente dei dati in ogni zona in cui la tua 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 determinano dove vengono archiviati i set di dati. Le località dei set di dati possono essere regionali o multiregionali. Per garantire la resilienza in caso di calamità 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 nell'ambito della regione multipla. Se selezioni la regione multipla UE, escludi Zurigo e Londra dalla configurazione multi-regione. Per indicazioni sull'implementazione di una soluzione di RE per BigQuery che tenga conto dell'improbabile evento di una perdita fisica della regione, consulta Perdita della regione.

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

  • Puoi utilizzare Firestore per archiviare i dati di Firestore in una località con più regioni o in una località a singola regione. I dati in una località multiregionale funzionano in una configurazione replicata multizona e multiregionale. Seleziona una località multiregionale se i 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 perdere dati. I dati in una località regionale vengono gestiti in una configurazione replicata in più zone.

  • 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 è composta da un'istanza principale e un'istanza in standby. Assicurati di conoscere il tempo di failover tipico dall'istanza principale a quella di standby.

    Se i tuoi requisiti lo consentono, puoi configurare Cloud SQL con repliche tra regioni. In caso di incidente, la replica di lettura in un'altra regione può essere promovida. Poiché le repliche di lettura possono essere configurate per l'HA in anticipo, non è necessario apportare ulteriori modifiche dopo la promozione per l'HA. Puoi anche configurare le repliche di lettura in modo che abbiano le proprie repliche tra regioni che possono offrire protezione immediata dagli 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 diversa zona Google Cloud della regione. Ogni replica di lettura/scrittura contiene una copia completa del database operativo in grado di soddisfare richieste di lettura/scrittura e di sola lettura.

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

Compute Engine

Le risorse Compute Engine sono globali, a livello di regione o zona. Le risorse Compute Engine, come istanze di macchine virtuali o dischi permanenti a livello di zona, sono definite risorse di zona. Altre risorse, come 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.

Se le risorse vengono collocate in zone diverse di una regione, queste sono isolate dalla maggior parte dei tipi di errori dell'infrastruttura fisica e dei servizi software di infrastruttura. Inoltre, collocare le risorse in regioni diverse offre un grado ancora maggiore di indipendenza dagli errori. Questo approccio consente di progettare sistemi robusti con risorse distribuite su diversi domini di errore.

Per ulteriori informazioni, consulta Regioni e zone.

Utilizzo di un ambiente 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 relative alla località in questo caso, ti consigliamo di utilizzare il tuo data center o un altro cloud come sito di produzione o come sito di failover.

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

GKE Enterprise

GKE Enterprise è la piattaforma di applicazioni ibrida e multi-cloud aperta di Google Cloud che ti aiuta a eseguire in sicurezza i tuoi carichi di lavoro basati su container ovunque. GKE Enterprise garantisce la coerenza tra gli ambienti on-premise e cloud, consentendoti di avere un modello operativo coerente e una singola visualizzazione dei tuoi 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 incidente, puoi eseguire il failover per eseguire gli stessi carichi di lavoro sui cluster GKE Enterprise in Google Cloud.

GKE Enterprise su Google Cloud dispone di tre tipi di cluster:

  • Cluster a zona singola. Un cluster a zona singola ha un unico piano di controllo in esecuzione in una zona. Questo piano di controllo gestisce i carichi di lavoro sui nodi in esecuzione nella stessa zona.
  • Cluster multi-zonale. Un cluster multi-zona ha una singola replica del piano di controllo in esecuzione in un'unica zona e nodi in esecuzione in più zone
  • Cluster a livello di regione. I cluster a livello di regione replicano i nodi e i principali del cluster in più zone di un'unica regione. Ad esempio, un cluster a livello di regione nella regione us-east1 crea repliche del piano di controllo 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 carichi di lavoro VMware nel cloud. Se i carichi di lavoro on-premise sono basati su VMware, puoi progettare la soluzione di RE in modo che venga eseguita sulla stessa soluzione di virtualizzazione in esecuzione on-premise. Puoi selezionare la regione che soddisfa i requisiti relativi alla località.

Networking

Quando il piano di RE si basa sullo spostamento dei dati da ambienti on-premise a Google Cloud o da un altro cloud provider a Google Cloud, devi affrontare la tua strategia di networking. Per ulteriori informazioni, consulta la sezione Trasferimento dei dati da e verso Google Cloud del documento "Componenti di base del ripristino di emergenza".

Controlli di servizio VPC

Quando pianifichi la tua strategia di RE, devi assicurarti che i controlli di sicurezza applicati all'ambiente di produzione si estendano anche all'ambiente di failover. Utilizzando i 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 controllo dell'accesso sensibile al contesto per 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 gli appropriati controlli di sicurezza negli ambienti on-premise e Google Cloud.

Passaggi successivi