Wir fangen an, Ansible zu prüfen, um eine alte cfengine2-Installation zu ersetzen. Ich habe ein einfaches Spielbuch, das:
- kopiert eine sudoers-Datei
- kopiert eine resolv.conf mit Vorlagen (gespeist mit group_vars- und host_vars-Daten)
- prüft, ob einige Dienste ausgeführt werden
- prüft auf Anwesenheit eines lokalen Benutzers
Das Playbook benötigt mehr als 4 Minuten Wallclock-Zeit, um auf 97 Computern ausgeführt zu werden (alle über ein schnelles 1-Gig- oder 10-Gig-Netzwerk mit einer LAN-Latenz von weniger als 1 ms verbunden) und verbraucht über 50% der CPU auf der 2-Core-4G-Speicher-VM, wenn ich bin Laufen lassen.
Es dauert ungefähr 11 Sekunden, um auf einem einzelnen Computer ausgeführt zu werden, wobei ungefähr 4 Sekunden CPU-Zeit von Benutzer + System verbraucht werden, was TBH für den Arbeitsaufwand immer noch etwas zu viel zu sein scheint.
Die offensichtlichen Punkte:
- Ich habe die Pipeline explizit in einem Playbook-Verzeichnis lokal ansible.cfg aktiviert
- Ich habe tatsächlich Caching zu jsonfile aktiviert, gleiche lokale ansible.cfg
- Ich habe Gabeln auf 50 eingestellt, gleich (ich habe andere Werte ausprobiert)
- Ich bin sicher, dass Ansible SSH und nicht Paramiko verwendet und den permanenten Kontrollsocket verwendet. Ich kann sehen, dass die SSH-Prozesse während des Laufs gestartet werden und bestehen bleiben.
Ist dieses Leistungsniveau normal oder stimmt etwas mit meinem Setup nicht? Wie kann ich feststellen, was, wenn ja?
Bearbeiten: Ab August 2017 sehen wir immer noch dieses Problem. Ansible Version ist 2.2.1 und die Größe des Playbooks ist jetzt gewachsen. Aktuelle Nummern:
- 98 Gastgeber
ansible -m ping all
dauert 4,6s real, 3,2s Benutzer, 2,5s sys mal- Ein vollständiger Playbook-Lauf dauert 4 Minuten, wobei 100% Benutzer und ~ 35% System-CPU verwendet werden (auf einem 2-Core-VM-Bereitstellungsserver, wobei 100% eine vollständige CPU sind).
- Zielbetriebssystem ist größtenteils CentOS 7, einige CentOS 6
- Bei der Profilerstellung werden keine spezifischen Aufgaben-Hotspots AFAICT angezeigt
Obwohl das Playbook jetzt viel größer ist, glaube ich immer noch nicht, dass irgendetwas vorhanden ist, das diese CPU-Auslastung auf dem Playbook-Server rechtfertigt - vielleicht die Wanduhrzeit, aber der Bereitstellungsserver sollte für den größten Teil des Laufs weitgehend inaktiv sein. Soweit ich sehen kann, handelt es sich hauptsächlich um Dateikopien und einige Vorlagenerweiterungen.
Beachten Sie, dass wir Host / Groupvars sehr häufig verwenden
Mehrere Leute haben nach Profiling gefragt, dem Ende eines Laufs mit Profiling:
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_avail
während das Playbook läuft. Wenn es weniger als 1000 ist, haben Sie ein potenzielles Problem. Wenn es weniger als 64 ist und sich nicht erholt, haben Sie ein definitives Problem mit dem Entropie-Hunger. (in einigen VM-Umgebungen üblich). Dies gilt für Ihren Verwaltungsserver und auch für die von Ihnen verwalteten Knoten.
ansible -i all all -m ping
gegen über 300 Hosts (meistens VMs) dauerte es weniger als 1 Minute. Tut Ihr Playbook etwas, um den Benutzer zu ändern (wird / sudo / etc.). Wie funktioniert '-m ping'? Ich würde erfahrungsgemäß sagen, dass Sie mehr Speicher für 50 Gabeln haben möchten.
ANSIBLE_CALLBACK_WHITELIST=profile_tasks
und für ein gründlicheres Debuggen mitANSIBLE_DEBUG=1
. Achten Sie auch bei der anfänglichen SSH-Verbindungsgeschwindigkeit genau darauf.