Questo documento illustra come utilizzare Google Cloud per progettare le soluzioni in caso di emergenza Recovery per soddisfare i requisiti specifici della località. Per alcuni settori regolamentati, i carichi di lavoro devono ottemperare a questi requisiti. In questo , si applicano uno o più dei seguenti requisiti:
- I dati at-rest 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 località predefinite.
- I dati devono essere criptati utilizzando chiavi gestite dal cliente.
- Se utilizzi i servizi cloud, ognuno deve fornire una o più di due località ridondanti tra loro. Ad esempio, per i requisiti di ridondanza delle località, consulta Catalogo dei criteri di conformità di Cloud Computing (C5).
La serie è costituita dai seguenti componenti:
- Guida alla pianificazione del ripristino di emergenza
- Componenti di base per il ripristino di emergenza
- Scenari di ripristino di emergenza per i dati
- Scenari di ripristino di emergenza per le applicazioni
- Progettazione del ripristino di emergenza per i carichi di lavoro con limitazioni a livello di località (questo documento)
- Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati con limitazioni a livello di località
- Architettura per il ripristino di emergenza per interruzioni dell'infrastruttura cloud
Terminologia
Prima di iniziare a progettare l'architettura per il RE per carichi di lavoro con limitazioni di località, una buona idea rivedere la terminologia relativa alle località usata in Google Cloud.
Google Cloud fornisce servizi in regioni delle Americhe,
Europa e Medio Oriente e Asia Pacifico. Ad esempio, Londra
(europe-west2
) è una regione dell'Europa, mentre l'Oregon (us-west1
) è una regione dell'
Nord America. Alcuni prodotti Google Cloud raggruppano più regioni in un
specifico
più regioni
accessibile nello stesso modo in cui useresti una regione.
Le regioni sono ulteriormente suddivise in zone in cui esegui il deployment di determinate risorse Google Cloud, di machine learning, cluster Kubernetes o database Cloud SQL. Risorse su Google Cloud sono a livello di più regioni, a livello di regione o di zona. Alcune risorse e prodotti designati per impostazione predefinita come multiregionale può anche essere limitato a una regione. I diversi tipi di risorse spiegati come segue:
- Le risorse multiregionali sono progettate da Google Cloud per ridondanti e distribuiti all'interno e tra le regioni. Le risorse multiregionali resilienti agli errori di una singola regione.
- Il deployment delle risorse di regione viene eseguito in modo ridondante in più zone di una regione, e sono resilienti ai guasti di una zona all'interno della regione.
- Le risorse di zona operano in una singola zona. Se una zona non è più disponibile, tutte le risorse di zona in quella zona non saranno disponibili fino al ripristino del servizio. Considera una zona come un dominio in errore singolo. Devi progettare l'architettura per mitigare gli effetti della mancata disponibilità di una singola zona.
Per ulteriori informazioni, vedi 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 del carico di lavoro e dei requisiti di località che devi soddisfare. Valuta anche il motivo per cui devi soddisfare questi requisiti perché ciò che si decide influisce direttamente sul suo RE dell'architettura.
Per iniziare, leggi le Guida alla pianificazione del ripristino di emergenza di Google Cloud. Se consideri i carichi di lavoro con limitazioni a livello di località, concentrati sui requisiti di cui parleremo in questa sezione sulla pianificazione.
Definisci i requisiti per le località
Prima di iniziare la progettazione, definisci i requisiti delle località rispondendo a queste domande:
- Dove si trovano i dati at-rest? La risposta determina quali servizi e i metodi ad alta disponibilità (HA) e RE utilizzabili per raggiungere i tuoi valori RTO/RPO. Utilizza la Località cloud pagina per stabilire quali prodotti rientrano nell'ambito.
- Puoi utilizzare tecniche di crittografia per attenuare il requisito? Se puoi mitigare i requisiti relativi alle località impiegando la crittografia con Cloud External Key Manager e Cloud Key Management Service, puoi usare i servizi multiregionali e due servizi regionali e seguono le tecniche standard di HA/RE delineato in Scenari di ripristino di emergenza per i dati.
I dati possono essere elaborati al di fuori del luogo in cui si trovano? Puoi utilizzare la modalità prodotti come GKE Enterprise per fornire un ambiente ibrido in grado di soddisfare le tue esigenze o implementare controlli specifici del prodotto come il bilanciamento del carico delle istanze Compute Engine attraverso più zone in una regione. Utilizzare il criterio dell'organizzazione Vincolo di località delle risorse per limitare le località in cui può essere eseguito il deployment delle risorse .
Se i dati possono essere elaborati al di fuori dei luoghi in cui devono essere at-rest, possiamo progettare l'"elaborazione" della tua applicazione seguendo le di assistenza Componenti di base per il ripristino di emergenza e Scenari di ripristino di emergenza per le applicazioni.
Configurare un perimetro dei Controlli di sicurezza VPC per controllare chi può accedere e limitare le risorse che possono elaborarli.
Puoi utilizzare più di una regione? Se puoi utilizzarne più di uno, regione, puoi utilizzare molte delle tecniche descritte nella Serie per il ripristino. Controlla il più regioni e vincoli di regione per i prodotti Google Cloud.
Hai bisogno di limitare l'accesso degli utenti alla tua applicazione? Google Cloud offre diversi prodotti e funzionalità che ti consentono di limitare che possono accedere alle tue applicazioni:
- Identity-Aware Proxy (IAP). Verifica l'identità di un utente e quindi determina se quest'ultimo deve di accedere a un'applicazione. Il criterio dell'organizzazione utilizza condivisione limitata al dominio vincolo per definire le autorizzazioni di Cloud Identity o Google Workspace consentite ID consentiti nei criteri IAM.
- Controlli di località specifici del prodotto. Fai riferimento a ogni prodotto che che vuoi usare nella tua architettura per i vincoli di località appropriati. Ad esempio, se utilizzi Cloud Storage, crea bucket in in determinate regioni.
Identifica i servizi che puoi utilizzare
Identifica quali servizi possono essere utilizzati in base alla tua località e alla tua regione requisiti di granularità. progettazione di applicazioni soggette alla località limitazioni richiede la comprensione dei prodotti che possono essere limitati regione e quali controlli è possibile applicare per applicare la limitazione di località i tuoi requisiti.
Identifica la granularità regionale per la tua applicazione e i tuoi dati
Identifica la granularità regionale per la tua applicazione e i tuoi dati rispondendo queste domande:
- Puoi utilizzare servizi multiregionali nella tua progettazione? Utilizzando a livello di più regioni, puoi creare soluzioni resilienti diverse architetture.
- L'accesso alla tua applicazione prevede limitazioni relative alla posizione? Utilizza le funzionalità di
questi prodotti Google Cloud per aiutarti ad applicare le applicazioni
sono accessibili da:
- Google Cloud Armor. Consente di implementare vincoli basati su dati geografici e IP.
- Controlli di servizio VPC. Fornisce sicurezza perimetrale basata sul contesto.
- I tuoi dati at-rest sono limitati a una regione specifica? Se utilizzi 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 BigQuery limitazioni di località per determinare dove vengono archiviati e eseguiti i backup dei tuoi set di dati.
- A quali regioni devi limitare la tua applicazione? Alcune I prodotti Google Cloud non hanno limitazioni regionali. Utilizza la Località cloud e le pagine specifiche dei prodotti per verificare quali regioni puoi utilizzare del prodotto e le eventuali funzionalità di mitigazione disponibili limita l'applicazione a una regione specifica.
Rispettare le limitazioni relative alle località utilizzando i prodotti Google Cloud
Questa sezione descrive le funzionalità e le tecniche di mitigazione per l'utilizzo Prodotti Google Cloud nell'ambito della tua strategia di RE per le limitazioni a livello di località carichi di lavoro con scale out impegnativi. Ti consigliamo di leggere questa sezione Componenti di base per il ripristino di emergenza.
Criteri dell'organizzazione
La Servizio Criteri dell'organizzazione ti offre un controllo centralizzato sulle tue risorse Google Cloud. Utilizzo criteri dell'organizzazione, puoi configurare limitazioni in tutto gerarchia delle risorse. Considera quanto segue. vincoli dei criteri quando si progetta per carichi di lavoro con limitazioni a livello di località:
Condivisione limitata al dominio: Per impostazione predefinita, è consentito aggiungere tutte le identità utente i criteri IAM. L'elenco di elementi consentiti o negati deve specificare uno o più identità cliente di Cloud Identity o Google Workspace. Se questo vincolo è attivo, solo le identità nell'elenco consentito sono i criteri IAM possono essere aggiunti ai criteri IAM.
Risorse con limitazioni in base alla località: Questo vincolo si riferisce all'insieme di località in cui le puoi creare risorse Google Cloud. Criteri per questo vincolo puoi specificare come località consentite o negate uno dei seguenti: regioni multiple come Asia ed Europa, regioni come
us-east1
oeurope-west1
o singole zone comeeurope-west1-b
. Per un elenco di servizi supportati, vedi Servizi supportati dalle località delle risorse.
Crittografia
Se i requisiti per le località dei dati riguardano la limitazione di chi può accedere ai dati, allora l'implementazione dei metodi di crittografia potrebbe essere una strategia applicabile. Utilizzando per gestire le chiavi fornite al di fuori Google Cloud, potresti essere in grado di eseguire il deployment di un'architettura multiregionale in base ai requisiti per le località. Senza le chiavi disponibili, i dati non possono essere decriptato.
Google Cloud offre due prodotti che ti consentono di utilizzare le chiavi gestite da te:
- Cloud External Key Manager (Cloud EKM): Cloud EKM ti consente di criptare i dati in BigQuery Compute Engine con chiavi di crittografia archiviate e gestite un sistema di gestione delle chiavi di terze parti di cui è stato eseguito il deployment al di fuori dell'infrastruttura.
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 e utilizzate per crittografare e decriptare i dati.
Se fornisci una chiave di crittografia fornita dal cliente, Google non memorizzare in modo permanente la chiave sui server di Google o gestire in altro modo i tuoi chiave. Devi invece fornire la chiave per ogni operazione e la chiave eliminati definitivamente dai server di Google al termine dell'operazione.
Quando gestisci la tua infrastruttura chiave, devi considerare attentamente la latenza ai problemi di affidabilità e affidabilità e assicurarti di implementare le soluzioni appropriate processi di ripristino per il gestore di chiavi esterno. Devi a comprendere i requisiti RTO. Le chiavi sono fondamentali per scrivere dati, perciò l'RPO non è il problema critico perché non è possibile scrivere dati senza le chiavi. Il vero problema è l'RTO, perché senza le chiavi non è possibile decriptare o scrivere in modo sicuro i dati.
Archiviazione
Quando progetti l'architettura di RE per carichi di lavoro con limitazioni a livello di località, devi assicurarti che i dati at-rest si trovano nella regione richiesta. Puoi configurare Servizi di archiviazione di oggetti e file Google Cloud per soddisfare i tuoi requisiti
Cloud Storage
Puoi creare bucket Cloud Storage che soddisfano limitazioni di località.
Oltre alle funzionalità illustrate nella sezione Cloud Storage del l'articolo sui componenti di base per il ripristino di emergenza, quando si progetta per la RE per con limitazioni di località, valuta se ridondanza tra regioni è un requisito: gli oggetti archiviati più regioni e due regioni sono archiviati in almeno due aree geograficamente separate, indipendentemente dal loro di archiviazione standard. Questa ridondanza garantisce la massima disponibilità dei tuoi dati, durante interruzioni su larga scala, come le calamità naturali. Le due regioni raggiungono 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 potrebbero includere data center non esplicitamente indicate come regioni disponibili.
La sincronizzazione dei dati tra i bucket avviene in modo asincrono. Se hai bisogno un elevato grado di certezza che i dati sono stati scritti in un'alternativa regione per soddisfare i valori RTO e RPO, una strategia consiste nell'utilizzare due regioni bucket. Puoi quindi eseguire la doppia scrittura dell'oggetto oppure scrivere in un bucket avere una copia di Cloud Storage al 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 sola regione, di implementare un'architettura ridondante in più località geografiche usando solo Google Cloud. In questo scenario, prova a utilizzare una o più delle seguenti tecniche:
Adotta una strategia multi-cloud o ibrida. Questo approccio ti permette di scegliere un'altra soluzione cloud o on-premise nella stessa area geografica del tuo regione Google Cloud. Puoi archiviare copie dei tuoi dati in nei bucket Cloud Storage on-premise o, in alternativa, usa Cloud Storage come destinazione per i dati di backup.
Per utilizzare questo approccio, segui questi passaggi:
- Assicurati che i requisiti relativi alla distanza siano soddisfatti.
- Se utilizzi AWS come altro cloud provider, consulta le Interoperabilità di Cloud Storage guida su come configurare l'accesso ad Amazon S3 utilizzando gli strumenti di Google Cloud.
- Per altri cloud e soluzioni on-premise, prendi in considerazione l'open source soluzioni come minIO e Ceph di archiviazione di oggetti on-premise.
- Valuta la possibilità di utilizzare Cloud Composer con la riga di comando
gcloud storage
per trasferire i dati da un archivio di oggetti on-premise di archiviazione ideale in Cloud Storage. - Utilizza la Transfer Service for On Premises Data per copiare i dati archiviati on-premise in Cloud Storage.
Implementare tecniche di crittografia. Se i requisiti per le località lo consentono usando tecniche di crittografia come soluzione alternativa, puoi usare più regioni o bucket a due regioni.
Filestore
Filestore offre spazio di archiviazione gestito per i file di cui regioni e zone in base ai requisiti di limitazioni per le località.
Database gestiti
Scenari di ripristino di emergenza per i dati descrive i metodi per implementare strategie di backup e ripristino per Google Cloud servizi di database gestiti. Oltre a utilizzare questi metodi, devi prendere in considerazione anche le limitazioni relative alle località per ciascun servizio di database gestito che utilizzi nella tua architettura, esempio:
Bigtable è disponibile in località di zona all'interno di una regione. Le istanze di produzione hanno almeno due cluster, che devono trovarsi in zone univoche della regione. Replica tra i cluster in un'istanza Bigtable viene gestita automaticamente realizzati da Google. Bigtable sincronizza i dati tra i cluster, creando una copia separata e indipendente dei tuoi dati in ogni zona in cui un'istanza non ha un cluster. La replica rende possibile il traffico in entrata a fail over in un altro cluster nella stessa istanza.
BigQuery ha limitazioni di località che determinano dove sono archiviati i tuoi set di dati. Le località del set di dati possono essere a livello di una o più regioni. Per offrire resilienza durante un processo regionale devi eseguire il backup dei dati in un'altra posizione geografica. Nel caso di BigQuery con più regioni, consigliamo di evitare il backup in regioni che rientrano nell'ambito di più regioni. Se selezioni la località multiregionale dell'UE, escludi Zurigo e Londra dalla configurazione multiregionale. Per indicazioni sull'implementazione di una soluzione di RE per BigQuery che risolvi l'improbabile evento di una perdita fisica a livello di regione, consulta Perdita di regione.
Per comprendere le implicazioni dell'adozione di una o più regioni configurazioni BigQuery, consulta Documentazione di BigQuery.
Puoi utilizzare la modalità Firestore per archiviare i dati Firestore in una località multiregionale di una località regionale. I dati in una località multiregionale operano in un configurazione replicata multizona e multiregionale. Seleziona una località multiregionale se i tuoi requisiti di limitazione per località vuoi massimizzare la disponibilità e la durabilità del tuo per configurare un database. località multiregionali possono far fronte alla perdita di intere regioni per mantenere la disponibilità senza perdita di dati. I dati in un funziona la località regionale in un configurazione replicata multizona.
Puoi configurare Cloud SQL alta disponibilità. Un'istanza Cloud SQL configurata per l'alta disponibilità è chiamata anche all'istanza e si trova in una zona principale e una secondaria nella regione. In un'istanza a livello di regione, la configurazione è composta da un e un'istanza in standby. Assicurati di aver compreso il tempo di failover tipico dall'istanza principale a quella in standby.
Se i tuoi requisiti lo consentono, puoi configurare Cloud SQL repliche tra regioni. In caso di emergenza, la replica di lettura in una regione diversa può essere promosso. Poiché le repliche di lettura possono essere configurate in anticipo per l'alta disponibilità, non hanno bisogno di apportare 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 che può offrire protezione immediata da errori a livello di regione dopo la replica promozione.
Puoi configurare Spanner come regionale o più regioni. Per qualsiasi configurazione a livello di regione, Spanner mantiene tre repliche di lettura e scrittura, ognuna in un ambiente Google Cloud zona in quella regione. Ogni replica di lettura/scrittura contiene una copia completa operativo in grado di fornire dati di lettura/scrittura e di sola lettura richieste.
Spanner usa repliche in zone diverse in modo che, se si verifica un errore a zona singola, il database rimane disponibile. Un deployment Spanner multiregionale offre un ambiente coerente in più regioni, tra cui due regioni di lettura-scrittura e una regione witness contenente un replica witness. Devi verificare che località di tutte le regioni in modo da soddisfare i requisiti delle limitazioni per le località.
Compute Engine
Le risorse Compute Engine globali, regionali o zone. alle risorse di Compute Engine, istanze di macchine virtuali o a livello di zona dischi permanenti sono definite risorse di zona. Altre risorse, ad esempio indirizzi IP esterni statici, sono regionali. Le risorse a livello di regione possono essere utilizzate da qualsiasi risorsa in quella regione, a prescindere dalla zona, mentre le risorse di zona possono essere utilizzate solo da altre risorse in nella stessa zona.
Collocando le risorse in zone diverse di una regione le isola dal la maggior parte dei tipi di guasti all'infrastruttura fisica e degli errori dei servizi software. Inoltre, collocare le risorse in regioni diverse offre un grado ancora più alto di indipendenza dai fallimenti. Questo approccio ti consente di progettare sistemi robusti con risorse distribuite su diversi domini di errore.
Per ulteriori informazioni, vedi regioni e zone.
Utilizzo di ambienti on-premise o di altri cloud come sito di produzione
È possibile che tu stia utilizzando una regione Google Cloud che ti impedisce di utilizzare combinazioni di due o più regioni per la tua architettura di RE. Per soddisfare la località restrizioni 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 carichi di lavoro ibridi. Architetture di RE che utilizzano on-premise e Google Cloud sono discussi in questo argomento Scenari di ripristino di emergenza per le applicazioni.
GKE Enterprise
GKE Enterprise è la piattaforma per applicazioni ibride e multi-cloud aperta di Google Cloud ti aiuta a eseguire in modo sicuro i carichi di lavoro basati su container ovunque. GKE Enterprise garantisce la coerenza tra on-premise e cloud ambienti, in modo da avere un modello operativo coerente e una visione unica per i 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 di architetture ad alta disponibilità e failover in ambienti diversi (tra Google Cloud e l'ambiente on-premise o un altro cloud). Puoi eseguire di produzione GKE Enterprise 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 unico piano di controllo in esecuzione in una zona. Questo piano di controllo gestisce i carichi di lavoro su nodi in esecuzione nella stessa zona.
- Cluster multi-zona. Un cluster multi-zona ha un'unica replica del un piano di controllo in esecuzione in una singola zona con nodi in esecuzione in più zone
- a livello di regione.
Cluster a livello di regione
replicare i nodi principali e i nodi in più zone in un unico
regione. Ad esempio, un cluster a livello di regione nella regione
us-east1
crea del piano di controllo e dei nodi in tre zoneus-east1
:us-east1-b
,us-east1-c
eus-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 consente di eseguire carichi di lavoro VMware nel cloud. Se i tuoi carichi di lavoro on-premise Basata su VMware, puoi progettare l'architettura della tua soluzione RE in modo che venga eseguita di virtualizzazione in esecuzione on-premise. Puoi selezionare regione che soddisfa i requisiti per le località.
Networking
Quando il piano di RE si basa sul trasferimento di dati da ambienti on-premise Google Cloud o da un altro cloud provider a Google Cloud, devi definire la tua strategia di networking. Per ulteriori informazioni, consulta Trasferimento di dati da e verso Google Cloud della sezione "Componenti di base per il ripristino di emergenza" documento.
Controlli di servizio VPC
Quando pianifichi la tua strategia di RE, devi assicurarti che i controlli di sicurezza si applicano anche all'ambiente di produzione. e si estendono anche all'ambiente di failover. Utilizzando Controlli di servizio VPC, puoi definire un perimetro di sicurezza da reti on-premise ai tuoi progetti in Google Cloud.
I Controlli di servizio VPC consentono accesso sensibile al contesto per controllare le risorse cloud. Puoi creare un accesso granulare controlla i criteri in Google Cloud in base ad attributi come l'identità dell'utente e indirizzo IP. Questi criteri aiutano a garantire che vengano applicate le misure di sicurezza in ambienti on-premise e Google Cloud.
Passaggi successivi
- Leggi altri articoli di questa serie di RE:
- Guida alla pianificazione del ripristino di emergenza
- Componenti di base per il ripristino di emergenza
- Scenari di ripristino di emergenza per i dati
- Scenari di ripristino di emergenza per le applicazioni
- Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati con limitazioni a livello di località
- Architettura per il ripristino di emergenza per interruzioni dell'infrastruttura cloud
- Leggi il white paper Residenza dei dati, trasparenza operativa e privacy per i clienti europei su Google Cloud (PDF).
- Per altre architetture di riferimento, diagrammi e best practice, esplora il Centro architetture cloud.