Arquitecturas para aplicaciones de Oracle con Azure Virtual Machines con base de datos en OCI

Se aplica a: ✔️ Máquinas virtuales Linux

Microsoft y Oracle trabajan en conjunto para permitir que los clientes implementen aplicaciones de Oracle como E-Business Suite, JD Edwards EnterpriseOne y PeopleSoft en la nube. Con la introducción de la interconectividad de red privada entre Microsoft Azure y Oracle Cloud Infrastructure (OCI), las aplicaciones de Oracle se pueden implementar en Azure con sus bases de datos de back-end en Azure o en OCI. Las aplicaciones de Oracle también se pueden integrar con Microsoft Entra ID, lo que le permite configurar el inicio de sesión único para que los usuarios puedan iniciar sesión en la aplicación Oracle con sus credenciales de Microsoft Entra.

OCI ofrece varias opciones de bases de datos de Oracle para las aplicaciones de Oracle, como DBaaS, Exadata Cloud Service, Oracle RAC e Infraestructura como servicio (IaaS). Actualmente, Autonomous Database no es un back-end compatible con las aplicaciones de Oracle.

Existen varias opciones para implementar las aplicaciones de Oracle en Azure, incluso de una manera altamente disponible y segura. Azure también ofrece imágenes de VM de bases de datos de Oracle que puede implementar si elige ejecutar las aplicaciones de Oracle completamente en Azure.

En las secciones siguientes se describen las recomendaciones de arquitectura tanto de Microsoft como de Oracle para implementar Oracle E-Business Suite, JD Edwards EnterpriseOne y PeopleSoft en una configuración entre nubes o completamente en Azure. Microsoft y Oracle probaron estas aplicaciones y confirmaron que el rendimiento cumple con los estándares que Oracle establece para estas aplicaciones.

Consideraciones sobre la arquitectura

Las aplicaciones de Oracle constan de varios servicios, los que pueden estar hospedados en la misma máquina virtual o en varias máquinas virtuales en Azure y, de manera opcional, en OCI.

Las instancias de las aplicaciones se pueden configurar con puntos de conexión privados o públicos. Microsoft y Oracle recomiendan configurar una máquina virtual host bastión con una dirección IP pública en una subred independiente para la administración de la aplicación. Luego, asigne solo direcciones IP privadas a las otras máquinas, incluido el nivel de base de datos.

Al configurar una aplicación en una arquitectura entre nubes, es necesario planear para garantizar que el espacio de direcciones IP de la red virtual de Azure no se superponga con el espacio de direcciones IP privadas de la red de la nube virtual de OCI.

Para mayor seguridad, configure los grupos de seguridad de red en un nivel de subred para garantizar que solo se permita el tráfico en direcciones IP y puertos específicos. Por ejemplo, las máquinas en el nivel intermedio solo deberían recibir tráfico desde dentro de la red virtual. Ningún tráfico externo debería llegar directamente a las máquinas del nivel intermedio.

Para lograr una alta disponibilidad, puede configurar instancias redundantes en los distintos servidores del mismo conjunto de disponibilidad o en distintas zonas de disponibilidad. Las zonas de disponibilidad le permiten alcanzar un SLA con un tiempo de actividad del 99,99 %, mientras que los conjuntos de disponibilidad le permiten alcanzar un SLA con un tiempo de actividad del 99,95 % en la región. Las arquitecturas de ejemplo que se muestran en este artículo se implementan en dos zonas de disponibilidad.

Al implementar una aplicación mediante la interconexión entre nubes, puede seguir usando un circuito ExpressRoute existente para conectar el entorno de Azure a la red local. Sin embargo, necesita un circuito ExpressRoute independiente para la interconexión con OCI del circuito que se conecta a la red local.

E-Business Suite

Oracle E-Business Suite (EBS) es un conjunto de aplicaciones entre las que se incluyen la administración de cadenas de suministros (SCM) y la gestión de relaciones con el cliente (CRM). Para aprovechar la cartera de bases de datos administradas de OCI, EBS también se puede implementar mediante la interconexión entre nubes entre Microsoft Azure y OCI. En esta configuración, los niveles de presentación y de aplicación se ejecutan en Azure y el nivel de base de datos, en OCI, tal como se muestra en el diagrama de arquitectura siguiente (Figura 1).

Figura 1: Arquitectura entre nubes de E-Business Suite

En esta arquitectura, la red virtual de Azure está conectada a una red de nube virtual en OCI mediante la interconexión entre nubes. La capa de aplicación está configurada en Azure, mientras que la base de datos se configura en OCI. La recomendación es implementar cada componente en su propia subred con grupos de seguridad de red para permitir el tráfico solo proveniente de subredes específicas en puertos específicos.

La arquitectura se puede adaptar para la implementación completamente en Azure con bases de datos de Oracle altamente disponibles configuradas mediante Oracle Data Guard en dos zonas de disponibilidad en una región. El diagrama siguiente (Figura 2) es un ejemplo de este patrón de arquitectura:

Figura 2: Arquitectura de E-Business Suite solo para Azure

En las secciones siguientes se describen los distintos componentes en un nivel alto.

Nivel de bastión

El host bastión es un componente opcional que puede usar como un servidor de salto para acceder a las instancias de aplicación y de base de datos. La máquina virtual host bastión puede tener asignada una dirección IP pública, a pesar de que la recomendación es configurar una VPN de sitio a sitio o una conexión de ExpressRoute con la red local para un acceso seguro. Además, solo se debe abrir SSH (puerto 22, Linux) o RDP (puerto 3389, Windows Server) para el tráfico entrante. Para lograr alta disponibilidad, implemente un host bastión en dos zonas de disponibilidad o en un conjunto de disponibilidad único.

También puede habilitar el desvío del agente SSH en las máquinas virtuales, lo que le permitirá acceder a otras máquinas virtuales de la red virtual si desvía las credenciales desde el host bastión. O bien, use la tunelización de SSH para acceder a otras instancias.

Este es un ejemplo de desvío del agente:

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

Este comando se conecta al bastión y, luego, de inmediato ejecuta ssh nuevamente, por lo que se obtiene un terminal en la instancia de destino. Es posible que tenga que especificar un usuario distinto de la raíz en la instancia de destino si el clúster se configuró de manera distinta. El argumento -A desvía la conexión del agente para que la clave privada de la máquina local se use automáticamente. Tenga en cuenta que el desvío del agente es una cadena, por lo que el segundo comando ssh también incluye -A para que toda conexión SSH subsiguiente iniciada desde la instancia de destino también use la clave privada local.

Capa de aplicación (intermedia)

La capa de aplicación está aislada en su propia subred. Hay varias máquinas virtuales configuradas para la tolerancia a errores y una administración de revisiones sencilla. Estas máquinas virtuales se pueden respaldar con almacenamiento compartido ofrecido por Azure NetApp Files y el almacenamiento en discos Ultra. Esta configuración permite simplificar la implementación de las revisiones sin tiempo de inactividad. Las máquinas de la capa de aplicación deben estar controladas por un equilibrador de carga público para que las solicitudes a la capa de aplicación de EBS se procesen incluso si una máquina de la capa está sin conexión debido a un error.

Equilibrador de carga

Un equilibrador de carga de Azure le permite distribuir el tráfico entre varias instancias de la carga de trabajo para garantizar una alta disponibilidad. En este caso, se configura un equilibrador de carga público porque los usuarios pueden acceder a la aplicación de EBS a través de la Web. El equilibrador de carga distribuye la carga en ambas máquinas en el nivel intermedio. Para mayor seguridad, permita el tráfico solo de los usuarios que acceden al sistema desde la red corporativa mediante una VPN de sitio a sitio o ExpressRoute y grupos de seguridad de red.

Nivel de base de datos

Este nivel hospeda la base de datos de Oracle y se encuentra aislado en su propia subred. La recomendación es agregar grupos de seguridad de red que solo permitan el tráfico desde la capa de aplicación al nivel de base de datos en el puerto 1521 de la base de datos específica de Oracle.

Microsoft y Oracle recomienda una configuración de alta disponibilidad. La alta disponibilidad en Azure se puede lograr mediante la configuración de dos bases de datos de Oracle en dos zonas de disponibilidad con Oracle Data Guard, o bien mediante Oracle Database Exadata Cloud Service en OCI. Cuando se usa Oracle Database Exadata Cloud Service, la base de datos se implementa en dos subredes. También puede configurar Oracle Database en VM en OCI en dos dominios de disponibilidad con Oracle Data Guard.

Nivel de identidad

El nivel de identidad contiene la máquina virtual de EBS Asserter. EBS Asserter permite sincronizar identidades de Oracle Identity Cloud Service (IDCS) y Microsoft Entra ID. EBS Asserter es necesario porque EBS no admite protocolos de inicio de sesión único como SAML 2.0 ni OpenID Connect. EBS Asserter usa el token de OpenID Connect (generado por IDCS), lo valida y luego crea una sesión para el usuario en EBS.

Si bien esta arquitectura muestra la integración de IDCS, también se puede habilitar el inicio de sesión único y el acceso unificado de Microsoft Entra ID con Oracle Access Manager con Oracle Internet Directory u Oracle Unified Directory. Para más información, consulte las notas sobre la implementación de Oracle EBS con la integración de IDCS o la implementación de Oracle EBS con la integración de OAM.

Para lograr una alta disponibilidad, la recomendación es implementar servidores redundantes de EBS Asserter en varias zonas de disponibilidad con un equilibrador de carga delante.

Una vez configurada la infraestructura, es posible instalar E-Business Suite según la guía de instalación que proporciona Oracle.

JD Edwards EnterpriseOne

JD Edwards EnterpriseOne de Oracle es un conjunto integrado de aplicaciones de software de planeamiento de recursos empresariales integral. Se trata de una aplicación de varios niveles que se puede configurar con un back-end de base de datos de Oracle o de SQL Server. En esta sección se describen los detalles de la implementación de JD Edwards EnterpriseOne con un back-end de base de datos de Oracle en OCI o en Azure.

En la arquitectura recomendada siguiente (Figura 3), los niveles de administración, presentación e intermedio se implementan en la red virtual de Azure. La base de datos se implementa en una red de nube virtual en OCI.

Al igual que con E-Business Suite, puede configurar un nivel de bastión opcional con fines administrativos seguros. Use el host de máquina virtual como servidor de salto para acceder a las instancias de aplicación y base de datos.

Figura 3: Arquitectura entre nubes de JD Edwards EnterpriseOne

En esta arquitectura, la red virtual de Azure está conectada a la red de nube virtual en OCI mediante la interconexión entre nubes. La capa de aplicación está configurada en Azure, mientras que la base de datos se configura en OCI. La recomendación es implementar cada componente en su propia subred con grupos de seguridad de red para permitir el tráfico solo proveniente de subredes específicas en puertos específicos.

La arquitectura se puede adaptar para la implementación completamente en Azure con bases de datos de Oracle altamente disponibles configuradas mediante Oracle Data Guard en dos zonas de disponibilidad en una región. El diagrama siguiente (Figura 4) es un ejemplo de este patrón de arquitectura:

Figura 4: Arquitectura de JD Edwards EnterpriseOne solo para Azure

En las secciones siguientes se describen los distintos componentes en un nivel alto.

Nivel de bastión

El host bastión es un componente opcional que puede usar como un servidor de salto para acceder a las instancias de aplicación y de base de datos. La máquina virtual host bastión puede tener asignada una dirección IP pública, a pesar de que la recomendación es configurar una VPN de sitio a sitio o una conexión de ExpressRoute con la red local para un acceso seguro. Además, solo se debe abrir SSH (puerto 22, Linux) o RDP (puerto 3389, Windows Server) para el tráfico entrante. Para lograr alta disponibilidad, implemente un host bastión en dos zonas de disponibilidad o en un conjunto de disponibilidad único.

También puede habilitar el desvío del agente SSH en las máquinas virtuales, lo que le permitirá acceder a otras máquinas virtuales de la red virtual si desvía las credenciales desde el host bastión. O bien, use la tunelización de SSH para acceder a otras instancias.

Este es un ejemplo de desvío del agente:

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

Este comando se conecta al bastión y, luego, de inmediato ejecuta ssh nuevamente, por lo que se obtiene un terminal en la instancia de destino. Es posible que tenga que especificar un usuario distinto de la raíz en la instancia de destino si el clúster se configuró de manera distinta. El argumento -A desvía la conexión del agente para que la clave privada de la máquina local se use automáticamente. Tenga en cuenta que el desvío del agente es una cadena, por lo que el segundo comando ssh también incluye -A para que toda conexión SSH subsiguiente iniciada desde la instancia de destino también use la clave privada local.

Nivel de administración

Tal como sugiere el nombre, este nivel se usa para las tareas administrativas. Puede establecer una subred independiente para el nivel de administración. Los servicios y servidores de este nivel se usan principalmente para la instalación y la administración de la aplicación. Por lo tanto, es suficiente con instancias únicas de estos servidores. No se requieren instancias redundantes para la alta disponibilidad de la aplicación.

Los componentes de este nivel son los siguientes:

• Servidor de aprovisionamiento: este servidor se usa para la implementación total de los distintos componentes de la aplicación. Se comunica con las instancias en los otros niveles, incluidas las instancias en el nivel de base de datos, a través del puerto 22. Hospeda la consola del Administrador del servidor para JD Edwards EnterpriseOne.
• Servidor de implementación: este servidor se requiere principalmente para la instalar de JD Edwards EnterpriseOne. Durante el proceso de instalación, este servidor actúa como el repositorio central de los paquetes de instalación y archivos requeridos. El software se distribuye o implementa en los demás servidores y clientes desde este servidor.
• Cliente de desarrollo: este servidor contiene componentes que se ejecutan en un explorador web, así como también aplicaciones nativas.

Nivel de presentación

Este nivel contiene varios componentes, como AIS (servicios de interfaz de aplicaciones), ADF (marco de desarrollo de aplicaciones) y JAS (servidores de aplicaciones de Java). Los servidores de este nivel se comunican con los servidores del nivel intermedio y son dirigidos por un equilibrador de carga que enruta el tráfico al servidor necesario según el número de puerto y la dirección URL en que se recibe el tráfico. Se recomienda implementar varias instancias de cada tipo de servidor para lograr la alta disponibilidad.

Los componentes de este nivel son los siguientes:

• AIS, servicios de interfaz de aplicaciones: el servidor de AIS proporciona la interfaz de comunicación entre las aplicaciones empresariales móviles de JD Edwards EnterpriseOne y JD Edwards EnterpriseOne.
• JAS, servidor de aplicaciones de Java: JAS recibe las solicitudes del equilibrador de carga y las transmite al nivel intermedio para ejecutar tareas complicadas. JAS tiene la capacidad de ejecutar una lógica de negocios sencilla.
• BIP, servidor de publicador de BI: este servidor presenta informes basados en los datos que recopila la aplicación JD Edwards EnterpriseOne. Puede diseñar y controlar la manera en que el informe presenta los datos en función de distintas plantillas.
• Servidor de servicios de negocio (BSS): BSS permite el intercambio de información y la interoperabilidad con otras aplicaciones de Oracle.
• RTE, servidor de eventos en tiempo real: el servidor RTE permite configurar notificaciones para los sistemas externos sobre las transacciones que se realizan en el sistema de JDE EnterpriseOne. Usa un modelo de suscriptor y permite que los sistemas de terceros se suscriban a los eventos. Para equilibrar la carga de las solicitudes a ambos servidores de RTE, asegúrese de que los servidores estén en un clúster.
• Servidor ADF, marco de desarrollo de aplicaciones: el servidor ADF se usa para ejecutar aplicaciones de JD Edwards EnterpriseOne desarrolladas con Oracle ADF. Este servidor se implementa en un servidor Oracle WebLogic con runtime de ADF.

Nivel intermedio

El nivel intermedio contiene el servidor lógico y el servidor de procesos por lotes. En este caso, ambos servidores están instalados en la misma máquina virtual. En escenarios de producción, la recomendación es implementar el servidor lógico y el servidor por lotes en servidores independientes. Son varios los servidores implementados en el nivel intermedio en dos zonas de disponibilidad para una mayor disponibilidad. Se debe crear un equilibrador de carga de Azure y estos servidores se deben colocar en su grupo de back-end para garantizar que ambos servidores estén activos y procesen las solicitudes.

Los servidores del nivel intermedio solo reciben solicitudes provenientes de los servidores en el nivel de presentación y del equilibrador de carga público. Es necesario configurar reglas de los grupos de seguridad de red para denegar el tráfico proveniente de cualquier dirección distinta de la subred del nivel de presentación y del equilibrador de carga. También se puede configurar una regla de NSG para permitir el tráfico en el puerto 22 proveniente del host bastión con fines administrativos. Es posible usar el equilibrador de carga público para equilibrar la carga de las solicitudes entre las máquinas virtuales del nivel intermedio.

Estos dos componentes se encuentran en el nivel intermedio:

• Servidor lógico: contiene la lógica de negocios o las funciones de negocios.
• Servidor de procesos por lotes: se usa para el procesamiento por lotes.

Nivel de base de datos

El nivel de base de datos contiene las instancias de base de datos para la aplicación. La base de datos puede ser una instancia de Oracle DB, Oracle RAC o un sistema de Oracle Exadata Database.

Si la opción es usar Oracle DB, la instancia de base de datos se puede implementar en Azure a través de las imágenes de Oracle DB disponibles en Azure Marketplace. Como alternativa, puede usar la interconexión entre Azure y OCI para implementar Oracle DB en un modelo de PaaS en OCI.

Para Oracle RAC, puede usar OCI en el modelo de PaaS. Se recomienda usar un sistema de RAC de dos nodos. Aunque es posible implementar Oracle RAC en Azure CloudSimple en el modelo IaaS, Oracle no es una configuración admitida. Consulte Programas de Oracle válidos para entornos de nube autorizados.

Por último, en el caso de los sistemas de Exadata, use la interconexión de OCI e implemente el sistema de Exadata en OCI. En el diagrama de arquitectura anterior se muestra un sistema de Exadata implementado en OCI en dos subredes.

En el caso de los escenarios de producción, implemente varias instancias de la base de datos en dos zonas de disponibilidad (si se implementa en Azure) o en dos dominios de disponibilidad (en OCI). Use Oracle Active Data Guard para sincronizar las base de datos principal y la que está en espera.

El nivel de base de datos solo recibe solicitudes del nivel intermedio. Se recomienda configurar un grupo de seguridad de red (lista de seguridad si la base de datos se implementa en OCI) para permitir solo solicitudes en el puerto 1521 del nivel intermedio y en el puerto 22 del servidor bastión por motivos administrativos.

En el caso de las bases de datos implementadas en OCI, se debe configurar una red de nube virtual independiente con una puerta de enlace de enrutamiento dinámico (DRG) que esté conectada al circuito de FastConnect.

Nivel de identidad

La asociación entre Microsoft y Oracle le permite configurar una identidad unificada entre Azure, OCI y la aplicación de Oracle. Para el conjunto de aplicaciones de PeopleSoft o JD Edwards EnterpriseOne, se necesita una instancia del servidor HTTP de Oracle (OHS) para configurar el inicio de sesión único entre Microsoft Entra ID y Oracle IDCS.

OHS actúa como un proxy inverso a la capa de aplicación, lo que significa que todas las solicitudes a las aplicaciones finales pasan por él. Oracle Access Manager WebGate es un complemento del servidor web de OHS que intercepta cada solicitud que va a una aplicación final. Si un recurso al que se está accediendo está protegido (requiere una sesión autenticada), WebGate inicia el flujo de autenticación de OIDC con Identity Cloud Service a través del explorador del usuario. Para más información sobre los flujos compatibles con WebGate de OpenID Connect, consulte la documentación de Oracle Access Manager.

Con esta configuración, un usuario que ya haya iniciado sesión en Microsoft Entra ID puede navegar a la aplicación de PeopleSoft o JD Edwards EnterpriseOne sin tener que volver a iniciar sesión, a través de Oracle Identity Cloud Service. Los clientes que implementen esta solución obtienen las ventajas del inicio de sesión único, incluido un conjunto de credenciales único, una mejor experiencia de inicio de sesión, mayor seguridad y un menor costo del departamento de soporte técnico.

Para más información sobre cómo configurar el inicio de sesión único para JD Edwards EnterpriseOne o PeopleSoft con Microsoft Entra ID, consulte las notas del producto de Oracle asociadas.

PeopleSoft

El conjunto de aplicaciones PeopleSoft de Oracle contiene software para la administración financiera y de recursos humanos. El conjunto de aplicaciones tiene varios niveles y las aplicaciones incluyen sistemas de administración de recursos humanos (HRMS), administración de finanzas y cadenas de suministros (FSCM) y administración del rendimiento empresarial (EPM).

La recomendación es que cada nivel del conjunto de software se implemente en su propia subred. Se necesita una base de datos de Oracle o una instancia de Microsoft SQL Server como la base de datos de back-end para la aplicación. En esta sección se analizan los detalles de la implementación de PeopleSoft con un back-end de base de datos de Oracle.

El siguiente diagrama muestra una arquitectura canónica para implementar el conjunto de aplicaciones de PeopleSoft en una arquitectura entre nubes (Figura 5).

Figura 5: Arquitectura entre nubes de PeopleSoft

En esta arquitectura de ejemplo, la red virtual de Azure está conectada a la red de nube virtual en OCI mediante la interconexión entre nubes. La capa de aplicación está configurada en Azure, mientras que la base de datos se configura en OCI. La recomendación es implementar cada componente en su propia subred con grupos de seguridad de red para permitir el tráfico solo proveniente de subredes específicas en puertos específicos.

La arquitectura también se puede adaptar para la implementación completamente en Azure con bases de datos de Oracle altamente disponibles configuradas mediante Oracle Data Guard en dos zonas de disponibilidad en una región. El diagrama siguiente (Figura 6) es un ejemplo de este patrón de arquitectura:

Figura 6: Arquitectura de PeopleSoft solo para Azure

En las secciones siguientes se describen los distintos componentes en un nivel alto.

Nivel de bastión

El host bastión es un componente opcional que puede usar como un servidor de salto para acceder a las instancias de aplicación y de base de datos. La máquina virtual host bastión puede tener asignada una dirección IP pública, a pesar de que la recomendación es configurar una VPN de sitio a sitio o una conexión de ExpressRoute con la red local para un acceso seguro. Además, solo se debe abrir SSH (puerto 22, Linux) o RDP (puerto 3389, Windows Server) para el tráfico entrante. Para lograr alta disponibilidad, implemente un host bastión en dos zonas de disponibilidad o en un conjunto de disponibilidad único.

También puede habilitar el desvío del agente SSH en las máquinas virtuales, lo que le permitirá acceder a otras máquinas virtuales de la red virtual si desvía las credenciales desde el host bastión. O bien, use la tunelización de SSH para acceder a otras instancias.

Este es un ejemplo de desvío del agente:

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

Este comando se conecta al bastión y, luego, de inmediato ejecuta ssh nuevamente, por lo que se obtiene un terminal en la instancia de destino. Es posible que tenga que especificar un usuario distinto de la raíz en la instancia de destino si el clúster se configuró de manera distinta. El argumento -A desvía la conexión del agente para que la clave privada de la máquina local se use automáticamente. Tenga en cuenta que el desvío del agente es una cadena, por lo que el segundo comando ssh también incluye -A para que toda conexión SSH subsiguiente iniciada desde la instancia de destino también use la clave privada local.

Nivel de aplicación

La capa de aplicación contiene instancias de los servidores de aplicación de PeopleSoft, servidores web de PeopleSoft, búsqueda elástica y el programador de procesos de PeopleSoft. Un equilibrador de carga de Azure está configurado para aceptar solicitudes de los usuarios que se enrutan al servidor adecuado en la capa de aplicación.

Para lograr una alta disponibilidad, considere la posibilidad de configurar instancias redundantes de cada servidor en la capa de aplicación en distintas zonas de disponibilidad. El equilibrador de carga de Azure se puede configurar con varios grupos de back-end para dirigir cada solicitud al servidor correcto.

Cliente de PeopleTools

El cliente de PeopleTools se usa para realizar las actividades de administración, como desarrollo, migración y actualización. Como el cliente de PeopleTools no es necesario para lograr la alta disponibilidad de la aplicación, los servidores redundantes del cliente de PeopleTools no son necesarios.

Nivel de base de datos

El nivel de base de datos contiene las instancias de base de datos para la aplicación. La base de datos puede ser una instancia de Oracle DB, Oracle RAC o un sistema de Oracle Exadata Database.

Si la opción es usar Oracle DB, la instancia de base de datos se puede implementar en Azure a través de las imágenes de Oracle DB disponibles en Azure Marketplace. Como alternativa, puede usar la interconexión entre Azure y OCI para implementar Oracle DB en un modelo de PaaS en OCI.

Para Oracle RAC, puede usar OCI en el modelo de PaaS. Se recomienda usar un sistema de RAC de dos nodos. Aunque es posible implementar Oracle RAC en Azure CloudSimple en el modelo IaaS, Oracle no es una configuración admitida. Consulte Programas de Oracle válidos para entornos de nube autorizados.

Por último, en el caso de los sistemas de Exadata, use la interconexión de OCI e implemente el sistema de Exadata en OCI. En el diagrama de arquitectura anterior se muestra un sistema de Exadata implementado en OCI en dos subredes.

En el caso de los escenarios de producción, implemente varias instancias de la base de datos en dos zonas de disponibilidad (si se implementa en Azure) o en dos dominios de disponibilidad (en OCI). Use Oracle Active Data Guard para sincronizar las base de datos principal y la que está en espera.

El nivel de base de datos solo recibe solicitudes del nivel intermedio. Se recomienda configurar un grupo de seguridad de red (lista de seguridad si la base de datos se implementa en OCI) para permitir solo solicitudes en el puerto 1521 del nivel intermedio y en el puerto 22 del servidor bastión por motivos administrativos.

En el caso de las bases de datos implementadas en OCI, se debe configurar una red de nube virtual independiente con una puerta de enlace de enrutamiento dinámico (DRG) que esté conectada al circuito de FastConnect.

Nivel de identidad

La asociación entre Microsoft y Oracle le permite configurar una identidad unificada entre Azure, OCI y la aplicación de Oracle. Para el conjunto de aplicaciones de PeopleSoft o JD Edwards EnterpriseOne, se necesita una instancia del servidor HTTP de Oracle (OHS) para configurar el inicio de sesión único entre Microsoft Entra ID y Oracle IDCS.

OHS actúa como un proxy inverso a la capa de aplicación, lo que significa que todas las solicitudes a las aplicaciones finales pasan por él. Oracle Access Manager WebGate es un complemento del servidor web de OHS que intercepta cada solicitud que va a una aplicación final. Si un recurso al que se está accediendo está protegido (requiere una sesión autenticada), WebGate inicia el flujo de autenticación de OIDC con Identity Cloud Service a través del explorador del usuario. Para más información sobre los flujos compatibles con WebGate de OpenID Connect, consulte la documentación de Oracle Access Manager.

Con esta configuración, un usuario que ya haya iniciado sesión en Microsoft Entra ID puede navegar a la aplicación de PeopleSoft o JD Edwards EnterpriseOne sin tener que volver a iniciar sesión, a través de Oracle Identity Cloud Service. Los clientes que implementen esta solución obtienen las ventajas del inicio de sesión único, incluido un conjunto de credenciales único, una mejor experiencia de inicio de sesión, mayor seguridad y un menor costo del departamento de soporte técnico.

Para más información sobre cómo configurar el inicio de sesión único para JD Edwards EnterpriseOne o PeopleSoft con Microsoft Entra ID, consulte las notas del producto de Oracle asociadas.

Pasos siguientes

Use scripts de Terraform para configurar aplicaciones de Oracle en Azure y establecer una conectividad entre nubes con OCI.

Para más información y las notas del producto acerca de OCI, consulte la documentación de Oracle Cloud.