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.

Actualización manual no disruptiva de ONTAP mediante la CLI (configuraciones estándar)

Colaboradores
PDF

La actualización automatizada mediante System Manager es el método de actualización preferido. Si System Manager no admite la configuración, puede utilizar la interfaz de línea de comandos (CLI) de ONTAP para realizar una actualización manual no disruptiva. Para actualizar un clúster de dos o más nodos mediante el método manual no disruptivo, debe iniciar una operación de conmutación por error en cada nodo de un par de alta disponibilidad, actualizar el nodo «'error'», iniciar la devolución y, a continuación, repetir el proceso para cada pareja de alta disponibilidad del clúster.

Antes de empezar

Debe haber realizado una actualización satisfecha "preparación" requisitos.

Actualizar el primer nodo de una pareja de alta disponibilidad

Puede actualizar el primer nodo de un par de alta disponibilidad iniciando la toma de control por parte del partner de nodo. El partner presta servicio a los datos del nodo mientras se actualiza el primer nodo.

Si realiza una actualización principal, el primer nodo que se va a actualizar debe ser el mismo nodo en el que haya configurado las LIF de datos para conectividad externa e instalado la primera imagen de ONTAP.

Después de actualizar el primer nodo, debe actualizar el nodo del compañero con la mayor rapidez posible. No permita que los dos nodos permanezcan en un "versión mixta" estado más largo de lo necesario.

Pasos

  1. Actualice el primer nodo del clúster invocando un mensaje de AutoSupport:

    autosupport invoke -node * -type all -message "Starting_NDU"

    Esta notificación de AutoSupport incluye un registro del estado del sistema justo antes de la actualización. Guarda información útil sobre la solución de problemas en caso de que haya un problema con el proceso de actualización.

    Si el clúster no está configurado para enviar mensajes de AutoSupport, se guardará una copia de la notificación de forma local.

  2. Establezca el nivel de privilegio en avanzado, introduzca y cuando se le solicite continuar:

    set -privilege advanced

    El aviso avanzado (*>) aparece.

  3. Establezca la nueva imagen del software ONTAP como la imagen predeterminada:

    system image modify {-node nodenameA -iscurrent false} -isdefault true

    El comando system image modify utiliza una consulta ampliada para cambiar la nueva imagen de software ONTAP (que se instala como imagen alternativa) a la imagen predeterminada del nodo.

  4. Supervise el progreso de la actualización:

    system node upgrade-revert show

  5. Compruebe que la nueva imagen del software ONTAP está configurada como la imagen predeterminada:

    system image show

    En el siguiente ejemplo, image2 es la nueva versión de ONTAP y se establece como la imagen predeterminada del nodo 0:

    cluster1::*> system image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   true    X.X.X     MM/DD/YYYY TIME
         image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  true    true    X.X.X     MM/DD/YYYY TIME
         image2  false   false   Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  6. Deshabilite la devolución automática del nodo del partner si está habilitada:

    storage failover modify -node nodenameB -auto-giveback false

    Si el clúster es un clúster de dos nodos, se muestra un mensaje que le advierte que al deshabilitar la devolución automática se impide que los servicios del clúster de gestión se conecten en el evento de un fallo alternativo. Introduzca y para continuar.

  7. Compruebe que la devolución automática está deshabilitada para el partner de nodo:

    storage failover show -node nodenameB -fields auto-giveback
    cluster1::> storage failover show -node node1 -fields auto-giveback
node     auto-giveback
-------- -------------
node1    false
1 entry was displayed.

  8. Ejecute el siguiente comando dos veces para determinar si el nodo que se va a actualizar está sirviendo a cualquier cliente

    system node run -node nodenameA -command uptime

    El comando uptime muestra el número total de operaciones que el nodo ha realizado para clientes NFS, SMB, FC e iSCSI desde que se inició por última vez el nodo. Para cada protocolo, debe ejecutar el comando dos veces para determinar si el número de operaciones está aumentando. Si aumentan, el nodo actualmente sirve clientes para ese protocolo. Si no aumentan, el nodo no ofrece actualmente clientes para ese protocolo.

    Nota Debe tomar una nota de cada protocolo que ha aumentado las operaciones de cliente de manera que, después de actualizar el nodo, pueda verificar que el tráfico del cliente se haya reanudado.

    En el ejemplo siguiente se muestra un nodo con operaciones NFS, SMB, FC e iSCSI. Sin embargo, actualmente el nodo sólo ofrece clientes NFS e iSCSI.

    cluster1::> system node run -node node0 -command uptime
  2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

cluster1::> system node run -node node0 -command uptime
  2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

  9. Migre todos los LIF de datos del nodo:

    network interface migrate-all -node nodenameA

  10. Compruebe las LIF que ha migrado:

    network interface show

    Para obtener más información acerca de los parámetros que puede utilizar para comprobar el estado de LIF, consulte la página show man de la interfaz de red.

    El ejemplo siguiente muestra que las LIF de datos de nodo 0 se migraron correctamente. Para cada LIF, los campos incluidos en este ejemplo le permiten comprobar el nodo y el puerto de inicio de la LIF, el nodo y el puerto actuales al que se ha migrado la LIF y el estado operativo y administrativo de la LIF.

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node0 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
vserver lif     home-node home-port curr-node curr-port status-oper status-admin
------- ------- --------- --------- --------- --------- ----------- ------------
vs0     data001 node0     e0a       node1     e0a       up          up
vs0     data002 node0     e0b       node1     e0b       up          up
vs0     data003 node0     e0b       node1     e0b       up          up
vs0     data004 node0     e0a       node1     e0a       up          up
4 entries were displayed.

  11. Inicie una toma de control:

    storage failover takeover -ofnode nodenameA

    No especifique el parámetro -option Immediate porque se requiere una toma de control normal para el nodo que se va a realizar la operación para arrancar en la nueva imagen de software. Si no ha migrado manualmente las LIF desde el nodo, migran automáticamente al partner de alta disponibilidad del nodo para garantizar que no hay interrupciones del servicio.

    El primer nodo arranca hasta la espera del estado de devolución.

    Nota Si AutoSupport está habilitado, se envía un mensaje de AutoSupport que indica que el nodo está fuera del quórum del clúster. Puede ignorar esta notificación y continuar con la actualización.

  12. Compruebe que la toma de control se ha realizado correctamente:

    storage failover show

    Es posible que aparezcan mensajes de error que indiquen problemas de versiones no coincidentes y de formato del buzón. Se trata del comportamiento esperado y representa un estado temporal en una actualización no disruptiva importante y no es perjudicial.

    El siguiente ejemplo muestra que la toma de control se ha realizado correctamente. El nodo 0 tiene el estado esperando devolución y su partner está en el estado de toma de control.

    cluster1::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node0          node1          -        Waiting for giveback (HA mailboxes)
node1          node0          false    In takeover
2 entries were displayed.

  13. Espere al menos ocho minutos para que surtan efecto las siguientes condiciones:

    • La multivía del cliente (si está implementada) se estabiliza.

    • Los clientes se recuperan de la pausa en una operación de I/o que se produce durante la toma de control.

      El tiempo de recuperación es específico del cliente y puede tardar más de ocho minutos, en función de las características de las aplicaciones cliente.

  14. Devuelva los agregados al primer nodo:

    storage failover giveback –ofnode nodenameA

    La devolución devuelve primero el agregado raíz al nodo del partner y, después de que ese nodo haya terminado de arrancarse, devuelve los agregados que no son raíz y los LIF que se hayan establecido en revertir automáticamente. El nodo que se acaba de arrancar empieza a suministrar datos a los clientes desde cada agregado en cuanto se devuelva dicho agregado.

  15. Compruebe que se han devuelto todos los agregados:

    storage failover show-giveback

    Si el campo Estado de devolución indica que no hay agregados que devolver, se devolverán todos los agregados. Si se vetó la devolución, el comando muestra el progreso de devolución y qué subsistema vetó la devolución.

  16. Si no se ha devuelto ningún agregado, realice los siguientes pasos:

    1. Revise la solución de veto para determinar si desea abordar la condición "vertical" o anular el veto.

    2. Si es necesario, tratar la condición "verto" descrita en el mensaje de error, asegurándose de que las operaciones identificadas se cancelen con gracia.

    3. Vuelva a ejecutar el comando de recuperación tras fallos del almacenamiento.

      Si ha decidido anular la condición "VETE", establezca el parámetro -override-vetoes en TRUE.

  17. Espere al menos ocho minutos para que surtan efecto las siguientes condiciones:

    • La multivía del cliente (si está implementada) se estabiliza.

    • Los clientes se recuperan de la pausa en una operación de I/o que se produce durante la devolución.

      El tiempo de recuperación es específico del cliente y puede tardar más de ocho minutos, en función de las características de las aplicaciones cliente.

  18. Compruebe que la actualización se ha realizado correctamente para el nodo:

    1. Vaya al nivel de privilegio avanzado :

      set -privilege advanced

    2. Compruebe que el estado de la actualización se haya completado para el nodo:

      system node upgrade-revert show -node nodenameA

      El estado debe aparecer como completo.

    Si el estado no se completa, póngase en contacto con el soporte técnico.

    1. Vuelva al nivel de privilegio de administrador:

      set -privilege admin

  19. Compruebe que los puertos del nodo estén activos:

    network port show -node nodenameA

    Debe ejecutar este comando en un nodo que se haya actualizado a la versión superior de ONTAP 9.

    En el ejemplo siguiente se muestra que todos los puertos del nodo están en funcionamiento:

    cluster1::> network port show -node node0
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
node0
       e0M       Default      -                up       1500  auto/100
       e0a       Default      -                up       1500  auto/1000
       e0b       Default      -                up       1500  auto/1000
       e1a       Cluster      Cluster          up       9000  auto/10000
       e1b       Cluster      Cluster          up       9000  auto/10000
5 entries were displayed.

  20. Revierte los LIF al nodo:

    network interface revert *

    Este comando muestra las LIF que se han migrado del nodo.

    cluster1::> network interface revert *
8 entries were acted on.

  21. Compruebe que los LIF de datos del nodo se hayan revertido correctamente al nodo y que estén en funcionamiento:

    network interface show

    En el ejemplo siguiente se muestra que todos los LIF de datos alojados en el nodo se han revertido correctamente al nodo y que su estado operativo está en funcionamiento:

    cluster1::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data001      up/up    192.0.2.120/24     node0         e0a     true
            data002      up/up    192.0.2.121/24     node0         e0b     true
            data003      up/up    192.0.2.122/24     node0         e0b     true
            data004      up/up    192.0.2.123/24     node0         e0a     true
4 entries were displayed.

  22. Si anteriormente ha determinado que este nodo sirve a clientes, compruebe que el nodo está proporcionando servicio para cada protocolo que estaba sirviendo anteriormente:

    system node run -node nodenameA -command uptime

    La operación se restablece a cero durante la actualización.

    En el ejemplo siguiente se muestra que el nodo actualizado ha reanudado el servicio a sus clientes NFS e iSCSI:

    cluster1::> system node run -node node0 -command uptime
  3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops

  23. Vuelva a habilitar la devolución automática en el nodo del partner si estaba previamente deshabilitada:

    storage failover modify -node nodenameB -auto-giveback true

Debe continuar para actualizar el partner de alta disponibilidad del nodo lo más rápido posible. Si debe suspender el proceso de actualización por cualquier motivo, ambos nodos de la pareja de alta disponibilidad deben ejecutar la misma versión de ONTAP.

Actualizar el nodo del partner en una pareja de alta disponibilidad

Después de actualizar el primer nodo de un par de alta disponibilidad, actualiza su compañero iniciando la toma de control sobre él. El primer nodo sirve los datos del partner mientras se actualiza el nodo del partner.

  1. Establezca el nivel de privilegio en avanzado, introduzca y cuando se le solicite continuar:

    set -privilege advanced

    El aviso avanzado (*>) aparece.

  2. Establezca la nueva imagen del software ONTAP como la imagen predeterminada:

    system image modify {-node nodenameB -iscurrent false} -isdefault true

    El comando system image modify utiliza una consulta ampliada para cambiar la nueva imagen de software ONTAP (que se instala como imagen alternativa) que es la imagen predeterminada del nodo.

  3. Supervise el progreso de la actualización:

    system node upgrade-revert show

  4. Compruebe que la nueva imagen del software ONTAP está configurada como la imagen predeterminada:

    system image show

    En el siguiente ejemplo: image2 Es la nueva versión de ONTAP y se establece como imagen predeterminada en el nodo:

    cluster1::*> system image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  false   true    X.X.X     MM/DD/YYYY TIME
         image2  true    false   Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  5. Deshabilite la devolución automática del nodo del partner si está habilitada:

    storage failover modify -node nodenameA -auto-giveback false

    Si el clúster es un clúster de dos nodos, se muestra un mensaje que le advierte que al deshabilitar la devolución automática se impide que los servicios del clúster de gestión se conecten en el evento de un fallo alternativo. Introduzca y para continuar.

  6. Compruebe que la devolución automática está deshabilitada para el nodo asociado:

    storage failover show -node nodenameA -fields auto-giveback
    cluster1::> storage failover show -node node0 -fields auto-giveback
node     auto-giveback
-------- -------------
node0    false
1 entry was displayed.

  7. Ejecute el siguiente comando dos veces para determinar si el nodo que se va a actualizar está sirviendo a cualquier cliente:

    system node run -node nodenameB -command uptime

    El comando uptime muestra el número total de operaciones que el nodo ha realizado para clientes NFS, SMB, FC e iSCSI desde que se inició por última vez el nodo. Para cada protocolo, debe ejecutar el comando dos veces para determinar si el número de operaciones está aumentando. Si aumentan, el nodo actualmente sirve clientes para ese protocolo. Si no aumentan, el nodo no ofrece actualmente clientes para ese protocolo.

    NOTA: Debe tomar nota de cada protocolo que tiene cada vez más operaciones de cliente para que después de actualizar el nodo, pueda verificar que el tráfico de cliente se ha reanudado.

    En el ejemplo siguiente se muestra un nodo con operaciones NFS, SMB, FC e iSCSI. Sin embargo, actualmente el nodo sólo ofrece clientes NFS e iSCSI.

    cluster1::> system node run -node node1 -command uptime
  2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

cluster1::> system node run -node node1 -command uptime
  2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

  8. Migre todos los LIF de datos del nodo:

    network interface migrate-all -node nodenameB

  9. Compruebe el estado de cualquier LIF que haya migrado:

    network interface show

    Para obtener más información acerca de los parámetros que puede utilizar para comprobar el estado de LIF, consulte la página show man de la interfaz de red.

    El ejemplo siguiente muestra que las LIF de datos del nodo 1 se migraron correctamente. Para cada LIF, los campos incluidos en este ejemplo le permiten comprobar el nodo y el puerto de inicio de la LIF, el nodo y el puerto actuales al que se ha migrado la LIF y el estado operativo y administrativo de la LIF.

    cluster1::> network interface show -data-protocol nfs|cifs -role data -home-node node1 -fields home-node,curr-node,curr-port,home-port,status-admin,status-oper
vserver lif     home-node home-port curr-node curr-port status-oper status-admin
------- ------- --------- --------- --------- --------- ----------- ------------
vs0     data001 node1     e0a       node0     e0a       up          up
vs0     data002 node1     e0b       node0     e0b       up          up
vs0     data003 node1     e0b       node0     e0b       up          up
vs0     data004 node1     e0a       node0     e0a       up          up
4 entries were displayed.

  10. Inicie una toma de control:

    storage failover takeover -ofnode nodenameB -option allow-version-mismatch

    No especifique el parámetro -option Immediate porque se requiere una toma de control normal para el nodo que se va a realizar la operación para arrancar en la nueva imagen de software. Si no ha migrado manualmente las LIF desde el nodo, migran automáticamente al partner de alta disponibilidad del nodo para que no haya interrupciones del servicio.

    Aparece una advertencia. Debe entrar y para continuar.

    El nodo que se ha tomado arranca hasta esperando el estado de devolución.

    Nota Si AutoSupport está habilitado, se envía un mensaje de AutoSupport que indica que el nodo está fuera del quórum del clúster. Puede ignorar esta notificación y continuar con la actualización.

  11. Compruebe que la toma de control se ha realizado correctamente:

    storage failover show

    El siguiente ejemplo muestra que la toma de control se ha realizado correctamente. El nodo 1 está en estado esperando devolución del nodo y su compañero está en estado de toma de control.

    cluster1::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node0          node1          -        In takeover
node1          node0          false    Waiting for giveback (HA mailboxes)
2 entries were displayed.

  12. Espere al menos ocho minutos para que surtan efecto las siguientes condiciones:

    + La multivía del cliente (si está implementada) se estabiliza. Los clientes se recuperan de la pausa en la I/o que se produce durante la toma de control.

    + El tiempo de recuperación es específico del cliente y puede tardar más de ocho minutos, según las características de las aplicaciones cliente.

  13. Devolver los agregados al nodo partner:

    storage failover giveback -ofnode nodenameB

    La operación de devolución devuelve en primer lugar el agregado raíz al nodo del partner y, después de que ese nodo haya finalizado el arranque, devuelve los agregados que no son raíz y los LIF que se hayan configurado para que se revierten automáticamente. El nodo que se acaba de arrancar empieza a suministrar datos a los clientes desde cada agregado en cuanto se devuelva dicho agregado.

  14. Compruebe que se devuelven todos los agregados:

    storage failover show-giveback

    Si el campo Giveback Status indica que no hay agregados que devolver, se devuelven todos los agregados. Si se vetó la devolución, el comando muestra el progreso de devolución y qué subsistema vetó la operación de devolución.

  15. Si no se devuelve ningún agregado, realice los siguientes pasos:

    1. Revise la solución de veto para determinar si desea abordar la condición "vertical" o anular el veto.

    2. Si es necesario, tratar la condición "verto" descrita en el mensaje de error, asegurándose de que las operaciones identificadas se cancelen con gracia.

    3. Vuelva a ejecutar el comando de recuperación tras fallos del almacenamiento.

      Si ha decidido anular la condición "VETE", establezca el parámetro -override-vetoes en TRUE.

  16. Espere al menos ocho minutos para que surtan efecto las siguientes condiciones:

    • La multivía del cliente (si está implementada) se estabiliza.

    • Los clientes se recuperan de la pausa en una operación de I/o que se produce durante la devolución.

      El tiempo de recuperación es específico del cliente y puede tardar más de ocho minutos, en función de las características de las aplicaciones cliente.

  17. Compruebe que la actualización se ha realizado correctamente para el nodo:

    1. Vaya al nivel de privilegio avanzado :

      set -privilege advanced

    2. Compruebe que el estado de la actualización se haya completado para el nodo:

      system node upgrade-revert show -node nodenameB

      El estado debe aparecer como completo.

    Si el estado no es completo, desde el nodo, ejecute el comando system node upgrade-revert upgrade. Si el comando no completa la actualización, póngase en contacto con el soporte técnico.

    1. Vuelva al nivel de privilegio de administrador:

      set -privilege admin

  18. Compruebe que los puertos del nodo estén activos:

    network port show -node nodenameB

    Este comando debe ejecutarse en un nodo que se ha actualizado a ONTAP 9.4.

    En el ejemplo siguiente se muestra que todos los puertos de datos del nodo están en funcionamiento:

    cluster1::> network port show -node node1
                                                             Speed (Mbps)
Node   Port      IPspace      Broadcast Domain Link   MTU    Admin/Oper
------ --------- ------------ ---------------- ----- ------- ------------
node1
       e0M       Default      -                up       1500  auto/100
       e0a       Default      -                up       1500  auto/1000
       e0b       Default      -                up       1500  auto/1000
       e1a       Cluster      Cluster          up       9000  auto/10000
       e1b       Cluster      Cluster          up       9000  auto/10000
5 entries were displayed.

  19. Revierte los LIF al nodo:

    network interface revert *

    Este comando muestra las LIF que se han migrado del nodo.

    cluster1::> network interface revert *
8 entries were acted on.

  20. Compruebe que los LIF de datos del nodo se hayan revertido correctamente al nodo y que estén en funcionamiento:

    network interface show

    En el ejemplo siguiente se muestra que todos los LIF de datos alojados en el nodo se vuelven a restaurar correctamente al nodo y que su estado operativo es up:

    cluster1::> network interface show
            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data001      up/up    192.0.2.120/24     node1         e0a     true
            data002      up/up    192.0.2.121/24     node1         e0b     true
            data003      up/up    192.0.2.122/24     node1         e0b     true
            data004      up/up    192.0.2.123/24     node1         e0a     true
4 entries were displayed.

  21. Si anteriormente ha determinado que este nodo sirve a clientes, compruebe que el nodo está proporcionando servicio para cada protocolo que estaba sirviendo anteriormente:

    system node run -node nodenameB -command uptime

    La operación se restablece a cero durante la actualización.

    En el ejemplo siguiente se muestra que el nodo actualizado ha reanudado el servicio a sus clientes NFS e iSCSI:

    cluster1::> system node run -node node1 -command uptime
  3:15pm up  0 days, 0:16 129 NFS ops, 0 CIFS ops, 0 HTTP ops, 0 FCP ops, 2 iSCSI ops

  22. Si este fue el último nodo del clúster que se actualizó, active una notificación de AutoSupport:

    autosupport invoke -node * -type all -message "Finishing_NDU"

    Esta notificación de AutoSupport incluye un registro del estado del sistema justo antes de la actualización. Guarda información útil sobre la solución de problemas en caso de que haya un problema con el proceso de actualización.

    Si el clúster no está configurado para enviar mensajes de AutoSupport, se guardará una copia de la notificación de forma local.

  23. Confirme que el nuevo software ONTAP se está ejecutando en ambos nodos de la pareja de alta disponibilidad:

    set -privilege advanced
    system node image show

    En el siguiente ejemplo, image2 es la versión actualizada de ONTAP y es la versión predeterminada en ambos nodos:

    cluster1::*> system node image show
                 Is      Is                Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- --------- -------------------
node0
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
node1
         image1  false   false   X.X.X     MM/DD/YYYY TIME
         image2  true    true    Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

  24. Vuelva a habilitar la devolución automática en el nodo del partner si estaba previamente deshabilitada:

    storage failover modify -node nodenameA -auto-giveback true

  25. Compruebe que el cluster está en quórum y que los servicios se están ejecutando mediante cluster show y.. cluster ring show comandos (nivel de privilegio avanzado).

    Debe realizar este paso antes de actualizar cualquier par de alta disponibilidad adicional.

  26. Vuelva al nivel de privilegio de administrador:

    set -privilege admin

  27. Actualice cualquier par de alta disponibilidad adicional.