Deployment in una singola zona su Compute Engine

Last reviewed 2024-02-08 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione multi-livello in esecuzione su VM di Compute Engine in una singola zona in Google Cloud. Puoi utilizzare per questa architettura di riferimento Rehosting (lift and shift) le applicazioni on-premise al cloud con modifiche minime. Il documento descrive inoltre i fattori di progettazione da prendere in considerazione per per creare un'architettura di zona per le applicazioni cloud. Il pubblico di destinazione per questo documento sono Cloud Architect.

Architettura

Il seguente diagramma mostra un'architettura per un'applicazione eseguita in un in una singola zona Google Cloud. Questa architettura è in linea con Archetipo di deployment a livello di zona di Google Cloud.

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 necessarie (computing, networking archiviazione) in Google Cloud. Mantieni il controllo completo sull'infrastruttura e la responsabilità del sistema operativo, del middleware e dei livelli superiori lo stack delle 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 alle VM del livello web.

Utilizzare un tipo di bilanciatore del carico appropriato in base al traffico tipo e altri requisiti. Ad esempio, se il backend è costituito da server web (come mostrato nell'architettura precedente), quindi utilizza Bilanciatore del carico delle applicazioni per inoltrare il traffico HTTP(S). Per bilanciare il carico per il traffico TCP, utilizza un bilanciatore del carico di rete. Per saperne di più, vedi Scegliere un bilanciatore del carico.

Gruppo di istanze gestite a livello di zona per il livello web Viene eseguito il deployment del livello web dell'applicazione VM di Compute Engine che fanno parte di un gruppo di istanze gestite a livello di zona. Il gruppo di istanze gestite è il backend per il bilanciatore del carico esterno regionale. Ogni VM nell'account Il gruppo di istanze gestite ospita un'istanza indipendente del livello web un'applicazione.
Bilanciatore del carico interno a livello di regione

Il bilanciatore del carico interno regionale distribuisce il traffico dalla da VM del livello web a quelle del livello di applicazione.

In base ai tuoi requisiti, puoi utilizzare una un bilanciatore del carico delle applicazioni o un bilanciatore del carico di rete interno regionale. Per ulteriori informazioni, consulta Scegliere un bilanciatore del carico.

Gruppo di istanze gestite a livello di zona per il livello di applicazione Il deployment del livello di applicazione viene eseguito sulle VM di Compute Engine che fanno parte di un gruppo di istanze gestite a livello di zona, ovvero il backend per con il bilanciatore del carico di rete passthrough esterno regionale. Ogni VM nel gruppo di istanze gestite ospita un'istanza indipendente il livello di applicazione.
Database di terze parti di cui è stato eseguito il deployment su Compute Engine VM

L'architettura in questo documento mostra un database di terze parti (come PostgreSQL) di cui viene eseguito il deployment alla 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 che utilizzi.

L'installazione e la gestione di un database di terze parti comporta sforzi e costi operativi aggiuntivi per l'applicazione degli aggiornamenti, il monitoraggio e la garanzia della disponibilità. Puoi evitare l'overhead installando e gestendo un database di terze parti e sfruttando le funzionalità integrate ad alta disponibilità utilizzando un modello come Cloud SQL o AlloyDB per PostgreSQL. Per maggiori informazioni informazioni sulle opzioni di database gestito, vedi Servizi di database.

Rete Virtual Private Cloud e subnet

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

In base ai tuoi requisiti, puoi scegliere di creare che utilizza più reti VPC o più subnet. Per per ulteriori informazioni, consulta la sezione Decidere se creare più combinazioni Reti VPC in "Best practice e architetture di riferimento per progettazione VPC."

Cloud Storage a livello di regione del bucket rimanente

I backup di applicazioni e database vengono archiviati in un nel bucket Cloud Storage. In caso di interruzione di una zona, l'applicazione e i dati non vadano 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 computing sicuro e personalizzabile che ti consente per creare ed eseguire VM sull'infrastruttura di Google.
  • Cloud Load Balancing: un portafoglio di soluzioni scalabili, globali e ad alte prestazioni di bilanciatori del carico regionali.
  • Cloud Storage: un archivio di oggetti economico e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloud replicati in più località per la ridondanza.
  • Virtual Private Cloud: un sistema virtuale che fornisce un networking globale e scalabile per i tuoi carichi di lavoro Google Cloud.

Casi d'uso

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

  • Sviluppo e test nel cloud: puoi utilizzare un deployment a zona singola per creare un ambiente cloud a basso costo per lo sviluppo e i test.
  • Applicazioni che non richiedono alta disponibilità: un'architettura a zona singola potrebbe essere sufficiente per le applicazioni che possono tollerare i tempi di inattività dovuti di eventuali interruzioni dell'infrastruttura.
  • Networking a bassa latenza e basso costo tra i componenti dell'applicazione: un a zona singola potrebbe essere adatta per applicazioni come che richiedono una rete a bassa latenza e a larghezza di banda elevata e connessioni tra i nodi di computing. Con un deployment a zona singola, senza traffico di rete tra zone né costi per il traffico all'interno della zona.
  • Migrazione dei carichi di lavoro di base: l'architettura di deployment a livello di zona offre un semplice percorso di migrazione al cloud per le commodity on-premise applicazioni per le quali non hai alcun controllo sul codice o che non supportare architetture che vanno oltre una topologia attiva-passiva di base.
  • Esecuzione di software con licenza limitata: un'architettura a zona singola potrebbe essere adatta a sistemi con limitazioni di licenza in cui vengono eseguiti un'istanza alla volta è troppo costosa o non è consentita.

Note sul layout

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

Progettazione del sistema

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

Selezione delle regioni

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

  • Disponibilità dei servizi Google Cloud. Per ulteriori informazioni, vedi Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchine di Compute Engine. Per maggiori informazioni le informazioni, vedi 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, vedi Selezionare zone geografiche e regioni nel framework dell'architettura Google Cloud.

Servizi di computing

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

A seconda dei requisiti della tua applicazione, puoi scegliere tra rispetto ad altri servizi di computing di Google Cloud. Le linee guida di progettazione non rientrano nell'ambito del presente documento.

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

La decisione di utilizzare VM, container o servizi serverless implica un compromesso tra flessibilità di configurazione e sforzi di gestione. VM i container offrono una maggiore flessibilità di configurazione, ma nella gestione delle risorse. In un'architettura serverless, il deployment dei carichi di lavoro una piattaforma preconfigurata che richiede il minimo sforzo di gestione. Per maggiori informazioni informazioni sulla scelta dei servizi di computing appropriati per i carichi di lavoro in per Google Cloud, consulta Scegliere e gestire il computing nel framework dell'architettura Google Cloud.

Servizi di archiviazione

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

Per un'archiviazione a basso costo e ridondante nelle varie zone all'interno di una regione, puoi per 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 a livello web o di applicazione, puoi utilizzare Filestore. I dati archiviati in un'istanza Filestore Enterprise sono replicati in modo sincrono tra le tre zone all'interno della regione. Questa replica garantisce alta disponibilità e robustezza contro le interruzioni di zona. Puoi archiviare file di configurazione condivisi, gli strumenti e le utilità comuni e i log centralizzati e montare l'istanza su più VM.

Se il tuo database è Microsoft SQL Server, ti consigliamo di utilizzare in Cloud SQL per SQL Server. Nei casi in cui Cloud SQL non supporta o se hai bisogno di accedere al sistema operativo, puoi eseguire il deployment istanza cluster di failover (FCI). In questo scenario, puoi utilizzare lo strumento Google Cloud NetApp Volumes per fornire archiviazione SMB a disponibilità continua (CA) per il database.

Quando progetti l'archiviazione per i carichi di lavoro, considerane il funzionamento caratteristiche, requisiti di resilienza, aspettative di prestazioni e costo obiettivi. Per ulteriori informazioni, vedi Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud.

Servizi di database

L'architettura di riferimento in questo documento utilizza un database di terze parti, come PostgreSQL di cui è stato eseguito il deployment su VM di Compute Engine. L'installazione e la gestione di un database di terze parti richiede sforzi e costi per operazioni come applicare aggiornamenti, monitorare e garantire la disponibilità, eseguire backup e il ripristino dagli errori.

Puoi evitare i sforzi e i costi legati all'installazione e alla gestione di un fornitore di terze parti utilizzando un servizio di database completamente gestito, Cloud SQL AlloyDB per PostgreSQL, Bigtable Spanner, o Firestore. Questi servizi di database di Google Cloud offrono uptime al livello di servizio contratti (SLA) e includono funzionalità predefinite per la scalabilità osservabilità. Se i tuoi carichi di lavoro richiedono un database Oracle, puoi utilizzare Soluzione Bare Metal offerti da Google Cloud, Per una panoramica dei casi d'uso Il servizio di database Google Cloud è adatto per, vedi database Google Cloud.

Sicurezza e conformità

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

Protezione contro minacce esterne

Per proteggere la tua applicazione da minacce esterne come Distributed Denial-of-Service (DDoS) e cross-site scripting (XSS), puoi utilizzare Criteri di sicurezza di Google Cloud Armor. I criteri di sicurezza vengono applicati prima che il traffico raggiunga il livello web. Ogni criterio è un insieme regole che specificano determinate condizioni che devono essere valutate e azioni quando le condizioni sono soddisfatte. Ad esempio, una regola potrebbe specificare che, l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP o CIDR specifico il traffico deve essere negato. Inoltre, puoi applicare modelli web application firewall (WAF). Per ulteriori informazioni, vedi Panoramica dei criteri di sicurezza.

Accesso esterno per le VM

Nell'architettura di riferimento descritta in questo documento, le VM che ospitano il livello di applicazione, il livello web e i database non hanno bisogno dell'accesso in entrata internet. Non assegnare indirizzi IP esterni a queste VM. Risorse Google Cloud che hanno solo un IP interno privato può comunque accedere a determinati servizi e API di Google utilizzando Private Service Connect o accesso privato Google. Per maggiori informazioni le informazioni, vedi Opzioni di accesso privato per i servizi.

Per abilitare connessioni in uscita sicure dalle risorse Google Cloud che hanno solo indirizzi IP interni, come le VM di Compute Engine di riferimento, puoi utilizzare Cloud NAT.

Sicurezza delle immagini VM

Per assicurarti che le VM utilizzino solo immagini approvate (ovvero immagini con software che soddisfi i requisiti dei criteri o di sicurezza), puoi definire un'organizzazione che limita l'uso delle immagini in progetti di immagini pubbliche specifici. Per ulteriori informazioni, vedi Configurare i criteri per le immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui è abilitata l'API Compute Engine, account di servizio predefinito viene creata automaticamente. All'account di servizio predefinito viene concesso il ruolo IAM Editor (roles/editor), a meno che non si tratti di il comportamento è disattivato. Per impostazione predefinita, l'account di servizio predefinito è collegato a tutte le VM che crei utilizzando Google Cloud CLI o la console Google Cloud. Ruolo Editor Include una vasta gamma di autorizzazioni, quindi collegare l'account di servizio predefinito delle VM crea un rischio per la sicurezza. Per evitare questo rischio, puoi creare e utilizzare più account di servizio dedicati per ogni applicazione. Per specificare le risorse a cui può accedere l'account di servizio, usare criteri granulari. Per ulteriori informazioni, vedi Limitare i privilegi degli account di servizio in "Best practice per l'utilizzo di account di servizio".

Sicurezza della rete

Per controllare il traffico di rete tra le risorse nell'architettura, devi configurano in modo appropriato Regole firewall di nuova generazione Cloud. 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 del database alle VM e bloccare tutto il resto del traffico.

Ulteriori considerazioni sulla sicurezza

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

Affidabilità

Questa sezione descrive i fattori di progettazione da prendere in considerazione quando utilizzi questa architettura di riferimento per creare e gestire un'infrastruttura affidabile deployment a livello di zona in Google Cloud.

Interruzioni dell'infrastruttura

In un'architettura di deployment a zona singola, se nell'infrastruttura è presente stack dell'infrastruttura ha errori, l'applicazione può elaborare le richieste se ogni livello contiene almeno un componente funzionante con una capacità adeguata. Ad esempio: In caso di errore di un'istanza del server web, il bilanciatore del carico inoltra le richieste dell'utente ad altre istanze del server web disponibili. Se una VM che ospita un server web o un'app l'istanza del server si arresta in modo anomalo, Il gruppo di istanze gestite ricrea la VM automaticamente. Se il database si arresta in modo anomalo, devi attivare manualmente il secondo database e aggiornare le istanze dell'app server per connettersi al database.

Un'interruzione della zona o della regione influisce su tutte le VM di Compute Engine in un il deployment in una singola zona. L'interruzione di una zona non influisce sul bilanciatore del carico perché è una risorsa di regione. ma il bilanciatore del carico non può distribuirà il traffico, perché non ci sono backend disponibili. Se una zona o una regione devi attendere che Google la risolva, quindi verifica che l'applicazione funzioni come previsto.

Puoi ridurre il tempo di inattività causato da interruzioni di zona o regione mantenendo un replica passiva (failover) dello stack dell'infrastruttura in un altro nella zona o nella regione Google Cloud. Se si verifica un'interruzione nella zona principale, attivare lo stack nella zona o regione di failover e usare Criteri di routing DNS per instradare il traffico al bilanciatore del carico nella zona o nella regione di failover.

Per le applicazioni che richiedono robustezza contro le interruzioni di zone o regioni, prendi in considerazione l'utilizzo di un'architettura a livello di una o più regioni. Consulta quanto segue: di riferimento:

Scalabilità automatica MIG

La scalabilità automatica dei MIG stateless consente di mantenere la disponibilità delle applicazioni del rendimento a livelli prevedibili. MIG stateful non possono essere scalati automaticamente.

Per controllare il comportamento della scalabilità automatica dei gruppi di istanze gestite, puoi specificare come l'utilizzo medio della CPU. Puoi anche configurare con scalabilità automatica basata sulla pianificazione. Per ulteriori informazioni, vedi Gruppi di istanze con scalabilità automatica.

Limite dimensioni MIG

Per impostazione predefinita, un gruppo di istanze gestite a livello di zona può avere fino a 1000 VM. Puoi Aumenta il limite di dimensioni di un gruppo di istanze gestite a 2000 VM.

Riparazione automatica delle VM

A volte le VM che ospitano la tua applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero verificarsi problemi con l'applicazione stessa. Potrebbe bloccarsi, arrestarsi in modo anomalo o se non hai memoria sufficiente. Per verificare se un'applicazione risponde puoi configurare i controlli di integrità basati sull'applicazione nell'ambito dei tuoi gruppi di istanze gestite. Se l'applicazione su una determinata VM non è risponde, il gruppo di istanze gestite corregge automaticamente la VM. Per ulteriori informazioni per configurare la riparazione automatica, consulta Configura un controllo di integrità delle applicazioni e una riparazione automatica.

Posizionamento VM

Nell'architettura descritta in questo documento, il livello di applicazione e su VM di Compute Engine all'interno di una singola zona. Per migliorare il robustezza dell'architettura, puoi creare criterio di posizionamento distribuito e applicarlo al modello MIG. Quando il gruppo di istanze gestite crea le VM, le posiziona diversi server fisici (chiamati host), in modo che le VM siano affidabili degli errori dei singoli host. Per ulteriori informazioni, vedi Applica alle VM criteri di posizionamento distribuito.

Pianificazione della capacità delle VM

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

Stato del disco permanente

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

Durabilità dei dati

Puoi utilizzare Backup e RE per creare, archiviare e gestire i backup delle VM di Compute Engine. Secondario e RE archivia i dati di backup nel formato originale leggibile dall'applicazione. Quando di produzione, puoi ripristinare i carichi di lavoro in produzione utilizzando dallo spazio di archiviazione di backup a lungo termine senza dover spostare i dati in modo dispendioso in termini di tempo attività di preparazione.

Se utilizzi un servizio di database gestito come Cloud SQL, i backup vengono eseguiti automaticamente in base al criterio di conservazione da te definito. Puoi integrare la strategia di backup con backup logici aggiuntivi per soddisfare le normative, un flusso di lavoro o requisiti aziendali.

Se usi un database di terze parti e devi archiviare backup e log delle transazioni, puoi usare i bucket Cloud Storage a livello di regione. A livello di regione I bucket Cloud Storage forniscono archiviazione di backup ridondante a basso costo tra zone diverse.

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

  • Puoi utilizzare snapshot per acquisire lo stato point-in-time dei volumi Persistent Disk. Standard gli snapshot sono archiviati in modo ridondante in più regioni, con per garantire l'integrità dei dati. Gli snapshot sono incrementali per impostazione predefinita, occupano quindi meno spazio di archiviazione e tu puoi risparmiare. Snapshot sono archiviati in un Località di Cloud Storage che puoi configurare. Per altri consigli sull'utilizzo e la gestione gli snapshot, vedi Best practice per gli snapshot dei dischi di Compute Engine.
  • Volumi di dischi permanenti a livello di regione consente di eseguire applicazioni a disponibilità elevata non interessate da errori nei dischi permanenti. Quando crei un volume di Persistent Disk regionale, Compute Engine mantiene una replica del disco in una zona diversa nella stessa regione. I dati vengono replicati in modo sincrono nei dischi diverse. Se si verifica un'interruzione in una delle due zone, i dati rimangono disponibili.

Disponibilità database

Se utilizzi un servizio di database gestito come Cloud SQL in configurazione ad alta disponibilità, In caso di errore del database principale, Cloud SQL non riesce automaticamente al database in standby. Non è necessario modificare l'IP per l'endpoint del database. Se utilizzi un account di terze parti di cui è stato eseguito il deployment su una VM di 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 quello principale non è disponibile.

Per implementare il failover tra zone per un database di cui è stato eseguito il deployment alla VM di Compute Engine, è necessario un meccanismo per identificare gli errori principale e un processo di failover sul database in standby. La e le specifiche del meccanismo di failover dipendono dal database che utilizzi. Puoi configurare un'istanza di osservazione per rilevare errori del database principale per orchestrare il failover. Devi configurare le regole di failover in modo appropriato evita un cervello diviso della situazione ed evitare failover non necessari. Ad esempio, le architetture che puoi utilizzare per implementare il failover per i database PostgreSQL, Architetture per l'alta disponibilità di cluster PostgreSQL su Compute Engine.

Ulteriori considerazioni sull'affidabilità

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

Ottimizzazione dei costi

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

Tipi di VM

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

Modello di provisioning delle VM

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

Utilizzo delle risorse

La scalabilità automatica dei MIG stateless consente all'applicazione di gestire l'aumento gestire il traffico in modo controllato e aiuta a ridurre i costi quando sono necessarie risorse è basso. MIG stateful non possono essere scalati automaticamente.

Licenze di terze parti

Quando esegui la migrazione di carichi di lavoro di terze parti su Google Cloud, potresti essere in grado per ridurre i costi BYOL (Bring Your Own License). Ad esempio, per eseguire il deployment alle VM Microsoft Windows Server, anziché utilizzare una immagine premium che comporta costi aggiuntivi per la licenza di terze parti, puoi creare un immagine BYOL di Windows personalizzata. Quindi paghi solo per l'infrastruttura delle VM che utilizzi su Google Cloud. Questa strategia ti consente di continuare a ottenere valore dai tuoi investimenti esistenti delle licenze di terze parti. Se decidi di utilizzare l'approccio BYOL, ti consigliamo di eseguire le seguenti operazioni:

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

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

Ulteriori considerazioni sui costi

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

Efficienza operativa

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

Aggiornamenti della configurazione delle VM

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

Immagini VM

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

Modelli di istanza deterministici

Se i modelli di istanza che utilizzi per i gruppi di istanze gestite includono script di avvio installare software di terze parti, accertarsi che gli script specifichino esplicitamente di installazione software come la versione software. Altrimenti, quando il gruppo di istanze gestite crea le VM, il software installato sulle VM potrebbe non essere coerente. Ad esempio, se il modello di istanza include uno script di avvio per installa Apache HTTP Server 2.0 (il pacchetto apache2), quindi verifica che lo script specifica la versione esatta di apache2 da installare, ad esempio versione 2.4.53. Per ulteriori informazioni, vedi Modelli di istanza deterministici.

Ulteriori considerazioni operative

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

Ottimizzazione delle prestazioni

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

Posizionamento VM

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

Tipi di VM

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

Requisito Famiglia di macchine consigliata Esempio di serie di macchine
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 attività ad alta intensità di calcolo carichi di lavoro Famiglia di macchine ottimizzate per il calcolo C2, C2D, H3
Rapporto memoria-vCPU elevato per carichi di lavoro che richiedono molta memoria Famiglia di macchine ottimizzate per la memoria M3, M2, M1
GPU per carichi di lavoro a elevata parallelizzazione Macchina ottimizzata per l'acceleratore famiglia A2, G2

Per ulteriori informazioni, vedi Guida alle risorse e al confronto per le famiglie di macchine.

Multi-threading delle VM

Ogni CPU virtuale (vCPU) allocata a una VM di Compute Engine implementato come un singolo multithread hardware. Per impostazione predefinita, due vCPU condividono un core CPU fisico. Per carichi di lavoro altamente paralleli o che eseguono di calcoli in virgola mobile (come l'analisi della sequenza genetica e i il modello di rischio), puoi migliorare le prestazioni riducendo il numero di thread in esecuzione su ciascun core della CPU fisico. Per ulteriori informazioni, vedi Imposta il numero di thread per core.

Il multi-threading delle VM potrebbe avere implicazioni sulle licenze per alcune terze parti come i database. Per saperne di più, leggi la documentazione sulle licenze per il software di terze parti.

Network Service Tiers

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

  • Il livello Premium utilizza la rete backbone globale altamente affidabile di Google per aiutarti e ottenere una latenza e una perdita di pacchetti minime. Il traffico entra ed esce dalla la rete Google su un POP perimetrale globale vicino a per l'utente finale. Ti consigliamo di utilizzare il livello Premium come livello predefinito per per ottenere prestazioni ottimali.
  • Con il livello Standard, il traffico entra ed esce dalla rete Google a un POP perimetrale più vicino alla località Google Cloud in cui per l'esecuzione dei carichi di lavoro. Il prezzo del livello Standard è inferiore a quello del livello Premium. Il livello Standard è adatto al traffico non sensibile alla perdita di pacchetti e che non prevede requisiti di bassa latenza.

Ulteriori considerazioni sulle prestazioni

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

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: