[chef] Re: Re: Re: pacemaker cookbook


Chronological Thread 
  • From: Matt Kynaston < >
  • To:
  • Subject: [chef] Re: Re: Re: pacemaker cookbook
  • Date: Wed, 29 Aug 2012 13:12:30 +0100



On 29 August 2012 11:48, Mat Davies < " target="_blank"> > wrote:


On 29 August 2012 11:25, Matt Kynaston < " target="_blank"> > wrote:
On 29 August 2012 11:10, Mat Davies < " target="_blank"> > wrote:
Hi,

does anyone know of any already written cookbook for setup and management of pacemaker that is compatible with debian?

I'm looking to setup some loadbalancers/reverse proxies using nginx and pacemaker for ip failover and service restart but so far I'm stuck finding anything current for pacemaker and thought it was worth checking here before starting from scratch.

I'm just getting round to looking at Pacemaker + Corosync + Chef as well, but for DB failover. So far I've found this:

As the author notes, the stumbling block is letting pacemaker manage the services instead of chef. I'd be very interested to discuss any solutions.

It looks interesting I've not really looked into barclamp and crowbar before, it looks to be far broader coverage than I was thinking of as it is try to setup and manage drbd etc.

Yeah but it doesn't look like the recipes and LWRP he's got actually do anything with barclamp/crowbar or drdb. Haven't tried them, mind, just scooted through the code ;)

The solution I'm trying to build uses replication, not drdb[1]. I'm pretty new to all this, and the problem I'm trying to get to grips with is separating out the responsibilities of Pacemaker and Chef. In some ways they're both doing similar things - holding information about nodes, configuring them, stopping/starting services. It'll be easy for them to get in a fight!

I don't know how relevant any of this will be for your setup, but my thinking so far goes:

Adding new nodes: Chef only ever adds slaves. Initial setup of master is manual (though Chef knows which nodes are slaves and which is master):
  1. Chef sets up new slave server and adds it to the cluster in 'standby' mode
  2. Chef gets the replication in sync
  3. Chef brings node online in pacemaker
Configuration changes:
  1. Chef puts slave on standby in Pacemaker
  2. Chef does configuration changes
  3. Chef puts slave online in Pacemaker
Failover: 
  1. Pacemaker does it's stuff promoting the slave and taking out the old master. 
  2. Modified Pacemaker resource agent updates master/slave attribute on Chef nodes.
Matt Ray suggests replacing the init scripts with symlinks to /dev/true so Chef doesn't screw things up trying to start and stop services. I'm wondering if it would be better to replace them with scripts that talk to Pacemaker.

Any thoughts or comments very welcome.

Matt

 

I have been using a non chef managed Pacemaker + Corosync for a redis failover environment and had issues with disk sync issues so was planning on avoiding that for a HA loadbalancer that does have any requirement for disk sync.




Archive powered by MHonArc 2.6.16.

§