Implantación de la replicación rsync entre iguales

Esta implantación utiliza la tecnología rsync y sigue el modelo de peer a peer. En este modelo, la copia se realiza directamente entre los hosts pares de capa media. Cada nodo tiene conectividad SSH con su par y utiliza comandos rsync a través de SSH para replicar los artefactos de archivo de nivel medio principales.

Las ventajas de implementar la replicación peer-to-peer rsync son las siguientes:

• 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.
• No necesita hardware adicional, como un host central o almacenamiento.
• 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.

Las consideraciones para implementar rsync peer-to-peer son las siguientes:

• 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.
• Requiere mantenimiento en muchos nodos, ya que los scripts no están centralizados, por lo que la solución es más compleja en grandes clusters.

Los scripts rsync de igual a igual 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 los archivos del nodo local en el nodo remoto. Cuando los scripts rsync se ejecutan en los nodos con el rol en espera, ejecutan una operación de "extracción" para recuperar el contenido de la base de datos primaria. Cuando los scripts rsync se ejecutan en los nodos con el rol principal, ejecutan una operación de transferencia para copiar el contenido en los nodos secundarios. Oracle recomienda el modelo pull para peer a peer. De esta forma, los scripts rsync utilizan menos recursos de los hosts del sistema principal, ya que todas las operaciones de la copia (por ejemplo, la comparación checksum de la copia) se ejecutan en los nodos secundarios.

Configuración de la replicación para rsync peer a peer

Se necesita lo siguiente para implementar el modelo peer-to-peer rsync:

• Permitir la conectividad SSH entre los hosts y sus hosts pares.
• Cree scripts que utilicen rsync para copiar los artefactos de archivo de nivel medio de hosts principales a secundarios. Los scripts rsync pueden omitir determinadas carpetas de la copia (como archivos de bloqueo, logs, archivos temporales, etc.)
• Implantar 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).

Ejemplo 1: Uso de los scripts rsync de Oracle Fusion Middleware Disaster Recovery Guide para la replicación peer a peer

Note:

Este ejemplo se aplica a cualquier sistema de nivel medio. Utiliza los scripts proporcionados por Oracle Fusion Middleware Disaster Recovery Guide para realizar la réplica de nivel medio para un sistema de DR WebLogic: rsync_for_WLS.sh y rsync_copy_and_validate.sh. Sin embargo, estos scripts son generalmente aplicables y proporcionan suficiente flexibilidad para sincronizar cualquier artefacto de archivo de nivel medio en OCI. Consulte Explorar más para obtener enlaces a estos y otros recursos.

En este ejemplo, cada host del sitio secundario establece una conexión con su nodo principal par y realiza una extracción del contenido. 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 peer a peer en particular.

Descripción de la ilustración dr-scripts-peer-peer.png

dr-scripts-peer-peer-oracle.zip

Validar replicación para rsync peer a peer

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 implantación, el almacenamiento siempre está disponible en la base de datos en espera; no es necesario asociar ni montar ningún volumen. La única acción que necesita es asegurarse de que contiene la última versión del contenido.

1. Ejecute una replicación.
   Ejecute las secuencias de comandos para replicar la última versión del contenido.
2. 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.
3. 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, las secuencias de comandos rsync omiten el archivo tnsnames.ora de la copia, por lo que no es necesario 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 en la que se encuentra la cartera original secundaria y la contraseña de la cartera.

Replicación en curso para rsync de igual a igual

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

Siga estas recomendaciones al utilizar rsync desde los hosts de nivel medio:

• 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 de Oracle Fusion Middleware, siga los pasos descritos en la sección Programación de replicación continua con scripts de sincronización. 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 al principio de 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.
• Mantenga actualizada la información 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. Por ejemplo, con los scripts rsync proporcionados por Oracle Fusion Middleware Disaster Recovery Guide, asegúrese de crear los scripts 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.