Tag / Kategorie: 'Failover Cluster'
Microsoft hat eine Liste der Events & Errors online, die bei einem Windows Server 2008 Failover Cluster auftreten könnten:
» W2K8 Failover Clustering Events and Errors
Events und Fehler aus folgenden Bereichen sind gelistet:
- Active Directory Permissions for Cluster Accounts
- Failover Cluster Configuration Availability
- Quorum and Connectivity Needed for Quorum
- Registry Checkpointing
- Verbose Cluster Logging
Die Liste ist Bestandteil der Windows Server 2008 Technical Library.
Stay tuned,
N.Own
Eben erreichte mich eine Nachricht von Symon Perriman bzgl. des Clustering Team Blog bei Microsoft:
The Clustering Blog is Restarting!!!
http://blogs.msdn.com/clustering/
Check out the failover clustering, NLB and high availability team’s blog.
Visit to learn about new features, find some cool techniques
and scripts, info about new KB articles, tips for debugging
clustering issues, and reflect upon Microsoft and industry news.
Stay tuned,
N.Own
Sechs Webcasts gibt es zum Auftakt von Windows Server 2008, der ab Ende Februar in die RTM Phase gehen wird. Die Webcasts drehen sich allesamt um das Thema Failover Clustering (HA).
Hier die Titel:
- Building High Availability Infrastructures
- Failover Clustering 101
- Failover Cluster Validation and Troubleshooting
- Geographically Dispersed Failover Clustering
- High Availability with Hyper-V
- Deep Dive on Failover Clustering
Die Termine sind zwischen dem 21.01. und dem 31.01.08
Hier sind die Webcasts zu finden:
http://blogs.technet.com/(…)high-availability(…).aspx
Stay tuned,
N.Own
Ein interessantes Interview mit Becky Benfield, Principal Program Manager, zum Thema Exchange 2007 High Availability Capabilities – sprich: Clustering – hat Harold Wong auf der TechEd 2007 aufgenommen.
Besonderes Augenmerk wird dabei auf die neuen Features des SP1 wie SCR gelegt:
http://msexchangeteam.com/videos/9/drandha/entry446453.aspx
Stay tuned,
N.Own
Mein Tutorial zum Thema “Windows Server 2008 Failover Clustering mit Virtual PC” ist nun fertig.
Mittels Virtual PC und der StarWind iSCSI Target Software wird ein Windows Server 2008 RC1 Failover Cluster aufgebaut. Als DC und iSCSI Target dient eine Windows Server 2003 R2 SP2 VM:
» W2K8 Failover Clustering mit Virtual PC
Stay tuned,
N.Own
Der Aufbau eines virtuellen Windows Server Failover Cluster mit Windows Server 2008 und Virtual PC ist kein großer Aufwand und bietet einem eine kostengünstige virtuelle Cluster Testumgebung.
Verwendete Software:
- Windows Server 2003 R2 SP2: DC und iSCSI Target
- Windows Server 2008 RC0: Failover Cluster Nodes
- RocketDivision StarWind v3.5: Software iSCSI Target
Folgende VMs sind aufgesetzt:
W2K3 R2 SP2: Domain Controller, iSCSI Target
256 MB RAM, 1 NIC, 1 HD, 3 iSCSI HDs
W2K8 RC0: Failover Cluster Nodes
384 MB RAM, 2 NICs, 1 HD
update: Ich habe das ganze nun in Tutorialform auf ServerHowTo.de online gestellt:
» W2K8 Failover Clustering mit Virtual PC
Stay tuned,
N.Own
Aus der Reihe Windows Server 2008 Technische Neuerungen dreht es sich beim 7. Teil um Windows Server Failover Clustering. Schwerpunkt ist die Installation eines Clusters sowie die neuen Quorum Modelle:
Stay tuned,
N.Own
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
Was tun, wenn nach einem Netzwerkkartentausch noch die alten TCP/IP Einstellungen im System vorhanden sind?
Dabei kann es zu folgender Fehlermeldung kommen:
The IP address XXX.XXX.XXX.XXX you have entered for this network adapter is already assigned to another adapter Name of adapter. Name of adapter is hidden from the network and Dial-up Connections folder because it is not physically in the computer or is a legacy adapter that is not working. (…)
Man kann sich die alte, nun versteckte Netzwerkkarte über den Device Manager wie folgt anzeigen:
1. Start > Run > cmd.exe
2. Umgebungsvariable über folgenden Befehl setzen:
set devmgr_show_nonpresent_devices=1
3. Device Manager in diesem Kontext aufrufen (nicht über die GUI!):
start devmgmt.msc
4. Im Gerätemanager über Menü ‘View’ >
‘Show Hidden Devices’ alle Geräte einblenden
5. Ausgegraute (physikalische) Netzwerkadapter deinstallieren
Nun sind die Überreste der alten Netzwerkkarte und deren Einstellungen gelöscht.
Diesen Tipp nutze ich schon seit vielen Jahren, ich habe das Verhalten bei vielen Systemen seit Windows 2000 beobachtet.
Es gibt zwei KB Artikel, die mir dazu bekannt sind – einen für Windows 2000 Server und einen für Windows Server 2003:
» Device Manager Does Not Display Devices Not Currently Present in Windows 2000 (KB 241257)
» Error message when you try to set an IP address on a network adapter (KB 269155)
Stay tuned,
N.Own
Wie deinstalliert man eigentlich einen Clusterknoten rückstandslos?
Folgende Vorgehensweise über den Cluadmin empfiehlt sich, um einen Knoten zu deinstallieren:
- Ressourcen auf passiven Knoten schwenken
- Cluster Knoten anhalten: “Stop the Cluster Service”
- 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
Im Deutschen heißt die englischsprachige “Resource” an sich “Ressource“. Solange man über Cluster Ressourcen spricht, fällt das nicht großartig auf – ist es mir bisher auch nicht.
Im Zuge des Blogs ist mir erst die unterschiedliche Schreibweise, je nach Sprache, aufgefallen.
MS selbst deutscht diese Begriffe in TechNet oder KB Artikeln ein.
Stay tuned,
N.Own
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: http://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:
- Initiieren eines Failovers über den Cluster Administrator
- Initiieren eines Failovers über die cluster.exe
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
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
Eine der unbeliebtesten Fehlermeldungen, die einem Cluster Admin widerfahren kann, ist die Meldung “Delayed Write Failed“. Diese Meldung besagt, daß Windows Daten im Speicher nicht mehr auf eine Storage schreiben kann, weil diese nicht mehr zur Verfügung steht. Das bedeutet kurz gesagt: Datenverlust (“The data has been lost”).
Das rührt daher, wenn ein Storage Treiber, in der Regel ein Storport Miniport Treiber, nicht rechtzeitig oder gar nicht mehr reagiert oder die Storage nicht mehr adäquat reagiert.
Das wiederum kann am Storport Miniport Treiber, an einem File System Filter Treiber liegen oder an der Hardware, sprich dem Controller oder den Array Komponenten bzw. den SAN Komponenten.
Events
Typische Events dazu im Cluster sind Event ID 9, 11, 15 sowie Event ID 50. Diese Event IDs sind kritische Fehler und sollten mit in das Monitoring aufgenommen werden.
» Troubleshooting event ID 9, 11, and 15 on Cluster Servers
» How to troubleshoot event ID 9, event ID 11, and event ID 15
Folgender KB Artikel hilft einem den error message dump zu dekodieren:
» Format of event log data created by ScsiPortLogError
Nachfolgend erscheint Event ID 50: Delayed Write Failed (IO_LOST_DELAYED_WRITE), ein Datenvolume oder die ganze Storage ist nicht mehr erreichbar. Windows kann empfangene oder verarbeitete Daten nicht mehr auf das Volume speichern, sprich: Irreparabler Datenverlust.
» Description of the Event ID 50 Error Message
Recovery
Den Cluster nun wieder betriebsbereit zu bekommen bedeutet zuerst das Storage Device, die Controller und alle Array bzw. SAN Komponenten zu prüfen sowie ggf. den Storage Treiber und die verwendeten File System Filter Treiber.
Erst danach kann man zu einem Recovery übergehen, denn bevor die Storage nicht wieder 100%ig ohne Fehler verfügbar ist macht die Wiederinbetriebnahme des Clusters keinen Sinn – der Fehler kann jederzeit wieder auftreten.
Stay tuned,
N.Own
Bei der Verwendung von Clustering über iSCSI kommen völlig neue Anforderungen an eine NIC (Netzwerkarte). Es läuft nun nicht nur der Netzwerktraffic eines Servers über eine (separate) NIC, um Clientanfragen abzuarbeiten, sondern auch der Backendverkehr vom Server zu einer Storage Box.
Um die CPU zu entlasten und einen höheren Durchsatz zu erreichen, gibt es die Möglichkeit den TCP/IP Overhead, den i.d.R. der TCP/IP Stack des OS verarbeitet, auf die NIC (sog. TOE NIC) zu verlagern. Dieses Verfahren nennt sich TCP Offload Engine (TOE) und schafft neben einer Entlastung der CPU eine effizientere Verarbeitung der Nutzdaten, sei es LAN Traffic oder iSCSI Payload.
Damit das TCP Offloading auf Windows Servern funktioniert, benötigt man neben einer TOE NIC auf 2K3 Servern <SP2 das Scalable Networking Pack (KB 912222), welches im SP2 enthalten ist. Microsoft spricht in dem Zusammenhang aus OS Sicht von TCP Chimney Offload, das weitere Aspekte beinhaltet (NetDMA/RDMA, RSS etc.).
In Zeiten von Gigabit Ethernet (1GbE/10GbE) ist TOE eine wünschenswerte Entwicklung, um den Flaschenhals NIC/CPU zu entlasten, allerdings bedeutet dies eine signifikante Veränderung der NDIS Architektur (2K3
In Verbindung mit NIC Teaming bringt einem TOE echtes Potenzial für Performancesteigerungen.
Im iSCSI Anwendungsfall auf Windows Cluster empfehle ich aus technischer Sicht anstatt von TOE NICs den Einsatz von iSCSI HBAs (Full iSCSI Offload HBA), die nochmals eine Steigerung des Durchsatzes/der IOPS schaffen, da diese rein für iSCSI Traffic optimiert sind. Zudem verwenden iSCSI HBAs wie auch FC HBAs den Storport Treiber und nicht den Windows Netzwerk Stack.
iSCSI HBAs sind nicht unbedingt billiger als FC HBAs, aber man spart sich immer noch die FC Switche 
Stay tuned,
N.Own
Clustering MVP Rodney R. Fournier hat ein Abschrift eines Interviews mit Jim Teague, Program Manager in der Microsoft High Availability Group zum Thema “Cluster Validation mit Longhorn/Windows Server 2008″ in seinem Blog veröffentlicht:
Interview mit Jim Teague:
» Cluster Validation in Windows Server “Longhorn”
Der Technet Webcast dazu ist ebenfalls online:
» TechNet Webcast: Cluster Validation in “Longhorn”
Stay tuned,
N.Own
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:
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
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
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
So langsam werden die ersten KB Artikel zu Windows Server Codename Longhorn publik:
Der KB Artikel beschreibt, wie man eine IPv6 Ressource im Cluster einbindet für Clustering mit dem SQL Server 2005.
Voraussetzung dafür ist der SQL Server 2005 Service Pack 2.
Infos bei TechNet zum Thema IPv6:
» http://www.microsoft.com/technet/network/ipv6/default.mspx
TechNet Einstiegsseite zu Longhorn Server:
» TechNet: Windows Server Code Name “Longhorn”
Stay tuned,
N.Own
Es gibt wieder einen TechNet WebCast zum Thema “Cluster Validation in Windows Server Longhorn”
Der WebCast findet am Montag, den 07.05.07 statt.
» TechNet Webcast: Cluster Validation in Windows Server “Longhorn”
Presenter: Jim Teague, Program Manager in der Microsoft High Availability group.
Stay tuned,
N.Own
