FLASH INFORMATIQUE FI



Installation automatique de clusters




Vittoria REZZONICO


Dans mon article précédent[1], j’avais brièvement décrit les clusters, en particulier ceux de type Beowulf. Néanmoins, uniquement des solutions Live CD pour la réalisation d’un tel type de cluster ont été montrées. Par contre, j’avais aussi introduit le fait que l’on pouvait construire son propre système. Dans cet article, je vais survoler l’installation du noeud maître du cluster et des noeuds. Je vais supposer, pour simplifier, que le cluster comporte un noeud maître unique (master), qui fonctionne à la fois comme front-end et comme serveur (fig. 1).

fig. 1

Les procédures décrites dans la suite de l’article peuvent aussi être utilisées pour installer un parc informatique.
Cet article ne vise pas à donner des instructions pas à pas, ce qui serait long et ennuyeux, mais plutôt à décrire brièvement les outils nécessaires à la mise en oeuvre d’un cluster de calcul. Pour des instructions plus détaillées, je vous renvoie sur les sites des outils correspondants ou vers la page iacs.epfl.ch/ rezzonic/clusters.

Prérequis

Avant de commencer, il faut se documenter sur certains services que le noeud maître offrira à l’ensemble du cluster :

  • partage de fichiers nfs
  • serveur dhcp
  • serveur de boot De plus, il est conseillé d’installer sur le master aussi les services suivants :
  • un serveur d’authentification
  • un miroir de paquetages (ceux-ci peuvent être ensuite distribués aux noeuds par nfs, ftp ou http)
  • un gestionnaire de queues

Comme les noeuds seront cachés derrière le master, ils n’auront pas d’accès direct à internet. Souvent, surtout pour des raisons de licences, il est nécessaire que les noeuds voient internet. Le master devra donc être passerelle pour les noeuds, c’est-à-dire qu’il devra rediriger le trafic entrant par son interface donnant sur les noeuds vers l’interface donnant sur le réseau externe. Ceci est fait par le biais d’iptables. Une connaissance d’iptables est donc conseillée.

Choix de la distribution

Le choix de la distribution dépend bien sûr de l’administratrice, qui va choisir la distribution dans laquelle elle est le plus à l’aise, et des besoins des utilisateurs. Un cluster est, comme tout serveur, une machine qui doit tourner en permanence, donc des mises à jour trop fréquentes nuiraient à sa fonction. Il vaut alors mieux choisir une distribution avec un long cycle de vie, ou, au moins, des mises à jour de sécurité supportées pendant longtemps (3-5 ans). Les deux distributions traitées ici, Debian et CentOS, remplissent ces critères.
Debian utilise un système de paquetages et des outils que l’on retrouve aussi dans sa dérivée très populaire Ubuntu. C’est pour cela que mes explications concernant Debian peuvent être appliquées quasiment mot pour mot dans le cas où vous voudriez installer un cluster Ubuntu (sauf bien sûr lorsqu’on utilise dans l’installation le nom en dur de la distribution ou de sa version).
La distribution CentOS est pratiquement un clone de RedHat, née après l’historique séparation RedHat/Fedora. CentOS est une recompilation de RedHat Entreprise depuis les sources (ces dernières étant disponibles), les commandes utilisées pour CentOS peuvent donc être également utilisées pour un cluster RedHat (modulo les licences). Deux autres distributions très répandues et très similaires à CentOS sont ScientificLinux et Fedora Core. Mes instructions pourront dans ces deux cas aussi être appliquées presque mot pour mot.
Je tiens à spécifier que le contenu de cet article a été testé avec soin, plusieurs fois, avec les distributions suivantes :

  • Debian stable (etch)
  • Scientific Linux 4.5
  • CentOS 5.1

Je m’excuse pour l’absence d’une distribution très utilisée sur les clusters de l’EPFL : SuSE. Malheureusement, son outil d’installation automatique AutoYaST lui est spécifique, c’est-à-dire qu’il n’est utilisé par aucune autre distribution.

Préparation des services sur le noeud maître

Je ne vais pas m’attarder sur les détails de configuration des différents services, mais juste donner les grandes lignes et souligner des points importants sur certains services qui nécessitent une configuration très particulière dans le cas d’un cluster.

Serveur de fichier nfs

Lors de l’installation des noeuds, les directives d’installation devront être accessibles d’une manière ou d’une autre depuis les noeuds. D’habitude, on utilise un partage nfs, une alternative consiste bien sûr à utiliser ftp ou http. De plus, les fichiers des utilisateurs doivent être accessibles depuis les noeuds. Il faudra donc exporter aussi le répertoire /home. Les noeuds peuvent éventuellement utiliser autofs pour monter les partages depuis le maître.

Serveur DHCP

Un serveur DHCP est nécessaire au moins lors de l’installation : on vise à l’automatiser au maximum, ce sera donc le master qui distribuera les adresses IP aux noeuds, en se basant sur l’adresse MAC de la carte réseau du noeud.
Avant de vous attaquer aux serveurs DHCP, contrôlez que les noeuds démarrent sur le réseau en premier. Ceci est fait au niveau du BIOS. Attention, un serveur DHCP mal configuré peut causer des problèmes sur tout le réseau. Je vous conseille donc dans un premier temps de ne pas connecter l’interface réseau qui va vers l’extérieur directement sur EPNET.
La configuration du serveur DHCP se fait en deux étapes : premièrement, il faut récupérer les adresses MAC des noeuds. Pour ce faire, il suffit de configurer le serveur DHCP pour écouter les requêtes depuis une de ses deux interfaces réseau, et de récupérer les adresses MAC depuis les logs. Ensuite, on entre les adresses MAC dans le fichier de configuration, en interdisant toute autre machine.
Le serveur DHCP s’occupe aussi de dire aux clients depuis quelle machine il faut s’installer. Ceci est fait par les directives :

 filename "pxelinux.0";
 next-server ip_du_bootserveur;

Le reste de la configuration est laissée à vos soins.

Autres services nécessaires au netboot

Une fois le DHCP configuré, testez-le en démarrant les noeuds. Le démarrage devrait s’interrompre assez rapidement, mais vous devriez avoir occasion de voir l’adresse IP assignée au noeud.
Maintenant, vous pouvez installer le serveur tftp, le configurer (souvent la configuration est faite au niveau d’inetd ou xinetd) et le tester.

Serveur de boot

Pour configurer un serveur de démarrage, il faut d’abord récupérer le fichier pxelinux.0 depuis le paquetage syslinux et le placer dans le répertoire racine du serveur tftp (voir configuration du serveur tftp pour avoir cette information). Il faut ensuite configurer le comportement des noeuds lorsqu’ils démarrent sur le réseau, en créant un répertoire pxelinux.cfg contenant plusieurs fichiers :

  • un fichier de démarrage par défaut : default qui dit au noeud de démarrer depuis son propre disque dur – ce fichier doit contenir les lignes suivantes :
                default local

                label local
                LOCALBOOT 0

- 

*un fichier par adresse IP, dont le nom est l’adresse IP du noeud en hexadécimal majuscule, contenant les instructions nécessaires au démarrage depuis le réseau. Ceci diffère en fonction de la distribution et sera donc traitée plus loin.

Routage du trafic

Pour que les noeuds voient internet, il faut rajouter le code suivant à la procédure de démarrage du master (remplacer ethX et ethY par ce qui convient) :

 WAN=ethX
 LAN=ethY

 iptables -F
 iptables -t nat -F
 iptables -A FORWARD -i $LAN -s  
192.168.0.0/255.255.255.0 -j ACCEPT
 iptables -A FORWARD -i $WAN -d
192.168.0.0/255.255.255.0 -j ACCEPT
 iptables -t nat -A POSTROUTING -o $WAN -j
MASQUERADE

 echo 1 > /proc/sys/net/ipv4/ip_forward
 for f in /proc/sys/net/ipv4/conf/*/rp_filter ;
do echo 1 > $f ; done

où, dans ce cas, le subnet privé sur lequel se trouvent les noeuds est le 192.168.0.0/24.
Sous Debian, on peut placer ce code dans le fichier /etc/init.d/bootmisc.sh. Sous CentOS, le fichier est /etc/rc.local.

Serveur d’authentification

Pour avoir une authentification homogène dans tout le cluster, vous pouvez soit installer un serveur d’authentification (à votre souhait : NIS, LDAP,...), ou bien synchroniser les mots de passe sur les noeuds en transférant les fichiers depuis le serveur.

Miroir de paquetages

Pour éviter que les noeuds téléchargent à chaque fois les paquetages depuis l’extérieur, il vaut mieux avoir un miroir local de la distribution, sur le master. Ici, chaque distribution a sa méthode pour dupliquer les paquetages en local. Pour CentOS et Co, on utilise rsync ou wget, tandis que pour Debian la manière la plus simple est d’utiliser apt-mirror.

Gestionnaire des queues

Lorsque les utilisateurs voudront lancer des calculs sur le cluster, il faudra éviter les collisions et les luttes de territoire. Pour cela, il y a les systèmes de queues. Chaque job rentre dans la queue, et le master décide où le job sera exécuté et avec quelle priorité. Un système de queues est nécessaire au bien-être des utilisateurs, qui ne devront pas se soucier de regarder où ils peuvent envoyer leur job. Il suffit de l’envoyer depuis le front-end, qui s’occupera de le distribuer parmi les noeuds libres, ou bien de le mettre en attente jusqu’à ce qu’il y ait assez de ressources disponibles. Il existe plusieurs gestionnaires de queues, je cite PBS et ses implémentations et Sun Grid Engine. Leur configuration étant une science à part, je me soucierai de cela dans un prochain article.

Méthodes d’installations automatiques

Je vais à présent décrire les méthodes d’installation spécifiques à chaque distribution. Dans le cas de CentOS, on va utiliser le très connu KickStart[2]. Dans le cas de Debian, le moins connu FAI[3].
Dans les deux cas, l’installation ne doit requérir aucune intervention manuelle de la part de l’administratrice. Au démarrage, le noeud s’installe. À la fin de l’installation, il redémarre automatiquement sur son disque dur : il faut éviter que le noeud continue à s’installer indéfiniment.
FAI a prévu ceci, par contre avec KickStart il faudra écrire un script de post-installation qui informe le master du fait que le noeud a été installé et qu’il ne doit donc plus démarrer depuis le réseau.

KickStart

KickStart est la méthode d’installation automatique de RedHat. Elle est utilisée aussi pour des installations semi-automatiques, et sa configuration repose sur un unique fichier, qui peut être écrit à la main, en partant de zéro ou bien du fichier anaconda-ks.cfg que l’installation manuelle du master aura généré pour vous dans le répertoire /root/. De plus, CentOS (comme aussi des cousines RedHat, Fedora et ScientificLinux) dispose d’un outil graphique pour générer des fichiers KickStart – system-config-kickstart.

fig. 2

Afin d’éviter la réinstallation infinie des noeuds, avec KickStart il faut rajouter un script de post-installation, qui désactive le démarrage depuis le réseau en renommant le fichier correspondant à l’adresse IP du client. Par exemple, le noeud ayant comme adresse IP 192.168.0.11 doit monter par nfs le répertoire tftpboot/pxelinux.cfg du master et renommer le fichier C0A8000B en C0A8000B.disabled. Le fichier C0A8000B correspondant à l’adresse IP 192.168.0.11 doit être placé préalablement sur le serveur et contenir les lignes suivantes :

default install

label install
kernel vmlinuz-install
append ip=dhcp ksdevice=eth0 load_ramdisk=1
initrd=initrd.img network ks=nfs:192.168.0.1:/data/install/nodes-ks.cfg ramdisk_size=9216

Remarquez l’option ks, qui indique où se trouve le fichier kickstart contenant les directives d’installation des noeuds. Dans notre cas, un partage nfs. Dans le cas d’un cluster hétérogène (ou de plusieurs salles de stations), on peut indiquer différents fichiers kickstart dans les différents fichiers contenus dans pxelinux.cfg.

FAI

FAI est un acronyme pour Fully Automatic Installation. Il est plus flexible que KickStart mais cette flexibilité a un prix : la difficulté. Avec FAI on peut également installer d’autres distributions, mais je ne l’ai pas traité ceci.
Tout d’abord, installez les paquetages nécessaires :

 apt-get install fai-kernels fai-server

La configuration de FAI en tant que service se fait dans les fichiers /etc/fai/fai.conf, /etc/fai/make-fai-nfsroot.conf et /etc/fai/apt/sources.list. Ajouter l’utilisateur fai et lancez fai-setup :

 useradd -m -g nogroup fai
 fai-setup

Si c’est votre première configuration FAI, copiez la configuration d’exemple depuis la doc :

 cp -a /usr/share/doc/fai-doc/examples/
simple/* /srv/fai/config

Maintenant, vous pouvez vous plonger dans /srv/fai/config... voici une brève explication du contenu de ce répertoire.

  • class : les scripts contenus dans ce répertoire permettent d’avoir différentes installations (par classes). Avec KickStart, on utiliserait l’option de démarrage ks qui indique quel fichier KickStart il faut utiliser. Le choix de l’installation est donc fait à un niveau différent.

Dorénavant, la configuration sera faite par classes de machines.

  • disk_config : pour chaque classe, ce répertoire contient un fichier qui définit la table des partitions des disques.
  • package_config : contient la liste des paquetages à installer sur les noeuds.
  • scripts : contient des scripts de post-installation
  • files : contient des fichiers qui peuvent être copiés sur les noeuds lors de l’exécution des scripts susmentionnés.
  • hooks : contient des scripts qui sont exécutés (en fonction de leur nom) à un moment particulier de l’installation
  • debconf : sert à la configuration des paquetages.

Une fois que vous avez une configuration à votre avis correcte, il faut finaliser le tout :

  • contrôlez que votre /etc/exports soit correct : tous les partages sont exportés uniquement dans le réseau interne.
  • créez les fichiers par adresse IP dans pxelinux.cfg. Ceci est plus simple qu’avec KickStart. Le script fai-chboot s’occupe pratiquement de tout :
  for i in 'grep fixed /etc/dhcp3/dhcpd.conf |
sed '/#/d'| awk '{ print $2 }' | sed 's/;//g''; do fai-chboot -IFv $i; done

À la fin de chaque installation automatique, le fichier correspondant à la machine qui vient d’être installée sera désactivé. Ainsi, au démarrage suivant, le noeud choisira le boot par défaut dans pxelinux.cfg/default et démarrera en local.
Enfin, changez les permissions de quelques répertoires :

 chown -R fai:nogroup /srv/tftp/fai /srv/fai/
config

Voilà, vous êtes théoriquement prêts à installer vos noeuds. Il suffit de les démarrer, si possible à distance !
Malheureusement, la première fois il se peut qu’il y ait des problèmes. Heureusement, FAI produit des logs très détaillés, qui sont sur le noeud dans /tmp pendant l’installation et sur le master dans /home/fai à la fin, si le transfert depuis le noeud a pu se faire. N’hésitez pas à vous y plonger pour résoudre vos problèmes, mais attention : si vous vous loguez sur un noeud depuis le serveur en tant que root, et que vous tapez un mot de passe erroné (fai par défaut), vous allez engendrer une erreur qui bloquera le redémarrage automatique du noeud.

Après l’installation

Il se peut que vous ayez oublié quelques paquetages lors de l’installation automatique. Pas de panique, il ne faut pas tout recommencer ! La manière la plus facile de rajouter des paquetages après coup est par ssh sur les noeuds. Les outils pssh et dsh permettent d’exécuter des commandes sur tous les noeuds en même temps, par ssh. Je vous conseille d’utiliser des clefs ssh pour éviter de devoir rentrer à chaque noeud le mot de passe root. On peut aussi profiter d’outils appropriés, par exemple CFEngine.

Conclusion

J’ai décrit dans cet article deux façons d’installer automatiquement un cluster par directives. L’installation par directives peut ne pas être le chemin le plus simple parce qu’elle dépend fortement de la distribution utilisée et pour cela risque de mener l’administratrice à être mono-distribution, alors que les utilisateurs souhaiteraient peut-être avoir un choix plus vaste. On peut aussi installer un cluster avec des images : on prépare une image sur un noeud, on la copie sur le master avec un outil approprié, et ensuite on la déploie sur les noeuds. L’installation par image n’épargne pas à l’administratrice la configuration des services comme nfs, nis ou dhcp, mais en fonction du logiciel utilisé pour le déploiement, on peut éviter de devoir configurer un serveur de démarrage, ceci étant fait automatiquement par l’outil.

Références

[1] FI 8/2007, Beowulf-me ! – http://dit.epfl.ch/publications-spip/spip.php?article1384
[2] fedoraproject.org/wiki/Anaconda/Kickstart
[3] www.informatik.uni-koeln.de/fai/



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.