Skip to main content
ONTAP MetroCluster
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Controller-Upgrade in einer MetroCluster IP-Konfiguration durch Switchover und Switchback (ONTAP 9.8 und höher)

Beitragende
PDFs

Mit ONTAP 9.8 ermöglicht die MetroCluster Umschaltung unterbrechungsfreien Service für Clients, während Controller-Module im Partner-Cluster aktualisiert werden. Andere Komponenten (wie Storage Shelves oder Switches) können nicht im Rahmen dieses Verfahrens aktualisiert werden.

Plattformen, die durch dieses Verfahren unterstützt werden

  • Die Plattformen müssen ONTAP 9.8 oder höher ausführen.

  • Die Ziel-Plattform (neue) muss ein anderes Modell sein als die ursprüngliche Plattform.

  • Plattformmodelle mit internen Shelfs werden nicht unterstützt.

  • Mit diesem Verfahren können Sie nur bestimmte Plattformmodelle in einer MetroCluster IP-Konfiguration aktualisieren.

Über diese Aufgabe

  • Dieses Verfahren gilt für Controller-Module in einer MetroCluster IP-Konfiguration.

  • Upgrades für alle Controller der Konfiguration sollten während des gleichen Wartungszeitraums durchgeführt werden.

    Das Ausführen der MetroCluster-Konfiguration mit unterschiedlichen Controller-Typen wird außerhalb dieser Wartungsaktivitäten nicht unterstützt.

  • Auf den IP-Switches muss eine unterstützte Firmware-Version ausgeführt werden.

  • Wenn die neue Plattform weniger Steckplätze als das ursprüngliche System besitzt oder weniger oder unterschiedliche Ports vorhanden sind, müssen Sie dem neuen System möglicherweise einen Adapter hinzufügen.

    Weitere Informationen finden Sie im "NetApp Hardware Universe".

  • Auf den neuen Plattformen werden die IP-Adressen, Netmasken und Gateways der ursprünglichen Plattformen wiederverwendet.

  • Folgende Beispielnamen werden in diesem Verfahren verwendet:

    • Standort_A

      • Vor dem Upgrade:

        • Node_A_1-alt

        • Node_A_2-alt

      • Nach dem Upgrade:

        • Node_A_1-neu

        • Node_A_2-neu

    • Standort_B

      • Vor dem Upgrade:

        • Node_B_1-alt

        • Node_B_2-alt

      • Nach dem Upgrade:

        • Node_B_1-neu

        • Node_B_2-neu

Workflow für das Upgrade von Controllern in einer MetroCluster IP-Konfiguration

Mithilfe des Workflow-Diagramms können Sie Upgrade-Aufgaben planen.

Workflow-ip-Upgrade

Vorbereitung auf das Upgrade

Bevor Sie Änderungen an der bestehenden MetroCluster Konfiguration vornehmen, müssen Sie den Zustand der Konfiguration überprüfen, die neuen Plattformen vorbereiten und andere verschiedene Aufgaben ausführen.

Aktualisieren der RCF-Dateien des MetroCluster-Switch vor dem Aktualisieren der Controller

Abhängig von den alten Plattformmodellen, oder wenn die Switch-Konfiguration nicht auf der Mindestversion steht oder wenn Sie die von den Back-End MetroCluster-Verbindungen verwendeten VLAN-IDs ändern möchten, müssen Sie die RCF-Dateien des Switches aktualisieren, bevor Sie mit dem Verfahren zum Plattformupgrade beginnen.

Über diese Aufgabe

Sie müssen die RCF-Datei in den folgenden Szenarien aktualisieren:

  • Bei bestimmten Plattformmodellen müssen die Switches eine unterstützte VLAN-ID für die Back-End MetroCluster IP-Verbindungen verwenden. Wenn sich die alten oder neuen Plattformmodelle in der folgenden Tabelle befinden, und nicht mit einer unterstützten VLAN-ID, müssen Sie die RCF-Dateien für den Switch aktualisieren.

    Hinweis Die lokalen Cluster-Verbindungen können jedes VLAN verwenden, sie müssen nicht im angegebenen Bereich sein.

    Plattformmodell (alt oder neu)

    Unterstützte VLAN-IDs

    • AFF A400

    • 10

    • 20

    • Beliebiger Wert im Bereich 101 bis 4096 inklusive.

  • Die Switch-Konfiguration wurde nicht mit der minimal unterstützten RCF-Version konfiguriert:

    Switch-Modell

    Erforderliche RCF-Dateiversion

    Cisco 3132Q-V

    1.7 oder höher

    Cisco 3232C

    1.7 oder höher

    Broadcom BES-53248

    1.3 oder höher

  • Sie möchten die VLAN-Konfiguration ändern.

    Der VLAN-ID-Bereich liegt zwischen 101 und 4096.

Bei einem Upgrade der Controller On Site_A werden die Switches von Site_A aktualisiert.

Schritte

  1. Bereiten Sie die IP-Schalter für die Anwendung der neuen RCF-Dateien vor.

    Folgen Sie den Schritten im Abschnitt Ihres Switch-Anbieters vom "Installation und Konfiguration von MetroCluster IP".

  2. Laden Sie die RCF-Dateien herunter und installieren Sie sie.

    Befolgen Sie die Schritte unter "Installation und Konfiguration von MetroCluster IP".

Zuordnen von Ports von den alten Nodes zu den neuen Nodes

Sie müssen überprüfen, ob die physischen Ports auf Node_A_1-old den physischen Ports auf Node_A_1-New korrekt zugeordnet sind. Dadurch kann Node_A_1-New nach dem Upgrade mit anderen Knoten im Cluster und mit dem Netzwerk kommunizieren.

Über diese Aufgabe

Wenn der neue Node zum ersten Mal während des Upgrades gebootet wird, stellt er die aktuellste Konfiguration des alten Node wieder dar, der ersetzt wird. Wenn Sie Node_A_1-New booten, versucht ONTAP, LIFs auf denselben Ports zu hosten, die in Node_A_1-old verwendet wurden. Deshalb müssen Sie im Rahmen des Upgrades die Port- und LIF-Konfiguration anpassen, sodass diese mit der der des alten Node kompatibel ist. Während des Upgrades führen Sie sowohl für die alten als auch für die neuen Nodes Schritte durch, um eine korrekte Cluster-, Management- und Daten-LIF-Konfiguration sicherzustellen.

Die folgende Tabelle zeigt Beispiele für Konfigurationsänderungen in Bezug auf die Portanforderungen der neuen Nodes.

Physische Ports für Cluster-Interconnect

Alter Controller

Neuer Controller

Erforderliche Maßnahme

e0a, e0b

e3a, e3b

Kein passender Port. Nach dem Upgrade müssen Sie Cluster-Ports neu erstellen.

e0c, e0d

e0a, e0b, e0c, e0d

e0c und e0d sind passende Anschlüsse. Sie müssen die Konfiguration nicht ändern, aber nach einem Upgrade können Sie die Cluster-LIFs über die verfügbaren Cluster-Ports verteilen.
Schritte

  1. Legen Sie fest, welche physischen Ports auf den neuen Controllern verfügbar sind und welche LIFs auf den Ports gehostet werden können.

    Die Port-Nutzung des Controllers hängt vom Plattformmodul ab und welche Switches Sie in der MetroCluster IP-Konfiguration verwenden werden. Sie können die Port-Nutzung der neuen Plattformen von erfassen "NetApp Hardware Universe".

  2. Planen Sie Ihre Portnutzung und füllen Sie die folgenden Tabellen als Referenz für jeden der neuen Nodes aus.

    Sie verweisen auf die Tabelle, während Sie das Upgrade-Verfahren durchführen.

    Node_A_1-alt

    Node_A_1-neu

    LIF

    Ports

    IPspaces

    Broadcast-Domänen

    Ports

    IPspaces

    Broadcast-Domänen

    Cluster 1

    Cluster 2

    Cluster 3

    Cluster 4

    Node-Management

    Cluster-Management

    Daten 1

    Daten 2

    Daten 3

    Daten 4

    San

    Intercluster-Port

Netbootting der neuen Controller

Nachdem Sie die neuen Nodes installiert haben, müssen Sie als Netzboot fahren, damit die neuen Nodes dieselbe Version von ONTAP wie die ursprünglichen Nodes ausführen. Der Begriff Netzboot bedeutet, dass Sie über ein ONTAP Image, das auf einem Remote Server gespeichert ist, booten. Wenn Sie das Netzboot vorbereiten, müssen Sie eine Kopie des ONTAP 9 Boot Images auf einem Webserver ablegen, auf den das System zugreifen kann.

Schritte

  1. Netzboot der neuen Controller:

    1. Auf das zugreifen "NetApp Support Website" Zum Herunterladen der Dateien zum Ausführen des Netzboots des Systems.

    2. Laden Sie die entsprechende ONTAP Software im Bereich Software Downloads auf der NetApp Support Website herunter und speichern Sie die ontap-version_image.tgz Datei in einem webbasierten Verzeichnis.

    3. Wechseln Sie in das Verzeichnis für den Zugriff über das Internet, und stellen Sie sicher, dass die benötigten Dateien verfügbar sind.

      Wenn das Plattformmodell…​

      Dann…​

      8000 Series Systeme

      Extrahieren Sie den Inhalt des ontap-version_image.tgz Datei zum Zielverzeichnis:

      tar -zxvf ontap-version_image.tgz

      Hinweis Wenn Sie die Inhalte unter Windows extrahieren, verwenden Sie 7-Zip oder WinRAR, um das Netzboot-Bild zu extrahieren. Ihre Verzeichnisliste sollte einen Netzboot-Ordner mit einer Kernel-Datei:Netzboot/Kernel enthalten

      Ihre Verzeichnisliste sollte einen Netzboot-Ordner mit einer Kernel-Datei enthalten:

      netboot/kernel

      Alle anderen Systeme

      Ihre Verzeichnisliste sollte einen Netzboot-Ordner mit einer Kernel-Datei enthalten:

      _ontap-version_image.tgz

      Sie müssen den nicht extrahieren _ontap-version_image.tgz Datei:

    4. Konfigurieren Sie an der Eingabeaufforderung DES LOADERS die Netzboot-Verbindung für eine Management-LIF:

      Wenn IP-Adresse…​

      Dann…​

      DHCP

      Konfigurieren der automatischen Verbindung:

      ifconfig e0M -auto

      Festgelegt

      Konfigurieren Sie die manuelle Verbindung:

      ifconfig e0M -addr=ip_addr -mask=netmask -gw=gateway

    5. Führen Sie den Netzboot aus.

      Wenn das Plattformmodell…​

      Dann…​

      Systeme der FAS/AFF8000 Serie

      netboot http://web_server_ip/path_to_web-accessible_directory/netboot/kernel

      Alle anderen Systeme

      netboot http://_web_server_ip/path_to_web-accessible_directory/ontap-version_image.tgz

    6. Wählen Sie im Startmenü die Option (7) Neue Software zuerst installieren aus, um das neue Software-Image auf das Startgerät herunterzuladen und zu installieren.

      Ignorieren Sie die folgende Meldung:

    "This procedure is not supported for Non-Disruptive Upgrade on an HA pair". Dies gilt für unterbrechungsfreie Software-Upgrades, nicht für Controller-Upgrades.

    1. Wenn Sie aufgefordert werden, den Vorgang fortzusetzen, geben Sie ein y, Und wenn Sie zur Eingabe des Pakets aufgefordert werden, geben Sie die URL der Bilddatei ein:

      http://web_server_ip/path_to_web-accessible_directory/ontap-version_image.tgz

    2. Geben Sie ggf. den Benutzernamen und das Kennwort ein, oder drücken Sie die Eingabetaste, um fortzufahren.

    3. Seien Sie dabei n So überspringen Sie die Backup-Recovery, wenn eine Eingabeaufforderung wie die folgende angezeigt wird:

      Do you want to restore the backup configuration now? {y|n} **n**

    4. Starten Sie den Neustart durch Eingabe y Wenn eine Eingabeaufforderung wie die folgende angezeigt wird:

      The node must be rebooted to start using the newly installed software. Do you want to reboot now? {y|n}

Löschen der Konfiguration auf einem Controller-Modul

Bevor Sie in der MetroCluster-Konfiguration ein neues Controller-Modul verwenden, müssen Sie die vorhandene Konfiguration löschen.

Schritte

  1. Halten Sie gegebenenfalls den Node an, um die LOADER-Eingabeaufforderung anzuzeigen:

    halt

  2. Legen Sie an der Loader-Eingabeaufforderung die Umgebungsvariablen auf Standardwerte fest:

    set-defaults

  3. Umgebung speichern:

    saveenv

  4. Starten Sie an der LOADER-Eingabeaufforderung das Boot-Menü:

    boot_ontap menu

  5. Löschen Sie an der Eingabeaufforderung des Startmenüs die Konfiguration:

    wipeconfig

    Antworten yes An die Bestätigungsaufforderung.

    Der Node wird neu gebootet, und das Startmenü wird erneut angezeigt.

  6. Wählen Sie im Startmenü die Option 5, um das System im Wartungsmodus zu booten.

    Antworten yes An die Bestätigungsaufforderung.

Überprüfen des MetroCluster-Systemzustands vor Standort-Upgrades

Vor dem Upgrade müssen Sie den Zustand und die Konnektivität der MetroCluster Konfiguration überprüfen.

Schritte

  1. Überprüfen Sie den Betrieb der MetroCluster-Konfiguration in ONTAP:

    1. Prüfen Sie, ob die Knoten multipathed sind:
      node run -node node-name sysconfig -a

      Sie sollten diesen Befehl für jeden Node in der MetroCluster-Konfiguration ausgeben.

    2. Stellen Sie sicher, dass in der Konfiguration: + keine defekten Festplatten vorhanden sind storage disk show -broken

      Sie sollten diesen Befehl für jeden Node in der MetroCluster-Konfiguration ausgeben.

    3. Überprüfen Sie auf Statusmeldungen:

      system health alert show

      Sie sollten diesen Befehl für jedes Cluster ausgeben.

    4. Überprüfen Sie die Lizenzen auf den Clustern:

      system license show

      Sie sollten diesen Befehl für jedes Cluster ausgeben.

    5. Überprüfen Sie die mit den Knoten verbundenen Geräte:

      network device-discovery show

      Sie sollten diesen Befehl für jedes Cluster ausgeben.

    6. Vergewissern Sie sich, dass Zeitzone und Uhrzeit auf beiden Standorten richtig eingestellt sind:

      cluster date show

    Sie sollten diesen Befehl für jedes Cluster ausgeben. Sie können das verwenden cluster date Befehle zum Konfigurieren der Zeit- und Zeitzone.

  2. Überprüfen Sie den Betriebsmodus der MetroCluster Konfiguration, und führen Sie eine MetroCluster-Prüfung durch.

    1. Bestätigen Sie die MetroCluster-Konfiguration und den Betriebsmodus normal:
      metrocluster show

    2. Vergewissern Sie sich, dass alle erwarteten Knoten angezeigt werden:
      metrocluster node show

    3. Geben Sie den folgenden Befehl ein:

      metrocluster check run

    4. Ergebnisse der MetroCluster-Prüfung anzeigen:

      metrocluster check show

  3. Prüfen Sie die MetroCluster-Verkabelung mit dem Tool Config Advisor.

    1. Laden Sie Config Advisor herunter und führen Sie sie aus.

      "NetApp Downloads: Config Advisor"

    2. Überprüfen Sie nach dem Ausführen von Config Advisor die Ausgabe des Tools und befolgen Sie die Empfehlungen in der Ausgabe, um die erkannten Probleme zu beheben.

Sammeln von Informationen vor dem Upgrade

Vor dem Upgrade müssen Informationen für alle Nodes gesammelt und bei Bedarf die Netzwerk-Broadcast-Domänen angepasst, beliebige VLANs und Schnittstellengruppen entfernt und Verschlüsselungsinformationen gesammelt werden.

Schritte

  1. Notieren Sie die physische Verkabelung für jeden Node und kennzeichnen Sie die Kabel nach Bedarf, damit die neue Nodes ordnungsgemäß verkabelt werden.

  2. Erfassung von Interconnect-, Port- und LIF-Informationen für jeden Node

    Sie sollten die Ausgabe der folgenden Befehle für jeden Node erfassen:

    • metrocluster interconnect show

    • metrocluster configuration-settings connection show

    • network interface show -role cluster,node-mgmt

    • network port show -node node_name -type physical

    • network port vlan show -node node-name

    • network port ifgrp show -node node_name -instance

    • network port broadcast-domain show

    • network port reachability show -detail

    • network ipspace show

    • volume show

    • storage aggregate show

    • system node run -node node-name sysconfig -a

    • vserver fcp initiator show

    • storage disk show

    • metrocluster configuration-settings interface show

  3. Erfassen Sie die UUIDs für Site_B (die Site, an der die Plattformen gerade aktualisiert werden):

    metrocluster node show -fields node-cluster-uuid, node-uuid

    Diese Werte müssen auf den neuen Controller-Modulen „Site_B“ genau konfiguriert werden, um eine erfolgreiche Aktualisierung zu gewährleisten. Kopieren Sie die Werte in eine Datei, damit Sie sie später im Upgrade-Prozess in die richtigen Befehle kopieren können.

    Im folgenden Beispiel wird die Befehlsausgabe mit den UUIDs angezeigt:

    cluster_B::> metrocluster node show -fields node-cluster-uuid, node-uuid
  (metrocluster node show)
dr-group-id cluster     node   node-uuid                            node-cluster-uuid
----------- --------- -------- ------------------------------------ ------------------------------
1           cluster_A node_A_1 f03cb63c-9a7e-11e7-b68b-00a098908039 ee7db9d5-9a82-11e7-b68b-00a098908039
1           cluster_A node_A_2 aa9a7a7a-9a81-11e7-a4e9-00a098908c35 ee7db9d5-9a82-11e7-b68b-00a098908039
1           cluster_B node_B_1 f37b240b-9ac1-11e7-9b42-00a098c9e55d 07958819-9ac6-11e7-9b42-00a098c9e55d
1           cluster_B node_B_2 bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f 07958819-9ac6-11e7-9b42-00a098c9e55d
4 entries were displayed.
cluster_B::*

    Es wird empfohlen, die UUIDs in eine Tabelle wie die folgende aufzunehmen.

    Cluster oder Node

    UUID

    Cluster_B

    07958819-9ac6-11e7-9b42-00a098c9e55d

    Knoten_B_1

    F37b240b-9ac1-11e7-9b42-00a098c9e55d

    Knoten_B_2

    Bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f

    Cluster_A

    E7db9d5-9a82-11e7-b68b-00a098908039

    Node_A_1

    F03cb63c-9a7e-11e7-b68b-00a098908039

    Node_A_2

    Aa9a7a7a-9a81-11e7-a4e9-00a098908c35

  4. Wenn sich die MetroCluster-Nodes in einer SAN-Konfiguration befinden, sammeln Sie die relevanten Informationen.

    Sie sollten die Ausgabe der folgenden Befehle erfassen:

    • fcp adapter show -instance

    • fcp interface show -instance

    • iscsi interface show

    • ucadmin show

  5. Wenn das Root-Volume verschlüsselt ist, erfassen und speichern Sie die für das Schlüsselmanagement verwendete Passphrase:

    security key-manager backup show

  6. Wenn die MetroCluster Nodes Verschlüsselung für Volumes oder Aggregate nutzen, kopieren Sie Informationen zu Schlüsseln und Passphrases.

    Weitere Informationen finden Sie unter "Manuelles Backup der integrierten Verschlüsselungsmanagementinformationen".

    1. Wenn Onboard Key Manager konfiguriert ist:
      security key-manager onboard show-backup

      Sie benötigen die Passphrase später im Upgrade-Verfahren.

    2. Wenn das Enterprise-Verschlüsselungsmanagement (KMIP) konfiguriert ist, geben Sie die folgenden Befehle ein:

      security key-manager external show -instance security key-manager key query

  7. Ermitteln Sie die System-IDs der vorhandenen Nodes:

    metrocluster node show -fields node-systemid,ha-partner-systemid,dr-partner-systemid,dr-auxiliary-systemid

    Die folgende Ausgabe zeigt die neu zugewiesen Laufwerke.

    ::> metrocluster node show -fields node-systemid,ha-partner-systemid,dr-partner-systemid,dr-auxiliary-systemid

dr-group-id cluster     node     node-systemid ha-partner-systemid dr-partner-systemid dr-auxiliary-systemid
----------- ----------- -------- ------------- ------------------- ------------------- ---------------------
1           cluster_A node_A_1   537403324     537403323           537403321           537403322
1           cluster_A node_A_2   537403323     537403324           537403322           537403321
1           cluster_B node_B_1   537403322     537403321           537403323           537403324
1           cluster_B node_B_2   537403321     537403322           537403324           537403323
4 entries were displayed.

Mediator- oder Tiebreaker-Überwachung wird entfernt

Vor dem Aktualisieren der Plattformen müssen Sie die Überwachung entfernen, wenn die MetroCluster-Konfiguration mit dem Tiebreaker oder Mediator Utility überwacht wird.

Schritte

  1. Sammeln Sie die Ausgabe für den folgenden Befehl:

    storage iscsi-initiator show

  2. Entfernen Sie die vorhandene MetroCluster-Konfiguration von Tiebreaker, Mediator oder einer anderen Software, die die Umschaltung initiieren kann.

    Sie verwenden…​

    Gehen Sie folgendermaßen vor:

    Tiebreaker

    "Entfernen von MetroCluster-Konfigurationen" Im Installations- und Konfigurationshandbuch MetroCluster Tiebreaker

    Mediator

    Geben Sie den folgenden Befehl an der ONTAP-Eingabeaufforderung ein:

    metrocluster configuration-settings mediator remove

    Applikationen von Drittanbietern

    Siehe Produktdokumentation.

Senden einer benutzerdefinierten AutoSupport Meldung vor der Wartung

Bevor Sie die Wartung durchführen, sollten Sie eine AutoSupport Meldung ausgeben, um den technischen Support von NetApp über die laufende Wartung zu informieren. Die Mitteilung des technischen Supports über laufende Wartungsarbeiten verhindert, dass ein Fall eröffnet wird, wenn eine Störung aufgetreten ist.

Über diese Aufgabe

Diese Aufgabe muss auf jedem MetroCluster-Standort ausgeführt werden.

Schritte

  1. Melden Sie sich bei dem Cluster an.

  2. Rufen Sie eine AutoSupport-Meldung auf, die den Beginn der Wartung angibt:

    system node autosupport invoke -node * -type all -message MAINT=maintenance-window-in-hours

    Der maintenance-window-in-hours Parameter gibt die Länge des Wartungsfensters an, mit maximal 72 Stunden. Wenn die Wartung vor dem Vergehen der Zeit abgeschlossen ist, können Sie eine AutoSupport-Meldung mit dem Ende des Wartungszeitraums aufrufen:

    system node autosupport invoke -node * -type all -message MAINT=end

  3. Wiederholen Sie diese Schritte auf der Partner-Site.

Umschalten der MetroCluster-Konfiguration

Sie müssen die Konfiguration auf Site_A umschalten, damit die Plattformen auf Site_B aktualisiert werden können.

Über diese Aufgabe

Diese Aufgabe muss auf Site_A ausgeführt werden

Nach Abschluss dieser Aufgabe ist Cluster_A aktiv und stellt Daten für beide Standorte bereit. Cluster_B ist inaktiv und kann den Upgrade-Prozess starten.

Upgrade von mcc Cluster A bei Switchover
Schritte

  1. Wechseln Sie über die MetroCluster-Konfiguration zu Site_A, damit Site_B-Knoten aktualisiert werden können:

    1. Geben Sie den folgenden Befehl für Cluster_A ein:

      metrocluster switchover -controller-replacement true

      Der Vorgang kann einige Minuten dauern.

    2. Überwachen Sie den Switchover-Betrieb:

      metrocluster operation show

    3. Nach Abschluss des Vorgangs bestätigen Sie, dass die Nodes sich im Switchstatus befinden:

      metrocluster show

    4. Den Status der MetroCluster-Knoten überprüfen:

      metrocluster node show

    Das automatische Heilen von Aggregaten nach der ausgehandelten Umschaltung wird während eines Controller-Upgrades deaktiviert.

Entfernen von Schnittstellenkonfigurationen und Deinstallation der alten Controller

Sie müssen Daten-LIFs zu einem gemeinsamen Port verschieben, VLANs und Schnittstellengruppen auf den alten Controllern entfernen und dann die Controller physisch deinstallieren.

Über diese Aufgabe
Schritte

  1. Booten der alten Nodes und melden Sie sich bei den Nodes an:

    boot_ontap

  2. Weisen Sie den Home-Port aller Daten-LIFs des alten Controllers einem gemeinsamen Port zu, der auf den alten und den neuen Controller-Modulen identisch ist.

    1. Anzeigen der LIFs:

      network interface show

      Alle Daten-LIFS einschließlich SAN und NAS befinden sich in Betrieb, da sie sich am Switchover-Standort (Cluster_A) befinden.

    2. Überprüfen Sie die Ausgabe, um einen gemeinsamen physischen Netzwerk-Port zu finden, der auf den alten und den neuen Controllern identisch ist, die nicht als Cluster-Port verwendet werden.

      e0d ist zum Beispiel ein physischer Port auf den alten Controllern und ist auch auf neuen Controllern vorhanden. e0d wird nicht als Cluster-Port oder anderweitig auf den neuen Controllern verwendet.

      Informationen zur Portnutzung von Plattformmodellen finden Sie im "NetApp Hardware Universe"

    3. Ändern Sie alle Daten-LIFS, um den gemeinsamen Port als Startport zu verwenden:
      network interface modify -vserver svm-name -lif data-lif -home-port port-id

      Im folgenden Beispiel ist dies "e0d".

      Beispiel:

    network interface modify -vserver vs0 -lif datalif1 -home-port e0d

  3. Entfernen Sie alle VLAN-Ports mithilfe von Cluster-Ports als Mitgliedsports und ifgrps, die Cluster-Ports als Mitgliedsports verwenden.

    1. VLAN-Ports löschen:
      network port vlan delete -node node-name -vlan-name portid-vlandid

      Beispiel:

      network port vlan delete -node node1 -vlan-name e1c-80

    2. Entfernen Sie physische Ports aus den Schnittstellengruppen:

      network port ifgrp remove-port -node node-name -ifgrp interface-group-name -port portid

      Beispiel:

    network port ifgrp remove-port -node node1 -ifgrp a1a -port e0d

    1. Entfernen Sie VLAN und Interface Group Ports aus Broadcast-Domäne:

      network port broadcast-domain remove-ports -ipspace ipspace -broadcast-domain broadcast-domain-name -ports nodename:portname,nodename:portname,..

    2. Ändern Sie die Schnittstellengruppen-Ports, um bei Bedarf andere physische Ports als Mitglied zu verwenden:

      ifgrp add-port -node node-name -ifgrp interface-group-name -port port-id

  4. Beenden Sie die Knoten der LOADER-Eingabeaufforderung:

    halt -inhibit-takeover true

  5. Stellen Sie eine Verbindung mit der seriellen Konsole der alten Controller (Node_B_1-old und Node_B_2-old) an Site_B her, und überprüfen Sie, dass die LOADER-Eingabeaufforderung angezeigt wird.

  6. Ermitteln Sie die Bootarg-Werte:

    printenv

  7. Trennen Sie die Speicher- und Netzwerkverbindungen auf Node_B_1-old und Node_B_2-old, und kennzeichnen Sie die Kabel, damit sie wieder mit den neuen Nodes verbunden werden können.

  8. Trennen Sie die Stromkabel von Node_B_1-old und Node_B_2-old.

  9. Entfernen Sie die Controller Node_B_1-old und Node_B_2-old aus dem Rack.

Aktualisierung der Switch-RCFs für die neuen Plattformen

Sie müssen die Switches auf eine Konfiguration aktualisieren, die die neuen Plattformmodelle unterstützt.

Über diese Aufgabe

Diese Aufgabe führen Sie an dem Standort mit den derzeit aktualisierten Controllern durch. In den Beispielen, die in diesem Verfahren gezeigt werden, aktualisieren wir zunächst Site_B.

Bei einem Upgrade der Controller On Site_A werden die Switches von Site_A aktualisiert.

Schritte

  1. Bereiten Sie die IP-Schalter für die Anwendung der neuen RCF-Dateien vor.

    Befolgen Sie die Schritte im Verfahren für Ihren Switch-Anbieter:

    "Installation und Konfiguration von MetroCluster IP"

  2. Laden Sie die RCF-Dateien herunter und installieren Sie sie.

    Folgen Sie den Schritten im Abschnitt Ihres Switch-Anbieters vom "Installation und Konfiguration von MetroCluster IP".

Konfigurieren der neuen Controller

Sie müssen die Controller im Rack unterbringen und installieren, die erforderliche Einrichtung im Wartungsmodus durchführen und dann die Controller booten und die LIF-Konfiguration auf den Controllern überprüfen.

Einrichten der neuen Controller

Sie müssen die neuen Controller im Rack unterbringen und verkabeln.

Schritte

  1. Planen Sie die Positionierung der neuen Controller-Module und Storage Shelves je nach Bedarf.

    Der Rack-Platz hängt vom Plattformmodell der Controller-Module, den Switch-Typen und der Anzahl der Storage-Shelfs in Ihrer Konfiguration ab.

  2. Richtig gemahlen.

  3. Installieren Sie die Controller-Module im Rack oder Schrank.

    "Dokumentation zu ONTAP Hardwaresystemen"

  4. Verbinden Sie die Controller mit den IP-Switches, wie in beschrieben "Installation und Konfiguration von MetroCluster IP".

  5. Starten Sie die neuen Nodes und starten Sie sie in den Wartungsmodus.

Wiederherstellen der HBA-Konfiguration

Je nach Vorhandensein und Konfiguration der HBA-Karten im Controller-Modul müssen Sie diese für die Verwendung Ihres Standorts richtig konfigurieren.

Schritte

  1. Konfigurieren Sie im Wartungsmodus die Einstellungen für alle HBAs im System:

    1. Überprüfen Sie die aktuellen Einstellungen der Ports:

      ucadmin show

    2. Aktualisieren Sie die Porteinstellungen nach Bedarf.

    Wenn Sie über diese Art von HBA und den gewünschten Modus verfügen…​

    Befehl

    CNA FC

    ucadmin modify -m fc -t initiator adapter-name

    CNA-Ethernet

    ucadmin modify -mode cna adapter-name

    FC-Ziel

    fcadmin config -t target adapter-name

    FC-Initiator

    fcadmin config -t initiator adapter-name

  2. Beenden des Wartungsmodus:

    halt

    Warten Sie, bis der Node an der LOADER-Eingabeaufforderung angehalten wird, nachdem Sie den Befehl ausgeführt haben.

  3. Starten Sie den Node wieder in den Wartungsmodus, damit die Konfigurationsänderungen wirksam werden:

    boot_ontap maint

  4. Überprüfen Sie die vorgenommenen Änderungen:

    Wenn Sie über diese Art von HBA verfügen…​

    Befehl

    CNA

    ucadmin show

    FC

    fcadmin show

Einstellen des HA-Status auf den neuen Controllern und dem Chassis

Sie müssen den HA-Status der Controller und des Chassis überprüfen. Bei Bedarf müssen Sie den Status entsprechend Ihrer Systemkonfiguration aktualisieren.

Schritte

  1. Zeigen Sie im Wartungsmodus den HA-Status des Controller-Moduls und des Chassis an:

    ha-config show

    Der HA-Status für alle Komponenten sollte „mccip“ sein.

  2. Wenn der angezeigte Systemzustand des Controllers oder Chassis nicht korrekt ist, setzen Sie den HA-Status ein:

    ha-config modify controller mccip

    ha-config modify chassis mccip

Festlegen der MetroCluster-IP-Bootarg-Variablen

Für die neuen Controller-Module müssen bestimmte MetroCluster IP-Bootarg-Werte konfiguriert werden. Die Werte müssen mit den auf den alten Controller-Modulen konfigurierten übereinstimmen.

Über diese Aufgabe

In dieser Aufgabe verwenden Sie die UUIDs und System-IDs, die bereits im Upgrade-Verfahren in identifiziert wurden "Sammeln von Informationen vor dem Upgrade".

Schritte

  1. Wenn die Nodes des Upgrades die Modelle AFF A400, FAS8300 oder FAS8700 umfassen, legen Sie die folgenden Boot-Bereiche an DER LOADER-Eingabeaufforderung fest:

    setenv bootarg.mcc.port_a_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address,vlan-id

    setenv bootarg.mcc.port_b_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address,vlan-id

    Hinweis Wenn die Schnittstellen Standard-VLANs verwenden, ist keine vlan-id erforderlich.

    Mit den folgenden Befehlen werden die Werte für Node_B_1-New unter Verwendung von VLAN 120 für das erste Netzwerk und VLAN 130 für das zweite Netzwerk festgelegt:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12,120
setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12,130

    Die folgenden Befehle legen die Werte für Node_B_2-New unter Verwendung von VLAN 120 für das erste Netzwerk und VLAN 130 für das zweite Netzwerk fest:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13,120
setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13,130

    Das folgende Beispiel zeigt die Befehle für Node_B_1-New bei Verwendung des Standard-VLAN:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12
setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12

    Das folgende Beispiel zeigt die Befehle für Node_B_2-New bei Verwendung des Standard-VLAN:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13
setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13

  2. Wenn die Knoten, die aktualisiert werden, keine Systeme im vorherigen Schritt sind, legen Sie bei der LOADER-Eingabeaufforderung für jeden der verbleibenden Nodes die folgenden Bootargs mit local_IP/maska fest:

    setenv bootarg.mcc.port_a_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address

    setenv bootarg.mcc.port_b_ip_config local-IP-address/local-IP-mask,0,HA-partner-IP-address,DR-partner-IP-address,DR-aux-partnerIP-address

    Mit den folgenden Befehlen werden die Werte für Node_B_1-New festgelegt:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.10/23,0,172.17.26.11,172.17.26.13,172.17.26.12
setenv bootarg.mcc.port_b_ip_config 172.17.27.10/23,0,172.17.27.11,172.17.27.13,172.17.27.12

    Mit den folgenden Befehlen werden die Werte für Node_B_2-New festgelegt:

    setenv bootarg.mcc.port_a_ip_config 172.17.26.11/23,0,172.17.26.10,172.17.26.12,172.17.26.13
setenv bootarg.mcc.port_b_ip_config 172.17.27.11/23,0,172.17.27.10,172.17.27.12,172.17.27.13

  3. Legen Sie an DER LOADER-Eingabeaufforderung der neuen Nodes die UUUIDs fest:

    setenv bootarg.mgwd.partner_cluster_uuid partner-cluster-UUID

    setenv bootarg.mgwd.cluster_uuid local-cluster-UUID

    setenv bootarg.mcc.pri_partner_uuid DR-partner-node-UUID

    setenv bootarg.mcc.aux_partner_uuid DR-aux-partner-node-UUID

    setenv bootarg.mcc_iscsi.node_uuid local-node-UUID

    1. Legen Sie die UUIDs auf Node_B_1-New fest.

      Im folgenden Beispiel werden die Befehle zum Einstellen der UUIDs auf Node_B_1-New angezeigt:

      setenv bootarg.mgwd.cluster_uuid ee7db9d5-9a82-11e7-b68b-00a098908039
setenv bootarg.mgwd.partner_cluster_uuid 07958819-9ac6-11e7-9b42-00a098c9e55d
setenv bootarg.mcc.pri_partner_uuid f37b240b-9ac1-11e7-9b42-00a098c9e55d
setenv bootarg.mcc.aux_partner_uuid bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f
setenv bootarg.mcc_iscsi.node_uuid f03cb63c-9a7e-11e7-b68b-00a098908039

    2. Legen Sie die UUIDs auf Node_B_2-New fest:

      Im folgenden Beispiel werden die Befehle zum Einstellen der UUIDs auf Node_B_2-New angezeigt:

    setenv bootarg.mgwd.cluster_uuid ee7db9d5-9a82-11e7-b68b-00a098908039
setenv bootarg.mgwd.partner_cluster_uuid 07958819-9ac6-11e7-9b42-00a098c9e55d
setenv bootarg.mcc.pri_partner_uuid bf8e3f8f-9ac4-11e7-bd4e-00a098ca379f
setenv bootarg.mcc.aux_partner_uuid f37b240b-9ac1-11e7-9b42-00a098c9e55d
setenv bootarg.mcc_iscsi.node_uuid aa9a7a7a-9a81-11e7-a4e9-00a098908c35

  4. Wenn die Originalsysteme für ADP konfiguriert wurden, aktivieren Sie an der LOADER-Eingabeaufforderung der Ersatz-Nodes ADP:

    setenv bootarg.mcc.adp_enabled true

  5. Legen Sie die folgenden Variablen fest:

    setenv bootarg.mcc.local_config_id original-sys-id

    setenv bootarg.mcc.dr_partner dr-partner-sys-id

    Hinweis Der setenv bootarg.mcc.local_config_id Variable muss auf die sys-id des original Controller-Moduls, Node_B_1-old, gesetzt werden.

    1. Legen Sie die Variablen auf Node_B_1-New fest.

      Im folgenden Beispiel werden die Befehle zum Einstellen der Werte auf Node_B_1-New angezeigt:

      setenv bootarg.mcc.local_config_id 537403322
setenv bootarg.mcc.dr_partner 537403324

    2. Legen Sie die Variablen auf Node_B_2-New fest.

      Im folgenden Beispiel werden die Befehle zum Einstellen der Werte auf Node_B_2-New angezeigt:

    setenv bootarg.mcc.local_config_id 537403321
setenv bootarg.mcc.dr_partner 537403323

  6. Wenn Sie die Verschlüsselung mit dem externen Schlüsselmanager verwenden, legen Sie die erforderlichen Bootargs fest:

    setenv bootarg.kmip.init.ipaddr

    setenv bootarg.kmip.kmip.init.netmask

    setenv bootarg.kmip.kmip.init.gateway

    setenv bootarg.kmip.kmip.init.interface

Neuzuweisen von Root-Aggregatfestplatten

Weisen Sie die Root-Aggregat-Festplatten dem neuen Controller-Modul unter Verwendung der zuvor gesammelten Sysiden wieder zu.

Über diese Aufgabe

Diese Schritte werden im Wartungsmodus ausgeführt.

Hinweis Root-Aggregat-Festplatten sind die einzigen Festplatten, die während des Controller-Upgrades neu zugewiesen werden müssen. Die Eigentumsrechte an Datenaggregaten werden im Rahmen des Switchover/Switchback-Vorgangs übernommen.
Schritte

  1. Starten des Systems in den Wartungsmodus:

    boot_ontap maint

  2. Zeigen Sie die Festplatten auf Node_B_1-New in der Eingabeaufforderung Wartungsmodus an:

    disk show -a

    Die Befehlsausgabe zeigt die System-ID des neuen Controller-Moduls (1574774970). Allerdings sind die Root-Aggregat-Festplatten immer noch im Besitz der alten System-ID (537403322). In diesem Beispiel werden keine Laufwerke angezeigt, die sich im Besitz anderer Nodes in der MetroCluster-Konfiguration befinden.

    *> disk show -a
Local System ID: 1574774970
DISK                  OWNER                 POOL   SERIAL NUMBER   HOME                  DR HOME
------------          ---------             -----  -------------   -------------         -------------
prod3-rk18:9.126L44   node_B_1-old(537403322)  Pool1  PZHYN0MD     node_B_1-old(537403322)  node_B_1-old(537403322)
prod4-rk18:9.126L49   node_B_1-old(537403322)  Pool1  PPG3J5HA     node_B_1-old(537403322)  node_B_1-old(537403322)
prod4-rk18:8.126L21   node_B_1-old(537403322)  Pool1  PZHTDSZD     node_B_1-old(537403322)  node_B_1-old(537403322)
prod2-rk18:8.126L2    node_B_1-old(537403322)  Pool0  S0M1J2CF     node_B_1-old(537403322)  node_B_1-old(537403322)
prod2-rk18:8.126L3    node_B_1-old(537403322)  Pool0  S0M0CQM5     node_B_1-old(537403322)  node_B_1-old(537403322)
prod1-rk18:9.126L27   node_B_1-old(537403322)  Pool0  S0M1PSDW     node_B_1-old(537403322)  node_B_1-old(537403322)
.
.
.

  3. Weisen Sie die Root-Aggregat-Disks in den Laufwerk-Shelfs den neuen Controllern wieder zu.

    Wenn Sie ADP verwenden…​

    Verwenden Sie dann diesen Befehl…​

    Ja.

    disk reassign -s old-sysid -d new-sysid -r dr-partner-sysid

    Nein

    disk reassign -s old-sysid -d new-sysid

  4. Weisen Sie die Root-Aggregat-Festplatten in den Laufwerk-Shelfs den neuen Controllern neu zu:

    disk reassign -s old-sysid -d new-sysid

    Das folgende Beispiel zeigt die Neuzuweisung von Laufwerken in einer nicht-ADP-Konfiguration:

    *> disk reassign -s 537403322 -d 1574774970
Partner node must not be in Takeover mode during disk reassignment from maintenance mode.
Serious problems could result!!
Do not proceed with reassignment if the partner is in takeover mode. Abort reassignment (y/n)? n

After the node becomes operational, you must perform a takeover and giveback of the HA partner node to ensure disk reassignment is successful.
Do you want to continue (y/n)? y
Disk ownership will be updated on all disks previously belonging to Filer with sysid 537403322.
Do you want to continue (y/n)? y

  5. Überprüfen Sie, ob die Festplatten des Root-Aggregats ordnungsgemäß neu zugewiesen sind.

    disk show

    storage aggr status

    *> disk show
Local System ID: 537097247

  DISK                    OWNER                    POOL   SERIAL NUMBER   HOME                     DR HOME
------------              -------------            -----  -------------   -------------            -------------
prod03-rk18:8.126L18 node_B_1-new(537097247)  Pool1  PZHYN0MD        node_B_1-new(537097247)   node_B_1-new(537097247)
prod04-rk18:9.126L49 node_B_1-new(537097247)  Pool1  PPG3J5HA        node_B_1-new(537097247)   node_B_1-new(537097247)
prod04-rk18:8.126L21 node_B_1-new(537097247)  Pool1  PZHTDSZD        node_B_1-new(537097247)   node_B_1-new(537097247)
prod02-rk18:8.126L2  node_B_1-new(537097247)  Pool0  S0M1J2CF        node_B_1-new(537097247)   node_B_1-new(537097247)
prod02-rk18:9.126L29 node_B_1-new(537097247)  Pool0  S0M0CQM5        node_B_1-new(537097247)   node_B_1-new(537097247)
prod01-rk18:8.126L1  node_B_1-new(537097247)  Pool0  S0M1PSDW        node_B_1-new(537097247)   node_B_1-new(537097247)
::>
::> aggr status
           Aggr          State           Status                Options
aggr0_node_B_1           online          raid_dp, aggr         root, nosnap=on,
                                         mirrored              mirror_resync_priority=high(fixed)
                                         fast zeroed
                                         64-bit

Booten der neuen Controller

Sie müssen die neuen Controller booten, um sicherzustellen, dass die Bootarg-Variablen korrekt sind und, falls erforderlich, die Verschlüsselungswiederherstellungsschritte durchführen.

Schritte

  1. Anhalten der neuen Knoten:

    halt

  2. Wenn der externe Schlüsselmanager konfiguriert ist, legen Sie die zugehörigen Bootargs fest:

    setenv bootarg.kmip.init.ipaddr ip-address

    setenv bootarg.kmip.init.netmask netmask

    setenv bootarg.kmip.init.gateway gateway-address

    setenv bootarg.kmip.init.interface interface-id

  3. Überprüfen Sie, ob die Partner-sysid aktuell ist:

    printenv partner-sysid

    Falls Partner-sysid nicht richtig ist, stellen Sie es fest:

    setenv partner-sysid partner-sysID

  4. ONTAP-Startmenü anzeigen:

    boot_ontap menu

  5. Wenn die Stammverschlüsselung verwendet wird, wählen Sie die Startmenü-Option für Ihre Konfiguration für die Schlüsselverwaltung aus.

    Sie verwenden…​

    Diese Startmenüoption auswählen…​

    Integriertes Verschlüsselungsmanagement

    Option 10

    Befolgen Sie die Anweisungen, um die erforderlichen Eingaben zur Wiederherstellung und Wiederherstellung der Schlüsselmanager-Konfiguration bereitzustellen.

    Externes Verschlüsselungskeymanagement

    Option 11

    Befolgen Sie die Anweisungen, um die erforderlichen Eingaben zur Wiederherstellung und Wiederherstellung der Schlüsselmanager-Konfiguration bereitzustellen.

  6. Wählen Sie im Startmenü „(6) Flash-Update aus Backup config“ aus.

    Hinweis Mit Option 6 wird der Node vor Abschluss zweimal neu gestartet.

    Beantworten Sie „y“ auf die Eingabeaufforderungen zur Änderung der System-id. Warten Sie auf die zweite Neustartmeldung:

    Successfully restored env file from boot media...

Rebooting to load the restored env file...

  7. Überprüfen Sie am LOADER die Bootarg-Werte und aktualisieren Sie die Werte nach Bedarf.

    Verwenden Sie die Schritte in "Festlegen der MetroCluster-IP-Bootarg-Variablen".

  8. Überprüfen Sie doppelt, ob die Partner-Sysid die richtige ist:

    printenv partner-sysid

    Falls Partner-sysid nicht richtig ist, stellen Sie es fest:

    setenv partner-sysid partner-sysID

  9. Wenn die Stammverschlüsselung verwendet wird, wählen Sie die Startmenü-Option erneut für Ihre Schlüsselverwaltungskonfiguration aus.

    Sie verwenden…​

    Diese Startmenüoption auswählen…​

    Integriertes Verschlüsselungsmanagement

    Option 10

    Befolgen Sie die Anweisungen, um die erforderlichen Eingaben zur Wiederherstellung und Wiederherstellung der Schlüsselmanager-Konfiguration bereitzustellen.

    Externes Verschlüsselungskeymanagement

    Option „11“

    Befolgen Sie die Anweisungen, um die erforderlichen Eingaben zur Wiederherstellung und Wiederherstellung der Schlüsselmanager-Konfiguration bereitzustellen.

    Führen Sie je nach Einstellung des Schlüsselmanagers den Wiederherstellungsvorgang durch, indem Sie die Option „10“ oder die Option „11“ und anschließend die Option auswählen 6 Bei der ersten Eingabeaufforderung für das Startmenü. Um die Knoten vollständig zu booten, müssen Sie möglicherweise den Wiederherstellungsvorgang mit Option „1“ (normaler Start) wiederholen.

  10. Warten Sie, bis die ersetzten Nodes gestartet werden.

    Wenn sich einer der beiden Nodes im Übernahmemodus befindet, geben Sie sie mithilfe der wieder storage failover giveback Befehl.

  11. Stellen Sie bei Verwendung der Verschlüsselung die Schlüssel mithilfe des korrekten Befehls für Ihre Verschlüsselungsmanagementkonfiguration wieder her.

    Sie verwenden…​

    Befehl

    Integriertes Verschlüsselungsmanagement

    security key-manager onboard sync

    Weitere Informationen finden Sie unter "Wiederherstellung der integrierten Schlüssel für das Verschlüsselungsmanagement".

    Externes Verschlüsselungskeymanagement

    `security key-manager external restore -vserver SVM -node node -key-server _host_name

  12. Vergewissern Sie sich, dass sich alle Ports in einer Broadcast-Domäne befinden:

    1. Broadcast-Domänen anzeigen:

      network port broadcast-domain show

    2. Fügen Sie bei Bedarf beliebige Ports zu einer Broadcast-Domäne hinzu.

      "Hinzufügen oder Entfernen von Ports aus einer Broadcast-Domäne"

    3. VLANs und Schnittstellengruppen nach Bedarf neu erstellen.

      VLAN und Interface Group Mitgliedschaft können sich von der des alten Node unterscheiden.

      "Erstellen eines VLANs"

    "Verbinden von physischen Ports zum Erstellen von Schnittstellengruppen"

Überprüfung und Wiederherstellung der LIF-Konfiguration

Vergewissern Sie sich, dass LIFs zu Beginn des Upgrade-Vorgangs auf entsprechenden Nodes und Ports gehostet werden, die zugeordnet sind.

Über diesen Tsak
Schritte

  1. Stellen Sie vor dem Wechsel sicher, dass LIFs auf dem entsprechenden Node und den entsprechenden Ports gehostet werden.

    1. Ändern Sie die erweiterte Berechtigungsebene:

      set -privilege advanced

    2. Port-Konfiguration überschreiben, um korrekte LIF-Platzierung zu gewährleisten:

      vserver config override -command "network interface modify -vserver vserver_name -home-port active_port_after_upgrade -lif lif_name -home-node new_node_name"

    Wenn Sie den Befehl zur Änderung der Netzwerkschnittstelle in eingeben vserver config override Befehl, Sie können die Funktion Autovervollständigung auf der Registerkarte nicht verwenden. Sie können das Netzwerk erstellen interface modify Verwenden Sie Autocomplete und schließen Sie es dann in das ein vserver config override Befehl.

    1. Zurück zur Administratorberechtigungsebene:

      set -privilege admin

  2. Zurücksetzen der Schnittstellen auf ihren Home-Node:

    network interface revert * -vserver vserver-name

    Führen Sie diesen Schritt bei allen SVMs aus, falls erforderlich.

Umschalten der MetroCluster-Konfiguration

In dieser Aufgabe führen Sie den Vorgang zum zurückwechseln durch, und die MetroCluster-Konfiguration kehrt in den normalen Betrieb zurück. Die Knoten auf Site_A warten noch auf das Upgrade.

upgrade von mcc Cluster A Switchback
Schritte

  1. Stellen Sie das aus metrocluster node show Befehl auf Site_B und überprüfen Sie die Ausgabe.

    1. Vergewissern Sie sich, dass die neuen Nodes korrekt dargestellt sind.

    2. Überprüfen Sie, ob sich die neuen Nodes im Status „Warten auf den Wechsel zurück“ befinden.

  2. Führen Sie die Reparatur und den Wechsel durch, indem Sie die erforderlichen Befehle von einem beliebigen Node im aktiven Cluster ausführen (das Cluster, das kein Upgrade durchlaufen hat).

    1. Heilen Sie die Datenaggregate:
      metrocluster heal aggregates

    2. Heilen Sie die Root-Aggregate:

      metrocluster heal root

    3. Zurückwechseln des Clusters:

      metrocluster switchback

  3. Überprüfen Sie den Fortschritt des Umschalttaschens:

    metrocluster show

    Der Umkehrvorgang läuft noch, wenn die Ausgabe angezeigt wird waiting-for-switchback:

    cluster_B::> metrocluster show
Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_B         Configuration state configured
                          Mode                switchover
                          AUSO Failure Domain -
Remote: cluster_A         Configuration state configured
                          Mode                waiting-for-switchback
                          AUSO Failure Domain -

    Der Umschalttavorgang ist abgeschlossen, wenn der Ausgang normal angezeigt wird:

    cluster_B::> metrocluster show
Cluster                   Entry Name          State
------------------------- ------------------- -----------
 Local: cluster_B         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain -
Remote: cluster_A         Configuration state configured
                          Mode                normal
                          AUSO Failure Domain -

    Wenn ein Wechsel eine lange Zeit in Anspruch nimmt, können Sie den Status der in-progress-Basispläne über die überprüfen metrocluster config-replication resync-status show Befehl. Dieser Befehl befindet sich auf der erweiterten Berechtigungsebene.

Überprüfen des Systemzustands der MetroCluster-Konfiguration

Nach dem Upgrade der Controller-Module müssen Sie den Systemzustand der MetroCluster Konfiguration überprüfen.

Über diese Aufgabe

Diese Aufgabe kann auf jedem Node der MetroCluster Konfiguration ausgeführt werden.

Schritte

  1. Überprüfen Sie den Betrieb der MetroCluster Konfiguration:

    1. Bestätigen Sie die MetroCluster-Konfiguration und den normalen Betriebsmodus:
      metrocluster show

    2. Führen Sie eine MetroCluster-Prüfung durch:
      metrocluster check run

    3. Ergebnisse der MetroCluster-Prüfung anzeigen:

      metrocluster check show

  2. Überprüfen Sie die MetroCluster-Konnektivität und den Status.

    1. Prüfen Sie die MetroCluster-IP-Verbindungen:

      storage iscsi-initiator show

    2. Prüfen Sie, ob die Knoten arbeiten:

      metrocluster node show

    3. Überprüfen Sie, ob die MetroCluster IP Schnittstellen aktiv sind:

      metrocluster configuration-settings interface show

    4. Überprüfen Sie, ob lokaler Failover aktiviert ist:

      storage failover show

Aktualisieren der Knoten auf Cluster_A

Sie müssen die Upgrade-Aufgaben auf „Cluster_A“ wiederholen

Schritte

  1. Wiederholen Sie die Schritte, um die Nodes auf Cluster_A zu aktualisieren. Beginnen Sie mit "Vorbereitung auf das Upgrade".

    Während Sie die Aufgaben ausführen, werden alle Beispielreferenzen zu den Clustern und Nodes umgekehrt. Wenn das Beispiel für die Umschaltung von Cluster_A verwendet wird, erfolgt die Umschaltung von Cluster_B.

Wiederherstellen der Tiebreaker- oder Mediator-Überwachung

Nach Abschluss des Upgrades der MetroCluster-Konfiguration können Sie die Überwachung mit dem Tiebreaker oder Mediator Utility fortsetzen.

Schritte

  1. Stellen Sie ggf. die Überwachung mithilfe des Verfahrens für Ihre Konfiguration wieder her.

    Sie verwenden…​ Gehen Sie wie folgt vor

    Tiebreaker

    "Hinzufügen von MetroCluster Konfigurationen".

    Mediator

    Link:../install-ip/concept_mediator_requirements.html [Konfigurieren des ONTAP Mediator-Dienstes aus einer MetroCluster IP-Konfiguration].

    Applikationen von Drittanbietern

    Siehe Produktdokumentation.

Senden einer benutzerdefinierten AutoSupport Meldung nach der Wartung

Nach Abschluss des Upgrades sollten Sie eine AutoSupport Meldung mit Angaben zum Ende der Wartung senden. Die automatische Case-Erstellung kann also fortgesetzt werden.

Schritte

  1. Um mit der automatischen Erstellung von Support-Cases fortzufahren, senden Sie eine AutoSupport Meldung, um anzugeben, dass die Wartung abgeschlossen ist.

    1. Geben Sie den folgenden Befehl ein:
      system node autosupport invoke -node * -type all -message MAINT=end

    2. Wiederholen Sie den Befehl im Partner-Cluster.