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 la procedura per progettare l'architettura dei carichi di lavoro utilizzando Google Cloud e componenti di base resilienti alle interruzioni dell'infrastruttura cloud.

La serie è composta dai seguenti componenti:

• Guida alla pianificazione del ripristino di emergenza
• Componenti di base per il ripristino di emergenza
• Scenari di ripristino di emergenza dei dati
• Scenari di ripristino di emergenza per le applicazioni
• Progettare ripristino di emergenza per i workload con limitazioni a livello di località
• Casi d'uso di disaster recovery: applicazioni di analisi dei dati con limitazioni di località
• Progettazione del ripristino di emergenza per le interruzioni dell'infrastruttura cloud (questo documento)

Introduzione

Quando le aziende spostano i workload sul cloud pubblico, devono tradurre la loro conoscenza della creazione di sistemi on-premise resilienti nell'infrastruttura hyperscale dei fornitori di servizi cloud come Google Cloud. Questo articolo mappa i concetti standard di settore relativi al ripristino di emergenza, come RTO (Recovery Time Objective) e RPO (Recovery Point Objective), all'infrastruttura Google Cloud.

Le indicazioni riportate in questo documento rispettano uno dei principi chiave di Google per ottenere una disponibilità del servizio estremamente elevata: pianificare i guasti. Anche se Google Cloud fornisce un servizio estremamente affidabile, possono verificarsi calamità, come calamità naturali, interruzioni della fibra e complesse interruzioni dell'infrastruttura imprevedibili, che causano interruzioni. La pianificazione delle interruzioni consente ai clienti di Google Cloud di creare applicazioni che funzionano in modo prevedibile durante questi eventi inevitabili, utilizzando i prodotti Google Cloud con meccanismi di RE "integrati".

Il disaster recovery è un argomento ampio che copre molto più dei semplici errori dell'infrastruttura, come bug software o danneggiamento dei dati, e devi avere un piano end-to-end completo. Tuttavia, questo articolo si concentra su una parte di un piano di RE complessivo: come progettare applicazioni resilienti alle interruzioni dell'infrastruttura cloud. Nello specifico, questo articolo illustra:

1. L'infrastruttura di Google Cloud, in che modo gli eventi catastrofici 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 le applicazioni in base ai risultati di affidabilità desiderati.
3. Un elenco dettagliato di prodotti Google Cloud selezionati che offrono funzionalità di RE integrate che potresti voler utilizzare nella tua applicazione.

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

Una nota sulla terminologia: questo articolo fa riferimento alla disponibilità quando discute della possibilità di accedere e utilizzare in modo significativo un prodotto nel tempo, mentre l'affidabilità si riferisce a un insieme di attributi che include la disponibilità, ma anche aspetti come la durata e la correttezza.

In che modo Google Cloud è progettato per la resilienza

Data center di Google

I data center tradizionali si basano sulla massimizzazione della disponibilità dei singoli componenti. Nel cloud, la scalabilità consente a operatori come Google di distribuire i servizi su molti componenti utilizzando tecnologie di virtualizzazione e quindi di superare l'affidabilità dei componenti tradizionali. Ciò significa che puoi cambiare il tuo approccio all'architettura di affidabilità, allontanandoti dalla miriade di dettagli che ti preoccupavano in precedenza on-premise. Anziché preoccuparti dei vari modi di guasto 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 rispecchiano il rischio di interruzione aggregato dell'intera infrastruttura di base. In questo modo, puoi concentrarti molto di più sul design, sul deployment e sulle operazioni delle applicazioni anziché sulla gestione dell'infrastruttura.

Google progetta la propria infrastruttura per raggiungere obiettivi di disponibilità ambiziosi in base alla sua vasta esperienza nella costruzione e gestione di data center moderni. Google è un leader mondiale nella progettazione di data center. Dall'alimentazione al raffreddamento alle reti, ogni tecnologia dei data center ha le proprie ridondanze e mitigazioni, inclusi i piani FMEA. I data center di Google sono progettati in modo da bilanciare questi molti rischi diversi e offrire ai clienti un livello di disponibilità previsto coerente per i prodotti Google Cloud. Google utilizza la propria esperienza per modellare la disponibilità dell'architettura di sistema fisica e logica complessiva al fine di garantire che il design del data center soddisfi le aspettative. Gli ingegneri di Google si impegnano molto per garantire che queste aspettative vengano soddisfatte. La disponibilità misurata effettiva supera in genere i nostri obiettivi di progettazione con un margine sufficiente.

Separando tutti questi rischi e le relative misure di mitigazione dei data center in prodotti rivolti agli utenti, Google Cloud ti solleva da queste responsabilità di progettazione e operatività. Puoi invece concentrarti sull'affidabilità progettata per le regioni e le zone Google Cloud.

Aree geografiche e zone

I prodotti Google Cloud sono disponibili in un gran numero di regioni e zone. Le regioni sono aree geografiche indipendenti costituite da zone. Le zone e le regioni sono astrattive logiche delle risorse fisiche sottostanti. Una regione è composta da tre o più zone ospitate in tre o più data center fisici. Le regioni Messico, Osaka e Montréal hanno tre zone in uno o due data center fisici. Queste regioni sono in fase di espansione in almeno tre data center fisici. Quando architetti le tue soluzioni in Google Cloud, tieni conto delle indicazioni riportate in Località cloud, SLA (accordi sul livello del servizio) della piattaforma Google Cloud, e nella documentazione del prodotto Google Cloud appropriata.

I prodotti Google Cloud sono suddivisi in risorse a livello di zona, risorse a livello di regione 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 guasto hardware interrompe il servizio in quella zona, l'istanza Compute Engine non è disponibile per la durata dell'interruzione.

Le risorse di regione vengono distribuite tramite deployment in modo ridondante in più zone all'interno di una regione. Ciò offre loro una maggiore affidabilità rispetto alle risorse di zona.

Le risorse multi-regione vengono distribuite all'interno e tra le regioni. In genere, le risorse multiregionali sono più affidabili di quelle regionali. Tuttavia, a questo livello i prodotti devono ottimizzare la disponibilità, le prestazioni e l'efficienza delle risorse. Di conseguenza, è importante comprendere i compromessi fatti da ciascun prodotto multiregionale che decidi di utilizzare. Questi compromessi sono documentati in base al prodotto più avanti in questo documento.

Come sfruttare le zone e le regioni per ottenere l'affidabilità

Gli SRE di Google gestiscono e scalano prodotti per gli utenti globali altamente affidabili come Gmail e la Ricerca tramite una serie di tecniche e tecnologie che sfruttano senza problemi l'infrastruttura di calcolo in tutto il mondo. Ciò include il reindirizzamento del traffico lontano dalle 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 tra le località. Queste stesse funzionalità sono disponibili per i clienti Google Cloud tramite prodotti come Cloud Load Balancing, Google Kubernetes Engine (GKE) e Spanner.

In genere, Google Cloud progetta i prodotti per offrire i seguenti livelli di disponibilità per zone e regioni:

Risorsa	Esempi	Obiettivo di progettazione della disponibilità	Tempo di riposo implicito
A livello di zona	Compute Engine, Persistent Disk	99,9%	8,75 ore / anno
Regionale	Cloud Storage regionale, disco permanente replicato, GKE regionale	99,99%	52 minuti / anno

Nota: queste sono linee guida per il design. Gli impegni relativi al livello del servizio Google Cloud sono disponibili negli accordi sul livello del servizio Google Cloud.

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

La composizione è importante perché, senza di essa, la disponibilità dell'applicazione non può superare quella dei prodotti Google Cloud che utilizzi. Infatti, a meno che l'applicazione non abbia mai errori, avrà una disponibilità inferiore rispetto ai prodotti Google Cloud sottostanti. Il resto di questa sezione illustra in generale come puoi utilizzare una combinazione di prodotti zonali e regionali per ottenere una disponibilità delle applicazioni superiore rispetto a quella offerta da una singola zona o regione. La sezione successiva fornisce una guida pratica per applicare questi principi alle tue applicazioni.

Pianificazione degli ambiti delle interruzioni della zona

Gli errori di infrastruttura di solito causano interruzioni del servizio in un'unica 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 in genere non influisce sul servizio di un'altra zona nella stessa regione. Un'interruzione limitata a una zona non significa necessariamente che l'intera zona non è disponibile, ma definisce solo il confine dell'incidente. È possibile che un'interruzione del servizio in una zona non abbia alcun effetto tangibile sulle tue risorse specifiche in quella zona.

Si tratta di un evento più raro, ma è anche fondamentale notare che più zone subiranno comunque un'interruzione correlata a un certo punto all'interno di una singola regione. Quando si verifica un'interruzione in due o più zone, viene applicata la strategia di ambito dell'interruzione regionale riportata di seguito.

Le risorse regionali sono progettate per essere resistenti alle interruzioni delle zone in quanto forniscono il servizio da una composizione di più zone. Se una delle zone di supporto di una risorsa di regione viene interrotta, la risorsa diventa automaticamente disponibile da un'altra zona. Per ulteriori dettagli, controlla attentamente la descrizione della funzionalità del prodotto nell'appendice.

Google Cloud offre solo alcune risorse zonali, ovvero le macchine virtuali (VM) e i Persistent Disk di Compute Engine. Se prevedi di utilizzare risorse a livello di zona, devi eseguire la composizione delle risorse progettando, creando e testando il failover e il recupero tra le risorse a livello di zona situate in più zone. Ecco alcune strategie:

• Inoltra rapidamente il traffico alle macchine virtuali in un'altra zona utilizzando Cloud Load Balancing quando un controllo di integrità determina che una zona sta riscontrando problemi.
• Utilizza i modelli di istanze 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 ulteriori dettagli, consulta Opzioni di alta disponibilità che utilizzano i PD regionali.

Pianificazione degli ambiti delle interruzioni regionali

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 larga scala e meno frequenti e possono essere causate da calamità naturali o guasti dell'infrastruttura su larga scala.

Per un prodotto regionale progettato per garantire una disponibilità del 99,99%, un interruzione del servizio può comunque comportare quasi un'ora di tempo di riposo per un determinato prodotto ogni anno. Pertanto, se la durata dell'interruzione non è accettabile, potrebbe essere necessario implementare un piano di RE multiregione per le applicazioni critiche.

Le risorse multiregionali sono progettate per essere resistenti alle interruzioni regionali perché forniscono il servizio da più regioni. Come descritto sopra, i prodotti su più regioni bilanciano la latenza, la coerenza e il costo. Il compromesso più comune è tra la replica dei dati sincrona e quella asincrona. La replica asincrona offre una latenza inferiore a costo del rischio di perdita di dati durante un interruzione del servizio. Pertanto, è importante controllare la descrizione delle funzionalità del prodotto nell'appendice per ulteriori dettagli.

Nota: in BigQuery, una località multiregionale non fornisce la replica tra regioni né la ridondanza regionale. I dati verranno archiviati in una singola 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 recupero tra le risorse regionali situate in più regioni. Oltre alle strategie zonali di cui sopra, che puoi applicare anche alle regioni, prendi in considerazione quanto segue:

• Le risorse regionali devono replicare i dati in una regione secondaria, in un'opzione di archiviazione multiregionale come Cloud Storage o in un'opzione di cloud ibrido come GKE Enterprise.
• Dopo aver implementato una soluzione di mitigazione delle interruzioni a livello di regione, verificala regolarmente. Poche cose sono peggiori del pensare di essere al sicuro da un'interruzione del servizio in una sola regione, per poi scoprire che non è così quando si verifica.

Approccio di Google Cloud alla resilienza e alla disponibilità

Google Cloud supera regolarmente i suoi obiettivi di progettazione della disponibilità, ma non dovresti assumere che questo ottimo rendimento passato sia la disponibilità minima che puoi progettare. Devi invece selezionare le dipendenze di Google Cloud i cui obiettivi previsti superano l'affidabilità prevista della tua applicazione, in modo che il tempo di riposo dell'applicazione più il tempo di riposo di Google Cloud generino il risultato che cerchi.

Un sistema ben progettato può rispondere alla domanda: "Cosa succede quando una zona o una regione presenta un'interruzione di 1, 5, 10 o 30 minuti?" Questo fattore deve essere preso in considerazione su molti livelli, tra cui:

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

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

Le sezioni precedenti hanno descritto come Google crea l'infrastruttura cloud e alcuni approcci per gestire le interruzioni a livello di zona e regione.

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 che hanno come target obiettivi di ripristino di emergenza come RTO e RPO devono essere progettate in modo che le operazioni aziendali critiche, soggette a RTO/RPO, abbiano dipendenze solo dai 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 e inviano la configurazione al piano di controllo e al piano dati.

Ad esempio, i clienti Google Cloud che intendono raggiungere il RTO per le operazioni aziendali fondamentali non devono dipendere da un'API di 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 ha già un certo livello di indicazioni di progettazione in questo ambito, che può essere sviluppato internamente o derivare da normative o altri requisiti legali. Queste indicazioni di progettazione sono normalmente codificate in due metriche chiave: Recovery Time Objective (RTO) e Recovery Point Objective (RPO). In termini aziendali, RTO si traduce come "Quanto tempo dopo un disastro prima che io possa riprendere a lavorare". RPO si traduce come "Quanti dati posso permettermi di perdere in caso di calamità".

In passato, le aziende hanno definito requisiti di RTO e RPO per un'ampia gamma di eventi catastrofici, dai guasti dei componenti ai terremoti. Questo aveva senso nel mondo on-premise, in cui i pianificatori dovevano mappare i requisiti RTO/RPO nell'intero stack software e hardware. Nel cloud non è più necessario definire i requisiti con così tanti dettagli perché il fornitore si occupa di tutto. In alternativa, puoi 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, questo semplifica la raccolta dei requisiti in tre scenari: un'interruzione a livello di zona, un'interruzione a livello di regione o l'interruzione estremamente improbabile di più regioni.

Poiché non tutte le applicazioni hanno la stessa criticità, la maggior parte dei clienti classifica le proprie applicazioni in livelli di criticità a cui è possibile applicare un requisito specifico RTO/RPO. Se presi insieme, RTO/RPO e la criticità dell'applicazione semplificano il processo di progettazione dell'architettura di una determinata applicazione rispondendo alle seguenti domande:

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

Questo è un esempio dell'output dell'esercizio di raccolta dei requisiti:

RTO e RPO in base alla criticità dell'applicazione per la società Example Organization:

Criticità dell'applicazione	% di app	App di esempio	Intrruzione di zona	Intrruzione nella regione
Livello 1 (più importante)	5%	In genere, applicazioni rivolte ai clienti globali o esterne, 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 applicazioni interne importanti, come CRM o ERP.	RTO 15 min RPO 15 min	RTO 1 ora RPO 1 ora
Livello 3 (meno importante)	60%	In genere applicazioni di team o reparti, come back office, prenotazione delle ferie, 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 verranno utilizzati dalle tue applicazioni. La maggior parte delle aziende esamina le informazioni pertinenti sul prodotto e poi aggiunge indicazioni su come modificare le proprie architetture per colmare eventuali lacune tra le funzionalità del prodotto e i relativi requisiti di resilienza. Questa sezione illustra alcune aree comuni e consigli relativi alle limitazioni di dati e applicazioni in questo spazio.

Come accennato in precedenza, i prodotti di Google compatibili con la RE si occupano in generale di due tipi di ambiti di interruzione: regionali e zonali. Le interruzioni parziali devono essere pianificate come per un'interruzione completa per quanto riguarda il piano di RE In questo modo, viene fornita una matrice di alto livello iniziale dei prodotti adatti per impostazione predefinita a ogni scenario:

Funzionalità generali dei prodotti Google Cloud
(consulta l'Appendice per funzionalità specifiche dei prodotti)

	Tutti i prodotti Google Cloud	Prodotti Google Cloud a livello di regione con replica automatica tra le zone	Prodotti Google Cloud multi-regionali o globali con replica automatica tra regioni
Errore di un componente all'interno di una zona	Coperto*	Con copertura	Con copertura
Intrruzione di zona	Non inclusi	Con copertura	Con copertura
Interruzioni nella regione	Non inclusi	Non inclusi	Con copertura

* Tutti i prodotti Google Cloud sono resilienti ai guasti dei componenti, ad eccezione di casi specifici indicati nella documentazione del prodotto. In genere si tratta di scenari in cui il prodotto offre accesso diretto o mappatura statica a un hardware specializzato come memoria o unità a stato solido (SSD).

In che modo l'RPO limita le scelte di prodotto

Nella maggior parte dei deployment cloud, l'integrità dei dati è l'aspetto di maggiore rilevanza dal punto di vista dell'architettura da prendere in considerazione per un servizio. Almeno alcune applicazioni hanno un requisito RPO pari a zero, il che significa che non deve verificarsi alcuna perdita di dati in caso di interruzione del servizio. In genere, è necessario che i dati vengano replicati in modo sincrono in un'altra zona o regione. La replica sincrona comporta compromessi in termini di costi e latenza, pertanto, anche se molti prodotti Google Cloud offrono la replica sincrona tra le zone, solo alcuni la offrono tra le regioni. Questo compromesso tra costi e complessità significa che non è insolito che tipi diversi 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 facilmente ricreati o recuperati da un'origine dati di riferimento, se necessario. Può anche essere una scelta ragionevole quando una piccola perdita di dati rappresenta un compromesso accettabile nel contesto delle durate previste delle interruzioni zonali e regionali. È inoltre importante notare che durante un'interruzione transitoria, i dati scritti nella località interessata, ma non ancora replicati in un'altra, diventano generalmente disponibili dopo la risoluzione dell'interruzione. Ciò significa che il rischio di perdita di dati permanente è inferiore al rischio di perdere l'accesso ai dati durante un'interruzione del servizio.

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

In che modo il RTO limita le scelte di prodotto

Uno dei principali vantaggi del cloud computing è la possibilità di eseguire il deployment dell'infrastruttura on demand; tuttavia, non si tratta di un deployment istantaneo. Il valore RTO per l'applicazione deve essere compatibile con l'RTO combinato dei prodotti Google Cloud utilizzati dall'applicazione e con qualsiasi azione che gli ingegneri o gli SRE devono intraprendere per riavviare le VM o i componenti dell'applicazione. Un RTO misurato in minuti significa progettare un'applicazione che si riprende automaticamente da un disastro senza intervento umano o con passaggi minimi, ad esempio premendo un pulsante per il failover. Il costo e la complessità di questo tipo di sistema sono stati storicamente molto elevati, ma i prodotti Google Cloud come i bilanciatori del carico e i gruppi di istanze rendono questo design molto più accessibile e semplice. Pertanto, ti consigliamo di valutare il failover e il recupero automatico per la maggior parte delle applicazioni. Tieni presente che la progettazione di un sistema per questo tipo di failover a caldo tra regioni è complicata e costosa; solo una piccolissima parte di servizi critici garantisce questa funzionalità.

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 disastro, con alcuni componenti dell'applicazione in esecuzione sempre in modalità di attesa, ad esempio i database, mentre altri vengono scalati in caso di un disastro effettivo, ad esempio i server web. Per queste applicazioni, ti consigliamo vivamente di prendere in considerazione l'automazione per gli eventi di scalabilità verso l'esterno. I servizi con un RTO superiore a un giorno sono quelli con la criticità più bassa e spesso possono essere recuperati da un backup o ricreati da zero.

Azioni chiave:stabilisci se hai sicuramente bisogno di un RTO (quasi) pari a zero per il failover regionale e, in caso affermativo, se puoi farlo per un sottoinsieme dei tuoi servizi. In questo modo, il costo di gestione e manutenzione del servizio cambia.

Passaggio 3: sviluppa le tue architetture e guide di riferimento

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

Creare linee guida per i prodotti

Se dai un'altra occhiata alla tabella di esempio RTO/RPO riportata sopra, hai una guida ipotetica che elenca i prodotti consentiti per impostazione predefinita per ogni livello di criticità. Tieni presente che, se alcuni prodotti sono stati identificati come non adatti per impostazione predefinita, puoi sempre aggiungere i tuoi meccanismi di replica e failover per abilitare la sincronizzazione tra zone o regioni, ma questo esercizio non rientra nell'ambito di questo articolo. Le tabelle rimandano anche a maggiori informazioni su ciascun prodotto per aiutarti a comprendere le relative funzionalità per la gestione delle interruzioni in una zona o una regione.

Pattern di architettura di esempio per l'azienda Co, un'organizzazione di esempio: resilienza in caso di interruzione del servizio in una zona

Prodotto Google Cloud	Il prodotto soddisfa i requisiti di interruzione zonale per l'organizzazione Example (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ì	Sì	Sì
Cloud Storage	Sì	Sì	Sì
Cloud SQL	No	Sì	Sì
Spanner	Sì	Sì	Sì
Cloud Load Balancing	Sì	Sì	Sì

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

Pattern di architettura di esempio per la resilienza alle interruzioni regionali dell'azienda Co

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

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

Per mostrare come verranno utilizzati questi prodotti, le sezioni seguenti illustrano alcune architetture di riferimento per ciascuno degli ipotetici livelli di criticità dell'applicazione. Si tratta di descrizioni volutamente di alto livello per illustrare le decisioni di architettura chiave e non sono rappresentative di un design completo della soluzione.

Esempio di architettura di livello 3

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

(Le icone non attive indicano l'infrastruttura da attivare per il recupero)

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

È importante notare che questa architettura supporta valori RTO e RPO migliori rispetto a quelli richiesti. Tuttavia, ti consigliamo anche di eliminare eventuali passaggi manuali aggiuntivi se potrebbero risultare costosi o inaffidabili. Ad esempio, il recupero di un database da un backup notturno potrebbe supportare un RPO di 24 ore, ma in genere è necessaria una persona qualificata come un amministratore di database che potrebbe non essere disponibile, soprattutto se sono stati interessati più servizi contemporaneamente. Con l'infrastruttura on demand di Google Cloud puoi creare questa funzionalità senza dover fare un grande sacrificio in termini di costi. Pertanto, questa architettura utilizza Cloud SQL HA anziché un backup/ripristino manuale per le interruzioni zonali.

Decisioni di architettura chiave per l'interruzione di servizio in una zona: RTO di 12 ore e RPO di 24 ore:

• Viene utilizzato un bilanciatore del carico interno per fornire agli utenti un punto di accesso scalabile che consenta 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 per area geografica è configurato con più zone, ma con risorse minime. In questo modo viene ottimizzato il costo, ma è comunque possibile eseguire rapidamente il ridimensionamento delle macchine virtuali nella zona di backup.
• Una configurazione Cloud SQL ad alta disponibilità prevede il failover automatico in un'altra zona. I database sono molto più difficili da ricreare e ripristinare rispetto alle macchine virtuali Compute Engine.

Decisioni di architettura chiave per l'interruzione della regione: RTO di 28 giorni e RPO di 24 ore:

• Un bilanciatore del carico verrebbe costruito nella regione 2 solo in caso di interruzione a livello di regione. Cloud DNS viene utilizzato per fornire una funzionalità di failover regionale orchestrata, ma manuale, poiché l'infrastruttura nella regione 2 verrebbe resa disponibile solo in caso di interruzione del servizio nella regione.
• Un nuovo gruppo di istanze gestite verrebbe creato solo in caso di interruzione del servizio in una regione. In questo modo, viene ottimizzato il costo ed è improbabile che venga invocato data la breve durata della maggior parte delle interruzioni regionali. Tieni presente che, per semplicità, il diagramma non mostra gli strumenti associati necessari per il nuovo 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, quindi si tratta di un altro compromesso per l'ottimizzazione dei costi.
• Per archiviare questi backup viene utilizzato Cloud Storage su più regioni. Ciò garantisce la resilienza automatica a livello di zona e di regione nei limiti di RTO e RPO.

Esempio di architettura di livello 2

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

Questa architettura descrive un data warehouse con utenti interni che si connettono a un livello di visualizzazione delle istanze di calcolo e a un livello di importazione e trasformazione dei dati che compila il data warehouse di backend.

Alcuni singoli componenti di questa architettura non supportano direttamente il RPO richiesto per il loro livello. Tuttavia, a causa del modo in cui vengono utilizzati insieme, il servizio complessivo soddisfa l'RPO. In questo caso, poiché Dataflow è un prodotto zonale, segui i consigli per la progettazione di un design ad alta disponibilità per contribuire a evitare la perdita di dati durante un'interruzione. Tuttavia, il livello Cloud Storage è la fonte attendibile 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 di architettura chiave per l'interruzione della zona:RTO di 4 ore e RPO pari a zero

• Un bilanciatore del carico viene utilizzato per fornire agli utenti un punto di accesso scalabile, che consente il failover automatico a un'altra zona. Anche se il 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 per area geografica per il livello di calcolo della visualizzazione dei dati è configurato con più zone, ma con risorse minime. In questo modo, viene ottimizzato il costo, ma è comunque possibile scalare rapidamente le macchine virtuali.
• Cloud Storage regionale viene utilizzato come livello di gestione temporanea per l'importazione iniziale dei dati, garantendo la resilienza automatica delle zone.
• Dataflow viene utilizzato per estrarre i dati da Cloud Storage e trasformarli prima di caricarli in BigQuery. In caso di interruzione del servizio in una zona, si tratta di un processo senza stato 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 del servizio in una zona, tutti i dati persi verranno importati di nuovo da Cloud Storage.

Decisioni di 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 per gli utenti. Cloud DNS viene utilizzato per fornire una funzionalità di failover regionale orchestrata, ma manuale, poiché l'infrastruttura nella regione 2 verrebbe resa disponibile solo in caso di interruzione della regione.
• Un gruppo di istanze gestite per area geografica per il livello di calcolo della visualizzazione dei dati è configurato con più zone, ma con risorse minime. Non è accessibile finché il bilanciatore del carico non viene nuovamente configurato, ma non richiede intervento manuale.
• Cloud Storage regionale viene utilizzato come livello di gestione temporanea per l'importazione iniziale dei dati. 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 del servizio in una regione, BigQuery verrà compilato con i dati più recenti di Cloud Storage.
• BigQuery fornisce il backend del data warehouse. In condizioni normali, questo valore viene aggiornato a intermittenza. In caso di interruzione del servizio in una regione, i dati più recenti verranno importati di nuovo tramite Dataflow da Cloud Storage.

Esempio di architettura di livello 1

Criticità dell'applicazione	Intrruzione di zona	Intrruzione nella regione
Livello 1 (il 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 insieme di microservizi in esecuzione in GKE. Spanner fornisce il livello di archiviazione dei dati di backend per i dati in tempo reale e i dati storici vengono trasmessi in streaming a un data lake BigQuery in ogni regione.

Anche in questo caso, alcuni singoli componenti di questa architettura non supportano direttamente il RPO richiesto per il loro livello, ma il servizio complessivo lo supporta grazie al modo in cui vengono utilizzati insieme. In questo caso BigQuery viene utilizzato per le query di analisi. Ogni regione viene alimentata contemporaneamente da Spanner.

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

• Un bilanciatore del carico viene utilizzato per fornire agli utenti un punto di accesso scalabile, che consente il failover automatico a un'altra zona.
• Per il livello di applicazione viene utilizzato un cluster GKE regionale configurato con più zone. In questo modo, il tempo di recupero obiettivo è pari a zero all'interno di ogni regione.
• Spanner multiregione viene utilizzato come livello di persistenza dei dati, fornendo resilienza automatica dei dati delle zone e coerenza delle transazioni.
• BigQuery fornisce la funzionalità di analisi per l'applicazione. A ogni regione vengono forniti in modo indipendente i dati di Spanner e l'applicazione vi accede in modo indipendente.

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

• Un bilanciatore del carico viene utilizzato per fornire agli utenti un punto di accesso scalabile, che consente il failover automatico in un'altra regione.
• Per il livello di applicazione viene utilizzato un cluster GKE regionale configurato con più zone. In caso di interruzione di una regione, il cluster nella regione alternativa viene scalato automaticamente per assumere il carico di elaborazione aggiuntivo.
• Spanner multiregione viene utilizzato come livello di persistenza dei dati, fornendo resilienza automatica dei dati regionali e coerenza delle transazioni. Si tratta del componente chiave per ottenere un RPO interregionale di 1 ora.
• BigQuery fornisce la funzionalità di analisi per l'applicazione. A ogni regione vengono forniti in modo indipendente i dati di Spanner e l'applicazione vi accede in modo indipendente. Questa architettura compensa il componente BigQuery, consentendogli di adattarsi ai requisiti complessivi dell'applicazione.

Appendice: riferimento del prodotto

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

Temi comuni

Molti prodotti Google Cloud offrono configurazioni regionali o multiregionali. I prodotti regionali sono resilienti alle interruzioni a livello di zona, mentre i prodotti disponibili in più regioni e globali sono resilienti alle interruzioni a livello di regione. In generale, ciò significa che durante un'interruzione la tua applicazione subisce interruzioni minime. Google ottiene questi risultati tramite alcuni approcci di architettura comuni, che rispecchiano le indicazioni di architettura riportate sopra.

• Deployment ridondante:¹ i backend dell'applicazione e lo spazio di archiviazione dei dati vengono eseguiti su più zone all'interno di una regione e in più regioni all'interno di una località con più regioni.

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

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

    Sebbene questa tecnica offra la massima protezione dei dati, può comportare compromessi in termini di latenza e prestazioni. I prodotti multiregione che utilizzano la replica sincrona sperimentano questo compromesso in misura maggiore, tipicamente nell'ordine di decine o centinaia di millisecondi di latenza aggiuntiva.

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

    Questa tecnica offre una latenza inferiore e una maggiore velocità effettiva all'API rispetto alla replica sincrona, ma a spese della protezione dei dati. Se la posizione in cui hai scritto i dati subisce un'interruzione prima del completamento della replica, non potrai più accedere ai dati fino a quando l'interruzione non sarà stata risolta.

• Gestione delle interruzioni con il bilanciamento del carico:Google Cloud utilizza il bilanciamento del carico software per instradare le richieste ai backend dell'applicazione appropriati. Rispetto ad altri approcci come il bilanciamento del carico DNS, questo approccio riduce il tempo di risposta del sistema in caso di interruzione del servizio. Quando si verifica un'interruzione di servizio in una località Google Cloud, il bilanciatore del carico rileva rapidamente che il backend di cui è stato eseguito il deployment in quella località non è più "in stato di salute" e indirizza tutte le richieste a un backend in una località alternativa. In questo modo, il prodotto può continuare a soddisfare le richieste della tua applicazione durante un'interruzione del servizio in una località. Quando l'interruzione della località è stata risolta, il bilanciatore del carico rileva la disponibilità dei backend dei prodotti in quella località e riprende a inviare il traffico.

Gestore contesto accesso

Il Gestore contesto accesso consente alle aziende di configurare livelli di accesso che corrispondono a una norma definita negli attributi della richiesta. I criteri vengono replicati 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 da altre zone disponibili della regione.

In caso di interruzione a livello di regione, i calcoli dei criteri della regione interessata non sono disponibili finché la regione non diventa di nuovo disponibile.

Access Transparency

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

Access Transparency è resiliente alle interruzioni a livello di zona e regione. In caso di interruzione o regionale, Access Transparency continua a elaborare i log di accesso amministrativo 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 alta disponibilità in una regione tramite i nodi ridondanti dell'istanza principale, che si trovano in due zone diverse della regione. L'istanza principale mantiene la disponibilità a livello di regione attivando un failover automatico nella zona di standby se la zona attiva riscontra un problema. L'archiviazione a livello di regione garantisce la durabilità dei dati in caso di perdita di 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 situati in regioni Google Cloud distinte.

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

AlloyDB per PostgreSQL rileva automaticamente gli 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 di standby, per il quale è già stato eseguito il provisioning in un'altra zona. Le nuove connessioni al database vengono indirizzate automaticamente a questa zona.

Dal punto di vista di un'applicazione client, un'interruzione zonale assomiglia 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 a livello di regione: la replica tra regioni utilizza la replica asincrona, che consente all'istanza principale di eseguire il commit delle transazioni prima che vengano eseguite sulle repliche. La differenza di tempo tra il momento in cui viene eseguita la commit di una transazione nell'istanza principale e il momento in cui viene eseguita la commit nella replica è nota come ritardo della replica. La differenza di tempo tra il momento in cui il primario genera il log WAL (write-ahead log) e il momento in cui il WAL raggiunge la replica è nota come ritardo di svuotamento. Il ritardo di replica e il ritardo di aggiornamento dipendono dalla configurazione dell'istanza di database e dal carico di lavoro generato dagli utenti.

In caso di interruzione a livello di regione, puoi promuovere i cluster secondari in un'altra regione in un 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 dello svuotamento, potrebbe verificarsi una perdita di dati perché potrebbero esserci transazioni sul cluster principale originale che non sono state propagate al cluster secondario.

Il RPO della replica tra regioni è influenzato sia dall'utilizzo della CPU del cluster principale sia dalla distanza fisica tra la regione del cluster principale e la regione del cluster secondario. Per ottimizzare il RPO, ti consigliamo di testare il tuo workload con una configurazione che includa una replica per stabilire un limite sicuro di transazioni al secondo (TPS), ovvero il TPS massimo sostenuto che non accumula ritardi di aggiornamento. Se il tuo workload supera il limite TPS sicuro, si accumula un ritardo di svuotamento, che può influire sul RPO. Per limitare il ritardo della rete, scegli coppie di regioni all'interno dello stesso continente.

Per saperne di più sul monitoraggio del ritardo della rete e di altre metriche di AlloyDB per PostgreSQL, consulta Monitora le istanze.

Anti Money Laundering AI

L'AI Anti Money Laundering (AML AI) fornisce un'API per aiutare gli istituti finanziari mondiali a rilevare il riciclaggio di denaro in modo più efficace ed efficiente. L'IA antiriciclaggio è 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 il carico viene bilanciato tra le zone, se necessario.

Interruzione di servizio a livello di zona:AML AI archivia i dati per le sue risorse in modo regionale, replicati in modo sincrono. Quando un'operazione a lunga esecuzione termina correttamente, le risorse possono essere utilizzate indipendentemente dai guasti di 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ò comportare un errore dell'operazione. In questo caso, puoi risolvere il problema riprovando a eseguire l'operazione. Durante un'interruzione di servizio zonale, i tempi di elaborazione potrebbero essere interessati.

Interruzione del servizio a livello di regione: i clienti scelgono la regione Google Cloud in cui creare le risorse di IA AML. I dati non vengono mai replicati tra le regioni. Il traffico dei clienti non viene mai indirizzato a una regione diversa dall'IA AML. In caso di guasto regionale, l'AI AML sarà di nuovo disponibile non appena l'interruzione sarà risolta.

Chiavi API

Le chiavi API offrono una gestione delle risorse API scalabile per un progetto. Le chiavi API sono un servizio globale, il che significa che sono visibili e accessibili da qualsiasi località Google Cloud. I relativi dati e metadati vengono archiviati in modo redundante in più zone e regioni.

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

Per ulteriori informazioni sulle chiavi API, consulta la panoramica dell'API chiavi API.

Apigee

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

Interruzione zonale:i dati di runtime del cliente vengono replicati in più zone di disponibilità. Pertanto, un'interruzione in una singola zona non influisce su Apigee.

Interruzione a livello di regione: per le istanze Apigee a una singola regione, se una regione non è disponibile, le istanze Apigee non sono disponibili in quella regione e non possono essere ripristinate in regioni diverse. Per le istanze Apigee multiregione, i dati vengono replicati in tutte le regioni in modo asincrono. Pertanto, il malfunzionamento di una regione non riduce completamente il traffico. Tuttavia, potresti non essere in grado di accedere ai dati non committati nella regione con errori. Puoi desviare il traffico dalle regioni non in buono stato. Per ottenere il failover automatico del traffico, puoi configurare il routing di rete utilizzando i gruppi di istanze gestite (MIG).

AutoML Translation

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

Interruzione a livello di zona: AutoML Translation ha server di calcolo attivi in più zone e regioni. supporta anche la replica sincrona dei dati tra le zone all'interno delle regioni. Queste funzionalità aiutano AutoML Translation a eseguire il failover istantaneo senza perdita di dati per i guasti zonali e senza richiedere alcun intervento o aggiustamento da parte del cliente.

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

AutoML Vision

AutoML Vision fa parte di Vertex AI. Offre un strumento unificato per creare set di dati, importare dati, addestrare modelli e pubblicarli per predizioni online e batch.

AutoML Vision è un'offerta regionale. I clienti possono scegliere la regione da cui lanciare un job, ma non possono scegliere le zone specifiche all'interno della regione. Il servizio esegue automaticamente il bilanciamento del carico tra diverse zone all'interno della regione.

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

• Job di addestramento AutoML Vision: un'interruzione di servizio zonale causa l'errore di tutti i job in esecuzione e lo stato del job viene aggiornato in stato di errore. Se un job non va a buon fine, riprova immediatamente. Il nuovo job viene instradato a una zona disponibile.

• Job di previsione in batch di AutoML Vision: le previsioni in batch sono basate su Vertex AI Batch Prediction. Quando si verifica un'interruzione di servizio a livello di zona, il servizio riprova automaticamente il job indirizzandolo alle zone disponibili. Se più tentativi non vanno a buon fine, lo stato del job viene aggiornato in non riuscito. Le richieste successive degli utenti per l'esecuzione del job vengono instradate a una zona disponibile.

Interruzione a livello di regione:i clienti scelgono la regione Google Cloud in cui eseguire i job. I dati non vengono mai replicati tra regioni. In caso di guasto regionale, il servizio AutoML Vision non è disponibile nella regione in questione. Ritornerà disponibile al termine dell'interruzione. Per eseguire i loro job, consigliamo ai clienti di utilizzare più regioni. In caso di interruzione regionale, indirizza i job a una regione disponibile diversa.

Batch

Batch è un servizio completamente gestito per inserire in coda, pianificare ed eseguire job batch su Google Cloud. Le impostazioni batch vengono definite a livello di regione. I clienti devono scegliere una regione per inviare i job batch, non una zona all'interno di 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 a livello di zona: quando si verifica un errore in una singola zona, anche le attività in esecuzione in quella zona non vanno a buon fine. Se le attività hanno impostazioni di ripetizione, Batch esegue automaticamente il failover di queste attività in altre zone attive della stessa regione. Il failover automatico è soggetto alla disponibilità delle 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 errore vengono messi in coda fino al recupero della zona con errore o fino al raggiungimento dei timeout di coda dei job. Se possibile, consigliamo ai clienti di lasciare che sia Batch a scegliere le risorse zonali per l'esecuzione dei job. In questo modo, puoi assicurarti che i job siano resilienti a un'interruzione di servizio zonale.

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

Protezione dei dati e dalle minacce di Chrome Enterprise Premium

La protezione dei dati e dalle minacce di Chrome Enterprise Premium fa parte della soluzione Chrome Enterprise Premium. Espande 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 generazione di report sulla sicurezza.

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

Interruzione a livello di zona e regione: poiché la protezione dei dati e dalle minacce di Chrome Enterprise Premium è multizonale e multiregionale, può sopravvivere a una perdita completa e imprevista di una zona o una regione senza perdere disponibilità. Offre questo livello di affidabilità reindirizzando il traffico al proprio servizio in altre zone o regioni attive. Tuttavia, poiché la protezione dei dati e la tutela dalle minacce di Chrome Enterprise Premium possono richiedere diverse ore per rilevare violazioni del DLP e dei malware, tutti i dati non elaborati in una zona o una regione specifica sono soggetti a perdita a causa di un'interruzione del servizio a livello di zona o 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 utente:

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

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

Autorizzazione binaria

L'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 rende inoltre le operazioni di lettura tolleranti agli errori a livello di zona all'interno di ogni regione.

Le operazioni di applicazione dell'Autorizzazione binaria sono resilienti alle interruzioni a livello di zona, ma non a quelle a livello di regione. Le operazioni di applicazione vengono eseguite nella stessa regione del cluster GKE o del job Cloud Run che effettua la richiesta. Pertanto, in caso di interruzione del servizio a livello di regione, non viene eseguito alcun servizio per effettuare richieste di applicazione dell&#Autorizzazione binaria.

Gestore certificati

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

In caso di interruzione zonale, Certificate Manager regionale e globale è resiliente agli errori zonali perché i job e i database sono ridondanti in più zone all'interno di una regione. In caso di interruzione a livello di regione, Certificate Manager è resiliente ai guasti regionali perché i job e i database sono ridondanti in più regioni. Regional Certificate Manager è un prodotto regionale, pertanto non può resistere a un errore regionale.

Cloud Intrusion Detection System

Cloud Intrusion Detection System (Cloud IDS) è un servizio zonale che fornisce endpoint IDS con ambito zonale, che elaborano il traffico delle VM in una zona specifica e quindi non sono tolleranti delle interruzioni zonali o regionali.

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

Interruzione a livello di regione:Cloud IDS è un prodotto regionale. Non offre funzionalità interregionali. Un errore a livello di regione comporta la disattivazione di tutte le funzionalità di Cloud IDS in tutte le zone della regione.

Google Security Operations SIEM

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 soluzioni a livello di regione e multi-regione.

• Nelle offerte regionali, il carico dei dati e del traffico viene bilanciato automaticamente tra le zone della regione scelta e i dati vengono archiviati in modo ridondante nelle zone di disponibilità della regione.

• Le regioni multiple sono con ridondanza geografica. Questa ridondanza offre un insieme più ampio di protezioni rispetto allo spazio di archiviazione a livello di regione. Inoltre, contribuisce ad assicurare che il servizio continui a funzionare anche se viene persa un'intera regione.

• La maggior parte dei percorsi di importazione dati replica i dati dei clienti in modo sincrono su più località. Quando i dati vengono replicati in modo asincrono, esiste un periodo di tempo (un obiettivo del punto di recupero o RPO) durante il quale i dati non sono ancora replicati in più località. Questo accade quando importi i dati con feed in deployment multi-regionali. Dopo il RPO, i dati sono disponibili in più località.

Interruzione zonale:

• Deployment regionali: le richieste vengono eseguite da qualsiasi zona all'interno della regione. I dati vengono replicati in modo sincrono in più zone. In caso di interruzione completa della zona, le zone rimanenti continuano a gestire il traffico ed elaborare i dati. Il provisioning ridondante e la scalabilità automatica per il SIEM di Google Security Operations contribuiscono a garantire che il servizio rimanga operativo nelle zone rimanenti durante questi trasferimenti di carico.

• Deployment multiregionali: le interruzioni zonali sono equivalenti a quelle regionali.

Interruzione a livello di regione:

• Implementazioni a livello di regione: il SIEM di Google Security Operations archivia tutti i dati dei clienti all'interno di una singola regione e il traffico non viene mai instradato tra regioni. In caso di interruzione del servizio a livello regionale, Google Security Operations SIEM non è disponibile nella regione fino alla risoluzione dell'interruzione.

• Deployment multiregionali (senza feed): le richieste vengono inviate da qualsiasi regione del deployment multiregionale. I dati vengono replicati in modo sincrono in più regioni. In caso di interruzione dell'intera regione, le regioni rimanenti continuano a gestire il traffico ed elaborare i dati. Il provisioning redundante e la scalabilità automatica per il SIEM di Google Security Operations contribuiscono a garantire che il servizio rimanga operativo nelle regioni rimanenti durante questi picchi di carico.

• Deployment multiregionali (con feed): le richieste vengono pubblicate da qualsiasi regione del deployment multiregionale. I dati vengono replicati in modo asincrono in più regioni con l'RPO specificato. In caso di interruzione dell'intera regione, nelle regioni rimanenti sono disponibili solo i dati archiviati dopo il RPO. I dati all'interno della finestra RPD potrebbero non essere replicati.

Cloud Asset Inventory

Cloud Asset Inventory è un servizio globale ad alte prestazioni e resiliente che gestisce un repository di metadati di risorse e criteri di Google Cloud. Cloud Asset Inventory fornisce strumenti di ricerca e analisi che ti aiutano a monitorare gli 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 provenienti da un'altra zona nella stessa regione o in un'altra.

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 e completamente gestito per carichi di lavoro analitici e operativi di grandi dimensioni.

Panoramica della replica Bigtable

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

Quando utilizzi configurazioni multizonali o multiregionali con routing a cluster multipli, in caso di interruzione del servizio a livello di zona o regione, Bigtable riassegna automaticamente il traffico e serve le richieste dal cluster disponibile più vicino. Poiché la replica di Bigtable è asincrona e coerente alla fine, le modifiche molto recenti ai dati nella località dell'interruzione potrebbero non essere disponibili se non sono ancora state 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 i cluster rimangano adeguatamente provisionati in ogni momento affinché la replica venga eseguita in modo prevedibile.

Quando le richieste di risorse della CPU superano la capacità dei nodi disponibili, Bigtable dà sempre la priorità al servizio delle richieste in entrata prima del traffico di replica.

Per ulteriori informazioni su come utilizzare la replica Bigtable con il tuo workload, consulta la Panoramica della replica Cloud Bigtable e gli esempi di impostazioni di replica.

I nodi Bigtable vengono utilizzati sia per gestire le richieste in arrivo 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 tue applicazioni utilizzino un design dello schema adeguato per evitare hotspot, che possono causare un utilizzo eccessivo o sbilanciato della CPU e un aumento della latenza della 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 dello schema.

Monitoraggio

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

Puoi anche monitorare in modo programmatico le metriche della 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 delle autorità di certificazione (CA) private e di emettere certificati resilienti su larga scala.

Interruzione di servizio a livello di zona: il servizio CA è resiliente ai guasti a livello di zona perché il relativo piano di controllo è ridondante in più zone all'interno di una regione. In caso di interruzione a livello di zona, il servizio CA continua a gestire le richieste provenienti da un'altra zona della stessa regione senza interruzioni. Poiché i dati vengono replicati in modo sincrono, non si verificano perdite o danneggiamenti dei dati.

Interruzione a livello di regione: il servizio CA è un prodotto regionale, pertanto non può resistere a un guasto regionale. Se hai bisogno di resilienza ai guasti regionali, crea CA emittenti in due regioni diverse. Crea la CA emittente principale nella regione in cui hai bisogno di certificati. Crea una CA di riserva in un'altra regione. Utilizza il valore di riserva quando si verifica un'interruzione nella regione della CA secondaria principale. Se necessario, entrambe le CA possono essere collegate alla stessa CA principale.

Cloud Billing

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

Errore a livello di zona o regione: l'API Cloud Billing eseguirà automaticamente il failover in un'altra zona o regione. Le singole richieste potrebbero non andare a buon fine, ma un criterio di ripetizione dovrebbe consentire il buon esito dei 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 i dati in modo sincrono tra le zone all'interno della regione. Ti consigliamo di utilizzare regioni Google Cloud specifiche anziché la regione globale e di assicurarti che le risorse utilizzate dalla build (inclusi i bucket di log, i repository Artifact Registry e così via) siano in linea con la regione in cui viene eseguita la build.

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

In caso di guasto regionale, il piano di controllo sarà offline e le build in esecuzione verranno ritardate o perse definitivamente. Gli attivatori, i pool di worker e i dati di compilazione non vengono mai replicati tra le regioni. Ti consigliamo di preparare attivatori e pool di worker in più regioni per semplificare la mitigazione di un'interruzione del servizio.

Cloud CDN

Cloud CDN distribuisce e memorizza nella cache i contenuti in molte località della rete di Google per ridurre la latenza di pubblicazione per i clienti. I contenuti memorizzati nella cache vengono pubblicati su una base di miglior impegno. Quando una richiesta non può essere gestita dalla cache di Cloud CDN, la richiesta viene inoltrata ai server di origine, ad esempio le VM di backend o i bucket di Cloud Storage, dove sono archiviati i contenuti originali.

Quando si verifica un errore in una zona o in una regione, le cache nelle località interessate non sono disponibili. Le richieste in entrata vengono instradate alle cache e alle località edge di Google disponibili. Se queste cache alternative non possono soddisfare la richiesta, la inoltrano a un server di origine disponibile. A condizione che il server possa soddisfare la richiesta con dati aggiornati, non ci sarà alcuna perdita di contenuti. Un aumento della frequenza di mancate corrispondenze della cache causerà un aumento dei volumi di traffico rispetto alla norma man mano che le cache vengono riempite. Le richieste successive vengono eseguite dalle cache non interessate dall'interruzione del servizio nella zona o nella regione.

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

Cloud Composer

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

La disponibilità dell'API Cloud Composer non è interessata dall'indisponibilità a livello di zona. Durante un'interruzione zonale, mantieni l'accesso all'API Cloud Composer, inclusa la possibilità di creare nuovi ambienti Cloud Composer.

Un ambiente Cloud Composer ha un cluster GKE come parte della sua architettura. Durante un'interruzione zonale, i flussi di lavoro nel cluster potrebbero essere interrotti:

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

In entrambe le versioni di Cloud Composer, un'interruzione zonale potrebbe causare l'interruzione dell'esecuzione dei flussi di lavoro eseguiti parzialmente, incluse eventuali azioni esterne che il flusso di lavoro è stato configurato per eseguire. A seconda del flusso di lavoro, ciò può causare incoerenze esterne, ad esempio se il flusso di lavoro si interrompe nel mezzo di un'esecuzione in più passaggi per modificare gli archivi di dati esterni. Pertanto, quando progetti il flusso di lavoro Airflow, devi prendere in considerazione la procedura di recupero, inclusa la modalità di rilevamento degli stati del flusso di lavoro parzialmente non eseguiti e di riparazione di eventuali modifiche parziali dei dati.

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

In Cloud Composer 2, puoi risolvere le interruzioni zonali configurando in anticipo il ripristino di emergenza con snapshot dell'ambiente. Durante un'interruzione in una zona, puoi passare a un altro ambiente trasferendo lo stato dei tuoi flussi di lavoro con uno snapshot dell'ambiente. Solo Cloud Composer 2 supporta il recupero di emergenza con gli 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. Sono disponibili tre versioni.

• Le interruzioni zonali influiscono sulle istanze della versione Developer.

• Le interruzioni regionali interessano le istanze delle versioni Basic ed Enterprise.

Per controllare l'accesso alle risorse, puoi progettare ed eseguire pipeline in ambienti separati. Questa separazione ti consente di progettare una pipeline una volta e poi di eseguirla in più ambienti. Puoi recuperare le pipeline in entrambi gli ambienti. Per ulteriori informazioni, consulta Effettuare il backup e ripristinare i dati delle istanze.

I seguenti consigli si applicano sia alle interruzioni regionali sia a quelle a livello di zona.

Interruzione del servizio nell'ambiente di progettazione della pipeline

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

Interruzione del servizio nell'ambiente di esecuzione della pipeline

Nell'ambiente di esecuzione, puoi avviare la pipeline internamente con gli attivatori o le pianificazioni di Cloud Data Fusion o esternamente con gli 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. In caso di interruzione, puoi utilizzare il backup per replicare un'istanza in una regione o zona non interessata.

Un altro modo per prepararsi alle interruzioni è avere più istanze nelle diverse regioni con la stessa configurazione e la stessa pipeline impostate. Se utilizzi l'orchestrazione esterna, le pipeline in esecuzione possono essere bilanciate automaticamente tra le istanze. Presta particolare attenzione ad assicurarti che non ci siano risorse (come origini dati o strumenti di orchestrazione) associate a una singola regione e utilizzate da tutte le istanze, in quanto potrebbero diventare un punto di errore centrale in caso di interruzione del servizio. Ad esempio, puoi avere più istanze in regioni diverse 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 l'esempio di architetture di livello 1 e livello 3).

Interruzione di altri servizi dati Google Cloud nella pipeline

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

Cloud Deploy

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

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

Interruzione a livello di regione: le operazioni del piano di controllo non sono disponibili, così come i dati di Cloud Deploy, finché la regione non viene ripristinata. Per semplificare il recupero del servizio in caso di interruzione del servizio a livello regionale, ti consigliamo di archiviare la pipeline di importazione e le definizioni dei target nel controllo del codice sorgente. Puoi utilizzare questi file di configurazione per ricreare le pipeline Cloud Deploy in una regione funzionante. Durante un'interruzione, i dati sulle release esistenti vengono persi. Crea una nuova release per continuare a eseguire il deployment del software nei tuoi target.

Cloud DNS

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

In caso di interruzione a livello di zona, Cloud DNS continua a gestire le richieste provenienti 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. Di conseguenza, non si verifica alcuna perdita di dati.

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

Funzioni Cloud Run

Le funzioni Cloud Run sono un ambiente di calcolo stateless in cui i clienti possono eseguire il codice delle funzioni sull'infrastruttura di Google. Le funzioni Cloud Run sono 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 nelle zone all'interno di una regione. Le funzioni vengono scalate automaticamente per soddisfare il traffico in entrata e il carico viene bilanciato tra le zone, se necessario. Ogni zona gestisce un programmatore che fornisce questo ridimensionamento automatico per zona. Inoltre, è consapevole del carico ricevuto dalle altre zone e eseguirà il provisioning di una capacità aggiuntiva all'interno della zona per consentire eventuali errori zonali.

Interruzione zonale: le funzioni Cloud Run archiviano 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 Run Admin restituisce la chiamata API solo dopo che i dati sono stati committati a un quorum all'interno di una regione. Poiché i dati vengono archiviati a livello di regione, anche le operazioni del piano dati non sono interessate da errori zonali. Il traffico viene indirizzato automaticamente ad altre zone in caso di guasto di una zona.

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

API Cloud Healthcare

L'API Cloud Healthcare, un servizio per l'archiviazione e la gestione dei dati sanitari, è progettata per fornire alta disponibilità e offre protezione contro i guasti zonali e regionali, a seconda della configurazione scelta.

Configurazione regionale: nella configurazione predefinita, l'API Cloud Healthcare offre protezione contro i guasti zonali. Il servizio viene implementato in tre zone di una regione, con i dati triplicati anche in zone diverse all'interno della regione. In caso di errore circoscritto a una zona, che interessa il livello di servizio o il livello di dati, le zone rimanenti prendono il controllo senza interruzioni. Con la configurazione a livello di regione, se un'intera regione in cui si trova il servizio presenta un'interruzione, il servizio non sarà disponibile fino a quando la regione non sarà di nuovo online. Nell'imprevedibile eventualità di una distruzione fisica di un'intera regione, i dati archiviati in quella regione andranno persi.

Configurazione multiregionale: nella configurazione multiregionale, l'API Cloud Healthcare viene dispiattata in tre zone appartenenti a tre diverse regioni. I dati vengono inoltre replicati in tre regioni. In questo modo, viene evitata la perdita del servizio in caso di interruzione del servizio in un'intera regione, poiché le regioni rimanenti assumerebbero 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 Diktat o oggetti HL7v2/FHIR di grandi dimensioni, vengono replicati in modo asincrono in più regioni.

Cloud Identity

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

Nella maggior parte dei casi, i dati permanenti vengono replicati in più regioni con la replica sincrona. Per motivi di prestazioni, alcuni sistemi, come le cache o le modifiche che interessano un gran numero di entità, vengono replicati in modo asincrono tra le regioni. Se la regione principale in cui sono archiviati i dati più recenti subisce un'interruzione, Cloud Identity pubblica dati non aggiornati da un'altra posizione fino a quando la regione principale non diventa disponibile.

Cloud Interconnect

Cloud Interconnect offre ai clienti accesso alle reti Google Cloud tramite protocollo RFC 1918 dai loro data center on-premise, tramite cavi fisici collegati al peering edge di Google.

Cloud Interconnect offre ai clienti un SLA del 99,9% se eseguono il provisioning di connessioni a due EAD (Edge Availability Domains) in un'area metropolitana. È disponibile un SLA del 99,99% se il cliente esegue il provisioning delle connessioni in due EAD in due aree metropolitane a due regioni con routing globale. 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 calcolo e offre alta disponibilità sotto forma di EAD. In caso di errore dell'EAD, la sessione BGP con quell'entità si interrompe e il traffico viene trasferito all'altra entità.

In caso di errore regionale, le sessioni BGP per quella regione si interrompono e il traffico non viene trasferito alle risorse nella regione funzionante. Questo vale quando è attivo il routing globale.

Cloud Key Management Service

Cloud Key Management Service (Cloud KMS) fornisce una gestione delle risorse delle chiavi di crittografia scalabile e altamente durevole. Cloud KMS archivia tutti i suoi dati e metadati nei database Spanner, che offrono elevata durabilità e disponibilità dei dati con la replica sincrona.

Le risorse 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 provenienti 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 dei dati. Quando l'interruzione della zona è stata risolta, viene ripristinata la ridondanza completa.

In caso di interruzione a livello di regione, le risorse regionali in quella regione rimangono offline fino a quando la regione non diventa di nuovo disponibile. Tieni presente che anche all'interno di una regione vengono mantenute almeno tre repliche in zone separate. Quando è richiesta una maggiore disponibilità, le risorse devono essere archiviate in una configurazione multi-regione o globale. Le configurazioni multiregionali e globali sono progettate per rimanere disponibili in caso di interruzione del servizio a livello di regione archiviando e pubblicando i dati con geo-ridondanza in più di una regione.

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 di terze parti supportati. Puoi utilizzare queste chiavi esterne per criptare i dati a riposo da utilizzare per altri servizi Google Cloud che supportano l'integrazione delle chiavi di crittografia gestite dal cliente (CMEK).

• Interruzione zonale: Cloud External Key Manager è resiliente alle interruzioni zonali grazie alla ridondanza fornita da più zone in una regione. Se si verifica un'interruzione del servizio 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 è comunque disponibile.

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

Cloud External Key Manager non archivia i dati dei clienti in modo permanente. Di conseguenza, non si verifica alcuna perdita di dati durante un'interruzione del servizio a livello di regione all'interno del 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 non funzionano durante un'interruzione a livello regionale, potresti perdere dati. Il 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 devi gestire un'infrastruttura di bilanciamento del carico fisica. I bilanciatori del carico sono un componente fondamentale della maggior parte delle applicazioni a disponibilità elevata.

Cloud Load Balancing offre bilanciatori del carico sia a livello di regione sia globali. Fornisce inoltre il bilanciamento del carico tra regioni, incluso il failover automatico in più regioni, che trasferisce il traffico ai backend di failover se i backend principali non sono disponibili.

I bilanciatori del carico globali sono resilienti alle interruzioni sia zonali che regionali. I bilanciatori del carico regionali sono resilienti alle interruzioni zonali, ma sono interessati dalle interruzioni nella loro regione. Tuttavia, in entrambi i casi, è importante capire che la resilienza dell'applicazione complessiva non dipende solo dal tipo di bilanciatore del carico di cui esegui 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 di log e lo spazio di archiviazione di Cloud Logging.

Router dei log gestisce gli eventi log in streaming e indirizza i log allo spazio di archiviazione Cloud Storage, Pub/Sub, BigQuery o Cloud Logging.

Lo spazio di archiviazione di Cloud Logging è un servizio per l'archiviazione, le query e la gestione della conformità per i log. Supporta molti utenti e flussi di lavoro, tra cui sviluppo, compliance, risoluzione dei problemi e avvisi proattivi.

Router di log e log in entrata: durante un'interruzione di servizio zonale, l'API Cloud Logging indirizza i log ad altre zone della regione. In genere, i log instradati da Router dei log a Cloud Logging, BigQuery o Pub/Sub vengono scritti nella destinazione finale il prima possibile, mentre i log inviati a Cloud Storage vengono memorizzati nella memoria intermedia e scritti in batch ogni ora.

Voci di log: in caso di interruzione del servizio a livello di zona o regione, le voci di log che sono state messe in buffer nella zona o nella regione interessata e non sono state scritte nella destinazione dell'esportazione diventano inaccessibili. Le metriche basate su log vengono calcolate anche nel router dei log e sono soggette agli stessi vincoli. Una volta inviati alla posizione di esportazione 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. Pertanto, consigliamo 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 del servizio.

Metadati dei log:i metadati come la configurazione di sink ed esclusione vengono archiviati a livello globale, ma memorizzati nella cache a livello regionale, pertanto in caso di interruzione le istanze Log Router regionali continueranno a funzionare. Le interruzioni in 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 del tempo di attività.

Tutta la configurazione di Cloud Monitoring, incluse dashboard, controlli di uptime e criteri di avviso, è definita a livello globale. Tutte le modifiche vengono replicate in modo sincrono in più regioni. Pertanto, durante le interruzioni sia a livello di zona sia a livello di regione, le modifiche di configurazione riuscite sono durature. Inoltre, anche se possono verificarsi errori di lettura e scrittura temporanei quando una zona o una regione non funziona inizialmente, Cloud Monitoring reindirizza le richieste verso le zone e le regioni disponibili. In questo caso, puoi riprovare a modificare la configurazione con un backoff exponenciale.

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

• A livello di zona: durante un'interruzione a livello di zona, le letture e le scritture delle metriche non sono completamente disponibili per le risorse nella zona interessata. In pratica, Cloud Monitoring agisce come se la zona interessata non esistesse.

• Regionale: durante un'interruzione a livello di regione, le letture e le scritture delle metriche non sono completamente disponibili per le risorse nella regione interessata. In pratica, Cloud Monitoring agisce come se la regione interessata non esistesse.

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 che alimenta la tua rete Virtual Private Cloud in modo da fornire la Network Address Translation di origine (NAT di origine o SNAT) per le VM senza indirizzi IP esterni. Cloud NAT fornisce anche 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 zonale: Cloud NAT è resiliente ai guasti zonali 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: Cloud NAT è un prodotto regionale, pertanto non può resistere a un guasto regionale.

Router Cloud

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

In caso di interruzione di servizio a livello di zona, router Cloud con una configurazione ad alta disponibilità (HA) è resiliente ai guasti zonali. In questo caso, un'interfaccia potrebbe perdere la connettività, ma il traffico viene reindirizzato all'altra interfaccia tramite il routing dinamico utilizzando BGP.

In caso di interruzione del servizio a livello di regione, router Cloud è un prodotto regionale, pertanto non può resistere a un guasto regionale. Se i clienti hanno attivato la modalità di routing globale, il routing tra la regione in cui si è verificato l'errore e altre regioni potrebbe essere interessato.

Cloud Run

Cloud Run è un ambiente di calcolo stateless in cui i clienti possono eseguire il loro 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 bilanciati automaticamente nelle zone all'interno di una regione. Le istanze container vengono scalate automaticamente per soddisfare il traffico in entrata e sono bilanciate in base al carico tra le zone, se necessario. Ogni zona gestisce un programmatore che fornisce questa scalabilità automatica per zona. Inoltre, è consapevole del carico ricevuto dalle altre zone e eseguirà il provisioning di una capacità aggiuntiva all'interno della zona per consentire eventuali errori zonali.

Interruzione di servizio 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 dopo che i dati sono stati sottoposti a commit in un quorum all'interno di una regione. Poiché i dati vengono archiviati a livello di regione, anche le operazioni del piano dati non sono interessate da errori zonali. Il traffico verrà indirizzato automaticamente ad altre zone in caso di guasto zonale.

Interruzione a livello di regione: i clienti scelgono la regione Google Cloud in cui creare il servizio Cloud Run. I dati non vengono mai replicati tra le regioni. Il traffico dei clienti non verrà mai indirizzato a una regione diversa da Cloud Run. In caso di guasto regionale, Cloud Run diventerà nuovamente 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 maggiore disponibilità, se lo desiderano.

Cloud Shell

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

Cloud Shell non è adatto all'esecuzione di carichi di lavoro delle applicazioni, ma è pensato per casi d'uso educativi e di sviluppo interattivo. Ha limiti di quota di runtime per utente, si arresta automaticamente dopo un breve periodo di inattività e l'istanza è accessibile solo all'utente assegnato.

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

Cloud Source Repositories

Cloud Source Repositories consente agli utenti di creare e gestire repository di codice sorgente privato. Questo prodotto è progettato con un modello globale, quindi non è necessario configurarlo per la resilienza a livello di regione o zona.

Le operazioni git push contro Cloud Source Repositories, invece, replicano in modo sincrono l'aggiornamento del repository di origine in più zone di più regioni. Ciò significa che il servizio è resiliente alle interruzioni in una determinata regione.

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

La funzionalità di mirroring automatico dei repository da GitHub o Bitbucket può essere soggetta a problemi in questi prodotti. Ad esempio, il mirroring è interessato se GitHub o Bitbucket non possono avvisare Cloud Source Repositories dei nuovi commit o se Cloud Source Repositories non riesce a recuperare i contenuti dal repository aggiornato.

Spanner

Spanner è un database scalabile, ad alta disponibilità, multi-versione, con replica sincrona ed elevata coerenza con semantica relazionale.

Le istanze Spanner regionali replicano in modo sincrono i dati in tre zone di una singola regione. Una scrittura in un'istanza Spanner regionale viene inviata in modo sincrono a tutte e tre le repliche e confermata al cliente dopo che almeno due repliche (quorum di maggioranza di 2 su 3) hanno eseguito il commit della scrittura. In questo modo, Spanner è resiliente a un errore di zona perché fornisce l'accesso a tutti i dati, poiché le ultime scritture sono state memorizzate e con 2 repliche è ancora possibile ottenere un quorum di maggioranza per le scritture.

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/scrittura ciascuna nella regione leader predefinita e in un'altra regione; e una replica nella regione di testimone). Una scrittura in 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 in una zona o in una regione, Spanner ha accesso a tutti i dati (incluse le ultime scritture) e gestisce le richieste di lettura/scrittura poiché i dati vengono mantenuti in almeno 3 zone in 2 regioni al momento dell'acknowledgment della scrittura al client.

Per ulteriori informazioni su queste configurazioni, consulta la documentazione relativa alle istanze di Spanner 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 utilizza macchine virtuali Compute Engine gestite per eseguire il software di database. Offre una configurazione ad alta disponibilità per la ridondanza a livello di regione, proteggendo il database da un'interruzione della zona. È possibile eseguire il provisioning delle repliche tra regioni per proteggere il database da un'interruzione della regione. Poiché il prodotto offre anche un'opzione a livello di zona, che non è resiliente a un'interruzione di zona o regione, devi fare attenzione a selezionare la configurazione a disponibilità elevata, le repliche tra regioni o entrambe.

Interruzione zonale:l'opzione alta disponibilità crea un'istanza VM principale e una in standby in due zone distinte all'interno di una regione. Durante il normale funzionamento, l'istanza VM principale gestisce tutte le richieste, scrivendo i file di database su un disco permanente regionale, che viene replicato in modo sincrono nelle zone principale e standby. Se un'interruzione della 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 questa procedura, il database deve essere inizializzato, il che include l'elaborazione di eventuali transazioni registrate nel log delle transazioni, ma non applicate al database. Il numero e il tipo di transazioni non elaborate possono aumentare il tempo RTO. Un numero elevato di scritture recenti può 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 di database.

Infine, quando l'interruzione a livello di zona è stata risolta, puoi attivare manualmente un'operazione di failback per riprendere il servizio nella zona principale.

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

Interruzione a livello di regione:l'opzione Replica tra regioni protegge il database dalle interruzioni a livello di regione 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 che vengano eseguite nelle 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 "lag di replica" (che può essere monitorato). Questa metrica riflette sia le transazioni che non sono state inviate dalla tabella principale alle repliche sia le transazioni che sono state ricevute, ma non sono state elaborate dalla replica. Le transazioni non inviate alla replica non sarebbero 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 includa una replica per stabilire un limite di "transazioni sicure al secondo (TPS)", ovvero il TPS massimo sostenuto che non accumula ritardi di replica. Se il tuo workload supera il limite di TPS sicuro, il ritardo di replica si accumula, influenzando negativamente i valori RPO e RTO. Come linea guida generale, evita di utilizzare configurazioni di piccole istanze (< 2 core vCPU, dischi < 100 GB o DP-HDD), che sono soggette a ritardi di replica.

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

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

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

Per ulteriori informazioni sul ripristino dei dati di Cloud SQL, consulta quanto segue:

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

Cloud Storage

Cloud Storage offre uno spazio di archiviazione di oggetti unificato a livello globale, scalabile e a elevata durabilità. I bucket Cloud Storage possono essere creati in uno dei tre diversi tipi di località: in una singola regione, in una doppia regione o in una regione con più regioni all'interno di un continente. Con i bucket regionali, gli oggetti vengono archiviati in modo ridondante nelle zone di disponibilità di un'unica regione. I bucket con due o più regioni, invece, sono con ridondanza geografica. Ciò significa che dopo che i dati appena scritti sono stati replicati in almeno una regione remota, gli oggetti vengono archiviati in modo ridondante nelle regioni. Questo approccio offre ai dati nei bucket a due e più regioni un insieme più ampio di protezioni rispetto a quanto possibile con lo spazio di archiviazione a livello di regione.

I bucket regionali 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 nella zona non disponibile vengono pubblicati automaticamente e in modo trasparente da altre parti della regione. I dati e i metadati vengono archiviati in modo ridondante nelle zone, a partire dalla scrittura iniziale. Nessuna scrittura andrà persa se una zona non è più disponibile. In caso di interruzione a livello di regione, i bucket regionali in quella regione non sono disponibili finché la regione non diventa di nuovo disponibile.

Se hai bisogno di una maggiore disponibilità, puoi archiviare i dati in una configurazione di due o più regioni. I bucket con due regioni e con più regioni sono singoli bucket (non sono presenti posizioni principali e secondarie separate), ma archiviano dati e metadati in modo ridondante nelle regioni. In caso di interruzione regionale, il servizio non viene interrotto. Puoi considerare i bucket a due regioni e a più regioni come attivi-attivi in quanto puoi leggere e scrivere carichi di lavoro in più regioni contemporaneamente, mantenendo al contempo il bucket fortemente coerente. Questa soluzione può essere particolarmente interessante per i clienti che vogliono suddividere il loro carico di lavoro tra le due regioni nell'ambito di un'architettura di ripristino di emergenza.

Le regioni a due e più regioni sono fortemente coerenti perché i metadati vengono sempre scritti in modo sincrono nelle regioni. Questo approccio consente al servizio di determinare sempre qual è la versione più recente di un oggetto e da dove può essere pubblicato, anche da regioni remote.

I dati vengono replicati in modo asincrono. Ciò significa che esiste una finestra temporale RPO in cui gli oggetti appena scritti iniziano a essere protetti come oggetti a livello di regione, con ridondanza nelle zone di disponibilità all'interno di un'unica regione. Il servizio poi replica gli oggetti all'interno della finestra RPO in una o più regioni remote per renderli geo-ridondanti. Una volta completata la replica, i dati possono essere pubblicati automaticamente e in modo trasparente da un'altra regione in caso di interruzione regionale. La replica turbo è una funzionalità premium disponibile in 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 georidondanti entro 15 minuti.

L'RPO è un aspetto importante da considerare, perché durante un'interruzione a livello di regione, i dati scritti di recente nella regione interessata all'interno del periodo 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 calcolo attivi in più zone e regioni. supporta inoltre la replica sincrona dei dati tra le zone all'interno delle regioni. Queste funzionalità consentono a Translation di eseguire il failover istantaneo senza perdita di dati in caso di guasti zonali e senza richiedere alcun intervento o aggiustamento da parte del cliente. In caso di guasto regionale, Cloud Translation non è disponibile.

Compute Engine

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

Le istanze Compute Engine sono risorse di zona, pertanto in caso di interruzione del servizio in una zona, le istanze non sono disponibili per impostazione predefinita. Compute Engine offre gruppi di istanze gestite (MIG) che possono scalare automaticamente altre VM da modelli di istanze preconfigurati, sia all'interno di un'unica zona sia in più zone all'interno di una regione. I gruppi di istanze gestite sono ideali per le applicazioni che richiedono resilienza alla perdita di zone e sono stateless, ma richiedono pianificazione e configurazione delle risorse. È possibile utilizzare più MIG regionali per ottenere la resilienza alle interruzioni regionali per le applicazioni stateless.

Le applicazioni con carichi di lavoro stateful possono comunque utilizzare MIG stateful, ma è necessario prestare particolare attenzione alla pianificazione della capacità poiché non scalano orizzontalmente. In entrambi gli scenari è importante configurare e testare correttamente i modelli di istanze Compute Engine e i gruppi di istanze gestite in anticipo per garantire funzionalità di failover funzionanti in altre zone. Per ulteriori informazioni, consulta la sezione Sviluppare guide e architetture di riferimento sopra.

Single-tenancy

La modalità 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 Compute Engine, sono risorse a livello di zona. Nell'improbabile caso di un'interruzione di servizio a livello di zona, non sono disponibili. Per ridurre al minimo i guasti relativi alle zone, puoi creare un nodo single-tenant in un'altra zona. Poiché determinati carichi di lavoro potrebbero trarre vantaggio dai nodi monoproprietario per la licenza o la contabilità CAPEX, devi pianificare in anticipo una strategia di failover.

La ricreazione di queste risorse in una posizione diversa potrebbe comportare costi di licenza aggiuntivi o violare i requisiti di contabilità CAPEX. Per indicazioni generali, consulta Sviluppare guide e architetture di riferimento.

I nodi single-tenant sono risorse di zona e non possono resistere a guasti regionali. Per eseguire il ridimensionamento in più 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 degli indirizzi IP esterni in modalità globale o regionale, il che influisce sulla loro disponibilità in caso di guasto regionale.

Resilienza di Cloud Load Balancing

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

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

Ambito del bilanciatore del carico	Architettura	Resiliente alle interruzioni a livello di zona	Resiliente alle interruzioni a livello di regione
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 del servizio in una determinata regione interessa i bilanciatori del carico regionali 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 tua configurazione e, in alcuni casi, esegue un'analisi del piano dati in tempo reale tra gli endpoint. Un endpoint è una sorgente o una destinazione di traffico di rete, ad esempio una VM, un cluster Google Kubernetes Engine (GKE), una regola di inoltro del bilanciatore del carico o un indirizzo IP. Connectivity Tests è uno strumento di diagnostica senza componenti del piano dati. Non elabora né genera traffico utente.

Interruzione zonale:le risorse di Connectivity Tests sono globali. Puoi gestirli e visualizzarli in caso di interruzione zonale. Le risorse Connectivity Tests sono i risultati dei test di configurazione. Questi risultati potrebbero includere i dati di configurazione delle risorse zonali (ad esempio le istanze VM) in una zona colpita. In caso di interruzione del servizio, i risultati dell'analisi non sono accurati perché l'analisi si basa su dati obsoleti precedenti all'interruzione. Non fare affidamento su di essa.

Interruzione del servizio a livello di regione: in caso di interruzione del servizio a livello di regione, puoi comunque gestire e visualizzare le risorse di Connectivity Tests. Le risorse Connectivity Tests potrebbero includere dati di configurazione delle risorse regionali, come le subnet, in una regione colpita. In caso di interruzione del servizio, i risultati dell'analisi non sono accurati perché l'analisi si basa su dati obsoleti precedenti all'interruzione. Non fare affidamento su di essa.

Container Registry

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

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 vengono memorizzate in bucket Cloud Storage multiregionali. Con questa strategia di archiviazione, Container Registry offre resilienza in caso di interruzione zonale in tutti i casi e resilienza in caso di interruzione regionale per tutti i dati che sono stati replicati 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 da data center on-premise a Google Cloud.

Database Migration Service è progettato come piano di controllo regionale. Il piano di controllo non dipende da una singola zona in una determinata regione. Durante un'interruzione zonale, mantieni l'accesso alle API di Database Migration Service, inclusa la possibilità di creare e gestire i job di migrazione. Durante un'interruzione a livello di regione, non potrai accedere alle risorse di Database Migration Service appartenenti a quella regione finché l'interruzione non sarà risolta.

Database Migration Service dipende dalla disponibilità dei database di origine e di destinazione utilizzati per la procedura di migrazione. Se un database di origine o di destinazione di Database Migration Service non è disponibile, le migrazioni non avanzano, ma non vengono persi dati di base del cliente o dei 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 zonali.

Le migrazioni di Database Migration Service passano attraverso due fasi:

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

Interruzione di servizio a livello di zona:se si verifica un errore a livello di zona durante una di queste fasi, puoi comunque accedere e gestire le risorse in Database Migration Service. La migrazione dei dati è interessata nel seguente modo:

• Dump completo: la migrazione dei dati non va a buon fine. Devi riavviare il job di migrazione al termine dell'operazione di failover del database di destinazione.
• CDC: la migrazione dei dati è in pausa. Il job di migrazione riprende automaticamente al termine dell'operazione di failover del database di destinazione.

Interruzione a livello di regione: Database Migration Service non supporta le risorse interregionali e, pertanto, non è resiliente ai guasti a livello di regione.

Dataflow

Dataflow è il servizio di elaborazione dei dati completamente gestito e serverless di Google Cloud per le pipeline di streaming e batch. Per impostazione predefinita, un endpoint regionale configura il pool di worker Dataflow in modo da utilizzare tutte le zone disponibili all'interno della regione. La selezione delle zone viene calcolata per ogni worker al momento della sua creazione, ottimizzando l'acquisizione delle risorse e l'utilizzo delle prenotazioni inutilizzate. Nella configurazione predefinita per i job Dataflow, i dati intermedi vengono memorizzati dal servizio Dataflow e lo stato del job viene archiviato nel backend. Se una zona non funziona, i job Dataflow possono continuare a essere eseguiti perché i worker vengono ricreati 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 che hanno 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 relative a Streaming Engine e Dataflow Shuffle.
• Le VM non vengono replicate in più zone. Se una VM non è più disponibile, i relativi elementi di lavoro vengono considerati persi e vengono sottoposti a rielaborazioni da un'altra VM.
• Se si verifica un esaurimento delle scorte a livello di regione, il servizio Dataflow non può creare altre VM.

Progettazione di pipeline Dataflow per l'alta disponibilità

Puoi eseguire più pipeline di streaming in parallelo per l'elaborazione di dati ad alta disponibilità. Ad esempio, puoi eseguire due job di streaming in parallelo in regioni diverse. L'esecuzione di pipeline parallele fornisce ridondanza geografica e tolleranza di errore per l'elaborazione dei dati. Se prendi in considerazione la disponibilità geografica delle origini e delle destinazioni dati, puoi gestire pipeline end-to-end in una configurazione multiregionale altamente disponibile. Per ulteriori informazioni, consulta Elevata disponibilità e ridondanza geografica in "Disegna i flussi di lavoro delle pipeline Dataflow".

In caso di interruzione del servizio in una zona o una regione, puoi evitare la perdita di dati riutilizzando lo stesso abbonamento all'argomento Pub/Sub. Per garantire che i record non vengano persi durante lo shuffle, Dataflow utilizza il backup a monte, il che significa che il worker che invia i record esegue nuovamente le RPC finché non riceve un conferma positiva che il record è stato ricevuto e che gli effetti collaterali dell'elaborazione del record sono stati applicati allo spazio di archiviazione permanente a valle. Inoltre, Dataflow continua a riprovare le chiamate RPC se il worker che invia i record diventa non disponibile. Il nuovo tentativo delle RPC garantisce che ogni record venga inviato esattamente una volta. Per ulteriori informazioni sulla garanzia exactly-once di Dataflow, consulta Exactly-once in Dataflow.

Se la pipeline utilizza il raggruppamento o le finestre temporali, puoi utilizzare la funzionalità di ricerca di Pub/Sub o la funzionalità di replay di Kafka dopo un'interruzione zonale o regionale per rielaborare gli elementi di dati e ottenere gli stessi risultati di calcolo. Se la logica di business utilizzata dalla pipeline non si basa su dati precedenti all'interruzione, la perdita di dati delle uscite della pipeline può essere ridotta al minimo fino a 0 elementi. Se la logica di business della pipeline si basa su dati che sono stati elaborati prima dell'interruzione (ad esempio se vengono utilizzate finestre scorrevoli lunghe o se una finestra temporale globale memorizza contatori in costante aumento), utilizza gli snapshot di Dataflow per salvare lo stato della pipeline di inserimento flussi e avviare una nuova versione del job senza perdere lo stato.

Dataproc

Dataproc fornisce funzionalità di elaborazione dei dati in flussi e in batch. Dataproc è progettato come un control plane regionale che consente agli utenti di gestire i cluster Dataproc. Il piano di controllo non dipende da una singola zona in una determinata regione. Pertanto, durante un'interruzione di servizio a livello di zona, mantieni l'accesso alle API Dataproc, inclusa 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 di servizio zonale rende il cluster non disponibile o lo distrugge. Dataproc non acquisisce automaticamente lo stato del cluster, pertanto un interruzione del servizio in una zona potrebbe causare la perdita dei dati in fase di elaborazione. Dataproc non memorizza i dati utente all'interno del servizio. Gli utenti possono configurare le pipeline per scrivere i risultati in molti data store. Devi prendere in considerazione l'architettura del datastore e scegliere un prodotto che offra la resilienza necessaria in caso di disastri.

Se una zona presenta un'interruzione, puoi scegliere di ricreare una nuova istanza del cluster in un'altra zona selezionando una zona diversa o utilizzando la funzionalità 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 influisca su un nodo master e, di conseguenza, sull'intero cluster.

Cluster Dataproc su GKE

I cluster Dataproc su GKE possono essere zonali o regionali.

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

Datastream

Datastream è un servizio di replica e CDC (Change Data Capture) serverless che consente di sincronizzare i dati in modo affidabile e con latenza minima. Datastream fornisce la replica dei dati dai database operativi in BigQuery e Cloud Storage. Inoltre, offre un'integrazione semplificata con i modelli Dataflow per creare flussi di lavoro personalizzati per il caricamento dei dati in un'ampia gamma di destinazioni, come Cloud SQL e Spanner.

Interruzione a livello di zona: Datastream è un servizio multizonale. Può resistere a un'interruzione zonale completa e imprevista senza alcuna perdita di dati o disponibilità. In caso di errore a livello di zona, puoi comunque accedere e gestire le tue risorse in Datastream.

Interruzione a livello di regione: in caso di interruzione a livello di regione, Datastream diventa di nuovo disponibile non appena l'interruzione viene risolta.

Document AI

Document AI è una piattaforma di comprensione dei documenti che acquisisce i dati non strutturati dei documenti e li trasforma in dati strutturati, semplificandone 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 bilanciati automaticamente nelle zone all'interno di una regione. I server vengono scalati automaticamente per soddisfare il traffico in entrata e il bilanciamento del carico avviene tra le zone, se necessario. Ogni zona gestisce un programmatore che fornisce questo autoscaling per zona. Lo scheduler è consapevole anche del carico ricevuto dalle altre zone e prevede una capacità aggiuntiva in-zone per consentire eventuali errori zonali.

Interruzione di servizio a livello di zona: Document AI archivia i documenti degli utenti e i dati sulle versioni dei processori. 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 zonali. Il traffico viene indirizzato automaticamente ad altre zone in caso di guasto zonale, con un ritardo basato sul tempo necessario per il recupero dei servizi dipendenti, come Vertex AI.

Interruzione del servizio a livello di regione:i dati non vengono mai replicati tra le regioni. In caso di 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 indirizzato 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 controllo dell'accesso basato sulla sicurezza e sull'affidabilità dei dispositivi nell'ambito della soluzione Chrome Enterprise Premium.

Utilizza la verifica degli endpoint quando vuoi una panoramica dell'approccio alla sicurezza dei laptop e dei computer della tua organizzazione. Quando la verifica degli endpoint viene accoppiata alle offerte Chrome Enterprise Premium, aiuta a applicare il controllo dell'accesso granulare alle risorse Google Cloud.

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

Eventarc

Eventarc fornisce eventi pubblicati in modo asincrono da fornitori 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 funzione Cloud Run di 2ª generazione) in modo che vengano attivate quando si verifica un evento in un servizio del fornitore di eventi o nel codice del cliente.

Interruzione di servizio zonale:Eventarc archivia i metadati relativi agli attivatori. Questi dati vengono archiviati a livello di regione e scritti in modo sincrono. L'API Eventarc che crea e gestisce gli attivatori e i canali restituisce la chiamata API solo quando i dati sono stati sottoposti a commit a un quorum all'interno di una regione. Poiché i dati vengono archiviati a livello di regione, le operazioni del piano dati non sono interessate da errori circoscritti a una zona. In caso di guasto zonale, il traffico viene indirizzato automaticamente ad altre zone. I servizi Eventarc per la ricezione e l'invio di eventi di terze parti e di proprietà di terze parti vengono replicati nelle varie zone. Questi servizi sono distribuiti a livello regionale. Le richieste alle zone non disponibili vengono eseguite automaticamente dalle zone disponibili nella regione.

Interruzione a livello di regione:i clienti scelgono la regione Google Cloud in cui creare gli attivatori Eventarc. I dati non vengono mai replicati tra regioni. Il traffico dei clienti non viene mai indirizzato da Eventarc a una regione diversa. In caso di guasto regionale, Eventarc diventa di nuovo disponibile non appena l'interruzione viene risolta. Per ottenere una disponibilità più elevata, i clienti sono invitati a eseguire il deployment degli attivatori in più regioni, se lo desiderano.

Tieni presente quanto segue:

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

Filestore

I livelli di base e HighScale sono risorse a livello di zona. Non sono tolleranti al fallimento della zona o della regione di cui è stato eseguito il deployment.

Le istanze Filestore di livello Enterprise sono risorse regionali. Filestore adotta il criterio di coerenza rigorosa richiesto da NFS. Quando un client scrive dati, Filestore non restituisce un conferma finché la modifica non viene mantenuta e replicata in due zone in modo che le letture successive restituiscano i dati corretti.

In caso di errore a livello di zona, un'istanza di livello Enterprise continua a fornire dati da altre zone e nel frattempo accetta nuove scritture. Sia le operazioni di lettura che quelle di scrittura potrebbero avere un calo delle prestazioni; l'operazione di scrittura potrebbe non essere replicata. La crittografia non è compromessa perché la chiave verrà fornita da altre zone.

Consigliamo ai clienti di creare backup esterni in caso di ulteriori interruzioni in altre zone della stessa regione. Il backup può essere utilizzato per ripristinare l'istanza in altre regioni.

Firestore

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

Firestore offre ai clienti località sia a livello di una sola regione sia a livello di più regioni. Il traffico viene bilanciato automaticamente tra le zone di una regione.

Le istanze Firestore regionali replicano i dati in modo sincrono su almeno tre zone. In caso di errore zonale, le scritture possono essere ancora committate dalle due (o più) repliche rimanenti e i dati committati vengono mantenuti. Il traffico viene indirizzato automaticamente ad altre zone. Una località a livello di regione offre costi inferiori, latenza di scrittura inferiore e co-locazione con altre risorse Google Cloud.

Le istanze multiregionali di Firestore replicano i dati in modo sincrono in cinque zone di tre regioni (due regioni di servizio e una regione di testimone) e sono resistenti ai guasti a livello di zona e di regione. In caso di errore a livello di zona o di regione, i dati committati vengono mantenuti. Il traffico viene instradato automaticamente alle zone/regioni di pubblicazione e i commit vengono comunque pubblicati 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 approfondimenti, suggerimenti e metriche sull'utilizzo delle regole firewall. Firewall Insights utilizza anche il machine learning per prevedere l'utilizzo futuro delle regole firewall. Firewall Insights ti 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ù rigorosa la configurazione del firewall.

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

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

Parco risorse

I parchi risorse consentono ai clienti di gestire più cluster Kubernetes come un gruppo e agli amministratori della 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 regionale nella stessa regione. Quando registri un cluster non Google Cloud a un parco risorse, puoi scegliere qualsiasi regione o la posizione globale. La best practice è scegliere una regione vicina alla sede fisica del cluster. In questo modo, la latenza è ottimale quando utilizzi Connect Gateway per accedere al cluster.

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

In caso di interruzione a livello di regione, le funzionalità del parco risorse non vanno a buon fine in modo statico per i cluster di appartenenza in regione. La mitigazione di un'interruzione regionale richiede il deployment in più regioni, come suggerito da Architecting ripristino di emergenza for cloud infrastructure outages.

Google Cloud Armor

Google Cloud Armor ti aiuta a proteggere le tue implementazioni e le tue applicazioni da diversi tipi di minacce, inclusi attacchi DDoS volumetrici e attacchi alle applicazioni come cross-site scripting e SQL injection. Google Cloud Armor filtra il traffico indesiderato negli load balancer di Google Cloud e impedisce a questo traffico di entrare nel tuo VPC e di consumare risorse. Alcune di queste protezioni sono automatiche. Alcuni richiedono di configurare i criteri di sicurezza e di collegarli a regioni o servizi di backend. I criteri di sicurezza di Google Cloud Armor con ambito globale vengono applicati ai bilanciatori del carico globali. I criteri di sicurezza con ambito a livello di regione vengono applicati ai bilanciatori del carico regionali.

Interruzione del servizio a livello di zona: in caso di interruzione del servizio a livello di zona, i bilanciatori del carico di Google Cloud reindirizzano il traffico ad altre zone in cui sono disponibili istanze di backend funzionanti. 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 globali di Google Cloud reindirizzano il traffico ad altre regioni in cui sono disponibili istanze di backend funzionanti. La protezione di Google Cloud Armor è disponibile immediatamente dopo il failover del traffico perché i criteri di sicurezza di Google Cloud Armor globali vengono replicati in modo sincrono in tutte le regioni. Per essere resiliente ai guasti regionali, devi configurare i criteri di sicurezza regionale di Google Cloud Armor per tutte le regioni.

Google Kubernetes Engine

Google Kubernetes Engine (GKE) offre un servizio Kubernetes gestito semplificando il deployment di applicazioni containerizzate su Google Cloud. Puoi scegliere tra topologie di cluster regionali o zonali.

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

Interruzione a livello di zona:per evitare interruzioni a livello di zona, utilizza i cluster regionali. Il piano di controllo e i nodi sono distribuiti in tre zone diverse all'interno di una regione. Un'interruzione del servizio in una zona non influisce sui nodi del 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 multiregione è un approccio adottato oggi da diversi clienti GKE e può essere implementata manualmente. Puoi creare più cluster regionali per replicare i tuoi workload in più regioni e controllare il traffico verso questi cluster utilizzando Ingress multi-cluster.

VPN ad alta disponibilità

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

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

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

Interruzione del servizio regionale:in caso di interruzione del servizio regionale, 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 di 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 di dati IAM a riprendersi dai guasti di altre regioni e tollerando i guasti delle zone all'interno di ogni regione. La resilienza del piano di dati IAM contro i guasti delle zone e delle regioni consente di implementare architetture multi-regione e multi-zona per l'alta disponibilità.

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

Identity-Aware Proxy

Identity-Aware Proxy fornisce l'accesso alle applicazioni in hosting su Google Cloud, su altri cloud e on-premise. L'IAP è distribuito a livello di regione e le richieste alle zone non disponibili vengono eseguite automaticamente da altre zone disponibili della 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 una maggiore disponibilità e resilienza nei confronti delle interruzioni a livello di regione.

Identity Platform

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

Interruzione di servizio zonale:durante un'interruzione di servizio zonale, Identity Platform non riesce a gestire le richieste alla cella più vicina. Tutti i dati vengono salvati su scala globale, quindi non si verificano perdite di dati.

Interruzione del servizio a livello di regione: durante un'interruzione del servizio a livello di regione, le richieste di Identity Platform alla regione non disponibile non vanno a buon fine temporaneamente, mentre Identity Platform rimuove il traffico dalla regione interessata. Quando non c'è più traffico nella regione interessata, un servizio di bilanciamento del carico del server globale instrada le richieste alla regione integra più vicina disponibile. Tutti i dati vengono salvati a livello globale, quindi non si verificano perdite 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 i carichi di lavoro di Knative serving vengano implementati correttamente nei cluster dei clienti e che lo stato di installazione di Knative serving sia riportato nella risorsa della funzionalità dell'API GKE Fleet. Questo servizio viene utilizzato solo durante l'installazione o l'upgrade delle risorse Knative serving sui cluster dei clienti. Non è coinvolto nell'esecuzione dei carichi di lavoro del cluster. I cluster dei clienti appartenenti ai progetti in cui è attivato il servizio Knative vengono distribuiti tra le repliche in più regioni e zone: ogni cluster viene monitorato da una replica.

Interruzione a livello di zona e di regione: i cluster monitorati da repliche ospitate in una località in cui si verifica un'interruzione vengono ridistribuiti automaticamente tra le repliche funzionanti in altre zone e regioni. Mentre questa 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 attivare le funzionalità di Knative serving sul cluster, l'installazione delle risorse di Knative serving sul cluster inizierà dopo che il cluster si sarà ricollegato a una replica del servizio Knative serving funzionante.

Looker (Google Cloud core)

Looker (Google Cloud core) è una piattaforma di business intelligence che fornisce provisioning, configurazione e gestione semplificati e senza problemi di un'istanza di 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 modellisti di dati e funzionalità di API e incorporamento avanzate per gli sviluppatori.

Looker (Google Cloud core) è composto da istanze isolate a livello di regione che replicano in modo sincrono i dati tra le 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 di servizio a livello di zona: le istanze di Looker (Google Cloud core) archiviano i metadati e i propri container di cui è stato eseguito il deployment. I dati vengono scritti in modo sincrono nelle istanze replicate. In caso di interruzione a livello di zona, le istanze di Looker (Google Cloud core) continuano a essere pubblicate da altre zone disponibili nella stessa regione. Eventuali transazioni o chiamate API vengono restituite dopo che i dati sono stati sottoposti a commit a un quorum all'interno di una regione. Se la replica non va a buon fine, la transazione non viene confermata e l'utente riceve una notifica dell'errore. Se più di una zona non va a buon fine, anche le transazioni non vanno a buon fine e l'utente riceve una notifica. Looker (Google Cloud core) interrompe eventuali pianificazioni o query in esecuzione. Devi riprogrammarli o metterli di nuovo in coda dopo aver risolto l'errore.

Interruzione del servizio a livello di regione: le istanze di Looker (Google Cloud core) all'interno della regione interessata non sono disponibili. Looker (Google Cloud core) interrompe eventuali pianificazioni o query in esecuzione. Devi riprogrammare o mettere di nuovo in coda le query dopo aver risolto l'errore. Puoi creare manualmente nuove istanze in una regione diversa. Puoi anche recuperare le istanze utilizzando la procedura descritta in Importa o esporta i dati da un'istanza di Looker (Google Cloud core). Ti consigliamo di configurare una procedura di esportazione periodica dei dati per copiare gli asset in anticipo, nell'improbabile eventualità di un'interruzione del servizio a livello regionale.

Looker Studio

Looker Studio è un prodotto di business intelligence e visualizzazione dei dati. Consente ai clienti di connettersi ai propri dati archiviati in altri sistemi, di creare report e dashboard utilizzando questi dati e di condividerli all'interno dell'organizzazione. Looker Studio è un servizio globale e non consente agli utenti di selezionare l'ambito di una risorsa.

In caso di interruzione a livello di zona, Looker Studio continua a gestire le richieste provenienti da un'altra zona della stessa regione o di un'altra regione senza interruzione. Le risorse utente vengono replicate in modo sincrono nelle varie regioni. Di conseguenza, non si verifica alcuna perdita 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 vengono replicati in modo sincrono tra le regioni. Di conseguenza, non si verifica alcuna perdita 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 che possono essere utilizzati come database chiave-valore ad alta velocità effettiva per le applicazioni.

I cluster Memcached sono regionali, con nodi distribuiti in tutte le zone specificate dal cliente. Tuttavia, Memcached non esegue la replica dei dati tra i nodi. Pertanto, un errore a livello di zona può causare la perdita di dati, descritta anche come svuotamento parziale della cache. Le istanze Memcached continueranno a funzionare, ma avranno meno nodi, poiché il servizio non ne avvierà di nuovi durante un errore zonale. I nodi Memcached nelle zone non interessate continueranno a gestire il traffico, anche se l'errore zonale comporterà un tasso di successo della cache inferiore fino al recupero della zona.

In caso di errore regionale, i nodi Memcached non gestiscono il traffico. In questo caso, i dati andranno persi e verrà eseguito uno svuotamento completo della cache. Per mitigare un'interruzione regionale, puoi implementare un'architettura che distribuisca l'applicazione e Memorystore per Memcached in più regioni.

Memorystore for Redis

Memorystore for Redis è un servizio Redis completamente gestito per Google Cloud che può ridurre il carico di gestione dei deployment Redis complessi. Al momento offre 2 livelli: livello base e Standard. Per il livello di base, un'interruzione a livello di singola regione o di più regioni causerà la perdita di dati, nota anche come svuotamento completo della cache. Per il livello Standard, un'interruzione a livello regionale causerà la perdita di dati. Un'interruzione a livello di zona potrebbe causare la perdita parziale dei dati nell'istanza di livello standard a causa della replica asincrona.

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

Interruzione di servizio a livello di zona: le istanze di livello standard replicano in modo asincrono le operazioni sul set di dati dal set di dati nel nodo principale al nodo di replica. Quando l'interruzione si verifica all'interno della zona del nodo principale, il nodo replica verrà promosso a nodo principale. 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 Alta disponibilità di Memorystore for Redis.

Se attivi 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 zonale. Per ulteriori informazioni sul ripristino di emergenza delle repliche di lettura, consulta Modalità di errore per le repliche di lettura.

Interruzione del servizio a livello di regione: Memorystore for Redis è un prodotto regionale, pertanto una singola istanza non può resistere a un errore a livello di regione. Puoi pianificare attività periodiche per esportare un'istanza Redis in un bucket Cloud Storage in un'altra regione. In caso di interruzione del servizio a livello di regione, puoi ripristinare l'istanza Redis in una regione diversa da quella del set di dati che hai esportato.

Multi-Cluster Service Discovery e Ingress multi-cluster

I servizi multi-cluster di GKE (MCS) sono costituiti da più componenti. I componenti includono l'hub Google Kubernetes Engine (che orchestra più cluster Google Kubernetes Engine utilizzando le iscrizioni), i cluster stessi e i controller dell'hub GKE (Ingress multi-cluster, Multi-Cluster Service Discovery). I controller hub orchestrano la configurazione del bilanciatore del carico di Compute Engine utilizzando i backend su più cluster.

In caso di interruzione del servizio a livello di zona, Multi-Cluster Service Discovery continua a gestire le richieste da un'altra zona o regione. In caso di interruzione del servizio a livello di regione, Multi-Cluster Service Discovery non esegue il failover.

In caso di interruzione di servizio zonale per Ingress multi-cluster, se il cluster di configurazione è zonale e rientra nell'ambito dell'errore, l'utente deve eseguire manualmente il failover. Il piano di dati è fail-static e continuerà a gestire il traffico fino al trasferimento dell'utente. Per evitare la necessità di un failover manuale, utilizza un cluster regionale per il cluster di configurazione.

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

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

Network Analyzer

Network Analyzer monitora automaticamente le configurazioni di rete VPC e rileva configurazioni errate e configurazioni non ottimali. Fornisce approfondimenti su topologia di rete, regole firewall, route, dipendenze di configurazione e connettività a servizi e applicazioni. Identifica gli errori di rete, fornisce informazioni sulla causa principale e suggerisce possibili soluzioni.

Network Analyzer viene eseguito continuamente e attiva analisi pertinenti in base agli aggiornamenti della configurazione quasi in tempo reale nella tua rete. Se Network Analyzer rileva un errore di rete, tenta di correlarlo alle modifiche alla configurazione recenti 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 utente.

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

Se gli approfondimenti di Network Analyzer contengono configurazioni di una zona in cui si è verificata un'interruzione del servizio, la qualità dei dati ne risente. Le statistiche di rete che fanno riferimento alle configurazioni in quella zona diventano obsolete. Non fare affidamento su alcun insight fornito da Network Analyzer durante le interruzioni del servizio.

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

Se gli approfondimenti di Network Analyzer contengono configurazioni di una regione in cui si è verificata un'interruzione del servizio, la qualità dei dati ne risente. Le statistiche sulla rete che fanno riferimento alle configurazioni nella regione diventano obsolete. Non fare affidamento su alcun insight fornito da Network Analyzer durante le interruzioni del servizio.

Network Topology

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

Interruzione di servizio zonale:in caso di interruzione di servizio zonale, i dati relativi alla zona in questione non verranno visualizzati in Network Topology. I dati relativi alle altre zone non sono interessati.

Interruzione del servizio a livello di regione: in caso di interruzione del servizio a livello di regione, i dati relativi alla regione in questione non verranno visualizzati 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 sulle prestazioni delle risorse del tuo progetto.

Con queste funzionalità di monitoraggio delle prestazioni, puoi distinguere tra un problema nell'applicazione e un problema nella rete Google Cloud sottostante. Puoi anche esaminare i problemi storici di rendimento della rete. Performance Dashboard esporta i dati anche in Cloud Monitoring. Puoi utilizzare il monitoraggio per eseguire query sui dati e accedere a informazioni aggiuntive.

Interruzione zonale:

In caso di interruzione a livello di zona, i dati relativi a latenza e perdita di pacchetti per il traffico proveniente dalla zona interessata non vengono 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 sulla latenza e sulla perdita di pacchetti riprendono.

Interruzione a livello di regione:

In caso di interruzione a livello di regione, i dati relativi a latenza e perdita di pacchetti per il traffico proveniente 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 sulla latenza e sulla perdita di pacchetti riprendono.

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 centralizzata funge da hub e ogni risorsa di connettività funge da spoke. Attualmente gli spoke ibride supportano VPN ad alta disponibilità, Dedicated Interconnect e Partner Interconnect, nonché appliance router SD-WAN dei principali fornitori di terze parti. Con gli spoke ibridi di Network Connectivity Center, le aziende possono collegare i carichi di lavoro e i servizi Google Cloud a data center on-premise, altri cloud e alle loro filiali tramite la copertura globale della rete Google Cloud.

Interruzione di servizio zonale:uno spoke ibrido di Network Connectivity Center con configurazione HA è resiliente ai guasti zonali perché il piano di controllo e il piano di 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, pertanto non può resistere a un errore regionale.

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 anycast annunciato a livello mondiale può fungere da frontend per i backend regionali o globali. Con il livello Standard, un indirizzo IP di livello Standard annunciato a livello regionale può fungere da frontend per i backend regionali. La resilienza complessiva di un'applicazione è influenzata sia dal livello del servizio di rete sia dalla ridondanza dei backend a cui è associata.

Interruzione a livello di zona: sia il livello Premium che quello Standard offrono resilienza contro le interruzioni a livello di zona se associati a backend ridondanti a livello di regione. Quando si verifica un'interruzione nella zona, il comportamento di failover per i casi che utilizzano backend ridondanti a livello di regione è determinato dagli stessi backend associati. Se associato con backend zonali, il servizio diventerà di nuovo disponibile non appena il disattivazione sarà risolta.

Interruzione a livello di regione:il livello Premium offre resilienza contro le interruzioni a livello di regione quando è associato a backend globalmente ridondanti. Nel livello Standard, tutto il traffico verso la regione interessata non andrà a buon fine. Il traffico verso tutte le altre regioni rimane unaffected. Quando si verifica un'interruzione a livello di regione, il comportamento di failover per le richieste che utilizzano il livello Premium con backend globalmente ridondanti è determinato dagli stessi backend associati. Se utilizzi il livello Premium con backend regionali o il livello Standard, il servizio diventerà di nuovo disponibile non appena l'interruzione sarà risolta.

Servizio Criteri dell'organizzazione

Il servizio Criteri dell'organizzazione offre un controllo centralizzato e programmatico sulle risorse Google Cloud della tua organizzazione. In qualità di amministratore dei criteri dell'organizzazione, puoi configurare i vincoli in tutta la gerarchia delle risorse.

Interruzione a livello di zona: tutti i criteri dell'organizzazione creati da Organization Policy Service vengono replicati in modo asincrono in più zone all'interno di ogni regione. I dati dei criteri dell'organizzazione e le operazioni del piano di controllo sono tolleranti nei confronti degli errori delle zone all'interno di ogni regione.

Interruzione del servizio a livello di regione:tutti i criteri dell'organizzazione creati dal servizio Organization Policy vengono replicati in modo asincrono in più regioni. Le operazioni del piano di controllo dei criteri dell'organizzazione vengono scritte in più regioni e la propagazione alle altre regioni è coerente entro pochi minuti. Il piano di controllo dei criteri dell'organizzazione è resiliente al fallimento di una singola regione. Le operazioni del piano dati dei criteri dell'organizzazione possono recuperare dai guasti in altre regioni e la resilienza del piano dati dei criteri dell'organizzazione ai guasti delle zone e delle regioni consente architetture multiregione e multizona per l'alta disponibilità.

Mirroring pacchetto

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

Per ulteriori informazioni sulla funzionalità di Mirroring pacchetto, consulta la pagina Panoramica del mirroring dei pacchetti.

Interruzione zonale: configura il bilanciatore del carico interno in modo che siano presenti istanze in più zone. In caso di interruzione del servizio in una zona, Mirroring pacchetto devia i pacchetti clonati in una zona funzionante.

Interruzione del servizio a livello di regione:Mirroring pacchetto è un prodotto regionale. Se si verifica un'interruzione regionale, i pacchetti nella regione interessata non vengono clonati.

Persistent Disk

I dischi permanenti sono disponibili in configurazioni zonali e regionali.

I dischi permanenti a livello di zona sono ospitati in un'unica zona. Se la zona del disco non è disponibile, il Persistent Disk non è disponibile fino alla risoluzione dell'interruzione della zona.

I dischi permanenti a livello di regione forniscono la replica sincrona dei dati tra due zone in una regione. In caso di interruzione nella zona della macchina virtuale, puoi collegare forzatamente un Persistent Disk regionale a un'istanza VM nella zona secondaria del disco. Per eseguire questa operazione, devi avviare un'altra istanza VM nella zona in questione o mantenere un'istanza VM in hot standby nella zona.

Per replicare in modo asincrono i dati in un disco permanente tra regioni, puoi utilizzare la replica asincrona del disco permanente (PD Async Replication), che fornisce una replica dell'archiviazione a blocchi con RTO e RPO bassi per il RE attivo-passivo tra regioni. Nell'improbabile caso di un'interruzione in una regione, la replica asincrona del disco permanente consente di eseguire il failover dei dati in una regione secondaria e di riavviare il carico di lavoro in quella regione.

Personalized Service Health

Personalized Service Health comunica le interruzioni del servizio pertinenti ai tuoi progetti Google Cloud. Fornisce più canali e procedure per visualizzare o integrare eventi che causano interruzioni (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 di servizio zonale:i dati vengono pubblicati da un database globale senza alcuna dipendenza da località specifiche. In caso di interruzione del servizio a livello di zona, Service Health è in grado di gestire le richieste e reindirizzare automaticamente il traffico alle zone della stessa regione che funzionano ancora. Service Health può restituire le chiamate API correttamente se è in grado di recuperare i dati sugli eventi dal database di Service Health.

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

Private Service Connect

Private Service Connect è una funzionalità della rete Google Cloud che consente ai consumer di accedere ai servizi gestiti in privato dall'interno della loro 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 propri consumer.

Endpoint Private Service Connect per i servizi pubblicati

Un endpoint Private Service Connect si connette ai servizi nella rete VPC dei produttori 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. In questo modo, l'utente consumer del servizio potrà assegnare un indirizzo IP virtuale dal proprio VPC per il servizio in questione.

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

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

Endpoint di Private Service Connect per le API di Google

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

Interruzione di servizio a livello di zona: il traffico di Private Service Connect dagli endpoint client VPC consumer può comunque accedere alle API di Google perché la connettività tra la VM e l'endpoint verrà trasferita automaticamente a un'altra zona funzionale nella stessa regione. Le richieste già inviate quando inizia un'interruzione del servizio dipenderanno dal comportamento di timeout e di ripetizione TCP del client per il recupero.

Per ulteriori dettagli, consulta la pagina sul recupero di Compute Engine.

Interruzione del servizio a livello di regione: Private Service Connect è un prodotto regionale. Non è resiliente alle interruzioni del servizio a livello di regione. I servizi gestiti multiregionali possono raggiungere un'alta disponibilità durante le interruzioni a livello di regione configurando gli 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 di dati. Gli argomenti Pub/Sub sono globali, il che significa che sono visibili e accessibili da qualsiasi località Google Cloud. Tuttavia, ogni messaggio viene archiviato in una singola regione Google Cloud, la più vicina all'editore e consentita dal criterio di località delle risorse. Pertanto, un argomento potrebbe avere messaggi archiviati in regioni diverse di Google Cloud. Il criterio di archiviazione dei messaggi di Pub/Sub può limitare le regioni in cui vengono archiviati i messaggi.

Interruzione zonale: quando viene pubblicato un messaggio Pub/Sub, viene scritto in modo sincrono nello spazio di archiviazione di almeno due zone all'interno della regione. Pertanto, se una singola zona non è più disponibile, non ci sono conseguenze visibili per i clienti.

Interruzione del servizio a livello di regione: durante un'interruzione del servizio a livello di regione, i messaggi archiviati all'interno della regione interessata non sono accessibili. Gli editori e gli abbonati che si connetterebbero alla regione interessata, tramite un endpoint regionale o globale, non riescono a connettersi. I publisher e gli abbonati che si connettono ad altre regioni possono ancora farlo e i messaggi disponibili in altre regioni vengono recapitati agli abbonati più vicini alla rete che dispongono di capacità.

Se la tua applicazione si basa sull'ordinamento dei messaggi, consulta i consigli dettagliati del team di Pub/Sub. Le garanzie di ordinamento dei messaggi vengono fornite su base regionale 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 regionale o zonale. Gli aggiornamenti dei 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 un'altra 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 per la gestione di secret e credenziali per Google Cloud. Con Secret Manager puoi controllare e limitare facilmente l'accesso ai secret, criptare i secret at-rest e assicurarti che le informazioni sensibili siano protette in Google Cloud.

In genere, le risorse Secret Manager vengono create con il criterio di replica automatica (consigliato), che ne consente la replica a livello globale. Se la tua organizzazione ha criteri che non consentono la replica globale dei dati dei secret, le risorse 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: in caso di interruzione a livello di zona, Secret Manager continua a gestire le richieste da un'altra zona nella stessa regione o in un'altra senza interruzioni. All'interno di ogni regione, Secret Manager gestisce sempre almeno due repliche in zone separate (nella maggior parte delle regioni, tre repliche). Quando l'interruzione della zona viene risolta, viene ripristinata la ridondanza completa.

Interruzione del servizio a livello di regione: in caso di interruzione del servizio 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ù di una regione (tramite la replica automatica o tramite la replica gestita dall'utente in più di una regione). Quando l'interruzione nella regione viene risolta, viene ripristinata la ridondanza completa.

Security Command Center

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

I rilevatori sono interessati da interruzioni sia regionali che zonali, in modi diversi. Durante un'interruzione del servizio a livello di regione, i rilevatori non possono generare nuovi risultati per le risorse regionali perché le risorse che dovrebbero essere sottoposte a scansione non sono disponibili.

Durante un'interruzione zonale, i rilevatori possono richiedere da alcuni minuti a diverse 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 peggiore scelto, gli agenti Container Threat Detection potrebbero esaurire lo spazio del buffer durante la connessione a una cella sana, il che potrebbe comportare la perdita di rilevamenti.

I risultati sono resilienti alle interruzioni sia a livello di regione sia a livello di zona perché vengono replicati in modo sincrono nelle varie regioni.

Sensitive Data Protection (inclusa l'API DLP)

Sensitive Data Protection fornisce servizi di classificazione, profiling, anonimizzazione, tokenizzazione e analisi del rischio per la privacy dei dati sensibili. Funziona in modo sincrono sui dati inviati nei campi delle richieste o in modo asincrono sui dati già presenti nei sistemi di spazio di archiviazione sul cloud. La protezione dei dati sensibili può essere invocata tramite gli endpoint globali o specifici per regione.

Endpoint globale:il servizio è progettato per essere resiliente ai guasti sia regionali che zonali. Se il servizio è sovraccaricato durante un errore, i dati inviati al metodo hybridInspect del servizio potrebbero andare persi.

Per creare un'architettura resistente agli errori, includi la logica per esaminare il rilevamento pre-errore più recente prodotto dal metodo hybridInspect. In caso di interruzione del servizio, i dati inviati al metodo potrebbero andare persi, ma non più di quelli degli ultimi 10 minuti prima dell'evento di errore. Se sono presenti risultati più recenti di 10 minuti prima dell'inizio dell'interruzione, significa che i dati che hanno generato il risultato non sono andati persi. In questo caso, non è necessario riprodurre nuovamente i dati precedenti al timestamp del rilevamento, anche se rientrano nell'intervallo di 10 minuti.

Endpoint regionale: gli endpoint regionali non sono resilienti ai fallimenti regionali. Se è necessaria la resilienza in caso di errore a livello di regione, valuta la possibilità di eseguire il passaggio a altre regioni. Le caratteristiche di guasto zonale sono le stesse riportate sopra.

Utilizzo dei servizi

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

Per ulteriori informazioni su Service Usage, consulta la documentazione di Service Usage.

Speech-to-Text

Speech-to-Text ti consente di convertire l'audio vocale in testo utilizzando tecniche di machine learning come i modelli di reti neurali. L'audio viene inviato in tempo reale dal microfono di un'applicazione o viene elaborato come batch di file audio.

Interruzione zonale:

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

• API Speech-to-Text 2: durante un'interruzione a livello di zona, la versione 2 dell'API Speech-to-Text continua a gestire le richieste da un'altra zona della stessa regione. Tuttavia, tutti i job attualmente in esecuzione nella zona con errori andranno persi. Gli utenti devono riprovare i job non riusciti, che verranno indirizzati automaticamente a una zona disponibile. L'API Speech-to-Text restituisce la chiamata API solo dopo che i dati sono stati sottoposti a commit a 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 in quella zona causa il fallimento del riconoscimento vocale, ma non si verifica alcuna perdita di dati.

Interruzione a livello di regione:

• API Speech-to-Text v1: la versione 1 dell'API Speech-to-Text non è interessata da errori regionali perché è un servizio globale multi-regione. Il servizio continua a gestire le richieste da un'altra regione senza interruzioni. Tuttavia, i job attualmente in esecuzione nella regione con problemi andranno persi. Gli utenti devono riprovare i job non riusciti, che verranno indirizzati automaticamente a una regione disponibile.

• API Speech-to-Text v2:

  • API Speech-to-Text multiregione versione 2, il servizio continua a gestire le richieste da un'altra zona della stessa regione senza interruzioni.

  • API Speech-to-Text versione 2 per una singola regione, il servizio limita l'esecuzione del job alla regione richiesta. La versione 2 dell'API Speech-to-Text non instrada il traffico verso un'altra regione e i dati non vengono replicati in un'altra regione. Durante un errore regionale, la versione 2 dell'API Speech-to-Text non è disponibile nella regione in questione. Tuttavia, diventa di nuovo disponibile quando l'interruzione viene risolta.

Storage Transfer Service

Storage Transfer Service gestisce i trasferimenti di dati da varie origini cloud a Cloud Storage, nonché verso, da 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 l'origine o la destinazione di un trasferimento non è disponibile, i trasferimenti non procedono. Tuttavia, non vengono persi dati principali dei clienti o dei job. I trasferimenti riprenderanno quando l'origine e la destinazione saranno di nuovo disponibili.

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

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

• I trasferimenti basati su agenti utilizzano agenti software installati sulla 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, tieni conto della disponibilità del file system. Ad esempio, se esegui agenti di trasferimento su più VM Compute Engine per trasferire dati a un'istanza Filestore di livello Enterprise (una risorsa di regione), ti consigliamo di posizionare le VM in zone diverse all'interno della regione dell'istanza Filestore.

  Se gli agenti non sono disponibili o se la loro connessione al file system viene interrotta, i trasferimenti non avanzano, ma non vengono persi dati. Se tutti i processi degli agenti vengono interrotti, il job di trasferimento viene messo in pausa finché non vengono aggiunti nuovi agenti al pool di agenti del trasferimento.

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

• Interruzione zonale: durante un'interruzione zonale, le API Storage Transfer Service rimangono disponibili e puoi continuare a creare job di trasferimento. Il trasferimento dei dati prosegue.

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

Vertex ML Metadata

Vertex ML Metadata ti consente di registrare i metadati e gli artefatti prodotti dal tuo sistema ML ed eseguire query su questi metadati per analizzare, eseguire il debug e controllare le prestazioni del tuo sistema ML o degli artefatti che produce.

Interruzione di servizio zonale:nella configurazione predefinita, Vertex ML Metadata offre protezione contro i guasti zonali. Il servizio viene implementato in più zone in ogni regione, con i dati replicati in modo sincrono in zone diverse all'interno di ogni regione. In caso di errore a livello di zona, le zone rimanenti prendono il controllo con un'interruzione minima.

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

Vertex AI Batch Prediction

La previsione batch consente agli utenti di eseguire previsioni batch su modelli di AI/ML sull'infrastruttura di Google. La previsione batch è un'offerta regionale. I clienti possono scegliere la regione in cui eseguire i job, ma non le zone specifiche all'interno di quella regione. Il servizio di previsione batch bilancia automaticamente il job in diverse zone all'interno della regione scelta.

Interruzione di servizio a livello di zona: la previsione in batch archivia i metadati per i job di previsione in batch all'interno di una regione. I dati vengono scritti in modo sincrono su più zone all'interno della regione. In caso di interruzione di una zona, la previsione batch perde parzialmente i worker che eseguono i job, ma li aggiunge automaticamente in altre zone disponibili. Se più tentativi di previsione in batch non vanno a buon fine, l'interfaccia utente indica lo stato del job come failed (non riuscito) nell'interfaccia utente e nelle richieste di chiamata all'API. Le richieste successive degli utenti di eseguire il job vengono instradate alle zone disponibili.

Interruzione del servizio a livello di regione: i clienti scelgono la regione Google Cloud in cui 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 inoltra mai le richieste di previsione a una regione diversa. Quando si verifica un errore a livello di regione, la previsione batch non è disponibile nella regione in questione. Diventa di nuovo disponibile al termine dell'interruzione. Consigliamo ai clienti di utilizzare più regioni per eseguire i job. In caso di interruzione del servizio 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 dei modelli ML in un repository centrale. Vertex AI Model Registry è un'offerta regionale con alta disponibilità e offre protezione contro le interruzioni a livello di zona.

Interruzione zonale:Vertex AI Model Registry offre protezione contro le interruzioni zonali. Il servizio viene implementato in tre zone in ogni regione, con i dati replicati in modo sincrono in zone diverse all'interno della regione. Se una zona non funziona, le zone rimanenti prendono il suo posto senza perdita di dati e con un'interruzione minima del servizio.

Interruzione a livello di regione: Vertex AI Model Registry è un servizio regionalizzato. Se una regione non funziona, il Registry dei modelli non viene eseguito in modalità di 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 eseguirà automaticamente il bilanciamento del carico tra le diverse zone all'interno della regione selezionata.

Interruzione zonale:la previsione online non memorizza contenuti dei clienti. Un'interruzione di servizio zonale comporta il fallimento dell'esecuzione della richiesta di previsione corrente. La previsione online può o meno riprovare automaticamente la richiesta di previsione a seconda del tipo di endpoint utilizzato. Nello specifico, un endpoint pubblico riproverà automaticamente, mentre un endpoint privato no. Per gestire gli errori e migliorare la resilienza, incorpora nel codice la logica per i nuovi tentativi con backoff esponenziale.

Interruzione del servizio a livello di regione:i clienti scelgono la regione Google Cloud in cui eseguire i modelli di AI/ML e i 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 regionale, il servizio di previsione online non è disponibile nella regione in questione. Diventa di nuovo disponibile quando l'interruzione viene risolta. Consigliamo ai clienti di utilizzare più regioni per eseguire i propri modelli di AI/ML. In caso di interruzione a livello di regione, indirizza il traffico a una regione diversa disponibile.

Vertex AI Pipelines

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

Interruzione di servizio zonale:nella configurazione predefinita, Vertex AI Pipelines offre protezione contro i guasti zonali. Il servizio viene implementato in più zone in ogni regione, con i dati replicati in modo sincrono in zone diverse all'interno della regione. In caso di errore a livello di zona, le zone rimanenti prendono il controllo con un'interruzione minima.

Interruzione a livello di regione: Vertex AI Pipelines è un servizio regionalizzato. In caso di interruzione del servizio a livello di regione, Vertex AI Pipelines non eseguirà il failover in un'altra regione. In caso di interruzione del servizio in una 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. Vertex AI Search viene distribuito e replicato automaticamente in più regioni all'interno di Google Cloud. Puoi configurare la posizione di archiviazione dei dati scegliendo una regione multipla supportata, ad esempio globale, Stati Uniti o UE.

Interruzione a livello di zona e di regione: UserEvents caricato su Vertex AI Search potrebbe non essere recuperabile a causa del ritardo nella replica asincrona. Altri dati e servizi forniti da Vertex AI Search rimangono disponibili grazie al failover automatico e alla 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 della regione. Il servizio di addestramento potrebbe bilanciare automaticamente l'esecuzione del job su diverse zone all'interno della regione.

Interruzione zonale: 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 restituisce un valore solo dopo che questi metadati sono stati sottoposti a commit a un quorum all'interno di una regione. Il job di addestramento potrebbe essere eseguito in una zona specifica. Un'interruzione di servizio zonale comporta il fallimento dell'esecuzione del job corrente. In questo caso, il servizio riprova automaticamente il job inviandolo a un'altra zona. Se più tentativi non vanno a buon fine, lo stato del job viene aggiornato in Non riuscito. Le richieste degli utenti successive per eseguire il job vengono instradate a una zona disponibile.

Interruzione del servizio a livello di regione: i clienti scelgono la regione Google Cloud in cui eseguire i job di addestramento. I dati non vengono mai replicati tra regioni. Vertex AI Training limita l'esecuzione dei job alla regione richiesta e non inoltra mai i job di addestramento a una regione diversa. In caso di guasto regionale, il servizio di addestramento Vertex AI non è disponibile nella regione in questione e diventa di nuovo disponibile quando l'interruzione del servizio viene risolta. Consigliamo ai clienti di utilizzare più regioni per eseguire i job e, in caso di interruzione del servizio a livello regionale, di indirizzarli a una regione diversa disponibile.

Virtual Private Cloud (VPC)

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

Interruzione zonale: se una rete VPC copre più zone e una zona non funziona, la rete VPC rimarrà in stato operativo per le zone operative. Il traffico di rete tra le risorse nelle zone sane continuerà a funzionare normalmente durante l'errore. Un errore zonale interessa solo il traffico di rete verso e proveniente dalle risorse nella zona in cui si verifica l'errore. Per ridurre l'impatto dei malfunzionamenti a livello di zona, consigliamo di non creare tutte le risorse in una singola zona. Quando crei le risorse, suddividile in più zone.

Interruzione a livello di regione: se una rete VPC copre più regioni e una regione non funziona, la rete VPC rimarrà in stato operativo per le regioni operative. Il traffico di rete tra le risorse nelle regioni funzionanti continuerà a lavorare normalmente durante l'errore. Un errore regionale interessa solo il traffico di rete verso e da risorse nella regione in cui si verifica l'errore. Per ridurre l'impatto dei malfunzionamenti regionali, ti consigliamo di distribuire le risorse su più regioni.

Controlli di servizio VPC

Controlli di servizio VPC è un servizio regionale. Con 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 replicati a livello di regione.

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

Interruzione del servizio a livello di regione: le API configurate per l'applicazione dei criteri di Controlli di servizio VPC nella regione interessata non sono disponibili finché la regione non diventa di nuovo disponibile. I clienti sono invitati a eseguire il deployment dei servizi applicati da Controlli di servizio VPC in più regioni se è richiesta una maggiore disponibilità.

Workflows

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

• Esegui il deployment ed esegui flussi di lavoro che connettono altri servizi esistenti utilizzando HTTP,
• automatizzare i processi, inclusa l'attesa delle risposte HTTP con nuovi tentativi automatici fino a un anno, e
• Implementa processi in tempo reale con esecuzioni a bassa latenza basate sugli eventi.

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

Interruzione di servizio zonale: il codice sorgente Workflows non è interessato dalle interruzioni di servizio zonali. 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 viene archiviato a livello di regione e scritto in modo sincrono: l'API control plane restituisce un valore solo dopo che questi metadati sono stati sottoposti a commit a un quorum all'interno di una regione. Anche le variabili e i risultati HTTP vengono memorizzati a livello di regione e scritti in modo sincrono, almeno ogni cinque secondi.

Se una zona non riesce, i flussi di lavoro vengono ripresi automaticamente in base agli ultimi dati memorizzati. Tuttavia, le richieste HTTP che non hanno già ricevuto risposte non vengono ripetute automaticamente. Utilizza i criteri di ripetizione per le richieste per le quali è possibile ripetere la richiesta in sicurezza, come descritto nella nostra documentazione.

Interruzione a livello di regione: Workflows è un servizio per regione. 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 è richiesta una maggiore disponibilità.

Cloud Service Mesh

Cloud Service Mesh ti consente di configurare un mesh di servizi gestito che si estende su più cluster GKE. Questa documentazione riguarda solo Cloud Service Mesh gestito. La variante in-cluster è self-hosted e devono essere seguite le linee guida della piattaforma standard.

Interruzione a livello di zona: la configurazione del mesh, poiché è memorizzata nel cluster GKE, è resiliente alle interruzioni a livello di zona purché il cluster sia regionale. I dati utilizzati dal prodotto per la contabilità interna vengono archiviati a livello regionale o globale e non sono interessati se una singola zona non è in servizio. Il piano di controllo viene eseguito nella stessa regione del cluster GKE supportato (per i cluster zonali è la regione contenente) e non è interessato dagli arresti anomali all'interno di un'unica zona.

Interruzione a livello di regione: Cloud Service Mesh fornisce servizi ai cluster GKE, che sono regionali o zonali. In caso di interruzione del servizio a livello regionale, Cloud Service Mesh non eseguirà il failover. Né GKE. I clienti sono invitati a eseguire il deployment di mesh costituiti da cluster GKE che coprono regioni diverse.

Service Directory

Service Directory è una piattaforma per scoprire, pubblicare e connettere servizi. Fornisce informazioni in tempo reale, in un'unica posizione, su tutti i tuoi servizi. Service Directory ti 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 Service Directory vengono create a livello di regione in base al parametro posizione specificato dall'utente.

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

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

---

1. Le regioni Messico, Montréal e Osaka hanno tre zone in uno o due data center fisici. Queste regioni sono in fase di espansione ad almeno tre data center fisici. Per ulteriori informazioni, consulta Località cloud e SLA della piattaforma Google Cloud. Per contribuire a migliorare l'affidabilità dei carichi di lavoro, valuta la possibilità di eseguire un deployment multiregionale.  ↩