[Linux-cluster] Redhat without qdisk

emmanuel segura emi2fast at gmail.com
Fri Apr 13 11:20:46 UTC 2012


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 <schlegel at riege.com> 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: schlegel at riege.com
> --                                 --
> 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 at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster
>



-- 
esta es mi vida e me la vivo hasta que dios quiera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20120413/38e96c7e/attachment.htm>


More information about the Linux-cluster mailing list