Formation linux temps réel - Rennes 14 octobre 2014eurogicielgroup
Ces sessions de formation abordent l'ensemble des problématiques temps réel en environnement GNU/Linux, des couches basses du noyau jusqu'aux applications utilisateur. Les API Linux et POSIX-RT sont étudiées. Elles s'adressent aux développeurs souhaitant utiliser Linux pour des applications temps réel. Les travaux pratiques intègrent l'utilisation des outils de l'environnement GNU/Linux pour la mise au point et l'analyse du temps-réel.
Formation linux temps réel - Rennes 14 octobre 2014eurogicielgroup
Ces sessions de formation abordent l'ensemble des problématiques temps réel en environnement GNU/Linux, des couches basses du noyau jusqu'aux applications utilisateur. Les API Linux et POSIX-RT sont étudiées. Elles s'adressent aux développeurs souhaitant utiliser Linux pour des applications temps réel. Les travaux pratiques intègrent l'utilisation des outils de l'environnement GNU/Linux pour la mise au point et l'analyse du temps-réel.
Virtualiastion des systèmes d'exploitations :
Installation et administration
Journée Logiciel Libre à la Faculté des Sciences Dhar El Mahraz.
Par KHAMILICH Jamal
Virtualiastion des systèmes d'exploitations :
Installation et administration
Journée Logiciel Libre à la Faculté des Sciences Dhar El Mahraz.
Par KHAMILICH Jamal
Présentation de Mme Asma MELLOULI Directeur de l’Innovation à la BFPME et de M. Jean Luc DANIEL de la Direction du développement et de la stratégie du groupe OSEO au Jeudis de l'Entrepreneur de l'ATUGE le jeudi 23 février 2012 à l'IACE.
Seminario de actualización fiscal 2015 para asociacionesGeasoc
Seminario de actualización fiscal 2015 para asociaciones realizado por Geasoc, asesoria fiscal y contable asociaciones, fundaciones y otros emprendedores sociales.
www.geasoc.es
Discussion continuum - La révolution biotechnologiqueXplore Health
La biotechnologie nous permet de comprendre les caractéristiques les plus intimes d’un être vivant — son code génétique — et même de les modifier. Mais dans quelle mesure les scientifiques devraient-ils être autorisés à modifier et à créer des êtres vivants? Quelles restrictions devraient être mises en place en ce qui concerne la sélection et l’implantation des embryons? Comment la biotechnologie affecte-elle les pays en développement? Dans quelle mesure avons-nous le droit de connaître ou de ne pas connaître les prédispositions génétiques à la maladie? Qui devrait assumer le coût de transfert de cette information génétique?
Des groupes de 8 à 12 étudiants débattent sur les questions soulevées par chaque affirmation proposée et choisissent la position des cartes entre « D’accord » et « Pas d’accord ». Des groupes plus nombreux peuvent utiliser cet outil pour entamer une discussion libre sur le sujet. Il est également possible de demander aux étudiants de travailler de façon plus formelle ou en plus petits groupes.
Document de formation[FR] pour l'apprentissage de Archlinux et la protection de l'information. Intégration d'environnement de travail et de suite logicielle(calcul scientifique, virtualisation, gestion biblio, gestionnaire mot de passe, etc..) pour l'internet des objets avec l'Open Source Hardware (Arduino, RaspberryPi). Optimisation IDE sous langage de programmation en python.
Tout ce que vous devez savoir sur les meilleures pratiques autour d'Exchange 2013... Des thèmes aussi divers que "comment virtualiser au mieux un serveur Exchange 2013" à "Que faire de mes dossiers partagés et que deviennent t'ils dans Exchange 2013". Tout ce qu'il y a à savoir expliqu par nos meilleurs experts Microsoft sur le sujet.
Speaker : Guy Groeneveld (Microsoft), Stefan Plizga (Microsoft), Raquel Municio (Microsoft France), Lionel Constantin (Microsoft France)
Le domaine des architectures reconfigurables est un domaine en extension il est nécessaire de faire des travaux de recherches sur :Architectures basse consommation de puissance (Low- Power)Architectures hétérogène (HARD + SOFT)Co-conception (Co-Design)Outils d’estimation de performances haut niveauOutils d’exploration de l’espace de conception
PHP jouit parfois d'une mauvaise réputation au niveau des performances. Nous verrons si cette réputation est méritée, si les performances sont réellement un problème pour utiliser PHP.
PHP a une architecture qui lui permet de monter en charge sans mettre en place des solutions complexes. Entre l'installation, la configuration et les possibilités au niveau applicatif, cette session vous permettra de répondre efficacement à la problématique des performances.
La nouvelle version du Framework .NET apporte des innovations majeures qui permettent encore plus de performance et accroissent le champ des possibles. Du poste client au serveur d’entreprise, ce jeu de nouvelles fonctionnalités logée au cœur du noyau vous offrent une gestion plus fine de votre code et donnent un nouveau souffle à vos applications. Ne manquez pas cette session et venez découvrir comment augmenter considérablement les performances de vos programmes et tirer parti de toute la puissance des ordinateurs modernes.
L’équipe du projet BeBoP a proposé un webinaire le 30 mai 2024 pour découvrir comment la technologie vidéo, combinée à l’intelligence artificielle, se met au service de l’analyse du comportement des taurillons.
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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