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

Funktionsweise von automatischem Takeover und Giveback

11/20/2024 Beitragende

PDFs

Die automatischen Takeover- und Giveback-Vorgänge können gemeinsam den Client-Ausfall reduzieren und verhindern.

Wenn ein Node im HA-Paar „Panik“, „Neustart“ oder „Anhalten“ beeinträchtigt wird, übernimmt der Partner-Node automatisch und gibt beim Neustart des betroffenen Node den Storage zurück. Das HA-Paar setzt dann den normalen Betriebszustand fort.

Automatische Übernahmen können auch auftreten, wenn einer der Knoten nicht mehr reagiert.

Standardmäßig wird das automatische Giveback durchgeführt. Wenn Sie lieber die Auswirkungen auf die Giveback-Funktion auf Clients kontrollieren möchten, können Sie die automatische Rückgabe deaktivieren und den storage failover modify -auto-giveback false -node <node> Befehl verwenden. Vor der Durchführung des automatischen Giveback (unabhängig davon, was ihn ausgelöst hat) wartet der Partner-Node auf eine festgelegte Zeitspanne, die vom -delay- seconds Parameter des storage failover modify Befehls gesteuert wird. Die Standardverzögerung beträgt 600 Sekunden.

Dieser Prozess vermeidet einen einzelnen, längeren Ausfall, der Folgendes beinhaltet:

Der Übernahmemodus
Der übernsorientierte Knoten, um bis zu dem Punkt zu booten, an dem er für das Giveback bereit ist
Der Giveback-Vorgang

Wenn das automatische Giveback für einen der nicht-Root-Aggregate fehlschlägt, versucht das System automatisch zwei weitere Versuche, das Giveback abzuschließen.

Während des Takeover wird der Prozess für die automatische Rückgabe gestartet, bevor der Partner-Node für das Giveback bereit ist. Wenn die Zeitgrenze des automatischen Giveback-Prozesses abgelaufen ist und der Partner-Node noch nicht bereit ist, wird der Timer neu gestartet. So kann der Zeitpunkt zwischen dem bereitzustehen des Partner-Nodes und dem tatsächlichen Giveback kürzer sein als die automatische Rückübertragung.

Was passiert bei der Übernahme

Wenn ein Node den Partner übernimmt, werden auch in den Aggregaten und Volumes des Partners weiterhin Daten bereitgestellt und aktualisiert.

Folgende Schritte treten während des Übernahmeseprozesses auf:

Wenn die ausgehandelte Übernahme vom Benutzer initiiert wird, werden aggregierte Daten vom Partner-Node auf den Node verschoben, der die Übernahme durchführt. Ein kurzer Ausfall tritt auf, wenn sich der aktuelle Eigentümer jedes Aggregats (mit Ausnahme des Root-Aggregats) zum Takeover-Node ändert. Dieser Ausfall ist kurz als ein Ausfall, der während einer Übernahme ohne Aggregatverschiebung auftritt.

Eine ausgehandelte Übernahme während der Panik kann im Falle einer Panik nicht auftreten. Ein Takeover kann auf einen Fehler führen, der nicht mit einem Panikzustand verbunden ist. Es kommt zu einem Ausfall, wenn die Kommunikation zwischen einem Node und seinem Partner unterbrochen wird, was auch als Heartbeat Loss bezeichnet wird. Wenn aufgrund eines Ausfalls ein Takeover auftritt, kann der Ausfall länger sein, da der Partner-Node Zeit benötigt, um den Heartbeat-Verlust zu erkennen.

Sie können den Fortschritt mit dem storage failover show-takeover Befehl überwachen.
Sie können die Aggregatverschiebung während dieser Takeover-Instanz vermeiden, indem Sie den -bypass-optimization Parameter mit dem storage failover takeover Befehl verwenden.

Aggregate werden während geplanter Übernahme seriell verschoben, um Client-Ausfälle zu verringern. Wenn die Aggregatverschiebung umgangen ist, kommt es während der geplanten Übernahme zu einem längeren Client-Ausfall.

Wenn es sich bei der vom Benutzer initiierten Übernahme um eine ausgehandelte Übernahme handelt, wird der Zielknoten problemlos heruntergefahren. Anschließend werden das Root-Aggregat des Ziel-Node und alle Aggregate übernommen, die im ersten Schritt nicht verschoben wurden.
Daten-LIFs (logische Schnittstellen) werden basierend auf LIF Failover-Regeln vom Ziel-Node zum Takeover-Node oder zu jedem anderen Node im Cluster migriert. Sie können die LIF-Migration mit dem -skip-lif-migration Parameter mit dem storage failover takeover Befehl vermeiden. Im Fall einer vom Benutzer initiierten Übernahme werden Daten-LIFs vor dem Start der Storage-Übernahme migriert. Im Falle eines Panic- oder Fehlerfalls können, je nach Ihrer Konfiguration, die Daten-LIFs mit dem Storage oder nach dem Abschluss der Übernahme migriert werden.

Bestehende SMB-Sessions werden unterbrochen, wenn eine Übernahme stattfindet.

Aufgrund des Wesens des SMB-Protokolls werden alle SMB-Sitzungen unterbrochen (außer bei SMB 3.0-Sitzungen, die mit Freigaben mit der Eigenschaft „Continuous Availability“ verbunden sind). SMB 1.0- und SMB 2.x-Sitzungen können die offenen Datei-Handles nach einem Takeover-Ereignis nicht erneut verbinden. Daher ist die Übernahme unterbrochen, und es könnten einige Datenverluste auftreten.

SMB 3.0-Sitzungen, die für Freigaben mit aktivierter Eigenschaft „kontinuierliche Verfügbarkeit“ eingerichtet wurden, können nach einem Takeover-Ereignis eine Verbindung zu den getrennten Freigaben herstellen. Wenn Ihre Site SMB 3.0-Verbindungen zu Microsoft Hyper-V verwendet und die Eigenschaft „kontinuierliche Verfügbarkeit“ auf den zugehörigen Freigaben aktiviert ist, sind Übernahmen für diese Sitzungen unterbrechungsfrei.

Was geschieht, wenn ein Node eine „Takeover“-Panik ausführt

Wenn der Node, der die Takeover-Panik innerhalb von 60 Sekunden nach dem Start des Takeover durchführt, treten die folgenden Ereignisse auf:

Der Node, der in Panik geraten war, wird neu gebootet.
Nach dem Neubooten des Node führt der Node Self-Recovery-Vorgänge aus und befindet sich nicht mehr im Übernahmemodus.
Der Failover ist deaktiviert.
Wenn der Node nach Aktivierung des Storage Failovers noch einige Aggregate des Partners besitzt, geben Sie diese Aggregate mithilfe des storage failover giveback Befehls an den Partner zurück.

Was passiert bei der Rückgabe

Wenn Probleme gelöst sind, wenn der Partner-Node gestartet wird oder wenn die Rückgabe initiiert wird, gibt der lokale Node die Eigentümerschaft an den Partner-Node zurück.

Der folgende Prozess findet im normalen Giveback-Vorgang statt. In dieser Diskussion hat Knoten A Knoten B übernommen. Alle Probleme auf Knoten B wurden behoben, und es ist bereit, die Bereitstellung von Daten fortzusetzen.

Alle Probleme auf Knoten B werden behoben, und es wird die folgende Meldung angezeigt: Waiting for giveback
Das Giveback wird durch den storage failover giveback Befehl oder durch automatisches Giveback initiiert, wenn das System für ihn konfiguriert ist. Dadurch wird die Rückgabe der Eigentumsrechte an Aggregaten und Volumes von Node B von Node A zurück zu Node B. initiiert
Node A gibt zuerst die Kontrolle über das Root-Aggregat zurück.
Node B schließt das Booten bis zu seinem normalen Betriebszustand ab.

Sobald Node B den Punkt im Boot-Prozess erreicht, an dem es die nicht-Root-Aggregate akzeptieren kann, gibt Node A die Eigentumsrechte an den anderen Aggregaten einzeln zurück, bis die Rückgabe abgeschlossen ist. Sie können den Fortschritt der Rückgabe mit dem storage failover show-giveback Befehl überwachen.

Der storage failover show-giveback Befehl zeigt keine Informationen über alle Vorgänge an, die während des Storage Failover-Giveback-Vorgangs stattfinden. Mithilfe des storage failover show Befehls können weitere Details zum aktuellen Failover-Status des Node angezeigt werden, beispielsweise wenn der Node vollständig funktionsfähig ist, Übernahme möglich ist und Rückgabe abgeschlossen ist.

Die I/O-Vorgänge werden für jedes Aggregat fortgesetzt, nachdem die Rückgabe für dieses Aggregat abgeschlossen ist, was das allgemeine Ausfallzeitfenster reduziert.

HA-Richtlinie und ihre Auswirkungen auf Takeover und Giveback

ONTAP weist einem Aggregat automatisch eine HA-Richtlinie von CFO (Controller Failover) und SFO (Storage Failover) zu. Diese Richtlinie bestimmt, wie Storage Failover-Vorgänge für das Aggregat und seine Volumes durchgeführt werden.

Die beiden Optionen, CFO und SFO, bestimmen die ONTAP-Aggregatkontrolle während des Storage Failover und Giveback.

Auch wenn die Begriffe CFO und SFO manchmal informell für Storage Failover (Takeover und Giveback) Vorgänge verwendet werden, stellen sie tatsächlich die HA-Richtlinie dar, die den Aggregaten zugewiesen ist. Zum Beispiel beziehen sich die Begriffe SFO-Aggregat oder CFO-Aggregat einfach auf die HA-Richtlinienzuweisung des Aggregats.

HA-Richtlinien wirken sich 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. Manuell initiierte Übernahme ist für Performance optimiert und verlagert SFO-Aggregate (nicht-Root-Aggregate) vor dem Takeover seriell an den Partner. Während des Giveback-Prozesses erhalten die Aggregate seriell, nachdem die übernehmen-Systeme gestartet wurden und die Management-Applikationen online geschaltet wurden. So erhält der Node seine Aggregate.
Da bei der Aggregatverschiebung die Neuzuteilung von aggregierten Festplatten und die Verschiebung der Kontrolle von einem Node zu seinem Partner erforderlich sind, können nur Aggregate mit einer HA-Richtlinie von SFO für einen Aggregatverschiebung qualifiziert werden.
Das Root-Aggregat hat immer eine HA-Richtlinie von CFO an und wird zu Beginn des Giveback-Vorgangs zurückgegeben. Dies ist erforderlich, damit das übernsaufgenommene System gestartet werden kann. Alle anderen Aggregate werden seriell zurückgegeben, nachdem das übergenommene System den Boot-Prozess abgeschlossen hat und die Management-Applikationen online geschaltet wurden. So erhält der Node seine Aggregate.

Die Änderung der HA-Richtlinie eines Aggregats von SFO zu CFO ist ein Wartungsmodus-Vorgang. Ändern Sie diese Einstellung nur, wenn Sie von einem Kundendienstmitarbeiter dazu aufgefordert werden.

Auswirkungen von Hintergrund-Updates auf Takeover und Giveback

Hintergrund-Updates der Festplatten-Firmware wirken sich je nach Initiierung der Operationen auf HA-Paar-Takeover, Giveback und Aggregatverschiebung aus.

In der folgenden Liste wird beschrieben, wie sich Updates der Festplatten-Firmware im Hintergrund auf Takeover, Giveback und Aggregatverschiebung auswirken:

Wenn auf einem Laufwerk auf einem der Nodes ein Update der Festplatten-Firmware im Hintergrund stattfindet, werden manuell initiierte Übernahmevorgänge verzögert, bis das Update der Festplatten-Firmware auf dieser Festplatte abgeschlossen ist. Wenn das Update der Firmware auf der Festplatte im Hintergrund länger als 120 Sekunden dauert, werden Übernahmevorgänge abgebrochen und müssen nach Abschluss des Festplatten-Firmware-Updates manuell neu gestartet werden. Wenn die Übernahme mit dem -bypass-optimization Parameter des storage failover takeover Befehls auf initiiert wurde true, wirkt sich das auf dem Ziel-Knoten vorkommende Festplatten-Firmware-Update im Hintergrund nicht auf die Übernahme aus.
Wenn ein Update der Festplatten-Firmware im Hintergrund auf einer Festplatte auf dem Quell-Node (oder Takeover) durchgeführt wird und der Takeover manuell mit dem -options Parameter des storage failover takeover Befehls auf initiiert wurde immediate, werden die Übernahmevorgänge sofort gestartet.
Wenn auf einer Festplatte auf einem Node eine Firmware im Hintergrund aktualisiert wird und eine Panik besteht, beginnt sofort die Übernahme des Panik- und Node-Systems.
Wenn auf einem Laufwerk auf einem der Nodes ein Update der Festplatten-Firmware im Hintergrund stattfindet, wird die Rückgabe von Datenaggregaten verzögert, bis das Update der Festplatten-Firmware auf dieser Festplatte abgeschlossen ist.
Wenn das Update der Firmware auf der Festplatte im Hintergrund länger als 120 Sekunden dauert, werden GiveBack-Vorgänge abgebrochen und müssen nach Abschluss der Aktualisierung der Festplatten-Firmware manuell neu gestartet werden.
Wenn auf einem Laufwerk auf einem der beiden Nodes ein Update der Festplatten-Firmware im Hintergrund stattfindet, werden Aggregatverschiebung verzögert, bis das Update der Festplatten-Firmware auf dieser Festplatte abgeschlossen ist. Wenn das Update der Festplatten-Firmware länger als 120 Sekunden dauert, werden Aggregatverschiebung abgebrochen und nach Abschluss der Firmware-Aktualisierung der Festplatte manuell neu gestartet. Wenn die Aggregatverschiebung mit dem -override-destination-checks storage aggregate relocation Befehl auf initiiert wurde true, wirkt sich das auf dem Zielknoten vorkommende Firmware-Update der Hintergrundfestplatte nicht auf die Aggregatverschiebung aus.