RSS

Aufbau und Einrichtung eines Failovercluster unter Windows Server 2012

WinServ2012-ClusterDer Windows Server 2012 ist raus, unser aktuelles Cluster unter Windows Server 2008 R2 SP1 sollte so schnell wie möglich durch ein neues in der aktuellen Version ersetzt werden. Ich habe mich der Thematik angenommen und eine “Migration” durchgeführt, die ich hier gerne in ein paar Artikeln beschreiben möchte. Großer Vorteil unserer eigenen EDV: Wir haben auf unserer NetApp nicht den kompletten Speicherplatz in Nutzung, weiterhin stehen mir aktuell mehrere Maschinen aus unserem PowerKurs zur Verfügung, die für den Übergang genutzt werden können.

Unser “altes” Cluster bestand aus drei Knoten, diese sollten nach der Migration Mitglieder des “neuen” Clusters sein. Da ein “In-Place-Upgrade” bei einem Cluster nicht funktioniert, habe ich parallel zum “alten” Cluster ein “neues” erstellt, Grundlage hierfür waren zwei der PowerKurs-Systeme.

Das Netzwerk in der Theorie

An der Aufteilung der Netze hat sich nichts geändert, hier bleiben wir bei dem Standard, den mein Kollege Carsten schon in seinem Artikel Netzwerkkonfiguration im Hyper-V Cluster definiert hat:

Netzwerke_Cluster

Kleiner Hinweis: In diesem Artikel wird die Einrichtung des Failovercluster ohne die Bildung von Netzwerk-Teams besprochen. Dies wäre durchaus möglich und wird später in einem weiteren Artikel auch besprochen, wir betreiben unser Produktiv-Cluster allerdings aktuell erst einmal ohne Teaming.

Bei den Funktionsweisen der Netze hat sich nichts geändert:

Management-Netz: Dieses Netzwerk ist für die Kommunikation des Cluster-Knoten mit der Domäne zuständig. Auf diesem Interface wird keine VM-Kommunikation betrieben, der Adapter steht exklusiv dem Knoten zur Verfügung.

VM-Netz: Bei diesem Netzwerk ist es genau anders herum, diese Karte wird ausschließlich für die Kommunikation der virtuellen Systeme genutzt. Der Knoten selbst hat keinerlei Bindung auf dieser Karte. Falls mehrere, von einander getrennte Netzwerke benötigt werden, können hier dementsprechend mehr Karten verbaut werden. Dies wäre z.B. bei einem LAN- und einem DMZ-Netz der Fall.

CSV-Netz: Über dieses Netz findet die Cluster-Kommunikation statt, weiterhin wird dieses Netz bei dem umgeleiteten Modus verwendet.

Livemigration-Netz: Über diese Karte wird der RAM-Inhalt der VMs bei einer Livemigration verschoben. Hier ist eine hohe Bandbreite und eine exklusive Karte quasi ein Muss, damit eine Migration nicht den restlichen Netzwerkverkehr des Clusters beeinflusst.

Beide iSCSI-Netze: Über diese beiden Karten wird die Verbindung zum SAN (in unserem Falle eine NetApp) hergestellt. Bei der Anbindung des SAN-Speichers per Fibre Channel entfallen diese beiden Karten, dafür werden FC-Karten benötigt

Die sechs Netzwerke werden wie folgt auf unsere Dual- und Quad-Port-Karte verteilt:

image

Die Grundinstallation

Nach der Grundinstallation der beiden Systeme mit Windows Server 2012 Datacenter wurden beide Systeme mit den aktuellen Updates versorgt, dies waren zu diesem Zeitpunkt “nur” das knapp 170MB große “Windows 8 Client and Windows Server 2012 General Availability Cumulative Update” sowie ein Update der Intel-Netzwerkkarte. Nach dem Update und dem Neustart des Systems beginnt die Einrichtung der Netzwerkkarten.

Das Netzwerk in der Praxis

Bei allen Karten außer dem Management-Interface! müssen grundsätzlich ein paar Einstellungen vorgenommen werden. Da es ausschließlich um Einstellungen unterhalb von Internetprotokoll Version 4 (TCP/IPv4) geht, habe ich die anderen, aktuell uninteressanten Protokolle leicht ausgeblendet:

SNAGHTML2f22acba

  • Registrierung der Verbindung in DNS registrieren muss deaktiviert werden
  • NetBIOS über TCP/IP muss deaktiviert werden

Die weiteren Einstellungen pro Karte werden in den folgenden Screenshots gezeigt. Das Protokoll Microsoft Failover Cluster Virtual Adapter Performance steht vor der Cluster-Installation noch nicht zur Verfügung und kann deshalb ignoriert werden.

Das Management-Interface

image

Die beiden iSCSI-Interfaces

image

Das CSV-Interface

image

Das Livemigration-Interface

image

Das VM-Interface

image

Die Konfiguration der Hyper-V Switch

Damit wir später bei der Validierung des Clusters keine Warnungen oder Fehler bekommen, muss die Hyper-V Switch auf jedem System den gleichen Namen haben. In unserem Fall nennen wir sie “VM”, die Einstellungen sehen wir folgt aus:

image

Die SAN-Anbindung

Im nächsten Schritt installieren wir das Feature Multipfad-E/A. Dieses Feature wird benötigt, damit die unterschiedlichen Wege zu unserem SAN per Netzwerk als ein gemeinsamer Pfad erkannt wird, und nicht pro Weg jeweils ein Laufwerk angezeigt wird. Das Feature kann wie gewohnt über den Server-Manager installiert werden. Nach der Installation befindet sich im Start-Menü (R.I.P.) eine Kachel MPIO, diese ruft die Eigenschaften auf. Im Reiter Multipfade suchen muss die Option Unterstützung für iSCSI-Geräte hinzufügen aktiviert werden.

image

Falls diese Option, wie in meinem Fall, nicht klickbar ist, müssen mindestens zwei iSCSI-Verbindungen aufgebaut werden (wie das geht wird gleich erklärt, evtl. einmal kurz runterspringen und danach mit der Installation fortfahren). Sobald diese Bedingung erfüllt ist kann man die Option auswählen. Nach einem Klick auf Hinzufügen fordert der Server direkt einen Neustart. Nach dem Neustart können Sie die Installation überprüfen, indem Sie erneut MPIO aufrufen und den Reiter Geräte mit MPIO auswählen. Hier muss das Gerät MSFT2005iSCSIBusType_0x9 vorhanden sein.

image

Nun kann die SAN-Anbindung beginnen, hierzu wird der iSCSI-Initiator benötigt. Im Reiter Suche werden die Adressen der SAN-Controller hinzugefügt.

image

Unter Ziele sehen wir nun die erkannten Ziele, der Status zeigt an ob eine Verbindung besteht oder nicht. In meinem Fall sind die beiden Köpfe der NetApp bereits verbunden.

image

Da dies nach der ersten Anbindung nicht der Fall ist wählen wir das erste Ziel an und wählen Verbinden.

image

Die erste Option konfiguriert diese Verbindung so, dass sie nach einem Neustart des Hosts wieder aufgebaut wird. Diese Option muss gesetzt sein, damit der Host nach einem Neustart wieder erfolgreich in unser Cluster aufgenommen wird. Dies zweite Option erlaubt eine Konfiguration des Multipfad, d.h. von diesem einen Server werden mehrere Netzwerkverbindungen zu unserem SAN aufgebaut. Dies wird zum einen aus Gründen der Ausfallsicherheit, zum anderen wegen einer höheren Gesamtbandbreite gemacht. Nach Aktivierung der Funktion und einem Klick auf Erweitert können wir die Initiator-IP und die Zielportal-IP festlegen:

image

Nachdem die Einrichtung von allen Quell-Adaptern zu allen Controllern des SAN durchgeführt wurde, sind wir mit der Einrichtung des iSCSI-Initiators fast fertig. Der letzte Punkt ist die Automatische Konfiguration der verfügbaren Geräte im Reiter Volumes und Geräte.

image

Die Anbindung lässt sich überprüfen, wenn man sich in der Datenträgerverwaltung die vorhandenen Laufwerke anschaut:

image

Falls dies neu angelegt wurden und noch kein Dateisystem besitzen sollten Sie einmal online geschaltet, formatiert (ohne Laufwerksbuchstaben) und wieder offline geschaltet werden. Um den Zugriff aller Hosts zu testen sollte dies auf jedem Knoten gemacht werden (Online und Offline schalten reicht, jedes Mal formatieren ist zeitlich uninteressant).

Der Hardware VSS Provider

Bevor wir mit der Erstellung des Clusters fortfahren, müssen wir den Hardware VSS Provider auf all unseren Hyper-V Hosts installieren. Dieser Treiber sorgt dafür, das hardwareseitig ein Snapshot der Daten erstellt wird, von dem dann die Sicherung abgezogen wird. Dies verkürzt die Zeit des “Umgeleiteten Modus” bzw. “Redirected Modus” bei einer Sicherung ungemein. Das Thema an dieser Stelle ausführlich zu beschreiben würde absolut den Rahmen sprengen, für solch umfassendes Wissen haben wir unseren PowerKurs :) oder unseren Blog:

Hyper-V im Failover-Cluster, Cluster Shared Volumes, das Backup und der Redirected Mode

Bei NetApp-Geräten heißt der Treiber “SnapDrive” und ist aktuell schon unter Windows Server 2012 lauffähig. Die Installation gestaltet sich als recht einfach, danach taucht ein neues Icon im Startmenü auf. Der Aufruf öffnet eine MMC, mit der sich einige Informationen ablesen lassen, weiterhin könnten die angebundenen LUNs bedingt mit dieser Oberfläche administriert werden.

image

Bei HP-Systemen z.B. ist der VSS-Treiber ein wenige MB großes Paket, welches ausschließlich den Treiber installiert. Ob dieser vorhanden ist kann man u.a. erkennen, indem man sich die installierten Programme in der Systemsteuerung anschaut.

 

Die Erstellung des Failovercluster

Kommen wir nun endlich zu dem Punkt, weswegen dieser Artikel überhaupt entstanden ist: Die Installation und Einrichtung unseres Clusters. Als erstes muss über den Server-Manager das Feature Failoverclustering installiert werden. Dies ist ohne Neustart des Hosts möglich, danach kann der Failovercluster-Manager aufgerufen werden. Im rechten Menü wählen wir die Option Cluster erstellen…

image

Es öffnet sich ein Assistent, der uns bei der Erstellung des Clusters behilflich ist.

image

Nach einem Klick auf Weiter müssen wir die Server angeben, die Mitglied des Clusters werden sollen. Wenn alle Systeme aufgenommen wurden, führen wir die Installation mit Weiter fort. Wir können nun den Konfigurationsüberprüfungs-Assistent starten oder die Überprüfung überspringen, zweites ist nicht empfohlen und kann zu einer nicht unterstützten Konfiguration führen, von der man nichts weiß. Die Überprüfung ist auch in Bezug auf die vorherige Arbeit wichtig, falls hier ein Fehler passiert ist und z.B. eine Karte noch auf DHCP steht wird dies in der Zusammenfassung angezeigt und wir haben die Möglichkeit, die Konfiguration anzupassen und den Fehler zu beheben.

Als nächsten geben wir einen Namen und eine IP-Adresse unseres Clusters an. Die IP-Adresse muss sich im Bereich unseres Management-Netzes befinden und muss frei sein. Nach einer Bestätigung der Einstellungen beginnt die Einrichtung des Clusters und quittiert uns dies (hoffentlich) mit einer Erfolgsmeldung. Danach können wir uns mit dem Cluster verbinden.

image

Die Benamung der Netzwerke und manuelle Vergabe der Metriken

Damit wir im Failovercluster-Manager unter Netzwerke eine vernünftige Zuordnung haben, benennen wir die Clusternetzwerke so wie die Karten auch in den einzelnen Hosts heißen. Dazu erweitern wir den Punkt Netzwerke und wählen eines der angezeigten Netzwerke an. In den Eigenschaften nennen wir das Cluster-Netzwerk so wie die Karten der einzelnen Knoten heißt. Das Ergebnis sieht wie folgt aus:

image

Die Eigenschaften der einzelnen Karten muss wie folgt aussehen:

Management

image

iSCSI und iSCSI2

image

CSV

image

Livemigration

image

Um die Metriken der Karten anzuschauen und anzupassen rufen wir uns eine administrative PowerShell auf und nutzen den folgenden Befehl:

Get-ClusterNetwork | ft Name, Metric, AutoMetric

Wann kann erkennen, das alle Karten die AutoMetric aktiviert haben. Die Netzwerke CSV und Livemigration soll aber von uns vergebene Werte bekommen, anpassen können wir die Werte mit den folgenden zwei Befehlen

(Get-ClusterNetwork “CSV”).Metric=100
(Get-ClusterNetwork “Livemigration”).Metric=500

Eine erneute Ausgabe der Metriken sieht nun wie folgt aus:

image

Bei Windows Server 2008 R2 musste die Reihenfolge der Netzwerkkarten in der Systemsteuerung noch angepasst werden, so dass das Interface Management an oberster Stelle steht. Das Interface muss weiterhin an dieser Stelle stehen, dies hat sich unter Windows Server 2012 nicht geändert. Anpassen bzw. überprüfen können wir die Reihenfolge in der Systemsteuerung unter Netzwerk und Internet => Netzwerkverbindungen. Dort im Aktionsmenü (ein Druck auf ALT zeigt dieses an) unter Erweitert => Erweiterte Einstellungen sortieren wir unter Adapter und Bindungen die Karte Management nach ganz oben.

image

image

Diese Einstellung muss auf jedem Clusterknoten überprüft und ggf. umsortiert werden.

Die Erstellung eines freigegebenen Clustervolumes (Cluster Shared Volume)

Um einen gemeinsamen Speicherplatz für unsere VMs zu haben, müssen wir noch unseren freigegebenen Speicher (unser angebundenes LUN) als CSV freigeben. Dies passiert unter Speicher => Datenträger. Dort wählen wir das Laufwerk, welches als Verfügbarer Speicher zur Verfügung steht, aus und wählen die Option Zu freigegebenen Clustervolumes hinzufügen.

image

Im unteren Teil können wir nun erkennen, das dieses Laufwerk unter C:\ClusterStorage\Volume1 zur Verfügung steht.

image

Die Konfiguration des Livemigration-Netzwerks

Dies war bisher noch nötig, und zwar an einer ziemlich komischen Stelle:

Priorisierung_Livemigation1

Diesen “Ort” gibt es nicht mehr, die Konfiguration des Livemigration-Netzwerkes ist nun über die Eigenschaften der Clusternetzwerke erreichbar:

image

In dem folgenden Fenster können dann die Netzwerke sowie deren Priorität konfiguriert werden:

image

Im Taskmanager sieht man, dass bei einer Livemigration die korrekte Karte genutzt wird:

image

Fazit

Die Einrichtung des Clusters unter Windows Server 2012 ist ähnlich komplex wie die Einrichtung von Windows Server 2008 R2, allerdings hat man nach der Einrichtung komplett andere Möglichkeiten. Die neue Oberfläche und der neue Aufbau sind sehr durchdacht, bieten eine Fülle an neuen Möglichkeiten und wirkt alles in allem sehr stabil und nutzbar. VMs können aus oder in ein Cluster repliziert werden, sie können im laufenden Betrieb hochverfügbar gemacht werden usw.

In den kommenden Tagen werden die VMs aus unserem alten Cluster per Export/Import in die neue Welt überführt und nachdem alle VMs übertragen wurden wird das alte Cluster abgeschaltet, die Hosts werden mit Windows Server 2012 neu installiert, wie oben beschrieben eingerichtet und dem Cluster hinzugefügt. Wenn alle drei Hosts aufgenommen wurden (und wir temporär ein Fünf-Knoten-Cluster haben) werden die VMs per Livemigration so verschoben das unsere Powerkurs-Systeme frei sind und aus dem Cluster entfernt werden können.

Eingabe Informationen

Unter: Management

Tags:

Über den Autor: Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitet seitdem bei der Rachfahl IT-Solutions GmbH & Co. KG. Jan Kappen ist unter anderen MCITP Server Administrator, Enterprise Administrator und Enterprise Messaging Administrator 2010 sowie MCTS für System Center Virtual Machine Manager 2008, Windows Server 2008 Active Directory, Windows Server Virtualization und Windows Server 2008 Network Infrastructure.

41 Responses to “Aufbau und Einrichtung eines Failovercluster unter Windows Server 2012”

  1. Jens W. sagt:

    Hallo Herr Kappen,

    ich bin gerade dabei ein Win2012 Cluster mit zwei HP BL465c G7 und einer EVA 4400 einzurichten.
    Bei der Cluster Validation bekomme ich eine Warnung unter dem Punkt “Validate Storage Spaces Persistent Reservation”:

    Successfully issued call to Persistent Reservation REGISTER using Invalid RESERVATION KEY 0xc, SERVICE ACTION RESERVATION KEY 0xd, for Test Disk 0 from node xxx.xxx.com.

    Test Disk 0 does not support SCSI-3 Persistent Reservations commands needed to support clustered Storage Pools. Some storage devices require specific firmware versions or settings to function properly with failover clusters. Please contact your storage administrator or storage vendor to check the configuration of the storage to allow it to function properly with failover clusters.

    Sonst gibt es keine Fehler oder Warnungen.
    Was mich etwas verwundert ist die Tatsache das es hier um Storage Spaces geht, welche ich gar nicht auf den Systemen eingerichtet habe.

    Wissen Sie was es mit diesem Fehler auf sich hat?

    Vielen Dank,
    Jens Wolfert

  2. Jan Kappen sagt:

    Hallo Jens,
    ist die EVA schon seitens HP freigegeben? Dies ist Bedingung, damit der Betrieb einwandfrei funktioniert. Eigentlich müssten es ja nur LUNs sein die angesprochen werden, allerdings kennen wir mittlerweile einige Systeme, die noch keine Unterstützung für Server 2012 haben UND auch nicht korrekt funktionieren.
    Gruß, Jan

  3. [...] unter Windows Server 2012 interessiert, dem kann ich den folgenden Blogartikel empfehlen:-> http://www.hyper-v-server.de/management/aufbau-und-einrichtung-eines-failovercluster-unter-windows-s…Google+ Dieser Beitrag wurde unter Hyper-V / SCVMM, Windows 8 / Server 2012, Windows Server [...]

  4. Christian sagt:

    Gäbe es die Möglichkeit für die Migration eventuell die 2008R2 Server VM’s via Live Storage Migration zu verschieben? Analog zu Vmware Storage VMotion

  5. Jan Kappen sagt:

    Hallo Christian,
    was du wohin verschiebst unter 2012 ist dir überlassen, einmal auf dem Level 2012 lassen sich die VMs komplett oder nur im Hintergrund die Daten verschieben, das ist kein Problem… :)
    Gruß, Jan

  6. ChristianH sagt:

    Hallo Jan, habe gerade deinen Artikel gelesen, sehr gut geschrieben und sehr Aufschlussreich.

    Kannst Du mir bitte sagen ob 1Gbit Netzwerkkarten ausreichend sind für solch einen Cluster bzw die SAN Anbindung oder ob es lieber 10 Gbit Netzwerkkarten sein sollten / müssen?

    Gruß
    ChristianH

  7. Jan Kappen sagt:

    Hallo Christian,
    eine generelle Aussage gibt es hier nicht, es kommt darauf an wie viel Traffic herrscht und was du als Zielgeschwindigkeit haben möchtest. Natürlich gilt bei 1 GBit vs. 10 GBit die Aussage “mehr bringt mehr”, aber ob du sie wirklich brauchst ist eine andere Frage. Wir selbst haben unser Cluster noch auf 1 GBit laufen, bisher gibt es hier keine Engpässe. Trotzdem denke ich würden sich 10 GBit positiv bemerkbar machen :)
    Wenn du eine genaue Aussage brauchst dann müsste eine Messung gemacht werden, die den Bedarf dann aufzeigt.
    Gruß, Jan

  8. Tobias Müller sagt:

    Hallo Herr Kappen,

    zunächst Danke für den aufschlussreichen Artikel. Ich habe gerade einen Failover-Cluster mit 4 Knoten aufgesetzt und es läuft sehr gut. Allerdings stellt sich für mich folgendes Verständnisproblem :

    Wenn ich das Netzwerkkabel von einem VM Interface ziehe, passiert quasi nichts. Auf dem Knoten wird es in der Adapteransicht angezeigt, aber die VM bekommt davon nichts mit. Die Verbindungen (ping) wird aber logischerweise getrennt.

    Kann man irgendwie einstellen, dass bei dem Verlust der VM Netzwerkverbindung ein Failover auf einen anderen Knoten durchgeführt wird?

    Oder kann dies nur durch eine NIC Teaming (Windows 2012 oder NIC Hersteller) realisieren werden?

    Gruß
    Tobias M.

  9. Jan Kappen sagt:

    Hallo,
    Den Verlust des Netzwerks einer VM erkennt das Failover-Cluster nicht. Für eine erhöhte Redundanz sorgt hier ein Team aus zwei oder mehr Karten, die dann über zwei oder mehr Switche mit der Außenwelt kommunizieren. Ich würde einem Team per Windows Server eindeutig einem Team mittels Kartentreiber vorziehen, alleine schon wegen dem Support seitens Microsoft.
    Gruß, Jan

  10. Tobias Müller sagt:

    Hallo Jan,

    Danke für Deine Rückmeldung. Das hatte ich befürchtet, muss ich den Cluster auflösen, um die Änderungen durchzuführen oder kann ich Knoten für Knoten (ggf. vorher offline schalten) ändern und die Fehlermeldungen ignorieren :) … ?

    Gruß, Tobias

  11. Jan Kappen sagt:

    Wenn du den Namen der Switch gleich lässt sollte diese Änderung im Betrieb bei jeweils einem offline genommenen Knoten (d.h. eigentlich dürfen nur keine VM darauf aktiv laufen und die Switch nutzen, offline nehmen brauchst du ihn nicht) funktionieren. Eine Auflösung des Failovercluster ist für diese Aktion auf keinen Fall notwendig.
    Gruß und schönes Wochenende,
    Jan

  12. Tobias Müller sagt:

    Hallo Jan,

    danke für die Tipps, hat alles geklappt.

    Für Alle die vor der gleichen Herausforderung stehen sollten:

    1. VMs runter fahren
    2. Cluster offline nehmen

    - – - auf allen Hyper-V-Server durchführen – - –

    3. virtuelle Switch als privat deklarieren
    4. bei allen benötigten Netzwerkkarten das TCP/IP Protokoll aktivieren (ggf. vorher Kabel trennen)
    5. Netzwerkadapter sauber benamen
    6. NIC Teaming konfigurieren (Lastenausgleich = Hyper-V-Port) und Kabel wieder verbinden
    7. den virtuelle Switch die neuen Adapter zuordnen (Multiplexor)

    8. Cluster wirder online schalten
    9. Clusterprüfung durchführen
    10. VMs wieder starten – fertig

    Besser ist natürlich das genau vorher zu machen :)

    Gruß und schöne Woche
    Tobias

  13. Jan Kappen sagt:

    Vielen Dank für deine Rückmeldung :)
    Gruß, Jan

  14. JoergL sagt:

    Super Beschreibung, aber jetzt bitte noch mal für Core Installationen.
    Da fehlen all die bunten Fenster.
    Besonders bei den Netzwerkeinstellungen, Bindungen, Reihenfolgen, etc…

    ;)

  15. Jan Kappen sagt:

    Wir arbeiten nicht mit der Core-Variante. Als volle Variante installieren und nachträglich den Desktop deinstallieren.

    http://blogs.technet.com/b/server_core/archive/2013/01/28/video-converting-server-with-a-gui-to-minimal-server.aspx

    Gruß, Jan

  16. Florian sagt:

    Hallo Hr. Kappen
    Vielen Dank für diesen Artikel etwas besseres habe ich bis jetzt nicht im Netz gefunden. Die trifft genau meine zur Zeit bestehende Problematik. Ich komme von der vmWare seite her und bin daher noch etwas überfrodert mit der ganzen Microsoft variante der Virtualisierung.

    Der Artikel hilft mir aber enorm bei der bevorstehenden integration.

    Einzig was mich noch interessieren würde ist ob ggf. hier bereits ein artikel zur konfig vom Teaming unter 2012 veröffentlicht wurde. ich habe wohl die kurz anleitung von Tobias Müller oben gesehen aber zur kompletten integration fehlt mir da noch ein bischen Fleisch am Knochen ;)

    Eventuell hat mir hier jemand noch ein Tipp ;)

    Vielen Dank im Vorraus

    Florian

  17. Andreas Fenz sagt:

    Hallo Herr Kappen

    Erstmal ein Lob für die Super Anleitung!

    Ich habe danach einen Failover Cluster mit Hyper-V aufgebaut.
    Zwei Server, ein Storage. Hat alle einwandfrei funktioniert.
    Ich kann auch virtuelle Maschinen erstellen und diese zwischen den beiden Nodes migrieren.
    Jetzt habe ich wohl ein Verständigungsproblem. Wenn ein Node des Clusters ausfällt, dann sollte doch der andere einspringen und die VM’s davon nichts mitbekommen, oder?
    Wenn ich nun einen Server ausschalte, dann schwenken auch die VM’s. Sie werden dann aber auf dem Node2 neu gebootet, als wenn es einen Absturz gab. Man erhält auch in der VM die Meldung, dass der Server unerwartet heruntergefahren wurde.
    Ist dies so richtig????
    Dann wäre aber auch ein Failover Cluster sinnlos.

    Ich hoffe Sie können mir da kurz helfen. Danke

    Gruß
    Andreas Fenz

  18. Jan Kappen sagt:

    Hallo,
    ein Failover Cluster erzeugt eine höhere Verfügbarkeit der VMs, kein Fault Tolerance, d.h. wenn ein Knoten ausfällt, fallen auch die auf diesem Knoten betriebenen VMs aus. Ich sehe ein Failover Cluster absolut nicht als sinnlos an, da die Wahrscheinlichkeit eines kompletten Ausfalls einer Hardware relativ gering ist, weiterhin werden die VMs innerhalb kürzester Zeit auf einem der verbleibenden Knoten erneut gestartet und stehen wieder zur Verfügung, ohne das hier manuell eingegriffen werden muss.
    Gruß, Jan

  19. Michael Roesch sagt:

    Hallo,

    ist es eigtl. möglich, dem Management Netzwerk des Clusters im Nachhinein eine andere NIC zuzuweisen? Hintergrund: bei der Installation von Hyper-V hat der Installer 2 virtuelle Switche angelegt: 1x den Switch aus 3 geteamten NICs und einen weiteren, auf dem die eigentliche Management-Karte hinterlegt ist (es wurde eine NIC erstellt, die vEthernet Virtual Switch heisst). Leider wurde letztere für die Konfiguration des Cluster Management Networks verwendet. Das Problem ist nun, wenn man in der Hyper-V Konfig den Switch entfernt, wird die virtuelle NIC gelöscht und der Cluster geht offline.

    Hat man hier eine Chance, rauszukommen?

    Vielen Dank

    Gruß,
    Michael Roesch

  20. Jan Kappen sagt:

    Hallo Michael,
    hast du, solange die Netze gleich bleiben. Dies bedeutet für dich: Knoten A leer räumen und herunterfahren. Alle Kabel abziehen, so das keine Verbindung mehr zum Netzwerk besteht. Nun die vEthernet-Karte entfernen (entweder “Gemeinsame Nutzung” deaktivieren oder die komplette Switch löschen. Danach sowohl die Switch als auch die Management-Karte wieder erstellen (Vielleicht für die VMs nur Team als 2 NICs und eine weitere für das Management, alternativ mit ConvergedNetwork lösen, dann ist auch das Thema Ausfallsicherheit besser bedient). Wenn alles so ist wie gewünscht den Server wieder herunterfahren, die Karten alle wieder verkabeln und dann starten.
    Nun alles von Knoten B auf A und genau das gleiche Spiel. Wichtig ist: Es dürfen sich keine Subnetze o.ä. ändern, das findet der Cluster überhaupt nicht lustig.
    Gruß, Jan

  21. Michael Roesch sagt:

    Hallo Jan,

    Vielen Dank für Deine Antwort. Leider bin ich nun nicht so sehr tief drin in Hyper-V und habe da noch (vielleicht doofe) Fragen.

    1. Nachdem alle VMs von Knoten A verschoben wurden, soll ich den Knoten A herunterfahren? Wie entferne ich denn dann denn dann die vEthernet-Karte? Oder meintest Du, ich soll das auf dem Knoten B durchführen?

    2. Was meinst Du mit “Danach sowohl die Switch als auch die Management-Karte wieder erstellen”? OK, die Info fehlte in meinem Beitrag. Beide Server haben je in Summe 6 physische NICs, davon sind 3 über Hyper-V geteamt, 1 für CSV Traffic und Heartbeat, eine für Live Migration und die letzte sollte für das Management gedacht sein.

    Vielen Dank

    Gruß,
    Michael

  22. Jan Kappen sagt:

    Hallo Michael,
    herunterfahren, Netzwerk entfernen und dann natürlich wieder starten :) Dadurch sieht sein Partnerknoten allerdings nichts von ihm und du kannst beliebige Konfigurationsänderungen vornehmen, bis du ihn dann letztendlich wieder online schaltest.
    Wie du deine sechs Karten im Cluster verteilst ist ja relativ egal, solange alle logischen Netzwerke nach dem Umbau wieder vorhanden und erreichbar sind. Den von dir beschriebenen Aufbau kannst du so verwenden, wenn die anderen Knoten die gleiche Aufteilung haben (logisch, nicht in der Hardware).
    Gruß, Jan

    P.S. Diese Themen und noch viel mehr besprechen wir in unserem Hyper-V PowerKurs :) http://www.hyper-v-server.de/powerkurs

  23. Michael Roesch sagt:

    Hallo Jan,

    OK, dachte ich mir schon, dass er wieder gestartet werden muss.

    Mein Problem ist nur, dass ich, zumindest im FCM keine Möglichkeit gefunden habe, die Netzwerkkarte zu ändern. Kann ich Deine Aussage dann so verstehen, dass man ohne Verbindung soz. Optionen sieht, die man “Online” nicht sieht?

    Vielen Dank

    Gruß,
    Michael

  24. Jan Kappen sagt:

    Guten Morgen,
    nein, du musst die Netzwerk-Einstellungen entweder in der Systemsteuerung ändern direkt in den Karten selber oder im Hyper-V-Manager (virtuelle Switch anpassen, ändern usw). Gerne können wir auch einen Termin vereinbaren, an dem ich mich per Fernwartung vorab aufschalte und wir uns die Thematik anschauen. Dies wäre dann allerdings kostenpflichtige Dienstleistung.
    Gruß, Jan

  25. Michael Roesch sagt:

    Hello again,

    ja das hatte ich versucht. Ich habe den virtuellen Switch im Hyper-V Manager unter “Manage Virtual Switches” entfernt und dann war auch die NIC weg, die der Hyper-V gebildet hatte und das ClusterNetwork ging dann offline und ich hatte keine Option, da irgendwo im FCM was einzustellen, welche NIC er stattdessen nehmen soll.

    Gruß,
    Michael

  26. Jan Kappen sagt:

    Damit der andere Cluster-Partner nicht merkt, dass sich was ändert => Knoten A offline bearbeiten. Sobald du die virtuelle Switch auflöst, musst du eine andere Karte mit der IP konfigurieren, die vorher die virtuelle NIC hatte. Wenn dann alle Netze wieder da sind => Knoten A wieder online nehmen. Knoten B denkt dann, es hat sich nichts geändert. Wie die Aufteilung passiert, ob du 1 GBit oder 10 GBit oder Teaming oder was auch immer nutzt ist relativ egal, das Cluster achtet eigentlich nur auf die logischen Netzwerke. Solange diese identisch sind ist für ihn alles gut. In Kürze kommt ein Artikel von mir in dem ich beschreibe, wie ich unser Cluster von 6x 1GBit auf 2x 10GBit umstelle und mit vNICs arbeite. Hier wird auch angesprochen, dass sich die Hardware ruhig ändern kann, solange die logischen Netzwerke nach der Änderung gleich sind.
    Gruß, Jan

  27. Michael Roesch sagt:

    Hallo Jan,

    die physische NIC, die quasi den virtuellen Switch gebildet hat, ist nach der Änderung noch da und hat auch die IP des vSwitch bekommen, heisst natürlich aber anders (NIC1 in meinem Fall). Nur scheint sich der Hyper-V am Namen der Karte zu stören bzw. er mag es nicht, dass eine Netzwerkkarte mit dem Namen vSwitch… nicht mehr vorhanden ist, kann das sein? Es scheint mir so zu sein, dass die Karte dann von der Bezeichnung her wieder genauso heissen muss, wie der Switch vorher hiess.

    Und das muss sich doch irgendwo ändern lassen können oder?

    Ich könnte natürlich versuchen, die Netzwerkkarte dann auch vSwitch zu nennen, aber das ist ja unschön.

    Gruß,
    Michael

  28. Michael Roesch sagt:

    Hallo Jan,

    habe ich bzgl. meines letzten Posts einen Denkfehler? Oder habe ich mehr Optionen, wenn der Server offline ohne Netzwerkkabel dasteht?

    Gruß,
    Michael

  29. Jan Kappen sagt:

    Hallo Michael,
    alle benötigten Informationen habe ich bereits in den vorherigen Antworten aufgeführt, ich kann mich sonst leider nur wiederholen. Schau dir bitte einmal die Funktionsweise der virtuellen Switche an, diese zu verstehen in Voraussetzung für die von dir gewünschten Änderungen. Alternativ können wir uns dies gern gemeinsam anschauen, meld dich dazu bitte per Mail oder telefonisch bei mir.
    Gruß, Jan

  30. Michael Roesch sagt:

    Hallo Jan,

    ok, vielleicht lässt sich die Verwirrung telefonisch eher klären. Wo müsste ich dann anrufen?

    Gruß,
    Michael

  31. Jan Kappen sagt:

    Hier im Büro unter 02984-92920
    Gruß, Jan

  32. Klaus Keull sagt:

    Guten Tag,
    Zunächst möchte ich ein Lob loswerden für die guten Artikel, Beschreibungen und Hilfen auf diesen Seiten. Ganz toll.

    Wir haben ein 5-Knoten-Cluster mit Anbindung an ein CSV auf einer NetApp-LUN über redundante Cisco-Switche. Die Hosts basieren auf W2008R2.
    Nun möchten wir die Hosts auf W2012R2 umstellen.

    Können wir das unter Verwendung des selben Clusters und der selben CSV-Anbindung machen, indem wir einen Knoten aus dem Cluster entferne, BS neu installieren (kein Upgrade, sondern Neuinstallation) und dann diesen neuen Knoten wieder in das Cluster heben?

    Vielen Dank im Voraus

    - Klaus -

  33. Hi Klaus,

    nein du kannst keine Windows Server 2012 und Windows Server 2012 R2 Hosts in einem Cluster mischen. Der Weg ist es einen neue LUN anzulegen und dann mit dem Cluster Migration Wizard zu arbeiten.

    Gruß Carsten

  34. Klaus Keull sagt:

    Hallo Carsten, ich danke für die rasche Antwort.

    Gruß – Klaus -

  35. Lucky sagt:

    Hallo,

    gibt es die Möglichkeit den Cluster auf einem Web Interface dazustellen?

    Eine Übersich, welche Knoten ON sind, vielleicht deren Auslastung.
    Den Zustand der VMs wäre auch interessant.

    Gruss Lucky

  36. Hi Lucky,

    nein es gibt kein Webinterface aber du kannst alles programmatisch oder per PowerShell abfragen.

    Gruß Carsten

  37. Lucky sagt:

    Habe etwas gefunden.
    Bis zu 6 Sokets ist es sogar kostenlos:

    http://www.veeam.com/de/virtual-server-management-one-free.html

  38. alexa sagt:

    Hallo

    Ist es Absicht, dass in der ersten Grafik Grafik Management-Netz und VM-Netz denselben IP-Bereich haben, aber darunter steht “Management-Netz: Dieses Netzwerk ist für die Kommunikation des Cluster-Knoten mit der Domäne zuständig. Auf diesem Interface wird keine VM-Kommunikation betrieben, der Adapter steht exklusiv dem Knoten zur Verfügung. VM-Netz: Bei diesem Netzwerk ist es genau anders herum,”

    Das widerspricht sich doch, oder?

    A.B.

  39. Klaus Keull sagt:

    Diese Frage bezieht sich auf meinen Eintrag vom 23.11.2013 – 14:19:

    Wir haben ein 5-Knoten-Cluster mit Anbindung an ein CSV auf einer NetApp-LUN über redundante Cisco-Switche. Die Hosts basieren auf W2008R2.
    Nun möchten wir die Hosts auf W2012R2 umstellen.

    Es gibt unterschiedliche Aussagen über die Ausgestaltung von Failoverclustern:

    Hyper-V-Hosts mit je einem CSV je Host
    Hyper-V-Hosts mit nur einem gemeinsamen CSV

    Was ist besser?

  40. Joachim sagt:

    Hallo, ich war auf dem Powerkurs und habe noch eine Lizenzfrage zum Hyper-V-Cluster:

    Ist es richtig, dass alle Mitglieder eines Cluster die gleiche Lizenzform besitzen müssen?
    Beispiel: Cluster aus 3 X WinServ2012. Zwei davon sind Standard und einer Datacenter. Geht das oder nicht?

    Gruß

    Joachim

  41. Daniel sagt:

    Hallo Jan

    Danke für die Anleitung. Ich hätte da eine Frage zu SMB3 da das Browsen zum SMB3 Share bis zu 30 Sekunden dauert. Ist der Share einmal da geht es schnell. Das gleich bei der Livemigration beim ersten mal schlägt diese Fehl und beim zweiten mal geht es schnell. Also ob der Weg erstmal zum SMB3 Share gesucht wird. Leider war der Kurs am Freitag bei Euch Früher zu ende somit konnte ich die Fragen nicht mehr stellen. :-(

    Ich habe folgende Umgebung:

    10.10.10.0 -> VLAN10-> Server Netzwerk (DNS, ADS usw) –> wird geroutet
    10.10.20.0 -> VLAN20 -> Hyper-V Management Netzwerk –> wird geroute
    10.10.30.0 -> VLAN30 -> LiveMigration –> nicht geroute
    10.10.40.0 -> VLAN40 -> SMB3 –> nicht geroutet

    SMB3 Fileserver hat sein Management im VLAN20 und sein DatenAdapter im VLAN40.

    Bei der IP Konfiguration hat nur das HyperV Management Adapter(DNS, GW usw..) eingetragen. Bei allen anderen ist nur IP und NetzwerkMaske eingetragen.

    1.) Meine frage ist nun muss auch das SMB3 Adapter GW, DNS Einträge haben?
    2.)Muss auch das SMB3 Adapter zugriff auf die DC , DNS haben oder bekommt es diese über das Management Adapter?
    3.) Wie wäre die Metric zusetzten?

    Danke Gruß
    Daniel

Antworten