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.

Comandos de toma de control manual

Colaboradores

Puede realizar la toma de control manualmente cuando necesite realizar tareas de mantenimiento en el partner y en otras situaciones similares. En función del estado del partner, el comando que utilice para realizar la toma de control varía.

Si desea…​

Se usa este comando…​

Tome el control del nodo del partner

storage failover takeover

Supervisar el progreso de la toma de control mientras los agregados del partner se mueven al nodo que realiza la toma de control

storage failover show‑takeover

Muestra el estado de conmutación por error de almacenamiento de todos los nodos del clúster

storage failover show

Tomar el control del nodo del partner sin migrar las LIF

storage failover takeover ‑skip‑lif‑migration‑before‑takeover true

Hágase cargo del nodo del partner incluso si hay un error de coincidencia del disco

storage failover takeover ‑skip‑lif‑migration‑before‑takeover true

Asuma el nodo del partner incluso si hay una discrepancia en la versión de ONTAP

Nota: Esta opción solo se utiliza durante el proceso de actualización de ONTAP no disruptivo.

storage failover takeover ‑option allow‑version‑mismatch

Asuma el control del nodo de partner sin realizar la reubicación de agregados

storage failover takeover ‑bypass‑optimization true

Toma el control del nodo de partner antes de que el partner tenga tiempo para cerrar sus recursos de almacenamiento perfectamente

storage failover takeover ‑option immediate

Nota

Antes de emitir el comando de conmutación al nodo de respaldo de almacenamiento con la opción inmediata, debe migrar las LIF de datos a otro nodo mediante el comando siguiente: network interface migrate-all -node node

Si especifica el storage failover takeover ‑option immediate Comando sin primero migrar las LIF de datos, la migración de la LIF de datos del nodo se retrasa significativamente aunque la skip‑lif‑migration‑before‑takeover opción no especificada.

De forma similar, si especifica la opción inmediato, se omite la optimización negociada de toma de control aunque la opción bypass-Optimization esté establecida en false.

Traslado del épsilon para determinadas adquisiciones iniciadas manualmente

Debería mover épsilon si espera que cualquier toma de control iniciada manualmente podría provocar que su sistema de almacenamiento falle un nodo inesperado durante una pérdida de quórum en todo el clúster.

Acerca de esta tarea

Para realizar tareas de mantenimiento planificadas, debe hacerse el control de uno de los nodos de un par de alta disponibilidad. Se debe mantener el quorum en todo el clúster para evitar interrupciones no planificadas en los datos del cliente para los nodos restantes. En algunos casos,
la toma de control puede provocar un cluster que es un fallo inesperado de nodo lejos de la pérdida de quórum en todo el cluster.

Esto puede suceder si el nodo que se está tomando está épsilon o si el nodo con épsilon no está en buen estado. Para mantener un clúster más resiliente, se puede transferir épsilon a un nodo en buen estado que no se vaya a transferir.
Normalmente, este sería el partner de alta disponibilidad.

Solo los nodos sanos y aptos participan en la votación de quórum. Para mantener el quórum en todo el clúster, se necesitan más de N/2 votos (donde N representa la suma de nodos en línea sanos y elegibles). En los clusters
con un número par de nodos online, épsilon añade una ponderación adicional para mantener quórum para el nodo al que está asignado.

Nota Aunque la formación de cluster puede modificarse mediante el cluster modify ‑eligibility false comando, debe evitar esto excepto en situaciones como restaurar la configuración del nodo o realizar un mantenimiento prolongado de los nodos. Si establece un nodo que no cumple los requisitos, deja de servir datos DE SAN hasta que el nodo se restablece a apto y se reinicia. El acceso a datos NAS al nodo también puede verse afectado cuando el nodo no cumple con los requisitos.
Pasos
  1. Compruebe el estado del clúster y confirme que un nodo en buen estado no está ocupado con épsilon:

    1. Cambie al nivel de privilegio avanzado y confirme que desea continuar cuando aparezca el símbolo del sistema del modo avanzado (*>):

      set -privilege advanced

    2. Determine qué nodo tiene épsilon:

      cluster show

      En el siguiente ejemplo, Node1 mantiene épsilon:

    Nodo

    Salud

    Condiciones

    Épsilon

    node1
    2

    verdadero
    verdadero

    verdadero
    verdadero

    verdadero
    falso

    +
    Si el nodo que desea sustituir no tiene un valor épsilon, continúe con el paso 4.

  2. Elimine el valor épsilon del nodo que desee sustituir:

    cluster modify -node Node1 -epsilon false

  3. Asigne épsilon al nodo del partner (en este ejemplo, Node2):

    cluster modify -node Node2 -epsilon true

  4. Realice la operación de toma de control:

    storage failover takeover -ofnode node_name

  5. Vuelva al nivel de privilegio de administrador:

    set -privilege admin