Aree geografiche e regioni

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

Google Cloud I servizi dell'infrastruttura 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

Regioni e zone

Le regioni sono aree geografiche indipendenti costituite da zone. Zone e regioni sono astrazioni logiche delle risorse fisiche sottostanti. Una regione è costituita da tre o più zone ospitate in tre o più data center fisici. Le regioni Stoccolma, Messico, Osaka e Montréal hanno tre zone in uno o due data center fisici. Queste regioni sono in fase di espansione per arrivare ad almeno tre data center fisici. Quando progetti le tue soluzioni in Google Cloud, tieni presente le indicazioni riportate in Località cloud, SLA della piattaformaGoogle Cloud e nella Google Cloud documentazione del prodotto appropriata.

Questi data center potrebbero essere di proprietà di Google ed essere elencati nella Google Cloud pagina delle sedi oppure essere presi in affitto da fornitori di data center di terze parti. Per l'elenco completo delle sedi dei data center per Google Cloud, consulta il nostro certificato ISO/IEC 27001. Indipendentemente dal fatto che il data center sia di proprietà o in affitto, 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 all'interno di una regione. Google Cloud 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 alta disponibilità 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 un disastro naturale, disponi di un piano diripristino di emergenzay e sappi come avviare la tua applicazione nell'improbabile caso di perdita della regione principale. Per saperne di più, consulta Considerazioni sul deployment delle applicazioni.

Per ulteriori informazioni sulle risorse specifiche disponibili in ogni opzione di località, consulta la sezione Località cloud.

I servizi e le risorse diGoogle Cloudpossono essere zonali, regionali o gestiti da Google in più regioni. Per saperne di più sul significato di queste opzioni per i tuoi dati, consulta la sezione 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 macchina virtuale (VM) Compute Engine che risiede 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

Più servizi Google Cloud sono gestiti da Google per essere 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 e il modello di coerenza. Questi compromessi sono documentati in base al prodotto.

I seguenti servizi hanno una o più località multiregionali oltre a 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 in seguito alla perdita di una singola regione.

Per saperne di più, consulta Prodotti disponibili per località e la documentazione di ogni prodotto.

Servizi globali

Google Cloud è stato progettato per operare a livello globale da zero e svolge continuamente manutenzione e aggiornamenti 24 ore al giorno, 7 giorni su 7, 365 giorni l'anno senza causare disagi. La nostra dorsale globale offre un'enorme flessibilità per il bilanciamento del carico e riduce la latenza per gli utenti finali grazie a interconnessioni vicine a te. Il nostro piano di gestione del cloud globale semplifica la gestione degli sviluppi multiregionali.

Servizi interni

Alla base di molti servizi rivolti ai clienti Google Cloud si trova un insieme di servizi interni collaudati come Spanner, Colossus, Borg e Chubby.

Questi servizi interni sono bilanciati del carico a livello globale in più regioni o dedicati a ogni regione in cui sono disponibili. Nei casi in cui i servizi sono bilanciati del carico in più regioni, eseguiamo il deployment degli aggiornamenti in modo progressivo 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 servizio

In generale, per i servizi Google Cloud , se una singola regione non funziona, solo i clienti che si trovano esclusivamente in quella regione sono interessati; i clienti che hanno prodotti multiregionali non sono interessati. Google Cloud dispone di un'architettura significativa con l'obiettivo di prevenire errori correlati tra le regioni.

Tutti i servizi Google Cloud si basano su strumenti interni di base per fornire servizi fondamentali come il networking (all'interno e all'esterno dei data center), l'accesso ai data center e i sistemi di autorizzazione dell'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 loro 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 principali dipendenze sono elencate di seguito, a partire da quelle comuni a tutti i servizi, con la clausola che i dettagli di implementazione di livello inferiore sono soggetti a modifiche.

Dipendenze comuni per tutti i servizi

• Piano di controllo dell'identità per l'autenticazione e l'autorizzazione
• Servizi interni che forniscono gestione di logging, archiviazione dei metadati e workflow
• L'accesso alle API Google Cloud dipende da DNS, bilanciatori del carico distribuiti a livello globale e punti di presenza (PoP).
• La configurazione delle risorse globali: ad esempio, le norme IAM, le regole firewall globali, le configurazioni del bilanciatore del carico globale e gli argomenti Pub/Sub vengono archiviati in database replicati.
• Quando Google Cloud services invia richieste a endpoint controllati dal cliente, ad esempio Cloud EKM che recupera le chiavi del cliente o Pub/Sub che distribuisce i 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 Google Cloud piani dati VM e Persistent Disk dipendono da servizi Compute Engine e Cloud Storage di livello inferiore come Borg e Colossus.
• Google Cloud e i servizi di archiviazione dell'infrastruttura come Spanner, Bigtable e Cloud Storage dipendono da:
  • Infrastruttura di crittografia e gestione delle chiavi per i clienti (Cloud KMS / Cloud EKM) e infrastruttura interna per le chiavi di proprietà di Google
  • Servizi interni per fornire la registrazione e il controllo dell'accesso ai dati
  • Servizi di replica dei dati interni, in cui i dati devono essere disponibili in più regioni
  • I backup e la replica configurati in modo esplicito in altre regioni dipendono dal networking tra regioni
• Servizi di messaggistica
  • Pub/Sub dipende dalla nostra infrastruttura di rete globale per accedere agli endpoint controllati dai clienti
• 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 ospitati 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, inclusi Borg e i tessuti di rete
  • Archiviazione a livello di cluster, ad esempio Colossus
  • Infrastruttura di crittografia e gestione delle chiavi

Mantenere e migliorare la disponibilità e la resilienza

Site Reliability Engineering (SRE) è l'organizzazione interna di Google dedicata a lavorare su disponibilità, latenza, prestazioni e capacità. Le interruzioni e l'indisponibilità del servizio sono correlate al deployment di nuovo codice o alle modifiche all'ambiente. Utilizzando le best practice del settore, SRE bilancia la necessità di rilasciare nuovo software e mantiene l'ambiente sicuro con la consapevolezza che queste 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 recupero di emergenza, i nostri team SRE/CRE e PSO possono collaborare con te per progettare le tue applicazioni in modo da coprire più regioni e zone e possono aiutarti ulteriormente a progettare sistemi ad alta disponibilità (HA).

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

Punti di presenza (POP)

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

Gestione geografica dei dati

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

Quando utilizzi risorse di archiviazione regionali o di zona, ti consigliamo vivamente di replicare i dati in un'altra regione o di creare uno snapshot in una risorsa di archiviazione multiregionale per il ripristino di emergenza.

Considerazioni sul deployment delle applicazioni

Per creare servizi e applicazioni ad alta disponibilità in grado di resistere all'indisponibilità delle zone

Utilizza quanto segue:

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

Per creare applicazioni in grado di eseguire il ripristino di emergenza e di tollerare la perdita prolungata di intere regioni

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

• Utilizza servizi di archiviazione gestiti e multiregionali come Cloud Storage, Datastore, Firestore o Spanner.
• Utilizza risorse zonali o regionali, ma crea 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 dati in una o più altre regioni.

Per il calcolo, utilizza la seguente strategia:

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

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

Tutorial e soluzioni aggiuntive

Le seguenti soluzioni e tutorial forniscono indicazioni per garantire che la tua applicazione sia ad alta disponibilità e possa resistere alle interruzioni: