Gentoo Logo

Gentoo Linux pour le calcul de haute performance

Table des matières :

1.  Introduction

Gentoo Linux est une variante de Linux qui peut être optimisée automatiquement et paramétrée pour répondre à tout usage ou besoin spécifique. Ses possibilités d'adaptation, ses performances extrêmes et sa grande communauté d'utilisateurs et de développeurs sont les principales caractéristiques de Gentoo.

L'outil Portage peut faire de Gentoo Linux un serveur sécurisé idéal, une station de développement ou de bureautique professionnelle, une console de jeux, une solution embarquée ou... un système pour le calcul de haute performance.

Ce document vous apprendra comment transformer un système Gentoo en un système pour le calcul de haute performance (en anglais « High Performance Computing », ou HPC). Étape par étape, il vous explique quels paquets logiciels vous seront utiles, et vous montre comment les installer et les configurer.

Vous pouvez obtenir Gentoo Linux à partir du site Web http://www.gentoo.org. Référez-vous à la documentation (en français) disponible sur ce même site pour procéder à son installation.

2.  Configurer Gentoo pour l'utiliser avec une grappe de calcul

Optimisations recommandées

Note : Dans cette section, nous ferons fréquemment référence au Manuel Gentoo Linux.

Pendant le processus d'installation, vous devrez paramétrer la variable USE dans le fichier /etc/make.conf. Nous vous suggérons de désactiver toutes les valeurs par défaut (voir /etc/make.profile/make.defaults) en les ajoutant sous forme négative (-option) dans make.conf. Il y a toutefois quelques options que vous souhaiterez peut-être conserver, par exemple : x86, 3dnow, gpm, mmx, nptl, nptlonly, sse, ncurses, pam et tcpd. Consultez la documentation relative à la variable USE pour plus de détails.

Exemple de code 2.1 : Options USE

USE="-oss 3dnow -apm -arts -avi -berkdb -crypt -cups -encode -gdbm -gif gpm -gtk
-imlib -java -jpeg -kde -gnome -libg++ -libwww -mikmod mmx -motif -mpeg ncurses
-nls nptl nptlonly -oggvorbis -opengl pam -pdflib -png -python -qt3 -qt4 -qtmt
-quicktime -readline -sdl -slang -spell -ssl -svga tcpd -truetype -X -xml2 -xv
-zlib"

Ou, plus simplement :

Exemple de code 2.2 : Variable USE - version simplifiée

USE="-* 3dnow gpm mmx ncurses pam sse tcpd"

Note : L'option USE tcpd augmente la sécurité pour certains paquets logiciels tels que xinetd.

En ce qui concerne le noyau, nous suggérons, pour des raisons de stabilité, les « vanilla-sources », c'est-à-dire les sources officielles disponibles sur le site http://www.kernel.org/. Vous devrez peut-être choisir des sources différentes si vous avez besoin du support pour une technologie particulière telle que xfs.

Exemple de code 2.3 : Installer les « vanilla-sources »

# emerge -p syslog-ng vanilla-sources

Lorsque viendra le temps d'installer les divers utilitaires complétant votre système Gentoo, nous vous suggérons d'installer les paquets suivants :

Exemple de code 2.4 : Installer quelques paquets nécessaires

# emerge -p nfs-utils portmap tcpdump ssmtp iptables xinetd

Interface de communication (réseau TCP/IP)

Une grappe de calcul nécessite une interface de communication pour interconnecter les nœuds esclaves au nœud maître. Il s'agit typiquement d'un réseau local (LAN) de type « FastEthernet » ou « GigaEthernet », cette technologie offrant un ratio performance versus prix intéressant. Les alternatives incluent les produits Myrinet, QsNet et d'autres.

Une grappe de calcul contient deux types de nœuds : maître et esclave. Dans la plupart des cas, la grappe contient un seul nœud maître et plusieurs nœuds esclaves.

Le nœud maître est le serveur de la grappe de calcul. Il est responsable de fournir les instructions aux nœuds esclaves. Ce serveur exécute habituellement des services tels que dhcpd, nfs, pbs-server et pbs-sched. Le nœud maître accepte les tâches et permet aux utilisateurs d'ouvrir des sessions interactives.

Chaque nœud esclave reçoit ses instructions (probablement par ssh ou rsh) du nœud maître. Puisque les nœuds esclaves sont dédiés aux calculs, ils ne devraient pas exécuter de services superflus.

La suite de ce document suppose une configuration similaire à celle proposée dans le fichier /etc/hosts ci-dessous. Ce fichier devrait être présent sur tous les nœuds et contenir une entrée pour chaque nœud de la grappe de calcul.

Exemple de code 2.5 : /etc/hosts

# Adelie Linux Research & Development Center
# /etc/hosts

127.0.0.1       localhost

192.168.1.100   master.adelie master

192.168.1.1     node01.adelie node01
192.168.1.2     node02.adelie node02

Pour configurer le réseau local (LAN) de votre grappe de calcul, éditez le fichier /etc/conf.d/net du nœud maître.

Exemple de code 2.6 : /etc/conf.d/net

# Global config file for net.* rc-scripts

# This is basically the ifconfig argument without the ifconfig $iface
#

iface_eth0="192.168.1.100 broadcast 192.168.1.255 netmask 255.255.255.0"
# Network Connection to the outside world using dhcp -- configure as required for you network
iface_eth1="dhcp"

Enfin, configurez un démon DHPC sur le nœud maître afin de ne pas avoir à configurer le réseau sur chacun des nœuds esclaves.

Exemple de code 2.7 : /etc/dhcp/dhcpd.conf

# Adelie Linux Research & Development Center
# /etc/dhcp/dhcpd.conf

log-facility local7;
ddns-update-style none;
use-host-decl-names on;

subnet 192.168.1.0 netmask 255.255.255.0 {
        option domain-name "adelie";
        range 192.168.1.10 192.168.1.99;
        option routers 192.168.1.100;

        host node01.adelie {
                # MAC address of network card on node 01
                hardware ethernet 00:07:e9:0f:e2:d4;
                fixed-address 192.168.1.1;
        }
        host node02.adelie {
                # MAC address of network card on node 02
                hardware ethernet 00:07:e9:0f:e2:6b;
                fixed-address 192.168.1.2;
        }
}

NFS/NIS

Le « Network File System » (NFS) a été conçu pour permettre à un ordinateur de monter un système de fichiers situé sur une machine distante comme si ce système de fichiers était sur le disque dur local. Cela permet le partage rapide et transparent de fichiers à travers un réseau.

Il existe d'autres systèmes dont les fonctionnalités sont comparables à celles de NFS et qui pourraient être utilisés avec une grappe de calcul. Le système de fichiers Andrew d'IBM, qui est maintenant un projet « open source », offre un mécanisme de partage de fichiers avec sécurité et performances améliorées. Le système de fichiers Coda est encore en développement, mais il est conçu pour bien fonctionner avec les clients déconnectés. Plusieurs fonctionnalités des systèmes de fichiers Andrew et Coda seront incorporées dans la prochaine version de NFS (version 4). NFS offre présentement plusieurs avantages : il est mature, standardisé, bien compris et supporté par une grande variété de plates-formes.

Exemple de code 2.8 : Les paquets logiciels pour le support de NFS

# emerge -p nfs-utils portmap
# emerge nfs-utils portmap

Configurez et installez un noyau supportant NFS version 3 sur tous vos nœuds :

Exemple de code 2.9 : Configuration du noyau requise pour utiliser NFS

CONFIG_NFS_FS=y
CONFIG_NFSD=y
CONFIG_SUNRPC=y
CONFIG_LOCKD=y
CONFIG_NFSD_V3=y
CONFIG_LOCKD_V4=y

Sur le nœud maître, éditez le fichier /etc/hosts.allow pour permettre les connexions à partir des nœuds esclaves. Si votre grappe de calcul occupe la plage réseau 192.168.1.0/24, votre fichier hosts.allow ressemblera à ceci :

Exemple de code 2.10 : hosts.allow

portmap:192.168.1.0/255.255.255.0

Éditez le fichier /etc/exports du nœud maître pour exporter une structure de répertoires pour le travail. Le répertoire /home est un bon choix.

Exemple de code 2.11 : /etc/exports

/home/  (rw)

Ajoutez nfs au niveau d'exécution par défaut du nœud maître :

Exemple de code 2.12 : Ajouter nfs au niveau d'exécution par défaut

# rc-update add nfs default

Pour monter le système de fichiers nfs exporté du maître, vous devez également configurer le fichier /etc/fstab de vos nœuds esclaves. Ajoutez-y la ligne suivante :

Exemple de code 2.13 : /etc/fstab

master:/home/   /home   nfs     rw,exec,noauto,nouser,async     0 0

Vous devez aussi exécuter la commande suivante pour que les nœuds montent le système de fichiers nfs automatiquement :

Exemple de code 2.14 : Ajouter nfsmount au niveau d'exécution par défaut

# rc-update add nfsmount default

RSH/SSH

SSH est un protocole pour l'ouverture de sessions sécurisées à distance (et pour d'autres services sécurisés) sur un réseau non sécurisé. OpenSSH utilise la cryptographie à clé publique pour fournir une méthode d'authentification sécurisée. La première chose à faire pour configurer OpenSSH sur votre grappe de calcul est de générer une clé publique, qui sera partagée avec les ordinateurs distants, et une clé privée, qui sera conservée sur le système local.

Pour une utilisation transparente de la grappe de calcul, des clés privée et publique peuvent être utilisées. Le processus se fait en deux étapes :

  • Générer les clés publique et privée.
  • Copier la clé publique sur les nœuds esclaves.

Pour l'authentification basée sur l'utilisateur, générez et copiez les clés comme suit :

Exemple de code 2.15 : Authentification par clés SSH

# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): /root/.ssh/id_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
f1:45:15:40:fd:3c:2d:f7:9f:ea:55:df:76:2f:a4:1f root@master

Attention ! Si vous avez déjà un fichier « authorized_keys »,
vous devez ajouter la clé publique à la fin de ce fichier plutôt
qu'utiliser les commandes suivantes.

# scp /root/.ssh/id_dsa.pub node01:/root/.ssh/authorized_keys
root@master's password:
id_dsa.pub   100%  234     2.0MB/s   00:00

# scp /root/.ssh/id_dsa.pub node02:/root/.ssh/authorized_keys
root@master's password:
id_dsa.pub   100%  234     2.0MB/s   00:00

Note : Les clés des hôtes doivent avoir une phrase de passe vide. RSA est requis pour l'authentification basée sur l'hôte.

Pour l'authentification basée sur l'hôte, vous devrez également éditer le fichier /etc/ssh/shosts.equiv.

Exemple de code 2.16 : /etc/ssh/shosts.equiv

node01.adelie
node02.adelie
master.adelie

Vous devrez aussi apporter quelques modifications au fichier /etc/ssh/sshd_config :

Exemple de code 2.17 : Configuration de sshd

# $OpenBSD: sshd_config,v 1.42 2001/09/20 20:57:51 mouring Exp $
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# This is the sshd server system-wide configuration file.  See sshd(8)
# for more information.

# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key

Si vos applications nécessitent la communication par RSH, vous devrez installer net-misc/netkit-rsh et sys-apps/xinetd.

Exemple de code 2.18 : Installer les applications requises

# emerge -p xinetd
# emerge xinetd
# emerge -p netkit-rsh
# emerge netkit-rsh

Ensuite, configurez le démon rsh. Éditez le fichier /etc/xinet.d/rsh.

Exemple de code 2.19 : rsh

# Adelie Linux Research & Development Center
# /etc/xinetd.d/rsh

service shell
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = root
        group           = tty
        server          = /usr/sbin/in.rshd
        log_type        = FILE /var/log/rsh
        log_on_success  = PID HOST USERID EXIT DURATION
        log_on_failure  = USERID ATTEMPT
        disable         = no
}

Éditez votre fichier /etc/hosts.allow pour permettre les connexions par RSH :

Exemple de code 2.20 : hosts.allow

# Adelie Linux Research & Development Center
# /etc/hosts.allow

in.rshd:192.168.1.0/255.255.255.0

Alternativement, vous pouvez simplement faire confiance au réseau local de votre grappe de calcul :

Exemple de code 2.21 : hosts.allow

# Adelie Linux Research & Development Center
# /etc/hosts.allow

ALL:192.168.1.0/255.255.255.0

Finalement, configurez l'authentification de l'hôte avec le fichier /etc/hosts.equiv.

Exemple de code 2.22 : hosts.equiv

# Adelie Linux Research & Development Center
# /etc/hosts.equiv

master
node01
node02

Il ne reste plus qu'à ajouter xinetd à votre niveau d'exécution par défaut :

Exemple de code 2.23 : Ajouter xinetd au niveau d'exécution par défaut

# rc-update add xinetd default

NTP

Le « Network Time Protocol » (NTP) est utilisé pour synchroniser l'horloge d'un ordinateur client ou serveur avec celle d'un autre serveur ou source de référence, par exemple une radio, un satellite, un modem ou un système de positionnement global (GPS). Il assure une précision de l'ordre de la milliseconde dans un réseau local, ou de quelques dizaines de millisecondes au maximum dans un réseau étendu (WAN). La synchronisation se fait relativement au temps universel coordonné (UTC). Une configuration NTP typique emploie de multiples serveurs redondants et des chemins réseaux variés afin d'obtenir une exactitude et une fiabilité élevées.

Choisissez un serveur géographiquement proche de votre système à partir de la liste « Public NTP Time Servers », puis éditez les fichiers /etc/conf.d/ntp et /etc/ntp.conf sur le nœud maître.

Exemple de code 2.24 : /etc/conf.d/ntp sur le nœud maître

# /etc/conf.d/ntpd

# NOTES:
#  - NTPDATE variables below are used if you wish to set your
#    clock when you start the ntp init.d script
#  - make sure that the NTPDATE_CMD will close by itself ...
#    the init.d script will not attempt to kill/stop it
#  - ntpd will be used to maintain synchronization with a time
#    server regardless of what NTPDATE is set to
#  - read each of the comments above each of the variable

# Comment this out if you dont want the init script to warn
# about not having ntpdate setup
NTPDATE_WARN="n"

# Command to run to set the clock initially
# Most people should just uncomment this line ...
# however, if you know what you're doing, and you
# want to use ntpd to set the clock, change this to 'ntpd'
NTPDATE_CMD="ntpdate"

# Options to pass to the above command
# Most people should just uncomment this variable and
# change 'someserver' to a valid hostname which you
# can aquire from the URL's below
NTPDATE_OPTS="-b ntp1.cmc.ec.gc.ca"

##
# A list of available servers is available here:
# http://www.eecis.udel.edu/~mills/ntp/servers.html
# Please follow the rules of engagement and use a
# Stratum 2 server (unless you qualify for Stratum 1)
##

# Options to pass to the ntpd process that will *always* be run
# Most people should not uncomment this line ...
# however, if you know what you're doing, feel free to tweak
#NTPD_OPTS=""

Éditez ensuite /etc/ntp.conf sur le nœud maître pour paramétrer une source de synchronisation externe.

Exemple de code 2.25 : ntp.conf sur le nœud maître

# Adelie Linux Research & Development Center
# /etc/ntp.conf

# Synchronization source #1
server ntp1.cmc.ec.gc.ca
restrict ntp1.cmc.ec.gc.ca
# Synchronization source #2
server ntp2.cmc.ec.gc.ca
restrict ntp2.cmc.ec.gc.ca
stratum 10
driftfile /etc/ntp.drift.server
logfile  /var/log/ntp
broadcast 192.168.1.255
restrict default kod
restrict 127.0.0.1
restrict 192.168.1.0 mask 255.255.255.0

Après cela, configurez la source de synchronisation de tous les nœuds esclaves pour qu'ils se réfèrent au nœud maître.

Exemple de code 2.26 : /etc/conf.d/ntp sur les nœuds esclaves

# /etc/conf.d/ntpd

NTPDATE_WARN="n"
NTPDATE_CMD="ntpdate"
NTPDATE_OPTS="-b master"

Exemple de code 2.27 : ntp.conf sur les nœuds esclaves

# Adelie Linux Research & Development Center
# /etc/ntp.conf

# Synchronization source #1
server master
restrict master
stratum 11
driftfile /etc/ntp.drift.server
logfile  /var/log/ntp
restrict default kod
restrict 127.0.0.1

Enfin, ajoutez ntpd au niveau d'exécution par défaut sur tous les nœuds :

Exemple de code 2.28 : Ajouter ntpd au niveau d'exécution par défaut

# rc-update add ntpd default

Note : NTP ne mettra pas à jour l'horloge locale si la différence de temps entre cette horloge et la source de synchronisation est trop grande.

Iptables

Vous aurez besoin de iptables pour installer un pare-feu sur votre grappe de calcul.

Exemple de code 2.29 : Installer iptables

# emerge -p iptables
# emerge iptables

Configuration du noyau nécessaire :

Exemple de code 2.30 : Configuration du noyau pour iptables

CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_LOG=y

Voici maintenant les règles du pare-feu :

Exemple de code 2.31 : rule-save

# Adelie Linux Research & Development Center
# /var/lib/iptables/rule-save

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s 192.168.1.0/255.255.255.0 -i eth1 -j ACCEPT
-A INPUT -s 127.0.0.1 -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -j LOG
-A INPUT -j REJECT --reject-with icmp-port-unreachable
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -s 192.168.1.0/255.255.255.0 -j MASQUERADE
COMMIT

Finalement, ajoutez iptables au niveau d'exécution par défaut de tous les nœuds :

Exemple de code 2.32 : Ajouter iptables au niveau d'exécution par défaut

# rc-update add iptables default

3.  Outils HPC

OpenPBS

« Portable Batch System » (PBS) est un système pour la gestion de files de travaux et de la répartition de la charge. PBS a été initialement développé pour la NASA. Il fonctionne sur les environnements UNIX multi plates-formes en réseau, incluant les grappes de calcul hétérogènes formées de stations de travail, de superordinateurs et de systèmes massivement parallèles. Le développement de PBS est assuré par Altair Grid Technologies.

Exemple de code 3.1 : Installer openpbs

# emerge -p openpbs

Note : L'ebuild pour OpenPBS n'attribue pas les bonnes permissions aux répertoires utilisés par OpenPBS dans /var.

OpenPBS doit être configuré avant que vous ne puissiez l'utiliser. Les fichiers qui doivent être personnalisés en fonction de votre système sont :

  • /etc/pbs_environment
  • /var/spool/PBS/server_name
  • /var/spool/PBS/server_priv/nodes
  • /var/spool/PBS/mom_priv/config
  • /var/spool/PBS/sched_priv/sched_config

Voici un exemple de sched_config :

Exemple de code 3.2 : /var/spool/PBS/sched_priv/sched_config

#
# Create queues and set their attributes.
#
#
# Create and define queue upto4nodes
#
create queue upto4nodes
set queue upto4nodes queue_type = Execution
set queue upto4nodes Priority = 100
set queue upto4nodes resources_max.nodect = 4
set queue upto4nodes resources_min.nodect = 1
set queue upto4nodes enabled = True
set queue upto4nodes started = True
#
# Create and define queue default
#
create queue default
set queue default queue_type = Route
set queue default route_destinations = upto4nodes
set queue default enabled = True
set queue default started = True
#
# Set server attributes.
#
set server scheduling = True
set server acl_host_enable = True
set server default_queue = default
set server log_events = 511
set server mail_from = adm
set server query_other_jobs = True
set server resources_default.neednodes = 1
set server resources_default.nodect = 1
set server resources_default.nodes = 1
set server scheduler_iteration = 60

Pour soumettre une tâche à OpenPBS, la commande qsub est utilisée avec quelques paramètres optionnels. Dans l'exemple ci-dessous, -l spécifie les ressources requises, -j redirige la sortie et l'erreur standards et -m envoie un courrier à l'utilisateur au début (b) et à la fin (e) de la tâche ou si la tâche est annulée (a).

Exemple de code 3.3 : Soumettre une tâche

(Demande à OpenPBS d'exécuter « monscript » sur 2 nœuds de calcul.)
# qsub -l nodes=2 -j oe -m abe monscript

Habituellement, les tâches sont soumises à OpenPBS sous forme de scripts. Parfois, vous voudrez exécuter une tâche manuellement. Pour ce faire, ouvrez un shell OpenPBS interactif avec l'option -I.

Exemple de code 3.4 : Ouvrir un shell interactif

# qsub -I

Pour consulter l'état de vos tâches, utilisez la commande qstat.

Exemple de code 3.5 : Vérifier l'état des tâches

# qstat
Job id  Name  User   Time Use S Queue
------  ----  ----   -------- - -----
2.geist STDIN adelie 0        R upto1nodes

MPICH

Les procédures d'échange de messages (en anglais « message passing ») sont fréquemment utilisées avec certains types de machines fonctionnant en parallèle, particulièrement celles qui utilisent de la mémoire distribuée. MPICH est une implémentation gratuite et portable de MPI, le standard pour les bibliothèques d'échange de messages.

L'ebuild pour MPICH fourni par Adelie Linux propose deux options USE : doc et crypt. Activer doc installera la documentation, alors qu'activer crypt configurera MPICH pour qu'il utilise ssh plutôt que rsh.

Exemple de code 3.6 : Installer MPICH

# emerge -p mpich
# emerge mpich

Vous devrez peut-être exporter un répertoire de travail sur tous vos nœuds esclaves dans le fichier /etc/exports :

Exemple de code 3.7 : /etc/exports

/home   *(rw)

La plupart des processeurs massivement parallèles (en anglais « massively parallel processors », MPP) permettent de lancer un programme sur un nombre spécifique de processeurs ; mpirun utilise la commande appropriée lorsque c'est possible. À l'inverse, les grappes de stations de travail nécessitent que chaque processus dans une tâche parallèle soit démarré individuellement (bien qu'il existe des programmes pour aider au démarrage de ces processus). Puisque les grappes de stations de travail ne sont pas organisées en MPP à la base, il faut procéder à leur configuration. MPICH devrait disposer de la liste des stations de travail participantes dans le fichier machines.LINUX situé dans le répertoire /usr/share/mpich/. Ce fichier est utilisé par mpirun pour la sélection des processeurs à utiliser.

Éditez ce fichier pour qu'il reflète la configuration de votre grappe et de votre réseau :

Exemple de code 3.8 : /usr/share/mpich/machines.LINUX

# Change this file to contain the machines that you want to use
# to run MPI jobs on.  The format is one host name per line, with either
#    hostname
# or
#    hostname:n
# where n is the number of processors in an SMP.  The hostname should
# be the same as the result from the command "hostname"
master
node01
node02
# node03
# node04
# ...

Utilisez le script tstmachines situé dans /usr/sbin/ pour vous assurer que vous pouvez employer toutes les machines que vous avez listées. Ce script utilise rsh pour se connecter et liste le contenu d'un répertoire ; ce test vérifie que vous pouvez accéder au nœud distant et qu'un programme situé dans le répertoire courant sera également visible par le nœud courant. Si des problèmes surviennent, ils seront affichés ; vous devrez les corriger avant de poursuivre.

La seule option à fournir à tstmachines est le nom de l'architecture. Ce nom correspond à l'extension du fichier contenant la liste des machines. Par exemple, la commande suivante vérifie qu'un programme dans le répertoire courant peut être exécuté par toutes les machines dans la liste LINUX.

Exemple de code 3.9 : Exécuter un test

# /usr/local/mpich/sbin/tstmachines LINUX

Note : Ce programme ne génère aucune sortie si tout va bien ; si vous voulez savoir ce que le programme fait, utilisez l'option -v (volubile) :

Exemple de code 3.10 : Exécuter un test en mode volubile

# /usr/local/mpich/sbin/tstmachines -v LINUX

La sortie de cette commande ressemblera à ce qui suit :

Exemple de code 3.11 : Sortie de la commande précédente

Trying true on host1.uoffoo.edu ...
Trying true on host2.uoffoo.edu ...
Trying ls on host1.uoffoo.edu ...
Trying ls on host2.uoffoo.edu ...
Trying user program on host1.uoffoo.edu ...
Trying user program on host2.uoffoo.edu ...

Si tstmachines découvre un problème, il donnera une liste de causes possibles accompagnée de suggestions pour le régler. En résumé, trois tests sont effectués :

  • Est-il possible d'exécuter des processus sur les machines distantes ? tstmachines essaie d'exécuter la commande shell true sur chaque machine de la liste en exécutant un shell distant.
  • Le répertoire courant est-il disponible sur toutes les machines ? La commande ls est exécutée dans un shell distant pour vérifier la disponibilité d'un fichier créé par tstmachines (dans le répertoire courant).
  • Les programmes utilisateurs peuvent-ils être exécutés sur les systèmes distants ? Ce test vérifie si les bibliothèques partagées et les autres composantes ont été installées correctement sur toutes les machines.

Bien sûr, n'oublions pas le test classique pour tout outil de développement :

Exemple de code 3.12 : Tester un outil de développement

# cd ~
# cp /usr/share/mpich/examples1/hello++.c ~
# make hello++
# mpirun -machinefile /usr/share/mpich/machines.LINUX -np 1 hello++

Pour plus d'information sur MPICH, consultez la documentation disponible à l'adresse : http://www-unix.mcs.anl.gov/mpi/mpich/docs/mpichman-chp4/mpichman-chp4.htm.

LAM

(Bientôt disponible !)

OMNI

(Bientôt disponible !)

4.  Bibliographie

La version originale de ce document est publiée sur le site Web du Centre de R&D Adelie Linux. Le document est reproduit avec la permission des auteurs, du Centre de R&D Adelie Linux et de Cyberlogic.



Imprimer

Dernière mise à jour le 18 décembre 2006

La version originale de cette traduction n'est plus maintenue

Résumé : Ce document a été écrit par des membres du centre de recherche et de développement Adelie Linux et se veut un guide étape par étape permettant de transformer un système Gentoo en un système pour le calcul de haute performance.

Marc St-Pierre
Auteur

Benoit Morin
Auteur

Jean-Francois Richard
Assistant/Recherche

Olivier Crête
Assistant/Recherche

Donnie Berkholz
Relecteur

Olivier Fisette
Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.