Virtualisieren mit vSphere, Hyper-V und KVM

Funktional bieten alle drei Kandidaten wie VMware vSphere, Microsoft Hyper-V und Red Hat Enterprise Virtualization beispielsweise hinsichtlich der Maximalwerte von VMs pro Node/Cluster, Anzahl vCPUs, RAM usw. pro VM oder die unterstützte Anzahl an logischen CPUs und RAM am Host-System seit langem weit mehr, als die meisten Unternehmen und realen Bedingungen ausnutzen. Als Entscheidungskriterium für Unternehmen, die erst jetzt in die Serverkonsolidierung einsteigen wollen, zählen aber mitnichten nur Marktanteile.

Ebenfalls in Betracht gezogen werden müssen:

• die Kosten für Anschaffung (Lizenzierung) sowie Implementation und Betrieb der jeweiligen Lösung. Hier lockt z. B. Red Hats Lösung nach eigener Lösung mit einem Kosteneinsparpotenzial von 50 bis 80 Prozent gegenüber vSphere.

• die Integrationsfähigkeit in bestehende Umgebungen und die Zukunftssicherheit in Bezug auf eine etwaige Integration mit Cloud-Lösungen. Auch hier kann man z. B. Red Hat Enterprise Virtualization Punkte als Enabler für OpenStack-basierte Private-Clouds sammeln.

• Den Aufwand (Schulung / Einarbeitung), um die eigene Virtualisierungsumgebung mit den Managementwerkzeugen des jeweiligen Herstellers zu verwalten. Hier hat Hyper-V mit seiner Integration in Microsoft Windows sicher Vorteile. Außerdem spielt auch der Faktor der eigenen Affinität zum jeweiligen Host- und Management-Betriebssystem in Zusammenhang mit den Vorkenntnissen eine gewisse Rolle.

Die Virtualisierungsprodukte und Hersteller im Einzelnen

Fokussiert man sich angesichts der zu erwartenden Marktrelevanz für 2016 auf VMware vSphere, Microsoft Hyper-V und Red Hat Enterprise Virtualization gibt es außerdem konzeptionelle Unterschiede zu berücksichtigen. Auch hier muss der Nutzer entscheiden, welche davon am besten mit den eigenen Vorkenntnisse, Vorlieben und Gegebenheiten harmonisieren.

VMware vSphere 6.0

VMware ESXi ist ein Typ1-Hyervisor, der auf dem Host Bare-Metal installiert wird. Bei vSphere, bzw. ESXi handelt es sich um einen monolithischen Hypervisor. Dessen von VMware entwickelter Kernel ist zwar im Vergleich zu einem vollwertigen Betriebssystem kompakt, aber größer als der Microkernel bei Hyper-V. Der vSphere-Kernel ist zudem gehärtet und erlaubt per Default kein Nachladen nicht signierter Module. Zudem hat VMware die alleinige Kontrolle über die Entwicklung von Treibern, bzw. Kernel-Modulen, weshalb bei VMware nichts ohne zertifizierte Hardware geht.

Server-Hersteller, die möchten, dass Ihre Hardware von vSphere unterstützt wird, müssen also einen gewissen Aufwand treiben, was sich zwar in den Kosten niederschlägt, aber auch in einem sehr stabilen Ökosystem aus Hard- und Software (Gerätetreiber, Kernel-Module). Darüber hinaus betreibt VMware seit Jahrzehnen eine umfangreiche Kompatibilitätsdatenbank für Hard- und Software.

Eine vSphere-Umgebung lässt sich nicht sinnvoll ohne einen zentralen vCenter Server betreiben. Dieser übernimmt sowohl elementare Managementaufgaben, stellt aber auch einen großen Teil der Funktionalität einer vSphere-Umgebung, insbesondere im Bereich Clustering zu Verfügung. Allerdings stellt er einen zusätzlichen Kostenfaktor dar und - wenn nicht in einem HA-Setup betrieben - ein Single Point of Failure. VMwares Hypervisor beherrscht sowohl Vollvirtualisierung auf Basis der BT (Binary Translation)-Technology, greift aber sofern vorhanden auf die Hardware-gestützte CPU-Virtualisierung zurück und beherrscht für einzelne Geräte (SCSI-Controller, Netzwerkkarte) mit Hilfe der VMware-Tools auch Paravirtualierung.

vSphere Management

Verwaltet wird eine vSphere-Umgebung wahlweise über einen nativen Windows-Client, ein Webinterface oder verschiedene CLI-Schnittstellen (Perl, PowerShell) und APIs. Die Unterstützung für Gastsysteme ist sehr umfangreich und nahezu lückenlos, neben allen aktuellen Windows-Versionen auch Linux, Solaris oder ESXi (nested). Herausragend an vSphere/ESXi ist die bereits von Haus aus sehr fortgeschrittene Netzwerkvirtualisierung in Form des vSphere Distributed vSwitches und die Unterstützung für nahezu alle relevanten Storage-Systeme wie SAN (iSCSI, FC) oder NFS (3.0, 4.1).

Das eigene Dateisystem VMFS ist von Haus aus Cluster-fähig. Außerdem integriert sich vSphere auf Wunsch perfekt mit den SDN- (NSX) und SDS-Technologien (VSAN) aus dem eigenen Haus, sowie mit VMware Cloud-Lösungen und ist mit Zusatzprodukten weitreichend automatisierbar. Selbstverständlich integriert sich vSphere auf Wunsch nahtlos (sowohl ESXi-Hosts, als auch vCenter) in bestehende Verzeichnisdienste wie Active Directory.

Funktionen und Scaleability

Hinsichtlich der gebotenen Funktion ist vSphere seit Jahren führend, um mit vMotion (Live Migration), Storage vMotion, Shared Nothing vMotion (Host und Datenspeicher ändern), High Availablity, Fault Tolerance, Distributed Ressource Scheduling, Replication, Snapshotting, Cloning nur die Wichtigsten zu nennen.

Mit vSphere 6 hat VMware im Compute-Bereich noch einmal die Maximalkonfigurationen massiv gesteigert. VSphere 6 unterstützt pro Host 480 physische CPUs, 2048 virtuelle Maschinen und 12 TB RAM sowie pro virtuelle Maschine 4 TB RAM, 128 virtuelle CPUs und pro Cluster 64 Knoten mit maximal 8000 VMs. Ferner hat VMware seine Verfügbarkeitsfunktionen noch einmal verbessert. So unterstützt das Fault-Tolerance-Feature jetzt bis zu 4 virtuellen CPUs für eine auf diese Art abgesicherte VM. Fault Tolerance erlaubt, dass VMs bei Ausfall des Hosts auf dem Sie laufen ohne Downtime auf einem anderen Host fortgeführt werden können.

Auch an seinem Live-Migration-Feature hat VMware gearbeitet. So ist vMotion jetzt routbar und erlaubt eine unterbrechungsfreie Live-Migration von Workloads über Entfernungen von bis zu 100 ms RTT. Mit der durch Long-Distance vMotion auf das zehnfache gesteigerten RTT können Live-Workloads nun beispielswese etwa zwischen physischen Rechenzentren in New York und London migriert werden. In die gleiche Richtung zielt auch das Feature Content Library. Unter Content Library versteht VMware ein zentrales Repository zum effektiven Verwalten von Content wie VM-Templates, VMs, ISO-Images und Skripten über Standortgrenzen hinweg. Mit dem Content Library Feature wird Content nicht nur an einem zentralen Ort gespeichert, sondern auch mithilfe eines Publish-Subscribe-Verfahrens geteilt. Auch sein vCenter hat VMware deutlich verbessert und den von diesem bereit gestellten Web Client deutlich beschleunigt und stabilisiert.

Hyper-V holt auf

Während VMware das Genre X86-Virtualisierung im Jahr 1998 mit VMware Workstation, einem reinen Typ2-Hypervsor quasi erfunden hat und seinen Typ-1-Hypervisor ESX (später ESXi, vsphere) seit 2001 entwickelt - was auch die hohe Marktdurchdringung erklärt - haben Microsoft und Red Hat erst sehr viel später nachgezogen. Hyper-V ist mit seiner Microkernel-Architektur im Gegensatz zu VMware Kern ein auf Paravirtualisierung ausgerichtet und daher konzeptionell mit dem Xen-Projekt vergleichbar, dass Ende des Jahres 2003 auf der Bildfläche erschienen war.

Wie Xen arbeitet Hyper-V mit einen Parent-Partition (dom0 bei Xen) und einem gegenüber VMware deutlich einfacher aufgebauten Hypervisor, der allerdings zur Bereitstellung von der für Hypervisors essentiellen Deprivilisierungstechnik auf die "Mitarbeit" der Gastsysteme angewiesen ist, während Gäste bei der von VMware erfundenen Vollvirtualisierung nichts davon wissen, dass sie auf virtualisierter Hardware laufen und daher unmodifiziert funktionieren.

Microkernel

In der Microkernel-Architektur von Hyper-V werden die Spezifika der Hardware "außerhalb" des schmal gehaltenen Hypervisors (Parent-Partition) behandelt. Der Vorteil ist neben dem kompakten Hypervisor, dass die Treiberversorgung und Hardwarekompatibilität im Gegensatz zu einem monolithischen Hypervisor, wie VMware exzellent ist.

Die Gastsysteme müssen allerdings modifiziert sein, "wissen" also, dass Sie auf virtualisierter Hardware laufen und kommunizieren ausschließlich über die Hypercall-API und den so genannten VM-Bus mir dem Hypervisor, der sämtliche Funktionsaufrufe behandelt und allein mit der physischen Hardware spricht. Wie Xen auf die Linux-Architektur war Hyper-V anfangs ausschließlich für Microsoft-Gastsysteme ausgelegt, bei denen Microsoft die betreffenden Modifikationen selbst einbauen kann.

Einfache Inbetriebnahme

Dafür lässt sich Hyper-V als "Rolle" in Windows Server deutlich einfacher in Betrieb nehmen. Mit dem einfachen Aktivieren der Hyper-V-Rolle leitet man unter der Haube einen recht komplexen Vorgang ein. In dessen Verlauf siebt der Server Manager quasi im Nachhinein den eigentlichen Hypervisor unter das laufende Windows, wodurch der auf echter Hardware installierte Windows Server komplett in eine virtuellen Maschine (der Parent Partition) verfrachtet wird und selbst nur noch für das Steuern des Hypervisors zuständig ist.

Erst durch das Aktivieren der Hyper-V-Rolle wird der Virtualisierungs-Stack aus Diensten, Komponenten und Treibern zur eigentlichen Management-Instanz in der Parant-Partiton, welche fortan genau wie alle anderen virtuellen Maschinen über die Paravirtualisierungsschicht ( VMBus) auf die physische Hardware zugreift.

Zwingender CPU-Virtualisierungssupport

Allerdings funktioniert das Aktivieren der Hyper-V-Rolle ausschließlich bei CPUs mit Hardware-Virtualisierungssupport (vmx), die außerdem Intel Extend Page Tables (EPT, bzw SLAT) unterstützen müssen, was erklärt, dass das Produkt erst seit 2006 eine gewisse Relevanz hat. Daher gibt es Hyper-V auch nur für die X64-Architektur. Die Gemeinsamkeit mit der Xen Architektur ist für Insider nicht überraschend, da Microsoft und XenSource (seinerzeit noch nicht von Citrix übernommen) seit Mitte 2006 zusammenarbeiten.

Hyper-V (intern v, 1.0) ist erstmals mit Windows Server 2008 erschienen, war aber seinerzeit funktional und vom Leistungsumfang keine Gefahr für den Platzhirsch VMware, da tragfähige Konzepte für die Virtualisierung von Netzwerken und Storage fehlten. Das gilt auch für Hyper-V 2.0 in Windows Server 2008R2. Mit Windows Server 2012 und Hyper-V 3 hatte Microsoft seine Virtualisierungstechnologie allerdings so weit entwickelt, dass auch Features wie die Live-Migration von VMs möglich wurden. Bedingung dafür war Shared Storage mit einem Cluster-fähigen Dateisystem, das Microsoft in Windows Server 2012 in Form von Cluster Shared Volumes (CSV) einführte. NFS-Shared-Storage unterstützt Hyper-V nicht.

Seit Windows Server 2012R2 lassen sich zudem auch SMB-3-Freigaben als Shared Sorage nutzen und mit der neuen Rolle ScaleOut-Fileserver (SoFS), sowie der Unterstützung für die Storage-, bzw. Shared Nothing Live-Migration hatte Microsoft Hyper-V 3.1 endgültig zu einer Enterprise-tauglichen Virtualisierungsplattform aufgepumpt, zumal die Hochverfügbarkeitskonzepte mit Windows Failover Cluster im Vergleich zu VMware schon damals vergleichsweise weit entwickelt waren. Derzeit unterstützt Hyper-V pro Host bis zu 320 logische Prozessoren (2048 virtuelle Prozessoren), 1024 virtuelle Maschinen und 4TB RAM sowie pro virtuelle Maschine 1TB RAM, 64 virtuelle CPUs und pro Cluster 64 Knoten mit maximal 8000 VMs.

Windows Server 2016

Richtig spannend und ggf. etwas enger für vSphere könnte es allerdings in kommenden Jahr mit der Einführung von Windows Server 2016 werden. Auch in dieser Version hat Microsoft Hyper-V weiter aufbohrt. So lassen sich nun auch in Hyper-V virtuelle Netzwerkadapter im laufenden hinzufügen und der Arbeitsspeicher kann im laufenden Betrieb angepasst werden, auch ohne dass man explizit das Dynamic Memory Feature nutzt.

VMware kann beides schon länger. Interessant in Hyper-V 2016 ist auch, dass VMs nun so genannte Production Checkpoints unterstützen. Hierbei wird zum Erzeugen eines Snapshots nicht nur der Speicherzustand der VM benutzt, sondern auch der Volume Shadow Service (VSS) innerhalb der VM. Die VM weiss hier also, dass es einen Snapshot gibt. Ferner sollen die Integrationsdienste (Integration Services) in Hyper-V 2016 nicht mehr mithilfe von ISO-Dateien, sondern via Windows Server Update Services (WSUS) aktualisiert werden.

Red Hat Enterprise Virtualization

Red Hats auf dem Linux-Kernel-Hypervisor KVM und dem Emulationsspezialisten Qemu sowie auf einem komplexen Managementsystem basierende Enterprise Virtualisierungslösung führt zahlenmäßig nur ein Nischendasein. Einige Einzelheiten finden sich http://www.computerwoche.de/a/red-hats-plaene-fuer-die-cloud,2532224,2 hier. Red Hats Virtualisierungsprodukt ist aus einer Lösung des israelischen Virtualisierungsspezialisten Qumranet hervorgegangen, den Red Hat im Jahr 2008 samt Produkt übernommen hatte.

Nachdem der Open-Source-Spezialist das ursprünglich auf Windows-Umgebungen gemünzte Produkt von sämtlichen proprietären Code-Bestandteilen befreit und unter eine Open-Source-Lizenz gestellt hatte - auch der Code des heute im Linux-Standard-Kernel enthaltenen Hypervisors KVMs stammt aus diesem Deal und wurde von Red Hat bereits 2008 freundlicherweise der Open-Source-Gemeinde übergeben - erschien Red Hat Enterprise Virtualization 2009 erstmalig als offizielles Produkt.

RHEV Scaleability und Windows-Gast-Support

2010 hat Red Hat noch seine VDI-Variante Red Hat Enterprise Virtualisierung for Desktops auf dem Markt gebracht. Sie ist mit der von Red Hat (Qumranet) erfundenen SPICE-Technologie augestattet, die samt gleichnamigen Protokoll eine Remote-Display-Performance bietet, die HDX (Citrix XenApp) oder MS RemoteFX nicht nachsteht, im Gegensatz zu den Lösungen von Citrix und VMware aber auch in einer gewöhnlichen RHEV-Server-virtualisierungsumgebung (ohne Session-Broker oder Self-Service-Technologie) zur Verfügung steht. Derzeit unterstützt Red Hat Enterprise Virtualization pro Host 160 logische Prozessoren und 4TB RAM sowie pro virtuelle Maschine 4TB RAM, 160 virtuelle CPUs und pro Cluster 200 Knoten.

Neben allen wichtigen Linux-Gastsystemen unterstützt RHEV Windows Server 2003, 2003 R2, 2008, 2008 R2 und 2012 in 32- und 64-Bit, Windows XP 32 Bit; Windows 7 32- und 64 Bit sowie Windows 8 32- und 64 Bit, wobei für Memory-Ballooning,

Netzwerkkarten und SCSI-Controller spezielle synthetische (paravirtualisierte) Gerätetreiber in Form des virtio-Driver-Packages zur Verfügung stehen, ähnlich wie bei dem VMwares Gast-System-Toolbox für Windows- und Linux-Gäste, sowie Microsofts Integration Services. Bei Hyper-V besteht allerdings der Vorteil, dass diese bei Windows-Gäste im Gegensatz zu den Linux Integration Services (LIS) nicht explizit installiert werden müssen.

KVM und Qemu

Bei Red hat Enterprise Virtualization kümmert sich die Qemu-Komponente um Emulation und teilweise auch die Vollvirtualisierung, während die KVM-Kernel-Komponente für das performante Durchreichen von CPU und Hauptspeicher verantwortlich ist. Insofern kann man RHEV auch weder als Typ1- noch als Typ2-Hypervisor bezeichnen. Der Kernel wird zwar Bare Metal installiert, ist aber im Prinzip ein vollwertiger Linux-Kernel, der theoretisch auch andere Aufgaben neben dem Hypervisor wahrnehmen könnte.

Bei der RHEV-Komponente RHEV-H handelt es sich allerdings in der Tat um ein Minimal-Footprint, das ausschließlich diesem Zwecke dient. Theoretisch könnte aber auch RHEL als Hypervisor zum Einsatz kommen. Die Management-Komponente RHEV-M ist inzwischen ebenfalls eine vollwertige Linux-Umgebung (früher Windows), die auf einer JBoss-Middleware fußt und per Default mit Open-Source-Datenbanken zusammenarbeitet. RHEV-M lässt sich optional physisch oder als VM betreiben. Storage-seitig unterstützt RHEV neben NFS das komplette Universum von Red Hats Storage-Technologien, einschließlich Ceph- und Gluster-Storage.

RHEV 3.5

Neu in RHEV 3.5 sind unter anderem ein verbesserter NUMA-Support (Non-Uniform Memory Access) für Multiprozessor-Systeme, Host NUMA, Guest Pinning und Virtual NUMA. Virtuelle Maschinen können und hochskalierbare Applikationen profitieren so auf Multiprozessorsystemen dank geringerem Ressource-Overload in Bezug auf die Memory-Zugriffszeiten von einer deutlich höheren Performance.

Darüber hinaus hat Red Hat mit RHEV 3.5 ein erweitertes Disaster Recovery eingeführt. Es bietet ein verbessertes Storage Domain Handling und erlaubt Unternehmen das Migrieren von Storage Domains zwischen verschiedenen Rechenzentren sowie Red Hats Technologiepartnern das Bereitstellen von Site-Recovery-Funktionalitäten. (hal)