Hyper-V Server 2008 R2 Netzwerk- und Cluster-Konfiguration - Hyper-V Server Blog

Hyper-V Server 2008 R2 Netzwerk- und Cluster-Konfiguration

Der Microsoft Hyper-V Server 2008 R2 ist für mich einen faszinierende komplett Version des Microsoft Windows Server 2008 R2. Mit Ihm kann man einem der Enterprise Version in nichts nachstehenden, 16 Knoten umfassenden Cluster incl. der begehrten Livemigration aufbauen. Und das Beste: für sage und schreibe 0 Euro! Richtig er kostet nichts! Aber warum wird der Hyper-V Server 2008 R2 dann so selten eingesetzt?

Meiner Meinung nach hat das drei Gründe:

  1. Ganz einfach – viele kennen diese Variante der Windows Server 2008 R2 schlicht und ergreifend nicht.
  2. Windows Administratoren haben die grafischen Tools von Windows schätzen und lieben gelernt. Deswegen mögen Sie ein System mit einer so minimalistischen Oberfläche nicht.
  3. Wer sich dann mit dem Hyper-V Server 2008 R2 beschäftigt stellt relativ schnell fest, dass die Konfiguration wenn man dann wirklich ein Cluster einsetzen möchte gar nicht so einfach ist.

Dieser Artikel soll in allen drei Fällen helfen. Man lernen den Hyper-V Server 2008 R2 kennen, ich zeige Ihnen wir man das System grafisch verwalten kann und wir konfigurieren einen kompletten Failover-Cluster. Dieser Cluster wird dabei nach unseren “Bestpractices” konfiguriert und steht damit in nichts der Vollinstallation nach. Im Gegenteil: die Core Edition hat noch den Vorteil, dass Sie wesentlich weniger Komponenten beinhaltet und damit viel weniger Patche benötigt. Das erhöht die Stabilität und verringert die Anzahl der Bootszenarien!

Deswegen zeige ich in diesem Blogartikel, wie man den Hyper-V Server 2008 R2 SP1 im Cluster installiert und zwar auf den Schulungssystemen aus unseren Hyper-V Powerkurs. Also los und bitte etwas Geduld mitbringen, der Blogartikel ist etwas “länglich”.

Netzwerk und Domäne

Nach der Basis Installation der beiden Hyper-V Server 2008 R2 SP1 stecken wir bei beiden Systemen die Management NIC ins Netzwerk. Wenn man einen DHCP Server im Netz hat bekommt das Interface damit eine DHCP Adresse. Diese ändern wir in dem wir im “sconfig” Tool (das Blaue Fenster) folgendes tun:

  1. imagePunkt 8 “Netzwerkeinstellungen“ anwählen
  2. Zahl des Interface auswählen, welches wir ändern wollen
  3. Punk 1 “IP-Adresse des Adapters festlegen” auswählen
  4. s” für statisch auswählen und IP-Adresse, Netzmaske und Gateway festlegen
  5. DNS über Punkt 2 “DNS-Server festlegen” konfigurieren
  6. über Punkt 4 “zurück zum Hauptmenü” wechseln

Da wir einige Aufgaben Remote ausführen wollen, sorgen wir dafür, dass die benötigten Remotemanagment Komponenten installiert und Remotedesktop aktiviert wird:

  1. Remotedesktop über Punkt 7 “Remotedesktop aktivieren“ aktivieren
  2. imageRemoteverwaltung” über Punkt 4 konfigurieren
  3. MMC-Remoteverwaltung” über Punkt 1 zulassen
  4. Windows PowerShell” über Punkt 2 aktivieren und neustarten
  5. am System als lokaler Administrator anmelden
  6. über Punkt 4 wieder in die Remoteverwaltung wechseln
  7. Remoteverwaltung für Windows ServerManager” über Punkt 3 zulassen
  8. über Punkt 5 wieder ins Hauptmenü wechseln

Als nächsten Schritt geben wir den Systemen einen Namen und nehmen sie in die Domäne auf:

  1. über Punkt 2 den “Computernamen” ändern
  2. über Punkt 1 der “Domäne” beitreten  und rebooten

Jetzt können wir bereits die Systeme von einem anderen Server oder von einem Windows 7 Client, der die Microsoft RSAT Tools installiert hat, managen.

Mit Hilfe des Befehls “ipconfig” oder “netsh interface ipv4 show interfaces” prüfen wir als nächstes, ob alle unsere Netzwerkkarten vom System erkannt werden. Bei unseren Schulungssystemen fehlen die vier Port des Intel I340-T4 Karte. Damit das System diese erkennt, müssen jetzt die passenden Treiber nachinstalliert werden. Wir kopieren dazu das Intel Treiber Packet “PROWinx64.exe” nach “C:\System” und führen dann die Installation mittels des Befehls:

PROWinx64.exe

durch. Ein erneuter Aufruf von “ipconfig” zeigt uns nun, dass alle Netzwerkkarten erkannt wurden. Jetzt können wir die einzelnen Karten konfigurieren. Dazu benötigen wir ein weiteres Tool: NVSBIND. Auch dieses müssen wir an  einem anderen System aus dem Internet downloaden und dann auf unsere Hyper-V Server in das Verzeichnis “C:\Tools” kopieren.

Namen der Netzwerk Portsimage

Wir haben uns wegen des besseren Verständnisses angewöhnt die Netzwerk Ports in unseren Hyper-V Installationen nach ihren Aufgaben zu benennen. In dem Screenshot rechts sieht man die Ausgabe des Befehls “netsh interface ipv4 show interfaces”. Er zeigt uns, unter anderem, die Netzwerkkartennamen. Jetzt gibt es aber ein Problem: wir haben festgestellt das es keine Zuordnung der Ports der Intel I340-T4 Karte zu den LAN-Verbindungen gibt. Deswegen hilft nur ausprobieren. Nachdem ich durch Stecken der einzelnen Ports und überprüfen mit dem “netsh” Befehl herausgefunden habe welcher Port welche Aufgabe bekommt, benennen wir diese mit dem Befehl

netsh interface set interface name=”Alter Name” newname=”Neuer Name”

imageum. Das heißt in unserem Beispiel:

netsh interface set interface name=”LAN-Verbindung” newname=”Management”
netsh interface set interface name=”LAN-Verbindung 2” newname=”iSCSI”
netsh interface set interface name=”LAN-Verbindung 4” newname=”CSV”
netsh interface set interface name=”LAN-Verbindung 5” newname=”iSCSI2”
netsh interface set interface name=”LAN-Verbindung 6”newname=”VM”
netsh interface set interface name=”LAN-Verbindung 7”newname=”Livemigration”

wird. Das Ergebnis sehen wir im Screenshot rechts.

Konfiguration des Management Ports

imageBei unserem Management Interface ist schon fast alles wie es sein soll: es besitzt eine feste IP Adresse und alle benötigten Bindungen. Einzig die Netzwerkpriorität muss geändert werden, sie soll ganz nach oben. Dazu benutzen wir den “nvsbind” Befehl:

C:\Tools\nvspbind.exe /++ Management ms_tcpip
C:\Tools\nvspbind.exe /++ Management ms_tcpip6

Konfiguration der iSCSI und iSCSI2 Ports

Aus Redundanzgründen haben wir die beiden iSCSI NICs in unterschiedlichen Netzwerkkarten gesteckt. Einmal in die Onboard Dual Port Intel Karte und einmal in die Intel 340-T Karte. Im folgenden Schritt werden wir die überflüssigen Bindungen entfernen und die IP-Adressen der entsprechenden Netzwerke setzten.

Zuerst setzten wir die IPv4 Adresse der beiden Karten. In unserem Fall nutzen wir die Netzwerke “192.168.212” für iSCSI und “192.168.213” für iSCSI2 und hängen die IP des Hosts (hier die 110)  in beiden Netzen an. Zur Konfiguration nehmen wir den “netsh”-Befehl:

netsh interface ipv4 set address ”iSCSI” static 192.168.212.110 255.255.255.0 none
netsh interface ipv4 set address ”iSCSI2” static 192.168.213.110 255.255.255.0 none

Als nächstes disablen wir alle Protokoll Bindungen, bis auf die des IPv4 Protokolls. Dazu benutzen wir “nvspbind” . Der erste Befehl schaltet dabei alle Protokoll Bindungen aus und der zweite Befehl schaltet nur “ms_tcp” (für IPv4) wieder ein:

C:\Tools\nvspbind.exe /d iSCSI *
C:\Tools\nvspbind.exe /e iSCSI ms_tcpip

C:\Tools\nvspbind.exe /d iSCSI2 *
C:\Tools\nvspbind.exe /e iSCSI2 ms_tcpip

Konfiguration des Livemigration Ports

Als nächstes setzen wir die IPv4 Adresse des Livemigration Ports und schalten IPv6 ab. Der Livemigration Port benötigt alle Bindungen, da er auch als Backup für den CSV Port dient. Auch hier benutzen wir die schon bekannten Tools “nvspbind” und “netsh”:

netsh interface ipv4 set address ”Livemigration” static 192.168.214.110 255.255.255.0 none

C:\Tools\nvspbind.exe /d Livemigration ms_tcpip6

Konfiguration des CSV Ports

Der CSV Port wird für den “Cluster-Heartbeat”, aber auch für den “Redirected Access” des Clusters benutzt. Deshalb benötigen wir ein eigenes Netz, in unserem Beispiel das “192.168.215” Netz. Da der “Redirected Access” über SMB funktioniert, muss zusätzlich der Microsoft Netzwerkclient gebunden sein. Bestpractice ist allerdings die beiden Bindungen der “Topologieerkennung” auszuschalten. Hier sind die Befehle dazu:

netsh interface ipv4 set address ”CSV” static 192.168.215.110 255.255.255.0 none

C:\Tools\nvspbind.exe /d CSV ms_tcpip6
C:\Tools\nvspbind.exe /d CSV ms_rspndr
imageC:\Tools\nvspbind.exe /d CSV ms_lltdio

Konfiguration des VM Ports

Über den VM Port kommunizieren die Virtuellen Maschinen mit dem Netzwerk. Hier werden alle Protokolle entfernt und nur die virtuelle Switch aktiviert (siehe Screenshot rechts):

C:\Tools\nvspbind.exe /d VM *
C:\Tools\nvspbind.exe /e VM vms_pp

 

“NetBIOS über TCP/IP” und “DNS Registrierung” deaktivieren

Im nächsten Schritt möchten wir einerseits das Feature “NetBIOS über TCP/IP” deaktivieren und andererseits verhindern das die IP-Adressen unsere “Cluster-NICs” im DNS eingetragen werden. Zuerst müssen wir wissen, welchen Index unsere “Cluster-NICs” iSCSI, iSCSI2, CSV imageund Livemigration haben. Dazu geben wir in der Kommandozeile folgenden Befehl ein:

wmic nicconfig get caption,index,ipaddress

Aus der Ausgabe dieses Befehls können wir anhand der angezeigten IP-Adressen die  benötigten Indexe unserer Netzwerkkarten herauslesen (siehe Screenshot).  Jetzt wenden wir folgende Befehle auf jeder der vier NICs an:

wmic nicconfig where index=<Index der NIC> call SetTcpipNetbios 2
wmic nicconfig where index=<Index der NIC> call SetDynamicDNSRegistration 0, 0

Hierbei ersetzen wir <Index der NIC> durch den Index aus dem Screenshot. Der erste Befehl deaktiviert das Feature “NetBIOS über TCP/IP” und der zweite schaltet “Adressen dieser Verbindung im DNS aktivieren” aus. Nachfolgend die Befehle für unser Netzwerke im Beispiel:

Für das iSCSI Interface:

wmic nicconfig where index=3 call SetTcpipNetbios 2
wmic nicconfig where index=3 call SetDynamicDNSRegistration 0, 0

Für das iSCSI2 Interface:

wmic nicconfig where index=8 call SetTcpipNetbios 2
wmic nicconfig where index=8 call SetDynamicDNSRegistration 0, 0

Für das CSV Interface:

wmic nicconfig where index=6 call SetTcpipNetbios 2
wmic nicconfig where index=6 call SetDynamicDNSRegistration 0, 0

Für das Livemigration Interface:

wmic nicconfig where index=10 call SetTcpipNetbios 2
wmic nicconfig where index=10 call SetDynamicDNSRegistration 0, 0

Bitte achten Sie unbedingt darauf das Ihnen jeder Befehl mit der Ausgabe:

Methode würde ausgeführt,
Ausgabeparamter:
instance of __PARAMETERS
{
ReturnValue = 0;
}

quitiert wird. Andernfalls muss man den Befehl und den Index der NIC prüfen.

Wir sind jetzt soweit, dass wir die Netzwerke benannt, ihnen feste IP-Adressen in den entsprechenden IP-Netzen gegeben und nur noch die nötigen Bindungen auf den Ports belassen haben. Jetzt gehen wir daran die iSCSI Anbindung an den benötigten Storage herzustellen.

iSCSI und MPIO

Da wir nach unserer Bestpractice zwei Verbindungen zum iSCSI Storage benötigen, müssen wir dafür sorgen, dass das Multipath-IO Feature des Betriebssystems installiert wird. Mit ihm ist es dann möglich, dass die redundanten Pfade zum Storage auch richtig benutzt werden. Unsere beiden Netzwerke haben wir schon als iSCSI und iSCSI2 im oberen Bereich des Beitrags konfiguriert, so dass wir nun das MPIO Feature nachinstallieren und den Microsoft DSM aktivieren müssen.

Hierzu rufen wir folgende beiden Befehle in einer Kommandozeile auf:

ocsetup MultipathIo /norestart
mpclaim -r -i -d “MSFT2005iSCSIBusType_0x9”

Das System rebootet und nach dem erneuten Einloggen starten wir in der Kommandozeile mit dem Befehl “iscsicpl” das iSCSI Control Panel. SNAGHTML17ab274Nach Bestätigung das der “Microsoft iSCSI-Initiator-Dienst” gestartet wird, konfigurieren wir nun die Anbindung unser Quorum und CSV Storage über zwei redundante Storage Pfade.

Zur eigentlichen iSCSI und MPIO Konfiguration habe ich ein 11 Minütigen Videocast gedreht (Videocast: Wie man iSCSI und MPIO für Hyper-V konfiguriert). Deshalb erkläre ich die Konfiguration hier nur nochmal im Schnelldurchlauf.

Schritte nach Aufruf von “iscsicpl”:

  1. Auf Reiter “Suche” navigieren
  2. Portal ermitteln…” anklicken
  3. erste IP-Adresse des iSCSI Storage (im Beispiel 192.168.212.61) eintragen und “Erweitert…” anklicken
  4. Microsoft iSCSI-Initiator auswählen und unter Initiator-IP die Adresse des Hosts aus dem gleichen Netz auswählen (im Beispiel 192.168.212.110) image
  5. OK” anklicken und im Dialog “Ziel verbinden…” auch “OK” anklicken
  6. Jetzt wechseln wir auf den Reiter “Ziele
  7. Klicken erneut auf “Verbinden…
  8. Wählen “Multipath aktivieren” aus
  9. und klicken auf “Erweitert…
  10. im Dialog “Erweitert” konfigurieren wir unseren zweiten Pfad zum iSCSI Storage (im Beispiel 192.168.213.61)
  11. OK” anklicken
  12. Im Dialog “mit Ziel verbinden…” auch “OK” anklicken
  13. Jetzt nochmal den Vorgang 7 bis 12 für die ursprüngliche IP-Adresse (192.168.212.61) wiederholen
  14. imageDanach wechseln wir in den Reiter “Bevorzugte Ziele
  15. hier prüfen wir ob wir zwei Einträge unter “Bevorzugte Ziele” finden
  16. dann wechseln wir auf den Reiter “Volumes und Geräte
  17. Wenn die Volumeliste leer ist, klicken wir auf “Autom. konfigurieren” und es sollten unsere Ziele erscheinen
  18. OK” anklicken

Wenn man diese Schritte auf allen zukünftigen Cluster Knoten durchgeführt hat, können wir unsere Volumes CSV1 und Quorum formatieren.

Vorbereitung und Anbindung des CSV1 und Quorum Volumes

imageDazu gibt es zwei Möglichkeiten: das Tool “Diskpart” und die “Speicherverwaltung” von “Windows Server 2008 R2” oder der “Windows 7 RSAT Tools”. Ich habe mir für die grafische Remote Variante entschieden. Deswegen öffne ich auf einem Windows 2008 R2 System den Servermanager (Achtung: man benötigt Domäne Administrator Rechte).

  1. Rechtsklick auf Servermanager und dann “Verbindung mit anderem Computer herstellen…” auswählen
  2. Im sich öffnen Dialog gibt man den Computernamen ein und klickt auf “OK

imageJetzt öffnet sich der Servermanager mit der Verbindung zum Hyper-V Server (im Beispiel hvserver1). Im nächsten Schritt klicken wir auf “Speicher” und dort dann auf “Datenträgerverwaltung” und bekommen den Fehler “Der RPC-Server ist nicht verfügbar”. Zur Remote Datenträgerverwaltung gibt es einen Artikel von Jan Kappen: Grafische Datenträgerverwaltung eines Hyper-V Server R2 worin er diesen Fehler beschreibt. Es muss auf dem System auf dem der Servermanager läuft in der Firewall die imageRemotevolumenverwaltung zugelassen werden. Diese Ausnahmen konfiguriert man wie folgt:

  1. Aufruf der “Windows FireWall” über die Systemsteuerung
  2. Klick auf “ein Programm oder Feature durch Windows FireWall zulassen
  3. Modifikation der Einstellungen durch klicken auf “Einstellungen ändern” einschalten
  4. Bis zu “Remotevolumenverwaltung” scrollen und durch klick auf die Checkbox für das “Domainenprofil” aktivieren
  5. Mit “OK” bestätigen

imageJetzt können wir uns erneut im Servermanager mit dem Hyper-V Server 2008 R2 verbinden und nachdem wir auf “Datenträgerverwaltung” geklickt haben, sind wir mit  dem Hyper-V Server verbunden.

Der “Datenträgerinitialisierung” Dialog erscheint (1) und wir müssen unsere beiden Volumes (2) initialisieren. Hier belassen es beim Default “MBR” und klicken auf “OK”.

Im nächsten Schritt formatieren wir auf dem ersten Clusterknoten die beiden Partitionen. SNAGHTML165aadDazu rechtsklicken wir in das größere der beiden Volumes (im Beispiel neben Datenträger 2 in den schraffiert Bereich) und erzeugen ein “Neues einfaches Volume”:

  1. den ersten Dialog überspringen wir mit klick auf “Weiter
  2. Im folgenden Dialog klicken wir “Keinen Laufwerksbuchstaben oder –pfad zuweisen” an und dann auf “Weiter
  3. Dann wählen wir “Dieses Volume mit folgenden Einstellungen formatieren:” an und belassen Werte (NTFS, Standard, “Schnellformatierung durchführen”) auf ihren Standardwerten. Nur bei dem Namen vergeben wir für das große Volume “CSV1”.
  4. Danach klicken wir auf “Weiter” und auf der im folgenden Dialog auf “Fertig stellen

Die obigen Schritte führen wir auch für das zweite, kleinere Volume aus (im Beispiel Datenträger 3 mit 1 GB) nur das wir das Volume dabei “Quorum” nennen.

imageNun schalten wir beide Datenträger Offline indem wir auf Datenträger rechtsklicken und dann Offline anwählen. Im Screenshot rechts sieht man wie Datenträger 2 bereits Offline ist und wir den Vorgang bei Datenträger 3 gerade ausführen.

Nun führen wir die Datenträgerverwaltung für die weiteren Hyper-V Server 2008 R2 durch. Dazu verbinden wir den Servermanager mit dem nächsten System (im Beispiel hvserver5) und klicken auf die “Datenträgerverwaltung”. Hier müssen wir dann ebenfalls die Datenträgerinitialisierung der beiden Volumes durchführen.

image

Installation Failover-Clusterunterstützung

Das Failovercluster Feature wird über die Hyper-V Server Konsole installiert. Man geht dazu wie folgt vor:

  1. Im “sconfig” Punkt 11 “Failoverclusterfeature” eingeben
  2. Dim Dialog “Failover-Clusterünterstützung jetzt hinzufügen?” auf “Ja” klicken
  3. Danach läuft die Installation durch, deren Fertigstellung mit Klick auf “OK” bestätigt

Als nächstes richten wir den Failover-Cluster ein. Hierzu benötigen wir wieder entweder die “Windows 7 RSAT Tools” oder einen “Windows 2008 R2 Server” mit mindestens der Enterprise Edition. Mein Notebook hat Windows Server 2008 R2 SP1 Enterprise installiert, weswegen ich über “Start –> Verwaltung” den Failovercluster-Manager aufrufe. Bevor wir den Cluster erstellen lassen wir die Clustervalidierung laufen. Diese rufen wir auf, indem wir im mittleren Bereich auf “Konfiguration prüfen…” klicken.SNAGHTML827e46

  1. Jetzt geben wir die an dem Failover-Cluster beteiligten Systeme ein und klicken auf “Weiter
  2. Alle Tests ausführen (empfohlen)” anwählen und auf “Weiter” klicken
  3. Weiter” anklicken um die Validierung zu starten
  4. Die Validierung läuft
  5. Nach der Validierung wir der Failovercluster-Prüfbericht angezeigt. Hier klicken wir auf “Bericht anzeigen…
  6. Failovercluster-Prüfbericht prüfen

Nachdem die Validierung durchgelaufen ist, prüfen wir den Bericht auf Fehler. Falls Fehler angezeigt werden sind diese zu beseitigen und danach eine erneute Validierung durchzuführen.

SNAGHTML2b90d18In unserem Fall gab es keine Fehler, sodass wir mit der eigentlichen Cluster Einrichtung starten können. Um dies zu tun klicken wir im mittleren Bereich des Failovercluster-Managers auf den Link “Cluster erstellen…” und es öffnet sich der “Clustererstellungs-Assistent”.

  1. Durchlesen der Einführung und dann  auf “Weiter” klicken
  2. Servernamen der an dem Failover-Cluster beteiligten Systeme eingeben
  3. Weiter” klicken
  4. Cluster Name und Cluster IP-Adresse eingeben
  5. Weiter” klicken
  6. Bestätigung prüfen und dann “Weiter” anklicken
  7. Clusterinstallation abwarten
  8. Zusammenfassung anschauen und mit “Fertig stellen” Installation beenden

Falls die Zusammenfassung keine Fehler enthält haben wir nun die Grundinstallation des Failover-Clusters durchgeführt.

Konfiguration des Failover-Clusters

Um das eigentliche “Feintuning” des Failover-Clusters durchzuführen, starten wir wieder den Failovercluster-Manager. Wir wählen im mittleren Fenster den Link “Cluster verwalten…” und verbinden uns mit dem Cluster. Als nächstes werden wir folgende Themen bearbeiten:

  • Einrichtung des Netzwerkkonfiguration (welches Netz übernimmt welche Aufgabe)
  • Wir werden das “Freigegebenen Clustervolume” aktivieren (Cluster Shared Volume)

Netzwerkkonfiguration

SNAGHTML2f8beacWenn wir im linken Fenster “Netzwerke” öffnen, dann sehen wir die Netze “Clusternetzwerk 1” bis “Clusternetzwerk 5”. Das sind nicht wirklich sprechende Namen, mit denen man im Problemfall nicht wirklich etwas anfangen kann. Um das zu ändern müssen wir wissen wie die Netze heißen. Wenn wir ein Netzwerk anklicken, dann sehen wir im Mittelbereich welche Netzwerkkarten daran beteiligt sind. Mit diesem Wissen können wir das Netzwerk jetzt über drücken der “F2” Taste umbenennen. Wenn wir das mit allen Netzwerken getan haben, heißen diese nun  “Management”, “Livemigration”, “CSV”, “iSCSI” und “iSCSI2”.

SNAGHTML301ff35Jetzt konfigurieren wir, welches Netz für die Clusterkommunikation(Cluster Heartbeat) benutzt wird.

  1. Dazu rechtsklicken wir auf das Netz “CSV” und wählen “Eigenschaften” aus
  2. den Punkt “Netzwerkkomunikation für Cluster in diesem Netzwerk zulassen” anklicken und mit
  3. OK” bestätigen

Die gleichen Einstellungen wiederholen wir beim Netzwerk “Livemigration” und “Management”. Allerdings aktivieren wir im “Management” Netz zusätzlich die Checkbox “Client das Herstellen  einer Verbindung über dieses Netzwerk gestatten”. Bei den beiden “iSCSI” und “iSCSI2” Netzwerken stellen wir den Punkt “Netzwerkkommunikation für Cluster in diesem Netzwerk nicht zulassen” ein, da diese nicht für den Cluster Heartbeat benutzt werden sollen.

Als nächstes konfigurieren wir das Netz, über den der Cluster den “Redirected Access” abwickelt soll. Hierzu müssen wir auf einen der Hyper-V Server 2008 R2 wechseln. Dort öffnen wir die PowerShell, indem wir in einer Kommandozeile “powershell” eingeben. Danach laden wir das Powershell FailoverCluster Module und lassen uns die Metriken der Netzwerkschnittstellen anzeigen:

Import-Module FailoverClusters

Get-ClusterNetwork | ft Name, Metric, Autometric

imageDas Netzwerk mit der niedrigsten Metrik wird vom Cluster automatisch für den “Redirected Access” genutzt. In unserem Fall ist das, das “Livemigration” Netz. Deshalb setzen wir die Metrik des “CSV” Netzes und des “Livemigration” Netzes per Hand neu. Hierzu nutzen wir in der PowerShell folgende Befehle:

(Get-ClusterNetwork “CSV”).Metric=900
(Get-ClusterNetwork “Livemigration”).Metric=1100

image

image

Im Screenshot sehen wir dass nun das “CSV” Netzwerk die niedrigste Metrik besitzt und damit für den “Redirected Access” benutzt wird. Ebenso haben wir damit das Netz für die “Livemigration” bestimmt. Es wird das Netz mit der zweitniedrigsten Metrik benutzt. Wirklich festlegen sollte man dies aber im Failovercluster-Manager. Hierzu müssen wir die Eigenschaften einer hochverfügbaren Virtual Maschine aufrufen. Dann wechseln wir über den Reiter “Netzwerk für Livemigration” in die Liste der Netzwerke. Hier sehen wir, dass das “Livemigration” Netzwerk ganz oben steht. Wenn das nicht der Fall ist wählt man das entsprechende Netz an und klickt solange auf “Nach oben” bis es an erster Stelle steht. Im Screenshot sehen wir, dass das “Management” Netzwerk ebenfalls mit einem Hacken versehen ist und an zweiter Stelle steht. Mit dieser Einstellung legen wir fest, über welches Ausfallnetz der Cluster im Falle eines Problems mit dem “Livemigration” Netzwerk den Speicher der VMs verschieben soll.

Freigegebene Clustervolume aktivieren

imageIm letzten Schritt aktivieren wir die Clustervolumes. Wir tuen dies, indem wir:

  1. im linken Bereich den Cluster anwählen
  2. dann im mittleren Fenster auf den Link “freigegeben Clustervolume aktivieren…” klicken
  3. Im Dialog müssen wir das Lesen des Hinweis mit anklicken der Checkbox “Ich habe den Hinweis gelesen” bestätigen
  4. Danach kann man die Aktivierung mit klicken auf “OK” aktivieren

SNAGHTML374f43fNachdem wir den Vorgang ausgeführt haben erscheint im linken Navigationsbereich der Punkt “Freigegebene Clustervolumes“. Um ein CSV-Volumen bereitzustellen müsssen wir folgendes tun:

  1. Wir klicken den Punkt “Freigegebene Clustervolumes“ an
  2. Im rechten Bereich klicken wir dann auf “Speicher hinzufügen
  3. Im Dialog bekommen wir das “CSV1” Volume angeboten welches wir durch klicken der Checkbox auswählen
  4. Um die die Einrichtung abzuschließen klicken wir “OK

Nun haben wir das erste Cluster Shared Volume aktiviert. Zur Prüfung schauen wir auf einem der Hyper-V Server 2008 R2, ob wir unter C:\ClusterStorage” ein Verzeichnis “Volume1” finden.

Was kommt als nächstes

Wir haben nun einen robusten, hochverfügbaren Hyper-V Cluster der nun mit VMs bespielt werden kann. Diese kann man entweder im Failovercluster-Manager anlegen oder exportierte VMs nach “C:\ClusterStorage\Volume1” kopieren und dann in den Cluster importierten.

Ich hoffe ich habe sie mit den vielen Schritten nicht abgeschreckt und wünsche viel Spaß beim Virtualisieren.

Carsten Rachfahl
 

Dipl. Ing. Carsten Rachfahl ist seit mehr als 25 Jahren in der IT-Branche tätig. Er ist einer der geschäftsführenden Gesellschafter der Rachfahl IT-Solutions GmbH & Co. KG und für den technischen Bereich verantwortlich.

  • James van den Berg sagt:

    Hi Carsten,
    Nice blogpost!
    Cheers, James

  • HaWa sagt:

    Dafür ein riesiges DANKE!!

  • MichaelS. sagt:

    Sehr gut beschrieben…. Kann ich auch nur bestätigen, das HyperV super läuft. Nur bei uns unter mit einem angeschlossenen FC SAN.

  • Alex sagt:

    Ich vermisse noch die Einbindung des Quorum Volumes. Wird das noch irgendwo zugewiesen?

    Super Artikel! ;)
    Danke,
    Alex

  • Jan sagt:

    Super Artikel Carsten,
    vielen Dank. P.S. Bin mal auf vNext des Hyper-V-Servers gespannt.

  • Sebi sagt:

    Hi,
    bei der Onfiguration der iSCSI Ports lautet es bei Dir:
    C:\Tools\nvspbind.exe /e iSCSI ms_tcp
    sollte es nicht nicht so lauten:
    C:\Tools\nvspbind.exe /e iSCSI ms_tcpIP

    Ansonsten konnte der Blog mir noch nützliche Tipps bei meinem HV Cluster geben. Daumen hoch!

  • Jan sagt:

    Hallo Herr Rachfahl,

    sie haben in Ihrem Artikel beschrieben das man das CSV- und Heartbeat Netz idealerweise trennen sollte. Da wir in unseren Servern mehr Netzwerkports zur Verfügung haben als sie in ihrem Schulungssystem würde ich diese Netze gerne trennen. Wie trennt man denn das CSV & Heartbeat Netz? Vielen Dank schonmal im vorraus und auch für die tolle Beschreibung.

  • Also ich finde den Hyper-V sehr intresant, nur leider wollte ich ihn auf einen V-Server installieren und das sorgt jetzt für einen Permanenten neustart des Systems.

  • Zu Sebi’s Kommentar:
    nein es sollte schon “ms_tcp” heissen. Scripte sind mehrfach getestet und es würde mich sehr wundern wenn sich da ein Fehler eingeschlichen hat (aber man weiss ja nie).

    Zu Jan’s Kommentar:
    Hardbeat setzt du auf den Clusternetzen fest mit dem Haken “Clusterkommunikation für dieses Netzwerk zulassen”. Wir haben das immer auf Management, CSV und Livemigration gesetzt.

  • Sebi sagt:

    Hi Carsten,
    also wenn ich mir nur das Binding einer NW anschaue mit “nvspbind.exe ” wird kein “ms_tcp” für IPV4 sondern “ms_tcpip” angezeigt, so sieht es auch beim der IPV6 aus, da gebt Ihr ja auch “ms_tcpip6” an. Zumindest ist das von mir gestesten unter dem Hyper-V Server 2008 R2 SP1 in DE und US Version. Kann es sein das dies die Beschreibung bei einem Hyper-V 2008 ist mit dem “ms_tcp”

  • Hi Sebi,

    du hast natürlich Recht. Habe es nochmal angeschaut und es muß “ms_tcpip” sein und nicht “ms_tcp”. Habe es korrigiert!

    Danke für den Hinweis.

    Carsten

  • TomS sagt:

    Danke für diesen Artikel! :)

  • Adam Richter sagt:

    Wir setzten häufig und gern den Windows Storage Server ein, da die Lizenzkosten (gibt es nur von OEMs zusammen mit Hardware – z.B. http://www.exomium.com) einfach attraktiv sind – leider lässt sich damit kein Storage-HA-Cluster direkt umsetzen. Ich kenne leider auch nichts außer Sansymphony, das leider recht kostspielig werden kann, um das ohne extra-Storages ab der Windowswelt umzusetzen. Hat jemand dazu eine Idee?

  • Frank C sagt:

    Erst einmal vielen Dank für den hilfreichen Artikel. Nach der Umsetzung mit 3 Knoten und einem ISCSI-SAN lief das Cluster auch ca. einen Monat ohne Fehler… dachte ich. Nach dem Neustart eines Knotens versuchte dieser die LUNs/Disks explizit anzubinden und lockte damit auch die LUNs/Disks. Ergebnis war das der Cluster nicht mehr funktionierte. Die anderen Hyper-V-Server hatten keinen Zugriff auf die LUNs/Disks. Nach einer “Reparatur” des Clusters konnte das Cluster wieder aktiviert werden, sodass alle Knotes Zugriff auf die LUNs/Disks hatten. Was mir dann aber auffiel war, das nur einer der 3 Server die LUNs/Disks wirklich im Zugriff hatte. Was mir noch aufgefallen ist, das das Änderungsdatum der VHDs nicht sauber geschrieben wird, auch wenn Änderungen in den VMs durchgeführt werden.
    Hat dazu jemand eine Idee oder Hinweise?
    Vielen Dank

  • Jan Kappen sagt:

    Hallo Frank,
    wenn das Cluster korrekt aufgebaut wird ist der Neustart eines Knoten kein Problem, vorher sollte der Besitz von dem/den CSV(s) von diesem Knoten weggenommen werden, damit dies nicht während des Shutdown-Vorgangs gemacht werden muss. Funktioniert zwar auch, anders ist aber sicher. Was ich jetzt nicht ganz verstehe: Was meinst du mit “explizit anbinden” und “lockte damit auch die LUNs/Disks”?
    Es hat immer nur einer der Knoten das CSV direkt und voll im Zugriff, die anderen bekommen nur Zugriff auf die Bytes, die zu den VMs auf diesem Knoten gehören. Dies ist bedingt durch das NTFS-FS, dieses ist grundsätzlich nicht cluster-aware…
    Gruß, Jan

  • Torsten sagt:

    Hi Frank,

    Erstmal eine top Anleitung hast du da geschrieben!

    Aber ich habe mal eine Frage dazu:

    Also ich habe zwei baugleiche HP Server G6 mit 25 Festplatten 2 sind im Raid 1 und da laeuft das System drauf der Rest ist im Raid 5 und eine ist Spare! auf beiden ist der HyperV Server installiert und konfiguriert sowie es beschrieben ist.

    Jetzt habe ich nur folgendes Problem; der Storage!
    Ich moechte oder ich muss den restlichen Storage verwenden als Cluster Speicher. So das sie diesen Speicher verwenden und keinen extra Server (SAN)

    Funktioniert das ueberhaupt mit nur 2 Server, wenn ja muss ich was anderest machen an den einstellung?

    Vielen Dank
    Torsten

  • Jan Kappen sagt:

    Hallo Torsten,
    das funktioniert nicht. Du kannst unter 2008 R2 keine lokalen Festplatten als gemeinsamen Speicher verwenden, es sei denn du installiert ein iSCSI-Target auf dem System und gibt den Speicher zur gemeinsamen Nutzung frei.
    Gruß, Jan

  • Torsten sagt:

    Hallo Jan,

    Vielen dank fuer die schnelle Antwort.

    Also um das so zu realisieren soll ich ein ISCSI Target auf dem HyperV Server erstellen und diese dann Freigeben?

    Wenn ja hast du auch zufaellig eine Anleitung dazu?

    mfg
    Torsten

  • Jan Kappen sagt:

    Hallo Torsten,
    diese Art von Betrieb ist nicht empfohlen, da hier mit starken Performance-Einschränkungen zu rechnen ist. Was genau ist dein Ziel? Der Aufbau eines Failover Cluster ohne SAN? Dies lässt sich unter Server 2008 R2 nicht erreichen, es wird zwingend gemeinsam genutzter Speicher benötigt. Um diesen möglichst performant zu gestalten, sollte eine professionelle SAN-Lösung genutzt werden, da es sonst zu Performance-Problemen kommt. Unter Windows Server 2012 erweitern sich die Möglichkeiten in diesem Fall, hier kann z.B. mit SMB 3.0 eine Freigabe erstellt werden, auf dem die Daten der VMs gespeichert und ggf. in einem Cluster-Verbund genutzt werden. Der Server, der für den Betrieb der Freigabe verantwortlich ist, sollte allerdings keine eigenen VMs ausführen. Je nach Konfiguration kann er dies auch nicht (zumindest nicht über die eigene Freigabe, Stichwort “SMB Loopback”).
    Gruß, Jan

  • Torsten sagt:

    Hi!

    Ja mein Ziel ist es ein FailoverCluster unter HyperV Server 2008r2 ohne SAN zu realisieren!

    Um die Performance mache ich meine keine sorgen nur um die Umsetzung! wenn das geht!

  • Torsten sagt:

    Hi

    Das Problem ist das ich nur zwei HP ProLiant DL380P G8 Server mit 25x600GB zur Verfuegung habe und ich kann auf den nur HyperV Server 2008r2 oder Windows Server 2008r2 installieren! Ich bekomme auch keinen extra Server mehr dazu! Extra software ist auch schwierig weil kein Geld…..Zwickmuehle eben!

    Auf diesen Servern soll ich unsere Virtuellen Maschinen installieren (8 Server)

    Und aus dieser konstellation muss ich eine ausfallsicherheit herstellen!

    Und zur Zeit weis ich leider nicht wie und suche verzweifelt nach einer Loesung!

    vielleicht faellt euch noch was dazu ein! Hoffentlich :)

    mfg
    Torsten

  • Chris sagt:

    Hallo Torsten,

    Starwind Native SAN for Hyper-v sollte dein Problem lösen.

    http://www.starwindsoftware.com/native-san-for-hyper-v

    mfg

    Chris

  • Markus sagt:

    Hallo Zusammen,

    kann man eigentlich auf einen 2008R2 Hyper-V Cluster auch ein Storage Vmotion ohne SCVMM Anbindung machen?

    Gruß

    Markus

  • Tim Diekhans sagt:

    Hallo,

    ich suche verzweifelt das NVSPBind Tool. Die MS Seite auf welche gefühlt das halbe Internet verweist, ist mittlerweile “retired”. Gibt es die .exe noch anderswo bzw. kann sie mir jemand zukommen lassen?

    Grüße,
    Tim

  • >