Deployment globale con Compute Engine e Spanner

Last reviewed 2025-08-12 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione a più livelli che viene eseguita su VM Compute Engine e Spanner in una topologia globale in Google Cloud. Il documento fornisce anche indicazioni per aiutarti a creare un'architettura che utilizza altri servizi di infrastruttura Google Cloud . Descrive i fattori di progettazione da considerare quando crei un'architettura globale per le tue applicazioni cloud. Il pubblico di destinazione di questo documento sono i cloud architect.

Questa architettura è in linea con l'archetipo di deployment globale. Consigliamo questo archetipo per le applicazioni che servono utenti in tutto il mondo e che richiedono alta disponibilità e robustezza contro le interruzioni in più regioni. Questa architettura supporta lo scaling elastico a livello di rete, applicazione e database. Ti consente di allineare i costi all'utilizzo senza dover scendere a compromessi in termini di prestazioni, disponibilità o scalabilità.

Architettura

Il seguente diagramma mostra un'architettura per un'applicazione che viene eseguita su un'infrastruttura distribuita a livello globale in più regioni Google Cloud.

Architettura di deployment globale che utilizza Compute Engine e Spanner.

In questa architettura, un bilanciatore del carico globale distribuisce le richieste in entrata ai server web nelle regioni appropriate in base alla loro disponibilità, capacità e vicinanza all'origine del traffico. Un livello di bilanciamento del carico interno multiregionale gestisce la distribuzione del traffico dai server web ai server delle applicazioni appropriati in base alla loro disponibilità e capacità. I server delle applicazioni scrivono i dati e li leggono da un database replicato in modo sincrono disponibile in tutte le regioni.

L'architettura include le seguenti risorse Google Cloud :

Componente Finalità
Bilanciatore del carico esterno globale

Il bilanciatore del carico esterno globale riceve e distribuisce le richieste degli utenti all'applicazione. Il bilanciatore del carico esterno globale annuncia un singolo indirizzo IP anycast, ma è implementato come un numero elevato di proxy su Google Front End (GFE). Le richieste del client vengono indirizzate al servizio GFE più vicino al client.

A seconda dei tuoi requisiti, puoi utilizzare un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore del carico di rete del proxy esterno globale. Per ulteriori informazioni, vedi Scegliere un bilanciatore del carico.

Per proteggere la tua applicazione da minacce come attacchi DDoS (Distributed Denial-of-Service) e cross-site scripting (XSS), puoi utilizzare i criteri di sicurezza di Google Cloud Armor.

Gruppi di istanze gestite (MIG) regionali per il livello web

Il livello web dell'applicazione viene eseguito il deployment su VM Compute Engine che fanno parte di gruppi di istanze gestite a livello di regione. Questi MIG sono i backend del bilanciatore del carico globale.

Ogni MIG contiene VM di Compute Engine in tre zone diverse. Ciascuna di queste VM ospita un'istanza indipendente del livello web dell'applicazione.

Livello di bilanciamento del carico interno tra regioni

I bilanciatori del carico interni con backend cross-region gestiscono la distribuzione del traffico dalle VM del livello web in qualsiasi regione alle VM del livello applicazione in tutte le regioni.

A seconda dei requisiti, puoi utilizzare un bilanciatore del carico delle applicazioni interno tra regioni o un bilanciatore del carico di rete proxy interno tra regioni. Per ulteriori informazioni, vedi Scegliere un bilanciatore del carico.

MIG a livello di regione per il livello applicazione

Il livello applicazione viene eseguito il deployment su VM Compute Engine che fanno parte di gruppi di istanze gestite a livello di regione. Questi MIG sono i backend per il livello di bilanciamento del carico interno.

Ogni MIG contiene VM di Compute Engine in tre zone diverse. Ogni VM ospita un'istanza indipendente del livello dell'applicazione.

Istanza Spanner multiregionale

L'applicazione scrive i dati e li legge da un' istanza Spanner multiregionale. La configurazione multiregionale in questa architettura include le seguenti repliche:

  • Quattro repliche di lettura e scrittura in zone separate in due regioni.
  • Una replica di sola lettura in una terza regione.
Rete Virtual Private Cloud (VPC) e subnet

Tutte le risorse nell'architettura utilizzano una singola rete VPC. La rete VPC ha le seguenti subnet:

  • Una subnet in ogni regione per le VM del server web.
  • Una subnet in ogni regione per le VM del server delle applicazioni.
  • (Non mostrato nel diagramma dell'architettura) Una subnet solo proxy in ogni regione per il bilanciatore del carico interno interregionale.

Anziché utilizzare una singola rete VPC, puoi creare una rete VPC separata in ogni regione e connettere le reti utilizzando Network Connectivity Center.

Prodotti utilizzati

Questa architettura di riferimento utilizza i seguenti prodotti Google Cloud :

  • Compute Engine: un servizio di calcolo sicuro e personalizzabile che ti consente di creare ed eseguire VM sull'infrastruttura di Google.
  • Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
  • Spanner: un servizio di database relazionale a scalabilità elevata e con coerenza globale.

Considerazioni sulla progettazione

Questa sezione fornisce indicazioni per aiutarti a utilizzare questa architettura di riferimento per sviluppare un'architettura che soddisfi i tuoi requisiti specifici per la progettazione del sistema, la sicurezza e la conformità, l'affidabilità, i costi, l'efficienza operativa e le prestazioni.

Progettazione del sistema

Questa sezione fornisce indicazioni per aiutarti a scegliere le Google Cloud regioni per il deployment globale e a selezionare i servizi Google Cloud appropriati.

Selezione delle regioni

Quando scegli le Google Cloud regioni in cui devono essere implementate le tue applicazioni, considera i seguenti fattori e requisiti:

  • Disponibilità dei servizi Google Cloud in ogni regione. Per ulteriori informazioni, consulta Prodotti disponibili per località.
  • Disponibilità dei tipi di macchine Compute Engine in ogni regione. Per maggiori informazioni, consulta Regioni e zone.
  • Requisiti di latenza per l'utente finale.
  • Costo delle risorse Google Cloud .
  • Costi del trasferimento di dati tra regioni.
  • Requisiti normativi.

Alcuni di questi fattori e requisiti potrebbero comportare compromessi. Ad esempio, la regione più conveniente potrebbe non avere l'impronta di carbonio più bassa. Per saperne di più, consulta Best practice per la scelta delle regioni di Compute Engine.

Infrastruttura di calcolo

L'architettura di riferimento in questo documento utilizza le VM Compute Engine per determinati livelli dell'applicazione. A seconda dei requisiti della tua applicazione, puoi scegliere tra altri servizi di calcolo: Google Cloud

  • Container: puoi eseguire applicazioni containerizzate in cluster Google Kubernetes Engine (GKE). GKE è un motore di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate.
  • Serverless: se preferisci concentrare i tuoi sforzi IT sui dati e sulle applicazioni anziché configurare e gestire le risorse dell'infrastruttura, puoi utilizzare servizi serverless come Cloud Run.

La decisione di utilizzare VM, container o servizi serverless comporta un compromesso tra flessibilità di configurazione e impegno di gestione. Le VM e i container offrono maggiore flessibilità di configurazione, ma sei responsabile della gestione delle risorse. In un'architettura serverless, esegui il deployment dei carichi di lavoro su una piattaforma preconfigurata che richiede uno sforzo di gestione minimo. Per ulteriori informazioni sulla scelta dei servizi di calcolo appropriati per i tuoi workload in Google Cloud, consulta Hosting di applicazioni su Google Cloud.

Servizi di archiviazione

L'architettura mostrata in questo documento utilizza volumi Persistent Disk di regione per le VM. I volumi Persistent Disk a livello di regione forniscono la replica sincrona dei dati tra due zone all'interno di una regione. I dati nei volumi Persistent Disk non vengono replicati tra le regioni.

Google Cloud Hyperdisk offre prestazioni, flessibilità ed efficienza migliori rispetto a Persistent Disk. Con Hyperdisk Balanced, puoi eseguire il provisioning di IOPS e throughput separatamente e dinamicamente, il che ti consente di ottimizzare il volume per un'ampia gamma di workload.

Per l'archiviazione a basso costo replicata in più località, puoi utilizzare bucket Cloud Storage regionali, a due regioni o multiregionali.

  • I dati nei bucket regionali vengono replicati in modo sincrono tra le zone della regione.
  • I dati nei bucket a due o più regioni vengono archiviati in modo ridondante in almeno due località geografiche separate. I metadati vengono scritti in modo sincrono in tutte le regioni e i dati vengono replicati in modo asincrono. Per i bucket a doppia regione, puoi utilizzare la replica turbo, che garantisce la replica degli oggetti tra le coppie di regioni, con un RPO (Recovery Point Objective) di 15 minuti. Per ulteriori informazioni, vedi Disponibilità e durabilità dei dati.

Per archiviare i dati condivisi tra più VM in una regione, ad esempio tra tutte le VM nel livello web o nel livello applicazione, puoi utilizzare un'istanza regionale Filestore. I dati archiviati in un'istanza regionale Filestore vengono replicati in modo sincrono in tre zone all'interno della regione. Questa replica garantisce alta disponibilità e robustezza in caso di interruzioni a livello di zona. Puoi archiviare file di configurazione condivisi, strumenti e utilità comuni e log centralizzati nell'istanza Filestore e montare l'istanza su più VM. Per una maggiore robustezza in caso di interruzioni della regione, puoi replicare un'istanza Filestore in una regione diversa. Per saperne di più, consulta Replica delle istanze.

Se il tuo database è Microsoft SQL Server, ti consigliamo di utilizzare Cloud SQL per SQL Server. Negli scenari in cui Cloud SQL non supporta i tuoi requisiti di configurazione o se hai bisogno dell'accesso al sistema operativo, puoi eseguire il deployment di un'istanza del cluster di failover (FCI) di Microsoft SQL Server. In questo scenario, puoi utilizzare Google Cloud NetApp Volumes completamente gestito per fornire spazio di archiviazione SMB a disponibilità continua (CA) per il database.

Quando progetti l'archiviazione per i tuoi workload, considera le caratteristiche funzionali, i requisiti di resilienza, le aspettative di prestazioni e gli obiettivi di costo. Per ulteriori informazioni, consulta Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud.

Servizi di database

L'architettura di riferimento in questo documento utilizza Spanner, un database completamente gestito, scalabile orizzontalmente, distribuito a livello globale e replicato in modo sincrono. Consigliamo una configurazione Spanner multiregionale per le implementazioni mission critical che richiedono una coerenza interregionale elevata. Spanner supporta la replica sincrona tra regioni senza tempi di inattività per il failover, la manutenzione o il ridimensionamento.

Per informazioni su altri servizi di database gestiti tra cui puoi scegliere in base ai tuoi requisiti, consulta la sezione Google Cloud Database. Quando scegli e configuri il database per un deployment multiregionale, valuta i requisiti della tua applicazione per la coerenza dei dati tra regioni e tieni conto dei compromessi in termini di prestazioni e costi.

Progettazione di rete

Scegli un design di rete che soddisfi i tuoi requisiti aziendali e tecnici. Puoi utilizzare una singola rete VPC o più reti VPC. Per saperne di più, consulta la seguente documentazione:

Opzioni di bilanciamento del carico esterno

Un'architettura che utilizza un bilanciatore del carico esterno globale, come l'architettura descritta in questo documento, supporta determinate funzionalità che ti aiutano a migliorare l'affidabilità dei tuoi deployment. Ad esempio, se utilizzi il bilanciatore del carico delle applicazioni esterno globale, puoi implementare la memorizzazione in una cache perimetrale utilizzando Cloud CDN.

Se la tua applicazione richiede la terminazione di Transport Layer Security (TLS) in una regione specifica o se hai bisogno di pubblicare contenuti da regioni specifiche, puoi utilizzare i bilanciatori del carico regionali con Cloud DNS per indirizzare il traffico a regioni diverse. Per informazioni sulle differenze tra i bilanciatori del carico regionali e globali, consulta la seguente documentazione:

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia globale in Google Cloud che soddisfi i requisiti di sicurezza, privacy e conformità dei tuoi workload.

Protezione contro le minacce esterne

Per proteggere la tua applicazione da minacce come gli attacchi DDoS (Distributed Denial of Service) e cross-site scripting (XSS), puoi utilizzare i criteri di sicurezza di Google Cloud Armor. Ogni criterio è un insieme di regole che specifica determinate condizioni da valutare e azioni da intraprendere quando le condizioni sono soddisfatte. Ad esempio, una regola potrebbe specificare che se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP o a un intervallo CIDR specifico, il traffico deve essere negato. Puoi anche applicare regole del web application firewall (WAF) preconfigurate. Per ulteriori informazioni, consulta Panoramica delle norme di sicurezza.

Accesso esterno per le VM

Nell'architettura di riferimento descritta in questo documento, le VM Compute Engine non richiedono l'accesso in entrata da internet. Non assegnare indirizzi IP esterni alle VM. Google Cloud Le risorse che hanno solo un indirizzo IP interno privato possono comunque accedere a determinati servizi e API di Google utilizzando Private Service Connect o l'accesso privato Google. Per maggiori informazioni, consulta Opzioni di accesso privato per i servizi.

Per abilitare connessioni in uscita sicure dalle risorse che hanno solo indirizzi IP privati, come le VM Compute Engine in questa architettura di riferimento, puoi utilizzare Secure Web Proxy o Cloud NAT. Google Cloud

Privilegi del service account

Per le VM Compute Engine nell'architettura, anziché utilizzare i service account predefiniti, ti consigliamo di creare service account dedicati e specificare le risorse a cui il account di servizio può accedere. L'account di servizio predefinito dispone di un'ampia gamma di autorizzazioni, tra cui alcune che potrebbero non essere necessarie. Puoi personalizzare i service account dedicati in modo che dispongano solo delle autorizzazioni essenziali. Per saperne di più, consulta Limitare i account di servizio account.

Sicurezza SSH

Per migliorare la sicurezza delle connessioni SSH alle VM di Compute Engine nella tua architettura, implementa Identity-Aware Proxy (IAP) e l'API Cloud OS Login. IAP ti consente di controllare l'accesso alla rete in base all'identità utente e alle policy IAM (Identity and Access Management). L'API Cloud OS Login ti consente di controllare l'accesso SSH Linux in base all'identità dell'utente e ai criteri IAM. Per maggiori informazioni sulla gestione dell'accesso alla rete, consulta Best practice per il controllo dell'accesso al login SSH.

Altre considerazioni sulla sicurezza

Quando crei l'architettura per il tuo workload, tieni conto delle best practice e dei suggerimenti per la sicurezza a livello di piattaforma forniti nel blueprint delle fondamenta aziendali e nel Google Cloud framework Well-Architected: sicurezza, privacy e conformità.

Affidabilità

Questa sezione descrive i fattori di progettazione da considerare quando utilizzi questa architettura di riferimento per creare e gestire un'infrastruttura affidabile per un deployment globale in Google Cloud.

Scalabilità automatica del gruppo di istanze gestite

Quando esegui l'applicazione su più MIG a livello di regione, l'applicazione rimane disponibile durante le interruzioni isolate delle zone o delle regioni. La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente di mantenere la disponibilità e le prestazioni delle applicazioni a livelli prevedibili.

Per controllare il comportamento di scalabilità automatica dei tuoi MIG stateless, puoi specificare metriche di utilizzo target, come l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica basata sulla pianificazione per i MIG stateless. I MIG stateful non possono essere scalati automaticamente. Per ulteriori informazioni, consulta Scalabilità automatica dei gruppi di istanze.

Limite di dimensioni del MIG

Quando decidi le dimensioni dei tuoi MIG, considera i limiti predefiniti e massimi al numero di VM che possono essere create in un MIG. Per saperne di più, consulta Aggiungi e rimuovi VM da un MIG.

Riparazione automatica delle VM

A volte le VM che ospitano l'applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero esserci problemi con l'applicazione stessa. L'applicazione potrebbe bloccarsi, arrestarsi in modo anomalo o non avere memoria sufficiente. Per verificare se un'applicazione risponde come previsto, puoi configurare i controlli di integrità basati sull'applicazione nell'ambito del criterio di riparazione automatica dei tuoi MIG. Se l'applicazione su una determinata VM non risponde, il MIG esegue la riparazione automatica della VM. Per saperne di più sulla configurazione della riparazione automatica, consulta Informazioni sulla riparazione delle VM per l'alta affidabilità.

Posizionamento delle VM

Nell'architettura descritta in questo documento, il livello applicazione e il livello web vengono eseguiti su VM Compute Engine distribuite in più zone. Questa distribuzione garantisce che la tua applicazione sia resiliente alle interruzioni di zona.

Per migliorare la robustezza dell'architettura, puoi creare una policy di posizionamento distribuito e applicarla al modello di MIG. Quando il MIG crea le VM, le posiziona all'interno di ogni zona su server fisici diversi (chiamati host), in modo che le VM siano robuste contro i guasti dei singoli host. Per saperne di più, consulta Crea e applica policy di posizionamento distribuito alle VM.

Pianificazione della capacità delle VM

Per assicurarti che la capacità per le VM Compute Engine sia disponibile quando è necessario eseguire il provisioning delle VM, puoi creare prenotazioni. Una prenotazione fornisce capacità garantita in una zona specifica per un numero specificato di VM di un tipo di macchina che scegli. Una prenotazione può essere specifica per un progetto o condivisa tra più progetti. Per saperne di più sulle prenotazioni, consulta Scegliere un tipo di prenotazione.

Archiviazione stateful

Una best practice nella progettazione delle applicazioni è evitare la necessità di dischi locali stateful. Tuttavia, se il requisito esiste, puoi configurare i dischi permanenti in modo che siano stateful per garantire che i dati vengano conservati quando le VM vengono riparate o ricreate. Tuttavia, ti consigliamo di mantenere i dischi di avvio stateless, in modo da poterli aggiornare alle immagini più recenti con nuove versioni e patch di sicurezza. Per saperne di più, consulta Configurazione dei dischi permanenti stateful nei MIG.

Durabilità dei dati

Puoi utilizzare Backup e DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Backup and RE archivia i dati di backup nel formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i tuoi workload in produzione utilizzando direttamente i dati dell'archiviazione di backup a lungo termine ed evitare la necessità di preparare o spostare i dati.

Compute Engine offre le seguenti opzioni per garantire la durabilità dei dati archiviati nei volumi diPersistent Diski:

Affidabilità del database

I dati archiviati in un'istanza Spanner multiregionale vengono replicati in modo sincrono in più regioni. La configurazione di Spanner mostrata nel diagramma dell'architettura precedente include le seguenti repliche:

  • Quattro repliche di lettura e scrittura in zone separate in due regioni.
  • Una replica di sola lettura in una terza regione.

Un'operazione di scrittura in un'istanza Spanner multiregionale viene riconosciuta dopo che almeno tre repliche, in zone separate in due regioni, hanno eseguito il commit dell'operazione. Se si verifica un errore di zona o regione, Spanner ha accesso a tutti i dati, inclusi quelli delle ultime operazioni di scrittura, e continua a gestire le richieste di lettura e scrittura.

Spanner utilizza l'archiviazione disaggregata, in cui le risorse di calcolo e archiviazione sono disaccoppiate. Non devi spostare i dati quando aggiungi capacità di calcolo per l'alta affidabilità o lo scaling. Le nuove risorse di calcolo ricevono i dati quando ne hanno bisogno dal nodo Colossus più vicino. In questo modo, il failover e lo scaling sono più rapidi e meno rischiosi.

Spanner fornisce una coerenza esterna, che è una proprietà più rigorosa della serializzabilità per i sistemi di elaborazione delle transazioni. Per maggiori informazioni, consulta le seguenti risorse:

Altre considerazioni sull'affidabilità

Quando crei l'architettura cloud per il tuo carico di lavoro, esamina le best practice e i suggerimenti relativi all'affidabilità forniti nella documentazione seguente:

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo di configurazione e gestione di una topologia Google Cloud globale che crei utilizzando questa architettura di riferimento.

Tipi di macchine VM

Per aiutarti a ottimizzare l'utilizzo delle risorse delle tue istanze VM, Compute Engine fornisce suggerimenti sul tipo di macchina. Utilizza i suggerimenti per scegliere i tipi di macchine che corrispondono ai requisiti di calcolo del tuo workload. Per i carichi di lavoro con requisiti di risorse prevedibili, puoi personalizzare il tipo di macchina in base alle tue esigenze e risparmiare denaro utilizzando i tipi di macchine personalizzate.

Modello di provisioning delle VM

Se la tua applicazione è a tolleranza di errore, le VM spot possono aiutarti a ridurre i costi di Compute Engine per le VM nei livelli applicazione e web. Il costo delle VM spot è notevolmente inferiore rispetto alle VM normali. Tuttavia, Compute Engine potrebbe arrestare o eliminare preventivamente le VM spot per recuperare capacità.

Le VM spot sono adatte per i job batch che possono tollerare il prerilascio e non hanno requisiti di alta affidabilità. Le Spot VM offrono gli stessi tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, quando la capacità delle risorse in una zona è limitata, i MIG potrebbero non essere in grado di fare lo scale out (ovvero creare VM) automaticamente fino alle dimensioni target specificate finché la capacità richiesta non torna disponibile.

Utilizzo delle risorse della VM

La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente alla tua applicazione di gestire agevolmente gli aumenti del traffico e ti aiuta a ridurre i costi quando il fabbisogno di risorse è basso. I MIG stateful non possono essere scalati automaticamente.

Costo del database

Spanner contribuisce a garantire che i costi del database siano prevedibili. La capacità di calcolo che specifichi (numero di nodi o unità di elaborazione) determina la capacità di archiviazione. I throughput di lettura e scrittura vengono scalati linearmente con la capacità di calcolo. Paghi solo per quello che utilizzi. Quando devi allineare i costi alle esigenze del tuo carico di lavoro, puoi modificare le dimensioni della tua istanza Spanner.

Licenze di terze parti

Quando esegui la migrazione di carichi di lavoro di terze parti a Google Cloud, potresti essere in grado di ridurre i costi utilizzando il modello Bring Your Own License (BYOL). Ad esempio, per eseguire il deployment delle VM Microsoft Windows Server, anziché utilizzare un'immagine premium che comporta costi aggiuntivi per la licenza di terze parti, puoi creare e utilizzare un'immagine BYOL Windows personalizzata. Paghi solo per l'infrastruttura delle VM che utilizzi su Google Cloud. Questa strategia ti aiuta a continuare a trarre valore dai tuoi investimenti esistenti in licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, i seguenti consigli potrebbero aiutarti a ridurre i costi:

  • Esegui il provisioning del numero richiesto di core CPU di computing indipendentemente dalla memoria utilizzando i tipi di macchine personalizzate. In questo modo, limiti il costo della licenza di terze parti al numero di core CPU di cui hai bisogno.
  • Riduci il numero di vCPU per core da 2 a 1 disattivando il multi-threading simultaneo (SMT).

Se esegui il deployment di un database di terze parti come Microsoft SQL Server su VM Compute Engine, devi considerare i costi della licenza per il software di terze parti. Quando utilizzi un servizio di database gestito come Cloud SQL, i costi della licenza del database sono inclusi negli addebiti per il servizio.

Altre considerazioni sui costi

Quando crei l'architettura per il tuo workload, considera anche le best practice e i suggerimenti generali forniti in Google Cloud Well-Architected Framework: ottimizzazione dei costi.

Efficienza operativa

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia Google Cloud globale che puoi gestire in modo efficiente.

Aggiornamenti della configurazione delle VM

Per aggiornare la configurazione delle VM in un MIG (ad esempio il tipo di macchina o l'immagine del disco di avvio), crea un nuovo template di istanza con la configurazione richiesta e poi applica il nuovo template al MIG. Il gruppo di istanze gestite aggiorna le VM utilizzando il metodo di aggiornamento che scegli: automatico o selettivo. Scegli un metodo appropriato in base ai tuoi requisiti di disponibilità ed efficienza operativa. Per saperne di più su questi metodi di aggiornamento del MIG, consulta Applica nuove configurazioni delle VM in un MIG.

Immagini VM

Per le tue VM, anziché utilizzare immagini pubbliche fornite da Google, ti consigliamo di creare e utilizzare immagini sistema operativo personalizzate che contengano le configurazioni e il software richiesti dalle tue applicazioni. Puoi raggruppare le tue immagini personalizzate in una famiglia di immagini personalizzate. Una famiglia di immagini punta sempre all'immagine più recente della famiglia, quindi i tuoi template di istanza e script possono utilizzare quell'immagine senza che tu debba aggiornare i riferimenti a una versione specifica dell'immagine. Devi aggiornare regolarmente le tue immagini personalizzate per includere gli aggiornamenti della sicurezza e le patch fornite dal fornitore del sistema operativo.

Template di istanza deterministici

Se i modelli di istanza che utilizzi per i tuoi MIG includono script di avvio per installare software di terze parti, assicurati che gli script specifichino esplicitamente i parametri di installazione del software, ad esempio la versione del software. In caso contrario, quando il MIG crea le VM, il software installato sulle VM potrebbe non essere coerente. Ad esempio, se il modello di istanza include uno script di avvio per installare Apache HTTP Server 2.0 (il pacchetto apache2), assicurati che lo script specifichi la versione esatta di apache2 da installare, ad esempio la versione 2.4.53. Per ulteriori informazioni, vedi Template di istanza deterministici.

Migrazione a Spanner

Puoi eseguire la migrazione dei dati a Spanner da altri database come MySQL, SQL Server e Oracle Database. Il processo di migrazione dipende da fattori come il database di origine, le dimensioni dei dati, i vincoli di tempo di inattività e la complessità del codice dell'applicazione. Per aiutarti a pianificare e implementare la migrazione a Spanner in modo efficiente, forniamo una gamma di strumenti Google Cloud interni e di terze parti. Per maggiori informazioni, vedi Panoramica della migrazione.

Amministrazione del database

Con Spanner, non è necessario configurare o monitorare la replica o il failover. La replica sincrona e il failover automatico sono integrati. La tua applicazione non subisce tempi di inattività per la manutenzione e il failover del database. Per ridurre ulteriormente la complessità operativa, puoi configurare la scalabilità automatica. Con la scalabilità automatica attivata, non devi monitorare e scalare manualmente le dimensioni dell'istanza.

Ulteriori considerazioni operative

Quando crei l'architettura per il tuo carico di lavoro, prendi in considerazione le best practice e i suggerimenti generali per l'efficienza operativa descritti in Google Cloud Well-Architected Framework: eccellenza operativa.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia globale in Google Cloud che soddisfi i requisiti di rendimento dei tuoi carichi di lavoro.

Prestazioni di rete

Per i carichi di lavoro che richiedono una bassa latenza di rete tra le VM all'interno dei livelli web e dell'applicazione, puoi creare una policy di posizionamento compatto e applicarla al modello di gruppo di istanze gestite utilizzato per questi livelli. Quando il gruppo di istanze gestite crea le VM, le posiziona su server fisici vicini tra loro. Mentre una policy di posizionamento compatto contribuisce a migliorare le prestazioni di rete tra le VM, una policy di posizionamento distribuito può contribuire a migliorare la disponibilità delle VM come descritto in precedenza. Per ottenere un equilibrio ottimale tra prestazioni di rete e disponibilità, quando crei una policy di posizionamento compatto, puoi specificare la distanza che deve separare le VM. Per saperne di più, consulta Panoramica delle policy di posizionamento.

Compute Engine ha un limite per VM per la larghezza di banda di rete in uscita. Questo limite dipende dal tipo di macchina della VM e dal fatto che il traffico venga instradato attraverso la stessa rete VPC della VM di origine. Per le VM con determinati tipi di macchine, per migliorare le prestazioni di rete, puoi ottenere una larghezza di banda in uscita massima più elevata attivando il networking Tier_1.

Prestazioni di computing

Compute Engine offre un'ampia gamma di tipi di macchine predefinite e personalizzabili per i carichi di lavoro eseguiti sulle VM. Scegli un tipo di macchina appropriato in base ai tuoi requisiti di prestazioni. Per saperne di più, consulta la guida alle risorse e al confronto per le famiglie di macchine.

Multi-threading della VM

Ogni CPU virtuale (vCPU) che allochi a una VM Compute Engine viene implementata come un singolo multithread hardware. Per impostazione predefinita, due vCPU condividono un core della CPU fisica. Per le applicazioni che comportano operazioni altamente parallele o che eseguono calcoli in virgola mobile (come l'analisi della sequenza genetica e la modellazione del rischio finanziario), puoi migliorare le prestazioni riducendo il numero di thread in esecuzione su ogni core della CPU fisica. Per ulteriori informazioni, vedi Imposta il numero di thread per core.

Il multithreading delle VM potrebbe avere implicazioni di licenza per alcuni software di terze parti, come i database. Per ulteriori informazioni, leggi la documentazione sulle licenze per il software di terze parti.

Network Service Tiers

Network Service Tiers ti consente di ottimizzare i costi e le prestazioni di rete dei tuoi carichi di lavoro. Puoi scegliere il livello Premium o Standard. Il livello Premium invia il traffico sul backbone globale di Google per ottenere una perdita di pacchetti minima e una bassa latenza. Il livello Standard invia il traffico utilizzando peering, provider di servizi internet (ISP) o reti di transito in un punto di presenza (PoP) perimetrale più vicino alla regione in cui viene eseguito il tuo workload Google Cloud . Per ottimizzare il rendimento, ti consigliamo di utilizzare il livello Premium. Per ottimizzare i costi, ti consigliamo di utilizzare il livello Standard.

L'architettura descritta in questo documento utilizza un bilanciatore del carico esterno globale con un indirizzo IP esterno e backend in più regioni. Questa architettura richiede l'utilizzo del livello Premium, che utilizza il backbone globale altamente affidabile di Google per aiutarti a ottenere una perdita di pacchetti e una latenza minime.

Se utilizzi bilanciatori del carico esterni regionali e indirizzi il traffico verso le regioni utilizzando Cloud DNS, puoi scegliere il livello Premium o Standard a seconda dei tuoi requisiti. I prezzi del livello Standard sono inferiori a quelli del livello Premium. Il livello Standard è adatto al traffico non sensibile alla perdita di pacchetti e che non ha requisiti di bassa latenza.

Prestazioni di Spanner

Quando esegui il provisioning di un'istanza Spanner, specifichi la capacità di calcolo dell'istanza in termini di numero di nodi o unità di elaborazione. Monitora l'utilizzo delle risorse della tua istanza Spanner e scala la capacità in base al carico previsto e ai requisiti di prestazioni della tua applicazione. Puoi scalare la capacità di un'istanza Spanner manualmente o automaticamente. Per saperne di più, consulta la panoramica della scalabilità automatica.

Con una configurazione multiregionale, Spanner replica i dati in modo sincrono in più regioni. Questa replica consente operazioni di lettura a bassa latenza da più località. Il compromesso è una latenza maggiore per le operazioni di scrittura, perché le repliche del quorum sono distribuite su più regioni. Per ridurre al minimo la latenza per le transazioni di lettura/scrittura in una configurazione multiregionale, Spanner utilizza il routing leader-aware (attivato per impostazione predefinita).

Per suggerimenti su come ottimizzare il rendimento dell'istanza e dei database Spanner, consulta la seguente documentazione:

Memorizzazione nella cache

Se la tua applicazione pubblica asset di siti web statici e se la tua architettura include un bilanciatore del carico delle applicazioni esterno globale, puoi utilizzare Cloud CDN per memorizzare nella cache i contenuti statici a cui si accede regolarmente più vicino agli utenti. Cloud CDN può contribuire a migliorare le prestazioni per i tuoi utenti, ridurre l'utilizzo delle risorse dell'infrastruttura nel backend e ridurre i costi di distribuzione della rete. Per saperne di più, vedi Prestazioni web più veloci e protezione web migliorata per il bilanciamento del carico.

Altre considerazioni sul rendimento

Quando crei l'architettura per il tuo carico di lavoro, considera le best practice e i suggerimenti generali forniti in Google Cloud Well-Architected Framework: ottimizzazione del rendimento.

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: