Performance Report PRIMERGY RX200 S5

Transkript

1 Performance Report PRIMERGY RX200 S5 Version 2.0a März 2010 Seiten 40 Abstract In diesem Dokument sind alle Benchmarks, die für die PRIMERGY RX200 S5 durchgeführt wurden, zusammengefasst. Ferner werden die Leistungsdaten der PRIMERGY RX200 S5 mit denen anderer PRIMERGY Modelle verglichen und diskutiert. Neben den Benchmark-Ergebnissen als solchen wird jeder Benchmark und die Umgebung, in der der Benchmark durchgeführt wurde, kurz erläutert. Inhalt Dokumenthistorie... 2 Technische Daten... 3 SPECcpu SPECjbb StorageBench OLTP Terminal Server mark vservcon Literatur Kontakt... 40

2 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Dokumenthistorie Version 1.0 Erste Reportversion mit den Benchmark-Kapiteln Version 1.1 SPECcpu2006 Messungen mit E5502, E5504, E5506, E5520, E5540, X5550 und X5570 SPECjbb2005 Messung mit X5570 StorageBench Messungen mit LSI MegaRAID SAS 1064/1068 Controller Messungen mit LSI MegaRAID SAS 1078 Controller OLTP-2 Messungen mit E5502, E5504, E5506, E5520, E5540, X5550 und X5570 Neue Benchmark-Kapitel: Terminal Server Messungen mit E5504 und X5570 Version 1.2 Neue Benchmark-Kapitel: vservcon Messungen mit L5520, E5520, E5540, X5550 und X5570 Geänderte Benchmark-Kapitel: Technische Daten, StorageBench, OLTP-2, Literatur (Korrekturen) Version 2.0 in allen Benchmark-Kapiteln: zusätzliche Fußnote zur Verfügbarkeit von Komponenten Überarbeitete Benchmark-Kapitel: SPECcpu2006 Messungen mit L5530, E5530 und X5560 Zusätzliche Messungen mit E5502, E5504, E5506, E5520, E5540, X5550 und X5570 SPECjbb2005: Messung mit Oracle JRockit(R) 6 P (build P _ windows-x86_64) OLTP-2 Werte für L5530, E5530 und X5560 StorageBench (Korrekturen) vservcon (Korrekturen, aktualisierte Grafiken) Neue Benchmark-Kapitel: mark Version 2.0a Überarbeitete Benchmark-Kapitel: SPECcpu2006 Tabellenformatierung geändert SPECjbb2005 (Korrekturen) StorageBench (Korrekturen) OLTP-2 (Korrekturen) Terminal Server (Literatur) mark (Korrekturen) vservcon (Korrekturen) Fujitsu Technology Solutions Seite 2 (40)

3 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Technische Daten Die PRIMERGY RX200 S5 ist ein mit nur einer Höheneinheit besonders Platz sparender Dual-Socket Rack- Server, der die PRIMERGY RX200 S4 ablöst. Sie besitzt einen Intel 5500 Chipsatz, zwei Intel Dual-Core oder Quad-Core Prozessoren, bis zu 96 GB PC oder PC registered ECC DDR3- SDRAM oder bis zu 24 GB PC unbuffered ECC DDR3-SDRAM, einen abhängig vom verwendeten Prozessor mit 800, 1067 oder 1333 MHz getakteten Bus, einen onboard 2-Port SATA-Controller mit RAID 0 und RAID 1, einen SAS-Controller mit RAID 0 und RAID 1 oder einen SAS-Controller mit RAID 5 und RAID 6 für bis zu acht interne SATA- oder SAS-Festplatten, einen onboard 2-Port 1-GBit Ethernet-Controller und drei PCI-Steckplätze (2 mal PCIe-2 x8 und 1 mal PCIe-2 x4). Detaillierte technische Informationen finden Sie im Datenblatt PRIMERGY RX200 S5. Fujitsu Technology Solutions Seite 3 (40)

4 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 SPECcpu2006 Benchmark-Beschreibung SPECcpu2006 ist ein Benchmark, der die Systemeffizienz bei Integer- und Fließkomma-Operationen misst. Er besteht aus einer Integer-Testsuite (SPECint2006), die 12 Applikationen enthält, und einer Fließkomma- Testsuite (SPECfp2006), die 17 Applikationen enthält. Beide Testsuiten sind extrem rechenintensiv und konzentrieren sich auf die CPU und den Speicher. Andere Komponenten, wie Disk-I/O und Netzwerk, werden von diesem Benchmark nicht vermessen. SPECcpu2006 ist nicht an ein spezielles Betriebssystem gebunden. Der Benchmark ist als Source-Code verfügbar und wird vor der eigentlichen Messung kompiliert. Daher beeinflussen auch die verwendete Compiler-Version und deren Optimierungseinstellungen das Messergebnis. SPECcpu2006 beinhaltet zwei verschiedene Methoden der Performance-Messung: Die erste Methode (SPECint2006 bzw. SPECfp2006) ermittelt die Zeit, die für die Bearbeitung einer einzelnen Aufgabe benötigt wird. Die zweite Methode (SPECint_rate2006 bzw. SPECfp_rate2006) ermittelt den Durchsatz, d.h. wie viele Aufgaben parallel erledigt werden können. Beide Methoden werden zusätzlich noch in zwei Messläufe unterteilt, base und peak, die sich in der Verwendung der Compiler-Optimierung unterscheiden. Bei der Publikation von Ergebnissen werden immer base -Werte verwendet, peak -Werte sind optional. Benchmark Arithmetik Typ Compiler- Optimierung SPECint2006 Integer peak aggressiv SPECint_base2006 Integer base konservativ SPECint_rate2006 Integer peak aggressiv SPECint_rate_base2006 Integer base konservativ SPECfp2006 Fließkomma peak aggressiv SPECfp_base2006 Fließkomma base konservativ SPECfp_rate2006 Fließkomma peak aggressiv SPECfp_rate_base2006 Fließkomma base konservativ Messergebnis Geschwindigkeit Durchsatz Geschwindigkeit Durchsatz Anwendung Singlethreaded Multithreaded Singlethreaded Multithreaded Bei den Messergebnissen handelt es sich um das geometrische Mittel aus normalisierten Verhältniswerten, die für die Einzel-Benchmarks ermittelt wurden. Das geometrische Mittel führt gegenüber dem arithmetischen Mittel dazu, dass bei unterschiedlich hohen Einzelergebnissen eine Gewichtung zugunsten der niedrigeren Einzelergebnisse erfolgt. Normalisiert heißt, dass gemessen wird, wie schnell das Testsystem verglichen mit einem Referenzsystem ist. Der Wert 1 wurde für die SPECint_base2006-, SPECint_rate_base2006, SPECfp_base2006 und SPECfp_rate_base2006-Ergebnisse des Referenzsystems festgelegt. So bedeutet beispielsweise ein SPECint_base2006-Wert von 2, dass das Messsystem diesen Benchmark etwa doppelt so schnell wie das Referenzsystem bewältigt hat. Ein SPECfp_rate_base2006-Wert von 4 bedeutet, dass das Messsystem diesen Benchmark etwa 4/[# base copies] mal so schnell wie das Referenzsystem bewältigt hat. # base copies gibt hierbei an, wie viele parallele Instanzen des Benchmarks ausgeführt worden sind. Nicht alle SPECcpu2006-Messungen werden von uns zur Veröffentlichung bei SPEC eingereicht. Daher erscheinen auch nicht alle Ergebnisse auf den Web-Seiten von SPEC. Da wir für alle Messungen die Protokolldateien archivieren, können wir jederzeit den Nachweis für die korrekte Durchführung der Messungen erbringen. Benchmark-Ergebnisse Die PRIMERGY RX200 S5 wurde mit den Prozessoren E5502, E5504, L5506, E5506, L5520, E5520, L5530, E5530, E5540, X5550, X5560 und X5570 vermessen. Die Benchmark-Programme wurden mit dem Intel C++/Fortran-Compiler 11.0 kompiliert und unter SUSE Linux Enterprise Server 10 SP2 (64-bit) SPEC, SPECint, SPECfp und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions Seite 4 (40)

5 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 ausgeführt. In den folgenden Tabellen sind alle fett gedruckten Ergebnisse Die mit (est.) gekennzeichneten Ergebnisse sind Schätzwerte. veröffentlicht bei Prozessor Cores GHz L3-Cache Bus TDP SPECint_base Chips SPECint Chips E MB 800 MHz 80 Watt E MB 800 MHz 80 Watt L MB 800 MHz 60 Watt 20.4 (est.) 22.6 (est.) E MB 800 MHz 80 Watt L MB 1067 MHz 60 Watt 24.3 (est.) 27.0 (est.) E MB 1067 MHz 80 Watt L MB 1067 MHz 60 Watt 25.7 (est.) 28.7 (est.) E MB 1067 MHz 80 Watt E MB 1067 MHz 80 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt Fujitsu Technology Solutions Seite 5 (40)

6 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Prozessor Cores GHz L3-Cache Bus TDP SPECint_rate_base2006 SPECint_rate Chip 2 Chips 1 Chip 2 Chips E MB 800 MHz 80 Watt E MB 800 MHz 80 Watt L MB 800 MHz 60 Watt 68.1 (est.) (est.) 141 E MB 800 MHz 80 Watt L MB 1067 MHz 60 Watt 95.8 (est.) (est.) 199 E MB 1067 MHz 80 Watt L MB 1067 MHz 60 Watt 99.6 (est.) (est.) 208 E MB 1067 MHz 80 Watt E MB 1067 MHz 80 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt Fujitsu Technology Solutions Seite 6 (40)

7 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Prozessor Cores GHz L3-Cache Bus TDP SPECfp_base Chips SPECfp Chips E MB 800 MHz 80 Watt E MB 800 MHz 80 Watt L MB 800 MHz 60 Watt 24.7 (est.) 26.2 (est.) E MB 800 MHz 80 Watt L MB 1067 MHz 60 Watt 29.7 (est.) 31.4 (est.) E MB 1067 MHz 80 Watt L MB 1067 MHz 60 Watt 30.9 (est.) 32.9 (est.) E MB 1067 MHz 80 Watt E MB 1067 MHz 80 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt Fujitsu Technology Solutions Seite 7 (40)

8 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Prozessor Cores GHz L3-Cache Bus TDP SPECfp_rate_base2006 SPECfp_rate Chip 2 Chips 1 Chip 2 Chips E MB 800 MHz 80 Watt E MB 800 MHz 80 Watt L MB 800 MHz 60 Watt 59.3 (est.) (est.) 119 E MB 800 MHz 80 Watt L MB 1067 MHz 60 Watt 79.9 (est.) (est.) 159 E MB 1067 MHz 80 Watt L MB 1067 MHz 60 Watt 82.4 (est.) (est.) 164 E MB 1067 MHz 80 Watt E MB 1067 MHz 80 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt X MB 1333 MHz 95 Watt Fujitsu Technology Solutions Seite 8 (40)

9 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Der Durchsatz mit zwei Prozessoren ist sowohl bei der Integer- als auch bei der Floating-Point-Testsuite etwa doppelt so groß wie der mit einem Prozessor. Fujitsu Technology Solutions Seite 9 (40)

10 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Die folgenden Grafiken verdeutlichen den Durchsatz der PRIMERGY RX200 S5 im Vergleich zu ihrem Vorgänger, der PRIMERGY RX200 S4, in jeweils performantester Ausstattung. Fujitsu Technology Solutions Seite 10 (40)

11 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Umgebung Alle SPECcpu2006-Messungen wurden auf einer PRIMERGY RX200 S5 mit folgender Hard- und Software- Ausstattung vorgenommen: Hardware Modell CPU Anzahl CPUs Primary Cache Secondary Cache Other Cache Software Betriebssystem PRIMERGY RX200 S5 E5502, E5504, L5506, E5506, L5520, E5520, L5530, E5530, E5540, X5550, X5560 und X Chip: E5502: 2 Cores, 2 Cores/Chip alle anderen: 4 Cores, 4 Cores/Chip 2 Chips: E5502: 4 Cores, 2 Cores/Chip alle anderen: 8 Cores, 4 Cores/Chip 32 KB instruction + 32 KB data on chip, pro Core 256 kb on chip, pro Core E5502, E5504, L5506 und E5506: 4 MB (I+D) on chip, pro Chip alle anderen: 8 MB (I+D) on chip, pro Chip SUSE Linux Enterprise Server 10 SP2 (64-bit) Compiler Intel C++/Fortran Compiler 11.0 Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. Fujitsu Technology Solutions Seite 11 (40)

12 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 SPECjbb2005 Benchmark-Beschreibung SPECjbb2005 ist ein Java Business Benchmark, dessen Fokus auf der Leistung von Java Server Plattformen liegt. Im Wesentlichen ist SPECjbb2005 ein modernisierter SPECjbb2000. Die Hauptunterschiede sind: Die Transaktionen sind komplexer geworden, um einen größeren Bereich an Funktionalität abzudecken. Der Working Set des Benchmarks ist vergrößert worden, so dass die Systemlast insgesamt gestiegen ist. SPECjbb2000 erlaubt nur eine aktive Java Virtual Machine Instanz (J), während SPECjbb2005 mehrere Instanzen zulässt, was eine größere Realitätsnähe insbesondere bei großen Systemen bewirkt. Softwareseitig misst SPECjbb2005 die Effizienz der Implementierungen der J, Just-In-Time (JIT) Compilers, Garbage Collection, Threads sowie einige Aspekte des Betriebssystems. Hardwareseitig wird die Effizienz der CPUs und Caches, des Speichersubsystems und die Skalierbarkeit von Shared Memory Systemen (SMP) gemessen. Disk- und Netzwerk-I/O spielen keine Rolle. SPECjbb2005 emuliert ein für moderne Geschäftsprozess-Applikationen typisches Three-Tier Client/Server System mit Augenmerk auf das Middle-Tier System: Clients erzeugen die Last, bestehend aus Driver Threads, die angelehnt an den TPC-C Benchmark OLTP Zugriffe auf eine Datenbank ohne Denkzeiten generieren. Das Middle-Tier System implementiert die Geschäftsprozesse und Aktualisierung der Datenbank. Die Datenbank übernimmt die Datenverwaltung und wird emuliert durch Java-Objekte, die im Memory liegen. Transaktions-Logging ist implementiert auf XML Basis. Der große Vorteil dieses Benchmarks ist, dass er alle drei Tiers beinhaltet, die gemeinsam auf einem Single- Host laufen. Gemessen wird die Performance des Middle-Tier. So werden große Hardware-Installationen vermieden und direkte Vergleiche von SPECjbb2005-Ergebnissen unterschiedlicher Systeme sind möglich. Client- und Datenbank-Emulation sind ebenfalls in Java geschrieben. SPECjbb2005 benötigt nur das Betriebssystem sowie eine Java Virtual Machine mit J2SE 5.0 Eigenschaften. Die Skalierungseinheit ist ein Warenhaus mit ca. 25 MB Java Objekten. Genau ein Java-Thread pro Warenhaus führt die Operationen auf diesen Objekten aus. Die Geschäftsoperationen sind von TPC-C übernommen: New Order Entry Payment Order Status Inquiry Delivery Stock Level Supervision Customer Report Das sind aber auch die einzigen Gemeinsamkeiten von SPECjbb2005 und TPC-C. Die Ergebnisse beider Benchmarks sind nicht vergleichbar. SPECjbb2005 besitzt 2 Performance-Metriken: bops (business operations per second) ist die Gesamtrate aller Geschäftsoperationen, die pro Sekunde durchgeführt werden. bops/j ist der Quotient der ersten Metrik und der Anzahl der aktiven J Instanzen. In Vergleichen verschiedener SPECjbb2005-Ergebnisse müssen beide Metriken angegeben werden. SPEC, SPECjbb und das SPEC-Logo sind eingetragene Warenzeichen der Standard Performance Evaluation Corporation (SPEC). Fujitsu Technology Solutions Seite 12 (40)

13 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Grundlage für diese Metriken sind die folgenden Regeln, nach denen ein konformer Benchmark-Lauf durchgeführt werden muss: Ein konformer Benchmarklauf besteht aus einer Sequenz von Messpunkten mit wachsender Anzahl von Warenhäusern (und damit von Threads), wobei die Anzahl jeweils um ein Warenhaus erhöht wird. Gestartet wird mit einem Warenhaus bis zu 2*MaxWh, mindestens aber 8 Warenhäusern. MaxWh ist die Anzahl Warenhäuser, bei der der Benchmark die höchste Operationsrate pro Sekunde erwartet. Standardmäßig setzt der Benchmark MaxWh mit der Anzahl vom Betriebssystem erkannter CPUs gleich. Die Metrik bops ist das arithmetische Mittel aller gemessenen Operations-Raten mit MaxWh Warenhäusern bis 2*MaxWh Warenhäusern. Benchmark-Ergebnisse Im März 2009 wurde die PRIMERGY RX200 S5 mit zwei X5570 Prozessoren bei einem Speicherausbau mit 24 GB PC R DDR3-SDRAM vermessen. Die Messung wurde unter Windows Server 2008 Enterprise x64 Edition durchgeführt. Als J wurden zwei Instanzen von JRockit(R) 6 P (build P _ windows-x86_64) von Oracle verwendet. Bei der Messung flossen alle Messwerte von 8 bis 16 Warenhäusern in das Benchmark-Ergebnis ein. Im August 2009 wurde die PRIMERGY RX200 S5 in gleicher Hardware-Konfiguration, aber anderer Software-Konfiguration vermessen. Die Messung wurde unter Windows Server 2008 Enterprise x64 Edition SP2 durchgeführt. Als J wurden vier Instanzen von JRockit(R) 6 P (build P _ windows-x86_64) von Oracle verwendet. Bei der Messung flossen alle Messwerte von 4 bis 8 Warenhäusern in das Benchmark-Ergebnis ein. Fujitsu Technology Solutions Seite 13 (40)

14 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Vergleicht man die PRIMERGY RX200 S5 mit ihrem Vorgänger, der PRIMERGY RX200 S4, in jeweils performantester Ausstattung, so ergibt sich eine Durchsatzsteigerung von +55%. Benchmark-Umgebung Die SPECjbb2005-Messungen wurden auf einer PRIMERGY RX200 S5 mit folgender Hard- und Software- Ausstattung durchgeführt: Messung vom März 2009 Hardware Modell CPU Anzahl Chips Primary Cache PRIMERGY RX200 S5 X Chips, 8 Cores, 4 Cores pro Chip 32 kb instruction + 32 kb data on chip, pro Core Secondary Cache ¼ MB (I+D) on chip, pro Core Other Cache Memory Software Betriebssystem J Version 8 MB (I+D) on chip, pro Chip 6 x 4 GB PC R DDR3-SDRAM Windows Server 2008 Enterprise x64 Edition Oracle JRockit(R) 6 P (build P _ windows-x86_64) Messung vom August 2009 Hardware wie im März 2009 Software Betriebssystem J Version Windows Server 2008 Enterprise x64 Edition SP2 Oracle JRockit(R) 6 P (build P _ windows-x86_64) Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. Fujitsu Technology Solutions Seite 14 (40)

15 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 StorageBench Benchmark-Beschreibung Um die Leistungsfähigkeit von Disk-Subsystemen zu beurteilen, wurde von Fujitsu Technology Solutions ein Benchmark mit dem Namen»StorageBench«definiert, mit dem ein Vergleich der verschiedenen Storage- Anbindungen möglich ist. StorageBench nutzt zu diesem Zweck das von der Firma Intel entwickelte Messwerkzeug Iometer mit einem definierten Satz von in der Praxis vorkommenden Lastprofilen und einem festgelegten Messszenario. Messwerkzeug Seit Ende 2001 ist Iometer ein Projekt bei und wird von einer Gruppe internationaler Entwickler auf verschiedene Plattformen portiert und weiterentwickelt. Iometer besteht aus einer grafischen Bedieneroberfläche für Windows-Systeme und dem so genannten»dynamo«, der für verschiedene Plattformen verfügbar ist. Diese beiden Komponenten können seit einigen Jahren unter»intel Open Source License«von oder heruntergeladen werden. Mit Iometer hat man die Möglichkeit, das Verhalten realer Anwendungen bezüglich der Zugriffe auf I/O- Subsysteme nachzubilden. Dazu kann man unter anderem die zu verwendenden Blockgrößen, die Art des Zugriffs wie sequentielles Lesen oder Schreiben, wahlfreies Lesen oder Schreiben und auch Mischungen davon konfigurieren. Zusätzlich lässt sich die Anzahl simultaner Zugriffe (»Outstanding IOs«) einstellen. Als Ergebnis liefert Iometer eine Textdatei mit durch Komma separierten Werten (.csv) wesentlicher Kenngrößen wie z.b.»durchsatz pro Sekunde«,»Transaktionen pro Sekunde«und»durchschnittliche Antwortzeit«für das jeweilige Zugriffsmuster. Auf diese Weise kann man die Leistungsfähigkeit verschiedener Subsysteme bei bestimmten Zugriffsmustern vergleichen. Iometer ist in der Lage, sowohl auf I/O-Subsysteme mit einem Dateisystem als auch auf I/O-Subsysteme ohne Dateisystem, so genannte Raw-Devices, zuzugreifen. Mit Iometer können die Zugriffsmuster verschiedenster Anwendungen simuliert und vermessen werden, jedoch bleibt der File-Cache des Betriebssystems außer Acht und es wird blockmäßig auf einer einzelnen Testdatei operiert. Lastprofil Von erheblichem Einfluss auf die Performance eines Speichersystems ist die Art, wie Anwendungen auf den Massenspeicher zugreifen. Beispiele für verschiedene Zugriffsmuster einiger Anwendungen: Anwendung Datenbank (Datentransfer) Datenbank (Log File) Backup Restore Video Streaming File-Server Web-Server Betriebssystem File-Copy Zugriffsmuster random, 67% read, 33% write, 8 KB (SQL Server) sequentiell, 100% write, 64 KB Blöcke sequentiell, 100% read, 64 KB Blöcke sequentiell, 100% write, 64 KB Blöcke sequentiell, 100% read, Blöcke 64 KB random, 67% read, 33% write, 64 KB Blöcke random, 100% read, 64 KB Blöcke random, 40% read, 60% write, Blöcke 4 KB random, 50% read, 50% write, 64 KB Blöcke Daraus wurden vier markante Profile abgeleitet: Lastprofil Zugriff Zugriffsmuster Blockgröße read write Outstanding IOs Last-Tool Streaming sequentiell 100% 64 KB 3 Iometer Restore sequentiell 100% 64 KB 3 Iometer Database random 67% 33% 8 KB 3 Iometer File-Server random 67% 33% 64 KB 3 Iometer Alle vier Profile wurden mit Iometer generiert. Fujitsu Technology Solutions Seite 15 (40)

16 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Messszenario Um vergleichbare Messergebnisse zu erhalten ist es wichtig, alle Messungen in identischen, reproduzierbaren Umgebungen durchzuführen. Daher liegen StorageBench neben dem oben beschriebenen Lastprofil die folgenden Regeln zugrunde: Da in realen Kundenkonfigurationen nur in Ausnahmefällen mit Raw-Devices gearbeitet wird, sind bei den Untersuchungen zur Leistungsfähigkeit der internen Festplatten diese immer mit einem Dateisystem formatiert. Für Windows wird NTFS, für Linux ext3 verwendet, auch wenn mit anderen Dateisystemen oder Raw-Devices eventuell eine höhere Leistung erreicht werden könnte. Festplatten gehören zu den fehleranfälligsten Komponenten eines Computersystems. Daher werden in Serversystemen RAID-Controller eingesetzt, um dem Datenverlust durch den Ausfall von Festplatten vorzubeugen. Dabei werden mehrere Festplatten zu einem»redundant Array of Independent Disks«, kurz RAID, zusammengefasst. Dabei werden die Daten über mehrere Festplatten derart verteilt, dass auch beim Ausfall einer Festplatte alle Daten, mit Ausnahme von RAID 0, erhalten bleiben. Die gebräuchlichsten Arten um Festplatten in Verbänden zu organisieren sind die RAID-Levels RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 und RAID 60. Informationen zu den Grundlagen verschiedener RAID-Levels sind im Papier Performance Report - Modular RAID für PRIMERGY zu finden. Für die StorageBench-Untersuchungen der PRIMERGY Server werden die je nach Plattenanzahl und eingebautem Controller möglichen RAID-Konfigurationen verwendet. Bei Systemen mit zwei Festplatten RAID 1 und RAID 0, bei drei und mehr Festplatten zusätzlich RAID 1E und RAID 5 und ggf. weitere RAID-Levels sofern der Controller diese RAID-Levels unterstützt. Für die Messung wird immer eine Messdatei mit einer Größe von 8 GB verwendet, unabhängig von der Größe der Festplatte. Bei der Beurteilung der Leistungsfähigkeit von I/O-Subsystemen spielen bei heutigen Systemen die Prozessorleistung und der Speicherausbau des Systems keine signifikante Rolle ein eventuell vorhandener Engpass betrifft in der Regel die Festplatten und den RAID-Controller und nicht CPU oder Memory. Daher brauchen unterschiedliche Ausbauvarianten mit CPU und Speicher unter StorageBench nicht untersucht zu werden. Messergebnisse StorageBench liefert pro Lastprofil eine ganze Reihe von Kenngrößen, z.b. den»datendurchsatz«in Megabytes pro Sekunde, kurz MB/s, die»transaktionsrate«in I/O-Operationen pro Sekunde, kurz IO/s, und die»latenzzeit«oder auch»mittlere Zugriffszeit«in ms. Für die sequentiellen Lastprofile ist der Datendurchsatz die übliche Messgröße, während bei den random-lastprofilen mit ihren kleinen Blockgrößen die Messgröße»Transaktionsrate«allgemein verwendet wird. Datendurchsatz und Transaktionsrate sind direkt proportional zueinander und lassen sich nach der Formel Datendurchsatz [MB/s] Transaktionsrate [Disk-I/O s -1 ] = Transaktionsrate [Disk-I/O s -1 ] Blockgröße [MB] = Datendurchsatz [MB/s] / Blockgröße [MB] berechnen. Fujitsu Technology Solutions Seite 16 (40)

17 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Ergebnisse Die PRIMERGY RX200 S5 ist mit den Controllern der»modular RAID«Familie ausgestattet. Die Vielfalt der RAID-Lösungen ermöglicht dem Anwender, den passenden Controller für sein Anwendungsszenario zu wählen. Die PRIMERGY RX200 S5 bietet folgende RAID-Lösungen an: 1. RAID-Controller LSI MegaRAID SAS 1064/1068 Der Controller wird als PCI-Express-Karte geliefert. Es werden die RAID-Levels 0, 1 und 1E unterstützt. Dieser Controller-Typ hat keinen Cache. Die maximale Anzahl der Festplatten, die man an den Controller LSI MegaRAID SAS 1064 anschließen kann, ist vier, während der LSI MegaRAID SAS 1068 Controller acht Ports für bis zu acht Festplatten bietet. 2. RAID-Controller LSI MegaRAID SAS 1078 Der Controller wird als PCI-Express-Karte geliefert und bietet dem Anwender eine komplette RAID- Lösung. Es werden die RAID-Levels 0, 1, 5, 6, 10, 50 und 60 unterstützt. Es werden zwei unterschiedliche Versionen dieses Controllers mit entweder 256 MB oder 512 MB Cache angeboten. Der Controller-Cache kann durch eine optionale Battery Backup Unit (BBU) gegen Stromausfälle geschützt werden. Der Controller unterstützt bis zu 240 Festplatten. An diese Controller können unterschiedliche Festplatten angeschlossen werden. In Abhängigkeit von der benötigten Performance kann das Disk-Subsystem passend ausgewählt werden. Die PRIMERGY RX200 S5 bietet je nach Modellvariante bis zu acht hot-plug Einschübe für 2½" SAS-Festplatten. Für die PRIMERGY RX200 S5 stehen folgende Festplatten zur Auswahl: 2½" SAS Festplatten mit einer Kapazität von 73 GB und 146 GB (10 krpm) 2½" SAS Festplatten mit einer Kapazität von 36 GB und 73 GB (15 krpm) LSI MegaRAID SAS 1064/1068 Im Folgenden wird die Leistung der verfügbaren Festplattentypen am LSI MegaRAID SAS 1068 Controller verglichen. Die Ergebnisse sind auf den LSI MegaRAID SAS 1064 Controller übertragbar. Dieser Controller hat keinen Controller-Cache. Deshalb wurden bei den Messungen nur die Auswirkungen der Disk-Cache-Parameter untersucht und die Messungen wurden jeweils mit und ohne Disk-Cache durchgeführt. Der Cache der Festplatten hat Einfluss auf die Disk-I/O-Performance. Er wird häufig als Sicherheitsproblem bei Stromausfall angesehen und daher abgeschaltet. Dennoch wurde er von den Festplattenherstellern aus gutem Grund zur Steigerung der Schreib-Performance integriert. Der weitaus größere Cache für I/O-Zugriffe und damit ein potentielles Sicherheitsrisiko für Datenverluste bei Stromausfall befindet sich im Arbeitsspeicher und wird vom Betriebssystem verwaltet. Um Datenverlusten vorzubeugen, empfiehlt es sich, das System mit einer USV auszustatten. Im Testaufbau wurden zwei Festplatten an den Controller angeschlossen und als RAID 1 konfiguriert. Bei den Messungen wurden alle heute für die PRIMERGY RX200 S5 verfügbaren Festplattentypen untersucht. Im Folgenden werden die Durchsätze der einzelnen Festplattentypen im RAID 1 bei unterschiedlichen Zugriffsmustern verglichen. Die Grafik zeigt, dass der Durchsatz beim sequentiellen Lesen und Schreiben mit 64 KB Blockgröße mit steigender Umdrehungsgeschwindigkeit steigt. Wird beim sequentiellen Lesen statt einer Festplatte mit einer Umdrehungsgeschwindigkeit von 10 krpm eine Festplatte mit 15 krpm verwendet, ergibt sich eine Durchsatzsteigerung von etwa 19%. Verwendet man beim sequentiellen Schreiben und eingeschaltetem Disk-Cache statt einer Festplatte mit einer Umdrehungsgeschwindigkeit von 10 krpm eine Festplatte mit 15 krpm, führt dieses zu einer Durchsatzsteigerung von etwa 21%. Wenn der Disk-Cache nicht eingeschaltet ist, beträgt die Steigerung sogar 52%. LSI MegaRAID SAS 1068 Fujitsu Technology Solutions Seite 17 (40)

18 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Eine relevante Durchsatzsteigerung beim sequentiellen Schreiben kann man, wie im Diagramm oben zu sehen ist, durch das Einschalten des Disk-Cache erreichen: bei den Festplatten mit 10 krpm steigt der Durchsatz um ca. 84% und bei den Festplatten mit 15 krpm steigt der Durchsatz um etwa 46%. Die folgende Grafik zeigt, dass auch bei wahlfreiem Zugriff mit 67% Leseanteil der Disk-Cache eine wichtige Rolle bei der Verbesserung des Durchsatzes spielt. Die Durchsatzsteigerung durch das Einschalten des Disk-Cache liegt etwa bei 23%. Auch beim wahlfreien Zugriff zeigt die schneller drehende Festplatte eine bessere Leistung, die Umdrehungsgeschwindigkeit von 15 krpm macht sich in einem Performance-Gewinn von etwas über 22% bemerkbar. LSI MegaRAID SAS 1078 LSI MegaRAID SAS 1068 Der RAID-Verband definiert die Art und Weise, wie die Daten hinsichtlich der Verfügbarkeit behandelt werden. Wie schnell die Daten im jeweiligen RAID-Verband-Kontext transportiert werden, hängt wesentlich vom Datendurchsatz der Festplatten ab. Abhängig vom RAID-Level wurde die Anzahl der Festplatten festgelegt, die für die Messungen in einem RAID-Verband konfiguriert wurden. Es wurden zwei und drei Festplatten verwendet. Damit die Festplatten keinen Engpass bei der Ermittlung der Leistungsfähigkeit des Controllers unter verschiedenen Cache-Einstellungen darstellen, wurden die Messungen mit Festplatten mit einer Umdrehungszahl von 15 krpm durchgeführt. Der Durchsatz der Festplatten lässt sich durch die Anpassung der Controller-Cache-Einstellungen in bestimmten Fällen erheblich erhöhen. Die Durchsatzsteigerungen fallen allerdings je nach Datenstruktur und Zugriffsmuster unterschiedlich aus. Bei den Messungen wurde die Controller-Cache-Option»Read-Mode«immer auf»no Read-ahead«und die Option»I/O cache«auf»i/o direct«gesetzt. Die Optionen»Write- Mode«und»Disk cache«wurden variiert. Die folgende Grafik stellt die Durchsätze beim sequentiellen Lesen und Schreiben mit 64 KB Blöcken und bei unterschiedlichen Cache-Einstellungen im RAID 1 mit zwei und im RAID 5 mit drei 2½" SAS-Festplatten dar. Der Lesedurchsatz liegt etwa im Bereich des maximal möglichen Durchsatzes von etwas über 100 MB/s beim RAID 1 und 200 MB/s beim RAID 5. Der Schreibdurchsatz dagegen hängt von den Cache- Einstellungen ab. Um die Leistung bei RAID 1 zu maximieren, ist es notwendig, die Option»Disk cache enabled«als optimale Cache-Einstellung zu verwenden. In unserem Fall hat sich der Durchsatz damit etwa um den Faktor 1.7 beim sequentiellen Schreiben verbessert. Dass die optimalen Cache-Einstellungen für eine verbesserte Performance wichtig sind, ist bei RAID 5 besonders deutlich zu sehen. Die Grafik zeigt, dass der sequentielle Schreibdurchsatz durch das Einschalten des Controller-Cache mit der Option»Write-back«und des Disk-Cache mit der Option»enabled«erheblich, um den Faktor 22, steigt. LSI MegaRAID SAS 1078 mit 512 MB Cache Fujitsu Technology Solutions Seite 18 (40)

19 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Um mit RAID 1 einen optimalen Durchsatz beim wahlfreien Zugriff zu erreichen, ist es wichtig, die Write- Mode-Option des Controller-Cache auf»write-through«zu setzen und den Disk-Cache der Festplatte einzuschalten. Durch diese optimalen Cache- Einstellungen werden Durchsatzverbesserungen von 19% und 14% erreicht, je nachdem, ob man beim wahlfreien Zugriff 8 KB oder 64 KB große Blöcke verwendet. Um mit RAID 5 einen optimalen Durchsatz beim wahlfreien Zugriff zu erreichen, ist es wichtig, die Write-Mode-Option des Controller-Cache auf»write-back«zu setzen und den Disk-Cache der Festplatte einzuschalten. Durch diese optimalen Cache-Einstellungen werden Durchsatzverbesserungen von 56% und 47% erreicht, je nach Blockgröße. Umfangreichere Informationen zu diesem Thema sind im Papier Performance Report - Modular RAID für PRIMERGY zu finden. Controller-Vergleich LSI MegaRAID SAS 1078 mit 512 MB Cache Bei der folgenden Gegenüberstellung werden die Durchsätze der unterschiedlichen Controller verglichen. Die Messungen erfolgten jeweils mit den gleichen Festplattentypen in dem gleichen RAID 1-Verband. Die Grafik zeigt die Durchsätze, die bei ausgeschalteten Caches (Off) und bei den optimalen Cache- Einstellungen (Optimal) erreicht wurden. Die Leistungsunterschiede der verwendeten Controller sind beim rein sequentiellen Zugriff und optimalen Cache-Einstellungen minimal. Beim sequentiellen Lesen erreichen alle Controller unabhängig von den Cache-Einstellungen den maximalen Datendurchsatz. Auch beim sequentiellen Schreiben sind alle Controller im gleichen Leistungsbereich, wobei der Datendurchsatz durch optimale Cache-Einstellungen um bis zu 65% gesteigert werden kann. Beim wahlfreien Zugriff im RAID 1 zeigt der Einstiegs-Controller LSI MegaRAID SAS 1064/1068 bei diesem Lastprofil einen etwas höheren Datendurchsatz als der LSI MegaRAID SAS 1078 Controller, der mit seinem Controller-Cache und der erweiterten Funktionalität für die höheren RAID-Level optimal ausgestattet ist und auch bei RAID 1 eine gute Leistung bietet. Fujitsu Technology Solutions Seite 19 (40)

20 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Fazit Mit dem»modular RAID«Konzept bietet die PRIMERGY RX200 S5 eine Fülle von Möglichkeiten, um den verschiedenen Anforderungen unterschiedlichster Anwendungsszenarien gerecht zu werden. Der Einstiegs-Controller, repräsentiert durch den LSI MegaRAID SAS 1064 bzw Controller, bietet die Basis-RAID-Lösungen RAID 0, RAID 1 und RAID 1E an, wobei er diese RAID-Levels bei sehr guter Performance unterstützt. Der»High End«Controller, repräsentiert durch den LSI MegaRAID SAS 1078 Controller, bietet alle heute gängigen RAID-Lösungen an: das sind für die PRIMERGY RX200 S5, die mit maximal acht internen Festplatten ausgebaut werden kann, die RAID-Level 0, 1, 5, 6, 10, 50 und 60. Dieser Controller wird mit 256 MB oder 512 MB großem Controller-Cache ausgeliefert und kann optional mit einer BBU gesichert werden. Vielfältige Möglichkeiten die Nutzung des Cache einzustellen erlauben eine flexible Anpassung der Controller-Leistung an den verwendeten RAID-Level. Die Verwendung von RAID 5 oder RAID 6 ermöglicht eine wirtschaftliche Ausnutzung der vorhandenen Festplattenkapazität bei guter Performance. Für optimale Performance und Sicherheit ist jedoch ein RAID 10 zu empfehlen. Die PRIMERGY RX200 S5 bietet 2½"-SAS-Festplatten mit Umdrehungsgeschwindigkeiten von 10 krpm und 15 krpm. In Abhängigkeit von der benötigten Performance ist zu entscheiden, welche Umdrehungsgeschwindigkeit zum Einsatz kommen soll. Festplatten mit 15 krpm bieten eine bis zu 52% bessere Performance. Für maximale Performance empfiehlt es sich, insbesondere bei der Verwendung eines Controllers ohne Controller-Cache, den Disk-Cache einzuschalten. Je nach verwendetem Plattentyp und Zugriffsmuster verbessert sich damit die Performance um bis zu etwa 85%. Entscheidet man sich für die Aktivierung des Disk-Cache, ist der Einsatz einer USV empfehlenswert. Benchmark-Umgebung Alle hier vorgestellten Messungen wurden mit den im Folgenden aufgelisteten Hardware- und Software- Komponenten durchgeführt. Komponente Server Betriebssystem Dateisystem Details PRIMERGY RX200 S5 Windows Server 2008, Enterprise Edition Version: Service Pack 1 Build 6001 NTFS Messwerkzeug Iometer Messdaten Controller LSI MegaRAID SAS 1068 Controller LSI MegaRAID SAS 1078 Hard Disk SAS, 2½", 10 krpm Hard Disk SAS, 2½", 15 krpm Messdatei von 8 GB Produkt: LSI RAID 0/1 SAS 1068 Driver Name: lsi_sas.sys, Driver Version: Firmware Version: BIOS Version: Produkt: LSI RAID 5/6 SAS 1078 Driver Name: megasas.sys, Driver Version: Firmware-Paket: Firmware Version: BIOS Version: Controller Cache: 256 MB oder 512 MB Seagate ST973402SS, 73 GB Seagate ST973451SS, 73 GB Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. Fujitsu Technology Solutions Seite 20 (40)

21 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 OLTP-2 Benchmark-Beschreibung OLTP steht für Online Transaction Processing. Dem OLTP-2-Benchmark liegt das typische Anwendungsszenario einer Datenbanklösung zugrunde. Es werden bei OLTP-2 Zugriffe auf eine Datenbank simuliert und die Anzahl erreichter Transaktionen pro Sekunde (tps) als Maß für die Leistungsfähigkeit des vermessenen Systems ermittelt. Im Gegensatz zu Benchmarks, wie beispielsweise SPECint und TPC-E, die von unabhängigen Gremien standardisiert wurden und bei denen die Einhaltung des jeweiligen Reglements überwacht wird, ist OLTP-2 ein interner Benchmark von Fujitsu Technology Solutions. Der zum Teil enorme Hardware- und Zeit- Aufwand der standardisierten Benchmarks wurde bei OLTP-2 auf ein vertretbares Maß reduziert, sodass eine Vielzahl von Konfigurationen in akzeptabler Zeit vermessen werden kann. Auch wenn die beiden Benchmarks OLTP-2 und TPC-E ähnliche Anwendungsszenarien simulieren und die gleichen Lastprofile verwenden, so sind die Ergebnisse nicht vergleichbar oder gar gleichzusetzen, da die beiden Benchmarks unterschiedliche Methoden zur Simulation der Benutzerlast verwenden. Typischerweise sind OLTP-2-Werte TPC-E-Werten ähnlich. Ein direkter Vergleich oder gar die Bezeichnung des OLTP-2- Ergebnisses als TPC-E-Ergebnis ist nicht zulässig, da insbesondere kein Preis-Leistungswert ermittelt wird. Benchmark-Ergebnisse Die PRIMERGY RX200 S5 wurde mit Prozessoren der Serie 5500 bei Speicherausbauten von 24 GB, 36 GB, 48 GB, 72 GB und 96 GB vermessen. Alle Ergebnisse basieren auf dem Betriebssystem Microsoft Windows Server 2008 Enterprise x64 Edition und der Datenbank SQL Server 2008 Enterprise x64 Edition. OLTP-2 Benchmark-Ergebnisse sind in hohem Maße abhängig von den Ausbaumöglichkeiten eines Systems mit Festplatten und deren Controllern. Für die Messungen wurden daher zwei 2-Kanal Fibre Channel Controller verwendet, über die fünf FibreCAT CX500 mit insgesamt 450 Festplatten angeschlossen waren. Das Disk-Subsystem wurde derart dimensioniert, dass es in der Messung kein Engpass ist. Es können vergleichbare Ergebnisse mit anderen Disk-Subsystemen erreicht werden, wenn diese ebenfalls keinen Engpass darstellen. Weitere Informationen über die Systemkonfiguration können dem Abschnitt Benchmark- Umgebung entnommen werden. In der maximalen Speicherausbaustufe der PRIMERGY RX200 S5 mit 6 Speichermodulen bei einem Prozessor und 12 Speichermodulen bei 2 Prozessoren erfolgt die Speicheransteuerung mit 1067 MHz für die Prozessortypen E5520, E5530, E5540, X5550, X5560 und X5570. Bei den Prozessortypen E5502, E5504 und E5506 erfolgt die Speicheransteuerung mit 800 MHz. Die folgenden Grafiken zeigen die OLTP-2-Leistungsdaten der PRIMERGY RX200 S5 in zwei Gruppen mit einem und zwei Prozessoren der Serie 5500 (E5502, E5504, E5506, E5520, E5530, E5540, X5550, X5560 und X5570). Die Leistungswerte des L5530 sind denen des E5530, die des L5520 denen des E5520 und die des L5506 denen des E5506 gleichzusetzen. Die größte Leistungssteigerung bei den Prozessortypen ist von E5502 nach E5504 mit +95% bis +98% durch die Verdopplung der Anzahl Cores von zwei auf vier. Ebenfalls deutlich ist die Steigerung von E5506 nach E5520 mit +56% bzw. +57% durch die Verdopplung des Prozessor-Caches von 4 MB auf 8 MB und die Nutzung von Hyper-Threading. Der Leistungsgewinn von E5520 nach X5570 beträgt +22% und +24%. Die Speicherskalierung von 36 GB auf 48 GB ist ca. +8% und von 72 GB auf 96 GB ca. +3%. Dies ist sehr stark vom Lastprofil des OLTP-2-Benchmarks abhängig und kann nicht auf alle Datenbankanwendungen übertragen werden. Fujitsu Technology Solutions Seite 21 (40)

22 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 OLTP-2: OLTP-2: PRIMERGY PRIMERGY RX200 RX200 S5 S5 with with 1 processor processor 55xx 55xx tps tps bold bold numbers: numbers: measured measured results results others: others: calculated calculated results results RAM RAM +57% +23% +57% +23% GB GB % +98% GB GB GB GB E5502 E5502 E5504 E5504 E5506 E5506 E5520 E5520 E5530 E5530 E5540 E5540 X5550 X5550 X5560 X5560 X5570 X5570 tps tps OLTP-2: OLTP-2: PRIMERGY PRIMERGY RX200 RX200 S5 S5 with with 2 processors processors 55xx 55xx bold bold numbers: numbers: measured measured results results others: others: calculated calculated results results E5502 E % +95% E5504 E5504 E5506 E5506 E5520 E % +22% +56% +22% RAM RAM E5530 E5530 E5540 E5540 X5550 X GB GB GB GB GB GB X5560 X5560 X5570 X5570 Fujitsu Technology Solutions Seite 22 (40)

23 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Vergleicht man die PRIMERGY RX200 S5 mit ihren Vorgängern, der PRIMERGY RX200 S3 und RX200 S4, in jeweils performantester Ausstattung, so ergibt sich eine Durchsatzsteigerung von 179% bzw. 135% OLTP-2: OLTP-2: PRIMERGY PRIMERGY RX200 RX200 S3 S3 vs. vs. RX200 RX200 S4 S4 vs. vs. RX200 RX200 S5 S % +179% % +135% PRIMERGY PRIMERGY RX200 RX200 S3 S3 2 2 x x X5365 X GB GB RAM RAM PRIMERGY PRIMERGY RX200 RX200 S4 S4 2 2 x x X5460 X GB GB RAM RAM PRIMERGY PRIMERGY RX200 RX200 S5 S5 2 2 x x X5570 X GB GB RAM RAM Fujitsu Technology Solutions Seite 23 (40)

24 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Umgebung Load generators System Under Test LAN Switch System Under Test (SUT) Hardware Server Processor Memory Settings (default) Network Interface Disk Subsystem Software Operating System Database PRIMERGY RX200 S5 E5502, E5504, E5506, E5520, E5530, E5540, X5550, X5560, X5570 Up to 12 x 8 GB DDR3 PC3-8500R Turbo Mode enabled, NUMA Support enabled, Hyper-Threading enabled 2 x 1-GBit LAN (onboard) PRIMERGY RX200 S5: 1 x LSI SAS with 1068E 2x 2.5" 36GB 15K Fujitsu MAY2073RC RAID-1, OS 6x 2.5" 73GB 15K Fujitsu MAY2073RC RAID-0, log 2 x dual-channel FC controller QLE x FibreCAT CX500: 315 x Seagate 36 GB 15 krpm 135 x Seagate 73 GB 15 krpm RAID-0, data Windows Server 2008 Enterprise x64 Edition SQL Server 2008 Enterprise x64 Edition Load Generators Hardware Model 4 x PRIMERGY Econel 200 Processor 2 x 3.40 GHz, 2 MB L2 cache Memory 2 GB DDR-SDRAM PC2700 Network Interface 1 x 1-GBit LAN (onboard) Software Operating System Windows Server 2003 Standard Edition SP1 (x86) OLTP-2 Software EGen version Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. Fujitsu Technology Solutions Seite 24 (40)

25 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Terminal Server Benchmark-Beschreibung Für die Messungen von Terminal Server gibt es verschiedene Lastsimulationswerkzeuge, deren Messergebnisse nicht miteinander vergleichbar sind, aber keinen Standard-Benchmark. Die existierenden Lastsimulatoren sind nicht in der Lage, Microsoft Terminal Services und Citrix Presentation Server unter den gleichen Bedingungen zu vermessen oder haben andere Einschränkungen. Fujitsu Technology Solutions setzt daher ein selbst entwickeltes Programm namens T4US,»Tool for User Simulation«, ein. Dieses flexible Werkzeug, das beliebige Terminal Server-artige Szenarien simulieren kann, ist unabhängig vom verwendeten Betriebssystem und von der Anwendersoftware und kann eine detaillierte Messwerterfassung von Antwortzeiten und Auslastung unterschiedlichster Systemkomponenten vornehmen. 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 Controller Lastgenerator des T4US-Playback. Jedes T4US-Playback»füttert«einen Terminal Server Client in Echtzeit mit Tastatur- und Mauseingaben anhand der 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. T4US Agent mit T4US-Record T4US Terminal Control Server aufgezeichneten Skripte TS Client und überwacht die Bildschirminhalte des Terminal Server Clients. Durch hoch auflösende Timer wird so die Antwortzeit des Terminal Servers ermittelt. Auf jedem der Lastgeneratoren läuft ein T4US-Agent, der für die Kommunikation mit dem Controller zuständig ist, die Instanzen von T4US-Playback steuert und überwacht und die ermittelten Antwortzeiten zum Controller überträgt. Bei der Messung wird die Anzahl der Benutzer, die mit dem Terminal Server arbeiten, kontinuierlich erhöht. Die Antwortzeiten des Terminal Servers werden vom T4US-Controller überwacht und mit gespeicherten Referenzwerten, die in einer vorhergehenden Referenzmessung mit nur wenigen Benutzern ermittelt worden sind, verglichen. Wenn sich die Antwortzeit der Anwendung so weit verschlechtert, dass sie den vorgegebenen Regeln nicht mehr genügt, wird die Messung beendet und man erhält die Benutzeranzahl als Resultat der Messung. Diese Zahl sollte man jedoch nicht absolut nehmen, da die Anzahl Benutzer, die ein System unterstützen kann, immer abhängig ist vom tatsächlichen Benutzerprofil. Stattdessen sollten die Ergebnisse relativ betrachtet werden, also beispielsweise»ein PRIMERGY System A ist doppelt so leistungsfähig wie ein PRIMERGY System B«oder»die Verdopplung des Arbeitsspeichers resultiert in x% Leistungssteigerung«. T4US Play T4US Play T4US Play System under Test (SUT) TS Client TS Client SUT Fujitsu Technology Solutions Seite 25 (40)

26 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Lastprofil V2 Das bisher in den Terminal Server Messungen benutzte Lastprofil V1, bei dem sich jeder Benutzer zyklisch beim Terminal Server anmeldet, einen bebilderten Text erstellt und sich dann wieder abmeldet, kann nicht mehr weiter verwendet werden. Durch die verbesserte Leistung der zu vermessenden Systeme kommt der Benchmark in eine Größenordnung, bei der die Benutzeranzahl durch die durchzuführenden An- und Abmeldevorgänge, also Restriktionen im Betriebssystem, erreicht wird und nicht mehr durch die Prozessorleistung des Systems. Das bedeutet, der Benchmark erreicht seine Grenzwerte schon, ohne den Prozessor auszulasten. Verbesserte Prozessorleistung wird durch den Benchmark nicht messbar. Deshalb wird bei den hier durchgeführten Messungen ein neues Lastprofil V2 eingesetzt. Das neue Lastprofil V2 zeichnet sich dadurch aus, dass ein zu simulierender Benutzer mit verschiedenen Microsoft Office Anwendungen 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 alten Lastprofil 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. Der Speicherbedarf beim Terminal Server Benchmark wächst linear mit der Anzahl der Benutzer. Er ist abhängig von dem unterliegenden Betriebssystem, insbesondere ergeben sich Unterschiede bei 32-bit- und 64-bit-Betriebssystemen. Ausführlich behandelt wird dieser Aspekt in dem Dokument Terminal Server Sizing Guide (siehe Literaturverzeichnis). In der nebenstehenden Grafik ist der Speicherbedarf des Benchmarks mit dem Lastprofil V2 auf einem 64-bit Windows Server 2008 System dargestellt. Dadurch dass die Benutzer nun mit verschiedenen Anwendungen arbeiten, fällt der Speicherverbrauch beim Lastprofil V2 höher aus als beim ursprünglichen Lastprofil V1. In den weiteren Grafiken werden die durchschnittlichen IO-Raten der Platten und des Netzwerkes sowie die zugehörigen Datendurchsätze aufgeführt, die dieses Lastprofil V2 auf einem Windows Server 2008 x64 System erzeugt. Fujitsu Technology Solutions Seite 26 (40)

27 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Ergebnisse Bei allen durchgeführten Messungen war das Terminal Server System mit dem Betriebssystem»Windows Server 2008 x64 Enterprise Edition SP1«ausgestattet. Auf Messungen mit einem 32-bit Betriebssystem wurde wegen der Limitierungen bei der Adressierung des Arbeitsspeichers und bei den Kernelstrukturen und der damit einhergehenden Beschränkung der Benutzeranzahl verzichtet. Alle Installationen sind Standard, für die Messungen wurden keine Optimierungen an Server oder Client durchgeführt bis auf: Die Page-Datei des Betriebssystems wurde auf eine feste Größe von 28 GB eingestellt. Für ein Terminal Server-System sind die folgenden Performance-relevanten Faktoren maßgeblich: Rechenleistung Arbeitsspeicher Disk-Subsystem Netzwerk Netzwerk Einen erheblichen Einfluss auf eine Infrastruktur, die auf Terminal Server basiert, hat die zugrunde liegende Netzwerkinfrastruktur. Da wir hier die Leistungsfähigkeit eines einzelnen Terminal Servers diskutieren, wurde das Netzwerk so dimensioniert, dass es keinen Engpass darstellt. Disk-Subsystem Eine weitere Performance-relevante Komponente ist das Disk-Subsystem. In der hier verwendeten Messumgebung wird das Betriebssystem auf einer Partition eines RAID 0-Verbandes zweier Festplatten, die Daten der Benutzer und das Pagefile werden auf Partitionen eines RAID 0-Verbandes weiterer zweier Festplatten des Terminal Servers gespeichert. Diese Konfiguration wird verwendet, damit die Messergebnisse zwischen den verschiedenen PRIMERGY Systemen vergleichbar sind und das Disk- Subsystem nicht zum Engpass bei der Messung wird. Dies entspricht jedoch nicht zwingend der realen Kundenkonfiguration, denn dort wird man die Benutzerdaten typischerweise auf entsprechende Disk- Subsysteme oder externe File Server legen und nicht auf lokale Festplatten eines Terminal Servers. Um einen maximalen Durchsatz zu erreichen, wurden alle Caches, auch die Write-Caches, eingeschaltet. 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. Arbeitsspeicher Den stärksten Einfluss auf die Leistungsfähigkeit eines Terminal Servers übt der Arbeitsspeicher aus. Das spiegelt sich insbesondere in der Antwortzeit wider, denn Windows verschafft sich bei Bedarf weiteren virtuellen Speicher durch Auslagern (Swappen) von momentan nicht benötigten Daten aus dem Arbeitsspeicher (RAM) in die Auslagerungsdatei (Swap-File) 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. Da ein Terminal Server mit vielen Benutzern und verschiedenen Anwendungen arbeitet, kommt es also in erster Linie darauf an, das System mit ausreichend Speicher bestückt zu haben. Die Speicherzugriffsgeschwindigkeit ist dann ein nachrangiger Faktor. Die PRIMERGY RX200 S5 bietet mit einem maximalen Speicherausbau von bis zu 96 GB eine gute Plattform für Terminal Server. Die Speicherzugriffsgeschwindigkeit bei der PRIMERGY RX200 S5 ist sowohl abhängig vom Prozessor als auch von der Speicherbestückung. Die beste Zugriffsgeschwindigkeit wird erreicht, wenn die Speicherstreifen nur auf eine Bank, verteilt über die der CPU zugeordneten Kanäle, gesteckt werden. Bei den hier durchgeführten Messungen waren die vermessenen Terminal Server Systeme mit ausreichend Speicher ausgestattet. Die PRIMERGY RX200 S5 war mit 6 4 GB Memory, verteilt auf je drei Kanäle pro CPU, optimal für die Anzahl simulierter Benutzer und auch optimal für geringe Speicherzugriffszeiten bestückt. Eine Verdopplung des Speichers auf 48 GB brachte keine Verbesserung der Benchmark- Ergebnisse. Fujitsu Technology Solutions Seite 27 (40)

28 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Rechenleistung Die PRIMERGY RX200 S5 kann je nach Bedarf mit verschiedenen Prozessoren ausgestattet werden, die sich hinsichtlich Taktfrequenz, Cache, Transferrate des Quick Path Interconnects (Gigatransfer, GT) und Anzahl Kerne unterscheiden. Für den Terminal Server Benchmark wurde das System sowohl mit dem kleinsten Quad-Core Prozessor, dem E5504, und dem zurzeit stärksten Quad-Core Prozessor für dieses System, dem X5570, vermessen. Im Gegensatz zum E5504 verfügt der X5570 sowohl über Hyper-Threading als auch über die Turbo Boost Technologie, die abhängig von der Anwendung den Prozessor automatisch beim Arbeiten unterhalb der maximalen Energieaufnahme (Thermal Design Power (TDP)) übertaktet. Weitere Kennzeichen der vermessenen Prozessoren sind E5504, 2.00 GHz, 4.8 GT, max. 800 MHz DDR3 Bus Speed, 4 MB L3-Cache, 80 Watt X5570, 2.93 GHz, 6.4 GT, max MHz DDR3 Bus Speed, 8 MB L3-Cache, 95 Watt Die mit dem neuen Lastprofil V2 erreichten maximalen Benutzerzahlen pro System sind nicht vergleichbar mit den Benutzerzahlen, die durch das frühere Lastprofil V1 erreicht wurden. Um Konfusion zu vermeiden, werden die Ergebnisse des Benchmarks deshalb nicht mehr in absoluten Benutzerzahlen dargestellt, sondern nur noch relativ zu einem zuvor gemessenen Referenzsystem, hier eine PRIMERGY TX200 S4 bestückt mit bis zu zwei E5430 Prozessoren, die weder über Hyper-Threading noch über Turbo Boost Technologie verfügen. E5430, 2.67 GHz, 1333 MHz Front-Side-Bus, 2 6 MB L2-Cache, 80 Watt Der Terminal Server Benchmark mit dem neuen Lastprofil V2 skaliert gut. Sowohl bei dem Referenzsystem als auch bei der PRIMERGY RX200 S5 mit dem E5504 wird durch eine Verdoppelung der Prozessoranzahl, d.h. von vier auf acht Kerne, eine Steigerung der System-Performance um den Faktor 1.8 erreicht. Der X5570 besitzt bei Einschalten des Hyper-Threadings acht logische CPU- Kerne. Die Hinzunahme einer zweiten CPU bedeutet also die Steigerung von acht auf 16 logische Kerne. Selbst bei diesen Messungen erreicht der Benchmark noch eine gute Skalierung der System-Performance von über 1.7. Das PRIMERGY RX200 S5 System mit dem E5504 liegt in der System- Performance in der gleichen Größenordnung wie das Referenzsystem. Wird das PRIMERGY RX200 S5 System mit den stärkeren X5570 Prozessoren bestückt, so wird bei dem Terminal Server Benchmark mehr als eine Verdoppelung der System-Performance erreicht. Neben der höheren Taktfrequenz und dem größeren Second Level Cache ist auch der Memory Zugriff schneller. Bei beiden Messungen war das System mit 6 4 GB Speicher ausgestattet. Der Terminal Server Benchmark profitiert dabei sehr gut von den zusätzlichen logischen Kernen. Bei der auftretenden Lastspitzen des Terminal Server Benchmarks wirkt auch die Turbo Boost Technologie des X5570 Performance-steigernd. Insgesamt zeigt sich die PRIMERGY RX200 S5 gut für Terminal Server Anwendungen geeignet. Durch Technologien wie Hyper-Threading und Turbo Boost ergibt sich eine starke Prozessorleistung, die in Verbindung mit einem großen Speicherausbau in der Praxis eine hohe Anzahl an Terminal Server Benutzern erlaubt. Dabei muss sich die tatsächliche Anzahl Benutzer jedoch immer nach dem aktuellen Kundenlastprofil richten. Fujitsu Technology Solutions Seite 28 (40)

29 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Umgebung Unten stehende Grafik zeigt die Umgebung, in der die Terminal Server Performance Messungen durchgeführt wurden. Ein Lastgenerator kann eine Vielzahl von Benutzern simulieren, da die Anwendungen auf dem Server ablaufen. Es werden bei den Terminal Server Protokollen nur Tastatureingaben und Mausklicks zum Server und Änderungen des Bildschirminhalts zum Client übertragen. Daher wird keine große Netzwerk-Bandbreite benötigt. Die Anbindung der Lastsimulatoren an den Terminal Server (auch System under Test (SUT) genannt) erfolgte über ein 100-MBit-Ethernet-Netzwerk, wobei der Terminal Server über den Gigabit-Uplink angeschlossen war. Die Benutzerprofile wurden auf dem Terminal Server gespeichert. Auch die Dateien der Benutzer, die während der Messung gelesen und geschrieben wurden, lagen lokal auf dem Terminal Server. Der sich auch im SUT-Netzwerk befindende Infrastruktur-Server stellt dem zu vermessenden Terminal Server Basisdienste wie Active Directory, DNS und Terminal Services Licensing zur Verfügung. Ein Login der simulierten Benutzer fand immer gegen das Active Directory statt. 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 System Under Test (SUT): Der Terminal Server wurde mit den Microsoft Terminal Services betrieben, die im Windows Betriebssystem enthalten sind. Auf dem Terminal Server wurde neben den in der Tabelle aufgeführten Anwendungen keine weitere Software installiert. Hardware Modell Prozessor Speicher Netzwerk-Interface Disk Subsystem ca. 40 PRIMERGY Dual Server Windows Server 2003 TS-Client T4US-Agent, T4US-Playback Jeder simuliert bis zu 12 Benutzer PRIMERGY RX200S5 // PRIMERGY TX200S4 1-2 E5504 // 1-2 E X GB // 12 GB 1 1-GBit LAN Intel (onboard) // Broadcom 2 SAS Controller: LSI 1078 Modular RAID 4 SAS Festplatten, 15 krpm, RAID 0 Software Betriebssystem Windows Server 2008 x64 Enterprise Edition Version Service Pack 1 Netzwerkprotokoll TCP/IP Disk Organisation 1 Volume für das Betriebssystem je 1 Volume für Daten und Pagefile Terminal Server Microsoft Terminal Services Software Anwendung Microsoft Office 2003 (32-bit), 7-Zip 4.57 PRIMERGY Windows Server 2008 Enterprise Edition PRIMERGY C200 Windows Server 2003 Active Directory Terminal Server Licensing Service T4US Messumgebung: Die Lastgeneratoren simulieren eine Vielzahl von Benutzern, die mit dem Terminal Server arbeiten. Ein T4US-Controller steuert und überwacht den gesamten Simulationslauf. Der Infrastruktur-Server stellt Basisdienste zur Verfügung. Lastgenerator-Hardware Modell PRIMERGY RX100 S3 // PRIMERGY BX300 # Lastgeneratoren 20 // 20 Prozessor Pentium D 940 // 2 Pentium III 933 MHz Memory 2 GB // 1 GB Netzwerk-Interface 2 1 GBit LAN T4US Controller- und Infrastrukturserver-Hardware Model PRIMERGY C200 Prozessor 2 Pentium III 1.40 GHz Memory 1.5 GB Netzwerk-Interface MBit LAN Software Betriebssystem Windows Server 2003 Standard Edition SP2 Netzwerkprotokoll TCP/IP RDP Client T4US Version 3.3 T4US Lastprofil T4US Lastprofil V2 Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. Fujitsu Technology Solutions Seite 29 (40)

30 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 mark 1 Benchmark-Beschreibung mark ist ein von ware entwickelter Benchmark zum Vergleich von Serverkonfigurationen mit Hypervisor-Lösungen von ware in Bezug auf ihre Eignung für Server-Konsolidierung. mark ist derzeit der einzige etablierte Benchmark für diesen Zweck. Neben der Software zur Lastgenerierung besteht der Benchmark aus einem definierten Lastprofil und aus einem verbindlichen Regelwerk. Mit mark erzielte Benchmark-Ergebnisse können bei ware eingereicht werden und werden nach einem erfolgreich durchlaufenen Review-Prozess auf deren Internet-Seite veröffentlicht. Damit ein Benchmark wie mark seinem Ziel gerecht wird, muss er die Realität in den Rechenzentren bei der Serverkonsolidierung abbilden, er muss also Bestandsserver mit solchen Anwendungsszenarien betrachten, die typischerweise virtualisiert werden. Diese Server sind schwach ausgelastet, und man strebt deswegen an, möglichst viele von ihnen als s zu konsolidieren. Ein solcher Benchmark muss also für einen Virtualisierungs-Host sowohl den geeignet gemittelten Gesamtdurchsatz über verschiedene Anwendungs-s bewerten als auch die Anzahl der effizient betreibbaren s. Für diese zweiteilige Zielsetzung hat sich folgendes Lösungskonzept etabliert: Man definiert im Benchmark eine repräsentative Auswahl von Anwendungsszenarien. Diese werden bei einer Messung gleichzeitig als s auf einem Virtualisierungs-Host gestartet. Jede dieser s wird mit einem geeigneten Last-Tool auf einem definierten niedrigen Lastniveau betrieben. Eine solche Gruppe von s nennt man eine»tile«(engl. für Kachel). Bei mark besteht eine Tile aus sechs s, von denen fünf dediziert den ausgewählten Anwendungsszenarien zugeordnet sind. Hinzu kommt eine sechste, so genannte Standby-. Jeder sind von mark her zwingend bestimmte Ressourcen an logischen Prozessoren, Memory und Festplattenplatz zugeordnet. Die nebenstehende Tabelle beschreibt diese sechs s und die Last-Tools, mit denen sie jeweils vermessen werden. Anwendungsszenario Database-Server File-Server Java-Applikationsserver Last-Tool Sysbench Dbench (angepasst) SPECjbb2005 (angepasst) Mail-Server LoadSim 2003 Web-Server Standby-Server - SPECweb2005 (angepasst) Je nach Leistungsfähigkeit der zugrunde liegenden Server-Hardware ist es meist notwendig, dass im Rahmen einer Messung mehrere identische Tiles parallel gestartet werden um eine maximale Gesamt- Performance zu erreichen. System under Test Database Fileserver Java Mail Web Standby Tile n Database Fileserver Database Fileserver Fileserver Database Java Java Java Mail Mail Mail Web Web Web Standby Standby Standby Tile 3 Tile 2 Tile 1 1 Zur Information über mark und seine Benutzungsregeln folgen Sie bitte dem Link ware und mark sind Warenzeichen bzw. eingetragene Warenzeichen von ware, Inc. ware mark ist ein Produkt von ware, Inc. mark benutzt SPECjbb 2005 und SPECweb 2005, welche bei der Standard Performance Evaluation Corporation (SPEC ) verfügbar sind. Fujitsu Technology Solutions Seite 30 (40)

31 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Jedes der fünf mark-anwendungsszenarien ergibt für jede ein spezifisches Ergebnis. Um hieraus eine Bewertungszahl (Score) zu bilden, werden die einzelnen Ergebnisse über alle s geeignet zusammengefasst. Das Ergebnis ist dann der mark-score für diese Tile-Anzahl, daher wird neben dem eigentlichen Score immer die Tile-Anzahl genannt, z.b.»12.34@5 tiles«. Eine ausführliche Beschreibung von mark ist im Übersichtsdokument mark - Benchmark Überblick zu finden. Benchmark-Ergebnisse Am 11. August 2009 erzielte Fujitsu mit einer PRIMERGY RX200 S5 und ware ESX 4.0 einen mark- Score von»24.20@17tiles«. Dieses Messergebnis sowie die ausführlichen Resultate und Konfigurationsdaten sind unter veröffentlicht. Mit dem Score von»24.20@17 tiles«ist die PRIMERGY RX200 S5 aus mark-sicht der leistungsstärkste 1U-Rackserver mit acht Cores und belegt zugleich den dritten Platz in der mark-rangliste der Server in der Acht-Core-Kategorie (zum Zeitpunkt der Veröffentlichung des Benchmark-Ergebnisses). Wesentliche Voraussetzungen zur Erreichung dieses Ergebnisses waren der verwendete Prozessor, ein X5570, und die verwendete Hypervisor-Version, die die Prozessor-Features optimal nutzt. Zu diesen Features gehören die»erweiterten Seitentabellen«(englisch»Extended Page Tables«, kurz EPT) 2, das Hyper-Threading und die schnelle Speicheranbindung dieser Prozessorarchitektur. All dies wirkt sich speziell bei der Virtualisierung positiv aus. Zum Betrieb der 17 Tiles war ein Speicherausbau von 96 GB (12 8 GB) notwendig. Alle s, deren Anwendungsdaten, das Host-Betriebssystem sowie weitere erforderliche Daten befanden sich auf einem leistungsfähigen Fibre-Channel Disk-Subsystem mit 37 LUNS. Bemerkenswert ist, dass bei der vermessenen PRIMERGY RX200 S5 die s für ihre Netzwerkzugriffe mit zwei physikalischen 1Gb-LAN-Ports auskamen. Fast alle vergleichbaren veröffentlichten mark-resultate der Mitbewerber verwendeten hierfür mehr physikalische LAN-Ports oder die 10Gb-Technologie. 2 EPT beschleunigt die Virtualisierung von Memory durch eine Hardware-Unterstützung für die Umsetzung zwischen Host- und Gast-Memory-Adressen. Fujitsu Technology Solutions Seite 31 (40)

32 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Umgebung Der Messaufbau wird symbolisch durch folgende Grafik veranschaulicht: Controller Server Storage-System Mehrere 1Gb oder 10Gb Netzwerke Lastgeneratoren System under Test (SUT) SUT-Hardware Modell PRIMERGY RX200 S5 Prozessor 2 X5570 (2.93 GHz) Memory 96 GB (12 8 GB per DIMM), 1066 MHz registered ECC DDR3 Netzwerk- Interface Disk-Subsystem Storage- Anbindung Integrierter Intel 82575EB dual port 1GbE Adapter und ein Intel 82571EB quad port Adapter. Davon 1 Port für die Service Console, 1 Port für die Webserver-s und 1 Port für alle übrigen s. Es wurden keine internen Festplatten verwendet, sondern ausschließlich vier Storage-Systeme FibreCAT CX500, insgesamt 291 Festplatten. Pro Tile eine 100 GB LUN über 11 Disks exklusiv und eine 24 GB LUN über 15 Disks geteilt mit je 2 anderen dieser LUNS. Eine 11 GB LUN über 5 Disks für das Host- OS Eine 120 GB LUN über 5 Disks für die Konfigurationen und als Swap-Bereich Eine 150 GB LUN über 5 Disks für Backup Alle LUNs sind RAID 0 Verbände aus Seagate ST373454FCV-Disks (15 krpm) Über dual port FC-Controller Qlogic QLE 2462 SUT-Software Betriebssystem Hypervisor ware ESX Server Version Version build BIOS Version 6.00 R1.05A.2786; Default- Einstellungen Lastgenerator-Hardware Modell 17 Server-Blades PRIMERGY BX620 S4 (1 pro Tile) Prozessor Intel 5130, 2 GHz Memory 3 GB Netzwerk-Interface Je 1 GBit LAN Betriebssystem W2K3 R2 EE, SP2 + KB Einige Komponenten sind möglicherweise nicht in allen Ländern / Vertriebsregionen verfügbar. Fujitsu Technology Solutions Seite 32 (40)

33 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 vservcon Benchmark-Beschreibung vservcon ist ein bei Fujitsu Technology Solutions verwendeter Benchmark zum Vergleich von Serverkonfigurationen mit Hypervisor in Bezug auf ihre Eignung für Server-Konsolidierung. Hiermit ist sowohl der Vergleich von Systemen, Prozessoren und I/O-Technologien möglich, wie auch der Vergleich von Hypervisor-en, Virtualisierungsformen und zusätzlichen Treibern für virtuelle Maschinen. Bei vservcon handelt es sich um ein Framework, das bereits etablierte Benchmarks zusammenfasst, um die Last einer konsolidierten und virtualisierten Serverumgebung nachzubilden. Es kommen drei bewährte Benchmarks zum Einsatz, die die Anwendungsszenarien Datenbank, Applikationsserver und Webserver abdecken: Anwendungsszenario Benchmark Anzahl logische CPU-Cores Memory Database Sysbench (angepasst) GB Java-Applikationsserver SPECjbb (angepasst, mit 50% - 60% Last) 2 2 GB Webserver WebBench GB Jeder der drei Standard-Benchmarks wird jeweils einer dedizierten virtuellen Maschine () zugeordnet. Hinzu kommt eine vierte, so genannte Idle-. Diese vier s bilden eine»tile«(engl. Kachel). Je nach Leistungsfähigkeit der zugrunde liegenden Server- Hardware kann es notwendig sein, dass im Rahmen einer Messung auch mehrere identische Tiles parallel gestartet werden müssen, um eine maximale Performance-Bewertungszahl (Score) zu erreichen. Jedes der drei vservcon-anwendungsszenarien ergibt für jede ein spezifisches Benchmark-Ergebnis in Form von applikationsspezifischen Transaktionsraten. Um hieraus einen Score für eine gegebene Tile-Anzahl zu bilden, werden die einzelnen Benchmark-Ergebnisse in Relation zu den jeweiligen Ergebnissen eines Referenzsystems gesetzt. Als Referenzsystem für vservcon ist eine PRIMERGY RX300 S3 definiert worden. Die daraus resultierenden dimensionslosen Performance-Werte werden dann unter Berücksichtigung Loadgen. Load Loadgen. Web Web Web System Under Test der Anzahl der virtuellen CPUs und der Memory-Größe gewichtet und über alle s und Tiles aufsummiert. Das Ergebnis ist der vservcon-score für diese Tile-Anzahl. Diese Prozedur wird in der Regel beginnend mit eins für steigende Tile-Anzahlen durchgeführt, bis keine signifikante Steigerung dieses vservcon-scores mehr eintritt. Der finale vservcon-score ist dann das Maximum über die vservcon-scores aller Tile-Anzahlen. Er spiegelt für eine Serverkonfiguration mit Hypervisor den maximalen summarischen Konsolidierungs-Nutzen über alle s wider. Ferner werden bei vservcon die Gesamt-CPU-Auslastung des Hosts (s und alle übrigen CPU- Aktivitäten) und soweit möglich die elektrische Leistungsaufnahme dokumentiert. Der Score soll eine virtualisierungsspezifische Leistung eines Systems ausdrücken, die man bis zur möglichst vollständigen Ausnutzung der CPU-Ressourcen mittels vieler s erzielen kann. Der Score wäre also nicht aussagekräftig, wenn während einer vservcon-messung schon bei einer unnötig kleinen Tile- Anzahl eine Limitierung eintreten würde, z. B. durch eine nicht ausreichend dimensionierte Disk-Anbindung oder nicht genügend Hauptspeicher. Deswegen wird die Messumgebung für vservcon-messungen so ausgelegt, dass nur die CPU der begrenzende Faktor ist, und keine Limitierungen durch andere Ressourcen eintreten. Zu diesem Zweck und zu Zwecken der Vergleichbarkeit wird für alle benutzten s in vservcon ein genau festgelegtes Profil für die virtuellen Hardware-Ressourcen, das Betriebssystem und die Anwendungen verwendet. Eine ausführliche Beschreibung von vservcon ist zu finden im Übersichtsdokument: vservcon - Benchmark Überblick. Web Database Tile Tile Tile Java Framework Controller Idle Fujitsu Technology Solutions Seite 33 (40)

34 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Benchmark-Ergebnisse Die PRIMERGY RX200 S5 ist durch erhebliche Fortschritte in der Prozessortechnologie gut für die Virtualisierung von Anwendungen geeignet. Verglichen mit dem Vorgängersystem ist eine etwa zweifache Virtualisierungs-Performance (gemessen in vservcon-score) erreichbar. So ist auf Basis des zuvor beschriebenen vservcon-profils bei Vollausbau mit zwei Prozessoren durch 18 echte Anwendungs- s (entsprechend sechs Tiles) eine nahezu optimale Auslastung der CPU-Ressourcen des Systems möglich. Das erste Diagramm veranschaulicht dies für die PRIMERGY RX200 S5 durch die vservcon-scores in Abhängigkeit vom Prozessor und der Anzahl der Tiles. Zusätzlich sind die jeweiligen CPU-Auslastungen des Hosts eingetragen. Im Bereich um 90% liegen typischerweise die Tile-Anzahlen mit optimaler CPU- Ausnutzung; jenseits davon liegt der Überlastbereich, in dem die Virtualisierungs-Performance nicht mehr zunimmt bzw. wieder abnimmt. Die Leistungsfähigkeit dieser aktuellen Prozessoren zeigt sich in einer Steigerung der Gesamt- Performance bis hin zu sechs Tiles. Die vservcon-scores steigen zudem erkennbar mit der Prozessorfrequenz an. Die hohe Tile-Anzahl wird insbesondere durch das Hyper-Threading ermöglicht, wobei bekanntermaßen ein physikalischer Prozessorkern in zwei logische Cores unterteilt wird, so dass für den Hypervisor 16 logische Cores verfügbar sind. Dieses standardmäßig eingestellte Feature steigert daher im Allgemeinen die Virtualisierungs-Performance eines Systems. Spezifisch für Systeme mit Hyper-Threading ist der Verlauf dieser Skalierungskurven über die Tile-Anzahl. Aufgrund der pro Tile verwendeten etwa vier logischen CPUs (siehe Benchmark-Beschreibung) wird bis etwa zwei Tiles eine parallele Nutzung gleicher physikalischer Cores durch mehrere s vermieden. Daher skaliert die Performance in diesem Bereich nahezu ideal. Darüber verläuft der Performance-Zuwachs bis zur CPU-Sättigung flacher. Als Richtschnur für die Auswahl von Arbeitsspeicher gilt im Virtualisierungsumfeld, dass eine ausreichende Menge wichtiger ist als die Geschwindigkeit der Speicherzugriffe. Fujitsu Technology Solutions Seite 34 (40)

35 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Ein wesentlicher Aspekt der Server-Konsolidierung ist die Einsparung elektrischer Energie. So kann man z. B. beim E5540 Prozessor allein durch die Verdoppelung der Anzahl der echten Anwendungs-s von drei auf sechs die Virtualisierungs-Performance um 76% steigern, während gleichzeitig die elektrische Leistungsaufnahme nur um ca. 11% ansteigt. Die Power-Aspekte für die oben dargestellten Prozessoren veranschaulicht das folgende Diagramm. Darin sind zum einen die absoluten Unterschiede in der Leistungsaufnahme dargestellt, zum anderen das Verhältnis vservcon-score zur Leistungsaufnahme in kw, im Diagramm kurz als»vservcon Power score«bezeichnet. Im Vorangegangenen wurde die Virtualisierungs-Performance des Systems in Gänze betrachtet. Im Folgenden soll noch die Performance aus Sicht einer einzelnen Anwendungs- in der beschriebenen virtualisierten Umgebung diskutiert werden. Dazu wird im Folgenden exemplarisch das System mit dem Prozessor X5570 betrachtet. Wenn die Anzahl der Anwendungs-s im optimalen Bereich aus Sicht der Gesamt- Performance liegt, ist die Performance einer einzelnen schon merklich geringer als im Betrieb in Niedriglastsituationen. Das nebenstehende Diagramm verdeutlicht dies durch die relative Performance im Verhältnis zum Referenzsystem bei einer einzelnen Anwendungs- von jedem der drei Typen für wachsende -Anzahlen. Die jeweils erste Säule einer Gruppe betrachtet eine im Verbund von insgesamt drei Anwendungs-s (1 Tile), die jeweils zweite im Verbund von 6 Anwendungs-s (2 Tiles) usw. Die Werte sind sowohl einzeln dargestellt als auch summiert über alle s des jeweiligen Typs durch die Höhe der gestapelten Säule. Bezüglich der -Anzahlen auf einem Virtualisierungs-Host muss man im konkreten Fall die Performance- Anforderungen einer einzelnen Anwendung gegen die Gesamtanforderungen abwägen. Fujitsu Technology Solutions Seite 35 (40)

36 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Wenn man Anwendungen in virtuellen Maschinen mit größtmöglicher Performance betreiben will, lohnt sich ein genauer Blick auf solche Anwendungsprofile, die erhöhte Anforderungen an eine Virtualisierungslösung stellen. Hierzu gehören Anwendungsszenarien wie Webserver, die das Memory-Management stark beanspruchen. Der erste Optimierungsweg setzt beim Anwendungsszenario an. Am Beispiel eines Webservers mit dynamischen Seiten lässt sich eindrucksvoll der Einfluss der Realisierung der dynamischen Inhalte auf die Performance aufzeigen. Dynamische Inhalte sind häufig als CGI-Programme (bzw. Skripte) realisiert. Diese CGI-Programme erzeugen bei jedem Aufruf einen neuen Prozess, was für den Hypervisor recht aufwändig ist. Alternativ können dynamische Inhalte durch den Einsatz von PHP, ASP oder ähnlichen Methoden realisiert werden, die keinen Overhead durch neu erzeugte Prozesse bewirken. Dies lässt sich in vservcon simulieren, indem im Lastprofil der Webserver- der Anteil der HTTP-Requests, die solche CGI- Programme starten, variiert wird. Die Auswirkungen auf die Performance verdeutlicht das Diagramm unten für einen unmodifizierten Linux-Kernel in der. Die beiden verglichenen Lastprofile sind: Lastprofile für Webserver STD-CGI MIN-CGI Definiert, dass 16% aller HTTP-Requests und 2% aller HTTP-SSL-Requests auf dem Webserver ein CGI-Programm starten. Beansprucht eine Virtualisierungslösung stark. STD-CGI-Profil ohne die 16% CGI-HTTP-Requests. Durch diese Verringerung der Zahl der CGI-Prozesse wird ein Webserver entlastet; sehr viel mehr noch aber reduziert dies den Aufwand innerhalb der Virtualisierungslösung. Durch beide Effekte zusammen wird soviel zusätzliche CPU-Leistung verfügbar, dass sich die Web-Transaktionsrate für s deutlich erhöht. Alle zuvor beschriebenen Messungen benutzen das STD-CGI-Profil als Standard. An dem Diagramm wird der Fortschritt der Prozessortechnologie im Bereich der Virtualisierung besonders gut deutlich. Es vergleicht eine PRIMERGY RX200 S5 (mit X5570) mit dem Vorgängersystem. Konnte eine Web- beim Vorgängersystem durch Optimierung des Anwendungsszenarios noch eine Performance-Verbesserung von 86% erzielen, so sind dies bei der aktuellen Prozessorgeneration nur noch 28%. Aufgrund der»extended Page Tables«(EPT) bewährt sich das System auch bei dem anspruchsvollen Lastprofil»STD-CGI«so gut, dass die Optimierungsreserve auf Seite des Anwendungsszenarios abschmilzt. Der Performance-Zuwachs beim Übergang von»std-cgi«nach»min-cgi«ähnelt schon dem Wert für ein nicht virtualisiertes System. Fazit für Optimierungen auf Seite des Anwendungsszenarios: Diese bleiben zwar interessant, aber der Nutzen ist in der gleichen Größenordnung wie bei einem nicht virtualisierten System. Fujitsu Technology Solutions Seite 36 (40)

37 White Paper Performance Report PRIMERGY RX200 S5 Version: 2.0a, März 2010 Der zweite Optimierungsweg setzt unterhalb der Anwendungsebene in der an. Prinzipiell möglich sind Performance-Steigerungen sowohl durch entsprechende Prozessorfunktionalitäten, als auch durch einen geeigneten Hypervisor oder auch durch ein speziell auf den Hypervisor angepasstes Betriebssystem oder Treiber in der. Eine so angepasste unterstützt den Hypervisor aktiv in seiner Arbeit, wodurch sich der Virtualisierungs-Overhead teilweise signifikant reduzieren lässt. Bei den Vorgängergenerationen der PRIMERGY Server brachte die Verwendung eines für die Virtualisierung angepassten Kernels für die Webserver- einen großen Performance-Gewinn. Das folgende Diagramm vergleicht eine PRIMERGY RX200 S5 (mit X5570) mit dem Vorgängersystem für zwei Kernel unter dem Lastprofil STD-CGI. Der eine Kernel ist der unmodifizierte LINUX- Kernel, und der andere ist der angepasste Kernel. Das Diagramm zeigt, dass mit einem aktuellen Prozessor der 5500 Serie die Qualität der Virtualisierungsunterstützung durch den Prozessor mittlerweile so exzellent ist, dass eine solche Kernel-Anpassung hier nicht mehr zu empfehlen ist. Beim Vorgängersystem mit einem X5460 Prozessor war hierdurch noch eine Leistungssteigerung von 65% möglich. Der unmodifizierte LINUX-Kernel (SMP) ist der Standard für die zuvor beschriebenen Messungen, sofern nichts anderes gesagt wurde. Die virtualisierungsrelevanten Fortschritte in der Prozessortechnologie gegenüber dem Vorgängersystem wirken zum einen auf eine einzelne (z. B. durch EPT), und zum anderen auf die maximal mögliche Anzahl von s bis zur CPU-Sättigung (durch Hyper-Threading). Die folgende Gegenüberstellung arbeitet die Anteile der beiden Arten von Verbesserungen heraus. Verglichen werden ein Vorgängersystem mit 2 E5420 (2.5 GHz) und eine PRIMERGY RX200 S5 mit 2 E5540 (2.53 GHz), beide mit gleicher Anzahl von physikalischen Cores. Man sieht also insgesamt eine Steigerung des vservcon-scores um den Faktor Die eine Ursache dafür ist die für eine einzelne realisierbare Performance-Steigerung um den Faktor 1.32 (siehe Score bei einer Tile). Die andere Ursache liegt darin, dass mehr Tiles möglich sind. Allerdings ist dies keine vollwertige Verdreifachung (von zwei Tiles auf sechs Tiles), da bei höheren Tile-Anzahlen der Performance-Zuwachs abflacht. Es sei daher noch einmal ausdrücklich davor gewarnt, die durch den Score ausgedrückte gesteigerte Virtualisierungs-Performance komplett als Verbesserung für eine einzelne zu erhoffen. Mehr als etwa 30% - 50% mehr Durchsatz gegenüber einem gleich getakteten Prozessor der Vorgängergeneration ist hier nicht möglich. Fujitsu Technology Solutions Seite 37 (40)