ThomasM3

Welches iSCSI Target verwendest Du?: StarWind 3.5.5 Was heißt in die andere Richtung?: Von node1 (lost communication) nach node2 ging die Umschaltung. Von node2 (lost communication) nach node1 klappte es nicht. Es funktioniert immer nur dann, wenn ich vor dem selbst erzeugten Fehler ein manuelles Verschieben der Clustergruppe anstoße. Hast Du Dir das cluster.log angesehen? Ja, ich sehe es mir in Echtzeit an 00000cc0.00000cb0::2008/11/05-12:55:14.013 ERR Physical Disk <Datenträger Q:>: [DiskArb] BusReset completed, status 1. 00000cc0.00000cb0::2008/11/05-12:55:14.013 ERR Physical Disk <Datenträger Q:>: [DiskArb] Failed to break reservation, error 1. 00000cc0.00000cb0::2008/11/05-12:55:14.508 WARN Physical Disk <Datenträger Q:>: [DiskArb] Retry arbitration, 4 attempts left 00000cc0.00000cb0::2008/11/05-12:55:14.508 INFO Physical Disk <Datenträger Q:>: [DiskArb] Read the partition info to insure the disk is accessible. Aber das sieht man schon im Eventlog, dass der SCSI Busreset scheitert. Ich weiss nur leider nicht, ob das Cluster nun umschalten müsste oder nicht. Du hast geschrieben, dass es nicht umschaltet, um ein Split Braun zu verhindern, der oben verlinkte MS-Artikel besagt das Gegenteil und mein System tuts mal und tuts mal nicht

Oh, das ging ja schnell. Ich hätte gehofft, dass Node2, die zwar Node1 nicht mehr sieht, bzw. eine hypothetische Node3 (bei mir nicht vorhanden) nun versuchen das Quorum zu übernehmen, da sie selbst noch funktionierende Netzwerkverbindungen haben. Siehe: How the Cluster service reserves a disk and brings a disk online 1.2.3.4... Die Übernahme wird durch den SCSI BUS-Reset auf Node2 initiiert. Node1 müsste dann das Quorum frei geben. Das passiert nicht. So interpretiere ich den KB309186 Artikel in den Punkten 1-4. – – – Nun habe ich gerade festgestellt, dass nach einem Update der iSCSI-Target-Software, das von mir gewünschte Verhalten Auftritt. D.h., wenn die aktive Node1 die Kommunikation verliert, dann übernimmt Node2 mittels Bus-Reset das Quorum. Leider klappt es nicht in die andere Richtung. Aber scheinbar hat das hier noch keiner getestet.

Hallo, folgende Frage möchte ich stellen: Was muss bei einem W2k3 shared nothing 2 node aktiv passiv Cluster passieren, wenn die aktive Node1 die Kommunikation auf Public und auf Private verliert? (Anmerkung: Als shared medium wird ein iSCSI-Target verwendet) In meinem Testnetz passiert folgendes, wobei ich denke, dass dies nicht i.O. ist. Im Cluadmin von Node1 sieht man, dass Public und Private einen Fehler haben. Im Eventlog von Node2 sieht man was zu erwarten ist, dass Node2 drei mal versucht einen SCSI BUS Reset zu initiieren, was aber nicht gelingt. Das wars dann. Sicherlich ist der Fall nur hypothetischer Natur, da Private und Public über separate NICs und separate Switche geführt sind. Am Echtsystem kann ich die Sache leider nicht testen. Ich vermute, dass das iSCSI-Target den BUS-Reset nicht erkennt.