Geografia e aree geografiche

I prodotti Google Cloud vengono serviti da domini con errori regionali specifici e sono completamente supportati dagli accordi sul livello del servizio per garantire che tu stia progettando l'architettura dell'applicazione all'interno della struttura di Google Cloud.

I servizi di infrastruttura Google Cloud sono disponibili in località in Nord America, Sud America, Europa, Asia, Medio Oriente e Australia. Queste località sono divise in regioni e zone. Puoi scegliere dove posizionare le 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 composte 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 ed elencati nella pagina delle sedi di Google Cloud oppure possono essere in leasing da fornitori di data center di terze parti. Per l'elenco completo delle località 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 in modo da 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 proteggere da errori imprevisti, esegui il deployment delle applicazioni in più zone all'interno di una regione.

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

Per ulteriori informazioni sulle risorse specifiche disponibili all'interno di ciascuna opzione di località, consulta le nostre località cloud.

Le risorse e i servizi 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 Gestione geografica dei dati.

Google Cloud intende offrire un minimo di tre zone di disponibilità (zone fisiche 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 di zona possono interessare alcune o tutte le risorse in quella zona. Un esempio di risorsa di zona è un'istanza di macchina virtuale (VM) Compute Engine che si trova all'interno di una zona specifica.

Risorse a livello di regione

Le risorse a livello di regione sono risorse di cui viene eseguito il 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 una maggiore disponibilità rispetto alle risorse di zona.

Risorse per più regioni

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 e il modello di coerenza. Questi compromessi sono documentati su base specifica del prodotto.

I seguenti servizi hanno una o più località con più regioni oltre a quelle a livello di regione:

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

Questi servizi per più regioni sono progettati per funzionare a seguito della perdita di una singola regione.

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

Servizi globali

Google Cloud è stato progettato per operare a livello globale ed esegue costantemente manutenzione ed upgrade 24 ore su 24, 7 giorni su 7, 365 giorni l'anno, senza disturbarti. La nostra rete backbone globale offre un'enorme flessibilità per il bilanciamento del carico e riduce la latenza dell'utente finale grazie alle interconnessioni nelle vicinanze. Il nostro piano globale di gestione del cloud semplifica la gestione degli sviluppi in più regioni.

Servizi interni

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

Questi servizi interni sono con bilanciamento del carico a livello globale in più regioni o sono dedicati a ogni regione in cui sono disponibili. Se i servizi sono con bilanciamento del carico in più regioni, eseguiamo il deployment degli aggiornamenti progressivamente regione per regione, consentendoci di rilevare e risolvere i problemi senza influire sull'utilizzo dei servizi. Nessuno di questi servizi interni è limitato a un singolo data center logico o a una singola regione.

Global Internal Services può essere eseguito o replicato 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 del servizio

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

Tutti i servizi Google Cloud si basano su strumenti interni fondamentali per fornire servizi di base come networking (all'interno e all'esterno dei data center), accesso ai data center e sistemi di autorizzazione delle identità. Questi strumenti sono resilienti alle interruzioni a livello di regione, con l'obiettivo di evitare conseguenze per una singola regione 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, soprattutto 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 condizione che i dettagli di implementazione di livello inferiore siano soggetti a modifica.

Dipendenze comuni per tutti i servizi

  • Piano di identità per l'autenticazione e l'autorizzazione
  • Servizi interni che forniscono logging, archiviazione dei metadati e gestione dei flussi di lavoro
  • L'accesso alle API 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, i criteri IAM, le regole firewall globali, le configurazioni del bilanciatore del carico globale e gli argomenti Pub/Sub sono archiviati in database replicati.
  • Quando i servizi Google Cloud inviano richieste a endpoint controllati dal cliente, ad esempio quando Cloud EKM recupera le chiavi dei clienti o recapita messaggi Pub/Sub, 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 della VM e del Persistent Disk di Google Cloud dipendono dai 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:
    • Crittografia e infrastruttura di gestione delle chiavi per il cliente (Cloud KMS / Cloud EKM) e infrastruttura interna per le chiavi di proprietà di Google
    • Servizi interni per fornire logging e controllo dell'accesso ai dati
    • Servizi di replica dei dati interni, in cui i dati dovrebbero essere disponibili in più regioni
    • I backup configurati esplicitamente e la replica in altre regioni dipendono dal networking tra regioni
  • Servizi di messaggistica
    • Pub/Sub si basa sulla nostra infrastruttura di rete globale per accedere agli endpoint
  • Servizi di networking
    • Il bilanciamento del carico globale, il DNS e il failover tra regioni dipendono tutti dall'infrastruttura di rete fisica.
    • La prevenzione degli attacchi DDos e simili dipende dall'infrastruttura Compute Engine di livello inferiore.
  • Servizi gestiti e ospitati come GKE e Cloud SQL
    • Dipende da Compute Engine e Container Registry o Artifact Registry per le immagini VM.
  • Infrastruttura di livello inferiore indipendente
    • Il nostro piano di controllo interno a livello di cluster, inclusi Borg e fabric di rete
    • Archiviazione a livello di cluster, ad esempio Colossus
    • Crittografia e infrastruttura di gestione delle chiavi

Mantenere e migliorare disponibilità e resilienza

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

Collaborare con i clienti per creare servizi resilienti

Se hai esigenze mission critical e hai bisogno di sviluppare un'architettura per la resilienza e il ripristino di emergenza, i nostri team SRE/CRE e PSO possono collaborare con te per progettare le tue applicazioni in modo da collegare più regioni e zone e possono aiutarti ulteriormente nella progettazione di sistemi ad alta disponibilità.

Se hai aumentati i requisiti di disponibilità in determinate date, come il Black Friday e il Cyber Monday, Google Cloud offre un programma che ti aiuta a controllare e convalidare la tua applicazione specifica in esecuzione su Google 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 in peering, il che significa che il traffico dei clienti può spostarsi all'interno della rete Google fino a quando non si avvicina alla sua destinazione, offrendo agli utenti un'esperienza e una sicurezza migliori. Per ulteriori informazioni, consulta Località sul perimetro della rete.

Gestione geografica dei dati

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

Se utilizzi risorse di archiviazione a livello di regione o zona, ti consigliamo vivamente di replicare i dati in un'altra regione o di creare uno snapshot in una risorsa di archiviazione multiregionale ai fini del ripristino di emergenza.

Considerazioni sul deployment dell'applicazione

Creare servizi e applicazioni ad alta disponibilità in grado di resistere alle zone che diventano non disponibili

Utilizza quanto segue:

creare applicazioni compatibili con il 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 di zona o di regione, ma esegui snapshot dei dati a una risorsa multiregionale come Cloud Storage, Datastore, Firestore o Spanner.
  • Utilizza risorse di zona o di regione, ma gestisci la tua replica dei dati in una o più regioni.

Per il computing, utilizza la strategia seguente:

  • Utilizza risorse di zona o di regione come Compute Engine o App Engine, ma manualmente o automaticamente la tua applicazione in un'altra regione (in caso di errore a livello di regione) facendo riferimento alle copie dei tuoi dati principali, se i dati non si trovano già in una risorsa gestita multiregionale.

Per ulteriori informazioni sulle dipendenze del servizio, contatta il team di vendita.

Ulteriori soluzioni e tutorial

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

Pattern per app scalabili e resilienti

Scopri come usare Google Cloud per creare architetture di applicazioni scalabili e resilienti utilizzando pattern e pratiche che si applicano su larga scala a qualsiasi applicazione web.

Creazione di un bilanciatore del carico HTTPS

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

Progettare sistemi solidi

Progetta la tua applicazione nel servizio Compute Engine in modo che sia resistente a guasti, interruzioni di rete e disastri imprevisti.

Backup e ripristino Cassandra con Cloud Storage

Scopri come aggiungere il ripristino di emergenza di base alla tua installazione Cassandra eseguendo il backup dei dati e ripristinandoli da Cloud Storage.

Guida alla pianificazione del ripristino di emergenza

Principi generali per la progettazione e il test di un piano di ripristino di emergenza con Google Cloud.