Deployment regionale su Compute Engine

Last reviewed 2024-11-14 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione a più livelli che viene eseguita su VM Compute Engine in più zone all'interno di una regione Google Cloud. Puoi utilizzare questa architettura di riferimento per eseguire il rehosting (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 prendere in considerazione quando crei un'architettura regionale per le tue applicazioni cloud. Il pubblico di destinazione di questo documento è costituito dagli architetti cloud.

Architettura

Il seguente diagramma mostra un'architettura per un'applicazione che viene eseguita in modalità attiva-attiva in stack isolati di cui è stato eseguito il deployment in tre zone Google Cloud all'interno di una regione. L'architettura è in linea con l'archetipo di implementazione regionale, che garantisce che la topologia di Google Cloud sia solida contro le interruzioni della zona.

Un'applicazione viene eseguita in modalità active-active in stack isolati di cui è stato eseguito il deployment in tre zone Google Cloud all'interno di una regione.

L'architettura si basa sul modello cloud Infrastructure as a Service (IaaS). Esegui il provisioning delle risorse di infrastruttura richieste (computing, networking e archiviazione) in Google Cloud. Mantieni il pieno controllo sull'infrastruttura e la responsabilità del sistema operativo, del middleware e dei livelli superiori dello stack di applicazioni. Per saperne di più su IaaS e su 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.

Utilizza un tipo di bilanciatore del carico appropriato a seconda del tipo di traffico e di altri requisiti. Ad esempio, se il backend è costituito da server web (come mostrato nell'architettura precedente), utilizza un bilanciatore del carico delle applicazioni per inoltrare il traffico HTTP(S). Per bilanciare il carico del traffico TCP, utilizza un bilanciatore del carico di rete. Per ulteriori informazioni, consulta Scegliere un bilanciatore del carico.

Gruppo di istanze gestite ( MIG) per il livello web a livello regionale

Il livello web dell'applicazione viene disegnato su VM Compute Engine che fanno parte di un gruppo di istanze gestite regionale. Il gruppo di istanze gestite è il backend per il bilanciatore del carico esterno regionale.

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

Bilanciatore del carico interno regionale

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

A seconda dei requisiti, puoi utilizzare un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete interno regionale. Per ulteriori informazioni, consulta la sezione Scegliere un bilanciatore del carico.

Gruppo di istanze gestite a livello di regione per il livello dell'applicazione

Il livello dell'applicazione viene di cui è stato eseguito il deployment su VM Compute Engine che fanno parte di un gruppo di istanze gestite regionale, che è il backend per il bilanciatore del carico interno.

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

Database di terze parti di cui è stato eseguito il deployment su una VM Compute Engine

L'architettura 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 degli aggiornamenti, il monitoraggio e la garanzia della disponibilità. Puoi evitare il sovraccarico di installare e gestire 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 gestite, consulta Servizi di database più avanti in questa guida.

Rete Virtual Private Cloud e subnet

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

A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC o più subnet. Per ulteriori informazioni, consulta Decidere se creare più reti VPC in "Best practice e architetture di riferimento per la progettazione di VPC".

Bucket Cloud Storage a due regioni

I backup di applicazioni e database vengono archiviati in un bucket Cloud Storage con due regioni. Se si verifica un'interruzione in una zona o una regione, l'applicazione e i dati non andranno persi.

In alternativa, puoi utilizzare il servizio di backup e RE 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 Cloud e vengono replicati in più località per garantire la ridondanza.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di networking scalabili e globali per i carichi di lavoro Google Cloud. 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 regionale su Compute Engine è una scelta appropriata.

Migrazione efficiente delle applicazioni on-premise

Puoi utilizzare questa architettura di riferimento per creare una topologia Google Cloud per eseguire il rehosting (lift and shift) delle applicazioni on-premise nel cloud con modifiche minime alle applicazioni. 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 in modo efficiente al cloud e di sfruttare i vantaggi in termini di costi, affidabilità, prestazioni e semplicità operativa offerti da Google Cloud.

Applicazione ad alta disponibilità con utenti all'interno di un'area geografica

Consigliamo un'architettura di deployment regionale per le applicazioni che richiedono robustezza contro le interruzioni del servizio nelle zone, ma che possono tollerare un certo tempo di riposo causato da interruzioni del servizio nelle regioni. Se una parte dello stack dell'applicazione non va a buon fine, l'applicazione continua a essere eseguita se in ogni livello esiste almeno un componente funzionante con una capacità adeguata. Se si verifica un'interruzione del servizio in una zona, lo stack delle applicazioni continua a funzionare nelle altre zone.

Bassa latenza per gli utenti dell'applicazione

Se tutti gli utenti di un'applicazione si trovano in un'unica area geografica, ad esempio un singolo paese, un'architettura di implementazione regionale può contribuire a migliorare il rendimento percepito dall'utente dell'applicazione. Puoi ottimizzare la latenza della rete per le richieste degli utenti eseguendo il deployment dell'applicazione nella regione Google Cloud più vicina agli utenti.

Networking a bassa latenza tra i componenti dell'applicazione

Un'architettura a singola regione potrebbe essere adatta per applicazioni come il calcolo batch che richiedono connessioni di rete a bassa latenza e ad alta larghezza di banda tra i nodi di calcolo. Tutte le risorse si trovano in un'unica regione Google Cloud, pertanto il traffico di rete tra risorse rimane all'interno della regione. La latenza di rete tra le risorse è bassa e non devi sostenere costi di trasferimento dei dati tra regioni. Si applicano comunque i costi di rete all'interno della regione.

Conformità ai requisiti di residenza dei dati

Puoi utilizzare un'architettura a una sola regione per creare una topologia che ti aiuti a soddisfare i requisiti di residenza dei dati. Ad esempio, un paese europeo potrebbe richiedere che tutti i dati utente vengano archiviati e a cui si acceda in data center situati fisicamente all'interno dell'Europa. Per soddisfare questo requisito, puoi eseguire l'applicazione in una regione Google Cloud in Europa.

Note sul layout

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

Progettazione del sistema

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

Selezione delle regioni

Quando scegli una regione Google Cloud per le tue applicazioni, prendi in considerazione i seguenti fattori e requisiti:

  • Disponibilità dei servizi Google Cloud. Per ulteriori informazioni, consulta Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchine Compute Engine. Per maggiori informazioni, consulta Regioni e zone.
  • Requisiti di latenza per l'utente finale.
  • Costo delle risorse Google Cloud.
  • Requisiti normativi.

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

Servizi di calcolo

L'architettura di riferimento in questo documento utilizza le VM Compute Engine per tutti i livelli dell'applicazione. Le indicazioni di progettazione riportate in questo documento sono specifiche per Compute Engine, se non diversamente indicato.

A seconda dei requisiti della tua applicazione, puoi scegliere tra i seguenti altri servizi di calcolo Google Cloud. Le indicazioni di progettazione per questi servizi non rientrano nell'ambito di questo documento.

  • Puoi eseguire applicazioni containerizzate nei cluster Google Kubernetes Engine (GKE). GKE è un motore di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate.
  • Se preferisci concentrare le risorse IT sui dati e sulle applicazioni anziché sulla configurazione e sul funzionamento delle risorse di infrastruttura, puoi utilizzare servizi serverless come Cloud Run e funzioni Cloud Run.

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

Servizi di archiviazione

L'architettura mostrata in questo documento utilizza volumi di Persistent Disk regionali per tutti i livelli. I dischi permanenti forniscono la replica sincrona dei dati tra due zone all'interno di una regione.

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

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 HA e robustezza contro le interruzioni delle zone. Puoi archiviare file di configurazione condivisi, strumenti e utilità comuni e log centralizzati nell'istanza Filestore e montare l'istanza su più VM.

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 requisiti di configurazione o se hai bisogno di accedere al sistema operativo, puoi eseguire il deployment di un'istanza del cluster di failover (FCI). In questo scenario, puoi utilizzare Google Cloud NetApp Volumes completamente gestito per fornire spazio di archiviazione SMB con disponibilità continua (CA) per il database.

Quando progetti lo spazio di archiviazione per i tuoi workload regionali, tieni conto delle caratteristiche funzionali dei workload, dei requisiti di resilienza, delle aspettative relative alle prestazioni e degli obiettivi di costo. Per ulteriori informazioni, consulta Progettare una strategia di archiviazione ottimale per il carico di lavoro cloud.

Servizi di database

L'architettura di riferimento in questo documento utilizza un database di terze parti, come PostgreSQL, di cui è stato eseguito il deployment sulle VM 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 Bare Metal Solution fornita da Google Cloud. Per una panoramica dei casi d'uso per i quali è adatto ciascun servizio di database Google Cloud, consulta Database Google Cloud.

Sicurezza e conformità

Questa sezione descrive i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia regionale in Google 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 esterne come gli attacchi DDoS (Distributed Denial of Service) e il cross-site scripting (XSS), puoi utilizzare i criteri di sicurezza di Google Cloud Armor. I criteri di sicurezza vengono applicati sul perimetro, ovvero prima che il traffico raggiunga il livello web. Ogni criterio è un insieme di regole che specificano determinate condizioni da valutare e le azioni da eseguire 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. Inoltre, puoi applicare regole del web application firewall (WAF) preconfigurate. Per ulteriori informazioni, consulta la Panoramica delle norme sulla sicurezza.

Accesso esterno per le VM

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

Per abilitare connessioni in uscita sicure dalle risorse Google Cloud che hanno solo indirizzi IP interni, come le VM Compute Engine in questa architettura 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 maggiori informazioni, consulta Configurare i criteri per l'utilizzo di immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui è abilitata l'API Compute Engine, viene creato automaticamente un account di servizio predefinito. All'account di servizio predefinito viene concesso il ruolo IAM Editor (roles/editor), a meno che questo comportamento non sia disattivato. Per impostazione predefinita, l'account di servizio predefinito è associato a tutte le VM create utilizzando Google Cloud CLI o la console Google Cloud. Il ruolo Editor include una vasta gamma di autorizzazioni, pertanto l'associazione dell'account di servizio predefinito alle VM rappresenta un rischio per la sicurezza. Per evitare questo rischio, puoi creare e utilizzare account di servizio dedicati per ogni applicazione. Per specificare le risorse a cui può accedere l'account di servizio, utilizza i criteri granulari. Per ulteriori informazioni, consulta Limitare i privilegi degli account di servizio in "Best practice per l'utilizzo degli account di servizio".

Sicurezza della rete

Per controllare il traffico di rete tra le risorse dell'architettura, devi configurare le regole di Cloud Next Generation Firewall appropriate. 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 carico di lavoro, prendi in considerazione le best practice e i consigli per la sicurezza a livello di piattaforma forniti nel blueprint Security Foundation.

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 implementazioni a livello di regione in Google Cloud.

Mancate disponibilità dell'infrastruttura

In un'architettura regionale, se un singolo componente dello stack dell'infrastruttura non funziona, l'applicazione può elaborare le richieste se in ogni livello esiste 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'istanza di server web o server app si arresta in modo anomalo, il gruppo di istanze gestite la ricrea automaticamente.

Se si verifica un'interruzione nella zona, il bilanciatore del carico non è interessato, in quanto si tratta di una risorsa di regione. Un'interruzione del servizio in una zona potrebbe interessare singole VM Compute Engine. Tuttavia, l'applicazione rimane disponibile e reattiva perché le VM si trovano in un gruppo di istanze gestite regionale. Un gruppo di istanze gestite regionale garantisce la creazione automatica di nuove VM per mantenere il numero minimo di VM configurato. Dopo che Google ha risolto l'interruzione del servizio nella zona, devi verificare che l'applicazione funzioni come previsto in tutte le zone in cui è implementata.

Se si verifica un'interruzione di tutte le zone di questa architettura o se si verifica un'interruzione di una regione, l'applicazione non è disponibile. Devi attendere che Google risolva l'interruzione e poi verificare che l'applicazione funzioni come previsto.

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

Per le applicazioni che richiedono robustezza contro le interruzioni regionali, valuta la possibilità di utilizzare un'architettura multiregionale. Per ulteriori informazioni, consulta Deployment multiregionale su Compute Engine.

Scalabilità automatica del gruppo di istanze gestite

Quando esegui l'applicazione su VM in un gruppo di istanze gestite regionale, l'applicazione rimane disponibile durante le interruzioni isolate delle zone. La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente di mantenere la disponibilità e le prestazioni delle applicazioni a livelli prevedibili. I gruppi di istanze gestite stateful non possono essere sottoposti a ridimensionamento automatico.

Per controllare il comportamento della scalabilità automatica dei tuoi MIG, puoi specificare le metriche di utilizzo target, ad esempio l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica in base alla pianificazione. Per ulteriori informazioni, consulta Gruppi di istanze a scalabilità automatica.

Riparazione automatica delle VM

A volte le VM che ospitano la tua applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero esserci problemi con l'applicazione stessa. Potrebbe bloccarsi, avere un arresto anomalo o non disporre di memoria sufficiente. Per verificare se un'applicazione risponde come previsto, puoi configurare i controlli di integrità basati su applicazioni all'interno del criterio di riparazione automatica dei tuoi gruppi di istanze gestite. Se l'applicazione su una determinata VM non risponde, il gruppo di istanze gestite ripara automaticamente la VM. Per saperne di più sulla configurazione della riparazione automatica, consulta Configurare un controllo di integrità e la riparazione automatica dell'applicazione.

Posizionamento della VM

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

Pianificazione della capacità delle VM

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

Stato del disco permanente

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

Durabilità dei dati

Puoi utilizzare Backup e DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Il backup e RE memorizzano i dati di backup nel formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i carichi di lavoro in produzione utilizzando direttamente i dati dello spazio di archiviazione di backup a lungo termine senza attività di preparazione o spostamento dei dati che richiedono molto tempo.

Se utilizzi un servizio di database gestito come Cloud SQL, i backup vengono eseguiti automaticamente in base alle norme di conservazione che hai definito. Puoi integrare la strategia di backup con backup logici aggiuntivi per soddisfare requisiti normativi, di flusso di lavoro o aziendali. Se utilizzi un database di terze parti e devi archiviare i backup del database e i log delle transazioni, puoi utilizzare i bucket Cloud Storage regionali. I bucket Cloud Storage regionali forniscono uno spazio di archiviazione di backup a basso costo che è ridondante tra le zone.

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

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

Disponibilità del database

Se utilizzi un servizio di database gestito come Cloud SQL in configurazione HA, in caso di errore del database principale, Cloud SQL esegue il failover automatico al database di riserva. Non è necessario modificare l'indirizzo IP per l'endpoint del database. Se utilizzi un database di terze parti autonomo di cui è stato eseguito il deployment su una VM Compute Engine, devi utilizzare un bilanciatore del carico interno o un altro meccanismo per assicurarti che l'applicazione possa connettersi a un altro database se quello 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 principale e di un processo per eseguire il failover al database di riserva. Le specifiche del meccanismo di failover dipendono dal database utilizzato. Puoi configurare un'istanza di 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 per impedire un failover non necessario. Ad esempio, per le architetture che puoi utilizzare per implementare il failover per i database PostgreSQL, consulta Architetture per l'alta disponibilità dei cluster PostgreSQL su Compute Engine.

Altre considerazioni sull'affidabilità

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

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo della configurazione e del funzionamento di una topologia Google Cloud regionale creata 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 consigli per scegliere i tipi di macchine che corrispondono ai requisiti di calcolo del tuo carico di lavoro. Per i carichi di lavoro con requisiti di risorse prevedibili, puoi personalizzare il tipo di macchina in base alle tue esigenze e risparmiare utilizzando i tipi di macchine personalizzate.

Modello di provisioning delle VM

Se la tua applicazione è a tolleranza di errore, le VM spot possono aiutarti a ridurre i costi di Compute Engine per le VM nei livelli di applicazione e web. Il costo delle VM spot è notevolmente inferiore rispetto alle VM normali. Tuttavia, Compute Engine potrebbe arrestare o eliminare in modo preventivo le VM spot per recuperare la capacità. Le VM spot sono adatte per job batch che possono tollerare il prerilascio e non hanno requisiti di HA. Le VM spot offrono gli stessi tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, quando la capacità delle risorse in una zona è limitata, i gruppi di istanze gestite potrebbero non essere in grado di eseguire lo scale out (ovvero creare VM) automaticamente fino alle dimensioni target specificate finché la capacità richiesta non diventa di nuovo disponibile.

Utilizzo delle risorse

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. Paghi solo per l'infrastruttura delle VM che utilizzi su Google Cloud. Questa strategia ti consente di continuare a trarre valore dai tuoi investimenti esistenti in licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, ti consigliamo di procedere nel seguente modo:

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

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

Altre considerazioni sui costi

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

Efficienza operativa

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

Aggiornamenti della configurazione della VM

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

Immagini VM

Per i modelli di istanze MIG, anziché utilizzare le immagini pubbliche fornite da Google, ti consigliamo di creare e utilizzare immagini personalizzate contenenti le configurazioni e il software richiesti dalle tue applicazioni. Puoi raggruppare le tue immagini personalizzate in una famiglia di immagini personalizzate. Una famiglia di immagini fa sempre riferimento all'immagine più recente della famiglia, pertanto i modelli di istanze e gli script possono utilizzare quell'immagine senza che tu debba aggiornare i riferimenti a una versione dell'immagine specifica.

Modelli di istanza deterministici

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

Altre considerazioni operative

Quando crei l'architettura per il tuo carico di lavoro, tieni conto delle best practice e dei consigli generali per l'efficienza operativa descritti nel Framework dell'architettura di Google Cloud: eccellenza operativa.

Ottimizzazione delle prestazioni

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

Posizionamento della VM

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

Tipi di macchine VM

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

Requisito Famiglia di macchine consigliata Serie di macchine di esempio
Miglior rapporto prezzo/prestazioni per diversi workload Famiglia di macchine per uso generico C3, C3D, E2, N2, N2D, Tau T2D, Tau T2A
Massime prestazioni per core e ottimizzazione per workload ad alta intensità di calcolo Famiglia di macchine ottimizzate per il calcolo C2, C2D, H3
Rapporto memoria/vCPU elevato per workload 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 della CPU fisica. Per i carichi di lavoro altamente paralleli o che eseguono calcoli con numeri in virgola mobile (ad esempio l'analisi delle sequenze genetiche e la creazione di modelli di rischio finanziario), puoi migliorare le prestazioni riducendo il numero di thread in esecuzione su ogni core della CPU fisica. Per ulteriori informazioni, consulta Impostare il numero di thread per core.

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

Network Service Tiers

Network Service Tiers ti consente di ottimizzare i costi e le prestazioni della rete dei tuoi carichi di lavoro. Puoi scegliere il livello Premium o Standard.

  • Il livello Premium utilizza la struttura backbone globale altamente affidabile di Google per aiutarti a minimizzare la perdita di pacchetti e la latenza. Il traffico entra ed esce dalla rete Google in un punto di presenza perimetrale (PoP) globale vicino all'utente finale. Ti consigliamo di utilizzare il livello Premium come livello predefinito per un rendimento ottimale.
  • Con il livello Standard, il traffico entra ed esce dalla rete Google in un PoP di confine più vicino alla località Google Cloud in cui viene eseguito il carico di lavoro. I prezzi del livello Standard sono inferiori a quelli del livello Premium. Il livello Standard è adatto per il traffico non sensibile alla perdita di pacchetti e che non ha requisiti di latenza ridotta.

Altre considerazioni sul rendimento

Quando crei l'architettura per il tuo carico di lavoro, tieni conto delle best practice e dei consigli generali forniti nel framework dell'architettura di Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: