Wer bei seinem Kunde Microsofts SQL Server mit Hyper-V oder in virtualisierten Umgebungen betreiben will, sollte einige Punkte beachten. Im nachfolgenden Beitrag finden Sie einige wichtige Fakten zur Installation, Dynamic Memory, Lizenzen und Hardware-Konfiguration.
Die folgende Aufzählung erhebt selbstverständlich keinen Anspruch auf Vollständigkeit, kann jedoch für Administratoren vielleicht einige Punkte hilfreich beleuchten. Wer es mit dem Microsoft SQL Server 2008 R2 einmal ausprobieren will, findet bei Microsoft eine voll funktionsfähige 180-Tage-Testversion zum Download.
Zunächst einige Anmerkungen zur Installation, dies betrifft Neuinstallationen in die Konsolidierungsumgebung, nicht die Migration von vorhandenen Umgebungen:
-
Für Private Cloud/Konsolidierungsumgebungen ist es empfohlen, SQL Server VMs aus VM-Templates zu erstellen.
-
SQL Server unterstützt sysprep zum Erstellen des Templates erst seit Version SQL Server 2008 R2.
-
Man muss für sysprep genau nach Anleitung vorgehen. Die Installation erfolgt in zwei Schritten: Vorbereiten (danach sysprep und Template erstellen) und abschließen. Eine Dokumentation finden Sie hier.
-
Stellen Sie unbedingt sicher, dass die Hyper-V Integrationskomponenten (beziehungsweise das entsprechende Äquivalent für die verwendete Virtualisierungsumgebung) in der jeweils aktuellen Version installiert sind, verwenden Sie keine emulierten Geräte.
-
Um festzustellen, welche SQL Server Instanzen in die virtuelle Umgebung migriert werden können verwendet man am einfachsten das MAP Toolkit
Dynamic Memory
SQL Server unterstützt Hyper-V 2008 R2 SP1 Dynamic Memory. Lesen Sie dazu auch unseren Workshop - Dynamic Memory beim Hyper-V einrichten.
Folgende Punkte sollen Sie im Hinblick auf Dynamic Memory beachten:
-
Das SQL Server Dienstkonto sollte unbedingt das Recht Lock Pages in memory haben.
-
Die Summe der Startup-Memory-Einstellungen aller VMs, die potentiell (auch nach einem ungeplanten Failover) auf einem Host laufen können muss kleiner sein als der physikalische Speicher des Hosts.
-
Wenn möglich sollte vor einer (geplanten) Live Migration einer SQL VM der Hauptspeicher von SQL Server mittels sp_configure ‘max server memory’ reduziert werden. Nicht vergessen, diese Einstellung nach der Live Migration wieder zu zurückzunehmen!
-
Über Memory Weight kann man die Priorität der VMs bei der Hauptspeicherzuteilung einstellen.
- Dynamic Memory unter Hyper-V
Start: Um Dynamic Memory nutzen zu können, muss zuerst das Windows Server Service Pack 1 installiert werden. - Dynamic Memory unter Hyper-V
Fertig: Die Installation ist abgeschlossen. - Dynamic Memory unter Hyper-V
Details: Unter Serverrollen muss die Funktion Hyper-V explizit aktiviert werden. - Dynamic Memory unter Hyper-V
Fortsetzung: Mit Hilfe des Hyper-V-Managers muss ein neuer Virtueller Computer angelegt werden. - Dynamic Memory unter Hyper-V
Standard: Wie gewohnt wird die Größe des Arbeitsspeicher beim Eiinrichten einer virtuellen Maschine vergeben. - Dynamic Memory unter Hyper-V
Zuweisung: In diesem Fenster werden die einzelnen Parameter des dynamischen Speichers einer virtuellen Maschine vergeben.
Storage
Alle Best Practices für SQL Server Storage gelten auch für virtualisierte Umgebungen. Folgendes gilt es zu berücksichtigen:
-
Für Lastsysteme: Daten und Logs auf getrennte LUNs, hinter denen getrennte Platten liegen.
-
Auf keinen Fall dynamische Disks für Daten und Logs.
-
Entweder Passthrough Disks oder VHDs fester Größe verwenden.
CPU
Virtualisierung erhöht leicht den CPU-Bedarf von SQL Server. Da Hyper-V maximal vier virtuelle CPUs pro VM unterstützt bedeutet das, dass nur Lasten, die weniger als vier volle CPU-Cores benötigen virtualisiert werden sollten.
Wenn CPUs overcommitted werden (also der Summe aller VMs mehr virtuelle CPUs zugewiesen werden als der Server physische CPU-Kerne hat) so erhöht sich der CPU-Bedarf durch die Virtualisierung weiter. Daher sollte bei Lastsystemen Overcommitment vermieden werden. Das gilt insbesondere, wenn die verwendeten Prozessoren keine Second Level Address Translation (SLAT) unterstützen Netzwerk-intensive Lasten erhöhen ebenfalls den CPU-Bedarf