Es ist zwar bekannt, dass die in Windows Server 2016 enthal­tenen Storage Spaces Direct (S2D) zerti­fizierte Hard­ware erfordern. Allerdings reicht es nicht, wenn Kompo­nenten nur für Windows Server zuge­lassen sind. Und selbst wenn sie der Hersteller für S2D getestet hat, ergibt sich daraus nicht immer ein brauch­bares System.

Microsoft hatte im 1. Halbjahr 2017 ange­kündigt, Windows as a Service auf das Server-OS auszu­dehnen und Features-Updates zwei Mal pro Jahr auszu­liefern. Mit Server 1709 liegt nun das erste dieser Releases vor. Es bringt einige neue Features, aber auch mehrere Einschränkungen.

Bei Virtual Volumes (VVOLs) sind die ver­füg­baren Storage-Policies viel­seitiger als in vSAN, dafür aber her­steller­abhängig. Daher muss man sie zuerst mit der Soft­ware des Anbieters auf der Storage-Seite definieren, bevor man sie im Regel-Editor von vSphere ein­binden kann.

Die mit vSphere 6.0 einge­führten Virtual Volumes (VVOLs) sind ein Frame­work zur Integration und zum Management von SAN- und NAS-Speicher. Es automa­tisiert die Zutei­lung von Speicher zu ein­zelnen VMs auf Basis von Policies und erlaubt so eine feinere Kontrolle von Storage-Ressourcen.

VMware Virtual SAN und Virtual Volumes (VVOLs) setzen ein richt­linien­basiertes Speicher-Management um. Admins können mit seiner Hilfe dafür sorgen, dass ein VM-Objekt stets auf einem Data­store zu liegen kommt, dessen Eigen­schaften mit den Policies über­ein­stimmen, die sie an die VM ange­hängt haben.

Storage Spaces Direct (S2D) fasst die Laufwerke von Cluster-Knoten zu einem hoch­ver­fügbaren Pool zu­sammen. Bevor man dieses Storage bil­det, sollte man die zuläs­sigen Lauf­werks­typen für den Fest- und Zwischen­speicher ver­gleichen sowie die resul­tierende Kapa­zität berechnen.

VMware vSphere kann seit der Version 6.5 virtu­elle Maschinen auf dem Daten­speicher ("Encyp­tion at rest") und beim Ver­schieben mit vMotion ver­schlüsseln. Die Beson­derheit dieses Features besteht darin, dass es auf Hypervisor-Ebene arbeitet und damit unab­hängig vom Gast­betriebs­system ist.

Eine besondere Form des 2-Knoten-Clusters bei VMware vSAN ist der mit Version 6.1 einge­führte Stretched Cluster ("Ausge­weiterter Cluster"). Ein solcher Storage-Ver­bund erstreckt sich typi­scher­weise über zwei Unter­nehmens­stand­orte und benötigt eben­falls die Witness-Appliance. Aus­fall­zeiten lassen sich zusätzlich durch Fehler­domänen redu­zieren.

Muss ein ESXi-Host in den Wartungs­modus, etwa für einen Reboot nach dem Ein­spielen von Patches, dann sind die Aus­wir­kungen bei einem vSAN-Cluster größer als wenn der Host nur Teil eines DRS- bzw. HA-Clusters wäre. Der Storage-Verbund muss nämlich die Inte­grität der Daten weiterhin garan­tieren. VMware sieht für diese Situation mehrere Optionen vor.

Auf Speicher­systemen, die VMwares vStorage APIs for Storage Aware­ness (VASA) unter­stützen, kann vSphere die Work­loads mit Hilfe von Policies weit­gehend auto­matisch auf einem passenden Data­store platzieren. Aber auch ein manu­elles Ver­fahren mit Tags hilft dabei, die Nutzung von Storage zu optimieren.