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)

09/23/2024 Beitragende

PDFs

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 die Upgrade-"Vorbereitung"Anforderungen erfüllen.

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 "Gemischte Version"zu, dass die beiden Nodes länger als erforderlich in einem Status bleiben.

Schritte

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.
Stellen Sie die Berechtigungsebene auf Erweitert ein, und geben Sie bei Aufforderung * y* ein, um fortzufahren:
```
set -privilege advanced
```
Die erweiterte Eingabeaufforderung (*>) wird angezeigt.
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.
Überwachen Sie den Fortschritt des Updates:
```
system node upgrade-revert show
```

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.

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. Geben Sie ein, y um fortzufahren.

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

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.

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

Migrieren Sie alle Daten-LIFs vom Node weg:

network interface migrate-all -node nodenameA

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

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

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.

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. Knoten node0 befindet sich im Status Warten auf Rückgabe, und sein Partner befindet sich im Übernahmestatus.
```
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.
```
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.
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.
Ü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.
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“.
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.
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

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.

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

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.

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

Stellen Sie die Berechtigungsebene auf Erweitert ein, und geben Sie bei Aufforderung * y* ein, um fortzufahren:
```
set -privilege advanced
```
Die erweiterte Eingabeaufforderung (*>) wird angezeigt.
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.
Überwachen Sie den Fortschritt des Updates:
```
system node upgrade-revert show
```

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

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. Geben Sie ein, y um fortzufahren.

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

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.

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

Migrieren Sie alle Daten-LIFs vom Node weg:

network interface migrate-all -node nodenameB

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

Ü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. Sie müssen eingeben y, um fortzufahren.

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

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.

Warten Sie mindestens acht Minuten, bis die folgenden Bedingungen wirksam werden:
- 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.
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.
Ü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.
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“.
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.
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 vollständig lautet, führen Sie den system node upgrade-revert upgrade Befehl vom Node 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

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.

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

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.

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

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.

Automatisches Giveback auf dem Partner-Knoten wieder aktivieren, wenn er zuvor deaktiviert war:
```
storage failover modify -node nodenameA -auto-giveback true
```
Überprüfen Sie mithilfe der cluster show cluster ring show Befehle und (Erweiterte Berechtigungsebene), ob das Cluster im Quorum ist und ob Services ausgeführt werden.

Sie müssen diesen Schritt durchführen, bevor Sie weitere HA-Paare aktualisieren.
Zurück zur Administratorberechtigungsebene:
```
set -privilege admin
```
Aktualisieren Sie alle zusätzlichen HA-Paare.

Manuelles, unterbrechungsfreies ONTAP Upgrade mithilfe der CLI (Standardkonfigurationen)

Creating your file...

Aktualisieren des ersten Node in einem HA-Paar

Aktualisieren des Partner-Node in einem HA-Paar