Speicheroptionen für den SQL Server in virtuellen Umgebungen

Ist in einem Unternehmen die Entscheidung gefallen, dass alle Applikationen bereits in virtuellen Umgebungen zum Einsatz kommen, dann gilt das in der Regel auch für die Datenbanken wie etwa den SQL Server. Doch wenn dabei ein hoher Bedarf an Ein-/Ausgabeoperationen gegeben ist, war das Virtualisieren der Datenbank-Server bislang kein so guter Vorschlag.

Wer allerdings auf moderne Hypervisor-basierte Server-Virtualisierungslösungen wie Vmwares Vsphere 4 oder Microsofts Hyper-V setzt, der kann sich durchaus auf dieses Abenteuer einlassen. Doch dazu muss er die grundlegenden Prinzipien zum Speichersubsystem in virtuellen Umgebungen verstehen.

In den meisten Firmen wird der Ansatz „Virtualisieren von SQL-Servern“ Schritt für Schritt angegangen. Ist die Entscheidung gefallen, die ersten Datenbank-Systeme in virtuellen Infrastrukturen zu betreiben, treten in der Regel die ersten Bedenken auf. Das ist auf alle Fälle eine positive Entwicklung, denn derartige Bedenken sind im Vorfeld durch eine sorgfältige Planung zu adressieren.

Für das Virtualisieren von SQL-Servern wird hier gezeigt, welche Aspekte es zu berücksichtigen gilt, damit der bestmögliche Datendurchsatz in der virtuellen Umgebung zur Verfügung steht.

Ganz egal, ob als Virtualisierungs-Plattform Vsphere 4 oder Hyper-V zum Einsatz kommt – der IT-Verantwortliche muss ein besonderes Augenmerk auf seine hoch ausgelasteten Datenbank-Festplatten legen. Denn sie benötigen die entsprechende Ein-/Ausgabe-Ressourcen, um die bestehenden Anforderungen der Anwendungen zu erfüllen – und um auch für die Zukunft gerüstet zu sein. Generell stehen drei Speicheroptionen für die virtuellen Maschinen zur Verfügung:

• Der Einsatz von traditionellen virtuellen Festplatten. Beim Hyper-V tragen sie die Bezeichnung „Virtual Hard Disks“ (mit der Dateiendung .vhd) und bei Vsphere 4 werden sie als „Virtual Machine Disks“ (.vmdk) bezeichnet.
• Das Mounten eines Volumes (oder einer LUN in einer Umgebung, die auf ein Speichernetzwerk – SAN—setzt) zu einer Virtuellen Maschine (VM), das durch den Hypervisor bereitgestellt wird: Beim Hyper-V wird das als eine „Pass Through Disk“ bezeichnet, in der Vsphere-Welt als ein „Raw Device Mapping“.
• Der Einsatz von ISCSI, um ein Fibrechannel-basierten Speicher-Array direkt mit der VM zu verbinden. Um diese Option nutzen zu können, muss das betreffende Speicher-Array als Schnittstelle ISCSI unterstützen oder aber es muss ein spezielles System in der Speicherumgebung vorhanden sein, das den ISCSI-Verkehr zu und vom Speicher-Array entsprechend umsetzt.

Der Einsatz der virtuellen Festplatten

Üblicherweise legt ein Systemverwalter die virtuellen Festplatten standardmäßig an. Dabei handelt es sich um Dateien, die im Speicherbereich des Virtualisierungs-Hosts angelegt werden – entweder als lokaler Speicher oder aber als Speicher, der in Form eines Speicher-Arrays zur Verfügung gestellt wird. Diese Dateien werden dann in der jeweiligen VM als physikalische Festplatten gemappt.

Der Host selbst wird dazu einen Satz von Festplatten in einem RAID-Array verwenden (das ist nichts anderes als ein Satz von Festplatten, die an den Server etwa über eine SCSI-Verbindung angeschlossen sind) oder aber auf ein Speicher-Array über ein Fibrechannel-Netzwerk zugreifen. Das Gastbetriebssystem, das in der VM zum Einsatz kommt, wird diese Festplatten dann als traditionelle SCSI-Festplatten sehen. Dabei hängt die Performance dieser virtuellen Festplatten von einigen Faktoren ab:

• Wie viele physikalische Festplatten die Daten beherbergen,
• wie schnell diese physikalischen Festplatten sind,
• wie viele andere VMs auf dasselbe physikalische RAID-Array verwenden  und
• wie viel Ein-/Ausgabelast die anderen VMs auf dem physikalischen RAID-Array aufbrauchen.

Angenommen für eine Virtualisierungs-Plattform stehen fünf Festplatten in einem RAID-5-Array zur Verfügung und 40 VMs verwenden dieses einzige RAID-Array, um dort die jeweiligen Daten abzuspeichern, dann wird womöglich nicht genügend Ein-/Ausgabe-Durchsatz für das SQL-Server-System zur Verfügung stehen, es sei denn es stellt nur minimale Anforderungen an den Ein-/Ausgabedurchsatz.

Handelt es sich dabei allerdings nicht um übliche Fibrechannel-Festplatten, sondern um schnelle Enterprise-SSDs (Solid State Disks), dann ist unter Umständen wieder genügend Ein-/Ausgabe-Durchsatz verfügbar. Denn die SSDs unterstützen zumindest beim Lesen und beim sequentiellen Schreiben viel höhere Datenraten als die traditionellen rotierenden Festplatten. Denn bei einer SSD fallen zum Beispiel keine Positionierzeiten für die Leseköpfe an, wie das bei den normalen Festplatten der Fall ist.

Es tritt aber ein Nachteil beim Einsatz von virtuellen Festplatten auf. Bei Vmware geht man dabei von einem reduzierten Durchsatz auf, der im Bereich von zwei bis drei Prozent liegt. Beim Hyper-V dürfte dies in etwa auf demselben Niveau liegen. Wenn man ein RAID-Array einsetzt, auf dem nur die Datendateien eines SQL-Server abgelegt werden, sollte das eine akzeptable Lösung darstellen – wenn man diese geringe Reduzierung der Performance verkraften kann.

Das Mounten eines Volumes

Abstrakt betrachtet besteht zwischen den Pass Through Disks und dem Einsatz von Raw Device Mapping kaum ein Unterschied. Das betreffende Volume (oder die LUN) wird vom Host-Betriebssystem gemountet – so wie das in der Abbildung 1 gezeigt ist. Dann wird das Volume direkt dem Gastbetriebssystem zugewiesen – und zwar über die geeigneten Verwaltungs-Tools. Damit bekommt das Gastbetriebssystem die vollständige Kontrolle über das Volume.

Mit diesem Ansatz kann das Gastbetriebssystem dann das Volume formatieren und dabei die passenden Dateisysteme verwenden. Das hat zur Folge, dass weniger Overhead im Spiel ist, der vom Host-Betriebssystem her kommt. Auch wenn der Overhead bei virtuellen Festplatten an sich schon recht gering ist (die bereits angesprochenen zwei bis drei Prozent), wird er bei einer derartigen Konstellation sogar noch geringer sein. Das White Paper aus dem Hause Microsoft namens „High Performance SQL Server Workloads on Hyper-V” verdeutlicht die Performance, die Pass Through Disks beim Hyper-V aufweisen. Die Werte für Vsphere dürften dabei in derselben Größenordnung liegen.

Ein weiterer Vorteil der Pass Through Disks beziehungsweise des Raw Device Mapping ist der direkte und somit effektive Zugriff der VM direkt auf das SCSI-Array (oder das Fibrechannel-Netzwerk in einem Storage-Array). Und zudem bleibt es immer noch der Zugriff aus einer VM – damit verliert es nicht den Vorteil der Live Migration oder der Vmotion-Funktionalität (also das Umziehen einer VM von einen Host auf einen anderen physikalischen Rechner beim laufenden Betrieb).

Als Nachteil ist dafür aber zu verbuchen, dass eine aufwändigere Konfiguration nötig ist – die auch den ein oder anderen Systemverwalter überfordern kann. Zudem ist diese komplexere Konfiguration dann auch schwieriger anderen Administratoren, die darin noch wenig Erfahrung haben, zu vermitteln.

Ein weiterer Nachteil betrifft die Kosten für das Mounten eines Volumes direkt zu einer VM. In diesem Fall muss man dedizierte Ressourcen für die eine VM vorhalten. Kommt „Direct Attached Storage“ (DAS, also Festplatten, die direkt in den Server oder ein direkt angebundenes Chassis eingebaut sind) zum Einsatz, sind auch dedizierte Festplatten und womöglich sogar ein RAID-Controller dafür nötig – je nach den Anforderungen des virtuellen Servers (sprich der VM). Diese physikalischen Ressourcen sind dann direkt der einen VM zugeordnet und damit können ihre Kosten nicht auf andere VMs verteilt beziehungsweise verrechnet werden.

In einer SAN-Umgebung warden dedizierte LUNs für die betreffende VM nötig. Auch wenn diese LUNs auf Festplatten liegen können, die auch von anderen physikalischen oder virtuellen Servern verwendet werden dürfen, so muss dieser Platz doch vom Speicher-Administrator zugewiesen und verwaltet werden. Wenn man eine LUN direkt einer VM zuweist und dazu die Pass Through Disks oder das Raw Device Mapping verwendet, muss man genau wissen, wie sich der andere Ein-/Ausgabeverkehr verhält, der von anderen LUNs kommt und sich auf dieselben physikalischen Festplatten bezieht.

Der Einsatz von ISCSI

Setzt ein Unternehmen bereits auf Speicher-Arrays, so besteht die Möglichkeit, ISCSI vom Speicher-Array aus direkt zur VM zu verwenden. Ehe man sich für diese Variante entscheidet, muss man allerdings mit dem Speicher-Administrator abklären, ob das Speicher-Array auch ISCSI unterstützt. Die meisten der neueren Speicher-Arrays unterstützen ISCSI bereits nativ – wie das auch vom Prinzip her in Abbildung 2 zu sehen ist.

Wer dagegen noch ein älteres System einsetzt, der hat damit womöglich Schwierigkeiten. In diesem Fall ist im Speichernetzwerk ein Fibrechannel-Switch nötig, der zudem noch ISCSI unterstützt. Über dieses gerät ist dann der Zugriff auf das Speicher-Array über ISCSI machbar – ohne dass das Array ISCSI nativ unterstützen muss.

Wenn ein Gastbetriebssystem über ISCSI auf ein Speicher-Array zugreift, umgeht es den Speicher-Treiber des jeweiligen Host-Systems. Das verringert zwar die Belastung des Speicher-Treibers, doch dafür bekommen der Ethernet-Treiber des Host-Systems sowie die komplette Ethernet-Infrastruktur eine zusätzliche Last aufgebürdet. Solange die Ethernet-Infrastruktur nicht schon hoch belastet ist, lassen sich damit gute Resultate für den Speicherzugriff aus dem Gastbetriebssystem erzielen.

Fällt die Entscheidung, dass ISCSI Verwendung finden soll, wird man einige Konfigurationsänderungen bei den Gastsystemen vornehmen. Typischerweise gilt es den ISCSI-Verkehr zu isolieren und dazu ein eigenes Netzwerk zu konzipieren. Das lässt sich zum einen über zusätzliche physikalische Netzwerk-Switche erreichen. Zum anderen kann der Administrator über die virtuellen LANS (VLANs) in seinen bestehenden Netzwerk-Switches diese Aufteilung vornehmen.

In beiden Fällen aber muss man zumindest eine physikalische Netzwerkinterfacekarte (NIC, Network Interface Card) auf dem Host für dieses Netzwerk (sprich ISCSI) vorsehen. Damit kann man den ISCSI-Verkehr effizienter leiten, sprich er muss nicht über verschiedene Subnetzwerke geroutet werden.

Nachdem diese Konfiguration gemacht wurde, empfiehlt sich noch das Hinzufügen einer virtuellen NIC (vNIC) in der VM, die Zugriff auf das ISCSI-Netzwerk bekommen soll. Damit wird dann der normale Verkehr der VM über das lokale Netzwerk (LAN) geroutet und der ISCSI-Verkehr läuft über ein eigenes dediziertes ISCSI-Netzwerk. Ein Beispiel dazu zeigt die Abbildung 3.

Auch wenn ein dediziertes Netzwerk nicht unbedingt nötig ist, so ist es dennoch für die meisten Konfigurationen empfohlen. Den ISCSI produziert üblicherweise viel Netzwerkverkehr. Und dieser Netzwerkverkehr kann zur Folge haben, dass die CPU-Belastung auf den Netzwerk-Routern sehr hoch ansteigt. Zudem sind noch alle weiteren Netzwerkgeräte einzurechnen, über die der ISCSI-verkehr läuft.

Auch da wird es zu Verzögerungszeiten kommen, bis der Zugriff auf das Speicher-Array erfolgt. Damit werden die betreffenden Speicher-Kommandos auch mit mehr Verzögerung ausgeführt und dauern länger.

Läuft der ISCSI-Verkehr über eine dedizierte Netzwerkverbindung vom Host zum Ethernet-Netzwerk wird die Wahrscheinlichkeit reduziert, dass die Netzwerk-Ports des Host-Systems überlastet werden. Das ist auch dann der Fall, wenn das physikalische Netzwerk zwischen dem ISCSI-Netzwerk und dem LAN denselben Netzwerk-Switch verwendet.

Mapping der physikalischen Hostbusadapter

Wer in einer virtuellen Umgebung auf  der Basis von Vsphere 4 arbeitet, dem steht noch eine vierte Option offen: Es handelt sich um das Mapping von physikalischen Hostbusadaptern (HBAs) auf eine einzige VM. Damit wird diese VM quasi direkt in ein Fibrechannel-Netzwerk eingebracht (siehe Abbildung 4).

Nachdem dieses Mapping des HBA erfolgt ist, muss nur noch das Zoning so eingestellt werden, dass der Zugriff auf das Speicher-Array gelingt. Unter Zoning versteht man den Vorgang, eine logische Verbindung zwischen zwei Ports herzustellen, so dass diese Ports miteinander sprechen können.
Der Vorteil des physikalischen HBA-Mappings liegt auf der Hand: Es bietet einen direkt, sehr schnellen Zugriff auf das Fibrechannel-Netzwerk. Doch leider kommen auch zwei Nachteile ins Spiel:

• Wenn man einen HBA auf eine VM mappt, kann keine andere VM und auch nicht das physikalische System diesen HBA verwenden. Verfügt ein System über zwei HBA und weist man einen davon einer VM zu, bleibt nur ein HBA für den physikalischen Server übrig. Und wenn man gar die beiden HBA der einen VM zuweist, bleibt für den Host gar kein HBA mehr übrig. Das bedeutet in letzter Konsequenz, dass der Hast gar nicht mehr mit dem Speicher-Array kommunizieren kann.
• Der zweite Nachteil wirkt sich bei der betreffenden VM aus: Sie kann dann nicht mehr von einem Host auf einen anderen – über Vmotion—im laufenden Betrieb verschoben werden. Der Grund ist klar: Da der HBA sich im physikalischen Server befindet, lässt sich die VM nicht auf einen anderen Server verschieben – der ja womöglich gar keinen passenden HBA besitzt. Deswegen muss der Administrator bei diesem Ansatz die VM herunterfahren, dann das Mapping zwischen der VM und dem HBA aufheben. Danach ist ein passendes Mapping auf dem neuen System zu erzeugen, anschließend das Zoning auszuführen und anschließend die VM neu zu starten. Dabei sind auch alle notwendigen Änderungen an den HBA-Treibern noch einzubeziehen. Da in einem derartigen Fall die VM für eine gewisse Zeit nicht verfügbar ist, eignet sich der Ansatz für einen SQL Server wohl kaum. Denn eine VM mit einem SQL Server wird in der Regel hochverfügbar sein müssen. Wenn aber in erster Linie eine maximale Performance für den SQL Server beim Speicherzugriff über ein Fibrechannel-Netzwerk gefordert ist, kann es eine valide Option darstellen.

Fazit

Beim Virtualisieren der SQL-Server-Umgebung wird man sicher nicht die High-end-Speicherlösungen für jede VM mit einem SQL Server benötigen. Die meisten Speicher-Arrays haben Grenzen in Bezug auf die LUNs, die sie maximal unterstützen  und wie viele physikalische oder virtuelle Server sich damit verbinden können. Es gilt daher eine Lösung zu finden, den Speicherzugriff mit der notwendigen Performance bietet und dabei die geringstmöglichen Kosten – bei einem möglichst geringen Aufwand für die Speicherverwaltung – verursacht.

In den Aussagen des Performance Monitors zu den Ein-/Ausgabeoperationen pro Sekunde kann der Administrator die aktuelle Auslastung seiner physikalischen Infrastruktur festhalten und sie dann mit denen vergleichen, die die verschiedenen Speicheroptionen in der virtuellen Umgebung liefern. Wer die Ausgangslage seiner Speicheranforderungen genau kennt, kann dann die passenden Entscheidungen treffen.

Denny Cherry/rhh