Prozessoren und deren Funktionen sind ein wichtiger Bestanteil für die Server Virtualisierung. In einem älteren Artikel (Hyper-V CPU Anforderungen) wurde bereits detailliert beschrieben, welche Funktionen Hyper-V voraussetzt und wie diese aktiviert werden können.

Anders als bei Memory findet bei Prozessoren generell ein over-commit statt. Das heisst es werden den Virtual Machines mehr Ressourcen zugewiesen, als physikalisch vorhanden sind. Damit dies am Schluss sich nicht negativ auf die Performance der Virtual Machines und den Host auswirkt, sollte die Empfehlung von Microsoft befolgt werden. Aktuell wird die Limite auf ein Maximum von 8 v-procs pro logical Processor festgelegt. Für die beste Performance sollte aber wenn möglich eine Ratio von 1:4 nicht überschritten werden. Um die aktuelle Auslatung auslesen zu können, kann eine Zeile PowerShell Code ausgeführt werden: write-host (@(gwmi -ns root\virtualization MSVM_Processor).count / (@(gwmi Win32_Processor) | measure -p NumberOfLogicalProcessors -sum).Sum) "virtual processor(s) per logical processor" -f yellow

Damit stell Ben Armstrong ein sehr nützliches Hilfsmittel bereits um die aktuelle Auslastung genauer zu prüfen, indem die Anzahl “MSVM_Processor” Instanzen ausgelesen werden um die aktuell laufenden Virtual Machines respektive der zugewiesenen v-procs auszulesen:

Diesen Beitrag weiterlesen »

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

Diesen Beitrag 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 keine Guest Cluster Konfiguration für diese Versionen.

Windows Server 2003

Damit eine Cluster Konfiguration durch Microsoft supported wird, muss diese zuvor 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 und als “Cluster Solution” beim Windows Server Catalog aufgeführt. Die vollständige Support Policy wird in Microsoft KB 309395 beschrieben.

Bei VMware haben zwei Lösungen das erforderliche Logo für einen Guest Cluster 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 zusätzlichen 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 Konfiguration durch Microsoft supported wird, müssen sämtliche Komponenten über ein Windows Server Logo verfügen und die Cluster Validierung (Validate a Configuration…) muss bestanden worden sein. Die Konfiguration von Windows Server 2008 und auch 2008 R2 als Guest Cluster wird ebenfalls durch Microsoft supported. Die vollständige Support Policy wird bei Microsoft TechNet beschrieben. Speziell dem Abschnitt “Virtualized Servers” sollte Aufmerksamkeit geschenkt werden.

Hinweise zu VMware

VMware selbst hat einen Knowledge Base Artikel mit dem Namen Microsoft Cluster Service (MSCS) support on ESX veröffentlicht wo weitere Informationen festgehalten wurden. Speziell dem Abschnitt “vSphere MSCS Setup Limitations” sollte Aufmerksamkeit geschenkt werden. Zudem sollten auch die VMware Support Policies auf zusätzliche Hinweise geprüft werden. Nachfolgend das wichtigste in Kürze zusammengefasst:

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

Per Juli 2010 kann folgende Support Matrix für Guest 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 Betriebssystem (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.

Diesen Beitrag 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:

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 um ein grosses Stück 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 Network und Storage geschaffen werden. Aber auch Aufgaben aus dem “Daily Business” müssen mit grösster Sorgfalt und bei CSV Volumes oftmals ein wenig anders durchgeführt werden. In den nachfolgenden Abschnitten werden daher die wichtigsten Punkte näher erläutert.

Diesen Beitrag weiterlesen »

Der Core Installation Mode (Server Core) ist sehr häufig mit Hyper-V und natürlich bei Hyper-V Server anzutreffen. Durch die geringe Angriffsfläche, Wartungs- und Verwaltungsaufwand ist dies die ideale Konfiguration. Ein sicheres System ist nicht immer die einfachste Variante – gerade die Installation von NIC Treiber und/oder Teaming Software ist bei Server Core aufwändiger als bei einer Installation im Full Installation Mode, aber durchaus machbar.

In gewissen Konstellationen kann es vorkommen / angebracht sein – nicht verendete Network Adapter zu deaktivieren. Bei Server Core wird dies mit dem Netsh Command-Line Utility durchgeführt: “netsh interface set interface "Local Area Connection 4" DISABLED. Der Status der Network Adapter kann mittels “netsh interface show interface” überprüft werden.

Es kann allerdings nachträglich zu Problemen kommen, diesen Adapter wieder zu aktivieren. Zum Beispiel nach einem Update der Treiber (zum Beispiel bei Broadcom in HP Server…). Der Status bleibt dann auch nach der Anwendung von Netsh “Disabled”. Ein simples WMI-Script kann hier Abhilfe leisten:

Function EnablePreviouslyDisabledNics()
    strComputer = "."
    Set objWMIService = GetObject("winmgmts:\\" & _
    strComputer & "\root\cimv2")
    Set colAdapters = objWMIService.Execquery("Select * from Win32_NetworkAdapter Where NetEnabled=False")
    For Each Adapter in colAdapters
        Adapter.Enable()
    Next
    Set objWMIService = Nothing
End Function

EnablePreviouslyDisabledNics

Einfach als enableNIC.vbs speichern und auf dem Server aufrufen, “cscript enableNIC.vbs“. Sämtlich deaktivierten Network Adapter werden nun wieder aktiviert und der können wieder verwendet werden. Mit “netsh interface show interface” kann wieder der Status überprüft werden.

Weitere Informationen

• Microsoft TechNet: Netsh Commands for Interface (IPv4 and IPv6)

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

Wir leben heute in einer vernetzten Welt. Viele der wirtschaftlichen und intellektuellen Barrieren, welche uns früher trennten, existieren nicht mehr.

So beginnen Christoph Müller und Reiner Ganser ihr neues Buch zum Thema SharePoint Server. Ein Buch welches darauf abzielt die Eckpunkte und Chancen, aber auch die Gefahren welche ein SharePoint Projekt mit sich bringt näher zu bringen. Der Namen wurde daher sehr passend gewählt, “Erfolgreiche Portalprojekte mit Microsoft SharePoint”.

Wer schon mal eine Plattform für Kommunikation und Zusammenarbeit bereitgestellt hat, der weiss dass die technische Umsetzung nur einen geringen Teil des Aufwands ausmacht. Viel mehr Zeit fordern kreative Ideen, Konzepte und Definition von Abläufen – nicht gerade das tägliche Brot eines IT Professionals. Doch genau hier kommt dieses Buch ins Spiel – denn beide Autoren schöpfen voll und ganz aus ihrer mehrjährigen Erfahrung zum Thema SharePoint und können daher auch vieles als “Notes from the field” direkt an den Leser weitergeben. Dabei bewegt sich das Buch immer zwischen gesundem Menschenverstand und Technologie. Mit rund 370 Seiten ist dies die ideale Lektüre für die bevorstehenden Sommerferien.

Diesen Beitrag weiterlesen »

Von einer Weile hat Microsoft angekündigt, dass Hyper-V Server 2008 R2 (HVS) auch boot von USB Flash Devices (UFD) unterstützt. Somit kann der Hypervisor zukünftig ohne lokale Hard Disks auskommen, ohne an Funktionen zu verlieren. Wenn man die Konfiguration etwas genauer unter die Lupe nimmt, so kann man feststellen dass nicht nur USB Flash Drives als Medium unterstützt werden, sondern dass Hyper-V dazu auch direkt Boot aus einem VHD Image startet.

Anforderungen

• USB Flash Device
  • Standard Storage Device (Class 08h)
  • USB 2.0 kompatibel
  • Non-removable, internal Device
  • Minimum 8 GB Kapazität, Empfohlen 16 GB
  • Plattform Firmware muss Boot von USB 2.x Port unterstützen
• Software
  • Hyper-V Server 2008 R2
  • Windows AIK

Der Vorgang um HVS von einem USB Flash Device starten zu können, umfasst mehrere Schritte. Diese werden nachfolgend im Detail beschrieben…

Diesen Beitrag weiterlesen »