Aufbau und Einrichtung eines Failovercluster unter Windows Server 2012
Der Windows Server 2012 ist raus, unser aktuelles Cluster unter Windows Server 2008 R2 SP1 sollte daher 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 auch 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:
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 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, voneinander 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:
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 einige 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:
- 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
Die beiden iSCSI-Interfaces
Das CSV-Interface
Das Livemigration-Interface
Das VM-Interface
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:
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 werden 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.
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.
Nun kann die SAN-Anbindung beginnen, hierzu wird der iSCSI-Initiator benötigt. Im Reiter Suche werden die Adressen der SAN-Controller hinzugefügt.
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.
Da dies nach der ersten Anbindung nicht der Fall ist, wählen wir das erste Ziel an und wählen Verbinden.
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. Diese 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:
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.
Die Anbindung lässt sich überprüfen, wenn man sich in der Datenträgerverwaltung die vorhandenen Laufwerke anschaut:
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/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 recht einfach, danach taucht ein neues Icon im Startmenü auf. Dessen Aufruf öffnet eine MMC, mit der sich einige Informationen ablesen lassen, weiterhin könnten die angebundenen LUNs bedingt mit dieser Oberfläche administriert werden.
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…
Es öffnet sich ein Assistent, der uns bei der Erstellung des Clusters behilflich ist.
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 allerdings 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 irgendwo ein Fehler passiert sein sollte. Steht z.B. eine Karte noch auf DHCP, wird dies in der Zusammenfassung angezeigt. So haben wir noch die Möglichkeit, die Konfiguration anzupassen und den Fehler zu beheben.
Als Nächstes geben wir einen Namen und eine IP-Adresse für unser Cluster an. Die IP-Adresse muss sich im Bereich unseres Management-Netzes befinden und frei sein. Nach 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.
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 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:
Die Eigenschaften der einzelnen Karten müssen wie folgt aussehen:
Management
iSCSI und iSCSI2
CSV
Livemigration
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
Man kann erkennen, dass alle Karten die AutoMetric aktiviert haben. Die Netzwerke CSV und Livemigration sollen 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:
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 auch 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.
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 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.
Im unteren Teil können wir nun erkennen, das dieses Laufwerk unter C:\ClusterStorage\Volume1 zur Verfügung steht.
Die Konfiguration des Livemigration-Netzwerks
Dies war bisher noch nötig, und zwar an einer ziemlich komischen Stelle:
Diesen “Ort” gibt es nicht mehr, die Konfiguration des Livemigration-Netzwerkes ist nun über die Eigenschaften der Clusternetzwerke erreichbar:
Im folgenden Fenster können dann die Netzwerke sowie deren Priorität konfiguriert werden:
Im Taskmanager ist zu sehen, dass bei einer Livemigration die korrekte Karte genutzt wird:
Fazit
Die Einrichtung des Clusters unter Windows Server 2012 ist ähnlich komplex wie die Einrichtung von Windows Server 2008 R2; nach der Einrichtung eröffnen sich jedoch komplett andere Möglichkeiten. Die neue Oberfläche und der neue Aufbau sind m.E. 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 sind (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.
