Die Einrichtung und Nutzung des Clusterfähigen Aktualisieren (CAU) (1. Update)
In diesem Beitrag möchte ich Ihnen zeigen, wie Sie Ihr Cluster unter Windows Server 2012 mit Hilfe des Clusterfähigen Aktualisieren (im englischen Cluster Aware Updating, CAU abgekürzt) auf den aktuellen Patchlevel bringen. Vielleicht ist Ihnen auf einem der Cluster-Knoten nach der Installation des Failover Cluster schon aufgefallen, dass eine neue Kachel zur Verfügung steht. Grundsätzlich arbeitet das CAU wie folgt:
Innerhalb Ihres Failover Cluster wird eine neue Rolle hinzugefügt, die für den gesamten Update-Vorgang verantwortlich ist. Diese Rolle ist innerhalb Ihrer Active Directory als Computer-Objekt sichtbar und kümmert sich neben dem eigentlichen Patch-Vorgang auch darum, dass die einzelnen Knoten in den Wartungsmodus versetzt werden, das ein Neustart nach dem Patch-Vorgang durchgeführt, das die Rollen wieder auf den ursprünglichen Besitzer verschoben werden usw. Dieser Vorgang kann entweder manuell angestoßen werden oder Sie konfigurieren eine automatische Installation mit einem Zeitplan, an dem die Wartung durchgeführt wird.
Wir könnten nun direkt mit der Einrichtung beginnen, in diesem Fall würde allerdings ein automatisch erzeugtes Objekt in Ihrer AD auftauchen und Sie hätten keine Möglichkeit, dieses Objekt zu benamen. Daher legen wir im ersten Schritt ein neues Objekt mit einem von uns gewünschten Namen an, damit wir später auch wissen, um was es sich handelt. Ich benenne das Objekt so wie auch das Cluster heißt und füge ein “-CAU” dahinter
Als nächstes müssen wir auf den Hyper-V Hosts eine Firewall-Regel aktivieren, damit die Systeme remote heruntergefahren werden können. Ich könnte dies nun bei unseren beiden Knoten manuell einstellen, würde dann allerdings bei einem potentiellen dritten Knoten dies irgendwann vergessen und nach dem ersten fehlgeschlagenen Update-Vorgang merken und aktivieren (wir lernen ja aus den Fehlern, die wir mal gemacht haben ;)). Aus diesem Grund erstelle ich eine neue Gruppenrichtlinie, die für alle Hyper-V Hosts im Cluster greift und in der die betreffende Regel konfiguriert wird. Dies geschieht ebenfalls auf einem der Domänencontroller
Diese Gruppenrichtlinie verknüpfen wir nun mit der OU, in der sich unsere Cluster-Knoten befinden
Nachdem dies geschehen ist und die Systeme die neue Gruppenrichtlinie erfolgreich angewandt haben können wir in der lokalen Firewall sehen, dass die Einstellungen angewandt worden sind
Da wir nun mit den Vorbereitungen fertig sind können wir uns nun der eigentlichen Einrichtung widmen. Hierzu rufen wir auf einem der Clusterknoten das “Clusterfähige Aktualisieren” auf. Es erscheint das folgende Fenster
Im ersten Schritt müssen wir im oberen Bereich eine Verbindung mit unserem Cluster aufbauen. Hierzu öffnen wir über das Dropdown-Menü die Liste der verfügbaren Cluster und wählen das Cluster auf dem lokalen System aus. Nachdem wir “Verbinden” gewählt haben, haben wir eine Verbindung aufgebaut. Das Fenster sieht dann wie folgt aus
Wir können nun die Option “Vorbereitung auf das Clusterupdate analysieren” nutzen, um uns einen Stand über die aktuellen Anforderungen und Bedingungen zu machen
Hier sehen wir, dass die CAU-Clusterrolle im Cluster aktiviert werden muss. Dies kann entweder per GUI oder per PowerShell geschehen. Ich zeige hier erst die Einrichtung per GUI, diese erzeugt uns das gewünschte PowerShell-Skript, welches ich dann im Anschluss hier bereitstelle.
Über die Option “Selbstaktualisierungsoptionen des Clusters konfigurieren” öffnet sich ein Assistent, der die benötigten Informationen abfragt
Im nächsten Fenster müssen beide Optionen angewählt werden, zusätzlich muss der Name des vorab erstellten AD-Objekts eingetragen werden
Nun muss das Datum und die Frequenz der Ausführung gewählt werden
Nun können noch diverse Optionen eingestellt werden, die den Update-Vorgang beeinflussen. Eine ziemlich sinnvolle Option ist “RequireAllNodesOnline”, hierdurch ist gewährleistet das die komplette Kapazität der Server zur Verfügung steht während dem Patchen (immer im Hinterkopf behalten, das immer ein Knoten temporär nicht vorhanden ist, da dieser nach der Installation durchgebootet wird). Wenn gewünscht könnte auch eine Reihenfolge der Knoten festgelegt werden, vorher und nachher ein Skript ausgeführt werden usw.
Im Feld “Bestätigung” sehen Sie dann, welches PowerShell-Skript ausgeführt wird
Wenn nun alles funktioniert wurde der Befehl erfolgreich abgesetzt, in meinem Fall habe ich allerdings einen ziemlich blöden Fehler bekommen
Gefunden habe ich bei einer Suche die folgende TechNet-Seite, die (wie der Assistent auch) in Richtung Rechte-Problem tendiert: Event ID 1194 — Active Directory Permissions for Cluster Accounts
Ich habe in meinem Fall die Rechte des vorab erstellten AD-Objekts angepasst und dem Cluster-Objekt volle Rechte auf dieses Konto gegeben.
Damit ich nicht jedes Mal die GUI durchlaufen lassen muss, habe ich den Befehl in eine PowerShell kopiert und ausgeführt. Ohne die Anpassungen erschien ebenfalls eine ziemlich lange und ziemlich rote Fehlermeldung, im unteren Teil kann man aber erkennen, dass die Installation nach Anpassung der AD-Rechte funktioniert hat
Wenn ich nun erneut den Vorbereitungs-Assistent aufrufe, erhalte ich mehr Abfragen als beim ersten Mal und auch mehr erfolgreich geprüfte Ergebnisse
Das war die Einrichtung der CAU-Rolle, ab nun werden automatisch die Updates installiert. Jetzt kommt wahrscheinlich der Moment, an dem sich die meisten fragen werden, wie oder wodurch ich das Installationsverhalten steuern kann.
Die Installation der Updates wurde mit Installation der CAU-Rolle automatisiert. Welche Updates installiert werden hängt davon ab, welche Updates für das System freigegeben wurden. Falls das Cluster komplett ohne Management “einfach” die Windows Updates eingeschaltet hat, wird bei Ausführung des Updates durch die CAU-Rolle alles installiert, was verfügbar ist. In unserem Fall steht hinter den Windows-Systemen ein WSUS-System, welches für die Installation der Updates verantwortlich ist. Gebe ich als Administrator keine Updates im WSUS frei, kann und wird das CAU auch keine Updates installieren. Gebe ich die Updates frei (oder stelle die Clusterknoten in den “installiere alle Updates”-Bereich) werden monatlich die Updates installiert.
Eine manuelle Installation der Updates per CAU ist natürlich ebenfalls möglich, hierzu muss ich in der GUI den Punkt “Vorschau der Updates für dieses Cluster anzeigen” auswählen
Nach einem Klick auf “Updatevorschauliste generieren” sucht das System für alle Knoten nach Updates und listet diese danach auf
Nun kann ich (wenn ich zufrieden mit der Auswahl bin) zurück im Hauptfenster die Option “Updates auf diesen Cluster anwenden” wählen, alternativ kann der Update-Vorgang an dieser Stelle abgebrochen bzw. erst gar nicht gestartet werden. Vor der Installation öffnet sich ein kleiner Assistent
Im Hauptfenster können wir nun den Fortschritt des Update-Vorgangs beobachten
Sobald der Download der Updates abgeschlossen ist, beginnt die Installation. Hierzu wird der aktuell aktive Knoten in den Wartungsmodus versetzt, dies erzwingt eine Migration der VMs zu dem anderen Knoten. In der GUI bzw. dem Failovercluster-Manager sieht der Vorgang wie folgt aus
Nach dem Update wird der Knoten durchgebootet, auf weitere Updates geprüft und der Patchvorgang wird auf dem zweiten Knoten fortgesetzt.
Update 12.08.2013: Falls Sie in Ihrer Umgebung einen Proxy nutzen, um in Richtung Internet eine Verbindung aufzubauen, müssen Sie diesen konfigurieren. CAU greift nicht auf den Internetoptionen-Proxy zurück, sondern auf den systemweiten. Dieser kann per netsh gesetzt werden, der Befehl hierzu ist der folgende
netsh winhttp set proxy proxy_server_name_oder_ip:port “*.domäne.local, <local>”
proxy_server_name_oder_ip mus ersetzt werden durch den Namen oder die IP es Proxy-Servers, danach wird mit einem Doppelpunkt der Port angegeben, auf den der Proxy-Dienst horcht. Danach müssen in Anführungszeichen die Ausnahmen eingetragen werden. Hier muss die genutzte Domäne eingetragen, da es sonst bei der Replikation Probleme gibt, da diese teilweise Port 80 nutzt und dann auf den Proxy anspringt. Neben der Domäne wird noch “>local>” aufgenommen, dies nimmt alle lokalen Systeme heraus.
Diese Einstellung könnte auch per Gruppenrichtlinie auf den Systemen eingetragen werden:
