Applicazione aziendale su Compute Engine con Oracle Exadata

Last reviewed 2025-08-18 UTC

Questo documento fornisce un'architettura di riferimento per un'applicazione aziendale ad alta disponibilità ospitata su macchine virtuali (VM) Compute Engine con connettività a bassa latenza ai database Exadata di Oracle Cloud Infrastructure (OCI) in esecuzione in Google Cloud. Il pubblico di destinazione di questo documento è costituito da cloud architect e amministratori di database Oracle. Il documento presuppone che tu abbia familiarità con Compute Engine e Oracle Exadata Database Service.

Se utilizzi Oracle Exadata o Oracle Real Application Clusters (Oracle RAC) per eseguire database Oracle on-premise, puoi eseguire la migrazione delle tue applicazioni in modo efficiente a Google Cloud ed eseguire i tuoi database su Oracle Database@Google Cloud. Oracle Database@Google Cloud è un'offerta di Google Cloud Marketplace che ti consente di eseguire Oracle Exadata Database Service e Oracle Autonomous Database direttamente all'interno di Google Cloud.

Se non hai bisogno della funzionalità Oracle RAC o se hai bisogno di una versione di Oracle Database diversa da 19c e 23ai, puoi eseguire database Oracle autogestiti su VM Compute Engine. Per saperne di più, consulta Applicazione aziendale con Oracle Database su Compute Engine.

Architettura

Il seguente diagramma mostra una visione generale dell'architettura:

Una visione di alto livello di un'architettura che utilizza Oracle Database@Google Cloud.

Nel diagramma precedente, un bilanciatore del carico esterno riceve richieste dagli utenti di un'applicazione rivolta al pubblico e le distribuisce ai server web frontend. I server web inoltrano le richieste degli utenti tramite un bilanciatore del carico interno ai server delle applicazioni. I server delle applicazioni leggono i dati dai database e scrivono in questi database in Oracle Database@Google Cloud. Gli amministratori e i servizi OCI possono connettersi e interagire con i database Oracle.

Il seguente diagramma mostra una visualizzazione dettagliata dell'architettura:

Una visualizzazione dettagliata di un'architettura che utilizza Oracle Database@Google Cloud.

In questa architettura, i livelli web e applicazione vengono eseguiti in modalità active-active su VM Compute Engine distribuite in due zone all'interno di una Google Cloud regione. L'applicazione utilizza database Oracle Exadata nella stessa regione Google Cloud.

Tutti i componenti dell'architettura si trovano in una singola regione Google Cloud. Questa architettura è in linea con l'archetipo di deployment regionale. Puoi adattare questa architettura per creare una topologia robusta contro le interruzioni regionali utilizzando l'archetipo di deployment multiregionale. Per saperne di più, consulta Deployment multiregionale su Compute Engine e anche le indicazioni nella sezione Affidabilità più avanti in questo documento.

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

Componente Purpose
Bilanciatore del carico delle applicazioni esterno regionale Il bilanciatore del carico delle applicazioni esterno regionale riceve le richieste degli utenti e le distribuisce alle VM del livello web.
Criterio di sicurezza di Google Cloud Armor I criteri di sicurezza di Cloud Armor contribuiscono a proteggere lo stack di applicazioni da minacce come attacchi DDoS (Distributed Denial of Service) 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 Compute Engine che fanno parte di un gruppo di istanze gestite a livello di regione. 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 applicazione, ad esempio un cluster Oracle WebLogic Server, viene eseguito il deployment su VM 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.
Rete Virtual Private Cloud (VPC) e subnet Tutte le risorse Google Cloud dell'architettura utilizzano una singola rete VPC. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti. Per ulteriori informazioni, consulta Decidere se creare più reti VPC.
Oracle Database@Google Cloud

I server delle applicazioni leggono i dati dai database Oracle e scrivono in questi database in Oracle Exadata Database Service. Esegui il provisioning di Oracle Exadata Database Service utilizzando Oracle Database@Google Cloud, un'offerta di Cloud Marketplace che ti consente di eseguire database Oracle su hardware gestito da Oracle all'interno di un data center. Google Cloud

Utilizzi interfacce Google Cloud come la console Google Cloud , Google Cloud CLI e le API per creare istanze di infrastruttura Exadata. Oracle configura e gestisce l'infrastruttura di calcolo, archiviazione e networking richiesta in un data center all'interno di una regione Google Cloud su hardware dedicato al tuo progetto.

Istanze di infrastruttura Exadata Ogni istanza di Exadata Infrastructure contiene due o più server di database fisici e tre o più server di archiviazione. Questi server, che non sono mostrati nel diagramma, sono interconnessi tramite un fabric di rete a bassa latenza. Quando crei un'istanza di infrastruttura Exadata, specifichi il numero di server di database e server di archiviazione di cui deve essere eseguito il provisioning.
Cluster di VM Exadata

All'interno di un'istanza dell'infrastruttura Exadata, crei uno o più cluster di VM Exadata. Ad esempio, puoi scegliere di creare e utilizzare un cluster di VM Exadata separato per ospitare i database necessari per ciascuna delle tue unità aziendali. Ogni cluster di VM Exadata contiene una o più VM Oracle Linux che ospitano istanze di Oracle Database.

Quando crei un cluster di VM Exadata, specifica quanto segue:

  • Il numero di server di database.
  • La capacità di calcolo, memoria e archiviazione da allocare a ogni VM nel cluster.
  • La rete VPC a cui deve connettersi il cluster.
  • Intervalli di indirizzi IP delle subnet di backup e client per il cluster.

Le VM all'interno dei cluster di VM Exadata non sono VM Compute Engine.

Istanze Oracle Database Puoi creare e gestire i database Oracle tramite la console OCI e altre interfacce OCI. Il software Oracle Database viene eseguito sulle VM all'interno del cluster di VM Exadata. Quando crei il cluster di VM Exadata, specifichi la versione di Oracle Grid Infrastructure. Puoi anche scegliere il tipo di licenza: Bring Your Own License (BYOL) o optare per il modello con licenza inclusa.
VCN OCI e subnet Quando crei un cluster di VM Exadata, viene creata automaticamente una rete cloud virtuale (VCN) OCI. Il VCN ha una subnet client e una subnet di backup con intervalli di indirizzi IP specificati. La subnet client viene utilizzata per la connettività dalla rete VPC ai database Oracle. La subnet di backup viene utilizzata per inviare i backup del database a OCI Object Storage.
Router Cloud, Partner Interconnect, e DRG OCI Il traffico tra la tua rete VPC e la VCN viene instradato da un router Cloud collegato al VPC e tramite un gateway di routing dinamico (DRG) collegato alla VCN. Il traffico fluisce attraverso una connessione a bassa latenza configurata da Google utilizzando Partner Interconnect.
Zona Cloud DNS privata Quando crei un cluster di VM Exadata, viene creata automaticamente una zona privata di Cloud DNS. Quando i server delle applicazioni inviano richieste di lettura e scrittura ai database Oracle, Cloud DNS risolve i nomi host del database negli indirizzi IP corrispondenti.
OCI Object Storage e OCI Service Gateway Per impostazione predefinita, i backup dei database Oracle Exadata vengono archiviati in OCI Object Storage. I backup del database vengono indirizzati a OCI Object Storage tramite un service gateway.
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 ogni approccio, consulta Scegliere un prodotto per la connettività di rete.
Cloud Monitoring Puoi utilizzare Cloud Monitoring per osservare il comportamento, l'integrità e le prestazioni della tua applicazione e delle tue risorse, incluse le risorse Oracle Exadata. Google Cloud Puoi anche monitorare le risorse nelle risorse Oracle Exadata utilizzando il servizio OCI 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.
  • Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
  • 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 Interconnect: un servizio che estende la tua rete esterna alla rete Google tramite una connessione a disponibilità elevata e a bassa latenza.
  • Partner Interconnect: un servizio che fornisce connettività tra la tua rete on-premise e le tue reti Virtual Private Cloud e altre reti tramite un provider di servizi supportato.
  • 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 OCI:

  • Exadata Database Service su infrastruttura dedicata: un servizio che ti consente di eseguire istanze di Oracle Database su hardware Exadata dedicato.
  • Object Storage: un servizio per l'archiviazione di grandi quantità di dati strutturati e non strutturati come oggetti.
  • VCN e subnet: una VCN è una rete virtuale e privata per le risorse in una regione OCI. Una subnet è un intervallo contiguo di indirizzi IP con un VCN.
  • Gateway di routing dinamico: un router virtuale per il traffico tra un VCN e reti esterne.
  • Service Gateway: un gateway che consente alle risorse in un VCN di accedere privatamente a servizi Oracle specifici.

Considerazioni sulla progettazione

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 riportate 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 in 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 sui dati e sulle applicazioni anziché configurare e gestire le 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 workload in Google Cloud, consulta Hosting di applicazioni su Google Cloud.

Opzioni di archiviazione

Per le VM Compute Engine nell'architettura, puoi utilizzare Hyperdisk o Persistent Disk come volumi di avvio. I volumi Hyperdisk offrono prestazioni, flessibilità ed efficienza migliori rispetto a Persistent Disk. Con Hyperdisk Balanced, puoi eseguire il provisioning di IOPS e throughput separatamente e dinamicamente, il che ti consente di ottimizzare il volume per un'ampia gamma di workload.

Per archiviare i file binari dell'applicazione, utilizza Filestore. I file archiviati in un'istanza Filestore regionale vengono replicati in modo sincrono in tre zone all'interno della regione. Questa replica contribuisce a garantire l'alta disponibilità e la robustezza in caso di interruzioni della zona. Per una maggiore robustezza contro le interruzioni del servizio nelle regioni, puoi replicare un'istanza Filestore in una regione diversa. Per maggiori informazioni, consulta Replica delle istanze.

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ù, vedi Progetta una strategia di archiviazione ottimale per il tuo carico di lavoro cloud.

Progettazione di rete Oracle Database@Google Cloud

Scegli un design di rete che soddisfi i tuoi requisiti aziendali e tecnici. Ad esempio, puoi utilizzare una singola rete VPC o più reti VPC. Per ulteriori informazioni, vedi Scopri di più sulla selezione delle topologie di rete per Oracle Database@Google Cloud.

Quando assegni gli intervalli di indirizzi IP per le subnet client e di backup da utilizzare per i cluster di VM Exadata, tieni presente i requisiti minimi per le dimensioni della subnet. Per maggiori informazioni, consulta Pianificare lo spazio degli indirizzi IP in Oracle Database@Google Cloud.

Migrazione del database

Quando pianifichi di eseguire la migrazione dei database on-premise a Oracle Database@Google Cloud, valuta l'ambiente di database attuale e ricevi consigli su configurazione e dimensionamento utilizzando lo strumento Database Migration Assessment (DMA).

Per informazioni sulla procedura e sugli strumenti che puoi utilizzare per eseguire la migrazione dei database Oracle a Google Cloud, consulta la Guida ai metodi di migrazione di Oracle.

Prima di utilizzare i database di cui è stata eseguita la migrazione in un ambiente di produzione, verifica la connettività dalle tue applicazioni ai database.

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, privacy 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 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 maggiori informazioni, consulta 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

Per le subnet utilizzate dalle VM Exadata, Oracle consiglia di assegnare intervalli di indirizzi IP privati.

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. L'account di servizio predefinito dispone di un'ampia gamma di autorizzazioni, tra cui alcune che potrebbero non essere necessarie. Puoi personalizzare i service account dedicati in modo che dispongano solo delle autorizzazioni essenziali. Per saperne di più, consulta Limitare i account di servizio account.

Sicurezza SSH

Per migliorare la sicurezza delle connessioni SSH alle VM di Compute Engine nella tua architettura, implementa Identity-Aware Proxy (IAP) e l'API Cloud OS Login. IAP ti consente di controllare l'accesso alla rete in base all'identità utente e alle policy 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 maggiori informazioni sulla gestione dell'accesso alla rete, consulta Best practice per il controllo dell'accesso al login SSH.

Crittografia dei dati

Per impostazione predefinita, i dati archiviati in Hyperdisk, Persistent Disk e Filestore vengono criptati utilizzandoGoogle-owned and Google-managed encryption keys. Come ulteriore livello di protezione, puoi scegliere di criptare Google-owned and managed key utilizzando chiavi di tua proprietà e gestite in Cloud Key Management Service (Cloud KMS). Per saperne di più, consulta Informazioni sulla crittografia del disco per i volumi Hyperdisk e Persistent Disk e Criptare i dati con chiavi di crittografia gestite dal cliente per Filestore.

Per impostazione predefinita, i database Exadata utilizzano Transparent Data Encryption (TDE), che consente di criptare i dati sensibili archiviati in tabelle e tablespace.

Sicurezza della rete

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

Sicurezza e conformità di Oracle Exadata

Oracle Exadata Database Service include Oracle Data Safe, che ti aiuta a gestire i requisiti di sicurezza e conformità per i database Oracle. Puoi utilizzare Oracle Data Safe per valutare i controlli di sicurezza, monitorare attività utente e mascherare i dati sensibili. Per saperne di più, consulta Gestire la sicurezza del database con Oracle Data Safe.

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 Compute Engine nel livello web o nel livello applicazione si arresta in modo anomalo, il MIG pertinente ricrea automaticamente la VM. I bilanciatori del carico inoltrano le richieste solo alle istanze del server web e del server delle applicazioni disponibili.

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 della riparazione automatica, consulta Informazioni sulla riparazione delle VM per l'alta affidabilità.

Robustezza contro le interruzioni a livello di regione

Se si verifica un'interruzione a livello di regione, l'applicazione non è disponibile. Per ridurre i tempi di inattività causati da interruzioni a livello di regione, puoi implementare il seguente approccio:

  • Mantieni una replica passiva (di failover) del livello web e del livello applicazione in un'altra regione Google Cloud .
  • Crea un'istanza di Exadata Infrastructure di standby con i cluster di VM Exadata richiesti nella stessa regione in cui si trova la replica passiva dello stack di applicazioni. Utilizza Oracle Data Guard per la replica dei dati e il failover automatico ai database Exadata di standby. Se la tua applicazione richiede un Recovery Point Objective (RPO) inferiore, puoi eseguire il backup e il recupero dei database utilizzando Oracle Autonomous Recovery Service.
  • Se si verifica un'interruzione del servizio nella regione principale, utilizza la replica del database o il backup per ripristinare il database in produzione e per attivare l'applicazione nella regione di failover.
  • Utilizza i criteri di routing DNS per instradare il traffico a un bilanciatore del carico esterno 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. Puoi utilizzare Oracle Active Data Guard per fornire un database di standby di sola lettura nella regione di failover.

Oracle gestisce l'infrastruttura in Oracle Database@Google Cloud. Per informazioni sugli obiettivi del livello di servizio (SLO) per Oracle Exadata Database Service su infrastruttura dedicata, consulta Obiettivi del livello di servizio per i servizi cloud pubblici PaaS e IaaS di Oracle.

Scalabilità automatica del gruppo di istanze gestite

L'architettura descritta in questo documento utilizza i MIG a livello di regione per il livello web e il livello applicazione. La funzionalità di scalabilità automatica dei MIG stateless garantisce che le VM di Compute Engine che ospitano il livello web e il livello applicazione non siano interessate da interruzioni di una singola zona.

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 ulteriori informazioni, consulta Scalabilità automatica dei gruppi di istanze.

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 saperne di più, consulta Aggiungi e rimuovi VM da un MIG.

Posizionamento della VM

Nell'architettura descritta in questo documento, il livello applicazione e il livello web vengono eseguiti su VM Compute Engine distribuite in più zone. Questa distribuzione contribuisce a garantire che il livello web e il livello applicazione siano robusti contro le interruzioni di una singola zona.

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

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 saperne di più, consulta Configurazione dei dischi permanenti stateful nei MIG.

Capacità di Oracle Exadata

Puoi scalare l'infrastruttura Exadata aggiungendo server di database e server di archiviazione in base alle esigenze. Dopo aver aggiunto i server di database o di archiviazione richiesti all'infrastruttura Exadata, per poter utilizzare le risorse di CPU o di archiviazione aggiuntive, devi aggiungere la capacità al cluster VM Exadata associato. Per ulteriori informazioni, vedi Scalabilità di Compute e Storage Exadata.

Durabilità dei dati

Puoi utilizzare il servizio di Backup e DR per creare, archiviare e gestire i backup delle VM di Compute Engine. Backup e RE 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'archivio di backup a lungo termine senza attività di preparazione o spostamento dei dati che richiedono molto tempo. Per ulteriori informazioni, consulta Backup e RE per i backup delle istanze Compute Engine.

Per garantire la durabilità dei dati nelle istanze Filestore, puoi creare backup e snapshot dell'istanza o utilizzare Backup e RE per Filestore e i file system.

Per impostazione predefinita, i backup dei database in Oracle Exadata Database Service su infrastruttura dedicata vengono archiviati in OCI Object Storage. Per ottenere un RPO inferiore, puoi eseguire il backup e il recupero dei database utilizzando Oracle Autonomous Recovery Service.

Altre 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 documentazione seguente:

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 i tipi di macchine personalizzate.

Modello di provisioning delle VM

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

Le VM spot sono adatte per i job batch che possono tollerare il prerilascio e non hanno requisiti di alta affidabilità. 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.

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 dei prodotti Oracle

È tua responsabilità procurarti le licenze per i prodotti Oracle che deploy su Compute Engine, nonché rispettare i termini e le condizioni delle licenze Oracle. Per ulteriori informazioni, consulta Licensing Oracle Software in the Cloud Computing Environment.

Licenze del database Oracle Exadata

Quando crei un cluster VM Exadata, puoi Bring Your Own License (BYOL) o utilizzare una licenza che hai acquistato nell'ambito dell'ordine Google Cloud Marketplace per Oracle Database@Google Cloud.

I costi di Networking per il trasferimento di dati tra le tue applicazioni e i database Oracle Exadata che si trovano nella stessa regione sono inclusi nel prezzo dell'offerta Oracle Database@Google Cloud.

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 template di istanza con la configurazione richiesta e poi applica il nuovo template 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 Applica nuove configurazioni delle VM in un MIG.

Immagini Oracle Linux

Per le tue VM, puoi utilizzare immagini Oracle Linux disponibili in Compute Engine oppure puoi importare immagini Oracle Linux che crei e gestisci. Puoi anche creare e utilizzare immagini sistema operativo personalizzate che includono le configurazioni e il software richiesti dalle tue applicazioni. Puoi raggruppare le immagini personalizzate in una famiglia di immagini personalizzate. Una famiglia di immagini punta sempre all'immagine più recente della famiglia, quindi i template di istanza e gli script possono 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.

Template 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 ulteriori informazioni, vedi Template di istanza deterministici.

Amministrazione del database Oracle Exadata

Oracle gestisce i server di database fisici, i server di archiviazione e l'hardware di rete in Oracle Exadata Database Service su infrastruttura dedicata. Puoi gestire le istanze dell'infrastruttura Exadata e i cluster di VM Exadata tramite le interfacce OCI o Google Cloud . Puoi creare e gestire i database tramite le interfacce OCI. Le pagine della console Google Cloud per Oracle Database@Google Cloud includono link che puoi utilizzare per andare direttamente alle pagine pertinenti nella console OCI. Per evitare di dover accedere di nuovo a OCI, puoi configurare la federazione delle identità tra OCI e Google Cloud.

Osservabilità per le applicazioni Oracle

Per implementare l'osservabilità per i carichi di lavoro Oracle di cui è stato eseguito il deployment in Google Cloud, puoi utilizzare i servizi di Google Cloud Observability o Oracle Enterprise Manager. Scegli una strategia di monitoraggio appropriata in base ai tuoi requisiti e vincoli. Ad esempio, se esegui altri carichi di lavoro in Google Cloud oltre a quelli Oracle, puoi utilizzare i servizi Google Cloud Observability per creare una dashboard operativa unificata per tutti i carichi di lavoro.

Documentazione e assistenza Oracle

I prodotti Oracle eseguiti sulle VM di Compute Engine presentano problemi operativi simili a quelli dei prodotti Oracle eseguiti on-premise. Tuttavia, non è necessario gestire l'infrastruttura di computing, networking e archiviazione sottostante. Per indicazioni sul funzionamento e sulla gestione dei prodotti Oracle, consulta la documentazione pertinente di Oracle.

Per informazioni sulle norme di assistenza di Oracle per le istanze di Oracle Database che esegui il deployment in Google Cloud, consulta Oracle Database Support for Non-Oracle Public Cloud Environments (ID documento 2688277.1).

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.

Prestazioni di computing

Compute Engine offre un'ampia gamma di tipi di macchine predefinite e personalizzabili per i carichi di lavoro eseguiti sulle VM. Scegli un tipo di macchina appropriato in base ai tuoi requisiti di prestazioni. Per saperne di più, consulta la guida alle risorse e al confronto per le famiglie di macchine.

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 fisica. 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 in esecuzione su ogni core della CPU fisica. Per ulteriori informazioni, vedi Imposta 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 ulteriori informazioni, leggi la documentazione sulle licenze per il software di terze parti.

Prestazioni di rete

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 attraverso la stessa rete VPC della VM di origine. Per le VM con determinati tipi di macchine, puoi ottenere una larghezza di banda in uscita massima più elevata attivando il networking Tier_1. Per ulteriori informazioni, consulta Configura le prestazioni di rete Tier_1 per VM.

Il traffico di rete tra le VM dell'applicazione e la rete Oracle Exadata viene instradato tramite una connessione Partner Interconnect a bassa latenza configurata da Google.

L'infrastruttura Exadata utilizza RDMA su Converged Ethernet (RoCE) per il networking a banda larga e bassa latenza tra i server di database e i server di archiviazione. I server scambiano i dati direttamente nella memoria principale senza coinvolgere il processore, la cache o il sistema operativo.

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: