Kaviza VDI-in-a-Box im Test: Desktop-Virtualisierung für den Mittelstand

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

• Anfangskosten, da hohe Anforderungen an die gesamte Umgebung gestellt werden, Kostentreiber ist vor allem der benötigte Netzwerkspeicher (SAN) mit den zugehörigen Hochleistungsnetzwerken.
• Hohe Komplexität, da zumeist eine Fülle von Komponenten und Diensten benötigt wird, um eine VDI-Umgebung aufzusetzen, wie Shared Storage, Load-Balancing, Hochverfügbarkeit, Connection Broker usw.
• Benutzererfahrung: Viele der verwendete Protokolle schränken die Anwendungsmöglichkeiten für Benutzer ein. Ein weiterer Nachteil ist die eingeschränkte Möglichkeit zur Offline-Nutzung des virtuellen Desktops, wobei Citrix und VMware hier zuletzt einige Fortschritte verzeichnen konnten.

Im ungünstigen Fall kommen zentrale Desktops teurer als die alte Fat-Client-Armada, wobei dann unter Umständen obendrein noch die Probleme der alten Desktop-Umgebung ins Data Center verlagert werden.

Übersichtliche Architektur von VDI-in-a-Box

Kaviza VDI-in-a-Box besteht im Unterschied zu den großen Systemen der marktführenden Anbieter nur aus drei Komponenten:

• Das gesamte Management erfolgt über den Kaviza Manager, dieser wird als virtuelle Appliance für VMware ESX(i) oder Citrix XenServer bereitgestellt. Über den Manager werden virtuelle Desktops erstellt, gesteuert und an die Benutzer publiziert.
• Jeder Virtuelle Desktop verfügt über einen Agent (Kaviza Desktop Agent), der die Kommunikation des Managers mit jeder Desktop-Instanz ermöglicht.
• Der Kaviza-Client ermöglicht dem Anwender den Remote-Zugriff auf den persönlichen virtuellen Desktop. Clients nutzen dafür entweder RDP oder das Kaviza Java-Applet, um sich mit ihrem virtuellen Desktop zu verbinden. Unterstützt werden Windows, Linux/Unix und Mac OS sowie diverse Thin Clients (z.B. Wyse, sowie solche, die Java oder einen Browser ausführen können). Zusätzlich steht optional Citrix HDX zur Verfügung. Mittels des dafür nötigen Citrix Receiver gelangt der Kaviza-Desktop auf eine Fülle weiterer Endgeräte, wie iPhone, iPad, Android.

Kaviza unterscheidet zwischen zwei Client-Typen:

• Kaviza Client: kommt ohne Installation aus, setzt aber Java voraus
• Kaviza Browser Client: dient dem Starten des lokal installierten HDX- oder RDP-Clients

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 kann auf einem schon vorhandenen Server mit Citrix XenServer 5.6 oder VMware ESX(i) 4 installiert werden. Die eigentliche Installation hat der Administrator flott erledigt: Die Kaviza- Server-Appliance importiert er dafür einfach als VM aus einer OVF-Datei.

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

• Dedizierte Server sind empfehlenswert
• Empfohlen werden bis 8 Desktops pro CPU-Kern. Bei 25 Desktops genügt somit zumeist ein handelsüblicher Vierkern-Prozessor.
• Der Kaviza-Manager benötigt selbst nur ca. 0.5 GB RAM sowie etwa 700 MB Festplattenplatz (für die Installation werden dabei temporär 70 GB allokiert).
• Je Windows-7-Desktop sollte mindestens 1 GB RAM vorgesehen werden, Windows XP kommt mit weniger aus. Dabei ist zu berücksichtigen, dass bei einem Hochverfügbarkeits-Setup jeder Server Reserven braucht, um zusätzlich alle (bei 2 Servern) oder einen Teil der übrigen Desktops übernehmen zu können und dafür die entsprechende Menge an RAM benötigt.
• Zuzüglich benötigter Festplattenplatz je Desktop: Basis-Image netto plus 15% des Images je virtuellem Desktop plus dem Anteil für RAM auf der Festplatte.

Direkt nach dem Booten der 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

Beim ersten Aufruf ist ein simpler Assistent zu durchlaufen, der dem Adminstrator hilft, die Basis-Einstellungen festzulegen: Directory (lokal oder Active Directory), Typ des Hypervisors und 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 Server-Software 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, der jedoch eine aktuelle JVM voraussetzt. Oder es kommt RDP zum Einsatz, so dass ein entsprechender Client vorhanden sein muss. Egal welche Variante präferiert wird: in jedem Fall steht damit eine große Auswahl 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 einzukalkulieren.

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

1. Die Basis für einen neuen virtuellen Desktops 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 sysprep.exe aus und erstellt damit das endgültige Desktop Image
4. Mittels Templates konfiguriert der Administrator die Eigenschaften der Desktops, z.B. die Menge an Arbeitsspeicher, angeschlossene Peripheriegeräte und weitere Eigenschaften
5. Auf Basis des Templates und des zugrundeliegenden Desktop-Images werden pro Anwender virtuelle Desktops dynamisch verteilt. Technisch handelt es sich um eigenständige VMs, welche aus dem Desktop Image geklont werden (linked clones).

Die eigentliche Flexibilität entsteht aus der Fähigkeit, aus einem 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 zur 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, zum Beispiel:

• Die VM im selben Storage liegen wie die Kaviza-Server-VM selbst;
• es 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 eine aktivierte Lizenzierung auf Basis einer Volumen-Lizenz zwingende Voraussetzung;
• RDP-Zugriff muss möglich, der HDX-Port freigeschaltet sein, der Administrator muss ein aktives Konto besitzen;
• der Windows-Patch KB 976494 muss installiert sein.

Hat der Administrator die Ur-VM derart vorbereitet, kann er in der Kaviza-Web-Konsole die Generierung der Desktop-Umgebung beginnen:

1. In der Ur-VM die benötigten Applikationen installieren und in Kaviza importieren
2. den Kaviza Desktop Agent (kDA) in der Ur-VM installieren
3. mit der Prepare-Funktion den Sysprep-Vorgang im "working image" anstoßen
4. anschließend Konnektivität zur VM prüfen mittels RDP-Verbindung
5. dann das Working Image als Desktop-Image speichern
6. Templates für den künftigen virtuellen Desktop definieren, dabei das generierte Desktop-Image als Basis wählen
7. Benutzer und Benutzergruppen anlegen und diesen die Templates zuweisen
8. Anschließend kann die Provisionierung der Desktops beginnen.

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 (in Schritt 5) oder später nicht deployed wird. In einer künftigen Version soll der Administrator ausführlicher informiert werden.

Als Best Practice ist es sehr empfehlenswert, nach der Erstellung einer "gültigen" Ur-VM diese quasi als Golden Kaviza Master sofort zu klonen (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 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 Authentifizierung.

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

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. Für ein künftiges Release ist geplant, diese Parameter abhängig von der Tageszeit vordefinierbar zu machen, um so beispielsweise für Stoßzeiten eine größere Desktop-Population vorzusehen als zu anderen Zeiten.

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.

Desktop-Management

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 verteilen.

Um Veränderungen in einem Desktop zu aktivieren oder diesen auf die letzte unveränderte Version zurückzusetzen, stehen unterschiedliche Policies zur Verfügung:

• Nach User-Logout
• Zeitsteuerung
• Manuell, d.h. zum Zeitpunkt der Auslösung durch Admin

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.

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, das eine RDP-Komponente 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.

Für eine gute Bildschirmauflösung und Tonqualität sorgt Citrix HDX (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 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 erwähnen ist, dass das von Kaviza mitgelieferte Internet-Gateway, das 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. Kaviza empfiehlt hier das Produkt Citrix Access Gateway.

Kaviza Grid

Kaviza liefert auf Wunsch ein Hochverfügbarkeits-Setup inklusive Load-Balancing. Templates und Images werden im Grid automatisch auf die beteiligten Kaviza-Server repliziert. Existieren mehrere virtualisierte Server mit installiertem Kaviza-Server, 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 Load-Balancer 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.

Um Kaviza zu administrieren, kann der Administrator dabei eine Verbindung mit einem beliebigen Kaviza-Server im Grid hergestellen.

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

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

Fazit

Kaviza ist auf kleinere bis mittlere Unternehmen und an Managed Service Provider ausgerichtet. Es liefert ein schnell zu installierendes VDI-System "out-of-the-box". Der Einstieg in zentrale Desktops gelingt damit vergleichsweise 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 dennoch gebotene Hochverfügbarkeit. Insgesamt gelingt damit der Spagat zwischen geringen Ansprüchen an die Umgebung, hoher Leistung und moderaten Kosten.

An die Administratoren werden trotz allem recht hohe Ansprüche gestellt. Zum einen sollte das Thema Server-Virtualisierung bereits etabliert sein, 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-Akzeptanz.

VDI-Einsteiger müssen bedenken, dass die Virtualisierung der PCs alleine 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 weitestgehend unabhängig vom Endgerät und von der Desktop-Session. Kaviza bringt jedoch keine Techniken zum Management der User-Profile und zur Virtualisierung der Applikationen mit. Darum müssen sich Kaviza-Anwender zur Zeit noch selbst kümmern – mithilfe von Drittprodukten.

Vorteile:

• Deutlich geringere Kosten als der Wettbewerb
• Einfache Inbetriebnahme durch Box-Charakter (virtuelle Appliance)
• Großer Funktionsumfang
• Unterstützt verschiedene – auch kostenfreie – Hypervisor

Nachteile:

• Web-Oberfläche nicht optimal umgesetzt, teilweise unübersichtlich
• Bei der Image-Generierung auftretende Fehler werden nicht angezeigt, der Prozess hängt dann, und der Administrator erhält keinen Hinweis auf die mögliche(n) Ursache(n)

Preise

Konkurrierende Lizenzen können für 100 Euro pro Desktop erworben werden (ab 50 Stück greifen vergünstigte Staffeln). Ist HDX gewünscht, erhöht das den Lizenzpreis um weitere 28 Euro - eine für die meisten Anwender lohnenswerte zusätzliche Investition. Hinzu kommen Wartung und Support für die ersten 12 Monate: € 20 je Desktop plus € 6 je HDX-Nutzer.

Systemvoraussetzungen

Kaviza kommt auf der Server-Seite mit Standard-Hardware aus und benötigt als Hosting-Umgebung kostenlose oder kostengünstige Hypervisor-Produkte: Citrix XenServer 5.6 (Free Edition) oder VMware ESX oder ESXi 4.

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)

Verfügbarkeit

Die in Kalifornien ansässige Firma wird im deutschsprachigen Raum durch wiora Software Partners GmbH repräsentiert. Eine kostenfreie 30-Tage-Testversion kann von der Hersteller-Website heruntergeladen werden.

Ein weiterer Kaviza-Partner in Deutschland ist Matrix42, das VDI-in-a-Box nicht nur vertreibt, sondern auch in Projekten implementiert. Zudem hat die Firma von Kaviza bereitgestellte virtuelle Desktops in seinen Service Catalog integriert, so dass sie Anwender nach dem Vorbild eines App-Store selbst auswählen und einsetzen können.