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

Bereiten Sie die Knoten für ein Upgrade vor

12/06/2024 Beitragende

PDFs

Bevor Sie die ursprünglichen Nodes ersetzen können, müssen Sie bestätigen, dass sich die Nodes in einem HA-Paar befinden, dass keine fehlenden oder ausgefallenen Festplatten vorhanden sind, auf den Storage der jeweils anderen Nodes zugreifen können und keine Daten-LIFs besitzen, die den anderen Nodes im Cluster zugewiesen sind. Sie müssen auch Informationen über die ursprünglichen Nodes sammeln und bestätigen, dass alle Knoten im Cluster Quorum sind, wenn sich der Cluster in einer SAN-Umgebung befindet.

Schritte

Vergewissern Sie sich, dass jeder der ursprünglichen Nodes über ausreichende Ressourcen verfügt, um den Workload beider Nodes im Übernahmemodus angemessen zu unterstützen.

Unter "Quellen" finden Sie einen Link zum HA-Paar-Management und befolgen Sie die Best Practices für HA-Paare Abschnitt. Keine der ursprünglichen Nodes sollte mit einer Auslastung von über 50 % laufen. Wenn ein Node eine Auslastung von unter 50 % aufweist, kann er die Lasten für beide Nodes während des Controller-Upgrades verarbeiten.

Führen Sie die folgenden Teilschritte durch, um eine Performance-Baseline für die ursprünglichen Nodes zu erstellen:

Stellen Sie sicher, dass das Benutzerkonto für den Diagnosebenutzer entsperrt ist.

Das diagnostische Benutzerkonto ist nur für diagnostische Zwecke auf niedriger Ebene gedacht und sollte nur unter Anleitung durch den technischen Support verwendet werden.

Informationen zum Entsperren der Benutzerkonten finden Sie unter "Quellen" Verknüpfen mit der Referenz Systemadministration.

Siehe "Quellen" Wenn Sie einen Link zur NetApp Support-Website_ erhalten möchten, können Sie den Performance and Statistics Collector (Perfstat Converged) herunterladen.

Mit dem konvergenten Perfstat Tool können Sie eine Performance-Baseline für den Vergleich nach dem Upgrade erstellen.
Erstellen Sie eine Performance-Baseline gemäß den Anweisungen auf der NetApp Support Site.

Siehe "Quellen" Einen Link zur NetApp Support Site_ öffnen und einen Support-Case auf der NetApp Support Site eröffnen.

Sie können den Fall verwenden, um eventuelle Probleme während des Upgrades zu melden.
Überprüfen Sie, ob NVMEM oder NVRAM-Batterien der Node3 und node4 geladen sind, und laden Sie sie, falls nicht, auf.

Sie müssen Node 3 und node4 physisch überprüfen, um zu ermitteln, ob die NVMEM- oder NVRAM-Batterien geladen sind. Informationen zu den LEDs für das Modell node3 und node4 finden Sie unter "Quellen" Zum Verknüpfen mit der Hardware Universe.

Achtung Versuchen Sie nicht, den NVRAM-Inhalt zu löschen. Wenn der Inhalt des NVRAM gelöscht werden muss, wenden Sie sich an den technischen Support von NetApp.
Überprüfen Sie die Version von ONTAP auf node3 und node4.

Die neuen Knoten müssen auf ihren ursprünglichen Knoten dieselbe Version von ONTAP 9.x installiert sein. Wenn die neuen Nodes über eine andere Version der ONTAP installiert sind, müssen Sie die neuen Controller nach der Installation neu laden. Anweisungen zum Upgrade von ONTAP finden Sie unter "Quellen" Link zu Upgrade ONTAP.

Informationen über die Version von ONTAP auf node3 und node4 sollten in den Versandkartons enthalten sein. Die ONTAP-Version wird angezeigt, wenn der Node hochgefahren wird oder Sie können den Node im Wartungsmodus booten und den Befehl ausführen:

version

Überprüfen Sie, ob Sie zwei oder vier Cluster LIFs auf node1 und node2 haben:

network interface show -role cluster

Das System zeigt alle Cluster-LIFs an, wie im folgenden Beispiel gezeigt:

cluster::> network interface show -role cluster
        Logical    Status     Network          Current  Current Is
Vserver Interface  Admin/Oper Address/Mask     Node     Port    Home
------- ---------- ---------- ---------------- -------- ------- ----
node1
        clus1      up/up      172.17.177.2/24  node1    e0c     true
        clus2      up/up      172.17.177.6/24  node1    e0e     true
node2
        clus1      up/up      172.17.177.3/24  node2    e0c     true
        clus2      up/up      172.17.177.7/24  node2    e0e     true

Wenn Sie zwei oder vier Cluster LIFs auf node1 oder node2 haben, stellen Sie sicher, dass Sie beide Cluster LIFs über alle verfügbaren Pfade pingen können, indem Sie die folgenden Unterschritte ausführen:

Geben Sie die erweiterte Berechtigungsebene ein:

set -privilege advanced

Vom System wird die folgende Meldung angezeigt:

Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel.
Do you wish to continue? (y or n):

Eingabe y.
Pingen der Knoten und Testen der Konnektivität:

cluster ping-cluster -node node_name

Vom System wird eine Meldung wie das folgende Beispiel angezeigt:

cluster::*> cluster ping-cluster -node node1
Host is node1
Getting addresses from network interface table...
Local = 10.254.231.102 10.254.91.42
Remote = 10.254.42.25 10.254.16.228
Ping status:
...
Basic connectivity succeeds on 4 path(s) Basic connectivity fails on 0 path(s)
................
Detected 1500 byte MTU on 4 path(s):
Local 10.254.231.102 to Remote 10.254.16.228
Local 10.254.231.102 to Remote 10.254.42.25
Local 10.254.91.42 to Remote 10.254.16.228
Local 10.254.91.42 to Remote 10.254.42.25
Larger than PMTU communication succeeds on 4 path(s)
RPC status:
2 paths up, 0 paths down (tcp check)
2 paths up, 0 paths down (udp check)

+
Wenn der Node zwei Cluster Ports verwendet, sollten Sie sehen, dass er in vier Pfaden kommunizieren kann, wie im Beispiel dargestellt.

Zurück zur Berechtigung auf Administratorebene:

set -privilege admin

Vergewissern Sie sich, dass sich node1 und node2 in einem HA-Paar befinden und überprüfen Sie, dass die Knoten miteinander verbunden sind und dass Übernahme möglich ist:

storage failover show

Das folgende Beispiel zeigt die Ausgabe, wenn die Nodes miteinander verbunden sind und Takeover möglich ist:
```
cluster::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------
node1          node2          true     Connected to node2
node2          node1          true     Connected to node1
```
Beide Nodes sollten sich im partiellen Giveback enthalten. Das folgende Beispiel zeigt, dass sich node1 teilweise im Giveback befindet:
```
cluster::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------
node1          node2          true     Connected to node2, Partial giveback
node2          node1          true     Connected to node1
```
Wenn sich einer der Knoten im Teilrückgeben befindet, verwenden Sie storage failover giveback den Befehl zum Durchführen des Giveback und verwenden Sie dann den storage failover show-giveback Befehl, um sicherzustellen, dass noch keine Aggregate zurückgeben müssen. Ausführliche Informationen zu den Befehlen finden Sie unter "Quellen"Link zum HA-Paar-Management.
Bestätigen Sie, dass weder node1 noch node2 die Aggregate besitzen, für die es der aktuelle Eigentümer ist (aber nicht der Hausbesitzer):

storage aggregate show -nodes node_name -is-home false -fields owner-name, home-name, state

Wenn weder node1 noch node2 besitzt Aggregate, für die es der aktuelle Eigentümer ist (aber nicht der Hausbesitzer), gibt das System eine Meldung ähnlich dem folgenden Beispiel zurück:
```
cluster::> storage aggregate show -node node2 -is-home false -fields owner-name,homename,state
There are no entries matching your query.
```
Im folgenden Beispiel wird die Ausgabe des Befehls für einen Node mit dem Namen node2 angezeigt, der der Home-Inhaber, jedoch nicht der aktuelle Eigentümer von vier Aggregaten ist:
```
cluster::> storage aggregate show -node node2 -is-home false
               -fields owner-name,home-name,state

aggregate     home-name    owner-name   state
------------- ------------ ------------ ------
aggr1         node1        node2        online
aggr2         node1        node2        online
aggr3         node1        node2        online
aggr4         node1        node2        online

4 entries were displayed.
```

Führen Sie eine der folgenden Aktionen durch:

Wenn der Befehl in ausgeführt wird Schritt 9…	Dann…
Leere Ausgabe	Überspringen Sie Schritt 11, und fahren Sie mit fort Schritt 12.
Hatte eine Ausgabe	Gehen Sie zu Schritt 11.

Wenn der Befehl in ausgeführt wird Schritt 9…

Dann…

Leere Ausgabe

Überspringen Sie Schritt 11, und fahren Sie mit fort Schritt 12.

Hatte eine Ausgabe

Gehen Sie zu Schritt 11.

[[man_prepare_Nodes_step11] Wenn node1 oder node2 Aggregate besitzt, für die es der aktuelle Eigentümer, aber nicht der Besitzer des Hauses ist, führen Sie die folgenden Teilschritte durch:
1. Gibt die Aggregate zurück, die derzeit dem Partner-Node gehören, an den Home-Owner-Node:
  
  storage failover giveback -ofnode home_node_name
2. Überprüfen Sie, dass weder node1 noch node2 noch Eigentümer von Aggregaten ist, für die es der aktuelle Eigentümer ist (aber nicht der Hausbesitzer):
  
  storage aggregate show -nodes node_name -is-home false -fields owner-name, home-name, state
  
  Das folgende Beispiel zeigt die Ausgabe des Befehls, wenn ein Node sowohl der aktuelle Eigentümer als auch der Home-Inhaber von Aggregaten ist:
```
cluster::> storage aggregate show -nodes node1
          -is-home true -fields owner-name,home-name,state

aggregate     home-name    owner-name   state
------------- ------------ ------------ ------
aggr1         node1        node1        online
aggr2         node1        node1        online
aggr3         node1        node1        online
aggr4         node1        node1        online

4 entries were displayed.
```
Bestätigen, dass node1 und node2 auf den Speicher des anderen zugreifen können und überprüfen, dass keine Festplatten fehlen:

storage failover show -fields local-missing-disks,partner-missing-disks

Im folgenden Beispiel wird die Ausgabe angezeigt, wenn keine Festplatten fehlen:
```
cluster::> storage failover show -fields local-missing-disks,partner-missing-disks

node     local-missing-disks partner-missing-disks
-------- ------------------- ---------------------
node1    None                None
node2    None                None
```
Falls Festplatten fehlen, lesen Sie "Quellen"den Link zu Festplatten- und Aggregatmanagement mit der CLI, logisches Storage Management mit der CLI und HA-Paar-Management, um den Storage für das HA-Paar zu konfigurieren.
Vergewissern Sie sich, dass node1 und node2 gesund sind und am Cluster teilnehmen können:

cluster show

Das folgende Beispiel zeigt die Ausgabe, wenn beide Nodes qualifiziert und ordnungsgemäß sind:
```
cluster::> cluster show

Node                  Health  Eligibility
--------------------- ------- ------------
node1                 true    true
node2                 true    true
```
Legen Sie die Berechtigungsebene auf erweitert fest:

set -privilege advanced

Bestätigen Sie, dass node1 und node2 dieselbe ONTAP-Version ausführen:

system node image show -node node1,node2 -iscurrent true

Im folgenden Beispiel wird die Ausgabe des Befehls angezeigt:

cluster::*> system node image show -node node1,node2 -iscurrent true

                 Is      Is                Install
Node     Image   Default Current Version   Date
-------- ------- ------- ------- --------- -------------------
node1
         image1  true    true    9.1         2/7/2017 20:22:06
node2
         image1  true    true    9.1         2/7/2017 20:20:48

2 entries were displayed.

Vergewissern Sie sich, dass weder node1 noch node2 Eigentümer sämtlicher Daten-LIFs sind, die zu anderen Nodes im Cluster gehören, und überprüfen Sie die Current Node Und Is Home Spalten in der Ausgabe:

network interface show -role data -is-home false -curr-node node_name

Das folgende Beispiel zeigt die Ausgabe, wenn node1 keine LIFs besitzt, die im Besitz anderer Nodes im Cluster sind:

cluster::> network interface show -role data -is-home false -curr-node node1
 There are no entries matching your query.

Das folgende Beispiel zeigt die Ausgabe, wenn Node1 dem anderen Node gehören wird, der Eigentümer von Daten-LIFs:

cluster::> network interface show -role data -is-home false -curr-node node1

            Logical    Status     Network            Current       Current Is
Vserver     Interface  Admin/Oper Address/Mask       Node          Port    Home
----------- ---------- ---------- ------------------ ------------- ------- ----
vs0
            data1      up/up      172.18.103.137/24  node1         e0d     false
            data2      up/up      172.18.103.143/24  node1         e0f     false

2 entries were displayed.

Wenn die Ausgabe in Schritt 15 Zeigt, dass Node1 oder node2 Eigentümer beliebiger Daten-LIFs sind, die sich im Besitz anderer Nodes im Cluster befinden. Migrieren Sie die Daten-LIFs von node1 oder node2:

network interface revert -vserver * -lif *

Ausführliche Informationen zum network interface revert Befehl, siehe "Quellen" Link zu den Befehlen ONTAP 9: Manual Page Reference.
Überprüfen Sie, ob node1 oder node2 ausgefallene Festplatten besitzt:

storage disk show -nodelist node1,node2 -broken

Wenn eine der Festplatten ausgefallen ist, entfernen Sie sie gemäß den Anweisungen in Disk und Aggregat-Management mit der CLI. (Siehe "Quellen" Verbinden mit Disk und Aggregatmanagement mit CLI.)

Sammeln Sie Informationen über node1 und node2, indem Sie die folgenden Unterschritte ausführen und die Ausgabe jedes Befehls aufzeichnen:

Diese Informationen werden Sie später im Verfahren verwenden.

Notieren Sie das Modell, die System-ID und die Seriennummer beider Nodes:

system node show -node node1,node2 -instance

Sie verwenden die Informationen, um Festplatten neu zuzuweisen und die ursprünglichen Nodes außer Betrieb zu nehmen.

Geben Sie in node1 und node2 den folgenden Befehl ein und notieren Sie Informationen über die Shelfs, die Anzahl der Festplatten in jedem Shelf, die Flash Storage-Details, den Arbeitsspeicher, NVRAM und die Netzwerkkarten aus der Ausgabe:

run -node node_name sysconfig

Sie können die Informationen verwenden, um Teile oder Zubehör zu identifizieren, die Sie auf node3 oder node4 übertragen möchten. Wenn Sie nicht wissen, ob die Nodes V-Series Systeme sind oder über FlexArray-Virtualisierungssoftware verfügen, können Sie das auch aus der Ausgabe lernen.

Geben Sie sowohl bei node1 als auch bei node2 den folgenden Befehl ein und notieren Sie die Aggregate, die auf beiden Nodes online sind:

storage aggregate show -node node_name -state online

Mithilfe dieser Informationen und der Informationen im folgenden Unterschritt können Sie überprüfen, ob die Aggregate und Volumes während des gesamten Verfahrens online bleiben, mit Ausnahme des kurzen Zeitraums, in dem sie während der Verschiebung offline sind.

Geben Sie sowohl für node1 als auch für node2 den folgenden Befehl ein und notieren Sie die Volumes, die auf beiden Knoten offline sind:

volume show -node node_name -state offline

Nach dem Upgrade führen Sie den Befehl erneut aus und vergleichen die Ausgabe mit der Ausgabe in diesem Schritt, um zu sehen, ob andere Volumes offline gegangen sind.

Geben Sie die folgenden Befehle ein, um zu ermitteln, ob Schnittstellengruppen oder VLANs auf node1 oder node2 konfiguriert sind:

network port ifgrp show

network port vlan show

Beachten Sie, ob Schnittstellengruppen oder VLANs auf node1 oder node2 konfiguriert sind. Diese Informationen benötigen Sie im nächsten Schritt und später im Verfahren.
Führen Sie die folgenden Teilschritte sowohl bei node1 als auch bei node2 durch, um zu bestätigen, dass die physischen Ports im weiteren Verlauf des Verfahrens korrekt zugeordnet werden können:
1. Geben Sie den folgenden Befehl ein, um zu ermitteln, ob außer den Failover-Gruppen auf dem Node Failover-Gruppen vorhanden sind clusterwide:
  
  network interface failover-groups show
  
  Failover-Gruppen sind Gruppen von Netzwerk-Ports, die sich im System befinden. Da durch ein Upgrade der Controller-Hardware der Standort physischer Ports geändert werden kann, können Failover-Gruppen während des Upgrades unbeabsichtigt geändert werden.
  
  Das System zeigt Failover-Gruppen auf dem Node an, wie im folgenden Beispiel dargestellt:
  cluster::> network interface failover-groups show Vserver Group Targets ------------------- ----------------- ---------- Cluster Cluster node1:e0a, node1:e0b node2:e0a, node2:e0b fg_6210_e0c Default node1:e0c, node1:e0d node1:e0e, node2:e0c node2:e0d, node2:e0e 2 entries were displayed.
2. Wenn es andere Failover-Gruppen als gibt `clusterwide`Notieren Sie die Namen der Failover-Gruppen und die Ports, die zu den Failover-Gruppen gehören.
3. Geben Sie den folgenden Befehl ein, um zu ermitteln, ob auf dem Node konfigurierte VLANs vorhanden sind:
  
  network port vlan show -node node_name
  
  VLANs werden über physische Ports konfiguriert. Wenn sich die physischen Ports ändern, müssen die VLANs später im Verfahren neu erstellt werden.
  
  Das System zeigt VLANs an, die auf dem Knoten konfiguriert sind, wie im folgenden Beispiel dargestellt:
```
cluster::> network port vlan show

Network Network
Node    VLAN Name Port    VLAN ID MAC Address
------  --------- ------- ------- ------------------
node1   e1b-70    e1b     70      00:15:17:76:7b:69
```
1. Wenn auf dem Node VLANs konfiguriert sind, notieren Sie sich jeden Netzwerkport und die Verbindung zwischen VLAN-ID.
Führen Sie eine der folgenden Aktionen durch:

Wenn Interface Groups oder VLANS… Dann…

Auf node1 oder node2

Vollständig Schritt 23 Und Schritt 24.

Nicht auf node1 oder node2

Gehen Sie zu Schritt 24.
[[man_prepare_Nodes_step23] Wenn Sie nicht wissen, ob sich node1 und node2 in einer SAN- oder nicht-SAN-Umgebung befinden, geben Sie den folgenden Befehl ein und überprüfen die Ausgabe:

network interface show -vserver vserver_name -data-protocol iscsi|fcp

Wenn iSCSI oder FC für die SVM konfiguriert ist, wird mit dem Befehl eine Meldung wie das folgende Beispiel angezeigt:
```
cluster::> network interface show -vserver Vserver8970 -data-protocol iscsi|fcp
There are no entries matching your query.
```
Sie können bestätigen, dass sich der Knoten in einer NAS-Umgebung befindet, indem Sie den verwenden network interface show Befehl mit dem -data-protocol nfs|cifs Parameter.

Wenn iSCSI oder FC für die SVM konfiguriert ist, wird mit dem Befehl eine Meldung wie das folgende Beispiel angezeigt:
```
cluster::> network interface show -vserver vs1 -data-protocol iscsi|fcp

         Logical    Status     Network            Current  Current Is
Vserver  Interface  Admin/Oper Address/Mask       Node     Port    Home
-------- ---------- ---------- ------------------ -------- ------- ----
vs1      vs1_lif1   up/down    172.17.176.20/24   node1    0d      true
```
Stellen Sie sicher, dass alle Knoten im Cluster Quorum sind, indem Sie die folgenden Teilschritte ausführen:
1. Geben Sie die erweiterte Berechtigungsebene ein:
  
  set -privilege advanced
  
  Vom System wird die folgende Meldung angezeigt:
  Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. Do you wish to continue? (y or n):
2. Eingabe y.
3. Überprüfen Sie einmal für jeden Node den Cluster-Service-Status im Kernel:
  
  cluster kernel-service show
  
  Vom System wird eine Meldung wie das folgende Beispiel angezeigt:
```
cluster::*> cluster kernel-service show

Master        Cluster       Quorum        Availability  Operational
Node          Node          Status        Status        Status
------------- ------------- ------------- ------------- -------------
node1         node1         in-quorum     true          operational
              node2         in-quorum     true          operational

2 entries were displayed.
```
+
Nodes in einem Cluster sind Quorum, wenn eine einfache Mehrheit der Nodes in einem ordnungsgemäßen Zustand ist und miteinander kommunizieren kann. Weitere Informationen finden Sie unter "Quellen" Verknüpfen mit der Referenz Systemadministration.
1. Zurück zur Administratorberechtigungsebene:
  
  set -privilege admin
Führen Sie eine der folgenden Aktionen durch:

Wenn der Cluster… Dann…

Ist SAN konfiguriert

Gehen Sie zu Schritt 26.

Hat kein SAN konfiguriert

Gehen Sie zu Schritt 29.

Wenn Interface Groups oder VLANS…	Dann…
Auf node1 oder node2	Vollständig Schritt 23 Und Schritt 24.
Nicht auf node1 oder node2	Gehen Sie zu Schritt 24.

Wenn der Cluster…	Dann…
Ist SAN konfiguriert	Gehen Sie zu Schritt 26.
Hat kein SAN konfiguriert	Gehen Sie zu Schritt 29.

Stellen Sie sicher, dass SAN LIFs auf node1 und node2 für jede SVM sind, bei der entweder SAN iSCSI oder FC Service aktiviert ist, indem Sie den folgenden Befehl eingeben und seine Ausgabe prüfen:

network interface show -data-protocol iscsi|fcp -home-node node_name

Der Befehl zeigt SAN LIF-Informationen für node1 und node2 an. Die folgenden Beispiele zeigen den Status in der Spalte Status Admin/Oper nach oben/oben und geben an, dass SAN-iSCSI- und FC-Service aktiviert sind:

cluster::> network interface show -data-protocol iscsi|fcp
            Logical    Status     Network                  Current   Current Is
Vserver     Interface  Admin/Oper Address/Mask             Node      Port    Home
----------- ---------- ---------- ------------------       --------- ------- ----
a_vs_iscsi  data1      up/up      10.228.32.190/21         node1     e0a     true
            data2      up/up      10.228.32.192/21         node2     e0a     true

b_vs_fcp    data1      up/up      20:09:00:a0:98:19:9f:b0  node1     0c      true
            data2      up/up      20:0a:00:a0:98:19:9f:b0  node2     0c      true

c_vs_iscsi_fcp data1   up/up      20:0d:00:a0:98:19:9f:b0  node2     0c      true
            data2      up/up      20:0e:00:a0:98:19:9f:b0  node2     0c      true
            data3      up/up      10.228.34.190/21         node2     e0b     true
            data4      up/up      10.228.34.192/21         node2     e0b     true

Alternativ können Sie ausführlichere LIF-Informationen anzeigen, indem Sie den folgenden Befehl eingeben:

network interface show -instance -data-protocol iscsi|fcp

Erfassen Sie die Standardkonfiguration aller FC-Ports an den ursprünglichen Nodes, indem Sie den folgenden Befehl eingeben und die Ausgabe für Ihre Systeme aufzeichnen:

ucadmin show

Der Befehl zeigt Informationen zu allen FC-Ports im Cluster an, wie im folgenden Beispiel dargestellt:

cluster::> ucadmin show

                Current Current   Pending Pending   Admin
Node    Adapter Mode    Type      Mode    Type      Status
------- ------- ------- --------- ------- --------- -----------
node1   0a      fc      initiator -       -         online
node1   0b      fc      initiator -       -         online
node1   0c      fc      initiator -       -         online
node1   0d      fc      initiator -       -         online
node2   0a      fc      initiator -       -         online
node2   0b      fc      initiator -       -         online
node2   0c      fc      initiator -       -         online
node2   0d      fc      initiator -       -         online
8 entries were displayed.

Sie können die Informationen nach dem Upgrade verwenden, um die Konfiguration von FC-Ports auf den neuen Nodes einzustellen.

Wenn Sie ein V-Series System oder ein System mit FlexArray Virtualisierungssoftware aktualisieren, erfassen Sie Informationen über die Topologie der Original-Nodes, indem Sie den folgenden Befehl eingeben und die Ausgabe aufzeichnen:

storage array config show -switch

Das System zeigt Topologieinformationen wie im folgenden Beispiel dargestellt an:

cluster::> storage array config show -switch

      LUN LUN                                  Target Side Initiator Side Initi-
Node  Grp Cnt Array Name    Array Target Port  Switch Port Switch Port    ator
----- --- --- ------------- ------------------ ----------- -------------- ------
node1 0   50  I_1818FAStT_1
                            205700a0b84772da   vgbr6510a:5  vgbr6510s164:3  0d
                            206700a0b84772da   vgbr6510a:6  vgbr6510s164:4  2b
                            207600a0b84772da   vgbr6510b:6  vgbr6510s163:1  0c
node2 0   50  I_1818FAStT_1
                            205700a0b84772da   vgbr6510a:5  vgbr6510s164:1  0d
                            206700a0b84772da   vgbr6510a:6  vgbr6510s164:2  2b
                            207600a0b84772da   vgbr6510b:6  vgbr6510s163:3  0c
                            208600a0b84772da   vgbr6510b:5  vgbr6510s163:4  2a
7 entries were displayed.

die folgenden Teilschritte ausführen:
1. Geben Sie an einem der Original-Nodes den folgenden Befehl ein und notieren Sie die Ausgabe:
  
  service-processor show -node * -instance
Das System zeigt auf beiden Nodes detaillierte Informationen zum SP an.
1. Vergewissern Sie sich, dass der SP-Status lautet online.
2. Vergewissern Sie sich, dass das SP-Netzwerk konfiguriert ist.
3. Notieren Sie die IP-Adresse und andere Informationen zum SP.
  
  Möglicherweise möchten Sie die Netzwerkparameter der Remote-Verwaltungsgeräte, in diesem Fall die SPs, vom ursprünglichen System für die SPs auf den neuen Knoten wieder verwenden. Ausführliche Informationen zum SP finden Sie unter "Quellen" Link zu den Befehlen Systemadministration Reference und ONTAP 9: Manual Page Reference.

Wenn die neuen Nodes dieselben lizenzierten Funktionen wie die ursprünglichen Knoten haben sollen, geben Sie den folgenden Befehl ein, um die Clusterlizenzen auf dem ursprünglichen System anzuzeigen:

system license show -owner *

Das folgende Beispiel zeigt die Websitelizenzen für Cluster1:

system license show -owner *
Serial Number: 1-80-000013
Owner: cluster1

Package           Type    Description           Expiration
----------------- ------- --------------------- -----------
Base              site    Cluster Base License  -
NFS               site    NFS License           -
CIFS              site    CIFS License          -
SnapMirror        site    SnapMirror License    -
FlexClone         site    FlexClone License     -
SnapVault         site    SnapVault License     -
6 entries were displayed.

Beschaffung neuer Lizenzschlüssel für die neuen Nodes auf der NetApp Support Site. Siehe "Quellen" Zum Link zu NetApp Support Site.

Falls auf der Website keine Lizenzschlüssel vorhanden ist, wenden Sie sich an Ihren NetApp Ansprechpartner.

Überprüfen Sie, ob im Original-System AutoSupport aktiviert ist, indem Sie auf jedem Node den folgenden Befehl eingeben und seine Ausgabe überprüfen:

system node autosupport show -node node1,node2

Die Befehlsausgabe gibt an, ob AutoSupport aktiviert ist. Wie im folgenden Beispiel gezeigt:

cluster::> system node autosupport show -node node1,node2

Node             State     From          To                Mail Hosts
---------------- --------- ------------- ----------------  ----------
node1            enable    Postmaster    admin@netapp.com  mailhost

node2            enable    Postmaster    -                 mailhost
2 entries were displayed.

Führen Sie eine der folgenden Aktionen durch:

Wenn das ursprüngliche System…	Dann…
Hat AutoSupport aktiviert…	Gehen Sie zu Schritt 34.
AutoSupport ist nicht aktiviert…	Aktivieren Sie AutoSupport, indem Sie den Anweisungen in der Systemverwaltungsreferenz_ folgen. (Siehe "Quellen" Zum Verknüpfen mit der Referenz Systemadministration.) Hinweis: AutoSupport ist standardmäßig aktiviert, wenn Sie Ihr Speichersystem zum ersten Mal konfigurieren. Sie können AutoSupport zwar jederzeit deaktivieren, jedoch sollten Sie sie aktiviert lassen. Wenn Sie AutoSupport aktivieren, können Sie erheblich dabei helfen, Probleme und Lösungen zu identifizieren, sollten bei Ihrem Storage-System Probleme auftreten.

Wenn das ursprüngliche System…

Dann…

Hat AutoSupport aktiviert…

Gehen Sie zu Schritt 34.

AutoSupport ist nicht aktiviert…

Aktivieren Sie AutoSupport, indem Sie den Anweisungen in der Systemverwaltungsreferenz_ folgen. (Siehe "Quellen" Zum Verknüpfen mit der Referenz Systemadministration.)

Hinweis: AutoSupport ist standardmäßig aktiviert, wenn Sie Ihr Speichersystem zum ersten Mal konfigurieren. Sie können AutoSupport zwar jederzeit deaktivieren, jedoch sollten Sie sie aktiviert lassen. Wenn Sie AutoSupport aktivieren, können Sie erheblich dabei helfen, Probleme und Lösungen zu identifizieren, sollten bei Ihrem Storage-System Probleme auftreten.

Überprüfen Sie, ob AutoSupport mit den korrekten E-Mail-IDs für den Mailhost konfiguriert ist, indem Sie auf beiden Originalknoten den folgenden Befehl eingeben und die Ausgabe prüfen:

system node autosupport show -node node_name -instance

Ausführliche Informationen zu AutoSupport finden Sie unter "Quellen" Link zu den Befehlen Systemadministration Reference und ONTAP 9: Manual Page Reference.
Senden Sie eine AutoSupport-Nachricht für node1 an NetApp, indem Sie den folgenden Befehl eingeben:

system node autosupport invoke -node node1 -type all -message "Upgrading node1 from platform_old to platform_new"

Senden Sie jetzt keine AutoSupport Nachricht für node2 an NetApp. Sie gehen das später im Verfahren vor.
Überprüfen Sie, ob die AutoSupport-Meldung gesendet wurde, indem Sie den folgenden Befehl eingeben und die Ausgabe prüfen:

system node autosupport show -node node1 -instance

Felder Last Subject Sent: Und Last Time Sent: Enthält den Nachrichtentitel der letzten gesendeten Nachricht und den Zeitpunkt, zu dem die Nachricht gesendet wurde.

Wenn Ihr System Self-Encrypting Drives verwendet, lesen Sie den Artikel der Knowledge Base "Wie erkennen Sie, ob ein Laufwerk FIPS-zertifiziert ist" Ermitteln der Art der Self-Encrypting Drives, die auf dem HA-Paar verwendet werden, das Sie aktualisieren. ONTAP unterstützt zwei Arten von Self-Encrypting Drives:

FIPS-zertifizierte NetApp Storage Encryption (NSE) SAS- oder NVMe-Laufwerke
Self-Encrypting-NVMe-Laufwerke (SED) ohne FIPS

FIPS-Laufwerke können nicht mit anderen Laufwerkstypen auf demselben Node oder HA-Paar kombiniert werden.

SEDs können mit Laufwerken ohne Verschlüsselung auf demselben Node oder HA-Paar kombiniert werden.

"Weitere Informationen zu unterstützten Self-Encrypting Drives".

Bereiten Sie die Knoten für ein Upgrade vor

Creating your file...