1. Obtenga más información sobre el despliegue de JD Edwards EnterpriseOne en Oracle Cloud Infrastructure
  2. Obtener más información sobre el despliegue de JD Edwards EnterpriseOne en Oracle Cloud Infrastructure

Obtener más información sobre el despliegue de JD Edwards EnterpriseOne en Oracle Cloud Infrastructure

Si desea aprovisionar JD Edwards EnterpriseOne en Oracle Cloud Infrastructure o migrar entornos JD Edwards EnterpriseOne desde el centro de datos a Oracle Cloud Infrastructure, puede planificar una topología multihost, segura y de alta disponibilidad.

Antes de empezar

Oracle Cloud Infrastructure admite la versión 9.0, 9.1 y 9.2 de la aplicación JD Edwards EnterpriseOne. Antes de empezar a planificar el despliegue o la migración de la aplicación JD Edwards EnterpriseOne, identifique si Oracle Cloud Infrastructure admite la combinación de la versión de la aplicación JD Edwards EnterpriseOne, la versión de herramientas JD Edwards EnterpriseOne y el sistema operativo en el que desea ejecutar las aplicaciones.

  • Aplicación JD Edwards EnterpriseOne versión 9.2 con JD Edwards EnterpriseOne Tools versión 9.2. x. Admite la instalación manual y automatizada de componentes de JD Edwards EnterpriseOne en sistemas operativos Oracle Linux y Windows.

  • Aplicación JD Edwards EnterpriseOne versión 9.1 con JD Edwards EnterpriseOne Tools versión 9.1. x o 9.2. x. Solo admite la instalación manual de componentes de JD Edwards EnterpriseOne en los sistemas operativos Oracle Linux y Windows.

Para obtener información sobre versiones anteriores de la aplicación JD Edwards EnterpriseOne, póngase en contacto con Oracle Advanced Consulting Services.

Consulte My Oracle Support para obtener información sobre certificaciones definitivas.

Consideraciones para el despliegue en Oracle Cloud Infrastructure

Oracle recomienda crear subredes separadas para las instancias, como el host bastion, la base de datos, la aplicación y las instancias del equilibrador de carga, para garantizar que se puedan implantar los requisitos de seguridad adecuados en las distintas subredes.

Subredes privadas o públicas

Puede crear instancias en una subred privada o pública en función de si desea permitir el acceso a las instancias desde Internet. A las instancias que cree en una subred pública se les asigna una dirección IP pública y puede acceder a estas instancias desde Internet. No puede asignar una dirección IP pública a instancias creadas en una subred privada. Por lo tanto, no puede acceder a estas instancias a través de Internet.

En la siguiente imagen se muestra una red virtual en la nube (VCN) con subredes públicas y privadas. VCN contiene dos dominios de disponibilidad y cada dominio de disponibilidad contiene una subred pública y privada. Los servidores web se colocan en la subred pública de esta imagen, por lo que las instancias del servidor web tienen una dirección IP pública conectada a ella. Puede acceder a estas instancias de Oracle Cloud en la subred pública desde Internet activando la comunicación a través del gateway de Internet (IGW). Tendrá que actualizar la tabla de rutas para activar el tráfico desde y hacia IGW. Para permitir el tráfico a los servidores web desde Internet, debe crear equilibradores de carga en la subred pública. Para acceder a sus instancias desde Internet, también debe crear el host bastion en subred pública y acceder al host bastion desde IGW.

Los servidores de base de datos se colocan en la subred privada de esta imagen. Puede acceder a instancias de Oracle Cloud en la subred privada desde los centros de datos conectándose a través del gateway de enrutamiento dinámico (DRG). DRG conecta sus redes locales a su red en la nube. Para activar la comunicación entre DRG y el equipo local del cliente, utilice IPSec VPN o Oracle Cloud Infrastructure FastConnect. También tendrá que actualizar la tabla de rutas para activar el tráfico desde y hacia DRG.


Descripción de public_private_subnets_jde.png a continuación
Descripción de la ilustración public_private_subnets_jde.png
Escenario 1: Desplegar Todas las Instancias en Subredes Privadas

Oracle recomienda desplegar todas las instancias en subredes privadas para entornos de producción en los que no haya puntos finales orientados a Internet. Este tipo de despliegue es útil cuando desea tener un despliegue híbrido con la nube como extensión a los centros de datos existentes.

En este despliegue, todas las instancias, incluidos los servidores de aplicaciones y bases de datos, se despliegan en una subred privada. No se puede asignar una dirección IP pública a instancias creadas en una subred privada, por lo que no puede acceder a estas instancias a través de Internet. Para acceder a los servidores de aplicaciones desde el entorno local en esta configuración, puede:

  • Configure un túnel VPN de IPSec entre el centro de datos y Oracle Cloud Infrastructure DRG antes de aprovisionar los servidores de aplicaciones.

  • Cree un host bastion en esta configuración y, a continuación, acceda a todos los servidores de subred privada desde el host bastion.

Escenario 2: Desplegar Instancias en Subredes Públicas y Privadas

Puede desplegar algunas instancias en una subred pública y algunas instancias en una subred privada. Este tipo de despliegue es útil cuando el despliegue incluye puntos finales orientados a Internet y no orientados a Internet.

En esta configuración, algunas instancias de aplicación se colocan en una subred pública y otras se colocan en una subred privada. Por ejemplo, puede tener instancias de aplicación que sirvan a usuarios internos y otro juego de instancias de aplicación que sirvan a usuarios externos. En este escenario, coloque las instancias de aplicación que sirven tráfico interno en una subred privada y coloque los servidores de aplicaciones que sirven tráfico externo en una subred pública. También puede configurar un equilibrador de carga público en las instancias de aplicación orientadas a Internet, en lugar de colocar los servidores de aplicaciones que sirven tráfico externo en una subred pública. Si coloca el host bastion en una subred pública, se asigna al host bastion una dirección IP pública y puede acceder a él a través de Internet. Puede acceder a las instancias de la subred privada a través del servidor bastion.

Escenario 3: Despliegue de Todas las Instancias en Subredes Públicas

Oracle recomienda este despliegue para demostraciones rápidas o para despliegues de nivel de producción sin puntos finales internos. Este despliegue es adecuado solo si no tiene su propio centro de datos o no puede acceder a instancias a través de VPN y desea acceder a la infraestructura a través de Internet.

En este despliegue, todas las instancias, incluidas las instancias de la aplicación y la base de datos, se despliegan en subredes públicas.

Cada instancia de la subred pública tiene una dirección IP pública asociada a ella. Aunque se puede acceder a instancias con direcciones IP públicas a través de Internet, puede restringir el acceso mediante listas de seguridad y reglas de seguridad. Para realizar tareas de administración, Oracle recomienda colocar un host de bastión en esta configuración. En este escenario, no abriría puertos de administración a Internet público, sino que abriría los puertos de administración sólo al host de bastión y configuraría las listas de seguridad y las reglas de seguridad para asegurarse de que la instancia sólo se puede acceder desde el host de bastión.

Antiafinidad

Al crear varias instancias para una alta disponibilidad en un dominio de disponibilidad de Oracle Cloud Infrastructure, la anti-afinidad para instancias se puede lograr mediante dominios de fallos.

Un dominio de fallo es una agrupación de hardware e infraestructura dentro de un dominio de disponibilidad. Cada dominio de disponibilidad contiene tres dominios de errores. Los dominios de errores le permiten distribuir sus instancias de forma que no se encuentren en el mismo hardware físico dentro de un solo dominio de disponibilidad. Por lo tanto, un fallo de hardware o un mantenimiento de hardware de Oracle Compute que afecta a un dominio de fallos no afecta a instancias de otros dominios de fallos. Mediante el uso de dominios de fallos, puede proteger sus instancias contra fallos inesperados de hardware y interrupciones planificadas.

Para una alta disponibilidad de bases de datos, puede crear sistemas de base de datos Oracle Real Application Clusters (Oracle RAC) de 2 nodos. Los dos nodos de Oracle RAC se crean siempre en dominios de fallos separados por defecto. Por lo tanto, los nodos de la base de datos no están en el mismo host físico ni en el mismo rack físico. Esto protege las instancias de la base de datos del host físico subyacente y de la parte superior de los fallos del conmutador de rack.

Arquitectura para Despliegue de JD Edwards EnterpriseOne en una sola Región

Puede desplegar JD Edwards EnterpriseOne en un único dominio de disponibilidad al tiempo que garantiza una alta disponibilidad.

Puede lograr una alta disponibilidad colocando las instancias de aplicación dentro de varios dominios de fallos. Utilice esta arquitectura cuando desee asegurarse de que la aplicación esté disponible incluso cuando una instancia de aplicación se reduzca en un dominio de fallos. Las otras instancias de aplicación disponibles dentro del otro dominio de fallos continúan procesando las solicitudes. Puede desplegar JD Edwards EnterpriseOne manualmente o mediante las herramientas de automatización de JD Edwards EnterpriseOne en Oracle Cloud Infrastructure.

Esta arquitectura muestra que las instancias redundantes se despliegan en la capa de presentación y la capa media en un dominio de disponibilidad para garantizar una alta disponibilidad dentro del dominio de disponibilidad. Todas las instancias del dominio de disponibilidad están activas. Esta alta disponibilidad de una aplicación dentro de un dominio de disponibilidad se puede lograr colocando instancias de aplicación en dominios de fallos independientes. Los dominios de errores le permiten distribuir sus instancias de forma que no se encuentren en el mismo hardware físico dentro de un solo dominio de disponibilidad. Un fallo de hardware o un mantenimiento de hardware de Oracle Cloud Infrastructure Compute que afecta a un dominio de fallos no afecta a instancias en otros dominios de fallos. Si falla una instancia, el tráfico se desvia a otras instancias del dominio de disponibilidad que continúan procesando las solicitudes. Sin embargo, si falla la conexión al dominio de disponibilidad o si todo el dominio de disponibilidad se cae, las instancias no están disponibles para procesar las solicitudes.

Las instancias de la subred privada requieren conexión saliente a Internet para descargar parches, así como para aplicar actualizaciones del sistema operativo y de la aplicación. Para ello, utilice un gateway de traducción de direcciones de red (NAT) en VCN. Con un gateway NAT, los hosts de la subred privada pueden iniciar conexiones a Internet y recibir respuestas, pero no recibirán conexiones entrantes iniciadas desde Internet.

Oracle recomienda que la base de datos y las aplicaciones desplegadas en Oracle Cloud Infrastructure tengan una sólida estrategia de copia de seguridad de recuperación. Se recomienda almacenar copia de seguridad de bases de datos e instancias de aplicación en Oracle Cloud Infrastructure Object Storage. Las bases de datos y las instancias de aplicación de subredes privadas se pueden realizar copias de seguridad en Oracle Cloud Infrastructure Object Storage mediante un gateway de servicio. Un gateway de servicio proporciona acceso a Oracle Cloud Infrastructure Object Storage sin atravesar Internet.

Las copias de seguridad automáticas y bajo demanda de la base de datos en Oracle Cloud Infrastructure Object Storage se pueden configurar mediante la consola Oracle Cloud Infrastructure. Esto requiere conectividad a Oracle Cloud Infrastructure Object Storage mediante un punto final Swift. Todas las copias de seguridad de la base de datos en Oracle Cloud Infrastructure Object Storage se cifran con la misma clave maestra utilizada para el cifrado de cartera de cifrado de datos transparente (TDE). El servicio de copia de seguridad automática de la base de datos utiliza una estrategia de copia de seguridad incremental semanal para realizar copias de seguridad de bases de datos con una política de retención de 30 días. También es posible realizar una copia de seguridad completa a petición de bases de datos para requisitos ad hoc.

La copia de seguridad de la aplicación se puede configurar mediante la función de copia de seguridad basada en políticas de Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes proporciona la capacidad de realizar copias de seguridad de volumen automáticamente en función de un programa y retenerlas en función de la política de copia de seguridad seleccionada. Esto le permite cumplir con sus requisitos normativos y de cumplimiento de datos. Hay tres políticas de copia de seguridad predefinidas: bronce, plata y oro. Cada política de copia de seguridad tiene una frecuencia de copia de seguridad predefinida y un período de retención.

La arquitectura consta de una red virtual en la nube (VCN) con el host bastion, la capa de equilibrador de carga, la capa de presentación, la capa media, la capa de administración y la capa de base de datos. Las capas se colocan en una sola subred de VCN en un único dominio de disponibilidad.

En el siguiente diagrama de arquitectura, el host bastion se despliega en una subred pública y todas las demás instancias se colocan en subredes privadas. En función de los requisitos de negocio, puede colocar instancias en subredes públicas o privadas. Puede acceder a las instancias que están en subredes privadas sobre el puerto 22 mediante el host bastion o el gateway de enrutamiento dinámico (DRG). Para activar la comunicación entre DRG y el equipo local del cliente, utilice IPSec VPN o Oracle Cloud Infrastructure FastConnect.

El gestor de servidores de la capa de administración se comunica con la capa de presentación, la capa media y la capa de base de datos para proporcionar despliegue de código, gestión de configuración, acceso a métricas de tiempo de ejecución y acceso al log. El servidor de despliegue de la capa de administración se comunica con la capa media y la capa de base de datos para crear y desplegar código. El cliente de desarrollo se comunica con la capa media y la capa de base de datos. El marco de desarrollo de aplicaciones (ADF) y Oracle Business Intelligence Publisher se comunican con el servidor HTML de la capa Presentación.


Descripción de single_availability_domain_jd_edwards_deployment.png a continuación
Descripción de la ilustración single_availability_domain_jd_edwards_deployment.png
Esta arquitectura se divide en estos niveles:

  • Host Bastion: El host bastion es un componente opcional que se puede utilizar como servidor de salto para acceder a instancias de la subred privada. Un host bastion es una instancia de Oracle Cloud Infrastructure Compute que utiliza Linux como sistema operativo. Coloque el host bastion en una subred pública y asígnele una dirección IP pública para acceder a él desde Internet.

    Para proporcionar un nivel adicional de seguridad, puede configurar listas de seguridad para acceder al host bastion solo desde la dirección IP pública de su red local. Puede acceder a instancias de Oracle Cloud Infrastructure en la subred privada mediante el host bastion. Para ello, active el reenvío ssh-agent, que permite conectarse al host bastion y, a continuación, acceder al siguiente servidor reenviando las credenciales desde el equipo. También puede acceder a las instancias de la subred privada mediante túneles SSH dinámicos. El túnel SSH es una forma de acceder a una aplicación web u otro servicio de escucha. El túnel dinámico proporciona un proxy SOCKS en el puerto local, pero las conexiones se originan desde el host remoto.

  • Nivel Equilibrador de Carga: la capa de equilibrador de carga contiene las instancias de Oracle Cloud Infrastructure Load Balancing que equilibran el tráfico con todas las instancias de la capa de presentación. El equilibrador de carga recibe solicitudes de los usuarios y, a continuación, las dirige a instancias de la capa de presentación.

    Utilice Oracle Cloud Infrastructure Load Balancing para distribuir tráfico a las instancias de la aplicación dentro de VCN. Este servicio proporciona una instancia primaria y en espera del equilibrador de carga para asegurarse de que si el equilibrador de carga principal no está disponible, el equilibrador de carga en espera reenvía las solicitudes. El equilibrador de carga garantiza que las solicitudes se dirijan a las instancias de aplicación sanas. Si se produce un problema en una instancia de aplicación, el equilibrador de carga direccionará las solicitudes a las restantes instancias de aplicación sanas.

    En función de sus necesidades, puede colocar equilibradores de carga en una subred pública o privada.

    • Para los puntos finales internos, a los que no se puede acceder desde Internet, utilice un equilibrador de carga privado. Un equilibrador de carga privado tiene una dirección IP privada y no es accesible desde Internet. Tanto las instancias primarias como las en espera de un equilibrador de carga residen en la misma subred privada. Puede acceder a equilibradores de carga privados en VCN o en el centro de datos a través de IPSec VPN a través de DRG. El equilibrador de carga privado acepta el tráfico desde el centro de datos y distribuye el tráfico a instancias de aplicación subyacentes.

    • Para los puntos finales orientados a Internet, utilice un equilibrador de carga público. Un equilibrador de carga público tiene una dirección IP pública y es accesible desde Internet. Puede acceder a los equilibradores de carga públicos desde Internet a través del gateway de Internet.

    • Para acceder a los puntos finales internos y a los puntos finales orientados a Internet, configure equilibradores de carga privados y equilibradores de carga públicos. Configure equilibradores de carga privados para servir al tráfico interno y configure equilibradores de carga públicos para servir al tráfico desde Internet.

    Registre la dirección IP pública o privada de las instancias de Oracle Cloud Infrastructure Load Balancing en el servidor de nombres de dominio público (DNS) o local para la resolución de dominio del punto final de la aplicación.

    Los puertos proporcionados en el diagrama de arquitectura son solo un ejemplo. Puede utilizar cualquier puerto que esté disponible.

  • Nivel de administración: el nivel de administración contiene una única instancia de los siguientes servidores. No necesita una instancia redundante de estos servidores para garantizar una alta disponibilidad.

    • Servidor de aprovisionamiento: utilice este servidor para automatizar el despliegue total de componentes de JD Edwards EnterpriseOne en Oracle Cloud Infrastructure. Se comunica con todas las instancias de los demás niveles, incluidas las instancias del nivel de base de datos, sobre el puerto 22. Alberga la consola de aprovisionamiento de un clic de JD Edwards EnterpriseOne y la consola de JD Edwards EnterpriseOne Server Manager.

    • Servidor de Despliegue: durante el proceso de instalación, este servidor actúa como repositorio central de todos los archivos y paquetes de instalación necesarios. El software se distribuye o se despliega en todos los demás servidores y clientes de este servidor.

    • Cliente de desarrollo: el cliente de desarrollo de JD Edwards EnterpriseOne contiene componentes que se ejecutan como aplicaciones Microsoft Windows estándar (por ejemplo, Active Console, Forms Design Aid (FDA) y Report Design Aid (RDA)) y componentes que se ejecutan en un explorador web.

    • Servidor de Application Development Framework (ADF): JD Edwards EnterpriseOne ADF Server es una aplicación web desplegada en un servidor Oracle WebLogic con tiempo de ejecución de ADF. Se utiliza para ejecutar aplicaciones de JD Edwards EnterpriseOne desarrolladas con Oracle ADF.

    • Oracle Business Intelligence Publisher: Oracle Business Intelligence Publisher presenta los datos recopilados por JD Edwards EnterpriseOne en forma de informes. Utilice Oracle Business Intelligence Publisher para presentar informes utilizando diferentes plantillas en función de los requisitos de negocio. Puede diseñar y controlar cómo se presentan las salidas del informe mediante archivos de plantilla.

  • Nivel de presentación: el nivel de presentación contiene instancias redundantes de Application Interface Services y Java Application Servers para proporcionar alta disponibilidad. Estos servidores se comunican con servidores de la capa media. Todas las instancias están activas y reciben tráfico del equilibrador de carga. Cada instancia está asociada a un volumen de almacenamiento en bloque. Esta capa también contiene componentes que puede utilizar para crear integración entre JD Edwards EnterpriseOne y un sistema externo. Su implementación puede incluir uno o más de estos componentes.

    Esta capa contiene los siguientes servidores:

    • Servidor de Application Interface Services (AIS): el servidor de Application Interface Service proporciona la interfaz de comunicación entre las aplicaciones empresariales móviles de JD Edwards EnterpriseOne y JD Edwards EnterpriseOne.

    • Servidores de aplicaciones Java estándar (JAS estándar): recibe solicitudes del equilibrador de carga y ejecuta lógica de negocio simple. Para tareas que requieren lógica de negocio complicada, JAS estándar transfiere las solicitudes al servidor lógico. También transfiere solicitudes al servidor AIS en algunos casos. Sin embargo, no está configurado con el servidor AIS para el tiempo de ejecución AIS.

    • Servidores de aplicaciones Java dedicados (JAS dedicados): recibe solicitudes del servidor AIS. Transfiere solicitudes al servidor lógico para ejecutar tareas que requieren lógica de negocio complicada. Está configurado con el servidor AIS para el tiempo de ejecución AIS.

    Para garantizar una alta disponibilidad en un dominio de disponibilidad, despliegue instancias redundantes de cada componente. Todas las instancias están activas y reciben tráfico del equilibrador de carga y la capa media.

  • Nivel Medio: La capa media contiene servidores lógicos y servidores por lotes. No se equilibran directamente con la carga, pero tienen una asignación de uno a uno con servidores en la capa de presentación. Puede alojar el servidor lógico y el servidor por lotes en la misma instancia de servidor de empresa. Sin embargo, se recomienda configurar el servidor lógico y el servidor por lotes en instancias de servidor empresarial independientes.

    La capa media recibe solicitudes de la capa de presentación. Después de procesar las solicitudes, reenvía las solicitudes a los servidores de base de datos. Todas las instancias de los servidores están activas y procesan solicitudes.

    Esta capa contiene los siguientes servidores:

    • Servidores lógicos o servidores empresariales: Estos servidores contienen la lógica de negocio o las funciones de negocio.

    • Servidores por lotes: estos servidores se utilizan para el procesamiento por lotes.

  • Nivel de base de datos: el nivel de base de datos contiene instancias del servidor de base de datos JD Edwards EnterpriseOne. Para requisitos de alta disponibilidad, Oracle recomienda utilizar sistemas de base de datos de Oracle Real Application Clusters (Oracle RAC) de dos nodos o un sistema de Oracle Database Exadata Cloud Service en Oracle Cloud Infrastructure para configurar instancias de servidor de base de datos JD Edwards EnterpriseOne.

    Puede configurar instancias de base de datos redundantes para proporcionar alta disponibilidad. Para los sistemas de base de datos Oracle RAC y Oracle Database Exadata Cloud Service, las solicitudes que se reciben de la subred de aplicaciones se equilibran con la carga en los servidores de base de datos. Si una instancia de base de datos no está disponible, la otra instancia de base de datos procesa las solicitudes. Puede utilizar Oracle Cloud Infrastructure Object Storage para realizar una copia de seguridad de la base de datos JD Edwards EnterpriseOne mediante Oracle Recovery Manager (RMAN). Para realizar una copia de seguridad o aplicar parches a la base de datos JD Edwards EnterpriseOne en Oracle Cloud Infrastructure Object Storage, VCN del sistema de base de datos se debe configurar con un gateway de servicio o un gateway de Internet. Se recomienda utilizar un gateway de servicio en lugar de un gateway de Internet para realizar copias de seguridad y parches.

    Utilice listas de seguridad para restringir el acceso a los servidores de base de datos sólo desde el host de bastión, el nivel de aplicación y los servidores locales. Puede configurar listas de seguridad para asegurarse de que la comunicación sólo se produzca en el puerto 22, a través del host bastion y en el puerto 1521. Asegúrese también de que no se pueda acceder a los sistemas de base de datos a través de Internet.

Puede utilizar Oracle Cloud Infrastructure Object Storage para realizar una copia de seguridad de las instancias de la capa de presentación y la capa media.

Arquitectura para Desplegar JD Edwards EnterpriseOne con Recuperación de Desastres

Esta arquitectura muestra el despliegue de servidores de aplicaciones JD Edwards EnterpriseOne con recuperación ante desastres. Muestra un VCN con el bastión en una subred pública y todos los demás servidores en una subred privada.

Los servidores de producción se colocan en dos regiones diferentes. Los servidores de una región están en modo activo y los servidores de la segunda región (región de recuperación ante desastres) están en modo en espera.

En el diagrama de arquitectura, el host bastion se despliega en una subred pública y todas las demás instancias se despliegan en subredes privadas. Puede colocar las instancias en subredes públicas o privadas en función de los requisitos de su negocio. Puede acceder a las instancias de subredes privadas en el puerto 22 mediante el host bastion o DRG. Para permitir la comunicación entre DRG y el equipo local del cliente, utilice IPSec VPN o Oracle Cloud Infrastructure FastConnect.

En esta arquitectura, se despliegan varias instancias de aplicación en varios dominios de fallos para garantizar una alta disponibilidad. Esto garantiza que su aplicación esté disponible incluso cuando uno de los dominios de disponibilidad no esté disponible. Las instancias de aplicación disponibles en otro dominio de disponibilidad continúan procesando las solicitudes.

Los bastiones alojados en ambas regiones están activos y pueden servir solicitudes SSH a ambas regiones en todo momento. El servicio DNS local o externo de DNS recibe una solicitud para la aplicación JD Edwards EnterpriseOne. Estas solicitudes están equilibradas con la carga de carga en redondo en el equilibrador de carga de la región activa. A continuación, el equilibrador de carga direcciona la solicitud a instancias de la capa de presentación y de la capa media. Las instancias de la capa media direccionan la solicitud a instancias de base de datos activas para su procesamiento. El cliente de desarrollo de la capa de administración también se comunica con la base de datos. El servidor de aprovisionamiento en el nivel de administración se comunica con instancias en todos los niveles.

Si la región primaria no está disponible, debe cambiar manualmente al servidor de base de datos que se ejecuta en la región Recuperación de Desastres y empezar a utilizar el host bastion o el equilibrador de carga que se ejecuta en la región Recuperación de Desastres.

Las bases de datos y las instancias de aplicación de subredes privadas se pueden realizar una copia de seguridad en el almacenamiento de objetos Oracle Cloud Infrastructure mediante un gateway de servicio. Un gateway de servicio proporciona acceso al almacenamiento de objetos sin atravesar Internet.


Descripción de jde2.png a continuación
Descripción de la ilustración jde2.png

  • Host de Bastión: un host de bastión es un componente opcional que se puede aprovisionar en cada región para actuar como host de salto para acceder a instancias de aplicación y base de datos. Los hosts de base en ambas regiones están en estado activo.

  • Instancia de equilibrador de carga: las instancias de Oracle Cloud Infrastructure Load Balancing distribuyen tráfico entre los servidores de aplicaciones. La instancia del equilibrador de carga en la región activa/primaria está activa. Las solicitudes recibidas en la URL de JD Edwards EnterpriseOne se envían al equilibrador de carga en la región activa por un servicio DNS local o externo.

  • Nivel de presentación: la capa de presentación contiene instancias redundantes de Application Interface Services (AIS) y Java Application Servers (JAS) para proporcionar alta disponibilidad. Estos servidores se comunican con servidores de la capa media. Todas las instancias están activas y reciben tráfico del equilibrador de carga. Cada instancia está asociada a un volumen de almacenamiento en bloque. Esta capa también contiene componentes que puede utilizar para crear integración entre JD Edwards EnterpriseOne y un sistema externo. Su implementación puede incluir uno o más de estos componentes.

  • Nivel Medio: La capa media contiene servidores lógicos y servidores por lotes. No están equilibrados de carga directamente, pero tienen una asignación de uno a uno con servidores en el nivel de presentación.

  • Nivel de base de datos: configure instancias de base de datos de alta disponibilidad en ambas regiones. El servidor de base de datos que se ejecuta en la región activa/primaria está en estado activo. En cada región, se configuran al menos dos instancias de base de datos para garantizar una alta disponibilidad dentro de una región. Si una instancia de base de datos no está disponible en la región activa/primaria, cambie a la instancia de base de datos en la región Recuperación en Casos de Desastre y comience a utilizar el equilibrador de carga en la región Recuperación en Casos de Desastre para acceder al entorno.

    Utilice Oracle Active Data Guard en modo síncrono para replicar la base de datos en todas las regiones.

Acerca de los Grupos de Seguridad de Red

En Oracle Cloud Infrastructure, las reglas de firewall se configuran mediante grupos de seguridad de red. Se crea un grupo de seguridad de red independiente para cada nivel.

Utilice listas de seguridad para permitir el tráfico entre diferentes niveles y entre el host bastion y los hosts externos. Las reglas de seguridad contienen reglas de entrada y salida para filtrar el tráfico en el nivel de nivel. También contienen información sobre los puertos de comunicación a través de los cuales se permite la transferencia de datos. Esos puertos (o en algunos casos, los protocolos que necesitarán puertos abiertos en las reglas de seguridad) se muestran en cada línea de grupo de seguridad de red en los diagramas de arquitectura.

Cada grupo de seguridad de red se aplica en el nivel de VNIC. Se permite la transferencia de un paquete de datos si una regla de cualquiera de las listas permite el tráfico (o si el tráfico forma parte de una conexión existente que se está rastreando). Además del grupo de seguridad de red, utilice iptables para implantar otra capa de seguridad en el nivel de instancia.

Para despliegues en una subred pública, puede proporcionar un nivel adicional de seguridad impidiendo el acceso a las instancias de la aplicación y la base de datos desde Internet. Utilice un grupo de seguridad de red personalizado para impedir el acceso a las instancias de la aplicación y la base de datos desde Internet y permitir el acceso a la base de datos y los hosts de la aplicación en el puerto 22 desde el host de bastión con fines de administración. No active el acceso SSH a las instancias de la aplicación y la base de datos desde Internet, pero puede permitir el acceso SSH a estas instancias desde la subred que contiene el host bastion.

Puede acceder a las instancias de la subred privada mediante el servidor bastion.

Grupo de Seguridad de Red para el Host Bastion

El grupo de seguridad de red bastion permite acceder al host bastion desde Internet en el puerto 22.

  • Para permitir el tráfico SSH desde la red local al host bastion a través de Internet:

    Entrada con estado: Permitir tráfico TCP desde CIDR0.0.0.0/0 de origen y todos los puertos de origen al puerto de destino 22 (SSH).

    Tipo de origen = CIDR, CIDR de origen = 0.0.0.0/0, Protocolo IP = TCP, Rango de puertos de origen = Todos, Rango de puertos de destino = 22

    También puede restringir el host bastion al que se puede acceder a través de Internet en el puerto 22 solo desde el centro de datos en lugar de Internet público (0.0.0.0/0). Para ello, utilice la IP del enrutador de borde en lugar de CIDR de origen como 0.0.0.0/0 en la regla de entrada con estado.

  • Para permitir todo el tráfico desde el host bastion a Oracle Cloud Infrastructure:

    Salida con estado: Permitir tráfico TCP a CIDR0.0.0.0/0 de destino desde todos los puertos de origen a todos los puertos de destino.

    Tipo de Destino = CIDR, CIDR de Destino = < Bloque CIDR de VCN>, Protocolo IP = TCP, Rango de Puerto de Origen = Todo, Rango de Puerto de Destino = Todo

Puede agregar o eliminar reglas del grupo de seguridad de red en función de sus requisitos. Además, especifique los puertos en los que desea acceder a los servidores de aplicaciones de Java y a los servidores de Application Interface Services.

Grupo de Seguridad de Red para el Nivel de Administración

  • Entrada con estado: permite el tráfico TCP en el puerto de destino 22 (SSH) desde el bloque CIDR de origen de VCN y cualquier puerto de origen.

  • Entrada con estado: bloque CIDR de origen de VCN en TCP, puerto de origen = all, puerto de destino = 445, 5985, 14501-14510, 3000, 8998-8999, 5150

  • Salida estable: Permitir todo el tráfico.

Grupo de seguridad de red para el nivel de equilibrador de carga

La arquitectura contiene equilibradores de carga privados, que se colocan en subredes privadas. Si coloca las instancias del equilibrador de carga en una subred pública, permitirá el tráfico de Internet a las instancias del equilibrador de carga.

  • Entrada con estado: bloque CIDR de origen de VCN y red local en TCP, puerto de origen = all, puerto de destino = puertos en los que ha creado listener en las instancias del equilibrador de carga

  • Salida estable: Permitir todo el tráfico.

Grupo de seguridad de red para el nivel de presentación

  • Para permitir el tráfico desde el entorno local y VCN a la subred de nivel de presentación:

    Entrada con estado: bloque CIDR de origen de VCN y red local en TCP, puerto de origen = all, puerto de destino = 14501-14510, 5150, puerto del servidor de administración de Weblogic, puertos del servidor web

  • Entrada con estado: bloque CIDR de origen de VCN en TCP, puerto de origen = all, puerto de destino = 22 (SSH)

  • Para permitir el tráfico desde la subred de nivel de presentación a la subred de nivel medio:

    Salida con estado: Origen 0.0.0.0/0 en TCP, puerto de origen = all, puerto de destino = all

Además, especifique los puertos sobre los que desea acceder a los servidores de Java Application y Application Interface Services y los puertos sobre los que desea acceder a los servidores de Oracle Business Intelligence Publisher.

Grupo de seguridad de red para el nivel medio

  • Para permitir el tráfico desde el entorno local y VCN a la subred de nivel medio:

    Entrada con estado: bloque CIDR de origen de VCN y red local en TCP, puerto de origen = all, puerto de destino = 6017-6023, 14502-14510, 5150

  • Entrada con estado: bloque CIDR de origen de VCN en TCP, puerto de origen = all, puerto de destino = 22 (SSH)

  • Para permitir el tráfico desde la subred de nivel medio a la subred de nivel de presentación:

    Salida con estado: Origen 0.0.0.0/0 en TCP, puerto de origen = all, puerto de destino = all

Lista de seguridad para el nivel de base de datos

  • Para permitir el tráfico desde el host bastion hasta el nivel de base de datos:

    Entrada con estado: bloque CIDR de origen del host bastion en TCP, puerto de origen = all, puerto de destino = 22

  • Para permitir el tráfico desde el nivel medio hasta el nivel de base de datos:

    Entrada con estado: bloque CIDR de origen de las capas medias en TCP, puerto de origen = all, puerto de destino = 1521

  • Para permitir el tráfico desde el entorno local y VCN a la subred de nivel de presentación:

    Entrada con estado: bloque CIDR de origen de VCN en TCP, puerto de origen = all, puerto de destino = 14502-14510, 5150

  • Para permitir el tráfico de la capa de base de datos a la capa media:

    Salida con estado: Destino 0.0.0.0/0 en TCP, puerto de origen = all, puerto de destino = all