Neu in VMware vSphere 6.0: Long-Distance-vMotion, FT für 4 vCPUs, Zertifikatsverwaltung

Sowohl VMware als auch Microsoft lockerten diese Restriktionen in den letzten Releases ihrer Systeme. Hyper-V 2012 führte zu diesem Zweck die so genannte Shared Nothing Live Migration ein und VMware zog in vSphere 5.1 mit Enhanced vMotion nach, das den Umzug von VMs zwischen 2 Hosts mit Storage vMotion kombiniert.

Dennoch gelten bisher noch einige Einschränkungen für vMotion, die sich primär bei großen Unternehmen mit mehreren Rechenzentren und in hybriden Cloud-Umgebungen bemerkbar machen. Dazu gehört, dass die Migration nur innerhalb der wesentlichen Management-Einheiten von vSphere möglich ist, nämlich innerhalb eines Datacenter oder zwischen Hosts, die vom gleichen vCenter-Server verwaltet werden.

VM-Migration zwischen vCenter und Netzwerken

In vSphere 6.0 fallen nun auch diese Limitierungen, so dass VMs mit Hilfe von vMotion über die Grenzen von Datencentern und vCenter verschoben werden können. Darüber hinaus lockert VMware auch die Bedingungen auf Seiten des Netzwerks, wodurch vMotion nicht mehr bloß zwischen Hosts funktioniert, die an einen gemeinsamen Distributed vSwitch angebunden sind.

Schließlich kann die VM-Migration zwischen verschiedenen Subnets erfolgen ("Routed vMotion") und funktioniert auch in Netzwerken mit höheren Latenzzeiten. Bis dato lag die Obergrenze für akzeptierte Round Trip Times (RTT) bei 10 ms, künftig erhöht sich dieser Wert auf 100 ms.

Verschiedenen Anwendungen für Long Distance vMotion

Mit diesen Änderungen sind die Voraussetzungen für die Migration von VMs über größere Entfernungen (Long Distance vMotion) geschaffen, weil Workloads damit nicht nur zwischen Compute- und Storage-Ressourcen umziehen können, sondern auch in der Lage sind, das Netzwerk und die administrative Domäne zu wechseln.

Typische Anwendungen für Long Distance vMotion wären die Vorbeugung gegen Desaster bzw. das Testen von DR-Lösungen, ein Load-Balancing zwischen mehreren Rechenzentren oder die dynamische Auslagerung von Workloads zu einem Cloud-Provider.

Fault Tolerance für vSMP

Einen großen Fortschritt meldet VMware bei Fault Tolerance (FT). Dieses Feature ist schon seit einigen Version in vSphere präsent, war aber bis dato auf VMs mit nur einer vCPU beschränkt. Die Erweiterung der Ausfallsicherheit auf Virtual SMP wurde vom Hersteller schon mehrmals angekündigt, aber dann immer wieder verschoben.

Anders als bei HA, wo die betroffenen VMs nach dem Ausfall eines Hosts auf einem anderen neu gestartet werden, erfordert FT die Ausführung der abgesicherten VMs im exakten Gleichschritt. Denn wenn ein Server etwa aufgrund eines Hardwaredefekts nicht mehr verfügbar ist, muss der andere ohne Downtime einspringen können.

Die synchrone Ausführung von VMs mit mehreren vCPUs ist eine komplexe Aufgabe, für die VMware nun ein anderes technisches Verfahren namens Fast Check-Pointing gewählt hat. Es schützt VMs mit bis zu 4 vCPUs, und insgesamt lässt FT pro Host maximal 8 vCPUs zu. Es greift also jenes Limit, das zuerst erreicht wird.

Das Update von FT bringt nicht nur die Unterstützung von vSMP, sondern beseitigt auch weitere bisher existente Beschränkungen. Dazu gehört vor allem, dass primäre und sekundäre VM nicht mehr den gleichen Datastore verwenden müssen, so dass Fault Tolerance zusätzlich Schutz gegen den Ausfall eines Storage-Systems bieten kann. Es entfällt selbst die Notwendigkeit für Shared Storage, denn die VMDKs und die Konfigurationsdateien lassen sich auch auf lokalen Platten speichern. Nur der Tiebreaker muss auf einem gemeinsam genutzten Speichersystem liegen.

Trotz dieser Fortschritte bleiben vSMP-VMs, die durch FT geschützt werden, weiterhin einige Features von vSphere vorenthalten. Das gilt etwa für Storage vMotion, vSAN, Virtual Volumes oder Virtual Flash Read Cache. Außerdem unterstützt eine für FT konfigurierte VM kein Hot-add von vRAM und kein Hot-Plug von vCPUs. Dafür können in der Version 6.0 nun aber Snapshots erzeugt werden.

Neue Zertifikatsverwaltung

vSphere 6.0 verbessert nicht nur einige vorhandene Features, sondern führt mit Platform Services Controller (PSC) ein neues Modul ein. Dieses fasst wesentliche Basisfunktionen für den Betrieb des Systems zusammen. Dort findet sich das in der Version 5.5 weitergehend neu entwickelte SSO, das unter anderem der Anbindung von vCenter an das Active Directory dient. Hinzu kommen eine zentrale Verwaltung der verschiedenen VMware-Lizenzen sowie die Registrierung der Produkte.

Den wohl wichtigsten Fortschritt bringt PSC beim Management von Zertifikaten, das bis dato inkonsistent und mit viel Handarbeit verbunden war. Zu seinem Lieferumfang gehört eine Certificate Authority (CA) inklusive Certificate Store, die selbst Root-Zertifikate ausstellen oder Zertifikate anderer CAs verwalten kann. Diese VMware Certificate Authority stellt für jeden ESXi-Host ein Zertifikat bereit, wenn er zu vCenter hinzugefügt wird. Die gesamte Verwaltung der Zertifikate erfolgt über den vSphere Web Client.

PSC lässt sich entweder auf einem vCenter-Server installieren oder als externe Komponente betreiben. Die interne Version empfiehlt VMware bei vSphere-Installationen mit bis zu 8 vCenters. PSC nutzt eine eigene vPostgres-Datenbank und kann deren Inhalte zwischen mehreren Instanzen des Moduls replizieren.

Content Library repliziert Ressourcen zwischen vCenters

Ein weiteres neues Feature stellt die Content Library dar, in der Administratoren verschiedene Ressourcen ablegen, verwalten und zwischen vCenter-Instanzen replizieren können. Dazu gehören Templates von virtuellen Maschinen, ISO-Abbilder, Scripts oder vApps.

Die wesentliche Aufgabe der Library besteht darin, die von ihr verwalteten Ressourcen über die gesamte vSphere-Infrastruktur hinweg konsistent zu halten. So können Admins damit beispielsweise sicherstellen, dass alle neuen VMs mit Windows Server 2012 auf der gleichen Schablone beruhen und somit einheitlich konfiguriert sind.

Als Speicherort für den Content sieht die Library entweder einen vSphere-Datastore oder das lokale Dateisystem eines vCenter-Servers vor, wobei man auf Letzterem die Daten komprimiert ablegen kann. Das Feature enthält in seiner ersten Inkarnation eine einfache Versionsverwaltung.

Virtuelle Datencenter

VMware bietet für das Gruppieren virtualisierter Ressourcen eine Reihe von logischen Konstrukten an, darunter Datacenter, Ressource Pools und Ordner. In vSphere 6.0 kommt eine weitere Einheit hinzu, nämlich das Virtual Datacenter. Dieses aggregiert ESXi-Cluster, Storage, Netzwerke und dazu gehörende Policies eines einzelnen vCenter-Servers.

Das virtuelle Datencenter kümmert sich automatisch um die anfängliche Platzierung einer VM auf einem der enthaltenen Cluster, abhängig von deren Kapazität und Fähigkeiten. Aus diesem Grund muss DRS auf allen Clustern aktiviert sein, wenn man diese Funktion eines virtuellen Datacenters in Anspruch nehmen möchte.

Mit Hilfe von Policies lässt sich festlegen, wo eine VM platziert wird und welche Speichersysteme sie nutzen kann. Eine Anwendung dafür bestünde etwa darin, aus Lizenzgründen Host Affinity Rules für bestimmte Programme durchzusetzen, so dass sie innerhalb eines Clusters immer nur auf bestimmten Hosts ausgeführt werden.

Insgesamt helfen virtuelle Datencenter dabei, die kompletten virtualisierten Ressourcen eines Rechenzentrums zu partitionieren. Diese Einheiten kann man dann beispielsweise bestimmten Abteilungen des Unternehmens zuordnen und ihnen abhängig von den Anforderungen jeweils eigene Policies zuteilen. Dieses Konzept erinnert an eine Kernfunktion von vCloud Director, den VMware seit einiger Zeit primär für Service-Provider und nicht mehr für Enterprise-Kunden positioniert.

Kurze Wiederbelebung für den vSphere Client

VMware hat sich vor geraumer Zeit strategisch auf den vSphere Web Client als Management-Frontend festgelegt. Neue Funktionen der Plattform lassen sich nur mehr mit seiner Hilfe verwalten, während der Funktionsumfang des nativen Windows-Clients (auch als C#-Client bezeichnet) mit der Version 5.1 eingefroren wurde.

Problematisch an dieser Entscheidung ist einerseits, dass der Web Client nicht alle Funktionen des alten Tools beherrscht und so zu einem gewissen Grad ein Nebeneinander der beiden Werkzeuge erforderlich ist.

Entgegen der ursprünglichen Absicht liefert VMware den vSphere Client für Windows auch noch mit vSphere 6.0 aus. Dieser war zuletzt nicht mehr in der Lage, VMs zu verwalten, die auf der aktuellen vHardware 10 beruhen. Dieses Manko beseitigt der Hersteller in der voraussichtlich letzten Version des Tools, so dass es sich auch wieder als Management-Werkzeug für den kostenlosen ESXi-Hypervisor eignen wird.

Diese lebensverlängernde Maßnahme kam offenbar auf Druck vieler Kunden zustande, die den C#-Client noch nicht zugunsten der Web-Konsole aufgeben möchten. Ein Grund dafür könnte in der mäßigen Performance des Web-Clients bestehen. Diese soll laut VMware in Version 6.0 deutlich verbessert werden, wobei das Tool weiterhin auf Adobe Flash basiert und eine HTML5-Ausführung derzeit nicht in Sicht ist.