Server-based Computing: Schlank und schnell

Kontrollmechanismen im Netz erforderlich

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.

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.

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.

1. Server-based Computing: Schlank und schnell
2. Kontrollmechanismen im Netz erforderlich
3. Fazit