Best Practices für SQL-Server, Teil 2: Virtualisierte Umgebungen

Wir schreiben das Jahr 2016, und teilweise gehen Anwender immer noch davon aus, dass man SQL-Server nicht in virtuellen Umgebungen ausführen kann. SQL-Server kann durchaus erfolgreich auf virtuellen Maschinen (VMs) genutzt werden. Allerdings ist das Programm ein Ressourcen-Fresser. Ohne bestimmte Best Practices geht es in virtuellen Umgebungen nicht. Genau die machen den Unterschied zwischen einer potenziell schlechten oder sehr guten Leistung. Im ersten Teil dieser Serie haben wir uns bereits mit grundlegenden Best Practices beschäftigt will man SQL Server optimal konfigurieren. Sie gelten im Übrigen auch für virtuelle Umgebungen.

Energiemanagement

Für den physischen VM-Host sollte im BIOS „High Performance“ eingestellt sein, um sicherzustellen, dass wirklich alle Ressourcen verfügbar sind. So kann der Hypervisor die abstrahierten Ressourcen entsprechend zuweisen.
Für Windows-VMs sollte man die Leistung stets auf „High Performance“ einstellen. „Balanced“ eignet sich insbesondere für Laptops, die Energie sparen müssen. Eine falsche Konfiguration führt bei VMs leicht zu ernsthaften Leistungsproblemen. In einigen Umgebungen kann man die Einstellungen für das Energiemanagement von VMs über den Hypervisor steuern. Sind jedoch ressourcenintensive Anwendungen wie SQL Server im Spiel sollte das Windows-Energiemanagement grundsätzlich im „High Performance“-Modus laufen.

Verwenden Sie SLAT-kompatible Serverhardware

Die meisten modernen Server verfügen über x64-Prozessoren, die SLAT (Second Level Address Translation) unterstützen. Bei älterer Hardware ist das möglicherweise nicht der Fall. VMware und Hyper-V-Hosts sollten mit 64-Bit-(x64-)Prozessoren (AMD oder Intel) ausgestattet sein. Der Hostprozessor muss unbedingt SLAT unterstützen. Für SLAT existieren unterschiedliche Herstellerbezeichnungen:

• Intel spricht von „Extended Page Tables“.
• AMD von „Nested Page Tables“ oder „Rapid Virtualization Indexing“.

SLAT ermöglicht dem Prozessor, das Mapping zwischen dem von den VMs genutzten virtuellen Speicher und dem physischen Speicher auf dem Hypervisor-Host beizubehalten. Ist der Prozessor dazu nicht in der Lage, muss der Hypervisor diese Speicherzuweisung übernehmen. Leistung und Skalierbarkeit sind jedoch deutlich höher, wenn der Prozessor diese Aufgabe erledigt.

Studien von Microsoft haben ergeben, dass SLAT

• den Verarbeitungsaufwand beim Host um etwa zwei Prozent senkt.
• die Speicheranforderungen des Host pro laufender VM um etwa 1 MB reduziert.

Die Hardware des VM-Hosts sollte also auf jeden Fall SLAT-kompatibel sein.

Überlasten Sie den VM-Host-Prozessor nicht

Diesen Punkt kann man nicht oft genug erwähnen. Werden auf den VMs eines überlasteten VM-Host ressourcenintensive Anwendungen wie SQL Server ausgeführt, sind Leistungsprobleme vorprogrammiert. Wenn sich nur einige schlanke Web-/Application-Server die Ressourcen teilen, kann der Hypervisor problemlos erkennen, welche VM wie viele Ressourcen benötigt. Bei ressourcenintensiven Anwendungen sieht das deutlich anders aus.

Bei einer extrem hohen Auslastung des virtuellen SQL-Servers sollte man unbedingt die neueste Version von Hyper-V oder vSphere einsetzen, da sich die Skalierbarkeit in der Regel mit jeder Version erhöht.

Eine bewährte Methode insbesondere für VMs, auf denen ressourcenintensive Anwendungen wie SQL Server gehostet werden: Stellen Sie sicher, dass die Gesamtanzahl der virtuellen Prozessoren, die der VM zugewiesen sind, die Anzahl der auf dem Host-Rechner verfügbaren physischen CPU-Steckplätze (im Unterschied zu den logischen Kernen) nicht übersteigt.

CPU Ready

CPU Ready ist ein Zeichen, dass der VM und/oder der Host überlastet sind. Damit bezeichnet man die Zeit, die eine VM warten muss, bis sie bedient wird, wenn die Ressourcen bereits von anderen VMs beansprucht werden.

Die Berechnung der Ready Time kann sich schwierig gestalten, da sie vom Abrufintervall für die Metrik abhängt, zum Beispiel 20 Sekunden (20.000 Millisekunden):
(CPU-Ready-Wert/20.000 ms) x 100 % = prozentuale Auswirkung auf die Performance pro 20-Sekunden-Intervall

Rechnet man den Wert hoch, ist schnell zu erkennen, zu welchen Leistungseinbußen das führen würde, insbesondere bei Applikationen wie SQL Server, die eine hohe Performance erfordern. Ready-Werte von weniger als 5 Prozent pro vCPU sind in der Regel in Ordnung. Ready-Werte über 5 Prozent pro vCPU sind ein Warnsignal, und wahrscheinlich hat sich dann die Leistung bereits verringert.

Ist die Konfiguration sogar falsch kommt man leicht auf CPU-Ready-Werte von >=10%, beispielsweise bei großen VMs mit mehreren vCPUs, die auf wenigen physischen Cores laufen, oder wenn das Verhältnis zwischen vCPU und pCPU nicht stimmt.

Eine überlastete VM mit z. B. acht vCPUs muss warten, bis alle acht pCPUs des VM-Host frei sind, bevor ihr Taktzyklen zugeteilt werden. Hier kommt es also auf das richtige Größenverhältnis an. Wenn eine VM wirklich eine große Anzahl von vCPUs benötigt, dann fügen Sie diese auf jeden Fall hinzu. Wenn Sie die Größenverhältnisse für eine neue Anwendung anpassen, dann fügen Sie nur vCPUs hinzu und behalten die Performance im Blick. Der Windows Task-Manager eignet sich nicht besonders gut um die Leistung in virtuellen Umgebungen zu überwachen. Überprüfen Sie die Performance besser von VM-Host-Seite aus. Sind alle vCPUs am Limit, sollten Sie weitere vCPUs einrichten. Ist das nicht der Fall, belassen Sie die Konfiguration so, wie sie ist. Es kommt vor, dass sich mit dem Entfernen von vCPUs aus einer VM die Leistung der Anwendungen mit Datenbanken, die auf diesem virtuellen SQL-Server gehostet wurden, tatsächlich verbessert hat.

Ist ein VM-Host überlastet, laufen mehrere VMs auf diesem Host, die um Ressourcen konkurrieren. In diesem Fall sollte man einige VMs auf andere Hosts migrieren, um Ressourcenkonflikte zu vermeiden.

Das Äquivalent zum CPU-Ready-Wert für Hyper-V ist der PerfMon-Zähler (Hyper-V – virtueller Prozessor des Hypervisors\CPU-Wartezeit pro Verteilung), der seit Windows Server 2012 zur Verfügung steht.

Hyper-Threading

Hyper-Threading ist eine Technologie von Intel, die zwei Hardware-Kontexte (Threads) aus einem einzigen physischen Kern verfügbar macht. Diese Threads werden logische CPUs genannt. Eine gängige Annahme ist, dass die Anzahl der CPUs oder Kerne durch Hyper-Threading verdoppelt wird. Das ist aber nicht der Fall. Hyper-Threading verbessert den Host-Durchsatz insgesamt um 10-30 Prozent, indem für eine höhere Auslastung der Prozessor-Pipeline gesorgt wird und der Hypervisor mehr Gelegenheit dazu bekommt, CPU-Taktzeiten zuzuteilen. Die Vorteile von Hyper-Threading sollte man unbedingt nutzen und es im BIOS des VM-Hosts aktivieren.

Cores pro Sockel

NUMA (Non-Uniform Memory Access) weist jedem Prozessor einen eigenen lokalen Speicher zu. Prozessor kombiniert mit Speicher bezeichnet man als NUMA-Knoten. Der Vorteil von NUMA besteht darin, dass ein Prozessor schneller auf seinen eigenen lokalen Speicher zugreifen kann, als das bei einem nicht lokalen Speicher möglich wäre. Sowohl Windows als auch SQL Server unterstützen NUMA und erstellen Zeitpläne für Threads auf Basis der NUMA-Topologie.

vNUMA veranschaulicht die NUMA-Architektur des physischen VM-Host gegenüber dem VM-Gastbetriebssystem. Die vNUMA-Topologie einer VM kann mehrere physische NUMA-Knoten umfassen. Sobald eine vNUMA-fähige VM eingeschaltet ist, kann die gegenüber dem Betriebssystem dargestellte Architektur nicht mehr verändert werden. Eigentlich ein positiver Aspekt, denn eine Änderung der vNUMA-Architektur kann dazu führen, dass das Betriebssystem instabil wird. Will man allerdings eine VM auf einen anderen VM-Host mit einer anderen NUMA-Architektur migrieren, bereitet das naturgemäß Probleme.

Bei VMs mit mehr als acht vCPUs ist vNUMA standardmäßig aktiviert (unabhängig von der Kombination aus Sockeln und Cores, die die Anzahl der vCPUs ergeben).

Best Practice:
Die Anzahl der virtuellen Sockel sollte der gewünschten Anzahl von vCPUs entsprechen (Einzelkern pro Sockel).

Dies ist die Standardeinstellung beim Einrichten einer VM. Diese Konfiguration wird als weit und flach bezeichnet. vNUMA präsentiert dem Gastbetriebssystem die optimale vNUMA-Topologie auf Basis der NUMA-Topologie des jeweiligen physischen VM-Hostservers. Ist eine VM-Konfiguration nicht weit und flach, kann vNUMA nicht mehr automatisch die beste NUMA-Konfiguration wählen. Stattdessen passt es sich an die eingegebene Konfiguration an. Das führt nicht selten zu Unstimmigkeiten in der NUMA-Topologie und das wiederrum beeinträchtigt die Performance.

Wenn Administratoren nicht gemäß dieser Best Practices vorgehen, sind meist Lizenzbeschränkungen der Grund. Wenn das der Fall ist, sollte man zumindest sicherstellen, dass die NUMA-Topologie des physischen VM-Host gespiegelt wird.

CPUs im laufenden Systembetrieb hinzufügen (CPU-Hot-Add)
Diese Einstellung birgt einige Fallstricke nebst der zugehörigen „Für“ und „Wider“.

Pro
CPU-Hot-Add erlaubt es VM-Administratoren, CPUs während des laufenden Betriebs hinzuzufügen, ohne dass die VM heruntergefahren werden muss. Das ermöglicht es Ressourcen dynamisch zu verwalten und CPUs hinzuzufügen, wenn vNUMA nicht benötigt wird (was üblicherweise bei kleineren VMs der Fall ist).

Kontra
Bei Aktivierung von CPU-Hot-Add auf einer VM wird vNUMA automatisch deaktiviert. SQL Server, die weiter sind als die NUMA-Architektur des physischen Servers, auf dem sie sich befinden, können die zugrunde liegende NUMA-Architektur nicht sehen, was zu Leistungseinbußen führt.

Ob Sie CPU-Hot-Add aktivieren sollten oder nicht, hängt davon ab, wie weit Ihre VM sein soll. Ich empfehle, die Funktion für größere VMs, die vNUMA benötigen, zu deaktivieren. Frei nach dem Motto „Vorsorgen ist besser als heilen“. Nehmen Sie sich deshalb am Anfang unbedingt die Zeit die richtige CPU-Anzahl für Ihre VM zu ermitteln, anstatt sich auf CPU-Hot-Add zu verlassen.

CPU-Affinität

CPU-Affinität: auf Produktionsrechnern besser nicht. Die Funktion schränkt die Fähigkeit des Hypervisors ein vCPUs auf dem physischen Server effizient zu planen.

Überlasten Sie den VM-Host-Arbeitsspeicher nicht

Auch diesen Punkt kann man nicht oft genug erwähnen. Stellen Sie bei der Konfiguration der Größenverhältnisse für eine SQL-Server-VM sicher, dass der Host nicht überlastet wird, sobald die SQL-Server-VM eingeschaltet wird. Denken Sie daran, dass der VM-Hostcomputer ebenfalls Arbeitsspeicher benötigt, um das Hypervisor-Betriebssystem auszuführen!

Arbeitsspeicher reservieren

In punkto Arbeitsspeicher ist SQL Server quasi ein schwarzes Loch. Die Anwendung schnappt sich so viel Speicher wie sie bekommen kann (und gibt ihn nicht mehr her). Deshalb kann es sinnvoll sein, die Reservierung von Arbeitsspeicher für die SQL-Server-VM auf den bereitgestellten Arbeitsspeicher (minus 4-6 GB zur Ausführung von Windows) zu setzen. Dadurch lässt sich die Wahrscheinlichkeit von Ballooning und Pufferaustausch deutlich reduzieren. Außerdem wird garantiert, dass die VM so viel Arbeitsspeicher bekommt wie sie braucht, um optimal zu funktionieren. Die Reservierung von Arbeitsspeicher kann allerdings verhindern, dass VMs zwischen Hosts migriert werden. Zum Beispiel, wenn der Zielhost nicht über ungenutzten Arbeitsspeicher mindestens in der Höhe der Speicherreservierung verfügt.

Und so berechnen Sie den Arbeitsspeicher, der für eine VM zur Verfügung gestellt werden sollte:

• VM-Arbeitsspeicher = max. SQL-Server-Arbeitsspeicher + Threadstapel + Betriebssystem-Arbeitsspeicher + VM-Speicher-Overhead
• Threadstapel = max. SQL-Server-Arbeitsthreads * Größe des Threadstapels
• Größe des Threadstapels = 1 MB bei x86, 2 MB bei x64, 4 MB bei IA-64

Dedizierter vs. dynamischer Arbeitsspeicher

Dedizierter Arbeitsspeicher widerspricht zwar den Grundregeln der Virtualisierung, aber es lohnt sich trotzdem es zu versuchen. So lassen sich nämlich Gerangel um die Ressourcen des VM-Host vermeiden.

Arbeitsspeicher ist einer der wichtigsten Faktoren für die SQL-Server-Leistung und verwendet Arbeitsspeicher für den internen Puffer (kürzlich verwendete Daten) und Caches (kürzlich ausgeführte T-SQL-Befehle). Dank dieser Puffer kann SQL Server die benötigten Daten und Befehle aus den Caches ziehen und muss nicht auf die Festplatte zugreifen. Es kommt damit nicht zum damit verbundenen I/O-Overhead.. SQL Server kann Puffer und Caches je nach Arbeitsauslastung und verfügbarem Arbeitsspeicher automatisch anpassen und verwalten. Steht jedoch kein Arbeitsspeicher zur Verfügung beeinträchtigt das die Leistung.

Wenn ein Virtualisierungs-Administrator dedizierten Arbeitsspeicher kategorisch ausschließt, dann fragen Sie nach dynamischem Hyper-V-Arbeitsspeicher oder VMware Memory Overcommitment.

VMware behandelt Arbeitsspeicher als teilbare Ressource, wobei jedes Megabyte als individueller Arbeitsspeicheranteil gilt. Bei Memory Overcommitment handelt es sich um einen automatischen, dynamischen Prozess, bei dem ungenutzte Speicheranteile von VMs bei Bedarf anderen VMs zugewiesen werden.

Arbeitsspeicher von VMs mit weniger Anteilen, wird VMs mit mehr Anteilen zugewiesen. Das stellt sicher, dass der SQL-Server-VM über ausreichend Speicheranteile verfügt.

Auch beim dynamischen Hyper-V-Arbeitsspeicher wird ungenutzter Arbeitsspeicher verteilt. Bei beiden Technologien behalten die VMs 25 Prozent des ungenutzten Speichers als Reserve, falls plötzlich mehr Arbeitsspeicher benötigt wird.

Datacenter- und Enterprise-Versionen ab SQL Server 2008 aufwärts unterstützen das Hinzufügen von Speicher im laufenden Systembetrieb (Hot Add Memory). Server-Betriebssysteme von Microsoft bieten diese Funktion bereits seit W2K3r2sp2.

Speichern Sie Dateien nicht auf derselben Festplatte

Wenn Sie eine VM mit den Standardeinstellungen erstellen und SQL Server mit den Standardeinstellungen installieren, landen sämtliche Betriebssystem-Dateien, SQL-Server-Datendateien, SQL-Server-Protokolldateien, SQL-Server-Backups usw. auf derselben virtuellen Festplatte.

SQL-Server-Binär- und Datendateien sollten jedoch grundsätzlich auf separaten VMDKs gespeichert werden.

Verwenden Sie RAID-10-Systeme für Benutzerdaten, Protokolldateien und tempdb-Datenbanken, um die bestmögliche Leistung und Verfügbarkeit zu gewährleisten.

Fazit

SQL Server in virtuellen Umgebungen kann die notwendige Leistung und Skalierbarkeit bereitstellen, um Datenbankanwendungen in Produktivumgebungen zu unterstützen. Sofern man Best Practices befolgt.

Quellen:
http://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf
http://download.microsoft.com/download/6/1/d/61dde9b6-ab46-48ca-8380-d7714c9cb1ab/best_practices_for_virtualizing_and_managing_sql_server_2012.pdf