Zum Thema betrieb von SQL Server in Virtualisierungsumgebungen und Private Cloud Szenarien gibt es auf der SQL CAT Seite vier hervorragende Whitepaper:

Für diejenigen, die nicht die Zeit haben um sich die Whitepaper durchzulesen möchte ich hier die wichtigsten Fakten (ohne Anspruch auf Vollständigkeit) einmal zusammenstellen

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 2 Schritten: Vorbereiten (danach sysprep und Template erstellen) und abschließen. Dokumentation: http://msdn.microsoft.com/de-de/library/ee210754.aspx
  • Stellen Sie unbedingt sicher, dass die Hyper-V Integrationskomponenten (bzw. das Äquivalent für die verwendete Virtualisierungsumgebung) in der jeweils aktuellen Version installiert sind, verwenden Sie keine emulierten Geräte

Migration

  • Um festzustellen, welche SQL Server Instanzen in die virtuelle Umgebung migriert werden können verwendet man am einfachsten das MAP Toolkit Demo von mir hier

Dynamic Memory

  • SQL Server unterstützt Hyper-V 2008 R2 SP1 Dynamic Memory
  • 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. Siehe mein Webcast SQL Server Storage Performanceanalyse
  • Daher 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 4 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 Lastsysteme 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ütz (zu VMWare siehe unten). Beides kann für höchste Flexibilität und Ausfallsicherheit kombiniert werden.
  • Ebenso ist Database Mirroring und Log Shipping auch im virtualisieren Betrieb unterstützt

Lizenzierung

  • SQL Server Enterprise bzw. Datacenter können in Virtualisierungsszenarien durch die erweiterten Virtualisierungsrechte deutlich Kosten sparen
  • Details dazu auf der SQL Server Lizenzierungs-Seite

VMWare (und andere)

  • Grundsätzlich ist VMWare (und andere Hypervisor) als Virtualisierungsumgebung supportet, solange die konkrete VMWare Version mit dem SVVP validiert ist. Details: http://support.microsoft.com/kb/956893/en-us
  • Soll statt Hyper-V VMWare eingesetzt werden so muss man sich die Limitationen von ESX, insbesondere in Zusammenhang mit Clustern klar machen. So vMotion nicht in Kombination mit Windows Clustering unterstützt. Man muss sich also zwischen Host Clustering (vMotion) und Guest Clustering (SQL Server/Windows Server Cluster) entscheiden. Das ist nicht gut, denn die beiden Technologien schützen gegen unterschiedliche Arten von Ausfällen. Ebenso ist iSCSI nicht unterstützt.
    Quelle: http://www.vmware.com/pdf/vsphere4/r41/vsp_41_mscs.pdf Seite 11

Gruß,
Steffen