Implantación de rsync con una ubicación temporal central

Implantación de `rsync` con una ubicación temporal central

Esta implantación utiliza la tecnología rsync y sigue el modelo basado en una ubicación temporal central. En este modelo, hay un nodo host bastión que actúa como coordinador. Se conecta a cada host que se debe replicar y copia el contenido en una ubicación temporal común.

Las ventajas de implementar rsync con una ubicación de almacenamiento provisional central son:

Se trata de una solución de uso general aplicable a cualquier nivel medio, por lo que si tiene varios sistemas, puede utilizar el mismo enfoque en todos ellos.
No depende del tipo de almacenamiento subyacente; es válido para replicar artefactos de archivo que residen en volúmenes en bloque, en NFS, etc.
El almacenamiento puede permanecer montado en los nodos secundarios. Por lo tanto, no requiere pasos adicionales para conectar o montar el almacenamiento en el secundario en cada operación de switchover o failover.
En comparación con la implementación peer-to-peer, el mantenimiento es más sencillo, ya que hay un nodo central para ejecutar los scripts.

Las consideraciones para implantar rsync con una ubicación temporal central son:

Es responsabilidad del usuario crear los scripts personalizados para cada entorno y ejecutarlos periódicamente.
Es responsabilidad del usuario implementar una forma de revertir la dirección de la réplica.
Este modelo requiere un host y almacenamiento adicionales para la ubicación temporal central.

Al igual que el modelo peer-to-peer, los scripts rsync pueden utilizar un modelo pull o push. En el modelo "pull", el script copia los archivos del nodo remoto al nodo local. En el modelo "push", el script copia el archivo del nodo local al nodo remoto. Oracle recomienda utilizar un modelo pull para recuperar el contenido de los hosts principales, ya que descarga los nodos principales de la sobrecarga de las copias.

Configuración de la replicación para `rsync` con la ubicación temporal central

Se necesita lo siguiente para implantar rsync con una ubicación temporal central:

Un host bastión con conectividad SSH a todos los hosts (tanto principales como secundarios).
Una carpeta temporal en el host bastión, con suficiente espacio para almacenar el contenido del sistema de archivos de nivel medio que se replican.
Scripts que utilizan rsync para copiar los artefactos de archivo de nivel medio desde y en esta carpeta temporal. Los scripts rsync pueden omitir determinadas carpetas de la copia (como archivos de bloqueo, logs, archivos temporales, etc.).
Una forma de gestionar la información específica del sitio, ya sea excluyendo esa información de la copia o actualizándola con la información adecuada después de la réplica.
Programe estos scripts para que se ejecuten periódicamente.
Un mecanismo para cambiar la dirección de la réplica después de una operación de switchover o failover. Este mecanismo puede ser una comprobación dinámica que identifique el rol del sitio o un cambio manual después de un switchover o failover (por ejemplo, desactivando y activando las secuencias de comandos adecuadas).

En este documento se presentan dos ejemplos de implantación diferentes de este modelo:

Ejemplo 1: uso de los scripts de Oracle Fusion Middleware Disaster Recovery Guide
Ejemplo 2: Uso del Marco WLS-HYDR

Ejemplo 1: Uso de los scripts de Oracle Fusion Middleware Disaster Recovery Guide

Note:

Este ejemplo se aplica a cualquier sistema de nivel medio. Como referencia, utiliza los scripts proporcionados por la Oracle Fusion Middleware Disaster Recovery Guide para realizar la réplica de nivel medio para un sistema de DR de Oracle WebLogic: rsync_for_WLS.sh y rsync_copy_and_validate.sh. Sin embargo, estos scripts son generalmente aplicables y proporcionan suficiente flexibilidad para sincronizar los artefactos del sistema de archivos de nivel medio en OCI.

La Guía de Recuperación ante Desastres de Oracle Fusion Middleware proporciona scripts rsync para realizar copias remotas en un sistema de nivel medio. Estos scripts son válidos para cualquier modelo rsync. En este ejemplo concreto se muestra cómo utilizarlos para el modelo de ubicación temporal central. Esta implantación utiliza operaciones de extracción en dos pasos:

Un host bastión extrae el contenido de todos los hosts principales y los almacena en la ubicación temporal central.
A continuación, todos los nodos secundarios realizan una operación de extracción para recopilar el contenido de la ubicación temporal central.

Para configurar la replicación de nivel medio con estos scripts, consulte Replicación de los sistemas de archivos principales en el sitio secundario en la Guía de recuperación ante desastres de Oracle Fusion Middleware, la sección Enfoque de replicación de sincronización y los pasos de Uso de una ubicación temporal en particular.

Descripción de réplica-rsync-scripts.png:

Descripción de la ilustración replica-rsync-scripts.png

réplica-rsync-scripts-oracle.zip

Ejemplo 2: Uso del Marco WLS-HYDR

Note:

Este ejemplo se aplica a un sistema de Oracle WebLogic Server. Utiliza el módulo de replicación de la estructura WLS-HYDR, pero se aplica a cualquier entorno de DR de Oracle WebLogic Server, independientemente de si se creó con la estructura WLS-HYDR o no.

En este modelo, un nodo host central actúa como un coordinador total, realizando operaciones pull y push. Se conecta a cada host que se debe replicar y copia el contenido en una ubicación temporal común. Este nodo también coordina la copia de la ubicación temporal a los hosts de destino. Este enfoque descarga los nodos individuales de la sobrecarga de las copias.

La estructura WLS-HYDR utiliza este enfoque para la copia inicial durante la configuración de DR. A continuación, puede reutilizar el módulo de replicación del marco para repetir la extracción y la transferencia periódicamente. Consulte Explorar más en este manual para obtener enlaces al marco WLS-HYDR y otros recursos.

El nodo bastión realiza la réplica en dos pasos:

Operación de extracción, en la que se conecta a los hosts principales y copia el contenido del sistema de archivos en una carpeta temporal en el host bastión.
Operación de transferencia, en la que se copia el contenido de la carpeta temporal del bastión en todos los hosts secundarios.

Un nodo central realiza todas las operaciones, por lo que la programación, los registros, el mantenimiento, etc., están centralizados en ese nodo. Cuando el sistema tiene muchos nodos, esto es más eficiente en comparación con el modelo peer-to-peer o el ejemplo anterior.

Descripción de réplica-wls-hydr-framework.png:

Descripción de la ilustración réplica-wls-hydr-framework.png

réplica-wls-hydr-framework-oracle.zip

Si ha utilizado el marco WLS-HYDR para crear el sistema secundario, el host bastión ya está preparado para realizar la réplica. De lo contrario, puede configurarlo en este punto. Siga estos pasos para configurar la réplica:

Preparar el bastión.

Si ha utilizado el marco WLS-HYDR para crear el sistema secundario, el host bastión ya está preparado para realizar la réplica. Si no es así, compruebe el archivo LÉAME del repositorio GitHub de la estructura WLS-HYDR para preparar un host bastión.
Revise los archivos de configuración de WLS-HYDR.
Asegúrese de que los archivos de configuración de WLS-HYDR (replication.properties, oci.env y prem.env) contengan la información correcta para el sistema.
Ejecute el módulo de replicación WLS-HYDR.
Puede utilizar el módulo de replicación del marco para sincronizar todos los elementos (el dominio y los productos de Oracle WebLogic Server), o bien puede sincronizar estos elementos de forma independiente. En todos los casos, la sincronización completa consta de dos operaciones: una operación de extracción, para recuperar el contenido de la principal y una operación de inserción, para copiar el contenido en la secundaria.

Note:
Ejecute siempre la operación PULL antes de PUSH. De lo contrario, no introducirá la última versión del contenido.
1. Para sincronizar todo el contenido:
  - Para extraer todo el contenido de los hosts principales a la ubicación temporal del host bastión:
```
WLS-HYDR_BASE/lib/DataReplication.py pull
```
  - Para transferir todo el contenido del almacenamiento provisional del host bastión a los hosts secundarios:
```
WLS-HYDR_BASE/lib/DataReplication.py push
```
2. Para sincronizar solo artefactos de productos:
  - Para extraer los productos de los hosts principales a la ubicación temporal del host bastión:
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d products
```
  - Para transferir los productos de la ubicación temporal del host bastión a los hosts secundarios:
```
WLS-HYDR_BASE/lib/DataReplication.py push -d products
```
3. Para sincronizar la configuración (sólo el dominio WebLogic).
  - Para recuperar la configuración de los hosts principales a la ubicación temporal del host bastión, ejecute esta operación de extracción:
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config
```
  - Para copiar la configuración de la ubicación temporal del host bastión en los hosts secundarios, ejecute esta operación de transferencia:
```
WLS-HYDR_BASE/lib/DataReplication.py push -d private_config
```
4. En los casos en los que hay una carpeta de configuración compartida (dominio compartido de Oracle WebLogic en un sistema de archivos de OCI File Storage):
  - Para recuperar la configuración compartida de los hosts principales a la ubicación temporal del host bastión, ejecute esta operación de extracción:
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config
```
  - Para copiar la configuración compartida de la ubicación temporal del host bastión en los hosts secundarios, ejecute esta operación de transferencia:
```
WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config
```

Prepárese para las sustituciones de cadena de conexión de base de datos.

Las operaciones de extracción y transferencia regulares de WLS-HYDR que copian la configuración WebLogic omiten el archivo tnsnames.ora de las copias, por lo que no es necesario actualizar tnsnames.ora en cada replicación posterior.

Sin embargo, el enfoque es diferente cuando la base de datos es una instancia de Autonomous Database. Para conectarse a una base de datos autónoma, la carpeta de administración de TNS también contiene un almacén de claves y archivos del almacén de confianza, que son diferentes para las bases de datos primaria y en espera.

En la siguiente tabla se resume cómo se puede gestionar la información de conexión a la base de datos en cada caso:

Tipo de base de datos Script de sustitución y pasos de descarga Uso

Tipo de base de datos	Script de sustitución y pasos de descarga	Uso
Oracle Base Database Service u Oracle Exadata Database Service	La secuencia de comandos para gestionar `tnsnames.ora` se incluye en el módulo de replicación de estructura WLS-HYDR.	Asegúrese de que la sección JDBC del archivo `replication.properties` contiene los datos correctos. Esta operación se ejecuta en el bastion y realiza la extracción, la actualización y la transferencia del archivo `tnsnames.ora`. Para realizar la operación completa: `WLS-HYDR/lib/DataReplication.py tnsnames` No es necesario ejecutarlo a menos que realice cambios en `tnsnames.ora` (por ejemplo, agregar un alias).
Autonomous Database	`fmwadb_switch_db_conn.sh` Vaya al repositorio de Oracle MAA en GitHub `https://github.com/oracle-samples/maa` Descargue todos los scripts en el directorio `app_dr_common`. Descargue todos los scripts en el directorio `fmw-wls-with-adb-dr`. Copiar en todos los hosts de capa media. Los guiones hacen llamadas entre sí. Coloque todos los archivos de comandos de ambos directorios en la misma carpeta.	Esta secuencia de comandos debe ejecutarse en todos los hosts de capa media en espera. Debe ejecutarse antes de iniciar los servidores WebLogic en la base de datos en espera para una operación de validación, switchover o failover. Sustituye la carpeta de administración de TNS que utiliza WebLogic por la que se proporciona como entrada. También actualiza las propiedades de contraseña de cartera en los orígenes de datos. Sintaxis para ejecutar el script: `fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD` Donde WALLET_DIR es una carpeta que contiene los archivos `tnsnames.ora`, almacén de claves y almacén de confianza para conectarse a la base de datos local. Asegúrese de que la carpeta WALLET_DIR no se sustituye en la réplica.

Oracle Base Database Service u Oracle Exadata Database Service

La secuencia de comandos para gestionar tnsnames.ora se incluye en el módulo de replicación de estructura WLS-HYDR.

Asegúrese de que la sección JDBC del archivo replication.properties contiene los datos correctos.

Esta operación se ejecuta en el bastion y realiza la extracción, la actualización y la transferencia del archivo tnsnames.ora. Para realizar la operación completa: WLS-HYDR/lib/DataReplication.py tnsnames

No es necesario ejecutarlo a menos que realice cambios en tnsnames.ora (por ejemplo, agregar un alias).

Autonomous Database

fmwadb_switch_db_conn.sh

Vaya al repositorio de Oracle MAA en GitHub https://github.com/oracle-samples/maa

Descargue todos los scripts en el directorio app_dr_common.

Descargue todos los scripts en el directorio fmw-wls-with-adb-dr.

Copiar en todos los hosts de capa media. Los guiones hacen llamadas entre sí. Coloque todos los archivos de comandos de ambos directorios en la misma carpeta.

Esta secuencia de comandos debe ejecutarse en todos los hosts de capa media en espera. Debe ejecutarse antes de iniciar los servidores WebLogic en la base de datos en espera para una operación de validación, switchover o failover.

Sustituye la carpeta de administración de TNS que utiliza WebLogic por la que se proporciona como entrada. También actualiza las propiedades de contraseña de cartera en los orígenes de datos.

Sintaxis para ejecutar el script:

fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD

Donde WALLET_DIR es una carpeta que contiene los archivos tnsnames.ora, almacén de claves y almacén de confianza para conectarse a la base de datos local. Asegúrese de que la carpeta WALLET_DIR no se sustituye en la réplica.

Validación de la replicación para `rsync` con la ubicación temporal central

En una operación de switchover o failover, la información replicada debe estar disponible y utilizarse en la ubicación en espera antes de que se inicien los procesos. Esto también es necesario al validar el sistema secundario (abriendo la base de datos en espera en modo de instantánea).

En esta implementación, el almacenamiento siempre está disponible en el sitio secundario, no es necesario asociar ni montar ningún volumen. La única acción que puede necesitar es asegurarse de que contiene la última versión del contenido es la siguiente.

Ejecute una replicación.
Ejecute las secuencias de comandos para replicar la última versión del contenido.
Desactive las replicaciones programadas.
Cuando termine la última réplica, desactive todos los scripts de réplica. De lo contrario, puede interferir con el procedimiento de switchover, failover o validación. Volverá a activar las secuencias de comandos después de la operación, en la dirección adecuada.
Sustituya la información específica del centro en los hosts secundarios de nivel medio.
Si los artefactos del sistema de archivos que está replicando contienen información específica del sitio, asegúrese de que la copia no la sustituya o de que se actualice después de la réplica.

Sugerencia:
Por ejemplo, los scripts rsync de la Guía de Recuperación ante Desastres de Oracle Fusion Middleware y el módulo de replicación WLS-HYDR omiten el archivo tnsnames.ora de la copia, por lo que no necesita modificarlo después de cada replicación.
Si el sistema utiliza Oracle Autonomous Database, restaure la carpeta de cartera necesaria en la base de datos secundaria para conectarse a la base de datos de la región secundaria. Puede utilizar el script de sustitución fmwadb_switch_db_conn.sh en todos los hosts de capa media en espera. Necesita, como entradas, la ruta de acceso donde se encuentra la cartera original secundaria y la contraseña de la cartera.

A continuación, puede realizar los pasos adicionales necesarios para validar el sistema.

Replicación continua para `rsync` con ubicación temporal central

Ejecute las secuencias de comandos de replicación periódicamente para mantener el dominio secundario sincronizado con el principal.

Siga estas recomendaciones para la replicación en curso al utilizar esta implantación:

Utilice el sistema operativo crontab u otra herramienta de programación para ejecutar secuencias de comandos de replicación periódicamente. Por ejemplo, al utilizar los scripts rsync proporcionados por la guía de recuperación ante desastres, siga los pasos de la sección Scheduling Ongoing Replication With Rsync Scripts de la Guía de recuperación ante desastres de Oracle Fusion Middleware. Consulte Explorar más en este manual para obtener enlaces a estos y otros recursos. Para la frecuencia de replicación, siga las directrices que se describen en Artefactos de archivos de nivel medio anteriormente en este manual.
Mantenga los procesos de capa media detenidos en la ubicación en espera. Si los servidores están activos en la ubicación en espera mientras se replican los cambios, estos se aplicarán la próxima vez que se inicien. Inícelos solo cuando esté validando la ubicación en espera o durante los procedimientos de switchover o failover.
Mantener actualizada la información que es específica de cada sitio. Por ejemplo, si el sistema de archivos contiene una carpeta con los artefactos para conectarse a una instancia de Autonomous Database, mantenga una copia de seguridad de esta carpeta. Asegúrese de actualizar la copia de seguridad de la carpeta de cartera cuando realice una actualización en la cartera. De esta forma, se restaurará correctamente en posteriores operaciones de switchover y failovers.
Después de una operación de switchover o failover, invierta la dirección de la réplica. Esto depende de la implementación específica. Esto se puede hacer mediante una comprobación dinámica que identifica quién es el sitio activo, o con un cambio manual después de una operación de switchover o failover, desactivando y activando las secuencias de comandos adecuadas.
Sugerencia:
- Al utilizar las secuencias de comandos rsync proporcionadas por la guía de DR (ejemplo 1), asegúrese de crear las secuencias de comandos equivalentes para realizar la réplica en la otra dirección. En crontab o la herramienta programada, active solo los scripts adecuados para el rol real.
- Al utilizar WLS-HYDR (ejemplo 2), cambie el rol de la base de datos primaria en el marco WLS-HYDR, de modo que las siguientes replicaciones vayan en la otra dirección. Para ello, edite WLS-HYRDR/lib/DataReplication.py y cambie de las siguientes opciones:
```
if True:
       PRIMARY = PREM 
       STANDBY = OCI
      	 else:
	        PRIMARY = OCI
               STANDBY = PREM
```
  en la siguiente:
```
if False:
	        PRIMARY = PREM
                STANDBY = OCI
       	else:
                PRIMARY = OCI
                STANDBY = PREM
```