Clusters généralistes du DIT avec AutoYaST

Transcription

1 Analyse Clusters généralistes du DIT avec AutoYaST EPFL DIT, analyste système en charge des clusters généralistes du DIT One way to manage the installation and configuration of a cluster s compute nodes. Une manière de gérer l installation et la configuration des nœuds de calcul d un cluster. Yast (Yet another Setup Tool) est l outil de gestion fourni par SuSE Linux, aussi bien en version opensuse que SLES (SuSE Linux Enterprise Server). SuSE a été rachetée par Novell il y a déjà quelques années. SLES 10 est utilisé sur les clusters généralistes du DIT & et les frontales du BlueGene/P &, en version SP1 et SP2 selon les machines. AutoYaST est la partie complémentaire à YaST pour gérer l installation des machines faisant partie d un parc. Nous présenterons dans un premier temps les principales fonctionnalités offertes par YaST. Ensuite, nous mettrons l accent sur l emploi que nous faisons d AutoYaST pour gérer les clusters Callisto, Antares et Vega au DIT. Les exemples de configuration sont tirés de Vega. Documentation et versions La documentation est disponible en ligne à l URL: chorgan.provo. novell.com/yast/doc/sles10/autoinstall/index.html ainsi que sur les machines dans le fichier: /usr/share/doc/packages/autoyast2/ autoyast.pdf. AutoYaST existe en modes semi-graphique et graphique, lancés par yast et yast2 respectivement. Ces commandes offrent les mêmes possibilités, présentées sous forme de groupes, comme illustré aux figures 1 et 2. La version de YaST montrée ici est celle qui est disponible sur SLES 10. Il y a des variations dans l interface utilisateur sur d autres versions. fig. 1 écran de Yast fig. 2 écran de Yast2 On peut accéder à la gestion des différents groupes sans les afficher tous auparavant, au moyen d un argument de la commande. Ainsi, /sbin/yast2 hwinfo permet d accéder à la fenêtre du groupe Hardware. Possibilités de YaST Les fonctionnalités de base sont similaires à celles qu offrent des outils équivalents disponibles sur des distributions comme Mandriva, Red Hat et Ubuntu par exemple. On peut donner dans la zone de saisie Filter une chaîne de caractères pour restreindre la quantité d information présentée dans la partie droite de la fenêtre. Dans le groupe Hardware, on a accès à toutes les informations sur le matériel présent dans la machine, avec les fabricants, modèles, numéros de série et versions. Sous Security and Users, on peut gérer les utilisateurs et groupes, définir comment les mots de passe sont contrôlés en termes de longueur et de pérennité. C est là aussi qu on trouve les réglages du firewall, ainsi que la gestion des certificats. Enregistrement auprès de Novell Il faut acheter une clé d activation (activation code) auprès d un partenaire de Novell pour accéder aux patches et évolutions logicielles. Le bouton Novel Customer Center Conf. permet d enregistrer cette clé d activation. Patch du système Le bouton Patch CD Update copie les patches disponibles sur la machine et les installe. On peut comparer les versions installées avec celles disponibles sur les serveurs de Novell, ainsi que leurs dépendances. Les fichiers faisant partie des versions installées sont aussi montrés. Dans le menu Extras, la commande Show products affiche les différents services packs disponibles. Le cluster Vega s appuie sur l infrastructure SAN du DIT, ce qui la limite à SP2 au moment où nous écrivons ces lignes, mais la migration en SP3 est proposée, par exemple. 22 JUIN N 6 17

2 Installation de logiciel fourni par Novell Cela se fait avec le bouton Software Management du groupe Software. Les dépendances sont prises en compte, ce qui peut conduire à devoir installer d autres logiciels au passage. Serveur d installation On doit configurer l accès à des catalogues de logiciel (software catalogs): ils sont disponibles sur CD, DVD, sur des serveurs de fichiers auxquels on accède par FTP, HTTP, HTTPS ou SMB/CIFS. On gère de tels catalogues par le bouton Installation Source du groupe Software. La clé d activation est utilisée pour créer un compte sur les serveurs de Novell, qui est accessible par une URL comme k97ce548ckb7a104e022760b75@nu.novell.com//repo/$RCE/ SLES10-SP2-Updates/sles-10-x86 64/ Le bouton Installation Into Directory du groupe Software est utilisé pour créer un dépôt local. On choisit la source de l installation (un serveur Novell ou un DVD monté localement, par exemple) et le dossier destination. Vega est une cliente HTTPS de SLES10-SP2-Pool et SLES10-SP2- Updates sur les serveurs de Novell, et elle accède à /exports/ cluster/suse/sles-10-sp2/cd1/ sur ses propres disques. Stratégie d installation des nœuds de calcul Un nœud de calcul est installé à la mise en production initiale de la machine, et ensuite lorsque des problèmes graves se manifestent. Le temps d installation varie de 15 à 25 minutes, selon la machine considérée et la taille du logiciel à installer. Nous préférons ne pas cloner un nœud de calcul existant standard. Nous obtenons ainsi un disque fraîchement formaté avec tout le logiciel installé à partir de la configuration de référence, sans qu il ne reste rien d historique. Nous utilisons: z un serveur de configuration, accessible par NFS sur le même segment que les nœuds de calcul. En pratique, la frontale est utilisée; z des fichiers XML dits de contrôle (control file): ils décrivent de manière structurée comment installer les nœuds; z un dossier de référence d installation sur la frontale, duquel les fichiers sont copiés sur les nœuds après l installation de base du logiciel. Dans le cas de Vega, le serveur d installation est accédé par: nfs :// /exports/cluster/suse/SLES-10-SP2/ CD1. Ce dossier contient l image du premier CD d installation. Le sousdossier suse/x86_64, contient les packages.rpm pour l architecture des nœuds, ainsi que MD5SUMS, la somme de contrôle MD5 pour chacun d eux. Ordre de boot des nœuds Les nœuds de Vega sont de marque Dell. La séquence de boot sur ces nœuds est: z DVD local; z interface NIC1; z interface NIC2; z disque dur interne. En l absence de DVD, ils bootent via PXE et vont chercher leur configuration sur la frontale. Là, il y a deux cas: nœud marqué comme boot install action booter sur le disque dur interne, rien de spécial aller chercher la configuration d installation sur la frontale par TFTP, et lancer le processus d installation Fichiers de configuration de boot PXE Leur nom est l adresse IP du nœud concerné, écrite en hexadécimal et sans points. L utilitaire getshotip est utile pour ça: root@node22:~ > /usr/bin/gethostip node23 node AC1E0217 root@vega:/opt/cluster/tftpboot/pxelinux.cfg > cat DEFAULT PROMPT TIMEOUT DISPLAY LABEL LOCALBOOT LABEL KERNEL APPEND initrd=initrd textmode=1 splash=0 showopts netdevice=eth0 hostip= netmask= gateway= netwait=120 install=nfs:// /exports/cluster/ suse/sles-10-sp2/cd1 LABEL KERNEL APPEND initrd=initrd splash=0 rescue=1 showopts install=nfs:// /exports/cluster/suse/ LABEL kernel append fig. 3 fichier de configuration PXE 18 flash informatique

3 > cat AC1E0217 VEGA boot menu for node23 [AC1E0217, ] Possible actions: boot - boot the node from its internal hard disk install - install the node, scratching everything rescue - boot in rescue mode memtest - run memtest on the node Default: install Enter an action in the next 20 seconds (default: install) fig. 4 fichier de message PXE <?xml version="1.0"?> <!DOCTYPE profile> <profile xmlns=" xmlns:config=" <bootloader> <device_map config:type="list"> <device_map_entry> <firmware>hd0</firmware> <linux>/dev/sda</linux> </device_map_entry> </device_map> <global> <activate>true</activate> <boot_root>true</boot_root> <default>suse Linux Enterprise Server 10 SP2</default> <generic_mbr>true</generic_mbr> <gfxmenu>/boot/message</gfxmenu> <lines_cache_id>2</lines_cache_id> <timeout config:type="integer">8</timeout> </global> </bootloader> </profile> fig. 5 structure d un fichier de contrôle Fichiers de contrôle AutoYaST Ces fichiers, comme node23.xml, sont essentiellement les mêmes pour tous les nœuds de calcul. Les seules différences sont le nom du nœud comme node23 et l adresse IP Ils ont la structure illustrée par la figure 5. Ces fichiers sont également créés par un script. On peut vérifier qu ils sont bien formés avec l utilitaire xmllint qui fait partie du package libxml2. Le modèle qui sert à les créer peut être obtenu initialement sur un nœud prêt à être utilisé. L interface utilisateur pour le faire est peu intuitive, toutefois: z dans YaST, choisir la commande Create Reference Profile du menu Tools; z cela amène une fenêtre permettant de sélectionner des ressources additionnelles, comme client NFS et configuration NTP; z le bouton Create crée le code XML décrivant le système d exploitation et les ressources additionnelles choisies. Si on sélectionne une ressource non encore installée, YaST propose de l installer au passage; z dans le menu View, la commande Source affiche ce code XML; z il reste à sauvegarder ce code dans un fichier par la commande Save as du menu File, avec le dossier /var/lib/autoinstall/repository proposé par défaut. Le nœud numéro 23 de Vega a l adresse Son fichier de configuration est montré à la figure 3. L option netwait=120 est nécessaire sur Vega, pour laisser les couches réseau démarrer avant d essayer d accéder au serveur NFS. Le message qui est affiché au boot est montré dans la figure 4. Ces fichiers de configuration et de message sont créés par un script dont l argument est l action par défaut, c est à dire install ou boot. Quand l installation est terminée, l action pour le nœud considéré est remise à boot pour les redémarrages à venir. Cela est fait en recréant les fichiers ci-dessus avec boot comme argument. <loader_type>grub</loader_type> <sections config:type="list"> <section> <append>resume=/dev/sda2 splash=silent showopts</append> <image>/boot/vmlinuz smp</image> <initial>1</initial> <initrd>/boot/initrd smp</initrd> <kernel>/boot/vmlinuz</kernel> <lines_cache_id>0</lines_cache_id> <name> SUSE Linux Enterprise Server 10 SP2</name> <original_name>linux</original_name> <root>/dev/sda1</root> <type>image</type> <vgamode>0x317</vgamode> </section> <section> <name> Failsafe -- SUSE Linux Enterprise Server 10 SP2</name> <original_name>failsafe</original_name> </section> </sections> fig. 6 section bootloader Une alternative serait d utiliser l option suivante, que nous n utilisons pas: <second_stage config:type="boolean">false <second_stage> Une alternative est de choisir, dans le menu Tools, la commande Check Validity of Profile: l effet est de créer un ficher de contrôle dans /tmp, comme: root@vega:/var/cache/zmd > ll /tmp/ YaST dkPnh9/valid.xml@ 148 -rw-r--r-- 1 root root May 5 16:50 / tmp/yast dkpnh9/valid.xml@ et de le tester avec xmllint. On peut alors utiliser ce fichier à volonté. Les options du bootloader disponibles sont montrées à la figure 6. La section Network contient les informations sur le 22 JUIN N 6 19

4 <networking> <dhcp_options> <dhclient_additional_options></dhclient_additional_options> <dhclient_client_id></dhclient_client_id> <dhclient_hostname_option>auto</dhclient_hostname_option> </dhcp_options> <interfaces config:type="list"> <interface> <bootproto>static</bootproto> <device> eth0</device> <ipaddr> </ipaddr> <name>broadcom NetXtreme II BCM5708 Gigabit Ethernet</name> <netmask> </netmask> <startmode>auto</startmode> <usercontrol>no</usercontrol> </interface> </interfaces> </networking> fig. 7 section des interfaces réseau 20 flash informatique # loop through the postinstall_files and execute them cd $CDIR/admin for SCRIPT in $(ls postinstall_[0-9][0-9]* sort) do echo "###############################################" echodate "### $SCRIPT starting" $SCRIPT echodate "### $SCRIPT finished" done <scripts> <chroot-scripts config:type="list"> <script> <chrooted config:type="boolean">true</chrooted> <debug config:type="boolean">true</debug> <feedback config:type="boolean">false</feedback> <filename>postinstall.sh</filename> <interpreter>shell</interpreter> <source><![cdata[echo "###### Running postinstall.sh" hostname >/tmp/hostname.out set >/tmp/set.out mkdir -p /opt/cluster mount -t nfs -o nolock :/exports/cluster /opt/cluster /opt/cluster/admin/postinstall.sh node umount /opt/cluster ]]></source> </script> </chroot-scripts> fig. 9 chroot-scripts fig. 8 script postinstall.sh <init-scripts config:type="list"> <script> <debug config:type="boolean">true</debug> <filename>postinstall2.sh</filename> <source><![cdata[echo "###### Running postinstall2.sh" mount -t nfs -o nolock :/exports/cluster /opt/cluster /opt/cluster/admin/postinstall2.sh umount /opt/cluster mount -at nfs ]]></source> </script> </init-scripts> </scripts> root@vega:/opt/cluster/admin > cat postinstall_20_atlas #!/bin/bash # AutoYaST Post-processing set -x -v # # Installing Atlas ARCHIVE=Atlas.tar.gz cd / tar xfzp /opt/cluster/spool/$archive fig. 11 script postinstall_20_atlas dans /opt/cluster/admin fig. 10 init-scripts

5 DNS et le routage, parmi d autres. Les réglages des interfaces sont présentés à la figure 7. Personnalisation des nœuds AutoYaST offre le moyen d exécuter des scripts à cette fin, à quatre stades différents du processus d installation: scripts pre-scripts chroot-scripts post-scripts init-scripts exécuté Au tout début, juste après la détection du matériel, mais avant que l installation ne démarre Avant que le système tout juste installé ne soit rebooté Juste après ce premier reboot, avant que les services de l OS ne démarrent Après que ces services ont démarré Nous utilisons des scripts pour configurer plus finement les nœuds juste avant et juste après le premier reboot du système qui vient d être installé. Leur rôle est d installer tous les logiciels complémentaires au-delà du système d exploitation, comme les compilateurs, librairies et logiciels spécifiques, comme illustré aux figures 9 and 10. Le volume /exports/cluster est monté temporairement de la frontale sur /opt/cluster, pour pouvoir exécuter: /opt/cluster/admin/postinstall.sh node Le script postinstall.sh, par exemple, parcourt le dossier où il se trouve pour y exécuter tous les scripts ayant un nom de la forme requise (fig. 8). Section chroot-scripts Pour les chroot-scripts, la valeur booléenne chrooted indique quand le script est exécuté: chrooted false (défault) true signification Le système installé est encore monté sur /mnt, et le bootloader n est pas encore installé Le chroot sur /mnt a été fait, le bootloader est installé et le système installé fonctionne. Il n y a plus besoin de préfixer les dossiers par /mnt Le script chroot-scripts que nous utilisons est présenté à la figure 9. La balise CDATA contient le code à exécuter. root@vega:/opt/cluster/admin > cat postinstall_01_nodeconfig #!/bin/bash # AutoYaST Post-processing set -x -v # # Copy node-config files cp -drp /opt/cluster/spool/node-config/* / fig. 12 script postinstall_01_nodeconfig dans /opt/cluster/admin SSH Nous gérons les clés SSH de la manière suivante: z quand un nœud est installé, rien de particulier n est fait pour la clé de son serveur SSH. Cette dernière est donc recréée; z il n y a pas de mot de passe local sur les nœuds de calcul pour les utilisateurs lambda: une paire de clés SSH est créée sur la frontale dans leur dossier racine partagé, et la clé publique est copiée dans authorized_keys; z le compte root des nœuds de calcul est local. Le dossier.ssh est copié du dossier de référence. Conclusion Nous utilisons AutoYaST depuis plusieurs années pour gérer les clusters généralistes du DIT. La manière de faire décrite ci-dessus nous a été fournie au départ par Jonas Lehmann et Beat Rubischon, de Dalco, pour Mizar et Alcor respectivement. Ces deux machines ont été mises hors production récemment. Markus Bärtschi, d IBM, a aussi fait des suggestions utiles quand Callisto a été installée par la suite. L expérience s avère très positive de notre point de vue: z les outils fournis par Novell font ce qu on attend d eux, sans problème; z l installation des nœuds de calcul est faite avec quelques scripts qui créent les fichiers de configuration et de message PXE, ainsi que les fichiers de contrôle AutoYaST, à partir de modèles; z quelques autres scripts personnalisent les nœuds de calcul après que le disque a été formaté et que le système d exploitation a été installé; z tous ces scripts sont écrits en Bash et en Perl, et peuvent être eux repris par n importe quel administrateur en cas de besoin; z il n y a pas de syndrome dans lequel l outil de gestion serait le principal problème parce qu il faudrait contourner ses limitations ou combler ses manques.n Section init-scripts Celui que nous utilisons est présenté à la figure 10. Scripts d installation de logiciels spécifiques Pour ajouter du logiciel à la configuration courante, il suffit de placer une archive dans /opt/cluster/spool et un script comme postinstall_20_atlas dans /opt/cluster/admin (fig. 11). Un autre script copie des fichiers de configuration depuis un dossier de référence. Parmi ceux-ci, /etc/passwd et /etc/group, vu que leur contenu évolue dans le temps, et les liens vers les dossiers racine des utilisateurs depuis /home (fig. 12). GLOSSAIRE & BlueGene/P: serveur IBM du type BlueGene, acheté dans le cadre du projet CADMOS. Le modèle installé à l'epfl a coeurs et 16 TB de mémoire vive (bluegene.epfl.ch). Clusters généralistes du DIT: le DIT met à disposition des scientifiques de l'epfl trois installations, Antares, Callisto et Vega (hpc-dit.epfl.ch) 22 JUIN N 6 21