Go to main content

Guía de administración de Oracle® ZFS Storage Appliance, versión OS8.8.x

Salir de la Vista de impresión

Actualización: Agosto de 2021
 
 

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.

image:Imagen de una configuración de grupo de reversión a varios destinos

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.

image:Imagen de un grupo de reversión a varios destinos con una operación de reversión realizada en el origen nuevo

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

  1. 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.

    image:Imagen de configuración de un origen potencial en la BUI
  2. 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

    1. Seleccione el proyecto adecuado.

    2. Vaya al subnodo replication de ese proyecto.

    3. Utilice el comando show para visualizar las acciones como se muestra en la siguiente figura. El destino de las acciones desenlazadas es <undefined>.

    image:Imagen de visualización de acciones desenlazadas en el origen en la CLI

    Visualización de acciones desenlazadas en el origen mediante el uso de la BUI

    1. Seleccione el proyecto adecuado.

    2. Haga clic en Replicación.

    3. El destino de las acciones desenlazadas es indefinido (<None>).

    image:Imagen de visualización de acciones desenlazadas en el origen en la BUI

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.

image:Imagen de supervisión de destinos potenciales en la CLI

Los destinos potenciales se pueden supervisar como se muestra en la siguiente figura de BUI.

image:Imagen de supervisión de destinos potenciales en la 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.

image:Imagen de un grupo de reversión a varios destinos con A como 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.

image:Imagen de dos orígenes: A1 y B

Detección de conflictos en el origen y el destino

  1. 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.

    image:Imagen del conflicto detectado en los destinos
  2. 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.

    image:Imagen de un conflicto detectado cuando el origen de un grupo envía una actualización al origen de otro grupo

    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:

    image:Ejemplo de una alerta emitida en el origen que ocasionó el conflicto en la CLI

    Ejemplo de una alerta de BUI emitida en el origen que ocasionó el conflicto:

    image:Ejemplo de una alerta emitida en el origen que ocasionó el conflicto en la BUI

Pasos generales para resolver un conflicto

  1. Desactive las actualizaciones de todos los orígenes.

  2. Seleccione el origen correcto.

  3. 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.

  4. 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.

  5. 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

  1. Seleccione el paquete de replicación adecuado, vaya al proyecto y luego seleccione replication.

  2. Compruebe el valor de la propiedad conflict_detected. Cuando es true, indica que se ha detectado un conflicto.

  3. 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.

    image:Imagen de resolución de conflictos mediante el uso de la CLI (destino)

Destino: uso de la BUI para resolver conflictos

  1. Seleccione el paquete de replicación.

  2. Haga clic en Replicación.

    Debería aparecer una notificación de conflicto, como se muestra en la siguiente figura.

    image:Imagen de notificación de conflicto en la BUI (destino)
  3. 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.

    image:Imagen del cuadro de diálogo de resolución de conflicto de replicación en la BUI (destino)
  4. 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

  1. Seleccione el proyecto revertido de manera incorrecta.

  2. Vaya al subnodo replication de ese proyecto.

  3. Compruebe el valor de la propiedad conflict_detected. Cuando es true, indica que se ha detectado un conflicto.

  4. 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.

    image:Imagen de resolución de conflictos mediante el uso de la CLI (origen)

Origen: uso de la BUI para resolver conflictos

  1. En el origen incorrecto, seleccione el proyecto creado por la reversión no deseada.

  2. Haga clic en Replicación.

    Debería aparecer la notificación de conflicto, como se muestra en la siguiente figura.

    image:Imagen de notificación de conflicto en la BUI (origen)
  3. 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.

    image:Imagen del cuadro de diálogo de resolución de conflicto de replicación en la BUI (origen)
  4. 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

    Cuando configure la reversión a varios destinos, siga estas reglas 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.

    Los siguientes fallos se producen debido a la incompatibilidad. Esta lista no es exhaustiva.

  • 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.

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