Praxis Thin-Clients: Die Infrastruktur muss passen

Während des Rollouts von Anwendungen testen Unternehmen zumeist die Performance neuer Systeme, indem sie Pilot-Programme einrichten oder das Netzwerk in einer Testumgebung betreiben, die reale Anwendungsbelastungen simuliert. Dieser Ansatz bietet normalerweise einen guten Ausblick darauf, auf welche Art die Unternehmensanwendungen das System belasten werden – bei Thin-Clients ist die Sache jedoch ganz anders.

Das liegt daran, dass konventionelle Test-Tools bisher keine Möglichkeit hatten, die tatsächliche Erfahrung des Thin-Client-Anwenders zu überwachen. Tools zur Serverüberwachung – wie Citrix Resource Manager oder NTP Software System Sentinel – werden üblicherweise auf dem Server installiert und bieten einen guten Überblick darüber, wie gut die Server-Farm die Anwendungen laufen lässt. Solche Tools geben jedoch normalerweise nur wenige Hinweise darauf, welche Performance auch auf den im ganzen Land verteilten Bildschirmen der Anwender ankommt, und Performance-Probleme werden zumeist erst dann erkannt, wenn die Anwender beim Help-Desk anrufen, um sich zu beschweren.

Ein kritisches Problem: Thin-Client-Lösungen mögen sich zwar mit Leichtigkeit skalieren lassen, wenn nur einige Dutzend Anwender hinzugefügt werden, ist die verfügbare Bandbreite jedoch ausgenutzt oder läuft der Anwendungsserver mit voller Kapazität, kann ihnen auch schnell die Luft ausgehen.

Der Bedarf zur Abschätzung der Anwendungsperformance beim Endanwender hat häufig zu einer noch strengeren Evaluierungsperiode vor dem Rollout von Thin-Client-Systemen in die Produktion geführt. So bot Sun Microsystems seinem Integrationspartner Frontline Systems beispielsweise an, während der Designphase des für 600 Arbeitsplätze ausgelegten Thin-Client-Systems für NSW TAB (das staatliche Wettbüro des australischen Bundesstaats New South Wales) seine zwei Millionen Dollar teure Versuchseinrichtung iForce Ready Centre zu nutzen. TAB setzt die Thin-Clients von Sun Ray als Support-Terminals im Call-Center ein. Unterstützt werden sie von E402R-Servern von Sun Enterprise, die bei der Verarbeitung von 22 Millionen Anrufen jährlich behilflich sind.

Das Testen eines Thin-Client-Systems unter realen Bedingungen kann zwar dazu beitragen, die richtige Anzahl der benötigten Server herauszufinden, es ist jedoch ein von Natur aus trügerisches Maß für die Performance in der realen Welt: Im echten Einsatz wird die Performance von Dingen wie der Netzwerk-Latenz, variierenden Belastungen und dem Kampf zwischen anderen Anwendungen und administrativen Prozessen (etwa Backups) um Server-Ressourcen beeinflusst. Selbst rudimentäre Multimedia-Anwendungen – Flash-Animationen oder Video in niedriger Bandbreite – können sich für Thin-Client-Software, die mit Höchstlast arbeiten muss, um einen Bildschirminhalt über eine häufig sehr langsame Verbindung zu übertragen, zu einem großen Problem auswachsen.

Dies führt zu Schwankungen in der Performance verschiedener Thin-Client-Technologien. So ergab eine kürzlich von PC Magazine Labs und von Jason Nieh von der Columbia University durchgeführte Analyse, dass es beträchtliche Effizienzunterschiede zwischen RDP (Remote Data Protocol, eingesetzt in Microsoft Terminal Services), dem RFB-Protokoll der Thin-Client-Software Virtual Network Computing (VNC) von AT&T und der von Citrix MetaFrame verwendeten ICA (Independent Computing Architecture) gab. VNC lief unter Linux, RDP und ICA liefen unter Windows 2000.

Während des Transfers einer 63sekündigen Videodatei, die 13,74 MB groß war, übertrug RDP unter Windows NT 117,93 MByte an Daten (der Unterschied ist größtenteils auf Steuerungsinformationen zurückzuführen). Im Gegensatz dazu wurden in einer ICA-Umgebung 42,48 MByte an Daten und 0,86 MByte über RFB übertragen (VNC lieferte allerdings ein unbrauchbares Video, so dass diese Zahl nicht korrekt ist). Unter Windows 2000 übertrug RDP 30,38 MByte an Daten an den Thin-Client, während ICA nur 21,83 MByte und RFB nur 1,19 MByte bewegte (wobei letzteres wiederum nicht korrekt funktionierte). Der Server basierte in diesen Tests auf einem Pentium III mit 550 MHz, während auf dem Thin-Client ein Pentium II Prozessor mit 300 MHz lief.

Solche Studien zeigen die großen Schwankungen auf, die bei der Verarbeitung von Datenströmen durch die unterschiedlichen Thin-Client-Protokolle existieren. Allerdings wird nicht klar, worin diese Unterschiede bestehen, denn die internen Arbeitsweisen der Protokolle sind nur schlecht dokumentiert. Feinheiten im Design von Thin-Clients bestätigen jedoch, dass nicht alle Thin-Client-Umgebungen gleich geschaffen sind. Es kann sich daher als schmerzhaft ungenau erweisen, wenn man sich bei der Bereitstellung von Serverausrüstung auf einfache Faustregeln verlässt. Auch konventionelle Benchmarks können daran wenig ändern, denn sie messen die Geschwindigkeit, mit der der Server die Anwendungen ausführt. Da die Protokolle jedoch Datenpakete fallen lassen, um auch langsame Verbindungen aufrecht zu erhalten, sind diese Benchmarks nicht in der Lage, die Nutzbarkeit zu messen.

Nachdem sie dieses Problem erkannt hatten, veröffentlichten Nieh und einige Kollegen im vergangenen Februar ihre Arbeit, in deren Rahmen sie das von ihnen so genannte „Slow-Motion-Benchmarking“ entwickelt haben – das ihnen zufolge eine sehr viel genauere Methode für die Evaluierung von Thin-Client-Einsätzen ermöglicht. Beim Slow-Motion-Benchmarking werden die Netzwerkverbindungen zwischen dem Thin-Client und dem Server aufgezeichnet, während gleichzeitig ein konventioneller Benchmark durchgeführt wird. In den gesamten Benchmark-Verlauf werden Verzögerungen eingebaut, die bewirken, dass für Erneuerungen des Bildschirminhalts auf der Client-Seite ausreichend Zeit bleibt. Auf diese Weise lässt sich der vollständige Output der Thin-Client-Technologie untersuchen.

Zur Beurteilung dieses Ansatzes testete das Team RDP, RFB, ICA und die Thin-Client-Technologie Sun Ray von Sun beim Ausführen der in der Test-Suite i-Bench von Ziff-Davis enthaltenen Web- und Multimedia-Anwendungen. Diese wurden über verschiedene simulierte Link-Geschwindigkeiten getestet, generiert mit Hilfe von The Cloud von Shunra Software. Zur Überwachung des Datenflusses zwischen Client und Server verwendeten die Tester den Netzwerk-Traffic-Monitor Etherpeek 4 von WildPackets.

Unter LAN-Geschwindigkeit lieferten alle Protokolle eine starke Performance. Als die Bandbreite jedoch schrittweise verringert wurde, hoben die Ergebnisse die Unterschiede hervor, die es bei der Verarbeitung der Daten zwischen den verschiedenen Protokollen gab. Sun Ray war zum Beispiel beim Erneuern von Bildschirminhalten langsamer, denn seine 24-Bit-Farbunterstützung macht es erforderlich, dass mehr Informationen übertragen werden als bei den nur 8 Bits tiefen Bildschirmen der Konkurrenten.

Insgesamt waren VNC und Sun Ray bei LAN-Bandbreite schneller, ICA und RDP erbrachten jedoch bei geringeren Bandbreiten bessere Leistungen – ein wichtiger Faktor für Kunden, die planen, Thin-Client-Technologie vorwiegend in-house einzusetzen. Bei einer Bandbreite von 128 KBit/s hatten alle Protokolle Probleme, das zu erreichen, was Nieh als „gute“ Reaktionszeiten bezeichnete. Dieser Punkt wird besonders in Situationen ausschlaggebend, in denen die Einwahl über ein Modem oder eine drahtlose GPRS-, CDMA 1x- oder UMTS-Verbindung durchgeführt wird – eine sehr reale Möglichkeit, denn drahtlose Geräte werden immer leistungsfähiger und fungieren praktisch als Thin-Client-Terminals.