Cluster-Wiederherstellung nach vollständigem Stromausfall

Wiederherstellungsverfahren und Best Practices für VergeOS-Cluster nach einem ungeplanten vollständigen Stromausfall – einschließlich Einschaltreihenfolge, vSAN-Integritätsprüfung und Vorbeugungsempfehlungen.

Überblick

Wichtige Punkte

Unsanfte Herunterfahrten sollten nach Möglichkeit vermieden werden, insbesondere auf Produktionssystemen.
Diese Anleitung bietet Best Practices -- zur Minderung potenzieller Probleme -- für das Einschalten des Clusters, nachdem ein unerwartetes Herunterfahren eingetreten ist.
Einschalten Node1 Zuerst. Warten Sie 30 Sekunden bis eine Minute, dann schalten Sie die übrigen Clusterknoten ein.
Ein von Null verschiedener Reparaturen Zählerstand nach der Wiederherstellung ist normal; er sollte abnehmen, wenn Journal Walks abgeschlossen werden.
Wenden Sie sich an den VergeIO-Support, wenn der Reparaturzähler nach Abschluss des Journal Walks nicht wieder auf null zurückkehrt oder andere Anomalien bestehen bleiben.

Umfang

Diese Anleitung behandelt das Wiederhochfahren eines VergeOS-Clusters nach einem unsauberen Herunterfahren -- wenn der Cluster aufgrund eines Stromausfalls, einer erschöpften USV, eines Ausfalls der Anlage oder eines ähnlichen Ereignisses abrupt die Stromversorgung verlor. Für geplante, kontrollierte Herunterfahr- und Einschaltverfahren siehe Korrektes Verfahren zum Herunterfahren des VergeOS-Systems und Richtige Stromversorgungsreihenfolge.

Unsanfte Herunterfahrten nach Möglichkeit vermeiden

Obwohl VergeOS mehrere integrierte Schutzmechanismen enthält, um die Datenintegrität zu bewahren, kann kein verteiltes Speichersystem vollständig garantieren, dass keine Datenbeschädigung auftritt, wenn Knoten abrupt und gleichzeitig die Stromversorgung verlieren.
Schreibvorgänge, die zum Zeitpunkt des Stromausfalls noch laufen, können unvollständig oder zwischen den Peers inkonsistent sein, und in manchen Fällen ist der einzige Weg zurück zur Integrität, ein Volume auf einen aktuellen Snapshot zurückzusetzen.
Außerdem treten nach unsauberen Herunterfahrten häufig Hardware-, Gast-OS- und Anwendungsprobleme auf.
Eine geeignete Strominfrastruktur -- USV-Kapazität, ausgelegt für ein sauberes Herunterfahren, redundante Netzteile und automatisches Herunterfahren bei niedrigem Akkustand -- ist der wirksamste Schutz; siehe den Vorbeugung Abschnitt für Hinweise.
Wenn es trotz dieser Vorsichtsmaßnahmen doch zu einem unsauberen Herunterfahren kommt, ist das folgende Verfahren darauf ausgelegt, den Cluster sicher wieder online zu bringen und alle Integritätsprobleme sichtbar zu machen, die Aufmerksamkeit erfordern.

Voraussetzungen

Physischer oder IPMI/BMC-Zugriff auf jeden Knoten
Kenntnis davon, welcher Knoten ist Node1 (Node1 muss zuerst gebootet werden.)
Bestätigung, dass die vorgelagerte Stromversorgung, das Netzwerk (Core-Fabric-Switches) und IPMI wiederhergestellt und stabil sind
Ein aktueller lokal oder remote replizierter Snapshot, falls Integritätsprobleme gefunden werden
Vertrautheit mit dem vSAN-Tier-Dashboard / Journal Walks

Schritte

Was zu erwarten ist

VergeFS enthält mehrere integrierte Schutzmechanismen, die helfen, die Datenintegrität bei Stromereignissen zu bewahren -- einschließlich Schreib-Journaling, Peer-Replikation, Reparaturserver (ioGuardian) und Verifizierung beim Start. Beim Start des Controllers löst VergeFS einen Vollständigen Journal Walk aus, um jeden Block zu prüfen und mit den Peers abzugleichen. Diese Schutzmechanismen sind in den meisten Fällen wirksam, aber kein verteiltes Speichersystem kann vollständig garantieren, dass abrupter Stromverlust keine Beschädigung verursacht; die Verifizierung nach dem Start ist wichtig, insbesondere nach einem unsauberen Herunterfahren.
vSAN erfordert Mindestknotenanzahl online sein, bevor es eingebunden wird (z. B. in einem Cluster mit 4 Knoten und N+1-Schutz wird vSAN eingebunden, solange 3 Knoten online sind). Bis dieser Schwellenwert erreicht ist, bleibt der Speicher offline und VMs werden nicht starten.
Node1 bootet, hält aber vor dem Einbinden des vSAN an, bis genügend Peers beigetreten sind.
Ein von Null verschiedener Reparaturen Zählerstand nach der Wiederherstellung ist normal und sollte abnehmen, während der Walk fortschreitet.

Prüfungen vor dem Einschalten

Zuerst sicherstellen, dass die Infrastruktur bereit ist

Bevor Sie irgendwelche Clusterknoten einschalten, bestätigen Sie, dass zwei kritische Bedingungen erfüllt sind. Diese werden in den Voraussetzungen behandelt, aber hier sollten sie noch einmal erwähnt werden -- wenn Sie sie überspringen, kann das erheblich mehr Schaden verursachen als das ursprüngliche Herunterfahren:

Die Stromversorgung der Anlage ist vollständig wiederhergestellt und stabil. Den Cluster während anhaltender Strominstabilität hochzufahren -- Flackern, Unterspannungen oder ein zweiter Ausfall -- riskiert, das ursprüngliche Problem zu verschärfen und kann zu weiteren Problemen bei der Datenintegrität führen.
Die zentralen Netzwerkswitches sind eingeschaltet und vollständig gebootet. Enterprise-Switches können mehrere Minuten brauchen, um ihren Bootvorgang abzuschließen, ähnlich wie ein Server. Wenn Clusterknoten online gehen, bevor das Netzwerk bereit ist, können sie ihre Peers nicht entdecken, was zu Reconciliationsproblemen führen kann.

Bestätigen Sie die vorgelagerte Stromversorgung ist stabil. Knoten an einer instabilen Versorgung hochzufahren, birgt das Risiko eines zweiten Ausfalls mitten in der Wiederherstellung.
Bestätigen Sie die zentralen Netzwerkswitches sind online, vollständig gebootetund das Inter-Node-Fabric ist aktiv. vSAN kann sich ohne es nicht neu bilden, und fortschrittliche Switches können mehrere Minuten brauchen, bis sie den Bootvorgang abschließen.
Prüfen Sie IPMI/BMC Zugriff auf jedem Knoten, damit Sie den Start bei Bedarf remote überwachen können.
Notieren Sie alle Knoten mit sichtbaren Hardwarefehlern (defekte Netzteile, Laufwerk-LEDs, Lüfteralarme) -- diese müssen möglicherweise vor dem erneuten Hinzufügen behoben werden.

Einschaltsequenz

Sobald Strom- und Netzwerk-Infrastruktur als bereit bestätigt sind:

Schalten Sie Node1 ein.
- Beobachten Sie die Konsole/IPMI. Node1 bootet das Betriebssystem, hält aber vor dem Einbinden des vSAN an bis genügend Peers beitreten.
Warten Sie 30 Sekunden bis eine Minute.
- Diese kurze Pause ermöglicht es Node1, mit der Initialisierung zu beginnen, bevor der Rest des Clusters eintrifft. Sie müssen nicht warten, bis Node1 vollständig seinen Halt-Zustand erreicht hat, bevor Sie fortfahren.
Schalten Sie die verbleibenden Knoten ein.
- Die übrigen Knoten können zusammen (oder kurz nacheinander) eingeschaltet werden; es ist nicht nötig, sie einzeln nacheinander hochzufahren.
- Das vSAN wird automatisch eingebunden, sobald eine Mindestanzahl von Knoten online ist (z. B. alle bis auf einen Knoten in einer Standard-N+1-Konfiguration).
Multi-Cluster-Umgebungen: Bringen Sie den Controller-Cluster vollständig online, bevor Sie zusätzliche Cluster einschalten.

Profi-Tipp

Node1 bootet zuerst und wartet, während Sie den Rest des Clusters einschalten -- das ist erwartet und kein Hängenbleiben. Das vSAN wird von selbst eingebunden, sobald genügend Peers online sind, und VergeOS übernimmt die Abstimmung automatisch; manuelle Reparaturbefehle sind nicht erforderlich.

Verifizierung nach der Wiederherstellung

Sobald alle Knoten online sind und der Cluster Zeit hatte, sich zu stabilisieren, überprüfen Sie, ob alles wieder in einem gesunden Zustand ist. Da der Cluster unsauber heruntergefahren wurde, führen Sie diese Prüfungen mit besonderer Sorgfalt durch -- abruptes Stromausfall kann Probleme hinterlassen, die der Cluster nicht vollständig selbst beheben kann. Achten Sie genau auf anhaltende vSAN-Fehler, fehlgeschlagene oder in Crash-Schleifen laufende Workloads und etwaige Dateisystemfehler auf Gast-Ebene. Wenn nicht behebbarer Schaden erkannt wird, kann ein Zurücksetzen eines Volumes auf einen aktuellen Snapshot erforderlich sein.

Gesamtzustand des Systems bestätigen
Ein abruptes Stromverlust erhöht das Risiko für Hardwareprobleme. Es ist wichtig, auf folgende Probleme zu achten:
- Prüfen Sie die Warnungen Dashboard. Bestätigen Sie, dass keine neuen Warnungen ausgelöst wurden.
- Prüfen Sie die Systemprotokolle (Haupt-Dashboard) auf Fehler während des Bootvorgangs oder des ersten Einbindens.
vSAN-Zustand prüfen
- Öffnen Sie das Haupt-Dashboard -- alle Statusanzeigen sollten Grün.
- Navigieren Sie zu System → vSAN → Ebenen und doppelklicken Sie auf jede Ebene.
- Prüfen Sie die Status Kachel auf dem Dashboard jeder Ebene. Der KB-Artikel vSAN-Tier-Status-/Journal-Durchläufe verstehen enthält eine Anleitung zum Lesen der vSAN-Ebenen-Statusfelder.
Laufwerkszustand prüfen
- Gehen Sie zu System → vSAN → Laufwerke.
- Achten Sie auf Laufwerke mit Fehlern, Warnungen oder SMART-Alarmen -- dies kann auftreten, wenn Laufwerke nach einem abrupten Stromverlust nicht sauber zurückkehren.
- Defekte Laufwerke ersetzen umgehend, um den vSAN-Datenschutz aufrechtzuerhalten.
Workloads prüfen
Verhalten beim automatischen Start von VMs
Standardmäßig sind VMs so konfiguriert, dass sie automatisch starten, wenn die Stromversorgung des Clusters wiederhergestellt wird. VMs mit einer alternativen Bei Stromverlust Einstellung müssen manuell eingeschaltet werden.
- Prüfen Sie kritische VMs: Konsole reagiert, Gast-OS gesund, Anwendungsdienste laufen. Unsanfte Herunterfahrten können Probleme innerhalb des Gast-OS und installierter Anwendungen verursachen -- achten Sie auf Dateisystemfehler, Dienste, die nicht starten, und Anwendungen, die beim Start abstürzen.
- Potenzielle Kandidaten für ein Zurückrollen so früh wie möglich identifizieren -- idealerweise bevor Anwendungen wieder stark genutzt werden.

Entscheidungen zum Zurückrollen von Snapshots sind zeitkritisch

Wenn das Gesamtsystem oder einzelne VMs Anzeichen von Schäden durch das unsaubere Herunterfahren zeigen, die nicht vor Ort repariert werden können, kann die Wiederherstellung aus einem Snapshot vor dem Ausfall der einzige Weg zurück zu einem gesunden Zustand sein. Diese Entscheidung sollte so schnell wie möglich getroffen werden, aus zwei Gründen:

Die Aufbewahrung von Snapshots ist begrenzt. Ein brauchbarer Snapshot vor dem Ausfall kann aus der Aufbewahrung fallen und nicht mehr verfügbar sein, wenn zu viel Zeit vergeht, bevor die Entscheidung getroffen wird.
Neuere Daten gehen beim Zurückrollen verloren. Je länger die betroffene VM nach dem Ausfall in Produktion genutzt wird, desto mehr legitime Arbeit nach der Wiederherstellung geht bei der Durchführung des Rollbacks verloren.

Fehlerbehebung

Häufige Probleme

Problem: Ein Knoten tritt dem Cluster nicht wieder bei.
- Lösung: Prüfen Sie die IPMI-/Konsolenausgabe auf Bootfehler. Stellen Sie sicher, dass die zentrale Netzwerkschnittstelle des Knotens aktiv und von den Peers erreichbar ist. Prüfen Sie System → Knoten → [Knoten] auf Status und Zuletzt-gesehen-Zeitstempel. Wenn der Knoten bootet, aber nicht beitritt, versuchen Sie nicht, ihn nicht zwangsweise zu entfernen -- wenden Sie sich an den Support.
Problem: vSAN wird nicht eingebunden / Speicher offline.
- Lösung: Bestätigen Sie Die Mindestanzahl an vSAN-Knoten ist online unter System → Knoten (z. B. in einer Standardkonfiguration: 3 von 4 in einem 4-Knoten-Cluster, 5 von 6 in einem 6-Knoten-Cluster). Prüfen Sie die Konnektivität zwischen den Knoten (Core-Fabric-Switches, Link-Status, MTU). Wenn der Schwellenwert erreicht ist, der Speicher aber trotzdem nicht eingebunden wird, erstellen Sie ein sysdiag und wenden Sie sich an den Support.
Problem: Reparaturzähler bleibt hängen oder wächst.
- Lösung: Ein kleiner, abnehmender Reparaturen Zählerstand ist nach der Wiederherstellung normal. Ein Zählerstand, der nicht weiter abnimmt oder wächst zeigt Blöcke an, die das vSAN nicht von Peers rekonstruieren kann. Starten Sie keine Knoten neu. Wenden Sie sich an den Support, bevor Sie Remediationsschritte durchführen.
Problem: Verdacht auf Split-Brain oder inkonsistenten Clusterzustand.
- Lösung: Während der Wiederherstellung kann ein Netzwerkproblem dazu führen, dass zwei Knotenmengen hochkommen, ohne einander zu sehen. Wenn Sie Anzeichen dafür sehen, dass sich zwei unabhängige Cluster bilden (selten, aber nach teilweiser Netzwerkwiederherstellung möglich), versuchen Sie nicht, sie selbst zusammenzuführen. Erfassen Sie sysdiags von jedem Knoten und wenden Sie sich sofort an den Support.

Vorbeugung/Minderung

USV-Dimensionierung und Abdeckung -- dimensionieren Sie die USV so, dass sie die Dauer für ein sauberes Herunterfahren plus Reserve für jeden Knoten abdeckt. Beziehen Sie die zentralen Netzwerkswitches in dieselbe Abdeckung ein. Testen Sie die Laufzeit der USV jährlich -- Batterien altern.
Automatisches sauberes Herunterfahren -- Verwenden Sie UPS-Management-Software (NUT, IPMI-Skripting oder den Agenten Ihres USV-Herstellers auf einem Management-Host), um ein Ereignis mit niedrigem Akkustand zu erkennen und ein sauberes Herunterfahren des Clusters auszulösen -- entweder über die Aktion des Cluster-Dashboards, die VergeOS-API ( Ausschalten POST /v4/cluster_actionsmit Body {"cluster": <cluster_id>, "action": "shutdown", "params": "{}"} ), oder unserenVRG CLI -Wrapper, der denselben Shutdown-Aufruf von einem Linux/macOS/Windows-Host aus skripten kann. Validieren Sie die Automatisierung in einem Wartungsfenster, bevor Sie sich darauf verlassen. "VM-Einstellungen bei Stromausfall"
"VM-Einstellungen bei Stromausfall" -- konfigurieren Sie das Verhalten jeder VM bewusst, damit der Zustand nach der Wiederherstellung vorhersehbar ist. Drei Optionen:
- Letzter Zustand -- VM wird nur eingeschaltet, wenn sie zum Zeitpunkt des Stromausfalls eingeschaltet war
- Ausgeschaltet lassen -- VM bleibt ausgeschaltet, wenn die Stromversorgung wiederhergestellt wird, unabhängig vom vorherigen Zustand
- Einschalten -- VM wird eingeschaltet, wenn die Stromversorgung wiederhergestellt wird, unabhängig vom vorherigen Zustand
Reparaturserver (ioGuardian) -- ein konfigurierter Reparaturserver gibt VergeFS eine alternative Quelle für fehlende Blöcke, falls Peers sie nach einem Ausfall nicht bereitstellen können. Er wird aus einer vorhandenen ausgehenden Site-Sync-Konfiguration aufgebaut und zieht benötigte Blöcke von einem synchronisierten entfernten VergeOS-System. Reparaturserver werden für jede Produktionsbereitstellung dringend empfohlen.
Ausreichende Snapshot-Rotation -- pflegen Sie einen Aufbewahrungsplan für Snapshots, der aktuelle Snapshots vor dem Ereignis für einen erforderlichen Rollback verfügbar hält. Das Replizieren von Snapshots an einen entfernten Standort wird ebenfalls als Teil einer umfassenden Datenschutzstrategie empfohlen.

Wann Sie den Support kontaktieren sollten

Eröffnen Sie ein Support-Ticket bevor Sie Knoten neu starten oder andere wesentliche Änderungen vornehmen, wenn einer der folgenden Punkte zutrifft:

vSAN wird nicht eingebunden, nachdem N Knoten online sind (z. B. die volle Knotenanzahl minus eins in einer Standard-N+1-Redundanz)
Eine Ebene zeigt Redundant: false über einen längeren Zeitraum, nachdem Full Walks abgeschlossen sind
Der Reparaturen Zählerstand bleibt hängen oder wächst
Eine Warnung wegen hängender Reparaturen ist vorhanden (VergeOS v26+)
Mehrere Laufwerke melden nach der Wiederherstellung Fehler
Sie vermuten Split-Brain oder einen inkonsistenten Clusterzustand
Ein Knoten kann nicht wieder beitreten, und die Ursache ist nicht offensichtlich hardwarebedingt

Erstellen eines Systemdiagnoseberichts für den Support

Bevor Sie das Ticket eröffnen, erfassen Sie ein sysdiag und hängen Sie es an (oder senden Sie es direkt an den Support):

Siehe Systemdiagnosen erstellen und die vollständige Systemdiagnose Referenz.

Zusätzliche Ressourcen

Feedback

Brauchen Sie Hilfe?

Wenn Sie weitere Unterstützung benötigen oder Fragen zu diesem Artikel haben, zögern Sie bitte nicht, sich an unser Support-Team zu wenden.

Dokumentinformationen

Zuletzt aktualisiert: 2026-05-08
vergeOS-Version: 26.0+

VorherigeSystemadministration

NächsteKonfigurieren von PTP in VergeOS

Zuletzt aktualisiert vor 2 Monaten

War das hilfreich?