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. 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? On Wed, Jan 25, 2012 at 5:02 PM, Digimer <linux@xxxxxxxxxxx> wrote: > On 01/25/2012 05:00 PM, Miguel Angel Guerrero wrote: >> The obliterate-peer.sh was restored, but when i make a cable >> disconnection or simulate this with ifdown, always the same node >> reboot in this case the node without sleep in obliterate-peer.sh >> script, this is a normal situation? > > Yup, this is expected. When the link breaks, the one with the sleep will > delay long enough that it will be dead before it finishes sleeping. > However, if the node without the sleep dies, the one with the sleep will > still succeed and the cluster will recover but with a short delay. > > -- > Digimer > E-Mail: digimer@xxxxxxxxxxx > Papers and Projects: https://alteeve.com -- Atte: ------------------------------------ Miguel Angel Guerrero Usuario GNU/Linux Registrado #353531 ------------------------------------ -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
