sysadmin #5 (day 1)
● Puppet et Foreman, par Romain Vigraud
● Les CPUs pour les nuls, par François Tigeot et Fabrice
Bacch...
Puppet et foreman (1/5)
● Foreman est un outil de gestion des cycles de vie des serveurs
– Génération de dashboard de plan...
Puppet et foreman (2/5)
● Le fonctionnement est modulaire
– Une BDD (PostgreSQL, MySQL, SQLite)
– Des smart-proxy pour int...
Puppet et foreman (3/5)
● L'orchestration de Foreman permet d'automatiser des
tâches Puppet
– Bootstrap DHCP/TFTP/etc ….
–...
Puppet et foreman (4/5)
● Authentification RBAC
● Gestion des « locations »
● Plugins
– discovery, hubotnotify, bootdisk
●...
Puppet et foreman (5/5)
● Et Techsys dans tout çà ?
– Nos clients n'utilisent pas encore Puppet … (ni même
Ruby)
– Interfa...
Les CPUs pour les nuls (1/5)
● Un peu d'histoire
– 1981 : un processeur x86 (un chipset « simple »)
– 1995 : SMP (Symmetri...
Les CPUs pour les nuls (2/5)
● La course aux performances
– Un Xeon permet un gain de 100 % sur une base SQL qui ne fait q...
Les CPUs pour les nuls (3/5)
● Le futur des CPUs 1 cœur x86 =>
– Superpipelines
– Architecture horizontale pour répartir l...
Les CPUs pour les nuls (4/5)
● « Le processeur le plus performant n'existe pas ! »
– Peu d'intérêt pour l'hyperthreading d...
Les CPUs pour les nuls (5/5)
● Et Techsys dans tout çà ?
– On apprend des astuces de choix de CPU
– Rappel d'infrastructur...
Logstach (1/5)
● Qu'est ce que c'est
– Une nouvelle coupe, naaah
– Une chanson russe, naaah
– Un logiciel d'indexation de ...
Logstach (2/5)
● Fonctionnement
– Inputs (tcp, syslog, any, file, …. )
– Codecs (graphite, json,
multiline → stack java - ...
Logstach (3/5)
● Bonnes pratiques architecturales
– « Avoir de la donnée c'est bien, y accéder, c'est mieux »
– n briques ...
Logstach (4/5)
● Logstach fait le café mais
– C'est mieux avec Kibana3 (dernière version)
– Ça ne fait pas de corrélation ...
Logstach (5/5)
● Et Techsys dans tout çà ?
– Nos clients utilisent peu ElasticSearch
– Nos clients n'ont pas vraiment la m...
Métrologie Disque (1/4)
● iostat, tout le monde connaît ?
– Outil issu du package de sysstat
– Bonne pratique : iostat -xm...
Métrologie Disque (2/4)
● Quelle information lire ?
– r|wrqm/s : nombre de merge, peu de sens
– r|wMB/s : avec les disques...
Métrologie Disque (3/4)
● Bonnes pratiques
– Ne pas lire les compteurs faux;-)
– Surveiller les batteries de cache
– Compa...
Métrologie Disque (4/4)
● Et Techsys dans tout çà ?
– On compte pas mal d'adminsys, pas mal formés sur le
tas, le rappel d...
Présentation de ansible (1/3)
● ansible est un outil d'automatisation de tâches système
– Alternative à puppet
– Pas d'age...
Présentation de ansible (2/3)
● Regroupement de tâches par rôles
● Apprentissage des hosts sur un inventaire facter ou d'u...
Présentation de ansible (3/3)
● Et Techsys dans tout çà ?
– ansible n'est pas aussi abouti que puppet, mais, l'a t'on déjà...
Conclusion
●
Le métier de sysadmin chez Techsys a encore de belles opportunités à venir malgré la
couleur middleware qui a...
Prochain SlideShare
Chargement dans…5
×

Sysadmin Day #5

240 vues

Publié le

Quelques notes prises lors du Sysadmin Day #5 à l'ICAM, Paris.

Publié dans : Ingénierie
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
240
Sur SlideShare
0
Issues des intégrations
0
Intégrations
7
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Sysadmin Day #5

  1. 1. 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
  2. 2. 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
  3. 3. Puppet et foreman (2/5) ● 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
  4. 4. Puppet et foreman (3/5) ● 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
  5. 5. Puppet et foreman (4/5) ● 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
  6. 6. Puppet et foreman (5/5) ● 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/
  7. 7. 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
  8. 8. Les CPUs pour les nuls (2/5) ● 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 !
  9. 9. Les CPUs pour les nuls (3/5) ● 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
  10. 10. Les CPUs pour les nuls (4/5) ● « 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.
  11. 11. Les CPUs pour les nuls (5/5) ● Et Techsys dans tout çà ? – 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
  12. 12. 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 »
  13. 13. 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 …
  14. 14. 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
  15. 15. 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
  16. 16. Logstach (5/5) ● Et Techsys dans tout çà ? – 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é
  17. 17. 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
  18. 18. Métrologie Disque (2/4) ● 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
  19. 19. Métrologie Disque (3/4) ● 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 »
  20. 20. Métrologie Disque (4/4) ● Et Techsys dans tout çà ? – 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
  21. 21. 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
  22. 22. Présentation de ansible (2/3) ● 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.
  23. 23. Présentation de ansible (3/3) ● Et Techsys dans tout çà ? – 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
  24. 24. 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

×