Installation et Configuration Centralisées et Automatisées d une Ferme de Serveur sous SLC6

Transcription

1 Institut Supérieur d Informatique, de Modélisation et de leurs Applications Organisation Européenne pour la Recherche Nucléaire F CERN Cedex BP Aubière Cedex CERN-THESIS /09/2012 Installation et Configuration Centralisées et Automatisées d une Ferme de Serveur sous SLC6 Stéphane Tourneyre Rapport de Stage de 2 eme Année Filière Réseau et Télécommunication 2 Avril 31 Aout 2012 Tuteur CERN : Niko Neufeld Tuteur ISIMA : Emmanuel Mesnard

2

3 Remerciements Je tiens à remercier : Niko Neufeld, mon tuteur, pour la confiance qu il a placé en moi, sa bonne humeur et sa disponibilité malgré son emploi du temps chargé. Loïc Brardra pour le temps qu il m a accordé pour répondre à mes (trop?) nombreuses questions L équipe du LHCb qui m a permis de mieux comprendre le fonctionnement du CERN et du LHCb en particulier Monsieur Menard qui a permis d ouvrir la brèche et de donner la chance à des stagiaires de l ISIMA de pouvoir effectuer leur stage au sein du CERN

4 Résumé Ce rapport a pour but de présenter une étude du changement du système d installation et de configuration de serveurs Linux équipés de la distribution Scientific Linux CERN (SLC) au sein de l expérience LHCb du CERN. Ces serveurs servent essentiellement à trier les données en sortie des différents capteurs des détecteurs de collisions de protons. Il était prévu d étudier une solution à base des logiciels Cobbler/Puppet pour remplacer le logiciel existant, Quattor, pour permettre d installer et de configurer de façon automatique. Tout d abord, ces tests devaient se faire sur des machines virtuelles puis mettre ces outils en condition réelle avec des machines sans disque dur, comme celles en production. À l heure actuelle, l utilisation du logiciel pour permettre la configuration automatise Puppet fonctionne et correspond aux attentes du responsable du projet, Niko Neufeld. Concernant Cobbler, après différents tests, il ne parvient pas à combler totalement nos attentes. C est pourquoi une étude approfondie doit être continuée soit en trouvant un autre logiciel, soit en adaptant Cobbler. Pour la partie des machines sans disque dur, elle devrait pouvoir être finie avant la fin du stage. Mot clé : installation et configuration automatisée, Cobbler, Puppet, Quattor, sans disque dur.

5 Abstract This report aims to present a study of the change of system installation and configuration of Linux servers with the distribution of Scientific Linux CERN (SLC) within the LHCb experiment at CERN. These servers are primarily used to sort the output data of various sensors detectors proton collisions. It was planned to explore a solution based software Cobbler / Puppet to replace the existing software, Quattor, to help install and configure automatically. First, these tests should be done on virtual machines and then putting these tools in real conditions with machines without hard disk, such as those in production. Currently, the use of software to allow configuration automates Puppet works and meets the expectations of the project manager, Niko Neufeld. Cobbler on, after various tests, it fails to meet our expectations fully. Therefore a thorough study should be continued or finding another software or by adapting Cobbler. For the part of the machines without hard disk, it should be done before the end of the course. Keyword: automated installation and configuration, Cobbler, Puppet, Quattor, diskless.

6 Tables des matières REMERCIEMENTS...III RESUME... IV ABSTRACT... V TABLES DES MATIERES... VI TABLE DES FIGURES... VII GLOSSAIRE... IX INTRODUCTION I. LE CONTEXTE ) Le CERN ) Le LHC ) LHCb ) L avenir de l informatique au CERN ) Le projet II. CONFIGURATION AUTOMATISEE AVEC PUPPET ) Définition de Puppet ) Principe de Puppet ) Configuration au LHCb : III. INSTALLATION AUTOMATISEE AVEC COBBLER ) Définition de Cobbler ) Principe de Cobbler IV. INTERCONNEXION PUPPET COBBLER ) Lien entre Puppet et Cobbler ) Remplacement de Cobbler? ) Razor ) La solution V. MACHINE DISKLESS ) Principe ) Problèmes ) Diskless avec Cobbler CONCLUSION REFERENCES BIBLIOGRAPHIQUES...LXVI

7 Table des figures FIGURE 1 : LE LHC DANS LE PAYS DE GEX FIGURE 2 : LE DETECTEUR ET UNE PARTIE DE L'EQUIPE DU LHCB FIGURE 3 : SERVEURS FAISANT PARTIE DE LA FERME FIGURE 4 : EXEMPLE DE LANGAGE PAN DE QUATTOR FIGURE 5 : PLANNING PREVISIONNEL FIGURE 6 : EXEMPLE D'ENTREPRISE UTILISANT PUPPET FIGURE 7 : INSTALLATION DU PACKAGE PUPPET-SERVER FIGURE 8 : INSTALLATION DU PACKAGE CLIENT FIGURE 9 : STRUCTURE DE PUPPET FIGURE 10 : FICHIER PUPPET.CONF FIGURE 11 : FICHIER NODE.PP FIGURE 12 : CHOIX DU MODULE EN FONCTION DU NŒUD FIGURE 13 : PREMIERE CONNEXION D'UN CLIENT VU PAR LE SERVEUR FIGURE 14 : PREMIERE CONNEXION D UN CLIENT VU PAR LE CLIENT FIGURE 15 : FONCTIONNEMENT DE PUPPET FIGURE 16 : STRUCTURE D'UNE RESSOURCE FIGURE 17 : CONFIGURATION DE YUM FIGURE 18 : STRUCTURE MODULE PUPPET FIGURE 19 : FICHIER INIT.PP DU MODULE PUPPET FIGURE 20 : FICHIER INSTALL DU MODULE PUPPET FIGURE 21 : FICHIER SERVICE DU MODULE PUPPET FIGURE 22 : UTILISATION DE VARIABLE DANS PUPPET FIGURE 23 : RESULTAT DE LA COMMANDE FACTER FIGURE 24 : CHOIX D'UNE CLASSE EN FONCTION DE L'OS FIGURE 25 : EXEMPLE DE FICHIER TEMPLATE FIGURE 26 : FICHIER TEMPLATE MACHINE A FIGURE 27 : FICHIER TEMPLATE MACHINE B FIGURE 28 : STRUCTURE DE PUPPET AVEC TROIS ENVIRONNEMENTS FIGURE 29 : ENVIRONNEMENTS DANS LE FICHIER PUPPET.CONF FIGURE 30 : EXECUTION DE PUPPET DANS UN ENVIRONNEMENT PARTICULIER FIGURE 31 : EXECUTION DE PUPPETMASTER FIGURE 32 : EXECUTION DE PUPPET CLIENT FIGURE 33 : EXECUTION DU SCRIPT SITE.PP FIGURE 34 : EXEMPLE DE MODULE DISPONIBLE SUR LE SITE PUPPET FORGE FIGURE 35 : LIGNE DE COMMANDE PARAMETRANT LE PROXY FIGURE 36 : FICHIER /ETC/BASHRC FIGURE 37 : STRUCTURE DU FICHIER NODE.PP FIGURE 38 : ARBORESCENCE DU MODULE PROXY FIGURE 39 : STRUCTURE DU FICHIER INIT.PP DU MODULE PROXY FIGURE 40 : STRUCTURE DU SCRIPT DU MODULE PROXY FIGURE 41 : SEQUENCE DE DEMARRAGE D'UN CLIENT FIGURE 42: CONFIGURATION DHCP DU POSTE CLIENT FIGURE 43 : TENTATIVE DE RECUPERATION DU FICHIER PXELINUX.CFG FIGURE 44 : COBBLER FIGURE 45 : INSTALLATION DE COBBLER FIGURE 46 : FICHIER SEETINGS DE COBBLER FIGURE 47 : GESTION DU DHCP PAR COBBLER FIGURE 48 : CHOIX DU SERVEUR DHCP DANS MODULE.CONF FIGURE 49 : TEMPLATE DU FICHIER DHCPD.CONF FIGURE 50 : FICHIER KICKSTART FIGURE 51 : IMPORT D'UN REPOSITORY SOUS COBBLER FIGURE 52 : SYNCHRONISATION DES REPOSITORY... 46

8 FIGURE 53 : IMPORTATION DE LA DISTRIBUTION SLC6 DEPUIS LE FICHIER BOOT.ISO FIGURE 54 : STRUCTURE D'UN PROFIL FIGURE 55 : AJOUT D'UN SYSTEM FIGURE 56 : RESULTAT DE LA COMMANDE COBBLER SYNC FIGURE 57 : CLIENT RECUPERANT DES FICHIERS SUR LE SERVEUR PXE FIGURE 58 : MANAGEMENT CLASSES AU SEIN DE COBBLER FIGURE 59 : REPONSE DU SCRIPT EN FONCTION D'UN CLIENT FIGURE 60 : CONFIGURATION DU FICHIER PUPPET.CONF FIGURE 61 : SCRIPT EXTERNAL FIGURE 62 : RAZOR DISCOVERY FIGURE 63 : LISTE DES NŒUDS SUR RAZOR FIGURE 64 : ATTRIBUT D'UN NODE SUR RAZOR FIGURE 65 : RAZOR TAGGING FIGURE 66 : RAZOR POLICY FIGURE 67 : RAZOR POLICY FIGURE 68 : RAZOR BROKER FIGURE 69 : LISTE DES BROKER FIGURE 70 : POLITIQUES SUR RAZOR AVEC "BROKER" FIGURE 71 : AJOUT D'UNE MACHINE SUR COBBLER FIGURE 72 : FICHIER SITE.PP FIGURE 73 : FICHIER CLIENT1.LBDAQ.CERN.CH.PP FIGURE 74 : FICHIER KICKSTART AVEC SCRIPT PHP FIGURE 75 : SCRIPT PHP POUR CREER LE FICHIER HOSTNAME.PP FIGURE 76 : SERVEUR CENTRAL ET CLIENT DISKLESS FIGURE 77 : LISTE DES DOSSIERS DU SERVEUR CENTRAL DISKLESS FIGURE 78 : LISTE DES DOSSIERS SPECIFIQUE MACHINE DISKLESS FIGURE 79 : DIAGRAMME DE GANT FINAL... 65

9 Glossaire Annuaire: Système de stockage de données Antimatière: Particule en opposition de la matière qui devrait être en égal quantité en théorie mais qui se révèle en total asymétrie dans l univers. Le LHCb devrait réussir à répondre a cette question Cloud Computing: Concept de déportation sur des serveurs distants les serveurs ou postes clients locaux Cobbler: Logiciel d installation automatisée et centralisée DHCP: Logiciel fournissant automatiquement une adresse IP aux machines qui le demande Diskless: Machine sans disque dur DNS: Protocole permettant de relier une adresse IP d une machine à son nom HTTP: Langage des sites web. Souvent utilisé pour un logiciel de serveur web ( exemple : Apache, IIS, WEBrick ) IP: Adresse unique sur un réseau d une machine permettant la communication avec les autres machines Kickstart: Fichier de réponse automatique lors de l installation des distributions RedHat/Fedora Ldap: Protocole utilisé pour l interrogation et la modification d annuaire. Les plus connus sont Active Directory et OpenLDAP Linux: Système d exploitation (OS pour Operating System ) très prisé des laboratoires de recherche de par sa gratuité et son ouverture. Deux distributions en sont dérivées : RedHat / Fedora et associé ( CentOS, Scientific Linux) et Debian/Ubuntu OpenStack: Solution logiciel permettant de gérer un Cloud Computing Packages: Archive comprenant les fichiers nécessaires à l installation d un logiciel Puppet: Logiciel de configuration automatisée et centralisée Quattor: Logiciel d installation et de configuration automatisées et centralisées Repository: Stockage centralisé de package

10 Serveur web : machine permettant à des clients d afficher un site web via des requêtes HTTP Template: Utilisation d un fichier générique pour la création d un fichier spécifique grâce à des variables TFTP: Protocole de serveur de fichier Virtualbox: logiciel de virtualisation de poste client Virtualisation: Concept permettant de simuler un système d exploitation sur une machine physique VMware: Solution logiciel de virtualisation Yum: Gestionnaire de paquets Linux pour les distributions RedHat/Fedora

11 Introduction Introduction Afin de traiter tous les résultats obtenus des nombreux capteurs lors des collisions au sein du LHC, l expérience LHCb du CERN a besoin d une puissance de calcul phénoménal : une ferme de serveurs de plus de deux mille machines. Pour administrer toutes ces machines, il est indispensable d avoir des outils adaptés et surtout qui permettent une automatisation la plus poussée possible. Pour installer et configurer les machines de façon centralisée et automatisée, les administrateurs système utilisent le logiciel Quattor. Malgré de nombreux atouts, il n est plus adapté aux besoins futurs du CERN et en particulier de l expérience LHCb. C est pourquoi il est important d anticiper et de trouver une solution équivalente. C est le sujet de mon stage. Ce rapport comporte quatre parties : Avant de changer quoi que ce soit, il est très important de connaitre l existant. C est pourquoi une présentation détaillée du contexte est effectuée avec les différentes solutions possibles. Puis une étude du logiciel Puppet qui sert à automatiser et centraliser les configurations des différents serveurs. Enfin, je vais mettre en place le logiciel Cobbler pour l installation des machines et voir s il arrive bien à s interconnecter avec Puppet. Ceci est une première version du rapport de stage : la version finale définitive devrait comporter une partie sur les machines sans disque dur. Page 11

12 Le Contexte I. Le Contexte 1) Le CERN Question : Quel est l endroit le plus chaud et à la fois le plus froid sur terre? Réponse : au LHC du CERN Avec une température de -271degrés pour pouvoir utiliser des supraconducteurs et une autre de plus de 10 millions de degrés lors des collisions des protons, le LHC du CERN nous prouve encore une fois que c est une merveille de technologie. Crée en 1954 à la suite de la 2 eme guerre mondiale, l Organisation Européenne pour la Recherche Nucléaire (l acronyme CERN vient du 1er nom Conseil Européen pour la recherche nucléaire) est le plus grand centre de physique du monde. Situé sur la frontière entre la France et la Suisse, près de Genève, c est la plus grande concentration de physiciens du monde avec plus de quatorze mille personnes sur le site lors des grandes affluences. Le CERN a quatre buts principaux : Recherche fondamentale de physique : Grâce à l accélérateur de particules Large Hadron Collider (Grand Collisionneur de Hadron - LHC), des collisions entre différentes particules permettent de recréer les instants qui ont succédé au Bigbang et ainsi mieux connaitre la physique. La conférence sur la découverte du Boson de Higgs du 4 juillet 2012 est le parfait exemple. Faire avancer la science Toutes les découvertes du CERN sont publiques et gratuites. C est ainsi que le protocole HTTP inventé en 1989 par Tim Berners Lee a permis à Internet de se démocratiser. Mais aussi le système de grille de calcul qui permet de répartir des calculs informatiques lourds entre plusieurs dizaines, centaines ou même milliers de machines. Former les scientifiques de demain En permettant à des stagiaires ou des étudiants de pouvoir continuer leurs apprentissages ici, le CERN s assure de former les générations futures. Page 12

13 Le Contexte Collaboration entre les différents pays À sa façon le CERN, collabore pour la paix dans le monde. En effet, les différents scientifiques travaillent ensemble et mettent de côté leurs différents pour faire avancer la science. Le financement du CERN provient essentiellement des douze états fondateurs (Allemagne, France, Danemark, Italie, Norvège etc...), des douze autres états membres qui les ont rejoints au fil du temps (Pologne, Bulgarie, Portugal etc...) mais aussi d autres états observateurs (Inde, Japon, Turquie etc...). 2) Le LHC Basé sur la structure de l ancien Grand collisionneur de positons et d électrons (le LEP), le LHC est le plus puissant accélérateur de particules du monde et cela devrait encore s accroitre avec la montée en puissance prévue pour l année Le principe du LHC est très simple : envoyer des protons dans un anneau large de vingt-sept kilomètres à une vitesse proche de celle de la lumière et examiner les collisions des particules au sein de différents détecteurs. Le but est de confirmer ou non certaines théories et de comprendre la naissance de la physique fondamentale. On peut trouver quatre grandes expériences qui correspondent chacune à un détecteur différent : ATLAS, CMS, ALICE et LHCb. Figure 1 : Le LHC dans le pays de Gex Page 13

14 Le Contexte 3) LHCb LHCb pour Large Hadron Collider beauty Le but de l expérience LHCb est d étudier la particule de Beauté qui permettrait d expliquer pourquoi il y a une dissymétrie entre la matière et l antimatière dans l Univers. L expérience regroupe près de sept cents physiciens et autres issus de quinze pays. Figure 2 : le Détecteur et une partie de l'équipe du LHCb Le détecteur est en réalité constitué de plusieurs sous détecteurs permettant chacun de capturer des informations sur une particule (Calorimètre, Rich etc...) et le flux de données en sortie est très important : 50mo/s pour chaque collision. Etant donné qu il y a quatre millions de collisions par seconde, il est impératif de pouvoir trier ces informations avant que les physiciens puissent travailler sur les résultats. Ce tri s effectue via deux niveaux (le niveau zéro et le niveau un) et permet de séparer le bruit des données intéressantes. Le niveau zéro (Level 0 Trigger) est constitué de cartes électroniques spécialisées qui permettent de passer de quatre millions d événements à 2 millions. Le niveau un (HLT pour Hight Level Trigger) est constitué d une ferme de plus de deux mille serveurs. La particularité de ces serveurs est d être diskless (sans disque) et ils utilisent des stockages réseaux pour fonctionner. Cinquante de ces serveurs sont utilisés pour gérer jusqu à vingt-sept nœuds (serveurs clients) Page 14

15 Le Contexte Figure 3 : Serveurs faisant partie de la ferme Ce triage permet de passer de quatre Millions d évènements à deux mille. Ces données sont traitées par les physiciens ensuite. À l heure actuelle, ces serveurs sont sous la distribution Linux SLC 5 (Scientifique Linux CERN version 5) dérivée de RHEL 5 (Red Hat Entreprise Linux version 5). Avec une équipe d administration réduite, il est indispensable d avoir des outils permettant une automatisation d installations et de configurations des machines Linux. Le choix du CERN et du LHCb en particulier s est porté sur Quattor. Quattor est un logiciel Open Source fonctionnant sous Linux basé sur un langage descriptif spécifique, le Pan. C est un langage compilé : avant de déployer une machine, un fichier XML est créé contenant l ensemble des configurations à mettre en place. Il existe peu d entités utilisant Quattor : principalement le CERN et la banque Margan Stanley. De par ce fait, la communauté autour de Quattor n est pas très importante. Page 15

16 Le Contexte Avantages de Quattor : Figure 4 : Exemple de langage PAN de Quattor Langage facile à prendre en main Modularité des composants Code ouvert Inconvénients : Communauté restreinte Gestion des packages (l installation de packages se fait via un fichier RPM et il faut gérer manuellement ses dépendances). Malgré le fait que Quattor soit plutôt bien adapté au système d information du CERN, il reste néanmoins perfectible. 4) L avenir de l informatique au CERN Les différentes expériences sont des services informatiques indépendants les uns des autres, mais aussi du service informatique général du CERN (généralement appelle IT pour Information Technologique). Malgré leur indépendance, chacun s inspire des autres et ainsi tout le monde marche plus ou moins dans le même sens, ou au moins, essaye les technologies sans forcément y adhérer. C est dans cette optique que le LHCb a commencé une réflexion sur le changement du système d information : Page 16

17 Le Contexte Les besoins techniques de l IT et des expériences sont en constantes évolution en terme de puissance de calcul sans devoir augmenter le personnel dédié. La solution retenue est de délocaliser un certain nombre de serveurs dans un Datacenter à Budapest en Hongrie. La gestion physique sera faite par une équipe sur place quand la gestion des logiciels (administration des serveurs) sera toujours effectuée par les équipes du CERN. De plus, cela permet de passer tous les serveurs en virtualisation ce qui ajoute en flexibilité et réduit les coûts. Ce système d infrastructure déportée est ce qu on appelle de nos jours le Cloud computing. Malheureusement, en plus des inconvénients précédemment cités, Quattor gère très mal les machines virtuelles. C est pourquoi une réflexion s est portée sur un outil permettant la configuration mais aussi sur un outil de service d infrastructure. De plus, la migration de SLC à SLC6 à court et moyen terme est un facteur déclenchant pour le changement d infrastructure. Même si les besoins de virtualisation sont moindres voir quasi nuls au sein du LHCb, il est quand même intéressant de se faire la même réflexion afin de faire évoluer leur système. 5) Le projet Le but du projet est de tester un des outils d installation de serveurs et un outil de gestion de configuration ainsi que d étudier leurs intégrations au sein de la ferme de calculs. Il est prévu que ces outils soient mis en production suite à ce projet. a) Le choix des outils Il n existe pas des millions d outils pour gérer un Cloud comme celui du CERN. De plus, de par sa nature de service public, d ouverture et de coûts, cet outil doit être un logiciel libre. OpenStack est naturellement imposé de par sa pérennité (de nombreux organisations/entreprises ont choisi OpenStack : la NASA à l origine du projet mais aussi AT&T, Korea Telecom, HP Public Cloud etc...) mais aussi pour sa modularité (l ensemble des outils sont interopérable avec les grandes solutions de virtualisation du marché : VM Ware, HV de Microsoft etc...). OpenStack commence à s imposer de plus en plus dans le Cloud. Concernant la gestion de configuration, étant donné que cela devait remplacer Quattor, il était judicieux de trouver un logiciel ayant la même philosophie : déclaratif, etc... Tout en comblant ses inconvénients : gestion des packages avancée, communautés actives etc... Page 17

18 Le Contexte Tout comme OpenStack, un logiciel s est plus ou moins imposé, surtout pour sa complémentarité avec OpenStack : Puppet de PuppetLabs. Il existe d autres logiciel comme Chef ou CFEngine mais ils sont soit trop jeunes soit dans une autre approche que Quattor, mais au cas où Puppet ne convienne pas, il serait intéressant de les regarder de plus près. Pour l installation des serveurs, aucun outil n n a été privilégié par rapport à un autre. Il m incombe de trouver la solution s intégrant le plus possible avec Puppet. Mon tuteur m a conseillé d étudier en premier le logiciel Cobbler. Si celuici ne convenait pas, je devrais étudier les différentes solutions. L ensemble de mes tests se sont effectués soit sur des machines virtuelles locales sous VirtualBox, soit sur des machines virtuelles RedHat : RedHat Entreprise Virtualization (c est un hyperviseur permettant de manager ces machines virtuelles). Le plus gros du travail n est finalement pas la mise en place de ces outils mais surtout de comprendre leurs fonctionnements. b) Diagramme de Gantt : Figure 5 : Planning prévisionnel Ce planning se décompose en 4 grandes parties avec chacune une partie découverte du produit, test sur une machine virtuel local et test sur une machine virtuel de production : Puppet Cobbler Machine Diskless Résultats Finaux Page 18

19 Configuration automatisée avec Puppet II. Configuration automatisée avec Puppet Un dicton dans l administration système et réseau dit Plus tu ruses, moins tu t uses. 1) Définition de Puppet C est exactement cela que permet Puppet : ruser pour éviter les tâches répétitives grâce à un outil d administration centralisé de parc de machines pour automatiser, harmoniser et homogénéiser les configurations pour gagner du temps, de la flexibilité et des performances. Certes au départ cela demande un travail supplémentaire pour déclarer l ensemble des machines. Mais une fois ce travail fait, l ajout d une nouvelle machine est plus beaucoup plus rapide et surtout, on est sûr que chaque machine a la bonne configuration. L inconvénient d un tel système est que lorsque la configuration est bonne, cela marche très bien mais lors d une erreur, ce n est plus une machine mais potentiellement l ensemble du parc qui peut être impacté. C est pourquoi c est un outil à magner avec délicatesse. Ecrit en langage RUBY sous licence GPLv2, la version actuelle est la 2.7 et est diffusée/écrite par PuppetLabs depuis Le serveur et le client fonctionnent avec Linux mais Puppet n est pas seulement limité au monde linux (Debian / RedHat) : il existe un client pour les machines MacOs et, fait très intéressant, Windows. L ensemble de la documentation et des ressources se trouvent sur le site officiel de Puppet [1]. De plus, un ouvrage m a grandement aidé : ProPuppet [2]. De nombreuses sociétés, dont certaines parmi les plus grandes du monde internet, utilisent Puppet et en font la promotion ce qui lui garantit une durée de vie confortable. Page 19

20 Configuration automatisée avec Puppet Figure 6 : Exemple d'entreprise utilisant Puppet Philosophie : Ne pas dire comment, dire quoi faire. a) Installation de Puppet 2) Principe de Puppet Sur une distribution SLC, une ligne de commande permet d installer le PuppetMaster ou l agent avec toutes ses dépendances : Figure 7 : Installation du package puppet-server Figure 8 : Installation du package client Parmi ses dépendances, on retrouve les packages Ruby qui permettent d interpréter Puppet mais aussi un package Facter qui fournira les «facts» du client (expliqué après) Page 20

21 Configuration automatisée avec Puppet b) Structure de Puppet Figure 9 : Structure de Puppet Ci-dessus, on trouve la structure de base de Puppet en incorporant un module Yum. Les fichiers de configuration se trouvent à la racine de puppet dans /etc/puppet : puppet.conf, auth.conf et autosign.conf. Le fichier puppet.conf contient la configuration utilisée par Puppet, que ce soit le client (partie [agent]), le serveur (partie [master]) ou pour les deux (partie [main]). C est ici qu est spécifié, s il y a besoin, le nom du serveur, l intervalle entre chaque demande du client au serveur, etc.... Dans notre cas, la configuration par défaut nous convient. Figure 10 : Fichier puppet.conf Le fichier auth.conf permet de spécifier quel client (appelé Nœud) aura accès à quel module. Dans notre cas, on laisse les paramètres par défaut : tous les nœuds auront accès à tous les modules. Page 21

22 Configuration automatisée avec Puppet Le fichier autosign.conf gère l auto signature de certificat pour la 1ere connexion des clients. Il est possible de laisser ce fichier vide et ainsi, pour chaque nœud, l administrateur devra accepter manuellement le certificat. Dans notre cas, nous allons auto signer toutes les machines ayant un hostname *.lbdaq.cern.ch. Les différentes configurations sont appelées Ressource, elles sont regroupées en Class et sont écrites dans des Manifests (fichiers une extension.pp) Les deux principaux manifests sont dans /etc/puppet/manifests : site.pp et node.pp. Site.pp : Premier fichier à être lu par le serveur lors d une demande de configuration d un client. Souvent utilisé pour mettre une configuration de base. Node.pp : Afin de savoir quelle configuration doit être appliquée tel Nœud, on utilise le fichier node.pp ou est répertorié l ensemble des Noeuds du systeme. Un nœud peut hériter d un autre nœud. Figure 11 : Fichier node.pp Ici notre nœud «virttest1006.lbdaq.cern.ch» va appliquer la classe razor avec en paramètre «ruby_version» et va hériter du nœud «base» qui appliquera le module Yum. Les modules sont des classes qui peuvent être utilisées par les nœuds. L avantage d utiliser les modules est que, en fonction du nœud, on peut appliquer une configuration particulière en ayant une seule classe : la class razor sera utilisé avec le paramètres «ruby_version = 1.8.7».On peut imaginer un autre nœud avec un autre paramètre «ruby_version = 1.9.3». Page 22

23 Configuration automatisée avec Puppet Figure 12 : Choix du module en fonction du nœud PS : Il est important de configurer le pare-feu du client et du serveur pour laisser passer les trames Puppet. Etant donné que les pare-feu des machines du LHCb sont désactivés par défaut, il n y a rien à changer. Si on veut garder le pare feu activé, il faut autoriser le port c) Déploiement Sur un fonctionnement Client/Serveur, un agent installé sur le client (appelé Nœud) va demander quelle configuration a adopté le serveur maitre (appelé PuppetMaster). Une possibilité d utiliser le client seul existe en utilisant un script mais cela reste marginal et n est pas approprié à notre besoin. Les échanges se font grâce à une connexion HTTPS via un échange de clé SSL lors de la première connexion du client. Cette première connexion demande une autorisation du client sur le serveur (de façon automatique ou manuelle). Une fois acceptée, le serveur ne fait plus cette demande. Page 23

24 Configuration automatisée avec Puppet Figure 13 : Première connexion d'un client vu par le serveur Figure 14 : Première connexion d un client vu par le client d) Traitement d une configuration : Plutôt que diffuser la configuration du serveur au client, ce sont les clients qui viennent réclamer cette configuration. Cela peut porter sur un fichier, un package, un service, etc... et sur son état : présent, absent, version pour les packages etc... Il est possible de spécifier les intervalles entre les différentes demandes de chaque client ou alors, passer par une tâche planifiée sur le client afin de mieux anticiper les possibles montées en charge : avoir deux mille demandes en même temps est diffèrent d avoir deux mille clients répartis sur deux heures pour le serveur. Page 24

25 Configuration automatisée avec Puppet Une fois la demande autorisée par le serveur, ce dernier envoi la configuration à l agent et celui-ci l applique: si la configuration du serveur est identique à celle du client, aucune action n est effectuée (exemple : un logiciel déjà installé sur le client ne sera pas réinstallé). Par contre, si la configuration du client est différente de celle du serveur, celui-ci appliquera la nouvelle configuration. Ainsi, si on applique la même configuration à cinq minutes d intervalle à un client, son état restera le même : un package installé ne sera pas ré installé si la version correspond à celle spécifiée par le serveur. Voici le processus de configuration de chaque client : 1) Demande de configuration du client au serveur. Envoi de ses «facts» en même temps 2) En fonction des informations du client, les ressources sont interprétées et compilées 3) Envoi de la configuration compilée au client 4) Mise en place de cette configuration par le client avec appel aux fichiers/template au serveur si besoin 5) Envoi d un rapport au PuppetMaster Figure 15 : fonctionnement de Puppet Page 25

26 Configuration automatisée avec Puppet e) Langage de configuration Puppet utilise un langage déclaratif simple pour définir les Ressources. Le fait que ce soit du déclaratif distingue Puppet des autres logiciels de configuration. Par exemple, pour installer un package, plutôt que d indiquer la marche à suivre, on va seulement déclarer le logiciel que l on veut installer et Puppet va, en fonction de l OS ou de la distribution, installer la bonne version avec le bon installateur. Ainsi, on peut avoir une seule ressource pour plusieurs OS. L administrateur s occupe seulement du quoi et plus du comment. Exemple de code de configuration : Figure 16 : Structure d'une ressource Figure 17 : Configuration de Yum Ici, on souhaite configurer Yum avec un fichier yum.conf et des Repository spécifiques. Pour le fichier yum.conf, on remplace le fichier/etc/yum.conf par le fichier se trouvant dans/etc/puppet/module/yum/files/yum.conf Voici une liste des principaux types de Ressource, qui peuvent être regroupés en classes, eux même regroupés en modules (qui regroupe les différentes ressources et fichiers utilisés par les ressources si besoin) : Fichier Package Page 26

27 Configuration automatisée avec Puppet Cron (tache planifié) Exec (exécution d une ligne de commande) User (tout ce qui touche un utilisateur) Group (tout ce qui touche un groupe) Service Nagios (pour la configuration du logiciel de monitoring Nagios) Mount Host (gère le fichier /etc/hosts) Router (gère une interface d un routeur ou un switch) Etc Voici l exemple d un module Puppet avec plusieurs types de ressources : Figure 18 : Structure module Puppet Figure 19 : Fichier init.pp du module puppet Le fichier init.pp sera le premier fichier lu lors de l import du module puppet. Ce manifests inclus le fichier install.pp (puppet ::install) et le fichier service.pp (puppet ::service). Figure 20 : Fichier install du module puppet Le manifest puppet ::install utilise le type «package» pour installer le client Puppet. Il n y a pas besoin de spécifier l installateur (Yum, Apt ), Puppet s occupe d exécuter le code en fonction de l OS. Page 27

28 Configuration automatisée avec Puppet Figure 21 : Fichier service du module puppet Il est possible de spécifier des variables qui seront utilisés dans les ressources : Figure 22 : Utilisation de variable dans Puppet La variable $longthing est utilisée par la ressource file «authorized_keys» afin de renseigner le fichier ssh. Cette variable peut très bien être déclarée ailleurs, comme par exemple dans le fichier node.pp. Ainsi, chaque nœud peut avoir une clé ssh autorisée particulière. f) Utilisation des facts Le package de PuppetLabs Facter est un outil d inventaire system : il retourne des facts ; des variables globales, du client telle que son adresse ip, son hostname, son os et sa version etc... Ces facts peuvent être utilisés par Puppet afin de servir de variable : Figure 23 : Résultat de la commande Facter Page 28

29 Configuration automatisée avec Puppet Exemple de code avec operating-system : Figure 24 : Choix d'une classe en fonction de l'os Ici, en fonction de la distribution, on va appliquer la class apache-redhat ou apache-debian. g) Les fichiers Template Nous avons vu que nous pouvons copier des fichiers depuis le serveur Puppet. Ces fichiers sont figés et ne sont pas modifiables par Puppet. Néanmoins, certains fichiers doivent être différents sur chaque machine, même si une seule ligne les diffère. Plutôt que d avoir un fichier par machine, il est possible d utiliser les Template. Ces Template sont des fichiers qu il y possible de modifier avec des variables dans des manifests et des «facts». Figure 25 : Exemple de fichier Template Notre exemple de fichier Template permet de créer un fichier sur chaque nœud avec l adresse ip du nœud en question. Si l IP de la machine A est , le fichier sera : Figure 26 : Fichier Template machine A Si l IP de la machine B est , le fichier sera : Figure 27 : Fichier Template machine B h) Environnement : Il est possible de séparer des environnements afin que ceux-ci s adaptent à nos besoins. Le meilleur exemple est un environnement de production, un de test et un de développement. Ainsi, les changements de configuration dans l environnement de test n impacte pas les autres environnements. Page 29

30 Configuration automatisée avec Puppet Pour cela, il faut mettre en place une arborescence avec un dossier par environnement diffèrent. Figure 28 : Structure de Puppet avec trois environnements Puis il faut spécifier dans le fichier puppet.conf l emplacement des environnements. : Figure 29 : Environnements dans le fichier puppet.conf Lors du lancement de l agent, il faut spécifier l environnement : Figure 30 : Exécution de Puppet dans un environnement particulier Page 30

31 Configuration automatisée avec Puppet Le cheminement dans la mise en place d une nouvelle configuration : 1. Mise en place d une nouvelle configuration dans l environnement «dev». 2. Si la configuration convient pour une machine, on peut la copier dans l environnement «test» afin de faire des tests à plus grande échelle. 3. Si ces tests sont concluants, on peut mettre en place la mise en production sur l ensemble des machines en copiant le contenu de «test» dans «prod». Pour cela, le plus pratique est de mettre en place une solution avec GIT : en plus de pouvoir gérer les versions des scripts, il pourra nous aider à utiliser les environnements via des dossiers séparés. i) Montée en puissance En ayant un serveur et un client il est évident que nous n avons pas de problème de charge. Néanmoins, dans un domaine de production, il n y a plus un client mais plusieurs milliers et un seul serveur ne pourrait supporter la charge. Pour gérer cela, nous avons différentes possibilités : changer le serveur HTTP utilisé (WEBrick) par un serveur Apache multiplier les PuppetMaster. utiliser un ou plusieurs serveurs pour isoler la fonction PuppetCA qui authentifie les clients Nous savons que cela est possible et que c est utilisé par de nombreux utilisateurs. C est pourquoi un tel dispositif ne fera pas partie du stage, sauf si le temps me le permet. j) Exécution de Puppet Afin de procéder aux différents tests, nous voulons que les processus PuppetMaster et Agent ne soient pas utilisés en tant que démon et aussi que la sortie soit détaillée, nous utilisons la commande suivante : D abord le PuppetMaster : Figure 31 : Exécution de PuppetMaster Page 31

32 Configuration automatisée avec Puppet Figure 32 : Exécution de Puppet Client Notre client s est connecté sur le serveur maitre et a exécuté la configuration spécifiée par le fichier/etc/puppet/site.pp. Etant donné que ce fichier est vide, la configuration n a rien changé. Si on voulait lancer le script directement sur le client sans devoir se connecter d abord au serveur, on utiliserait la commande suivante en spécifiant le script à utiliser : Figure 33 : Exécution du script site.pp k) Communauté Puppet L une des grandes forces de Puppet est sa communauté extrêmement active. Par active, il faut comprendre avec une entraide solide, du partage de codes via des modules à installer ou des conférences comme lors des 13emes Rencontre Mondiales du Logiciel Libre à Genève du 7 au 12 Juillet 2012 (conférences concernant Puppet faites par la société PuppetLabs mais aussi par des utilisateurs donnant leur point de vue basé sur une expérience de plusieurs années de Puppet). Ces rencontres sur internet ou en vrai permettent de s enrichir et en retour, d aider d autres personnes. Le site PuppetForge [3] rassemble les modules de la communauté. Page 32

33 Configuration automatisée avec Puppet Figure 34 : Exemple de module disponible sur le site Puppet Forge Concernant les modules, il existe même un outil de PuppetLabs pour faciliter leur mise en place. L outil va se connecter sur le site PuppetForge regroupant tous les modules mis à disposition et va récupérer les fichiers correspondants. 3) Configuration au LHCb : Pour endommager une machine, une seule personne suffit. Pour endommager une ferme de serveur, il faut passer par un outil de configuration automatisé. Un des buts du stage est de répondre à la question : Est-ce que Puppet peut configurer les machines de la ferme pour obtenir le même résultat que Quattor en apportant ses avantages? Pour répondre à cela, mon tuteur m a donné un cahier des charges et en fonction des résultats, nous aurons une réponse à cette question. a) Configuration minimum En fait, un serveur de la ferme n a pas besoin de beaucoup de configuration. Cela consiste en une installation de quelques package et de leur paramétrage, de faire en sorte que l on puisse se connecter en SSH et de monter des dossiers. Liste de packages à installer : Openldap : implémentation libre du protocole LDAP Autofs : contrôle les opérations des démons d automount Nss-pam-ldapd : permet de fournir des services de correspondance entre hostname de toute sorte Page 33

34 Configuration automatisée avec Puppet Cyrus-sasl-gssapi : contient les plugins Cyrus SASL supportant l'authentification GSSAPI. GSSAPI est fréquemment utilisé pour l'authentification Kerberos (protocole d authenfication réseau) Liste des configurations à implémenter : Clé SSH Paramétrage du proxy netgw01 Configuration du cache ldap Configuration Kerberos pour LDAP Configuration des recherches LDAP Montage de deux dossiers réseau Configuration du client NFS Dans le monde linux, tout est fichier. Donc, on peut mettre en place ces configurations en modifiant des fichiers ou en utilisant des types de ressources de Puppet pour y arriver. La façon la plus simple serait de copier les fichiers depuis une machine en fonctionnement et les mettre au bon endroit. Mais, pour le faire dans les règles de l art, il serait préférable de récupérer les différents paramètres depuis les fichiers de configuration de Quattor, en déduire les variables et créer des fichiers génériques en utilisant les variables de Quattor comme des variables sur Puppet. b) Exemple de configuration : Configuration des tests : Un serveur PuppetMaster sous SLC6 Deux clients sous SLC6 Avec un serveur et deux clients, il était simple de comparer la mise en place d une configuration. Vous pourrez trouver ci-dessous un exemple de configuration que j ai appliqué. Paramétrage du proxy Netgw01 :8080 : Ce proxy permet d avoir une porte ouverte sur Internet si on passe par lui. Cela permet de restreindre certains accès si besoin. Pour cela, il existe plusieurs façons de faire : Page 34

35 Configuration automatisée avec Puppet Via une ligne de commande : Via le fichier /etc/bashrc Figure 35 : ligne de commande paramétrant le proxy Figure 36 : fichier /etc/bashrc Encore une fois, pour bien prendre en main Puppet, il faut penser fichier/action générique avec des variables définies à côté. Ainsi, si le proxy vient à changer, plutôt que changer le fichier, il suffira de changer la variable dans un fichier. De même, si un deuxième proxy vient à exister, un changement de variable résout le problème. C est pour cela qu il a été préféré la deuxième méthode. Pour se faire, plutôt que remplacer le fichier, il est préférable de rajouter une ligne dans le fichier. Notre problème est que Puppet ne gère pas l ajout de texte avec vérification si le texte est déjà présent et si c est le cas, ne pas le rajouter. C est pourquoi j ai dû passer par un script qui va «parser»le fichier /etc/bashrc et rajouter les paramètres en conséquence. Figure 37 : Structure du fichier node.pp Le fichier node.pp permet de spécifier la configuration pour chaque nœud. Dans notre cas, le nœud «client1.lbdaq.cern.ch» n a pas besoin d autre configuration que celle de base (juste le module proxy ici). Page 35

36 Configuration automatisée avec Puppet Pour inclure un module, il suffit de mettre «include nom_du_module» et Puppet ira chercher le module /etc/puppet/module (possibilité de changer le chemin avec le fichier «puppet.conf»).bien entendu, il est possible de spécifier des paramètres sont seront repris dans le module. Cela pourrait, si on le souhaitait, permettre d avoir un proxy diffèrent sur certaine machine tout en gardant des fichiers génériques. Figure 38 : Arborescence du module proxy Le fichier «init.pp» est le premier fichier lu lors de l appel d un module. Ce fichier est le «chef d orchestre» et son rôle est de faire appel aux autres fichiers du module. Bien entendu, tout le module peut tenir dans ce fichier mais, encore une fois, il est préférable de séparer le code. Figure 39 : Structure du fichier init.pp du module proxy Le fichier «init.pp» est composé de deux ressources : La première qui va copier un fichier «script_proxy»dans le dossier/tmp/du client avec certains droits. La deuxième qui va exécuter ce script. Vous pouvez remarquer qu il est possible d ordonnancer l exécution de la configuration. En effet, par défaut, Puppet ne va lire les fichiers que dans l ordre que l on veut. Cela se fait de manière plus ou moins aléatoire : deux exécutions de la même configuration pourront ne pas avoir le même enchaînement de Ressource. Pour pallier à cela, il est possible d utiliser des mots clé : Before, Require, Notify et Subscribe. Ainsi, la deuxième Ressource sera appelée si et seulement si la première ressource a déjà été utilisée. Il est logique d exécuter un script seulement s il est bien présent à l emplacement prévu. Page 36

37 Configuration automatisée avec Puppet Figure 40 : Structure du script du module proxy Le script va «parser» le fichier /etc/bashrc et agir en fonction : si la ligne «export http_proxy=netgw01 :8080» n existe pas, il va la rajouter. Ce module est assez simple mais permet d apercevoir la puissance de Puppet avec les types de ressources. Et même quand une fonctionnalité n est pas native dans Puppet, il existe certainement un module pour le faire (ce qui n est pas le cas pour notre module proxy). c) Conclusion La configuration de base des machines de la ferme est très bien gérée par Puppet. Une fois ce travail achevé et validé par mon tuteur, nous en avons conclu que Puppet correspondait à nos attentes et qu il pourra remplacer Quattor dans un futur proche. Mais la vraie question est : peut-on optimiser cela? La seule réponse est : oui mais avec de l expérience. En effet, comme dit plus haut, il n existe pas qu une seule manière d utiliser Puppet. Reste à trouver la méthode la plus adaptée et la plus fonctionnelle possible. Quattor comprend la gestion des configurations mais aussi une partie d installation automatisée. Puppet remplie la première fonction. Il nous reste à trouver le logiciel pour la deuxième partie. Page 37

38 Installation automatisée avec Cobbler III. Installation automatisée avec Cobbler On sait que Puppet est l outil que l on veut pour configurer les différentes machines. Mais avant de configurer ces serveurs, il faut les installer. Il existe la méthode «à l ancienne» : insérer un dvd dans chaque machine et valider manuellement le paramétrage. Ça fonctionne pour un seul serveur mais quand il y en a plus de deux mille, à moins de prendre un stagiaire pendant cinq mois pour cette seule tâche et ne faisant que ça, c est mission impossible. C est là qu intervient Cobbler. 1) Définition de Cobbler Cobbler est un serveur d installation par réseau d OS Linux permettant un paramétrage rapide des environnements d installations. Il relie et automatise plusieurs fonctions comme un serveur web, un serveur TFP etc et ainsi n a qu une seule interface pour gérer une nouvelle machine. Il relie dans le sens où il peut utiliser des services externes ou bien fournir ces services par lui-même. Projet de la distribution Fedora, il gère de plus en plus d autres distributions : bien entendu Fedora/RedHat et ses dérivés (CentOS et Scientific Linux) mais aussi Debian/Ubuntu, Suse et FreeBsd. Le serveur ne fonctionne par contre que pour la famille Fedora/RedHat. La version actuelle est la et la documentation et les sources peuvent se trouver sur le site officiel [4]. Avantage : Rapidité Simplification et automatisation Installation de plusieurs clients à la fois Installation homogène Abstraction d un support physique tel que Dvd ou clé USB Inconvénients : Utilisation des ressources réseaux Page 38

39 Installation automatisée avec Cobbler 2) Principe de Cobbler Cobbler utilise le protocole PXE (Pre-boot execution Environment) qui permet à un client d utiliser le réseau pour récupérer une image d un OS. Cette image peut être utilisée pour permettre le diagnostic d un mini OS pour des clients légers, d un vrai OS dans le cas de machine diskless où le système d exploitation sera entièrement utilisé via le réseau, ou un mini système d exploitation qui permet d installer un OS sur le disque dur local de la machine. C est cette dernière possibilité qui nous intéresse. De nombreuses sociétés utilisent Cobbler (Dell, Sony, LinkShare, TomTom etc ) et donc, sa pérennité ne peut pas être remise en question. a) Serveur Pxe Figure 41 : Séquence de démarrage d'un client Tout d abord, le client doit avoir une carte réseau compatible PXE (ce qui est vrai pour la plupart des machines actuelles) et spécifier qu il doit démarrer sur le réseau au lieu d utiliser le disque dur local. Afin de savoir où le client doit aller chercher le serveur PXE, on utilise le serveur DHCP (1 er composant indispensable à Cobbler). En effet, la première information que le client va chercher est une adresse IP. Dans la configuration du serveur DHCP est indiquée l adresse du serveur TFT PXE et le nom du fichier d amorce. Ce fichier d amorce se nomme «pxelinux.0» et c est ce fichier qui indiquera où récupérer la configuration PXE en utilisant le format suivant : Page 39

40 Installation automatisée avec Cobbler Figure 42: Configuration DHCP du poste client1 Le client va chercher sa configuration dans un dossier en commençant par un dossier portant le nom de son adresse MAC (numéro unique), puis cette adresse convertit en hexadécimal en retranchant un digit à chaque essai pour finir par le fichier par default. Si malgré cela le client n a rien trouvé lui correspondant alors l installation se solde par un échec. Figure 43 : Tentative de récupération du fichier pxelinux.cfg Dans le cas où un fichier de configuration est trouvé, ce fichier est analysé et exploité : requête PXE au serveur TFTP PXE pour les paramètres de démarrage. Si la machine est vierge, on souhaite installer un OS. Si l OS est déjà installé, on va booter sur le disque dur local. Tous ces fichiers sont hébergés sur un serveur TFTP (deuxième composant indispensable à Cobbler). Ainsi, en fonction de l adresse MAC, Cobbler pourra indiquer quel OS installer avec quelle configuration. C est à partir de ce moment que la machine peut commencer à s installer. Afin d automatiser cela, un fichier de réponse appelé fichier «Kickstart» est fourni au client. Ce fichier va automatiquement fournir des réponses que l installateur pourrait poser comme le choix de la langue, du clavier, des packages à installer etc Page 40

41 Installation automatisée avec Cobbler Une variable sur Cobbler indique si une machine doit être installée ou si elle doit démarrer sur le disque dur local. Par défaut, cette variable indique qu un nouveau system doit être installé. Pour la modifier, on peut le faire manuellement ou bien une routine est utilisée à la fin du fichier Kickstart dans le script de post-install. Ainsi, si l installation doit s interrompre avant la fin, au prochain démarrage la machine recommencera le processus d installation. Si l installation s est bien déroulée, le prochain démarrage se fera sur le disque dur local. Figure 44 : Cobbler Ce schéma montre bien comment Cobbler agit comme un couteau suisse : utiliser des services externes (DHCP, DNS, HTTP, TFTP) pour des ressources internes (System, Profile, Distro, Repository, Kickstart). Pour configurer une nouvelle machine, on va créer un nouveau «System» avec son adresse MAC (adresse IP en option) que l on va rattacher à un «Profil» (ex : serveur web), qui ira puiser ses fichiers de base dans une «Distribution» en utilisant des «Repository» pour l installation de packages définis dans un fichier «Kickstart»(les Mgmt-Class pour Management Class est un peu à part : cela sera utilisé pour créer un lien avec Puppet). Notre but est d avoir une configuration minimum, la plus générique possible avec juste le package Puppet installé et que ce soit Puppet qui gère vraiment toute la configuration de la machine. Page 41

42 Installation automatisée avec Cobbler b) Installation de Cobbler Sur une distribution SLC, une ligne de commande permet d installer Cobbler et ses dépendances : Figure 45 : Installation de Cobbler Parmi ces dépendances, on retrouve «httpd» (serveur web), «tftpserver» (serveur tftp), «xinetd» (gère les connexions basé sur Internet). c) Structure de Cobbler Liste des dossiers créés durant l installation de Cobbler : /etc/cobbler : Regroupe la configuration propre à Cobbler /var/www/cobbler Ensemble des données utiles aux clients pour s installer (exemple : distribution, packages etc ) /var/lib/cobbler Dossier des données propre à Cobbler /var/log/cobbler Journaux de Cobbler Page 42

43 Installation automatisée avec Cobbler d) Configuration de Cobbler Avant de paramétrer les services externes, on va le faire via Cobbler au fichier/etc/cobbler/seetings. Exemples : Adresse du serveur PXE (Serveur hébergeant Cobbler dans notre cas) Gestion du DHCP par Cobbler Figure 46 : Fichier seetings de Cobbler Figure 47 : Gestion du DHCP par Cobbler Le choix des outils DHCP ou http par exemple se fait dans le fichier /etc/cobbler/module.conf. Figure 48 : Choix du serveur DHCP dans module.conf Cobbler est un outil permettant de centraliser les configurations des autres services qui lui sont utiles. Ainsi, il n existe qu une seule interface pour gérer les données et les serveurs externes. Pour se faire, des Template existent et Cobbler va modifier les fichiers de config de ces serveurs grâce au variable fournit par l administrateur dans la configuration de Cobbler. Page 43

44 Installation automatisée avec Cobbler Figure 49 : Template du fichier dhcpd.conf Une fois l installation terminée et la configuration de Cobbler finit, une commande (cobbler check) va confirmer que la configuration est conforme et on saura si on peut commencer l importation des données. e) Fichier Kickstart Un fichier Kickstart est composé de quatre parties : La configuration de base Répond aux questions de base : langue, time zone, partitionnement des disques durs etc... Liste des packages Dans notre cas, seul le package Puppet sera installé mais on peut aussi spécifier des packages simples ou des groupes de packages, voire d enlever un package d un groupe Script de Pré Install Liste des commandes à exécuter avant l installation. Vide dans notre cas. Script de Post Install Liste des commandes à exécuter après l installation. On va effacer les listes d origines des Repository de Yum qui pointent sur l extérieur et faire en sorte que Puppet se lance à chaque démarrage du client. On va aussi utiliser un Template de Cobbler appelé SNIPPET pour modifier la variable qui désactive l installation du client à son prochain démarrage. Page 44

45 Installation automatisée avec Cobbler Figure 50 : Fichier Kickstart f) Import des Repository La première chose à faire est d importer des Repository qui seront utilisés lors de l installation des packages pendant l installation de l OS. Il est possible d utiliser des Repository externe à Cobbler (sur Internet par exemple pour avoir les dernières versions des packages) mais étant donné que l on souhaite qu il n y ait aucune donnée venant de l autre part du serveur Cobbler afin de pouvoir garantir leur bonne intégrité, nous allons devoir importer leur contenu. Le Repository le plus important est celui hébergeant Puppet. Malheureusement, le package Puppet (et certaines de ses dépendances) ne fait pas partie des packages d origine des Repository de SLC6. C est pourquoi j ai créé un Repository local spécialement pour cela. L importation des données se fait en deux étapes : configuration d un Repository et synchronisation des données. Figure 51 : Import d'un Repository sous Cobbler Page 45

46 Installation automatisée avec Cobbler Par la suite, il est possible de resynchroniser nos Repository locaux avec les originaux. Figure 52 : Synchronisation des Repository Les Repository se trouvent dans le dossier /var/www/cobbler/repo_mirror/ g) Import des OS Dans ce projet, seul l OS SLC6 sera utilisé pour l installation des clients mais il est possible d importer plusieurs OS. Il suffit de spécifier le nom que l on souhaite donner à cet OS et son emplacement d origine (Dvd, Fichier ISO etc ) Figure 53 : Importation de la distribution SLC6 depuis le fichier boot.iso Les distributions se trouvent dans le dossier /var/www/cobbler/ks_mirror/. h) Création d un profil Lors de l importation d une distribution, un profil est automatiquement créé avec comme seul paramètre la distribution qui lui est lié. Nous devons lui ajouter les Repository que l on a créés juste avant, ainsi que l emplacement du fichier Kickstart. Figure 54 : Structure d'un profil Il est tout à fait possible de créer d autres profiles que ceux d origine pour spécifier d autres fichiers Kickstart par exemple. i) Ajout d un système Maintenant que tout est mis en place pour permettre l installation d une nouvelle machine, il suffit de la rajouter dans Cobbler. Page 46

47 Installation automatisée avec Cobbler Pour cela, on a besoin de son nom pour l identifier sur Cobbler, du profil utilisé, de son adresse MAC et interface réseau, son config réseau (adresse IP, DNS etc ). Ces informations iront renseigner le fichier de configuration du serveur DHCP (dhcpd.conf). Une seule interface de configuration : Cobbler. Figure 55 : Ajout d'un system j) Installation d une machine Avant de lancer une nouvelle installation d un client, il faut synchroniser Cobbler pour qu il puisse modifier les fichiers de configuration et relancer les services. Figure 56 : Résultat de la commande cobbler sync Page 47

48 Installation automatisée avec Cobbler Une fois cette étape validée, on peut démarrer le client. Aucune action de notre part n est nécessaire. Figure 57 : Client récuperant des fichiers sur le serveur PXE Page 48

49 Interconnexion Puppet Cobbler IV. Interconnexion Puppet Cobbler 1) Lien entre Puppet et Cobbler C est parfait. Cobbler installe les clients et Puppet les configure. Mais il reste un problème à résoudre : chaque machine est déclarée sous Cobbler et sous Puppet à la fois. Il y a des outils pour éviter ce double travail. Pour pallier à cela, il est possible de configurer Puppet pour que, au lieu d utiliser le fichier «node.pp» pour connaitre la configuration à appliquer à chaque client, il aille chercher ces informations à l extérieur : c est la notion de configuration de node externe (ENC pour External Node Configuration). Mais cela est un peu plus subtil avec Cobbler qu avec le fichier «node.pp» : un paramètre dans Cobbler, que l on retrouve sur les distributions les profiles et les systèmes, est appelé «Management Classes» et on peut y spécifier plusieurs variables. On va y mettre des noms de class de Puppet (exemple : la class yum ou la class puppet qui se trouve chacune dans un module). Figure 58 : Management Classes au sein de Cobbler Mais comment retourner ces variables en fonction de l hostname d un client et les utiliser dans Puppet? Cobbler fournit un script qui retourne ces valeurs via le serveur web. Figure 59 : Réponse du script en fonction d'un client Et justement, la notion de node externe peut se paramétrer dans /etc/puppet/puppet.conf grâce à un script (ici, une copie du script d origine renommé dans /etc/puppet/external). Figure 60 : Configuration du fichier puppet.conf Page 49

50 Interconnexion Puppet Cobbler Figure 61 : Script external Ainsi, Puppet peut interroger Cobbler pour connaitre les class à utiliser pour tel ou tel client. L interconnexion fonctionne parfaitement mais Mais ce n est pas l utilisation souhaitée. Ce que nous recherchons, c est de définir les distributions, les profiles et les Repository sous Cobbler et tout ce qui touche les systèmes, de les définir sous Puppet. Dans le meilleur des cas, c est Puppet qui va renseigner Cobbler sur les clients et non pas Cobbler qui indique à Puppet ce qu il doit faire. À l heure actuelle, malgré tous ces atouts, Cobbler ne correspond pas à l outil souhaité par le LHCb et par Niko Neufeld en particulier. Mais, il est faut pas enterrer Cobbler trop vite. Quelle est finalement la solution? 2) Remplacement de Cobbler? Lors des conférences des Rencontres du Monde du Logiciel Libre le 11 Juillet 2012, PuppetLabs a parlé d une nouvelle solution qui pourrait nous convenir : Razor. Etant donné qu il est développé par PuppetLabs justement, on est en droit d espérer une complète imbrication dans Puppet. 3) Razor «La solution la plus simple est la plus élégante» Luke Kanies, Fondateur de PuppetLabs Page 50

51 Interconnexion Puppet Cobbler Razor [5] utilise 4 composants ayant chacun une fonctionnalité bien définie : a) Discovery Figure 62 : Razor Discovery Alors qu avec Cobbler chaque machine doit être déclarée manuellement, Razor intègre un outil permettant de connaitre exactement les composants matériels et logiciels de chaque nœud avant même leur installation et ainsi si une machine fait partie d un lot de même type, Razor saura déjà quel OS installer. Fonctionnant aussi avec un serveur DHCP et un serveur PXE, le serveur Razor va fournir une adresse IP via le serveur DHCP. En plus de l adresse, le client va récupérer l adresse du «next-server» qui correspond au serveur PXE Razor. Ce serveur PXE va fournir un MicroKernel de 20mo à peu près. Ce MicroKernel est un système d exploitation extrêmement simplifié basé sur Linux et fournissant une certaine fonctionnalité de base au client. Son but est de faire en sorte que le client puisse faire un inventaire, de contacter le serveur Razor et s enregistrer sur celui-ci. En s enregistrant, il fournit grâce au logiciel Facter de PuppetLabs des informations sur son matériel et sa configuration réseau ( Adresse IP, Mac etc ). Parmi ces informations, on trouve le nombre de processeur, le fabriquant de l ordinateur, le nombre de disque dur et bien plus. Page 51

52 Interconnexion Puppet Cobbler Grace à cela, Razor est capable de découvrir et répertorier des centaines de nœud automatiquement. Figure 63 : Liste des nœuds sur Razor Figure 64 : Attribut d'un node sur Razor Page 52

53 Interconnexion Puppet Cobbler b) Tagging Figure 65 : Razor Tagging Une fois le client et ses informations découverts, il faut utiliser des modèles permettant une classification et ainsi traiter un ensemble de serveur plutôt que chaque machine individuellement. Pour se faire, Razor utilise des règles de «tags» à appliquer sur les nœuds en fonction de ce que Facter a découvert. Exemple : on a 50 serveurs avec 25 de la marque Cisco UCS et 25 de la marque Dell. On souhaite utiliser chaque groupe de serveurs dans un rôle bien spécifique : les Cisco pour faire une ferme de serveur et les Dell pour faire de la virtualisation. On peut connaitre toutes les informations dont on a besoin pour les classer grâce à la partie Discovery et on peut les grouper en appliquant un «tag» commun. Exemple : si l information «constructeur» est Cisco alors on applique le «tag» Cisco. On peut aussi avoir des tags big_server, medium_server et small_server en fonction du nombre de processeur. Il est aussi possible de spécifier plusieurs tag à la fois : [ Dell, small_server ]. Par défaut, Razor utilise les tags [ Nombre_de_CPU, Type_de_CPU, Nombre_de_Carte_Reseau, Type_de_machine ]. Page 53

54 Interconnexion Puppet Cobbler c) Policy Figure 66 : Razor Policy Maintenant, il faut appliquer un modèle commun à chaque tags ou groupe de tags pour l installation des systèmes d exploitation : si les tags sont [ web_farm, small_server ] alors on applique le model «Ubuntu» (du nom de la distribution Ubuntu). Ces modèles sont déclarés préalablement sur Razor en important le système d exploitation. Ainsi, le système d exploitation SLC6 sera installé sur les machines ayant les mêmes «tags» que ceux déclarés. Figure 67 : Razor Policy Ci-dessous, on retrouve la liste des politiques déclarés sur Razor avec la liste des tags associé et le nombre de clients existants. Page 54

55 Interconnexion Puppet Cobbler d) Brokers Figure 68 : Razor Broker On se retrouve avec des machines installées avec le système d exploitation souhaité. Mais il n y a pas de lien encore avec Puppet. Etant donné que Razor et Puppet viennent de la même entreprise, PuppetLabs, il est très facile d intégrer Puppet lors de l installation des clients. Pour se faire, il faut spécifier via une ligne de commande un lien entre le serveur Razor et le serveur Puppet : un «Broker» (agent de change). Figure 69 : Liste des Broker Il faut ensuite associer ce «Broker» a une politique existante. Figure 70 : Politiques sur Razor avec "Broker" Page 55

56 Interconnexion Puppet Cobbler e) Avantages / Inconvénients On a un outil permettant l automatisation à outrance : contrairement à Cobbler, il n est plus utile de déclarer chaque machine pour permettre leur installation : un modèle unique pour un groupe de machine suffit. Mais Razor n est pas dénué d inconvénients : Pour l instant, seules les distributions Debian/Ubuntu sont supportées. Il faut adapter une partie du code de Razor pour le rendre compatibles avec SLC6. Si certaines parties sont plutôt simples, d autres sont plus compliquées : Razor utilise des packages Ruby appelés Gems dont certains n existent que pour Debian/Ubuntu. Une réécriture complète de ces Gems est donc indispensable. De plus, Razor est un outil extrêmement jeune : début Juillet 2012, l outil venait tout juste d être publié par PuppetLabs, soit à peine quelques mois d existence contrairement à Cobbler qui existe depuis plus de quatre ans et a de nombreux clients. Il est donc difficile de trouver de la documentation de nombreux cas ne sont pas pris en compte ( exemple de SLC6 reconnu comme un OS SLC et non pas RedHat ). C est pourquoi, malgré ses avantages, Razor n est pas une solution retenue. 4) La solution Finalement, pour la solution de lien entre Puppet et le logiciel d installation, il est envisagé de revenir à Cobbler avec le développement de script : séparer la partie matérielle avec Cobbler de la partie logiciel avec Puppet. a) Partie Matériel La première partie consiste à déclarer chaque machine sur Cobbler avec comme information : Hostname, Adresse Mac et Adresse IP. Ces seules informations sont indispensables pour l installation du client avec, bien sûr, le choix d un Profil existant dans Cobbler. Figure 71 : Ajout d'une machine sur Cobbler Page 56

57 Interconnexion Puppet Cobbler b) Partie Logiciel L enregistrement sous Puppet est extrêmement simple : cela consiste à avoir un fichier ayant pour nom l hostname du nœud avec l extension «:pp»dans le dossier /etc/puppet/manifests/nodes/ avec comme contenu «node hostname». En paramétrant le fichier /etc/puppet/manifests/site.pp, il ira directement chercher la définition des nœuds dans ce dossier. Figure 72 : Fichier site.pp Figure 73 : Fichier client1.lbdaq.cern.ch.pp c) Lien entre les deux Une solution est d enregistrer chaque machine sur Puppet grâce à Cobbler et au fichier Kickstart. A la fin de l installation avec un fichier Kickstart, il est possible d exécuter des commandes. Ces commandes peuvent servir à modifier le champ «Netboot Enable» des machines sous Cobbler pour éviter que l installation se fasse en boucle si elle est réussie. Nous pouvons nous servir de ce modèle en utilisant un serveur web fonctionnant sous la technologie Web PHP pour créer le fichier «hostname.pp» dans le serveur Puppet. En utlisant une addresse web avec l hostname du client en paramettre, le serveur va créer le fichier.pp. Page 57

58 Interconnexion Puppet Cobbler Figure 74 : Fichier Kickstart avec script PHP Figure 75 : Script PHP pour créer le fichier hostname.pp Ce fichier.pp pourra être modifié par la suite au besoin et ainsi modifier la configuration du client. Page 58

59 Interconnexion Puppet Cobbler Même si cette solution n est pas parfaite (utilisation d outil externe avec le serveur web en PHP plutôt que des outils internes à Cobbler) l avantage d un tel système est de séparer la partie logiciel et la partie matériel. Si une machine a un problème de carte réseau et qu elle doit être changée, l adresse MAC du nœud changera. Seule la modification sous Cobbler est nécessaire et rien ne change pour Puppet. Page 59

60 Machine Diskless V. Machine Diskless Une fois la solution pour interconnecter Puppet et le logiciel d installation trouvé, il faut pouvoir la mettre en production. Seulement, la production, c est la ferme de serveur. Et cette ferme de serveur est composée de machines Diskless (sans disque dur local : l OS est sur un disque dur d un serveur central et envoyé au client via le réseau). 1) Principe Comme indiqué, une machine Diskless ne possède pas de disque dur. Son espace de stockage est centralisé avec les espaces de stockage des autres clients sur un serveur central. Au LHCb, un serveur central administre 27 nœuds client Figure 76 : Serveur Central et Client Diskless Il existe deux fonctionnements de serveur Diskless : Chaque client possède son propre espace Tous les clients partagent le même espace (fichiers communs pour tous les clients, appelé root ), sauf quelques dossiers sélectionnés où chaque client possède son propre espace (appelé snapshot). cela : Le deuxième système est celui sélectionné par le LHCb. Deux raisons à Gain de place : l ensemble des données d un client font 4,5 Giga et avec ce système, on a 500 mo de données spécifiques et les données partagées font 4 Giga. Au lieu d avoir 27x 4,5 Giga =120 Giga par serveur), on a 27x500mo + 4 Giga= 17,5 Giga. Page 60