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

Die Fragmentierung der Festplattendateien ist vor allem bei I/O-intensiven Anwendungen, wo auch Microsofts Hyper-V dazuzählt, ein Problem. Wie im letzten Artikel “How-To: Verwaltung eines Cluster Shared Volume (CSV)” beschrieben kann mit durchaus mit Boardmittel eine Defragmentierung der Cluster Shared Volumes durchgeführt werden – Der in Windows integrierte Disk Defragmenter ist die erste Anlaufstelle, aber bietet nur einen limitierten Funktionsumfang. Weiter verfügen weder Host und Guests über die Information ob ein System virtualisiert ist (Virtualization Awareness) und können somit den Defragmentierungsvorgang nicht entsprechend abstimmen.

Abhilfe schafft hier V-locity von Diskeeper welche speziell für Hyper-V ausgelegt wurde. Mit der auf virtuelle Plattformen ausgelegten Lösung wird nicht einfach nur eine Defragmentierung ausgelöst – sondern die komplexen Aktivitäten zwischen Host und Guest werden laufend synchronisiert. Eine vollständige Liste der Funktionen von Diskeeper und den Limitationen von Windows Disk Defragmenter gibt es auf der Webseite von Diskeeper.

About Diskeeper V-locity

V-locity überwindet die Barrieren zur vollständigen Effizienz virtueller Systeme, mit einer neuen Technologie, die unsichtbar operiert und keinerlei Konflikte der Systemressourcen verursacht. Auf Windows Plattformen optimiert jede V-locity Komponente das jeweilige  Operating System (OS), indem sie Dateien defragmentiert und freien Speicherplatz zusammenlegt. Dies minimiert unnötige I/Os, die vom OS zum Untersystem des Laufwerks gesendet werden und ordnet Daten auf den Laufwerken so an, dass bisher unerreichte Geschwindigkeiten und Ausfallsicherheit erzielt werden.

(weiterlesen…)

Diese Woche hat Nils Kaczenski von faq-o-matic.net ein Artikel zu “LUN auswerfen?!” gepostet. Bei näherer Betrachtung hat sich herausgestellt, dass dieser Server virtuell betrieben wird und die LUNs als Wechselhardware angezeigt werden. Da dies bei manchen Servern sehr unangenehm sein kann, wenn ein Laufwerk einfach so entfernt würde, schauen wir uns die Ursache mal etwas genauer an…

Bei Hyper-V werden Datenträger entweder an einen IDE- oder SCSI-Controller angeschlossen. Da man mit SCSI weitaus eine grössere Zahl von Devices verwalten kann, sowie auch im laufenden Betrieb ohne downtime weitere Hard Disks hinzugefügt werden können, wird empfohlen für Daten Disks ausschliesslich den SCSI-Controller zu verwenden. Auch Pass-through Disks werden mit einem SCSI-Controller konfiguriert.

Nun ist es so, dass alle Hard Disks welche an einem solchen SCSI-Controller angeschlossen sind, als auswerfbar angezeigt werden. Mit einem Klick auf das Task Icon “Safely Remove Hardware and Eject Media” lässt sich die Disk auswerfen (“Eject Msft Virtual Disk SCSI Disk Device”):

Was passiert nun, wenn eine Hard Disk ausgeworfen wurde? Windows Server führt diese Aktion entsprechend durch und die Disk wird auch aus dem Storage Manager entfernt. Diese bleibt solange “verschwunden” bis a) der Server neu gestartet wird, oder b) die VHD in den Virtual Machine Settings re-attached wird. Übrigens, da IDE Hard Disks, wie zum Beispiel auch die System Disk, nicht online hinzugefügt werden können, werden diese Laufwerke auch nicht als auswerfbar angezeigt.

Ironischerweise ist die Anzeige im Device Manager korrekt und die Hard Disk wird nicht als “Devices with removable storage” aufgeführt:

Dieses Verhalten ist auch bei Windows Server 2008 R2 (Beta) mit installiertem Service Pack 1 noch so. Workaround? Eigentlich kein richtiger – “Safely Remove Hardware and Eject Media” kann zum Beispiel von der Taskbar ausgeblendet werden…

By the way – auch bei VMware werden Devices zum Auswerfen angezeigt: