Skip to main content
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Recuperarse de operaciones de conmutación por error automáticas no planificadas del clúster ONTAP

Colaboradores netapp-lenida netapp-aaron-holt netapp-ahibbard netapp-dbagwell
PDF

Una operación de conmutación por error automática no planificada (AUFO) se produce cuando el clúster primario está inactivo o aislado. SnapMirror active sync detecta este tipo de fallos e inicia una conmutación por error automática no planificada al clúster secundario. El clúster secundario pasa a ser el primario (el clúster preferido) y comienza a dar servicio a los clientes. Ten en cuenta que la detección de fallos y el procesamiento de la conmutación por error solo pueden realizarse con ayuda de ONTAP Mediator.

Nota Tras una conmutación automática no planificada, es importante volver a escanear las rutas de los hosts para que no se pierda ninguna ruta de E/S.

Restablecer la relación de protección tras una conmutación al respaldo no planificada

Una vez que el clúster primario original, por ejemplo Cluster A, se recupere, SnapMirror active sync establece automáticamente la protección en sentido inverso. Si quieres restablecer el estado original, haciendo que Cluster A sea el clúster primario y preferido, puedes realizar una reversión manual iniciando una operación de conmutación por error planificada usando System Manager o la ONTAP CLI.

System Manager
Importante
Pasos
Desde ONTAP 9.8 hasta ONTAP 9.14.1, la sincronización activa de SnapMirror se denomina SnapMirror Business Continuity (SM-BC).

  1. Vaya a Protección > Relaciones y espere hasta que el estado de la relación muestre "InSync".

  2. Para realizar una recuperación tras un fallo y reanudar las operaciones en el clúster de origen, haz clic en Icono de opciones de menú y selecciona Failover.

CLI

Puede supervisar el estado de la conmutación automática al respaldo no planificada con snapmirror failover show el comando.

Por ejemplo:

ClusterB::> snapmirror failover show -instance
Start Time: 9/23/2020 22:03:29
         Source Path: vs1:/cg/scg3
    Destination Path: vs3:/cg/dcg3
     Failover Status: completed
        Error Reason:
            End Time: 9/23/2020 22:03:30
Primary Data Cluster: cluster-2
Last Progress Update: -
       Failover Type: unplanned
  Error Reason codes: -

Puedes supervisar el estado de la relación de protección inversa usando el comando snapmirror show en el clúster primario original.

Por ejemplo:

ClusterA::> snapmirror show
                                                                               Progress
Source             Destination  Mirror        Relationship   Total             Last
Path         Type  Path         State         Status         Progress  Healthy Updated
-----------  ----  ------------ -------       -------------- --------- ------- --------
vs3:/cg/dcg3 XDP   vs1:/cg/scg3 Snapmirrored  InSync          -         true    -

Puedes realizar una recuperación (failback) al clúster primario original mediante el comando snapmirror failover start.

Por ejemplo:

ClusterA::> snapmirror failover start -destination-path vs1:/cg/scg3

Consulte el "Referencia EMS" para obtener más información acerca de los mensajes de eventos y las acciones correctivas.

Reanude la protección en una configuración ramificada después de una conmutación al nodo de respaldo

A partir de ONTAP 9.15.1, la sincronización activa de SnapMirror admite la reconfiguración automática en el ramal de distribución tras un evento de conmutación por error en una relación SAN. En una configuración NAS, debes reconfigurar manualmente la relación de protección tras una conmutación por error de la sincronización activa de SnapMirror. El ramal de distribución asíncrono puede ser una relación de grupo de consistencia o una relación de volumen independiente. Para más información, consulta "configuraciones de dispersión".

Si usa ONTAP 9.14.1 o una versión anterior y experimenta una conmutación al nodo de respaldo en el clúster secundario en la relación de sincronización activa de SnapMirror, el destino asíncrono de SnapMirror cambia a estado incorrecto. Debe restaurar manualmente la protección eliminando y volviendo a crear la relación con el extremo asíncrono de SnapMirror.

Pasos

  1. Compruebe que el failover se ha completado correctamente:
    snapmirror failover show

  2. En el extremo asíncrono de SnapMirror, elimine el extremo de fan-out:
    snapmirror delete -destination-path destination_path

  3. En el tercer sitio, cree una relación asíncrona de SnapMirror entre el nuevo volumen primario de sincronización activa de SnapMirror y el volumen de destino asíncrono de distribución ramificada:
    snapmirror create -source-path source_path -destination-path destination_path -policy MirrorAllSnapshots -schedule schedule

  4. Resincronice la relación:
    snapmirror resync -destination-path destination_path

  5. Compruebe el estado y el estado de la relación:
    snapmirror show

Información relacionada