Virtualisierung ist derzeit in der IT-Welt in aller Munde. CIOs möchten durch Konsolidierungsprojekte höhere Auslastungen ihrer Systeme erreichen und damit letztendlich bei der Hardware Kosteneinsparungen erzielen. Administratoren sehen durch die Loslösung des Betriebssystems von der Hardware eine Flexibilisierung, die ihnen den Alltag erleichtert.
Nachdem Vmware über Jahre hinweg auf der x86-Plattform ihre proprietäre Virtualisierungslösung positioniert hat, sind heute auch einige Open-Source-Lösungen verfügbar, von denen sich das Projekt Xen der Cambridge University hervorhebt. Hinter dem Xen-Projekt stehen alle grossen Player der IT-Welt, unter anderem Intel, AMD, HP, IBM, Dell, Novell und Red Hat. Das sichert nicht nur finanziell eine langfristige Existenz dieses Projekts, sondern auch technologisch.
Die Xen-Lösung basiert auf einer Paravirtualisierung und geht damit einen gänzlich anderen Weg als die bisher bekannten Software-Virtualisierungsansätze. Um den wesentlichen Unterschied und dessen Auswirkung zu verstehen, ist es wichtig, zu begreifen, wo die eigentliche Herausforderung einer Virtualisierung auf der x86-Plattform liegt. Es liegt im wesentlichen an dem in dieser Plattform definierten Ringmodell (siehe Grafik «Ringmodell und Virtualisierung») und der Tatsache, dass diese Architektur nicht unter dem Aspekt der Virtualisierung konzipiert wurde. Demzufolge beachtet es nur das traditionelle Setup mit einer fixen Verbindung zwischen Hardware und Betriebssystem.
Das Betriebssystem wird im privilegierten Ring 0 ausgeführt und hat somit Zugriff auf alle für das Betriebssystem notwendigen Instruktionen des Prozessors. Beim Betrieb einer Software-Virtualisierung liegt nun jedoch der Virtual Machine Monitor (VMM) im Ring 0 und das Betriebssystem eine Stufe höher in einem nicht mehr privilegierten Ring. Damit gehen wesentliche, für ein Betriebssystem lebensnotwendige Zugriffsmöglichkeiten verloren oder liefern gar andere als die im Ring 0 erwarteten Werte. Hier liegt also die eigentliche Aufgabe der Virtualisierungstechnologien auf Software-Ebene: das Problem der Ringverschiebung zu lösen.
Klassische Ansätze zur Lösung dieser Problematik sind das Abfangen von Prozessorinstruktionen, die einen privilegierten Ring 0 benötigen, oder das Verwenden eines Interpreters, welcher die privilegierte Umgebung emuliert. Allen diesen Ansätzen gemeinsam ist, dass sie zusätzliche Rechenleistung benötigen.
Die Paravirtualisierung setzt in diesem Bereich auf eine andere Ausgangslage: ein modifiziertes Betriebssystem. Simpel ausgedrückt ist dem Gastsystem bewusst, dass es in einer virtualisierten Umgebung ausgeführt wird, worauf es sich anders verhalten kann als im Ring-0-Betrieb.
Technisch betrachtet werden dem Gastsystem für privilegierte Interaktionen mit dem Prozessor entsprechende Hypercalls über eine API implantiert. Es existiert bei der Paravirtualisierung eine direkte Kommunikation mit der Virtualisierungsschicht. Somit arbeiten alle Beteiligten eines paravirtualisierten Xen-Szenarios miteinander und es muss kein Ring-0-Betrieb für das Betriebssystem emuliert werden. Folglich ist diese Art der Virtualisierung sehr effizient.
Da Xen eine direkt auf der Hardware aufliegende Virtualisierungsschicht darstellt, spielt es technisch betrachtet in der gleichen Liga wie beispielsweise der ESX-Server von Vmware. Es ist daher nicht verwunderlich, dass die grossen Linux-Anbieter diese Technologie in ihre Enterprise-Distributionen integriert haben. Der Suse Linux Enterprise Server 10 (SLES) liefert beispielsweise seit Juni 2006 die Möglichkeit der Virtualisierung frei Haus mit. Kinderkrankheiten der Integration von Xen sind mit heutigen Versionen daher nicht mehr zu erwarten. Im Gegenteil: Beispielsweise unterstützt SAP für den SLES 10 die Xen-Virtualisierung mittlerweile und hat mit Hardwareherstellern Zertifizierungen für komplette Stacks (Hardware mit SLES, SAP und Xen) vorgenommen. Ein deutliches Signal, dass nicht nur Hardwareproduzenten und Linux-Distributoren hinter Xen stehen, sondern auch Applikationshersteller.
Virtualisierungen von Serverlandschaften sind also mit Xen heutzutage eine gute Alternative zu proprietären Lösungen. Doch es geht noch weiter: Auch der Desktop ist ein Ziel der Virtualisierung, beispielsweise in Zusammenhang mit Thin Clients, welche derzeit ebenfalls eine wachsende Begeisterung verzeichnen.
Klassischerweise werden im Umfeld von Thin Clients Terminalserver verwendet. Dieses Modell hat den Vorteil, dass pro Terminalserver nur ein Betriebssystem gepflegt werden muss. Allerdings weist dieses Konzept auch einige Einschränkungen auf: Die Sitzung eines Benutzers auf einem solchen System ist nicht komplett isoliert – mit allen daraus resultierenden Risiken. Beim Einsatz von Java-Applikationen in einem solchen Szenario sieht man sich schnell der Problematik von gleichzeitig laufenden Instanzen einer gleichen Applikation gegenüber. Letzteres führt dazu, dass sich nur wenige Benutzer mit einem Terminalserver versorgen lassen.
Virtualisierte Desktops mit Xen und FreeNX
Die Lösung hierzu kann eine virtualisierte Desktop-Lösung sein. Dabei werden Desktops auf Xen-Server aufgesetzt und beispielsweise mit Hilfe der freien Terminal-Server-Software FreeNX mit den Thin Clients verbunden. Die positiven Aspekte dieses Ansatzes sind zum einen die komplett isolierten Desktop-Umgebungen und zum anderen die Ausfallsicherheit. Erstere helfen, bei einem Systemproblem innerhalb eines virtualisierten Desktops die benachbarten virtuellen Sitzungen nicht zu beeinträchtigen und lösen das bereits genannte Java-Problem auf Terminalservern.
Von einem Systemproblem betroffene Benutzer können den Desktop neu starten oder sich gleich auf eine andere Desktop-Instanz verbinden. Dies führt wiederum zu der positiven Auswirkung, dass der Administrator sich nicht zwingend unmittelbar um einen defekten Desktop eines Benutzers kümmern muss. Auch Wartungsarbeiten im Backend der virtualisierten Desktop-Umgebung werden durch die Möglichkeit der Migration von virtuellen Desktops auf andere Hosts zu einer simplen Angelegenheit und stoppen nicht die Produktivität der Mitarbeiter.
Das Anbinden von Aussenstellen oder gar des Heimarbeitsplatzes sind typische Gründe, weshalb man über solche Desktop-Szenarien nachdenkt. Gerade die angesprochene Komponente FreeNX2 zeichnet sich für diesen Einsatz aus. Sie kommt aufgrund von Komprimierung mit sehr geringer Bandbreite aus und verwendet eine starke Verschlüsselung (SSH) für die komplette Kommunikation. Trotz dieser Mechanismen werden die Benutzer in der Arbeit an einem solchen Desktop, auch bei Verwendung einer schmalbandigen, analogen Modemverbindung, nicht spürbar beeinträchtigt.
Zudem sparen virtualisierte Desktops Geld. Einerseits weil herkömmliche Terminalserver-Lösungen teuer sind, und andererseits, weil statt speziellen Client-Access-Lizenzen nur die normalen Lizenzen für Desktops benötigt werden, die in der Regel günstiger sind.
Xen, XenSource – oft tauchen diese beiden Begriffe gemeinsam auf. Insbesondere, nachdem Citrix mit der Übernahme von XenSource für Schlagzeilen gesorgt hat. Doch wo ist der Unterschied? Dieser liegt darin, dass Xen die freie Version der gleichnamigen Virtualisierungstechnologie ist. XenSource ist hingegen ein kommerzieller Ableger des Xen-Projekts und liefert Managementlösungen für Xen. Neben XenSource existiert auch noch eine Reihe weiterer kommerzieller Anbieter von Managementlösungen mit grösserem oder kleineren Funktionsumfang – darunter auch Novell mit seinem ZENworks Orchestrator. Der Vorteil der Trennung zwischen Virtualisierung und Management für den Kunden liegt dabei auf der Hand: Er kann sich für das zu seinen Bedürfnissen passende Angebot entscheiden und ist nicht fix an eine Lösung gebunden.
