Terminal Server Sizing Guide Ausgabe 3.3 Dezember 2006 Seiten 68 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.
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.
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.
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.
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.
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.
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 Anwendungslast.
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.
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.
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.
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.
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.
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 bekanntesten sind: Terminal Server Scalability Planning Tool CSTK • • • • • • • • • • • • • • • • • CitraTest • • • LoadRunner for Citrix • • • • • • • • • • • • • Eine Lastsimulator-Suite von Microsoft (http://www.microsoft.com), die Bestandteil des Windows Server 2003 Resource Kit ist.
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.
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.
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.
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.
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.
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.
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.
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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Bei den Messungen mit variabler Benutzeranzahl wird der Terminal Server so weit belastet, bis sich die Antwortzeit der Applikation gegenüber einer Referenzzeit so weit verschlechtert, dass sie den vorgegebenen Regeln nicht mehr genügt.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Ressourcenbedarf In diesem Dokument wird Terminal Server sowohl unter dem 32-bit Betriebssystem »Windows Server 2003 R2« als auch unter dem 64-bit Betriebssystem »Windows Server 2003 R2 x64« untersucht. Die 32-bit und 64-bit Versionen von Windows Server 2003 R2 basieren dabei auf der gleichen Code-Basis und sind daher direkt vergleichbar.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Rechenleistung Die Rechenleistung eines Systems hängt von den Prozessoreigenschaften und der Anzahl Prozessoren ab. Prozessortyp Für Intel-kompatible Server steht heute eine Vielzahl an Prozessorvarianten zur Verfügung, die heute in den PRIMERGY Systemen eingebaut werden: AMD Opteron, Intel Celeron, Intel Pentium 4, Intel Pentium D, Intel Pentium M, Intel Xeon Prozessor und Intel Xeon Prozessor MP.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Taktfrequenz Die Prozessorlinien gibt es wiederum in verschiedenen Leistungsstufen. Abhängig vom Prozessormodell gibt es bei Intel Prozessoren Taktfrequenzen von 1 GHz bis heute 3.8 GHz und die Geschwindigkeit des Front-Side-Busses reicht von 133 MHz bis derzeit 1333 MHz. Die CPU-Taktfrequenz sagt heutzutage allerdings nicht mehr unbedingt etwas über die Rechenleistung aus.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Pentium 4 Der Pentium 4 Prozessor findet in den PRIMERGY Servern mit einem CPUSockel Verwendung, wie zum Beispiel PRIMERGY TX150 S2, PRIMERGY TX150 S3 oder PRIMERGY RX100 S3, wobei nicht alle Prozessoren der Pentium 4Klasse in allen PRIMERGYs verwendet werden. Bei dieser CPU-Generation gibt es derzeit Exemplare mit 1 MB und 2 MB Second Level Cache (SLC).
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Xeon (Single-Core Xeon für 2-Socket-Systeme) Untersucht man einen 2-Socket PRIMERGY Server, hier eine PRIMERGY RX300 S2 mit jeweils einem oder zwei Xeon Single-Core Prozessoren, erkennt man wieder die Leistungssteigerung durch die CPU Frequenz. Beim System mit einer CPU wird in diesem Beispiel eine Frequenzsteigerung um ca. 7% in eine um ca. 2.5% höhere Benutzeranzahl umgesetzt.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Dual-Core Xeon (für 2-Socket-Systeme) Die Unterscheidung erfolgt bei neueren Xeon Prozessoren über die Prozessornummer. Als Dual-Core Prozessoren für die 2-Socket-Systeme gibt es folgende Prozessortypen: • Xeon • Xeon 50xx • Xeon 51xx 2.8 GHz 3 - 3.73 GHz 1.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Xeon MP (Single-Core, ab 4-Socket-Systemen) Bei der PRIMERGY RX600/TX600-Systemreihe mit jeweils einem, zwei und vier Prozessoren kann man die Skalierung über die Taktfrequenz, Cachegröße und Prozessoranzahl beobachten. Die Performance steigt erwartungsgemäß beim Hinzufügen weiterer Prozessoren. Jedoch ist die Skalierung über die Frequenzen beim Monoprozessorsystem besser als bei den Multiprozessorsystemen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Dual-Core Xeon (ab 4-Socket-Systemen) Die multiprozessorfähigen Dual-Core Xeon Prozessoren werden in der PRIMERGY RX600 S2 und PRIMERGY RX600 S3 eingesetzt. Unter einem 64-bit Windows Server 2003 wurden diese Prozessoren in ihrer Skalierung vermessen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 AMD Opteron Der Rackserver PRIMERGY RX220 und der Blade Server PRIMERGY BX630 sind mit AMD Opteron Prozessoren ausgestattet. Diese gibt es als Single-Core und als Dual-Core Varianten, wobei die Dual-Core CPU die gleiche Charakteristik hat wie die Single-Core CPU. So hat jeder Prozessorkern 1 MB SLC, und auch die Frequenzabstufungen sind die gleichen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Front-Side-Bus Im Folgenden wird der Einfluss des Front-Side-Bus(FSB)-Taktes bei Intel-basierten Servern untersucht. Über den Front-Side-Bus wird die Kommunikation zwischen dem Prozessor und der so genannten Northbridge abgewickelt, einem Bestandteil des Chipsatzes, der wiederum mit anderen Komponenten wie zum Beispiel dem Arbeitsspeicher oder dem PCI-Bus verbunden ist.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Da beim 64-bit Betriebssystem mehr Daten verarbeitet werden müssen, hat die Größe des CPU-Caches hier einen größeren Einfluss. Das gleiche PRIMERGY System wurde wahlweise mit Xeon Prozessoren mit 1 MB oder mit 2 MB SLC ausgestattet. Wie nebenstehende Grafik zeigt, führt eine Verdoppelung des Caches auf beiden Plattformen zu einer höheren Performance.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Hyper-Threading Die meisten Intel Prozessoren der aktuellen Generationen unterstützen Hyper-Threading. Bei den heute angebotenen Prozessortypen wird eine Prozessorfamilie meist durchgängig entweder mit oder ohne HyperThreading angeboten. Der Vorteil von Hyper-Threading gegenüber dem klassischen Multiprozessing war ein Mehr an Leistung bei geringeren Kosten.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Anzahl Prozessoren 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). Alle Ressourcen einer CPU sind mehrfach, d.h. auf jeder physikalischen CPU vorhanden, so dass mehrere Prozesse gleichzeitig ausgeführt werden können.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Verhalten bei hoher CPU-Last 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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. Kennt man jedoch den Speicherbedarf der Anwendung bei einem Benutzer, so lässt sich leicht der Gesamt-Speicherbedarf berechnen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Wie bereits oben erwähnt, belegt ein Terminal Server Benutzer auf einem 64bit System mehr Arbeitsspeicher als auf einem 32-bit System. Die Anwendung, mit der der Terminal Server Benutzer arbeitet, ist in beiden Fällen Microsoft Word, welches heute nur als 32-bit Version existiert. Die Microsoft Terminal Services liegen als Bestandteil des Betriebssystems in einer 64-bit Version vor.
White Paper | Sizing Guide | Terminal Server Sizing Guide Wenn die Prozessor-Leistung nicht mehr ausreicht, dann können die angeschlossenen Clients nicht mehr mit akzeptabler Antwortzeit bedient werden, auch wenn noch ausreichend Arbeitsspeicher vorhanden ist. Dies wird durch nebenstehende Grafik am Beispiel der PRIMERGY RX200 verdeutlicht. Ausgabe: 3.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Wie bereits erwähnt, hilft sich ein System, das mit zu wenig Hauptspeicher ausgestattet ist, indem es nicht benötigte Daten auf die Festplatte auslagert. Das Windows Betriebssystem und die laufenden Anwendungen belegen mehr Speicher, wenn noch genügend Hauptspeicher zur Verfügung steht. Erst wenn der freie Speicher unter einen bestimmten Schwellwert fällt, wird »aufgeräumt«.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 • »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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Prinzipiell sind alle Festplatten für den Einsatz mit Terminal Server geeignet. Selbst relativ langsame Festplatten stellen bei den Terminal Server Anwendungen keinen ernstzunehmenden Engpass da, wenn die verwendete Festplatte auf die Anzahl der mit dem Terminal Server arbeitenden Benutzer abgestimmt ist.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Netzwerk Eine wichtige Rolle im Terminal Server-Umfeld kommt dem Netzwerk zu. Die Thin-Clients eines Terminal Servers dürften häufig – aus Ihrer Entstehungsgeschichte als ältere kleine PC-Systeme – über 10-MbitEthernet oder noch langsamere PPP-Anbindungen verfügen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Stellt man die während einer Messung aus Sicht des Clients gesendeten und empfangenen Daten des Terminal Servers grafisch dar, so sieht man, dass die Daten, die pro simulierten Benutzer über das Netzwerk übertragen werden, linear skalieren. Diese lineare Skalierung kann bei allen PRIMERGY Systemen beobachtet werden. Erst unter Hochlast wird diese gleich bleibende Steigerung der Datenrate nicht mehr erreicht.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Benutzerverhalten Neben der Server Hardware, die in den vorherigen Kapiteln ausführlich diskutiert wurde, gibt es noch weitere Größen, die das Verhalten des Terminal Servers entscheidend beeinflussen. Die Arbeitsweise der Benutzer spielt dabei eine wichtige Rolle. Dies wurde am Beispiel der Eingabegeschwindigkeit untersucht.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Betriebssystem Neben der Server Hardware, die in den vorherigen Kapiteln ausführlich diskutiert wurde, gibt es noch weitere Größen, die das Verhalten des Terminal Servers entscheidend beeinflussen. Eine davon ist das Betriebssystem, das heute entweder in der 32-bit Variante oder in der 64-bit Variante eingesetzt wird.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 64-bit Heute sind zwei verschiedene 64-bit Plattformen etabliert, die sich grundlegend unterscheiden. Intel Itanium (IA64) Bereits seit langem sind 64-bit PRIMERGY Systeme auf Basis von Intel Itanium und Itanium-2 Prozessoren verfügbar. Diese Prozessoren sind jedoch nicht Code-kompatibel zu 32-bit-Anwendungen (x86).
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Nutzbarer Speicher Der wesentliche Unterschied zwischen 32-bit und 64-bit liegt in der Menge des nutzbaren Speichers.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 64-bit Einer der wesentlichen Vorteile von 64-bit ist der erweiterte Adressraum. Heutige Server können problemlos mit mehr als 4 GB Arbeitsspeicher ausgestattet werden. Dieser ist auf 32-bit Systemen nur mit erhöhtem Aufwand adressierbar. Mit 64-bit Windows können theoretisch direkt 264 Bytes = 16 Exabyte adressiert werden.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Physical Address Extension (PAE) Auf einem 32-bit System mit einem 32-bit Adressraum können nur 4 GB Arbeitsspeicher adressiert werden. Um diese Grenze zu überwinden und mehr Speicher zu nutzen, kann auf dieser Plattform PAE eingeschaltet werden. Wenn ein Terminal Server durch die Rechenleistung und nicht durch den Arbeitsspeicher begrenzt wird, kann PAE einen leicht negativen Einfluss haben.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Terminal Server Version Microsoft Terminal Server vs. Citrix Presentation Server Welche Unterschiede gibt es zwischen den Microsoft Terminal Services und Citrix Presentation Server? Die größten Unterschiede zwischen den Microsoft Terminal Services und Citrix Presentation Server liegen im Netzwerkbereich. Dies wurde bereits im Kapitel »Netzwerk« behandelt.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Anwendungen Auch die Version und bestimmte Einstellungen der Anwendungen, die unter dem Terminal Server zur Verfügung gestellt werden, können die Leistungsfähigkeit des Terminal Servers beeinflussen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Vergleich der Messwerkzeuge Wie bereits oben erwähnt, können verschiedene Messwerkzeuge als Ergebnis verschiedene Benutzerzahlen liefern, da die Benutzerprofile und Messmethoden unterschiedlich sind. Aber obwohl die absoluten Zahlen verschieden sind, kann man die relative Skalierung des Server-Systems vergleichen.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Die Testprogramme beinhalten die folgenden Automatisierungswerkzeuge: • Robosrv.exe ist das Werkzeug, das die Server-Seite der Lastsimulation steuert. Zusammen sorgen RoboServer und RoboClient für die Automatisierung von Server und Client. RoboServer wird typischerweise auf dem Test Controller installiert und muss laufen, bevor eine Instanz von RoboClient gestartet werden kann.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Die Antwortzeit ist die Zeit von dem Tastendruck bis zur Anzeige der Zeichenfolge. Um die Antwortzeit genau messen zu können, wird der Messwert anhand von zwei Ausgangszeitwerten t1 und t2 aus einer Referenzzeitquelle berechnet bevor und nachdem ein Tastendruck gesendet wurde.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Auf dem PRIMERGY TX600 System wurde eine Messreihe aufgesetzt. Wie nebenstehende Grafik zeigt, ist der CPU-Skalierungsfaktor von einer CPU auf zwei CPUs immer 1.6, unabhängig davon, welches Lastprofil benutzt wird. Die Skalierung von zwei auf vier Prozessoren ist für beide Messszenarien 1.25. Die absoluten Benutzerzahlen sind jedoch unterschiedlich.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Resümee 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.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 In dieser Darstellung wird die höchste erreichbare Benutzeranzahl jedes PRIMERGY Systems als Maximalwert verwendet, die mit einer optimalen Hardwarekonfiguration und dem jeweils besten Betriebssystem (32-bit oder 64-bit) erreicht wurde.
White Paper | Sizing Guide | Terminal Server Sizing Guide Ausgabe: 3.3 | Dezember 2006 Literatur [L1] Allgemeine Informationen zu Produkten von Fujitsu Siemens Computers http://www.fujitsu-siemens.de [L2] Allgemeine Informationen zur PRIMERGY Produktfamilie http://www.PRIMERGY.de [L3] PRIMERGY Benchmarks - Performance Reports und Sizing Guides http://www.fujitsu-siemens.de/products/standard_servers/primergy_bov.html [L4] Terminal Server Sizing Guide - 64-bit Technologie http://extranet.