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

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 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

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

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)

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

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

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

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

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 :

#SBATCH --constraint=NoPreemption

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

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:

#SBATCH --constraint=Xeon-E5-2630-v4

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

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

#SBATCH --constraint=Infiniband