Diplomarbeit. Performanceanalyse von Virtualisierungssystemen für den Einsatz in Hochverfügbarkeitsumgebungen in mittelständischen Unternehmen

Transkript

1 Diplomarbeit Performanceanalyse von Virtualisierungssystemen für den Einsatz in Hochverfügbarkeitsumgebungen in mittelständischen Unternehmen Vorgelegt am: 28. August 2009 Von: Sebastian Röhner Dorotheenstraße Chemnitz Studienbereich: Studienrichtung: Seminargruppe: Technik Informationstechnik IT06/2 Matrikelnummer: Praxispartner: ibes Systemhaus GmbH Bergstraße Chemnitz Tel.: Gutachter: Prof. Dr. Reinhardt Nindel (ibes Systemhaus GmbH) Dipl.-Inf. (TU) Falk Puschmann (Staatliche Studienakademie Glauchau)

2 Inhaltsverzeichnis Abbildungsverzeichnis... V Tabellenverzeichnis... VI Abkürzungsverzeichnis... VII 1 Thematische Einordnung Virtualisierung im Unternehmen Historie, Marktanteile und Wachstumsprognosen Gründe und Ziele der Virtualisierung im Unternehmen Grundlagen der Virtualisierung Virtualisierungsformen und Arten der Servervirtualisierung Virtualisierungstechnologien Pacifica und Vanderpool Extended Page Tables und Rapid Virtualization Indexing RAW-Device Mapping Möglichkeiten der Storage-Anbindung FC-SAN iscsi-san Speichervirtualisierung in einem Disksubsystem Virtualisierungslösungen VMware ESX 3.5 und ESXi Architektur von ESX Möglichkeiten der Hochverfügbarkeit Neuerungen in VMware ESX 4.0 und ESXi Microsoft Hyper-V Architektur von Hyper-V Neuerungen in Hyper-V Möglichkeiten der Hochverfügbarkeit Citrix XenServer Architektur von Citrix XenServer Möglichkeiten der Hochverfügbarkeit Virtual Iron II

3 3.4.1 Architektur von Virtual Iron Möglichkeiten der Hochverfügbarkeit Entwicklung eines Testszenarios Physikalische Testumgebung Rahmenbedingungen Virtualisierungslösungen, Serverbetriebssysteme und Anwendungen Verwendete Benchmarktools Benchmarks für Virtualisierungssysteme Iometer TPC-H Auswertung Performanceauswertung von NCQ Performanceunterschiede zwischen RAID 6 und RAID Performanceauswertung von Iometer Aufgetretene Fehler bzw. Entscheidungen bei Performancemessungen Vergleich zwischen FC-SAN und iscsi-san im nativen Bereich Performanceauswertung von Microsoft Hyper-V Performanceauswertung von VMware ESXi Performanceauswertung von Virtual Iron Performanceauswertung von Citrix XenServer Gegenüberstellung der Virtualisierungslösungen im FC-SAN Gegenüberstellung der Virtualisierungslösungen im iscsi-san Auswertung der CPU-Effektivität Performanceauswertung von TPC-H Preis-/Leistungsverhältnis der Virtualisierungslösungen Fazit Literaturverzeichnis... IX Anhang A1 Anhang A2 Anhang A3 Berechnung der Parity bei RAID 5... XII Spezifikationen der verwendeten Hardwarekomponenten... XIII Beschreibung der Anfrageoperationen des TPC-H Benchmarks... XVI III

4 Anhang A4 Anhang A5 Anhang A6 Anhang A7 Anhang A8 Anhang A9 Anhang A10 Anhang A11 Anhang A12 Anhang A13 Anhang A14 Anhang A15 Anhang A16 Anhang A17 Anhang A18 Anhang A19 Anhang A20 Anhang A21 Anhang A22 Anhang A23 Anhang A24 Anhang A25 Iometer: FC-SAN Windows Server 2003 nativ...xx Iometer: iscsi-san Windows Server 2003 nativ...xxi Iometer: FC-SAN Windows Server 2008 nativ... XXII Iometer: iscsi-san Windows Server 2008 nativ... XXIII Iometer: FC-SAN Hyper-V 1.0 Windows Server XXIV Iometer: iscsi-san Hyper-V 1.0 Windows Server XXV Iometer: FC-SAN Hyper-V 1.0 Windows Server XXVI Iometer: iscsi-san Hyper-V 1.0 Windows Server XXVII Iometer: FC-SAN ESXi 4.0 Windows Server XXVIII Iometer: iscsi-san ESXi 4.0 Windows Server XXIX Iometer: FC-SAN ESXi 4.0 Windows Server XXX Iometer: iscsi-san ESXi 4.0 Windows Server XXXI Iometer: FC-SAN Virtual Iron 4.5 Windows Server XXXII Iometer: iscsi-san Virtual Iron 4.5 Windows Server XXXIII Iometer: FC-SAN XenServer 5.5 Windows Server XXXIV Iometer: FC-SAN XenServer 5.5 Windows Server XXXV Iometer: iscsi-san XenServer 5.5 Windows Server XXXVI TPC-H Messwerte... XXXVII Gegenüberstellung der Virtualisierungslösungen im FC-SAN... XXXIX Gegenüberstellung der Virtualisierungslösungen im iscsi-san... XL TPC-H - Performanceunterschiede in % auf Basis des nativen Systems... XLI Lizenzkosten für VMware vsphere 4.0 und Microsoft Hyper-V XLII Ehrenwörtliche Erklärung... XLIII IV

5 Abbildungsverzeichnis Abbildung 1: Marktanteil von Virtualisierungsanbietern im Jahr Abbildung 2: Marktanteil von Virtualisierungsanbietern im Jahr Abbildung 3: Virtualisierung in deutschen Unternehmen (Juni 2008)... 4 Abbildung 4: Hardwarevirtualisierung... 6 Abbildung 5: Bare Metal-Virtualisierung... 7 Abbildung 6: Hosted-Virtualisierung... 7 Abbildung 7: Betriebssystemvirtualisierung... 8 Abbildung 8: RAW-Device Mapping am Beispiel von VMware ESX Abbildung 9: iscsi-layer Modell Abbildung 10: Merfachkapselung der SCSI-Daten Abbildung 11: Entlastung der CPU durch TOE und iscsi-hbas Abbildung 12: Architektur von VMware ESX Abbildung 13: Kommunikationsschnittstellen von ESX / ESXi Server Abbildung 14: Aufbau einer VMware Infrastructure Abbildung 15: Monolithischer und Microkernel-Hypervisor Abbildung 16: Grobe Architektur von Hyper-V Abbildung 17: LiveMigration in Hyper-V Abbildung 18: Architektur des Xen Hypervisor Abbildung 19: dediziertes Managementnetzwerk bei Virtual Iron Abbildung 20: grobe Architektur von Virtual Iron Abbildung 21: physikalische Testumgebung Abbildung 22: Datenbankschema des TPC-H Benchmarks Abbildung 23: Datendurchsatz mit und ohne NCQ (sequentielles Schreiben) Abbildung 24: IOps mit und ohne NCQ (random, 65% Leseanteil) Abbildung 25: Datendurchsatz mit und ohne NCQ (random, 65% Leseanteil) Abbildung 26: Vergleich RAID 6 und RAID 10 (sequentielles Lesen) Abbildung 27: Vergleich RAID 6 und RAID 10 (sequentielles Schreiben) Abbildung 28: Vergleich RAID 6 und RAID 10 (random, 65% Leseanteil) Abbildung 29: Datendurchsatz im FC-SAN und iscsi-san (sequentielles Lesen) Abbildung 30: Datendurchsatz im FC-SAN und iscsi-san (sequentielles Schreiben) Abbildung 31: Datendurchsatz im FC-SAN und iscsi-san (random, 65% Leseanteil) Abbildung 32: CPU-Belastung zwischen FC und iscsi (sequentielles Lesen) Abbildung 33: CPU-Belastung zwischen FC und iscsi (sequentielles Schreiben) V

6 Abbildung 34: CPU-Belastung zwischen FC und iscsi (random, 65% Leseanteil) Abbildung 35: Datendurchsatz in Hyper-V 1.0 (sequentielles Lesen) Abbildung 36: Datendurchsatz in Hyper-V 1.0 (sequentielles Schreiben) Abbildung 37: Datendurchsatz in Hyper-V 1.0 (random, 65% Leseanteil) Abbildung 38: Datendurchsatz in ESXi 4.0 (sequentielles Lesen) Abbildung 39: Datendurchsatz in ESXi 4.0 (sequentielles Schreiben) Abbildung 40: Datendurchsatz in ESXi 4.0 (random, 65% Leseanteil) Abbildung 41: Datendurchsatz in Virtual Iron 4.5 (sequentielles Lesen) Abbildung 42: Datendurchsatz in Virtual Iron 4.5 (sequentielles Schreiben) Abbildung 43: Datendurchsatz in Virtual Iron 4.5 (random, 65% Leseanteil) Abbildung 44: Datendurchsatz in Citrix XenServer 5.5 (sequentielles Schreiben) Abbildung 45: Datendurchsatz in Citrix XenServer 5.5 (random, 65% Leseanteil) Abbildung 46: Vergleich - Virtualisierungslösungen im FC-SAN (sequentielles Lesen) Abbildung 47: Vergleich - Virtualisierungslösungen im FC-SAN (sequentielles Schreiben) Abbildung 48: Vergleich - Virtualisierungslösungen im FC-SAN (random, 65% Leseanteil) Abbildung 49: Vergleich - Virtualisierungslösungen im iscsi-san (sequentielles Lesen) Abbildung 50: Vergleich - Virtualisierungslösungen im iscsi-san (sequentielles Schreiben). 73 Abbildung 51: Vergleich - Virtualisierungslösungen im iscsi-san (random, 65% Leseanteil). 73 Abbildung 52: Vergleich der CPU-Effektivität (sequentielles Lesen) Abbildung 53: Vergleich der CPU-Effektivität (sequentielles Schreiben) Abbildung 54: Vergleich der CPU-Effektivität (random, 65% Leseanteil) Abbildung 55: QphH-Messwerte Abbildung 56: QppH-Messwerte Abbildung 57: QthH-Messwerte Tabellenverzeichnis Tabelle 1: Kapazitätsberechnung bei RAID 5 und RAID Tabelle 2: Zusammenfassung der RAID-Level 1, 5, 6 und Tabelle 3: Zugriffsmuster von Anwendungen Tabelle 4: Lastprofile für Iometer Tabelle 5: anfallende Lizenzkosten im Vergleich VI

7 Abkürzungsverzeichnis AD AMD AMD-V ARP CIM CLI CSV DHCP DNS DPM DRS EPT ERD FC FT HA HBA IDC IETF Intel Intel VT IP iscsi LUN MAC NCQ NIC NPIV NX OLTP OSDL Active Directory Advanced Micro Devices AMD Virtualization Address Resolution Protocol Common Information Model Command Line Interface Cluster Shared Volumes Dynamic Host Configuration Protocol Domain Naming System Distributed Power Management Distributed Resource Scheduler Extended Page Tables Entity-Relationship-Diagram Fibre Channel Fault Tolerance High Availability Host Bus Adapter International Data Corporation Internet Engineering Task Force Integrated Electronics Intel Virtualization Technology Internet Protocol Internet Small Computer System Interface Logical Unit Number Media Access Control Native Command Queuing Network Interface Card N-Port-ID-Virtualisierung No Execute Online Transaction Processing Open Source Development Lab VII

8 RAID RDM RVI SAN SCSI SDK SF SPEC SSE TCP TDP TOE TPC VHD VI VMDK VMFS VMM VMQ VSC VSP XD Redundant Array of Independent Disks RAW-Device Mapping Rapid Virtualization Indexing Storage Area Network Small Computer System Interface Software Development Kit Scale Faktor Standard Performance Evaluation Corporation Streaming Single Instruction Multiple Data Extension Transmission Control Protocol Thermal Design Power TCP/IP Offload Engine Transaction Processing Performance Council Virtual Hard Disk Virtual Infrastructure Virtual Machine Disk Format Virtual Machine File System Virtual Machine Monitor Virtual Machine Queue Virtualization Service Consumer Virtualization Service Provider Execute Disable VIII

9 1 Thematische Einordnung Der im Jahr 2002 beginnende Boom der Virtualisierungslösungen hat sich zu einer nicht mehr wegzudenkenden Technologie in großen Rechenzentren entwickelt. In den letzten Jahren verbreitete sich die Technologie in großen bis mittelständischen Betrieben, oder es wird geplant, in sehr naher Zukunft in diese zu investieren. Viele Kunden, aber auch unabhängige Anbieter wie Systemhäuser, können die Produkte bisher nur über ihr Funktionsspektrum auswählen. Andere Kunden entscheiden sich meist für den aktuellen Marktführer oder haben sich vor Beratungen bereits entschieden. Fundierte und praktische Messungen zwischen den unterschiedlichen Technologien, die eine Auswahl erheblich vereinfachen könnten, existieren nicht. Gegenstand der vorliegenden Diplomarbeit soll es sein, sich mit dem Virtualisierungsthema theoretisch und praktisch auseinander zu setzen. Ein Bereich wird sich mit dem Thema der Hochverfügbarkeit von virtuellen Maschinen befassen, ein anderer mit den Leistungsunterschieden zwischen den Virtualisierungslösungen selbst. Dabei werden die Leitungsunterschiede der Systeme jeweils in einer FC-SAN und iscsi-san Umgebung getestet. Die dabei zur Anwendung kommenden virtuellen Maschinen basieren auf Microsoft Windows Server 2003 und Windows Server 2008, jeweils in einer 32-bit und 64-bit Ausführung, um auch dahingehend die Leistungsunterschiede aufzuzeigen. Das Ergebnis der Arbeit wird eine Reihe von Messergebnissen sein, mit der man den Kunden bei bevorstehenden Virtualisierungsprojekten besser darüber beraten kann, welche Technologie für seinen Anwendungsfall die für Ihn geeignetste ist. Der Anbieter erhöht damit auch seinen Stellenwert beim Kunden, dass er nicht nur mit Marketing-Aussagen den Kunden von einem Produkt überzeugen will, sondern mit fundierten Zahlen argumentieren kann. 1

10 2 Virtualisierung im Unternehmen 2.1 Historie, Marktanteile und Wachstumsprognosen Die Firma VMware Inc. ist Wegbereiter in dem Bereich Virtualisierung und demonstrierte 1999 die Machbarkeit der x86-basierten Virtualisierung auf Intel-Architekturen. Ab dem Jahre 2002 setzte in großen Rechenzentren die Serverkonsolidierung ein und verhalf vor allem der Firma VMware Inc., zu einem der Marktführer im Bereich der Virtualisierung zu werden. Bis heute hat sich auf dem Markt viel getan, und immer mehr Anbieter wollen an dem stetig wachsenden Potenzial der Technologie beteiligt sein. Entsprechend einer Erhebung des Marktforschungsinstituts IDC (International Data Corporation) soll der Markt für Virtualisierung in den nächsten Jahren durchschnittlich um 25% zulegen 1. Ein Grund für das starke Wachstum resultiert vor allem daraus, dass Virtualisierung zukünftig nicht nur Entwicklungs- oder Testumgebungen bereitstellen soll, auch etablierte Kernapplikationen stehen in kleinen und mittelständischen Betrieben zur Disposition. Die folgenden beiden Abbildungen 1 und 2 zeigen die Marktanteile der führenden Anbieter für Virtualisierungslösungen. Marktanteile 2006 (Quelle: IDC) Xen 5% Andere 5% Microsoft Virtual Server 21% VMware ESX Server 43% VMware Server 26% 2 Abbildung 1: Marktanteil von Virtualisierungsanbietern im Jahr [RUN09], S [RUN09], S

11 Eine Erhebung im Juni 2008 veränderte das Bild der Marktanteile deutlich. Obwohl Microsoft seinen Virtual Server 2005 ab Mitte 2006 kostenlos zur Verfügung stellte, konnten die Marktanteile nicht gehalten werden. Die neue Virtualisierungslösung Hyper-V von Microsoft wird erst kommende Umfrageergebnisse beeinflussen können. Analysten von IDC rechnen damit, dass Microsoft seinen Marktanteil steigert und im Jahr 2010 bei 25% liegen könnte. Neben dem Virtualisierungsprodukt Xen werden zudem 12% andere Unix- und Mainframe- Technologien zur Virtualisierung verwendet. Marktanteile 2008 (Quelle: IDC) Xen 3% Other 12% Microsoft 12% VMware 73% 3 Abbildung 2: Marktanteil von Virtualisierungsanbietern im Jahr 2008 Die Abbildung 3 zeigt, welches Potenzial in der Virtualisierung liegt. In Deutschland sind nach Umfragen der IDC bisher nur 13% der Systeme virtualisiert. 50% der Befragten planen zudem, weitere Systeme zu kaufen, mit der Absicht, diese zu virtualisieren. Die derzeit anhaltende Wirtschaftskrise, die kurz nach der Erhebung der Zahlen ausbrach, hat neue Investitionen in Unternehmen fast vollständig gestoppt. Dabei wird es aber keine Abkehr von der Virtualisierung geben. Es kommt lediglich zu einer Verschiebung und späteren Investitionen, wenn die Wirtschaft Ende des Jahres 2009 bzw. Anfang nächsten Jahres wieder nach oben gehen wird. Gründe für die Virtualisierung werden in Kapitel 2.2 näher untersucht. 3 [HOR08], S. 1 3

12 70% Virtualisierung in deutschen Unternehmen (Quelle: IDC) 60% 50% 40% 30% 20% 10% Anteil virtualisierter Systeme im Unternehmen Anteil der gekauften Server in den letzten 12 Monaten, die virtualisiert wurden Anteil geplanter Serverkäufe mit Virtualisierungsabsicht in den nächsten 12 Monaten 0% Deutschland (Juni 2008) 4 Abbildung 3: Virtualisierung in deutschen Unternehmen (Juni 2008) 2.2 Gründe und Ziele der Virtualisierung im Unternehmen Die Virtualisierung wurde seit 2002 in großen Rechenzentren verstärkt eingesetzt. Folgende Gründe und die daraus abgeleiteten Ziele waren dafür maßgeblich. Gründe: Immer höhere geforderte Rechenleistung erforderte immer größere Stellfläche Hohe Wartungs- und Betriebskosten der wachsenden physischen Infrastruktur Unzureichende Nutzung vorhandener Ressourcen Ziele und Folgen durch Anwendung der Virtualisierung: Reduzierung der physischen Server und Verringerung der benötigten Stellfläche Höhere Effizienz durch bessere Ressourcenausnutzung, aber auch geringere Verlustleistung und somit geringere Kosten für Klimatisierungsmaßnahmen Geringe Wartungs- und Betriebskosten, bezogen auf die physische Infrastruktur Senkung der IT-Kosten 4 [HOR08], S. 1 4

13 Aus diesen Gründen und den zu erwarteten Vorteilen entscheiden sich auch zunehmend große und mittelständische Unternehmen dafür, ihre Rechenzentren mittels Virtualisierung zu optimieren. Durch die Verwendung von Virtualisierung stehen dem jeweiligen Unternehmen bzw. den IT-Verantwortlichen neue Möglichkeiten zur Verfügung, dazu zählen unter anderem: Höhere Flexibilität und kürzere Reaktionszeit bei der Bereitstellung neuer Systeme Höhere Verfügbarkeit der Systeme durch Hardwareunabhängigkeit Aufbau von virtuellen Testumgebungen, bevor eine Implementierung im produktiven System durchgeführt wird, dazu gehört auch der Test von Migrationen, Upgrades oder Updates von vorhanden Geschäftsanwendungen Reduzierung benötigter physischer Netzwerkkomponenten durch deren virtuelle Abbildung Neben den genannten Gründen, Zielen und neuen Möglichkeiten durch Virtualisierung sollten jedoch aufkommende Nachteile nicht außer Acht gelassen werden. Entstehende Performanceverschlechterungen gegenüber physischen Servern Zugrundeliegende Virtualisierungshardware muss redundant ausgelegt werden, weil sonst bei technischen Problemen die gesamte Infrastruktur lahmgelegt werden kann Höhere Anforderungen an die Administratoren, da kleine Änderungen an den Hardwareparametern, oder auch den Virtualisierungslösung selbst, mehrere Systeme beeinträchtigen können Alle diese Nachteile können jedoch durch genaue Konzeption, Planung, Analyse der zu vitalisierenden Systeme, Schulung der Administratoren und Verwendung von zentralisierten Managementlösungen für die virtuelle Infrastruktur weitestgehend behoben werden. 5

14 2.3 Grundlagen der Virtualisierung Virtualisierungsformen und Arten der Servervirtualisierung Wenn heute von Virtualisierung gesprochen wird, verbindet man dies automatisch mit dem Begriff der Servervirtualisierung. Obwohl der Schwerpunkt dieser Arbeit auf der Servervirtualisierung liegt, sollen die anderen Varianten dennoch genannt werden: Servervirtualisierung Desktopvirtualisierung Netzwerkvirtualisierung Storage-Virtualisierung Anwendungsvirtualisierung Die Servervirtualisierung selbst unterteilt sich dabei nochmals in 4 unterschiedliche Architekturen. Hardwarevirtualisierung Hypervisor-basierende Virtualisierung Hosted-Virtualisierung Bare Metal-Virtualisierung Paravirtualisierung Betriebssystemvirtualisierung Hardwarevirtualisierung: Bei der Hardwarevirtualisierung ist die Virtualisierungstechnologie Bestandteil der Hardware selbst und somit plattformspezifisch. Dabei wird jedem Gastsystem eine standardisierte, isolierte Hardwareumgebung bereitgestellt (siehe Abbildung 4). virtuelle Maschine 1 virtuelle Maschine 2 virtuelle Maschine n Partition Partition Partition Hardware Abbildung 4: Hardwarevirtualisierung 6

15 Hypervisor-basierende Virtualisierung: Viele auf dem Markt angebotenen Virtualisierungslösungen basieren auf dem Prinzip eines Hypervisor. Darunter zählen auch die Produkte VMware ESX/ESXi 4.0, Microsoft Hyper-V 1.0, Citrix XenServer 5.5 und Virtual Iron 4.5, die Hauptbestandteil dieser Diplomarbeit sind. Die Hypervisor-basierende Virtualisierung unterteilt sich in die Unterkategorien, Bare Metal- Virtualisierung und Hosted-Virtualisierung. Bei der Hosted-Virtualisierung benötigt die Virtualisierungsumgebung ein darunterliegendes Betriebssystem. Die grobe Architektur eines solchen Gesamtsystems ist in Abbildung 6 dargestellt. Bei der Bare Metal- Virtualisierung setzen die Virtualisierungslösungen direkt auf der darunterliegenden Hardware auf und benötigen kein darunterliegendes Betriebssystem, siehe Abbildung 5. Der Hypervisor besteht aus einem Virtual Machine Monitor (VMM) und aus einer gewissen Anzahl an Treibern und stellt den virtuellen Gastsystemen eine angepasste Architektur zur Verfügung. virtuelle Maschine 1 virtuelle Maschine n virtuelle Maschine 1 virtuelle Maschine n Hypervisor Hypervisor Hardware Host Betriebssystem Hardware Abbildung 5: Bare Metal-Virtualisierung Abbildung 6: Hosted-Virtualisierung Beide Methoden haben ihr Vor- und Nachteile. Da bei der Hosted-Virtualisierungslösung der Zugriff auf die Hardware über das Host Betriebssystem erfolgt, besteht eine größere Kompatibilität mit möglichen Hardwarekomponenten. Durch die zusätzliche Vermittlungsschicht ist diese Virtualisierungslösung langsamer. Dagegen unterstützt die Bare Metal-Virtualisierung nur bestimmte Hardwarekomponenten. 7

16 Paravirtualisierung: Die Paravirtualisierung gehört zu der Kategorie der Hypervisor-basierenden Virtualisierung. Bei der Paravirtualisierung wird der Kernel des Gastsystems so angepasst, dass dieser direkt mit der von der Virtualisierungsschicht und nicht mit der physikalischen Hardware kommuniziert. Auf diese Weise muss die physikalische Hardware nicht für jede einzelne virtuelle Maschine gesondert virtualisiert werden. Vielmehr greifen die Gastbetriebssysteme direkt auf eine angepasste Hardware zu. 5 Aus Lizenzgründen ist die Anpassung des Kernels nur bei Linux möglich. Durch Einführung von Virtualisierungstechnologien wie AMD-V oder Intel VT ist eine Anpassung des Kernels nicht mehr erforderlich. Mehr dazu im Kapitel Virtualisierungstechnologien Pacifica und Vanderpool. Betriebssystemvirtualisierung: Die Betriebssystemvirtualisierung baut auf einem Host-Betriebssystem und mehreren möglichen Child-Betriebssystemen auf (siehe Abbildung 7). Die Kernel der Child- Betriebssysteme sind so verändert, dass sie gemeinsam auf dem Kernel des Host- Betriebsystems laufen. Dadurch kann die Lösung auch nur das Host-Betriebssystem unterstützen. Der einzige Anbieter ist die Firma Parallels mit dem Produkt Virtuozzo. virtuelles Betriebssystem 1 virtuelles Betriebssystem 2 virtuelles Betriebssystem n Host Betriebssystem Hardware Abbildung 7: Betriebssystemvirtualisierung 5 [RUN09], S. 66 8

17 2.3.2 Virtualisierungstechnologien Pacifica und Vanderpool Die Serverprozessoren, die auf einer x86-architektur basieren, unterscheiden zwischen 4 Privilegierungsstufen. Die Unterteilung erfolgt dabei von Ring 0, dem mit der höchsten Privilegierungsstufe, bis hin zu Ring 3 mit der niedrigsten Privilegierungsstufe. Nur der Kernel eines Betriebssystems hat direkten Zugriff auf den Ring 0 und somit direkten Zugriff auf die Ressourcen des Servers. Die nachfolgenden Ringe 1 und 2 sind Gerätetreibern vorbehalten, werden aber von den meisten x86 Betriebssystemen nicht verwendet. Der Ring 3 mit der niedrigsten Privilegierungsstufe wird für die Zugriffe von Anwendungen genutzt. Da ein gleichzeitiger Zugriff mehrerer Betriebssysteme nicht möglich ist, bzw. eine Instabilität des gesamten Systems zur Folge hätte, hat bei der Hypervisor-basierenden Virtualisierung der Hypervisor alleinigen Zugriff auf den Kern 0. Die virtuellen Maschinen laufen somit in der Anwendungsebene auf Ring 3 und müssen bei dem Zugriff auf Ring 0 über den VMM gehen. Die Folge ist ein Performanceverlust gegenüber einem nativen System. Die beiden Prozessorhersteller AMD (Advanced Micro Devices) und Intel (Integrated Electronics) haben deshalb ihre CPUs um die Befehlssätze AMD-V (AMD Virtualization) bzw. Intel VT (Intel Virtualization Technology) erweitert. Hinter den Bezeichnungen verbergen sich die Virtualisierungstechnologien Pacifica (AMD) und Vanderpool (Intel). Mit den beiden Virtualisierungstechnologien ist es möglich, dass auch die Gast- Betriebssysteme auf den Kern 0 zugreifen können, ohne eine Instabilität des Host-Systems und somit aller virtuellen Maschinen zu gefährden. Nebeneffekt ist ein Performancegewinn gegenüber virtuellen Maschinen ohne die genannten Virtualisierungstechnologien, wenn Anwendungen auf den Kern 0 zugreifen. Neben der Unterstützung der CPU selbst, müssen auch die Virtualisierungsprodukte diese Technologien unterstützen. Eine weitere Prozessorfunktion, die für einige Virtualisierungslösungen benötigt wird, ist das NX-Bit (No Execute) bzw. XD-Bit (Execute Disable). Entwickelt wurde diese Technologie von AMD (NX-Bit) und wurde später von Intel übernommen (XD-Bit). Ziel dieser Implementierung ist es, vor der Ausführung von schadhaftem Code zu schützen, indem man nun zwischen Code und Daten unterscheidet. In den Speicherbereichen, in denen sich Daten befinden, können keine Codes mehr ausgeführt werden. 9

18 2.3.3 Extended Page Tables und Rapid Virtualization Indexing Ein viel größeres Problem stellt die Speicherverwaltung dar. Der Hypervisor nimmt hierbei eine Schlüsselrolle ein und sorgt für die Umsetzung von virtuellen in physikalische Speicheradressen und umgekehrt. Neue CPU-Architekturen von AMD und Intel bieten seit neuem eine Technologie, die auf den Namen Rapid Virtualization Indexing (RVI) bzw. Extended Page Tables (EPT) hört. Mittels EPT (Intel) übernimmt die CPU die Speicherverwaltung der virtuellen und physikalischen Speicheradressen. Die Lösung RVI von AMD sieht vor, dass die virtuellen Maschinen ihren eigenen Adressraum im physikalischen Speicherbereich erhalten und direkt darauf zugreifen. Das Ziel beider Technologien ist es, den Hypervisor bei der Speicherverwaltung zu entlasten und den Virtualisierungsoverhead gegenüber einem nativen System weiter zu verringern RAW-Device Mapping Die Methode RAW-Device Mapping (RDM) ermöglicht einer virtuellen Maschine den direkten Zugriff auf eine LUN (Logical Unit Number) im Storage-System. Als Vermittlung wird eine Zuordnungsdatei benötigt, die auf das entsprechende RAW-Device verweist. Im Gegensatz zu der herkömmlichen Variante, virtuelle Maschinen in einem Datastore als Datei(en) anzulegen, werden bei RAW-Devices die Daten direkt auf die LUN geschrieben. Wie RDM am Beispiel von VMware ESX Server 3.5 funktioniert, soll folgende Abbildung 8 verdeutlichen. 6 Abbildung 8: RAW-Device Mapping am Beispiel von VMware ESX [RUN09], S

19 2.4 Möglichkeiten der Storage-Anbindung FC-SAN Die derzeit am häufigsten eingesetzte Technik zur Realisierung von Speichernetzen ist Fibre Channel (FC). Eine weitere Möglichkeit bietet das Internet Small Computer System Interface (iscsi). Es wird im Kapitel iscsi-san näher betrachtet. Bei beiden Techniken handelt es sich um eine Übertragungstechnik, die den SCSI-Bus ersetzen. Die Kommunikation zwischen den beteiligten Systemen erfolgt weiterhin über das SCSI-Protokoll. Es gibt aber entscheidende Unterschiede in der Effizienz zwischen FC und iscsi. Die damaligen Entwurfsziele von FC entsprechen den Anforderungen, die für eine effektive Anbindung von Speichernetzen benötigt werden. Hierzu zählen die Überbrückung hoher Distanzen mit einer hohen Datenübertragungsrate, eine geringe Rate an Übertragungsfehlern, geringe Latenzzeiten sowie die Implementierung der Technik in entsprechende Host Bus Adapter (HBA) zur Entlastung der Server-Prozessoren. 7 Das FC-Protokoll ist durch die 5 Schichten FC-0 bis FC-4 definiert. FC-0 beschreibt die Übertragungsmedien, Stecker und Signale. Im Gegensatz zum SCSI-Bus werden bei FC die Daten seriell übertragen, um unterschiedliche Signallaufzeiten zu verhindern. Heute werden Übertragungsraten von 1 GBit/s, 2 GBit/s, 4 GBit/s und 8 GBits/s unterstützt. Bei der Pointto-Point Topologie und Fabric-Topologie erfolgt die Datenübertragung bidirektional und im Vollduplex-Betrieb, die maximale Datenrate steht somit für Sende und Empfangskanal zur Verfügung. Im FC-Standard ist weiterhin definiert, dass ein Bitfehler höchstens einmal pro übermittelten Bits auftreten darf. Die Schicht FC-1 ist für die Kodierung verantwortlich. Als Kodierungsverfahren wird die 8b/10b-Kodierung angewendet. Da durch die serielle Übertragung nur ein Übertragungskanal zur Verfügung steht, muss der Empfänger aus dem Datenstrom den entsprechenden Übertragungstakt ermitteln. Die Synchronisation des Taktes ist nur bei Signalwechseln von 0 auf 1 oder von 1 auf 0 möglich. 7 [TRO08], S.69 11

20 Bei der 8b/10b-Kodierung wird deshalb aus einem zu übertragenden Achtbit-Byte ein Zehnbit-Zeichen generiert. Dies ist so implementiert, dass garantiert nach 5 Bit ein Signalwechsel erfolgt. Die Schicht FC-2 definiert unter anderem die Flusskontrolle. Die Flusskontrolle im FC arbeitet mit Credits. Solange der Empfänger über einen freien Puffer und somit über freie buffer credits verfügt, kann der Sender weitere Daten übermitteln. Der Absender erhält hierzu Receive-Ready-Signale. Hierdurch kann ein nahezu kontinuierlicher Datenstrom erzeugt werden. Außerdem garantieren die Sequenzen, dass die Daten in der gleichen Reihenfolge ankommen, wie diese vom Absender abgeschickt wurden. Ein FC-Paket kann bis zu 2112 Byte Nutzdaten übertragen, hinzu kommen der Start-of-Frame und End-of-Frame Delimiter von je 4 Byte, der Frameheader von 24 Byte und die CRC- Prüfsumme von 4 Byte. Das Verhältnis von Nutzdaten zu Protokolloverhead liegt bei 98%. In den heutigen Produkten ist die Schicht 3 ungenutzt. In der Schicht 4 ist definiert, wie höhere Protokolle auf FC abzubilden sind. Die bei einer Fabric zum Einsatz kommenden Switche arbeiten im Cut-Through Modus. Hierbei kommt es nur zur Auswertung der Zieladresse, um das Paket weiterleiten zu können. Eine Fehlerüberprüfung findet durch die geringe Bitfehlerwahrscheinlichkeit nicht statt. Durch dieses Verfahren kann die Latenzzeit verringert werden. Zur Adressierung der FC- Geräte werden World Wide Port Names (WWPN) bzw. World Wide Node Names (WWNN) verwendet. Ein FC-HBA verfügt somit über einen WWNN und kann, je nach Anzahl der Ports über mehrere WWPNs verfügen. Mittels Zoning ist es zudem möglich, Geräte in Gruppen zusammenzufassen, die sich im FC- SAN gegenseitig sehen sollen. Eine Überlappung der Zonen ist hierbei möglich. Zusammenfassend kann festgehalten werden, dass sich FC nicht ohne Grund für die Realisierung von Speichernetzen durchgesetzt hat. 12

21 2.4.2 iscsi-san Der iscsi-standard wurde von der Internet Engineering Task Force (IETF) im Jahr 2003 ratifiziert. Hierbei handelt es sich um ein Übertragungsprotokoll, bei dem SCSI-Daten in TCP/IP-Pakete verpackt und über IP-fähige Netze transportiert werden. Die Kommunikation zwischen den beteiligten Quell- und Zielsystemen wird über iscsi-initiatoren und iscsi- Targets realisiert. Bei einem iscsi-target handelt es sich in der Regel um ein System, welches als zentralisiertes Storage fungiert. Dabei kann es sich um einen Server oder um ein Festplatten-Array mit iscsi-funktionalität handeln. Die Systeme mit iscsi-initiatoren greifen auf die vom iscsi-target bereitgestellten LUNs zu. Die iscsi-initiatoren und iscsi-targets können sowohl software- als auch hardwaremäßig realisiert werden. Bei der Ausnutzung herkömmlicher Netzwerkkarten werden zusätzliche Software iscsi-initiatoren bzw. iscsi-targets benötigt. Zur Paketierung wird hierbei ausschließlich die Server-CPU beansprucht. Eine Faustregel für die Paketierung besagt, dass für ein Bit ein Hz benötigt wird. Im Umkehrschluss bedeutet dies, dass für eine 1 GBit- Verbindung, eine CPU-Last von 1 GHz erzeugt wird, spätere Benchmarkmessungen werden diese Behauptung untersuchen. Die hohe CPU-Last wird durch den TCP/IP-Datenverkehr selbst und die Mehrfacheinkapselung der SCSI-Daten erzeugt. In Abbildung 9 ist das iscsi-layer Modell dargestellt. Hierbei ist zu erkennen, welche Protokollschichten durchlaufen werden, um SCSI-Daten von einem iscsi-target zu einem iscsi-initiator zu übertragen bzw. umgekehrt. Abbildung 9: iscsi-layer Modell 13

22 Da ein SCSI-Datenpaket standardmäßig eine Größe von 512 Byte besitzt, können mit einem iscsi-paket nur 2 SCSI-Datenpakete übertragen werden. Grund für die Limitierung ist das Ethernet-Paket, welches eine Nutzlast von 1500 Byte übertragen kann. Weiterhin muss die Einkapselung der anderen Protokoll-Header mit beachten werden (siehe Abbildung 10). Abbildung 10: Merfachkapselung der SCSI-Daten Ein FC-Paket kann hingegen 4 SCSI-Datenpakete aufnehmen. Das Verhältnis von Nutzdaten zu Protokolloverhead beträgt bei iscsi 90%. Um dem Problem der hohen CPU-Entlastung entgegen zu wirken, gibt es spezielle Netzwerkarten. Bei Netzwerkadapter mit der Funktion TCP/IP Offload Engine (TOE) wird der TCP/IP-Protokollturm auf dem Netzwerkadapter abgewickelt und somit die Server-CPU entlastet. Spezielle iscsi-hbas erweitern die Funktion TOE und realisieren das iscsi-protokoll ebenfalls hardwaremäßig (siehe Abbildung 11). Die tatsächliche Entlastung der CPU konnte während der praktischen Messungen nicht überprüft werden, da Netzwerkkarten mit TOE bzw. spezielle iscsi-hbas nicht zur Verfügung standen. Abbildung 11: Entlastung der CPU durch TOE und iscsi-hbas Ein weiteres Problem bei IP Storages sind höhere Latenzzeiten. Diese können durch die Sortierung der Datenpakete, das Verwerfen von Datenpaketen und durch Switching- Mechanismen wie Store-and-Forward hervorgerufen werden. Inwieweit iscsi schlechter ist als FC, werden die geplanten Messungen im Bereich der Virtualisierungslösungen zeigen. 14

23 2.4.3 Speichervirtualisierung in einem Disksubsystem Die zentrale Speichereinheit eines FC-SAN oder iscsi-san ist ein zentrales Storage bzw. Disksubsystem. Die Verbindung zwischen den Servern und den Ports des Disksubsystems wird über die entsprechende IO-Technik realisiert. Zwischen den Anschlussports des Disksubsystems und den verbauten physikalischen Festplatten befindet sich ein zusätzlicher RAID-Controller mit Lese- und Schreibcache. Durch die Anwendung von RAID-Verfahren können die Verfügbarkeit durch Redundanz und die Performance durch Striping der bereitgestellten virtuellen Festplatten erhöht werden. Bei diesem Verfahren spricht man von Speichervirtualisierung mittels RAID. Hierbei werden den physikalischen Servern virtuelle Festplatten, sogenannte LUNs, zur Verfügung gestellt. Die darunterliegende Architektur der verwendeten physikalischen Festplatten und angewendeten RAID-Verfahren bleibt dem Server verborgen. Mittels RDM können die LUNs auch direkt dem virtuellen Server zugewiesen werden. Um eine Ausfallsicherheit in einem zentralen Storage zu gewährleisten, müssen RAID-Level ausgewählt werden, die Daten redundant speichern. Hierzu zählen die in der Praxis am häufigsten angewendeten RAID-Level 1, 5, 6 und 10. RAID 1: Bei einem RAID 1 werden zwei physikalische Festplatten zu einer virtuellen Festplatte zusammengefasst. Werden Datenblöcke auf die virtuelle Festplatte geschrieben, so schreibt der RAID-Controller die Daten blockweise auf beide physikalischen Platten. Deshalb spricht man bei einem RAID 1 auch von einem Spiegelsatz, es liegen also zwei exakte Kopien der Daten vor. Somit ist der Ausfall einer Platte tolerierbar. Der Kapazitätsoverhead beträgt 50%, der theoretisch maximale Schreibdurchsatz liegt bei einer Festplatte. Theoretisch ist der maximale Lesedurchsatz doppelt so hoch wie von einer Festplatte, wird jedoch von den RAID-Controllern praktisch nicht unterstützt. Aufgrund des geringen Schreib- und Lesedurchsatzes und dem hohen Kapazitätsoverhead ist RAID 1 für ein Storage im Hinblick auf die spätere Servervirtualisierung eher ungeeignet. 15

24 RAID 5 und 6: Bei RAID 5 und 6 werden die Datenblöcke über n-1 bzw. n-2 Festplatten gestriped. Der RAID- Controller errechnet für die gestripten Blöcke einen Paritätsblock, bei RAID 6 zwei Paritätsblöcke, und legt diese auf einer bzw. auf zwei unterschiedlichen Festplatten ab. Im Gegensatz zu RAID 4, werden bei RAID 5 und 6 die Parity-Blöcke auf die physikalischen Festplatten verteilt geschrieben. Die Vorteile von RAID 5 und 6 sind gegenüber RAID 1, bei entsprechend vielen n Platten, ein geringer Kapazitätsoverhead (siehe Tabelle 1). Tabelle 1: Kapazitätsberechnung bei RAID 5 und RAID 6 RAID 5 Kapazitätsoverhead in % Verfügbare Kapazität RAID 6 Da die Daten gestripet sind, erreicht RAID 5 einen theoretischen Lesedurchsatz von n-1, RAID 6 von n-2 Platten. Der Nachteil von RAID 5 und 6 ist das Write Penalty. Hierbei handelt es sich um den Mehraufwand, der bei Schreiboperationen durchgeführt werden muss. Jede Schreiboperation zieht weitere 5 Operationen nach sich. Am Beispiel von 4 physikalischen Festplatten wird der erste Parityblock folgendermaßen berechnet: Bei allen weiteren Schreiboperationen wird zur Berechnung der neuen Parity nur der geänderte Block benötigt, ein Berechnungsbeispiel ist hierfür in Anhang A1 erklärt. Daher sollten RAID-Arrays vorher initialisiert werden, sonst findet die komplexere Paritätsberechnung beim Schreiben der ersten Blöcke statt. Die ausgeführten Operationen bei einer Änderungsoperation von Block C sollen anhand eines Beispiels verdeutlicht werden: 1. Auslesen des alten Blockinhalts C 2. Auslesen des alten Paritywertes 3. Berechnung der neuen Parity (siehe Anhang A1) 4. Schreiben des neuen Blockinhalts 5. Schreiben des neuen Paritywertes 16

25 Die praktische Realisierung zur Paritätsberechnung unterscheidet sich im Vergleich zur Theorie. Nach Rücksprache mit Adaptec und bereits bekannten Erkenntnissen bei Proware wird die Parity durch erneutes Auslesen aller beteiligten Blöcke berechnet. RAID 10: Bei RAID 10 handelt es sich um eine Kombination aus RAID 1 und RAID 0 und somit um ein zweistufiges System. Es werden mindestens 4 Platten benötigt, um ein RAID 10 zu erzeugen. In der ersten Stufe werden aus jeweils 2 physikalischen Platten ein RAID 1 gebildet. Aus den n virtuellen RAID 1 Festplatten wird in der zweiten Stufe ein RAID 0 erstellt. Ergebnis dieser Kombination ist ein theoretischer Lese- und Schreibdurchsatz von n/2. Der Kapazitätsoverhead liegt wie bei RAID 1 bei 50%. Die zweite Stufe kann hierbei von dem RAID-Controller oder im Betriebssystem realisiert werden. Bei RAID 10 wird der Ausfall einer Festplatte toleriert. Es können mehr Platten ausfallen, aber nur eine Platte pro Spiegel. Zusammenfassung der RAID-Verfahren: Tabelle 2: Zusammenfassung der RAID-Level 1, 5, 6 und 10 RAID 1 RAID 5 RAID 6 RAID 10 Anzahl der Laufwerke N = 2 N 3 N 4 N 4 Tolerierter Plattenausfall *; (n/2)** Kapazitätsoverhead in % / n 200 / n 50 Parallele Leseoperationen 1; (2)*** n-1 n-2 n / 2 Parallele Schreiboperationen 1 n / 2 n / 3 n / 2 Geeignet für: Betriebssysteme Datenbanken Fileserver Backup * Worst Case Szenario; ** pro Spiegel eine Platte; *** theoretisch 2, praktisch 1 Fileserver Backup Datenbanken 17

26 Im Kapitel 4 und 5 wird auf die Auswirkung von Cachemechanismen in RAID-Controllern und Optimierung bei Festplattenzugriffen eingegangen. Die folgenden Beschreibungen sollen als theoretische Grundlage für die späteren praktischen Auswertungen dienen. Cache-Mechanismen Write Back und Write Through: Die meisten RAID-Controller besitzen zusätzliche Pufferspeicher für Lese- und Schreibzugriffe. Bei Write Back erhält das Betriebssystem vom RAID-Controller einen Bestätigungsbefehl, wenn die zu schreibenden Datenblöcke im Cache des RAID-Controllers vorhanden sind. Ein Schreibvorgang auf die physikalischen Festplatten ist hierbei noch nicht erfolgt. Die Methode Write Back hat den Nachteil, dass bei Problemen mit der Stromversorgung Daten im Cache unwiderruflich verloren gehen können. Write Back sollte nur aktiviert werden, wenn das System über eine USV bzw. der RAID-Controller Cache über eine Pufferbatterie abgesichert ist. Dagegen erhält das Betriebssystem beim Cachemechanismus Write Through den Bestätigungsbefehl erst, wenn die Daten auf die Festplatte geschrieben wurden. NCQ (Native Command Queuing): Die Methode NCQ wurde in erster Linie entwickelt, um den Datendurchsatz und die Transaktionszeiten zu senken. Hierbei werden mehrere Anfragen an die Festplatte geschickt, die anschließend selbst entscheidet, welche Anfragen zuerst abgearbeitet werden. Ziel ist es, die Antworten mit so wenig wie möglichen Kopfbewegungen bzw. Umdrehungen pro Platter(n) zu liefern. Die Methode NCQ hat ihre Vor- und Nachteile. Bei zufälligem Datenzugriff können der Datendurchsatz gesteigert und die Transaktionszeiten gesenkt werden. Bei sequentiellen Zugriffen verhält es sich genau umgekehrt, der Datendurchsatz sinkt und die Transaktionszeiten steigen. Im Kapitel 5.1 Performanceauswertung von NCQ sind hierzu Messungen durchgeführt wurden, die die hier beschriebene Theorie überprüfen und Empfehlungen für den praktischen Einsatz liefern. 18

27 3 Virtualisierungslösungen 3.1 VMware ESX 3.5 und ESXi Architektur von ESX 3.5 Die Firma VMware Inc. ist der Wegbereiter in der Virtualisierung auf x86-basierenden Prozessoren und hat in den letzen Jahren ein enormes Portfolio an Virtualisierungsprodukten und unterstützenden Anwendungen aufgebaut. Für den professionellen Einsatzzweck im Unternehmen eignen sich jedoch nur zwei Virtualisierungsplattformen. Dazu zählt der VMware ESX/ESXi Server 3.5. In Verbindung mit dem Managementwerkzeug VMware VirtualCenter Server, dem Virtual Infrastructure Client (VI Client) und dem VMware Lizenz Server bilden diese Komponenten zusammen das Produkt VMware Virtual Infrastructure 3. Diese Produkte müssen kombiniert werden, da nur dadurch weitere Funktionen wie Hochverfügbarkeit, VMotion oder Lastenausgleich über einen ESX-Cluster möglich sind. Der eigentliche Unterschied zwischen den VMware Server Varianten ESX und ESXi liegt in der Abhärtung der Virtualisierungsplattform. Dies lässt sich am Aufbau des VMKernel erklären, der die eigentliche Hypervisor-Funktionalität bereitstellt. In Abbildung 12 ist die Architektur eines VMware ESX Servers 3.5 dargestellt. 8 Abbildung 12: Architektur von VMware ESX [RUN09], S

28 Im Gegensatz zum ESX Server, verzichtet der ESXi Server auf die Service-Konsole. Diese benötigte in letzter Zeit immer wieder Sicherheitsupdates und verbraucht zusätzlichen Festplattenspeicher. Daher spricht man bei einem ESXi Server von einer schlankeren und gehärteten Virtualisierungsplattform. ESXi Server 3.5 wird von Serverherstellern zudem als Embedded Version vom Werk angeboten. Der VMKernel befindet sich dabei auf einem integrierten Flashspeicher und kann ohne weitere Installation in eine bestehende Virtualisierungsumgebung integriert werden. Der ESXi Server ist jedoch auch als installierbare Version erhältlich. Zu den vier Hauptkomponenten des VMKernel zählen der Resource Manager, Hardware Interface Layer (HIL), Virtual Machine Monitor (VMM) und der Scheduler. Der Resource Manager ist für die Verteilung der physischen Hardwareressourcen an die virtuellen Maschinen verantwortlich. Der HIL kommuniziert direkt mit der darunterliegenden Hardware und bildet eine Abstraktionsschicht, um Hardwareunterschiede vor den virtuellen Maschinen zu verbergen. Weiterhin enthält er die fest implementierten Gerätetreiber und verwaltet die Netzwerk- und Speicherzugriffe der einzelnen virtuellen Maschinen. Der VMM ist für die Virtualisierung der physikalischen CPUs verantwortlich und nimmt demzufolge die Anfragen der virtuellen Maschinen entgegen. Die letzte Komponente, der Scheduler, ist für die Zuweisung von virtuellen CPUs auf freie Slots auf der physikalischen CPU verantwortlich. Hierbei ist zu beachten: Ist eine virtuelle Maschine mit z.b. 4 oder 8 virtuellen CPUs ausgestattet, so muss der Scheduler einen freien Slot finden, in dem auch 4 oder 8 physische CPUs zu Verfügung stehen. Umso mehr virtuelle Maschinen auf einem physikalischen Host laufen und ihnen viele virtuelle CPUs zugewiesen sind, desto schwieriger wird bzw. länger dauert es, einen entsprechenden Slot zu finden. Deshalb kann es vorkommen, dass virtuelle Server mit mehreren virtuellen CPUs langsamer laufen als andere mit nur einer virtuellen CPU. Deshalb sollten virtuellen Maschinen nur so viele virtuelle CPUs zugewiesen werden wie benötigt. Das gilt auch für andere Virtualisierungslösungen. 20

29 Durch das Fehlen der Service-Konsole verfügt der ESXi Server 3.5 über andere Kommunikationsschnittstellen (siehe Abbildung 13). Einschnitte im Funktionsumfang entstehen dabei jedoch nicht. 9 Abbildung 13: Kommunikationsschnittstellen von ESX / ESXi Server 3.5 Die grafische Administration erfolgt bei beiden Servervarianten über den VI Client oder über einen Webbrowser. Eine Kommandozeilenverwaltung ist über das Command Line Interface (CLI) möglich, hierbei wird eine SSH-Verbindung mit der Service-Konsole aufgebaut. Eine SDK-Schnittstelle ermöglicht es, eigene Skripte oder Programme auszuführen, unterstützte Programmiersprachen sind dabei Java, C# oder Perl. Bei der ESXi Variante ist der Aufbau einer SSH Verbindung durch das Fehlen der Service- Konsole nicht möglich. Hierfür gibt es einen Remote-CLI Client, der die Befehle über die SDK- Schnittstelle sendet. Die Schnittstelle Common Information Model (CIM) wird für die Hardwareüberwachung des ESXi Servers genutzt, da durch das Fehlen der Service-Konsole die entsprechenden Agents fehlen. 9 [RUN09], S

30 In der Abbildung 14 ist der Aufbau einer VMware Infrastructure 3 schematisch dargestellt. Die Kernkomponenten einer VMware Infrastructure 3 bestehen aus den ESX-Hosts, dem zentralen Managementserver VirtualCenter (VC) Server, dem License Server und dem VI Client. Mittels des VI Clients kann eine Verbindung zu VC Server oder den einzelnen ESX- Hosts aufgebaut werden. Bei Verwendung eines VC Servers, der unter anderem für die Hochverfügbarkeitsfunktionen benötigt wird, sollte mit dem VI Client kein direkter Zugriff mehr auf die ESX-Hosts erfolgen, da sonst Inkonsistenzen in der SQL-Datenbank des VC Server auftreten können. An das Netzwerk sind folgende Bedingungen geknüpft: Jeder ESX-Host sollte über ein separates Management Netzwerk mit dem VC Server verbunden sein. Ein zweites separates Netzwerk wird für die Hochverfügbarkeitsfunktionen VMotion und Distributed Resource Scheduler (DRS) benötigt. Auf die genannten Funktionen wird im Kapitel Möglichkeiten der Hochverfügbarkeit näher eingegangen. Ein drittes Netzwerk würde die Verbindung der virtuellen Maschinen zum eigentlichen LAN des entsprechenden Unternehmens herstellen. Zusätzliche Netzwerkkarten werden benötigt, falls die Anbindung der ESX-Host an ein iscsi-san erfolgt. Zusätzlich können jedem vswitch mehrere physische Netzwerkadapter zugewiesen werden, um einen Lastenausgleich oder ein Failover zu ermöglichen. Abbildung 14: Aufbau einer VMware Infrastructure 3 22

31 Bei der Anbindung von Festplatten bietet VMware zwei unterschiedliche Möglichkeiten an. Wie im Kapitel RAW-Device Mapping bereits erwähnt, können LUNs einer virtuellen Maschine direkt zugewiesen werden. Die Daten werden hierbei wie bei einem physischen Server auf Platte geschrieben, bei einem Failover wird die LUN an einen neuen ESX-Host gemountet. Eine zweite Möglichkeit ist die Speicherung in Virtual Hard Disks (VHDs). Die Bezeichnung von VMware lautet Virtual Machine Disk Format (VMDK). VMware entwickelte hierfür das Virtual Machine File System (VMFS) und ähnelt sehr stark den Cluster Shared Volumes (CSV), die bei Hyper-V 2.0 zum Einsatz kommen. Bei dem VMFS handelt es sich um ein Cluster-Dateisystem, auf dem mehrere ESX-Hosts gleichzeitige Lese- und Schreibzugriffe durchführen können. Hierdurch wird gewährleistet, dass bei der Hochverfügbarkeitsfunktion VMotion eine nahezu unterbrechungsfreie Migration zwischen den ESX-Hosts erfolgt, da die LUN nicht erneut gemountet werden muss. Bei der Verwendung von VHDs müssen die LUNs im Storage mit dem VMFS-Dateisystem formatiert werden. Einen Vorteil haben VHDs gegenüber RAW-Devices. Bei VHDs können zeitpunktbezogene Kopien (Snapshots) der virtuellen Maschinen erstellt werden, dies ist bei RAW-Devices nicht möglich. 23

32 3.1.2 Möglichkeiten der Hochverfügbarkeit Wie im vorherigen Abschnitt bereits erwähnt, ist die Funktionalität der Hochverfügbarkeit erst bei dem Einsatz der VMware Infrastructure 3 möglich. Dies wird durch 4 Funktionen gewährleistet, keine ist jedoch bei dem Ausfall eines Knotens in der Lage, die Maschinen unterbrechungsfrei wiederherzustellen. Die Hochverfügbarkeit wird bei VMware durch die Funktionen VMotion, High Availability (HA), Distributed Resource Scheduler (DRS) und Storage VMotion bereitgestellt. VMotion: Die Technologie VMotion bildet das Fundament, auf dem die Hochverfügbarkeitslösung DRS in einem ESX-Cluster aufbaut, kann jedoch auch manuell genutzt werden. Hinter VMotion verbirgt sich die Funktion, virtuelle Maschinen im laufenden Betrieb zwischen ESX-Servern zu verschieben, ohne dass die virtuelle Maschine heruntergefahren werden muss. Dabei bleibt nahezu eine unterbrechungsfreie Verfügbarkeit des entsprechenden virtuellen Servers bestehen. Damit jedoch VMotion funktioniert, sind folgende Bedingungen zu beachten: Das VMware VirtualCenter muss als Managementlösung zum Einsatz kommen. Die an der Migration beteiligten ESX-Hosts müssen auf ein gemeinsames Storage zugreifen können. Für VMotion sollte ein separates Netz zwischen den ESX-Hosts vorhanden sein, um eine unterbrechungsfreie Migration zu gewährleisten. Die Einstellungen zu den virtuellen Netzen, dazu zählen die virtuellen Switche und die Portgroups, müssen auf beiden ESX-Hosts vorhanden sein und die exakt gleiche Bezeichnung tragen. VMotion ist nur innerhalb der Grenzen eines Datacenters möglich. VMotion funktioniert nur, wenn die CPUs der beteiligten ESX-Hosts miteinander kompatibel sind. 24

33 Die Kompatibilität der verwendeten CPUs ist auch für die spätere Erweiterung einer bestehenden ESX-Farm ein entscheidender Faktor. Folgende Bedingungen gelten bei VMotion und müssen eine exakte Übereinstimmung aufweisen: Gleicher Prozessorhersteller und gleiche Prozessorserie bzw. Prozessorfamilie Für virtuelle Maschinen mit 64-bit Betriebssystem werden die Virtualisierungstechnologien AMD-V bzw. Intel-VT benötigt. Unterstützung des SSE3-Befehlsatzes Das NX-Bit bzw. XD-Bit muss von den Prozessoren unterstützt werden, wenn es für die virtuelle Maschine aktiviert wurde. Die Funktion VMotion ist im Grunde genommen nur für die Migration des Speicherinhalts zwischen zwei ESX-Hosts verantwortlich, deshalb müssen beide ESX-Hosts auf das gemeinsame Storage zugreifen können, auf dem sich die virtuelle Maschine befindet. VMotion erfolgt dabei über den VMKernel Port und muss für VMotion aktiviert sein. Folgende Schritte werden bei VMotion durchgeführt: Nachdem ein VMotion Vorgang gestartet wurde, wird eine Arbeitsspeicher-Kopie (Memory Pre-Copy) von Quell-ESX-Host auf den Ziel-ESX-Host übertragen. Der Zugriff auf die virtuelle Maschine erfolgt weiterhin über den Quell-ESX- Host. Alle Änderungen des Arbeitsspeichers werden nach Anstoß des VMotion Vorgangs in einer separaten Datei festgehalten (Arbeitsspeicher-Bitmap). Nach erfolgreichem Memory Pre-Copy, wird die virtuelle Maschine auf dem Quell- ESX-Host pausiert und die Arbeitsspeicher-Bitmap an den Ziel-ESX-Host gesendet. Abschließend wird die virtuelle Maschine auf dem Ziel-ESX-Host fortgesetzt und die Netzwerkkomponenten mittels eines Address Resolution Protocol Requests (ARP- Request) informiert, dass die MAC-Adresse der virtuellen Maschine über einen neuen Switch erreichbar ist. 25

34 High Availability: Mit High Availability (HA) können virtuelle Maschinen automatisch auf anderen ESX-Hosts in einem Clusters neugestartet werden, sollte der ursprüngliche ESX-Host nicht mehr verfügbar sein. Der Grund kann dabei ein Serverausfall sein, oder wenn sich der ESX-Host von seinen anderen im Cluster verfügbaren Knoten isoliert fühlt. Ein spezieller Agent (Automated Availability Manager) auf den ESX-Hosts versendet dazu Heartbeats, um die Erreichbarkeit festzustellen. Distributed Resource Scheduler: Die Funktion Distributed Resource Scheduler (DRS) verwendet VMotion, um einen Lastenausgleich in einem Cluster zu erreichen. Dabei werden automatisch virtuelle Maschinen mittels VMotion zwischen den einzelnen Cluster-Knoten verschoben. Neben der automatischen regelbasierten Ausführung können dem Administrator auch Empfehlungen gegeben werden. Storage VMotion: Bei der Hochverfügbarkeitsfunktion Storage VMotion wird der Speicherplatz der virtuellen Maschinen von einem Datastore in einen anderen Datastore verschoben und dies im laufenden Betrieb. Damit Storage VMotion funktioniert, müssen unter anderem folgende Voraussetzungen gegeben sein: Bei den Festplatten der virtuellen Maschine muss es sich um ein RAW-Device handeln oder die virtuelle Festplatte (VMDK-Datei) muss sich im Modus Persistent befinden. Dabei werden alle Änderungen in der virtuellen Festplatte direkt gespeichert und sind von Snapshots ausgeschlossen. Der ESX-Hosts muss kurzzeitig in der Lage sein, eine zweite virtuelle Maschine des gleichen Typs auszuführen. Storage VMotion funktioniert nur, wenn virtuelle Maschinen die Option N-Port-ID- Virtualisierung (NPIV) nicht nutzen. Mit der Funktion NPIV werden mehrere N_Port-IDs zu einem physikalischen N_Port zugewiesen. Ein FC-Port erscheint durch NPIV wie mehrere virtuelle Ports, die jeweils ihre eigene N_Port-ID und einen virtuellen WWN besitzen. 26

35 3.1.3 Neuerungen in VMware ESX 4.0 und ESXi 4.0 Während der Ausarbeitung zur Virtualisierungslösung VMware Infrastructure 3 erschien Ende April 2009 der Nachfolger VMware vsphere 4. Diese Lösung verwendet den neuen ESX/ESXi 4.0 Hypervisor, sowie den Managementserver VMware vcenter Server. Dieses Kapitel soll kurz die Neuerungen gegenüber der VMware Infrastructure 3 aufzählen, die im Bereich der Hochverfügbarkeit relevant sind. Distributed Power Management: Die Funktion DRS wurde durch die Komponente Distributed Power Management (DPM) erweitert. DPM war bereits in der VMware Infrastructure 3 enthalten, durch seinen Beta- Status wurde es jedoch für produktive Umgebungen nicht empfohlen. Aufgabe von DPM ist es, in Zeiten mit geringer Ressourcenauslastung virtuelle Maschinen auf andere ESX-Hosts eines Clusters zu verschieben und die ESX-Hosts ohne Virtualisierungsaufgaben in den Standby Modus zu versetzen. Ziel dieser Technologie soll es sein, den Stromverbrauch von Rechenzentren automatisch zu senken, wenn weniger Ressourcen benötigt werden. Fault Tolerance: Eine neue Hochverfügbarkeitsfunktion ist Fault Tolerance (FT). Ist bei einer virtuellen Maschine FT aktiviert, wird eine exakte Kopie der virtuellen Maschine auf einem anderen ESX-Host mitgeführt und stets synchron gehalten, was unwiderruflich zu einer Performanceminderung führen muss. Fällt der ESX-Host aus, auf dem die virtuelle Maschine läuft, wird die Kopie auf dem anderen ESX-Host aktiv geschalten und ist über die gleiche IP- Adresse zu erreichen, wie die ausgefallene VM. Durch FT wird die Ausfallzeit, die bei der Funktion HA auftritt, beseitigt. VMware verspricht sich hierbei, eine Hochverfügbarkeitslösung gefunden zu haben, die Null-Ausfallzeit garantiert und Datenverlust verhindert. 27

36 3.2 Microsoft Hyper-V Architektur von Hyper-V Bei dem Produkt Hyper-V handelt es sich um die derzeit aktuelle Virtualisierungslösung von Microsoft. Mit der Einführung des Windows Server 2008 ist die Virtualisierungslösung bereits Teil des Betriebssystems und kann als zusätzliche Server-Rolle implementiert werden. Bei Hyper-V handelt es um eine Hypervisor-basierende Virtualisierungslösung, im speziellen um eine Bare Metall-Virtualisierung, bei dem der Hypervisor direkt auf der Hardware aufsetzt. Bei der Installation der Hyper-V Rolle schiebt sich der Hypervisor zwischen das Host-Betriebssystem (Parent Partition) und die Hardware (siehe Abbildung 15). Dennoch unterscheidet sich der Hypervisor von anderen Hypervisor Implementierungen. Wie im Kapitel zu VMware ESX 3.5 bereits erklärt, verfügt dieser über einen monolithischen Hypervisor mit fest implementierten Treibern. Hyper-V verwendet dagegen einen Microkernel-Hypervisor (siehe Abbildung 15). Dieser ist auf die Kernfunktionalitäten beschränkt und verfügt über kein eigenes Treiber-Modell. Die Treiber befinden sich in der Parent Partition. Abbildung 15: Monolithischer und Microkernel-Hypervisor Die Verwaltung der I/O-Geräte übernimmt bei Hyper-V nicht der Hypervisor, sondern die Parent Partition (siehe Abbildung 16). Zudem verfügt die Parent Partition über direkten Zugriff auf den physikalischen Speicher. Die virtuellen Maschinen haben nur eine virtuelle Sicht auf die Ressourcen, sogenannte virtuelle Geräte (vdevs). Zur Anbindung der vdevs an die virtuellen Maschinen kommunizieren diese über den VMBus mit der Parent Partition. Die Virtualization Service Provider (VSPs) nehmen die Anfragen der virtuellen Maschinen entgegen und werden über den I/O-Stack an die darunterliegende physische Hardware weitergeleitet. 28

37 Damit die virtuellen Maschinen auf den VMBus zugreifen können, werden durch die Installation der Integrationstools die Virtualization Service Consumers (VSCs) bereitgestellt. Da die Parent Partition alle I/O-Vorgänge der einzelnen virtuellen Maschinen verarbeitet, müssen genügend freie Ressourcen für die Parent Partition freigehalten werden, weil es sonst zu Leistungseinbußen kommen kann. Die Empfehlung liegt hier bei einem 2 4 GB freien Arbeitsspeicher und einer Reservierung von 2 CPUs bzw. 2 CPU-Kernen. 10 Abbildung 16: Grobe Architektur von Hyper-V [MIC01], S. 1 29

38 Microsoft bietet die Virtualisierungslösung Hyper-V in unterschiedlichen Versionen an: Hyper-V 1.0 wird als Server-Rolle bei einer Windows Server 2008 Standard, Enterprise oder Datacenter Edition hinzugefügt. Microsoft bietet mit dem Microsoft Hyper-V Server 2008 die Virtualisierungslösung Hyper-V 1.0 als Standalone-Lösung an. Hyper-V 2.0 wird sowohl als Server-Rolle in Microsoft Windows Server 2008 R2 und als separater Microsoft Hyper-V Server 2008 R2 verfügbar sein (Ende Oktober 2009). Der Unterschied zwischen der Hyper-V Server-Rolle und der Standalone-Lösung liegt in der Parent Partition und dass die Standalone-Lösung kostenlos zur Verfügung steht. Bei dem Microsoft Hyper-V Server 2008 befinden sich in der Parent Partition nur die wichtigen Bestandteile, die zur Virtualisierung benötigt werden, unter anderem das Treiber-Modell. Da auf ein komplettes Serverbetriebssystem verzichtet wird, bleiben hierbei mehr Ressourcen für die eigentliche Virtualisierung verfügbar. Zur Verwaltung des Hyper-V Rolle bzw. des Hyper-V Servers kann der Hyper-V Manager des Windows Server 2008 oder der System Center Virtual Machine Manager (SCVMM) 2008 genutzt werden. Handelt es sich um einen Hyper-V Cluster, ist die Verwaltung über den SCVMM oder über die Failover- Clusterverwaltung möglich. 30

39 3.2.2 Neuerungen in Hyper-V 2.0 Mit der Einführung von Hyper-V 2.0 werden wichtige Funktionalitäten im Bereich der Hochverfügbarkeit implementiert und verbessert. Der Microsoft Hyper-V Server 2008 R2 unterstützt nun alle Funktionen, die ein Windows Server 2008 R2 Enterprise mit Hyper-Rolle bietet. Dazu zählen unter anderem Live Migration und die Failover Clustering Funktionalität. Bei der ersten Version von Microsoft Hyper-V Server 2008 wurde unter anderem Quick Migration und die Clusterfunktionalität nicht unterstützt. Folgende Neuerungen bietet Hyper-V 2.0: Festplatten (VHDs bzw. RAW-Devices) können nun im laufenden Betrieb an eine virtuelle Maschine angeschlossen oder von ihr getrennt werden. Die Anforderung hierbei ist die Verwendung eines virtuellen SCSI-Controllers, desweiteren müssen die Integrationsdienste installiert sein. Jeder Virtuellen Maschine können bis zu 32 logische CPUs zugewiesen werden, abhängig von den darunterliegenden physischen CPUs. Unterstützung der Technologien EPT und RVI Bei der Funktion CPU Core Parking wird die benötigte Rechenleistung auf eine geringe Anzahl von physischen CPU-Kernen verschoben. Inaktive CPU-Kerne werden daraufhin deaktiviert, wenn dies die darunterliegende Prozessorarchitektur unterstützt. Welche Kerne geparkt werden, kann auf der Parent Partition, über den Ressourcen Monitor überwacht werden. Unterstützung von Cluster Shared Volumes (CSV) und Live Migration (siehe Kapitel Möglichkeiten der Hochverfügbarkeit ) Unterstützung von TCP Chimney Offload und von Jumbo Frames 9014 Byte (TCP Chimney Offload bietet die Möglichkeit, die gesamte TCP/IP-Verarbeitung auf entsprechende Netzwerkadapter mit TOE auszulagern) In Hyper-V 1.0 werden Netzwerkdaten in den Arbeitsspeicher des Host übertragen, um anschließend diese zur entsprechenden virtuellen Maschine zu transferieren. Die neue Funktion Virtual Machine Queue (VMQ) kopiert die Daten von der Netzwerkkarte direkt in den Arbeitsspeicher der virtuellen Machine. Die Hochverfügbarkeitsfunktionalitäten werden im nächsten Kapitel näher erläutert. 31

40 3.2.3 Möglichkeiten der Hochverfügbarkeit Im Bereich der Hochverfügbarkeit bietet Hyper-V zwei grundlegende Implementierungen: Quick Migration und Live Migration. Egal ob Quick Migration oder Live Migration, ein Failover Cluster ist hierbei immer Grundvoraussetzung. Hyper-V 1.0 unterstützt nur Quick Migration, dagegen unterstützt Hyper-V 2.0 beide Implementierungen. Quick Migration: Die Funktion Quick Migration stammt aus Hyper-V 1.0 und ermöglicht das Verschieben einer virtuellen Maschine von einem Quell-Cluster-Knoten zu einem Ziel-Cluster-Knoten. Folgende Schritte werden bei der Funktion Quick-Migration ausgeführt: 1. Quick Migration speichert den Zustand der virtuellen Maschine und schreibt den Inhalt des Arbeitsspeichers des Quell-Cluster-Knotens auf das gemeinsame Storage. 2. Die Storage-Verbindung wird von dem Quell-Cluster-Knoten zu dem Ziel-Cluster- Knoten verschoben. 3. Der neue Host lädt das Arbeitsspeicherabbild und startet die virtuelle Maschine. Quick Migration ist also nicht in der Lage, einen Server ohne Unterbrechung zu verschieben. Desweiteren sind folgende Bedingungen zu beachten: Quick-Migration ist nur in einem Hyper-V Cluster möglich. Beteiligte Cluster-Knoten müssen derselben Active Directory (AD) Domain angehören, als Namensauflösung wird Domain Naming System (DNS) empfohlen. Auch an die Hardware werden hohe Anforderungen gestellt: So müssen beide Cluster-Knoten über eine nahezu gleiche Hardware, sowie über den gleichen Prozessor-Hersteller und gleiche Prozessor-Architektur verfügen. Beide Prozessoren müssen AMD-V bzw. Intel VT unterstützen. Der Failover-Cluster ist in einem Storage Area Network (SAN) installiert. 32

41 Live Migration: Eine neue Funktion von Hyper-V 2.0 ist Live Migration. Bei Live Migration wird eine virtuelle Maschine von einem Cluster-Knoten auf einen anderen Cluster-Knoten verschoben, ohne Unterbrechung. Live Migration wird von Windows Server 2008 R2 EE/DC (x64) und von Microsoft Hyper-V Server 2008 R2 unterstützt. Die benötigten Managementwerkzeuge sind dabei der Failover Cluster Manager oder der System Center Virtual Machine Manager 2008 R2. Die Abbildung 17 zeigt die einzelnen Schritte der Live Migration nochmals in einer grafischen Darstellung. 1. Im ersten Schritt wird eine TCP Verbindung zwischen den beteiligten physikalischen Hosts aufgebaut. Der Quell-Cluster-Knoten sendet die Konfigurationsdaten der virtuellen Maschinen. Der Ziel-Cluster-Knoten erstellt die Konfigurationsdatei der virtuellen Maschine und reserviert benötigten Arbeitsspeicher. 2. Im zweiten Schritt wird der Arbeitsspeicherinhalt vom Quell-Cluster-Knoten auf den Ziel- Cluster-Knoten transferiert. 3. Zum Abschluss wird der geänderte Arbeitsspeicherinhalt übertragen. 4. Im vorletzten Schritt der Live Migration erhält der Ziel-Cluster-Knoten Zugriff auf die VHD(s) bzw. auf die RAW-Devices der virtuellen Maschine. 5. Im letzten Schritt der Live Migration ist die virtuelle Maschine auf dem Ziel-Cluster- Knoten online. Die beteiligten Netzwerkkomponenten werden über einen ARP-Request darüber informiert, dass die MAC Adresse der virtuellen Maschine über einen neuen Switch erreichbar ist. Abbildung 17: LiveMigration in Hyper-V

42 Um eine höhere Kompatibilität für Live Migration zu gewährleisten, ist in Hyper-V 2.0 eine Funktion zur Bereitstellung vorhandener Prozessoren in einem Kompatibilitätsmodus implementiert. Hierbei besteht die Möglichkeit, virtuelle Maschinen zwischen unterschiedlichen Prozessorarchitekturen und -familien des gleichen Prozessorherstellers zu migrieren. Bei Aktivierung des Kompatibilitätsmodus (nur im ausgeschalteten Zustand der virtuellen Maschine zu empfehlen) werden bestimmte Befehlssätze von Prozessoren vor der virtuellen Maschine verborgen, um eine Migration zu einem anderen Host zu gewährleisten. Cluster Shared Volumes: Die dritte Neuerung bei Hyper-V 2.0 sind die Cluster Shared Volumes (CSV). Die CSV sind eine neue Funktion des Failover Clusters und Bestandteil des neuen Windows Server 2008 R2. Die Funktion CSV ermöglicht, dass mehrere Hyper-V Clusterknoten gleichzeitig auf eine LUN lesenden und schreibenden Zugriff haben. Wird eine LUN im Failover Cluster Manager als CSV eingerichtet, wird der direkte Zugriff über den Explorer auf die LUN unterbunden. Ein Verweis zu den entsprechenden CSV (C:\ClusterStorage\Volume[X]), befindet sich dabei auf jedem Cluster-Knoten. Der Vorteil von CSV ist, dass im Fall einer Live Migration das Dismounten und Mounten des entsprechenden Volume entfällt. Die Folge ist, dass der Timeout während der Live Migration garantiert unter 300ms liegt. In der Regel liegt der Timeout bei 10 20ms. Die virtuellen Maschinen werden in den CSV als VHDs abgelegt. Die virtuellen Maschinen greifen in Hyper-V 2.0 dennoch über RAW I/O auf die LUN zu, wie bei der direkten Zuweisung von RAW-Devices. In Kombination mit CSV kann zudem die Unterbrechung einer SAN-Verbindung kompensiert werden. Führt ein Hyper-V Server eine virtuelle Maschine aus und verliert die Verbindung zum CSV, wird die RAW I/O über das Heartbeat oder das öffentliche Netzwerk übertragen. Als Vermittlungsstelle fungiert der Clusterknoten, der noch Zugriff auf das entsprechende CSV besitzt. Um den Ausfall eines Storages zu kompensieren, müssen die Daten auf ein anderes Storage gespiegelt werden, entweder durch entsprechende Funktionen von Storages oder mit Softwarelösungen wie Veritas Storage Foundation. Die CSV sind jedoch keine Bedingung für Live Migration, wird jedoch von Microsoft empfohlen. Live Migration funktioniert auch mit RAW-Devices oder virtuellen Maschinen, bei denen die VHDs auf einer einzelnen LUN liegt. Hierbei ist aber durch das oben beschriebene Dismounten und Mounten der LUN mit höheren Timeouts zu rechnen. 34

43 3.3 Citrix XenServer Architektur von Citrix XenServer 5.5 Der Grundstein für Xen wurde 2001 an der Universität von Cambridge gelegt. In den folgenden Jahren gründeten die ehemaligen Entwickler die Firma XenSource und entwickelten die Virtualisierungslösung weiter, um eine Konkurrenzlösung zu VMware ESX Servern zu schaffen. Schlussendlich übernahm Citrix die Firma im Jahr 2007 für 500 Millionen US-Dollar. Ziel von Citrix ist es, mit einer bereits bestehenden Lösung in den Markt der Virtualisierung einzutreten. Die aktuelle Virtualisierungslösung ist der Citrix XenServer 5.5 und die Managementlösung Citrix Essentials für XenServer. Ab der Version 5.5 bietet Citrix die Virtualisierungsplattform und das Managementtool Citrix XenCenter 5.5 komplett kostenlos an, ohne Einschränkungen auf Ressourcen wie CPUs oder Sockets. Der Kern von Citrix XenServer 5.5 ist der Open Source Xen Hypervisor in der Version 3.3. Der Citrix XenServer 5.5 unterstützt im Gegensatz zu Xen Open Source nur die 64-bit Version des Hypervisors. Die neue Version unterstützt 32 CPU-Kerne und einen maximalen Arbeitsspeicher von 128 GB. Einer virtuellen Maschine können maximal 8 vcpus und 32GB RAM zugeteilt werden. Festplatten und Netzwerkkarten können den virtuellen Maschinen im laufenden Betrieb hinzugefügt oder entfernt werden. Die Architektur des Xen Hypervisors ähnelt dem Grundaufbau von Hyper-V. Der Xen Hypervisor setzt direkt auf der Hardware auf und ist für die Speicherverwaltung und das CPU Scheduling der virtuellen Maschinen verantwortlich. Der Xen Hypervisor hat jedoch keine Informationen über Netzwerk- oder extern angeschlossene Speichergeräte. Nach dem Start des Hypervisors wird hierfür eine separate virtuelle Maschine (Domain 0) gestartet. Sämtlicher Netzwerk- und Storage-Datenverkehr von den virtuellen Maschinen wird über die Domain 0 abgewickelt. Die verantwortlichen Dienste bzw. Treiber sind der Network Backend Driver und der Block Backend Driver. Bei Xen werden die weiteren virtuellen Systeme als Domain U bezeichnet. Hierbei gibt es eine Unterscheidung zwischen Domain U PV und Domain U HVM. Alle paravirtualisierten Maschinen, bei dem der Kernel angepasst werden kann bzw. darf, zählen zu der Gruppe der Domain U PV. Der Kernel kann unter anderem bei Linux Betriebssystemen, Solaris und FreeBSD angepasst werden. Zu den Domain U HVM 35

44 Gästen zählen alle Windows Betriebssysteme. In Abbildung 18 ist die grobe Architektur des Citrix XenServer 5.5 abgebildet. Abbildung 18: Architektur des Xen Hypervisor Im Gegensatz zu VMware, lassen sich mit dem kostenlosen XenCenter mehrere Virtualisierungsserver zu einem Ressourcenpool zusammenfassen und zentral verwalten. Citrix XenServer 5.5 arbeitet hier nach einem Master/Slave Prinzip. Ein Virtualisierungsserver nimmt dabei die Rolle des Masters ein und repliziert sämtliche Konfigurationsdaten der Datenbank pool db auf die Secondary Server, die im Failover-Fall zu einem neuen Master herauf gestuft werden. Citrix verzichtet somit auf das Modell mit einem zentralen Managementserver, der die Konfigurationsdaten der virtuellen Infrastruktur speichert. Bei der Anbindung von Festplattenlaufwerken unterscheidet sich Citrix XenServer 5.5 von den anderen getesteten Lösungen. Citrix XenServer 5.5 unterstützt kein RDM, sondern nur VHDs. 36

45 3.3.2 Möglichkeiten der Hochverfügbarkeit Im kostenlosen Citrix XenServer 5.5 ist die Hochverfügbarkeitslösung XenMotion bereits implementiert. Die Funktionen HA oder dynamischer Lastenausgleich sind erst mit der kostenpflichtigen Managementlösung möglich. XenMotion: Die Funktion XenMotion bietet die gleichen Funktionen wie LiveMigration oder VMotion und garantiert ein Verschieben der virtuellen Maschinen zwischen den Virtualisierungshosts ohne Ausfallzeit. XenMotion funktioniert nur zwischen gleichen Prozessorherstellern, Prozessorfamilien und gleichen Befehlssätzen. Ein Kompatibilitätsmodus wie bei Hyper-V 2.0 wird nicht unterstützt. XenMotion verursacht eine Downtime von ms. High Availability: Die Funktion HA ist für den automatisierten Neustart virtueller Maschinen verantwortlich, wenn ein Virtualisierungsserver in einem Ressourcenpool ausfällt. Der Master überwacht hierbei den Status sämtlicher Virtualisierungsserver in einem Pool und startet ausgefallene virtuelle Maschinen neu. Bei Ausfall des Masters, wird automatisch ein Secondary Server herauf gestuft. Ohne die Funktion HA sollte eine virtuelle Infrastruktur nicht betrieben werden, da dies ein manuelles Eingreifen für den Neustart virtueller Maschinen bedeuten würde. Dynamic Workload Balancing: Bei der Funktion Dynamic Workload Balancing werden aufbauend auf XenMotion virtuelle Maschinen automatisch anhand von Regel zwischen den Virtualisierungshost verschoben. Ziel dieser Lösung ist es, einen automatischen Lastenausgleich oder eine Effizienzsteigerung zu erreichen. Der Lastenausgleich erfolgt anhand von CPU, RAM, Netzwerk und Festplattenauslastung, die vom Administrator festgelegt werden. Die Funktionen HA und Dynamic Workload Balancing sind in der Enterprise Edition von Citrix Essentials enthalten. Der Preis für die Enterprise Edition liegt bei 2500 US-Dollar. Die Lizenzsierung erfolgt pro Virtualisierungshost. 37

46 3.4 Virtual Iron Architektur von Virtual Iron 4.5 Als letzte zu testende Virualisierungslösung wurde Virtual Iron Extended Enterprise Edition ausgewählt. Das Unternehmen Oracle kaufte Mitte Mai 2009 die Firma Virtual Iron auf und wird die Produktpalette von Virtual Iron nicht weiter fortführen. Das komplette Entwicklerteam wurde bereits entlassen. Dennoch wurde das Produkt mit in die Betrachtung aufgenommen. Oracle hat angekündigt, die Hypervisor Technologie in eigene, zukünftige Produkte zu integrieren. Aufgrund der Tatsache, dass es dieses Produkt nicht mehr käuflich zu erwerben gibt, wird nur eine Zusammenfassung der Architektur und der Hochverfügbarkeitsmöglichkeiten betrachtet, um die spätere Implementierung bei den praktischen Tests nachvollziehen zu können. Für die Implementierung von Virtual Iron muss ein dediziertes Managementnetzwerk eingerichtet werden (siehe Abbildung 19). Der Management Server (Virtualization Manager) besitzt einen eigenen DHCP-Server und muss so physisch vom Unternehmensnetzwerk getrennt werden. Die Virtualisierungsserver sind auf einer Netzwerkschnittstelle mit dem Managementnetzwerk verbunden. Die Funktion LiveProvisioning lädt mittels PXE-Boot den Hypervisor direkt in den Arbeitsspeicher des Virtualisierungsserver. Durch diese Methode ist das Hinzufügen weiterer Virtualisierungsserver bedeutend einfacher und schneller zu realisieren als bei VMware, Hyper-V oder Citrix XenServer. Abbildung 19: dediziertes Managementnetzwerk bei Virtual Iron

47 Wie Citrix XenServer 5.5 basiert Virtual Iron auch auf dem Xen Open-Source-Hypervisor und benötigt die Virtualisierungslösungen AMD-V bzw. Intel VT. Die neuen Virtualisierungstechnologien AMD RVI und Intel EPT werden dagegen von Virtual Iron 4.5 nicht unterstützt. Nachdem der Hypervisor über PXE-Boot geladen wurde, startet dieser die Service Partition (Domain 0). Der Hypervisor und die Service Partition befinden sich dabei im Arbeitsspeicher des Virtualisierungsservers, interne Festplattenlaufwerke sind nicht erforderlich. Die Service Partition steuert unter anderem den Hypervisor und enthält Anwendungen für das Management, I/O Virtualisierung und den Dienst für LiveMigration (siehe Abbildung 20). Sie enthält weiterhin Gerätetreiber und basiert auf einem SLES 10 Linux Kernel. Die Service Konsole ist über einen Management Agent (Management Control) mit dem Virtualization Manager verbunden. Die Verbindung wird für Steuersignale und für den Heartbeat verwendet. Die Kommunikation erfolgt dabei gesichert über TCP/IP. Wie bei Hyper-V 1.0 und Citrix XenServer 5.5 geht der Daten- und Netzwerkverkehr über die Service Partition. Nur die Service Partition hat direkten Zugriff auf die Hardware. Wie VMware und Hyper-V unterstützt auch Virtual Iron VHDs oder die direkte Anbindung von RAW-Devices. Abbildung 20: grobe Architektur von Virtual Iron

48 3.4.2 Möglichkeiten der Hochverfügbarkeit In Bereich der Hochverfügbarkeit bietet Virtual Iron 4.5 die Implementierungen LiveMigration, LiveCapacity, LiveRecovery, LiveMaintenance, LiveSnapshot und LivePower. Die Funktion LiveMigration ermöglicht das Verschieben der virtuellen Maschinen zwischen den Hosts. Für einen automatischen Lastenausgleich zwischen den Virtualisierungsservern ist die Funktion LiveCapacity verantwortlich. Mit der Funktion LiveRecovery werden virtuelle Server auf anderen Host automatisch neugestartet, falls der Ausfall eines Virtualisierungsservers vorliegt. Die Implementierung LiveMaintenance schaltet den physischen Host in einen Wartungszustand, alle auf ihm laufenden virtuellen Server werden durch LiveMigration auf andere Hosts verschoben. Mittels LiveSnapshot können zeitpunktbezogene Zustände von virtuellen Maschinen erstellt werden. Diese Methodik kann unter anderem genutzt werden, um bei fehlgeschlagenen Upgrade-Szenarien auf den zuvor erstellten Snapshot zurückzukehren. LivePower dient in erster Linie der Senkung der Stromkosten eines Rechenzentrums. Dabei werden mittels LiveMigration die Maschinen auf andere Hosts verschoben und untätige Hosts heruntergefahren. Diese Host werden automatisch neugestartet, wenn mehr Ressourcen zur Virtualisierung benötigt werden. Virtual Iron 4.5 war im Grunde genommen das einzige Produkt, das einen ähnlichen Funktionsumfang im Bereich der Hochverfügbarkeit wie VMware bietet. 40

49 4 Entwicklung eines Testszenarios 4.1 Physikalische Testumgebung Um unterschiedliche Virtualisierungssysteme direkt miteinander vergleichen zu können, wird als erstes eine nahezu einheitliche, physikalische Hardwareumgebung vorausgesetzt. Die verwendete Testumgebung besteht aus einem physischen Virtualisierungsserver, auf dem die Virtualisierungslösungen implementiert werden. Die zweite Komponente ist ein zentrales Storage, welches als Speichermedium für die virtuellen Maschinen fungiert. Die Virtualisierungslösungen werden dabei jeweils getrennt in einer FC-SAN und in einer iscsi- SAN Umgebung getestet. Zwischen dem FC-SAN Storage und dem iscsi-san Storage existieren Unterschiede. Das FC-Storage verfügt über einen integrierten RAID-Controller und FC-Ports und wird direkt mit dem FC-HBA des Virtualisierungsserver verbunden. Die Konfiguration ist eine 4 GBit Point-to-Point Topologie. Das iscsi-storage ist hingegen ein JBOD, welches über ein SAS-Interface mit einem RAID Controller verbunden wird. Dieser RAID-Controller befindet sich in einem zweiten physischen Server, baugleich zum Virtualisierungsserver. Als iscsi-lösung kommt hierbei das Produkt Open-E DSS 6.0 zum Einsatz. Die LUNs des iscsi-storages werden über eine 1 GBit Netzwerkschnittstelle mittels eines iscsi-software Targets bereitgestellt. Die folgende Abbildung 21 zeigt die physikalische Testumgebung. Proware SB-3163S-F4S3 4 GBit FC SAS/SATA RAID Disksubsystem (16 Slots) Proware SB-3163-S3S3 SAS/SATA JBOD Disksubsystem (16 Slots) Point-to-Point Topologie separates iscsi-netz D-Link DGS-1016D 1 GBit Switch 16 Ports SAS Kabel 26pin: SFF 8088 (4 x 3 Gbit/s) Qlogic QLE2562 FC-HBA 1 GBit NIC 1 GBit NIC Adaptec RAID 5445 SAS/SATA RAID Controller Virtualisierungsserver Server mit Open-E DSS 6.0 Virtual Iron Management Netzwerk Netgear FS MBit Switch 5 Ports Virtual Iron Management Server internes Firmennetzwerk Abbildung 21: physikalische Testumgebung 41

50 Bei den Implementierungen wurde auf ein separates Management Netzwerk verzichtet, da es keine negativen Auswirkungen auf die Messungen hat, den Implementierungsaufwand jedoch verringert. Als Management Netzwerk diente das interne Firmennetz, benötigte Managementlösungen wurden vom Client ausgeführt. Bei Virtual Iron musste aufgrund des eigenen DHCP Servers ein separates Management Netzwerk eingerichtet werden. 4.2 Rahmenbedingungen Um eine Verfälschung der Ergebnisse zu verhindern, wurden bestimmte Hardwarefunktionen deaktiviert, die unter anderem das System während der Messungen verändern. Folgende Parameter wurden gegenüber den Standardeinstellungen verändert: Virtualisierungsserver: Die Spezifikationen des Virtualisierungsservers bzw. des baugleichen Open-E DSS 6.0 Servers befinden sich im Anhang A2. Der Fokus liegt auf der neuen Intel CPU-Architektur und den daraus teilweise resultierenden Funktionen, die die Eckdaten des Systems während der Tests ändert. Deshalb wurden im BIOS folgende Parameter gegenüber den Standardspezifikationen verändert: Die Stromsparfunktion Intel Speed Step, die den Multiplikator der CPU senkt, wenn weniger Systemlast anliegt, wurde deaktiviert. Daraus resultiert ein geringer CPU- Takt, und die Änderung des Multiplikators produziert ein kurzes Performance-Leck. Eine Neuerung in der Intel Nehalem-Architektur ist die Intel Turbo Boost Technologie. Bei geringer Gesamtlast werden einzelne CPU-Kerne automatisch übertacktet, der maximale TDP-Wert wird hierbei nicht überschritten. Von dieser Technologie sollen Anwendungen profitieren, die nur einen Kern nutzen. Die Funktion wurde deaktiviert, um eine Verfälschung des CPU-Taktes zu verhindern. Die Virtualisierungstechnologie Intel VT und das XD-Bit wurden aktiviert. Storagesysteme und Caches: Bei den Festplatten im FC-Storage und iscsi-storage wurden bewusst 16 identische Exemplare (siehe Anhang A2) gleicher Größe und gleicher Baureihe ausgewählt, um Unterschiede zwischen den Datendichten auf den Plattern und somit einen unterschiedlichen Datendurchsatz zu verhindern. In Anlehnung an praktische 42

51 Konfigurationen bei Firmenkunden arbeiten beide Storagesysteme bzw. dessen RAID- Controller im Write-Through Modus. Der Read-Cache des Controllers ist hingegen aktiviert, da die Datenintegrität hierdurch nicht gefährdet wird. Auf Festplattenebene bleiben Read- Cache und Write-Cache aktiv. Auch die Funktion NCQ wurde zusätzlich aktiviert. Zuvor durchgeführte Messungen haben ergeben, dass bei zufälligem Zugriff ein höherer Datendurchsatz und geringere Transaktionszeiten zu erzielen sind. Entsprechende Messergebnisse sind dem Kapitel 5.1 Performanceauswertung von NCQ zu entnehmen. Die erstellten LUNs haben jeweils eine Größe von 30 GB. Desweiteren liegt den LUNs ein RAID 6 zugrunde, welches sich über die 16 verfügbaren Platten erstreckt. Die eingestellte Stripe Size liegt bei 64 KB. Die LUNs wurden vor der Nutzung initialisiert. Virtualisierungslösungen und virtuelle Maschinen: Die zu testenden Virtualisierungslösungen werden jeweils lokal auf der Festplatte des Virtualisierungsserver installiert. Virtual Iron 4.5 bildet hierbei eine Ausnahme. Der Hypervisor wird beim Starten des Servers über PXE-Boot vom Managementserver in den Arbeitsspeicher geladen. Allen virtuellen Maschinen wird per RDM eine LUN für das Serverbetriebssystem zugewiesen. Eine weitere Ausnahme ist hier der Citrix XenServer 5.5, der RDM nicht unterstützt. Jedem virtuellen Server werden 1 bis 2 weitere LUNs zugewiesen, die für Performancemessungen mit Iometer und als Ablageort für Datenbanken und deren Logdateien verwendet werden. Die LUN Zuweisung erfolgt hierbei stets auf der Ebene des Hypervisors und nicht in der virtuellen Maschine. Genauere Informationen zu den Benchmarks und entwickelten Testszenarien siehe Kapitel 4.4 verwendete Benchmarktools. Der Virtualisierungsserver verfügt physisch über eine CPU mit 4 Kernen und 12 GB RAM, detaillierte Serverspezifikationen sind dem Anhang A2 zu entnehmen. Jeder virtuellen Maschine werden 4 vcpus und 8 GB RAM zugewiesen. Aufgrund der Architektur von Hyper-V 1.0 und 2.0, Virtual Iron 4.5 und Citrix XenServer 5.5, bei dem ein Großteil des I/O-Verkehrs über die Parent Partition abgewickelt wird, bleiben 4 GB RAM als Reserve frei, um keinen künstlichen Flaschenhals zu produzieren und VMware dadurch einen Vorteil zu verschaffen. Die Funktion EPT, welche in der Nehalem-Architektur integriert ist, wird bei VMware ESX/ESXi 4.0 separat aktiviert. Bei Citrix XenServer 5.5 und Microsoft Hyper-V 2.0 ist die Funktion automatisch aktiv. 43

52 4.3 Virtualisierungslösungen, Serverbetriebssysteme und Anwendungen Folgende Virtualisierungsprodukte werden jeweils im FC-SAN und im iscsi-san getestet: Citrix XenServer 5.5 VMware ESX 4.0 / ESXi 4.0 Virtual Iron Extended Enterprise Edition Microsoft Windows Server 2008 Enterprise SP2 (x64) mit Hyper-V 1.0 Microsoft Windows Server 2008 R2 Enterprise RC (x64) mit Hyper-V 2.0 Microsoft Hyper-V Server 2008 R2 RC (x64) Folgende Serverbetriebssysteme werden virtualisiert und entsprechenden Testszenarien unterzogen. Desweiteren wird der Virtualisierungsserver mit den Betriebssystemen jeweils in einer FC-SAN und iscsi-san Umgebung nativ getestet. Microsoft Windows Server 2003 R2 Enterprise SP2 (x86) Microsoft Windows Server 2008 Enterprise SP2 (x64) Folgende Anwendungen werden nach erfolgreich abgeschlossenen Iometer Tests gemeinsam auf den Windows Server 2008 installiert. Diese Anwendungen werden benötigt, um entsprechende Performancemessungen im Bereich von SQL Datenbanken durchführen zu können. Die Datenbankdateien und die Logs werden auf zwei LUNs getrennt gespeichert. Microsoft SQL Server 2008 Enterprise (x64) Quest Software Benchmark Factory for Databases 44

53 4.4 Verwendete Benchmarktools Benchmarks für Virtualisierungssysteme Das Problem bei der Auswahl geeigneter Benchmarks bestand darin, dass bis heute kein unabhängiges Benchmarktool existiert, welches die Leistung von Virtualisierungssystemen nach einem standardisierten Verfahren testet. Das unabhängige Benchmark-Konsortium Standard Performance Evaluation Corporation (SPEC) entwickelt seit Jahren standardisierte Benchmarks für Hardware- und Softwarelösungen im Businessbereich und genießt eine große Akzeptanz in der Wirtschaft. SPEC hat im Oktober 2006 die Entwicklung zu einem Benchmark für Virtualisierungssysteme gestartet. Bis heute befindet sich das Projekt in der Entwicklungs- und Testphase. Aus diesem Grund wurden zwei andere Benchmarks herangezogen, auf die in den nächsten beiden Unterkapiteln näher eingegangen wird Iometer Um Leistungsunterschiede zwischen den Virtualisierungslösungen zu ermitteln, werden unterschiedliche Testszenarien durchgeführt. Im ersten Testszenario werden unterschiedliche Blockgrößen simuliert. Dabei werden der Datendurchsatz, die Anzahl der Transaktionen, die Antwortzeiten und die Auslastung der Prozessoren in Abhängigkeit der verwendeten Blockgrößen ermittelt. Zur Ermittlung der Werte wird das Benchmark-Tool Iometer herangezogen, welches zur Analyse von I/O-Subsystemen empfohlen wird. Ursprünglich wurde es von der Firma Intel entwickelt und 2001 an die Open Source Development Lab (OSDL) übergeben. Iometer ist als Stable-Version und als Beta- Version RC2 erhältlich. Trotz besserer Unterstützung für 64-bit Betriebssysteme erzeugte die Beta-Version in einigen Testmessungen fehlerhafte Werte, die sich z.b. in Transferraten von 35 GB/s niederschlugen. Aus diesem Grund wurde die ältere Stable- Version, die dieses Verhalten nicht zeigte und nachvollziehbare Werte lieferte, für die Messungen herangezogen. 45

54 Für die Entwicklung von Iometer Lastprofilen wurden zuvor die Zugriffsmuster von den zu virtualisierten Anwendungsservern ermittelt und analysiert. In der Tabelle 3 sind die wichtigsten Anwendungen mit den dazugehörigen Zugriffsmustern aufgelistet. Als Quellen dienten hierzu Angaben von Microsoft und Fujitsu 11. Tabelle 3: Zugriffsmuster von Anwendungen Anwendungen Zugriffsmuster Blockgrößen Zugriffsart Lesen Schreiben Betriebssysteme random 40% 60% 4 KB Datenbank (MS SQL Server) random 67% 33% 8 KB 256 KB Datenbank (MS Exchange 2003) random 67% 33% 4 KB Datenbank (MS Exchange 2007) random 67% 33% 8 KB File-Server random 67% 33% 8 KB Kopiervorgänge random 50% 50% 64 KB Web-Server random 100% 64 KB Datenbank Log File sequentiell 100% 64 KB Backup sequentiell 100% 64 KB Restore sequentiell 100% 64 KB Streaming von Videos sequentiell 100% 64 KB Aus den gegebenen Zugriffsmustern wurden 3 Lastprofile abgeleitet (siehe Tabelle 4), die jeweils Blockgrößen von 1 KB 256 KB simulieren, um ein größeres Spektrum zwischen den am meisten genutzten Blockgrößen 4 64 KB zu erhalten. Die Zwischenschritte ergeben sich jeweils aus der Verdopplung der vorherigen Werte. Tabelle 4: Lastprofile für Iometer Lastprofile Zugriffsart Zugriffsmuster Blockgrößen Lesen Schreiben Lesen sequentiell 100% KB Schreiben sequentiell 100% KB Datenbanken random 65% 35% KB Jedes Lastenprofil wird in 8 Sitzungen mit je 8 Worker und in 32 Sitzungen mit wiederum jeweils 8 Worker getestet. Hierdurch soll festgestellt werden, wie die Systeme mit höherer Last skalieren. Jede Blockgröße wird für genau 1 Minute simuliert, mit einer dazwischen liegenden Pause (Ramp Up Time) von 10 Sekunden. Gemessen wird auf leere 30 GB große, nichtformatierte Festplatte, die auf der Hypervisorebene per RDM der virtuellen Maschine zugewiesen ist. 11 [FUJ09] 46

55 4.4.3 TPC-H Im zweiten Testszenario wird untersucht, welche Performanceunterschiede zwischen den Virtualisierungslösungen auftreten, wenn typische Serveranwendungen wie Datenbanksysteme auf den virtuellen Server ausgeführt werden. Damit die Ergebnisse vergleichbar bleiben, werden standardisierte Benchmarks für Datenbanksysteme herangezogen. Aufgrund der Festlegung auf den Microsoft SQL Server 2008 eignet sich dafür der Benchmark für relationale Datenbanken TPC-H. Der Benchmark TPC-H wurden von dem Transaction Processing Performance Council (TPC) entwickelt und standardisiert. Dabei handelt es sich um eine Vereinigung mehrerer IT- Unternehmen wie AMD, IBM, Intel, Microsoft, VMware und weitere, die das Ziel verfolgt, Datenbanksysteme verschiedener Hersteller und die darunterliegende Hardware in ihrem Preis-/Leistungsverhältnis besser vergleichen zu können. Das Ziel der TPC Benchmarks ist es, praxisrelevante Umgebungsbedingungen zu erzeugen, und somit liegt auch dem TPC-H Benchmark ein hypothetisches Handelsunternehmen zugrunde. Bei dem TPC-H Benchmark werden, basierend auf den Verkaufsdaten eines Handelsunternehmens, sogenannte Decision-Support-Anfragen gestellt. Beim TPC-H Benchmark sind es im speziellen ad-hoc Anfragen. Solche Anfragen sind sehr komplex, besitzen keinerlei Vorwissen und benötigen zur Ergebnisermittlung relativ große Datenmengen. Das zugrunde liegende relationale Datenbankschema besteht aus 8 Relationen und ist in Abbildung 22 dargestellt. 47

56 12 Abbildung 22: Datenbankschema des TPC-H Benchmarks Um eine Skalierbarkeit des TPC-H Benchmarks zu gewährleisten, sind alle Tupel in den Relationen abhängig vom eingestellten Scale Faktor (SF). Auf die Relationen REGION und NATION hat der SF keinen Einfluss. Bei einem SF von 1 werden ca. 1 GB Nutzdaten generiert und steigen abhängig vom verwendeten SF linear an. Das TPC erlaubt die Verwendung der Scale Faktoren 1, 10, 30, 100, 300 und Für das ausgearbeitete Testszenario wurde ein SF von 10 festgelegt. Die tatsächliche Größe der Datenbank erreicht einen Wert von ca. 20,3 GB. Diese Größe ergibt sich aus den reinen Nutzdaten, sowie Indizes und anderer Overhead, die durch das Datenbankmanagementsystem, in diesem Fall Microsoft SQL Server 2008 Enterprise Edition (x64), erzeugt werden. Nach Erstellung der Datenbank, startet der eigentliche TPC-H Benchmark mit seinen 22 Anfragen Q1 bis Q22. Eine detaillierte Beschreibung der Anfragen ist dem Anhang A3 zu entnehmen. 12 [KEM06], S

57 Auswertung des TPC-H Benchmarks TPC-H Powermetrik: Für die Auswertung des TPC-H Benchmarks werden mehrere Größen benötigt. Der TPC-H Powermetrik Wert QppH gibt die Anzahl von sequentiell ausgeführten Anfrage- und Änderungsoperationen pro Stunde an. Das verwendete Benchmark Tool für TPC-H (Benchmark Factory von Quest Software) verzichtet auf die Updatefunktionen UF1 und UF2, deshalb wird der Wert für QppH mit dem Vermerk auf Verzicht der UF angegeben. Hinter der Abkürzung QI verbirgt sich das Intervall der einzelnen Abfragen Q1 bis Q22. Von den in Sekunden ermittelten Abfrageintervallen wird der natürliche Logarithmus ln() gebildet. Dies verhindert, dass die komplexeren Abfragen des TPC-H Benchmarks nicht die weniger komplexeren in ihrer Wichtigkeit verdrängen. Durch die Angabe der Datenbankgröße (Nutzdaten) ist zudem ein Rückschluss auf den verwendeten SF gegeben. TPC-H Durchsatz: Der Durchsatz wird aus der Anzahl bearbeiteter Anfragen pro Stunde ermittelt. Die Konstante S steht für die Anzahl der verwendeten Abfrage-Streams und ist bei dem Testszenario auf 1 festgelegt. Der Wert T steht für die Gesamtdauer aller Abfragen bzw. für die maximale Transaktionszeit eines Abfrage-Streams. 49

58 TPC-H Leistungsmetrik: Der Wert für die Leistungsmetrik QphH wird aus dem geometrischen Mittel der Werte QppH und QthH gebildet. Preis-/Leistungsverhältnis: Als vierte und letzte Größe wird das Preis-/Leistungsverhältnis des entsprechenden Systems ermittelt. Dabei werden die anfallenden Gesamtkosten des Systems bestimmt, dazu gehören die Kosten für die Hardware, Software und anfallende Wartungskosten für die kommenden 5 Jahre. Mit den Gesamtkosten und der ermittelten Leistungsmetrik QphH wird das Preis/Leistungsverhältnis bestimmt. Dieses muss in der aktuellen Landeswährung pro Anfrage pro Stunde angegeben werden (Preis/QphH). Auf diesen Teil der Auswertung wird verzichtet, da das Hauptaugenmerk auf den Performance Messungen liegt. 50

59 5 Auswertung 5.1 Performanceauswertung von NCQ Die Testmessungen zu NCQ haben die in Kapitel Speichervirtualisierung in einem Disksubsystem aufgestellte Theorie bewiesen. Als Grundlage dient die gleiche physikalische Testumgebung mit den festgelegten Rahmenbedingungen. In diesem Testszenario wird ausschließlich die Funktion NCQ einmal im angeschalteten und im ausgeschalten Zustand betrachtet, um die Auswirkungen auf die Performance festzustellen. Da NCQ in Abhängigkeit von der Art des Zugriffes seine Vor- und Nachteile hat, werden die drei definierten Lastprofile mit 8 Anwendungen und je 8 Prozesse getestet. Die Ergebnisse lassen folgenden Schluss zu. Im sequentiellen Lesen sind die Unterschiede mit und ohne NCQ kaum messbar. Werden die Werte ohne NCQ auf 100% normiert, so erreicht man mit NCQ einen Datendurchsatz von +/- 4%. Der Mittelwert von den wichtigen Blockgrößen KB ergibt, dass mit NCQ eine Performancesteigerung von 0,7% vorliegt. Dieser Wert liegt jedoch im Toleranzbereich. Beim sequentiellen Schreiben treten größere Unterschiede auf, vor allem im Bereich von 4 16 KB (siehe Abbildung 23). Der erzielte Datendurchsatz liegt im Bereich von +/- 20%, der Mittelwert ergibt einen Performanceverlust von 0,8%. Datendurchsatz in MB/s (8 Anwendungen - je 8 Prozesse - sequentielles Schreiben) MB/s Windows Server 2008 nativ - FC - NCQ aus 2,2 5,8 12,4 19,1 21,2 36,4 49,7 Windows Server 2008 nativ - FC - NCQ an 2,6 4,9 10,1 19,1 22,1 37,0 50,5 Blockgröße in KB Abbildung 23: Datendurchsatz mit und ohne NCQ (sequentielles Schreiben) 51

60 Die größten Performancezuwächse werden beim zufälligen Datenzugriff erreicht. Die Performancesteigerung liegt im Bereich zwischen 21% bis 48%. Der Datendurchsatz kann im Durchschnitt um 38% gesteigert werden. In Abbildung 24 und 25 sind die IOps und der daraus resultierende Datendurchsatz dargestellt. IOps (8 Anwendungen - je 8 Prozesse - random, 65% Leseanteil) IOps Windows Server 2008 nativ - FC - NCQ aus 915,6 862,0 811,1 709,5 575,2 423,8 273,8 Windows Server 2008 nativ - FC - NCQ an 1105,1 1182,7 1198,5 978,1 765,8 611,6 391,8 Blockgröße in KB Abbildung 24: IOps mit und ohne NCQ (random, 65% Leseanteil) Datendurchsatz in MB/s (8 Anwendungen - je 8 Prozesse - random, 65% Leseanteil) MB/s Windows Server 2008 nativ - FC - NCQ aus 3,6 6,7 12,7 22,2 35,9 53,0 68,5 Windows Server 2008 nativ - FC - NCQ an 4,3 9,2 18,7 30,6 47,9 76,5 98,0 Blockgröße in KB Abbildung 25: Datendurchsatz mit und ohne NCQ (random, 65% Leseanteil) Weil im sequentiellen Lesen und Schreiben kein nennenswerter Performanceverlust festzustellen ist, wurde NCQ für die Testreihen aktiviert, da der Datendurchsatz bei zufälligem Zugriff erheblich gesteigert werden kann. Die Funktion NCQ kann generell bei produktiven Systemen aktiviert werden, da hierdurch keine Nachteile im Datendurchsatz entstehen. Die Funktion NCQ muss bei einigen Herstellern separat angeschaltet werden, hierzu gehören z.b. die Disksubsysteme von Proware. 52

61 5.2 Performanceunterschiede zwischen RAID 6 und RAID 10 Im Bezug auf die im Kapitel Speichervirtualisierung im Disksubsystem betrachteten RAID-Verfahren 6 und 10 werden ebenfalls Performancemessungen durchgeführt. Grundlage für die Tests ist wiederum die bestehende physische Umgebung mit den festgelegten Rahmenbedingungen, getestet wird mit 64 IO-Prozessen. Das Proware Disksubsystem unterstützt kein RAID 10, deshalb werden die zwei Stufen von RAID 10 getrennt. Hierzu werden im Proware Disksubsystem 8 Spiegelsätze aus je 2 Festplatten mit einer Größe von 4 GB erstellt. Auf Betriebssystemebene werden anschließend die 8 Spiegelsätze zu einem RAID 0 verbunden, um ein RAID 10 mit einer Größe von 32 GB zu erhalten. Im sequentiellen Lesen ist RAID 10 um bis zu 22% langsamer als der RAID 6 Verbund (siehe Abbildung 26). Der Mittelwert von den Blockgrößen 4 bis 256 KB ergibt einen Performanceverlust von 8%. Der höhere Lesedurchsatz von RAID 6 ist darin begründet, dass RAID 6 von 14 Platten und RAID 10 von 8 Platten parallel lesen kann. Datendurchsatz in MB/s (8 Anwendungen - je 8 Prozesse - sequentielles Lesen) MB/s % Windows Server 2008 nativ - FC - RAID Windows Server 2008 nativ - FC - RAID Unterschied zwischen RAID 10 und RAID 6 in % Blockgröße in KB 0 Abbildung 26: Vergleich RAID 6 und RAID 10 (sequentielles Lesen) 53

62 Im sequentiellen Schreiben erreicht der RAID 10 Verbund einen gesteigerten Datendurchsatz von 350% bis 700% gegenüber RAID 6. Der Mittelwert von den wichtigen Blockgrößen ergibt eine gesteigerte Gesamtperformance von 550% (siehe Abbildung 27). Datendurchsatz in MB/s (8 Anwendungen - je 8 Prozesse - sequentielles Schreiben) MB/s % Windows Server 2008 nativ - FC - RAID 6 Windows Server 2008 nativ - FC - RAID 10 Unterschied zwischen RAID 10 und RAID 6 in % Blockgöße in KB Abbildung 27: Vergleich RAID 6 und RAID 10 (sequentielles Schreiben) Beim rein zufälligen Zugriff mit 65% Leseanteil liegt die Performancesteigerung von RAID 10 im Bereich von 14% bis 100% über den Werten von RAID 6. Im Mittel ergibt sich ein Anstieg des Datendurchsatzes um 50% (siehe Abbildung 28). Datendurchsatz in MB/s (8 Anwendungen - je 8 Prozesse - random, 65% Leseanteil) MB/s % Windows Server 2008 nativ - FC - RAID 6 Windows Server 2008 nativ - FC - RAID 10 Unterschied zwischen RAID 10 und RAID 6 in % Blockgröße in KB Abbildung 28: Vergleich RAID 6 und RAID 10 (random, 65% Leseanteil) Werden alle Ergebnisse zusammengefasst und die wichtige Blockgröße von 8 KB betrachtet, die bei Datenbanken (MS SQL Server) zum Einsatz kommen, kann in Kombination mit RAID 10 und Datenbanken eine erhebliche Performancesteigerung erreicht werden. Für Backupserver oder Fileserver ist dieses RAID Level eher ungeeignet, da bei RAID 10 immer ein Kapazitätsoverhead von 50% vorliegt. 54

63 5.3 Performanceauswertung von Iometer Aufgetretene Fehler bzw. Entscheidungen bei Performancemessungen Es gibt unterschiedliche Gründe, warum in der folgenden Auswertung der Iometer Messergebnisse einige Systeme fehlen oder Messergebnisse nicht ausgewertet werden. Citrix XenServer 5.5: In der Testumgebung ist es nicht möglich, Performancemessungen mit einem virtualisieren Windows Server 2003 durchzuführen. Der Windows Server 2003 startet bei der Hardwareerkennung ständig neu und lässt sich somit nicht installieren. Dieser Fehler ist von Citrix offiziell bestätigt und tritt in Kombination mit der neuen Nehalem-Architektur und Windows Server 2003 Betriebssystemen auf. An einem Hotfix wird gearbeitet, er stand zu den Messungen jedoch nicht zur Verfügung. Der beschriebene Fehler tritt nur in der iscsi- SAN Umgebung auf, sodass Messwerte im FC-SAN ermittelt werden konnten. Citrix XenServer 5.5 ist zudem die einzige Virtualisierungslösung, die im Lastprofil sequentielles Lesen fehlerhafte Werte liefert. Dies zeigt sich mit erzielten IOps von über und Transferraten jenseits der möglichen Datenrate des iscsi-san bzw. FC-SAN. Desweiteren musste die CPU-Belastung teilweise mit dem Systemmonitor ermittelt werden. Iometer zeigte in Verbindung mit dem Xen Hypervisor das Phänomen, dass die CPU- Belastung bei 0% lag. Microsoft Windows Server 2008 R2 Enterprise RC (x64) mit Hyper-V 2.0: Die Messungen zu Microsoft Windows Server 2008 R2 Enterprise RC (x64) mit Hyper-V 2.0 zeigen, dass eine Auswertung der Ergebnisse nicht repräsentativ wäre. Die CPU-Last ist in allen getesteten Blockgrößen um den Faktor 10 größer als bei allen anderen Virtualisierungslösungen. Die erzielten IOps und der daraus resultierende Datendurchsatz liegt weit unter Hyper-V 1.0. Zurückzuführen ist dies auf die unfertige RC-Version. Aus früheren RC-Versionen und Messungen in der Firma ist bekannt, dass der in RC-Versionen vorhandene Debugging-Code zu Performanceverlusten führt. Aus diesem Grund wurden Messreihen mit der Standalone Version von Hyper-V 2.0 erst gar nicht durchgeführt. 55

64 VMware ESX/ESXi 4.0: Eine erste Messreihe, die zur Validierung des Testsystems genutzt wurde, zeigte, dass fast keine Unterschiede in der Performance zwischen VMware ESX 4.0 und ESXi 4.0 auftreten. Für die endgültigen Performancemessungen wurde deshalb entschieden, aufgrund des schlankeren Hypervisors, ausschließlich den ESXi 4.0 Server einzusetzen. Virtual Iron 4.5: Bei Virtual Iron 4.5 konnten keine Messungen zu Windows Server 2003 ermittelt werden. Sobald die Integrationstools installiert werden, kann das Betriebssystem nicht mehr hochfahren oder stürzt mit einem Blue Screen ab. Da Virtual Iron 4.5 nicht mehr käuflich zu erwerben ist, wurden die Messungen zu Windows Server 2003 weggelassen. 56

65 5.3.2 Vergleich zwischen FC-SAN und iscsi-san im nativen Bereich Dieses Kapitel zeigt die Unterschiede zwischen einem FC-SAN und iscsi-san im nativen Bereich. Da nicht alle Messungen grafisch ausgewertet werden können, wurden bewusst die Ergebnisse herangezogen, bei denen 256 IO-Prozesse anlagen. Es werden zudem nur der erreichte Datendurchsatz, die CPU-Belastung und CPU-Effizienz ausgewertet. Es wird auf die Auswertung der erzielten IOps und der durchschnittlichen Transaktionszeiten verzichtet. Die erzielten IOps, multipliziert mit der Blockgröße, ergeben den Datendurchsatz. Der erzielte Datendurchsatz ist besser einzuordnen als die erreichten IOps. Auch die durchschnittlichen Transaktionszeiten berechnen sich wie folgt und sind nur eine andere Darstellungsform: Die Messungen im iscsi-san und FC-SAN haben gezeigt, dass iscsi speziell bei den Blockgrößen 1 bis 4 KB teils deutlich höhere IOps und somit einen höheren Datendurchsatz erzeugt als FC. Im sequentiellen Lesen (siehe Abbildung 29) ist dies deutlich zu erkennen. Erst ab einer Blockgröße von 8 KB, können sich der Windows Server 2003 und 2008 im FC vom iscsi absetzen. Der Windows Server 2008 erzielt hier bereits einen um 43% höheren Datendurchsatz als im iscsi-san. Bei einer Blockgröße von 16 KB limitiert das 1 GBit Ethernet des iscsi-sans, das eine weitere Auswertung der Ergebnisse verhindert. Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Lesen) MB/s FC-SAN - Windows Server 2003 nativ iscsi-san - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2008 nativ Blockgröße in KB Abbildung 29: Datendurchsatz im FC-SAN und iscsi-san (sequentielles Lesen) 57

66 Theoretisch können über eine 1 GBit Ethernet Verbindung 119,21 MB/s übertragen werden. Der praktische Durchsatz liegt im Maximum bei 113 MB/s. Die 4 GBit FC-Verbindung erreichte bei 256 IO-Prozessen einen maximalen Datendurchsatz von 360 MB/s. Bei nur 64 IO-Prozessen konnte speziell der Windows Server 2008 einen Datendurchsatz von 375 MB/s erreichen. Die theoretische maximale Datenrate einer 4 GBit FC-Verbindung liegt durch die 8b/10b-Kodierung bei 381,47 MB/s und nicht bei den angenommenen 476,84 MB/s. Der Mittelwert von den wichtigen Blockgrößen KB ergibt, dass im sequentiellen Lesen der Windows Server 2003 im iscsi-san 60% und der Windows Server 2008 im iscsi-san 49% vom Datendurchsatz erzielen, gegenüber dem FC-SAN. Dies ist begründet durch die Limitierung der 1 GBit Ethernet-Verbindung. Beim sequentiellen Schreiben kann sich FC bereits bei einer Blockgröße von 4 16 KB absetzen. Bei den Blockgrößen KB erzielt wiederum iscsi einen höheren Datendurchsatz. Dieser Unterschied kann unter anderem durch die zwei verschiedenen RAID-Controller hervorgerufen werden, die je nach Blockgröße unterschiedlich effizient arbeiten. Auffällig ist jedoch, dass der maximale Datendurchsatz im iscsi-san bei ca. 30 MB liegt und bereits bei einer Blockgröße von 64 KB erreicht wird. Im FC-SAN wird bei einer Blockgröße von 256 KB ein Datendurchsatz von 53 MB erreicht. Dass ist gegenüber iscsi eine um 76% gesteigerte Performance. Der Mittelwert über die Blockgrößen KB ergibt, dass iscsi 8% langsamer ist als FC. 60 Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) MB/s FC-SAN - Windows Server 2003 nativ iscsi-san - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2008 nativ Blockgröße in KB Abbildung 30: Datendurchsatz im FC-SAN und iscsi-san (sequentielles Schreiben) 58

67 Beim zufälligen Zugriff mit 65% Leseanteil erzielen die Windows Server im FC-SAN einen gleichen oder höheren Datendurchsatz als im iscsi-san (siehe Abbildung 31). iscsi erzielt im Mittelwert einen 13% geringer Datendurchsatz. 128 Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - random 65% Leseanteil) MB/s FC-SAN - Windows Server 2003 nativ iscsi-san - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2008 nativ Blockgröße in KB Abbildung 31: Datendurchsatz im FC-SAN und iscsi-san (random, 65% Leseanteil) Die weitere Auswertung soll sich speziell mit der CPU-Belastung und der daraus resultierenden CPU-Effektivität auseinander setzen. Es sei hier nochmals erwähnt, dass die FC-Verbindung über einen speziellen FC-HBA und die iscsi-verbindung über den internen Netzwerkkontroller (Intel 82575EB) ohne TOE realisiert wurde. Die CPU-Effektivität berechnet sich wie folgt: Bei sehr kleinen Blockgrößen kann in der Regel eine sehr große Anzahl an IOps erzeugt werden. Dies geht zu Lasten der CPU und ist kein Rückschluss auf die CPU-Last, die durch die Paketierung der Netzwerkpakete erzeugt wird. Um die CPU-Last zu ermitteln, die für die Paketierung verwendet wird, müssen große Blockgrößen betrachtet werden. Die IOps sind hier in der Regel sehr niedrig und der Datendurchsatz sehr hoch. 59

68 In Abbildung 32 ist zu erkennen, dass die CPU-Belastung mit einer FC-HBA und bei dem bereits erwähnten Datendurchsatz von rund 360 MB/s eine CPU-Last von 1 bis 1,5% erzeugt, siehe hierzu die Blockgröße von 256 KB in Abbildung 32 links. Die 1 GBit iscsi-verbindung erzeugt bei einem Datendurchsatz von 113 MB/s eine CPU-Last von 8% (Gesamtlast aller 4- Kerne). Für die Paketierung einer 1 GBit Ethernet-Verbindung wird somit eine CPU-Leistung von ca. 720 MHz benötigt. Anhand dieser Werte trifft die Faustformel nicht zu, dass für ein Bit ein Hz benötigt wird. Nach den ermittelten Werten werden für ein Bit 0,75 Hz benötigt. Die Veränderung ist nachvollziehbar, da sich die Leistung neuer Prozessorarchitekturen pro Hz stetig verbessert. 32,0 16,0 8,0 4,0 2,0 1,0 0,5 CPU-Belastung aller 4 Kerne in % (32 Anwendungen - je 8 Prozesse - sequentielles Lesen) Blockgröße in KB CPU-Effektivität aller 4 Kerne (32 Anwendungen - je 8 Prozesse - sequentielles Lesen) Blockgröße in KB FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ Abbildung 32: CPU-Belastung zwischen FC und iscsi (sequentielles Lesen) Im Mittelwert ist die CPU-Effektivität mit einem FC-HBA gegenüber iscsi mit einer normalen Netzwerkkarte im sequentiellen Lesen um den Faktor 8,5 effizienter. Im sequentiellen Schreiben um den Faktor 6,0 und im zufälligen Zugriff um den Faktor 5,5. In den folgenden Abbildungen 33 und 34 sind zur Vollständigkeit die Werte im sequentiellen Schreiben und dem rein zufälligen Datenzugriff abgebildet. 60

69 CPU-Belastung aller 4 Kerne in % (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) CPU-Effektivität aller 4 Kerne (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) 3,0 2,5 2,0 1,5 1,0 0,5 0, Blockgröße in KB Blockgröße in KB FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ Abbildung 33: CPU-Belastung zwischen FC und iscsi (sequentielles Schreiben) 4,0 3,5 3,0 2,5 2,0 1,5 1,0 0,5 0,0 CPU-Belastung aller 4 Kerne in % (32 Anwendungen - je 8 Prozesse - random 65% Leseanteil) Blockgröße in KB CPU-Effektivität aller 4 Kerne (32 Anwendungen - je 8 Prozesse - random 65% Leseanteil) Blockgröße in KB FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ Abbildung 34: CPU-Belastung zwischen FC und iscsi (random, 65% Leseanteil) 61

70 5.3.3 Performanceauswertung von Microsoft Hyper-V 1.0 Dieses Kapitel vergleicht die Performanceunterschiede von Hyper-V 1.0 in einer FC-SAN und in einer iscsi-san Umgebung. Der Vergleich der anderen Virtualisierungslösungen wird in den drei folgenden Kapiteln betrachtet. Im rein sequentiellen Zugriff erreichen die virtuellen Server nahezu die Leistung der nativen Systeme. Die einzigen Verluste gegenüber dem nativen System verzeichnen die virtualisierten Betriebssysteme im iscsi-san bei der Blockgröße von 4 KB. In Hyper-V zeigt es sich zudem, dass die virtualisierten Systeme im FC bereits ab der Blockgröße von 4 KB einen höheren Durchsatz erreichen als im iscsi-san (siehe Abbildung 35). Der virtualisierte Windows Server 2008 erzielt bei einer Blockgröße von 8 KB einen 43% höheren Datendurchsatz als im iscsi-san Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Lesen) MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - Hyper-V Windows Server 2003 FC-SAN - Hyper-V Windows Server 2008 iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ Blockgröße in KB iscsi-san - Hyper-V Windows Server 2003 iscsi-san - Hyper-V Windows Server 2008 Abbildung 35: Datendurchsatz in Hyper-V 1.0 (sequentielles Lesen) Beim sequentiellen Schreiben treten größere Unterschiede auf (siehe Abbildung 36). Wie bei dem Vergleich zwischen den nativen Systemen, erzielen auch die virtualisierten Systeme im iscsi-san bei den Blockgrößen 32 KB und 64 KB einen höheren Datendurchsatz als im FC- SAN. Bei 64 KB erreicht iscsi eine um 30% gesteigerte Datenrate. Der Datendurchsatz kann bei größeren Blockgrößen nicht weiter gesteigert werden. In der FC Umgebung kann der virtualisierte Windows Server 2008, in den letzten beiden getesteten Blockgrößen, den höchsten Datendurchsatz erzielen und liegt bei 256 KB Blockgröße nur 21% unter dem nativen System. 62

71 Der virtualisierte Windows Server 2003 kann ab einer Blockgröße von 64 KB den Datendurchsatz nicht weiter steigern und bleibt hinter der iscsi-umgebung zurück. Dieses Verhalten tritt sowohl bei 256 IO-Prozessen als auch bei 64 IO-Prozessen auf, siehe hierzu die passenden Messwertreihen im Anhang A8. 60 Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) 50 MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - Hyper-V Windows Server 2003 FC-SAN - Hyper-V Windows Server 2008 iscsi-san - Windows Server 2003 nativ Blockgröße in KB iscsi-san - Windows Server 2008 nativ iscsi-san - Hyper-V Windows Server 2003 iscsi-san - Hyper-V Windows Server 2008 Abbildung 36: Datendurchsatz in Hyper-V 1.0 (sequentielles Schreiben) Im rein zufälligen Zugriff mit 65% Leseanteil zeigen die virtualisierten Systeme im FC-SAN eine deutlich höhere Performance mit steigender Blockgröße als im iscsi-san. Der Windows Server 2008 kann im FC-SAN bei der Blockgröße von 64 KB mit einer um 26% höheren Performance überzeugen. Bei 256 KB wird sogar eine Performancesteigerung von 48% gegenüber dem virtuellen Server im iscsi-san erreicht. Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - random 65% Leseanteil) MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - Hyper-V Windows Server 2003 FC-SAN - Hyper-V Windows Server 2008 iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ iscsi-san - Hyper-V Windows Server 2003 iscsi-san - Hyper-V Windows Server 2008 Blockgröße in KB Abbildung 37: Datendurchsatz in Hyper-V 1.0 (random, 65% Leseanteil) 63

72 5.3.4 Performanceauswertung von VMware ESXi 4.0 Wie bei Hyper-V 1.0 liegen die erzielten Datenraten im sequentiellen Lesen nahe dem nativen Datendurchsatz. Die Messungen ergeben, dass der virtualisierte Windows Server 2003 unter Last im FC-SAN schlechter skaliert als der Windows Server 2008 (siehe Abbildung 38). Der Windows Server 2003 erreicht einen maximalen Datendurchsatz von 314 MB/s. Der Maximalwert beim Windows Server 2008 liegt bei 365 MB/s. In Hyper-V 1.0 erzielen beide virtualisierten Betriebssysteme einen nahezu gleichen Datendurchsatz auf hohem Niveau. Auch bei ESXi 4.0 erzielen die Systeme im FC einen höheren Datendurchsatz als im iscsi. Bei der Blockgröße von 8 KB, erreicht der Windows Server 2008 einen 33% höheren Datendurchsatz als im iscsi Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Lesen) MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - ESXi Windows Server 2003 FC-SAN - ESXi Windows Server 2008 iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ iscsi-san - ESXi Windows Server Blockgröße in KB iscsi-san - ESXi Windows Server 2008 Abbildung 38: Datendurchsatz in ESXi 4.0 (sequentielles Lesen) Im sequentiellen Schreiben liegt der erzielte Datendurchsatz im Bereich der nativen Systeme (siehe Abbildung 39). Eine Ausnahme ist der Windows Server 2003 im iscsi-san. Der erzielte Datendurchsatz liegt im Bereich von 4 32 KB und KB unter den anderen getesteten Systemen. Bei einer Blockgröße von 64 KB liegt er im Bereich der nativen Messwerte. Dieses Verhalten zeigt sich auch bei den Messwertreihen mit 64 IO-Prozessen (siehe Anhang A13). Betrachtet man die virtualisierten Systeme im FC-SAN, erzielt der Windows Server 2008 über alle Blockgröße den Datendurchsatz der nativen Systeme. Der Windows Server 2003 kann ab Blockgrößen von 64 KB den Datendurchsatz nicht weiter steigern. 64

73 Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) 60 MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - ESXi Windows Server 2003 FC-SAN - ESXi Windows Server 2008 iscsi-san - Windows Server 2003 nativ Blockgröße in KB iscsi-san - Windows Server 2008 nativ iscsi-san - ESXi Windows Server 2003 iscsi-san - ESXi Windows Server 2008 Abbildung 39: Datendurchsatz in ESXi 4.0 (sequentielles Schreiben) Bei rein zufälligen Zugriff mit 65% Leseanteil, erreichen die virtualisierten Systeme im FC- SAN einen höheren Datendurchsatz über alle wichtigen Blockgrößen. Im Gegensatz zu Hyper-V 1.0, kann der Windows Server 2003 den Datendurchsatz ab einer Blockgröße von 128 KB nicht weiter steigern und erreicht maximal 51 MB/s. Der Windows Server 2003 erreicht hingegen in Hyper-V 1.0 einen Maximalwert von 65 MB/s. Betrachtet man den Verlauf des Windows Server 2003 im iscsi-san, ist zu erkennen, dass es bei 64 KB zu einem Einbruch von 60% des Datendurchsatzes kommt. Das Verhalten tritt auch bei geringer Last mit 64 IO-Prozessen auf, siehe hierzu die Messwertreihen im Anhang A13. Im weiteren Verlauf skaliert der Windows Server 2003 schlechter als der Windows Server Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - random 65% Leseanteil) MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - ESXi Windows Server 2003 FC-SAN - ESXi Windows Server 2008 iscsi-san - Windows Server 2003 nativ iscsi-san - Windows Server 2008 nativ iscsi-san - ESXi Windows Server 2003 iscsi-san - ESXi Windows Server 2008 Blockgröße in KB Abbildung 40: Datendurchsatz in ESXi 4.0 (random, 65% Leseanteil) 65

74 5.3.5 Performanceauswertung von Virtual Iron 4.5 Aufgrund des beschriebenen Problems mit dem Windows Server 2003, können nur die Messwerte des Windows Server 2008 ausgewertet werden. Im Gegensatz zu Hyper-V 1.0 und ESXi 4.0 liegt der erzielte Datendurchsatz im sequentiellen Lesen deutlich unter den nativen Werten (siehe Abbildung 41). Der maximale Datendurchsatz liegt bei 290 MB/s. Bei den Messungen im iscsi-san ist zu erkennen, dass das virtualisierte System einen höheren Datendurchsatz ermöglicht als das native System. Der Maximalwert beträgt 118 MB/s und liegt demnach nahe der theoretischen Datenrate von 1 GBit/s. Der Grund für die höhere Performance liegt an den unterschiedlichen iscsi Software Initiatoren. Bei den nativen Messungen wurde der Microsoft iscsi Software Initiator verwendet. Die Virtualisierungslösung Virtual Iron 4.5 nutzt hingegen einen eigenen iscsi Software Initiator, der Anhand der Messungen einen höheren Datendurchsatz erreicht. Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Lesen) MB/s Blockgröße in KB FC-SAN - Windows Server 2008 nativ FC- SAN - Virtual Iron Windows Server 2008 iscsi-san - Windows Server 2008 nativ iscsi-san - Virtual Iron Windows Server 2008 Abbildung 41: Datendurchsatz in Virtual Iron 4.5 (sequentielles Lesen) Die Messungen im sequentiellen Schreiben zeigen, dass das virtualisierte System im FC-SAN eine deutlich höhere Performance erzielt, als im iscsi-san (siehe Abbildung 42). Bei einer Blockgröße von 64 KB liegt eine Performancesteigerung von 64% vor. Bei Betrachtung der nativen Werte ist der Virtualisierungsoverhead, speziell bei iscsi, gravierend. Der Mittelwert über die wichtigen Blockgrößen ergibt, dass der virtualisierte Windows Server 2008 im FC- SAN, 81% des Datendurchsatzes gegenüber dem nativen System erreicht. Im iscsi-san werden 36% erreicht. 66

75 Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) MB/s FC-SAN - Windows Server 2008 nativ FC- SAN - Virtual Iron Windows Server 2008 iscsi-san - Windows Server 2008 nativ iscsi-san - Virtual Iron Windows Server Blockgröße in KB Abbildung 42: Datendurchsatz in Virtual Iron 4.5 (sequentielles Schreiben) Im dritten Lastenprofil skaliert der Windows Server 2008 im FC-SAN sowie im iscsi-san identisch. Der maximale Datendurchsatz wird bei 31 bzw. 35,5 MB/s erreicht und kann ab einer Blockgröße von 64 KB nicht weiter gesteigert werden (siehe Abbildung 43). Im FC werden 83% und im iscsi 89% des Datendurchsatzes gegenüber dem nativen Systemen erreicht. Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - random, 65% Leseanteil) MB/s Blockgröße in KB FC-SAN - Windows Server 2008 nativ FC- SAN - Virtual Iron Windows Server 2008 iscsi-san - Windows Server 2008 nativ iscsi-san - Virtual Iron Windows Server 2008 Abbildung 43: Datendurchsatz in Virtual Iron 4.5 (random, 65% Leseanteil) 67

76 5.3.6 Performanceauswertung von Citrix XenServer 5.5 Die Messergebnisse des Citrix XenServer 5.5 zeigen beim sequentiellen Schreiben ein ähnliches Verhalten, wie bei Virtual Iron 4.5 (siehe Abbildung 44). Der Grund ist die Verwendung des gleichen Hypervisors. Ein Leistungsunterschied zwischen der Implementierung im FC und iscsi ist beim Citrix XenServer 5.5 nicht festzustellen. Nur der Windows Server 2003 skaliert im FC tendenziell besser als der Windows Server Der Datendurchsatz kann ab einer Blockgröße von 32 KB nicht nennenswert gesteigert werden. Eine Verringerung des Datendurchsatzes bei größeren Blockgrößen tritt nicht auf, wie es die Messungen bei Virtual Iron zeigten. Wie bei Virtual Iron treten ab der Blockgröße von 64 KB größere Unterschiede zwischen den nativen und virtualisierten Systemen auf. Der Mittelwert von allen Blockgrößen ergibt, dass der Windows Server 2003 im FC 80% des Datendurchsatzes gegenüber dem nativen System erreicht. Der Windows Server 2008 erzielt nur 73%. Im iscsi-san erreicht der Windows Server 2008 hingegen 78%, gegenüber dem nativen System im iscsi. 60 Datendurchsatz in MB/s (32 Anwendungen - je 8 Prozesse - sequentielles Schreiben) 50 MB/s FC-SAN - Windows Server 2003 nativ FC-SAN - Windows Server 2008 nativ FC-SAN - XenServer Windows Server 2003 FC-SAN - XenServer Windows Server Blockgröße in KB iscsi-san - Windows Server 2008 nativ iscsi-san - XenServer Windows Server 2008 Abbildung 44: Datendurchsatz in Citrix XenServer 5.5 (sequentielles Schreiben) Bei Auswertung des dritten Lastenprofils erreichen die virtualisierten Systeme im FC-SAN einen deutlich höheren Datendurchsatz als im iscsi-san (siehe Abbildung 45). Speziell der Windows Server 2008 erzielt im Mittelwert einen 94% höheren Datendurchsatz. Wie beim sequentiellen Schreiben skaliert der virtualisierte Windows Server 2003 tendenziell besser. 68