Implantación de la replicación de nivel medio en una arquitectura de recuperación ante desastres de OCI
Implante la replicación continua de su nivel de middleware en un sistema de recuperación ante desastres (DR) simétrico en Oracle Cloud Infrastructure (OCI), replicando los servidores de aplicaciones y sus configuraciones entre las regiones principal y secundaria, garantizando un tiempo de inactividad mínimo y una pérdida de datos durante un failover o switchover.
Este manual de soluciones proporciona una visión general de la replicación de nivel medio a lo largo del ciclo de vida del sistema. Presenta varias tecnologías de replicación y proporciona detalles para implementarlas en un escenario real. Aplica escenarios de recuperación ante desastres de nivel medio activo-pasivo en los que los sistemas principal y en espera están en OCI.
El contenido está destinado a administradores de nivel medio familiarizados con las topologías de recuperación ante desastres (DR) para middleware y con OCI. Los ejemplos y la terminología hacen referencia a Oracle WebLogic Server y a los servicios PaaS que utilizan WebLogic; sin embargo, las tecnologías y las implementaciones de replicación descritas se aplican a cualquier sistema de nivel medio.
Note:
En este documento no se describe la configuración de la recuperación ante desastres.Arquitectura
Esta arquitectura muestra una visión general de alto nivel de la topología de recuperación ante desastres activa-pasiva de middleware. Este manual asume que los sistemas primario y secundario ya están creados.
Cualquier solución de recuperación ante desastres activa-pasiva para un sistema de nivel medio debe implementar las siguientes funciones esenciales:
- Separación geográfica
Los sistemas primarios y secundarios están geográficamente separados, lo suficientemente lejos como para que no puedan verse afectados por el mismo evento de desastre.
- Simetría
Los sistemas primario y secundario son simétricos. El sistema secundario tiene el mismo número de nodos en el nivel medio y el nivel de base de datos, con una capacidad similar de CPU y memoria.
- Nombre de frontend único
Nombres de front-end únicos para el primario y el secundario. El acceso de los clientes al sistema debe ser independiente del sitio que se utilice como principal. Para lograr esto, los nombres de las direcciones front-end deben ser únicos y siempre deben asignarse a la IP del sistema que es la principal en ese momento. Este nombre se suele denominar frente virtual o URL personalizada.
- Direcciones para recepción
Las direcciones de recepción de los procesos de capa media deben ser nombres de host que se puedan resolver en ambos sistemas y que se puedan asignar a las IP de los hosts del sitio local.
- Replicación de base de datos
Los datos de la base de datos primaria se deben replicar en la base de datos en espera mediante Oracle Data Guard.
- Replicación de nivel medio
Los niveles medios principal y secundario deben estar sincronizados. Deben tener la misma configuración, la misma versión del producto y el mismo nivel de parche. Existen diferentes enfoques para lograrlo. Puede mantener los sistemas principal y secundario por separado: si se realiza un cambio en el sistema principal, el mismo cambio se repite en el sistema secundario; si se instala un parche en el sistema principal, el mismo parche se instala en el sistema en espera. Sin embargo, esto duplica el trabajo y es propenso a errores. Oracle Maximum Availability Architecture (Oracle MAA) recomienda implementar una replicación automática para copiar los artefactos del sistema de archivos de nivel medio. Esto garantiza que los sistemas principal y en espera estén siempre sincronizados.
- Gestión de la información específica de cada sitio
La configuración del secundario es una copia exacta de la principal, pero puede haber artefactos de archivo que contengan información específica de cada sitio, que debe ser diferente en la principal y la secundaria. La topología de DR debe admitir esto y permitir la personalización de la información específica del sitio.
Sugerencia:
Ejemplo de Oracle WebLogic Server
En un sistema Oracle WebLogic, la capa media primaria se conecta a la base de datos de la región primaria y la capa media secundaria se conecta a la base de datos de la región secundaria. Los sistemas de nivel medio primario y secundario tienen la misma configuración, por lo que debe haber un mecanismo para garantizar que cada sistema utilice la cadena de conexión adecuada que apunte a su base de datos local. Oracle Maximum Availability Architecture (Oracle MAA) recomienda utilizar alias TNS para los orígenes de datos, con diferentes archivos
tnsnames.oraen cada sitio. Los métodos de replicación de nivel medio deben tener esto en cuenta, ya sea omitiendo el archivo que contiene la cadena de conexión a la base de datos (tnsnames.ora) o sustituyendo la cadena de conexión a la base de datos en los archivos para que apunten a la base de datos local.
La siguiente imagen es un ejemplo de una solución de recuperación ante desastres activa-pasiva para un sistema de nivel medio.
Terminología
Debe estar familiarizado con los siguientes conceptos y terminología:
- Capa media (también de capa media o middleware)
El nivel medio hace referencia a la capa dentro de una arquitectura de aplicaciones de varios niveles que se encuentra entre la interfaz de usuario (front-end) y el almacenamiento de datos (back-end). Maneja la lógica de negocio, el procesamiento de datos y la seguridad, actuando como un puente entre el usuario y la base de datos.
- Desastre
Evento catastrófico repentino y no planificado que causa daño o pérdida inaceptable en un sitio o área geográfica. Un desastre es un evento que compromete la capacidad de una organización para proporcionar funciones, procesos o servicios críticos durante un período inaceptable y hace que la organización invoque sus planes de recuperación.
-
Recuperación ante desastres (DR)
Capacidad para salvaguardar contra interrupciones naturales o no planificadas en un sitio de producción mediante una estrategia de recuperación para aplicaciones y datos, en un sitio secundario separado geográficamente.
- Topología de recuperación ante desastres
El sitio de producción y los componentes de hardware y software del sitio secundario que componen una solución de recuperación ante desastres de Oracle Fusion Middleware.
- Arquitectura de Máxima Disponibilidad (MAA) de Oracle
Oracle Maximum Availability Architecture (Oracle MAA) es el plan de mejores prácticas para la protección de datos y la disponibilidad de productos de Oracle (base de datos, Fusion Middleware, aplicaciones). La implementación de las mejores prácticas de Oracle MAA es uno de los requisitos clave para cualquier despliegue de Oracle. Proporciona recomendaciones para configurar y gestionar un sistema Oracle. Oracle MAA incluye las recomendaciones de la Guía de despliegue empresarial de Oracle Fusion Middleware y agrega las mejores prácticas de protección ante desastres para minimizar el tiempo de inactividad planificado y no planificado de las interrupciones que afectan a un centro de datos o región completos.
- Sistema
Un sistema es un conjunto de destinos (hosts, bases de datos, servidores de aplicaciones, etc.) que funcionan conjuntamente para alojar las aplicaciones. Por ejemplo, para supervisar una aplicación en Oracle Enterprise Manager, primero debe crear un sistema, que consta de la base de datos, el listener, el servidor de aplicaciones y los destinos de hosts en los que se ejecuta la aplicación.
- Sitio
Un sitio es el juego de diferentes componentes de un centro de datos necesarios para ejecutar un grupo de aplicaciones. Por ejemplo, un sitio podría constar de instancias, bases de datos, almacenamiento, etc. de Oracle Fusion Middleware.
- Producción o sitio principal
El sitio que lleva la carga de trabajo del sistema en un momento preciso. Es un grupo de recursos de hardware, red y almacenamiento, y procesos que se utilizan activamente para llevar la lógica de negocio y procesar las solicitudes en un momento preciso.
- Ubicación secundaria (o en espera o DR)
Un sitio secundario es una ubicación de copia de seguridad que puede hacerse cargo de la lógica de negocio y solicita que se esté procesando un sitio principal. Normalmente, los sitios secundarios también se denominan "Standby" porque permanecen en "modo en espera o inactivo". Esto significa que no están procesando la carga de trabajo de producción durante las operaciones normales. Sin embargo, esto no implica que el sitio secundario no pueda ser utilizado para otros fines. Esto es especialmente cierto en modelos más modernos donde el sitio secundario se utiliza para las operaciones de informes y, lo que es más importante, para validar los cambios antes de aplicarlos en el sitio principal.
- Objetivo de punto de recuperación (RPO)
El objetivo de punto de recuperación es la cantidad de pérdida de datos que un sistema puede tolerar desde un punto de vista empresarial. Por ejemplo, la cantidad de pérdida de datos que es aceptable cuando se produce una interrupción.
- Objetivo de tiempo de recuperación (RTO)
El objetivo de tiempo de recuperación es la cantidad de tiempo de inactividad que un sistema puede tolerar o la cantidad aceptable de tiempo que una aplicación o servicio puede permanecer no disponible cuando se produce una interrupción, desde el punto de vista empresarial.
- Infraestructura de Oracle Cloud (OCI)
OCI es un conjunto de servicios complementarios en la nube que le permiten crear y ejecutar una gama de aplicaciones y servicios que se encuentran en un entorno alojado en un entorno altamente disponible. OCI proporciona capacidades informáticas de alto rendimiento (como instancias del hardware físico) y capacidad de almacenamiento en una red virtual de superposición flexible accesible de forma segura desde su red local.
- Región OCI
Una zona de OCI es un área geográfica localizada compuesta por uno o más dominio de disponibilidad. Las regiones son independientes de otras regiones y se pueden separar con grandes distancias (entre países e incluso continentes). Una región es un sitio en términos de recuperación ante desastres.
- Volúmenes en bloque de OCI
Los OCI Block Volumes proporcionan almacenamiento de bloques fiable, de alto rendimiento y de bajo costo que persiste más allá de la vida útil de una máquina virtual, con redundancia incorporada y capacidad de ampliación.
- OCI File Storage
OCI File Storage es un servicio de almacenamiento empresarial flexible y totalmente gestionado que permite a los servidores y las aplicaciones acceder a los datos a través de sistemas de archivos compartidos.
- DBFS
Un sistema de archivos de base de datos (DBFS) es una interfaz de sistema de archivos estándar en Oracle Database. DBFS es similar a NFS, ya que proporciona un sistema de archivos de red compartido que se parece a un sistema de archivos local y tiene un componente de servidor y un componente de cliente.
- Marco WLS-HYDR
El "marco WLS-HYDR" hace referencia a un marco para crear y configurar un sistema simétrico de recuperación ante desastres (DR) para entornos de Oracle WebLogic Server (WLS), específicamente dentro de Oracle Cloud Infrastructure. Este marco automatiza los procesos manuales implicados en la configuración de un entorno de DR para dominios de WLS o Fusion Middleware (FMW).
- Pila Oracle WebLogic Server for Oracle Cloud Infrastructure
La pila de Oracle WebLogic Server para OCI hace referencia a un entorno preconfigurado creado mediante Oracle Resource Manager en OCI Marketplace, que aprovisiona y gestiona despliegues de Oracle WebLogic Server en OCI. Automatiza la creación y configuración de varios recursos de OCI, como instancias informáticas, redes, equilibradores de carga, junto con un dominio WebLogic.
- Pila Oracle SOA Suite on Marketplace
La pila de Oracle SOA Suite on Marketplace es un entorno preconfigurado creado mediante Oracle Resource Manager en OCI Marketplace, para desplegar y gestionar aplicaciones de Oracle SOA Suite en OCI. Automatiza la creación y configuración de varios recursos de OCI, como instancias informáticas, redes, equilibradores de carga, junto con un dominio SOA WebLogic.
- Alias TNS
En Oracle, un alias de TNS, también conocido como nombre de servicio de red, es un identificador fácil de utilizar que simplifica las conexiones a la base de datos. Actúa como acceso directo, asignando un nombre legible por el usuario a los detalles de conexión más complejos necesarios para acceder a una instancia de base de datos Oracle específica. Estos detalles, incluidos el protocolo, el host, el puerto y el nombre de servicio, se almacenan en un archivo de configuración, normalmente denominado
tnsnames.ora. - Carpeta de administración de TNS
La carpeta Admin de Oracle TNS, especificada por la variable de entorno
TNS_ADMIN, es el directorio donde se encuentran los archivos de configuración de Oracle Net Services, comotnsnames.ora. Un sistema de nivel medio puede utilizar una carpeta de administrador de TNS contnsnames.oray otros artefactos necesarios para conectarse a la base de datos.
Acerca de los Procedimientos de Configuración de DR Activo-Pasivo de Middleware en OCI
En una topología de recuperación ante desastres activa-pasiva para el middleware, el sistema secundario es un reflejo del sistema principal. Cuando los sistemas principal y secundario están en OCI, hay diferentes formas de configurar el sistema secundario:
- Manual
Cree cada recurso individualmente a través de la consola o la CLI de OCI como reflejo del sistema principal.
- Marco WLS-HYDR
Utilice el marco WLS-HYDR para los sistemas de nivel medio basados en Oracle WebLogic. Este marco utiliza el SDK de OCI para Python para crear todos los recursos en el secundario como reflejo del sistema principal. Consulte la sección Explorar más de este manual para obtener un enlace al marco
wls-hydren GitHub. - Aprovisionamiento mediante la misma pila de Marketplace
Si el sistema principal es una pila de Marketplace, como Oracle WebLogic Server para OCI o SOA Marketplace, puede realizar el aprovisionamiento mediante la misma pila de Marketplace que se utiliza en la base de datos principal, con la base de datos en espera en modo de instantánea en espera.
Este manual de soluciones se aplica a todos estos casos siempre que cumplan con las funciones de una topología de recuperación ante desastres activa-pasiva descrita en el punto anterior. Supone que los sistemas primario y secundario ya se han creado.
Note:
En este documento no se describe la configuración de la recuperación ante desastres.