Kommt eine Infrastruktur an ihr Limit, muss diese in der Regel weiter ausgebaut werden. Doch wie kann ein zusätzlicher Host in die bestehende Umgebung integriert? Mit der Erweiterung eines Hyper-V Failover Clusters befasst sich nun dieses How-To. Zunächst muss der neue Hyper-V Host installiert und soweit konfiguriert werden, dass dieser den anderen Nodes entspricht. Dies beinhaltet unteranderem folgende Punkte:

• Hardware Configuration (Power, BIOS, Firmware)
• Storage Configuration (LUN, MPIO, DSM, etc.)
• Network Configuration (Drivers, Teaming, IP Settings)
• Hyper-V (Virtual Networks)
• Windows Updates (analog den existierenden Nodes)
• etc.

(weiterlesen …)

Storage ist eines der wichtigsten Erfolgsfaktoren Virtualisierungs-Projekte. Ein sehr beliebtes Storage System kommt aus dem Hause HP und trägt den Namen p4000, früher auch bekannt unter dem Namen HP LeftHand p4000. Wie bereits andere Storage Lösungen folgt das p4000 auch dem GRID-Ansatz. Das Storage System besteht aus mehreren Storage Nodes welche in einem Cluster zusammengefasst werden. Jeder einzelne Node bietet als abgeschlossene Einheit die Kombination aus Speicherkapazität (SATA oder SAS), eigener Rechenleistung und Netzwerkbandbreite an.

Damit ein Host, wie zum Beispiel Hyper-V, eine fehlertolerante Verbindung mit mehreren iSCSI HBAs / NICs aufbauen kann, wird Multipath I/O (MPIO) mit zusätzlichem “Device Specific Module” (DSM) vom Storage Hersteller erweitert. Dieses Modul wird von HP als SAN/iQ bezeichnet.

Nebst MPIO installiert SAN/iQ auch den Hardware VSS Provider welcher für das Storage integrierte Backup verwendet werden kann. Diese erlauben es, Backups von Virtual Machines schnell und parallel durchzuführen indem die Hardware VSS Provider des Storage System angesprochen und Snapshots erstellt werden. Doch die Problematik liegt wiedermal im Detail…

SAN/iQ 8.5 wird zwar für Windows Server 2008 R2 und auch Hyper-V supported, doch wird Cluster Shared Volume (CSV) nicht speziell erwähnt. Dies kann zu grossen Problemen führen! Sobald ein Backup Job startet und das DSM anspricht, kann es zu Disk Deadlocks und schlussendlich zum Blue Screen “STOP: 0x0000009E” auf den Hyper-V Hosts kommen.

HP hat reagiert und im November 2010 ist die neueste SAN/iQ in der Version 9.0 erschienen. Dies sollte die Probleme adressieren und nun auch offiziell die Hardware VSS Provider für CSV Backups unterstützen. SAN/iQ 9.0  ist für die HP LeftHand p4000 G1 und G2 Modelle einsetzbar. Gemäss HP ist ein direktes Update von den Versionen 8.0, 8.1 und 8.5 möglich. Die Software kann kostenlos bei HP bezogen werden.

Wie jeden Monat ist wieder mal soweit, es ist Patch Day. Diesen Monat gilt es bei Hyper-V Server sieben (7) Recommended Updates zu installieren. Damit ein Hyper-V Host mit den aktuellsten Windows Updates bestückt und anschliessen neugestartet werden kann, gibt es im Virtual Machine Manager die nette Funktion “Maintenance Mode”.

Nun kann es vorkommen, dass dieser Modus nicht angewendet werden kann. Ebenfalls bricht die manuell initiierte Live Migration mit demselben Fehler ab. In der Job Übersicht wird dabei folgende Fehlermeldung angezeigt:

Error (10698)
Virtual machine MyVM could not be live migrated to virtual machine host MyHost using this cluster configuration.
(Unspecified error (0×80004005))

Recommended Action
Check the cluster configuration and then try the operation again.

Die Lösung, oder mehr die Ursache dieses Problem ist sehr einfach aufzuzeigen – der Host verfügt nicht über genügend Memory. VMM bricht daher den Job bei 50% ab, nachdem die Pre-Checks nicht erfolgreich waren. Der Failover Cluster bricht bereits schon nach 5% mit der Meldung “Migration attempt failed” ab.

Und nun? Als Workaround könnten nicht benötigte Virtual Machines heruntergefahren oder in einen “Save State” (Vorsicht mit dieser Funktion!) versetzt werden. Ist genügend Memory vorhanden, funktioniert auch Live Migration oder der Maintenance Mode.

Ein Storage welches in einem Failover Cluster genutzt werden sollt, muss zwingend die SCSI-3 Spezifikationen erfüllen. Denn mit Persistent Reservation kann ein Node durch das setzen einer Reservation Lese- und Schreibzugriffe von anderen Nodes unterbinden. Weil dadurch nie mehr als ein Node auf eine Cluster Disk zugreifen kann, wird bereits auf Storage-Ebene dem Split-Brain entgegengewirkt. Die Storage-Voraussetzungen werden auch explizit im Cluster Validation Wizard abgefragt und geprüft, wie zum Beispiel:

• List Potential Cluster Disks
• Validate SCSI-3 Persistent Reservation
• Validate Simultaneous Failover
• …

Unter bestimmten Umständen kann es nun aber zu einem Problem kommen, dass eine Disk Reservation nicht wieder aufgehoben (released) wird. In einem solchen Fall kann kein Node diese Disk mehr online nehmen und die Hochverfügbare Applikation (Exchange Server, Hyper-V, SQL Server) schlägt fehlt . (weiterlesen …)

Vor einigen Wochen wurde hier ein Artikel zu Failover Cluster mit VMware publiziert. Natürlich darf dann auch ein Artikel zu Failover Cluster mit Hyper-V nicht fehlen. Die Konfiguration von Guest Clustering ist auch bei Hyper-V möglich. Allerdings gilt es die Support Policy für das jeweilige Operating System zu prüfen und die Limitierungen zu beachten. Im nachfolgenden Artikel wird nun detaillierter auf den Support der einzelnen Windows Server Versionen in einer Cluster Konfiguration eingegangen.

Windows NT Server 4.0 / Windows 2000 Server / Windows Server 2003

Microsoft supported keinen virtuellen Failover Cluster (MSCS) auf Basis dieser Windows Server Version.

Windows Server 2008 und 2008 R2

Microsoft hat die Support Policy für Failover Cluster in Windows Server 2008 radikal geändert um zukünftig flexibler zu sein. Damit eine Failover Cluster Konfiguration durch Microsoft supported wird, müssen sämtliche Komponenten über ein Windows Server Logo verfügen und neu die Cluster Validierung (Validate a Configuration…) erfolgreich ohne Fehler bestehen. Die Konfiguration von Windows Server 2008 und auch 2008 R2 als Guest Failover Cluster ist grundsätzlich supported. Die vollständige Support Policy wird bei Microsoft TechNet beschrieben – hier sollte dem Abschnitt “Virtualized Servers” spezielle Aufmerksamkeit geschenkt werden.

Hinweise zu Hyper-V

Nebst den bereits erwähnten TechNet und Knowledge Base Artikeln sollten auch die Policies für die jeweilige Applikation auf zusätzliche Hinweise und Limitationen geprüft werden. Nachfolgend wird das wichtigste (Stand Juli 2010) für Hyper-V zusammengefasst:

• Wird ein virtueller Cluster Node mittels Quick Migration auf einen anderen Hyper-V Host verschoben, so führt dies zu einem Unterbruch des Heartbeats. Dies hat zur Folge, dass ein Failover der Virtual Machine initiiert wird.
• Grundsätzlich wird Live Migration für Virtual Machines, welche Bestandteil eines Guest Failover Cluster sind, supportet. Allerdings sollte die Toleranz für Heartbeat (“SameSubnetThreshold” und “SameSubnetDelay”) angepasst werden.
• Die Guest Failover Cluster Nodes sollten nicht auf demselben Host betrieben werden. Dazu kann in einem Failover Cluster das “AntiAffinityClassNames” konfiguriert werden. Damit wird sichergestellt dass Cluster Ressourcen, in diesem Fall Virtual Machines, nicht auf dem gleichen Cluster Node (Hyper-V Host) betrieben werden. Diese können über die Command Prompt konfiguriert werden, zum Beispiel:
• cluster.exe group “MyServer1″ /prop AntiAffinityClassNames=”MyClassToBlock”
• cluster.exe group “MyServer2″ /prop AntiAffinityClassNames=”MyClassToBlock”
• Von der Virtual Machine kann Shared Storage nur über den Microsoft iSCSI Software Initiator angesprochen werden. Ein Fiber Channel LUN kann in Hyper-V nicht als Shared Storage Konfiguriert werden.

Speziell zum letzten Punkt noch eine detailliertere Erläuterung – Das Schlüsselwort ist “Shared Storage”. Es gibt viele Cluster Konstellationen welche kein Shared Storage voraussetzen, wie zum Beispiel Exchange Server 2010. Dort ist auch eine Anbindung per Pass-through möglich, die dann auf beliebig an den Host angebundene LUNs (iSCSI, FC, FCOE) zugreifen kann. Für Exchange Server wird dies in einem Microsoft TechNet Artikel detailliert beschrieben. Danke an Nils Kaczenski für den Hinweis.

Per September 2010 kann folgende Support Matrix für virtuelle Failover Cluster auf Basis von Hyper-V erstellt werden:

Server Virtualization Validation Program (SVVP)

Ein inzwischen wichtiger Bestandteil des Windows Server Catalog ist das bereits angekündigte Server Virtualization Validation Program, oder kurz SVVP. Der verfügbare “Support Policy Wizard” erlaubt es im Voraus die geplante Konfiguration zu prüfen und ist ein “Muss” für jede Installation. Es ist also von grosser Wichtigkeit, nicht nur auf die Windows Support Policy zu achten, sondern auch jene der Applikation welche zukünftig im Guest Failover Cluster betrieben werden soll. Auch non-Microsoft Hypervisor können hier ausgewählt werden.

Nebst dem Support Statement (Supportet / not Supported) werden auch zusätzliche Details bereitgestellt und direkt auf die entsprechende Information verlinkt:

Weitere Informationen

• Microsoft KB 296799: How to configure Windows clustering groups for hot spare support
• Microsoft TechNet: Configure Heartbeat and DNS Settings in a Multi-Site Failover Cluster
• Microsoft TechNet Webcast: Guest Clustering vs. Host Clustering
• Microsoft Windows Server Catalog: What the logo means
• Microsoft: Lifecycle

Gemäss Handbuch wird ein Server nach der Installation und Konfiguration einem “Hardening” Prozess unterzogen. Somit werden alle nicht benötigten Dienste und Prozesse deaktiviert um die Angriffsfläche zu verkleinern. In diesem Zusammenhang wird in den meisten Fällen auch die Authentifizierung angepasst. Ein Active Directory kann NTLM, NTLMv2 sowie Kerberos zur Authentifizierung verwenden. Als eine Best Practice wird in diesem Zusammenhang empfohlen, dass ältere Protokoll NTLM im ganzen Netzwerk zu deaktivieren. Dazu kann zum Beispiel sehr einfach mittels einer Group Policy Object (GPO) umgesetzt werden: Computer Configuration ⇒ Policies ⇒ Windows Settings ⇒ Security Settings ⇒ Local Policies ⇒ Security Options ⇒ Network security: Restrict NTLM: …

Für Windows und Windows Server mag dies eine gute Einstellung sein, doch Hyper-V Failover Cluster hat mit dieser Einstellung ein Problem. Denn wird NTLM deaktiviert, so kann nicht mehr auf das CSV Volume zugegriffen werden. Im Event Log wird die folgende Fehlermeldung mit der ID 5121 festgehalten:

Log Name: System
Source: Microsoft-Windows-FailoverClustering
Event ID: 5121
Task Category: Cluster Shared Volume
Level: Error
Symbolic Name: DCM_VOLUME_NO_DIRECT_IO_DUE_TO_FAILURE
Description: Cluster Shared Volume ‘Volume1′ (‘Cluster Disk 1′) is no longer available on this node because of ‘STATUS_BAD_NETWORK_PATH(c00000be)’. All I/O will temporarily be queued until a path to the volume is reestablished.

Um das Problem zu beheben ist es zwingend erforderlich dass die in dem Group Policy Object, welche NTLM deaktiviert, die Hyper-V Hosts ausgeschlossen werden. Es kann auch eine weitere GPO angelegt werden, welche speziell für den Hyper-V Failover Cluster NTLM wieder aktiviert. Einen Security Guide speziell für Hyper-V hat Microsoft bereits schon vor einigen Monaten veröffentlicht.

Eine sehr ähnliche Fehlermeldung zu Cluster Shared Volume hatten wir schon Mal vor einem Jahr. In diesem Artikel geht es ebenfalls um eine deaktivierte Funktion welche den Hyper-V Failover Cluster mit aktiviertem CSV ins Straucheln bringt…

Weitere Informationen

• Microsoft TechNet: Event ID 5121 — Cluster Shared Volume Functionality

In diesem Artikel wird beschrieben, wie eine Failed VM in Virtual Machine Manager repariert werden kann. Dieses Troubleshooting, auch als “Notes from the field” bekannt, sollte auch aufzeigen wie ein Problem in VMM analysiert werden kann… Zur Situation: Bei einer von VMM verwaltete Virtual Machine wurde jeder Job / jede Änderung abgebrochen.

Eine solche Situation kann zum Beispiel dann vorkommen, wenn eine clustered VM (HAVM) in Hyper-V exportiert und auf einem anderen Cluster Node wieder importiert wird. Beim erneuten Hinzufügen in den Failover Cluster wird allerdings automatisch eine neue ID erstellt. Wird VMM bei einer solchen Aktion ausgelassen, kommt die #CLUSTER-INVARIANT# Information zum Zug, darüber kann VMM eine bekannte VM eindeutig zuweisen. Leider funktioniert dies bei Export / Import (noch) nicht…

Im Job-Log wurde folgende Fehlermeldung ausgegeben:

Error (12711)
VMM cannot complete the WMI operation on server MyDamagedVM.intra.server-talk.eu because of error: [MSCluster_ResourceGroup.Name="dced5bf8-493b-49b7-8295-ee079d008b1f"] The cluster group could not be found.
(The cluster group could not be found (0×1395))

Recommended Action
Resolve the issue and then try the operation again.

Die Virtual Machine wird in Virtual Machine Manager mit dem Status Failed dargestellt. Ist die VM gestartet, läuft diese zwar uneingeschränkt weiter, allerdings könne in VMM keine  Aktionen mehr ausgeführt werden, selbst die Funktion “Repair” schlägt fehl…

(weiterlesen …)

Mit Windows Server 2008 R2 wurde für Hyper-V das Cluster Shared Volume (CSV) eingeführt. Im Artikel “Einblicke in Cluster Shared Volume (CSV)” wurde bereits detailliert darüber berichtet. Mit Cluster Shared Volume (CSV) nimmt allerdings nicht nur die Flexibilität, sondern auch die Komplexität eines Hyper-V Failover Cluster zu. Da durch den Einsatz von “Direct IO” gleichzeitig mehrere Hyper-V Hosts auf das gleiche LUN Zugriff haben, muss für den optimalen Betrieb eine perfekte Ausgangslage bezüglich Storage geschaffen werden. Aber auch das Cluster Network spielt eine wesentliche Rolle in dieser Architektur.

Da Aufgaben aus dem “Daily Business” bei Cluster Shared Volumes oftmals ein wenig anders durchgeführt werden, werden im nachfolgenden Artikel die wichtigsten Punkte näher erläutert.

(weiterlesen …)

Vor wenigen Tagen hat Microsoft den TechNet Artikel “Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2″ angepasst. Neu können in einem Failover Cluster pro Host mehr Virtual Machines gehostet werden:

Neu können somit generell bis zu 384 Virtual Machines auf einem Hyper-V Host betrieben werden. Anhand von paar konkreten Beispielen kann dies noch besser veranschaulicht werden, wie die Konfigurationen empfohlen werden:

• 5 Node Hyper-V Cluster: 4 aktive Nodes mit jeweils 250 VMs + 1 Failover Node
• 11 Node Hyper-V Cluster: 10 aktive Nodes mit jeweils 100 VMs + 1 Failover Node
• 16 Node Hyper-V Cluster: 15 aktive Nodes mit jeweils 66 VMs + 1 Failover Node

Natürlich müssen auch die Rahmenbedingungen für Hyper-V und die Virtual Machines gegebensein. Wichtig sind vor allem Punkte wie IOPS, Arbeitsspeicher und genügend Bandbreite für Network und Storage.

Und was sind die Limits bei VMware?

Diese Anpassung ist besonders auch interessant, wenn man über den Zaun zum Konkurenten VMware schaut. Gemäss der aktuellen Version der Configuration Maximums für VMware vSphere 4.0 ohne/mit Update 1 gelten folgende Limiten:

Sonst noch was?

Ja, es wird empfohlen dass in einem Hyper-V Cluster auch ein “Reserved Node” (Passive Node) berücksichtigt wird. Dies bedeutet dass solch ein Host nicht in Gebrauch ist, bis ein anderer Host ausfällt, oder Wartungsarbeiten durchgeführt werden.

Die anderen Empfehlungen und Limiten für Hyper-V gelten nach wie vor. Das heisst es können zum Beispiel maximal 4 CPU’s einer Virtual Machine (je nach Operating System) zugewiesen werden. Zudem sollte eine Ratio von maximal 8 CPU’s pro logical Processor nicht überschritten werden. Für ein System mit zwei Quad Core CPU‘s wären dies dann eine Limite von 64 virtual CPU’s welche den VM’s zugewiesen werden könnten.

Weitere Informationen

• Microsoft TechNet: Requirements and Limits for Virtual Machines and Hyper-V in Windows Server 2008 R2
• Microsoft TechNet: Hyper-V: Using Hyper-V and Failover Clustering

Microsoft empfiehlt für den produktiven Einsatz von Hyper-V den Core Installation Mode zu wählen. Denn die Vorteile des Server Core liegen für die Virtualisierung eigentlich ganz klar auf der Hand:

• Wartung – Da bei einer Server Core Installation nur das installiert wird, was zur Verwaltung einer Rolle erforderlich ist, fällt weniger Wartungsaufwand an.
• Angriffsfläche – Systemdateien sind nur in minimalem Umfang installiert. Dadurch dass nur wenige Dienste und Anwendungen laufen, verringert dies die Angriffsfläche.
• Management – Da auf einem Server im Core Installation Mode nur wenige Applikationen und Dienste vorhanden sind, sinkt der Verwaltungsaufwand.
• Speicherplatzbedarf – Server Core benötigt zur Installation nur etwa 1 Gigabyte (GB) Disk Space. Im Anschluss daran sind beim Betrieb lediglich rund 2 GB erforderlich.

Wie die Installation von Hyper-V auf Basis von Server Core durchgeführt werden kann, wird in einem älteren Artikel bereits beschrieben. Mit dem in Windows Server 2008 R2 hinzugefügten “sconfig” geht dies  inzwischen ganz flott. Nun hat sich herausgestellt, dass bei manchen ProLiant Server von HP zu Problemen kommen kann. Beim Anlegen des Failover Cluster wird folgende Fehlermeldung angezeigt:

An error occurred while creating the cluster. An error occurred creating cluster ‘clustername’.
The service has not been started.

(weiterlesen …)