Die fünf wichtigsten Hyper-V Best Practices

Die Microsoft Hyper-V Virtualisierungstechnologie ist seit über einem Jahr auf dem Markt. In verschiedenen Artikeln von Tech OnTap wurde der Einsatz von Hyper-V mit NetApp Technologie bereits vorgestellt. Unter anderem wurde ein Überblick und eine Kundenreferenz veröffentlicht.

NetApp war an zahlreichen Implementierungen von Hyper-V beteiligt und hat dafür eine detaillierte Sammlung an Best Practices. Tech OnTap bat mich, die fünf wichtigsten Best Practices für Hyper-V mit NetApp vorzustellen und dabei ein besonderes Augenmerk auf das vor kurzem veröffentlichte Hyper-V Server 2008 R2 zu legen.

• Netzwerkkonfiguration
• Einrichtung der korrekten iGroup und des korrekten LUN-Protokolltyps
• Virtual Machine Disk Alignment
• Einsatz von Cluster Shared Volumes (CSVs)
• Optimale Nutzung von NetApp Storage Software und Tools

Alle Details hierzu sowie weitere Informationen finden Sie unter NetApp Storage Best Practices zur Microsoft Virtualisierung, wo jetzt auch Hyper-V R2 Bezug genommen wird.

BP 1: Netzwerkkonfiguration in Hyper-V Umgebungen

Im Hinblick auf die Netzwerkkonfiguration gibt es zwei wichtige Best Practices:

• Stellen Sie sicher, dass Sie bei Hyper-V Servern die korrekte Anzahl an physischen Netzwerkadaptern bieten.
• Nutzen Sie sofern möglich die neuen von Hyper-V R2 unterstützen Netzwerkfunktionen.

Physische Netzwerkadapter. Wurden nicht genügend Netzwerkverbindungen konfiguriert, kann dies den Anschein erwecken, als hätten Sie ein Storage-Problem, insbesondere bei der Verwendung von iSCSI. Bei kleineren Umgebungen sind mindestens zwei oder drei Netzwerkadapter erforderlich, während bei größeren Umgebungen mindestens vier oder fünf erforderlich sind. Möglicherweise benötigen Sie deutlich mehr. Hier die Gründe dafür:

• Management. Microsoft empfiehlt einen spezifischen Netzwerkadapter für Hyper-V Server Management.
• Virtual Machines. Für virtuelle Netzwerkkonfigurationen der externen Art ist mindestens ein Netzwerkadapter erforderlich.
• IP-Storage. Microsoft empfiehlt, der IP-Storage-Kommunikation ein spezifisches Netzwerk zuzuweisen, daher ist ein Adapter erforderlich. Zur Unterstützung von Multipathing sind mindestens zwei Adapter erforderlich.
• Windows Failover Cluster. Für Windows Failover Cluster ist ein eigenes Netzwerk erforderlich.
• Live-Migration. Diese neue Hyper-V R2 Funktion unterstützt die Migration zwischen Hyper-V Servern von Virtual Machines während des Betriebs. Microsoft empfiehlt die Konfiguration eines spezifischen physischen Netzwerkadapters für den Datenverkehr von Live-Migrationen.
• Cluster Shared Volumes. Microsoft empfiehlt ein spezifisches Netzwerk zur Unterstützung des Kommunikationsverkehrs dieser neuen Hyper-V R2 Funktion.

Die folgenden Tabellen sind Ihnen bei der Auswahl der richtigen Anzahl an physischen Adaptern behilflich.

Tabelle 1) Standalone Hyper-V Server

Tabelle 2) Clustered Hyper-V Server

Tabelle 3) Clustered Hyper-V Server mit Live-Migration

Tabelle 4) Clustered Hyper-V Server mit Live-Migration und CSV

Neue Netzwerkfunktionen. Windows Server 2008 R2 unterstützt eine Reihe neuer Netzwerkfunktionen. NetApp empfiehlt, diese Funktionen auf Ihren Hyper-V Servern zu konfigurieren und soweit wie möglich von ihnen zu profitieren. Möglicherweise werden nicht alle oder keine dieser Funktionen von Ihrem Server und Ihrer Netzwerk-Hardware unterstützt. (Einzelheiten hierzu finden Sie in der Randleiste.)

BP 2: Auswahl der korrekten iGroup und des korrekten LUN-Protokolltyps

Wenn Sie eine NetApp LUN für die Verwendung mit Hyper-V bereitstellen, müssen Sie bestimmte Initiatorgruppen (iGroups) und den korrekten LUN-Typ angeben. Durch falsche Einstellungen kann die Implementierung erschwert und die Performance beeinträchtigt werden.

Initiatorgruppen. FCP- und iSCSI-Storage müssen maskiert werden, damit eine Verbindung mit dem entsprechenden Hyper-V Server und den Virtual Machines (VMs) hergestellt werden kann. Bei NetApp Storage wird die LUN-Maskierung von iGroups übernommen.

• Beim Einsatz von individuellen Hyper-V Servern oder VMs sollten Sie für jedes System und jedes vom System verwendete Protokoll (FC und iSCSI) eine iGroup erstellen, über die das System eine Verbindung zum NetApp Storage-System herstellen kann.
• Beim Einsatz von einem Cluster von Hyper-V Servern oder VMs sollten Sie eine individuelle iGroup für jedes Protokoll erstellen, das das Cluster-System verwendet, um eine Verbindung zum NetApp Storage-System herzustellen.

iGroups lassen sich einfacher mit NetApp SnapDrive verwenden. SnapDrive räumt mit allen Unklarheiten auf, da es erkennt, welches Betriebssystem Sie verwenden, und die Einstellung für Ihre iGroups entsprechend konfiguriert.

LUN-Typen. Die Einstellung des LUN-Protokolltyps ist ausschlaggebend für das Layout der LUN auf Datenträgern. Es ist wichtig, den korrekten LUN-Typ anzugeben, um sicherzustellen, dass die LUN auf das vorhandene File-System ausgerichtet ist. (Im Folgenden Tipp finden Sie die Erklärung hierfür.) Dieses Problem ist nicht auf NetApp Storage beschränkt. Bei jedem Storage-Anbieter oder jeder Host-Plattform kann dieses Problem auftreten.

Tipp: Der von Ihnen angegebene LUN-Typ ist abhängig von Ihrem Betriebssystem, der Betriebssystemversion, dem Festplattentyp und der Data ONTAP Version. Alle Informationen zu LUN-Typen für verschiedene Betriebssysteme finden Sie im Block Access Management-Leitfaden für Ihre Version von Data ONTAP.

Die folgenden Tabellen sind Ihnen bei der Auswahl des korrekten LUN-Typs behilflich.

Tabelle 5) LUN-Typen für die Verwendung mit Data ONTAP 7.3.1 und höher

Tabelle 6) LUN-Typen für die Verwendung mit Data ONTAP 7.2.5 bis 7.3.0

BP 3: Virtual Machine Disk Alignment

Tipp: Dieser Tipp ist eng mit dem vorherigen verknüpft, da eine Nicht-Beachtung des vorherigen Tipps ebenfalls zu einer falschen Ausrichtung führt. Das Problem von Virtual Disk Alignment ist weder auf Hyper-V noch auf NetApp Storage beschränkt. Dieses Problem besteht in jeder virtuellen Umgebung auf jeder beliebigen Storage-Plattform.

Dieses Problem tritt auf, da viele Gast-Betriebssysteme, einschließlich Windows 2000 und 2003 sowie verschiedene Linux-Versionen, standardmäßig bei Sektor 63 (logischer Block) mit der primären Partition beginnen. Diese Vorgehensweise hat falsch ausgerichtete File-Systeme zur Folge, da die Partition nicht an einer Blockgrenze beginnt. Dies führt dazu, dass von der Virtual Machine zwei Blöcke von der zugrundeliegenden LUN gelesen werden müssen, selbst wenn nur einer gelesen werden sollte. Dadurch wird die I/O-Last verdoppelt.

Abbildung 1) Falsche Ausrichtung der virtuellen Festplatte

Die Situation ist noch komplizierter, wenn Virtual Machines innerhalb von Hyper-V Servern als Dateien gemanagt werden, da so eine weitere Ebene eingeführt wird, die ordnungsgemäß ausgerichtet werden muss. Daher ist die Auswahl des LUN-Typs so wichtig.

• NetApp empfiehlt die Korrektur des Offsets für alle VM-Vorlagen sowie alle bestehenden VMs, die falsch ausgerichtet sind und bei denen ein Problem mit der I/O-Performance besteht. (Falsch ausgerichtete VMs mit niedrigen I/O-Anforderungen profitieren möglicherweise nicht von einer korrigierten Ausrichtung.)
• Beim Einsatz von Virtual Hard Disks (VHDs) empfiehlt NetApp sofern möglich die Verwendung von VHDs mit fester Größe in Ihrer virtuellen Microsoft Hyper-V Umgebung, vor allem in Produktionsumgebungen, da eine korrekte Ausrichtung des File-Systems nur mit VHDs mit fester Größe zuverlässig erreicht werden kann. Vermeiden Sie sofern möglich die Verwendung von dynamisch wachsenden und unterschiedlichen VHDs, da mit diesen VHD-Typen niemals eine zuverlässige Anpassung des File-Systems erreicht werden kann.

Der Best Practices Guide enthält alle Vorgehensweisen zur Identifizierung und Behebung von Ausrichtungsproblemen.

BP 4: Verwendung von Cluster Shared Volumes

Cluster Shared Volumes stellen eine völlig neue Funktion von Hyper-V R2 dar. Wenn Sie mit VMware vertraut sind, können Sie sich CSV als eine Art VMFS vorstellen (obwohl es erhebliche Unterschiede gibt).

Ein CSV ist eine „Festplatte“, die mit einer übergeordneten Hyper-V Partition verbunden ist und von mehreren Hyper-V Server Nodes verwendet wird. Sie wird als Teil des Windows Failover Cluster konfiguriert. Ein CSV kann nur von gemeinsam genutztem Storage erstellt werden, wie beispielsweise von einer in einem NetApp Storage-System bereitgestellten LUN. Alle Hyper-V Server Nodes im Failover Cluster müssen mit einem gemeinsam genutzten Storage verbunden sein.

CSVs bietet viele Vorteile, darunter folgende:

• Gemeinsamer Namespace. CSVs müssen keinem Laufwerksbuchstaben zugewiesen werden, wodurch Beschränkungen reduziert werden und das Management von GUIDs und Bereitstellungspunkten entfällt.
• Vereinfachtes Storage-Management. Mehr VMs greifen auf weniger LUNs zu.
• Storage-Effizienz. Durch die Zusammenfassung von VMs auf derselben LUN wird die Kapazitätsplanung vereinfacht und der für zukünftiges Wachstum reservierte Speicherplatz reduziert, da er nicht mehr pro VM reserviert werden muss.

Dank der dynamischen I/O-Weiterleitung von CSV können Storage und Netzwerk-I/O innerhalb eines Failover Clusters selbst dann weitergeleitet werden, wenn der primäre Pfad unterbrochen ist. Die folgenden Empfehlungen gelten insbesondere für die Verwendung von CSVs und sollen die Auswirkungen auf die I/O-Weiterleitung minimieren:

• Neben den zum Management im Hyper-V Server installierten NICs, VMs, IP-Storage und vielem mehr (siehe Best Practice 1) empfiehlt NetApp die Zuweisung eines physischen Netzwerkadapters ausschließlich für CSV-Verkehr. Der physische Netzwerkadapter sollte mindestens ein Gigabit-Ethernet-Adapter sein. Falls Sie planen, größere Server einzusetzen (16 LCPUs+, 64 GB+), CSVs in großem Maß zu verwenden, VMs innerhalb des Clusters mit SCVMM dynamisch auszugleichen, und/oder Live-Migration in großem Maß nutzen möchten, sollten Sie 10 Gigabit Ethernet für den CSV-Verkehr einsetzen.
• NetApp empfiehlt ausdrücklich die Konfiguration von MPIO auf allen Hyper-V Cluster Nodes, um das mögliche Auftreten von CSV-I/O-Weiterleitung zu minimieren. CSV-I/O-Weiterleitung ist kein Ersatz für Multipathing oder angemessene Planung von Storage-Layout und Netzwerk, wodurch Single Points of Failure in Produktionsumgebungen minimiert werden.
• Sobald Sie feststellen, dass eine I/O-Weiterleitung auf einem CSV auftritt, möchten Sie möglicherweise alle betroffenen VMs auf dem betroffenen Cluster Node zu einem anderen Hyper-V Cluster Node migrieren, um wieder eine optimale Performance herzustellen, bis die Probleme des I/O-Pfads diagnostiziert und behoben sind.

Der Best Practices Guide enthält weitere Best Practices, die sich speziell mit Backup und VM Provisioning mit CSVs befassen.

BP 5: NetApp Storage Software und Tools

NetApp bietet Storage Software und eine Reihe verschiedener Tools, die die Vorgänge in einer Hyper-V Umgebung vereinfachen können. Mit der Veröffentlichung von Hyper-V R2 haben sich die Mindestanforderungen für viele Software-Elemente verändert:

• NetApp empfiehlt mindestens Data ONTAP 7.3 zur Verwendung mit virtuellen Hyper-V Umgebungen.
• Das Windows Host Utilities Kit ändert die Systemeinstellungen, so dass das übergeordnete oder untergeordnete Hyper-V Betriebssystem mit möglichst hoher Zuverlässigkeit arbeitet, wenn eine Verbindung zu NetApp Storage besteht. NetApp empfiehlt ausdrücklich die Installation des Windows Host Utilities Kit auf allen Hyper-V Servern. Für Windows Server 2008 ist Windows Host Utilities Kit 5.1 oder höher erforderlich. Für Windows Server 2008 R2 (Hyper-V R2) ist Windows Host Utilities Kit 5.2 oder höher erforderlich.
• Für hochverfügbare Storage-Konfigurationen ist die entsprechende Version von Data ONTAP DSM für Windows MPIO erforderlich. Für Windows Server 2008 ist Data ONTAP DSM 3.2R1 oder höher erforderlich. Für Windows Server 2008 R2 ist Data ONTAP DSM 3.3.1 oder höher erforderlich. Bei der Verwendung von MPIO sollten Sie eine geringe Warteschlangentiefe einstellen. (Dies ist die Standardeinstellung.)
• NetApp empfiehlt NetApp SnapDrive auf allen Hyper-V und SCVMM Servern, um maximale Funktionalität zu ermöglichen und wichtige Funktionen zu unterstützen. Installieren Sie SnapDrive für Windows 6.0 oder höher für Microsoft Windows Server 2008 mit aktiviertem Hyper-V und für Microsoft Hyper-V Server 2008. Für Microsoft Windows Server 2008 R2 mit aktiviertem Hyper-V und für Microsoft Hyper-V Server 2008 R2 zur Unterstützung von:
• Bestehenden Funktionen (keine neuen R2-Funktionen): installieren Sie NetApp SnapDrive für Windows 6.1P2 oder höher.
• Neuen Funktionen (alle neuen R2-Funktionen): installieren Sie NetApp SnapDrive für Windows 6.2 oder höher.
• NetApp SnapDrive für Windows 6.0 oder höher kann ebenfalls in unterstützten untergeordneten Betriebssystemen installiert werden, wie beispielsweise Microsoft Windows Server 2003, Microsoft Windows Server 2008 und Microsoft Windows Server 2008 R2.

Die neuesten Informationen zu unterstützten Software-Versionen finden Sie in der NetApp Interoperabilitätsmatrix. (Sie benötigen ein NOW Konto (NetApp on the Web), um auf diese Ressource zuzugreifen.)

Schlussfolgerung

Wenn Sie die von mir hier aufgezeigten Best Practices beachten, können Sie die meisten Stolperfallen bei der Konfiguration von Hyper-V Umgebungen vermeiden. Alle Details zu diesen Verfahren sowie viele weitere Informationen finden Sie im Hyper-V Best Practices Guide und Hyper-V Implementierungshandbuch.

 Ihre Meinung zu Hyper-V?

Stellen Sie Fragen, tauschen Sie Ideen aus und teilen Sie Ihre Meinung mit der NetApp Community!