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 che viene eseguito su VM di Compute Engine in più zone all'interno di un Google Cloud regione. Puoi utilizzare questa architettura di riferimento per 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 e creare un'architettura regionale per le tue applicazioni cloud. Il pubblico di destinazione per questo documento sono Cloud Architect.

Architettura

Il seguente diagramma mostra un'architettura per un'applicazione in esecuzione attiva/attiva in stack isolati il cui deployment viene eseguito in tre zone di Google Cloud all'interno di una regione. L'architettura è in linea con archetipo di deployment regionale, per garantire che la tua topologia Google Cloud sia affidabile contro le zone o in caso di interruzione del servizio.

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 cloud IaaS (Infrastructure as a Service) un modello di machine learning. Esegui il provisioning delle risorse di infrastruttura richieste (computing, networking, e archiviazione) in Google Cloud. L'utente mantiene il controllo completo infrastruttura e la responsabilità per il sistema operativo, il middleware ai livelli più alti dello stack di applicazioni. Per saperne di più su IaaS e altre tecnologie di machine learning, 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 ulteriori informazioni, vedi Scegli un bilanciatore del carico.

A livello di regione gruppo di istanze gestite 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 regione. Il gruppo di istanze gestite è il backend per il bilanciatore del carico esterno regionale.

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

Bilanciatore del carico interno a livello di regione

Il bilanciatore del carico interno a livello di regione distribuisce il traffico dai 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, vedi Scegli un bilanciatore del carico.

Gruppo di istanze gestite a livello di regione 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 regione, ovvero il backend con il bilanciatore del carico interno.

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

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 (ad esempio PostgreSQL) di cui è stato eseguito il deployment su una VM di Compute Engine. Tu può eseguire il deployment di un database in standby in un'altra zona. Il database le capacità di replica e failover dipendono dal database che per gli utilizzi odierni.

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 ulteriori informazioni informazioni sulle opzioni di database gestito, vedi Servizi di database più avanti in questa guida.

rete VPC (Virtual Private Cloud) e . una 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 ulteriori informazioni, vedi Decidere se creare più reti VPC nella sezione "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 una doppia regione nel bucket Cloud Storage. In caso di interruzione di una zona o di una regione, l'applicazione e i dati non vadano persi.

In alternativa, puoi utilizzare 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 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 a livello di regione Compute Engine è una scelta appropriata.

Migrazione efficiente delle applicazioni on-premise

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

Applicazione a disponibilità elevata con utenti all'interno di un'area geografica

Consigliamo un'architettura di deployment regionale per le applicazioni che necessitano robustezza contro le interruzioni di zona, ma è in grado di tollerare alcuni tempi di inattività causati dalla regione o in caso di interruzione del servizio. Se si verifica un errore in una qualsiasi parte dello stack di applicazioni, l'applicazione continua se è presente almeno un componente funzionante con capacità adeguata in per ogni livello. In caso di interruzione di una zona, lo stack di applicazioni continua a essere eseguito nelle altre zone.

Bassa latenza per gli utenti delle applicazioni

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

Networking a bassa latenza tra i componenti dell'applicazione

Un'architettura a una singola regione potrebbe essere adatta per applicazioni come che richiedono connessioni di rete a bassa latenza e a larghezza di banda elevata tra i nodi di computing. Tutte le risorse si trovano in un unico ambiente Google Cloud regione, in modo che il traffico di rete tra risorse rimanga all'interno della regione. La la latenza di rete tra risorse è bassa e non ti vengono addebitati dati tra regioni costi di trasferimento. Si applicano comunque i costi di rete all'interno delle regioni.

Conformità ai requisiti di residenza dei dati

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

Note sul layout

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

Progettazione del sistema

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

Selezione delle regioni

Quando scegli una regione Google Cloud per le tue applicazioni, considera la 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 ulteriori 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. Per Ad esempio, la regione più conveniente potrebbe non avere il impronta di carbonio.

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 Funzioni di Cloud Run.

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 ulteriori informazioni informazioni sulla scelta dei servizi di computing appropriati per i carichi di lavoro in per Google Cloud, consulta Hosting di applicazioni su Google Cloud nel framework dell'architettura 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 in 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 Istanza Filestore Enterprise. 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 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 regionali, considera il funzionamento caratteristiche dei carichi di lavoro, requisiti di resilienza, prestazioni le aspettative e gli obiettivi di costo. Per ulteriori informazioni, vedi Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud.

Servizi di database

L'architettura di riferimento in questo documento utilizza un database di terze parti, come PostgreSQL di cui è stato eseguito il deployment sulle VM di Compute Engine. L'installazione e la gestione di un database di terze parti 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 regionale 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 attacchi DDoS (Denial of Service) 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 ulteriori 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 alle 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 Progetto della piattaforma di sicurezza.

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

Interruzioni dell'infrastruttura

In un'architettura regionale, se sono presenti singoli componenti dell'infrastruttura lo stack ha esito negativo, l'applicazione può elaborare le richieste se almeno uno con capacità adeguata sia presente in ogni livello. Ad esempio, se un sito web un errore dell'istanza del server, il bilanciatore del carico inoltra le richieste dell'utente all'altra di Compute Engine disponibili. Se una VM che ospita un server web o un server di app l'istanza ha un arresto anomalo, Il gruppo di istanze gestite ricrea la VM automaticamente.

Se si verifica un'interruzione in una zona, il bilanciatore del carico non è interessato, perché si tratta di un di risorsa di regione. L'interruzione di una zona può interessare singoli istanze di Compute Engine delle VM in esecuzione. Ma l'applicazione rimane disponibile e reattiva perché le VM si trovano un gruppo di istanze gestite a livello di regione. Un gruppo di istanze gestite a livello di regione garantisce la creazione automatica di nuove VM il numero minimo configurato di VM. Dopo che Google risolve la zona devi verificare che l'applicazione venga eseguita come previsto in tutte le zone in cui viene eseguito il deployment.

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

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

Per le applicazioni che richiedono robustezza contro le interruzioni della regione, valuta l'utilizzo un'architettura multiregionale. Per ulteriori informazioni, vedi Deployment multiregionale su Compute Engine.

Scalabilità automatica MIG

Quando esegui l'applicazione sulle VM in un gruppo di istanze gestite a livello di regione, l'applicazione rimane disponibile durante le interruzioni di una zona isolata. La funzionalità di scalabilità automatica I gruppi di istanze gestite consentono di mantenere disponibilità e prestazioni delle applicazioni a livelli prevedibili diversi. 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.

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 di livello base, vengono eseguite su VM di Compute Engine distribuite su più diverse. Questa distribuzione garantisce che l'applicazione sia robusta contro le zone o in caso di interruzione del servizio. 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, posiziona le VM all'interno di ciascuna zona su diversi server fisici (chiamati host), in modo che le tue VM affidabile contro gli 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 è evitare la necessità di un client stateful 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 facilmente 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 la modalità 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 utilizzi un database di terze parti e backup del database e log delle transazioni, puoi usare l'impostazione di archiviazione dei bucket Cloud Storage. I bucket Cloud Storage a livello di regione basso costo spazio di archiviazione di backup ridondante nelle varie zone.

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

  • Puoi utilizzare la modalità snapshot per acquisire lo stato point-in-time dei volumi Persistent Disk. Standard vengono archiviati in modo ridondante in più regioni, con per garantire l'integrità dei dati. Gli snapshot sono incrementali per impostazione predefinita, quindi occupano meno spazio di archiviazione e tu potrai 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 consentono di eseguire applicazioni a disponibilità elevata che non sono 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 regione 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 un progetto Google Cloud a livello di regione che puoi 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 regionale 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 Famiglia di macchine ottimizzate per l'acceleratore 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 con 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 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: