Cluster Problem - MS DTC

[Lian 2.539]

Das ist merkwürdig.

 

Welchen Laufwerksbuchstaben hat Dein Quorum?

Siehst Du das Quorum auf dem aktive Node?

Welche Meldung erhältst Du bei einem Zugriffsversuch?

Hast Du aktuell ERR oder WARN Einträge im cluster.log?

 

auf die Daten der von Laufwerk F: kann ich ja auch zugreifen, aber halt nur auf die Freigaben und nicht auf alle Verzeichnisse...

Aus welchem Grund?

Fehlende Share/NTFS Berechtigung?

[Pipeline 12]

Allerdings ist das merkwürdig!

 

Quorum ist P:

Und ich sehe das Quorum als Laufwerk auf keinem der beiden Nodes.

Allerdings sehe ich den Datenträger in der Computerverwaltung, wenn ich dort auf öffnen gehe erscheint: "Das System kann das angegebene Gerät nicht finden"

Die Eigenschaften der Partition sind leer, die der Festplatte sind okay.

 

nur Error keine Warnings:

[FM] FmpRmOfflineResource: RmOffline() for 51a2e62c-777e-46c3-aed6-094c4a420cc1 returned error 997

 

Network Name <Clustername-2>: Unable to read resource data parameter, error=2

 

[CPCK] CpckDeleteCheckpointFile- couldn't open CryptoSync key error 2

 

[CP] CppDeleteCheckpointFile- couldn't open RegSync key error 2

[CP] CpRemoveResourceCheckpoints, CppDeleteCheckpointFile failed 2

 

 

Mit keinen Zugriff auf alle Verzeichnisse meinte ich, dass ich halt nur auf die Freigaben zugreifen kann und auf die restlichen Verzeichnisse halt nicht.

[Pipeline 12]

Nachtrag:

 

Wenn ich im Explorer in der Adressleiste einfach mal p: eintippe erscheint die Meldung:

Titel "Cluster"

Text: "Auf P:\ kann nicht zugegriffen werden. Der Ordner wurde verschoben oder entfernt"

[Lian 2.539]

Laß uns mal prüfen, ob uns ein File System Filter Treiber einen Streich spielt.

 

Stelle sicher, daß ein Node alle Ressourcen online hält und führe in der Kommandozeile folgenden Befehl aus:

 

devcon listclass LegacyDriver > fltrdriver.txt

 

Siehe: Cluadmin.de Windows Cluster Blog » Blog Archiv » Filtertreiber im Cluster

 

Bitte hänge die Datei fltrdriver.txt an Deinen Beitrag an.

[Pipeline 12]

hier ist das Ergebnis

fltrdriver.txt

[Lian 2.539]

Ok, laß uns mal folgendes testen:

 

Fahre beide Nodes herunter und schalte sie aus. Bitte auch die Storage ausschalten (stromlos). Nach ca. 30 Sekunden die Storage wieder einschalten, wiederum nach ca. 30 Sekunden einen Node starten, den anderen ausgeschaltet belassen.

Wie sieht es mit dem Zugriff auf das Quorum (P:) und den Daten aus?

Bitte hänge Screenshots von der Datenträgerverwaltung und vom Explorer an.

 

Nutzt Ihr eine IBM Storage? Was ist es für eine? Shared SCSI?

Sind die Nodes auch von IBM?

Welche Version von McAfee nutzt Ihr?

[Pipeline 12]

Moin Lian,

 

ich habe seit meinem letzten Eintrag nur gekuckt und nichts weiter geändert, keinen Neustart gemacht oder ähnliches.

 

Ich habe zwar noch nicht gefunden was da passiert ist, aber ich sehe wieder alles!

Ich wollte es vorhin meinem Vorgesetzten zeigen und siehe da, alles wieder normal!

 

Tja, nun muss ich nur noch verstehen was da los war/ist.

 

Zumindest möchte ich dir vielen Dank aussprechen, dafür das du so viel und lange versucht hast mit mir das Problem zu finden! Das ist echt klasse von dir!

 

Wenn du mal in Hamburg bist sag bescheid, dann gebe ich dir n Bier aus...

[Pipeline 12]

@Lian:

 

Kannst du mir eine Quelle für Informationen zum Cluster.log nennen?

[Lian 2.539]

Immer gerne - Prima, das es wieder läuft :)

 

Vermutlich war der Online Pending der Disk Ressourcen aus Storagesicht noch nicht abgeschlossen...

 

Versuche beim nächsten Wartungsfenster ein paar Failover mit genügend Zeit dazwischen, um sicherzugehen, daß alles wie gewohnt funktioniert.

 

Zum Thema cluster.log gibt es hier gute Infos:

Anatomy of a Cluster Log Entry

Techniques for Tracking the Source of a Problem

 

Auch sehr hilfreich: Die Erklärung zu den Status Codes im cluster.log:

Für Cluster Nodes - Cluster Groups - Cluster Resources - Network Interfaces - Networks

 

 

hth