Mise en place d`un cluster via OpenMosix sous Linux

Résumé
Cet article vous guidera dans l'installation et l'administration d'un cluster OpenMosix.
OpenMosix est un patch du noyau Linux vous permettant la migration des processus entre
plusieurs ordinateurs au sein d'un réseau en LAN. Il s'agit là d'une solution de clustering
simple et performante compte tenu de son coût et des types de machines concernés.
1.
NOTIONS DE BASES :
Avant de pouvoir découvrir ce qu’est OpenMosix, nous allons définir succinctement ce qu’est
un Cluster, car il y a beaucoup à dire à ce sujet. Et je pense qu’il est nécessaire de posséder
certaines notions avant de démarrer notre entreprise.
1.1. Qu’est ce qu’un Cluster ?
Tout d’abord, le nom « cluster » (ou grappe en français) est un terme attaché à un réseau.
Imaginez-vous une grappe de raisin, à première vue, rien à voir avec un anneau de calcul !
Maintenant, prenez la tige comme étant la backbone et les fruits comme étant l’un des
ordinateurs (nœud ou node) de cette grappe, vous obtenez donc un système (grappe ou
cluster) relié par de multiples tiges qui correspondent à leur tour aux câbles réseaux (couche
physique) du système. Le but de ce Cluster de calcul est de permettre des calculs grâce à
l’intermédiaire de plusieurs machines afin d’augmenter les performances du système ou afin
d’équilibrer les charges CPU entre d’un nœuds en redirigeant certains processus vers un
autre noeud. Le cluster est donc un ensemble d’ordinateurs qui vous permettrons de
partager leurs ressources matérielles.
Il existe plusieurs types de clusters. OpenMosix s’apparente à un cluster loadbalancing dû à l’algorithme de répartition de charges. Cet algorithme permet un équilibre des
charges en fonction de l'occupation des processeurs.
1.2. Comment fonctionne OpenMosix ?
Le but d’un anneau de calcul est comme son nom l’indique de calculer une information par
l’intermédiaire de migration de processus dans le cas d’OpenMosix. Rappelons qu’un
processus est une tache exécutée par le noyau d’un système d’exploitation, dans notre cas,
le noyau Linux. Les performances d’un ordinateur sont en partie dues au temps que met un
processeur à terminer les threads d’un processus.
L’avantage des ordinateurs SMP est que les threads des processus sont répartis sur
plusieurs processeurs d’une même machine, divisant donc le temps d'execution de la tâche
par le nombre de processeurs. L’Hyper-threading possède aussi un certain avantage à cela,
mais cela peut ne pas suffire, comme le montre ce site : http://www.top500.org les cluster ont
aucune limite en terme de puissance d'où la nécessitée et l'avantage de créer un anneau
de calcul avec des machines SMP, seulement leur coût est élevé !
1
Le plus gros cluster est actuellement Earth Simulator Center : Regardez ses
caractéristiques et vous comprendrez que vous votre merveilleux PC n’est même pas l’égale
au centième d’un supercalculateur ! http://www.es.jamstec.go.jp/esc/eng/Hardware/pn.html
Pourquoi utiliser un anneau de calcul ?
Imaginez-vous six conversions d’un format audio quelconque. Le nombre de processus
envoyés en même temps au processeur sera découpé en thread par le système
d’exploitation (et heureusement, étant donné qu'un processeur ne peut calculer qu’un thread
à la fois, le système d’exploitation découpe celui-ci en threads afin que le noyau puisse vous
donner l’impression d’exécuter plusieurs tâches en même temps alors qu’en réalité il exécute
un thread à la fois. Heureusement car si vous ne pouviez voir une vidéo en ayant le son en
même temps, cela semblerait plutôt embarrassant) ces 6 processus prendront donc 6 fois le
temps d’exécution d’un seul processus en supposant que la taille des fichier soient
identiques. Dans un cluster de 6 noeuds, si les ressources sont équivalentes, le temps
théorique de la conversion de ces 6 fichiers sera divisé par 6.
OpenMosix fonctionne de cette façon. Lors du lancement des 6 conversions sur un nœuds,
l’algorithme d’équilibre des charges redirigera ces processus lourds vers les machines les
plus puissantes ou les plus libres du cluster afin d’améliorer la vitesse d’exécution de la
totalité des tâches. De plus, il vous est possible de gérer vous-même la migration des
processus, ce qui présente un certain avantage si vous désirez occuper votre poste à
d’autres fins. OpenMosix met à disposition pour cela une pléthore de programmes
1.3. Limites et problèmes rencontrés :
OpenMosix fonctionne différemment de certains clusters de serveurs.
Tout d’abord, les ordinateurs sont identifiés comme étant plusieurs ordinateurs (plusieurs
IP) contrairement à certains cluster beaucoup plus performants.
La mémoire n’est pas partagée.
Il ne peut être migré que certains processus appelés lourds (qui nécessitent tout
simplement un temps de calcul important) du fait des problèmes de latences réseaux qui
sont beaucoup plus importantes que les latences entre les bus d’un ordinateur. Un petit
processus migré mettra plus de temps à être terminé qu'un gros processus migré sur une
machine pouvant l'exécuter plus rapidement du fait que le réseau entraîne une latence lors
de la transmission de celui-ci.
Le plus grand problème en terme de sécurité est due à l’utilisation du démon omdiscd. En
effet celui-ci met à jour une carte des nœuds openmosix de manière automatique ce qui fait
que n’importe quel administrateur d’un ordinateur, est aussi administrateur du réseau et cela
est du à deux choses : le système MFS (Mosix File System) vous donne accès à tt les
nœuds en montant chaque racine dans le répertoire monter de type MFS.
Ex : /mnt/mfs/num_id_du_noeud/
Et le fait de manière automatique grâce à omdiscd qui met à jour le mappage du
cluster. N’importe quel administrateur possède les droits de toutes les machines. Il est donc
recommandé de limiter l’accès physique au réseau.
2
Après ces quelques explications théoriques, vous pouvez dès à présent débuter
l’installation de votre cluster OpenMosix.
2.
MISE EN PLACE DU CLUSTER OPEN MOSIX :
2.1. Pré requis :
Au moins 2 PC feront l’affaire, prévoyez sinon un bon switch et un réseau en 100Mbits ça
vaut mieux, à 10Mbits la latence sera tellement forte que le système ne sera pas efficace.
Voilà pour les grandes lignes, le reste c’est un O.S. Linux n’importe quel distribution,
personnellement j’utilise Gentoo. Il n’y a aucun pré requis de package si ce n’est de
posséder un noyau 2.4.24 (conseillé) (il n’est pas encore possible d’utiliser un 2.6) pour
appliquer le patch openmosix. Donc il suffit des sources du kernel 2.4.24 et de quoi le
compiler.
Cependant vous aurez par la suite besoin d’autres librairies pour compiler les outils de
gestion et de monitoring. (libjpeg, glibc, etc.)
2.2. Installation :
Dans mon cas, j'installe un cluster sous gentoo, le tout sur un réseau avec un serveur
DHCP, la reconnaissance des nodes se fait donc automatiquement grâce au démon
omdiscd.
Téléchargement :
Au moment où cet article est écrit, le Noyau patché OpenMosix est le noyau linux2.4.24
Il est disponible sur le site http://openmosix.sourceforge.net
Téléchargez la dernière version du patch d’OpenMosix et placez-le dans le répertoire des
sources du noyau. (Ex : /usr/src/linux-2.4.24)
N’oubliez pas de vous mettre en root.
Sur n’importe quel distribution :
# mv openMosix-2.4.24.gz /usr/src/linux-2.4.24
# cd /usr/src/linux-2.4.24
# zcat openMosix-2.4.24.gz | patch -Np1
Si vous n’utilisez pas zcat :
# mv /root/openMosix-2.4.24.gz /usr/src/linux-2.4.24
# cd /usr/src/linux-2.4.24
# gunzip openMosix-2.4.24.gz
# cat openMosix-2.4.24 | patch -Np1
Sur Gentoo :
Pour emerger les sources de OpenMosix :
# emerge openmosix-sources
3
1.2. Configuration du noyau :
# cd /usr/src/linux
# make menuconfig
Vous devez mettre les options suivantes (à ajoutez à votre configuration du noyau
courantes) :
9 OpenMosix process migration : Migration des processus du cluster.
9 Stricter security on OpenMosix ports
9 Level of process-identify disclosure (0-3)
9 OpenMosix File System : Permet l'utilisation des système de fichier oMFS ou MFS
(Mosix File system) nous verrons l'utilité de ce système de fichier plus loin.
9 Prompt for development and/or incomplete code/drivers : Active des
options nécessaires à la configuration du noyau.
4
9 Packet socket
9 TCP/IP networking
9 IP: multicasting
9 /proc files system support : permet d’accéder au noyau sous forme de fichier
système dans le répertoire /proc.
9 /dev file system support (EXPERIMENTAL)
9 Automatically mount at boot
5
Une fois la configuration terminée, il ne reste plus qu’à compiler notre nouveau noyau :
#make dep clean bzImage modules modules_install
# cp arch/i386/boot/bzImage /boot/bzImage-OMosix-2.4.24
Puis configurer et mettre à jour son boot loader :
Lilo :
# vi /etc/lilo.conf
Rajoutez à la fin ceci (remplacez X par votre partition correspondant à la racine /) :
image = /boot/bzImage-OMosix-2.4.24
root= /dev/hdaX
label = OpenMosix
read-only
N’oubliez pas de monter votre partition boot ! Certaines distributions mette la partition boot
dans le fstab en noauto, donc avant de taper cette commande montez la partition !
mount /boot
# lilo (ou /sbin/lilo)
6
Installation des outils OpenMosix :
La suite de programmes OpenMosix est assez complète. Elle permet de gérer le cluster.
Cette suite de programmes se trouve dans l'archive openmosix-tools.
Pour obtenir openmosix-tools, téléchargez les packages ou le sources sur le lien suivant :
http://sourceforge.net/project/showfiles.php?group_id=46729
Sur une Gentoo, il suffit d'emerger openmosix-user.
2.3. Configuration d’un nœud :
Mise en place de Mosix File System (MFS) :
Ce Système de fichier supporté par votre nouveau noyau permet d'accéder à tout vos
noeuds sur chaque ordinateurs et ce, de manière identique sur chaque noeud.
Vous devez donc créer un fichier dans lequel vous monterez vos noeuds :
# mkdir /mfs
Editez le fichier table d’allocation des système de fichier :
# vi /etc/fstab
Puis ajoutez la ligne :
none /mfs
mfs
noauto,dfsa=1 0 0
Enfin, montez le répertoire :
# mount /mfs
L'option noauto n'est pas obligatoire seulement au cas ou vous utiliser un noyau autre que
openmosix, vous ne pourrez pas monter ce système de fichier (il ne sera pas reconnu pas ce
noyau)
De plus, ce système de fichier vous donne accès à l’ensemble des nœuds des racines du
système avec les privilèges que sur votre machine !!! Il suffit donc d’avoir accès au compte
administrateur d’un nœud pour en contrôler l’ensemble. Ne laissez donc pas votre MFS en
auto ;-)
Voilà, vous avez terminé l'installation d'OpenMosix, il ne vous reste plus qu'à maitriser ses
outils.
3. Administration d’OpenMosix
3.1. Démarrage d’OpenMosix :
Pour gérer le démarrage de OpenMosix et l'Arrêt :
# /etc/init.d/openmosix start
# /etc/init.d/openmosix stop
# /etc/init.d/openmosix status
La manière la plus facile de configurer openmosix au démarrage et à l'arrêt est de rajouter
dans le rc.local la commande :
7
/sbin/setpe -W -f /etc./hpc.map
Pour Gentoo :
#rc-update add openmosix default
En lisant le script openmosix :
#!/sbin/runscript
#
# Distribué sous les termez de la GNU General Public License V2
depend() {
need net
}
stop() {
ebegin "Stopping openMosix"
# Tout les processus sont desactivé grace à la commande expel
einfo "openMosix:
"
mosctl expel
setpe -off
killall -TERM omdiscd &> /dev/null
rm -f /var/lock/subsys/mosix
eend
}
start() {
# Si vous n’avez pas activez l’option OpenMosix dans le noyau : exit
# /proc/hpc est le repertoire du noyau lié au cluster
if [ ! -d /proc/hpc ]; then
einfo "This is not an openMosix kernel, configuration aborted"
exit
fi
# Cherche le mapfile d’OpenMosix
AUTODISC=0
if [ -f /etc/openmosix.map ]; then
OMOSIX_MAP=/etc/openmosix.map
elif [ -f /etc/mosix.map ]; then
OMOSIX_MAP=/etc/mosix.map
einfo "openMosix map-file /etc/mosix.map depreciated: Rename to /etc/openmosix.map"
elif [ -f /etc/hpc.map ]; then
OMOSIX_MAP=/etc/hpc.map
einfo "openMosix map-file /etc/hpc.map depreciated: Rename to /etc/openmosix.map"
else
AUTODISC=1
fi
OMnode=""
if [ -f /etc/openmosix/om-node-num ]
then
OMnode="-p $(< /etc/openmosix/om-node-num)"
fi
# Check the map-file for sanity
if [ $AUTODISC -eq 0 ]; then
setpe $OMnode -c -f $OMOSIX_MAP &> /dev/null
if [ ! $? -eq 0 ]; then
einfo "openMosix: Invalid configuration in map-file $OMOSIX_MAP, using
autodiscovery"
8
AUTODISC=1
fi
fi
# Source the configuration from /etc/openmosix/openmosix.config
# This file would be a good place to force autodiscovery by setting AUTODISC=1
[ -f /etc./openmosix/openmosix.config ] && . /etc./openmosix/openmosix.config
# Make sure we have omdiscd installed
if [ $AUTODISC -eq 1 ]; then
if [ ! -x `which omdiscd` ]; then
eerror "openMosix: omdiscd not installed, exiting"
eend
fi
fi
ebegin "Initializing openMosix"
# The variables $OVERHEADS, $MFSCOSTS, $MYOMID, $MOSGATES and
$AUTODISCIF
# can be set to desired values in /etc/openmosix/openmosix.config
[ $OVERHEADS ] && echo $OVERHEADS > /proc/hpc/admin/overheads
[ $MFSCOSTS ] && echo $MFSCOSTS > /proc/hpc/admin/mfscosts
if [ $AUTODISC -eq 0 ]; then
# Static configuration via $OMOSIX_MAP
SETPE_OPTIONS=""
[ $MYOMID ] && SETPE_OPTIONS="$SETPE_OPTIONS -p $MYOMID"
[ $MOSGATES ] && SETPE_OPTIONS="$SETPE_OPTIONS -g $MOSGATES"
setpe $OMnode -W $SETPE_OPTIONS -f $OMOSIX_MAP
else
# Configurate openMosix with the omdiscd
OMDISCD_OPTIONS=""
[
$AUTODISCIF
]
&&
OMDISCD_OPTIONS="$OMDISCD_OPTIONS
$AUTODISCIF"
omdiscd $OMDISCD_OPTIONS
fi
[ $? -eq 0 ] && touch /var/lock/subsys/openmosix
mosctl noblock 1>/dev/null 2>&1
eend
}
-i
On peut remarquer que le script utilise les programmes setpe, mosctl à l’arrêt du
système.
Nous verrons plus loin leurs fonctions importantes dans l’administration du cluster.
La lecture de la map s’effectuait auparavant dans le fichier /etc/hpc.map, puis
/etc/mosix.map et enfin maintenant sur /etc/openmosix.map.
3.2. Identification des noeuds :
Afin que les noeuds puissent s’identifier à l’anneau, il est nécessaire qu’ils déclarent leurs
adresses IP correspondantes ainsi qu’un numéro d’identification (ID) du noeud et ses
caractéristiques comme le nombre de processeur sur la machine.
Pour cela, il existe deux méthodes : La méthode empirique (à la main ;-)) et la méthode
automatique (avec un démon) :
9
o Configuration du fichier /etc/openmosix.map :
Depuis les dernières versions ce fichier se nomme openmosix.map, ne vous étonnez pas s’il
possède un autre nom.
Chaque ordinateur doit configurer un fichier contenant le numéro de chaque noeud du
cluster ainsi que leur IP et le nombre de processeur qu’il contient.
De la manière suivante :
Id
IP
Nb_de_Processeurs
Par exemple :
1
172 .168.100.34
2
Cette méthode n’est malheureusement pas pratique. Bien que l’on soit sur de contrôler
le « mappage » du cluster et donc sa sécurité, cette technique nécessite tout d’abord un
réseau possédant des nœuds fixe ainsi qu’une grande patience, car il faut avant tout
reproduire, mettre à jour la openmosixmap sur chaque nœud, à chaque fois qu’un nouveau
nœud apparaît.
C’est pourquoi par défaut, OpenMosix est configuré par une démon de découverte
automatique : OMDISCD (OpenMosix autoDISCover Daemon) :
A chaque intégration d’un nouveau nœud, Omdiscd envoie une requête au réseaux
afin d’obtenir en réponse le « mappage » du cluster. Il est ainsi intégré en se déclarant
automatiquement auprès de l’anneau et mets à jour le mappage de celui-ci. Ce démon se
trouve être très efficace pour la mise en place d’un anneau de calcul devant être
opérationnel en peu de temps ou dans les cas ou les calculs s’effectuent dans une écoles ou
dans une université possédant des IP dynamique…
L'utilisation de Omdiscd ne nécessite pas de configuration particulière dans le cas d'un
cluster intégré à un réseau possédant un serveur DHCP
3.3. Les programmes OpenMosix :
En ligne de commande :
¾cpujob : Donne a un processus une partie définie de la charge de CPU
¾iojob : permet de limiter sur le réseaux les entrées et sorties accorder au processus
¾joingroup : Permet de joindre un processus à un group. (utile pour la commande
migrategroup)
¾migrate : Pour migrer les processus en cours vers un nœuds
¾migrategroup : Pour migrer un groupe
¾mosmon : il s'agit d'un moniteur openmosix permettant de visionner l'état de tous les
noeuds du cluster (CPU, mémoire)
¾mosctl
:
Programme
important
dans
l'administration
d'OpenMosix
:
Il permet de gérer l'administration d'un noeud au niveau du noyau. (cf. section
administration) Les options de mosctl sont :stay, block, noblock, quiet, noquiet,
nomfs, mfs, expel, bring, gettune, getdecay.
10
¾mosrun : Mosrun vous permet de forcer la migration d'un processus, de préciser un
noeud de destination ou un groupe de noeuds particulier.
ex : mosrun -12 emerge gkrellm
La compilation s'effectue sur le noeud ayant pour ID 12. Dans notre cas, la charge
donnée pour le processus exécutant la ligne possède une charge de moins de 10% dans
notre exemple, la charge du noeuds 12 possède une charge d'environ 90%.
¾mps est l'équivalent de la commande ps pour un cluster OM. Il donne en plus l’ID du
nœud ou le processus est migré.
¾mtop est l'équivalent de la commande top pour OM. Une colonne est ajoutée pour
donner le numéro d'ID du noeuds où le processus a été migré.
¾nomig : Lance une commande sur le noeud qui interdit toute migration.
¾Resetgroup : supprime le groupe crée
¾runhome : équivalent à la commande mosrun -h : il permet de lancer et de bloquer le
processus en local.
¾runon permet de lancer et de bloquer le processus sur un noeud OpenMosix
particulier.
¾Setpe : l’option -r (read) permet de lire la configuration actuelle du cluster (la map)
¾-off déconnecte le noeuds du réseau. Le script /etc/init.d/openmosix est muni de mosctl
expel afin de renvoyer les processus traités sur le noeuds (pour éviter de perdre les
données et de setpe -off pour le shutdown d'openmosix.
¾Cette procédure est relativement importante si vous ne voulez pas perdre les
processus !
¾showmap : montre la "carte" du cluster. Dans l'ordre : le numéro hexadécimal de la
node, l'IP et le nombre de processeurs.
En voici un exemple :
root@localhost / # showmap
My Node-Id: 0x6417
Base Node-Id Address
Count
------------ ---------------- ----0x6417
172.16.100.23 1
0x640c
172.16.100.12 1
¾showgroup : montre les groupe de processus (qui ont été crées par la commande
joingroup)
Toutes ces commandes sont amplement suffisantes
d'OpenMosix. Elles sont relativement simples mais complètes !
pour
l'adminstration
Openmosixview :
Openmosixview est une interface graphique rassemblant la totalité des programmes
précédents et permettant une gestion totale et optimale du cluster.
Lancer en root, on obtient quelques options supplémentaires (mémoire de tout les
nœuds et nombre de processeurs sur chaque nœud).
11
La gestion est très pratique et permet de gérer votre cluster de migrer des processus
en quelques cliques. Cependant le rafraîchissement du la charge des CPU et des mémoires
de chaque nœud peut poser certains problèmes arrivé à un certains nombre de nœuds.
En cliquant sur l’IP d’un des nœuds, on obtient la fenêtre suivante :
On retrouve ici, l’option auto migration (/proc/hpc/admin/stay), le démarrage ou
l’arrête du nœuds distant etc… Le tout en mode click-click ;-). Jetez un oeil sur
l'administration avancé pour comprendre votre nouveau noyau !
3.4. Administration avancé de OpenMosix :
L’administrateur peut configurer et optimiser le cluster en utilisant openmosix user space
tools. Cela consiste à modifier les valeurs des fichiers de configuration présent dans
/proc/hpc/admin.
Quelques exemples :
# echo 1 > /proc/hpc/admin/block
Cette commande refuse l’arrivé de processus “émigré”.
12
# echo 1 > /proc/hpc/admin/bring
Ramène tout les processus migrés de la node.
Les programmes définis précédemment interfère en réalité dans le noyau, grace à
l’interface du noyau dans le répertoire /proc/hpc/admin :
On active ainsi toutes ses fonctions en donnant la valeur 1 à leur fichier de configuration.
config : fichier principale de configuration
block : permet / interdit l'arriver de processus distant
bring : ramène tout les processus migrés
dfsalinks : liste les lien dfsa en cours
expel : envoi les processus home
gateways : nombre maximum de passerelles
lstay : liste des processus qui doivent pas migrer
mospe : contient les ID des noeuds OpenMosix
nomfs : Activer/Desactiver MFS
overheads : pour optimiser
quiet : stopper la collecte des informations d’équilibre des charges
decay-interval: définit l’intervalle de rafraîchissement du load-balancing
speed : définit une vitesse de nœud. Un cluster possédant un nombre plus faible aura une
priorité d’« immigration » de processus plus important que les autres nœuds.
Stay : activer/désactiver la migration automatique des processus
Vous voilà fin prêt à maitriser votre merveilleux cluster ! Il ne vous reste plus qu'à convertir,
compiler, etc. afin de vérifier que tout est opérationnel !
Si openmosixview présente une adresse IP en rouge, celà signifie que ce noeud est tombé, il
ne vous reste qu'à cerner le problème, quitte a redémarrer le scriot /etc/init.d/openmosix du
noeud.
Pour plus d'informations, jetez un oeil sur le HOWTO openmosix, celui-ci n'existant qu'en
anglais.
13
Conclusion
Vous voilà fin prêt à gérer votre cluster. Mais résumons les caractéristiques de votre anneau
de calcul OpenMosix :
Votre anneau de calcul vous permet de réaliser des gros calculs.
Les outils d’administrations vous permettent de gérer simplement la migration de vos
processus.
Les petites tâches ne vous permettent pas de rentabiliser le temps d’exécution de celles-ci
sur les autres nœuds.
La sécurité des données n’est pas possible lançant tel quel le démon omdiscd du fait que
celui-ci met à jour automatiquement la map du système et accepte donc n’importe quel
machine et donc n’importe quel administrateur en tant qu'administrateur du cluster.
Il s’agit là des caractéristiques classiques d’un anneau de calcul très abouti.
L’utilisation de Linux, vous permet de faire tourner OpenMosix sur des machines diverses et
variées, vous permettant donc d’exploiter des machines dépassées par les ordinateurs
actuelles. Pour cela il existe divers possibilités dont celle à retenir est LSTP.
OpenMosix a été porté sur des consoles de jeux (Playstation 2, Xbox, etc.) à des fins
expérimentales et on montrés une améliorations des performances allant jusqu’à 20% des
capacités normales.
De plus, l’équipe du projet OpenMosix travaille sur des améliorations tout à fait intéressantes
en tentant de contourner problèmes rencontrés sur la migration des processus légers.
14