DataDomain: Guía de actualización del SO para sistemas de alta disponibilidad (HA)

摘要: Descripción general del proceso para las actualizaciones de Data Domain Operating System (DDOS) en dispositivos de “alta disponibilidad” de Data Domain (DDHA).

本文适用于 本文不适用于 本文并非针对某种特定的产品。 本文并非包含所有产品版本。
查看其他资源

说明

Mantenimiento planificado del sistema de HA

A fin de reducir el tiempo de inactividad por el mantenimiento planificado, la actualización gradual del sistema se incluye en la arquitectura de HA. Una actualización gradual puede actualizar primero el nodo en espera y, luego, usar una conmutación por error de HA esperada para transferir los servicios del nodo activo al nodo en espera. Por último, los nodos activos anteriores se actualizarán y se reincorporarán al clúster de HA como nodos en espera. Todos los procesos se realizan con un solo comando.
Un enfoque de actualización manual alternativo es la “actualización local”. Actualice primero el nodo en espera de forma manual y, luego, actualice manualmente el nodo activo.  Por último, el nodo en espera se reincorporará al clúster de HA. La actualización local se puede realizar para una actualización regular o corregir problemas.
Es posible que la conversión de datos de todas las operaciones de actualización del sistema en el nodo activo no se inicie hasta que ambos sistemas se actualicen al mismo nivel y el estado de HA se restaure por completo.


DDOS 5.7 en adelante soporta dos tipos de métodos de actualización de sistemas de HA:

  • Actualización gradual: actualización automática de ambos nodos de HA con un solo comando. El servicio se transfiere al otro nodo después de la actualización.

  • Actualización local: actualización manual de los nodos de HA, uno por uno. El servicio se mantiene en el mismo nodo después de la actualización.

 

Actualización gradual a través de la GUI:

Prepare el sistema para la actualización:

  1. Asegúrese de que el estado del sistema de HA sea “altamente disponible”.

 Login GUI  à Home à Dashboard

Página del panel
  1. El archivo RPM de DDOS se debe colocar en el nodo activo y la actualización debe comenzar desde este nodo.
- Cómo encontrar un nodo activo:
  Login GUI  à Home à Dashboard

Página del panel               
 
  1. Cargar el archivo RPM en el nodo activo
Login GUI  à Maintenance à System à Haga clic en el botón UPLOAD UPGRADE PACKAGE

Página de mantenimiento 
Después de la carga, aparecerá el archivo RPM. 
  1. Ejecute la comprobación previa en el nodo activo. La actualización se debe anular si se produce algún error.
Login GUI  à Maintenance à System à Haga clic en el archivo RPM de actualización à Haga clic en UPGRADE PRECHECK

Página del sistema 
 

         Desactive también la GC, la transferencia de datos y la replicación antes de iniciar la actualización (paso 6) para que estos trabajos no provoquen un tiempo de apagado de DDFS más prolongado durante la actualización. Un tiempo de apagado de DDFS más corto ayudará a minimizar el impacto para los clientes. Estas cargas de trabajo no afectan las operaciones de respaldo/restauración del cliente.

         En función de las necesidades, estos servicios se pueden reanudar una vez finalizada la actualización mediante los comandos de habilitación correspondientes. Consulte la guía de administración para obtener más detalles.

         Hay algunos otros comandos y comprobaciones manuales que se describen en la guía de administración que no son estrictamente necesarios para un sistema de HA. Actualmente, se sugiere realizar un reinicio previo como prueba para los sistemas de nodo único. No es necesario para los sistemas de HA porque el paso 5 “conmutación por error de alta disponibilidad” a continuación ya incluye un reinicio automático durante el proceso de conmutación por error.

  1. Opcional. Antes de ejecutar una actualización gradual, se recomienda realizar la conmutación por error de HA dos veces de forma manual en el nodo activo. El fin es probar la funcionalidad de conmutación por error. La operación hará que el nodo activo se reinicie; tenga en cuenta esto.

   
              En primer lugar, prepárese para la conmutación por error mediante el apagado de la GC, la transferencia de datos y la replicación. Consulte la guía de administración para saber cómo hacerlo a través de la GUI. Estos servicios no afectan las cargas de trabajo de respaldo/restauración del cliente. Luego, continúe con “conmutación por error de HA”.
 

Login GUI  à Health à High Availability à Haga clic en Failover to XXX


(Cuando el estado del sistema de HA vuelva a ser “altamente disponible”, ejecute la segunda “conmutación por error de HA” y espere a que ambos nodos estén en línea)
 

Después de la conmutación por error de HA, los servicios detenidos se pueden reanudar mediante los comandos de habilitación correspondientes. Consulte la guía de administración para obtener más detalles.

Las pruebas de conmutación por error anteriores son opcionales y no es necesario realizarlas justo antes de una actualización. Las pruebas de conmutación por error se pueden realizar antes de la actualización, por ejemplo, con dos semanas de anticipación, de modo que se pueda utilizar una ventana de mantenimiento más pequeña para la actualización posterior. El tiempo de inactividad del servicio DDFS para cada conmutación por error es de alrededor de 10 minutos (menos o más según las versiones de DDOS y algunos otros factores). Las versiones 7.4 y posteriores de DDOS tendrán menos tiempo de inactividad versión tras versión debido a las mejoras continuas del software de DDOS.
 

      Procedimiento de actualización paso a paso
  1. Si la comprobación previa finalizó sin problemas, continúe con la actualización gradual en el nodo activo.
Login GUI  à Maintenance à System à Haga clic en el archivo RPM de actualización à Haga clic en PERFORM SYSTEM UPGRADE
 
Página del sistema
  1. Espere que la actualización gradual finalice. Antes de que esto ocurra, no active ninguna operación de conmutación por error de HA.

Disponibilidad de DDFS durante el comando anterior:

  1. Primero actualizará el nodo en espera y lo reiniciará con la nueva versión. Tarda aproximadamente entre 20 y 30 minutos, dependiendo de varios factores. El servicio DDFS está activo y funciona en el nodo activo durante este período sin ninguna degradación del rendimiento.

  2. Después de aplicar el nuevo DDOS, el sistema realizará una conmutación por error del servicio DDFS al nodo en espera actualizado. Tarda aproximadamente 10 minutos (menos o más dependiendo de varios factores).

    1. Un factor importante es la actualización del FW del DAE. Puede introducir alrededor de 20 minutos más de tiempo de inactividad, según la cantidad de DAE que estén configurados. Consulte el artículo de la base de conocimientos “Data Domain: La actualización gradual de HA puede fallar para el firmware del gabinete externo actualizado”, con el fin de determinar si se requiere una actualización del FW del DAE. Tenga en cuenta que, a partir de DDOS 7.5, hay una mejora para habilitar la actualización en línea del FW del DAE, lo que elimina esta preocupación.

    2. Es posible comunicarse con el soporte de Dell para analizar los factores que podrían afectar los tiempos de actualización. Según el sistema operativo del cliente, la aplicación y el protocolo entre el cliente y el sistema de HA, a veces es posible que el usuario deba reanudar manualmente las cargas de trabajo del cliente justo después de la conmutación por error. Por ejemplo, si con los clientes de DDBoost el tiempo de conmutación por error es superior a 10 minutos, se agota el tiempo de espera del cliente y el usuario debe reanudar las cargas de trabajo de forma manual. Pero, por lo general, hay opciones disponibles para los clientes con el fin de establecer valores de tiempo de espera y cantidad de reintentos. 

Tenga en cuenta que el servicio de DDFS está inactivo durante el período de conmutación por error. Al observar el resultado del comando “filesys status” en el nodo actualizado, se sabrá si el servicio DDFS se reanuda o no. Se espera que las versiones 7.4 y posteriores de DDOS tengan cada vez menos tiempo de inactividad debido a las mejoras en el código de DDOS.

Después de la conmutación por error, se actualizará el nodo activo anteriormente.  Después de ejecutar la actualización, se reiniciará con la nueva versión y, luego, se reincorporará al clúster de HA como el nodo en espera. El servicio DDFS no se ve afectado durante este proceso, ya que ya se reanudó en el paso 2 anterior.


     Verificación:
  1. Una vez finalizada la actualización gradual, debe iniciar sesión en la GUI a través de la dirección IP del nodo en espera anterior, en este caso, es nodo 1.
Login GUI  à Maintenance à System à Check Upgrade History
Página del sistema
  1. Compruebe si hay alertas inesperadas.
Login GUI  à Dashboard à Alerts
  1. En este punto, la actualización gradual finalizó correctamente.

Actualización gradual a través de la CLI:
      Prepare el sistema para la actualización:
  1. Asegúrese de que el estado del sistema de HA sea “altamente disponible”.
#ha status
     
     HA System name:       HA-system   
     HA System status:     highly available         ç
     Node Name                       Node id   Role      HA State
     -----------------------------   -------   -------   --------
     Node0   0         active    online   
     Node1   1         standby   online
     -----------------------------   -------   -------   --------
  1. El archivo RPM de DDOS se debe colocar en el nodo activo y la actualización debe comenzar desde este nodo.
- Cómo encontrar un nodo activo:
  #ha status
 
      HA System name:       HA-system   
      HA System status:     highly available
      Node Name                       Node id   Role      HA State
      -----------------------------   -------   -------   --------
      Node0   0         active    online    ß Node0 is active node
      Node1   1         standby   online
      -----------------------------   -------   -------   --------
  1. Cargar el archivo RPM en el nodo activo
Client-server # scp <rpm file> sysadmin@HA-system.active_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
            Una vez completado el comando “scp”, compruebe la información del paquete del sistema
     Active-node # system package list

     File                 Size (KiB)   Type     Class        Name    Version
     ------------------   ----------   ------   ----------   -----   -------
     x.x.x.x-12345.rpm    2927007.3   System   Production   DD OS   x.x.x.x
     ------------------   ----------   ------   ----------   -----  -------         
  1. Ejecute la comprobación previa en el nodo activo. La actualización se debe anular si se produce algún error.
Active-node # system upgrade precheck <rpm file>

     Upgrade precheck in progress:
     Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%)
     Upgrade precheck found no issues.

     Desactive también la GC, la transferencia de datos y la replicación antes de iniciar la actualización (paso 6) para que estos trabajos no provoquen un tiempo de apagado de DDFS más prolongado durante la actualización. Un tiempo de apagado de DDFS más corto ayudará a minimizar el impacto para los clientes. Estas cargas de trabajo no afectan las operaciones de respaldo/restauración del cliente. En función de las necesidades, estos servicios se pueden reanudar una vez finalizada la actualización mediante los comandos de habilitación correspondientes. Consulte la guía de administración para obtener más detalles.
      Active-node # filesys clean stop
   Active-node # cloud clean stop
   Active-node # data-movement suspend
   Active-node # data-movement stop to-tier active
   Active-node # replication disable all
       
     Tenga en cuenta que hay algunos comandos de “supervisión” para comprobar si se realizan las operaciones anteriores.
      Active-node # filesys clean watch 
   Active-node # cloud clean watch
   Active-node # data-movement watch

      Hay algunos otros comandos y comprobaciones manuales que se describen en la guía de administración que no son estrictamente necesarios para un sistema de HA. Actualmente, se sugiere realizar un reinicio previo como prueba para los sistemas de nodo único. No es necesario para los sistemas de HA porque el paso 5 “conmutación por error de alta disponibilidad” a continuación ya incluye un reinicio automático durante el proceso de conmutación por error.

  1. Opcional. Antes de ejecutar una actualización gradual, se recomienda realizar la conmutación por error de HA dos veces de forma manual en el nodo activo. El fin es probar la funcionalidad de conmutación por error. La operación hará que el nodo activo se reinicie; tenga en cuenta esto.

        En primer lugar, prepárese para la conmutación por error mediante el desactivación de la GC, la transferencia de datos y la replicación. Estos servicios no afectan las cargas de trabajo de respaldo/restauración del cliente. Luego, ejecute la “conmutación por error de HA”.

       A continuación, se muestran los comandos para ejecutarla:
          Active-node # filesys clean stop
     Active-node # cloud clean stop
     Active-node # data-movement suspend
     Active-node # data-movement stop to-tier active
     Active-node # replication disable all
        Tenga en cuenta que hay algunos comandos de “supervisión” para comprobar si se realizan las operaciones anteriores.
          Active-node # filesys clean watch 
     Active-node # cloud clean watch
     Active-node # data-movement watch
        Y, luego, ejecute el comando de conmutación por error:

Active-node # ha failover
          Esta operación iniciará una conmutación por error desde este nodo. El nodo local se reiniciará.
      Do you want to proceed? (yes|no) [no]: yes
    Failover operation initiated. Ejecute “ha status” para monitorear el estado
(Cuando el estado del sistema de HA vuelva a ser “altamente disponible”, ejecute la segunda “conmutación por error de HA” y espere a que ambos nodos estén en línea)

Después de la conmutación por error de HA, los servicios detenidos se pueden reanudar mediante los comandos de habilitación correspondientes. Consulte la guía de administración para obtener más detalles.
Las pruebas de conmutación por error anteriores son opcionales y no es necesario realizarlas justo antes de una actualización. Las pruebas de conmutación por error se pueden realizar antes de la actualización, por ejemplo, con dos semanas de anticipación, de modo que se pueda utilizar una ventana de mantenimiento más pequeña para la actualización posterior. El tiempo de inactividad del servicio DDFS para cada conmutación por error es de alrededor de 10 minutos (menos o más según las versiones de DDOS y algunos otros factores). La versión 7.4 y posteriores de DDOS tendrán menos tiempo de inactividad versión tras versión debido a las mejoras continuas del software de DDOS. 
  

      Procedimiento de actualización paso a paso      
  1. Si la comprobación previa finalizó sin problemas, continúe con la actualización gradual en el nodo activo.
             Active-node # system upgrade start <rpm file>

      El comando “system upgrade” actualiza el SO de Data Domain.  El acceso a los archivos
      se interrumpe durante la actualización.  El sistema se reinicia automáticamente
      después de la actualización.
              Are you sure? (yes|no) [no]: yes
      ok, proceeding.
      Upgrade in progress:
      Node   Severity   Issue                           Solution
      ----   --------   ------------------------------  --------
      0      WARNING    1 component precheck
         script(s) failed to complete
      0      INFO       Upgrade time est: 60 mins
      1      WARNING    1 component precheck
          script(s) failed to complete
      1      INFO       Upgrade time est: 80 mins
      ----   --------   ------------------------------  --------
      Node 0: phase 2/4 (Install    0%) , Node 1: phase 1/4 (Precheck 100%)
      Upgrade phase status legend:
      DU : Data Upgrade
      FO : Failover
      ..               
      PC : Peer Confirmation
      VA : Volume Assembly

      Node 0: phase 3/4 (Reboot     0%) , Node 1: phase 4/4 (Finalize   5%) FO
      Upgrade has started.  System will reboot.   
        

       Disponibilidad de DDFS durante el comando anterior:

  1. Primero actualizará el nodo en espera y lo reiniciará con la nueva versión. Tarda aproximadamente entre 20 y 30 minutos, dependiendo de varios factores. El servicio DDFS está activo y funciona en el nodo activo durante este período sin ninguna degradación del rendimiento.

  2. Después de aplicar el nuevo DDOS, el sistema realizará una conmutación por error del servicio DDFS al nodo en espera actualizado. Tarda aproximadamente 10 minutos (menos o más dependiendo de varios factores).

    1. Un factor importante es la actualización del FW del DAE. Puede introducir alrededor de 20 minutos más de tiempo de inactividad, según la cantidad de DAE que estén configurados. Consulte el artículo de la base de conocimientos “Data Domain: La actualización gradual de HA puede fallar para el firmware del gabinete externo actualizado”, con el fin de determinar si se requiere una actualización del FW del DAE. Tenga en cuenta que, a partir de DDOS 7.5, hay una mejora para habilitar la actualización en línea del FW del DAE, lo que elimina esta preocupación.

    2. Es posible comunicarse con el soporte de Dell para analizar los factores que podrían afectar los tiempos de actualización. Según el sistema operativo del cliente, la aplicación y el protocolo entre el cliente y el sistema de HA, a veces es posible que el usuario deba reanudar manualmente las cargas de trabajo del cliente justo después de la conmutación por error. Por ejemplo, si con los clientes de DDBoost el tiempo de conmutación por error es superior a 10 minutos, se agota el tiempo de espera del cliente y el usuario debe reanudar las cargas de trabajo de forma manual. Pero, por lo general, hay opciones disponibles para los clientes con el fin de establecer valores de tiempo de espera y cantidad de reintentos. 

  1. Después de la conmutación por error, se actualizará el nodo activo anteriormente.  Después de ejecutar la actualización, se reiniciará con la nueva versión y, luego, se reincorporará al clúster de HA como el nodo en espera. El servicio DDFS no se ve afectado durante este proceso, ya que ya se reanudó en el paso 2 anterior.

Tenga en cuenta que el servicio de DDFS está inactivo durante el período de conmutación por error. Al observar el resultado del comando “filesys status” en el nodo actualizado, se sabrá si el servicio DDFS se reanuda o no. Se espera que las versiones 7.4 y posteriores de DDOS tengan cada vez menos tiempo de inactividad debido a las mejoras en el código de DDOS.
  1. Una vez que el nodo en espera (nodo 1) se reinicia y se puede acceder a él, es posible iniciar sesión en el nodo en espera para controlar el estado o el progreso de la actualización.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade In Progress
Node 0: phase 3/4 (Reboot     0%)
Node 1: phase 4/4 (Finalize 100%) waiting for peer confirmation
  1. Espere que la actualización gradual finalice. Antes de que esto ocurra, no active ninguna operación de conmutación por error de HA.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
  1. Compruebe el estado de HA; ambos nodos están en línea y el estado del sistema de HA es “altamente disponible”.
Node1 # ha status detailed
HA System name:               HA-system
HA System Status:             highly available
Interconnect Status:          ok
Primary Heartbeat Status:      ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check:       ok
Node  Node1:
      Role:          active
      HA State:      online
      Node Health: ok
Node Node0:
      Role:          standby
      HA State:      online
      Node Health: ok
Mirroring Status:
Component Name   Status
--------------   ------
nvram            ok
registry         ok
sms              ok
ddboost          ok
cifs             ok
--------------   ------
            

     Verificación:
  1. Compruebe que ambos nodos tengan la misma versión de DDOS.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version                  
Data Domain OS x.x.x.x-12345
  1. Compruebe si hay alertas inesperadas.
Node1 # alert show current
Node0 # alert show current
  1. En este punto, la actualización gradual finalizó correctamente. 

Nota: Si tiene algún problema con la actualización, comuníquese con el soporte de Data Domain para obtener más instrucciones y asistencia.


ACTUALIZACIÓN LOCAL para el par de DDHA: 
A grandes rasgos, una actualización local funciona de la siguiente manera:

      Prepare el sistema para la actualización:

  1. Compruebe el estado del sistema de HA. Incluso si el estado es degradado, la actualización local puede funcionar en esta situación.

     #ha status
     HA System name:       HA-system   
     HA System status:     highly available   <-      
     Node Name                       Node id   Role      HA State
     -----------------------------   -------   -------   --------
     Node0   0         active    online   
     Node1   1         standby   online
     -----------------------------   -------   -------   --------

  1. El archivo RPM de DDOS se debe colocar en ambos nodos y la actualización debe comenzar desde el nodo en espera.
- Cómo encontrar un nodo en espera:
#ha status
HA System name:       HA-system   
HA System status:     highly available
Node Name                       Node id   Role      HA State
-----------------------------   -------   -------   --------
Node0   0         active    online   
Node1   1         standby   online   <- Node1 is standby node
-----------------------------   -------   -------   --------
  1. Cargue el archivo RPM en ambos nodos.
       Client-server # scp <rpm file> sysadmin@HA-  system.active_node:/ddr/var/releases/
Client-server # scp <rpm file> sysadmin@HA-system.standby_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
 
            Una vez completado el comando “scp”, compruebe la información del paquete del sistema.
     Active-node # system package list
     File                 Size (KiB)   Type     Class        Name    Version
     ------------------   ----------   ------   ----------   -----   -------
     x.x.x.x-12345.rpm    2927007.3   System   Production   DD OS   x.x.x.x
     ------------------   ----------   ------   ---------- -----   ------       
     Standby-node # system package list
     File                 Size (KiB)   Type     Class        Name    Version
     ------------------   ----------   ------   ----------   -----   -------
     x.x.x.x-12345.rpm    2927007.3   System   Production   DD OS   x.x.x.x
     ------------------   ----------   ------   ----------   -----   ------
  1. Ejecute una comprobación previa en el nodo activo si el estado de HA es “altamente disponible”. La actualización se debe anular si se produce algún error.
            Active-node # system upgrade precheck <rpm file>

      Upgrade precheck in progress:
      Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%)
      Upgrade precheck found no issues.

            Si el estado de HA es “degradado”, debe realizar una verificación previa en ambos nodos.

            Active-node # system upgrade precheck <rpm file> local
      Upgrade precheck in progress:
      Node 0: phase 1/1 (Precheck 100%)
      Upgrade precheck found no issues.

      Standby-node # system upgrade precheck <rpm file> local
      Upgrade precheck in progress:
      Node 1: phase 1/1 (Precheck 100%)
      Upgrade precheck found no issues.           
     Procedimiento de actualización paso a paso   
     
  1. Desconecte el nodo en espera.
            Standby-node # ha offline
      This operation will cause the ha system to no longer be highly  available.
      Do you want to proceed? (yes|no) [no]: yes
      Standby node is now offline.
           (NOTA: Si la operación de desconexión falló o el estado de alta disponibilidad está degradado, continúe con la actualización local,                ya que los pasos posteriores pueden manejar fallas).
  1. Asegúrese de que el estado del nodo en espera sea fuera de línea.
       Standby-node # ha status
    HA System name:       HA-system
    HA System status:     degraded
    Node Name                       Node id   Role      HA State
    -----------------------------   -------   -------   --------
    Node1   1         standby   offline
    Node0   0         active    degraded
    -----------------------------   -------   -------   --------
    1. Realice la actualización del nodo en espera. Esta operación provocará el reinicio del nodo en espera.
             Standby-node # system upgrade start <rpm file> local
        El comando “system upgrade” actualiza el SO de Data Domain.  El acceso a los archivos
          se interrumpe durante la actualización.  El sistema se reinicia automáticamente
        después de la actualización.
                Are you sure? (yes|no) [no]: yes
        ok, proceeding.
        La marca “local” es altamente disruptiva para los sistemas de HA y se debe utilizar solo como una operación de reparación.
               Are you sure? (yes|no) [no]: yes
        ok, proceeding.
        Actualización en curso:
        Node 1: phase 3/4 (Reboot     0%)
    La actualización ha comenzado.  El sistema se reiniciará.
    1. El nodo en espera se reiniciará con la nueva versión de DDOS, pero permanecerá fuera de línea.
    2. Compruebe el estado de actualización del sistema; puede tardar más de 30 minutos en finalizar la actualización del SO.
                 Standby-node # system upgrade status
          Current Upgrade Status: DD OS upgrade Succeeded
          End time: 20xx.xx.xx:xx:xx
    1. Compruebe el estado del sistema de HA, el nodo en espera (en este caso, es el nodo 1) está fuera de línea y el estado de HA es “degradado”.
                 Standby-node # ha status
          HA System name:       HA-system
          HA System status:     degraded
          Node Name                       Node id   Role      HA State
          -----------------------------   -------   -------   --------
          Node1   1         standby   offline
          Node0   0         active    degraded
          -----------------------------   -------   -------   --------
    1. Realice la actualización local en el nodo activo. Esta operación reiniciará el nodo activo.
            Active-node # system upgrade start <rpm file> local
        The 'system upgrade' command upgrades the Data Domain OS.  File access
        is interrupted during the upgrade.  The system reboots automatically
        after the upgrade.
                   Are you sure? (yes|no) [no]: yes
        ok, proceeding.
        The 'local' flag is highly disruptive to HA systems and should be used        only as a repair operation.
                   Are you sure? (yes|no) [no]: yes
        ok, proceeding.
        Upgrade in progress:
        Node   Severity   Issue                           Solution
        ----   --------   ------------------------------  --------
        0      WARNING    1 component precheck
                 script(s) failed to complete
        0      INFO       Upgrade time est: 60 mins
        ----   --------   ------------------------------  --------
        Node 0: phase 3/4 (Reboot     0%)
        Upgrade has started.  System will reboot.
    1. Compruebe el estado de actualización del sistema; puede tardar más de 30 minutos en finalizar la actualización del SO.
             Active-node # system upgrade status
        Current Upgrade Status: DD OS upgrade Succeeded
        End time: 20xx.xx.xx:xx:xx
    1. Una vez finalizada la actualización del nodo activo, el estado del sistema de HA sigue degradado. Ejecute el siguiente comando para poner en línea al nodo en espera; se reiniciará el nodo en espera.
             Standby-node # ha online
        The operation will reboot this node.
            Do you want to proceed? (yes|no) [no]: yes
        Broadcast message from root (Wed Oct 14 22:38:53 2020):
        The system is going down for reboot NOW!
        **** Error communicating with management service.
        (NOTA: Si no se ejecutó “ha offline” en los pasos anteriores, ignore este paso)
    1. El nodo en espera se reiniciará y se reincorporará al clúster. Después de esto, el estado de HA volverá a ser “altamente disponible”.
              Active-node # ha status detailed
         HA System name:               Ha-system
         HA System Status:             highly available
         Interconnect Status:          ok
         Primary Heartbeat Status:      ok
         External LAN Heartbeat Status: ok
         Hardware compatibility check: ok
         Software Version Check:       ok
         Node node0:
                   Role:          active
                   HA State:      online
                   Node Health: ok
         Node node1:
                   Role:          standby
                   HA State:      online
                   Node Health: ok
         Mirroring Status:
         Component Name   Status
         --------------   ------
         nvram            ok
         registry         ok
         sms              ok
         ddboost          ok
         cifs             ok
         --------------   ------
    Verificación:
    1. Compruebe que ambos nodos tengan la misma versión de DDOS.
           Node1 # system show version
       Data Domain OS x.x.x.x-12345
       Node0 # system show version                  
       Data Domain OS x.x.x.x-12345
    1. Compruebe si hay alertas inesperadas.
           Node1 # alert show current
       Node0 # alert show current
    1. En este punto, la actualización gradual finalizó correctamente.
               
    Nota: Si tiene algún problema con la actualización, comuníquese con el soporte de Data Domain para obtener más instrucciones y asistencia.

    其他信息

    Actualización gradual:

    • Tenga en cuenta que se realiza una sola conmutación por error durante la actualización, por lo que las funciones se intercambiarán

    • La información de actualización se conserva en infra.log, pero puede haber información adicional en ha.log

    • El progreso de la actualización se puede monitorear a través de la vigilancia de actualización del sistema 

    Actualización de nodo local:

    • Una actualización de nodo local no realiza una conmutación por error de HA

    • Como resultado, será un período prolongado de tiempo de inactividad mientras el nodo activo actualiza/reinicia/realiza actividades de actualización posteriores al reinicio, lo que probablemente hará que se agote el tiempo de espera de los respaldos/restauraciones y que fallen. Requerir la asignación de una ventana de tiempo de mantenimiento para la actualización local.

    • Incluso si el estado del sistema de HA es “degradado”, se puede continuar con la actualización local.

    • Por algún motivo, la actualización gradual puede fallar de manera inesperada. En esta situación, la actualización local se puede considerar como un método de corrección.

       

    受影响的产品

    Data Domain

    产品

    Data Domain, DD OS
    文章属性
    文章编号: 000009653
    文章类型: How To
    上次修改时间: 07 10月 2025
    版本:  8
    从其他戴尔用户那里查找问题的答案
    支持服务
    检查您的设备是否在支持服务涵盖的范围内。