Configuración de una Solución de DR Híbrida para Oracle SOA Suite

Antes de empezar

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

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 la Guía de Despliegue de Empresa para Oracle SOA Suite (EDG) para sistemas Fusion Middleware. Aunque no todos los escenarios siguen esta topología exacta en detalle, esto abarca muchos componentes y combinaciones diferentes, se utiliza con frecuencia en despliegues grandes e implementa 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 empresarial y de alta disponibilidad de Oracle WebLogic Server para la configuración de red, almacenamiento y host antes de desplegar un sistema híbrido.

Consulte lo siguiente para obtener más detalles:

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 híbrida de recuperación ante desastres (DR) para el entorno local de Oracle SOA Suite.

El sistema principal es un sistema de Oracle SOA Suite 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 al entorno local.

El nivel medio en OCI se crea instalando SOA en máquinas virtuales (VM) de OCI y no una instancia de Oracle SOA Cloud Service u Oracle SOA Suite on Marketplace (hay restricciones en las versiones del sistema operativo, los usuarios del sistema operativo y la estructura de directorios que impiden que la instancia de Oracle SOA Cloud Service u Oracle SOA Suite on Marketplace funcione correctamente como base de datos en espera para un sistema local).

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

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

maa-soa-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 automatizada del tráfico desde un único punto de entrada a varios servidores del backend.
Oracle SOA Suite
El entorno SOA se configura siguiendo la Guía de Despliegue de Empresa para Oracle SOA Suite (EDG) estándar. Esta topología abarca muchos componentes diferentes que se utilizan a menudo en despliegues grandes e implementa recomendaciones de alta disponibilidad que se deben aplicar antes de desplegar un sistema de DR.
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 se accede al almacenamiento compartido. Las sesiones de usuario que se conectan a instancias de Oracle RAC pueden realizar un failover y reproducir los cambios de forma segura durante las interrupciones, sin 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 de 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 entre sí y pueden separarse grandes distancias (entre países o incluso continentes).
Red y subred virtuales en la nube (VCN)
Una VCN es una red personalizable definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes de los centros de datos tradicionales, las redes virtuales le proporcionan un control completo de su entorno de red. Una VCN puede tener varios bloques de CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, las cuales se pueden acotar a una región o a un dominio de disponibilidad. Cada subred está formada por un rango contiguo de direcciones 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 para el tráfico de red privada entre las redes virtuales en la misma región, entre una VCN y una red fuera de la región, como una VCN en otra región de Oracle Cloud Infrastructure, una red local o una red en 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 rutas
Las tablas de rutas virtuales contienen reglas para enrutar el tráfico de 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 deficiencias de seguridad y para supervisar a los operadores y usuarios para determinadas actividades de riesgo. Cuando se detecta una configuración incorrecta o una actividad no segura, 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
Oracle Database System es un servicio de base de datos de Oracle Cloud Infrastructure (OCI) que le permite crear, escalar y gestionar bases de datos Oracle completas. El sistema de base de datos utiliza OCI Block Volumes storage en lugar de almacenamiento local y puede ejecutar Oracle Real Application Clusters (Oracle RAC) para mejorar la disponibilidad.
Servicio Oracle Cloud Infrastructure File Storage
El servicio Oracle Cloud Infrastructure File Storage ofrece un sistema de archivos de red duradero, ampliable, 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 admite el protocolo del sistema de archivos de red versión 3.0 (NFSv3). El servicio admite el protocolo de administrador de bloqueo de red (NLM) para la funcionalidad de bloqueo de archivos.

Oracle Cloud Infrastructure File Storage emplea un almacenamiento replicado en 5 direcciones, ubicado 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 de 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 activar 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 los cambios de forma segura durante las interrupciones, sin 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 el nivel de base de datos.
Data Guard
Oracle Data Guard proporciona un completo juego de servicios que permiten crear, mantener, gestionar y controlar una o más bases de datos en espera para que las bases de datos Oracle de producción puedan seguir estando 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 SOA Suite 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 principal 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 máquinas virtuales (VM) de OCI. Los binarios de Oracle Fusion Middleware y el dominio SOA son una réplica de los binarios principales y del dominio SOA, utilizando el servicio 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 principal se utilizan también como direcciones de listener de los servidores WebLogic del entorno secundario. En la ubicación secundaria, los alias de nombre de host se resuelven con las direcciones IP de los hosts secundarios.

La capa web del centro de datos principal sigue el modelo de la Guía de despliegue empresarial (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, puede implantar de forma alternativa la capa web solo con un equilibrador de carga de OCI, que proporciona la mayoría de las funciones necesarias para la topología de despliegue empresarial. En este documento se incluyen ambas opciones, solo OCI Load Balancer o OCI Load Balancer y hosts de Oracle HTTP Server.

Se configura una dirección de frontend ú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 primaria. En una operación de switchover, el nombre de frontend se actualiza en DNS para que apunte a la IP del equilibrador de carga de OCI en la ubicación secundaria. Siempre debe apuntar a la IP del equilibrador de carga del sitio que tiene el rol principal.

Durante el funcionamiento normal del negocio, la base de datos en espera es una base de datos física en espera. Está 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 de 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, incluidos los esquemas de arquitectura orientada al servidor (SOA), la información de Oracle Platform Security Services, los esquemas personalizados, los logs de transacciones (TLOG), los 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 una operación de switchover completa. 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 primaria. Todos los cambios aplicados a una instantánea en espera se descartan cuando se convierte en una instantánea en espera física.

La configuración del dominio WebLogic se debe replicar de la ubicación principal a la secundaria. 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 en curso del sistema. Cuando se realizan cambios de configuración en el dominio principal, se deben replicar en la ubicación secundaria.

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

Consideraciones para la topología

Las siguientes son las suposiciones de topología más relevantes consideradas en esta configuración:

El sistema principal es un entorno local existente
El entorno incluye una base de datos de 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 de Oracle Cloud totalmente estándar con la capacidad de convertirse en el sistema principal.
Oracle SOA Suite y componentes
Este documento se centra en el sistema de Oracle SOA Suite, incluidos sus componentes. Por ejemplo, Oracle Service Bus, Oracle Business Process Management, Oracle Enterprise Scheduler Service, etc. Aunque los procedimientos y recomendaciones de este documento se puedan aplicar a otros componentes de Oracle Fusion Middleware que no formen parte de Oracle SOA Suite (como Web Center y Business Intelligence), los detalles y la compatibilidad de estos quedan excluidos de este ejercicio.
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 OCI Load Balancer se utiliza solo en OCI (sin Oracle HTTP Server).
Los sistemas primario y secundario utilizan recursos similares
Aunque es posible que las unidades de OCI disponibles no coincidan con los mismos valores exactos en 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 a la del sistema principal. De lo contrario, se podrían producir problemas de rendimiento y fallos en cascada cuando la carga de trabajo se conmuta al sistema OCI.

Consideraciones para la red

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 el listener de Oracle SQL*Net (puerto 1521) para el transporte redo de Oracle Data Guard. Los hosts locales y de nivel medio de OCI se deben comunicar entre sí mediante el puerto SSH (para 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 una conectividad y un ancho de banda seguros dedicados, con latencia, fluctuaciones y costos predecibles. También puede utilizar la VPN de sitio a sitio, que también proporciona conectividad segura entre el entorno local y OCI. Sin embargo, esto proporciona un menor ancho de banda y una latencia, fluctuación y costo variables.
Desactivar la conectividad entre los hosts de capa media y la base de datos remota
Se espera que los hosts de capa media nunca se conecten a la base de datos remota durante el tiempo de ejecución. La latencia entre on-premises y OCI generalmente desaconseja esta interconectividad. Para evitar conexiones accidentales y problemas de carga de trabajo, impida la conectividad de los hosts de nivel medio a la base de datos remota.
Nombres de hosts virtuales
Como mejor práctica, 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 son normalmente alias del nombre de host del nodo físico. El uso de nombres de host virtuales 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 principal como alias en cada nodo (como 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 la alta disponibilidad (HA) local, lo que significa que los servidores gestionados no son necesarios para utilizar direcciones IP virtuales. Solo el servidor de administración necesita una VIP para el failover local. Como mejor práctica, 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 estricto para configurar Disaster Recovery en OCI con este documento. Si el servidor de administración principal no recibe en una VIP, puede omitir ese punto.
Equilibrador de carga
En el entorno local principal se utiliza un equilibrador de carga front-end (LBR) y en el entorno en espera se utiliza un equilibrador de carga de OCI.
Dirección de front-end virtual
El sistema principal debe utilizar un nombre de frontend virtual (una URL personalizada, como mysoa.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 frontend virtual. Cuando se produce una operación de switchover o failover en el sistema secundario, el nombre de frontend 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 utiliza como principal. Lo mismo se aplica a cualquier nombre de frontend virtual utilizado en el sistema. Por ejemplo, puede utilizar un nombre de frontend adicional, como admin.example.com, para acceder a las funciones de administración de la consola de administración de Oracle WebLogic Server o de la consola de Fusion Middleware Control.

Puede utilizar un nombre de frontend separado, como osb.example.com, para acceder a los servicios de Oracle Service Bus. Este documento utiliza un nombre de host de frontend para la simplificación.

Consideraciones de almacenamiento

Tenga en cuenta lo siguiente al configurar el almacenamiento:

Estructura de directorios basada en EDG
En este documento se 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 a los detalles del entorno.
Consideraciones para el almacenamiento en la ubicación principal (local)
Es una buena práctica almacenar no solo 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 del directorio raíz de Oracle Fusion Middleware y las configuraciones locales (directorios de dominio del servidor gestionado, carpeta del gestor de nodos) en el almacenamiento NFS en la ubicación principal. Esto facilita la copia de principal a 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 fácil si residen en almacenamiento compartido. Con este enfoque, es posible montar todos ellos 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.

Note:
Los scripts proporcionados para la copia rsync de estos son lo suficientemente flexibles como para adaptarse a cualquier caso.
Consideraciones para carpetas compartidas en el secundario (OCI)
Las carpetas que se deben compartir entre los hosts de capa media (por ejemplo, el directorio de dominio del servidor de administración de Oracle WebLogic Server, el directorio raíz de 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 distintos artefactos son carpetas compartidas y tienen un uso y un ciclo de vida diferentes. Deben colocarse 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 despliegue). El resto de los hosts acceden de forma residual (para planes de despliegue, almacenes de claves compartidos, etc.). 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 la utilizan normalmente de forma simultánea. 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 el secundario (OCI)
Los binarios de FMW y las configuraciones locales son utilizados por cada host individualmente. Se recomienda almacenarlos en 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, directorios de dominio de servidor gestionado WebLogic y carpeta de gestor de nodos) en Oracle Cloud Infrastructure Block Volumes porque se espera que cada host los utilice de forma privada. También puede utilizar 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.

Note:
Los scripts proporcionados para la copia rsync de estos son lo suficientemente flexibles como para adaptarse a cualquier caso.
Replicación de almacenamiento
No hay replicación directa en el nivel de almacenamiento entre el entorno 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 una VPN de sitio a sitio (nunca utilice la red pública de Internet). La copia de los artefactos de configuración y tiempo de ejecució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 los mensajes TLOGS y 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 los TLOGS y JMS en el sitio secundario.

Consideraciones para la base de datos

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

Varios Contenidos
La base de datos primaria debe ser una base de datos multi-inquilino (CDB/PDB). Es necesario para configurar una instancia híbrida de Oracle Data Guard en Oracle Cloud Infrastructure.
Niveles de parche
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 Transparent Data Encryption (TDE) para las bases de datos principal y en espera para asegurarse de que todos los datos están cifrados. Si la base de datos local aún no está activada con TDE, se recomienda realizar la conversión a TDE antes de configurar Oracle Data Guard para proporcionar el entorno más seguro.
Alta disponibilidad
Para obtener alta disponibilidad local en el 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 se centra 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 de Base de Datos
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 de TNS en 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 primario y en el secundario, no es necesario modificar la configuración de WebLogic después de replicarla del primario al secundario.

Si el principal aún no está utilizando 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:

Lightweight Directory Access Protocol (LDAP)
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	Obligatorio o altamente recomendado
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 frente a 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 el entorno local y OCI, como alternativa, VPN de sitio a sitio. Nunca internet público.	Obligatorio
Red	Desactive la conectividad entre los hosts de capa media 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 frontend virtual.	Obligatorio
Almacenamiento	Estructura de directorios basada en EDG.	Muy recomendado
Almacenamiento	Carpetas privadas y compartidas locales en 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	Las carpetas de binarios de OCI FMW en OCI File Storage se montan de forma privada.	Muy recomendado
Almacenamiento	Configuraciones locales de OCI en Oracle Cloud Infrastructure Block Volumes (también OCI File Storage montado de forma privada).	Muy recomendado
Almacenamiento	Montaje de DBFS temporal (solo 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 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 principal y en espera. Si la base de datos local aún no está activada con TDE, se recomienda realizar una conversión 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 multi-arrendamiento principal.	Obligatorio
Base de datos	Utilice un servicio de base de datos de aplicación, 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 de TNS en cadenas de conexión de base de datos WebLogic.	Muy recomendado
Identity Management	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, se debe poder acceder a él desde ambos sitios)
Identity Management	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 contra DR, debe proporcionar una dirección de acceso virtual que permanezca igual cuando se produce un switchover/failover para la forma de LDAP de acceder a ella)

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 de 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`	Gestión de las bases de datos.
Oracle WebLogic Server: `root`, `oracle`	Configure los hosts de capa media 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: parar, iniciar y aplicar los cambios de configuración de WebLogic.

Consulte https://docs.oracle.com/pls/topic/lookup?ctx=en/solutions/soa-dr-on-cloud&id=GCSSL para obtener los servicios en la nube que necesita.