Terminal-Services rund um die Uhr

Wie kann man einen hohen Anspruch an Verfügbarkeit mit der Dynamik einer zentralen
Terminal-Server-Infrastruktur vereinbaren? Ein Weg aus diesem Dilemma soll folgendes Beispiel
aufzeigen: Administrator Mayer ist als IT-Koordinator für das Change-Management zweier
Terminal-Server-Gruppen zuständig. Eine Gruppe von 20 Servern hostet die Standardanwendungen wie
Office, Outlook, SAP und die CRM-Software. Anwender arbeiten weltweit auf diesem Verbund, weshalb
die Fachabteilungen verlangen, dass diese Server immer zur Verfügung stehen. Ein weiterer Verbund
betreibt zwei geschäftskritische Anwendungen, die gesondert laufen, da sich die Anwendungen nicht
mit SAP auf dem anderen Verbund vertragen. Auch diese beiden Anwendungen sollen rund um die Uhr
verfügbar sein.

Die Sicherheitsabteilung fordert, dass Microsoft-Updates wöchentlich zu installieren sind. Aus
Betriebssicht möchte Herr Mayer die Server zudem einer wöchentlichen Wartung unterziehen, in der
temporäre Ordner und Spool-Verzeichnisse aufgeräumt und die Terminal-Server neu gestartet werden
sollen, damit der Arbeitsspeicher sich neu initialisiert. Um diesen Ansprüchen gerecht zu werden,
benötigt unser Administrator ein flexibles Wartungsfenster, also eine Möglichkeit, die
Terminal-Server zu warten, ohne dass die Endanwender davon betroffen sind.

Wartungskonzept mit zwei Phasen

Das Konzept dafür stellt sich wie folgt dar (Bild): Man sucht sich einen Zeitraum aus, in der
die Server-Farm möglichst wenig belastet ist. Dies muss ein Zeitraum sein, in dem 50 Prozent der
Server einer Farm die gesamte Anwenderlast tragen können. Für 50 Prozent der Server wird dann zehn
Stunden vor der eigentlichen Wartung die Anmeldung gesperrt. Der Wert von zehn Stunden wird
gewählt, weil die Anwender sich in dieser Zeitspanne normalerweise vom Server abmelden und in den
Feierabend gehen.

Nach den zehn Stunden werden die verbleibenden Anwender über die Wartung informiert.
Normalerweise sollte aber kein Anwender mehr auf diesen Servern angemeldet sein – oder der Zeitraum
von zehn Stunden ist zu kurz gewählt. Anwender, die noch arbeiten, können sich abmelden und sofort
wieder anmelden; sie landen dann auf den anderen 50 Prozent der Server. Danach startet die
IT-Abteilung die ersten 50 Prozent der Server neu und installiert bei Bedarf Software.

Haben alle Server die Wartung durchlaufen, analysiert man, wie viele der Server wieder online
sind. Dies kann per Ping erfolgen sowie mittels Einzelprüfung, ob Dienste laufen und auf allgemeine
Anfragen antworten. Nur wenn ein hoher Prozentsatz wieder online ist, startet man das zweite
Wartungsfenster, andernfalls erhält der Administrator einen Alarm. Diese Abfrage ist wichtig, da
eventuell die Tests für den Rollout nicht intensiv genug waren. Unterbleibt so, so riskiert man,
dass nach der Wartung kein einziger Server mehr zur Verfügung steht. Es gab zum Beispiel schon
Fälle, in denen ein Microsoft-Hotfix das Starten der Xenapp-Dienste verhindert hat. Sollten genug
Server wieder online sein, startet das zweite Wartungsfenster in der gleichen Manier.

Zum Deaktivieren der Anmeldungen gibt es zwar den Befehl "Change Logon /disable", doch dieser
birgt Nachteile: Erstens können sich auch Administratoren in dieser Zeit nicht anmelden, zweitens
führt die Methode ziemlich sicher zu Incidents durch Anwender, die sich nicht wieder mit ihrem
Server verbinden können. Als optimal hat sich deshalb das Zuweisen eines Lastauswertungsprogramms
erwiesen, wie sie in Xenapp-Infrastrukturen verfügbar sind. Weist der Administrator ein solches
Programm zu, meldet es Volllast und nimmt keine neuen Anwender an. Ab Windows 2008 Terminal-Server
hat Microsoft einen so genannten Drain Mode eingeführt, der genau dies ermöglicht.

Lastauswertungsprogramm

In unserem Beispiel stellt Herr Mayer fest, dass 99 Prozent der Anwender maximal neun Stunden in
einer Sitzung arbeiten und die Farm nach Freitag 24:00 Uhr nur noch zu 20 Prozent belastet ist. Die
Nutzung steigt am Montagmorgen ab 4:00 Uhr wieder an. Am Freitag um 22:00 Uhr weist er deshalb 50
Prozent aller Server das Lastauswertungsprogramm "keine neuen Anmeldungen" zu. Zehn Stunden später
(zur Sicherheit ein wenig länger als die ermittelte Zeit) werden die Anwender erstmals informiert,
nach zehnminütiger Pause erneut. Danach, also am Samstag um zirka 8:20 Uhr, starten die Server neu.
Dadurch startet auch der Software-Agent, wodurch neue Pakete installiert werden und allgemeine
Aufräumarbeiten erfolgen können. Dieser Dienst wird dann wieder gestoppt, was Aktualisierungen
außerhalb der Wartung verhindert.

Am Ende wertet man die Antworten des IMA-Dienstes (Independent Management Architecture) aus:
Herr Mayer hat definiert, dass das zweite Wartungsfenster starten darf, wenn 80 Prozent der Server
wieder online sind. Ist alles glatt gelaufen, sind die gesamten Aktualisierungen innerhalb von drei
Stunden erledigt, das zweite Wartungsfenster startet damit am Samstag um 11:30 Uhr. Der
Administrator weist den aktualisierten Servern wieder das normale Lastauswertungsprogramm zu und
den restlichen das Programm für die Volllast. Er wartet wieder zehn Stunden, verschickt seine zwei
Meldungen an die Anwender auf den nun betroffenen Servern und startet letztere dann neu. Damit hat
der Administrator ein flexibles Wartungsfenster etabliert und sichergestellt, dass für die Anwender
immer genügend Terminal-Server zur Verfügung stehen.

Sonderfälle

Dieses Szenario zeigt das flexible Wartungsfenster in seiner einfachsten Form. In der Praxis
können aber Sonderfälle auftreten, zum Beispiel:

lange Berechnungszeiten, die nicht unterbrochen werden dürfen,

VIPs, die man nicht abmelden darf,

Aktualisierungen im Backend oder

keine Auslastung der Terminal-Server unter 50 Prozent.

Dauert eine Berechnung länger als ein Wartungsintervall, so würde diese durch das oben
beschriebene Verfahren unterbrochen und damit wertlos. In solch einem Fall ist zu prüfen, ob
entsprechende Berechnungsprozesse laufen. Wenn ja, muss die Wartung für diesen Server verzögert
werden, bis der Prozess beendet ist. Beendet sich der Prozess nach der Berechnung nicht selbst, ist
entweder zu ermitteln, dass der Prozess keine CPU mehr verbraucht, woraufhin der Server neu
startet; oder aber der Server wird ganz aus dem Wartungsintervall genommen und der Administrator
darüber informiert. Auf diesem Server werden dann die Anmeldungen deaktiviert, sodass der Server
nach dem Ende der Berechnung sofort in Wartung gehen kann (dies ist in der Regel dann am
Montag).

Mit VIP-Anwendern verfährt der Administrator im Prinzip wie mit langen Berechnungen: Solange der
Anwender angemeldet ist, geht der Server nicht in Wartung. Der Anwender bekommt dann zum Beispiel
jede Stunde eine Meldung mit der Bitte, sich abzumelden. Sind alle Anwender abgemeldet, geht der
Server in Wartung.

Häufig geht mit einer Anwendungsaktualisierung auch ein Update im Backend einher, sodass zum
Beispiel die Aktualisierung der Frontend-Anwendung mit der eines Datenbank-Servers zu
synchronisieren ist. Der optimale Weg dafür ist es, die Datenbankwartung mit dem ersten Wechsel zu
starten (in unserem Beispiel am Samstag um 11:30). Denn geht der Datenbank-Server in Wartung,
werden sowieso alle Verbindungen getrennt (also alle alten Anwendungen).

Wenn sich auch am Wochenende keine geringere Auslastung als 50 Prozent ergibt, so muss man das
Wartungsfenster dritteln. Dies wiederspricht dem Konzept, dass zu einem Zeitpunkt nur eine
Anwendungsversion aufrufbar ist: Zum Zeitpunkt des zweiten Wartungsfensters sind die aktualisierten
Anwendungen auf dem ersten Drittel und die noch nicht aktualisierten Anwendungen auf dem letzten
Drittel im Zugriff. Jedoch ist dies dann die einzige Möglichkeit, eine Wartung ohne Einbußen bei
der Verfügbarkeit durchzuführen.

Die Herausforderung der Softwareaktualisierung entspannt sich ein wenig, wenn man
Anwendungsvirtualisierung einführt. Durch Anwendungsvirtualisierung wird die Software nicht mehr
installiert, sondern auf das Gerät gestreamt, was dem Ablaufen eines Videos gleicht. Dafür ist
keine Betriebsunterbrechung und damit auch kein Wartungsfenster notwendig. Bei der Aktualisierung
eines bereits gestreamten Pakets stellt sich dies wieder anders dar, da dann alle Anwender die
Anwendung einmal beenden müssen. Erst danach kann das aktualisierte Paket übertragen werden. Dies
wird bei der Planung der Wartungsfenster für virtualisierte Anwendungen häufig nicht
berücksichtigt.

Das flexible Wartungsfenster ist ein hervorragendes Konzept, um Wartungen in
Terminal-Server-Umgebungen durchzuführen. Ein Wartungsfenster wird auch beim Einsatz virtueller
Anwendungen notwendig sein. Leider fehlen dafür in die bestehende Software integrierte Mechanismen.
Zum Glück gibt es auf dem Markt aber Frameworks, die für solche Szenarien entwickelt wurden und die
Realisierung eines flexiblen Wartungsfensters ermöglichen