> 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/learn-the-platform/de/modul-5-speicher/01-vsan-architecture.md). # vSAN-Architektur und VergeFS ## VergeFS: Integrierter Speicherdienst Modul 1 führte die vSAN-Konzepte auf hoher Ebene ein. Diese Seite geht tiefer in die interne Architektur ein — wie Blöcke gehasht und verteilt werden, wie Lese- und Schreibvorgänge durch das System fließen und wie Funktionen wie Deduplizierung, Verschlüsselung und Snapshots auf Blockebene implementiert werden. ## Architektur auf Blockebene Im Kern von VergeFS befindet sich ein **Storage-Engine auf Blockebene**. Jedes auf die vSAN geschriebene Datenelement — ob VM-Datenträger, Snapshot, ISO-Image oder Systemmetadaten — wird in **Datenblöcke**. Jedem Block wird ein **SHA-1-Content-Hash** zugewiesen, der als seine eindeutige Kennung im gesamten System dient. SHA-1 wird hier für die inhaltsbasierte Adressierung und Verteilung verwendet, nicht für kryptografische Sicherheit. Dieser Hash ist die Grundlage für nahezu jede vSAN-Funktion: * **Verteilung** — Der Hash bestimmt, welche Knoten die primären und redundanten Kopien des Blocks speichern * **Deduplizierung** — Identische Blöcke erzeugen identische Hashes, daher wird nur eine Kopie gespeichert * **Integrität** — Der Hash validiert den Blockinhalt und ermöglicht so die kontinuierliche Erkennung von Bitrot * **Ableitung der Position** — Der Hash wird zusammen mit den gerätebezogenen Maps pro Tier auf Tier 0 verwendet, um die physische Position jedes Blocks deterministisch abzuleiten ### Die Hash-Map und Tier 0 Die Platzierung von Blöcken in vSAN wird **aus dem SHA-1-Content-Hash abgeleitet** und mit den auf **Tier 0** Laufwerken (hochbelastbare NVMe-SSDs) gespeicherten gerätebezogenen Maps pro Tier kombiniert: * Jedes Tier führt eine `0.map` (Geräte-Map für die primäre Kopie) und `1.map` (Geräte-Map für die sekundäre Kopie) * Der SHA-1-Hash wird als Eingabe für die deterministische Platzierungslogik gegen diese Maps verwendet — es gibt keine zentrale Tabelle, die „Block X liegt auf Knoten Y, Laufwerk Z“ verzeichnet * Referenzzähler werden **nicht** dauerhaft in einer Hash-Map gespeichert — sie werden durch den differentiellen **vSAN Walk** neu aufgebaut, während er aktive Hashes durchläuft * Der Dateisystemindex von Tier 0 und die gerätebezogenen Maps pro Tier sind das, was Tier 0 tatsächlich zusammen mit den vSAN-Metadaten enthält **Tier 0 ist ausschließlich ein Metadaten-Tier.** Es speichert den vSAN-Dateisystemindex und die gerätebezogenen Maps pro Tier. Es ist **nicht** ein Performance-Cache, und es **nicht** speichert Workload-Daten. Da vSAN-Metadatenoperationen von Tier 0 abhängen, wirkt sich die Leistung Ihrer Tier-0-Laufwerke direkt auf die gesamte Systemreaktionsfähigkeit aus. {% hint style="warning" %} **Tier 0 ist nur für Metadaten** Tier 0 kann **nicht** nicht als Performance-Cache oder Hot-Daten-Tier fungieren. Es speichert nur den vSAN-Dateisystemindex und die gerätebezogenen Maps pro Tier. Workload-Daten liegen auf den Tiers 1–5. Verwenden Sie für Tier 0 immer Enterprise-NVMe-Laufwerke mit 3 DWPD oder gleichwertig und halten Sie mindestens 30 % freien Speicherplatz vor. {% endhint %} ### Wie die Hash-Map funktioniert Das folgende Diagramm veranschaulicht, wie VM-Daten durch die vSAN-Architektur auf Blockebene fließen: ![vSAN-Hash-Map-Architektur](/files/dbf9c9ee2f5f923d317468ed3656fb4eeccb6ca7) Der Ablauf funktioniert wie folgt: 1. Eine VM schreibt Daten auf ihren virtuellen Datenträger 2. VergeFS teilt den Schreibvorgang in Datenblöcke auf 3. Jedem Block wird ein SHA-1-Content-Hash zugewiesen 4. Die Platzierungslogik gegen die gerätebezogenen Maps pro Tier (auf Tier 0 gespeichert) wählt eine primäre und eine redundante Position aus 5. Der Block wird sowohl auf einen primären Knoten als auch auf einen redundanten Knoten geschrieben 6. Metadatenaktualisierungen auf Tier 0 werden gebündelt und asynchron angewendet ## Hash-basierte Datenverteilung vSAN verteilt Datenblöcke mithilfe einer **hashbasierten Verteilungsalgorithmus**über alle an der Speicherung beteiligten Knoten innerhalb jedes Tiers. Dies sorgt für eine ausgeglichene I/O-Last, Fehlertoleranz und effiziente Skalierung. ### Schreibpfad Wenn eine VM Daten schreibt: 1. VergeFS teilt die Daten in Blöcke auf und berechnet für jeden einen SHA-1-Content-Hash 2. Die Platzierungslogik gegen die gerätebezogenen Maps pro Tier bestimmt einen **primären Knoten** und einen **redundanten Knoten** — der Controller ist **nicht** im Daten-Schreibpfad 3. Wenn bereits ein identischer Hash existiert, wird der Schreibvorgang **dedupliziert** (kein neuer Datenblock wird geschrieben; die Deduplizierung ist eine natürliche Folge der inhaltsbasierten Adressierung) 4. Bei neuen Blöcken werden beide Kopien **gleichzeitig** über das Core-Fabric-Netzwerk direkt auf die Zielknoten geschrieben 5. Der Schreibvorgang wird **erst nach Bestätigung beider Kopien bestätigt** — so wird die Datenpersistenz gewährleistet, bevor die VM ein Schreibabschluss-Signal erhält 6. Metadatenaktualisierungen auf Tier 0 werden **gebündelt** und asynchron angewendet, anstatt den Datenpfad über einen zentralen Index zu serialisieren ### Lesepfad Wenn eine VM Daten liest: 1. Die Position des Blocks wird aus seinem Inhalts-Hash und den gerätebezogenen Maps pro Tier abgeleitet 2. Das System **priorisiert das Lesen aus der primären Kopie** 3. Wenn eine redundante Kopie auf dem **gleichen Knoten wie die anfordernde VM vorhanden ist**, liest VergeFS die **lokale Kopie** lokale redundante Kopie, um den Netzwerkverkehr zu minimieren (read-local-prefer) 4. Wenn die primäre Kopie langsam oder nicht reagierend ist, schaltet VergeFS automatisch **auf die redundante Kopie um** — transparent, ohne Beeinträchtigung der VM ```mermaid flowchart TB VM["VM-Leseanforderung"] --> LOOKUP["Position ableiten
aus Inhalts-Hash"] LOOKUP --> LOCAL{"Lokale Kopie
verfügbar?"} LOCAL -->|Ja| READLOCAL["Lokale
redundante Kopie lesen"] LOCAL -->|Nein| PRIMARY["Von
primärem Knoten lesen"] PRIMARY --> HEALTHY{"Primär
reagiert?"} HEALTHY -->|Ja| RETURN["Daten an
VM zurückgeben"] HEALTHY -->|Nein| FAILOVER["Failover zur
redundanten Kopie"] READLOCAL --> RETURN FAILOVER --> RETURN style VM fill:#e3f2fd,stroke:#1565c0 style LOOKUP fill:#fff3e0,stroke:#e65100 style RETURN fill:#e8f5e9,stroke:#2e7d32 ``` ### Verteilung über Knoten hinweg Datenblöcke werden über **alle an der Speicherung beteiligten Knoten** innerhalb jedes Tiers verteilt. Dieses Design bietet: * **Ausgewogene Leistung** — Die I/O-Last wird auf alle Knoten verteilt, wodurch Hotspots vermieden werden * **Fehlertoleranz** — Kein einzelner Knoten hält alle Kopien eines Datensatzes * **Effiziente Skalierung** — Das Hinzufügen eines Knotens erweitert automatisch den Speicherpool und löst eine Neuverteilung aus * **Paralleles I/O** — Mehrere Knoten bedienen Daten gleichzeitig und erhöhen so den Gesamtdurchsatz ## Inline-Globale Deduplizierung VergeOS vSAN führt **Inline- und globale Deduplizierung** durch, die immer aktiviert ist und keine Konfiguration erfordert. Da jeder Datenblock durch seinen Inhalts-Hash identifiziert wird, ist Deduplizierung eine natürliche Folge der Architektur: 1. Wenn ein neuer Block geschrieben wird, wird sein Hash berechnet 2. Wenn bereits ein identischer Hash existiert, ist der Block ein Duplikat — Deduplizierung ist eine natürliche Folge der inhaltsbasierten Adressierung 3. Bei duplizierten Blöcken wird kein zusätzlicher Speicher verbraucht — der vorhandene Block wird einfach erneut referenziert 4. Dies erfolgt **inline** (während des Schreibpfads), nicht als Hintergrundauftrag Deduplizierung funktioniert **über alle VMs, alle Tiers und alle Datentypen** im System. Typische Szenarien, in denen Deduplizierung erhebliche Speichereinsparungen bringt, sind: * Mehrere VMs mit demselben Betriebssystem (gemeinsame OS-Blöcke) * VM-Bereitstellungen auf Basis von Vorlagen (geklonte Basis-Images) * Entwicklungsumgebungen mit ähnlichen Konfigurationen * Backup-Snapshots mit minimalen Datenänderungen zwischen den Iterationen Deduplizierungsraten sind im VergeOS-Speicher-Dashboard sichtbar und zeigen typischerweise die effektiven Kapazitätseinsparungen über jedes Tier hinweg. {% hint style="info" %} **VMware Bridge** Kommen Sie von VMware vSAN? Die Deduplizierung von VergeOS ist immer aktiv, inline und global über jeden Tier-Typ hinweg (NVMe, SSD, HDD) — es gibt keinen Schalter und keinen separaten Aktivierungsschritt. {% endhint %} ## Komprimierung VergeOS vSAN kann **nicht** Daten im Ruhezustand komprimieren. Im Gegensatz zu Plattformen, die Inline-Komprimierung auf gespeicherte Blöcke anwenden, speichert VergeFS Daten in ihrer ursprünglichen Form auf dem Datenträger. **Die Komprimierung wird nur bei der Site-Sync-Replikation angewendet** — wenn Daten über das Netzwerk zwischen VergeOS-Standorten übertragen werden. In diesem Kontext reduziert Komprimierung den Bandbreitenverbrauch bei WAN-Übertragungen, ohne die lokale Speicherleistung zu beeinträchtigen. Diese Designentscheidung hält den lokalen I/O-Pfad einfach und schnell. Deduplizierung (oben beschrieben) liefert den primären Speichereffizienzvorteil für gespeicherte Daten. ## AES-256-Verschlüsselung im Ruhezustand vSAN unterstützt **AES-256-Verschlüsselung im Ruhezustand**, konfiguriert während der ersten VergeOS-Installation. Wichtige Details: | Aspekt | Details | | ------------------------------ | ---------------------------------------------------------------------------- | | **Algorithmus** | AES-256 | | **Bei Konfiguration** | Nur während der Erstinstallation | | **Umkehrbarkeit** | Nach der Installation nicht umkehrbar | | **Umfang** | Alle Daten über alle Tiers hinweg werden transparent verschlüsselt | | **Schlüsselspeicher-Option 1** | USB-Laufwerke, die an die ersten beiden Controller-Knoten angeschlossen sind | | **Schlüsselspeicher-Option 2** | Manuelle Passworteingabe bei jedem Systemstart | Die Verschlüsselung ist für VMs und Anwendungen transparent — sie lesen und schreiben Daten ganz normal, während VergeFS die Verschlüsselung und Entschlüsselung auf Blockebene übernimmt. Die Verschlüsselungskonfiguration gilt systemweit; Sie können nicht einige Tiers verschlüsseln und andere unverschlüsselt lassen. Um den Verschlüsselungsstatus zu überprüfen: Navigieren Sie zu **Knoten > Knoten 1 > Laufwerke**, doppelklicken Sie auf das erste Laufwerk und prüfen Sie das **Verschlüsselt** Kontrollkästchen. ## Redundanzmodelle vSAN hält mehrere Kopien jedes Datenblocks vor, um sich gegen Hardwareausfälle zu schützen. Die Redundanz wird auf der **Systemebene** konfiguriert und gilt **pro Tier** — nicht pro VM oder pro Speichercontainer. | Funktion | N+1 (RF2) — Standard | N+2 (RF3) | | ------------------------------------------ | -------------------- | --------- | | **Kopien der Daten** | 2 | 3 | | **Gleichzeitige Ausfälle toleriert** | 1 Knoten | 2 Knoten | | **Mindestanzahl an Controller-Knoten** | 2 | 3 | | **Empfohlene Knoten** | 3 | 5 | | **Speicher-Overhead** (vor Deduplizierung) | \~2x | \~3x | **N+1 (RF2)** ist die Standardkonfiguration und eignet sich für die meisten Produktionsumgebungen. Sie hält zwei Kopien jedes Blocks auf verschiedenen Knoten vor und toleriert einen gleichzeitigen Knotenfehler. **N+2 (RF3)** hält drei Kopien über drei oder mehr Knoten vor und toleriert zwei gleichzeitige Ausfälle. Dies ist für ultra-kritische Workloads oder Remote-/Edge-Standorte gedacht, an denen Ersatzhardware nicht schnell eintreffen kann. Ein Ausfall betrifft nur das **Tier, in dem sich die ausgefallenen Laufwerke befinden** — andere Tiers bleiben vollständig betriebsfähig. Wenn in einem N+2-System beispielsweise Tier-1-Laufwerke auf zwei Knoten ausfallen und auf einem dritten Knoten ein Tier-4-Laufwerk ausfällt, bleibt der Cluster ohne Datenverlust betriebsfähig. {% hint style="success" %} **Repair-Server** Für zusätzlichen Schutz über das konfigurierte Redundanzniveau hinaus kann ein **Repair-Server** so konfiguriert werden, dass fehlende Datenblöcke automatisch von einem Sync-Ziel abgerufen werden, wenn Ausfälle das konfigurierte Redundanzniveau überschreiten — wodurch möglicherweise ein vollständiges Zurückrollen des Snapshots vermieden wird. {% endhint %} ## Selbstheilung Wenn ein Knoten oder Laufwerk ausfällt, erkennt vSAN den Ausfall automatisch und beginnt ohne manuelle Eingriffe mit der Wiederherstellung: ```mermaid flowchart LR A["Ausfall von Laufwerk oder Knoten
erkannt"] --> B["Lese-/Schreibvorgänge umgeleitet
zu redundanten Kopien"] B --> C["VMs laufen weiter
— keine Ausfallzeit"] B --> D["Automatischer Wiederaufbau
beginnt sofort"] D --> E["Fehlende Blöcke werden
erneut auf
gesunde Knoten repliziert"] E --> F["Vollständige Redundanz
wiederhergestellt"] style A fill:#fce4ec,stroke:#c62828 style C fill:#e8f5e9,stroke:#2e7d32 style F fill:#e8f5e9,stroke:#2e7d32 ``` Der Selbstheilungsprozess: 1. **Erkennung** — vSAN überwacht kontinuierlich den Zustand von Laufwerken und Knoten. Ausfälle werden automatisch erkannt. 2. **Failover** — Lese- und Schreibvorgänge werden sofort auf redundante Kopien umgeleitet. VMs erleben keine Ausfallzeit. 3. **Rebuild** — Fehlende Datenblöcke werden aus den überlebenden Kopien auf die verbleibenden gesunden Knoten erneut repliziert. Dies geschieht im Hintergrund, während die Workloads weiterlaufen. 4. **Wiederherstellung** — Sobald alle Blöcke erneut repliziert wurden, kehrt das Tier auf das konfigurierte Redundanzniveau zurück. ### Datenintegrität Über die Wiederherstellung nach Ausfällen hinaus führt vSAN **kontinuierliche Bitrot-Erkennung** mithilfe von Hash-Validierung durch. Der gespeicherte Hash jedes Blocks wird regelmäßig gegen seinen Inhalt geprüft. Wenn eine Beschädigung erkannt wird, wird der Block automatisch aus einer gültigen redundanten Kopie repariert. ## Speichereffiziente Snapshots und Klone Die Architektur auf Blockebene von vSAN ermöglicht **speichereffiziente Snapshots** die nur minimal zusätzlichen Speicherplatz verbrauchen: * Ein Snapshot erfasst den **Zustand des Dateisystemindex zu einem bestimmten Zeitpunkt** — er kopiert keine Datenblöcke * Von einem Snapshot referenzierte Blöcke bleiben erhalten, selbst wenn die ursprüngliche VM sie löscht (Referenzzählung) * Klone funktionieren ähnlich — sie verweisen auf dieselben zugrunde liegenden Blöcke und verbrauchen erst dann zusätzlichen Speicherplatz, wenn sich Daten unterscheiden (Copy-on-Write) * Snapshots können **über ein optionales Flag unveränderlich gemacht werden** mit den Zuständen Entsperrt/Gesperrt/Entsperren und einer siebentägigen Entsperrverzögerung nach dem Sperren; standardmäßige Snapshots können gelöscht werden. Sperren Sie Snapshots, wenn Ransomware-Schutz oder Aufbewahrungsgarantien erforderlich sind. ### Löschen und Speicherbereinigung Wenn eine VM, ein Laufwerk oder ein Snapshot gelöscht wird: 1. Die Hashes der Datei werden aus dem vSAN-Verzeichnisbaum entfernt 2. Das **vSAN Walk** der differentielle Walk leitet die Referenzzähler aus den verbleibenden aktiven Hashes neu ab — Zähler werden nicht gespeichert, sie werden während des Durchlaufs neu aufgebaut 3. Blöcke, die auf null Referenzen fallen, warten ungefähr **10 Walks (\~70 Sekunden)** bevor sie für die Bereinigung infrage kommen, was ein Sicherheitsfenster gegen schnelle Änderungen bietet 4. Physischer Speicherplatz wird asynchron freigegeben, während der Walk diese Blöcke bereinigt Deshalb verringert sich der Speicherplatz nach einer Löschung möglicherweise nicht sofort — die Bereinigung erfolgt asynchron während der Hintergrund-vSAN-Walk-Operationen. ## Wichtige Erkenntnisse | Konzept | Zusammenfassung | | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **VergeFS** | Integrierter verteilter Speicher — kein externes SAN/NAS, kein CVM-Overhead | | **Blockarchitektur** | Alle Daten werden in Blöcke aufgeteilt, die jeweils durch einen SHA-1-Content-Hash identifiziert werden | | **Tier 0** | Nur Metadaten (Dateisystemindex + gerätebezogene Maps pro Tier). Kein Cache. Erforderlich auf Controller-Knoten (Knoten 1–2 für N+1, 1–3 für N+2). | | **Verteilung** | Hash-basiert, verteilt über alle an der Speicherung beteiligten Knoten pro Tier | | **Deduplizierung** | Inline, immer aktiv, global über alle Tiers hinweg — keine Konfiguration erforderlich | | **Komprimierung** | Nicht im Ruhezustand — nur während der Site-Sync-Replikation | | **Verschlüsselung** | AES-256 im Ruhezustand, bei der Installation konfiguriert, nicht umkehrbar | | **Redundanz** | N+1 (2 Kopien, Standard) oder N+2 (3 Kopien) — systemweit pro Tier | | **Selbstheilend** | Automatisches Failover und Wiederaufbau bei Ausfällen, kontinuierliche Bitrot-Erkennung | | **Snapshots** | Zeitpunktbezogene Hash-Referenzen, speichereffizient; Unveränderlichkeit ist optional (Entsperrt/Gesperrt/Entsperren, 7-tägige Entsperrverzögerung) | ## Nächste Schritte Nachdem Sie nun die interne Architektur von vSAN verstanden haben, behandelt das nächste Thema, wie das Tier-System in der Praxis funktioniert — Tiers konfigurieren, Laufwerke zuweisen, Kapazität planen und Speicher skalieren: [**Speicherebenen**](/learn-the-platform/de/modul-5-speicher/02-storage-tiers.md) --- # 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/learn-the-platform/de/modul-5-speicher/01-vsan-architecture.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.