Niagara ː Guide de démarrage

From Alliance Doc
Revision as of 16:47, 6 July 2018 by Diane27 (talk | contribs)
Jump to navigation Jump to search
Other languages:

Renseignements sur la grappe

La grappe Niagara compte 1500 serveurs Lenovo SD350, chacun avec 40 cœurs Skylake de 2.4GHz. Sa performance de pointe est de 3.02 pétaflops (4.6 en théorie). En juin 2018, la grappe se classait au 53e rang des 500 superordinateurs les plus performants.

Chaque nœud de la grappe est de 188Gio/202Go dont un minimum de 4Gio par cœur vont aux tâches des utilisateurs. La grappe est conçue pour des tâches parallèles intensives avec un réseau InfiniBand EDR (Enhanced Data Rate) à topologie Dragonfly+

cœurs

Visionnez la vidéo de présentation de SciNet.

Pour plus d'information sur les spécifications matérielles, consultez la page Niagara.

Se connecter

L'accès à Niagara se fait uniquement par SSH (Secure Shell).

Pour accéder à Niagara, ouvrez d'abord une fenêtre de terminal (par exemple avec PuTTY sous Windows ou MobaXTerm), puis connectez-vous avec SSH aux nœuds de connexion avec les coordonnées de votre compte Calcul Canada. 

$ ssh -Y MYCCUSERNAME@niagara.scinet.utoronto.ca

ou 

$ ssh -Y MYCCUSERNAME@niagara.computecanada.ca

Les tâches sont créées, éditées, compilées, préparées et soumises dans les nœuds de connexion.

Ces nœuds de connexion ne font pas partie de la grappe Niagara, mais ils ont la même architecture et la même pile logicielle que les nœuds de calcul.

Dans les commandes ci-dessus, -Y est optionnel, mais nécessaire pour ouvrir des fenêtres de lignes de commande sur votre serveur local.

Pour utiliser les nœuds de calcul, il faut soumettre les tâches en lot (batch) à l'ordonnanceur.

If you cannot log in, be sure first to check the System Status on this site's front page.

Localisation de vos répertoires

Répertoires home et scratch

Pour localiser vos espaces home et scratch, utilisez

$HOME=/home/g/groupname/myccusername

$SCRATCH=/scratch/g/groupname/myccusername

Par exemple, 

nia-login07:~$ pwd
/home/s/scinet/rzon

nia-login07:~$ cd $SCRATCH

nia-login07:rzon$ pwd
/scratch/s/scinet/rzon

Répertoire project

Les utilisateurs disposant de ressources allouées par le concours 2018 peuvent localiser leur répertoire projet avec

$PROJECT=/project/g/groupname/myccusername

$ARCHIVE=/archive/g/groupname/myccusername

NOTE: Currently archive space is available only via HPSS

IMPORTANT : Mesure préventive

Puisque les chemins risquent de changer, utilisez plutôt les variables d'environnement (HOME, SCRATCH, PROJECT).

Data Management

Purpose of each file system

/home

/home is intended primarily for individual user files, common software or small datasets used by others in the same group, provided it does not exceed individual quotas. Otherwise you may consider /scratch or /project. /home is read-only on the compute nodes.

/scratch

/scratch is to be used primarily for temporary or transient files, for all the results of your computations and simulations, or any material that can be easily recreated or reacquired. You may use scratch as well for any intermediate step in your workflow, provided it does not induce too much IO or too many small files on this disk-based storage pool, otherwise you should consider burst buffer (/bb). Once you have your final results, those that you want to keep for the long term, you may migrate them to /project or /archive. /scratch is purged on a regular basis and has no backups.

/project

/project is intended for common group software, large static datasets, or any material very costly to be reacquired or re-generated by the group. Material on /project is expected to be relatively immutable over time. Temporary or transient files should be kept on scratch, not project. High data turnover induces the consumption of a lot of tapes on the TSM backup system, long after this material has been deleted, due to backup retention policies and the extra versions kept of the same file. Users abusing the project file system and using it as scratch will be flagged and contacted. Note that on niagara /project is only available to groups with RAC allocation.

/bb (burst buffer)

/bb is basically a very fast, very high performance alternative to /scratch, made of solid-state drives (SSD). You may request this resource instead, if you anticipate a lot of IO/IOPs (too much for scratch) or when you notice your job is not performing well running on scratch or project because of IO bottlenecks. Keep in mind, we can only offer 232TB for all niagara users at any given time. Once you get your results you may bundle/tarball them and move to scratch, project or archive. /bb is purged very frequently.

/archive

/archive is a nearline storage pool, if you want to temporarily offload semi-active material from any of the above file systems. In practice users will offload/recall material as part of their regular workflow, or when they hit their quotas on scratch or project. That material can remain on HPSS for a few months to a few years. Note that on niagara /archive is only available to groups with RAC allocation.

Performance

GPFS is a high-performance filesystem which provides rapid reads and writes to large datasets in parallel from many nodes. As a consequence of this design, however, the file system performs quite poorly at accessing data sets which consist of many, small files. For instance, you will find that reading data in from one 16MB file is enormously faster than from 400 40KB files. Such small files are also quite wasteful of space, as the blocksize for the scratch and project filesystems is 16MB. This is something you should keep in mind when planning your input/output strategy for runs on SciNet.

For instance, if you run multi-process jobs, having each process write to a file of its own is not an scalable I/O solution. A directory gets locked by the first process accessing it, so all other processes have to wait for it. Not only has the code just become considerably less parallel, chances are the file system will have a time-out while waiting for your other processes, leading your program to crash mysteriously. Consider using MPI-IO (part of the MPI-2 standard), which allows files to be opened simultaneously by different processes, or using a dedicated process for I/O to which all other processes send their data, and which subsequently writes this data to a single file.

Déplacer des données

  • Only Niagara login nodes visible from outside SciNet.
  • Use scp or rsync to niagara.scinet.utoronto.ca or niagara.computecanada.ca (no difference).
  • This will time out for amounts larger than about 10GB.

Move amounts larger than 10GB through the datamover nodes.

  • From a Niagara login node, ssh to nia-datamover1 or nia-datamover2.
  • Transfers must originate from this datamover.
  • The other side (e.g. your machine) must be reachable from the outside.
  • If you do this often, consider using Globus, a web-based tool for data transfer.

Moving data to HPSS/Archive/Nearline using the scheduler.

Vous pourriez vouloir déplacer des données vers HPSS/Archive/Nearline. L'espace de stockage sur HPSS est alloué dans le cadre du concours d'allocation de ressources.

using globus

If you regularly move more than 10GB, consider using globus, a web-based data transfer tool.

Please check the comprehensive documentation here.

The Niagara "endpoint" for globus is "computecanada#niagara"

Stockage

quota taille des blocs durée sauvegarde sur nœuds de connexion sur nœuds de calcul
$HOME 100 Go 1 Mo oui oui lecture seule
$SCRATCH 25 To 16 Mo 2 mois non oui oui
$PROJECT par groupe 16 Mo oui oui oui
$ARCHIVE par groupe 2 copies non non
$BBUFFER ? 1 Mo très courte non ? ?
  • Les nœuds de calcul n'offrent pas d'espace de stockage.
  • L'espace d'archivage est sur HPSS qui est relié à Niagara.
  • La sauvegarde est un instantané (snapshot) récent et non une copie archivée de toutes les données ayant existé.

  • $BBUFFER (Burst Buffer) désigne la mémoire tampon d'accès en rafale.

File/Ownership Management (ACL)

  • By default, at SciNet, users within the same group already have read permission to each other's files (not write)
  • You may use access control list (ACL) to allow your supervisor (or another user within your group) to manage files for you (i.e., create, move, rename, delete), while still retaining your access and permission as the original owner of the files/directories. You may also let users in other groups or whole other groups access (read, execute) your files using this same mechanism.

Using mmputacl/mmgetacl

  • You may use gpfs' native mmputacl and mmgetacl commands. The advantages are that you can set "control" permission and that POSIX or NFS v4 style ACL are supported. You will need first to create a /tmp/supervisor.acl file with the following contents:
user::rwxc
group::----
other::----
mask::rwxc
user:[owner]:rwxc
user:[supervisor]:rwxc
group:[othegroup]:r-xc

Then issue the following 2 commands: 

1) $ mmputacl -i /tmp/supervisor.acl /project/g/group/[owner]
2) $ mmputacl -d -i /tmp/supervisor.acl /project/g/group/[owner]
   (every *new* file/directory inside [owner] will inherit [supervisor] ownership by default as well as 
   [owner] ownership, ie, ownership of both by default, for files/directories created by [supervisor])

   $ mmgetacl /project/g/group/[owner]
   (to determine the current ACL attributes)

   $ mmdelacl -d /project/g/group/[owner]
   (to remove any previously set ACL)

   $ mmeditacl /project/g/group/[owner]
   (to create or change a GPFS access control list)
   (for this command to work set the EDITOR environment variable: export EDITOR=/usr/bin/vi)

NOTES:

  • mmputacl will not overwrite the original linux group permissions for a directory when copied to another directory already with ACLs, hence the "#effective:r-x" note you may see from time to time with mmgetacf. If you want to give rwx permissions to everyone in your group you should simply rely on the plain unix 'chmod g+rwx' command. You may do that before or after copying the original material to another folder with the ACLs.
  • In the case of PROJECT, your group's supervisor will need to set proper ACL to the /project/G/GROUP level in order to let users from other groups access your files.
  • ACL's won't let you give away permissions to files or directories that do not belong to you.
  • We highly recommend that you never give write permission to other users on the top level of your home directory (/home/G/GROUP/[owner]), since that would seriously compromise your privacy, in addition to disable ssh key authentication, among other things. If necessary, make specific sub-directories under your home directory so that other users can manipulate/access files from those.

For more information on using mmputacl or mmgetaclacl see their man pages.

Recursive ACL script

You may use/adapt this sample bash script to recursively add or remove ACL attributes using gpfs built-in commands

Courtesy of Agata Disks (http://csngwinfo.in2p3.fr/mediawiki/index.php/GPFS_ACL)

Scratch Disk Purging Policy

In order to ensure that there is always significant space available for running jobs we automatically delete files in /scratch that have not been accessed or modified for more than 2 months by the actual deletion day on the 15th of each month. Note that we recently changed the cut out reference to the MostRecentOf(atime,ctime). This policy is subject to revision depending on its effectiveness. More details about the purging process and how users can check if their files will be deleted follows. If you have files scheduled for deletion you should move them to more permanent locations such as your departmental server or your /project space or into HPSS (for PIs who have either been allocated storage space by the RAC on project or HPSS).

On the first of each month, a list of files scheduled for purging is produced, and an email notification is sent to each user on that list. You also get a notification on the shell every time your login to Niagara. Furthermore, at/or about the 12th of each month a 2nd scan produces a more current assessment and another email notification is sent. This way users can double check that they have indeed taken care of all the files they needed to relocate before the purging deadline. Those files will be automatically deleted on the 15th of the same month unless they have been accessed or relocated in the interim. If you have files scheduled for deletion then they will be listed in a file in /scratch/t/todelete/current, which has your userid and groupid in the filename. For example, if user xxyz wants to check if they have files scheduled for deletion they can issue the following command on a system which mounts /scratch (e.g. a scinet login node): ls -1 /scratch/t/todelete/current |grep xxyz. In the example below, the name of this file indicates that user xxyz is part of group abc, has 9,560 files scheduled for deletion and they take up 1.0TB of space: 

 [xxyz@nia-login03 ~]$ ls -1 /scratch/t/todelete/current |grep xxyz
 -rw-r----- 1 xxyz     root       1733059 Jan 17 11:46 3110001___xxyz_______abc_________1.00T_____9560files

The file itself contains a list of all files scheduled for deletion (in the last column) and can be viewed with standard commands like more/less/cat - e.g. more /scratch/t/todelete/current/3110001___xxyz_______abc_________1.00T_____9560files

Similarly, you can also verify all other users on your group by using the ls command with grep on your group. For example: ls -1 /scratch/t/todelete/current |grep abc. That will list all other users in the same group that xxyz is part of, and have files to be purged on the 15th. Members of the same group have access to each other's contents.

NOTE: Preparing these assessments takes several hours. If you change the access/modification time of a file in the interim, that will not be detected until the next cycle. A way for you to get immediate feedback is to use the 'ls -lu' command on the file to verify the ctime and 'ls -lc' for the mtime. If the file atime/ctime has been updated in the meantime, coming the purging date on the 15th it will no longer be deleted.

How much Disk Space Do I have left?

The /scinet/niagara/bin/diskUsage command, available on the login nodes and datamovers, provides information in a number of ways on the home, scratch, project and archive file systems. For instance, how much disk space is being used by yourself and your group (with the -a option), or how much your usage has changed over a certain period ("delta information") or you may generate plots of your usage over time. Please see the usage help below for more details. 

Usage: diskUsage [-h|-?| [-a] [-u <user>]
       -h|-?: help
       -a: list usages of all members on the group
       -u <user>: as another user on your group

Did you know that you can check which of your directories have more than 1000 files with the /scinet/niagara/bin/topUserDirOver1000list command and which have more than 1GB of material with the /scinet/niagara/bin/topUserDirOver1GBlist command?

Note:

  • information on usage and quota is only updated every 3 hours!

Gestion des données et trucs pour les Entrées/Sorties

  • $HOME, $SCRATCH et $PROJECT utilisent tous le système de fichiers parallèle GPFS.
  • Vos fichiers sont visibles sur tous les nœuds de connexion et de calcul de Niagara.
  • GPFS est un système de fichiers haute performance avec des entrées/sorties rapides sur plusieurs nœuds pour de grands ensembles de données.
  • Cependant, l'accès à des ensembles de données constitués de plusieurs petits fichiers engendre une faible performance.
  • Évitez de lire et écrire plusieurs petites quantités de données sur les disques.
  • Un système constitué de plusieurs petits fichiers utilise mal l'espace disponible et ralentit l'accès, la lecture et l'écriture.
  • Écrivez vos données en binaire pour plus de vitesse et une économie de l'espace.
  • La fonctionnalité burst buffer est en préparation; elle facilitera les entrées/sorties pour les tâches intensives et accélérera la création et l'enregistrement des points de contrôle.

Charger des modules

Mis à part les logiciels essentiels, les applications sont installées via des modules. Les modules configurent les variables d'environnement (PATH, etc.). Ceci rend disponible plusieurs versions incompatibles d'un même paquet. Pour connaître les logiciels disponibles, utilisez module spider.

Par exemple, 

nia-login07:~$ module spider
---------------------------------------------------
The following is a list of the modules currently av
---------------------------------------------------
  CCEnv: CCEnv

  NiaEnv: NiaEnv/2018a

  anaconda2: anaconda2/5.1.0

  anaconda3: anaconda3/5.1.0

  autotools: autotools/2017
    autoconf, automake, and libtool 

  boost: boost/1.66.0

  cfitsio: cfitsio/3.430

  cmake: cmake/3.10.2 cmake/3.10.3

  ...
    Les commandes les plus utilisées sont ː
  • module load <module-name> : pour un logiciel particulier
  • module purge : pour supprimer les modules déjà chargés
  • module spider (ou module spider <module-name>) : pour obtenir la liste des paquets logiciels disponibles
  • module avail : pour obtenir la liste des paquets logiciels disponibles pour le chargement
  • module list : pour obtenir la liste des modules chargés

Il y a deux piles logicielles sur Niagara.

  1. La pile logicielle Niagara est spécifiquement adaptée à cette grappe. Elle est disponible par défaut, mais au besoin peut être chargée à nouveau avec 

    module load NiaEnv
    .

  2. La pile logicielle usuelle des grappes d'usage général (Graham et Cedar), compilée pour l'instant pour une génération précédente de CPU. 

    module load CCEnv

    Pour charger les modules par défaut comme ceux de Cedar ou Graham, exécutez aussi module load StdEnv.

Note : Les modules *Env sont sticky; supprimez-les avec --force.

Trucs pour le chargement de modules

Il n'est pas conseillé de changer des modules dans votre .bashrc de Niagara. Dans certains cas, le comportement peut être très étrange. Au besoin, chargez plutôt les modules manuellement ou par un script distinct et chargez des modules requis pour l'exécution via le script de soumission de votre tâche.

The default .bashrc and .bash_profile files on Niagara can be found here

Instead, load modules by hand when needed, or by sourcing a separate script.

Load run-specific modules inside your job submission script.

Les noms courts sont pour les versions par défaut; par exemple, intel → intel/2018.2. Il est habituellement préférable de préciser la version pour pouvoir reproduire un cas.

Certaines abréviations sont utiles ː 

        ml → module list
        ml NAME → module load NAME  # if NAME is an existing module
        ml X → module X

Certains modules requièrent le chargement préalable d'autres modules.

Pour résoudre les dépendances, utilisez module spider.

La commande module spider

La sous-commande spider vous renseigne sur les modules qui sont chargés.

Prenons un exemple ː En voulant charger le module openmpi, vous recevez le message 

nia-login07:~$ module load openmpi
Lmod has detected the error:  These module(s) exist but cannot be loaded as requested: "openmpi"
   Try: "module spider openmpi" to see how to load the module(s).

Ceci n'a pas fonctionné, mais le message fournit un indice, alors la commande serait 

nia-login07:~$ module spider openmpi
------------------------------------------------------------------------------------------------------
  openmpi:
------------------------------------------------------------------------------------------------------
     Versions:
        openmpi/2.1.3
        openmpi/3.0.1
        openmpi/3.1.0rc3

------------------------------------------------------------------------------------------------------
  For detailed information about a specific "openmpi" module (including how to load the modules) use
  the module s full name.
  For example:

     $ module spider openmpi/3.1.0rc3
------------------------------------------------------------------------------------------------------

Nous avons maintenant des détails sur comment utiliser la commande; profitons de ce conseil et modifions le script ː 

nia-login07:~$ module spider openmpi/3.1.0rc3
------------------------------------------------------------------------------------------------------
  openmpi: openmpi/3.1.0rc3
------------------------------------------------------------------------------------------------------
    You will need to load all module(s) on any one of the lines below before the "openmpi/3.1.0rc3"
    module is available to load.

      NiaEnv/2018a  gcc/7.3.0
      NiaEnv/2018a  intel/2018.2

Les directives expliquent comment charger ce module openmpi particulier. 

nia-login07:~$ module load NiaEnv/2018a  intel/2018.2
nia-login07:~$ module load openmpi/3.1.0rc3

nia-login07:~$ module list
Currently Loaded Modules:
  1) NiaEnv/2018a (S)   2) intel/2018.2   3) openmpi/3.1.0.rc3

  Where:
   S:  Module is Sticky, requires --force to unload or purge

Applications du commerce

  • Vous devrez peut-être fournir votre propre licence.
  • SciNet et Compute Canada desservent des milliers d'utilisateurs de disciplines variées; il n'est pas possible d'accommoder toutes les applications préférées de chacun.
  • Ainsi, les seules applications du commerce installées sur Niagara sont d'ordre général, soit des compilateurs, des bibliothèques mathématiques et des outils de débogage.
  • Ceci exclut Matlab, Gaussian, IDL.
  • Des options open source sont disponibles, comme Octave, Python et R.
  • Nous vous aiderons à installer toute application du commerce pour laquelle vous détenez une licence.
  • Dans certains cas, si vous avez une licence, vous pouvez utiliser des applications de la pile logicielle de Calcul Canada.

Exemple de compilation

Nous voulons compiler une application à partir des deux fichiers source main.c et module.c qui utilisent GSL (Gnu Scientific Library). Nous pourrions procéder ainsi ː 

nia-login07:~$ module list
Currently Loaded Modules:
  1) NiaEnv/2018a (S)
  Where:
   S:  Module is Sticky, requires --force to unload or purge

nia-login07:~$ module load intel/2018.2 gsl/2.4

nia-login07:~$ ls
appl.c module.c

nia-login07:~$ icc -c -O3 -xHost -o appl.o appl.c
nia-login07:~$ icc -c -O3 -xHost -o module.o module.c
nia-login07:~$ icc  -o appl module.o appl.o -lgsl -mkl

nia-login07:~$ ./appl

Note :

  • Les indicateurs d'optimisation -O3 -xHost permettent au compilateur Intel d'utiliser les instructions spécifiques à l'architecture CPU existante (plutôt que pour des CPU x86_64 plus génériques).
  • GSL exige une implémentation cblas qui fait partie de MKL(Intel Math Kernel Library). Il st facile de faire un lien avec cette bibliothèque quand on utilise le compilateur Intel; on n'a besoin que des indicateurs -mkl.
  • Pour compiler avec gcc, les indicateurs d'optimisation seraient -O3 -march=native. Pour faire un lien avec MKL, nous suggérons MKL link line advisor.

Tests

Vous devriez toujours tester votre code avant de soumettre une tâche pour savoir s'il est valide et pour connaître les ressources dont vous avez besoin.

  • Les tâches de test courtes peuvent être exécutées sur les nœuds de connexion.

    En principe : quelques minutes, utilisant au plus 1-2Go de mémoire, quelques cœurs.

  • Après module load ddt, vous pouvez lancer le débogueur ddt sur les nœuds de connexion.

  • Les tests courts qui ne peuvent être exécutés sur un nœud de connexion ou qui nécessitent un nœud dédié requièrent un débogage interactif avec la commande salloc.
    interactive debug job with the salloc command

    nia-login07:~$ salloc -pdebug --nodes N --time=1:00:00

    où N est le nombre de nœuds. La session de débogage interactif ne doit pas dépasser une heure, ne doit pas utiliser plus de 4 cœurs et chaque utilisateur ne doit avoir qu'une session de débogage à la fois.

    Une autre option est d'utiliser la commande 

    nia-login07:~$ debugjob N

    où N est le nombre de nœuds. Si N=1, la session interactive est d'une heure et si N=4 (valeur maximale) la session est de 30 minutes.

Testing with Graphics: X-forwarding

If you need to use graphics while testing your code, e.g. when using a debugger such as DDT or DDD, you have the following options:

  • You can use the debugjob command which automatically provides X-forwarding support. 
    $ ssh  niagara.scinet.utoronto.ca -X

USER@nia-login07:~$ debugjob
debugjob: Requesting 1 nodes for 60 minutes
xalloc: Granted job allocation 189857
xalloc: Waiting for resource configuration
xalloc: Nodes nia0030 are ready for job

[USER@nia1265 ~]$
  • If debugjob is not suitable for your case due to the limitations either on time or resources (see above #Testing), then you have to follow these steps: You will need two terminals in order to achieve this:
    1. In the 1st terminal
      • ssh to niagara.scinet.utoronto.ca and issue your salloc command
      • wait until your resources are allocated and you are assigned the nodes
      • take note of the node where you are logged to, ie. the head node, let's say niaWXYZ 
      $ ssh  niagara.scinet.utoronto.ca
USER@nia-login07:~$ salloc --nodes 5 --time=2:00:00

.salloc: Granted job allocation 141862
.salloc: Waiting for resource configuration
.salloc: Nodes nia1265 are ready for job

[USER@nia1265 ~]$
    2. On the second terminal:
      • ssh into niagara.scinet.utoronto.ca now using the -X flag in the ssh command
      • after that ssh -X niaWXYZ, ie. you will ssh carrying on the '-X' flag into the head node of the job
      • in the niaWXYZ you should be able to use graphics and should be redirected by x-forwarding to your local terminal 
      ssh niagara.scinet.utoronto.ca -X
USER@nia-login07:~$ ssh -X nia1265
[USER@nia1265 ~]$ xclock   ## just an example to test the graphics, a clock should pop up, close it to exit
[USER@nia1265 ~]$ module load ddt  ## load corresponding modules, eg. for DDT
[USER@nia1265 ~]$ ddt  ## launch DDT, the GUI should appear in your screen


Observations:

  • If you are using ssh from a Windows machine, you need to have an X-server, a good option is to use MobaXterm, that already brings an X-server included.
  • If you are in Mac OS, substitute -X by -Y
  • Instead of using two terminals, you could just use screen to request the resources and then detach the session and ssh into the head node directly.

Soumettre des tâches

  • Niagara utilise l'ordonnanceur Slurm.

  • À partir d'un nœud de connexion, les tâches sont soumises en passant un script à la commande sbatch :

    nia-login07:~$ sbatch jobscript.sh

  • Ceci place la tâche dans la queue; elle sera exécutée sur les nœuds de calcul à son tour.

  • Les tâches seront comptabilisées contre l'allocation de Ressources pour les groupes de recherche; si le groupe n'a reçu aucune de ces ressources, la tâche sera comptabilisée contre le Service d'accès rapide (autrefois allocation par défaut).

Souvenez-vous ː

  • L'ordonnancement se fait par nœud, donc en multiples de 40 cœurs.

  • La limite en temps réel ne doit pas dépasser 24 heures; pour les utilisateurs sans allocation, la limite est de 12 heures.

  • L'écriture doit se faire dans votre répertoire scratch ou project (sur les nœuds de calcul, home est seulement en lecture).

  • Les nœuds de calcul ne peuvent accéder à l'internet.

    Avant de commencer, téléchargez les données sur un nœud de connexion.

SLURM nomenclature: jobs, nodes, tasks, cpus, cores, threads

SLURM, which is the job scheduler used on Niagara, has a somewhat different way of referring to things like mpi processes and threads tasks. The SLURM nomenclature is reflected in the names of scheduler option (i.e., resource requests). SLURM strictly enforces those requests, so it is important to get this right.

term meaning SLURM term related scheduler options
job scheduled piece of work for which specific resources were requested. job sbatch, salloc
node basic computing component with several cores (40 for Niagara) that share memory node --nodes -N
mpi process one of a group of running programs using Message Passing Interface for parallel computing task --ntasks -n --ntasks-per-node
core or physical cpu A fully functional independent physical execution unit. - -
logical cpu An execution unit that the operating system can assign work to. Operating systems can be configured to overload physical cores with multiple logical cpus using hyperthreading. cpu --ncpus-per-task
thread one of possibly multiple simultaneous execution paths within a program, which can share memory. - --ncpus-per-task and OMP_NUM_THREADS
hyperthread a thread run in a collection of threads that is larger than the number of physical cores. - -

Ordonnancement par nœud

  • Toutes les requêtes de ressources pour les tâches sont ordonnancées en multiples de nœuds.

  • Les nœuds utilisés par vos tâches sont à votre usage exclusif.
    • Aucun autre utilisateur n'y a accès.
    • Vous pouvez accéder aux tâches avec SSH pour en faire le suivi.

  • Peu importe votre requête, l'ordonnanceur la traduit en multiples de nœuds alloués à la tâche.

  • Il est inutile de faire une requête pour une quantité de mémoire.

    Votre tâche obtient toujours Nx202Go de mémoire vive, où N représente le nombre de nœuds.

  • Vous devriez essayer d'utiliser tous les cœurs des nœuds alloués à votre tâche. Puisqu'il y a 40 cœurs par nœud, votre tâche devrait utiliser Nx40 cœurs. Si ce n'est pas le cas, nous vous contacterons pour vous aider à optimiser votre travail.

CPU logiques vs cœur ː Hyperthreading

Niagara fait usage de la technologie de l'hyperthreading qui augmente la capacité du matériel en prétendant qu'il y a deux fois plus de cœurs logiques qu'il n'y en a en réalité.

Le système d'exploitation et l'ordonnanceur voient alors 80 cœurs.

Utiliser 80 cœurs logiques contre 40 cœurs réels augmente la vitesse de 5 à 10% (variable selon les cas).

Puisque l'ordonnancement se fait par nœud, cette technologie est plutôt facile à utiliser.

  • Demandez N nœuds pour vos tâches.
  • Vous savez que vous obtenez 40xN cœurs, alors vous utiliserez (au moins) un total de 40xN processus mpi ou fils. (mpirun, srun, et le système d'exploitation les répartissent automatiquement sur les cœurs réels).
  • Vous devriez aussi voir si vous obtenez plus de vitesse si vous exécutez 80xN processus mpi ou fils.
  • Peu importe, votre utilisation sera comptabilisée comme étant 40xN x (temps réel en années).

Limits

There are limits to the size and duration of your jobs, the number of jobs you can run and the number of jobs you can have queued. It matters whether a user is part of a group with a Resources for Research Group allocation or not. It also matters in which 'partition' the jobs runs. 'Partitions' are SLURM-speak for use cases. You specify the partition with the -p parameter to sbatch or salloc, but if you do not specify one, your job will run in the compute partition, which is the most common case.

Usage Partition Running jobs Submitted jobs (incl. running) Min. size of jobs Max. size of jobs Min. walltime Max. walltime
Compute jobs with an allocation compute 50 1000 1 node (40 cores) 1000 nodes (40000 cores) 15 minutes 24 hours
Compute jobs without allocation ("default") compute 50 200 1 node (40 cores) 20 nodes (800 cores) 15 minutes 12 hours
Testing or troubleshooting debug 1 1 1 node (40 cores) 4 nodes (160 cores) N/A 1 hour
Archiving or retrieving data in HPSS archivelong 2 per user (max 5 total) 10 per user N/A N/A 15 minutes 72 hours
Inspecting archived data, small archival actions in HPSS archiveshort 2 per user 10 per user N/A N/A 15 minutes 1 hour

Within these limits, jobs will still have to wait in the queue. The waiting time depends on many factors such as the allocation amount, how much allocation was used in the recent past, the number of nodes and the walltime, and how many other jobs are waiting in the queue.

SLURM Accounts

To be able to prioritise jobs based on groups and allocations, the SLURM scheduler uses the concept of accounts. Each group that has a Resource for Research Groups (RRG) or Research Platforms and Portals (RPP) allocation (awarded through an annual competition by Compute Canada) has an account that starts with rrg- or rpp-. SLURM assigns a 'fairshare' priority to these accounts based on the size of the award in core-years. Groups without an RRG or RPP can use Niagara using a so-called Rapid Access Service (RAS), and have an account that starts with def-.

On Niagara, most users will only ever use one account, and those users do not need to specify the account to SLURM. However, users that are part of collaborations may be able to use multiple accounts, i.e., that of their sponsor and that of their collaborator, but this mean that they need to select the right account when running jobs.

To select the account, just add 

   #SBATCH -A [account]

to the job scripts, or use the -A [account] to salloc or debugjob.

To see which accounts you have access to, or what their names are, use the command 

   sshare -U

Passing Variables to Job's submission scripts

It is possible to pass values through environment variables into your SLURM submission scripts. For doing so with already defined variables in your shell, just add the following directive in the submission script, 

#SBATCH --export=ALL

and you will have access to any predefined environment variable.

A better way is to specify explicitly which variables you want to pass into the submision script, 

sbatch --export=i=15,j='test' jobscript.sbatch

You can even set the job name and output files using environment variables, eg. 

i="simulation"
j=14
sbatch --job-name=$i.$j.run --output=$i.$j.out --export=i=$i,j=$j jobscript.sbatch

(The latter only works on the command line; you cannot use environment variables in #SBATCH lines in the job script.)

Arguments en ligne de commande

Command line arguments can also be used in the same way as command line argument for shell scripts. All command line arguments given to sbatch that follow after the job script name, will be passed to the job script. In fact, SLURM will not look at any of these arguments, so you must place all sbatch arguments before the script name, e.g.: 

sbatch  -p debug  jobscript.sbatch  FirstArgument SecondArgument ...

In this example, -p debug is interpreted by SLURM, while in your submission script you can access FirstArgument, SecondArgument, etc., by referring to $1, $2, ....

Email Notification

Email notification works, but you need to add the email address and type of notification you may want to receive in your submission script, eg. 

   #SBATCH --mail-user=YOUR.email.ADDRESS
   #SBATCH --mail-type=ALL

If you omit the mail-user option, the scheduler will use the primary email address associated with your Compute Canada account.

The sbatch man page (type man sbatch on Niagara) explains all possible mail-types.

Exemple d'un script de soumission pour MPI

Pour exécuter l'application MPI nommée appl_mpi_ex avec 320 processus, le script serait ː 

#!/bin/bash 
#SBATCH --nodes=8
#SBATCH --ntasks=320
#SBATCH --time=1:00:00
#SBATCH --job-name mpi_ex
#SBATCH --output=mpi_ex_%j.txt

cd $SLURM_SUBMIT_DIR

module load intel/2018.2
module load openmpi/3.1.0rc3

mpirun ./appl_mpi_ex

Soumettez le script (nommé ici mpi_ex.sh) avec la commande 

nia-login07:~$ sbatch mpi_ex.sh

  • La première ligne mentionne qu'il s'agit d'un script bash.

  • Les lignes qui commencent par #SBATCH sont pour l'ordonnanceur.

  • sbatch interprète ces lignes comme étant une requête et la nomme mpi_ex

  • Ici, l'ordonnanceur cherche 8 nœuds avec 40 cœurs pour exécuter 320 tâches, pour une durée d'une heure.

  • Une fois le nœud trouvé, le script est exécuté ː

    • redirige vers le répertoire de soumission;
    • charge les modules;
    • exécute l'application appl_mpi_ex avec mpirun (srun devrait aussi fonctionner).
  • Pour utiliser la fonctionnalité hyperthreading, remplacez --ntasks=320 par --ntasks=640 et ajoutez --bind-to none à la commande mpirun (seulement avec avec OpenMPI et non IntelMPI).

Exemple d'un script de soumission pour OpenMP

Dans cet exemple, nous allons exécuter sur un nœud unique l'application multifil appl_openmp_ex qui utilise OpenMP. Le script est le suivant : 

#!/bin/bash
#SBATCH --nodes=1
#SBATCH --cpus-per-task=40
#SBATCH --time=1:00:00
#SBATCH --job-name openmp_ex
#SBATCH --output=openmp_ex_%j.txt

cd $SLURM_SUBMIT_DIR

module load intel/2018.2

export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK

./openmp_example
# or "srun ./openmp_example".

Soumettez le script (nommé openmp_ex.sh) avec la commande 

nia-login07:~$ sbatch openmp_ex.sh
  • La première ligne mentionne qu'il s'agit d'un script bash.
  • Les lignes qui commencent par #SBATCH sont pour l'ordonnanceur.
  • sbatch interprète ces lignes comme étant une requête et la nomme openmp_ex.
  • L'ordonnanceur cherche alors un nœud de 40 cœurs à exécuter dans une tâche, pour une durée d'une heure.
  • Une fois le nœud trouvé, le script est exécuté:
    • redirige vers le répertoire de soumission;
    • charge les modules (doit être fait aussi dans le script de soumission sur Niagara);
    • configure une variable d'environnement pour spécifier 40 fils (il n'y a pas de hyperthreading dans cet exemple);
    • exécute l'application appl_openmp_ex.
  • Pour utiliser la fonctionnalité hyperthreading, remplacez --cpus-per-task=40 par --cpus-per-task=80.

Suivi des tâches en attente

Une fois la tâche placée dans la queue, suivez son déroulement avec les commandes suivantes ː

  • squeue ou qsum pour voir les tâches dans la queue (squeue -u $USER pour vos propres tâches);

  • squeue -j JOBID pour des renseignements sur une tâche en particulier

    (ou la version plus longue scontrol show job JOBID);

  • squeue --start -j JOBID pour une estimation de quand la tâche sera exécutée (le résultat n'est pas toujours fiable);

    • Puisque ceci n'est pas très précis, vous pourriez vouloir savoir où se trouve votre tâche dans la queue avec la fonction bash suivante ː Pour en savoir plus, consultez Exécuter des tâches.

    Visualisation

    Pour savoir comment utiliser les outils de visualisation de Niagara, consultez cette page du wiki SciNet.

    Pour plus d'information

    Sites

    Soutien technique

    • support@scinet.utoronto.ca
    • niagara@computecanada.ca

Resource Allocation Competition

Message Passing Interface

Intel Math Kernel Library, a software library of optimized math routines

Rapid Access Service

Retrieved from "https://docs.alliancecan.ca/mediawiki/index.php?title=Niagara_Quickstart/fr&oldid=54516"