Woody - Fotolia
Best Practices für Hyper-V: Storage für virtuellen Maschinen optimieren
Unser Experte erklärt, mit welchen Storage-Best-Practices für Microsoft Hyper-V Sie die maximale Performance aus virtuellen Maschinen holen.
Beim Thema virtuelles Data Center wird oft Arbeitsspeicher als die wichtigste Hardwareressource genannt. Allerdings hat in der Regel Storage die größte Auswirkung auf die Performance virtueller Maschinen (VM). Microsoft Hyper-V ist im Hinblick auf nutzbare Storage-Typen ziemlich flexibel. Allerdings müssen Administratoren aufpassen. Es gibt einige Einschränkungen im Hinblick auf Funktionen und Voraussetzungen. In diesem Beitrag stellen wir Ihnen die Best Practices zu Storage und Microsoft Hyper-V vor.
Ausuferung virtueller Maschinen beschränken
Ein Problem, mit dem sich Administratoren bei Virtualisierung früher oder später befassen müssen, ist die Ausuferung (sprawl) virtueller Maschinen. Microsofts Lizenz-Politik für Windows Server 2012 Datacenter Edition und Tools wie System Center Virtual Machine Manager haben das Anlegen von virtuellen Maschinen zu einfach gemacht. Wenn Sie das nicht prüfen, können sich virtuelle Maschinen mit rasender Geschwindigkeit vermehren und ausbreiten.
Oft begegnet man dem Problem der Ausuferung, indem man Grenzen hinsichtlich VM-Kreation setzt. Es helfen auch Regeln, die alternde virtuelle Maschinen in die digitale Rente schicken. Sie müssen allerdings die Folgen der VM-Ausuferung auf die Storage-Infrastruktur im Auge behalten.
Werden mehr und mehr virtuelle Maschinen angelegt, kann der Storage-Verbrauch zu einem Problem ausarten. Häufiger ist allerdings der Streit um die Ressourcen (Resource Contention) ein größeres Problem. virtuelle Festplatten liegen oft auf gemeinsam genutzten Datenträgern oder in einem Storage-Pool. Somit konkurrieren die virtuellen Festplatten um IOPS.
Allerdings gibt es hier keine universelle, günstige und einfache Lösung für das Problem mit dem Ressourcen-Streit. Hyper-V bietet Administratoren aber einige verschiedene Mechanismen, wie Sie das Problem adressieren können.
Dem Ressourcen-Krieg mit Deduplizierung entgegenwirken
Eine der besten Strategien für die Reduzierung von Storage-IOPS ist die Deduplizierung des Dateisystems. Allerdings gibt es hier einige Einschränkungen, die Sie beachten müssen.
Microsoft hat mit Windows Server 2012 native Dateisystem-Deduplizierung eingeführt. Auf den ersten Blick schien dieses Feature vielversprechend zu ein. Es gab aber zwei große Einschränkungen. Native Deduplizierung war nicht zum neuen Dateisystem ReFS kompatibel. Weiterhin wurde Deduplizierung nicht für Datenträger unterstützt, auf denen mit laufenden virtuellen Maschinen verbundene virtuelle Festplatten liegen.
Bei Windows Server 2012 R2 hat Microsoft weiter an der Deduplizierungs-Funktion gearbeitet. Hier können Sie Deduplizierung auch bei Datenträgern einsetzen, die aktiv genutzte virtuelle Festplatten enthalten. Allerdings gibt es eine massive Einschränkung: Diese Art von Deduplizierung wird nur für virtuelle Desktops und nicht für virtuelle Server unterstützt.
Deduplizierung kann die IOPS reduzieren und die Performance von mit Hyper-V virtualisierten Servern verbessern. Sie profitieren von diesen Vorteilen allerdings nur dann, wenn die Deduplizierung auf Hardware-Ebene komplett transparent für den Hyper-V-Host und alle Gastbetriebssysteme ist.
QoS für effizientes Storage I/O managen
Ein weiteres Tool für die Reduzierung des Konkurrenzkampfes um Storage I/O ist eine neue Funktion in Windows Server 2012 R2, das sich Quality of Service Management nennt. Es war früher als Storage QoS bekannt. Durch den Einsatz dieser Funktion können Sie Storage IOPS für virtuelle Festplatten reservieren. Dabei spezifizieren Sie eine Mindestanzahl an IOPS, die in Schrittweiten von acht KByte auftreten. Ähnlich dazu können Sie auch die maximalen I/O-Operationen virtueller Festplatten begrenzen, indem Sie eine Obergrenze erlaubter IOPS festlegen.
Das Feature Quality of Service Management wird pro virtueller Festplatte eingesetzt und nicht auf einer Basis pro virtueller Maschine. Somit können Sie Quality-of-Service-Management-Regeln sehr granular vergeben und damit die bestmögliche Performance aus den verfügbaren IOPS herausholen.
Überlegungen zu Windows Storage Spaces
Windows Storage Spaces hat Microsoft mit Windows Server 2012 eingeführt. Damit können Sie physikalischen Storage in einen Pool an Storage-Ressourcen abstrahieren. Nun haben Sie die Möglichkeit, virtuelle Maschinen mithilfe dieses Storage-Pools anzulegen und brauchen sich nicht um die physikalischen Storage-Zuweisungen kümmern.
Microsoft hat die Funktion Windows Storage Spaces in Windows Server 2012 R2 noch erweitert. Es gibt neue Dinge wie Drei-Wege-Spiegelung und Storage Tiering (mehrstufige Speicherung). Sie können die mehrstufige Speicherung pro virtuelle Festplatte einsetzen. So genannte „Hot Blocks“ lassen sich dynamisch auf eine SSD-basierte (Solid-State Disk) Storage-Ebene umlagern. Das System liest diese dann so effizient wie möglich.
Die mehrstufige Speicherung verbessert die Performance virtueller Maschinen enorm. Allerdings gibt es einige Einschränkungen. Die dringlichste ist, dass sich Storage Tiers nur mit gespiegelten oder einfachen virtuellen Festplatten einsetzen lassen. Bei Datenträgern mit Parität funktioniert das nicht, obwohl das in der Preview-Ausgabe noch implementiert war.
Wenn Sie mehrstufige Speicherung mit einem gespiegelten Datenträger einsetzen möchten, braucht Windows die exakt gleiche Anzahl an SSDs im Storage-Pool wie die der gespiegelten Festplatten. Erschaffen Sie zum Beispiel einen Drei-Wege-Spiegel, brauchen Sie drei SSDs.
Angenommen Sie kreieren eine virtuelle Festplatte, die mehrstufige Speicherung benutzt. Hier können Sie die gewünschte Menge an SSD-Platz festlegen, die den schnellen Storage-Bereich zur Verfügung stellt. Sie sollten ungefähr abschätzen wie viel Platz Sie benötigen und legen dann ein GByte oben drauf. Der Grund dafür ist, dass Windows bei ausreichend Platz ein GByte des schnellen Bereichs als Write-Back Cache verwendet. Dieser Cache hilft beim Ausgleichen von Schreib-Operationen und verbessert somit die Schreib-Performance. Wenn Sie das Extra-GByte gleich von Anfang an einkalkulieren, dann können Sie sowohl Write-Back Cache als auch Hot Storage Blocks nutzen.
Einschränkungen bei ReFS
Mit Windows Server 2012 hat Microsoft das Resilient File System (ReFS) eingeführt. Dies ist ein Ersatz für das in die Jahre gekommene Dateisystem NTFS, das ebenfalls in Windows Server 2012 R2 verfügbar ist. Hyper-V-Administratoren müssen sich überlegen, ob Sie VM-Provisioning mit ReFS- oder NTFS-Datenträgern nutzen.
Betreiben Sie Hyper-V auf Windows Server 2012, sollten Sie vom Dateisystem ReFS möglichst die Finger lassen. Es gibt hier einige Einschränkungen. Die wesentlichste davon (zumindest für Virtualisierungs-Administratoren) ist wahrscheinlich, dass ReFS für die Benutzung mit Cluster Shared Volumes keine Unterstützung findet.
Bei Windows Server 2012 R2 unterstützt Microsoft die Benutzung von ReFS auf Cluster Shared Volumes aber. Allerdings gibt es auch hier einige Einschränkungen zu beachten. Zunächst ist es die Wahl eines Dateisystems eine quasi-permanente Entscheidung. Es gibt keine Option, NTFS nach ReFS und umgekehrt zu konvertieren.
Weiterhin gibt es da einige Funktionen in NTFS, die ReFS nicht hat. Microsoft hat durchblicken lassen, dass solche Features in Zukunft eingeführt werden. Für den Moment eine Liste, was fehlt:
- Datei-basierte Komprimierung
- Festplatten-Quotas
- Objekt-Identifizierung
- verschlüsseltes Dateisystem
- Benannte (Named) Streams
- Transaktionen
- Hard-Links
- Erweiterte Attribute (Extended Attributes)
Warum sollte bei dieser Anzahl an fehlenden Funktionen überhaupt jemand ReFS einsetzen wollen? Hierfür gibt es zwei Gründe: ReFS ist wirklich gut bei der Instandhaltung der Daten-Integrität und verhindert so genanntes Bit Rot (Speichermedienverfall). Weiterhin ist ReFS eine gute Wahl, wenn große Mengen an Daten gespeichert werden müssen. Das theoretische Limit des Dateisystems liegt bei einem Yottabyte.
Setzen Sie das Dateisystem ReFS auf einem Datenträger ein, auf dem VHD- oder VHDX-Dateien von Hyper-V liegen, müssen Sie das Integrity Bit für diese virtuellen Festplatten deaktivieren. Hyper-V schaltet das Integritäts-Bit bei neu angelegten virtuellen Festplatten automatisch ab. Haben Sie eine virtuelle Festplatte allerdings auf einem NTFS-Datenträger erstellt und ziehen diese auf ein ReFS-Volume um, müssen Sie diesen Schritt manuell erledigen. Ansonsten gibt Hyper-V beim Startversuch einer VM eine Reihe an Fehlermeldungen aus.
Sie können das Integrity Bit nur via PowerShell deaktivieren. Den Status können Sie mit diesem Befehl überprüfen:
Get-Item <virtual hard disk name> | Get-FileIntegrity
Müssen Sie das Integrity Bit deaktivieren, dient dazu dieser Befehl:
Get-Item <virtual hard disk name> | Set-FileIntegrity –Enable $False
Best Practices für Storage-Konnektivität
Mit welcher Art von Storage-Hardware Hyper-V eingesetzt werden kann, ist sehr flexibel. Die Software unterstützt Direct-Attached Storage, iSCSI, Fibre Channel (FC), virtuelles FC und so weiter. Die Performance kann allerdings von der Art der Anbindung beeinträchtigt werden. Das gilt auch für die Backup-Möglichkeiten.
Eine alte Weisheit besagt: „Nur weil Sie etwas tun können, müssen Sie es nicht zwangsläufig tun“. In der Hyper-V-Welt gilt dies im Speziellen für Pass-Through-Datenträger. Diese erlauben eine direkte Verbindung virtueller Maschinen zu physischen Festplatten. Sie würden damit eine virtuelle Festplatte außen vor lassen.
Das Problem bei der Nutzung von Pass-Through-Festplatten ist allerdings, dass sie für den Hyper-V VSS Writer nicht sichtbar sind. Backup-Applikationen, die auf Hyper-V VSS Writer setzen, können also keine Datei-, Ordner- oder Applikations-konsistente Backups von Datenträgern erstellen, die auf einer Pass-Through-Festplatte residieren. Man müsste die virtuelle Maschine als in einen gespeicherten Status versetzen. Erwähnenswert ist in diesem Zusammenhang, dass das nicht für virtuelles FC zutrifft.
Wann immer möglich, verwenden Sie iSCSI-Verbindungen vom Host-Betriebssystem aus und nicht innerhalb der virtuellen Maschine. Abhängig von einigen Faktoren, kann das sonst die Storage-Performance negativ beeinträchtigen. Die Faktoren sind etwa die Hyper-V-Version, das Gast-Betriebssystem und die Nutzung des Integrations-Service. Der Grund ist, dass eine Verbindung von der virtuellen Maschine zum Host keine Jumbo-Frames unterstützt.
Folgen Sie SearchStorage.de auch auf Twitter, Google+, Xing und Facebook!