Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Manuelles unterbrechungsfreies ONTAP Upgrade mit der CLI (Standardkonfigurationen)

Beitragende netapp-aherbin netapp-aaron-holt netapp-dbagwell netapp-ahibbard netapp-forry
Änderungen vorschlagen
PDFs

Die automatisierte Aktualisierung mit System Manager ist die bevorzugte Upgrade-Methode. Wenn System Manager Ihre Konfiguration nicht unterstützt, kann die ONTAP Befehlszeilenschnittstelle (CLI) für ein manuelles unterbrechungsfreies Upgrade verwendet werden. Für das Upgrade eines Clusters mit zwei oder mehr Nodes mittels der manuellen unterbrechungsfreien Methode ist es erforderlich, auf jedem Node eines HA-Paars einen Failover-Vorgang zu initiieren, den „failed“-Node zu aktualisieren, die Rückgabe zu starten und diesen Prozess für jedes HA-Paar im Cluster zu wiederholen.

Bevor Sie beginnen

Die Upgrade-"Vorbereitung"Anforderungen müssen erfüllt sein.

Aktualisierung des ersten Knotens in einem HA-Paar

Sie können den ersten Knoten eines HA-Paares aktualisieren, indem eine Übernahme durch den Partnerknoten eingeleitet wird. Der Partnerknoten stellt die Daten des ersten Knotens bereit, während dieser aktualisiert wird.

Wenn Sie ein größeres Upgrade durchführen, muss der erste zu aktualisierende Knoten derselbe Knoten sein, auf dem Sie die Daten-LIFs für die externe Konnektivität konfiguriert und das erste ONTAP Image installiert haben.

Nach dem Upgrade des ersten Knotens sollte der Partnerknoten so schnell wie möglich aktualisiert werden. Die beiden Knoten sollten sich nicht länger als nötig in einem "gemischte Version" Zustand befinden.

Schritte

  1. Der erste Node im Cluster wird aktualisiert, indem eine AutoSupport-Nachricht ausgelöst wird:

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

    Diese AutoSupport Benachrichtigung enthält einen Datensatz des Systemstatus unmittelbar vor dem Update. Es werden nützliche Informationen zur Fehlerbehebung gespeichert, falls ein Problem mit dem Update-Prozess auftritt.

    Wenn der Cluster nicht für den Versand von AutoSupport-Nachrichten konfiguriert ist, wird eine Kopie der Benachrichtigung lokal gespeichert.

  2. Die Berechtigungsstufe wird auf „Erweitert“ gesetzt, wobei bei entsprechender Aufforderung y einzugeben ist, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (*>) erscheint.

  3. Das neue ONTAP Software-Image als Standard-Image festlegen:

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

    Der Befehl „system image modify“ verwendet eine erweiterte Abfrage, um das neue ONTAP Software-Image (das als alternatives Image installiert wird) in das Standard-Image für den Node zu ändern.

  4. Der Fortschritt des Updates kann überwacht werden:

    system node upgrade-revert show

  5. Es sollte überprüft werden, ob das neue ONTAP Software-Image als Standard-Image festgelegt ist:

    system image show

    Im folgenden Beispiel ist image2 die neue ONTAP Version und wird als Standardimage auf node0 festgelegt:

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

  6. Die automatische Rückgabe auf dem Partner-Node ist zu deaktivieren, falls sie aktiviert ist:

    storage failover modify -node nodenameB -auto-giveback false

    Wenn es sich bei dem Cluster um ein Zwei-Node-Cluster handelt, wird eine Meldung angezeigt, die darauf hinweist, dass das Deaktivieren der automatischen Rückgabe verhindert, dass die Management-Cluster-Services im Falle eines alternierenden Ausfallszenarios online gehen. Geben Sie y ein, um fortzufahren.

  7. Es sollte überprüft werden, ob das automatische Giveback für den Partner des Knotens deaktiviert ist:

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

  8. Führen Sie den folgenden Befehl zweimal aus, um festzustellen, ob der zu aktualisierende Node derzeit Clients bedient

    system node run -node nodenameA -command uptime

    Der Befehl uptime zeigt die Gesamtzahl der Operationen an, die der Knoten seit dem letzten Start für NFS, SMB, FC und iSCSI Clients ausgeführt hat. Für jedes Protokoll muss der Befehl zweimal ausgeführt werden, um festzustellen, ob die Anzahl der Operationen steigt. Wenn sie steigt, bedient der Knoten derzeit Clients für dieses Protokoll. Wenn sie nicht steigt, bedient der Knoten derzeit keine Clients für dieses Protokoll.

    Hinweis Es empfiehlt sich, jedes Protokoll zu notieren, bei dem die Client-Operationen zunehmen, sodass nach der Aktualisierung des Knotens überprüft werden kann, ob der Client-Datenverkehr wieder aufgenommen wurde.

    Das folgende Beispiel zeigt einen Knoten mit NFS-, SMB-, FC- und iSCSI-Operationen. Allerdings bedient der Knoten derzeit nur NFS- und iSCSI-Clients.

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

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

  9. Alle Daten-LIFs vom Knoten migrieren:

    network interface migrate-all -node nodenameA

  10. Alle migrierten LIFs überprüfen:

    network interface show

    Weitere Informationen zu network interface show und zu Parametern, mit denen der LIF-Status überprüft werden kann, finden Sie im "ONTAP-Befehlsreferenz".

    Das folgende Beispiel zeigt, dass die Data-LIFs von node0 erfolgreich migriert wurden. Für jede LIF ermöglichen die in diesem Beispiel enthaltenen Felder die Überprüfung des Home-Nodes und Ports der LIF, des aktuellen Nodes und Ports, zu dem die LIF migriert wurde, sowie des Betriebs- und Verwaltungsstatus der LIF.

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

  11. Eine Übernahme initiieren:

    storage failover takeover -ofnode nodenameA

    Geben Sie den Parameter „-option immediate“ nicht an, da für den zu übernehmenden Knoten ein normaler Übernahmevorgang erforderlich ist, damit der Knoten mit dem neuen Software-Image startet. Wenn die LIFs nicht manuell vom Knoten migriert wurden, migrieren sie automatisch zum HA-Partner des Knotens, sodass keine Serviceunterbrechungen auftreten.

    Der erste Knoten startet im Zustand „Warten auf Rückgabe“.

    Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport-Meldung gesendet, die darauf hinweist, dass der Knoten das Cluster-Quorum verlassen hat. Diese Benachrichtigung kann ignoriert und das Update fortgesetzt werden.

  12. Es sollte überprüft werden, ob die Übernahme erfolgreich war:

    storage failover show

    Möglicherweise werden Fehlermeldungen angezeigt, die auf Versionskonflikte und Probleme mit dem Postfachformat hinweisen. Dies ist ein erwartetes Verhalten und stellt einen vorübergehenden Zustand während eines größeren unterbrechungsfreien Upgrades dar und ist unbedenklich.

    Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Knoten node0 befindet sich im Zustand „Warten auf Rückgabe“, und sein Partner befindet sich im Zustand „In Übernahme“.

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

  13. Mindestens acht Minuten abwarten, bis die folgenden Bedingungen wirksam werden:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Die Clients werden nach einer Unterbrechung einer E/A-Operation, die während einer Übernahme auftritt, wiederhergestellt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  14. Die Aggregate an den ersten Knoten zurückgeben:

    storage failover giveback -ofnode nodenameA

    Der Giveback-Vorgang gibt zunächst das Root-Aggregat an den Partnerknoten zurück und anschließend, nachdem dieser den Startvorgang abgeschlossen hat, die Nicht-Root-Aggregate sowie alle LIFs, die für die automatische Rücksetzung konfiguriert wurden, zurück. Der neu gestartete Knoten beginnt, Daten für Clients aus jedem Aggregat bereitzustellen, sobald das Aggregat zurückgegeben wurde.

  15. Es sollte sichergestellt sein, dass alle Aggregate zurückgegeben wurden:

    storage failover show-giveback

    Wenn das Feld „Rückgabestatus“ anzeigt, dass keine Aggregate zurückzugeben sind, wurden alle Aggregate zurückgegeben. Wenn die Rückgabe abgelehnt wird, zeigt der Befehl den Fortschritt der Rückgabe und das Subsystem an, das die Rückgabe abgelehnt hat.

  16. Wenn einige Aggregate nicht zurückgegeben wurden, sind die folgenden Schritte auszuführen:

    1. Die Vorgehensweise zur Umgehung des Veto-Problems kann herangezogen werden, um zu bestimmen, ob die “veto”-Bedingung behoben oder das Veto außer Kraft gesetzt werden soll.

    2. Falls erforderlich sollte die in der Fehlermeldung beschriebene “veto”-Bedingung behoben werden, wobei sichergestellt wird, dass alle identifizierten Operationen ordnungsgemäß beendet werden.

    3. Den `storage failover giveback`Befehl erneut ausführen.

      Wenn die “veto”-Bedingung außer Kraft gesetzt werden soll, ist der Parameter -override-vetoes auf true zu setzen.

  17. Mindestens acht Minuten abwarten, bis die folgenden Bedingungen wirksam werden:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Clients werden aus der Pause einer E/A-Operation wiederhergestellt, die während der Rückgabe auftritt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  18. Überprüfen, ob die Aktualisierung für den Node erfolgreich abgeschlossen wurde:

    1. Zur erweiterten Berechtigungsstufe wechseln:

      set -privilege advanced

    2. Es wird geprüft, ob der Aktualisierungsstatus für den Knoten abgeschlossen ist:

      system node upgrade-revert show -node nodenameA

      Der Status sollte als abgeschlossen angezeigt werden.

    Wenn der Status nicht vollständig ist, den technischen Support kontaktieren.

    1. Zurück zur Administrator-Privilegstufe:

      set -privilege admin

  19. Es wird geprüft, ob die Ports des Knotens aktiv sind:

    network port show -node nodenameA

    Dieser Befehl muss auf einem Knoten ausgeführt werden, der auf die höhere Version von ONTAP 9 aktualisiert wurde.

    Das folgende Beispiel zeigt, dass alle Ports des Knotens aktiv sind:

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

  20. Die LIFs werden wieder auf den Knoten zurückgesetzt:

    network interface revert *

    Dieser Befehl gibt die LIFs zurück, die vom Knoten migriert wurden.

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

  21. Es sollte überprüft werden, ob die Data-LIFs des Knotens erfolgreich auf den Knoten zurückgekehrt sind und ob sie aktiv sind:

    network interface show

    Das folgende Beispiel zeigt, dass alle vom Knoten gehosteten Daten-LIFs erfolgreich zum Knoten zurückgeführt wurden und ihr Betriebsstatus aktiv ist:

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

  22. Wenn Sie zuvor festgestellt haben, dass dieser Knoten Clients bedient, überprüfen Sie, ob der Knoten für jedes Protokoll, das er zuvor bedient hat, weiterhin Dienste bereitstellt:

    system node run -node nodenameA -command uptime

    Die Vorgangszähler werden während des Updates auf Null zurückgesetzt.

    Das folgende Beispiel zeigt, dass der aktualisierte Knoten seine NFS- und iSCSI-Clients wieder bedient:

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

  23. Die automatische Rückgabe auf dem Partnerknoten wird wieder aktiviert, falls sie zuvor deaktiviert war:

    storage failover modify -node nodenameB -auto-giveback true

Das Update des HA-Partners des Knotens sollte so schnell wie möglich durchgeführt werden. Falls der Aktualisierungsprozess aus irgendeinem Grund unterbrochen werden muss, sollten beide Knoten des HA-Paars dieselbe ONTAP Version ausführen.

Aktualisierung des Partnerknotens in einem HA-Paar

Nach der Aktualisierung des ersten Knotens in einem HA-Paar wird der Partner aktualisiert, indem eine Übernahme auf ihm initiiert wird. Der erste Knoten stellt die Daten des Partners bereit, während der Partnerknoten aktualisiert wird.

  1. Die Berechtigungsstufe wird auf „Erweitert“ gesetzt, wobei bei entsprechender Aufforderung y einzugeben ist, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (*>) erscheint.

  2. Das neue ONTAP Software-Image als Standard-Image festlegen:

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

    Der Befehl „system image modify“ verwendet eine erweiterte Abfrage, um das neue ONTAP Software-Image (das als alternatives Image installiert wird) als Standard-Image für den Knoten festzulegen.

  3. Der Fortschritt des Updates kann überwacht werden:

    system node upgrade-revert show

  4. Es sollte überprüft werden, ob das neue ONTAP Software-Image als Standard-Image festgelegt ist:

    system image show

    Im folgenden Beispiel ist image2 die neue Version von ONTAP und als Standardimage auf dem Knoten festgelegt:

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

  5. Die automatische Rückgabe auf dem Partner-Node ist zu deaktivieren, falls sie aktiviert ist:

    storage failover modify -node nodenameA -auto-giveback false

    Wenn es sich bei dem Cluster um ein Zwei-Node-Cluster handelt, wird eine Meldung angezeigt, die darauf hinweist, dass das Deaktivieren der automatischen Rückgabe verhindert, dass die Management-Cluster-Services im Falle eines alternierenden Ausfallszenarios online gehen. Geben Sie y ein, um fortzufahren.

  6. Es sollte überprüft werden, ob die automatische Rückgabe für den Partnerknoten deaktiviert ist:

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

  7. Führen Sie den folgenden Befehl zweimal aus, um zu ermitteln, ob der zu aktualisierende Knoten derzeit Clients bedient:

    system node run -node nodenameB -command uptime

    Der Befehl uptime zeigt die Gesamtzahl der Operationen an, die der Knoten seit dem letzten Start für NFS, SMB, FC und iSCSI Clients ausgeführt hat. Für jedes Protokoll muss der Befehl zweimal ausgeführt werden, um festzustellen, ob die Anzahl der Operationen steigt. Wenn sie steigt, bedient der Knoten derzeit Clients für dieses Protokoll. Wenn sie nicht steigt, bedient der Knoten derzeit keine Clients für dieses Protokoll.

    Hinweis Es empfiehlt sich, jedes Protokoll zu notieren, bei dem die Client-Operationen zunehmen, sodass nach der Aktualisierung des Knotens überprüft werden kann, ob der Client-Datenverkehr wieder aufgenommen wurde.

    Das folgende Beispiel zeigt einen Knoten mit NFS-, SMB-, FC- und iSCSI-Operationen. Allerdings bedient der Knoten derzeit nur NFS- und iSCSI-Clients.

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

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

  8. Alle Daten-LIFs vom Knoten migrieren:

    network interface migrate-all -node nodenameB

  9. Status aller migrierten LIFs überprüfen:

    network interface show

    Weitere Informationen zu network interface show und zu Parametern, mit denen der LIF-Status überprüft werden kann, finden Sie im "ONTAP-Befehlsreferenz".

    Das folgende Beispiel zeigt, dass die Data-LIFs von node1 erfolgreich migriert wurden. Für jede LIF ermöglichen die in diesem Beispiel enthaltenen Felder die Überprüfung des Home-Nodes und Ports der LIF, des aktuellen Nodes und Ports, zu dem die LIF migriert wurde, sowie des Betriebs- und Verwaltungsstatus der LIF.

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

  10. Eine Übernahme initiieren:

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

    Geben Sie den Parameter „-option immediate“ nicht an, da für den zu übernehmenden Knoten ein normaler Übernahmevorgang erforderlich ist, damit der Knoten mit dem neuen Software-Image startet. Wenn die LIFs nicht manuell vom Knoten migriert wurden, migrieren sie automatisch zum HA-Partner des Knotens, sodass keine Serviceunterbrechungen auftreten.

    Es wird eine Warnung angezeigt. Sie müssen y eingeben, um fortzufahren.

    Der übernommene Knoten startet im Zustand „Warten auf Rückgabe“.

    Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport-Meldung gesendet, die darauf hinweist, dass der Knoten das Cluster-Quorum verlassen hat. Diese Benachrichtigung kann ignoriert und das Update fortgesetzt werden.

  11. Es sollte überprüft werden, ob die Übernahme erfolgreich war:

    storage failover show

    Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Knoten node1 befindet sich im Zustand „Warten auf Rückgabe“, und sein Partner befindet sich im Zustand „In Übernahme“.

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

  12. Mindestens acht Minuten abwarten, damit die folgenden Bedingungen wirksam werden:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Clients werden nach der Unterbrechung der E/A, die während der Übernahme auftritt, wiederhergestellt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  13. Die Aggregate an den Partnerknoten zurückgeben:

    storage failover giveback -ofnode nodenameB

    Der Rückgabevorgang gibt zunächst das Root-Aggregat an den Partnerknoten zurück und anschließend, nachdem dieser den Startvorgang abgeschlossen hat, die Nicht-Root-Aggregate sowie alle LIFs, die für die automatische Rücksetzung konfiguriert wurden. Der neu gestartete Knoten beginnt, Daten für Clients aus jedem Aggregat bereitzustellen, sobald das Aggregat zurückgegeben wurde.

  14. Es wird überprüft, ob alle Aggregate zurückgegeben werden:

    storage failover show-giveback

    Wenn das Feld „Rückgabestatus“ anzeigt, dass keine Aggregate zurückzugeben sind, werden alle Aggregate zurückgegeben. Wenn die Rückgabe abgelehnt wird, zeigt der Befehl den Fortschritt der Rückgabe und das Subsystem an, das die Rückgabe abgelehnt hat.

  15. Wenn keine Aggregate zurückgegeben werden, sind die folgenden Schritte auszuführen:

    1. Die Vorgehensweise zur Umgehung des Veto-Problems kann herangezogen werden, um zu bestimmen, ob die “veto”-Bedingung behoben oder das Veto außer Kraft gesetzt werden soll.

    2. Falls erforderlich sollte die in der Fehlermeldung beschriebene “veto”-Bedingung behoben werden, wobei sichergestellt wird, dass alle identifizierten Operationen ordnungsgemäß beendet werden.

    3. Den `storage failover giveback`Befehl erneut ausführen.

      Wenn die “veto”-Bedingung außer Kraft gesetzt werden soll, ist der Parameter -override-vetoes auf true zu setzen.

  16. Mindestens acht Minuten abwarten, bis die folgenden Bedingungen wirksam werden:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Clients werden aus der Pause einer E/A-Operation wiederhergestellt, die während der Rückgabe auftritt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  17. Überprüfen, ob die Aktualisierung für den Node erfolgreich abgeschlossen wurde:

    1. Zur erweiterten Berechtigungsstufe wechseln:

      set -privilege advanced

    2. Es wird geprüft, ob der Aktualisierungsstatus für den Knoten abgeschlossen ist:

      system node upgrade-revert show -node nodenameB

      Der Status sollte als abgeschlossen angezeigt werden.

    Wenn der Status nicht „Abgeschlossen“ ist, auf dem Knoten den system node upgrade-revert upgrade Befehl ausführen. Wenn der Befehl die Aktualisierung nicht abschließt, den technischen Support kontaktieren.

    1. Zurück zur Administrator-Privilegstufe:

      set -privilege admin

  18. Es wird geprüft, ob die Ports des Knotens aktiv sind:

    network port show -node nodenameB

    Dieser Befehl muss auf einem Knoten ausgeführt werden, der auf ONTAP 9.4 aktualisiert wurde.

    Das folgende Beispiel zeigt, dass alle Daten-Ports des Knotens aktiv sind:

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

    Weitere Informationen zu network port show finden sich in der "ONTAP-Befehlsreferenz".

  19. Die LIFs werden wieder auf den Knoten zurückgesetzt:

    network interface revert *

    Dieser Befehl gibt die LIFs zurück, die vom Knoten migriert wurden.

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

  20. Es sollte überprüft werden, ob die Data-LIFs des Knotens erfolgreich auf den Knoten zurückgekehrt sind und ob sie aktiv sind:

    network interface show

    Das folgende Beispiel zeigt, dass alle vom Knoten gehosteten Daten-LIFs erfolgreich auf den Knoten zurückgesetzt wurden und dass ihr Betriebsstatus aktiv ist:

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

  21. Wenn Sie zuvor festgestellt haben, dass dieser Knoten Clients bedient, überprüfen Sie, ob der Knoten für jedes Protokoll, das er zuvor bedient hat, weiterhin Dienste bereitstellt:

    system node run -node nodenameB -command uptime

    Die Vorgangszähler werden während des Updates auf Null zurückgesetzt.

    Das folgende Beispiel zeigt, dass der aktualisierte Knoten seine NFS- und iSCSI-Clients wieder bedient:

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

  22. Wenn dies der letzte Knoten im Cluster war, der aktualisiert wurde, eine AutoSupport-Benachrichtigung auslösen:

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

    Diese AutoSupport Benachrichtigung enthält einen Datensatz des Systemstatus unmittelbar vor dem Update. Es werden nützliche Informationen zur Fehlerbehebung gespeichert, falls ein Problem mit dem Update-Prozess auftritt.

    Wenn der Cluster nicht für den Versand von AutoSupport-Nachrichten konfiguriert ist, wird eine Kopie der Benachrichtigung lokal gespeichert.

  23. Bestätigen Sie, dass die neue ONTAP Software auf beiden Knoten des HA-Paars ausgeführt wird:

    set -privilege advanced
    system node image show

    Im folgenden Beispiel ist image2 die aktualisierte Version von ONTAP und die Standardversion auf beiden Knoten:

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

  24. Die automatische Rückgabe auf dem Partnerknoten wird wieder aktiviert, falls sie zuvor deaktiviert war:

    storage failover modify -node nodenameA -auto-giveback true

  25. Es kann überprüft werden, ob sich der Cluster im Quorum befindet und die Dienste ausgeführt werden, indem die Befehle cluster show und cluster ring show (erweiterte Berechtigungsstufe) verwendet werden.

    Dieser Schritt ist vor dem Upgrade weiterer HA-Paare erforderlich.

    Weitere Informationen zu cluster show und cluster ring show finden sich in der "ONTAP-Befehlsreferenz".

  26. Zurück zur Administrator-Privilegstufe:

    set -privilege admin

  27. Alle zusätzlichen HA-Paare aktualisieren.

Verwandte Informationen