Data Domain: BS-Upgradehandbuch für HA-Systeme (High Availability)

Summary: Verfahrensübersicht für Upgrades des Data Domain Operating System (DDOS) auf „hochverfügbaren“ Data Domain-Appliances (DDHA)

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Geplante Wartung des HA-Systems

Um geplante Ausfallzeiten für Wartungen zu reduzieren, unterstützt die HA-Architektur sequenzielle Systemupgrades. Bei einem sequenziellen Upgrade kann zuerst der Stand-by-Node aktualisiert und dann ein erwartetes HA-Failover durchgeführt werden, um die Services vom aktiven Node auf den Stand-by-Node zu verschieben. Anschließend werden die vorherigen aktiven Nodes aktualisiert und treten dem HA-Cluster als Stand-by-Node wieder bei. Alle Vorgänge werden in einem Befehl ausgeführt.
Ein alternativer manueller Upgradeansatz ist ein „lokales Upgrade“. Führen Sie zuerst ein manuelles Upgrade des Stand-by-Node und dann ein manuelles Upgrade des aktiven Node durch.  Anschließend tritt der Stand-by-Node wieder dem HA-Cluster bei. Ein lokales Upgrade kann entweder als reguläres Upgrade oder zur Behebung von Problemen durchgeführt werden.
Alle Systemupgradevorgänge auf aktiven Nodes, die eine Datenkonvertierung erfordern, können erst gestartet werden, wenn beide Systeme auf dieselbe Codeebene aktualisiert wurden und der HA-Status vollständig wiederhergestellt wurde.


Ab DDOS 5.7 werden zwei Upgrademethoden für HA-Systeme unterstützt:

  • Sequenzielles Upgrade: automatisches Upgrade beider HA-Nodes mit einem Befehl. Der Service wird nach dem Upgrade auf den anderen Node verschoben.

  • Lokales Upgrade: manuelles Upgrade der HA-Nodes nacheinander. Der Service wird nach dem Upgrade auf demselben Node beibehalten.

 

Sequenzielles Upgrade über die GUI:

Vorbereiten des Systems auf das Upgrade:

  1. Stellen Sie sicher, dass der HA-Systemstatus „Hochverfügbar“ lautet.

 Melden Sie sich bei der GUI an > Start > Dashboard.

Seite „Dashboard“
  1. Die DDOS-RPM-Datei sollte auf dem aktiven Node abgelegt und das Upgrade von diesem Node aus gestartet werden.
So ermitteln Sie den aktiven Node:
  Melden Sie sich bei der GUI an > Start > Dashboard.

Seite „Dashboard“               
 
  1. Laden Sie die RPM-Datei auf den aktiven Node hoch.
Melden Sie sich bei der GUI an > Wartung > System > Klicken Sie auf die Schaltfläche UPGRADEPAKET HOCHLADEN.

Seite „Wartung“
Nach dem Hochladen wird die RPM-Datei aufgelistet. 
  1. Führen Sie die Vorabprüfung auf dem aktiven Node aus. Das Upgrade sollte abgebrochen werden, wenn ein Fehler auftritt.
Melden Sie sich bei der GUI an > Wartung > System > Klicken Sie auf die Upgrade-RPM-Datei > Klicken Sie auf UPGRADE-VORABPRÜFUNG.

Seite „System“ 
 

         Deaktivieren Sie auch die automatische Speicherbereinigung, Datenverschiebungen und Replikationen, bevor Sie das Upgrade starten (Schritt 6), damit diese Jobs während des Upgrades nicht zu einem längeren Herunterfahren des DDFS führen. Ein kürzeres DDFS-Herunterfahren trägt dazu bei, die Auswirkungen auf Clients zu minimieren. Diese Workloads wirken sich nicht auf Client-Backup-/Wiederherstellungsvorgänge aus.

         Je nach Bedarf können diese Services nach Abschluss des Upgrades mit den entsprechenden Aktivierungsbefehlen fortgesetzt werden. Weitere Informationen finden Sie im Administrationshandbuch.

         Im Administrationshandbuch sind weitere manuelle Prüfungen und Befehle beschrieben, die für ein HA-System nicht unbedingt erforderlich sind. Die Option „Vor dem Neustart“ wird derzeit als Test für Systeme mit nur einem Node empfohlen. Dies ist für HA-Systeme nicht erforderlich, da Schritt 5 „HA-Failover“ unten bereits einen automatischen Neustart während des Failover-Vorgangs beinhaltet.

  1. Optional. Vor der Ausführung eines sequenziellen Upgrades empfiehlt es sich, zweimal ein manuelles HA-Failover auf dem aktiven Node durchzuführen. Der Zweck besteht darin, die Failover-Funktionalität zu testen. Beachten Sie, dass durch den Vorgang der aktive Node neu gestartet wird.

   
              Bereiten Sie zunächst das Failover vor, indem Sie die automatische Speicherbereinigung, Datenverschiebungen und Replikationen deaktivieren. Informationen zur Vorgehensweise über die GUI finden Sie im Administrationshandbuch. Diese Services wirken sich nicht auf Client-Backup/Wiederherstellungs-Workloads aus. Fahren Sie dann mit „HA-Failover“ fort.
 

Melden Sie sich bei der GUI an > Integrität > Hochverfügbarkeit > Klicken Sie auf „Failover auf XXX“


(Wenn der HA-Systemstatus wieder zu „Hochverfügbar“ wechselt, führen Sie das zweite HA-Failover aus und warten Sie, bis beide Nodes online sind).
 

Nach dem HA-Failover können die beendeten Services mit den entsprechenden Aktivierungsbefehlen fortgesetzt werden. Weitere Informationen finden Sie im Administrationshandbuch.

Die oben genannten Failover-Tests sind optional und müssen nicht direkt vor dem Upgrade durchgeführt werden. Die Failover-Tests können vor dem Upgrade durchgeführt werden, z. B. zwei Wochen vorher, sodass für das spätere Upgrade ein kürzeres Wartungszeitfenster geplant werden kann. Die Ausfallzeit des DDFS-Service bei jedem Failover beträgt etwa 10 Minuten (je nach DDOS-Version und anderen Faktoren mehr oder weniger). Ab DDOS-Versionen 7.4 werden aufgrund kontinuierlicher DDOS-SW-Verbesserungen von Version zu Version kürzere Ausfallzeiten notwendig sein.
 

      Schritt-für-Schritt-Verfahren für das Upgrade
  1. Wenn die Vorabprüfung ohne Probleme abgeschlossen wurde, fahren Sie mit dem sequenziellen Upgrade auf dem aktiven Node fort.
Melden Sie sich bei der GUI an > Wartung > System > Klicken Sie auf die Upgrade-RPM-Datei > Klicken Sie auf SYSTEMUPGRADE DURCHFÜHREN.
 
Seite „System“
  1. Warten Sie, bis das sequenzielle Upgrade abgeschlossen ist. Lösen Sie vorher keinen HA-Failover-Vorgang aus.

DDFS-Verfügbarkeit während des obigen Befehls:

  1. Zuerst wird der Stand-by-Node aktualisiert und mit der neuen Version neu gestartet. Dies dauert, abhängig von verschiedenen Faktoren, etwa 20 bis 30 Minuten. Der DDFS-Service ist aktiv und wird während dieses Zeitraums ohne Performanceverschlechterung auf dem aktiven Node ausgeführt.

  2. Nachdem das neue DDOS angewendet wurde, führt das System ein Failover des DDFS-Service auf den aktualisierten Stand-by-Node durch. Dies dauert etwa 10 Minuten (mehr oder weniger, abhängig von verschiedenen Faktoren).

    1. Ein wichtiger Faktor ist das DAE-FW-Upgrade. Dies kann zu ca. 20 Minuten längerer Ausfallzeit führen, je nachdem, wie viele DAEs konfiguriert sind. Lesen Sie den Wissensdatenbank-Artikel „Data Domain: Sequenzielles HA-Upgrade kann aufgrund aktualisierter externer Gehäusefirmware fehlschlagen“, um zu ermitteln, ob ein DAE-FW-Upgrade erforderlich ist. Beachten Sie, dass es ab DDOS 7.5 die Möglichkeit für Onlineupgrades der DAE-FW gibt, wodurch dieses Problem beseitigt wird.

    2. Sie können den Dell Support kontaktieren, um die Faktoren zu besprechen, die sich auf Upgradezeiträume auswirken können. Abhängig vom Client-Betriebssystem, der Anwendung und dem Protokoll zwischen Client und HA-System müssen NutzerInnen Client-Workloads möglicherweise direkt nach dem Failover manuell fortsetzen. Beispiel: Bei DDBoost-Clients und einer Failover-Zeit von mehr als 10 Minuten tritt beim Client ein Timeout auf und NutzerInnen müssen die Workloads manuell fortsetzen. In der Regel sind jedoch Optionen auf Clients verfügbar, um Timeout-Werte und die Wiederholungsanzahl anzupassen. 

Beachten Sie, dass der DDFS-Service während des Failover-Zeitraums inaktiv ist. Sie können der Ausgabe des Befehls „filesys status“ auf dem aktualisierten Node entnehmen, ob der DDFS-Service fortgesetzt wurde oder nicht. Ab DDOS-Versionen 7.4 wird es aufgrund von Verbesserungen am DDOS-Code zu immer weniger Ausfallzeiten kommen.

Nach dem Failover wird der zuvor aktive Node aktualisiert.  Nachdem das Upgrade angewendet wurde, wird er mit der neuen Version neu gestartet und tritt dann dem HA-Cluster als Stand-by-Node wieder bei. Da der DDFS-Service bereits in Schritt 11 fortgesetzt wurde, wird er während dieses Vorgangs nicht beeinträchtigt.


     Überprüfung:
  1. Nach Abschluss des sequenziellen Upgrades ist eine Anmeldung bei der GUI mit der IP-Adresse des vorherigen Stand-by-Node erforderlich, in diesem Fall Node 1.
Melden Sie sich bei der GUI an > Wartung > System > Upgradeverlauf prüfen.
Seite „System“
  1. Überprüfen Sie, ob unerwartete Warnmeldungen vorhanden sind.
Melden Sie sich bei der GUI an > Dashboard > Warnmeldungen.
  1. An diesem Punkt ist das sequenzielle Upgrade erfolgreich abgeschlossen.

Sequenzielles Upgrade über die CLI:
      Vorbereiten des Systems auf das Upgrade:
  1. Stellen Sie sicher, dass der HA-Systemstatus „Hochverfügbar“ lautet.
#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. Die DDOS-RPM-Datei sollte auf dem aktiven Node abgelegt und das Upgrade von diesem Node aus gestartet werden.
So ermitteln Sie den aktiven Node:
  #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. Laden Sie die RPM-Datei auf den aktiven Node hoch.
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”)
            Überprüfen Sie nach Abschluss des Befehls „scp“ die Informationen zum Systempaket.
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. Führen Sie die Vorabprüfung auf dem aktiven Node aus. Das Upgrade sollte abgebrochen werden, wenn ein Fehler auftritt.
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.

     Deaktivieren Sie auch die automatische Speicherbereinigung, Datenverschiebungen und Replikationen, bevor Sie das Upgrade starten (Schritt 6), damit diese Jobs während des Upgrades nicht zu einem längeren Herunterfahren des DDFS führen. Ein kürzeres DDFS-Herunterfahren trägt dazu bei, die Auswirkungen auf Clients zu minimieren. Diese Workloads wirken sich nicht auf Client-Backup-/Wiederherstellungsvorgänge aus. Je nach Bedarf können diese Services nach Abschluss des Upgrades mit den entsprechenden Aktivierungsbefehlen fortgesetzt werden. Weitere Informationen finden Sie im Administrationshandbuch.
      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
       
     Beachten Sie, dass es einige „watch“-Befehle gibt, mit denen überprüft werden kann, ob die oben genannten Vorgänge ausgeführt wurden.
      Active-node # filesys clean watch 
   Active-node # cloud clean watch
   Active-node # data-movement watch

      Im Administrationshandbuch sind weitere manuelle Prüfungen und Befehle beschrieben, die für ein HA-System nicht unbedingt erforderlich sind. Die Option „Vor dem Neustart“ wird derzeit als Test für Systeme mit nur einem Node empfohlen. Dies ist für HA-Systeme nicht erforderlich, da Schritt 5 „HA-Failover“ unten bereits einen automatischen Neustart während des Failover-Vorgangs beinhaltet.

  1. Optional. Vor der Ausführung eines sequenziellen Upgrades empfiehlt es sich, zweimal ein manuelles HA-Failover auf dem aktiven Node durchzuführen. Der Zweck besteht darin, die Failover-Funktionalität zu testen. Beachten Sie, dass durch den Vorgang der aktive Node neu gestartet wird.

        Bereiten Sie zunächst das Failover vor, indem Sie die automatische Speicherbereinigung, Datenverschiebungen und Replikationen deaktivieren. Diese Services wirken sich nicht auf Client-Backup/Wiederherstellungs-Workloads aus. Führen Sie dann „HA-Failover“ aus.

       Die erforderlichen Befehle lauten wie folgt:
          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
        Beachten Sie, dass es einige „watch“-Befehle gibt, mit denen überprüft werden kann, ob die oben genannten Vorgänge ausgeführt wurden.
          Active-node # filesys clean watch 
     Active-node # cloud clean watch
     Active-node # data-movement watch
        Führen Sie dann den Failover-Befehl aus:

Active-node # ha failover
          This operation will initiate a failover from this node. The local node will reboot.
      Do you want to proceed? (yes|no) [no]: yes
    Failover operation initiated. Run 'ha status' to monitor the status
(Wenn der HA-Systemstatus wieder zu „Hochverfügbar“ wechselt, führen Sie das zweite HA-Failover aus und warten Sie, bis beide Nodes online sind.)

Nach dem HA-Failover können die beendeten Services mit den entsprechenden Aktivierungsbefehlen fortgesetzt werden. Weitere Informationen finden Sie im Administrationshandbuch.
Die oben genannten Failover-Tests sind optional und müssen nicht direkt vor dem Upgrade durchgeführt werden. Die Failover-Tests können vor dem Upgrade durchgeführt werden, z. B. zwei Wochen vorher, sodass für das spätere Upgrade ein kürzeres Wartungszeitfenster geplant werden kann. Die Ausfallzeit des DDFS-Service bei jedem Failover beträgt etwa 10 Minuten (je nach DDOS-Version und anderen Faktoren mehr oder weniger). Ab DDOS-Versionen 7.4 werden aufgrund kontinuierlicher DDOS-SW-Verbesserungen von Version zu Version kürzere Ausfallzeiten notwendig sein. 
  

      Schritt-für-Schritt-Verfahren für das Upgrade      
  1. Wenn die Vorabprüfung ohne Probleme abgeschlossen wurde, fahren Sie mit dem sequenziellen Upgrade auf dem aktiven Node fort.
             Active-node # system upgrade start <rpm file>

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

       DDFS-Verfügbarkeit während des obigen Befehls:

  1. Zuerst wird der Stand-by-Node aktualisiert und mit der neuen Version neu gestartet. Dies dauert, abhängig von verschiedenen Faktoren, etwa 20 bis 30 Minuten. Der DDFS-Service ist aktiv und wird während dieses Zeitraums ohne Performanceverschlechterung auf dem aktiven Node ausgeführt.

  2. Nachdem das neue DDOS angewendet wurde, führt das System ein Failover des DDFS-Service auf den aktualisierten Stand-by-Node durch. Dies dauert etwa 10 Minuten (mehr oder weniger, abhängig von verschiedenen Faktoren).

    1. Ein wichtiger Faktor ist das DAE-FW-Upgrade. Dies kann zu ca. 20 Minuten längerer Ausfallzeit führen, je nachdem, wie viele DAEs konfiguriert sind. Lesen Sie den Wissensdatenbank-Artikel „Data Domain: Sequenzielles HA-Upgrade kann aufgrund aktualisierter externer Gehäusefirmware fehlschlagen“, um zu ermitteln, ob ein DAE-FW-Upgrade erforderlich ist. Beachten Sie, dass es ab DDOS 7.5 die Möglichkeit für Onlineupgrades der DAE-FW gibt, wodurch dieses Problem beseitigt wird.

    2. Sie können den Dell Support kontaktieren, um die Faktoren zu besprechen, die sich auf Upgradezeiträume auswirken können. Abhängig vom Client-Betriebssystem, der Anwendung und dem Protokoll zwischen Client und HA-System müssen NutzerInnen Client-Workloads möglicherweise direkt nach dem Failover manuell fortsetzen. Beispiel: Bei DDBoost-Clients und einer Failover-Zeit von mehr als 10 Minuten tritt beim Client ein Timeout auf und NutzerInnen müssen die Workloads manuell fortsetzen. In der Regel sind jedoch Optionen auf Clients verfügbar, um Timeout-Werte und die Wiederholungsanzahl anzupassen. 

  1. Nach dem Failover wird der zuvor aktive Node aktualisiert.  Nachdem das Upgrade angewendet wurde, wird er mit der neuen Version neu gestartet und tritt dann dem HA-Cluster als Stand-by-Node wieder bei. Da der DDFS-Service bereits in Schritt 11 fortgesetzt wurde, wird er während dieses Vorgangs nicht beeinträchtigt.

Beachten Sie, dass der DDFS-Service während des Failover-Zeitraums inaktiv ist. Sie können der Ausgabe des Befehls „filesys status“ auf dem aktualisierten Node entnehmen, ob der DDFS-Service fortgesetzt wurde oder nicht. Ab DDOS-Versionen 7.4 wird es aufgrund von Verbesserungen am DDOS-Code zu immer weniger Ausfallzeiten kommen.
  1. Nachdem der Stand-by-Node (Node 1) neu gestartet wurde und zugänglich ist, können Sie sich beim Stand-by-Node anmelden, um den Upgradestatus/-fortschritt zu überwachen.
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. Warten Sie, bis das sequenzielle Upgrade abgeschlossen ist. Lösen Sie vorher keinen HA-Failover-Vorgang aus.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
  1. Überprüfen Sie den HA-Status, ob beide Nodes online sind und ob der HA-Systemstatus „Hochverfügbar“ lautet.
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
--------------   ------
            

     Überprüfung:
  1. Überprüfen Sie, ob beide Nodes dieselbe DDOS-Version ausführen.
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. Überprüfen Sie, ob unerwartete Warnmeldungen vorhanden sind.
Node1 # alert show current
Node0 # alert show current
  1. An diesem Punkt ist das sequenzielle Upgrade erfolgreich abgeschlossen. 

Hinweis: Wenn beim Upgrade Probleme auftreten, wenden Sie sich an den Data Domain-Support, um weitere Anweisungen und Unterstützung zu erhalten.


LOKALES UPGRADE für DDHA-Paar: 
Ein lokales Upgrade funktioniert im Großen und Ganzen wie folgt:

      Vorbereiten des Systems auf das Upgrade:

  1. Überprüfen Sie den HA-Systemstatus. Auch wenn der Status heruntergestuft ist, kann ein lokales Upgrade in dieser Situation funktionieren.

     #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. Die DDOS-RPM-Datei sollte auf beiden Nodes abgelegt und das Upgrade vom Stand-by-Node aus gestartet werden.
So ermitteln Sie den Stand-by-Node:
#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. Laden Sie die RPM-Datei auf beide Nodes hoch.
       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”)
 
            Überprüfen Sie nach Abschluss des Befehls „scp“ die Informationen zum Systempaket.
     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. Führen Sie eine Vorabprüfung auf dem aktiven Node aus, wenn der HA-Status „Hochverfügbar“ lautet. Das Upgrade sollte abgebrochen werden, wenn ein Fehler auftritt.
            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.

            Wenn der HA-Status „heruntergestuft“ ist, muss auf beiden Nodes eine Vorabprüfung durchgeführt werden.

            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.           
     Schritt-für-Schritt-Verfahren für das Upgrade   
     
  1. Schalten Sie den Stand-by-Node offline.
            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.
           (HINWEIS: Wenn der Offlinevorgang fehlgeschlagen oder der HA-Status heruntergestuft ist, fahren Sie mit dem lokalen Upgrade fort, da die Fehler bei späteren Schritten möglicherweise keine Rolle spielen.)
  1. Stellen Sie sicher, dass der Status des Stand-by-Node offline ist.
       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. Führen Sie das Upgrade auf dem Stand-by-Node durch. Dieser Vorgang löst einen Neustart des Stand-by-Node aus.
             Stand-by-node # system upgrade start <RPM-Datei> 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 1: phase 3/4 (Reboot     0%)
        Upgrade has started.  System will reboot.
    1. Der Stand-by-Node wird mit der neuen DDOS-Version neu gestartet, bleibt aber offline.
    2. Überprüfen Sie den Status des Systemupgrades. Es kann mehr als 30 Minuten dauern, bis das Betriebssystem-Upgrade abgeschlossen ist.
                 Standby-node # system upgrade status
          Current Upgrade Status: DD OS upgrade Succeeded
          End time: 20xx.xx.xx:xx:xx
    1. Überprüfen Sie den HA-Systemstatus, ob der Stand-by-Node (in diesem Fall Node 1) offline ist und der HA-Status „heruntergestuft“ lautet.
                 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. Führen Sie das lokale Upgrade auf dem aktiven Node durch. Durch diesen Vorgang wird der aktive Node neu gestartet.
            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. Überprüfen Sie den Status des Systemupgrades. Es kann mehr als 30 Minuten dauern, bis das Betriebssystem-Upgrade abgeschlossen ist.
             Active-node # system upgrade status
        Current Upgrade Status: DD OS upgrade Succeeded
        End time: 20xx.xx.xx:xx:xx
    1. Nach Abschluss des Upgrades des aktiven Node ist der HA-Systemstatus weiterhin heruntergestuft. Führen Sie den folgenden Befehl aus, um den Stand-by-Node online zu schalten. Dadurch wird der Stand-by-Node neu gestartet.
             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.
        (HINWEIS: Wenn „ha offline“ in den vorherigen Schritten nicht ausgeführt wurde, ignorieren Sie diesen Schritt.)
    1. Der Stand-by-Node wird neu gestartet und tritt dem Cluster wieder bei. Danach wird der HA-Status wieder „Hochverfügbar“.
              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
         --------------   ------
    Überprüfung:
    1. Überprüfen Sie, ob beide Nodes dieselbe DDOS-Version ausführen.
           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. Überprüfen Sie, ob unerwartete Warnmeldungen vorhanden sind.
           Node1 # alert show current
       Node0 # alert show current
    1. An diesem Punkt ist das sequenzielle Upgrade erfolgreich abgeschlossen.
               
    Hinweis: Wenn beim Upgrade Probleme auftreten, wenden Sie sich an den Data Domain-Support, um weitere Anweisungen und Unterstützung zu erhalten.

    Additional Information

    Sequenzielles Upgrade:

    • Beachten Sie, dass während des Upgrades ein einzelnes Failover durchgeführt wird, sodass die Rollen getauscht werden.

    • Die Upgradeinformationen werden weiterhin in infra.log gespeichert. Es können jedoch zusätzliche Informationen in ha.log enthalten sein.

    • Der Upgradefortschritt kann über die Systemupgradeüberwachung nachverfolgt werden. 

    Lokales Node-Upgrade:

    • Bei einem lokalen Node-Upgrade wird kein HA-Failover durchgeführt.

    • Infolgedessen kommt es zu einer längeren Ausfallzeit, während der aktive Node Upgrades/Neustarts/Upgradeaktivitäten nach dem Neustart durchführt, was wahrscheinlich dazu führt, dass Backups/Wiederherstellungen aufgrund eines Timeouts fehlschlagen. Für ein lokales Upgrade muss daher ein Wartungszeitfenster eingeplant werden.

    • Selbst wenn der HA-Systemstatus „heruntergestuft“ ist, kann das lokale Upgrade fortgesetzt werden.

    • Aus irgendeinem Grund kann das sequenzielle Upgrade unerwartet fehlschlagen. Ein lokales Upgrade kann in diesem Fall als Korrekturmaßnahme in Betracht gezogen werden.

       

    Affected Products

    Data Domain

    Products

    Data Domain, DD OS
    Article Properties
    Article Number: 000009653
    Article Type: How To
    Last Modified: 07 Oct 2025
    Version:  8
    Find answers to your questions from other Dell users
    Support Services
    Check if your device is covered by Support Services.