Anforderungen an die Infrastruktur:
Server-based Computing: Schlank und schnell

von Thomas Boele

Share
18.02.2008

LAN und WAN müssen einige spezifische Anforderungen erfüllen, wenn Server-Based-Computing effektiv eingesetzt werden soll.

(Fortsetzung des Artikels von Seite 2)

Einhergehend mit der Renaissance der Mainframes fand am Ende des vergangenen Jahrtausends ein Paradigmen-Wechsel statt. Server-Based- beziehungsweise Thin-Client-Computing erfreuen sich seitdem starker Wachstumsraten. Immer mehr Hersteller steigen in die Produktion schlanker Endbenutzer-Syteme auf der einen und immer besser skalierbarer und leistungsfähiger Server-Systeme und Software-Implementierungen auf der anderen Seite ein. Virtualisierung für Storage, Server und Netzwerk ist die Technologie für heute und für die Zukunft.

Die Vorteile für den stationären Einsatz von Thin-Clients – besonders im Unternehmensbereich – liegen auf der Hand:

  • Geringere Kosten für die Administration von Hard- und Software,
  • geringere Anschaffungskosten und längere Lebenszyklen für die Endbenutzersysteme,
  • Sicherheitsrichtlinien lassen sich einfacher um- und durchsetzen, erlaubt ist nur, was zentral installiert wird,
  • Schutz vor Schadsoftware,
  • Data-Loss-Prevention (DLP): mit dem Fehlen lokaler Massenspeicher lässt sich sehr genau steuern und falls gewünscht protokollieren, welche Daten portabel sind und welche nicht,
  • geringerer Energieverbrauch der Client-Systeme sowie
  • geringerer Bandbreitenbedarf beim Standard-Einsatz im Büro.

Mittlerweile gibt es die unterschiedlichsten Arten von Thin-Clients, darunter Linux-basierte Thin-Client-Terminals, Windows-Based-Terminals (WBT), POS-Terminals (Kassensysteme), Browser-Terminals, Java-Terminals, Kiosk-Terminals sowie Abspielgeräte für IPTV (TV-Streamer) und Digital-Media-Signage und Terminals für weitere Spezialanwendungen.

Protokolldschungel

Beim Einsatz von Thin-Clients spielt die Qualität der eingesetzten Kommunikationsinfrastruktur eine entscheidende Rolle, zum einen für die Anbindung der Terminals an die Applikations-Server-Landschaften und zum anderen bei der Anbindung verschiedener Subsysteme im Server-Verbund: CPUs und I/O.

Für die Kommunikation zwischen Thin-Clients und den Servern existiert eine Vielzahl unterschiedlicher Ansätze und damit auch eine entsprechend große Anzahl unterschiedlicher Protokolle, darunter: X.11/X.11 via SSH (Secured-Shell)/NX, XML beziehungsweise HTML via HTTP für Web-Applikationen, ALP (Sun-Ray-Appliance-Link-Protocol), VNC (Virtual-Network-Computing), RDP (Microsoft-Remote-Destop-Protocol), RGS (HP-Remote-Graphics-Software) sowie Citrix-ICA (Independent-Computing-Architecture).

Die Bandbreitenanforderungen für das einzelne im LAN angebundene Terminal sind eher gering. Je nach Anwendungs-Mix, Farbtiefe, Auflösung und Anzahl der Druckjobs liegt sie zwischen wenigen kBit/s und mehreren 100 kBit/s pro Terminal. Jedoch sind bei einer hohen Anzahl von Terminals die Strecken zu den Servern hinsichtlich Dienstgüte, Bandbreite und Verfügbarkeit einer kritischen Betrachtung zu unterziehen.

Noch kritischer wird dies, sobald WAN-Strecken zwischen den Terminals und den Applikations-Servern dazwischen geschaltet sind. Es ist insbesondere zwischen interaktivem (Bildschirm-Updates, Mausbewegungen und Tastaturanschläge) und nicht-interaktivem (Druckaufträge, FTP-Übertragungen) Thin-Client-Datenverkehr zu unterscheiden.


Thin-Clients über WAN-Verbindungen

Typischerweise können Applikationsserver nahezu jede Applikation hosten. Die Anwender können von ihren Thin-Clients aus via Netzwerk über das gewohnte Graphical-User-Interface (GUI) auf diese Applikationen zugreifen.

Mausbewegungen und Tastaturanschläge werden von den Thin-Clients auf die Server übertragen, diese schicken Bildschirm-Updates zurück. Läuft diese Kommunikation über eine WAN-Verbindung, kann eine Überlastung dieser Strecke den Arbeitsablauf des Anwenders empfindlich stören, weil die zeitkritischen Screen-Updates verzögert übertragen werden.

Hier ein Beispiel: zwei Anwender sind mit ihren Thin-Clients über einen WAN-Link ohne aktivierte QoS-Funktionen mit einem zentralen Applikationsserver verbunden. Ein Benutzer führt einen Druck-Job (Applikationsserver zentral, Drucker lokal), einen FTP-Upload oder einen anderen Job aus, der hohe Bandbreite benötigt.

Hierdurch kann der WAN-Link überlastet werden, so dass damit die flüssige Übertragung des Dialogverkehrs des zweiten Anwenders beeinträchtigt wird. Die WAN-Strecke wird überlastet, da die TCP-Sessions des ersten Anwenders diese auf 100 Prozent Auslastung treiben können.

Kontrollmechanismen im Netz erforderlich

Damit der zweite Anwender den Eindruck einer im lokalen Netz gehosteten Applikation bekommt, muss ein Display-Update innerhalb von höchstens rund 150 ms nach der Auslösung empfangen werden. In der gegebenen Situation können diese zeitkritischen Updates unzumutbar langsam werden.

Versucht der zweite Anwender beispielsweise den Mauszeiger quer über den Bildschirm zu bewegen, so kann dies bei einer Überlastung des WAN-Links plötzlich mehrere Sekunden dauern. Das Netzwerk muss mithin in der Lage sein, zwischen interaktivem und nicht-interaktivem Thin-Client-Datenverkehr zu unterscheiden und wirksame Kontroll- und Steuermechanismen zur Verfügung stellen, um eine konsistente und positive User-Experience sicherzustellen.

Ein angemessenes Bandbreitenmanagement mit geeigneten QoS-Mechanismen kann diese Problematik lindern oder eliminieren. Idealerweise sollte der FTP-Transfer oder der Print-Job des ersten Benutzers gerade so viel Bandbreite bekommen, so dass der zweite Benutzer bei seiner Dialog-Anwendung im Rahmen der Delay-Grenzen bleibt.

Die Bandbreitenanforderungen variieren jedoch unter anderem mit der aktuell verwendeten Applikation. Eine grafikintensive Präsentationssoftware benötigt mehr Bandbreite als eine Textverarbeitung.

Bandbreitenbedarf zwei 20 und mehreren 100 kBit/s

Die im stationären Zustand pro Benutzer im Dialogbetrieb benötigte Bandbreite je nach verwendeter Thin-Client-Technologie kann zwischen rund 20 kBit/s und mehreren 100 kBit/s schwanken. Diese Informationen können in der Regel den Design-Guides der jeweiligen Anbieter beziehungsweise aus öffentlich zugänglichen Testberichten beziehungsweise Messprotokollen entnommen werden.

Das (Thin-Client-relevante) Sizing der WAN-Leitungen kann dann über die Anzahl der antizipierten gleichzeitigen Benutzer multipliziert mit der durchschnittlichen Bandbreite für Dialogbetrieb zuzüglich sonstigem nicht-interaktivem Datenverkehr (Print-Jobs oder Disk & Serial-IO) vorgenommen werden.

Um ein reibungsloses Funktionieren der Thin-Clients auch in Zeiten, in denen Spitzenlasten auftreten, sicherzustellen, sind unter anderem die folgenden »Best Guess«-Ansätze möglich.

  • Design für Zeiten der Spitzenlast für jeden Datenverkehrstyp: Messung der Spitzenlasten für jeglichen Datenverkehr. Genügend Bandbreite für Wachstum und unvorhergesehene Bursts hinzuzählen. Überlastsituationen werden mit diesem Ansatz in der Regel vermieden, allerdings ist das Verfahren kostenintensiv.
  • Design für Zeiten der Spitzenlast für jeglichen Thin-Client-Datenverkehr: Messung der Spitzenlasten für Thin-Client-Datenverkehr (teilweise Identifikation von Thin-Client-Traffic via TCP-Port möglich). Anwendung von QoS-Mechanismen wie CB-WFQ (Class-Based-Weighted-Fair-Queuing) oder FL-WFQ (Flow-Based-Weighted-Fair-Queuing), um den Thin-Client-Daten eine angemessene Priorität zu geben. Bei gemischtem Datenverkehr wird damit ein wenig Granularität erreicht. Besteht der Datenverkehr hauptsächlich aus Thin-Client-Paketen, ist man wieder bei der eingangs beschriebenen Überlastungs-Thematik angelangt. Interaktive und nicht-interaktive Terminal-Daten können nicht voneinander unterschieden werden, so dass die Gefahr besteht, interaktiven Datenverkehr wieder mit Delays zu belasten. Es wird mithin eine Möglichkeit benötigt, Dialog-Datenverkehr von anderem zu unterscheiden.
  • Design für Zeiten der Spitzenlast für ausgesuchte Applikationen: In manchen Fällen gibt es die Möglichkeit, aus Datenpaketen des Thin-Client-Datenverkehrs (wenn diese nicht beispielsweise per SSL-verschlüsselt sind) beispielsweise den Namen der ausgeführten Datei der Applikation auszulesen und somit den Thin-Client-Verkehr zum Beispiel von Word-Processor und Datenbank bevorzugt zu behandeln. In dieser Konstellation wird allerdings noch nicht zwischen interaktiven und nicht-interaktiven Daten der priorisierten Applikation unterschieden. Das Netzwerk sollte in der Lage sein, beispielsweise Druckaufträge von Display-Updates zu unterscheiden.
  • Design für Zeiten der Spitzenlast bei interaktivem Thin-Client-Datenverkehr: Zeitweilig kann über eine (proprietäre) Protokoll-Erweiterung des verwendeten Thin-Client-Protokolls eine Möglichkeit für Erkennungsmechanismen auf Routern oder Switches geschaffen werden, zwischen unterschiedlichen Terminal-Daten zu unterscheiden: Display-Updates, Disk-I/O, Serial-I/O und Audio. Auf diesem Weg kann der Netzwerk-Designer eine QoS-Architektur aufsetzen, um einen optimalen Dialogbetrieb auch bei Spitzenlasten zu gewährleisten. Mittels CBWFQ kann der Dialogdatenverkehr in einer eigenen Klasse beziehungsweise Queue behandelt werden. Die dafür berechnete Bandbreite ergibt sich aus dem Produkt der Anzahl der maximalen parallelen Nutzer im Dialogbetrieb und der benötigten Bandbreite für interaktive Daten pro Benutzer (beispielsweise 20 kBit/s). Zusätzliche Bandbreite wird für nicht-interaktive Daten sowie übrigen Datenverkehr benötigt. Diese zusätzlichen Verkehrstypen können in unterschiedliche Klassen aufgeteilt werden, die eine eigene Bandbreitenzuordnung bekommen. Dank des Queuing-Algorithmus wird allerdings sichergestellt, dass die für Dialogbetrieb allokierte Bandbreite für andere Queues zur Verfügung steht, wenn diese momentan nicht beispielsweise für Display-Updates benötigt wird.


Für langsame Leitungen sollte auch der Serialization-Delay (die Zeit, die benötigt wird, um ein Paket aus der Queue heraus zu bekommen) berücksichtigt werden.

Bei einem 1500 Byte großen FTP-Paket sind das auf einer 64-kBit/s-Verbindung immerhin rund 187 ms. Da aber die Round-Trip-Time (RTT) für interaktiven Terminal-Datenverkehr 150 ms (75 ms in jede Richtung) nicht überschreiten sollte, sollten die Pakete beispielsweise auf 256 oder 512 Byte fragmentiert werden, damit keine Delay-Probleme entstehen.

Diese Funktion wird im allgemeinen als »Link Fragmentation & Interleaving« bezeichnet. Um eine Fragmentierung zu vermeiden, kann auch die MTU-Size für den WAN-Link angepasst werden, da eine Fragmentierung lediglich auf langsamen WAN-Verbindungen und nicht Ende zu Ende erfolgen sollte.

Innerhalb der letzen Jahre hat sich ein stetig wachsender Markt für WAN-Optimierungs-Systeme entwickelt. Diese Systeme – zumeist als Appliance oder Add-On-Software/-Hardware für WAN-Router erhältlich – greifen auf unterschiedlichen Ebenen in die WAN-Übertragung ein und können so Applikationen oder Dateiübertragungen um bis zu mehreren 100 Prozent beschleunigen.

Im Falle der Thin-Client-Kommunikation kann man beispielsweise auf die folgenden Weisen optimierend eingreifen:

  • TCP-Optimierung: TCP-Sessions werden lokal terminiert, Flows über das WAN werden im Hintergrund optimiert, so dass im Idealfall für Applikation und Anwender der Eindruck entsteht, auf einem gemeinsamen lokalen Netz zu sein. Die TCP-Initial-Windows werden vergrößert, damit der Client die TCP-Slow-Start-Phase schneller verlässt und in die Congestion-Avoidance-Phase geht, um schneller einen höheren Durchsatz zu erreichen. Die TCP-Window-Kapazität von optimierten TCP-Verbindungen wird vergrößert, um den Durchsatz zu erhöhen. Ein verbessertes Congestion-Handling ermöglicht es, Retransmits effizienter durchzuführen und so wieder schneller in Bereiche höheren Durchsatzes zu kommen.
  • Vermeidung redundant übertragener Daten, für wiederholte auftauchende Daten müssen gegebenenfalls nur Anweisungen, was mit diesen auf der Gegenseite zu geschehen hat, übertragen werden. Der Rest wird dort hinzugefügt.
  • Verbesserte Kompressions-Algorithmen, auch in Verbindung mit Algorithmen zur Vermeidung redundant übertragener Daten: Damit wird die Bandbreite, die von einzelnen TCP-Flows benötigt wird, verringert. Verschiedene Hersteller von Thin-Client-Lösungen haben auch eigene Kompressions- und zusätzliche Verschlüsselungsverfahren implementiert, die den Wirkungsgrad der Optimierungs- und Erkennungsmechanismen beeinflussen können.

Fazit

Auf der Seite der Applikations-Server trägt die Kommunikationsinfrastruktur entscheidend zum Erfolg einer Server-Based-Computing Lösung bei. Performance, Verfügbarkeit, Skalierbarkeit und nicht zuletzt Techniken für die Virtualisierung von Rechenleistung, Storage- und Netzwerkelementen gehören hier zu den wichtigsten Schlagworten.

Diese Infrastruktur muss sicherstellen, dass herkömmliche Server via Gigabit-Ethernet oder 10-Gigabit-Ethernet angebunden werden können. Storage sollte beispielsweise via Fibre-Channel oder iSCSI erreichbar sein und die Vernetzung von Bladeservern via Gigabit-Ethernet oder 10-Gigabit-Ethernet oder in HPC-Umfeldern mittels Infiniband ermöglicht werden.

So kann der benötigte Applikations-Mix dynamisch im Data-Center bereitgestellt und den Benutzern auf den Thin-Clients via LAN oder – unter Beachtung der oben erörterten WAN-Design-Richtlinien – verfügbar gemacht werden, ganz gleich, ob die Bereitstellung dieser Dienste im eigenen Unternehmen stattfindet oder über einen Application-Service-Provider geleistet wird.

Thomas Boele ist Technical Marketing Manager bei Cisco Systems [1].

[1] http://www.cisco.de