[chef] Re: Re: Re: High availability for chef

[KC Braunschweig < >]

I'd be interested in people's experience with the capacity of various
Chef server configurations. I'm working on the HA setup as well.
Active/passive failover seems relatively straightforward but the next
question is when that won't be good enough. Anyone have numbers they'd
be willing to post? Haven't started testing yet to see what the first
bottleneck will be. Hoping that it'll scale well enough to handle our
needs (only a couple thousand nodes) so that we won't have to do much
more than split off the data components on separate nodes. Not
terribly interested in mimicking the full multi-tier stack I imagine
the platform runs on if I can avoid it.

KC

On Tue, Jul 5, 2011 at 11:00 AM, Anthony Goddard 
<
 >
 wrote:
> You may also (in addition to the HA setup) want to check out Spiceweasel:
> https://github.com/mattray/spiceweasel which will allow you to reference all
> of your nodes, cookbooks, roles etc in a yaml file and bulk load from it.
> Ant
>
> On Jul 5, 2011, at 1:42 PM, Adam Jacob wrote:
>
> On Mon, Jul 4, 2011 at 7:30 AM,  
> <
 >
>  wrote:
>
> As we move configuration  of more critical components to our chef server, we
>
> need to implement some sort of high availability solution for our chef
>
> server.
>
> Any one has experience in that matter ?
>
> a)      Is replication of couchdb, solr index viable ? or
>
> It depends on what level of HA you require. For both CouchDB and Solr,
> you can handle this with DRBD and passive failover for what is usually
> sub-second takeover on failure - this is also good for things like
> cookbook uploads (stick /var/chef on the DRBD drives.)
>
> You can also make each component HA on their own, using the mechanisms
> the upstream recommends - Replication in both cases you list above.
>
> b)      it is  more simple to just re-create the database from source code
>
> of cookbook, roles and databags ? in that case how to make sure that we
>
> don´t have to re-register each node
>
> You likely want to be keeping an active replica (either with app
> replication or disk-level replication) for your failover - this helps
> in DR, but that's what backups are for.
>
> Best,
> Adam
>
> --
> Opscode, Inc.
> Adam Jacob, Chief Product Officer
> T: (206) 619-7151 E: 
> 
 
>
>