Entendendo o Funcionamento do Puppet Server

Neste artigo estou utilizando o Puppet Server 4.3.
Antes de fazer o tuning vamos entender um pouco sobre o funcionamento do Puppet. O Puppet Server trabalha com o JRuby, permitindo a utilização de todos os recursos do Ruby dentro da plataforma Java, a ideia é aproveitar o melhor dos 2 mundos, ou seja, utilizar recursos tanto do Ruby como do Java.
Quando você inicia o Puppet Server ele carrega um pool de interpretadores JRuby para poder executar os códigos em Ruby, pense neste pool como se fossem pequenas máquinas virtuais “VM” executando os códigos em Ruby.

Por padrão o Puppet Server carrega apenas uma instância JRuby (max-active-instances), isto quer dizer que o puppet Server pode tratar apenas uma requisição de clientes puppet por vez; por exemplo seu puppet server está configurado na forma padrão, ou seja max-active-instances=1, sendo assim com apenas uma instância JRuby UP, se você tiver 2 clientes solicitando configurações no Puppet Server ao mesmo tempo, um deles entrará na fila até que o outro termine.

Análise de logs.

tail –f /var/log/puppetlabs/puppetserver/puppetserver-access.log

10.0.0.161 - - - 23/Feb/2016:13:28:17 -0300 "GET /puppet/v3/node/puppetclient-01.devopslab.com.br?environment=production&transaction_uuid=c2cba296-f2e3-4f8e-90fe-1d52dfa4e0ad&fail_on_404=true HTTP/1.1" 200 9386 10.0.0.161 10.0.0.161 8140 93
10.0.0.162 - - - 23/Feb/2016:13:28:17 -0300 "GET /puppet/v3/node/puppetclient-02.devopslab.com.br?environment=production&transaction_uuid=b12a202a-81b6-414b-82db-22289d59c372&fail_on_404=true HTTP/1.1" 200 9400 10.0.0.162 10.0.0.162 8140 58
10.0.0.161 - - - 23/Feb/2016:13:28:17 -0300 "GET /puppet/v3/file_metadatas/pluginfacts?environment=production&links=follow&recurse=true&source_permissions=use&ignore=.svn&ignore=CVS&ignore=.git&checksum_type=md5 HTTP/1.1" 200 242 10.0.0.161 10.0.0.161 8140 16
10.0.0.162 - - - 23/Feb/2016:13:28:17 -0300 "GET /puppet/v3/file_metadatas/pluginfacts?environment=production&links=follow&recurse=true&source_permissions=use&ignore=.svn&ignore=CVS&ignore=.git&checksum_type=md5 HTTP/1.1" 200 242 10.0.0.162 10.0.0.162 8140 17

tail –f /var/log/puppetlabs/puppetserver/puppetserver.log

2016-02-23 13:28:17,644 INFO  [qtp955200837-68] [puppet-server] Puppet Caching node for puppetclient-01.devopslab.com.br
2016-02-23 13:28:17,742 INFO  [qtp955200837-69] [puppet-server] Puppet Caching node for puppetclient-02.devopslab.com.br

2016-02-23 13:28:20,790 INFO  [qtp955200837-67] [puppet-server] Puppet Caching node for puppetclient-01.devopslab.com.br
2016-02-23 13:28:20,906 INFO  [qtp955200837-67] [puppet-server] Puppet Compiled catalog for puppetclient-01.devopslab.com.br in environment production in 0.09 seconds

2016-02-23 13:28:21,253 INFO  [qtp955200837-68] [puppet-server] Puppet Caching node for puppetclient-02.devopslab.com.br
2016-02-23 13:28:21,354 INFO  [qtp955200837-68] [puppet-server] Puppet Compiled catalog for puppetclient-02.devopslab.com.br in environment production in 0.08 seconds

Perceba que cada requisição dos clientes são tratadas de forma sequencial, uma de cada vez, a diferença é de milissegundos, no entanto dependendo do tamanho do seu ambiente passará de milissegundos para segundos, e de segundos para minuto, e quando você perceber seu Puppet Server estará com um overhead imenso, causando lentidão na aplicação de configurações nos clientes.

Tuning parte 1 – Cálculo de CPUs

Uma instância definida no parâmetro “max-active-instances” aloca 1 CPU.

Não é recomendável ter mais instâncias definidas no “max-active-instances” do que CPUs. Se você tem 8 CPUs, logo a quantidade de “max-active-instances” tem que ser no máximo 8, se o número de instâncias forem maior que as CPUs logo sobrará instâncias carregadas em memória porém sem trabalhar, no final das contas, mais instâncias que a quantidade de CPU, vai aumentar o consumo de memória porém sem benefício algum.

Uma fórmula razoável para cálculo de “max-active-instances”:
max-active-instances = CPUs-1.

CPUs = a quantidade de CPUs no servidor.
CPUs-1 = a Quantidade de CPUs-1, pois precisa sobrar uma CPU para o restante do sistema, é possível utilizar todas as CPUs para o Puppet Server, max-active-instances=Número-de-CPUs, mas seu sistema também tem outras coisas rodando, como systemd, ssh, postfix, e outros vários processos, então é recomendável deixar uma CPU sobrando.

Para aumentar a quantidade de instâncias edite o arquivo puppetserver.conf.

vi /etc/puppetlabs/puppetserver/conf.d/puppetserver.conf

# (optional) maximum number of JRuby instances to allow
max-active-instances: 7

Reinicie o Puppet Server para a aplicação das alterações.

Tuning parte 2 – Cálculo de Memória RAM do JRuby e do Sistema Operacional

Cálculo de Memória RAM do JRuby
Cada instância JRuby/JVM definida no “max-active-instances” consome 512MB em média, podendo ser um pouco mais dependendo da quantidade de módulos, manifestos e etc, mas em regras gerais é 512MB.

Para calcular a memória do JRuby/JVM podemos fazer:
Memória RAM = (max-active-instances * 512)MB.
Se eu tenho 7 CPUs destinadas ao max-active-instances, então minha memória RAM para o JRuby/JVM seria: (7 * 512) = 3584 MB RAM.

Altere a variável JAVA_ARGS no arquivo /etc/sysconfig/puppetserver.

vi /etc/sysconfig/puppetserver

JAVA_ARGS="-Xms3584m -Xmx3584m -XX:MaxPermSize=256m"

Xms e Xmx é recomendável serem iguais; o Xms é a memória inicial alocada pelo JVM e Xmx é o máximo que pode ser alocado pelo JVM.

Reinicie o Puppet Server para a aplicação das alterações.

Cálculo de Memória RAM do Sistema Operacional.
Destine para o Sistema Operacional algo em torno de 512MB, sendo assim a memória RAM total do seu servidor deve ser igual a memória calculada para o JRuby/JVM + 512MB.

Mem RAM do sistema Operacional = (max-active-instances * 512)MB + 512MB
No nosso exemplo, precisaríamos de um servidor com 4GB RAM pois (7*512)MB+512MB = 4096MB.

Tuning parte 3 – File Descriptors

File Descriptors controlam a quantidade de processos e arquivos que um usuário pode trabalhar no Linux, por padrão vem configurado em 1024 open files.

Vamos alterar isto para um número maior, já que o usuário “puppet” responsável por todos os processos do Puppet Perver pode precisar de algo acima de 1024 open files.

Edite o arquivo: /etc/security/limits.conf

vi /etc/security/limits.conf


*                soft   nofile      4096
*                hard   nofile      65535

Esta configuração se aplicará globalmente afetando todos os usuários do sistema.

Se você quiser mais segurança, você pode especificar o usuário “puppet” de forma explicita.

vi /etc/security/limits.conf

puppet                soft   nofile      4096
puppet                hard   nofile      65535

Verifique também o File Descriptor “fs.file-max” configurado no Sysctl.

sysctl -a | grep fs.file-max

fs.file-max = 150216

Se for algum número menor do que você configurou no arquivo limits.conf, ajuste para um número no mínimo igual ao “puppet hard nofile 65535”.
Edite o arquivo “/etc/sysctl.conf”.

vi /etc/sysctl.conf

fs.file-max = 150216

No meu caso o “fs.file-max” já estava como 150216, então não precisei mexer em nada, porém é sempre bom saber que no sysctl.conf também pode ser configurado o File Descriptor.

Dúvidas, sugestões e correções entre em contato.
Muito brigado.
Leonardo