Environnement

Connexion à la machine

Elle s’effectue en ssh sur : occigen.cines.fr

ssh <mon_login>@occigen.cines.fr

Le système d’exploitation est de type linux basé sur la suite logicielle BullX SCS (Redhat).
Le cluster comprend plusieurs nœuds de connexion pour les utilisateurs. Lorsque la connexion est établie, l’utilisateur se trouve sur un de ces nœuds. L’affectation des connexions se fait en fonction de la disponibilité des nœuds de login. Il peut arriver que deux connexions simultanées aboutissent sur deux nœuds de login différents.

Environnement logiciel : modules

Le CINES met à disposition de nombreux logiciels sur ses clusters, et souvent plusieurs versions de chaque logiciel. Afin d’éviter les conflits entre différentes versions d’un même logiciel, il faut généralement définir un environnement propre à chaque version.

Les logiciels disponibles peuvent être visualisés ou chargés via les commandes suivantes :

module avail 
afficher la liste des environnements disponibles
module load 
charger une librairie ou un logiciel dans votre environnement
module list 
afficher la liste des environnements chargés
module purge 
retirer un environnement déjà chargé
module show 
voir le contenu du module

 

Environnement de soumission de travaux (SLURM)

Les nœuds de calcul de la machine Occigen peuvent être utilisés dans deux modes :

  • Le mode exclusif
  • Le mode partagé

1) Travaux en mode « EXCLUSIF »

 

Après la mise en Production en février 2017 de l’extension d’Occigen, constituée de nœuds avec des processeurs Broadwell, la soumission de travaux s’effectue sur deux partitions bien distinctes à savoir : la tranche des processeurs Haswell (24 cœurs) et celle des processeurs Broadwell (28 cœurs), un travail ne pouvant utiliser simultanément les deux types de processeurs.

 

Depuis le printemps 2018, nous proposons plus de flexibilité, en permettant de demander également soit les deux architectures en même temps, soit l’une ou l’autre sans préciser laquelle. Le tableau ci-dessous résume les différentes possibilités et la directive de SLURM associée à chaque cas.

 

 

 

Type de travail Choix de processeurs Directive SLURM
Code OpenMP

Des nœuds Haswell uniquement

 

--constraint=HSW24

Des nœuds Broadwell uniquement

 

--constraint=BDW28

 

 

Code parallèle MPI /

Code Hybride

Des nœuds Haswell uniquement

 

--constraint=HSW24

Des nœuds Broadwell uniquement

 

--constraint=BDW28

Une configuration précise de x nœuds Haswell et y nœuds Broadwell

 

--constraint="[HSW24*x&BDW28*y]"

Les nœuds Haswell ou Broadwell indifféremment (mélange HSW24 et BDW28 possible)

 

--constraint=HSW24|BDW28

Tous les nœuds du même type, Haswell ou Broadwell selon les disponibilités

 

--constraint=[HSW24|BDW28]

 

Vous trouverez des modèles de script de soumission batch décrivant tous ces cas dans le gitlab du CINES dans le répertoire suivant :

https://git.cines.fr/support/hello_world/wikis/scripts

 

2) Travaux en mode « PARTAGE »

Dans le mode partagé, plusieurs jobs peuvent tourner de façon simultanée dans un nœud. Un mécanisme technique empêche les jobs de s’interpénétrer, il ne peut pas y avoir d’écrasement de zones mémoire, ni de « vol » de cycles CPU.

Par défaut, tous les jobs qui demandent moins de 24 cœurs seront en mode partagé.

Tous les nœuds de la partition partagée disposent de 128 Go de mémoire.

Les jobs dont la demande est supérieure à 23 cœurs ne sont pas concernés par le mode partagé, pas plus que les jobs qui demandent explicitement le mode exclusif.

 

3) Commandes

Ce tableau fournit les commandes utiles pour la soumission des travaux.

Action commande
Soumettre un travail
sbatch script_soumission.slurm
Lister l’ensemble des travaux
squeue
Lister ses propres travaux
squeue –u <login>
Afficher des caractéristiques d’un travail
scontrol show job
Prévision d’horaire de passage d’un travail
squeue –start –job <job_id>
Prévision d’horaire de passage de ses propres travaux
squeue –u <login> --start
Annuler un travail
scancel <job_id>

 

4) Variables d’environnement

Les variables utilitaires suivantes (liste non exhaustive) peuvent être exploitées dans les commandes utilisateurs (Shell) d’un script de soumission.

Nom de variable valeur
$SLURM_JOB_ID Identification du travail
$SLURM_JOB_NAME Nom du travail (spécifié par « #SBATCH -J »)
$SLURM_SUBMIT_DIR Nom du répertoire initial (dans lequel la commande sbatch a été lancée)
$SLURM_NTASKS Nombre de processus MPI du travail

5) Options SBATCH courantes

Dans le script SLURM pour donner des indications sur les ressources il est possible d’utiliser les directives suivantes :

  • Pour indiquer le nombre de nœuds physique de la machine :
    #SBATCH --nodes=W

  • Pour indiquer le nombre total de tâches MPI qui vont tourner sur des nœuds contenant 48 ou 56 cœurs hyperthreadés, utilisez la directive suivante :
    #SBATCH --ntasks=X

  • Pour indiquer pour les codes OpenMP combien de threads seront affectés par cœur de la machine :
    #SBATCH --threads-per-core=Y

  • Pour indiquer la quantité mémoire que l’on désire dans un noeud (ne peut pas dépasser la mémoire totale du nœud, 64 Go ou 128 Go) :
    #SBATCH --mem=Z

  • Enfin cette directive est un indicateur qui précise que vous ne voulez pas partager le nœud sur lequel va tourner votre job avec un autre job :
    #SBATCH --exclusive

Dans un nœud partagé, chaque job peut consommer tout ou partie de la mémoire du nœud.

Ou alors, un job peut demander à consommer beaucoup plus de mémoire.

Dans ce second cas, le gestionnaire de travaux ne placera pas de nouveau job dans ce nœud, tant que la mémoire ne sera pas libérée. Pour ce cas d’exemple, le job J1 se verra facturer 1 cœur, alors que le job J2 se verra facturer 5 cœurs (maximum entre le nombre de cœur demandés (–ntasks=1) et sa taille mémoire divisé par 5). Sur cet exemple simplifié, le maximum est 5, il sera donc facturé 5 cœurs..

Voici quelques exemples d’utilisation de ces paramètres
Exemple1:

 #SBATCH –nodes=1 # Un seul nœud #SBATCH –ntasks=48 # Autant de tâches que souhaité #SBATCH –threads-per-core=2 # Nombre de tâches par cœur physique : soit un sous multiple du nombre de tâches –> on réserve ici 24 cœurs physiques

Si vous ne réservez pas la totalité des ressources cœurs et/ou mémoire, un autre job pourra démarrer sur le nœud en utilisant les ressources restantes.

Il est possible d’imposer le mode « nœud dédié » en utilisant la directive :

#SBATCH –exclusive

Si aucune demande mémoire n’est précisée par l’utilisateur dans le script de soumission, le job qui tourne sur un nœud partagé se voit affecter une limite mémoire de 1 Go par tâche.
La valeur par défaut est volontairement faible pour inciter les utilisateurs à définir leurs besoins. Voici la directive à utiliser pour exprimer son besoin mémoire :

#SBATCH –mem=4000 # 4 Go de mémoire garantie par tâche

6) Erreurs fréquentes :

Lorsqu’un job dépasse sa demande mémoire, le processus qui en est responsable est tué par SLURM et le job arrêté. Les autres jobs actifs sur ce nœud ne seront pas impactés. Si un job provoque un « débordement mémoire », celui-ci est traité au niveau du noyau Linux et ni le nœud, ni les autres jobs ne devraient être impactés.
Un message d’erreur apparaît alors dans le fichier de sortie :

/SLURM/job919521/slurm_script: line 33: 30391 Killed /home/user/TEST/memslurmstepd: Exceeded step memory limit at some point.

Les jobs partagés seront aussi pris en compte dans le processus de blocage en cas de sur-occupation des espaces de stockage /home et /scratch. Les jobs partagés seront affectés dans des partitions dont le nom sera suffixé par s. Exemple : BLOCKED_home_s pour un job partagé bloqué pour dépassement d’un quota sur /home.

Pour constater qu’un job est démarré en mode partagé il suffit de regarder la partition dans laquelle il est affecté :

login@occigen54:~/TEST$ squeue -u login JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 919914 shared TEST_SHA login R 0:04 1 occigen3100

On voit que le job 919914 tourne dans la partition shared.

Pour connaître l’état des nœuds partagés lancer la commande : sinfo -p shared -o « %.15n %.8T %.8m %.8O %.8z %.14C »

gil@occigen57:~/TEST$ sinfo -p shared -o « %.15n %.8T %.8m %.8O %.8z %.14C » HOSTNAMES STATE MEMORY CPU_LOAD S:C:T CPUS(A/I/O/T) occigen3100 mixed 128000 0.00 2:12:2 24/24/0/48 occigen3101 idle 128000 0.00 2:12:2 0/48/0/48 occigen3102 idle 128000 0.00 2:12:2 0/48/0/48 occigen3103 idle 128000 0.01 2:12:2 0/48/0/48 occigen3104 idle 128000 0.01 2:12:2 0/48/0/48 occigen3105 idle 128000 0.00 2:12:2 0/48/0/48 gil@occigen57:~/TEST$

On voit qu’il y a (au moment de la commande) six nœuds dans la partition « shared » (occigen3100 à 3105).

Le nœud occigen3100 en l’état « mixed » contient déjà un ou plusieurs jobs.

Le nœud était occupé sur la moitié de ses cœurs (24/24/0/48). 24 cœurs alloués, 24 cœurs idle, 0 en l’état « autre », et 48 cœurs maximum par nœuds.

Dernière modification le : 20 août 2018
CINES