~~SLIDESHOW theme=yatil level=4~~
====== Partitions de CALI-2, Feature ======
Cet article décrit deux des notions fondamentales de l'ordonnanceur de travaux //slurm// : 
  * les //partitions//
  * les //features// qui vous permettent de contrôler finement le placement de vos travaux

===== Partitions =====
Une //partition// est un groupe de nœuds de calcul du cluster
  * Les partitions peuvent se « chevaucher », un même nœud peut faire partie de plusieurs partitions
  * Un job slurm ne peut s'exécuter que dans une seule partition

Les partitions sont utilisées :
  * pour grouper des ressources de calcul à peu près "identiques", comme par exemple la partition avec des GPU 
  * pour placer des travaux qui ont des contraintes identiques, par exemple en temps d'exécution
  * pour donner des priorités

Rappel : pour connaître les nœuds de calcul disponibles, consultez [[:materiel-cali2#noeuds_de_calcul | la page de description matérielle]]

Vous trouverez sur CALI :
  * des partitions communes, ouvertes à tout chercheur
  * des partitions dites //privatives//, restreintes à un laboratoire ou groupe de chercheurs
==== Partitions ouvertes à tout chercheur ====
=== Liste ====
^Partition ^Noeuds ^Durée max / job ^# noeuds max / job ^# CPU Max actives / User ^# Max Jobs actif (soumis) / User ^ Infiniband ^ Pré-emptible ? ^
^rapide    |tous sauf GPU  |      1 H|  -|  32|   2 (10)|  Selon placement | Selon placement |
^normal    |tous sauf GPU  |  **2 J**|  -|  120|  - (400)|  Selon placement | Selon placement |
^cluster   |tous sauf GPU  |     45 J|  1|  120|  - (400)|  Selon placement | Selon placement |
^gpu       |Ceux avec GPU  |      2 J|  -|   -|  - (400)|  Non | Selon placement |

Pour ceux qui veulent en savoir plus, les //limites// ci-dessus sont imposées à travers plusieurs mécanismes : 
  * les limites des partitions proprement dites
  * le choix d'une //QoS// utilisateur qui est faite __automatiquement__ lors de la soumission d'un travail
==== Quelle partition choisir ? ====
Le principe général est le suivant : 
  * pour la mise au point de code, jobs très courts : ''rapide''
  * pour les jobs "normaux" : ''normal''
    * point notable : **durée limitée à 2 jours**
  * pour les jobs "longs" : ''cluster''
    * point notable : limité à **un noeud max par job** (pas de job réparti sur plusieurs noeuds)

=== Danger des jobs longs (partition cluster) ===
Les jobs longs (plusieurs jours) sont à éviter autant que possible :
  * Les nœuds de calculs ne sont pas "hautement disponibles", ils peuvent être arrêtés inopinément. Si vous perdez 40 jours de calcul ... vous devrez patienter !
  * L'ordonnanceur réalise un meilleur travail de placement et de répartition des ressources avec des jobs de courte durée

==== Partitions "privatives" (à accès restreint) ====
=== Principe ===
Certains noeuds de calcul ont été financés spécifiquement par des laboratoires ou groupes de chercheurs :
  * ces parties "privatives" peuvent être utilisées par tout le monde
  * mais le laboratoire propriétaire sera prioritaire lorsqu'il en aura besoin

Autrement dit : 
  * les noeuds sont regroupés dans des partitions de haute priorité, utilisables uniquement par le laboratoire propriétaire.
  * si des jobs d'autres partitions sont en cours d'utilisation, ils seront gelés pour laisser de la place

=== Utilisation ===
Afin d'utiliser une partition privative, un membre du laboratoire doit simplement changer le nom de la partition (''%%--partition%%'').

=== Liste ===
^Partition           ^Noeuds  ^ Durée max      ^
^cluster-e5v4-umr850        |node46-57 (2016) |30 J |
^gpu-umr850                 |node58 (2016)    |30 J |
^cluster-e5v4-xlim-electro  |node59-62 (2016) |30 J |
^gpu-umr1248-gtx1080        |node63-64 (2018) |30 J |
^gpu-ircer-gtx1080          |node65 (2018)    |30 J |
^xlim-cc                    |node66 (2019)    |30 J |


===== Les "Features" : contrôler le placement des jobs, éviter la pré-emption =====
==== Principe ====
Chaque //noeud// est marqué avec des //features//. Lorsqu'on lance un job, il est possible de demander son placement sur des noeuds possédant certaines //features//, avec par exemple l'option ''%%--constraint%%''

Sur CALI, vous pouvez utiliser les //features// pour plusieurs usages :
  * demander un type de processeur
  * demander des noeuds **qui ne sont pas soumis à la pré-emption**
  * demander des noeuds **qui ont le réseau Infiniband**

==== Eviter la pré-emption ====
Nous avons déjà vu que certains noeuds sont à la fois dans des partitions ouvertes à tout le monde, et dans des partitions //privatives//, prioritaires. Si un job est lancé dans la partition prioritaire, slurm va, si nécessaire, "libérer" des ressources via le mécanisme de //pré-emption// (gel des jobs en cours). 

Pour éviter ce mécanisme, appelez la //feature// ''NoPreemption''. Par exemple, ajouter :
<file bash>
#SBATCH --constraint=NoPreemption
</file>

__Inconvénient__ le job sera limité aux noeuds les plus anciens de CALI, il ne pourra pas s'exécuter sur les processeurs les plus puissants

==== Choisir un type de processeur ====
Les partitions communes sont hétérogènes. Vous pouvez spécifier sur quel processeur vous voulez exécuter le job. 

Liste des //feature// déclarés (correspondant au nom du processeur) : 
  * ''Xeon-E5-2650-v2''
  * ''Xeon-E5-2630-v4''
  * ''Xeon-4108''

Pour que le job se lance sur des processeurs E5-2630-v4, il faut par exemple ajouter: 
<file bash>
#SBATCH --constraint=Xeon-E5-2630-v4
</file>

Consultez la page [[:materiel-cali2]] pour connaître le nombre de noeuds disponibles pour chaque type de processeur.

==== Réseau Infiniband ====
Tous les noeuds n'ont pas de réseau Infiniband. 

En pratique, seuls 4 noeuds, dont 3 dédiés GPU, ne sont pas équipés. Si vous voulez être certains que votre job disposera du réseau Infiniband (utile pour les calculs distribués MPI), utilisez la //feature// ''Infiniband''
<file bash>
#SBATCH --constraint=Infiniband
</file>