On Monday, July 20, 2015 at 6:28:09 PM UTC-5, Stack Kororā wrote: > > Greetings, > > First, a short intro. :-) > > Last year I invested quite a bit of time building out a puppet > infrastructure. I have +150 Scientific Linux 6 and RHEL 6 servers running > puppet 3.7.1. It has been working really well concidering that I basically > haven't touched it since last October.... > > The issues I see are things like: > * I never got around to moving off of WEBrick for the webserver. So the > box takes a beating (it is always under a lot of load with that many > clients). > * I haven't gotten around to updating past 3.7.1....that is kinda a big > one... > * A lot of the poorly written modules _I_ wrote a year ago can now be > easily replaced with much better versions from the forge. > > Basically, things are pretty much my fault for not properly caring for it. > :-D > > But! It is working /really/ well. I don't have many changes except the > addition/decomission of servers. I keep meaning to spend time, but it > hasn't happened....until last weekend when the puppetmaster server went off > line...I have the server functioning again, but the motherboard is *not* > long for this world. > > Since I am rebuilding anyway and I _know_ that our infrastructure is about > to grow another 100 servers in the next few months, I figured I should look > into upgrading to puppet 4.1. I have read through the changelog (didn't > understand a lot, but I recognize there are a lot of changes I will have to > make). If I am willing to take the time to migrate to puppet-forge modules > anyway (plus hopefully fix any bad code I can't replace), wouldn't this be > a good time to switch puppet versions too? > >
Sure it would, if you can in fact accommodate that. > 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. > 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. > I never got around to setting up puppet dashboard, but I would like to. > Any load-balanced solution I would prefer to be one that worked with > dashboard (unless there is a better recomendation out there??). > > 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. > > 2) > I read in the changelog that the older clients should work with the > backward compatibility, but is it worth even trying? Or should I just push > out the updated puppet client wherever I can before adding the server into > my new build? (not hard to do in my environment) > It's worth trying if upgrading the clients when you upgrade the master would present a challenge. Even if you plan to update everything in one fell swoop, it may be to your advantage to rely on the newer master serving older clients at least for the duration of the upgrade. > 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). John -- 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/bef899c9-ee8c-41fe-a054-b48f90dd1ee4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
