But if you have problem with your storage it's normale the node goes fenced, because your cluster services depends on storage
Remember the storage it's a critical component of a cluster Or maybe you wold like to have a cluster running without san disk Il giorno 13 aprile 2012 11:20, Gunther Schlegel <[email protected]> ha scritto: > 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: [email protected] > -- -- > 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 > [email protected] > https://www.redhat.com/mailman/listinfo/linux-cluster > -- esta es mi vida e me la vivo hasta que dios quiera
-- Linux-cluster mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-cluster
