vSAN Sizing für ESA: von der Roh- zur nutzbaren Kapazität, Speicherrichtlinien, Reserven und Hostanzahl

So berechnen Sie die nutzbare vSAN-Kapazität

Ein vSAN Sizing geht von der nutzbaren Kapazität aus, also der Rohkapazität aller Kapazitätsgeräte im Cluster, abzüglich der Kapazität, die vSAN braucht, um Daten nach einem Hostausfall zu reparieren und interne Vorgänge auszuführen, geteilt durch den Overhead der Speicherrichtlinie. Unter vSAN ESA brauchen RAID-5 2+1 und RAID-6 4+2 das 1,5-Fache der Datenmenge an Rohkapazität, RAID-5 4+1 das 1,25-Fache und Spiegelung das 2- bis 4-Fache. Broadcoms vSAN-Designleitfaden vom 5. Mai 2026 verlangt, dass Kapazität im Umfang eines ganzen Hosts ungenutzt bleibt, damit Komponenten nach einem Ausfall oder während einer Wartung neu aufgebaut werden können.

Als Formel gilt usable = (raw - reserves) / factor, gerechnet in TiB Rohkapazität. Komprimierung und Deduplizierung kommen danach, als Einsparungen, die vSAN meldet, sobald Daten geschrieben sind, und Broadcoms Designleitfaden hält fest, dass sein Richtlinien-Overhead „vor Einsparungen durch Komprimierung und Deduplizierung“ gilt.

Dieser Leitfaden geht von vSAN ESA an einem Standort ohne Fehlerdomänen aus. OSA und seine Regeln für Erasure Coding stehen in unserem Vergleich von vSAN ESA und OSA, und die Spiegelung über zwei Standorte behandelt unser Leitfaden zu vSAN Stretched Clustern.

vSAN-Speicherrichtlinien und Mindestanzahl an Hosts je Richtlinie

Broadcoms Dokumentation zu VCF 9.1 über vSAN-Richtlinien, aktualisiert am 5. Oktober 2026, definiert die zu tolerierenden Fehler (Failures to Tolerate, FTT) als die Anzahl der Host- und Geräteausfälle, die ein Objekt tolerieren kann. Mit Fehlerdomänen braucht vSAN für n Ausfälle 2n+1 davon, und ein Host außerhalb einer Fehlerdomäne zählt als eigene Fehlerdomäne mit nur diesem Host. Spiegelung mit FTT=2 braucht deshalb fünf Hosts und FTT=3 sieben.

Für ESA heißt es auf derselben Seite, vSAN erstelle „ein optimiertes RAID-5-Format auf Basis der Clustergröße“. Unter sechs Hosts verwendet es RAID-5 2+1 und ab sechs Hosts RAID-5 4+1, das für einen Datenträger mit 100 GB 125 GB Rohkapazität belegt. Nach einer Änderung der Hostanzahl passt vSAN das Format nach 24 Stunden an. RAID-6 ist unter ESA ein 4+2-Schema, verteilt auf mindestens sechs Hosts.

Broadcom TechDocs VCF 9.1, What are vSAN Policies (5. Oktober 2026); vSAN-Designleitfaden (5. Mai 2026); vSAN-FAQ (6. Oktober 2026); KB 405876. Hosts mit N+1 ist das Minimum plus ein Host, wie die FAQ empfiehlt; RAID-5 4+1 erstreckt sich über fünf Hosts, deshalb lässt seine Schwelle von sechs Hosts bereits einen Host in Reserve.

Die letzte Spalte folgt Broadcoms vSAN-FAQ vom 6. Oktober 2026, die empfiehlt, „die Hostanzahl eines Clusters um einen zusätzlichen Host über die Anforderungen der verwendeten Speicherrichtlinien hinaus zu dimensionieren“. Ein Cluster mit sechs Hosts kann RAID-6 betreiben, doch nach dem Ausfall eines Hosts gibt es keinen sechsten Host, auf dem die fehlenden Komponenten abgelegt werden können, bis der Host zurückkehrt. Dieselbe Seite, die RAID-1 mit FTT=3 aufführt, sagt, die Option werde „in einem künftigen vSAN-Release als veraltet eingestuft“.

Operations Reserve und Host Rebuild Reserve in vSAN 8 und 9.0

Vor vSAN 7 Update 1, so erinnert der Designleitfaden, wurden für Ausfälle und Wartung typischerweise 25 bis 30 Prozent freie Kapazität (Slack Space) eingeplant; dieses Release brachte dafür zwei optionale Einstellungen. Broadcoms KB 326889 beschreibt die Operations Reserve als Kapazität für vorübergehende Vorgänge wie Richtlinienänderungen und Rebalancing. Die Host Rebuild Reserve wird für die Wiederherstellung nach dem Ausfall eines Hosts vorgehalten.

Der Designleitfaden bemisst die Host Rebuild Reserve unter der Annahme, dass der größte Host im Cluster ausgefallen ist. KB 326889 ergänzt, dass sie mit zusätzlichen Hosts sinkt, da ein Host dann einen kleineren Anteil am Cluster hat. Laut der Dokumentation zu vSAN 8.0 lässt sich die Host Rebuild Reserve erst nach der Operations Reserve aktivieren. Beide brauchen mindestens vier Hosts und stehen auf Stretched Clustern, ROBO-Clustern (zwei Knoten) und Clustern mit Fehlerdomänen nicht zur Verfügung. Für Cluster mit Fehlerdomänen verweist der Designleitfaden auf die ältere Empfehlung, etwa 25 Prozent der Kapazität ungenutzt zu lassen.

KB 326889 legt auch die Schwellenwerte der Integritätsprüfung für die vSAN-Kapazität fest. Sie definiert die Host-Rebuild-Schwelle als Gesamtkapazität abzüglich Operations Reserve und Host Rebuild Reserve. Mit aktivierter Host Rebuild Reserve wird die Prüfung gelb beim niedrigeren Wert aus 70 Prozent der Gesamtkapazität und 80 Prozent dieser Schwelle und rot beim niedrigeren Wert aus 90 Prozent und der Schwelle selbst. Ohne sie wird die Prüfung gelb beim niedrigeren Wert aus 70 Prozent und der Host-Rebuild-Schwelle. Eine Warnung bedeutet laut KB, dass der Cluster nach einem Ausfall möglicherweise nicht genug Kapazität für die Reparatur hat.

Auto-RAID und die Ansicht der effektiven Kapazität in vSAN 9.1

In vSAN für VCF 9.1 wählt Auto-RAID die Richtlinie nach der Clustergröße. Broadcoms Designleitfaden und sein VCF-Blogbeitrag vom 8. Mai 2026 nennen FTT=1 mit RAID-5 auf 3 bis 5 Hosts und FTT=2 mit RAID-6 auf 6 oder mehr, beide mit dem 1,5-Fachen der Objektgröße. Unter drei Hosts verwendet Auto-RAID in einem Cluster an einem Standort FTT=0 mit dem 1,0-Fachen der Objektgröße, was Objekte ohne Redundanz lässt. Die Release Notes zu 9.1, aktualisiert am 8. Oktober 2026, halten fest, dass „vSAN-Cluster RAID-6 als Standard-RAID-Level verwenden“. Laut vSAN-FAQ wird RAID-5 4+1 nicht mehr verwendet, wenn Auto-RAID aktiviert ist.

Laut dem Blogbeitrag ist Auto-RAID auf neuen Clustern standardmäßig aktiviert, während auf 9.1 aktualisierte Cluster ihre bestehenden Speicherrichtlinien behalten und einen Integritätsalarm erhalten, der Auto-RAID empfiehlt. Um in 9.1 eine eigene VM-Speicherrichtlinie anzulegen, müssen Sie laut der TechDocs-Seite zu vSAN-Richtlinien zuerst vSAN ESA Auto-RAID deaktivieren.

Die Ansicht der effektiven Kapazität setzt Auto-RAID voraus. Broadcoms VCF-Blogbeitrag vom 11. Mai 2026 sagt, die Ansicht halte Kapazität für betriebliche Vorgänge und Hostausfälle automatisch zurück, sodass die Reserven nicht mehr von Hand eingestellt werden. Der Designleitfaden bezeichnet die alten Einstellungen Operations Reserve und Host Rebuild Reserve als Legacy und, wenn Auto-RAID verwendet wird, als redundant zu diesen Ansichten. Bereitgestellte Größen erscheinen ohne den Richtlinien-Overhead, sodass eine VM mit 100 GB unter RAID-6 mit etwa 100 GB statt 150 GB angezeigt wird. Cluster ohne Auto-RAID behalten die bisherige Kapazitätsansicht, und für sie gilt der vorige Abschnitt.

Unsere VMware-Optimierung umfasst Versions- und Architektur-Updates für vSAN, mit allen Änderungen in vereinbarten Wartungsfenstern und einem Rollback-Plan für jede Etappe. Nennen Sie uns die vSAN-Cluster, die Sie auf 9.1 aktualisiert haben, und die Speicherrichtlinien, mit denen sie laufen.

Komprimierung und Deduplizierung in der vSAN-Dimensionierung

vSAN ESA bewertet jeden eingehenden 4-KB-Block auf Sektoren mit 512 Byte und kann einen stark komprimierbaren Block auf einem Achtel seiner Größe speichern, laut Broadcoms Whitepaper zur Speichereffizienz vom 11. Mai 2026. Die vSAN-FAQ nennt die Komprimierung „eine opportunistische Funktion zur Speichereffizienz“, und das Whitepaper empfiehlt für Produktivdaten eine konservative Schätzung der Komprimierungsraten. Bereits komprimierte Bild- und Videodateien werden nicht weiter verkleinert. VM-Verschlüsselung in vSphere hebt laut demselben Whitepaper die Einsparungen durch Deduplizierung auf, weshalb es die eigenen Verschlüsselungsdienste von vSAN empfiehlt.

Die Ansicht der effektiven Kapazität in 9.1 prognostiziert laut Broadcoms Blogbeitrag vom 11. Mai 2026 keine ungenutzte Kapazität aus Komprimierung oder Deduplizierung. Einsparungen erscheinen als Verhältniswerte auf Clusterebene, sobald Daten geschrieben sind. Für einen neuen Cluster dimensionieren wir ohne Datenreduktion und behandeln das später gemessene Verhältnis als Spielraum.

Rohkapazität je Host: Laufwerke, TB und TiB

Laufwerkshersteller geben die Kapazität in dezimalen Terabyte an, während vSAN und seine Lizenzen in Tebibyte zu 2^40 Byte rechnen. Ein NVMe-Gerät mit 7,68 TB fasst etwa 6,98 TiB, acht davon ergeben also etwa 55,9 TiB Rohkapazität je Host. Broadcoms KB 394440 ergänzt, dass ein Laufwerk etwas größer sein kann als angegeben, und nennt als Beispiel ein Laufwerk mit 15,36 TB und 13,9707 TiB gegenüber 13,9698 TiB, berechnet aus der Spezifikation.

Der Designleitfaden setzt 1,6 TB als kleinstes Gerät an, das für den Produktivbetrieb mit ESA unterstützt wird, und die vSAN-FAQ erlaubt bis zu 64 Hosts in einem Cluster. Gleiche Hosts halten die Host Rebuild Reserve, die sich nach dem größten Host richtet, einfach planbar. Rohe TiB sind auch die Lizenzmetrik für vSAN, wie unser Leitfaden zur VMware-Lizenzierung nach der Übernahme durch Broadcom erklärt.

vSAN ReadyNode Sizer und Broadcoms Sizing-Tools

Broadcoms Designleitfaden vom 5. Mai 2026 legt nahe, jede vSAN-Dimensionierung über das vSAN Sizing Tool zu führen, das er mit „wird im Sommer 2026 abgekündigt“ beschreibt, und nennt den VCF Private Cloud Sizer, damals in der Beta, als Nachfolger. Für Speicherschätzungen empfiehlt er den vSAN ReadyNode Sizer und sagt, „der vSAN Sizer berücksichtigt den Overhead für Dateisystem, Metadaten und Prüfsummen“. Die vSAN-FAQ vom 6. Oktober 2026 sagt, die Dimensionierung sei „in der Vergangenheit über den vSAN ReadyNode Sizer erfolgt“, und nennt Live Optics und RVTools, um eine bestehende Umgebung zu erfassen. Mit Stand Oktober 2026 haben wir kein Broadcom-Dokument gefunden, das sagt, welches Tool das vSAN Sizing Tool ersetzt hat.

Jeder Sizer braucht dieselben Eingaben, und sie stammen aus der bestehenden Umgebung: die belegte Kapazität je VM statt der bereitgestellten, das Wachstum über den Planungshorizont, die Speicherrichtlinie und die Hostkonfiguration. Die Prognose dieses Wachstums ist Thema unseres Leitfadens zur Kapazitätsplanung für vSphere.

Rechenbeispiele für 6, 12 und 24 Hosts

Die Beispiele unten stammen von uns, gerechnet nach den von Broadcom veröffentlichten Regeln. Jeder Host hat acht NVMe-TLC-Geräte mit 7,68 TB, also 55,9 TiB Rohkapazität, und der Cluster läuft mit vSAN 9.1 und Auto-RAID. Die Obergrenze von 70 Prozent für die Rohbelegung ist unsere eigene Planungsregel, keine Empfehlung von Broadcom. Wir setzen sie auf den höchsten Punkt, an dem die Integritätsprüfung aus KB 326889 gelb werden kann. In allen drei Clustern lässt sie mehr als die Kapazität eines Hosts ungenutzt, und Komprimierung wird nicht mitgerechnet. Unter vSAN 8 oder 9.0 mit aktivierter Host Rebuild Reserve warnt ein Cluster mit sechs Hosts früher, bei etwa 67 Prozent oder weniger, weil diese Reserve allein ein Sechstel der Kapazität ausmacht.

Unsere Rechnung und unsere Planungsregel von 70 Prozent auf Grundlage von Broadcoms Designleitfaden (5. Mai 2026), TechDocs VCF 9.1 zu vSAN-Richtlinien (5. Oktober 2026), KB 326889 und KB 394440; gekennzeichnetes Beispiel, vor dem Overhead für Dateisystem und Metadaten.

Der Cluster mit sechs Hosts erfüllt das Minimum für RAID-6, aber nicht den empfohlenen siebten Host, deshalb laufen seine Objekte nach einem Hostausfall mit einem tolerierten Ausfall weniger, bis der Host zurück ist. Die eigene Richtlinie mit RAID-5 4+1 auf zwölf Hosts hält etwa 60 TiB mehr VM-Daten als RAID-6, bei FTT=1 statt FTT=2, und setzt voraus, dass Auto-RAID zuerst deaktiviert wird. Bei 24 Hosts ist ein Host etwa 4 Prozent des Clusters, sodass der Plan mit 70 Prozent weit mehr zurückhält, als ein Rebuild braucht.

Geht man stattdessen vom Bedarf aus, kommen 1.000 VMs mit durchschnittlich 250 GiB belegtem Speicher auf etwa 244 TiB Daten. Die Schritte sind folgende:

1. Entnehmen Sie die belegte Kapazität je VM und ihr Wachstum über den Planungshorizont dem aktuellen Cluster oder einem Assessment-Tool.
2. Multiplizieren Sie mit dem Richtlinienfaktor für die geplante Hostanzahl, 1,5 für Auto-RAID unter ESA, das ergibt 366 TiB.
3. Teilen Sie durch die geplante Rohbelegung, 0,7 nach unserer Planungsregel, das ergibt 523 TiB.
4. Teilen Sie durch die rohen TiB je Host und runden Sie auf, hier auf 10 Hosts, und prüfen Sie das Ergebnis dann gegen das Minimum der Richtlinie plus einen Host.
5. Rechnen Sie Komprimierung und Deduplizierung erst als Spielraum ein, wenn der Cluster ein gemessenes Verhältnis meldet.

Zehn Hosts dieser Dichte laufen unter Auto-RAID mit RAID-6 und enthalten den zusätzlichen Host, den Broadcom empfiehlt. Dichtere Hosts senken die Hostanzahl, mit den Auswirkungen auf lizenzierte Kerne, die unser Leitfaden zur Host-Konsolidierung zeigt, während der Anteil jedes Hosts an der Rebuild-Reserve wächst.

Unsere VMware-Optimierung umfasst ein Audit der Umgebung mit ihrer tatsächlichen Ressourcennutzung, und Eurokommerz liefert die Hardware zur Lösung. Schicken Sie uns die Hosts, Laufwerke und belegte Kapazität jedes vSAN-Clusters über das Formular unten, mit dem Wachstum, das Sie planen.

Was wir tun

Im Rahmen der VMware-Optimierung auditiert unser Engineering-Partner Vixen.UNO Ihre VMware-Umgebung und Lizenzen und modernisiert vSphere, vSAN, NSX und VCF. Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, mit EU-Rechnungsstellung, Lieferung und Garantie nach europäischem Recht. Änderungen, clusterübergreifende Migrationen eingeschlossen, laufen in vereinbarten Wartungsfenstern mit einem Rollback-Plan für jede Etappe, gefolgt von Support unter einem vereinbarten SLA. Das erste Gespräch ist kostenlos; der Preis des technischen Assessments mit Bericht, TCO- und ROI-Modell und Maßnahmenplan vor der Verlängerung steht vor Beginn fest.

FAQ