Niagara ː Guide de démarrage

From CC Doc
Jump to: navigation, search
This page is a translated version of the page Niagara Quickstart and the translation is 70% complete.

Other languages:
English • ‎français

Renseignements et spécifications de 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+ et routage dynamique. L'ordonnanceur Slurm accepte les tâches d'une durée d'au moins 15 minutes et d'au plus 12 ou 24 heures en priorisant les tâches intensives.

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

Si vous êtes un nouvel utilisateur de SciNet et que vous appartenez à un groupe dont le chercheur principal ne dispose pas de ressources allouées par le concours d'allocation de ressources, vous devez obtenir un compte SciNet.

Autrement, comme c'est le cas avec toutes les grappes de Calcul Canada et de SciNet, vous ne pouvez vous connecter que 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.

Si vous ne pouvez vous connecter, vérifiez d'abord l'état de la grappe.

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 : L'espace d'archivage n'est présentement disponible que sur HPSS.

IMPORTANT : Mesure préventive

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

Gestion des données

Systèmes de fichiers

/home

Principalement destiné aux fichiers des utilisateurs, logiciels communs et ensembles de données de petite taille, pourvu qu'ils ne dépassent pas les quotas individuels; autrement, utilisez /scratch ou /project. Le système de fichiers /home est en lecture seule sur les nœuds de calcul.

/scratch

Principalement destiné aux fichiers temporaires ou transitoires, résultat de calculs ou de simulations et au contenu pouvant être recréé ou réacquis. Peut aussi être utilisé pour les étapes intermédiaires d'un processus pourvu qu'il n'y ait pas trop d'opérations en lecture/écriture ou trop de petits fichiers pour cet espace de stockage sur disque partagé; autrement, utilisez /bb (burst buffer). Les résultats à conserver à long terme peuvent être migrés vers /project ou /archive. Le système de fichiers /scratch est purgé régulièrement; aucune copie de sauvegarde n'en est faite.

/project

Principalement destiné aux logiciels de groupes communs, grands ensembles de données statiques et au contenu difficile à réacquérir ou regénérer par le groupe. Son contenu devrait être relativement stable dans le temps. Les fichiers temporaires ou transitoires devraient se trouver sur /scratch. Le traitement intensif des données consomme beaucoup d'espace sur les bandes du système de sauvegarde TSM et ce longtemps après que les données sont supprimées, ceci en raison des politiques de rétention des sauvegardes et des versions supplémentaires du même fichier. Les utilisateurs qui en font un mauvais usage seront remarqués et contactés. Le système de fichiers /project est disponible uniquement aux groupes qui disposent de ressources allouées par concours.

/bb (burst buffer)

Mémoire tampon d'accès en rafale sur disques SSD, alternative très performante pour /scratch. Vous pouvez demander cette ressource si vous vous attendez à trop d'opérations IO/IOPs pour /scratch ou si la performance de votre tâche laisse à désirer sur /scratch ou /project parce que les opérations d'I/O causent des goulots d'étranglement. N'oubliez pas qu'en tout temps, seulement 232To sont disponibles pour les utilisateurs. Une fois que vos résultats sont produits, groupez-les (bundle ou tarball) et déplacez-les vers /scratch, /project ou /archive. Le système de fichiers /bb est purgé très fréquemment.

/archive

Espace de stockage partagé nearline utilisé pour héberger temporairement des données en provenance des autres systèmes de fichiers. En pratique, il sert à déposer et récupérer des données lors du déroulement d'un processus ou lorsque les quotas sont atteints dans /scratch ou /project. Ce contenu peut demeurer sur HPSS pendant quelques mois ou quelques années. Le système de fichiers /archive est disponible uniquement aux groupes qui disposent de ressources allouées par concours.

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 MPIMessage Passing Interface-IO (part of the MPIMessage Passing Interface-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

Avec rsync/scp

Déplacer moins de 10Go par les nœuds de connexion

  • Seulement les nœuds de connexion Niagara visibles de l'extérieur de SciNet.
  • Utilisez scp ou rsync vers niagara.scinet.utoronto.ca ou niagara.computecanada.ca (aucune différence).
  • Il y aura interruption dans les cas où il y a plus qu'environ 10Go.

Déplacer plus de 10Go par les nœuds de copie

  • À partir d'un nœud de connexion Niagara par ssh vers nia-datamover1 ou nia-datamover2.
  • Les transferts doivent se faire à partir de ce nœud de copie.
  • L'autre partie (votre ordinateur) doit pouvoir être rejointe de l'extérieur.
  • Si vous transférez souvent de telles quantités, considérez l'outil web Globus.

Déplacer des données vers HPSS/Archive/Nearline avec l'ordonnanceur

Avec GlobusGlobus is a file transfer service [https://www.globus.org/]

Si vous déplacez souvent des quantités de plus de 10Go, considérez l'outil web GlobusGlobus is a file transfer service [https://www.globus.org/].

Consultez la documentation Globus.

Le point de chute GlobusGlobus is a file transfer service [https://www.globus.org/] est "computecanada#niagara".

Stockage et quotas

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

Lancez ensuite les deux commandes

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.
  • Pour ce qui est de PROJECT, le superviseur de votre groupe devra définir les accès ACL appropriés au niveau /project/G/GROUP pour que les utilisateurs des autres groupes puissent avoir accès à vos fichiers.
  • ACL ne vous permet pas d'accorder des permissions pour des fichiers ou des répertoires qui ne vous appartiennent pas.
  • 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.

Pour plus d'information, consultez mmputacl et mmgetaclacl.

Recursive ACL script

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

Courtoisie d'Agata Disks (http://csngwinfo.in2p3.fr/mediawiki/index.php/GPFS_ACL).

Politique de purge pour scratch

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

Le fichier contient (dans la dernière colonne) la liste de tous les fichiers à supprimer, visible avec des commandes standards comme more/less/cat, par exemple 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.

Vérifier l'espace disque disponible

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

Pour savoir quels sont vos répertoires qui contiennent plus de 1000 fichiers, utilisez la commande /scinet/niagara/bin/topUserDirOver1000list; la commande /scinet/niagara/bin/topUserDirOver1GBlist vous permet de savoir quels répertoires contiennent plus de 1Go.

Note :

  • les renseignements sur l'utilisation et les quotas est mise à jour aux trois heures seulement.

Trucs pour les opérations lecture/écriture

  • $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 en réalité deux environnements logiciels 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.

Voyez l'information sur les fichiers par défaut .bashrc et .bash_profile.

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, intelintel/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 MKLIntel Math Kernel Library, a software library of optimized math routines(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 MKLIntel Math Kernel Library, a software library of optimized math routines, 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 MPIMessage Passing Interface

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