Architetture per applicazioni Oracle con Azure Macchine virtuali con database in OCI

Si applica a: ✔️ macchine virtuali Linux

Microsoft e Oracle collaborano per consentire ai clienti di distribuire applicazioni Oracle come Oracle E-Business Suite, JD Edwards EnterpriseOne e PeopleSoft nel cloud. Con l'introduzione dell'interconnettività di rete privata tra Microsoft Azure e Oracle Cloud Infrastructure (OCI), le applicazioni Oracle possono essere distribuite in Azure con i database back-end in Azure o OCI. Le applicazioni Oracle possono anche essere integrate con Microsoft Entra ID, consentendo di configurare l'accesso Single Sign-On in modo che gli utenti possano accedere all'applicazione Oracle usando le credenziali di Microsoft Entra.

OCI offre più opzioni di database Oracle per le applicazioni Oracle, tra cui DBaaS, Servizio cloud Exadata, Oracle RAC e Infrastructure-as-a-Service (IaaS). Il database autonomo non è attualmente un back-end supportato per le applicazioni Oracle.

Sono disponibili più opzioni per la distribuzione di applicazioni Oracle in Azure, tra cui in modo a disponibilità elevata e sicurezza. Azure offre anche immagini di macchine virtuali di database Oracle che è possibile distribuire se si sceglie di eseguire interamente le applicazioni Oracle in Azure.

Le sezioni seguenti descrivono le raccomandazioni sull'architettura di Microsoft e Oracle per distribuire Oracle E-Business Suite, JD Edwards EnterpriseOne e PeopleSoft in una configurazione tra cloud o interamente in Azure. Microsoft e Oracle hanno testato queste applicazioni e hanno confermato che le prestazioni soddisfano gli standard impostati da Oracle per queste applicazioni.

Considerazioni sull'architettura

Le applicazioni Oracle sono costituite da più servizi, che possono essere ospitati nella stessa macchina virtuale o in più macchine virtuali in Azure e facoltativamente in OCI.

Le istanze dell'applicazione possono essere configurate con endpoint privati o pubblici. Microsoft e Oracle consigliano di configurare una macchina virtuale host bastion con un indirizzo IP pubblico in una subnet separata per la gestione dell'applicazione. Assegnare quindi solo indirizzi IP privati agli altri computer, incluso il livello di database.

Quando si configura un'applicazione in un'architettura tra cloud, è necessaria la pianificazione per assicurarsi che lo spazio degli indirizzi IP nella rete virtuale di Azure non si sovrapponga allo spazio indirizzi IP privato nella rete cloud virtuale OCI.

Per una maggiore sicurezza, configurare i gruppi di sicurezza di rete a livello di subnet per garantire che sia consentito solo il traffico su porte e indirizzi IP specifici. Ad esempio, i computer nel livello intermedio devono ricevere traffico solo dall'interno della rete virtuale. Nessun traffico esterno deve raggiungere direttamente i computer di livello intermedio.

Per la disponibilità elevata, è possibile configurare istanze ridondanti dei diversi server nello stesso set di disponibilità o in zone di disponibilità diverse. Le zone di disponibilità consentono di ottenere un contratto di servizio con tempo di attività del 99,99%, mentre i set di disponibilità consentono di ottenere un contratto di servizio con tempo di attività del 99,95% nell'area. Le architetture di esempio illustrate in questo articolo vengono distribuite in due zone di disponibilità.

Quando si distribuisce un'applicazione usando l'interconnessione tra cloud, è possibile continuare a usare un circuito ExpressRoute esistente per connettere l'ambiente Azure alla rete locale. Tuttavia, è necessario un circuito ExpressRoute separato per l'interconnessione a OCI rispetto a quello che si connette alla rete locale.

E-Business Suite

Oracle E-Business Suite (EBS) è una suite di applicazioni, tra cui Supply Chain Management (SCM) e Customer Relationship Management (CRM). Per sfruttare i vantaggi del portfolio di database gestiti di OCI, EBS può essere distribuito usando l'interconnessione tra cloud tra Microsoft Azure e OCI. In questa configurazione, i livelli presentazione e applicazione vengono eseguiti in Azure e nel livello di database in OCI, come illustrato nel diagramma dell'architettura seguente (Figura 1).

Figura 1: Architettura cross-cloud di E-Business Suite

In questa architettura la rete virtuale in Azure è connessa a una rete cloud virtuale in OCI usando l'interconnessione tra cloud. Il livello applicazione è configurato in Azure, mentre il database è configurato in OCI. È consigliabile distribuire ogni componente nella propria subnet con gruppi di sicurezza di rete per consentire il traffico solo da subnet specifiche su porte specifiche.

L'architettura può essere adattata per la distribuzione interamente in Azure con database Oracle a disponibilità elevata configurati usando Oracle Data Guard in due zone di disponibilità in un'area. Il diagramma seguente (figura 2) è un esempio di questo modello architettonico:

Figura 2: Architettura solo Azure di E-Business Suite

Le sezioni seguenti descrivono i diversi componenti a livello generale.

Livello Bastion

L'host bastion è un componente facoltativo che è possibile usare come jump server per accedere alle istanze dell'applicazione e del database. La macchina virtuale host bastion può avere un indirizzo IP pubblico assegnato, anche se è consigliabile configurare una connessione ExpressRoute o una VPN da sito a sito con la rete locale per l'accesso sicuro. Inoltre, solo SSH (porta 22, Linux) o RDP (porta 3389, Windows Server) deve essere aperto per il traffico in ingresso. Per la disponibilità elevata, distribuire un bastion host in due zone di disponibilità o in un singolo set di disponibilità.

È anche possibile abilitare l'inoltro dell'agente SSH nelle macchine virtuali, che consente di accedere ad altre macchine virtuali nella rete virtuale inoltrando le credenziali dall'host bastion. In alternativa, usare il tunneling SSH per accedere ad altre istanze.

Ecco un esempio di inoltro dell'agente:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Questo comando si connette al bastion e quindi viene eseguito ssh di nuovo immediatamente, quindi si ottiene un terminale nell'istanza di destinazione. Potrebbe essere necessario specificare un utente diverso da root nell'istanza di destinazione se il cluster è configurato in modo diverso. L'argomento -A inoltra la connessione dell'agente in modo che la chiave privata nel computer locale venga usata automaticamente. Si noti che l'inoltro dell'agente è una catena, quindi il secondo ssh comando include -A anche in modo che tutte le connessioni SSH successive avviate dall'istanza di destinazione usino anche la chiave privata locale.

Livello applicazione (intermedio)

Il livello applicazione è isolato nella propria subnet. Sono disponibili più macchine virtuali configurate per la tolleranza di errore e la gestione semplificata delle patch. Queste macchine virtuali possono essere supportate con l'archiviazione condivisa offerta da Azure NetApp Files e da unità SSD Ultra. Questa configurazione consente una distribuzione più semplice delle patch senza tempi di inattività. I computer nel livello applicazione devono essere indirizzati da un servizio di bilanciamento del carico pubblico in modo che le richieste al livello applicazione EBS vengano elaborate anche se un computer nel livello è offline a causa di un errore.

Bilanciamento del carico

Un servizio di bilanciamento del carico di Azure consente di distribuire il traffico tra più istanze del carico di lavoro per garantire la disponibilità elevata. In questo caso, viene configurato un servizio di bilanciamento del carico pubblico, perché gli utenti possono accedere all'applicazione EBS sul Web. Il servizio di bilanciamento del carico distribuisce il carico a entrambi i computer nel livello intermedio. Per una maggiore sicurezza, consentire il traffico solo dagli utenti che accedono al sistema dalla rete aziendale usando una VPN da sito a sito o ExpressRoute e gruppi di sicurezza di rete.

Livello database

Questo livello ospita il database Oracle ed è separato nella propria subnet. È consigliabile aggiungere gruppi di sicurezza di rete che consentono solo il traffico dal livello applicazione al livello di database sulla porta del database specifica di Oracle 1521.

Microsoft e Oracle consigliano una configurazione a disponibilità elevata. La disponibilità elevata in Azure può essere ottenuta configurando due database Oracle in due zone di disponibilità con Oracle Data Guard o usando Oracle Database Exadata Cloud Service in OCI. Quando si usa Oracle Database Exadata Cloud Service, il database viene distribuito in due subnet. È anche possibile configurare Oracle Database nelle macchine virtuali in OCI in due domini di disponibilità con Oracle Data Guard.

Livello identità

Il livello identity contiene la macchina virtuale Asserter EBS. EBS Asserter consente di sincronizzare le identità da Oracle Identity Cloud Service (IDCS) e Microsoft Entra ID. EBS Asserter è necessario perché EBS non supporta protocolli di Single Sign-On come SAML 2.0 o OpenID Connect. EBS Asserter utilizza il token di connessione OpenID (generato da IDCS), lo convalida e quindi crea una sessione per l'utente in EBS.

Anche se questa architettura mostra l'integrazione idCS, l'accesso unificato e l'accesso Single Sign-On di Microsoft Entra ID possono essere abilitati anche con Oracle Access Manager con Oracle Internet Directory o Oracle Unified Directory. Per altre informazioni, vedere i white paper sulla distribuzione di Oracle EBS con integrazione IDCS o distribuzione di Oracle EBS con integrazione OAM.

Per la disponibilità elevata, è consigliabile distribuire server ridondanti di EBS Asserter in più zone di disponibilità con un servizio di bilanciamento del carico davanti a esso.

Dopo aver configurato l'infrastruttura, E-Business Suite può essere installato seguendo la guida all'installazione fornita da Oracle.

JD Edwards EnterpriseOne

JD Edwards EnterpriseOne di Oracle è una suite di applicazioni integrata di software di pianificazione delle risorse aziendali completo. Si tratta di un'applicazione a più livelli che può essere configurata con un back-end di database Oracle o SQL Server. Questa sezione illustra i dettagli sulla distribuzione di JD Edwards EnterpriseOne con un back-end del database Oracle in OCI o in Azure.

Nell'architettura consigliata seguente (figura 3), l'amministrazione, la presentazione e i livelli intermedi vengono distribuiti nella rete virtuale in Azure. Il database viene distribuito in una rete cloud virtuale in OCI.

Come per E-Business Suite, è possibile configurare un livello bastion facoltativo per scopi amministrativi sicuri. Usare l'host della macchina virtuale bastion come jump server per accedere alle istanze dell'applicazione e del database.

Figura 3: Architettura cross-cloud di JD Edwards EnterpriseOne

In questa architettura la rete virtuale in Azure è connessa alla rete cloud virtuale in OCI usando l'interconnessione tra cloud. Il livello applicazione è configurato in Azure, mentre il database è configurato in OCI. È consigliabile distribuire ogni componente nella propria subnet con gruppi di sicurezza di rete per consentire il traffico solo da subnet specifiche su porte specifiche.

L'architettura può essere adattata per la distribuzione interamente in Azure con database Oracle a disponibilità elevata configurati usando Oracle Data Guard in due zone di disponibilità in un'area. Il diagramma seguente (figura 4) è un esempio di questo modello architettonico:

Figura 4: Architettura solo Azure di JD Edwards EnterpriseOne

Le sezioni seguenti descrivono i diversi componenti a livello generale.

Livello Bastion

L'host bastion è un componente facoltativo che è possibile usare come jump server per accedere alle istanze dell'applicazione e del database. La macchina virtuale host bastion può avere un indirizzo IP pubblico assegnato, anche se è consigliabile configurare una connessione ExpressRoute o una VPN da sito a sito con la rete locale per l'accesso sicuro. Inoltre, solo SSH (porta 22, Linux) o RDP (porta 3389, Windows Server) deve essere aperto per il traffico in ingresso. Per la disponibilità elevata, distribuire un bastion host in due zone di disponibilità o in un singolo set di disponibilità.

È anche possibile abilitare l'inoltro dell'agente SSH nelle macchine virtuali, che consente di accedere ad altre macchine virtuali nella rete virtuale inoltrando le credenziali dall'host bastion. In alternativa, usare il tunneling SSH per accedere ad altre istanze.

Ecco un esempio di inoltro dell'agente:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Questo comando si connette al bastion e quindi viene eseguito ssh di nuovo immediatamente, quindi si ottiene un terminale nell'istanza di destinazione. Potrebbe essere necessario specificare un utente diverso da root nell'istanza di destinazione se il cluster è configurato in modo diverso. L'argomento -A inoltra la connessione dell'agente in modo che la chiave privata nel computer locale venga usata automaticamente. Si noti che l'inoltro dell'agente è una catena, quindi il secondo ssh comando include -A anche in modo che tutte le connessioni SSH successive avviate dall'istanza di destinazione usino anche la chiave privata locale.

Livello amministrativo

Come suggerisce il nome, questo livello viene usato per le attività amministrative. È possibile ritagliarsi una subnet separata per il livello amministrativo. I servizi e i server in questo livello vengono usati principalmente per l'installazione e l'amministrazione dell'applicazione. Di conseguenza, sono sufficienti singole istanze di questi server. Le istanze ridondanti non sono necessarie per la disponibilità elevata dell'applicazione.

I componenti di questo livello sono i seguenti:

• Server di provisioning : questo server viene usato per la distribuzione end-to-end dei diversi componenti dell'applicazione. Comunica con le istanze negli altri livelli, incluse le istanze nel livello di database, sulla porta 22. Ospita la console di Server Manager per JD Edwards EnterpriseOne.
• Server di distribuzione: questo server è principalmente necessario per l'installazione di JD Edwards EnterpriseOne. Durante il processo di installazione, questo server funge da repository centrale per i file e i pacchetti di installazione necessari. Il software viene distribuito o distribuito ad altri server e client da questo server.
• Client di sviluppo: questo server contiene componenti eseguiti in un Web browser e in applicazioni native.

Livello presentazione

Questo livello contiene vari componenti, ad esempio Application Interface Services (AIS), Application Development Framework (ADF) e Java Application Servers (JAS). I server in questo livello comunicano con i server nel livello intermedio front-end da un servizio di bilanciamento del carico che instrada il traffico al server necessario in base al numero di porta e all'URL in cui viene ricevuto il traffico. È consigliabile distribuire più istanze di ogni tipo di server per la disponibilità elevata.

Di seguito sono riportati i componenti di questo livello:

• Application Interface Services (AIS): il server AIS fornisce l'interfaccia di comunicazione tra applicazioni aziendali per dispositivi mobili JD Edwards EnterpriseOne e JD Edwards EnterpriseOne.
• Java Application Server (JAS): jas riceve le richieste dal servizio di bilanciamento del carico e lo passa al livello intermedio per eseguire attività complesse. JAS ha la possibilità di eseguire una semplice logica di business.
• BI Publisher Server (BIP): questo server presenta report basati sui dati raccolti dall'applicazione JD Edwards EnterpriseOne. È possibile progettare e controllare il modo in cui il report presenta i dati in base a modelli diversi.
• Business Services Server (BSS): il servizio BSS consente lo scambio di informazioni e l'interoperabilità con altre applicazioni Oracle.
• Server eventi in tempo reale (RTE): il server RTE consente di configurare notifiche ai sistemi esterni sulle transazioni che si verificano nel sistema JDE EnterpriseOne. Usa un modello di sottoscrittore e consente ai sistemi di terze parti di sottoscrivere gli eventi. Per bilanciare il carico delle richieste a entrambi i server RTE, assicurarsi che i server si trovino in un cluster.
• Server Application Development Framework (ADF): il server ADF viene usato per eseguire applicazioni JD Edwards EnterpriseOne sviluppate con Oracle ADF. Questo server viene distribuito in un server Oracle WebLogic con runtime di Azure Data Factory.

Livello intermedio

Il livello intermedio contiene il server per la logica e il server batch. In questo caso, entrambi i server vengono installati nella stessa macchina virtuale. Per gli scenari di produzione, è consigliabile distribuire il server per la logica e il server batch in server separati. Più server vengono distribuiti nel livello intermedio tra due zone di disponibilità per una maggiore disponibilità. È necessario creare un servizio di bilanciamento del carico di Azure e inserire questi server nel pool back-end per assicurarsi che entrambi i server siano attivi e che eselaborino le richieste.

I server nel livello intermedio ricevono richieste dai server nel livello presentazione e solo dal servizio di bilanciamento del carico pubblico. Le regole del gruppo di sicurezza di rete devono essere configurate per negare il traffico da qualsiasi indirizzo diverso dalla subnet del livello presentazione e dal servizio di bilanciamento del carico. È anche possibile configurare una regola del gruppo di sicurezza di rete per consentire il traffico sulla porta 22 dall'host bastion a scopo di gestione. Potrebbe essere possibile usare il servizio di bilanciamento del carico pubblico per bilanciare il carico delle richieste tra le macchine virtuali nel livello intermedio.

I due componenti seguenti si trovano nel livello intermedio:

• Server per la logica: contiene la logica di business o le funzioni business.
• Server Batch - Usato per l'elaborazione batch

Livello database

Il livello Database contiene le istanze di database per l'applicazione. Il database può essere un database Oracle, Oracle RAC o un sistema di database Oracle Exadata.

Se si vuole usare Oracle DB, l'istanza del database può essere distribuita in Azure tramite le immagini di Oracle DB disponibili in Azure Marketplace. In alternativa, è possibile usare l'interconnessione tra Azure e OCI per distribuire Oracle DB in un modello PaaS in OCI.

Per Oracle RAC, è possibile usare OCI nel modello PaaS. È consigliabile usare un sistema RAC a due nodi. Sebbene sia possibile distribuire Oracle RAC in Azure CloudSimple nel modello IaaS, non è una configurazione supportata da Oracle. Fare riferimento ai programmi Oracle idonei per gli ambienti cloud autorizzati.

Infine, per i sistemi Exadata, usare l'interconnessione OCI e distribuire il sistema Exadata in OCI. Il diagramma dell'architettura precedente mostra un sistema Exadata distribuito in OCI tra due subnet.

Per gli scenari di produzione, distribuire più istanze del database tra due zone di disponibilità (se si distribuisce in Azure) o due domini di disponibilità (in OCI). Usare Oracle Active Data Guard per sincronizzare i database primari e di standby.

Il livello database riceve solo le richieste dal livello intermedio. È consigliabile configurare un gruppo di sicurezza di rete (elenco di sicurezza se si distribuisce il database in OCI) per consentire solo le richieste sulla porta 1521 dal livello intermedio e dalla porta 22 dal server bastion per motivi amministrativi.

Per i database distribuiti in OCI, è necessario configurare una rete cloud virtuale separata con un gateway di routing dinamico (DRG) connesso al circuito FastConnect.

Livello identità

La partnership tra Microsoft e Oracle consente di configurare un'identità unificata tra Azure, OCI e l'applicazione Oracle. Per la famiglia di applicazioni JD Edwards EnterpriseOne o PeopleSoft, è necessaria un'istanza di Oracle HTTP Server (OHS) per configurare l'accesso Single Sign-On tra Microsoft Entra ID e Oracle IDCS.

OHS funge da proxy inverso per il livello applicazione, vale a dire che tutte le richieste alle applicazioni finali passano attraverso di esso. Oracle Access Manager WebGate è un plug-in del server Web OHS che intercetta ogni richiesta indirizzata all'applicazione finale. Se si accede a una risorsa protetta (ossia che richiede una sessione autenticata), WebGate avvia il flusso di autenticazione OIDC con Identity Cloud Service tramite il browser dell'utente. Per altre informazioni sui flussi supportati da OpenID Connect WebGate, vedere la documentazione di Oracle Access Manager.

Con questa configurazione, un utente già connesso a Microsoft Entra ID può passare all'applicazione JD Edwards EnterpriseOne o PeopleSoft senza eseguire di nuovo l'accesso tramite Oracle Identity Cloud Service. I clienti che distribuiscono questa soluzione usufruiscono dei vantaggi del Single Sign-On, tra cui un singolo set di credenziali, un'esperienza di accesso migliorata, una maggiore sicurezza e una riduzione dei costi di help desk.

Per altre informazioni sulla configurazione dell'accesso Single Sign-On per JD Edwards EnterpriseOne o PeopleSoft con Microsoft Entra ID, vedere il white paper Oracle associato.

PeopleSoft

La suite di applicazioni PeopleSoft di Oracle contiene software per le risorse umane e la gestione finanziaria. La suite di applicazioni è multilivello e le applicazioni includono sistemi di gestione delle risorse umane (HRMS), CRM (Customer Relationship Management), financials and supply chain management (FSCM) e Enterprise Performance Management (EPM).

È consigliabile distribuire ogni livello della suite di software nella propria subnet. Un database Oracle o Microsoft SQL Server è necessario come database back-end per l'applicazione. Questa sezione illustra i dettagli sulla distribuzione di PeopleSoft con un back-end del database Oracle.

Il diagramma seguente illustra un'architettura canonica per la distribuzione della suite di applicazioni PeopleSoft in un'architettura tra cloud (figura 5).

Figura 5: Architettura multi-cloud PeopleSoft

In questa architettura di esempio la rete virtuale in Azure è connessa alla rete cloud virtuale in OCI usando l'interconnessione tra cloud. Il livello applicazione è configurato in Azure, mentre il database è configurato in OCI. È consigliabile distribuire ogni componente nella propria subnet con gruppi di sicurezza di rete per consentire il traffico solo da subnet specifiche su porte specifiche.

L'architettura può anche essere adattata per la distribuzione interamente in Azure con database Oracle a disponibilità elevata configurati usando Oracle Data Guard in due zone di disponibilità in un'area. Il diagramma seguente (figura 6) è un esempio di questo modello architettonico:

Figura 6: Architettura solo PeopleSoft Azure

Le sezioni seguenti descrivono i diversi componenti a livello generale.

Livello Bastion

L'host bastion è un componente facoltativo che è possibile usare come jump server per accedere alle istanze dell'applicazione e del database. La macchina virtuale host bastion può avere un indirizzo IP pubblico assegnato, anche se è consigliabile configurare una connessione ExpressRoute o una VPN da sito a sito con la rete locale per l'accesso sicuro. Inoltre, solo SSH (porta 22, Linux) o RDP (porta 3389, Windows Server) deve essere aperto per il traffico in ingresso. Per la disponibilità elevata, distribuire un bastion host in due zone di disponibilità o in un singolo set di disponibilità.

È anche possibile abilitare l'inoltro dell'agente SSH nelle macchine virtuali, che consente di accedere ad altre macchine virtuali nella rete virtuale inoltrando le credenziali dall'host bastion. In alternativa, usare il tunneling SSH per accedere ad altre istanze.

Ecco un esempio di inoltro dell'agente:

ssh -A -t user@BASTION_SERVER_IP ssh -A root@TARGET_SERVER_IP`

Questo comando si connette al bastion e quindi viene eseguito ssh di nuovo immediatamente, quindi si ottiene un terminale nell'istanza di destinazione. Potrebbe essere necessario specificare un utente diverso da root nell'istanza di destinazione se il cluster è configurato in modo diverso. L'argomento -A inoltra la connessione dell'agente in modo che la chiave privata nel computer locale venga usata automaticamente. Si noti che l'inoltro dell'agente è una catena, quindi il secondo ssh comando include -A anche in modo che tutte le connessioni SSH successive avviate dall'istanza di destinazione usino anche la chiave privata locale.

Livello applicazione

Il livello applicazione contiene istanze dei server applicazioni PeopleSoft, dei server Web PeopleSoft, della ricerca elastica e dell'utilità di pianificazione dei processi PeopleSoft. Un servizio di bilanciamento del carico di Azure è configurato per accettare le richieste degli utenti, indirizzate al server appropriato nel livello applicazione.

Per la disponibilità elevata, è consigliabile configurare istanze ridondanti di ogni server nel livello applicazione in zone di disponibilità diverse. Il servizio di bilanciamento del carico di Azure può essere configurato con più pool back-end per indirizzare ogni richiesta al server corretto.

PeopleTools Client

Il client PeopleTools viene usato per eseguire attività di amministrazione, ad esempio sviluppo, migrazione e aggiornamento. Poiché il client PeopleTools non è necessario per ottenere una disponibilità elevata dell'applicazione, non sono necessari server ridondanti del client PeopleTools.

Livello database

Il livello Database contiene le istanze di database per l'applicazione. Il database può essere un database Oracle, Oracle RAC o un sistema di database Oracle Exadata.

Se si vuole usare Oracle DB, l'istanza del database può essere distribuita in Azure tramite le immagini di Oracle DB disponibili in Azure Marketplace. In alternativa, è possibile usare l'interconnessione tra Azure e OCI per distribuire Oracle DB in un modello PaaS in OCI.

Per Oracle RAC, è possibile usare OCI nel modello PaaS. È consigliabile usare un sistema RAC a due nodi. Sebbene sia possibile distribuire Oracle RAC in Azure CloudSimple nel modello IaaS, non è una configurazione supportata da Oracle. Fare riferimento ai programmi Oracle idonei per gli ambienti cloud autorizzati.

Infine, per i sistemi Exadata, usare l'interconnessione OCI e distribuire il sistema Exadata in OCI. Il diagramma dell'architettura precedente mostra un sistema Exadata distribuito in OCI tra due subnet.

Per gli scenari di produzione, distribuire più istanze del database tra due zone di disponibilità (se si distribuisce in Azure) o due domini di disponibilità (in OCI). Usare Oracle Active Data Guard per sincronizzare i database primari e di standby.

Il livello database riceve solo le richieste dal livello intermedio. È consigliabile configurare un gruppo di sicurezza di rete (elenco di sicurezza se si distribuisce il database in OCI) per consentire solo le richieste sulla porta 1521 dal livello intermedio e dalla porta 22 dal server bastion per motivi amministrativi.

Per i database distribuiti in OCI, è necessario configurare una rete cloud virtuale separata con un gateway di routing dinamico (DRG) connesso al circuito FastConnect.

Livello identità

La partnership tra Microsoft e Oracle consente di configurare un'identità unificata tra Azure, OCI e l'applicazione Oracle. Per la famiglia di applicazioni JD Edwards EnterpriseOne o PeopleSoft, è necessaria un'istanza di Oracle HTTP Server (OHS) per configurare l'accesso Single Sign-On tra Microsoft Entra ID e Oracle IDCS.

OHS funge da proxy inverso per il livello applicazione, vale a dire che tutte le richieste alle applicazioni finali passano attraverso di esso. Oracle Access Manager WebGate è un plug-in del server Web OHS che intercetta ogni richiesta indirizzata all'applicazione finale. Se si accede a una risorsa protetta (ossia che richiede una sessione autenticata), WebGate avvia il flusso di autenticazione OIDC con Identity Cloud Service tramite il browser dell'utente. Per altre informazioni sui flussi supportati da OpenID Connect WebGate, vedere la documentazione di Oracle Access Manager.

Con questa configurazione, un utente già connesso a Microsoft Entra ID può passare all'applicazione JD Edwards EnterpriseOne o PeopleSoft senza eseguire di nuovo l'accesso tramite Oracle Identity Cloud Service. I clienti che distribuiscono questa soluzione usufruiscono dei vantaggi del Single Sign-On, tra cui un singolo set di credenziali, un'esperienza di accesso migliorata, una maggiore sicurezza e una riduzione dei costi di help desk.

Per altre informazioni sulla configurazione dell'accesso Single Sign-On per JD Edwards EnterpriseOne o PeopleSoft con Microsoft Entra ID, vedere il white paper Oracle associato.

Passaggi successivi

Usare gli script Terraform per configurare le app Oracle in Azure e stabilire la connettività tra cloud con OCI.

Per altre informazioni e white paper su OCI, vedere la documentazione di Oracle Cloud.