Desktop-Virtualisierung für den Mittelstand

Kaviza VDI-in-a-Box im Test

15.11.2010 von Andrej Radonic
Das Startup Kaviza will mit VDI-in-a-Box neue Standards bei Kosten und Benutzererfahrung setzen und damit auch kleinen und mittleren Unternehmen eine erschwingliche Lösung für virtualisierte Desktops bieten. Von den großen Lösungen wie Citrix XenDesktop und VMware View unterscheidet es sich durch reduzierte Komplexität, einfachere Infrastruktur sowie geringere Kosten.

Nachdem sich Servervirtualisierung inzwischen als feste Größe in den Rechenzentren etabliert hat, rückt zunehmend die Virtualisierung von Desktops in den Fokus der IT-Verantwortlichen. Denn auch hier locken - zumindest auf dem Papier - ähnliche Vorteile wie für die Server.

Übersichtliche Architektur

Die Architektur der Kaviza-Software, welche kürzlich auf der VMworld 2010 als beste Desktop-Virtualisierungslösung ausgezeichnet wurde, besteht im Kern aus drei Komponenten:

Die Kaviza-Architektur setzt auf einer virtualisierten Serverappliance auf

Kaviza unterscheidet zwischen zwei Client-Typen:

Für die Verwaltung von Berechtigungen und Usern kann sich der Kaviza Server mit einem Active Directory verbinden. Alternativ verwaltet der Kaviza Manager diese Daten in einer eigenen Datenbank lokal. Im Zusammenspiel mit AD bietet Kaviza die Option, Roaming User Profiles zu verwenden. Die Benutzer-bezogenen Daten werden dabei zentral außerhalb des Virtuellen Desktops vorgehalten.

Installation

Der Kaviza-Manager wird auf einem Standard-Server mit Citrix XenServer 5.6 oder VMware ESX(i) 4 installiert, dedizierte Server sind dabei empfehlenswert. Unterstützung für Microsoft Hyper-V ist für Anfang 2011 angekündigt. Die eigentliche Installation hat der Administrator flott erledigt: Die Kaviza- Serverappliance importiert er dafür einfach als VM aus einer OVF-Datei.

Die Server-Ausstattung sollte dabei gut geplant werden, um genügend Ressourcen für die zu hostenden virtuellen Desktops bereitzustellen:

Direkt nach dem Booten der Kaviza-Manager-VM kann der Administrator per Browser auf die Administrationskonsole unter der URL http://SERVERIP/dt zugreifen. Die Standard-Zugangsdaten für den Administrator lauten: kavizaadmin / kaviza

Kaviza-Setutp Assistent erfragt den Hypervisor-Typ

Beim ersten Aufruf ist ein simpler Assistent zu durchlaufen, der dem Adminstrator hilft, die Basis-Einstellungen festzulegen: Directory (lokal oder MS AD), Hypervisor-Typ, optionale Grid-Konfiguration sofern Hochverfügbarkeit und ein verteiltes Setup gewünscht ist.

Davon, dass im Kern des Kaviza-Servers ein Linux-System (Ubuntu mit Tomcat) vor sich hin werkelt, bemerkt der Sysadmin im Normalfall nichts. Das ändert sich jedoch, wenn es gilt, ein Update der Serversoftware durchzuführen. Dafür ist das Update-Paket per SSH auf den Server zu laden und auf der Shell ein Update-Script zu starten. Der Prozess ist gut dokumentiert und soll in Zukunft durch einen automatischen Vorgang abgelöst werden.

Auf der Client-Seite hat der Admin nicht viel zu tun: Er nutzt entweder den Zero-Install-Client, welcher jedoch eine aktuelle JVM voraussetzt. Oder es kommt RDP zum Einsatz, so dass ein Terminalserver-Client vorhanden sein muss. Egal welche Variante präferiert wird: in jedem Fall steht damit eine große Bandbreite an potenziellen Endgeräten zur Verfügung.

Desktop-Deployment

Aufgrund des Box-Charakters des Serversystems hat der Administrator mit diesem nicht allzu viel Mühe. Im Fokus der VDI stehen vielmehr die virtuellen Desktops – und hier gilt es entsprechend viel Zeit und Sorgfalt einzukalkulieren.

Kaviza organisiert die Generierung und das Deployment von Desktops in mehreren Schritten:

  1. Die Basis für einen neuen Virtuellen Desktop ist eine vorhandene Windows-VM. Unterstützt werden Windows XP und Windows 7 (32 und 64 Bit).

  2. Aus dieser "Ur-VM" erstellt der Kaviza Manager zunächst ein sog. Working Image. Achtung: Die ursprüngliche VM existiert nach diesem Vorgang nicht mehr!

  3. Der Kaviza Manager führt im Working Image einen Sysprep-Vorgang durch und erstellt dabei das endgültige Desktop Image.

  4. Mittels Templates konfiguriert der Administrator die Eigenschaften der Desktops, wie Menge an Arbeitsspeicher, angeschlossene Peripheriegeräte und weitere Eigenschaften.

  5. Auf Basis des Templates und des zugrundeliegenden Desktop Images werden pro Anwender dynamisch virtuelle Desktops deployed. Technisch handelt es sich um eigenständige VMs, welche aus dem Desktop Image gecloned werden (linked clones).

Die eigentliche Flexibilität entsteht aus der Fähigkeit, aus einem Desktop Image viele virtuelle Desktops generieren und mittels Templates deren Eigenschaften dynamisch bestimmen zu können. Mehrere verschiedene Templates dürfen dabei auf einem Image basieren. Somit ist die Verwaltung stark zentralisiert, der Administrationsaufwand wird minimiert.

Der eigentliche Vorgang der Generierung virtueller Desktops bis hin zur produktiven Nutzung ist von der Bedienung her einfach, vom gesamten Prozess jedoch durchaus diffizil, da bereits durch Kleinigkeiten der beschriebene Generierungsprozess fehlschlagen kann.

Vor allem muss der Kaviza-Administrator bei der Bereitstellung der Ur-VM eine ganze Reihe von Restriktionen kennen und penibel beachten: Beispielsweise muss die VM im selben Storage liegen wie die Kaviza-Server-VM selbst, zudem dürfen keine Snapshots zu der VM im Hypervisor existieren. Die Ur-VM darf nur über eine NIC und eine Festplatte verfügen. Bei Windows XP ist außerdem eine aktivierte Lizenzierung auf Basis einer Volumen-Lizenz zwingende Voraussetzung. RDP-Zugriff muss möglich sein, der HDX-Port freigeschaltet sein, der Administrator muss ein aktives Konto besitzen. Weiterhin muss der Windows-Patch KB 976494 installiert werden.

Hat der Administrator die Ur-VM derart vorbereitet, kann er in der Kaviza-Webkonsole die virtuellen Desktops generieren und das Deployment automatisieren.

Kaviza Template-System

Probleme können im wesentlichen nur dann entstehen, wenn der Administrator die Voraussetzungen nicht beachtet bzw. die Ur-VM nicht korrekt vorbereitet. Die eigentliche Schwierigkeit für den Verwalter liegt darin, dass Kaviza keine Fehlermeldungen ausgibt, sondern er einfach nur feststellt, dass die VM entweder nicht gespeichert oder später nicht deployed wird. In einer künftigen Version soll der Administrator ausführlicher informiert werden.

Als Best Practice ist es empfehlenswert, nach der Erstellung einer "gültigen" Ur-VM diese als "Golden Kaviza Master" sofort zu clonen (nicht linked clone), um für spätere Desktop-Generierungen wieder auf eine fertige VM zurückgreifen zu können. Denn Kaviza wandelt die Ur-VM in ein VM-Template um, welches nicht mehr direkt als VM nutzbar ist.

Desktops-Templates

Die eigentliche Flexibilität des Deployment-Systems im Hinblick auf die Anwender der virtuellen Desktops bezieht Kaviza aus dem Template-Ansatz.

Mit Templates definiert der VDI-Sysadmin, welches Image mit welchen Eigenschaften (z.B. Menge an Arbeitsspeicher) an welche Anwender geliefert wird. Über das Template wird auch gesteuert, wann der virtuelle Desktop "refreshed" wird – also in den ursprünglichen Zustand des Betriebssystems vor der ersten Verwendung versetzt wird. Dies ist dann nützlich, wenn Mitarbeiter beispielsweise in Schichten arbeiten und der jeweils nächste Start ein völlig "frisches" Windows liefern soll. Der Refresh kann aber auch vom Sysadmin ausgelöst werden, beispielsweise um durchgeführte Updates zu installieren und zu "propagieren".

Das Template definiert zudem, ob Drucker und Laufwerke an den Desktop durchgereicht werden sowie ob Smartcards verfügbar sein sollen für die Authentisierung.

Um den Lifecycle der Desktops zu verwalten, kann der Administrator zu jeder Zeit ein vorhandenes Image verändern ("patchen"), beispielsweise um Sicherheitsupdates einzuspielen. Hierzu erstellt er ein neues Working Image auf Basis des zu ändernden Images. Kaviza legt dabei einen verbundenen Clone des ursprünglichen Images an. Diesen kann der Sysadmin verändern und dann als neue Variante des Desktops deployen.

Um Benutzer sofort bei Login mit einem Desktop zu versorgen, so dass Anwender nicht erst auf das Booten warten müssen, kann der Administrator je Template einstellen, wieviele Desktops vorab automatisch gestartet werden sollen. Wichtig unter Auslastungsgesichtspunkten ist der zugehörige Begrenzungsparameter, der die Anzahl gleichzeitiger Desktops limitiert.

Entscheidend für die Skalierbarkeit und Verfügbarkeit des Systems ist die integrierte Ressourcenüberwachung. Der Administrator kann definieren, wieviele Ressourcen des Servers bzw. Hypervisors Kaviza inklusive der laufenden Desktops nutzen darf und zeigt dies in einem Auslastungsbalken je Server im Grid an.

Dialog zum Erstellen eines Templates für eine virtuelle Maschine

Nicht optimal gelöst ist aus Anwendersicht der Login, wenn der Desktop noch nicht gestartet ist: Der Benutzer erhält in diesem Fall die lapidare Meldung, dass sein Desktop nun gestartet wird und er sich später erneut einloggen soll, um ihn zu erreichen. Es gibt jedoch keinerlei Indikation über den Status des Desktops, so dass der Benutzer es "blind" neu versuchen muss.

Client-Verwaltung


Der Browser-Client startet lokal den jeweils Installierten RDP-Client und dient somit nur zur ersten Verbindungsherstellung und dem Kaviza-Login. Anwender starten ihn im Webbrowser mit der Adresse http://SERVERIP/dt/

Empfehlenswert ist der Kaviza Client. Dabei handelt es sich um ein Java-Applet, welches einen RDP-Client mitliefert und je nach Ausstattung des Endgeräts eine HDX- oder RDP-Verbindung zum Desktop herstellt. Der Java-Client ist erreichbar unter der URL : http://SERVERIP/dt/kavizaclient.jnlp.

Kaviza-Client mit Desktop-Auswahl für den aktuellen Anwender

Die Voraussetzungen für die Client-Ausstattung sind vergleichsweise gering: Java VM, RDP (unter Linux/Unix: rdesktop client; Mac OS X: RDP Client), Citrix Online HDX Plugin (optional).

Für eine verbesserte Bildschirmauflösung und Tonqualität sorgt Citrix HDX (High-Definition User Experience). Hierbei handelt es sich um ein Bündel von Technologien, welche die Performance bei der Übertragung von Multimedia-Inhalten, Sprache, Video und 3D-Grafiken für Remote Nutzer verbessern. So wird durch die Komponente HDX Realtime überhaupt erst eine VoIP- oder Webcam-Nutzung möglich.

Damit der Kaviza-Desktop-Nutzer in den Genuß der HDX-Fähigkeiten kommt, muss er zunächst das Citrix Online Plugin Web installieren. Der Kaviza-Client nutzt sodann automatisch die HDX-Technik bei der Desktop-Darstellung.

Zu beachten ist, dass der von Kaviza mitgelieferte Internet Gateway, der SSL-verschlüsselte Anbindung von Remote Usern ohne VPN ermöglicht, nur mit RDP-Sessions funktioniert und nicht mit HDX. Anwender dieser Technik müssen daher bei Zugang über Internet eine Absicherung der Verbindung über VPN einrichten.

Wie bei anderen VDI-Lösungen kann der Kaviza-Anwender seinen virtuellen Desktop einfach “mitnehmen”: Meldet er sich ab und loggt sich von einem anderen Endgerät aus wieder ein, findet er automatisch seinen zuvor benutzten Desktop 1:1 wieder vor.

Kaviza Grid: Hochverfügbarkeit inklusive

Kaviza liefert auf Wunsch ein integriertes Hochverfügbarkeits-Setup inklusive Loadbalancing. Templates und Images werden im Grid automatisch auf die beteiligten Kaviza-Server repliziert. Existieren mehrere virtualisierte Server mit installiertem Kaviza Manager, ist es sinnvoll, diese zu einem Grid zu verbinden. Hierdurch wird eine Lastverteilung und eine Koordination der VM-Aktivitäten mit einer gewissen Ausfallsicherheit gewährleistet. Der Loadbalancer wirkt sich dabei auch auf die Prestart-Desktops aus und verteilt die vorab gestarteten Desktops über die beteiligten Server. Bei einem User-Login wird der Virtuelle Desktop von demjenigen Server mit der geringsten Belastung provisioniert.

Die verteilte Grid-Architektur bietet gegenüber SAN-basierten VDI-Setups den zusätzlichen Vorteil, dass das Storage weder Single-Point-of-Failure noch Performance-Flaschenhals sein kann.

Unbedingt zu beachten ist die Empfehlung seitens des Herstellers, das Hypervisor-Setup für die Kaviza-Grid ohne HA- und Pooling-Funktionalität aufzusetzen, damit keine Konflikte zwischen Kaviza-HA und Hypervisor-HA entstehen.

Preise

Lizenzen können für € 100 pro concurrent Desktop erworben werden (ab 50 Stück greifen vergünstigte Staffeln). Ist HDX gewünscht, erhöht sich der Lizenzpreis um weitere € 28 – eine für die meisten Anwender sehr lohnenswerte Investition. Hinzu kommen Wartung und Support für die ersten 12 Monate: € 20 je concurrent Desktop plus € 6 je HDX-Nutzer. Eine kostenfreie 30-Tage-Testversion kann von der Hersteller-Website heruntergeladen werden.

Weblinks

Unternehmenswebsite: www.kaviza.com, www.kaviza.de
Kaviza-Blog: kaviza.blogspot.com
Kaviza Reseller in Deutschland: Matrix 42 www.matrix42.com
Video: Kaviza im Einsatz: www.youtube.com/watch?v=KZdkh6Kzny8
Video: Kaviza-HA Demo: www.youtube.com/watch?v=hHxqCsBgaMA

Fazit

Kaviza ist auf kleinere bis mittlere Unternehmen ausgerichtet und richtet sich außerdem an Managed Service Provider. Es liefert ein schnell aufzusetzendes VDI-System "out-of-the-box". Der Einstieg in die Welt des VDI gelingt damit vergleichsweise sehr kostengünstig und mit einem erfreulich einfachen Lizenzmodell obendrein.

Besonders hervorzuheben – gerade aus Sicht der angepeilten Zielgruppen – ist die Genügsamkeit bei Server- und Storage-Ausstattung und die angesichts dessen trotzdem gebotene Hochverfügbarkeits-Versicherung. Insgesamt gelingt damit der Spagat zwischen geringen Ansprüchen an die Umgebung, hoher Leistung und moderaten Kosten.

Da die Anfangs-Kosten vergleichsweise gering sind, rechnet der Hersteller vor, dass sich der Einsatz ab etwa 25 Anwendern / virtuellen Desktops lohnt. Konkret werden Kosten von 270 bis 370 € je Desktop exklusive Endgerät aber inklusive Serverhardware und ESX-Lizenz genannt.

An die Administratoren werden trotz allem recht hohe Ansprüche gestellt. Zum einen sollte Knowhow im Thema Server-Virtualisierung vorhanden sein, ansonsten es muss im Zuge der Kaviza-VDI angeeignet werden. Zum anderen muss das von Natur aus komplexe Thema VDI mit all seinen Aspekten erarbeitet werden. Hier sind vor allem die Besonderheiten und Problematiken mit der Virtualisierung und dem Rollout von Windows-Desktops zu nennen, was zwar keine Kaviza-Besonderheit ist, jedoch ein generelles Hindernis für eine breite VDI-Adoption.

Was gerade VDI-Einsteiger bedenken müssen, ist, dass die Virtualisierung der PCs allein das Flexibilisierungspotenzial nur zu einem kleinen Teil ausschöpft: Die Zentralisierung der Benutzerprofile, sämtlicher Anwenderdaten sowie der Applikationen (z.B. durch Applikationsvirtualisierung) macht den Anwender wirklich weitestgehend unabhängig vom Endgerät und von der Desktop-Session. Und erst dann kann der HA-Mechanismus bei einem Ausfall im laufenden Betrieb wirklich Schaden abwenden. Kaviza bringt jedoch keine Techniken zum Management der Userprofile und zur Virtualisierung der Applikationen mit. Darum müssen sich Kaviza-Anwender zur Zeit noch selbst kümmern – mithilfe von Drittprodukten.

Pro:

Contra:

VDI – Vor- und Nachteile

VDI (Virtual Desktop Infrastructure) verlagert physische PC-Desktops in virtuelle Maschinen auf einigen wenigen Servern, wo sie zentralisiert gemanaged und betrieben werden. Damit vereinfacht VDI das Management, erhöht die Sicherheit und die Verfügbarkeit der Systeme und spart Kosten bei Betrieb und Hardware. Zudem verbessert sich die Flexibilität der gesamten IT, indem neue Desktops in Sekundenschnelle bereitgestellt werden können, zum Beispiel für neue Mitarbeiter oder für kurzfristige spezielle Aufgaben.

Gegenüber anderen Varianten der Desktopvirtualisierung wie z.B. Terminal Server hat VDI den großen Vorteil, dass sich individuelle Arbeitsumgebungen besser abbilden lassen, da jeder Mitarbeiter seine eigene Umgebung in Form einer separaten und privaten VM erhält, die sich im wesentlichen identisch zu einem physischen Desktop verhält.

Weitere Anreize für die Auseinandersetzung mit Desktopvirtualisierung sind aktuelle Themen wie das Auslaufen des Microsoft-Supports für Windows 2000 sowie die bei vielen Unternehmen bevorstehende Migration auf Windows 7.

Bislang ist die praktische Umsetzung von VDI jedoch aufwändig und bleibt daher noch den großen Unternehmen vorbehalten. Die wesentlichen Hindernisse sind: