Deployment a livello di regione su Compute Engine

Last reviewed 2024-01-31 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione multi-livello eseguita su VM di Compute Engine in più zone all'interno di una regione Google Cloud. Puoi utilizzare questa architettura di riferimento per rehosting (lift and shift) in modo efficiente delle applicazioni on-premise sul cloud con modifiche minime alle applicazioni. Il documento descrive inoltre i fattori di progettazione da considerare quando crei un'architettura a livello di regione per le tue applicazioni cloud. Il pubblico di destinazione di questo documento è Cloud Architect.

Architettura

Il seguente diagramma mostra un'architettura per un'applicazione eseguita in modalità attivo-attivo in stack isolati di cui viene eseguito il deployment in tre zone Google Cloud all'interno di una regione. L'architettura è in linea con l'archetipo di deployment a livello di regione, il che assicura che la tua topologia Google Cloud sia solida contro le interruzioni delle zone.

Un'applicazione viene eseguita in modalità attiva-attiva in stack isolati di cui viene 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 necessarie (computing, networking e archiviazione) in Google Cloud. Mantieni il controllo completo sull'infrastruttura e sulla responsabilità del sistema operativo, del middleware e dei livelli più elevati dello stack di applicazioni. Per scoprire di più su IaaS e su altri modelli cloud, consulta Confronto tra PaaS, IaaS, SaaS e CaaS: in che cosa differiscono?.

Il diagramma precedente include i seguenti componenti:

Componente Finalità
Bilanciatore del carico esterno a livello di regione

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 in base al tipo di traffico e ad 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 maggiori informazioni, consulta Scegliere un bilanciatore del carico.

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

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

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

Bilanciatore del carico interno a livello di regione

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

A seconda dei tuoi requisiti, puoi utilizzare un Application Load Balancer interno regionale o un bilanciatore del carico di rete. Per saperne di più, consulta Scegliere un bilanciatore del carico.

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

Il livello di applicazione viene eseguito su VM di Compute Engine che fanno parte di un gruppo di istanze gestite a livello di regione, che rappresentano il backend per il bilanciatore del carico interno.

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

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

L'architettura in questo documento mostra un database di terze parti (come PostgreSQL) di cui è stato eseguito il deployment su una VM di Compute Engine. Puoi eseguire il deployment di un database in 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 comporta ulteriori sforzi e costi operativi per l'applicazione di aggiornamenti, il monitoraggio e la garanzia della disponibilità. Puoi evitare l'overhead associato all'installazione e la gestione di un database di terze parti e sfruttare le funzionalità ad alta disponibilità 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 più avanti in questa guida.

Rete Virtual Private Cloud e subnet

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

A seconda delle tue esigenze, puoi scegliere di creare un'architettura che utilizza più reti VPC o più subnet. Per maggiori informazioni, consulta Decidere se creare più reti VPC in "Best practice e architetture di riferimento per la progettazione VPC".

Bucket a due regioni Cloud Storage

I backup di applicazioni e database sono archiviati in un bucket Cloud Storage a due regioni. In caso di interruzione di una zona o di 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 dei 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 ad alte prestazioni, scalabili, globali e a livello di regione.
  • Cloud Storage: un archivio di oggetti a basso costo e senza limitazioni per tipi di dati diversi. I dati sono accessibili dall'interno e dall'esterno di Google Cloud e sono replicati tra località per ridondanza.
  • Virtual Private Cloud: un sistema virtuale che fornisce funzionalità di networking globale e scalabile per i carichi di lavoro Google Cloud.

Casi d'uso

Questa sezione descrive i casi d'uso per cui un deployment a livello di regione 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 il rehosting (lift and shift) delle applicazioni on-premise sul cloud con modifiche minime alle applicazioni. Tutti i livelli dell'applicazione in questa architettura di riferimento sono ospitati su VM di Compute Engine. Questo approccio consente di migrare in modo efficiente le applicazioni on-premise al cloud e di sfruttare i vantaggi in termini di costi, affidabilità, prestazioni e semplicità operativa offerti da Google Cloud.

Applicazione a disponibilità elevata con utenti in un'area geografica

Consigliamo un'architettura di deployment a livello di regione per le applicazioni che richiedono solidità contro le interruzioni delle zone, ma possono tollerare alcuni tempi di inattività causati da interruzioni delle regioni. In caso di errore di una parte dello stack dell'applicazione, l'applicazione continua a essere eseguita se in ogni livello è presente almeno un componente funzionante con capacità adeguata. In caso di interruzione di una zona, lo stack di applicazioni continua a essere eseguito nelle altre zone.

Bassa latenza per gli utenti dell'applicazione

Se tutti gli utenti di un'applicazione si trovano in una singola area geografica, ad esempio un solo paese, un'architettura di deployment a livello di regione può contribuire a migliorare le prestazioni dell'applicazione percepite dall'utente. Puoi ottimizzare la latenza di rete per le richieste degli utenti eseguendo il deployment dell'applicazione nella regione Google Cloud più vicina ai tuoi utenti.

Networking a bassa latenza tra componenti delle applicazioni

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

Conformità con i requisiti di residenza dei dati

Puoi utilizzare un'architettura a regione singola per creare una topologia che ti aiuti a soddisfare i requisiti di residenza dei dati. Ad esempio, un paese europeo potrebbe richiedere l'archiviazione e l'accesso a tutti i dati utente in data center che si trovano fisicamente in Europa. Per soddisfare questo requisito, puoi eseguire l'applicazione in una regione Google Cloud in Europa.

Note sul layout

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

Progettazione del sistema

Questa sezione fornisce indicazioni che aiutano a scegliere le regioni Google Cloud per il deployment a livello di regione e a selezionare i servizi Google Cloud appropriati.

Selezione della regione

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

  • Disponibilità dei servizi Google Cloud. Per scoprire di più, consulta la sezione Prodotti disponibili per località.
  • Disponibilità dei tipi di macchine di Compute Engine. Per saperne di più, consulta Regioni e zone.
  • Requisiti di latenza dell'utente finale.
  • Costo delle risorse Google Cloud.
  • Requisiti normativi.

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

Servizi di computing

L'architettura di riferimento in questo documento utilizza VM di Compute Engine per tutti i livelli dell'applicazione. Le linee guida di progettazione in questo documento sono specifiche per Compute Engine, se non diversamente specificato.

A seconda dei requisiti della tua applicazione, puoi scegliere tra i seguenti altri servizi di computing di 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.
  • Se preferisci concentrare gli sforzi IT sui tuoi dati e sulle applicazioni anziché sulla configurazione e la gestione delle risorse dell'infrastruttura, puoi utilizzare servizi serverless come Cloud Run e Cloud Functions.

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 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 computing appropriati per i tuoi carichi di lavoro in Google Cloud, consulta Scegliere e gestire il computing nel framework dell'architettura Google Cloud.

Servizi di archiviazione

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

Per uno spazio di archiviazione a basso costo ridondante in tutte le zone di una regione, puoi utilizzare i bucket a livello di regione di 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 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 assicura alta disponibilità e robustezza contro le interruzioni delle zone. Puoi archiviare file di configurazione condivisi, strumenti e utilità comuni e log centralizzati nell'istanza Filestore e montare l'istanza su più VM.

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 eseguire il deployment di un'istanza di cluster di failover. 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 carichi di lavoro regionali, considera le caratteristiche funzionali dei carichi di lavoro, i requisiti di resilienza, le aspettative in termini di prestazioni e gli 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 nelle VM di Compute Engine. L'installazione e la gestione di un database di terze parti comporta sforzi e costi per operazioni come l'applicazione di aggiornamenti, il monitoraggio e la garanzia della disponibilità, l'esecuzione di backup e il ripristino in caso di errori.

Puoi evitare gli sforzi 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 servizi di database di Google Cloud offrono accordi sul livello del servizio (SLA) di uptime e includono funzionalità predefinite di scalabilità e 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 cui è adatto ogni servizio di database Google Cloud, consulta Database Google Cloud.

Sicurezza e conformità

In questa sezione vengono descritti i fattori da considerare quando utilizzi questa architettura di riferimento per progettare e creare una topologia a livello di regione in Google Cloud che soddisfi i requisiti di sicurezza e conformità dei tuoi carichi di lavoro.

Protezione contro minacce esterne

Per proteggere la tua applicazione da minacce esterne come attacchi DDoS (Distributed Denial-of-Service) e cross-site scripting (XSS), puoi utilizzare i criteri di sicurezza di Google Cloud Armor. I criteri di sicurezza vengono applicati al perimetro, ossia prima che il traffico raggiunga il livello web. Ogni criterio è un insieme di regole che specifica determinate condizioni che devono essere valutate e le azioni da intraprendere quando le condizioni sono soddisfatte. Ad esempio, una regola potrebbe specificare che se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP o a un intervallo CIDR specifico, il traffico deve essere negato. Inoltre, puoi applicare regole WAF (web application firewall) preconfigurate. Per maggiori informazioni, consulta la 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 hanno bisogno dell'accesso in entrata da internet. Non assegnare indirizzi IP esterni a queste VM. Le risorse Google Cloud 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, consulta Opzioni di accesso privato per i servizi.

Per abilitare le connessioni in uscita sicure dalle risorse Google Cloud che hanno solo indirizzi IP interni, come le VM di 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 con software che soddisfano i tuoi criteri o requisiti di sicurezza), puoi definire un criterio dell'organizzazione che limiti l'utilizzo delle immagini in specifici progetti di immagini pubbliche. Per ulteriori informazioni, consulta la pagina Configurare i criteri per le immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui l'API Compute Engine è abilitata, 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 venga disabilitato. Per impostazione predefinita, l'account di servizio predefinito è collegato a tutte le VM che crei utilizzando Google Cloud CLI o la console Google Cloud. Il ruolo Editor include un'ampia gamma di autorizzazioni, quindi il collegamento dell'account di servizio predefinito alle VM crea 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 criteri granulari. Per maggiori 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 regole firewall di Cloud Next Generation appropriate. Ogni regola firewall consente di controllare il traffico in base a parametri come il protocollo, l'indirizzo IP e la 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.

Ulteriori considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, prendi in considerazione i suggerimenti e le best practice per la sicurezza a livello di piattaforma forniti nel progetto della piattaforma di sicurezza.

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

Interruzioni dell'infrastruttura

In un'architettura a livello di regione, in caso di errore di un singolo componente dello stack di infrastruttura, l'applicazione può elaborare le richieste se in ogni livello è presente almeno un componente funzionante con capacità adeguata. Ad esempio, in caso di errore di un'istanza del server web, 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 dell'app si arresta in modo anomalo, il MIG ricrea automaticamente la VM.

L'interruzione di una zona non influisce sul bilanciatore del carico, in quanto è una risorsa di regione. Un'interruzione di una zona potrebbe influire sulle singole VM di Compute Engine. Ma l'applicazione rimane disponibile e reattiva perché le VM si trovano in un gruppo di istanze gestite a livello di regione. Un gruppo di istanze gestite a livello di regione assicura che le nuove VM vengano create automaticamente per mantenere il numero minimo configurato di VM. Dopo che Google ha risolto l'interruzione della zona, devi verificare che l'applicazione venga eseguita come previsto in tutte le zone in cui è stato eseguito il deployment.

Se tutte le zone di questa architettura sono soggette a un'interruzione o se si verifica un'interruzione di una regione, l'applicazione non è disponibile. Devi attendere che Google risolva l'interruzione, quindi 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 di infrastruttura in un'altra regione Google Cloud. In caso di interruzione nella regione principale, puoi attivare lo stack nella regione di failover e utilizzare i criteri di routing DNS per instradare il traffico al bilanciatore del carico nella regione di failover.

Per le applicazioni che richiedono solidità contro le interruzioni a livello di regione, valuta l'utilizzo di un'architettura multiregionale. Per maggiori informazioni, consulta Deployment multiregionale su Compute Engine.

Scalabilità automatica MIG

Quando esegui l'applicazione su VM in un gruppo di istanze gestite a livello di regione, l'applicazione rimane disponibile durante le interruzioni delle zone isolate. La capacità di scalabilità automatica dei MIG stateless ti consente di mantenere la disponibilità e le prestazioni delle applicazioni a livelli prevedibili. I gruppi di gruppi di istanze gestite stateful non possono essere scalati automaticamente.

Per controllare il comportamento della scalabilità automatica dei gruppi di istanze gestite, puoi specificare le metriche di utilizzo target, come l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica basata sulla pianificazione. Per maggiori informazioni, consulta Scalabilità automatica dei gruppi di istanze.

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 arresto anomalo o non dispone di memoria sufficiente. Per verificare se un'applicazione risponde come previsto, puoi configurare controlli di integrità basati sull'applicazione nell'ambito dei criteri di riparazione automatica dei gruppi di istanze gestite. Se l'applicazione su una determinata VM non risponde, il gruppo di istanze gestite corregge automaticamente (ripara) la VM. Per saperne di più sulla configurazione della riparazione automatica, consulta Configurare un controllo di integrità dell'applicazione e la riparazione automatica.

Posizionamento VM

Nell'architettura descritta in questo documento, il livello applicazione e il livello web vengono eseguiti su VM di Compute Engine distribuite in più zone. Questa distribuzione assicura che l'applicazione sia affidabile contro le interruzioni delle zone. Per migliorare ulteriormente questa affidabilità, puoi creare un criterio di posizionamento diffuso e applicarlo al modello di gruppo di istanze gestite. Quando il gruppo di istanze gestite crea le VM, posiziona le VM all'interno di ciascuna zona su server fisici diversi (chiamati host), in modo che le VM siano sicure contro i guasti dei singoli host. Per maggiori informazioni, consulta Applicare criteri di posizionamento distribuito alle VM.

Pianificazione della capacità VM

Per assicurarti che la capacità per le VM di Compute Engine sia disponibile quando richiesta per la scalabilità automatica di MIG, puoi creare delle prenotazioni. Una prenotazione offre capacità garantita in una zona specifica per un numero specificato di VM del tipo di macchina scelto. Una prenotazione può essere specifica per un progetto o condivisa tra più progetti. Ti vengono addebitati dei costi per le risorse prenotate, anche se non ne viene eseguito il provisioning o l'utilizzo. Per ulteriori informazioni sulle prenotazioni, incluse le considerazioni sulla fatturazione, consulta Prenotazioni di risorse di zona di Compute Engine.

Stato del disco permanente

Una best practice nella progettazione di applicazioni consiste nell'evitare la necessità di dischi locali stateful. Tuttavia, se il requisito esiste, puoi configurare i dischi permanenti in modo che siano di tipo stateful, in modo da 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 facilmente alle immagini più recenti con nuove versioni e patch di sicurezza. Per maggiori informazioni, consulta Configurazione di dischi permanenti stateful nei gruppi di istanze gestite.

Durabilità dei dati

Puoi utilizzare Backup ed RE per creare, archiviare e gestire i backup delle VM di Compute Engine. Il backup e il RE archiviano i dati di backup nel suo formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i carichi di lavoro in produzione utilizzando direttamente i dati dall'archiviazione di backup a lungo termine, senza lunghi spostamenti dei dati o attività di preparazione.

Se utilizzi un servizio di database gestito come Cloud SQL, i backup vengono eseguiti automaticamente in base al criterio di conservazione che hai definito. Puoi integrare la strategia di backup con ulteriori backup logici per soddisfare i requisiti normativi, del 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 offrono spazio di archiviazione di backup a basso costo e ridondante in più zone.

Compute Engine offre 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 di Persistent Disk. Gli snapshot standard sono archiviati in modo ridondante in più regioni, con checksum automatici per garantire l'integrità dei dati. Per impostazione predefinita, gli snapshot sono incrementali, quindi utilizzano meno spazio di archiviazione e tu risparmi denaro. Gli snapshot sono archiviati in una località di Cloud Storage che puoi configurare. Per ulteriori suggerimenti sull'utilizzo e la gestione degli snapshot, consulta Best practice per gli snapshot dei dischi di Compute Engine.
  • I volumi di dischi permanenti a livello di regione consentono di eseguire applicazioni ad alta disponibilità che non sono interessate da errori nei dischi permanenti. Quando crei un volume di Persistent Disk a livello di regione, Compute Engine conserva 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 si verifica un'interruzione in una delle due zone, i dati rimangono disponibili.

Disponibilità del database

Se utilizzi un servizio di database gestito come Cloud SQL nella configurazione ad alta disponibilità, in caso di errore del database principale Cloud SQL esegue automaticamente il failover nel database in standby. Non è necessario modificare l'indirizzo IP per l'endpoint del database. Se utilizzi un database di terze parti autogestito di cui è stato eseguito il deployment 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 principale e di un processo per il failover nel database in standby. Le specifiche del meccanismo di failover dipendono dal database utilizzato. Puoi configurare un'istanza di osservazione per rilevare gli errori del database primario 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. Ad esempio, consulta 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.

Ulteriori considerazioni sull'affidabilità

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

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare i costi di configurazione e gestione di una topologia Google Cloud a livello di regione che crei utilizzando questa architettura di riferimento.

Tipi di macchina 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 tipi di macchina che soddisfino i 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 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 applicazioni e web. Il costo delle VM spot è notevolmente inferiore rispetto alle VM normali. Tuttavia, Compute Engine potrebbe arrestare o eliminare preventivamente le VM spot per recuperare capacità. Le VM spot sono adatte per job batch che possono tollerare il prerilascio e non hanno requisiti ad alta disponibilità. Le VM spot offrono gli stessi tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, quando la capacità delle risorse in una zona è limitata, i gruppi di istanze gestite potrebbero non essere in grado di fare lo scale out (ovvero di creare VM) automaticamente alla dimensione di destinazione specificata fino a quando la capacità richiesta non diventa di nuovo disponibile.

Utilizzo delle risorse

La funzionalità di scalabilità automatica dei MIG stateless consente all'applicazione di gestire agevolmente l'aumento del traffico e di ridurre i costi quando il fabbisogno di risorse è ridotto. I gruppi di gruppi di istanze gestite stateful non possono essere scalati automaticamente.

Licenze di terze parti

Quando esegui la migrazione di carichi di lavoro di terze parti in Google Cloud, potresti riuscire a ridurre i costi applicando il modello BYOL (Bring Your Own License). Ad esempio, per eseguire il deployment delle VM di Microsoft Windows Server, invece di utilizzare un'immagine premium che comporta costi aggiuntivi per la licenza di terze parti, puoi creare e utilizzare un'immagine BYOL personalizzata di Windows. Quindi paghi solo per l'infrastruttura VM che utilizzi su Google Cloud. Questa strategia ti consente di continuare a trarre valore dagli investimenti esistenti in licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, ti consigliamo di procedere come segue:

  • Esegui il provisioning del numero richiesto di core della CPU di computing indipendentemente dalla memoria utilizzando i tipi di macchine personalizzate. In questo modo, limiti il costo delle licenze 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 multithreading simultaneo (SMT) e riduci i costi per le licenze del 50%.

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 del servizio.

Ulteriori considerazioni sui costi

Quando crei l'architettura per il tuo carico di lavoro, tieni anche conto delle best practice e dei suggerimenti generali 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 a livello di regione che puoi operare 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 quindi applica il nuovo modello al gruppo di istanze gestite. Il gruppo di istanze gestite aggiorna le VM utilizzando il metodo di aggiornamento che scegli: automatico o selettivo. Scegli un metodo appropriato in base ai tuoi requisiti di disponibilità e di efficienza operativa. Per saperne di più su questi metodi di aggiornamento dei gruppi di istanze gestite, consulta Applicare nuove configurazioni delle VM in un gruppo di istanze gestite.

Immagini VM

Per i modelli di istanza di gruppo di istanze gestite, anziché utilizzare 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 immagini personalizzate in una famiglia di immagini personalizzate. Una famiglia di immagini rimanda sempre all'immagine più recente nella famiglia, quindi i modelli di istanza e gli script possono utilizzare l'immagine senza che tu debba aggiornare i riferimenti a una versione specifica dell'immagine.

Modelli di istanza deterministici

Se i modelli di istanza che utilizzi per i gruppi di istanze gestite includono script di avvio per installare software di terze parti, assicurati che questi specifichino esplicitamente i parametri di installazione del software, ad esempio 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 tuo modello di istanza include uno script di avvio per installare Apache HTTP Server 2.0 (il pacchetto apache2), assicurati che lo script specifichi esattamente la versione apache2 da installare, ad esempio la versione 2.4.53. Per ulteriori informazioni, 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 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 a livello di regione 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 tra le VM, puoi creare un criterio di posizionamento compatto e applicarlo al modello di gruppo di istanze gestite. Quando il gruppo di istanze gestite crea le VM, posiziona le VM su server fisici vicini tra loro. Per maggiori informazioni, consulta Ridurre la latenza utilizzando criteri di posizionamento compatti.

Tipi di macchina VM

Compute Engine offre un'ampia gamma di tipi di macchine predefinite e personalizzabili tra cui puoi scegliere in base ai requisiti di costo e prestazioni. I tipi di macchina sono raggruppati in serie di macchine e famiglie. La seguente tabella fornisce un riepilogo delle famiglie e delle serie di macchine consigliate per i 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 ottimizzate per carichi di lavoro ad alta intensità di calcolo Famiglia di macchine ottimizzate per il calcolo C2, C2D, H3
Alto rapporto memoria-vCPU per carichi di lavoro che richiedono molta memoria Famiglia di macchine ottimizzate per la memoria M3, M2, M1
GPU per carichi di lavoro altamente parallelizzati Famiglia di macchine ottimizzate per l'acceleratore A2 e G2

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

Multi-threading delle VM

Ogni CPU virtuale (vCPU) allocata a una VM di Compute Engine 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 modellazione del rischio finanziario), puoi migliorare le prestazioni riducendo il numero di thread eseguiti su ciascun core fisico della CPU. Per maggiori informazioni, consulta Impostare il numero di thread per core.

Il multithreading delle VM potrebbe avere implicazioni sulle licenze per alcuni software di terze parti, come i database. Per ulteriori informazioni, leggi la documentazione relativa alle licenze del 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 utilizza la struttura backbone globale altamente affidabile di Google per aiutarti a ridurre al minimo la perdita di pacchetti e la latenza. Il traffico entra ed esce dalla rete Google in un punto di presenza (POP) perimetrale globale, vicino all'utente finale. Ti consigliamo di utilizzare il livello Premium come livello predefinito per prestazioni ottimali.
  • Con il livello Standard, il traffico entra ed esce dalla rete Google presso un PoP perimetrale più vicino alla località Google Cloud in cui viene eseguito il carico di lavoro. I prezzi del livello Standard sono inferiori rispetto al livello Premium. Il livello Standard è adatto per il traffico non sensibile alla perdita di pacchetti e che non ha requisiti di bassa latenza.

Ulteriori considerazioni sul rendimento

Quando crei l'architettura per il tuo carico di lavoro, prendi in considerazione le best practice e i suggerimenti generali forniti nel documento Framework dell'architettura Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Cross-Product Solution Developer

Altri collaboratori: