Anwendungen in der Private Cloud bereitstellen
Komplexer, als man denkt
Viele Unternehmen stellen den Benutzergruppen Anwendungen auf unterschiedliche Weisen bereit. So trifft man auf lokal auf dem Fat Client (PC) installierte und gestreamte, zentral via Windows Terminal-Server oder Citrix Xenapp bereitgestellte sowie Web-basierte Anwendungen, die im Web-Browser entweder lokal auf einem Fat oder Thin Client oder via Terminal-Services laufen. In jüngster Zeit erweitert das Konzept der virtuellen Desktops den Reigen der Techniken. Was ist hier zu beachten?
Dank Desktop-Virtualisierung ist es möglich, auch ohne WTS/Xenapp komplette Desktops auf Basis
virtueller Maschinen im sicheren RZ vorzuhalten. Dieser Ansatz bietet weitere Vorteile und macht
die zentrale Bereitstellung von Anwendungen nun auch für Unternehmen interessant, die sich bisher
mit der WTS-Technik nicht anfreunden konnten oder bei denen andere Gründe gegen die Zentralisierung
von Anwendungen sprachen. Über virtuelle Desktops lassen sich heute selbst exotische und scheinbar
unlösbare Anforderungen wie zum Beispiel der zentralisierte Betrieb komplexer und
ressourcenintensiver 3D-CAD-Anwendungen sicher umsetzen. Hersteller wie Microsoft, Citrix, VMware,
Kaviza und andere werben um die Gunst der Kunden und bieten auf Basis teils umfangreicher
Produktportfolios nahezu alle Möglichkeiten und Kombinationen zur Anwendungsbereitstellung.
Je nach IT-Strategie des Unternehmens, IT-Betriebsmodell und Art der Anwendung eignet sich der
eine oder andere Bereitstellungsansatz besser oder schlechter. Dies führt in manchen Unternehmen zu
einem schwer beherrschbaren Mix von Ansätzen, Techniken und Produkten. In den seltensten Fällen ist
dieser Mix effizient, kostentransparent und bei Veränderungen schnell an neue Anforderungen oder
Gegebenheiten anpassbar.
IT-Abteilungen werden mit permanent steigenden Anforderungen konfrontiert, Anwendungen
kosteneffizienter und sicherer zu liefern. Dabei soll man aber gleichzeitig schneller auf
Veränderungen reagieren. Etliche Unternehmen haben deshalb bereits vor geraumer Zeit damit
begonnen, die Bereitstellung der Unternehmensanwendungen auf Basis der WTS-Technik (meist in
Verbindung mit Citrix Xenapp) zu zentralisieren. Damit kehrten sie teilweise gleichzeitig dem
schwerfälligen und teuren Fat Client-Konzept den Rücken. Da viele Anwendungen jedoch für den
Einsatz auf einem Fat Client entwickelt wurden, erzeugt die Überführung der Anwendungen auf eine
zentrale Plattform einige konzeptionelle und technische Herausforderungen, die es zu lösen
gilt.
Die Begrifflichkeiten rund um die zentrale Bereitstellung von Anwendungen haben sich in den
letzten Jahren gleich mehrfach geändert: Begonnen bei "Server-Based Computing" über "Application
Delivery" spricht man heute von "Application Virtualization in der Private Cloud". Von einer "
Private Cloud" spricht man, wenn die Bereitstellung von Rechenleistung, Anwendungen, Storage und
Netzwerk zentral im unternehmenseigenen RZ auf der Basis der Virtualisierung sowie standardisierter
und hochautomatisierter Prozesse erfolgen.
Anforderungen
Weniger dynamisch als bei den Begrifflichkeiten ging es bei den Anforderungen zu. Hier gilt nach
wie vor in allen Projekten: Alle Anwendungen sollen weiterhin wie auf dem Fat Client funktionieren
und in der Lage sein, störungsfrei miteinander zu kommunizieren. Alle auf Basis einer zentralen
Plattform vorgehaltenen Anwendungen dürfen sich in Sachen Performance, Kompatibilität und
Funktionalität nicht von ihren lokal installierten Doubles auf einem Fat Client unterscheiden. Sind
sie nur mit eingeschränktem Funktionsumfang lauffähig, ist die Performance schlechter als zuvor,
oder können Anwendungen nicht mehr wie gewohnt miteinander dynamische Daten austauschen (über DDE,
OLE etc.), sind Zentralisierungsprojekte mangels Akzeptanz der Benutzer meist schon im Vorfeld zum
Scheitern verurteilt.
Gehen wir beispielhaft davon aus, dass im Rechenzentrum schon eine sauber strukturierte
Private-Cloud-Infrastruktur existiert, und konzentrieren uns daher auf die Anwendungsintegration.
Diese nimmt in Zentralisierungsprojekten gewöhnlich den größten Zeitraum ein, da eine Umstellung
von lokal auf zentral selten in einer Art "Big Bang" möglich ist. Deshalb werden Anwendungen oft
blockweise auf die neue zentrale Plattform migriert. Hier muss die IT-Abteilung großes Augenmerk
auf die Abhängigkeiten der Anwendungen von den Backend-Systemen und untereinander legen.
Problematischer Anwendungsmix
Nicht immer ist es sinnvoll, den Benutzern alle Anwendungen über die zentrale Plattform zur
Verfügung zu stellen. So verbleiben spezielle Anwendungen wie zum Beispiel Scanner- oder
CD-Brennersoftware auf dem Fat Client, da aufgrund einer Hardwareabhängigkeit eine Bündelung im RZ
nicht möglich ist. Aber auch zentralisierbare Anwendungen laufen auf einem zentralen System in
Verbindung mit anderen Anwendungen nicht immer störungsfrei. Deshalb werden zueinander kompatible
Anwendungen auf der WTS/Xenapp-Plattform in so genannten "Anwendungssilos" bereitgestellt. Jeder
Server des Silos enthält exakt dasselbe Spektrum von Anwendungen, die teilweise voneinander
abhängig sind und störungsfrei in den Sitzungen der Benutzer laufen können. Sitzungsintern können
die Anwendungen ungehindert miteinander kommunizieren, so wie man es vom Fat Client her kennt.
Office-Anwendungen können sich auf diese Weise gegenseitig dynamische Informationen einbetten,
Add-ons integrieren und mehr. Dies alles funktioniert nur innerhalb derselben WTS/Xenapp-Sitzung.
Lediglich die Anzeige der Bildschirmdaten erfolgt noch am Arbeitsplatz des Benutzers.
Die zentrale Bereitstellung aller Anwendungen aus einem einzigen Anwendungssilo heraus ist in
der Praxis aber leider nicht immer umsetzbar. Alles, was innerhalb eines Anwendungssilos nicht
harmoniert, muss der Administrator trennen, also in zwei oder mehr separaten Silos unterbringen. Es
soll jedoch erwähnt werden, dass die in der Vergangenheit gefürchtete "DLL-Hölle" heute nur noch in
seltenen Ausnahmefällen vorkommt. Mit einer qualitätsbewussten Anwendungspaketierung sind in großen
IT-Umgebungen mittlerweile Xenapp-Server mit über 400 installierten Anwendungen betrieben, ohne
dass sich die Anwendungen gegenseitig stören. Dadurch bleiben die typischen Probleme aus, die sich
bei der Trennung inkompatibler Anwendungen oft ergeben würden.
Cloud- und Browser-Basis
Bei Anwendungen, die man aus einer Public Cloud (also einem öffentlichen, aus externer Quelle
stammenden Cloud-Service) bezieht, handelt es sich überwiegend um Browser-basierte Anwendungen. Es
stellt sich nun die Frage, in welchem Browser die Cloud-Anwendung zum Einsatz kommen soll.
Anwendungen, die auf einem WTS laufen, werden zwar auf der Client-Seite angezeigt, aber tatsächlich
auf dem Terminal-Server ausgeführt. Soll die Cloud-Anwendung also Daten mit weiteren Anwendungen
eines Silos austauschen können, muss der Browser auf dem WTS Verwendung finden. Läuft die
Cloud-Anwendung jedoch ohne jegliche Abhängigkeiten, kann sie auch im lokalen Browser des Client
betrieben werden. Dies gilt es bei der Buchung von Public-Cloud-basierten Lösungen zu beachten.
Bei der Nutzung von Public-Cloud-Anwendungen ist zudem darauf zu achten, dass zwischen Browser
und Web-Server im Internet genügend Brandbreite zur Verfügung steht, um eine zufriedenstellende
Performance zu garantieren. Denn stockt es bei der Performance, ist die Anwenderzufriedenheit
schnell dahin.
Die restlichen wie auch die erwähnten peripherienahen Anwendungen sind lokal auf dem Fat Client
zu installieren. Für den effizienten Gesamtbetrieb ist der Anteil lokaler Anwendungen so gering wie
möglich zu halten. Idealerweise lässt sich der Fat Client dann durch einen energieeffizienten Thin
Client ersetzen, sodass nur noch sehr wenige Fat Clients im Unternehmen zu verwalten sind.
Automation und Standardisierung
Um Anwendungen automatisiert und standardisiert auf einer WTS/Xenapp-Plattform in einer
Virtual-Desktop-Umgebung zu installieren, ist der Einsatz von Paketierungs- und
Software-Deployment-Tools erforderlich. Bei der Erstellung der verteilenden Softwarepakete ist es
sehr wichtig, die speziellen Anforderungen des Terminal-Server-Umfelds bei der Paketierung zu
beachten.
Die für die Fat-Client-Welt erstellten Softwarepakete erfüllen oft nur teilweise die
Anforderungen einer Terminal-Server-Umgebung. Sie sind deshalb größtenteils anzupassen oder zu
erweitern, lassen sich also nicht 1:1 übernehmen, auch wenn sich dieser Wunschgedanke hartnäckig im
Markt hält. Je umfangreicher die zentrale IT-Plattform wird, desto sorgfältiger ist die
Softwarepaketierung durchzuführen, um später ein stabiles und performantes Gesamtsystem zu
erhalten.
Application Streaming
Ziel des Application Streamings mit Microsoft App-V, VMware Thinapp und anderen Lösungen ist die
Isolation problematischer Anwendungen, damit sie weiterhin mit geringen Einschränkungen auf
demselben Silo laufen können. Einschränkungen in der Kommunikation und der gegenüber einer normalen
Installation erhöhte Ressourcenbedarf senken speziell im Multi-User-Umfeld des WTS die
Gesamteffizienz. Daher sollte man das Application Streaming auf dem WTS nur anstreben, um Probleme
mit der normalen Installation einer Anwendung zu lösen. Weitere Probleme mit Application Streaming
können im Support-Fall auftauchen, wenn der Hersteller vorher nicht gefragt wurde, ob er überhaupt
das Streaming seiner Anwendung unterstützt. Dann besteht ein erhebliches Risiko, dass man ohne
Hersteller-Support dasteht. Für unternehmenskritische Anwendungen ist eine solche Prüfung daher
Pflicht.
Sofern sich eine Anwendung weder per Installation noch per Streaming im zentralen Anwendungssilo
(Hauptsilo) unterbringen lässt, wird üblicherweise ein eigener Sondersilo gebildet. Diese und
mitunter weitere Anwendungen laufen dann in einer zusätzlichen Terminal-Server-Sitzung des
Benutzers mit der Einschränkung, dass keine dynamische Verbindung zu den Anwendungen des Hauptsilos
möglich ist. Lediglich die statische Zwischenablage zwischen dem Client und den Terminal-Servern
ist zum Datenaustausch noch vorhanden.
Virtuelle Desktops
Alle oben genannten Methoden beziehen sich auf die Bereitstellung von Anwendungen auf einem
Windows Terminal-Server, da dies heutzutage immer noch die bevorzugte und kosteneffizienteste
Methode ist. Nahezu alle größeren Umgebungen mit zentralisierten Anwendungen laufen auf Basis des
WTS mit Xenapp. Hier punkten vor allem die Management-Funktionen von Xenapp. Sofern WTS/Xenapp
technisch nicht umsetzbar oder im Unternehmen nicht gewünscht ist, kann heute alternativ ein
virtueller Desktop mit Windows XP oder Windows 7 zur Lösung beitragen. Da das Prinzip der
virtuellen Desktops jedoch auf einer möglichst einheitlichen Konfigurationsbasis aufbaut, sollte
auch hier ein einheitliches Desktop-Umfeld geschaffen werden.
Virtuelle Desktops sind im Gegensatz zum WTS keine Multi-User-Plattformen. Sie stellen
stattdessen den Ersatz des bisherigen lokalen Desktops auf Basis einer zentralisierten virtuellen
Maschine (VM) dar. Wäre jedem Benutzer eine 1:1-Verbindung zu seinem eigenen individuellen Desktop
anzubieten, würde dies zu viel teuren Plattenplatz im zentralen RZ für die individuellen
Virtual-Desktop-Images erfordern. Daher gehört die Konsolidierung des Anwendungsspektrums zur
Pflichtübung jedes Projekts, bevor man die Einführung der Desktop-Virtualisierung vorantreibt. Nur
auf diese Weise lassen sich identische Pools von Desktops bilden und der Bedarf an zentralen
Ressourcen in akzeptablen Grenzen halten.
Virtuelle Desktops müssen aber nicht immer der vollständige Ersatz einer WTS/Xenapp-Plattform
sein. Vielmehr können sie auch hervorragend als Ergänzung zu einer WTS Umgebung dienen, falls nur
diejenigen Anwendungen auf einem virtuellen Desktop installiert werden, die absolut nicht auf der
WTS-Plattform lauffähig sind. Eine weitere ideale Ergänzung zum WTS sind individuelle
zentralisierte Entwicklerarbeitsplätze mit lokalen Administrationsrechten für die Benutzer, da dies
im WTS-Umfeld nicht möglich ist.
Lesen Sie mehr zum Thema
