Applicazione aziendale con Oracle Database su Compute Engine

Last reviewed 2025-05-27 UTC

Questo documento fornisce un'architettura di riferimento per aiutarti a creare l'infrastruttura per ospitare un'applicazione aziendale ad alta disponibilità che utilizza un database Oracle, con l'intero stack di deployment sulle VM di Compute Engine. Puoi utilizzare questa architettura di riferimento per eseguire il rehosting (lift and shift) in modo efficiente delle applicazioni on-premise che utilizzano database Oracle su Google Cloud. Questo documento include anche indicazioni per aiutarti a creare una topologia di Oracle Database inGoogle Cloud che soddisfi i requisiti dell'architettura di massima disponibilità (MAA) di Oracle. Il pubblico di destinazione di questo documento è costituito da architetti cloud e amministratori di database Oracle. Il documento presuppone che tu abbia familiarità con Compute Engine e Oracle Database.

Se utilizzi Oracle Exadata o Oracle Real Application Clusters (Oracle RAC) per eseguire database Oracle on-premise, puoi eseguire la migrazione in modo efficiente delle tue applicazioni a Google Cloud ed eseguire i tuoi database su Oracle Database@Google Cloud. Per ulteriori informazioni, vedi Applicazione aziendale su VM Compute Engine con Oracle Exadata in Google Cloud.

Architettura

Il seguente diagramma mostra l'infrastruttura per un'applicazione aziendale a più livelli che utilizza Oracle Database. I livelli web, applicazione e le istanze di Oracle Database sono ospitati su VM di Compute Engine. Il livello web e il livello applicazione vengono eseguiti in modalità active-active su VM distribuite in due zone all'interno di una Google Cloud regione. Le istanze del database primario e in standby vengono implementate in zone separate. Questa architettura è allineata all'archetipo di deployment regionale, che contribuisce a garantire che la topologia Google Cloud sia robusta contro interruzioni di una singola zona1.

Un'applicazione aziendale a più livelli utilizza Oracle Database su VM di Compute Engine.

L'architettura mostrata nel diagramma precedente include i seguenti componenti:

Componente Finalità
Bilanciatore del carico delle applicazioni esterno regionale Il bilanciatore del carico delle applicazioni esterno regionale riceve e distribuisce le richieste degli utenti alle VM del livello web.
Criterio di sicurezza di Google Cloud Armor I criteri di sicurezza di Google Cloud Armor contribuiscono a proteggere lo stack di applicazioni da minacce come attacchi distributed denial-of-service (DDoS) e cross-site scripting (XSS).
Gruppo di istanze gestite (MIG) regionale per il livello web Il livello web dell'applicazione viene eseguito il deployment su VM di Compute Engine che fanno parte di un MIG regionale. Questo MIG è il backend del bilanciatore del carico delle applicazioni esterno. Il MIG contiene VM Compute Engine in due zone. Ciascuna di queste VM ospita un'istanza indipendente del livello web dell'applicazione.
Bilanciatore del carico delle applicazioni interno regionale Il bilanciatore del carico delle applicazioni interno regionale distribuisce il traffico dalle VM del livello web alle VM del livello applicazione.
MIG regionale per il livello applicazione Il livello dell'applicazione, ad esempio un cluster Oracle WebLogic Server, viene eseguito il deployment sulle VM di Compute Engine che fanno parte di un MIG regionale. Questo MIG è il backend del bilanciatore del carico delle applicazioni interno. Il MIG contiene VM Compute Engine in due zone. Ogni VM ospita un'istanza indipendente del server delle applicazioni.
Istanze Oracle Database di cui è stato eseguito il deployment su VM di Compute Engine L'applicazione in questa architettura utilizza una coppia principale-standby di istanze Oracle Database di cui è stato eseguito il deployment su VM Compute Engine in zone separate. Porti le tue licenze (BYOL) per queste istanze di Oracle Database e gestisci le VM e le istanze di database.
Pool di archiviazione Hyperdisk Le VM in ogni zona (in tutti i livelli dello stack dell'applicazione) utilizzano volumi Hyperdisk bilanciato di un pool di archiviazione Hyperdisk. La creazione e la gestione di tutti i dischi in un unico pool di archiviazione ti consentono di migliorare l'utilizzo della capacità e ridurre la complessità operativa, mantenendo al contempo la capacità di archiviazione e le prestazioni necessarie alle VM.
Osservatore Oracle Data Guard FSFO L'osservatore Oracle Data Guard Fast-Start Failover (FSFO) è un programma leggero che avvia il failover automatico all'istanza Oracle Database di standby quando l'istanza principale non è disponibile. L'osservatore viene eseguito su una VM Compute Engine in una zona diversa da quelle in cui vengono implementate le istanze di database primario e in standby.
Bucket Cloud Storage Per archiviare i backup delle istanze di Oracle Database, questa architettura utilizza un bucket Cloud Storage. Per facilitare il recupero del database durante un'interruzione a livello di regione, puoi archiviare i backup con ridondanza geografica in un bucket multiregionale o dual-region.
Rete Virtual Private Cloud (VPC) e subnet Tutte le risorse Google Cloud nell'architettura utilizzano una singola rete VPC e subnet. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC o più subnet. Per ulteriori informazioni, consulta Decidere se creare più reti VPC.
Gateway Cloud NAT pubblico L'architettura include un gateway Cloud NAT pubblico per abilitare connessioni in uscita sicure dalle VM di Compute Engine che hanno solo indirizzi IP interni.
Cloud Interconnect e Cloud VPN Per connettere la rete on-premise alla rete VPC in Google Cloud, puoi utilizzare Cloud Interconnect o Cloud VPN. Per informazioni sui vantaggi relativi di ciascun approccio, consulta Scegliere un prodotto per la connettività di rete.
Cloud Monitoring e Cloud Logging Cloud Monitoring ti aiuta a osservare il comportamento, l'integrità e le prestazioni della tua applicazione e delle tue risorse. Google Cloud Ops Agent raccoglie metriche e log dalle VM Compute Engine, incluse le VM che ospitano le istanze di Oracle Database. L'agente invia i log a Cloud Logging e le metriche a Cloud Monitoring.

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.
  • Google Cloud Hyperdisk: un servizio di archiviazione di rete che puoi utilizzare per eseguire il provisioning e scalare dinamicamente i volumi di archiviazione a blocchi con prestazioni configurabili e prevedibili.
  • Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
  • Cloud Storage: uno spazio di archiviazione di oggetti a basso costo e senza limiti per diversi tipi di dati. I dati sono accessibili dall'interno e dall'esterno di Google Cloude vengono replicati in più località per la ridondanza.
  • Virtual Private Cloud (VPC): un sistema virtuale che fornisce funzionalità di rete globali e scalabili per i tuoi Google Cloud carichi di lavoro. VPC include il peering di rete VPC, Private Service Connect, l'accesso privato ai servizi e VPC condiviso.
  • Google Cloud Armor: un servizio di sicurezza di rete che offre regole WAF (web application firewall) e contribuisce a proteggere da attacchi DDoS e alle applicazioni.
  • Cloud NAT: un servizio che fornisce Network Address Translation ad alte prestazioni gestita da Google Cloud.
  • Cloud Monitoring: un servizio che offre visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e della tua infrastruttura.
  • Cloud Logging: un sistema di gestione dei log in tempo reale con archiviazione, ricerca, analisi e avvisi.
  • Cloud Interconnect: un servizio che estende la tua rete esterna alla rete Google tramite una connessione a disponibilità elevata e a bassa latenza.
  • Cloud VPN: un servizio che estende in modo sicuro la tua rete peer alla rete di Google tramite un tunnel VPN IPsec.

Questa architettura di riferimento utilizza i seguenti prodotti Oracle:

  • Oracle Database: un sistema di gestione di database relazionali (RDBMS) che estende il modello relazionale a un modello relazionale a oggetti.
  • Oracle Data Guard: un insieme di servizi per creare, mantenere, gestire e monitorare uno o più database di standby.

È tua responsabilità procurarti le licenze per i prodotti Oracle che implementi in Google Clouded è tua responsabilità rispettare i termini e le condizioni delle licenze Oracle.

Note sul layout

Questa sezione descrive i fattori di progettazione, le best practice e i consigli di progettazione da prendere in considerazione quando utilizzi questa architettura di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici di sicurezza, affidabilità, efficienza operativa, costi e prestazioni.

Le indicazioni in questa sezione non sono esaustive. A seconda dei requisiti specifici della tua applicazione e dei prodotti e delle funzionalità di terze parti che utilizzi, potrebbero esserci ulteriori fattori di progettazione e compromessi da prendere in considerazione. Google Cloud

Progettazione del sistema

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

Selezione delle regioni

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

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

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

Infrastruttura di calcolo

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

  • Container: puoi eseguire applicazioni containerizzate nei cluster Google Kubernetes Engine (GKE). GKE è un motore di orchestrazione dei container che automatizza il deployment, la scalabilità e la gestione delle applicazioni containerizzate.
  • Serverless: se preferisci concentrare i tuoi sforzi IT su dati e applicazioni anziché configurare e gestire risorse dell'infrastruttura, puoi utilizzare servizi serverless come Cloud Run.

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

Opzioni di archiviazione

L'architettura mostrata in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona, con volumi Hyperdisk bilanciato per le VM in tutti i livelli. I volumi Hyperdisk offrono prestazioni, flessibilità ed efficienza migliori rispetto a Persistent Disk. Per informazioni sui tipi e sulle funzionalità di Hyperdisk, consulta Informazioni su Hyperdisk bilanciato.

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

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

Progettazione di rete

Quando crei l'infrastruttura per uno stack di applicazioni multilivello, devi scegliere una progettazione di rete che soddisfi i tuoi requisiti aziendali e tecnici. L'architettura mostrata in questo documento utilizza una topologia di rete semplice con una singola rete VPC e subnet. A seconda dei tuoi requisiti, puoi scegliere di utilizzare più reti VPC o più subnet. Per saperne di più, consulta la seguente documentazione:

Sicurezza, privacy e conformità

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

Protezione contro le minacce esterne

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

Accesso esterno per le VM

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

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

Privilegi del service account

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

Sicurezza SSH

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

Crittografia del disco

Per impostazione predefinita, i dati archiviati nei volumi Hyperdisk vengono criptati utilizzando Google-owned and Google-managed encryption keys. Come ulteriore livello di protezione, puoi scegliere di criptare le chiavi di crittografia dei dati di proprietà di Google utilizzando chiavi di tua proprietà e gestite in Cloud Key Management Service (Cloud KMS). Per saperne di più, vedi Informazioni sulla crittografia dei dischi.

Sicurezza della rete

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

Altre considerazioni sulla sicurezza

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

Affidabilità

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

Robustezza contro gli errori delle VM

Nell'architettura mostrata in questo documento, se una VM di Compute Engine in uno qualsiasi dei livelli non funziona, l'applicazione può continuare a elaborare le richieste.

  • Se una VM nel livello web o nel livello applicazione si arresta in modo anomalo, il MIG pertinente la ricrea automaticamente. I bilanciatori del carico inoltrano le richieste solo alle istanze del server web e del server delle applicazioni attualmente disponibili.
  • Se la VM che ospita l'istanza del database Oracle principale non funziona, l'osservatore Oracle Data Guard FSFO avvia un failover automatico sull'istanza del database Oracle di standby.

Riparazione automatica delle VM

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

Robustezza contro le interruzioni di zona

In caso di interruzione di una zona, l'applicazione rimane disponibile.

  • Il livello web e il livello applicazione sono disponibili (e reattivi) perché le VM si trovano in MIG regionali. I MIG di regione assicurano che le nuove VM vengano create automaticamente nell'altra zona per mantenere il numero minimo di VM configurato. I bilanciatori del carico inoltrano le richieste alle VM del server web e alle VM del server delle applicazioni disponibili.
  • Se un'interruzione interessa la zona che contiene l'istanza principale di Oracle Database, l'osservatore FSFO di Oracle Data Guard avvia un failover automatico all'istanza di standby di Oracle Database. L'osservatore FSFO viene eseguito su una VM in una zona diversa da quelle che contengono le istanze di database primarie e in standby.
  • Per garantire l'alta affidabilità dei dati nei volumi Hyperdisk durante un'interruzione di una singola zona, puoi utilizzare Hyperdisk bilanciato ad alta affidabilità. Quando i dati vengono scritti in un volume, vengono replicati in modo sincrono tra due zone nella stessa regione.

Robustezza contro le interruzioni a livello di regione

Se si verifica un'interruzione del servizio in entrambe le zone dell'architettura o in una regione, l'applicazione non è disponibile. Per ridurre i tempi di inattività causati da interruzioni multizona o regionali, puoi implementare il seguente approccio:

  • Mantieni una replica passiva (failover) dello stack dell'infrastruttura in un'altra Google Cloud regione.

  • Utilizza un bucket Cloud Storage con due regioni o più regioni per archiviare i backup di Oracle Database. I backup vengono replicati in modo asincrono in almeno due località geografiche. Con i backup del database replicati, la tua architettura corrisponde al livello Silver di Maximum Availability Architecture (MAA) di Oracle.

    Per ottenere una replica più rapida dei backup archiviati nei bucket in due regioni, puoi utilizzare la replica turbo. Per ulteriori informazioni, vedi Disponibilità e durabilità dei dati.

  • Se si verifica un'interruzione nella regione primaria, utilizza il backup del database per ripristinare il database e attivare l'applicazione nella regione di failover. Utilizza policy di routing DNS per instradare il traffico al bilanciatore del carico nella regione di failover.

Per le applicazioni business-critical che devono continuare a essere disponibili anche in caso di interruzione di una regione, valuta la possibilità di utilizzare l'archetipo di deployment multiregionale. Per il livello del database, puoi utilizzare Oracle Active Data Guard FSFO per eseguire automaticamente il failover a un'istanza di database Oracle di standby nella regione di failover. Questo approccio corrisponde al livello Gold di MAA di Oracle.

Scalabilità automatica del gruppo di istanze gestite

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

Limite di dimensioni del MIG

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

Posizionamento delle VM

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

Pianificazione della capacità delle VM

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

Disponibilità dell'archiviazione a blocchi

L'architettura descritta in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona per fornire spazio di archiviazione a blocchi per le VM Compute Engine. Crea un pool di capacità di archiviazione a blocchi per una zona. Poi crei i volumi Hyperdisk nel pool di archiviazione e li colleghi alle VM nella zona. Il pool di archiviazione tenta di aggiungere capacità automaticamente per garantire che il tasso di utilizzo non superi l'80% della capacità sottoposta a provisioning del pool. Questo approccio garantisce che lo spazio di archiviazione a blocchi sia disponibile quando necessario. Per saperne di più, consulta Come funzionano i pool di archiviazione Hyperdisk.

Archiviazione stateful

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

Backup e ripristino

L'architettura descritta in questo documento utilizza Cloud Storage per archiviare i backup del database. Se scegli il tipo di località a due regioni o multiregionale per il bucket Cloud Storage, i backup vengono replicati in modo asincrono in almeno due località geografiche. In caso di interruzione a livello di regione, puoi utilizzare i backup per ripristinare il database in un'altra regione. Con un bucket in due regioni, puoi ottenere una replica più rapida attivando l'opzione di replica turbo. Per ulteriori informazioni, vedi Disponibilità e durabilità dei dati.

Puoi utilizzare il servizio di Backup e DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Il servizio di backup e DR archivia i dati di backup nel formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i carichi di lavoro in produzione utilizzando direttamente i dati dell'archiviazione di backup a lungo termine senza attività di preparazione o spostamento dei dati che richiedono molto tempo. Per saperne di più, consulta la seguente documentazione:

Ulteriori considerazioni sull'affidabilità

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

Ottimizzazione dei costi

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

Tipi di macchine VM

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

Modello di provisioning delle VM

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

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

Utilizzo delle risorse della VM

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

Licenze Oracle Database

È tua responsabilità procurarti le licenze per i prodotti Oracle che deploy su Compute Engine ed è tua responsabilità rispettare i termini e condizioni delle licenze Oracle. Quando calcoli il costo della licenza del database Oracle, considera il numero di licenze del processore Oracle necessarie in base al tipo di macchina scelto per le VM Compute Engine che ospitano le istanze del database Oracle. Per ulteriori informazioni, consulta la pagina Licensing Oracle Software in the Cloud Computing Environment.

Utilizzo delle risorse di archiviazione a blocchi

L'architettura descritta in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona per fornire spazio di archiviazione a blocchi per le VM Compute Engine. Puoi migliorare l'utilizzo complessivo della capacità di archiviazione a blocchi e ridurre i costi utilizzando i pool di archiviazione Capacità avanzata, che utilizzano le tecnologie di thin provisioning e di riduzione dei dati per migliorare l'efficienza dello spazio di archiviazione.

Altre considerazioni sui costi

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

Efficienza operativa

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

Aggiornamenti della configurazione delle VM

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

Immagini VM

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

Modelli di istanza deterministici

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

Gestione dell'archiviazione a blocchi

L'architettura descritta in questo documento utilizza un pool di archiviazione Hyperdisk in ogni zona per fornire spazio di archiviazione a blocchi per le VM Compute Engine. I pool di archiviazione Hyperdisk semplificano la gestione dello spazio di archiviazione. Anziché allocare e gestire la capacità individualmente per numerosi dischi, definisci un pool di capacità che può essere condiviso tra più workload in una zona. Poi crei i volumi Hyperdisk nel pool di archiviazione e li colleghi alle VM nella zona. Il pool di archiviazione tenta di aggiungere capacità automaticamente per garantire che il tasso di utilizzo non superi l'80% della capacità sottoposta a provisioning del pool.

Connettività dal server delle applicazioni al database

Per le connessioni dalla tua applicazione a Oracle Database, ti consigliamo di utilizzare il nome DNS interno di zona della VM del database anziché il suo indirizzo IP. Google Cloud risolve automaticamente il nome DNS nell'indirizzo IP interno principale della VM. Un ulteriore vantaggio di questo approccio è che non è necessario prenotare e assegnare indirizzi IP interni statici per le VM di database.

Amministrazione e supporto del database Oracle

Quando esegui un'istanza di Oracle Database autogestita su una VM Compute Engine, ci sono preoccupazioni operative simili a quando esegui Oracle Database on-premise. Tuttavia, con una VM di Compute Engine non devi più gestire l'infrastruttura sottostante di calcolo, networking e archiviazione.

Ulteriori considerazioni operative

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

Ottimizzazione delle prestazioni

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

Rendimento del calcolo

Compute Engine offre un'ampia gamma di tipi di macchine predefiniti e personalizzabili che puoi scegliere in base ai requisiti di prestazioni dei tuoi carichi di lavoro.

  • Per le VM che ospitano il livello web e il livello applicazione, scegli un tipo di macchina appropriato in base ai requisiti di prestazioni per questi livelli. Per ottenere un elenco dei tipi di macchine disponibili che supportano i volumi Hyperdisk e che soddisfano i tuoi requisiti di prestazioni e altri requisiti, utilizza la tabella Confronto tra le serie di macchine.
  • Per le VM che ospitano le istanze di Oracle Database, ti consigliamo di utilizzare un tipo di macchina della serie di macchine C4 della famiglia di macchine per uso generico. I tipi di macchine C4 offrono prestazioni costantemente elevate per i carichi di lavoro di database.

Multi-threading della VM

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

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

Prestazioni di rete

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

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

Prestazioni di archiviazione Hyperdisk

L'architettura descritta in questo documento utilizza volumi Hyperdisk per le VM in tutti i livelli. Hyperdisk ti consente di scalare dinamicamente le prestazioni e la capacità. Puoi modificare le IOPS, il throughput e le dimensioni di cui è stato eseguito il provisioning di ogni volume in base alle esigenze di prestazioni e capacità di archiviazione del tuo workload. Le prestazioni dei volumi Hyperdisk dipendono dal tipo di Hyperdisk e dal tipo di macchina delle VM a cui sono collegati i volumi. Per ulteriori informazioni sui limiti di prestazioni e sull'ottimizzazione di Hyperdisk, consulta la seguente documentazione:

Altre considerazioni sul rendimento

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

Passaggi successivi

Collaboratori

Autori:

Altri collaboratori:

  1. Per saperne di più sulle considerazioni specifiche per le regioni, consulta Area geografica e regioni.  ↩