Rolling Cluster Upgrade zur Migration eines Failover Cluster von Windows Server 2012 R2 zu Windows Server 2016

Rolling Cluster Upgrade

Setzt man ein Failover Cluster ein, welches auf eine neue Version geupdatet werden soll, musste dies bisher immer durch ein neues Failover Cluster mit einem neuen Namen, neuen IP-Adressen usw. gemacht werden. Dies war nicht sehr flexibel, häufig waren die IP-Adressen nicht verfügbar oder der neue Namen hat viele gestört. Seit dem Windows Server 2016 kann ein Failover Cluster nun geupdatet werden, ohne das neue Namen oder Adressen benötigt werden. Diese Art von Update ist aktuell unterstützt für ein Hyper-V und ein Scale-Out File Server Cluster, nicht für andere Aufbauten. Die neue Funktion nennt sich Rolling Cluster Upgrade und ermöglicht das erste Mal die Aufnahme von unterschiedlichen Betriebssystem-Versionen in einem Cluster (Und um Missverständnisse vorzubeugen, es geht “nur” mit Windows Server 2012 R2 und Windows Server 2016, nicht mit älteren Versionen). Mit diesem Beitrag möchte ich einmal die Durchführung von solch einem Upgrade zeigen.

Die Umgebung

Der Aufbau, der in diesem Beitrag genutzt wird, wird auch für unsere Hyper-V Schulung genutzt. Hier haben Sie die Möglichkeit, fünf Tage intensiv die Themen Hyper-V, SMB3 Storage, Failover Clustering und weitere relevante Themen zu lernen.

Bei dem Failover Cluster handelt es sich um einen Scale-Out File Server, der aus zwei Knoten besteht. Beide Server haben aktuell ein Windows Server 2012 R2 installiert, der Failover Cluster betreibt eine Rolle, unseren hochverfügbaren Datei-Server.

image

image

Innerhalb des Failover Cluster gibt es fünf Datenträger, die alle basierend auf dem gleichen Pool angelegt wurden.

image

Beginn der Migration

Wir beginnen das Upgrade mit der Aktivierung des Wartungsmodus auf einem der beiden Server. Ich beginne mit Knoten A mit dem Namen FSNode1.

image

Nach der erfolgreichen Aktivierung ist der Knoten Angehalten und betreibt keine Rollen oder Funktionen mehr.

image

Nun kann der Knoten aus dem Failover Cluster entfernt werden. Zu diesem Zeitpunkt läuft der Betrieb komplett auf Knoten B mit dem Namen FSNode2.

image

image

Nach dem Entfernen ist nur noch FSNode2 sichtbar, weiterhin meldet der Failover Cluster den Vorgang mit einer Warnmeldung:

image

image

Nun muss FSNode1 mit Windows Server 2016 neu installiert werden. Bei diesem Vorgang kann bei Produktiv-Systemen direkt ein Update der Firmware gemacht werden, falls diese nicht aktuell ist. Nach Abschluss der Grundinstallation ist das System wieder erreichbar, allerdings mit einem neuen Betriebssystem. Der Name ist der gleiche wie vorher, zusätzlich habe ich den Server bereits der Domäne powerkurs.local hinzugefügt.

image

Nun muss das System wieder so eingerichtet werden, dass es ein vollwertiges Mitglied es Failover Cluster werden kann. Das bedeutet, dass alle benötigten Rollen und Funktionen wieder installiert und konfiguriert werden müssen. In meinem Fall muss die Dateiserver-Rolle inkl. Unterrollen wieder aktiviert werden, weiterhin muss das Failover Cluster- und das MPIO-Feature installiert und aktiviert werden.

Der Mixed Mode

Sobald das erste System vollständig eingerichtet ist, kann es wieder in das bestehende Failover Cluster aufgenommen werden. Dazu öffne ich auf dem FSNode1 den Failover Cluster Manager und stelle eine Verbindung mit meinem Cluster her.

image

Nun kann ich den ersten Knoten wieder in das Failover Cluster aufnehmen.

image

image

image

An dieser Stelle fällt mit der Technical Preview 5 auf, dass keinerlei Abfrage erscheint, ob man den neuen Knoten gegen die vorhandenen Knoten testen möchte. Dies sollte in einer Produktiv-Umgebung auf jeden Fall gemacht werden, um mögliche Fehler (sei es durch Unaufmerksamkeit oder durch technische Abhängigkeiten) zu finden.

image

image

Nun ist der Knoten wieder Mitglied des Clusters, zusätzlich erscheinen mehrere Warnmeldungen in den Cluster Events.

image

image

In diesem Moment beginnt der Betrieb im gemischten Modus bzw. im Mixed Mode. Dieser Zustand ist erst einmal kein Problem, allerdings sollte er nicht länger als (maximal!) ein Monat bestehen bleiben. Wenn Sie mit der Migration starten, achten Sie darauf, dass Sie stetig alle Server nach und nach umziehen bzw. migrieren und danach die Migration abschließen. Wie dies geht, zeige ich im weiteren Verlauf.

Der zweite Server

Nachdem der erste Server nun wieder Mitglied des Failover Cluster ist, kann der zweite Server ebenfalls in den Wartungsmodus geschickt werden. Bei Aktivierung der Wartung werden alle Ressourcen automatisch auf den ersten Server verschoben.

image

image

Gibt es nach der Aktivierung keine weiteren Probleme, kann der zweite Server ebenfalls aus dem Cluster entfernt werden und die Neuinstallation kann beginnen.

image

image

Nachdem das System wieder installiert ist und nun  mit Windows Server 2016 läuft, kann es wieder in das bestehende Failover Cluster aufgenommen werden.

image

Bei der Aufnahme von dem zweiten Server kommt nun eine Warnmeldung mit der Nachfrage, ob eine Überprüfung gemacht werden soll.

image

Diese sollte ebenfalls gemacht werden, gibt es keine Warn- oder Fehlermeldungen, kann der zweite Server aufgenommen werden.

image

Ist der Server wieder verfügbar, können die Ressourcen im Failover Cluster wieder auf beide Systeme aufgeteilt werden.

image

Abschluss der Migration

Sind nun alle Knoten durchgetauscht worden, kann als finaler Schritt das Cluster-Level angehoben werden. Ähnlich wie bei einer Active Directory gibt es ein Cluster-Level, welches den Stand der Betriebssysteme definiert. Ohne eine Anpassung sieht das Level wie folgt aus:

image

Erhöht werden kann es mit dem Befehl

Update-ClusterFunctionalLevel –Cluster <Name>

Diese Funktion lässt sich nicht wieder rückgängig machen, danach kann das Failover Cluster nur aus Systemen mit Windows Server 2016 bestehen.

image

Nach der erfolgreichen Aktualisierung hat sich das Level auf den Wert 9 erhöht.

image

Damit ist die Migration abgeschlossen. Beide Hosts laufen nun mit Windows Server 2016, alle Rollen waren während der Migration konstant verfügbar. Natürlich kann die Hardware auch während der Migration getauscht werden und die Systeme können zusätzlich aufgenommen werden. Wichtig ist nur, dass alle Cluster-Knoten zu jedem Zeitpunkt einen Zugriff auf die gemeinsamen Ressourcen haben.

Wenn Sie Unterstützung bei der Migration benötigen oder wir diese Arbeit für Sie übernehmen sollen, rufen Sie uns an. Wir stehen Ihnen gerne mit Rat und Tat zur Seite.

Jan Kappen
 

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. Im April 2015 wurde Jan Kappen im Bereich "File System Storage" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

Click Here to Leave a Comment Below 0 comments