vSAN ESA vs OSA: Hardware-Anforderungen, Datendienste, Lizenzierung in 9.x und der Wechsel zu ESA

vSAN ESA vs OSA, Merkmal für Merkmal

vSAN Express Storage Architecture (ESA), eingeführt mit vSAN 8, ist ein Single-Tier-Design: Die NVMe-Geräte eines Hosts bilden einen Speicherpool, und jedes Gerät trägt Kapazität und Leistung bei. vSAN Original Storage Architecture (OSA) baut Datenträgergruppen auf, jede mit einem Flash-Cache-Gerät vor Kapazitätsgeräten, als All-Flash- oder Hybridkonfiguration. Broadcoms vSAN-Designleitfaden zu 9.1 (5. Mai 2026) empfiehlt ESA für neue Cluster ab vSAN 9 und behält All-Flash-OSA „für die Erweiterung von Brownfield-Clustern“ bei. Für beide gilt dieselbe Lizenz, gezählt auf der Rohkapazität, die vSAN beansprucht, und ein OSA-Cluster lässt sich nicht an Ort und Stelle in ESA umwandeln.

Broadcom TechDocs zu vSAN 8.0, VCF 9.0 und 9.1 (August bis Oktober 2026), Handbücher zu vSAN 8.0 Update 3 (Juli 2024), vSAN-Designleitfaden (5. Mai 2026), Whitepaper zur Speichereffizienz (11. Mai 2026), VCF-Blog (7. Mai 2026), vSAN-FAQ (30. September 2026).

OSA-Datenträgergruppen und Cache-Ebene vs ESA-Speicherpool

In OSA verbindet jede Datenträgergruppe ein Flash-Cache-Gerät mit einem bis sieben Kapazitätsgeräten, und ein Host kann bis zu fünf Datenträgergruppen haben. In All-Flash-Konfigurationen „verwendet vSAN die Cache-Schicht nur für das Schreib-Caching“, so das Planungshandbuch zu vSAN 8.0 Update 3, und fällt ein Cache-Gerät aus oder wird es entfernt, stellt vSAN die Komponenten der gesamten Datenträgergruppe wieder her. Seit vSAN 8.0 kann der Schreibpuffer auf Cache-Geräten mit 1,6 TB oder mehr bis zu 1,6 TB erreichen, statt zuvor 600 GB (KB 326411).

ESA hat weder Datenträgergruppen noch eine Cache-Ebene. Schreibvorgänge gehen zuerst in ein gespiegeltes Log im log-strukturierten Dateisystem (vSAN LFS), das später große vollständige Stripes als RAID-5 oder RAID-6 schreibt, ohne Read-Modify-Write für die Parität, wie VMwares Produktblog im September 2022 erklärte. Komprimierung, Verschlüsselung und Prüfsummen laufen weit oben im Storage-Stack, sodass die nachfolgende Verarbeitung und das Netzwerk mit komprimierten Daten arbeiten, laut Broadcoms Whitepaper zur Speichereffizienz. Für Snapshots nutzt OSA das System SparseSE, das laut Broadcoms Designleitfaden „beim Löschen eines Snapshots I/O für das Zusammenführen erfordert“, während in ESA ein Basisdatenträger und seine Snapshots ein einziges vSAN-Objekt bilden.

Hardware-Anforderungen für vSAN ESA und ReadyNode-Profile

Die vSAN-Anforderungen für VCF 9.1, aktualisiert am 5. Oktober 2026, verlangen von einem ESA-Host mindestens ein NVMe-TLC-Gerät und 128 GB Arbeitsspeicher. Für das Netzwerk legen sie „mindestens 10 GbE, empfohlen 25 GbE oder höher“ fest. Jedes Kapazitätsgerät, jeder Treiber und jede Firmware-Version muss im vSAN-Teil des Broadcom Compatibility Guide gelistet sein. Das Planungshandbuch zu 8.0 Update 3 vom Juli 2024 hatte vier NVMe-Geräte, 512 GB und 25 GbE verlangt. Broadcoms aktuelle Seiten zu vSAN 8.0 und VCF 9.0, aktualisiert im August und September 2026, setzen dieselbe Untergrenze wie 9.1. Oberhalb dieser Untergrenze dimensioniert Broadcom ESA-Hosts nach ReadyNode-Profil, und sein Designleitfaden verlangt 100 Gbit/s für Hosts mit 200 TB oder mehr.

Broadcoms vSAN-Designleitfaden zu 9.1 (5. Mai 2026), Werte je Host; vSAN-HCI-SM hieß früher ESA-0.

Die Hosts sind ESA ReadyNodes, unter einer SKU gekauft, oder Konfigurationen vom Typ ReadyNode Emulated, „mit derselben OEM-Serverhardware aufgebaut“, wie es in Broadcoms FAQ heißt. KB 326717 erlaubt Änderungen innerhalb bestimmter Regeln: Laufwerke aus der Stückliste des ESA ReadyNode, ein anderes Laufwerksmodell nur vom selben Server-OEM, mindestens 1,6 TB und 1 DWPD je Gerät; außerdem rät die KB davon ab, Laufwerke unterschiedlicher Schreibfestigkeit zu mischen. SAS- und SATA-Geräte werden mit ESA nicht unterstützt, und Broadcoms FAQ erklärt, dass ReadyNodes mit Intel-Prozessoren, die älter als Ice Lake sind, eine ältere PCIe-Generation und zu wenige PCIe-Lanes haben. Ob ein Host überhaupt ESX 9 ausführt, steht in unserem Leitfaden zu den Hardware-Anforderungen für ESX 9.

Komprimierung, Deduplizierung und Erasure Coding in OSA und ESA

OSA dedupliziert und komprimiert nur auf All-Flash-Datenträgergruppen, clusterweit eingestellt und je Datenträgergruppe angewandt, während die reine Komprimierung (Compression-only) je Datenträger arbeitet (Administrationshandbuch zu 8.0 Update 3). ESA komprimiert je Objekt, und Broadcoms Whitepaper zur Speichereffizienz vom 11. Mai 2026 beschreibt die Komprimierung in 9.1 als clusterbasierte Funktion, die „standardmäßig aktiviert“ ist und „in der Benutzeroberfläche nicht deaktiviert werden kann“. Die globale Deduplizierung, für ESA in 9.0 ein Limited Release, ist ab 9.1 allgemein verfügbar. Sie läuft nachgelagert (Post-Process) und clusterweit, auf vSAN-HCI- und Storage-Clustern mit 3 bis 64 Hosts und vorerst nicht auf Stretched Clustern oder Zwei-Knoten-Clustern.

OSA betreibt RAID-5 ab vier Fehlerdomänen und RAID-6 ab sechs, nur auf All-Flash, sodass ein OSA-Cluster mit drei Hosts nur spiegeln kann. ESA legt RAID-5 auf weniger als sechs Hosts als 2+1 an und ab sechs Hosts als 4+1. Mit Auto-RAID in 9.1 kommt RAID-5 nur auf 3 bis 5 Hosts zum Einsatz, immer als 2+1. Cluster mit sechs oder mehr Hosts erhalten RAID-6 4+2. Die Faktoren unten geben die Rohkapazität je Einheit VM-Daten an, vor Komprimierung und Deduplizierung.

Administrationsdokumentation zu vSAN 8.0 (133 GB für ein Objekt mit 100 GB bei RAID 5 und FTT=1); vSAN-Designleitfaden (5. Mai 2026); Whitepaper zur Speichereffizienz (11. Mai 2026).

vSAN 9.0 und 9.1: OSA-Support, veraltetes Hybrid-OSA und Storage-Cluster

Auf die Frage, ob OSA wegfällt, antwortet Broadcoms vSAN-FAQ vom 30. September 2026 mit „Nein, nicht in absehbarer Zukunft“ und ergänzt, dass hybrides OSA in den Release Notes zu VCF 9.0 als veraltet eingestuft wurde und All-Flash-OSA-Cluster weiterhin unterstützt werden.

vSAN-Storage-Cluster, früher vSAN Max genannt, sind ESA-Cluster, die anderen Clustern Speicher bereitstellen. Broadcoms Leitlinien vom 5. Mai 2026 verlangen für einen Storage-Cluster an einem einzigen Standort mindestens 4 Hosts, mit mindestens 25 GbE zwischen ihnen. Clients können ESA-HCI-Cluster, reine Compute-Cluster oder, ab 9.1, OSA-Cluster sein, und sie können den Datastore bereits mit 10 GbE mounten. Stretched Cluster samt Witness behandelt unser Leitfaden zu vSAN Stretched Clustern.

vSAN-Lizenzierung in 9.x: TiB je Kern und Add-on-Kapazität

Für OSA und ESA gleichermaßen geben Broadcoms Programmdokumentationen vom Juni 2026 jedem VVF-Kern Anspruch auf 0,25 TiB vSAN-Kapazität und jedem VCF-Kern auf 1 TiB, und jedes Kontingent „kann nur über Kerne hinweg aggregiert und genutzt werden“, die zum eigenen Produkt gehören. KB 313548, „Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN“, rundet den VVF-Wert auf das nächste TiB auf. Darüber hinaus wird das vSAN-Add-on je TiB verkauft; seine Programmdokumentation vom Mai 2026 legt fest, was zählt: „Der Kunde muss den gesamten rohen physischen Speicher lizenzieren, der von der Software auf allen Servern im vSAN-Cluster beansprucht wird.“ Ein Broadcom-Dokument, das die Cache-Geräte von OSA-Datenträgergruppen von dieser Zählung ausnimmt, haben wir nicht gefunden.

In 9.0 weisen Sie laut den Release Notes, aktualisiert am 29. September 2026, die Lizenz VMware vSAN in VCF Operations einer vCenter-Instanz zu, nach deren VCF- oder VVF-Lizenz, und jeder vSAN-Cluster in diesem vCenter ist dann lizenziert. Nach der Lizenzdokumentation zu 9.1 vom 1. Oktober 2026 werden Komponenten, die einer lizenzierten vCenter-Instanz hinzugefügt werden, „automatisch lizenziert“, und vSAN-Kapazität aus VCF, VVF und Add-ons wird in einer Default-Lizenz gepoolt. In Broadcoms Beispiel ergeben 300 VCF-Kerne und ein Add-on mit 50 TiB zusammen eine vSAN-Lizenz mit 350 TiB. Wie dieser Pool zur Regel je Produkt passt, erklärt unser Vergleich von VVF und VCF; das Skript aus der KB, das die rohen TiB je Cluster ausgibt, behandelt unser Leitfaden zur Kernzählung.

Für die Lizenzierung unterscheiden sich ESA und OSA in der Rohkapazität, die dieselben Daten brauchen. Nehmen Sie drei Hosts mit je zwei 16-Kern-CPUs, nach den Regeln aus unserem Leitfaden zur VMware-Lizenzierung 96 lizenzierte Kerne. Sie bringen unter VVF 24 TiB vSAN mit und unter VCF 96 TiB. Um 30 TiB VM-Daten bei FTT=1 zu halten, braucht OSA mindestens 60 TiB Rohkapazität, weil es auf drei Hosts nur spiegeln kann. ESA mit RAID-5 2+1 braucht 45 TiB, in beiden Fällen vor Reservekapazität und Datenreduktion. Unter VVF sind das mindestens 36 TiB Add-on-Kapazität für OSA und 21 TiB für ESA; unter VCF braucht keine der beiden Varianten ein Add-on. Die Rechnung stammt von uns, auf Grundlage der von Broadcom veröffentlichten Regeln. Auf vier oder fünf Hosts kehrt sich das Ergebnis um, da RAID-5 unter OSA das 1,33-Fache der Datenmenge braucht, gegenüber dem 1,5-Fachen bei 2+1 unter ESA; ab sechs Hosts, bei FTT=2, brauchen beide das 1,5-Fache.

Unsere VMware-Optimierung umfasst ein Audit der Umgebung und ihrer Lizenzen, sodass Sie die Zahlen sehen, bevor Sie die Verlängerung unterschreiben. Schicken Sie uns die Rohkapazität jedes vSAN-Clusters über das Formular unten, mit den für VVF oder VCF lizenzierten Kernen.

Migration von vSAN OSA zu ESA

Eine Umwandlung an Ort und Stelle gibt es nicht. Laut Broadcoms KB 405623 lässt sich ein OSA-Cluster weder mit dem vSphere Client noch mit der Ruby vSphere Console auf ESA upgraden. KB 432894, gültig für vSAN 8.0 bis 9.1, nennt den Grund: OSA und ESA „verwenden grundlegend verschiedene On-Disk-Formate und Datenpfade“. Ein Upgrade an Ort und Stelle auf vSAN 8 belässt einen Cluster auf OSA, ergänzt Broadcoms FAQ.

KB 432894 beschreibt zwei Wege. Beim Side-by-Side-Weg bauen Sie einen neuen ESA-Cluster auf Hardware auf, die für ESA gelistet ist, verschieben die VMs mit Storage vMotion und nehmen den OSA-Cluster außer Betrieb, sobald alle Workloads migriert und geprüft sind. Die alten Hosts können danach als reiner Compute-Cluster weiterlaufen; Broadcoms Designleitfaden nennt diese Verwendung für „ältere Hardware, die möglicherweise nicht für vSAN oder VSAN ESA geeignet ist“. Bis der OSA-Cluster außer Betrieb genommen ist, beansprucht vSAN die Rohkapazität beider Cluster, und die Programmdokumentation zu vSAN verlangt, dass sie vollständig lizenziert wird. Auf dem zweiten Weg bauen Sie die vorhandenen Hosts, soweit sie die ESA-Anforderungen oben erfüllen, in dieser Reihenfolge um:

1. Migrieren Sie alle VMs mit vMotion auf einen anderen Cluster und Datastore.
2. Versetzen Sie jeden Host mit der Option No Data Migration in den Wartungsmodus.
3. Löschen Sie die OSA-Datenträgergruppen und bereinigen Sie jedes Gerät von seinen bisherigen Partitionen und Metadaten.
4. Verschieben Sie den Host auf die Rechenzentrumsebene des vCenter-Inventars, dann in den ESA-Cluster, und beanspruchen Sie seine Geräte für den ESA-Speicherpool.

Seit 9.1 kann ein OSA-Cluster außerdem den Datastore eines ESA-Storage-Clusters oder ESA-HCI-Clusters mounten, sodass neuer VM-Speicher auf ESA liegen kann, während die OSA-Hosts weiter Rechenleistung bereitstellen.

Clusterübergreifende Migrationen in vereinbarten Wartungsfenstern, mit einem Rollback-Plan für jede Etappe, gehören zu unserer VMware-Optimierung. Beschreiben Sie Ihre OSA-Cluster im Formular unten, mit Hosts, Gerätemodellen und vSAN-Version.

Wann Sie OSA behalten und wann Sie ESA planen

Nach unserer Lesart von Broadcoms Dokumenten kann All-Flash-OSA auf Hosts mit SAS- oder SATA-Geräten oder mit Intel-Prozessoren vor Ice Lake bleiben, bis die Hardware ersetzt wird, da ESA diese Hosts in ihrem jetzigen Zustand nicht nutzen kann und OSA unterstützt bleibt. Auch solche Hosts brauchen ein unterstütztes ESX-Release, und Broadcoms KB 318697 führt Broadwell-Xeons für 9.x als eingestellt und Cascade Lake als veraltet. Hybride Cluster kommen im Plan zuerst an die Reihe, da hybrides OSA als veraltet eingestuft ist. Der Zeitpunkt für den Wechsel ist eine Hardware-Erneuerung, weil Broadcom ESA für neue Cluster empfiehlt und Cluster mit drei Hosts RAID-5 statt Spiegelung erhalten.

Was wir tun

Eurokommerz hält den Vertrag und liefert die Hardware zur Lösung, mit EU-Rechnungsstellung, Lieferung und Garantie nach europäischem Recht; die technische Umsetzung übernimmt unser Engineering-Partner Vixen.UNO. Im Rahmen der VMware-Optimierung auditiert Vixen.UNO die Umgebung und ihre Lizenzen, stimmt Editionen und Abonnements innerhalb der aktuellen Broadcom-Lizenzlogik auf Ihre realen Workloads ab und modernisiert vSphere, vSAN, NSX und VCF, clusterübergreifende Migrationen eingeschlossen. Änderungen 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