First steps with the cluster MUSE
The very first step consists in checking if your connection to the cluster is working fine. You use the protocol SSH and the client ssh. To test you connection, use :
ssh nomlogin@muse-login01.hpc-lr.univ-montp2.fr where nomlogin is your user identifier. Once you have written your password, you may get this answer :
nomlogin@muse-login01.hpc-lr.univ-montp2.fr password:
Last login: Mon Mar 29 11:03:29 2021 from 162.38.141.123If it is really your first attempt to log on, the cluster replies also that the cluster host is registered as a new regular destination for your ssh actions. If you get a message claiming that you cannot connect, you must contact the administrator to solve this problem first before going forth.
It is quite annoying to write your password each time you want to connect to the cluster. A first step to simplify the connection procedure is to use the SSH protocol with private/public keys. In brief, a private key is stored on your own computer, and a corresponding public key (derived from the private one) is sent to the remote cluster safely. When you tentatively log on the cluster from your own computer, the cluster compares the signature of your private key with the public key provided to the cluster previously. If they are the same, you can log on successfully.
To create a key, you have to use the command:
ssh-keygen
The name of the local file to store the private and public keys is asked. For instance, name your file id_rsa_your-name. This results in the creation of a file id_rsa_your-name containing the private key, and a file file id_rsa_your-name.pub storing the public one. A passphrase will be asked also. If you set one, you will have to write it each time you connect. It is up to you keeping in mind that setting no passphrase is less secure. In all cases, remember your passphrase as cautionously as you remember your original password.
Then to copy securely you public key to the Muse cluster, you can use:
nomlogin@muse-login01.hpc-lr.univ-montp2.fr's password:
Last login: Mon Mar 29 11:03:29 2021 from 162.38.141.123
La suite
La connexion au cluster de calcul haute performance se fait via le protocole SSH. Le nom d’hôte de la machine de connexion est « muse-login.hpc-lr.univ-montp2.fr ».
Suivant votre système d’exploitation, vous pouvez vous y connecter comme suit :
Sous linux :
Ouvrir une connexion ssh dans un terminal en tapant la commande suivante : « ssh -X « nom_utilisateur »@muse-login.hpc-lr.univ-montp2.fr »
(L’option -X permet d’avoir un affichage graphique)
Sous windows :
Installer le logiciel putty , ouvrir putty en remplissant les champs de configuration comme suit :
– Hostname : « muse-login.hpc-lr.univ-montp2.fr »
– Connection type : « SSH »
Cliquer ensuite sur « Open » et remplir les champs « login as» et « password » avec ceux fournis lors de la création du compte.
Vous êtes connecté au cluster Muse.
Si vous souhaitez obtenir un affichage graphique, installer le logiciel Xming et l’ouvrir. Rajouter l’option suivante avant d’appuyer sur « Open » dans putty :
« Category > Connection > SSH > X11 > Cocher Enable X11 forwarding »
Sous Mac :
Installer Xquartz et l’ouvrir
Entrer la commande :
ssh -X « nom_utilisateur »@muse-login.hpc-lr.univ-montp2.fr
Quel que soit votre système d’exploitation, lors de la première connexion pensez à utiliser la commande « passwd » sur le cluster pour changer le mot de passe par défaut.
Présentation du cluster Muse & bonnes pratiques
Nous organisons régulièrement des sessions de formation pour « présenter le calculateur » et « comment lancer son premier job ».
Les supports de présentation sont disponibles, n’hésitez pas à les utiliser.
Rappel des points de vigilance :
–> Les machines muse-login (muse-login01 et muse-login02) sont les interfaces utilisateur de connexion au cluster.
Les jobs sont lancés depuis muse-login mais ne doivent pas être exécutés sur muse-login, mais via le gestionnaire de job SLURM.
Une charge trop importante des serveurs frontaux pénalise l’ensemble des utilisateurs, ce qui nous amène à supprimer ces jobs. plus d’information sur l’utilisation du gestionnaire de tâche SLURM plus bas.
–> espace de stockage: Il y a plusieurs espaces de stockage (voir détail ci-dessous). Les fichiers déposés sur le répertoire « scratch » sont temporaires pour effectuer vos calcul, et sont automatiquement supprimés à 60 jours. Les documents destinés à être conservés doivent être déposés sur votre répertoire « home ».
Premier pas sous un environnement Linux
Le cluster est sous Linux et ne possède pas d’interface graphique. A cet effet, voici une liste de commandes vous permettant de réaliser des actions basiques une fois connecté :
– ls : liste le contenu de votre répertoire
– cd « chemin_du_dossier » : pour se déplacer dans les sous dossiers de votre répertoire
– pwd : affiche le répertoire courant
– mv (ou cp) fichier_base fichier_destination : déplace (ou copie) un fichier
– mkdir « nom_dossier » : crée un sous-dossier dans le répertoire courant
– vim (ou nano) « fichier_texte » : édite un fichier (le crée si il n’existe pas)
– cat « fichier_texte » : affiche le contenu du fichier
N’hésitez pas à consulter le site suivant pour découvrir d’autres possibilités https://doc.ubuntu-fr.org/tutoriel/console_commandes_de_base
Le gestionnaire d’environnement module
Le gestionnaire d’environnement module permet de configurer les variables d’environnements adaptées à votre programme. Les modules fonctionnent par groupe. Pour obtenir l’ensemble des modules d’un groupe, il vous faut utiliser la commande « module load group ». Par exemple, pour le module le plus courant est « module load cv-standard » et ensuite vous pouvez taper « module available » pour obtenir la liste des modules présents dans le groupe « cv-standard ». Sélectionnez ensuite le compilateur, la bibliothèque MPI et les bibliothèques de routines scientifiques selon vos besoins et chargez-les :
GNU compilers, Intel icc/icpc/ifort
OpenMPI, Intel MPI, mpich, mvapich, mvapich2, etc…
Blas, Lapack, hdf5, fftw3, etc…
Exemple :
$ module load openmpi/2.0.1
$ module load gcc/4.9.3
Les principales options sont :
$ module available : Liste des modules disponibles.
$ module list : Liste des modules chargés dans votre environnement.
$ module show : Description du module.
$ module purge : Supprime tous les modules de votre environnement.
$ module add/load : Charge le module dans votre environnement.
$ module rm/unload : Supprime le module de votre environnement.
La liste des modules installés est disponible en bas de page
Utilisation du gestionnaire de tâche SLURM sur le cluster MUSE
Il y a deux modes d’exécution d’un calcul :
⇒ Un mode d’exécution en temps réel avec la commande srun
⇒ Un mode d’exécution différé avec la commande sbatch.
Avec la commande « srun » les paramètres d’exécution sont renseignés en ligne. Avec la commande « sbatch » les paramètres d’exécution sont renseignés dans un fichier batch.
Nous vous recommandons d’utiliser le mode différé.
Exemple de fichier batch :
#!/bin/sh
#SBATCH –job-name=test
#SBATCH -N 3
#SBATCH -n 9
#SBATCH –ntasks-per-node=3
#SBATCH –ntasks-per-core=1
#SBATCH –partition=defq
#SBATCH –time=01:00:00
echo « Running on: $SLURM_NODELIST »
mpirun ./mon_programme.exe
Le job nommé ‘test’ va s’exécuter sur 3 cœurs * 3 nœuds soit 9 cœurs au total. La queue de calcul est ‘defq’ et avec une durée limite d’une heure.
La variable d’environnement $SLURM_NODELIST permet de récupérer le nom des nœuds sur les quels le job est exécuté.
Chaque ligne commençant par « #SBATCH » décrit un paramètre SLURM. Il est important que ces paramètres se trouvent en haut de fichier avant la première instruction à exécuter.
Remarque : Pour certains paramètres (mais pas tous) il existe deux écritures différentes. Une écriture longue et une écriture courte. Ainsi le nom du job peut être déclaré par ‘–job-name=test’ ou par ‘-J test’. Le nombre de nœuds de calcul peut être déclaré par ‘–nodes=3’ ou par ‘-N 3’ (notez que la syntaxe est un peu différence selon le format utilisé).
Attention au temps de calcul par défaut les queues de calcul « defq » et « thau-smp » ont un temps d’allocation de 7 jours par défaut.
Avant de lancer votre Job, le système vérifie que vous disposez du quota suivant : (7 jours * 24heures * nombres de coeurs demandés pour votre job)
Si vous ne disposez pas du quota nécessaire vous aurez les messages d’erreur suivant : « queued and waiting for resources » (avec la commande squeue : « QOSGrpCPUMinutesLimit »)
Pour pallier à cela vous devez ajouter la variable « –time=HH:MM:SS » en indiquant le nombre d’heures que vous estimez nécessaire à la réalisation du calcul
Notre conseil : arrondir au-dessus. Il ne s’agit que d’une estimation et non pas un décompte d’heure réel
Seules les heures réellement calculées seront déduites de votre quota
Le tableau ci-dessous récapitule les principaux paramètres :
Format long Format court Description
–job-name -J Nom du job
–account Nom du projet
–nodes -N Nombre de nœuds
–ntasks -n Nombre de tâches au total
–ntasks-per-node Nombre de tâches par nœud (doit correspondre au nombre total de tâches divisé par le nombre de nœuds)
–ntasks-per-core Nombre de tâches par cœurs (en général 1)
–partition -p Groupe de machines sur lequel le job va tourner
–mem Mémoire réservée par nœud en MegaBytes? (Si cette option n’est pas spécifiée la totalité de la mémoire du nœud est allouée)
–time -t Le temps maximum durant lequel le job va tourner (Passé ce délai, le job est automatiquement arrété)
–output -o Le nom du fichier oû sera écrit les sorties. Par défaut slurm-%j.out ou ‘%j’ est le numéro du job
–error -e Le nom du fichier oû seront écrit les messages d’erreur. Par défaut slurm-%j.err ou ‘%j’ est le numero du job
–time=HH:MM:SS -t HH:MM:SS Temps limite de votre job en heures, minutes et secondes.
–mail-user Adresse mail à laquelle les notifications seront envoyées
Si vous exécutez un job OpenMP renseignez la variable d’environnement OMP_NUM_THREADS dans votre fichier batch à la suite des paramètres.
Exemple : export OMP_NUM_THREADS=12
Remarque : La commande « srun » peut être utilisée à l’intérieur d’un fichier batch que l’on exécute avec la commande « sbatch ». Dans ce cas les paramètres peuvent être renseignés à la suite de la commande srun.
Autres commandes SLURM utils :
$ squeue : Affiche la liste des jobs avec leurs états
$ scancel 221 : Supprime le job 221 de la queue
$ sinfo : Liste les partitions de calcul avec leurs caractéristiques
$ scontrol show jobid 221 : Affiche le détail du job 221
Quelques ressources d’initiation à l’utilisation du Cluster
1-Presentation_cluster_Muse
1-TP-Environment_module
1-TP-SLURM
Décompte des heures sur le Cluster MUSE
La commande « mon_nbre_heures » est disponible à tout moment sur « muse-login » pour vous permettre de vérifier votre consommation d’heure de calcul.
Exemple de scripts optimisés pour le cluster MUSE
slurm_muse_exemple
Dans cette archive vous trouverez :
– un exemple de job MPI
– un exemple de job OpenMP
– un exemple de job MPI + OpenMP
A noter : Les paramètres utilisés dans les 3 exemples, optimisés pour l’utilisation de slurm, sont transférable à l’ensemble de vos job sous Slurm.
Comment organiser ses fichiers
Montage Description Utilisation Quota Péremption
/home NFS Fichiers de configuration globale
code, bibliothèques
Partagé avec le groupe
(en général 50GigaOctet
partagé) Non
/nfs/work NFS Fichiers de configuration des travaux
Données d’entrée et de sortie
Copie des exécutables
Partagé avec le groupe
(en général 50GigaOctet
partagé) Non
/lustre/scratch
lustre Exécution des travaux
Donnée temporaires
Le répertoire Scratch est à utiliser impérativement pour l’exécution des jobs. Les résultats peuvent ensuite être déplacés vers les répertoires /home ou /work
Non
2 mois
Au delà, les données sont effacées
Il faut TOUJOURS utiliser votre répertoire de scratch pour l’exécution de vos jobs et ensuite déplacer les résultats que vous souhaitez conserver sur votre /home ou /work.
Copier des fichiers de façon sécurisée depuis le Cluster Muse
rsync
Ce fichier vous permet de copier des données depuis le cluster Muse vers votre machine LINUX.
Il vous faut modifier les champs USER, DOSSIER_CLUSTER et DOSSIER_PERSO et ensuite le lancer avec la commande « bash rsync ».
Il est vivement conseillé d’utiliser ce script lors de téléchargement de fichiers volumineux.
#! /usr/bin/env bash
###################################################################
# rsync.sh : Ecrit par Jérémy Verrier #
# Script permettant la copie sécurisée de fichiers ou de dossiers #
###################################################################
# Entrez votre nom d’utilisateur
USER=
# Entrez le chemin complet du répertoire ou du fichier à copier (/home/verrier/work/results.txt)
DOSSIER_CLUSTER=
# Entrez le chemin complet du répertoire ou du fichier de destination
DOSSIER_PERSO=
while [ 1 ]
do
rsync -avz –progress –partial “${USER}”@muse-login.hpc-lr.univ-montp2.fr:”${DOSSIER_CLUSTER}” “${DOSSIER_PERSO}”
if [ “$?” = “0” ] ; then
echo “Rsync OK”
exit
else
echo “Rsync erreur, nouvelle tentative dans 1 minute…”
sleep 60
fi
done
Installation d’un logiciel au niveau d’un groupe
1) Quand je charge un module (depuis un script de scratch) avec “module load fluidity/openmpi316/gcc75/snapshot”, est-ce que cela pointe vers le répertoire “softs” de mon home ? vers le répertoire “softs” du work ? Les deux ?
2) Puis-je simplement déplacer mon dossier “/home/garelf/softs/fluidity” dans un dossier “/home/garelf/work_fluidity/softs” ou dois-je refaire l’install complète ?
réponse de Fabien:
Si vous voulez faire une installation de groupe, vous pouvez refaire une installation avec PAGURE en spécifiant votre dossier partagé pour les exécutables et votre dossier partagé pour l’environnement module.
Par exemple :
–prefix=/nfs/work/fluidity/softs –module-dir=/nfs/work/fluidity/softs/modules
Il vous faut ensuite créer un fichier module qui chargera les modules de votre groupe (exactement comme le module cv-standard)
Par exemple :
Créer un fichier /nfs/work/fluidity/softs/fluidity avec le contenu suivant
module use –append /nfs/work/fluidity/softs/modules
Vous pourrez alors faire
module load /nfs/work/fluidity/softs/fluidity
Et vous aurez accès au installation du groupe.
Vous pouvez déplacer le contenu de /home/garelf/soft vers /nfs/work/fluidity/softs et le contenu /home/garelf/privatemodules dans /nfs/work/fluidity/modules
MAIS il vous faudra éditer tous les chemins dans les fichiers de module du dossier /nfs/work/fluidity/modules
Copie de scratch vers un autre lieu
Avec la nouvelle politique d’accès aux système de fichiers, les noeuds du cluster n’ont d’accès en écriture que sur le “scratch”, qui n’est pas un stockage pérenne. Afin de sauver automatiquement les résultats et autres “artefacts” de vos calculs sur le cluster, il est donc utile de pouvoir décorer le lancement de ses batchs avec une sauvegarde automatique sur un stockage pérenne (work/home) à la fin de celui-ci. Supposons que vous avez un fichier de batch “mon_batch.sh”
Créez un autre fichier fichier mon_batch_sauve.sh
#!/bin/bash
sbatch -W mon_batch.sh \ # l’option -W permet d’être sûr que le job est fini
&& cp scrach/vos_résultats.txt work/votre_répertoire_de_sauvegarde
Ici && permet de garantir que le code qui suit la terminaison du batch ne s’effectue que si celui-ci s’est correctement terminé (pas de cancel ou de plantage par exemple). Si vous voulez faire une sauvegarde inconditionnelle remplacez simplement par :
sbatch -W mon_batch.sh
cp scrach/vos_résultats.txt work/votre_répertoire_de_sauvegarde
Et finalement pour le lancer :
nohup bash mon_batch_sauve.sh &
nohup permet de garantir que le process continue de tourner si vous vous déconnectez ou que vous perdez votre session sur le frontal (autre possibilité, à lancer dans un screen ou un tmux, pour ceux qui connaissent)
Documentation de l’option –wait
-W, –wait
Do not exit until the submitted job terminates. The exit code of the sbatch command will be the same as the exit code of the submitted job. If the job terminated due to a signal rather than a normal exit, the exit code will be set to 1. In the case of a job array, the exit code recorded will be the highest value for any task in the job array.