Mehr Hinweise und Notizen zu Hyper-V

Dieser Artikel ergänzt unseren älteren Beitrag “Hyper-V: Notizen und Best Practice” vom März 2009. Während sich der damalige Artikel vorrangig auf Hyper-V “1.0” bezog (also den ursprünglichen Hypervisor in Windows Server 2008), liefern wir hier vor allem Empfehlungen zu Hyper-V “2.0” in Windows Server 2008 R2.

CPU

• Mit aktuellen CPUs (Stand Mitte 2010) setzen viele Experten folgende Faustformel für das Verhältnis “virtueller CPUs” zu “physischen CPUs” ein: Pro CPU-Core rechnet man acht “virtuelle CPUs” (vCPUs). Ein physischer Server mit zwei Quad-Core-CPUs enthält also acht Cores. Nach der genannten Faustformel hat man damit 64 vCPUs, die man auf die VMs verteilen kann. Dabei sollte man “einen halben Core” für die Parent Partition reservieren (also logisch berücksichtigen) – in unserem Beispiel macht das vier vCPUs, die man nicht an VMs vergibt; bleiben somit 60 vCPUs für die virtuellen Maschinen.
  Hinweis: Diese Faustregel ist kein fester Wert und sollte immer in Abhängigkeit vom konkreten Projekt überprüft werden! Es kann im Einzelfall durchaus möglich sein, mit dem genannten Server mehr als 64 virtuelle CPUs zu betreiben. Andersrum kann es vorkommen, dass bestimmte Applikationen ein konservativeres Sizing erfordern und man die acht “physischen” Cores in “nur” 30-40 virtuelle CPUs oder weniger umrechnet.

Arbeitsspeicher

• Die neue Funktion “Dynamic Memory” kommt bekanntermaßen erst mit dem Service Pack 1 für Windows Server 2008 R2 (angekündigt für “die erste Jahreshälfte 2011”). Erst dann wird es möglich sein, virtuellen Maschinen flexibel anhand der aktuellen Last mehr oder weniger Arbeitsspeicher zuzuordnen.
  Vorsicht aber: Egal ob mit Dynamic Memory oder ohne – ein “Überbuchen” des Speichers ist in Hyper-V nicht möglich! Wenn der physische Arbeitsspeicher des Hostservers ausgebucht ist und eine zusätzliche VM versucht zu starten, so schlägt deren Startvorgang ohne eine aussagekräftige Meldung fehl.
  Insbesondere in Clusterumgebungen muss man also die RAM-Größe sorgfältig entwerfen und die tatsächliche Nutzung im Auge behalten, denn erstens ist es gerade beim Clustering wichtig, sich auf das System verlassen zu können, und zweitens verführt die Live Migration dazu, “mal eben” eine VM von einem Host auf einen anderen zu verschieben und damit die Ressourcenverteilung zu verändern.

Storage

• Das Storage-Grunddesign einer virtuellen Maschine unterscheidet sich nicht von dem eines physischen Servers. Würde man also etwa auf einem “echten” Server getrennte RAID-Gruppen für die Datenbank und für ihre Logs vorsehen, so plant man dies auch für eine VM so ein. Benötigt eine Applikation eine bestimmte Storage-Performance, dann muss man diese auch in einer VM-Umgebung bereitstellen (und natürlich den Overhead durch die Virtualisierung vermeiden oder ausgleichen – z.B. durch direkte Einbindung von LUNs aus dem SAN).
• Bei der redundanten Anbindung von iSCSI-LUNs aktiviert man auf keinen Fall das Teaming der Netzwerkkarten. Hier ist MPIO (Multipath I/O) die richtige Technik, denn nur dieses Protokoll ist für den Speicherzugriff geeignet. Je nach SAN-Anbieter kann hier zusätzliche lizenzpflichtige Software nötig sein (sog. “Device-Specific Modules”, DSM); die Grundkomponenten für MPIO bringt Windows 2008 bereits mit.
• Wer LUNs im SAN anlegt, sollte diese gleich aussagekräftig benennen, um die Zuordnung zu VMs zu erleichtern.
• Daten-LUNs darf man erst dann an mehrere Hosts anbinden, wenn der Clusterdienst läuft. Dieser koordiniert die Zugriffe.
• Neu in Windows Server 2008 R2 ist die Storage Redirection: Sollte ein Clusterknoten die direkte Netzwerkverbindung (iSCSI, FC, FCOE usw.) zum Storage verlieren, so können seine Storage-Zugriffe über das Heartbeat-Netz auf einen der anderen Knoten umgeleitet und von dort beantwortet werden. Voraussetzung hierfür ist das aktivierte CSV (Cluster Shared Volume), und damit es funktioniert, sollte natürlich ein dediziertes Netzwerk dafür bereitstehen. Mehr zu diesen Voraussetzungen:

  [How-To: Verwaltung eines Cluster Shared Volume (CSV) | Server Talk]
  http://www.server-talk.eu/2010/06/27/how-to-verwaltung-eines-cluster-shared-volume-csv/

• VHD ist kein vollständig einheitliches Format, sondern eher ein Containerformat für unterschiedliche virtuelle “Festplattentypen”. So wird es i.d.R. nicht gelingen, eine VHD-Datei, die man mit Windows Server Backup erzeugt hat, in Hyper-V als Boot-Device aufzurufen.
• Die Performance von VHD gilt als “sehr gut”, allerdings gilt das nur, wenn die VHD-Datei gerade nicht vergrößert wird. In der Produktion empfehlen sich also nur VHD-Dateien mit vordefinierter, fester Größe. Hier geht man von einem Performance-Nachteil gegenüber “nativen” Platten von unter fünf Prozent aus. Muss Windows eine (dynamische) VHD-Datei allerdings vergrößern, dann können die Leistungseinbußen bei über 20 Prozent liegen. Aus diesem Grund sind dynamische VHDs für die meisten Produktionsszenarien auch nicht unterstützt, zumindest aber “nicht empfohlen”.
• Oft richtet man eine VHD nur zum Booten der VM ein und legt die Daten der Applikationen auf separaten, direkt gemappten LUNs ab (“Pass-through Disk”). In diesem Fall muss die VHD groß genug dimensioniert sein. Als Faustregel gilt “zweimal RAM plus 20 GB” – genug Speicher für das Swapping, das Crashdump-File (für den Supportfall) und das Betriebssystem samt Overhead. Gerade bei letzterem sollte man aber nicht knausern und je nach Applikation auf dem Server ggf. eher 30 oder sogar 50 GB aufschlagen.
• Man kann einen VHD-Snapshot mit dem aktuellen Stand zusammenführen. Das ist z.B. hilfreich, wenn man in einer Entwicklungsumgebung nach einem erfolgreichen Update-Test die Änderungen ins Live-System integrieren möchte. In Produktionsumgebungen rate ich davon ab.
  • Dazu wählt man “Datenträger bearbeiten” und navigiert dann zu der AVHD-Datei, die den Snapshot enthält.
  • Klickt man nun auf “Weiter”, so erscheint die Auswahl “Zusammenführen”. Diese wählt man aus.
  • Vorsicht: Das Ergebnis ist nicht immer vorhersagbar. Es kann durchaus sein, dass man ein unbrauchbares System erhält. Zur Absicherung empfiehlt es sich also, die VM vorher per Export zu sichern.
  • Grundsätzlich funktioniert dies auch mit mehreren Snapshots – wobei das Risiko steigt. In diesem Fall integriert man die Snapshots nacheinander von “Alt” nach “Neu”.

Netzwerk

• Es empfiehlt sich der Einsatz moderner Netzwerkkarten für Hyper-V, weil diese oft integrierte Virtualisierungsfunktionen enthalten, die die Host-CPU entlasten.
• Wer auf seinem Host das Netzwerkkarten-Teaming einsetzen will, muss sich strikt an die Installationsreihenfolge halten, die der Treiber-Hersteller vorgibt. Anderenfalls kann es zu schwer nachvollziehbaren, aber gravierenden Kommunikationsstörungen kommen. Vorsicht: Microsoft unterstützt das Teaming nicht, dafür sind die Treiber-Hersteller zuständig! Siehe auch:

  [How-To: Netzwerkkarten Teaming mit Hyper-V | Server Talk]
  http://www.server-talk.eu/2009/12/02/how-to-netzwerkkarten-teaming-mit-hyper-v/

• Zwischen virtuellen Switches und den “physischen” Netzwerkkarten des Hosts besteht eine 1:1-Beziehung: Jeder vSwitch gehört zu genau einer Netzwerkkarte, und jede Netzwerkkarte kann nur einen vSwitch bilden (es gibt aber auch Karten, die in Hyper-V nicht eingebunden sind und daher gar keinen vSwitch haben). Eine VM, die mit mehreren Netzwerken sprechen soll, muss daher “im Host” mehrere Netzwerkkarten mit den dazugehörigen vSwitches vorfinden.
• Fügt man auf dem “Host” einen neuen vSwitch für eine Netzwerkkarte hinzu, so verlieren für einen Moment alle Netzwerkkarten (und damit ggf. auch alle VMs) ihre Netzwerkverbindung, weil die internen Kanäle neu geordnet werden. In so einem Fall empfiehlt es sich, die laufenden VMs ggf. zuvor per Live Migration auf einen anderen Host zu verschieben.

Sicherheit

• Da ein Windows-Cluster zwingend voraussetzt, dass die Clusterknoten (also die Server) Mitglieder einer AD-Domäne sind, nimmt man die Hyper-V-Server meist direkt in die Produktionsdomäne auf. Es kann allerdings empfehlenswert sein, die Hyper-V-Hostumgebung von der Produktionsumgebung zu trennen. Das kann man z.B. so erreichen:
  • Für den Hyper-V-Cluster erzeugt man eine eigene AD-Domäne, die nur aus zwei DCs (physisch!) und den Host-Clusterservern besteht. Der Zugang zu dieser Domäne lässt sich gut kontrollieren, weil man nur sehr wenige Anmeldekonten dort braucht. Natürlich sollten diese mit sinnvollen, starken Kennwörtern geschützt sein, die man in der Produktionsumgebung nicht verwendet.
  • Das eigentliche Produktions-AD läuft getrennt von der Hyper-V-Domäne. Hierbei wäre es sogar denkbar, auf physische DCs zu verzichten, weil die Hyper-V-Umgebung selbst ja nicht von den virtuellen DCs der Produktion abhängt. Trotzdem empfiehlt sich grundsätzlich, auch hier einen DC physisch auf separater Hardware zu betreiben.
  • Achtung, wer den SCVMM (Virtual Machine Manager) einsetzen will, muss ihn in diesem Szenario in der Hyper-V-Domäne installieren, denn einen Hyper-V-Cluster kann der VMM nur in seiner eigenen oder einer vertrauten Domäne verwalten.

Clustering

• Seit Windows Server 2008 ist das Clustering sehr einfach geworden. Auch die Support-Policy hat sich geändert: Support gewährt Microsoft für einen Cluster, wenn der Validierungs-Report keine Fehler aufzeigt und alle verwendeten Komponenten zur Nutzung mit Windows Server 2008 (bzw. R2) freigegeben sind. Eine separate Cluster-Supportliste gibt es nicht mehr.
• Daher empfiehlt es sich, den Validierungs-Report zu speichern, denn er kann als Supportnachweis dienen. Er darf keine Fehler (rote Kategorie) aufweisen. Warnungen (gelbe Kategorie) sind kein Support-Hindernis, gleichwohl sollte man sie beheben.
• Die Volumes weist Windows beim Erzeugen des Clusters automatisch zu. Daher kann es sich empfehlen, zunächst nur das Quorum-Volume auf den ersten Host zu verbinden und die anderen Volumes nachträglich einzeln hinzuzufügen, um die Benennung und Zuordnung besser steuern zu können. Eine andere Mögllichkeit ist, die LUNs unterschiedlich groß anzulegen, um sie anhand ihrer Größe unterscheiden zu können.
• Die Netzwerkkarten für das Heartbeat-Netz dürfen nicht als Team eingerichtet sein – dies würde zu einem Support-Ausschluss führen. Stattdessen kann man einfach mehrere Netzwerkkarten für den Heartbeat vorsehen, dann kann Windows selbst ein Failover über die Karten ausführen.
• Die Benennung und Zuordnung der Netzwerkverbindungen sollte man vor dem Einrichten des Clusters vornehmen, damit während der Einrichtung Klarheit besteht. Wichtig: Die virtuellen Switches (= “physische” Netzwerkkarten) müssen auf allen Hosts denselben Namen tragen (einschließlich Groß- und Kleinschreibung), sonst schlägt hinterher di Live Migration und das Failover fehl, weil die VMs ihre Switches nicht finden.
• Achtung: Die verschiedenen Eigenschaften-Seiten für Hyper-V und virtuelle Maschinen im Cluster-Manager sind schnell verwirrend. Findet man eine Option nicht, so sollte man die anderen “Eigenschaften”-Möglichkeiten probieren.
• Anders als unter Windows Server 2008 fährt ein Cluster unter 2008 R2 eine VM nicht sofort wieder hoch, wenn man sie auf der Ebene des VM-Betriebssystems herunterfährt. Dieses Standardverhalten lässt sich aber pro VM konfigurieren und so bei Bedarf auf das “alte” Verhalten zurücksetzen.
• Das Cluster Shared Volume (CSV, im deutschen Windows “Freigegebener Datenträger”) ist ausschließlich für Hyper-V supported. Man sollte der Versuchung unbedingt widerstehen, dort andere Daten abzulegen!

Live Migration

• Live Migration ist keine Hochverfügbarkeits-Funktion! Sie kann allenfalls dazu dienen, bestimmte geplante Unterbrechungen (etwa beim Patchen des Host-Servers) zu überbrücken, aber auch nicht alle. Hauptsächlich dient Live Migration der Lastverteilung in größeren Host-Farmen und zur Unterstützung von administrativen Vorgängen.
• Live Migration setzt voraus, dass die gesamte Umgebung sauber entworfen wurde und technisch einwandfrei funktioniert. Insbesondere die Netzwerkverbindungen müssen sowohl auf dem Host als auch für die VMs korrekt aufgebaut sein. Es kann in größeren Umgebungen auch sinnvoll oder erforderlich sein, eigene physische Netzwerkverbindungen für die Live Migration zu reservieren.

  [Hyper-V: Live Migration Network Configuration Guide]
  http://technet.microsoft.com/en-us/library/ff428137(WS.10).aspx

• Bei extrem hoher Arbeitsspeicherbelastung kann die Live Migration einer VM auch scheitern, weil der RAM-Abgleich über das Migrationsnetzwerk niemals den Punkt erreicht, an dem das “Active Working Set” so klein ist, dass Windows auf den anderen Host umschalten kann. In solch einem Fall kann ein Timeout dazu führen, dass der Migrationsvorgang abbricht. In Zeiten geringerer Last kann die Migration derselben VM aber gelingen.
  (Dies ist kein Problem von Hyper-V, sondern trifft prinzipiell auf alle Virtualisierer zu.)
• Sollte die Live Migration und auch die Quick Migration einer VM fehlschlagen, so funktioniert meist trotzdem das Verschieben (Move), allerdings nur bei pausierter VM.

Verwaltung

• Für eine administrative Aufgabe sollte man immer das “höchstwertige” Werkzeug nutzen, das zur Verfügung steht. Leider sind die verschiedenen Tools nämlich nicht immer sauber aufeinander abgestimmt. Hat man also z.B. einen Hyper-V-Cluster, so sollte man den Cluster-Manager für alle VM-Aufgaben verwenden, die er selbst anbietet, und nur auf den Hyper-V-Manager ausweichen, wenn es nicht anders geht. Wer den SCVMM nutzt, sollte diesen für alles nutzen, was er beherrscht.
  Falls durch die Nutzung eines anderen Werkzeugs ein Admin-Tool eine Änderung nicht mitbekommen hat, gibt es manchmal Abgleichsmöglichkeiten (z.B. im Cluster-Manager oder im SCVMM).
  Keine Regel ohne Ausnahme: SCVMM 2008 R2 hat einen bekannten Fehler, der es nicht erlaubt, die Zeitsynchronisation mit dem Host für eine laufende VM abzuschalten. Dies geht mit dem VMM nur für eine abgeschaltete VM. Abhilfe hier: Die Zeitsynchronisation im Hyper-V-Manager abschalten, der kann das auch im laufenden VM-Betrieb.
• Hinweise zum Backup mit Bordmitteln gibt folgender Artikel. Ob sich damit ein sinnvolles Recovery-Konzept aufbauen lässt, muss man anhand der konkreten Gegebenheiten prüfen.

  [How to back up Hyper-V virtual machines from the parent partition on a Windows Server 2008-based computer by using Windows Server Backup]
  http://support.microsoft.com/kb/958662/en-us