Installation von Terminalserverfarmen
Automation verschafft den Durchblick
Die Vorteile von Server-based Computing zur Konsolidierung, Standardisierung und Kostensenkung von IT-Umgebungen stellt kaum jemand in Frage. Die schnelle, effiziente und sichere Bereitstellung von Anwendungen gilt als ein Hauptvorteil dieser Technik. Dennoch bleiben Herausforderungen bestehen, die sich bei der Installation und dem Betrieb von Terminalserverfarmen ergeben.
In vielen Unternehmen konkurriert heute eine neue Generation von zentralisierten Web- mit
traditionellen Windows-Anwendungen. Diese Windows-Applikationen befinden sich in der Regel auf den
Endgeräten der Benutzer und entziehen sich damit oftmals einer effizienten zentralen Kontrolle. Oft
löst die gezielte Installation der Anwendungen auf zentralisierten Terminalservern dieses Problem.
Die Anwendungen laufen dann auf den Terminalservern, und die Benutzer erhalten ohne lokale
Installation ein Abbild der benötigten Anwendung auf ihrem vernetzten Endgerät. Der Unterschied
zwischen Web- und Windows-Anwendungen schrumpft, zumindest in Bezug auf ihre zentralisierte
Verwaltung.
Trotz vieler Vorteile von zentralisierten Terminalserverfarmen sehen sich die Administratoren
damit konfrontiert, dass Installation und Wartung der Anwendungen für Endbenutzer nun in das
Rechenzentrum verlagert sind. Zudem wachsen die einzelnen Server der Anfangszeit schließlich oft zu
massiven Serverfarmen heran. Verbunden mit einem hochverfügbaren Betrieb erzeugt das eine
Komplexität, die einen hohen Standardisierungsgrad erfordert. Dies gilt insbesondere für mittlere
bis große Zielumgebungen. Die naheliegende Lösung ist eine weitgehende Automatisierung von
Installation und Betrieb der Terminalserverfarmen. Diese Lösung ist jedoch nicht trivial.
Problemquelle manueller Rollout
Betrachten wir zunächst die konventionelle manuelle Einrichtung vollständiger Terminalserver:
Auf die Basisinstallation des Serverbetriebssystems auf der Zielhardware folgt die Aktivierung der
Terminaldienste in der Rolle eines Anwendungsservers und das Einspielen der erforderlichen
Lizenzen. Nötig ist dann die Konfiguration der Parameter für die Terminaldienste, das
Windows-Basissystem, die Systemrichtlinien, das Dateisystem, die Registry, die Benutzerverwaltung
und die Sicherheitseinstellungen. Anschließend folgt auf den meisten Terminalservern im
Unternehmensumfeld die Installation von Citrix Presentation Server (CPS), um die SBC-Funktionalität
zum Beispiel durch veröffentlichte Anwendungen, randlose Anwendungsfenster und hochskalierbare
Lastverteilung zu erweitern.
Die Einrichtung dutzender oder gar hunderter Anwendungen erfordert es, einen Terminalserver
jeweils in einen speziellen Installationsmodus zu bringen, in dem ausschließlich der
verantwortliche Administrator interaktiv auf dem Server arbeiten sollte. Nach erfolgter
Installation jeder einzelnen Anwendung ist das System zwingend wieder in den normalen
Ausführungsmodus zu bringen. Darauf folgen in der Regel wiederum Anpassungen an Systemrichtlinien,
Dateisystem, Registry, Sicherheitssystem, Benutzer- und Gruppeneinstellungen sowie zumeist auch an
Benutzerprofilen und Anmeldeskripten. Nicht vergessen sollte man beim Citrix-Einsatz den Aufwand
für die Konfiguration der zugehörigen spezifischen Parameter und das Veröffentlichen der
installierten Anwendungen.
Die Komplexität ist also nicht zu unterschätzen – insbesondere im Hinblick darauf, dass der
Administrator die Reihenfolge der Installationsschritte nicht ändern darf: Terminalserver reagieren
in der Praxis extrem sensibel auf kleinste Abweichungen von einer Referenzinstallation. Benutzer
erfahren dies oftmals schmerzlich durch ein nicht-deterministisches Verhalten manuell duplizierter
Terminalserver. Ist man jedoch auf ein absolut identisches Verhalten mehrerer Terminalserver in
einer gemeinsamen Lastverteilungsfarm angewiesen, hilft meist nicht einmal die Erfahrung eines sehr
versierten Administrators, um eine manuelle Farminstallation zu 100 Prozent erfolgreich und
reproduzierbar durchzuführen.
Dies wird umso kritischer, wenn nach einigen Tagen oder Wochen zusätzliche Softwarekomponenten
wie Service-Packs oder neue Anwendungen nachzuinstallieren sind. Eine solche mehrstufige
Installation manuell zu reproduzieren – und sei es nur, um der Farm einen neuen Server hinzuzufügen
– ist auch mit einer möglichst vollständigen Dokumentation kaum zu verwirklichen. Die Anforderung,
mehrere hundert oder gar tausend Installationsschritte manuell in exakt der vorgegebenen Weise für
mehrere Zielserver durchzuführen, übersteigt nun mal die Fähigkeiten der meisten Administratoren.
Dies schreit nach unterstützenden Automationsmethoden.
Hier weist ein erfahrener Administrator natürlich darauf hin, dass sich eine solche
Automatisierung auch mit Cloning realisieren ließe. Hierbei nutzt der Systemverwalter das
vollständige Festplattenabbild einer Serverinstallation als Quelle und dupliziert es auf andere
Zielplattformen. Diese Idee ist grundsätzlich nicht schlecht, birgt jedoch einige Fallen.
Stolpersteine beim Cloning
Zunächst einmal sind Cloning-Lösungen am besten für das relativ statische Aufsetzen eines
Betriebssystems geeignet. Sie haben jedoch Schwierigkeiten, die wesentlich dynamischeren,
serverspezifischen Parameter einer Anwendungsinstallation zu beachten. Diese beinhalten
beispielsweise individuelle Servernamen, IDs oder lokale Lizenzinformationen. Des Weiteren kann
Cloning nur in sehr begrenztem Maße mit Abweichungen bei der genutzten Hardwarebasis umgehen: Es
erfordert in der Regel die Erstellung eines neuen Quellabbilds, selbst wenn sich die Hardware oder
die installierte Software nur minimal ändern – wenn zum Beispiel lediglich ein einfacher Patch
einzuspielen ist. Ohne neues Quellabbild fällt dann manuelle Nacharbeit an.
Außerdem kann Cloning nicht zwischen den Parametern einer initialen und einer Folgeinstallation
unterscheiden. Ein gutes Beispiel für diese Problematik bildet der Umstand, dass der Administrator
die Einrichtung des ersten Servers einer CPS-Farm anders durchführen muss als die jedes weiteren
Servers, den er dieser Farm hinzufügt. Zudem übernehmen in einer solchen Farm manche Server
besondere Rollen im Verbund. Damit ist klar, dass ein Quellabbild vor dem eigentlichen Cloning für
jeden Zielserver gesondert anzupassen ist.
Problemfall Wiederherstellung
Als echte Herausforderung erweist sich Cloning für Unternehmen, die eine weitreichende Kontrolle
über die Installationshistorie ihrer Server gewährleisten müssen. Hierbei kann gefordert sein,
jederzeit den exakten Zustand eines Computers so wiederherzustellen, wie er vor einer bestimmten
Zeit bestanden hat. Insgesamt weist Cloning somit als Ansatz für die Terminalserverinstallation
trotz des zunächst einfach erscheinenden Ablaufs gravierende Schwächen auf. Für die eher statische
Phase der initialen Systeminstallation bildet es jedoch eine leistungsfähige Alternative zur
konventionellen Methode der "Unattended Installation" eines Betriebssystems.
Eine vollständig automatisierte Verteilung von Betriebssystem und Anwendungen muss in der Regel
auf einer effektiveren Methode beruhen. Dieses stellt jedoch oft das "Betriebsgeheimnis" versierter
Administratoren dar.
SBC-Administratorenalltag
Betrachten wir das exemplarische Vorgehen eines erfahrenen Terminalserveradministratoren
genauer: Zunächst setzt er das "Rohmetall" (Bare Metal) des Servers auf, indem er den
RAID-Controller konfiguriert und die Festplatten partitioniert – natürlich automatisiert über ein
Skript. Danach bringt er das Betriebssystem über Cloning oder Unattended Installation auf die
Zielplattform. Anschließend erstellt er Skripte zur Optimierung und Erweiterung des Betriebssystems
sowie zum Setzen von Sicherheitseinstellungen über Service-Packs, Hotfixes, Patches oder
Security-Packs. Durch die Reihung dieser Skripte mithilfe einer Ablaufsteuerung – möglicherweise
wieder über ein vorgegebenes Skript – erzeugt er nun ein optimiertes Basissystem. Bis zu dieser
Stelle sind schon einige Neustarts und Übergabeskripte zum nahtlosen Wechsel von einer
Installationsphase zur nächsten nötig.
Nun nutzt der Administrator einen Satz kleiner Kommandozeilenwerkzeuge, die er eventuell selbst
entwickeln musste oder als freie Software im Internet findet. Die Tools führen Einstellungen für
Terminalserver auf der Zielplattform durch. Dies betrifft beispielsweise die Verwaltung von
Registry-Mapping-Optionen, die Kontrolle der Farmkonfiguration, die Umstellung in den
Installationsmodus oder die Modifikation von Einstellungen der grafischen Benutzerschnittstelle.
Die Tools lässt der Administrator durch ein weiteres Skript zusammen mit zugehörigen
serverspezifischen Konfigurationsdateien auf die Zielplattform kopieren. Nun kann er sie bei Bedarf
wiederum durch ein Skript aus der Ferne ausführen. Die Konfigurationsdateien der Werkzeuge füttert
er vor ihrer Ausführung mit den Daten aus einer Datenbank, die sämtliche Serverparameter
enthält.
Mit seinem Vorgehen hat der Administrator schließlich auf jeder Zielplattform ein optimiertes
und individualisiertes Basissystem installiert. Dabei hat jeder Installationsschritt einen Eintrag
in einer Protokolldatei oder in einer zentralen Datenbank erzeugt, damit alles nachvollziehbar
bleibt. Nun muss der Systemverwalter "nur" noch die Anwendungen auf die vorbereiteten Server
bringen. Dies geschieht wieder durch Skripte mit Platzhaltern für dynamische serverbezogene
Parameter. Eine dominante Rolle spielen hier zumeist die Ausführung von .msi-Dateien über den
Microsoft Installer oder "Silent-Installation"-Methoden konventioneller Windows-Anwendungen. Und
wieder kontrollieren Skripte den exakten Ablauf, bis alle Server vollständig eingerichtet sind. Nun
muss der CPS-Administrator die Anwendungen veröffentlichen. Auch das erfordert wieder ein Tool und
so weiter.
Das beschriebene Vorgehen ist keinem normalen Administrator zuzumuten. Es erfordert umfangreiche
Kenntnisse im Umgang mit Konzepten und Werkzeugen wie Cloning, Unattended Setup, Sysprep, Remote
Installation Services, Automated Deployment Services, Microsoft Installer, Registry Editor,
Microsoft Windows Script Host und Visual Studio. Was also ist die Lösung, um nicht einen hoch
spezialisierten Administratoren einkaufen zu müssen, der es hasst, seine Arbeit zu dokumentieren,
und der sich dadurch für immer unentbehrlich macht?
Der erste Teil einer Lösung liegt scheinbar auf der Hand: Der Markt bietet eine Reihe von
Installationsprodukten wie Microsoft Systems Management Server, Citrix Installation Services, Enteo
Netinstall, Symantec Livestate Management Suite, Altiris Deployment Solution und viele andere.
Diese Lösungen automatisieren Installationstätigkeiten, nachdem das Betriebssystem über Cloning
oder Unattended Installation auf der Zielplattform eingerichtet ist. In der Regel sind sie jedoch
für den Rollout umfangreicher Client-Umgebungen optimiert und bedienen Terminalserver nur als
Nische. Entsprechend lang ist die Liste potenzieller Schwachpunkte (siehe Kasten).
Anforderungen bei CPS-Einsatz
Diese Anforderungsliste ist um vier Punkte zu erweitern, wenn die Lösung auch die automatische
Einrichtung von Citrix Presentation Server unterstützen soll:
Lassen sich alle CPS-Parameter automatisiert anpassen und installierte
Anwendungen veröffentlichen?
Unterstützt die Lösung die Verwaltung mehrerer Serverfarmen und die Option zum
Farm-Splitting?
Lassen sich der Citrix Datastore und die Data Collectors automatisiert
einrichten und verwalten?
Lässt sich das Einrichten der Lizenzierung korrekt durchführen?
Diese Zusatzfunktionen bieten nur Softwareverteilungslösungen, die speziell für das Management
von Server-based-Computing-Infrastrukturen ausgelegt sind. Im Optimalfall bietet eine solche Lösung
zahlreiche Vorlagen für Pakete zur Installation und Konfiguration, die Terminalserver-Profis in der
Praxis erstellt haben. Ein wesentliches Element ist dabei die lückenlose Protokollierung sämtlicher
Installationsschritte, was auch nachträgliche Analysen deutlich erleichtert. Ein "normaler"
Administrator erreicht damit nach kurzer Zeit die gleichen Ergebnisse wie zuvor nur
hochspezialisierte Systemverwalter.
Lesen Sie mehr zum Thema
