Deployment multiregionale su Compute Engine

Last reviewed 2024-02-20 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione a più livelli che viene eseguita su VM Compute Engine in più regioni di Google Cloud. La fornisce anche indicazioni per aiutarti a creare un'architettura che utilizza da altri servizi dell'infrastruttura Google Cloud. Descrive i fattori di progettazione devi considerare quando crei un'architettura multiregionale per il tuo cloud diverse applicazioni. Il pubblico di destinazione di questo documento sono gli architetti cloud.

Architettura

Figura 1 mostra un'architettura per un'applicazione che viene eseguita in modalità stack isolati di cui viene eseguito il deployment in due regioni Google Cloud. In ogni regione, l'applicazione viene eseguita in modo indipendente in tre zone. L'architettura è in linea con archetipo di deployment multiregionale, per garantire che la tua topologia Google Cloud sia robusta contro zona a livello di regione e che offra bassa latenza agli utenti delle applicazioni.

Architettura multiregionale che utilizza un bilanciatore del carico globale

Figura 1. Un bilanciatore del carico globale instrada le richieste degli utenti a stack di applicazioni isolate a livello di regione.

L'architettura si basa sul modello cloud Infrastructure as a Service (IaaS). Esegui il provisioning delle risorse di infrastruttura necessarie (computing, networking, e archiviazione) in Google Cloud, oltre a mantenere il controllo completo su responsabile del sistema operativo, del middleware e dei livelli superiori e lo stack di applicazioni. Per saperne di più su IaaS e altri modelli cloud, consulta PaaS, IaaS, SaaS e CaaS: in che cosa differiscono?

Il diagramma precedente include i seguenti componenti:

Componente Purpose
Bilanciatore del carico esterno globale

Il bilanciatore del carico esterno globale riceve e distribuisce richieste all'applicazione. Il bilanciatore del carico esterno globale annunci un singolo indirizzo IP anycast, ma è implementato come un gran numero di proxy su Google Front End (GFE). Le richieste del cliente vengono indirizzate al servizio 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 proxy esterno globale. Per ulteriori informazioni, consulta Scegliere un bilanciatore del carico.
Gruppi di istanze gestite a livello di regione 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 MIG sono i backend per il bilanciatore del carico globale.

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

Il bilanciatore del carico interno in ogni regione distribuisce il traffico dalle VM del livello web alle VM del livello di applicazione nella regione in questione.

A seconda dei requisiti, puoi utilizzare un bilanciatore del carico delle applicazioni interno regionale o un bilanciatore del carico di rete. Per saperne di più, vedi Scegliere un bilanciatore del carico.
Gruppi di istanze gestite a livello di regione per il livello di applicazione

Il livello dell'applicazione viene disegnato su VM Compute Engine che fanno parte di MIG regionali. Il gruppo di istanze gestite in ogni regione è il backend per il bilanciatore del carico interno in quella regione.

Ogni MIG contiene VM di Compute Engine in tre zone diverse. Ogni VM ospita un'istanza indipendente dell'applicazione livello.
Database di terze parti con deployment eseguito su VM di Compute Engine

Viene eseguito il deployment di un database di terze parti (come PostgreSQL) di Compute Engine nelle due regioni. Puoi configurare la replica tra regioni per i database e configurare il database in ogni regione in modo che venga eseguito il failover al database nell'altra regione. Le funzionalità di replica e failover dipendono dal database utilizzato.

L'installazione e la gestione di un database di terze parti richiede ulteriori sforzi e i costi operativi di replica, applicazione di aggiornamenti, monitoraggio assicurando la disponibilità. Puoi evitare di sovraccaricare l'installazione e la gestione un database di terze parti e sfruttare l'alta disponibilità integrata di funzionalità usando un database completamente gestito come istanza Spanner multiregionale.
Virtual Private Cloud rete e subnet Tutte le risorse Google Cloud nell'architettura utilizzano un singolo una rete VPC con subnet in due diverse regioni.
Due regioni per Cloud Storage bucket I backup dei dati dell'applicazione vengono archiviati in bucket Cloud Storage con due regioni. In alternativa, puoi utilizzare il servizio di backup e RE per creare, archiviare e gestire i backup del database.

Casi d'uso

Questa sezione descrive i casi d'uso per i quali un deployment multiregionale su Compute Engine è una scelta appropriata.

Migrazione efficiente delle applicazioni on-premise

Puoi utilizzare questa architettura di riferimento per creare una topologia Google Cloud a Rehosting (lift and shift) le applicazioni on-premise al cloud con modifiche minime. Tutti i livelli dell'applicazione in questa architettura di riferimento sono ospitati su VM Compute Engine. Questo approccio ti consente di eseguire la migrazione delle applicazioni on-premise al cloud in modo efficiente e di sfruttare i vantaggi in termini di costi, affidabilità, prestazioni e semplicità operativa offerti da Google Cloud.

Disponibilità elevata per utenti con distribuzione geografica

Consigliamo un deployment multiregionale per le applicazioni business critical e dove siano disponibili alta disponibilità e robustezza rispetto alla regione e le interruzioni di servizio sono essenziali. Se una regione non è più disponibile per qualsiasi motivo (anche una un'interruzione su larga scala causata da una calamità naturale), gli utenti dell'applicazione non presenti tempi di inattività. Il traffico viene indirizzato all'applicazione nelle altre regioni disponibili. Se i dati vengono replicati in modo sincrono, il tempo di ripristino dell'obiettivo (RTO) è vicino allo zero.

Bassa latenza per gli utenti delle applicazioni

Se i tuoi utenti si trovano in un'area geografica specifica, ad esempio un continente, puoi utilizzare un deployment multiregionale per ottenere un equilibrio ottimale tra disponibilità e prestazioni. Quando in una delle regioni si verifica un'interruzione del servizio, il bilanciatore del carico globale invia le richieste che hanno origine in quella regione a un'altra regione. Gli utenti non percepiscono un impatto significativo sul rendimento perché le regioni si trovano all'interno di un'area geografica.

Design alternativo

Un'architettura che utilizza un bilanciatore del carico globale (figura 1) supporta determinate funzionalità che ti aiutano a migliorare l'affidabilità dei tuoi deployment, ad esempio la memorizzazione nella cache perimetrale utilizzando Cloud CDN. Questa sezione presenta un'architettura alternativa che utilizza il carico a livello di regione e Cloud DNS, come illustrato in figura 2. Questa architettura alternativa supporta le seguenti funzionalità aggiuntive:

  • Terminazione Transport Layer Security (TLS) in regioni specifiche.
  • Possibilità di pubblicare contenuti dalla regione specificata. Tuttavia, questa regione potrebbe non essere quella con il rendimento migliore in un determinato momento.
  • Una gamma più ampia di protocolli di connessione se utilizzi un bilanciatore del carico di rete passthrough.

Per saperne di più sulle differenze tra il carico a livello di regione e quello globale bilanciatori del carico, consulta la documentazione seguente:

Architettura multiregionale che utilizza bilanciatori del carico e DNS a livello di regione.

Figura 2. Cloud DNS instrada le richieste utente a bilanciatori del carico a livello di regione.

Come quella nella figura 1, quella nella figura 2 è robusta contro le interruzioni di zone e regioni. R Cloud DNS la zona pubblica instrada le richieste dell'utente alla regione appropriata. Esterno regionale I bilanciatori del carico ricevono le richieste degli utenti e le distribuiscono sul livello web dell'applicazione all'interno di ogni regione. Gli altri componenti di questo sono identici ai componenti architettura globale basata su bilanciatore del carico.

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à, efficienza operativa, costi delle prestazioni.

Progettazione del sistema

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

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 maggiori informazioni le informazioni, vedi Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchine Compute Engine in ogni regione. Per ulteriori informazioni, vedi Regioni e zone.
  • Requisiti di latenza dell'utente finale
  • Costo delle risorse Google Cloud
  • Costi di trasferimento di dati tra regioni
  • Requisiti normativi

Alcuni di questi fattori e requisiti potrebbero comportare dei 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 tutti i livelli dell'applicazione. In base ai requisiti del tuo 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 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 uno sforzo 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

Le architetture mostrate in questo documento utilizzano volumi di dischi permanenti regionali per tutti i livelli. I dischi permanenti forniscono la replica sincrona dei dati tra due zone all'interno di una regione.

Altre opzioni di archiviazione per i deployment multiregionali includono: Bucket a due o più regioni di Cloud Storage. Gli oggetti archiviati in un a due o più regioni sono 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 due regioni, puoi utilizzare la replica turbo, che garantisce la replica degli oggetti tra coppie di regioni, con un RPO (Recovery Point Objective) di 15 minuti. Per ulteriori informazioni, vedi Disponibilità e durabilità dei dati.

Per archiviare i dati condivisi su più VM in una regione, ad esempio su tutte le VM nel livello web o nel livello di applicazione, puoi utilizzare un'istanza Filestore Enterprise. I dati 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 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.

Se il tuo database è Microsoft SQL Server, puoi eseguire il deployment istanza cluster di failover (FCI) e utilizzare lo strumento Google Cloud NetApp Volumes per fornire archiviazione SMB a disponibilità continua (CA) per il database.

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 un database di terze parti, come PostgreSQL di cui è stato eseguito il deployment sulle VM di Compute Engine. L'installazione e la gestione di un database di terze parti richiedono impegno e costi per operazioni come l'applicazione di aggiornamenti, il monitoraggio e la garanzia della disponibilità, l'esecuzione di backup e il recupero da errori.

Puoi evitare lo sforzo e il costo dell'installazione e della gestione di un database di terze parti utilizzando un servizio di database completamente gestito come Cloud SQL, AlloyDB per PostgreSQL, Bigtable, Spanner o Firestore. Questi servizi di database Google Cloud forniscono contratti di livello del servizio (SLA) per il tempo di attività e includono funzionalità predefinite per la scalabilità e l'osservabilità. Se i tuoi carichi di lavoro richiedono un database Oracle, puoi utilizzare Soluzione Bare Metal offerti da Google Cloud, Per una panoramica dei casi d'uso per i quali è adatto ciascun servizio di database Google Cloud, consulta Database Google Cloud.

Quando scegli e configuri il database per un deployment multiregionale, tieni conto dei requisiti della tua applicazione per la coerenza dei dati tra regioni e tieni presente i compromessi tra prestazioni e costi.

  • Se l'applicazione richiede elevata coerenza (tutti gli utenti devono leggere gli stessi dati sempre), i dati devono essere replicati in modo sincrono in tutte le regioni dell'architettura. Tuttavia, la replica sincrona può portare a costi più alti e a una riduzione del rendimento, perché i dati devono essere replicati in tempo reale tra le regioni prima che i dati è disponibile per le operazioni di lettura.
  • Se la tua applicazione può tollerare la coerenza finale, puoi riprodurre i dati in modo asincrono. Ciò può contribuire a migliorare il rendimento perché non è necessario replicare i dati in modo sincrono tra le regioni. Tuttavia, gli utenti in regioni diverse potrebbero leggere dati diversi perché i dati potrebbero non essere stati completamente replicati al momento della richiesta.

Sicurezza e conformità

Questa sezione descrive i fattori da prendere in considerazione quando utilizzi questo di riferimento per progettare e creare una topologia multiregionale 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 Distributed Denial of Service (DDoS) e cross-site scripting (XSS), puoi utilizzare Google Cloud Armor criteri di sicurezza. Ogni criterio è un insieme di regole che specifica condizioni che devono essere valutate e le azioni da intraprendere quando le condizioni sono sono soddisfatte determinate condizioni. Ad esempio, una regola potrebbe specificare che, se l'IP di origine del traffico in entrata corrisponde a un indirizzo IP o a un intervallo CIDR specifici, il traffico negata. Inoltre, puoi applicare un web application firewall (WAF) preconfigurato le regole del caso. 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, il livello web e i database non richiedono l'accesso in entrata da 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 maggiori 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 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 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. All'account di servizio predefinito viene concesso l'accesso all'Editor ruolo IAM (roles/editor), a meno che non si tratti di il comportamento è 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, vedi Limitare i privilegi degli account di servizio in "Best practice per l'utilizzo di account di servizio".

Considerazioni sulla residenza dei dati

Puoi usare bilanciatori del carico a livello di regione per creare un'architettura multiregionale ti aiuta a soddisfare i requisiti di residenza dei dati. Ad esempio, un paese in Europa potrebbe richiedere l'archiviazione e l'accesso a tutti i dati utente nei data center che si trovano fisicamente in Europa. Per soddisfare questo requisito, puoi utilizzare l'architettura basata su bilanciatori del carico regionali riportata nella Figura 2. In questa architettura, l'applicazione viene eseguita nelle regioni Google Cloud in Europa e utilizzi Cloud DNS con un criterio di routing con recinto virtuale per instradare il traffico tramite i bilanciatori del carico regionali. Per soddisfare la residenza dei dati in base ai requisiti per il livello di database, utilizza suddiviso anziché replicare tra regioni diverse. Con questo approccio, i dati in ogni regione è isolata, ma non è possibile implementare un valore la disponibilità e il failover per il database.

Altre considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, tieni conto delle best practice e dei consigli per la sicurezza a livello di piattaforma forniti nel blueprint Security Foundations.

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 deployment multiregionali 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 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 la scalabilità automatica il comportamento dei MIG stateless, puoi specificare le metriche di utilizzo target, come l'utilizzo medio della CPU. Puoi anche configurare per i MIG stateless. 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 esserci problemi con l'applicazione stessa. Potrebbe bloccarsi, arrestarsi in modo anomalo o se non hai 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 sulla configurazione della riparazione automatica, consulta Configurare un controllo di integrità e la riparazione automatica dell'applicazione.

Posizionamento 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, puoi creare prenotazioni. Una prenotazione offre capacità garantita in una zona specifica per un numero specifico di VM di un tipo di macchina scegliere. Una prenotazione può essere specifica per un progetto o condivisa tra più in modo programmatico a gestire i progetti. Per ulteriori informazioni sulle prenotazioni, inclusa la fatturazione considerazioni, vedi Prenotazioni delle risorse di zona Compute Engine.

Stato del disco permanente

Una best practice nella progettazione di applicazioni è evitare la necessità di dischi locali stateful. Ma se il requisito esiste, puoi configurare i tuoi dischi permanenti essere stateful per garantire che i dati vengano conservati anche durante la riparazione delle VM viene ricreato. 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 Backup e DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Il servizio 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.

Per archiviare i backup del database e i log delle transazioni, puoi utilizzare i bucket Cloud Storage regionali, che forniscono spazio di archiviazione di backup a basso costo e ridondante tra le zone.

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

  • Puoi utilizzare la modalità snapshot standard per acquisire lo stato point-in-time dei volumi Persistent Disk. La gli snapshot sono 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 puoi risparmiare. Gli snapshot vengono archiviati in una posizione 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 consente di eseguire applicazioni a disponibilità elevata non 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 sui dischi di entrambe le zone. Se una delle due zone presenta un'interruzione, i dati rimangono disponibili.

Disponibilità database

Per implementare il failover tra zone per il database in ogni regione, è necessaria una meccanismo per identificare gli errori del database primario e un processo di errore al database in standby. Le specifiche del meccanismo di failover dipendono dal database utilizzato. Puoi configurare un'istanza di osservatore per rilevare i guasti del database principale e orchestrare il failover. Devi e configurare opportunamente le regole di failover per evitare cervello diviso della situazione ed evitare failover non necessari. Ad esempio, le architetture che puoi utilizzare per implementare il failover per i database PostgreSQL, Architetture per l'alta disponibilità di cluster PostgreSQL su Compute Engine.

Altre 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 il costo della configurazione e del funzionamento di una topologia Google Cloud multiregionale creata utilizzando questa architettura di riferimento.

Tipi di VM

Per aiutarti a ottimizzare l'utilizzo delle risorse delle tue istanze VM, Compute Engine fornisce suggerimenti sul tipo di macchina. Utilizza i suggerimenti per scegliere i tipi di 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 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 i job batch che possono tollerare la preemption e non hanno requisiti di alta disponibilità. Le VM spot offrono gli stessi tipi di macchina, le 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

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.

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. 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 delle 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 necessari.
  • 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 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 considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia Google Cloud multiregionale che puoi gestire in modo efficiente.

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), 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 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, quindi 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 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 installare Apache HTTP Server 2.0 (il pacchetto apache2), assicurati che lo script specifichi la versione esatta di apache2 da installare, ad esempio la versione 2.4.53. Per ulteriori informazioni, vedi Modelli di istanza deterministici.

Altre 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 considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia multiregionale in Google Cloud che soddisfi i requisiti di prestazioni dei tuoi carichi di lavoro.

Posizionamento 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 del gruppo di istanze gestite. Quando il gruppo di istanze gestite crea le VM, le posiziona a 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 e per diversi tipi di carichi di lavoro:

Requisito Famiglia di macchine consigliata Serie di macchine di esempio
Miglior rapporto prezzo/prestazioni per diversi carichi di lavoro Famiglia di macchine per uso generico C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
Massime prestazioni per core e ottimizzazione per carichi di lavoro ad alta intensità di calcolo Famiglia di macchine ottimizzate per il calcolo C2, C2D, H3
Rapporto memoria-vCPU elevato per carichi di lavoro che richiedono molta memoria Famiglia di macchine ottimizzate per la memoria M3, M2, M1
GPU per carichi di lavoro parallelizzati in modo massiccio Famiglia di macchine ottimizzate per l'acceleratore A2, G2

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 CPU fisico. Per i carichi di lavoro altamente paralleli o che eseguono calcoli in virgola mobile (come 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, vedi Imposta il numero di thread per core.

Network Service Tiers

Network Service Tiers ti consente di ottimizzare costi e prestazioni di rete carichi di lavoro con scale out impegnativi. Puoi scegliere tra i seguenti livelli:

  • Il livello Premium utilizza la struttura backbone globale altamente affidabile di Google per aiutarti a ottenere una perdita di pacchetti e una latenza minime. Il traffico entra ed esce dalla la rete Google presso un POP perimetrale più vicino alla rete all'ISP dell'utente finale. Per ottenere prestazioni ottimali, consigliamo di utilizzare il livello Premium come livello predefinito. Il livello Premium supporta sia gli indirizzi IP esterni regionali sia gli indirizzi IP esterni globali per VM e bilanciatori del carico.
  • Il livello Standard è disponibile solo per le risorse che utilizzano indirizzi IP esterni regionali. Il traffico entra ed esce dalla rete Google in un PoP di confine più vicino alla regione in cui viene eseguito il tuo carico di lavoro Google Cloud. Il prezzo del livello Standard è inferiore a quello del livello Premium. Il livello Standard è adatto per il traffico non sensibile alla perdita di pacchetti e che non ha requisiti di latenza ridotta.

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 (come mostrato nella Figura 1), puoi utilizzare Cloud CDN per memorizzare nella cache i contenuti statici a cui si accede regolarmente più vicino agli utenti. Cloud CDN può aiutare a migliorare le prestazioni gli utenti, l'utilizzo delle risorse dell'infrastruttura nel backend e la riduzione per i costi di distribuzione della rete. Per ulteriori 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, 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: