Deployment globale con Compute Engine e Spanner

Last reviewed 2024-05-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 inoltre indicazioni per aiutarti a creare un'architettura che utilizzi 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 è costituito da cloud architect.

Questa architettura è in linea con l'archetipo di implementazione globale. Consigliamo questo archetipo per le applicazioni che servono utenti in tutto il mondo e richiedono alta disponibilità e robustezza contro le interruzioni in più regioni. Questa architettura supporta la scalabilità elastica a livello di rete, applicazione e database. Ti consente di allineare i costi all'utilizzo senza dover scendere a compromessi su 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 arrivo 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 applicazioni scrivono e leggono i dati da un database con replica sincrona 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 un numero elevato di proxy su Google Front End (GFE). Le richieste del cliente vengono indirizzate al GFE più vicino al cliente.

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

Per proteggere la tua applicazione da minacce come gli attacchi DDoS (Distributed Denial of Service) e il 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 di cui è stato eseguito il deployment su VM di Compute Engine che fanno parte di MIG regionali. Questi MIG sono i backend per il bilanciatore del carico globale.

Ogni gruppo di istanze gestite contiene VM 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 interregionali 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 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, consulta Scegliere un bilanciatore del carico.

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

Il livello dell'applicazione viene eseguito su VM Compute Engine che fanno parte di MIG regionali. Questi MIG sono i backend per il livello di bilanciamento del carico interno.

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

Istanze Spanner multiregione

L'applicazione scrive e legge dati da un' istanza Spanner multiregione. La configurazione per più aree geografiche 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 e sottoreti Virtual Private Cloud (VPC)

Tutte le risorse dell'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 tra regioni.

Anziché utilizzare una singola rete VPC, puoi creare una rete VPC distinta 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 altamente scalabile e 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 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 regioni Google Cloud per il tuo deployment globale e a selezionare i servizi Google Cloud appropriati.

Selezione delle regioni

Quando scegli le regioni Google Cloud in cui devono essere eseguite il deployment delle applicazioni, prendi in considerazione i seguenti fattori e requisiti:

  • Disponibilità dei servizi Google Cloud in ogni regione. Per ulteriori informazioni, consulta Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchine Compute Engine in ogni regione. Per maggiori informazioni, consulta Regioni e zone.
  • Requisiti relativi alla latenza per gli utenti finali.
  • Costo delle risorse Google Cloud.
  • Costi per il trasferimento di dati tra regioni.
  • Requisiti normativi.

Alcuni di questi fattori e requisiti potrebbero comportare compromessi. Ad esempio, la regione più conveniente in termini di costi potrebbe non avere la minore impronta di carbonio.

Servizi di calcolo

L'architettura di riferimento in questo documento utilizza le VM Compute Engine per i livelli web e di applicazione. A seconda dei requisiti della tua applicazione, puoi scegliere tra altri servizi di calcolo 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 delle applicazioni containerizzate.
  • Se preferisci concentrare le risorse IT sui dati e sulle applicazioni anziché sulla configurazione e sul funzionamento delle risorse di infrastruttura, puoi utilizzare servizi serverless come Cloud Run e funzioni 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 contenitori offrono una 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 un impegno di gestione minimo. Per ulteriori informazioni sulla scelta dei servizi di calcolo appropriati per i tuoi carichi di lavoro in Google Cloud, consulta Hosting di applicazioni su Google Cloud nel framework di architettura di Google Cloud.

Servizi di archiviazione

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

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

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

Quando progetti lo spazio di archiviazione per i tuoi workload multiregionali, tieni conto delle caratteristiche funzionali dei workload, dei requisiti di resilienza, delle aspettative relative alle prestazioni e degli obiettivi di costo. Per ulteriori informazioni, consulta Progettare 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 replicato in modo sincrono. Consigliamo una configurazione di Spanner per più regioni per le implementazioni mission-critical che richiedono una coerenza rigorosa tra regioni. Spanner supporta la replica tra regioni sincrona 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 Database Google Cloud. Quando scegli e configuri il database per un deployment multiregionale, tieni conto dei requisiti dell'applicazione per la coerenza dei dati tra regioni e tieni presente 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 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 che Transport Layer Security (TLS) venga terminato in una regione specifica o se hai bisogno di poter pubblicare contenuti da regioni specifiche, puoi utilizzare i bilanciatori del carico a livello di regione con Cloud DNS per instradare il traffico in regioni diverse. Per informazioni sulle differenze tra i bilanciatori del carico regionali e quelli globali, consulta la seguente documentazione:

Sicurezza 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 e conformità dei tuoi workload.

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 da valutare 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 del web application firewall (WAF) preconfigurate. Per ulteriori informazioni, consulta la Panoramica delle norme sulla 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 richiedono l'accesso in entrata da internet. Non assegnare indirizzi IP esterni a queste VM. Le risorse Google Cloud che hanno solo un indirizzo IP privato interno possono comunque accedere ad alcune API e servizi Google utilizzando Private Service Connect o l'accesso privato Google. Per ulteriori informazioni, consulta 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 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 soddisfano i tuoi criteri o requisiti di sicurezza), puoi definire un criterio dell'organizzazione che limiti l'utilizzo delle immagini in progetti di immagini pubbliche specifici. Per maggiori informazioni, consulta Configurare i criteri per l'utilizzo di 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 disattivato.

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

Altre considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, tieni presenti le best practice e i consigli per la sicurezza a livello di piattaforma forniti nel blueprint Enterprise Foundations.

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 regionali, l'applicazione rimane disponibile durante interruzioni isolate delle zone o delle regioni. La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless ti consente di mantenere la disponibilità e le prestazioni delle applicazioni a livelli prevedibili. Per controllare il comportamento della scalabilità automatica dei gruppi di istanze gestite stateless, puoi specificare le metriche di utilizzo target, ad esempio l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica in base alla pianificazione per i gruppi di istanze gestite stateless. I gruppi di istanze gestite stateful non possono essere sottoposti a ridimensionamento automatico. Per ulteriori informazioni, consulta Gruppi di istanze a scalabilità automatica.

Riparazione automatica delle VM

A volte le VM che ospitano la tua applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero esserci 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 i controlli di integrità basati su applicazioni all'interno del criterio di riparazione automatica dei tuoi gruppi di istanze gestite. Se l'applicazione su una determinata VM non risponde, il gruppo di istanze gestite ripara automaticamente la VM. Per saperne di più sulla configurazione della riparazione automatica, consulta Configurare un controllo di integrità e la riparazione automatica dell'applicazione.

Posizionamento della VM

Nell'architettura descritta in questo documento, il livello di applicazione e il livello web vengono eseguiti su VM Compute Engine distribuite su più zone. Questa distribuzione garantisce la robustezza dell'applicazione in caso di interruzioni della 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 le VM, le posiziona all'interno di ogni zona su diversi server fisici (chiamati host), in modo che siano resistenti ai guasti dei singoli host. Per ulteriori informazioni, consulta Applicare i criteri di posizionamento della diffusione alle VM.

Pianificazione della capacità delle VM

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

Stato del Persistent Disk

Una best practice nella progettazione di applicazioni è evitare la necessità di dischi locali stateful. Tuttavia, se il requisito esiste, puoi configurare i dischi permanenti in modo che siano stateful per assicurarti 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 la pagina Configurazione dei dischi permanenti stateful nei gruppi di istanze gestite.

Durabilità dei dati

Puoi utilizzare il servizio di Backup e DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Backup e 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 dello spazio di archiviazione di backup a lungo termine senza attività di preparazione o spostamento dei dati che richiedono molto tempo.

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

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

Puoi utilizzare la funzionalità di backup e ripristino in Spanner per contribuire a difenderti dalla corruzione dei dati causata da errori dell'operatore e problemi dell'applicazione. Per ulteriori informazioni, consulta la panoramica del backup e del ripristino di Spanner.

Affidabilità del database

I dati archiviati in un'istanza Spanner multiregione 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 multiregione viene confermata dopo che almeno tre repliche, in zone separate in due regioni, hanno eseguito il commit dell'operazione. Se si verifica un errore in una zona o una regione, Spanner ha accesso a tutti i dati, inclusi quelli delle operazioni di scrittura più recenti, e continua a soddisfare le richieste di lettura e scrittura.

Spanner utilizza l'archiviazione disaggregata in cui le risorse di calcolo e di archiviazione sono disaccoppiate. Non devi spostare i dati quando aggiungi capacità di calcolo per l'HA 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 il ridimensionamento sono più rapidi e meno rischiosi.

Spanner fornisce coerenza esterna, una proprietà più rigorosa della serializzabilità per i sistemi di elaborazione delle transazioni. Per ulteriori informazioni, consulta quanto segue:

Altre considerazioni sull'affidabilità

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

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo della configurazione e del funzionamento di una topologia Google Cloud globale creata utilizzando questa architettura di riferimento.

Tipi di macchine VM

Per aiutarti a ottimizzare l'utilizzo delle risorse delle VM, Compute Engine fornisce suggerimenti sul tipo di macchina. Utilizza i consigli per scegliere i tipi di macchine che corrispondono ai requisiti di calcolo del tuo carico di lavoro. Per i carichi di lavoro con requisiti di risorse prevedibili, puoi personalizzare il tipo di macchina in base alle tue esigenze e risparmiare 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 di applicazione e web. Il costo delle VM spot è notevolmente inferiore rispetto alle VM normali. Tuttavia, Compute Engine potrebbe arrestare o eliminare in modo preventivo le VM spot per recuperare la capacità. Le VM spot sono adatte per job batch che possono tollerare la preemption e non hanno requisiti di alta disponibilità. Le VM spot offrono gli stessi tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, quando la capacità delle risorse in una zona è limitata, i gruppi di istanze gestite potrebbero non essere in grado di eseguire lo scale out (ovvero creare VM) automaticamente fino alle dimensioni target specificate finché la capacità richiesta non diventa di nuovo disponibile.

Utilizzo delle risorse VM

La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente alla tua applicazione di gestire agevolmente l'aumento del traffico e ti aiuta a ridurre i costi quando il fabbisogno di risorse è ridotto. I gruppi di istanze gestite stateful non possono essere sottoposti a ridimensionamento automatico.

Costo del database

Spanner ti aiuta ad assicurarti 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 portate di lettura e scrittura aumentano in modo lineare 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 dell'istanza Spanner.

Licenze di terze parti

Quando esegui la migrazione dei carichi di lavoro di terze parti a Google Cloud, potresti essere in grado di ridurre i costi utilizzando le tue licenze (BYOL). Ad esempio, per eseguire il deployment delle VM Microsoft Windows Server, anziché utilizzare un'immagine premium che comporta un costo aggiuntivo 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 consente di continuare a trarre valore dai tuoi investimenti esistenti in licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, ti consigliamo di procedere nel seguente modo:

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

Altre considerazioni sui costi

Quando crei l'architettura per il tuo carico di lavoro, prendi in considerazione anche le best practice e i consigli generali forniti nel Framework dell'architettura di Google Cloud: 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 utilizzare in modo efficiente.

Aggiornamenti della configurazione della 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), crea un nuovo modello di istanza con la configurazione richiesta e poi applica 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 ulteriori informazioni su questi metodi di aggiornamento del gruppo di istanze gestite, consulta Applicare nuove configurazioni VM in un gruppo di istanze gestite.

Immagini VM

Per i modelli di istanze MIG, anziché 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 fa sempre riferimento all'immagine più recente della famiglia, pertanto i modelli di istanze e gli script possono utilizzare quell'immagine senza che tu debba aggiornare i riferimenti a una versione dell'immagine specifica.

Modelli di istanza deterministici

Se i modelli di istanze 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, come 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, consulta Modelli di istanze deterministiche.

Migrazione a Spanner

Puoi eseguire la migrazione dei dati in Spanner da altri database come MySQL, SQL Server e Oracle Database. La procedura 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, offriamo una gamma di strumenti di Google Cloud e di terze parti. Per ulteriori informazioni, consulta la 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 presenta 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 abilitata, non è necessario monitorare e scalare manualmente le dimensioni delle istanze.

Altre considerazioni operative

Quando crei l'architettura per il tuo carico di lavoro, tieni conto delle best practice e dei consigli generali per l'efficienza operativa descritti nel Framework dell'architettura di Google Cloud: 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 prestazioni dei tuoi workload.

Posizionamento della VM

Per i carichi di lavoro che richiedono una bassa latenza di rete inter-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 ulteriori informazioni, consulta la sezione Ridurre la latenza utilizzando i criteri di posizionamento compatto.

Tipi di macchine VM

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

Requisito Famiglia di macchine consigliata
Miglior rapporto prezzo/prestazioni per diversi workload Famiglia di macchine per uso generico
Massime prestazioni per core e ottimizzazione per workload ad alta intensità di calcolo Famiglia di macchine ottimizzate per il calcolo
Rapporto memoria/vCPU elevato per workload che richiedono molta memoria Famiglia di macchine ottimizzate per la memoria
GPU per carichi di lavoro parallelizzati in modo massiccio Famiglia di macchine ottimizzate per l'acceleratore
Utilizzo ridotto dei core e elevata densità di archiviazione Famiglia di macchine ottimizzate per lo spazio di archiviazione

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

Multi-threading VM

Ogni CPU virtuale (vCPU) allocata a una VM Compute Engine viene implementata come un singolo multithread hardware. Per impostazione predefinita, due vCPU condividono un core della CPU fisica. Per i carichi di lavoro altamente paralleli o che eseguono calcoli con numeri in virgola mobile (ad esempio l'analisi delle sequenze genetiche e la creazione di modelli di rischio finanziario), puoi migliorare le prestazioni riducendo il numero di thread in esecuzione su ogni core della CPU fisica. Per ulteriori informazioni, consulta Impostare il numero di thread per core.

Network Service Tiers

Network Service Tiers ti 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 un indirizzo IP esterno e backend in più regioni. Questa architettura richiede l'utilizzo del livello Premium, che utilizza la dorsale 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 inoltri il traffico alle regioni tramite 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 ulteriori informazioni, 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 con bassa latenza da più località. Il compromesso è una latenza più elevata per le operazioni di write, 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 con più regioni, Spanner utilizza il routing consapevole del leader (abilitato per impostazione predefinita).

Per consigli 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 viene eseguito spesso l'accesso più vicino agli utenti. Cloud CDN può contribuire a migliorare le prestazioni per gli utenti, ridurre l'utilizzo delle risorse dell'infrastruttura nel backend e ridurre i costi di distribuzione sulla rete. Per ulteriori informazioni, consulta 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, tieni conto delle best practice e dei consigli generali forniti nel framework dell'architettura di Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: