Deployment globale con Compute Engine e Spanner

Last reviewed 2024-05-12 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione multi-livello in esecuzione su VM di Compute Engine e Spanner in una topologia globale in Google Cloud. Il documento fornisce inoltre indicazioni utili per creare un'architettura che usa altri servizi dell'infrastruttura Google Cloud. Descrive i fattori di progettazione da prendere in considerazione quando crei un'architettura globale per le applicazioni cloud. Questo documento è destinato ai cloud architect.

Questa architettura è in linea con l'archetipo di deployment globale. Consigliamo questo archetipo per le applicazioni che servono gli utenti di tutto il mondo e che necessitano di disponibilità elevata e robustezza contro le interruzioni in più regioni. Questa architettura supporta la scalabilità elastica a livello di rete, applicazione e database. Consente di allineare i costi con l'utilizzo senza dover scendere a compromessi su prestazioni, disponibilità o scalabilità.

Architettura

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

Architettura di deployment globale tramite 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 tra regioni 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 e leggono i dati in 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 pubblicizza un singolo indirizzo IP anycast, ma è implementato come numero elevato di proxy su Google Front End (GFE). Le richieste del client vengono indirizzate al 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 proxy esterno globale. Per maggiori informazioni, consulta 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 a livello di regione per il livello web

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

Ogni gruppo di istanze gestite contiene VM di Compute Engine in tre zone diverse. Ognuna 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 tra regioni gestiscono la distribuzione del traffico dalle VM del livello web in qualsiasi regione alle VM del livello di applicazione in tutte le regioni.

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

Gruppi di istanze gestite a livello di regione per il livello di applicazione

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

Ogni gruppo di istanze gestite contiene VM di Compute Engine in tre zone diverse. Ogni VM ospita un'istanza indipendente del livello di applicazione.

Istanza Spanner multiregionale

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

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

Tutte le risorse nell'architettura utilizzano una singola rete VPC. La rete VPC include 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 mostrata nel diagramma dell'architettura) Una subnet solo proxy in ogni regione per il bilanciatore del carico interno tra regioni.

Anziché utilizzare un'unica 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 computing sicuro e personalizzabile che consente di creare ed eseguire VM sull'infrastruttura di Google.
  • Cloud Load Balancing: un portafoglio di bilanciatori del carico ad alte prestazioni, scalabili, globali e a livello di regione.
  • Spanner: un servizio di database relazionale a scalabilità elevata, coerente a livello globale.

Note sul layout

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

Progettazione del sistema

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

Selezione della regione

Quando scegli le regioni Google Cloud in cui deve essere eseguito il deployment delle applicazioni, considera i fattori e i requisiti seguenti:

  • Disponibilità dei servizi Google Cloud in ogni regione. Per maggiori informazioni, consulta la pagina Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchina Compute Engine in ciascuna 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 dei compromessi. Ad esempio, l'area geografica più conveniente potrebbe non avere l'impronta di carbonio più bassa. Per maggiori informazioni, consulta Selezionare zone e regioni geografiche nel framework dell'architettura Google Cloud.

Servizi di computing

L'architettura di riferimento in questo documento utilizza le VM di Compute Engine per il livello web e per le applicazioni. A seconda dei requisiti della tua applicazione, puoi scegliere tra altri servizi di computing Google Cloud:

  • Puoi eseguire applicazioni containerizzate nei cluster Google Kubernetes Engine (GKE). GKE è un motore di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione
  • Se preferisci concentrare le tue iniziative IT sui dati e sulle applicazioni anziché configurare e gestire le risorse dell'infrastruttura, puoi utilizzare servizi serverless come Cloud Run e Cloud Functions.

La decisione di utilizzare VM, container o servizi serverless comporta un compromesso tra flessibilità di configurazione e attività di gestione. VM e container offrono una maggiore flessibilità di configurazione, ma sei responsabile della gestione delle risorse. In un'architettura serverless, il deployment dei carichi di lavoro su una piattaforma preconfigurata che richiede il minimo sforzo di gestione. Per ulteriori informazioni sulla scelta dei servizi di computing appropriati per i carichi di lavoro in Google Cloud, consulta Scegliere e gestire il computing nel framework dell'architettura Google Cloud.

Servizi di archiviazione

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

Altre opzioni di archiviazione per i deployment multiregionali includono i bucket Cloud Storage a due o più regioni. Gli oggetti archiviati in un bucket a due o più regioni vengono archiviati in modo ridondante in almeno due località geografiche separate. I metadati sono scritti in modo sincrono tra le regioni e i dati vengono replicati in modo asincrono. Per i bucket a due regioni, puoi utilizzare la replica turbo, che garantisce una replica più rapida tra le regioni. Per ulteriori informazioni, consulta Disponibilità e durabilità dei dati.

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

Quando progetti l'archiviazione per i carichi di lavoro multiregionali, considera le caratteristiche funzionali dei carichi di lavoro, i requisiti di resilienza, le aspettative nelle prestazioni e gli obiettivi di costo. Per ulteriori informazioni, consulta Progettazione di una strategia di archiviazione ottimale per il 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 con replica sincrona. Consigliamo una configurazione di Spanner per più regioni per i deployment mission critical che richiedono un'elevata coerenza tra regioni. Spanner supporta la replica sincrona tra regioni senza tempi di inattività per failover, manutenzione o ridimensionamento.

Per informazioni sugli altri servizi di database gestiti tra cui puoi scegliere in base ai tuoi requisiti, consulta Database Google Cloud. Quando scegli e configuri il database per un deployment in più regioni, considera i requisiti della tua applicazione in termini di coerenza dei dati tra regioni e prendi in considerazione i compromessi in termini di prestazioni e costi.

Opzioni di bilanciamento del carico esterno

Un'architettura che utilizza un bilanciatore del carico esterno globale, come quella illustrata in questo documento, supporta alcune funzionalità utili per migliorare l'affidabilità dei 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 l'esecuzione di Transport Layer Security (TLS) in una regione specifica o se hai bisogno della capacità di gestire contenuti da regioni specifiche, puoi utilizzare bilanciatori del carico regionali con Cloud DNS per instradare il traffico a regioni diverse. Per informazioni sulle differenze tra i bilanciatori del carico regionali e globali, consulta la seguente documentazione:

Sicurezza e conformità

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

Protezione dalle minacce

Per proteggere la tua applicazione da minacce come attacchi DDoS e XSS, puoi utilizzare i criteri di sicurezza di Google Cloud Armor. Ogni criterio è un insieme di regole che specifica determinate condizioni che devono essere valutate e le 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 firewall per applicazioni web (WAF) preconfigurate. Per maggiori informazioni, consulta Panoramica dei criteri di sicurezza.

Accesso esterno per le VM

Nell'architettura di riferimento descritta in questo documento, le VM che ospitano il livello di applicazione e il livello web non hanno bisogno dell'accesso in entrata da internet. Non assegnare indirizzi IP esterni a queste VM. Le risorse Google Cloud che hanno solo un indirizzo IP interno privato possono comunque accedere a determinati servizi e API Google utilizzando Private Service Connect o accesso privato Google. Per maggiori informazioni, vedi Opzioni di accesso privato per i servizi.

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

Sicurezza delle immagini VM

Per assicurarti che le VM utilizzino solo immagini approvate (ovvero immagini con software che soddisfi i requisiti dei criteri o di sicurezza), puoi definire un criterio dell'organizzazione che limiti l'uso delle immagini in specifici progetti di immagini pubbliche. Per maggiori informazioni, consulta la pagina Configurare i criteri per le immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui è abilitata l'API Compute Engine, viene creato automaticamente un account di servizio predefinito. Per le organizzazioni Google Cloud create prima del 3 maggio 2024, a questo account di servizio predefinito viene concesso il ruolo IAM Editor (roles/editor), a meno che questo comportamento non sia disabilitato.

Per impostazione predefinita, l'account di servizio predefinito è collegato a tutte le VM che crei utilizzando Google Cloud CLI o la console Google Cloud. Il ruolo Editor include una vasta gamma di autorizzazioni, quindi il collegamento dell'account di servizio predefinito alle VM crea un rischio per la sicurezza. Per evitare questo rischio, puoi creare e utilizzare account di servizio dedicati per ogni applicazione. Per specificare le risorse alle quali l'account di servizio può accedere, utilizza criteri granulari. Per ulteriori informazioni, vedi Limitare i privilegi degli account di servizio in "Best practice per l'utilizzo degli account di servizio".

Ulteriori considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, considera le best practice e i suggerimenti per la sicurezza a livello di piattaforma forniti nel progetto di base Enterprise.

Affidabilità

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

Scalabilità automatica MIG

Quando esegui l'applicazione su più gruppi di istanze gestite a livello di regione, l'applicazione rimane disponibile durante le interruzioni di zone o regioni isolate. La 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 della scalabilità automatica dei MIG stateless, puoi specificare le metriche di utilizzo target, come l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica basata su pianificazione per i MIG stateless. I MIG stateful non possono essere scalati automaticamente. Per ulteriori informazioni, consulta Scalabilità automatica dei gruppi di istanze.

Riparazione automatica delle VM

A volte le VM che ospitano la tua applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero verificarsi problemi con l'applicazione stessa. Potrebbe bloccarsi, arrestarsi in modo anomalo o non avere memoria sufficiente. Per verificare se un'applicazione risponde come previsto, puoi configurare controlli di integrità basati sull'applicazione come parte del criterio di riparazione automatica dei gruppi di istanze gestite. Se l'applicazione su una determinata VM non risponde, il gruppo di istanze gestite corregge automaticamente la VM. Per ulteriori informazioni sulla configurazione della riparazione automatica, vedi Configurare un controllo di integrità dell'applicazione e riparazione automatica.

Posizionamento VM

Nell'architettura descritta in questo documento, il livello di applicazione e il livello web vengono eseguiti su VM di Compute Engine distribuite in più zone. Questa distribuzione garantisce che l'applicazione sia robusta contro le interruzioni di zona. Per migliorare ulteriormente questa robustezza, puoi creare un criterio di posizionamento distribuito e applicarlo al modello MIG. Quando il gruppo di istanze gestite crea VM, le posiziona all'interno di ogni zona su diversi server fisici (chiamati host), in modo che le VM siano affidabili contro i guasti dei singoli host. Per maggiori informazioni, consulta Applicare criteri di posizionamento distribuiti alle VM.

Pianificazione della capacità delle VM

Per assicurarti che la capacità per le VM di Compute Engine sia disponibile quando è richiesta per la scalabilità automatica del gruppo di istanze gestite, puoi creare prenotazioni. Una prenotazione offre capacità garantita in una zona specifica per un numero specifico di VM di un tipo di macchina scelto da te. Una prenotazione può essere specifica di un progetto o condivisa tra più progetti. Per ulteriori informazioni sulle prenotazioni, incluse le considerazioni relative alla fatturazione, consulta Prenotazioni di risorse di zona di Compute Engine.

Stato Persistent Disk

Una best practice nella progettazione di applicazioni consiste nell'evitare la necessità di dischi stateful locali. 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 facilmente alle immagini più recenti con nuove versioni e patch di sicurezza. Per ulteriori informazioni, consulta Configurazione di dischi permanenti stateful nei gruppi di istanze gestite.

Durabilità dei dati

Puoi utilizzare il servizio di backup e RE per creare, archiviare e gestire i backup delle VM di Compute Engine. Il servizio Backup & RE archivia i dati di backup nel formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i carichi di lavoro in produzione utilizzando direttamente i dati provenienti dall'archiviazione di backup a lungo termine senza attività di preparazione o spostamento dei dati dispendiose in termini di tempo.

Compute Engine offre le seguenti opzioni per aiutarti a garantire la durabilità dei dati archiviati in volumi di Persistent Disk:

  • Gli snapshot standard consentono di acquisire lo stato point-in-time dei volumi di Persistent Disk. Gli snapshot sono archiviati in modo ridondante in più regioni, con checksum automatici per garantire l'integrità dei dati. Per impostazione predefinita, gli snapshot sono incrementali, quindi utilizzano meno spazio di archiviazione e ti permettono di risparmiare. Gli snapshot vengono archiviati in una località Cloud Storage che puoi configurare. Per ulteriori suggerimenti sull'utilizzo e sulla gestione degli snapshot, consulta le best practice per gli snapshot dei dischi di Compute Engine.
  • I volumi di dischi permanenti a livello di regione consentono di eseguire applicazioni a disponibilità elevata che non sono interessate da errori nei dischi permanenti. Quando crei un volume di Persistent Disk a livello di regione, Compute Engine mantiene una replica del disco in una zona diversa all'interno della stessa regione. I dati vengono replicati in modo sincrono nei dischi in entrambe le zone. Se si verifica un'interruzione in una delle due zone, i dati rimangono disponibili.

Puoi utilizzare la funzionalità di backup e ripristino in Spanner per proteggerti dal danneggiamento dei dati causato da errori dell'operatore e problemi dell'applicazione. Per maggiori informazioni, consulta Panoramica del backup e ripristino di Spanner.

Affidabilità del database

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

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

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

Spanner utilizza l'archiviazione disaggregata in cui le risorse di computing e archiviazione sono disaccoppiate. Non è necessario spostare i dati quando aggiungi capacità di calcolo per l'alta disponibilità o la scalabilità. Le nuove risorse di computing ricevono i dati quando ne hanno bisogno dal nodo Colossus più vicino. Ciò rende il failover e la scalabilità più rapidi e meno rischiosi.

Spanner offre la coerenza esterna, che è una proprietà più rigida rispetto alla serializzabilità per i sistemi di elaborazione delle transazioni. Per ulteriori informazioni, consulta quanto segue:

Ulteriori 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 i costi di configurazione e gestione di una topologia Google Cloud globale creata utilizzando questa architettura di riferimento.

Tipi di VM

Per aiutarti a ottimizzare l'utilizzo delle risorse VM, Compute Engine fornisce suggerimenti per il tipo di macchina. Utilizza i suggerimenti per scegliere i tipi di macchina che corrispondono ai requisiti di calcolo del carico di lavoro. Per carichi di lavoro con requisiti di risorse prevedibili, puoi personalizzare il tipo di macchina in base alle tue esigenze e risparmiare denaro utilizzando 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 per applicazioni 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 Le VM spot sono adatte per job batch che possono tollerare il prerilascio e non hanno requisiti di alta disponibilità. Le VM spot offrono gli stessi tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, se la capacità delle risorse in una zona è limitata, i gruppi di istanze gestite potrebbero non essere in grado di fare lo scale out automatico (ovvero di creare VM) automaticamente per la dimensione target specificata fino a quando la capacità richiesta non diventa di nuovo disponibile.

Utilizzo delle risorse VM

La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente all'applicazione di gestire agevolmente l'aumento del traffico e a ridurre i costi quando il fabbisogno di risorse è ridotto. I MIG stateful non possono essere scalati automaticamente.

Costo del database

Spanner aiuta a garantire che i costi del database siano prevedibili. La capacità di calcolo specificata (numero di nodi o unità di elaborazione) determina la capacità di archiviazione. Le velocità effettiva di lettura e scrittura scalano in modo lineare con capacità di calcolo. Paghi solo per quello che utilizzi. Quando devi allineare i costi alle esigenze del tuo carico di lavoro, puoi regolare le dimensioni dell'istanza di Spanner.

Licenze di terze parti

Quando esegui la migrazione di carichi di lavoro di terze parti in Google Cloud, potresti riuscire a ridurre i costi 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 di Windows personalizzata. Quindi paghi solo per l'infrastruttura delle VM che utilizzi su Google Cloud. Questa strategia ti consente di continuare a ottenere valore dagli investimenti esistenti in licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, ti consigliamo di procedere come segue:

  • Esegui il provisioning del numero richiesto di core della CPU di computing indipendentemente dalla memoria utilizzando tipi di macchine personalizzate. In questo modo, limiti il costo delle licenze di terze parti al numero di core CPU necessari.
  • Riduci il numero di vCPU per core da 2 a 1 disabilitando il multi-threading simultaneo (SMT) e riduci i costi delle licenze del 50%.

Ulteriori considerazioni sui costi

Quando crei l'architettura per il tuo carico di lavoro, considera anche le best practice e i suggerimenti generali forniti in Framework dell'architettura Google Cloud: ottimizzazione dei costi.

Efficienza operativa

Questa sezione descrive i fattori da prendere in considerazione quando utilizzi questa architettura di riferimento per progettare e creare una topologia Google Cloud globale con efficienza operativa.

Aggiornamenti della configurazione delle VM

Per aggiornare la configurazione delle VM in un gruppo di istanze gestite (ad esempio il tipo di macchina o l'immagine del disco di avvio), devi creare un nuovo modello di istanza con la configurazione richiesta e quindi applicare il nuovo modello al gruppo di istanze gestite. Il gruppo di istanze gestite aggiorna le VM utilizzando il metodo di aggiornamento scelto: 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 gruppo di istanze gestite, consulta Applicare nuove configurazioni di VM in un gruppo di istanze gestite.

Immagini VM

Per i modelli di istanza MIG, invece di utilizzare le immagini pubbliche fornite da Google, ti consigliamo di creare e utilizzare immagini personalizzate contenenti 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 rimanda sempre all'immagine più recente della famiglia, in modo che i modelli e gli script di istanza possano utilizzarla senza che tu debba aggiornare i riferimenti a una versione specifica dell'immagine.

Modelli di istanza deterministici

Se i modelli di istanza che utilizzi per i gruppi di istanze gestite includono script di avvio per installare software di terze parti, assicurati che gli script specifichino esplicitamente i parametri di installazione del software, come la versione software. In caso contrario, quando il gruppo di istanze gestite 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, consulta Modelli di istanza deterministici.

Migrazione a Spanner

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

Amministrazione di 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 ha tempi di inattività per la manutenzione e il failover del database. Per ridurre ulteriormente la complessità operativa, puoi configurare la scalabilità automatica. Se la scalabilità automatica è abilitata, non è necessario monitorare e scalare manualmente le dimensioni dell'istanza.

Ulteriori considerazioni operative

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

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da prendere in considerazione quando si utilizza questa architettura di riferimento per progettare e creare una topologia globale in Google Cloud che soddisfi i requisiti di prestazioni dei carichi di lavoro.

Posizionamento VM

Per i carichi di lavoro che richiedono una bassa latenza di rete tra le VM, puoi creare un criterio di posizionamento compatto e applicarlo al modello MIG. Quando il gruppo di istanze gestite crea le VM, le posiziona su server fisici vicini tra loro. Per maggiori informazioni, consulta Ridurre la latenza utilizzando i criteri di posizionamento compatto.

Tipi di VM

Compute Engine offre un'ampia gamma di tipi di macchine predefinite e personalizzabili tra cui puoi scegliere in base ai tuoi requisiti di costo e prestazioni. I tipi di macchina sono raggruppati in serie e famiglie di macchine. La tabella seguente fornisce un riepilogo delle famiglie di macchine consigliate per i diversi tipi di carichi di lavoro:

Requisito Famiglia di macchine consigliata
Miglior rapporto prezzo/prestazioni per diversi carichi di lavoro Famiglia di macchine per uso generico
Massime prestazioni per core e ottimizzate per carichi di lavoro ad alta intensità di calcolo Famiglia di macchine ottimizzate per il calcolo
Rapporto memoria-vCPU elevato per carichi di lavoro che richiedono molta memoria Famiglia di macchine ottimizzate per la memoria
GPU per carichi di lavoro a elevata parallelizzazione Famiglia di macchine ottimizzate per l'acceleratore
Basso utilizzo dei core e alta densità di archiviazione Famiglia di macchine ottimizzate per l'archiviazione

Per maggiori informazioni, consulta la Guida alle risorse e al confronto per le famiglie di macchine.

Multi-threading delle VM

Ogni CPU virtuale (vCPU) allocata a una VM di Compute Engine viene implementata come un singolo multithread hardware. Per impostazione predefinita, due vCPU condividono un core CPU fisico. Per i carichi di lavoro altamente paralleli 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 eseguiti su ciascun core della CPU fisica. Per maggiori informazioni, consulta Impostare il numero di thread per core.

Network Service Tiers

Network Service Tiers consente di ottimizzare i costi e le prestazioni della rete dei tuoi carichi di lavoro. A seconda dei tuoi requisiti, puoi scegliere il livello Premium o Standard.

L'architettura in questo documento utilizza un bilanciatore del carico esterno globale con indirizzo IP esterno e backend in più regioni. Questa architettura richiede l'uso 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 instrada il traffico alle regioni mediante Cloud DNS, puoi scegliere il livello Premium o Standard a seconda dei tuoi requisiti. Il prezzo del livello Standard è inferiore a quello del livello Premium. Il livello Standard è adatto al traffico non sensibile alla perdita di pacchetti e che non ha requisiti di bassa latenza.

Prestazioni 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 dell'istanza Spanner e scala la capacità in base al carico previsto e ai requisiti di prestazioni dell'applicazione. Puoi scalare la capacità di un'istanza Spanner manualmente o automaticamente. Per maggiori informazioni, consulta 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à. Lo svantaggio è avere una latenza maggiore per le operazioni di scrittura, poiché le repliche del quorum sono distribuite in più regioni. Per ridurre al minimo la latenza per le transazioni di lettura-scrittura in una configurazione multiregionale, Spanner utilizza il routing con consapevolezza leader (abilitato per impostazione predefinita).

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

Memorizzazione nella cache

Se l'applicazione gestisce asset di siti web statici e se l'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 di frequente più vicino agli utenti. Cloud CDN può contribuire a migliorare le prestazioni per i tuoi utenti, ridurre l'utilizzo di risorse dell'infrastruttura nel backend e i costi di distribuzione della rete. Per maggiori informazioni, consulta Prestazioni web più veloci e protezione web migliorata per il bilanciamento del carico.

Ulteriori considerazioni sulle prestazioni

Quando crei l'architettura per il tuo carico di lavoro, considera le best practice e i suggerimenti generali forniti nel framework dell'architettura Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: