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


Chronological Thread 
  • From: Tim Smith < >
  • To:
  • Subject: [chef] Re: How do you manage multiple data centers
  • Date: Tue, 7 May 2013 15:26:42 -0700

The simplest thing to do is to create a role per datacenter.  You can have a generic "base" role that contains your various base recipes and attributes that are not specific to each datacenter.  Then your datacenter role contains just attributes that are specific to that datacenter such as dns, smtp, etc.  You can still have a single Chef server or Hosted Chef to wrap it all up in a single easy to manage interface.

Tim Smith  - Systems Engineer 
m: +1 707.738.8132


On May 7, 2013, at 3:02 PM, Elvin Abordo < "> > wrote:

Oh and each "datacenter role" includes another "default" role that has a master run list that contains organization wide stuff like the apt, resolver, ntp,postfix, etc. etc. cookbooks. the cookbooks that generally shouldn't be modified. 

we follow the attribute precedence rules pretty heavily. This allows me to control everything in one shot, like say i want to remove a user everywhere. But if there are pretty little snow flakes it still gives me the final say in the chef_environment. 


On Tue, May 7, 2013 at 5:46 PM, Elvin Abordo < " target="_blank"> > wrote:
I have multiple chef servers for different data centers, atleast that's the plan. I stopped at 2 because i haven't found an elegant solution to keep them in sync yet. I have 2 more datacenters. 

The data that's different between my datacenters are the infrastructure stuff. DNS, NTP, SMTP relays, etc. etc. Those get set in a datacenter role (zips up flame suit). Essentially it's items that should not ever change unless for a good reason. It's a repeatable pattern across each individual data center. The stuff that needs to be accessed by ALL datacenters are in a databag which is kept in sync with some janky shell scripts. I need to find a more elegant solution to handle this. 

One OSC server is handling production data centers and another is handling DR/Development.

It helps limit the blast radius and i can sleep at night knowing that if something gets pushed to DR/Development it's not going to impact revenue in production. Although "Dev is a production" dev doesn't bring home the bacon. I'll just have angry people at me. 

The sycning part is tought, but overall this setup has made nervous people a bit at ease. 




On Tue, May 7, 2013 at 5:15 PM, Sascha Bates < " target="_blank"> > wrote:
I'm about to embark on the multiple part of my multi-datacenter automation project and am wondering how people are accomplishing this now?

I currently have environments that mimic code promotion: dev/test/prod whatever.

My production environment is only used to pin cookbook versions and that's how I ensure promotion is controlled, by bumping the version in my environment.

Now that I'm approaching a situation where I need to make some design decisions, I'm wondering how people are managing data that vary by location and how they feel about what they're doing.  I'm aware of most of the ways to do something like this: environments, roles, data bags, whatevs, so I'm not in need suggestions on what I should do, but am looking for how you like what YOU'RE doing.

Thanks,
Sascha



--
Elvin Abordo
Mobile: (845) 475-8744



--
Elvin Abordo
Mobile: (845) 475-8744




Archive powered by MHonArc 2.6.16.

§