07.07.2011 (rhh) Drucken
(4.5 von 5, 6 Bewertungen)

Konfigurationsoptionen für Disks in der ESX-Umgebung

  • Konfigurationsoptionen für Disks in der ESX-Umgebung
  • Erzeugen einer Disk im ESX-Umfeld
  • Raw-Device-Mapping kommt in zwei Modi
  • Das Provisionieren der Festplatten
  • Disks und die Controller-Typen

Die optimale Performance und höchste Effizienz der Disk-Subsysteme bei der Virtualisierungs-Plattform von VMware (die ESX-Umgebungen) lassen sich nur dann erzielen, wenn aus den verschiedenen Optionen der Massenspeicher die passende Variante gewählt wird. Hierzu muss der Administrator allerdings die entsprechenden Finessen beherrschen.

In der VMware-Welt – also den ESX-Umgebungen – gibt es einige Optionen für das Erzeugen von virtuellen Festplatten – die so genannten VMDK-Dateien. Sie nehmen ebenfalls die virtuellen Maschinen (VMs) auf. Dabei liegt der Fokus in diesem Beitrag auf den Unterschieden, die mit dem »Thin« und dem »Thick VM Disk Provisioning« bei ESX ins Spiel kommen. Zudem werden einige Empfehlungen und Richtlinien vorgestellt, die das Speichern von VMDK-Dateien auf »Direct Attached Storage« (DAS) und in Speichernetzwerken (SAN; Storage Area Networks) betreffen.

Hier ist vor allem das Thema Blockgröße wichtig, wenn man eine ESX-Speichergruppe formatiert. Denn falls man hier auf das falsche Pferd gesetzt hat, gilt es hinterher die bestehenden VMs zu sichern und anschließend die komplette Speichergruppe neu zu formatieren. Diese Parameter für die Konfiguration der Festplatten haben auch eine große Auswirkung auf die Funktionalität, die Performance und die Verwaltbarkeit des Speicher-Subsystems.

Erzeugen einer Disk im ESX-Umfeld

Will der Administrator einer VM in der ESX-Umgebung eine Disk hinzufügen, stehen ihm mehrere Optionen zur Verfügung. Er kann eine neue virtuelle Fest0platte erzeugen, eine bereits bestehende Virtual-Disk verwenden oder aber ein »Raw Device Mapping« anlegen. Die ersten beiden Optionen sind quasi selbsterklärend. Wenn aber ein »Raw Device Mapping« mit der Ablage der Daten in einem SAN zum Einsatz kommt, werden die Dateien nicht innerhalb einer VMDK-Datei eingekapselt. Wenn der Administrator dann die Dateien in der LUN (im SAN) durchsucht, wird er nur die einzelnen Dateien sehen und nicht eine einzige VMDK-Datei, die alle Dateien innerhalb der VM-Disk enthält.

Kommt ein Speichernetzwerk zum Einsatz, wird das Raw-Device-Mapping so angelegt, dass es Speicherbereiche auf eine LUN im SAN abbildet. Dieses Konzept verspricht eine bessere Performance, wenn es um sequentielle Schreib- und Lesevorgänge auf die Festplatte geht. Sind dagegen »Random IO Aktionen« nötig, liegt die Performance in etwa auf demselben Niveau wie bei Festplatten, die nicht über das Raw Device Mapping zur Verfügung gestellt werden. Doch der hauptsächliche Grund für den Einsatz des Raw Device Mappings liegt darin, wenn es darum geht, die physischen Eigenschaften der Disk für die SAN-Verwaltungs-Software nutzbar zu machen.

Raw-Device-Mapping kommt in zwei Modi

Das Raw-Device-Mapping lässt sich entweder im virtuellen oder im physischen Modus konfigurieren. Beim Virtual Mode wird das Raw Device Mapping wie eine jede andere VMDK-Datei dargestellt – mit all der Funktionalität einer normalen VMDK-Datei. Dazu gehören die Funktionalitäten wie Snapshots oder das Cloning. Im Physical Mode dagegen wird sozusagen die physische Hardware angezeigt. Eine Ausnahme macht das Kommando REPORT LUNS – es ist virtualisiert, so dass ESX verfolgen kann, welche VM die LUN verwendet.

Einige Hersteller von SANs haben VSS-Writer, die sich für Speicherfunktionen wie Snapshots, Backup oder Replikation verwenden lassen. Doch wer das Raw Device Mapping im Physical-Mode verwendet, der kann VMware-Snapshots, das Cloning und das Verschieben von VMs im laufenden Betrieb (VMotion) für die VMs nicht verwenden. Der Physical Mode wird von einigen SAN-Herstellern vorausgesetzt, um sicherzustellen, dass die VMs auch wirklich keine Aktionen ausführen, wenn ein SAN-Snapshot gezogen wird.

Dieses Ruhigstellen von VMs ist wichtig, um alle Arten von Datenänderungen mitschrieben zu können. Das gilt für Anwendungen in den VMs wie etwa Exchange Server oder SQL Server. Mit der Ruhigstellung wird vorübergehend der Transaktionsfluss in der VM angehalten. Wenn dann ein Snapshot gezogen wird, liegen nur komplett abgeschlossene Transaktionen in der Datenbank und alles befindet sich danach wieder in einem konsistenten Zustand. Ist dagegen eine VM nicht entsprechend ruhig gestellt, geht man das Risiko ein, dass eine Datenbank sich in einem inkonsistenten Zustand – bei dem eine Transaktion nur teilweise ausgeführt wurde – vorliegt und man einen inkonsistenten Zustand erhält.

Das Raw-Device-Mapping bei den Festplatten kann man auch dann einsetzen, wenn einem die VMDK-Datei selbst zu groß wird. Ist diese Datei größer als ein TByte, könnte das zu einem Problem werden. Weitere Hilfestellung dazu gibt es in der Regel vom Hersteller des SAN für derartige Fälle.

Das Provisionieren der Festplatten

 Beim Erzeugen einer VM-Disk stehen dem Administrator zwei Optionen offen: Zum einen kann er das »Thick Provisioning« verwenden – dabei wird von ESX die gesamte Größe der Disk in der Speichergruppe beim Erzeugen zugewiesen. Das ist dem Ansatz der »Static Disk« bei Microsofts Virtualisierungs-Plattform Hyper-V vergleichbar. Bei der zweite Option, dem Thin-Provisioning, wird nur der Speicherplatz zugewiesen, der aktuell in der VM-Disk verwendet wird. Damit spart das Thin-Provisioning (ähnlich wie die dynamisch anwachsenden Disks beim Hyper-V) zunächst Speicherplatz. Doch es gibt dafür einen Nachteil bei der Performance zu verzeichnen und zudem steigt die Wahrscheinlichkeit, dass man zu wenig Speicherplatz in der ESX-Speichergruppe zur Verfügung hat.

Wie groß die Performance-Einbuße gegenüber dem Thick-Provisioning ist, hängt von mehreren Faktoren ab. Dazu gehört die Geschwindigkeit der Festplattem, die Konfiguration des Speicher-Arrays und auch der Grad der Disk-Fragmentierung. Als eine generelle Aussage gilt, dass mit Thick Provisioning sich die beste Performance erzielen lässt und man zudem das Risiko vermeidet, dass zu wenig Speicherplatz zur Verfügung steht. Dafür muss man aber mehr Disk-Platz zur Verfügung stellen.

Wer auf das Thin-Provisioning bei den Disks setzen möchte, der sollte das nur für die Basis-Images der VMs machen und nicht für die Datenlaufwerke der VMs. Wenn der Administrator mehrere Datenlaufwerke mit jeweils ein TByte im Zuge des Thin-Provisionings bereit stellt, und wenn die Benutzer dann richtig loslegen und Daten auf diesen Laufwerken ablegen, kommt es recht schnell zur gefürchteten Situation: Der Speicherplatz in der ESX-Speichergruppe reicht nicht mehr aus.

Wer sich um die Disk-Fragmentierung in der Speichergruppe kümmern möchte, der kann Produkte von Drittherstellern einsetzen. Gute Kandidaten dazu sind »V-Locity« (von Diskeeper) oder »PerfectDisk 11 vSphere Bundle« (von Raxco Software).

Disks und die Controller-Typen

Beim Erzeugen einer VM hat der Administrator die Wahl zwischen IDE- oder SCSI-Disks. Wann  immer es möglich ist, sollte man allerdings die SCSI-Typen verwenden, denn sie liefern bessere Performance-Werte verglichen mit den IDE-Festplatten. Es kann allerdings sein, dass bestimmte Applikationen oder Betriebssysteme in einer VM nur mit IDE-Disks funktionieren.

Beim Erzeugen einer SCSI-Disk gilt es den passenden SCSI-Controller anzugeben. Je nachdem welches Windows-Betriebssystem in der VM zum Einsatz kommen soll, sind andere SCSI-Controller nötig. Zudem lassen sich als SCSI-Controllern auch die paravirtualisierten Treiber von Vmware verwenden. Allerdings sollte der Administrator diese Option nur bei den folgenden Umständen verwenden:

  • Die Laufwerke liegen in einem SAN und sind nicht direkt angeschlossen (DAS).
  • Die VM benötigt einen Disk-Durchsatz von mehr als 2000 I/O-Operationen pro Sekunde.
  • Die VM setzt als Gastbetriebssystem Windows Server 2008 R2, Windows Server 2008 oder Windows Server 2003 bzw. Red Hat Enterprise Linux (RHEL) 5 ein.
  • Bei dem Laufwerk handelt es sich nicht um ein Boot-Laufwerk.
  • Die VCM ist nicht fehlertolerant ausgelegt.
  • Die VM wird nicht als Teil eines Microsoft-Clusters eingesetzt.
Als generelle Regel zur Performance lässt sich zu den paravirtualisierten Treibern von VMware sagen: Sie liefern eine etwa um 10 Prozent besseren Disk-Durchsatz und eine um zirka 15 Prozent geringere CPU-Ausnutzung als der LSI Logic SCSI-Controller, wenn die VMDK-Datei in einem SAN abgelegt wird.
Weitere Informationen:
Den Vergleich zwischen virtuellen Festplatten der Virtualisierungs-Plattformen Hyper-V und ESX bietet ein ausführlicher Beitrag in der Print-Ausgabe Juli 2011 von NT4ADMINS. Wer Interesse an dieser Ausgabe hat, kann sich ein kostenloses Probeexemplar bestellen. Dazu muss nur eine Mail an rhh@oberland.net mit dem Betreff »Disk-Optionen beim Hyper-V« und den Zusendedaten geschickt werden.