Configuración de una solución de DR híbrida para Oracle WebLogic Server

Para garantizar la continuidad del negocio en caso de desastres, deseará implementar una estrategia de recuperación ante desastres (DR) para sus aplicaciones locales que proporcione protección de datos y le permita cambiar rápidamente al sistema en espera con una pérdida mínima de datos y productividad. Puede configurar una estrategia de DR híbrida en la que los sistemas principales sean locales y los sistemas en espera estén en Oracle Cloud Infrastructure (OCI). Con la ayuda de Oracle Data Guard, esta solución proporciona una infraestructura de alta disponibilidad, segura y escalable que le permite recuperarse de desastres de forma fiable y segura.

Antes de empezar

Antes de empezar a desplegar una solución de recuperación ante desastres (DR) híbrida para el sistema Oracle WebLogic Server, asegúrese de que está familiarizado con las mejores prácticas de alta disponibilidad en red, almacenamiento y configuración de host para sistemas Oracle WebLogic Server locales.

El sistema de Oracle WebLogic Server utilizado en este documento es un entorno de alta disponibilidad que se ha configurado siguiendo las mejores prácticas estándar de MAA descritas en Enterprise Deployment Guide for Oracle SOA Suite (EDG) para sistemas Fusion Middleware. Aunque no todos los escenarios siguen esta topología exacta al detalle, esto cubre muchos componentes y combinaciones diferentes, se utiliza con frecuencia en despliegues grandes e implanta recomendaciones de alta disponibilidad que se deben aplicar antes de desplegar un sistema de recuperación ante desastres (DR). Por lo tanto, se considera el mejor ejemplo de referencia de un sistema principal para una solución de DR híbrida para Oracle WebLogic Server. En función de esto, se recomienda familiarizarse con las mejores prácticas de despliegue de Oracle WebLogic Server High Availability and Enterprise para las mejores prácticas de configuración de red, almacenamiento y host antes de desplegar un sistema híbrido.

Consulte lo siguiente para obtener más información:

• Oracle Fusion Middleware High Availability Guide
• Guía de Despliegue de Empresa de Oracle Fusion Middleware para Oracle SOA Suite
• Guías de despliegue empresarial de Oracle Fusion Middleware en Mejores prácticas de MAA: Oracle Fusion Middleware

Asegúrese de que también está familiarizado con los conceptos y la administración de Oracle Cloud Infrastructure.

Arquitectura

Esta arquitectura muestra el entorno del centro de datos principal local con un sistema en espera en Oracle Cloud Infrastructure (OCI). Utilice esta arquitectura para una solución de recuperación ante desastres (DR) híbrida para su entorno Oracle WebLogic Server local.

El sistema principal es un sistema Oracle WebLogic Server ubicado localmente. El sistema en espera se crea desde cero en un arrendamiento de OCI que utiliza Oracle Cloud Infrastructure FastConnect (o VPN de sitio a sitio) para conectarse con el entorno local.

La capa media de OCI se crea aprovisionando imágenes de Oracle WebLogic Server para OCI y no la pila de Oracle WebLogic Server para OCI (existen restricciones en las versiones del sistema operativo, los usuarios del sistema operativo y la estructura de directorios que impiden que las pilas de Oracle WebLogic Server para OCI funcionen correctamente como base de datos en espera para un sistema local).

El nivel de base de datos del sitio de OCI es un sistema de base de datos Oracle Real Application Clusters (Oracle RAC).

Descripción de la ilustración maa-wls-hybrid-dr.png

maa-wls-hybrid-dr-oracle.zip

Esta arquitectura admite los siguientes componentes en el centro de datos principal local:

• Red local

  Esta red es la red local que utiliza su organización. Es uno de los radios de la topología.

• equilibrador de carga

  Proporciona una distribución automática del tráfico desde un único punto de entrada a varios servidores del backend.

• Oracle WebLogic Server

  El dominio de Oracle WebLogic Server es un entorno de alta disponibilidad que se ha configurado siguiendo las mejores prácticas estándar de MAA para alta disponibilidad.

• Oracle Real Application Clusters (Oracle RAC)

  Oracle RAC permite ejecutar una única instancia de Oracle Database en varios servidores para maximizar la disponibilidad y activar la escalabilidad horizontal, al tiempo que accede al almacenamiento compartido. Las sesiones de usuario que se conectan a instancias de Oracle RAC pueden realizar un failover y reproducir de forma segura los cambios durante las interrupciones, sin realizar ningún cambio en las aplicaciones de usuario final, lo que oculta el impacto de las interrupciones a los usuarios finales.

Esta arquitectura soporta los siguientes componentes en el entorno secundario en espera en OCI:

• Región

  Una región de Oracle Cloud Infrastructure es un área geográfica localizada que contiene uno o más centros de datos, denominados dominios de disponibilidad. Las regiones son independientes de otras regiones y grandes distancias pueden separarlas (entre países e incluso continentes).

• Red virtual en la nube (VCN) y subred

  Una VCN es una red personalizable y definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de centros de datos tradicionales, las VCN le proporcionan un control total de su entorno de red. Una VCN puede tener varios bloques CIDR que no se superpongan y que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, cuyo ámbito puede ser una región o un dominio de disponibilidad. Cada subred está formada por un rango de direcciones contiguas que no se solapan con las demás subredes de la VCN. Puede cambiar el tamaño de una subred después de la creación. Una subred puede ser pública o privada.

  Las subredes privadas se recomiendan genéricamente por motivos de seguridad, a menos que se deba acceder al recurso desde la red pública de Internet (si se accede a un equilibrador de carga desde la red pública de Internet, debe estar en una subred pública).

• Gateway de enrutamiento dinámico (DRG)

  El DRG es un enrutador virtual que proporciona una ruta de acceso para el tráfico de red privada entre las VCN de la misma región, entre una VCN y una red fuera de la región, como una VCN de otra región de Oracle Cloud Infrastructure, una red local o una red de otro proveedor en la nube.

• FastConnect

  Oracle Cloud Infrastructure FastConnect proporciona una forma sencilla de crear una conexión dedicada y privada entre el centro de datos y Oracle Cloud Infrastructure. FastConnect proporciona opciones de mayor ancho de banda y una experiencia de red más fiable en comparación con las conexiones basadas en Internet.

• Lista de seguridad

  Para cada subred, puede crear reglas de seguridad que especifiquen el origen, el destino y el tipo de tráfico que se debe permitir dentro y fuera de la subred.

• Tabla de ruta

  Las tablas de rutas virtuales contienen reglas para enrutar el tráfico desde subredes a destinos fuera de una VCN, normalmente a través de gateways.

• equilibrador de carga

  El servicio Oracle Cloud Infrastructure Load Balancing proporciona una distribución automatizada del tráfico desde un único punto de entrada a varios servidores en el backend.

• Cloud Guard

  Puede utilizar Oracle Cloud Guard para supervisar y mantener la seguridad de los recursos en Oracle Cloud Infrastructure. Cloud Guard utiliza recetas de detector que puede definir para examinar los recursos en busca de debilidades de seguridad y para supervisar a los operadores y usuarios en busca de determinadas actividades de riesgo. Cuando se detecta cualquier actividad no segura o de configuración incorrecta, Cloud Guard recomienda acciones correctivas y ayuda a realizar esas acciones, en función de las recetas de responsable de respuesta que pueda definir.

• Sistema de base de datos

  El sistema de Oracle Database es un servicio de base de datos de Oracle Cloud Infrastructure (OCI) que permite crear, ampliar y gestionar bases de datos Oracle completas. El sistema de base de datos utiliza el almacenamiento de OCI Block Volumes en lugar del almacenamiento local y puede ejecutar Oracle Real Application Clusters (Oracle RAC) para mejorar la disponibilidad.

• Servicio de Oracle Cloud Infrastructure File Storage

  El servicio Oracle Cloud Infrastructure File Storage ofrece un sistema de archivos de red duradero, escalable, seguro y empresarial. Puede conectarse a un sistema de archivos del servicio File Storage desde cualquier instancia con hardware dedicado, de máquina virtual o de contenedor en su red virtual en la nube (VCN). El servicio de almacenamiento de archivos soporta el protocolo del sistema de archivos de red versión 3.0 (NFSv3). El servicio admite el protocolo de gestor de bloqueo de red (NLM) para la funcionalidad de bloqueo de archivos.

  Oracle Cloud Infrastructure File Storage emplea el almacenamiento replicado en 5 direcciones, situado en diferentes dominios de errores, para proporcionar redundancia a la protección de datos resiliente. Los datos están protegidos con la codificación de borrado. El servicio de almacenamiento de archivos está diseñado para cumplir las necesidades de aplicaciones y usuarios que necesitan un sistema de archivos de empresa en una amplia variedad de casos de uso.

• Oracle Cloud Infrastructure Block Volumes

  El servicio Oracle Cloud Infrastructure Block Volumes le permite aprovisionar y gestionar volúmenes de almacenamiento en bloque de forma dinámica. Puede crear, asociar, conectar y mover volúmenes, así como cambiar el rendimiento de estos, según sea necesario, para cumplir con los requisitos de almacenamiento, rendimiento y aplicación. Después de asociar y conectar un volumen a una instancia, puede utilizar el volumen como si se tratara de una unidad de disco duro normal.

• Sistema de base de datos Oracle RAC

  Oracle Real Application Clusters (Oracle RAC) permite a los clientes ejecutar una única instancia de Oracle Database en varios servidores para maximizar la disponibilidad y permitir la escalabilidad horizontal, al tiempo que acceden al almacenamiento compartido. Las sesiones de usuario que se conectan a instancias de Oracle RAC pueden realizar un failover y reproducir de forma segura los cambios durante las interrupciones, sin realizar ningún cambio en las aplicaciones de usuario final, lo que oculta el impacto de las interrupciones a los usuarios finales. El marco de alta disponibilidad de Oracle RAC mantiene la disponibilidad de servicios al almacenar la información de configuración de cada servicio en Oracle Cluster Registry (OCR).

  El sistema de base de datos Oracle RAC está en la capa de base de datos.

• Data Guard

  Oracle Data Guard proporciona un juego completo de servicios que crean, mantienen, gestionan y supervisan una o más bases de datos en espera para permitir que las bases de datos Oracle de producción permanezcan disponibles sin interrupción. Oracle Data Guard mantiene estas bases de datos en espera como copias de la base de datos de producción. A continuación, si la base de datos de producción deja de estar disponible debido a una interrupción planificada o no planificada, Oracle Data Guard puede cambiar cualquier base de datos en espera al rol de producción, minimizando el tiempo de inactividad asociado a la interrupción.

Descripción de Topología

La topología de DR híbrida de Oracle WebLogic Server utiliza un modelo activo-pasivo. El sistema principal está en un centro de datos local y el sistema secundario está en Oracle Cloud Infrastructure (OCI). Las redes locales y OCI están interconectadas con Oracle Cloud Infrastructure FastConnect (preferido) o VPN de sitio a sitio.

En el nivel de base de datos, las bases de datos primaria y secundaria se configuran con Oracle Data Guard. Con Oracle Data Guard, todos los cambios que se aplican a la base de datos primaria se replican en la base de datos secundaria (en espera).

El nivel medio secundario se instala en instancias de OCI Compute, que pueden ser imágenes de Oracle WebLogic Server for Oracle Cloud Infrastructure para aprovechar la licencia de derechos WebLogic incluida en estas imágenes. Los binarios de Oracle Fusion Middleware y el dominio de Oracle WebLogic son una réplica de los binarios y el dominio principal, que utilizan los servicios de Oracle Cloud Infrastructure File Storage como solución de sistema de archivos de red y Oracle Cloud Infrastructure Block Volumes como solución de sistema de archivos de acceso privado de nodo. Los alias de nombre de host de la base de datos primaria también se utilizan como direcciones de listener de Oracle WebLogic Server en el entorno secundario. En la ubicación secundaria, los alias de nombre de host se resuelven con las direcciones IP de los hosts secundarios.

La nivel web del centro de datos principal sigue el modelo de Enterprise Deployment Guide (EDG) con dos hosts de Oracle HTTP Server y un equilibrador de carga (LBR). La misma topología se despliega en el sistema secundario mediante un equilibrador de carga de OCI y hosts de Oracle HTTP Server instalados en instancias informáticas de OCI. En el sistema secundario, también puede implantar la capa web solo con un equilibrador de carga de OCI, que proporciona la mayoría de las funciones que necesita la topología de despliegue empresarial. En este documento solo se incluyen ambas opciones, equilibrador de carga de OCI o equilibrador de carga de OCI y hosts de Oracle HTTP Server.

Se configura una dirección front-end única para acceder a las aplicaciones que se ejecutan en el sistema. El nombre de front-end virtual apunta a la IP del equilibrador de carga en la ubicación principal. En un switchover, el nombre de front-end se actualiza en DNS para que apunte a la IP del equilibrador de carga de OCI en el sitio secundario. Siempre debe apuntar a la IP del equilibrador de carga del sitio que tenga el rol principal.

Durante el funcionamiento normal del negocio, la base de datos en espera es una base de datos física en espera. Se encuentra en estado de montaje o se abre en modo de solo lectura cuando se utiliza Active Data Guard. La base de datos en espera recibe y aplica redo desde la base de datos primaria, pero no se puede abrir en modo de lectura-escritura. Oracle Data Guard replica automáticamente la información que reside en la base de datos en el sitio secundario, incluida la información de Oracle Platform Security Services, esquemas personalizados, logs de transacciones (TLOG), almacenes persistentes de Java Database Connectivity (JDBC) y mucho más.

Durante los pasos de configuración de DR y validación del ciclo de vida descritos en este documento, puede convertir la base de datos en espera de una base de datos física en espera a una base de datos de instantánea en espera para validar la ubicación secundaria sin realizar un switchover completo. Una base de datos en modo de instantánea en espera es una base de datos totalmente actualizable. Una base de datos de instantánea en espera recibe y archiva, pero no aplica, los datos redo recibidos de una base de datos principal. Todos los cambios aplicados a una base de datos de instantánea en espera se desechan cuando se convierte en una base de datos física en espera.

La configuración de dominio WebLogic se debe replicar del sitio principal al secundario. Esta replicación es necesaria y se realiza durante la configuración inicial de DR, y también es necesaria durante el ciclo de vida continuo del sistema. Cuando se realizan cambios de configuración en el dominio principal, se deben replicar en la ubicación secundaria.

Cuando una base de datos en espera se cierra durante el funcionamiento normal del negocio, no recibe actualizaciones de la base de datos primaria y puede que se quede sin sincronizar. Puesto que esto puede provocar una pérdida de datos en un caso de switchover, no se recomienda parar la base de datos en espera durante el funcionamiento normal del negocio. Los hosts en espera de nivel medio se pueden parar. Sin embargo, cuando se detienen los hosts en espera, los cambios de configuración que se replican desde la ubicación primaria no se transferirán al dominio secundario. En este caso, cuando se produce un switchover, el objetivo de tiempo de recuperación (RTO) aumenta ya que los hosts de nivel medio en espera se deben iniciar y el dominio se debe sincronizar con los cambios principales.

Consideraciones sobre la Topología

A continuación, se muestran las suposiciones de topología más relevantes que se tienen en cuenta en esta configuración:

• El sistema principal es un entorno local existente

  El entorno incluye una base de datos Oracle Real Application Clusters (Oracle RAC), hosts de nivel medio y un equilibrador de carga. La configuración del sistema local está fuera del ámbito de este documento.

• El sistema secundario está en Oracle Cloud Infrastructure (OCI)

  El sistema secundario se crea desde cero en OCI y proporciona una versión de Oracle Cloud de su sistema local. Es un sistema totalmente estándar de Oracle Cloud con la capacidad de convertirse en el sistema principal.

• Los sistemas primario y secundario son simétricos

  El sistema secundario tiene el mismo número de nodos en el nivel medio, el nivel web y el nivel de base de datos. Puede haber diferencias en la capa de capa web cuando el equilibrador de carga de OCI se utiliza solo en OCI (sin Oracle HTTP Server).

• Los sistemas principal y secundario utilizan recursos similares

  Aunque las unidades de OCI disponibles pueden no coincidir con los mismos valores exactos de CPU y memoria de la configuración principal existente, debe utilizar las unidades más similares. Oracle recomienda utilizar bases de datos en espera simétricas que proporcionen una potencia de procesamiento similar al sistema principal. De lo contrario, se pueden producir problemas de rendimiento y fallos en cascada cuando la carga de trabajo se conmuta al sistema OCI.

Consideraciones para las redes

Tenga en cuenta lo siguiente al configurar la red:

• Conectividad entre la red local y Oracle Cloud Infrastructure (OCI)

  Las bases de datos locales y OCI se deben comunicar entre sí mediante Oracle SQL*Net Listener (puerto 1521) para el transporte de Oracle Data Guard redo. Los hosts locales y de nivel medio de OCI se deben comunicar entre sí mediante el puerto SSH (para las copias rsync). Oracle recomienda utilizar la comunicación de Oracle Cloud Infrastructure FastConnect entre el centro de datos local y la región de OCI. Oracle Cloud Infrastructure FastConnect proporciona conectividad y ancho de banda seguros y dedicados, con latencia, jitter y costo predecibles. También puede utilizar la VPN de sitio a sitio, que también proporciona conectividad segura entre la ubicación local y OCI. Sin embargo, esto proporciona menor ancho de banda y latencia variable, fluctuación y costo.

• Desactivar la conectividad entre hosts de nivel medio y la base de datos remota

  Se espera que los hosts de nivel medio nunca se conecten a la base de datos remota durante el tiempo de ejecución. La latencia entre las ubicaciones locales y OCI normalmente desaconseja esta interconectividad. Para evitar conexiones accidentales y problemas de carga de trabajo, evite la conectividad de los hosts de nivel medio a la base de datos remota.

• Nombres de Host Virtuales

  Como práctica recomendada, se supone que el sistema local principal utiliza nombres de host virtuales, en lugar del nombre de host del nodo físico, como direcciones de recepción para los servidores Oracle WebLogic Server. Los nombres de host virtuales normalmente son alias del nombre de host del nodo físico. El uso de nombres de host virtual facilita el movimiento de configuraciones a diferentes hosts; sin embargo, este no es un requisito obligatorio. La configuración de este documento funciona siempre que los servidores secundarios de OCI puedan utilizar los nombres de host utilizados como direcciones de recepción en la base de datos primaria como alias en cada nodo (según se resuelve en DNS o /etc/hosts local).

• Solo se necesita una IP virtual para la dirección de recepción del servidor de administración

  La migración automática de servicios está soportada y recomendada para alta disponibilidad (HA) local, lo que significa que los servidores gestionados no están obligados a utilizar direcciones IP virtuales. Solo el servidor de administración necesita una VIP para el failover local. Como práctica recomendada, se supone que el servidor de administración del sistema local principal recibe en una dirección VIP. En este documento se proporcionan instrucciones para configurar una VIP para el servidor de administración en OCI. Sin embargo, esta dirección VIP no es un requisito imprescindible para configurar la recuperación ante desastres en OCI con este documento. Si el servidor de administración principal no recibe en una VIP, puede omitir ese punto.

• equilibrador de carga

  Se utiliza un equilibrador de carga front-end (LBR) en el entorno local principal y un equilibrador de carga de OCI en el entorno en espera.

• Dirección de front-end virtual

  El sistema principal debe utilizar un nombre de front-end virtual (una URL personalizada, como wlsfrontend.example.com) como punto de entrada para los clientes. Este nombre de front-end se resuelve en DNS con la dirección IP del equilibrador de carga principal. En una topología de DR, el sistema secundario está configurado para usar el mismo nombre de front-end virtual. Cuando se produce un switchover o failover al sistema secundario, el nombre de front-end virtual se modifica en el DNS para que apunte a la dirección IP del equilibrador de carga secundario. De esta manera, el acceso de los clientes al sistema no tiene en cuenta el sitio que se está utilizando como principal. Lo mismo se aplica a cualquier nombre de front-end virtual utilizado en el sistema. Por ejemplo, puede utilizar un nombre de front-end adicional, como admin.example.com, para acceder a las funciones de administración de la consola de administración de Oracle WebLogic Server o la consola de Fusion Middleware Control.

Consideraciones para el almacenamiento

Tenga en cuenta lo siguiente al configurar el almacenamiento:

• Estructura de directorios basada en EDG

  Este documento utiliza una estructura de directorios de Enterprise Deployment Guide (EDG) para la configuración de dominio de Oracle WebLogic Server del sistema principal. El modelo de EDG utiliza directorios de dominio independientes para la administración de Oracle WebLogic Server y para cada Oracle WebLogic Server gestionado, como se describe en Preparación del Sistema de Archivos para un Despliegue de Empresa. La estructura de directorios de EDG se utiliza como referencia en los ejemplos. Utiliza una combinación de carpetas compartidas y privadas, que abarca más casos de uso. Si el sistema no utiliza la estructura de directorios de EDG, adapte los ejemplos para que cumplan los requisitos específicos del entorno.

• Consideraciones para el almacenamiento en la base de datos primaria (local)
  Se recomienda no solo almacenar las carpetas compartidas (directorio de dominio del servidor de administración de Oracle WebLogic Server, directorio raíz de planes de despliegue, tiempo de ejecución compartido, etc.), sino también los binarios de directorio raíz de Oracle Fusion Middleware y las configuraciones locales (directorios de dominio de servidor gestionado, carpeta de gestor de nodos) en el almacenamiento NFS en la ubicación principal. Esto facilita la copia de la base de datos primaria a la base de datos en espera. Aunque cada host utilizará sus propios binarios y su propia configuración local de forma privada (volúmenes NFS separados para cada servidor), la copia de la configuración entre sitios es más sencilla si residen en almacenamiento compartido. Mediante este enfoque, es posible montarlos todos desde un nodo único y ejecutar la copia rsync en los nodos remotos en una sola operación. Sin este enfoque, la copia se debe realizar de forma individual, desde cada uno de los nodos principales que almacenan datos de forma privada.

  Nota:

  Los scripts proporcionados para la copia rsync de estos son lo suficientemente flexibles para adaptarse a cualquier caso.
• Consideraciones para carpetas compartidas en la secundaria (OCI)

  Las carpetas que se deben compartir entre los hosts de nivel medio (por ejemplo, el directorio de dominio del servidor de administración de Oracle WebLogic Server, el directorio raíz de los planes de despliegue, el tiempo de ejecución compartido, etc.) se deben almacenar en el almacenamiento compartido. OCI proporciona Oracle Cloud Infrastructure File Storage como solución de sistema de archivos de red.

  Los diferentes artefactos son una carpeta compartida y tienen un uso y un ciclo de vida diferentes. Se deben colocar en un almacenamiento compartido separado, según su uso. Por ejemplo:

  • El host del servidor de administración accede principalmente a la configuración compartida (por ejemplo, directorio de dominio del servidor de administración WebLogic Server, directorio raíz de planes de implementación). El resto de los hosts (para planes de despliegue, almacenes de claves compartidos, etc.) accede a ella de forma permanente. Se debe colocar en un sistema de archivos de Oracle Cloud Infrastructure File Storage.
  • Si el sistema utiliza una carpeta compartida para artefactos de tiempo de ejecución (por ejemplo, archivos creados y leídos por la aplicación), todos los hosts de nivel medio suelen utilizarla simultáneamente. Debe colocar los artefactos de tiempo de ejecución en otro sistema de archivos de Oracle Cloud Infrastructure File Storage o en un montaje de sistema de archivos de base de datos (DBFS).
• Consideraciones para el almacenamiento de carpetas privadas en la secundaria (OCI)

  Cada host utiliza los binarios de FMW y las configuraciones locales de forma individual. Es una buena práctica almacenarlos en un almacenamiento externo en lugar de en el volumen de inicio por defecto de los hosts.

  • En OCI, puede almacenar los binarios de FMW en Oracle Cloud Infrastructure Block Volumes para cada host. Cuando hay más de dos hosts de nivel medio, se recomienda utilizar directorios raíz binarios compartidos redundantes (consulte la Guía de alta disponibilidad). Para ello, utilice Oracle Cloud Infrastructure File Storage para almacenar los binarios de FMW.
  • Puede almacenar la configuración local (por ejemplo, los directorios de dominio del servidor gestionado WebLogic y la carpeta del gestor de nodos) en Oracle Cloud Infrastructure Block Volumes porque se espera que cada host los utilice de forma privada. También puede utilizar los sistemas de archivos de Oracle Cloud Infrastructure File Storage montados de forma privada por cada nodo.
  Para facilitar la copia del sitio primario al remoto, es posible montar los archivos de almacenamiento desde un nodo único y ejecutar la copia rsync en una sola operación (para los volúmenes en bloque, otro host puede montar los archivos en modo de solo lectura). Como alternativa, la copia se puede realizar de forma individual, desde cada uno de los nodos que almacenan los datos de forma privada.

  Nota:

  Los scripts proporcionados para la copia rsync de estos son lo suficientemente flexibles para adaptarse a cualquier caso.
• replicación de almacenamiento

  No hay replicación directa en el nivel de almacenamiento entre la ubicación local y OCI. La copia de los binarios y la configuración de principal a en espera se realiza con rsync a través de shell seguro (SSH) a través de una conexión privada en Oracle Cloud Infrastructure FastConnect o VPN de sitio a sitio (no utilice nunca la red pública de Internet). La copia de los artefactos de tiempo de ejecución y configuración también se puede basar en DBFS, según las necesidades del cliente. Más adelante se proporcionan más detalles al respecto.

• Almacenes persistentes WebLogic

  Se supone que los almacenes persistentes WebLogic utilizados para TLOGS y mensajes JMS son almacenes persistentes JDBC y se almacenan en tablas de base de datos. De esta manera, se puede acceder a los almacenes persistentes desde cualquier miembro del cluster (para proporcionar HA local con Service Migration). Esto también aprovecha el Oracle Data Guard subyacente, que replica automáticamente TLOGS y JMS en el sitio secundario.

Consideraciones para los sistemas operativos

Las imágenes de Oracle WebLogic Server for Oracle Cloud Infrastructure soportan los sistemas operativos Oracle Linux 7.9 y Oracle Linux 8.5.

Las instancias informáticas de nivel medio y de nivel web deben utilizar la imagen del sistema operativo y la unidad de computación más similares a la imagen y la unidad que utilizan los hosts locales. Al utilizar WebLogic Server para imágenes de OCI, la solución se restringe a la versión del sistema operativo que utilizan (ahora Oracle Linux 7.X o 8.X).

• Versiones del sistema operativo para hosts de nivel medio

  Un Oracle WebLogic Server que se ejecute en Oracle Cloud Infrastructure (OCI) debe estar cubierto por una licencia válida y un contrato de soporte además de la licencia y el contrato de soporte utilizados para cubrir el Oracle WebLogic Server que se ejecuta localmente. En Oracle Cloud, las instancias informáticas se pueden crear con las imágenes de Oracle WebLogic Server para OCI. Las instancias informáticas creadas con estas imágenes incluyen el derecho a ejecutar Oracle WebLogic Server y se facturan por OCPU/hora cuando están en estado de ejecución. Estas imágenes están disponibles para los sistemas operativos Oracle Linux 7.9 y Oracle Linux 8.5.

• Versiones del sistema operativo para hosts de capa web

  Es necesario que un Oracle HTTP Server que se ejecute en OCI esté cubierto por un contrato válido de licencia y soporte, además del contrato de licencia y soporte utilizado para cubrir el Oracle HTTP Server que se ejecute localmente. En Oracle Cloud, las instancias informáticas se pueden crear con las imágenes de Oracle WebLogic Server para OCI. Las instancias informáticas creadas con estas imágenes incluyen el derecho a ejecutar Oracle HTTP Server y se facturan por OCPU/hora por el derecho a ejecutar el software WebLogic cuando están en estado de ejecución. Estas imágenes están disponibles para los sistemas operativos Oracle Linux 7.9 y Oracle Linux 8.5.

Consideraciones para Oracle WebLogic Server

Al implantar esta solución, tenga en cuenta lo siguiente:

• Productos sobre Oracle WebLogic Server

  Los entornos con productos adicionales instalados sobre Oracle WebLogic Server pueden beneficiarse de los procedimientos descritos en este manual, pero los detalles de otros productos están fuera del ámbito de este documento.

• Edición de Oracle WebLogic Server

  Este documento se puede aplicar a Oracle WebLogic Suite Edition y a Oracle WebLogic Server Enterprise Edition. Sin embargo, cuando la base de datos es una base de datos Oracle Real Application Clusters (Oracle RAC) (que es una práctica recomendada para obtener alta disponibilidad local), este documento asume que se utiliza Oracle WebLogic Suite Edition porque Oracle WebLogic Server Enterprise Edition no incluye derechos para utilizar orígenes de datos de Active GridLink.

• Dominios WebLogic activados para JRF

  Este documento se aplica a dominios con componentes de Java Required Files (JRF) activados y dominios básicos.

  Los dominios activados para JRF tienen más dependencias en la base de datos que los dominios básicos. Debido a esto, un modelo de recuperación ante desastres (DR) diseñado para el dominio activado para JRF tiene más restricciones. Los dominios básicos tienen más flexibilidad para la DR, pero un modelo de DR válido para un dominio básico puede no aplicarse a un dominio activado para JRF porque no tiene en cuenta las dependencias de base de datos de JRF WebLogic. Un modelo de DR válido para un dominio activado para JRF también es válido para un dominio básico. El modelo descrito en este documento se basa en dominios activados para JRF, por lo tanto, se aplica a ambos tipos de dominios de Oracle WebLogic.

Consideraciones para la base de datos

Tenga en cuenta lo siguiente al configurar las bases de datos:

• Multi-inquilino

  La base de datos primaria debe ser una base de datos multiinquilino (CDB/PDB). Es necesario para configurar un Oracle Data Guard híbrido en Oracle Cloud Infrastructure.

• Niveles de parches

  El directorio raíz de Oracle para la base de datos local debe estar en el mismo nivel de parche que la base de datos en espera.

• Cifrado de datos transparente

  Utilice el cifrado de datos transparente (TDE) para las bases de datos primaria y en espera a fin de garantizar que todos los datos estén cifrados. Si la base de datos local aún no está activada con TDE, se recomienda convertirla en TDE antes de configurar Oracle Data Guard para proporcionar el entorno más seguro.

• Alta disponibilidad

  Para obtener alta disponibilidad local a nivel de base de datos y seguir la topología de EDG, utilice Oracle Real Application Clusters (Oracle RAC) para las bases de datos primaria y en espera. Aunque está centrado en Oracle RAC, este procedimiento se aplica a una única base de datos. Sin embargo, la práctica recomendada es utilizar Oracle RAC para obtener alta disponibilidad local en el nivel de base de datos.

• Servicio Database

  La capa media local principal debe utilizar un servicio de base de datos de aplicación para conectarse a la base de datos primaria.

• Sistema de base de datos de Oracle Cloud Infrastructure (OCI)

  Utilice un sistema de base de datos OCI (con hardware dedicado, máquina virtual u Oracle Exadata Database Service) como base de datos en espera. Una instancia de Oracle Autonomous Database, compartida o dedicada, está fuera del ámbito de este documento. No proporciona una serie de funciones necesarias para la configuración de recuperación ante desastres híbrida, como la capacidad de configurar Oracle Data Guard con una base de datos local y la conversión de instantánea en espera.

• Alias TNS en las cadenas de conexión de base de datos WebLogic

  Este documento utiliza un alias TNS para definir la cadena de conexión a la base de datos en la configuración de Oracle WebLogic. El alias TNS se resuelve con un archivo tnsnames.ora, que es diferente en cada sitio y apunta a la base de datos local. Dado que se utiliza el mismo nombre de alias en el principal y en el secundario, no es necesario modificar la configuración WebLogic después de replicarla del principal al secundario.

  Si el principal aún no está usando este enfoque, se requiere una configuración inicial única. Los detalles sobre esto se describen más adelante en este documento.

Consideraciones para Identity Management

Tenga en cuenta lo siguiente al configurar Identity Management:

• LDAP (Lightweight Directory Access Protocol)

  El sistema puede utilizar un LDAP externo para la autenticación (por ejemplo, Oracle Unified Directory), siempre que se pueda acceder al LDAP externo desde los sistemas principal y en espera.

• Solución de recuperación ante desastres para LDAP

  La solución de recuperación ante desastres para cualquier servicio LDAP externo está fuera del alcance de este documento y debe ser proporcionada por el producto LDAP específico. La solución de DR para LDAP debe proporcionar una forma única de acceder a ella (normalmente un nombre de host virtual), que no cambia cuando hay un switchover en el sistema LDAP.

Resumen de consideraciones

A continuación, se proporciona un resumen de lo que debe tener en cuenta al planificar una solución de recuperación ante desastres.

Consideraciones para	Resumen	Obligatoria o altamente recomendada
Topología	El sistema principal es un entorno local existente.	Muy recomendado
Topología	El sistema secundario está en Oracle Cloud Infrastructure (OCI) que se crea desde cero en OCI.	Obligatorio
Topología	Los sistemas primario y secundario son simétricos y tienen el mismo número de nodos en el nivel de base de datos, el nivel medio y el nivel web.	Obligatorio
Topología	La capa web principal consta de un equilibrador de carga delante de Oracle HTTP Server.	Muy recomendado
Topología	Los sistemas principal y secundario utilizan recursos similares (CPU, memoria, etc.).	Obligatorio
Red	Utilice OCI FastConnect para la conectividad entre las ubicaciones locales y OCI, como alternativa, VPN de sitio a sitio. Nunca Internet pública.	Obligatorio
Red	Desactive la conectividad entre los hosts de nivel medio y la base de datos remota. Solo es necesario si se utiliza Oracle Database File System (DBFS) para replicar la configuración.	Muy recomendado
Red	Utilice nombres de host virtuales para las direcciones de recepción del servidor WebLogic.	Muy recomendado
Red	IP Virtual para el Servidor de Administración.	Muy recomendado
Red	Dirección de front-end virtual.	Obligatorio
Almacenamiento	Estructura de directorios basada en EDG.	Muy recomendado
Almacenamiento	Carpetas privadas y compartidas locales en el almacenamiento externo para que se puedan montar desde un nodo único para centralizar las operaciones rsync.	Muy recomendado
Almacenamiento	Configuración compartida de OCI en Oracle Cloud Infrastructure File Storage.	Obligatorio
Almacenamiento	Tiempo de ejecución compartido de OCI en OCI File Storage u Oracle Database File System (DBFS).	Obligatorio
Almacenamiento	Carpetas binarias de OCI FMW en OCI File Storage montadas de forma privada.	Muy recomendado
Almacenamiento	Configuraciones locales de OCI en Oracle Cloud Infrastructure Block Volumes (alternativamente, OCI File Storage montado de forma privada).	Muy recomendado
Almacenamiento	Almacenamiento en zona intermedia del montaje de DBFS (sólo cuando se utiliza la réplica basada en DBFS para la configuración).	Muy recomendado
Almacenamiento	Replicación de almacenamiento basada en rsync (o DBFS para algunos artefactos específicos como la configuración).	Muy recomendado
Almacenamiento	WebLogic almacenes persistentes (TLOGS, JMS) en almacenes persistentes de JDBC.	Obligatorio (*si la información de JMS es relevante)
Base de datos	El nivel de parche de la base de datos local es el mismo que el de la base de datos en espera.	Obligatorio
Base de datos	Cifrado de datos transparente (TDE) para las bases de datos primaria y en espera. Si la base de datos local aún no está activada con TDE, se recomienda convertirla a TDE antes de configurar Oracle Data Guard.	Obligatorio
Base de datos	Base de datos Oracle RAC para alta disponibilidad local.	Muy recomendado
Base de datos	Base de datos de multi-arrendamiento principal.	Obligatorio
Base de datos	Utilice un servicio de base de datos de aplicaciones, no el servicio de administración por defecto, para conectarse a la base de datos.	Obligatorio
Base de datos	En OCI, utilice el sistema de base de datos (BM, VM u Oracle Exadata Database Service), no Oracle Autonomous Database.	Obligatorio
Base de datos	Alias TNS en las cadenas de conexión de base de datos WebLogic.	Muy recomendado
Administración de identidad	El sistema puede utilizar un LDAP externo para la autenticación (por ejemplo, Oracle Unified Directory), siempre que se pueda acceder al LDAP externo desde los sistemas principal y en espera.	Obligatorio (el uso de LDAP externo NO es obligatorio, pero si se utiliza, debe ser accesible desde ambos sitios)
Administración de identidad	La solución de recuperación ante desastres para cualquier servicio LDAP externo está fuera del alcance de este documento y debe ser proporcionada por el producto LDAP específico. La solución de DR para LDAP debe proporcionar una forma única de acceder a ella (normalmente un nombre de host virtual), que no cambia cuando hay un switchover en el sistema LDAP.	Obligatorio (el uso de LDAP externo NO es obligatorio, pero si se utiliza y está protegido por DR, debe proporcionar una dirección de acceso virtual que siga siendo la misma cuando se produce un switchover/failover para el modo de acceso de LDAP)

En la siguiente tabla se resumen las consideraciones del sistema operativo y de Oracle WebLogic, además de las consideraciones descritas en la tabla anterior.

Consideraciones para	Resumen	Obligatoria o altamente recomendada
Sistema operativo	Versiones locales del sistema operativo de nivel medio Oracle Linux 7 u 8	Muy recomendado (para aprovechar las imágenes de Oracle WebLogic Server para OCI)
Sistema operativo	Versiones del sistema operativo de capa web local de Oracle Linux 7 u 8	Muy recomendado (para aprovechar las imágenes de Oracle WebLogic Server para OCI)
Oracle WebLogic Server	Sólo software WebLogic. Otros productos fuera del ámbito del documento	n/d
Oracle WebLogic Server	Oracle WebLogic Suite Edition cuando se utiliza Oracle RAC, para utilizar orígenes de datos GridLink	Obligatorio
Oracle WebLogic Server	WebLogic Dominios activados para JRF y no activados para JRF	n/d (ambos son válidos)

Acerca de los servicios y los roles necesarios

Esta solución requiere los siguientes servicios y roles:

Estos son los roles necesarios para cada servicio.

Nombre de servicio: rol	Necesario para...
Oracle Cloud Infrastructure: administrator	Cree los recursos necesarios en el arrendamiento de OCI: compartimento, sistema de base de datos, instancias informáticas, recursos FSS y equilibrador de carga.
Red: administrator	Configure los recursos de red necesarios tanto en entornos locales como en OCI: Fast Connect, VCN y subredes en OCI, reglas de seguridad de red y reglas de enrutamiento.
Oracle Data Guard: root, oracle y sysdba	Configure Oracle Data Guard entre OCI principal local y en espera, y realice conversiones de roles.
Oracle Database: sysdba	Gestionar las bases de datos.
Oracle WebLogic Server: root, oracle	Configure los hosts de nivel medio según sea necesario: realice la configuración de nivel de sistema operativo, agregue alias de host, gestione direcciones IP virtuales y monte sistemas de archivos.
Oracle WebLogic Server: Weblogic Administrator	Gestionar Oracle WebLogic Server: pare, inicie y aplique los cambios de configuración de WebLogic.

Consulte Descubra cómo obtener servicios de Oracle Cloud para las soluciones de Oracle para obtener los servicios en la nube que necesita.