SDI statt VDI
Tücken der Desktop-Virtualisierung
Der Virtualisierungsexpress rollt und rollt, und nichts scheint ihn aufhalten zu können. Nachdem gefühlt bereits die Hälfte aller Server nur noch virtuell existiert - real dürfte der Wert eher bei zehn Prozent liegen - heißt der nächste Stopp nun Desktop-Virtualisierung oder Virtual Desktop Infrastructure (VDI). Doch ab dort muss der Schnellzug so viele Passagiere befördern, dass er zu einem dampfgetriebenen Bummelzug zu verkommen droht.
So attraktiv der Gedanke ist, nun auch den Desktop in die Obhut der Mitarbeiter im Rechenzentrum
zu geben: Diese Technik hat nicht nur Vorteile. Die Streaming Desktop Infrastructure verspricht
eine bessere Ausnutzung der Ressourcen bei ebenfalls zentralisiertem Management. Wer VDI sagt,
meint meist die Überführung der Desktop-PCs in virtuelle Maschinen, einschließlich aller
Anwendungen und individuellen Einstellungen. Der physische Desktop ist dabei auf die Rolle eines
simplen Sichtgeräts reduziert. Insgesamt ähnelt eine VDI damit den klassischen
Mainframe-Umgebungen.
Wie beim Mainframe kann die Konzentration der Desktops in zentrale VMware, Xen- oder
Hyper-V-Umgebungen Probleme bei der Interoperabilität und der Skalierbarkeit vermeiden, und die
Verwaltung der gesamten Infrastruktur verspricht erheblich leichter zu werden. Durch die
Virtualisierung sind dabei zudem die Workloads einzelner Benutzer strikt voneinander getrennt.
Probleme bei einem virtuellen Desktop schlagen daher anders als beim Mainframe nicht auf die
anderen Anwender durch.
Doch wird die Cloud tatsächlich dazu führen, dass wir die gesamte IT-Infrastruktur
entmaterialisieren? Nicht jeder ist bereit, wieder auf den Mainframe zu setzen, nur weil er sich in
der aktuellen Generation als Wolke verkleidet hat. Denn wenngleich die Arbeitsumgebungen der
einzelnen Mitarbeiter in Form virtueller Maschinen sauber voneinander getrennt sind, nutzen doch
alle die gleichen physischen Ressourcen. Um hier auch in Spitzenzeiten akzeptable Antwortzeiten zu
gewährleisten, ist eine sehr großzügige Auslegung der Server-Systeme erforderlich. Zudem ist die
vorhandene Hardware sehr ungleichgewichtig ausgelastet: Während auf dem Server und im Netzwerk
Hochbetrieb herrschen, langweilen sich die CPUs der Clients bei minimaler Auslastung, lokale
Grafikprozessoren sind gar völlig arbeitslos. Green IT sieht anders aus. Hinzu kommt, dass die
Skalierung zwar prinzipiell unproblematisch, aber teuer ist. Müssen hundert neue Arbeitsplätze
hinzugefügt werden, zahlt man für die Rechenleistung gleich doppelt: Einmal bei den Clients, deren
Prozessoren nicht genutzt werden, und einmal bei einem teuren Server-Upgrade.
Eine gängige Alternative zur kompletten Virtualisierung der Desktop-Infrastruktur ist die
zentrale Verwaltung von Disk-Images. Damit ist gewährleistet, dass Patches und Updates kontrolliert
und einheitlich erfolgen und kein wartungsintensiver Wildwuchs entsteht. Meist kann zudem eine
größere Anzahl von Desktops mit identischen Images arbeiten, was die Standardisierung unterstützt
und die Wartungskosten weiter reduziert. Lokale Ressourcen wie CPU und RAM werden intensiv genutzt,
und die potenzielle Überlastung von Server-Ressourcen lässt sich vermeiden. Allerdings ist es nach
jedem Patch und jeder sonstigen Änderung erforderlich, das komplette Image über das Netzwerk an die
jeweiligen Client-PCs zu übermitteln. In Netzwerken mit Tausenden von Clients summiert sich das
schnell zu TBytes – damit sind auch leistungsstarke LANs überfordert. Hinzu kommt, dass in größeren
Umgebungen trotz des Einsatzes einschlägiger Deployment-Tools meist doch eine ganze Reihe von
Systemen im Management-by-Turnschuh-Verfahren aktualisiert werden müssen. Lokale
Betriebssystem-Installationen sind zu guter Letzt auch genau das Gegenteil der überall angestrebten
Datendeduplizierung: Tausende identischer Datenbestände verschwenden Massenspeicherplatz, obwohl
eigentlich einer für alle ausreichen würde.
Lokale Ressourcen nutzen
Als Kompromiss zwischen einer kompletten Virtual Desktop Infrastructure und dem aufwändigen
Management lokaler Betriebssysteminstallationen bietet sich eine neue Technik an, die als Streaming
Desktop Infrastructure (SDI) bezeichnet wird. SDI ermöglicht wie VDI die effiziente Verwaltung der
gesamten Desktop-Infrastruktur und die Zentralisierung von Workloads, sprich Betriebssystem,
Anwendung und Daten. Allerdings treten die wesentlichen Nachteile nicht auf, da in diesem Fall zur
Verarbeitung die lokalen Ressourcen der Desktop-Systeme dienen. Alles, was die Komplexität einer
Desktop-Installation ausmacht, ist dagegen zentral administriert.
Eine Streaming Desktop Infrastructure basiert auf dem so genannten OS Streaming, einer
Technik, bei der das Desktop-System von einem Image im Netzwerk bootet anstatt von seiner eigenen
Festplatte. Anders als bei der Distribution von Images über das Netz werden dabei nur die
Komponenten des Betriebssystems übertragen, die der Client tatsächlich benötigt. Bei Windows XP
sind dies typischerweise etwa 80 MByte, bei Windows 7 liegt der Wert bei 130 MByte. Bei einem Test
der -Gakushuin Universität in Tokyo mit der SDI-Software Flex von Double-Take benötigten 200
gleichzeitig startende XP-Clients im Durchschnitt 40 Sekunden für den Boot-Vorgang. Das Booten aus
dem Netzwerk dauert also nicht länger als von einer lokalen Festplatte. Dabei können multiple
Clients vom gleichen Image booten.
Der Einsatz von Boot-fähigen Images im Netzwerk führt bereits bei der Einbindung eines neuen
Systems zu großen Vereinfachungen. Im BIOS muss lediglich das Netzwerk als erstes Bootmedium
eingestellt werden, und in einer zentralen Management-Konsole ist dem neuen System ein vorhandenes
Image zugeordnet. Dabei kann dann auf eine lokale Festplatte verzichtet werden – ein wesentlicher
Beitrag zur Deduplizierung wie zur Green IT.
Abgestürzte oder durch Viren verseuchte PCs sind in Sekunden repariert, dazu reicht ein
einfaches Aus- und wieder Einschalten. Dann bootet das Gerät vom geschützten Image und ist nach
wenigen Augenblicken wieder wie neu. Updates und Patches sind nur wenige Male zu installieren und
zu testen, nämlich an den Boot-Images. Schon beim nächsten Start sind dann alle Rechner wieder auf
dem neuesten Stand.
Flexible Konfiguration
Flexible Konfigurationsmöglichkeiten sind das A und O einer SDI-Implementierung. Flex von
Double-Take etwa basiert auf zwei Server-Komponenten, von denen eine die Verwaltung der Images im
SAN übernimmt (Storage Server) und die andere die Zuordnung der Images zu den einzelnen Desktops.
Diese Zuordnung erfolgt entweder über die MAC-Adresse oder über das Benutzerkonto. Dazu besitzt der
Management-Server eine Datenbank mit allen Benutzern, Systemen und iSCSI-Targets im SAN. Jedem User
oder System kann damit per Mausklick sein Boot-Image zugewiesen werden. Dabei besteht auch die
Möglichkeit, aus Redundanz-Gründen ein primäres und ein sekundäres Image auf verschiedenen
Storage-Systemen zu definieren. Schließlich kann der Ausfall eines Targets unter Umständen dazu
führen, dass Hunderte von Desktop-Systemen nicht booten können. Bei Bedarf kann Flex auch so
konfiguriert werden, dass der Anwender zunächst ein Boot-Menü angezeigt bekommt und selbst
entscheiden kann, welche Konfiguration er gerade benötigt. Bei Bedarf kann Flex zum Speichern der
Images auch ein iSCSI-San auf einem Windows Server emulieren.
Je nach Anwendungsbereich unterscheidet Flex vier verschiedene Arten von Boot-Images:
Exclusive,
Concurrent,
Shared (persistent) und
Shared (non-persistent).
Will man einem System oder User dauerhaft ein dediziertes Image zuweisen, wird dieses im
exklusiven Modus betrieben. Alle Schreibvorgänge finden direkt auf dem Image statt – wobei das
lokale RAM oder die Festplatten als Schreib-Cache dienen können. In Cluster-Umgebungen kann man die
Images im gleichzeitigen "Concurrent" Zugriff bereitstellen – dort steuert der Cluster-Dienst den
Zugriff.
Mehrwert durch Images
Ein richtiger Mehrwert im Bezug auf Desktop-Optimierung entsteht jedoch erst dann, wenn man
ein Master-Image mehreren Systemen gleichzeitig zur Verfügung stellt. In diesem Fall booten alle
Systeme vom gleichen (schreibgeschützten) Image, während alle Schreibzugriffe in einen dedizierten
Schreib-Cache umgeleitet werden. Dieser kann nach einem Neustart erhalten bleiben (persistent) oder
verworfen werden (non-persistent). Mit persistenten Images lassen sich standardisierte Boot-Images
sehr einfach individualisieren, jedoch gehen bei einem Update des Master-Images alle individuellen
Änderungen verloren. Besonders in größeren Umgebungen, Trainingsräumen oder Kiosk-PCs ist es
empfehlenswert, die Images im nicht-persistenten Modus zu betreiben, da sämtliche Änderungen bei
einem Neustart verworfen werden und die Anwender stets ein "sauberes" Betriebssystem zu Gesicht
bekommen – was die Kosten für den Anwendersupport enorm reduzieren dürfte.
Einsatz in Trainingsumgebungen
In Trainingsumgebungen sind gerade die Vorteile der nicht-persistenten Images erwünscht,
wobei man in Produktivumgebungen die Anwendungsbezogenen Einstellungen (Signaturen, Favoriten,
Eigene Dateien etc.) möglichst erhalten will. Eine Möglichkeit dazu sind Windows-Bordmittel wie
Group-Policies oder Roaming Profiles.
Diese haben allerdings den Nachteil, dass sie meist zu unflexibel oder gerade in größeren
Umgebungen schwer zu administrieren sind. Alternativlösungen wie das in Flex integrierte RES
Powerfuse bieten komfortablere Optionen, die die granulare Speicherung aller wichtigen
Applikationsdaten im Netzwerk ermöglichen So besteht keine Gefahr, dass diese bei einem Neustart
verloren gehen. Zudem kann man auf Objektebene (User/Gruppen/OUs) den Zugriff auf Anwendungen
steuern. Man kann die Anzahl der benötigten Flex Images minimieren, indem man ein Image mit allen
Anwendungen zur Verfügung stellt – die Anwender sehen dann nur die Applikationen, für die sie
berechtigt sind.
Sven Wolf ist Technical Manager DACH bei Double-Take Software.
Lesen Sie mehr zum Thema
