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.
Innerhalb des Failover Cluster gibt es fünf Datenträger, die alle basierend auf dem gleichen Pool angelegt wurden.
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.
Nach der erfolgreichen Aktivierung ist der Knoten Angehalten und betreibt keine Rollen oder Funktionen mehr.
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.
Nach dem Entfernen ist nur noch FSNode2 sichtbar, weiterhin meldet der Failover Cluster den Vorgang mit einer Warnmeldung:
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.
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.
Nun kann ich den ersten Knoten wieder in das Failover Cluster aufnehmen.
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.
Nun ist der Knoten wieder Mitglied des Clusters, zusätzlich erscheinen mehrere Warnmeldungen in den Cluster Events.
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.
Gibt es nach der Aktivierung keine weiteren Probleme, kann der zweite Server ebenfalls aus dem Cluster entfernt werden und die Neuinstallation kann beginnen.
Nachdem das System wieder installiert ist und nun mit Windows Server 2016 läuft, kann es wieder in das bestehende Failover Cluster aufgenommen werden.
Bei der Aufnahme von dem zweiten Server kommt nun eine Warnmeldung mit der Nachfrage, ob eine Überprüfung gemacht werden soll.
Diese sollte ebenfalls gemacht werden, gibt es keine Warn- oder Fehlermeldungen, kann der zweite Server aufgenommen werden.
Ist der Server wieder verfügbar, können die Ressourcen im Failover Cluster wieder auf beide Systeme aufgeteilt werden.
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:
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.
Nach der erfolgreichen Aktualisierung hat sich das Level auf den Wert 9 erhöht.
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.
