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

Informationen zu automatischem Takeover und Rückgabe in ONTAP Clustern

07/23/2026 Beitragende

PDFs

Die automatischen Takeover- und Rückgabevorgänge können zusammenwirken, um Kundenausfälle zu reduzieren und zu vermeiden.

Standardmäßig übernimmt der Partnerknoten automatisch, wenn ein Knoten im HA-Paar abstürzt, neu startet oder anhält, und gibt den Speicher zurück, wenn der betroffene Knoten neu startet. Das HA-Paar setzt dann den normalen Betriebszustand fort.

Automatisches Takeover kann auch erfolgen, wenn einer der Knoten nicht mehr reagiert.

Die automatische Rückgabe erfolgt standardmäßig. Wenn Sie die Auswirkungen der Rückgabe auf Clients steuern möchten, kann die automatische Rückgabe deaktiviert und der storage failover modify -auto-giveback false -node <node> Befehl verwendet werden. Vor der automatischen Rückgabe (unabhängig vom Auslöser) wartet der Partnerknoten eine festgelegte Zeitspanne, die durch den -delay- seconds Parameter des storage failover modify Befehls gesteuert wird. Die Standardverzögerung beträgt 600 Sekunden.

Dieses Verfahren vermeidet einen einzelnen, längeren Ausfall, der die für Folgendes benötigte Zeit umfasst:

Die Übernahmeoperation
Der übernommene Knoten wird so weit hochgefahren, bis er bereit für die Rückgabe ist.
Die Rückgabeaktion

Falls das automatische Giveback für eines der Nicht-Root-Aggregate fehlschlägt, unternimmt das System automatisch zwei weitere Versuche, das Giveback abzuschließen.

Während des Takeover-Prozesses startet der automatische Giveback-Prozess, bevor der Partnerknoten für das Giveback bereit ist. Wenn das Zeitlimit des automatischen Giveback-Prozesses abläuft und der Partnerknoten weiterhin nicht bereit ist, wird der Timer neu gestartet. Daraus ergibt sich, dass die Zeit zwischen der Bereitschaft des Partnerknotens und der tatsächlichen Durchführung des Givebacks kürzer sein kann als die automatische Giveback-Zeit.

Was geschieht während eines Takeovers

Wenn ein Knoten die Funktion seines Partners übernimmt, werden weiterhin Daten in den Aggregaten und Volumes des Partners bereitgestellt und aktualisiert.

Im Rahmen des Takeover-Prozesses erfolgen folgende Schritte:

Wird das ausgehandelte Takeover vom Benutzer initiiert, werden die aggregierten Daten vom Partnerknoten auf den Knoten verschoben, der das Takeover durchführt. Es kommt zu einer kurzen Unterbrechung, da der aktuelle Eigentümer jedes Aggregats (mit Ausnahme des Root-Aggregat) auf den Takeover-Knoten wechselt. Diese Unterbrechung ist kürzer als eine Unterbrechung, die bei einem Takeover ohne Aggregatverschiebung auftritt.

Eine verhandelte Übernahme während einer Panik kann im Falle einer Panik nicht erfolgen. Eine Übernahme kann durch einen Fehler ausgelöst werden, der nicht mit einer Panik zusammenhängt. Ein Fehler tritt auf, wenn die Kommunikation zwischen einem Knoten und seinem Partner verloren geht, was auch als Heartbeat-Verlust bezeichnet wird. Wenn eine Übernahme aufgrund eines Fehlers erfolgt, kann der Ausfall länger dauern, da der Partnerknoten Zeit benötigt, um den Heartbeat-Verlust zu erkennen.

Sie können den Fortschritt mit dem storage failover show-takeover Befehl überwachen.
Die Aggregatverschiebung kann während dieser Takeover-Instanz vermieden werden, indem der -bypass-optimization Parameter mit dem storage failover takeover Befehl verwendet wird.

Aggregate werden bei geplanten Takeover-Operationen nacheinander verlagert, um die Ausfallzeit für Clients zu reduzieren. Wenn die Aggregate-Verlagerung umgangen wird, tritt bei geplanten Takeover-Ereignissen eine längere Ausfallzeit für Clients auf.

Wenn die vom Benutzer initiierte Übernahme eine ausgehandelte Übernahme ist, fährt der Zielknoten ordnungsgemäß herunter, gefolgt von der Übernahme des Root-Aggregats und aller Aggregate, die im ersten Schritt nicht verschoben wurden.
Daten-LIFs (logische Schnittstellen) migrieren gemäß den LIF-Failover-Regeln vom Zielknoten auf den Übernahmeknoten oder auf einen anderen Knoten im Cluster. Die LIF-Migration kann vermieden werden, indem der -skip-lif-migration Parameter mit dem storage failover takeover Befehl verwendet wird. Im Fall einer benutzerinitiierten Übernahme werden die Daten-LIFs vor Beginn der Speicherübernahme migriert. Im Fall eines Systemabsturzes oder Ausfalls können die Daten-LIFs je nach Konfiguration zusammen mit dem Speicher oder nach Abschluss der Übernahme migriert werden.

Bestehende SMB-Sitzungen werden bei einem Takeover getrennt.

Aufgrund der Funktionsweise des SMB-Protokolls werden alle SMB-Sitzungen unterbrochen (mit Ausnahme von SMB 3.0-Sitzungen, die mit Freigaben verbunden sind, für die die Eigenschaft „Kontinuierliche Verfügbarkeit“ aktiviert ist). SMB 1.0- und SMB 2.x-Sitzungen können nach einem Takeover offene Dateihandles nicht wiederherstellen, daher ist das Takeover unterbrechend und es kann zu Datenverlust kommen.

SMB 3.0-Sitzungen, die zu Freigaben mit aktivierter Eigenschaft „Continuous Availability“ eingerichtet sind, können nach einem Takeover-Ereignis die Verbindung zu den getrennten Freigaben wiederherstellen. Wenn an Ihrem Standort SMB 3.0-Verbindungen zu Microsoft Hyper-V verwendet werden und die Eigenschaft „Continuous Availability“ auf den zugehörigen Freigaben aktiviert ist, sind Takeover-Ereignisse für diese Sitzungen unterbrechungsfrei.

Was passiert, wenn ein Knoten, der ein Takeover durchführt, einen Panic-Zustand erreicht?

Wenn der Knoten, der das Takeover durchführt, innerhalb von 60 Sekunden nach Einleitung des Takeovers in Panik gerät, treten die folgenden Ereignisse ein:

Der Knoten, der einen Panic ausgelöst hat, wird neu gestartet.
Nach dem Neustart führt der Knoten Selbstwiederherstellungsoperationen durch und befindet sich nicht mehr im Takeover-Modus.
Failover ist deaktiviert.
Falls der Knoten nach der Aktivierung des Storage-Failovers noch einige Aggregate des Partners besitzt, können diese Aggregate mit dem storage failover giveback Befehl an den Partner zurückgegeben werden.

Was geschieht während der Rückgabe

Der lokale Knoten gibt die Besitzrechte an den Partnerknoten zurück, wenn Probleme behoben sind, wenn der Partnerknoten hochfährt oder wenn die Rückgabe eingeleitet wird.

Der folgende Prozess läuft im Rahmen einer normalen Rückgabeoperation ab. In dieser Darstellung hat Node A die Kontrolle über Node B übernommen. Alle Probleme auf Node B wurden behoben und es ist bereit, die Datenbereitstellung wieder aufzunehmen.

Alle Probleme auf Knoten B wurden behoben und es wird die folgende Meldung angezeigt: Waiting for giveback
Die Rückgabe wird durch den storage failover giveback-Befehl oder durch automatisches Giveback eingeleitet, wenn das System entsprechend konfiguriert ist. Damit beginnt der Prozess, bei dem die Besitzrechte an den Aggregaten und Volumes von Node B von Node A zurück an Node B übertragen werden.
Knoten A gibt zuerst die Kontrolle über das Root-Aggregat zurück.
Knoten B schließt den Hochfahrvorgang bis zum Erreichen des normalen Betriebszustands ab.

Sobald Knoten B im Bootvorgang den Punkt erreicht hat, an dem er die Nicht-Root-Aggregate akzeptieren kann, gibt Knoten A die Besitzrechte an den übrigen Aggregaten nacheinander zurück, bis die Rückgabe abgeschlossen ist. Der Fortschritt der Rückgabe kann mit dem storage failover show-giveback Befehl überwacht werden.

Der `storage failover show-giveback`Befehl zeigt keine Informationen über alle Vorgänge während des Storage Failover Giveback-Vorgangs an (und ist auch nicht dafür vorgesehen). Mit dem `storage failover show`Befehl lassen sich zusätzliche Details zum aktuellen Failover-Status des Knotens anzeigen, etwa ob der Knoten voll funktionsfähig ist, ein Takeover möglich ist und das Giveback abgeschlossen ist.

Die E/A wird für jedes Aggregat wieder aufgenommen, nachdem die Rückgabe für dieses Aggregat abgeschlossen ist, was das gesamte Ausfallfenster verkürzt.

HA-Richtlinie und ihre Auswirkungen auf Takeover und Giveback

ONTAP weist einem Aggregat automatisch eine HA-Richtlinie mit CFO (Controller-Failover) und SFO (Storage-Failover) zu. Diese Richtlinie legt fest, wie Speicher-Failover-Operationen für das Aggregat und seine Volumes ablaufen.

Die beiden Optionen CFO und SFO bestimmen die Aggregat-Steuerungssequenz, die ONTAP während Storage-Failover- und Giveback-Vorgängen verwendet.

Obwohl die Begriffe CFO und SFO umgangssprachlich manchmal für Storage-Failover-Operationen (Takeover und Giveback) verwendet werden, bezeichnen sie tatsächlich die HA-Richtlinie, die den Aggregaten zugewiesen ist. Beispielsweise beziehen sich die Begriffe SFO Aggregate oder CFO Aggregate einfach auf die HA-Richtlinienzuweisung des Aggregats.

Die HA-Richtlinien wirken sich wie folgt auf Takeover- und Giveback-Vorgänge aus:

Auf ONTAP-Systemen erstellte Aggregate (mit Ausnahme des Root-Aggregats, das das Root-Volume enthält) haben eine HA-Richtlinie von SFO. Eine manuell initiierte Übernahme ist hinsichtlich der Performance optimiert, indem SFO-Aggregate (Nicht-Root-Aggregate) vor der Übernahme seriell zum Partner verschoben werden. Während des Rückgabeprozesses werden Aggregate seriell zurückgegeben, nachdem das übernommene System gestartet ist und die Management-Anwendungen online sind, sodass der Node seine Aggregate empfangen kann.
Da bei einer Aggregatverschiebung die Eigentumsrechte an der Aggregatfestplatte neu zugewiesen und die Kontrolle von einem Knoten auf seinen Partner übertragen werden, sind nur Aggregate mit einer HA-Richtlinie vom Typ SFO für eine Aggregatverschiebung geeignet.
Das Root-Aggregat verfügt stets über die HA-Richtlinie CFO und wird zu Beginn des Rückgabevorgangs zurückgegeben. Dies ist erforderlich, damit das übernommene System starten kann. Alle anderen Aggregate werden nacheinander zurückgegeben, nachdem das übernommene System den Startvorgang abgeschlossen hat und die Managementanwendungen online sind, sodass der Knoten seine Aggregate empfangen kann.

Die Änderung der HA-Richtlinie eines Aggregats von SFO auf CFO ist ein Wartungsmodus-Vorgang. Diese Einstellung sollte nur auf Anweisung eines Kundendienstmitarbeiters geändert werden.

Wie sich Hintergrundaktualisierungen auf Takeover und Giveback auswirken

Hintergrundaktualisierungen der Festplatten-Firmware wirken sich unterschiedlich auf HA-Paar-Takeover-, Giveback- und Aggregatverschiebungsoperationen aus, je nachdem, wie diese Operationen initiiert werden.

Die folgende Liste beschreibt, wie sich Hintergrund-Firmware-Updates der Festplatte auf Takeover, Giveback und Aggregatverschiebung auswirken:

Wenn auf einer Festplatte eines der beiden Knoten ein Firmware-Update im Hintergrund durchgeführt wird, verzögern sich manuell initiierte Takeover-Vorgänge, bis das Firmware-Update auf dieser Festplatte abgeschlossen ist. Dauert das Firmware-Update im Hintergrund länger als 120 Sekunden, werden die Takeover-Vorgänge abgebrochen und müssen nach Abschluss des Firmware-Updates manuell neu gestartet werden. Wenn das Takeover mit dem -bypass-optimization-Parameter des storage failover takeover-Befehls auf true gesetzt initiiert wurde, hat das im Hintergrund laufende Firmware-Update auf dem Zielknoten keine Auswirkungen auf das Takeover.
Wenn auf einer Festplatte des Quellknotens (oder Übernahmeknotens) ein Hintergrund-Firmware-Update stattfindet und die Übernahme manuell mit dem -options Parameter des storage failover takeover Befehls auf immediate gesetzt eingeleitet wurde, beginnen die Übernahmevorgänge sofort.
Falls auf einer Festplatte eines Knotens im Hintergrund ein Firmware-Update durchgeführt wird und es zu einem Systemabsturz kommt, beginnt sofort die Übernahme des betroffenen Knotens.
Wird auf einer Festplatte eines der beiden Knoten gerade ein Hintergrund-Firmware-Update durchgeführt, verzögert sich die Rückgabe der Datenaggregate, bis das Firmware-Update auf dieser Festplatte abgeschlossen ist.
Dauert die Aktualisierung der Festplatten-Firmware im Hintergrund länger als 120 Sekunden, werden die Rückgabevorgänge abgebrochen und müssen nach Abschluss der Festplatten-Firmware-Aktualisierung manuell neu gestartet werden.
Wird auf einem der beiden Knoten im Hintergrund ein Firmware-Update für eine Festplatte durchgeführt, werden die Aggregatverschiebungsvorgänge verzögert, bis das Firmware-Update auf dieser Festplatte abgeschlossen ist. Dauert das Firmware-Update im Hintergrund länger als 120 Sekunden, werden die Aggregatverschiebungsvorgänge abgebrochen und müssen nach Abschluss des Firmware-Updates manuell neu gestartet werden. Wurde die Aggregatverschiebung mit dem -override-destination-checks des storage aggregate relocation Befehls auf true initiiert, hat das im Hintergrund laufende Firmware-Update auf dem Zielknoten keine Auswirkungen auf die Aggregatverschiebung.

Verwandte Informationen