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

Last reviewed 2024-05-10 UTC

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

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
• Architettura del ripristino di emergenza per carichi di lavoro con limitazioni a livello di località
• Casi d'uso per il ripristino di emergenza: applicazioni di analisi dei dati con limitazioni a livello di località
• Progettazione del ripristino di emergenza per le interruzioni dell'infrastruttura cloud (questo documento)

Introduzione

Quando le aziende spostano i carichi di lavoro sul cloud pubblico, devono tradurre le informazioni sulla creazione di sistemi on-premise resilienti nell'infrastruttura iperscalabile dei provider di servizi cloud come Google Cloud. Questo articolo associa i concetti standard del settore relativi al ripristino di emergenza, ad esempio 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à del servizio estremamente elevata: pianifica gli errori. Sebbene Google Cloud fornisca un servizio estremamente affidabile, si verificano situazioni di emergenza (calamità naturali, tagli delle fibre ottiche e guasti complessi e imprevedibili dell'infrastruttura) che causano interruzioni del servizio. La pianificazione delle interruzioni consente ai clienti di Google Cloud di creare applicazioni dalle prestazioni prevedibili attraverso questi eventi inevitabili, utilizzando i prodotti Google Cloud con meccanismi di RE "integrati".

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

1. L'infrastruttura di Google Cloud, il modo in cui gli eventi di emergenza si manifestano come interruzioni di Google Cloud e come 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 e progettare applicazioni in base ai risultati di affidabilità desiderati.
3. Un elenco dettagliato di alcuni prodotti Google Cloud che offrono funzionalità di RE integrate che puoi utilizzare nella tua applicazione.

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

Una nota sulla terminologia: questo articolo fa riferimento alla disponibilità quando analizza la capacità di un prodotto di essere consultato e utilizzato in modo significativo nel tempo, mentre affidabilità si riferisce a un insieme di attributi, che include la 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 agli operatori come Google di distribuire i servizi su molti componenti utilizzando tecnologie di virtualizzazione, superando così l'affidabilità dei componenti tradizionali. Ciò significa che puoi allontanare il tuo approccio all'architettura di affidabilità dalla miriade di dettagli di cui una volta ti preoccupavi per l'ambiente on-premise. Anziché preoccuparti delle varie modalità di errore dei componenti, come il raffreddamento e l'erogazione di energia, puoi pianificare in base ai prodotti Google Cloud e alle relative metriche di affidabilità dichiarate. Queste metriche riflettono il rischio aggregato di interruzione 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 raggiungere target di disponibilità aggressivi sulla base della sua vasta esperienza nello sviluppo e nella gestione di data center moderni. Google è leader mondiale nella progettazione di data center. Dall'alimentazione al raffreddamento alle reti, ogni tecnologia dei data center ha le proprie ridondanze e misure di mitigazione, compresi i piani FMEA. I data center di Google sono costruiti in modo da bilanciare molti rischi diversi e presentare ai clienti un livello previsto coerente di disponibilità per i prodotti Google Cloud. Google utilizza la sua esperienza per modellare la disponibilità dell'architettura fisica e logica del sistema complessivo in modo da garantire che la progettazione del data center soddisfa le aspettative. I tecnici di Google impiegano molto impegno dal punto di vista operativo per soddisfare tali aspettative. La disponibilità effettiva misurata di solito supera i nostri target di progettazione con un margine ragionevole.

Riunendo tutti questi rischi e mitigazioni dei data center nei prodotti rivolti agli utenti, Google Cloud ti solleva dalle responsabilità operative e di progettazione. Concentrati invece sull'affidabilità progettata nelle regioni e nelle zone di Google Cloud.

Aree geografiche e zone

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

I prodotti Google Cloud sono suddivisi in risorse di zona, risorse regionali o risorse multiregionali.

Le risorse di zona sono ospitate all'interno di 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, l'istanza di Compute Engine non è disponibile per la durata dell'interruzione.

Il deployment delle risorse di regione viene eseguito in modo ridondante in più zone all'interno di una regione. Ciò offre loro una maggiore affidabilità rispetto alle risorse di zona.

Le risorse per più regioni sono distribuite all'interno e tra le regioni. In generale, le risorse multiregionali hanno un'affidabilità maggiore rispetto alle risorse regionali. Tuttavia, a questo livello i prodotti devono ottimizzare disponibilità, prestazioni ed efficienza delle risorse. Di conseguenza, è importante comprendere i compromessi di ciascun prodotto multiregionale che decidi di utilizzare. Questi compromessi sono documentati su una base specifica del prodotto più avanti in questo documento.

Come sfruttare zone e regioni per ottenere affidabilità

Gli SRE di Google gestiscono e scalano prodotti utente globali e altamente affidabili come Gmail e la Ricerca tramite una varietà di tecniche e tecnologie che sfruttano senza problemi l'infrastruttura di computing in tutto il mondo. Ciò include il reindirizzamento del traffico da località non disponibili utilizzando il bilanciamento del carico globale, l'esecuzione di più repliche in molte località in tutto il mondo 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 (GKE) e Spanner.

In genere Google Cloud progetta i prodotti in modo da fornire i seguenti livelli di disponibilità per zone e regioni:

Risorsa	Esempi	Obiettivo di progettazione della disponibilità	Tempo di inattività implicito
Zonale	Compute Engine, Persistent Disk	99,9%	8,75 ore / anno
Regionale	Cloud Storage a livello di regione, disco permanente replicato, GKE a livello di regione	99,99%	52 minuti all'anno

Nota: queste sono linee guida per la progettazione. Gli impegni sul livello di servizio di Google Cloud sono disponibili negli accordi sul livello del servizio di Google Cloud.

Confronta gli obiettivi di progettazione della disponibilità di Google Cloud con il livello accettabile di inattività per identificare le risorse Google Cloud appropriate. Mentre i progetti tradizionali si concentrano sul miglioramento della disponibilità a livello di componente per migliorare la conseguente disponibilità delle applicazioni, i modelli cloud si concentrano invece sulla composizione dei componenti per raggiungere questo obiettivo. Molti prodotti di Google Cloud utilizzano questa tecnica. Ad esempio, Spanner offre un database multiregionale che compone più regioni per fornire una disponibilità del 99,999%.

La composizione è importante perché, senza di essa, la disponibilità della tua applicazione non può superare quella dei prodotti Google Cloud che utilizzi. Infatti, a meno che la tua applicazione non non abbia problemi, avrà una disponibilità inferiore rispetto ai prodotti Google Cloud sottostanti. Il resto di questa sezione mostra in generale come utilizzare una composizione di prodotti a livello di zona e di regione per ottenere una disponibilità delle applicazioni maggiore rispetto a quella fornita da una singola zona o regione. La prossima sezione fornisce una guida pratica per applicare questi principi alle tue applicazioni.

Pianificazione per gli ambiti di interruzione delle zone

I guasti dell'infrastruttura di solito causano interruzioni del servizio in una singola zona. All'interno di una regione, le zone sono progettate per ridurre al minimo il rischio di errori correlati con altre zone e un'interruzione del servizio in una zona di solito non influisce sul servizio di un'altra zona della stessa regione. Un'interruzione con ambito a livello di zona non significa necessariamente che l'intera zona non sia disponibile, ma definisce solo il confine dell'incidente. È possibile che un'interruzione di una zona non abbia alcun effetto tangibile sulle risorse al suo interno.

Si tratta di un caso più raro, ma è anche fondamentale notare che più zone riscontreranno comunque un'interruzione correlata a un certo punto all'interno di una singola regione. Quando due o più zone subiscono un'interruzione, si applica la strategia di ambito dell'interruzione a livello di regione riportata di seguito.

Le risorse regionali sono progettate per resistere alle interruzioni di zona, fornendo il servizio da una composizione di più zone. Se una delle zone che supporta una risorsa di regione viene interrotta, la risorsa si rende automaticamente disponibile da un'altra zona. Per ulteriori dettagli, controlla attentamente la descrizione della funzionalità del prodotto nell'appendice.

Google Cloud offre solo poche risorse di zona, ovvero macchine virtuali (VM) Compute Engine e Persistent Disk. Se prevedi di utilizzare risorse a livello di zona, dovrai eseguire personalmente la composizione delle risorse progettando, creando e testando il failover e il ripristino tra risorse di zona situate in più zone. Ecco 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 stia riscontrando problemi.
• Utilizza i modelli di istanza Compute Engine e/o i gruppi di istanze gestite per eseguire e scalare istanze VM identiche in più zone.
• Utilizza un Persistent Disk regionale per replicare in modo sincrono i dati in un'altra zona di una regione. Per maggiori dettagli, consulta Opzioni di alta disponibilità che utilizzano DP a livello di regione.

Pianificazione per gli ambiti di interruzione a livello di regione

Un'interruzione a livello di regione è un'interruzione del servizio che interessa più di una zona in una singola regione. Si tratta di interruzioni su scala più ampia, meno frequenti e possono essere causate da calamità naturali o guasti dell'infrastruttura su larga scala.

Per un prodotto regionale progettato per fornire una disponibilità del 99,99%, un'interruzione può comunque comportare quasi un'ora di inattività per un determinato prodotto ogni anno. Pertanto, per le applicazioni critiche potrebbe essere necessario disporre di un piano di RE per più regioni se la durata dell'interruzione non è accettabile.

Le risorse multiregionali sono progettate per resistere alle interruzioni delle regioni fornendo il servizio da più regioni. Come spiegato in precedenza, i prodotti multiregionali si trovano in un compromesso tra latenza, coerenza e costo. Il compromesso più comune è tra replica dei dati sincrona e asincrona. La replica asincrona offre una latenza inferiore, a scapito del rischio di perdita di dati durante un'interruzione. Pertanto, è importante controllare la descrizione della funzionalità del prodotto nell'appendice per ulteriori dettagli.

Nota: in BigQuery, una località multiregionale non fornisce la replica tra regioni o la ridondanza a livello di regione. I dati verranno archiviati in un'unica regione all'interno della posizione geografica.

Se vuoi utilizzare risorse regionali e rimanere resiliente alle interruzioni regionali, devi eseguire la tua composizione delle risorse progettando, creando e testando il failover e il ripristino tra risorse regionali situate in più regioni. Oltre alle strategie di zona descritte sopra, che puoi applicare anche a più regioni, valuta la possibilità di:

• Le risorse a livello di regione devono replicare i dati in una regione secondaria, con un'opzione di archiviazione multiregionale come Cloud Storage o un'opzione di cloud ibrido come GKE Enterprise.
• Dopo aver implementato una mitigazione delle interruzioni a livello di regione, testala regolarmente. Ci sono poche cose peggiori che pensare di resistere a un'interruzione di una singola regione, solo per scoprire che non è così nel caso reale.

Approccio a resilienza e disponibilità di Google Cloud

Google Cloud batte regolarmente i propri target di progettazione della disponibilità, ma non devi dare per scontato che queste solide prestazioni passate siano la disponibilità minima per cui puoi progettare. Devi invece selezionare le dipendenze di Google Cloud le cui destinazioni, progettate per le destinazioni superano l'affidabilità prevista dell'applicazione, in modo che il tempo di inattività dell'applicazione e il tempo di inattività di Google Cloud siano il risultato auspicato.

Un sistema ben progettato può rispondere alla domanda: "Cosa succede quando una zona o una regione subisce un'interruzione di 1, 5, 10 o 30 minuti?" Questo aspetto dovrebbe essere considerato in molti livelli, tra cui:

• Che esperienza avranno i miei clienti durante un'interruzione del servizio?
• Come faccio a rilevare un'interruzione del servizio?
• Cosa succede alla mia applicazione durante un'interruzione?
• Cosa succede ai miei dati durante un'interruzione del servizio?
• Cosa succede alle altre mie applicazioni a causa di un'interruzione (a causa di dipendenze incrociate)?
• Cosa devo fare per recuperare il servizio dopo la risoluzione di un'interruzione? Chi lo fa?
• Chi devo avvisare in caso di interruzione, entro quale periodo di tempo?

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

Le sezioni precedenti hanno visto come Google crea l'infrastruttura cloud e alcuni approcci per gestire le interruzioni di zona o regionali.

Questa sezione ti aiuta a sviluppare un framework per applicare il principio di composizione alle tue applicazioni in base ai risultati di affidabilità desiderati.

Le applicazioni dei clienti in Google Cloud destinate a obiettivi di ripristino di emergenza come RTO e RPO devono essere progettate in modo che le operazioni business-critical, soggette a RTO/RPO, abbiano dipendenze solo sui componenti del piano dati responsabili dell'elaborazione continua delle operazioni per il servizio. In altre parole, queste operazioni business-critical del cliente 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 di Google Cloud che intendono ottenere l'RTO per operazioni business-critical non devono dipendere da un'API per la creazione di 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 tue applicazioni. La maggior parte delle aziende dispone già di un certo livello di orientamento alla progettazione in questo ambito, che può essere sviluppato internamente o derivato da normative o altri requisiti legali. Queste linee guida per la progettazione sono generalmente codificate in due metriche chiave: RTO (Recovery Time Objective) e RPO (Recovery Point Objective). In termini commerciali, RTO si traduce come "Quanto tempo dopo un'emergenza prima di essere operativa" RPO si traduce come "Quanti dati posso permettermi di perdere in caso di un disastro".

In passato, le aziende hanno definito requisiti RTO e RPO per un'ampia gamma di eventi disastrosi, dagli errori dei componenti ai terremoti. Questo aveva senso nel mondo on-premise, in cui i planner dovevano mappare i requisiti RTO/RPO attraverso l'intero stack software e hardware. Nel cloud, non è più necessario definire i requisiti con questi dettagli perché è il provider che se ne occupa. Puoi invece definire i requisiti di RTO e RPO in termini di ambito della perdita (intere zone o regioni) senza specificare i motivi sottostanti. Per Google Cloud ciò semplifica la raccolta dei requisiti in 3 scenari: un'interruzione a livello di zona, un'interruzione a livello di regione o l'interruzione estremamente improbabile di più regioni.

Riconoscendo che non tutte le applicazioni hanno la stessa criticità, la maggior parte dei clienti classifica le proprie applicazioni in livelli di criticità in base ai quali è possibile applicare un requisito RTO/RPO specifico. Se combinati, RTO/RPO e la criticità dell'applicazione semplificano il processo di progettazione di una determinata applicazione rispondendo a:

1. L'applicazione deve essere eseguita in più zone della stessa regione o in più zone di più regioni?
2. Da quali prodotti Google Cloud può dipendere l'applicazione?

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

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

Criticità dell'applicazione	% di app	App di esempio	Interruzione zona	Interruzione per regione
Livello 1 (più importante)	5%	Applicazioni tipicamente globali o esterne rivolte ai clienti, come pagamenti in tempo reale e vetrine di e-commerce.	RTO zero RPO zero	RTO zero RPO zero
Livello 2	35%	In genere, applicazioni regionali o importanti applicazioni interne, come CRM o ERP.	RTO 15 min RPO 15 min	RTO 1 ora RPO 1 ora
Livello 3 (meno importante)	60%	In genere, le applicazioni a livello di team o dipartimenti, ad esempio back office, prenotazioni di permessi, 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 funzionalità di resilienza dei prodotti Google Cloud che utilizzeranno le tue applicazioni. La maggior parte delle aziende esamina le informazioni pertinenti sul prodotto e poi aggiunge indicazioni su come modificare le architetture per colmare eventuali lacune tra le funzionalità del prodotto e i requisiti di resilienza. Questa sezione illustra alcune aree comuni e consigli relativi ai dati e alle limitazioni delle applicazioni in questo ambito.

Come accennato in precedenza, i prodotti abilitati per la RE di Google soddisfano ampiamente due tipi di ambiti di interruzione: a livello di regione e di zona. Le interruzioni parziali devono essere pianificate allo stesso modo di un'interruzione completa per quanto riguarda il RE. In questo modo viene fornita una matrice iniziale di alto livello dei prodotti idonei per ogni scenario per impostazione predefinita:

Funzionalità generali del prodotto Google Cloud
(consulta l'appendice per le funzionalità specifiche del prodotto)

	Tutti i prodotti Google Cloud	Prodotti Google Cloud regionali con replica automatica tra zone	Prodotti Google Cloud globali o multiregionali con replica automatica tra regioni
Errore di un componente all'interno di una zona	Con copertura*	Con copertura	Con copertura
Interruzione zona	Non inclusi	Con copertura	Con copertura
Interruzione per regione	Non inclusi	Non inclusi	Con copertura

* Tutti i prodotti Google Cloud sono resilienti agli errori dei componenti, tranne nei casi specifici indicati nella documentazione del prodotto. Si tratta in genere di scenari in cui il prodotto offre accesso diretto o mappatura statica a componenti hardware speciali 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ù significativo dal punto di vista dell'architettura da considerare per un servizio. Almeno alcune applicazioni hanno un requisito RPO pari a zero, il che significa che non dovrebbero verificarsi perdite di dati in caso di interruzione. Questo richiede in genere la replica sincrona dei dati in un'altra zona o regione. La replica sincrona presenta compromessi in termini di costi e latenza, perciò, sebbene molti prodotti Google Cloud forniscano la replica sincrona tra zone, solo pochi la forniscono in diverse regioni. Questo compromesso in termini di 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, se necessario, recuperarli da una fonte di dati aurea. 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 regione. È inoltre importante che durante un'interruzione transient, i dati scritti nella località interessata, ma non ancora replicati in un'altra località, diventino disponibili in genere dopo la risoluzione dell'interruzione. Ciò significa che il rischio di perdita definitiva dei dati è inferiore al rischio di perdere l'accesso ai dati durante un'interruzione.

Azioni chiave: stabilisci se hai effettivamente bisogno di RPO zero e, in caso affermativo, se puoi farlo per un sottoinsieme dei tuoi dati, questo aumenta notevolmente la gamma di servizi abilitati per RE a tua disposizione. In Google Cloud, ottenere un RPO pari a zero significa utilizzare per la tua applicazione prodotti prevalentemente regionali, che per impostazione predefinita sono resilienti alle interruzioni con scalabilità a livello di zona, ma non a livello di regione.

Come RTO limita le scelte relative ai prodotti

Uno dei principali vantaggi del cloud computing è la possibilità di eseguire il deployment dell'infrastruttura on demand; tuttavia, non è la stessa cosa del deployment istantaneo. Il valore RTO per la tua applicazione deve soddisfare l'RTO combinato dei prodotti Google Cloud utilizzato dall'applicazione e le eventuali azioni che i tuoi ingegneri o SRE devono intraprendere per riavviare le VM o i componenti dell'applicazione. Un RTO misurato in minuti significa progettare un'applicazione che recupera automaticamente da un'emergenza senza intervento umano o con passaggi minimi come la pressione di un pulsante per il failover. I costi e la complessità di questo tipo di sistema sono sempre stati molto elevati, ma i prodotti Google Cloud, come i bilanciatori del carico e i gruppi di istanze, rendono questa progettazione molto più conveniente e semplice. Dovresti quindi considerare il failover e il ripristino automatici per la maggior parte delle applicazioni. Tieni presente che la progettazione di un sistema per questo tipo di failover a caldo in più regioni è complicata e costosa al tempo stesso. Solo una piccola parte dei servizi critici garantisce questa capacità.

La maggior parte delle applicazioni avrà un RTO compreso tra un'ora e un giorno, il che consente un failover a caldo in uno scenario di emergenza, con alcuni componenti dell'applicazione sempre in esecuzione in modalità standby (come i database), mentre altri vengono sottoposti a scale out in caso di emergenza effettiva, come i server web. Per queste applicazioni, ti consigliamo vivamente di considerare l'automazione per gli eventi di scale out. I servizi con un RTO nell'arco di un giorno rappresentano la criticità più bassa e spesso possono essere recuperati da un backup o ricreati da zero.

Azioni chiave:stabilisci se hai effettivamente bisogno di un RTO pari a (vicino) zero per il failover a livello di regione e, in questo caso, se puoi farlo per un sottoinsieme dei tuoi servizi. che modifica i costi di esecuzione e manutenzione del servizio.

Passaggio 3: sviluppa le tue architetture e guide di riferimento

L'ultimo passaggio consigliato consiste nel creare pattern di architettura specifici per l'azienda per aiutare i team a standardizzare l'approccio al ripristino di emergenza. La maggior parte dei clienti di Google Cloud produce una guida per i propri team di sviluppo che associa le proprie aspettative in termini di resilienza aziendale individuali alle due categorie principali di scenari di interruzione su Google Cloud. In questo modo, i team possono classificare facilmente i prodotti abilitati per RE e adatti a ogni livello di criticità.

Crea le linee guida per i prodotti

Osservando di nuovo la tabella RTO/RPO di esempio riportata sopra, è disponibile una guida ipotetica che elenca quali prodotti sarebbero 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 i tuoi meccanismi di replica e di failover per abilitare la sincronizzazione tra zone o tra regioni, ma questo esercizio non rientra nell'ambito di questo articolo. Le tabelle contengono inoltre link a ulteriori informazioni su ciascun prodotto per aiutarti a comprenderne le funzionalità per quanto riguarda la gestione delle interruzioni di zona o regione.

Esempi di pattern di architettura per l'organizzazione di esempio - Resilienza per interruzione di zona

Prodotto Google Cloud	Il prodotto soddisfa i requisiti di interruzione a livello di zona per l'organizzazione di esempio (con la configurazione del prodotto appropriata)?
	Livello 1	Livello 2	Livello 3
Compute Engine	No	No	No
Dataflow	No	No	No
BigQuery	No	No	Sì
GKE	Sì	Yes	Sì
Cloud Storage	Sì	Yes	Sì
Cloud SQL	No	Sì	Sì
Spanner	Sì	Yes	Sì
Cloud Load Balancing	Sì	Yes	Sì

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

Modelli di architettura di esempio per l'organizzazione di esempio - Resilienza per interruzione regionale

Prodotto Google Cloud	Il prodotto soddisfa i requisiti di interruzione per regione per Organizzazione di esempio (con la configurazione del prodotto appropriata)?
	Livello 1	Livello 2	Livello 3
Compute Engine	Sì	Yes	Sì
Dataflow	No	No	No
BigQuery	No	No	Sì
GKE	Sì	Yes	Sì
Cloud Storage	No	No	No
Cloud SQL	No	Sì	Sì
Spanner	Sì	Yes	Sì
Cloud Load Balancing	Sì	Yes	Sì

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

Per mostrare come potrebbero essere utilizzati questi prodotti, le sezioni seguenti illustrano alcune architetture di riferimento per ciascuno dei livelli ipotetici di criticità dell'applicazione. Si tratta di descrizioni volutamente di alto livello finalizzate a illustrare le decisioni chiave dell'architettura e non sono rappresentative del progetto di una soluzione completa.

Esempio di architettura di livello 3

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

(Le icone in grigio indicano che l'infrastruttura deve essere 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 rispetto a quanto richiesto. Tuttavia, ti consigliamo di eliminare anche i passaggi manuali aggiuntivi quando potrebbero rivelarsi costosi o inaffidabili. Ad esempio, il ripristino di un database da un backup notturno potrebbe supportare l'RPO di 24 ore, ma di solito necessita di una persona qualificata come un amministratore di database che potrebbe non essere disponibile, soprattutto se il problema riguarda più servizi contemporaneamente. Con l'infrastruttura on demand di Google Cloud è possibile creare questa capacità senza dover scendere a compromessi in termini di costi. Per questo motivo, questa architettura utilizza l'alta disponibilità di Cloud SQL anziché un backup/ripristino manuale per le interruzioni della 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 agli utenti un punto di accesso scalabile, che consente il failover automatico in un'altra zona. Anche se il RTO è di 12 ore, le modifiche manuali agli indirizzi IP o persino gli aggiornamenti DNS possono richiedere più tempo del previsto.
• Un gruppo di istanze gestite a livello di regione è configurato con più zone, ma con risorse minime. Questo ottimizza i costi, ma consente comunque lo scale out rapido delle macchine virtuali nella zona di backup.
• Una configurazione di Cloud SQL ad alta disponibilità fornisce il failover automatico in un'altra zona. I database sono molto più difficili da ricreare e ripristinare rispetto alle macchine virtuali di Compute Engine.

Decisioni in materia di architettura chiave per l'interruzione della regione - 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 a livello di regione orchestrata ma manuale, poiché l'infrastruttura nella regione 2 verrebbe resa disponibile solo in caso di interruzione del servizio.
• Viene creato un nuovo gruppo di istanze gestite solo in caso di interruzione di una regione. Questo consente di ottimizzare i costi ed è improbabile che venga richiamata, data la breve durata delle interruzioni nella maggior parte delle regioni. Tieni presente che, per semplicità, il diagramma non mostra gli strumenti associati necessari per rieseguire 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 prolungata in una regione è estremamente basso, perciò si tratta di un altro compromesso per l'ottimizzazione dei costi.
• Per archiviare questi backup, viene utilizzato Cloud Storage multiregionale. Ciò fornisce una zona automatica e una resilienza regionale all'interno dell'RTO e dell'RPO.

Esempio di architettura di livello 2

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

Questa architettura descrive un data warehouse con utenti interni collegati a un livello di visualizzazione dell'istanza di computing e un livello di importazione e trasformazione dei dati che popola 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 loro utilizzo combinato, il servizio complessivo soddisfa l'RPO. In questo caso, poiché Dataflow è un prodotto a livello di zona, segui i suggerimenti per la progettazione ad alta disponibilità per aiutare a prevenire la perdita di dati durante un'interruzione. Tuttavia, il livello Cloud Storage è l'origine aurea di questi dati e supporta un RPO pari a zero. Di conseguenza, puoi importare nuovamente i dati persi in BigQuery utilizzando la zona b in caso di interruzione nella zona a.

Decisioni in materia di architettura chiave per l'interruzione della zona - RTO di 4 ore e RPO di zero:

• Un bilanciatore del carico viene utilizzato per fornire un punto di accesso scalabile agli utenti, che consente il failover automatico in un'altra zona. Anche se l'RTO è di 4 ore, le modifiche manuali agli indirizzi IP o persino gli aggiornamenti DNS possono richiedere più tempo del previsto.
• Un gruppo di istanze gestite a livello di regione per il livello di calcolo della visualizzazione dei dati è configurato con più zone con risorse minime. Questo ottimizza i costi, ma consente comunque lo scale out delle VM.
• Cloud Storage a livello di regione viene utilizzato come livello di gestione temporanea per l'importazione iniziale dei dati, fornendo resilienza automatica della zona.
• Dataflow viene utilizzato per estrarre i 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 del data warehouse per il frontend di visualizzazione dei dati. In caso di interruzione di una zona, i dati persi vengono importati nuovamente da Cloud Storage.

Decisioni nell'architettura chiave per l'interruzione della regione - RTO di 24 ore e RPO di 4 ore:

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

Esempio di architettura di livello 1

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

Questa architettura descrive un'infrastruttura di backend per app mobile con utenti esterni che si connettono a un set di microservizi in esecuzione in GKE. Spanner fornisce il livello di archiviazione dei dati backend per i dati in tempo reale e i dati storici vengono trasmessi in flusso a un data lake BigQuery in ogni regione.

Anche in questo caso, alcuni singoli componenti di questa architettura non supportano direttamente l'RPO richiesto per il loro livello, ma a causa del modo in cui vengono utilizzati insieme al servizio complessivo. In questo caso BigQuery viene usato per le query analitiche. Ogni regione viene alimentata contemporaneamente da 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, che consente il failover automatico in un'altra zona.
• Per il livello dell'applicazione viene utilizzato un cluster GKE a livello di regione configurato con più zone. In questo modo viene raggiunto un RTO pari a zero all'interno di ciascuna regione.
• Lo Spanner per più regioni viene utilizzato come livello di persistenza dei dati, che fornisce resilienza automatica dei dati e coerenza delle transazioni.
• BigQuery offre la funzionalità di analisi per l'applicazione. Ogni regione riceve dati alimentati in modo indipendente da Spanner e l'applicazione vi accede in modo indipendente.

Decisioni chiave sull'architettura per l'interruzione della regione - RTO di 4 ore e RPO di 1 ora:

• Un bilanciatore del carico viene utilizzato per fornire un punto di accesso scalabile agli utenti, che consente il failover automatico in un'altra regione.
• Per il livello dell'applicazione viene utilizzato un cluster GKE a livello di regione configurato con più zone. In caso di interruzione di una regione, il cluster nella regione alternativa scala automaticamente per adattarsi al carico di elaborazione aggiuntivo.
• Lo Spanner per più regioni viene utilizzato come livello di persistenza dei dati, che fornisce resilienza automatica dei dati a livello di regione e coerenza delle transazioni. È il componente fondamentale per raggiungere l'RPO tra regioni di un'ora.
• BigQuery offre la funzionalità di analisi per l'applicazione. Ogni regione riceve dati alimentati in modo indipendente da Spanner e l'applicazione vi accede in modo indipendente. Questa architettura compensa il componente BigQuery, consentendogli di soddisfare i requisiti generali dell'applicazione.

Appendice: Riferimento prodotto

Questa sezione descrive l'architettura e le funzionalità di RE dei prodotti Google Cloud più comunemente utilizzate nelle applicazioni del cliente 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ù regioni. I prodotti regionali sono resilienti alle interruzioni di zona e i prodotti multiregionali e globali sono resilienti alle interruzioni a livello di regione. In generale, questo significa che durante un'interruzione l'applicazione subisce interruzioni minime. Google raggiunge questi risultati tramite alcuni approcci architetturali comuni, che rispecchiano le linee guida sull'architettura sopra descritte.

• Deployment ridondante: il deployment dei backend delle applicazioni e dell'archiviazione dei dati viene eseguito in più zone all'interno di una regione e in più regioni all'interno di una località multiregionale.

• Replica dei dati: i prodotti utilizzano la replica sincrona o asincrona tra le località ridondanti.

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

    Sebbene questa tecnica offra la massima protezione dei dati, può avere vantaggi in termini di latenza e prestazioni. I prodotti multiregionali che utilizzano la replica sincrona offrono questo compromesso in modo significativo, in genere nell'ordine di 10 o 100 secondi di latenza aggiuntiva.

  • La replica asincrona implica che, quando l'applicazione effettua una chiamata API per creare o modificare i dati archiviati dal prodotto, riceve una risposta positiva dopo che il prodotto ha scritto i dati in un'unica posizione. Dopo la tua richiesta di scrittura, il prodotto replica i dati in ulteriori posizioni.

    Questa tecnica fornisce nell'API una latenza inferiore e una velocità effettiva superiore rispetto alla replica sincrona, ma a scapito della protezione dei dati. Se la località in cui hai scritto i dati subisce un'interruzione prima del completamento della replica, perdi l'accesso ai dati finché l'interruzione della località 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 dell'applicazione appropriati. Rispetto ad altri approcci come il bilanciamento del carico del DNS, questo approccio riduce il tempo di risposta del sistema a un'interruzione. Quando si verifica un'interruzione della località di Google Cloud, il bilanciatore del carico rileva rapidamente che il backend di cui è stato eseguito il deployment in tale località è diventato "non integro" e indirizza tutte le richieste a un backend in una posizione 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 località, il bilanciatore del carico rileva la disponibilità dei backend dei prodotti in quella località e riprende a inviare traffico in quella località.

Gestore contesto accesso

Gestore contesto accesso consente alle aziende di configurare livelli di accesso mappati a un criterio definito negli attributi della richiesta. I criteri vengono rispecchiati a livello di regione.

In caso di interruzione a livello di zona, le richieste alle zone non disponibili vengono gestite automaticamente e in modo trasparente dalle altre zone disponibili nella regione.

In caso di interruzione del servizio a livello di regione, i calcoli dei criteri della regione interessata non saranno disponibili finché la regione non tornerà disponibile.

Access Transparency

Access Transparency consente agli amministratori di organizzazioni Google Cloud di definire un controllo dell'accesso granulare e basato sugli attributi per progetti e risorse in Google Cloud. Occasionalmente, Google deve accedere ai dati dei clienti per scopi amministrativi. Quando accediamo ai dati dei clienti, Access Transparency fornisce i log degli accessi ai clienti Google Cloud interessati. Questi log di Access Transparency contribuiscono a garantire l'impegno di Google per la sicurezza e la trasparenza dei dati nella gestione dei dati.

Access Transparency è resiliente in caso di interruzioni a livello di zona e di regione. Se si verifica un'interruzione a livello di zona o di regione, Access Transparency continua a elaborare i log degli accessi amministrativi in un'altra zona o regione.

AlloyDB per PostgreSQL

AlloyDB per PostgreSQL è un servizio di database completamente gestito e compatibile con PostgreSQL. AlloyDB per PostgreSQL offre disponibilità elevata in una regione attraverso i nodi ridondanti della sua istanza principale che si trovano in due zone diverse dell'area geografica. L'istanza principale mantiene la disponibilità a livello regionale attivando un failover automatico nella zona in standby se si verifica un problema nella zona attiva. Regional Storage garantisce la durabilità dei dati in caso di perdita in una singola zona.

Come ulteriore metodo di ripristino di emergenza, AlloyDB per PostgreSQL utilizza la replica tra regioni per fornire funzionalità di ripristino di emergenza replicando in modo asincrono i dati del cluster principale in cluster secondari che si trovano in regioni Google Cloud separate.

Interruzione di zona: durante il normale funzionamento, solo uno dei due nodi di un'istanza principale ad alta disponibilità è attivo e gestisce tutte le scritture dei dati. Questo nodo attivo archivia i dati nel livello di archiviazione regionale separato del cluster.

AlloyDB per PostgreSQL rileva automaticamente errori a livello di zona e attiva un failover per ripristinare la disponibilità del database. Durante il failover, AlloyDB per PostgreSQL avvia il database sul nodo in standby, di cui è già stato eseguito il provisioning in una zona diversa. Le nuove connessioni al database vengono instradate automaticamente a questa zona.

Dal punto di vista di un'applicazione client, un'interruzione a livello di zona è simile a un'interruzione temporanea della connettività di rete. Al termine del failover, un client può riconnettersi all'istanza allo stesso indirizzo, utilizzando le stesse credenziali, senza perdita di dati.

Interruzione regionale: la replica tra regioni utilizza la replica asincrona, che consente all'istanza principale di eseguire il commit delle transazioni prima che venga eseguita sulle repliche. La differenza di tempo tra il momento in cui viene impegnata una transazione sull'istanza principale e il momento in cui viene eseguita sulla replica è nota come tempo di replica. La differenza di tempo tra il momento in cui l'istanza principale genera il log write-ahead (WAL) e il momento in cui WAL raggiunge la replica è nota come flush lag. Il ritardo della replica e del flush lag dipendono dalla configurazione dell'istanza di database e dal carico di lavoro generato dall'utente.

In caso di interruzione a livello di regione, puoi promuovere cluster secondari in un'altra regione a cluster principale autonomo e scrivibile. Questo cluster promosso non replica più i dati del cluster principale originale a cui era associato in precedenza. A causa del ritardo di svuotamento, potrebbe verificarsi una perdita di dati perché potrebbero esserci transazioni nell'istanza principale originale non propagate al cluster secondario.

L'RPO di replica tra regioni è influenzato sia dall'utilizzo della CPU del cluster principale e dalla distanza fisica tra la regione del cluster principale e quella del cluster secondario. Per ottimizzare l'RPO, ti consigliamo di testare il carico di lavoro con una configurazione che include una replica per stabilire un limite di transazioni al secondo (TPS) sicure, ovvero il TPS sostenuto più alto che non accumula flush lag. Se il carico di lavoro supera il limite di TPS sicuro, il ritardo di svuotamento si accumula, il che può influire sull'RPO. Per limitare il ritardo della rete, scegli coppie di regioni all'interno dello stesso continente.

Per ulteriori informazioni sul monitoraggio del ritardo della rete e su altre metriche AlloyDB per PostgreSQL, consulta Monitorare le istanze.

Anti Money Laundering AI

Anti Money Laundering AI (AML AI) fornisce un'API per aiutare gli istituti finanziari di tutto il mondo a rilevare in modo più efficace ed efficiente il riciclaggio di denaro. Anti riciclaggio di denaro è un'offerta regionale, il che significa che i clienti possono scegliere la regione, ma non le zone che la compongono. I dati e il traffico vengono bilanciati automaticamente tra le zone all'interno di una regione. Le operazioni (ad esempio, per creare una pipeline o eseguire una previsione) vengono scalate automaticamente in background e vengono bilanciate in base alle esigenze.

Interruzione a livello di zona: AML AI archivia i dati per le sue risorse a livello di regione, replicati in modo sincrono. Quando un'operazione a lunga esecuzione viene completata correttamente, è possibile fare affidamento sulle risorse a prescindere dai guasti della zona. L'elaborazione viene replicata anche tra le zone, ma questa replica ha come obiettivo il bilanciamento del carico e non l'alta disponibilità, pertanto un errore a livello di zona durante un'operazione può causare un errore dell'operazione. In questo caso, puoi provare a risolvere il problema riprovando a eseguire l'operazione. Durante un'interruzione a livello di zona, i tempi di elaborazione potrebbero risentirne.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui vogliono creare le proprie risorse AML AI. I dati non vengono mai replicati tra le regioni. Il traffico dei clienti non viene mai instradato a una regione diversa da AML AI. In caso di errore a livello di regione, AML AI tornerà disponibile non appena l'interruzione verrà risolta.

Chiavi API

Le chiavi API offrono una gestione scalabile delle risorse delle chiavi API per un progetto. Le chiavi API sono un servizio globale, ovvero le chiavi sono visibili e accessibili da qualsiasi località di Google Cloud. I dati e i metadati sono archiviati in modo ridondante in più zone e regioni.

Le chiavi API sono resilienti alle interruzioni sia a livello di zona che di regione. In caso di interruzione a livello di zona o di regione, le chiavi API continuano a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa.

Per ulteriori informazioni sulle chiavi API, consulta Panoramica dell'API delle chiavi API.

Apigee

Apigee offre una piattaforma sicura, scalabile e affidabile per lo sviluppo e la gestione delle API. Apigee offre deployment a livello di una o più regioni.

Interruzione a livello di zona: i dati sul runtime dei clienti vengono replicati in più zone di disponibilità. Di conseguenza, un'interruzione in una singola zona non ha alcun impatto su Apigee.

Interruzione regionale: per le istanze Apigee a una singola regione, se una regione non è più disponibile, le istanze Apigee non sono disponibili in quella regione e non possono essere ripristinate in regioni diverse. Per le istanze Apigee multiregionali, i dati vengono replicati in tutte le regioni in modo asincrono. Di conseguenza, l'errore di un'area geografica non riduce completamente il traffico. Tuttavia, potresti non essere in grado di accedere ai dati di cui non è stato eseguito il commit nella regione in errore. Puoi allocare il traffico dalle regioni in stato non integro. Per ottenere il failover automatico del traffico, puoi configurare il routing di rete utilizzando gruppi di istanze gestite.

AutoML Translation

AutoML Translation è un servizio di traduzione automatica che ti consente di importare i tuoi dati (coppie di frasi) per addestrare modelli personalizzati per le tue esigenze specifiche del dominio.

Interruzione a livello di zona: AutoML Translation ha server di computing attivi in più zone e regioni. Supporta inoltre la replica sincrona dei dati tra zone all'interno delle regioni. Queste funzionalità aiutano AutoML Translation a ottenere un failover immediato senza alcuna perdita di dati in caso di errori a livello di zona e senza richiedere input o aggiustamenti da parte del cliente.

Interruzione a livello di regione: in caso di errore a livello di regione, AutoML Translation non è disponibile.

AutoML Vision

AutoML Vision fa parte di Vertex AI. Offre un framework unificato per creare set di dati, importare dati, addestrare modelli e fornire modelli per la previsione online e batch.

AutoML Vision è un'offerta regionale. I clienti possono scegliere da quale regione vogliono avviare un job, ma non possono scegliere le zone specifiche all'interno di quella regione. Il servizio bilancia automaticamente il carico tra zone diverse della regione.

Interruzione a livello di zona: AutoML Vision archivia i metadati per i job a livello di regione e scrive in modo sincrono tra le zone all'interno della regione. I job vengono avviati in una zona specifica, selezionata da Cloud Load Balancing.

• Job di addestramento AutoML Vision: un'interruzione a livello di zona provoca la mancata riuscita di tutti i job in esecuzione e degli aggiornamenti dello stato dei job. Se un job non va a buon fine, riprova subito. Il nuovo job viene instradato a una zona disponibile.

• Job di previsione batch di AutoML Vision: la previsione batch si basa sulla previsione batch di Vertex AI. Quando si verifica un'interruzione a livello di zona, il servizio riprova automaticamente a eseguire il job instradandolo alle zone disponibili. Se più nuovi tentativi non vanno a buon fine, lo stato del job viene aggiornato a non riuscito. Le successive richieste dell'utente per eseguire il job vengono instradate a una zona disponibile.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui vogliono eseguire i propri job. I dati non vengono mai replicati tra regioni. In caso di errore a livello di regione, il servizio AutoML Vision non è disponibile in quella regione. Quando l'interruzione viene risolta, diventa di nuovo disponibile. Per eseguire i job, consigliamo ai clienti di utilizzare più regioni. In caso di interruzione a livello di regione, indirizza i job a un'altra regione.

Batch

Batch è un servizio completamente gestito per inserire in coda, pianificare ed eseguire job batch su Google Cloud. Le impostazioni batch sono definite a livello di regione. I clienti devono scegliere una regione per l'invio dei job batch, non una zona in una regione. Quando viene inviato un job, Batch scrive in modo sincrono i dati dei clienti in più zone. Tuttavia, i clienti possono specificare le zone in cui le VM batch eseguono i job.

Errore di zona: quando si verifica un errore in una singola zona, anche le attività in esecuzione al suo interno non vanno a buon fine. Se le attività hanno impostazioni per i nuovi tentativi, il failover delle attività in Batch viene eseguito automaticamente in altre zone attive nella stessa regione. Il failover automatico è soggetto alla disponibilità di risorse nelle zone attive della stessa regione. I job che richiedono risorse di zona (come VM, GPU o dischi permanenti a livello di zona) disponibili solo nella zona con errori vengono messi in coda fino al ripristino della zona in errore o fino al raggiungimento dei timeout per l'accodamento dei job. Quando possibile, consigliamo ai clienti di consentire a Batch di scegliere le risorse di zona per eseguire i propri job. Così facendo puoi assicurarti che i job siano resilienti a un'interruzione a livello di zona.

Errore a livello di regione: in caso di errore a livello di regione, il piano di controllo del servizio non è disponibile nella regione. Il servizio non replica i dati né reindirizza le richieste tra regioni. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri job e di reindirizzare i job a un'altra regione in caso di errore di una regione.

Protezione dei dati e tutela dalle minacce di Chrome Enterprise Premium

La protezione dei dati e la protezione dalle minacce di Chrome Enterprise Premium fa parte della soluzione Chrome Enterprise Premium. Estende Chrome con una serie di funzionalità di sicurezza, tra cui protezione da malware e phishing, prevenzione della perdita di dati (DLP), regole di filtro degli URL e report sulla sicurezza.

Gli amministratori di Chrome Enterprise Premium possono attivare l'archiviazione dei contenuti principali dei clienti che violano i criteri relativi a DLP o malware in eventi del log delle regole di Google Workspace e/o in Cloud Storage per indagini future. Gli eventi del log delle regole di Google Workspace sono basati su un database Spanner per più regioni. Il rilevamento delle violazioni delle norme in Chrome Enterprise Premium può richiedere diverse ore. Durante questo periodo, tutti i dati non elaborati sono soggetti a perdita di dati a causa di un'interruzione del servizio a livello di zona o di regione. Una volta rilevata una violazione, i contenuti che violano i criteri vengono scritti negli eventi del log delle regole di Google Workspace e/o in Cloud Storage.

Interruzione a livello di zona e di regione: Poiché la protezione dei dati e la protezione dalle minacce di Chrome Enterprise Premium sono multi-zona e multiregionali, possono sopravvivere a una perdita completa e non pianificata di una zona o di una regione senza perdita di disponibilità. Fornisce questo livello di affidabilità reindirizzando il traffico al proprio servizio in altre zone attive o regioni. Tuttavia, poiché la protezione dei dati e la protezione dalle minacce di Chrome Enterprise Premium potrebbero impiegare diverse ore per rilevare le violazioni DLP e da malware, tutti i dati non elaborati in una zona o regione specifica potrebbero subire la perdita a causa di un'interruzione del servizio a livello di zona o di regione.

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 degli utenti:

• Una regione: una località geografica specifica, ad esempio Iowa (us-central1) o Montréal (northamerica-northeast1).
• Più regioni: una grande area geografica contenente due o più luoghi geografici, come gli Stati Uniti (US) o l'Europa (EU).

In entrambi i casi, i dati vengono archiviati in modo ridondante in due zone all'interno di una singola regione all'interno della località selezionata. I dati scritti in BigQuery vengono scritti in modo sincrono sia nella zona primaria che in quella secondaria. Questo ti protegge dall'indisponibilità di una singola zona all'interno della regione, ma non da un'interruzione del servizio a livello di regione.

Autorizzazione binaria

Autorizzazione binaria è un prodotto per la sicurezza della catena di fornitura del software per GKE e Cloud Run.

Tutti i criteri di Autorizzazione binaria vengono replicati in più zone all'interno di ogni regione. La replica consente alle operazioni di lettura dei criteri di Autorizzazione binaria di recuperare dagli errori di altre regioni. La replica inoltre tollera le operazioni di lettura in caso di errori a livello di zona all'interno di ogni regione.

Le operazioni di applicazione di Autorizzazione binaria sono resilienti contro le interruzioni a livello di zona, ma non a livello di regione. Le operazioni di applicazione vengono eseguite nella stessa regione del cluster GKE o del job Cloud Run che esegue la richiesta. Di conseguenza, in caso di interruzione a livello di regione, non c'è nulla in esecuzione per effettuare richieste di applicazione di Autorizzazione binaria.

Gestore certificati

Gestore certificati consente di acquisire e gestire i certificati Transport Layer Security (TLS) da utilizzare con diversi tipi di Cloud Load Balancing.

In caso di interruzione a livello di zona, il Gestore certificati a livello di zona e di regione è resiliente agli errori a livello di zona, poiché i job e i database sono ridondanti in più zone all'interno di una regione. In caso di interruzione del servizio a livello di regione, Gestore certificati globale è resiliente agli errori regionali, poiché i job e i database sono ridondanti in più regioni. Regional Certificate Manager è un prodotto regionale, quindi non è in grado di resistere a errori regionali.

Cloud Intrusion Detection System

Cloud Intrusion Detection System (Cloud IDS) è un servizio di zona che fornisce endpoint IDS con ambito a livello di zona, che elaborano il traffico delle VM in una zona specifica e quindi non tollera interruzioni a livello di zona o di regione.

Interruzione a livello di zona: Cloud IDS è collegato alle istanze VM. Se un cliente prevede di mitigare le interruzioni a livello di zona eseguendo il deployment di VM in più zone (manualmente o tramite gruppi di istanze gestite a livello di regione), dovrà eseguire il deployment degli endpoint Cloud IDS anche in quelle zone.

Interruzione regionale: Cloud IDS è un prodotto regionale. Non fornisce alcuna funzionalità per più regioni. Un errore regionale disattiverà tutte le funzionalità di Cloud IDS in tutte le zone della regione.

SIEM per Google Security Operations

Google Security Operations SIEM (che fa parte di Google Security Operations) è un servizio completamente gestito che aiuta i team di sicurezza a rilevare, analizzare e rispondere alle minacce.

Google Security Operations SIEM offre offerte regionali e multiregionali.

• Nelle offerte regionali, i clienti possono scegliere la regione, ma non le zone che la compongono. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno della regione selezionata. I dati vengono archiviati in modo ridondante nelle zone di disponibilità all'interno della regione.

• Le regioni multiple sono con ridondanza geografica. I dati sono archiviati in modo ridondante tra le regioni, il che fornisce un insieme più ampio di protezioni rispetto all'archiviazione regionale e garantisce la funzionalità del servizio anche in caso di perdita di un'intera regione. I dati vengono replicati in modo asincrono. Ciò significa che esiste una finestra temporale (un RPO o Recovery Point Objective) durante la quale i dati non vengono ancora replicati tra regioni. Dopo l'RPO, i dati sono disponibili in più regioni. Non sono disponibili garanzie per il ritardo della replica.

Interruzione a livello di zona:

• Implementazioni regionali: la soluzione SIEM per le operazioni di sicurezza di Google viene distribuita in più zone all'interno di una sola regione. Le richieste vengono gestite da qualsiasi zona all'interno della regione e i dati vengono replicati in più zone della regione. In caso di interruzione dell'intera zona, le zone rimanenti continuano a gestire il traffico ed elaborare i dati. Il provisioning ridondante e la scalabilità automatizzata per Google Security Operations SIEM garantiscono che il servizio resti operativo nelle zone sopravvissute durante questi cambi di carico.

• Deployment in più regioni: il deployment di Google Security Operations SIEM viene eseguito in più regioni. I dati vengono replicati in modo asincrono tra le regioni. In caso di interruzione dell'intera regione, non sono disponibili garanzie per la replica dei dati e la capacità del servizio di eseguire il fallback su una zona o regione diversa.

Interruzione a livello di regione:

• Implementazioni regionali: Google Security Operations SIEM archivia tutti i dati dei clienti in un'unica regione e il traffico non viene mai instradato tra regioni. In caso di interruzione a livello di regione, Google Security Operations SIEM non sarà disponibile fino alla risoluzione dell'interruzione.

• Deployment in più regioni: Google Security Operations SIEM replica i dati in più regioni e il traffico viene reindirizzato automaticamente alle regioni rimanenti. Non esistono garanzie per il ritardo di replica e per la possibilità di continuare l'elaborazione dalle regioni rimanenti.

Cloud Asset Inventory

Cloud Asset Inventory è un servizio globale resiliente e ad alte prestazioni che gestisce un repository di metadati di criteri e risorse di Google Cloud. Cloud Asset Inventory offre strumenti di ricerca e analisi che consentono di tenere traccia degli asset di cui è stato eseguito il deployment in organizzazioni, cartelle e progetti.

In caso di interruzione di una zona, Cloud Asset Inventory continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa.

In caso di interruzione a livello di regione, Cloud Asset Inventory continua a gestire le richieste provenienti da altre regioni.

Bigtable

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 in più zone all'interno della stessa regione. Bigtable può inoltre fornire il Failover automatico per le tue richieste quando utilizzi la replica.

Quando utilizzi configurazioni multi-zona o multiregionali con il routing multi-cluster, in caso di interruzione a livello di zona o di regione, Bigtable reindirizza automaticamente il traffico e gestisce le richieste dal cluster più vicino disponibile. Poiché la replica di Bigtable è asincrona e alla fine 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 sulle prestazioni

Importante: devi assicurarti che l'utilizzo della CPU e le dimensioni dei dati rimangano entro i valori massimi consigliati e che il provisioning dei cluster venga sempre eseguito in modo adeguato affinché la replica possa essere prevedibile.

Quando le richieste di risorse della CPU superano la capacità disponibile per i nodi, Bigtable dà 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 Bigtable vengono utilizzati sia per gestire le richieste in entrata sia per eseguire la replica dei dati da altri cluster. Oltre a mantenere un numero sufficiente di nodi per cluster, devi anche assicurarti che le applicazioni utilizzino una progettazione dello schema appropriata per evitare gli hotspot, che possono causare un utilizzo eccessivo o sbilanciato della CPU e una maggiore latenza di replica.

Per saperne di più sulla progettazione dello schema dell'applicazione per massimizzare le prestazioni e l'efficienza di Bigtable, consulta le best practice per la progettazione di schemi.

Monitoraggio

Bigtable offre diversi modi per monitorare visivamente la latenza di replica di istanze e cluster utilizzando i grafici per la replica disponibili nella console Google Cloud.

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

Certificate Authority Service

Certificate Authority Service (CA Service) consente ai clienti di semplificare, automatizzare e personalizzare il deployment, la gestione e la sicurezza di autorità di certificazione private (CA) e di emettere certificati in modo resiliente su larga scala.

Interruzione a livello di zona: il servizio CA è resiliente agli errori a livello di zona perché il suo piano di controllo è ridondante in più zone all'interno di una regione. In caso di interruzione a livello di zona, CA Service continua a gestire le richieste da un'altra zona nella stessa regione senza interruzioni. Poiché i dati vengono replicati in modo sincrono, non si verifica alcuna perdita o danneggiamento dei dati.

Interruzione a livello di regione: il servizio CA è un prodotto a livello di regione, perciò non può resistere a un errore a livello di regione. Se hai bisogno di resilienza agli errori regionali, crea CA di emissione in due regioni diverse. Crea la CA emittente principale nella regione in cui hai bisogno dei certificati. Creare una CA di riserva in un'altra regione. Utilizza il fallback quando si verifica un'interruzione nella regione della CA subordinata principale. Se necessario, entrambe le CA possono concatenare la stessa CA radice.

Cloud Billing

L'API Cloud Billing consente agli sviluppatori di gestire in modo programmatico la fatturazione dei progetti Google Cloud. L'API Cloud Billing è progettata come sistema globale con aggiornamenti scritti in modo sincrono in più zone e regioni.

Errore a livello di zona o di regione: l'API Cloud Billing eseguirà automaticamente il failover in un'altra zona o regione. Le singole richieste potrebbero non riuscire, ma un criterio di ripetizione dovrebbe consentire i tentativi successivi.

Cloud Build

Cloud Build è un servizio che esegue le tue build su Google Cloud.

Cloud Build è composto da istanze isolate a livello di regione che replicano in modo sincrono i dati tra le zone all'interno della regione. Ti consigliamo di utilizzare regioni di Google Cloud specifiche anziché la regione globale e di assicurarti che le risorse utilizzate dalla build (inclusi bucket di log, repository Artifact Registry e così via) siano allineate alla regione in cui viene eseguita la build.

In caso di interruzione a livello di zona, le operazioni del piano di controllo non sono interessate. Tuttavia, le build attualmente in esecuzione nella zona in errore verranno ritardate o perse definitivamente. Le build appena attivate verranno distribuite automaticamente alle zone di funzionamento rimanenti.

In caso di errore a livello di regione, il piano di controllo sarà offline e le build attualmente in esecuzione verranno ritardate o verranno perse definitivamente. I trigger, i pool di worker e i dati di build non vengono mai replicati tra regioni. Ti consigliamo di preparare trigger e pool di worker in più regioni per semplificare la mitigazione di un'interruzione.

Cloud CDN

Cloud CDN distribuisce e memorizza nella cache i contenuti in molte località della rete Google per ridurre la latenza di servizio per i client. I contenuti memorizzati nella cache vengono pubblicati secondo il criterio del "best effort": quando una richiesta non può essere gestita dalla cache di Cloud CDN, la richiesta viene inoltrata ai server di origine, come le VM di backend o i bucket Cloud Storage, in cui sono archiviati i contenuti originali.

In caso di errore in una zona o in una regione, le cache nelle località interessate non sono disponibili. Le richieste in entrata vengono instradate alle località perimetrali e alle cache di Google disponibili. Se queste cache alternative non possono soddisfare la richiesta, la inoltreranno a un server di origine disponibile. Se il server è in grado di soddisfare la richiesta con dati aggiornati, non si verificherà alcuna perdita di contenuti. Una maggiore percentuale di fallimenti della cache farà sì che i server di origine registrino volumi di traffico superiori al normale quando le cache vengono riempite. Le richieste successive vengono gestite dalle cache non interessate dall'interruzione della zona o della regione.

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

Cloud Composer

Cloud Composer è un servizio gestito di orchestrazione dei flussi di lavoro che consente di creare, pianificare, monitorare e gestire flussi di lavoro distribuiti tra cloud e data center on-premise. Gli ambienti Cloud Composer sono basati sul progetto open source Apache Airflow.

La disponibilità dell'API Cloud Composer non è influenzata dall'indisponibilità a livello di zona. Durante un'interruzione a livello di zona, puoi mantenere l'accesso all'API Cloud Composer e, ad esempio, creare nuovi ambienti Cloud Composer.

Un ambiente Cloud Composer include un cluster GKE come parte della propria architettura. Durante un'interruzione a livello di zona, i flussi di lavoro nel cluster potrebbero subire interruzioni:

• In Cloud Composer 1, il cluster dell'ambiente è una risorsa di zona, pertanto un'interruzione a livello di zona potrebbe rendere il cluster non disponibile. Workflows in esecuzione al momento dell'interruzione potrebbero essere arrestati prima del completamento.
• In Cloud Composer 2, il cluster dell'ambiente è una risorsa regionale. Tuttavia, i flussi di lavoro eseguiti sui nodi nelle zone interessate da un'interruzione a livello di zona potrebbero essere arrestati prima del completamento.

In entrambe le versioni di Cloud Composer, un'interruzione a livello di zona potrebbe causare l'interruzione dell'esecuzione dei flussi di lavoro eseguiti parzialmente, incluse eventuali azioni esterne che il flusso di lavoro è stato configurato da te. A seconda del flusso di lavoro, ciò può causare incoerenze esternamente, ad esempio se il flusso di lavoro si arresta durante un'esecuzione in più passaggi per modificare i datastore esterni. Pertanto, quando progetti il flusso di lavoro di Airflow, devi prendere in considerazione il processo di ripristino, incluse le modalità di rilevamento degli stati del flusso di lavoro parzialmente non eseguiti e di correggere eventuali modifiche parziali ai dati.

In Cloud Composer 1, durante un'interruzione di una zona, puoi scegliere di avviare un nuovo ambiente Cloud Composer in un'altra zona. Poiché Airflow mantiene lo stato dei flussi di lavoro nel proprio database di metadati, il trasferimento di queste informazioni in un nuovo ambiente Cloud Composer può richiedere ulteriori passaggi e la preparazione.

In Cloud Composer 2, puoi far fronte alle interruzioni a livello di zona configurando in anticipo il ripristino di emergenza con snapshot di ambiente. Durante un'interruzione di una zona, puoi passare a un altro ambiente trasferendo lo stato dei flussi di lavoro con uno snapshot dell'ambiente. Solo Cloud Composer 2 supporta il ripristino di emergenza con snapshot dell'ambiente.

Cloud Data Fusion

Cloud Data Fusion è un servizio di integrazione dei dati aziendali completamente gestito per creare e gestire rapidamente pipeline di dati. Offre tre versioni.

• Le interruzioni a livello di zona influiscono sulle istanze della versione Developer.

• Le interruzioni a livello di regione influiscono sulle istanze delle versioni Basic ed Enterprise.

Per controllare l'accesso alle risorse, puoi progettare ed eseguire pipeline in ambienti separati. Questa separazione consente di progettare una pipeline una sola volta e quindi di eseguirla in più ambienti. Puoi ripristinare le pipeline in entrambi gli ambienti. Per maggiori informazioni, consulta Effettuare il backup e il ripristino dei dati dell'istanza.

I consigli seguenti riguardano le interruzioni a livello di regionale e a livello di zona.

Interruzioni nell'ambiente di progettazione delle pipeline

Nell'ambiente di progettazione, salva le bozze della pipeline in caso di interruzione. A seconda dei requisiti RTO e RPO specifici, puoi utilizzare le bozze salvate per ripristinare la pipeline in un'istanza Cloud Data Fusion diversa durante un'interruzione.

Interruzioni nell'ambiente di esecuzione della pipeline

Nell'ambiente di esecuzione, la pipeline viene avviata internamente con trigger o pianificazioni di Cloud Data Fusion, oppure esternamente con strumenti di orchestrazione come Cloud Composer. Per poter recuperare le configurazioni di runtime delle pipeline, esegui il backup delle pipeline e delle configurazioni, ad esempio plug-in e pianificazioni. Durante un'interruzione, puoi usare il backup per replicare un'istanza in una zona o regione non interessata.

Un altro modo per prepararsi alle interruzioni è avere più istanze nelle regioni con la stessa configurazione e lo stesso set di pipeline. Se utilizzi l'orchestrazione esterna, le pipeline in esecuzione possono essere bilanciate automaticamente tra le istanze. Presta particolare attenzione per assicurarti che non ci siano risorse (ad esempio, origini dati o strumenti di orchestrazione) collegate a una singola regione e utilizzate da tutte le istanze, poiché questo potrebbe diventare un punto di errore centrale in un'interruzione. Ad esempio, puoi avere più istanze in diverse regioni e utilizzare Cloud Load Balancing e Cloud DNS per indirizzare le richieste di esecuzione della pipeline a un'istanza non interessata da un'interruzione (vedi le architetture di livello uno e livello tre di esempio).

Interruzioni per altri servizi dati Google Cloud nella pipeline

L'istanza potrebbe utilizzare altri servizi Google Cloud come origini dati o ambienti di esecuzione della pipeline, come Dataproc, Cloud Storage o BigQuery. Questi servizi possono trovarsi in regioni diverse. Quando è necessaria l'esecuzione tra regioni, un errore in una delle due regioni comporta un'interruzione. In questo scenario, seguirai i passaggi per il ripristino di emergenza standard, tenendo presente che la configurazione tra regioni con servizi critici in regioni diverse è meno resiliente.

Cloud Deploy

Cloud Deploy fornisce la distribuzione continua di carichi di lavoro in servizi di runtime come GKE e Cloud Run. Il servizio è composto da istanze a livello di regione che replicano in modo sincrono i dati tra le zone all'interno della regione.

Interruzione a livello di zona: le operazioni del piano di controllo non sono interessate. Tuttavia, le build di Cloud Build (ad esempio operazioni di rendering o deployment) in esecuzione in caso di errore di una zona vengono ritardate o perse definitivamente. Durante un'interruzione, la risorsa Cloud Deploy che ha attivato la build (una release o un'implementazione) mostra uno stato di errore che indica che l'operazione sottostante non è riuscita. Puoi ricreare la risorsa per avviare una nuova build nelle zone funzionanti rimanenti. Ad esempio, crea una nuova implementazione eseguendo di nuovo il deployment della release in una destinazione.

Interruzione a livello di regione: le operazioni del piano di controllo e i dati di Cloud Deploy non sono disponibili fino al ripristino della regione. Per semplificare il ripristino del servizio in caso di interruzione del servizio a livello di regione, ti consigliamo di archiviare la pipeline di distribuzione e le definizioni della destinazione nel controllo dell'origine. Puoi utilizzare questi file di configurazione per ricreare le pipeline di Cloud Deploy in una regione funzionante. Durante un'interruzione, i dati relativi alle release esistenti vengono persi. Crea una nuova release per continuare a eseguire il deployment del software nelle tue destinazioni.

Cloud DNS

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

In caso di interruzione a livello di zona, Cloud DNS continua a gestire le richieste da un'altra zona, nella stessa regione o in una regione diversa, senza interruzioni. Gli aggiornamenti ai record Cloud DNS vengono replicati in modo sincrono tra le zone all'interno della regione in cui vengono ricevuti. Pertanto, non si verificano perdite di dati.

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

Cloud Functions

Cloud Functions è un ambiente di computing stateless in cui i clienti possono eseguire il codice della funzione sull'infrastruttura di Google. Cloud Functions è un'offerta regionale, il che significa che i clienti possono scegliere la regione, ma non le zone che la compongono. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno di una regione. Le funzioni vengono scalate automaticamente per soddisfare il traffico in entrata e bilanciate il carico tra le zone, se necessario. Ogni zona mantiene uno scheduler che fornisce questa scalabilità automatica per zona. È inoltre consapevole del carico ricevuto dalle altre zone ed eseguirà il provisioning di capacità extra nella zona per consentire eventuali errori a livello di zona.

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

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui vogliono creare la propria funzione. I dati non vengono mai replicati tra regioni. Il traffico dei clienti non verrà mai instradato a una regione diversa da Cloud Functions. In caso di errore a livello di regione, Cloud Functions sarà di nuovo disponibile non appena l'interruzione verrà risolta. Consigliamo ai clienti di eseguire il deployment in più regioni e di utilizzare Cloud Load Balancing per ottenere una disponibilità maggiore, se lo desiderano.

API Cloud Healthcare

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

Configurazione regionale: nella configurazione predefinita, l'API Cloud Healthcare offre protezione contro i guasti delle zone. Il deployment del servizio viene eseguito in tre zone di una regione e i dati sono triplicati in diverse zone all'interno della regione. In caso di errore a livello di zona che interessa il livello di servizio o il livello dati, le zone rimanenti prendono il controllo senza interruzioni. Con la configurazione a livello di regione, se si verifica un'interruzione di un'intera regione in cui si trova il servizio, questo non sarà disponibile finché la regione non tornerà online. In caso di distruzione fisica di un'intera regione, i dati archiviati in quella regione andranno persi.

Configurazione per più regioni: nella sua configurazione multiregionale, il deployment dell'API Cloud Healthcare viene eseguito in tre zone appartenenti a tre diverse regioni. I dati vengono inoltre replicati in tre regioni. Questa funzionalità impedisce la perdita del servizio in caso di interruzione del servizio in un'intera regione, poiché le regioni rimanenti prenderanno automaticamente il controllo. I dati strutturati, come FHIR, vengono replicati in modo sincrono in più regioni, quindi sono protetti dalla perdita di dati in caso di interruzione dell'intera regione. I dati archiviati nei bucket Cloud Storage, come DICOM e dettatura, o oggetti HL7v2/FHIR di grandi dimensioni, vengono replicati in modo asincrono in più regioni.

Cloud Identity

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

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

Cloud Interconnect

Cloud Interconnect offre ai clienti l'accesso RFC 1918 alle reti Google Cloud dai data center on-premise, tramite cavi fisici connessi al perimetro del peering di Google.

Cloud Interconnect offre ai clienti uno SLA del 99,9% se eseguono il provisioning delle connessioni a due EAD (domini di disponibilità Edge) in un'area metropolitana. Se il cliente esegue il provisioning delle connessioni in due EAD in due aree metropolitane a due regioni mediante routing globale, è disponibile uno SLA del 99,99%. Per ulteriori informazioni, consulta la panoramica della topologia per le applicazioni non critiche e la panoramica della topologia per le applicazioni a livello di produzione.

Cloud Interconnect è indipendente dalla zona di computing e offre disponibilità elevata sotto forma di EAD. In caso di errore EAD, la sessione BGP a quell'EAD si interrompe e il traffico esegue il failover verso l'altro EAD.

In caso di errore a livello di regione, le sessioni BGP verso quella regione si interrompono e il traffico viene eseguito con il failover delle risorse nella regione di lavoro. Ciò si applica quando è abilitato il routing globale.

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 nei database Spanner, che offrono un'elevata durabilità e disponibilità dei dati con la replica sincrona.

Le risorse di Cloud KMS possono essere create in una singola regione, in più regioni o a livello globale.

In caso di interruzione a livello di zona, Cloud KMS continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni. Poiché i dati vengono replicati in modo sincrono, non si verificano perdite o danneggiamenti. Una volta risolta l'interruzione della zona, viene ripristinata la ridondanza completa.

In caso di interruzione del servizio a livello di regione, le risorse a livello di regione in quella regione sono offline finché la regione non diventa di nuovo disponibile. Tieni presente che anche all'interno di un'area geografica, almeno tre repliche vengono mantenute in zone separate. Quando è richiesta una maggiore disponibilità, le risorse devono essere archiviate in una configurazione globale o multiregionale. Le configurazioni multiregionali e globali sono progettate per rimanere disponibili durante un'interruzione regionale mediante l'archiviazione e la distribuzione geografica dei dati in più regioni.

Cloud External Key Manager (Cloud EKM)

Cloud External Key Manager è integrato con Cloud Key Management Service per consentirti di controllare e accedere alle chiavi esterne tramite partner terzi supportati. Puoi utilizzare queste chiavi esterne per criptare i dati at-rest da utilizzare per altri servizi Google Cloud che supportano l'integrazione delle chiavi di crittografia gestite dal cliente (CMEK).

• Interruzione a livello di zona: Cloud External Key Manager è resiliente alle interruzioni a livello di zona grazie alla ridondanza fornita da più zone in una regione. Se si verifica un'interruzione a livello di zona, il traffico viene reindirizzato ad altre zone all'interno della regione. Durante il reindirizzamento del traffico, potresti notare un aumento degli errori, ma il servizio è ancora disponibile.

• Interruzione a livello di regione: Cloud External Key Manager non è disponibile durante un'interruzione a livello di regione nella regione interessata. Non esiste un meccanismo di failover che reindirizza le richieste tra regioni. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri job.

Cloud External Key Manager non archivia i dati dei clienti in modo permanente. Di conseguenza, non si verificano perdite di dati durante un'interruzione regionale nel sistema Cloud External Key Manager. Tuttavia, Cloud External Key Manager dipende dalla disponibilità di altri servizi, come Cloud Key Management Service e fornitori di terze parti esterni. Se questi sistemi si verificano durante un'interruzione regionale, potresti perdere dati. L'RPO/RTO di questi sistemi non rientra nell'ambito degli impegni di Cloud External Key Manager.

Cloud Load Balancing

Cloud Load Balancing è un servizio gestito completamente distribuito e software-defined. Con Cloud Load Balancing, un singolo indirizzo IP anycast può fungere da frontend per i backend in regioni di tutto il mondo. Non è basato su hardware, quindi non è necessario gestire un'infrastruttura fisica di bilanciamento del carico. I bilanciatori del carico sono un componente fondamentale della maggior parte delle applicazioni

Cloud Load Balancing offre bilanciatori del carico a livello di regione e globale. Fornisce inoltre il bilanciamento del carico tra regioni, compreso il failover automatico multiregione, che trasferisce il traffico ai backend di failover se i backend primari sono in stato non integro.

I bilanciatori del carico globali sono resilienti alle interruzioni di servizio sia a livello di zona che a livello di regione. I bilanciatori del carico regionali sono resilienti alle interruzioni a livello di zona, ma sono interessati da interruzioni nella loro regione. Tuttavia, in entrambi i casi, è importante comprendere che la resilienza dell'applicazione complessiva dipende non solo dal tipo di bilanciatore del carico di cui si esegue il deployment, ma anche dalla ridondanza dei backend.

Per ulteriori informazioni su Cloud Load Balancing e sulle sue funzionalità, consulta la panoramica di Cloud Load Balancing.

Cloud Logging

Cloud Logging è costituito da due parti principali: il router dei log e lo spazio di archiviazione di Cloud Logging.

Il router dei log gestisce i flussi di eventi dei log e indirizza i log allo spazio di archiviazione di Cloud Storage, Pub/Sub, BigQuery o Cloud Logging.

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, tra cui sviluppo, conformità, risoluzione dei problemi e avvisi proattivi.

Router dei log e log in entrata: durante un'interruzione del servizio a livello di zona, l'API Cloud Logging instrada i log ad altre zone della regione. Di solito, 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 inseriti nel buffer e scritti in batch ogni ora.

Voci di log: in caso di interruzione a livello di zona o di regione, le voci di log che sono state memorizzate nel buffer nella zona o 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 consegnati nella località di esportazione dei 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 di una regione. Per il comportamento di replica di altri tipi di destinazione, consulta la sezione pertinente di questo articolo. Tieni presente che i log esportati in Cloud Storage vengono raggruppati e scritti ogni ora. Consigliamo quindi di utilizzare lo spazio di archiviazione di Cloud Logging, BigQuery o Pub/Sub per ridurre al minimo la quantità di dati interessati da un'interruzione.

Metadati di log: i metadati come la configurazione di sink ed esclusione vengono archiviati a livello globale, ma memorizzati nella cache a livello di regione, quindi, in caso di interruzione, le istanze del router di log a livello di regione potrebbero funzionare. Le interruzioni di una singola regione non hanno alcun impatto al di fuori della regione.

Cloud Monitoring

Cloud Monitoring è costituito da una serie di funzionalità interconnesse, come dashboard (integrate e definite dall'utente), avvisi e monitoraggio dell'uptime.

Tutte le configurazioni di Cloud Monitoring, comprese dashboard, controlli di uptime e criteri di avviso, sono definite a livello globale. Tutte le modifiche vengono replicate in più regioni in modo sincrono. Pertanto, durante le interruzioni a livello di zona e di regione, le modifiche alla configurazione eseguite correttamente sono durevoli. Inoltre, anche se possono verificarsi errori temporanei di lettura e scrittura quando inizialmente una zona o una regione non vanno a buon fine, Cloud Monitoring reindirizza le richieste verso le zone e le regioni disponibili. In questo caso, puoi riprovare a modificare la configurazione con backoff esponenziale.

Quando scrivi le metriche per una risorsa specifica, Cloud Monitoring identifica innanzitutto la regione in cui si trova la risorsa. Poi scrive tre repliche indipendenti dei dati delle metriche all'interno della regione. La scrittura della metrica regionale complessiva viene restituita non appena una delle tre scritture riesce. Non è garantito che le tre repliche si trovino in zone diverse della regione.

• A livello di zona: durante un'interruzione a livello di zona, le scritture e le letture delle metriche non sono completamente disponibili per le risorse nella zona interessata. Di fatto, Cloud Monitoring si comporta come se la zona interessata non esiste.

• A livello di regione: durante un'interruzione a livello di regione, le scritture e le letture delle metriche non sono completamente disponibili per le risorse nella regione interessata. Di fatto, Cloud Monitoring si comporta come se la regione interessata non esiste.

Cloud NAT

Cloud NAT (Network Address Translation) è un servizio gestito, distribuito e software-defined, che consente a determinate risorse senza indirizzi IP esterni di creare connessioni in uscita verso internet. Non si basa su VM o appliance proxy. Cloud NAT configura invece il software Andromeda utilizzato per la rete Virtual Private Cloud in modo da fornire Network Address Translation di origine (NAT o SNAT di origine) per le VM senza indirizzi IP esterni. Cloud NAT offre inoltre Network Address Translation di destinazione (NAT di destinazione o DNAT) per i pacchetti di risposta in entrata stabiliti.

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

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

Interruzione a livello di regione: Cloud NAT è un prodotto a livello di regione, quindi non è in grado di resistere a un errore a livello di regione.

Router Cloud

Il router Cloud è un servizio Google Cloud completamente distribuito e gestito che utilizza il Border Gateway Protocol (BGP) per pubblicizzare gli intervalli di indirizzi IP. Programma route dinamiche in base agli annunci BGP che riceve da un peer. Invece di un dispositivo fisico o di un'appliance, ciascun router Cloud è costituito da attività software che fungono da relatori BGP.

In caso di interruzione a livello di zona, il router Cloud con configurazione ad alta disponibilità è resiliente agli errori a livello di zona. In questo caso, un'interfaccia potrebbe perdere la connettività, ma il traffico viene reindirizzato all'altra tramite il routing dinamico utilizzando BGP.

In caso di interruzione del servizio a livello di regione, il router Cloud è un prodotto a livello di regione, quindi non può resistere a un errore a livello di regione. Se i clienti hanno abilitato la modalità di routing globale, il routing tra la regione in errore e altre regioni potrebbe essere interessato.

Cloud Run

Cloud Run è un ambiente di computing stateless in cui i clienti possono eseguire il codice containerizzato sull'infrastruttura di Google. Cloud Run è un'offerta regionale, il che significa che i clienti possono scegliere la regione, ma non le zone che la compongono. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno di una regione. Le istanze di container vengono scalate automaticamente per soddisfare il traffico in entrata e bilanciate il carico tra le zone in base alle esigenze. Ogni zona gestisce uno scheduler che fornisce questa scalabilità automatica per zona. È inoltre consapevole del carico ricevuto dalle altre zone ed eseguirà il provisioning di capacità extra nella zona per consentire eventuali errori a livello di zona.

Interruzione a livello di zona: Cloud Run archivia i metadati e il container di cui è stato eseguito il deployment. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. L'API Cloud Run Admin restituisce la chiamata API solo una volta che i dati sono stati impegnati per un quorum all'interno di una regione. Poiché i dati sono archiviati a livello di regione, anche le operazioni del piano dati non sono interessate da errori a livello di zona. Il traffico verrà instradato automaticamente ad altre zone in caso di errore di una zona.

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

Cloud Shell

Cloud Shell fornisce agli utenti di Google Cloud l'accesso a istanze di Compute Engine per singoli utenti preconfigurate per attività di onboarding, formazione, sviluppo e operatore.

Cloud Shell non è adatto all'esecuzione di carichi di lavoro delle applicazioni ed è destinato invece a casi d'uso didattici e di sviluppo interattivi. Prevede limiti di quota di runtime per utente, viene arrestato automaticamente dopo un breve periodo di inattività e l'istanza è accessibile solo all'utente assegnato.

Le istanze di Compute Engine a supporto del servizio sono risorse di zona, quindi in caso di interruzione di una zona, Cloud Shell di un utente non è disponibile.

Cloud Source Repositories

Cloud Source Repositories consente agli utenti di creare e gestire repository privati di codice sorgente. Questo prodotto è progettato con un modello globale, pertanto non è necessario configurarlo per la resilienza regionale o zona.

Invece, le operazioni git push su Cloud Source Repositories replicano in modo sincrono l'aggiornamento del repository di codice sorgente a più zone in più regioni. Ciò significa che il servizio è resiliente alle interruzioni in qualsiasi regione.

Se si verifica un'interruzione in una zona o regione specifica, il traffico viene distribuito automaticamente in altre zone o regioni.

La funzionalità che consente di eseguire automaticamente il mirroring dei repository da GitHub o Bitbucket può essere influita da problemi in questi prodotti. Ad esempio, il mirroring è influenzato se GitHub o Bitbucket non possono avvisare Cloud Source Repositories dei nuovi commit o se Cloud Source Repositories non è in grado di recuperare il contenuto dal repository aggiornato.

Spanner

Spanner è un database scalabile, ad alta disponibilità, multiversione, replicato in modo sincrono e a elevata coerenza con semantica relazionale.

Le istanze Spanner regionali replicano in modo sincrono i dati in tre zone in un'unica regione. Una scrittura su un'istanza Spanner a livello di regione viene inviata in modo sincrono a tutte e tre le repliche e confermata al client dopo che almeno 2 repliche (quorum di maggioranza di 2 su 3) hanno eseguito il commit della scrittura. Ciò rende Spanner resiliente a un errore di zona fornendo l'accesso a tutti i dati, poiché le ultime scritture sono state persistenti e il quorum di maggioranza per le scritture può essere ancora raggiunto con 2 repliche.

Le istanze multiregionali di Spanner includono un quorum di scrittura che replica in modo sincrono i dati in 5 zone situate in tre regioni (due repliche di lettura e scrittura ciascuna nella regione leader predefinita e in un'altra regione; e una replica nella regione di testimonianza). Una scrittura su un'istanza Spanner multiregionale viene confermata dopo che almeno 3 repliche (quorum di maggioranza di 3 su 5) hanno eseguito il commit della scrittura. In caso di errore di una zona o di una regione, Spanner ha accesso a tutti i dati (incluse le ultime scritture) e gestisce le richieste di lettura/scrittura quando i dati sono mantenuti in almeno tre zone in due regioni al momento della conferma della scrittura al client.

Consulta la documentazione sull'istanza di Spanner per ulteriori informazioni su queste configurazioni e la documentazione sulla replica per ulteriori informazioni sul funzionamento della replica di Spanner.

Cloud SQL

Cloud SQL è un servizio di database relazionale completamente gestito per MySQL, PostgreSQL e SQL Server. Cloud SQL usa macchine virtuali gestite di Compute Engine 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. Puoi eseguire il provisioning delle repliche tra regioni per proteggere il database da un'interruzione del servizio. Poiché il prodotto offre anche un'opzione a livello di zona, che non è resiliente all'interruzione di una zona o di una regione, devi prestare attenzione a selezionare la configurazione ad alta disponibilità, le repliche tra regioni o entrambe.

Interruzione a livello di zona: l'opzione di alta disponibilità crea un'istanza VM principale e in standby in due zone separate all'interno della stessa regione. Durante il normale funzionamento, l'istanza VM principale gestisce tutte le richieste, scrivendo i file di database su un disco permanente a livello di regione, che viene replicato in modo sincrono nelle zone primarie e in standby. Se un'interruzione di una zona interessa l'istanza principale, Cloud SQL avvia un failover durante il quale il Persistent Disk viene 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 delle transazioni, ma non applicate al database. Il numero e il tipo di transazioni non elaborate possono aumentare il tempo RTO. Scritture recenti elevate possono portare a un backlog di transazioni non elaborate. Il tempo RTO è maggiormente influenzato da (a) un'elevata attività di scrittura recente e (b) modifiche recenti agli schemi dei database.

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

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

Interruzione a livello di regione: l'opzione di replica tra regioni protegge il database da interruzioni regionali creando repliche di lettura dell'istanza principale in altre regioni. La replica tra regioni utilizza la replica asincrona, che consente all'istanza principale di eseguire il commit delle transazioni prima dell'esecuzione del commit sulle repliche. La differenza di tempo tra il momento in cui viene eseguito il commit di una transazione nell'istanza principale e il momento in cui viene eseguito il commit nella 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 che sono state ricevute ma non sono state elaborate dalla replica. Le transazioni non inviate alla replica diventano non disponibili durante un'interruzione del servizio a livello di regione. Le transazioni ricevute ma non elaborate dalla replica influiscono sul tempo di recupero, come descritto di seguito.

Cloud SQL consiglia di testare il carico di lavoro con una configurazione che include una replica per stabilire un limite di "transazioni sicure al secondo (TPS)", ovvero il TPS più elevato sostenuto che non accumula il ritardo della replica. Se il carico di lavoro supera il limite TPS sicuro, il ritardo della replica si accumula, con ripercussioni negative sui valori RPO e RTO. Come indicazione generale, evita di utilizzare configurazioni di istanze di piccole dimensioni (<2 core vCPU, dischi da <100 GB o DP-HDD), vulnerabili al ritardo della replica.

In caso di interruzione a livello di regione, devi decidere se promuovere manualmente una replica di lettura. Questa è un'operazione manuale perché la promozione può causare uno scenario di split cervello in cui la replica promossa accetta nuove transazioni nonostante sia in ritardo rispetto all'istanza principale al momento della promozione. Ciò può causare problemi quando l'interruzione regionale viene risolta e devi riconciliare le transazioni che non sono mai state propagate dall'istanza principale a quella di replica. Se questo è un problema per le tue esigenze, puoi prendere in considerazione un prodotto di database di replica sincrona tra regioni come Spanner.

Una volta attivato dall'utente, il processo di promozione segue passaggi simili all'attivazione di un'istanza in standby nella configurazione ad alta disponibilità. In questo processo, la replica di lettura deve elaborare il log delle transazioni che determina il tempo di ripristino totale. Poiché nella promozione della replica non è coinvolto un bilanciatore del carico integrato, reindirizza manualmente le applicazioni all'istanza principale promossa.

Per ulteriori dettagli sull'opzione di replica tra regioni, consulta la documentazione relativa alla replica tra regioni di Cloud SQL.

Per saperne di più sulla RE di Cloud SQL, consulta quanto segue:

• Ripristino di emergenza del database Cloud SQL per MySQL
• Ripristino di emergenza dei database Cloud SQL per PostgreSQL
• Ripristino di emergenza dei database Cloud SQL per SQL Server

Cloud Storage

Cloud Storage offre archiviazione di oggetti unificata, scalabile e a elevata durabilità a livello globale. I bucket Cloud Storage possono essere creati in uno dei tre diversi tipi di località: in una singola regione, in due regioni o in più regioni all'interno di un continente. Con i bucket a livello di regione, gli oggetti vengono archiviati in modo ridondante nelle zone di disponibilità di una singola regione. I bucket a due e più regioni sono invece con ridondanza geografica. Ciò significa che dopo che i nuovi dati scritti sono stati replicati in almeno una regione remota, gli oggetti vengono archiviati in modo ridondante tra le regioni. Questo approccio offre ai dati nei bucket a due e più regioni un set di protezioni più ampio rispetto a quello ottenuto con l'archiviazione regionale.

I bucket a livello di regione sono progettati per essere resilienti in caso di interruzione in una singola zona di disponibilità. Se si verifica un'interruzione in una zona, gli oggetti al suo interno vengono forniti automaticamente e in modo trasparente da qualsiasi punto della regione. I dati e i metadati vengono archiviati in modo ridondante nelle varie zone, a partire dalla scrittura iniziale. Nessuna scrittura viene persa se una zona non è più disponibile. In caso di interruzione a livello di regione, i bucket a livello di regione in quella regione sono offline finché la regione non torna disponibile.

Se hai bisogno di una maggiore disponibilità, puoi archiviare i dati in una configurazione a due o più regioni. I bucket per due o più regioni sono bucket singoli (senza località principali e secondarie separate), ma archiviano dati e metadati in modo ridondante tra le regioni. In caso di interruzione a livello di regione, il servizio non viene interrotto. I bucket a due e più regioni possono essere considerati attivi-attivi, in quanto puoi leggere e scrivere carichi di lavoro in più di una regione contemporaneamente mentre il bucket rimane a elevata coerenza. Questo può essere particolarmente interessante per i clienti che vogliono suddividere il carico di lavoro tra due regioni nell'ambito di un'architettura di ripristino di emergenza.

Le due regioni e le regioni multiple sono a elevata coerenza perché i metadati sono sempre scritti in modo sincrono tra le regioni. Questo approccio consente al servizio di determinare sempre qual è la versione più recente di un oggetto e da dove può essere pubblicata, incluse le regioni remote.

I dati vengono replicati in modo asincrono. Ciò significa che esiste una finestra temporale RPO in cui gli oggetti appena scritti vengono inizialmente protetti come oggetti a livello di regione, con ridondanza nelle zone di disponibilità all'interno di una singola regione. Il servizio replica quindi gli oggetti all'interno della finestra RPO in una o più regioni remote per renderli con ridondanza geografica. Al termine della replica, i dati possono essere forniti automaticamente e in modo trasparente da un'altra regione in caso di interruzione a livello di regione. La replica turbo è una funzionalità premium disponibile su un bucket a due regioni per ottenere una finestra RPO più piccola, che ha come target il 100% degli oggetti appena scritti che vengono replicati e resi geo-ridondanti entro 15 minuti.

L'RPO è una considerazione importante perché, durante un'interruzione a livello di regione, i dati scritti recentemente nella regione interessata all'interno della finestra RPO potrebbero non essere ancora stati replicati in altre regioni. Di conseguenza, questi dati potrebbero non essere accessibili durante l'interruzione e potrebbero andare persi in caso di distruzione fisica dei dati nella regione interessata.

Cloud Translation

Cloud Translation ha server di computing attivi in più zone e regioni. Supporta inoltre la replica sincrona dei dati tra zone all'interno delle regioni. Queste funzionalità aiutano Translation a ottenere un failover immediato senza alcuna perdita di dati in caso di errori a livello di zona e senza richiedere input o aggiustamenti da parte del cliente. In caso di errore a livello di regione, Cloud Translation non è disponibile.

Compute Engine

Compute Engine è una delle opzioni Infrastructure as a Service di Google Cloud. Utilizza l'infrastruttura globale di Google per offrire macchine virtuali (e i servizi correlati) ai clienti.

Le istanze di Compute Engine sono risorse di zona quindi, in caso di interruzione di una zona, le istanze non sono disponibili per impostazione predefinita. Compute Engine offre gruppi di istanze gestite (MIG) che possono fare automaticamente lo scale up di VM aggiuntive da modelli di istanze preconfigurati, sia all'interno di una singola zona che in 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 richiedono configurazione e pianificazione delle risorse. È possibile utilizzare più gruppi di istanze gestite a livello di regione per ottenere la resilienza delle interruzioni a livello di regione per le applicazioni stateless.

Le applicazioni con carichi di lavoro stateful possono comunque utilizzare MIG stateful, ma è necessaria un'attenzione particolare nella pianificazione della capacità poiché non scalano orizzontalmente. In entrambi gli scenari, è importante configurare e testare in anticipo i modelli di istanza Compute Engine e i gruppi di istanze gestite in modo corretto per garantire che le funzionalità di failover siano attive in altre zone. Per ulteriori informazioni, consulta la sezione Sviluppare architetture e guide di riferimento personalizzate in alto.

Single-tenancy

Single-tenancy ti consente di avere accesso esclusivo a un nodo single-tenant, ovvero un server fisico Compute Engine dedicato all'hosting solo delle VM del tuo progetto.

I nodi single-tenant, come le istanze di Compute Engine, sono risorse di zona. Nel caso improbabile di un'interruzione a livello di zona, non saranno disponibili. Per mitigare i guasti a livello di zona, puoi creare un nodo single-tenant in un'altra zona. Dato che alcuni carichi di lavoro potrebbero trarre vantaggio dai nodi single-tenant per la licenza o la contabilità CapEx, è consigliabile pianificare in anticipo una strategia di failover.

Ricreare queste risorse in una località diversa potrebbe comportare costi aggiuntivi per la licenza o violare i requisiti contabili CAPEX. Per indicazioni generali, vedi Sviluppare architetture e guide di riferimento.

I nodi single-tenant sono risorse di zona e non possono tollerare errori a livello di regione. Per scalare tra zone, utilizza gruppi di istanze gestite a livello di regione.

Networking per Compute Engine

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

• Disponibilità del 99,99% per Dedicated Interconnect
• Disponibilità del 99,99% per Partner Interconnect

Puoi eseguire il provisioning di indirizzi IP esterni in modalità globale o a livello di regione, il che ne influisce sulla disponibilità se si verifica un errore a livello di regione.

Resilienza di Cloud Load Balancing

I bilanciatori del carico sono un componente fondamentale della maggior parte delle applicazioni ad alta disponibilità. È importante capire che la resilienza dell'applicazione complessiva dipende non solo dall'ambito del bilanciatore del carico scelto (globale o a livello di regione), ma anche dalla ridondanza dei servizi di backend.

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

Ambito del bilanciatore del carico	Architettura	Resistente alle interruzioni a livello di zona	Resistente all'interruzione regionale
Globale	Ogni bilanciatore del carico è distribuito in tutte le regioni
Tra regioni	Ogni bilanciatore del carico è distribuito in più regioni
Regionale	Ogni bilanciatore del carico è distribuito in più zone nella regione		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.

Connectivity Tests

Connectivity Tests è uno strumento di diagnostica che consente di verificare la connettività tra gli endpoint di rete. Analizza la configurazione e, in alcuni casi, esegue un'analisi del piano dati in tempo reale tra gli endpoint. Un endpoint è un'origine o una destinazione del traffico di rete, ad esempio una VM, un cluster Google Kubernetes Engine (GKE), una regola di forwarding del bilanciatore del carico o un indirizzo IP. Connectivity Tests è uno strumento di diagnostica senza componenti del piano dati. Non elabora né genera traffico di utenti.

Interruzione a livello di zona: le risorse di Connectivity Tests sono globali. Puoi gestirli e visualizzarli in caso di interruzione del servizio a livello di zona. Le risorse Connectivity Tests sono i risultati dei test di configurazione. Questi risultati potrebbero includere i dati di configurazione delle risorse di zona (ad esempio, istanze VM) in una zona interessata. In caso di interruzione, i risultati dell'analisi non sono accurati perché si basa su dati inattivi prima dell'interruzione. Non fare affidamento su questo.

Interruzione a livello di regione: in un'interruzione a livello di regione, puoi comunque gestire e visualizzare le risorse di Connectivity Tests. Le risorse di Connectivity Tests potrebbero includere dati di configurazione di risorse a livello di regione, ad esempio le subnet, in una regione interessata. In caso di interruzione, i risultati dell'analisi non sono accurati perché si basa su dati inattivi prima dell'interruzione. Non fare affidamento su questo.

Container Registry

Container Registry offre un'implementazione scalabile di Docker Registry che archivia in modo sicuro e privato le immagini container 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 regioni per impostazione predefinita. Le immagini container sono archiviate in bucket multiregionali di Cloud Storage. Con questa strategia di archiviazione, Container Registry offre resilienza in caso di interruzione a livello di zona, resilienza da interruzione a livello di regione per qualsiasi dato che è stato replicato in modo asincrono in più regioni da Cloud Storage.

Database Migration Service

Database Migration Service è un servizio Google Cloud completamente gestito per la migrazione dei database da altri cloud provider o dai data center on-premise a Google Cloud.

Database Migration Service è progettato come piano di controllo a livello di regione. Il piano di controllo non dipende da una singola zona in una determinata regione. Durante un'interruzione a livello di zona, manterrai l'accesso alle API Database Migration Service, inclusa la possibilità di creare e gestire i job di migrazione. Durante un'interruzione a livello di regione, perderai l'accesso alle risorse di Database Migration Service che appartengono a quella regione finché l'interruzione non viene risolta.

Database Migration Service dipende dalla disponibilità dei database di origine e di destinazione utilizzati per il processo di migrazione. Se un database di origine o di destinazione di Database Migration Service non è disponibile, l'avanzamento delle migrazioni viene interrotto, ma non vengono persi i dati principali del cliente o i dati del job. I job di migrazione riprendono quando i database di origine e di destinazione diventano di nuovo disponibili.

Ad esempio, puoi configurare un database Cloud SQL di destinazione con l'alta disponibilità abilitata per ottenere un database di destinazione resiliente alle interruzioni del servizio a livello di zona.

Le migrazioni di Database Migration Service passano attraverso due fasi:

• Dump completo: esegue una copia completa dei dati dall'origine alla destinazione in base alle specifiche del job di migrazione.
• Change Data Capture (CDC): replica le modifiche incrementali dall'origine alla destinazione.

Interruzione a livello di zona: se si verifica un errore a livello di zona durante una di queste fasi, puoi comunque accedere alle risorse di Database Migration Service e gestirle. La migrazione dei dati è interessata come segue:

• Dump completo: la migrazione dei dati non riesce. Devi riavviare il job di migrazione una volta che il database di destinazione ha completato l'operazione di failover.
• CDC: la migrazione dei dati è in pausa. Il job di migrazione riprende automaticamente quando il database di destinazione ha completato l'operazione.

Interruzione a livello di regione: Database Migration Service non supporta le risorse tra regioni, pertanto non è resiliente in caso di errori a livello di regione.

Dataflow

Dataflow è il servizio di elaborazione dei dati serverless e completamente gestito di Google Cloud per pipeline in modalità flusso e batch. Per impostazione predefinita, un endpoint a livello di regione configura il pool di worker Dataflow per utilizzare tutte le zone disponibili all'interno della regione. La selezione della zona viene calcolata per ogni worker nel momento in cui viene creato il worker, ottimizzando l'acquisizione di risorse e l'utilizzo delle prenotazioni inutilizzate. Nella configurazione predefinita per i job Dataflow, i dati intermedi vengono archiviati dal servizio Dataflow e lo stato del job è archiviato nel backend. In caso di errore di una zona, i job Dataflow possono continuare a essere eseguiti, perché i worker vengono creati nuovamente in altre zone.

Si applicano le seguenti limitazioni:

• Il posizionamento a livello di regione è supportato solo per i job che utilizzano Streaming Engine o Dataflow Shuffle. I job per cui è stato disattivato Streaming Engine o Dataflow Shuffle non possono utilizzare il posizionamento a livello di regione.
• Il posizionamento regionale si applica solo alle VM. Non si applica alle risorse correlate a Streaming Engine e Dataflow Shuffle.
• Le VM non vengono replicate in più zone. Se una VM non è più disponibile, i suoi elementi di lavoro vengono considerati persi e vengono rielaborati da un'altra VM.
• Se si verifica uno stock di esaurimento a livello di regione, il servizio Dataflow non può creare altre VM.

Architettura di pipeline Dataflow per l'alta disponibilità

Puoi eseguire più pipeline di flusso in parallelo per l'elaborazione dei dati ad alta disponibilità. Ad esempio, puoi eseguire due job di flussi di dati paralleli in regioni diverse. L'esecuzione di pipeline parallele offre ridondanza geografica e tolleranza di errore per l'elaborazione dei dati. Considerando la disponibilità geografica di origini dati e sink, puoi operare le pipeline end-to-end in una configurazione multiregionale ad alta disponibilità. Per ulteriori informazioni, consulta Alta disponibilità e ridondanza geografica in "Progettare flussi di lavoro della pipeline Dataflow".

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. Per garantire che i record non vengano persi durante lo shuffling, Dataflow utilizza il backup upstream, il che significa che il worker che invia i record ritenta gli RPC finché non riceve una conferma positiva della ricezione del record e che gli effetti collaterali dell'elaborazione del record vengono impegnati nello spazio di archiviazione permanente a valle. Dataflow continua anche a riprovare le RPC se il worker che invia i record non è disponibile. I nuovi tentativi delle RPC assicurano che ogni record venga consegnato esattamente una volta. Per ulteriori informazioni sulla garanzia "exactly-once" di Dataflow, consulta exactly-once in Dataflow.

Se la pipeline utilizza il raggruppamento o il time-windowing, puoi utilizzare la funzionalità Seek di Pub/Sub o Replay di Kafka dopo un'interruzione a livello di zona o di regione per rielaborare gli elementi di dati e ottenere gli stessi risultati di calcolo. Se la logica di business utilizzata dalla pipeline non si basa sui dati prima dell'interruzione, la perdita di dati negli output della pipeline può essere ridotta al minimo a 0 elementi. Se la logica di business della pipeline si basa su dati elaborati prima dell'interruzione (ad esempio, se vengono utilizzate lunghe finestre scorrevoli o se una finestra temporale globale memorizza i contatori in costante aumento), utilizza gli snapshot di Dataflow per salvare lo stato della pipeline in modalità flusso e avviare una nuova versione del job senza perdere lo stato.

Dataproc

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

Puoi creare cluster Dataproc su:

• Cluster Dataproc su Compute Engine
• Cluster Dataproc su GKE

Cluster Dataproc su Compute Engine

Poiché un cluster Dataproc su Compute Engine è una risorsa di zona, un'interruzione a livello di zona rende il cluster non disponibile o elimina il cluster. Dataproc non crea automaticamente snapshot dello stato del cluster, pertanto un'interruzione di una zona potrebbe causare la perdita dei dati elaborati. Dataproc non conserva i dati utente all'interno del servizio. Gli utenti possono configurare le pipeline in modo da scrivere risultati in molti datastore. Dovresti considerare l'architettura del datastore e scegliere un prodotto che offra la resilienza alle emergenze necessaria.

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. Una volta che il cluster è disponibile, l'elaborazione dei dati può riprendere. Puoi anche eseguire un cluster con la modalità ad alta disponibilità abilitata, riducendo la probabilità che un'interruzione parziale della zona abbia un impatto su un nodo master e, di conseguenza, sull'intero cluster.

Cluster Dataproc su GKE

I cluster Dataproc su GKE possono essere a livello di zona o di regione.

Per ulteriori informazioni sull'architettura e sulle funzionalità di RE dei cluster GKE a livello di zona e di regione, consulta la sezione su Google Kubernetes Engine più avanti in questo documento.

Document AI

Document AI è una piattaforma di comprensione dei documenti che prende i dati non strutturati dai documenti e li trasforma in dati strutturati, semplificando la comprensione, l'analisi e l'utilizzo. Document AI è un'offerta regionale. I clienti possono scegliere la regione, ma non le zone al suo interno. I dati e il traffico vengono automaticamente bilanciati del carico tra le zone all'interno di una regione. I server vengono scalati automaticamente per soddisfare il traffico in entrata e bilanciato il carico tra le zone, se necessario. Ogni zona gestisce uno scheduler che fornisce questa scalabilità automatica per zona. Lo scheduler è inoltre consapevole del carico ricevuto dalle altre zone e fornisce ulteriore capacità nella zona per consentire eventuali errori a livello di zona.

Interruzione a livello di zona: Document AI archivia i documenti utente e i dati sulle versioni del processore. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. Poiché i dati vengono archiviati a livello di regione, le operazioni del piano dati non sono interessate da errori a livello di zona. Il traffico viene instradato automaticamente ad altre zone in caso di errore a livello di zona, con un ritardo basato sul tempo necessario per il ripristino dei servizi dipendenti, come Vertex AI.

Interruzione a livello di regione: i dati non vengono mai replicati tra regioni. Durante un'interruzione regionale, Document AI non eseguirà il failover. I clienti scelgono la regione Google Cloud in cui vogliono utilizzare Document AI. Tuttavia, il traffico dei clienti non viene mai instradato a un'altra regione.

Verifica degli endpoint

La verifica degli endpoint consente agli amministratori e ai professionisti delle operazioni di sicurezza di creare un inventario dei dispositivi che accedono ai dati di un'organizzazione. La verifica degli endpoint fornisce inoltre un'affidabilità critica dei dispositivi e controllo dell'accesso basato sulla sicurezza come parte della soluzione Chrome Enterprise Premium.

Utilizza Verifica degli endpoint per avere una panoramica del livello di sicurezza dei dispositivi laptop e desktop della tua organizzazione. Quando la verifica degli endpoint viene abbinata alle offerte Chrome Enterprise Premium, la verifica degli endpoint consente di applicare controllo dell'accesso granulare alle risorse Google Cloud.

La verifica degli endpoint è disponibile per Google Cloud, Cloud Identity, Google Workspace Business e Google Workspace Enterprise.

Eventarc

Eventarc fornisce eventi distribuiti in modo asincrono da provider Google (proprietari), app utente (di terze parti) e Software as a Service (di terze parti) utilizzando servizi a basso accoppiamento che reagiscono ai cambiamenti di stato. Consente ai clienti di configurare le destinazioni (ad esempio, un'istanza Cloud Run o una Cloud Function di 2ª generazione) da attivare quando si verifica un evento in un servizio del provider di eventi o nel codice del cliente.

Interruzione a livello di zona: Eventarc archivia i metadati relativi ai trigger. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. L'API Eventarc che crea e gestisce trigger e canali restituisce la chiamata API solo quando i dati sono stati impegnati per un quorum all'interno di una regione. Poiché i dati sono archiviati a livello di regione, le operazioni del piano dati non sono interessate da errori a livello di zona. In caso di errore a livello di zona, il traffico viene instradato automaticamente ad altre zone. I servizi Eventarc per la ricezione e la distribuzione di eventi di seconda parte e di terze parti vengono replicati nelle zone. Questi servizi sono distribuiti a livello di regione. Le richieste a zone non disponibili vengono gestite automaticamente dalle zone disponibili nella regione.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui vogliono creare i propri trigger Eventarc. I dati non vengono mai replicati tra regioni diverse. Il traffico dei clienti non viene mai instradato da Eventarc a una regione diversa. In caso di errore a livello di regione, Eventarc diventa di nuovo disponibile non appena l'interruzione viene risolta. Per ottenere una disponibilità maggiore, invitiamo i clienti a eseguire il deployment dei trigger in più regioni, se vogliono.

Tieni presente quanto segue:

• I servizi Eventarc per la ricezione e l'erogazione di eventi proprietari vengono forniti secondo il criterio del "best effort" e non sono coperti da RTO/RPO.
• La distribuzione di eventi Eventarc per i servizi Google Kubernetes Engine viene fornita secondo il criterio del "best effort" e non è coperta da RTO/RPO.

Filestore

I livelli Basic e HighScale sono risorse a livello di zona. Non tollerano i guasti della zona o della regione di cui è stato eseguito il deployment.

Le istanze Filestore di livello Enterprise sono risorse a livello di regione. Filestore adotta i criteri di coerenza rigorosa richiesti da NFS. Quando un client scrive dati, Filestore non restituisce un riscontro finché la modifica non viene resa persistente e replicata in due zone, in modo che le letture successive restituiscano i dati corretti.

In caso di errore di una zona, un'istanza di livello Enterprise continua a gestire i dati di altre zone e nel frattempo accetta nuove scritture. Le prestazioni delle operazioni di lettura e scrittura potrebbero essere ridotte; l'operazione di scrittura potrebbe non essere replicata. La crittografia non è compromessa perché la chiave verrà gestita da altre zone.

Consigliamo ai client di creare backup esterni in caso di ulteriori interruzioni in altre zone della stessa regione. Puoi usare il backup per ripristinare l'istanza in altre regioni.

Firestore

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

Firestore offre ai clienti località a singola regione e a più regioni. Il traffico viene automaticamente bilanciato del carico tra le zone di una regione.

Le istanze Firestore regionali replicano in modo sincrono i dati in 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 di cui è stato eseguito il commit rimangono permanenti. Il traffico viene instradato automaticamente ad altre zone. Una località a singola regione offre costi inferiori, minore latenza di scrittura e colocation con altre risorse di Google Cloud.

Le istanze multiregionali di Firestore replicano in modo sincrono i dati in cinque zone in tre regioni (due regioni di gestione e una regione di testimonianza) e sono resistenti agli errori di zona e di regione. In caso di errore a livello di zona o di regione, i dati di commit vengono mantenuti. Il traffico viene instradato automaticamente a zone/regioni di gestione e i commit vengono comunque gestiti da almeno tre zone nelle due regioni rimanenti. Le regioni multiple massimizzano la disponibilità e la durabilità dei database.

Firewall Insights

Firewall Insights ti aiuta a comprendere e ottimizzare le tue regole firewall. Fornisce insight, suggerimenti e metriche sull'utilizzo delle regole firewall. Firewall Insights usa il machine learning per prevedere l'uso futuro delle regole. Firewall Insights consente di prendere decisioni migliori durante l'ottimizzazione delle regole firewall. Ad esempio, Firewall Insights identifica le regole che classifica come eccessivamente permissive. Puoi utilizzare queste informazioni per rendere più restrittiva la configurazione del firewall.

Interruzione a livello di zona: poiché i dati di Firewall Insights vengono replicati tra le zone, non sono interessati da un'interruzione a livello di zona e il traffico dei clienti viene instradato automaticamente ad altre zone.

Interruzione a livello di regione: poiché i dati di Firewall Insights vengono replicati in più regioni, non sono interessati da un'interruzione a livello di regione e il traffico dei clienti viene instradato automaticamente ad altre regioni.

Parco risorse

I parchi risorse consentono ai clienti di gestire più cluster Kubernetes come gruppo e consentono agli amministratori di piattaforma di utilizzare servizi multi-cluster. Ad esempio, i parchi risorse consentono agli amministratori di applicare criteri uniformi a tutti i cluster o di configurare Ingress multi-cluster.

Quando registri un cluster GKE in un parco risorse, per impostazione predefinita il cluster ha un'appartenenza a livello di regione nella stessa regione. Quando registri un cluster non Google Cloud in un parco risorse, puoi scegliere qualsiasi regione o località globale. La best practice consiste nello scegliere una regione vicina alla località fisica del cluster. Ciò fornisce una latenza ottimale quando utilizzi Connetti il gateway per accedere al cluster.

In caso di interruzione a livello di zona, le funzionalità del parco risorse non sono interessate, a meno che il cluster sottostante non sia di zona e diventi non disponibile.

In caso di interruzione a livello di regione, le funzionalità del parco risorse non funzionano in modo statico per i cluster di appartenenza alla regione. La mitigazione di un'interruzione a livello di regione richiede il deployment in più regioni, come suggerito dall'architettura del ripristino di emergenza per le interruzioni dell'infrastruttura cloud.

Google Cloud Armor

Google Cloud Armor ti aiuta a proteggere i tuoi deployment e le tue applicazioni da diversi tipi di minacce, tra cui attacchi DDoS volumetrici e attacchi alle applicazioni come cross-site scripting (XSS) e SQL injection. Google Cloud Armor filtra il traffico indesiderato presso i bilanciatori del carico Google Cloud e impedisce che questo traffico entri nel VPC e utilizzi risorse. Alcune di queste protezioni sono automatiche. Alcune richiedono la configurazione dei criteri di sicurezza e il loro collegamento a servizi di backend o regioni. I criteri di sicurezza di Google Cloud Armor con ambito globale vengono applicati ai bilanciatori del carico globali. I criteri di sicurezza con ambito regionale vengono applicati ai bilanciatori del carico regionali.

Interruzione a livello di zona: in caso di interruzione a livello di zona, i bilanciatori del carico Google Cloud reindirizzano il traffico ad altre zone in cui sono disponibili istanze di backend integre. La protezione di Google Cloud Armor è disponibile immediatamente dopo il failover del traffico perché i criteri di sicurezza di Google Cloud Armor vengono replicati in modo sincrono in tutte le zone di una regione.

Interruzione a livello di regione: in caso di interruzioni a livello di regione, i bilanciatori del carico Google Cloud globali reindirizzano il traffico ad altre regioni in cui sono disponibili istanze di backend integre. La protezione di Google Cloud Armor è disponibile immediatamente dopo il failover del traffico perché i criteri di sicurezza globali di Google Cloud Armor vengono replicati in modo sincrono in tutte le regioni. Per garantire la resilienza in caso di errori a livello di regione, devi configurare i criteri di sicurezza regionali di Google Cloud Armor per tutte le tue regioni.

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 di cluster a livello di regione o zona.

• Durante la creazione di un cluster di zona, GKE esegue il provisioning di una macchina del piano di controllo nella zona scelta, oltre alle macchine worker (nodi) all'interno della stessa zona.
• Per i cluster regionali, GKE esegue il provisioning di tre macchine del piano di controllo in tre diverse zone all'interno della regione scelta. Per impostazione predefinita, i nodi sono inoltre distribuiti in tre zone, ma puoi scegliere di creare un cluster a livello di regione con nodi di cui è stato eseguito il provisioning solo in una zona.
• I cluster multi-zona sono simili ai cluster di zona in quanto includono una macchina master, ma offrono anche la possibilità di abbracciare i nodi in più zone.

Interruzione a livello di zona: per evitare interruzioni a livello di zona, utilizza i cluster a livello di regione. Il piano di controllo e i nodi sono distribuiti in tre zone diverse all'interno di una regione. Un'interruzione in 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 regione: la mitigazione di un'interruzione a livello di regione richiede il deployment in più regioni. Sebbene al momento non sia offerta come funzionalità di prodotto integrata, la topologia multiregionale è un approccio adottato oggi da diversi clienti GKE e può essere implementata manualmente. Puoi creare più cluster a livello di regione per replicare i carichi di lavoro in più regioni e controllare il traffico verso questi cluster utilizzando Ingress multi-cluster.

VPN ad alta disponibilità

La VPN ad alta disponibilità (alta disponibilità) è un'offerta Cloud VPN resiliente che cripta in modo sicuro il traffico dal cloud privato on-premise, da un altro virtual private cloud o da un altro provider di servizi cloud alla rete VPC 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 logicamente che fisicamente tra diversi PoP e cluster, per garantire una ridondanza ottimale.

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

Interruzione a livello di regione: in caso di interruzione a livello di regione, entrambe le interfacce potrebbero perdere la connettività per un breve periodo.

Identity and Access Management

Identity and Access Management (IAM) è responsabile di tutte le decisioni di autorizzazione per le azioni sulle risorse cloud. IAM conferma che un criterio concede l'autorizzazione per ogni azione (nel piano dati) ed elabora gli aggiornamenti di questi criteri tramite una chiamata SetPolicy (nel piano di controllo).

Tutti i criteri IAM vengono replicati in più zone all'interno di ogni regione, aiutando le operazioni del piano dati IAM a recuperare gli errori di altre regioni e tollerando gli errori di zona all'interno di ogni regione. La resilienza del piano dati IAM contro gli errori delle zone e degli errori a livello di regione consente architetture multiregionali e multizona per una disponibilità elevata.

Le operazioni del piano di controllo IAM possono dipendere dalla replica tra regioni. Quando le chiamate SetPolicy hanno esito positivo, i dati sono stati scritti in più regioni, ma la propagazione in altre regioni è alla fine coerente. Il piano di controllo IAM è resiliente agli errori a livello di una singola regione.

Identity-Aware Proxy

Identity-Aware Proxy fornisce l'accesso alle applicazioni ospitate su Google Cloud, su altri cloud e on-premise. IAP viene distribuito a livello di regione e le richieste alle zone non disponibili vengono gestite automaticamente da altre zone disponibili nella regione.

Le interruzioni regionali in IAP influiscono sull'accesso alle applicazioni ospitate nella regione interessata. Ti consigliamo di eseguire il deployment in più regioni e di utilizzare Cloud Load Balancing per ottenere disponibilità e resilienza maggiori contro le interruzioni regionali.

Identity Platform

Identity Platform consente ai clienti di aggiungere alle proprie app la gestione personalizzabile di identità e accessi di livello Google. Identity Platform è un'offerta globale. I clienti non possono scegliere le regioni o le zone in cui sono archiviati i loro dati.

Interruzione di zona: durante un'interruzione a livello di zona, Identity Platform esegue il failover delle richieste alla cella più vicina successiva. Tutti i dati vengono salvati su scala globale, quindi non c'è perdita di dati.

Interruzione a livello di regione:durante un'interruzione a livello di regione, le richieste di Identity Platform alla regione non disponibile non vanno a buon fine, mentre Identity Platform rimuove il traffico dalla regione interessata. Quando il traffico verso la regione interessata è esaurito, un servizio di bilanciamento del carico del server globale instrada le richieste alla regione integro più vicino disponibile. Tutti i dati vengono salvati a livello globale, quindi non c'è perdita di dati.

Knative serving

Knative serving è un servizio globale che consente ai clienti di eseguire carichi di lavoro serverless sui cluster dei clienti. Il suo scopo è garantire che il deployment dei carichi di lavoro di Knative serving venga eseguito correttamente sui cluster dei clienti e che lo stato di installazione di Knative serving si rifletta nella risorsa delle funzionalità dell'API GKE Fleet. Questo servizio è attivo solo durante l'installazione o l'upgrade delle risorse Knative serving sui cluster dei clienti. Non è coinvolto nell'esecuzione dei carichi di lavoro dei cluster. I cluster di clienti appartenenti a progetti in cui è abilitato Knative serving sono distribuiti tra repliche in più regioni e zone: ciascun cluster è monitorato da una replica.

Interruzione a livello di zona e di regione: i cluster monitorati da repliche ospitate in una località in fase di interruzione, vengono ridistribuiti automaticamente tra repliche integre in altre zone e regioni. Mentre la riassegnazione è in corso, potrebbe verificarsi un breve periodo di tempo in cui alcuni cluster non sono monitorati da Knative serving. Se durante questo periodo l'utente decide di abilitare le funzionalità di Knative serving nel cluster, l'installazione delle risorse di Knative serving nel cluster inizierà dopo la riconnessione del cluster con una replica del servizio Knative serving integro.

Looker (Google Cloud core)

Looker (Google Cloud core) è una piattaforma di business intelligence che fornisce provisioning, configurazione e gestione semplificati e semplificati di un'istanza Looker dalla console Google Cloud. Looker (Google Cloud core) consente agli utenti di esplorare i dati, creare dashboard, configurare avvisi e condividere report. Inoltre, Looker (Google Cloud core) offre un IDE per i creatori di modelli di dati e funzionalità avanzate di incorporamento e API per gli sviluppatori.

Looker (Google Cloud core) è composto da istanze isolate a livello di regione che replicano in modo sincrono i dati tra zone all'interno della regione. Assicurati che le risorse utilizzate dall'istanza, ad esempio le origini dati a cui si connette Looker (Google Cloud core), si trovino nella stessa regione in cui viene eseguita l'istanza.

Interruzione a livello di zona: le istanze di Looker (Google Cloud core) archiviano i metadati e i container di cui è stato eseguito il deployment. I dati sono scritti in modo sincrono nelle istanze replicate. In un'interruzione a livello di zona, le istanze di Looker (Google Cloud core) continuano a gestire da altre zone disponibili nella stessa regione. Eventuali transazioni o chiamate API vengono restituite dopo che i dati sono stati impegnati per raggiungere un quorum all'interno di una regione. Se la replica non riesce, il commit della transazione non viene eseguito e l'utente viene avvisato dell'errore. Se in più di una zona si verifica un errore, anche le transazioni non vanno a buon fine e l'utente viene avvisato. Looker (Google Cloud core) interrompe le pianificazioni o le query attualmente in esecuzione. Una volta risolto l'errore, dovrai riprogrammarlo o metterlo in coda.

Interruzione a livello di regione: le istanze di Looker (Google Cloud core) nella regione interessata non sono disponibili. Looker (Google Cloud core) interrompe le pianificazioni o le query attualmente in esecuzione. Dopo aver risolto l'errore, devi riprogrammare o inserire di nuovo in coda le query. Puoi creare manualmente nuove istanze in un'altra regione. Puoi anche ripristinare le istanze utilizzando il processo definito in Importare o esportare dati da un'istanza di Looker (Google Cloud core). Ti consigliamo di configurare un processo periodico di esportazione dei dati per copiare gli asset in anticipo, nell'improbabile caso di interruzione del servizio a livello di regione.

Looker Studio

Looker Studio è un prodotto di visualizzazione dei dati e business intelligence. Consente ai clienti di connettersi ai dati archiviati in altri sistemi, creare report e dashboard utilizzando questi dati e condividere report e dashboard in tutta l'organizzazione. Looker Studio è un servizio globale e non consente agli utenti di selezionare un ambito delle risorse.

In caso di interruzione a livello di zona, Looker Studio continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni. Gli asset utente vengono replicati in modo sincrono tra le regioni. Pertanto, non si verificano perdite di dati.

In caso di interruzione a livello di regione, Looker Studio continua a gestire le richieste da un'altra regione senza interruzioni. Gli asset utente sono replicati in modo sincrono tra le regioni. Pertanto, non si verificano perdite di dati.

Memorystore for Memcached

Memorystore for Memcached è l'offerta Memcached gestita di Google Cloud. Memorystore for Memcached consente ai clienti di creare cluster Memcached da utilizzare come database a velocità effettiva elevata e valore-chiave per le applicazioni.

I cluster Memcached sono a livello di regione, con nodi distribuiti in tutte le zone specificate dal cliente. Tuttavia, Memcached non replica alcun dato tra i nodi. Pertanto, un errore a livello di zona può causare la perdita di dati, operazione descritta anche come svuotamento parziale della cache. Le istanze Memcached continueranno a funzionare, ma avranno meno nodi: il servizio non avvierà nessun nuovo nodo in caso di errore di zona. I nodi Memcached nelle zone non interessate continueranno a gestire il traffico, anche se l'errore a livello di zona determinerà una percentuale di successo della cache inferiore fino al recupero della zona.

In caso di errore a livello di regione, i nodi Memcached non gestiscono il traffico. In questo caso, i dati andranno persi e questo comporterà uno svuotamento completo della cache. Per mitigare un'interruzione del servizio a livello di regione, puoi implementare un'architettura che esegue il deployment dell'applicazione e di Memorystore for Memcached in più regioni.

Memorystore for Redis

Memorystore for Redis è un servizio Redis completamente gestito per Google Cloud in grado di ridurre il carico della gestione di deployment Redis complessi. Attualmente offre 2 livelli: livello base e standard. Per il livello base, un'interruzione a livello di zona o di regione causerà la perdita di dati, nota anche come svuotamento completo della cache. Per il livello Standard, un'interruzione a livello di regione comporterà la perdita di dati. Un'interruzione a livello di zona potrebbe causare una perdita parziale di dati per l'istanza del livello Standard a causa della replica asincrona.

Importante: affinché la replica funzioni in modo prevedibile, assicurati che l'utilizzo della CPU e il rapporto di utilizzo della memoria di sistema rimangano entro i valori suggeriti.

Interruzione a livello di zona: le istanze del livello Standard replicano in modo asincrono le operazioni del set di dati dal set di dati nel nodo primario al nodo di replica. In caso di interruzione all'interno della zona del nodo primario, il nodo di replica verrà promosso e diventerà il nodo primario. Durante la promozione si verifica un failover e il client Redis deve riconnettersi all'istanza. Dopo la riconnessione, le operazioni riprendono. Per ulteriori informazioni sull'alta disponibilità delle istanze Memorystore for Redis nel livello Standard, consulta la pagina relativa all'alta disponibilità di Memorystore for Redis.

Se abiliti le repliche di lettura nell'istanza di livello Standard e hai una sola replica, l'endpoint di lettura non è disponibile per la durata di un'interruzione a livello di zona. Per maggiori informazioni sul ripristino di emergenza delle repliche di lettura, consulta Modalità di errore per le repliche di lettura.

Interruzione a livello di regione: Memorystore for Redis è un prodotto a livello di regione, perciò una singola istanza non è in grado di tollerare errori a livello di regione. In alternativa, puoi pianificare attività periodiche per esportare l'istanza Redis in un bucket Cloud Storage in un'altra regione. Quando si verifica un'interruzione a livello di regione, puoi ripristinare l'istanza Redis in una regione diversa dal set di dati che hai esportato.

Rilevamento servizi multi-cluster e Ingress multi-cluster

I servizi multi-cluster GKE sono costituiti da vari componenti. I componenti includono l'hub Google Kubernetes Engine (che orchestra più cluster Google Kubernetes Engine tramite le appartenenze), i cluster stessi e i controller dell'hub GKE (Ingress multi-cluster, rilevamento dei servizi multi-cluster). I controller dell'hub orchestrano la configurazione del bilanciatore del carico di Compute Engine utilizzando backend su più cluster.

In caso di interruzione a livello di zona, Multi-Cluster Service Discovery continua a gestire le richieste da un'altra zona o regione. In caso di interruzione a livello di regione, il failover dei servizi multi-cluster non viene eseguito.

In caso di interruzione di Ingress multi-cluster a livello di zona, se il cluster di configurazione è a livello di zona e rientra nell'ambito dell'errore, l'utente deve eseguire manualmente il failover. Il piano dati è statico e continuerà a gestire il traffico finché l'utente non avrà eseguito il failover. Per evitare il failover manuale, utilizza un cluster a livello di regione per il cluster di configurazione.

In caso di interruzione a livello di regione, Ingress multi-cluster non esegue il failover. Gli utenti devono disporre di un piano di RE per il failover manuale del cluster di configurazione. Per ulteriori informazioni, consulta Configurazione di Ingress multi-cluster e Configurazione di servizi multi-cluster.

Per ulteriori informazioni su GKE, consulta la sezione "Google Kubernetes Engine" in Architettura del ripristino di emergenza per interruzioni dell'infrastruttura cloud.

Network Analyzer

Network Analyzer monitora automaticamente le configurazioni di rete VPC e rileva le configurazioni errate e non ottimali. Fornisce insight su topologia di rete, regole firewall, route, dipendenze di configurazione e connettività a servizi e applicazioni. Identifica gli errori di rete, fornisce informazioni sulle cause principali e suggerisce possibili risoluzioni.

Network Analyzer è in esecuzione continua e attiva le analisi pertinenti in base agli aggiornamenti della configurazione quasi in tempo reale nella tua rete. Se Network Analyzer rileva un errore di rete, prova a correlarlo con le recenti modifiche alla configurazione per identificare le cause principali. Ove possibile, fornisce consigli per suggerire dettagli su come risolvere i problemi.

Network Analyzer è uno strumento di diagnostica senza componenti del piano dati. Non elabora né genera traffico di utenti.

Interruzione a livello di zona: il servizio Network Analyzer viene replicato a livello globale e la sua disponibilità non è influenzata da un'interruzione a livello di zona.

Se gli insight di Network Analyzer contengono configurazioni di una zona che subisce un'interruzione, la qualità dei dati influisce sulla qualità dei dati. Gli insight sulla rete che fanno riferimento alle configurazioni in quella zona diventano inattivi. Non fare affidamento sugli insight forniti da Network Analyzer durante le interruzioni.

Interruzione a livello di regione: il servizio Network Analyzer viene replicato a livello globale e la sua disponibilità non è influenzata da un'interruzione a livello di regione.

Se gli insight di Network Analyzer contengono configurazioni di una regione soggetta a interruzione, la qualità dei dati influisce sulla qualità dei dati. Gli insight sulla rete che fanno riferimento alle configurazioni in quella regione diventano inattivi. Non fare affidamento sugli insight forniti da Network Analyzer durante le interruzioni.

Network Topology

Network Topology è uno strumento di visualizzazione che mostra la topologia dell'infrastruttura di rete. La visualizzazione Infrastruttura mostra le reti Virtual Private Cloud (VPC), la connettività ibrida da e verso le reti on-premise, la connettività ai servizi gestiti da Google e le metriche associate.

Interruzione a livello di zona: in caso di interruzione a livello di zona, i relativi dati non verranno visualizzati in Network Topology. I dati relativi alle altre zone non sono interessati.

Interruzione a livello di regione: in caso di interruzione a livello di regione, i dati per quella regione non verranno mostrati in Network Topology. I dati relativi ad altre regioni non sono interessati.

Performance Dashboard

Performance Dashboard ti offre visibilità sulle prestazioni dell'intera rete Google Cloud e delle risorse del tuo progetto.

Con queste funzionalità di monitoraggio delle prestazioni, puoi distinguere un problema nella tua applicazione da uno nella rete Google Cloud sottostante. Puoi anche analizzare i problemi storici di prestazioni della rete. Performance Dashboard esporta anche i dati in Cloud Monitoring. Puoi utilizzare Monitoring per eseguire query sui dati e ottenere l'accesso a informazioni aggiuntive.

Interruzione a livello di zona:

In caso di interruzione a livello di zona, i dati relativi a latenza e perdita di pacchetti relativi al traffico proveniente dalla zona interessata non verranno visualizzati in Performance Dashboard. I dati sulla latenza e sulla perdita di pacchetti per il traffico proveniente da altre zone non sono interessati. Al termine dell'interruzione, i dati di latenza e perdita di pacchetti riprenderanno.

Interruzione a livello di regione:

In caso di interruzione a livello di regione, i dati relativi a latenza e perdita di pacchetti relativi al traffico dalla regione interessata non verranno visualizzati in Performance Dashboard. I dati sulla latenza e sulla perdita di pacchetti per il traffico proveniente da altre regioni non sono interessati. Al termine dell'interruzione, i dati di latenza e perdita di pacchetti riprenderanno.

Network Connectivity Center

Network Connectivity Center è un prodotto per la gestione della connettività di rete che utilizza un'architettura hub e spoke. Con questa architettura, una risorsa di gestione centrale funge da hub e ogni risorsa di connettività funge da spoke. Attualmente gli spoke ibridi supportano VPN ad alta disponibilità, Dedicated and Partner Interconnect e appliance router SD-WAN dei principali fornitori di terze parti. Con gli spoke ibridi di Network Connectivity Center, le aziende possono connettere carichi di lavoro e servizi Google Cloud a data center on-premise, altri cloud e alle loro filiali attraverso la portata globale della rete Google Cloud.

Interruzione a livello di zona: uno spoke ibrido di Network Connectivity Center con configurazione ad alta disponibilità è 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 regione: uno spoke ibrido di Network Connectivity Center è una risorsa di regione, quindi non può resistere a un errore a livello di regione.

Network Service Tiers

Network Service Tiers ti consente di ottimizzare la connettività tra i sistemi su internet e le tue istanze Google Cloud. Offre due livelli di servizio distinti: il livello Premium e il livello Standard. Con il livello Premium, un indirizzo IP del livello Premium anycast annunciato a livello globale può fungere da frontend per i backend regionali o globali. Con il livello Standard, può essere utilizzato da frontend per i backend regionali un indirizzo IP del livello Standard annunciato a livello regionale. La resilienza complessiva di un'applicazione è influenzata sia dal livello di servizio di rete sia dalla ridondanza dei backend a cui è associata.

Interruzione a livello di zona: sia il livello Premium che il livello Standard offrono resilienza alle interruzioni a livello di zona quando sono associati a backend ridondanti a livello regionale. Quando si verifica un'interruzione a livello di zona, il comportamento di failover per i casi che utilizzano backend ridondanti a livello di regione è determinato dai backend associati stessi. Se associato a backend di zona, il servizio sarà di nuovo disponibile non appena l'interruzione verrà risolta.

Interruzione a livello di regione: il livello Premium offre resilienza contro le interruzioni regionali quando è associato a backend ridondanti a livello globale. Nel livello Standard, tutto il traffico verso la regione interessata avrà esito negativo. Il traffico verso tutte le altre regioni non è interessato. Quando si verifica un'interruzione a livello di regione, il comportamento di failover per i casi che utilizzano il livello Premium con backend ridondanti a livello globale è determinato dai backend associati stessi. Quando utilizzi il livello Premium con backend regionali o il livello Standard, il servizio diventerà di nuovo disponibile non appena l'interruzione verrà risolta.

Mirroring pacchetto

Mirroring pacchetto clona il traffico delle istanze specificate nella rete Virtual Private Cloud (VPC) e inoltra i dati clonati alle istanze dietro un bilanciatore del carico interno a livello di regione per l'analisi. Mirroring pacchetto acquisisce tutto il traffico e i dati dei pacchetti, inclusi payload e intestazioni.

Per ulteriori informazioni sulla funzionalità del servizio Mirroring pacchetto, consulta la pagina di riepilogo del servizio Mirroring pacchetto.

Interruzione a livello di zona: configura il bilanciatore del carico interno in modo che ci siano istanze in più zone. Se si verifica un'interruzione a livello di zona, il mirroring pacchetto devia i pacchetti clonati a una zona integro.

Interruzione a livello di regione: il mirroring pacchetto è un prodotto a livello di regione. In caso di interruzione a livello di regione, i pacchetti nella regione interessata non vengono clonati.

Persistent Disk

I dischi permanenti sono disponibili in configurazioni a livello di zona e di regione.

I dischi permanenti a livello di zona sono ospitati in un'unica zona. Se la zona del disco non è disponibile, il Persistent Disk non sarà disponibile fino a quando l'interruzione della zona non viene risolta.

I dischi permanenti a livello di regione offrono la replica sincrona dei dati tra due zone di una regione. In caso di interruzione nella zona della macchina virtuale, puoi forzare il collegamento di un Persistent Disk a livello di regione a 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 hot standby in quella zona.

Personalized Service Health

Personalized Service Health comunica le interruzioni dei servizi pertinenti ai tuoi progetti Google Cloud. Fornisce diversi canali e processi per visualizzare o integrare eventi di disturbo (incidenti, manutenzione pianificata) nel processo di risposta agli incidenti, tra cui:

• Una dashboard nella console Google Cloud
• Un'API di servizio
• Avvisi configurabili
• Log generati e inviati a Cloud Logging

Interruzione a livello di zona: i dati vengono forniti da un database globale senza alcuna dipendenza da località specifiche. Se si verifica un'interruzione a livello di zona, Service Health è in grado di gestire le richieste e reindirizzare automaticamente il traffico a zone della stessa regione ancora funzionanti. Service Health può restituire correttamente chiamate API se è in grado di recuperare i dati sugli eventi dal database Service Health.

Interruzione a livello di regione:i dati vengono forniti da un database globale senza alcuna dipendenza da località specifiche. In caso di interruzione a livello di regione, Service Health è comunque in grado di gestire le richieste, ma potrebbe operare con una capacità ridotta. Gli errori regionali nelle località di Logging potrebbero influire sugli utenti di Service Health che utilizzano i log o le notifiche di avviso su cloud.

Private Service Connect

Private Service Connect è una funzionalità di networking di Google Cloud che consente ai consumatori di accedere privatamente ai servizi gestiti dall'interno della rete VPC. Analogamente, consente ai producer di servizi gestiti di ospitare questi servizi nelle proprie reti VPC separate e di offrire una connessione privata ai consumer.

Endpoint Private Service Connect per i servizi pubblicati

Un endpoint Private Service Connect si connette ai servizi nella rete VPC dei producer di servizi utilizzando una regola di forwarding Private Service Connect. Il producer di servizi fornisce un servizio utilizzando la connettività privata a un consumer di servizi, esponendo un singolo collegamento al servizio. Il consumer di servizi potrà quindi assegnare un indirizzo IP virtuale dal proprio VPC.

Interruzione a livello di zona: il traffico di Private Service Connect proveniente dal traffico delle VM generato dagli endpoint client VPC consumer può comunque accedere a servizi gestiti esposti sulla rete VPC interna del producer di servizi. Questo accesso è possibile perché il failover del traffico di Private Service Connect esegue il failover su backend di servizio più integri in una zona diversa.

Interruzione a livello di regione: Private Service Connect è un prodotto a livello di regione. Non è resiliente alle interruzioni regionali. I servizi gestiti multiregionali possono raggiungere una disponibilità elevata durante le interruzioni di servizio a livello di regione configurando endpoint Private Service Connect in più regioni.

Endpoint Private Service Connect per le API di Google

Un endpoint Private Service Connect si connette alle API di Google utilizzando una regola di forwarding di Private Service Connect. Questa regola di forwarding consente ai clienti di utilizzare nomi personalizzati degli endpoint con i loro indirizzi IP interni.

Interruzione di zona: il traffico di Private Service Connect proveniente dagli endpoint client VPC consumer può comunque accedere alle API di Google perché la connettività tra la VM e l'endpoint eseguirà automaticamente il failover su un'altra zona funzionale nella stessa regione. Le richieste già in corso quando inizia un'interruzione dipendono dal timeout TCP del client e dal comportamento dei nuovi tentativi per il ripristino.

Consulta il ripristino di Compute Engine per ulteriori dettagli.

Interruzione a livello di regione: Private Service Connect è un prodotto a livello di regione. Non è resiliente alle interruzioni regionali. I servizi gestiti multiregionali possono raggiungere una disponibilità elevata durante le interruzioni di servizio a livello di regione configurando endpoint Private Service Connect in più regioni.

Per ulteriori informazioni su Private Service Connect, consulta la sezione "Endpoint" in Tipi di Private Service Connect.

Pub/Sub

Pub/Sub è un servizio di messaggistica per l'integrazione delle applicazioni e l'analisi dei flussi. Gli argomenti Pub/Sub sono globali, ovvero sono visibili e accessibili da qualsiasi località di Google Cloud. Tuttavia, ogni messaggio viene archiviato in un'unica regione Google Cloud, più vicina all'editore e consentito dal criterio di località delle risorse. Pertanto, i messaggi di un argomento potrebbero essere archiviati in regioni diverse in Google Cloud. Il criterio di archiviazione dei messaggi di Pub/Sub può limitare le regioni in cui vengono archiviati i messaggi.

Interruzione a livello di zona: quando un messaggio Pub/Sub viene pubblicato, viene scritto in modo sincrono nello spazio di archiviazione in almeno due zone all'interno della regione. Pertanto, se una singola zona non è più disponibile, non c'è alcun impatto visibile al cliente.

Interruzione a livello di regione: durante un'interruzione di una regione, i messaggi archiviati all'interno della regione interessata non sono accessibili. I publisher e gli abbonati che si connetterebbero alla regione interessata, tramite un endpoint a livello di regione o di endpoint globale, non possono connettersi. I publisher e i sottoscrittori che si connettono ad altre regioni possono comunque connettersi e i messaggi disponibili in altre regioni vengono recapitati ai sottoscrittori più vicini alla rete dotati di capacità.

Se la tua applicazione si basa sull'ordinamento dei messaggi, esamina i suggerimenti dettagliati del team di Pub/Sub. Le garanzie di ordine dei messaggi vengono fornite a livello di regione e possono essere interrotte se utilizzi un endpoint globale.

reCAPTCHA

reCAPTCHA è un servizio globale che rileva attività fraudolente, spam e comportamenti illeciti. Non richiede né consente la configurazione per la resilienza a livello di regione o zona. Gli aggiornamenti ai metadati di configurazione vengono replicati in modo asincrono in ogni regione in cui viene eseguito reCAPTCHA.

In caso di interruzione a livello di zona, reCAPTCHA continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni.

In caso di interruzione a livello di regione, reCAPTCHA continua a gestire le richieste da un'altra regione senza interruzioni.

Secret Manager

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

Le risorse di Secret Manager vengono in genere create con il criterio di replica automatica (consigliato), che ne consente la replica a livello globale. Se la tua organizzazione dispone di criteri che non consentono la replica globale dei dati secret, le risorse di Secret Manager possono essere create con criteri di replica gestiti dall'utente, in cui vengono scelte una o più regioni in cui replicare un secret.

Interruzione a livello di zona: nel caso di un'interruzione a livello di zona, Secret Manager continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni. All'interno di ogni regione, Secret Manager mantiene sempre almeno 2 repliche in zone separate (nella maggior parte delle regioni, 3 repliche). Una volta risolta l'interruzione della zona, viene ripristinata la ridondanza completa.

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

Security Command Center

Security Command Center è la piattaforma globale e in tempo reale di gestione dei rischi per Google Cloud. Consiste di due componenti principali: rilevatori e risultati.

I rilevatori sono interessati da interruzioni sia a livello di regione che di zona, in modi diversi. Durante un'interruzione a livello di regione, i rilevatori non possono generare nuovi risultati per le risorse a livello di regione perché quelle che dovrebbero analizzare non sono disponibili.

Durante un'interruzione a livello di zona, i rilevatori possono impiegare da diversi minuti a ore per riprendere il normale funzionamento. Security Command Center non perderà i dati dei risultati. Inoltre, non genererà nuovi dati sui risultati per le risorse non disponibili. Nel caso peggiore, gli agenti di Container Threat Detection potrebbero esaurire lo spazio del buffer durante la connessione a una cella integro, il che potrebbe comportare la perdita di rilevamenti.

I risultati sono resilienti alle interruzioni sia a livello di regione che di zona, perché vengono replicati in modo sincrono tra le regioni.

Sensitive Data Protection (compresa l'API DLP)

Sensitive Data Protection offre servizi di classificazione, profilazione, anonimizzazione, tokenizzazione e analisi dei rischi per la privacy dei dati sensibili. Funziona in modo sincrono sui dati che vengono inviati nel corpo della richiesta o in modo asincrono sui dati già presenti nei sistemi di spazio di archiviazione sul cloud. Sensitive Data Protection può essere richiamato tramite gli endpoint globali o specifici per regione.

Endpoint globale: il servizio è progettato per essere resiliente agli errori sia a livello di regione che di zona. Se il servizio è sovraccarico durante un errore, i dati inviati al metodo hybridInspect del servizio potrebbero andare persi.

Per creare un'architettura a prova di guasto, includi la logica per esaminare il risultato pre-guasto più recente prodotto dal metodo hybridInspect. In caso di interruzione, i dati inviati al metodo potrebbero andare persi, ma non più degli ultimi 10 minuti prima dell'evento di errore. Se vengono rilevati risultati più recenti di 10 minuti prima dell'inizio dell'interruzione, significa che i dati che hanno portato al risultato non sono stati persi. In questo caso, non è necessario riprodurre di nuovo i dati precedenti al timestamp del risultato, anche se rientrano nell'intervallo di 10 minuti.

Endpoint a livello di regione:gli endpoint a livello di regione non sono resilienti a errori a livello di regione. Se è necessaria la resilienza rispetto a un errore a livello di regione, valuta la possibilità di eseguire il failover in altre regioni. Le caratteristiche di errore a livello di zona sono le stesse di cui sopra.

Service Usage

L'API Service Usage è un servizio di infrastruttura di Google Cloud che consente di elencare e gestire API e servizi nei progetti Google Cloud. Puoi elencare e gestire le API e i servizi forniti da Google, Google Cloud e dai produttori di terze parti. L'API Service Usage è un servizio globale resiliente alle interruzioni a livello di zona e di regione. In caso di interruzione a livello di zona o di regione, l'API Service Usage continua a gestire le richieste da un'altra zona in diverse regioni.

Per ulteriori informazioni su Service Usage, consulta la documentazione sull'utilizzo dei servizi.

Speech-to-Text

Speech-to-Text consente di convertire l'audio della voce in testo utilizzando tecniche di machine learning come i modelli di rete neurale. L'audio viene inviato in tempo reale dal microfono di un'applicazione oppure elaborato come batch di file audio.

Interruzione a livello di zona:

• API Speech-to-Text v1: durante un'interruzione a livello di zona, la versione 1 dell'API Speech-to-Text continua a gestire le richieste da un'altra zona nella stessa regione senza interruzioni. Tuttavia, tutti i job attualmente in esecuzione all'interno della zona con errori andranno persi. Gli utenti devono riprovare a eseguire i job non riusciti, che verranno instradati automaticamente a una zona disponibile.

• API Speech-to-Text v2: durante un'interruzione a livello di zona, la versione 2 dell'API Speech-to-Text continua a gestire le richieste da un'altra zona nella stessa regione. Tuttavia, tutti i job attualmente in esecuzione all'interno della zona con errori andranno persi. Gli utenti devono riprovare a eseguire i job non riusciti, che verranno instradati automaticamente a una zona disponibile. L'API Speech-to-Text restituisce la chiamata API solo dopo che è stato eseguito il commit dei dati per un quorum all'interno di una regione. In alcune regioni, gli acceleratori AI (TPU) sono disponibili solo in una zona. In questo caso, un'interruzione del servizio in quella zona impedisce il riconoscimento vocale, ma non perde i dati.

Interruzione a livello di regione:

• API Speech-to-Text v1: la versione 1 dell'API Speech-to-Text non è interessata dall'errore regionale perché si tratta di un servizio globale multiregionale. Il servizio continua a gestire le richieste da un'altra regione senza interruzioni. Tuttavia, i job attualmente in esecuzione all'interno della regione con errori andranno persi. Gli utenti devono riprovare a questi job non riusciti, che verranno instradati automaticamente a una regione disponibile.

• API Speech-to-Text v2:

  • L'API Speech-to-Text in più regioni versione 2, il servizio continua a gestire senza interruzioni le richieste da un'altra zona nella stessa regione.

  • API Speech-to-Text versione 2 a regione singola, il servizio limita l'esecuzione del job alla regione richiesta. La versione 2 dell'API Speech-to-Text non instrada il traffico a una regione diversa e i dati non vengono replicati in un'altra regione. Durante un errore a livello di regione, la versione 2 dell'API Speech-to-Text non è disponibile nella regione. Tuttavia, tornerà disponibile una volta risolta l'interruzione.

Storage Transfer Service

Storage Transfer Service gestisce i trasferimenti di dati da varie origini cloud a Cloud Storage, nonché da, verso e tra file system.

L'API Storage Transfer Service è una risorsa globale.

Storage Transfer Service dipende dalla disponibilità dell'origine e della destinazione di un trasferimento. Se un'origine o una destinazione di trasferimento non è disponibile, l'avanzamento dei trasferimenti viene interrotto. Tuttavia, i dati principali dei clienti o i dati dei job non andranno persi. I trasferimenti riprendino quando l'origine e la destinazione diventano di nuovo disponibili.

Puoi utilizzare Storage Transfer Service con o senza un agente, come segue:

• I trasferimenti senza agente utilizzano worker regionali per orchestrare i job di trasferimento.

• I trasferimenti basati su agenti utilizzano gli agenti software installati nella tua infrastruttura. I trasferimenti basati su agenti si basano sulla disponibilità degli agenti di trasferimento e sulla loro capacità di connettersi al file system. Quando decidi dove installare gli agenti di trasferimento, valuta la disponibilità del file system. Ad esempio, se esegui agenti di trasferimento su più VM di Compute Engine per trasferire i dati a un'istanza Filestore di livello aziendale (una risorsa di regione), dovresti valutare la possibilità di individuare le VM in zone diverse all'interno della regione dell'istanza Filestore.

  Se gli agenti non sono più disponibili o se la loro connessione al file system viene interrotta, l'avanzamento dei trasferimenti viene interrotto, ma i dati non vengono persi. Se tutti i processi degli agenti vengono terminati, il job di trasferimento viene messo in pausa fino a quando non vengono aggiunti nuovi agenti al pool di agenti del trasferimento.

Durante un'interruzione, il comportamento di Storage Transfer Service è il seguente:

• Interruzione a livello di zona: durante un'interruzione a livello di zona, le API Storage Transfer Service rimangono disponibili e puoi continuare a creare job di trasferimento. I dati continuano a essere trasferiti.

• Interruzione a livello di regione: durante un'interruzione a livello di regione, le API Storage Transfer Service rimangono disponibili e puoi continuare a creare job di trasferimento. Se i worker del trasferimento si trovano nella regione interessata, il trasferimento di dati si interrompe finché la regione non diventa di nuovo disponibile e il trasferimento riprende automaticamente.

Vertex ML Metadata

Vertex ML Metadata consente di registrare i metadati e gli artefatti prodotti dal sistema ML ed eseguire query su tali metadati per facilitare l'analisi, il debug e l'audit delle prestazioni del sistema ML o degli artefatti che produce.

Interruzione a livello di zona: nella configurazione predefinita, Vertex ML Metadata offre protezione contro i guasti delle zone. Il deployment del servizio viene eseguito in più zone in ogni regione, con i dati replicati in modo sincrono tra le diverse zone all'interno di ogni regione. In caso di errore a livello di zona, le zone rimanenti prendono il controllo con interruzioni minime.

Interruzione a livello di regione: Vertex ML Metadata è un servizio regionalizzato. In caso di interruzione a livello di regione, non verrà eseguito il failover di Vertex ML Metadata in un'altra regione.

Previsione batch di Vertex AI

La previsione batch consente agli utenti di eseguire previsioni batch sulla base di modelli AI/ML nell'infrastruttura di Google. La previsione batch è un'offerta a livello di regione. I clienti possono scegliere la regione in cui eseguono i job, ma non le zone specifiche all'interno di quella regione. Il servizio di previsione batch bilancia automaticamente il carico del job tra diverse zone all'interno della regione scelta.

Interruzione a livello di zona: la previsione batch archivia i metadati per i job di previsione batch all'interno di una regione. I dati sono scritti in modo sincrono, in più zone all'interno della regione. In un'interruzione a livello di zona, la previsione batch perde parzialmente i worker che eseguono job, ma li riaggiunge automaticamente in altre zone disponibili. Se più tentativi di previsione batch non vanno a buon fine, nella UI e nelle richieste di chiamata API lo stato del job sarà non riuscito. Le successive richieste dell'utente per eseguire il job vengono instradate alle zone disponibili.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui vogliono eseguire i job di previsione batch. I dati non vengono mai replicati tra le regioni. La previsione batch limita l'esecuzione del job alla regione richiesta e non instrada mai le richieste di previsione a una regione diversa. Quando si verifica un errore a livello di regione, la previsione batch non è disponibile in quella regione. Sarà di nuovo disponibile quando l'interruzione verrà risolta. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri job. In caso di interruzione a livello di regione, indirizza i job a un'altra regione disponibile.

Vertex AI Model Registry

Vertex AI Model Registry consente agli utenti di semplificare la gestione, la governance e il deployment di modelli ML in un repository centrale. Vertex AI Model Registry è un'offerta regionale con disponibilità elevata e protezione contro le interruzioni a livello di zona.

Interruzione a livello di zona: Vertex AI Model Registry offre protezione contro le interruzioni a livello di zona. Il deployment del servizio viene eseguito in tre zone in ogni regione, con i dati replicati in modo sincrono tra le diverse zone all'interno della regione. In caso di errore di una zona, le zone rimanenti ne prenderanno il controllo senza perdita di dati e minima interruzione del servizio.

Interruzione regionale: Vertex AI Model Registry è un servizio regionalizzato. In caso di errore di una regione, Model Registry non eseguirà il failover.

Previsione online di Vertex AI

La previsione online consente agli utenti di eseguire il deployment di modelli AI/ML su Google Cloud. La previsione online è un'offerta regionale. I clienti possono scegliere la regione in cui eseguire il deployment dei modelli, ma non le zone specifiche all'interno della regione. Il servizio di previsione bilancia automaticamente il carico di lavoro tra diverse zone all'interno della regione selezionata.

Interruzione a livello di zona: la previsione online non memorizza i contenuti dei clienti. Un'interruzione a livello di zona porta all'errore dell'esecuzione della richiesta di previsione attuale. La previsione online può riprovare automaticamente a eseguire la richiesta, a seconda del tipo di endpoint utilizzato. In particolare, un endpoint pubblico riproverà automaticamente, mentre l'endpoint privato no. Per gestire gli errori e migliorare la resilienza, incorpora nel codice una logica di ripetizione con una back off esponenziale.

Interruzione a livello di regione:i clienti scelgono la regione Google Cloud in cui vogliono eseguire i propri modelli di AI/ML e i propri servizi di previsione online. I dati non vengono mai replicati tra regioni. La previsione online limita l'esecuzione del modello AI/ML alla regione richiesta e non instrada mai le richieste di previsione a una regione diversa. Quando si verifica un errore a livello di regione, il servizio di previsione online non è disponibile nella regione in questione. Sarà di nuovo disponibile una volta risolta l'interruzione. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri modelli IA/ML. In caso di interruzione a livello di regione, indirizza il traffico a un'altra regione disponibile.

Vertex AI Pipelines

Vertex AI Pipelines è un servizio Vertex AI che consente di automatizzare, monitorare e gestire i flussi di lavoro di machine learning (ML) in modo serverless. Vertex AI Pipelines è progettato per offrire disponibilità elevata e protezione contro i guasti a livello di zona.

Interruzione a livello di zona: nella configurazione predefinita, Vertex AI Pipelines offre protezione contro i guasti a livello di zona. Il deployment del servizio viene eseguito in più zone in ogni regione, con i dati replicati in modo sincrono tra le diverse zone all'interno della regione. In caso di errore a livello di zona, le zone rimanenti prendono il controllo con interruzioni minime.

Interruzione regionale: Vertex AI Pipelines è un servizio regionalizzato. In caso di interruzione a livello di regione, non verrà eseguito il failover di Vertex AI Pipelines in un'altra regione. Se si verifica un'interruzione a livello di regione, ti consigliamo di eseguire i job della pipeline in una regione di backup.

Vertex AI Search

Vertex AI Search è una soluzione di ricerca personalizzabile, con funzionalità di IA generativa e conformità aziendale nativa. Il deployment di Vertex AI Search viene eseguito e replicato in più regioni in Google Cloud. Puoi configurare la posizione in cui vengono archiviati i dati scegliendo una località multiregionale supportata, ad esempio globale, USA o UE.

Interruzione a livello di zona e di regione: i dati UserEvents caricati su Vertex AI Search potrebbero non essere recuperabili a causa di un ritardo della replica asincrona. Altri dati e servizi forniti da Vertex AI Search rimangono disponibili a causa del failover automatico e della replica sincrona dei dati.

Vertex AI Training

Vertex AI Training offre agli utenti la possibilità di eseguire job di addestramento personalizzati sull'infrastruttura di Google. Vertex AI Training è un'offerta regionale, il che significa che i clienti possono scegliere la regione in cui eseguire i job di addestramento. Tuttavia, i clienti non possono scegliere le zone specifiche all'interno di quella regione. Il servizio di addestramento potrebbe bilanciare automaticamente il carico dell'esecuzione del job tra diverse zone all'interno della regione.

Interruzione a livello di zona: Vertex AI Training archivia i metadati per il job di addestramento personalizzato. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. La chiamata all'API Vertex AI Training viene restituita solo dopo aver raggiunto il quorum in una regione. Il job di addestramento potrebbe essere eseguito in una zona specifica. Un'interruzione a livello di zona porta all'errore dell'esecuzione attuale del job. In questo caso, il servizio ritenta automaticamente il job instradandolo a un'altra zona. Se più tentativi non vanno a buon fine, lo stato del job viene aggiornato in Non riuscito. Le successive richieste dell'utente per eseguire il job vengono instradate a una zona disponibile.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui vogliono eseguire i job di addestramento. I dati non vengono mai replicati tra regioni. Vertex AI Training limita l'esecuzione del job alla regione richiesta e non instrada mai i job di addestramento verso una regione diversa. In caso di errore a livello di regione, il servizio Vertex AI Training non è disponibile in quella regione, ma lo torna nuovamente quando l'interruzione viene risolta. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri job e, in caso di interruzione a livello di regione, di indirizzare i job a una diversa regione disponibile.

Virtual Private Cloud (VPC)

VPC è un servizio globale che fornisce connettività di rete alle risorse (ad esempio VM). Gli errori, tuttavia, sono a livello di zona. In caso di errore a livello di zona, le risorse in quella zona non saranno disponibili. Analogamente, se si verifica un errore in una regione, viene influenzato solo il traffico da e verso la regione in questione. La connettività delle regioni integre non è interessata.

Interruzione a livello di zona: se una rete VPC copre più zone e si verifica un errore in una zona, la rete VPC sarà comunque integra. Il traffico di rete tra risorse nelle zone integre continuerà a funzionare normalmente durante l'errore. Un errore a livello di zona influisce solo sul traffico di rete da e verso le risorse nella zona in cui si è verificato l'errore. Per mitigare l'impatto degli errori a livello di zona, ti consigliamo di non creare tutte le risorse in un'unica zona. Al contrario, quando crei le risorse, distribuiscile su più zone.

Interruzione a livello di regione: se una rete VPC copre più regioni e si verifica un errore in una regione, la rete VPC sarà comunque integra per le regioni integre. Il traffico di rete tra le risorse nelle regioni integre continuerà a funzionare normalmente durante l'errore. Un errore a livello di regione influisce solo sul traffico di rete da e verso le risorse nella regione in errore. Per mitigare l'impatto degli errori a livello di regione, ti consigliamo di distribuire le risorse in più regioni.

Controlli di servizio VPC

Controlli di servizio VPC è un servizio a livello di regione. Utilizzando i Controlli di servizio VPC, i team di sicurezza aziendale possono definire controlli perimetrali granulari e applicare la strategia di sicurezza a numerosi servizi e progetti Google Cloud. I criteri dei clienti vengono applicati a livello regionale.

Interruzione a livello di zona: i Controlli di servizio VPC continuano a gestire le richieste da un'altra zona nella stessa regione senza interruzioni.

Interruzione a livello di regione: le API configurate per l'applicazione dei criteri dei Controlli di servizio VPC nella regione interessata non saranno disponibili finché la regione non tornerà disponibile. Consigliamo ai clienti di eseguire il deployment dei servizi applicati dei Controlli di servizio VPC in più regioni se si desidera una maggiore disponibilità.

Workflows

Workflows è un prodotto di orchestrazione che consente ai clienti Google Cloud di:

• il deployment e l'esecuzione di flussi di lavoro che connettono altri servizi esistenti tramite HTTP,
• automatizzare i processi, ad esempio attendere risposte HTTP con nuovi tentativi automatici
• di implementare processi in tempo reale con esecuzioni a bassa latenza basate su eventi.

Un cliente Workflows può eseguire il deployment di flussi di lavoro che descrivono la logica aziendale che intende eseguire, quindi eseguirli direttamente con l'API o con trigger basati su eventi (attualmente limitati a Pub/Sub o Eventarc). Il flusso di lavoro in esecuzione può manipolare le variabili, effettuare chiamate HTTP e archiviare i risultati o definire callback e attendere che venga ripreso da un altro servizio.

Interruzione a livello di zona: il codice sorgente di Workflows non è interessato da interruzioni a livello di zona. Workflows archivia il codice sorgente dei flussi di lavoro, insieme ai valori delle variabili e alle risposte HTTP ricevute dai flussi di lavoro in esecuzione. Il codice sorgente è archiviato a livello di regione e scritto in modo sincrono: l'API del piano di controllo restituisce solo dopo il commit dei metadati per un quorum all'interno di una regione. Anche le variabili e i risultati HTTP vengono archiviati a livello di regione e scritti in modo sincrono, almeno ogni cinque secondi.

In caso di errore in una zona, i flussi di lavoro vengono ripresi automaticamente in base agli ultimi dati archiviati. Tuttavia, le richieste HTTP che non hanno già ricevuto risposte non vengono ritentate automaticamente. Utilizza i criteri relativi ai nuovi tentativi per le richieste che è possibile ritentare in sicurezza, come descritto nella nostra documentazione.

Interruzione a livello di regione: Workflows è un servizio regionalizzato. In caso di interruzione a livello di regione, Workflows non eseguirà il failover. I clienti sono invitati a eseguire il deployment di Workflows in più regioni se si desidera una maggiore disponibilità.

Cloud Service Mesh

Cloud Service Mesh consente di configurare un mesh di servizi gestito che interessa più cluster GKE. Questa documentazione riguarda solo il mesh di servizi Cloud gestito. La variante nel cluster è ospitata autonomamente ed è necessario seguire le normali linee guida sulla piattaforma.

Interruzione a livello di zona: la configurazione mesh, poiché viene archiviata nel cluster GKE, è resiliente alle interruzioni a livello di zona, purché il cluster sia regionale. I dati utilizzati dal prodotto per la tenuta contabile interna vengono archiviati a livello regionale o globale e non vengono interessati se una singola zona è fuori servizio. Il piano di controllo viene eseguito nella stessa regione del cluster GKE che supporta (per i cluster di zona è la regione che la contiene) e non è interessato da interruzioni all'interno di una singola zona.

Interruzione a livello di regione: Cloud Service Mesh fornisce servizi ai cluster GKE, che sono a livello di regione o zona. In caso di interruzione regionale, Cloud Service Mesh non eseguirà il failover. Neanche GKE. Ai clienti viene consigliato di eseguire il deployment di mesh che costituiscono cluster GKE che coprono diverse regioni.

Service Directory

Service Directory è una piattaforma per il rilevamento, la pubblicazione e la connessione di servizi. Fornisce informazioni in tempo reale, in un unico posto, su tutti i tuoi servizi. Service Directory consente di eseguire la gestione dell'inventario dei servizi su larga scala, indipendentemente dal fatto che tu disponga di pochi endpoint di servizio o di migliaia.

Le risorse di Service Directory vengono create a livello di regione, in base al parametro di località specificato dall'utente.

Interruzione a livello di zona: durante un'interruzione a livello di zona, Service Directory continua a gestire le richieste da un'altra zona nella stessa regione o in una regione diversa senza interruzioni. All'interno di ogni regione, Service Directory mantiene sempre più repliche. Una volta risolta l'interruzione a livello di zona, viene ripristinata la ridondanza completa.

Interruzione a livello di regione: Service Directory non è resiliente alle interruzioni a livello di regione.