Archiv der Kategorie: Failover Cluster

Cluster Knoten deinstallieren

★ von

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

Resource oder Ressource?

★ von

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

Cluster Ressource pending on-/offline

★ von

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

  2. Initiieren eines Failovers über die cluster.exe

    3. 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

Delayed Write Failed

★ von

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

TCP Offload Engine (TOE) & iSCSI

★ von

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.
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