Betrifft: SQL Server 2008
Werbung
Ausführen von SQL Server 2008 in einer Hyper-V-Umgebung Best Practices und Überlegungen zur Leistung Technischer Artikel zu SQL Server Autoren: Lindsey Allen, Mike Ruthruff, Prem Mehra Technische Lektoren: Cindy Gross, Burzin Patel, Denny Lee, Michael Thomassy, Sanjay Mishra, Savitha Padmanabhan, Tony Voellm, Bob Ward Veröffentlicht: Oktober 2008 Betrifft: SQL Server 2008 Zusammenfassung: Hyper-V in Windows Server 2008 stellt eine leistungsfähige Virtualisierungstechnologie dar, mit der die IT-Abteilungen von Unternehmen Server mit geringer Auslastung konsolidieren, die Gesamtbetriebskosten senken und gleichzeitig die Quality of Service aufrechterhalten und verbessern können. In diesem Dokument werden auf Grundlage von Testszenarien für grundlegende Anwendungen von SQL Server Best Practices für die Ausführung von SQL Server in einer Windows Hyper-V-Umgebung vorgestellt. 1 Copyright Die Informationen in diesem Dokument stellen die zum Datum der Veröffentlichung aktuelle Ansicht der Microsoft Corporation zu den erörterten Themen dar. Da Microsoft auf geänderte Marktbedingungen reagieren muss, dürfen diese Informationen nicht als Verpflichtung von Microsoft ausgelegt werden, und Microsoft kann nicht garantieren, dass alle Informationen in dem Dokument nach dem Datum der Veröffentlichung noch genau zutreffen. Dieses Whitepaper dient ausschließlich Informationszwecken. MICROSOFT ÜBERNIMMT FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT KEINE GEWÄHRLEISTUNG, SEI SIE AUSDRÜCKLICH, KONKLUDENT ODER GESETZLICH. Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf kein Teil dieses Dokuments ohne ausdrückliche schriftliche Erlaubnis der Microsoft Corporation für irgendwelche Zwecke vervielfältigt oder in einem Datenempfangssystem gespeichert oder darin eingelesen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht. Es ist möglich, dass Microsoft Rechte an Patenten bzw. an angemeldeten Patenten, an Marken, Urheberrechten oder sonstigem geistigen Eigentum besitzt, die sich auf den fachlichen Inhalt dieses Dokuments beziehen. Die Bereitstellung dieses Dokuments gewährt Ihnen jedoch keinerlei Lizenzrechte an diesen Patenten, Marken, Urheberrechten oder anderem geistigen Eigentum, es sei denn, dies wurde ausdrücklich durch einen schriftlichen Lizenzvertrag mit der Microsoft Corporation vereinbart. Die in den Beispielen verwendeten Namen von Firmen, Organisationen, Produkten, Domänen, Personen, Orten, Ereignissen sowie E-Mail-Adressen und Logos sind frei erfunden, soweit nichts anderes angegeben ist. Jede Ähnlichkeit mit tatsächlichen Firmen, Organisationen, Produkten, Domänennamen, Personen, Orten, Ereignissen, E-Mail-Adressen und Logos ist rein zufällig. 2 © 2008 Microsoft Corporation. Alle Rechte vorbehalten. Microsoft, Hyper-V, SQL Server, Windows und Windows Server sind Marken der Microsoft-Unternehmensgruppe. Alle anderen Marken sind Eigentum ihrer jeweiligen Inhaber. 3 Inhalt Einführung..................................................................................................................................................... 5 Setup und Konfigurationen von Hyper-V ...................................................................................................... 6 Prüfliste und Überlegungen vor der Installation von Hyper-V ................................................................. 6 Empfehlungen für die Speicherkonfiguration........................................................................................... 7 Methodik und Arbeitsauslastungen der Tests .............................................................................................. 8 Arbeitsauslastungen der Tests .................................................................................................................. 8 Überwachen von SQL Server in Hyper-V-Konfigurationen ..................................................................... 11 Testergebnisse, Beobachtungen und Empfehlungen ................................................................................. 14 Verarbeitungsaufwand bei der Ausführung von SQL Server in Hyper-V ................................................ 14 E/A-Aufwand von Pass-Through-Datenträgern – SQLIO..................................................................... 15 Verarbeitungsaufwand für virtuelle Computer: OLTP-Arbeitsauslastung .......................................... 17 Vergleich der Leistung von Berichtsabfragen ..................................................................................... 22 Datenbankvorgänge ............................................................................................................................ 23 Szenarien der SQL Server-Konsolidierung mit Hyper-V .......................................................................... 28 Vergleichen der Speicherkonfigurationen in einer Konsolidierungsumgebung ................................. 29 Skalierbarkeit der virtuellen Instanz ................................................................................................... 32 Leistung der virtuellen Instanz mit überlasteten CPU-Ressourcen .................................................... 34 Vergleichen von Konsolidierungsoptionen ......................................................................................... 35 Fazit ............................................................................................................................................................. 36 Beobachtungen ....................................................................................................................................... 37 Empfehlungen ......................................................................................................................................... 38 Weitere Informationen ........................................................................................................................... 39 4 Anhang 1: Architektur von Hyper-V ............................................................................................................ 40 Anhang 2: Hardwareanforderungen ........................................................................................................... 44 Arbeitsspeicher ....................................................................................................................................... 44 Prozessoren............................................................................................................................................. 45 Netzwerk ................................................................................................................................................. 45 Speicher .................................................................................................................................................. 46 Anhang 3: Hardwarekonfiguration ............................................................................................................. 47 Einführung Das auf Hypervisortechnologie basierende Virtualisierungsfeature Hyper-V™ in Windows Server® 2008 ist eine dünne Softwareschicht zwischen Hardware und Betriebssystem, die das gleichzeitige Ausführen mehrerer Betriebssysteme ohne Modifizierungen auf einem Hostcomputer ermöglicht. Hyper-V ist eine leistungsfähige Virtualisierungstechnologie, mit der die IT-Abteilungen von Unternehmen Server mit geringer Auslastung konsolidieren, die Gesamtbetriebskosten (Total Cost of Ownership, TCO) senken und gleichzeitig die Quality of Service (QoS) aufrechterhalten und verbessern können. Hyper-V ermöglicht eine größere Anzahl von Entwicklungs- und Testumgebungen, die andernfalls durch die verfügbare Hardware eingeschränkt ist. Bereits unter normalen Umständen ist es schwierig, Hardware so zu dimensionieren, dass bestehende Arbeitsauslastungen konsolidiert werden können und Raum für Wachstum bleibt. Wenn zusätzlich Virtualisierungstechnologie genutzt werden soll, erhöhen sich die Anforderungen an die Kapazitätsplanung. Das vorliegende Dokument gibt Hilfestellung, wie Sie diese Anforderungen erfolgreich meistern können. Hierzu werden zwei wichtige Aspekte im Hinblick auf die Ausführung von Microsoft® SQL Server® in einer Hyper-V-Umgebung behandelt: Zusätzlicher Systemressourcenaufwand durch die Ausführung von SQL Server in einer Hyper-V-Umgebung Skalierbarkeit bei der Ausführung von SQL Server 2008 in Hyper-V 5 In diesem Whitepaper wird eine Reihe von Testkonfigurationen beschrieben, die erprobt wurden und die verschiedene mögliche Szenarien für die Ausführung von SQL Server in Hyper-V darstellen. Ferner werden die Ergebnisse und Beobachtungen erörtert und Empfehlungen gegeben. Die Ergebnisse der Tests haben gezeigt, dass SQL Server 2008 in Hyper-V sehr gute Leistung und Skalierbarkeit bietet. Nach unserer Überzeugung ist Windows Server 2008 Hyper-V bei entsprechender Arbeitsauslastung eine zuverlässige Plattform für SQL Server 2008. Hyper-V-Umgebungen sind optimal für Produktionsszenarien geeignet, sofern die Kapazität des virtuellen Hyper-V-Gastcomputers für die jeweilige Arbeitsauslastung ausreicht. Setup und Konfigurationen von Hyper-V Dieser Abschnitt enthält eine vereinfachte Prüfliste für die Hyper-V-Installation. Weitere Informationen über Hyper-V finden Sie am Ende dieses Whitepapers in der Liste zusätzlicher Whitepaper sowie in Anhang 3, in dem die für die Tests verwendete Hardware beschrieben wird. Prüfliste und Überlegungen vor der Installation von Hyper-V Verwenden Sie einen Serverprozessor, der hardwaregestützte Virtualisierung unterstützt. Es stehen zwei Optionen zur Auswahl: o Intel VT o AMD Virtualization (AMD-V) Stellen Sie sicher, dass die hardwaregestützte Virtualisierung und Datenausführungsverhinderung (Data Execution Prevention, DEP) vorhanden und aktiviert sind. (Sie können dies in der BIOS-Einstellung überprüfen.) Führen Sie die Hyper-V-Serverrolle nur in der Stammpartition des Windows®-Betriebssystems aus. Legen Sie Datenträger, die als Pass-Through-Datenträger für den virtuellen Gastcomputer konfiguriert werden sollen, mit DISKPART oder der Volume-Verwaltung in der Stammpartition als offline fest. Stellen Sie sicher, dass die Integrationskomponenten (Optimierungen oder „Enlightenments“) auf dem virtuellen Gastcomputer installiert sind. Verwenden Sie eine Netzwerkkarte vom Typ „Netzwerkkarte“ statt vom Typ „ältere Netzwerkkarte“, wenn Sie das Netzwerk für den virtuellen Computer konfigurieren. 6 Vermeiden Sie für SQL Server-Bereitstellungen nach Möglichkeit emulierte Geräte. Diese können im Vergleich zu synthetischen Geräten einen erheblich höheren CPU-Verarbeitungsaufwand verursachen. Empfehlungen für die Speicherkonfiguration Wie bei jeder SQL Server-Bereitstellung ist ein E/A-Durchsatz mit ordnungsgemäßer Dimensionierung und Konfiguration von entscheidender Bedeutung für die Leistung. Dies gilt ebenso beim Konfigurieren des Speichers in virtuellen Umgebungen. E/ADurchsatz und Speicherkapazität der Speicherhardware müssen für die aktuellen und zukünftigen Anforderungen der geplanten virtuellen Computer ausreichen. Beachten Sie beim Konfigurieren des Speichers alle Best Practices für die Speicherung vor der Bereitstellung. Hyper-V unterstützt verschiedene Arten von Speicheroptionen. Jede Speicheroption kann über einen IDE- oder SCSI-Controller zugeordnet werden. Für SQL Server-Datenund -Protokolldateien wurde die Konfigurationsoption für den virtuellen SCSI-Controller verwendet. SQL Server ist E/A-intensiv, deshalb wird empfohlen, die Auswahl auf die beiden Optionen mit der höchsten Leistung zu beschränken: Pass-Through-Datenträger Virtuelle Festplatten (Virtual Hard Disks, VHDs) mit fester Größe Dynamische VHDs werden aus Leistungsgründen nicht empfohlen. Der Grund hierfür ist, dass bei dynamischen VHDs die Blöcke auf dem Datenträger zunächst Nullblöcke sind, für diese jedoch kein tatsächlicher Bereich in der Datei vorhanden ist. Lesevorgänge von diesen Blöcken geben einen Block von Nullen zurück. Wenn das erste Mal in einen Block geschrieben wird, muss der Virtualisierungsstapel einen Bereich für den Block in der VHD-Datei reservieren und dann die Metadaten aktualisieren. Außerdem muss jedes Mal, wenn auf einen vorhandenen Block verwiesen wird, die Blockzuordnung in den Metadaten gesucht werden. Hierdurch werden sowohl die Anzahl der Datenträger-E/A-Operationen für Lese- und Schreibaktivitäten als auch die CPU-Nutzung erhöht. Außerdem muss der Serveradministrator aufgrund des dynamischen Wachstums die Datenträgerkapazität überwachen, um sicherzustellen, dass bei zunehmenden Speicheranforderungen genügend Speicherplatz vorhanden ist. VHDs fester Größe können bei Bedarf erweitert werden, jedoch muss hierfür der virtuelle Gastcomputer während des Betriebs heruntergefahren werden. 7 In den Testszenarien für dieses Dokument wurden Speicherkonfigurationen für Pass-ThroughDatenträger und VHDs fester Größe verwendet. In allen Konfigurationen wurden synthetische SCSI-Controller für die virtuellen Gastcomputer verwendet. Weitere Informationen zu der für die Tests verwendeten Hardware finden Sie in Anhang 3. (Hinweis: Synthetische IDE-Controller wurden nicht getestet.) Methodik und Arbeitsauslastungen der Tests Es wurde eine Reihe von Testszenarien gewählt, um Best Practices und Leistungsaspekte für das Ausführen von SQL Server 2008-Anwendungen in einer Hyper-V-Umgebung zu bestimmen. Mit der ersten Gruppe von Testszenarien sollten die Unterschiede zwischen dem Verarbeitungsaufwand einer systemeigenen Umgebung und einer Hyper-V-Umgebung mit virtuellem Gastcomputer ermittelt werden. Mit der zweiten Gruppe von Testszenarien sollte die Skalierbarkeit eines virtuellen Gastcomputers auf einem einzelnen Hostserver untersucht werden. Arbeitsauslastungen der Tests Zum Messen der Leistung der unterschiedlichen Szenarien wurden verschiedene Arbeitsauslastungen verwendet. In diesem Whitepaper bezeichnet systemeigen eine Windows-Installation ohne aktiviertes Hyper-V, Stamm bezeichnet die übergeordnete Partition in einer Windows Hyper-V-Konfiguration mit aktiviertem Hyper-V, und virtueller Gastcomputer bezeichnet den virtuellen Gastcomputer auf der Stammpartition (bzw. übergeordneten Partition) von Windows. Diese Szenarien dienten hauptsächlich den folgenden Zwecken: Vergleichen der Leistung von SQL Server bei der Ausführung im Stamm mit der Ausführung auf einem virtuellen Gastcomputer Vergleichen der Leistung mehrerer SQL Server-Instanzen, die unter einer systemeigenen Windows-Instanz ausgeführt werden, mit der Leistung von einzelnen SQL Server-Instanzen, die auf mehreren virtuellen Gastcomputern ausgeführt werden Beobachten der Skalierbarkeit des SQL Server-Auslastungsdurchsatzes bei zunehmender Anzahl virtueller Gastcomputer, die in einer einzelnen Stammpartition ausgeführt werden 8 Die für diese Tests verwendeten Arbeitsauslastungen, ihre Merkmale sowie die Szenarien für die einzelnen Arbeitsauslastungen werden in der folgenden Tabelle beschrieben. Tabelle 1: Arbeitsauslastungen und Szenarien Arbeitsauslastung Allgemeine Merkmale Entsprechende Szenarien SQLIO Generieren der E/A-Arbeitsauslastung Vergleichen der E/A-Leistung von systemeigener Instanz und virtuellem Gastcomputer OLTP-Arbeitsauslastung OLTP-Arbeitsauslastung, die eine Makleranwendung für die Interaktion mit Kunden simuliert. Weitere Informationen zur Hardwarekonfiguration finden Sie in Anhang 3. Vergleichen der Leistung von Arbeitsauslastungen zwischen systemeigener Instanz, Stamm und virtuellem Gastcomputer Vergleichen mehrerer SQL Server-Instanzen, die unter einer systemeigenen Instanz von Windows ausgeführt werden, mit mehreren virtuellen Gastcomputern, die jeweils unter einer einzelnen SQL ServerInstanz ausgeführt werden Skalierung des Arbeitsauslastungsdurchsatzes bei zunehmender Anzahl von Gastcomputern Berichtsarbeitsauslastung Berichtsabfragen, die umfangreiche CPU- und E/A-Ressourcen nutzen Vergleichen der Leistung von Berichtsabfragen zwischen systemeigener Instanz, Stamm und virtuellem Gastcomputer Betriebsbedingte SQL ServerArbeitsauslastung Vergleichen der Leistung von Datenbankvorgängen zwischen systemeigener Instanz, Stamm und virtuellem Gastcomputer Sicherung/Wiederherstellung, Indexerstellung, DBCC CHECKDB Die folgende Liste enthält spezifischere Informationen über die Szenarios für die einzelnen verwendeten Arbeitsauslastungen: SQLIO-Test: SQLIO ist ein Tool, mit dem die E/A-Kapazität einer ausgewählten Konfiguration bestimmt wird. Mit diesem Testszenario sollte die E/A-Kapazität beim Ausführen eines virtuellen Gastcomputers bestimmt werden, wenn als Speicherkonfiguration Pass-Through-Datenträger verwendet werden. 9 OLTP-Arbeitsauslastung. Merkmale dieses Testszenarios: o Vergleich der Leistung von SQL Server unter einer systemeigenen Instanz von Windows mit der Leistung bei der Ausführung auf einem virtuellen Gastcomputer. Bei diesem Vergleich wurden für die systemeigene Instanz und den virtuellen Gastcomputer äquivalente Hardwarekonfigurationen verwendet. o Vergleich der Leistung von SQL Server unter Verwendung verschiedener Speicherkonfigurationen für Daten- und Protokolldateien. Vergleiche der Pass-Through-Datenträger-Konfigurationen mit VHD-Konfigurationen sowie unterschiedlichen zugrunde liegenden Speicherarraykonfigurationen (d. h. Vergleich der Konfiguration für freigegebenen Speicher mit der Konfiguration für dedizierten Speicher). o Vergleich der Leistung mehrerer SQL Server-Instanzen, die unter einer systemeigenen Instanz von Windows ausgeführt werden, mit einer entsprechenden Anzahl von virtuellen Gastcomputern, die jeweils für eine einzelne Instanz von SQL Server konfiguriert sind. o Beobachtung der Skalierung der Arbeitsauslastung, wenn der Stammpartition eines einzelnen physischen Servers weitere virtuelle Gastcomputer hinzugefügt werden. In diesem Fall wurden folgende Fälle betrachtet: Die Anzahl physischer CPU-Kerne entsprach der Summe logischer CPU-Kerne für alle virtuellen Gastcomputer. Die Anzahl physischer CPU-Kerne war kleiner als die Summe der logischen CPU-Kerne aller virtuellen Gastcomputer (überlastete CPU-Ressourcen). Berichtsarbeitsauslastung: In diesem Szenario wird die Leistung von SQL Server unter einer systemeigenen Windows-Instanz mit der Leistung von SQL Server auf einem virtuellen Gastcomputer mit äquivalenter Hardwarekonfiguration verglichen. Datenbankvorgänge: In diesem Szenario wird die Leistung von SQL Server unter einer systemeigenen Windows-Instanz mit der Leistung von SQL Server auf einem virtuellen Gastcomputer mit äquivalenter Hardwarekonfiguration verglichen. In den Szenarien mit OLTP-Arbeitsauslastung wurden verschiedene Arbeitsauslastungsgrade verwendet, um Verhaltensunterschiede bei unterschiedlicher CPU-Auslastung zu beobachten. Details der unterschiedlichen Arbeitsauslastungsgrade werden weiter unten in diesem Whitepaper erörtert. 10 Überwachen von SQL Server in Hyper-V-Konfigurationen Wenn Sie mit Windows System Monitor („Perfmon“) die Leistung von SQL Server in Hyper-V-Konfigurationen überwachen, ist Verschiedenes zu beachten. Um zuverlässige Messungen der Ressourcennutzung zu erhalten, müssen Hyper-V-Leistungsindikatoren verwendet werden, die von Windows in der Stammpartition verfügbar gemacht werden. Eine ausführliche Erläuterung der Hyper-V-Überwachung würde den Rahmen dieses Dokuments sprengen. Weitere Informationen finden Sie in Anhang 3. Während der Tests ergaben sich unterschiedliche Erkenntnisse hinsichtlich der Leistungsüberwachung. Die Mehrzahl der Überlegungen betrifft Messungen der CPU-Nutzung. Wenn Sie die CPU-Auslastung auf einem Server überwachen, auf dem Hyper-V ausgeführt wird, sollten Sie für die Stammpartition verfügbar gemachte Hyper-V-Prozessorleistungsindikatoren verwenden. Hyper-V macht drei primäre Leistungsindikatoren bezüglich der CPU-Auslastung verfügbar: Logischer Prozessor für Hyper-V-Hypervisor: Liefert die präzisesten Daten zur Summe der auf dem gesamten physischen Server genutzten CPU-Ressourcen. Virtueller Prozessor des Hyper-V-Hypervisorstamms: Liefert das präziseste Maß für die von der Stammpartition genutzten CPU-Ressourcen. Virtueller Prozessor von Hyper-V-Hypervisor: Liefert das präziseste Maß der CPU-Nutzung für bestimmte virtuelle Gastcomputer. Die herkömmlichen Leistungsindikatoren vom Typ % Prozessorzeit können in der Stammpartition überwacht werden. Da jedoch Virtualisierungsschichten vorhanden sind, die nicht für diese Prozessorleistungsindikatoren verfügbar gemacht werden, stellen sie die Nutzung der CPU-Ressourcen möglicherweise nicht präzise dar. Messen Sie zum Überwachen der Leistung die CPU-Nutzung mit Hyper-V-Leistungsindikatoren auf jedem Server, auf dem die Rolle für Hyper-V mit aktiviertem Hypervisor ausgeführt wird. Weitere Informationen finden Sie im Blog von Tony Voellm zur Hyper-V-Leistungsüberwachung. Die einzelnen Indikatoren werden in Abbildung 1 dargestellt. In dieser Abbildung wird die obere Gruppe von Leistungsindikatoren (\\SQLBP08R900) in der Stammpartition überwacht, und die untere Gruppe von Leistungsindikatoren (\\sqlhv1) wird aus der Perspektive des Gastcomputers überwacht. Beachten Sie, dass in diesem Beispiel 16 physische CPU-Kerne für die Stammpartition und vier logische CPU-Kerne für den virtuellen Gastcomputer sichtbar sind. Beachten Sie außerdem, dass in der Stammpartition zwei virtuelle Gastcomputer ausgeführt 11 werden, in der Abbildung aus Platzgründen jedoch nur ein virtueller Gastcomputer gezeigt wird. Die vier Leistungsindikatoren für die logischen Prozessoren des zweiten virtuellen Computers nehmen die gesamte Breite der Abbildung ein. Abbildung 1: Hyper-V-Leistungsindikatoren Weitere Informationen zur Überwachung und zu diesen spezifischen Themen finden Sie im Virtualisierungsabschnitt der Richtlinien für die Leistungsoptimierung von Windows Server 2008 und in den Blogs zu Hyper-V-Leistungsindikatoren. Für die Überwachung von SQL Server müssen bei der Ausführung auf einem virtuellen Gastcomputer keine besonderen Überlegungen berücksichtigt werden. Im Allgemeinen messen SQL Server-Leistungsindikatoren entweder die Nutzung (SQL Server-spezifische Ressourcen) oder den Durchsatz. Außerdem werden SQL Server-Leistungsindikatoren nicht für die Stammpartition verfügbar gemacht, wenn sie auf einem virtuellen Gastcomputer ausgeführt werden. Sie müssen auf dem virtuellen Gastcomputer überwacht werden. Das Messen der E/A-Leistung erfolgt je nach Konfiguration des Gastcomputers auf unterschiedliche Weise. Die Latenzzeit ist ein Maß für die verstrichene Zeit, und sie kann vom Stamm oder vom Gastcomputer mit ausreichender Genauigkeit gemessen werden. Es folgen einige allgemeine Überlegungen zur Überwachung der Datenträgerleistung: 12 Sie können die E/A-Leistung mit Indikatoren für logische oder physische Datenträger auf dem virtuellen Gastcomputer überwachen. Es wurden äußerst geringe Unterschiede zwischen den Werten der Leistungsindikatoren beobachtet, die von der Stammpartition und vom virtuellen Gastcomputer gemessen wurden. Jedoch wurden bei der Überwachung vom virtuellen Gastcomputer geringfügig höhere Latenzzeitwerte („Mittlere Sek./Lesevorgänge“ und „Mittlere Sek./Schreibvorgänge“) als bei der Überwachung vom Stamm beobachtet. Der Grund hierfür ist, dass der Abschluss von E/A-Vorgängen aus der Perspektive des virtuellen Computers möglicherweise etwas länger dauert. Wenn der Speicher des virtuellen Gastcomputers als Pass-Through-Datenträger konfiguriert ist, ist der Datenträger auf der Ebene der Stammpartition offline, und er wird von den Leistungsindikatoren des logischen Datenträgers in der Stammpartition nicht erfasst. Zum Überwachen der Leistung von Pass-Through-Datenträgern in der Stammpartition müssen die Leistungsindikatoren für physische Datenträger verwendet werden. Zum Zeitpunkt der Tests gab es bekannte Probleme bei Windows Server 2008Leistungsindikatoren für physische Datenträger, wenn Multipfadlösungen verwendet wurden. Die Probleme wurden mit der neuesten allgemeinen Vertriebsversion von System Center Virtual Machine Manager behoben. Wenn virtuelle Gastcomputer so konfiguriert sind, dass für die Speicherung VHD-Dateien verwendet werden, und diese VHD-Dateien auf gewöhnlichen physischen Datenträgern gespeichert werden, liefert die Überwachung der Datenträgerleistungsindikatoren vom virtuellen Gastcomputer aus Detailinformationen zum E/A-Verhalten für die jeweilige VHD. Die Überwachung des Volumes in der Stammpartition, das alle VHD-Dateien enthält, liefert Aggregatwerte für alle E/A-Vorgänge, die für den Datenträger oder das Volume ausgegeben werden. In Tabelle 2 werden die Typen von Leistungsindikatoren gezeigt, deren Werte während Arbeitsauslastungen für den die OLTP-Arbeitsauslastung betreffenden Teil der Tests erfasst wurden. Sie veranschaulicht die Unterschiede bei den Werten der Leistungsindikatoren bei Überwachung vom virtuellen Gastcomputer im Vergleich zur Überwachung der Stammpartition. 13 Tabelle 2: Leistungsindikatoren und Arbeitsauslastungen Ausgangspunkt der Indikatormessung Virtueller Gastcomputer Stammpartition Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Transactions/sec 352 546 658 Batches/sec 565 897 1075 % Processor Time 34,2 65,3 84,2 % Privilege Time 5,1 8 8,4 Logical - Avg. Disk sec/Read (_Total) 0,005 0,006 0,007 Logical - Disk Reads/sec (_Total) 1053 1597 1880 % Processor Time 4,9 7,8 11,2 % Privilege Time Hyper-V Logical Processor – %Hypervisor Run Time Hyper-V Logical Processor – %Total Run Time Hyper-V Logical Processor – %guest virtual machine Run Time 3,6 6,1 7,3 4 4,8 4,3 39,1 68,7 86,5 35,1 63,9 82,1 Physical – Avg. Disk sec/Read (_Total) 0,005 0,006 0,006 Physical – Disk Reads/sec (_Total) 1053 1597 1880 Batches per CPU % (Batches/sec / %Guest virtual machine Run Time) 16,1 14 13,1 Leistungsindikator Hinweis: In der Stammpartition gemessene Hyper-V-Leistungsindikatoren sind die Aggregation aller ausgeführten virtuellen Gastcomputer. Testergebnisse, Beobachtungen und Empfehlungen In diesem Abschnitt werden die Testergebnisse beschrieben und analysiert. Er enthält außerdem Empfehlungen und Beobachtungen zum Ausführen von SQL Server in einer virtuellen Umgebung. Der Abschnitt besteht aus zwei Teilen: Im ersten Teil wird der grundlegende Ressourcenaufwand erläutert, der durch Ausführen von SQL Server in einer Hyper-V-Umgebung verursacht wird, und im zweiten Teil werden die Auswirkungen des Konsolidierens von SQL Server als virtuelle Instanzen erläutert. Verarbeitungsaufwand bei der Ausführung von SQL Server in Hyper-V Mit der ersten Gruppe von Testszenarien sollte der Verarbeitungsaufwand bei der Ausführung von SQL Server in einer sicheren Hyper-V-Umgebung ermittelt werden. Es wurden drei Typen von Basistests ausgeführt: in einer systemeigenen Windows-Umgebung mit deaktiviertem 14 Hyper-V, in der Stammpartition mit aktiviertem Hyper-V und auf einem einzelnen virtuellen Gastcomputer. In allen Fällen wurde die gleiche Hardwarekonfiguration verwendet. Hinweis: Systemeigene Instanz bezeichnet eine SQL Server-Instanz, die in einer systemeigenen Windows-Umgebung ausgeführt wird, und virtuelle Instanz bezeichnet eine SQL Server-Instanz, die auf einem virtuellen Gastcomputer ausgeführt wird. Dieser Abschnitt enthält die folgenden Testszenarien: Bestimmen des E/A-Aufwands von Pass-Through-Datenträgern mithilfe von SQLIO Vergleichen der Leistung der OLTP-Arbeitsauslastung in einer einzelnen systemeigenen Instanz und einer virtuellen Instanz Vergleichen der Leistung von Berichtsabfragen in einer systemeigenen Instanz und einer virtuellen Instanz Beobachtungen der Auswirkungen der Virtualisierung auf häufige Datenbankvorgänge: o Komprimierte Datensicherung und Wiederherstellung o Indexerstellung o DBCC CHECKDB E/A-Aufwand von Pass-Through-Datenträgern – SQLIO Der E/A-Aufwand stellte bislang in virtuellen Umgebungen ein Problem dar. Er konnte bei E/A-intensiven Anwendungen wie SQL Server Fehler bei der Ausführung verursachen. Für Hyper-V wird eine andere Technologie verwendet. Um den optimalen Fall zu untersuchen, wurde im ersten Testszenario der E/A-Aufwand der besten E/A-Konfiguration ermittelt, d. h. mit dedizierten Pass-Through-Datenträgern. Die Konfiguration mit Pass-Through-Datenträgern wurde gewählt, weil diese den kürzesten Codepfad vom Host zum E/A-Subsystem aufweist. In den Tests wurde der Stammpartition und dem virtuellen Gastcomputer dieselbe Anzahl physischer Spindeln zugeordnet. Wiederholte Tests verschiedener nach dem Zufallsprinzip ausgewählter sowie sequenzieller E/A-Anforderungen ergaben, dass bei Verwendung von Hyper-V mit Pass-Through-Datenträgern nahezu kein zusätzlicher E/A-Aufwand auftritt. Weitere Informationen, einschließlich einer detaillierten Leistungsanalyse von Pass-ThroughDatenträgern und virtuellen Festplatten, finden Sie in dem Whitepaper „Windows Server 2008 Hyper-V Virtual Hard Disk and Pass-through Disk Performance“ (Leistung von Windows 15 Server 2008 Hyper-V mit virtuellen Festplatten und Pass-Through-Datenträgern), das in Kürze veröffentlicht wird. Weitere Informationen zur Analyse der Speicherleistung von Hyper-V finden Sie außerdem hier (http://blogs.msdn.com/tvoellm/archive/2008/09/24/what-hyper-v-storage-is-best-for-you-show-methe-numbers.aspx). Speicherkonfiguration Die Konfiguration der Pass-Through-Datenträger für den Stamm und den virtuellen Computer war identisch. Jede Konfiguration wurde mit logischen Gerätenummern (Logical Unit Numbers, LUNs) aus dem Speicherarray dargestellt, in dem die gleiche Anzahl von physischen Datenträgerressourcen verwendet wurde. Die LUNs waren nicht auf Datenträgerebene freigegeben, d. h., für die LUNs waren keine Spindeln freigegeben. In Abbildung 2 wird die jeweilige Konfiguration dargestellt. Abbildung 2: Speicherkonfiguration für Pass-Through-Datenträger Leistung der Pass-Through-Konfiguration Um eine Basislinie des Durchsatzes zu bestimmen, wurden für alle virtuellen Gastcomputer und den Stamm die gleichen SQLIO-Tests durchgeführt. In Abbildung 3 und 4 werden die Ergebnisse der Tests für nach dem Zufallsprinzip ausgewählte und sequenzielle E/AAnforderungen mit SQLIO veranschaulicht. Für dieses Testszenario wurden die beiden üblichen SQLIO-Werte (8.000 und 64.000) verwendet. 16 8.000 nach Zufallsprinzip – Stamm und VC E/A pro Sekunde 4,000 3,500 3,000 Systemeigenes BS 2,500 2,000 VC 1,500 1,000 500 0 Schreiben Lesen Abbildung 3: Pass-Through mit 8.000 nach dem Zufallsprinzip ausgewählten E/A-Anforderungen SQLIO, 64.000 sequenziell – Stamm und VC 10,000 8,000 Systemeigenes BS 6,000 VC 4,000 2,000 0 Schreiben Lesen Abbildung 4: Pass-Through mit 64.000 sequenziellen E/A-Anforderungen Verarbeitungsaufwand für virtuelle Computer: OLTP-Arbeitsauslastung Mit diesem Testszenario sollten die Auswirkungen der Ausführung von SQL Server 2008 auf einem virtuellen Computer gemessen werden. Hierfür wurde eine OLTP-Arbeitsauslastung verwendet, die eine Makleranwendung simuliert. Informationen zu der für diesen Test verwendeten Hardwarekonfiguration finden Sie in Anhang 3. Es wurden drei 17 Arbeitsauslastungsgrade für die Basislinie, den Stamm und den virtuellen Gastcomputer ausgeführt. Bei der Basislinie handelt es sich um das Ausführen der SQL Server-Instanz auf dem systemeigenen Server mit deaktiviertem Hyper-V. Zu diesem Zweck wurde die Einstellung „hypervisorlaunchtype off“ („bcdedit /set hypervisorlaunchtype off“) verwendet. Damit diese Einstellung wirksam wird, ist ein Neustart von Windows erforderlich. Die Belastungsgrade des Testszenarios wurden anhand des Prozentsatzes der CPU-Auslastung definiert. Da in Produktionsumgebungen normalerweise keine vollständige CPU-Sättigung eintritt, wurde für die CPU-Belastung ein Zielbereich von 20 % bis 80 % festgelegt. Die Zielwerte der CPU-Auslastung für die einzelnen Arbeitsauslastungsgrade sind in Tabelle 3 definiert. Tabelle 3: Zielwerte der CPU-Auslastung Testarbeitsauslastung OLTP – niedrig OLTP – mittel OLTP – hoch Ungefährer CPU-Zielwert 30 % 50 % - 60 % 80 % Da die virtuellen Hyper-V-Gastcomputer bis zu vier logische Prozessoren unterstützen, wurde zum direkten Vergleich der Host über die BIOS-Einstellung für die Verwendung von vier Kernen konfiguriert (NUMPROC=4). Um die Auswirkungen der Speicherkonfiguration zu ermitteln, wurden zwei virtuelle Computer mit den beiden für SQL Server-Arbeitsauslastung empfohlenen Typen der Hyper-V-Speicherkonfiguration (Pass-Through-Datenträger und VHDs fester Größe) konfiguriert. Auswirkungen auf Durchsatz und Prozessor Die Basistests mit drei Arbeitsauslastungsgraden wurden in einer systemeigenen Windows Server 2008-Umgebung mit deaktivierter Hyper-V-Rolle ausgeführt. Der gleiche Satz von Arbeitsauslastungen wurde für die Stammpartition mit aktiviertem Hyper-V, für einen mit Pass-Through-Datenträgerspeicherung konfigurierten Gastcomputer und anschließend für einen virtuellen Gastcomputer mit VHD-Speicher fester Größe ausgeführt. 18 In Tabelle 4 werden die Batchanforderungen im Verhältnis zum CPU-Prozentwert sowie der Aufwand für alle Testfälle gezeigt. In allen Testfällen dieses Szenarios war die Skalierbarkeit des Systems sehr gut. Jede Konfiguration erzielte den gleichen Durchsatz, wobei der virtuelle Computer einen höheren CPU-Aufwand zum Erreichen des gleichen Durchsatzes verursachte. Pass-Through-Datenträger und VHDs mit fester Größe wiesen bei Abweichungen des Aufwands von unter 1 Prozent eine nahezu gleiche Leistung auf. In Tabelle 4 wird der durch Ausführen der OLTP-Arbeitsauslastung auf dem virtuellen Computer verursachte CPU-Verarbeitungsaufwand dargestellt. Der Prozentsatz des Verarbeitungsaufwands war bei der geringeren Arbeitsauslastung höher. Dem virtuellen Computer ist ein bestimmter fester Umfang an Arbeits- und CPU-Auslastung zugeordnet. Wenn dieser Umfang auf eine geringere Arbeitsauslastung verteilt wird, ist der Prozentsatz des Verarbeitungsaufwands höher. Als Maß für die Leistung wurde die folgende Formel verwendet: Batch/CPU% = Batchanforderungen/Sekunde dividiert durch den Prozentsatz der CPU-Auslastung Tabelle 4: CPU-Verarbeitungsaufwand des virtuellen Computers beim Ausführen von OLTP-Arbeitsauslastungen Niedrig Basislinie1 2 Stamm VC_PT 3 VC_VHD 1. 4 Mittel Batchanf./s Batch/ CPU% 566 19,2 0,00 % 908 16 566 17,5 8,85 % 907 565 16,1 16,15 % 563 15,7 18,23 % Aufwand Batchanf./s Batch/ CPU% 0,00 % 1069 14,8 0,00 % 14,8 7,50 % 1113 13,5 8,78 % 897 14 12,50 % 1075 13,1 11,49 % 876 13,9 13,13 % 1029 13,2 10,81 % Batchanf./s Batch/ CPU% Hoch Aufwand Aufwand5 Basislinie: Eine systemeigene Windows Server 2008-Umgebung mit deaktivierter Hyper-V-Rolle. Der virtuelle Netzwerkswitch ist nicht deaktiviert. 2. Stammpartition: Eine Stammpartition in Windows Server 2008 mit aktiviertem Hyper-V. 3. VC_PT: Ein virtueller Gastcomputer, der mit Pass-Through-Datenträgern, vier logischen Prozessoren und 14 GB RAM konfiguriert ist. 19 4. VC_VHD: Ein virtueller Gastcomputer, der mit VHDs fester Größe, vier logischen Prozessoren und 14 GB RAM konfiguriert ist. 5. Der Aufwand wird durch Vergleichen mit der Basislinie berechnet ((Basislinienbatches/CPU – VCBatches/CPU)/Basislinienbatches/CPU) Relativer Durchsatz (Batches/s/% Prozessorzeit) Relativer Durchsatz – Batches pro CPU% (Batches pro Sekunde / Summe % Prozessorzeit) 20.0 18.0 16.0 14.0 Systemeigenes BS – Hyper-V deaktiviert 12.0 Stammpartition – Hyper-V aktiviert 10.0 8.0 Einzelner VC (PassThrough-Datenträger) 6.0 Einzelner VC (VHD fester Größe) 4.0 2.0 0.0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 5: Relativer Durchsatz – Batchanforderung pro CPU% Speicherkonfiguration und Leistung Beide virtuellen Gastcomputer wiesen die gleiche zugrunde liegende Datenträgerkonfiguration für SQL Server-Daten- und -Protokolldateien auf, daher sind diese direkt vergleichbar. (Die Details der jeweiligen physischen Konfiguration werden weiter oben in diesem Dokument beschrieben. Sie sind mit der für die SQLIO-Tests verwendeten Konfiguration identisch.) Bei Verwendung von VHD-Dateien waren diese die einzigen Dateien auf den physischen Datenträgern, die in der Stammpartition verfügbar gemacht wurden. Wenn für die Speicherung von SQL Server-Daten- und -Protokolldateien VHDs verwendet wurden, wurde eine geringfügig 20 höhere Latenzzeit beobachtet, die sich geringfügig auf den Arbeitsauslastungsdurchsatz auswirkte, wie in Abbildung 5 gezeigt. Die Verwendung von VHDs als Konfiguration für virtuelle Gastcomputer bietet Vorteile bei der Bereitstellung und Verwaltung. Bei geringer Belastung weisen Pass-Through-Datenträger und VHDs fester Größe keinen Unterschied hinsichtlich Durchsatz/Leistung auf. Bei zunehmender Arbeitsauslastung ist ein geringer Leistungsvorteil von Pass-Through-Datenträgern zu beobachten. In Abbildung 6 wird die in diesem OLTP-Testszenario aufgezeichnete Leseleistung dargestellt. Lesevorgänge pro Sekunde für Datenmengen 2000 1800 Datenträger-Lesevorgänge/s 1600 1400 Systemeigenes BS – Hyper-V deaktiviert Stammpartition – Hyper-V aktiviert Einzelner VC (PassThrough-Datenträger) Einzelner VC (VHD fester Größe) 1200 1000 800 600 400 200 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 6: Datenmengen (Lesevorgänge pro Sekunde) In Abbildung 7 wird die durchschnittliche Datenträgerlatenzzeit aller ausgeführten Tests gezeigt. Erwartungsgemäß weisen VHDs die größte Latenzzeit auf, während die Latenzzeit der PassThrough-Datenträger gleich der Latenzzeit des systemeigenen Speichers ist. Die Werte für die Datenträgerlatenzzeit der VHDs wurden von den Leistungsindikatoren der virtuellen Gastcomputer gemeldet. Es wurden jedoch keine Unterschiede zwischen diesen Werten und den von der Stammpartition gemeldeten Werten festgestellt. 21 Durchschnittliche Datenträgerlatenzzeit in Sekunden 0.009 Mittlere Sek./Lesevorgänge 0.008 Systemeigenes BS – Hyper-V deaktiviert 0.007 0.006 Stammpartition – Hyper-V aktiviert 0.005 0.004 Einzelner VC (PassThrough-Datenträger) 0.003 0.002 Einzelner VC (VHD fester Größe) 0.001 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 7: Durchschnittliche Datenträgerlatenzzeit Vergleich der Leistung von Berichtsabfragen Berichtsabfragen sind im Allgemeinen lesende Abfragen mit langer Ausführungszeit, die umfangreiche CPU- und E/A-Ressourcen nutzen. Normalerweise ist die Benutzerparallelität bei der Ausgabe von Abfragen dieses Typs im Vergleich zu OLTP-Arbeitsauslastungen gering. In diesem Testszenario wurden vier Berichtsabfragen sequenziell ausgeführt, um die Ressourcennutzung und die Zeit bis zum Abschluss des Vorgangs zu messen. Die vier Abfragen waren E/A-intensiv und verursachten aufgrund von Aggregationen eine hohe CPU-Last. Die sp_configure-Einstellung „Max. Grad an Parallelität“ war auf 0 festgelegt, sodass alle verfügbaren CPU-Ressourcen von den Abfragen genutzt wurden. 22 Bei der Ausführung der Abfragen auf virtuellen Gastcomputern, in systemeigenen Instanzen und in der Stammpartition wurden nur minimale Unterschiede festgestellt. Bei den virtuellen Gastcomputern wurde eine relativ geringe Zunahme des Verarbeitungsaufwands beobachtet. In Abbildung 8 werden die Ausführungszeit und die CPU-Nutzung der Abfragen dargestellt. 700 70 650 60 600 550 600 605 620 630 50 40 500 30 450 400 20 350 10 300 % Gastlaufzeit Zeit bis zum Abschluss (Sekunden) Berichtsabfragen mit MAXDOP 0 Gesamtzeit und % genutzte CPU-Ressourcen Gesamtzeit (Sekunden) Hyper-V – % Gastlaufzeit 0 Systemeigenes Stammpartition BS – Hyper-V – Hyper-V deaktiviert aktiviert Gast (PassThrough) Gast (VHD) Abbildung 8: Leistung von Berichtsabfragen Datenbankvorgänge Einige Datenbankvorgänge sind relativ CPU-intensiv. Die Testergebnisse in diesem Abschnitt betreffen die Auswirkungen der Virtualisierung auf Datenbankvorgänge, z. B. Sichern und Wiederherstellen mit Komprimierung, Indexerstellung und DBCC CHECKDB. Sichern und Wiederherstellen Bei den Sicherungs- und Wiederherstellungsvorgängen wurde eine Dateifreigabe auf einem anderen physischen Server als Ziel für die Sicherungsdateien verwendet. In diesem Fall war die Sicherung und Wiederherstellung durch die Bandbreite des Netzwerks und nicht durch den Datenträger oder den Prozessor beschränkt. Für den Test des Sicherungsvorgangs wurde die systemeigene Sicherungskomprimierung von SQL Server 2008 verwendet. 23 Im Vergleich zu dem gleichen Vorgang in einem systemeigenen Betriebssystem wies der Durchsatz bei der Sicherung eine um 10-15 % geringere Leistung bei beachtlicher Zunahme der CPU-Auslastung auf. Beim Durchsatz der Wiederherstellung wurde ein vergleichbarer Leistungsabfall beobachtet. Die Verringerung des Durchsatzes wird durch die Netzwerkbelastung verursacht, die auftritt, wenn Vorgänge auf dem virtuellen Gastcomputer in großem Umfang Netzwerkressourcen nutzen. In den Tests erwies sich dies bei Betrachtung des Aufwands, der durch die Ausführung von SQL Server auf einem virtuellen Hyper-V-Gastcomputer verursacht wird, als der gravierendste Faktor. Er war weitaus signifikanter als jeder für E/A- oder CPU-Vorgänge festgestellte Aufwand. In diesem Testszenario wurde während der Sicherung und Wiederherstellung ein Netzwerkdurchsatz von 50-60 MB pro Sekunde beobachtet. Sowohl der für SQL Server verwendete Server als auch der Server, auf dem die Netzwerk-Dateifreigabe für das Sicherungsziel verfügbar gemacht wurde, verfügten über eine Netzwerkkarte mit 1 GB/s. Der Durchsatz bei Sicherung und Wiederherstellung betrug ca. 100 MB pro Sekunde. Die Werte stammen aus der Ausgabe der Sicherung und Wiederherstellung von SQL Server. Bei diesem Vorgang wurde die Komprimierung verwendet. Aus diesem Grund ist der gemeldete Durchsatz weitaus höher als der Netzwerkdurchsatz, den die Netzwerkkonfiguration ermöglicht. In Abbildung 9, 10 und 11 wird der Durchsatz von Sicherung und Wiederherstellung der systemeigenen Instanz, der Stammpartition und der virtuellen Computer gezeigt, die mit Pass-Through-Datenträgern und VHDs fester Größe konfiguriert sind. Der relative Durchsatz auf der y-Achse wird berechnet, indem die Summe von Megabytes pro Sekunde durch den Mittelwert der gesamten CPU-Prozentwerte dividiert wird. Die Ursache für den geringfügig höheren Durchsatz der Wiederherstellung ist die Schreibleistung der Zieldateifreigabe (die Schreibleistung dieser Freigabe ist etwas höher, weil RAID 5 verwendet wird). 24 Relativer Durchsatz – Datensicherung und Wiederherstellung (Summe MB pro Sekunde / Summe Durchschnitt CPU%) Relativer Durchsatz 6.00 Systemeigenes BS – Hyper-V deaktiviert 5.00 4.00 Stammpartition – Hyper-V aktiviert 3.00 Gast (Pass-Through) 2.00 1.00 Gast (VHD) 0.00 Sicherung Wiederherstellung Abbildung 9: Vergleich des Durchsatzes von Sicherung und Wiederherstellung Sicherung – Netzwerkdurchsatz und CPU 70,000,000 60,000,000 100 64,175,343 56,608,244 56,353,835 56,084,247 90 80 50,000,000 70 60 40,000,000 50 30,000,000 40 30 20,000,000 Netzwerkschnittstelle, gesendete Bytes/s Summe % CPU-Zeit 20 10,000,000 10 0 0 Systemeigenes BS Stammpartition – – Hyper-V Hyper-V aktiviert deaktiviert Gast (PassThrough) Gast (VHD) Abbildung 10: Netzwerkauslastung und CPU-Auslastung bei der Sicherung 25 Wiederherstellung – Netzwerkauslastung und CPU 90,000,000 85,472,730 100 75,673,694 80,000,000 70,000,000 90 61,530,273 60,000,000 80 59,206,576 70 60 50,000,000 50 40,000,000 Netzwerkschnittstelle, empfangene Bytes/s 40 30,000,000 30 20,000,000 20 10,000,000 10 0 Summe % CPU-Zeit 0 Systemeigenes BS Stammpartition – – Hyper-V Hyper-V aktiviert deaktiviert Gast (PassThrough) Gast (VHD) Abbildung 11: Netzwerkauslastung und CPU-Auslastung bei der Wiederherstellung Tabelle 5 enthält die im Testszenario gesammelten Daten. Tabelle 5: Durchsatz von Sicherung und Wiederherstellung Stammpartition Virtueller Gastcomputer (Pass-Through) 181,00 764,00 241,00 158,00 875,00 218,00 154,00 874,00 173,00 157,00 874,00 167,00 573 634 799 824 Basislinie Durchsatz der Sicherung (MB/s) Gesamtzeit für Sicherung (Sekunden) Durchsatz der Wiederherstellung (MB/s) Gesamtzeit für Wiederherstellung (Sekunden) Virtueller Gastcomputer (VHD fester Größe) Indexerstellung Die Indexerstellung ist ein sehr häufiger Datenbankvorgang, der CPU- und E/A-intensiv ist. Mit diesem Testfall sollten die Auswirkungen der Virtualisierung auf den Indexerstellungsvorgang ermittelt werden. Es wurden drei umfangreiche Indizes sequenziell neu erstellt, wobei PAGEKomprimierung (ein neues Feature von SQL Server 2008, mit dem die Datenseiten in einem Index komprimiert werden) aktiviert war. Der Index wurde mit PAGE-Komprimierung erstellt, um die CPU-Auslastung zu erhöhen. Es wurden die Ressourcennutzung und die Zeit bis zum Abschluss aufgezeichnet. 26 Bei Ausführung des gleichen Vorgangs auf den virtuellen Computern wurde ein äußerst geringer Aufwand beobachtet. Abbildung 12 zeigt Indexerstellungszeit und Prozentsatz der CPU-Zeit für das systemeigene Betriebssystem, die Stammpartition und die virtuellen Gastcomputer. 2500 100 2400 90 2300 2200 2160 2176 2220 2220 80 70 2100 60 2000 50 1900 40 1800 30 1700 20 1600 10 1500 % Gast-CPU-Zeit Zeit bis zum Abschluss (Sekunden) Antwortzeit Indexerstellung und % CPU Gesamtzeit (Sekunden) Hyper-V – % Gastlaufzeit 0 Stamm BS – Hyper-V deaktiviert Stamm BS – Hyper-V aktiviert Gast (PassThrough) Gast (VHD) Abbildung 12: Drei mit PAGE-Komprimierung sequenziell neu erstellte Indizes DBCC CHECKDB DBCC CHECKDB, ein weiterer CPU- und E/A-intensiver Vorgang, wurde ebenfalls getestet. Die Ausführung des Vorgangs dauerte auf dem virtuellen Gastcomputer länger als unter dem Basisbetriebssystem. In Abbildung 13 werden die Zeit bis zum Abschluss und die Summe der durch den Vorgang genutzten CPU-Ressourcen dargestellt. Wie bei den Indexerstellungstests wurde eine relativ geringe Zunahme der Zeit bis zum Abschluss festgestellt. 27 2000 100 1900 90 1800 1680 1700 1600 1560 1700 80 70 1590 60 1500 50 1400 40 1300 30 1200 20 1100 10 1000 % Gast-CPU-Zeit Zeit bis zum Abschluss (Sekunden) DBCC CHECKDB mit MAXDOP 0 Gesamtzeit und % CPU Gesamtzeit (Sekunden) Hyper-V – % Gastlaufzeit 0 Stamm BS – Hyper-V Stamm BS – Hyper-V Gast (Pass-Through) deaktiviert aktiviert Gast (VHD) Abbildung 13: DBCC CHECKDB mit MAXDOP 0 Szenarien der SQL Server-Konsolidierung mit Hyper-V Mit dieser Gruppe von Testszenarien sollten einige der wichtigsten Fragen zur Konsolidierung von SQL Server in einer Hyper-V-Umgebung beantwortet werden: Leistungsauswirkungen der Speicherkonfiguration für mehrere Instanzen Mit diesem Testszenario sollten die Leistungsauswirkungen von dediziertem und freigegebenem Speicher in einer Konsolidierungsumgebung ermittelt werden. Skalierbarkeit der virtuellen Instanz Mit diesem Testszenario sollte die Skalierbarkeit der virtuellen Instanz ermittelt werden, wenn die Leistung des physischen Prozessors für eine 1:1-Zuordnung zu dem für den virtuellen Gastcomputer konfigurierten logischen Prozessor ausreicht. Leistung der virtuellen Instanz mit überlasteten CPU-Ressourcen 28 Mit diesem Testszenario sollten die Auswirkungen auf die Leistung ermittelt werden, wenn die Gesamtzahl der für die virtuellen Instanzen konfigurierten logischen Prozessoren größer als die Gesamtzahl der auf dem Server verfügbaren physischen Prozessoren ist. Vergleichen der Speicherkonfigurationen in einer Konsolidierungsumgebung In den vorherigen Abschnitten wurde ermittelt, dass sich Pass-Through-Datenträger und VHDs fester Größe gut als Speicherkonfigurationen für SQL Server-Arbeitsauslastungen eignen. Um die Auswirkungen dieser beiden unterschiedlichen Speicherkonfigurationen auf die OLTP-Arbeitsauslastung zu ermitteln, wurden zwei Gruppen von Tests zum Vergleichen der folgenden Speichermethoden eingerichtet: Dedizierter Speicher (d. h. keine Freigabe auf Datenträgerebene) mit Pass-Through-Datenträgern Ein gemeinsamer Pool von Datenträgerressourcen mit VHD-Dateien für SQL Server-Daten- und -Protokolldateien In der ersten Speicherkonfiguration wurden Pass-Through-Datenträger mit dediziertem Speicher für die einzelnen virtuellen Computer verwendet, wie in Abbildung 14 gezeigt. Jeder virtuelle Gastcomputer wurde mit dieser Konfiguration implementiert, die aus zwei LUNs (150 GB) für Datendateien und einem LUN (50 GB) für das Protokoll bestand. Die LUNs waren nicht für die virtuellen Gastcomputer auf der Ebene des physischen Datenträgers freigegeben, und jede LUN verfügte über einen Satz dedizierter physischer Datenträger. Abbildung 14: Datenträgerkonfiguration pro virtuellen Computer/Stamm 29 Für die zweite Speicherkonfiguration wurde ein gemeinsamer Pool von Datenträgern verwendet, wie in Abbildung 15 gezeigt. In diesem Fall wurden ein einzelner Pool von Datenträgerdateien für VHD-Dateien mit SQL Server-Datendateien und ein eigener Pool von Datenträgerressourcen für VHD-Dateien mit SQL Server-Protokolldateien verwendet. Diese Konfiguration bietet eine höhere Flexibilität für virtuelle Speicherumgebungen. Abbildung 15: Einzelne Pools Anschließend wurde für jede der beiden Konfigurationen die gleiche OLTP-Arbeitsauslastung mit unterschiedlichen Durchsatzraten ausgeführt. In Abbildung 16 und 17 wird der Vergleich von E/A-Durchsatz und Latenzzeit der Konfiguration mit dediziertem Speicher unter Verwendung von Pass-Through-Datenträgern mit der Konfiguration mit freigegebenem Speicher unter Verwendung von VHD-Dateien dargestellt. 30 Dedizierte Pass-Through-Datenträger und VHDs mit freigegebenem Speicher Gesamte E/A pro Sekunde und Datenträgerlatenzzeit 7,000 6,425 5,828 5,697 Datenträger-Lesevorgänge/s 6,000 6,151 0.009 Gesamte Lesevorgänge/s (dedizierte LUNs) 0.008 0.007 5,000 Gesamte Lesevorgänge/s (gemeinsames Volume mit VHDs) 0.006 4,178 4,047 4,000 0.005 3,000 0.004 Durchschnittliche Leselatenzzeit (dedizierte LUNs) 0.003 2,000 0.002 1,000 Durchschnittliche Leselatenzzeit (gemeinsames Volume mit VHDs) 0.001 0 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 16: Vergleich von E/A-Durchsatz und Latenzzeit mit Pass-Through-Datenträgern und VHDs fester Größe Dedizierter Speicher und VHDs mit freigegebenem Speicher 4,000 3,612 3,245 3,173 Batches/s 3,500 3,444 Summe Batches/s 4 VCs (dedizierte LUNs) 3,000 2,500 2,244 2,182 2,000 Summe Batches/s 4 VCs (gemeinsames Volume mit VHDs) 1,500 1,000 500 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 17: Vergleich des Durchsatzes von LUNs mit dediziertem Speicher auf Pass-Through-Datenträgern mit VHDs fester Größe auf freigegebenen Datenträgern 31 Beide Speicherkonfigurationen wiesen einen ähnlichen Durchsatz auf. Die durchschnittliche Leistung der Konfiguration mit VHDs fester Größe war ca. 3,5 % geringer als die Leistung der Konfiguration mit dedizierten Pass-Through-Datenträgern. Wenn E/A-Leistung und Berechenbarkeit von wesentlicher Bedeutung für eine Anwendung sind, wird empfohlen, Pass-Through-Datenträger auf dedizierten Datenträgerressourcen zu verwenden. Diese Konfiguration bietet jedoch nicht die Flexibilität von VHD-Dateien. Skalierbarkeit der virtuellen Instanz Im häufigsten Bereitstellungsszenario werden mehrere virtuelle Computer auf demselben Host ausgeführt. Dieses Testszenario wurde aufgenommen, um die Eigenschaften der Skalierung der Datenbankauslastung mit virtuellen Computern zu untersuchen. Der für dieses Testszenario verwendete Dell R900 verfügt über 16 physische Kerne. Es wurden zwei Gruppen von Testfällen ausgeführt. Die erste Gruppe wurde für die Verwendung von 8 Kernen konfiguriert (NUMPROC=8). Die zweite Gruppe wurde für die Verwendung von allen 16 Kernen konfiguriert (NUMPROC=16). Alle virtuellen Gastcomputer wurden mit vier logischen Prozessoren und 14 GB RAM konfiguriert. SQL Server wurde für die Verwendung von 12 GB konfiguriert, sodass 2 GB für das Betriebssystem übrig blieben. Zwei parallele virtuelle Gastcomputer In diesem Testfall wurden zwei virtuelle Computer parallel auf dem Host ausgeführt, der mit acht physischen Prozessoren konfiguriert war. Jeder virtuelle Computer war mit vier logischen Prozessoren konfiguriert. Die virtuellen Computer wurden mit identischem zugrunde liegendem Speicher konfiguriert. Das Ergebnisdiagramm in Abbildung 18 zeigt, dass die Konfiguration sehr gut entsprechend der zunehmenden Arbeitsauslastung skalierbar ist. 32 Aggregierte Batches/s und Gastlaufzeit von 2 VCs 100 90 2000 Batches/s 80 70 1500 60 50 1000 1647 1884 40 30 500 1080 Summe Batches/s alle VCs Hyper-V – % Gastlaufzeit Hyper-V – % Gesamtlaufzeit 20 10 0 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 18: Skalierbarkeit von parallelen virtuellen Gastcomputern Vier parallele virtuelle Gastcomputer Dieser Test wurde ausgeführt, um die Skalierbarkeit virtueller Computer mit OLTPArbeitsauslastung zu ermitteln, wenn die Prozessorressourcen ausreichen, um die 1:1-Zuordnung von physischen Prozessoren zu logischen Prozessoren zu unterstützen. Auf dem Host waren 16 CPUs verfügbar, und jeder virtuelle Computer war mit vier logischen Prozessoren konfiguriert. Der zugrunde liegende Speicher war für alle vier virtuellen Computer identisch. Die in Abbildung 19 dargestellten Ergebnisse zeigen eine sehr gute Skalierbarkeit der virtuellen Computer, wenn die CPUs nicht überlastet sind. Bei vier parallelen virtuellen Gastcomputern kann aufgrund der erhöhten Parallelität ein größerer Verarbeitungsaufwand als bei zwei parallelen virtuellen Gastcomputern auftreten. 33 Aggregierte Batches/s und Gastlaufzeit von 2 bis 4 VCs 4000 3,612 3500 90 3,245 Batches/s 3000 2500 2,244 1500 2102 1779 2000 100 80 Summe Batches/s 2 VCs 70 Summe Batches/s 4 VCs 60 50 1128 1000 40 Hyper-V – % Gastlaufzeit (4 VCs) 30 Hyper-V – % Gesamtlaufzeit 20 500 10 0 Hyper-V – % Gastlaufzeit (2 VCs) Hyper-V – % Gesamtlaufzeit 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 19: Skalierbarkeit von virtuellen Computern ohne überlastete CPUs Leistung der virtuellen Instanz mit überlasteten CPU-Ressourcen Hyper-V unterstützt die Überlastung von CPUs bis zu einer Zuordnung von logischen zu virtuellen Prozessoren im Verhältnis 1:8. Überlastete Prozessoren können bei der Konsolidierung zum Maximieren der auf dem physischen Server verfügbaren CPU-Ressourcen verwendet werden. Dieses Verfahren verursacht jedoch beträchtlichen zusätzlichen CPU-Verarbeitungsaufwand. Mit den in diesem Abschnitt beschriebenen Tests wurden die Auswirkungen der Ausführung von SQL Server in einer virtuellen Umgebung mit überlasteten CPU-Ressourcen untersucht. Vier parallele virtuelle Gastcomputer mit überlasteten CPU-Ressourcen In dem Szenario mit überlasteten Prozessoren wurden vier virtuelle Gastcomputer für die parallele Ausführung konfiguriert. Jeder virtuelle Computer wurde mit vier logischen Prozessoren, 14 GB RAM und 12 GB für SQL Server konfiguriert. Der zugrunde liegende Speicher war für alle vier virtuellen Computer identisch. In Abbildung 20 wird die Skalierbarkeit bei zunehmender Arbeitsauslastung gezeigt. Die Skalierungskurve ist recht flach, und bei etwa 90 % ist sie nahezu waagerecht. Das Ausführen von vier virtuellen Computern mit jeweils vier virtuellen Prozessoren 34 führte zu einer CPU-Überlastung: Die CPU-Ressourcen von 16 virtuellen Prozessoren mit nur 8 physischen CPU-Kernen wurden eingeschränkt. Hyper-V macht auf der Ebene der virtuellen Computer Optionen für die CPURessourcenverwaltung verfügbar, die in diesen Typen von Szenarien verwendet werden können. Diese Optionen werden in einem später zu veröffentlichenden Dokument erörtert. Aggregierte Batches/s und Gastlaufzeit von 4 VCs 2500 100 90 Batches/s 2000 2203 2104 80 70 1893 1500 60 50 1000 Summe Batches/s alle VCs Hyper-V – % Gastlaufzeit 40 30 500 20 Hyper-V – % Gesamtlaufzeit 10 0 0 Geringe OLTPArbeitsauslastung Mittlere OLTPArbeitsauslastung Hohe OLTPArbeitsauslastung Abbildung 20: Skalierbarkeit von vier parallelen virtuellen Gastcomputern mit überlasteten CPUs Vergleichen von Konsolidierungsoptionen In Konsolidierungsszenarien bietet die Virtualisierung viele Vorteile. Einer der wichtigsten Vorteile ist, dass virtuelle Computer mehrere isolierte Umgebungen auf demselben Hostcomputer bereitstellen. Die resultierende Leistung variiert je nach Anwendung, Arbeitsauslastung und Hardware. Die Vor- und Nachteile der Verwendung einer systemeigenen und einer virtuellen Instanz für ein Konsolidierungsprojekt müssen gründlich getestet und sorgfältig abgewogen werden. In Tabelle 6 werden die Optionen für systemeigene und virtuelle Instanzen hinsichtlich der Konsolidierung verglichen. 35 Tabelle 6: Konsolidierungsoptionen Mehrere SQL Server-Instanzen Mehrere virtuelle Computer Isolation Freigegebene Windows-Instanz Dedizierte Windows-Instanz CPU-Ressourcen Anzahl der für die WindowsInstanz sichtbaren CPUs Maximum • Windows 2008 – bis zu 4 virtuelle CPUs • Windows 2003 – bis zu 2 virtuelle CPUs Arbeitsspeicher Flexibler Servergrenzwert (max. Serverarbeitsspeicher) Statische Reservierung des virtuellen Computers • Nur Offlineänderungen • Keine Möglichkeit zur Überlastung von Speicherressourcen 64-GB-Grenzwert pro virtuellen Gastcomputer 2-TB-Grenzwert (Terabyte) pro Host Speicher SQL Server-Datendateien mit Standardspeicheroptionen SQL Server-Datendateien mit Pass-Through-Datenträgern oder virtuellen Festplatten, die für den virtuellen Computer verfügbar gemacht werden Ressourcenverwaltung WSRM (Prozessebene) Virtueller Hyper-V-Gastcomputer Anzahl von Instanzen 50 Tatsächlicher Grenzwert hängt von physischen Ressourcen ab Unterstützung Es gelten die üblichen Regeln. SQL Server 2008 und SQL Server 2005 Hohe Verfügbarkeit Es gelten die üblichen Regeln. Gastcomputercluster werden unterstützt Datenbankspiegelung, Protokollversand (unterstützt) Fazit Hinsichtlich der Leistung ist Hyper-V eine geeignete Option für SQL ServerKonsolidierungsszenarien. SQL Server bietet in einer virtuellen Hyper-V-Umgebung im Vergleich zur entsprechenden systemeigenen Windows Server 2008-Umgebung eine zufriedenstellende Gesamtleistung. Bei angemessener E/A-Kapazität und -Konfiguration ist der E/A-Aufwand minimal. Eine optimale Leistung wird erzielt, wenn eine für die Anzahl der auf dem Server konfigurierten virtuellen Prozessoren ausreichende Anzahl physischer Prozessoren 36 vorhanden ist, um eine Überlastung der CPU-Ressourcen zu vermeiden. Wenn die CPU-Ressourcen überlastet sind, erhöht sich der CPU-Verarbeitungsaufwand beträchtlich. Sie müssen jede Anwendung unbedingt gründlich testen, bevor Sie sie in einer Hyper-V-Produktionsumgebung bereitstellen. Es folgen einige allgemeine Überlegungen und Empfehlungen für die Ausführung von SQL Server in Hyper-V-Umgebungen. Beobachtungen • Virtuelle Hyper-V-Gastcomputer sind auf vier CPU-Kerne beschränkt. Daher sollten Sie nur dann SQL Server auf virtuellen Hyper-V-Gastcomputern ausführen, wenn die Arbeitsauslastung von maximal vier CPUs verarbeitet werden kann. • Auf einem virtuellen Gastcomputer lässt sich der gleiche Durchsatz wie bei systemeigenen Konfigurationen mit vergleichbaren Hardwareressourcen erzielen, allerdings mit geringfügig höherer CPU-Auslastung. Mit Hyper-V können CPU-Ressourcen überlastet werden, wenn die Gesamtzahl der für alle virtuellen Gastcomputer konfigurierten logischen CPU-Kerne die Anzahl der auf dem Server verfügbaren physischen CPU-Kerne überschreitet. In diesen Fällen wurden beim Ausführen von SQL Server-Arbeitsauslastungen eine höhere CPU-Auslastung und ein höherer Verarbeitungsaufwand beobachtet. Eine angemessene Dimensionierung der Hardware ist für die Leistung von SQL Server von ausschlaggebender Bedeutung. Stellen Sie sicher, dass die Summe der physischen CPU-Ressourcen für die Anforderungen der virtuellen Gastcomputer ausreicht, indem Sie die Arbeitsauslastung in der geplanten virtuellen Umgebung testen. • Bei netzwerkintensiven Arbeitsauslastungen erhöhen sich der CPU-Verarbeitungsaufwand und somit auch die Leistungsbeeinträchtigung. • Die bisher dargestellten Informationen betreffen Leistungsaspekte. Berücksichtigen Sie für die Bereitstellung auch Funktionsaspekte (unterstützte Konfigurationen, Optionen zum Erreichen hoher Verfügbarkeit usw.). Die Anhänge dieses Dokuments enthalten weitere Informationen zu allgemeinen Hyper-V-Funktionen 37 und aktuellen Unterstützungsrichtlinien für das Ausführen von SQL Server in Hyper-V-Konfigurationen. • Beim Ausführen von SQL Server auf einem virtuellen Gastcomputer wurde ein minimaler E/A-Verarbeitungsaufwand festgestellt. Die Konfiguration mit Pass-Through-Datenträgern lieferte die beste E/A-Leistung, jedoch wurde bei der Ausführung mit VHDs fester Größe ein minimaler zusätzlicher E/A-Aufwand festgestellt. Die zu verwendende Speicherkonfiguration sollte entsprechend der jeweiligen Bereitstellung ausgewählt werden. Virtuelle Computer mit VHDs können leichter migriert werden als virtuelle Computer mit Pass-Through-Datenträgern. • Bei Konsolidierungsszenarien hängt die Entscheidung vom Umfang der verfügbaren Speicherressourcen und vom Szenario ab. In den durchgeführten Tests war die Leistung sowohl in den Konfigurationen mit freigegebenem Speicher als auch in den Konfigurationen mit dediziertem Speicher akzeptabel. In beiden Fällen sollten Sie bei der Festlegung der Speichergröße die Anforderungen an die Arbeitsauslastung und die Antwortzeit berücksichtigen. Beachten Sie in Hyper-V-Umgebungen genauso wie bei einer SQL Server-Bereitstellung immer die Best Practices bezüglich des zugrunde liegenden Speichers. Weitere Informationen finden Sie unter Predeployment I/O Best Practices for SQL Server (Best Practices für SQL Server vor der Bereitstellung des E/A-Systems, auf Englisch). Empfehlungen Verwenden Sie für den Speicher des virtuellen Gastcomputers Pass-ThroughDatenträger oder VHDs fester Größe. Diese sind unter Leistungsaspekten die besten Optionen, und sie bieten die besten Ergebnisse für SQL Server-Arbeitsauslastungen. Dynamische VHDs werden aus Leistungsgründen nicht empfohlen. Verwenden Sie keine emulierten Geräte. Stellen Sie stattdessen sicher, dass Integrationskomponenten für Hyper-V installiert wurden und dass für E/A, Netzwerk usw. synthetische Geräte verwendet werden. Synthetische Geräte bieten die beste Leistung mit geringstem CPU-Verarbeitungsaufwand. 38 Die Möglichkeit einer Verwendung einiger dieser Verfahren hängt von den Hardwarefunktionen ab. Informieren Sie sich über Arbeitsauslastungen mit intensiver Nutzung von Netzwerkressourcen in den Richtlinien für die Leistungsoptimierung von Windows Server 2008 in den Abschnitten zu Virtualisierung und Netzwerk über Best Practices zum Optimieren des Netzwerks für die spezifische Konfiguration. Testen Sie die Leistung mit der von Ihnen verwendeten Arbeitsauslastung, da die Merkmale von Arbeitsauslastungen erheblich variieren können. Weitere Informationen Windows Server Hyper-V (auf Englisch) Hyper-V Deployment and Planning Guide (Bereitstellungs- und Planungshandbuch für Hyper-V, auf Englisch) Microsoft Assessment and Planning Toolkit 3.1 for Hyper-V (auf Englisch) Erste Schritte mit Hyper-V Performance Tuning Guidelines for Windows Server 2008 (Richtlinien für die Leistungsoptimierung von Windows Server 2008, Abschnitt zur Virtualisierung, auf Englisch) Hyper-V Performance FAQ (auf Englisch) Hyper-V Monitoring (Hyper-V-Überwachung, Windows-Team – alle Themen des Blogs zur Leistung, auf Englisch) Supportrichtlinie für Microsoft SQL Server-Produkte, die in einer Umgebung mit Hardware-Virtualisierung ausgeführt werden (maschinell übersetzt) Predeployment I/O Best Practices for SQL Server (Best Practices für SQL Server vor der Bereitstellung des E/A-Systems, auf Englisch) Microsoft System Center Virtual Machine Manager 39 Anhang 1: Architektur von Hyper-V Hyper-V ist eine hypervisorbasierte Virtualisierungstechnologie für Windows Server 2008. Der Hypervisor ist die prozessorspezifische Virtualisierungsplattform, die die gemeinsame Nutzung einer einzelnen Hardwareplattform durch mehrere isolierte Betriebssysteme ermöglicht. Hyper-V unterstützt Isolierung in Form einer Partitionierung. Eine Partition ist eine vom Hypervisor unterstützte logische Isolationseinheit, in der Betriebssysteme ausgeführt werden. Der Microsoft-Hypervisor muss über mindestens eine übergeordnete Partition bzw. Stammpartition verfügen, in der eine 64-Bit-Edition von Windows Server 2008 ausgeführt wird. Der Virtualisierungsstapel wird in der übergeordneten Partition ausgeführt und verfügt über direkten Zugriff auf die Hardwaregeräte. Die Stammpartition erstellt dann die untergeordneten Partitionen, die die Gastbetriebssysteme hosten. Die untergeordneten Partitionen werden von der Stammpartition mit der Hypercall-API (Application Programming Interface, Anwendungsprogrammierschnittstelle) erstellt. Partitionen haben keinen Zugriff auf den physischen Prozessor, und sie behandeln keine Prozessorinterrupts. Stattdessen verfügen sie über eine virtuelle Sicht des Prozessors, und sie werden in einem virtuellen Arbeitsspeicheradressbereich ausgeführt, der für jede Gastpartition privat ist. Der Hypervisor behandelt die Interrupts des Prozessors und leitet sie an die entsprechende Partition um. Hyper-V kann auch die Hardwarebeschleunigung verwenden, um die Adressübersetzung zwischen den Adressbereichen verschiedener virtueller Gastcomputer zu beschleunigen. Dies erfolgt mithilfe einer IOMMU (Input Output Memory Management Unit, E/A-Speicherverwaltungseinheit), die unabhängig von der Speicherverwaltungshardware arbeitet, die von der CPU verwendet wird. Mithilfe einer IOMMU werden die physischen Speicheradressen den von den untergeordneten Partitionen verwendeten Adressen neu zugeordnet. Untergeordnete Partitionen haben ebenfalls keinen direkten Zugriff auf andere Hardwareressourcen, und diese werden für sie in einer virtuellen Sicht als virtuelle Geräte (VDevs) dargestellt. Anforderungen an die virtuellen Geräte werden über den VMBus oder den Hypervisor an die Geräte in der übergeordneten Partition umgeleitet, die die Anforderungen behandelt. Der VMBus ist ein logischer Kommunikationskanal zwischen Partitionen. Die übergeordnete Partition hostet VSPs (Virtualization Service 40 Providers, Virtualisierungsdienstanbieter), die über den VMBus kommunizieren, um Gerätezugriffsanforderungen von untergeordneten Partitionen zu behandeln. Untergeordnete Partitionen hosten VSCs (Virtualization Service Consumer, Virtualisierungsdienstclients), die Geräteanforderungen über den VMBus an VSPs in der übergeordneten Partition umleiten. Der gesamte Vorgang ist für das Gastbetriebssystem transparent. Virtuelle Geräte können außerdem ein Windows Server-Virtualisierungsfeature mit dem Namen „Optimierte E/A“ („Enlightened“ E/A) für Speicher, Netzwerk, Grafiken und Eingabesubsysteme nutzen. „Optimierte E/A“ ist eine spezielle virtualisierungsfähige Implementierung allgemeiner Kommunikationsprotokolle (z. B. SCSI), die den VMBus unter Umgehung von Geräteemulationsebenen direkt nutzen. Dies erhöht die Effizienz der Kommunikation, erfordert jedoch einen optimierten Gast, der Hypervisor- und VMBus-fähig ist. Optimierte Hyper-V-E/A und ein Hypervisor-fähiger Kernel werden mit der Installation von Hyper-V-Integrationsdiensten bereitgestellt. Integrationskomponenten, die VSC (Virtual Server Client)-Treiber enthalten, sind auch für andere Clientbetriebssysteme verfügbar. Hyper-V erfordert einen Prozessor mit hardwaregestützter Virtualisierung, die mit Intel VT oder AMD-V-Technologie (AMD Virtualization) bereitgestellt wird. Die folgende Abbildung bietet eine allgemeine Übersicht über eine Hyper-V-Umgebung unter Windows Server 2008. 41 Übersicht über die Hyper-V-Architektur Die in der Abbildung verwendeten Akronyme und Begriffe werden im Folgenden beschrieben: APIC – Advanced Programmable Interrupt Controller (erweiterter programmierbarer Interruptcontroller) – Ein Gerät, das es ermöglicht, den Interruptausgaben Prioritätsebenen zuzuweisen. Untergeordnete Partition – Partition, die ein Gastbetriebssystem hostet – Alle Zugriffe einer untergeordneten Partition auf physischen Speicher und Geräte werden über den Bus des virtuellen Computers (Virtual Machine Bus, VMBus) oder den Hypervisor bereitgestellt. Hypercall – Schnittstelle für die Kommunikation mit dem Hypervisor – Die Hypercallschnittstelle bietet Zugriff auf die vom Hypervisor bereitgestellten Optimierungen. Hypervisor – Eine Softwareschicht zwischen der Hardware und einem oder mehreren Betriebssystemen. Seine wichtigste Aufgabe ist die Bereitstellung isolierter Ausführungsumgebungen, die als Partitionen bezeichnet werden. Der Hypervisor steuert und vermittelt den Zugriff auf die zugrunde liegende Hardware. IK – Integrationskomponente – Komponente, die untergeordneten Partitionen die Kommunikation mit anderen Partitionen und dem Hypervisor ermöglicht. E/A-Stapel – Eingabe-/Ausgabestapel. MSR – Memory Service Routine (Speicherdienstroutine). Stammpartition– Verwaltet Funktionen auf Computerebene, z. B. Gerätetreiber, Energieverwaltung und das Hinzufügen/Entfernen von Geräten während des Betriebs. Die Stammpartition (bzw. übergeordnete Partition) ist die einzige Partition mit direktem Zugriff auf physischen Arbeitsspeicher und physische Geräte. 42 VID – Virtualization Infrastructure Driver (Virtualisierungsinfrastrukturtreiber) – Stellt Partitionsverwaltungsdienste, Verwaltungsdienste für virtuelle Prozessoren und Arbeitsspeicher-Verwaltungsdienste für Partitionen bereit. VMBus – Kanalbasierter Kommunikationsmechanismus, der in Systemen mit mehreren aktiven virtuellen Partitionen für die Kommunikation zwischen Partitionen und die Geräteenumeration verwendet wird. Der VMBus wird mit Hyper-V-Integrationsdiensten installiert. VMMS – Virtual Machine Management Service (Verwaltungsdienst für virtuelle Computer) – Verantwortlich für die Verwaltung des Status aller virtuellen Computer in untergeordneten Partitionen. VMWP – Virtual Machine Worker Process (Arbeitsprozess für virtuelle Computer) – Eine Benutzermoduskomponente des Virtualisierungsstapels. Vom Arbeitsprozess werden Verwaltungsdienste für virtuelle Computer von der Windows Server 2008-Instanz in der übergeordneten Partition für die Gastbetriebssysteme in den untergeordneten Partitionen bereitgestellt. Der Verwaltungsdienst für virtuelle Computer erzeugt für jeden ausgeführten virtuellen Computer einen eigenen Arbeitsprozess. VSC – Virtualization Service Client (Virtualisierungsdienstclient) – Eine synthetische Geräteinstanz in einer untergeordneten Partition. VSCs nutzen Hardwareressourcen, die von VSPs (Virtualization Service Providers, Virtualisierungsdienstanbietern) in der übergeordneten Partition bereitgestellt werden. Sie kommunizieren mit den entsprechenden VSPs in der übergeordneten Partition über den VMBus, um die E/A-Anforderungen für ein Gerät der untergeordneten Partition zu bedienen. VSP – Virtualization Service Provider (Virtualisierungsdienstanbieter) – Befindet sich in der Stammpartition und unterstützt über den VMBus (Virtual Machine Bus) synthetische Geräte für untergeordnete Partitionen. WinHv – Windows Hypervisor-Schnittstellenbibliothek – WinHv stellt eine Brücke zwischen den Treibern eines partitionierten Betriebssystems und dem Hypervisor dar, die Treibern den Aufruf des Hypervisors mit Windows-Standardaufrufkonventionen ermöglicht. WMI – Der Verwaltungsdienst für virtuelle Computer macht eine Gruppe von WMI-basierten (Windows Management Instrumentation) APIs zum Verwalten und Steuern von virtuellen Computern verfügbar. 43 Anhang 2: Hardwareanforderungen Hyper-V erfordert spezifische Hardware. Sie können Systeme identifizieren, die die x64Architektur und Hyper-V unterstützen, indem Sie im Windows Server-Katalog unter „Additional Qualifications“ auf „Hyper-V“ klicken (siehe http://go.microsoft.com/fwlink/?LinkId=111228). Zum Installieren und Verwenden der Hyper-V-Rolle benötigen Sie folgende Elemente: x64-basierter Prozessor. Hyper-V ist in 64-Bit-Editionen von Windows Server 2008 verfügbar, d. h. in den 64-Bit-Editionen von Windows Server 2008 Standard, Windows Server 2008 Enterprise und Windows Server 2008 Datacenter. Für 32-Bit-Editionen (x86) oder Windows Server 2008 für Itanium-basierte Systeme ist Hyper-V nicht verfügbar. Die Hyper-V-Verwaltungstools sind jedoch für 32-Bit-Editionen verfügbar. Hardwareunterstützte Virtualisierung. Diese ist in Prozessoren verfügbar, die eine Virtualisierungsoption enthalten, insbesondere in Prozessoren mit Intel Virtualization Technology (Intel VT) oder AMD Virtualization-Technologie (AMD-V). Durch die Hardware erzwungene Datenausführungsverhinderung (Data Execution Protection, DEP) muss verfügbar und aktiviert sein. Das heißt, Sie müssen das Intel XD-Bit (Execute DisableBit) bzw. AMD NX-Bit (No Execute-Bit) aktivieren. Tipp Die Einstellungen für hardwaregestützte Virtualisierung und durch die Hardware erzwungene Datenausführungsverhinderung sind im BIOS verfügbar. Die Namen der Einstellungen können jedoch von den oben genannten Namen abweichen. Weitere Informationen zur Unterstützung von Hyper-V durch ein bestimmtes Prozessormodell erhalten Sie vom Computerhersteller. Wenn Sie die Einstellungen für hardwareunterstützte Virtualisierung oder durch Hardware erzwungene Datenausführungsverhinderung ändern, sollten Sie die Stromversorgung des Computers ausschalten und anschließend wieder einschalten. Durch einen einfachen Neustart des Computers werden die geänderten Einstellungen möglicherweise nicht übernommen. Arbeitsspeicher Der maximale verwendbare Arbeitsspeicher richtet sich wie folgt nach dem Betriebssystem: Für Windows Server 2008 Enterprise und Windows Server 2008 Datacenter kann der physische Computer mit maximal 2 TB physischem Speicher konfiguriert werden. Virtuelle Computer, auf denen eine dieser Editionen ausgeführt wird, können mit maximal 64 GB Speicher pro virtuellen Computer konfiguriert werden. Für Windows Server 2008 Standard kann der physische Computer mit bis zu 32 GB an physischem Speicher konfiguriert werden. Virtuelle Computer, auf denen eine dieser Editionen ausgeführt wird, können mit bis zu 31 GB Speicher pro virtuellen Computer konfiguriert werden. 44 Prozessoren Hyper-V wird auf physischen Computern mit bis zu 16 logischen Prozessoren mit der Hyper-v RTM-Version und 64 logischen Prozessoren mit der Hyper-v R2-Version unterstützt. Bei einem logischen Prozessor kann es sich um einen Kernprozessor oder um einen Prozessor mit Hyperthreadingtechnologie handeln. Sie können auf einem virtuellen Computer bis zu 4 virtuelle Prozessoren konfigurieren. Jedoch ist möglicherweise die von einem Gastbetriebssystem unterstützte Anzahl virtueller Prozessoren geringer. Weitere Informationen finden Sie unter Grundlegendes zu virtuellen Computern und Gastbetriebssystemen. Im Folgenden sind einige Beispiele für unterstützte Systeme und die Anzahl der von ihnen bereitgestellten logischen Prozessoren aufgeführt: Ein Einzelprozessor/Zweikern-System stellt 2 logische Prozessoren bereit. Ein Einzelprozessor/Vierkern-System stellt 4 logische Prozessoren bereit. Ein Doppelprozessor/Zweikern-System stellt 4 logische Prozessoren bereit. Ein Doppelprozessor/Vierkern-System stellt 8 logische Prozessoren bereit. Ein Vierfachprozessor/Zweikern-System stellt 8 logische Prozessoren bereit. Ein Vierfachprozessor/Zweikern-System mit Hyperthreading stellt 16 logische Prozessoren bereit. Ein Vierfachprozessor/Vierkern-System stellt 16 logische Prozessoren bereit. Netzwerk Hyper-V bietet folgende Netzwerkunterstützung: Jeder virtuelle Computer kann mit maximal 12 virtuellen Netzwerkkarten konfiguriert werden, 8 davon vom Typ „Netzwerkkarte“ und 4 vom Typ „ältere Netzwerkkarte“. Der Typ „Netzwerkkarte“ ermöglicht eine bessere Leistung und erfordert einen Treiber für virtuelle Computer, der in den Paketen für die Integrationsdienste enthalten ist. Jede virtuelle Netzwerkkarte kann mit einer statischen oder dynamischen MAC-Adresse konfiguriert werden. Jede virtuelle Netzwerkkarte bietet integrierte Unterstützung für virtuelle lokale Netzwerke (Virtual Local Area Networks, VLANs), und ihr kann ein eindeutiger VLAN-Kanal zugewiesen werden. Sie können eine beliebige Anzahl von virtuellen Netzwerken mit einer unbegrenzten Anzahl von virtuellen Computern pro virtuelles Netzwerk verwenden. Weitere Informationen über virtuelle Netzwerke finden Sie unter Konfigurieren virtueller Netzwerke. Hinweis Ein virtuelles Netzwerkwerk kann nicht mit einer Drahtlosnetzwerkkarte verbunden werden. Daher können für virtuelle Computer keine Drahtlosnetzwerkfunktionen bereitgestellt werden. 45 Speicher Hyper-V unterstützt eine Vielzahl von Speicheroptionen. Sie können auf einem Server mit Hyper-V die folgenden Typen von physischem Speicher verwenden: Direkt angeschlossener Speicher: Sie können SATA (Serial Advanced Technology Attachment), eSATA (external Serial Advanced Technology Attachment), PATA (Parallel Advanced Technology Attachment), SAS (Serial Attached SCSI), SCSI, USB und Firewire verwenden. SANs (Storage Area Networks): Sie können die Technologien iSCSI (Internet SCSI), Fibre Channel und SAS verwenden. NAS (Network Attached Storage). Virtuelle Computer können für die Verwendung folgender Typen von virtuellem Speicher konfiguriert werden: Virtuelle Festplatten mit bis zu 2040 GB. Sie können virtuelle Festplatten mit fester Größe, dynamisch erweiterbare virtuelle Festplatten und differenzierende Datenträger verwenden. Virtuelle IDE-Geräte. Jeder virtuelle Computer unterstützt bis zu 4 IDE-Geräte. Der Startdatenträger muss an eines der IDE-Geräte angeschlossen sein. Beim Startdatenträger kann es sich um eine virtuelle Festplatte oder um einen physischen Datenträger handeln. Virtuelle SCSI-Geräte. Jeder virtuelle Computer unterstützt bis zu 4 virtuelle SCSI-Controller, von denen jeder bis zu 64 Datenträger unterstützt. Somit kann jeder virtuelle Computer mit 256 virtuellen SCSI-Datenträgern konfiguriert werden. Physische Datenträger. Für physische Datenträger, die direkt an einen virtuellen Computer angeschlossen sind (auch als Pass-Through-Datenträger bezeichnet), richtet sich die Größenbeschränkung lediglich nach der vom Gastbetriebssystem unterstützten Größe. Speicherkapazität virtueller Computer. Mit virtuellen Festplatten werden auf jedem virtuellen Computer bis zu 512 TB an Speicher unterstützt. Mit physischen Datenträgern ist diese Zahl, abhängig von der Unterstützung durch das Gastbetriebssystem, noch höher. Snapshots virtueller Computer. Hyper-V unterstützt bis zu 50 Snapshots pro virtuellen Computer. Hinweis Zwar muss das Gastbetriebssystem auf einem virtuellen Computer mithilfe eines virtuellen IDEGeräts als Startdatenträger gestartet werden, jedoch stehen Ihnen viele Optionen bei der Auswahl des physischen Geräts zur Verfügung, das den Speicher für das virtuelle IDE-Gerät bereitstellt. Beispielsweise können Sie jeden der in der vorangehenden Liste angegebenen Typen von physischem Speicher verwenden. 46 Anhang 3: Hardwarekonfiguration Testkonfiguration für SQL Server in Hyper-V Prozessor Server Dell R900 Speicher HDS AMS1000 Cache Arbeitsspeicher HBA Betriebssystem Netzwerk Daten Protokoll Sicherung Betriebssystem Intel Quad-Core-Prozessor mit 4 Sockets, 2,40 GHz, 1066-MHz-Bus 6-MB-L2-Cache 64 GB physischer Arbeitsspeicher 2 x 4 GB/s Dual-Port Emulex Windows Server 2008 SP1 2 x Broadcom BCM5708C NetXtreme II GigE 8 x 8 Spindeln (4+4) (RAID 1+0) 4 x 4 Spindeln (2+2) (RAID 1+0) 6 Spindeln (5+1) (RAID 5) 4 x Datenträger (1+1) (RAID 1+0) 47
