Reversión a varios destinos
En una configuración de recuperación ante desastres que consiste en la replicación de un proyecto de un origen a varios destinos, cuando se realiza una replicación a uno de los destinos, la función de reversión a varios destinos permite seguir enviando actualizaciones incrementales desde el origen nuevo a todos los demás destinos configurados originalmente.
Configuración básica
Una configuración típica de reversión a varios destinos consta de las siguientes entidades:
-
Origen: un origen de replicación responsable de enviar actualizaciones de replicación y realizar la gestión de instantáneas. Debe haber exactamente un origen.
-
Origen potencial: un origen potencial es un destino de replicación en la configuración de reversión a varios destinos que necesita hacerse cargo de enviar actualizaciones de replicación incrementales (además de otras tareas, como la gestión de instantáneas, etc.) a todos los destinos. Debe haber por lo menos un origen potencial.
-
Destino dedicado: un destino dedicado es un destino de replicación en la configuración de reversión a varios destinos que no puede realizar una operación de reversión. El destino dedicado necesita menos instantáneas que un origen potencial. Los dispositivos que ejecutan una versión de software más antigua se pueden configurar como destino dedicado en una configuración de reversión a varios destinos. Los destinos dedicados pueden estar presentes o no en una configuración de reversión a varios destinos.
-
Grupo de reversión a varios destinos: un grupo de acciones de replicación para el mismo juego de datos que permite realizar una reversión en uno de los destinos potenciales. Después de la reversión, el origen nuevo puede seguir enviando actualizaciones incrementales a todos los destinos configurados originalmente.
En la siguiente figura, este ejemplo de configuración de reversión a varios destinos consta de un origen (S), tres orígenes potenciales (PS1, PS2 y PS3) y un destino dedicado (DT1). El origen es responsable de enviar actualizaciones a los destinos. Cuando el origen se apaga, se elige uno de los orígenes potenciales (en este caso, PS1) para que sea el origen nuevo.
Cuando se realiza una reversión en este origen nuevo, este sigue enviando actualizaciones incrementales a los demás destinos, como se muestra en la siguiente figura.
Gestión de grupo de reversión a varios destinos
Los grupos de reversión a varios destinos se crean mediante la configuración de por lo menos una acción de nivel de proyecto como origen potencial. En ausencia de un origen potencial, no se crea el grupo de reversión a varios destinos, y se permite la reversión en cualquier destino, pero esta solo creará una acción de replicación para replicar de nuevo al origen original.
Notas - Mientras se esté usando la reversión a varios destinos, se podrán conservar varias instantáneas de replicación para cada acción en el grupo de reversión a varios destinos.
Creación de un grupo de reversión a varios destinos
-
Configure un origen potencial.
El origen potencial se puede configurar en una acción de replicación de nivel de proyecto, como se muestra en la siguiente figura de la BUI.
Los cambios de configuración de una acción de replicación se propagan como parte de una actualización de replicación. No existen garantías de que dichos cambios de configuración se vayan a entregar a todos los miembros del grupo de varios destinos al mismo tiempo.
-
Cree destinos de replicación en los orígenes potenciales como se describe en Creación de un destino de replicación (BUI) o Creación de un destino de replicación (CLI).
Cuando se realice una reversión en un origen potencial, se crearán acciones en todos los destinos originales. Si no hay destinos de replicación configurados en el origen potencial, las acciones recién creadas no tendrán destinos de replicación. Por lo tanto, estas acciones nuevas estarán desenlazadas. Cuando se creen los destinos de replicación correspondientes más adelante, las acciones desenlazadas se enlazarán automáticamente a los destinos correctos.
Notas - Dado que el proceso de enlace automático utiliza la dirección IP del destino, es necesario crear destinos para los mismos dispositivos y las mismas direcciones IP que se utilizaron en el origen original.Visualización de acciones desenlazadas en el origen mediante el uso de la CLI
-
Seleccione el proyecto adecuado.
-
Vaya al subnodo replication de ese proyecto.
-
Utilice el comando show para visualizar las acciones como se muestra en la siguiente figura. El destino de las acciones desenlazadas es <undefined>.
Visualización de acciones desenlazadas en el origen mediante el uso de la BUI
-
Seleccione el proyecto adecuado.
-
Haga clic en Replicación.
-
El destino de las acciones desenlazadas es indefinido (<None>).
-
Supervisión de destinos potenciales
Los paquetes de replicación de orígenes potenciales muestran una lista de destinos potenciales. Durante la reversión, se crearán acciones para los destinos potenciales además de la acción para replicar de nuevo al origen original. La lista incluye el nombre del destino o su dirección IP y el ID de paquete del destino correspondiente.
Los destinos potenciales se pueden supervisar como se muestra en la siguiente figura de CLI.
Los destinos potenciales se pueden supervisar como se muestra en la siguiente figura de BUI.
Detección y resolución de conflictos
En la siguiente figura de un grupo de reversión a varios destinos, A es el origen del grupo.
En cualquier momento, debería existir solo un origen en un grupo de reversión a varios destinos. Puede surgir un conflicto cuando exista más de un origen, como en los siguientes escenarios.
-
A causa de un error de administración cuando se realiza una reversión en dos o más orígenes potenciales que reciben actualizaciones del mismo origen de replicación.
-
En caso de que ocurra una segmentación de la red, el administrador puede optar por crear varios segmentos de reversión a varios destinos, cada uno con su propio origen. Después de recuperarse de la segmentación de la red, los orígenes de cada uno de los segmentos de reversión a varios destinos intentan enviarse actualizaciones entre sí y esto origina un conflicto.
Como se muestra en la siguiente figura, ahora hay dos orígenes: A1 y B.
Detección de conflictos en el origen y el destino
-
Como se muestra en la siguiente figura, se detecta un conflicto en los destinos cuando dos o más orígenes intentan enviar actualizaciones al mismo destino. En este escenario, las actualizaciones de un origen se llevarán a cabo sin problemas y ese origen podrá seguir enviando actualizaciones correctas al destino. Las actualizaciones de otros orígenes fallarán con una alerta específica, y el destino mostrará una notificación de conflicto que le pedirá al administrador que seleccione el origen correcto para resolver el conflicto. Una vez que el conflicto se haya resuelto, el destino recibirá la actualización del origen definido por el administrador. Sin embargo, si el origen incorrecto sigue enviando una actualización, se emitirá una alerta nueva en el origen incorrecto, y se emitirá nuevamente una notificación de resolución de conflicto en el destino.
-
Se detecta un conflicto cuando el origen (nodo B) de un grupo envía una actualización a un origen de otro grupo (nodo A1),como se muestra en la siguiente figura. La actualización del nodo que envía la actualización (nodo B) fallará con una alerta, y el origen que recibe la actualización (nodo A1) mostrará una notificación de conflicto que le pedirá al administrador que seleccione el origen correcto para resolver el conflicto. Una vez que se haya resuelto el conflicto, el origen incorrecto convertirá su proyecto a un paquete en la siguiente actualización y, por lo tanto, se convertirá en destino.
Notas - Cuando el destino recibe actualizaciones de orígenes incorrectos, la reversión de datos se puede realizar durante la primera actualización del origen correcto.Ejemplo de una alerta de CLI emitida en el origen que ocasionó el conflicto:
Ejemplo de una alerta de BUI emitida en el origen que ocasionó el conflicto:
Pasos generales para resolver un conflicto
-
Desactive las actualizaciones de todos los orígenes.
-
Seleccione el origen correcto.
-
En el destino, defina el origen correcto para resolver el conflicto. Para ello, siga el siguiente procedimiento de Destino en la CLI o la BUI.
-
En el origen incorrecto, defina el origen correcto para resolver el conflicto. Para ello, siga el siguiente procedimiento de Origen en la CLI o la BUI.
-
Active las actualizaciones del origen correcto.
Notas - 1) Las actualizaciones de otros orígenes harán que se muestren las notificaciones de conflicto correspondientes.2) La herramienta de resolución de conflictos no almacena información de forma persistente. Si el nodo se reinicia por cualquier motivo, las selecciones de conflicto y resolución serán descartadas, y las actualizaciones de los orígenes que habían ocasionado el conflicto antes del reinicio mostrarán la notificación de conflicto nuevamente.
Destino: uso de la CLI para resolver conflictos
-
Seleccione el paquete de replicación adecuado, vaya al proyecto y luego seleccione replication.
-
Compruebe el valor de la propiedad conflict_detected. Cuando es true, indica que se ha detectado un conflicto.
-
Vaya al subnodo conflict y, para resolver el conflicto, configure el valor de la propiedad source en el origen correcto, como se muestra en la siguiente figura.
Destino: uso de la BUI para resolver conflictos
-
Seleccione el paquete de replicación.
-
Haga clic en Replicación.
Debería aparecer una notificación de conflicto, como se muestra en la siguiente figura.
-
Haga clic en la notificación de conflicto para abrir el cuadro de diálogo de resolución de conflicto de replicación, como se muestra en la siguiente figura.
-
Seleccione el origen correcto y haga clic en APLICAR.
Ahora no se producirán errores al ejecutar las actualizaciones de ese origen.
Origen: uso de la CLI para resolver conflictos
-
Seleccione el proyecto revertido de manera incorrecta.
-
Vaya al subnodo replication de ese proyecto.
-
Compruebe el valor de la propiedad conflict_detected. Cuando es true, indica que se ha detectado un conflicto.
-
Vaya al subnodo conflict y, para resolver el conflicto, configure el valor de la propiedad source en el origen correcto, como se muestra en la siguiente figura.
A partir de este punto, la actualización del origen seleccionado hará que el proyecto se convierta en un paquete de replicación.
Origen: uso de la BUI para resolver conflictos
-
En el origen incorrecto, seleccione el proyecto creado por la reversión no deseada.
-
Haga clic en Replicación.
Debería aparecer la notificación de conflicto, como se muestra en la siguiente figura.
-
Haga clic en la notificación de conflicto para abrir el cuadro de diálogo de resolución de conflicto de replicación, como se muestra en la siguiente figura.
-
Seleccione el origen correcto y haga clic en APLICAR.
La primera actualización de ese origen convertirá el proyecto en un paquete de replicación y la actualización de ese origen debería completarse correctamente.
Consideraciones de compatibilidad
-
Solo los destinos que son compatibles con la reversión a varios destinos o que ejecutan una versión de firmware OS8.7.0 y posterior pueden ser miembros de un grupo de reversión a varios destinos.
-
Solo los destinos que son compatibles con la reversión a varios destinos se pueden configurar como orígenes potenciales.
-
Solo los destinos que ejecutan una versión de firmware OS8.7.0 y posterior se pueden configurar como destinos dedicados en un grupo de reversión a varios destinos.
Cuando configure la reversión a varios destinos, siga estas reglas de compatibilidad:
-
Se produce un error durante la configuración de un origen potencial en una acción de replicación a un destino que no es compatible con la reversión a varios destinos.
-
Se produce un error durante la configuración de un origen potencial en un juego de datos con acciones de replicación existentes a destinos que ejecutan una versión de firmware anterior a OS8.7.0.
-
Se produce un error durante la configuración de una acción de replicación a un destino que ejecuta una versión de firmware anterior a OS8.7.0 en un grupo de reversión a varios destinos existente.
-
Los destinos que forman parte de un grupo de reversión a varios destinos y que están configurados como destinos dedicados, pero ejecutan una versión de firmware anterior a OS8.8.6, pueden realizar una reversión de replicación. No obstante, estos no podrán ejecutar una actualización de replicación en su origen. No se pueden recuperar relaciones de replicación en ese escenario.
Los siguientes fallos se producen debido a la incompatibilidad. Esta lista no es exhaustiva.
Implicaciones de retención de instantánea automática
Cuando se utiliza la retención de instantáneas automática para algunos destinos, pero no para otros, en la configuración de una reversión a varios destinos, después de la reversión, los destinos que no especificaron un valor de retención de instantáneas automática conservan la misma cantidad de instantáneas que el origen nuevo, que puede ser distinta a la de los destinos anteriores. Para evitar esta situación, configure la política de retención para cada destino de un grupo de varios destinos como "independiente". Para obtener más información, consulte Configuración de retención de instantáneas automáticas en un destino (BUI) o Configuración de retención de instantáneas automáticas en un destino (CLI).
Temas relacionados