Migrationsplanung für Citrix Presentation Server
Verjüngungskur
Mit der Freigabe neuer Versionen beginnt für die Systembetreuer der Weg einer Umstellung, den sie behutsam beschreiten müssen, damit die Anwender ungestört weiterarbeiten können. Beim Lifting des Citrix Presentation Servers (CPS) sollten die Schritte sorgfältig geplant sein.
In überschaubaren Umgebungen geht das Installieren einer neuen CPS-Version recht einfach über
die Bühne: Ein erfahrener Administrator erledigt dies in wenigen Stunden – vorausgesetzt, er hat
die automatische Installation und Konfiguration passend eingerichtet, denn sonst kann die
Umstellung Tage oder Wochen in Anspruch nehmen. Doch die Installation einer neuen Version ist nur
ein kleiner Baustein einer sauberen Migration: Die vier Phasen Analyse, Design, Build/Test und
Rollout dürfen in keinem IT-Projekt fehlen. Je nach Umgebungsgröße wird ein Projektteam die Phasen
unterschiedlich intensiv ausdifferenzieren. In keinem Projekt aber sollte die Planungsphase
(Analyse, Design, Erstellen des Migrationspfads) zu kurz kommen. Würde man hier sparen, könnte das
Projektteam wichtige Besonderheiten übersehen und die Komplexität der Umgebung und somit des ganzen
Vorhabens falsch einschätzen.
Auch bei einer CPS-Migration können die Benutzer für den Projekterfolg das Zünglein an der Waage
sein. So gilt es zu klären: Wieviel Unterbrechung akzeptieren die Benutzer? Kann oder soll im Zuge
der Migration ein neuer Zugriffsmechanismus wie Web Interface implementiert werden? Meist lassen
sich Migrationen auch nutzen, um weitere Techniken einzuführen. Derzeit steigt die Tendenz,
Applikationen als Webanwendungen und Informationen im Unternehmensportal bereitzustellen. Citrix
Web Interface bietet hier gute Voraussetzung für die Integration in Portallösungen wie Microsoft
Sharepoint oder IBM Websphere.
CPS-Farmen sind keine autarken Konstrukte. So stellt sich bei einer Migration immer die Frage
nach weiteren Komponenten auf dem betroffenen Server oder in dessen Umfeld, die im gleichen Zug
eine Verjüngungskur erhalten sollten. Neben Citrix Metaframe oder CPS könnten zeitgleich auch das
Serverbetriebssystem oder die Anwendungen ein Upgrade erhalten. Neben harten technischen Fakten
gibt es eine Reihe "weicher", eher organisatorisch orientierter Fragestellungen: Wie lange kann die
Migration dauern? Sind alle Server gleichzeitig zu aktualisieren? Ist die bestehende Konfiguration
beizubehalten? Soll ein Upgrade, eine In-Place- oder eine Parallelmigration erfolgen? Die letzte
Frage ist nicht so einfach und eindeutig zu beantworten, da die Antwort stark von der Umgebung und
den Anforderungen des Unternehmens abhängt.
Upgrade und In-Place-Migration
Die Vorteile eines Upgrades, also des Erneuerns einer CPS-Installation ohne Veränderung des
Betriebssystems und der Applikationen, sind der geringe Planungsaufwand und das Entfallen des
Bedarfs an zusätzlichen Hardwareressourcen während der Migration. Jedoch besteht hier die Gefahr,
Fehlkonfigurationen in die "neue Welt" mitzunehmen. Man vergibt die Chance einer grundlegenden
Bereinigung oder Homogenisierung der Umgebung. Bei einem Upgrade sollte das Projektteam steigende
hard- und softwareseitige Mindestvoraussetzungen nicht vergessen, zum Beispiel Windows 2000 mit
Service-Pack 4 und Citrix Metaframe XP mit Feature Release 3 (inklusive Service-Pack 3) für eine
Migration auf CPS 4.0.
Bei einer In-Place-Migration entfernt der Administrator die Server nacheinander aus der Farm,
versieht sie mit einer neuen Version des Betriebssystems, der Applikationen und des Presentation
Servers und fügt sie wieder zur Farm hinzu. Dies ermöglicht die gleichzeitige CPS- und
Betriebssystemmigration, bedingt jedoch einen deutlich höheren Planungsaufwand als ein reines
Upgrade. Denn es erfordert, die Anwendungen mit der neuen Betriebssystemversion zu testen, was
gerade bei einem älteren Anwendungsportfolio recht aufwändig sein kann. Auch darf man nicht
vergessen, dass während der In-Place-Migration weniger Server in der Farm bereitstehen, was zu
höherer Last auf den verbliebenen Systemen und zu geringer Ausfallsicherheit führt. Benutzer
könnten in Mitleidenschaft gezogen werden und somit die Akzeptanz der SBC-Lösung sinken. Darum ist
es empfehlenswert, entsprechende Redundanz einzuplanen.
Zwar ist eine In-Place-Migration technisch recht einfach, doch einige Spielregeln sollte der
Administrator beachten. Zunächst wäre da der wichtige, aber leider oft überhörte Rat, einen Server
aus einer Presentation-Serverfarm nur mithilfe einer CPS-Deinstallation auf der jeweiligen Maschine
oder mit dem Befehl "CHFARM" zu entfernen. Sonst kann die Struktur der zentralen
Konfigurationsdatenbank der Serverfarm (Data Store) Schaden nehmen, bedingt durch den internen
Aufbau des Datenspeichers. Ferner ist es ratsam, Systemen mit einer neueren CPS-Version die
zentralen Rollen der Farm anzuvertrauen, um einen stabilen und performanten Betrieb zu
gewährleisten. Dies gilt insbesondere für den Datensammelpunkt (Data Collector).
Parallelmigration
Eine parallele Migration stellt die technisch wohl sauberste, wenn auch finanziell und
logistisch aufwändigste Methode eines Umstiegs zu einer neuen CPS-Version dar. Hier baut das
Serverteam ohne den Stress des Tagesgeschäfts eine zweite CPS-Umgebung auf. Darin können Admins und
Testbenutzer bequem und ohne Zeitdruck neue Installationsverfahren, CPS- oder auch
Betriebssystemversionen sowie Anwendungen auf ihre Funktion hin prüfen. Erst nach einer
vollständigen Freigabe aller Beteiligten macht das Projektteam die Umgebung den übrigen Benutzern
zugänglich. Das Einbinden von Testbenutzern und die finale Freigabe für die Endbenutzer können dank
Web-Interface-Technik in einem geregelten Ablauf stattfinden. Dabei kontaktiert Web Interface die
bestehende wie auch die neue CPS-Farm und präsentiert dem Benutzer anhand seiner
Gruppenmitgliedschaft im Verzeichnisdienst (Active Directory, LDAP, Novell Edirectory) die
veröffentlichten Anwendungen beider Farmen auf einer Webseite (Bild).
(((Bild bitte hierher!)))
Dieser "Aggregation" genannte Vorgang erfordert vom Benutzer keinerlei Konfiguration oder
Hintergrundwissen. Die Administratoren sollten aber unbedingt auf eine eindeutige Namensgebung der
veröffentlichten Ressourcen achten, da die Benutzer sonst nicht mehr zwischen Test- und
Produktivumgebung unterscheiden können. Mit diesem Mechanismus lassen sich auch Benutzergruppen wie
Teams oder Abteilungen auf die neue Umgebung schalten, während andere Benutzer weiterhin die alten
Systeme nutzen. Im Hintergrund lassen sich dann die CPS-Systeme nach Bedarf und Rollout-Stand in
die neue Farm umziehen.
Doch auch eine parallele Migration hat Nachteile: Neben erhöhtem Hardwareaufwand im Vergleich zu
den anderen Migrationsarten kann vor allem die Übernahme von Farmeinstellungen, veröffentlichten
Anwendungen oder Citrix-Richtlinien in größeren Farmen eine Herausforderung darstellen. Citrix
verweist hier nur auf die MFCOM-Schnittstelle, die im Presentation Server SDK (Software Development
Kit) detailliert beschrieben ist. Mit dem SDK lassen sich Werkzeuge entwickeln, die die
Einstellungen der alten Farm auslesen und mit einigen wenigen Einschränkungen in die neue Farm
importieren. Eine gute Ausgangsbasis für die Entwicklung eines solchen Tools stellt das Citrix
Developer Network dar. Es bietet verschiedene Code-Versatzstücke (Sniplets), die die ersten
Schritte erleichtern können. Wer aufgrund knapper Zeit oder Ressourcen eine Eigenentwicklung
scheut, kann auf fertige Tools verschiedener Anbieter zurückgreifen, die sich dieser Problematik
angenommen haben (siehe Kasten).
Profile und Einstellungen
Trotz des Hauptaugenmerks auf die CPS-Überführung darf man angrenzende Bereiche und Techniken
bei der Migrationsplanung nicht vernachlässigen. Wichtige Punkte sind hier das
Serverbetriebssystem, der Verzeichnisdienst und die Integration der Terminalserver in diesen oder
die Anwendungen. Einen weiteren wichtigen, aber leider oft übersehenen Punkt bilden die
Benutzerprofile, die alle Benutzereinstellungen speichern. Zu klären ist: Welcher Profiltyp passt
für die neue Umgebung? Wie erfolgt die Übernahme der Einstellungen?
Grundsätzlich finden in einer Windows-Terminal-Services-Umgebung drei Profiltypen Verwendung:
lokale, verbindliche (Mandatory) und servergespeicherte (Roaming) Profile. Lokale Profile stehen
ausschließlich lokal auf einem Windows-Terminalserver zur Verfügung und sind nur sinnvoll, wenn
eine Terminalserver- oder CPS-Umgebung aus nur einem Server besteht.
Verbindliche Profile werden vom Administrator vorkonfiguriert. Sie bilden den kleinsten
gemeinsamen Nenner der Benutzer, da kein Benutzer diese Profile verändern kann. Anwender können
Einstellungen zur Laufzeit vornehmen, jedoch verfallen diese nach der Abmeldung, da nichts
gespeichert wird. Ein verbindliches Profil bietet Vorteile in Bezug auf die Stabilität und
Vereinheitlichung der Benutzerumgebung auf Terminalservern, ist jedoch mit dem Nachteil verbunden,
dass sich persönliche Einstellungen der Benutzer nicht speichern lassen. Das verbindliche Profil
steht lokal auf einem Terminalserver oder auf einer Netzwerkfreigabe eines Fileservers bereit.
Servergespeicherte Profile hingegen ermöglichen einem Benutzer, seine gewohnte Benutzerumgebung
einschließlich persönlicher Einstellungen von Terminalserver zu Terminalserver mitzunehmen. Dies
bietet den Benutzern eine flexible Umgebung. Ein Kritikpunkt an servergespeicherten Profilen ist
das schnelle Anwachsen der Profilgröße. Da Fileserver per Netzwerkfreigabe die servergespeicherten
Profile vorhalten, ist es äußerst wichtig, die Benutzer zum Beispiel per Gruppenrichtlinie am
Ablegen großer Dateien in ihrem Profil zu hindern. Denn all diese Daten im Profil sind zum
Anmeldezeitpunkt des Benutzers auf den Terminalserver zu kopieren.
Obwohl servergespeicherte Profile die verbreitetste Profillösung in Terminalserver- und
CPS-Umgebungen sind, vernachlässigen Administratoren die Beschränkung der Profilgröße häufig, was
zu langen Anmeldezeiten führt. Ein weiterer Nachteil ist die Anfälligkeit für eine Beschädigung des
Profils. Wie beim Anmelden ist das Profil beim Abmeldevorgang zwischen File- und Terminalserver zu
übertragen. Diesmal jedoch wird es auf den Fileserver zurückgeschrieben. Treten dabei
Kommunikationsprobleme zwischen den beteiligten Servern auf, kann das Profil Schaden erleiden.
Dieser Umstand kann für Benutzer äußerst unangehm sein, da die letzten Änderungen dann nicht mehr
im Profil vorhanden sind oder das Profil unbrauchbar wird.
Neben den genannten Profiltypen bietet der Markt spezielle Profillösungen (siehe Kasten), die
die Nachteile verbindlicher und servergespeicherter Profile beseitigen, deren Stärken vereinen und
somit eine stabile Benutzerumgebung gewährleisten. Dabei verfolgen die meisten Tools die gleiche
Strategie: Sie kombinieren das verbindliche Profil mit vordefinierten Einstellungen und
An-/Abmeldeskripten. Die vom Administrator erlaubten Einstellungen für die Benutzer werden beim
Anmelden importiert und beim Abmelden exportiert. Beim Abmeldevorgang verwerfen sie dann
Einstellungen, die der Administrator nicht gestattet hat. Diese Funktionalität realisiert ein auf
den Terminalservern installierter Dienst.
Fazit
Systemverwalter sollten vor einer Migration auf eine neuere CPS-Version nicht zurückschrecken.
Es ist jedoch äußerst wichtig, den Anfangsaufwand in Form von Planung und Betrachtung aller
relevanten Bereiche auch über den Citrix Presentation Server hinaus zu treiben. In Anbetracht des
aktuellen Citrix Presentation Servers 4.5 bietet sich gerade jetzt die Möglichkeit, das Thema
Migration in Angriff zu nehmen.
Lesen Sie mehr zum Thema
