Reversión de la dirección de la replicación

Se puede invertir la dirección de la replicación para admitir los planes típicos de recuperación ante desastres de dos sistemas. Esta operación es similar a la operación de corte descrita anteriormente, pero, además, configura una acción de replicación en el nuevo proyecto local para realizar una replicación incremental en el sistema de origen. No se efectúan cambios en el sistema de origen cuando se completa esta operación, sino que el primer intento de actualización con esta acción convertirá el proyecto original del sistema de origen en un paquete de replicación y revertirá los cambios efectuados desde la última actualización de replicación exitosa de ese sistema.

Esta función no redirige automáticamente cargas de trabajo de producción ni direcciones IP de failover, ni realiza otras actividades relacionadas con el failover de la recuperación ante desastres, aparte de modificar el estado de lectura y escritura de las copias de datos principales y secundarios.

Como parte de la conversión del proyecto de origen original en un paquete de replicación en el sistema de origen original (que ahora funciona como destino), los recursos compartidos que se replicaron como parte de la acción o el paquete que actualmente se está revirtiendo se trasladan a un nuevo paquete de replicación y no se exportan. El proyecto original permanece en la recopilación local, pero podría terminar vacío si la acción o el paquete incluyeran todos los recursos compartidos. Cuando se revierte la replicación de nivel de recurso compartido, todos los demás recursos compartidos del proyecto original no se modifican.

Después de establecer la replicación de nivel de recurso compartido de un dispositivo a otro, la reversión de esa replicación en el dispositivo de destino destruye el cronograma de replicación. Luego, se crea una acción de replicación en el nivel de proyecto, que contiene el dispositivo de destino correcto sin un cronograma.

Como mencionamos anteriormente, esta característica generalmente se utiliza para implementar una configuración de recuperación ante desastres de dos sistemas, en la cual un sistema principal proporciona datos de producción y los replica a un sistema secundario o DR (por lo general, en otro centro de datos) en espera para tomar el control del tráfico de producción en caso de que se produzca un desastre en el sitio principal. Si se produce un desastre en el sitio principal, la copia del sitio secundario se debe convertir en "principal" y, para ello, se debe convertir en modificable y el tráfico de producción se debe redirigir al sitio secundario. Cuando se repara el sitio principal, los cambios acumulados en el sitio secundario se pueden replicar nuevamente en el sitio principal y ese sitio puede reanudar el mantenimiento de la carga de trabajo de producción.

A continuación, se describe una secuencia típica de eventos con ese plan:

• El sistema principal abastece la carga de trabajo de producción y se ocupa de la replicación al sistema secundario.

• Se produce un desastre, que posiblemente representa una falla total del sistema en el sitio principal. Los administradores revierten la dirección de la replicación en el sitio secundario; para ello, exportan los recursos compartidos replicados de un nuevo proyecto configurado para realizar la replicación nuevamente en el sitio principal cuando se restaure dicho servicio principal. Mientras tanto, la carga de trabajo de producción se redirige al sitio secundario.

• Cuando el sitio principal vuelve a estar en línea, el administrador inicia una actualización de replicación desde el sitio secundario hacia el sitio principal. Esto permite convertir la copia del sitio principal en un paquete de replicación, lo cual revierte los cambios realizados desde la última actualización exitosa del destino (antes de la falla). Cuando la copia del sitio principal está actualizada, la dirección de la replicación se revierte nuevamente, lo que convierte la copia del sitio principal en modificable. El tráfico de producción se redirige nuevamente al sitio principal. Se reanuda la replicación del sitio principal al secundario, lo cual restaura la relación inicial entre las copias principal y secundaria.

Para revertir la dirección de la replicación de un paquete, se recomienda a los administradores que, antes de hacerlo, detengan la replicación de ese proyecto desde el origen. Si hay una actualización de replicación en curso cuando el administrador revierte la dirección de la replicación de un proyecto, los administradores no podrán saber qué instantánea de replicación coherente se utilizó para crear el proyecto resultante en el dispositivo de destino anterior (que ahora es el dispositivo de origen).

Para revertir la replicación desde la BUI, se debe navegar hasta el paquete de replicación (ver más arriba) y, a continuación, hacer clic en la ficha Replication (Replicación) y en el botón . El cuadro de diálogo que aparece permite que el administrador especifique el nombre del nuevo proyecto local.

Para revertir la replicación desde la CLI, se debe navegar hasta el paquete de replicación (ver más arriba) y, a continuación, utilizar el comando reverse. Este comando toma un argumento opcional que especifica el nombre del nuevo proyecto local. Si no se especifica ningún argumento, se utiliza el nombre original.

Dado que se exportan todos los recursos compartidos locales, todos los recursos compartidos del paquete se exportan cuando se revierte el paquete, independientemente de que se hayan exportado previamente (ver más arriba). Si existen conflictos de punto de montaje entre los sistemas de archivos replicados y otros sistemas de archivos del sistema, se producirá un error en la operación de reversión. Estos conflictos se deben resolver antes de realizar el corte mediante la reconfiguración de los puntos de montaje de los recursos compartidos correspondientes. Dado que esta operación, generalmente, forma parte de la ruta crítica de restauración del servicio de producción, se recomienda resolver estos conflictos de punto de montaje cuando los sistemas se configuran por primera vez, en lugar de hacerlo en el momento en que se produce el failover de la recuperación ante desastres.