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

Eine Landschaft mit zahlreichen Virtual Machines bietet viele Vorteile – doch auch einige neue Herausforderung mit sich. Eine davon ist der Patch-Tuesday von Microsoft. Wie hält man sämtliche Virtual Machines, Templates und Virtual Machines welche oftmals offline sind auf einem aktuellen Stand?

Die Antwort lautetet: Mit dem Virtual Machine Servicing Tool (VMST). Kürzlich hat Microsoft die Version 3.0 des Solution Accelerator Tools veröffentlich. Nachdem die vorgängigen Versionen nur für offline Virtual Machines, respektive nur um Virtual Machines in der VMM Library, eingesetzt werden konnten, lassen sich nun doch einige interessante Szenarien abbilden:

• Aktualisieren von gestoppten Virtual Machines (Host)
• Aktualisieren von exportieren Virtual Machines (VMM Library)
• Aktualisieren von VHD Images (VMM Library)
• Aktualisieren von Virtual Machine Templates (VMM Library)

(weiterlesen…)

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

Server Virtualisierung ist hoch im Kurs und auch Domain Controller werden inzwischen fleissig virtualisiert. Wer allerdings einen Domain Controller als Virtual Machine betreibt, sollte besonderes Augenmerk auf die korrekte Zeitsynchronisation legen. Grundsätzlich sollte dies kein Problem darstellen, denn…

… jeder Active Directory Client synchronisiert seine Zeit mit einem Domain Controller
… jeder Domain Controller gleicht seine Zeit mit dem PDC Emulator (Primary Domain Controller Emulator) FSMO Rolle ab.
… der Domain Controller mit der PDC Emulator FSMO Rolle kann die Zeit mit einer externen Zeitquelle abgleichen.

Was wenn die Zeit “falsch” ist? Doch “falsch” ist nicht gleich “falsch” – Haben alle Active Directory Clients die gleiche falsche Uhrzeit konfiguriert, so funktioniert die Authentifizierung nach wie vor. Doch wird nur bei einzelnen Computer oder Domain Controller eine falsche Uhrzeit konfiguriert, kann dies zu grossen Problemen führen. Denn bereits eine Abweichung von fünf (5) Minuten reicht aus, damit die Kerberos-Tickets ihre Gültigkeit verlieren.

Dead on arrival?

Seit Windows Server 2008 wird kein Microsoft Zeitserver (time.windows.com) mehr vorkonfiguriert. Dies bedeutet dass auch kein automatischer Abgleich mehr erfolgt. Auf diesen Umstand wird nun im Active Directory Best Practices Analyzer von Windows Server 2008 R2 entsprechend hingewiesen:

The PDC emulator master srv-dc01.intra.server-talk.eu in this forest should be configured to correctly synchronize time from a valid time source

Diesen Fehler gilt es nun zunächst zu korrigieren, doch auch funktioniert das cmdlet net time nicht mehr wie früher. Eine Möglichkeit für Windows Server 2008 R2 wäre folgender Befehl. Dieser kann in einem Command Prompt als Administrator ausgeführt werden: w32tm /config /computer:srv-dc01.intra.server-talk.eu /manualpeerlist:ntp.metas.ch /syncfromflags:manual /update

In diesem Beispiel wird der NTP Server von METAS verwendet. METAS ist das nationale Metrologieinstitut der Schweizerischen Eidgenossenschaft. Der Abgleich mit dem Zeitserver im Internet erfolgt jeweils mittels UDP 123. Dieser Port muss auch entsprechend auf der Firewall geöffnet werden, damit der Domain Controller mit dem Internet kommunizieren kann.

Do’s and Dont’s – was man vermeiden sollte

In einer Infrastruktur wo Domain Controller virtuell betrieben werden gilt es zudem noch weitere Punkte zu beachten:

Auch ein Hypervisor aktualisiert die Zeit seiner Guests. Um Probleme zwischen Hyper-V Host und Virtual Machines zu verhindern, muss bei den Domain Controller in den Integration Components, VMware oder Xen Tools die Zeit Synchronisation deaktiviert werden.

Eine Virtual Machine muss immer heruntergefahren (Shutdown) und darf nie pausiert werden. Da bei einer Pause Zeit / Datum nicht verändert werden, kann unter Umstände nicht mehr repliziert werden und es können veraltete Objekte (Lingering Objects) entstehen.

Für einen Domain Controller sind Snapshots und Undo Virtual Hard Disks (VHDs) sind absolut tabu! Eine falsche Anwendung kann in einem Desaster mit Verlust von Active Directory Informationen enden.

Pro Domain muss mindestens ein physikalischer Domain Controller inklusive GC, DNS und den FSMO Rollen existieren. Wenn dennoch sämtliche Domain Controller virtualisiert wurden, sollten diese zumindest nicht auf ein CSV Volume gespeichert werden, um ein einfacheres und schnelleres Recovery durchführen zu können.

Dazu hat Microsoft ein umfangreiches Dokument veröffentlicht. Der Reference Guide kann jeweils direkt im Microsoft Download Center heruntergeladen werden: Running Domain Controllers in Hyper-V. Zum Lesen von Word Dokumenten ist Microsoft Office Word oder der Microsoft Word Viewer erforderlich.

Windows Patch-Level

Bevor eine Virtual Machine als Domain Controller in Betrieb genommen wird, muss noch sichergestellt werden dass diese im Minimum folgenden Patch-Level aufweisen:

Weitere Informationen

• Microsoft KB 888794: Things to consider when you host Active Directory domain controllers in virtual hosting environments
• Jorge’s Blog: Lingering objects
• Yusuf’s Blog: Lingering Objects (veraltete Objekte)

Damit Virtual Machines auf ein Netzwerk zugreifen können, ist ein Virtual Network erforderlich. Der Virtual Network Manager kann einen allerdings schon mal Kopfzerbrechen bereiten, wie auch schon im Artikel “How-To: Netzwerkkarten Teaming mit Hyper-V” beschrieben wurde.

Die meisten Probleme Herausforderungen treten bei Server Core auf – Allerdings kann es auch bei einer Full Installation zu Fehlermeldungen kommen, wenn ein neues Virtual Network angelegt wird:

Error Applying New Virtual Network Changes
The operation on computer %Computername% failed.

Diese Meldung kommt dann, wenn im Hintergrund noch die Eigenschaften dieses Network Adapters offen sein sollten. Wird das offene Fenster geschlossen, kann der Vorgang umgehend abgeschlossen werden!

Diese Meldung ist, aufgrund der Arbeitsweise der zugrunde liegenden API’s, (leider) zu erwarten. Wenn das Fenster mit den Eigenschaften des Network Adapters zuerst geladen wird, wird im Hintergrund die API “INetCfg” blockiert damit kein anderer Prozess eine Änderung durchführen kann. Diese Blockierung wird erst dann wieder aufgehoben, wenn die Eigenschaften wieder geschlossen werden.

Im oberen Beispiel kann daher auch der Hyper-V Management Code die Sperre der INetCfg API nicht umgehen um ein “bind” des Switch Protokolls auf den Network Adapter durchzuführen.

Bei der Erstellung eines Konzepts und/oder Dokumentation ist Microsoft Office Visio nicht mehr wegzudenken. Layouts und Schemas lassen sich wunderbar abbilden und visualisieren. Leider gibt es für viele Produkte keine offiziellen Stencils… wie auch schon bei schon für VMware und Citrix.

Jonathan Cusson hat in seinem Blog nun auch für Hyper-V und System Center Virtual Machine Manager eine Kollektion erstellt und bereitgestellt. Hier geht es direkt zum Download…

Weitere hilfreiche Informationen und Links zu Downloads gibt es in der Kategorie Visio Stencils.

Microsoft hat neu ein Component Architecture Poster für Remote Desktop Services (RDS) bereitgestellt. Wie bereits schon beim Windows Server 2008 R2 oder Hyper-V Components Poster werden auf dieser A3 Seite die wichtigsten Funktionen einfach dargestellt. Es werden folgende Komponenten beschrieben:

• RD Services Architecture
• RD Session Host
• RD Virtualization Host
• RD Connection Broker
• RD Web Access
• RD Gateway
• RD Licensing
• Microsoft RemoteFX

(weiterlesen…)

Vor einigen Wochen wurde im Artikel “Hyper-V und Diskeeper V-locity, eine optimale Ergänzung” die Defragmentierungs-Lösung für Hyper-V vorgestellt. Das Interesse an V-locity ist riesig, daher folgt nun ein How-To zur Installation von Diskeeper V-locity in einer Hyper-V Infrastruktur.

Da die Möglichkeiten der V-locity Konsole zur Analyse und Berichte sehr begrenzt sind, wird zudem die Management Lösung “Diskeeper Administrator” (DKA) vorgestellt.

About Diskeeper Administrator

Diskeeper 2010 Administrator spart Zeit und Geld, da die gesamte Verwaltung des Diskeeper-Betriebs für alle Computer im Netzwerk zentralisiert wird, einschliesslich Installation, Konfiguration, Überwachung, Aktualisierung, E-Mail-Berichte und Warnungen. Mit der vereinfachten auf Richtlinien basierenden Verwaltung der Clients in vorhandenen oder neuen Gruppen können Sie die Probleme mit der Dateisystemleistung an Ihrem kompletten Standort beheben, ohne Ihren Schreibtisch verlassen zu müssen.

DKA bietet allerdings weitaus mehr Funktionen als nur die Remote Verwaltung. Praktisch ist auch die Integration in System Center Operations Manager, oder auch die Benachrichtigungen per E-Mail bei Problemen. Ein besonderes Highlight ist die Installation und Verwaltung basierend auf eigenen Policies. Die angewandte Methodik ist vergleichbar mit den bereits bekannten Windows Group Policies Objects.

(weiterlesen…)