Compartir a través de

Diseño de aplicaciones de Oracle

  • Artículo

La migración de aplicaciones de Oracle a la nube es un proceso complejo. Debe comprender qué funcionalidades admite cada versión de una aplicación para que pueda evitar problemas durante la migración o incluso evitar una migración con errores. Las organizaciones no quieren simplemente migrar mediante lift-and-shift aplicaciones. También quieren modernizar la arquitectura y alinearse con los requisitos funcionales y no funcionales. Debe examinar estos requisitos junto con los patrones clave de diseño de aplicaciones en la nube para asegurarse de lograr los objetivos de migración.

Algunos ejemplos de aplicaciones de Oracle populares son Siebel, E-Business Suite, JD Edwards y PeopleSoft. Estas aplicaciones tienen dependencias sólidas entre el nivel de aplicación y el nivel de base de datos. La separación de los dos niveles entre distintos proveedores de nube presenta latencias que pueden dar lugar a una mala experiencia para los clientes. Siempre debe realizar una evaluación técnica adecuada antes de decidir cómo hospedar los dos niveles.

Para cada aplicación, debe tener en cuenta las consideraciones de diseño que proporciona el proveedor de la aplicación y tener en cuenta las características de los servicios de Azure que se usan para cada diseño. La nube de Azure ofrece muchas características y funcionalidades que pueden dar lugar a una solución eficaz, confiable, segura y de alta disponibilidad.

Para obtener instrucciones de arquitectura más específicas, consulte Arquitecturas para aplicaciones de Oracle con una base de datos en Azure Virtual Machines.

Recomendaciones

Use las siguientes recomendaciones para planear la migración de las aplicaciones de Oracle a la nube.

Red y seguridad

  • Considere la posibilidad de configurar el inicio de sesión único (SSO) mediante Microsoft Entra ID. Los clientes pueden usar el inicio de sesión único para conectarse a las aplicaciones de Oracle a través de su explorador de Internet. Para más información, consulte Habilitación del inicio de sesión único para una aplicación empresarial.
  • Considere la posibilidad de usar una conexión privada a la instalación en la nube. Azure proporciona funcionalidades de conectividad privada, como conexiones de Azure ExpressRoute y conexiones VPN de sitio a sitio.
  • Si un cliente accede a la aplicación desde Internet, considere una puerta de enlace de aplicaciones. Azure Application Gateway proporciona dos funcionalidades integradas. Funciona como un firewall de aplicaciones web y tiene un equilibrador de carga de nivel 7 integrado. Application Gateway solo admite el acceso en el puerto 443 (HTTPS).
  • Otra opción para proteger la red es Azure Firewall. Este componente protege los servicios web frente a vulnerabilidades y vulnerabilidades comunes. Mantiene las aplicaciones de Oracle de alta disponibilidad y le ayuda a cumplir los requisitos de cumplimiento.
  • Considere la posibilidad de configurar grupos de seguridad de red en un nivel de subred para asegurarse de que la red permite el tráfico solo en puertos y direcciones IP específicos.
  • Si la aplicación requiere acceso al protocolo Secure Shell (SSH) o al Protocolo de escritorio remoto (RDP), implemente un host de Azure Bastion como servidor de salto para proporcionar seguridad adicional para una posición de seguridad madura y detallada.

Niveles web y de aplicación

  • Implemente la aplicación en máquinas virtuales (VM). Agrupe esas máquinas virtuales en conjuntos de disponibilidad para mejorar la disponibilidad general.
  • Si necesita que la aplicación se escale automáticamente, considere la posibilidad de usar Azure Virtual Machine Scale Sets.
  • Coloque las máquinas virtuales en una sola zona de disponibilidad para acercarlas físicamente. Sin embargo, tenga en cuenta que a medida que crece la superficie de Azure, una sola zona de disponibilidad puede abarcar varios centros de datos físicos. La distancia entre los centros de datos físicos puede provocar una latencia de red que afecte a la aplicación. Para obtener las máquinas virtuales lo más cerca posible y lograr la menor latencia posible, impleméntelas dentro de un grupo con ubicación por proximidad.

Nivel de base de datos

  • Considere la posibilidad de implementar el nivel de base de datos como un servidor principal que se replica en un servidor secundario mediante Oracle Data Guard.
  • Si usa dos zonas para implementar los servidores primarios y secundarios en una región, considere la posibilidad de usar la configuración de replicación sincrónica de Data Guard después de comprobar la latencia de red entre las zonas de la región.
  • Si implementa los servidores principales y secundarios en dos regiones, considere la posibilidad de usar la configuración de replicación asincrónica de Data Guard.
  • Si necesita una estrategia de replicación de pérdida de datos cero, considere la posibilidad de usar la configuración de replicación asincrónica.
  • Además de Data Guard, otras opciones de integración incluyen Striim, Qlik, GoldenGate o Active Data Guard.

Copia de seguridad y protección de datos

  • Considere la posibilidad de usar Azure Backup para realizar copias de seguridad de las máquinas virtuales de la aplicación y de la base de datos.
  • Considere la posibilidad de colocar las copias de seguridad en una región diferente de la región primaria para proporcionar protección adicional frente a errores regionales.
  • Considere la posibilidad de realizar una copia de seguridad de la base de datos mediante componentes de almacenamiento que tienen funcionalidades de replicación integradas.

Recuperación ante desastres

Paso siguiente

Principios de diseño para una carga de trabajo de Oracle en Azure