[Linux-cluster] rhel6 node start causes power on of the other one

[Gianluca Cecchi]

On Tue, 22 Mar 2011 11:47:58 +0100, Fabio M. Di Nitto wrote:
> For RHEL related questions you should always file a ticket with GSS.

yes, it is my usual behaviour, but tipically I prefer to analyze in
advance and know if  a problem I'm encountering is a bug or only my
fault in docs understanding...

> This is expected behavior.
> The node that is booting/powering on, will gain quorum by itself and
> since it does not detect the other node for N amount of seconds, it will
> perform a fencing action to make sure the node is not accessing any
> shared resource.

I have been using clusters with rh el 4.x (x=6 and 8) without quorum
disks and clusters with rh el 5.y (y=3,4,5) with quorum disks and
tested also Fedora 13 cluster
All of them were two nodes clusters and I don't remember this behaviour.
I limit my example to 2-nodes cluster.
I thought that the sequence when both nodes are down and one starts was:
a) Fence daemon notices that the other node is down
(with status option of the fence command)
b) Fence daemon waits for the configured amount of time, based on
cluster.conf values or default ones, to "see" the other node coming up
c) after this amount of time fenced completes its start phase and the
other ones take place
In particular if quorum disk is defined (and votes expected = 2), when
the node becomes the master for the quorum disk, the cluster is formed
and services started
Without any power-on of the other node at all....

> I am not sure why you want a one node cluster,

This is intended only for mainteneance windows where for example I
could prefer to:
- power off both nodes
- startup and update the first one (so that the second remains
unchanged as a rollback path)
- test/verify it
- let it start alone and be an active one-node cluster (eventually with quorum)
- update the second node and let it join the cluster again

And in all the cases fence was working: it was iLO based fencing for
most of clusters and drac5 fencing another time.

Thanks,
Gianluca