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

En este artículo se proporciona arquitectura de referencia para implementar la aplicación Oracle en Azure IaaS donde también reside o se coloca la base de datos de Oracle.

Las cargas de trabajo de Oracle incluyen no solo bases de datos de Oracle, sino también de aplicaciones de Oracle propias como Siebel, PeopleSoft, JD Edwards, E-Business Suite o aplicaciones de servidor WebLogic personalizadas. La implementación de aplicaciones de Oracle en Azure laaS (infraestructura como servicio) es un escenario común para las organizaciones que buscan usar la nube para sus cargas de trabajo de Oracle junto con la base de datos de Oracle. Microsoft ofrece arquitecturas de referencia y procedimientos recomendados para facilitar este proceso.

Directrices generales relativas a la migración de aplicaciones

A medida que las aplicaciones de Oracle se mueven en Azure IaaS, hay consideraciones de diseño comunes que deben seguirse independientemente del tipo de aplicaciones. Algunas consideraciones son específicas de las aplicaciones. En esta sección, se enumeran las consideraciones de diseño comunes de todas las aplicaciones y todas las consideraciones específicas de la aplicación se tratan en cada aplicación.

Red y seguridad

La configuración de red proporcionada para aplicaciones de Oracle en Azure abarca varios aspectos relativos a la red y seguridad. A continuación se muestra un desglose de la configuración de red recomendada:

• Inicio de sesión único (SSO) con Microsoft Entra ID y SAML: Use Microsoft Entra ID para el inicio de sesión único (SSO) mediante el protocolo Lenguaje de Marcado para Confirmaciones de Seguridad (SAML). Este inicio de sesión único permite a los usuarios autenticarse una vez y acceder a varios servicios sin problemas.

• El proxy de aplicación de Microsoft Entra: considere el uso del proxy de aplicación de Microsoft Entra, especialmente para los usuarios remotos. Este proxy permite acceder de forma segura a las aplicaciones locales desde fuera de la red.

• Enrutamiento de usuarios internos a través de ExpressRoute: para usuarios internos, enrute el tráfico a través de Azure ExpressRoute para una conexión privada y dedicada a los servicios de Azure, lo que garantiza una baja latencia y una comunicación segura.

• Azure Firewall: si es necesario, puede configurar Azure Firewall delante de la aplicación para mayor seguridad. Azure Firewall ayuda a proteger los recursos frente a amenazas y acceso no autorizado.

• Application Gateway para usuarios externos: cuando los usuarios externos necesiten acceder a la aplicación, considere usar Azure Application Gateway. Proporciona funcionalidades de Web Application Firewall (WAF) para proteger las aplicaciones web y el equilibrio de carga de nivel 7 para distribuir el tráfico.

• Grupos de seguridad de red (NSG): proteja las subredes mediante grupos de seguridad de red (NSG). Los grupos de seguridad de red permiten controlar el tráfico entrante y saliente a interfaces de red, máquinas virtuales y subredes mediante la definición de reglas de seguridad.

• Control de acceso basado en rol (RBAC): para conceder acceso a usuarios o roles específicos, use el control de acceso basado en rol (RBAC) de Azure. RBAC proporciona un control de acceso específico a los recursos de Azure en función de los roles y permisos.

• Host bastión para el acceso SSH: use un host bastión como jumpbox para mejorar la seguridad del acceso SSH. Un host bastión actúa como puerta de enlace segura para que los administradores accedan a las máquinas virtuales de la red virtual. Este host proporciona una capa adicional de seguridad.

• Más consideraciones:

  • Cifrado de datos: asegúrese de que los datos en reposo y en tránsito estén cifrados. Azure proporciona herramientas como Azure Disk Encryption y SSL/TLS para este propósito.
  • Administración de revisiones: actualice y aplique revisiones periódicas al entorno EBS para protegerse frente a las vulnerabilidades conocidas.
  • Supervisión y registro: implemente Azure Monitor y Azure Defender para la seguridad para comprobar continuamente el entorno en busca de amenazas y anomalías de seguridad. Configure el registro para la auditoría y el análisis forense.

• En resumen, esta configuración de red y seguridad tiene como objetivo proporcionar un entorno sólido y seguro para hospedar aplicaciones de Oracle en Azure IaaS. Incorporan procedimientos recomendados para la autenticación, el control de acceso y la seguridad de red, tanto para usuarios internos como externos. También tienen en cuenta la necesidad de acceso SSH a los servidores de aplicaciones. Estas recomendaciones pueden ayudarle a configurar una posición de seguridad madura para la implementación de aplicaciones de Oracle en Azure IaaS.

Nivel web: el nivel web equilibra las solicitudes y las envía en consecuencia al nivel de aplicación, al nivel de base de datos o a la copia de seguridad.

Nivel de aplicación: el nivel de aplicación normalmente implica servidores de aplicaciones y sistemas de archivos compartidos.

Para el escalado automático, Virtual Machine Scale Sets puede ser una opción excelente para escalar horizontalmente varias máquinas virtuales en función de la demanda con reglas de escalado personalizadas para adaptarse a la carga de trabajo.

Colabore con expertos en la materia (SME) de Azure para realizar una evaluación exhaustiva de la arquitectura. Pueden ayudarle a determinar los servicios de Azure más adecuados en función de sus requisitos específicos, incluido el rendimiento, la disponibilidad y la escalabilidad. Recuerde tener en cuenta factores como el coste, la seguridad de los datos, el cumplimiento y la recuperación ante desastres al diseñar la arquitectura.

También es esencial comprobar y optimizar los recursos de Azure continuamente para garantizar la eficiencia y la rentabilidad.

Equilibrio de carga y rendimiento: es importante evaluar las características de carga de trabajo de los servidores de aplicaciones. Algunos servidores controlan más tareas y generar un mayor rendimiento que otros. Esta información es fundamental al diseñar los conjuntos de escalado de máquinas virtuales de Azure y la configuración de equilibrio de carga para asegurarse de que los recursos se asignan de forma eficaz

Nivel de base de datos: se recomiendan arquitecturas de alta disponibilidad con Oracle Data Guard para Oracle en Azure IaaS. Las aplicaciones requieren un tipo específico de configuración de alta disponibilidad y se indican en cada aplicación.

Copia de seguridad: las copias de seguridad se envían desde el nivel de aplicación y el nivel de base de datos. Es solo una de las muchas razones por las que esos dos niveles no se deben separar en dos proveedores diferentes. Las copias de seguridad de la base de datos se realizan mediante la instantánea de volumen de Azure Backup en archivos Premium en la región secundaria.

Recuperación ante desastres: hay diferentes soluciones entre las que puede elegir. Depende mucho de sus requisitos. La arquitectura se ha creado para ser de alta disponibilidad. Para replicar el nivel de aplicación, puede usar Azure Site Recovery. Otra solución que puede elegir es Opciones de redundancia para discos administrados. Ambas soluciones replican los datos. Las opciones de redundancia para discos administrados son una solución que puede simplificar la arquitectura, pero también conlleva algunas limitaciones.

Siebel en Azure

Oracle Siebel CRM sigue siendo una solución CRM de nivel empresarial preferida para muchas empresas. Es una de las aplicaciones más complejas de la cartera de Oracle que ofrece una combinación de características transaccionales, analíticas y de involucración para administrar las operaciones orientadas al cliente.

Esta es la arquitectura recomendada de una implementación de aplicación Siebel en Azure Virtual Machines para Innovation Pack 16 y versiones anteriores:

El diagrama siguiente es la arquitectura de una implementación de aplicación Siebel en Azure Virtual Machines para Innovation Pack 17 y versiones anteriores:

Consideraciones de diseño de Oracle Siebel

• Seguridad y red: la configuración de red de Oracle Siebel en Azure debe seguir las consideraciones generales relativas a las seguridad y a la red.

• La migración debe realizarse mediante la subred de la herramienta Siebel.

Capa de aplicación

• Versión 17 o posterior: se requieren configuraciones de determinados servidores y utilidades en la aplicación y la base de datos.

Nivel de base de datos

• Asegúrese de que las versiones de la base de datos y de Siebel coinciden.
• Base de datos principal y la replicación en una base de datos secundaria mediante la arquitectura de referencia Oracle recomendada basada en Data Guard.

E-Business Suite en Azure

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). Como EBS es un sistema SCM y CRM, normalmente tiene muchas interfaces para sistemas de terceros. La arquitectura que se muestra a continuación está diseñada para ofrecer una alta disponibilidad dentro de una misma región.

Se supone que los usuarios externos no cruzan la red corporativa en el diagrama siguiente.

Consideraciones de diseño de Oracle EBS

Nivel de base de datos: las bases de datos primaria y secundaria deben estar dentro de un centro de datos; se debe usar la configuración sincrónica. Si instala la aplicación en centros de datos, debe configurar Data Guard en modo asincrónico.

JD Edwards en Azure

JD Edwards de Oracle es un conjunto integrado de aplicaciones de software de planeamiento de recursos empresariales integral. Hemos visto que JDE se usa en la cadena de suministro, administración de almacenes, logística, planificación de recursos de fabricación y mucho más. Debido al uso de la aplicación, vemos que las interfaces con otros sistemas también son importantes.

La arquitectura siguiente se ha creado para ser de alta disponibilidad. Se supone que los usuarios externos no tienen acceso a través de la red corporativa. Si un usuario externo accede a la aplicación mediante la red corporativa, la arquitectura se puede simplificar en las redes de la siguiente manera.

Consideraciones de diseño de JD Edwards

Nivel web: el nivel web de aplicación normalmente consta de varios servidores de aplicaciones. En JD Edwards, las reglas a menudo se guardan en estos servidores web de aplicaciones.

• Nivel de presentación: cada instancia del nivel de presentación está asociada al almacenamiento. El corte de dependencias entre instancias puede provocar latencias elevadas, por lo que es fundamental evaluarlas cuidadosamente.

• Variación de rendimiento del servidor: algunos servidores pueden controlar más tareas y generar un mayor rendimiento que otros. Durante la fase de diseño, es esencial evaluar esta variación de rendimiento para asegurarse de que la infraestructura pueda controlar las cargas de trabajo máximas de forma eficaz.

• Rediseño: el uso de conjuntos de escalado de máquinas virtuales de Azure para el escalado automático no requiere una rediseño de la configuración de JD Edwards. Es una solución escalable que se puede implementar sin cambios significativos en la arquitectura de la aplicación.

Nivel de base de datos: la base de datos principal y la secundaria se encuentran dentro de un centro de datos; se debe usar la configuración sincrónica. Si instala la aplicación en centros de datos, debe configurar Data Guard en modo asincrónico. Los datos del nivel de base de datos se envían directamente a Azure Storage. El almacenamiento depende de la configuración actual de la arquitectura.

PeopleSoft en Azure

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

Consideraciones de diseño de PeopleSoft

Nivel de aplicación: el nivel de aplicación contiene varias tareas y servidores. Ejecuta la lógica de negocios y los procesos, pero también mantiene la conexión a la base de datos. En cuanto se corta esta dependencia, provoca latencias.

• Dependencia entre los niveles de aplicación y base de datos: es importante minimizar la latencia entre los niveles de aplicación y base de datos. Al colocar la aplicación y el nivel de base de datos en el mismo proveedor de nube (Azure, en este caso), se reduce la latencia de red. Azure proporciona varias opciones de red y servicios como el emparejamiento de red virtual (VNet) o ExpressRoute para garantizar conexiones de baja latencia entre niveles.

• Consideraciones sobre el sistema operativo: si el programador de procesos requiere específicamente sistemas operativos Windows, puede seguir ejecutándolo en Azure Virtual Machines. Azure admite varias versiones de Windows Server, lo que le permite elegir la que cumple los requisitos de la aplicación.

• Evaluación de la arquitectura: evalúe cuidadosamente los requisitos de arquitectura, incluida la escalabilidad, la disponibilidad y el rendimiento. Considere la posibilidad de configurar varias instancias de servidor de aplicaciones en una configuración de carga equilibrada para garantizar una alta disponibilidad y escalabilidad.

Nivel de base de datos: la base de datos principal y la replicación en una base de datos secundaria deben permanecer dentro de un centro de datos; se debe usar la configuración sincrónica. Si instala la aplicación en centros de datos, debe configurar Data Guard en modo asincrónico.

Pasos siguientes

Arquitecturas de referencia para Oracle Database

Migrar la carga de trabajo de Oracle a Azure Virtual Machines