Fujitsu 68 User Manual

Terminal Server Sizing Guide

Abstract

In diesem technischen Papier wird die Frage diskutiert, wie viele Benutzer eine als Terminal Server eingesetzte PRIMERGY mit adäquater Performance bedienen kann. Das Papier richtet sich in erster Linie an Personen, die sich mit der Planung und Konfektionierung von Microsoft Terminal Server-Systemen beschäftigen. Es soll helfen, für eine geforderte Leistungsklasse das passende PRIMERGY Modell zu finden. Dabei wird auf die verschiedenen Leistungsklassen der PRIMERGY Modellpalette und deren Ausbaumöglichkeiten mit Prozessoren, Arbeitsspeicher und anderen Terminal Serverrelevanten Komponenten eingegangen.

Inhalt

PRIMERGY .................................................................2

Windows Terminal Server ...........................................3

Microsoft Terminal Services 2003.............................4

Citrix Presentation Server.........................................5

Skalierung.................................................................8

Scale-Up................................................................8

Scale-Out...............................................................9

Dimensionierung........................................................11

Benutzer .................................................................11

Benutzersimulation .................................................12

Vergleichbarkeit......................................................14

»Tool for User Simulation« .....................................15

Messumgebung.........................................................17

Lastprofil.................................................................18

Messmethode.........................................................19

Ressourcenbedarf.....................................................23

Rechenleistung.......................................................24

Prozessortyp........................................................24

Taktfrequenz........................................................25

Front-Side-Bus.....................................................32

Caches.................................................................33

Hyper-Threading..................................................35

Anzahl Prozessoren.............................................36

Verhalten bei hoher CPU-Last............................. 37

Arbeitsspeicher.......................................................39

Disk-Subsystem......................................................46

Netzwerk ................................................................49

Benutzerverhalten ..................................................51

Eingabegeschwindigkeit ......................................51

Betriebssystem.......................................................52

Windows Server 2003 R2.................................... 52

64-bit....................................................................53

Nutzbarer Speicher..............................................54

Physical Address Extension (PAE)......................56

Anzahl Prozesse.................................................. 57

Terminal Server Version.........................................58

Microsoft Terminal Server vs. Citrix Presentation

..................................................................58

Server

Citrix Presentation Server Version.......................58

Anwendungen ........................................................ 59

Microsoft Office Version.......................................59

Einstellungen für Microsoft Office in einer Terminal Server Umgebung

Infrastruktur ............................................................60

Vergleich der Messwerkzeuge ..................................62

Microsoft Testwerkzeuge und -Skripte.................62

Ergebnisse von Fujitsu Siemens Computers und Microsoft

Resümee...................................................................66

Literatur..................................................................... 68

Kontakt...................................................................... 68

Ausgabe 3.3 Dezember 2006

Seiten 68

.................................59

..............................................................64

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

PRIMERGY

All den Lesern, denen der Name PRIMERGY noch kein Begriff ist, sei hier zunächst ein kleiner Überblick gegeben: PRIMERGY Server ist seit 1995 der Markenname für die sehr erfolgreiche Industrie-Standard-Server-Familie aus dem Hause Fujitsu Siemens Computers. Es handelt sich dabei um eine bei Fujitsu Siemens Computers entwickelte und produzierte Produktlinie mit Systemen für kleine Arbeitsgruppen bis hin zu Lösungen für Großunternehmen.

Scalability, Flexibility & Expandability

Vom kleinen Monoprozessorsystem bis hin zu Systemen mit 16 Prozessoren kommen in der PRIMERGY-Familie die neuesten Technologien zum Einsatz. Als Herzstück werden Intel Prozessoren der obersten Leistungsklasse verwendet. Mehrere 64-bit PCI-X-I/O- und MemoryBusse, schnelles RAM und performante Komponenten, wie SCSI-Technologie und Fibre-Channel, sorgen für hohen Datendurchsatz. Dies bedeutet Leistung satt, gleich ob für Scaling-Out oder Scaling-Up. Bei der Methode des Scaling-Out, die nach dem Ameisenstaat-Modell mehr Leistung durch eine Vielzahl von Einzelindividuen erzielt, können idealerweise Blade-Server und kompakte Compu-Node Systeme platziert werden. Für die Methode des Scale-Ups, d.h. Hochrüsten eines vorhandenen Systems, sorgen die umfangreichen Ausbaumöglichkeiten der PRIMERGY Systeme, auf bis zu 16 Prozessoren und 128 Gigabyte Arbeitsspeicher. PCI- und PCI-X-Slots sorgen für die notwendige Erweiterbarkeit von I/OKomponenten. Eine Langzeitplanung in enger Zusammenarbeit mit namhaften Zulieferern von Komponenten, wie z.B. Intel, LSI, ServerWorks, sichert kontinuierliche und bestmögliche Kompatibilität von einer zur nächsten Server-Generation. Die PRIMERGY-Planung reicht zwei Jahre in die Zukunft und garantiert eine möglichst frühe Einbeziehung neuester Technologien.

Reliability & Availability

Neben der Leistung steht die Qualität im Vordergrund. Dazu zählen nicht nur eine exzellente Verarbeitungsqualität und der Einsatz qualitativ hochwertiger Einzelkomponenten, sondern auch Vorkehrungen zur Ausfallsicherheit, frühzeitiger Fehlerdiagnose und Datenschutz. Wichtige Systemkomponenten sind redundant ausgelegt, und werden vom System auf Funktionalität überwacht. Viele Teile können problemlos im laufenden Betrieb ausgetauscht werden, so dass Ausfallzeiten minimiert werden und die Verfügbarkeit gewährleistet wird.

Security

Ihre Daten sind der PRIMERGY heilig. Schutz vor Datenverlusten bieten leistungsfähige Disk-Subsysteme der PRIMERGY und FibreCAT Produktlinie. Eine noch höhere, größtmögliche Verfügbarkeit bieten PRIMERGY Cluster-Konfigurationen, bei denen nicht nur die Server, sondern auch die Disk-Subsysteme sowie die gesamte Verkabelung redundant ausgelegt werden können.

Manageability

Umfassende Management-Software für alle Phasen des Server-Lebenszyklus sorgt für einen reibungslosen Betrieb und erleichtert Wartung und Fehlerdiagnose der PRIMERGY.

ServerStart, ein benutzerfreundliches, menübasiertes Software-Paket für die optimale Installation und Konfigurierung des Systems mit automatischer Hardware-Erkennung und Installation aller notwendigen Treiber.

ServerView zur Serverüberwachung mit Alarm-, Schwellen-, Berichts- und Basis-Management, Prefailure Detection and Analyzing, Alarm-Service und Versionsmanagement.

RemoteView zur von der Hardware und dem Betriebssystem unabhängigen Fern-Wartung und -Diagnose via LAN oder Modem.

Weitere detaillierte Informationen zu den PRIMERGY Systemen finden Sie im Internet unter

http://www.primergy.de/.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Windows Terminal Server

Terminal Server steht als Oberbegriff für Server-based Computing auf Basis von Microsoft® Windows® Server Betriebssystemen.

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 g enannten Thin-Clients.

Senkung der TCO durch Rezentralisierung

Rasant ansteigende Betriebskosten (Total Cost of Ownership) zählen heute zu den größten Problemen in den IT-Umgebungen der Unternehmen. Früher achtete man bei der Einrichtung eines unternehmensweiten IT-Systems vorrangig auf die Anschaffungskosten und weniger auf die Folgekosten. Nach Angaben von Analysten haben jedoch die Anschaffungskosten, die zweifellos eine beträchtliche einmalige Investition darstellen, nur einen Anteil von 15 Prozent an den Gesamtkosten einer unternehmensweiten IT-Lösung. Daher richtet sich heute das Augenmerk mehr auf die laufenden Kosten.

Das Konzept des Server-based Computing hilft durch Rezentralisierung von Anwendungen und Daten, diese Kosten zu reduzieren. Man hat erkannt, dass es effektiver ist, in einer Client-Server-Architektur die Bereitstellung der Applikationen sowie Hardware- und Softwarepflege von einer zentralen Stelle aus im gesamten Unternehmen durchzuführen statt an jedem einzelnen Arbeitsplatz. Server-based Computing kann sowohl für die Endanwender als auch für die Systemadministratoren die Produktivität und Effizienz erheblich verbessern. Nach Meinung von Analysten kann das Server-based Computing die IT-Betriebskosten um 30 bis 50% senken.

Einsatzgebiet

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. Aber auch in Umgebungen, in denen ein einzelner Benutzer bereits eine höhere Rechen- oder Grafikleistung braucht, bietet der Terminal Server den Vorteil der zentralen Bereitstellung der Anwendungen.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Historie

Das von Mainframes seit langem bekannte Konzept des Server-based Computing hielt 1994 Einzug in die Windows-Welt. Als erstes entwickelte das US-amerikanische Softwarehaus Citrix eine Multiuser-Erweiterung für Microsoft Windows NT 3.51, die unter dem Namen »WinFrame« als Gesamtprodukt aus Windows NT und Multiuser-Erweiterung vertrieben wurde. 1997 hat Microsoft die so genannte »Citrix MultiWin Technologie« und damit einen Teil der Citrix-Betriebssystemerweiterung für NT von Citrix lizenziert und in das Produkt »Windows NT 4.0 Terminal Server« einfließen lassen. Seit 2000 hat diese Technologie unter dem Namen »Terminal Services« einen festen Platz in allen Server-Produkten der Microsoft Windows 2000 Server™ und Windows Server 2003 Produktlinie. Selbst in dem Client-Betriebssystem 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.

Bereits seit Windows 2000 Server bietet Terminal Server umfangreiche Funktionalitäten, hier nur einige der wichtigsten:

Unterstützte Clients

• 32-bit Clients für Windows-basierte PCs

• 16-bit Client für Windows for Workgroups

• Windows CE-basierter Thin-Client

• Windows XP Embedded-basierter Thin-Client

• Microsoft ActiveX

® Control

Client-Eigenschaften

• Datenaustausch von Text und Grafiken über die Zwischenablage zwischen Client und Server

• Bereitstellung der lokalen parallelen und seriellen Schnittstellen des Client innerhalb der Server-basierten

Anwendung

• Druck auf lokalen Druckern am Thin-Client

• Zugriff auf lokale Laufwerke des Clients innerhalb der Server-basierten Anwendung

• Bitmap-Caching zur Performance-Steigerung

Kommunikation

• Client-Anbindung über lokales Netzwerk (LAN), »wide area network« (WAN), Dial-up, »Integrated Services Digital Network« (ISDN), »x digital subscriber line« (xDSL), und »virtual private net work« (VPN)

• Verschlüsselung der Client-Kommunikation

Microsoft Terminal Services 2003

Windows Server 2003 Terminal Services bieten weitere Neuerungen gegenüber der Vorgängerversion in Windows 2000 Server. Hier einige der wichtigsten:

Server-Eigenschaften

• Optimiertes Ressourcen-Management, so dass Windows Server 2003 auf gleicher Hardware nun mehr Benutzer unterstützen kann als unter Windows 2000 Server.

• Windows Server 2003 Enterprise Edition und Datacenter Edition bieten ein Session Directory und somit die Möglichkeit, eine Terminal Server-Farm mit Load Balancing aufzubauen.

• Verbesserte Manageability durch Group Policies, Windows Mana gement Instrumentation (WMI).

• Nutzung von Windows Server 2003 Erweiterungen wie Software Restriction Policies, Erweiterung

von Roaming Profiles und neuen Windows-Anwendungskompatibilitätsmodi.

Client-Eigenschaften

• Unterstützung weiterer lokalen Geräte, wie Smart Cards, und Audio-Ausgabe innerhalb der Serverbasierten Anwendung

• Farbtiefe bis zu True Color (24-bit)

• Bildschirmauflösung bis zu 1600 x 1200

• Individuelle Zeitzonen je Benutzer

Die Terminal Services sind Bestandteil des jeweiligen Betriebssystems und liegen daher beim Windows 2000 Server und beim Windows Server 2003 als 32-bit Version und bei der Windows Server 2003 x64 Edition als 64-bit Version vor.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Citrix Presentation Server

Als Erweiterung der Basis Terminal Services in Windows bietet Citrix mit der Produktfamilie »Citrix Presentation Server for Windows« (im Weiteren abgekürzt als »Citrix Presentation Server«) sinnvolle Ergänzungen. Die aktuelle Version ist »Citrix Presentation Server 4.0 for Windows«. Die vorangegangenen Versionen sind unter dem Produktnamen »Citrix MetaFrame« bekannt geworden.

Um den Ansprüchen verschiedener Unternehmen gerecht zu werden, gibt es drei verschiedene Produktvarianten von Citrix Presentation Server:

• Citrix Presentation Server, Standard Edition Applikationsbereitstellung für kleinere Unternehmen

• Citrix Presentation Server, Advanced Edition Applikationsbereitstellung mit Load Balancing für mittlere Unternehmen

• Citrix Presentation Server, Enterprise Edition Applikationsbereitstellung mit Load Balancing für größere Unternehmen mit mehreren Standorten

Die wichtigsten Erweiterungen von Citrix Presentation Server gegenüber Windows Terminal Services sind:

Server

• Veröffentlichte Anwendungen (Published Applications), randlose Fenster (Seamless Windows) Direkter Start einer Server-seitigen Anwendung, ohne einen Windows Desktop zu starten. Direkter Zugriff auf einzelne Anwendungen.

• Load Balancing Ein integriertes Load Balancing sorgt für die automatische, lastspezifische Verteilung der Benutzer

auf die einzelnen Terminal Server einer Terminal Server-Farm. Das Load Balancing ist in Citrix Presentation Server Advanced Edition und Enterprise Edition enthalten, es wird dafür keine zusätzliche Software benötigt. Es kann eine sehr feine und individuelle Einstellung der Load Balancing-Kriterien vorgenommen werden, insbesondere können auch Terminal Server-spezifische Parameter gewählt werden.

Unterstützte Clients

• Unterstützung heterogener Clients Auch nicht Windows-basierte Clients können durch das Betriebssystem-unabhängige

»Independent Computing Architecture« (ICA)-Protokoll auf vom Server bereitgestellte Anwendungen zugreifen. Zusätzlich werden bei Citrix 16-bit Clients für ältere Windows-Versionen und für Microsoft MS-DOS® sowie Clients für UNIX, Macintosh, Java und ein Browser Client angeboten.

Die Versionen »Citrix MetaFrame XP«, »Citrix MetaFrame Presentation Server 3.0« und »Citrix Presentation Server 4.0« laufen nur unter einem 32-bit Windows Betriebssystem. Für Windows x64 ist der »Citrix Presentation Server for Windows Server 2003 x64« einzusetzen, der funktional der 32-bit Version »Citrix Presentation Server 4.0« entspricht.

Im Folgenden werden die Performance-relevanten Funktionen von »Citrix Presentation Server 4.0« im Vergleich zur Vorgängerversion 3.0 kurz charakterisiert.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Citrix Presentation Server 4.0

Citrix Presentation Server 4.0 enthält einige Neuerungen, die Einfluss auf die Performance haben können. Die ersten beiden Features dienen im Wesentlichen der Applikationskompatibilität.

Application Isolation

»Application Isolation« ermöglicht eine isolierte Installations- und Ablaufumgebung für Applikationen, mit dem Ziel gegenseitige Störungen durch z.B. Registry Settings, Konfigurationsdateien etc. auszuschließen. Das ist vorteilhaft, um verschiedene Versionen einer Applikation auf einem Terminal Server vorzuhalten, oder auch »Alt-Last« Anwendungen, die in einer Multi-User-Umgebung sonst nicht ablauffähig wären. Realisiert wird dieses Feature durch eine Virtualisierungsschicht für Registry Settings, Dateisystem und Named Objects z.B. Semaphoren, Sections etc., auf der die Anwendung installiert wird. Der Citrix Präsentation Server übernimmt dann das Mapping von den virtuellen Ressourcen auf die physikalischen Ressourcen des Betriebsystems. Dabei ist es möglich, die Anwendung bereits in eine isolierte Umgebung zu installieren oder auch nur eine veröffentlichte Anwendung in einer isolierten Umgebung ablaufen zu lassen. Letzteres ist sinnvoll, wenn die Applikation nicht in einer Mehrbenutzerumgebung ablaufen kann.

Virtual Address Support

»Virtual Address Support« unterstützt Anwendungen, die eine eindeutige IP-Adresse pro Session b enötigen.

Virtual Memory Optimization

Das Ziel der »Virtual Memory Optimization« ist es, Speicherplatz zu sparen, indem Adress Konflikte beim Laden von DLLs nicht durch »relocation« sondern durch »rebasing« gelöst werden. »Relocation« bedeutet, die DLL wird nicht an die im Image stehende Basisadresse geladen, sondern in einen anderen Teil des virtuellen Speichers und alle in der DLL benutzten Adressen müssen relativ zur Basisadresse umgerechnet werden. Eine Benutzung der DLL durch mehrere Applikationen hat damit auch ein mehrfaches Laden in den virtuellen Speicher zur Folge. »Rebasing« bedeutet, es wird eine Schattenkopie der DLL-Datei angelegt, die eine (konfliktfreie) optimale virtuelle Basisadresse enthält. Dadurch braucht ein »rebased« Objekt nur einmal geladen werden, auch wenn es von mehreren Applikationen genutzt wird.

Das »rebasing« von DLLs führt damit also zu Einsparungen beim virtuellen Speicherplatzverbrauch. In welchem Maße die Speicheranforderungen verringert werden, ist stark applikationsabhängig. Außerdem funktioniert dieses Feature auch nicht bei allen Anwendungen, z.B. können Applikationen, deren DLLs geschützt sind durch »Windows Rights Managements« oder die »digitally signed components« haben, nicht rebased werden. Solche Applikationen können durch eine Ausschlussliste vom Prozess des Optimierens ausgeschlossen werden.

Die »Virtual Memory Optimization« wird durch einen Monitorprozess realisiert, der feststellt, wo »relocation« von DLLs erfolgt und dies in deiner Datei protokolliert.

Zu vom Administrator festzulegenden Zeiten wird dann ein Prozess tätig, der diese Datei liest und das »Rebasing« der entsprechenden DLLs durchfüh rt.

Zusätzlich zum »Rebasing« erfolgt auch das »Binding« von DLLs, d.h. in der DLL »import Section« wird die virtuelle Ladeadresse der importierten Funktionen gleich eingetragen. Auf diese Weise wird CPU-Zeit beim Initialisieren der Applikation gespart.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

CPU Utilization Management

Das »CPU Utilization Management« dient dazu, die CPU-Leistung gleichmäßig auf die vorhandenen Benutzer aufzuteilen, um dadurch Spitzen in der CPU-Auslastung eines Servers auszugleichen, und daher mehr User pro Server zu ermöglichen.

Der tatsächliche Performancegewinn ist sehr abhängig von der Anwendungsla st. Wenn das »CPU Utilization Management« aktiviert ist, bekommt jeder Benutzer den gleichen Anteil CPU-

Zeit zugeteilt. Auf diese Weise soll verhindert werden, dass ein Benutzer, der besonders intensiv die CPU nutzt, andere Benutzer benachteiligt. Schöpft ein Benutzer seinen ihm zur Verfügung stehenden Anteil an CPU-Leistung nicht voll aus, so können die anderen Benutzer diese Leistung nutzen. Es ist auch möglich, einem Benutzer einen relativ zu den anderen Benutzern höheren Anteil an CPU-Leistung zuzusprechen. Ebenso ist es möglich, einem Benutzer einen festen Anteil der Rechenleistung, unabhängig von der Gesamtlast, zuzuteilen.

Leider gibt es für die Verwaltung der benutzerspezifischen CPU-Zuteilung kein grafisches Benutzerinterface und die Einstellungen erfolgen über entsprechende »Registry Settings«.

Realisiert wird die entsprechende CPU-Zuteilung über Prozesse, die den CPU-Verbrauch der Benutzer monitoren und dann über Betriebsystemaufrufe den Scheduler beeinflussen.

Support für Windows Server 2003 x64 Edition

Citrix unterstützt Windows Server 2003 x64. Mit der 64-bit Version von Windows können verschiedene Limitierungen von 32-bit überwunden werden. So sind z.B. unter dem 64-bit Betriebssystem die KernelRessourcen ausreichend dimensioniert; ein Beispiel ist der Non-Paged Pool mit 128 GB ,der unter dem 32bit Windows durch die geringe Größe (256 MB) schon zum Engpass werden konnte (vgl. auch Kapitel

Nutzbarer Speicher). Auch unter dem 32-bit Betriebssystem bietet Citrix Presentation Server Version 4.0

Vorteile gegenüber der Vorgängerversion, da bestimmte Seiten, die früher dem »Non-Paged Pool« zugeordnet waren, jetzt dem »Paged Pool« zugeordnet sind.

Verbessertes Printing

Ein neuer »Universal Print Driver« verspricht laut Dokumentation eine bis zu vierfach verbesserte Druckgeschwindigkeit bei verminderter Speicher- und Bandbreitennutzung.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Skalierung

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

Beide Szenarien, sowohl Scale-Up als auch Scale-Out, werden von Terminal Server unterstützt.

Scale-Up

Beim Scale-Up wird die Leistung eines Terminal Servers durch den Einsatz leistungsfähigerer Hardware, also insbesondere Rechenleistung und Arbeitsspeicher, erhöht. Diesem Skalierungsprozess sind Grenzen durch die maximale Größe eines Server-Systems gesetzt.

Theoretisch benötigt man »nur« eine beliebig leistungsfähige Hardware und würde im Scale-Up-Szenario einen beliebig leistungsfähigen Terminal Server erhalten. Dies ist jedoch leider nur Theorie. So ist die Skalierung mit wachsender Anzahl Prozessoren 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. Man bezeichnet diesen Sachverhalt auch als »Amdahls Gesetz«, nach Gene Amdahl, der dieses 1967 untersuchte und in ein mathematisches Modell fasste.

Designer von großen Multiprozessorsystemen 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 zuo rdn en.

In der Praxis setzt heute oft nicht die Hardware die Grenzen, sondern die Software-Architektur. Die heute zumeist eingesetzte Software im 32-bit Design kann die zur Verfügung stehende Hardware häufig nicht mehr voll nutzen. Im speziellen ergeben sich Limitierungen bei der Adressierung des Arbeitsspeichers, durch die 32-bit Anwendungen auf 4 GB virtuellen Adressraum begrenzt sind. Ist der Server physikalisch mit mehr als 4 GB Arbeitsspeicher ausgestattet, so kann dieser Speicher zumeist nicht effektiv genutzt werden. Durch die Abhängigkeit zwischen dem Bedarf an Arbeitsspeicher und Rechenleistung können viele Anwendungen auch die Rechenleistung, die moderne Systeme mit 8 oder 16 CPU-Sockeln bereitstellen, nicht ausschöpfen.

Auch für Terminal Server ergibt sich eine Grenze, ab der ein Scale-Up nicht mehr die gewünschte Leistungssteigerung zeigt Diese ist bei dem heutigen 32-bit Windows Server 2003 bei einem 4-way System mit 4 GB Arbeitsspeicher zu sehen. Daher waren Terminal Server-Umgebungen bisher klassische ScaleOut-Szenarien. Mit 64-bit-Betriebssystemen und 64-bit-Anwendungen werden diese Grenzen überwunden, so dass viele Kunden heute vor der Frage stehen, ob die neue 64-bit-Welt eine Lösung für die bisherigen Engpässe darstellt. Siehe hierzu die Kapitel »

Rechenleistung«, »Arbeitsspeicher« und »Betriebssystem«).

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Scale-Up ist eine adäquate Skalierungsmethode, wenn eine überschaubare Anzahl an Benutzern zu bedienen ist (vgl. Kapitel »

Resümee«). Ist eine größere Anzahl an Benutzern von mehreren hundert oder

tausenden mit Terminal Server zu bedienen, so kann das Scale-Up-Szenario nicht mehr verwendet werden und es bedarf anderer Mechanismen um die Leistung eines Terminal Servers zu steigern.

Scale-Out

Das Scale-Out-Szenario verfolgt einen anderen Weg als das Scale-Up. Anstatt einen Server immer größer zu dimensionieren, werden beim Scale-Out viele Server zu einer Gruppe zusammengefasst. Man spricht auch von Server-Farmen.

Mit diesem Konzept kann leicht die Grenze überwunden werden, die ein einzelner Terminal Server aufgrund seiner Software-Architektur bedingt. Die Skalierung ist aber auch bei einer Server-Farm nicht ideal linear, denn analog zu Amdahls Gesetz bei Multiprozessorsystemen gibt es auch in einer Server-Farm Overhead durch interne Kommunikation. Allerdings fällt dieser meist geringer aus als bei großen Multiprozessorsystemen.

Beim Scale-Out kann man drei Varianten unterscheiden:

Just a Bunch of Servers

»Just a Bunch of Servers« ist eine lose Ansammlung von Servern, in unserem Fall Terminal Servern. Diesen Terminal Servern sind dediziert Benutzergruppen oder Applikationen zugeordnet, es findet jedoch unter den Terminal Servern kein Informationsaustausch und kein Lastausgleich statt.

Der Vorteil dieser Architektur ist die sehr einfache Erweiterbarkeit. Nachteilig ist, dass kein automatischer Lastausgleich zwischen den einzelnen Servern stattfindet, so dass je nach Zuordnung der Benutzer zu den Servern Rechenleistung ungenutzt bleibt. 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.

Server-Farm

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 erfolgt meist statisch, ein Load Balancing wird nicht notwendigerweise verwendet. Vorteil gegenüber der »Just a Bunch of Servers« Variante ist die vereinfachte Administration. Redundanz und ein automatischer Lastausgleich sind jedoch nicht gegeben.

Auch diese Variante des Scale-Outs wird in der Praxis sehr häufig eingesetzt.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

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.

Wesentliche Basis für ein Load Balancing von Terminal Servern ist das Führen einer SessionListe. Terminal Server erlaubt es eine Verbindung zwischen Client und Server zu trennen (disconnect), wobei die Session auf dem Terminal Server jedoch weiterläuft. Baut der Client erneut eine Verbindung zu der Terminal Server-Farm auf, so muss anhand dieser Session-Liste sichergestellt werden, dass er wieder zu »seiner« bestehenden Session verbunden wird und nicht aufgrund des Load Balancing zu einem anderen Terminal Server der Farm, der momentan die geringste Auslastung zeigt. Eine Verschiebung von Sessions zwischen den einzelnen Mitgliedern der Farm wird von Terminal Server nicht un terstützt.

Neben dem Verteilen der Benutzer-Verbindungen in Abhängigkeit der Auslastung bietet die Methode der load-balanced Server-Farm auch eine gewisse Redundanz. Fällt ein Terminal Server aus, so können die Benutzer von den anderen Mitgliedern in der Server-Farm bedient werden. Bei dediziert zugeordneten Terminal Servern im »Just a Bunch of Server« Szenario stehen bei einem Ausfall eines Terminal Servers den zugeordneten Clients keine Terminal Server-Dienste mehr zur Verfügung. Allerdings bietet eine loadbalanced Server-Farm keine Ausfallsicherheit für die einzelnen Client-Sessions. Fällt ein Terminal Server im laufenden Betrieb aus, so gehen alle auf diesem Terminal Server aktiven Sessions verloren.

Große Terminal Server Farmen, die sich auch über mehrere Standorte erstrecken können, findet man in der Praxis häufig in Enterprise-Umgebungen.

Scale-Out mit Terminal Server

Die einzelnen Versionen von Terminal Server unterscheiden sich hinsichtlich Ihrer Scale-Out Fähigkeiten. Windows 2000 Server Terminal Services unterstützt keine Session-Liste. Eine Server-Farm mit Load

Balancing kann somit ohne eine Zusatzsoftware wie Citrix Presentation Server nicht realisiert werden. Windows Server 2003 Terminal Services unterstützt in den Enterprise und Datacenter Editionen eine

Session-Liste. Das Load Balancing kann wahlweise mit Windows »Network Load Balancing« (NLB) oder mit dedizierten 3

-Party Load Balancern, wie z.B. F5 Network BIG-IP, realisiert werden.

Citrix Presentation Server Advanced Edition und Enterprise Edition unterstützen ein Session-Directory und bieten ein eigenes sehr flexibles Load Balancing, das speziell auf die Bedürfnisse von Terminal Server zugeschnitten ist.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Dimensionierung

Aus Gründen der zentralen Administration werden Terminal Server heute in einem breiten Aufgabenspektrum eingesetzt. Nicht nur für Aufgaben, wo bislang kleine Rechner oder Terminals für einfache Dateneingabe bzw. -abfrage Verwendung fanden, sondern auch in Umgebungen, in denen ein einzelner Benutzer durchaus die Rechen- oder Grafikleistung eines dedizierten PCs benötigt.

Vor jeder Implementierung eines Applikationsservers 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. 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.

Benutzer

Um den unterschiedlichen Einsatzszenarien und Anwendern gerecht zu werden und dennoch eine Vereinheitlichung zu erreichen, definiert man Benutzergruppen. Dabei befassen sich neben den Autoren von Sizing Guides auch Marktforschungsinstitute mit diesem Thema. Die von der Gartner Group getroffene Einteilung dürfte eine der gebräuchlichsten in der IT-Branche sein (Quelle »TCO: A Critical Tool for Managing IT« Gartner Group, 12.10.1998). Darin wird eine Vielzahl von Benutzergruppen definiert:

HighPerformance Worker

Knowledge Worker

Mobile Worker

Process Worker

Data Entry Worker

verwendet EDV zur Erstellung von Produkten nutzt sehr spezialisierte Anwendungen Ingenieure, Graphiker und Programmierer verwendet EDV zur Sammlung von Daten aus unterschiedlichen Quellen nutzt ein Mix aus Office- und spezialisierten entscheidungsunterstützenden Anwendungen Analysten, Berater und Projekt-Manager Im wesentlichen ein Knowledge Worker, jedoch Standort unabhängig nutzt ein Mix aus Office-Anwendungen Analysten, Berater und Projekt-Manager verwendet EDV zur Bearbeitung immer wiederkehrender Aufgaben in einem Produktions-

prozess nutzt einen Mix aus Office- und Enterprise-Anwendungen Sachbearbeiter, Kundendienst und Helpdesk Nutzt die EDV zur Eingabe von Daten verwendet zumeist nur eine Anwendung Bestellwesen, Wareneingang und Verwaltungsaufgaben

Für Anwendungen, die auf Terminal Server basieren, sind nicht alle Benutzergruppen von Belang. Die Gruppe der High-Performance Worker nutzt typischerweise dedizierte Workstations; und Mobile Worker nutzen Anwendungen lokal auf ihren mobilen Arbeitsplätzen. Benötigen diese Benutzergruppen in Ergänzung zu ihren lokalen Arbeitsplätzen Terminal Server Anwendungen, so können sie der Gruppe der Knowledge Worker zugeordnet werden.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Die Klassifizierung der Benutzer und Einteilung in Gruppen nach Gartner sagt jedoch noch nichts über die tatsächliche Aktivität aus, also konkret, welche Anwendung Benutzer einer bestimmten Gruppe nutzen und mit welcher Intensität. Insbesondere die Arbeitsgeschwindigkeit, also wie schnell ein Benutzer Text eingibt oder auf Dialoge der Anwendung reagiert, spielt eine große Rolle. Berücksichtigt man dieses, so kann man basierend auf Gartner drei Benutzerklassen definieren, die zumeist mit Heavy, Medium und Light bezeichnet werden:

nutzt gleichzeitig mehrere verschiedene Anwendungen

Heavy Knowledge Worker

gibt Daten mäßig schnell ein führt komplexere Operationen aus

arbeitet zu einer Zeit intensiv mit einer Anwendung

Medium Process Worker

gibt schnell viele Daten ein arbeitet kontinuierlich

arbeitet zu einer Zeit nur mit einer Anwendung

Light Data Entry Worker

gibt wenig Daten ein längere Pausen zwischen den Eingaben

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.

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 ServerClient, von dem einer oder mehrere auf dem Lastgenerator ausgeführt werden. Ein simulierter »Benutzer« arbeitet innerhalb einer Terminal Server Sitzung.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Für Terminal Server gibt es verschiedene Werkzeuge zur Simulation von Last. Einige der bekannteste n sind:

Terminal Server Scalability Planning Tool

CSTK

CitraTest

LoadRunner for Citrix

• Eine Lastsimulator-Suite von Microsoft ( Windows Server 2003 Resource Kit ist.

• Arbeitet nur mit Microsoft Terminal Services.

• Modifiziert den RDP-Client zur Simulation der Benutzereingaben.

• Simulation von Maus-Eingaben nur bedingt möglich.

• Es werden modifizierbare Skripte für Lastprofile mitgeliefert, die ein aufwändiges

Testszenario bedingen und nicht nur Terminal Server, sondern auch BackOffice Dienste, wie Exchange und SQL in den Test mit einbeziehen.

• Es können maximal 20 Benutzer mit einem Lastgenerator simuliert werden.

• Zur Vermessung von load-balanced Terminal Server-Farmen nur bedingt geeignet.

• Ein kostenloser Lastsimulator von Citrix (

• Arbeitet nur mit Citrix Presentation Server zusammen, da nur das ICA-Protokoll

unterstützt wird.

• Die eigentliche Simulation der Eingabe-Daten erfolgt nicht auf dem Lastgenerator (Client), sondern auf dem Server.

• Nur Simulation von Tastatureingaben möglich.

• Die Ausgaben der Terminal Server Session werden nicht auf Korrektheit überprüft.

• Es werden Skripte für Lastprofile mitgeliefert, die aber nicht veränderbar und einsehbar

sind.

• Kundenspezifische Skripte müssen manuell und mit Hilfe eines kostenpflichtigen 3 Party Tools erstellt werden.

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

• CSTK ist instabil und für leistungsfähige Server-Systeme nicht nutzbar. Die Messergebnisse sind nicht reproduzierbar. Nutzbar als Test-Tools aber nicht zur Messung geeignet.

• Zur Vermessung von load-balanced Terminal Server-Farmen ungeeignet.

• Ein kommerzielles Produkt der gehobenen Preisklasse von Tevron

(http://www.tevron.com).

• Kann sowohl für Microsoft Terminal Server als auch für Citrix Presentation Server verwendet werden.

• Das Simulations werkzeug läuft ausschließlich auf dem Client, ohne Cl ient und Server zu modifizieren.

• Es werden Tastatur- und Maus-Eingaben simuliert.

• Die Ausgaben der Terminal Server Session können auf Korrektheit überprüft werden.

• Es werden keine Skripte zur Benutzersimulation mitgeliefert.

• Tool-gestützte Erstellung kundenspezifischer Skripte möglich.

• Etwa nur 5 bis 10 Benutzer auf einem Lastgenerator simulierbar.

• Zur Vermessung von load-balanced Terminal Server-Farmen geeignet.

• Ist ein kommerzielles Produkt der gehobenen Preisklasse von Mercury Interactive

(http://www.mercuryinteractive.com).

• Unterstützt nur Citrix Presentation Server, jedoch keinen Microsoft Terminal Server.

• Die Simulation der Eingaben erfolgt mittels eines modifizierten ICA-Clients.

• Es werden Text- und Maus-Eingaben simuliert.

• Die Ausgaben der Terminal Server Session werden auf Korrektheit überprüft.

• Tool-gestützte Erstellung kundenspezifischer Skripte möglich.

• Zur Vermessung von load-balanced Terminal Server-Farmen ungeeignet.

http://www.microsoft.com), die Bestandteil des

http://www.citrix.com/cdn).

Wie die Auflistung zeigt, sind viele dieser Lastsimulatoren leider sehr spezialisiert und nicht universell und uneingeschränkt nutzbar. Einige können nur mit einer speziellen Version des Terminal Servers zusammenarbeiten, bei anderen kann der zu simulierende Benutzer nicht modelliert werden, wiederum andere verfälschen möglicherweise das Messergebnis durch zusätzliche Komponenten der Simulationssoftware auf Client oder Server.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Vergleichbarkeit

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-C, gibt es für Terminal Server bis heute keinen standardisierten und akzeptierten Benchmark.

Es gibt zwar verschiedene Lastgeneratoren, die auch mit vordefinierten Lastprofilen bereitgestellt werden, wie es beim Terminal Server Scalability Planning Tool von Microsoft und dem CSTK von Citrix der Fall ist, jedoch mangelt es an einem Reglement bezüglich der Messumgebung, der Durchführung der Messung und standardisieren Lastprofilen, so dass durch diesen Spielraum jeder Hersteller andere Resultate ermittelt hat. Ein weiterer Mangel ist die Tatsache, dass es kein standardisiertes Werkzeug gibt, mit dem sowohl Microsoft als auch Citrix Terminal Server vermessen und verglichen werden können.

Die 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 gleichem Lastprofil durchgeführt wurden, können auch sinnvoll verglichen werden. Daher haben Microsoft und Fujitsu Siemens Computers zusammengearbeitet, um die Ergebnisse ihrer zwei Messwerkzeuge auf der gleichen PRIMERGY Hardware zu vergleichen. Die Unterschiede in den Ergebnissen des »Microsoft Terminal Server Capacity and Scaling« Werkzeugs und des Fujitsu Siemens Computers »T4US« Werkzeugs werden detailliert im Kapitel »

Des Weiteren ist zu beachten, dass Performance-Messungen nicht in realen Produktivumgebungen, sondern in idealisierten Laborumgebungen durchgeführt werden. Zwar wird versucht, diese möglichst realitätsnah nachzubilden, es können jedoch nicht alle kundenspezifischen Gegebenheiten berücksichtigt werden.

Vergleich der Messwerkzeuge« diskutiert.

Obgleich die Einheit vieler Performance-Messungen »Anzahl Benutzer pro Server« ist, sollte man die Ergebnisse von Performance-Messungen in erster Linie relativ betrachten, 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 »

Benutzer«

erläutert, ist ein Benutzer schwer zu quantifizieren, und ein synthetischer Benutzer muss nicht in allen Fällen mit einem realen Benutzer korrelieren.

Mit dieser Ausgabe liegt Version 3.x des PRIMERGY Terminal Server Sizing Guides vor. Zwischen jeder Ausgabe haben sich die Randbedingungen grundlegend geändert, so dass sich die in den bisherigen Dokumenten genannten absoluten Benutzerzahlen leider nicht miteinander vergleichen lassen. Zum einen hat jeweils ein Generationswechsel in den Betriebssystemen und Terminal Servern vorgelegen, zum anderen musste leider auch die Messmethodik den wechselnden Voraussetzungen in der IT-Landschaft angepasst werden. So zeigte z.B. das für die Version 2.0 des Sizing Guides eingesetzte Lastsimulationstool gravierende Schwächen hinsichtlich der Stabilität und Reproduzierbarkeit der Ergebnisse, so dass bei heutiger Leistungsfähigkeit der PRIMERGY Server lediglich ein Monoprozessorsystem vermessen werden könnte (vgl. Kapitel »

Benutzersimulation«). Um dennoch einen Vergleich zu älteren PRIMERGY Systemen

vornehmen zu können, wurden in den Messreihen für diese Ausgabe auch einige Prozessoren älterer PRIMERGY Server einbezogen, so dass Rückschlüsse auf die Leistungsfähigkeit zwischen älteren und aktuellen PRIMERGY Server gezogen werden können (vgl. Kapitel »

Prozessortyp«).

Es hat sich gezeigt, dass viele Messtools, z.B. CSTK, im Vergleich zur Realität zu hohe Benutzerzahlen liefern. Ein Grund hierfür ist, dass sich während der gesamten Messphase kein Benutzer an- oder abmeldet. In unseren neuen Messreihen haben wir dem Rechnung getragen und können daher davon ausgehen, dass die ermittelten Benutzerzahlen denen aus realen Produktionsumgebungen nahe kommen.

Trotzdem 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 von Citrix Presentation Server oder Komponenten aus der Citrix Access Suite, für die Rechenleistung zur Verfügung stehen muss. Der Terminal Server sollte im Normalbetrieb auch nicht bis an seine Leistungsgrenze belastet werden.

Es hat sich auch gezeigt, dass sich allein durch leichte Modifikationen des Benutzerprofils hinsichtlich der Eingabegeschwindigkeit die Benutzeranzahl pro Terminal Server verdoppeln oder halbieren kann. Die Ergebnisse dieser Untersuchungen findet man im Kapitel »

Eingabegeschwindigkeit«.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

»Tool for User Simulation«

Aus den Gründen, die in den vorhergehenden Abschnitten diskutiert werden, hat Fujitsu Siemens Computers sich entschlossen, einen eigenen Lastsimulator zu entwickeln, der keinen dieser Nachteile besitzt und der unabhängig von dem verwendeten Terminal Server und ohne Einflüsse auf das zu testende System beliebige Benutzerprofile simulieren kann.

T4US, »Tool for User Simulation«, ist ein flexibles Werkzeug, das beliebige Terminal Server-artige Szenarien simulieren kann, unabhängig vom verwendeten Betriebssystem und von der Anwendersoftware, und eine detaillierte Messwerterfassung von Antwortzeiten und Auslastung unterschiedlichster Systemkomponenten vornimmt.

Benutzeraktivitäten können mit Hilfe des Aufzeichnungswerkzeugs T4US-Record in Echtzeit aufgezeichnet werden. Dazu gehören die Tastaturund Mauseingaben, die Zeiten zwischen den einzelnen Eingaben, sowie die Bildschirmausgaben. Alle Aktionen werden in lesbarer Form in einem T4US- Skript abgelegt. In der Simulation werden diese aufgezeichneten Eingabedaten mit identischem Zeitverhalten simuliert und die Bildschirmausgaben mit den aufgezeichneten verglichen. Dabei sind die Simulationsläufe jederzeit reproduzierbar. Verschiedene T4US-Skripte können miteinander kombiniert werden, so dass aus den Aufzeichnungen von unterschiedlichen Benutzeraktivitäten beliebige Lastprofile zusammengestellt werden können. Sollen die Lastprofile an verschiedene Umgebungen angepasst werden oder für eine Vielzahl von Benutzern gleichzeitig verwendet werden, so können Teile mit Hilfe von variablen Parametern wie Benutzername, Servername, Domainname usw. parametrisiert werden ohne das Zeitverhalten zu beeinflussen.

Der Lastsimulator von T4US besteht aus drei Komponenten. T4US-Control ist die zentrale Steuerkonsole. Über eine grafische Oberfläche wird der gesamte Simulationslauf zentral gesteuert und überwacht. Alle Messwerte werden bereits während der Messung ermittelt und über ein separates LAN, das Simulationsnetzwerk, von den Lastgeneratoren zur Steuerkonsole übermittelt und dort gesammelt. Bereits während der Messung können die Werte automatisch ausgewertet und so zur dynamischen Steuerung des Messlaufs verwendet werden.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Auf jedem der Lastgeneratoren laufen mehrere Instanzen des T4US-Playback. Jedes T4US-Playback »füttert« einen Terminal Server-Client in Echtzeit mit Tastatur- und Mauseingaben anhand der mit T4USRecord aufgezeichneten Skripte und überwacht die Bildschirminhalte des Terminal Server-Clients. Anhand der Bildschirminhalte erfolgt die Synchronisation; das Skript wartet so lange, bis der erwartete Bildschirminhalt vollständig erschienen ist. Durch hoch auflösende Timer wird die Antwortzeit des Terminal Servers ermittelt. Die Synchronisation ist besonders wichtig für ein verlässliches Messwerkzeug, da dadurch einerseits Fehleingaben vermieden werden und andererseits so erst die Reaktionszeit des Terminal Servers deutlich und messbar wird.

Jede Instanz von T4US-Playback kann dabei ein beliebiges Skript ausführen, so dass ein Mix unterschiedlicher Benutzergruppen und asynchrones Benutzerverhalten simuliert werden kann. 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.

Mit T4US erfolgt die gesamte Lastsimulation von außen, ohne den Terminal Server-Client zu modifizieren oder zusätzliche Software auf dem Terminal Server zu installieren. Selbst für die Kommunikation zwischen Controller und den Lastgeneratoren wird ein separates Netzwerk verwendet, so dass es keine Einflüsse auf den Datentransport zwischen Terminal Server und Terminal Server-Clients gibt. Somit ist es möglich, nicht nur den Terminal Server zu vermessen, sondern auch die Einflüsse verschiedener Clients oder ClientOptionen, wie z.B. Bildschirmauflösung, -farbtiefen oder Audioausgabe, auf die Netzwerkbandbreite zu ermitteln. Das »System under Test« (SUT), wie man das System, welches vermessen wird allgemein bezeichnet, besteht also nicht nur aus dem Terminal Server selbst, sondern genau genommen aus den Terminal Server-Clients, dem Netzwerk zwischen Clients und dem Terminal Server, sowie dem Terminal Server selbst. T4US wird diesem Sachverhalt gerecht, in dem es keinen Eingriff in diese Client-NetzwerkServer-Beziehung macht.

Die Terminal ServerClients und die Komponenten T4US-Agent und T4US-Playback laufen zusammen auf den Lastgeneratoren. Durch Vergleichsmessungen wird jedoch sichergestellt, dass die Hardware der Lastgeneratoren so dimensioniert ist, dass sie keinen Engpass darstellt und keinen negativen Einfluss auf die Terminal Server-Clients und somit auf das Messergebnis hat. Weiterhin kann man optional einen Lastgenerator als so genannten Referenz-Client betreiben, der nur einen einzigen Benutzer simuliert, während alle anderen Lastgeneratoren eine Vielzahl von Benutzern simulieren. Durch Vergleich der Messwerte des Referenz-Clients mit denen der anderen Clients kann eine Einflussnahme der Lastgeneratoren auf die Messergebnisse ausgeschlossen werden.

Der sich noch im SUT-Netzwerk befindende Infrastruktur-Server stellt dem zu vermessenden Terminal Server Basis-Dienste wie Active Directory, Domain Name Service (DNS) und Terminal Services Licensing zur Verfügung, er wird selbst nicht vermessen.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Messumgebung

Nachdem wir uns im vorangegangen Kapitel allgemein mit Benutzerklassen, Benutzersimulation und Lastgeneratoren auseinander gesetzt haben, kommen wir nun zu den für die PRIMERGY Server-Familie durchgeführten Performance-Messungen.

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

Controller (T4US-Control):

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

Lastgeneratoren:

• 20 - 24 Lastgeneratoren mit jeweils zwei Pentium III Prozessoren mit mehr als 1 GHz und 1 GB

Arbeitsspeicher wurden eingesetzt.

• Die Lastsimulatoren liefen unter dem Betriebssystem Windows Server 2003 Standard Edition SP1.

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.

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.

• 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.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

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 als Terminal Server Licensing

Service.

• Der Infrastruktur-Server lief unter dem Betriebssystem Windows Server 2003 Standard Edition SP1. Diese synthetische Messumgebung vereinfacht eine realistische Kundenumgebung stark, um Einflüsse

anderer Systeme auszuschließen und reproduzierbare Ergebnisse zu erhalten. Der Einfluss weiterer Komponenten in einer Terminal Server Umgebung wird im Kapitel »

Infrastruktur« diskutiert.

Lastprofil

Alle Messungen wurden mit einem Medium Lastprofil durchgeführt. Wie im Kapitel »Benutzer« definiert, arbeitet ein »Medium User« mit nur einer Anwendung und gibt Daten zügig ein. In unserem Medium Lastprofil dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute.

Das Lastprofil wurde in einem realen Szenario aufgezeichnet und die Eingabe der Zeichen entspricht der realen Arbeitsgeschwindigkeit eines mit 10 Fingern schreibenden Autors.

Des Weiteren beinhaltet das Medium 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 mit der Größe von ca. 227 KB 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.

Da es bei diesem Sizing Guide um einen relativen Vergleich der PRIMERGY Modelle untereinander geht, wurde auf Untersuchungen mit weiteren Lastprofilen verzichtet. Dies würde zwar zu einer anderen Anzahl von Benutzern pro PRIMERGY führen, die Relation zwischen den einzelnen PRIMERGY Modellen wäre jedoch die gleiche.

Bei einer Aussage von absoluten Benutzerzahlen auf einem Server muss ohnehin der kundenspezifische Last-Mix analysiert und mit den Leistungsdaten in diesem Papier in Relation gesetzt werden (vgl. Kapitel

Vergleichbarkeit«).

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

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.

Messarten, Messdauer und Messphasen

Vor der Messung werden grundsätzlich alle Systeme, d.h. Lastgeneratoren und Server under Test, inklusive der T4US-Client Komponenten T4US-Agent und T4US-Playback, neu gestartet. Auf dem Controller-System wird der T4US-Controller jedes Mal neu gestartet.

T4US unterstützt drei verschiedene Messfunktionen:

Referenzmessung mit konstanter Benutzeranzahl

Eine konstante, aber geringe Anzahl von Benutzern lässt ein oder mehrere T4US-Skripte mehrmals durchlaufen. In der Terminal Server Messumgebung wurde das T4US-Skript mindestens dreimal hintereinander von fünf Benutzern ausgeführt. Diese Messdaten werden gesammelt und aus ihnen berechnet der T4USController für jeden einzelnen Messpunkt Vergleichswerte, die als Baseline für die weiteren Messungen dienen.

Messung mit konstanter Benutzeranzahl

Bei der Messung mit konstanter Benutzeranzahl arbeitet eine gleich bleibende Anzahl von Benutzern über einen vorgegebenen Zeitraum mit dem Terminal Server.

Als Resultat der Messung erhält man die Antwortzeiten des Terminal Servers und Performance Counter des Servers.

Die Messung selbst unterteilt sich in drei Phasen:

Startphase

(Startup)

15 Minuten

Während der Startphase nehmen nach und nach alle T4US-Playback’s auf Befehl des T4US-Controllers ihre Arbeit auf. Hierbei verteilt der T4US-Controller den Start der Skripte gleichmäßig auf die Startphase, die immer 15 Minuten dauert; unabhängig davon, wie viele Benutzer simuliert werden sollen. Dies entspricht der Realität, da leistungsstärkere PRIMERGY Server insgesamt mehr Benutzer bedienen können und diesen daher auch mehr Anmeldungen in der gleichen Zeit zugemutet werden als leistungsschwächeren Systemen. Auf eine ungleichmäßig gestaffelte Verteilung der Anmeldungen, wie sie in anderen Messungen gern gemacht wird, wurde bewusst verzichtet, da in der Realität der Benutzer auch nicht länger mit seiner Anmeldung warten wird, nur weil schon viele Benutzer arbeiten. Die Startphase ist beendet, wenn alle Skripte gestartet sind.

Einschwingphase

(Warm-up)

30 Minuten Messphase

(Steady State)

60 Minuten

Während der Einschwingphase laufen alle T4US-Playback’s gemäß den eingestellten Skripts ab.

Die jetzt folgenden 60 Minuten dienen der Erhebung von Messdaten. Es werden die Performance Counter des Terminal Servers ausgewertet sowie die von den T4US-Playback’s gemeldeten Antwortzeiten des Terminal Servers.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Sollte während einer der Phasen ein Fehler festgestellt werden, führt dieser zum Abbruch und zur Wiederholung der Messung.

Während aller Phasen werden Messdaten erhoben und kontrolliert, aber nur die Messdaten, deren Beginn und Ende vollständig in die Messphase fallen, werden zur Auswertung herangezogen. Die Antwortzeiten des Terminal Servers werden von den T4USPlayback’s registriert und an den Controller gemeldet.

Die Performance Counter des Servers werden vom Controller abgefragt. Die Daten des Terminal Servers im Zeitraum der Messphase werden ausgewertet. Die Daten der anderen beteiligten Systeme wie Lastgeneratoren, Controller und Infrastruktur-Server werden zur Kontrolle überwacht, um sicherzustellen, dass diese nicht überlastet sind oder dass eine Messung durch Seiteneffekte ungültig i st.

Alle Messungen des Terminal Server Sizing Guides V3.0 wurden mit diesem Typ der Messung durchgeführt.

Messung mit variabler Benutzeranzahl

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.

Während der gesamten Messung werden die Antwortzeiten des Terminal Servers von dem T4US Controller überwacht. Dieser vergleicht jeden einzelnen Messwert mit einem gespeicherten Referenzwert, der aus einer vorhergehenden

Referenzmessung ermittelt wurde. Als Maßgabe für die Überlastung des

Servers werden bestimmte Ende-Kriterien konfiguriert. Als Resultat der Messung erhält man eine Benutzeranzahl (»Score«). Bei der Messung mit variabler

Benutzeranzahl wechseln sich Phasen, bei denen neue Terminal Server Benutzer hinzukommen, mit Phasen ab, in denen die Benutzeranzahl stabil bleibt. Während der einzelnen Startphasen nimmt nach und nach ein Teil der T4USPlayback’s auf Befehl des T4USControllers die Arbeit auf. Hierbei verteilt der T4US-Controller den Start der Skripte gleichmäßig auf die Startphase. Eine Startphase ist beendet, wenn alle Skripte der T4US-Playback’s gestartet sind. Während der jetzt folgenden »Steady State« Phase ist die Messung in einem stabilen Zustand, es werden keine neuen Benutzer hinzugefügt. Die Startphasen und stabilen Phasen werden kontinuierlich wiederholt. Dabei können im frühen Zeitraum der Messung viele Benutzer schnell gestartet werden, während die Dauer der Startphasen im Verlauf der Messung immer weiter zunimmt, dadurch wird der Abstand der Benutzeranmeldung vergrößert. Durch diese Dehnung der Benutzeranmeldungen wird das Messergebnis genau er und reproduzierbar.

Sollte während der Messung ein Fehler festgestellt werden, führt dieser zum Abbruch und zur Wiederholung der Messung.

White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006

Die Performance Counter des Terminal Servers werden vom Controller abgefragt und über die gesamte Messphase ausgewertet. Die Daten der anderen beteiligten Systeme wie Lastgeneratoren, Controller und Infrastruktur-Server werden zur Kontrolle überwacht, um sicherzustellen, dass diese nicht überlastet sind oder dass eine Messung durch Seiteneffekte ungültig ist.

Alle Messungen des Terminal Server Sizing Guides ab Version 3.1 wurden mit diesem Typ der Messung durchgeführt.

Prozessorauslastung

Es ist insbesondere festzulegen, wann ein Server ausgelastet ist. Denn sicherlich lässt sich auf einem System, auf dem n Applikationen laufen, auch noch eine n+1-te starten. Aber es ist ja nicht zweckmäßig, einen Server beliebig zu überlasten. Dies würde nur ermitteln, wie »dehnbar« die Verwaltungstabellen des Betriebssystems sind. Vielmehr muss man ein Maß für stabiles Arbeiten des Systems finden. Ist dieses überschritten, so wird das System überlastet und wird instabil. Alle Windows Server Betriebssysteme bieten hierfür eine Vielzahl von Performance Countern, die Auskunft über den Systemzustand geben. Ein Indikator für die Aus- bzw. Überlastung des Systems ist die »Processor Queue Length«. Dieser Counter gibt an, wie viele Threads auf ihre Ausführung durch die CPU warten. Steigt dieser Counter signifikant und kontinuierlich an, so ist dies ein Hinweis auf eine Überlastung des Systems. Dabei ist zu bedenken, dass unabhängig von der Anzahl Prozessoren nur ein Counter für die Queue-Länge geführt wird. Auch bei einem hohen Wert für die Queue-Länge muss die prozentuale CPU-Auslastung nicht nahe 100% sein, auch bei niedrigerer CPUAuslastung von unter 50% kann es zum Ansteigen der Prozessor-Queue kommen. Dies tritt dann auf, wenn sich eine Vielzahl von Prozessen im Idle-Zustand befindet, ein Zustand, der beim Terminal Server-Szenario insbesondere durch eine Vielzahl von Benutzern erreicht wird, die im Prinzip nichts weiter tun, als eine Applikation offen zu halten (vgl. Kapitel »

Anzahl Prozesse«).

Reaktionszeit

Ein zweites Maß für die Stabilität des Servers ist die Antwortzeit, mit der ein Server auf Eingaben des Benutzers reagiert. Sie hängt natürlich unmittelbar mit Prozessor-Auslastung und Prozessor-Queue-Länge zusammen.

Bei den Messungen mit konstanter Benutzeranzahl wird der Terminal Server so weit belastet, bis die durchschnittliche CPU-Auslastung über 70% liegt, die Prozessor-Queue signifikant ansteigt oder die Antwortzeit der Applikation sich gegenüber einer Referenzzeit um mehr als 10% verlängert.

Um die Referenzzeit festzulegen, wird auf fünf Lastgeneratoren je eine Instanz des betreffenden Lastprofils gestartet und dreimal erfolgreich durchlaufen. Die Referenzzeiten sind hauptsächlich von den Wartezeiten innerhalb der Skripte begrenzt und unterscheiden sich nur minimal von System zu System. Die Referenzzeiten selbst werden nicht verwendet, um die Leistungsfähigkeit des betreffenden PRIMERGY Systems zu dokumentieren, sondern nur, um die Verlängerung der Antwortzeiten zu berechnen.

Um die Antwortzeiten zu bestimmen, wird aus allen Messdaten der einzelnen Messpunkte, die die Clients während der Messphase ermitteln und an den T4US-Controller senden, der Durchschnitt gebildet und mit den Referenzzeiten verglichen.

Da von allen Messwerten während der Messphase der Durchschnitt gebildet wird, ist der Prozentsatz, um den sich die Antwortzeiten verschlechtern dürfen, mit 10% nicht sehr hoch.

Bei einer Messung mit konstanter Benutzeranzahl wird die Anzahl Benutzer vorgegeben, mit der der Terminal Server während der Messung arbeitet, und erst nach Durchlauf der Messung kann festgestellt werden, ob der Terminal Server diesen Anforderungen noch gewachsen war oder nicht.

+ 47 hidden pages