Hyper-V: Neunmal Best Practice? Eine Antwort

Vor einigen Wochen hat der IT-Fachautor Thomas Joos auf dem IT-Portal “Datacenter Insider” einen Artikel mit dem Titel “3X3 Tipps für die Beschleunigung von Hyper-V-Server und VMs” veröffentlicht. Auf Xing hatte ich daraufhin angemerkt, dass ich dazu einige Einwände hätte. Im Lauf der Diskussion, die sich daraufhin entspann, kündigte ich einen Blogpost dazu an. Hier ist er nun.

Warum halte ich Thomas’ Tipps zum größeren Teil nicht für sinnvoll? Gehen wir sie im Einzelnen durch.

1. Physische Festplatten direkt an VMs anbinden?

Der erste Tipp schlägt vor, virtuellen Maschinen einzelne physische Festplatten des Hostservers zuzuweisen. In Hyper-V nennt sich dies “Pass-through Disk”, vSphere kennt dies als “Raw Device Mapping”. Warum ist das in aller Regel keine gute Idee?

Scheinbar lässt sich durch das Anbinden einer physischen Disk an eine VM die Leistungsfähigkeit des Volumes “ungeschmälert” verwenden, weil die Virtualisierungsschicht nicht dazwischensteht. Das mag rein rechnerisch zwar sein, doch ist dieser “Vorteil” teuer erkauft:

• Wer eine physische Festplatte an eine VM anbindet, koppelt die VM an den Host. Die VM kann weder per Live Migration noch per Failover auf einen anderen Host wechseln, denn dort ist die betreffende Platte ja nicht vorhanden.
• Eine Pass-through Disk steht der betreffenden VM exklusiv zur Verfügung – der gesamte Platz kann nur von der einen VM genutzt werden. Die Flexibilität einer VM-Umgebung schränkt man damit erheblich ein.
• Wer ein SAN-Volume (eine so genannte “LUN”) als Pass-through-Disk an eine VM anbindet, umgeht grundsätzlich das Problem, dass die VM an einen Host gebunden ist, denn auf ein SAN-Volume kann ja auch ein anderer Host zugreifen. Aber: Damit dies funktioniert, ist eine exakte Konfiguration des SANs und der Hosts erforderlich. Hier lauern gleich mehrere Fehlerquellen, die die Zuverlässigkeit des Gesamtsystems gefährden.
• Bestimmte Vorgänge einer VM funktionieren nicht mit Pass-through Disks. Dazu zählen etwa VM-Snapshots (im Hyper-V-Jargon als “Checkpoints” bezeichnet). Diese sollte man zwar ohnehin nur in Spezialfällen nutzen, doch Pass-through Disks können mögliche Probleme noch einmal erheblich verschärfen: Eine solche Disk wird ja nicht vom Hypervisor kontrolliert, sie erhöht damit das Risiko inkonsistenter Daten.

Vor allem aber ist der Performance-Vorteil einer Pass-through-Disk in aller Regel zu vernachlässigen. Schon mit dem VHD-Format für virtuelle Festplatten war der “Leistungsverlust” durch die Virtualisierung in der Praxis gering. Durch das neuere VHDX-Format sind virtuelle Platten noch einmal schneller geworden. Und schließlich bietet gerade das VHDX-Format sogar einige Optimierungen, die eine Pass-through-Disk nicht hat.

Fazit: Diesen Tipp sollte man nicht anwenden! Nur in sehr wenigen, speziellen Situationen können Pass-through Disks sinnvoll sein. Für den generellen Gebrauch raten eigentlich alle Experten von ihrem Einsatz ab.

2. SAN-Volumes an VMs anbinden?

Diesen Tipp hat Thomas leider sehr unklar formuliert. Er bezieht sich auf “Virtual Fibre Channel” (vFC) und empfiehlt, dieses einzusetzen, um SAN-Volumes direkt an VMs anzukoppeln.

Hier ist zunächst anzumerken, dass dieser Tipp ohnehin nur in Betracht kommt, wenn Fibre Channel für die Storage-Anbindung im Einsatz ist. Das ist gerade im Mittelstand eher selten der Fall. Selbst dann aber muss die SAN-Anbindung die Technik auch unterstützen – dazu wiederum sind spezielle Komponenten erforderlich (diese müssen das Protokoll NPIV unterstützen, das kein Standardfeature ist).

Selbst wenn man die nötigen Komponenten also hat, stellt sich aber immer noch die Frage, ob es überhaupt sinnvoll ist, SAN-Volumes direkt in eine VM umzuleiten. Dazu kommen wieder die Argumente von Punkt 1 ins Spiel: In den meisten Situationen hat man hier nicht nur keinen Vorteil, sondern schnell sogar handfeste Nachteile.

Fazit: Auch diesen Tipp sollte man in der Regel nicht anwenden. Die meisten werden ihn aber auch gar nicht anwenden können.

3. Host-Systemdaten und VMs trennen

Gut, diesem Tipp kann man sich ohne Vorbehalte anschließen. Die Standardpfade zur Dateiablage, die Hyper-V nach der Grundinstallation vorschlägt, sind in der Tat völlig unsinnig. Es ist sehr sinnvoll, für die VMs und die virtuellen Festplatten ein eigenes Volume vorzuhalten: Auf einem Einzel-Host eine eigene Platte (bzw. ein eigenes RAID-Volume), in einer Cluster-Umgebung natürlich das SAN (oder einen SOFS-Dateiserver).

Fazit: Im Großen und Ganzen okay. Hier ist mein Einwand nur, dass diese Konfiguration keine “Optimierung” ist, sondern zu den Grundlagen der Hyper-V-Einrichtung gehört.

4. Festplatten fester Größe und Dynamic Memory

In diesem Tipp verbergen sich eigentlich zwei Empfehlungen, die nichts miteinander zu tun haben.

Die erste betrifft die virtuellen Festplatten, für die Thomas Joos empfiehlt, sie auf “Fixed Size” zu setzen. Normalerweise erzeugt Hyper-V virtuelle Festplatten dynamischer Größe. Diese haben in der Tat ein paar Nachteile – die Performance gehört aber eher nicht dazu. Zwar ist es durchaus so, dass VHD(X)-Dateien fester Größe einen messbaren Leistungsvorteil gegenüber den dynamischen VHD(X)-Dateien haben. Spürbar ist dieser Unterschied aber so gut wie nie.

Die Gründe, Fixed-Size-Disks einzusetzen, sind meist andere. Zum einen gewähren Microsoft und andere Hersteller für manche ihrer Applikationen nur dann Support, wenn diese in Fixed-Size-Festplatten einer VM laufen. Zum anderen sind dynamische Festplatten tückisch: Die VM selbst “sieht” immer den gesamten Speicherplatz, aber die VHD(X)-Datei umfasst nur den Platz, der tatsächlich belegt ist. Passt man hier nicht auf, dann kann es passieren, dass die physische Platte des Hostservers nicht mehr genügend Platz hat, um die gesamte virtuelle Disk unterzubringen. Da die VM keine Möglichkeit hat, das rechtzeitig zu merken, laufen viele Admins hier in eine Falle: Die Host-Platte ist voll, die VM kann nichts mehr speichern, und die VM fällt daher aus.

Fazit 1: Ja, für kritische VM-Systeme sind virtuelle Festplatten mit fester Größe vorzuziehen.

Ergänzung: Wer dynamische VHD(X)-Dateien einsetzt, muss den physischen Plattenplatz des Hostservers laufend überwachen!

Die zweite Empfehlung betrifft “Dynamic Memory” und damit das RAM einer VM, nicht deren Plattenspeicher. Mit Dynamic Memory kann eine VM im laufenden Betrieb mehr RAM beim Host anfordern oder auch RAM wieder abgeben, wenn sie gerade weniger benötigt.

Klingt gut – was spricht dagegen? Das Problem mit Dynamic Memory ist, dass auch die Applikationen in den VMs damit umgehen können müssen. Die meisten Dienste des Betriebssystems können das. Gerade einige Applikationen, die viel RAM brauchen, können mit Dynamic Memory aber nichts anfangen. Exchange (alle Versionen) oder SQL Server in der Standard- und Express-Fassung kennen kein Dynamic Memory. Sie nutzen immer nur so viel RAM, wie sie beim Start ihrer Dienste vorgefunden haben. Stellt die VM im laufenden Betrieb mehr RAM bereit, so können die Applikationen nicht darauf zugreifen.

Für Exchange gilt daher, dass es gar nicht supported ist, wenn Dynamic Memory eingeschaltet ist!

Fazit 2: Dynamic Memory auf keinen Fall als Standard einschalten! Nur in bestimmten Situationen ist es nützlich. Besser ist es fast immer, den tatsächlichen RAM-Bedarf der VMs zu ermitteln und ihnen diesen Wert fest zuzuweisen.

5. Generation-2-VMs

Thomas empfiehlt die Nutzung von virtuellen Maschinen der Generation 2. Grundsätzlich ist dagegen nichts zu sagen – nur dass die Gen-2-VMs längst nicht so große Performance-Vorteile gegenüber ihren Generation-1-Vorgängern haben wie Thomas’ Artikel nahelegt. Dass die Generation 2 in ihrer Implementierung in Windows Server 2012 R2 auch einige Nachteile hat (z.B. der vermurkste Tastatur-Treiber bei der Installation oder der Verzicht auf virtuelle Grafikkarten), erwähnt Thomas nicht.

Die Daten-Deduplizierung, die Thomas am Ende dieses Tipps erwähnt, hat mit Generation-2-VMs nichts zu tun. Sie ist auch mit größter Vorsicht zu genießen!

Fazit: Generation-2-VMs sind längst nicht in jeder Situation zu empfehlen. Man sollte prüfen, ob sie im konkreten Anwendungsfall wirklich Vorteile bringen. Sie sind kein Performance-Renner im Vergleich zu den herkömmlichen Generation-1-VMs.

Und: Daten-Deduplizierung auf keinen Fall “einfach so” einschalten!

6. Host-Netzwerkadapter

Dass die Netzwerkverbindungen des Hostservers von denen der VMs getrennt werden sollten, ist eine der Grundlagen von Hyper-V – mit Performance-Optimierung, die die Einleitung des Artikels ankündigt, hat das wenig zu tun. Das ist so, als wolle man das Steuern eines Autos als Profi-Fahrertrick verkaufen.

Tatsächlich gehören die Netzwerkeinstellungen in Hyper-V-Systemen zu den Komponenten, bei denen Administratoren in der Praxis die meisten Schwierigkeiten haben und die meisten Fehler machen. Darauf geht Joos’ Artikel aber leider nicht ein.

Fazit: Ja, natürlich trennt man Host- und VM-Netzwerke. Genau an dieser Stelle gibt es aber noch einiges mehr zu tun!

7. Dedizierte NICs für iSCSI und für einzelne VMs

Der Empfehlung, für die iSCSI-Anbindung der Host-Umgebung eigene, dedizierte Netzwerkkarten zuzuweisen, kann ich nur vorbehaltlos zustimmen. Das sollte man niemals anders machen. iSCSI ist Storage-Verkehr, der nie mit anderem Traffic gemischt werden darf.

Diese Empfehlung kann man nur erweitern: Nicht nur eigene Netzwerkkarten für iSCSI, sondern ein eigenes Netzwerk-Segment (mindestens ein eigenes VLAN, besser – in großen Umgebungen – separate Switches) und auch ein eigenes IP-Segment. Ganz nebenbei, gehört dieser Tipp in dieselbe Kategorie wie die Nummer 6.

Die zweite Empfehlung hingegen, auch für einzelne VMs dedizierte Netzwerkkarten (und damit eigene vSwitches) vorzusehen, ist fast immer Unsinn. Praktisch alle Implementierungsversuche dieser Art, die ich in der freien Wildbahn gesehen habe, führten entweder zu Ressourcenverschwendung (weil die Anwendungen auf den VMs bei weitem kein Gigabit ausgelastet haben) oder in die Irre (weil die resultierende Komplexität der Konfiguration die Admins überfordert hat).

Der abschließende Verweis auf SR-IOV führt angesichts der typischen Zielgruppe des Artikels (eher Hyper-V-Einsteiger als erfahrene Profis) in die Irre: Nicht nur sind SR-IOV-Adapter sehr teuer, sondern sie bergen auch viele Stolperfallen in Konfiguration und Betrieb. Die Vorteile sind in den meisten Umgebungen nicht relevant. Also eher: Bleiben lassen.

Fazit: Gemischt. Für iSCSI auf jeden Fall separate Netzwerkkarten und ein separates Netzwerk-Segment. Anwenden! Für einzelne VMs in aller Regel bitte keine separaten Netzwerkkarten im Host – nicht anwenden!

8. Virenschutz auf dem Host

Ja – da die meisten Hyper-V-Hosts in der Praxis eben nicht ausschließlich als Hosts verwendet werden, sondern die Admins von dort aus auch mal den Browser aufrufen (um z.B. nach Treibern zu suchen) oder Dateien dorthin kopieren, ist ein lokaler Virenscanner auf dem Host erforderlich. Und dann muss man diesen auch richtig konfigurieren.

Hilfreicher als einzelne Prozesse zu benennen, wäre allerdings ein Verweis auf die Quellen des Herstellers:

[Hyper-V: Anti-Virus Exclusions for Hyper-V Hosts – TechNet Articles – United States (English) – TechNet Wiki]
http://social.technet.microsoft.com/wiki/contents/articles/2179.hyper-v-anti-virus-exclusions-for-hyper-v-hosts.aspx

Fazit: Ja, bitte anwenden, dann aber richtig. (Auch dies ist aber eine Grundlage und kein Optimierungs-Tipp.)

9. Monitoring mit “Freeware”

Ja, natürlich sollte eine Virtualisierungsumgebung überwacht werden. Dummerweise ist das Thema aber alles andere als trivial.

Das gilt auch für das Werkzeug “PAL”, das Thomas Joos erwähnt. Wer damit ernsthaft die Leistung seiner Umgebung prüfen und verbessern will, sollte sich schon ausführlich damit und mit den Grundlagen beschäftigen.

Fazit: Naja. Monitoring ist nicht einfach. Ein Werkzeug, das Einsteigern eine simple und zuverlässige Überwachung ermöglicht gibt es für Hyper-V so wenig wie für vSphere. Und alle fortgeschrittenen Tools sind schnell so komplex, dass sie sich nicht für die Zielgruppe des Artikels eignen. Es spricht nichts dagegen, sich die empfohlenen Werkzeuge anzusehen, aber sie sind keine “Lösung”.