Am gestrigen Tag hat Microsoft die Arbeiten am Service Pack 1 für Windows 7 und Server 2008 R2 abgeschlossen. Dies hat somit den Status “Release to Manufacturing” (RTM) erreicht und ist ab 22. Februar als Download erhältlich.

Welche Änderungen das neue SP bringt und welche Anforderungen gelten, können im Artikel “Was kommt mit Service Pack 1 für Windows 7 und Server 2008 R2” nachgelesen werden. In diesem Artikel geht es darum einen bestehenden Hyper-V Failover Cluster auf SP1 zu aktualisieren.

(weiterlesen …)

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 …)

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 dem weiterhin anhaltenden Trend der Server Virtualisierung, werden auch vermehrt Virtual Machines als Windows Server Failover Cluster (WSFC) konfiguriert. Generell supported Microsoft die Konfiguration von Guest Clustering, auch bei VMware ESX. Allerdings gilt es die Support Policy für das jeweilige OS zu prüfen und die Limitierungen zu beachten. Die Basis für eine solche Support Vereinbarung wurde im September 2008 geschaffen, als VMware dem Server “Virtualization Validation Program” (SVVP) beigetreten ist. 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

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

Windows Server 2003

Damit eine Cluster Konfiguration durch Microsoft supported wird, muss diese zuvor durch den Hersteller getestet worden sein. Eine qualifizierte Lösung erhält dann das “Designed for Microsoft® Windows® Server 2003″ Logo und wird in die “Hardware Compatibility List” (HCL) aufgenommen. Nur zertifizierte Hardware wird als “Cluster Solution” beim Windows Server Catalog aufgeführt. Die ausführliche Support Policy für Windows Server 2003 wird in Microsoft KB 309395 beschrieben.

Bei VMware haben zwei Lösungen das erforderliche Logo für einen Failover Cluster (MSCS) unter Windows Server 2003 erhalten:

1. VMware vSphere 4.0 cluster for EMC Symmetrix V-Max
2. VMware vSphere 4.0 cluster for EMC CLARiiON CX4

Da das Windows Server 2003 Cluster Logo Program am 31.12.2009 gestoppt wurde, werden zukünftige, nebst den beiden aufgeführten Lösungen mit EMC, keine weiteren Konfigurationen mehr hinzufügt.

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 VMware

VMware selbst hat ebenfalls einen Knowledge Base Artikel mit dem Namen Microsoft Cluster Service (MSCS) support on ESX veröffentlicht. Hier sollte der Abschnitt “vSphere MSCS Setup Limitations” gelesen werden. Zudem sollten auch die VMware Support Policies auf zusätzliche Hinweise und Limitationen geprüft werden. Nachfolgend wird das wichtigste (Stand Juli 2010) zusammengefasst:

• Windows Server 2008 Guest Failover Clustering erfordert VMware vSphere 4.0 oder neuer
• Windows Server 2008 R2 Guest Failover Clustering erfordert VMware vSphere 4.0 Update 1 oder neuer
• Guest Failover Clustering zusammen mit VMware HA erfordert vSphere 4.1
• Guest Failover Clustering mit iSCSI, FCoE und NFS Disks werden nicht supported
• Guest Failover Clustering konfiguriert mit VMware Fault Tolerance wird nicht supported
• vMotion einer Virtual Machine, welche Bestandteil eines Guest Failover Cluster ist, wird nicht supported

Per Juli 2010 kann folgende Support Matrix für virtuelle Failover Cluster auf Basis von VMware erstellt werden:

Das Original dieses Artikels stammt von Elden Christensen, Senior Program Manager Lead bei Microsoft für Clustering & High-Availability. Nach Absprache mit Elden wurde diese Version publiziert.

Weitere Informationen

• Microsoft Windows Server Catalog: What the logo means
• Microsoft: Lifecycle

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