Herunterfahren der Controller – AFF A400
Fahren Sie den Controller mit eingeschränkter Konfiguration herunter oder übernehmen Sie ihn entsprechend.
Option 1: Fahren Sie die Controller beim Ersetzen eines Gehäuses herunter
Dieses Verfahren gilt für Systeme mit zwei-Knoten-Konfigurationen. Weitere Informationen über das ordnungsgemäßes Herunterfahren beim Warten eines Clusters finden Sie unter "Anleitung zur Problemlösung für das Speichersystem – NetApp Knowledge Base".
-
Stellen Sie sicher, dass Sie über die erforderlichen Berechtigungen und Anmeldeinformationen verfügen:
-
Lokale Administratoranmeldeinformationen für ONTAP.
-
BMC accessibility für jeden Controller.
-
-
Stellen Sie sicher, dass Sie über die erforderlichen Werkzeuge und Geräte für den Austausch verfügen.
-
Melden Sie sich über SSH beim Cluster an oder von einem beliebigen Node im Cluster mit einem lokalen Konsolenkabel und einem Laptop/einer Konsole an.
-
Stoppen Sie den Zugriff aller Clients/Hosts auf Daten auf dem NetApp System.
-
Externe Sicherungsaufträge werden angehalten.
-
Wenn AutoSupport aktiviert ist, unterdrücken Sie die Case-Erstellung und geben Sie an, wie lange Sie das System voraussichtlich offline sein werden:
system node autosupport invoke -node * -type all -message "MAINT=2h Replace chassis" -
Ermitteln Sie die SP/BMC-Adresse aller Cluster-Nodes:
system service-processor show -node * -fields address -
Beenden Sie die Cluster-Shell:
exit -
Melden Sie sich beim SP/BMC jedes Controllers mit der im vorherigen Schritt ermittelten IP-Adresse an:
-
Wenn Sie sich vom BMC über SSH anmelden, stellen Sie die Verbindung über die SP/BMC-Adresse her (zum Beispiel
ssh admin@<SP/BMC_address>), geben Sie dann den Befehlsystem consoleein und authentifizieren Sie sich. -
Wenn Sie eine lokale Konsole oder einen Laptop verwenden, der direkt mit dem Controller verbunden ist, melden Sie sich mit denselben Cluster Administrator-Anmeldeinformationen an.
-
-
Halten Sie die beiden Nodes im beeinträchtigten Chassis an:
system node halt -node <node1>,<node2> -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover trueBei Clustern mit SnapMirror Synchronous-Betrieb im StructSync-Modus: system node halt -node <node1>,<node2> -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true -ignore-strict-sync-warnings true -
Geben Sie y für jeden Controller im Cluster ein, wenn Folgendes angezeigt wird:
Warning: Are you sure you want to halt node <node_name>? {y|n}: -
Warten Sie, bis die einzelnen Controller angehalten sind, und zeigen Sie die LOADER-Eingabeaufforderung an.
Option 2: Herunterfahren eines Controllers in einer MetroCluster-Konfiguration mit zwei Nodes
Um den beeinträchtigten Controller herunterzufahren, müssen Sie den Status des Controllers bestimmen und gegebenenfalls den Controller umschalten, damit der gesunde Controller weiterhin Daten aus dem beeinträchtigten Reglerspeicher bereitstellen kann.
-
Sie müssen die Netzteile am Ende dieses Verfahrens einschalten, um den gesunden Controller mit Strom zu versorgen.
-
Überprüfen Sie den MetroCluster-Status, um festzustellen, ob der beeinträchtigte Controller automatisch auf den gesunden Controller umgeschaltet wurde:
metrocluster show -
Je nachdem, ob eine automatische Umschaltung stattgefunden hat, fahren Sie mit der folgenden Tabelle fort:
Wenn die eingeschränkte Steuerung… Dann… Ist automatisch umgeschaltet
Fahren Sie mit dem nächsten Schritt fort.
Nicht automatisch umgeschaltet
Einen geplanten Umschaltvorgang vom gesunden Controller durchführen:
metrocluster switchoverHat nicht automatisch umgeschaltet, haben Sie versucht, mit dem zu wechseln
metrocluster switchoverBefehl und Switchover wurde vetoedÜberprüfen Sie die Veto-Meldungen, und beheben Sie das Problem, wenn möglich, und versuchen Sie es erneut. Wenn das Problem nicht behoben werden kann, wenden Sie sich an den technischen Support.
-
Synchronisieren Sie die Datenaggregate neu, indem Sie das ausführen
metrocluster heal -phase aggregatesBefehl aus dem verbleibenden Cluster.controller_A_1::> metrocluster heal -phase aggregates [Job 130] Job succeeded: Heal Aggregates is successful.
Wenn die Heilung ein Vetorecht ist, haben Sie die Möglichkeit, das zurückzugeben
metrocluster healBefehl mit dem-override-vetoesParameter. Wenn Sie diesen optionalen Parameter verwenden, überschreibt das System alle weichen Vetos, die die Heilung verhindern. -
Überprüfen Sie, ob der Vorgang mit dem befehl „MetroCluster Operation show“ abgeschlossen wurde.
controller_A_1::> metrocluster operation show Operation: heal-aggregates State: successful Start Time: 7/25/2016 18:45:55 End Time: 7/25/2016 18:45:56 Errors: - -
Überprüfen Sie den Status der Aggregate mit
storage aggregate showBefehl.controller_A_1::> storage aggregate show Aggregate Size Available Used% State #Vols Nodes RAID Status --------- -------- --------- ----- ------- ------ ---------------- ------------ ... aggr_b2 227.1GB 227.1GB 0% online 0 mcc1-a2 raid_dp, mirrored, normal...
-
Heilen Sie die Root-Aggregate mit dem
metrocluster heal -phase root-aggregatesBefehl.mcc1A::> metrocluster heal -phase root-aggregates [Job 137] Job succeeded: Heal Root Aggregates is successful
Wenn die Heilung ein Vetorecht ist, haben Sie die Möglichkeit, das zurückzugeben
metrocluster healBefehl mit dem Parameter -override-vetoes. Wenn Sie diesen optionalen Parameter verwenden, überschreibt das System alle weichen Vetos, die die Heilung verhindern. -
Stellen Sie sicher, dass der Heilungsvorgang abgeschlossen ist, indem Sie den verwenden
metrocluster operation showBefehl auf dem Ziel-Cluster:mcc1A::> metrocluster operation show Operation: heal-root-aggregates State: successful Start Time: 7/29/2016 20:54:41 End Time: 7/29/2016 20:54:42 Errors: - -
Trennen Sie am Controller-Modul mit eingeschränkter Betriebsstörung die Netzteile.