FLASH INFORMATIQUE FI



public averti Clusters généralistes du DIT avec AutoYaST


Une manière de gérer l’installation et la configuration des noeuds de calcul d’un cluster.



One way to manage the installation and configuration of a cluster’s compute nodes.


Jacques MENU


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 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.

PNG - 11.1 ko
écran de Yast
PNG - 12.5 ko
é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.

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 https://5e2705k97ce548ckb7a104e022760b75@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 noeuds de calcul

Un noeud 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 noeud 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 :

  • un serveur de configuration, accessible par NFS sur le même segment que les noeuds de calcul. En pratique, la frontale est utilisée ;
  • des fichiers XML dits de contrôle (control file) : ils décrivent de manière structurée comment installer les noeuds ;
  • un dossier de référence d’installation sur la frontale, duquel les fichiers sont copiés sur les noeuds après l’installation de base du logiciel.

Dans le cas de Vega, le serveur d’installation est accédé par :

nfs ://172.30.1.1/exports/cluster/suse/SLES-10-SP2/CD1/tt>.
Ce dossier contient l’image du premier CD d’installation. Le sous-dossier suse/x86_64, contient les packages .rpm pour l’architecture des noeuds, ainsi que MD5SUMS, la somme de contrôle MD5 pour chacun d’eux.

Ordre de boot des noeuds

Les noeuds de Vega sont de marque Dell. La séquence de boot sur ces noeuds est :

  • DVD local ;
  • interface NIC1 ;
  • interface NIC2 ;
  • 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 :

noeud marqué comme action
boot booter sur le disque dur interne, rien de spécial
install 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 noeud concerné, écrite en hexadécimal et sans points. L’utilitaire getshotip est utile pour ça :

root@node22:~ > /usr/bin/gethostip node23
node23 172.30.2.23 AC1E0217

Le noeud numéro 23 de Vega a l’adresse 172.30.2.23. Son fichier de configuration est montré à la figure 3.

root@vega:/opt/cluster/tftpboot/pxelinux.cfg > cat AC1E0217
DEFAULT install
PROMPT 1
TIMEOUT 20
DISPLAY message/AC1E0217

LABEL boot
       LOCALBOOT 0

LABEL install
       KERNEL linux
       APPEND initrd=initrd textmode=1 splash=0 showopts netdevice=eth0 hostip=172.30.2.23 netmask=255.255.0.0 gateway=172.30.1.1 netwait=120 install=nfs://172.30.1.1/exports/cluster/suse/SLES-10-SP2/CD1autoYaST=nfs://172.30.1.1/exports/cluster/autoYaST/node23.xml

LABEL rescue
KERNEL linux
APPEND initrd=initrd splash=0 rescue=1 showopts install=nfs://172.30.1.1/exports/cluster/suse/SLES-10-SP2/CD1

LABEL memtest
       kernel memdisk
       append initrd=dalco/mem165.img

fig. 3 - fichier de configuration PXE

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.

root@vega:/opt/cluster/tftpboot/message > cat AC1E0217
VEGA boot menu for node23 [AC1E0217, 172.30.2.23]
----------------------------------------------------------
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

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 noeud considéré est remise à boot pour les redémarrages à venir. Cela est fait en recréant les fichiers ci-dessus avec boot comme argument.
Une alternative serait d’utiliser l’option suivante, que nous n’utilisons pas :

<second_stage config:type="boolean">false<second_stage>

Fichiers de contrôle AutoYaST

Ces fichiers, comme node23.xml, sont essentiellement les mêmes pour tous les noeuds de calcul. Les seules différences sont le nom du noeud comme node23 et l’adresse IP 172.30.2.23. Ils ont la structure illustrée par la figure 5.

<?xml version="1.0"?>
<!DOCTYPE profile>

<profile xmlns="http://www.suse.com/1.0/YaST2ns"  
xmlns:config="http://www.suse.com/1.0/configns">

 <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>   </chroot-scripts>

fig. 5 - structure d’un fichier de contrôle

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 noeud prêt à être utilisé. L’interface utilisateur pour le faire est peu intuitive, toutefois :

  • dans YaST, choisir la commande Create Reference Profile du menu Tools ;
  • cela amène une fenêtre permettant de sélectionner des ressources additionnelles, comme client NFS et configuration NTP ;
  • 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 ;
  • dans le menu View, la commande Source affiche ce code XML ;
  • 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.

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/YaST2-31366-dkPnh9/valid.xml
148 -rw-r--r-- 1 root root 147424 May  5 16:50 /tmp/YaST2-31366-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.

   <loader_type>grub</loader_type>
   <sections config:type="list">
     <section>
       <append>resume=/dev/sda2 splash=silent showopts</append>
       <image>/boot/vmlinuz-2.6.16.60-0.21-smp</image>
       <initial>1</initial>
       <initrd>/boot/initrd-2.6.16.60-0.21-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

La section Network contient les informations sur le DNS et le routage, parmi d’autres. Les réglages des interfaces sont présentés à la figure 7.

<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>172.30.2.23</ipaddr>
       <name>Broadcom NetXtreme II BCM5708 Gigabit Ethernet</name>
       <netmask>255.255.0.0</netmask>
       <startmode>auto</startmode>
       <usercontrol>no</usercontrol>
     </interface>
   </interfaces>
   ... ... ... ...
 </networking>

fig. 7 - section des interfaces réseau

Personnalisation des noeuds

AutoYaST offre le moyen d’exécuter des scripts à cette fin, à quatre stades différents du processus d’installation :

scriptsexécuté
pre-scripts Au tout début, juste après la détection du matériel, mais avant que l’installation ne démarre
chroot-scripts Avant que le système tout juste installé ne soit rebooté
post-scripts Juste après ce premier reboot, avant que les services de l’OS ne démarrent
init-scripts Après que ces services ont démarré

Nous utilisons des scripts pour configurer plus finement les noeuds 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é ci-dessous. Le volume /exports/cluster est monté temporairement de la frontale 172.30.1.1 sur /opt/cluster, pour pouvoir exécuter :

/opt/cluster/admin/postinstall.sh node23 172.30.2.23 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.

# 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

fig. 8 - script postinstall.sh

Section chroot-scripts

Pour les chroot-scripts, la valeur booléenne chrooted indique quand le script est exécuté :

chrooted signification
false (défault) Le système installé est encore monté sur /mnt, et le bootloader n’est pas encore installé
true 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é ci-après.

<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 172.30.1.1:/exports/cluster /opt/cluster
       /opt/cluster/admin/postinstall.sh node23 172.30.2.23
       umount /opt/cluster
       ]]></source>
   </script>
 </chroot-scripts>

fig. 9 - chroot-scripts

La balise CDATA contient le code à exécuter.

Section init-scripts

Voilà celui que nous utilisons.

<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 172.30.1.1:/exports/cluster /opt/cluster
         /opt/cluster/admin/postinstall2.sh
         umount /opt/cluster
         mount -at nfs
         ]]></source>
   </script>
   </init-scripts>
 </scripts>

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.

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

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 .

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. 11 - script postinstall_20_Atlas dans /opt/cluster/admin

SSH

Nous gérons les clés SSH de la manière suivante :

  • quand un noeud est installé, rien de particulier n’est fait pour la clé de son serveur SSH. Cette dernière est donc recréée ;
  • il n’y a pas de mot de passe local sur les noeuds 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 ;
  • le compte root des noeuds 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 :

  • les outils fournis par Novell font ce qu’on attend d’eux, sans problème ;
  • l’installation des noeuds 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 ;
  • quelques autres scripts personnalisent les noeuds de calcul après que le disque a été formaté et que le système d’exploitation a été installé ;
  • tous ces scripts sont écrits en Bash et en Perl, et peuvent être eux repris par n’importe quel administrateur en cas de besoin ;
  • 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.


Glossaire

BlueGene/P
serveur IBM du type BlueGene, acheté dans le cadre du projet CADMOS. Le modèle installé à l’EPFL a 16384 coeurs et 16 TB de mémoire vive.
Clusters généralistes du DIT
le DIT met à disposition des scientifiques de l’EPFL trois installations, Antares, Callisto et Vega


Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.