Sysadmin Day #5

sysadmin #5 (day 1)
● Puppet et Foreman, par Romain Vigraud
● Les CPUs pour les nuls, par François Tigeot et Fabrice
Bacchella
● Logstach, par Aurélien Rougemont et Nicolas Szalay
● Comprendre les I/O, par Fabrice Bacchella
● Ansible, une alternative à Puppet ?, par Bruno Bonfils
Photo sous licence CC Atos

Puppet et foreman (1/5)
● Foreman est un outil de gestion des cycles de vie des serveurs
– Génération de dashboard de plan d'exécution de Puppet
(modification de fichier, temps passé, etc ...)
● Il permet d'installer, configurer et superviser des machines physiques
et virtuelles
● Il est intimement lié à Puppet (mais on peut utiliser SALT et bientôt
Chef ou Ansible)
– Il ne permet pas de modifier les classes Puppet (ENC)
– Seules les classes dans des modules sont prises en compte
– 1 node Foreman = 1 hostgroup Puppet
– Affichage des classes via des templates YAML

● Le fonctionnement est modulaire
– Une BDD (PostgreSQL, MySQL, SQLite)
– Des smart-proxy pour interroger Chef, Puppet, BMC, le DNS
– Provisionning de machines pour VMWare, ovirt, libvirt (KVM),
OpenStack, EC2, …, RedHat, Debian, OpenSUSE, Solaris
● Réduction du coût d'installation
● Diminution du nombre d'erreurs
● Décommissionnement possible
(attention à la faire aussi dans Puppet)
– Son inventaire de ressources est fait
par facter ou ohai

● L'orchestration de Foreman permet d'automatiser des
tâches Puppet
– Bootstrap DHCP/TFTP/etc ….
– Signature du certificat de la CA Puppet
– Écriture du DNS (dnsupdate)
– Déployer des mots de passe, ….
– Rollback de toute opération en cas d'erreur
● Foreman est un ensemble de d'outil à adapter

● Authentification RBAC
● Gestion des « locations »
● Plugins
– discovery, hubotnotify, bootdisk
● Intégration peu aisée
– Bien documentée mais non clé-en-main
– À adapter
– Interface lourde
– Connexion possible à Nagios mais lente

● Et Techsys dans tout çà ?
– Nos clients n'utilisent pas encore Puppet … (ni même
Ruby)
– Interface au design peu vendeur
– Outil d'avenir : Foreman est piloté par RedHat pour
remplacer RedHat Satellite
● Ressources
– http://theforeman.org/
– http://puppetlabs.com/

Les CPUs pour les nuls (1/5)
● Un peu d'histoire
– 1981 : un processeur x86 (un chipset « simple »)
– 1995 : SMP (Symmetric MultiProcessing), deux ou plus CPU avec un lien
symétrique vers la mémoire
– 2003 : NUMA (Non Uniform Memory Access), la mémoire est attachée au CPU
● Hiérarchie d'accès (CPU, cache L1, L2, RAM, disque)
● Ajout de cohérence, bande passante inter-socket importante, mais mémoire
toujours très lente, besoin de limiter les invalidations
● L'Hyperthreading
– permet de faire croire à un programme
qu'il est sur une architecture SMP
– Faire tourner des instructions simples
sur un thread pendant qu'un autre
traite les complexes

● La course aux performances
– Un Xeon permet un gain de 100 % sur une base SQL qui ne fait que du select
– En PostGreySQL9.1, on a une limite à 16 cœurs ;
– En PostGreySQL9.2, on peut aller jusqu'à 64 cœurs et le calcul est 63,8x plus rapide (pertes
liées aux locks)
– L'OS doit faire tourner les instructions sur les parties les plus rapides, le faire profiter des
caches => le noyau doit connaître la topologie du CPU
– Ne pas sous-estimer le réseau (gestion multi-queue) avec par exemple le bus PCI-Express
(carte réseau attachée à un socket) mais dont le gain n'est utile qu'avec un kernel récent
● Problème de dissipation thermique
– Plus la fréquence est élevée, plus il chauffe, plus il baisse sa fréquence pour ne pas fondre
(ex du repo DragonFly 1,9 GHz qui tombe à 800 MHz en compilation)
– Loi d'Amdhal : ajouter des cœurs n'est pas une solution miracle !

● Le futur des CPUs 1 cœur x86 =>
– Superpipelines
– Architecture horizontale pour répartir les fonctions
– Hyperthreading sur partie jaune
– Le branch predication gère les sauts pour qu'une colonne
soit toujours remplie (on accepte jusqu'à 900 rollback pour
faire l'opération en une étape)
– Le jeu d'instruction est toujours x86 avec des ajouts (Regular
Instruction Set) : parallélisation des instructions
– Réels gains Haswell = port 6 et 7
– Utile de tout recompiler un kernel pour accéder au
nouveautés vidéos (bleu / FMA) à l'inverse des kernel sur
Itanium qui peuvent/doivent être optimisés.
– Normalement, c'est la libc qui apporte les améliorations
sur le système
– Les traitements AGU traitent ensuite avec la mémoire et les
écritures

● « Le processeur le plus performant n'existe pas ! »
– Peu d'intérêt pour l'hyperthreading dans le cas de calcul scientifique
– Réel intérêt pour l'hyperthreading dans le cas d'une base de données
– Certains CPU sont plus adaptés à la virtualisation (mais c'est à l'hyperviseur à
connaître le TLB),
– D'autres aux traitements multimédia ….
– Consulter les matrices « nombre de cœur / fréquence »
● Monitoring
– cpustat (OpenSolaris) donne une vision par cœur et ce qui est en attente
– Il est possible de choisir la topologie CPU lors de la création d'une machine
VMWare.

– On apprend des astuces de choix de CPU
– Rappel d'infrastructure : ajouter des CPUs ne suffit pas !
(cf loi d'Amdhal)
– Il faut un kernel récent pour un CPU récent !
– Ne pas sous-estimer les périphériques (réseau, RAM, disque, ...)
● Ressources
– https://en.wikipedia.org/wiki/Haswell_%28microarchitecture%29
– http://tof.canardpc.com/view/f554e5e4-3331-4423-a3b3-b5d75f62f7d9.jpg
– https://fr.wikipedia.org/wiki/Loi_d%27Amdahl
– http://docs.oracle.com/cd/E19253-01/816-5166/cpustat-1m/index.html

Logstach (1/5)
● Qu'est ce que c'est
– Une nouvelle coupe, naaah
– Une chanson russe, naaah
– Un logiciel d'indexation de logs,
wiiiz, tou gagnes un t-shirt !
● Caractéristiques
– OpenSource, package en jar (jRuby) → portable
– Boîte à outils sans bonnes pratiques documentées
– « Unix Pipes and Steroids »

Logstach (2/5)
● Fonctionnement
– Inputs (tcp, syslog, any, file, …. )
– Codecs (graphite, json,
multiline → stack java - , plain, netflow)
– Filters (date, grok, geoip, mutate …)
– Output (elasticsearch, redis, syslog, nagios, …)
●
Au sujet des filtres
– Le format date est un standard ISO8601
(YYY-MM-DD), pourquoi changer ?
Une bonne idée, changer tous les loggers.
Ou demander à logstach de le faire avec des tags.
– grok, « regexp for dummies »,
des patterns clé en main tels que %url ,%ip, etc …

Logstach (3/5)
● Bonnes pratiques architecturales
– « Avoir de la donnée c'est bien, y accéder, c'est mieux »
– n briques logstach → queue → grok → elasticsearch et à côté un frontend basé sur
kibana ou
– n syslog → logstach → redis → grik → elasticsearch (+ 1 reverse proxy entre Kibana et
elasticsearch – securité - )
– Puppet fait la conf pour elasticsearch et logstach
– Piper un CustomLog apache vers fleece (dev. Gandi)
– Attention à sécuriser l'accès à elasticsearch ! La base ES est accessible sur toutes les
commandes par défaut. Un index ne se modifie pas.
– Attention à ne pas minimiser l'empreinte mémoire de logstach (ruby ….) ni l'espace
disque : 2000 evt/sec → 90 Go/jour ; tuning de JVM incontournable (java 1.7 , augmenter
la heap, ajouter les compteurs JMX, augmenter le nombre de threads, etc ….)
– Faire du tuning IP (voir les doc de LVS par exemple)
– « Peu importe le choix, fais le choix », KISS c'est mieux

Logstach (4/5)
● Logstach fait le café mais
– C'est mieux avec Kibana3 (dernière version)
– Ça ne fait pas de corrélation de logs
– Ça demande un gros traitement en
amont sur les loggers
●
Ressources
– http://logstash.net/
– http://www.elasticsearch.org/overview/kibana/
– http://logstash.net/docs/1.2.2/filters/grok
– https://github.com/Gandi/fleece
– http://www.linuxvirtualserver.org/docs/sysctl.html
– http://www.iso.org/iso/home/standards/iso8601.htm

Logstach (5/5)
– Nos clients utilisent peu ElasticSearch
– Nos clients n'ont pas vraiment la main sur leurs
loggers
– Nos clients ont peu de compétence Ruby
– Par contre, ils ne sont pas mauvais côté exploitation
d'applications en java → et multiline peut les aider
– Ils ont besoin de dashboard sur leurs logs !
– Et cela correspond bien à certains besoins de sécurité

Métrologie Disque (1/4)
● iostat, tout le monde connaît ?
– Outil issu du package de sysstat
– Bonne pratique : iostat -xm 30
● x : tous les devices
● m : de nos jours, on peut compter en Mo !
● En dessous de 30 sec, la lecture est illisible à cause
des flush de cache disque
– Sans refresh, inutile, les statistiques sont mesurées depuis
le boot de la machine
– Beaucoup de compteurs inutiles ou mal interprêtés

● Quelle information lire ?
– r|wrqm/s : nombre de merge, peu de sens
– r|wMB/s : avec les disques actuels, pas de soucis à se faire, lire plutôt r/s & w/s → à relativiser selon la
structure de fichiers : beaucoup de 4 k ou gros tablespace de base de données .....
– await : temps moyen d'attente I/O, Si 4 cœurs, on peut avoir une attente de 4.
● 20 ms sur de la swap est inadmissible, penser à killer le process
● 20 ms sur de gros fichiers, ce n'est pas gênant en ces périodes de disques avec des batteries de cache
– svctm : servicetime, temps pendant lequel il y a une écriture, valeur utilisable sur un disque IDE uniquement,
n'indique pas de ralentissement
– %util : calculé à l'époque des disques IDE
● Si <100 % : il existe des moments sans étranglement
● Si 100 % : Il y a une écriture, 20 ou 100, on ne sait pas.
– avg-cpu : moyenne sur tous les processeurs
● iowait : si un processeur attend, on monte à 100 %, cette valeur est suffisamment complexe à lire pour
Solaris décide de ne même plus l'afficher à partir de la version 10.
● loadavg : (pas dans iostat mais à comparer à iowait), si un process en cours, si attente retour IO, si attente
réseau → ce compteur est faux sous Linux

● Bonnes pratiques
– Ne pas lire les compteurs faux;-)
– Surveiller les batteries de cache
– Comparer à d'autres outils, exemple pt-diskstat de
chez Percona
– Bien faire attention à l'échantillon de données
analysées, si la valeur est prise depuis l'uptime tel un
server-status apache, ça n'est pas exploitable
– Pour cette raison : « munin est bon pour la
poubelle »

– On compte pas mal d'adminsys, pas mal formés sur le
tas, le rappel des compteurs est une bonne chose.
– Les valeurs de iostat sous Linux sont souvent fausses
ou inexploitables
● Ressources
– http://sebastien.godard.pagesperso-orange.fr/man_iostat.html
– http://www.percona.com/doc/percona-toolkit/2.1/pt-diskstats.html
– https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Docume
ntation/block?id=refs/tags/v3.13-rc3

Présentation de ansible (1/3)
● ansible est un outil d'automatisation de tâches système
– Alternative à puppet
– Pas d'agent sur les machines
– Une machine de référence et
des accès en ssh vers les
machines clientes (recyclage
possible via un control-master
bien sûr)
– Outil simple, à la demande
– Pré-requis sur les machines cibles : python / ssh
– Écriture de templates en YAML

● Regroupement de tâches par rôles
● Apprentissage des hosts sur un inventaire facter ou d'un fichier plat
● Possibilité d'installation de package via des classes mais le
gestionnaire de package est à spécifier
● Possibilité d'ajouter des handlers en fin de tâche
– Mais pas de notion de stage comme puppet
● Génère un package de configuration sur l'hôte distant puis l'applique
● Possibilité de générer des rapports d'exécution avec gdash.

– ansible n'est pas aussi abouti que puppet, mais, l'a t'on déjà dit, nos
clients n'utilisent pas puppet
– ansible est KISS, demande peu de chose
– ansible est proche dans le design de « reference-tools » que
les anciens worldliners ont bien connu
– ansible est utilisé par les adminsys de Société Générale.
● Ressources
– http://www.ansibleworks.com/
– https://github.com/ansible/ansible
– https://github.com/ripienaar/gdash

Conclusion
●
Le métier de sysadmin chez Techsys a encore de belles opportunités à venir malgré la
couleur middleware qui a tendance à s'inscrire ces dernières années
●
Mais il faut trouver des clients prêts à investir du temps et des moyens dans des solutions
opensource peut-être pas encore assez matures pour eux,
●
Et les convaincre de l'intérêt de les choisir :
– foreman, puppet, logstach, ansible
●
Les rappels pour les vieux dinosaures n'étaient pas superflus
– iostat, architecture CPU
●
On regrettera
– L'annulation des conférences de Stéphane Bortzmeyer sur DNSSEC et DANE
●
Bonne idée d'y retourner !
●
Ressources
– http://sysadmin.asyd.net/
– http://frsag.org/mailman/listinfo/frsag

Sysadmin Day #5

Contenu connexe

Tendances

En vedette

Similaire à Sysadmin Day #5

Dernier

Sysadmin Day #5