> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/de/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md). # vSAN-Tier-Status-/Journal-Durchläufe verstehen ## Ü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. {% hint style="info" %} **Die Überwachung der auf dieser Seite behandelten Statusinformationen des vSAN-Tiers ist im normalen Betrieb in der Regel nicht erforderlich (allgemeine vSAN-Gesundheit und Aktivität können auf dem Haupt-Dashboard überwacht werden). Die folgenden Details sind für die Fehlerbehebung oder für Benutzer gedacht, die die Einzelheiten der Journal-Walk-Aktivität einsehen möchten. Dieses Dashboard ist besonders nützlich, wenn ein Problem untersucht oder der Fortschritt eines Journal Walks verfolgt wird, z. B. während eines Aktualisierungsvorgangs.** {% endhint %} ## 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.). {% hint style="info" %} **Wenn ein anderer Knoten als der aktive Controller neu startet, wird stattdessen ein gemischter Walk ausgelöst.** {% endhint %} * **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](#journal-walk-duration) 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. {% hint style="success" %} **Wenn fehlende Datenblöcke bereits erkannt wurden und noch kein Reparaturserver konfiguriert ist, ist es noch nicht zu spät.** [**Das Einrichten eines Reparaturservers**](/automate-protect-and-extend/backup-and-dr/repair-server.md) **ermöglicht VergeFS jetzt, bei nachfolgenden Journal Walks automatisch zu versuchen, diese Blöcke wiederherzustellen.** {% endhint %} * **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](/plan-and-deploy/implementation-guide/sizing.md) (z. B. dediziertes Tier 0 mit NVME-Laufwerken, passend dimensionierter Controller-Speicher für Ihre Umgebung) * Setzen Sie [Netzwerkdesign](/plan-and-deploy/implementation-guide/network-design.md) 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. {% hint style="info" %} **Wenn Sie Fragen oder Bedenken bezüglich des Zeitrahmens der Walk-Transaktionen haben, wenden Sie sich bitte an unser Support-Team, um Unterstützung zu erhalten.** {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/knowledge-base/de/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.