Virtual Volumes

Eine weitere, immer wieder angekündigte und mit vSphere 6 offenbar endlich eingeführte Neuerung hört auf den Namen Virtual Volumes (VVOL). Hierbei handelt es sich um eine Technologie, die Software-Defined Storage in SAN- und NAS-Arrays erlaubt. Das Feature zeigt virtuelle Festplatten an, als handele es sich um native Storage-Objekte, und ermöglicht detaillierte Array-gestützte Operationen auf der Ebene virtueller Festplatten. Allerdings wird das Feature Virtual Volumes unter Fachleuten seit Langem durchaus auch kontrovers diskutiert.

vMotion im WAN

Neben Virtual Volumes besteht die wichtigste Neuerung von vSphere 6 in einer Funktionserweiterung für vMotion, das künftig über die Grenzen von vCentern hinaus funktionieren soll.

Das Verschieben von Workloads im laufenden Betrieb auf einen anderen Host gehört vom Prinzip her zu den Key Features aller virtuellen Infrastrukturen. Die ersten Implementationen von VMware und Microsoft wiesen allerdings noch Einschränkungen auf, die von den Herstellern erst nach und nach von Version zu Version gelockert werden konnten. So bestand eine der anfänglichen Voraussetzungen darin, dass das Verschieben von laufenden VMs stets einen Cluster und Shared Storage voraussetzte. Erst mit vSphere 5.1 hat VMware Enhanced vMotion eingeführt, das einen Umzug von VMs zwischen zwei Host mit dem Feature Storage vMotion kombinierte. Microsoft hatte zu diesem Zweck mit Hyper-V 2012 die Funktion Shared Nothing Live Migration eingeführt.

Die bislang größte Einschränkung im Zusammenhang mit vMotion bestand allerdings darin, dass vMotion/Storage vMotion beziehungsweise Enhanced vMotion nur innerhalb der vorgegebenen Verwaltungseinheiten einer vSphere-Umgebung möglich war, also beispielsweise innerhalb eines Datacenters, das heißt zwischen im gleichen vCenter-Server verwalteten Hosts. Die Einschränkung betrifft im Wesentlichen große Unternehmen, die mehrere Rechenzentren betreiben, oder den Einsatz in hybriden Cloud-Umgebungen. Mit vSphere 6.0 soll auch diese Einschränkung wegfallen, sodass sich VMs künftig auch über die Grenzen von Datencentern und vCentern hinweg verschieben lassen. Neu ist zudem, dass vMotion nicht mehr nur zwischen Hosts arbeitet, die am selben Distributed vSwitch hängen.

Fault Tolerance für SMP

Ebenfalls neu ist, dass sich VMwares HA-Implementation Fault Tolerance (FT) ab vSphere 6 nicht mehr auf VMs mit einer vCPU beschränkt. Auch dieses Feature wurde von VMware schon mehrfach angekündigt. FT geht über das HA-Feature in einem vSphere-Cluster hinaus.

Nutzer in Deutschland verstehen unter Hochverfügbarkeit in der Regel nämlich etwas anderes als das, was die US-Hersteller unter diesem Feature anbieten, also etwa den HA-Cluster bei vSphere. Geht es um das unterbrechungsfreie Ausführen von VMs, ist VMware FT das "härtere" Feature. Der Unterschied ist bedeutsam: Bei FT läuft auf einem Secondary Server die VM synchronisiert mit, belegt dort also aktiv Ressourcen. Bei einem Ausfall des primären Servers wird die VM unterbrechungsfrei vom Secondary übernommen. Bei HA wird die VM auf einem anderen Server neu gestartet, was einige Minuten dauern kann, bis der Dienst wieder verfügbar ist. Dafür ist die Maschine aber in einem crash-konsistenten Zustand. Daher erfordert FT das absolut synchrone Ausführen der gesicherten VM, damit diese bei einem Ausfall ohne Downtime sofort einspringen kann.

Allerdings ist das synchrone Ausführen von VMs mit mehreren vCPUs eine komplexe Angelegenheit. Für vSphere 6 setzt VMware dazu jetzt mit Fast Check-Pointing auf ein anderes technisches Verfahren. Dieses schützt VMs mit bis zu vier vCPUs. Insgesamt erlaubt VMware FT maximal acht vCPUs pro Host, wobei zuerst die Limitierung greift, die als Erste erreicht ist.