Deployment a zona singola su Compute Engine

Last reviewed 2025-05-27 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione a più livelli che viene eseguita su VM Compute Engine in una singola zona di Google Cloud. Puoi utilizzare questa architettura di riferimento per eseguire l'hosting (lift and shift) in modo efficiente delle applicazioni on-premise nel cloud con modifiche minime alle applicazioni. Il documento descrive anche i fattori di progettazione da considerare quando crei un'architettura zonale per le tue applicazioni cloud. Il pubblico di destinazione di questo documento sono i cloud architect.

Architettura

Il seguente diagramma mostra un'architettura per un'applicazione che viene eseguita in una singola zona Google Cloud . Questa architettura è in linea con l'Google Cloud archetipo di deployment zonale.

Architettura a zona singola che utilizza Compute Engine.

L'architettura si basa sul modello cloud Infrastructure as a Service (IaaS). Esegui il provisioning delle risorse di infrastruttura richieste (calcolo, networking e archiviazione) in Google Cloud. Mantieni il controllo completo dell'infrastruttura e la responsabilità del sistema operativo, del middleware e dei livelli superiori dello 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 Finalità
Bilanciatore del carico esterno regionale

Il bilanciatore del carico esterno regionale riceve e distribuisce le richieste degli utenti alle VM del livello web.

Gruppo di istanze gestite (MIG) a livello di zona per il livello web Il livello web dell'applicazione viene eseguito il deployment su VM di Compute Engine che fanno parte di un MIG zonale. Il MIG è il backend per il bilanciatore del carico esterno regionale. Ogni VM nel MIG ospita un'istanza indipendente del livello web dell'applicazione.
Bilanciatore del carico interno regionale

Il bilanciatore del carico interno regionale distribuisce il traffico dalle VM del livello web alle VM del livello applicazione.

MIG a livello di zona per il livello applicazione Il livello applicazione viene eseguito il deployment sulle VM di Compute Engine che fanno parte di un MIG zonale, che è il backend del bilanciatore del carico interno. Ogni VM nel MIG ospita un'istanza indipendente del livello applicazione.
Database di terze parti di cui è stato eseguito il deployment su una VM di Compute Engine

L'architettura descritta in questo documento mostra un database di terze parti (come PostgreSQL) di cui è stato eseguito il deployment su una VM Compute Engine. Puoi eseguire il deployment di un database di standby in un'altra zona. Le funzionalità di replica e failover del database dipendono dal database utilizzato.

L'installazione e la gestione di un database di terze parti comportano un impegno e un costo operativo aggiuntivi per l'applicazione di aggiornamenti, il monitoraggio e la garanzia di disponibilità. Puoi evitare il sovraccarico di installazione e gestione di un database di terze parti e sfruttare le funzionalità di alta disponibilità (HA) integrate utilizzando un servizio di database completamente gestito come Cloud SQL o AlloyDB per PostgreSQL. Per ulteriori informazioni sulle opzioni di database gestito, consulta Servizi di database.

Rete Virtual Private Cloud e subnet

Tutte le risorse Google Cloud dell'architettura utilizzano una singola rete VPC e subnet.

A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC o più subnet. Per maggiori informazioni, consulta Decidere se creare più reti VPC.

Bucket regionale Cloud Storage

I backup di applicazioni e database vengono archiviati in un bucket Cloud Storage regionale. Se si verifica un'interruzione del servizio in una zona, l'applicazione e i dati non vengono persi.

In alternativa, puoi utilizzare il servizio di backup e DR per creare, archiviare e gestire i backup del database.

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.
  • Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud carichi di lavoro. VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e VPC condiviso.

Casi d'uso

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

  • Sviluppo e test nel cloud: puoi utilizzare un'architettura di deployment a zona singola per creare un ambiente cloud a basso costo per lo sviluppo e il test.
  • Applicazioni che non richiedono HA: un'architettura a zona singola potrebbe essere sufficiente per le applicazioni che possono tollerare tempi di inattività dovuti a interruzioni dell'infrastruttura.
  • Networking a bassa latenza e a basso costo tra i componenti dell'applicazione: un'architettura a zona singola potrebbe essere adatta ad applicazioni come il batch computing che richiedono connessioni di rete a bassa latenza e larghezza di banda elevata tra i nodi di calcolo. Con un deployment a zona singola, non c'è traffico di rete tra zone e non vengono addebitati costi per il traffico all'interno della zona.
  • Migrazione dei carichi di lavoro di base: l'architettura di deployment zonale fornisce un percorso di migrazione al cloud per le applicazioni on-premise di base per le quali non hai il controllo del codice o che non possono supportare architetture oltre una topologia attiva-passiva di base.
  • Esecuzione di software con licenza limitata: un'architettura a zona singola potrebbe essere adatta a sistemi con licenza limitata in cui l'esecuzione di più istanze contemporaneamente è troppo costosa o non è consentita.

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 progettazione del sistema, sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Quando crei l'architettura per il tuo carico di lavoro, tieni in considerazione le best practice e i suggerimenti del Google Cloud framework Well-Architected.

Progettazione del sistema

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

Selezione delle regioni

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

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

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

Infrastruttura di calcolo

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

  • Container: puoi eseguire applicazioni containerizzate 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.
  • Serverless: se preferisci concentrare i tuoi sforzi IT su dati e applicazioni anziché configurare e gestire risorse dell'infrastruttura, puoi utilizzare servizi serverless come Cloud Run.

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

Servizi di archiviazione

L'architettura mostrata in questo documento utilizza volumi Persistent Disk zonali per tutti i livelli. Per un'archiviazione permanente più durevole, puoi utilizzare i volumiPersistent Diski regionali, che forniscono la replica sincrona dei dati tra due zone all'interno di una regione.

Per un'archiviazione a basso costo ridondante nelle zone di una regione, puoi utilizzare i bucket regionali Cloud Storage.

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

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

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

Servizi di database

L'architettura di riferimento in questo documento utilizza un database di terze parti di cui è stato eseguito il deployment su VM di Compute Engine. L'installazione e la gestione di un database di terze parti comportano impegno e costi per operazioni come l'applicazione di aggiornamenti, il monitoraggio e la garanzia di disponibilità, l'esecuzione di backup e il ripristino in caso di errori.

Puoi evitare l'impegno e i costi di installazione e 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 Google Cloud servizi di database forniscono accordi sul livello del servizio (SLA) per il tempo di attività e includono funzionalità predefinite per la scalabilità e l'osservabilità.

Se il tuo carico di lavoro richiede un database Oracle, puoi eseguire il deployment del database su una VM Compute Engine o utilizzare Oracle Database@Google Cloud. Per saperne di più, vedi Carichi di lavoro Oracle in Google Cloud.

Sicurezza, privacy e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia zonale inGoogle Cloud che soddisfi i requisiti di sicurezza e conformità dei tuoi carichi di lavoro.

Protezione contro le minacce esterne

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

Accesso esterno per le VM

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

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

Privilegi del service account

Per le VM Compute Engine nell'architettura, anziché utilizzare i service account predefiniti, ti consigliamo di creare service account dedicati e specificare le risorse a cui il account di servizio può accedere. Il account di servizio predefinito include un'ampia gamma di autorizzazioni non necessarie in questo caso, mentre puoi personalizzare i service account dedicati in modo che abbiano solo le autorizzazioni necessarie. Per saperne di più, consulta Limitare i account di servizio account.

Sicurezza SSH

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

Sicurezza della rete

Per controllare il traffico di rete tra le risorse nell'architettura, devi configurare criteri Cloud Next Generation Firewall (NGFW) appropriati.

Ogni regola firewall ti consente di controllare il traffico in base a parametri come protocollo, indirizzo IP e porta. Ad esempio, puoi configurare una regola firewall per consentire il traffico TCP dalle VM del server web a una porta specifica delle VM del database e bloccare tutto il resto del traffico.

Altre considerazioni sulla sicurezza

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

Affidabilità

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

Robustezza contro le interruzioni dell'infrastruttura

In un'architettura di deployment a zona singola, se un componente dello stack dell'infrastruttura non funziona, l'applicazione può elaborare le richieste se ogni livello contiene almeno un componente funzionante con capacità adeguata. Ad esempio, se un'istanza del server web non funziona, il bilanciatore del carico inoltra le richieste degli utenti alle altre istanze del server web disponibili. Se una VM che ospita un server web o un'istanza del server app si arresta in modo anomalo, il MIG ricrea automaticamente la VM. Se il database si arresta in modo anomalo, devi attivare manualmente il secondo database e aggiornare le istanze del server delle app per connetterti al database.

Un'interruzione della zona o della regione influisce su tutte le VM Compute Engine in un deployment a zona singola. Un'interruzione del servizio a livello di zona non influisce sul bilanciatore del carico in questa architettura perché è unarisorsa di regionee. Tuttavia, il bilanciatore del carico non può distribuire il traffico perché non sono disponibili backend. Se si verifica un'interruzione di una zona o di una regione, devi attendere che Google risolva l'interruzione, quindi verificare che l'applicazione funzioni come previsto.

Puoi ridurre il tempo di inattività causato da interruzioni di zona o regione mantenendo una replica passiva (di failover) dello stack dell'infrastruttura in un'altra zona o regioneGoogle Cloud . Se si verifica un'interruzione nella zona principale, puoi attivare lo stack nella zona o nella regione di failover e utilizzare un criterio di routing DNS per indirizzare il traffico al bilanciatore del carico nella zona o nella regione di failover.

Per le applicazioni che richiedono robustezza contro le interruzioni di zona o regione, valuta la possibilità di utilizzare un'architettura regionale o multiregionale. Consulta le seguenti architetture di riferimento:

Scalabilità automatica del gruppo di istanze gestite

La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente di mantenere la disponibilità e le prestazioni delle applicazioni a livelli prevedibili.

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

Limite di dimensioni del MIG

Quando decidi le dimensioni dei tuoi MIG, considera i limiti predefiniti e massimi al numero di VM che possono essere create in un MIG. Per ulteriori informazioni, vedi Aggiungere e rimuovere VM da un gruppo di istanze gestite.

Riparazione automatica delle VM

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

Posizionamento delle VM

Nell'architettura descritta in questo documento, il livello applicazione e il livello web vengono eseguiti su VM Compute Engine all'interno di una singola zona.

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

Pianificazione della capacità delle VM

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

Archiviazione stateful

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

Durabilità dei dati

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

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

Disponibilità del database

Se utilizzi un servizio di database gestito come Cloud SQL nella configurazione HA, in caso di errore del database primario, Cloud SQL esegue automaticamente il failover sul database di standby. Non devi modificare l'indirizzo IP per l'endpoint del database. Se utilizzi un database di terze parti autogestito che viene implementato su una VM Compute Engine, devi utilizzare un bilanciatore del carico interno o un altro meccanismo per garantire che l'applicazione possa connettersi a un altro database se il database principale non è disponibile.

Per implementare il failover tra zone per un database di cui è stato eseguito il deployment su una VM Compute Engine, devi disporre di un meccanismo per identificare gli errori del database primario e di un processo per eseguire il failover al database di standby. I dettagli del meccanismo di failover dipendono dal database che utilizzi. Puoi configurare un'istanza osservatore per rilevare gli errori del database principale e orchestrare il failover. Devi configurare le regole di failover in modo appropriato per evitare una situazione di split-brain e impedire failover non necessari. Per esempi di architetture che puoi utilizzare per implementare il failover per i database PostgreSQL, consulta Architetture per l'alta affidabilità dei cluster PostgreSQL su Compute Engine.

Ulteriori considerazioni sull'affidabilità

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

Ottimizzazione dei costi

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

Tipi di macchine VM

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

Modello di provisioning delle VM

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

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

Utilizzo delle risorse della VM

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

Licenze di terze parti

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

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

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

Altre considerazioni sui costi

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

Efficienza operativa

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

Aggiornamenti della configurazione delle VM

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

Immagini VM

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

Modelli di istanza deterministici

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

Ulteriori considerazioni operative

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

Ottimizzazione delle prestazioni

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

Rendimento del calcolo

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

Multi-threading della VM

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

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

Network Service Tiers

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

Prestazioni di rete

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

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

Altre considerazioni sul rendimento

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

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori: