Hi Lon,
>> Why redhat made the qdisk as Tie-breakers and some people from support
>> say it's one optional or some time says is not needed?
>
> It is optional and is often not needed. It was developed really for two purposes:
>
> - to help resolve fencing races (which can be resolved using delays or other tactics)
>
> - to allow 'last-man-standing' in >2-node clusters.
>
> With qdiskd you can go from 4 to 1 node (given properly configured heuristics). The other 3 nodes then, because heuristics fail, can't "gang up" (by forming a quorum) on the surviving node and take over - this means your critical service stays running and available. The problem is that, in practice, the "last node" is rarely able to handle the workload.
>
> This behavior is obviated by features in corosync 2.0, which gives administrators the ability to state that a -new- quorum can only form if all members are present (but joining an existing quorum is always allowed).
Is this in RHEL6? I am still trying to solve the following situation:
- 2 node cluster without need for shared storage (no gfs)
- qdiskd in place because of the heuristics.
- Cluster is fine if both nodes have network communication and heuristics reach the minimum score.
Problem: if the shared storage the qdisk resides on becomes unavailable (but everything else is fine) a node will be fenced. It actually happens at the time the shared storage comes back online, the node re-establishing the storage link first wins and fences the other one. I try to mitigate that with loooong timeout settings, but therefore a necessary cluster switch eviction is also delayed.
I would really appreciate if the qdiskd would withdraw it's quorum vote and not do any fencing at all. The cluster would survive as quorum is also gathered if the cluster network connection is established.
best regards, Gunther
Gunther Schlegel
Head of IT Infrastructure
--
.............................................................
Riege Software International GmbH Phone: +49 2159 91480
Mollsfeld 10 Fax: +49 2159 914811
40670 Meerbusch Web: www.riege.com
Germany E-Mail: schlegel@xxxxxxxxx
-- --
Commercial Register: Managing Directors:
Amtsgericht Neuss HRB-NR 4207 Christian Riege
VAT Reg No.: DE120585842 Gabriele Riege
Johannes Riege
Tobias Riege
.............................................................
YOU CARE FOR FREIGHT, WE CARE FOR YOU
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
