Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Does either Puppet or Chef support replicated puppetmasterd/Chef servers? It seems very surprising to me that these tools would force a single point of failure, but I haven't been able to find any mention of this in their docs or Google.

I know Puppet and Chef can be run without a server (possibly updated with, e.g., git as described in, but this seems like a second-class citizen, and presumably loses some monitoring ability.

share|improve this question
up vote 5 down vote accepted

For puppet you would need

  1. Identical manifests. This can be accomplished by keeping your manifests in version control and checking them out on each server, which you should be doing anyway.
  2. A single database for stored configuration, if you using it. This is as simple as switching from the default of sqlite to MySQL or PostgreSQL. You could then use those database's tools to replicate the database if desired.
  3. Certificates from the same certificate authority on all puppetmasters. Dan Bode has the best explanation I've seen. However, it may not work the way you expect. Also, I'm not sure how this works with client certificates (i.e. /var/lib/puppet/ssl/ca/signed/*). Maybe their verification is always handled by the single CA (introducing a single point of failure), or maybe the the pem files be distributed to each puppetmaster after they're signed by the CA.
share|improve this answer
The signed directory doesn't much matter; as long as the cert presented by the client chains up to the CA cert each master uses, you'll be fine. The tricky thing about multiple hosts running a single CA certificate is that they can issue duplicate serial numbers so revocation (puppet cert --clean will also revoke if they were issued with the same serial by different masters. Bad news. To get around it use --ca_server on the clients and set ca = false on your non-signing puppetmasters. – eric sorenson Mar 16 '11 at 1:36

Chef was designed from the ground up to be run with multiple servers, for all its backend component, as this is a core feature of the Opscode Platform - a highly scalable hosted Chef Server.

The various core components of the Chef Server:

  • API server
  • Data Store (CouchDB)
  • Search Engine (SOLR)

As such, each of these components is capable of running on separate servers, and Chef can be configured to use separate servers for each component. For configuration information, see the Chef Configuration Settings page. Primarily, couchdb_url and solr_url settings can point to either a separate server (or servers) running those components, or a load balancer sitting in front of them.

The Chef Server API will also need access to the cookbooks, which could be in a shared filesystem.

share|improve this answer

If you are concerned about a single point of failure, create a puppet cluster :)

  1. Create a cluster with corosync/pacemaker (or old school heartbeat), make it active/passive or even active/active
  2. Get the two (or more) server's important data duplicated with DRBD or other method
  3. Profit!

Puppet clients get their manifests from the puppet server identified by DNS (unless you specify a server on the client, but that's not very good), so you have many ways to guarantee that you will never be without a server, be it an active/passive cluster where the passive gets the IP address if the active fails or even changing the DNS entry to a new server in case of failure (the first option being the most elegant).

A great resource for clusters those days is the Cluster from Scratch document from clusterlabs. The guide includes DRBD configuration examples so it's very through.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.