Immer wenn Updates auf pro­duktiv ge­nutzten Clustern mit Storage Spaces Direct ein­gespielt werden müssen, ver­setzt man einen Kno­ten nach dem anderen in den War­tungs­modus. Das kann manu­ell oder auto­matisiert per Cluster-Aware Updating passieren. Dabei migrieren VMs unterbrechungsfrei auf andere Cluster-Knoten.

Die VMware-Mitarbeiter Cormac Hogan und Duncan Epping, beide be­kannte Blogger zu Themen der Virtua­lisierung, haben vor einiger Zeit ein über 300 Seiten starkes Buch über Virtual SAN 6.2 veröffent­licht. Dieses steht nun als kosten­loses E-Book zum Down­load bereit, eine Regi­strierung ist nicht nötig.

VM Fleet kann Storage Spaces Direct Cluster mit simu­lierten Work­loads unter Last setzen. Es bringt dafür mehrere Skripte mit und baut auf Diskspd, um dann innerhalb von auto­matisch generierten VMs Arbeits­last zu erzeugen. Dieser Bei­trag zeigt, wie eine Umgebung für VM Fleet vorbe­reitet wird und Tests konfiguriert werden.

Hinter Star­Winds "Virtual SAN - Hybrid Cloud for Azure" ver­birgt sich ein Soft­ware - defined Storage, welches sich über das lokale Rechen­zen­trum hinaus in die Public Cloud er­streckt. Ein Failover von VMs kann hier nach Azure erfolgen, VSAN deckt zudem ein Disaster Recovery ab.*

Remote Direct Memory Access (RDMA) ist die empfohlene Techno­logie für Storage Spaces Direct und generell, um schnelle Netzwerk­daten­transfers mit geringen Latenzen zu er­zielen. Hyper-V 1709 erlaubt erst­mals, RDMA auch in VMs zu nutzen. Micro­soft gibt in seinen Guide­lines Empfehlungen zu den RDMA-Techniken.

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.