Wer ein Cluster Shared Volume (CSV) als Speichersubsystem für seinen Hyper-V-Cluster einsetzen möchte, muss einige Designaspekte beachten. Dazu gehört in erster Linie die Art der Festplatten, die für die virtuellen Maschinen (VMs) zum Einsatz kommen.

Die Art der Speicherung virtueller Maschinen (VMs) beim Hyper-V spielt für die Definition der Sicherungsstrategie den zugehörigen Clustern eine wichtige Rolle. Generell stehen beim Hyper-V drei verschiedene Typen von Festplatten für eine »Virtual Hard Disk« (VHD; Virtuelle Festplatte) zur Verfügung:

• VHDs mit fester Größe (Fixed VHDs),
• dynamisch wachsende VHDs (»Dynamic VHDs«) sowie
• die »Pass-Through Disks«.

Zudem gibt es noch die differenzierenden Disks, die sich allerdings für einen Produktivbetrieb mit einer Server-Virtualisierung weniger eignen. Sie haben ihre Stärken eher im Bereich einer VDI (Virtual Desktop Infrastructure), wenn VMs schnell bereitgestellt werden müssen. Sie werden in den folgenden Überlegungen außen vor gelassen.

VHDs mit fester Größe gelten als die einfachste Variante. Beim Anlegen der VM werden sie vom Administrator definiert und belegen auch sofort den angegebenen Platz auf dem physischen Speicher. Angenommen eine fixe VHD wird mit einer Größe von 300 GByte angelegt, dann wird auch in etwa dieser Platz auf dem physischen Datenträger belegt. Bei diesem Typ fallen Erweiterungsaktionen weg, daher muss man sich nicht mit zusätzlichem Verwaltungsaufwand herumschlagen. Dieser Disk-Typus verspricht daher auch die höchste Performance. Allerdings wird viel Speicherplatz verbraucht, denn oftmals hat eine VM am Anfang nicht schon den kompletten Speicherbereich belegt.

Da bieten die dynamischen Disks eine bessere Speicherplatzausnutzung. Der Administrator gibt einen Maximalwert für die Größe der VHD an. Die VHD auf dem physischen Datenträger aber startet mit dem anfangs notwendigen Bereich und wächst im Verlauf des Betriebs dann bis zum Maximum an. Dabei handelt es sich um eine spezielle Form des Thin Provisioning. In Bezug auf die Performance ist zu sagen, dass Overhead anfällt, wenn die Disk vergrößert wird. Mit der aktuellen Variante des Hyper-V (als auf der Stufe des Windows Server 2008 Release 2) soll das aber so gut wie kaum mehr messbar sein – so zumindest der Originalton aus dem Hause Microsoft.

Die dritte Gattung sind die Pass-Through-Disks. Dabei handelt es sich um die Variante, bei der einer VM eine unformatierte LUN aus dem physischen Speicherbereich zugeweisen wird, die vom Gastbetriebssystem in der VM (genauer vom Installationsprogramm des Gastbetriebssystems) formatiert wird. Damit umgeht man zwei Probleme: Der Verwaltungs-Overhead für das Arbeiten mit der VHD entfällt – und somit steht die gesamte Performance des Speichersubsystems für die Applikationen in der VM zur Verfügung. Das kann einige zusätzliche Prozent an Durchsatz bringen. Zum anderen gibt es keine Einschränkungen in Bezug auf die Größe der VHD: Sie darf beim Hyper-V normalerweise maximal 2040 GByte betragen. Ist mehr Speicherplatz nötig, muss man definitiv zur Pass-Through-Disk greifen.

Pass-Through-Disk bereitet Probleme

Doch mit einer derartigen Disk handelt man sich auch Probleme ein: Die üblichen Operationen auf eine VHD – wie ein »VSS-Snapshot« einer VM (etwa für eine Sicherung auf Speicherebene) oder eine »Quick Storage Migration« (die über den »System Center Virtual Machine Manage« erfolgen kann) sind nicht machbar.

Zudem erfordert eine Pass-Through-Disk auch eine LUN für jede Disk. Das zieht wieder Probleme für die Speicherverwaltung nach sich – die Bereitstellung von weiterem Speicher kann dadurch recht komplex werden. Für einen Einsatz im Umfeld einer »Private Cloud« – mit einem Self Service Portal – wird man eine derartige Disk daher ebenfalls ausschließen müssen. Generell sollte man daher eine Pass-Through-Disk nur in den seltensten Fällen verwenden – vor allem wenn man eine unternehmenskritische Applikation damit betreiben will. Hier spielt die Robustheit eine wichtigere Rolle als die maximale Performance.

Aktuelle Hyper-V-Server sind optimiert

Der Hyper-V auf der Basis des Windows Server 2008 hatte dagegen noch seine Performance-Probleme mit den Dynamic Disks. Der Grund lag in den kleinen Häppchen, in denen weiterer Speicherplatz an die VHD zugeteilt wurde. Denn bei zusätzlichem Speicherbedarf musste die VHD sehr oft vergrößert werden und erst nach der Vergrößerung konnte eine Applikation dann weitere Daten in den Speicher schreiben.

Das wurde dann mit dem Release 2 verbessert – und mit weniger Erweiterungsaktionen lässt sich eben schneller in den Speicher schreiben. Damit konnte Microsoft sein Designziel – die Dynamic Disk soll fast genauso schnell sein wie die mit fester Größe – erreichen. Doch im Verlauf des Betriebs wird dieses Verhältnis sich verschlechtern. Denn mit wachsenden VHDs auf einem CSV wird der Speicherplatz zerstückelt. Immer mehr »Speicherscheibchen« für die betreffenden VMs liegen dann auf dem Speicher. Das gibt beim Lesen dann eine entsprechende Verzögerung – ganz so wie man das von defragmentierten Dateisystemen auf physischen Systemen her kennt.

Daher muss man den physischen Speicher immer wieder defragmentieren. Im Falle eines »Cluster Shared Volume« (CSV) bedeutet das allerdings, dass wieder der »Redirected Mode« zum Einsatz kommen muss. Denn es handelt sich dabei wieder um eine Low-Level-Aktion auf der LUN. Aber auch die Erweiterung einer dynamischen Disk darf nur vom »Coordinator« in einem Cluster ausgeführt werden. Falls die VM mit einer dynamischen VHD arbeitet und diese VM auf dem Coordinator des CSV läuft, kann der Coordinator diese Erweiterungsaufgabe ohne zusätzlichen Overhead erledigen.

Doch im anderen Fall – die VM läuft auf einem normalen Knoten in einem Hyper-V-Cluster – wird die Angelegenheit schon komplexer: Ist die dynamische VHD zu erweitern, muss das der Coordinator für das CSV erledigen. Dazu ist der Redirected Mode für die komplette CSV zu starten, ehe es an die Low-Level-Operationen gehen darf. Daraus kann man schon das Problem erahnen.

Schlimmer wird die Angelegenheit, wenn bei einem Hyper-V-Cluster gar mehrere CSVs im Einsatz sind. Wenn dann noch viele dynamische VHDs auf jedem CSV agieren, kommt es extrem häufig zu den Erweiterungsaktionen bei den VHDs. Und somit wird der Redirected Mode auch sehr häufig nötig sein – mit all seinen Einschränkungen. Für die Applikationen im Produktivbetrieb führt das bestimmt zu deutlichen Einschnitten in Sachen Performance.

Für diese Herausforderungen bieten sich zwei Auswege an: Zum einen kann der Administrator vorgeben, dass nur VHDs mit fester Größe zum Einsatz kommen. Das wird die beste Empfehlung sein – eventuell muss man eben mehr Speicherkapazität für das Storage-Subsystem spendieren.

Zum anderen könnte man die VMs mit den dynamischen VHDs auf den Knoten laufen lassen, die als Coordinator für das CSV dienen. Doch wer dann die Live Migration einsetzen möchte, der kann hier erneut auf größere Problem stoßen – wenn die VMs dann auch einen anderen Knoten verschoben werden.