Positionnement de Plafrim: machine expérimentale, avec une diversité de types de machines disponibles. Le passage à l’échelle des programmes doit être fait sur d’autres clusters (mésocentre, GENCI, …)
Changement dans Slurm: sans aucune contrainte sur le job, Slurm va attribuer des machines suivant cette liste de priorités: d’abord les zondas (pas de réseau rapide, ni GPUs, …), puis miriel (vieux), puis bora, puis les autres types de machines plus spécifiques (GPU, ARM, mémoire, …). Ce changement devrait être communiqué et documenté rapidement. Pour demander un type de machine particulier, il faut utiliser l’option -C des commandes Slurm (voir https://www.plafrim.fr/hardware-documentation/). On évite ainsi des donner des machines aux caractéristiques particulières à des jobs qui n’utilisent pas ces caractéristiques.
Il y a maintenant une queue preempt dans laquelle les jobs sont exécutés quand la machine n’est pas utilisée, mais ils peuvent être préemptés si d’autres jobs arrivent. Il faut avoir un système de checkpointing pour bien en profiter.
Besoins matériels rapportés:
GPUs récents
Quelques nœuds avec GPUs et beaucoup de mémoire comme sirocco21
Des nœuds avec réseau rapide et beaucoup de RAM pour les gros problèmes de simulation 3D, mais PlaFRIM ne pourra pas en avoir beaucoup, il faut rapidement passer au MCIA
Pas besoin de gros nœud pour remplacer souris/brise, diablo05 suffit la plupart du temps
Noeuds ARM avec GPU et réseau rapide, voire RISC-V, si possible proche de ce qui risque d’arriver dans le projet Exascale France et/ou EPI.
Encore trop tôt pour les FPGA mais continuer à surveiller (comme toujours, essayer d’avoir les machines qui seront demain dans les grands centres de calculs)
Un dataverse pour stocker des données, y compris pour la reproductibilité (voir avec JM Frigerio de l’INRAE)
Besoins logiciels rapportés:
Pouvoir utiliser des nœuds Plafrim comme runner GitLab ou slave Jenkins (les vieilles machines mistral avec des GPU pourraient être utilisées pour ça)
Une interface REST pour soumettre sans passer par la ligne de commande
Avoir une contrainte comme ‘mpi’ pour signaler les nœuds qui ont un réseau rapide (mais il faudrait que slurm prenne des nœuds dans la même partition pour que mpi marche)
Beaucoup de points peuvent être améliorés dans la documentation (sur plafrim.fr):
Expliquer les warnings souvent rencontrés avec MPI et les réseaux rapides
Comment migrer vers un cluster plus important ? (quels clusters sont disponibles, comment migrer son application et ses données)
Documenter la politique d’utilisation, que faire quand on constate un abus
Documenter la version de SLURM installée pour les fonctionnalités avancées comme les jobs héterogènes
Besoin d’éducation par rapport à la politique d’utilisation de Plafrim:
Pas de quota ni de créneaux horaires différenciés pour simplifier les règles d’utilisation et la configuration de Slurm
En échange: utilisation “raisonnée” de la plateforme, ne pas monopoliser tous les nœuds d’un certain type pendant trop longtemps (voir Good usage rules de https://www.plafrim.fr/wp-content/uploads/2015/09/2015_09_charte_plafrim_en.pdf). Si on souhaite utiliser beaucoup de nœuds pendant beaucoup de temps, c’est sans doute signe qu’il faut plutôt utiliser un autre cluster plus grand.
En cas de besoin exceptionnel (publication, …) qui nécessite de monopoliser des nœuds de calcul sur un temps déterminé, une demande pourrait être adressée au Comité Utilisateurs qui donnera son avis et son accord. Ce type de demande est déjà mis en pratique au MCIA.
Si un abus est constaté, ne pas hésiter à contacter le comité technique ou utilisateur.
Nécessité de mieux expliquer cette politique d’utilisation, peut-être dans le mail de confirmation de création du compte
Ne pas hésiter à contacter le comité utilisateur ou technique pour un usage qui sortirait des Good usage rules
Rajouter des informations dans le mail envoyé quand un compte PlaFRIM est créé.