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 un ambiente una topologia in Google Cloud. Il documento fornisce inoltre indicazioni per aiutarti a creare che utilizza altri servizi dell'infrastruttura Google Cloud. it descrive i fattori di progettazione da prendere in considerazione quando si crea una per le tue applicazioni cloud. Il pubblico di destinazione Cloud Architect.

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

Architettura

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

Architettura di deployment globale tramite Compute Engine e Spanner.

In questa architettura, un bilanciatore del carico globale distribuisce le richieste in entrata server web nelle regioni appropriate in base alla loro disponibilità, capacità vicinanza alla sorgente del traffico. Un bilanciamento del carico interno tra regioni gestisce la distribuzione del traffico dai server web all'app a server delle applicazioni in base alla loro disponibilità e capacità. L'applicazione 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 annuncia singolo anycast, ma il bilanciatore del carico è implementato come un di proxy . Google Front End (GFE). Le richieste dei client vengono indirizzate al GFE più vicino al cliente.

In base ai tuoi requisiti, puoi utilizzare una un bilanciatore del carico delle applicazioni esterno globale o un bilanciatore . Network Load Balancer proxy esterno globale. Per ulteriori informazioni, vedi Scegli un bilanciatore del carico.

Per proteggere la tua applicazione da minacce come attacchi DDoS (Denial of Service) e cross-site scripting (XSS), è possibile usare Criteri di sicurezza di Google Cloud Armor.

A livello di regione gruppi di istanze gestite per il livello web

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

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

Livello di bilanciamento del carico interno tra regioni

I bilanciatori del carico interni con backend tra regioni gestiscono del traffico dalle VM a livello web in qualsiasi regione a livello di applicazione in tutte le regioni.

In base ai tuoi requisiti, puoi utilizzare una un bilanciatore del carico delle applicazioni interno tra regioni o un . il bilanciatore del carico di rete proxy interno tra regioni. Per ulteriori informazioni, vedi Scegli un bilanciatore del carico.

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

Il deployment del livello di applicazione viene eseguito sulle 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 di bilanciamento del carico interno.

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

Istanza Spanner multiregionale

L'applicazione scrive dati e legge da un dell'istanza Spanner multiregionale. La località multiregionale configurazione in questa architettura include di repliche:

  • Quattro repliche di lettura e scrittura in zone separate in due regioni.
  • Una replica di testimonianza in una terza regione.
alla rete VPC (Virtual Private Cloud) . 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) A una subnet solo proxy in ogni regione per l'infrastruttura con il bilanciatore del carico di rete passthrough esterno regionale.

Anziché utilizzare un'unica rete VPC, puoi creare una rete VPC rete VPC 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 ti consente per creare ed eseguire VM sull'infrastruttura di Google.
  • Cloud Load Balancing: un portafoglio di soluzioni scalabili, globali e ad alte prestazioni di bilanciatori del carico regionali.
  • Spanner: un ambiente relazionale altamente scalabile, coerente a livello globale completamente gestito di Google Cloud.

Note sul layout

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

Progettazione del sistema

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

Selezione delle regioni

Quando scegli le regioni Google Cloud in cui devono essere è necessario considerare i fattori e i requisiti seguenti:

  • Disponibilità dei servizi Google Cloud in ogni regione. Per ulteriori informazioni le informazioni, vedi Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchina Compute Engine in ciascuna regione. Per ulteriori informazioni, vedi Regioni e zone.
  • Utente finale latenza i tuoi requisiti.
  • Costo delle risorse Google Cloud.
  • Trasferimento di dati tra regioni costi.
  • Requisiti normativi.

Alcuni di questi fattori e requisiti potrebbero comportare dei compromessi. Ad esempio: la regione più economica potrebbe non avere l'impronta di carbonio più bassa. Per ulteriori informazioni, vedi Selezionare zone geografiche e regioni nel framework dell'architettura Google Cloud.

Servizi di computing

L'architettura di riferimento in questo documento utilizza le VM di Compute Engine per ai livelli web e alle applicazioni. In base ai requisiti del tuo puoi scegliere tra altri servizi di computing Google Cloud:

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

La decisione di utilizzare VM, container o servizi serverless implica un compromesso tra flessibilità di configurazione e sforzi di gestione. VM i container offrono una maggiore flessibilità di configurazione, ma nella gestione delle risorse. In un'architettura serverless, il deployment dei carichi di lavoro una piattaforma preconfigurata che richiede il minimo sforzo di gestione. Per ulteriori informazioni informazioni sulla scelta dei servizi di computing appropriati per i carichi di lavoro in per 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 regionali per le VM. I volumi dei dischi permanenti a livello di regione offrono la replica sincrona di dati in due zone all'interno di una regione. I dati nei volumi di Persistent Disk sono non replicati tra regioni.

Altre opzioni di archiviazione per i deployment multiregionali includono Cloud Storage di bucket a due o più regioni. Oggetti archiviati in una doppia regione sono archiviati in modo ridondante in almeno due aree geografiche separate luoghi. I metadati sono scritti in modo sincrono tra le regioni e i dati replicati in modo asincrono. Per i bucket a due regioni, puoi utilizzare replica turbo, assicurando una replica più rapida tra le regioni. Per ulteriori informazioni, vedi Disponibilità e durabilità dei dati.

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

Quando progetti l'archiviazione per carichi di lavoro multiregionali, considera caratteristiche funzionali dei carichi di lavoro, requisiti di resilienza, previsioni di rendimento e obiettivi di costo. Per ulteriori informazioni, vedi 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, uno completamente gestito, scalabile orizzontalmente, distribuito a livello globale a replica sincrona. Consigliamo una strategia multiregionale Configurazione Spanner per deployment mission critical che richiedono un'elevata coerenza tra regioni. Spanner supporta replica sincrona tra regioni senza tempi di inattività per failover, manutenzione o il ridimensionamento.

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

Opzioni di bilanciamento del carico esterno

Un'architettura che utilizza un bilanciatore del carico esterno globale, come di questo documento, supporta alcune funzioni che consentono di 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'interruzione del protocollo Transport Layer Security (TLS) in una regione specifica o se hai bisogno della possibilità di pubblicare contenuti da regioni, puoi utilizzare bilanciatori del carico a livello di regione con Cloud DNS per instradare il traffico in diverse regioni. Per informazioni sulle differenze tra i segmenti di pubblico bilanciatori del carico globali, consulta la documentazione seguente:

Sicurezza e conformità

Questa sezione descrive i fattori da prendere in considerazione quando utilizzi questo di riferimento per progettare e creare una topologia globale Google Cloud che soddisfa i requisiti di sicurezza e conformità del tuo carichi di lavoro con scale out impegnativi.

Protezione dalle minacce

Per proteggere la tua applicazione da minacce come attacchi DDoS e XSS, puoi: usano i criteri di sicurezza di Google Cloud Armor. Ogni criterio è un insieme di regole specifica determinate condizioni che devono essere valutate e le azioni da intraprendere quando che le condizioni siano soddisfatte. Ad esempio, una regola potrebbe specificare che, se l'oggetto l'indirizzo IP di origine del traffico corrisponde a un indirizzo IP o a un intervallo CIDR specifico, è necessario negare il traffico. Puoi anche applicare applicazioni web preconfigurate delle regole firewall (WAF). Per ulteriori informazioni, vedi 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 quello web non necessitano dell'accesso in entrata internet. Non assegnare indirizzi IP esterni a queste VM. Risorse Google Cloud che hanno solo un IP interno privato può comunque accedere a determinati servizi e API di Google utilizzando Private Service Connect o accesso privato Google. Per ulteriori informazioni le 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 di riferimento, puoi utilizzare Proxy web sicuro 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'organizzazione che limita l'uso delle immagini in progetti di immagini pubbliche specifici. Per ulteriori informazioni, vedi Configurare i criteri per le immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui è abilitata l'API Compute Engine, account di servizio predefinito viene creata automaticamente. 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 non sia indicato il comportamento è disattivato.

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

Ulteriori considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, considera il livello di piattaforma best practice e consigli in materia di sicurezza forniti Progetto delle basi aziendali.

Affidabilità

Questa sezione descrive i fattori di progettazione da prendere in considerazione quando utilizzi a questa architettura di riferimento per creare e gestire un'infrastruttura affidabile nel 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 disponibili durante le interruzioni di una zona o di una regione isolate. La scalabilità automatica dei MIG stateless consente di mantenere la disponibilità delle applicazioni del rendimento a livelli prevedibili. Per controllare il comportamento della scalabilità automatica MIG stateless, puoi specificare metriche di utilizzo target, come all'utilizzo delle risorse. Puoi anche configurare la scalabilità automatica basata sulla pianificazione per gruppi di istanze gestite. MIG stateful non possono essere scalati automaticamente. Per ulteriori informazioni, vedi Gruppi di istanze con scalabilità automatica.

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 hanno memoria sufficiente. Per verificare se un'applicazione risponde puoi configurare i controlli di integrità basati sull'applicazione nell'ambito dei tuoi 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 configurare la riparazione automatica, consulta Configura un controllo di integrità delle applicazioni e una riparazione automatica.

Posizionamento VM

Nell'architettura descritta in questo documento, il livello di applicazione e di livello base, vengono eseguite su VM di Compute Engine distribuite su più diverse. Questa distribuzione garantisce che l'applicazione sia robusta contro le zone o in caso di interruzione del servizio. 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, posiziona le VM all'interno di ciascuna zona su diversi server fisici (chiamati host), in modo che le tue VM affidabile contro gli errori dei singoli host. Per ulteriori informazioni, vedi Applica alle VM criteri di posizionamento distribuito.

Pianificazione della capacità delle VM

per assicurarti che la capacità per le VM di Compute Engine sia disponibile necessaria per la scalabilità automatica MIG, puoi creare prenotazioni. Una prenotazione offre capacità garantita in una zona specifica per un numero specificato di VM di un il tipo di macchina scelto. Una prenotazione può essere specifica per un progetto condivisi tra più progetti. Per ulteriori informazioni sulle prenotazioni, incluse le considerazioni sulla fatturazione, Prenotazioni delle risorse di zona Compute Engine.

Stato Persistent Disk

Una best practice nella progettazione delle applicazioni è evitare la necessità di un client stateful i dischi permanenti. Ma se il requisito esiste, puoi configurare i tuoi dischi permanenti essere stateful per garantire che i dati vengano conservati anche quando le VM vengono riparate viene ricreato. Tuttavia, ti consigliamo di mantenere i dischi di avvio stateless, puoi aggiornarle facilmente alle immagini più recenti con nuove versioni e sicurezza patch. Per ulteriori informazioni, vedi Configurazione di dischi permanenti stateful nei gruppi di istanze gestite.

Durabilità dei dati

Puoi utilizzare Servizio di Backup & DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Backup & RE archivia i dati di backup nel file originale leggibile dall'applicazione formato. Se necessario, puoi ripristinare i carichi di lavoro in produzione utilizzando i dati provenienti da un'archiviazione di backup a lungo termine senza dover spostare i dati in modo dispendioso in termini di tempo o attività di preparazione.

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

  • Snapshot standard consentono di acquisire lo stato point-in-time dei volumi Persistent Disk. La vengono archiviati in modo ridondante in più regioni, con per garantire l'integrità dei dati. Gli snapshot sono incrementali per impostazione predefinita, quindi occupano meno spazio di archiviazione e tu potrai risparmiare. Snapshot sono archiviati in un Località di Cloud Storage che puoi configurare. Per altri consigli sull'utilizzo e la gestione gli snapshot, vedi Best practice per gli snapshot dei dischi di Compute Engine.
  • 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 regionale, Compute Engine mantiene una replica del disco in una zona diversa nella stessa regione. I dati vengono replicati in modo sincrono nei dischi diverse. Se si verifica un'interruzione in una delle due zone, i dati rimangono disponibili.

Puoi usare la funzionalità di backup e ripristino in Spanner per aiutarti protegge dal danneggiamento dei dati causato da errori dell'operatore e applicazioni che le applicazioni presentino problemi di prestazioni. Per ulteriori informazioni, vedi Panoramica del backup e ripristino di Spanner.

Affidabilità del database

I dati archiviati in un'istanza Spanner multiregionale sono replicati in modo sincrono tra più regioni. Spanner mostrata nel precedente diagramma dell'architettura include persone che seguo repliche:

  • 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 confermati dopo almeno tre repliche, in zone separate tra 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 provenienti ultime operazioni di scrittura e continua a gestire richieste di lettura e scrittura.

Spanner utilizza 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 più vicino Colossus nodo. Ciò rende il failover e la scalabilità più rapidi e meno rischiosi.

Spanner offre la coerenza esterna, che è una maggiore rispetto alla serializzabilità per i sistemi di elaborazione delle transazioni. Per ulteriori informazioni informazioni, consulta le seguenti risorse:

Ulteriori considerazioni sull'affidabilità

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

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare i costi di configurazione e gestione una topologia Google Cloud globale creata utilizzando questo riferimento dell'architettura.

Tipi di VM

Per aiutarti a ottimizzare l'utilizzo delle risorse VM, Compute Engine fornisce suggerimenti sul tipo di macchina. Utilizza i suggerimenti per scegliere i tipi di macchina che corrispondono alle esigenze del tuo carico di lavoro di computing. 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 tipi di macchine personalizzate.

Modello di provisioning delle VM

Se la tua applicazione è a tolleranza di errore, VM spot può aiutarti a ridurre i costi di Compute Engine per le VM per applicazioni e web. Il costo delle VM spot è significativamente rispetto alle VM normali. Tuttavia, Compute Engine potrebbe arrestarsi o eliminare le VM spot per recuperare capacità. Spot VM sono adatti per job batch che possono tollerare il prerilascio e non hanno requisiti di disponibilità. Le VM spot offrono gli stessi tipi di macchina, le opzioni di archiviazione e le prestazioni delle normali VM. Tuttavia, quando la capacità delle risorse una zona è limitata, i gruppi di istanze gestite potrebbero non essere in grado di fare lo scale out (ovvero creare VM) automaticamente alla dimensione target specificata finché la capacità richiesta non diventa disponibile di nuovo.

Utilizzo delle risorse VM

La scalabilità automatica dei MIG stateless consente all'applicazione di gestire l'aumento gestire il traffico in modo controllato e aiuta a ridurre i costi quando sono necessarie risorse è basso. 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 è necessario allineare in base alle esigenze del tuo carico di lavoro, puoi regolare le dimensioni Spanner.

Licenze di terze parti

Quando esegui la migrazione di carichi di lavoro di terze parti su Google Cloud, potresti essere in grado per ridurre i costi BYOL (Bring Your Own License). Ad esempio, per eseguire il deployment alle VM Microsoft Windows Server, anziché utilizzare un immagine premium che comporta costi aggiuntivi per la licenza di terze parti, puoi creare a 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 dai tuoi investimenti esistenti in licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, ti consigliamo di eseguire le seguenti operazioni:

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

Ulteriori considerazioni sui costi

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

Efficienza operativa

Questa sezione descrive i fattori da prendere in considerazione quando utilizzi questo un'architettura di riferimento per progettare e creare una topologia Google Cloud globale da poter operare in modo efficiente.

Aggiornamenti della configurazione delle VM

ad aggiornare la configurazione delle VM in un gruppo di istanze gestite (ad esempio il tipo di macchina o immagine disco di avvio), crei un nuovo modello di istanza con configurazione e quindi applicare il nuovo modello al gruppo di istanze gestite. Il gruppo di istanze gestite aggiorna VM utilizzando il metodo di aggiornamento scelto: automatico o selettivo. Scegli un metodo appropriato in base ai requisiti di disponibilità e dell'efficienza operativa. Per ulteriori informazioni su questi metodi di aggiornamento del gruppo di istanze gestite, consulta Applica nuove configurazioni di VM in un gruppo di istanze gestite.

Immagini VM

Per i modelli di istanza MIG, invece di utilizzare immagini pubbliche fornite da Google, ti consigliamo di creare e utilizzare immagini personalizzate che contengono configurazioni e il software richiesti dalle tue applicazioni. Puoi raggruppare i tuoi immagini personalizzate in una famiglia di immagini personalizzate. Una famiglia di immagini rimanda sempre un'immagine più recente della famiglia, in modo che i modelli e gli script di istanza possano utilizzare dell'immagine senza dover aggiornare i riferimenti a un'immagine specifica. completamente gestita.

Modelli di istanza deterministici

Se i modelli di istanza che utilizzi per i gruppi di istanze gestite includono script di avvio installare software di terze parti, accertarsi che gli script specifichino esplicitamente di installazione software, come la versione software. Altrimenti, 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 installa Apache HTTP Server 2.0 (il pacchetto apache2), quindi verifica che lo script specifica la versione esatta di apache2 da installare, ad esempio versione 2.4.53. Per ulteriori informazioni, vedi 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 come il database di origine, la dimensione dei dati, i vincoli di tempo di inattività e complessità del codice dell'applicazione. Per aiutarti a pianificare e implementare la migrazione a Spanner in modo efficiente, forniamo una gamma di Google Cloud e strumenti di terze parti. Per ulteriori informazioni, vedi Panoramica della migrazione.

Amministrazione di database

Con Spanner, non è necessario configurare o monitorare la replica o failover. La replica sincrona e il failover automatico sono integrati. Il tuo e non ha tempi di inattività per la manutenzione e il failover del database. A per ridurre ulteriormente la complessità operativa, scalabilità automatica. Se la scalabilità automatica è abilitata, non è necessario monitorare e scalare la dimensione dell'istanza manualmente.

Ulteriori considerazioni operative

Quando crei l'architettura per il carico di lavoro, considera la soluzione migliore in generale pratiche e raccomandazioni per l'efficienza operativa descritte in Framework dell'architettura Google Cloud: eccellenza operativa.

Ottimizzazione delle prestazioni

Questa sezione descrive i fattori da prendere in considerazione quando utilizzi questo di riferimento per progettare e creare una topologia globale di Google Cloud che soddisfa i requisiti di prestazioni dei tuoi carichi di lavoro.

Posizionamento VM

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

Tipi di VM

Compute Engine offre un'ampia gamma di tipi di macchina tra cui puoi scegliere in base ai tuoi costi e prestazioni i tuoi requisiti. I tipi di macchina 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 carichi di lavoro Famiglia di macchine per uso generico
Massime prestazioni per core e ottimizzate per attività ad alta intensità di calcolo carichi di lavoro 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 lo spazio di archiviazione

Per ulteriori informazioni, vedi 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 implementato come un singolo multithread hardware. Per impostazione predefinita, due vCPU condividono un core CPU fisico. Per carichi di lavoro altamente paralleli o che eseguono di calcoli in virgola mobile (come l'analisi della sequenza genetica e i il modello di rischio), puoi migliorare le prestazioni riducendo il numero di thread in esecuzione su ciascun core della CPU fisico. Per ulteriori informazioni, vedi Imposta il numero di thread per core.

Network Service Tiers

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

L'architettura in questo documento utilizza un bilanciatore del carico esterno globale con un e backend in più regioni. Questa architettura richiede a utilizzare il livello Premium, che usa la rete backbone globale altamente affidabile di Google per ridurre al minimo la perdita di pacchetti e la latenza.

Se utilizzi bilanciatori del carico esterni a livello di regione e instrada il traffico alle regioni tramite utilizzando Cloud DNS, puoi scegliere il livello Premium o Standard a seconda delle tue esigenze. Il prezzo per il livello Standard è inferiore a Livello Premium. Il livello Standard è adatto al traffico non sensibile a e che non presenti requisiti di bassa latenza.

Prestazioni Spanner

Quando esegui il provisioning di un'istanza Spanner, specifichi i criteri di computing della capacità dell'istanza in termini di numero di nodi o unità di elaborazione. Monitora l'utilizzo delle risorse dell'istanza Spanner e Scalare la capacità in base al carico previsto e alle prestazioni dell'applicazione i tuoi requisiti. Puoi scalare la capacità di un'istanza Spanner manualmente o automaticamente. Per ulteriori informazioni, vedi Panoramica della scalabilità automatica.

Con una configurazione multiregionale, Spanner replica i dati in modo sincrono tra più regioni. Questa replica consente una bassa latenza operazioni di lettura da più posizioni. Lo svantaggio è avere una latenza maggiore operazioni write, perché le repliche del quorum sono distribuite su più regioni. Per ridurre al minimo la latenza per le transazioni di lettura-scrittura in più regioni configurazione standard, Spanner utilizza percorso consapevole (attivata per impostazione predefinita).

Per suggerimenti su come ottimizzare le prestazioni di Spanner di Compute Engine, consulta la documentazione seguente:

Memorizzazione nella cache

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

Ulteriori considerazioni sulle prestazioni

Quando crei l'architettura per il carico di lavoro, considera la soluzione migliore in generale pratiche e consigli forniti in Framework dell'architettura Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: