Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server...

46
Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur etabliert. Das vorliegende Papier beschäftigt sich mit der Frage, wie viele Benutzer eine als Terminal Server eingesetzte PRIMERGY mit adäquater Performance bedienen kann. Es soll helfen, für eine geforderte Leistungsklasse das passende PRIMERGY Modell zu finden. Nach einer allgemeinen Abhandlung über das Vermessen von Terminal Server wird das zum Dimensionieren der PRIMERGY Systeme benutzte Simulationswerkzeug (T4US) vorgestellt. Dann wird ausführlich darauf eingegangen, welche Komponenten welchen Einfluss auf die Leistungsfähigkeit eines Terminal Server Systems haben. Anschließend wird eine Einordnung älterer und aktueller PRIMERGY Systeme in Bezug auf ihre Leistungsfähigkeit als Terminal Server durchgeführt. Da eine Dimensionierung auch immer einen kundenspezifischen Aspekt beinhaltet, wird zusätzlich ein Überblick über nützliche Analysewerkzeuge und Engpassanalysen gegeben. Zum Abschluss werden Messmethoden anderer Hersteller skizziert. Inhalt Einführung ................................................................... 2 PRIMERGY............................................................... 2 Server-based Computing .......................................... 2 Windows Terminal Server ...................................... 2 Lösungen ............................................................... 3 Trends .................................................................... 3 Dimensionierung.......................................................... 4 Methoden .................................................................. 4 Kenngröße »Benutzer«............................................. 5 Benutzersimulation ................................................... 5 Interpretation............................................................. 6 Benchmark-Beschreibung ........................................... 7 Simulationswerkzeug: T4US ..................................... 7 Lastprofil ................................................................... 7 Lastprofil V1 ........................................................... 8 Lastprofil V2 ........................................................... 8 Messmethode ........................................................... 9 Messumgebung ......................................................... 10 Ressourcenbedarf ..................................................... 12 Betriebssystem ....................................................... 12 IA64 ..................................................................... 12 x64 ....................................................................... 12 Limitierungen ....................................................... 13 Auswirkungen ...................................................... 14 Rechenleistung ....................................................... 15 Prozessortyp ........................................................ 15 Taktfrequenz ........................................................ 16 Memory-Anbindung.............................................. 17 Caches ................................................................. 18 Hyper-Threading ..................................................19 Anzahl Kerne........................................................20 Arbeitsspeicher .......................................................21 Disk-Subsystem ......................................................24 Netzwerk .................................................................25 Infrastruktur .............................................................26 Überlastverhalten ....................................................28 Anzahl Prozesse ..................................................28 PRIMERGY Skalierung ..............................................29 Analysewerkzeuge.....................................................31 Task-Manager ......................................................31 Sysinternals Process Explorer .............................31 Performance Monitor ............................................31 Windows Performance Toolkit ..............................32 Citrix Resource Manager......................................34 Microsoft Operations Manager (MOM) 2005 ........35 Engpassanalyse ........................................................36 Rechenleistung/System ..........................................37 Arbeitsspeicher .......................................................38 Betriebssystemressourcen ......................................39 Disk-Subsystem ......................................................40 Netzwerk .................................................................41 Terminal Server ......................................................42 Applikationen ..........................................................43 Performance Monitor-Konfigurationsskript ..............44 Messwerkzeuge .........................................................45 Literatur......................................................................46 Kontakt.......................................................................46 Terminal Server Sizing Guide Ausgabe 4.0 Oktober 2009 Seiten 46

Transcript of Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server...

Page 1: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

Abstract

Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur etabliert. Das vorliegende Papier beschäftigt sich mit der Frage, wie viele Benutzer eine als Terminal Server eingesetzte PRIMERGY mit adäquater Performance bedienen kann. Es soll helfen, für eine geforderte Leistungsklasse das passende PRIMERGY Modell zu finden. Nach einer allgemeinen Abhandlung über das Vermessen von Terminal Server wird das zum Dimensionieren der PRIMERGY Systeme benutzte Simulationswerkzeug (T4US) vorgestellt. Dann wird ausführlich darauf eingegangen, welche Komponenten welchen Einfluss auf die Leistungsfähigkeit eines Terminal Server Systems haben. Anschließend wird eine Einordnung älterer und aktueller PRIMERGY Systeme in Bezug auf ihre Leistungsfähigkeit als Terminal Server durchgeführt. Da eine Dimensionierung auch immer einen kundenspezifischen Aspekt beinhaltet, wird zusätzlich ein Überblick über nützliche Analysewerkzeuge und Engpassanalysen gegeben. Zum Abschluss werden Messmethoden anderer Hersteller skizziert.

Inhalt

Einführung ................................................................... 2 PRIMERGY ............................................................... 2 Server-based Computing .......................................... 2

Windows Terminal Server ...................................... 2 Lösungen ............................................................... 3 Trends .................................................................... 3

Dimensionierung .......................................................... 4 Methoden .................................................................. 4 Kenngröße »Benutzer« ............................................. 5 Benutzersimulation ................................................... 5 Interpretation ............................................................. 6

Benchmark-Beschreibung ........................................... 7 Simulationswerkzeug: T4US ..................................... 7 Lastprofil ................................................................... 7

Lastprofil V1 ........................................................... 8 Lastprofil V2 ........................................................... 8

Messmethode ........................................................... 9 Messumgebung ......................................................... 10 Ressourcenbedarf ..................................................... 12

Betriebssystem ....................................................... 12 IA64 ..................................................................... 12 x64 ....................................................................... 12 Limitierungen ....................................................... 13 Auswirkungen ...................................................... 14

Rechenleistung ....................................................... 15 Prozessortyp ........................................................ 15 Taktfrequenz ........................................................ 16 Memory-Anbindung .............................................. 17 Caches ................................................................. 18

Hyper-Threading .................................................. 19 Anzahl Kerne ........................................................ 20

Arbeitsspeicher ....................................................... 21 Disk-Subsystem ...................................................... 24 Netzwerk ................................................................. 25 Infrastruktur ............................................................. 26 Überlastverhalten .................................................... 28

Anzahl Prozesse .................................................. 28 PRIMERGY Skalierung .............................................. 29 Analysewerkzeuge ..................................................... 31

Task-Manager ...................................................... 31 Sysinternals Process Explorer ............................. 31 Performance Monitor ............................................ 31 Windows Performance Toolkit .............................. 32 Citrix Resource Manager...................................... 34 Microsoft Operations Manager (MOM) 2005 ........ 35

Engpassanalyse ........................................................ 36 Rechenleistung/System .......................................... 37 Arbeitsspeicher ....................................................... 38 Betriebssystemressourcen ...................................... 39 Disk-Subsystem ...................................................... 40 Netzwerk ................................................................. 41 Terminal Server ...................................................... 42 Applikationen .......................................................... 43 Performance Monitor-Konfigurationsskript .............. 44

Messwerkzeuge ......................................................... 45 Literatur ...................................................................... 46 Kontakt ....................................................................... 46

Terminal Server Sizing Guide

Ausgabe 4.0 Oktober 2009

Seiten 46

Page 2: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 2 (46)

Terminal Server

Data Store

Einführung

PRIMERGY

»PRIMERGY« ist seit 1995 der Markenname für die sehr erfolgreiche Industrie-Standard-Server-Familie aus dem Hause Fujitsu Technology Solutions. Es handelt sich dabei um eine bei Fujitsu Technology Solutions entwickelte und produzierte Produktlinie mit Systemen für kleine Arbeitsgruppen bis hin zu Lösungen für Großunternehmen. Zu den PRIMERGY Modellen gehören neben wirtschaftlichen 1-Socket Systemen der Einstiegsklasse auch leistungsstarke Dual-Socket Systeme als Rack und Tower Modelle bis hin zu den Mehr-Sockel Systemen und Blade Servern. Als Herzstück werden Intel Prozessoren der obersten Leistungsklasse verwendet. Weitere detaillierte Informationen über die aktuellen Systeme findet man bei Fujitsu Technology Solutions im Internet.

Server-based Computing

Windows Terminal Server

Terminal Server ist eine Form des Server-based Computing auf Basis von Microsoft Windows Server Betriebssystemen.

Das klassische Server-based Computing ist eine Systemarchitektur, bei der Microsoft Windows Client-Anwendungen zu 100 Prozent auf dem Server installiert und ausgeführt werden. Von dort erfolgt nicht nur deren Einsatz, sondern auch deren Wartung, Verwaltung und Support finden direkt auf dem Server statt. Lediglich die Benutzeroberfläche, d.h. die Bildschirm-, Maus- und Tastatur-Informationen werden zwischen Client und Server übertragen. Der Benutzer kann so von fast beliebigen Clients aus, auch nicht Windows basierten, über einen solchen Terminal Server sofort auf Windows Anwendungen zugreifen, ohne dass die jeweiligen Applikationen erst zum Client übertragen, dort gestartet, oder gar auf lokalen Massenspeichern vorgehalten werden müssten. Wird ein Client ausschließlich in diesem Server-based Szenario eingesetzt, so hat er hinsichtlich Speicher- und Plattenausstattung wesentlich geringere Anforderungen als ein traditioneller Client, man spricht daher auch von so genannten Thin-Clients.

Vorteile des Server-based Computing sind die Kostenreduktion durch bessere Server-Auslastung sowie bessere Administration durch Zentralisierung von Anwendungen.

Ein Terminal Server kann prinzipiell für alle Arten von Applikationen eingesetzt werden. Wo bislang kleine Rechner oder Terminals für einfache Dateneingabe bzw. -abfrage Verwendung fanden, können mit dem Terminal Server moderne Anwendungen in ein bestehendes Umfeld integriert werden.

Eine Terminal Server Farm ist ein Zusammenschluß von Terminal Servern, die eine gemeinsame Verwaltungseinheit, Data Store genannt, besitzen. Diese werden gemeinsam administriert. Die Zuordnung von Benutzern zu Servern und Applikationen kann statisch erfolgen oder dynamisch nach Auslastung der Terminal Server (Load Balanced Server Farm).

Page 3: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 3 (46)

Lösungen

Das Konzept des Server-based Computing hat seit 2000 unter dem Namen »Terminal Services« einen festen Platz in Server-Produkten der Microsoft Windows 2000 Server und Windows Server 2003 Produktlinie. Selbst in dem Client-Betriebssystem ab Windows XP Professional steht in begrenztem Umfang der Terminal Service unter dem Namen »Remote Desktop« zur Verfügung. Von einem beliebigen Windows Client kann somit auf das entfernte System zugegriffen werden, wobei die Anwendungen komplett auf dem Remote-System ablaufen. Das unterliegende Protokoll wird als »Remote Desktop Protocol« (RDP) bezeichnet. Auch wenn seit dem aktuellen Betriebssystem Windows Server 2008 die Terminal-Dienste nicht mehr »Terminal Services« heißen, sondern in »Remote Desktop Services« (RDS) umbenannt wurden, wird in diesem Papier der Einfachheit halber weiterhin der Name »Terminal Services« verwandt. Die Remote Desktop Services unter Windows Server 2008 sind um Funktionen erweitert, die die Verwaltung von Terminal Server Anwendungen (RemoteApp), den Webzugriff (Remote Desktop Web Access) auf diese sowie den sicheren Zugang zu den Terminal-Diensten über das Internet (Remote Desktop Gateway) betreffen.

Der größte Player im Terminal Server Umfeld ist das US-amerikanische Softwarehaus Citrix. Sein weiterentwickeltes Produkt »Citrix XenApp« (früher »Citrix Presentation Server«, davor »Citrix Metaframe«) dient der virtuellen Bereitstellung und dem Managen von Anwendungen insbesondere in großen Server-Umgebungen. Citrix XenApp basiert auf Microsoft Windows Terminal Services. Es bietet Erweiterungen und zusätzliche Funktionalitäten in den Bereichen der zentralen Verwaltung und Überwachung großer Server-Farmen, sowie Unterstützung in stark heterogenen IT-Umgebungen. Im Gegensatz zu Microsoft Terminal Server benutzt Citrix das eigenentwickelte, effiziente ICA-(Independent Computing Architecture) Protokoll zur Datenübertragung zwischen Client und Server.

Trends

Neben dem Konzept des Server-based Computing hat sich in den letzten Jahren das Konzept der Virtualisierung in den unterschiedlichsten Formen durchgesetzt.

Server-Virtualisierung hat ähnlich wie Terminal Server Lösungen die Aufgabe, die Auslastung physikalischer Server zu erhöhen und Betriebskosten sowie Wartungs- und Administrationsaufwände zu verringern.

Unter Applikations-Virtualisierung versteht man den Ansatz, Anwendungen von ihrer Umgebung zu isolieren, so dass Konflikte mit anderen Programmen oder dem Betriebssystem vermieden werden. Die Terminal Server Lösung von Citrix, »Citrix XenApp« realisiert Applikations-Virtualisierung durch die zwei Funktionalitäten: Application Streaming und Application Isolation. Das Application Streaming ermöglicht es, Anwendungen zum Client Device zu bringen und dort in einer geschützten und isolierten Umgebung ablaufen zu lassen. Die Applikations-Virtualisierungslösung von Microsoft findet sich in einem von Windows Terminal Server separaten Produkt »Microsoft Application Virtualization« (bekannt auch als App-V, früher SoftGrid).

Eine der größten Barrieren bei der Einführung einer Terminal Server Lösung ist die Tatsache, dass allen Benutzern die gleiche Arbeitsplatzoberfläche bzw. die gleichen Anwendungen zur Verfügung gestellt wurden. Eine komplette Individualisierung, wie sie der Benutzer von seinem traditionellen Arbeitsplatz aus gewohnt ist, ist nicht möglich. Dieses wird bei der Desktop-Virtualisierung umgangen. Sie ist eine Zusammenführung der beiden Konzepte Virtualisierung und traditionelles Server-based Computing und findet sich im Konzept des von VMware zuerst eingeführten Begriffs des »Virtual Desktop Infrastructure« (VDI) wieder.

In einer virtuellen Desktop-Umgebung sind die Desktops einzelner Benutzer in jeweils einer virtuellen Maschine eines Servers »gehostet«. Damit hat jeder Benutzer sein eigenes Desktop-System. Zugriff auf diesen virtuellen Arbeitsplatz kann z.B. über Protokolle wie RDP oder ICA erfolgen. Auch eine traditionelle Terminal Server Umgebung bietet die Möglichkeit, einem Benutzer in einer Session einen Desktop zur Verfügung zu stellen, allerdings entfällt die Möglichkeit der Personalisierung, wie sie bei einem traditionellen PC-Arbeitsplatz möglich wäre. Eine Diskussion welches Konzept – VDI oder Terminal Server – in welchem Umfeld mehr Vorteile bezüglich Kosten und Funktionalität bietet und sich damit durchsetzen wird, würde den Rahmen dieses Papiers sprengen, bleibt aber weiterhin spannend.

Page 4: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 4 (46)

Scale-Up

bezeichnet den Einsatz zunehmend größerer Server Systeme.

Scale-Out

bezeichnet den Einsatz von vielen kleineren Systemen, die sich die Arbeit teilen.

Load Balancer

Session List

Terminal Server

Dimensionierung

Methoden

Bei der Skalierung – das ist der Prozess, das System an die benötigte Leistung anzupassen – werden zwei Methoden unterschieden:

Beim Scale-Up wird die Leistung eines Terminal Servers durch den Einsatz leistungsfähigerer Hardware, also insbesondere Rechenleistung und Arbeitsspeicher, erhöht. Es ist eine adäquate Skalierungsmethode, wenn eine überschaubare Anzahl an Benutzern zu bedienen ist. Diesem Skalierungsprozess sind Grenzen durch die maximale Leistungsfähigkeit des Server-Systems oder auch durch die Softwarearchitektur gesetzt. Insbesondere bei einem 32-bit Windows Betriebssystem ergeben sich Limitierungen im Speicherbereich, die dazu führen können, dass die Rechenleistung moderner Prozessoren nicht mehr voll ausgeschöpft werden kann. Genauer wird darauf im Kapitel Betriebssystem eingegangen.

Beim Scale-Out werden viele Server zu einer Gruppe zusammengefasst. Man kann drei Varianten unterscheiden:

1. Just a Bunch of Servers

»Just a Bunch of Servers« ist eine lose Ansammlung von Servern, hier Terminal Servern, denen dedizierte Benutzergruppen oder Applikationen zugeordnet sind. Es findet jedoch unter den Terminal Servern kein Informationsaustausch und kein Lastenausgleich statt. Der Vorteil dieser Architektur ist die sehr einfache Erweiterbarkeit. Nachteilig ist, dass durch fehlenden Lastenausgleich Server-Leistung ungenutzt bleiben kann. Der administrative Aufwand ist recht hoch, da jedes System separat verwaltet werden muss. Dennoch wird diese Variante des Scale-Outs in der Praxis in kleineren Konfigurationen eingesetzt.

2. Server-Farm

Eine Terminal Server Farm ist ein Zusammenschluß von Terminal Servern, die eine gemeinsame Verwaltungseinheit besitzen. Die Zuordnung von Benutzern zu Servern und Applikationen erfolgt meist statisch. Vorteil gegenüber der »Just a Bunch of Servers« Variante ist die vereinfachte Administration der Server. Auch diese Variante des Scale-Outs wird in der Praxis sehr häufig eingesetzt.

3. Load-balanced Server-Farm

Bei einer »load-balanced Server-Farm« werden die einzelnen Terminal Server zu einer logischen Einheit zusammengefasst. Wird von einem Client eine Session initiiert, so wird diese von einem Load Balancer nach bestimmten Mechanismen an den Server mit der momentan geringsten Auslastung delegiert. Neben der besseren Auslastung der Terminal Server bietet das Load Balancing auch eine gewisse Redundanz. Aktuelle Terminal Server Softwarelösungen, sowohl von Microsoft als auch Citrix, bieten umfangreiche Möglichkeiten des Load Balancing.

Im Folgenden beschäftigen wir uns mit einem Scale-Up Scenario, d.h. der Dimensionierung eines einzelnen Terminal Servers.

Page 5: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 5 (46)

Kenngröße »Benutzer«

Vor jeder Implementierung eines Applikations-Servers steht immer die gleiche Frage: Welches ist die passende Hardware für die geforderte Aufgabe? Natürlich möchte man dabei ein möglichst optimales System, welches weder für die Anforderungen zu klein noch (aus Kostengründen) total überdimensioniert ist. Die Frage ist also: Wie findet man ein wohl dimensioniertes System?

Die einzige meist vorliegende Kenngröße ist die Anzahl Benutzer, die mit dem System arbeiten sollen. Die typische Frage, die also zumeist auftritt, ist: »Welches PRIMERGY Modell benötigt man für einen Terminal Server zur Unterstützung einer bestimmten Anzahl von Benutzern?«. Optimalerweise würde man als Antwort eine handliche Tabelle erwarten, aus der anhand der Benutzerzahl in der einen Spalte unmittelbar aus der zweiten Spalte das ideale PRIMERGY System abgelesen werden kann. Leider gibt es eine solche Tabelle nicht – auch wenn mancher Mitbewerber dies dem Kunden mit bunten Web-Seiten suggeriert. Die Antwort auf die scheinbar so einfache Frage ist doch wesentlich komplexer, denn sie enthält eine große Unbekannte, und die ist der Benutzer.

Ein Benutzer ist, auch wenn dies viele vielleicht wünschen, keine standardisierte und berechenbare Größe, sondern ein Individuum mit unterschiedlichem Arbeitstempo und Arbeitsverhalten. Das Arbeitstempo z.B. bestimmt mit welcher Häufigkeit Eingaben gemacht werden und hat damit direkten Einfluss auf die Belastung des Terminal Server Systems. Hinzu kommen unterschiedliche Arbeitsaufgaben, die in unterschiedlichen Anforderungen an ein Computersystem resultieren. Ein Benutzer, dessen Aufgabe aus Abfragen an ein Lagerhaltungssystem besteht, wird eine andere Last auf einem Computersystem erzeugen, als ein Benutzer, dessen Aufgabe es ist, eine grafische Werbebroschüre zu entwerfen. Nicht zu vernachlässigen ist der mit der Zeit steigende Ressourcenverbrauch der Applikationen durch deren Weiterentwicklung, z.B. im Bereich 3D-Grafik oder Multimedia/Videoanwendungen.

Die folgende Tabelle zeigt eine Einteilung der Benutzer in Gruppen nach ihrem Benutzerverhalten und Belastungsprofil.

Heavy Knowledge Worker nutzt gleichzeitig mehrere verschiedene Anwendungen gibt Daten mäßig schnell ein führt komplexere Operationen aus

Medium Process Worker arbeitet zu einer Zeit intensiv mit einer Anwendung gibt schnell viele Daten ein arbeitet kontinuierlich

Light Data Entry Worker arbeitet zu einer Zeit nur mit einer Anwendung gibt wenig Daten ein längere Pausen zwischen den Eingaben

Wie im Kapitel Lastprofil noch erläutert wird, wurde bei den Messungen für das vorliegende Dokument das Verhalten eines Medium Benutzers angenommen.

Benutzersimulation

Bei Leistungsmessungen werden generell keine realen Benutzer verwendet, sondern die Benutzer werden mit Hilfe von Computern, so genannten Lastgeneratoren, und einer speziellen Software simuliert. Dabei wird von einem physikalischen Lastgenerator zumeist eine Vielzahl von logischen Benutzern simuliert, so dass je nach Lastgenerator einige zig oder hundert Benutzer simuliert werden können. Die folgende Abbildung zeigt eine typische Simulationsumgebung.

Controller

SUT- Netzwerk

Lastgeneratoren

Simulations- Netzwerk

Infrastruktur- Server

System under Test

(SUT)

Page 6: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 6 (46)

Der Controller ist die zentrale Steuerkonsole, die die Simulation steuert und überwacht. Über ein Simulations-Netzwerk ist dieser mit den Lastgeneratoren verbunden. Jeder Lastgenerator kann eine Vielzahl von Benutzern simulieren. Die Lastgeneratoren erreichen das Testsystem (System under Test (SUT)) über ein zweites Netzwerk, in dem sich auch noch ein Infrastruktur-Server befindet. Dieser liefert dem SUT die notwendigen Dienste, aber er wird selbst nicht vermessen.

Unterschiedliche Benutzergruppen, wie oben diskutiert, werden von Lastsimulatoren zumeist durch verschiedene Lastprofile, im Terminal Server Umfeld auch Skript genannt, berücksichtigt.

Bei der Benutzersimulation unterscheidet man die Begriffe »Lastgenerator«, »Client« und »Benutzer«. Im weiteren Verlauf wird als »Lastgenerator« die Hardware bezeichnet. Ein »Client« ist der Terminal Server Client, von dem einer oder mehrere auf dem Lastgenerator ausgeführt werden. Ein simulierter »Benutzer« arbeitet innerhalb einer Terminal Server Sitzung.

Interpretation

Anders als bei anderen Benchmarks, wo es vom Hersteller der Applikation oder einem unabhängigen Gremium einen Benchmark und ein entsprechendes Reglement zur Durchführung gibt, wie z.B. bei Microsoft Exchange Server, SAP R/3, SPECweb oder TPC, gibt es für Terminal Server bis heute keinen standardisierten und akzeptierten Benchmark. Es existieren zwar verschiedene Produkte verschiedener Hersteller zur Benutzersimulation, aber es gibt kein standardisiertes Werkzeug, mit dem sowohl Microsoft als auch Citrix Terminal Server vermessen und verglichen werden können.

Ergebnisse solcher Performance-Messungen verschiedener Hersteller oder Benchmark-Labore sind unter diesen Bedingungen natürlich nicht untereinander vergleichbar. Nur Messungen, die in gleicher Umgebung und mit vergleichbarem Lastprofil durchgeführt wurden, können auch sinnvoll verglichen werden.

Weiterhin ist zu beachten, dass es sich bei den Terminal Server Sizing Messungen um Auswertungen in einer vereinfachten, idealisierten und standardisierten Umgebung handelt, um vergleichbare Bedingungen für alle Systeme zu schaffen. Zusätzliche Komponenten und Programme sind nicht installiert, und der Terminal Server wird bis an seine Leistungsgrenze belastet. In der Realität wird man Zusatzsoftware wie zum Beispiel einen Virenscanner installiert haben, oder man betreibt weitere Add-Ons der Terminal Server Software. Auch werden Terminal Server im Produktivbetrieb nicht bis an ihre Leistungsgrenze belastet.

Vor diesem Hintergrund kann man also sagen:

Obgleich die Einheit vieler Performance-Messungen »Anzahl Benutzer pro Server« ist, sollte man nur Ergebnisse von Performance-Messungen im gleichen Umfeld miteinander vergleichen. Sie sollten in erster Linie auch nur relativ betrachtet werden, also beispielsweise »ein System A ist doppelt so leistungsfähig wie ein System B« oder »die Verdopplung des Arbeitsspeichers resultiert in x% Leistungssteigerung«. Denn wie bereits im Kapitel Kenngröße »Benutzer« erläutert, ist ein Benutzer schwer zu quantifizieren, und ein synthetischer Benutzer muss nicht in allen Fällen mit einem realen Benutzer korrelieren.

Page 7: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 7 (46)

Benchmark-Beschreibung

Simulationswerkzeug: T4US

Fujitsu Technology Solutions hat einen eigenen Lastsimulator, T4US, entwickelt, der unabhängig von dem verwendeten Terminal Server und ohne Einflüsse auf das zu testende System beliebige Benutzerprofile simulieren kann.

Benutzeraktivitäten wie Tastatur- und Mauseingaben sowie Bildschirmausgaben können mit Hilfe des Auf-zeichnungswerkzeugs T4US-Record in Echtzeit auf-gezeichnet und in einem T4US-Skript gespeichert werden. T4US-Skripte werden während der Messung als Lastprofil verwendet.

Der Lastsimulator von T4US besteht aus drei Komponenten.

T4US-Control steuert und überwacht den gesamten Simulationslauf zentral und ermittelt Messwerte bereits während der Messung. Auf jedem der Lastgeneratoren laufen mehrere Instanzen des T4US-Playback. Je-des T4US-Playback »füt-tert« einen Terminal Server Client in Echtzeit mit Tas-tatur- und Mauseingaben anhand der mit T4US-Record aufgezeichneten Skripte und überwacht die Bildschirminhalte des Terminal Server Clients. Durch hoch auflösende Timer wird so die Antwortzeit des Terminal Servers ermittelt. Auf jedem der Lastge-neratoren läuft ein T4US-Agent, der für die Kommunikation mit dem Controller zuständig ist, die Instanzen von T4US-Playback steuert und überwacht und die ermittelten Antwortzeiten zum Controller überträgt.

Bei der Messung wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, kontinuierlich erhöht. Die Antwortzeiten des Terminal Servers werden vom T4US-Controller überwacht und mit gespeicherten Referenzwerten, die in einer vorhergehenden Referenzmessung mit nur wenigen Benutzern ermittelt worden sind, verglichen. Wenn sich die Antwortzeit der Anwendung so weit verschlechtert, dass sie den vorgegebe-nen Regeln nicht mehr genügt, wird die Messung beendet und man erhält die Benutzeranzahl als Resultat der Messung

Lastprofil

Wie im Kapitel Kenngröße »Benutzer« schon erläutert wurde, hängt die Belastung eines Terminal Servers stark vom Benutzer ab. Das Benutzerverhalten spiegelt sich bei einer Simulation im Lastprofil wider. Die hier beschriebenen Lastprofile simulieren das Verhalten eines »Medium User«, der zu einer Zeit intensiv mit einer Anwendung arbeitet und kontinuierlich, schnell viele Daten eingibt.

Der größte Teil der Messungen für den »Sizing Guide« wurde mit dem Lastprofil V1 durchgeführt. Allerdings stellte sich heraus, dass durch verbesserte Leistung der zu vermessende Systeme (neue Prozessorgenerationen) der Benchmark mit diesem Lastprofil in eine Größenordnung kam, bei der die gemessene Benutzeranzahl durch die Anzahl Ab- und Anmeldevorgänge, also daraus resultierende Restriktionen im Betriebssystem, erreicht wurde und nicht mehr durch die Prozessorleistung des Systems. Das bedeutete, der Benchmark erreichte seine Grenzwerte schon ohne den Prozessor auszulasten. Verbesserte Prozessorleistung und damit auch Systemleistung konnten so nicht mehr gemessen werden.

T4US Record

T4US Skript

Benutzer bei der Arbeit

T4US Play

T4US Agent

Lastgenerator

T4US Play

T4US Play

TS Client

TS Client

Terminal Server

TS Client

System under Test (SUT)

SUT

T4US Control

Controller

Page 8: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 8 (46)

Deshalb wurde ein neues Lastprofil V2 definiert. Die mit dem Lastprofil V2 erreichten maximalen Benutzerzahlen pro System sind natürlich nicht direkt vergleichbar mit den Benutzerzahlen des Lastprofils V1. Im Kapitel PRIMERGY Skalierung werden daher die Messergebnisse in Relation zueinander und nicht mehr absolut angegeben.

Lastprofil V1

Im Lastprofil V1 dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute.

Des Weiteren beinhaltet das Lastprofil:

Jeder Benutzer arbeitet unter einem eigenen Benutzerkonto.

Die erste Anmeldung (Login) des Benutzers und der erste Start der Anwendung liegen außerhalb der Messstrecke. Jedoch meldet sich der Benutzer nach einmal getaner Arbeit am Terminal Server ab und für einen neuen Durchlauf wieder an. Da die Benutzer versetzt gestartet werden, ergibt sich so während der gesamten Messdauer ein kontinuierliches An- und Abmelden.

Jeder Terminal Server Client (Benutzer) startet die Applikation aus seinem Desktop heraus, die Applikation wird bei jedem Skriptdurchlauf gestartet und beendet.

Jeder Benutzer hat sein eigenes Verzeichnis, in dem die im Text verwendeten Bilder hinterlegt sind. So wird verhindert, dass alle Benutzer die gleichen Bilder-Dateien laden und sich diese nach kurzer Zeit alle im Server File Cache befinden. Jeder Benutzer schreibt bei jedem Skriptdurchlauf ein neues Dokument mit eindeutigem Namen. Nach erfolgreicher Erstellung wird das Dokument auf die Festplatte des Terminal Servers in ein benutzereigenes Verzeichnis gespeichert.

Die durchschnittliche Eingabegeschwindigkeit liegt bei etwa 4 Zeichen bzw. Cursor-Bewegungen pro Sekunde. Allerdings finden nicht während des gesamten Durchlaufes Eingaben statt, denn es sind diverse, unterschiedlich lange Denkzeiten im Skript eingestreut, wie es einem natürlichen Arbeiten nahe kommt.

Die Bildschirmauflösung ist 1024x768, die Farbtiefe ist 16-bit.

Ein Durchlauf des Skripts inklusive Wartezeiten dauert ca. 16 Minuten.

Lastprofil V2

Das neue Lastprofil V2 zeichnet sich dadurch aus, dass ein zu simulierender Benutzer mit verschiedenen Microsoft Office Anwendungen nacheinander arbeitet. Neben der Erstellung eines Microsoft Word Dokumentes wird auch eine PowerPoint-Präsentation kreiert. Ebenso werden Berechnungen auf einem neu angelegten Excel-Arbeitsblatt durchgeführt. Die Anzahl der An- und Abmeldevorgänge ist im Vergleich zum Lastprofil V1 reduziert. Im Schnitt meldet sich nur jeder sechste Benutzer zyklisch am Terminal Server ab und wieder an. Ebenso druckt durchschnittlich jeder sechste Benutzer ein Word-Dokument aus. Zusätzliche CPU-Last wird durch Verpacken und Entpacken von Dateien im Speicher erreicht. Die Tippgeschwindigkeit des simulierten Benutzers beträgt zwischen 330 und 440 Anschlägen pro Minute.

Die weiteren Rahmenbedingungen gelten wie beim Lastprofil V1:

Jeder Benutzer arbeitet unter einem eigenen Benutzerkonto.

Jeder Terminal Server Client (Benutzer) startet die Applikation aus seinem Desktop heraus, die Applikation wird bei jedem Skriptdurchlauf gestartet und beendet.

Jeder Benutzer hat sein eigenes Verzeichnis, in dem die im Text verwendeten Bilder hinterlegt sind. So wird verhindert, dass alle Benutzer die gleichen Bilder-Dateien laden und sich diese nach kurzer Zeit alle im Server File Cache befinden. Jeder Benutzer schreibt bei jedem Skriptdurchlauf ein neues Dokument mit eindeutigem Namen. Nach erfolgreicher Erstellung wird das Dokument auf die Festplatte des Terminal Servers in ein benutzereigenes Verzeichnis gespeichert.

Die Bildschirmauflösung ist 1024x768, die Farbtiefe ist 16-bit.

Page 9: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 9 (46)

Messmethode

Zu einer Leistungsmessung gehört neben einem Simulationswerkzeug und einem möglichst realistischen Lastprofil ein Regelwerk, nach dem die einzelnen Messungen durchgeführt und bewertet werden. Im Folgenden wird das Regelwerk beschrieben, nach der die Messungen für diesen Sizing Guide durchgeführt wurden.

Bei der Messung mit variabler Benutzeranzahl wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, nach einer voreingestellten Regel kontinuierlich erhöht, bis der Terminal Server überlastet ist. Dabei wird eine Überlastung des Servers durch die gemessenen Antwortzeiten im Vergleich zu vorher festgelegten Referenzzeiten definiert. Insgesamt müssen 90% der Messwerte innerhalb eines festgesetzten Rahmens liegen, 10% Ausreißer werden toleriert. Die so erreichte Benutzeranzahl ist das Ergebnis der Messung und wird als »Score« bezeichnet.

Die Referenzzeiten werden vorher aus den durchschnittlichen Antwortzeiten bei geringer Belastung (nur wenige simulierte Benutzer) ermittelt. Sie sind hauptsächlich von den Wartezeiten innerhalb der Skripte begrenzt und unterscheiden sich nur minimal von System zu System.

Die Grafik veranschaulicht die Arbeitsweise des T4US Controllers bei der Auswertung der Messwerte. Die waagerechte Linie bei 1000 ms Antwortzeit ist die eingestellte Grenze, die 90% der Messwerte nicht überschreiten dürfen. Einige Ausreißer sind erlaubt, diese werden durch nachfolgende Werte innerhalb des erlaubten Bereichs kompensiert. Werden jedoch zu viele Ausreißer erkannt, gilt der Terminal Server als überlastet. Die Messung wird an dieser Stelle beendet. In diesem Beispiel ist der Score »76 Benutzer«.

Das Bild zeigt außerdem, wie sich die Messwerte weiter verschlechtern würden, wenn noch weitere Benutzer hinzugefügt würden. Rechts von der senkrechten Markierung verlängern sich die Antwortzeiten für alle Benutzer erheblich.

Auch wenn es von Microsoft und Citrix zahlreiche Artikel zur Optimierung von Betriebssystem- und Terminal Server gibt, so haben wir bei unseren Messungen doch gänzlich auf eine Optimierung verzichtet. Der Grund ist, dass viele dieser Einstellungen nur in bestimmten Umgebungen Sinn machen; in einem anderen Umfeld eingesetzt bewirken sie oft das Gegenteil. Da wir verschiedene PRIMERGY Systeme mit unterschiedlichen Systemkomponenten untersucht haben, wären die Ergebnisse nicht miteinander vergleichbar gewesen.

Die einzigen Einstellungen, die verändert werden um alle PRIMERGYs den gleichen Testbedingungen zu unterwerfen, sind:

Das Pagefile des Betriebssystems wurde auf eine feste Größe entsprechend des verwendeten Hauptspeichers eingestellt, um eine Fragmentierung zu vermeiden und damit für alle getesteten Server die gleichen Bedingungen vorliegen.

Für Citrix musste die Grenze von 100 Benutzern pro Server, die durch das eingebaute Load Balancing vorgegeben wird (auch wenn die Terminal Server Farm aus nur einem Terminal Server besteht) aufgehoben werden.

Page 10: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 10 (46)

Messumgebung

Untersucht wurden alle aktuellen PRIMERGY Modelle, die für den Einsatz als typischer Terminal Server geeignet sind, in der folgenden Messumgebung:

Controller (T4US-Control):

Auf dem Controller kam Windows Server 2003 Standard Edition zum Einsatz.

Lastgeneratoren:

20 - 40 Lastgeneratoren (PRIMERGY Dual Server)

Die Lastsimulatoren liefen unter dem Betriebssystem Windows Server 2003 Standard Edition SP1. Die Messungen mit Lastprofil V2 wurden mit SP2 durchgeführt.

Clients:

Für den Zugriff auf den Terminal Server über das ICA-Protokoll wurde der Citrix Terminal Server Client (Programm Neighborhood mit 32-bit ICA-Client) verwendet (entweder Version 7.00.17534 aus »Citrix MetaFrame XP Presentation Server« Feature Release 3 oder Version 9.00.32649 aus »Citrix Presentation Server 4.0«).

Der RDP-Client (»Remote Desktop«) von Microsoft ermöglicht den Zugriff auf einen Terminal Server über das RDP-Protokoll. In Windows Server 2003 Standard Edition ist die Version 5.2.3790.1830 des RDP-Clients enthalten, der das RDP-Protokoll V5.2 unterstützt. Die Messungen mit dem Lastprofil V2 wurden mit dem RDP-Protokoll V6.0.6000.16459 durchgeführt.

Netzwerk:

Die Anbindung der Lastsimulatoren an das SUT-Netzwerk erfolgte über ein 100 MBit-Ethernet-Netzwerk, wobei der Terminal Server über den Gigabit-Uplink angeschlossen war. Das Netzwerkprotokoll war TCP/IP.

Terminal Server (System under Test):

Die vermessenen PRIMERGY Server (System under Test) waren jeweils mit Windows Server 2003 Enterprise Edition ausgestattet. Die Terminal Services waren im Application Server Modus aktiviert. Die Messungen mit dem Lastprofil V2 wurden unter Windows Server 2008 durchgeführt.

Bei den Messungen, bei denen ein Citrix Terminal Server vermessen wurde, war entweder Citrix MetaFrame Enterprise Edition mit Service Pack 3 und Feature Release 3 oder Citrix Presentation Server installiert. Die Terminal Server Farm bestand nur aus einem Terminal Server. Der Data Store befand sich lokal auf der Systemplatte des zu vermessenden Systems und war als Microsoft Access Datenbank realisiert.

Auch die Dateien der Benutzer, die während der Messung gelesen und geschrieben wurden, lagen lokal auf dem Terminal Server.

Die Benutzerprofile wurden standardmäßig auf dem Terminal Server gespeichert.

PRIMERGY C200 T4US-Control

SUT-Netzwerk

ca. 40 PRIMERGY Dual Server Windows Server 2003

TS-Client T4US-Agent, T4US-Playback

Jeder simuliert bis zu 12 Benutzer

Simulations- netzwerk

PRIMERGY C200 Windows Server 2003

Active Directory Terminal Server

Licensing Service

PRIMERGY Windows Server 2003 Windows Server 2008

Enterprise Edition

Infrastruktur- Server

switched 100 Mbit

Lastgeneratoren Controller für die

Simulation

switched 100 Mbit

System under test

(SUT)

Page 11: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 11 (46)

Infrastruktur-Server:

Der Infrastruktur-Server stellt dem System under Test notwendige Dienste zur Verfügung, er selbst wurde nicht vermessen. Der Server wurde so dimensioniert, dass er keinen Engpass darstellt.

Die Benutzerkonten der simulierten Benutzer wurden auf dem Active Directory Domain Controller angelegt. Ein Login fand immer gegen das Active Directory statt.

Das Active Directory System dient gleichzeitig als DNS Server und beherbergt den Terminal Server Licensing Service.

Der Infrastruktur-Server lief unter dem Betriebssystem Windows Server 2003 Standard Edition SP1.

Page 12: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 12 (46)

Ressourcenbedarf

Im Folgenden wollen wir diskutieren und anhand von Messergebnissen untermauern, welche Komponenten welchen Einfluss auf die Leistungsfähigkeit eines Terminal Server Systems haben. Dabei wird neben Aspekten des Betriebssystems auf die Performance-relevanten Faktoren eines Server-Systems wie Rechenleistung, Arbeitsspeicher, Disk-Subsystem und Netzwerk eingegangen. Im Anschluss daran wird das Umfeld, in dem ein Terminal Servers betrieben wird, betrachtet und auf Komponenten der Infrastruktur hingewiesen, die das Performance-Verhalten beeinflussen. Zum Abschluss wird das Verhalten eines Terminal Servers in beobachteten Überlastsituationen erläutert.

Betriebssystem

Microsoft Windows Server Betriebssysteme existieren bis Windows Server 2008 in zwei Varianten, der 32-bit- und der 64-bit-Variante. Auch wenn es zukünftige Betriebssysteme – ab Windows Server 2008 R2 – nur in der 64-bit-Variante geben wird, soll hier noch auf die Unterschiede und die damit möglichen Performance-Einbußen bei Terminal Server eingegangen werden.

Voraussetzung für ein 64-bit-Betriebssystem ist eine 64-bit-Hardware-Plattform. Hier unterscheiden wir aktuell Intel Itanium (IA64) und x64.

IA64

Prozessoren der IA64 Plattform sind nicht Code-kompatibel zu 32-bit-Anwendungen (x86); das hat zur Konsequenz, dass x86-Anwendungen auf Itanium Systemen lediglich emuliert werden, was jedoch einen entsprechenden Performance-Verlust durch die Emulationsschichten bedeutet. Einen Terminal Server auf einer IA64 Architektur zu betreiben ist also nicht sinnvoll, da alle 32-bit-Anwendungen (z.B. Microsoft Office 2007) durch die Emulation sehr langsam laufen würden. Daher gibt es aktuell für Itanium-basierte Systeme weder Citrix Terminal Server Lösungen noch kann unter Windows Server 2008 das Feature Terminal Server konfiguriert werden.

x64

Mit x64 werden die Architekturen bezeichnet, die 100% kompatibel zur x86-Architektur sind und nur Erweiterungen für 64-bit bieten. Hierzu zählen der AMD Opteron mit der AMD64-Achitektur und die Intel Pentium und Xeon Prozessoren der neuesten Generation mit EM64T (jetzt Intel 64)-Architektur.

Der Vorteil der x64 Plattform ist, dass 32-bit-Anwendungen, wie z.B. Microsoft Office direkt unter dem x64-Betriebssystem ausgeführt werden können. Das 64-bit Windows stellt das WoW64 (»Windows on Windows64«) Subsystem bereit, um einen reibungslosen Betrieb der 32-bit-Applikationen zu ermöglichen. Im WoW64 werden Zugriffe auf den Speicher, auf die Registry und auf das Dateisystem isoliert. Allerdings gilt für viele systemnahe Anwendungen und alle Anwendungen, die Treiberkomponenten enthalten, sie müssen speziell für x64-Systeme angepasst werden, da sie im 32-bit-Modus nicht ablauffähig sind. Beispiele für Anwendungen, die speziell für 64-bit angepasst wurden sind Microsoft SQL Server oder Microsoft Exchange Server und die Terminal Server Produkte von Citrix. 16-bit-Anwendungen für DOS oder Windows sind generell nicht mehr ablauffähig, dies ist insbesondere ein Problem für Anwendungen mit einem 16-bit-Installer.

Nachfolgende Tabelle gibt einen Überblick über relevante Systemplattformen und Windows Produkte und deren Anforderungen an Gerätetreiber und Anwendungen.

Server-Plattform x86 x64 x64

Windows Produkt

Windows Server 2003 R2 / Windows Server 2008

Standard Edition Enterprise Edition Datacenter Edition

Windows Server 2003 R2 / Windows Server 2008

Standard Edition Enterprise Edition Datacenter Edition

Windows Server 2003 R2 / Windows Server 2008 Standard x64 Edition Enterprise x64 Edition Datacenter x64 Edition

Betriebssystem 32-bit 32-bit 64-bit

Gerätetreiber 32-bit 32-bit 64-bit

Anwendungen 32-bit 32-bit 32-bit und 64-bit

Page 13: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 13 (46)

Limitierungen

Der wesentliche Unterschied zwischen 32-bit- und 64-bit-Architektur liegt in der Größe des adressierbaren Speichers. Mit einer 32-bit-Architektur sind durch die Wortbreite des Prozessors maximal 2

32 Byte =4 GByte

adressierbar, mit einer 64-bit-Architektur sind es bis zu 264

Bytes = 16 Exabyte (EB). Die nachfolgende Tabelle gibt einen Überblick über die Limitierungen der verschiedenen 32-bit und 64-bit Windows Produkte, die für Terminal Server sinnvoll eingesetzt werden können.

Bei dem 32-bit Windows ist der virtuelle Adressraum von 4 GB standardmäßig in 2 GB für das Betriebssystem und 2 GB für die Anwendungen unterteilt. In den 2 GB, die vom Betriebssystem verwendet werden, werden alle Datenstrukturen und Informationen des Kerns gehalten. Hier sind drei besondere Datenbereiche zu nennen: die Paged Pool Area, die System Page Table Entries (PTE) Area und der System File Cache. Speicher aus der Paged Pool Area wird von Kernel-Mode Komponenten angefordert, während die PTE Area für Kernel Stack Allocations verwendet wird. Im System File Cache werden Speicherabbilder von geöffneten Dateien gehalten. Diese Bereiche teilen sich einen Speicherbereich und die Grenze zwischen ihnen wird unter Windows Server 2003 beim Systemstart fest eingestellt. Wenn dem Betriebssystem während der Laufzeit in einem Bereich der Speicher ausgeht, kann dies nicht aus den anderen Bereichen ausgeglichen werden. Die Folge ist, dass keine neuen Benutzer mehr angemeldet werden können oder dass unerwartete Fehler auftreten. In 32-bit Windows Server 2008 wird der Kernel Address Space dynamisch verwaltet und die Speicherbereiche für Paged Pool, System Cache etc. können entsprechend der Arbeitslast wachsen oder schrumpfen. Begrenzt werden die Bereiche aber durch den aktuell verfügbaren virtuellen Adressraum des Kernels.

PAE (Physical Address Extension) ist eine technische Erweiterung für x86 kompatible CPUs (ab Intel Pentium und AMD Athlon) die es ermöglicht bis zu 2

36 Bytes = 64 GByte Speicher zu adressieren. Dies ist

möglich, da diese Prozessoren einen 36 Bit breiten Adressbus besitzen. Spezielle Erweiterungen in der »Paging«-Einheit des Prozessors sorgen dafür, dass 36-bittige physikalische Adressen generiert werden. Um PAE nutzen zu können, muss es vom Betriebssystem unterstützt werden.

64-bit Windows nutzt vom theoretischen Wert von 16 EB adressierbaren Speichers 16 TB als virtuellen Adressraum. Windows teilt diesen (zumindest aus heutiger Sicht) gigantischen Adressraum in verschiedene Bereiche auf, so dass für den Kernel und jeden 64-bit-Prozess jeweils ein Adressraum von 8 TB zur Verfügung steht. Für 32-bit-Anwendungen, die im so genannten Kompatibilitätsmodus laufen, steht pro Anwendung ein Adressbereich von 4 GB zur Verfügung, aber auch das ist mehr als bei einem reinen 32-bit-Betriebssystem, bei dem es maximal 3 GB sind.

Windows Produkt (WS = Windows Server)

WS 2003 R2 / WS 2008 WS 2003 R2 x64 / WS 2008 x64

Standard Edition

Enterprise Edition

Standard Edition

Enterprise Edition

Anzahl Prozessoren 1 – 4 1 – 8 1 – 4 1 – 8

Max. RAM 4 GB 64 GB

(mit PAE) 32 GB 2 TB

gesamter virtueller Adressraum

4 GB 16 TB

Virtueller Adressraum eines 32-bit-Prozesses

2 GB 2 GB

3 GB wenn mit /3GB Switch gebootet

4 GB wenn mit /LARGEADDRESSAWARE

übersetzt wurde

Virtueller Adressraum eines 64-bit-Prozesses

- 8 TB

Paged Pool 470 MB / WS 2008 dynamisch 128 GB

Non-Paged Pool 256 MB / WS 2008 dynamisch 128 GB

System Page Table Entries

ca. 900 MB / WS 2008 dynamisch 128 GB

System Cache 1 GB / WS 2008 dynamisch 1 TB

Page 14: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 14 (46)

(Light Lastprofil, Microsoft Office 2003,

Microsoft Terminal Services)

Auswirkungen

Wenn ausreichend Hardware-Ressourcen zur Verfügung stehen, also weder die CPU noch der Arbeitsspeicher der begrenzende Faktor ist, dann können auf einem 64-bit-System wesentlich mehr Benutzer betrieben werden als auf einem 32-bit-System. Der Grund hierfür liegt in der Betriebssystemarchitektur, genauer gesagt, bei den Kernel-Ressourcen. Das 32-bit-Betriebssystem hat einen Adressraum von 2 GB zur Verfügung, um seine Daten, unter anderem Kernel-Tabellen und System Cache, zu speichern. Bei hinreichender Rechenleistung erreicht die Benutzeranzahl eine Größenordnung, die für ein 32-bit-Betriebssystem zu hoch ist. Die Kernel-Tabellen sind vollständig belegt, was in Paging-Aktivitäten resultiert, obwohl noch Hauptspeicher frei ist. Weiterhin ist auch der System Cache überlastet und kann nicht weiter vergrößert werden, was zu einer schlechten Trefferrate im Cache führt. Hierdurch steigen ebenfalls die Plattenzugriffe sprunghaft an. Sobald auf die Festplatte statt auf den Arbeitsspeicher zugegriffen werden muss, macht sich das sofort in einer Verschlechterung der Antwortzeiten bemerkbar. Würde man den Terminal Server über diese Engpasssituation hinaus weiter belasten, so würden die Applikationen auf Fehler laufen oder Benutzer könnten sich beim Terminal Server gar nicht mehr anmelden.

In welchem Szenario ein 32-bit-Betriebssystem oder ein 64-bit-Betriebssystem Vorteile bringt, lässt sich gut an Hand einer durchgeführten Messreihe erläutern. Das gleiche PRIMERGY System mit jeweils ausreichender Rechenleistung wurde mit 4, 8, 16 und 32 GB RAM ausgestattet und die maximale Anzahl Light User ermittelt. Bei den Messungen mit 4 GB Hauptspeicher ist sowohl unter dem 32-bit-Betriebssystem als auch unter dem 64-bit-Betriebssystem der Hauptspeicher der limitierende Faktor, was in Paging-Aktivitäten resultiert. Die Messungen unter 64-bit ergeben sogar ein leicht schlechteres Ergebnis. Erklärbar ist das dadurch, dass 64-bit-Anwendungen in der Regel mehr Arbeitsspeicher benötigen als die 32-bit-Versionen, denn alle Adresszeiger sind bei 64-bit doppelt so breit (siehe Kapitel Arbeitsspeicher).

Bei einer Vergrößerung des Speichers auf 8 GB können mehr Benutzer bedient werden, dieser Speicherausbau ist hier die optimale Konfiguration für das 32-bit-System.

Eine weitere Speicheraufrüstung auf 16 GB bzw. 32 GB ist bei diesen Messungen unter dem 32-bit-Betriebssystem nicht von Vorteil. Wie schon oben erläutert, führen die begrenz-ten Kernel-Ressourcen dazu, dass nicht mehr Benutzer unterstützt werden können.

Demgegenüber werden bei dem 64-bit-Betriebssystem durch steigenden Haupt-speicherausbau auch eine steigende Anzahl User erreicht, da keine Limitierungen durch Betriebssystemressourcen auftreten.

Zusammenfassend kann man also feststellen, dass ein 32-bit-Betriebssystem bei Terminal Server limitierend wirkt, wenn entweder der für die gewünschte Anzahl Benutzer notwendige Arbeitsspeicher (> 64 GB) nicht unterstützt wird, oder es aufgrund der vielen Benutzer zu internen Kernel-Engpässen kommt. Dabei ist der Speicherverbrauch eines einzelnen Benutzers natürlich anwendungsabhängig. Bestehen diese beiden Limitierungen nicht, so kann ein 32-bit-Betriebssystem durch geringeren Speicherverbrauch gegenüber dem 64-bit-Betriebssystem punkten.

(Light Lastprofil, Microsoft Office 2003, Microsoft Terminal Services)

Zu wenig Speicher

Engpass der Kernel-Ressourcen

Page 15: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 15 (46)

Rechenleistung

Die Rechenleistung eines Systems hängt von den Prozessoreigenschaften und der Anzahl Prozessoren ab. Unter Prozessoreigenschaften verstehen wir Kenngrößen wie z.B. Taktfrequenz, Cache, Hyper-Threading, Anbindung ans Memory oder Anzahl Kerne. Dabei sind Prozessoreigenschaften immer im Hinblick auf die jeweilige Prozessarchitektur zu sehen.

Prozessortyp

Folgende Übersicht zeigt Prozessoren verschiedener Generationen, die in älteren und aktuellen PRIMERGY Systemen für Terminal Server im Einsatz sind. Die Leistungsdaten gelten für jeweils eine CPU, wie sie mit dem Terminal Server Simulationswerkzeug »T4US« mit dem Lastprofil V1 bzw. V2 ermittelt wurden. Dabei sind alle Werte normiert zu den Ergebnissen der besten Xeon X5570 CPU aufgetragen.

Bei der Betrachtung der Rechenleistung waren alle Systeme mit genügend Arbeitsspeicher ausgebaut. Hyper-Threading, sofern vorhanden, war eingeschaltet, da dieses Feature bei Terminal Server Anwendungen für eine Entlastung des Systems sorgt und dadurch eine höhere Anzahl von Benutzern mit dem Terminal Server arbeiten kann. Aus diesen Messergebnissen für eine CPU kann man die Leistung eines Systems mit einer höheren CPU-Anzahl nicht ablesen, da die Steigerung nicht linear ist (siehe Kapitel Anzahl Kerne).

Page 16: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 16 (46)

Taktfrequenz

Prozessorlinien der PRIMERGY Server gibt es in verschiedenen Leistungsstufen, die sich unter anderem in der Taktfrequenz unterscheiden. Dabei sagt die Taktfrequenz für sich allein nichts über die Leistungsfähigkeit des Prozessors aus. Andere Faktoren wie Architektur, Befehlssatz, Caches, Anbindung ans Memory beeinflussen die Prozessoren in ihrer Leistungsfähigkeit ebenso. Man darf also nicht den Fehler machen, mit einer höheren Taktfrequenz immer eine höhere Performance zu verbinden. Deutlich wird das bei den Intel Xeon 55xx Prozessoren, die im Vergleich zu dem Vorgänger Xeon 54xx niedriger getaktet sind, sich dennoch als viel leistungsfähiger erweisen. Der Vorteil der niedrigen Taktfrequenz liegt in der niedrigeren elektrischen Leistungsaufnahme (Energieverbrauch).

Durch die Einführung der Turbo Boost Technologie bei der Intel Xeon 55xx Serie ist die Kennzahl Frequenz auch nicht mehr so eindeutig. Bei dieser Technologie wird nämlich, abhängig von der Anwendung, der Prozessor automatisch beim Arbeiten unterhalb thermischer und elektrischer Schwellwerte übertaktet. Vereinfacht heißt das: Wenn der Prozessor nicht voll ausgelastet ist und die Thermal Design Power (TDP) nicht überschritten wird, wird der Prozessor höher getaktet.

Vergleicht man Prozessoren einer Familie, die sich nur in der Taktfrequenz unterscheiden während die anderen Kenngrößen wie Architektur, Caches, Memory-Anbindung und Anzahl Kerne gleich sind, so lässt sich durchaus bei höherer Taktfrequenz auch eine höhere Performance nachweisen. Allerdings spiegelt sich die Frequenzsteigerung nicht 1:1 in der relativen Performance-Steigerung wider. Dies erklärt sich aus der gleich bleibenden Geschwindigkeit bei Speicher- und I/O-Zugriffen.

Als Beispiel sind in nebenstehender Grafik die Ergebnisse der PRIMERGY RX300 S4 1-CPU-Messungen der Xeon 54xx Reihe aufgetragen. Die Resultate wurden mit dem Terminal Server Benchmark und dem Lastprofil V1 unter Microsoft Terminal Server erreicht und normiert auf den kleinsten Prozessor dargestellt. Alle Prozessoren haben einen Front-Side-Bus mit 1333 MHz und einen 2 × 6 MB L2-Cache.

(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)

Page 17: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 17 (46)

Memory-Anbindung

Die Memory-Anbindung ist bei den PRIMERGY Systemen je nach Prozessorarchitektur unterschiedlich.

Bei PRIMERGY Systemen, die mit AMD Opteron Prozessoren bestückt sind, ist der Memory Controller in der CPU integriert und die Prozessoren untereinander sind durch einen HyperTransport-Link verbunden.

Bei Intel Prozessoren bis zur Xeon 5400-Serie wird die Kommunikation über den Front-Side-Bus (FSB) zwischen dem Prozessor und der so genannten Northbridge abgewickelt. Die Northbridge ist ein Bestandteil des Chipsatzes, der wiederum mit anderen Komponenten wie zum Beispiel dem Arbeitsspeicher oder dem PCI-Bus verbunden ist. Der FSB wird mit einer bestimmten Taktrate betrieben, welche Einfluss auf die System-Performance hat. Da sich die Prozessoren im Allgemeinen aber nicht nur in der Taktfrequenz des FSBs unterscheiden, ist ein direkter Vergleich unterschiedlicher FSB schlecht möglich.

Unter Laborbedingungen konnte der Einfluss des Front-Side-Bus-Taktes jedoch vermessen werden. Die Grafik zeigt die Performance-Verbesserung durch Steigerung der Front-Side-Bus-Taktfrequenz von 667 MHz auf 800 MHz, was einer Steigerung von ca. 20% entspricht. Die Anzahl der Terminal Server Benutzer steigt in allen drei vermessenen Konfigurationen. Ein schnellerer FSB entlastet den Prozessor, die »% Processor Time« ist bei 800 MHz FSB etwas niedriger und gleichermaßen auch die »Processor Queue Length«. Durch diese CPU-Reserve können mehr Benutzer mit dem Terminal Server arbeiten, bevor die Antwort-zeiten sich verschlechtern und sich nicht mehr im zulässigen Rahmen befinden. Die Steigerung der Benutzeranzahl ist jedoch geringer als die Erhöhung der FSB-Taktfrequenz. Terminal Server als Anwendung beansprucht nicht nur Prozessorleistung, sondern zur Gesamtleistung trägt das Zusammenspiel aller Ressourcen wie Prozessor, Speicher, Netzwerk und Disk bei.

Ab der PRIMERGY Generation mit Prozessoren der Serie Xeon 5500 (Nehalem EP) erfolgte ein Wechsel in der Systemarchitektur, weil die FSB Technologie hinsichtlich ihrer Komplexität, beispielsweise der Anzahl der im Chipset pro FSB benötigten Pins, zuletzt an Grenzen gestoßen ist: Intel Quick Path Interconnect (QPI) statt Front Side Bus (FSB). Der QPI verbindet Prozessoren untereinander, sowie Prozessoren und den für I/O zuständigen Chipsatz, mittels unidirektionaler, serieller Links. Für die Anbindung des Hauptspeichers sind die Prozessoren der Serie Xeon 5500 mit Speicher-Controllern ausgestattet, d.h. jeder Prozessor steuert unmittelbar eine Gruppe ihm zugeordneter Speichermodule. Die Leistungsfähigkeit des Quick-Path Interconnects wird in Gigatransfers pro Sekunde angegeben. Dabei erreichen die aktuellen Prozessoren der Xeon 5500 Serie mit einem QPI von bis zu 6.4 GT/s (entspricht bis zu 25.6 GByte/s) eine weit höhere Bandbreite als der stärkste Prozessor der Xeon 5400 Serie mit Hilfe der der Front-Side-Bus Architektur liefern konnte.

(Lastprofil V1, Microsoft Office 2003,

Microsoft Terminal Services)

Page 18: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 18 (46)

Caches

Ein Cache ist generell ein schneller Zwischenspeicher, der durch die Pufferung von Daten den Zugriff beschleunigt. Bei Intel-CPUs sind die Caches in mehreren Stufen kaskadiert. Man unterscheidet Level 1 Cache, Level 2 Cache (auch Second Level Cache (SLC) genannt) und Level 3 Cache (Third Level Cache (TLC)). Meistens wird bei den Leistungsdaten der CPUs nur der jeweils letzte Cache genannt. Der Cache soll verhindern, dass der Prozessor auf Daten des langsameren Arbeitsspeichers warten muss. Je größer der Cache, umso weniger Speicherzugriffe sind nötig. Aus dieser Zeitersparnis resultiert wiederum eine höhere Rechenleistung.

Vergleichende Messungen mit dem Terminal Server Benchmark zeigten, dass eine Verdoppelung des Caches zu einer Entlastung der CPU führte. Bei sonst gleichen Bedin-gungen wurden jeweils zwei Prozessoren einmal mit 1 MB Cache und einmal mit 2 MB Cache eingesetzt. Wie nebenstehende Grafik zeigt, wird der Prozessor des Terminal Server Systems bei dem größeren Cache weniger stark beansprucht. Daraus resultierte eine höhere Benutzeranzahl als Benchmark-Ergebnis.

Da beim 64-bit-Betriebssystem aufgrund der doppelt so großen Adressbreite mehr Daten verarbeitet werden müssen, hat die Größe des CPU-Caches hier einen größeren Einfluss.

Das gleiche PRIMERGY System wurde wahlweise mit Xeon Prozessoren mit 1 MB oder mit 2 MB SLC ausgestattet. Wie nebenstehende Grafik zeigt, führt eine Verdoppelung des Caches auf beiden Plattformen zu einer höheren Performance. Das 64-bit-System profitiert am meisten von dem doppelt so großen Cache mit einem Performance-Gewinn von 25%. Das 32-bit-System gewinnt bis zu 15% mehr Leistung mit dem größeren Cache. Diese Messungen zeigen, dass ein 64-bit-System durch den Adress-Overhead einen größeren Cache benötigt.

Eine generelle Empfehlung leitet sich aus diesen Ergebnissen ab: Für Systeme mit 64-bit-Betriebssystem sollten in jedem Fall Prozessorvarianten mit einem großen Cache eingesetzt werden. Dies ist wichtiger als eine geringfügig höhere Taktfrequenz.

Allerdings sollte nicht der Fehler begangen werden, Cache-Größen von Prozessoren mit unterschiedlicher Architektur zu vergleichen. Die Caches der Prozessoren sind auf die Prozessorarchitektur abgestimmt. So haben z.B. aktuell Prozessoren der Serie Xeon 5500 (Nehalem) mit 256 kB per Core SLC und maximal 8 MB TLC für alle vier Kerne nominell weniger Cache als Prozessoren der Serie Xeon 5400 (Harpertown) mit 2 × 6 MB SLC. Trotzdem ist die Gesamtleistung der Prozessoren weit höher.

(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)

(Lastprofil V1, Microsoft Office XP, Citrix MetaFrame)

Page 19: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 19 (46)

Hyper-Threading

Bei Hyper-Threading-Prozessoren sind einige Ressourcen auf dem Chip verdoppelt, so dass diese CPUs nun die Fähigkeit besitzen, zwei Threads parallel ausführen zu können. So werden zwei virtuelle bzw. logische CPUs simuliert. Dem Betriebssystem gegenüber stellt sich eine CPU mit Hyper-Threading als zwei CPUs dar und wird auch so angesteuert. Dies bringt einen Geschwindigkeitsvorteil, wenn Betriebssystem und Anwendungen dafür geeignet sind. Windows als Betriebssystem ist vom Design her Hyper-Threading-fähig und gerade in Terminal Server Umgebungen arbeiten viele einzelne Benutzer mit insgesamt vielen, meist kleineren Anwendungen parallel, so dass von Hyper-Threading eine Performance-Steigerung zu erwarten ist.

Die meisten Intel Prozessoren der aktuellen Xeon 5500 Serie (Nehalem) unterstützen Hyper-Threading. AMD Prozessoren besitzen grundsätzlich kein Hyper-Threading.

Messungen haben gezeigt, dass der Performance-Gewinn durch Hyper-Threading bei gering bis mittel belasteten Systemen am größten ist. Bei Systemen, die an ihrer Lastgrenze arbeiten, ist der Performance-Gewinn geringer. Auch ist die Leistungssteigerung auf einem Monoprozessorsystem höher als auf Multiprozessorsystemen.

Eine Messreihe wurde auf einer PRIMERGY RX200 S1 mit zwei Prozessoren durchgeführt, einmal mit eingeschaltetem Hyper-Threading und einmal mit abgeschaltetem Hyper-Threading. In beiden Fällen wurde die gleiche Anzahl von 101 Benutzern simuliert. Bei Terminal Server Anwendungen sorgt das Hyper-Threading für eine Entlastung des Systems, die CPU-Last konnte um 31% reduziert werden, wie die nebenstehende Grafik veranschaulicht. Bei der verwendeten PRIMERGY RX200 S1 und 101 Benutzern konnte man ohne Hyper-Threading schon einen CPU Engpass feststellen, die Antwortzeiten des Terminal Servers waren nicht mehr im vorgegebenen Rahmen. Durch die CPU Entlastung durch Hyper-Threading erfüllte das System wieder die vorgegebene Reaktionszeit.

In einer weiteren Messreihe wurden die absoluten Benutzer-anzahlen für Systeme mit und ohne Hyper-Threading ermittelt. Die nebenstehende Grafik zeigt die Messergebnisse. Das vermessene PRIMERGY System war eine PRIMERGY RX300 S2 mit einem oder zwei Prozessoren mit verschiedenen Takt-frequenzen. Für diesen Vergleich wurden Prozessoren mit 1 MB SLC verwendet. Hyper-Threading war alternativ ein- (»HT on«) oder ausgeschaltet (»HT off«). Man erkennt deutlich, dass mit ein-geschaltetem Hyper-Threading eine höhere Anzahl Benutzer mit

dem Terminal Server arbeiten können. Bei einem langsameren Monoprozessorsystem ist der Performance-Gewinn durch Hyper-Threading höher als bei einem schnellen Dualprozessorsystem.

(Lastprofil V1, Microsoft Office XP,

Citrix MetaFrame)

(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)

Page 20: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 20 (46)

Anzahl Kerne

Eine gängige Variante um die Leistungsfähigkeit eines Prozessors zu steigern, ist die Erhöhung durch die Taktfrequenz. Doch dies geht bei Frequenzen um 4 GHz mit einer nicht mehr sinnvoll handhabbaren Abwärme einher. Eine Möglichkeit der Fortentwicklung ist die Verwendung von Mehrkernprozessoren. Im Gegensatz zum »Hyper-Threading«, wo nur Teile eines Prozessors mehrfach auf dem Chip vorhanden sind um Threads parallel ausführen zu können, sind bei einem Mehrkernprozessor sämtliche Ressourcen des Prozessors repliziert. Mehrkernprozessoren haben zudem den Vorteil, dass die Kosten für den Einsatz eines einzelnen Chips mit mehreren Ressourcen häufig geringer sind als bei mehreren einzelnen Chips. Während bis zum Jahr 2005 die Einzelkernprozessoren dominierten, sind die aktuellen Prozessoren der Intel Xeon Reihe als 4-fach oder auch 6-fach Kerne ausgelegt. Zukünftige Prozessorgenerationen werden die Anzahl Kerne pro Chip noch vervielfachen.

Die rein theoretische Leistungssteigerung beträgt maximal 100% (gegenüber einem einzelnen Kern) pro zusätzlichem Kern. In der Praxis hängt die Leistungssteigerung aber stark von dem Parallelisierungsgrad des ausgeführten Programms und des verwendeten Betriebssystems ab.

Darüber hinaus lässt sich die Rechenleistung eines Systems durch den Einsatz mehrerer Prozessoren erhöhen. Man bezeichnet den Einsatz mehrerer gleicher physikalischer Prozessoren auch als »symmetric multiprocessing« (SMP). Die Skalierung mit wachsender Anzahl Prozessoren ist nur im Idealfall einer optimal parallelisierbaren Anwendung linear. Je mehr Zugriffe jedoch auf gemeinsame Ressourcen wie Arbeitsspeicher, Festplatten oder Netzwerk erfolgen, und somit eine Koordination zwischen den Prozessoren bedingen, umso mehr flacht die Skalierungskurve ab. Im Extremfall kann es bei einer sehr großen Anzahl Prozessoren und sehr hohem Koordinationsanteil der Prozessoren untereinander sogar zu einem »Umkippen« der Skalierung kommen. Schon 1967 betrachtete Gene Amdahl die Beschleunigung von Programmen durch parallele Ausführung in einem mathematischen Modell und stellte fest, dass der Geschwindigkeitszuwachs vor allem durch den sequentiellen Anteil des Programms beschränkt ist (»Amdahls Gesetz«).

Aktuelle Multiprozessorsysteme wirken dem entgegen, indem sie den Prozessoren große Caches beiseite stellen oder Gruppen von Prozessoren bilden und diesen eigenen Arbeitsspeicher und I/O-Komponenten zuordnen. Letzteres bedingt für optimale Performance darauf angepasste Betriebssysteme wie z.B. Windows Server 2003 Enterprise und Datacenter Edition mit »nonuniform memory access« (NUMA) Support.

Wie schon im Kapitel Hyper-Threading ausgeführt, arbeiten in Terminal Server Umgebungen viele einzelne Benutzer mit insgesamt vielen, meist kleineren Anwendungen parallel – eine gute Voraussetzung, um viele Rechenkerne zu nutzen. Bis zu welcher Anzahl Kerne eine Terminal Server Anwendung gut skaliert ist aber auch wieder anwendungsspezifisch und kann nicht verallgemeinert werden.

Wie in der nebenstehende Grafik dargestellt, zeigten Terminal Server Messungen mit dem T4US Lastprofil V2 auf einer PRIMERGY RX300 S5 mit einem und zwei Xeon Quad-Core Prozessoren bei ein-geschaltetem Hyper-Threading eine sehr gute Skalierung vom Faktor 1.7.

(Lastprofil V2, Microsoft Office 2003,

Microsoft Terminal Services)

Page 21: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 21 (46)

Arbeitsspeicher

Den stärksten Einfluss auf die Leistungsfähigkeit des Terminal Servers übt der Arbeitsspeicher aus. Dabei spiegelt sich dies insbesondere in der Antwortzeit wider. Denn Windows verschafft sich bei Bedarf weiteren virtuellen Speicher durch Auslagern (Pagen) von momentan nicht benötigten Daten aus dem Arbeitsspeicher (RAM) in die Auslagerungsdatei (Pagefile) auf Festplatte. Da Plattenzugriffe aber mindestens um die Größenordnung 1000 langsamer sind als Speicherzugriffe, führt dies unmittelbar zum Zusammenbruch der Leistung und zu einem rapiden Anstieg der Antwortzeiten.

Bei Terminal Server wächst der Speicherbedarf linear mit der Anzahl der Benutzer, unabhängig vom PRIMERGY Modell und gleichermaßen bei 32-bit- und 64-bit-Betriebssystemen, wie die beiden Grafiken veranschaulichen.

Trägt man den belegten Speicher, den »Committed« Speicher und den »Working Set« grafisch auf, so erkennt man einen linearen Verlauf, der mit steigender Benutzeranzahl wächst. Während »Available MBytes« den aktuell freien physikalischen Hauptspeicher angibt, wird in »Committed Bytes« angegeben, wie viel virtueller Hauptspeicher den laufenden Anwendungen zugesagt wurde. Der »Working Set« einer Anwendung ist der Speicher, den sie bereits verwendet hat.

Es soll auch nicht verschwiegen werden, dass 64-bit-Betriebssysteme und 64-bit-Anwendungen in der Regel mehr Arbeitsspeicher benötigen als die 32-bit-Versionen, denn alle Adresszeiger sind bei 64-bit doppelt so breit. Im Extremfall führt das bei 64-bit zu einem doppelten Speicherbedarf im Vergleich zu 32-bit.

Wie die nebenstehende Grafik zeigt, belegt der gleiche Benutzer, der den Desktop gestartet hat und mit Microsoft Word 2003 arbeitet, auf dem 64-bit-System im Vergleich zum 32-bit-System ca. 60% mehr Arbeitsspeicher. Die Anwendung, mit der der Terminal Server Benutzer arbeitet, ist in beiden Fällen Microsoft Word, welches heute nur als 32-bit-Version existiert.

Allgemeingültig ist jedoch die Tatsache, dass der Speicherbedarf linear nach der Formel

anwächst.

Man beachte dabei nur, dass der Speicherbedarf pro Benutzer stark von der verwendeten Anwendung abhängt und jeweils kundenspezifisch ermittelt werden muss. Kennt man jedoch den Speicherbedarf der Anwendung bei einem Benutzer, so lässt sich leicht der Gesamt-Speicherbedarf berechnen.

(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)

Page 22: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 22 (46)

Nach oben begrenzend wirken nur der maximal mögliche Speicherausbau des Systems sowie die Unterstützung des Betriebssystems (siehe Kapitel Limitierungen).

Der maximale Speicherausbau eines Systems ist abhängig vom Modell.

Die x86-basierten PRIMERGY Server haben unterschiedliche Architekturen. Die älteren Modelle (von Intel Pentium Pro Prozessor (1995) bis Intel Xeon 5400 (Harpertown)) entsprechen dem Prinzip des Symmetric Multiprocessing (SMP). Die Anbindung der Prozessoren an den Hauptspeicher ist durch einen Front-Side Bus realisiert ist. Auch bei der Bestückung mit nur einem Prozessor ist der gesamte Speicher nutzbar.

Intel Xeon Prozessoren ab der Xeon 5500 Serie unterliegen einer anderen Architektur. Für die Anbindung des Hauptspeichers sind diese Prozessoren mit Speicher-Controllern ausgestattet, d.h. jeder Prozessor steuert unmittelbar eine Gruppe ihm zugeordneter Speichermodule. Gleichzeitig ist der Prozessor in der Lage, über den Quick Path Interconnect Speicherinhalte dem benachbarten Prozessor zur Verfügung zu stellen und solche selbst anzufordern (siehe Kapitel Memory-Anbindung). Durch die direkte Kopplung zwischen Prozessor und Speicher ist eine Steigerung der Speicher-Performance plausibel, jedoch mit dem Performance-Unterschied zwischen lokaler und ferner Anforderung, der die Klassifizierung dieser Architektur als NUMA rechtfertigt. Die Berücksichtigung von NUMA bei der Vergabe von physikalischem Speicher und beim Scheduling von Prozessen erfolgt durch das Betriebssystem. Soweit möglich, sollte die Gesamtmenge an Arbeitsspeicher symmetrisch über beide Prozessoren verteilt werden. Ist das System nur mit einem Prozessor bestückt, können auch nur die diesem Prozessor zugeordneten Speicherbänke genutzt werden.

Weitere Performance-relevante Hinweise zu leistungsfähigen Speicherkonfigurationen der Xeon 5500 basierten PRIMERGY Systeme finden sich im Dokument »Speicher-Performance Xeon 5500 (Nehalem EP) basierter PRIMERGY Server« [L4].

Auch PRIMERGY Modelle mit AMD Opteron Prozessoren besitzen eine direkte Zuordnung des Speichers zu den Prozessoren. Jeder Prozessor hat »seinen« Speicher direkt angebunden, was in einem schnellen Zugriff resultiert. Aus dieser Systemarchitektur folgt umgekehrt, dass eine PRIMERGY, die lediglich mit einem AMD Opteron Prozessor bestückt ist, auch nur die Hälfte der Speicherbänke nutzen kann, da der zweite CPU-interne Memory Controller zur Ansteuerung fehlt.

Bei der Kalkulation des Arbeitsspeichers für Terminal Server sollte man zwei Besonderheiten nicht außer Acht lassen:

»Desktop« oder »Published Application«?

Bei Terminal Server Umgebungen muss man dem Benutzer nicht den gesamten Desktop mit allen Anwendungen zur Verfügung stellen, man kann den Zugriff auch beschränken. Microsoft Terminal Server kann man so konfigurieren, dass eine bestimmte Anwendung statt des Desktop gestartet wird.

Bei Citrix Presentation Server kann man den Benutzern auch mehrere einzelne Anwendungen (»Published Application«) direkt zur Verfügung stellen, der Start der Applikation innerhalb des Desktop entfällt. Dabei werden pro Benutzer ungefähr 5 bis 10 MB an Hauptspeicher gespart, da der Explorer-Prozess nicht mit gestartet werden muss. Auch wenn es in einer bestimmten Umgebung vielleicht nicht um diesen kleinen Gewinn von Hauptspeicher geht; ein nicht zu vernachlässigender Vorteil dieser Konfiguration ist, dass der Benutzer nur die für ihn vorgesehenen Anwendungen auf dem Server laufen lassen kann. Man kann also die Aktionen der Benutzer besser vorhersagen und auch einschränken.

Der Speicherbedarf eines Benutzers, der eine Anwendung über den Desktop startet, wurde mit dem Speicherbedarf eines Anwenders verglichen, der die gleiche Applikation direkt ohne Desktop startet. Die Anwendung Microsoft Word aus Microsoft Office 2003 wurde einmal über den Desktop und einmal über den RDP Client direkt gestartet. Wie nebenstehe Graphik deutlich zeigt, ist der Speichermehrverbrauch ohne Starten des Desktops geringer.

(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)

Page 23: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 23 (46)

»Logoff« oder »Disconnect«?

Es ist ein Unterschied, ob der Benutzer die Verbindung zum Terminal Server beendet, indem er sich abmeldet (»Logoff«) oder ob er mit einem »Disconnect« die Verbindung nur unterbricht. Im letzteren Fall läuft die Anwendung auf dem Terminal Server weiter und gibt ihre Ressourcen nicht frei. Der Benutzer kann seine Arbeit dann an dieser Stelle fortsetzen. Wenn der belegte Arbeitsspeicher des Servers analysiert wird, zählen die Verbindungen im Status »Disconnect« natürlich mit. Manche Anwendungen brauchen auch CPU-Ressourcen, während die Verbindung getrennt ist. Sowohl Microsoft als auch Citrix unterstützen »disconnected« Sessions.

Page 24: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 24 (46)

Disk-Subsystem

Geht man davon aus, dass ein Server dediziert als Terminal Server eingesetzt wird, und nicht gleichzeitig noch als File Server oder Datenbank-Server, so werden an das Disk-Subsystem keine großen Anforderungen gestellt. Es muss im Wesentlichen nur das Betriebssystem, den Paging-Bereich und die den Terminal Server Clients zur Verfügung stehenden Applikationen beherbergen. Die Plattenzugriffe sind dabei gering. Auf das Betriebssystem und die Applikationen wird nur zugegriffen, wenn sie das erste Mal in den Speicher geladen werden. Der Paging-Bereich spielt prinzipiell auch keine Rolle, denn das System muss so konfiguriert sein, dass es nicht in starkes Pagen gerät, anderenfalls ist die Leistungsfähigkeit des Systems in jedem Fall erheblich beeinträchtigt.

Die Benutzerdaten und Benutzerprofile werden typischerweise auf entsprechende Disk-Subsysteme oder externe File Server gelegt und nicht auf die lokalen Festplatten eines Terminal Servers.

Wird ein Terminal Server auf moderner Server-Hardware mit Multi-Core-Architektur und ggf. einem 64-bit-Betriebssystem aufgebaut, so können damit mehr Benutzer arbeiten und somit muss auch das Disk-Subsystem wachsen, um diesen Anforderungen gerecht werden zu können. Durch mehr Benutzersitzungen finden mehr Zugriffe auf das lokale Pagefile und auf das Disk-Subsystem statt und beim 64-bit-Betriebssystem werden auch größere Datenmengen Richtung Pagefile geschrieben. Aus diesen Gründen muss das Disk-Subsystem entsprechend dimensioniert werden. Hinweise zum Monitoren des Disk-Subsystems finden sich im Kapitel Engpassanalyse.

Um einen maximalen Durchsatz zu erreichen, sollten alle vorhandenen Controller- und Festplatten Caches (auch die Write-Caches) eingeschaltet werden. Write-Caches der Festplatten tragen erheblich zur Performance-Steigerung bei, und es empfiehlt sich, diese bei allen Festplatten vorhandene Funktionalität auch im produktiven Einsatz zu nutzen. Dabei ist die Verwendung einer USV zum Schutz gegen Stromausfälle und damit verbundenem Datenverlust empfehlenswert.

Zum Sizing von Disk-Subsystemen wurde ein eigenes White Paper »Performance Report - Modular RAID für PRIMERGY« [L5] erstellt.

Wird das Terminal Server System hingegen gleichzeitig noch als Datei- oder Datenbank-Server eingesetzt, so gelten für das Disk-Subsystem natürlich zusätzliche Kriterien, wie sie für Datei- oder Datenbank-Server typisch sind. Von einer solchen Konstellation ist jedoch abzuraten, es sei denn, das System wird nur in einem sehr begrenzten Workgroup-Umfeld eingesetzt. Ansonsten sollten dedizierte Systeme für die einzelnen Aufgaben, wie Terminal Server, Datei-Server, Datenbank- oder Applikations-Server, aufgebaut werden. Nur so kann ein Server-System optimal für seinen Aufgabenbereich zugeschnitten werden.

Je nach Anzahl Festplatten im Server-System gelten folgende Empfehlungen:

Zwei Festplatten, Konfiguration für Sicherheit: Wenn nur zwei Festplatten zur Verfügung stehen und auf Sicherheit Wert gelegt wird, so sollte aus Sicherheitsgründen eine Spiegelung über RAID 1 eingerichtet werden. Dort befinden sich dann Betriebssystem, Paging-Bereich und Applikationen. Eine Spiegelung kann entweder mit den onboard RAID 1-Funktionalitäten, die fast alle PRIMERGY Server standardmäßig bieten, oder softwaremäßig mit Windows Mitteln realisiert werden. Alternativ kann auch ein RAID-Controller eingesetzt werden.

Zwei Festplatten, Konfiguration für Performance: Um eine bessere Performance zu erreichen, sollte das Pagefile nicht auf einer gespiegelten Festplatte konfiguriert werden. Wenn nur zwei Festplatten zur Verfügung stehen, sollten das Betriebssystem und die Applikationen auf der ersten Festplatte gespeichert werden, während das Pagefile auf die zweite Festplatte gelegt werden sollte. Da die Festplatte des Betriebssystems nicht gespiegelt ist, sollte sichergestellt werden, dass dort keine Benutzerdaten abgelegt und dass regelmäßige Backups durchgeführt werden.

Drei oder mehr Festplatten: Stehen insgesamt mindestens drei Festplatten zur Verfügung, sollte man zwei Festplatten mit Hilfe von RAID 1 spiegeln und dort das Betriebssystem und die Applikationen unterbringen. Der Paging-Bereich wird auf die dritte dedizierte Festplatte gelegt, da die Nutzung einer gespiegelten Festplatte durch das Pagefile beträchtliche Auswirkungen auf die Performance haben kann. Da diese Daten alle temporärer Natur sind, ist hier natürlich keine Absicherung durch RAID notwendig.

Page 25: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 25 (46)

Netzwerk

Obwohl dem Thema Netzwerk im Terminal Server Umfeld eine wichtige Rolle zukommt, wird es im Rahmen dieses Papieres nicht ausführlich behandelt, da es ein eigenständiges Thema darstellt. Auch soll hier ein einzelner Terminal Server und nicht eine Terminal Server Farm im Focus stehen. In der Praxis sind zudem häufig schon Netzwerk-Topologien vorhanden, in die der Terminal Server zu integrieren ist.

Bei der Betrachtung eines einzelnen Terminal Servers ist zu berücksichtigen, dass er bezüglich Netzwerkanbindung die benötigten Bandbreiten für alle Benutzer zur Verfügung stellt. Welche Bandbreiten für den Terminal Server benötigt werden, ist dabei stark vom Benutzer abhängig. Benutzer, die z.B. mehr im Office-Umfeld mit Textverarbeitung zu tun haben, benötigen weniger Bandbreite als Nutzer von 2D- oder 3D-Anwendungen. Ebenso spielt das verwendete Übertragungsprotokoll eine Rolle. Dabei hat sich das von Citrix entwickelte ICA-Protokoll als effizienter erwiesen als RDP von Microsoft.

Aktuelle PRIMERGY Server bieten mit ihren Gigabit Ethernet Anschlüssen eine gute Voraussetzung, um einen Terminal Server performant zu betreiben.

Bedingt es das Aufgabenszenario, dass die auf dem Terminal Server ablaufenden Anwendungen auf große Datenmengen, Datenbanken oder gar Host-Anwendungen zugreifen, so empfiehlt es sich, den Terminal Server mit einer weiteren Netzwerkkarte für den dedizierten Zugriff auf diese Server-Dienste auszustatten, um so den Datenverkehr in dieser Three-Tier-Umgebung zwischen Server-Server- und Client-Server-Kommunikation zu trennen.

In einer Terminal Server Umgebung muss folgender Netzwerkverkehr berücksichtigt werden:

Terminal Server und Active Directory Hauptsächlich während des Anmeldevorgangs der einzelnen Benutzer in die Domäne werden Informationen aus dem Active Directory benötigt. Dies wird in realen Konfigurationen oft auch über ein Netzwerksegment abgewickelt, das von den Client-Netzwerken getrennt ist.

Clients und Terminal Server Tastatur- und Mauseingaben werden zum Terminal Server gesendet, und die Änderungen der Bild-schirmdarstellung werden zum Client übertragen.

Database Server

File Server

Application Server

Terminal Server

Network Network

Page 26: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 26 (46)

Infrastruktur

In unseren Untersuchungen haben wir den Terminal Server immer isoliert betrachtet. In der Messumgebung gab es weitere Komponenten, mit denen der Terminal Server zusammen arbeitet, jedoch waren diese immer konstant und so ausgelegt, dass diese nicht der Engpass waren. In der Realität ist dies jedoch nicht immer der Fall. In diesem Abschnitt soll diskutiert werden, welche weiteren Komponenten der Infrastruktur einen Einfluss auf das Benutzerempfinden in einer Terminal Server Umgebung haben, was sich in einem negativen Gesamteindruck widerspiegeln könnte.

Clients

Neben den Server-Ressourcen und dem Netzwerk gehört natürlich auch der Client zur Gesamtumgebung des Server-based Computing. Also ist auch bzgl. des Clients die Frage berechtigt, welchen Einfluss dessen Leistungsfähigkeit auf die Gesamtkonfiguration hat. Da beim klassischen Server-based Computing die eigentliche Applikation auf dem Server abläuft, wird die CPU-Leistung des Clients nur für die Bedienung des Netzwerks und die vom Aufwand her nicht zu vernachlässigende Bildaufbereitung benötigt. Es wurde festgestellt, dass je nach verwendetem Client-System die Gesamt-Ausführungszeit einer Applikation durchaus variiert. Diese Unterschiede dürften sich im realen Betrieb aber allenfalls in einem subjektiven Performance-Eindruck des Benutzers widerspiegeln und haben keinen unmittelbaren Einfluss auf die Leistungsfähigkeit des Terminal Server Systems.

Wie »thin« der Thin-Client sein darf, hängt in erster Linie von den Ansprüchen seitens der eingesetzten Applikationen an die Grafik ab, wie Auflösung, Farbtiefe und Komplexität (Text, Grafik) sowie von ggf. zusätzlichen Anforderungen an lokal auf dem Client ablaufende Anwendungen, die über das reine Server-based Computing hinausgehen.

Neben den ortsgebundenen (Thin-)Clients gibt es die Anforderungen auch mobile Geräte wie Notebooks oder PDAs an Terminal Server anzuschließen. Üblicherweise werden diese Geräte dann nicht mehr über kabelgebundene Netzwerke angeschlossen, sondern über Funk-LANs (W-LAN) oder mobile Funknetze (z.B. »General Packet Radio Services« (GPRS) oder »Universal Mobile Telecommunication System« (UMTS)).

Dies stellt insbesondere beim Ressourcen sparenden ICA-Protokoll kein Problem dar. Den ICA-Client gibt es auch für viele gängige PDAs und das ICA-Protokoll ist durch sein Design besonders auch für langsame Verbindungen geeignet. Für Benutzer, die ständig und ausschließlich mit Terminal Server Anwendungen arbeiten, stellt solch ein Endgerät sicher nicht den idealen Client dar, aber jemand, der mobil arbeiten muss und nur gelegentlich Zugriff auf einen Terminal Server braucht, profitiert von der Flexibilität und Funktionalität dieser Lösung.

Active Directory

Terminal Server Benutzer authentifizieren sich im Normalfall in einer Domäne, d.h. der Terminal Server überprüft die eingegebenen Benutzercredentials gegen das Active Directory. Außer in sehr kleinen Workgroup-Umgebungen sollten Active Directory und Terminal Server immer auf verschiedenen Systemen laufen und auf dem Terminal Server selbst sollten keine Benutzer verwaltet werden. An das Active Directory werden die gleichen Anforderungen gestellt wie in einer Umgebung ohne Terminal Server, es sollte aber weder das Active Directory noch das Netzwerk zwischen Active Directory und Terminal Server der Engpass sein.

Benutzerprofile (User Profiles)

In einem Benutzerprofil werden die individuellen Benutzereinstellungen gespeichert. Auch bei einem Login von Terminal Server Benutzern in einer Domäne in einem Active Directory Umfeld würden deren Benutzerprofile standardmäßig auf dem Terminal Server gespeichert. Insbesondere bei einer load-balanced Terminal Server Farm wird man die Benutzerprofile allerdings zentral auf einem Server im Netzwerk ablegen wollen, damit der Benutzer immer die gleichen Einstellungen vorfindet, unabhängig davon, auf welchem Terminal Server seine Sitzung ausgeführt wird. Diese Funktionalität ist bereits für so genannte »Wandernde Benutzer« (Roaming User) vorhanden, die sich an verschiedenen Arbeitsplätzen anmelden. Beim Einsatz von Terminal Servern ist zu beachten, dass ggf. verschiedene Benutzerprofile verwaltet werden müssen, wenn sich nämlich das lokale Betriebssystem des Arbeitsplatzes von dem des Terminal Servers unterscheidet bzw. wenn verschiedene Anwendungen vorhanden sind. Aus diesem Grunde kann man ein Terminal Server Benutzerprofil zusätzlich zu einem lokal zu ladenden Benutzerprofil konfigurieren. Eine besondere Variante des Server-basierten Benutzerprofils ist das Mandatory User Profile, ein Benutzerprofil, das der Benutzer nicht ändern kann. Server-basierte Benutzerprofile sollten generell möglichst klein sein.

Page 27: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 27 (46)

DNS

Auch im Terminal Server Umfeld wird DNS verwendet, um die Namensauflösung von Verbindungen zu realisieren. Besonders im Load Balancing Umfeld wird auf diese Weise ein virtueller Name mit einer virtuellen oder realen IP-Adresse verknüpft, so dass sich eine Terminal Server Farm zum Benutzer hin wie ein Server darstellt. Daraus ergibt sich umgekehrt die Forderung, dass DNS immer erreichbar sein muss, damit ein Benutzer eine Verbindung zum Terminal Server aufbauen kann. DNS stellt im Allgemeinen keinen Engpass dar, dieser Dienst sollte nur ausfallsicher und redundant konzipiert sein.

Terminal Services Licensing Server

Bei der Anmeldung eines Benutzers an einen Terminal Server wird dieser einen Lizenz-Server suchen und von ihm eine gültige Lizenz für den Zugriff über Terminal Server anfordern. In größeren Konfigurationen wird dieser Lizenz-Server ein eigenes System sein.

Backend Server

Gerade in »load-balanced Terminal Server Farmen« werden die Dateien der Benutzer nicht auf den lokalen Festplatten der Terminal Server Systeme liegen, sondern auf File Servern oder NAS Systemen. Vermutlich werden in größeren Umgebungen auch weitere Dienste wie E-Mail, Datenbanken usw. benötigt, so dass man Server für Anwendungen wie zum Beispiel Exchange, SQL oder SAP R/3 zusammen mit dem Terminal Server vorfinden wird. Wird für die Anbindung der Clients zum Terminal Server nur wenig Netzwerkbandbreite benötigt, so gilt dies nicht für die Anbindung der Terminal Server an die Backend Server. Hier sollte genügend Netzwerk- und Rechenkapazität zur Verfügung stehen. Für die einzelnen Server verweisen wir auf eigene Performance-Untersuchungen und Sizing Guides, da dies den Rahmen dieses Papiers sprengen würde. Es wird nicht empfohlen, Backend-Dienste auf einem Terminal Server zu betreiben.

Page 28: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 28 (46)

Überlastverhalten

Bei allen PRIMERGY Servern, insbesondere aber bei den leistungsfähigeren, kann man ein Verhalten beobachten, bei dem ein scheinbar normal ausgelastetes System durch das Hinzufügen einiger weniger Benutzer überlastet wird. Setzt man die Anzahl Benutzer, die CPU-Auslastung des Systems und die Antwortzeiten miteinander in Beziehung, so erkennt man, wie sich die Antwortzeiten des Terminal Servers bei steigender Auslastung verhalten. Während einer Messung über 25 Minuten wurde in den ersten 15 Minuten die Benutzeranzahl kontinuierlich erhöht. Jeder Benutzer meldet sich erst an, danach arbeitet er mit Microsoft Word, um sich nach ca. 16 Minuten wieder abzumelden und wieder von vorn zu beginnen.

Dadurch verteilen sich die Benutzeranmeldungen (blaue Kurve ) auf einen relativ kurzen Zeitraum, was aber der Realität nahe kommt, wenn die Benutzer etwa zur gleichen Zeit ihre Arbeit aufnehmen. Die CPU Auslastung des Terminal Servers stieg ständig an (rote Kurve ) bis nah an 100%. Zwei signifikante Messergebnisse wurden beobachtet: Die Zeit, die der Benutzer brauchte, um sich am Terminal Server anzumelden (violette Kurve ) und die Zeit, um in Microsoft Word ein Bild einzufügen (grüne Kurve ). Eine Anmeldung an den Terminal Server beinhaltet nicht nur das Login selbst, sondern auch der Desktop des Benutzers wird gestartet. Dies belastet den Terminal Server mehr als das Einfügen des Bildes in Microsoft Word. Aktionen, die von sich aus den Terminal Server stark belasten, werden unter Hochlast stärker verlangsamt als weniger belastende Aktionen. Man erkennt drei Phasen der Terminal Server Auslastung:

Die CPU-Belastung des Terminal Servers ist unter 70%. Die Antwortzeiten des Servers verlängern sich geringfügig, dies wird der Benutzer aber nicht realisieren.

Die CPU-Belastung des Terminal Servers ist zwischen 70% und 90%. Aktionen, die den Server stärker belasten, sind verlangsamt, aber die Antwortzeit ist für den Benutzer noch tolerierbar. Aktionen, die den Server nicht so stark belasten, haben im Durchschnitt die gleichen Reaktionszeiten, jedoch können Schwankungen auftreten.

Wenn die CPU-Belastung des Terminal Servers über 90% ist, ist der Server deutlich überlastet. Je nach Benutzeraktion antwortet der Server wesentlich später, speziell Aktionen wie ein Login brauchen deutlich mehr Zeit. Aber auch einfachere Aktionen sind deutlich verlangsamt. Der Benutzer wird das Antwortzeitverhalten des Servers nicht mehr tolerieren.

Anzahl Prozesse

Auch wenn es paradox klingt: es kann Konstellationen geben, in denen, obgleich ausreichend CPU- und Speicher-Ressourcen zur Verfügung stehen, es zu Leistungsengpässen kommen kann. Auch Disk-I/O oder Netzwerke stellen in dieser Situation keinen Engpass dar, sondern quasi die Systemarchitektur. Diese Situation wird insbesondere von einer großen Anzahl an Benutzern, die viele Prozesse mit einer geringen gleichmäßigen Last induzieren, provoziert. Dabei spielt die Prozessor-Warteschlange eine nicht zu vernachlässigende Rolle. So gibt es in Abhängigkeit der Prozessor-Leistung und Prozessor-Anzahl einen Punkt, an dem das System keine weiteren Prozesse und somit Clients mehr bedienen kann. Im Prinzip ist hierbei das System nur noch damit beschäftigt, die Prozesse zu verwalten. Oder in »Fachchinesisch« ausgedrückt: In einem Multitasking-Betriebssystem erhält jeder Prozess eine Zeitscheibe, die er nicht schnell genug wieder frei gibt. Diese Situation könnte nur durch kleinere Zeitscheiben und somit größeren Turn-Around-Zeiten behoben werden. Dies hätte jedoch in anderen Lastsituationen negative Auswirkungen auf die Grundlast, die das Betriebssystem erzeugt. Die Anzahl Prozesse, ab der diese Situation eintritt, hängt neben der zur Verfügung stehenden CPU-Leistung und -Anzahl leider aber auch von der verwendeten Applikation ab, sodass keine generelle Formel hierfür angegeben werden kann. Bei Heavy Usern tritt dieser Effekt meist nicht zu Tage, da hier andere Ressourcen, wie Speicher und Rechenleistung die dominierenden Begrenzungsfaktoren sind.

Page 29: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 29 (46)

PRIMERGY Skalierung

Die Leistungsfähigkeit des Terminal Servers ist durch CPU-Leistung und Hauptspeicher bestimmt.

Den Speicherausbau kann man recht einfach anhand der Formel

abschätzen. Werden verschiedene Applikationen gleichzeitig verwendet, so ist die Summe des Speicher-bedarfs aller gleichzeitig verwendeter Applikationen zu bilden.

Die Anzahl Benutzer bei einer vorgegebenen Speichermenge kann mit folgender Formel berechnet werden:

Für die CPU-Leistung gilt leider keine so einfache Formel. Bei einem Medium oder Heavy User stellt im Allgemeinen die CPU-Leistung den begrenzenden Faktor dar. Für eine Klasse von Light Usern ist die maximale Benutzerzahl eher durch andere Systemressourcen begrenzt.

Die Vielzahl an Prozessoren, mit denen jedes PRIMERGY-Modell ausgestattet werden kann, lässt bereits erahnen, dass es nicht eine bestimmte Anzahl Benutzer gibt, die ein PRIMERGY-Modell bedienen kann, sondern dass jedes PRIMERGY-Modell eine gewisse Bandbreite abdeckt. Auch gibt es keine scharfe Grenze, wo die Leistung eines Modells endet und die des nächst leistungsfähigeren beginnt. Vielmehr gibt es Überlappungen zwischen den Systemen. Die folgenden auf Basis unserer Messreihen gewonnenen Ergebnisse können also nur einen Eindruck für den Leistungsbereich vermitteln.

Page 30: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 30 (46)

Da die Systeme mit unterschiedlichen Lastprofilen vermessen wurden, sind keine absoluten Benutzeranzahlen angegeben. Vielmehr soll die relative Leistung der Systeme unter Terminal Server Anwendungen aufgezeigt werden. In dieser Darstellung wird die PRIMERGY RX300 S3 als Bezugssystem genommen und die auf dem System gemessenen Anzahl Benutzer zu 100% gesetzt. Alle anderen Systeme werden in Relation zum Bezugsystem angegeben, wobei die unterschiedlichen Lastprofile entsprechend berücksichtigt sind.

Wenn Sie einen Terminal Server oder eine Terminal Server Farm planen, sollten Sie sich die Zeit nehmen, das Benutzerverhalten vorher genau zu analysieren.

Welche Anwendungen müssen generell über den Terminal Server zur Verfügung gestellt werden?

Welcher Benutzer nutzt wann und wie oft welche Anwendung?

Wie intensiv wird die Anwendung verwendet?

Welche Bildschirmauflösung und Farbtiefe verwendet der Client?

Welches Netzwerk und Protokoll wird verwendet?

Welche Antwortzeiten werden erwartet?

Bei größeren Konfigurationen sollte auf eine Pilotphase unter realen Bedingungen nicht verzichtet werden.

Page 31: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 31 (46)

Analysewerkzeuge

Bei Performance-Problemen oder auch vor der Migration von Systemen ist es hilfreich, die Terminal Server Umgebung zu analysieren. Je nach gewünschtem Detaillierungsgrad eignen sich verschiedene mehr oder weniger aufwändige Methoden, um sich einen Überblick über die aktuelle Situation zu verschaffen oder einen zeitlichen Ablauf der Systemauslastung aufzuzeichnen. Im Folgenden werden für die Analyse von Systemen nützliche Werkzeuge kurz vorgestellt. Eine ausführliche Beschreibung der Tools würde den Rahmen dieses Papiers sprengen.

Task-Manager

Am bekanntesten ist der Windows Task-Manager »taskmgr.exe«, den man in allen Windows Server Betriebssystemen, aber auch in Windows XP findet. Mit dem Task-Manager kann man sich einen schnellen Überblick über die aktuelle Systemauslastung verschaffen, weiterhin können laufende Anwen-dungen bzw. Prozesse und die Netzwerkauslastung angezeigt werden. Als Administrator kann man auch Prozesse beenden oder deren Prioritäten ver-ändern. Zum Aufrufen klickt man mit der rechten Maustaste auf eine leere Stelle in der Taskbar und dann klickt man auf »Task-Manager«. Das Pro-gramm selbst stellt eine ausführliche Online-Hilfe bereit; weitere Informationen findet man auch bei Microsoft im Internet. Auf Terminal Server Systemen empfiehlt es sich, unter »Prozesse« die Einstellung »Prozesse aller Benutzer anzeigen« zu selektieren. Hilfreich kann auch bei »Systemleistung« unter »Ansicht« die Einstellung »Kernel-Zeiten anzeigen« sein, um den CPU-Verbrauch des Kernels einzeln zu überwachen.

Sysinternals Process Explorer

Detailreichere Informationen bietet das Freeware-Programm »Process Explorer«, das von den beiden Windows Spezialisten Mark Russinovich und Bryce Cogswell kostenlos unter www.sysinternals.com bereitgestellt wird. Es bietet eine wesentlich größere Funktionalität als der Windows Task-Manager. Hervorzuhe-ben sind die Baumansicht der Prozesse, die gerade bei Terminal Server Systemen eine einfache Zuordnung von Prozessen zu Benutzern ermöglicht, und die erweiterte »System Information«-Anzeige. Der »Process Explorer« muss nicht installiert werden, kann aber auch an Stelle des Task-Managers in Windows integriert werden. Dieses Programm liefert eine Online-Hilfe mit, aber auch die Sysinternals-Web-Seite liefert nützliche Informationen.

Performance Monitor

Um den Verlauf des Ressourcenverbrauchs zu dokumentieren und zu speichern, sind o.g. Tools weniger geeignet. Hierzu gibt es in allen aktuellen Windows Versionen den System Monitor, oder auch Performance Monitor genannt, mit dem man über einen längeren Zeitraum so genannte Performance Counter beobachten kann. Performance Counter sind Objekt-spezifisch gruppiert, teilweise gibt es sie auch in verschiedenen Instanzen, wenn ein Objekt mehrfach vorhanden ist. Beispielsweise gibt es für das Objekt »Prozessor« einen Performance Counter »%Processor Time«, wobei dann bei einem Multiprozessorsystem eine Instanz pro CPU existiert. Nicht alle Performance Counter sind in Windows bereits vorhanden, sondern viele Anwendungen wie z.B. Citrix Presentation Server bringen ihre eigenen Performance Counter mit, die sich in das Betriebssystem integrieren und über den Performance Monitor abgefragt werden können. Die Performance-Daten kann man entweder am Bildschirm verfolgen oder, besser, in eine Datei schreiben und offline analysieren. Es können nicht nur Performance Counter des lokalen Systems ausgewertet werden, sondern auch von entfernten Servern, die entsprechenden Zugriffsrechte vorausgesetzt. Das Programm, das sich unter »perfmon.exe« aufrufen lässt, ist in der Windows Hilfe oder in

Page 32: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 32 (46)

Microsoft Artikeln im Internet beschrieben, weiterhin gibt es für jeden einzelnen Performance Counter unter »Erklärung« eine Erläuterung.

Zu beachten ist, dass der Performance Monitor auch eine Windows Anwendung ist, die Rechenzeit benötigt. Es kann vorkommen, dass der Performance Monitor bei extremer Server-Überlastung selbst keine Performance-Daten ermitteln und anzeigen kann, dann sind die entsprechenden Werte 0 oder leer.

Windows Performance Toolkit

Mit dem Windows Performance Tools (WPT) Kit stellt Microsoft eine offizielle Sammlung von Tools zur freien Verfügung. Sie eignen sich zum Vermessen und Analysieren von System- und Anwendungsverhalten sowie des Ressourcenverbrauchs auf Windows Vista, Windows Server 2008 und späteren Windows Betriebssystemen. Diese Tools beruhen auf dem Event Tracing for Windows (ETW) und verursachen daher nur sehr geringen Overhead. Durch das ETW können Events des Kernels oder der Applikationen, wie z.B. Context Switches, Interrupts, Thread Creation und viele mehr, in Trace-Dateien aufgezeichnet und zu einem späteren Zeitpunkt ausgewertet und als übersichtliche Graphen oder Tabellen dargestellt werden. Sie ermöglichen daher eine sehr detaillierte Analyse eines Windows Systemverhaltens.

Aktuell enthält die Sammlung drei Programme, die von der Kommandozeile aus ausgeführt werden können:

Xperf Event tracing durchführen und auswerten Xperfview Visionalisierung der Performance-Daten Xbootmgr Erstellen eines Traces des Bootvorganges

Die grundsätzliche Vorgehensweise erfolgt in vier Schritten:

1) Starten des Event Tracing durch Aufruf von »xperf«; über Parameter kann genau gesteuert werden, was getraced werden soll.

2) Durchführen der zu analysierenden Szenerie. 3) Stoppen des Event Tracing durch Aufruf von »xperf«; alle zur Analyse notwendigen Daten

werden ins Trace-File geschrieben. 4) Auswerten des Trace-Files mittels »xperf« oder auch Visionalisierung über »xperfview«; kann

auch auf einer anderen Maschine erfolgen.

Beispiel eines Xperfview-Graph für CPU-Sampling:

Page 33: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 33 (46)

Beispiel eines Xperfview-Graph für Disk IO Sampling:

Das Windows Performance Tool Kit ermöglicht eine sehr viel mehr in die Tiefe gehende Analyse eines Systemverhaltens als der Performance Monitor. Dadurch, dass die Aufzeichnung der Events über einen längeren Zeitraum oder auf einem durch viele Prozesse stark belasteten System zu sehr großen Trace Files führt, ist dieses Tool aber eher für die Analyse einer Momentaufnahme geeignet, während z.B. der Performance Monitor zur Analyse eines Systemverhalten über einen längeren Zeitraum, z.B. einen Tag oder eine Nacht eingesetzt werden kann.

Windows Performance Analyzer kann nur eingeschränkt auf Windows XP bzw. Windows Server 2003 eingesetzt werden. Es können zwar auch Event Traces geschrieben werden, allerdings müssen alle Analysen, die Trace-Dekodierung enthalten – das beinhaltet auch die graphische Aufbereitung mittels »Xperfview« – auf einem Windows Vista bzw. Windows Server 2008 System erfolgen.

Page 34: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 34 (46)

Citrix Resource Manager

In größeren Terminal Server Konfigurationen mit Citrix Presentation Server Enterprise Edition kommt vielleicht auch der Resource Manager von Citrix zum Einsatz. Er bietet eine benutzerfreundlichere Sicht auf die für den Citrix Presentation Server relevanten Performance Counter und darüber hinaus noch eine Schwellwertüberwachung mit Be-nachrichtigung des Administrators. Die Schwellwerte sind schon auf bestimmte Werte voreingestellt, können aber bei Bedarf angepasst werden. Da diese Schwellwerte in der Citrix Resource Manager Software fest eingestellt sind, ist es fraglich, ob sie der Vielzahl der heute verfügbaren Leistungsva-rianten von Server-Systemen ohne individu-elle Anpassung gerecht werden können.

Auf einem Citrix Presentation Server 4.0 Terminal Server unter Windows Server 2003 Enterprise Edition 32-bit mit 16 GB Hauptspeicher und Gigabit LAN sind beispielsweise folgende Werte voreingestellt:

Wenn die Schwellwerte jedoch auf den Normalbetrieb (Baseline) eines Citrix Systems angepasst werden, dann lösen Überschreitungen rechtzeitig eine Warnung oder einen Alarm aus und helfen dem Administrator, einen Engpass frühzeitig zu erkennen. Für den Citrix Resource Manager sei auf die Dokumentation von Citrix verwiesen.

Objekt Counter Warnung Fehler

Citrix MetaFrame Presentation Server

Data Store Connection Failure 6 60

Logical Disk % Disk Time 400 600

Logical Disk % Free Space 10 5

Memory Available Bytes 858924851 343569940

Memory Pages/sec 3000 5000

Network Interface Bytes Total/sec 3000000 4000000

Paging File % Usage 40 50

Processor % Interrupt Time 0.3 0.4

Processor % Processor Time 80 90

System Context Switches/sec 120000 14000

Terminal Services Active Sessions 50 100

Terminal Services Inactive Sessions 10 20

Page 35: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 35 (46)

Microsoft Operations Manager (MOM) 2005

Microsoft stellt mit dem Produkt Microsoft Operations Manager (MOM) 2005 eine leistungsfähige Software zur Verfügung, mit der Ereignisse und Systemleistung verschiedener Server-Gruppen im Firmennetzwerk überwacht wer-den können. MOM bietet proaktive Benachrichtigungen im War-nungs- und Fehlerfall und erstellt Berichte und Trendanalysen.

MOM bedient sich dabei existie-renden Windows Mitteln wie der Ereignisanzeige, liest die Perfor-mance Counter aus und über-wacht Dienste, jedoch komfortabel für ganze Gruppen von Servern. Die Ergebnisse werden in einer SQL Datenbank gespeichert.

Zusätzliche Management Packs für MOM werden von Microsoft und anderen Anbietern für ihre Produkte zur Verfügung gestellt und hinterlegen weitere System- oder Anwendungs-spezifische Regelwerke in der MOM-Datenbank. So kann MOM nicht nur Terminal Server, sondern eine Vielzahl von verschiedenen Server-Typen gleichzeitig überwachen.

Für die Terminal Services kann das »Microsoft Terminal Server MOM 2005 Management Pack« hinzugefügt werden, das Terminal Server-spezifische Regeln und Berichte für die folgenden Komponenten mitbringt

Terminal Services

Terminal Services Licensing Server

Session Directory Server

sowie ein Performance Monitoring anbietet.

Beispielsweise wird eine Warnung ausgegeben, wenn mehr als 520 Terminal Server Sessions aktiv sind oder die Prozessorauslastung einer Session über einen Zeitraum von 15 Minuten über 80% liegt. Ein Fehler wird angezeigt, wenn mehr als 20 Terminal Server Sitzungen inaktiv sind oder die Cachetrefferrate weniger als 99% beträgt. Diese vordefinierten Regeln müssen an die kundenspezifischen Gegebenheiten angepasst werden.

Weiterhin können aktive und inaktive Sitzungen über gewisse Zeiträume beobachtet werden, so dass hier-aus Aussagen über das Benutzerverhalten gewonnen werden können.

Eine Beschreibung der Features von MOM würde den Rahmen dieses Dokumentes sprengen. Zu MOM und den einzelnen Management Packs gibt es im Internet detaillierte Beschreibungen von Microsoft.

Page 36: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 36 (46)

Engpassanalyse

Um eine Vorhersage zu treffen, wie sich eine existierende Terminal Server Umgebung verhält oder um bei einer Pilotinstallation die Auslastung eines Terminal Servers beurteilen zu können, ist es notwendig, selbst eine Engpassanalyse durchzuführen oder durch unseren Professional Service durchführen zu lassen.

Performance-Werte aufzuzeichnen oder zu überwachen ist weniger das Problem, als die richtigen Schlüsse aus den Messwerten zu ziehen. Bevor wir im Folgenden einige wichtige Performance Counter zu den verschiedenen Performance-relevanten Server-Objekten diskutieren, werden kurz einige typische Verhaltensweisen von Performance Countern dargestellt. Wenn man einen Engpass auf einem Server-System analysiert, ist es nicht einfach, aus einem Schnappschuss von der Engpasssituation Rückschlüsse zu ziehen. Von Vorteil ist es, wenn man Erfahrungen hat, wie sich das Server-System unter verschiedenen Lasten verhält und eine Baseline zum Vergleich erstellt hat.

Während man einige Messwerte wie den Netzwerkdurchsatz in Relation zum theoretisch erreichbaren Maximalwert, z.B. bei einer 100 MBit-Netzwerkverbindung, setzen kann, ist dies bei anderen Messwerten, wie z.B. Anzahl Context Switches pro Sekunde, nicht möglich.

Es gibt folgende typische Kurvenverläufe bei synthetischer Last:

Linear:

Die Performance-Werte steigen im gleichen Verhältnis zur Last. Kein Engpass.

Logarithmisch:

Bei steigender Last steigen die Performance Counter nicht weiter, sondern erreichen eine Sättigung. Dies kann ein Indiz für einen Engpass sein.

Konstant:

Die Performance Counter sind nicht abhängig von der Last, sondern konstant. Eventuell bilden sich bei unterschiedlicher Last verschiedene Stufen einer Treppenfunktion aus.

Exponentiell:

Im unteren Lastbereich steigt die Kurve relativ flach an, während sie bei steigender Last überproportional wächst. Im Extremfall kann hier bereits ein weiterer Benutzer das »Fass zum Überlaufen« bringen.

Im Folgenden werden einzelne Performance Counter, nach Systemkomponenten gruppiert, beschrieben und diskutiert. Im Anschluss daran ist ein Beispielskript eingefügt, das nach geringen Anpassungen direkt für ein Terminal Server System übernommen werden kann.

Page 37: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 37 (46)

Rechenleistung/System

Die wichtigsten Performance Counter sind:

\Processor(*)\% Processor Time bzw. \Processor(_Total)\% Processor Time

\System\Processor Queue Length

»% Processor Time« ist die insgesamt verbrauchte Rechenzeit. Auf jedem Windows System läuft ein »Leerlaufprozess«, den man mit dem Task-Manager oder Process Explorer auch sehen kann. Alle CPU Zeit, die dieser idle Prozess nicht bekommt, ist »% Processor Time«. Bei »% Processor Time« gibt es mehrere Instanzen, eine pro logische CPU, die Windows kennt. Unsere unten aufgeführte Beispielkonfiguration zeichnet mit dem Objekt »Processor(*)« alle vorhandenen Prozessoren auf und deren Summe. Die Auslastung der einzelnen Prozessoren muss nicht immer gleich hoch sein, gerade im Niedriglastbereich und mit Hyper-Threading ist das oft der Fall. Weiterhin wird beim normalen Arbeiten mit Terminal Server Anwendungen selten eine in Summe 100%ige CPU-Auslastung erreicht. Je mehr logische Prozessoren parallel arbeiten, desto niedriger kann sich der Durchschnittswert der CPU-Auslastung darstellen, auch wenn der Terminal Server bereits überlastet ist.

»Processor Queue Length« bezeichnet die Anzahl Threads, die auf ihre Ausführung warten. Dieser Counter ist nur einmal pro System vorhanden, also nicht CPU-spezifisch. Daher sollte dieser Wert die Anzahl der Prozessoren nicht dauerhaft übersteigen.

Normalerweise steigen »% Processor Time« und »Processor Queue Length« (PQL) bei Belastung des Servers gemeinsam an. Nebenstehende Grafik zeigt einen typischen Verlauf der CPU Zeit und der »Processor Queue Length«, während die Last auf dem Terminal Server zunehmend gesteigert wird. Kritisch sind % CPU-Zeiten ab 80% zusammen mit hohen Peaks der PQL-Kurve, die dann auch dauerhaft auf einem höheren Niveau bleibt.

Es kann jedoch auch Situationen geben, wo eine Vielzahl von kleinen Prozessen auf ihre Ausführung wartet und das System allein schon durch die Verwaltung der Prozesse überlastet wird, obwohl die benötigten CPU-Ressourcen noch verfügbar wären.

Zusätzliche Performance Counter:

\System\Context Switches/sec

\System\System Calls/sec

\System\Processes

\Processor(*)\Interrupts/sec bzw. \Processor(_Total)\Interrupts/sec

»System Calls/sec« zählt die Anzahl Aufrufe an das System pro Sekunde. »Context Switches/sec« zählt die Anzahl Kontextwechsel pro Sekunde, also Wechsel zwischen Threads oder zwischen Benutzerprogrammen und Kernel-Aktivitäten. »Processes« ist die Anzahl der aktuell ausgeführten Prozesse. »Interrupts/sec« ist ein Counter, den es pro Prozessorinstanz und als Durchschnitt aller Prozessoren gibt. Interrupts sind meist durch Hardware wie Netzwerkkarten, Tastatur, Maus, Systemuhr, usw. initiierte Ereignisse, die der Prozessor bearbeiten muss. Zu beachten ist, dass das Windows in der x64 Edition deutlich höhere Werte bei Interrupts/sec anzeigt als das 32-bit Windows. Dieser Unterschied liegt allerdings einzig in der Zählung der Interrupts, da das 64-bit Windows auch die Interrupt-Weiterleitungen zwischen den Prozessoren dokumentiert, die unter dem 32-bit Windows nicht mitgezählt wurden.

Diese Counter steigen normalerweise zusammen mit der benötigten Rechenleistung an. Bedenklich ist es, wenn diese Kurven eine Sättigung erreichen, was bedeutet, dass das System nicht mehr von diesen Ereignissen verarbeiten kann. Eine Sättigung kann am besten über einen längeren Zeitraum beurteilt werden, im Zusammenhang mit den anderen Performance Countern. Die Anzahl Benutzer steigt deutlich steiler als der aufgezeichnete Performance Counter.

Ein CPU-Engpass kann auch durch fehlerhafte Anwendungen ausgelöst werden, siehe Kapitel Applikationen.

Page 38: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 38 (46)

Arbeitsspeicher

Die wichtigsten Performance Counter bzgl. der Arbeitsspeicherauslastung sind:

\Memory\Available MBytes

\Memory\Pages Input/sec

\Process(_Total)\Working Set

»Available MBytes« ist der aktuell freie physikalische Hauptspeicher in MB. »Pages Input/sec« zeigt die Anzahl der Seiteneinlagerungen pro Sekunde. Der »Working Set« einer Anwendung ist der Speicher, den sie bereits verwendet hat.

Nebenstehende Performance-Aufzeichnung wurde auf einem PRIMERGY Server erstellt, der absichtlich in einen Hauptspeicher-engpass getrieben wurde. Eine Eigenschaft des Windows Betriebssystems ist hierbei zu erkennen: wenn genügend Hauptspeicher zur Verfügung steht, wird auch mehr Speicher belegt. Erst wenn der freie Speicher unter einen bestimmten Schwellwert fällt, wird »aufgeräumt« und der Speicher außerhalb des »Working Set« ausgelagert. So kann man an einem System, das nicht im Speichergrenzbereich betrieben wird, den wirklichen Speicherbedarf nicht unbedingt ablesen. In der hier provozierten Engpasssituation werden jedoch exzessive Paging-Aktivitäten sichtbar. Der Speicherengpass deutet sich bereits an, wenn »Available MBytes« unter einen Schwellwert fällt und Windows deshalb den »Working Set« verkleinert. Gleichzeitig steigen die Paging-Aktivitäten (»Pages Input/sec«) an. Wenn nun noch weiterer Speicher gebraucht wird, dann wird schrittweise der »Working Set« weiter verkleinert und die Paging-Vorgänge steigen deutlich an. Auch der Performance Counter »Paging File\%Usage« steigt entsprechend an.

Auch die folgenden Performance Counter können weiteren Aufschluss über die Auslastung des Arbeits-speichers geben:

\Memory\Committed Bytes

\Memory\Pages Output/sec

\Memory\Pages Faults/sec

\Paging File(\??\C:\pagefile.sys)\% Usage

In »Committed Bytes« wird angegeben, wie viel virtueller Hauptspeicher den laufenden Anwendungen zugesagt und im Pagefile reserviert wurde. Hieran kann man ablesen, ob das System in einen Engpass mit dem virtuellen Adressraum gerät.

»Pages Output/sec« zeigt die Anzahl der Seitenauslagerungen pro Sekunde, durch die physikalischer Hauptspeicher freigegeben wird, indem die Daten auf die Festplatte geschrieben werden. Auch wenn ausreichend Arbeitsspeicher vorhanden ist, findet eine moderate Zahl von Auslagerung statt. Erst wenn dieser Wert sprunghaft ansteigt, liegt ein Speicherengpass vor. Insbesondere ist darauf zu achten, dass dieser Wert mit der Leistungsfähigkeit der Festplatte harmoniert, auf der das Pagefile liegt.

»Pages Faults/sec« ist ein Durchschnittswert der Seitenfehler pro Sekunde, beinhaltet aber sowohl Seiteneinlagerungen aus dem physikalischen Hauptspeicher (»soft fault«) als auch Zugriffe auf die Festplatte (»hard fault«).

»Paging File\%Usage« des Pagefiles ist dessen Belegung in Prozent. Eine geringe Belegung des Pagefiles ist normal, auch wenn genügend RAM vorhanden ist. Wenn diese jedoch signifikant ansteigt, könnte ein Hauptspeicherengpass vorliegen. Dies wird durch die anderen Performance Counter der Paging-Aktivitäten untermauert.

Ein Engpass des Arbeitsspeichers geht direkt Hand in Hand mit einem Ansteigen der Disk Counter auf der Festplatte, die das Pagefile beherbergt (siehe Kapitel Engpassanalyse - Disk-Subsystem).

Page 39: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 39 (46)

Betriebssystemressourcen

Der wichtigste Performance Counter, an dem man die Gesundheit des Betriebssystems ablesen kann, ist:

\Cache\Copy Read Hits %

»Copy Read Hits %« ist der prozentuale Anteil der erfolgreichen Lesevorgänge aus dem Systemcache. Werden Daten im Systemcache gefunden, so erübrigt sich ein Festplattenzugriff, was in einem enormen Performance-Gewinn resultiert. Laut Microsoft sollte dieser Anteil immer über 95% liegen. Allerdings kann sich bei diesem Performance Counter bereits eine Verschlechterung von wenigen Prozentpunkten durch eine verzögerte Reaktion des Terminal Servers bemerkbar machen. Im Idealfall liegt »Copy Read Hits %« während des eingeschwungenen Server-Betriebs über 99%. Ein 32-bit-Betriebssystem hat im Vergleich zum 64-bit-Betriebssystem durch den limitierten Kernel-Adressraum auch einen kleineren Systemcache.

Da speziell Engpässe des Betriebssystems im Terminal Server Umfeld untersucht werden, sollten folgende zusätzliche Performance Counter auf jeden Fall mit betrachtet werden:

\Memory\Free System Page Table Entries

\Memory\Pool Nonpaged Bytes

\Memory\Pool Paged Bytes

»Free System Page Table Entries« zeigt die Anzahl der freien Einträge in der System Page Table. Ein Engpass dieser Betriebssystemressource ist erreicht, wenn nur noch wenige 1000 Einträge frei sind. »Pool Nonpaged Bytes« ist die Anzahl Bytes, die aktuell für den Nonpaged Pool verwendet werden. Im Nonpaged Pool speichert das Betriebssystem alle Daten, die immer im Hauptspeicher gehalten werden müssen und nicht in das Pagefile geschrieben werden dürfen. »Pool Paged Bytes« ist die Anzahl Bytes, die aktuell für den Paged Pool verwendet werden. Im Paged Pool liegen die Systemspeicherbereiche, die in das Pagefile ausgelagert werden können. Auf Windows Server 2003 32-bit-Betriebssystemen sind diese Speicherbereiche limitiert und nicht erweiterbar, so dass diese an ihre Grenzen stoßen können, wenn viele Benutzer auf dem Terminal Server arbeiten. Ein größerer Speicherausbau führt nicht zu größeren Kernel-Strukturen, sondern es wird im Gegenteil noch mehr Kernel-Speicher durch die Verwaltung und die Adressierung dieser Datenbereiche belegt.

Nebenstehende Grafik zeigt eine solche Situation, bei der bei einem Terminal Server ein Engpass der Betriebssystem-ressourcen durch kontinuierliche Erhöhung der Benutzerlast provoziert wurde. Zur Verdeutlichung wird zusätzlich der Performance Counter »Working Set« dargestellt. Man erkennt vier Phasen bei der Server-Belastung. In der ersten Phase ist der Terminal Server performant, die Trefferrate im Systemcache liegt fast bei 100% , es sind noch genug freie PTEs vorhanden und der Working Set sowie der Paged Pool und der Nonpaged Pool kann mit der Anzahl Benutzer gesteigert werden. In der zweiten Phase fällt die Trefferrate des Systemcaches ab. Der Paged Pool erfährt eine Sättigung. Die Performance wird sich langsam verschlechtern. In der dritten Phase ist die Effizienz des Systemcaches deutlich herabgesetzt. während durch Paging-Aktivitäten noch Paged Pool Ressourcen freigeschaufelt werden konnten. Die Terminal Server Performance wird durch fehlende Kapazitäten im Systemcache gemeinsam mit erhöhten Plattenaktivitäten jedoch nicht mehr befriedigend sein. Überlastet man das System über diese Phase hinaus, dann erkennt man die Sättigung des Paged Pools. Auch der »Working Set« kann nicht mehr gesteigert werden und die freien PTEs sind auf einem Minimalwert angekommen. Neben einer schlechten Terminal Server Performance wird sich ein Teil der Benutzer auch nicht mehr anmelden können, oder Anwendungen können nicht mehr gestartet oder bedient werden. Das System hat, im Gegensatz zu dem im Abschnitt Arbeitsspeicher gezeigten Fall eines Hauptspeicherengpasses, jedoch noch genügend freien physikalischen Speicher. In diesem Fall hatte das System am Ende der Aufzeichnung noch 26 GB von 32 GB physikalischem Hauptspeicher frei.

Page 40: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 40 (46)

Disk-Subsystem

Der wichtigste Performance Counter zur Beurteilung der Festplattenauslastung ist:

\PhysicalDisk(*)\Avg. Disk Queue Length

bzw.

\LogicalDisk(*)\Avg. Disk Queue Length

Hierbei zeichnen die Performance Counter für die »PhysicalDisk« alle Aktivitäten an einem physikalischen Laufwerk auf, während das »LogicalDisk« Objekt diese nach den einzelnen Partitionen, z.B. C: oder D:, unterteilt. Wird ein RAID-Controller, SAN oder iSCSI verwendet, so bezieht sich der Counter »PhysicalDisk« jedoch nicht, wie der Name suggeriert, auf die physikalische Platte, sondern auf den RAID-Verband bzw. die LUN.

Der Counter »Avg. Disk Queue Length« ist der Durchschnitt der Festplattenwarteschlange für Lese- und Schreibaufträge, man kann aber auch für Lese- und Schreiboperationen getrennte Counter aktivieren. Dieser Performance Counter ist ein signifikanter Indikator für die Belastung des Disk-Subsystems und sollte nicht dauerhaft größer sein als 1 pro Festplatte, die netto zur Verfügung steht. In einem RAID 1 Verband aus zwei Festplatten also nicht dauerhaft größer als 1, in einem RAID 1+0 aus 6 Festplatten nicht dauerhaft größer als 3. Die Beispielgrafik zeigt die »Avg. Disk Queue Length« für eine Konfiguration mit einer Festplatte, bei der der Wert unter 1 liegen sollte. Während im ersten Zeitraum dieser Aufzeichnung die Festplatte nicht wesentlich belastet wird, so ist gegen Ende der Messung das Disk-Subsystem deutlich überlastet.

Die Performance des Disk-Subsystems, auf dem das Pagefile liegt, sollte immer gemeinsam mit dem Arbeitsspeicher betrachtet werden. Wenn der Arbeitsspeicher knapp wird, lagert Windows Teile des Speichers in das Pagefile auf der Festplatte aus und liest diese später wieder ein, was zu deutlich erhöhten Plattenaktivitäten auf der Festplatte führt, auf der das Pagefile liegt.

Zusätzliche Performance Counter des \PhysicalDisk(*) bzw. \LogicalDisk(*) Objektes, die weiteren Aufschluss über die Plattenaktivität geben können:

Avg. Disk Bytes/Read Durchschnitt der Auftragsgröße beim Lesen

Avg. Disk Bytes/Write Durchschnitt der Auftragsgröße beim Schreiben

Avg. Disk sec/Read Durchschnittswert der pro Leseauftrag benötigte Zeit in Sekunden

Avg. Disk sec/Write Durchschnittswert der pro Schreibauftrag benötigte Zeit in Sekunden

Disk Read Bytes/sec Gesamtanzahl der gelesenen Bytes pro Sekunde

Disk Reads/sec Gesamtanzahl der Lesevorgänge pro Sekunde

Disk Write Bytes/sec Gesamtanzahl der geschriebenen Bytes pro Sekunde

Disk Writes/sec Gesamtanzahl der Schreibvorgänge pro Sekunde

Der vielfach verwendete Counter »% Disk Time« ist nicht zu empfehlen, da er in heutigen Windows Versionen genau dem Hundertfachen von »Avg. Disk Queue Length« entspricht.

Page 41: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 41 (46)

Aus diesen Performance Countern lässt sich das Zugriffsmuster auf die Festplatten ablesen, d.h. die gelesenen und geschriebenen Blockgrößen, und die Latenzzeiten (»Avg. Disk sec«) beim Lesen und Schreiben. Diese Messwerte sollten in dem Fall als Zusatzinformation ausgewertet werden, wenn die »Avg. Disk Queue Length« auf einen Festplattenengpass hindeutet. Mit der Anzahl von Schreib- und Leseaufträgen pro Sekunde können in Verbindung mit der im Durchschnitt genutzten Auftragsgröße und dem verwendeten RAID-Level ebenfalls Rückschlüsse auf die Auslastung des Disk-Subsystems getroffen werden. Zum Sizing von Disk-Subsystemen wurde ein eigenes White Paper »Performance Report – Modular RAID für PRIMERGY« [L5] erstellt.

Zu beachten ist auch, dass ein Disk-Subsystem, das über iSCSI angeschlossen ist, zusätzlich zu den Performance Countern der Festplattenobjekte bei den Performance Countern der Netzwerkkarte auftaucht, die im Folgenden beschrieben werden.

Netzwerk

Für einen ersten Blick auf die Netzwerkauslastung reicht der Task-Manager aus. Auf der Seite »Netzwerk« (»Networking«) erhält man schnell einen Überblick über die »Netzwerkauslastung« (»Network Utilization«) der einzelnen Netzwerkkarten und deren »Übertragungsrate« (»Link Speed«).

Bei einer Performance Monitor-Aufzeichnung sollten die folgenden Performance Counter mit berücksichtigt werden:

\Network Interface(*)\Bytes Sent/sec

\Network Interface(*)\Bytes Received/sec

»Bytes Sent/sec« und »Bytes Received/sec« zählen die aus Sicht des Servers gesendeten und empfangenen Daten in Bytes.

Zusätzlich ist es auch sinnvoll die Performance Counter

\Network Interface(*)\Packets Received/sec

\Network Interface(*)\Packets Sent/sec

zu betrachten. »Packets Sent/sec« und »Packets Received/sec« sind die Anzahl der aus Sicht des Servers gesendeten und empfangenen Datenpakete. Aus dem Verhältnis der Datenbytes und der Anzahl der Pakete lässt sich die durchschnittliche Paketgröße ermitteln.

Je größer die Netzwerkpakete, desto höher die mögliche Netzwerkauslastung.

Die Protokolle RDP oder ICA, die ein Terminal Server zwischen Client und Server verwendet, beinhalten nicht sehr große Datenpakete. Eine 100% Auslastung eines 100 MBit-Netzwerkes wird sich daher kaum beobachten lassen. Das ICA-Protokoll des Citrix Presentation Server ist dabei noch etwas sparsamer als das RDP-Protokoll des Microsoft Terminal Services.

Neben der Client-Server-Kommunikation entsteht in den meisten Anwendungsszenarien jedoch auch weiterer Netzwerkverkehr zu Back-End-Server, ins Internet, oder bei Verwendung eines Netzwerk-basierten Disk-Subsystem, wie NAS oder iSCSI Datentransfer zum Disk-Subsystem. Es ist dringend zu empfehlen, dass für diese unterschiedlichen Datenströme dedizierte Netzwerkinterfaces verwendet werden.

Die verschiedenen Netzwerkinterfaces können anstelle des (*) im Performance Monitor auch einzeln mit ihrem Namen selektiert werden. Wenn (*), wie im Beispiel oben, als Netzwerkkartenbezeichnung angegeben wird, dann werden alle im System verfügbaren Netzwerkkarten aufgezeichnet. Hierzu gehört auch das Loopback-Interface, auf dem normalerweise nicht viel Netzwerkverkehr stattfindet.

Zu beachten ist, dass sich mit dem Performance Monitor oder dem Task-Manager nur die Auslastung des Netzwerkes aus Sicht des Terminal Servers analysieren lässt. Datenverkehr anderer Server und Clients auf dem Netzwerk kann nicht erfasst werden. Oft ist jedoch nicht das Server-seitige Netzwerk selbst zu klein dimensioniert, sondern die Probleme können beispielsweise von fehlerhaften oder falsch konfigurierten Komponenten herrühren oder durch vielfältige Problemen bei der Verbindung dieser Komponenten entstehen. An dieser Stelle sollte man einen Netzwerkspezialisten hinzuziehen.

Page 42: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 42 (46)

Terminal Server

Der Microsoft Terminal Server selbst liefert nicht viele Performance Counter. Jedoch bietet der Terminal Server unter dem Objekt »Terminal Services Sessions« Performance Counter pro Session für eine detaillierter Auswertung einzelner Sitzungen an.

Die Anzahl Terminal Server Verbindungen sollte immer mitgeschrieben werden, um die anderen Performance Counter in Relation zur Anzahl verbundenen Benutzer setzen zu können:

\Terminal Services\Active Sessions

Es ist ein Unterschied, ob der Benutzer die Verbindung zum Terminal Server beendet, indem er sich abmeldet (»Logoff«) oder ob er mit einem »Disconnect« die Verbindung nur unterbricht. Im letzteren Fall läuft die Anwendung auf dem Terminal Server weiter und gibt ihre Ressourcen nicht frei. Der Benutzer kann seine Arbeit dann an dieser Stelle fortsetzen. Manche Anwendungen brauchen auch CPU-Ressourcen, während die Verbindung getrennt ist. Daher sollte die Anzahl der inaktiven Verbindungen (»Inactive Sessions«)

\Terminal Services\Inactive Sessions

ebenfalls mitprotokolliert werden.

Diese beiden Parameter gelten gleichwohl für die Microsoft Terminal Services als auch für den Citrix Presentation Server.

Citrix selbst liefert auch Performance-Objekte mit verschiedenen Performance Countern mit. Folgende Performance Objekte werden installiert:

»Citrix CPU Utilization Mgmt User« Counter für das Feature »CPU Utilization Management«

»Citrix IMA Networking« Counter für Anzahl Verbindungen und Netzwerklast

»Citrix MetaFrame Presentation Server« Counter u.a. für Data Store, Local Host Cache, Licensing

»ICA Session« (für einzelne Sessions oder gesamt »_Server Total«) Counter spezifisch für ICA-Session

Diese sind jedoch eher für spezielle Auswertungen geeignet und weniger für eine allgemeine Performance-Analyse eines Terminal Servers.

Page 43: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 43 (46)

Applikationen

Eine fehlerhafte Anwendung kann eine CPU zeitweise oder permanent voll belasten, und gerade auf einem Terminal Server kann das fatale Auswirkungen auf die Gesamtleistung des Systems haben, da diese Anwendung auch mehrfach gestartet sein kann. Wenn die Anwendung einen Thread besitzt, der z.B. in einer Endlosschleife läuft oder »aktiv wartet«, dann belegt dieser maximal »100% / #CPUs« Prozessorzeit. Auf einem System mit zwei logischen Prozessoren also 50%, auf einem System mit vier logischen CPUs 25%. Je mehr logische CPUs das System hat, desto weniger fällt so ein Programm auf. Bei CPU-Engpässen sollte immer überprüft werden, ob es solche Anwendungen gibt, die dauerhaft genau diese Prozentzahl an CPU-Leistung benötigen. Kurzfristige Lastspitzen einer Anwendung sind hingegen völlig normal. Einen ersten Blick auf die Anwendungen ermöglicht der Task-Manager bzw. der Process Explorer. Folgender Screenshot zeigt einen synthetischen Lastsimulator auf einem PRIMERGY System mit acht logischen Prozessoren, der eine Endlosschleife simuliert. Der Process Explorer weist 12.50% CPU Last aus, d.h. diese eine Anwendung lastet einen Prozessorkern vollständig aus.

Ein solches Verhalten ist oft in Desktop-Anwendungen zu finden, die für einen einzelnen Benutzer geschrie-ben und daher für eine Terminal Server Umgebung nur bedingt geeignet sind. Wenn Citrix Presentation Server 4.0 eingesetzt wird, dann kann man solche Anwendungen auch in ihrer Rechenleistung beschränken. Diese Einschränkung greift nur, wenn insgesamt zu wenig CPU Ressourcen zur Verfügung stehen.

Auch der Speicherbedarf einer Applikation sollte überprüft werden. Unser synthetischer Lastsimulator hat ca. 1.5 GB virtuellen Speicher belegt, allerdings ist der »Working Set« nur 5.3 MB groß. Diese Anwendung hat zwar eine Menge Speicher reserviert, hat ihn jedoch nicht in Verwendung. Erst wenn die Anwendung auf dem Speicher arbeitet, vergrößert sich der »Working Set« und der im System verfügbare Speicher »Available Mbytes« nimmt ab.

Mit dem Performance Monitor kann man viele Performance Counter statt für das Gesamtsystem auch für einzelne laufende Anwendungen anzeigen lassen. Hierzu verwendet man das Objekt »Process« und als Instanz dann den zu überwachenden Prozess.

Page 44: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 44 (46)

Performance Monitor-Konfigurationsskript

An dieser Stelle möchten wir eine Beispielkonfiguration mit den aussagekräftigsten Performance Countern aufführen, die bei Bedarf erweitert werden kann. Normalerweise stellt man die Auswahl der Performance Counter mit dem Performance Montitor Programm zusammen und speichert diese dann als »Protokolle der Ablaufverfolgung (Counter Log)« als *.htm Datei ab. Diese HTML-Datei kann man auch wieder in einer anderen Umgebung einlesen, jedoch sind einige Parameter ggf. systemspezifisch einzustellen, und die Performance Counter sind neu zu nummerieren, wenn Performance Counter hinzugefügt oder entfernt werden.

Beim remote Monitoring ist der Name des Servers im Format »\\<server>« vor den Performance Counter zu stellen, z.B. für den Server »server«: »\\server\Terminal Services\Active Sessions«. Neben einem einzelnen Server können beim remote Monitoring auch mehrere Server gleichzeitig überwacht werden.

Alternativ kann man die Kon-figuration der Performance Counter auch in eine Text-datei schreiben und mit dem »logman« Kommando laden. Hierzu siehe die Hilfe des »logman« Kommandos mit »logman -?«.

Ein fertiges Konfigurations-skript ist nebenstehend ab-gebildet. Es kann als HTML-Datei, z.B. mit dem Namen »perf.htm«, am besten mit einem Text-Editor wie Note-pad, angelegt werden und dann im Performance Monitor mit »Neue Protokoll-einstellungen von... (New Log Settings From ...)« im-portiert werden. Besonders wichtige Parameter sind farb-lich unterlegt, während der fett gedruckte Laufwerks-buchstabe ggf. an den Speicherort des Pagefiles angepasst werden muss.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"><HTML> <HEAD> <META NAME="GENERATOR" Content="Microsoft System Monitor"> </HEAD> <BODY> <OBJECT ID="DISystemMonitor1" WIDTH="100%" HEIGHT="100%" CLASSID="CLSID:C4D2D8E0-D1DD-11CE-940F-008029004347"> <PARAM NAME="_Version" VALUE="196611"> <PARAM NAME="LogName" VALUE="perf"> <PARAM NAME="Comment" VALUE=""> <PARAM NAME="LogType" VALUE="0"> <PARAM NAME="CurrentState" VALUE="0"> <PARAM NAME="RealTimeDataSource" VALUE="1"> <PARAM NAME="LogFileMaxSize" VALUE="-1"> <PARAM NAME="DataStoreAttributes" VALUE="1"> <PARAM NAME="LogFileBaseName" VALUE="perf"> <PARAM NAME="LogFileSerialNumber" VALUE="1"> <PARAM NAME="LogFileFolder" VALUE="C:\Perflogs"> <PARAM NAME="Sql Log Base Name" VALUE="SQL:!perf"> <PARAM NAME="LogFileAutoFormat" VALUE="-1"> <PARAM NAME="LogFileType" VALUE="2"> <PARAM NAME="StartMode" VALUE="0"> <PARAM NAME="StopMode" VALUE="0"> <PARAM NAME="RestartMode" VALUE="0"> <PARAM NAME="LogFileName" VALUE="C:\Perflogs\perf.blg"> <PARAM NAME="EOFCommandFile" VALUE=""> <PARAM NAME="Counter00001.Path" VALUE="\Terminal Services\Active Sessions"> <PARAM NAME="Counter00002.Path" VALUE="\Terminal Services\Inactive Sessions"> <PARAM NAME="Counter00003.Path" VALUE="\Processor(_Total)\% Processor Time"> <PARAM NAME="Counter00004.Path" VALUE="\Processor(_Total)\Interrupts/sec"> <PARAM NAME="Counter00005.Path" VALUE="\System\Processor Queue Length"> <PARAM NAME="Counter00006.Path" VALUE="\System\Context Switches/sec"> <PARAM NAME="Counter00007.Path" VALUE="\System\Processes"> <PARAM NAME="Counter00008.Path" VALUE="\System\System Calls/sec"> <PARAM NAME="Counter00009.Path" VALUE="\Memory\Available MBytes"> <PARAM NAME="Counter00010.Path" VALUE="\Memory\Free System Page Table Entries"> <PARAM NAME="Counter00011.Path" VALUE="\Memory\Pool Nonpaged Bytes"> <PARAM NAME="Counter00012.Path" VALUE="\Memory\Pool Paged Bytes"> <PARAM NAME="Counter00013.Path" VALUE="\Memory\Page Faults/sec"> <PARAM NAME="Counter00014.Path" VALUE="\Memory\Pages Input/sec"> <PARAM NAME="Counter00015.Path" VALUE="\Memory\Pages Output/sec"> <PARAM NAME="Counter00016.Path" VALUE="\Memory\Committed Bytes"> <PARAM NAME="Counter00017.Path" VALUE="\Process(_Total)\Working Set"> <PARAM NAME="Counter00018.Path" VALUE="\Paging File(\??\C:\pagefile.sys)\% Usage"> <PARAM NAME="Counter00019.Path" VALUE="\Cache\Copy Read Hits %"> <PARAM NAME="Counter00020.Path" VALUE="\LogicalDisk(*)\Avg. Disk Queue Length"> <PARAM NAME="Counter00021.Path" VALUE="\LogicalDisk(*)\Avg. Disk Bytes/Read"> <PARAM NAME="Counter00022.Path" VALUE="\LogicalDisk(*)\Avg. Disk Bytes/Write"> <PARAM NAME="Counter00023.Path" VALUE="\LogicalDisk(*)\Avg. Disk sec/Read"> <PARAM NAME="Counter00024.Path" VALUE="\LogicalDisk(*)\Avg. Disk sec/Write"> <PARAM NAME="Counter00025.Path" VALUE="\LogicalDisk(*)\Disk Read Bytes/sec"> <PARAM NAME="Counter00026.Path" VALUE="\LogicalDisk(*)\Disk Reads/sec"> <PARAM NAME="Counter00027.Path" VALUE="\LogicalDisk(*)\Disk Write Bytes/sec"> <PARAM NAME="Counter00028.Path" VALUE="\LogicalDisk(*)\Disk Writes/sec"> <PARAM NAME="Counter00029.Path" VALUE="\Network Interface(*)\Bytes Received/sec"> <PARAM NAME="Counter00030.Path" VALUE="\Network Interface(*)\Bytes Sent/sec"> <PARAM NAME="Counter00031.Path" VALUE="\Network Interface(*)\Packets Received/sec"> <PARAM NAME="Counter00032.Path" VALUE="\Network Interface(*)\Packets Sent/sec"> <PARAM NAME="CounterCount" VALUE="32"> <PARAM NAME="UpdateInterval" VALUE="15"> <PARAM NAME="SampleIntervalUnitType" VALUE="1"> <PARAM NAME="SampleIntervalValue" VALUE="15"> </OBJECT> </BODY> </HTML>

Page 45: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

© Fujitsu Technology Solutions 2009 Seite 45 (46)

Messwerkzeuge

Da es für Terminal Server keinen Standard-Benchmark gibt, existiert eine Reihe von verschiedenen proprietären Messwerkzeugen und -methoden zur Skalierung von Terminal Servern. Neben Fujitsu Technology Solutions benutzen auch Microsoft und Citrix eigene Software und auch der bekannte Microsoft-Press-Autor und Terminal Server Experte Dr. Bernhard Tritsch hat Untersuchungen mit eigenem Lastsimulator durchgeführt. Die 2002 gegründete Firma LoginConsultants stellt auf ihren Internet-Seiten ein kostenloses Tool zum Messen von Server-based Computing Sessions zur Verfügung.

Die nachfolgende Tabelle charakterisiert die verschiedenen Werkzeuge.

Microsoft

Terminal Server Scalability Planning Tool

Eine Lastsimulator-Suite von Microsoft (http://www.microsoft.com), die Bestandteil des Windows Server 2003 Resource Kit ist.

Arbeitet nur mit Microsoft Terminal Services (RDP-Protokoll)

bis zu 20 Benutzer pro Lastgenerator

Knowledge Worker arbeitet mit einem Remote Desktop und verschiedenen Anwendungen (Microsoft Excel, Outlook, Internet Explorer, Word)

Eingaben per Tastatur, 35 Wörter pro Minute

Aufzeichnung von Performance Countern mit dem Windows Performance Monitor

Citrix

CSTK / Citrix ICAMark 3.0

CSTK ist ein Lastsimulator von Citrix (http://www.citrix.com/cdn).

Citrix ICAMark 3.0 ist ein Citrix-internes Tool, das auf dem CSTK basiert.

Nur für Citrix Presentation Server / XenApp (ICA-Protokoll).

Produziert Last, aber ermittelt keine Antwortzeiten von einzelnen Aktionen, nur die Gesamtlaufzeit für ein komplettes Skript ist messbar.

Light User: Microsoft Excel, ca. 20 Wörter pro Minute Heavy User: Microsoft Excel, Microsoft Access, Microsoft PowerPoint (sequentiell) ca. 40 Wörter pro Minute

Aufzeichnung von Performance Countern mit dem Windows Performance Monitor

Fujitsu Technology Solutions

T4US

Eigenentwicklung von Fujitsu Technology Solutions

Sowohl für Microsoft Terminal Services als auch für Citrix Presentation Server

Bis zu 40 Benutzer pro Lastgenerator

Überwachung der Antwortzeiten für alle Benutzer bei verschiedenen Aktionen, Vergleich mit Referenzmessung

Medium Lastprofil: Login + Desktop + Office-Anwendungen + Logoff Eingabe per Tastatur und Maus; Lesen und Schreiben von Daten

Aufzeichnung von Performance Countern mit dem Windows Performance Monitor

visionapp

Remote Desktop + vRD Load Edition

Eigenentwicklung von visionapp (http://www.visionapp.com/de)

Messungen mit Microsoft Terminal Services (RDP-Protokoll)

Bis zu 40 Benutzer pro Lastgenerator

Desktop + Applikationen: Notepad: Textdatei, 8.4 KB Microsoft Word: Word Dokument, 3.1 MB Acrobat Reader 7: PDF-Datei, 3.8 MB

Abgesehen von der Benutzeranmeldung finden während des Tests keine Eingaben statt, es werden keine Daten durch die Anwendungen angelegt

Messung der Logon-Zeiten sowie der Anzahl der gestarteten Verbindungen und Applikationen

Aufzeichnung von Performance Countern mit dem Windows Performance Monitor

Login

Consultants

Login Virtual Session Indexer (VSI)

Eigenentwicklung von LoginConsultants (http://www.loginconsultants.com)

VSI: kostenlose Version mit einem (Medium) Lastprofil, nicht anpassbar

VSIpro: Lizenzpflichtige customize-fähige Version, verschiedene Lastprofile

Messungen erfolgen auf dem SUT, daher Protokoll-unabhängig

Medium Lastprofil: Login, Outlook, Internet Explorer, Word, Excel, PowerPoint, PDFWriter Aktionen

Kontinuierliches Starten von Benutzer-Sessions und Messen von Reaktionszeiten

Ergebnis VSI: die maximale Anzahl Virtual Sessions anhand der Reaktionszeiten

Page 46: Ausgabe Terminal Server Sizing Guide - sp.ts. · PDF fileOktober 2009 Abstract Terminal Server als eine Form des Server-based Computing hat sich in weiten Bereichen der IT Infrastruktur

White Paper Sizing Guide | Terminal Server Sizing Guide Version: 4.0, Oktober 2009

Lieferung vorbehaltlich Verfügbarkeit, technische Änderungen ohne Vorankündigung möglich, Korrektur von Irrtümern und Auslassungen vorbehalten. Alle angegebenen Konditionen (TCs) sind empfohlene Einstandspreise in Euro ohne MwSt. (sofern im Text nicht anderweitig angegeben). Sämtliche verwendete Hardware- und Software- Namen sind Handelsnamen und/oder Warenzeichen ihrer jeweiligen Hersteller. Copyright © Fujitsu Technology Solutions GmbH 2009

Herausgegeben durch: Enterprise Products PRIMERGY Server PRIMERGY Performance Lab mailto:[email protected]

Internet:

http://ts.fujitsu.com/primergy

Extranet:

http://partners.ts.fujitsu.com/com/products/servers/primergy

Literatur

[L1] Allgemeine Informationen zu Produkten von Fujitsu Technology Solutions

http://de.ts.fujitsu.com

[L2] Allgemeine Informationen zur PRIMERGY Produktfamilie

http://www.primergy.de

[L3] PRIMERGY Benchmarks - Performance Reports und Sizing Guides

http://de.ts.fujitsu.com/products/standard_servers/primergy_bov.html

[L4] Speicher-Performance Xeon 5500 (Nehalem EP) basierter PRIMERGY Server

http://docs.ts.fujitsu.com/dl.aspx?id=3ba9fc71-4b0d-493f-b842-02a1d3645be0

[L5] Performance Report - Modular RAID für PRIMERGY

http://docs.ts.fujitsu.com/dl.aspx?id=2d0d20d8-7c14-407c-b904-6112f4c7821c

[L6] Microsoft Windows 2003 und Terminal Server

http://www.microsoft.com/terminalserver

[L7] Windows Server 2003 Terminal Server Capacity and Scaling

http://www.microsoft.com/windowsserver2003/techinfo/overview/tsscaling.mspx

[L8] Remote Desktop Services Windows Server 2008 R2

http://www.microsoft.com/windowsserver2008/en/us/rds-product-home.aspx

[L9] Citrix

http://www.citrix.de

[L10] Sysinternals Tools

www.sysinternals.com

[L11] Microsoft Windows Performance Toolkit

http://msdn.microsoft.com/en-us/performance/cc752957.aspx

Kontakt

PRIMERGY Hardware

PRIMERGY Product Marketing

mailto:[email protected]

PRIMERGY Performance und Benchmarks

PRIMERGY Performance und Benchmarks

mailto:[email protected]