Verständnis von vSAN-Tier-Status-/Journal-Walks
Verständnis der Statusmetriken des vSAN-Tier-Dashboards, einschließlich Journal-Walk-Typen, Fortschrittsverfolgung, Redundanzprüfungen und Reparaturzähler zur Überwachung der Speicherintegrität.
Überblick
Diese Seite soll Ihnen helfen, die auf dem vSAN-Tier-Dashboard. Diese Metriken bieten Einblicke in Journal Walks, die Prozesse, die kontinuierlich die Datenintegrität von vSAN überwachen und unterstützen.
Journal Walks
VergeFS verwendet einen Prozess namens Journal Walks (auch als „Walks“ bezeichnet), um die Speicherintegrität kontinuierlich zu überprüfen und vor Risiken wie Hardwareausfällen, stillem Bitrot, Stromausfällen und irreführenden Schreibbestätigungen von Geräten zu schützen. Diese Walks werden automatisch ausgelöst und scannen jeden Knoten, um zu verifizieren, dass die erwarteten Datenblöcke vorhanden sind. Falls Datenblöcke fehlen, was auf Folgendes zurückzuführen sein kann: Geräteprobleme, geplante Neustarts von Knoten oder Umgebungsstörungen, führt VergeFS proaktiv Reparaturen durch, um die Konsistenz wiederherzustellen.
Journal Walks laufen als Hintergrundprozess; Systemoperationen laufen während eines Journal Walks normal weiter.
Das System führt drei Arten von Journal Walks:
Teilweiser (differenzieller) Walk - zielt auf Daten ab, die seit der letzten Walk-Transaktion geändert wurden, um eine schnellere Validierung zu ermöglichen
Vollständiger Walk - scannt alle Daten über alle Knoten hinweg
Gemischter Walk - tritt auf, wenn ein Nicht-Controller-Knoten neu gestartet wird; nur dieser Knoten wird vollständig gescannt, während die anderen Knoten differenziell gescannt werden.
Zugriff auf Statusinformationen des vSAN-Tiers
Navigieren Sie zu: Infrastruktur > vSAN-Tiers > doppelklicken Sie auf das gewünschte Tier. Dadurch wird das Dashboard für das ausgewählte vSAN-Tier angezeigt. Siehe die Status-Kachel auf dieser Seite.
Statusdaten
Redundant: (Kontrollkästchen) Zeigt an, ob das vSAN-Tier derzeit als redundant verifiziert ist. Wenn es nicht aktiviert ist, wird der Wartungsmodus deaktiviert, um Unterbrechungen zu verhindern. Das Kästchen kann während eines vollständigen Journal Walks als nicht aktiviert erscheinen, bis die Redundanz bestätigt ist. Es bleibt auch dann nicht aktiviert, wenn die Redundanz nicht verifiziert werden kann, z. B. wenn ein Knoten nach Abschluss des Journal Walks offline ist.
Verschlüsselt: (Kontrollkästchen) Zeigt an, ob Daten im vSAN-Tier verschlüsselt sind. Der Verschlüsselungsstatus wird während der Installation festgelegt und bleibt unverändert; diese Einstellung kann nach der Bereitstellung nicht geändert werden.
In Arbeit: (Kontrollkästchen) Gibt an, dass für dieses Tier gerade ein Journal Walk ausgeführt wird. Wenn keine Snapshots oder Datenänderungen stattfinden, können Walks so schnell abgeschlossen werden, dass sie in der Benutzeroberfläche nicht als „in Arbeit“ angezeigt werden.
Vollständiger Walk: (Kontrollkästchen) Kennzeichnet, ob ein vollständiger Journal Walk ausgeführt wird. Vollständige Walks werden durch Ereignisse wie den Start des Controllers oder Topologieänderungen ausgelöst (z. B. Knoten offline oder hinzugefügt, Laufwerksausfall usw.).
Walk-Fortschritt: Zeigt den aktuellen Fortschritt des Journal Walks als Prozentsatz an oder „Leerlauf“, wenn kein Walk aktiv ist.
Letzte Walk-Zeit (ms): Dauer in Millisekunden des zuletzt ausgeführten Journal Walks.
Letzte vollständige Walk-Zeit (ms): Dauer in Millisekunden des zuletzt ausgeführten vollständigen Journal Walks.
Aktuelle Transaktion: Eine eindeutige ID, die die neueste Transaktion darstellt. Dieser Wert erhöht sich mit jedem Journal Walk, unabhängig davon, ob er vollständig, gemischt oder differentiell ist.
Transaktionsstartzeit: Zeitstempel, der angibt, wann der aktuelle oder zuletzt ausgeführte Journal Walk begonnen hat. Nützlich zur Diagnose lang andauernder oder hängender Vorgänge. (siehe Dauer des Journal Walks unten).
Reparaturen: Zeigt die aktuelle Anzahl fehlender Datenblöcke an, die auf dem Tier erkannt wurden. Es ist normal, nach Ereignissen wie Knotenausfällen, Wartungsvorgängen oder Aktualisierungen einen von Null abweichenden Wert zu sehen. VergeFS Journal Walks erkennen diese Blöcke automatisch und arbeiten daran, sie mithilfe redundanter Daten auf anderen Knoten zu korrigieren. Wenn die Redundanz ausfällt (z. B. doppelter Knotenausfall), versucht das System, Blöcke von einem konfigurierten Reparaturserver abzurufen. Anhaltende Reparaturzähler (d. h. nach mehreren Transaktionsinkrementen) können darauf hinweisen, dass eine manuelle Behebung erforderlich ist; in solchen Fällen wird empfohlen, den VergeIO-Support zu kontaktieren.
Wenn fehlende Datenblöcke bereits erkannt wurden und noch kein Reparaturserver konfiguriert ist, ist es noch nicht zu spät. Das Einrichten eines Reparaturservers ermöglicht VergeFS jetzt, bei nachfolgenden Journal Walks automatisch zu versuchen, diese Blöcke wiederherzustellen.
Fehlende Laufwerke: Gibt die Anzahl der Laufwerke an, die seit Beginn des aktuellen Journal Walks fehlen. Es ist üblich, hier nach Neustarts von Knoten, Wartung oder Aktualisierungen einen von Null abweichenden Wert zu sehen; dies bedeutet nicht automatisch einen Laufwerksausfall. Fehlende Laufwerke hängen typischerweise mit offline befindlichen Knoten oder Erkennungsverzögerungen zu Beginn des Walks zusammen. Wenn keine Knoten offline sind und dieses Feld einen Wert anzeigt, prüfen Sie den Laufwerks- und Knotenstatus über das System-Dashboard, um weitere Informationen zu erhalten.
Dauer des Journal Walks
Walk-Zeiträume variieren, und mehrere Faktoren können die Dauer beeinflussen, darunter:
Verwendung von NVME Tier 0 für Metadaten
Verfügbarer Speicher auf Controller-Knoten
Datenmenge auf dem Tier
Menge der Datenänderungen seit der letzten Transaktion
Überlegungen zur Walk-Dauer
Updates beinhalten vollständige Walks und gemischte Walks; daher beeinflusst die Dauer dieser Vorgänge die erforderlichen Wartungsfenster.
Die letztlich benötigte Zeit für große Löschvorgänge und Daten-Tier-Migrationen (z. B. von einem Tier zu einem anderen) hängt von den Dauer der differenziellen Walks ab.
Systeme, die den veröffentlichten Empfehlungen zu Dimensionierung und Design folgen, sollten akzeptable Walk-Dauern aufweisen. Beispielsweise passen Walks, die während Aktualisierungsvorgängen ausgelöst werden, in der Regel innerhalb üblicher Wartungsfenster.
Optimierung der Walk-Dauer
Die Walk-Dauer hängt von der Größe des Tiers und der Änderungsrate der Daten ab. Ausreichende Ressourcen und ein geeignetes Netzwerkdesign haben erheblichen Einfluss auf die Walk-Leistung.
Tipps zur Optimierung der Dauer von Journal Walks
Befolgen Sie die empfohlenen Anforderungen an die Knotendimensionierung (z. B. dediziertes Tier 0 mit NVME-Laufwerken, passend dimensionierter Controller-Speicher für Ihre Umgebung)
Setzen Sie Netzwerkdesign Empfehlungen um (z. B. ausreichende Verbindungskapazität zwischen den Knoten von mindestens 10 Gb, isolierte, dedizierte Kernnetze)
Vermeiden Sie die Überprovisionierung von Workload-RAM auf Compute-and-Storage-(HCI-)Knoten.
Planen Sie Wartungsvorgänge, die vollständige oder gemischte Walks auslösen, wenn möglich während geplanter Wartungsfenster und vermeiden Sie gleichzeitig parallele, stark I/O-lastige Vorgänge.
Zuletzt aktualisiert
War das hilfreich?