Configurar una solución de recuperación ante desastres híbrida para Oracle SOA Suite

Antes de empezar

Antes de empezar a desplegar una solución de recuperación ante desastres (DR) híbrida para el sistema Oracle SOA Suite, asegúrese de que está familiarizado con las mejores prácticas de alta disponibilidad en la red, el almacenamiento y la configuración del host para los 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 SOA Suite local.

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

El nivel medio de OCI se crea instalando SOA en máquinas virtuales (VM) de OCI y no en una instancia de Oracle SOA Cloud Service ni de Oracle SOA Suite on Marketplace (existen restricciones en las versiones del sistema operativo, los usuarios del sistema operativo y la estructura de directorios que impiden que las instancias de Oracle SOA Cloud Service u Oracle SOA Suite on Marketplace 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 maa-soa-hybrid-dr.png a continuación

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 local principal:

Red local
Esta red es la red local utilizada por su organización. Es uno de los voces de la topología.
equilibrador de carga
Proporciona una distribución automatizada del tráfico desde un único punto de entrada a varios servidores en el backend.
Oracle SOA Suite
El entorno SOA se configura siguiendo la Guía de despliegue empresarial para Oracle SOA Suite (EDG) estándar. Esta topología cubre muchos componentes diferentes que a menudo se utilizan en grandes implementaciones e implementa recomendaciones de alta disponibilidad que se deben aplicar antes de implementar 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 failover y reproducir de forma segura los cambios durante las interrupciones, sin cambios en las aplicaciones de usuario final, ocultando el impacto de las interrupciones de los usuarios finales.

Esta arquitectura admite 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 las grandes distancias pueden separarlas (entre países e, incluso, continentes).
Red virtual en la nube (VCN) y subred
Una VCN es una red personalizada y definida por software que se configura en una región de Oracle Cloud Infrastructure. Al igual que las redes del centro de datos tradicionales, las VCN le proporcionan un control completo sobre su entorno de red. Una VCN puede tener varios bloques CIDR no superpuestos que puede cambiar después de crear la VCN. Puede segmentar una VCN en subredes, que 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 VCN de 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 privada dedicada entre el centro de datos y Oracle Cloud Infrastructure. FastConnect ofrece opciones de un ancho de banda superior 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 desde subredes hasta 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 de 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 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 failover y reproducir de forma segura los cambios durante las interrupciones, sin cambios en las aplicaciones de usuario final, ocultando el impacto de las interrupciones de 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 conjunto de servicios que crean, mantienen, gestionan y controlan 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 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 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 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 el dominio SOA, que utiliza 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 del principal también se utilizan como direcciones de listener de los servidores WebLogic 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, 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 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 del dominio WebLogic se debe replicar del sitio principal al secundario. Esta replicación se requiere y se realiza durante la configuración de DR inicial, 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 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 quedar fuera de sincronización. Dado que esto puede provocar una pérdida de datos en un escenario de switchover, no se recomienda detener la base de datos en espera durante el funcionamiento normal del negocio. Los hosts de nivel medio en espera se pueden parar. Sin embargo, cuando los hosts en espera se paran, los cambios de configuración que se replican desde la ubicación principal 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 sincroniza 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.
Oracle SOA Suite y componentes
Este documento se centra en el sistema Oracle SOA Suite, incluidos sus componentes. Por ejemplo, Oracle Service Bus, Oracle Business Process Management y Oracle Enterprise Scheduler Service, entre otros. Aunque los procedimientos y las recomendaciones de este documento se pueden aplicar a otros componentes de Oracle Fusion Middleware que no forman parte de Oracle SOA Suite (como Web Center y Business Intelligence), los detalles y la compatibilidad de estos se excluyen 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 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 los sistemas locales y OCI suele desalentar esta interconectividad. Para evitar problemas de conexiones y cargas de trabajo accidentales, excluya la conectividad desde 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 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 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.

Puede utilizar un nombre de front-end separado, como osb.example.com, para acceder a los servicios de Oracle Service Bus. Este documento utiliza un nombre de host de front-end para simplificar.

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 la base de datos

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

Multitenancia
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 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 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
El nivel medio local principal debe utilizar un servicio de base de datos de aplicaciones 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 la gestión de identidades

Tenga en cuenta lo siguiente al configurar Identity Management:

Protocolo ligero de acceso a directorios (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 manera ú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)

Acerca de los servicios y 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 ubicaciones 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 primario local y en espera y realice conversiones de roles.
Oracle Database: `sysdba`	Gestione 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: detener, iniciar y aplicar 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.