Questo documento fornisce architetture di riferimento per aiutarti a creare l'infrastruttura per eseguire le applicazioni Oracle E-Business Suite con Oracle Database sulle VM Compute Engine in Google Cloud. Oracle E-Business Suite è una suite di applicazioni aziendali per funzioni aziendali come finanza, risorse umane, catena di fornitura e relazioni con i clienti.
Il pubblico di destinazione di questo documento è costituito da architetti e amministratori cloud di database Oracle e applicazioni Oracle E-Business Suite. Il documento presuppone che il tuo team abbia familiarità con Oracle Database e con l'architettura e lo stack tecnologico di Oracle E-Business Suite.
Se devi utilizzare Oracle Exadata o Oracle Real Application Clusters (Oracle RAC), puoi eseguire la migrazione delle tue applicazioni a Google Cloud ed eseguire i tuoi database su Oracle Database@Google Cloud. Per saperne di più, vedi Oracle E‑Business Suite con Oracle Exadata in Google Cloud.
Architettura
A seconda del caso d'uso e dei requisiti di disponibilità e ripristino di emergenza (RE), puoi scegliere uno dei seguenti Google Cloud archetipi di deployment per eseguire le applicazioni Oracle E-Business Suite su Google Cloud:
- Zonale: le tue applicazioni vengono eseguite all'interno di una singola zona Google Cloud. Questo archetipo di deployment è adatto per ambienti di sviluppo e test e per applicazioni non critiche che non richiedono alta disponibilità.
- Regionale: le tue applicazioni vengono eseguite in modo indipendente in due o più zone all'interno di una singola Google Cloud regione. Consigliamo questo archetipo di deployment per le applicazioni che non sono mission-critical, ma che devono essere robuste contro le interruzioni di zona.
- Multiregionale: le tue applicazioni vengono eseguite in modo indipendente in più zone di due o più regioni Google Cloud , in modalità attiva-attiva o attiva-passiva. Questo archetipo di deployment è ideale per supportare scenari diRER. Consigliamo questo archetipo per le applicazioni mission-critical che richiedono resilienza a interruzioni e disastri a livello di regione.
La scelta di un archetipo di deployment semplifica le decisioni successive riguardo ai Google Cloud prodotti e alle funzionalità necessari per la tua architettura.
Le sezioni seguenti presentano quattro opzioni di architettura. Ogni opzione si basa su uno degli archetipi di deployment:
- Architettura zonale
- Architettura zonale con una DMZ
- Architettura regionale
- Architettura attiva-passiva multiregionale (RE)
Architettura zonale
Il seguente diagramma mostra un'architettura per le applicazioni Oracle E-Business Suite con Oracle Database in esecuzione in una singola zona all'interno di una regioneGoogle Cloud . Questa architettura è in linea con l'archetipo di deployment zonale.
L'architettura nel diagramma precedente include i seguenti componenti:
Componente | Descrizione |
---|---|
Bilanciatore del carico delle applicazioni esterno regionale | Il bilanciatore del carico riceve e distribuisce le richieste degli utenti alle applicazioni Oracle E-Business Suite. |
Policy di sicurezza di Google Cloud Armor | I criteri di sicurezza di Google Cloud Armor contribuiscono a proteggere le tue applicazioni da minacce come attacchi DDoS e XSS. |
Oracle E‑Business Suite (BYOL) |
I componenti del livello applicazione di Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e un server di elaborazione simultanea) vengono eseguiti sulle VM Compute Engine. Ogni VM ospita un'istanza indipendente del livello applicazione. Il disco di avvio per ogni VM è un volume Google Cloud Hyperdisk. Utilizzi le tue licenze (BYOL) per Oracle E-Business Suite e gestisci le VM e le applicazioni. |
Binari e dati dell'applicazione | Un'istanza di Filestore zonale contiene i dati e i file binari dell'applicazione. L'istanza Filestore è montata sulle VM di Compute Engine che ospitano i componenti del livello applicazione. |
Oracle Database (BYOL) |
Le applicazioni Oracle E-Business Suite utilizzano un'istanza di Oracle Database di cui è stato eseguito il deployment su una VM di Compute Engine. I dischi di avvio e dati per la VM sono volumi Hyperdisk. Utilizzi la tua licenza (BYOL) per l'istanza di Oracle Database e gestisci la VM e il database. |
Backup di applicazioni e database | I backup dei dati dell'applicazione e del database vengono creati, archiviati e gestiti utilizzando il servizio di backup e DR. |
Rete Virtual Private Cloud (VPC) e subnet |
Tutte le Google Cloud risorse nell'architettura utilizzano una singola rete VPC. Le VM che ospitano il livello applicazione e il database utilizzano subnet separate. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC. Per saperne di più, consulta Decidere se creare più reti VPC. |
Gateway NAT pubblico | L'architettura include un gateway Cloud NAT pubblico per connessioni in uscita sicure dalle VM Compute Engine, che hanno solo indirizzi IP interni. Ad esempio, le VM possono accedere al server Oracle Linux Yum per scaricare i pacchetti del sistema operativo. |
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. |
Architettura zonale con una DMZ
Il seguente diagramma mostra un'architettura con due livelli applicativi Oracle E-Business Suite indipendenti in esecuzione su VM Compute Engine. Uno dei livelli dell'applicazione è una zona demilitarizzata (DMZ), che serve gli utenti esterni delle applicazioni Oracle E-Business Suite. L'altro livello serve gli utenti interni. Entrambi i livelli dell'applicazione vengono eseguiti all'interno di una singola zona in una regione Google Cloud e utilizzano una singola istanza di Oracle Database. Come l'architettura nella sezione precedente, questa architettura è allineata all'archetipo di deployment zonale.
L'architettura nel diagramma precedente include i seguenti componenti:
Componente | Descrizione |
---|---|
Bilanciatore del carico delle applicazioni esterno regionale | Il bilanciatore del carico esterno riceve e distribuisce le richieste degli utenti esterni al livello dell'applicazione esterna. |
Bilanciatore del carico delle applicazioni interno regionale | Il bilanciatore del carico interno riceve e distribuisce le richieste degli utenti interni a un livello applicativo interno. |
Policy di sicurezza di Google Cloud Armor | I criteri di sicurezza di Google Cloud Armor contribuiscono a proteggere le tue applicazioni da minacce esterne come attacchi DDoS e XSS. |
Oracle E‑Business Suite (BYOL) |
I componenti del livello applicazione di Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e un server di elaborazione simultanea) vengono eseguiti sulle VM Compute Engine. Ogni VM ospita un'istanza indipendente del livello applicazione. Le applicazioni interne ed esterne vengono pubblicate da set distinti di VM. Il disco di avvio per ogni VM è un volume Hyperdisk. Utilizzi le tue licenze (BYOL) per Oracle E-Business Suite e gestisci le VM e le applicazioni. |
Binari e dati dell'applicazione | Un'istanza zonale di Filestore contiene i dati e i file binari dell'applicazione. L'istanza Filestore è montata sulle VM di Compute Engine che ospitano i componenti del livello applicazione. |
Oracle Database (BYOL) |
Le applicazioni Oracle E-Business Suite utilizzano un'istanza di Oracle Database di cui è stato eseguito il deployment su una VM di Compute Engine. I dischi di avvio e dati per la VM sono volumi Hyperdisk. Utilizzi la tua licenza (BYOL) per l'istanza di Oracle Database e gestisci la VM e il database. |
Backup di applicazioni e database | I backup dei dati e del database dell'applicazione vengono creati, archiviati e gestiti utilizzando Backup e DR. |
Rete Virtual Private Cloud (VPC) e subnet |
Tutte le Google Cloud risorse nell'architettura utilizzano una singola rete VPC. Le VM che ospitano il livello applicazione e il database utilizzano subnet separate. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC. Per saperne di più, consulta Decidere se creare più reti VPC. |
Gateway NAT pubblico | L'architettura include un gateway Cloud NAT pubblico per connessioni in uscita sicure dalle VM Compute Engine, che hanno solo indirizzi IP interni. Ad esempio, le VM possono accedere al server Oracle Linux Yum per scaricare i pacchetti del sistema operativo. |
Cloud Interconnect e Cloud VPN | Per connettere la rete on-premise alla rete VPC in Google Cloud, puoi utilizzare Cloud Interconnect o Cloud VPN. Gli amministratori e gli utenti interni delle applicazioni utilizzano queste connessioni per accedere rispettivamente alle risorse e alle applicazioni. Per informazioni sui vantaggi relativi di ciascun approccio, consulta Scegliere unaConnettività di reterk Connectivity. |
Architettura regionale
Il seguente diagramma mostra un'architettura in cui le applicazioni Oracle E-Business Suite vengono eseguite in modalità active-active su VM Compute Engine distribuite in due zone all'interno di una regione Google Cloud . Entrambi i deployment delle applicazioni utilizzano un'istanza Oracle Database principale in esecuzione su una VM in una delle zone. Oracle Data Guard gestisce la replica e il failover del database in un'istanza di standby di Oracle Database nella seconda zona. Questa architettura si basa sull'archetipo di deployment regionale.
L'architettura nel diagramma precedente include i seguenti componenti:
Componente | Descrizione |
---|---|
Bilanciatore del carico delle applicazioni esterno regionale | Il bilanciatore del carico riceve e distribuisce le richieste degli utenti alle applicazioni Oracle E-Business Suite. |
Policy di sicurezza di Google Cloud Armor | I criteri di sicurezza di Google Cloud Armor contribuiscono a proteggere le tue applicazioni da minacce come attacchi DDoS distribuiti e XSS. |
Oracle E‑Business Suite (BYOL) |
I componenti del livello applicazione di Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e un server di elaborazione simultanea) vengono eseguiti su VM Compute Engine distribuite in due zone. Ogni VM ospita un'istanza indipendente del livello applicazione. Il disco di avvio per ogni VM è un volume Hyperdisk. Utilizzi le tue licenze (BYOL) per Oracle E-Business Suite e gestisci le VM e le applicazioni. |
Binari e dati dell'applicazione | Un'istanza regionale Filestore contiene i dati e i file binari dell'applicazione. L'istanza Filestore è montata su tutte le VM di Compute Engine che ospitano i componenti del livello applicazione in entrambe le zone. |
Oracle Database (BYOL) |
Le applicazioni Oracle E-Business Suite utilizzano una coppia principale-standby di istanze Oracle Database di cui è stato eseguito il deployment su VM di Compute Engine in zone separate. I dischi di avvio e dati per la VM sono volumi Hyperdisk. Oracle Data Guard gestisce la replica e il failover del database dall'istanza principale all'istanza di standby. Utilizzi le tue licenze (BYOL) per le istanze di Oracle Database e gestisci le VM e i database. |
Backup di applicazioni e database | I backup dei dati e del database dell'applicazione vengono creati, archiviati e gestiti utilizzando Backup e DR. |
Rete Virtual Private Cloud (VPC) e subnet |
Tutte le Google Cloud risorse nell'architettura utilizzano una singola rete VPC. Le VM che ospitano il livello applicazione e il database utilizzano subnet separate. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC. Per saperne di più, consulta Decidere se creare più reti VPC. |
Gateway NAT pubblico | L'architettura include un gateway Cloud NAT pubblico per connessioni in uscita sicure dalle VM Compute Engine, che hanno solo indirizzi IP interni. Ad esempio, le VM possono accedere al server Oracle Linux Yum per scaricare i pacchetti del sistema operativo. |
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. |
Architettura attiva/passiva (RE) multiregionale
Il seguente diagramma mostra un'architettura in cui le applicazioni Oracle E-Business Suite vengono eseguite in modalità active-active su VM Compute Engine distribuite in due zone all'interno di una regione Google Cloud . Entrambi i deployment delle applicazioni utilizzano un'istanza Oracle Database principale in esecuzione su una VM in una delle zone. Oracle Data Guard gestisce la replica e il failover del database in un'istanza di standby di Oracle Database nella seconda zona. L'architettura include una replica in scala ridotta dello stack di applicazioni in una regione remota (di failover) per RE Come l'architettura nella sezione precedente, questa architettura si basa sull'archetipo di deployment regionale.
L'architettura nel diagramma precedente include i seguenti componenti:
Componente | Descrizione |
---|---|
Policy di routing di failover DNS | Una zona pubblica Cloud DNS configurata con un criterio di routing di failover indirizza le richieste degli utenti al bilanciatore del carico nella regione che attualmente gestisce le richieste. |
Bilanciatore del carico delle applicazioni esterno regionale | Il bilanciatore del carico riceve e distribuisce le richieste degli utenti alle applicazioni Oracle E-Business Suite. |
Policy di sicurezza di Google Cloud Armor | I criteri di sicurezza di Google Cloud Armor contribuiscono a proteggere le tue applicazioni da minacce come attacchi DDoS distribuiti e XSS. |
Oracle E‑Business Suite (BYOL) |
I componenti del livello applicazione di Oracle E-Business Suite (Oracle HTTP Server, Oracle WebLogic Server e un server di elaborazione simultanea) vengono eseguiti su VM Compute Engine distribuite in due zone della regione principale. Ogni VM ospita un'istanza indipendente del livello applicazione. Il disco di avvio per ogni VM è un volume Hyperdisk. Utilizzi le tue licenze (BYOL) per Oracle E-Business Suite e gestisci le VM e le applicazioni. |
Binari e dati dell'applicazione |
Un'istanza regionale Filestore nella regione principale contiene i file binari e i dati dell'applicazione. L'istanza Filestore è montata su tutte le VM Compute Engine che ospitano i componenti del livello applicazione in entrambe le zone della regione primaria. L'istanza Filestore viene replicata nella regione di failover. |
Oracle Database (BYOL) |
Le applicazioni Oracle E-Business Suite utilizzano una coppia principale-standby di istanze Oracle Database di cui è stato eseguito il deployment su VM Compute Engine in zone separate nella regione principale. I dischi di avvio e dati per la VM sono volumi Hyperdisk. Oracle Data Guard gestisce la replica e il failover del database dall'istanza principale all'istanza di standby. Utilizzi le tue licenze (BYOL) per le istanze di Oracle Database e gestisci le VM e i database. |
Backup di applicazioni e database | I backup dei dati dell'applicazione e del database vengono creati, archiviati e gestiti utilizzando Backup e DR. |
Rete Virtual Private Cloud (VPC) e subnet |
Tutte le Google Cloud risorse nell'architettura utilizzano una singola rete VPC. Le VM che ospitano il livello applicazione e il database utilizzano sottoreti regionali separate. A seconda dei tuoi requisiti, puoi scegliere di creare un'architettura che utilizzi più reti VPC. Per saperne di più, consulta Decidere se creare più reti VPC. |
Gateway NAT pubblico | L'architettura include un gateway Cloud NAT pubblico in ogni regione per connessioni in uscita sicure dalle VM Compute Engine, che hanno solo indirizzi IP interni. Ad esempio, le VM possono accedere al server Oracle Linux Yum per scaricare i pacchetti del sistema operativo. |
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. |
Prodotti utilizzati
Queste architetture di riferimento utilizzano 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.
- Filestore: un servizio che fornisce archiviazione di file completamente gestita ad alte prestazioni su Google Cloud a cui puoi connetterti a una serie di tipi di client.
- Servizio di backup e DR: un servizio di backup e ripristino sicuro e gestito centralmente per i workload Google Cloud che aiuta a proteggere i dati di backup da eliminazioni intenzionali o accidentali.
- Cloud DNS: un servizio che fornisce una gestione DNS resiliente e a bassa latenza dalla rete globale di Google.
- Cloud Load Balancing: un portafoglio di bilanciatori del carico scalabili, globali e regionali ad alte prestazioni.
- 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.
- 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.
- Cloud NAT: un servizio che fornisce Network Address Translation ad alte prestazioni gestita da Google Cloud.
- 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.
Queste architetture di riferimento utilizzano i seguenti prodotti Oracle:
- Oracle E-Business Suite: una suite di applicazioni per operazioni aziendali come finanza, risorse umane e catena di fornitura.
- 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 queste architetture di riferimento per sviluppare una topologia che soddisfi i tuoi requisiti specifici in termini di sicurezza, affidabilità, efficienza operativa, costi e prestazioni.
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.
Migrazione del database
Quando pianifichi di eseguire la migrazione dei deployment di Oracle Database on-premise a Google Cloud, valuta l'ambiente di database attuale e ricevi consigli su configurazione e dimensionamento utilizzando lo strumento Database Migration Assessment (DMA).
Per eseguire la migrazione dei dati on-premise alle implementazioni del database Oracle inGoogle Cloud, puoi utilizzare strumenti Oracle standard come Oracle GoldenGate.
Opzioni di archiviazione
Le architetture mostrate in questo documento utilizzano volumi Hyperdisk per i dischi di avvio di tutte le VM Compute Engine e per i dischi di dati delle VM che ospitano istanze di Oracle Database. I volumi Hyperdisk offrono prestazioni, flessibilità ed efficienza migliori rispetto al Persistent Disk. Per informazioni sui tipi e sulle funzionalità di Hyperdisk, consulta Informazioni su Hyperdisk.
Per i dati e i file binari delle applicazioni, tutte le architetture in questo documento utilizzano 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 anche 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. Le architetture mostrate in questo documento utilizzano una topologia di rete semplice con una singola rete VPC. A seconda dei tuoi requisiti, puoi scegliere di utilizzare più reti VPC. Per ulteriori informazioni, consulta la seguente documentazione:
- Decidere se creare più reti VPC
- Decidere la struttura di rete per la tua Google Cloud zona di destinazione
Analisi di dati
Per l'analisi avanzata, puoi utilizzare Google Cloud Cortex Framework per importare i dati dalle applicazioni Oracle E-Business Suite in BigQuery. Per ulteriori informazioni, vedi Cortex Framework: integrazione con Oracle E‑Business Suite.
Sicurezza, privacy e conformità
Questa sezione descrive i fattori da considerare quando utilizzi queste architetture 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 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 e in Filestore vengono criptati utilizzando Google-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 ulteriori informazioni, vedi Informazioni sulla crittografia del disco per i volumi Hyperdisk e Criptare i dati con chiavi di crittografia gestite dal cliente per Filestore.
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 queste architetture di riferimento per creare e gestire un'infrastruttura affidabile per la tua implementazione in Google Cloud.
Robustezza del livello applicazione contro gli errori della VM
Con tutte le opzioni di architettura descritte in questo documento, se alcune (ma non tutte) delle VM dell'applicazione non funzionano, le applicazioni continuano a essere disponibili perché il bilanciamento del carico inoltra le richieste ad altre VM dell'applicazione.
A volte una VM applicativa potrebbe essere in esecuzione e disponibile, ma potrebbero esserci problemi con l'applicazione stessa. L'applicazione potrebbe bloccarsi, arrestarsi in modo anomalo o non avere memoria sufficiente. In questo scenario, la VM non risponderà ai controlli di integrità del bilanciatore del carico e quest'ultimo non indirizzerà il traffico alla VM che non risponde.
Robustezza del database contro gli errori delle VM
In un'architettura zonale, se la VM del database non funziona, puoi ripristinare il database in produzione su una nuova VM utilizzando i backup archiviati in Backup anRER. Dopo aver ripristinato il database, devi connettere le applicazioni alla nuova istanza del database.
Se la coerenza dei dati è una priorità, configura un'istanza di database principale e una di standby, preferibilmente su VM che si trovano in zone diverse, come mostrato in Architettura regionale. Per la replica e il failover all'istanza di database di standby, utilizza Data Guard. Data Guard contribuisce a garantire la coerenza replicando le transazioni nell'istanza di standby prima di confermarle nell'istanza primaria. L'architettura del database primario-standby comporta costi aggiuntivi per infrastruttura e licenze.
In un'architettura regionale o multiregionale, se la VM che ospita il database primario non funziona, Oracle Data Guard avvia un failover all'istanza di Oracle Database di standby. Durante il processo di failover, le applicazioni non possono accedere al database.
Robustezza contro le interruzioni di zona
In un'architettura zonale, se la zona che ospita il deployment ha un'interruzione del servizio, le applicazioni e il database non sono disponibili. Puoi ripristinare le applicazioni e il database in produzione in una zona o regione diversa utilizzando i backup archiviati in Backup REDR.
In un'architettura regionale, se una delle zone ha un'interruzione del servizio, il bilanciatore del carico inoltra le richieste alle istanze delle applicazioni eseguite nell'altra zona. Filestore continua a essere disponibile perché l'architettura utilizza il livello di servizio regionale Filestore.
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 Hyperdisk bilanciato ad alta affidabilità, vengono replicati in modo sincrono tra due zone nella stessa regione.
Robustezza contro le interruzioni a livello di regione
Se si verifica un'interruzione a livello di regione, le applicazioni e il database non sono disponibili. Puoi ripristinare le applicazioni e il database in produzione in una regione diversa utilizzando i backup archiviati in Backup e RE. Per ridurre i tempi di inattività, utilizza l'architettura multiregionale attiva-passiva (RE). Dopo aver visualizzato le applicazioni e il database, devi aggiornare il criterio di routing DNS per indirizzare il traffico al bilanciamento del carico nella regione di failover.
Per le applicazioni business-critical che non possono tollerare tempi di inattività anche in caso di interruzione della regione, utilizza l'archetipo di deployment attivo-attivo multiregionale.
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.
Durabilità dei dati
Le architetture in questo documento utilizzano Backup e RE per creare, archiviare e gestire i backup delle VM di Compute Engine. Backup e RE memorizza i dati di backup nel formato originale leggibile dall'applicazione. Se necessario, puoi ripristinare i workload in produzione utilizzando direttamente i dati dell'archivio di backup a lungo termine ed evitare la necessità di preparare o spostare i dati.
Backup e RE supporta due metodi per la creazione di backup:
- Archiviazione del vault di backup: i dati di backup vengono archiviati nella stessa regione dei dati di origine e non possono essere modificati o eliminati.
- Archiviazione autogestita: gli utenti autorizzati possono modificare o eliminare i dati di backup e puoi archiviare i dati in più regioni.
Per ulteriori informazioni, consulta la seguente documentazione:
- Panoramica di RE e DR
- Backup e RE per i backup delle istanze Compute Engine
- Backup e RE per Filestore e file system
- Backup e RE per Oracle
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:
- Google Cloud Guida all'affidabilità dell'infrastruttura
- Pattern per app scalabili e resilienti
- Progettazione di sistemi resilienti
- Google Cloud Well-Architected Framework: affidabilità
Ottimizzazione dei costi
Questa sezione fornisce indicazioni per ottimizzare il costo di configurazione e gestione di una topologia Google Cloud che crei utilizzando queste architetture 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.
Licenze dei prodotti Oracle
È 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, considera il numero di licenze per processore Oracle necessarie in base al tipo di macchina che scegli per le VM di Compute Engine che ospitano i prodotti Oracle. Per ulteriori informazioni, consulta la pagina Licensing Oracle Software in the Cloud Computing Environment.
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 queste architetture di riferimento per progettare una topologia Google Cloud che puoi gestire in modo efficiente.
Immagini VM
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 del sistema operativo personalizzate che includono le configurazioni e il software richiesti dalle tue applicazioni. Puoi raggruppare le tue immagini personalizzate in una famiglia di immagini personalizzata. Una famiglia di immagini punta sempre all'immagine più recente della famiglia, in modo che i modelli di istanza e gli script possano utilizzare l'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 forniti dal fornitore del sistema operativo.
Connettività dal server delle applicazioni al database
Per le connessioni dalle tue applicazioni 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.
Documentazione e assistenza Oracle
I prodotti Oracle eseguiti su VM Compute Engine hanno 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 fornita da Oracle per il prodotto pertinente.
- 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).
- Per un riepilogo delle norme di assistenza Oracle per Oracle E-Business Suite, consulta Certificazioni EBS.
Osservabilità
Per implementare l'osservabilità per la tua implementazione di Oracle E-Business Suite su Google Cloud, puoi utilizzare i servizi 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 alle applicazioni Oracle E-Business Suite, puoi utilizzare i servizi Google Cloud Observability per creare una dashboard operativa unificata per tutti i carichi di lavoro.
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 queste architetture 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 le applicazioni e il database, scegli un tipo di macchina appropriato in base ai requisiti di prestazioni. 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 la VM che ospita 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.
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 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. Per ulteriori informazioni, vedi Configurare le prestazioni di rete Tier_1 per VM.
Prestazioni di archiviazione Hyperdisk
Le architetture descritte in questo documento utilizzano volumi Hyperdisk per tutti i dischi di avvio delle VM e per i dischi di dati della VM del database. Hyperdisk ti consente di scalare le prestazioni e la capacità in modo dinamico. Puoi regolare le IOPS, il throughput e le dimensioni 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 saperne di più sui limiti di prestazioni e sull'ottimizzazione di Hyperdisk, consulta la seguente documentazione:
- Tipi di macchine che supportano Hyperdisk
- Limiti di prestazioni di Hyperdisk
- Ottimizzare le prestazioni di Hyperdisk
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
- Trasformazione cloud con Google Cloud e Oracle
- Architetture di riferimento Oracle MAA
- Applicazione aziendale su VM di Compute Engine con Oracle Exadata in Google Cloud
- Per ulteriori architetture di riferimento, diagrammi e best practice, esplora il Cloud Architecture Center.
Collaboratori
Autori:
- Kumar Dhanagopal | Sviluppatore di soluzioni cross-product
- Samantha He | Technical Writer
Altri collaboratori:
- Andy Colvin | Database Black Belt Engineer, Oracle su Google Cloud
- Balazs Pinter | Partner Solutions Architect
- Celia Antonio | Database Customer Engineer
- Majed Al-Halaseh | Customer Engineer, Infrastructure Modernization
- Marc Fielding | Data Infrastructure Architect
- Mark Schlagenhauf | Technical Writer, Networking
- Michelle Burtoft | Senior Product Manager
- Sean Derrington | Group Outbound Product Manager, Storage
- Sekou Page | Outbound Product Manager
- Souji Madhurapantula | Group Product Manager
- Victor Moreno | Product Manager, Cloud Networking