Terminal Server Sizing Guide

Transcription

Ausgabe 4.0
Oktober 2009
Terminal Server Sizing Guide
Seiten 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
White Paper
Sizing Guide | Terminal Server Sizing Guide
Version: 4.0, Oktober 2009
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.
Terminal
Server
Data
Store
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).
© Fujitsu Technology Solutions 2009
Seite 2 (46)
White Paper
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 ServerUmgebungen. 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 ServerFarmen, 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.
Seite 3 (46)
White Paper
Dimensionierung
Methoden
Bei der Skalierung – das ist der Prozess, das System an die benötigte Leistung anzupassen – werden zwei
Methoden unterschieden:
Scale-Up
bezeichnet den Einsatz
zunehmend größerer
Server Systeme.
Scale-Out
bezeichnet den Einsatz von
vielen kleineren Systemen,
die sich die Arbeit teilen.
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.
Terminal
Server
Session
List
Load Balancer
Im Folgenden beschäftigen wir uns mit einem Scale-Up Scenario, d.h. der Dimensionierung eines einzelnen
Terminal Servers.
Seite 4 (46)
White Paper
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
Medium
Process Worker
Light
Data Entry Worker
nutzt gleichzeitig mehrere verschiedene Anwendungen
gibt Daten mäßig schnell ein
führt komplexere Operationen aus
arbeitet zu einer Zeit intensiv mit einer Anwendung
gibt schnell viele Daten ein
arbeitet kontinuierlich
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.
SimulationsNetzwerk
…
SUTNetzwerk
Controller
Lastgeneratoren
System
under Test
(SUT)
InfrastrukturServer
Seite 5 (46)
White Paper
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.
Seite 6 (46)
White Paper
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 Aufzeichnungswerkzeugs T4US-Record in Echtzeit aufgezeichnet und in einem T4US-Skript gespeichert
werden. T4US-Skripte werden während der Messung
als Lastprofil verwendet.
Benutzer bei
der Arbeit
T4US
Record
T4US
Skript
Der Lastsimulator von T4US besteht aus drei Komponenten.
T4US-Control steuert und
überwacht den gesamten
System under Test (SUT)
Simulationslauf zentral und
Controller
Lastgenerator
SUT
ermittelt Messwerte bereits
T4US
während der Messung. Auf
Play
jedem der Lastgeneratoren
TS Client
laufen mehrere Instanzen
des T4US-Playback. JeT4US
des T4US-Playback »fütPlay
tert« einen Terminal Server
TS Client
…
Client in Echtzeit mit Tastatur- und Mauseingaben
T4US
T4US
anhand der mit T4USPlay
T4US
Terminal
Agent
Record
aufgezeichneten
Control
Server
TS Client
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 Lastgeneratoren 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 vorgegebenen 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.
Seite 7 (46)
White Paper
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.
Seite 8 (46)
White Paper
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.
Seite 9 (46)
White Paper
Messumgebung
Untersucht wurden alle aktuellen PRIMERGY Modelle, die für den Einsatz als typischer Terminal Server
geeignet sind, in der folgenden Messumgebung:
Controller
für die
Simulation
Simulationsnetzwerk
switched
100 Mbit
PRIMERGY C200
T4US-Control
System
under test
(SUT)
Lastgeneratoren
ca. 40 PRIMERGY Dual Server
Windows Server 2003
TS-Client
T4US-Agent, T4US-Playback
Jeder simuliert bis zu 12 Benutzer
InfrastrukturServer
SUTNetzwerk
switched
100 Mbit
PRIMERGY
Windows Server 2003
Windows Server 2008
Enterprise Edition
PRIMERGY C200
Windows Server 2003
Active Directory
Terminal Server
Licensing Service
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.
Seite 10 (46)
White Paper
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.
Seite 11 (46)
White Paper
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 32bit- 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 PerformanceEinbuß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 x64Betriebssystem 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-bitInstaller.
Nachfolgende Tabelle gibt einen Überblick über relevante Systemplattformen und Windows Produkte und
deren Anforderungen an Gerätetreiber und Anwendungen.
Server-Plattform
Windows Produkt
Betriebssystem
Gerätetreiber
Anwendungen
x86
Windows Server 2003 R2 /
Windows Server 2008
Standard Edition
Enterprise Edition
Datacenter Edition
32-bit
32-bit
32-bit
x64
Windows Server 2008
Standard Edition
Enterprise Edition
Datacenter Edition
32-bit
32-bit
32-bit
x64
Windows Server 2008
Standard x64 Edition
Enterprise x64 Edition
Datacenter x64 Edition
64-bit
64-bit
32-bit und 64-bit
Seite 12 (46)
White Paper
Limitierungen
Der wesentliche Unterschied zwischen 32-bit- und 64-bit-Architektur liegt in der Größe des adressierbaren
32
Speichers. Mit einer 32-bit-Architektur sind durch die Wortbreite des Prozessors maximal 2 Byte =4 GByte
64
adressierbar, mit einer 64-bit-Architektur sind es bis zu 2 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.
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
Virtueller Adressraum
eines 32-bit-Prozesses
4 GB
16 TB
2 GB
2 GB
3 GB wenn mit
/3GB Switch gebootet
4 GB wenn mit
/LARGEADDRESSAWARE
übersetzt wurde
-
8 TB
Virtueller Adressraum
eines 64-bit-Prozesses
Paged Pool
470 MB
/ WS 2008 dynamisch
128 GB
Non-Paged Pool
256 MB
/ WS 2008 dynamisch
128 GB
ca. 900 MB
/ WS 2008 dynamisch
128 GB
1 GB
/ WS 2008 dynamisch
1 TB
System Page Table
Entries
System Cache
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
36
Pentium und AMD Athlon) die es ermöglicht bis zu 2 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-bitBetriebssystem, bei dem es maximal 3 GB sind.
Seite 13 (46)
White Paper
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-bitSystem 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-bitBetriebssystem 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
(Light Lastprofil, Microsoft Office 2003,
führt. Hierdurch steigen ebenfalls die Plattenzugriffe
Microsoft Terminal Services)
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 PagingAktivitä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-bitVersionen, 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 begrenzten Kernel-Ressourcen dazu, dass nicht mehr
Benutzer unterstützt werden können.
Engpass der
Kernel-Ressourcen
Zu wenig Speicher
Demgegenüber werden bei dem 64-bitBetriebssystem durch steigenden Hauptspeicherausbau 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
(Light Lastprofil, Microsoft Office 2003,
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.
Seite 14 (46)
White Paper
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).
Seite 15 (46)
White Paper
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-CPUMessungen 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,
Seite 16 (46)
White Paper
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 PerformanceVerbesserung durch Steigerung der Front-SideBus-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 CPUReserve können mehr Benutzer mit dem
Terminal Server arbeiten, bevor die Antwortzeiten 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.
Seite 17 (46)
White Paper
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 Bedingungen 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 BenchmarkErgebnis.
(Lastprofil V1, Microsoft Office XP, Citrix MetaFrame)
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.
(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)
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 64bit-System profitiert am meisten
von dem doppelt so großen
Cache mit einem PerformanceGewinn von 25%. Das 32-bitSystem 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.
Seite 18 (46)
White Paper
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-Threadingfä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 PerformanceGewinn 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 HyperThreading für eine Entlastung des Systems, die CPULast 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.
(Lastprofil V1, Microsoft Office XP,
Citrix MetaFrame)
In einer weiteren Messreihe
wurden die absoluten Benutzeranzahlen 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
Taktfrequenzen. 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(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)
geschaltetem
Hyper-Threading
eine höhere Anzahl Benutzer mit
dem Terminal Server arbeiten können. Bei einem langsameren Monoprozessorsystem ist der PerformanceGewinn durch Hyper-Threading höher als bei einem schnellen Dualprozessorsystem.
Seite 19 (46)
White Paper
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 eingeschaltetem Hyper-Threading eine sehr gute
Skalierung vom Faktor 1.7.
Seite 20 (46)
White Paper
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-bitSystem 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 32bit-Version existiert.
(Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services)
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.
Seite 21 (46)
White Paper
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 ExplorerProzess 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.
Seite 22 (46)
White Paper
»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.
Seite 23 (46)
White Paper
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-bitBetriebssystem aufgebaut, so können damit mehr Benutzer arbeiten und somit muss auch das DiskSubsystem 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-bitBetriebssystem werden auch größere Datenmengen Richtung Pagefile geschrieben. Aus diesen Gründen
muss das Disk-Subsystem entsprechend dimensioniert werden. Hinweise zum Monitoren des DiskSubsystems 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.
Seite 24 (46)
White Paper
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 3DAnwendungen. 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-ServerKommunikation zu trennen.
Application Server
Terminal Server
Database Server
File Server
Network
Network
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 Bildschirmdarstellung werden zum Client übertragen.
Seite 25 (46)
White Paper
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 Serverbased 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.
Seite 26 (46)
White Paper
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.
Seite 27 (46)
White Paper
Ü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 TurnAround-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.
Seite 28 (46)
White Paper
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 Speicherbedarfs 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.
Seite 29 (46)
White Paper
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.
Seite 30 (46)
White Paper
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 Anwendungen 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 Programm 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. Hervorzuheben 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
Seite 31 (46)
White Paper
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
Xperfview
Xbootmgr
Event tracing durchführen und auswerten
Visionalisierung der Performance-Daten
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:
Seite 32 (46)
White Paper
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.
Seite 33 (46)
White Paper
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 Benachrichtigung 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 Leistungsvarianten von Server-Systemen ohne individuelle Anpassung gerecht werden können.
Auf einem Citrix Presentation Server 4.0 Terminal Server unter Windows Server 2003 Enterprise Edition 32bit mit 16 GB Hauptspeicher und Gigabit LAN sind beispielsweise folgende Werte voreingestellt:
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
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.
Seite 34 (46)
White Paper
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 werden können. MOM bietet proaktive
Benachrichtigungen
im
Warnungs- und Fehlerfall und erstellt
Berichte und Trendanalysen.
MOM bedient sich dabei existierenden Windows Mitteln wie der
Ereignisanzeige, liest die Performance Counter aus und überwacht 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 MOMDatenbank. So kann MOM nicht nur Terminal Server, sondern eine Vielzahl von verschiedenen ServerTypen 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 hieraus 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.
Seite 35 (46)
White Paper
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 ServerSystem 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
Verhältnis zur Last. Kein Engpass.
Konstant:
im
gleichen
Die Performance Counter sind nicht abhängig von
der Last, sondern konstant. Eventuell bilden sich
bei unterschiedlicher Last verschiedene Stufen
einer Treppenfunktion aus.
Logarithmisch:
Exponentiell:
Bei steigender Last steigen die Performance
Counter nicht weiter, sondern erreichen eine
Sättigung. Dies kann ein Indiz für einen Engpass
sein.
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.
Seite 36 (46)
White Paper
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.
Seite 37 (46)
White Paper
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
PerformanceAufzeichnung
wurde
auf
einem
PRIMERGY
Server
erstellt,
der
absichtlich in einen Hauptspeicherengpass
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 PagingAktivitä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 PagingAktivitä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 Arbeitsspeichers 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).
Seite 38 (46)
White Paper
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 KernelStrukturen, 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 Betriebssystemressourcen
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.
Seite 39 (46)
White Paper
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.
Seite 40 (46)
White Paper
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.
Seite 41 (46)
White Paper
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 PerformanceAnalyse eines Terminal Servers.
Seite 42 (46)
White Paper
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 CPULeistung 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 geschrieben 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.
Seite 43 (46)
White Paper
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 Konfiguration der Performance
Counter auch in eine Textdatei schreiben und mit dem
»logman« Kommando laden.
Hierzu siehe die Hilfe des
»logman« Kommandos mit
»logman -?«.
Ein fertiges Konfigurationsskript ist nebenstehend abgebildet. Es kann als HTMLDatei, z.B. mit dem Namen
»perf.htm«, am besten mit
einem Text-Editor wie Notepad, angelegt werden und
dann
im
Performance
Monitor mit »Neue Protokolleinstellungen von... (New
Log Settings From ...)« importiert werden. Besonders
wichtige Parameter sind farblich unterlegt, während der
fett gedruckte Laufwerksbuchstabe 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>
Seite 44 (46)
White Paper
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 MicrosoftPress-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
Citrix
CSTK /
Citrix ICAMark
3.0
Fujitsu
Technology
Solutions
T4US
visionapp
Remote
Desktop +
vRD Load
Edition
Login
Consultants
Login Virtual
Session
Indexer (VSI)
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
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
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
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
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
Seite 45 (46)
White Paper
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:Primergy-PM@ts.fujitsu.com
PRIMERGY Performance und Benchmarks
PRIMERGY Performance und Benchmarks
mailto:primergy.benchmark@ts.fujitsu.com
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:
Internet:
http://ts.fujitsu.com/primergy
Enterprise Products
PRIMERGY Server
PRIMERGY Performance Lab
mailto:primergy.benchmark@ts.fujitsu.com
Extranet:
http://partners.ts.fujitsu.com/com/products/serv
ers/primergy

Terminal Server Sizing Guide

Transcription

Similar documents

Terminal Server Sizing Guide

- MCS GmbH

lösungen für die automatisierung - SPS

- TuneUp Utilities 2014

Nr.: 1 CD Nr.: 2.44 Bilderbuch Deutschland – Leipzig Version2.6

Sizing Guide Exchange Server 2003