Utilisation du Cluster (et OAR) au Centre Blaise Pascal

Les éléments de cette page ne sont plus valables : se reporter à la page Utilisation du Cluster (et GridEngine) au Centre Blaise Pascal

Ce qu'il faut retenir !

  • pour se connecter sur la passerelle de cluster :
    ssh <login>@styx.cbp.ens-lyon.fr
  • pour connaître les noeuds disponibles : oarnodes
  • pour connaître l'état des tâches : oarstat
  • pour réserver une machine en mode intéractif : oarsub -I
  • pour lancer une tâche définie par le script OAR MyJob.sh : oarsub -S MyJob.oar

Introduction

Le Centre Blaise Pascal dispose de plateaux techniques, notamment des noeuds de clusters, destinés :

  • à l'initiation au calcul scientifique, notamment MPI, OpenMP, CUDA OpenCL
  • au développement d'applications dans le domaine du calcul scientifique
  • à l'intégration de démonstrateurs agrégeant des technologies matures dans un ensemble original
  • au passage de l'expérience scientifique (“la paillasse”) à la technologie de production (“le génie des procédés”
  • à l'exploration de “domaine de vol” des applications scientifiques (paramètres de parallélisation, audit de code)
  • à la réalisation de prototypes pour la mise en place de nouveaux services informatiques

Le Centre Blaise Pascal n'a pas vocation à voir ses infrastructures utilisées :

  • pour de longs calculs de production (de l'ordre de la semaine)
  • pour des calculs sur de très grands nombres de coeurs (de l'ordre du millier)

Pour ces deux exigences, le PSMN dispose d'une infrastructure de production.

Les équipements mis à disposition 72 noeuds dans 2 groupes différents pour un total de 384 coeurs et 1248 Go de RAM.

Les noeuds v40z et v20z ont été arrêtés puis déposés suite à l'arrivée de Equip@Meso : ils sont remplacés par quelques x41z supplémentaires durant l'été 2013.

Cluster Marque Modèle Noeuds Coeurs /Noeud RAM /NoeudRéseau GERéseau IBTotal CoeursTotal RAM
r410 Dell R410 48 4 24 Go GE IB 384 1.1 To
x41z Sunfire x41z 24 8 24 Go GE IB 192 576 Go

Ces clusters partagent exactement la même image de système, Sidus (pour Single Instance Distributing Universal System), un système complet Debian intégrant tous les paquets scientifiques ainsi que de nombreux paquets de développement.

Accès aux clusters

L'accès aux clusters se fait via la passerelle styx.cbp.ens-lyon.fr, par le protocole SSH :

ssh -X <login>@styx.cbp.ens-lyon.fr

Cette passerelle n'est accessible que de l'intérieur de l'ENS : il est nécessaire de passer par la passerelle de l'ENS ssh.ens-lyon.fr ou par le Virtual Private Network par OpenVPN pour y accéder.

Dossiers personnels

Sur la passerelle styx, chaque utilisateur dispose de 2 comptes :

  • un rapide dans /home/<login>
  • un plus lent dans /cbp/<login>

Le second est le compte dont tout utilisateur de ressources informatiques du CBP dispose pour se connecter :

  • aux stations de travail de la salle libre service
  • aux machines à la demande SIDUS (Single Image Distributing Universal System)
  • aux serveurs d'intégration, de compilation, de tests
    • sous différentes architectures matérielles : x86_64, AMD64, PowerPC, Sparc
    • sous différents systèmes 32 bits ou 64 bits
    • sous différentes distributions Debian : Lenny, Squeeze, Wheezy et Sid

Accès aux ressources

L'utilisation de OAR permet de :

  • connaître les ressources disponibles : commande oarnodes et ses options
  • connaître l'état des calculs en cours : commande oarstat et ses options
  • lancer un calcul autonome (sous forme de batch) : commande oarsub et ses options
  • lancer une session interactive pour travailler : commande oarsub -I et ses options

Une documentation exhaustive se trouve là au format HTML et PDF

Connaître les ressources disponibles

La commande oarnodes permet de connaître l'état des noeuds gérés par le gestionnaire de tâches. Chaque resource représente un coeur. Il existe donc plus entrées par noeud.

oarnodes pour toute l'infrastructure

La commande oarnodes fournit en sortie :

network_address : x41z1
resource_id : 1
state : Alive
properties : core=1, deploy=NO, besteffort=YES, cpuset=0, desktop_computing=NO, available_upto=2147483647, cluster=x41z, cpu=1, host=x41z1, network_address=x41z1, last_available_upto=0, mem=16085, type=default

network_address : x41z2
resource_id : 10
state : Alive
properties : core=10, deploy=NO, besteffort=YES, cpuset=2, desktop_computing=NO, available_upto=2147483647, cluster=x41z, cpu=3, host=x41z2, network_address=x41z2, last_available_upto=0, mem=16085, type=default

--- <snip><snip>

network_address : x41z13
resource_id : 98
state : Alive
properties : core=98, deploy=NO, besteffort=YES, cpuset=2, desktop_computing=NO, available_upto=2147483647, cluster=x41z, cpu=25, host=x41z13, network_address=x41z13, last_available_upto=0, mem=16085, type=default

network_address : x41z13
resource_id : 99
state : Alive
properties : core=99, deploy=NO, besteffort=YES, cpuset=3, desktop_computing=NO, available_upto=2147483647, cluster=x41z, cpu=25, host=x41z13, network_address=x41z13, last_available_upto=0, mem=16085, type=default

oarnodes pour un noeud unique

Par exemple, la commande oarnodes –sql “host='v20z40'” pour examiner les ressources offertes par le noeud v20z40 sort :

network_address : v20z40
resource_id : 375
state : Alive
properties : core=375, deploy=NO, besteffort=YES, cpuset=0, desktop_computing=NO, available_upto=2147483647, cluster=v20z, cpu=183, host=v20z40, network_address=v20z40, last_available_upto=0, mem=7944, type=default

network_address : v20z40
resource_id : 376
state : Alive
properties : core=376, deploy=NO, besteffort=YES, cpuset=1, desktop_computing=NO, available_upto=2147483647, cluster=v20z, cpu=184, host=v20z40, network_address=v20z40, last_available_upto=0, mem=7944, type=default

oarnodes pour un cluster unique

La commande oarnodes –sql “cluster='v20z'” va chercher toutes les ressources (coeurs) disposant de l'entrée cluster=v20z.

Pour toute la documentation

Connaître l'état des calculs en cours oarstat

Pour connaître l'état général

oarstat

Pour avoir l'information sur une tâche particulière

Pour connaître toutes les informations (option -f) sur la tâche 9, par exemple, oarstat -j 9 -f

Job_Id: 9
    job_array_id = 9
    job_array_index = 1
    name = 
    project = default
    owner = equemene
    state = Terminated
    wanted_resources = -l "{type = 'default'}/network_address=4/core=1,walltime=2:0:0" 
    types = 
    dependencies = 
    assigned_resources = 41+49+57+65
    assigned_hostnames = x41z6+x41z7+x41z8+x41z9
    queue = default
    command = ./IMB-MPI1.sh
    exit_code = 0 (0,0,0)
    launchingDirectory = /home/equemene
    stdout_file = IMB.9.output
    stderr_file = IMB.9.error
    jobType = PASSIVE
    properties = (cluster='x41z') AND desktop_computing = 'NO'
    reservation = None
    walltime = 2:0:0
    submissionTime = 2013-02-05 15:51:45
    startTime = 2013-02-05 15:51:46
    stopTime = 2013-02-05 15:58:12
    cpuset_name = equemene_9
    initial_request = oarsub -p cluster='x41z' -S ./IMB-MPI1.sh; #OAR -l nodes=4/core=1,walltime=2:00:00; #OAR -O IMB.%jobid%.output; #OAR -E IMB.%jobid%.error
    message = Karma = 3.000
    scheduledStart = no prediction
    resubmit_job_id = 0
    events = [2013-02-05 15:58:12] SWITCH_INTO_TERMINATE_STATE:[bipbip 9] Ask to change the job state , 

On voit ainsi que la tâche a commencé le 5 février 2013 à 15h51 pour se terminer à 15h58 et qu'elle s'est exécutée sur 4 noeuds x41z.

Pour toute la documentation

Lancer une session interactive

La commande oarsub -I ouvre par défaut un session sur une machine choisie au hasard.

Exemple, pour ouvrir une session intéractive sur 2 noeuds sur une durée de 20 heures :

oarsub -I -l nodes=2,walltime=20:00:00

La session de connexion s'établit sur le premier noeud.

La variable d'environnement $OAR_NODE_FILE dans notre exemple contient

x41z8
x41z8
x41z8
x41z8
x41z8
x41z8
x41z8
x41z8
x41z9
x41z9
x41z9
x41z9
x41z9
x41z9
x41z9
x41z9

Nous voyons que sont mentionnés tous les coeurs disponibles sur les deux noeuds réservés pour l'occasion.

Pour lancer le calcul MPI MyJob sur la totalité des noeuds :

mpirun -np $(cat $OAR_NODE_FILE | wc -l) -hostfile $OAR_NODE_FILE MyJob

Lancer un calcul autonome (mode batch)

Il est possible de lancer un batch en précisant les paramètres (nombre de noeuds, nombre de coeurs, nombre de CPU) mais il est nécessaire de toutes façons de créer un script shell.

Autant créer un script de lancement OAR lequel sera utilisé pour déclarer tout d'un bloc.

Nous voulons exécuter le programme MPI MyJob sur 4 noeuds avec tous les coeurs disponibles. Nous fixons la durée maximale à 20 heures. Nous voulons que le nom de fichiers de de sortie soit préfixés de MyJob.

Nous créons le script suivant sous le nom (très original) de MyJob.oar :

#!/bin/bash
#OAR -l nodes=4/core=1,walltime=20:00:00
#OAR -O MyJob.%jobid%.output
#OAR -E MyJob.%jobid%.error

# Calcul le nombre de coeurs reserves
NP=$(cat $OAR_NODE_FILE | wc -l)

mpirun.openmpi -np $NP -hostfile $OAR_NODE_FILE ./MyJob

Le programme se lance en utilisant la commande de soumission oarsub -S ./MyJob.oar.

La commande d'examen des tâches en cours oarstat permet ensuite de savoir que le job a bien été pris en compte.

Choisir un cluster

Le choix d'un cluster se réalise en précisant dans la soumission oarsub et le paramètre : -p “cluster='<NomDuCluster>' ” .

Les noms de cluster étant v22z et x41z, pour lancer le calcul MyJob défini dans le script OAR MyJob.sh sur le cluster de x41z, lancez la commande :

oarsub -p "cluster='x41z'" -S ./MyJob.oar
ressources/oar4cbp.txt · Dernière modification: 2017/03/09 11:25 par equemene