Hinter Server-based Computing verbirgt sich ein Paradigmenwechsel: Die Nutzapplikationen laufen nicht auf teuren und aufwändig zu wartenden Clientrechnern, sondern auf einem oder mehreren Terminalservern. Das vereinfacht die Softwarewartung und verbessert die Verfügbarkeit des Systems.

Wer Direktor eines inhomogenen und auch örtlich verstreuten Client-Zoos ist, hat Grund, öfter sein Schicksal zu verfluchen. Entweder befehligt er eine Horde mobiler PC-Pfleger, die täglich Turnschuh-Administration betreibt. Oder er muss ein Konglomerat von Inventarisierungs-, Patchmanagement- und Remote-Software einsetzen, die nicht nur das Budget belastet, sondern auch selbst viel Pflege braucht.

Deutlich höher als die Anschaffung eines professionellen PC-Arbeitsplatzes liegen laut Untersuchungen, etwa der Gartner Group, die jährlichen Folgekosten von 4000 bis 7000 Euro für Administration, Wartung, Support und die informelle Unterstützung von Anwendern.

Die Lösung kann ein Paradigmenwechsel hin zum so genannten Server-based Computing und Terminalservices bringen. Dabei laufen die Applikationen nicht auf den Clients, sondern auf einem oder mehreren großzügig dimensionierten Servern (Terminalserver). Die Vorteile: Konfigurationen und Patchmanagement finden zentral statt und lassen sich sehr gut ausrollen. Außerdem sinken die Anforderungen an die Clients, was deren Nutzungszeitraum verlängert und Ausstattungsunterschiede egalisiert. In der Reinform kann man sich für dedizierte Thin Clients entscheiden, das sind plattenlose, Strom sparende, für den Terminalbetrieb optimierte (Linux-)Rechner (siehe Kasten “Thin Clients”).

Applikationen und User profitieren von zentral einfacher implementierbarer Hochverfügbarkeit. Bis zu 80 Prozent der Betriebskosten sollen sich durch zentrale Administration einsparen lassen, andere Quellen sprechen von bis zu 56 Prozent (IDC) oder 41 Prozent (Gartner) niedrigeren TCO im Vergleich zur Client-Server-Architektur. Eingerechnet haben die Marktforscher die Einsparungen über den Arbeitsplatzrechner-Lebenszyklus, der bei Thin Clients länger ist.

Die Kostenvorteile haben dazu beigetragen, dass das Konzept des Server-based Computing in nahezu allen Großunternehmen, aber auch vielen kleineren Firmen und Bildungseinrichtung Eingang gefunden hat. Wer nun ebenfalls überlegt, entweder komplett umzusteigen oder erstmal einzelne Applikation zu zentralisieren, sollte sich nach der passenden Steuersoftware umsehen – die folgenden Artikel beschreiben praxiserprobte Lösungen.

Ressourcen gemeinsam auf dem Server

Eine zentrale Maschine simultan auf mehrere Benutzer aufzuteilen mag auf den ersten Blick kontraproduktiv erscheinen. Aber es gibt mehrere Faktoren, die den Mehrbenutzerbetrieb begünstigen. Bei typischen Büroapplikationen verbringt ein PC den Großteil seiner Zeit im Leerlauf. Lediglich Benutzerinteraktionen wie das Ändern der Schrift in einer Textverarbeitung bewirken kurze Lastspitzen, die mit zunehmender Prozessorleistung sogar schmaler werden.

Schnelles Antwortverhalten der Applikationen ist durchaus erwünscht, denn niemand wartet gern, bis sich eine Aktion wie die im Beispiel genannte Schriftartänderung auswirkt. Allerdings bleiben im Einzelbenutzerbetrieb auf PCs Ressourcen so zwangsläufig ungenutzt, während sich bei mehreren Benutzern eine wesentlich effektivere Auslastung ergibt (siehe Abbildung 1).

Abbildung 1: Die Zeiträume, in denen ein typischer Office-Rechner nichts tut, sind viel größer als jene Zeiten, in denen er unter Last steht. Mehrere Benutzer sorgen statistisch gesehen für eine bessere Auslastung, ohne dass sie sich dabei gegenseitig ausbremsen.

Terminalserver profitieren zusätzlich davon, dass Linux den Code von Anwendungen und Bibliotheken nur ein einziges Mal in den Speicher lädt, unabhängig davon, wie viele User sie aufrufen. Es bilden sich so Schnittmengen der von den Benutzern beanspruchten Speicherbereiche. Die Menge des zur Laufzeit angeforderten Speichers gestaltet sich zwar weiterhin individuell für jede aufgerufene Instanz. Gleichwohl kommunizieren die Anbieter von Terminalsoftware praxiserprobte Richtwerte, die sich meist zwischen 64 und 256 KByte pro eingeloggtem Anwender bewegen.

Zentrales Management

Der größte Brocken der Kosteneinsparung durch Server-based Computing entsteht durch das zentralisierte Management. Denn die Sicherheit und Verfügbarkeit der Applikationen liegt in kompetenten Händen, nämlich bei Administratoren. So kümmern sich nicht die Anwender, sondern Profis um das Betriebssystem- und Programm-Patchmanagement. Die brauchen sich dazu nicht von ihren Arbeitsplätzen wegzubewegen. Gleiches gilt bei Software-Rollouts, die in großen Firmen statt innerhalb vieler Wochen, auf dem zentralen Server meist in wenigen Stunden erledigt sind.

Unterm Strich erreicht Server-basierte IT eine höhere Verfügbarkeit und bessere Mitarbeiterproduktivität. Ein vielfach willkommender Nebeneffekt ist, dass der Fernzugriff externer Mitarbeiter über Mobilgeräte oder aus einem Internetcafé einfacher realiserbar ist. Die Praxis zeigt auch, dass in größeren Organisationen bei zentralisierten Applikationen die Neigung zunimmt, die Versionsstände zu konsolidieren – mit allen damit verbundenen Vereinfachungseffekten.

Welchen Client nehmen?

Generell sinken die Anforderung an den Client, wenn die Nutzapplikationen auf dem Server laufen. Das erhöht deren Nutzungszeit und spart beim Einsatz von Thin Clients spürbar Strom [1]. Mit wachsender Anzahl der Clients skalieren beide Effekte positiv. Drei Arten von Clients lassen sich unterscheiden:

• Klassischer PC (Fat Client), der nur die Ausgabe ausgesuchte
  Applikationen vom dem Server bezieht.
• Thin-Client-artig arbeitender PC ohne Festplatte, der sein
  Betriebssystem von einem USB-Stick, einem Spezialspeicher zum
  Aufstecken auf die ATA-Schnittstelle, bootet. Noch besser ist, per
  Etherboot [2], Netboot [3], Bootix [4] oder PXE [5] übers
  Netzwerk zu booten. Die meisten dieser Netzkonzepte fußen auf
  bekannten Protokollen wie BOOTP, DHCP und TFTP.
• Echte Thin Clients, die nur übers Netz booten (siehe
  Kasten “Thin Clients”).

Thin-Client-Hersteller liefern oft sowohl angepasste Client-Betriebssysteme (Linux oder Windows) als auch ganz passable Managing-Tools, die anhand der eigenen Vorgaben zu evaluieren normalerweise lohnt. Beispielsweise ist gerade Neolinux 4.0 von Neoware erschienen – mit eingebautem Citrix- und NX-Client sowie lokalem USB-Support.

Wer für einen Thin-Client-artig arbeitenden PC oder einen nackten Thin Client ein Betriebssystem sucht, ist oft mit Thinstation [6] ganz gut beraten. Die Linux-Distribution spricht nämlich alle wichtigen Protokolle dieses Umfelds: Citrix ICA, Nomachine NX, 2X Thinclient, RDP, Cendio Thinlinc, Tarantella, X11, SSH, Telnet und VMS Term.

Der LTSP-5-Artikel ab Seite 40 beschreibt eine interessante und einfach einzurichtende Alternative, die Edubuntu einsetzt. Er erklärt nochmals mehrere Bootkonzepte, den Bootstrap sowie NFS und beschreibt, was der Server an niederen Diensten vorhalten muss. Auch die Infos [2] bis [5] halten Links zu den Server-Voraussetzungen vor.

Generell ist gegenwärtig ein Trend zu LDAP zu erkennen, gegen das sich die User authentifizieren. Apropos: Beim Anmelden auf den Clients merken die Benutzer keinen Unterschied zu normalen Linux-Clients – sie bekommen nämlich auch hier einen XDM, KDM oder GDM präsentiert.

Abbildung 2: Der Thin Client Compact 3210 LX der Firma Igel besitzt einen Smartcard-Reader und -Writer, zahlreichen I/O-Ports, WLAN und Dualview-fähige VGA- und DVI-Ausgänge. Auf dem lokalen Linux arbeiten X11R6, Firefox und ein PDF-Reader, ICA, Extended Program Neighborhood, RDP, eine Terminalemulation-Suite mit Kerberos, Thinprint, VoIP-SIP-Client sowie zwei VPN-Arten alternativ.

Software für den Terminalserver

Eigentlich sollte dieser Abschnitt des Artikels sehr kurz sein: “Nimm X11!”, denn das X-Protokoll ist komplett netzwerktransparent. Wer nun einwendet, die Kommunikation zwischen Server und Client laufe im Klartext, dem dürfte man antworten: “Nimm SSH!”. Das Protokoll kümmert sich nicht nur um Verschlüsselung, sondern komprimiert auch noch etwas und sorgt für das Setzen der Display-Variablen.

Leider kann dieser Abschnitt hier nicht enden, denn in der Praxis zeigt sich, dass das X-Window-System über Rechnergrenzen hinweg langsam und mit hohen Latenzzeiten geschlagen ist. Grund sind die Architektur von X11 und die ineffiziente Programmierung mancher X-Applikationen.

Ein Ausweg kann sein, die Netzwerktransparenz von X zu ignorieren und den Bildschirminhalt einfach mit Programmen wie dem VNC-Server zu übertragen, was nachgewiesen sowohl mit Linux als auch mit Windows funktioniert (Tight VNC, Ultra VNC, VNC 4). Die Remote-Software tut sich zudem leicht, bestehende Sitzungen umzuleiten, was für den User-Helpdesk gut ist. Fürs dauerhafte Arbeiten aber genügen Performance und Farbtiefe meist nicht.

Bleiben nur völlig neue Protokolle. Spätestens hier muss das Wort “Citrix” fallen – lange Jahre faktisch für “Terminalserver” das, was “Tempo” für “Papiertaschentücher” bedeutet. Das zugehörige Produkt heißt Citrix Presentation Server ([7], früher Metaframe). Sein Bandbreite sparendes ICA-Protokoll überträgt nur Grafikdaten, die sich tatsächlich auf dem Server ändern. Außerdem: Clients gibt es für fast jedes Betriebssystem, die Serversoftware auch (siehe Abbildung 3).

Abbildung 3: So stellt sich die Firma Citrix das Server-based Computing der Zukunft vor: Auf dem Server laufen alle Applikationen, mobile und stationäre Clients dienen nur noch der Anzeige.

Am Markt herrschen trotzdem Citrix-Serverinstallationen mit Windows vor. Das mag an den Lizenzkosten liegen, die Citrix verlangt. In den letzten ein, zwei Jahren dürfte auch NX dazu beigetragen haben (siehe ausführlicher Artikel in diesem Schwerpunkt). Das ausgebuffte Protokoll der italienischen Firma Nomachine selektiert und komprimiert die zu übertragenden Daten derart effizient, dass es sich selbst über dünne Leitungen fließend arbeiten lässt. Neben einer kommerziellen Variante gibt es zusätzlich die freie Version Free NX.

Eingermaßen problematisch ist die notwenige Serverhardware zu planen, denn zum einen kann man den Usern nicht vorschreiben, ihre rechen- und I/O-intensiven Arbeiten möglichst so zu legen, dass sie niemanden behindern. Zum anderen soll ein Terminalserver einige Jahre halten und nicht wegen des technischen Fortschritts der Software bereits vor der Abschreibung obsolet sein. Kein Weg geht an schnellen Plattensystemen, also Raids, vorbei. Neben ordentlich RAM muss man bei der Hardwarebestellung in die obere Etage der CPU greifen – in der Regel zur Mehrprozessormaschine. Sobald Hunderte Clients zu versorgen sind, läuft es auf einen starken Terminalserver-Pool mit dynamischer Lastverteilung hinaus.

Welche Applikationen eignen sich?

Nicht alle Anwendungen lassen sich gleichmaßen gut auf einem Terminalserver betreiben: Office-Programme, Enterprise Resource Management (ERP) und Customer Relationship Management (CRM) eignen sich gut, wie die Praxis beweist. CAD und vergleichbare grafikintensive Applikationen sowie Multimediaprogramme hingegen tun sich schwerer, da die Grafikdaten sich ja ihren Weg durchs Netz bahnen.

Hier muss entweder die verwendete Terminalsoftware sehr intelligent vorgehen und komprimieren oder – und das wird wohl die häufigere Variante sein – man legt die betroffenen (meist wenigen) Arbeitsplätze besser als Fat Clients aus. Auch Notebooks sind beim Server-based Computing prinzipbedingt weniger geeignet und eher Kandidaten, die als Fat Clients arbeiten, da sie keine permanente Onlineverbindung zum Server besitzen. Doch Vorsicht: Solche gemischten Umgebungen sind aufwändiger zu warten, was schon in der Planungsphase geeignet einzuarbeiten ist.

Windows auf Abwegen

Es ist kein Geheimnis, dass Tausende Branchenlösungen nur für die Windows-Plattform erhältlich sind. Der pragmatische Ansatz in einer Firma sieht vor, die meist wenigen Nur-Windows-Applikationen auf einem Windows-Server laufen zu lassen und per Terminaldienst an die Linux-Clients zu verteilen. Dafür gibt es viele, viele Möglichkeiten, von denen einige schon vom Linux-Server her bekannt sind: VNC, Citrix [7] oder Hoblink JWT ([8], siehe auch Kasten “Beispiel aus der Praxis I”).

Beispiel aus der Praxis I

Roman Hebel arbeitet im Direktorium der Landeshauptstadt München, Hauptabteilung III – Informationstechnologie. Linux-Magazin: Herr Hebel, Sie arbeiten in der IT der Münchner Stadtverwaltung, die rund 14000 Arbeitsplätze auf Linux-Desktopsysteme umstellt. Das Projekt nennt sich Limux, eine Verschmelzung der Wörter Linux und München. Sie haben sich in diesem Rahmen auf Terminalserverdienste spezialisiert? Hebel: Ja, meine Abteilung bietet Terminalserverdienste als zentrale Dienstleistung für die Referate der Stadt München an. Diese Aufgabe ergibt sich aus der Migration der Fachverfahren, die bisher auf Windows NT 4.0 oder 2000 Workstation liefen und nun auf dem Limux-Basiscilent funktionieren sollen. Hier gibt es im Grunde zwei Migrationswege – zum einen die Webanwendung, die betriebssystemunabhängig ist, zum anderen das Erstellen einer nativen Linux-Anwendung. Geht das nicht, bieten wir die Anwendung übergangsweise per Terminalserver an. Am Beginn stand eine Testphase: Die Kollegen, die eine Anwendung auf den Terminalserver umziehen lassen wollten, installierten sie mit mir auf Windows 2003 Server. Dabei stellten wir fest, dass nicht alle Anwendungen auf einem 64-Bit-System funktionieren. Linux-Magazin: Welche Software, welches Protokoll setzen Sie ein? Hebel: Als Clientsoftware benutzen wir Hoblink JWT Enterprise Access [8]. Sie verwendet das RDP-Protokoll von Microsoft, das ein Windows-Server bereits mitbringt, während Citrix ein eigenes Protokoll spricht. Zudem haben wir festgestellt, dass die Citrix-Produkte mehr Funktionen bieten als wir benötigen. Den Hob-Client bieten wir auf einem Webserver an. Der Anwender besucht die Seite, auf der er zunächst ein Session-Manager-Applet findet, in dem er die Sitzungsart auswählt. Der Session-Manager liest die Einstellungen für diesen Benutzer, beispielsweise die Bildschirmauflösung, von einem LDAP-Server und bietet dann einen bereits parametrisierten und personalisierten Java-Client zum Download an. Der stellt die Verbindung zum Terminalserver her. Er spricht unsere normalen Arbeitsplatzdrucker an, für Sonderfälle wie einen DIN-A2-Farbdrucker habe ich schon einen eigenen Treiber auf dem Terminalserver installiert. Der Vorteil besteht darin, dass man auf dem Arbeitsplatzrechner nichts benötigt als einen Webbrowser und eine Java Virtual Machine – beides ist im Limux-Basis-Client vorhanden. Die Installation eines eigenen Terminalserver-Clients entfällt und die Konfiguration lässt sich zentral auf einem LDAP-Server ablegen. Linux-Magazin: Welche Anwendungen liefern Sie über den Dienst aus? Hebel: Über diesen Terminalservice stellen wir beispielweise unserer Entwicklungsabteilung Natural, eine IDE von der Software AG, zur Verfügung. Auch die Helpdesk-Software Assyst von Axios Systems betreiben wir so. Für Assyst gibt es zwar inzwischen eine Web-Version, die bietet aber weniger Funktionen. Ähnlich ist es beim SAP-Client, den drei Sachbearbeiter im Direktorium per Terminalservice benutzen. Außerdem halten wir noch Microsoft-Office-Produkte vor, um gelegentlich Dokumente und Vorlagen zu öffnen, die in Open Office nicht funktionieren. In den nächsten Monaten erwarte ich Anfragen für andere Applikationen, wenn weitere städtische Referate auf den Linux-Arbeitsplatz umstellen.

Selbst Microsofts Pendant zur Citrix-Software kommt hier ins Spiel, das Remote Desktop Protocol (RDP), das Windows-Betriebssysteme sprechen. Es gibt einen Linux-Client dafür, der sich beispielsweise gut zum Managen eines Windows-Servers von Linux-Rechnern aus eignet. Der Rdesktop-Artikel in diesem Schwerpunkt stellt ihn vor. Eine Alternative ist Thinsoft Winconnect. [9]

Tarantella war früher ein sehr wichtiger Mitspieler im Softwaremarkt für Windows-Terminalserver, spielt aber heute keine Rolle mehr. Durch die Dotcom-Zeit gebeutelt [10] und in die glücklosen Hände von SCO geraten, dem heutigen Linux-Gegner Nummer 1, kaufte Sun Mitte 2005 den Scherbenhaufen und machte es zum Bestandteil der hauseigegen Thin-Client-Lösung [11].

Wer trotz Windows-Applikationen die Nummer mit dem Windows-Server nicht mitmachen möchte, darf sich neben Produkten von VMware [12] und Win4Lin [13] die Möglichkeiten des Windows-Emulators Wine vergegenwärtigen. Der Artikel ab Seite 49 hilft bei der Auswahl der Tools und erklärt, welche Art Windows-Programme damit gut laufen.

Was schiefgehen kann

Wer mit einem Umstieg liebäugelt, muss sich vergegenwärtigen, dass die Einführung von Server-based Computing intern auf Widerstände treffen kann. Im Zuge eines Change-Managements sollten die Verantwortlichen die Mitarbeiter darum früh von den Vorteilen des Konzepts überzeugen. Sonst werden die Anwender selbst kleine Ungereimtheiten in der Anfangszeit dazu nutzen, das ganze Konzept in Frage zu stellen. Auch muss die IT den Benutzern sagen, dass sie nicht mehr ohne Weiteres eigene Programme installieren können beziehungsweise sollen – der alte Zielkonflikt: Benutzerrechte gegen Adminpflicht.

Fast ebenso wichtig: Der Wechsel der Architektur verändert eventuell einige Geschäfts-, insbesondere Informationsabläufe. Wer viele Anwendungen in der Firma betreibt, sollte beim Server-based Computing darum besser nicht die radikale Komplettlösung mit Thin Clients fordern, sondern die vorhandenen PCs behalten und die Applikationen Zug um Zug auf Terminalserver migrieren. Dabei stellt der Benutzer keine oder kaum Leistungs- und Komfortunterschiede gegenüber traditionellen PC-Clients fest.

Beispiel aus der Praxis II

Horst Bräuner ist EDV-Koordinator in der deutschen Stadt Schwäbisch Hall. Linux-Magazin: Ihre Heimatstadt setzt seit Langem auf Linux. Man kann lesen, Sie hätten auch ein Konzept für einen Open-Source-Thin-Client erstellt. Herr Bräuner, was wurde aus dem Prototyp? Bräuner: Die Geräte sind derzeit in 17 Kindergärten im Produktiveinsatz. Die Mitarbeiter dort bekommen ihren individuellen Linux-Desktop von einem Terminalserver zur Verfügung gestellt und erledigen damit ihre Verwaltungsaufgaben. Wir haben den Thin Client im Jahr 2006 genau so implementiert, wie es Nico Gulden in seinem Arbeitspapier für die Linux Solutions Group beschreibt [14]. Die Kindergärten sind per VPN an unsere Zentrale in der Stadtmitte angebunden. Der Linux-Desktop läuft zentral und die Thin Clients bekommen ihn über einen Nomachine-Server präsentiert. Linux-Magazin: Wofür sonst setzen Sie Server-based Computing ein? Bräuner: Es gibt Fachanwendungen, die nur ein Windows-GUI besitzen und daher nicht auf unseren Linux-Desktops laufen. Nun könnten wir direkt vom Linux-Desktop aus auf den Windows-Terminalserver zugreifen lassen, auf dem die Fachapplikation läuft. Dann bräuchten wir aber jeweils einen individuellen Desktop, der gepflegt sein will. Da wir Nomachine anwenden, gehen wir zweistufig vor: Der Client kontaktiert den Nomachine-Server, der per RDP auf den Windows-Terminalserver zugreift. Damit realisieren wir den gleichen Zugang, ob man nun von Windows, Linux oder Mac kommt, da es die Clientsoftware für alle Betriebssysteme gibt. Linux-Magazin: Um welche Art Anwendungen geht es genau? Bräuner: Beispielsweise um Standesamt-Software. Die lassen wir nun neu entwickeln, damit sie in Zukunft nativ unter Linux läuft. Daneben gibt es viele kleine Verfahren, etwa Auskunft-Software vom Tarifvertrag TVÖD bis hin zu Waffen- und Sprengstoffvorschriften. Im Prinzip ist das immer so Kleinkram: Eine Datenbank mit GUI, teilweise in Microsoft Access oder in Foxpro gemacht. Immer für ein, zwei Arbeitsplätze entwickelt, aber so etwas hält bei der Migration zu Linux auf. Wir haben einfach alle Verfahren eingesammelt, auf den Terminalserver gepackt und per Nomachine auf die Clientdisplays gebracht. Wir haben zwei Windows-Teminalserver mit je einem Nomachine-Server davor, die 20 bis 30 Anwendungen ausliefern. Linux-Magazin: Stand die freie NX-Version für Ihre Zwecke auch zur Debatte? Bräuner: Ich kenne die jüngsten Entwicklungen bei Free NX nicht, aber zumindest eine Weile lang passierte dort nichts – was ich übrigens bei Community-Software für ganz normal halte. Um an den neuen Entwicklungen teilzuhaben, holten wir uns die kommerzielle Variante, auch um nötigenfalls Support zu erhalten. Bisher mussten wir den aber nicht in Anspruch nehmen. Ich werde mir ansehen, wie sich Free NX entwickelt hat. Das Nomachine-Produkt setzen wir auf jeden Fall schon seit drei, vier Jahren für die Fachanwendungen ein, bei unserem Thin Client war die NX-Technologie bereits Teil des Konzepts. (Interviews: Mathias Huber)

Wann umsteigen?

Wer seine vorhandenen PCs zu Thin Clients umfunktionieren möchte, kann das jederzeit tun. Ein guter – gemeint ist ein ökonomisch sinnvoller – Zeitpunkt ist, wenn neue Server ins Haus kommen, da diese höheren Anforderungen genügen müssen als bisher. Wer auf echte Thin Clients setzen will, tut dies, wenn das Abschreibungsende eines Großteils der vorhandenen PCs erreicht ist und die bestehenden Softwarelizenz- und Supportverträge auslaufen.