Cluster Failover Szenario

[ThomasM3 10]

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.

[Lian 2.325]

Hallo und Willkommen an board,

 

worauf willst Du hinaus?

Solange die Verbindung zur Storage steht passiert auf dem aktiven Node i.d.R. nichts (SAS & FC).

 

In Deinem Fall passiert mehr: Die Netzwerkverbindungen gehen verloren und da Du kein dediziertes Netz für die Storage hast (empfehlenswert) auch die Verbindung zum iSCSI Device.

 

Das ergibt ggf. ein klassisches Split Brain Szenario: http://technet.microsoft.com/en-us/library/cc780689.aspx

Tie-breaker

 

The quorum is used as the tie-breaker to avoid “split-brain” scenarios. A split-brain scenario happens when all of the network communication links between two or more cluster nodes fail. In these cases, the cluster may be split into two or more partitions that cannot communicate with each other. The quorum is used to guarantee that any cluster resource is only brought online on only one node. It does this by allowing the partition that “owns” the quorum to continue, while the other partitions are evicted from the cluster.

Was genau im Detail millisekundengenau passiert, siehst Du im cluster.log im %SYSTEMROOT%\Cluster Verzeichnis.

[ThomasM3 10]

Hallo und Willkommen an board,

 

worauf willst Du hinaus?

Solange die Verbindung zur Storage steht passiert auf dem aktiven Node i.d.R. nichts (SAS & FC).

 

In Deinem Fall passiert mehr: Die Netzwerkverbindungen gehen verloren und da Du kein dediziertes Netz für die Storage hast (empfehlenswert) auch die Verbindung zum iSCSI Device.

 

Das ergibt ggf. ein klassisches Split Brain Szenario: Background (Server Clusters: Quorum Options - Windows Server 2003)

 

Was genau im Detail millisekundengenau passiert, siehst Du im cluster.log im %SYSTEMROOT%\Cluster Verzeichnis.

 

 

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.

[Lian 2.325]

Welches iSCSI Target verwendest Du?

 

Was heißt in die andere Richtung?

 

Hast Du Dir das cluster.log angesehen?

 

Hast Du eine dedizierte NIC mit einem eigenen privaten Netz/VLAN für den iSCSI Traffic?

[ThomasM3 10]

Welches iSCSI Target verwendest Du?

 

Was heißt in die andere Richtung?

 

Hast Du Dir das cluster.log angesehen?

 

Hast Du eine dedizierte NIC mit einem eigenen privaten Netz/VLAN für den iSCSI Traffic?

 

 

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

[Lian 2.325]

Welches iSCSI Target verwendest Du?:

StarWind 3.5.5

Ist bei den Shared Volumes Clustering aktiviert? (Allow multiple concurrent iSCSI connections (clustering))

 

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

Hast Du dazu auch Event IDs im Windows System Event Log?

Lege mal ein neues Quorum an, um Probleme mit der Signatur auszuschließen:

How to change the quorum disk designation

Wichtig dabei ist, daß beide Nodes und deren Ressourcen online sind.

 

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

Das habe ich nicht geschrieben, bitte nicht mißinterpretieren.

 

Leider hast Du die wichtigste Frage in Deinem Szenario nicht beantwortet: Hast Du eine dedizierte NIC mit einem eigenen privaten Netz/VLAN für den iSCSI Traffic?