Questa pagina è stata tradotta dall'API Cloud Translation.

Aree geografiche e regioni

I prodotti Google Cloud vengono forniti da specifici domini in errore a livello di regione e sono completamente supportati dagli accordi sul livello del servizio per garantire che tu stia progettando l'architettura delle tue applicazioni all'interno della struttura di Google Cloud.

I servizi dell'infrastruttura Google Cloud sono disponibili in diverse località in Nord America, Sud America, Europa, Asia, Medio Oriente e Australia. Queste località sono suddivise in regioni e zone. Puoi scegliere dove collocare le tue applicazioni per soddisfare i requisiti di latenza, disponibilità e durabilità.

Provalo

Se non conosci Google Cloud, crea un account per valutare le prestazioni dei nostri prodotti in scenari reali. I nuovi clienti ricevono anche 300 $ di crediti gratuiti per l'esecuzione, il test e il deployment dei carichi di lavoro.

Inizia gratuitamente

Aree geografiche 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.

Questi data center potrebbero essere di proprietà di Google e elencati nella pagina Località di Google Cloud oppure essere in affitto da fornitori di data center di terze parti. Per l'elenco completo delle sedi dei data center di Google Cloud, consulta il nostro certificato ISO/IEC 27001. Indipendentemente dal fatto che il data center sia di proprietà o in leasing, Google Cloud seleziona i data center e progetta la propria infrastruttura per fornire un livello uniforme di prestazioni, sicurezza e affidabilità.

Una zona è un'area di deployment per le risorse Google Cloud all'interno di una regione. Le zone devono essere considerate come un unico dominio in errore all'interno di una regione. Per eseguire il deployment di applicazioni a tolleranza di errore con disponibilità elevata e proteggerti da guasti imprevisti, esegui il deployment delle applicazioni in più zone in una regione.

Per proteggerti dalla perdita di un'intera regione a causa di calamità naturali, devi avere un piano di ripristino di emergenza e sapere come avviare la tua applicazione nell'improbabile caso in cui la regione principale venga persa. Per ulteriori informazioni, consulta le considerazioni sul deployment delle applicazioni.

Per ulteriori informazioni sulle risorse specifiche disponibili in ogni opzione di località, consulta le nostre località Cloud.

I servizi e le risorse di Google Cloud possono essere a livello di zona, a livello di regione o gestiti da Google in più regioni. Per saperne di più sul significato di queste opzioni per i tuoi dati, consulta la sezione sulla gestione geografica dei dati.

Google Cloud intende offrire un minimo di tre zone di disponibilità (zone fisicamente e logicamente distinte) in ogni regione per uso generico.

Risorse di zona

Le risorse di zona operano all'interno di una singola zona. Le interruzioni a livello di zona possono interessare alcune o tutte le risorse della zona. Un esempio di risorsa di zona è un'istanza di una macchina virtuale (VM) Compute Engine che si trova all'interno di una zona specifica.

Risorse regionali

Le risorse di regione sono risorse distribuite tramite deployment in modo ridondante in più zone all'interno di una regione, ad esempio applicazioni App Engine o gruppi di istanze gestite a livello di regione. Ciò offre loro una maggiore disponibilità rispetto alle risorse di zona.

Risorse multiregionali

Google gestisce più servizi Google Cloud in modo che siano ridondanti e distribuiti all'interno e tra le regioni. Questi servizi ottimizzano la disponibilità, le prestazioni e l'efficienza delle risorse. Di conseguenza, questi servizi richiedono un compromesso tra la latenza o il modello di coerenza. Questi compromessi sono documentati in base al prodotto.

I seguenti servizi hanno una o più località multiregionali oltre alle eventuali località regionali:

Artifact Registry
Bigtable
Sensitive Data Protection
API Cloud Healthcare
Cloud KMS
Container Registry
Spanner
Cloud Storage
Database Migration Service
Datastore
Firestore

Questi servizi multiregionali sono progettati per poter funzionare dopo la perdita di una singola regione.

Per ulteriori informazioni, consulta la sezione Prodotti disponibili in base alla località e la documentazione di ciascun prodotto.

Servizi globali

Google Cloud è stato progettato per operare a livello globale da zero esegue continuamente attività di manutenzione e upgrade 24 ore su 24, 7 giorni su 7, 365 giorni l'anno senza alcun disagio per te. La nostra dorsale globale offre una straordinaria flessibilità per il bilanciamento del carico e riduce la latenza per gli utenti finali grazie alle interconnessioni nelle vicinanze. Il nostro piano di gestione del cloud globale semplifica la gestione degli sviluppi multi-regione.

Servizi interni

Alla base e a supporto di molti servizi Google Cloud rivolti ai clienti c'è un insieme di servizi interni collaudati come Spanner, Colossus, Borg e Chubby.

Questi servizi interni sono bilanciati a livello globale su più regioni o dedicati a ogni regione in cui sono disponibili. Se i servizi sono bilanciati in base al carico in più regioni, implementiamo gli aggiornamenti progressivamente, regione per regione, il che ci consente di rilevare e risolvere i problemi senza influire sull'utilizzo del servizio. Nessuno di questi servizi interni è limitato a un singolo data center logico o a una singola regione.

I servizi interni globali possono essere eseguiti o replicati nelle seguenti regioni cloud:

Americhe

southamerica-west1
us-central1
us-east1
us-east4
us-west1
us-west4

Europa

europe-north1
europe-west1
europe-west4

Asia

asia-east1
asia-southeast1

Dipendenze dei servizi

In generale, per i servizi Google Cloud, se si verifica un errore in una singola regione, sono interessati solo i clienti che si trovano in quella regione; i clienti che hanno prodotti multiregione non sono interessati. Google Cloud ha implementato un'architettura significativa con l'obiettivo di prevenire errori correlati nelle varie regioni.

Tutti i servizi Google Cloud si basano su strumenti interni di base per fornire servizi fondamentali come la rete (all'interno e all'esterno dei data center), l'accesso ai data center e i sistemi di autorizzazione delle identità. Questi strumenti sono resilienti alle interruzioni del servizio a livello di regione, con l'obiettivo di evitare che una regione venga interessata se altre regioni non sono più disponibili.

Google Cloud fornisce indicazioni chiare su come i clienti possono progettare le proprie applicazioni per il livello di resilienza desiderato sul nostro sito web pubblico, in particolare per i prodotti Google Cloud di uso comune come Compute Engine, BigQuery, Pub/Sub e altri servizi.

Le nostre dipendenze principali sono elencate di seguito, a partire da quelle comuni a tutti i servizi, con la precisazione che i dettagli di implementazione di livello inferiore sono soggetti a modifiche.

Dipendenze comuni per tutti i servizi

Piano dati dell'identità per l'autenticazione e l'autorizzazione
Servizi interni che forniscono registrazione, archiviazione dei metadati e gestione del flusso di lavoro
L'accesso alle API di Google Cloud dipende da DNS, bilanciatori del carico distribuiti a livello globale e punti di presenza (PoP).
La configurazione delle risorse globali: ad esempio, i criteri IAM, le regole di firewall globali, le configurazioni dei bilanciatori del carico globali e gli argomenti Pub/Sub sono archiviati in database replicati.
Quando i servizi Google Cloud inviano richieste a endpoint controllati dal cliente, ad esempio Cloud EKM che recupera le chiavi del cliente o Pub/Sub che invia messaggi, queste richieste dipendono dalla nostra infrastruttura di rete globale per accedere a questi endpoint controllati dal cliente.

Servizi con dipendenze aggiuntive

Servizi Compute Engine
- I piani dati delle VM e Persistent Disk di Google Cloud dipendono da servizi Compute Engine e Cloud Storage di livello inferiore, come Borg e Colossus.
I servizi di archiviazione di Google Cloud e dell'infrastruttura come Spanner, Bigtable e Cloud Storage dipendono da:
- Infrastruttura di crittografia e gestione delle chiavi per il cliente (Cloud KMS / Cloud EKM) e infrastruttura interna per le chiavi di proprietà di Google
- Servizi interni per fornire il logging e il controllo dell'accesso ai dati
- Servizi di replica dei dati interni, in cui i dati dovrebbero essere disponibili in più regioni
- I backup e la replica configurati in modo esplicito in altre regioni dipendono dalla rete tra regioni
Servizi di messaggistica
- Pub/Sub si basa sulla nostra infrastruttura di rete globale per accedere agli endpoint controllati dal cliente
Servizi di networking
- Il bilanciamento del carico globale, il DNS e il failover tra regioni dipendono tutti dall'infrastruttura di rete fisica.
- La prevenzione di attacchi DDoS e simili dipende dall'infrastruttura di Compute Engine di livello inferiore.
Servizi gestiti e in hosting come GKE e Cloud SQL
- Dipendono da Compute Engine e da Container Registry o Artifact Registry per le immagini VM.
Infrastruttura di livello inferiore autonoma
- Il nostro piano di controllo interno a livello di cluster, che include Borg e i network fabric
- Spazio di archiviazione a livello di cluster, ad esempio Colossus
- Infrastruttura di crittografia e gestione delle chiavi

Mantenere e migliorare la disponibilità e la resilienza

L'SRE (Site Reliability Engineering) è l'organizzazione interna di Google dedicata al miglioramento di disponibilità, latenza, prestazioni e capacità. Le interruzioni e l'indisponibilità del servizio sono correlate al deployment di nuovo codice o a modifiche all'ambiente. Utilizzando le best practice del settore, l'SRE bilancia la necessità di rilasciare nuovo software e mantiene l'ambiente sicuro, con la consapevolezza che queste modifiche necessarie possono causare tempi di inattività.

Collaborazione con i clienti per creare servizi resilienti

Se hai esigenze mission critical e devi progettare la resilienza e il disaster recovery, i nostri team SRE/CRE e PSO possono collaborare con te per progettare le tue applicazioni in modo che colleghino più regioni e zone e possono aiutarti ulteriormente a progettare sistemi ad alta disponibilità (HA).

Se hai requisiti di disponibilità elevati in date specifiche, come il Black Friday e il Cyber Monday, Google Cloud ha un programma per collaborare con te per verificare e convalidare la tua applicazione specifica in esecuzione su Google Cloud e identificare eventuali dipendenze di servizi impreviste tra la tua applicazione e i nostri servizi.

Punti di presenza (POP)

Google gestisce una rete globale di punti di presenza di peering, il che significa che il traffico dei clienti può viaggiare all'interno della rete di Google fino a quando non è vicino alla destinazione, offrendo agli utenti un'esperienza e una sicurezza migliori. Per maggiori informazioni, consulta Località di confine della rete.

Gestione geografica dei dati

La località dei dati per i servizi Google Cloud è regolata dai Termini di servizio, inclusi i Termini specifici del servizio. Google è consapevole che ogni cliente potrebbe avere esigenze di sicurezza e conformità specifiche. Il team di vendita di Google Cloud può aiutarti a soddisfare i tuoi requisiti.

Quando utilizzi risorse di archiviazione regionali o zonali, ti consigliamo vivamente di replicare i dati in un'altra regione o di acquisire uno snapshot in una risorsa di archiviazione multiregionale a scopo di ripristino di emergenza.

Considerazioni sul deployment delle applicazioni

Per creare servizi e applicazioni altamente disponibili che possono resistere alla mancata disponibilità delle zone

Utilizza quanto segue:

Risorse regionali, come le applicazioni App Engine, i gruppi di istanze gestite regionali o le risorse multiregionali gestite come Cloud Storage, Datastore, Firestore o Spanner.
Risorse a livello di zona, come le macchine virtuali Compute Engine, ma gestisci la tua ridondanza di calcolo e archiviazione tra zone o regioni.

Per creare applicazioni compatibili con il ripristino di emergenza in grado di resistere alla perdita prolungata di intere regioni

Per i dati, utilizza una o più delle seguenti strategie:

Utilizza servizi di archiviazione multiregionali gestiti come Cloud Storage, Datastore, Firestore o Spanner.
Utilizza risorse zonali o regionali, ma acquisisci gli snapshot dei dati in una risorsa multiregionale come Cloud Storage, Datastore, Firestore o Spanner.
Utilizza risorse a livello di zona o regione, ma gestisci la replica dei tuoi dati in una o più altre regioni.

Per l'elaborazione, utilizza la seguente strategia:

Utilizza risorse zonali o regionali, come Compute Engine o App Engine, ma avvia manualmente o automaticamente la tua applicazione in un'altra regione (in caso di errore regionale) facendo riferimento a copie dei tuoi dati principali se non sono già presenti in una risorsa multiregionale gestita.

Per ulteriori informazioni sulle dipendenze dei servizi, contatta il team di vendita.

Soluzioni e tutorial aggiuntivi

Le seguenti soluzioni e tutorial forniscono indicazioni per garantire che la tua applicazione sia altamente disponibile e possa resistere alle interruzioni:

Pattern per app scalabili e resilienti

Scopri come utilizzare Google Cloud per creare architetture di applicazioni scalabili e resilienti utilizzando pattern e procedure applicabili in modo esteso a qualsiasi applicazione web.

Creazione di un bilanciatore del carico HTTPS

Configura le istanze Compute Engine in regioni diverse e utilizza il bilanciamento del carico HTTP per distribuire il traffico tra le regioni in modo da aumentare la disponibilità nelle regioni e fornire il failover in caso di interruzione del servizio.