XenServer 6.0: Support für VMM 2012, GPU pass-thru, Self Service Manager

Im Vergleich zu den großen Fortschritten, die XenServer 5.6 inklusive FP1 und SP2 brachte, nehmen sich die Neuerungen der Version 6.0 weniger spektakulär aus. Sie bestehen primär in der (besseren) Integration von bereits bestehenden Techniken und daraus resultierender einfacherer Bedienung. Hinzu kommen ein als neu angekündigtes Self-Service-Portal sowie eine generelle Aktualisierung der Plattform, sowohl den Hypervisor als auch die unterstützten Gäste betreffend.

Zu den wichtigsten Aufräumaktionen in XenServer 6.0 zählt das vereinfachte Management von Workload Blancing, Site Recovery und StorageLink. Citrix stellt zudem die Funktionen für die dynamische Lastenverteilung als vorkonfigurierte virtuelle Maschine (virtual Appliance) bereit, um ihre Inbetriebnahme und Administration zu vereinfachen.

Verwaltung über System Center Virtual Machine Manager 2012

Wenn sie schon nicht der Vereinfachung dient, dann bietet die Unterstützung für den System Center VMM 2012 zumindest eine zusätzliche Option zur Administration. Laut Citrix lassen sich mit dem Microsoft-Tool Hosts und VMs überwachen sowie verwalten. Die Ankündigung des VMM-2012-Supports gibt keine Auskunft darüber, wo seine Einschränkungen im Vergleich zu XenCenter liegen. Für die Anbindung von XenServer an den VMM 2012 ist ein eigenes Supplemental Pack erforderlich, das mit der Markteinführung des Microsoft-Tools verfügbar sein soll.

Integration und Umbau von StorageLink

StorageLink, das Speichersysteme über eine einheitliche Schnittstelle anbindet und darüber Operationen wie Cloning oder Snapshoting von VMs an Storage-Arrays delegieren kann, wird direkt in das Kernprodukt übernommen. Es setzt somit keine zusätzliche Windows-Installation mehr voraus. Mit dieser Änderung reduziert sich jedoch die Zahl der direkt unterstützten Speichersysteme, so dass nun nicht mehr berücksichtigte Produkte generisch etwa über iSCSI-Funktionen angebunden werden.

Gleichzeitig wird Site Recovery von StorageLink entkoppelt, so dass für das Disaster Recovery auf Basis praktisch aller Speichersysteme möglich ist, wenn diese Replikationsfunktionen beherrschen, sei es direkt oder über Software von Drittanbietern.

Open vSwitch als Standard

Einen weiteren Schritt in der Konsolidierung von XenServer und damit verbundener Technologien bedeutet die Verwendung von Open vSwitch als Standard für das Networking. XenServer unterstützt diese Komponente schon seit der Version 5.6 FP1, sie musste dort aber nachträglich eingerichtet werden, um das von Linux stammende Bridging zu ersetzen. Letzeres ist immer noch an Bord, müsste nun aber seinerseits nach der Installation nachträglich aktiviert werden.

Mit diesem Wechsel im Networking geht die Verbesserung von NIC Bonding (Aggregierung mehrerer Adapter) einher sowie die Unterstützung von Jumbo Frames. Außerdem erhöht sich damit die Ausfallsicherheit, wenn die vSwitch-Appliances im Fail-Safe-Modus betrieben werden.

Hypervisor-Verbesserungen durch Xen 4.1

Zu den weiteren Maßnahmen der Produktpflege in XenServer 6.0 zählt das Update des Hypervisors auf Xen 4.1. Daraus ergibt sich eine höhere Leistungsfähigkeit, beispielsweise kann das neue Release von XenServer bis zu 1 TB an Host-RAM ansprechen und VMs bis zu 16 vCPUs und 128 GB vRAM zur Verfügung stellen. Konkurrent VMware schraubte diese Werte mit vSphere 5 auf 32 vCPUs und 1TB vRAM hoch. Hintergrund für diesen Wettlauf ist das Bestreben der Anbieter, auch anspruchsvollste Anwendungen wie SAP oder In-Memory-Datenbanken virtualisieren zu können.

GPU Pass Thru wertet HDX 3D auf

Die Auffrischung der Basistechnik bringt mit GPU Pass Thru ein neues Feature, das vor allem der Desktop-Virtualisierung zugute kommt. Es bietet die Möglichkeit, einer virtuellen Maschine direkten und exklusiven Zugriff auf die Grafik-Hardware zu erlauben. Damit erschließen sich auch Arbeitsplätze mit anspruchsvollen Anwendungen, beispielsweise CAD oder Broker-Systeme in der Finanzindustrie, der Ausführung in VMs. Die von XenServer angebotenen virtuellen GPUs sind dafür nicht ausreichend leistungsfähig.

Schon bisher bot Citrix mit HDX 3D die Möglichkeit, derartige Desktops ins Rechenzentrum zu verlagern, allerdings nur auf dedizierte Hardware, also in der Regel auf Blade-PCs. Diese lassen sich zwar auch über XenDesktop administrieren, verursachen wegen der erforderlichen zusätzlichen Hardware jedoch höhere Kosten. Diese lassen sich mit GPU Pass Thru senken, wenn Desktops mit höheren Grafikanforderungen ebenfalls in VMs auf einem Server ausgeführt werden können.

Self Service Manager ersetzt Lab Manager und Self-Service-Portal

Als neues Feature für XenServer 6.0 kündigte Citrix den Self Service Manager an. Es erlaubt Benutzern oder Abteilungen die Verwaltung ihrer Ressourcen in Eigenregie, ohne die IT-Abteilung dafür beauftragen zu müssen. Damit reiht sich dieses Tool in ein Angebot mehrerer solcher Selbstbedienungsportale ein, wie etwa jenes von VMM 2012 oder das in vCloud Director. Citrix selbst lieferte ein solches bereits mit XenServer 5.6 aus, der Lab Manager erfüllte als Teil der Essentials eine ähnliche Aufgabe.

Der neue Self Service Manager beerbt diese beiden Produkte. Entsprechend enthält er ebenfalls ein Web-basiertes Selbstbedienungsportal und unterstützt dessen Nutzung durch die Möglichkeit, Freigabe-Workflows zu definieren, die Kosten für die Nutzung von virtuellen Ressourcen abzurechnen (Chargeback) oder Quotas einzuziehen sowie zu verwalten. Der Self Service Manager bietet zudem eine rollenbasierte Administration und kann außerdem auch Ressourcen verwalten, die über VMware vSphere bereitgestellt werden.

In der Nachfolge des Lab Manager kann der Self Service Manager auch so genannte vApps anlegen und verwalten. Es handelt sich im Citrix-Jargon dabei um Verbünde von virtuellen Maschinen, die von einer Anwendung benötigt werden. Dabei könnte es sich beispielsweise um das Zusammenspiel einer Datenbank, eines Applikations- und eines Web-Server handeln, die jeweils in eigenen VMs laufen. Sie lassen sich in einem Vorgang gemeinsam aktivieren oder speichern. Bei einem Neustart des Hosts kann man im Self Service Manager die Boot-Reihenfolge der VMs festlegen, um etwa zu gewährleisten, dass die Datenbank verfügbar ist, wenn der Applikation-Server seine Arbeit aufnimmt.