Die Einrichtung und Nutzung des Clusterfähigen Aktualisieren (CAU) (1. Update) - Hyper-V Server Blog

Die Einrichtung und Nutzung des Clusterfähigen Aktualisieren (CAU) (1. Update)

WinServ2012-ClusterIn 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

image

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

image

image

image

Diese Gruppenrichtlinie verknüpfen wir nun mit der OU, in der sich unsere Cluster-Knoten befinden

image

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

image

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

image

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

image

Wir können nun die Option “Vorbereitung auf das Clusterupdate analysieren” nutzen, um uns einen Stand über die aktuellen Anforderungen und Bedingungen zu machen

image

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

image

Im nächsten Fenster müssen beide Optionen angewählt werden, zusätzlich muss der Name des vorab erstellten AD-Objekts eingetragen werden

image

Nun muss das Datum und die Frequenz der Ausführung gewählt werden

image

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.

image

image

Im Feld “Bestätigung” sehen Sie dann, welches PowerShell-Skript ausgeführt wird

image

Wenn nun alles funktioniert wurde der Befehl erfolgreich abgesetzt, in meinem Fall habe ich allerdings einen ziemlich blöden Fehler bekommen

image

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.

image

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

image

Wenn ich nun erneut den Vorbereitungs-Assistent aufrufe, erhalte ich mehr Abfragen als beim ersten Mal und auch mehr erfolgreich geprüfte Ergebnisse

image

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

image

Nach einem Klick auf “Updatevorschauliste generieren” sucht das System für alle Knoten nach Updates und listet diese danach auf

image

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

image

image

image

Im Hauptfenster können wir nun den Fortschritt des Update-Vorgangs beobachten

image

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

SNAGHTML3dcec46b

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:

image

Jan Kappen
 

Jan Kappen ist ausgebildeter Fachinformatiker in der Richtung Systemintegration. Er hat seine Ausbildung im Sommer 2008 abgeschlossen und arbeitete bis August 2018 bei der Rachfahl IT-Solutions GmbH & Co. KG. Seit September 2018 arbeitet er als Senior Netzwerk- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland. 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. Seit 2015 wird Jan Kappen im Bereich "File System Storage" bzw. "Cloud & Datacenter Management" für seine Expertise und seine Community-Arbeit mit dem MVP Award von Microsoft ausgezeichnet.

  • Stefan sagt:

    Hallo,
    vielen Dank für diesen interessanten Artikel. Ich hätte noch eine Frage zur Anbindung an einen bestehenden WSUS. Wir haben dort Deadlines definiert. Diese Deadline wird manuell nach jedem Patchday (Sonntag Nacht nach dem zweiten Dienstag im Monat) festgelegt. Wird der Zeitplan des CAU durch diese WSUS Deadline beeinflusst? Oder müsste dann jeweils ein manueller Zeitplan im CAU angelegt werden.

    Vielen Dank!
    Stefan

  • Flo sagt:

    Hallo und danke für den tollen Artikel.

    Bei mir klappt es leider nicht in einer frischen 2012 R2 Umgebung mit 3 Nodes.

    Wenn ich das Update starte kommt leider nur nach einiger Zeit folgende Meldung:

    The update run has been triggered, but it has not yet started and might take a long time or might fail….

    Get-CauRun zeigt auch nichts an…

    Grüße, Flo.

  • Maik Müller sagt:

    Hallo Herr Kappen,

    ich habe versucht mit Ihrer Anleitung „Cluster Aware Updates“ zu konfigurieren. Wenn ich den Assistent zur Prüfung durchlaufen lasse bekomme ich bei dem Punkt „In jedem Knoten im Failovercluster sollte eine Firewallregel aktiviert sein, die das Remoteherunterfahren zulässt“. Gleichzeitig erhalte ich noch den Hinweis „Hostname“ (internal error). Die Meldung bezieht sich nur auf den Knoten auf dem ich die Überprüfung vornehme. Andere Knoten des Clusters tauchen in dieser Meldung nicht auf. Abgesehen davon, dass ich eine Firewallregel per Gruppenrichtlinie definiert habe, kommt diese Meldung auch wenn ich die Firewall komplett deaktiviert habe. Ich habe den Eindruck, dass sich diese Fehlermeldung nicht auf die Firewall bezieht.

    Haben Sie hierzu vielleicht eine Idee? Die Windows-Protokolle bringen keinen brauchbaren Hinweis.

    Vielen Dank und viele Grüße

    Maik Müller

  • >