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 di infrastruttura di Google Cloud sono disponibili in località Nord America, Sud America, Europa, Asia, Medio Oriente e Australia. Queste località sono divise 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 astrazioni logiche delle risorse fisiche sottostanti fornite in uno o più data center fisici. Questi data center possono essere di proprietà di Google e elencate nella pagina delle località di Google Cloud, oppure essere affittati 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 che il data center sia di proprietà o in leasing, Google Cloud seleziona i data center e progetta la propria infrastruttura per fornire prestazioni uniformi, 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, regionali o gestiti da Google in più regioni. Per ulteriori informazioni su cosa significano i tuoi dati, vedi gestione geografica dei dati.

Google Cloud intende offrire un minimo di tre zone di disponibilità (zone fisiche e logiche distinte) in ogni regione a 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 di regione

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 latenza e modello di coerenza. Questi compromessi sono documentati in base al prodotto.

I seguenti servizi hanno uno o più località multiregionali oltre a eventuali località regionali:

Artifact Registry
Bigtable
Protezione dei dati sensibili
API Cloud Healthcare
Cloud KMS
Container Registry
Spanner
Cloud Storage
Database Migration Service
Datastore
Firestore

Questi servizi multiregionali sono progettati per essere in grado di funzionare seguendo le di una singola regione.

Per ulteriori informazioni, vedi Prodotti disponibili in base alla località e la documentazione di ogni prodotto.

Servizi globali

Google Cloud è stato progettato per operare a livello globale da cima a fondo ed effettua continuamente interventi di manutenzione e upgrade 24 ore su 24, 7 giorni su 7, 365 giorni l'anno senza disturbarti. 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 in più o dedicate a ciascuna regione in cui sono disponibili. Dove il bilanciamento del carico viene eseguito in più regioni, eseguiamo il deployment degli aggiornamenti di regione per regione, consentendoci 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 servizio

In generale, per i servizi Google Cloud, in caso di errore di una singola regione, solo i clienti di quella regione; I clienti con più regioni i prodotti non ne 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 regionali, 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 di identità per autenticazione e autorizzazione
Servizi interni che forniscono registrazione, archiviazione dei metadati e gestione del flusso di lavoro
L'accesso alle API di Google Cloud dipende dal DNS, dai bilanciatori del carico distribuiti a livello globale e dai punti di presenza (PoP).
La configurazione delle risorse globali, ad esempio IAM criteri, regole firewall globali, configurazioni dei bilanciatori del carico globali e Gli argomenti Pub/Sub vengono archiviati in database replicati.
Quando i servizi Google Cloud effettuano richieste controllate dal cliente endpoint, ad esempio Cloud EKM che recupera le chiavi dei clienti Pub/Sub per la consegna dei messaggi, queste richieste dipendono un'infrastruttura di rete globale per accedere agli endpoint controllati dal cliente.

Servizi con dipendenze aggiuntive

Servizi Compute Engine
- I piani dati VM e Persistent Disk di Google Cloud dipendono Compute Engine e servizi Cloud Storage di livello inferiore come Borg e Colossus.
di Google Cloud e dei servizi di archiviazione 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 l'infrastruttura interna per Chiavi di proprietà di Google
- Servizi interni per fornire il logging e il controllo dell'accesso ai dati
- Servizi di replica dei dati interna, dove si prevede che i dati siano disponibili in più regioni
- I backup e la replica configurati in modo esplicito in altre regioni dipendono dalla rete tra regioni
Servizi di messaggistica
- Per accedere a Pub/Sub dipende dalla nostra infrastruttura di rete globale endpoint controllati dal cliente
Servizi di networking
- Bilanciamento del carico globale, DNS e failover tra regioni dipendono tutti 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 infrastrutture di rete
- Archiviazione a livello di cluster, come 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à. Interruzioni e assistenza l'indisponibilità è correlata al deployment di nuovo codice o alle modifiche completamente gestito di Google Cloud. Utilizzando le best practice del settore, l'SRE bilancia la necessità di rilasciare nuovo software e mantiene l'ambiente sicuro, sapendo che le modifiche necessarie potrebbero causare tempi di inattività.

Collaborare 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 (POP) di peering, il che significa che il traffico dei clienti può spostarsi all'interno della rete Google fino a quando di destinazione, offrendo agli utenti un'esperienza migliore e una maggiore sicurezza. 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 potrebbe avere esigenze specifiche in termini di sicurezza e conformità. 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 App Engine applicazioni, gruppi di istanze gestite a livello di regione, o 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 con funzionalità di ripristino di emergenza in grado di tollerare la perdita estesa di intere regioni

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

Usa servizi di archiviazione gestiti multiregionali 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 di zona o di regione, ma gestisci la replica dei dati in una o più altre regioni.

Per il computing, utilizza la seguente strategia:

Utilizza risorse di zona o di regione, come Compute Engine o App Engine, ma attivare manualmente o automaticamente in un'altra regione (in caso di errore regionale) che fa riferimento alle copie I dati primari se non si trovano già in un'area multiregionale gestita risorsa.

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

Soluzioni e tutorial aggiuntivi

Le soluzioni e i tutorial seguenti forniscono indicazioni per garantire che il tuo l'applicazione è ad alta disponibilità e può resistere a interruzioni del servizio: