[Linux-cluster] Halt nodes in cluster with cable disconnect

[Miguel Angel Guerrero]

In this scenario do you  know how i can do an explict ping to a
gateway to add a additional fencing condition?

On Fri, Jan 27, 2012 at 12:07 PM, Digimer <linux at alteeve.com> wrote:
> On 01/27/2012 11:51 AM, Miguel Angel Guerrero wrote:
>> Hi Digimer and Emmanuel
>>
>> I was trying some tests with my cluster configuration and, in short:
>>
>> 1. I think something's wrong with my configuration, because when a
>> real desconnection (i.e. unplug the cable) happens on the node which
>> does not have the sleep in the script (node A), the other node (node
>> B) is always stonith'ed, when obviously the node which should reboot
>> is the node A. This important to me because I want to know how the
>> cluster should behave when a fail over the switch port or the NIC
>> occurs.
>
> A broken link is a broken link. The cluster has no idea whose cable has
> been unplugged, only that they can no longer talk to one another. So the
> same node being fenced is expected.
>
> If you want to test an actual failure of the node to confirm that the
> node with the sleep will win, hang the nodeA machine.
>
> You can crash the machine with this;
>
> echo c > /proc/sysrq-trigger
>
> NodeB will lose contact with NodeA and call it's fence, sleep and then
> finish the fence call. NodeA will be completely hung, so it won't even
> try to fence and will stay hung until fenced by nodeB.
>
>> 2.  @Emmanuel, could you point me to redhat's documentation about
>> this? I tried your solution as this:
>>
>> <fence_daemon clean_start="0" post_fail_delay="10" post_join_delay="30"/>
>>
>> But still failed, tthere is another way?
>>
>> 3. Another solution in this thread is to add a quorum disk to the
>> cluster. I began to make this with this manual
>> http://www.skau.dk/index.php?option=com_content&view=article&id=34:rhcs-cluster-using-iscsi&catid=4:cases-to-explain&Itemid=3
>>
>> But I need to replicate the data using only two nodes, and it seems
>> that this solution requires three. Could somebody tell me if I'm doing
>> it fine/wrong? This causes conflicts when using DRBD?
>
> Using qdisk on DRBD is a bad idea. Consider a split-brain scenario, the
> qdisk could effectively duplicate, completely rendering it's purpose void.
>
> --
> Digimer
> E-Mail:              digimer at alteeve.com
> Papers and Projects: https://alteeve.com



-- 
Atte:
------------------------------------
Miguel Angel Guerrero
Usuario GNU/Linux Registrado #353531
------------------------------------