- To: linux clustering <linux-cluster@xxxxxxxxxx>
- Subject: Re: Fencing: Prevent rebooting halted node
- From: Digimer <lists@xxxxxxxxxx>
- Date: Wed, 21 Mar 2012 09:20:51 -0400
- In-reply-to: <CAE7pJ3Cr-AKMNSKuE5yM8SXw2RFP4fCkd-FjM=pwhZ1g2G-RwQ@mail.gmail.com>
- References: <4F69B0CE.7020809@ecarnot.net> <CAE7pJ3Cr-AKMNSKuE5yM8SXw2RFP4fCkd-FjM=pwhZ1g2G-RwQ@mail.gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1
On 03/21/2012 07:23 AM, emmanuel segura wrote:
> Hello Nicolas
>
> The first i can recommend it's use a quorum disk and for your problem i
> know that it's called fencing-loop
Quorum disk works only when someone has a SAN proper, and even then, I
am pretty sure that a node in an unknown state will still need to be fenced.
> you got two choices
>
> 1:don't put the daemons cluster at boot time
This delays the issue, not avoid it. When Nicolas starts cman, it will
still fence the peer.
> 2:If you use a qdisk you can use clean_start="1" in the fence_daemon
> tag, this can be used if you are not using gfs or gfs2 or
> <cmantwo_node="1"expected_votes="1"/>
I feel *very* uncomfortable with the 'clean_start="1"' option. Making
any kind of assumption about the state of a node in a cluster is asking
for trouble.
--
Alteeve's Niche!
Madison Kelly 647-501-5200
Papers and Projects: https://alteeve.com
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
[Corosync Cluster Engine]
[Linux RAID]
[Fedora Users]
[Fedora Legacy List]
[Fedora Desktop]
[Fedora SELinux]
[Big List of Linux Books]
[Yosemite News]
[Yosemite Photos]
[KDE Users]