Architetta del ripristino di emergenza per le interruzioni dell'infrastruttura cloud

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Questo articolo fa parte di una serie che parla del ripristino di emergenza (RE) in Google Cloud. Questa parte illustra il processo per l'architettura di carichi di lavoro utilizzando Google Cloud e componenti di base resilienti alle interruzioni dell'infrastruttura cloud.

La serie è composta da queste parti:

Introduzione

Man mano che le aziende spostano i carichi di lavoro sul cloud pubblico, devono tradurre le proprie conoscenze sulla creazione di sistemi on-premise resilienti nell'infrastruttura iperscalabile di cloud provider come Google Cloud. In questo articolo vengono mappati i concetti standard del settore relativi al ripristino di emergenza, come RTO (Recovery Time Objective) e RPO (Recovery Point Objective) all'infrastruttura di Google Cloud.

Le indicazioni contenute in questo documento seguono uno dei principi chiave di Google per ottenere una disponibilità di servizi estremamente elevata: pianifica il fallimento. Sebbene Google Cloud fornisca un servizio estremamente affidabile, le catastrofi che colpiscono (disastri naturali, fibre tagli e complessi guasti dell'infrastruttura) e queste calamità causano interruzioni. La pianificazione per le interruzioni consente ai clienti di Google Cloud di creare applicazioni che funzionano in modo prevedibile attraverso questi eventi inevitabili, utilizzando prodotti Google Cloud con meccanismi di ripristino di emergenza integrati.

Il ripristino di emergenza è un argomento ampio che copre molto di più dei soli errori di infrastruttura, come bug di software o danneggiamento dei dati, e dovresti avere un piano end-to-end completo. Tuttavia, questo articolo si concentra su una parte di un piano generale di ripristino di emergenza: come progettare applicazioni resilienti alle interruzioni dell'infrastruttura cloud. Nello specifico, questo articolo illustra i seguenti aspetti:

  1. L'infrastruttura di Google Cloud, il modo in cui gli eventi di emergenza si manifestano come interruzioni di Google Cloud e il modo in cui Google Cloud è progettato per ridurre al minimo la frequenza e l'ambito delle interruzioni.
  2. Una guida alla pianificazione dell'architettura che fornisce un framework per classificare le applicazioni e progettarle in base ai risultati di affidabilità desiderati.
  3. Un elenco dettagliato di alcuni prodotti Google Cloud che offrono funzionalità di ripristino di emergenza integrate che puoi utilizzare nella tua applicazione.

Per ulteriori dettagli sulla pianificazione di ripristino di emergenza generale e sull'utilizzo di Google Cloud come componente nella strategia di ripristino di emergenza on-premise, consulta la guida alla pianificazione del ripristino di emergenza. Inoltre, anche se la disponibilità elevata è un concetto strettamente correlato al ripristino di emergenza, non è trattato in questo articolo. Per ulteriori dettagli sull'architettura per l'alta disponibilità, consulta il framework di architettura di Google Cloud.

Una nota sulla terminologia: questo articolo si riferisce alla disponibilità quando si tratta della possibilità di accedere a un prodotto e di utilizzarlo nel tempo, mentre l'affidabilità si riferisce a un insieme di attributi, tra cui disponibilità, ma anche aspetti come durabilità e correttezza.

In che modo Google Cloud è progettato per la resilienza

Data center di Google

I data center tradizionali si basano sulla massimizzazione della disponibilità dei singoli componenti. Nel cloud, la scalabilità consente a operatori come Google di distribuire i servizi su più componenti utilizzando tecnologie di virtualizzazione e, di conseguenza, di superare l'affidabilità tradizionale dei componenti. Ciò significa che puoi allontanare la tua mentalità relativa all'architettura di affidabilità dai tantissimi dettagli che un tempo ti preoccupavano on-premise. Anziché preoccuparti delle varie modalità di errore dei componenti, ad esempio il raffreddamento e l'alimentazione, puoi pianificare i prodotti Google Cloud e le relative metriche di affidabilità. Queste metriche riflettono il rischio di interruzione aggregato dell'intera infrastruttura sottostante. Ciò ti consente di concentrarti maggiormente sulla progettazione, sul deployment e sulle operazioni delle applicazioni, anziché sulla gestione dell'infrastruttura.

Google progetta la propria infrastruttura per soddisfare i target di disponibilità aggressivi in base alla nostra vasta esperienza di creazione e gestione di data center moderni. Google è un leader mondiale nella progettazione di data center. Dall'alimentazione al raffreddamento alle reti, ogni tecnologia di data center ha le proprie ridondanze e mitigazioni, inclusi i piani FMEA. I data center di Google sono progettati in modo da bilanciare questi numerosi rischi diversi e presentano ai clienti un livello di disponibilità costante per i prodotti Google Cloud. Google utilizza la sua esperienza per modellare la disponibilità dell'architettura generale del sistema fisico e logico per garantire che la progettazione del data center soddisfi le aspettative. Gli ingegneri di Google fanno di tutto per garantire l'operatività di tali aspettative. Di solito, la disponibilità effettiva misurata supera di norma i nostri target di progettazione.

Accorpando tutti questi rischi e mitigazioni dei data center in prodotti rivolti agli utenti, Google Cloud ti libera da queste responsabilità di progettazione e operative. Puoi invece concentrarti sull'affidabilità progettata nelle aree geografiche e nelle zone di Google Cloud.

Aree geografiche e zone

I prodotti Google Cloud sono forniti in un numero elevato di aree geografiche e zone. Le aree geografiche sono aree geografiche fisicamente indipendenti che contengono tre o più zone. Le zone rappresentano gruppi di risorse di elaborazione fisica all'interno di una regione che hanno un alto grado di indipendenza l'una dall'altra in termini di infrastruttura fisica e logica. Forniscono connessioni di rete a larghezza di banda elevata e a bassa latenza ad altre zone nella stessa area geografica. Ad esempio, l'area geografica asia-northeast1 in Giappone contiene tre zone: asia-northeast1-a, asia-northeast1-b e asia-northeast1-c.

I prodotti Google Cloud sono divisi in risorse a livello di zona, risorse a livello di area geografica o risorse a livello di più aree geografiche.

Le risorse a livello di area geografica sono ospitate in una singola zona. Un'interruzione del servizio in quella zona può interessare tutte le risorse al suo interno. Ad esempio, un'istanza Compute Engine viene eseguita in una singola zona specificata; se un errore hardware interrompe il servizio in quella zona, tale istanza non è disponibile per la durata dell'interruzione.

Il deployment delle risorse a livello di area geografica viene eseguito in modo ridondante in più zone all'interno di un'area geografica. Questo garantisce un'affidabilità maggiore rispetto alle risorse di zona.

Le risorse a più aree geografiche sono distribuite all'interno e tra le regioni. In generale, le risorse a livello di più aree geografiche hanno una maggiore affidabilità rispetto alle risorse a livello di area geografica. Tuttavia, a questo livello i prodotti devono ottimizzare la disponibilità, le prestazioni e l'efficienza delle risorse. Di conseguenza, è importante comprendere i compromessi apportati da ciascun prodotto in più aree geografiche che decidi di utilizzare. I compromessi sono documentati su base specifica per il prodotto più avanti in questo documento.

Esempi di prodotti Google Cloud a livello di zona, a livello di area geografica e multiregionale

Come sfruttare zone e aree geografiche per ottenere affidabilità

Gli SRE di Google gestiscono e scalano prodotti utente globali altamente affidabili come Gmail e la Ricerca, attraverso una varietà di tecniche e tecnologie che sfruttano perfettamente l'infrastruttura di calcolo in tutto il mondo. Ciò include il reindirizzamento del traffico dalle località non disponibili utilizzando il bilanciamento del carico globale, l'esecuzione di più repliche in molte località del pianeta e la replica dei dati in più località. Queste stesse funzionalità sono disponibili per i clienti di Google Cloud tramite prodotti come Cloud Load Balancing, Google Kubernetes Engine e Cloud Spanner.

In generale, Google Cloud progetta i prodotti per offrire i seguenti livelli di disponibilità per zone e aree geografiche:

Risorsa Esempi Obiettivo di progettazione della disponibilità Tempo di inattività implicito
a zona Compute Engine, disco permanente 99,9% 8,75 ore / anno
A livello di regione Cloud Storage a livello di regione, disco permanente replicato, a livello di regione di Google Kubernetes Engine 99,99% 52 minuti / anno

Confronta gli obiettivi di progettazione della disponibilità di Google Cloud con i livelli di inattività accettabili per identificare le risorse Google Cloud appropriate. Mentre i design tradizionali si concentrano sul miglioramento della disponibilità a livello di componente per migliorare la disponibilità dell'applicazione risultante, i modelli cloud si concentrano invece sulla composizione dei componenti per raggiungere questo obiettivo. Molti prodotti all'interno di Google Cloud utilizzano questa tecnica. Ad esempio, Cloud Spanner offre un database a più aree geografiche che compone più regioni per fornire una disponibilità del 99,999%.

La composizione è importante perché, senza questa funzionalità, la disponibilità della tua applicazione non può superare quella dei prodotti Google Cloud che utilizzi; in effetti, a meno che l'applicazione non abbia mai problemi, la disponibilità sarà inferiore a quella dei prodotti Google Cloud sottostanti. Il resto di questa sezione mostra come utilizzare una composizione dei prodotti a livello di zona e di regione per ottenere una disponibilità dell'applicazione superiore a quella fornita da una singola zona o regione. La prossima sezione fornisce una guida pratica per l'applicazione di questi principi alle tue applicazioni.

Pianificazione degli ambiti di interruzione delle zone

Gli errori dell'infrastruttura causano in genere interruzioni del servizio in una singola zona. All'interno di un'area geografica, le zone sono progettate per ridurre al minimo il rischio di errori correlati con altre zone e l'interruzione di un servizio in una zona di solito non influirà sul servizio di un'altra zona della stessa area geografica. Un'interruzione dell'ambito di una zona non significa necessariamente che l'intera zona non sia disponibile, ma definisce semplicemente il confine dell'incidente. L'interruzione di una zona può non avere effetto tangibile sulle risorse specifiche in quella zona.

Si tratta di un'eventualità più rara, ma è anche importante notare che più zone alla fine otterranno un'interruzione correlata in un determinato momento all'interno di una singola regione. In caso di interruzione di due o più zone, viene applicata la strategia di ambito di interruzione a livello di area geografica riportata di seguito.

Le risorse a livello di area geografica sono progettate per resistere alle interruzioni di zona fornendo il servizio da una composizione di più zone. Se una delle zone che supportano una risorsa a livello di area geografica viene interrotta, la risorsa viene resa automaticamente disponibile da un'altra zona. Per ulteriori dettagli, controlla attentamente la descrizione delle funzionalità del prodotto nell'appendice.

Google Cloud offre solo alcune risorse a livello di zona, ovvero macchine virtuali (VM) Compute Engine e disco permanente. Se prevedi di utilizzare risorse a livello di zona, dovrai eseguire la tua composizione di risorse progettando, creando e testando il failover e il ripristino tra le risorse a livello di zona situate in più zone. Di seguito sono riportate alcune strategie:

  • Instradare rapidamente il traffico a macchine virtuali in un'altra zona utilizzando Cloud Load Balancing quando un controllo di integrità determina che una zona sta riscontrando problemi.
  • Utilizza i modelli di istanza e/o i gruppi di istanze gestite di Compute Engine per eseguire e scalare istanze VM identiche in più zone.
  • Utilizza un disco permanente a livello di regione per replicare in modo sincrono i dati in un'altra zona di un'area geografica. Per ulteriori dettagli, consulta Opzioni di alta disponibilità utilizzando i DP regionali.

Pianificazione degli ambiti di interruzione a livello di regione

Un'interruzione a livello di area geografica è un'interruzione di servizio che interessa più zone in una singola area geografica. Si tratta di interruzioni su scala più grande e meno frequenti e possono essere causate da calamità naturali o guasti dell'infrastruttura su vasta scala.

Per un prodotto regionale progettato per fornire una disponibilità del 99,99%, un'interruzione può comunque tradursi in quasi un'ora di inattività per un determinato prodotto ogni anno. Pertanto, le tue applicazioni critiche potrebbero dover disporre di un piano di ripristino di emergenza su più aree geografiche se questa durata di interruzione è inaccettabile.

Le risorse multiregionali sono progettate per resistere alle interruzioni di servizio della rete in quanto forniscono servizi da più regioni. Come descritto sopra, i prodotti a più aree geografiche sono compromessi in termini di latenza, coerenza e costo. Il compromesso più comune è la replica sincrona e asincrona dei dati. La replica asincrona offre una latenza più bassa a scapito del rischio di perdita di dati durante un'interruzione. Per questo motivo, è importante controllare la descrizione della funzionalità del prodotto nell'appendice.

Se vuoi utilizzare risorse a livello di area geografica e vuoi resistere alle interruzioni di servizio a livello di area geografica, devi eseguire la tua composizione di risorse progettando, creando e verificando il failover e il ripristino tra le risorse a livello di area geografica in più aree geografiche. Oltre alle strategie a livello di zona riportate sopra, che puoi applicare a livello di area geografica, tieni presente che:

  • Le risorse a livello di area geografica devono replicare i dati in un'area geografica secondaria, in un'opzione di archiviazione con più aree geografiche, come Cloud Storage, o in un'opzione per il cloud ibrido come Anthos.
  • Dopo aver attivato una mitigazione delle interruzioni a livello di area geografica, esegui regolarmente dei test. Ci sono poche cose peggiori che pensare di essere resistente a un'interruzione a livello di una singola regione, solo per scoprire che questo non è vero quando si verifica per davvero.

Approccio alla resilienza e alla disponibilità di Google Cloud

Google Cloud supera regolarmente i target di progettazione della disponibilità, ma non dovresti presumere che queste solide prestazioni passate siano la disponibilità minima che puoi progettare. Devi invece selezionare le dipendenze Google Cloud i cui target progettati per gli utenti superano l'affidabilità prevista dell'applicazione, in modo che il tempo di inattività dell'applicazione più il tempo di inattività di Google Cloud fornisca il risultato che stai cercando.

Un sistema ben progettato può rispondere alla domanda: "Cosa succede quando una zona o un'area geografica ha un'interruzione di 1, 5, 10 o 30 minuti?" Questo aspetto deve essere preso in considerazione in diversi livelli, tra cui:

  • Cosa sperimenteranno i miei clienti durante un'interruzione?
  • Come faccio a rilevare un'interruzione?
  • Cosa succede alla mia applicazione durante un'interruzione del servizio?
  • Cosa succede ai miei dati durante un'interruzione?
  • Cosa succede alle altre mie applicazioni a causa di un'interruzione (a causa di dipendenze incrociate)?
  • Cosa devi fare per eseguire il ripristino dopo la risoluzione di un'interruzione? Chi lo fa?
  • A chi devo inviare una notifica in merito a un'interruzione, entro un determinato periodo di tempo?

Guida passo passo per la progettazione del ripristino di emergenza per le applicazioni in Google Cloud

Le sezioni precedenti riguardavano il modo in cui Google crea l'infrastruttura cloud e alcuni approcci per la gestione delle interruzioni a livello di zona e di regione.

Questa sezione ti aiuta a sviluppare un framework per l'applicazione del principio di composizione alle tue applicazioni in base ai risultati di affidabilità desiderati.

Le applicazioni dei clienti in Google Cloud che hanno come target obiettivi di ripristino di emergenza come RTO e RPO devono essere progettate in modo che le operazioni business-critical, soggette a RTO/RPO, abbiano solo dipendenze sui componenti del piano dati responsabili dell'elaborazione continua delle operazioni per il servizio. In altre parole, tali operazioni business-critical dei clienti non devono dipendere dalle operazioni del piano di gestione, che gestiscono lo stato della configurazione ed eseguono il push della configurazione al piano di controllo e al piano dati.

Ad esempio, i clienti Google Cloud che intendono RTO per operazioni aziendali critiche non devono dipendere da un'API di creazione delle VM o dall'aggiornamento di un'autorizzazione IAM.

Passaggio 1: raccogli i requisiti esistenti

Il primo passaggio consiste nel definire i requisiti di disponibilità per le applicazioni. La maggior parte delle aziende ha già alcune linee guida per la progettazione in questo settore, che possono essere sviluppate internamente o derivate da normative o da altri requisiti legali. In genere queste linee guida di progettazione sono codificate in due metriche chiave: Recovery Time Objective (RTO) e Recovery Point Objective (RPO). In termini di business, RTO si traduce come "Quanto tempo dopo un disastro prima che io possa iniziare". RPO significa "Quanti dati posso permettermi di perdere in caso di disastro"."

Una bilancia che mostra l'ora. L'evento è nel mezzo. All'estrema sinistra c'è RPO con le parole " "Questi scritture sono perdute"." A destra c'è RTO con le parole "normale, il servizio riprende."

Storicamente, le aziende hanno definito requisiti RTO e RPO per un'ampia gamma di eventi disastrosi, dai guasti dei componenti ai terremoti. Tutto ciò aveva senso nel mondo on-premise in cui i planner dovevano mappare i requisiti RTO/RPO nell'intero stack hardware e software. Nel cloud, non devi più definire i tuoi requisiti con tale dettaglio perché il provider se ne occupa. Definire invece i requisiti RTO e RPO in termini di ambito di perdita (intera zona o area geografica) senza specificare i motivi sottostanti. Per Google Cloud questo semplifica la raccolta dei requisiti in 3 scenari: un'interruzione del servizio a livello di zona, un'interruzione a livello di area geografica o l'interruzione estremamente improbabile di più aree geografiche.

Ammettendo che non tutte le applicazioni hanno la stessa criticità, la maggior parte dei clienti classifica le applicazioni in livelli di criticità in base ai quali può essere applicato un requisito RTO/RPO specifico. Insieme, RTO/RPO e criticità dell'applicazione semplificano il processo di architettura di una determinata applicazione rispondendo a:

  1. L'applicazione deve essere eseguita in più zone nella stessa area geografica o in più zone in più aree geografiche?
  2. Da quali prodotti Google Cloud può dipendere l'applicazione?

Ecco un esempio dell'output dell'esercizio di raccolta dei requisiti:

RTO e RPO per gravità dell'applicazione per l'organizzazione di esempio Co:

Criticità dell'applicazione % di app App di esempio Interruzione di zona Interruzione di regione
Livello 1

(più importante)

5% In genere applicazioni globali o esterne al cliente, come i pagamenti in tempo reale e le vetrine di e-commerce. RTO Zero

RPO Zero

RTO Zero

RPO Zero

Livello 2 35% In genere sono applicazioni regionali o importanti applicazioni interne come CRM o ERP. 15 minuti RTO

RPO 15 minuti

RTO 1 ora

RPO 1 ora

Livello 3

(meno importante)

Il 60% In genere, le applicazioni di team o dipartimento, ad esempio back office, abbandono delle prenotazioni, viaggi interni, contabilità e RU. RTO 1 ora

RPO 1 ora

RTO 12 ore

RPO 12 ore

Passaggio 2: mappatura delle funzionalità ai prodotti disponibili

Il secondo passaggio consiste nel comprendere le capacità di resilienza dei prodotti Google Cloud che verranno utilizzate dalle tue applicazioni. La maggior parte delle aziende esamina le informazioni pertinenti sul prodotto e poi aggiunge delle linee guida su come modificare le proprie architetture per colmare eventuali lacune tra le capacità dei prodotti e i propri requisiti di resilienza. In questa sezione vengono illustrate alcune aree comuni e i suggerimenti relativi ai limiti di dati e applicazioni in questo spazio.

Come accennato in precedenza, i prodotti abilitati per la ripristino di emergenza di Google soddisfano in generale due tipi di ambiti di interruzione: a livello di area geografica e a livello di zona. Per quanto riguarda l'RD, è necessario pianificare le interruzioni parziali esattamente come per un'interruzione completa. In questo modo, per impostazione predefinita, si avrà una matrice iniziale di livello elevato di prodotti adatti a ogni scenario.

Funzionalità generali dei prodotti Google Cloud
(vedi Appendice per informazioni sulle funzionalità specifiche dei prodotti)

Tutti i prodotti Google Cloud Prodotti di Google Cloud a livello di regione con replica automatica tra zone Prodotti Google Cloud multiregionali o globali con replica automatica tra aree geografiche
Errore di un componente all'interno di una zona. Con copertura* Con copertura Con copertura
Interruzione di zona Non coperto Con copertura Con copertura
Interruzione di regione Non coperto Non coperto Con copertura

* Tutti i prodotti Google Cloud sono resilienti agli errori dei componenti, tranne nei casi specifici riportati nella documentazione dei prodotti. In genere si tratta di scenari in cui il prodotto offre accesso diretto o mappatura statica a componenti hardware specifici, come memoria o dischi a stato solido (SSD).

In che modo l'RPO limita le scelte dei prodotti

Nella maggior parte dei deployment cloud, l'integrità dei dati è l'aspetto più importante dall'architettura da considerare per un servizio. Alcune applicazioni hanno un requisito RPO pari a zero, il che significa che non dovrebbero verificarsi perdite di dati in caso di interruzione. In genere questa operazione richiede la replica sincrona in un'altra zona o area geografica. La replica sincrona presenta compromessi e costi in termini di latenza. Pertanto, sebbene molti prodotti Google Cloud forniscano la replica sincrona tra le zone, solo alcuni la forniscono in più aree geografiche. Questo compromesso tra costi e complessità significa che non è insolito che diversi tipi di dati all'interno di un'applicazione abbiano valori RPO diversi.

Per i dati con un RPO maggiore di zero, le applicazioni possono sfruttare la replica asincrona. La replica asincrona è accettabile quando i dati persi possono essere ricreati facilmente o recuperati da un'origine dati dorata, se necessario. Può essere una scelta ragionevole anche quando una piccola perdita di dati rappresenta un compromesso accettabile nel contesto delle durate di interruzione previste a livello di zona e di area geografica. È inoltre importante che, durante un'interruzione temporanea, i dati scritti nella località interessata, ma non ancora replicati in un'altra località diventino generalmente disponibili dopo la risoluzione dell'interruzione. Ciò significa che il rischio di perdita di dati permanente è inferiore al rischio di perdere l'accesso ai dati durante un'interruzione.

Azioni chiave: stabilisci se hai davvero bisogno di RPO zero e, in tal caso, se puoi farlo per un sottoinsieme di dati, aumentando così notevolmente la gamma di servizi abilitati per il ripristino di emergenza. In Google Cloud, raggiungere RPO zero significa utilizzare prodotti prevalentemente a livello regionale per la tua applicazione, che per impostazione predefinita sono resilienti alle interruzioni su scala locale, ma non a livello di area geografica.

In che modo l'RTO limita le scelte dei prodotti

Uno dei principali vantaggi del cloud computing è la capacità di eseguire il deployment dell'infrastruttura on demand, che però non è uguale al deployment istantaneo. Il valore RTO della tua applicazione deve adattarsi all'RTO combinato dei prodotti Google Cloud utilizzati dall'applicazione ed eventuali azioni che devono essere eseguite dai tuoi tecnici o dagli SRE per riavviare le VM o i componenti delle applicazioni. Un RTO misurato in minuti richiede la progettazione di un'applicazione che si recupera automaticamente da un'emergenza senza intervento umano o con passaggi minimi come il push di un pulsante per il failover. I costi e la complessità di questo tipo di sistemi storicamente sono stati molto alti, ma i prodotti Google Cloud come i bilanciatori del carico e i gruppi di istanze rendono questo design molto più accessibile e semplice. Pertanto, devi considerare il failover e il ripristino automatici per la maggior parte delle applicazioni. Tieni presente che progettare un sistema per questo tipo di failover hot in tutte le aree geografiche è sia complicato sia costoso; solo una minima parte dei servizi critici garantisce questa capacità.

La maggior parte delle applicazioni avrà un RTO compreso tra un'ora e un giorno, che consente un failover sicuro in uno scenario di emergenza, con alcuni componenti dell'applicazione in esecuzione sempre in modalità standby, come i database, mentre altri vengono scalati in caso di disastro reale, come i server web. Per queste applicazioni, ti consigliamo di prendere in considerazione l'automazione per gli eventi di scale out. I servizi con un RTO nell'arco di una giornata hanno la criticità più bassa e spesso possono essere recuperati da un backup o ricreati da zero.

Azioni chiave: stabilisci se hai sicuramente bisogno di un RTO (quasi) zero per il failover regionale e, in tal caso, se puoi farlo per un sottoinsieme dei tuoi servizi. Questo comporta il costo di esecuzione e manutenzione del servizio.

Passaggio 3: sviluppa architetture di riferimento e guide personalizzate

Il passaggio finale consigliato consiste nella creazione di pattern di architettura specifici per l'azienda per aiutare i tuoi team a standardizzare il loro approccio al ripristino di emergenza. La maggior parte dei clienti di Google Cloud crea una guida per i propri team di sviluppo che abbina le loro aspettative individuali di resilienza aziendale alle due principali categorie di scenari di interruzione su Google Cloud. Questo consente ai team di classificare facilmente quali prodotti abilitati per RE sono adatti a ogni livello di criticità.

Creare le linee guida del prodotto

Guardando nuovamente la tabella RTO/RPO di esempio riportata sopra, hai una guida ipotetica che elenca i prodotti consentiti per impostazione predefinita per ogni livello di criticità. Tieni presente che, se alcuni prodotti sono stati identificati come non adatti per impostazione predefinita, puoi sempre aggiungere meccanismi di replica e failover per abilitare la sincronizzazione tra zone o aree geografiche, ma questo esercizio non rientra nell'ambito di questo articolo. Le tabelle rimandano anche a ulteriori informazioni su ogni prodotto per aiutarti a comprendere le loro capacità in merito alla gestione delle interruzioni di zona o regione.

Esempi di pattern dell'architettura per un esempio di organizzazione Co - Interruzione dell'interruzione di zona Resilienza

Prodotto Google Cloud Il prodotto soddisfa i requisiti di interruzione della zona per Organizzazione di esempio (con configurazione del prodotto appropriata)
Livello 1 Livello 2 Livello 3
Compute Engine No No No
Dataflow No No No
BigQuery No No
Google Kubernetes Engine
Cloud Storage
Cloud SQL No
Cloud Spanner
Cloud Load Balancing

Questa tabella è un esempio basato solo su livelli ipotetici mostrati sopra.

Esempi di pattern architetturali per un esempio di organizzazione Co - Interruzione dell'area geografica Resilienza

Prodotto Google Cloud Il prodotto soddisfa i requisiti di interruzione della regione per l'organizzazione di esempio (con configurazione del prodotto appropriata)
Livello 1 Livello 2 Livello 3
Compute Engine
Dataflow No No No
BigQuery No No
Google Kubernetes Engine
Cloud Storage No No No
Cloud SQL
Cloud Spanner
Cloud Load Balancing

Questa tabella è un esempio basato solo su livelli ipotetici mostrati sopra.

Per mostrare come potrebbero essere utilizzati questi prodotti, le seguenti sezioni descrivono alcune architetture di riferimento per ciascuno dei ipotetici livelli di criticità dell'applicazione. Queste sono descrizioni volutamente generiche per illustrare le decisioni chiave dell'architettura e non sono rappresentative di un progetto di soluzione completo.

Esempio di architettura di livello 3

Criticità dell'applicazione Interruzione di zona Interruzione di regione
Livello 3
(meno importante)
RTO 12 ore
RPO 24 ore
RTO 28 giorni
RPO 24 ore

Un'architettura di livello 3 di esempio che utilizza i prodotti Google Cloud

Le icone grigie indicano che l'infrastruttura è abilitata per il ripristino.

Questa architettura descrive un'applicazione client/server tradizionale: gli utenti interni si connettono a un'applicazione in esecuzione su un'istanza di computing supportata da un database per l'archiviazione permanente.

È importante notare che questa architettura supporta valori RTO e RPO migliori del necessario. Tuttavia, dovresti anche prendere in considerazione l'eliminazione di ulteriori passaggi manuali che potrebbero rivelarsi costosi o inaffidabili. Ad esempio, il recupero di un database da un backup notturno potrebbe supportare l'RPO delle 24 ore, ma in genere è necessario un singolo esperto come un amministratore del database che potrebbe non essere disponibile, soprattutto se sono stati interessati più servizi contemporaneamente. Grazie all'infrastruttura on demand di Google Cloud, puoi creare questa capacità senza subire un grave compromesso in termini di costi. Di conseguenza, questa architettura utilizza l'alta disponibilità di Cloud SQL anziché un backup/ripristino manuale per le interruzioni a livello di zona.

Decisioni chiave sull'architettura per l'interruzione della zona - RTO di 12 ore e RPO di 24 ore:

  • Un bilanciatore del carico interno viene utilizzato per fornire un punto di accesso scalabile agli utenti, consentendo il failover automatico in un'altra zona. Anche se l'RTO è 12 ore, le modifiche manuali agli indirizzi IP o anche agli aggiornamenti DNS possono richiedere più tempo del previsto.
  • Un gruppo di istanze gestite a livello di area geografica è configurato con più zone ma risorse minime. Ottimizza per i costi, ma consente comunque di scalare rapidamente le macchine virtuali nella zona di backup.
  • Una configurazione Cloud SQL ad alta disponibilità fornisce il failover automatico in un'altra zona. Rispetto alle macchine virtuali Compute Engine, la creazione e il ripristino dei database sono molto più complessi.

Decisioni chiave sull'architettura per l'interruzione dell'area geografica - RTO di 28 giorni e RPO di 24 ore:

  • Un bilanciatore del carico viene creato nella regione 2 solo in caso di interruzione del servizio a livello di regione. Cloud DNS viene utilizzato per fornire una funzionalità di failover regionale, ma orchestrata, poiché l'infrastruttura nella regione 2 verrebbe resa disponibile solo in caso di interruzione della regione.
  • Un nuovo gruppo di istanze gestite viene creato solo in caso di interruzione di un'area geografica. Ottimizza per i costi ed è improbabile che venga richiamato a causa della breve durata della maggior parte delle interruzioni a livello di area geografica. Tieni presente che, per semplicità, il diagramma non mostra gli strumenti associati necessari per eseguire nuovamente il deployment o la copia delle immagini Compute Engine necessarie.
  • Verrà ricreata una nuova istanza Cloud SQL e i dati verranno ripristinati da un backup. Anche in questo caso, il rischio di un'interruzione estesa per un'area geografica è estremamente basso, quindi si tratta di un altro compromesso sull'ottimizzazione dei costi.
  • Il servizio Cloud Storage su più aree geografiche viene utilizzato per archiviare i backup. Ciò fornisce la resilienza automatica a livello di zona e area RTO e RPO.

Esempio di architettura di livello 2

Criticità dell'applicazione Interruzione di zona Interruzione di regione
Livello 2 4 ore RTO
RPO zero
RTO 24 ore
RPO 4 ore

Un'architettura di livello 2 di esempio che utilizza i prodotti Google Cloud

Questa architettura descrive un data warehouse con utenti interni collegati a un livello di visualizzazione istanza Compute, e un livello di importazione e trasformazione dei dati che completa il data warehouse di backend.

Alcuni singoli componenti di questa architettura non supportano direttamente l'RPO richiesto per il loro livello; tuttavia, a causa del modo in cui vengono utilizzati insieme, il servizio generale soddisfa l'RPO. In questo caso, poiché Dataflow è un prodotto a livello di zona, è necessario seguire i suggerimenti per la progettazione ad alta disponibilità per evitare perdite di dati durante un'interruzione a livello di zona. Tuttavia, il livello Cloud Storage è l'origine d'oro di questi dati e supporta un RPO pari a zero. Ciò significa che i dati persi possono essere reinseriti in BigQuery tramite la zona b in caso di interruzione nella zona a.

Decisioni chiave sull'architettura per l'interruzione delle zone - RTO pari a 4 ore e RPO pari a zero:

  • Un bilanciatore del carico viene utilizzato per fornire un punto di accesso scalabile agli utenti, consentendo il failover automatico in un'altra zona. Anche se l'RTO è quattro ore, le modifiche manuali agli indirizzi IP o anche gli aggiornamenti DNS possono richiedere più tempo del previsto.
  • Un gruppo di istanze gestite a livello di area geografica per il livello di calcolo della visualizzazione dati è configurato con più zone ma risorse minime. Ottimizza per i costi, ma consente comunque di scalare rapidamente le macchine virtuali.
  • Cloud Storage a livello di regione viene utilizzato come livello di gestione temporanea per l'importazione iniziale dei dati, che fornisce resilienza automatica delle zone.
  • Dataflow viene utilizzato per estrarre dati da Cloud Storage e trasformarli prima di caricarli in BigQuery. In caso di interruzione di una zona, questo è un processo stateless che può essere riavviato in un'altra zona.
  • BigQuery fornisce il backend di data warehouse per il front-end di visualizzazione dei dati. In caso di interruzione di una zona, qualsiasi dato perso verrà importato di nuovo da Cloud Storage.

Decisioni chiave sull'architettura per l'interruzione dell'area geografica - RTO di 24 ore e RPO di 4 ore:

  • Un bilanciatore del carico in ogni area geografica viene utilizzato per fornire un punto di accesso scalabile agli utenti. Cloud DNS viene utilizzato per fornire una funzionalità di failover a livello di area geografica orchestrata ma manuale, poiché l'infrastruttura nella regione 2 sarà resa disponibile solo in caso di interruzione del servizio.
  • Un gruppo di istanze gestite a livello di area geografica per il livello di calcolo della visualizzazione dati è configurato con più zone ma risorse minime. Questo accesso non è accessibile finché il bilanciatore del carico non è riconfigurato, ma non richiede un intervento manuale.
  • Cloud Storage a livello di area geografica viene utilizzato come livello temporaneo per l'importazione iniziale dei dati. Questo viene caricato contemporaneamente in entrambe le regioni per soddisfare i requisiti RPO.
  • Dataflow viene utilizzato per estrarre dati da Cloud Storage e trasformarli prima di caricarli in BigQuery. In caso di interruzione di una regione, questo completerà BigQuery con i dati più recenti di Cloud Storage.
  • BigQuery fornisce il backend di data warehouse. Questo valore viene aggiornato a intermittenza nelle normali operazioni. In caso di interruzione del servizio in una regione, i dati più recenti vengono importati nuovamente con Dataflow tramite Cloud Storage.

Esempio di architettura di livello 1

Criticità dell'applicazione Interruzione di zona Interruzione di regione
Livello 1
(più importante)
zero RTO
RPO zero
RTO 4 ore
RPO 1 ora

Un'architettura di livello 1 di esempio che utilizza i prodotti Google Cloud

Questa architettura descrive un'infrastruttura di backend per app per dispositivi mobili con utenti esterni che si connettono a un set di microservizi in esecuzione in Google Kubernetes Engine. Cloud Spanner offre il livello di archiviazione dati di backend per i dati in tempo reale e i dati storici vengono trasmessi in flussi a un data lake BigQuery in ogni area geografica.

Anche in questo caso, alcuni singoli componenti di questa architettura non supportano direttamente l'RPO richiesto per il loro livello, ma a causa di come vengono utilizzati insieme il servizio generale. In questo caso BigQuery viene utilizzato per le query analitiche. Ogni area geografica viene fornita contemporaneamente da Cloud Spanner.

Decisioni chiave sull'architettura per l'interruzione di una zona - RTO pari a zero e RPO pari a zero:

  • Un bilanciatore del carico viene utilizzato per fornire un punto di accesso scalabile agli utenti, consentendo il failover automatico in un'altra zona.
  • Un cluster Google Kubernetes Engine a livello di area geografica viene utilizzato per il livello di applicazione configurato con più zone. In questo modo l'RTO è pari a zero in ogni area geografica.
  • Cloud Spanner in più aree geografiche viene utilizzato come livello di persistenza dei dati, fornendo coerenza automatica dei dati della zona e coerenza delle transazioni.
  • BigQuery offre la capacità di analisi per l'applicazione. Ogni area geografica riceve dati in modo indipendente da Cloud Spanner ed è accessibile in modo indipendente dall'applicazione.

Decisioni chiave sull'architettura per l'interruzione dell'area geografica - RTO di 4 ore e RPO di 1 ora:

  • Un bilanciatore del carico viene utilizzato per fornire un punto di accesso scalabile agli utenti, consentendo il failover automatico in un'altra area geografica.
  • Un cluster Google Kubernetes Engine a livello di area geografica viene utilizzato per il livello di applicazione configurato con più zone. In caso di interruzione del servizio in un'area geografica, il cluster nell'area geografica alternativa scala automaticamente per gestire il carico di elaborazione aggiuntivo.
  • Cloud Spanner su più aree geografiche viene utilizzato come livello di persistenza dei dati, fornendo coerenza automatica dei dati a livello di area geografica e coerenza delle transazioni. Questa è la componente chiave per ottenere l'RPO tra aree geografiche di 1 ora.
  • BigQuery offre la capacità di analisi per l'applicazione. Ogni area geografica riceve dati in modo indipendente da Cloud Spanner ed è accessibile in modo indipendente dall'applicazione. Questa architettura compensa il componente BigQuery in modo che possa soddisfare i requisiti generali dell'applicazione.

Appendice: Riferimento prodotto

Questa sezione descrive l'architettura e le funzionalità di ripristino di emergenza dei prodotti Google Cloud più comunemente utilizzate nelle applicazioni dei clienti e che possono essere facilmente sfruttate per soddisfare i requisiti di RE.

Temi comuni

Molti prodotti Google Cloud offrono configurazioni a livello di una o più aree geografiche. I prodotti regionali sono resilienti alle interruzioni di zona, mentre i prodotti a livello di più aree geografiche e globali sono resilienti alle interruzioni di aree geografiche. In generale, ciò significa che durante un'interruzione i problemi dell'applicazione sono minimi. Google ottiene questi risultati attraverso alcuni approcci architetturali comuni, che rispecchiano le linee guida architettoniche sopra riportate.

  • Deployment ridondante. I backend dell'applicazione e l'archiviazione dei dati vengono distribuiti in più zone all'interno di una e in più aree geografiche all'interno di una località a più aree geografiche.
  • Replica dei dati: i prodotti utilizzano la replica sincrona o asincrona nelle località ridondanti.

    • La replica sincrona significa che, quando l'applicazione effettua una chiamata API per creare o modificare i dati archiviati dal prodotto, riceve una risposta riuscita solo dopo che il prodotto ha scritto i dati in più località. La replica sincrona garantisce che tu non perda l'accesso a nessuno dei dati durante un'interruzione dell'infrastruttura Google Cloud perché tutti i dati sono disponibili in una delle località di backend disponibili.

      Sebbene questa tecnica offra la massima protezione dei dati, può avere dei compromessi in termini di latenza e prestazioni. Prodotti a più aree geografiche che utilizzano l'esperienza di replica sincrona in modo significativo, in genere nell'ordine di 10 o 100 millisecondi di ulteriore latenza.

    • La replica asincrona significa che, quando l'applicazione effettua una chiamata API per creare o modificare i dati archiviati dal prodotto, riceve una risposta riuscita dopo che il prodotto ha scritto i dati in una singola località. In seguito alla tua richiesta di scrittura, il prodotto replica i tuoi dati in ulteriori posizioni.

      Questa tecnica offre una latenza più bassa e una velocità effettiva superiore a livello di API rispetto alla replica sincrona, ma a discapito della protezione dei dati. Se la località in cui hai scritto i dati subisce un'interruzione prima che la replica sia completata, perderai l'accesso a questi dati fino a quando l'interruzione non viene risolta.

  • Gestione delle interruzioni con il bilanciamento del carico: Google Cloud utilizza il bilanciamento del carico del software per instradare le richieste ai backend delle applicazioni appropriati. Rispetto ad altri approcci come il bilanciamento del carico DNS, questo approccio riduce i tempi di risposta del sistema a un'interruzione. Quando si verifica un'interruzione della posizione di Google Cloud, il bilanciatore del carico rileva rapidamente che il backend di cui è stato eseguito il deployment in quella località è diventato "non integro" e indirizza tutte le richieste a un backend in una località alternativa. Ciò consente al prodotto di continuare a gestire le richieste della tua applicazione durante un'interruzione della posizione. Una volta risolta l'interruzione della posizione, il bilanciatore del carico rileva la disponibilità dei backend di prodotto in quella località e riprende a inviare il traffico lì.

Compute Engine

Compute Engine è la soluzione Infrastructure as a Service di Google Cloud. Utilizza l'infrastruttura su scala mondiale di Google per offrire macchine virtuali (e servizi correlati) ai clienti.

Le istanze di Compute Engine sono risorse a livello di zona, quindi nel caso di un'interruzione della zona non sono disponibili per impostazione predefinita. Compute Engine offre gruppi di istanze gestite (MIG) in grado di fare automaticamente lo scale up di VM aggiuntive da modelli di istanze preconfigurati, sia all'interno di una singola zona che su più zone all'interno di una regione. I gruppi di istanze gestite sono ideali per le applicazioni che richiedono resilienza alla perdita di zona e sono stateless, ma che richiedono configurazione e pianificazione delle risorse. È possibile utilizzare più gruppi di istanze geografiche a livello di area geografica per ottenere la resilienza alle interruzioni di area geografica per le applicazioni stateless.

Le applicazioni con carichi di lavoro stateful possono comunque utilizzare MIG stateful, ma è necessario prestare particolare attenzione nella pianificazione della capacità poiché non scalano in orizzontale. È importante in entrambi gli scenari configurare e testare correttamente i modelli di istanza Compute Engine e i gruppi di istanze gestite in anticipo per garantire il funzionamento delle funzionalità di failover ad altre zone. Consulta la sezione Modelli di architettura in alto per ulteriori informazioni.

Networking per Compute Engine

Per informazioni sulle configurazioni ad alta disponibilità per le connessioni Interconnect, consulta i seguenti documenti:

Puoi eseguire il provisioning di indirizzi IP esterni in modalità globale o a livello di area geografica, il che influisce sulla loro disponibilità in caso di errore di una regione.

Resilienza Cloud Load Balancing

I bilanciatori del carico sono un componente critico della maggior parte delle applicazioni a disponibilità elevata. Google Cloud offre bilanciatori del carico a livello di area geografica e globale. In entrambi i casi, è importante comprendere che la resilienza della tua applicazione complessiva dipende non solo dal bilanciatore del carico che scegli, ma anche dalla ridondanza dei servizi di backend.

La tabella seguente riassume la resilienza del bilanciatore del carico in base alla distribuzione o all'ambito del bilanciatore del carico.

Ambito del bilanciatore del carico Architettura Resiliente all'interruzione locale Resilienti all'interruzione a livello di regione
Globale Ogni bilanciatore del carico è distribuito in tutte le regioni
A livello di regione Ogni bilanciatore del carico è distribuito in più zone dell'area geografica Un'interruzione in una determinata regione influisce sui bilanciatori del carico a livello di regione in quella regione

Per ulteriori informazioni sulla scelta di un bilanciatore del carico, consulta la documentazione di Cloud Load Balancing.

Dataproc

Dataproc offre funzionalità di elaborazione dei dati in modalità flusso e batch. Dataproc è progettato come piano di controllo a livello di area geografica che consente agli utenti di gestire i cluster Dataproc. Il piano di controllo non dipende da una singola zona in una determinata area geografica. Pertanto, durante un'interruzione a livello di zona, mantieni l'accesso alle API Dataproc, inclusa la possibilità di creare nuovi cluster.

I cluster vengono eseguiti in Compute Engine. Poiché il cluster è una risorsa di zona, un'interruzione della zona rende il cluster non disponibile o distrugge il cluster. Dataproc non esegue lo snapshot automatico dello stato del cluster, quindi un'interruzione della zona potrebbe causare la perdita di dati in elaborazione. Dataproc non persiste per i dati utente all'interno del servizio. Gli utenti possono configurare le proprie pipeline per scrivere i risultati in molti datastore; dovresti considerare l'architettura del datastore e scegliere un prodotto che offra la resilienza necessaria in caso di emergenza.

Se una zona subisce un'interruzione, puoi scegliere di ricreare una nuova istanza del cluster in un'altra zona, selezionando una zona diversa o utilizzando la funzionalità di posizionamento automatico in Dataproc per selezionare automaticamente una zona disponibile. Quando il cluster è disponibile, il trattamento dati può riprendere. Puoi inoltre eseguire un cluster con la modalità alta disponibilità abilitata, riducendo la probabilità che un'interruzione parziale della zona influirà su un nodo master e, di conseguenza, sull'intero cluster.

Dataflow

Dataflow è il servizio di trattamento dati serverless e completamente gestito di Google Cloud per pipeline in modalità flusso e batch. I job Dataflow sono di zona e in configurazione predefinita non conservano i risultati di calcolo intermedio quando si verifica un'interruzione del servizio a livello di zona. Un approccio di ripristino tipico per queste pipeline Dataflow è in fase di riavvio di un job in una zona o un'area geografica diversa e la rielaborazione dei dati di input.

Progettazione di pipeline Dataflow per l'alta disponibilità

In caso di interruzione di una zona o di una regione, puoi evitare la perdita di dati riutilizzando la stessa sottoscrizione all'argomento Pub/Sub. Come parte della garanzia unica di Dataflow, Dataflow raccoglie i messaggi in Pub/Sub solo se erano persistenti nella destinazione o se un messaggio ha eseguito un'operazione di raggruppamento/time-windowing ed è stato salvato nella pipeline durevole di Dataflow. Se non sono presenti operazioni di raggruppamento/timeout, un failover a un altro job Dataflow in un'altra zona o regione riutilizzando l'abbonamento non comporta alcuna perdita di dati nei dati di output della pipeline.

Se la pipeline utilizza il raggruppamento o il periodo di tempo, puoi utilizzare la funzionalità Ricerca di Pub/Sub o Replay di Kafka dopo un'interruzione a livello di zona o di regione per rielaborare gli elementi di dati in modo da ottenere gli stessi risultati di calcolo. La perdita di dati degli output della pipeline può essere ridotta al minimo fino a 0 elementi, se la logica di business utilizzata dalla pipeline non fa affidamento sui dati prima dell'interruzione. Se la logica di business della pipeline si basa su dati elaborati prima dell'interruzione (ad esempio se vengono utilizzate finestre scorrevoli lunghe o se una finestra temporale globale memorizza contatori in continua crescita), Dataflow offre una funzionalità di snapshot (attualmente in anteprima) che fornisce un backup degli snapshot di uno stato della pipeline.

BigQuery

BigQuery è un data warehouse su cloud serverless, a scalabilità elevata e dai costi contenuti, progettato per l'agilità aziendale. BigQuery supporta i seguenti tipi di località per i set di dati utente:

  • Una regione: una posizione geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
  • Una multiregione: un'area geografica di grandi dimensioni che contiene due o più luoghi geografici, ad esempio gli Stati Uniti (US) o l'Europa (EU).

In entrambi i casi, i dati vengono archiviati in modo ridondante in due zone all'interno della località selezionata. I dati scritti in BigQuery sono scritti nelle zone primarie e secondarie. Questo impedisce l'indisponibilità di una singola zona all'interno di una o più aree geografiche.

Google Kubernetes Engine

Google Kubernetes Engine (GKE) offre un servizio Kubernetes gestito semplificando il deployment delle applicazioni containerizzate su Google Cloud. Puoi scegliere tra topologie cluster a livello di area geografica o di zona.

  • Quando crea un cluster di zona, GKE esegue il provisioning di una macchina del piano di controllo nella zona scelta, nonché delle macchine worker (nodi) all'interno della stessa zona.
  • Per i cluster a livello di area geografica, GKE esegue il provisioning di tre macchine a piano di controllo in tre diverse zone all'interno dell'area geografica scelta. Per impostazione predefinita, i nodi sono distribuiti in tre zone, anche se puoi scegliere di creare un cluster a livello di area geografica con nodi di cui è stato eseguito il provisioning in una sola zona.
  • I cluster multi-zona sono simili ai cluster di zona poiché includono una macchina master, ma offrono anche la possibilità di estendere i nodi su più zone.

Interruzione regionale: per evitare interruzioni a livello di zona, utilizza i cluster a livello di area geografica. Il piano di controllo e i nodi sono distribuiti in tre diverse zone all'interno di un'area geografica. L'interruzione di una zona non influisce sul piano di controllo e sui nodi worker di cui è stato eseguito il deployment nelle altre due zone.

Interruzione a livello di area geografica: la mitigazione di un'interruzione a livello di area geografica richiede il deployment in più aree geografiche. Sebbene non sia al momento offerto come funzionalità di prodotto integrata, la topologia a più aree geografiche è un approccio utilizzato oggi da diversi clienti GKE e può essere implementata manualmente. Puoi creare più cluster a livello di area geografica per replicare i carichi di lavoro su più aree geografiche e controllare il traffico verso questi cluster utilizzando il traffico in entrata multi-cluster.

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) offre una gestione delle risorse delle chiavi di crittografia scalabile e a elevata durabilità. Cloud KMS archivia tutti i suoi dati e metadati in database Cloud Spanner che offrono alta durabilità e disponibilità dei dati con replica sincrona.

Le risorse Cloud KMS possono essere create in un'unica area geografica, in più aree geografiche o a livello globale.

In caso di interruzione del servizio a livello di zona, Cloud KMS continua a gestire le richieste da un'altra zona nella stessa area geografica o in aree geografiche diverse senza interruzioni. Poiché i dati vengono replicati in modo sincrono, non si verifica alcuna perdita o danneggiamento dei dati. Una volta risolta l'interruzione della zona, verrà ripristinata la ridondanza completa.

In caso di interruzione del servizio a livello di area geografica, le risorse a livello di area geografica nell'area geografica sono offline finché l'area geografica non sarà tornata disponibile. Tieni presente che, anche all'interno di un'area geografica, almeno tre repliche vengono mantenute in zone distinte. Quando è richiesta una disponibilità più elevata, le risorse devono essere archiviate in una configurazione a livello di più aree geografiche o globali. Le configurazioni a livello di più aree geografiche e globali sono progettate per rimanere disponibili attraverso un'interruzione a livello di area geografica archiviando e gestendo i dati in modo geo-ridondante in più aree geografiche.

Cloud Identity

I servizi Cloud Identity sono distribuiti in più aree geografiche e utilizzano il bilanciamento del carico dinamico. Cloud Identity non consente agli utenti di selezionare un ambito di risorse. Se si verifica un'interruzione di una determinata zona o regione, il traffico viene distribuito automaticamente ad altre zone o regioni.

Nella maggior parte dei casi, i dati permanenti vengono sottoposti a mirroring in più aree geografiche con replica sincrona. Per migliorare le prestazioni, alcuni sistemi, ad esempio cache o modifiche che interessano un numero elevato di entità, vengono replicati in modo asincrono tra le regioni. Se si verifica un'interruzione dell'area geografica principale in cui sono archiviati i dati più aggiornati, Cloud Identity pubblica dati non aggiornati da un'altra località fino a quando l'area geografica principale non diventa disponibile.

Persistent Disk

I dischi permanenti sono disponibili nelle configurazioni a livello di zona e di area geografica.

I dischi permanenti a livello di zona sono ospitati in una singola zona. Se la zona del disco non è disponibile, il disco permanente non sarà disponibile finché non verrà risolta l'interruzione della zona.

I dischi permanenti a livello di area geografica offrono la replica sincrona dei dati tra due zone all'interno di un'area geografica. In caso di interruzione nella zona della tua macchina virtuale, puoi forzare l'associazione di un disco permanente a una regione di un'istanza VM nella zona secondaria del disco. Per eseguire questa attività, devi avviare un'altra istanza VM in quella zona o mantenere un'istanza VM di hot standby in quella zona.

Cloud Storage

Cloud Storage fornisce uno spazio di archiviazione di oggetti unificato a livello globale, scalabile e a elevata durabilità. I bucket Cloud Storage possono essere creati in un'unica area geografica, due aree geografiche o più aree geografiche all'interno di un continente.

Se si verifica un'interruzione di una zona, i dati nella zona non disponibile vengono gestiti automaticamente e in modo trasparente da altre zone della regione. I dati e i metadati vengono archiviati in modo ridondante in tutte le zone, a partire dalla scrittura iniziale. Nessuna scrittura andrà persa quando una zona non sarà più disponibile.

In caso di interruzione a livello di area geografica, i bucket a livello di area geografica nell'area geografica sono offline finché l'area geografica non sarà tornata disponibile.

Quando è richiesta una disponibilità più elevata, considera l'archiviazione dei dati in una configurazione a doppia area geografica o a più aree geografiche. Cloud Storage utilizza Cloud Load Balancing per gestire bucket a doppia area geografica e a più aree geografiche da diverse aree geografiche. In caso di interruzione del servizio a livello di area geografica, la pubblicazione non viene interrotta.

Le configurazioni a doppia area geografica e a più aree geografiche di Cloud Storage replicano i dati scritti in modo sincrono in un'altra zona all'interno della stessa area geografica e in modo asincrono in un'altra area geografica o aree geografiche. Per saperne di più, consulta Località dei bucket nella documentazione di Cloud Storage.

Durante un'interruzione a livello di area geografica, i dati scritti di recente nell'area geografica interessata potrebbero non essere stati replicati in altre aree geografiche. Di conseguenza, questi dati potrebbero non essere accessibili durante l'interruzione e potrebbero andare persi in caso di distruzione fisica dei dati nell'area geografica interessata.

Container Registry

Container Registry fornisce un'implementazione scalabile di Docker Registry che archivia in modo sicuro e privato le immagini Docker. Container Registry implementa l'API HTTP Docker Registry.

Container Registry è un servizio globale che archivia in modo sincrono i metadati delle immagini in modo ridondante in più zone e aree geografiche per impostazione predefinita. Le immagini container vengono archiviate in bucket a più aree geografiche di Cloud Storage. Con questa strategia di archiviazione, Container Registry fornisce resilienza delle interruzioni di zona a livello di area geografica e resilienza di interruzione a livello di area geografica per tutti i dati che sono stati replicati in modo asincrono in più aree geografiche da Cloud Storage.

Pub/Sub

Pub/Sub è un servizio di messaggistica per l'integrazione di applicazioni e l'analisi dei flussi. Gli argomenti Pub/Sub sono globali, ovvero sono visibili e accessibili da qualsiasi località di Google Cloud. Tuttavia, un determinato messaggio viene archiviato in un'unica area geografica Google Cloud, il più vicino al publisher e consentito dal criterio di località delle risorse. Pertanto, un argomento potrebbe contenere messaggi archiviati in regioni diverse di Google Cloud. Il criterio di archiviazione dei messaggi Pub/Sub può limitare le regioni in cui sono archiviati i messaggi.

Interruzione di zona: quando un messaggio Pub/Sub viene pubblicato, viene scritto in modo sincrono per l'archiviazione in almeno due zone all'interno dell'area geografica. Pertanto, se una singola zona non è più disponibile, non vi sarà alcun impatto visibile al cliente.

Interruzione di una regione: durante un'interruzione del servizio in una regione, i messaggi archiviati al suo interno non sono accessibili. Le operazioni amministrative, come la creazione e l'eliminazione di argomenti e sottoscrizioni, sono multiregionali e resilienti a un'interruzione di qualsiasi singola regione Google Cloud. Le operazioni di pubblicazione sono anche resilienti alle interruzioni di servizio nella regione, a condizione che:

  • almeno una regione consentita dal criterio di archiviazione dei messaggi è disponibile (per impostazione predefinita Pub/Sub non limita la posizione di archiviazione dei messaggi) e
  • la tua applicazione utilizza l'endpoint globale (pubsub.googleapis.com) o più endpoint a livello di regione
  • Il client di pubblicazione non si trova nella regione interessata.

Se la tua applicazione si basa sull'ordinamento dei messaggi, consulta i consigli dettagliati del team Pub/Sub. Le garanzie di ordinamento dei messaggi sono fornite su base area geografica e possono interrompersi se si utilizza un endpoint globale.

Cloud Composer

Cloud Composer è l'implementazione di Apache Airflow di Google Cloud. Cloud Composer è progettato come un piano di controllo a livello di area geografica che consente agli utenti di gestire i cluster Cloud Composer. Il piano di controllo non dipende da una singola zona in una determinata area geografica. Pertanto, durante un'interruzione a livello di zona, mantieni l'accesso alle API Cloud Composer, inclusa la possibilità di creare nuovi cluster.

I cluster vengono eseguiti in Google Kubernetes Engine. Poiché il cluster è una risorsa di zona, un'interruzione di zona rende il cluster non disponibile o distrugge il cluster. I flussi di lavoro attualmente in esecuzione al momento dell'interruzione potrebbero essere interrotti prima del completamento. Ciò significa che l'interruzione causa la perdita dello stato dei flussi di lavoro parzialmente eseguiti, incluse eventuali azioni esterne che il flusso di lavoro è stato configurato dall'utente. A seconda del flusso di lavoro, questo potrebbe causare incoerenze all'esterno, ad esempio se il flusso di lavoro si interrompe nel bel mezzo di un'esecuzione in più passaggi per modificare i datastore esterni. Pertanto, dovresti prendere in considerazione il processo di ripristino quando progetti il flusso di lavoro di Airflow, incluso come rilevare gli stati del flusso di lavoro parzialmente non eseguiti, riparare le modifiche di dati parziali e così via.

Durante l'interruzione di una zona, puoi scegliere di utilizzare Cloud Composer per avviare una nuova istanza del cluster in un'altra zona. Quando il cluster è disponibile, il flusso di lavoro può riprendere. A seconda delle tue preferenze, potresti voler eseguire un cluster di replica inattivo in un'altra zona e passare a tale replica in caso di interruzione della zona.

Cloud SQL

Cloud SQL è un servizio di database relazionale completamente gestito per MySQL, PostgreSQL e SQL Server. Cloud SQL utilizza macchine virtuali Compute Engine gestite per eseguire il software del database. Offre una configurazione ad alta disponibilità per la ridondanza a livello di regione, proteggendo il database da un'interruzione della zona. È possibile eseguire il provisioning delle repliche tra regioni per proteggere il database da un'interruzione del servizio in una regione. Poiché il prodotto offre anche un'opzione a livello di zona, che non è resiliente alle interruzioni di una zona o di una regione, devi prestare attenzione a selezionare la configurazione ad alta disponibilità, le repliche tra regioni o entrambi.

Interruzione di zona: l'opzione alta disponibilità crea un'istanza VM primaria e in standby in due zone separate all'interno di una regione. Durante il normale funzionamento, l'istanza VM principale gestisce tutte le richieste, scrivendo file di database su un disco permanente a livello di area geografica, che vengono replicati in modo sincrono nelle zone principali e in standby. Se un'interruzione della zona influisce sull'istanza principale, Cloud SQL avvia un failover durante il quale il disco permanente è collegato alla VM in standby e il traffico viene reindirizzato.

Durante questo processo, il database deve essere inizializzato, il che include l'elaborazione di tutte le transazioni scritte nel log Transaction (Transazione), ma non applicate al database. Il numero e il tipo di transazioni non elaborate possono aumentare il tempo RTO. Un numero elevato di scritture recenti può causare un backlog di transazioni non elaborate. Il tempo RTO è ampiamente influenzato da (a) attività di scrittura recente e (b) modifiche recenti agli schemi di database recenti.

Infine, una volta risolta l'interruzione a livello di zona, puoi attivare manualmente un'operazione di failover per riprendere la pubblicazione nella zona principale.

Per ulteriori dettagli sull'opzione ad alta disponibilità, consulta la documentazione di alta disponibilità di Cloud SQL.

Interruzione di una regione: l'opzione replica tra regioni protegge il tuo database dalle interruzioni a livello di regione creando repliche di lettura della tua istanza principale in altre regioni. La replica tra le regioni utilizza la replica asincrona, che consente all'istanza principale di eseguire il commit delle transazioni prima di eseguire il commit sulle repliche. La differenza di tempo tra il momento in cui viene eseguita una transazione sull'istanza principale e il momento in cui viene eseguita la replica sulla replica è nota come "tempo di replica" (che può essere monitorato). Questa metrica riflette sia le transazioni che non sono state inviate dall'istanza principale alle repliche sia le transazioni ricevute, ma non elaborate dalla replica. Le transazioni non inviate alla replica diventino non disponibili durante un'interruzione a livello di area geografica. Le transazioni ricevute ma non elaborate dalla replica influiscono sul tempo di ripristino, come descritto di seguito.

Cloud SQL consiglia di testare il tuo carico di lavoro con una configurazione che include una replica per stabilire un limite di tipo "Transazioni sicure al secondo" (TPS), che è il TPS prolungato più elevato che non accumula tempi di replica. Se il carico di lavoro supera il limite del TPS sicuro, il tempo di replica si accumula, incidendo negativamente sui valori RPO e RTO. Come guida generale, evita di utilizzare configurazioni di istanze piccole (<2 core vCPU, <dischi da 100 GB o PD-HDD), che sono suscettibili a ritardi nella replica.

In caso di interruzione del servizio a livello di area geografica, devi decidere se promuovere manualmente una replica di lettura. Questa è un'operazione manuale perché la promozione può causare uno scenario a parte in cui la replica promossa accetta nuove transazioni nonostante l'istanza principale non sia stata eseguita al momento della promozione. Ciò può causare problemi quando l'interruzione a livello di area geografica viene risolta e devi riconciliare le transazioni che non sono state mai propagate dall'istanza principale all'istanza di replica. Se questo è problematico per le tue esigenze, puoi prendere in considerazione un prodotto di database di replica sincrono tra aree geografiche come Cloud Spanner.

Una volta attivato dall'utente, il processo di promozione segue i passaggi simili all'attivazione di un'istanza in standby nella configurazione ad alta disponibilità: la replica di lettura deve elaborare il log Transaction (Transazione) e il bilanciatore del carico deve reindirizzare il traffico. L'elaborazione del log Transaction (Transazione) determina il tempo di recupero totale.

Per maggiori dettagli sull'opzione di replica tra regioni, consulta la documentazione sulla replica tra regioni di Cloud SQL.

Cloud Logging

Cloud Logging è costituito da due parti principali: il router dei log e l'archiviazione su Cloud Logging.

Il router dei log gestisce gli eventi di log in streaming e indirizza i log a Cloud Storage, Pub/Sub, BigQuery o Cloud Storage.

L'archiviazione Cloud Logging è un servizio per l'archiviazione, l'esecuzione di query e la gestione della conformità per i log. Supporta molti utenti e flussi di lavoro inclusi sviluppo, conformità, risoluzione dei problemi e avvisi proattivi.

Router Logs e log in entrata: durante un'interruzione del servizio a livello di zona, l'API Cloud Logging instrada i log ad altre zone dell'area geografica. Normalmente, i log instradati dal router dei log a Cloud Logging, BigQuery o Pub/Sub vengono scritti nella destinazione finale il prima possibile, mentre i log inviati a Cloud Storage vengono memorizzati nel buffer e scritti in batch ogni ora.

Voci di log:in caso di interruzione del servizio a livello di zona o di regione, le voci di log memorizzate nel buffer nella zona o nella regione interessata e non scritte nella destinazione di esportazione diventano inaccessibili. Le metriche basate su log vengono calcolate anche nel router dei log e sono soggette agli stessi vincoli. Una volta inviati alla posizione di esportazione del log selezionata, i log vengono replicati in base al servizio di destinazione. I log esportati nello spazio di archiviazione di Cloud Logging vengono replicati in modo sincrono tra due zone in una regione. Per il comportamento della replica di altri tipi di destinazione, consulta la sezione pertinente in questo articolo. Tieni presente che i log esportati in Cloud Storage vengono raggruppati e scritti ogni ora. Pertanto, consigliamo di utilizzare l'archiviazione Cloud Logging, BigQuery o Pub/Sub per ridurre al minimo la quantità di dati interessati da un'interruzione.

Metadati del log: i metadati come il sink e la configurazione dell'esclusione vengono memorizzati in tutto il mondo, ma sono memorizzati nella cache a livello di regione, quindi, in caso di interruzione, vengono eseguite le istanze del log di regione. Le interruzioni di una singola area geografica non hanno alcun impatto al di fuori dell'area geografica.

Cloud Spanner

Cloud Spanner è un database scalabile, a disponibilità elevata, multi-versione, replicato in modo sincrono e a elevata coerenza con la semantica relazionale.

Le istanze Cloud Spanner a livello di area geografica replicano i dati in modo sincrono tra tre zone in una singola regione. Una scrittura in un'istanza Cloud Spanner a livello di area geografica viene inviata in modo sincrono a tutte e 3 le repliche e confermata al client dopo che almeno 2 repliche (numero di maggioranza di 2 su 3) hanno eseguito il commit della scrittura. Ciò rende Cloud Spanner resiliente a un errore di zona fornendo l'accesso a tutti i dati, poiché sono state mantenute le ultime scritture ed è possibile ottenere un quorum di maggioranza per le scritture con due repliche.

Le istanze multiregionali di Cloud Spanner includono un quorum di scrittura che replica in modo sincrono i dati su cinque zone situate in tre regioni (due repliche di lettura e scrittura nell'area geografica di default-leader e un'altra nell'area geografica di testimoni). La scrittura in un'istanza Cloud Spanner a più aree geografiche viene confermata dopo che almeno 3 repliche (quorum principale di 3 su 5) hanno eseguito il commit della scrittura. In caso di errore di una zona o di una regione, Cloud Spanner ha accesso a tutti i dati (incluse le scritture più recenti) e gestisce le richieste di lettura/scrittura, in quanto i dati vengono mantenuti in almeno tre zone in due regioni al momento della conferma della scrittura al client.

Consulta la documentazione relativa all'istanza Cloud Spanner per ulteriori informazioni su queste configurazioni e la documentazione di replica per ulteriori informazioni sul funzionamento della replica Cloud Spanner.

Cloud DNS

Cloud DNS è un servizio DNS (Domain Name System) globale ad alte prestazioni e resiliente che pubblica i tuoi nomi di dominio nel DNS globale in modo conveniente.

In caso di interruzione del servizio a livello di zona, Cloud DNS continua a gestire le richieste provenienti da un'altra zona nella stessa area geografica o in un'altra area geografica senza interruzioni. Gli aggiornamenti ai record Cloud DNS vengono replicati in modo sincrono tra le zone all'interno della regione in cui vengono ricevuti. Non si verifica quindi alcuna perdita di dati.

In caso di interruzione a livello di area geografica, Cloud DNS continua a gestire le richieste provenienti da altre aree geografiche. È possibile che gli aggiornamenti molto recenti ai record Cloud DNS non siano disponibili perché gli aggiornamenti vengono elaborati per la prima volta in una singola regione prima di essere replicati in modo asincrono in altre regioni.

Cloud CDN

Cloud CDN distribuisce e memorizza nella cache i contenuti in molte posizioni sulla rete di Google per ridurre la latenza di pubblicazione per i clienti. Il contenuto memorizzato nella cache viene gestito nel miglior modo possibile: quando una richiesta non può essere fornita dalla cache di Cloud CDN, la richiesta viene inoltrata ai server di origine, ad esempio VM di backend o bucket Cloud Storage, in cui sono archiviati i contenuti originali.

In caso di errore di una zona o di un'area geografica, le cache nelle località interessate non sono disponibili. Le richieste in entrata vengono instradate alle posizioni e alle cache perimetrali di Google disponibili. Se queste cache alternative non riescono a soddisfare la richiesta, la inoltreranno a un server di origine disponibile. A condizione che il server possa soddisfare la richiesta con i dati aggiornati, non si verificherà alcuna perdita di contenuti. Una maggiore frequenza di fallimenti della cache causerà un incremento dei server di traffico rispetto ai normali volumi di traffico man mano che le cache si esauriscono. Le richieste successive vengono gestite dalle cache non interessate dall'interruzione della zona o dell'area geografica.

Per ulteriori informazioni su Cloud CDN e sul comportamento della cache, consulta la documentazione di Cloud CDN.

Cloud Functions

Cloud Functions è un ambiente di computing stateless in cui i clienti possono eseguire il proprio codice funzione sull'infrastruttura di Google. Cloud Functions è un'offerta a livello di area geografica, ovvero i clienti possono scegliere l'area geografica, ma non le zone che la costituiscono. I dati e il traffico vengono automaticamente bilanciati in base al carico tra le zone di un'area geografica. Le funzioni vengono scalate automaticamente per soddisfare il traffico in entrata e il bilanciamento del carico viene eseguito tra le zone in base alle necessità. Ogni zona mantiene uno scheduler che fornisce questa scalabilità automatica per zona. È inoltre a conoscenza del carico che ricevono altre zone e eseguirà il provisioning della capacità aggiuntiva in zona per consentire eventuali errori a livello di zona.

Interruzione di zona: Cloud Functions archivia i metadati e la funzione di cui è stato eseguito il deployment. Questi dati vengono archiviati in un'area geografica e scritti in modo sincrono. L'API Cloud Functions Admin restituisce la chiamata API solo dopo che i dati sono stati messi in un quorum all'interno di una regione. Dato che i dati sono archiviati in una regione, le operazioni del piano dati non sono interessate nemmeno dai guasti a livello di zona. Il traffico viene automaticamente indirizzato ad altre zone in caso di errore di una zona.

Interruzione a livello di area geografica:i clienti scelgono la regione di Google Cloud in cui vogliono creare la propria funzione. I dati non vengono mai replicati in più aree geografiche. Il traffico dei clienti non verrà mai instradato a un'area geografica diversa da Cloud Functions. In caso di errore a livello di area geografica, Cloud Functions tornerà disponibile non appena verrà risolta. Consigliamo ai clienti di eseguire il deployment in più aree geografiche e utilizzare Cloud Load Balancing per ottenere una maggiore disponibilità, se necessario.

Cloud Run

Cloud Run è un ambiente di computing stateless, in cui i clienti possono eseguire il proprio codice containerizzato sull'infrastruttura di Google. Cloud Run è un'offerta a livello di area geografica, ovvero i clienti possono scegliere l'area geografica, ma non le zone che la costituiscono. I dati e il traffico vengono automaticamente bilanciati in base al carico tra le zone di un'area geografica. Le istanze di container vengono scalate automaticamente per soddisfare il traffico in entrata e, se necessario, vengono bilanciate il carico tra le zone. Ogni zona mantiene uno scheduler che fornisce questa scalabilità automatica per zona. È inoltre a conoscenza del carico che ricevono altre zone e eseguirà il provisioning della capacità aggiuntiva in zona per consentire eventuali errori a livello di zona.

Interruzione di zona: Cloud Run archivia i metadati e il container di cui è stato eseguito il deployment. Questi dati vengono archiviati in un'area geografica e scritti in modo sincrono. L'API Cloud Run Admin restituisce la chiamata API solo dopo che i dati sono stati impegnati in un quorum all'interno di una regione. Dato che i dati sono archiviati in una regione, le operazioni del piano dati non sono interessate nemmeno dai guasti a livello di zona. Il traffico inoltrerà automaticamente ad altre zone in caso di errore della zona.

Interruzione a livello di area geografica: i clienti scelgono la regione di Google Cloud in cui vogliono creare il proprio servizio Cloud Run. I dati non vengono mai replicati in più aree geografiche. Il traffico dei clienti non verrà mai instradato a una regione diversa da Cloud Run. In caso di errore a livello di area geografica, Cloud Run sarà di nuovo disponibile non appena l'interruzione verrà risolta. I clienti sono invitati a eseguire il deployment in più aree geografiche e a utilizzare Cloud Load Balancing per ottenere una maggiore disponibilità, se lo desiderano.

VPN ad alta disponibilità

La VPN ad alta disponibilità (VPN) è un'offerta Cloud VPN resiliente, che cripta in modo sicuro il traffico dal cloud privato on-premise, da altri cloud privati virtuali o da una rete di altri provider di servizi cloud al tuo VPC (Virtual Private Cloud) di Google Cloud.

I gateway della VPN ad alta disponibilità hanno due interfacce, ciascuna con un indirizzo IP di pool di indirizzi IP separati, suddivisi sia in modo logico che fisico in diversi PoP e cluster, per garantire una ridondanza ottimale.

Interruzione di zona: in caso di interruzione del servizio a livello di zona, un'interfaccia potrebbe perdere la connettività, ma il traffico viene reindirizzato all'altra interfaccia tramite il routing dinamico utilizzando il protocollo BGP (Border Gateway Protocol).

Interruzione a livello di area geografica: nel caso di un'interruzione a livello di area geografica, entrambe le interfacce potrebbero perdere la connettività per un breve periodo.

Cloud NAT

Cloud NAT (traduzione indirizzo di rete) è un servizio gestito distribuito e software-defined che consente a determinate risorse senza indirizzi IP esterni di creare connessioni in uscita a Internet. Non si basa su VM o appliance proxy. Cloud NAT configura invece il software Andromeda che supporta la tua rete Virtual Private Cloud in modo da fornire la traduzione degli indirizzi di rete di origine (SNAT di origine o SNAT) per le VM senza indirizzi IP esterni. Cloud NAT fornisce anche la traduzione degli indirizzi di rete di destinazione (DNA o DNAT di destinazione) per i pacchetti di risposta in entrata stabiliti.

Per ulteriori informazioni sulla funzionalità di Cloud NAT, consulta la documentazione.

Interruzione di zona: Cloud NAT è resiliente agli errori a livello di zona perché il piano di controllo e il piano dati di rete sono ridondanti in più zone all'interno di una regione.

Interruzione a livello di area geografica: Cloud NAT è un prodotto a livello di area geografica, quindi non è in grado di resistere a eventuali errori a livello di area geografica.

Cloud Load Balancing

Google Cloud Load Balancing è un bilanciatore del carico pass-through a livello di area geografica che bilancia il traffico tra le istanze VM nella stessa area geografica.

  • Il bilanciatore del carico TCP/UDP interno e il bilanciatore del carico HTTP(S) interno bilanciano il traffico TCP, UDP e HTTP(S) interno.

  • Il bilanciatore del carico HTTP(S) esterno bilancia il traffico TCP, UDP, ICMP ed ESP esterno. Il supporto di ESP e ICMP è in anteprima.

In caso di interruzione del servizio a livello di zona, Cloud Load Balancing continua a bilanciare nuove connessioni alle istanze di backend in altre zone disponibili. Le connessioni esistenti sulle istanze VM nella zona non riuscita vengono svuotate in base al criterio di monitoraggio della connessione specificato dall'utente. Questo criterio contribuisce a garantire che le connessioni ai backend in stato non integro e alle configurazioni di svuotamento delle connessioni non vengano mantenute.

Poiché Cloud Load Balancing è un prodotto a livello di area geografica, non è resiliente alle interruzioni a livello di area geografica.

Cloud Interconnect

Cloud Interconnect offre ai clienti l'accesso RFC 1918 alle reti Google Cloud dai loro data center on-premise, su cavi fisici collegati al peering Google Cloud.

Cloud Interconnect fornisce ai clienti uno SLA del 99,9% se eseguono il provisioning di connessioni a due EAD (Edgeavailability Domains) in un'area metropolitana. Uno SLA del 99,99% è disponibile se il cliente esegue il provisioning delle connessioni in due EAD in due aree metropolitane con due aree geografiche con il routing globale. Per ulteriori informazioni, consulta le pagine Topologia per applicazioni non critiche e Panoramica per applicazioni a livello di produzione.

Cloud Interconnect è indipendente dalla zona di calcolo e offre disponibilità elevata sotto forma di EAD. In caso di errore di EAD, la sessione BGP su EAD si interrompe e il traffico si interrompe sull'altro EAD.

In caso di errore a livello di area geografica, le sessioni BGP nell'area geografica in questione e il traffico subiscono un failover alle risorse nell'area di lavoro. Questa impostazione si applica quando il routing globale è abilitato.

Secret Manager

Secret Manager è un prodotto di gestione delle credenziali e dei secret per Google Cloud. Con Secret Manager, puoi controllare e limitare facilmente l'accesso ai secret, criptare i secret at-rest e assicurarti che le informazioni sensibili siano protette in Google Cloud.

In genere le risorse di Secret Manager vengono create con il criterio di replica automatico (consigliato), che ne comporta la replica globale. Se la tua organizzazione ha criteri che non consentono la replica globale dei dati secret, le risorse Secret Manager possono essere create con criteri di replica gestiti dall'utente, in cui vengono scelte una o più aree geografiche per la replica di un secret.

Interruzione di zona: in caso di interruzione del servizio a livello di zona, Secret Manager continua a gestire le richieste da un'altra zona nella stessa area geografica o in un'altra area geografica senza interruzioni. All'interno di ogni area geografica, Secret Manager gestisce sempre almeno due repliche in zone distinte (nella maggior parte delle aree geografiche tre repliche). Una volta risolta l'interruzione della zona, viene ripristinata la ridondanza completa.

Interruzione di un'area geografica:in caso di interruzione di una regione, Secret Manager continua a gestire le richieste da un'altra regione senza interruzioni, supponendo che i dati siano stati replicati in più di una regione (tramite la replica automatica o la replica gestita dall'utente in più di una regione). Una volta risolta l'interruzione dell'area geografica, viene ripristinata la ridondanza completa.

API Cloud Healthcare

L'API Cloud Healthcare, un servizio per l'archiviazione e la gestione dei dati sanitari, è progettato per fornire disponibilità elevata e offre protezione contro gli errori a livello di zona e di regione, in base alla configurazione scelta.

Configurazione a livello di area geografica: con la configurazione predefinita, l'API Cloud Healthcare offre protezione dagli errori a livello di zona. Il deployment del servizio si sviluppa in tre zone di un'area geografica, con dati triplicati in diverse zone dell'area geografica. In caso di errore a livello di zona che interessa il livello di servizio o il livello dati, le zone rimanenti eseguono la migrazione senza interruzioni. L'unica eccezione è la funzionalità di ricerca per cui una piccola quantità di dati, quelli indicizzati pochi minuti prima dell'errore della zona, potrebbe non essere disponibile nella Ricerca l (i dati sottostanti, utilizzati come fonte di riferimento, non sono interessati). Con la configurazione a livello di area geografica, se un'intera area geografica in cui si trova il servizio subisce un'interruzione, il servizio non sarà disponibile finché l'area geografica non torna online. Nell'evento imprevisto di una distruzione fisica di un'intera area geografica, i dati archiviati al suo interno andranno persi.

Configurazione su più aree geografiche: nella sua configurazione con più aree geografiche, viene eseguito il deployment dell'API Cloud Healthcare in tre zone che appartengono a tre diverse aree geografiche. I dati vengono replicati anche in tre regioni. Questo garantisce la perdita di servizi in caso di interruzione di un'intera area geografica, dato che le restanti aree geografiche acquisiranno automaticamente l'autorizzazione (la stessa eccezione per la funzionalità della Ricerca si applica alla configurazione regionale). Mentre i dati strutturati, come FHIR, vengono replicati in modo sincrono in più aree geografiche e, come tali, protetti contro la perdita di dati in caso di interruzione di un'intera area geografica, i dati archiviati nei bucket Google Storage, come DICOM e dettatura o grandi oggetti HL7v2/FHIR, vengono replicati in modo asincrono in più aree geografiche. Ciò significa che, in caso di distruzione fisica di una regione, alcuni dati scritti nelle ultime 48 ore potrebbero andare persi.

Cloud Bigtable

Cloud Bigtable è un servizio di database NoSQL ad alte prestazioni completamente gestito per grandi carichi di lavoro analitici e operativi.

Panoramica della replica Bigtable

Bigtable offre una funzionalità di replica flessibile e completamente configurabile, che puoi utilizzare per aumentare la disponibilità e la durabilità dei tuoi dati copiandoli in cluster in più regioni o più zone all'interno della stessa regione. Bigtable può anche fornire failover automatico per le tue richieste quando utilizzi la replica.

Quando utilizzi configurazioni multi-zona o a livello di più aree geografiche con il routing multi-cluster, in caso di interruzione del servizio a livello di zona o di area geografica, Bigtable reindirizza automaticamente il traffico e gestisce le richieste dal cluster disponibile più vicino. Poiché la replica Bigtable è asincrona e costantemente coerente, le modifiche molto recenti ai dati nella località dell'interruzione potrebbero non essere disponibili se non sono state ancora replicate in altre località.

Considerazioni sul rendimento

Quando le esigenze di risorse della CPU superano la capacità dei nodi disponibile, Bigtable assegna sempre la priorità alla gestione delle richieste in entrata prima del traffico di replica.

Per ulteriori informazioni su come utilizzare la replica Bigtable con il tuo carico di lavoro, consulta la Panoramica della replica Cloud Bigtable ed esempi di impostazioni di replica.

I nodi di Bigtable vengono utilizzati sia per la gestione delle richieste in entrata che per l'esecuzione di repliche dei dati provenienti da altri cluster. Oltre a mantenere un numero di nodi sufficiente per cluster, devi anche assicurarti che le tue applicazioni utilizzino un'adeguata progettazione dello schema per evitare hotspot, che possono causare un utilizzo eccessivo o inequilibrato della CPU e una latenza di replica maggiore.

Per ulteriori informazioni sulla progettazione dello schema dell'applicazione per massimizzare le prestazioni e l'efficienza di Bigtable, consulta le best practice per la progettazione dello schema.

Monitoraggio

Cloud Bigtable offre diversi modi per monitorare visivamente la latenza di replica delle istanze e dei cluster utilizzando i grafici per la replica disponibili in Google Cloud Console.

Puoi anche monitorare le metriche di replica di Bigtable in modo programmatico utilizzando l'API Cloud Monitoring.

Firestore

Firestore è un database flessibile e scalabile per lo sviluppo di soluzioni per dispositivi mobili, Web e server da Firebase e Google Cloud. Firestore offre replica automatica dei dati multiregione, garanzie di elevata coerenza, operazioni batch atomiche e transazioni ACID.

Firestore offre ai clienti sia località con una singola area geografica che più aree geografiche. Il traffico viene bilanciato automaticamente in base al carico tra le zone di un'area geografica.

Le istanze di Firestore a livello di area geografica replicano i dati in modo sincrono tra almeno tre zone. In caso di errore a livello di zona, le scritture possono comunque essere impegnate dalle due (o più) repliche rimanenti e i dati impegnati rimangono invariati. Il traffico viene instradato automaticamente ad altre zone. Una località a singola area geografica offre costi inferiori, minore latenza in scrittura e la co-location con altre risorse di Google Cloud.

Le istanze multiregionali Firestore replicano i dati in modo sincrono tra cinque zone in tre regioni (due regioni di gestione e una regione di testimoni) e sono solide contro gli errori a livello di zona e di regione. In caso di errore di zona o di area geografica, i dati commit vengono mantenuti. Il traffico viene instradato automaticamente verso le zone e le regioni di gestione e i commit vengono comunque pubblicati da almeno tre zone delle due regioni rimanenti. Più regioni massimizzano la disponibilità e la durabilità dei database.