- Puppet：Mastering Infrastructure Automation
- Felix Frank Martin Alfke Alessandro Franceschi Jaime Soriano Pastor Thomas Uphillis
- 471字
- 2021-07-09 18:59:01
Performance considerations
Operating a Puppet master gives you numerous benefits over just using puppet apply on all your machines. This comes at a cost, of course. The master and agents form a server/client relation, and as with most such constructs, the server can become the bottleneck.
The good news is that the Puppet agent is a fat client. The major share of the work—inspecting file contents, interfacing with the package-management subsystem, services subsystem, and much more—is done by the agent. The master only has to compile manifests and build catalogs from them. This becomes increasingly complex as you hand over more control to Puppet.
There is one more task your master is responsible for. Many of your manifests will contain file resources that rely on prepared content:
file { '/usr/local/etc/my_app.ini':
ensure => file,
owner => 'root',
group => 'root',
source => 'puppet:///modules/my_app/usr/local/etc/my_app.ini',
}
The source parameter with a URL value indicates that the file has been pregenerated and placed in a module on the Puppet master (more on modules in Chapter 5, Extending Your Puppet Infrastructure with Modules). The agent will compare the local file with the master's copy (by checksum) and download the canonical version, if required. The comparison is a frequent occurrence in most agent runs—you will make Puppet manage a lot of files. The master does not need a lot of resources to make this happen, but it will hinder fluent agent operation if the master gets congested.
This can happen for any combination of these reasons:
There are ways to scale your master operation via load balancing, but these are not covered in this book.
Tip
Puppet Labs have some documentation on a few advanced approaches at https://docs.puppetlabs.com/guides/scaling_multiple_masters.html.
Tuning puppetserver
puppetserver is a great way to run the master service. It is simple to set up and maintain, and it also has great performance during operation. Starting up can take a little while to initialize everything to that end.
There are only few customizable settings that can impact performance. Seeing as puppetserver runs in the JVM, the most important tuning approach is to scale the heap. A small heap will increase the overhead for garbage collection. Therefore, you should use the -Xmx and -Xms Java options to allow the JVM to use large parts of your available memory for the mentioned heap.
On Debian, these settings are found in /etc/default/puppetserver. It is sensible to pass the same value to both. A dynamic heap has little benefit, because you cannot safely use any saved memory.