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 mithilfe der CLI (Standardkonfigurationen)

Beitragende

Die bevorzugte Upgrade-Methode ist automatisiertes Upgrade mithilfe von System Manager. Wenn System Manager Ihre Konfiguration nicht unterstützt, können Sie über die ONTAP Befehlszeilenschnittstelle (CLI) ein manuelles, unterbrechungsfreies Upgrade durchführen. Um ein Cluster von zwei oder mehr Nodes mithilfe der manuellen unterbrechungsfreien Methode zu aktualisieren, müssen Sie bei jedem Node in einem HA-Paar einen Failover-Vorgang initiieren, den Node „failed“ aktualisieren, die Rückgabe initiieren und den Prozess für jedes HA-Paar im Cluster wiederholen.

Bevor Sie beginnen

Sie müssen ein zufriedenes Upgrade haben "Vorbereitung" Bedingungen:

Aktualisieren des ersten Node in einem HA-Paar

Sie können den ersten Node in einem HA-Paar aktualisieren, indem Sie ein Takeover durch den Partner des Node initiieren. Der Partner stellt die Daten des Node bereit, während ein Upgrade des ersten Node durchgeführt wird.

Bei einem umfassenden Upgrade muss der erste zu aktualisierende Node derselbe Node sein, auf dem Sie die Daten-LIFs für externe Konnektivität konfiguriert und das erste ONTAP Image installiert haben.

Nach dem Upgrade des ersten Node sollten Sie so schnell wie möglich ein Upgrade des Partner-Nodes durchführen. Lassen Sie nicht zu, dass die beiden Knoten in einem bleiben "Gemischte Version" Geben Sie den Status länger als erforderlich ein.

Schritte
  1. Aktualisieren Sie den ersten Node im Cluster, indem Sie eine AutoSupport Meldung aufrufen:

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

    Diese AutoSupport-Benachrichtigung enthält eine Aufzeichnung des Systemstatus direkt vor dem Update. Es speichert nützliche Informationen zur Fehlerbehebung, falls ein Problem mit dem Aktualisierungsprozess auftritt.

    Wenn das Cluster nicht zum Senden von AutoSupport Meldungen konfiguriert ist, wird eine Kopie der Benachrichtigung lokal gespeichert.

  2. Stellen Sie die Berechtigungsebene auf Erweitert ein, und geben Sie bei Aufforderung * y* ein, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (`*>`Erscheint.

  3. Legen Sie das neue ONTAP Software-Image als Standard-Image fest:

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

    Der Befehl zum Ändern des System-Images wird mithilfe einer erweiterten Abfrage das neue ONTAP Software-Image (das als alternatives Image installiert wird) auf das Standard-Image des Node geändert.

  4. Überwachen Sie den Fortschritt des Updates:

    system node upgrade-revert show
  5. Vergewissern Sie sich, dass 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 Standard-Image 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. Deaktivieren Sie das automatische Giveback auf dem Partner-Knoten, wenn er aktiviert ist:

    storage failover modify -node nodenameB -auto-giveback false

    Wenn es sich um ein Cluster mit zwei Knoten handelt, wird eine Meldung angezeigt, die Sie darauf hingewiesen, dass durch die Deaktivierung des automatischen Giveback verhindert wird, dass die Management-Cluster-Services im Falle eines doppelten Ausfalls online geschaltet werden. Eingabe y Um fortzufahren.

  7. Überprüfen Sie, ob das automatische Giveback für den Partner von Nodes 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 zu ermitteln, ob der zu aktualisiere Node derzeit alle Clients bereitstellt

    system node run -node nodenameA -command uptime

    Der Befehl Uptime zeigt die Gesamtzahl der Vorgänge an, die der Node seit dem letzten Booten des Node für NFS-, SMB-, FC- und iSCSI-Clients durchgeführt hat. Für jedes Protokoll müssen Sie den Befehl zweimal ausführen, um festzustellen, ob die Anzahl der Vorgänge steigt. Wenn der Node hinzugefügt wird, bietet er derzeit Clients für dieses Protokoll. Wenn sie nicht erhöht werden, stellt der Node derzeit keine Clients für dieses Protokoll bereit.

    Hinweis Notieren Sie sich jedes Protokoll, bei dem der Client-Betrieb zunimmt, damit Sie nach der Aktualisierung des Node überprüfen können, ob der Client-Datenverkehr wieder aufgenommen wurde.

    Im folgenden Beispiel wird ein Node mit NFS-, SMB-, FC- und iSCSI-Vorgängen angezeigt. Der Node bietet jedoch 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. Migrieren Sie alle Daten-LIFs vom Node weg:

    network interface migrate-all -node nodenameA
  10. Überprüfen Sie alle migrierten LIFs:

    network interface show

    Weitere Informationen zu Parametern, die Sie zum Überprüfen des LIF-Status verwenden können, finden Sie in der Netzwerkschnittstelle show-man-Page.

    Das folgende Beispiel zeigt, dass die Daten-LIFs von Node0 erfolgreich migriert wurden. In den in diesem Beispiel enthaltenen Feldern können Sie für jede LIF die Home-Node und -Port des LIF, den aktuellen Node und Port, zu dem die LIF migriert wurde, sowie den Betriebs- und Administrationsstatus der logischen Schnittstelle überprüfen.

    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. Übernahme initiieren:

    storage failover takeover -ofnode nodenameA

    Geben Sie nicht den Parameter -Option sofortige an, da für den Node, der übernommen wird, um auf das neue Software-Image zu booten, eine normale Übernahme erforderlich ist. Wenn Sie die LIFs nicht manuell vom Node weg migrieren haben, werden sie automatisch zum HA-Partner des Node migriert, um sicherzustellen, dass keine Service-Unterbrechungen auftreten.

    Der erste Node bootet bis zum Status „Warten auf Giveback“.

    Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport Meldung gesendet, die angibt, dass der Node nicht über das Cluster-Quorum verfügt. Sie können diese Benachrichtigung ignorieren und mit der Aktualisierung fortfahren.
  12. Vergewissern Sie sich, dass die Übernahme erfolgreich ist:

    storage failover show

    Möglicherweise werden Fehlermeldungen bezüglich Versionsfehler und Problemen im Postfachformat angezeigt. Dieses Verhalten wird erwartet und stellt in einem größeren unterbrechungsfreien Upgrade einen temporären Zustand dar und ist nicht schädlich.

    Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Node node0 wartet auf Giveback-Status, und sein Partner befindet sich im Übernahmemodus.

    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. Warten Sie mindestens acht Minuten, bis die folgenden Bedingungen erfüllt sind:

    • Das Client-Multipathing (falls bereitgestellt) wird stabilisiert.

    • Clients werden nach der Pause bei einem I/O-Vorgang während der Übernahme wiederhergestellt.

      Die Recovery-Zeit ist Client-spezifisch und kann je nach Eigenschaften der Client-Applikationen länger als acht Minuten dauern.

  14. Rückgabe der Aggregate an den ersten Node:

    storage failover giveback –ofnode nodenameA

    Das Giveback gibt zuerst das Root-Aggregat an den Partner-Node zurück und liefert anschließend, nachdem der Knoten vollständig gebootet wurde, die nicht-Root-Aggregate und alle LIFs zurück, die auf die automatische Wiederherstellung festgelegt wurden. Der neu gestartete Node beginnt, Clients von jedem Aggregat Daten bereitzustellen, sobald das Aggregat zurückgegeben wird.

  15. Überprüfen Sie, ob alle Aggregate zurückgegeben wurden:

    storage failover show-giveback

    Wenn das Feld „GiveBack Status“ angibt, dass keine Aggregate zurückgegeben werden müssen, wurden alle Aggregate zurückgegeben. Wenn ein Giveback vetoed ist, zeigt der Befehl den Status des Giveback an und welches Subsystem das Giveback vetoed hat.

  16. Wenn keine Aggregate zurückgegeben wurden, führen Sie die folgenden Schritte aus:

    1. Überprüfen Sie die Veto-Problemumgehung, um festzustellen, ob Sie die Bedingung „vebis“ beheben oder das Veto außer Kraft setzen möchten.

    2. Falls erforderlich, beheben Sie die in der Fehlermeldung beschriebene Bedingung „veto“, um sicherzustellen, dass alle identifizierten Operationen ordnungsgemäß beendet werden.

    3. Führen Sie den Befehl für die Rückgabe des Storage-Failovers erneut aus.

      Wenn Sie sich entschieden haben, die Bedingung „vebis“ zu überschreiben, setzen Sie den Parameter -override-Vetoes auf „true“.

  17. Warten Sie mindestens acht Minuten, bis die folgenden Bedingungen erfüllt sind:

    • Das Client-Multipathing (falls bereitgestellt) wird stabilisiert.

    • Clients werden im Rahmen eines I/O-Vorgangs während der Rückgabe aus der Pause wiederhergestellt.

      Die Recovery-Zeit ist Client-spezifisch und kann je nach Eigenschaften der Client-Applikationen länger als acht Minuten dauern.

  18. Vergewissern Sie sich, dass das Update für den Node erfolgreich abgeschlossen wurde:

    1. Gehen Sie zur erweiterten Berechtigungsebene :

      set -privilege advanced
    2. Vergewissern Sie sich, dass der Aktualisierungsstatus für den Node abgeschlossen ist:

      system node upgrade-revert show -node nodenameA

      Der Status sollte als „vollständig“ aufgeführt sein.

    Wenn der Status nicht abgeschlossen ist, wenden Sie sich an den technischen Support.

    1. Zurück zur Administratorberechtigungsebene:

      set -privilege admin
  19. Vergewissern Sie sich, dass die Ports des Node aktiv sind:

    network port show -node nodenameA

    Sie müssen diesen Befehl auf einem Node ausführen, der auf die höhere Version von ONTAP 9 aktualisiert wird.

    Im folgenden Beispiel werden alle Ports des Node aktiv sein:

    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. Zurücksetzen der LIFs zurück auf den Node:

    network interface revert *

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

    cluster1::> network interface revert *
    8 entries were acted on.
  21. Vergewissern Sie sich, dass die Daten-LIFs des Node erfolgreich wieder auf den Node zurückgesetzt wurden und dass sie den folgenden Zustand aufweisen:

    network interface show

    Im folgenden Beispiel wird gezeigt, dass alle von dem Node gehosteten Daten-LIFs erfolgreich wieder auf den Node 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     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 Node Clients bereitstellt, überprüfen Sie, ob der Node für jedes Protokoll, das er zuvor bereitstellt, Service bereitstellt:

    system node run -node nodenameA -command uptime

    Während der Aktualisierung wird die Funktion auf Null zurückgesetzt.

    Das folgende Beispiel zeigt, dass der aktualisierte Node 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. Automatisches Giveback auf dem Partner-Knoten wieder aktivieren, wenn er zuvor deaktiviert war:

    storage failover modify -node nodenameB -auto-giveback true

Sie sollten fortfahren, so schnell wie möglich den HA-Partner des Node zu aktualisieren. Wenn Sie den Aktualisierungsprozess aus irgendeinem Grund unterbrechen müssen, sollten beide Nodes im HA-Paar auf derselben ONTAP-Version ausgeführt werden.

Aktualisieren des Partner-Node in einem HA-Paar

Nach der Aktualisierung des ersten Node in einem HA-Paar aktualisieren Sie seinen Partner, indem Sie ein Takeover darauf initiieren. Der erste Node stellt die Daten des Partners bereit, während ein Upgrade des Partner-Node durchgeführt wird.

  1. Stellen Sie die Berechtigungsebene auf Erweitert ein, und geben Sie bei Aufforderung * y* ein, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (`*>`Erscheint.

  2. Legen Sie das neue ONTAP Software-Image als Standard-Image fest:

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

    Der Befehl zum Ändern des System-Images wird mithilfe einer erweiterten Abfrage das neue ONTAP Software-Image (das als alternatives Image installiert wird) als Standard-Image des Node geändert.

  3. Überwachen Sie den Fortschritt des Updates:

    system node upgrade-revert show
  4. Vergewissern Sie sich, dass das neue ONTAP Software-Image als Standard-Image festgelegt ist:

    system image show

    Im folgenden Beispiel: image2 Ist die neue Version von ONTAP und wird als Standard-Image auf dem Node 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. Deaktivieren Sie das automatische Giveback auf dem Partner-Knoten, wenn er aktiviert ist:

    storage failover modify -node nodenameA -auto-giveback false

    Wenn es sich um ein Cluster mit zwei Knoten handelt, wird eine Meldung angezeigt, die Sie darauf hingewiesen, dass durch die Deaktivierung des automatischen Giveback verhindert wird, dass die Management-Cluster-Services im Falle eines doppelten Ausfalls online geschaltet werden. Eingabe y Um fortzufahren.

  6. Überprüfen Sie, ob das automatische Giveback für den Partner-Knoten 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 zweimal den folgenden Befehl aus, um zu ermitteln, ob der zu aktualisiere Node derzeit alle Clients bereitstellt:

    system node run -node nodenameB -command uptime

    Der Befehl Uptime zeigt die Gesamtzahl der Vorgänge an, die der Node seit dem letzten Booten des Node für NFS-, SMB-, FC- und iSCSI-Clients durchgeführt hat. Für jedes Protokoll müssen Sie den Befehl zweimal ausführen, um festzustellen, ob die Anzahl der Vorgänge steigt. Wenn der Node hinzugefügt wird, bietet er derzeit Clients für dieses Protokoll. Wenn sie nicht erhöht werden, stellt der Node derzeit keine Clients für dieses Protokoll bereit.

    HINWEIS: Sie sollten jedes Protokoll mit zunehmenden Client-Operationen notieren, damit Sie nach der Aktualisierung des Knotens überprüfen können, ob der Client-Datenverkehr wieder aufgenommen wurde.

    Im folgenden Beispiel wird ein Node mit NFS-, SMB-, FC- und iSCSI-Vorgängen angezeigt. Der Node bietet jedoch 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. Migrieren Sie alle Daten-LIFs vom Node weg:

    network interface migrate-all -node nodenameB
  9. Überprüfen Sie den Status aller zu migrierenden LIFs:

    network interface show

    Weitere Informationen zu Parametern, die Sie zum Überprüfen des LIF-Status verwenden können, finden Sie in der Netzwerkschnittstelle show-man-Page.

    Das folgende Beispiel zeigt, dass die Daten-LIFs von Node1 erfolgreich migriert wurden. In den in diesem Beispiel enthaltenen Feldern können Sie für jede LIF die Home-Node und -Port des LIF, den aktuellen Node und Port, zu dem die LIF migriert wurde, sowie den Betriebs- und Administrationsstatus der logischen Schnittstelle überprüfen.

    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. Übernahme initiieren:

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

    Geben Sie nicht den Parameter -Option sofortige an, da für den Node, der übernommen wird, um auf das neue Software-Image zu booten, eine normale Übernahme erforderlich ist. Wenn Sie die LIFs nicht manuell vom Node weg migriert haben, werden sie automatisch zum HA-Partner des Node migriert, damit keine Service-Unterbrechungen auftreten.

    Eine Warnung wird angezeigt. Eingabe ist erforderlich y Um fortzufahren.

    Der Knoten, der über wird gestartet bis zum Status „Warten auf Giveback“.

    Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport Meldung gesendet, die angibt, dass der Node nicht über das Cluster-Quorum verfügt. Sie können diese Benachrichtigung ignorieren und mit der Aktualisierung fortfahren.
  11. Vergewissern Sie sich, dass die Übernahme erfolgreich war:

    storage failover show

    Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Node Node1 befindet sich im Status „Warten auf Giveback“, und sein Partner befindet sich im Übernahmemodus.

    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. Warten Sie mindestens acht Minuten, bis die folgenden Bedingungen erfüllt sind:

    + Das Client-Multipathing (falls bereitgestellt) wird stabilisiert. Clients werden nach der Pause des I/O, die während der Übernahme stattfindet, wiederhergestellt.

    + Die Recovery-Zeit ist Client-spezifisch und kann je nach Eigenschaften der Client-Applikationen länger als acht Minuten dauern.

  13. Rückgabe der Aggregate an den Partner-Node:

    storage failover giveback -ofnode nodenameB

    Der Giveback-Vorgang gibt zuerst das Root-Aggregat an den Partner-Node zurück und liefert dann, nachdem der Knoten vollständig gebootet wurde, die nicht-Root-Aggregate und alle LIFs zurück, die auf die automatische Wiederherstellung festgelegt wurden. Der neu gestartete Node beginnt, Clients von jedem Aggregat Daten bereitzustellen, sobald das Aggregat zurückgegeben wird.

  14. Überprüfen Sie, ob alle Aggregate zurückgegeben werden:

    storage failover show-giveback

    Wenn das Feld „GiveBack Status“ angibt, dass keine Aggregate zurückgegeben werden müssen, werden alle Aggregate zurückgegeben. Wenn ein Giveback vetoed ist, zeigt der Befehl den Status der Rückgabe an und welches Subsystem den Giveback-Vorgang gebietet hat.

  15. Wenn keine Aggregate zurückgegeben werden, führen Sie die folgenden Schritte aus:

    1. Überprüfen Sie die Veto-Problemumgehung, um festzustellen, ob Sie die Bedingung „vebis“ beheben oder das Veto außer Kraft setzen möchten.

    2. Falls erforderlich, beheben Sie die in der Fehlermeldung beschriebene Bedingung „veto“, um sicherzustellen, dass alle identifizierten Operationen ordnungsgemäß beendet werden.

    3. Führen Sie den Befehl für die Rückgabe des Storage-Failovers erneut aus.

      Wenn Sie sich entschieden haben, die Bedingung „vebis“ zu überschreiben, setzen Sie den Parameter -override-Vetoes auf „true“.

  16. Warten Sie mindestens acht Minuten, bis die folgenden Bedingungen erfüllt sind:

    • Das Client-Multipathing (falls bereitgestellt) wird stabilisiert.

    • Clients werden im Rahmen eines I/O-Vorgangs während der Rückgabe aus der Pause wiederhergestellt.

      Die Recovery-Zeit ist Client-spezifisch und kann je nach Eigenschaften der Client-Applikationen länger als acht Minuten dauern.

  17. Vergewissern Sie sich, dass das Update für den Node erfolgreich abgeschlossen wurde:

    1. Gehen Sie zur erweiterten Berechtigungsebene :

      set -privilege advanced
    2. Vergewissern Sie sich, dass der Aktualisierungsstatus für den Node abgeschlossen ist:

      system node upgrade-revert show -node nodenameB

      Der Status sollte als „vollständig“ aufgeführt sein.

    Wenn der Status nicht abgeschlossen ist, führen Sie den Upgrade-Befehl für den System-Node „Upgrade revert“ aus. Wenn das Update mit dem Befehl nicht abgeschlossen wird, wenden Sie sich an den technischen Support.

    1. Zurück zur Administratorberechtigungsebene:

      set -privilege admin
  18. Vergewissern Sie sich, dass die Ports des Node aktiv sind:

    network port show -node nodenameB

    Sie müssen diesen Befehl auf einem Node ausführen, der auf ONTAP 9.4 aktualisiert wurde.

    Im folgenden Beispiel werden alle Daten-Ports des Node aktiv sein:

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

    network interface revert *

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

    cluster1::> network interface revert *
    8 entries were acted on.
  20. Vergewissern Sie sich, dass die Daten-LIFs des Node erfolgreich wieder auf den Node zurückgesetzt wurden und dass sie den folgenden Zustand aufweisen:

    network interface show

    Im folgenden Beispiel wird gezeigt, dass alle von dem Node gehosteten Daten-LIFs erfolgreich wieder auf den Node zurückgesetzt werden 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 Node Clients bereitstellt, überprüfen Sie, ob der Node für jedes Protokoll, das er zuvor bereitstellt, Service bereitstellt:

    system node run -node nodenameB -command uptime

    Während der Aktualisierung wird die Funktion auf Null zurückgesetzt.

    Das folgende Beispiel zeigt, dass der aktualisierte Node 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 Node im Cluster war, der aktualisiert werden soll, lösen Sie eine AutoSupport-Benachrichtigung aus:

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

    Diese AutoSupport-Benachrichtigung enthält eine Aufzeichnung des Systemstatus direkt vor dem Update. Es speichert nützliche Informationen zur Fehlerbehebung, falls ein Problem mit dem Aktualisierungsprozess auftritt.

    Wenn das Cluster nicht zum Senden von AutoSupport Meldungen konfiguriert ist, wird eine Kopie der Benachrichtigung lokal gespeichert.

  23. Vergewissern Sie sich, dass die neue ONTAP Software auf beiden Nodes 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. Automatisches Giveback auf dem Partner-Knoten wieder aktivieren, wenn er zuvor deaktiviert war:

    storage failover modify -node nodenameA -auto-giveback true
  25. Überprüfen Sie mithilfe des, ob sich der Cluster im Quorum befindet und ob Services ausgeführt werden cluster show Und cluster ring show (Erweiterte Berechtigungsebene) Befehle.

    Sie müssen diesen Schritt durchführen, bevor Sie weitere HA-Paare aktualisieren.

  26. Zurück zur Administratorberechtigungsebene:

    set -privilege admin
  27. Aktualisieren Sie alle zusätzlichen HA-Paare.