Nous commençons à envisager Ansible pour remplacer une ancienne installation de cfengine2. J'ai un playbook simple qui:
- copie un fichier sudoers
- copie un modèle resolv.conf (alimenté par les données group_vars et host_vars)
- vérifie que deux services sont en cours d'exécution
- vérifie la présence d'un utilisateur local
Le playbook prend plus de 4 minutes d'horloge murale pour fonctionner contre 97 machines (toutes connectées via un réseau rapide de 1 Go ou 10 Go, avec une latence LAN inférieure à 1 ms) et consomme plus de 50% du processeur sur la machine virtuelle à mémoire vive 4G à 2 cœurs lorsque je suis l'exécuter.
Il faut environ 11 secondes pour s'exécuter sur une seule machine, avec environ 4 secondes de temps processeur utilisateur + sys consommé, ce qui semble encore un peu excessif TBH pour la quantité de travail impliqué.
Les bits évidents:
- J'ai le pipeline explicitement activé dans un répertoire playbook-ans localible.cfg
- J'ai la mise en cache des faits sur jsonfile activée, même ansible.cfg local
- J'ai des fourches réglées à 50, les mêmes (j'ai essayé d'autres valeurs)
- Je suis sûr qu'Ansible utilise SSH et non Paramiko et qu'il utilise le socket de contrôle persistant - je peux voir les processus SSH démarrés et persistants pendant l'exécution.
Ce niveau de performance est-il normal ou quelque chose ne va pas avec ma configuration? Comment puis-je déterminer quoi, le cas échéant?
Edit: En août 2017, nous voyons toujours ce problème. La version Ansible est 2.2.1 et la taille du playbook a maintenant augmenté. Numéros à jour:
- 98 hôtes
ansible -m ping allprend 4,6 s réel, 3,2 s utilisateur, 2,5 s sys fois- une exécution complète du livre de lecture prend 4 minutes, en utilisant 100% d'utilisateurs et ~ 35% de CPU système tout en le faisant (sur un serveur de déploiement de VM à 2 cœurs, 100% étant un CPU complet)
- le système d'exploitation cible est largement CentOS 7, certains CentOS 6
- le profilage ne révèle aucun point chaud de tâche spécifique AFAICT
Bien que le playbook soit maintenant beaucoup plus grand, je ne pense toujours pas qu'il y ait quoi que ce soit là-dedans pour justifier ce niveau de charge CPU sur le serveur de playbook - heure d'horloge, peut-être, mais le serveur de déploiement devrait être largement inactif pendant la majeure partie de la course, autant que je sache, il s'agit principalement de copies de fichiers et de quelques extensions de modèles.
Notez que nous utilisons assez largement les hôtes / groupvars
Plusieurs personnes ont posé des questions sur le profilage, à la suite d'une analyse avec profilage:
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
watch cat /proc/sys/kernel/random/entropy_availpendant que le playbook est en cours d'exécution. Si c'est moins de 1000, vous avez un problème potentiel; si son moins que 64 et ne récupère pas, alors vous avez un problème de famine d'entropie défini. (commun dans certains environnements VM). Cela s'applique à votre serveur de gestion ainsi qu'aux nœuds que vous gérez.
ansible -i all all -m pingcontre plus de 300 hôtes (principalement des VM) a pris un peu moins d'une minute. Votre playbook fait-il quelque chose pour changer d'utilisateur (devenir / sudo / etc.). À quoi ressemble «-m ping»? Je dirais, d'après mon expérience, que vous voulez avoir plus de mémoire pour 50 fourchettes.
ANSIBLE_CALLBACK_WHITELIST=profile_taskset pour un débogage plus approfondi avecANSIBLE_DEBUG=1. Faites également très attention à la vitesse de connexion ssh initiale.