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

Fahren Sie die Controller herunter - AFF C400

Beitragende

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 nur für Konfigurationen ohne MetroCluster mit 2 Nodes. Wenn Sie ein System mit mehr als zwei Nodes haben, finden Sie weitere Informationen unter "So schalten Sie ein HA-Paar in einem Cluster mit 4 Nodes ein und fahren ein paar ordnungsgemäß hoch".

Bevor Sie beginnen

Sie benötigen:

  • Lokale Administratoranmeldeinformationen für ONTAP.

  • NetApp Onboard-Verschlüsselungsmanagement (OKM) Cluster-weite Passphrase bei Verwendung von Storage-Verschlüsselung.

  • SP/BMC-Zugriff für jeden Controller.

  • Stoppen Sie den Zugriff aller Clients/Hosts auf Daten auf dem NetApp System.

  • Externe Sicherungsaufträge werden angehalten.

  • Notwendige Werkzeuge und Ausrüstung für den Austausch.

Anmerkung Wenn es sich bei dem System um ein NetApp StorageGRID oder ONTAP S3 handelt, das als FabricPool Cloud Tier verwendet wird, finden Sie im "Anleitung zur Problemlösung des Speichersystems wird ordnungsgemäß heruntergefahren und gestartet" Nach Durchführung dieses Verfahrens.
Anmerkung Wenn Sie FlexArray-Array-LUNs verwenden, befolgen Sie die Dokumentation zum Speicher-Array des jeweiligen Anbieters, um das Herunterfahren für diese Systeme durchzuführen, nachdem Sie dieses Verfahren durchgeführt haben.
Anmerkung Wenn Sie SSDs verwenden, finden Sie weitere Informationen unter "SU490: (Auswirkung: Kritisch) SSD Best Practices: Vermeiden Sie das Risiko von Laufwerksausfällen und Datenverlust, wenn Sie sich für mehr als zwei Monate ausgeschaltet haben"

Als Best Practice vor dem Herunterfahren sollten Sie:

Schritte

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

  2. Schalten Sie AutoSupport aus, und geben Sie an, wie lange das System voraussichtlich offline ist:

    system node autosupport invoke -node * -type all -messages "MAINT=8h Power Maintenance"

  3. Ermitteln Sie die SP/BMC-Adresse aller Nodes:

    system service-processor show -node * -fields address

  4. Beenden Sie die Cluster-Shell: exit

  5. Melden Sie sich über SSH beim SP/BMC an. Verwenden Sie dabei die IP-Adresse eines der in der Ausgabe des vorherigen Schritts aufgeführten Nodes.

    Wenn Sie eine Konsole oder einen Laptop verwenden, melden Sie sich mit den gleichen Cluster-Administratorberechtigungen beim Controller an.

    Anmerkung Öffnen Sie eine SSH-Sitzung für jede SP/BMC-Verbindung, damit Sie den Fortschritt überwachen können.

  6. Alle Nodes im Cluster anhalten:

    system node halt -node * -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true.

    Anmerkung Bei Clustern mit SnapMirror Synchronous-Betrieb im StructSync-Modus: system node halt -node * -skip-lif-migration-before-shutdown true -ignore-quorum-warnings true -inhibit-takeover true -ignore-strict-sync-warnings true

  7. Geben Sie y für jeden Controller im Cluster ein, wenn angezeigt wird Warning: Are you sure you want to halt node "cluster name-controller number"? {y|n}:

  8. Warten Sie, bis die einzelnen Controller angehalten sind, und zeigen Sie die LOADER-Eingabeaufforderung an.

  9. Schalten Sie jedes Netzteil aus, oder ziehen Sie den Netzstecker, wenn kein Netzteilschalter vorhanden ist.

  10. Ziehen Sie das Netzkabel von den einzelnen Netzteilen ab.

  11. Vergewissern Sie sich, dass alle Controller im Gehäuse für beeinträchtigte Verbindung heruntergefahren sind.

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.

Über diese Aufgabe

  • Wenn Sie NetApp Storage Encryption verwenden, müssen Sie die MSID mithilfe der Anweisungen im Abschnitt „ein FIPS-Laufwerk oder SED in ungeschützten Modus zurückgeben“ von zurücksetzen "NetApp Encryption: Übersicht mit CLI".

  • Sie müssen die Netzteile am Ende dieses Verfahrens einschalten, um den gesunden Controller mit Strom zu versorgen.

Schritte

  1. Überprüfen Sie den MetroCluster-Status, um festzustellen, ob der beeinträchtigte Controller automatisch auf den gesunden Controller umgeschaltet wurde: metrocluster show

  2. 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 switchover

    Hat nicht automatisch umgeschaltet, haben Sie versucht, mit dem zu wechseln metrocluster switchover Befehl 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.

  3. Synchronisieren Sie die Datenaggregate neu, indem Sie das ausführen metrocluster heal -phase aggregates Befehl 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 heal Befehl mit dem -override-vetoes Parameter. Wenn Sie diesen optionalen Parameter verwenden, überschreibt das System alle weichen Vetos, die die Heilung verhindern.

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

  5. Überprüfen Sie den Status der Aggregate mit storage aggregate show Befehl.

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

  6. Heilen Sie die Root-Aggregate mit dem metrocluster heal -phase root-aggregates Befehl.

    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 heal Befehl mit dem Parameter -override-vetoes. Wenn Sie diesen optionalen Parameter verwenden, überschreibt das System alle weichen Vetos, die die Heilung verhindern.

  7. Stellen Sie sicher, dass der Heilungsvorgang abgeschlossen ist, indem Sie den verwenden metrocluster operation show Befehl 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: -

  8. Trennen Sie am Controller-Modul mit eingeschränkter Betriebsstörung die Netzteile.