Progettazione del ripristino di emergenza per i carichi di lavoro con limitazioni a livello di località

Last reviewed 2022-06-10 UTC

Questo documento illustra come utilizzare Google Cloud per progettare il ripristino di emergenza (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 un paese specificato.
  • I dati devono essere trattati nel paese in cui si trovano.
  • I carichi di lavoro sono accessibili solo da posizioni predefinite.
  • I dati devono essere criptati usando 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 catalogo dei criteri di conformità per il cloud computing (C5).

Questo articolo è la quinta parte di una serie dedicata al ripristino di emergenza (RE) in Google Cloud. Questa parte fornisce una panoramica del processo di pianificazione di RE: cosa devi sapere per progettare e implementare un piano di RE.

La serie è costituita dai seguenti componenti:

Terminologia

Prima di iniziare a progettare l'architettura per il RE per carichi di lavoro con limitazioni a livello di località, è consigliabile rivedere la terminologia delle località utilizzata in Google Cloud.

Google Cloud offre servizi in regioni delle Americhe, Europa, Medio Oriente e Asia Pacifico. Ad esempio, Londra (europe-west2) è una regione in Europa, mentre l'Oregon (us-west1) è una regione del Nord America. Alcuni prodotti Google Cloud raggruppano più regioni in una località specifica multiregionale, accessibile nello stesso modo in cui useresti una regione.

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

  • Le risorse per più regioni sono progettate da Google Cloud per essere ridondanti e distribuite all'interno e tra le regioni. Le risorse su più regioni sono resistenti al fallimento di una singola regione.
  • Le risorse a livello di regione vengono distribuite in modo ridondante in più zone di una regione e sono resilienti in caso di errore di una zona all'interno della regione.
  • Le risorse di zona operano in un'unica zona. Se una zona non è più disponibile, tutte le risorse di zona al suo interno non saranno disponibili fino al ripristino del servizio. Considera una zona come un dominio in errore singolo. Devi progettare l'architettura delle applicazioni per ridurre gli effetti dovuti al fatto che una singola zona non è più disponibile.

La seguente tabella mostra la relazione attuale tra regioni, zone e località per l'Europa.

Regione Zone Località
europe-north1 a, b, c Hamina, Finlandia
europe-west1 b, c, d Saint-Ghislain, Belgio
europe-west2 a, b, c Londra, Inghilterra, Regno Unito
europe-west3 a, b, c Francoforte, Germania
europe-west4 a, b, c Eemshaven, Paesi Bassi
europe-west6 a, b, c Zurigo, Svizzera

Per ulteriori informazioni, consulta Area geografica e regioni.

Pianificazione del RE per carichi di lavoro con limitazioni a livello di località

L'approccio da adottare nella progettazione dell'applicazione dipende dal tipo di carico di lavoro e dai requisiti di località che devi soddisfare. Valuta anche perché devi soddisfare questi requisiti perché ciò che decidi influenza direttamente l'architettura di RE.

Inizia leggendo la guida alla pianificazione del ripristino di emergenza di Google Cloud. E quando consideri i carichi di lavoro con limitazioni a livello di località, concentrati sui requisiti esaminati in questa sezione di pianificazione.

Definisci i requisiti per le località

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

  • Dove si trovano i dati at-rest? La risposta determina i servizi che puoi utilizzare e i metodi di alta disponibilità (HA) e RE che puoi utilizzare per ottenere i tuoi valori RTO/RPO. Utilizza la pagina Località cloud per determinare quali prodotti sono nell'ambito.
  • È possibile utilizzare tecniche di crittografia per mitigare il requisito? Se sei in grado di ridurre i requisiti di località utilizzando tecniche di crittografia utilizzando Cloud External Key Manager e Cloud Key Management Service, puoi utilizzare servizi multiregionali e a due regioni e seguire le tecniche di alta disponibilità e RE standard descritte in Scenari di ripristino di emergenza per i dati.

  • I dati possono essere elaborati al di fuori della località in cui si trovano? Puoi utilizzare prodotti come GKE Enterprise per offrire un ambiente ibrido in cui soddisfare i requisiti o implementare controlli specifici del prodotto, come il bilanciamento del carico delle istanze di Compute Engine in più zone di una regione. Utilizza il vincolo di località delle risorse del criterio dell'organizzazione per limitare le località in cui è possibile eseguire il deployment delle risorse .

    Se i dati possono essere elaborati al di fuori del luogo in cui devono essere inattivi, puoi progettare le parti di "elaborazione" dell'applicazione seguendo le indicazioni in Componenti di base per il ripristino di emergenza e Scenari di ripristino di emergenza per le applicazioni.

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

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

  • Devi limitare gli utenti che possono accedere alla tua applicazione? Google Cloud offre diversi prodotti e funzionalità che consentono di limitare gli utenti che possono accedere alle applicazioni:

    • Identity-Aware Proxy (IAP). Verifica l'identità di un utente, quindi determina se l'utente deve essere autorizzato ad accedere a un'applicazione. Il criterio dell'organizzazione utilizza il vincolo di condivisione limitata al dominio per definire gli ID Cloud Identity o Google Workspace consentiti nei criteri IAM.
    • Controlli per le località specifici dei prodotti. Fai riferimento a ogni prodotto che vuoi usare nella tua architettura per i vincoli di località appropriati. Ad esempio, utilizza il Configuration Manager di GKE Enterprise per applicare criteri specifici della località ai tuoi cluster GKE gestiti da GKE Enterprise. Se utilizzi Cloud Storage, crea bucket in regioni specificate.

Identifica i servizi che puoi utilizzare

Identifica quali servizi possono essere utilizzati in base ai tuoi requisiti di granularità per località e regione. La progettazione di applicazioni soggette a restrizioni in base alla località richiede la comprensione di quali prodotti è possibile limitare a quale regione e quali controlli possono essere applicati per applicare i requisiti di limitazione di località.

Identifica la granularità a livello di regione per l'applicazione e i dati

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

  • È possibile utilizzare servizi multiregionali nella progettazione? Utilizzando servizi multiregionali, puoi creare architetture resilienti ad alta disponibilità.
  • L'accesso alla tua applicazione ha limitazioni relative alla posizione? Utilizza questi prodotti Google Cloud per determinare da dove è possibile accedere alle tue applicazioni:
  • I dati at-rest sono limitati a una regione specifica? Se utilizzi servizi gestiti, assicurati che questi 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 determinare dove vengono archiviati e sottoposti a backup i tuoi set di dati.
  • 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 convalidare in quali regioni puoi utilizzare il prodotto e quali funzionalità di mitigazione sono disponibili per limitare la tua applicazione a una regione specifica.

Rispettare le limitazioni relative alle località utilizzando i prodotti Google Cloud

Questa sezione descrive nel dettaglio le funzionalità e le tecniche di mitigazione per utilizzare i prodotti Google Cloud nell'ambito della strategia di RE per carichi di lavoro limitati a località. Ti consigliamo di leggere questa sezione insieme ai 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. L'utilizzo dei criteri dell'organizzazione consente di configurare limitazioni nell'intera gerarchia delle risorse. Quando progetti l'architettura per carichi di lavoro con limitazioni a livello di località, prendi in considerazione i seguenti vincoli relativi ai criteri:

  • Condivisione limitata al dominio: per impostazione predefinita, tutte le identità utente possono essere aggiunte ai criteri IAM. L'elenco degli account consentiti/negati deve specificare una o più identità cliente di Cloud Identity o Google Workspace. Se questo vincolo è attivo, solo le identità nell'elenco delle identità consentite sono idonee per essere aggiunte ai criteri IAM.

  • Risorse con limitazioni in base alla località: questo vincolo si riferisce all'insieme di località in cui è possibile creare risorse Google Cloud basate sulla località. Con i criteri di questo vincolo è possibile specificare come consentite o negate le località seguenti: aree geografiche multiple 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 per le località delle risorse.

Crittografia

Se i tuoi requisiti di località dei dati riguardano la limitazione degli utenti che possono accedere ai dati, l'implementazione dei metodi di crittografia potrebbe essere una strategia applicabile. Utilizzando sistemi di gestione delle chiavi esterni per gestire le chiavi che fornisci al di fuori di Google 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 in BigQuery e Compute Engine con chiavi di crittografia archiviate e gestite in un sistema di gestione delle chiavi di terze parti di cui è stato eseguito il deployment al di fuori dell'infrastruttura di Google.

  • Chiavi di crittografia fornite dal cliente (CSEK): puoi utilizzare 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 definitivamente la chiave sui server di Google né la gestisce in altro modo. Devi invece fornire la chiave per ogni operazione, che viene eliminata definitivamente 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 i processi appropriati di alta disponibilità e ripristino per il gestore di chiavi esterno. Devi anche conoscere i tuoi requisiti per l'RTO. Le chiavi sono parte integrante della scrittura dei dati, quindi l'RPO non è un problema critico perché non è possibile scrivere dati in modo sicuro senza le chiavi. Il problema reale è l'RTO, perché senza le chiavi non è possibile decriptare o scrivere dati in modo sicuro.

Archiviazione

Quando progetti RE per carichi di lavoro 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 file e oggetti di Google Cloud per soddisfare

Cloud Storage

Puoi creare bucket Cloud Storage che soddisfano le restrizioni di località.

Oltre alle funzionalità descritte nella sezione Cloud Storage dell'articolo sui componenti di base per il ripristino di emergenza, quando crei l'architettura di RE per carichi di lavoro limitati a località, valuta se è necessario considerare la ridondanza tra regioni: gli oggetti archiviati in più regioni e due regioni vengono archiviati in almeno due aree geograficamente separate, indipendentemente dalla loro classe di archiviazione. Questa ridondanza garantisce la massima disponibilità dei dati, anche in caso di interruzioni su larga scala, come le calamità naturali. Le due regioni consentono di raggiungere questa ridondanza utilizzando una coppia di regioni a tua scelta. Le regioni multiple ottengono questa ridondanza utilizzando qualsiasi combinazione di data center nella località multiregionale specificata, che potrebbe includere data center non indicati esplicitamente come regioni disponibili.

La sincronizzazione dei dati tra i bucket avviene in modo asincrono. Se hai bisogno di un elevato grado di certezza che i dati siano stati scritti in un'area geografica alternativa per soddisfare i valori dell'RTO e dell'RPO, una strategia è utilizzare due bucket a regione singola. Puoi quindi eseguire la doppia scrittura dell'oggetto o la scrittura in un bucket e far sì che Cloud Storage copi (rewriteTo) il secondo bucket.

Strategie di mitigazione a livello di singola regione quando si utilizza Cloud Storage

Se i tuoi requisiti ti limitano all'utilizzo di una singola regione, ad esempio Londra o Zurigo, non puoi utilizzare solo quella regione e non puoi implementare un'architettura ridondante in più località geografiche utilizzando solo Google Cloud. In questo caso, ti consigliamo 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 nei bucket Cloud Storage on-premise o, in alternativa, utilizzare Cloud Storage come destinazione per i dati di backup.

    Per utilizzare questo approccio:

    • Assicurati che siano soddisfatti i requisiti relativi alla distanza.
    • Se utilizzi AWS come altro cloud provider, consulta la guida sull'interoperabilità di Cloud Storage per informazioni su come configurare l'accesso ad Amazon S3 utilizzando gli strumenti di Google Cloud.
    • Per altri cloud e soluzioni on-premise, prendi in considerazione soluzioni open source come minIO e Ceph per fornire un archivio di oggetti on-premise.
    • Valuta la possibilità di utilizzare soluzioni dei partner per fornire un archivio di oggetti on-premise.
    • Prendi in considerazione l'utilizzo di una soluzione di partner per implementare flussi di lavoro che ti consentono di scrivere dati sia in Cloud Storage che in un servizio di archiviazione di oggetti del cloud alternativo.
    • Valuta la possibilità di utilizzare Cloud Composer con l'utilità a riga di comando gsutil per trasferire i dati da un archivio di oggetti on-premise a Cloud Storage.
    • Utilizza Transfer Service for On Premises Data per copiare dati archiviati on-premise su Cloud Storage.

  • Implementare le tecniche di crittografia. Se i tuoi requisiti di località consentono l'utilizzo di tecniche di crittografia come soluzione alternativa, puoi utilizzare bucket multiregionali o a due regioni.

Filestore

Filestore offre archiviazione di file gestita di cui puoi eseguire il deployment in regioni e zone in base ai requisiti delle limitazioni per le località.

Database gestiti

Gli scenari di ripristino di emergenza per i dati descrivono i metodi per implementare le strategie di backup e ripristino per i servizi di database gestiti di Google Cloud. Oltre a utilizzare questi metodi, devi anche considerare le limitazioni relative alle località per ogni servizio di database gestito che utilizzi nella tua architettura, ad esempio:

  • Bigtable è disponibile in località a livello di zona di una regione. Le istanze di produzione hanno un minimo di due cluster, che devono trovarsi in zone univoche della regione. La replica tra i cluster in 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 l'istanza ha un cluster. La replica consente al traffico in entrata di effettuare il failover su un altro cluster nella stessa istanza.

  • BigQuery prevede restrizioni di località che determinano dove vengono archiviati i set di dati. Le località dei set di dati possono essere a livello di una o più regioni. Per garantire resilienza durante una calamità regionale, devi eseguire il backup dei dati in un'altra area geografica. Nel caso di più regioni BigQuery, ti consigliamo di evitare di eseguire il backup in regioni che rientrano nell'ambito di questa metrica. Se selezioni l'opzione multiregionale dell'UE, escludi Zurigo e Londra dalla configurazione per più regioni. Per indicazioni sull'implementazione di una soluzione di RE per BigQuery che risolva l'improbabile eventualità di una perdita fisica a livello di regione, consulta Perdita di regione.

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

  • Puoi utilizzare Firestore per archiviare i dati Firestore in una località a più regioni o in una località a livello di regione. I dati in una località multiregionale operano in una configurazione replicata multizona e multiregionale. Seleziona una località a più regioni se i tuoi requisiti di limitazione per le località lo consentono e vuoi massimizzare la disponibilità e la durabilità del tuo database. Le località in più regioni possono tollerare la perdita di intere regioni e mantenere la disponibilità senza perdita di dati. I dati in una località a livello di regione funzionano in una configurazione replicata multizona.

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

    Se i tuoi requisiti lo consentono, puoi configurare Cloud SQL con repliche tra regioni. In caso di emergenza, è possibile promuovere la replica di lettura in un'altra regione. Poiché le repliche di lettura possono essere configurate in anticipo per l'alta disponibilità, non devono essere apportate ulteriori modifiche dopo la promozione per l'alta disponibilità. Puoi anche configurare le repliche di lettura in modo che abbiano le proprie repliche tra regioni in grado di offrire protezione immediata dagli errori a livello di regione dopo la promozione della replica.

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

    Spanner utilizza le 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 su più regioni, incluse due regioni di lettura-scrittura e una regione di testimoni contenente una replica di testimonianza. Devi verificare che le località di tutte le regioni soddisfino i requisiti relativi alle limitazioni in base alle località.

Compute Engine

Le risorse di Compute Engine sono globali, a livello di regione o di zona. Le risorse di Compute Engine, come le istanze di macchine virtuali o i dischi permanenti di zona, sono definite risorse di zona. Altre risorse, ad esempio indirizzi IP esterni statici, sono a livello di regione. Le risorse 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 nella stessa zona.

L'inserimento delle risorse in zone diverse di una regione le isola dalla maggior parte dei tipi di guasti dell'infrastruttura fisica e di errori del servizio software dell'infrastruttura. Inoltre, collocare le risorse in regioni diverse offre un grado ancora maggiore di indipendenza dagli errori. Questo approccio consente di progettare sistemi affidabili con risorse distribuite su diversi domini di errore.

Per saperne di più, consulta regioni e zone.

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

È possibile che tu stia utilizzando una regione Google Cloud che ti impedisce di utilizzare combinazioni con due o più regioni per l'architettura di RE. In questo caso, per rispettare le limitazioni di località, valuta la possibilità di utilizzare il tuo data center o un altro cloud come sito di produzione o sito 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 aperta di applicazioni ibride e multi-cloud di Google Cloud che ti consente di eseguire in modo sicuro ovunque i carichi di lavoro basati su container. GKE Enterprise garantisce coerenza tra ambienti on-premise e cloud, offrendo un modello operativo coerente e una singola visualizzazione dei cluster Google Kubernetes Engine (GKE), indipendentemente da dove vengono eseguiti.

Nell'ambito della tua strategia di RE, GKE Enterprise semplifica la configurazione e il funzionamento di architetture ad alta disponibilità 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 degli stessi carichi di lavoro sui cluster GKE Enterprise in Google Cloud.

GKE Enterprise su Google Cloud ha tre tipi di cluster:

  • Cluster a zona singola. Un cluster a zona singola ha un 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-zona. Un cluster multi-zona ha un'unica replica del piano di controllo in esecuzione in un'unica zona e ha nodi in esecuzione in più zone
  • di un cluster a livello di regione. I cluster a livello di regione replicano i nodi primari e i nodi del cluster in più zone all'interno di una singola 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 in caso di interruzioni a livello di zona.

Google Cloud VMware Engine

Google Cloud VMware Engine consente di eseguire carichi di lavoro VMware nel cloud. Se i 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 l'area geografica che soddisfa i requisiti per le località.

Networking

Se il tuo piano di RE è basato 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 ulteriori informazioni, consulta la sezione Trasferimento di dati da e verso Google Cloud del documento "Componenti di base per il 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. Con 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 un approccio di accesso sensibile al contesto per controllare le risorse cloud. Puoi creare criteri di controllo granulare degli accessi in Google Cloud in base ad attributi come l'identità dell'utente e l'indirizzo IP. Questi criteri aiutano a garantire che vengano implementati gli appropriati controlli di sicurezza negli ambienti on-premise e Google Cloud.

Passaggi successivi