Seit 15 Jahren befindet sich der PC nunmehr auf seinem Siegeszug in die deutschen Wohnzimmer und die DV-Landschaften der Unternehmen. Vor allem das reichhaltige Software-Angebot und die Macht des Endanwenders über sein Werkzeug trugen dem Personal Computer viele Sympathien ein. Auf der anderen Seite brachte er die DV-Verantwortlichen, die ständig gegen die verteilte Intelligenz am lokalen Arbeitsplatz kämpften, durch diese augenscheinlichen Vorteile in schwere Argumentationsnöte.

Etliche Prozessorgenerationen später wird nun vielen bewußt, daß der Preis für die bunten Windows-Bilder sehr hoch ist. Die DV-Administratoren müssen vor der Aufgabe, die Rechner zu warten und instand zu halten, mitunter kapitulieren. Aufgrund von Personalknappheit entwickelt sich ein reibungsloser PC-Betrieb im Unternehmen manchmal zu einem regelrechten Glücksspiel. Abhilfe verspricht ein neues Computermodell, das sogenannte Server-based Computing, bei dem alle Applikationen auf zentralen Servern laufen und nur die Bildschirminformationen auf die einzelnen Arbeitsplätze verteilt werden.

Diese Lösung wird hierzulande inzwischen häufig gewählt. Firmen, die bereits den Großteil ihrer PCs durch schlanke Rechner, Thin Clients, ersetzt haben, schwören auf die Technologie und sind begehrte Referenten. Der Nutzen der zentral ausgerichteten Systemarchitektur liegt klar auf der Hand: weniger Verwaltung, geringere Kosten und dabei mehr Performance sowie Sicherheit, was Verfügbarkeit und Daten betrifft.

In Microsofts Terminal Server Edition (TSE) in Verbindung mit Windows-based Terminals (WBTs) sehen viele DV-Leiter eine Rückkehr zur alten Terminalwelt. Und mit den zentralen Lösungen kommen zwangsläufig auch wieder die alten Fragen auf:

- die Kapazitätsplanung der zentralen Server,

- die Kapazitätsplanung des Netzwerks,

- Ausfallkonzepte für die zentralen Server,

- die Performance der Terminals,

- die Entscheidung für PCs oder Terminals,

- die Anwenderakzeptanz sowie

- die Softwarekompatibilität.

Welche Kapazität braucht der Server?

Die immer wiederkehrende Frage, wieviele Benutzer pro Server bedient werden können, läßt sich im Vorfeld nicht beantworten. Es gibt jedoch Faustregeln, anhand derer Anwender die ersten Test-Server in ihrem DV-System entsprechend ausstatten können.

Die endgültige Server-Dimensionierung muß allerdings für jeden Einsatzfall neu überdacht, ausprobiert und in mehreren Testläufen verifiziert werden.

Beispiel: Ein Unternehmen hat seine Oberfläche komplett im SAP R/3 abgebildet. Das heißt, der Anwender bedient 90 Prozent seiner Arbeitszeit das SAP-Graphic-User-Interface (GUI). Der zentrale Server, der mit vier Prozessoren und einem Hauptspeicher von 2 GB ausgestattet ist, wird problemlos bis zu 140 Benutzer gleichzeitig verkraften. Dasselbe Unternehmen hat in einer anderen Abteilung Excel-Makros mit einer Größe von etwa 40 MB eingeführt, die via OLE Daten in Word übertragen und über einen 16-Bit-ODBC-Treiber mit einer Datenbank kommunizieren. Auf dem gleichen Server können unter dieser Anwendungskonstellation maximal 40 Benutzer arbeiten.

Der Weg, die perfekte Dimensionierung für den Server herauszufinden, führt allerdings ausschließlich über den Kunden vor Ort. Nur Streßtests mit den eingesetzten Applikationen und eine längere Protokollierung der Server-Auslastung über einen Zeitraum von mindestens einer Woche liefern verläßliche Ergebnisse.

Anhand dieses Protokolls analysieren die Systemadministratoren, wann der Server aktive Programmelemente auslagert - dann wird mehr Speicher benötigt -, und wann die CPU-Last dauerhaft die 100-Prozent-Marke erreicht. Dann sind mehr oder schnellere CPUs nötig. Es ist zwar ganz normal, daß das Betriebssystem einzelne Programmteile auf der Festplatte zwischenlagert. Doch dürfen keine Betriebssystem-DLLs oder ähnlich wichtige Dateien ausgelagert werden, sonst bricht die Leistung des Systems deutlich ein.

Auch Spitzenlasten und 100-Prozent-Peaks bei der Beanspruchung des Prozessors sind gewollt, jedoch sollte die CPU nach kurzer Zeit wieder den Weg nach unten finden. Es gibt auch Tools, die die Rechenlast organisieren und verteilen. Das dynamische Load-Balancing, wie es beispielsweise von Citrix mit "Metaframe" angeboten wird, hilft bei der Verteilung und Skalierung der Rechenleistung über eine ganze Server-Farm.

Die Anwender dürfen jedoch nicht vergessen, daß neuere Versionen einer bereits eingesetzten Applikation in der Zukunft mehr Rechenleistung brauchen werden. Deshalb sollte ein Server bei der Anschaffung nicht zu knapp konfiguriert werden. Sehr einfach ist allerdings die Methode, Rechner zu ergänzen, wenn tatsächlich eines Tages mehr Performance gebraucht wird. Die Technik besteht darin, mit weiteren Servern, die in die DV-Struktur integriert werden, die Anzahl der gleichzeitigen Benutzer pro Maschine zu verringern. Damit besitzen die Maschinen eine wesentlich höhere Lebensdauer als vergleichbare PCs, die einfach ausgemustert werden, wenn die Rechenleistung nicht mehr genügt.

Auch diese alten Rechner lassen sich bei Server-basierten Systemlösungen übrigens sehr elegant an den zentralen Server-Bestand anschließen und reaktivieren. Die eingesetzten Server zeichnen sich durch eine hohe CPU-Leistung und ausreichend Arbeitsspeicher aus. Server mit vier CPUs und 2 GB Arbeitsspeicher sind heute allgemein üblich. Die Festplattenkapazität ist unkritisch. 9 GB für etwa 120 Benutzer sind ausreichend. Allerdings sollten die DV-Verantwortlichen auf Redundanzeffekte achten. Empfehlenswert sind ferner der Einsatz eines RAID-1-Controllers und möglichst viele Netzteile, da diese Komponenten erfahrungsgemäß am häufigsten ausfallen. Weil die Daten auf getrennten, zentralen Daten-Servern abgelegt werden, sind die Anwender flexibel bei der Auswahl des Applikations-Servers.

Im Gegensatz zur Rechenleistung des Servers, die von Fall zu Fall von unterschiedlich vielen Faktoren beeinflußt wird, läßt sich die Netzbelastung eindeutiger definieren und berechnen. Mit einer durchschnittlichen Belastung von weniger als 20 Kbit/s pro aktive Session braucht sich der Netzwerkadministrator keine Sorgen zu machen. Im Gegenteil: Der TSE hilft bei der Entlastung der Netzwerke und bei der Anbindung von Außenstellen über eine WAN-Strecke. Allerdings sollte der Zugriff auf die Daten-Server vom erzeugten Bildschirmdatenstrom entkoppelt werden. Erst dann spüren die Anwender eine deutliche Entlastung der Netzwerkverbindungen zum Arbeitsplatz.

Alle verfügbaren Protokolle wie die Independent Computer Architecture (ICA), das Remote Desktop Protocol (RDP) und X11 verursachen keine nennenswerte Netzwerkbelastung im LAN. Im WAN dagegen hat sich ICA, das sich durch dauerhaftes Bitmap-Caching und ein optimiertes Kompressionsverfahren auszeichnet, als das optimale Protokoll erwiesen.

Ausfallkonzepte und Verfügbarkeit

Bei zentral organisierten DV-Lösungen müssen folgende Komponenten zu 100 Prozent verfügbar sein: die zentralen Server und das Netzwerk. Besonders die Server, auf denen Windows NT beziehungsweise TSE installiert ist, sind durch die zahlreichen gleichzeitigen Benutzer schwer belastet und können jederzeit ausfallen. Schlecht programmierte Treiber, der tausendste Hotfix einer Applikation und nicht zuletzt die Hardware selbst können von Zeit zu Zeit den Server abstürzen lassen. Die Folge: Ein blauer Bildschirm verdammt die Anwender zur Untätigkeit. Während beim PC nur einzelne dieses Schicksal erleiden, sind bei einer zentralen Lösung alle angemeldeten Anwender betroffen.

Außerdem dürfen die Verantwortlichen nicht vergessen, daß dieses Problem sowohl auf dem PC als auch auf dem Server auftritt. Während beim Personal Computer der Reboot asynchron stattfindet, wird dies beim TSE-Server synchronisiert, was leider die Telefonleitung zur Hotline stark beanspruchen kann. Hier empfiehlt sich die Errichtung einer virtuellen Server-Farm, die aus mehreren Einzel-Servern besteht, was die Verfügbarkeit des gesamten DV-Systems deutlich verbessert.

Performance auf dem Terminal

Die Performance der Terminals ist ein Spiegel der Server-Performance und unabhängig von den lokalen Ressourcen. Der grafische Benchmark "Wintach" gibt Auskunft über die Bildschirmausgabe. So ist beispielsweise ein Wintach-Wert größer als 25 für Office- Anwendungen absolut ausreichend. Der Betrieb von grafischen Anwendungen, zum Beispiel Desktop Publishing, CAE, CAD, oder 3D-Programmen, ist jedoch nicht empfehlenswert. Allerdings müssen die Anwender hier zwischen dem reinen Betrachten, dem Viewing, und dem aktiven Arbeiten mit solchen Applikationen unterscheiden: Viewing funktioniert problemlos, da nicht mehr die gesamten Dokumente übertragen werden müssen. Das Bearbeiten der Daten ist dagegen nicht möglich.

PCs oder Terminals?

Die WBT-TSE-Lösung wird nur in den seltensten Fällen alle PCs einer DV-Landschaft komplett ersetzen können. Mit der WBT-Lösung geht es vielmehr darum, bestehende Arbeitsplätze an die zentralen Server anzuschließen und diese zentralen Ressourcen ganz oder teilweise zu nutzen.

Die Verwaltung der zentral organisierten Server ist nahezu identisch mit der Administration bestehender Windows-NT-Workstations. Die TSE-Server zentralisieren Rechenkapazität und Verwaltung. Spezielle Anforderungen an die Hardware-Eigenschaften, wie zum Beispiel die Erweiterbarkeit mit Steckkarten, 3D-Grafikbeschleunigern oder Videokarten schränken den Einsatz von WBTs ein. Dort, wo diese Hardware-Eigenschaften aber nicht gefragt sind, läßt sich ein PC durch ein WBT ersetzen.

Sehr oft werden CD-ROM-Brenner, Scanner oder CAD-Applikationen auf den PCs selbst installiert, die Office-Programme aber von einem zentralen Server aus genutzt. Der ICA-Client führt auf dem Rechner lokale und zentrale Applikationen nahtlos zusammen.

Bei Arbeitsplätzen für die Software-Entwicklung sollten Administratoren beachten, daß maximal 20 Benutzer auf einem hochausgebauten zentralen Server gleichzeitig arbeiten können. Erstens kann dort ein Compiler die CPU für Stunden beschäftigen, und zweitens sind das Poweruser-Arbeitsplätze, die mindestens acht Stunden am Tag genutzt werden.

Problemfall Anwenderakzeptanz

Da der PC in den letzten Jahren immer mehr zu einem Statussymbol geworden ist und die Taktrate des Prozessors offensichtlich etwas darüber aussagt, welche Stufe man in der Bürohierarchie erklommen hat, können sich Akzeptanzprobleme beim Anwender ergeben. Und ohne CD-ROM- und Floppy-Laufwerk degradiert man die Benutzer zu reinen Anwendern. Eigentlich genau das, was sich die Administratoren wünschen.

Die Verantwortlichen sollten jedoch den Widerstand der User nicht unterschätzen. Es geht hier vor allem darum, sie vom zentralen Modell zu überzeugen. Gelingt das, entwickelt sich die Einführung zentraler Lösungen zum Selbstläufer. Wenn Argumente wie hohe Verfügbarkeit, geringe Gefahr von Datenverlusten, hohe Performance, neueste und einheitliche Programmversionen nicht locken, dann überzeugen vielleicht die gute Ergonomie, größere Bildschirme oder die Realisierbarkeit von Home Offices.

In den Testläufen für die zentral orientierten DV-Systeme machen Unternehmen leider oft immer wieder die gleichen Fehler. Es wird ein einziger Test-Server eingerichtet, der gleichzeitig als Domain Controller dient, denn man möchte in einer separaten Domäne testen. Zusätzlich packen sie auch die restlichen Windows-NT-Dienste auf diese eine Maschine, inklusive Dynamic Host Configuration Protocol (DHCP), Domain Name Service (DNS) sowie Print- und File-Services. Und da die Oberfläche mit der von Windows NT 4.0 identisch ist, wird auch die Software über den Aufruf von "setup. exe" installiert, ohne vorher in den Install-Modus von TSE zu schalten. Übereilt werden alle im Unternehmen eingesetzten Softwarepakete einschließlich 16-Bit-Software und DOS-Anwendungen aufgespielt, obwohl kein PC im gesamten Unternehmen alle Programme liefern muß. Da die Kompatibilitäts-Scripts den meisten Systemadministratoren unbekannt sind, funktionieren die Applikationen für denjenigen, der sie installiert hat, nicht aber für andere Benutzer. Nach Prüfung des Admins wird der Server zur Benutzung freigegeben, und spätestens nach ein paar Tagen ist das Thema "TSE" meist wieder vom Tisch.

Die Tests verlaufen dann erfolgreich, wenn die Verantwortlichen die Grundideen des Internet-Computing-Modells beachten und die TSE-Server als reine Applikations-Server betreiben. Auch wenn der TSE prinzipiell alle Windows-NT-Dienste installieren läßt, kann man davon nur dringend abraten. Der Test sollte mit zwei Servern starten, um auch die Load-Balancing-Funktion als wesentlichen Bestandteil der Lösung ausprobieren zu können.

Zuerst sollten sich die Tester überlegen, welche Applikationen in Zukunft tatsächlich auf dem TSE abgelegt werden. Wenn für wenige Arbeitsplätze noch ein DOS- oder 16-Bit-Programm notwendig ist, dann sollte man für diese Arbeitsplätze auch in Zukunft einen PC vorsehen. Die 16-Bit- und DOS-Integration von Windows NT ist bekanntlich sehr ressourcenintensiv.

Für die Installation und Anpassung eines neuen Programms sollten sich die Administratoren auf jeden Fall Zeit nehmen. Der abschließende Test sollte mit einem Domain-Benutzer erfolgen, um auch die Rechte im NT-Dateisystem NTFS überprüfen zu können. Die eingestellten NTFS-Rechte unter Windows NT und TSE sind ein weiterer Punkt, der saubere Arbeit erfordert. Manche Programme verweigern ihren Dienst, wenn man die Rechte zu weit einschränkt. Ein offenes NTFS wird dagegen bereits nach kurzer Zeit einige Dateien vermissen lassen.

Die Probleme mit TSE sind unabhängig von der Größe der Installation. Oft ist sogar eine größere Installation mit weniger Problemen behaftet als eine kleinere, da dort in aller Regel mehr Ausweich-Server zur Verfügung stehen. Schwierigkeiten kann es zum Beispiel mit Druckertreibern geben, die beim TSE die gefürchteten Blue-Screens verursachen können. Hewlett-Packard hat erst vor kurzem seine Druckertreiber komplett an TSE angepaßt. Gleiches gilt für Faxanwendungen, die leider oft auf IP-Adressen-Basis programmiert sind.

Die Software selbst muß nicht speziell für TSE geschrieben sein, denn das Betriebssystem macht jedes Programm Multisession-fähig. Wenn eine Software nach den Richtlinen von Microsoft programmiert wurde, sind keine Anpassungen notwendig. Leider verwenden aber einige Hersteller fälschlicherweise immer noch die "Hive HKEY-Local-Machine" zum Speichern von anwenderspezifischen Einstellungen; dann muß das Programm nachträglich mit Hilfe von Scripts angepaßt werden.

Ausfälle des Netzwerks werden über eine Disconnect/Reconnect-Technologie entschärft. Sollte tatsächlich einmal das Netzwerk in die Knie gehen, wird die aktuelle Session auf dem Server gehalten und der Anwender kann sich jederzeit wieder in seine Session einschalten und seine Arbeit da fortsetzen, wo er unterbrochen wurde.

Das GUI bei der Verwaltung von PCs gaukelt vielen eine einfache Administration vor, und der Aufruf einer "setup.exe"-Datei installiert innerhalb weniger Minuten komplexe Anwendungen von einigen hundert MB auf die Festplatte. Aber genau diese scheinbare Einfachheit hat zu einem Wildwuchs in der PC-Welt geführt. Jeder DV-Verantwortliche muß den Rollout einer neuen Applikation akribisch planen, und die Zweifel, ob danach alles noch funktioniert, werden bis zuletzt an den Nerven der Administratoren nagen.

Zentrales Server-based Computing muß jedoch genauso sorgfältig geplant werden. Die Konfiguration bleibt ebenfalls schwierig. Ist diese Lösung aber erst einmal installiert und sind die Clients verteilt, wird vieles in der Administration deutlich einfacher.

Hier noch einmal zusammengefaßt die wichtigsten Punkte, die es zu beachten gilt:

- Testen, Pilotieren, Installieren, Dokumentieren (Software, Hardware, Updates),

- Start mit mindestens zwei TSE-Servern,

- Auslagern der Daten auf separate, zentrale Server,

- Einführung von Scripts zur Verwaltung,

- Testen der Applikation an einem lokalen PC und über den TSE als Domain-Benutzer sowie

- Zusammenarbeit mit erfahrenen Partnern beim Test und der Einführung.

Wenn alle Hürden der zentralen Server übersprungen sind, werden die Anwender dafür mit einem stabilen, performanten und kostengünstigen DV-System belohnt. Auch der Umstieg auf Windows 2000 wird wesentlich erleichtert, da dieses bereits von Haus aus Multiuser-fähig sein soll und laut Hersteller dem Anwender nach der Installation auf zentralen Servern in kürzester Zeit an jedem Arbeitsplatz zur Verfügung stehen wird.

Angeklickt

Der Umstieg der Unternehmens-DV auf ein Client-Server-Modell sollte genauestens geplant und getestet werden. Sonst entwickelt sich das Ganze schnell zum Alptraum für Verantwortliche und Anwender. Unter anderem müssen die Kapazitäten der Server und des Netzwerks geplant werden. Zwar gibt es dafür Faustregeln, anhand derer eine grobe Orientierung möglich ist. Wie die Rechner letztendlich dimensioniert werden müssen, finden die Administratoren jedoch nur durch umfangreiche Testläufe heraus.

*Ralf Siller ist Vertriebsleiter bei der GTS-GRAL GmbH in Darmstadt.Empfohlenes Buch:Microsft Windows NT 4.0 Terminal Server Edition einsetzen. Autor: Dr. Bernhard Tritsch; ISBN 3-86063-499-2.