On Tuesday, July 21, 2015 at 9:14:04 AM UTC-5, jcbollinger wrote: > > > >> Questions! >> >> 1a) >> 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 >> puppet? >> https://docs.puppetlabs.com/guides/scaling_multiple_masters.html >> >> > > 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 > Passenger. >
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. :-) > > 1b) > 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. 3) 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 groups). 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+unsubscr...@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.
