Zentralisierung, Virtualisierung, Streaming - Teil 1
Application Delivery im Überblick
Der Markt bietet zahlreiche Methoden der Application Delivery (Anwendungsbereitstellung) für Windows-Applikationen. Jede dieser Methoden weist Vor- und Nachteile auf, keine eignet sich für alle Anwender gleich gut. Dieser zweiteilige Beitrag befasst sich deshalb mit den Lösungsvarianten zentralisierter Anwendungsbereitstellung. Er gibt einen Überblick über heute verfügbare Techniken und beleuchtet deren Praxisrelevanz. Dieser erste Teil stellt die klassische Softwareverteilung dem Server-based Computing gegenüber, während Teil zwei in der Folgeausgabe der LANline sich dem Hype rund um Streaming- und Virtualisierungstechniken widmen wird.
Heute wird die Unternehmens-IT mehr denn je daran gemessen, welchen messbaren Wertbeitrag sie
zum Unternehmenserfolg erbringt. In dieser Betrachtung spielt die wirtschaftliche Bereitstellung
der Anwendungen eine entscheidende Rolle. Der Aufbau und Betrieb einer robusten und verlässlichen
Plattform zur effizienten Bereitstellung von Anwendungen (Application-Delivery-Plattform) stellt in
diesem Zusammenhang eine der größten Herausforderungen für die IT-Abteilung dar.
Sie muss zahlreiche Arten von Anwendungen für verschiedene Anwendergruppen über diverse
Zugriffswege zur Verfügung stellen und dabei wichtige Anforderungen erfüllen. Die
Application-Delivery-Plattform eines Unternehmens muss daher folgenden generellen Anforderungen
gerecht werden:
anwenderfreundlich und anpassbar,
kosteneffizient und wirtschaftlich,
abgesichert gegen Sabotage, Spionage und Datendiebstahl,
hoch verfügbar und zuverlässig,
flexibel und skalierbar,
beherrschbar durch möglichst geringe Komplexität.
Zudem muss sie in der Lage sein, folgende drei Benutzergruppen mit Anwendungen zu versorgen:
Task-Worker arbeiten mit einer geringen Anzahl von gleichartigen Anwendungen und haben geringere
Anforderungen an die Arbeitsumgebung. Knowledge-Worker arbeiten mit einer Vielzahl verschiedener
Anwendungen in beliebiger Kombination und benötigen dafür teilweise Administrationsrechte für ihre
Systemumgebungen. Power-User arbeiten mit verschiedensten, teils ressourcenintensiven Anwendungen
in beliebiger Kombination Sie benötigen in aller Regel administrative Rechte für ihre
Systemumgebung.
Anwendungen und Anwender
Eine weitere Herausforderung ist die Anwendermobilität. Man unterscheidet hier grundsätzlich
drei Anwendertypen:
Stationäre Anwender arbeiten ausschließlich im Büro.
Mobile Anwender arbeiten ausschließlich aus der Ferne.
Hybride Anwender arbeiten sowohl im Büro als auch remote.
Mit einer Application-Delivery-Plattform gilt es, folgende Anwendungsformen bereitzustellen:
lokale Anwendungen (Word, Excel, Powerpoint etc.),
hybride Anwendungen mit Schnittstellen zu anderen Anwendungen und lokalen
Datenrepliken (Outlook, Lotus Notes etc.),
Client-/Server-Anwendungen (Business-Applikationen für ERP, CRM etc.) und
Webanwendungen (mit zentralem Web- und Datenbankserver).
Zur effizienten und wirtschaftlichen Bereitstellung dieser Anwendungen sind verschiedene
Strategien und Techniken verfügbar, die sich teilweise in ihrer Methodik grundsätzlich
unterscheiden, jedoch in Kombination optimale Lösungen bieten. Einige der Techniken sind seit
Jahren etabliert und können eine Vielzahl von Referenzen vorweisen. Andere wiederum sind brandneu,
auf der Spitze der Gartner-Hype-Kurve und müssen sich entweder noch beweisen oder verschwinden
unbemerkt von der Bildfläche. Allen gemein ist jedoch dasselbe Ziel: die zentrale Bereitstellung
von Anwendungen über den gesamten Lebenszyklus.
Strategien und Techniken
Die Bereitstellung von Anwendungen kann über zwei grundverschiedene Lösungsansätze erfolgen:
über die lokale Installation oder den serverbasierten Anwendungsbetrieb. Für das Deployment von
Anwendung, die von der Festplatte des lokalen Endgeräts geladen und ausgeführt werden, existieren
drei Ausprägungen:
Der erste und offensichtliche Weg: Die Anwendung wird manuell auf den Endgeräten installiert und
über das lokal installierte Betriebssystem ausgeführt (also die altbekannte "
Turnschuhadministration"). Die bekannte Alternative: Anwendung wird mittels einer Verteilsoftware
auf die Endgeräte kopiert, installiert ("push") und der Installationsprozess dort manuell oder
automatisch eingeleitet. Im Anschluss ist die Anwendung über das lokal installierte Betriebssystem
ausführbar (Electronic Software Distribution, ESD).
Eine neuerdings oft propagierte weitere Alternative: Das Endgerät lädt die Anwendung mittels
Streaming (Echtzeitübermittlung von einer entfernten Quelle) in den Cache einer lokal installierten
Laufzeitumgebung ("pull") und führt die Applikation hier aus. Dabei sorgt ein "Abstraction Layer"
(Abstraktionsschicht) innerhalb der Laufzeitumgebung dafür, dass die Anwendung vom Betriebssystem
isoliert abläuft, um Konflikte zu vermeiden (Application Streaming und Application
Virtualization).
Eine weit verbreitete Alternative besteht darin, die Anwendung auf einem zentralen
Windows-Server auszuführen. Die Übermittlung der grafischen Benutzeroberfläche (GUI) sowie der
Tastatur- und Mauseingaben erfolgt über ein spezielles Terminal-Protokoll (zum Beispiel Microsofts
RDP oder Citrix? ICA). Auf dem Endgerät ist entsprechende Terminal-Software erforderlich (RDP- oder
ICA-Client). Es lassen sich dabei drei Ansätze des zentralen Computings unterscheiden:
Erstens kann ein mittels Terminal-Services-Funktion mehrbenutzerfähiger Windows-Server mehrere
Windows-Sitzungen mit Anwendungen zentral bereitstellen (Server-based Computing, SBC). Die
Windows-Anwendungen muss der Administrator manuell, per Imaging oder mit einer ESD-Lösung auf dem
Server oder den Servern installieren und konfigurieren. Dabei sind die Terminal-Services des
Win-dows-Servers aktiviert, oft ist zusätzlich die Erweiterung Citrix Presentation Server (CPS)
installiert.
Zweitens lassen sich mittels Virtualisierung (Vmware ESX-Server, MS Virtual Server, Virtuozzo
oder XEN) innerhalb der virtuellen Maschinen Windows-XP- oder Vista-Desktops starten. Der Zugriff
erfolgt wie beim SBC über das RDP- oder ICA-Protokoll. Die serverseitige Windows-Software ist
entweder manuell, per Imaging oder mit einer ESD-Lösung auf dem Server zu installieren und zu
konfigurieren (die so genannte Virtual Desktop Infrastructure, VDI. Den Begriff VDI hat Vmware
geprägt, aber mittlerweile verwenden ihn auch andere Hersteller.)
Citrix propagiert seit kurzem eine dritte Lösung: Per ICA-Client greift der Anwender hier auf
einen zentralen Dienst zu (Citrix Desktop Broker oder Citrix Desktop Server), der zusätzlich auf
einem CPS ins-talliert ist. Je nach Konfiguration verbindet der Dienst den Anwender mit einer
Terminalserver-Sitzung, einem via VDI gehosteten XP-/Vista-Desktop oder einem dedizierten PC mit
aktiviertem Remote-Sitzungsprotokoll (Dynamic Desktop Infrastructure, DDI). DDI lässt sich daher
als Mischform der beiden zuvor genannten Varianten bezeichnen.
Welche der beschriebenen Lösungen ist nun die beste? Ein guter IT-Berater würde sagen: "Es kommt
darauf an." Und tatsächlich hat jede der Methoden ihre Stärken und Schwächen. Es kommt also in der
Tat darauf an, welche Anforderungen es zu erfüllen gilt. Deshalb treten die Lösungen oft parallel
auf. Das Problem: Je mehr Application-Delivery-Methoden ein Unternehmen parallel einsetzt, desto
komplexer wird die Verwaltung insgesamt (Bild 1)
Softwareverteilung versus SBC
Die automatisierte Installation von Anwendungen auf lokalen Desktops über das Netzwerk mittels
ESD ist heute im Markt sehr stark verbreitet. Ein zentrales Management-Tool verwaltet die gesamte
Softwarekonfiguration (Betriebssystem, Anwendungen und Benutzereinstellungen) jedes Endgeräts in
einer Datenbank. Vor der eigentlichen Installation auf dem Endgerät (PC) ist die Anwendung zu
paketieren, also in ein verteilfähiges Format zu überführen. Der Prozess des Paketierens ist
aufwändig, zeit- und Know-how-intensiv. Nachdem ein Anwendungspaket fertig gestellt ist, sollte es
zunächst in einer Testumgebung validiert werden, bevor es in der Produktivumgebung zum Einsatz
kommt.
Aus Bild 2 ist ersichtlich, dass beim ESD-Einsatz fehlerhafte Anwendungspakete und Probleme in
der Rollout-Phase zu einem zusätzlichen Aufwand durch erneute Tests und die Fehlersuche führen. Bei
jedem Rollout sind zirka 15 Prozent (Industriedurchschnitt) der Anwendungspakete aus verschiedenen
Gründen nicht zu installieren. Dies macht einen individuellen Nachversand der fehlerhaften oder
nicht installierbaren Pakete beziehungsweise eine punktuelle Fehlersuche am Endgerät notwendig. Für
jede Softwareinstallation und jedes Update muss der Administrator vorab die notwendigen Pakete
erstellen, um dann den Verteilprozess erneut zu starten.
Im Rahmen einer modernen Application-Delivery-Strategie ermöglicht ESD die Bereitstellung jeder
beliebigen Anwendung auf den Endgeräten. Da die Software auf der lokalen Festplatte installiert
wird, kann die IT-Abteilung jeder Anwendergruppe und jedem Anwendertyp seine individuelle
Softwarekonfiguration zur Verfügung stellen. Diese Flexibilität hat jedoch auch ihren Preis:
Fehleranfälligkeit, Komplexität und Zeitaufwand. Um die Fehleranfälligkeit und damit die Zahl der
Softwarekonfigurationen möglichst gering zu halten, versucht man bei ESD, Gruppen von
Anwenderprofilen zu definieren. Zu den weit verbreiteten ESD-Suiten zählen Lösungen von Microsoft,
Altiris, Landesk und Novell.
Das SBC-Modell ermöglicht die zentrale Bereitstellung von Anwendungen über den Windows
Terminalserver. Diesen ergänzt in über 90 Prozent aller Installationen der Citrix Presentation
Server, der wichtige zusätzliche Funktionen für die Bereitstellung von Anwendungen bietet. Das
Besondere am SBC ist, dass eine Applikation nicht für jeden Anwender einzeln, sondern lediglich
einmal pro Server installiert und im Shared User Mode ausgeführt wird.
Zur Gewährleistung der Funktion müssen die Anwendungen auf Basis der Programmierrichtlinien von
Microsoft entwickelt sein. Da dies nicht bei jeder Anwendung der Fall ist, können Probleme bei der
Lauffähigkeit bestimmter Anwendungen auf Terminalservern auftreten. In vielen Fällen lassen sich
diese Probleme durch entsprechende Konfigurationen beheben. Bei besonders problematischen Fällen
bietet CPS die Möglichkeit, eine Anwendung über einen Silo zu separieren und so in einer isolierten
Umgebung oder auf einem separaten Server zu betreiben. Die Folgen sind ein Mehraufwand bei
Systemmanagement und Betrieb sowie erhöhte Komplexität und Kosten der Anwendungsbereitstellung.
Seit CPS Version 4.0 liefert Citrix eine Zusatzfunktion zur Isolation problematischer Anwendungen:
das Application Isolation Environment (AIE). Funktional wird die Anwendungsisolierung durch eine "
Teilvirtualisierung" der Anwendung auf dem Terminalserver erreicht.
Sofern keine Konflikte zwischen den Anwendungen auftreten, lassen sich Anwendungen über den
SBC-Ansatz sehr einfach, schnell und effizient einer großen Anzahl von Anwendern zur Verfügung
stellen. Man sollte sich jedoch darüber im Klaren sein, dass sich die Komplexität der Umgebung vom
installations- und wartungsfreien schlanken Endgerät zum "full-featured" zentralen Server
verlagert. Der Komplexitätsgrad einer SBC-Umgebung wächst mit der steigenden Anzahl der Anwendungen
und Anwendertypen. Ab einer bestimmten Größe ist der Betrieb nur noch mit leistungsfähigen
Managementwerkzeugen zu bewältigen. Besonders problematisch sind Power-User, da sie die Performanz
der Systemumgebung negativ beeinflussen und andere Anwender dadurch in Mitleidenschaft ziehen
können.
Terminalserverumgebungen eignen sich hervorragend für eine Vielzahl gleichartiger Task- oder
Knowledge-Worker, die unabhängig von Ort und Endgerät auf zentral bereitgestellte Daten und
Anwendungen zugreifen können. Je nach Leistungsfähigkeit der Hardware können auf einem
Terminalserver bis zu 60 Anwender flüssig arbeiten.
Bei größeren Serverfarmen sollte Citrix‘ wichtige Load-Balancing-Option zum Einsatz kommen. Zur
Gewährleistung eines stabilen Betriebs ist jedoch dafür zu sorgen, dass die Server nahezu identisch
installiert sind. Dies lässt sich nur durch eine Automation des Installationsprozesses
sicherstellen. Deshalb sollte ein Administrator eine Umgebung mit mehr als fünf Terminalservern
nicht mehr manuell installieren, sondern wiederum auf ESD zurückgreifen. Änderungen an der
Systemumgebung sollten im Vorfeld immer in einer Testumgebung verifiziert und erst im Anschluss in
der Produktivumgebung eingesetzt werden: Leichtsinnigkeit schmerzt bei zentralen Umgebungen viel
mehr, denn meist sind von Fehlern nicht nur einzelne Anwender, sondern gleich ganze Anwendergruppen
betroffen.
Lesen Sie mehr zum Thema
