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

Manuelles unterbrechungsfreies ONTAP Upgrade einer MetroCluster Konfiguration mit vier oder acht Knoten mithilfe der CLI

Beitragende netapp-aherbin netapp-aoife netapp-aaron-holt netapp-dbagwell netapp-ahibbard netapp-thomi
Änderungen vorschlagen
PDFs

Ein manuelles Upgrade einer MetroCluster Konfiguration mit vier oder acht Knoten umfasst die Vorbereitung des Updates, die gleichzeitige Aktualisierung der DR-Paare in jeder der ein oder zwei DR-Gruppen sowie die Durchführung von Aufgaben nach dem Upgrade.

  • Diese Aufgabe gilt für die folgenden Konfigurationen:

    • Vier-Knoten MetroCluster FC- oder IP-Konfigurationen mit ONTAP 9.2 oder älter

    • Acht-Knoten MetroCluster FC-Konfigurationen, unabhängig von ONTAP Version

  • Wenn eine MetroCluster Konfiguration mit zwei Knoten vorliegt, sollte dieses Verfahren nicht verwendet werden.

  • Die folgenden Aufgaben beziehen sich auf die alte und die neue Version von ONTAP.

    • Beim Upgrade ist die alte Version eine frühere Version von ONTAP mit einer niedrigeren Versionsnummer als die neue Version von ONTAP.

    • Beim Downgrade ist die alte Version eine spätere Version von ONTAP mit einer höheren Versionsnummer als die neue Version von ONTAP.

  • Für diese Aufgabe wird folgender übergeordneter Arbeitsablauf verwendet:

    MetroCluster Konfigurationsupgrade-Entscheidungsablauf

Unterschiede beim Aktualisieren der ONTAP Software auf einer Acht-Knoten- oder Vier-Knoten MetroCluster Konfiguration

Der MetroCluster Software-Upgrade-Prozess unterscheidet sich, je nachdem, ob in der MetroCluster Konfiguration acht oder vier Knoten vorhanden sind.

Eine MetroCluster Konfiguration besteht aus einer oder zwei DR-Gruppen. Jede DR-Gruppe besteht aus zwei HA-Paaren, jeweils einem HA-Paar pro MetroCluster Cluster. Eine acht-Knoten MetroCluster Konfiguration umfasst zwei DR-Gruppen:

Diagramm einer Acht-Knoten MetroCluster Konfiguration.

Es wird jeweils eine DR-Gruppe aktualisiert.

Für MetroCluster Konfigurationen mit vier Knoten:

  1. Upgrade von DR-Gruppe eins:

    1. Node_A_1 und Node_B_1 aktualisieren.

    2. Knoten_A_2 und Knoten_B_2 aktualisieren.

Für MetroCluster Konfigurationen mit acht Knoten wird das Upgrade-Verfahren für die DR-Gruppe zweimal durchgeführt:

  1. Upgrade von DR-Gruppe eins:

    1. Node_A_1 und Node_B_1 aktualisieren.

    2. Knoten_A_2 und Knoten_B_2 aktualisieren.

  2. Upgrade DR Gruppe Zwei:

    1. Knoten A_3 und Knoten B_3 aktualisieren.

    2. Knoten_A_4 und Knoten_B_4 aktualisieren.

Vorbereitung der Aktualisierung einer MetroCluster DR-Gruppe

Bevor Sie die ONTAP Software auf den Knoten aktualisieren, müssen Sie die DR-Beziehungen zwischen den Knoten ermitteln, eine AutoSupport Nachricht senden, dass Sie ein Upgrade einleiten, und die auf jedem Knoten laufende ONTAP Version bestätigen.

Sie benötigen "heruntergeladen" und "installiert" die Software-Images.

Dieser Vorgang muss für jede DR-Gruppe wiederholt werden. Besteht die MetroCluster Konfiguration aus acht Knoten, gibt es zwei DR-Gruppen. Daher muss dieser Vorgang für jede DR-Gruppe wiederholt werden.

Die in dieser Aufgabe bereitgestellten Beispiele verwenden die in der folgenden Abbildung gezeigten Namen zur Identifizierung der Cluster und Knoten:

Diagramm einer Acht-Knoten MetroCluster Konfiguration.

  1. Die DR-Paare in der Konfiguration identifizieren:

    metrocluster node show -fields dr-partner
     cluster_A::> metrocluster node show -fields dr-partner
   (metrocluster node show)
 dr-group-id cluster     node       dr-partner
 ----------- -------     --------   ----------
 1           cluster_A   node_A_1   node_B_1
 1           cluster_A   node_A_2   node_B_2
 1           cluster_B   node_B_1   node_A_1
 1           cluster_B   node_B_2   node_A_2
 4 entries were displayed.

 cluster_A::>

  2. Die Berechtigungsstufe wird von admin auf advanced geändert, wobei bei entsprechender Aufforderung y eingegeben wird, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (*>) erscheint.

  3. Die ONTAP Version auf Cluster_A bestätigen:

    system image show
     cluster_A::*> system image show
                  Is      Is                Install
 Node     Image   Default Current Version   Date
 -------- ------- ------- ------- -------   -------------------
 node_A_1
          image1  true    true    X.X.X     MM/DD/YYYY TIME
          image2  false   false   Y.Y.Y     MM/DD/YYYY TIME
 node_A_2
          image1  true    true    X.X.X     MM/DD/YYYY TIME
          image2  false   false   Y.Y.Y     MM/DD/YYYY TIME
 4 entries were displayed.

 cluster_A::>

  4. Die Version auf Cluster_B bestätigen:

    system image show
     cluster_B::*> system image show
                  Is      Is                 Install
 Node     Image   Default Current Version    Date
 -------- ------- ------- ------- -------    -------------------
 node_B_1
          image1  true    true    X.X.X      MM/DD/YYYY TIME
          image2  false   false   Y.Y.Y      MM/DD/YYYY TIME
 node_B_2
          image1  true    true    X.X.X      MM/DD/YYYY TIME
          image2  false   false   Y.Y.Y      MM/DD/YYYY TIME
 4 entries were displayed.

 cluster_B::>

  5. Eine AutoSupport-Benachrichtigung auslösen:

    autosupport invoke -node * -type all -message "Starting_NDU"

    Diese AutoSupport-Benachrichtigung enthält eine Aufzeichnung des Systemstatus vor dem Upgrade. Sie speichert nützliche Informationen zur Fehlerbehebung, falls es während des Upgrade-Prozesses zu Problemen kommt.

    Wenn Ihr Cluster nicht für das Senden von AutoSupport-Nachrichten konfiguriert ist, wird eine Kopie der Benachrichtigung lokal gespeichert.

  6. Für jeden Knoten im ersten Satz wird das Ziel-ONTAP Software-Image als Standard-Image festgelegt:

    system image modify {-node nodename -iscurrent false} -isdefault true

    Dieser Befehl verwendet eine erweiterte Abfrage, um das als alternatives Image installierte Zielsoftware-Image als Standard-Image für den Knoten festzulegen.

  7. Es wird geprüft, ob das Ziel-ONTAP Software-Image auf Cluster_A als Standard-Image festgelegt ist:

    system image show

    Im folgenden Beispiel ist image2 die neue ONTAP Version und wird auf jedem der Knoten in der ersten Gruppe als Standard-Image festgelegt:

     cluster_A::*> system image show
                  Is      Is              Install
 Node     Image   Default Current Version Date
 -------- ------- ------- ------- ------- -------------------
 node_A_1
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true    false   Y.Y.Y   MM/DD/YYYY TIME
 node_A_2
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true   false   Y.Y.Y   MM/DD/YYYY TIME

 2 entries were displayed.

    1. Es wird überprüft, ob das Ziel-ONTAP Software-Image auf Cluster_B als Standard-Image festgelegt ist:

      system image show

      Das folgende Beispiel zeigt, dass die Zielversion auf jedem der Knoten im ersten Satz als Standard-Image festgelegt ist:

     cluster_B::*> system image show
                  Is      Is              Install
 Node     Image   Default Current Version Date
 -------- ------- ------- ------- ------- -------------------
 node_A_1
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true    false   Y.Y.Y   MM/YY/YYYY TIME
 node_A_2
          image1  false   true    X.X.X   MM/DD/YYYY TIME
          image2  true    false   Y.Y.Y   MM/DD/YYYY TIME

 2 entries were displayed.

  8. Ermitteln, ob die zu aktualisierenden Knoten derzeit für jeden Knoten jeweils zweimal Clients bedienen:

    system node run -node target-node -command uptime

    Der Befehl uptime zeigt die Gesamtzahl der Operationen an, die der Knoten seit dem letzten Start für NFS, CIFS, FC und iSCSI Clients ausgeführt hat. Für jedes Protokoll muss der Befehl zweimal ausgeführt werden, um festzustellen, ob die Anzahl der Operationen steigt. Wenn sie steigt, bedient der Knoten derzeit Clients für dieses Protokoll. Wenn sie nicht steigt, bedient der Knoten derzeit keine Clients für dieses Protokoll.

    Hinweis Sie sollten sich jedes Protokoll notieren, bei dem die Anzahl der Client-Operationen zunimmt, damit nach dem Upgrade des Knotens überprüft werden kann, ob der Client-Datenverkehr wieder aufgenommen wurde.

    Dieses Beispiel zeigt einen Knoten mit NFS-, CIFS-, FC- und iSCSI-Operationen. Allerdings bedient der Knoten derzeit nur NFS- und iSCSI-Clients.

     cluster_x::> system node run -node node0 -command uptime
   2:58pm up  7 days, 19:16 800000260 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32810 iSCSI ops

 cluster_x::> system node run -node node0 -command uptime
   2:58pm up  7 days, 19:17 800001573 NFS ops, 1017333 CIFS ops, 0 HTTP ops, 40395 FCP ops, 32815 iSCSI ops

Aktualisierung des ersten DR-Paares in einer MetroCluster DR-Gruppe

Sie müssen die Übernahme und Rückgabe der Knoten in der richtigen Reihenfolge durchführen, damit die neue Version von ONTAP zur aktuellen Version des Knotens wird.

Alle Knoten müssen die alte Version von ONTAP ausführen.

In dieser Aufgabe werden node_A_1 und node_B_1 aktualisiert.

Wenn die ONTAP Software auf der ersten DR-Gruppe aktualisiert wurde und nun die zweite DR-Gruppe in einer Acht-Knoten MetroCluster Konfiguration aktualisiert wird, werden in diesem Schritt node_A_3 und node_B_3 aktualisiert.

  1. Alle Daten-LIFs vom Knoten migrieren:

    network interface migrate-all -node node_A_1
    network interface migrate-all -node node_B_1

  2. Falls die MetroCluster Tiebreaker-Software aktiviert ist, deaktivieren Sie sie.

  3. Für jeden Node im HA-Paar die automatische Rückgabe deaktivieren:

    storage failover modify -node target-node -auto-giveback false

    Dieser Befehl muss für jeden Knoten im HA-Paar wiederholt werden.

  4. Überprüfen, ob das automatische Giveback deaktiviert ist:

    storage failover show -fields auto-giveback

    Dieses Beispiel zeigt, dass die automatische Rückgabe auf beiden Knoten deaktiviert wurde:

     cluster_x::> storage failover show -fields auto-giveback
 node     auto-giveback
 -------- -------------
 node_x_1 false
 node_x_2 false
 2 entries were displayed.

  5. Es ist sicherzustellen, dass die I/O-Auslastung für jeden Controller etwa 50 % nicht überschreitet und die CPU-Auslastung pro Controller ebenfalls nicht über ~50 % liegt.

  6. Eine Übernahme des Zielknotens auf Cluster_A initiieren:

    Der Parameter -option immediate darf nicht angegeben werden, da für den Start der zu übernehmenden Knoten mit dem neuen Software-Image ein normaler Übernahmevorgang erforderlich ist.

    1. Übernahme des DR-Partners auf cluster_A (node_A_1):

      storage failover takeover -ofnode node_A_1

      Der Knoten startet im Zustand "Warten auf Giveback".

      Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport-Meldung gesendet, die darauf hinweist, dass die Knoten das Cluster-Quorum verlassen haben. Diese Benachrichtigung kann ignoriert werden und das Upgrade kann fortgesetzt werden.

    2. Es sollte überprüft werden, ob die Übernahme erfolgreich war:

      storage failover show

      Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Node_A_1 befindet sich im Status „Warten auf Rückgabe“ und node_A_2 im Status „In Übernahme“.

     cluster_A::> storage failover show
                               Takeover
 Node           Partner        Possible State Description
 -------------- -------------- -------- -------------------------------------
 node_A_1       node_A_2       -        Waiting for giveback (HA mailboxes)
 node_A_2       node_A_1       false    In takeover
 2 entries were displayed.

  7. Übernahme des DR-Partners auf cluster_B (node_B_1):

    Der Parameter -option immediate darf nicht angegeben werden, da für den Start der zu übernehmenden Knoten mit dem neuen Software-Image ein normaler Übernahmevorgang erforderlich ist.

    1. Knoten B1 übernehmen:

      storage failover takeover -ofnode node_B_1

      Der Knoten startet im Zustand "Warten auf Giveback".

      Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport-Meldung gesendet, die darauf hinweist, dass die Knoten das Cluster-Quorum verlassen haben. Diese Benachrichtigung kann ignoriert werden und das Upgrade kann fortgesetzt werden.

    2. Es sollte überprüft werden, ob die Übernahme erfolgreich war:

      storage failover show

      Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Node_B_1 befindet sich im Status „Warten auf Rückgabe“ und node_B_2 im Status „In Übernahme“.

     cluster_B::> storage failover show
                               Takeover
 Node           Partner        Possible State Description
 -------------- -------------- -------- -------------------------------------
 node_B_1       node_B_2       -        Waiting for giveback (HA mailboxes)
 node_B_2       node_B_1       false    In takeover
 2 entries were displayed.

  8. Mindestens acht Minuten warten, damit die folgenden Bedingungen sichergestellt sind:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Clients werden nach der Unterbrechung der E/A, die während der Übernahme auftritt, wiederhergestellt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  9. Die Aggregate werden an die Zielknoten zurückgegeben:

    Nach dem Upgrade der MetroCluster IP-Konfigurationen auf ONTAP 9.5 oder höher befinden sich die Aggregate für kurze Zeit in einem degradierten Zustand, bevor sie sich neu synchronisieren und wieder in einen gespiegelten Zustand zurückkehren.

    1. Die Aggregate werden an den DR-Partner auf Cluster_A zurückgegeben:

      storage failover giveback -ofnode node_A_1

    2. Die Aggregate werden an den DR-Partner auf Cluster_B zurückgegeben:

      storage failover giveback -ofnode node_B_1

      Die Giveback-Operation gibt zuerst das Root-Aggregat an den Knoten zurück und gibt dann, nachdem der Knoten den Bootvorgang abgeschlossen hat, die Nicht-Root-Aggregate zurück.

  10. Es sollte überprüft werden, ob alle Aggregate zurückgegeben wurden, indem auf beiden Clustern der folgende Befehl ausgeführt wird:

    storage failover show-giveback

    Wenn das Feld „Rückgabestatus“ anzeigt, dass keine Aggregate zurückzugeben sind, wurden alle Aggregate zurückgegeben. Wenn die Rückgabe abgelehnt wird, zeigt der Befehl den Fortschritt der Rückgabe und das Subsystem an, das die Rückgabe abgelehnt hat.

  11. Wenn Aggregate nicht zurückgegeben wurden, ist Folgendes zu tun:

    1. Die Vorgehensweise zur Umgehung des Veto-Problems kann herangezogen werden, um zu bestimmen, ob die “veto”-Bedingung behoben oder das Veto außer Kraft gesetzt werden soll.

    2. Falls erforderlich sollte die in der Fehlermeldung beschriebene “veto”-Bedingung behoben werden, wobei sichergestellt wird, dass alle identifizierten Operationen ordnungsgemäß beendet werden.

    3. Geben Sie den Befehl storage failover giveback erneut ein.

      Wenn die “veto”-Bedingung außer Kraft gesetzt werden soll, ist der Parameter -override-vetoes auf true zu setzen.

  12. Mindestens acht Minuten warten, damit die folgenden Bedingungen sichergestellt sind:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Die Clients werden nach der Unterbrechung der E/A, die während der Rückgabe auftritt, wiederhergestellt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  13. Die Berechtigungsstufe wird von admin auf advanced geändert, wobei bei entsprechender Aufforderung y eingegeben wird, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (*>) erscheint.

  14. Die Version auf Cluster_A bestätigen:

    system image show

    Das folgende Beispiel zeigt, dass das Systemimage2 (Ziel-ONTAP-Image) die Standard- und aktuelle Version auf node_A_1 ist:

     cluster_A::*> system image show
                  Is      Is               Install
 Node     Image   Default Current Version  Date
 -------- ------- ------- ------- -------- -------------------
 node_A_1
          image1  false   false    X.X.X   MM/DD/YYYY TIME
          image2  true    true     Y.Y.Y   MM/DD/YYYY TIME
 node_A_2
          image1  false   true     X.X.X   MM/DD/YYYY TIME
          image2  true    false    Y.Y.Y   MM/DD/YYYY TIME
 4 entries were displayed.

 cluster_A::>

  15. Die Version auf Cluster_B bestätigen:

    system image show

    Das folgende Beispiel zeigt, dass das Systemimage2 (Ziel-ONTAP-Image) die Standard- und aktuelle Version auf node_B_1 ist:

     cluster_B::*> system image show
                  Is      Is               Install
 Node     Image   Default Current Version  Date
 -------- ------- ------- ------- -------- -------------------
 node_B_1
          image1  false   false    X.X.X   MM/DD/YYYY TIME
          image2  true    true     Y.Y.Y   MM/DD/YYYY TIME
 node_B_2
          image1  false   true     X.X.X   MM/DD/YYYY TIME
          image2  true    false    Y.Y.Y   MM/DD/YYYY TIME
 4 entries were displayed.

 cluster_B::>

Aktualisierung des zweiten DR-Paares in einer MetroCluster DR-Gruppe

Sie müssen die Übernahme und Rückgabe des Knotens in der richtigen Reihenfolge durchführen, damit die neue Version von ONTAP zur aktuellen Version des Knotens wird.

Das erste DR-Paar (node_A_1 und node_B_1) sollte aktualisiert worden sein.

In dieser Aufgabe werden node_A_2 und node_B_2 aktualisiert.

Wenn die ONTAP Software auf der ersten DR-Gruppe aktualisiert wurde und nun die zweite DR-Gruppe in einer Acht-Node MetroCluster Konfiguration aktualisiert wird, werden in dieser Aufgabe node_A_4 und node_B_4 aktualisiert.

  1. Alle Daten-LIFs vom Knoten migrieren:

    network interface migrate-all -node node_A_2
    network interface migrate-all -node node_B_2

  2. Eine Übernahme des Zielknotens auf Cluster_A initiieren:

    Der Parameter -option immediate darf nicht angegeben werden, da für den Start der zu übernehmenden Knoten mit dem neuen Software-Image ein normaler Übernahmevorgang erforderlich ist.

    1. Übernahme des DR-Partners auf Cluster_A:

      storage failover takeover -ofnode node_A_2 -option allow-version-mismatch
      Hinweis Die allow-version-mismatch Option ist weder für Upgrades von ONTAP 9.0 auf ONTAP 9.1 noch für Patch Upgrades erforderlich.

      Der Knoten startet im Zustand "Warten auf Giveback".

      Wenn AutoSupport aktiviert ist, wird eine AutoSupport-Meldung gesendet, die darauf hinweist, dass die Knoten das Cluster-Quorum verlassen haben. Diese Benachrichtigung kann ignoriert werden und das Upgrade kann fortgesetzt werden.

    2. Es sollte überprüft werden, ob die Übernahme erfolgreich war:

      storage failover show

      Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Node_A_2 befindet sich im Status „Warten auf Rückgabe“ und node_A_1 im Status „In Übernahme“.

    cluster_A::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node_A_1       node_A_2       false    In takeover
node_A_2       node_A_1       -        Waiting for giveback (HA mailboxes)
2 entries were displayed.

  3. Eine Übernahme des Zielknotens auf Cluster_B initiieren:

    Der Parameter -option immediate darf nicht angegeben werden, da für den Start der zu übernehmenden Knoten mit dem neuen Software-Image ein normaler Übernahmevorgang erforderlich ist.

    1. Übernahme des DR-Partners auf cluster_B (node_B_2):

      Wenn Sie von …​ ein Upgrade durchführen Geben Sie diesen Befehl ein…​

      ONTAP 9.2 oder ONTAP 9.1

      		 
      storage failover takeover -ofnode node_B_2

      ONTAP 9.0 oder Data ONTAP 8.3.x

      		 
      storage failover takeover -ofnode node_B_2 -option allow-version-mismatch
      Hinweis Die allow-version-mismatch Option ist weder für Upgrades von ONTAP 9.0 auf ONTAP 9.1 noch für Patch Upgrades erforderlich.

      Der Knoten startet im Zustand "Warten auf Giveback".

      Hinweis Wenn AutoSupport aktiviert ist, wird eine AutoSupport-Meldung gesendet, die darauf hinweist, dass die Nodes nicht mehr Teil des Cluster-Quorums sind. Diese Benachrichtigung kann ignoriert werden und das Upgrade kann fortgesetzt werden.

    2. Es sollte überprüft werden, ob die Übernahme erfolgreich war:

      storage failover show

      Das folgende Beispiel zeigt, dass die Übernahme erfolgreich war. Node_B_2 befindet sich im Status „Warten auf Rückgabe“ und node_B_1 im Status „In Übernahme“.

    cluster_B::> storage failover show
                              Takeover
Node           Partner        Possible State Description
-------------- -------------- -------- -------------------------------------
node_B_1       node_B_2       false    In takeover
node_B_2       node_B_1       -        Waiting for giveback (HA mailboxes)
2 entries were displayed.

  4. Mindestens acht Minuten warten, damit die folgenden Bedingungen sichergestellt sind:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Clients werden nach der Unterbrechung der E/A, die während der Übernahme auftritt, wiederhergestellt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  5. Die Aggregate werden an die Zielknoten zurückgegeben:

    Nach dem Upgrade der MetroCluster IP-Konfigurationen auf ONTAP 9.5 befinden sich die Aggregate für kurze Zeit in einem eingeschränkten Zustand, bevor sie sich neu synchronisieren und wieder in einen gespiegelten Zustand zurückkehren.

    1. Die Aggregate werden an den DR-Partner auf Cluster_A zurückgegeben:

      storage failover giveback -ofnode node_A_2

    2. Die Aggregate werden an den DR-Partner auf Cluster_B zurückgegeben:

      storage failover giveback -ofnode node_B_2

      Die Giveback-Operation gibt zuerst das Root-Aggregat an den Knoten zurück und gibt dann, nachdem der Knoten den Bootvorgang abgeschlossen hat, die Nicht-Root-Aggregate zurück.

  6. Es sollte überprüft werden, ob alle Aggregate zurückgegeben wurden, indem auf beiden Clustern der folgende Befehl ausgeführt wird:

    storage failover show-giveback

    Wenn das Feld „Rückgabestatus“ anzeigt, dass keine Aggregate zurückzugeben sind, wurden alle Aggregate zurückgegeben. Wenn die Rückgabe abgelehnt wird, zeigt der Befehl den Fortschritt der Rückgabe und das Subsystem an, das die Rückgabe abgelehnt hat.

  7. Wenn Aggregate nicht zurückgegeben wurden, ist Folgendes zu tun:

    1. Die Vorgehensweise zur Umgehung des Veto-Problems kann herangezogen werden, um zu bestimmen, ob die “veto”-Bedingung behoben oder das Veto außer Kraft gesetzt werden soll.

    2. Falls erforderlich sollte die in der Fehlermeldung beschriebene “veto”-Bedingung behoben werden, wobei sichergestellt wird, dass alle identifizierten Operationen ordnungsgemäß beendet werden.

    3. Geben Sie den Befehl storage failover giveback erneut ein.

      Wenn die “veto”-Bedingung außer Kraft gesetzt werden soll, ist der Parameter -override-vetoes auf true zu setzen.

  8. Mindestens acht Minuten warten, damit die folgenden Bedingungen sichergestellt sind:

    • Client Multipathing (sofern implementiert) ist stabilisiert.

    • Die Clients werden nach der Unterbrechung der E/A, die während der Rückgabe auftritt, wiederhergestellt.

      Die Wiederherstellungszeit ist client-spezifisch und kann abhängig von den Eigenschaften der Client-Anwendungen länger als acht Minuten dauern.

  9. Die Berechtigungsstufe wird von admin auf advanced geändert, wobei bei entsprechender Aufforderung y eingegeben wird, um fortzufahren:

    set -privilege advanced

    Die erweiterte Eingabeaufforderung (*>) erscheint.

  10. Die Version auf Cluster_A bestätigen:

    system image show

    Das folgende Beispiel zeigt, dass das Systemimage2 (Ziel-ONTAP-Image) die Standard- und aktuelle Version auf node_A_2 ist:

    cluster_A::*> system image show
                 Is      Is                 Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- ---------- -------------------
node_A_1
         image1  false   false    X.X.X     MM/DD/YYYY TIME
         image2  true    true     Y.Y.Y     MM/DD/YYYY TIME
node_A_2
         image1  false   false    X.X.X     MM/DD/YYYY TIME
         image2  true    true     Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

cluster_A::>

  11. Die Version auf Cluster_B bestätigen:

    system image show

    Das folgende Beispiel zeigt, dass das Systemimage2 (Ziel-ONTAP-Image) die Standard- und aktuelle Version auf node_B_2 ist:

    cluster_B::*> system image show
                 Is      Is                 Install
Node     Image   Default Current Version    Date
-------- ------- ------- ------- ---------- -------------------
node_B_1
         image1  false   false    X.X.X     MM/DD/YYYY TIME
         image2  true    true     Y.Y.Y     MM/DD/YYYY TIME
node_B_2
         image1  false   false    X.X.X     MM/DD/YYYY TIME
         image2  true    true     Y.Y.Y     MM/DD/YYYY TIME
4 entries were displayed.

cluster_B::>

  12. Für jeden Knoten im HA-Paar die automatische Rückgabe aktivieren:

    storage failover modify -node target-node -auto-giveback true

    Dieser Befehl muss für jeden Knoten im HA-Paar wiederholt werden.

  13. Es sollte überprüft werden, ob das automatische Giveback aktiviert ist:

    storage failover show -fields auto-giveback

    Dieses Beispiel zeigt, dass die automatische Rückgabe auf beiden Knoten aktiviert wurde:

    cluster_x::> storage failover show -fields auto-giveback
node     auto-giveback
-------- -------------
node_x_1 true
node_x_2 true
2 entries were displayed.
Verwandte Informationen