[ClusterLabs] Start at boot time Corosync 2.X + Pacemaker 1.1 cluster (Debian Wheezy)

[Andrew Beekhof]

> On 8 Jun 2015, at 6:36 pm, Danilo Malcangio <d.malcangio at eletech.it> wrote:
> 
> Thanks Kristoffer for answering
>> The corosync and pacemaker services are just regular services, and are
>> configured to start at boot just like any other service in sysvinit. That said, if
>> you have a two node cluster, starting the services at boot might not be
>> what you want since you can easily end up with a deathmatch
>> configuration.
>> 
> I noticed that corosync and pacemaker are regular services, in fact if I start them from shell /etc/init.d/corosync start /etc/init.d/pacemaker start they both seem to work.
> 
> You say that having them at boot is not a good configuration (possible deathmatch), but how can I ensure the cluster stays always up if I don't have that? What is the best practice?

The ‘cluster’ is more than one node though.
Even if one node goes down, the cluster is still ‘up’.

You should be getting alerts that the node went down so that you can check what happened and re-insert it into the cluster.
And if one event takes out both nodes… then you’ve designed a single point of failure ;-)

> 
> In my previous cluster configuration I used the Debian Wheezy apt-get binaries (corosync v1.4.2 and pacemaker v1.1.7)

yikes!

> and all I had to do was setting a START variale to yes in /etc/default/corosync on both nodes.
> (as described here http://zeldor.biz/2010/12/activepassive-cluster-with-pacemaker-corosync/)
> 
>> If adding them to runlevels doesn't work, there's a bug of some sort.
> I thought there was a bug in the init.d scripts, but I cannot find any so far.
> I was looking for someone who had done this on Debian, because I am starting to think maybe I am picking the wrong runlevels, should I change defaults to specific runlevels?
> update-rc.d corosync defaults 
> update-rc.d pacemaker defaults 
> 
>> There's a basic guide here: http://crmsh.github.io/start-guide/
> While googling I also found the guide you mentioned, but all I could find are commands to configure corosync, configure pacemaker start and stop the cluster. 
> No way to make crmsh a daemon that starts the cluster at boot (if this is the right thing to do to obtain a cluster on even after a temporary node failure like an AC power failure)

Even if you want the cluster to start at boot, this would be a horrible way to do it.
Just use whatever mechanism debian normally uses for starting things at boot time.

>> I'm working on a crmsh version of the official documentation, but it's
>> not online yet unfortunately.
>> 
> 
> That would be great! Do you think you'll be able to share the crmsh version of documentation soon? 
>> The crmsh commands simply call
>> "service corosync start; service pacemaker start"
>> and
>> "service pacemaker stop; service corosync stop"
>> 
> That is what I thought and what I found evince of while I was googling online, corosync and pacemaker must be started in an order and stopped in the opposite one, I was planning to do that on Debian by renaming the symlinks in rc.d but I haven't got to that point because update-rc.d doesn't create any symlinks for corosync and pacemaker when I issue the two commands I wrote before. That's why I am wondering about specifying different runlevels.
> 
>> To be honest this has only been tested on SUSE distros by me. I'd be
>> happy for patches to make this work properly on Debian. :)
>> 
> Anyway I could help, I'd be glad to make the latest stable cluster stack (corosync + pacemaker) work on Debian with compiled sources. 
> I thought mine was a common problem because there was this compiling guide on the official website (http://clusterlabs.org/wiki/Compiling_on_Debian) so I thought more people used this OS for clustering, and some already encountered my problem.
> 
> Thanks again
> Danilo
> 
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org