[chef] Re: Re: Re: Re: Re: Re: Re: How do you manage multiple data centers

["Scott M. Likens" < >]

Hi,

Ever debated an ec2-like endpoint and an ohai plugin to answer what datacenter/and other useful metadata?  Might seem extreme but if your dealing with multiple datacenters it should help reduce some bad patterns such as roles per datacenter, or having to manually set the datacenter attribute.

Scott

P.S. I know of no open source solutions to accomplish this, if there is any please link them.

On 5/8/13 4:01 AM, Maxime Brugidou wrote:

" type="cite">

Currently the plugin is purely based on the network subnet since we have clear separated subnets for each DC.

We are adding additional location info like room/rack/plane using LLDP (based on the physical network topology which matches the physical location).

On May 8, 2013 10:26 AM, "Jesse Nelson" < "> > wrote:

Maxime, I agree the fact that a node resides in a certain location shouldn't be prescribed it should be discovered. What does your ohai plugin do the discover the datacenter the node is in ?

On Wed, May 8, 2013 at 12:53 AM, Maxime Brugidou < " target="_blank"> > wrote:

We run chef on 7 datacenters and get the node's datacenter from an ohai plugin.

This is actually the cleanest thing to do, you don't have to manually set the node's DC anywhere since it's auto-discovered. When you need specific attributes per data center we use "wrapper" cookbooks that dynamically define attributes according to the DC.

On May 8, 2013 7:19 AM, "Torben Knerr" < " target="_blank"> > wrote:

Hey guys,

this is theoretical, I'm not through this in practice yet:

From a aconceptual point of view, I'd argue to definitely use environments rather than roles for keeping the datacenter (=a different environment) specific attributes.

From the gut feeling I would have started with sth like 'prod_dc1' and 'prod_dc2' environments etc..

Did I get it conceptually wrong or are there other practical reasons why you are all using a single 'prod' env and managing the dc specific stuff in roles instead?

Cheers, Torben

On May 8, 2013 1:40 AM, "Jesse Nelson" < " target="_blank"> > wrote:

I've used internal DNS to denote locality. We use a contrived 4letter LTD and then use the datacenter as the first dot: i.e: 356sf.myorg, 365ny.myorg.  I know it violates the cardinal no metadata in name rule that I try to abide by, but this makes it pretty easy to handle data center specific needs via node.domain, and without the need for specific roles to locality. A single cook/role (or role cook) denotes all the specifics for each datacenter, and individual cooks can easily override if needed. 

!DSPAM:518a3092305041804284693!