DataDomain: Guida all'aggiornamento del sistema operativo per sistemi con high availability (HA)

Summary: Panoramica del processo per gli aggiornamenti DDOS (Data Domain Operation System) sulle appliance DDHA (Data Domain "Highly Available").

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

Manutenzione programmata del sistema HA

Per ridurre il downtime della manutenzione programmata, l'aggiornamento in sequenza del sistema è incluso nell' architettura HA. Un aggiornamento in sequenza potrebbe aggiornare prima il nodo di standby e quindi utilizzare un failover HA previsto per spostare i servizi dal nodo attivo al nodo di standby. Infine, i nodi attivi precedenti verranno aggiornati e aderiranno di nuovo al cluster HA come nodo di standby. Tutti i processi vengono eseguiti con un unico comando.
Un approccio alternativo all'aggiornamento manuale è l'aggiornamento locale. Aggiornare manualmente prima il nodo di standby, quindi aggiornare manualmente il nodo attivo.  Infine, il nodo di standby si ricollega al cluster HA. L'aggiornamento locale può essere eseguito per l'aggiornamento regolare o per la risoluzione di problemi.
Tutte le operazioni di upgrade del sistema sul nodo attivo richiedono la conversione dei dati potrebbero non iniziare fino a quando entrambi i sistemi non vengono aggiornati allo stesso livello e lo stato HA non viene completamente ripristinato.

Questo articolo della KB deve essere controllato prima di procedere con questa procedura:

Data Domain PowerProtect: Controllo preliminare dell'upgrade di DDHA

 

DDOS 5.7 e versioni successive supportano due tipi di metodi di aggiornamento dei sistemi HA:

  • Aggiornamento in sequenza: aggiornamento automatico di entrambi i nodi HA con un solo comando. Il servizio viene spostato nell'altro nodo dopo l'aggiornamento.

  • Aggiornamento locale: aggiornamento manuale dei nodi HA uno alla volta. Il servizio viene mantenuto nello stesso nodo dopo l'aggiornamento.

 

Aggiornamento in sequenza tramite GUI:

Preparazione del sistema per l'aggiornamento:

  1. Assicurarsi che lo stato del sistema HA sia ad alta disponibilità.

 GUI di accesso -> Home -> Dashboard

Pagina Dashboard
  1. Il file RPM DDOS deve essere posizionato sul nodo attivo e l'aggiornamento deve iniziare da questo nodo.
- Come trovare il nodo attivo:
  GUI di accesso -> Home -> Dashboard

Pagina Dashboard               
 
  1. Caricare il file RPM sul nodo attivo
Interfaccia grafica utente di accesso -> Manutenzione -> Sistema -> Cliccare sul pulsante


Pagina MaintenanceUPLOAD UPGRADE PACKAGE Dopoil caricamento, verrà elencato il file RPM.  
  1. Eseguire il controllo preliminare sul nodo attivo. In caso di errori, l'aggiornamento deve essere interrotto.
Interfaccia utente di accesso ->Manutenzione-> Sistema -> Cliccare sul file RPM di aggiornamento -> Cliccare su UPGRADE PRECHECK

Pagina System 
 

         Arrestare anche la pulizia dei file, lo spostamento dei dati e la replica prima di avviare l'aggiornamento (passaggio #6) in modo che questi lavori non portino a tempi di arresto DDFS più lunghi durante l'aggiornamento. Tempi di arresto DDFS più brevi per contribuiscono a ridurre al minimo l'impatto sui client. Questi carichi di lavoro non influiscono sulle operazioni di backup/ripristino dei client.

         In base alle esigenze, questi servizi possono essere ripresi dopo il completamento dell'aggiornamento utilizzando i comandi di abilitazione corrispondenti . Fare riferimento alla guida all'amministrazione per ulteriori dettagli.

         Nella guida all'amministrazione sono descritti altri controlli e comandi manuali che non sono strettamente necessari per un sistema HA. Il pre-riavvio è attualmente consigliato come test per i sistemi a nodo singolo. Non è necessario per i sistemi HA, poiché il punto 5 "ha failover" di seguito include già un riavvio automatico durante il processo di failover.

 

  1. Opzionale. Prima di eseguire l'aggiornamento in sequenza, si consiglia di eseguire manualmente il failover HA due volte sul nodo attivo. Lo scopo è testare la funzionalità di failover. Tenere in considerazione che l'operazione farà riavviare il nodo attivo.
    In primo luogo, preparare il failover arrestando la pulizia, lo spostamento dei dati e la replica. Fare riferimento alla guida all'amministrazione per informazioni su come farlo tramite GUI. Questi servizi non influiscono sui carichi di lavoro di backup/ripristino dei client. Quindi procedere con "ha failover". 
GUI di accesso -> Health -> High Availability -> Cliccare su Failover to Node


(quando lo stato del sistema HA diventa di nuovo "high availability", eseguire il secondo "ha failover" e attendere che entrambi i nodi diventino online)
 

Dopo il failover HA, i servizi arrestati possono essere ripresi utilizzando i comandi enable corrispondenti. Per ulteriori dettagli, fare riferimento alla guida all'amministrazione.

I suddetti test di failover sono opzionali e non devono essere eseguiti subito prima dell'aggiornamento. I test di failover possono essere eseguiti prima dell'aggiornamento, ad esempio due settimane prima, in modo da poter utilizzare una finestra di manutenzione più piccola per l'aggiornamento successivo. Il downtime del servizio DDFS per ogni failover è di circa 10 minuti (più o meno, a seconda delle versioni di DDOS e di altri fattori). Le versioni DDOS 7.4 e successive avranno meno downtime per rilascio grazie ai continui miglioramenti del software DDOS.
 

      Procedura di aggiornamento passo passo
  1. Se il controllo preliminare viene completato senza problemi, procedere con l'aggiornamento in sequenza sul nodo attivo.
Interfaccia utente di accesso -> Manutenzione-> Sistema-> Cliccare sul file RPM di aggiornamento -> Cliccare su ESEGUI AGGIORNAMENTO DEL SISTEMA
 
Pagina System
  1. Attendere il completamento dell'aggiornamento in sequenza. Prima, non attivare alcuna operazione di failover HA.

Disponibilità DDFS durante il comando indicato in precedenza:

  1. Il nodo di standby verrà prima aggiornato e riavviato alla nuova versione. Sono necessari da 20 a 30 minuti circa, a seconda di vari fattori. Il servizio DDFS è attivo e funziona sul nodo attivo durante questo periodo senza alcuna riduzione delle prestazioni

  2. Dopo aver applicato il nuovo DDOS, il sistema eseguirà il failover del servizio DDFS al nodo di standby aggiornato. Sono necessari circa 10 minuti (più o meno a seconda di vari fattori).

    1. Un fattore significativo è l'upgrade del firmware del DAE (Disk Enclosure). Potrebbe introdurre ~20 minuti di downtime in più a seconda del numero di DAE configurati. Fare riferimento all'articolo della Knowledge base "Data Domain: l'aggiornamento in sequenza HA potrebbe non riuscire per l'aggiornamento del firmware dell'enclosure esterno", per determinare se è necessario un aggiornamento del firmware DAE. Tieni presente che a partire da DDOS 7.5 è disponibile un miglioramento per abilitare l'aggiornamento online del firmware DAE, che elimina questo problema.

    2. È possibile contattare il supporto Dell per discutere di fattori che potrebbero influire sui tempi di aggiornamento. Dipende dal sistema operativo client, dall'applicazione e dal protocollo tra il client e il sistema HA, a volte l'utente potrebbe dover riprendere manualmente i carichi di lavoro client subito dopo il failover. Ad esempio, se con i client DDBoost il tempo di failover è superiore a 10 minuti, il timeout del client e l'utente devono riprendere manualmente i carichi di lavoro. Tuttavia, i client sono in genere regolabili per impostare i valori di timeout e i tempi di nuovi tentativi. 

Tenere presente che il servizio DDFS non è attivo durante il periodo di failover. Guardando l'output del comando "filesys status" sul nodo aggiornato, è possibile sapere se il servizio DDFS è stato ripreso o meno. Si prevede che le versioni DDOS 7.4 e successive avranno meno downtime grazie ai miglioramenti apportati al codice DDOS.

Dopo il failover, il nodo attivo precedente verrà aggiornato.  Dopo aver applicato l'aggiornamento, verrà riavviato alla nuova versione e quindi si ricollegherà al cluster HA come nodo di standby. Il servizio DDFS non è interessato da questo processo in quanto è già stato ripreso in precedenza.


     Verifica:
  1. Al termine dell'aggiornamento continuo, è necessaria l'interfaccia grafica utente di accesso tramite l'indirizzo IP del nodo di pre-standby, in questo caso si tratta del nodo 1.
Accedi alla GUI -> Manutenzione -> Sistema ->Controlla cronologia aggiornamenti
Pagina System
  1. Controllare se ci sono avvisi imprevisti.
Interfaccia utente di accesso -> Dashboard -> Avvisi
  1. A questo punto, l'aggiornamento in sequenza è stato completato correttamente.

Aggiornamento in sequenza tramite CLI:
      Preparazione del sistema per l'aggiornamento:
  1. Assicurarsi che lo stato del sistema HA sia ad alta disponibilità.
#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. Il file RPM DDOS deve essere posizionato sul nodo attivo e l'aggiornamento deve iniziare da questo nodo.
- Come trovare il nodo attivo:
  #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. Caricare il file RPM sul nodo attivo
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”)
You might need the -O option to get scp to work
           Dopo aver completato il comando "scp", controllare le informazioni sul pacchetto di 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. Eseguire il controllo preliminare sul nodo attivo. In caso di errori, l'aggiornamento deve essere interrotto.
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.

     Arrestare anche GC, spostamento e replica dei dati prima di avviare l'aggiornamento (passaggio 6) in modo che questi processi non prolunghino il tempo di arresto DDFS durante l'aggiornamento. Tempi di arresto DDFS più brevi per contribuiscono a ridurre al minimo l'impatto sui client. Questi carichi di lavoro non influiscono sulle operazioni di backup/ripristino dei client. In base alle esigenze, questi servizi possono essere ripresi dopo il completamento dell'aggiornamento utilizzando i comandi di abilitazione corrispondenti. Fare riferimento alla guida all'amministrazione per ulteriori dettagli.
   Active-node # filesys clean stop
   Active-node # cloud clean stop
   Active-node # replication disable all
       
     Tenere presente che sono disponibili alcuni comandi di controllo per verificare se le operazioni sopra descritte sono state eseguite.
     Active-node # filesys clean watch 
   Active-node # cloud clean watch


      Nella guida all'amministrazione sono descritti altri controlli e comandi manuali che non sono strettamente necessari per un sistema HA. Il pre-riavvio è attualmente consigliato come test per i sistemi a nodo singolo. Non è necessario per i sistemi HA, poiché il punto 5 "ha failover" di seguito include già un riavvio automatico durante il processo di failover.

  1. Opzionale. Prima di eseguire l'aggiornamento in sequenza, si consiglia di eseguire manualmente il failover HA due volte sul nodo attivo. Lo scopo è testare la funzionalità di failover. Tenere in considerazione che l'operazione farà riavviare il nodo attivo.

        Per prima cosa, prepararsi al failover disattivando GC, spostamento e replica dei dati. Questi servizi non influiscono sui carichi di lavoro di backup/ripristino dei client. Quindi eseguire "ha failover".

       Di seguito sono riportati i comandi per compiere l'operazione:
         Active-node # filesys clean stop
     Active-node # cloud clean stop
     Active-node # replication disable all
        Tenere presente che sono disponibili alcuni comandi di controllo per verificare se le operazioni sopra descritte sono state eseguite.
        Active-node # filesys clean watch 
     Active-node # cloud clean watch
        Quindi eseguire il comando failover:

Active-node # ha failover
          Questa operazione avvierà un failover da questo nodo. Il nodo locale verrà riavviato.
      Continuare? (yes|no) [no]: yes
    Operazione di failover avviata. Eseguire "ha status" per monitorare lo stato
(Quando lo stato del sistema HA diventa nuovamente "highly available", eseguire il secondo "ha failover" e attendere che entrambi i nodi diventino online)

Dopo il failover HA, i servizi arrestati possono essere ripresi utilizzando i comandi enable corrispondenti. Per ulteriori dettagli, fare riferimento alla guida all'amministrazione.
I suddetti test di failover sono opzionali e non devono essere eseguiti subito prima dell'aggiornamento. I test di failover possono essere eseguiti prima dell'aggiornamento, ad esempio due settimane prima, in modo da poter utilizzare una finestra di manutenzione più piccola per l'aggiornamento successivo. Il downtime del servizio DDFS per ogni failover è di circa 10 minuti (più o meno, a seconda delle versioni di DDOS e di altri fattori). Le versioni DDOS 7.4 e successive avranno meno downtime per rilascio grazie ai continui miglioramenti del software DDOS. 
  

      Procedura di aggiornamento passo passo      
  1. Se il controllo preliminare viene completato senza problemi, procedere con l'aggiornamento in sequenza sul nodo attivo.
             Active-node # system upgrade start <rpm file>

      Il comando "system upgrade" aggiorna il sistema operativo di Data Domain.  L'accesso ai file
      viene interrotto durante l'aggiornamento.  Il sistema si riavvia automaticamente
      dopo l'aggiornamento.
              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.   
        

       Disponibilità DDFS durante il comando indicato in precedenza:

  1. Il nodo di standby verrà prima aggiornato e riavviato alla nuova versione. Sono necessari da 20 a 30 minuti circa, a seconda di vari fattori. Il servizio DDFS è attivo e funziona sul nodo attivo durante questo periodo senza alcun peggioramento delle prestazioni.

  2. Dopo aver applicato il nuovo DDOS, il sistema eseguirà il failover del servizio DDFS al nodo di standby aggiornato. Sono necessari circa 10 minuti (più o meno a seconda di vari fattori).

    1. Un fattore significativo è l'upgrade del firmware DAE (Disk Enclosure). Potrebbe introdurre ~20 minuti di downtime in più a seconda del numero di DAE configurati. Fare riferimento all'articolo della Knowledge base "Data Domain: l'aggiornamento in sequenza HA potrebbe non riuscire per l'aggiornamento del firmware dell'enclosure esterno", per determinare se è necessario un aggiornamento del firmware DAE. Tieni presente che a partire da DDOS 7.5 è disponibile un miglioramento per abilitare l'aggiornamento online del firmware DAE, che elimina questo problema.

    2. È possibile contattare il supporto Dell per discutere di fattori che potrebbero influire sui tempi di aggiornamento. Dipende dal sistema operativo client, dall'applicazione e dal protocollo tra il client e il sistema HA, a volte l'utente potrebbe dover riprendere manualmente i carichi di lavoro client subito dopo il failover. Ad esempio, se con i client DDBoost il tempo di failover è superiore a 10 minuti, il timeout del client e l'utente devono riprendere manualmente i carichi di lavoro. Tuttavia, i client sono in genere regolabili per impostare i valori di timeout e i tempi di nuovi tentativi. 

  1. Dopo il failover, il nodo attivo precedente verrà aggiornato.  Dopo aver applicato l'aggiornamento, verrà riavviato alla nuova versione e quindi si ricollegherà al cluster HA come nodo di standby. Il servizio DDFS non è interessato da questo processo, in quanto è già stato ripreso in precedenza.

Tenere presente che il servizio DDFS non è attivo durante il periodo di failover. Guardando l'output del comando "filesys status" sul nodo aggiornato, è possibile sapere se il servizio DDFS è stato ripreso o meno. Si prevede che le versioni DDOS 7.4 e successive avranno meno downtime grazie ai miglioramenti apportati al codice DDOS.
  1. Dopo che il nodo di standby (node1) viene riavviato e diventa accessibile, è possibile accedere al nodo di standby per monitorare lo stato/l'avanzamento dell'aggiornamento.
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. Attendere il completamento dell'aggiornamento in sequenza. Prima, non attivare alcuna operazione di failover HA.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
  1. Controllare lo stato HA, che entrambi i nodi siano online, che lo stato del sistema HA sia "highly available".
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
--------------   ------
            

     Verifica:
  1. Verificare che entrambi i nodi abbiano la stessa versione di 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. Controllare se ci sono avvisi imprevisti.
Node1 # alert show current
Node0 # alert show current
  1. A questo punto, l'aggiornamento in sequenza è stato completato correttamente. 

Nota: Se si verificano problemi con l'aggiornamento, contattare il supporto Data Domain per ulteriori istruzioni e supporto.


AGGIORNAMENTO LOCALE per la coppia DDHA: 
Un aggiornamento locale funziona generalmente come segue:

      Preparazione del sistema per l'aggiornamento:

  1. Verifica dello stato del sistema HA. Anche se lo stato è degradato, l'aggiornamento locale può funzionare in questa situazione.

     #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. Il file RPM DDOS deve essere posizionato su entrambi i nodi e l'aggiornamento deve iniziare dal nodo di standby.
- Come trovare il nodo di standby:
#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. Caricare il file RPM su entrambi i nodi.
       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.)
You might need the -O option to get scp to work
(From client server, target path is “/ddr/var/releases”)
 
           Dopo aver completato il comando "scp", controllare le informazioni sul pacchetto di 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. Eseguire il controllo preliminare sul nodo attivo per verificare se lo stato HA è "highly available". In caso di errori, l'aggiornamento deve essere interrotto.
            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.

           If HA status is "degraded", need do precheck on both nodes.

         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.           
     Procedura di aggiornamento passo passo   
     
  1. Portare il nodo di standby 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.
           (NOTA: Se il funzionamento offline non è riuscito o lo stato ha è ridotto, continuare l'aggiornamento locale perché i passaggi successivi potrebbero gestire gli errori.)
  1. Assicurarsi che lo stato del nodo di standby sia offline.
       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. Eseguire l'aggiornamento sul nodo di standby. Questa operazione invocherà il riavvio del nodo di standby.
             Standby-node # system upgrade start <rpm file> local
        Il comando "system upgrade" aggiorna il sistema operativo di Data Domain.  L'accesso ai file
        viene interrotto durante l'aggiornamento.  Il sistema si riavvia automaticamente
        dopo l'aggiornamento.
                Continuare? (yes|no) [no]: yes
        ok, proceeding.
        Il flag "local" disturba estremamente i sistemi HA e deve essere utilizzato solo come intervento di riparazione.
               Continuare? (yes|no) [no]: yes
        ok, proceeding.
        Aggiornamento in corso:
        Node 1: phase 3/4 (Reboot     0%)
        Aggiornamento avviato.  Il sistema verrà riavviato.
    1. Il nodo di standby verrà riavviato nella nuova versione di DDOS ma rimarrà offline.
    2. Verificare lo stato dell'aggiornamento del sistema; potrebbero essere necessari più di 30 minuti per completare l'aggiornamento del sistema operativo.
                 Standby-node # system upgrade status
          Current Upgrade Status: DD OS upgrade Succeeded
          End time: 20xx.xx.xx:xx:xx
    1. Controllare lo stato del sistema HA, che il nodo di standby (in questo caso node1) sia offline, se lo stato del sistema HA è "degraded".
                 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. Eseguire l'aggiornamento locale sul nodo attivo. Questa operazione riavvierà il nodo attivo.
            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. Verificare lo stato dell'aggiornamento del sistema; potrebbero essere necessari più di 30 minuti per completare l'aggiornamento del sistema operativo.
             Active-node # system upgrade status
        Current Upgrade Status: DD OS upgrade Succeeded
        End time: 20xx.xx.xx:xx:xx
    1. Al termine dell'aggiornamento del nodo attivo, lo stato del sistema HA è ancora degradato. Eseguire il seguente comando per rendere online il nodo di standby e riavviare il nodo di standby.
             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: Se "ha offline" non è stato eseguito ai passaggi precedenti, ignorare questo    passaggio)
    1. Il nodo di standby si riavvia e si ricollega al cluster. Successivamente, lo stato HA diventerà di nuovo "highly available".
              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
         --------------   ------
    Verifica:
    1. Verificare che entrambi i nodi abbiano la stessa versione di 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. Controllare se ci sono avvisi imprevisti.
          Node1 # alert show current
       Node0 # alert show current
    1. A questo punto, l'aggiornamento in sequenza è stato completato correttamente.
               
    Nota: In caso di problemi con l'aggiornamento, contattare il supporto di Data Domain per ulteriori istruzioni e assistenza.

    Additional Information

    Aggiornamento in sequenza:

    • Tenere presente che durante l'aggiornamento viene eseguito un singolo failover, in modo che i ruoli si invertano

    • Le informazioni sull'aggiornamento continuano a essere conservate in infra.log, ma in ha.log potrebbero essere presenti informazioni aggiuntive

    • L'avanzamento dell'aggiornamento può essere monitorato tramite la funzione di controllo dell'aggiornamento del sistema 

    Aggiornamento nodo locale:

    • Un aggiornamento del nodo locale non esegue il failover HA

    • Di conseguenza, ci sarà un periodo di downtime prolungato mentre il nodo attivo si aggiorna/si riavvia/esegue attività di aggiornamento post-riavvio, che probabilmente causeranno il timeout e la mancata riuscita di backup/ripristini. Richiedere l'assegnazione di una finestra temporale di manutenzione per l'aggiornamento locale.

    • Anche se lo stato del sistema HA è "degraded", è possibile procedere con l'aggiornamento locale.

    • Per qualche motivo, l'aggiornamento in sequenza potrebbe non riuscire in modo imprevisto. In questa situazione, l'aggiornamento locale può essere considerato come un metodo di correzione.

       

    Affected Products

    Data Domain

    Products

    Data Domain, DD OS
    Article Properties
    Article Number: 000009653
    Article Type: How To
    Last Modified: 12 يناير 2026
    Version:  10
    Find answers to your questions from other Dell users
    Support Services
    Check if your device is covered by Support Services.