Applicazione aziendale su VM Compute Engine con Oracle Exadata in Google Cloud

Last reviewed 2024-09-30 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 su Google Cloud. Il pubblico di destinazione di questo documento è costituito da architetti cloud e amministratori di database Oracle. Il documento assume 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 su Google Cloud in modo efficiente ed eseguire i 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 sulle VM Compute Engine. Per ulteriori informazioni, consulta Applicazione aziendale con Oracle Database su Compute Engine.

Architettura

Il seguente diagramma mostra una visione di alto livello dell'architettura:

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

Nel diagramma precedente, un bilanciatore del carico esterno riceve le richieste degli 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 li scrivono 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, il livello web e il livello di applicazione vengono eseguiti in modalità active-active su VM Compute Engine distribuite su due zone all'interno di una regione Google Cloud. L'applicazione utilizza i database Oracle Exadata nella stessa regione Google Cloud.

Tutti i componenti dell'architettura si trovano in un'unica regione Google Cloud. Questa architettura è in linea con l'archetipo di implementazione regionale. Puoi adattare questa architettura per creare una topologia solida contro le interruzioni regionali utilizzando l'archetipo di deployment multiregionale. Per ulteriori informazioni, consulta Deployment multiregionale su Compute Engine e le indicazioni nella sezione Affidabilità di 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.
Criteri di sicurezza di Google Cloud Armor Il criterio di sicurezza di Google Cloud Armor contribuisce a proteggere il tuo app stack 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 disegnato su VM Compute Engine che fanno parte di un gruppo di istanze gestite regionale. Questa MIG è il backend per il bilanciatore del carico delle applicazioni esterno. Il gruppo di istanze gestite 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 di livello web alle VM di livello applicazione.
Gruppo di istanze gestite a livello di regione per il livello dell'applicazione Il livello dell'applicazione, ad esempio un cluster Oracle WebLogic Server, viene disegnato su VM Compute Engine che fanno parte di un MIG regionale. Questa MIG è il backend per il bilanciatore del carico delle applicazioni interno. Il gruppo di istanze gestite contiene VM Compute Engine in due zone. Ogni VM ospita un'istanza indipendente del server delle applicazioni.
Rete Virtual Private Cloud (VPC) e sottorete Tutte le risorse Google Cloud nell'architettura utilizzano una singola rete VPC. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti. Per saperne di più, 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 Exadata Infrastructure. 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 Exadata Infrastructure 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 utilizzando una struttura di rete a bassa latenza. Quando crei un'istanza di Exadata Infrastructure, specifichi il numero di server database e server di archiviazione di cui deve essere eseguito il provisioning.
Cluster di VM Exadata

All'interno di un'istanza di Exadata Infrastructure, puoi creare 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 database Oracle.

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, specifica la versione di Oracle Grid Infrastructure. Puoi anche scegliere il tipo di licenza: BYOL (Bring Your Own License) o 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 del client viene utilizzata per la connettività dalla rete VPC ai database Oracle. La sottorete 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 rete VPC e la VCN viene indirizzato da un router Cloud collegato alla VPC e tramite un gateway di routing dinamico (DRG) collegato alla VCN. Il traffico passa 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 Cloud DNS. Quando i server delle applicazioni inviano richieste di lettura e scrittura ai database Oracle, Cloud DNS risolve i nomi host dei 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 inoltrati a OCI Object Storage tramite un Service Gateway.
Gateway Cloud NAT pubblico L'architettura include un gateway Cloud NAT pubblico per attivare connessioni in uscita sicure dalle VM Compute Engine, che hanno solo indirizzi IP interni.
Cloud Interconnect e Cloud VPN Per connettere la tua 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 Puoi utilizzare Cloud Monitoring per osservare il comportamento, l'integrità e le prestazioni della tua applicazione e delle risorse Google Cloud, incluse le risorse Oracle Exadata. Puoi anche monitorare le risorse in 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 networking scalabili e globali per i carichi di lavoro Google Cloud. 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 della 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 fornisce visibilità su prestazioni, disponibilità e integrità delle tue applicazioni e dell'infrastruttura.
  • Cloud Interconnect: un servizio che estende la tua rete esterna alla rete Google tramite una connessione a bassa latenza e alta disponibilità.
  • 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 consente di eseguire istanze Oracle Database su hardware Exadata dedicato.
  • Archiviazione di oggetti: un servizio per archiviare 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 una VCN.
  • Gateway di routing dinamico: un router virtuale per il traffico tra una VCN e reti esterne.
  • Service Gateway: un gateway per consentire alle risorse di una VCN di accedere privatamente a servizi Oracle specifici.

Note sul layout

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

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

Progettazione del sistema

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

Selezione delle regioni

Quando scegli la regione Google Cloud per il tuo deployment, prendi in considerazione i seguenti fattori e requisiti:

  • Disponibilità dei servizi Google Cloud in ogni regione. Per ulteriori informazioni, consulta Prodotti disponibili in base alla località.
  • Disponibilità dei tipi di macchine Compute Engine in ogni regione. Per maggiori informazioni, consulta Regioni e zone.
  • Disponibilità di Oracle Database@Google Cloud in ogni regione. Per ulteriori informazioni, consulta la sezione Configurazioni disponibili.
  • Requisiti relativi alla latenza per gli utenti finali.
  • Costo delle risorse Google Cloud.
  • 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 maggiori informazioni, consulta Best practice per la scelta delle regioni Compute Engine.

Infrastruttura di calcolo

L'architettura di riferimento in questo documento utilizza le VM Compute Engine per ospitare il livello web e il livello dell'applicazione. A seconda dei requisiti della tua applicazione, puoi scegliere i seguenti altri servizi di calcolo Google Cloud:

  • Contenitori: 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 le risorse IT sui dati e sulle applicazioni anziché sulla configurazione e sul funzionamento delle risorse di infrastruttura, puoi utilizzare servizi serverless come Cloud Run e funzioni 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 contenitori offrono maggiore flessibilità e controllo della 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. Le indicazioni di progettazione per questi servizi non rientrano nell'ambito di questo documento. Per ulteriori informazioni sulle opzioni di servizio, consulta Hosting di applicazioni su Google Cloud.

Opzioni di archiviazione

Per fornire archiviazione permanente per le VM Compute Engine nel livello web e nel livello dell'applicazione, scegli un tipo di Persistent Disk o Google Cloud Hyperdisk appropriato in base ai requisiti di capacità, scalabilità, disponibilità e prestazioni della tua applicazione. Per saperne di più, consulta Opzioni di archiviazione.

Se hai bisogno di spazio di archiviazione a basso costo e ridondante nelle zone di una regione, utilizza i bucket regionali Cloud Storage.

Per archiviare i dati condivisi tra più VM in una regione, come i file di configurazione per tutte le VM nel livello web, puoi utilizzare un'istanza Filestore regionale. I dati archiviati in un'istanza Filestore regionale vengono riproduttivi in modo sincrono in tre zone all'interno della regione. Questa replica contribuisce a garantire alta disponibilità e robustezza contro le interruzioni della zona per i dati archiviati in Filestore. 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 lo spazio di archiviazione per i tuoi carichi di lavoro, tieni conto delle caratteristiche funzionali dei carichi di lavoro, dei requisiti di resilienza, delle aspettative relative alle prestazioni e degli obiettivi di costo. Per ulteriori informazioni, consulta Progettare una strategia di archiviazione ottimale per il carico di lavoro cloud.

Progettazione di reti

Quando crei l'infrastruttura per uno stack di applicazioni multilivello, devi scegliere un design 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. A seconda dei tuoi requisiti, puoi scegliere di utilizzare più reti. Per ulteriori informazioni, consulta la seguente documentazione:

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

Migrazione del database

Quando prevedi di eseguire la migrazione dei database on-premise a Oracle Database@Google Cloud, valuta il tuo ambiente di database attuale e ricevi consigli per la configurazione e le dimensioni utilizzando lo strumento Database Migration Assessment (DMA).

Per eseguire la migrazione dei dati on-premise ai deployment del database Oracle in Google Cloud, puoi utilizzare strumenti Oracle standard come Oracle GoldenGate.

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

Sicurezza

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

Protezione contro le minacce esterne

Per proteggere la tua applicazione da minacce esterne come attacchi DDoS e XSS, definisci i criteri di sicurezza di Google Cloud Armor appropriati in base ai tuoi requisiti. Ogni criterio è un insieme di regole che specifica le condizioni da valutare e le azioni da intraprendere quando le condizioni sono soddisfatte. Ad esempio, una regola potrebbe specificare che se l'indirizzo IP di origine del traffico in entrata corrisponde a un indirizzo IP o a un intervallo CIDR specifico, il traffico deve essere negato. Puoi anche applicare regole WAF preconfigurate. Per ulteriori informazioni, consulta la Panoramica delle norme sulla sicurezza.

Accesso esterno per le VM

Nell'architettura di riferimento descritta in questo documento, le VM che ospitano il livello web e il livello di applicazione non richiedono l'accesso in entrata diretto da internet. Non assegnare indirizzi IP esterni a queste VM. Le risorse Google Cloud con solo indirizzi IP interni privati possono comunque accedere ad alcune API e servizi Google utilizzando Private Service Connect o l'accesso privato Google. Per ulteriori informazioni, consulta Opzioni di accesso privato per i servizi.

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

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

Sicurezza delle immagini VM

Le immagini approvate sono immagini con software che soddisfano i tuoi requisiti di sicurezza o delle norme. Per assicurarti che le VM nel livello web e nel livello di applicazione utilizzino solo immagini approvate, puoi definire un criterio dell'organizzazione che limiti l'utilizzo delle immagini in progetti di immagini pubbliche specifici. Per ulteriori informazioni, consulta Configurare i criteri per l'utilizzo di immagini attendibili.

Privilegi dell'account di servizio

Nei progetti Google Cloud in cui è abilitata l'API Compute Engine, viene creato automaticamente un account di servizio predefinito. Per le organizzazioni Google Cloud create prima del 3 maggio 2024, a questo account di servizio predefinito viene concesso il ruolo IAM Editor (roles/editor), a meno che questo comportamento non sia disattivato.

Per impostazione predefinita, l'account di servizio predefinito è associato a tutte le VM Compute Engine che crei utilizzando gcloud CLI o la console Google Cloud. Il ruolo Editor include una vasta gamma di autorizzazioni, pertanto l'associazione dell'account di servizio predefinito alle VM rappresenta un rischio per la sicurezza. Per evitare questo rischio, puoi creare e utilizzare account di servizio dedicati per ogni livello dello stack dell'applicazione. Per specificare le risorse a cui può accedere l'account di servizio, utilizza criteri granulari. Per ulteriori informazioni, consulta Limitare i privilegi degli account di servizio.

Sicurezza della rete

Per controllare il traffico di rete tra le risorse del livello web e del livello di applicazione dell'architettura, devi configurare i criteri Cloud NGFW (Next-Generation Firewall) appropriati.

Conformità e sicurezza del database

Il servizio Exadata Database 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 l'attività utente e mascherare i dati sensibili. Per ulteriori informazioni, consulta Gestire la sicurezza del database con Oracle Data Safe.

Altre considerazioni sulla sicurezza

Quando crei l'architettura per il tuo carico di lavoro, tieni presenti le best practice e i consigli per la sicurezza a livello di piattaforma forniti nel blueprint Enterprise Foundations.

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 tuo deployment in Google Cloud.

Resistenza ai guasti delle VM

Nell'architettura mostrata in questo documento, se una VM Compute Engine nel livello web o nel livello dell'applicazione si arresta in modo anomalo, il MIG pertinente ricrea automaticamente la VM. I bilanciatori del carico inoltrano le richieste solo alle istanze di server web e di server applicazioni attualmente disponibili.

Riparazione automatica delle VM

A volte le VM che ospitano il livello web e il livello di applicazione potrebbero essere in esecuzione e disponibili, ma potrebbero esserci problemi con l'applicazione stessa. L'applicazione potrebbe bloccarsi, avere un arresto anomalo o non avere memoria sufficiente. In questo scenario, le VM non risponderanno ai controlli di integrità del bilanciatore del carico e il bilanciatore del carico non indirizzerà il traffico alle VM non rispondenti. Per contribuire ad assicurare che le applicazioni rispondano come previsto, puoi configurare i controlli di integrità basati su applicazioni nell'ambito del criterio di riparazione automatica dei tuoi gruppi di istanze gestite. Se l'applicazione su una determinata VM non risponde, il gruppo di istanze gestite ripara automaticamente la VM. Per ulteriori informazioni sulla configurazione della riparazione automatica, consulta Informazioni sulla riparazione delle VM per l'alta disponibilità.

Resistenza alle interruzioni a livello di regione

Se si verifica un'interruzione del servizio in una regione, l'applicazione non è disponibile. Per ridurre il tempo di riposo causato da interruzioni nelle regioni, puoi implementare il seguente approccio:

  • Mantieni una replica passiva (di failover) del livello web e del livello di applicazione in un'altra regione di Google Cloud.
  • Crea un'istanza Exadata Infrastructure di riserva con i cluster di VM Exadata richiesti nella stessa regione che ha la replica passiva dello stack delle applicazioni. Utilizza Oracle Data Guard per la replica dei dati e il failover automatico ai database Exadata in standby. Se la tua applicazione ha bisogno di un obiettivo di punto di recupero (RPO) inferiore, puoi eseguire il backup e il recupero dei database utilizzando Oracle Autonomous Recovery Service.
  • Se si verifica un'interruzione nella regione principale, utilizza la replica o il backup del database per ripristinare il database in produzione e attivare l'applicazione nella regione di failover.
  • Utilizza 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 del servizio in una regione, ti consigliamo di utilizzare l'archetipo di implementazione 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 Oracle PaaS e IaaS.

Scalabilità automatica del gruppo di istanze gestite

L'architettura in questo documento utilizza i MIG regionali per il livello web e per il livello di applicazione. La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless garantisce che le VM Compute Engine che ospitano il livello web e il livello di applicazione non siano interessate da interruzioni di singole zone. I gruppi di istanze gestite stateful non possono essere sottoposti a ridimensionamento automatico.

Per controllare il comportamento della scalabilità automatica dei tuoi MIG, puoi specificare le metriche di utilizzo target, ad esempio l'utilizzo medio della CPU. Puoi anche configurare la scalabilità automatica in base alla pianificazione. Per ulteriori informazioni, consulta Gruppi di istanze a scalabilità automatica.

Posizionamento della VM

Nell'architettura descritta in questo documento, il livello di applicazione e il livello web vengono eseguiti su VM Compute Engine distribuite su più zone. Questa distribuzione contribuisce ad assicurare che il livello web e il livello di applicazione siano resistenti alle interruzioni in una singola zona. Per migliorare ulteriormente questa robustezza, puoi creare un criterio di posizionamento distribuito e applicarlo al modello MIG. Con un criterio di posizionamento distribuito, quando l'MIG crea le VM, le posiziona all'interno di ogni zona su server fisici diversi (chiamati host), in modo che siano resistenti ai guasti dei singoli host. Tuttavia, un compromesso di questo approccio è che la latenza del traffico di rete tra VM potrebbe aumentare. Per ulteriori informazioni, consulta la Panoramica delle norme relative al posizionamento.

Pianificazione della capacità delle VM

Per assicurarti che la capacità per le VM Compute Engine sia disponibile quando necessaria per la scalabilità automatica del gruppo di istanze gestite, puoi creare prenotazioni. Una prenotazione fornisce una capacità garantita in una zona specifica per un numero specificato di VM di un tipo di macchina scelto. Una prenotazione può essere specifica per un progetto o essere condivisa tra più progetti. Gli addebiti per le risorse prenotate vengono applicati anche se non viene eseguito il provisioning delle risorse o se non vengono utilizzate. Per ulteriori informazioni sulle prenotazioni, incluse le considerazioni sulla fatturazione, consulta Prenotazioni di risorse a livello di zona di Compute Engine.

Archiviazione stateful

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

Capacità del database

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

Backup e ripristino

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 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 dello spazio di archiviazione di backup a lungo termine senza attività di spostamento o preparazione dei dati che richiedono molto tempo. Per ulteriori informazioni, consulta Backup and DR Service per i backup delle istanze Compute Engine.

Per impostazione predefinita, i backup dei database in Oracle Exadata Database Service sull'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, consulta le best practice e i consigli relativi all'affidabilità forniti nella seguente documentazione:

Ottimizzazione dei costi

Questa sezione fornisce indicazioni per ottimizzare il costo della configurazione e del funzionamento di una topologia Google Cloud creata utilizzando questa architettura di riferimento.

Tipi di macchine VM

Per aiutarti a ottimizzare l'utilizzo delle VM, Compute Engine fornisce suggerimenti sul tipo di macchina. Utilizza i consigli per scegliere i tipi di macchine che corrispondono ai requisiti di calcolo delle VM di livello web e di livello applicazione. Per i carichi di lavoro con requisiti di risorse prevedibili, puoi personalizzare il tipo di macchina in base alle tue esigenze e risparmiare 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 nel livello web e nel livello di applicazione. 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 la capacità.

Le VM spot sono adatte per job batch che possono tollerare la preemption e non hanno requisiti di alta disponibilità. Le VM spot offrono gli stessi tipi di macchine, opzioni e prestazioni delle VM normali. Tuttavia, quando la capacità delle risorse in una zona è limitata, i gruppi di istanze gestite potrebbero non essere in grado di eseguire lo scale out (ovvero creare VM) automaticamente per raggiungere le dimensioni target specificate finché la capacità richiesta non diventa di nuovo disponibile.

Utilizzo delle risorse VM

La funzionalità di scalabilità automatica dei gruppi di istanze gestite stateless consente alla tua applicazione di gestire in modo graduale gli aumenti del traffico verso il livello web e il livello di applicazione. La scalabilità automatica consente inoltre di ridurre i costi quando il fabbisogno di risorse è ridotto. I gruppi di istanze gestite stateful non possono essere sottoposti a ridimensionamento automatico.

Costi del database

Quando crei un cluster di VM Exadata, puoi scegliere BYOL o eseguire il provisioning di database Oracle con licenza inclusa.

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

Altre considerazioni sui costi

Quando crei l'architettura per il tuo carico di lavoro, prendi in considerazione anche le best practice e i consigli generali forniti nel Framework dell'architettura di Google Cloud: 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 della VM

Per aggiornare la configurazione delle VM in un gruppo di istanze gestite (ad esempio il tipo di macchina o l'immagine del disco di avvio), crea un nuovo modello di istanza con la configurazione richiesta e poi applica il nuovo modello al gruppo di istanze gestite. Il gruppo di istanze gestite aggiorna le VM utilizzando un metodo di aggiornamento specificato da te: automatico o selettivo. Scegli un metodo appropriato in base ai tuoi requisiti di disponibilità ed efficienza operativa. Per ulteriori informazioni su questi metodi di aggiornamento del gruppo di istanze gestite, consulta Applicare nuove configurazioni VM in un gruppo di istanze gestite.

Immagini VM

Per i modelli di istanze MIG, anziché utilizzare le immagini pubbliche fornite da Google, ti consigliamo di creare e utilizzare immagini del 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 fa sempre riferimento all'immagine più recente della famiglia, pertanto i modelli di istanze e gli script possono utilizzare l'immagine senza che tu debba aggiornare i riferimenti a una versione dell'immagine specifica. Devi aggiornare regolarmente le immagini personalizzate in modo da includere aggiornamenti di sicurezza e patch forniti dal fornitore del sistema operativo.

Modelli di istanza deterministici

Se i modelli di istanze che utilizzi per i tuoi MIG includono script di avvio (ad esempio per installare software di terze parti), assicurati che gli script specifichino esplicitamente i parametri di installazione del software, come la versione del software. In caso contrario, quando il gruppo di istanze gestite crea le VM, il software installato sulle VM potrebbe non essere coerente. Ad esempio, se il 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, consulta Modelli di istanze deterministiche.

Amministrazione del database

Oracle gestisce i server di database fisici, i server di archiviazione e l'hardware di rete in Oracle Exadata Database Service on Dedicated Infrastructure. Puoi gestire le istanze di Exadata Infrastructure 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.

Altre considerazioni operative

Quando crei l'architettura per il tuo carico di lavoro, tieni conto delle best practice e dei consigli generali per l'efficienza operativa descritti nel Framework dell'architettura di Google Cloud: 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 prestazioni dei tuoi workload.

Prestazioni di calcolo

Compute Engine offre un'ampia gamma di tipi di macchine predefinite e personalizzabili tra cui scegliere in base ai requisiti di prestazioni dei tuoi carichi di lavoro. Per le VM che ospitano il livello web e il livello di applicazione, scegli un tipo di macchina appropriato in base ai requisiti di prestazioni per questi livelli. Per ulteriori informazioni, consulta Confronto tra le serie di macchine.

Prestazioni della rete

Per i carichi di lavoro che richiedono una bassa latenza di rete inter-VM all'interno dei livelli web e di applicazione, puoi creare un criterio di posizionamento compatto e applicarlo al modello MIG utilizzato per questi livelli. Quando il gruppo di istanze gestite crea le VM, le posiziona su server fisici vicini tra loro. Sebbene un criterio di posizionamento compatto contribuisca a migliorare le prestazioni della rete inter-VM, un criterio di posizionamento distribuito può contribuire a migliorare la disponibilità delle VM, come descritto in precedenza. Per ottenere un equilibrio ottimale tra prestazioni e disponibilità della rete, quando crei un criterio di posizionamento compatto, puoi specificare la distanza a cui devono essere posizionate le VM. Per ulteriori informazioni, consulta la Panoramica delle norme relative al posizionamento.

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

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

Exadata Infrastructure utilizza RDMA su Converged Ethernet (RoCE) per la rete 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, tieni conto delle best practice e dei consigli generali forniti nel framework dell'architettura di Google Cloud: ottimizzazione delle prestazioni.

Passaggi successivi

Collaboratori

Autore: Kumar Dhanagopal | Sviluppatore di soluzioni cross-product

Altri collaboratori: