> 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-1-architekturgrundlagen/03-vsan-vergefs.md).

# vSAN / VergeFS: Softwaredefinierter Storage

## Was ist vSAN / VergeFS?

**vSAN** (Virtual Storage Area Network), auch bekannt als **VergeFS**, ist das softwaredefinierte verteilte Speichersystem, das in jeder VergeOS-Bereitstellung integriert ist. Es bündelt die physischen (oder virtuellen) Laufwerke aller speicherbeteiligten Knoten zu einer einzigen, gemeinsam genutzten Speicherressource für das gesamte System.

Es ist kein externes SAN, NAS oder Speichersoftware eines Drittanbieters erforderlich. vSAN ist direkt in die VergeOS-Plattform integriert und arbeitet auf Blockebene, wobei es Speicher für alle VM-Disks, Snapshots, ISO-Images und Systemmetadaten bereitstellt.

Wesentliche Merkmale:

* **Architektur auf Blockebene** — VM-Disks werden in Blöcke aufgeteilt, die jeweils durch einen inhaltadressierbaren Hash identifiziert werden
* **Über Knoten verteilt** — Datenblöcke werden über alle speicherbeteiligten Knoten im Cluster verteilt
* **Mehrstufiger Speicher** — Tier 0 ist für vSAN-Metadaten reserviert; die Tiers 1–5 sind Workload-Speichertiers, mit denen Sie den Medientyp an die Workload-Anforderungen anpassen können
* **Inline-Deduplizierung** — Die blockbasierte Identifikation per Hash ermöglicht automatische Deduplizierung über alle Tiers hinweg
* **Selbstheilend** — Automatische Fehlererkennung und Failover zu redundanten Kopien. Der Rebuild wird vom Administrator ausgelöst (Hot Spare oder Hardwareaustausch); Journal Walks replizieren dann die fehlenden Blöcke aus redundanten Kopien erneut. Die Selbstheilung arbeitet innerhalb des konfigurierten Redundanzniveaus (N+1 oder N+2); Ausfälle, die die Redundanz überschreiten (z. B. der gleichzeitige Verlust von mehr Knoten, als das System tolerieren kann), können zu hängengebliebenen Reparaturen führen, die manuelle Eingriffe und Unterstützung erfordern

{% hint style="info" %}
**VMware-Übergang**

Kommen Sie vom vSAN-Cache-+Kapazitätsmodell und von VM-spezifischen Speicherrichtlinien? VergeFS verwendet standardmäßig 5 Workload-Tiers (T1–T5) plus 1 Metadatentier (Tier 0), führt Inline-Deduplizierung über alle Tiers hinweg durch, wendet eine einzige systemweite Redundanzeinstellung (N+1/N+2) an und unterstützt sowohl HCI- als auch UCI-Bereitstellungen. Komprimierung wird nur während der Site-Sync-Replikation angewendet — nicht im Ruhezustand.
{% endhint %}

{% hint style="info" %}
**Nutanix-Übergang**

Kommen Sie von Nutanix DSF und seiner CVM-pro-Knoten-Architektur? VergeFS läuft als integrierter OS-Dienst — keine separate CVM, kein CPU-/RAM-Overhead pro Knoten. Es verwendet standardmäßig 5 Workload-Tiers (T1–T5) plus 1 Metadatentier (Tier 0) ohne automatische Verschiebung zwischen heiß/kalt, eine einzige systemweite N+1/N+2-Redundanzeinstellung, immer aktive Inline-Deduplizierung und unterstützt sowohl HCI- als auch UCI-Bereitstellungen.
{% endhint %}

## Das Tiersystem

VergeOS vSAN organisiert Laufwerke in **Tiers** mit den Nummern 0 bis 5. Jeder Tier ist für eine andere Klasse von Speichermedien und Workload-Profilen ausgelegt. Während der Installation wird jedem physischen Laufwerk ein bestimmter Tier zugewiesen, und diese Zuweisung bestimmt, wie das Laufwerk vom System verwendet wird.

### Tier 0: Metadaten

* **Hardware**: Hochausdauer-NVMe-SSDs
* **Zweck**: Speichert ausschließlich den vSAN-Dateisystemindex und interne Metadaten
* **Wichtige Anforderung**: Tier 0 befindet sich nur auf Controller-Knoten — Knoten 1–2 für N+1 oder Knoten 1–3 für N+2
* **Best Practice**: Verwenden Sie Enterprise-NVMe-Laufwerke mit 3 DWPD (Drive Writes Per Day) oder gleichwertig (d. h. wenn Sie nur 500 GB für vSAN-Metadaten benötigen, bietet ein größeres 2-TB-Laufwerk mit 1 DWPD eine vergleichbare gesamte Schreibausdauer); halten Sie mindestens 30 % freien Speicherplatz auf Tier 0 vor

### Tiers 1–5: Workload-Daten

| Tier       | Hardware               | Zweck                                 | Typische Anwendungsfälle                                    |
| ---------- | ---------------------- | ------------------------------------- | ----------------------------------------------------------- |
| **Tier 1** | Hochausdauer-NVMe-SSDs | Schreibintensive Workloads            | Hochleistungsdatenbanken, Transaktionsprotokolle            |
| **Tier 2** | Mittelklasse-SSDs      | Ausgewogene Lese-/Schreib-Workloads   | Allzweck-VMs, gemischte Anwendungen, Entwicklungsumgebungen |
| **Tier 3** | Leseoptimierte SSDs    | Leselastige Workloads                 | Content-Delivery, Anwendungs-Repos, Referenzdaten           |
| **Tier 4** | Hochkapazitäts-HDDs    | Weniger häufig abgerufene Daten       | Dateiserver, Backup-Ziele                                   |
| **Tier 5** | Archivtaugliche HDDs   | Kaltlagerung und Langzeitaufbewahrung | Compliance-Archive, Backup-Archive                          |

Nicht jede Bereitstellung nutzt alle fünf Workload-Tiers. Eine typische Produktionskonfiguration könnte nur Tier 1 (NVMe für leistungs-/latenzsensitive Workloads) und Tier 4 (HDD für Kapazität) verwenden. Die Terraform-Spielwiese verwendet nur Tier 0 und Tier 1.

```mermaid
graph LR
    subgraph "vSAN-Tier-Architektur"
        T0["Tier 0<br/>Metadaten<br/>NVMe"]
        T1["Tier 1<br/>Hochleistung<br/>NVMe-SSD"]
        T2["Tier 2<br/>Gemischte Workloads<br/>SSD"]
        T3["Tier 3<br/>Leseoptimiert<br/>SSD"]
        T4["Tier 4<br/>Kapazität<br/>HDD"]
        T5["Tier 5<br/>Archiv<br/>HDD"]
    end

    T0 -.->|"Nachschlagen in der<br/>Hash-Map"| T1
    T0 -.->|"Nachschlagen in der<br/>Hash-Map"| T2
    T0 -.->|"Nachschlagen in der<br/>Hash-Map"| T3
    T0 -.->|"Nachschlagen in der<br/>Hash-Map"| T4
    T0 -.->|"Nachschlagen in der<br/>Hash-Map"| T5

    style T0 fill:#e3f2fd,stroke:#1565c0
    style T1 fill:#e8f5e9,stroke:#2e7d32
    style T2 fill:#e8f5e9,stroke:#2e7d32
    style T3 fill:#fff3e0,stroke:#e65100
    style T4 fill:#fce4ec,stroke:#c62828
    style T5 fill:#f3e5f5,stroke:#6a1b9a
```

{% hint style="info" %}
**VMware-Übergang**

VMware vSAN hat Cache-+Kapazitätstiers und verwendet VM-spezifische Speicherrichtlinien (FTT, Stripe-Breite, Erasure Coding). VergeOS verwendet 6 explizite Tiers und keine VM-spezifischen Richtlinien — wählen Sie den Tier bei der Laufwerksbereitstellung, und die Redundanz (N+1/N+2) wird systemweit festgelegt.
{% endhint %}

{% hint style="info" %}
**Nutanix-Übergang**

Nutanix AOS organisiert Daten in Speichercontainern innerhalb eines Storage-Pools und verwendet die Intelligent Tiering Engine (ILM), um Blöcke anhand von Zugriffsmustern zwischen SSD und HDD zu verschieben. VergeOS verschiebt keine Daten zwischen Tiers — Laufwerke werden bei der Installation zugewiesen und Daten bleiben dort, wo sie geschrieben wurden; dafür gibt es eine explizite Platzierung und vorhersehbare Leistung.
{% endhint %}

## Wie Daten verteilt werden

vSAN verwendet einen **hashbasierten Verteilungsalgorithmus** um Datenblöcke über alle Knoten im Cluster zu verteilen. So funktioniert es:

### Blockerstellung und Hashing

1. Wenn eine VM Daten schreibt, teilt vSAN den Schreibvorgang in **Datenblöcke**
2. Jeder Block erhält einen **inhaltadressierbaren Hash** der als seine eindeutige Kennung dient
3. Der Hash bestimmt sowohl den Speicherort des Blocks als auch die Deduplizierung — wenn zwei Blöcke denselben Hash erzeugen, wird nur eine Kopie gespeichert

### Verteilung über Knoten hinweg

Datenblöcke werden über mehrere Knoten im Cluster verteilt statt auf einem einzelnen Knoten gespeichert. Dieses Design bietet:

* **Ausgewogene Leistung** — Die I/O-Last wird auf alle speicherbeteiligten Knoten verteilt
* **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

```mermaid
graph TB
    VM["VM-Schreibvorgang"]
    VM --> HASH["Block-Hashing<br/>(kryptografischer Hash pro Block)"]
    HASH --> DIST["Hashbasierte Verteilung"]
    DIST --> N1["Knoten 1<br/>Primär: Block A, C<br/>Redundant: Block B"]
    DIST --> N2["Knoten 2<br/>Primär: Block B<br/>Redundant: Block A, C"]
    DIST --> N3["Knoten 3<br/>Primär: Block D<br/>Redundant: Block E"]
    DIST --> N4["Knoten 4<br/>Primär: Block E<br/>Redundant: Block D"]

    style VM fill:#e3f2fd,stroke:#1565c0
    style HASH fill:#fff3e0,stroke:#e65100
    style DIST fill:#e8f5e9,stroke:#2e7d32
```

### Lese- und Schreibpfade

**Lesen:**

* Das System ermittelt den Speicherort des Blocks über die Hash-Map auf Tier 0
* Beim Lesen wird die **primäre Kopie** für mehr Effizienz
* Wenn die VM auf demselben Knoten wie eine redundante Kopie läuft, liest vSAN die **lokale Kopie** um den Netzwerkverkehr zu minimieren
* Wenn die primäre Kopie langsam oder nicht reagierend ist, wechselt vSAN automatisch zur redundanten Kopie

**Schreiben:**

* Neue Blöcke werden gehasht und auf dem optimalen Knoten platziert
* Sowohl die **primäre als auch die redundanten Kopien** werden gleichzeitig geschrieben
* Der Schreibvorgang wird erst bestätigt, nachdem beide Kopien bestätigt wurden
* Die Tier-0-Metadaten werden aktualisiert, um den Speicherort des neuen Blocks nachzuverfolgen

## Redundanz und Selbstheilung

vSAN hält mehrere Kopien jedes Datenblocks vor, um vor Hardwarefehlern zu schützen. Das Redundanzniveau — auch bekannt als **Replikationsfaktor (RF)** — wird auf Systemebene konfiguriert und gilt pro Tier. RF ist einfach die Anzahl der vorgehaltenen Kopien: **RF2** (N+1) hält 2 Kopien, **RF3** (N+2) hält 3.

### Redundanzstufen

| 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) | \~2×                 | \~3×      |

* **N+1 (RF2)** ist der Standard und eignet sich für die meisten Produktionsumgebungen
* **N+2 (RF3)** ist für hochkritische Workloads oder entfernte Standorte verfügbar, an denen der Hardwareaustausch langsam ist
* Das Redundanzniveau wird normalerweise während der Installation festgelegt und gilt systemweit
* Ein Ausfall betrifft nur den Tier, auf dem die ausgefallenen Laufwerke liegen — andere Tiers bleiben voll betriebsfähig

### Selbstheilungsprozess

Wenn ein Knoten oder Laufwerk ausfällt, wechselt vSAN automatisch auf redundante Kopien — VMs laufen ohne Ausfallzeit weiter, aber der betroffene Tier arbeitet mit verringerter Redundanz. Die Wiederherstellung der vollen Redundanz wird vom Betreiber angestoßen: entweder einen Rebuild gegen einen zugewiesenen Hot Spare starten oder das ausgefallene Laufwerk (oder den Knoten) ersetzen; dann beginnt der Rebuild von dort aus:

```mermaid
flowchart LR
    A["Laufwerk- oder Knoten<br/>Fehler erkannt"] --> B["Failover zu<br/>redundanten Kopien"]
    B --> C["VMs laufen weiter<br/>(keine Ausfallzeit)"]
    B --> D["Tier arbeitet mit<br/>reduzierter Redundanz"]
    D --> E{"Aktion des Betreibers"}
    E -->|"Rebuild auf<br/>Hot Spare starten"| F["Rebuild beginnt"]
    E -->|"Ausgefallenes<br/>Laufwerk oder Knoten ersetzen"| F
    F --> G["Volle Redundanz<br/>wiederhergestellt"]

    style A fill:#fce4ec,stroke:#c62828
    style C fill:#e8f5e9,stroke:#2e7d32
    style D fill:#fff3e0,stroke:#e65100
    style G fill:#e8f5e9,stroke:#2e7d32
```

1. **Erkennung** — vSAN erkennt den Ausfall des Laufwerks oder Knotens automatisch; die Topologieänderung löst einen **vollständigen Journal Walk** aus, der die Redundanz über den betroffenen Tier hinweg erneut überprüft
2. **Failover** — Lese- und Schreibzugriffe werden ohne VM-Ausfallzeit auf redundante Kopien umgeleitet
3. **Reduzierte Redundanz** — Der betroffene Tier arbeitet ohne volle Redundanz, bis ein Betreiber eingreift
4. **Rebuild** — Ein Betreiber initiiert entweder einen Rebuild gegen einen zugewiesenen Hot Spare oder ersetzt das ausgefallene Laufwerk/den ausgefallenen Knoten. vSAN repliziert dann die betroffenen Blöcke erneut, um die volle Redundanz wiederherzustellen

{% hint style="info" %}
**Was ist ein Journal Walk?**

Ein **Journal Walk** ist der Hintergrunddurchlauf von vSAN über einen Speichertier, der Block-Referenzzähler neu aufbaut (die niemals dauerhaft gespeichert werden), die Redundanz überprüft und notwendige Reparaturen anstößt. Er läuft in drei Formen: ein **Full Walk** (ausgelöst durch den Start des Controllers oder eine Topologieänderung wie einen Laufwerks-/Knotenausfall oder das Hinzufügen bzw. Entfernen eines Knotens), ein **Mixed Walk** (wenn ein anderer Knoten als der aktive Controller neu startet) und ein routinemäßiger **Differential Walk**. Auf dem vSAN-Tier-Dashboard zeigt das `laufend` -Flag an, dass ein Walk im Gange ist, und `Walk-Fortschritt` zeigt seinen Prozentsatz. Siehe [vSAN-Tier-Status / Journal Walks verstehen](/knowledge-base/de/storage-vsan/understanding-journal-walks-and-vsan-tier-status.md) für die vollständige Aufschlüsselung.
{% endhint %}

{% hint style="info" %}
**VMware-Übergang**

Kommen Sie vom vSAN-VM-spezifischen Speicherpolicies-Modell (FTT, Stripe-Breite) und automatischem Rebuild auf Zeitbasis? VergeOS verwendet eine einzige systemweite Redundanzeinstellung (N+1 oder N+2) und stellt die Redundanz auf Betreiberaktion wieder her — Rebuild auf einen Hot Spare starten oder die ausgefallene Hardware ersetzen.
{% endhint %}

{% hint style="info" %}
**Nutanix-Übergang**

Kommen Sie von Nutanix' pro-Container-Replikationsfaktor und Curator-gesteuerter Neuverteilung? VergeOS verwendet eine einzige systemweite N+1- oder N+2-Einstellung und stellt die Redundanz auf Betreiberaktion wieder her — Rebuild auf einen Hot Spare starten oder die ausgefallene Hardware ersetzen.
{% endhint %}

## Laufwerkszuweisung in der Praxis

Während der VergeOS-Installation wird jedes physische Laufwerk einem bestimmten vSAN-Tier zugewiesen. Der Installer verwendet die `YC_DRIVE_LIST` und `YC_VSAN_TIER_LIST` Variablen (interaktiv während der Installation festgelegt), um Laufwerke Tiers zuzuordnen.

### Zuweisungsregeln

* **Tier-0-Platzierung**: Tier 0 befindet sich nur auf Controller-Knoten — Knoten 1–2 für N+1 oder Knoten 1–3 für N+2
* Laufwerke innerhalb desselben Tiers sollten von ähnlichem Typ und mit ähnlichen Leistungsmerkmalen sein
* Beim Hochskalieren (Hinzufügen von Laufwerken) fügen Sie **gleiche Laufwerke über alle Knoten hinweg** im Cluster hinzu, um eine ausgewogene Verteilung beizubehalten
* Beim Skalieren nach außen (Hinzufügen von Knoten) sollten neue Knoten der Hardwarekonfiguration des bestehenden Clusters entsprechen (CPU, Speicher, Laufwerkslayout)

### Beispiel: 2-Knoten-HCI-Konfiguration

In der einfachsten Bereitstellung der Terraform-Spielwiese hat jeder Controller-Knoten:

| Laufwerk        | Tier   | Zweck                                          |
| --------------- | ------ | ---------------------------------------------- |
| 1× NVMe (klein) | Tier 0 | Metadaten — vSAN-Hash-Map und Dateisystemindex |
| 1× NVMe (groß)  | Tier 1 | Workload-Daten — VM-Disks, Snapshots, ISOs     |

Beide Knoten tragen ihre Laufwerke zum selben vSAN-Pool bei. Mit N+1-Redundanz (Standard) hat jeder auf Tier 1 auf Knoten 1 geschriebene Block eine redundante Kopie auf Knoten 2 und umgekehrt.

## Zusätzliche vSAN-Funktionen

### Inline-Deduplizierung

Da jeder Datenblock durch seinen kryptografischen Hash identifiziert wird, erkennt vSAN automatisch doppelte Blöcke. Wenn zwei VMs (oder zwei Bereiche innerhalb desselben VM-Datenträgers) identische Daten schreiben, wird nur eine Kopie dieses Blocks gespeichert. Dies geschieht inline — während des Schreibpfads — ohne separaten Deduplizierungsjob oder Zeitplan.

### Verschlüsselung

vSAN unterstützt **AES-256-Verschlüsselung im Ruhezustand**, konfiguriert während der Erstinstallation. Verschlüsselungsschlüssel können auf USB-Laufwerken gespeichert werden (angeschlossen an die ersten beiden Controller-Knoten) oder beim Start manuell eingegeben werden. Alle Daten über alle Tiers hinweg werden transparent verschlüsselt.

### Snapshots und Klone

Die Architektur auf Blockebene von vSAN ermöglicht **speichereffiziente Snapshots** — ein Snapshot speichert den Hash-Map-Status zu einem Zeitpunkt, anstatt Datenblöcke zu kopieren. Klone verweisen ebenfalls auf vorhandene Blöcke und verbrauchen zusätzlichen Speicherplatz nur, wenn sich Daten unterscheiden.

## Kernaussagen

| Konzept             | Zusammenfassung                                                                                      |
| ------------------- | ---------------------------------------------------------------------------------------------------- |
| **vSAN / VergeFS**  | Integrierter verteilter Speicher — keine externe SAN/NAS erforderlich                                |
| **Tier 0**          | Nur Metadaten (NVMe). Befindet sich nur auf Controller-Knoten (1–2 für N+1, 1–3 für N+2).            |
| **Tiers 1–5**       | Workload-Daten, von Hochleistungs-NVMe bis Archiv-HDD                                                |
| **Datenverteilung** | Hashbasiert, über alle Speicherknoten verteilt                                                       |
| **Redundanz**       | N+1 (2 Kopien, Standard) oder N+2 (3 Kopien) — systemweit pro Tier                                   |
| **Selbstheilend**   | Automatisches Failover bei Fehlern; Rebuild wird vom Betreiber angestoßen (Hot Spare oder Austausch) |
| **Deduplizierung**  | Inline, hashbasiert, über alle Tiers hinweg                                                          |
| **Komprimierung**   | Nicht im Ruhezustand — nur während der Site-Sync-Replikation                                         |

## Nächste Schritte

Jetzt, da Sie wissen, wie VergeOS Daten speichert, behandelt das nächste Thema die Netzwerkinfrastruktur, die alle Knoten verbindet und den vSAN-Replikationsverkehr transportiert: [**Kernnetz & Netzwerke →**](/learn-the-platform/de/modul-1-architekturgrundlagen/04-core-fabric.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-1-architekturgrundlagen/03-vsan-vergefs.md?ask=<question>&goal=<endgoal>
```

`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.