Die LooksAlive und IsAlive Checks im Cluster

Wie überprüft der Cluster Service die Verfügbarkeit einzelner Ressourcen?

Um zu überprüfen, ob Cluster Ressourcen noch verfügbar sind gibt es im allgemeinen zwei Checks, die der Clusterdienst periodisch ausführt: Den LooksAlive check und den IsAlive check.
Der LooksAlive check ist eine einfache Überprüfung, ob eine Ressource ansprechbar ist. Der IsAlive check geht -je nach Ressourcentyp- darüber hinaus.

Die LooksAlive und IsAlive checks fallen je nach Ressourcentyp unterschiedlich aus, hier anhand des Beispiels einer Cluster Print Spooler Ressource:

LooksAlive
Der Windows Service Control Monitor (SCM) wird abgefragt, ob der Spooler Dienst läuft

IsAlive
Ein API Call auf das Printer Subsystem (localspl.dll) wird abgesetzt

Der LooksAlive-/IsAlive check einer Ressource ist also stark davon abhängig, welche Funktion eine Ressource inne hat. Folgender KB Artikel gibt einem eine gute Übersicht wie die üblichen Cluster Standardressourcen überprüft werden:

» Behavior of the LooksAlive and IsAlive functions… (KB 914458)

Im Falle einer Physical Disk Ressource prüft der Clusdisk.sys Clusterdienst zusätzlich alle 3 Sekunden mittels eines SCSI Reserve Kommandos, ob die LUN noch verfügbar ist. Weiterhin wird eine Lese-/Schreiboperation auf den sog. „Private Sector“, den Sektor 12 einer LUN, ausgeführt.

Um die LooksAlive-/IsAlive checks zu unterdrücken, um beispielsweise ein „chkdsk /f“ exklusiv und vor allem unterbrechungsfrei auf einer Shared Disk auszuführen zu können, gibt es seit Windows Server 2003 SP1 den Maintenance Mode. Mittels folgendem cluster.exe Parameter kann eine Disk in diesen Wartungsmodus versetzt werden:

cluster.exe . res "ADisk" /maint:on

Weiterführende Informationen zum Wartungsmodus:
» http://support.microsoft.com/kb/903650/en-us

Das LooksAlive-/IsAlive Intervall kann alternativ dazu über ein cluster.exe Parameter angepasst werden:

» Cluster.exe Parameters: LooksAlivePollInterval – IsAlivePollInterval

Die Defaultwerte sollten nur in begründeten Fällen angepasst werden, zB. um die Zeit für einen Restore zu erhöhen. In der Regel können ab W2K3 SP1 anstatt der manuellen Anpassung die Werte des Maintenance Mode verwendet werden.

Stay tuned,
N.Own

Recommended W2K3 SP2 Cluster Hotfixes

Nebst der Liste empfohlener Hotfixe für Windows 2000 Server und Windows Server 2003 SP1 Cluster gibt es inzwischen auch eine Liste empfohlener Hotfixe für Windows Server 2003 SP2 Cluster:

» Recommended hotfixes for Windows Server 2003 Service Pack 2-based server clusters

Ende letzter Woche wurde die Liste aktualisiert. Diese Liste sollte jeder Cluster Admin im Auge behalten und die Nodes entsprechend patchen.

Stay tuned,
N.Own

Cluster Knoten deinstallieren

Wie deinstalliert man eigentlich einen Clusterknoten rückstandslos?

Folgende Vorgehensweise über den Cluadmin empfiehlt sich, um einen Knoten zu deinstallieren:

  1. Ressourcen auf passiven Knoten schwenken
  2. Cluster Knoten anhalten: „Stop the Cluster Service“
  3. Knoten evicten: „Evict Node“

Das führt dazu, daß der Knoten entfernt wird und alle Clusterspezifischen Einstellungen gelöscht werden.
Der Clusterdienst an sich gehört zum Funktionsumfang eines Windows Servers und bleibt erhalten.

Falls dies fehlschlägt, kann die Kommandozeilen-Option forcecleanup gewählt werden:

cluster node nodename /forcecleanup

Vorsicht: Diesen Befehl keinesfalls auf einem aktiven Node ausführen. KB 282227 beschreibt diese Optionen:
» How to Uninstall the Cluster Service

Sinn macht ein forcecleanup auch, falls der Knoten ursprünglich mal einem anderen Cluster (KB 555216) angehört hat oder das evicten nicht vollständig abgeschlossen wurde.

Stay tuned,
N.Own

Cluster Ressource pending on-/offline

Im Fehlerfall kann es vorkommen, daß eine einzelne Cluster Ressource über den als Pending Timeout definierten Zeitraum hinaus im Status On- oder Offline Pending verbleibt.
Die entsprechende Ressource DLL gibt weiterhin Statusmeldungen an den Ressource Monitor zurück, so daß der Status in diesem Fall weiterhin bestehen bleibt.
Siehe dazu auch folgenden Beitrag: https://www.cluadmin.de/giving-a-reprieve-for-resource-p104/

Um den Zustand zu beenden, kann man einen manuellen Failover initiieren:

» Cluster Resource Appears to Stop Responding in an Online Pending State…

Der KB Artikel zeigt dazu zwei Lösungsmöglichkeiten auf:

  1. Initiieren eines Failovers über den Cluster Administrator
  2. Dazu sucht man sich eine Ressource in der gleichen Gruppe, die online ist, wie zB. eine IP Ressource und initiiert über ‚Initiate Failure‘ einen Failover

  3. Initiieren eines Failovers über die cluster.exe
  4. cluster res "ResourceName" /fail

Ein weiterer Fehlerfall zB. beim Neueinrichten einer Applikation kann ebenfalls dazu führen. Ein Löschen der Ressource zur Neukonfiguration ist dann im Status On-/Offline Pending nicht möglich.
Eine praktikable Möglichkeit dies zu lösen ist das Offlineschalten der Ressourcen einer Gruppe:

1. Auswählen aller Ressourcen in der Gruppe
2. Über Rechtsklick ‚Take Offline‘ alle Ressourcen offline nehmen
3. Hängende Ressource löschen und mit korrekten Parametern neu einrichten

Stay tuned,
N.Own

Cluster Service Account (CSA) Rechte

Der Cluster Service Account (CSA) braucht gewisse Rechte, um alle Operationen des Cluster Dienstes ausführen zu können.

Voraussetzung für den ordentlichen Betrieb ist die Mitgliedschaft des Cluster Service Accounts in der Gruppe der Lokalen Administratoren sowie, daß der CSA Mitglied einer Domäne ist. Kein Cluster ohne DC und ohne Windows Domäne.

Weitergehende Rechte müssen in den Lokalen Sicherheitsrichtlinien auf jedem Nodes eines Clusters explizit vergeben werden:

Zum Vergrößern anklicken...

Klicken Sie den Screenshot zum Vergrößern an. Bei den grün markierten Rechten muss der CSA eingetragen werden, bei den orange markierten Rechten muss die lokale Administratorengruppe eingetragen sein (standard).

Das gilt für Windows Server 2003 Cluster – bei Windows Server 2000 müssen weiterhin folgende Rechte eingetragen sein:

  • Increase quotas
  • Load and unload device drivers
  • Lock pages in memory

Ein Fehlen dieser Rechte kann zu unvorhergesehenen Effekten und Fehlern führen, daher empfehle ich dringend die Einrichtung dieser Rechte, die man manuell vornehmen muss.

Wichtig: Keine Security Templates auf Cluster Nodes verteilen, typische Stolperfallen sind Security Templates wie die Highly Secure Predefined Security Templates (hisec*.inf). Die Predefined Templates müssen stark verändert werden für einen reibungslosen Betrieb des Cluster Dienstes.

KB Artikel zu den CSA Rechten:
» How to manually re-create the Cluster service account

Unter Windows Server 2008 wird der CSA obsolet, der Cluster Dienst läuft dort im Kontext des LocalSystem Accounts.

Stay tuned,
N.Own