27.09.2011 - 

Ratgeber

SQL Server in virtualisierten Umgebungen betreiben

Malte Jeschke ist Leitender Redakteur bei TecChannel. Seit vielen Jahren beschäftigt er sich intensiv mit professionellen Drucklösungen und deren Einbindung in Netzwerke. Daneben gehört seit Anbeginn sein Interesse mobilen Rechnern und Windows-Betriebssystemen. Dank kaufmännischer Herkunft sind ihm Unternehmensanwendungen nicht fremd. Vor dem Start seiner journalistischen Laufbahn realisierte er unter anderem für Großunternehmen IT-Projekte.
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.

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

Newsletter 'Technologien' bestellen!