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

PowerShell Provider & Cmdlets für CCS

Ende letzter Woche wurde das Compute Cluster Pack Tool Pack veröffentlicht, es bietet einen Simple Cluster Monitor, MPI Ping Pong sowie einen PowerShell Provider und Cmdlets.

Das CCS Tool Pack stammt von windowshpc.net und ist kostenlos:

Siehe: » Microsoft Compute Cluster Pack Tool Pack Released

» Download des Compute Cluster Pack Tool Pack

» Zu dem Artikel beim Windows PowerShell Team Blog

Stay tuned,
N.Own

Windows Server Failover Clustering mit Longhorn Server Beta 3

Mit Erscheinen der Beta 3 von Longhorn Server sind die ersten Step-by-Step Guides der Windows Server Code Name „Longhorn“ Technical Library verfügbar.

Die folgenden beiden Guides sind momentan für Windows Server Failover Clustering online:

» Step-by-Step Guide for Configuring a Two-Node File Server Failover Cluster in Windows Server „Longhorn“

» Step-by-Step Guide for Configuring a Two-Node Print Server Failover Cluster in Windows Server „Longhorn“

Die Neuerungen zu WSFC hatte ich bereits in einem früheren Beitrag angesprochen und sind ebenfalls in dem Dokumentenzweig verfügbar:

» Longhorn Server: What’s New in Failover Clusters

Also – holt Euch die Beta 3 von Longhorn Server und testet die Neuerungen von Longhorn Clustering 😉

Stay tuned,
N.Own

„Giving a reprieve for resource…“

Wird ein Volume als dirty markiert, das als Clusterressource eingebunden ist, so läuft es in den checkdisk. Der chkdsk geschieht erst nach dem Systemstart und nicht, wie außerhalb des Clusters üblich, während des Bootens und wird vom ClusDisk Treiber initiiert.
Folgender Eintrag ist in einem solchen Fall im cluster.log sichtbar:

00000a24.00000220::2007/05/04-07:31:33.934 INFO Physical Disk <Datenträger F:>: DriveIsAlive called for Online check
00000a24.00000220::2007/05/04-07:31:34.091 INFO Physical Disk <Datenträger F:>: DriveIsAlive checking that file system is not corrupt. If so, chkdsk may run.
00000a24.00000220::2007/05/04-07:31:34.091 INFO Physical Disk <Datenträger F:>: DisksIsVolumeDirty: Volume is dirty
00000a24.00000220::2007/05/04-07:31:34.091 INFO Physical Disk <Datenträger F:>: DisksOpenChkdskLogFile: chkdsk.exe output is in file: C:\WINDOWS\Cluster\ChkDsk_Disk0_Sig7D01274F.log

Im Hintergrund läuft nun ein chkdsk Prozess, der aktuelle Status ist im chkdsk(…).log ersichtlich.

Die Ressourcen verbleiben solange im Status Online Pending, im cluster.log wird folgendes geloggt:

00000a24.00000df0::2007/05/04-07:36:55.915 WARN [RM] ChkdskNotRunning: Found process chkdsk.exe.
00000a24.00000df0::2007/05/04-07:36:55.915 INFO [RM] RmpTimerThread: Giving a reprieve for resource Datenträger F:…

Der Resource Monitor (RM) wartet solange auf die Resource DLL, solange diese Statusupdates meldet.
Das bedeutet, daß die Zeit für ein PendingTimeout erst ab dem Zeitpunkt läuft, wenn keine Rückmeldung mehr von einer Resource DLL zurückgegeben wird.
Siehe: » MSDN – PendingTimeout
In diesem Fall muss der chkdsk Prozess abgewartet werden, die Ressourcen verbleiben währenddessen wie gesagt im Status Online Pending.
Folgender Eintrag ist im cluster.log zu finden über den chkdsk status:

00000a24.00000220::2007/05/04-08:39:59.779 WARN Physical Disk <Datenträger F:>: FixCorruption: chkdsk.exe returned status of X (…)

Erläuterung zu den status codes:
» http://support.microsoft.com/kb/265533/en-us/
Allgemeines zum chkdsk im cluster:
» http://support.microsoft.com/kb/272244/en-us

Ein Failover würde hier keine Verbesserung des Status bewirken, da erst das Dateisystem sauber sein muss, bevor eine Disk Ressource online genommen werden kann.

Um zum Titel dieses Beitrags und den eingangs erwähnten Eintrag im cluster.log zurückzukommen („giving a reprieve for resource…“): Interessante Wortwahl 😉

Stay tuned,
N.Own