Bereiten Sie die Knoten für ein Upgrade vor
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.
-
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 denstorage 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.
-
[[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:
-
Gibt die Aggregate zurück, die derzeit dem Partner-Node gehören, an den Home-Owner-Node:
storage failover giveback -ofnode home_node_name
-
Ü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
UndIs 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.
-
Wenn Sie ein System mit mehr als zwei Cluster-Ports pro Node, wie z. B. einem FAS8080 oder AFF8080 System, haben Sie vor dem Upgrade die Cluster-LIFs zu zwei Cluster-Ports pro Node zu migrieren und neu zu starten. Wenn Sie das Controller-Upgrade mit mehr als zwei Cluster-Ports pro Node durchführen, fehlen möglicherweise nach dem Upgrade Cluster-LIFs auf dem neuen Controller.
-
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:
-
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.
-
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.
-
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
-
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:
-
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
. -
Ü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.-
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.
-
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:
-
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.
-
Vergewissern Sie sich, dass der SP-Status lautet
online
. -
Vergewissern Sie sich, dass das SP-Netzwerk konfiguriert ist.
-
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.
-
Ü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:
UndLast 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.
-