Die herkömmliche Topologie eines virtualisierten Rechenzentrums sieht einen zentralen Storage vor, auf den mehrere Hosts zugreifen, die selbst nur Betriebssystem-Festplatten beinhalten oder gar von USB-Sticks oder vom zentralen SAN-Storage booten. Je nach Budget und Bedeutung verfügt der zentrale Storage über eine eingebaute Redundanz oder sogar Georedundanz. Marktübliche Serversysteme, die meistens als Virtualisierungs-Hosts dienen, haben jedoch den lokalen Festplattenspeicher nach wie vor fest in ihrem Design verankert. In den frühen Jahren der Virtualisierung kamen häufig Server als Virtualisierungs-Hosts zum Einsatz, die ursprünglich für einen anderen Zweck angeschafft worden waren und über große lokale Festplatten-Arrays verfügten.

Aus diesen Umständen ist bereits früh im Virtualisierungszeitalter die Idee entstanden, lokale Festplatten der Hosts als Storage für die VMs zu nutzen, ohne auf die Mobilität und Hochverfügbarkeit der VMs verzichten zu müssen. Die ersten Versuche wie die vSphere-Storage-Appliance von VMware oder die Virtual-Storage-Appliance von HP gingen in die gleiche Richtung: Auf jedem Host lief eine Storage-VM, deren Festplatten in den lokalen Datastores lagen. Die VMs bildeten einen Cluster und glichen die Festplatteninhalte über das Netzwerk ab. Der resultierende Speicherpool wurde an die Hosts mit Standardprotokollen wie iSCSI oder NFS zurückpräsentiert.

Die ersten Gehversuche zeigten allerdings schnell, dass der hohe Protokoll-Overhead und die meist eigenständige, vom Hypervisor entkoppelte Verwaltung der virtuellen Storage-Appliances die erhofften Vorteile wieder zunichtemachen. Um dem Konzept zum Erfolg zu verhelfen, mussten der Storage und der Hypervisor also enger zusammenrücken. Das hyperkonvergente Storage- und Virtualisierungscluster war geboren.

In hyperkonvergenten Storage-Konfigurationen werden die in den Hosts verbauten Festplatten nicht durch mehrere Schichten vom Hypervisor abstrahiert, nur damit am Ende Protokolle wie iSCSI diese zurückspielen müssen. Vielmehr bilden die Softwarekomponenten und Treiber, die für die Verwaltung der Festplatten und die Replikation der Daten zwischen den Hosts verantwortlich sind, eine dünne Schicht innerhalb des Hypervisors selbst. Die Bereitstellung der so entstehenden Festplatten-Volumes an die Hosts erfolgt ebenfalls auf einem tieferen Level als bei den herkömmlichen Konstrukten, die ein externes SAN oder NAS emuliert haben.

VMware hat mit der vSphere-Version 5.5 Update 1 erstmalig unter dem Namen "vSAN" einen echten hyperkonvergenten Storage aus eigenem Haus vorgestellt. Somit ist die Technologie bereits über sieben Jahre alt. Es sind sowohl All-Flash-Konfigurationen als auch Mischkonfigurationen aus magnetischen Festplatten (HDDs) und SSD- oder NVMe-Laufwerken möglich. In solchen Konstellationen übernehmen die HDDs die "Capacity"-Schicht, also die permanente Datenspeicherung. Die schnelleren Flash-Laufwerke dienen als "Performance"-Schicht, die sowohl die Lese- als auch die Schreiboperationen puffert und beschleunigt. Im All-Flash-Betrieb muss ebenfalls zwingend ein Cache bereitstehen; in diesem Fall handelt es sich jedoch ausschließlich um einen Schreib-Cache. Diese Unterschiede zu kennen, hilft Ihnen, die optimalen Laufwerke für Ihren hyperkonvergenten Storage auszuwählen.

Das Aktivieren der vSAN-Funktionalität erfolgt pro Compute-Cluster. Ist das vSAN konfiguriert und sind die in den Hosts verbauten Festplatten für den vSAN-Betrieb beansprucht, so erscheint bei allen Hosts im Cluster ein neuer Datenspeicher namens "vsanDatastore", der die zu Festplattengruppen zusammengefassten lokalen Festplatten der Hosts aggregiert darstellt. Der vordefinierte Name lässt sich nachträglich ändern. Die Art der Anbindung dieses Datenspeichers an ESXi-Hosts entspricht keinem der herkömmlichen Typen wie Fibre Channel, iSCSI oder NFS. Allerdings kann dieser Speicher ganz oder teilweise blockbasiert über iSCSI oder filebasiert über NFS beziehungsweise SMB anderen Systemen zur Verfügung gestellt werden.

Microsofts "Storage Spaces Direct" (S2D) [1] veredelt ebenfalls einen Server-Cluster mit der Funktion, lokal in den Clusterknoten verbaute Festplatten als zentralen hochverfügbaren Storage dem ganzen Cluster zur Verfügung zu stellen. Allerdings sieht die Einbettung in die Produktpalette der Microsoft-Serverwelt etwas anders als bei vSAN aus. Der S2D-Storage ist nicht ausschließlich der Virtualisierung vorbehalten, sondern steht dem Cluster für beliebige Rollen zur Verfügung. Beispielsweise ist ein hochverfügbares iSCSI-Target auf dieser Basis möglich. Die beiden häufigsten Einsatzszenarien für S2D sind jedoch:

- Hyperkonvergente Virtualisierung: Das Cluster führt Hyper-V-VMs aus, deren Dateien auf S2D-Volumes liegen.

- Scale Out File Server (SOFS): Der S2D-Cluster führt eine oder mehrere SOFS-Rollen aus, womit Teile des S2D-Storage in Form hochverfügbarer Applikations-Dateifreigaben über SMB3 bereitstehen. In diesen Freigaben können Dateien der Hyper-V-VMs oder SQL-Datenbanken liegen. Die SOFS-Funktion stellt sicher, dass der SMB-Zugriff auf alle Clusterknoten verteilt ist und bei Ausfall eines der Knoten nicht unterbrochen wird.

Im Umgang mit den physischen Datenträgern unterscheidet Microsoft zwischen HDD, SSD, NVMe und Persistent Memory und erlaubt im S2D-Speicher bis zu drei Tiers: Capacity, Performance und Cache. Wie bei vSAN ist der Cache in All-Flash-Konfigurationen (SSD oder SSD + NVMe) ein reiner Schreibcache und in Hybridkonfigurationen (HDD + SSD oder HDD + SSD + NVMe) ein Schreib- und Lesecache. Bei einer Drei-Tier-Architektur verschiebt S2D automatisch die "heißen" Blöcke, auf die häufig zugegriffen wird, in den Performance-Tier und die "kalten" Blöcke, auf die eher selten zugegriffen wird, in den Capacity-Tier.

S2D ist verfügbar mit Windows Server 2016, 2019 und mit Azure Stack HCI, wo S2D die Basis der hyperkonvergenten Storage-Bereitstellung bildet. Beide Umgebungen sind sehr anspruchsvoll in der Verwaltung ihrer physischen Datenträger und erwarten einen direkten Zugriff auf die jeweiligen Festplatten. RAID-Laufwerke oder gar externer SAN-Storage werden nicht unterstützt. Sowohl VMware als auch Microsoft pflegen für ihre hyperkonvergenten Systeme separate Hardware-Kompatibilitätslisten, die Serversysteme, Host Bus Adapter (HBA), externe Festplatten-Enclosures und nicht zuletzt Festplattenmodelle umfassen. Beide Umgebungen erwarten separate 10 GBit/s oder schnellere Netzwerkadapter für den Storage-Datenverkehr. Microsofts S2D setzte bereits früh auf RDMA zur radikalen Reduzierung des Protokoll-Overheads im Netzwerk. Bei VMware hat es etwas länger gedauert – erst die aktuelle Version 7.0 U2 kann von RDMA-fähigen Netzwerkadaptern und Switches profitieren.

Ein vSAN-Cluster untersützt bis zu 64 Knoten. Jeder dieser ESXi-Hosts kann über höchstens fünf Diskgruppen mit maximal sieben Capacity-Datenträgern (HDD oder SSD) verfügen. In einem Cluster lassen sich also maximal 2240 Festplatten zusammenfassen. Gehen wir von einer gängigen 2-TByte-SSD im Capacity-Tier aus, ergibt sich ein Brutto-Speicherplatz von rund 4,5 Petabyte, den ein solcher hyperkonvergenter Speicher bereitzustellen vermag. Allerdings muss dafür jeder Host über 40 Festplatten-Steckplätze zuzüglich des Boot-Laufwerks verfügen. Nicht unerheblich ist auch der Arbeitsspeicherbedarf eines vSAN-Clusters. Im gerade geschilderten Vollausbau müssen Sie pro Host über 80 GByte RAM allein für den vSAN-Betrieb einplanen [2], sogar ohne Berücksichtigung fortgeschrittener Features wie Komprimierung und Deduplizierung.

Bei Microsofts S2D ist die Anzahl der Festplatten pro Server nicht beschränkt. Allerdings ist ein S2D-befähigter Cluster auf "nur" 16 Knoten limitiert, wovon jeder maximal 400 TByte an Brutto-Festplattenspeicher im Capacity-Tier beisteuern kann. Die maximale Gesamtkapazität des S2D-Pools beträgt bei Windows Server 2019 und Azure Stack HCI 4 Petabyte, womit bei gleichmäßiger Verteilung jeder Clusterknoten mit 250 TByte dabei ist. In der Annahme der 2-TByte-Einzellaufwerke sind dies stolze 125 Festplatten allein im Capacity-Tier. Auch hier ist das Boot-Laufwerk nicht mitgerechnet. Ohne externe Festplatten-Enclosures ist ein solcher Maximalausbau mit herkömmlichen Servern also nicht zu schaffen. Die Anforderungen an Server und Festplatten für S2D finden Sie unter [3] zusammengefasst.

Der zusätzliche Arbeitsspeicherbedarf von S2D lässt sich nicht so genau beziffern wie bei vSAN. Die einzige fixe Größe sind 4 GByte RAM pro TByte Cache. Wenn Sie also mit 15 Prozent Cache-Tier planen und Ihr Capacity-Tier bei den maximal möglichen 250 TByte liegt, brauchen Sie allein für die S2D-Metadaten bereits 150 GByte RAM pro Host. Steht noch mehr RAM für das Storage-Subsystem zur Verfügung, können Sie einen gewissen Teil davon als CSV-Cache verwenden. Diese Technik ist nicht S2D-spezifisch, sondern steht Ihnen auch bei Cluster Shared Volumes zur Verfügung, die Sie aus einem herkömmlichen SAN bereitstellen.

Software-defined Storage ist ein sehr interessanter und zukunftsfähiger Design-ansatz für Enterprise-Rechenzentren. Nicht weniger interessant ist er allerdings für die kleinstmöglichen Einsatzszenarien wie abgesetzte Standorte, für die sich in letzter Zeit der Begriff ROBO (Remote Office Branch Office) durchgesetzt hat, obwohl es sich dabei häufig um Produktionsstätten und nicht um Büros handelt. Diese Standorte benötigen nur in einem begrenzten Maß Compute- und Storage-Leistung und verfügen so gut wie nie über qualifiziertes IT-Personal vor Ort zur Wartung der Serverinfrastruktur. Begrenzt sind hier in der Regel auch die Möglichkeiten, Server und Storage sicher unterzubringen und mit Strom und Kühlung zu versorgen. Das macht die Vorstellung, mit zwei oder drei Servern und lokalen Festplatten eine hochverfügbare lokale Plattform zu schaffen, sehr attraktiv.

Doch auch innerhalb eines großen Datacenters gibt es Einsatzmöglichkeiten für einen kleinen autonomen Cluster. Die häufigsten Szenarien sind Management-Cluster, die von den verwalteten Systemen unabhängig sein sollen, oder DMZ-Cluster, bei denen oft die Anforderung der vollständigen Netzwerktrennung vom produktiven LAN formuliert wird. VMware kommt diesen Anforderungen mit Zwei-Knoten-Clustern entgegen. Es sind sogar Konstellationen möglich, in denen die beiden Cluster-Knoten ohne 10-GBit-Switche auskommen, sondern mit direkten Kabelverbindungen vernetzt sind (Direct Connect). Um die Cluster-Funktionen zu gewährleisten, muss neben den zwei ESXi-Knoten noch ein Zeugenserver (vSAN-Witness) bereitstehen. Dabei handelt es sich um einen ESXi-Host, der keine VMs ausführt, sich dafür aber selbst als VM betreiben lässt. Ein solcher Zeugenserver sollte nach Möglichkeit in einem anderen Brandabschnitt oder sogar an einem anderen Standort platziert sein.

Auch Microsofts S2D unterstützt die Bereitstellungen mit zwei Knoten, ebenfalls mit der zusätzlichen Anforderung, einen Zeugen bereitzustellen. Der Zeuge kann eine SAN-LUN oder eine Fileserver-Freigabe sein. Die Unterstützung von "Direct Connect" gilt bei Microsoft sogar für beliebige Cluster-Größen. Die einzige Bedingung hierfür ist, dass zwischen je zwei Knoten eine Verbindung bestehen muss, was bei größeren Clustern zu extrem vielen 10-GBit-Netzwerkkarten pro Host führt und daher weder wirtschaftlich noch praktikabel ist.

Sind die lokalen Festplatten der Hosts zu einem Cluster-weiten Datastore oder Storage-Pool zusammengefasst, gilt es, die virtuellen Festplatten und sonstigen Dateien der VMs möglichst effizient in diesem Speicher unterzubringen. Dabei müssen einerseits genug Kopien vorhanden sein, um den Ausfall sowohl einer Festplatte als auch eines ganzen Hosts zu kompensieren. Andererseits muss der Festplattenplatz und der Netzwerkverkehr zwischen den Hosts auf das notwendige Minimum reduziert werden. VMware und Microsoft verfolgen hier leicht unterschiedliche Ansätze.

VMware setzt bei vSAN auf das "Storage Policy-based Management" (SPBM). Jedes gespeicherte Objekt (das kann eine VM oder eine einzelne Datei sein) ist dabei einer Storage-Richtlinie zugeordnet. Diese Richtlinie regelt, wie viele Kopien der Daten im vSAN-Speicher platziert sind, um die gewünschte Ausfallsicherheit zu erreichen. Dabei wird, wie bei einem herkömmlichen RAID, zwischen vollständigen Kopien (RAID 1) und "erasure coding" (RAID 5 oder 6) unterschieden.

Um die Topologie Ihres Rechenzentrums in Bezug auf mögliche Ausfälle genau abzubilden, bedient sich vSAN der "Fehlerdomänen" (Fault Domains [4]). Eine Fehlerdomäne kann einem Blade Enclosure oder einem ganzen Server-Rack entsprechen. Auf diese Weise werden die Daten im vSAN so verteilt, dass der Ausfall einer ganzen Fehlerdomäne tolerierbar ist – zum Beispiel, wenn ein ganzes Blade Enclosure ausfallen sollte. Bei der Definition von Fehlerdomänen müssen Sie beachten, dass Sie mindestens 2 * N + 1 Fehlerdomänen im Cluster brauchen, um den Ausfall von N Kopien zu verkraften. Genügt Ihnen die Absicherung gegen den Ausfall einer Kopie, sind drei Fehlerdomänen ausreichend. Möchten Sie Ihre VMs gegen den Ausfall von zwei Kopien absichern, müssen Sie bereits fünf Fehlerdomänen vorhalten. Ist Ihr Cluster auf vier Racks verteilt, ist ein Rack eine zu grobe Unterteilung. Im einfachsten Fall bildet jeder ESXi-Host im Cluster eine eigene Fehlerdomäne.

Bei Microsofts S2D existieren ebenfalls mehrere Ebenen des Ausfallschutzes, jedoch beziehen sie sich nicht auf einzelne Dateien oder VMs, sondern auf Volumes, die Sie aus dem S2D-Pool bereitstellen. Die möglichen Redundanz-Algorithmen beinhalten einfache und doppelte Spiegelung, einfache und doppelte Parität (RAID5 beziehungsweise 6), gespiegelte Parität sowie eine proprietäre Technik namens "Local Reconstruction Codes" (LRC), die höchstmögliche Storage-Effizienz bei guter Performance verspricht.

S2D bedient sich der Fehlerdomänen auf die gleiche Weise wie vSAN. Das Einrichten dieser Domänen erfolgt mithilfe der PowerShell und gestaltet sich für visuell veranlagte Administratoren nicht ganz intuitiv. Allerdings läuft die Verwaltung der Fehlerdomänen etwas granularer ab als bei VMware. Jede Domäne gehört den Typen "Node", "Chassis", "Rack" oder "Site" an, zwischen denen eine Eltern-Kind-Hierarchie besteht. So können Sie den physischen Aufbau Ihres Rechenzentrums präzise abbilden, um die höchstmögliche Ausfallsicherheit zu gewährleisten.

Zusätzlich zu der Storage-Effizienz der verschiedenen RAID-Stufen lohnt es sich oft, durch Komprimierung und Deduplizierung die Menge des tatsächlich beanspruchten physischen Festplattenspeichers zu verringern. VMware bietet diese Funktionalität nur in All-Flash-Konfigurationen an. Storage Spaces Direct hingegen greift auf das Komprimierungs-Feature zurück, das seit Windows Server 2012 an Bord ist. Aus Betriebssicht stellt sich diese Funktionalität etwas unterschiedlich dar: Das Komprimieren im vSAN ist ein kontinuierlicher Prozess, der ständig mitläuft und für einen etwas höheren CPU- und RAM-Verbrauch der ESXi-Hosts sorgt. Die Windows-Server-Komprimierung findet in Form von diskreten Aufgaben statt, sodass sich das Ergebnis der Komprimierung im Laufe der Zeit ständig verbessert. Die engere Integration der Deduplizierung und Komprimierung bei vSAN bedingt eine Neuformatierung aller physischen Datenträger im vSAN-Cluster. Bei einem nachträglichen Aktivieren der Speichereffizienz in einem bereits gefüllten Cluster müssen Sie also in Kauf nehmen, dass die Leistung des Clusters für eine längere Zeit beeinträchtigt wird und der Netzwerktraffic durch vSAN erheblich ansteigt.

Oft sind Verbindungen zwischen Rechenzentrumsstandorten deutlich langsamer und mit höheren Latenzen behaftet als innerhalb der Standorte selbst. Soll ein hochverfügbares Storage-, Compute- oder Anwendungskonstrukt über mehrere Standorte ausgedehnt werden, so ist von einem "Stretched Cluster" die Rede. vSAN unterstützt dies als möglichen Betriebsmodus. Dafür muss ein Zeugenhost bereitstehen, der sich idealerweise in einem zusätzlichen Standort befindet. Die Latenz, verstanden als Round Trip Time (RTT), zwischen den produktiven Standorten und dem Zeugenstandort, darf 200 ms nicht überschreiten. Sind an jedem Standort höchstens zehn vSAN-Hosts Teil des "Stretched Cluster", ist zwischen den Standorten auch eine Latenz von 200 ms möglich. Ist das Cluster größer, müssen Sie jedoch eine Latenz von maximal 100 ms sicherstellen.

Storage Spaces Direct setzt keine harten Grenzen für die Latenzen zwischen den einzelnen Servern. Vielmehr beziehen sich die Systemanforderungen auf Bandbreiten und die entsprechend niedrige Latenz wird stillschweigend vorausgesetzt. Somit ist der Betrieb eines S2D-Clusters über latenzbehaftete Verbindungen hinweg nicht möglich. Azure Stack HCI bietet dennoch einen Ansatz namens "Stretched Cluster" an. Allerdings handelt es sich dabei um ein Disaster-Recovery-Szenario, in dem zwei S2D-Cluster ihre Volumes mittels Storage Replica synchron oder asynchron replizieren. Es ist jedoch nicht möglich, eine VM im Standort A zu starten, deren Daten im Standort B gespeichert sind.

Unterschiedlich sind auch die Lösungsansätze von VMware und Microsoft bei der Bereitstellung des hyperkonvergenten Storage an Systeme, die selbst nicht mit ihren lokalen Festplatten zum Storage-Pool beitragen. In einem vSphere-Cluster mit vSAN-Funktionalität können einzelne Knoten unterschiedlich viel Storage zu vSAN beitragen, oder auch gar keinen. Trotzdem haben alle Hosts des Clusters Zugriff auf den vSAN-Datenspeicher dieses Clusters. Hosts außerhalb des Clusters können nur vom vSAN profitieren, indem sie den vSAN-Storage per iSCSI oder NFS einbinden. Seit vSAN 7.0 Update 1 besteht im Rahmen von "HCI Mesh" außerdem die Möglichkeit, vSAN-Datenspeicher Cluster-übergreifend zu nutzen.

An einem S2D-Cluster können nur Hosts teilnehmen, die selbst mit ihren lokalen Festplatten zum Storage-Pool beitragen. Die "Disk-Symmetrie", also möglichst identische Konfiguration der lokalen Festplatten-Subsysteme auf allen Hosts im Cluster, ist ein wichtiger Garant für die Performance und Stabilität des Gesamtkonstrukts. Ein hyperkonvergentes Cluster ist also in sich selbst eingeschlossen. Wenn Sie den S2D-Storage jedoch per SMB3 als Scale-Out-Fileserver in Ihrem Netzwerk freigeben, sind der Nutzung dieses Speichers durch beliebige Hyper-V-Hosts und -Cluster sowie SQL-Server und -Cluster keine technischen oder lizenzrechtlichen Grenzen gesetzt.

Die enge Integration von vSAN in den ESXi-Hypervisor setzt sich bei der Verwaltung und Überwachung des hyperkon­vergenten Storage nahtlos fort. Alle Funktionen sind über die Weboberfläche des vSphere-Clients administrierbar – ab vSAN 6.7 im HTML5-Client, in den früheren Versionen war die Verwaltung von vSAN dem Flash-Client vorbehalten. Im Webinterface finden Sie sowohl die Einstellmöglichkeiten als auch Performance-Graphen und Links zu Diagnose- und Reparaturfunktionen. Auch beim Wartungsmodus wird die Mitgliedschaft des Hosts in einem vSAN-Cluster berücksichtigt: Sie können auswählen, welche Teile der vSAN-Daten Sie auf andere Hosts verlagern möchten, bevor Sie den zu wartenden Host außer Betrieb nehmen.

Microsofts hyperkonvergente Virtualisierung lässt sich am einfachsten mithilfe des Windows Admin Center [5] verwalten. Dieses zeigt Inventur- und Zustandsdaten über Cluster, Hosts, virtuelle Maschinen, aber auch über physische Disks, Speicherpools und Volumes in einer Weboberfläche an. Von hier aus können Sie auch grundlegende Verwaltungsaufgaben starten und sogar einige Funktionen ausführen, die Ihnen mit Bordmitteln von Windows Server nicht zur Verfügung stehen, wie zum Beispiel das Klonen virtueller Maschinen.

Das Cluster Aware Updating (CAU), Microsofts Orchestrierungsdienst zum Patchen von Hyper-V-Clustern, beherrscht auch hyperkonvergente Cluster mit S2D. Allerdings müssen Sie hier etwas nachhelfen und den folgenden PowerShell-Befehl als Post-Update-Skript in Ihre CAU-Konfiguration einfügen:

Dies stellt sicher, dass der S2D-Speicher im Cluster wieder synchronisiert ist, bevor CAU den Host aus dem Wartungsmodus nimmt und mit dem nächsten Host fortfährt. Den Befehl müssen Sie als PowerShell-Skript verpackt in einem Pfad ablegen, auf den alle Hosts im Cluster Zugriff haben, beispielsweise im S2D-Speicher unter "C:\ClusterStorage".

Microsofts Antwort auf die Frage nach der Lizenzierung seines hyperkonvergenten Speichers ist maximal einfach: Alle Knoten, die Storage zum S2D-Cluster beitragen, müssen vollständig für Windows Server Datacenter 2016 oder 2019 lizenziert sein und auch diese Edition der Serversoftware ausführen. Alle Systeme und Benutzer, die über SMB3 auf den bereitgestellten Storage zugreifen, müssen über eine Windows-Server-CAL mindestens in der eingesetzten Version verfügen. Dient ein Windows-System als Cluster Witness, muss es regulär lizenziert sein.

In einem rein hyperkonvergenten Szenario (alle Hyper-V-Hosts im Cluster tragen zum S2D-Storage bei) gibt es den Storage-Teil also praktisch zum Nulltarif, sofern die Datacenter-Lizenzierung bereits für die im Cluster laufenden Server-VMs erforderlich ist. Eine andere Lizenzierungs- und Bereitstellungsoption für Storage Spaces Direct ist der "Azure Stack HCI" [6]. Damit erhalten Sie zu einem Mietpreis von derzeit monatlich 9 Euro pro CPU-Kern eine hyperkonvergente Umgebung von Microsoft, die Sie auf Ihrer eigenen, für Azure Stack HCI zertifizierten Hardware ausführen können. Die Abrechnung erfolgt über Ihre Azure-Subscription.

VMware-vSphere-Kunden, die von den Vorteilen von vSAN profitieren möchten, müssen sich sowohl mit der komplexen Lizenzierung auseinandersetzen als auch ordentlich in die Tasche greifen. Wie bei vielen VMware-Produkten üblich, steht vSAN in den vier Lizenzstufen "Standard", "Advanced", "Enterprise" und "Enterprise Plus" bereit. Das "Plus" in der höchsten Lizenzstufe machen jedoch keine vSAN-spezifischen Funktionen aus, sondern eine mit vSAN gebündelte Lizenz für vRealize Operations Advanced. Der Sprung von der "Standard"- zur "Advanced"-Edition wertet Ihr vSAN mit Deduplizierung und Komprimierung sowie RAID5/6-Funktionalität auf. "Enterprise" bringt High-End-Features wie Datenverschlüsselung, File Services und Stretched Cluster mit.

Für den Einsatz von vSAN ist es nicht erforderlich, eine bestimmte Mindestausbaustufe von vSphere lizenziert zu haben – auch vSphere Standard mit vCenter sowie Foundation-Pakete sind unterstützt, nicht jedoch der kostenlose ESXi-Hypervisor. Die "kleineren" vSphere-Editionen werden sogar durch vSAN aufgewertet, denn jede vSAN-Lizenz beinhaltet die Features "Distributed Switch" und "Policy Based Storage Management", die bei vSphere der Enterprise-Plus-Edition vorbehalten sind. Ein ESXi-Host, der als reiner vSAN-Zeuge fungiert, benötigt keine Lizenz, wenn er als VM läuft – die vSAN-Zeugen-Appliance beinhaltet bereits eine entsprechende Lizenz. Möchten Sie den Zeugen hingegen physisch bereitstellen, müssen Sie ihn regulär als ESXi-Host lizenzieren.

Für ROBO-Szenarien hat vSAN einen zusätzlichen Lizenztyp, der dem ROBO-Licensing für vSphere folgt. Lizenziert werden dabei virtuelle Maschinen, die im abgesetzten Standort laufen. Ein ROBO-Standort darf maximal 25 VMs ausführen. Die Anzahl der Hosts, auf denen diese VMs laufen, spielt für die Lizenzierung der VMware-Komponenten keine Rolle. Einen tabellarischen Vergleich aller Editionen und Features finden Sie unter [7]. VMware-Kunden, die ihre Lizenzen über die Serverhersteller oder im Rahmen anderer Verträge beziehen, müssen beim Kauf der vSAN-Lizenzen abschließend darauf achten, dass sie die Lizenzschlüssel aus mehreren Bestellungen im VMware-Kundenportal zusammenführen können. Die Zuweisung von vSAN-Lizenzen erfolgt pro Cluster, und einem Cluster lässt sich nur ein Lizenzschlüssel zuweisen. Dieser muss dann sämtliche CPUs des Clusters abdecken.

Microsofts S2D und VMwares vSAN folgen dem gleichen Grundkonzept, setzen dieses jedoch auf etwas unterschiedliche Weise um. Die Eigenarten der jeweiligen Produkte wurzeln in ihrer Entwicklungsgeschichte und sorgen dafür, dass erfahrene Microsoft- oder VMware-Administratoren sich schnell in ihrer hyperkonvergenten Umgebung zurechtfinden. Die Lizenzierung der beiden Technologien gestaltet sich einerseits sehr unterschiedlich, andererseits jedoch im Rahmen der bekannten Strategie des jeweiligen Herstellers. Beide Systeme sind inzwischen ausgereift und finden sowohl in selbst installierten und betriebenen Umgebungen als auch in schlüsselfertigen Konstrukten wie vxRail (VMware) oder Azure Stack HCI (Microsoft) Anwendung.