> 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/02-storage-tiers.md).

# Speicherebenen

## Das VergeOS-Speicher-Tier-Modell

VergeOS vSAN organisiert physischen Speicher in **5 Workload-Tiers (1–5) plus ein dediziertes Metadaten-Tier (Tier 0)**, die jeweils für eine bestimmte Art von Workload oder Datentyp ausgelegt sind. Diese abgestufte Architektur ermöglicht es Unternehmen, Leistung, Kapazität und Kosten auszubalancieren, indem sie VM-virtuelle Datenträger auf dem für ihr Workload-Profil am besten geeigneten Tier bereitstellen.

### Tier 0 — Metadaten

vSAN-Dateisystemindex und gerätebezogene Zuordnungen pro Tier. Erforderlich auf Controller-Knoten. Kein Cache — ausschließlich Metadaten.

### Tiers 1–3 — Leistung

NVMe- und SSD-Tiers für schreibintensive, gemischte bzw. leseoptimierte Workloads.

### Tiers 4–5 — Kapazität

HDD-Tiers für Dateiserver, Backup-Ziele, Compliance-Archive und Cold Storage.

Im Gegensatz zu Speicherplattformen, die einen einzigen Pool mit Hintergrund-Datenverschiebung verwenden, gibt VergeOS Administratoren explizite Kontrolle darüber, wo Daten gespeichert werden. Sie wählen das Tier, wenn Sie einen VM-Datenträger bereitstellen, und die Daten bleiben für die gesamte Lebensdauer des virtuellen Datenträgers auf diesem Tier.

## Tier-Spezifikationen

Die folgende Tabelle fasst den Hardwaretyp, den Zweck und die typischen Einsatzszenarien der einzelnen Tiers zusammen:

| Tier  | Medientyp                  | Zweck                             | Typische Anwendungsfälle                                                                   |
| ----- | -------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------ |
| **0** | NVMe mit hoher Haltbarkeit | vSAN-Metadaten                    | Dateisystemindex, gerätebezogene Zuordnungen pro Tier — erforderlich auf Controller-Knoten |
| **1** | Hochausdauer-NVMe-SSDs     | Schreibintensive Workloads        | Hochleistungsdatenbanken, Transaktionsprotokolle, schreibintensive Anwendungen             |
| **2** | Mittelklasse-SSDs          | Gemischte Lese-/Schreib-Workloads | VMs für allgemeine Zwecke, gemischte Anwendungs-Workloads, Entwicklung/Test                |
| **3** | Leseoptimierte SSDs        | Leselastige Workloads             | Content Delivery, Anwendungs-Repositorys, Referenzdaten                                    |
| **4** | Hochkapazitäts-HDDs        | Kapazität für große Datenmengen   | Dateiserver, Backup-Ziele, selten genutzte Daten                                           |
| **5** | Archivtaugliche HDDs       | Cold Storage / Archiv             | Compliance-Archive, langfristige Aufbewahrung, regulatorische Daten                        |

### Tier 0: Das Metadaten-Tier

Tier 0 verdient besondere Aufmerksamkeit, da es sich grundlegend von den Workload-Tiers unterscheidet. Es speichert **nur** vSAN-Metadaten — den Dateisystemindex und die gerätebezogenen Zuordnungen pro Tier, aus denen die Blockplatzierung abgeleitet wird. Es gibt keine zentrale Tabelle, die Blockpositionen oder Referenzzähler verfolgt: Die Platzierung wird aus dem Inhalts-Hash jedes Blocks gegen die Gerätezuordnungen berechnet, und die Referenzzähler werden durch den vSAN Walk neu aufgebaut.

**Dimensionierungsrichtlinie:** Planen Sie ungefähr **5 GB Tier-0-Kapazität pro 1 TB nutzbarer Speicherkapazität** (mindestens) oder **10 GB pro 1 TB** (empfohlen) über alle Ihre Workload-Tiers hinweg. Verwenden Sie Enterprise-NVMe-Laufwerke mit einer Auslegung für **3 DWPD oder gleichwertig (d. h. TBW)**. Halten Sie stets mindestens **30 % freien Speicherplatz** auf Tier 0 vor, um Metadaten-Druck zu vermeiden.

**Hardwareanforderungen:** Verwenden Sie NVMe-Laufwerke der Enterprise-Klasse mit mindestens **3 DWPD** (Drive Writes Per Day) Haltbarkeit. Consumer-NVMe-Laufwerke werden für Tier 0 in Produktionsumgebungen nicht unterstützt.

### Workload-Tiers (1–5)

Tiers 1 bis 5 speichern tatsächliche VM-Daten. Nicht jede Bereitstellung benötigt alle fünf Workload-Tiers — viele Produktionsumgebungen verwenden nur zwei oder drei. Die Tier-Nummern sind ein Rangsystem: Niedrigere Zahlen stehen für höhere Leistung (und in der Regel höhere Kosten pro GB), während höhere Zahlen eine größere Kapazität (zu niedrigeren Kosten pro GB) anzeigen.

**Gängige Bereitstellungsmuster:**

* **All-Flash:** Tier 0 (Metadaten) + Tier 1 oder 2 (alle VM-Workloads)
* **Hybrid:** Tier 0 (Metadaten) + Tier 2 (leistungsintensive VMs) + Tier 4 (Dateiserver, Backups)
* **Mehrstufig:** Tier 0 (Metadaten) + Tier 1 (Datenbanken) + Tier 2 (allgemeine VMs) + Tier 4 (Dateifreigaben) + Tier 5 (Archiv)

### Verhalten der bevorzugten Tier-Stufe

Beim Erstellen oder Ändern eines VM-virtuellen Datenträgers legen Sie eine **Bevorzugte Ebene**bevorzugte Tier-Stufe **System > Systemeinstellungen > Standard-VM-Laufwerkstier**. Wenn das angegebene Tier im Cluster nicht vorhanden ist:

* **Höheres Tier angefordert als verfügbar:** Das System wählt das nächsthöhere (langsamere) Tier. Wenn Sie beispielsweise Tier 3 in einem System mit Tier 1 und Tier 4 anfordern, wird Tier 4 als Speicherort verwendet.
* **Niedrigeres Tier angefordert als verfügbar:** Das System wählt das nächstniedrigere (schnellere) Tier. Wenn Sie beispielsweise Tier 3 in einem System mit Tier 1 und Tier 2 anfordern, wird Tier 2 als Speicherort verwendet.

Dieses Fallback-Verhalten stellt sicher, dass VMs immer bereitgestellt werden können, selbst wenn das exakt angeforderte Tier nicht vorhanden ist.

## Kein automatisches Tiering

Dies ist eines der wichtigsten Konzepte, die Sie über den VergeOS-Speicher verstehen sollten:

{% hint style="danger" %}
**Wichtiges Konzept: Keine automatische Datenverschiebung**

VergeOS **NICHT** führt VergeOS kein automatisches Hot/Cold-Tiering auf Basis von Zugriffsmustern durch. Es gibt keine richtliniengesteuerte Datenbewegung. Daten verbleiben auf ihrem bereitgestellten Tier, es sei denn, ein Administrator ändert die bevorzugte Tier-Stufe des Datenträgers — wodurch eine Live-Hintergrundmigration online und ohne Ausfallzeit ausgelöst wird. Die Tier-Zuordnung ist eine administrative Entscheidung.
{% endhint %}

Dieses Design ist absichtlich so gewählt und bietet mehrere Vorteile:

* **Vorhersehbare Leistung** — Workloads erhalten konsistente I/O-Eigenschaften, weil ihre Daten nie unerwartet auf langsamere Medien migrieren
* **Einfache Kapazitätsplanung** — Die Kapazität jedes Tiers wird nur von explizit bereitgestellten Workloads verbraucht
* **Kein Hintergrund-Overhead** — Keine Tiering-Engine, die CPU, Speicher oder I/O-Bandbreite verbraucht, um Daten zu analysieren und zu verschieben
* **Klare Kostenmodellierung** — Die Speicherkosten lassen sich direkt den bereitgestellten Tiers zuordnen

Um die Tier-Zuordnung eines Workloads zu ändern, muss ein Administrator den VM-virtuellen Datenträger manuell auf ein anderes Tier verschieben. Dies ist eine bewusste operative Entscheidung, kein automatisierter Prozess.

```mermaid
flowchart TB
    subgraph PROVISION["Bereitstellung von VM-Datenträgern"]
        ADMIN["Administrator wählt<br/>bevorzugte Tier-Stufe"] --> TIER{"Tier<br/>verfügbar?"}
        TIER -->|Ja| PLACE["Daten platziert auf<br/>ausgewähltem Tier"]
        TIER -->|Nein| FALLBACK["Nächstverfügbares<br/>Tier ausgewählt"]
        FALLBACK --> PLACE
    end

    subgraph LIFECYCLE["Gesamte Lebensdauer des Datenträgers"]
        PLACE --> STAYS["Daten verbleiben auf<br/>demselben Tier"]
        STAYS --> STAYS
    end

    STAYS -.->|"Nur manuelle Verschiebung<br/>(Administratorentscheidung)"| MOVE["Verschieben auf<br/>anderes Tier"]

    style PROVISION fill:#e3f2fd,stroke:#1565c0
    style LIFECYCLE fill:#e8f5e9,stroke:#2e7d32
    style MOVE fill:#fff3e0,stroke:#e65100
```

## Regeln für die Laufwerkszuordnung

Die korrekte Zuordnung physischer Laufwerke zu Tiers ist für ein gesundes vSAN entscheidend. Befolgen Sie diese Regeln bei der Konfiguration des Speichers:

### Regel 1: Controller-Knoten benötigen Tier 0

Controller-Knoten müssen mindestens ein Tier-0-Laufwerk haben. Tier 0 enthält den vSAN-Dateisystemindex und die gerätebezogenen Zuordnungen pro Tier (Metadaten), die von den Controller-Knoten verwaltet werden. Scale-out- und reine Speicherknoten stellen Workload-Tiers (1–5) bereit, hosten aber kein Tier 0; Tier 0 befindet sich nur auf Controller-Knoten (Knoten 1–2 für N+1, Knoten 1–3 für N+2).

Tier 0 ist **verpflichtend** — dort speichert vSAN seinen Dateisystemindex und seine Gerätezuordnungen, sodass vSAN ohne sie nicht eingebunden oder betrieben werden kann. Deshalb müssen die Controller-Knoten vor der Nutzung eines Workload-Tiers mit Tier-0-Laufwerken ausgestattet sein; ein System hat keinen laufenden „ohne Tier 0“-Zustand, mit dem es umgehen könnte.

### Regel 2: Einheitliche Laufwerke innerhalb eines Tiers

Alle Laufwerke innerhalb eines Tiers sollten **ähnlichen Typs, Kapazität und Leistung**. Wenn Sie einem vorhandenen Tier ein Laufwerk anderer Größe hinzufügen, kann das Tier nur die Kapazität des **kleinsten Laufwerks** im Tier nutzen. Das Mischen von NVMe- und SATA-Laufwerken im selben Tier wird nicht empfohlen.

### Regel 3: Gleiche Laufwerksanzahl über alle Knoten hinweg

Für eine ausgewogene Datenverteilung und optimale Leistung sollte jeder Speicherknoten die **gleiche Anzahl von Laufwerken pro Tier**. Wenn Knoten 1 beispielsweise zwei Tier-2-Laufwerke hat, sollte Knoten 2 ebenfalls zwei Tier-2-Laufwerke desselben Typs und derselben Kapazität haben.

### Regel 4: Verteilung pro Tier über mehrere Knoten

Jedes Tier erstreckt sich über **alle an der Speicherung beteiligten Knoten**. Blockverteilung, Redundanzkopien und I/O-Lastverteilung arbeiten innerhalb jedes Tiers unabhängig voneinander. Das bedeutet:

* Ein Ausfall von Tier-4-Laufwerken beeinträchtigt Tier 1 oder Tier 2 nicht
* Ein Ausfall auf einem Tier beeinflusst die Redundanz auf anderen Tiers nicht — die Redundanz jedes Tiers wird unabhängig verfolgt. Das clusterweite Redundanzniveau (N+1 oder N+2) gilt einheitlich für alle Tiers.
* Kapazität und Leistung skalieren pro Tier unabhängig voneinander

```mermaid
flowchart TB
    subgraph NODE1["Knoten 1"]
        T0_N1["Tier 0<br/>NVMe 400GB"]
        T2_N1["Tier 2<br/>SSD 1.92TB x2"]
        T4_N1["Tier 4<br/>HDD 8TB x4"]
    end
    subgraph NODE2["Knoten 2"]
        T0_N2["Tier 0<br/>NVMe 400GB"]
        T2_N2["Tier 2<br/>SSD 1.92TB x2"]
        T4_N2["Tier 4<br/>HDD 8TB x4"]
    end
    subgraph NODE3["Knoten 3"]
        T0_N3["Tier 0<br/>NVMe 400GB"]
        T2_N3["Tier 2<br/>SSD 1.92TB x2"]
        T4_N3["Tier 4<br/>HDD 8TB x4"]
    end

    T0_N1 <--> T0_N2
    T0_N2 <--> T0_N3
    T2_N1 <--> T2_N2
    T2_N2 <--> T2_N3
    T4_N1 <--> T4_N2
    T4_N2 <--> T4_N3

    style T0_N1 fill:#fff3e0,stroke:#e65100
    style T0_N2 fill:#fff3e0,stroke:#e65100
    style T0_N3 fill:#fff3e0,stroke:#e65100
    style T2_N1 fill:#e3f2fd,stroke:#1565c0
    style T2_N2 fill:#e3f2fd,stroke:#1565c0
    style T2_N3 fill:#e3f2fd,stroke:#1565c0
    style T4_N1 fill:#e8f5e9,stroke:#2e7d32
    style T4_N2 fill:#e8f5e9,stroke:#2e7d32
    style T4_N3 fill:#e8f5e9,stroke:#2e7d32
```

## Speicher skalieren

vSAN unterstützt zwei Skalierungsansätze, und jedes Tier kann unabhängig skaliert werden:

### Vertikale Skalierung (Scale Up)

Fügen Sie vorhandenen Knoten innerhalb eines Tiers weitere Laufwerke hinzu. Dadurch erhöhen sich die Kapazität und der aggregierte Durchsatz dieses Tiers, ohne neue Hardware hinzuzufügen.

**Wichtige Voraussetzungen für die Skalierung nach oben:**

* Stellen Sie sicher, dass vSAN mindestens **30 % freie Kapazität** hat, bevor Sie Laufwerke hinzufügen (es sei denn, Sie verdoppeln die Laufwerksanzahl)
* Neue Laufwerke müssen in Typ, Kapazität und Leistung den vorhandenen Laufwerken im Tier entsprechen
* Fügen Sie die gleiche Anzahl von Laufwerken zu **jedem Speicherknoten** hinzu, um eine ausgewogene Verteilung beizubehalten
* Erstellen Sie vor Beginn des Scale-up-Prozesses einen Systemsnapshot
* Befolgen Sie die [vSAN-Scale-Up-SOP](https://docs.verge.io/product-guide/operations/vsan-scale-up-sop/) für das vollständige Verfahren

### Horizontale Skalierung (Scale Out)

Fügen Sie dem Cluster neue Knoten hinzu. Dadurch erhöhen sich Kapazität, Rechenressourcen und aggregierte I/O-Bandbreite gleichzeitig.

**Wichtige Voraussetzungen für die Skalierung nach außen:**

* Neue Knoten sollten die **gleiche Laufwerkskonfiguration** wie die vorhandenen Knoten für jedes Tier
* Die Netzwerkanbindung (Core Fabric) muss vor dem Hinzufügen des Knotens überprüft werden
* Der neue Knoten wird per USB installiert und tritt dem vorhandenen Cluster bei
* Nach dem Beitritt beginnt vSAN automatisch damit, Daten auf den neuen Knoten zu verteilen
* Befolgen Sie die [vSAN-Scale-Out-Leitfaden](https://docs.verge.io/implementation-guide/scale-out-nodes/) für das vollständige Verfahren

### Entscheidungsmatrix für die Skalierung

| Faktor                       | Scale Up (Laufwerke hinzufügen) | Scale Out (Knoten hinzufügen) |
| ---------------------------- | ------------------------------- | ----------------------------- |
| **Kapazitätszuwachs**        | Nur pro Tier                    | Alle Tiers + Rechenleistung   |
| **Leistungszuwachs**         | Mäßig (mehr Spindeln)           | Erheblich (mehr Knoten)       |
| **Rechenressourcen**         | Keine Änderung                  | Zusätzliche CPU + RAM         |
| **Fehlerdomäne**             | Keine Änderung                  | Bessere Verteilung            |
| **Komplexität**              | Geringer                        | Höher                         |
| **Typischer Anwendungsfall** | Ein Tier läuft knapp            | Mehr Gesamtkapazität benötigt |

## Kapazitätsplanung

Proaktive Kapazitätsplanung verhindert Leistungseinbußen und stellt sicher, dass vSAN innerhalb gesunder Parameter arbeitet.

### Empfohlene Schwellenwerte für freien Speicherplatz

| Tier          | Mindestfreier Speicherplatz | Begründung                                                                         |
| ------------- | --------------------------- | ---------------------------------------------------------------------------------- |
| **Tier 0**    | 30%+                        | Metadaten-Druck wirkt sich systemweit auf alle I/O-Operationen aus                 |
| **Tiers 1–3** | 20–30 %                     | Leistungstiers benötigen Puffer für Deduplizierungsoperationen und Schreibvorgänge |
| **Tiers 4–5** | 15–20 %                     | Kapazitätstiers benötigen Puffer für die Aufbewahrung von Snapshots                |

### Wichtige Metriken zur Überwachung

Verfolgen Sie diese Metriken im VergeOS-Speicher-Dashboard, um einen gesunden Betrieb der Tiers sicherzustellen:

* **Kapazitätsauslastung pro Tier** — Über die Zeit trendmäßig verfolgen, um vorherzusagen, wann Skalierung erforderlich ist
* **I/O-Leistung (IOPS und Latenz)** — Tiers identifizieren, die Workloads möglicherweise ausbremsen
* **Deduplizierungsraten** — Effektive gegenüber rohen Kapazitätseinsparungen pro Tier verstehen
* **Laufwerksfehlerraten** — Frühwarnung vor bevorstehenden Laufwerksausfällen
* **Wiederherstellungsstatus** — Den Self-Healing-Fortschritt nach Laufwerksersetzungen überwachen

### RAM-Anforderungen

vSAN benötigt dedizierten RAM für Speicheroperationen. Planen Sie **1 GB RAM pro 1 TB Rohspeicher** (mindestens) oder **1,5 GB pro 1 TB** (empfohlen) auf jedem Knoten, der am Speicher teilnimmt. Dieser RAM wird vom VergeOS-Host verbraucht und steht VMs nicht zur Verfügung.

## Integration mit Snapshots und Klonen

Speicher-Tiers interagieren auf wichtige Weise mit den Snapshot- und Klonfunktionen von vSAN:

* **Snapshots sind tierbewusst** — Ein Snapshot einer VM mit einem Tier-2-Datenträger verweist auf Blöcke auf Tier 2. Die Snapshot-Metadaten werden auf Tier 0 gespeichert, aber die Datenblöcke bleiben auf ihrem ursprünglichen Tier.
* **Klon verweist auf dasselbe Tier** — Wenn Sie eine VM klonen, verweist der Klon zunächst auf dieselben Datenblöcke auf demselben Tier. Neue Schreibvorgänge des Klons belegen Speicher auf demselben Tier wie das Original.
* **Deduplizierung arbeitet pro Tier** — Die hashbasierte Deduplizierungs-Engine arbeitet über alle Daten innerhalb jedes Tiers hinweg und sorgt so für Speicherersparnisse, die pro Tier getrennt erfasst und gemeldet werden.
* **Replikation ist bandbreitenoptimiert** — Während der Site-Sync-Replikation werden nur eindeutige Blöcke übertragen (unter Berücksichtigung der Deduplizierung), und auf den Übertragungsstrom wird Komprimierung angewendet, um die WAN-Bandbreite zu reduzieren.

{% hint style="info" %}
**Kommen Sie von VMware oder Nutanix?**

VergeOS führt keine automatische Hoch- oder Herabstufung von Blöcken zwischen Tiers durch. Die Platzierung erfolgt bei der Bereitstellung explizit pro VM-Datenträger und bleibt für die gesamte Lebensdauer des Datenträgers bestehen.

VergeOS stellt 5 Workload-Tiers (1–5) plus ein dediziertes Metadaten-Tier (Tier 0) bereit. Kompromiss: vorhersehbare Leistung (keine überraschenden Herabstufungen) bei administrativ gesteuerter Platzierung.
{% endhint %}

## Wichtige Erkenntnisse

| Konzept                        | Zusammenfassung                                                                                                                   |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| **Tier-Modell**                | 5 Workload-Tiers (1–5) plus ein dediziertes Metadaten-Tier (Tier 0); Tiers 1–3 = Leistung (NVMe/SSD); Tiers 4–5 = Kapazität (HDD) |
| **Kein automatisches Tiering** | Daten verbleiben auf dem bereitgestellten Tier — keine Hot/Cold-Migrations-Engine                                                 |
| **Bevorzugte Tier-Stufe**      | Wird pro VM-Datenträger festgelegt; fällt auf das nächstverfügbare Tier zurück, wenn das angeforderte Tier nicht vorhanden ist    |
| **Laufwerksregeln**            | Ähnliche Laufwerke pro Tier, gleiche Anzahl über alle Knoten hinweg, Controller-Knoten benötigen Tier 0                           |
| **Skalierung**                 | Vertikal (Laufwerke hinzufügen) oder horizontal (Knoten hinzufügen) — jedes Tier skaliert unabhängig                              |
| **Kapazitätsplanung**          | 30 %+ frei auf Tier 0, 20–30 % auf Workload-Tiers, 1 GB RAM pro 1 TB Rohspeicher                                                  |
| **Snapshot-Integration**       | Snapshots sind tierbewusst; Deduplizierung arbeitet pro Tier; Replikation ist bandbreitenoptimiert                                |

## Nächste Schritte

Mit dem Verständnis, wie Speicher-Tiers organisiert und verwaltet werden, behandelt das nächste Thema den Zugriff auf Speicher auf Dateiebene: [**NAS-Dienst & Freigaben**](/learn-the-platform/de/modul-5-speicher/03-nas-shares.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/02-storage-tiers.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.
