Mittels Desktop-Virtualisierung werden den Nutzern virtuelle Desktops schnell und vollautomatisiert bereitgestellt. Beim Anwender selbst soll sich durch den Umstieg auf einen virtuellen Desktop zunächst einmal nichts ändern. Er benötigt die gleichen Rechte und Möglichkeiten, die er von seinem herkömmlichen PC gewohnt ist. Der Vorteil: Er kann seinen Desktop jetzt flexibler nutzen, weil er von überall darauf zugreift, sei es vom Nachbarbüro, von zu Hause oder von unterwegs - vorausgesetzt eine Netzwerkanbindung ist vorhanden.
Zudem erlaubt die Desktop-Virtualisierung eine freie Auswahl an Endgeräten. So lassen sich vorhandene PCs einfach weiternutzen. Dafür wird ein abgespecktes und somit wartungsarmes Betriebssystem installiert, das die Verbindung zum virtuellen Desktop aufbaut und aufrecht hält. Parallel dazu können Unternehmen sukzessive Thin Clients einführen und bei Neubeschaffungen direkt kostengünstigere Geräte kaufen.
Die Server-Virtualisierung hat such zunehmend als feste Größe in den Rechenzentren etabliert. Deshalb rückt in der logischen Konsequenz zunehmend die Virtualisierung von Desktops in den Vordergrund der IT-Verantwortlichen. Denn auch hier versprecht die Theorie ähnliche Vorteile wie für die Server. Aus diesem Grund haben wir die Desktop-Virtualisierungslösung Kaviza VDI-in-a-box unter die Lupe genommen.
Ü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:
-
Das gesamte Management erfolgt über den Kaviza Manager, dieser wird als Virtuelle Appliance für VMware ESX(i) oder Citrix XenServer auf Standard-Hardware bereitgestellt. Über den Manager werden virtuelle Desktops erstellt, gesteuert und an die Benutzer publiziert.
-
Jeder Virtuelle Desktop verfügt über einen 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 greifen entweder per RDP-Client zu oder nutzen das Kaviza Java-Applet, um sich mit ihrem Virtuellen Desktop zu verbinden. Unterstützt werden Windows, Linux/Unix und Mac OS sowie diverse ThinClients (zum Beispiel Wyse, sowie solche die Java oder Browser ausführen können). Mittels Citrix Receiver gelangt der Kaviza-Desktop zudem auf eine Fülle weiterer Endgeräte-Typen wie iPhone, iPad, Android. Zusätzlich steht optional Citrix HDX zur Verfügung.
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 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:
-
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 Speicher 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 den RAM.
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
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:
-
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).
-
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!
-
Der Kaviza Manager führt im Working Image einen Sysprep-Vorgang durch und erstellt dabei das endgültige Desktop Image.
-
Mittels Templates konfiguriert der Administrator die Eigenschaften der Desktops, wie Menge an Arbeitsspeicher, angeschlossene Peripheriegeräte und weitere Eigenschaften.
-
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.
Virtuelle Desktops erzeugen
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.
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 (zum Beispiel. 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, wie viele 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, wie viele Ressourcen des Servers beziehungsweise Hypervisors Kaviza inklusive der laufenden Desktops nutzen darf und zeigt dies in einem Auslastungsbalken je Server im Grid an.
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/
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 Load Balancing. 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 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.
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 Euro 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 Euro - eine für die meisten Anwender sehr lohnenswerte Investition.
Hinzu kommen Wartung und Support für die ersten 12 Monate: 20 Euro je concurrent Desktop plus 6 Euro je HDX-Nutzer. Eine kostenfreie 30-Tage-Testversion kann von der Hersteller-Website heruntergeladen werden.
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 zum Beispiel. 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:
-
Hohe Anfangskosten, da hohe Anforderungen an die gesamte Umgebung gestellt werden, Kostentreiber ist vor allem der benötigte zentrale 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, Loadbalancing, Hochverfügbarkeit, Connection Broker usw.
-
Benutzererfahrung: Viele der verwendeten Protokolle schränken die Anwendungsmöglichkeiten für Benutzer ein. Multimediage-lastige Anwendungen oder der Einsatz von VoIP an solchen Arbeitsplätzen scheidet zum Teil aus. Ein weiterer Nachteil ist die fehlende Möglichkeit zur Offline-Nutzung des virtuellen Desktops. Im ungünstigen Falle verursachen virtualisierte Desktops sogar höhere Kosten als die alte Fat Client Armada, wobei dann unter Umständen obendrein noch die Probleme der konventionellen Desktop-Umgebung ins Data Center verlagert werden.
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 (zum Beispiel 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:
Gelungene Umsetzung des Gesamt-Produkts
Deutlich geringere Kosten als der Wettbewerb
Einfache Inbetriebnahme durch Box-Charakter (virtuelle Appliance)
Großer Funktionsumfang
Unterstützt verschiedene - auch kostenfreie - Hypervisor
Contra:
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öglichen Ursachen.
(hal)
Dieser Artikel basiert auf einem Beitrag unserer Schwesterpublikation Computerwoche.