Terminal Server Sizing Guide

Größe: px
Ab Seite anzeigen:

Download "Terminal Server Sizing Guide"

Transkript

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

2 Einführung PRIMERGY»PRIMERGY«ist seit 1995 der Markenname für die sehr erfolgreiche Industrie-Standard-Server-Familie aus dem Hause Fujitsu Technology Solutions. Es handelt sich dabei um eine bei Fujitsu Technology Solutions entwickelte und produzierte Produktlinie mit Systemen für kleine Arbeitsgruppen bis hin zu Lösungen für Großunternehmen. Zu den PRIMERGY Modellen gehören neben wirtschaftlichen 1-Socket Systemen der Einstiegsklasse auch leistungsstarke Dual-Socket Systeme als Rack und Tower Modelle bis hin zu den Mehr-Sockel Systemen und Blade Servern. Als Herzstück werden Intel Prozessoren der obersten Leistungsklasse verwendet. Weitere detaillierte Informationen über die aktuellen Systeme findet man bei Fujitsu Technology Solutions im Internet. Server-based Computing Windows Terminal Server Terminal Server ist eine Form des Server-based Computing auf Basis von Microsoft Windows Server Betriebssystemen. Das klassische Server-based Computing ist eine Systemarchitektur, bei der Microsoft Windows Client-Anwendungen zu 100 Prozent auf dem Server installiert und ausgeführt werden. Von dort erfolgt nicht nur deren Einsatz, sondern auch deren Wartung, Verwaltung und Support finden direkt auf dem Server statt. Lediglich die Benutzeroberfläche, d.h. die Bildschirm-, Maus- und Tastatur-Informationen werden zwischen Client und Server übertragen. Der Benutzer kann so von fast beliebigen Clients aus, auch nicht Windows basierten, über einen solchen Terminal Server sofort auf Windows Anwendungen zugreifen, ohne dass die jeweiligen Applikationen erst zum Client übertragen, dort gestartet, oder gar auf lokalen Massenspeichern vorgehalten werden müssten. Wird ein Client ausschließlich in diesem Server-based Szenario eingesetzt, so hat er hinsichtlich Speicher- und Plattenausstattung wesentlich geringere Anforderungen als ein traditioneller Client, man spricht daher auch von so genannten Thin-Clients. Vorteile des Server-based Computing sind die Kostenreduktion durch bessere Server-Auslastung sowie bessere Administration durch Zentralisierung von Anwendungen. Terminal Server Data Store Ein Terminal Server kann prinzipiell für alle Arten von Applikationen eingesetzt werden. Wo bislang kleine Rechner oder Terminals für einfache Dateneingabe bzw. -abfrage Verwendung fanden, können mit dem Terminal Server moderne Anwendungen in ein bestehendes Umfeld integriert werden. Eine Terminal Server Farm ist ein Zusammenschluß von Terminal Servern, die eine gemeinsame Verwaltungseinheit, Data Store genannt, besitzen. Diese werden gemeinsam administriert. Die Zuordnung von Benutzern zu Servern und Applikationen kann statisch erfolgen oder dynamisch nach Auslastung der Terminal Server (Load Balanced Server Farm). Fujitsu Technology Solutions 2009 Seite 2 (46)

3 Lösungen Das Konzept des Server-based Computing hat seit 2000 unter dem Namen»Terminal Services«einen festen Platz in Server-Produkten der Microsoft Windows 2000 Server und Windows Server 2003 Produktlinie. Selbst in dem Client-Betriebssystem ab Windows XP Professional steht in begrenztem Umfang der Terminal Service unter dem Namen»Remote Desktop«zur Verfügung. Von einem beliebigen Windows Client kann somit auf das entfernte System zugegriffen werden, wobei die Anwendungen komplett auf dem Remote-System ablaufen. Das unterliegende Protokoll wird als»remote Desktop Protocol«(RDP) bezeichnet. Auch wenn seit dem aktuellen Betriebssystem Windows Server 2008 die Terminal-Dienste nicht mehr»terminal Services«heißen, sondern in»remote Desktop Services«(RDS) umbenannt wurden, wird in diesem Papier der Einfachheit halber weiterhin der Name»Terminal Services«verwandt. Die Remote Desktop Services unter Windows Server 2008 sind um Funktionen erweitert, die die Verwaltung von Terminal Server Anwendungen (RemoteApp), den Webzugriff (Remote Desktop Web Access) auf diese sowie den sicheren Zugang zu den Terminal-Diensten über das Internet (Remote Desktop Gateway) betreffen. Der größte Player im Terminal Server Umfeld ist das US-amerikanische Softwarehaus Citrix. Sein weiterentwickeltes Produkt»Citrix XenApp«(früher»Citrix Presentation Server«, davor»citrix Metaframe«) dient der virtuellen Bereitstellung und dem Managen von Anwendungen insbesondere in großen Server- Umgebungen. Citrix XenApp basiert auf Microsoft Windows Terminal Services. Es bietet Erweiterungen und zusätzliche Funktionalitäten in den Bereichen der zentralen Verwaltung und Überwachung großer Server- Farmen, sowie Unterstützung in stark heterogenen IT-Umgebungen. Im Gegensatz zu Microsoft Terminal Server benutzt Citrix das eigenentwickelte, effiziente ICA-(Independent Computing Architecture) Protokoll zur Datenübertragung zwischen Client und Server. Trends Neben dem Konzept des Server-based Computing hat sich in den letzten Jahren das Konzept der Virtualisierung in den unterschiedlichsten Formen durchgesetzt. Server-Virtualisierung hat ähnlich wie Terminal Server Lösungen die Aufgabe, die Auslastung physikalischer Server zu erhöhen und Betriebskosten sowie Wartungs- und Administrationsaufwände zu verringern. Unter Applikations-Virtualisierung versteht man den Ansatz, Anwendungen von ihrer Umgebung zu isolieren, so dass Konflikte mit anderen Programmen oder dem Betriebssystem vermieden werden. Die Terminal Server Lösung von Citrix,»Citrix XenApp«realisiert Applikations-Virtualisierung durch die zwei Funktionalitäten: Application Streaming und Application Isolation. Das Application Streaming ermöglicht es, Anwendungen zum Client Device zu bringen und dort in einer geschützten und isolierten Umgebung ablaufen zu lassen. Die Applikations-Virtualisierungslösung von Microsoft findet sich in einem von Windows Terminal Server separaten Produkt»Microsoft Application Virtualization«(bekannt auch als App-V, früher SoftGrid). Eine der größten Barrieren bei der Einführung einer Terminal Server Lösung ist die Tatsache, dass allen Benutzern die gleiche Arbeitsplatzoberfläche bzw. die gleichen Anwendungen zur Verfügung gestellt wurden. Eine komplette Individualisierung, wie sie der Benutzer von seinem traditionellen Arbeitsplatz aus gewohnt ist, ist nicht möglich. Dieses wird bei der Desktop-Virtualisierung umgangen. Sie ist eine Zusammenführung der beiden Konzepte Virtualisierung und traditionelles Server-based Computing und findet sich im Konzept des von VMware zuerst eingeführten Begriffs des»virtual Desktop Infrastructure«(VDI) wieder. In einer virtuellen Desktop-Umgebung sind die Desktops einzelner Benutzer in jeweils einer virtuellen Maschine eines Servers»gehostet«. Damit hat jeder Benutzer sein eigenes Desktop-System. Zugriff auf diesen virtuellen Arbeitsplatz kann z.b. über Protokolle wie RDP oder ICA erfolgen. Auch eine traditionelle Terminal Server Umgebung bietet die Möglichkeit, einem Benutzer in einer Session einen Desktop zur Verfügung zu stellen, allerdings entfällt die Möglichkeit der Personalisierung, wie sie bei einem traditionellen PC-Arbeitsplatz möglich wäre. Eine Diskussion welches Konzept VDI oder Terminal Server in welchem Umfeld mehr Vorteile bezüglich Kosten und Funktionalität bietet und sich damit durchsetzen wird, würde den Rahmen dieses Papiers sprengen, bleibt aber weiterhin spannend. Fujitsu Technology Solutions 2009 Seite 3 (46)

4 Dimensionierung Methoden Bei der Skalierung das ist der Prozess, das System an die benötigte Leistung anzupassen werden zwei Methoden unterschieden: Scale-Up bezeichnet den Einsatz zunehmend größerer Server Systeme. Scale-Out bezeichnet den Einsatz von vielen kleineren Systemen, die sich die Arbeit teilen. Beim Scale-Up wird die Leistung eines Terminal Servers durch den Einsatz leistungsfähigerer Hardware, also insbesondere Rechenleistung und Arbeitsspeicher, erhöht. Es ist eine adäquate Skalierungsmethode, wenn eine überschaubare Anzahl an Benutzern zu bedienen ist. Diesem Skalierungsprozess sind Grenzen durch die maximale Leistungsfähigkeit des Server-Systems oder auch durch die Softwarearchitektur gesetzt. Insbesondere bei einem 32-bit Windows Betriebssystem ergeben sich Limitierungen im Speicherbereich, die dazu führen können, dass die Rechenleistung moderner Prozessoren nicht mehr voll ausgeschöpft werden kann. Genauer wird darauf im Kapitel Betriebssystem eingegangen. Beim Scale-Out werden viele Server zu einer Gruppe zusammengefasst. Man kann drei Varianten unterscheiden: 1. Just a Bunch of Servers»Just a Bunch of Servers«ist eine lose Ansammlung von Servern, hier Terminal Servern, denen dedizierte Benutzergruppen oder Applikationen zugeordnet sind. Es findet jedoch unter den Terminal Servern kein Informationsaustausch und kein Lastenausgleich statt. Der Vorteil dieser Architektur ist die sehr einfache Erweiterbarkeit. Nachteilig ist, dass durch fehlenden Lastenausgleich Server-Leistung ungenutzt bleiben kann. Der administrative Aufwand ist recht hoch, da jedes System separat verwaltet werden muss. Dennoch wird diese Variante des Scale-Outs in der Praxis in kleineren Konfigurationen eingesetzt. 2. Server-Farm Eine Terminal Server Farm ist ein Zusammenschluß von Terminal Servern, die eine gemeinsame Verwaltungseinheit besitzen. Die Zuordnung von Benutzern zu Servern und Applikationen erfolgt meist statisch. Vorteil gegenüber der»just a Bunch of Servers«Variante ist die vereinfachte Administration der Server. Auch diese Variante des Scale-Outs wird in der Praxis sehr häufig eingesetzt. 3. Load-balanced Server-Farm Bei einer»load-balanced Server-Farm«werden die einzelnen Terminal Server zu einer logischen Einheit zusammengefasst. Wird von einem Client eine Session initiiert, so wird diese von einem Load Balancer nach bestimmten Mechanismen an den Server mit der momentan geringsten Auslastung delegiert. Neben der besseren Auslastung der Terminal Server bietet das Load Balancing auch eine gewisse Redundanz. Aktuelle Terminal Server Softwarelösungen, sowohl von Microsoft als auch Citrix, bieten umfangreiche Möglichkeiten des Load Balancing. Terminal Server Load Balancer Session List Im Folgenden beschäftigen wir uns mit einem Scale-Up Scenario, d.h. der Dimensionierung eines einzelnen Terminal Servers. Fujitsu Technology Solutions 2009 Seite 4 (46)

5 Kenngröße»Benutzer«Vor jeder Implementierung eines Applikations-Servers steht immer die gleiche Frage: Welches ist die passende Hardware für die geforderte Aufgabe? Natürlich möchte man dabei ein möglichst optimales System, welches weder für die Anforderungen zu klein noch (aus Kostengründen) total überdimensioniert ist. Die Frage ist also: Wie findet man ein wohl dimensioniertes System? Die einzige meist vorliegende Kenngröße ist die Anzahl Benutzer, die mit dem System arbeiten sollen. Die typische Frage, die also zumeist auftritt, ist:»welches PRIMERGY Modell benötigt man für einen Terminal Server zur Unterstützung einer bestimmten Anzahl von Benutzern?«. Optimalerweise würde man als Antwort eine handliche Tabelle erwarten, aus der anhand der Benutzerzahl in der einen Spalte unmittelbar aus der zweiten Spalte das ideale PRIMERGY System abgelesen werden kann. Leider gibt es eine solche Tabelle nicht auch wenn mancher Mitbewerber dies dem Kunden mit bunten Web-Seiten suggeriert. Die Antwort auf die scheinbar so einfache Frage ist doch wesentlich komplexer, denn sie enthält eine große Unbekannte, und die ist der Benutzer. Ein Benutzer ist, auch wenn dies viele vielleicht wünschen, keine standardisierte und berechenbare Größe, sondern ein Individuum mit unterschiedlichem Arbeitstempo und Arbeitsverhalten. Das Arbeitstempo z.b. bestimmt mit welcher Häufigkeit Eingaben gemacht werden und hat damit direkten Einfluss auf die Belastung des Terminal Server Systems. Hinzu kommen unterschiedliche Arbeitsaufgaben, die in unterschiedlichen Anforderungen an ein Computersystem resultieren. Ein Benutzer, dessen Aufgabe aus Abfragen an ein Lagerhaltungssystem besteht, wird eine andere Last auf einem Computersystem erzeugen, als ein Benutzer, dessen Aufgabe es ist, eine grafische Werbebroschüre zu entwerfen. Nicht zu vernachlässigen ist der mit der Zeit steigende Ressourcenverbrauch der Applikationen durch deren Weiterentwicklung, z.b. im Bereich 3D-Grafik oder Multimedia/Videoanwendungen. Die folgende Tabelle zeigt eine Einteilung der Benutzer in Gruppen nach ihrem Benutzerverhalten und Belastungsprofil. Heavy Medium Light Knowledge Worker Process Worker Data Entry Worker nutzt gleichzeitig mehrere verschiedene Anwendungen gibt Daten mäßig schnell ein führt komplexere Operationen aus arbeitet zu einer Zeit intensiv mit einer Anwendung gibt schnell viele Daten ein arbeitet kontinuierlich arbeitet zu einer Zeit nur mit einer Anwendung gibt wenig Daten ein längere Pausen zwischen den Eingaben Wie im Kapitel Lastprofil noch erläutert wird, wurde bei den Messungen für das vorliegende Dokument das Verhalten eines Medium Benutzers angenommen. Benutzersimulation Bei Leistungsmessungen werden generell keine realen Benutzer verwendet, sondern die Benutzer werden mit Hilfe von Computern, so genannten Lastgeneratoren, und einer speziellen Software simuliert. Dabei wird von einem physikalischen Lastgenerator zumeist eine Vielzahl von logischen Benutzern simuliert, so dass je nach Lastgenerator einige zig oder hundert Benutzer simuliert werden können. Die folgende Abbildung zeigt eine typische Simulationsumgebung. Simulations- Netzwerk SUT- Netzwerk Controller Lastgeneratoren System under Test (SUT) Infrastruktur- Server Fujitsu Technology Solutions 2009 Seite 5 (46)

6 Der Controller ist die zentrale Steuerkonsole, die die Simulation steuert und überwacht. Über ein Simulations-Netzwerk ist dieser mit den Lastgeneratoren verbunden. Jeder Lastgenerator kann eine Vielzahl von Benutzern simulieren. Die Lastgeneratoren erreichen das Testsystem (System under Test (SUT)) über ein zweites Netzwerk, in dem sich auch noch ein Infrastruktur-Server befindet. Dieser liefert dem SUT die notwendigen Dienste, aber er wird selbst nicht vermessen. Unterschiedliche Benutzergruppen, wie oben diskutiert, werden von Lastsimulatoren zumeist durch verschiedene Lastprofile, im Terminal Server Umfeld auch Skript genannt, berücksichtigt. Bei der Benutzersimulation unterscheidet man die Begriffe»Lastgenerator«,»Client«und»Benutzer«. Im weiteren Verlauf wird als»lastgenerator«die Hardware bezeichnet. Ein»Client«ist der Terminal Server Client, von dem einer oder mehrere auf dem Lastgenerator ausgeführt werden. Ein simulierter»benutzer«arbeitet innerhalb einer Terminal Server Sitzung. Interpretation Anders als bei anderen Benchmarks, wo es vom Hersteller der Applikation oder einem unabhängigen Gremium einen Benchmark und ein entsprechendes Reglement zur Durchführung gibt, wie z.b. bei Microsoft Exchange Server, SAP R/3, SPECweb oder TPC, gibt es für Terminal Server bis heute keinen standardisierten und akzeptierten Benchmark. Es existieren zwar verschiedene Produkte verschiedener Hersteller zur Benutzersimulation, aber es gibt kein standardisiertes Werkzeug, mit dem sowohl Microsoft als auch Citrix Terminal Server vermessen und verglichen werden können. Ergebnisse solcher Performance-Messungen verschiedener Hersteller oder Benchmark-Labore sind unter diesen Bedingungen natürlich nicht untereinander vergleichbar. Nur Messungen, die in gleicher Umgebung und mit vergleichbarem Lastprofil durchgeführt wurden, können auch sinnvoll verglichen werden. Weiterhin ist zu beachten, dass es sich bei den Terminal Server Sizing Messungen um Auswertungen in einer vereinfachten, idealisierten und standardisierten Umgebung handelt, um vergleichbare Bedingungen für alle Systeme zu schaffen. Zusätzliche Komponenten und Programme sind nicht installiert, und der Terminal Server wird bis an seine Leistungsgrenze belastet. In der Realität wird man Zusatzsoftware wie zum Beispiel einen Virenscanner installiert haben, oder man betreibt weitere Add-Ons der Terminal Server Software. Auch werden Terminal Server im Produktivbetrieb nicht bis an ihre Leistungsgrenze belastet. Vor diesem Hintergrund kann man also sagen: Obgleich die Einheit vieler Performance-Messungen»Anzahl Benutzer pro Server«ist, sollte man nur Ergebnisse von Performance-Messungen im gleichen Umfeld miteinander vergleichen. Sie sollten in erster Linie auch nur relativ betrachtet werden, also beispielsweise»ein System A ist doppelt so leistungsfähig wie ein System B«oder»die Verdopplung des Arbeitsspeichers resultiert in x% Leistungssteigerung«. Denn wie bereits im Kapitel Kenngröße»Benutzer«erläutert, ist ein Benutzer schwer zu quantifizieren, und ein synthetischer Benutzer muss nicht in allen Fällen mit einem realen Benutzer korrelieren. Fujitsu Technology Solutions 2009 Seite 6 (46)

7 Benchmark-Beschreibung Simulationswerkzeug: T4US Fujitsu Technology Solutions hat einen eigenen Lastsimulator, T4US, entwickelt, der unabhängig von dem verwendeten Terminal Server und ohne Einflüsse auf das zu testende System beliebige Benutzerprofile simulieren kann. Benutzeraktivitäten wie Tastatur- und Mauseingaben sowie Bildschirmausgaben können mit Hilfe des Aufzeichnungswerkzeugs T4US-Record in Echtzeit aufgezeichnet und in einem T4US-Skript gespeichert werden. T4US-Skripte werden während der Messung als Lastprofil verwendet. Benutzer bei der Arbeit T4US Record T4US Skript Der Lastsimulator von T4US besteht aus drei Komponenten. T4US-Control steuert und überwacht den gesamten Simulationslauf zentral und ermittelt Messwerte bereits während der Messung. 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 Controller Lastgenerator anhand der mit T4US- T4US T4US Record aufgezeichneten T4US Agent Play Terminal Control Server Skripte und überwacht die TS Client Bildschirminhalte des Terminal Server Clients. Durch hoch auflösende Timer wird so die Antwortzeit des Terminal Servers ermittelt. Auf jedem der Lastgeneratoren läuft ein T4US-Agent, der für die Kommunikation mit dem Controller zuständig ist, die Instanzen von T4US-Playback steuert und überwacht und die ermittelten Antwortzeiten zum Controller überträgt. Bei der Messung wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, kontinuierlich erhöht. Die Antwortzeiten des Terminal Servers werden vom T4US-Controller überwacht und mit gespeicherten Referenzwerten, die in einer vorhergehenden Referenzmessung mit nur wenigen Benutzern ermittelt worden sind, verglichen. Wenn sich die Antwortzeit der Anwendung so weit verschlechtert, dass sie den vorgegebenen Regeln nicht mehr genügt, wird die Messung beendet und man erhält die Benutzeranzahl als Resultat der Messung T4US Play T4US Play System under Test (SUT) TS Client TS Client SUT Lastprofil Wie im Kapitel Kenngröße»Benutzer«schon erläutert wurde, hängt die Belastung eines Terminal Servers stark vom Benutzer ab. Das Benutzerverhalten spiegelt sich bei einer Simulation im Lastprofil wider. Die hier beschriebenen Lastprofile simulieren das Verhalten eines»medium User«, der zu einer Zeit intensiv mit einer Anwendung arbeitet und kontinuierlich, schnell viele Daten eingibt. Der größte Teil der Messungen für den»sizing Guide«wurde mit dem Lastprofil V1 durchgeführt. Allerdings stellte sich heraus, dass durch verbesserte Leistung der zu vermessende Systeme (neue Prozessorgenerationen) der Benchmark mit diesem Lastprofil in eine Größenordnung kam, bei der die gemessene Benutzeranzahl durch die Anzahl Ab- und Anmeldevorgänge, also daraus resultierende Restriktionen im Betriebssystem, erreicht wurde und nicht mehr durch die Prozessorleistung des Systems. Das bedeutete, der Benchmark erreichte seine Grenzwerte schon ohne den Prozessor auszulasten. Verbesserte Prozessorleistung und damit auch Systemleistung konnten so nicht mehr gemessen werden. Fujitsu Technology Solutions 2009 Seite 7 (46)

8 Deshalb wurde ein neues Lastprofil V2 definiert. Die mit dem Lastprofil V2 erreichten maximalen Benutzerzahlen pro System sind natürlich nicht direkt vergleichbar mit den Benutzerzahlen des Lastprofils V1. Im Kapitel PRIMERGY Skalierung werden daher die Messergebnisse in Relation zueinander und nicht mehr absolut angegeben. Lastprofil V1 Im Lastprofil V1 dient Microsoft Word als Anwendung und der Benutzer schreibt einen bebilderten Text mit einer durchschnittlichen Eingaberate von 230 Anschlägen pro Minute. Des Weiteren beinhaltet das Lastprofil: Jeder Benutzer arbeitet unter einem eigenen Benutzerkonto. Die erste Anmeldung (Login) des Benutzers und der erste Start der Anwendung liegen außerhalb der Messstrecke. Jedoch meldet sich der Benutzer nach einmal getaner Arbeit am Terminal Server ab und für einen neuen Durchlauf wieder an. Da die Benutzer versetzt gestartet werden, ergibt sich so während der gesamten Messdauer ein kontinuierliches An- und Abmelden. Jeder Terminal Server Client (Benutzer) startet die Applikation aus seinem Desktop heraus, die Applikation wird bei jedem Skriptdurchlauf gestartet und beendet. Jeder Benutzer hat sein eigenes Verzeichnis, in dem die im Text verwendeten Bilder hinterlegt sind. So wird verhindert, dass alle Benutzer die gleichen Bilder-Dateien laden und sich diese nach kurzer Zeit alle im Server File Cache befinden. Jeder Benutzer schreibt bei jedem Skriptdurchlauf ein neues Dokument mit eindeutigem Namen. Nach erfolgreicher Erstellung wird das Dokument auf die Festplatte des Terminal Servers in ein benutzereigenes Verzeichnis gespeichert. Die durchschnittliche Eingabegeschwindigkeit liegt bei etwa 4 Zeichen bzw. Cursor-Bewegungen pro Sekunde. Allerdings finden nicht während des gesamten Durchlaufes Eingaben statt, denn es sind diverse, unterschiedlich lange Denkzeiten im Skript eingestreut, wie es einem natürlichen Arbeiten nahe kommt. Die Bildschirmauflösung ist 1024x768, die Farbtiefe ist 16-bit. Ein Durchlauf des Skripts inklusive Wartezeiten dauert ca. 16 Minuten. Lastprofil V2 Das neue Lastprofil V2 zeichnet sich dadurch aus, dass ein zu simulierender Benutzer mit verschiedenen Microsoft Office Anwendungen nacheinander arbeitet. Neben der Erstellung eines Microsoft Word Dokumentes wird auch eine PowerPoint-Präsentation kreiert. Ebenso werden Berechnungen auf einem neu angelegten Excel-Arbeitsblatt durchgeführt. Die Anzahl der An- und Abmeldevorgänge ist im Vergleich zum Lastprofil V1 reduziert. Im Schnitt meldet sich nur jeder sechste Benutzer zyklisch am Terminal Server ab und wieder an. Ebenso druckt durchschnittlich jeder sechste Benutzer ein Word-Dokument aus. Zusätzliche CPU-Last wird durch Verpacken und Entpacken von Dateien im Speicher erreicht. Die Tippgeschwindigkeit des simulierten Benutzers beträgt zwischen 330 und 440 Anschlägen pro Minute. Die weiteren Rahmenbedingungen gelten wie beim Lastprofil V1: Jeder Benutzer arbeitet unter einem eigenen Benutzerkonto. Jeder Terminal Server Client (Benutzer) startet die Applikation aus seinem Desktop heraus, die Applikation wird bei jedem Skriptdurchlauf gestartet und beendet. Jeder Benutzer hat sein eigenes Verzeichnis, in dem die im Text verwendeten Bilder hinterlegt sind. So wird verhindert, dass alle Benutzer die gleichen Bilder-Dateien laden und sich diese nach kurzer Zeit alle im Server File Cache befinden. Jeder Benutzer schreibt bei jedem Skriptdurchlauf ein neues Dokument mit eindeutigem Namen. Nach erfolgreicher Erstellung wird das Dokument auf die Festplatte des Terminal Servers in ein benutzereigenes Verzeichnis gespeichert. Die Bildschirmauflösung ist 1024x768, die Farbtiefe ist 16-bit. Fujitsu Technology Solutions 2009 Seite 8 (46)

9 Messmethode Zu einer Leistungsmessung gehört neben einem Simulationswerkzeug und einem möglichst realistischen Lastprofil ein Regelwerk, nach dem die einzelnen Messungen durchgeführt und bewertet werden. Im Folgenden wird das Regelwerk beschrieben, nach der die Messungen für diesen Sizing Guide durchgeführt wurden. Bei der Messung mit variabler Benutzeranzahl wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, nach einer voreingestellten Regel kontinuierlich erhöht, bis der Terminal Server überlastet ist. Dabei wird eine Überlastung des Servers durch die gemessenen Antwortzeiten im Vergleich zu vorher festgelegten Referenzzeiten definiert. Insgesamt müssen 90% der Messwerte innerhalb eines festgesetzten Rahmens liegen, 10% Ausreißer werden toleriert. Die so erreichte Benutzeranzahl ist das Ergebnis der Messung und wird als»score«bezeichnet. Die Referenzzeiten werden vorher aus den durchschnittlichen Antwortzeiten bei geringer Belastung (nur wenige simulierte Benutzer) ermittelt. Sie sind hauptsächlich von den Wartezeiten innerhalb der Skripte begrenzt und unterscheiden sich nur minimal von System zu System. Die Grafik veranschaulicht die Arbeitsweise des T4US Controllers bei der Auswertung der Messwerte. Die waagerechte Linie bei 1000 ms Antwortzeit ist die eingestellte Grenze, die 90% der Messwerte nicht überschreiten dürfen. Einige Ausreißer sind erlaubt, diese werden durch nachfolgende Werte innerhalb des erlaubten Bereichs kompensiert. Werden jedoch zu viele Ausreißer erkannt, gilt der Terminal Server als überlastet. Die Messung wird an dieser Stelle beendet. In diesem Beispiel ist der Score»76 Benutzer«. Das Bild zeigt außerdem, wie sich die Messwerte weiter verschlechtern würden, wenn noch weitere Benutzer hinzugefügt würden. Rechts von der senkrechten Markierung verlängern sich die Antwortzeiten für alle Benutzer erheblich. Auch wenn es von Microsoft und Citrix zahlreiche Artikel zur Optimierung von Betriebssystem- und Terminal Server gibt, so haben wir bei unseren Messungen doch gänzlich auf eine Optimierung verzichtet. Der Grund ist, dass viele dieser Einstellungen nur in bestimmten Umgebungen Sinn machen; in einem anderen Umfeld eingesetzt bewirken sie oft das Gegenteil. Da wir verschiedene PRIMERGY Systeme mit unterschiedlichen Systemkomponenten untersucht haben, wären die Ergebnisse nicht miteinander vergleichbar gewesen. Die einzigen Einstellungen, die verändert werden um alle PRIMERGYs den gleichen Testbedingungen zu unterwerfen, sind: Das Pagefile des Betriebssystems wurde auf eine feste Größe entsprechend des verwendeten Hauptspeichers eingestellt, um eine Fragmentierung zu vermeiden und damit für alle getesteten Server die gleichen Bedingungen vorliegen. Für Citrix musste die Grenze von 100 Benutzern pro Server, die durch das eingebaute Load Balancing vorgegeben wird (auch wenn die Terminal Server Farm aus nur einem Terminal Server besteht) aufgehoben werden. Fujitsu Technology Solutions 2009 Seite 9 (46)

10 Messumgebung Untersucht wurden alle aktuellen PRIMERGY Modelle, die für den Einsatz als typischer Terminal Server geeignet sind, in der folgenden Messumgebung: Controller für die Simulation Lastgeneratoren System under test (SUT) Infrastruktur- Server Simulationsnetzwerk SUT- Netzwerk switched 100 Mbit switched 100 Mbit PRIMERGY C200 T4US-Control ca. 40 PRIMERGY Dual Server Windows Server 2003 TS-Client T4US-Agent, T4US-Playback Jeder simuliert bis zu 12 Benutzer PRIMERGY Windows Server 2003 Windows Server 2008 Enterprise Edition PRIMERGY C200 Windows Server 2003 Active Directory Terminal Server Licensing Service Controller (T4US-Control): Auf dem Controller kam Windows Server 2003 Standard Edition zum Einsatz. Lastgeneratoren: Lastgeneratoren (PRIMERGY Dual Server) Die Lastsimulatoren liefen unter dem Betriebssystem Windows Server 2003 Standard Edition SP1. Die Messungen mit Lastprofil V2 wurden mit SP2 durchgeführt. Clients: Für den Zugriff auf den Terminal Server über das ICA-Protokoll wurde der Citrix Terminal Server Client (Programm Neighborhood mit 32-bit ICA-Client) verwendet (entweder Version aus»citrix MetaFrame XP Presentation Server«Feature Release 3 oder Version 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 des RDP-Clients enthalten, der das RDP-Protokoll V5.2 unterstützt. Die Messungen mit dem Lastprofil V2 wurden mit dem RDP-Protokoll V durchgeführt. Netzwerk: Die Anbindung der Lastsimulatoren an das SUT-Netzwerk erfolgte über ein 100 MBit-Ethernet-Netzwerk, wobei der Terminal Server über den Gigabit-Uplink angeschlossen war. Das Netzwerkprotokoll war TCP/IP. Terminal Server (System under Test): Die vermessenen PRIMERGY Server (System under Test) waren jeweils mit Windows Server 2003 Enterprise Edition ausgestattet. Die Terminal Services waren im Application Server Modus aktiviert. Die Messungen mit dem Lastprofil V2 wurden unter Windows Server 2008 durchgeführt. Bei den Messungen, bei denen ein Citrix Terminal Server vermessen wurde, war entweder Citrix MetaFrame Enterprise Edition mit Service Pack 3 und Feature Release 3 oder Citrix Presentation Server installiert. Die Terminal Server Farm bestand nur aus einem Terminal Server. Der Data Store befand sich lokal auf der Systemplatte des zu vermessenden Systems und war als Microsoft Access Datenbank realisiert. Auch die Dateien der Benutzer, die während der Messung gelesen und geschrieben wurden, lagen lokal auf dem Terminal Server. Die Benutzerprofile wurden standardmäßig auf dem Terminal Server gespeichert. Fujitsu Technology Solutions 2009 Seite 10 (46)

11 Infrastruktur-Server: Der Infrastruktur-Server stellt dem System under Test notwendige Dienste zur Verfügung, er selbst wurde nicht vermessen. Der Server wurde so dimensioniert, dass er keinen Engpass darstellt. Die Benutzerkonten der simulierten Benutzer wurden auf dem Active Directory Domain Controller angelegt. Ein Login fand immer gegen das Active Directory statt. Das Active Directory System dient gleichzeitig als DNS Server und beherbergt den Terminal Server Licensing Service. Der Infrastruktur-Server lief unter dem Betriebssystem Windows Server 2003 Standard Edition SP1. Fujitsu Technology Solutions 2009 Seite 11 (46)

12 Ressourcenbedarf Im Folgenden wollen wir diskutieren und anhand von Messergebnissen untermauern, welche Komponenten welchen Einfluss auf die Leistungsfähigkeit eines Terminal Server Systems haben. Dabei wird neben Aspekten des Betriebssystems auf die Performance-relevanten Faktoren eines Server-Systems wie Rechenleistung, Arbeitsspeicher, Disk-Subsystem und Netzwerk eingegangen. Im Anschluss daran wird das Umfeld, in dem ein Terminal Servers betrieben wird, betrachtet und auf Komponenten der Infrastruktur hingewiesen, die das Performance-Verhalten beeinflussen. Zum Abschluss wird das Verhalten eines Terminal Servers in beobachteten Überlastsituationen erläutert. Betriebssystem Microsoft Windows Server Betriebssysteme existieren bis Windows Server 2008 in zwei Varianten, der 32- bit- und der 64-bit-Variante. Auch wenn es zukünftige Betriebssysteme ab Windows Server 2008 R2 nur in der 64-bit-Variante geben wird, soll hier noch auf die Unterschiede und die damit möglichen Performance- Einbußen bei Terminal Server eingegangen werden. Voraussetzung für ein 64-bit-Betriebssystem ist eine 64-bit-Hardware-Plattform. Hier unterscheiden wir aktuell Intel Itanium (IA64) und x64. IA64 Prozessoren der IA64 Plattform sind nicht Code-kompatibel zu 32-bit-Anwendungen (x86); das hat zur Konsequenz, dass x86-anwendungen auf Itanium Systemen lediglich emuliert werden, was jedoch einen entsprechenden Performance-Verlust durch die Emulationsschichten bedeutet. Einen Terminal Server auf einer IA64 Architektur zu betreiben ist also nicht sinnvoll, da alle 32-bit-Anwendungen (z.b. Microsoft Office 2007) durch die Emulation sehr langsam laufen würden. Daher gibt es aktuell für Itanium-basierte Systeme weder Citrix Terminal Server Lösungen noch kann unter Windows Server 2008 das Feature Terminal Server konfiguriert werden. x64 Mit x64 werden die Architekturen bezeichnet, die 100% kompatibel zur x86-architektur sind und nur Erweiterungen für 64-bit bieten. Hierzu zählen der AMD Opteron mit der AMD64-Achitektur und die Intel Pentium und Xeon Prozessoren der neuesten Generation mit EM64T (jetzt Intel 64)-Architektur. Der Vorteil der x64 Plattform ist, dass 32-bit-Anwendungen, wie z.b. Microsoft Office direkt unter dem x64- Betriebssystem ausgeführt werden können. Das 64-bit Windows stellt das WoW64 (»Windows on Windows64«) Subsystem bereit, um einen reibungslosen Betrieb der 32-bit-Applikationen zu ermöglichen. Im WoW64 werden Zugriffe auf den Speicher, auf die Registry und auf das Dateisystem isoliert. Allerdings gilt für viele systemnahe Anwendungen und alle Anwendungen, die Treiberkomponenten enthalten, sie müssen speziell für x64-systeme angepasst werden, da sie im 32-bit-Modus nicht ablauffähig sind. Beispiele für Anwendungen, die speziell für 64-bit angepasst wurden sind Microsoft SQL Server oder Microsoft Exchange Server und die Terminal Server Produkte von Citrix. 16-bit-Anwendungen für DOS oder Windows sind generell nicht mehr ablauffähig, dies ist insbesondere ein Problem für Anwendungen mit einem 16-bit- Installer. Nachfolgende Tabelle gibt einen Überblick über relevante Systemplattformen und Windows Produkte und deren Anforderungen an Gerätetreiber und Anwendungen. Server-Plattform x86 x64 x64 Windows Produkt Windows Server 2003 R2 / Windows Server 2008 Standard Edition Enterprise Edition Datacenter Edition Windows Server 2003 R2 / Windows Server 2008 Standard Edition Enterprise Edition Datacenter Edition Windows Server 2003 R2 / Windows Server 2008 Standard x64 Edition Enterprise x64 Edition Datacenter x64 Edition Betriebssystem 32-bit 32-bit 64-bit Gerätetreiber 32-bit 32-bit 64-bit Anwendungen 32-bit 32-bit 32-bit und 64-bit Fujitsu Technology Solutions 2009 Seite 12 (46)

13 Limitierungen Der wesentliche Unterschied zwischen 32-bit- und 64-bit-Architektur liegt in der Größe des adressierbaren Speichers. Mit einer 32-bit-Architektur sind durch die Wortbreite des Prozessors maximal 2 32 Byte =4 GByte adressierbar, mit einer 64-bit-Architektur sind es bis zu 2 64 Bytes = 16 Exabyte (EB). Die nachfolgende Tabelle gibt einen Überblick über die Limitierungen der verschiedenen 32-bit und 64-bit Windows Produkte, die für Terminal Server sinnvoll eingesetzt werden können. Windows Produkt (WS = Windows Server) WS 2003 R2 / WS 2008 Standard Edition Enterprise Edition WS 2003 R2 x64 / WS 2008 x64 Standard Edition Enterprise Edition Anzahl Prozessoren Max. RAM gesamter virtueller Adressraum Virtueller Adressraum eines 32-bit-Prozesses Virtueller Adressraum eines 64-bit-Prozesses 4 GB 64 GB (mit PAE) 32 GB 2 TB 4 GB 16 TB 2 GB 2 GB 3 GB wenn mit /3GB Switch gebootet 4 GB wenn mit /LARGEADDRESSAWARE übersetzt wurde - 8 TB Paged Pool 470 MB / WS 2008 dynamisch 128 GB Non-Paged Pool 256 MB / WS 2008 dynamisch 128 GB System Page Table Entries ca. 900 MB / WS 2008 dynamisch 128 GB System Cache 1 GB / WS 2008 dynamisch 1 TB Bei dem 32-bit Windows ist der virtuelle Adressraum von 4 GB standardmäßig in 2 GB für das Betriebssystem und 2 GB für die Anwendungen unterteilt. In den 2 GB, die vom Betriebssystem verwendet werden, werden alle Datenstrukturen und Informationen des Kerns gehalten. Hier sind drei besondere Datenbereiche zu nennen: die Paged Pool Area, die System Page Table Entries (PTE) Area und der System File Cache. Speicher aus der Paged Pool Area wird von Kernel-Mode Komponenten angefordert, während die PTE Area für Kernel Stack Allocations verwendet wird. Im System File Cache werden Speicherabbilder von geöffneten Dateien gehalten. Diese Bereiche teilen sich einen Speicherbereich und die Grenze zwischen ihnen wird unter Windows Server 2003 beim Systemstart fest eingestellt. Wenn dem Betriebssystem während der Laufzeit in einem Bereich der Speicher ausgeht, kann dies nicht aus den anderen Bereichen ausgeglichen werden. Die Folge ist, dass keine neuen Benutzer mehr angemeldet werden können oder dass unerwartete Fehler auftreten. In 32-bit Windows Server 2008 wird der Kernel Address Space dynamisch verwaltet und die Speicherbereiche für Paged Pool, System Cache etc. können entsprechend der Arbeitslast wachsen oder schrumpfen. Begrenzt werden die Bereiche aber durch den aktuell verfügbaren virtuellen Adressraum des Kernels. PAE (Physical Address Extension) ist eine technische Erweiterung für x86 kompatible CPUs (ab Intel Pentium und AMD Athlon) die es ermöglicht bis zu 2 36 Bytes = 64 GByte Speicher zu adressieren. Dies ist möglich, da diese Prozessoren einen 36 Bit breiten Adressbus besitzen. Spezielle Erweiterungen in der»paging«-einheit des Prozessors sorgen dafür, dass 36-bittige physikalische Adressen generiert werden. Um PAE nutzen zu können, muss es vom Betriebssystem unterstützt werden. 64-bit Windows nutzt vom theoretischen Wert von 16 EB adressierbaren Speichers 16 TB als virtuellen Adressraum. Windows teilt diesen (zumindest aus heutiger Sicht) gigantischen Adressraum in verschiedene Bereiche auf, so dass für den Kernel und jeden 64-bit-Prozess jeweils ein Adressraum von 8 TB zur Verfügung steht. Für 32-bit-Anwendungen, die im so genannten Kompatibilitätsmodus laufen, steht pro Anwendung ein Adressbereich von 4 GB zur Verfügung, aber auch das ist mehr als bei einem reinen 32-bit- Betriebssystem, bei dem es maximal 3 GB sind. Fujitsu Technology Solutions 2009 Seite 13 (46)

14 Auswirkungen Wenn ausreichend Hardware-Ressourcen zur Verfügung stehen, also weder die CPU noch der Arbeitsspeicher der begrenzende Faktor ist, dann können auf einem 64-bit- System wesentlich mehr Benutzer betrieben werden als auf einem 32-bit-System. Der Grund hierfür liegt in der Betriebssystemarchitektur, genauer gesagt, bei den Kernel-Ressourcen. Das 32-bit-Betriebssystem hat einen Adressraum von 2 GB zur Verfügung, um seine Daten, unter anderem Kernel-Tabellen und System Cache, zu speichern. Bei hinreichender Rechenleistung erreicht die Benutzeranzahl eine Größenordnung, die für ein 32-bit- Betriebssystem zu hoch ist. Die Kernel-Tabellen sind vollständig belegt, was in Paging-Aktivitäten resultiert, obwohl noch Hauptspeicher frei ist. Weiterhin ist auch der System Cache überlastet und kann nicht weiter vergrößert werden, was zu einer schlechten Trefferrate im Cache (Light Lastprofil, Microsoft Office 2003, führt. Hierdurch steigen ebenfalls die Plattenzugriffe Microsoft Terminal Services) sprunghaft an. Sobald auf die Festplatte statt auf den Arbeitsspeicher zugegriffen werden muss, macht sich das sofort in einer Verschlechterung der Antwortzeiten bemerkbar. Würde man den Terminal Server über diese Engpasssituation hinaus weiter belasten, so würden die Applikationen auf Fehler laufen oder Benutzer könnten sich beim Terminal Server gar nicht mehr anmelden. In welchem Szenario ein 32-bit-Betriebssystem oder ein 64-bit-Betriebssystem Vorteile bringt, lässt sich gut an Hand einer durchgeführten Messreihe erläutern. Das gleiche PRIMERGY System mit jeweils ausreichender Rechenleistung wurde mit 4, 8, 16 und 32 GB RAM ausgestattet und die maximale Anzahl Light User ermittelt. Bei den Messungen mit 4 GB Hauptspeicher ist sowohl unter dem 32-bit-Betriebssystem als auch unter dem 64-bit-Betriebssystem der Hauptspeicher der limitierende Faktor, was in Paging- Aktivitäten resultiert. Die Messungen unter 64-bit ergeben sogar ein leicht schlechteres Ergebnis. Erklärbar ist das dadurch, dass 64-bit-Anwendungen in der Regel mehr Arbeitsspeicher benötigen als die 32-bit- Versionen, denn alle Adresszeiger sind bei 64-bit doppelt so breit (siehe Kapitel Arbeitsspeicher). Bei einer Vergrößerung des Speichers auf 8 GB können mehr Benutzer bedient werden, dieser Speicherausbau ist hier die optimale Konfiguration für das 32-bit-System. Eine weitere Speicheraufrüstung auf 16 GB bzw. 32 GB ist bei diesen Messungen unter dem 32-bit-Betriebssystem nicht von Vorteil. Wie schon oben erläutert, führen die begrenzten Kernel-Ressourcen dazu, dass nicht mehr Benutzer unterstützt werden können. Demgegenüber werden bei dem 64-bit- Betriebssystem durch steigenden Hauptspeicherausbau auch eine steigende Anzahl User erreicht, da keine Limitierungen durch Betriebssystemressourcen auftreten. Zusammenfassend kann man also feststellen, dass ein 32-bit-Betriebssystem bei Terminal Server limitierend wirkt, wenn entweder der für die gewünschte Anzahl Benutzer notwendige Arbeitsspeicher (> 64 GB) nicht unterstützt wird, oder es aufgrund der vielen Benutzer zu internen Kernel-Engpässen kommt. Dabei ist Zu wenig Speicher Engpass der Kernel-Ressourcen (Light Lastprofil, Microsoft Office 2003, Microsoft Terminal Services) der Speicherverbrauch eines einzelnen Benutzers natürlich anwendungsabhängig. Bestehen diese beiden Limitierungen nicht, so kann ein 32-bit-Betriebssystem durch geringeren Speicherverbrauch gegenüber dem 64-bit-Betriebssystem punkten. Fujitsu Technology Solutions 2009 Seite 14 (46)

15 Rechenleistung Die Rechenleistung eines Systems hängt von den Prozessoreigenschaften und der Anzahl Prozessoren ab. Unter Prozessoreigenschaften verstehen wir Kenngrößen wie z.b. Taktfrequenz, Cache, Hyper-Threading, Anbindung ans Memory oder Anzahl Kerne. Dabei sind Prozessoreigenschaften immer im Hinblick auf die jeweilige Prozessarchitektur zu sehen. Prozessortyp Folgende Übersicht zeigt Prozessoren verschiedener Generationen, die in älteren und aktuellen PRIMERGY Systemen für Terminal Server im Einsatz sind. Die Leistungsdaten gelten für jeweils eine CPU, wie sie mit dem Terminal Server Simulationswerkzeug»T4US«mit dem Lastprofil V1 bzw. V2 ermittelt wurden. Dabei sind alle Werte normiert zu den Ergebnissen der besten Xeon X5570 CPU aufgetragen. Bei der Betrachtung der Rechenleistung waren alle Systeme mit genügend Arbeitsspeicher ausgebaut. Hyper-Threading, sofern vorhanden, war eingeschaltet, da dieses Feature bei Terminal Server Anwendungen für eine Entlastung des Systems sorgt und dadurch eine höhere Anzahl von Benutzern mit dem Terminal Server arbeiten kann. Aus diesen Messergebnissen für eine CPU kann man die Leistung eines Systems mit einer höheren CPU-Anzahl nicht ablesen, da die Steigerung nicht linear ist (siehe Kapitel Anzahl Kerne). Fujitsu Technology Solutions 2009 Seite 15 (46)

16 Taktfrequenz Prozessorlinien der PRIMERGY Server gibt es in verschiedenen Leistungsstufen, die sich unter anderem in der Taktfrequenz unterscheiden. Dabei sagt die Taktfrequenz für sich allein nichts über die Leistungsfähigkeit des Prozessors aus. Andere Faktoren wie Architektur, Befehlssatz, Caches, Anbindung ans Memory beeinflussen die Prozessoren in ihrer Leistungsfähigkeit ebenso. Man darf also nicht den Fehler machen, mit einer höheren Taktfrequenz immer eine höhere Performance zu verbinden. Deutlich wird das bei den Intel Xeon 55xx Prozessoren, die im Vergleich zu dem Vorgänger Xeon 54xx niedriger getaktet sind, sich dennoch als viel leistungsfähiger erweisen. Der Vorteil der niedrigen Taktfrequenz liegt in der niedrigeren elektrischen Leistungsaufnahme (Energieverbrauch). Durch die Einführung der Turbo Boost Technologie bei der Intel Xeon 55xx Serie ist die Kennzahl Frequenz auch nicht mehr so eindeutig. Bei dieser Technologie wird nämlich, abhängig von der Anwendung, der Prozessor automatisch beim Arbeiten unterhalb thermischer und elektrischer Schwellwerte übertaktet. Vereinfacht heißt das: Wenn der Prozessor nicht voll ausgelastet ist und die Thermal Design Power (TDP) nicht überschritten wird, wird der Prozessor höher getaktet. Vergleicht man Prozessoren einer Familie, die sich nur in der Taktfrequenz unterscheiden während die anderen Kenngrößen wie Architektur, Caches, Memory-Anbindung und Anzahl Kerne gleich sind, so lässt sich durchaus bei höherer Taktfrequenz auch eine höhere Performance nachweisen. Allerdings spiegelt sich die Frequenzsteigerung nicht 1:1 in der relativen Performance-Steigerung wider. Dies erklärt sich aus der gleich bleibenden Geschwindigkeit bei Speicher- und I/O-Zugriffen. Als Beispiel sind in nebenstehender Grafik die Ergebnisse der PRIMERGY RX300 S4 1-CPU- Messungen der Xeon 54xx Reihe aufgetragen. Die Resultate wurden mit dem Terminal Server Benchmark und dem Lastprofil V1 unter Microsoft Terminal Server erreicht und normiert auf den kleinsten Prozessor dargestellt. Alle Prozessoren haben einen Front-Side-Bus mit 1333 MHz und einen 2 6 MB L2-Cache. (Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) Fujitsu Technology Solutions 2009 Seite 16 (46)

17 Memory-Anbindung Die Memory-Anbindung ist bei den PRIMERGY Systemen je nach Prozessorarchitektur unterschiedlich. Bei PRIMERGY Systemen, die mit AMD Opteron Prozessoren bestückt sind, ist der Memory Controller in der CPU integriert und die Prozessoren untereinander sind durch einen HyperTransport-Link verbunden. Bei Intel Prozessoren bis zur Xeon 5400-Serie wird die Kommunikation über den Front-Side-Bus (FSB) zwischen dem Prozessor und der so genannten Northbridge abgewickelt. Die Northbridge ist ein Bestandteil des Chipsatzes, der wiederum mit anderen Komponenten wie zum Beispiel dem Arbeitsspeicher oder dem PCI-Bus verbunden ist. Der FSB wird mit einer bestimmten Taktrate betrieben, welche Einfluss auf die System-Performance hat. Da sich die Prozessoren im Allgemeinen aber nicht nur in der Taktfrequenz des FSBs unterscheiden, ist ein direkter Vergleich unterschiedlicher FSB schlecht möglich. Unter Laborbedingungen konnte der Einfluss des Front-Side-Bus-Taktes jedoch vermessen werden. Die Grafik zeigt die Performance- Verbesserung durch Steigerung der Front-Side- Bus-Taktfrequenz von 667 MHz auf 800 MHz, was einer Steigerung von ca. 20% entspricht. Die Anzahl der Terminal Server Benutzer steigt in allen drei vermessenen Konfigurationen. Ein schnellerer FSB entlastet den Prozessor, die»% Processor Time«ist bei 800 MHz FSB etwas niedriger und gleichermaßen auch die»processor Queue Length«. Durch diese CPU- Reserve können mehr Benutzer mit dem Terminal Server arbeiten, bevor die Antwortzeiten sich verschlechtern und sich nicht mehr im zulässigen Rahmen befinden. Die Steigerung der Benutzeranzahl ist jedoch geringer als die Erhöhung der FSB-Taktfrequenz. Terminal Server als Anwendung beansprucht nicht nur (Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) Prozessorleistung, sondern zur Gesamtleistung trägt das Zusammenspiel aller Ressourcen wie Prozessor, Speicher, Netzwerk und Disk bei. Ab der PRIMERGY Generation mit Prozessoren der Serie Xeon 5500 (Nehalem EP) erfolgte ein Wechsel in der Systemarchitektur, weil die FSB Technologie hinsichtlich ihrer Komplexität, beispielsweise der Anzahl der im Chipset pro FSB benötigten Pins, zuletzt an Grenzen gestoßen ist: Intel Quick Path Interconnect (QPI) statt Front Side Bus (FSB). Der QPI verbindet Prozessoren untereinander, sowie Prozessoren und den für I/O zuständigen Chipsatz, mittels unidirektionaler, serieller Links. Für die Anbindung des Hauptspeichers sind die Prozessoren der Serie Xeon 5500 mit Speicher-Controllern ausgestattet, d.h. jeder Prozessor steuert unmittelbar eine Gruppe ihm zugeordneter Speichermodule. Die Leistungsfähigkeit des Quick-Path Interconnects wird in Gigatransfers pro Sekunde angegeben. Dabei erreichen die aktuellen Prozessoren der Xeon 5500 Serie mit einem QPI von bis zu 6.4 GT/s (entspricht bis zu 25.6 GByte/s) eine weit höhere Bandbreite als der stärkste Prozessor der Xeon 5400 Serie mit Hilfe der der Front-Side-Bus Architektur liefern konnte. Fujitsu Technology Solutions 2009 Seite 17 (46)

18 Caches Ein Cache ist generell ein schneller Zwischenspeicher, der durch die Pufferung von Daten den Zugriff beschleunigt. Bei Intel-CPUs sind die Caches in mehreren Stufen kaskadiert. Man unterscheidet Level 1 Cache, Level 2 Cache (auch Second Level Cache (SLC) genannt) und Level 3 Cache (Third Level Cache (TLC)). Meistens wird bei den Leistungsdaten der CPUs nur der jeweils letzte Cache genannt. Der Cache soll verhindern, dass der Prozessor auf Daten des langsameren Arbeitsspeichers warten muss. Je größer der Cache, umso weniger Speicherzugriffe sind nötig. Aus dieser Zeitersparnis resultiert wiederum eine höhere Rechenleistung. Vergleichende Messungen mit dem Terminal Server Benchmark zeigten, dass eine Verdoppelung des Caches zu einer Entlastung der CPU führte. Bei sonst gleichen Bedingungen wurden jeweils zwei Prozessoren einmal mit 1 MB Cache und einmal mit 2 MB Cache eingesetzt. Wie nebenstehende Grafik zeigt, wird der Prozessor des Terminal Server Systems bei dem größeren Cache weniger stark beansprucht. Daraus resultierte eine höhere Benutzeranzahl als Benchmark- Ergebnis. (Lastprofil V1, Microsoft Office XP, Citrix MetaFrame) Da beim 64-bit-Betriebssystem aufgrund der doppelt so großen Adressbreite mehr Daten verarbeitet werden müssen, hat die Größe des CPU-Caches hier einen größeren Einfluss. (Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) Das gleiche PRIMERGY System wurde wahlweise mit Xeon Prozessoren mit 1 MB oder mit 2 MB SLC ausgestattet. Wie nebenstehende Grafik zeigt, führt eine Verdoppelung des Caches auf beiden Plattformen zu einer höheren Performance. Das 64- bit-system profitiert am meisten von dem doppelt so großen Cache mit einem Performance- Gewinn von 25%. Das 32-bit- System gewinnt bis zu 15% mehr Leistung mit dem größeren Cache. Diese Messungen zeigen, dass ein 64-bit-System durch den Adress-Overhead einen größeren Cache benötigt. Eine generelle Empfehlung leitet sich aus diesen Ergebnissen ab: Für Systeme mit 64-bit-Betriebssystem sollten in jedem Fall Prozessorvarianten mit einem großen Cache eingesetzt werden. Dies ist wichtiger als eine geringfügig höhere Taktfrequenz. Allerdings sollte nicht der Fehler begangen werden, Cache-Größen von Prozessoren mit unterschiedlicher Architektur zu vergleichen. Die Caches der Prozessoren sind auf die Prozessorarchitektur abgestimmt. So haben z.b. aktuell Prozessoren der Serie Xeon 5500 (Nehalem) mit 256 kb per Core SLC und maximal 8 MB TLC für alle vier Kerne nominell weniger Cache als Prozessoren der Serie Xeon 5400 (Harpertown) mit 2 6 MB SLC. Trotzdem ist die Gesamtleistung der Prozessoren weit höher. Fujitsu Technology Solutions 2009 Seite 18 (46)

19 Hyper-Threading Bei Hyper-Threading-Prozessoren sind einige Ressourcen auf dem Chip verdoppelt, so dass diese CPUs nun die Fähigkeit besitzen, zwei Threads parallel ausführen zu können. So werden zwei virtuelle bzw. logische CPUs simuliert. Dem Betriebssystem gegenüber stellt sich eine CPU mit Hyper-Threading als zwei CPUs dar und wird auch so angesteuert. Dies bringt einen Geschwindigkeitsvorteil, wenn Betriebssystem und Anwendungen dafür geeignet sind. Windows als Betriebssystem ist vom Design her Hyper-Threadingfähig und gerade in Terminal Server Umgebungen arbeiten viele einzelne Benutzer mit insgesamt vielen, meist kleineren Anwendungen parallel, so dass von Hyper-Threading eine Performance-Steigerung zu erwarten ist. Die meisten Intel Prozessoren der aktuellen Xeon 5500 Serie (Nehalem) unterstützen Hyper-Threading. AMD Prozessoren besitzen grundsätzlich kein Hyper-Threading. Messungen haben gezeigt, dass der Performance-Gewinn durch Hyper-Threading bei gering bis mittel belasteten Systemen am größten ist. Bei Systemen, die an ihrer Lastgrenze arbeiten, ist der Performance- Gewinn geringer. Auch ist die Leistungssteigerung auf einem Monoprozessorsystem höher als auf Multiprozessorsystemen. Eine Messreihe wurde auf einer PRIMERGY RX200 S1 mit zwei Prozessoren durchgeführt, einmal mit eingeschaltetem Hyper-Threading und einmal mit abgeschaltetem Hyper-Threading. In beiden Fällen wurde die gleiche Anzahl von 101 Benutzern simuliert. Bei Terminal Server Anwendungen sorgt das Hyper- Threading für eine Entlastung des Systems, die CPU- Last konnte um 31% reduziert werden, wie die nebenstehende Grafik veranschaulicht. Bei der verwendeten PRIMERGY RX200 S1 und 101 Benutzern konnte man ohne Hyper-Threading schon einen CPU Engpass feststellen, die Antwortzeiten des Terminal Servers waren nicht mehr im vorgegebenen Rahmen. Durch die CPU Entlastung durch Hyper-Threading erfüllte das System wieder die vorgegebene Reaktionszeit. (Lastprofil V1, Microsoft Office XP, Citrix MetaFrame) In einer weiteren Messreihe wurden die absoluten Benutzeranzahlen für Systeme mit und ohne Hyper-Threading ermittelt. Die nebenstehende Grafik zeigt die Messergebnisse. Das vermessene PRIMERGY System war eine PRIMERGY RX300 S2 mit einem oder zwei Prozessoren mit verschiedenen Taktfrequenzen. Für diesen Vergleich wurden Prozessoren mit 1 MB SLC verwendet. Hyper-Threading war alternativ ein- (»HT on«) oder ausgeschaltet (»HT off«). Man erkennt deutlich, dass mit eingeschaltetem Hyper-Threading (Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) eine höhere Anzahl Benutzer mit dem Terminal Server arbeiten können. Bei einem langsameren Monoprozessorsystem ist der Performance- Gewinn durch Hyper-Threading höher als bei einem schnellen Dualprozessorsystem. Fujitsu Technology Solutions 2009 Seite 19 (46)

20 Anzahl Kerne Eine gängige Variante um die Leistungsfähigkeit eines Prozessors zu steigern, ist die Erhöhung durch die Taktfrequenz. Doch dies geht bei Frequenzen um 4 GHz mit einer nicht mehr sinnvoll handhabbaren Abwärme einher. Eine Möglichkeit der Fortentwicklung ist die Verwendung von Mehrkernprozessoren. Im Gegensatz zum»hyper-threading«, wo nur Teile eines Prozessors mehrfach auf dem Chip vorhanden sind um Threads parallel ausführen zu können, sind bei einem Mehrkernprozessor sämtliche Ressourcen des Prozessors repliziert. Mehrkernprozessoren haben zudem den Vorteil, dass die Kosten für den Einsatz eines einzelnen Chips mit mehreren Ressourcen häufig geringer sind als bei mehreren einzelnen Chips. Während bis zum Jahr 2005 die Einzelkernprozessoren dominierten, sind die aktuellen Prozessoren der Intel Xeon Reihe als 4-fach oder auch 6-fach Kerne ausgelegt. Zukünftige Prozessorgenerationen werden die Anzahl Kerne pro Chip noch vervielfachen. Die rein theoretische Leistungssteigerung beträgt maximal 100% (gegenüber einem einzelnen Kern) pro zusätzlichem Kern. In der Praxis hängt die Leistungssteigerung aber stark von dem Parallelisierungsgrad des ausgeführten Programms und des verwendeten Betriebssystems ab. Darüber hinaus lässt sich die Rechenleistung eines Systems durch den Einsatz mehrerer Prozessoren erhöhen. Man bezeichnet den Einsatz mehrerer gleicher physikalischer Prozessoren auch als»symmetric multiprocessing«(smp). Die Skalierung mit wachsender Anzahl Prozessoren ist nur im Idealfall einer optimal parallelisierbaren Anwendung linear. Je mehr Zugriffe jedoch auf gemeinsame Ressourcen wie Arbeitsspeicher, Festplatten oder Netzwerk erfolgen, und somit eine Koordination zwischen den Prozessoren bedingen, umso mehr flacht die Skalierungskurve ab. Im Extremfall kann es bei einer sehr großen Anzahl Prozessoren und sehr hohem Koordinationsanteil der Prozessoren untereinander sogar zu einem»umkippen«der Skalierung kommen. Schon 1967 betrachtete Gene Amdahl die Beschleunigung von Programmen durch parallele Ausführung in einem mathematischen Modell und stellte fest, dass der Geschwindigkeitszuwachs vor allem durch den sequentiellen Anteil des Programms beschränkt ist (»Amdahls Gesetz«). Aktuelle Multiprozessorsysteme wirken dem entgegen, indem sie den Prozessoren große Caches beiseite stellen oder Gruppen von Prozessoren bilden und diesen eigenen Arbeitsspeicher und I/O-Komponenten zuordnen. Letzteres bedingt für optimale Performance darauf angepasste Betriebssysteme wie z.b. Windows Server 2003 Enterprise und Datacenter Edition mit»nonuniform memory access«(numa) Support. Wie schon im Kapitel Hyper-Threading ausgeführt, arbeiten in Terminal Server Umgebungen viele einzelne Benutzer mit insgesamt vielen, meist kleineren Anwendungen parallel eine gute Voraussetzung, um viele Rechenkerne zu nutzen. Bis zu welcher Anzahl Kerne eine Terminal Server Anwendung gut skaliert ist aber auch wieder anwendungsspezifisch und kann nicht verallgemeinert werden. Wie in der nebenstehende Grafik dargestellt, zeigten Terminal Server Messungen mit dem T4US Lastprofil V2 auf einer PRIMERGY RX300 S5 mit einem und zwei Xeon Quad-Core Prozessoren bei eingeschaltetem Hyper-Threading eine sehr gute Skalierung vom Faktor 1.7. (Lastprofil V2, Microsoft Office 2003, Microsoft Terminal Services) Fujitsu Technology Solutions 2009 Seite 20 (46)

21 Arbeitsspeicher Den stärksten Einfluss auf die Leistungsfähigkeit des Terminal Servers übt der Arbeitsspeicher aus. Dabei spiegelt sich dies insbesondere in der Antwortzeit wider. Denn Windows verschafft sich bei Bedarf weiteren virtuellen Speicher durch Auslagern (Pagen) von momentan nicht benötigten Daten aus dem Arbeitsspeicher (RAM) in die Auslagerungsdatei (Pagefile) auf Festplatte. Da Plattenzugriffe aber mindestens um die Größenordnung 1000 langsamer sind als Speicherzugriffe, führt dies unmittelbar zum Zusammenbruch der Leistung und zu einem rapiden Anstieg der Antwortzeiten. Bei Terminal Server wächst der Speicherbedarf linear mit der Anzahl der Benutzer, unabhängig vom PRIMERGY Modell und gleichermaßen bei 32-bit- und 64-bit-Betriebssystemen, wie die beiden Grafiken veranschaulichen. Trägt man den belegten Speicher, den»committed«speicher und den»working Set«grafisch auf, so erkennt man einen linearen Verlauf, der mit steigender Benutzeranzahl wächst. Während»Available MBytes«den aktuell freien physikalischen Hauptspeicher angibt, wird in»committed Bytes«angegeben, wie viel virtueller Hauptspeicher den laufenden Anwendungen zugesagt wurde. Der»Working Set«einer Anwendung ist der Speicher, den sie bereits verwendet hat. Es soll auch nicht verschwiegen werden, dass 64-bit-Betriebssysteme und 64-bit-Anwendungen in der Regel mehr Arbeitsspeicher benötigen als die 32-bit-Versionen, denn alle Adresszeiger sind bei 64-bit doppelt so breit. Im Extremfall führt das bei 64-bit zu einem doppelten Speicherbedarf im Vergleich zu 32-bit. Wie die nebenstehende Grafik zeigt, belegt der gleiche Benutzer, der den Desktop gestartet hat und mit Microsoft Word 2003 arbeitet, auf dem 64-bit- System im Vergleich zum 32-bit-System ca. 60% mehr Arbeitsspeicher. Die Anwendung, mit der der Terminal Server Benutzer arbeitet, ist in beiden Fällen Microsoft Word, welches heute nur als 32- bit-version existiert. (Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) Allgemeingültig ist jedoch die Tatsache, dass der Speicherbedarf linear nach der Formel anwächst. Man beachte dabei nur, dass der Speicherbedarf pro Benutzer stark von der verwendeten Anwendung abhängt und jeweils kundenspezifisch ermittelt werden muss. Kennt man jedoch den Speicherbedarf der Anwendung bei einem Benutzer, so lässt sich leicht der Gesamt-Speicherbedarf berechnen. Fujitsu Technology Solutions 2009 Seite 21 (46)

22 Nach oben begrenzend wirken nur der maximal mögliche Speicherausbau des Systems sowie die Unterstützung des Betriebssystems (siehe Kapitel Limitierungen). Der maximale Speicherausbau eines Systems ist abhängig vom Modell. Die x86-basierten PRIMERGY Server haben unterschiedliche Architekturen. Die älteren Modelle (von Intel Pentium Pro Prozessor (1995) bis Intel Xeon 5400 (Harpertown)) entsprechen dem Prinzip des Symmetric Multiprocessing (SMP). Die Anbindung der Prozessoren an den Hauptspeicher ist durch einen Front-Side Bus realisiert ist. Auch bei der Bestückung mit nur einem Prozessor ist der gesamte Speicher nutzbar. Intel Xeon Prozessoren ab der Xeon 5500 Serie unterliegen einer anderen Architektur. Für die Anbindung des Hauptspeichers sind diese Prozessoren mit Speicher-Controllern ausgestattet, d.h. jeder Prozessor steuert unmittelbar eine Gruppe ihm zugeordneter Speichermodule. Gleichzeitig ist der Prozessor in der Lage, über den Quick Path Interconnect Speicherinhalte dem benachbarten Prozessor zur Verfügung zu stellen und solche selbst anzufordern (siehe Kapitel Memory-Anbindung). Durch die direkte Kopplung zwischen Prozessor und Speicher ist eine Steigerung der Speicher-Performance plausibel, jedoch mit dem Performance-Unterschied zwischen lokaler und ferner Anforderung, der die Klassifizierung dieser Architektur als NUMA rechtfertigt. Die Berücksichtigung von NUMA bei der Vergabe von physikalischem Speicher und beim Scheduling von Prozessen erfolgt durch das Betriebssystem. Soweit möglich, sollte die Gesamtmenge an Arbeitsspeicher symmetrisch über beide Prozessoren verteilt werden. Ist das System nur mit einem Prozessor bestückt, können auch nur die diesem Prozessor zugeordneten Speicherbänke genutzt werden. Weitere Performance-relevante Hinweise zu leistungsfähigen Speicherkonfigurationen der Xeon 5500 basierten PRIMERGY Systeme finden sich im Dokument»Speicher-Performance Xeon 5500 (Nehalem EP) basierter PRIMERGY Server«[L4]. Auch PRIMERGY Modelle mit AMD Opteron Prozessoren besitzen eine direkte Zuordnung des Speichers zu den Prozessoren. Jeder Prozessor hat»seinen«speicher direkt angebunden, was in einem schnellen Zugriff resultiert. Aus dieser Systemarchitektur folgt umgekehrt, dass eine PRIMERGY, die lediglich mit einem AMD Opteron Prozessor bestückt ist, auch nur die Hälfte der Speicherbänke nutzen kann, da der zweite CPU-interne Memory Controller zur Ansteuerung fehlt. Bei der Kalkulation des Arbeitsspeichers für Terminal Server sollte man zwei Besonderheiten nicht außer Acht lassen:»desktop«oder»published Application«? Bei Terminal Server Umgebungen muss man dem Benutzer nicht den gesamten Desktop mit allen Anwendungen zur Verfügung stellen, man kann den Zugriff auch beschränken. Microsoft Terminal Server kann man so konfigurieren, dass eine bestimmte Anwendung statt des Desktop gestartet wird. Bei Citrix Presentation Server kann man den Benutzern auch mehrere einzelne Anwendungen (»Published Application«) direkt zur Verfügung stellen, der Start der Applikation innerhalb des Desktop entfällt. Dabei werden pro Benutzer ungefähr 5 bis 10 MB an Hauptspeicher gespart, da der Explorer- Prozess nicht mit gestartet werden muss. Auch wenn es in einer bestimmten Umgebung vielleicht nicht um diesen kleinen Gewinn von Hauptspeicher geht; ein nicht zu vernachlässigender Vorteil dieser Konfiguration ist, dass der Benutzer nur die für ihn vorgesehenen Anwendungen auf dem Server laufen lassen kann. Man kann also die Aktionen der Benutzer besser vorhersagen und auch einschränken. Der Speicherbedarf eines Benutzers, der eine Anwendung über den Desktop startet, wurde mit dem Speicherbedarf eines Anwenders verglichen, der die gleiche Applikation direkt ohne Desktop startet. Die Anwendung Microsoft Word aus Microsoft Office 2003 wurde einmal über den Desktop und einmal über den RDP Client direkt gestartet. Wie nebenstehe Graphik deutlich zeigt, ist der Speichermehrverbrauch ohne Starten des Desktops geringer. (Lastprofil V1, Microsoft Office 2003, Microsoft Terminal Services) Fujitsu Technology Solutions 2009 Seite 22 (46)

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

24 Disk-Subsystem Geht man davon aus, dass ein Server dediziert als Terminal Server eingesetzt wird, und nicht gleichzeitig noch als File Server oder Datenbank-Server, so werden an das Disk-Subsystem keine großen Anforderungen gestellt. Es muss im Wesentlichen nur das Betriebssystem, den Paging-Bereich und die den Terminal Server Clients zur Verfügung stehenden Applikationen beherbergen. Die Plattenzugriffe sind dabei gering. Auf das Betriebssystem und die Applikationen wird nur zugegriffen, wenn sie das erste Mal in den Speicher geladen werden. Der Paging-Bereich spielt prinzipiell auch keine Rolle, denn das System muss so konfiguriert sein, dass es nicht in starkes Pagen gerät, anderenfalls ist die Leistungsfähigkeit des Systems in jedem Fall erheblich beeinträchtigt. Die Benutzerdaten und Benutzerprofile werden typischerweise auf entsprechende Disk-Subsysteme oder externe File Server gelegt und nicht auf die lokalen Festplatten eines Terminal Servers. Wird ein Terminal Server auf moderner Server-Hardware mit Multi-Core-Architektur und ggf. einem 64-bit- Betriebssystem aufgebaut, so können damit mehr Benutzer arbeiten und somit muss auch das Disk- Subsystem wachsen, um diesen Anforderungen gerecht werden zu können. Durch mehr Benutzersitzungen finden mehr Zugriffe auf das lokale Pagefile und auf das Disk-Subsystem statt und beim 64-bit- Betriebssystem werden auch größere Datenmengen Richtung Pagefile geschrieben. Aus diesen Gründen muss das Disk-Subsystem entsprechend dimensioniert werden. Hinweise zum Monitoren des Disk- Subsystems finden sich im Kapitel Engpassanalyse. Um einen maximalen Durchsatz zu erreichen, sollten alle vorhandenen Controller- und Festplatten Caches (auch die Write-Caches) eingeschaltet werden. Write-Caches der Festplatten tragen erheblich zur Performance-Steigerung bei, und es empfiehlt sich, diese bei allen Festplatten vorhandene Funktionalität auch im produktiven Einsatz zu nutzen. Dabei ist die Verwendung einer USV zum Schutz gegen Stromausfälle und damit verbundenem Datenverlust empfehlenswert. Zum Sizing von Disk-Subsystemen wurde ein eigenes White Paper»Performance Report - Modular RAID für PRIMERGY«[L5] erstellt. Wird das Terminal Server System hingegen gleichzeitig noch als Datei- oder Datenbank-Server eingesetzt, so gelten für das Disk-Subsystem natürlich zusätzliche Kriterien, wie sie für Datei- oder Datenbank-Server typisch sind. Von einer solchen Konstellation ist jedoch abzuraten, es sei denn, das System wird nur in einem sehr begrenzten Workgroup-Umfeld eingesetzt. Ansonsten sollten dedizierte Systeme für die einzelnen Aufgaben, wie Terminal Server, Datei-Server, Datenbank- oder Applikations-Server, aufgebaut werden. Nur so kann ein Server-System optimal für seinen Aufgabenbereich zugeschnitten werden. Je nach Anzahl Festplatten im Server-System gelten folgende Empfehlungen: Zwei Festplatten, Konfiguration für Sicherheit: Wenn nur zwei Festplatten zur Verfügung stehen und auf Sicherheit Wert gelegt wird, so sollte aus Sicherheitsgründen eine Spiegelung über RAID 1 eingerichtet werden. Dort befinden sich dann Betriebssystem, Paging-Bereich und Applikationen. Eine Spiegelung kann entweder mit den onboard RAID 1-Funktionalitäten, die fast alle PRIMERGY Server standardmäßig bieten, oder softwaremäßig mit Windows Mitteln realisiert werden. Alternativ kann auch ein RAID-Controller eingesetzt werden. Zwei Festplatten, Konfiguration für Performance: Um eine bessere Performance zu erreichen, sollte das Pagefile nicht auf einer gespiegelten Festplatte konfiguriert werden. Wenn nur zwei Festplatten zur Verfügung stehen, sollten das Betriebssystem und die Applikationen auf der ersten Festplatte gespeichert werden, während das Pagefile auf die zweite Festplatte gelegt werden sollte. Da die Festplatte des Betriebssystems nicht gespiegelt ist, sollte sichergestellt werden, dass dort keine Benutzerdaten abgelegt und dass regelmäßige Backups durchgeführt werden. Drei oder mehr Festplatten: Stehen insgesamt mindestens drei Festplatten zur Verfügung, sollte man zwei Festplatten mit Hilfe von RAID 1 spiegeln und dort das Betriebssystem und die Applikationen unterbringen. Der Paging-Bereich wird auf die dritte dedizierte Festplatte gelegt, da die Nutzung einer gespiegelten Festplatte durch das Pagefile beträchtliche Auswirkungen auf die Performance haben kann. Da diese Daten alle temporärer Natur sind, ist hier natürlich keine Absicherung durch RAID notwendig. Fujitsu Technology Solutions 2009 Seite 24 (46)

25 Netzwerk Obwohl dem Thema Netzwerk im Terminal Server Umfeld eine wichtige Rolle zukommt, wird es im Rahmen dieses Papieres nicht ausführlich behandelt, da es ein eigenständiges Thema darstellt. Auch soll hier ein einzelner Terminal Server und nicht eine Terminal Server Farm im Focus stehen. In der Praxis sind zudem häufig schon Netzwerk-Topologien vorhanden, in die der Terminal Server zu integrieren ist. Bei der Betrachtung eines einzelnen Terminal Servers ist zu berücksichtigen, dass er bezüglich Netzwerkanbindung die benötigten Bandbreiten für alle Benutzer zur Verfügung stellt. Welche Bandbreiten für den Terminal Server benötigt werden, ist dabei stark vom Benutzer abhängig. Benutzer, die z.b. mehr im Office-Umfeld mit Textverarbeitung zu tun haben, benötigen weniger Bandbreite als Nutzer von 2D- oder 3D- Anwendungen. Ebenso spielt das verwendete Übertragungsprotokoll eine Rolle. Dabei hat sich das von Citrix entwickelte ICA-Protokoll als effizienter erwiesen als RDP von Microsoft. Aktuelle PRIMERGY Server bieten mit ihren Gigabit Ethernet Anschlüssen eine gute Voraussetzung, um einen Terminal Server performant zu betreiben. Bedingt es das Aufgabenszenario, dass die auf dem Terminal Server ablaufenden Anwendungen auf große Datenmengen, Datenbanken oder gar Host-Anwendungen zugreifen, so empfiehlt es sich, den Terminal Server mit einer weiteren Netzwerkkarte für den dedizierten Zugriff auf diese Server-Dienste auszustatten, um so den Datenverkehr in dieser Three-Tier-Umgebung zwischen Server-Server- und Client-Server- Kommunikation zu trennen. Application Server Terminal Server Database Server File Server Network Network In einer Terminal Server Umgebung muss folgender Netzwerkverkehr berücksichtigt werden: Terminal Server und Active Directory Hauptsächlich während des Anmeldevorgangs der einzelnen Benutzer in die Domäne werden Informationen aus dem Active Directory benötigt. Dies wird in realen Konfigurationen oft auch über ein Netzwerksegment abgewickelt, das von den Client-Netzwerken getrennt ist. Clients und Terminal Server Tastatur- und Mauseingaben werden zum Terminal Server gesendet, und die Änderungen der Bildschirmdarstellung werden zum Client übertragen. Fujitsu Technology Solutions 2009 Seite 25 (46)

26 Infrastruktur In unseren Untersuchungen haben wir den Terminal Server immer isoliert betrachtet. In der Messumgebung gab es weitere Komponenten, mit denen der Terminal Server zusammen arbeitet, jedoch waren diese immer konstant und so ausgelegt, dass diese nicht der Engpass waren. In der Realität ist dies jedoch nicht immer der Fall. In diesem Abschnitt soll diskutiert werden, welche weiteren Komponenten der Infrastruktur einen Einfluss auf das Benutzerempfinden in einer Terminal Server Umgebung haben, was sich in einem negativen Gesamteindruck widerspiegeln könnte. Clients Neben den Server-Ressourcen und dem Netzwerk gehört natürlich auch der Client zur Gesamtumgebung des Server-based Computing. Also ist auch bzgl. des Clients die Frage berechtigt, welchen Einfluss dessen Leistungsfähigkeit auf die Gesamtkonfiguration hat. Da beim klassischen Server-based Computing die eigentliche Applikation auf dem Server abläuft, wird die CPU-Leistung des Clients nur für die Bedienung des Netzwerks und die vom Aufwand her nicht zu vernachlässigende Bildaufbereitung benötigt. Es wurde festgestellt, dass je nach verwendetem Client-System die Gesamt-Ausführungszeit einer Applikation durchaus variiert. Diese Unterschiede dürften sich im realen Betrieb aber allenfalls in einem subjektiven Performance-Eindruck des Benutzers widerspiegeln und haben keinen unmittelbaren Einfluss auf die Leistungsfähigkeit des Terminal Server Systems. Wie»thin«der Thin-Client sein darf, hängt in erster Linie von den Ansprüchen seitens der eingesetzten Applikationen an die Grafik ab, wie Auflösung, Farbtiefe und Komplexität (Text, Grafik) sowie von ggf. zusätzlichen Anforderungen an lokal auf dem Client ablaufende Anwendungen, die über das reine Serverbased Computing hinausgehen. Neben den ortsgebundenen (Thin-)Clients gibt es die Anforderungen auch mobile Geräte wie Notebooks oder PDAs an Terminal Server anzuschließen. Üblicherweise werden diese Geräte dann nicht mehr über kabelgebundene Netzwerke angeschlossen, sondern über Funk-LANs (W-LAN) oder mobile Funknetze (z.b.»general Packet Radio Services«(GPRS) oder»universal Mobile Telecommunication System«(UMTS)). Dies stellt insbesondere beim Ressourcen sparenden ICA-Protokoll kein Problem dar. Den ICA-Client gibt es auch für viele gängige PDAs und das ICA-Protokoll ist durch sein Design besonders auch für langsame Verbindungen geeignet. Für Benutzer, die ständig und ausschließlich mit Terminal Server Anwendungen arbeiten, stellt solch ein Endgerät sicher nicht den idealen Client dar, aber jemand, der mobil arbeiten muss und nur gelegentlich Zugriff auf einen Terminal Server braucht, profitiert von der Flexibilität und Funktionalität dieser Lösung. Active Directory Terminal Server Benutzer authentifizieren sich im Normalfall in einer Domäne, d.h. der Terminal Server überprüft die eingegebenen Benutzercredentials gegen das Active Directory. Außer in sehr kleinen Workgroup-Umgebungen sollten Active Directory und Terminal Server immer auf verschiedenen Systemen laufen und auf dem Terminal Server selbst sollten keine Benutzer verwaltet werden. An das Active Directory werden die gleichen Anforderungen gestellt wie in einer Umgebung ohne Terminal Server, es sollte aber weder das Active Directory noch das Netzwerk zwischen Active Directory und Terminal Server der Engpass sein. Benutzerprofile (User Profiles) In einem Benutzerprofil werden die individuellen Benutzereinstellungen gespeichert. Auch bei einem Login von Terminal Server Benutzern in einer Domäne in einem Active Directory Umfeld würden deren Benutzerprofile standardmäßig auf dem Terminal Server gespeichert. Insbesondere bei einer load-balanced Terminal Server Farm wird man die Benutzerprofile allerdings zentral auf einem Server im Netzwerk ablegen wollen, damit der Benutzer immer die gleichen Einstellungen vorfindet, unabhängig davon, auf welchem Terminal Server seine Sitzung ausgeführt wird. Diese Funktionalität ist bereits für so genannte»wandernde Benutzer«(Roaming User) vorhanden, die sich an verschiedenen Arbeitsplätzen anmelden. Beim Einsatz von Terminal Servern ist zu beachten, dass ggf. verschiedene Benutzerprofile verwaltet werden müssen, wenn sich nämlich das lokale Betriebssystem des Arbeitsplatzes von dem des Terminal Servers unterscheidet bzw. wenn verschiedene Anwendungen vorhanden sind. Aus diesem Grunde kann man ein Terminal Server Benutzerprofil zusätzlich zu einem lokal zu ladenden Benutzerprofil konfigurieren. Eine besondere Variante des Server-basierten Benutzerprofils ist das Mandatory User Profile, ein Benutzerprofil, das der Benutzer nicht ändern kann. Server-basierte Benutzerprofile sollten generell möglichst klein sein. Fujitsu Technology Solutions 2009 Seite 26 (46)

27 DNS Auch im Terminal Server Umfeld wird DNS verwendet, um die Namensauflösung von Verbindungen zu realisieren. Besonders im Load Balancing Umfeld wird auf diese Weise ein virtueller Name mit einer virtuellen oder realen IP-Adresse verknüpft, so dass sich eine Terminal Server Farm zum Benutzer hin wie ein Server darstellt. Daraus ergibt sich umgekehrt die Forderung, dass DNS immer erreichbar sein muss, damit ein Benutzer eine Verbindung zum Terminal Server aufbauen kann. DNS stellt im Allgemeinen keinen Engpass dar, dieser Dienst sollte nur ausfallsicher und redundant konzipiert sein. Terminal Services Licensing Server Bei der Anmeldung eines Benutzers an einen Terminal Server wird dieser einen Lizenz-Server suchen und von ihm eine gültige Lizenz für den Zugriff über Terminal Server anfordern. In größeren Konfigurationen wird dieser Lizenz-Server ein eigenes System sein. Backend Server Gerade in»load-balanced Terminal Server Farmen«werden die Dateien der Benutzer nicht auf den lokalen Festplatten der Terminal Server Systeme liegen, sondern auf File Servern oder NAS Systemen. Vermutlich werden in größeren Umgebungen auch weitere Dienste wie , Datenbanken usw. benötigt, so dass man Server für Anwendungen wie zum Beispiel Exchange, SQL oder SAP R/3 zusammen mit dem Terminal Server vorfinden wird. Wird für die Anbindung der Clients zum Terminal Server nur wenig Netzwerkbandbreite benötigt, so gilt dies nicht für die Anbindung der Terminal Server an die Backend Server. Hier sollte genügend Netzwerk- und Rechenkapazität zur Verfügung stehen. Für die einzelnen Server verweisen wir auf eigene Performance-Untersuchungen und Sizing Guides, da dies den Rahmen dieses Papiers sprengen würde. Es wird nicht empfohlen, Backend-Dienste auf einem Terminal Server zu betreiben. Fujitsu Technology Solutions 2009 Seite 27 (46)

28 Überlastverhalten Bei allen PRIMERGY Servern, insbesondere aber bei den leistungsfähigeren, kann man ein Verhalten beobachten, bei dem ein scheinbar normal ausgelastetes System durch das Hinzufügen einiger weniger Benutzer überlastet wird. Setzt man die Anzahl Benutzer, die CPU-Auslastung des Systems und die Antwortzeiten miteinander in Beziehung, so erkennt man, wie sich die Antwortzeiten des Terminal Servers bei steigender Auslastung verhalten. Während einer Messung über 25 Minuten wurde in den ersten 15 Minuten die Benutzeranzahl kontinuierlich erhöht. Jeder Benutzer meldet sich erst an, danach arbeitet er mit Microsoft Word, um sich nach ca. 16 Minuten wieder abzumelden und wieder von vorn zu beginnen. Dadurch verteilen sich die Benutzeranmeldungen (blaue Kurve ) auf einen relativ kurzen Zeitraum, was aber der Realität nahe kommt, wenn die Benutzer etwa zur gleichen Zeit ihre Arbeit aufnehmen. Die CPU Auslastung des Terminal Servers stieg ständig an (rote Kurve ) bis nah an 100%. Zwei signifikante Messergebnisse wurden beobachtet: Die Zeit, die der Benutzer brauchte, um sich am Terminal Server anzumelden (violette Kurve ) und die Zeit, um in Microsoft Word ein Bild einzufügen (grüne Kurve ). Eine Anmeldung an den Terminal Server beinhaltet nicht nur das Login selbst, sondern auch der Desktop des Benutzers wird gestartet. Dies belastet den Terminal Server mehr als das Einfügen des Bildes in Microsoft Word. Aktionen, die von sich aus den Terminal Server stark belasten, werden unter Hochlast stärker verlangsamt als weniger belastende Aktionen. Man erkennt drei Phasen der Terminal Server Auslastung: Die CPU-Belastung des Terminal Servers ist unter 70%. Die Antwortzeiten des Servers verlängern sich geringfügig, dies wird der Benutzer aber nicht realisieren. Die CPU-Belastung des Terminal Servers ist zwischen 70% und 90%. Aktionen, die den Server stärker belasten, sind verlangsamt, aber die Antwortzeit ist für den Benutzer noch tolerierbar. Aktionen, die den Server nicht so stark belasten, haben im Durchschnitt die gleichen Reaktionszeiten, jedoch können Schwankungen auftreten. Wenn die CPU-Belastung des Terminal Servers über 90% ist, ist der Server deutlich überlastet. Je nach Benutzeraktion antwortet der Server wesentlich später, speziell Aktionen wie ein Login brauchen deutlich mehr Zeit. Aber auch einfachere Aktionen sind deutlich verlangsamt. Der Benutzer wird das Antwortzeitverhalten des Servers nicht mehr tolerieren. Anzahl Prozesse Auch wenn es paradox klingt: es kann Konstellationen geben, in denen, obgleich ausreichend CPU- und Speicher-Ressourcen zur Verfügung stehen, es zu Leistungsengpässen kommen kann. Auch Disk-I/O oder Netzwerke stellen in dieser Situation keinen Engpass dar, sondern quasi die Systemarchitektur. Diese Situation wird insbesondere von einer großen Anzahl an Benutzern, die viele Prozesse mit einer geringen gleichmäßigen Last induzieren, provoziert. Dabei spielt die Prozessor-Warteschlange eine nicht zu vernachlässigende Rolle. So gibt es in Abhängigkeit der Prozessor-Leistung und Prozessor-Anzahl einen Punkt, an dem das System keine weiteren Prozesse und somit Clients mehr bedienen kann. Im Prinzip ist hierbei das System nur noch damit beschäftigt, die Prozesse zu verwalten. Oder in»fachchinesisch«ausgedrückt: In einem Multitasking-Betriebssystem erhält jeder Prozess eine Zeitscheibe, die er nicht schnell genug wieder frei gibt. Diese Situation könnte nur durch kleinere Zeitscheiben und somit größeren Turn- Around-Zeiten behoben werden. Dies hätte jedoch in anderen Lastsituationen negative Auswirkungen auf die Grundlast, die das Betriebssystem erzeugt. Die Anzahl Prozesse, ab der diese Situation eintritt, hängt neben der zur Verfügung stehenden CPU-Leistung und -Anzahl leider aber auch von der verwendeten Applikation ab, sodass keine generelle Formel hierfür angegeben werden kann. Bei Heavy Usern tritt dieser Effekt meist nicht zu Tage, da hier andere Ressourcen, wie Speicher und Rechenleistung die dominierenden Begrenzungsfaktoren sind. Fujitsu Technology Solutions 2009 Seite 28 (46)

29 PRIMERGY Skalierung Die Leistungsfähigkeit des Terminal Servers ist durch CPU-Leistung und Hauptspeicher bestimmt. Den Speicherausbau kann man recht einfach anhand der Formel abschätzen. Werden verschiedene Applikationen gleichzeitig verwendet, so ist die Summe des Speicherbedarfs aller gleichzeitig verwendeter Applikationen zu bilden. Die Anzahl Benutzer bei einer vorgegebenen Speichermenge kann mit folgender Formel berechnet werden: Für die CPU-Leistung gilt leider keine so einfache Formel. Bei einem Medium oder Heavy User stellt im Allgemeinen die CPU-Leistung den begrenzenden Faktor dar. Für eine Klasse von Light Usern ist die maximale Benutzerzahl eher durch andere Systemressourcen begrenzt. Die Vielzahl an Prozessoren, mit denen jedes PRIMERGY-Modell ausgestattet werden kann, lässt bereits erahnen, dass es nicht eine bestimmte Anzahl Benutzer gibt, die ein PRIMERGY-Modell bedienen kann, sondern dass jedes PRIMERGY-Modell eine gewisse Bandbreite abdeckt. Auch gibt es keine scharfe Grenze, wo die Leistung eines Modells endet und die des nächst leistungsfähigeren beginnt. Vielmehr gibt es Überlappungen zwischen den Systemen. Die folgenden auf Basis unserer Messreihen gewonnenen Ergebnisse können also nur einen Eindruck für den Leistungsbereich vermitteln. Fujitsu Technology Solutions 2009 Seite 29 (46)

30 Da die Systeme mit unterschiedlichen Lastprofilen vermessen wurden, sind keine absoluten Benutzeranzahlen angegeben. Vielmehr soll die relative Leistung der Systeme unter Terminal Server Anwendungen aufgezeigt werden. In dieser Darstellung wird die PRIMERGY RX300 S3 als Bezugssystem genommen und die auf dem System gemessenen Anzahl Benutzer zu 100% gesetzt. Alle anderen Systeme werden in Relation zum Bezugsystem angegeben, wobei die unterschiedlichen Lastprofile entsprechend berücksichtigt sind. Wenn Sie einen Terminal Server oder eine Terminal Server Farm planen, sollten Sie sich die Zeit nehmen, das Benutzerverhalten vorher genau zu analysieren. Welche Anwendungen müssen generell über den Terminal Server zur Verfügung gestellt werden? Welcher Benutzer nutzt wann und wie oft welche Anwendung? Wie intensiv wird die Anwendung verwendet? Welche Bildschirmauflösung und Farbtiefe verwendet der Client? Welches Netzwerk und Protokoll wird verwendet? Welche Antwortzeiten werden erwartet? Bei größeren Konfigurationen sollte auf eine Pilotphase unter realen Bedingungen nicht verzichtet werden. Fujitsu Technology Solutions 2009 Seite 30 (46)

31 Analysewerkzeuge Bei Performance-Problemen oder auch vor der Migration von Systemen ist es hilfreich, die Terminal Server Umgebung zu analysieren. Je nach gewünschtem Detaillierungsgrad eignen sich verschiedene mehr oder weniger aufwändige Methoden, um sich einen Überblick über die aktuelle Situation zu verschaffen oder einen zeitlichen Ablauf der Systemauslastung aufzuzeichnen. Im Folgenden werden für die Analyse von Systemen nützliche Werkzeuge kurz vorgestellt. Eine ausführliche Beschreibung der Tools würde den Rahmen dieses Papiers sprengen. Task-Manager Am bekanntesten ist der Windows Task-Manager»taskmgr.exe«, den man in allen Windows Server Betriebssystemen, aber auch in Windows XP findet. Mit dem Task-Manager kann man sich einen schnellen Überblick über die aktuelle Systemauslastung verschaffen, weiterhin können laufende Anwendungen bzw. Prozesse und die Netzwerkauslastung angezeigt werden. Als Administrator kann man auch Prozesse beenden oder deren Prioritäten verändern. Zum Aufrufen klickt man mit der rechten Maustaste auf eine leere Stelle in der Taskbar und dann klickt man auf»task-manager«. Das Programm selbst stellt eine ausführliche Online-Hilfe bereit; weitere Informationen findet man auch bei Microsoft im Internet. Auf Terminal Server Systemen empfiehlt es sich, unter»prozesse«die Einstellung»Prozesse aller Benutzer anzeigen«zu selektieren. Hilfreich kann auch bei»systemleistung«unter»ansicht«die Einstellung»Kernel-Zeiten anzeigen«sein, um den CPU-Verbrauch des Kernels einzeln zu überwachen. Sysinternals Process Explorer Detailreichere Informationen bietet das Freeware-Programm»Process Explorer«, das von den beiden Windows Spezialisten Mark Russinovich und Bryce Cogswell kostenlos unter bereitgestellt wird. Es bietet eine wesentlich größere Funktionalität als der Windows Task-Manager. Hervorzuheben sind die Baumansicht der Prozesse, die gerade bei Terminal Server Systemen eine einfache Zuordnung von Prozessen zu Benutzern ermöglicht, und die erweiterte»system Information«- Anzeige. Der»Process Explorer«muss nicht installiert werden, kann aber auch an Stelle des Task-Managers in Windows integriert werden. Dieses Programm liefert eine Online-Hilfe mit, aber auch die Sysinternals-Web-Seite liefert nützliche Informationen. Performance Monitor Um den Verlauf des Ressourcenverbrauchs zu dokumentieren und zu speichern, sind o.g. Tools weniger geeignet. Hierzu gibt es in allen aktuellen Windows Versionen den System Monitor, oder auch Performance Monitor genannt, mit dem man über einen längeren Zeitraum so genannte Performance Counter beobachten kann. Performance Counter sind Objekt-spezifisch gruppiert, teilweise gibt es sie auch in verschiedenen Instanzen, wenn ein Objekt mehrfach vorhanden ist. Beispielsweise gibt es für das Objekt»Prozessor«einen Performance Counter»%Processor Time«, wobei dann bei einem Multiprozessorsystem eine Instanz pro CPU existiert. Nicht alle Performance Counter sind in Windows bereits vorhanden, sondern viele Anwendungen wie z.b. Citrix Presentation Server bringen ihre eigenen Performance Counter mit, die sich in das Betriebssystem integrieren und über den Performance Monitor abgefragt werden können. Die Performance-Daten kann man entweder am Bildschirm verfolgen oder, besser, in eine Datei schreiben und offline analysieren. Es können nicht nur Performance Counter des lokalen Systems ausgewertet werden, sondern auch von entfernten Servern, die entsprechenden Zugriffsrechte vorausgesetzt. Das Programm, das sich unter»perfmon.exe«aufrufen lässt, ist in der Windows Hilfe oder in Fujitsu Technology Solutions 2009 Seite 31 (46)

32 Microsoft Artikeln im Internet beschrieben, weiterhin gibt es für jeden einzelnen Performance Counter unter»erklärung«eine Erläuterung. Zu beachten ist, dass der Performance Monitor auch eine Windows Anwendung ist, die Rechenzeit benötigt. Es kann vorkommen, dass der Performance Monitor bei extremer Server-Überlastung selbst keine Performance-Daten ermitteln und anzeigen kann, dann sind die entsprechenden Werte 0 oder leer. Windows Performance Toolkit Mit dem Windows Performance Tools (WPT) Kit stellt Microsoft eine offizielle Sammlung von Tools zur freien Verfügung. Sie eignen sich zum Vermessen und Analysieren von System- und Anwendungsverhalten sowie des Ressourcenverbrauchs auf Windows Vista, Windows Server 2008 und späteren Windows Betriebssystemen. Diese Tools beruhen auf dem Event Tracing for Windows (ETW) und verursachen daher nur sehr geringen Overhead. Durch das ETW können Events des Kernels oder der Applikationen, wie z.b. Context Switches, Interrupts, Thread Creation und viele mehr, in Trace-Dateien aufgezeichnet und zu einem späteren Zeitpunkt ausgewertet und als übersichtliche Graphen oder Tabellen dargestellt werden. Sie ermöglichen daher eine sehr detaillierte Analyse eines Windows Systemverhaltens. Aktuell enthält die Sammlung drei Programme, die von der Kommandozeile aus ausgeführt werden können: Xperf Xperfview Xbootmgr Event tracing durchführen und auswerten Visionalisierung der Performance-Daten Erstellen eines Traces des Bootvorganges Die grundsätzliche Vorgehensweise erfolgt in vier Schritten: 1) Starten des Event Tracing durch Aufruf von»xperf«; über Parameter kann genau gesteuert werden, was getraced werden soll. 2) Durchführen der zu analysierenden Szenerie. 3) Stoppen des Event Tracing durch Aufruf von»xperf«; alle zur Analyse notwendigen Daten werden ins Trace-File geschrieben. 4) Auswerten des Trace-Files mittels»xperf«oder auch Visionalisierung über»xperfview«; kann auch auf einer anderen Maschine erfolgen. Beispiel eines Xperfview-Graph für CPU-Sampling: Fujitsu Technology Solutions 2009 Seite 32 (46)

33 Beispiel eines Xperfview-Graph für Disk IO Sampling: Das Windows Performance Tool Kit ermöglicht eine sehr viel mehr in die Tiefe gehende Analyse eines Systemverhaltens als der Performance Monitor. Dadurch, dass die Aufzeichnung der Events über einen längeren Zeitraum oder auf einem durch viele Prozesse stark belasteten System zu sehr großen Trace Files führt, ist dieses Tool aber eher für die Analyse einer Momentaufnahme geeignet, während z.b. der Performance Monitor zur Analyse eines Systemverhalten über einen längeren Zeitraum, z.b. einen Tag oder eine Nacht eingesetzt werden kann. Windows Performance Analyzer kann nur eingeschränkt auf Windows XP bzw. Windows Server 2003 eingesetzt werden. Es können zwar auch Event Traces geschrieben werden, allerdings müssen alle Analysen, die Trace-Dekodierung enthalten das beinhaltet auch die graphische Aufbereitung mittels»xperfview«auf einem Windows Vista bzw. Windows Server 2008 System erfolgen. Fujitsu Technology Solutions 2009 Seite 33 (46)

34 Citrix Resource Manager In größeren Terminal Server Konfigurationen mit Citrix Presentation Server Enterprise Edition kommt vielleicht auch der Resource Manager von Citrix zum Einsatz. Er bietet eine benutzerfreundlichere Sicht auf die für den Citrix Presentation Server relevanten Performance Counter und darüber hinaus noch eine Schwellwertüberwachung mit Benachrichtigung des Administrators. Die Schwellwerte sind schon auf bestimmte Werte voreingestellt, können aber bei Bedarf angepasst werden. Da diese Schwellwerte in der Citrix Resource Manager Software fest eingestellt sind, ist es fraglich, ob sie der Vielzahl der heute verfügbaren Leistungsvarianten von Server-Systemen ohne individuelle Anpassung gerecht werden können. Auf einem Citrix Presentation Server 4.0 Terminal Server unter Windows Server 2003 Enterprise Edition 32- bit mit 16 GB Hauptspeicher und Gigabit LAN sind beispielsweise folgende Werte voreingestellt: Objekt Counter Warnung Fehler Citrix MetaFrame Presentation Server Data Store Connection Failure 6 60 Logical Disk % Disk Time Logical Disk % Free Space 10 5 Memory Available Bytes Memory Pages/sec Network Interface Bytes Total/sec Paging File % Usage Processor % Interrupt Time Processor % Processor Time System Context Switches/sec Terminal Services Active Sessions Terminal Services Inactive Sessions Wenn die Schwellwerte jedoch auf den Normalbetrieb (Baseline) eines Citrix Systems angepasst werden, dann lösen Überschreitungen rechtzeitig eine Warnung oder einen Alarm aus und helfen dem Administrator, einen Engpass frühzeitig zu erkennen. Für den Citrix Resource Manager sei auf die Dokumentation von Citrix verwiesen. Fujitsu Technology Solutions 2009 Seite 34 (46)

35 Microsoft Operations Manager (MOM) 2005 Microsoft stellt mit dem Produkt Microsoft Operations Manager (MOM) 2005 eine leistungsfähige Software zur Verfügung, mit der Ereignisse und Systemleistung verschiedener Server-Gruppen im Firmennetzwerk überwacht werden können. MOM bietet proaktive Benachrichtigungen im Warnungs- und Fehlerfall und erstellt Berichte und Trendanalysen. MOM bedient sich dabei existierenden Windows Mitteln wie der Ereignisanzeige, liest die Performance Counter aus und überwacht Dienste, jedoch komfortabel für ganze Gruppen von Servern. Die Ergebnisse werden in einer SQL Datenbank gespeichert. Zusätzliche Management Packs für MOM werden von Microsoft und anderen Anbietern für ihre Produkte zur Verfügung gestellt und hinterlegen weitere System- oder Anwendungs-spezifische Regelwerke in der MOM- Datenbank. So kann MOM nicht nur Terminal Server, sondern eine Vielzahl von verschiedenen Server- Typen gleichzeitig überwachen. Für die Terminal Services kann das»microsoft Terminal Server MOM 2005 Management Pack«hinzugefügt werden, das Terminal Server-spezifische Regeln und Berichte für die folgenden Komponenten mitbringt Terminal Services Terminal Services Licensing Server Session Directory Server sowie ein Performance Monitoring anbietet. Beispielsweise wird eine Warnung ausgegeben, wenn mehr als 520 Terminal Server Sessions aktiv sind oder die Prozessorauslastung einer Session über einen Zeitraum von 15 Minuten über 80% liegt. Ein Fehler wird angezeigt, wenn mehr als 20 Terminal Server Sitzungen inaktiv sind oder die Cachetrefferrate weniger als 99% beträgt. Diese vordefinierten Regeln müssen an die kundenspezifischen Gegebenheiten angepasst werden. Weiterhin können aktive und inaktive Sitzungen über gewisse Zeiträume beobachtet werden, so dass hieraus Aussagen über das Benutzerverhalten gewonnen werden können. Eine Beschreibung der Features von MOM würde den Rahmen dieses Dokumentes sprengen. Zu MOM und den einzelnen Management Packs gibt es im Internet detaillierte Beschreibungen von Microsoft. Fujitsu Technology Solutions 2009 Seite 35 (46)

36 Engpassanalyse Um eine Vorhersage zu treffen, wie sich eine existierende Terminal Server Umgebung verhält oder um bei einer Pilotinstallation die Auslastung eines Terminal Servers beurteilen zu können, ist es notwendig, selbst eine Engpassanalyse durchzuführen oder durch unseren Professional Service durchführen zu lassen. Performance-Werte aufzuzeichnen oder zu überwachen ist weniger das Problem, als die richtigen Schlüsse aus den Messwerten zu ziehen. Bevor wir im Folgenden einige wichtige Performance Counter zu den verschiedenen Performance-relevanten Server-Objekten diskutieren, werden kurz einige typische Verhaltensweisen von Performance Countern dargestellt. Wenn man einen Engpass auf einem Server- System analysiert, ist es nicht einfach, aus einem Schnappschuss von der Engpasssituation Rückschlüsse zu ziehen. Von Vorteil ist es, wenn man Erfahrungen hat, wie sich das Server-System unter verschiedenen Lasten verhält und eine Baseline zum Vergleich erstellt hat. Während man einige Messwerte wie den Netzwerkdurchsatz in Relation zum theoretisch erreichbaren Maximalwert, z.b. bei einer 100 MBit-Netzwerkverbindung, setzen kann, ist dies bei anderen Messwerten, wie z.b. Anzahl Context Switches pro Sekunde, nicht möglich. Es gibt folgende typische Kurvenverläufe bei synthetischer Last: Linear: Konstant: Die Performance-Werte steigen im gleichen Verhältnis zur Last. Kein Engpass. Logarithmisch: Die Performance Counter sind nicht abhängig von der Last, sondern konstant. Eventuell bilden sich bei unterschiedlicher Last verschiedene Stufen einer Treppenfunktion aus. Exponentiell: Bei steigender Last steigen die Performance Counter nicht weiter, sondern erreichen eine Sättigung. Dies kann ein Indiz für einen Engpass sein. Im unteren Lastbereich steigt die Kurve relativ flach an, während sie bei steigender Last überproportional wächst. Im Extremfall kann hier bereits ein weiterer Benutzer das»fass zum Überlaufen«bringen. Im Folgenden werden einzelne Performance Counter, nach Systemkomponenten gruppiert, beschrieben und diskutiert. Im Anschluss daran ist ein Beispielskript eingefügt, das nach geringen Anpassungen direkt für ein Terminal Server System übernommen werden kann. Fujitsu Technology Solutions 2009 Seite 36 (46)

37 Rechenleistung/System Die wichtigsten Performance Counter sind: \Processor(*)\% Processor Time bzw. \Processor(_Total)\% Processor Time \System\Processor Queue Length»% Processor Time«ist die insgesamt verbrauchte Rechenzeit. Auf jedem Windows System läuft ein»leerlaufprozess«, den man mit dem Task-Manager oder Process Explorer auch sehen kann. Alle CPU Zeit, die dieser idle Prozess nicht bekommt, ist»% Processor Time«. Bei»% Processor Time«gibt es mehrere Instanzen, eine pro logische CPU, die Windows kennt. Unsere unten aufgeführte Beispielkonfiguration zeichnet mit dem Objekt»Processor(*)«alle vorhandenen Prozessoren auf und deren Summe. Die Auslastung der einzelnen Prozessoren muss nicht immer gleich hoch sein, gerade im Niedriglastbereich und mit Hyper-Threading ist das oft der Fall. Weiterhin wird beim normalen Arbeiten mit Terminal Server Anwendungen selten eine in Summe 100%ige CPU-Auslastung erreicht. Je mehr logische Prozessoren parallel arbeiten, desto niedriger kann sich der Durchschnittswert der CPU-Auslastung darstellen, auch wenn der Terminal Server bereits überlastet ist.»processor Queue Length«bezeichnet die Anzahl Threads, die auf ihre Ausführung warten. Dieser Counter ist nur einmal pro System vorhanden, also nicht CPU-spezifisch. Daher sollte dieser Wert die Anzahl der Prozessoren nicht dauerhaft übersteigen. Normalerweise steigen»% Processor Time«und»Processor Queue Length«(PQL) bei Belastung des Servers gemeinsam an. Nebenstehende Grafik zeigt einen typischen Verlauf der CPU Zeit und der»processor Queue Length«, während die Last auf dem Terminal Server zunehmend gesteigert wird. Kritisch sind % CPU-Zeiten ab 80% zusammen mit hohen Peaks der PQL-Kurve, die dann auch dauerhaft auf einem höheren Niveau bleibt. Es kann jedoch auch Situationen geben, wo eine Vielzahl von kleinen Prozessen auf ihre Ausführung wartet und das System allein schon durch die Verwaltung der Prozesse überlastet wird, obwohl die benötigten CPU-Ressourcen noch verfügbar wären. Zusätzliche Performance Counter: \System\Context Switches/sec \System\System Calls/sec \System\Processes \Processor(*)\Interrupts/sec bzw. \Processor(_Total)\Interrupts/sec»System Calls/sec«zählt die Anzahl Aufrufe an das System pro Sekunde.»Context Switches/sec«zählt die Anzahl Kontextwechsel pro Sekunde, also Wechsel zwischen Threads oder zwischen Benutzerprogrammen und Kernel-Aktivitäten.»Processes«ist die Anzahl der aktuell ausgeführten Prozesse.»Interrupts/sec«ist ein Counter, den es pro Prozessorinstanz und als Durchschnitt aller Prozessoren gibt. Interrupts sind meist durch Hardware wie Netzwerkkarten, Tastatur, Maus, Systemuhr, usw. initiierte Ereignisse, die der Prozessor bearbeiten muss. Zu beachten ist, dass das Windows in der x64 Edition deutlich höhere Werte bei Interrupts/sec anzeigt als das 32-bit Windows. Dieser Unterschied liegt allerdings einzig in der Zählung der Interrupts, da das 64-bit Windows auch die Interrupt-Weiterleitungen zwischen den Prozessoren dokumentiert, die unter dem 32-bit Windows nicht mitgezählt wurden. Diese Counter steigen normalerweise zusammen mit der benötigten Rechenleistung an. Bedenklich ist es, wenn diese Kurven eine Sättigung erreichen, was bedeutet, dass das System nicht mehr von diesen Ereignissen verarbeiten kann. Eine Sättigung kann am besten über einen längeren Zeitraum beurteilt werden, im Zusammenhang mit den anderen Performance Countern. Die Anzahl Benutzer steigt deutlich steiler als der aufgezeichnete Performance Counter. Ein CPU-Engpass kann auch durch fehlerhafte Anwendungen ausgelöst werden, siehe Kapitel Applikationen. Fujitsu Technology Solutions 2009 Seite 37 (46)

38 Arbeitsspeicher Die wichtigsten Performance Counter bzgl. der Arbeitsspeicherauslastung sind: \Memory\Available MBytes \Memory\Pages Input/sec \Process(_Total)\Working Set»Available MBytes«ist der aktuell freie physikalische Hauptspeicher in MB.»Pages Input/sec«zeigt die Anzahl der Seiteneinlagerungen pro Sekunde. Der»Working Set«einer Anwendung ist der Speicher, den sie bereits verwendet hat. Nebenstehende Performance- Aufzeichnung wurde auf einem PRIMERGY Server erstellt, der absichtlich in einen Hauptspeicherengpass getrieben wurde. Eine Eigenschaft des Windows Betriebssystems ist hierbei zu erkennen: wenn genügend Hauptspeicher zur Verfügung steht, wird auch mehr Speicher belegt. Erst wenn der freie Speicher unter einen bestimmten Schwellwert fällt, wird»aufgeräumt«und der Speicher außerhalb des»working Set«ausgelagert. So kann man an einem System, das nicht im Speichergrenzbereich betrieben wird, den wirklichen Speicherbedarf nicht unbedingt ablesen. In der hier provozierten Engpasssituation werden jedoch exzessive Paging- Aktivitäten sichtbar. Der Speicherengpass deutet sich bereits an, wenn»available MBytes«unter einen Schwellwert fällt und Windows deshalb den»working Set«verkleinert. Gleichzeitig steigen die Paging- Aktivitäten (»Pages Input/sec«) an. Wenn nun noch weiterer Speicher gebraucht wird, dann wird schrittweise der»working Set«weiter verkleinert und die Paging-Vorgänge steigen deutlich an. Auch der Performance Counter»Paging File\%Usage«steigt entsprechend an. Auch die folgenden Performance Counter können weiteren Aufschluss über die Auslastung des Arbeitsspeichers geben: \Memory\Committed Bytes \Memory\Pages Output/sec \Memory\Pages Faults/sec \Paging File(\??\C:\pagefile.sys)\% Usage In»Committed Bytes«wird angegeben, wie viel virtueller Hauptspeicher den laufenden Anwendungen zugesagt und im Pagefile reserviert wurde. Hieran kann man ablesen, ob das System in einen Engpass mit dem virtuellen Adressraum gerät.»pages Output/sec«zeigt die Anzahl der Seitenauslagerungen pro Sekunde, durch die physikalischer Hauptspeicher freigegeben wird, indem die Daten auf die Festplatte geschrieben werden. Auch wenn ausreichend Arbeitsspeicher vorhanden ist, findet eine moderate Zahl von Auslagerung statt. Erst wenn dieser Wert sprunghaft ansteigt, liegt ein Speicherengpass vor. Insbesondere ist darauf zu achten, dass dieser Wert mit der Leistungsfähigkeit der Festplatte harmoniert, auf der das Pagefile liegt.»pages Faults/sec«ist ein Durchschnittswert der Seitenfehler pro Sekunde, beinhaltet aber sowohl Seiteneinlagerungen aus dem physikalischen Hauptspeicher (»soft fault«) als auch Zugriffe auf die Festplatte (»hard fault«).»paging File\%Usage«des Pagefiles ist dessen Belegung in Prozent. Eine geringe Belegung des Pagefiles ist normal, auch wenn genügend RAM vorhanden ist. Wenn diese jedoch signifikant ansteigt, könnte ein Hauptspeicherengpass vorliegen. Dies wird durch die anderen Performance Counter der Paging-Aktivitäten untermauert. Ein Engpass des Arbeitsspeichers geht direkt Hand in Hand mit einem Ansteigen der Disk Counter auf der Festplatte, die das Pagefile beherbergt (siehe Kapitel Engpassanalyse - Disk-Subsystem). Fujitsu Technology Solutions 2009 Seite 38 (46)

39 Betriebssystemressourcen Der wichtigste Performance Counter, an dem man die Gesundheit des Betriebssystems ablesen kann, ist: \Cache\Copy Read Hits %»Copy Read Hits %«ist der prozentuale Anteil der erfolgreichen Lesevorgänge aus dem Systemcache. Werden Daten im Systemcache gefunden, so erübrigt sich ein Festplattenzugriff, was in einem enormen Performance-Gewinn resultiert. Laut Microsoft sollte dieser Anteil immer über 95% liegen. Allerdings kann sich bei diesem Performance Counter bereits eine Verschlechterung von wenigen Prozentpunkten durch eine verzögerte Reaktion des Terminal Servers bemerkbar machen. Im Idealfall liegt»copy Read Hits %«während des eingeschwungenen Server-Betriebs über 99%. Ein 32-bit-Betriebssystem hat im Vergleich zum 64-bit-Betriebssystem durch den limitierten Kernel-Adressraum auch einen kleineren Systemcache. Da speziell Engpässe des Betriebssystems im Terminal Server Umfeld untersucht werden, sollten folgende zusätzliche Performance Counter auf jeden Fall mit betrachtet werden: \Memory\Free System Page Table Entries \Memory\Pool Nonpaged Bytes \Memory\Pool Paged Bytes»Free System Page Table Entries«zeigt die Anzahl der freien Einträge in der System Page Table. Ein Engpass dieser Betriebssystemressource ist erreicht, wenn nur noch wenige 1000 Einträge frei sind.»pool Nonpaged Bytes«ist die Anzahl Bytes, die aktuell für den Nonpaged Pool verwendet werden. Im Nonpaged Pool speichert das Betriebssystem alle Daten, die immer im Hauptspeicher gehalten werden müssen und nicht in das Pagefile geschrieben werden dürfen.»pool Paged Bytes«ist die Anzahl Bytes, die aktuell für den Paged Pool verwendet werden. Im Paged Pool liegen die Systemspeicherbereiche, die in das Pagefile ausgelagert werden können. Auf Windows Server bit-Betriebssystemen sind diese Speicherbereiche limitiert und nicht erweiterbar, so dass diese an ihre Grenzen stoßen können, wenn viele Benutzer auf dem Terminal Server arbeiten. Ein größerer Speicherausbau führt nicht zu größeren Kernel- Strukturen, sondern es wird im Gegenteil noch mehr Kernel-Speicher durch die Verwaltung und die Adressierung dieser Datenbereiche belegt. Nebenstehende Grafik zeigt eine solche Situation, bei der bei einem Terminal Server ein Engpass der Betriebssystemressourcen durch kontinuierliche Erhöhung der Benutzerlast provoziert wurde. Zur Verdeutlichung wird zusätzlich der Performance Counter»Working Set«dargestellt. Man erkennt vier Phasen bei der Server-Belastung. In der ersten Phase ist der Terminal Server performant, die Trefferrate im Systemcache liegt fast bei 100%, es sind noch genug freie PTEs vorhanden und der Working Set sowie der Paged Pool und der Nonpaged Pool kann mit der Anzahl Benutzer gesteigert werden. In der zweiten Phase fällt die Trefferrate des Systemcaches ab. Der Paged Pool erfährt eine Sättigung. Die Performance wird sich langsam verschlechtern. In der dritten Phase ist die Effizienz des Systemcaches deutlich herabgesetzt. während durch Paging-Aktivitäten noch Paged Pool Ressourcen freigeschaufelt werden konnten. Die Terminal Server Performance wird durch fehlende Kapazitäten im Systemcache gemeinsam mit erhöhten Plattenaktivitäten jedoch nicht mehr befriedigend sein. Überlastet man das System über diese Phase hinaus, dann erkennt man die Sättigung des Paged Pools. Auch der»working Set«kann nicht mehr gesteigert werden und die freien PTEs sind auf einem Minimalwert angekommen. Neben einer schlechten Terminal Server Performance wird sich ein Teil der Benutzer auch nicht mehr anmelden können, oder Anwendungen können nicht mehr gestartet oder bedient werden. Das System hat, im Gegensatz zu dem im Abschnitt Arbeitsspeicher gezeigten Fall eines Hauptspeicherengpasses, jedoch noch genügend freien physikalischen Speicher. In diesem Fall hatte das System am Ende der Aufzeichnung noch 26 GB von 32 GB physikalischem Hauptspeicher frei. Fujitsu Technology Solutions 2009 Seite 39 (46)

40 Disk-Subsystem Der wichtigste Performance Counter zur Beurteilung der Festplattenauslastung ist: \PhysicalDisk(*)\Avg. Disk Queue Length bzw. \LogicalDisk(*)\Avg. Disk Queue Length Hierbei zeichnen die Performance Counter für die»physicaldisk«alle Aktivitäten an einem physikalischen Laufwerk auf, während das»logicaldisk«objekt diese nach den einzelnen Partitionen, z.b. C: oder D:, unterteilt. Wird ein RAID-Controller, SAN oder iscsi verwendet, so bezieht sich der Counter»PhysicalDisk«jedoch nicht, wie der Name suggeriert, auf die physikalische Platte, sondern auf den RAID-Verband bzw. die LUN. Der Counter»Avg. Disk Queue Length«ist der Durchschnitt der Festplattenwarteschlange für Lese- und Schreibaufträge, man kann aber auch für Lese- und Schreiboperationen getrennte Counter aktivieren. Dieser Performance Counter ist ein signifikanter Indikator für die Belastung des Disk-Subsystems und sollte nicht dauerhaft größer sein als 1 pro Festplatte, die netto zur Verfügung steht. In einem RAID 1 Verband aus zwei Festplatten also nicht dauerhaft größer als 1, in einem RAID 1+0 aus 6 Festplatten nicht dauerhaft größer als 3. Die Beispielgrafik zeigt die»avg. Disk Queue Length«für eine Konfiguration mit einer Festplatte, bei der der Wert unter 1 liegen sollte. Während im ersten Zeitraum dieser Aufzeichnung die Festplatte nicht wesentlich belastet wird, so ist gegen Ende der Messung das Disk-Subsystem deutlich überlastet. Die Performance des Disk-Subsystems, auf dem das Pagefile liegt, sollte immer gemeinsam mit dem Arbeitsspeicher betrachtet werden. Wenn der Arbeitsspeicher knapp wird, lagert Windows Teile des Speichers in das Pagefile auf der Festplatte aus und liest diese später wieder ein, was zu deutlich erhöhten Plattenaktivitäten auf der Festplatte führt, auf der das Pagefile liegt. Zusätzliche Performance Counter des \PhysicalDisk(*) bzw. \LogicalDisk(*) Objektes, die weiteren Aufschluss über die Plattenaktivität geben können: Avg. Disk Bytes/Read Durchschnitt der Auftragsgröße beim Lesen Avg. Disk Bytes/Write Durchschnitt der Auftragsgröße beim Schreiben Avg. Disk sec/read Durchschnittswert der pro Leseauftrag benötigte Zeit in Sekunden Avg. Disk sec/write Durchschnittswert der pro Schreibauftrag benötigte Zeit in Sekunden Disk Read Bytes/sec Gesamtanzahl der gelesenen Bytes pro Sekunde Disk Reads/sec Gesamtanzahl der Lesevorgänge pro Sekunde Disk Write Bytes/sec Gesamtanzahl der geschriebenen Bytes pro Sekunde Disk Writes/sec Gesamtanzahl der Schreibvorgänge pro Sekunde Der vielfach verwendete Counter»% Disk Time«ist nicht zu empfehlen, da er in heutigen Windows Versionen genau dem Hundertfachen von»avg. Disk Queue Length«entspricht. Fujitsu Technology Solutions 2009 Seite 40 (46)

41 Aus diesen Performance Countern lässt sich das Zugriffsmuster auf die Festplatten ablesen, d.h. die gelesenen und geschriebenen Blockgrößen, und die Latenzzeiten (»Avg. Disk sec«) beim Lesen und Schreiben. Diese Messwerte sollten in dem Fall als Zusatzinformation ausgewertet werden, wenn die»avg. Disk Queue Length«auf einen Festplattenengpass hindeutet. Mit der Anzahl von Schreib- und Leseaufträgen pro Sekunde können in Verbindung mit der im Durchschnitt genutzten Auftragsgröße und dem verwendeten RAID-Level ebenfalls Rückschlüsse auf die Auslastung des Disk-Subsystems getroffen werden. Zum Sizing von Disk-Subsystemen wurde ein eigenes White Paper»Performance Report Modular RAID für PRIMERGY«[L5] erstellt. Zu beachten ist auch, dass ein Disk-Subsystem, das über iscsi angeschlossen ist, zusätzlich zu den Performance Countern der Festplattenobjekte bei den Performance Countern der Netzwerkkarte auftaucht, die im Folgenden beschrieben werden. Netzwerk Für einen ersten Blick auf die Netzwerkauslastung reicht der Task-Manager aus. Auf der Seite»Netzwerk«(»Networking«) erhält man schnell einen Überblick über die»netzwerkauslastung«(»network Utilization«) der einzelnen Netzwerkkarten und deren»übertragungsrate«(»link Speed«). Bei einer Performance Monitor-Aufzeichnung sollten die folgenden Performance Counter mit berücksichtigt werden: \Network Interface(*)\Bytes Sent/sec \Network Interface(*)\Bytes Received/sec»Bytes Sent/sec«und»Bytes Received/sec«zählen die aus Sicht des Servers gesendeten und empfangenen Daten in Bytes. Zusätzlich ist es auch sinnvoll die Performance Counter \Network Interface(*)\Packets Received/sec \Network Interface(*)\Packets Sent/sec zu betrachten.»packets Sent/sec«und»Packets Received/sec«sind die Anzahl der aus Sicht des Servers gesendeten und empfangenen Datenpakete. Aus dem Verhältnis der Datenbytes und der Anzahl der Pakete lässt sich die durchschnittliche Paketgröße ermitteln. Je größer die Netzwerkpakete, desto höher die mögliche Netzwerkauslastung. Die Protokolle RDP oder ICA, die ein Terminal Server zwischen Client und Server verwendet, beinhalten nicht sehr große Datenpakete. Eine 100% Auslastung eines 100 MBit-Netzwerkes wird sich daher kaum beobachten lassen. Das ICA-Protokoll des Citrix Presentation Server ist dabei noch etwas sparsamer als das RDP-Protokoll des Microsoft Terminal Services. Neben der Client-Server-Kommunikation entsteht in den meisten Anwendungsszenarien jedoch auch weiterer Netzwerkverkehr zu Back-End-Server, ins Internet, oder bei Verwendung eines Netzwerk-basierten Disk-Subsystem, wie NAS oder iscsi Datentransfer zum Disk-Subsystem. Es ist dringend zu empfehlen, dass für diese unterschiedlichen Datenströme dedizierte Netzwerkinterfaces verwendet werden. Die verschiedenen Netzwerkinterfaces können anstelle des (*) im Performance Monitor auch einzeln mit ihrem Namen selektiert werden. Wenn (*), wie im Beispiel oben, als Netzwerkkartenbezeichnung angegeben wird, dann werden alle im System verfügbaren Netzwerkkarten aufgezeichnet. Hierzu gehört auch das Loopback-Interface, auf dem normalerweise nicht viel Netzwerkverkehr stattfindet. Zu beachten ist, dass sich mit dem Performance Monitor oder dem Task-Manager nur die Auslastung des Netzwerkes aus Sicht des Terminal Servers analysieren lässt. Datenverkehr anderer Server und Clients auf dem Netzwerk kann nicht erfasst werden. Oft ist jedoch nicht das Server-seitige Netzwerk selbst zu klein dimensioniert, sondern die Probleme können beispielsweise von fehlerhaften oder falsch konfigurierten Komponenten herrühren oder durch vielfältige Problemen bei der Verbindung dieser Komponenten entstehen. An dieser Stelle sollte man einen Netzwerkspezialisten hinzuziehen. Fujitsu Technology Solutions 2009 Seite 41 (46)

42 Terminal Server Der Microsoft Terminal Server selbst liefert nicht viele Performance Counter. Jedoch bietet der Terminal Server unter dem Objekt»Terminal Services Sessions«Performance Counter pro Session für eine detaillierter Auswertung einzelner Sitzungen an. Die Anzahl Terminal Server Verbindungen sollte immer mitgeschrieben werden, um die anderen Performance Counter in Relation zur Anzahl verbundenen Benutzer setzen zu können: \Terminal Services\Active Sessions Es ist ein Unterschied, ob der Benutzer die Verbindung zum Terminal Server beendet, indem er sich abmeldet (»Logoff«) oder ob er mit einem»disconnect«die Verbindung nur unterbricht. Im letzteren Fall läuft die Anwendung auf dem Terminal Server weiter und gibt ihre Ressourcen nicht frei. Der Benutzer kann seine Arbeit dann an dieser Stelle fortsetzen. Manche Anwendungen brauchen auch CPU-Ressourcen, während die Verbindung getrennt ist. Daher sollte die Anzahl der inaktiven Verbindungen (»Inactive Sessions«) \Terminal Services\Inactive Sessions ebenfalls mitprotokolliert werden. Diese beiden Parameter gelten gleichwohl für die Microsoft Terminal Services als auch für den Citrix Presentation Server. Citrix selbst liefert auch Performance-Objekte mit verschiedenen Performance Countern mit. Folgende Performance Objekte werden installiert:»citrix CPU Utilization Mgmt User«Counter für das Feature»CPU Utilization ManagementCitrix IMA Networking«Counter für Anzahl Verbindungen und Netzwerklast»Citrix MetaFrame Presentation Server«Counter u.a. für Data Store, Local Host Cache, Licensing»ICA Session«(für einzelne Sessions oder gesamt»_server Total«) Counter spezifisch für ICA-Session Diese sind jedoch eher für spezielle Auswertungen geeignet und weniger für eine allgemeine Performance- Analyse eines Terminal Servers. Fujitsu Technology Solutions 2009 Seite 42 (46)

43 Applikationen Eine fehlerhafte Anwendung kann eine CPU zeitweise oder permanent voll belasten, und gerade auf einem Terminal Server kann das fatale Auswirkungen auf die Gesamtleistung des Systems haben, da diese Anwendung auch mehrfach gestartet sein kann. Wenn die Anwendung einen Thread besitzt, der z.b. in einer Endlosschleife läuft oder»aktiv wartet«, dann belegt dieser maximal»100% / #CPUs«Prozessorzeit. Auf einem System mit zwei logischen Prozessoren also 50%, auf einem System mit vier logischen CPUs 25%. Je mehr logische CPUs das System hat, desto weniger fällt so ein Programm auf. Bei CPU-Engpässen sollte immer überprüft werden, ob es solche Anwendungen gibt, die dauerhaft genau diese Prozentzahl an CPU- Leistung benötigen. Kurzfristige Lastspitzen einer Anwendung sind hingegen völlig normal. Einen ersten Blick auf die Anwendungen ermöglicht der Task-Manager bzw. der Process Explorer. Folgender Screenshot zeigt einen synthetischen Lastsimulator auf einem PRIMERGY System mit acht logischen Prozessoren, der eine Endlosschleife simuliert. Der Process Explorer weist 12.50% CPU Last aus, d.h. diese eine Anwendung lastet einen Prozessorkern vollständig aus. Ein solches Verhalten ist oft in Desktop-Anwendungen zu finden, die für einen einzelnen Benutzer geschrieben und daher für eine Terminal Server Umgebung nur bedingt geeignet sind. Wenn Citrix Presentation Server 4.0 eingesetzt wird, dann kann man solche Anwendungen auch in ihrer Rechenleistung beschränken. Diese Einschränkung greift nur, wenn insgesamt zu wenig CPU Ressourcen zur Verfügung stehen. Auch der Speicherbedarf einer Applikation sollte überprüft werden. Unser synthetischer Lastsimulator hat ca. 1.5 GB virtuellen Speicher belegt, allerdings ist der»working Set«nur 5.3 MB groß. Diese Anwendung hat zwar eine Menge Speicher reserviert, hat ihn jedoch nicht in Verwendung. Erst wenn die Anwendung auf dem Speicher arbeitet, vergrößert sich der»working Set«und der im System verfügbare Speicher»Available Mbytes«nimmt ab. Mit dem Performance Monitor kann man viele Performance Counter statt für das Gesamtsystem auch für einzelne laufende Anwendungen anzeigen lassen. Hierzu verwendet man das Objekt»Process«und als Instanz dann den zu überwachenden Prozess. Fujitsu Technology Solutions 2009 Seite 43 (46)

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen?

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Umgebung Getestet wurde auf einem Linux-System mit voller invis-server Installation, auf dem eine virtuelle Maschine

Mehr

Terminal Server Sizing Guide

Terminal Server Sizing Guide 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

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.5, Asura Pro 9.5, Garda 5.0...2 PlugBALANCEin 6.5, PlugCROPin 6.5, PlugFITin 6.5, PlugRECOMPOSEin 6.5, PlugSPOTin 6.5,...2 PlugTEXTin 6.5, PlugINKSAVEin 6.5, PlugWEBin

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.6, Asura Pro 9.6, Garda 5.6...2 PlugBALANCEin 6.6, PlugCROPin 6.6, PlugFITin 6.6, PlugRECOMPOSEin 6.6, PlugSPOTin 6.6,...2 PlugTEXTin 6.6, PlugINKSAVEin 6.6, PlugWEBin

Mehr

Voraussetzungen für jeden verwalteten Rechner

Voraussetzungen für jeden verwalteten Rechner Kaseya 2 (v6.1) Systemvoraussetzungen Voraussetzungen für jeden verwalteten Rechner Kaseya Agent 333 MHz CPU oder höher 128 MB RAM 30 MB freier Festplattenspeicher Netzwerkkarte oder Modem Microsoft Windows

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 10, Asura Pro 10, Garda 10...2 PlugBALANCEin 10, PlugCROPin 10, PlugFITin 10, PlugRECOMPOSEin10, PlugSPOTin 10,...2 PlugTEXTin 10, PlugINKSAVEin 10, PlugWEBin 10...2

Mehr

Systemanforderungen für MuseumPlus und emuseumplus

Systemanforderungen für MuseumPlus und emuseumplus Systemanforderungen für MuseumPlus und emuseumplus Systemanforderungen für MuseumPlus und emuseumplus Gültig ab: 01.03.2015 Neben den aufgeführten Systemvoraussetzungen gelten zusätzlich die Anforderungen,

Mehr

Ein kleines Computer-Lexikon

Ein kleines Computer-Lexikon Stefan Edelmann 10b NIS-Klasse Ein kleines Computer-Lexikon Mainboard Die Hauptplatine! Sie wird auch Motherboard genannt. An ihr wird das gesamte Computerzubehör angeschlossen: z.b. Grafikkarte Soundkarte

Mehr

Was ist PretonSaverTM... 3 PretonSaver's... 3 PretonCoordinator... 3 PretonControl... 4 PretonSaver Client... 4 PretonSaver TM Key Funktionen...

Was ist PretonSaverTM... 3 PretonSaver's... 3 PretonCoordinator... 3 PretonControl... 4 PretonSaver Client... 4 PretonSaver TM Key Funktionen... PRETON TECHNOLOGY Was ist PretonSaverTM... 3 PretonSaver's... 3 PretonCoordinator... 3 PretonControl... 4 PretonSaver Client... 4 PretonSaver TM Key Funktionen... 4 System Architekturen:... 5 Citrix and

Mehr

2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Lernziele:

2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Lernziele: 2 Die Terminaldienste Prüfungsanforderungen von Microsoft: Configuring Terminal Services o Configure Windows Server 2008 Terminal Services RemoteApp (TS RemoteApp) o Configure Terminal Services Gateway

Mehr

Systemanforderungen für MSI-Reifen Release 7

Systemanforderungen für MSI-Reifen Release 7 Systemvoraussetzung [Server] Microsoft Windows Server 2000/2003/2008* 32/64 Bit (*nicht Windows Web Server 2008) oder Microsoft Windows Small Business Server 2003/2008 Standard od. Premium (bis 75 User/Geräte)

Mehr

Systemanforderungen. Sage Personalwirtschaft

Systemanforderungen. Sage Personalwirtschaft Systemanforderungen Sage Personalwirtschaft Systemanforderungen der Sage HR Software für die Personalwirtschaft... 3 Allgemeines... 3 Betriebsysteme und Software... 4 Hardwareanforderungen... 5 Datenbankserver

Mehr

Systemanforderungen. Sage Personalwirtschaft

Systemanforderungen. Sage Personalwirtschaft Systemanforderungen Sage Personalwirtschaft Systemanforderungen der Sage HR Software für die Personalwirtschaft... 3 Allgemeines... 3 Betriebsysteme und Software... 4 Hardwareanforderungen... 5 Datenbankserver

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 10.2, Asura Pro 10.2,Garda 10.2...2 PlugBALANCEin 10.2, PlugCROPin 10.2, PlugFITin 10.2, PlugRECOMPOSEin 10.2, PlugSPOTin 10.2,...2 PlugTEXTin 10.2, PlugINKSAVEin 10.2,

Mehr

Systemanforderungen. Sage Personalwirtschaft

Systemanforderungen. Sage Personalwirtschaft Systemanforderungen Sage Personalwirtschaft Inhalt 1.1 für die Personalwirtschaft... 3 1.1.1 Allgemeines... 3 1.1.2 Betriebssysteme und Software... 3 1.2 Hinweise zur Verwendung von Microsoft Office...

Mehr

Systemanforderungen und unterstützte Software

Systemanforderungen und unterstützte Software Systemanforderungen und unterstützte Software 1. Systemanforderungen für Server und Client Diese Anforderungen gelten für den Betrieb von Sage 200 ERP Extra Version 2013 Die Übersicht beschreibt die für

Mehr

Windows x64. Wieso, Weshalb, Warum? Helge Klein http://blogs.sepago.de/helge

Windows x64. Wieso, Weshalb, Warum? Helge Klein http://blogs.sepago.de/helge Windows x64 Wieso, Weshalb, Warum? Helge Klein http://blogs.sepago.de/helge Wer ist Helge Klein? IT-Architekt bei sepago Architekt des in Citrix User Profile Manager aufgegangenen sepagoprofile x86-64

Mehr

Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003

Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003 Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003 In diesem Whitepaper werden zwei wichtige NAS Betriebssysteme gegenübergestellt und auf ihre

Mehr

theguard! NetworkManager (Gültig für Version 6.0 und höher)

theguard! NetworkManager (Gültig für Version 6.0 und höher) theguard! NetworkManager (Gültig für Version 6.0 und höher) Der theguard! NetworkManager besteht in erster Linie aus interaktiven Client-Applikationen und zentralen Communication Servern. Die Clients müssen

Mehr

Hyper-V Grundlagen der Virtualisierung

Hyper-V Grundlagen der Virtualisierung Grundlagen der Virtualisierung Was ist Virtualisierung? Eine Software-Technik, die mehrere Betriebssysteme gleichzeitig auf dem Rechner unabhängig voneinander betreibt. Eine Software-Technik, die Software

Mehr

Systemvoraussetzungen. Hardware und Software MKS AG

Systemvoraussetzungen. Hardware und Software MKS AG Goliath.NET Systemvoraussetzungen Hardware und Software MKS AG Version: 1.4 Freigegeben von: Stefan Marschall Änderungsdatum: 20.10.2013 Datum: 29.10.2013 Goliath.NET-Systemvoraussetzungen Hardware-Software.docx

Mehr

theguard! ApplicationManager Version 3.0

theguard! ApplicationManager Version 3.0 theguard! ApplicationManager Version 3.0 Stand 08/07/2007 Der ApplicationManager ist eine 3-schichtige Client-Server Applikation für die es System- Voraussetzungen in verschiedenen Ausprägungen gibt Das

Mehr

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen Learning Suite Talent Suite Compliance Suite Systemvoraussetzungen Vorwort Dieses Dokument beschreibt, welche Anforderungen an die Installationsumgebung zu stellen sind, um die Plattform unter optimalen

Mehr

Systemvoraussetzungen

Systemvoraussetzungen Systemvoraussetzungen Gültig ab Stotax Update 2013.1 1 Allgemeines... 2 2 Stotax Online Variante (ASP)... 2 3 Stotax Offline Variante (Inhouse)... 3 3.1 Einzelplatz... 3 3.1.1 Hardware... 3 3.1.2 Software...

Mehr

Die in diesem Dokument aufgelisteten Anforderungen an das Betriebssystem schließen die aktuellen Patches und Servivepacks ein.

Die in diesem Dokument aufgelisteten Anforderungen an das Betriebssystem schließen die aktuellen Patches und Servivepacks ein. Systemanforderungen Die unten angeführten Systemanforderungen für Quark Publishing Platform sind grundlegende Anforderungen, Ihre Benutzerzahl, Asset-Anzahl und Anzahl der Asset-Versionen beeinflussen

Mehr

enerpy collaborative webased workflows collaborative webbased groupware INDEX 1. Netzwerk Überblick 2. Windows Server 2008

enerpy collaborative webased workflows collaborative webbased groupware INDEX 1. Netzwerk Überblick 2. Windows Server 2008 INDEX 1. Netzwerk Überblick 2. Windows Server 2008 3. SQL Server 2008 (32 Bit & 64 Bit) 4. Benötigte Komponenten 5. Client Voraussetzungen 1 1. Netzwerk Überblick mobile Geräte über UMTS/Hotspots Zweigstelle

Mehr

theguard! NetworkManager (Gültig für Version 5.2)

theguard! NetworkManager (Gültig für Version 5.2) theguard! NetworkManager (Gültig für Version 5.2) Der theguard! NetworkManager besteht in erster Linie aus interaktiven Client-Applikationen und zentralen Communication Servern. Die Clients müssen sich

Mehr

HOB Remote Desktop Selector

HOB Remote Desktop Selector Secure Business Connectivity HOB Remote Desktop Selector für Microsoft Windows Server mit Remote Desktop Services Optimierte Performance durch HOB Load Balancing Stand 07 14 Vorteile auf einen Blick Erweitertes

Mehr

HOB Remote Desktop VPN

HOB Remote Desktop VPN HOB GmbH & Co. KG Schwadermühlstr. 3 90556 Cadolzburg Tel: 09103 / 715-0 Fax: 09103 / 715-271 E-Mail: support@hob.de Internet: www.hob.de HOB Remote Desktop VPN Sicherer Zugang mobiler Anwender und Geschäftspartner

Mehr

Systemvoraussetzungen sou.matrixx-produkte

Systemvoraussetzungen sou.matrixx-produkte Systemvoraussetzungen sou.matrixx-produkte Vorwort Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens des Verkäufers dar.

Mehr

Worry-Free Business Security Standard- und Advanced-Versionen Service Pack 1

Worry-Free Business Security Standard- und Advanced-Versionen Service Pack 1 Worry-Free Business Security Standard- und Advanced-Versionen Service Pack 1 Systemvoraussetzungen Securing Your Journey to the Cloud p c Protected Cloud ws Web Security Trend Micro Deutschland GmbH behält

Mehr

Lasttestbericht BL Bankrechner

Lasttestbericht BL Bankrechner Lasttestbericht BL Bankrechner Business-Logics GmbH Inhaltsverzeichnis 1 Testumgebung 2 1.1 Hardwareversionen........................ 2 1.2 Softwareversionen........................ 3 1.3 Datenbestand..........................

Mehr

Virtual Solution Democenter

Virtual Solution Democenter Virtual Solution Democenter Innovative Datensysteme GmbH indasys Leitzstr. 4c 70469 Stuttgart www.indasys.de vertrieb@indasys.de Virtual Solution Democenter Das Virtual Solution Democenter ist eine beispielhafte

Mehr

Systemvoraussetzungen

Systemvoraussetzungen Systemvoraussetzungen Gültig ab Stotax Update 2016.1 Stand 03 / 2015 1 Allgemeines... 2 2 Stotax Online Variante (ASP)... 2 3 Stotax Offline Variante (Inhouse)... 3 3.1 Einzelplatz... 3 3.1.1 Hardware...

Mehr

DELL On-Demand Desktop Streaming-Referenzarchitektur (ODDS) (Bedarfsbasierte Desktop- Streaming-Referenzarchitektur)

DELL On-Demand Desktop Streaming-Referenzarchitektur (ODDS) (Bedarfsbasierte Desktop- Streaming-Referenzarchitektur) DELL On-Demand Desktop Streaming-Referenzarchitektur (ODDS) (Bedarfsbasierte Desktop- Streaming-Referenzarchitektur) Ein technisches White Paper von Dell ( Dell ). Mohammed Khan Kailas Jawadekar DIESES

Mehr

Systemvoraussetzungen GS-Programme 2012

Systemvoraussetzungen GS-Programme 2012 Systemvoraussetzungen GS-Programme 2012 Voraussetzungen Kompatibilitätsvoraussetzungen Kompatibilität mit anderen GS-Produkten Die GS-Programme 2011 (GS-Auftrag, GS-Adressen) sind nur mit Applikationen

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Systemvoraussetzungen für Autodesk Revit 2015 - Produkte (gemäß Angaben von Autodesk)

Systemvoraussetzungen für Autodesk Revit 2015 - Produkte (gemäß Angaben von Autodesk) Systemvoraussetzungen für Autodesk Revit 2015 - Produkte (gemäß Angaben von Autodesk) Mindestanforderung: Einstiegskonfiguration Betriebssystem ¹ Windows 8.1 Enterprise, Pro oder Windows 8.1 CPU-Typ Single-

Mehr

Virtualisierung: Neues aus 2010 und Trends 2011

Virtualisierung: Neues aus 2010 und Trends 2011 Virtualisierung: Neues aus 2010 und Trends 2011 Werner Fischer, Technology Specialist Thomas-Krenn.AG Thomas Krenn Herbstworkshop 2010 Freyung, 24. September 2010 Agenda 1) Virtualisierungs-Software VMware

Mehr

Softwarelösungen. Systemvoraussetzung E+S Anwendung Forms11

Softwarelösungen. Systemvoraussetzung E+S Anwendung Forms11 Systemvoraussetzung Forms11 Stand 23. März 2015 Impressum E+S Unternehmensberatung für EDV GmbH Ravensberger Bleiche 2 33649 Bielefeld Telefon +49 521 94717 0 Telefax +49 521 94717 90 E-Mail info@es-software.de

Mehr

2 Virtualisierung mit Hyper-V

2 Virtualisierung mit Hyper-V Virtualisierung mit Hyper-V 2 Virtualisierung mit Hyper-V 2.1 Übersicht: Virtualisierungstechnologien von Microsoft Virtualisierung bezieht sich nicht nur auf Hardware-Virtualisierung, wie folgende Darstellung

Mehr

theguard! ApplicationManager (Version 2.4)

theguard! ApplicationManager (Version 2.4) theguard! ApplicationManager (Version 2.4) Stand 01/2005 Der ApplicationManager ist eine 3-schichtige Client-Server Applikation für die es System- Voraussetzungen in verschiedenen Ausprägungen gibt Das

Mehr

Systemvoraussetzungen

Systemvoraussetzungen Systemvoraussetzungen Gültig ab Stotax Update 2015.1 Stand 09 / 2014 1 Allgemeines... 2 2 Stotax Online Variante (ASP)... 2 3 Stotax Offline Variante (Inhouse)... 3 3.1 Einzelplatz... 3 3.1.1 Hardware...

Mehr

Worry-FreeTM. Business Security Standard- und Advanced-Versionen. Systemvoraussetzungen. Administrator s Guide. Securing Your Journey to the Cloud

Worry-FreeTM. Business Security Standard- und Advanced-Versionen. Systemvoraussetzungen. Administrator s Guide. Securing Your Journey to the Cloud Worry-FreeTM Business Security Standard- und Advanced-Versionen Securing Your Journey to the Cloud Administrator s Guide Systemvoraussetzungen Trend Micro Incorporated behält sich das Recht vor, Änderungen

Mehr

Beschreibung Mobile Office

Beschreibung Mobile Office Beschreibung Mobile Office 1. Internet / Netz Zugriff Für die Benutzung von Mobile Office ist lediglich eine Internet oder Corporate Netz Verbindung erforderlich. Nach der Verbindungsherstellung kann über

Mehr

Systemvoraussetzungen sou.matrixx-produkte

Systemvoraussetzungen sou.matrixx-produkte Systemvoraussetzungen sou.matrixx-produkte Vorwort Die in diesem Dokument enthaltenen Informationen können ohne Vorankündigung geändert werden und stellen keine Verpflichtung seitens des Verkäufers dar.

Mehr

Neues in Hyper-V Version 2

Neues in Hyper-V Version 2 Michael Korp Technical Evangelist Microsoft Deutschland GmbH http://blogs.technet.com/mkorp Neues in Hyper-V Version 2 - Virtualisieren auf die moderne Art - Windows Server 2008 R2 Hyper-V Robust Basis:

Mehr

Virtualisierung 360 Einführung in die Virtualisierung Server- und Desktopvirtualisierung mit Hyper-V

Virtualisierung 360 Einführung in die Virtualisierung Server- und Desktopvirtualisierung mit Hyper-V Virtualisierung 360 Einführung in die Virtualisierung Server- und Desktopvirtualisierung mit Hyper-V ITK-Forum Mittelstand IT TRENDS & TECHNOLOGIEN 2010 Frank Seiwerth Technologieberater Microsoft Deutschland

Mehr

Unterrichtseinheit 14

Unterrichtseinheit 14 Unterrichtseinheit 14 Einführung in die Terminaldienste Die Terminaldienste ermöglichen Mehrbenutzerzugriff auf Windows 2000. Da alle Anwendungen auf dem Server ausgeführt werden und auch die gesamte Datenverarbeitung

Mehr

Systemvoraussetzungen

Systemvoraussetzungen Systemvoraussetzungen Gültig ab Stotax Update 2014.2 Stand 05 / 2014 1 Allgemeines... 2 2 Stotax Online Variante (ASP)... 2 3 Stotax Offline Variante (Inhouse)... 3 3.1 Einzelplatz... 3 3.1.1 Hardware...

Mehr

Migration auf Windows 7 und Windows Server 2008 R2

Migration auf Windows 7 und Windows Server 2008 R2 We secure your business. (tm) Migration auf Windows 7 und Windows Server 2008 R2 BSI 2.IT-Grundschutz-Tag 29.3.2012 Andreas Salm Managing Consultant HiSolutions AG, Berlin Agenda Migration auf Windows

Mehr

1 Remotedesktopdienste (ehem. Terminal Services)

1 Remotedesktopdienste (ehem. Terminal Services) Windows Server 2008 (R2): Anwendungsserver 1 Remotedesktopdienste (ehem. Terminal Services) Die Remotedesktopdienste gehören zu den Desktopvirtualisierungsprodukten von Microsoft. Die Remotedesktopdienste

Mehr

Installationsvoraussetzungen

Installationsvoraussetzungen Installationsvoraussetzungen CHEFS CULINAR Software und Consulting GmbH & Co. KG Holtumsweg 26 47652 Weeze Telefon: 02837 80-226 Telefax: 02837 80-229 E-Mail: info@cc-softwareundconsulting.de JOMOsoft-Support:

Mehr

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25 XEN Performance Projektpraktikum Informatik Arne Klein 2008-02-26 Arne Klein () XEN Performance 2008-02-26 1 / 25 1 Virtualisierung mit XEN 2 Performance von XEN Allgemeines Netzwerk-Performance IO-Performance

Mehr

Warum also mit einem 32-Bit-System arbeiten, wenn es Systeme für 64 Bit gibt?

Warum also mit einem 32-Bit-System arbeiten, wenn es Systeme für 64 Bit gibt? Mehr als 4GB RAM mit 32-Bit Windows XP nutzen ( Mit freundlicher Erlaubnis: https://grafvondiepelrath.wordpress.com/2015/01/10/windowsxp-mit-8-gb-ram-betreiben/) Das Windows XP -32-Bit-System wird auch

Mehr

Installationsvoraussetzungen Verpflegungsmanagementsystem JOMOsoft M

Installationsvoraussetzungen Verpflegungsmanagementsystem JOMOsoft M Installationsvoraussetzungen Verpflegungsmanagementsystem JOMOsoft M JOMO GV-Partner Beratungs- & Software GmbH & Co. KG Holtumsweg 26 47652 Weeze Telefon: 02837 / 80-226 Telefax: 02837 / 80-229 E-Mail:

Mehr

Softwarelösungen. Systemvoraussetzung E+S Anwendung Forms10

Softwarelösungen. Systemvoraussetzung E+S Anwendung Forms10 Systemvoraussetzung Forms10 Stand 20. Juni 2014 Impressum E+S Unternehmensberatung für EDV GmbH Ravensberger Bleiche 2 33649 Bielefeld Telefon +49 521 94717 0 Telefax +49 521 94717 90 E-Mail info@es-software.de

Mehr

Der Nutzen und die Entscheidung für die private Cloud. Martin Constam Rechenpower in der Private Cloud 12. Mai 2014

Der Nutzen und die Entscheidung für die private Cloud. Martin Constam Rechenpower in der Private Cloud 12. Mai 2014 Der Nutzen und die Entscheidung für die private Cloud Martin Constam Rechenpower in der Private Cloud 12. Mai 2014 1 Übersicht - Wer sind wir? - Was sind unsere Aufgaben? - Hosting - Anforderungen - Entscheidung

Mehr

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 Inhaltsverzeichnis Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 1. Terminal-Server-Betrieb (SQL)... 3 1.1. Server 3 1.1.1. Terminalserver... 3 1.1.2. Datenbankserver (bei einer Datenbankgröße

Mehr

Hinweise zur Installation. CP-Suite

Hinweise zur Installation. CP-Suite Hinweise zur Installation CP-Suite Standard Hard- und Softwareempfehlungen Je nach Anwendung der Software (Strukturgröße, Anzahl der Anwender, Berechnungen innerhalb der Struktur, etc.) kann die notwendige

Mehr

Bewährte Vorgehensweisen für den Einstieg in Ihre mobile Client- Virtualisierungs-Lösung. Thomas Gande Dell Cloud Client Computing

Bewährte Vorgehensweisen für den Einstieg in Ihre mobile Client- Virtualisierungs-Lösung. Thomas Gande Dell Cloud Client Computing Bewährte Vorgehensweisen für den Einstieg in Ihre mobile Client- Virtualisierungs-Lösung Thomas Gande Dell Cloud Client Computing Dell Cloud Client Computing Expertise Referenz-Architektur ThinOS Cloud

Mehr

Systemanforderungen. Sage Personalwirtschaft

Systemanforderungen. Sage Personalwirtschaft Systemanforderungen Sage Personalwirtschaft Systemanforderungen der Sage HR Software für die Personalwirtschaft... 3 Allgemeines... 3 Betriebssysteme und Software... 4 Datenbankserver (Mindestanforderung)...

Mehr

Das Citrix Delivery Center

Das Citrix Delivery Center Das Citrix Delivery Center Die Anwendungsbereitstellung der Zukunft Marco Rosin Sales Manager Citrix Systems GmbH 15.15 16.00 Uhr, Raum B8 Herausforderungen mittelständischer Unternehmen in einer globalisierten

Mehr

DriveLock in Terminalserver Umgebungen

DriveLock in Terminalserver Umgebungen DriveLock in Terminalserver Umgebungen Technischer Artikel CenterTools Software GmbH 2011 Copyright Die in diesen Unterlagen enthaltenen Angaben und Daten, einschließlich URLs und anderen Verweisen auf

Mehr

Staatlich geprüfter EDV-Führerschein

Staatlich geprüfter EDV-Führerschein Staatlich geprüfter 1. Seit wie viel Jahren gibt es den Personal Computer? seit ~ 50 Jahren seit ~ 30 Jahren seit ~ 20 Jahren seit ~ 5 Jahren Computer gibt es schon immer. 2. Ein Computer wird auch als

Mehr

onboard, optimale Darstellung bei: 1.024 x 768, 32 Bit, bei 75 Hz Veröffentlichte Anwendung / Veröffentlichter Desktop ausgestattet mit min.

onboard, optimale Darstellung bei: 1.024 x 768, 32 Bit, bei 75 Hz Veröffentlichte Anwendung / Veröffentlichter Desktop ausgestattet mit min. Terminal Server Anforderungen Betriebssystem: Windows Server 2003 / 2008 / 2008 R2 / 2012 Grafik/ Videospeicher: Netzwerkkarte: Technologien Veröffentlichungs- Methoden: 2-fach Dual Core Prozessoren min.

Mehr

Version 2.0. Copyright 2013 DataCore Software Corp. All Rights Reserved.

Version 2.0. Copyright 2013 DataCore Software Corp. All Rights Reserved. Version 2.0 Copyright 2013 DataCore Software Corp. All Rights Reserved. VDI Virtual Desktop Infrastructure Die Desktop-Virtualisierung im Unternehmen ist die konsequente Weiterentwicklung der Server und

Mehr

Version 2.0.1 Deutsch 28.10.2014

Version 2.0.1 Deutsch 28.10.2014 Version.0. Deutsch 8.0.04 In diesem HOWTO wird beschrieben wie Sie die Performance der IAC-BOX und damit auch die Ihres Netzwerks optimieren können. Inhaltsverzeichnis.... Hinweise.... Hardware... 3..

Mehr

Systemvoraussetzungen Werkstattplanungssystem WPS

Systemvoraussetzungen Werkstattplanungssystem WPS Systemvoraussetzungen Werkstattplanungssystem WPS Allgemeiner Hinweis: Die im Folgenden genannten Systemvoraussetzungen stellen nur Richtlinien dar. Die genauen Anforderungen hängen von verschiedenen Faktoren

Mehr

Worry-Free. p c. Business Security Standard- und Advanced-Versionen. Systemvoraussetzungen. Securing Your Journey to the Cloud.

Worry-Free. p c. Business Security Standard- und Advanced-Versionen. Systemvoraussetzungen. Securing Your Journey to the Cloud. Worry-Free Business Security Standard- und Advanced-Versionen Systemvoraussetzungen Securing Your Journey to the Cloud p c Protected Cloud ws Web Security Trend Micro Incorporated behält sich das Recht

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Avira Professional / Server Security. Date

Avira Professional / Server Security. Date Date Agenda Wozu benötige ich einen Virenschutz für Workstations/Server? Systemanforderungen der Avira Professional Security Was bietet die Avira Professional Security? Systemanforderungen der Avira Professional

Mehr

Virtual Desktop Infrastructure: Das Backbone für Hosted Desktops. Ralf Schnell

Virtual Desktop Infrastructure: Das Backbone für Hosted Desktops. Ralf Schnell Virtual Desktop Infrastructure: Das Backbone für Hosted Desktops Ralf Schnell WAN Optimization Citrix Branch Repeater WAN WAN Optimization Citrix Branch Repeater Secure Remote Access Infrastructure Internet

Mehr

Systemanforderungen Daten und Fakten

Systemanforderungen Daten und Fakten Daten und Fakten NTConsult GmbH Lanterstr. 9 D-46539 Dinslaken fon: +49 2064 4765-0 fax: +49 2064 4765-55 www.ntconsult.de Inhaltsverzeichnis 1. für die Online-Dokumentation... 3 2. Server... 3 2.1 Allgemein...

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

INDEX. Netzwerk Überblick. Benötigte Komponenten für: Windows Server 2008. Windows Server 2008 R2. Windows Server 2012

INDEX. Netzwerk Überblick. Benötigte Komponenten für: Windows Server 2008. Windows Server 2008 R2. Windows Server 2012 INDEX Netzwerk Überblick Benötigte Komponenten für: Windows Server 2008 Windows Server 2008 R2 Windows Server 2012 Windows SQL Server 2008 (32 Bit & 64 Bit) Windows SQL Server 2012 Client Voraussetzungen

Mehr

HP ConvergedSystem Technischer Teil

HP ConvergedSystem Technischer Teil HP ConvergedSystem Technischer Teil Rechter Aussenverteidiger: Patrick Buser p.buser@smartit.ch Consultant, SmartIT Services AG Linker Aussenverteidiger: Massimo Sallustio massimo.sallustio@hp.com Senior

Mehr

Baumgart, Wöhrmann, Aide Weyell, Harding. VMware View 5

Baumgart, Wöhrmann, Aide Weyell, Harding. VMware View 5 Baumgart, Wöhrmann, Aide Weyell, Harding VMware View 5 Inhalt Geleitwort 15 Vorwort und Hinweis 17 1 Einleitung 23 1.1 Warum dieses Buch? 23 1.2 Wer sollte dieses Buch lesen? 24 1.3 Aufbau des Buches 24

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Systemanforderungen Daten und Fakten

Systemanforderungen Daten und Fakten Daten und Fakten buchner documentation GmbH Lise-Meitner-Straße 1-7 D-24223 Schwentinental Tel 04307/81190 Fax 04307/811999 www.buchner.de Inhaltsverzeichnis 1. für die Online-Dokumentation... 3 2. Server...

Mehr

Xenologie oder wie man einen Plastikmainframe baut

Xenologie oder wie man einen Plastikmainframe baut Xenologie oder wie man einen Plastikmainframe baut Alexander Schreiber http://www.thangorodrim.de/ Chemnitzer Linux-Tage 2006 I think there is a world market for maybe five computers.

Mehr

... Geleitwort... 15. ... Vorwort und Hinweis... 17

... Geleitwort... 15. ... Vorwort und Hinweis... 17 ... Geleitwort... 15... Vorwort und Hinweis... 17 1... Einleitung... 23 1.1... Warum dieses Buch?... 23 1.2... Wer sollte dieses Buch lesen?... 24 1.3... Aufbau des Buches... 24 2... Konzeption... 29 2.1...

Mehr

Desktop-Virtualisierung mit Univention DVS

Desktop-Virtualisierung mit Univention DVS Desktop-Virtualisierung mit Univention DVS Dipl.-Ing. Ansgar H. Licher Geschäftsführer LWsystems GmbH & Co. KG 23.04.12 Folie 1 LWsystems. Das linux-systemhaus.com Open Source IT Solutions Mail- und Groupwarelösungen,

Mehr

Effizient, sicher und flexibel: Desktop-Virtualisierung mit Citrix XenDesktop

Effizient, sicher und flexibel: Desktop-Virtualisierung mit Citrix XenDesktop Effizient, sicher und flexibel: Desktop-Virtualisierung mit XenDesktop Der richtige Desktop für jeden Anwender Wolfgang Traunfellner, Systems GmbH Unsere Vision Eine Welt, in der jeder von jedem Ort aus

Mehr

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008

Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Die Linux Kernel Virtual Machine - Wo steht der Linux Hypervisor? 2. März 2008 Jörg Rödel Virtualization - Whats out there? Virtualisierung hat bereits längere Geschichte auf x86 Startete mit VMware Setzte

Mehr

Systemanforderungen. Finanzbuchführung. Anlagenbuchführung. Kostenrechnung. Personalwirtschaft

Systemanforderungen. Finanzbuchführung. Anlagenbuchführung. Kostenrechnung. Personalwirtschaft anforderungen Finanzbuchführung Anlagenbuchführung Kostenrechnung Personalwirtschaft IMPRESSUM Varial World Edition Beschreibung der voraussetzungen Februar 2008 by Varial Software AG Hauptstraße 18 57074

Mehr

PVSS II UI über MS Terminal Server 2

PVSS II UI über MS Terminal Server 2 Uneingeschränkte Visualisierungsmöglichkeiten Eine zunehmend heterogene Mischung aus PC-Systemen, Netzwerkstrukturen und Betriebssystemen stellt eine weitere Herausforderung an ein SCADA-System dar. Die

Mehr

Systemvoraussetzungen. Titel

Systemvoraussetzungen. Titel voraussetzungen Titel Installation & Administration Finanzbuchführung Anlagenbuchhaltung Kostenrechnung Personalwirtschaft 1 IMPRESSUM Varial World Edition Beschreibung der voraussetzungen März 2011 Varial

Mehr

FileMaker Pro 14. Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14

FileMaker Pro 14. Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14 FileMaker Pro 14 Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14 2007-2015 FileMaker, Inc. Alle Rechte vorbehalten. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054,

Mehr

Citrix Provisioning Server Marcel Berquez. System Engineer

Citrix Provisioning Server Marcel Berquez. System Engineer Citrix Provisioning Server Marcel Berquez. System Engineer Agenda Was ist der Citrix Provisioning Server? Wie funktioniert der Citrix Provisioning Server? Was gehört zum Citrix Provisioning Server? Welche

Mehr

High-End-Serverlösung. MAXDATA PLATINUM Server 7210R

High-End-Serverlösung. MAXDATA PLATINUM Server 7210R High-End-Serverlösung MAXDATA PLATINUM Server 7210R MAXDATA PLATINUM Server 7210R: High-End-Serverlösung für unternehmenskritische Daten Die Standardausstattung Der MAXDATA PLATINUM 7210R kombiniert Hochleistung

Mehr

Citrix - Virtualisierung und Optimierung in SharePoint. Server Umgebungen. Peter Leimgruber Citrix Systems GmbH

Citrix - Virtualisierung und Optimierung in SharePoint. Server Umgebungen. Peter Leimgruber Citrix Systems GmbH Citrix - Virtualisierung und Optimierung in SharePoint Server Umgebungen Peter Leimgruber Citrix Systems GmbH Citrix-Microsoft Alliance eine lange Historie! 1989 Microsoft licenses OS/2 to Citrix for multi-user

Mehr

Systemvoraussetzungen

Systemvoraussetzungen Systemvoraussetzungen Sage Office Line Evolution 2011 1 Anmerkungen...2 2 Hardware-Anforderungen...3 3 Software-Anforderungen...5 4 Weitere Hinweise...7 5 Einschränkungen bezüglich Sage Business Intelligence...8

Mehr

rhv Lohn/rhv Zeit Systemanforderungen

rhv Lohn/rhv Zeit Systemanforderungen Client- bzw. Einzelplatz - Software Unterstützte Client-Betriebssysteme (kein Citrix oder Terminalserver im Einsatz) Windows Vista Windows XP (SP3) Microsoft Windows 7 Home Basic Microsoft Windows 7 Home

Mehr

Technische Dokumentation Winsolvenz.p3

Technische Dokumentation Winsolvenz.p3 Technische Dokumentation Winsolvenz.p3 Inhaltsverzeichnis Inhaltsverzeichnis 1 Hinweise zum Dokument... 2 2 Einsatz im LAN... 2 STP Management-Konsole... 2 winsolvenz.p3 Client Updater... 2 winsolvenz.p3

Mehr

Professionelle betriebswirtschaftliche Software. Sage New Classic 2015 (5.3.3) Systemvoraussetzungen

Professionelle betriebswirtschaftliche Software. Sage New Classic 2015 (5.3.3) Systemvoraussetzungen Professionelle betriebswirtschaftliche Software Sage New Classic 2015 (5.3.3) Systemvoraussetzungen www.sage.de. Ohne ausdrückliche schriftliche Erlaubnis dürfen weder das Handbuch noch Auszüge daraus

Mehr

Server- & Storagelösungen, die mit Ihrem Business wachsen SV-Modul, hot plug, 94% Effizienz

Server- & Storagelösungen, die mit Ihrem Business wachsen SV-Modul, hot plug, 94% Effizienz Server- & Storagelösungen, die mit Ihrem Business wachsen SV-Modul, hot plug, 94% Effizienz Success Solution März 2014 Der Fujitsu Server PRIMERGY RX300 S8 ist ein Dual-Socket-Rack-Server mit 2 HE, der

Mehr

für das Diamant /2 Rechnungswesen ab V 6.0.x

für das Diamant /2 Rechnungswesen ab V 6.0.x Systemvoraussetzungen für das Diamant /2 Rechnungswesen ab V 6.0.x Die Systemvoraussetzungen dienen der Planung und Konzeption der Infrastruktur für das Diamant Rechnungswesen Diamant Software GmbH & Co

Mehr