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.
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
Hochverfügbarkeit
Sowohl Host-Clustering (mit Live Migration) als auch Guest Clustering (Windows/SQL Cluster in VMs) ist mit Hyper-V unterstützt (zu VMWare siehe unten). Beides kann für höchste Flexibilität und Ausfallsicherheit kombiniert werden.
Ebenso wird Database Mirroring und Log Shipping auch im virtualisieren Betrieb unterstützt.
Lizenzen
SQL Server Enterprise bzw. Datacenter können in Virtualisierungsszenarien durch die erweiterten Virtualisierungsrechte deutlich Kosten sparen. Details dazu finden Sie auf der SQL Server Lizenzierungs-Seite.
VMware und andere Hypervisor
Grundsätzlich werden VMware-Lösungen (und andere Hypervisor) als Virtualisierungsumgebung unterstützt, solange die konkrete VMWare- Version mit dem SVVP validiert ist. Details hierzu finden Sie hier.
Soll statt Hyper-V VMware eingesetzt werden so muss man sich insbesondere im Zusammenhang mit Clustern Gedanken machen. Man muss sich zwischen Host Clustering (vMotion) und Guest Clustering (SQL Server/Windows Server Cluster) entscheiden. Dies gilt es zu berücksichtigen, denn die beiden Technologien schützen gegen unterschiedliche Arten von Ausfällen. (mje)
Weiterführende Whitepaper
Zum Thema betrieb von SQL Server in Virtualisierungsumgebungen und Private Cloud Szenarien gibt es auf der SQL CAT Seite vier hilfreiche Whitepaper:
Running SQL Server 2008 in a Hyper-V Environment - Best Practices and Performance Recommendations oder die deutsche Übersetzung.
High Performance SQL Server Workloads on Hyper-V
Onboarding SQL Server Private Cloud Environment
Running SQL Server with Hyper-V Dynamic Memory - Best Practices and Considerations
Dieser Artikel unserer Kollegen der Computerwoche basiert unter anderem auf einem Blogbeitrag von Steffen Krause aus dem SQL Server Team Deutschland Blog auf Microsofts TechNet.