On Tuesday, July 21, 2015 at 9:14:04 AM UTC-5, jcbollinger wrote:


I am debating as to whether I need to build multiple puppet masters or
not. Is the following documentation still valid for the 4.x series of
It does say in a big callout box, "This document is specific to open
source Puppet, versions 2.7 through 3.2". The information within looks
reasonably accurate as far as it goes, and it probably applies more or less
to OS Puppet 4. That page doesn't talk about puppetserver, however, which
you should definitely be looking at as an alternative to both Webrick and
The differences between puppetserver and webbrick/Passenger were actually
the big concerns I had for that documentation. I did see that warning, but
I couldn't find an equivelent page for 4 so I figured it was best to ask.

I have a lot of load, a lot of puppet clients, and I wouldn't mind the
reliability of multiple systems. But I am not sure if it is worth the
effort or not. Are there good metrics for when to load balance or not?
You should consider balancing across multiple servers if one cannot manage
the load by itself. Catalog request timeouts, file service delays, and
constantly running at or near CPU or RAM capacity are possible signs. 150
clients all checking in at the default 30-minute interval is far more than
Webrick can usually handle. On the other hand, Webrick is single-threaded,
and you cannot easily buy a computer these days that does not sport
multiple CPU cores. Before opting to load-balance, you should look at ways
to make one server shoulder more load by engaging more cores, giving it
more RAM, or otherwise making more resources available to it. This is
where Passenger or puppetserver comes in.
The old hardware was a 2.2Ghz 4 core with 4GB of memory. The new hardware
is a 3Ghz 8 core with 8GB of memory. I read a few forum posts about
puppetserver doing much better at multi-threading, but I haven't found any
hard metrics on it. I decided to build out a fresh install of Scientific
Linux 6 with Puppet 4 today and start seeing how many of my modules will
move over and break. To make it simple to get working, I am doing it all on
one box, but I am thinking about moving the puppetDB to a second box after
I verify my setup works with a few clients. :-)

I have also been debating moving the puppetdb (that takes a ton of
resources on the system) to a second server and just letting the first
server be the puppetmaster/ca/ect. Thoughts on that? Any easier? Harder? I
figure it would be a lot easier to configure the balance, but I am not sure
what the consequences are or if it is even a good idea at all.

In a load-balancing scenario with puppetdb involved, it is essential that
the masters all have the same logical view of puppetdb data. It makes
sense to designate a separate machine for that role instead of making one
of the masters serve it, and it makes sense to reduce the load on your
master by splitting out puppetdb to its own machine even before you opt for
load balancing.
Awesome! Thanks for the confirmation. I will pursue that route first and
see what kind of load/need I have for multiple puppet masters.

Any got-cha!'s that I should be aware of? Any suggestions to make this
process smoother? Any recommendations for a big jump (more like complete
replacement) like this?

I'd strongly advise you to set up a separate test network on which you can
test the upgrade itself and validate all the code you intend to run in the
upgraded environment. Puppet 4 is not 100% backward compatible with Puppet
3 manifests (which is a different question from whether it is
backward-compatible with Puppet 3 clients).
I think I am just going to move forward with my proposed-new-build with 4
and a few clients. If everything works, then I will handle the servers in
chunks (test the webservers with one node, work out the kinks, move another
to verify, then move all of the other webservers before testing other

Thanks for the advice!

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/63f718bc-a02e-43cc-9b12-444712432b17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 5 of 17 | next ›
Discussion Overview
grouppuppet-users @
postedJul 20, '15 at 11:28p
activeJul 25, '15 at 11:37p



site design / logo © 2022 Grokbase