Qual é o desempenho razoável de um manual simples do Ansible contra ~ 100 hosts?


11

Estamos começando a olhar para o Ansible para substituir uma instalação antiga do cfengine2. Eu tenho um manual simples que:

  • copia um arquivo sudoers
  • copia um resolv.conf modelado (alimentado com dados de group_vars e host_vars)
  • verifica alguns serviços em execução
  • verifica a presença de um usuário local

O manual demora mais de 4 minutos para ser executado em 97 máquinas (todas conectadas em redes 1gig ou 10gig rápidas, com latência de LAN de sub-1ms) e consome mais de 50% da CPU na VM de memória 4G de dois núcleos quando estou executando.

Demora cerca de 11 segundos para rodar em uma única máquina, com cerca de 4 segundos de tempo de CPU do usuário + do sistema consumido, o que TBH ainda parece um pouco excessivo para a quantidade de trabalho envolvida.

Os bits óbvios:

  • Tenho o pipeline ativado explicitamente em um local ansible.cfg do playbook-dir
  • Tenho cache de fato para jsonfile ativado, mesmo local ansible.cfg
  • Tenho garfos definidos para 50, o mesmo (tentei outros valores)
  • Estou certo de que o Ansible está usando SSH e não Paramiko e está usando o soquete de controle persistente - posso ver os processos SSH sendo iniciados e persistindo durante a execução.

Esse nível de desempenho é normal ou há algo errado com minha configuração? Como posso determinar o que? Em caso afirmativo?

Edit: A partir de agosto de 2017, ainda estamos vendo esse problema. A versão Ansible é 2.2.1 e o tamanho do manual cresceu agora. Números atualizados:

  • 98 anfitriões
  • ansible -m ping all leva 4,6s reais, 3,2s usuário, 2,5s sys vezes
  • uma execução completa do manual leva 4 minutos, usando 100% de usuário e ~ 35% da CPU do sistema (em um servidor de implantação de VM de 2 núcleos, sendo 100% de uma CPU completa)
  • O SO alvo é amplamente o CentOS 7, alguns CentOS 6
  • a criação de perfil não revela nenhum ponto ativo de tarefa específica AFAICT

Embora o manual agora seja muito maior, ainda não acho que exista algo que justifique esse nível de carga da CPU no servidor do manual - horário do relógio de parede, talvez, mas o servidor de implantação deve ficar ocioso durante a maior parte da execução, até onde posso ver, são principalmente cópias de arquivos e algumas expansões de modelos.

Observe que estamos fazendo um uso bastante extenso de host / groupvars

Várias pessoas perguntaram sobre criação de perfil, cauda de uma corrida com criação de perfil:

Tuesday 01 August 2017  16:02:24 +0100 (0:00:00.539)       0:06:22.991 ******** 
=============================================================================== 
yumrepo : centos repos -------------------------------------------------- 9.77s
sshd : copy CentOS 6 sshd config ---------------------------------------- 7.41s
sshd : copy CentOS 7 sshd config ---------------------------------------- 6.94s
core : ensure core packages are present --------------------------------- 6.28s
core : remove packages on VM guests ------------------------------------- 5.39s
resolv : stop NetworkManager changing resolv.conf ----------------------- 5.25s
yumrepo : epel6 gpg key ------------------------------------------------- 3.94s
yumrepo : epel7 gpg key ------------------------------------------------- 3.71s
yumrepo : nsg gpg key --------------------------------------------------- 3.57s
resolv : build resolv.conf ---------------------------------------------- 3.30s
yumrepo : nsg repo ------------------------------------------------------ 2.66s
resolv : check NetworkManager running ----------------------------------- 2.63s
yumrepo : psp repo ------------------------------------------------------ 2.62s
yumrepo : ucs repo ------------------------------------------------------ 2.44s
yumrepo : epel repo ----------------------------------------------------- 2.27s
resolv : check for nmcli ------------------------------------------------ 2.08s
core : remove various unwanted files ------------------------------------ 1.42s
telegraf : write telegraf.conf file ------------------------------------- 1.13s
core : copy sudoers in place -------------------------------------------- 0.94s
core : ensure sshd is running ------------------------------------------- 0.90s

4
Faça alguns perfis com ANSIBLE_CALLBACK_WHITELIST=profile_taskse para uma depuração mais completa com ANSIBLE_DEBUG=1. Preste muita atenção também na velocidade inicial da conexão ssh.
Konstantin Suvorov

Concorde com o comentário de @KonstantinSuvorov - pode haver um único host no lote que está demorando bastante em uma determinada tarefa. Depois de isolar a tarefa com profile_tasks, é possível examinar a execução dessas tarefas em seus hosts e ver qual delas é a mais longa. Você também pode executar uma tarefa trivial, como "command: w" em relação a todos os hosts para ver que leva um tempo esperado.
precisa saber é o seguinte

1
Verifique a falta de entropia. watch cat /proc/sys/kernel/random/entropy_availenquanto o manual está sendo executado. Se for menor que 1000, você tem um problema em potencial; se for menor que 64 e não se recuperar, você terá um problema definido de inanição por entropia. (comum em alguns ambientes de VM). Isso se aplica ao seu servidor de gerenciamento e também aos nós que você está gerenciando.
Cameron Kerr #

Na minha VM de gerenciamento com 4 GB de RAM, tenho garfos = 20 e pipelining = True. ansible -i all all -m pingcontra mais de 300 hosts (principalmente VMs) levou menos de 1 minuto. Seu manual está fazendo algo para mudar de usuário (tornar-se / sudo / etc.). Como funciona o '-m ping'? Eu diria que, com base na experiência, você deseja ter mais memória para 50 garfos.
Cameron Kerr #

qual é o seu sistema operacional de destino?
Xddsg

Respostas:


1

no seu ansible.cfgconjunto, o seguinte:

[defaults]

# profile each task
callback_whitelist = profile_tasks

# [don't validate host keys](http://docs.ansible.com/ansible/intro_configuration.html#host-key-checking)
host_key_checking = False

[ssh_connection]
pipelining = True

Além disso, em seu manual, defina a estratégia como 'grátis'

- hosts: all
  strategy: free
  tasks: [...]

Por fim, desative a coleta de fatos em seu jogo: gather_facts: false

Se, após a criação de perfil, você estiver vendo muito disso:

TASK [pip foo]
ok: [10.192.197.252] => (item=ansible)
ok: [10.192.197.252] => (item=boto)
ok: [10.192.197.252] => (item=boto3)
ok: [10.192.197.252] => (item=passlib)
ok: [10.192.197.252] => (item=cryptography)

esmague essas ações em ansible.cfg[padrões]:

por exemplo squash_actions = yum,pip,bar


Obrigado pela resposta. Já estamos usando a estratégia: receio e coleta de fatos, receio, é algo que os manuais exigem, para que isso realmente não funcione. Como observado na minha resposta, eu já estou fazendo pipelining.
user53814

@ user53814 com a criação de perfis ativada, o que leva mais tempo? você pode atualizar sua pergunta com a versão do ansible que você está usando?
Xddsg
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.