The authenticity of host '...' can't be established. ... This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '...' (...) to the list of known hosts.
La migration vers le cluster IO se fera en plusieurs phases :
phase 0 : tests du cluster IO par certains utilisateurs
phase I : migration des données du scratch, même authentification que sur Muse, cluster muse toujours actif
phase II : extinction définitive du cluster muse
Et en parallèle :
phase authentification et gestion des groupes : authentification via votre compte personnel de votre tutelle (SSO), cluster muse toujours actif
| trouvez toutes les particularités et spécifications du cluster IO sur cette page : cluster-io-specifications |
Durant cette phase, vous avez accès au cluster Muse et au nouveau cluster IO en parallèle.
Authentification :
Dans cette première phase, l’authentification est la même : même login, même mot de passe, même clé ssh. Au lieu de vous connecter à muse-login.meso.umontpellier.fr, vous vous connectez à io-login.meso.umontpellier.fr. Rien ne change, aucune autre action n’est attendue de votre part concernant l’authentification. Néanmoins, pour les clés SSH :
Il faut accepter les clés des nouvelles machines :
The authenticity of host '...' can't be established. ... This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '...' (...) to the list of known hosts.
Le type RSA-1 n’est plus accepté sur IO (si votre clé est de type RSA, mais qu’elle a été généré récemment, vous n’aurez pas de problème). Il faudra alors que vous génériez une nouvelle clé; avec ed25519:
ssh-keygen -t ed25519
HomeDirectory : Votre home directory est strictement le même sur Muse que sur IO. Ce n’est pas une copie, c’est le même. Si vous modifiez un fichier sur IO, vous verrez instantanément cette modification sur Muse.
Workspaces : Les workspaces sont strictement les mêmes sur Muse que sur IO. Ce ne sont pas des copies, ce sont les mêmes. Si vous modifiez un fichier sur IO, vous verrez instantanément la modification sur Muse.
HelpDesk : ticketing à préférer au mail pour toute communication
Documentation : wiki, de nombreuses pages ont déjà été créées. Afin d’être compréhensibles par le plus grand nombre, elles sont à mi-chemin entre des documentations et des cours. C’est un wiki, tout le monde peut participer. Corriger une faute d’orthographe, c’est déjà aider !
Organisation générale par groupes : Sur le cluster IO, tout est organisé en groupes. Un groupe est formé d’un ou plusieurs utilisateurs.
Chaque groupe a un responsable et, éventuellement, des co-responsables. Ces responsables et co-responsables ont plusieurs fonctions :
Ils décident quels utilisateurs peuvent rejoindre le groupe ou en sortir.
Ils décident de ce que deviennent les données laissées par les utilisateurs sortants.
Ils décident à quels services le groupe a accès (calcul, stockage, cloud, …).
Ils décident quels sont les quotas du groupe et leurs évolutions.
Ils assurent le lien pour le paiement des services.
Chaque groupe a un workspace sur le stockage capacitif et un scratch de groupe sur le stockage rapide (scratch).
Le scratch : Le scratch IO est nouveau et il sera vide lors de votre première connexion.
Structuration différente :
Sur le cluster Muse, chaque utilisateur avait un scratch personnel où il était le seul à pouvoir écrire. Ce scratch personnel existe toujours sur cluster IO. Vous le trouverez dans votre homescratch_VotreLogin
Des scratchs de groupe font leur apparition. Ils portent le même nom que les workspaces. Par exemple, si le workspace du groupe est work_yellosub, alors le scratch sera scratch_yellosub et vous verrez dans votre home les répertoires ./work_yellosub et ./scratch_yellosub.
| vous verrez des liens symboliques, en rouge, au moins pendant la durée de la migration. Ces derniers font référence à des dossiers de destination qui n’existent pas. C’est normal, votre dossier personnel est le même sur les deux infrastructures, alors que les chemins vers les scratchs sont différents entre ces denières. |
Purge des fichiers non accédés : Comme sur Muse, les fichiers non accédés depuis au moins un mois sont effacés. Si le remplissage du scratch le permet, l’équipe administratrice du cluster IO se réserve le droit d’augmenter ce délai mais aussi de revenir à un mois sans préavis quand le scratch est trop plein.
Accès gratuit et payant : Le scratch par défaut est inclus dans le prix du calcul. Il est mutualisé entre tous les utilisateurs du calculateur. Ce scratch est donc soumis à des effacements réguliers. Un groupe peut décider de privatiser son espace scratch afin d’éviter la purge mensuelle. Cette privatisation est payante (cf. la page sur les prix).
Soumission des jobs et partitions: un très gros changement par rapport à Muse concerne la manière de soumettre les calculs. Il faut désormais spécifier un account et éventuellement une QoS si celle par défaut ne vous convient pas. Pour déterminer à quoi vous êtes rattaché, vous pouvez utiliser la commande suivante :
sacctmgr list account --associations format=account%30,maxwall,grptres,defaultqos%30,qos%120,User%30 |grep $USER-A), l’avant-dernière colonne à la liste des QOS auxquelles vous avez accès, et la précédente, la QOS par défaut quand vous soumettez un job (à modifier avec option SBATCH -q).
pour avoir les informations concernant une QOS; ici ondemand-short :
|
sacctmgr show qos ondemand-short format=Name%30,maxwall,grptres%35
Name MaxWall GrpTRES
------------------------------ ----------- -----------------------------------
ondemand-short 01:00:00 cpu=2400,mem=19661000MPour utiliser des jobs de plus d’une heure, un utilisateur de ressource à la demande devra spécifier par exemple la QoS cpu-ondemand-long.
Les logiciels :
Modules : module. Les anciens modules ont été conservés, mais tous ne sont pas forcément fonctionnels. Par contre, de nombreux autres modules ont été ajoutés. Il y a un peu plus de 1500 :
modules OpenHPC
anciens modules cv-* et local désormais sous deprecated/. use.own nexiste plus; si vous aviez des modules personnels, vous pouvez les charger en rajoutant le chemin des modules (module use --append ~/privatemodules)
modules IFB core bioinfo-ifb
modules bioinfo du CIRAD bioinfo-cirad
EESSI : EESSI (pas par défaut, à activer)
Singularity-HPC (conteneurs maintenus par la communauté)
Guix : Guix (58000+ logiciels dont 800+ scientifiques)
conda : conda, 25000+ logiciels via conda-forge
spack : un jour peut-être…
Apptainer et Singularity : apptainer (pour installer facilement vos logiciels)
Ressources et répartitions :
les partitions dédiées : sur le cluste Muse vous aviez la possibilité de louer à l’année des serveurs de 28 coeurs, 128 Go de RAM avec 3 To de disque pour 1000€ par an (prix A). Ce sera toujours le cas sur le cluster IO, et les partitions en cours seront reportées de Muse vers IO. Toutefois, il y a quelques modifications :
avec les 28 coeurs, viennent non plus 128 Go de RAM mais 224 Go de RAM. Cette augmentation de la RAM implique une légère augmentation du tarif qui passe de 1000€ à 1158€. Ce changement de prix s’appliquera sur les nouvelles paritions ou sur le renouvellement des partitions actuelles.
vous pouvez réserver plusieurs tranches de 28 coeurs
les coeurs sont virtualisés : 28 coeurs sont réservés mais pas forcément sur le même serveur. Cette virtualisation permet une meilleure résilience aux pannes. Ainsi quand un serveur est hors service il n’impacte plus les ressources des partitions qu’il héberge.
il arrivait que des partitions ne soient pas complètement remplies durant plusieurs semaines. Afin d’optimiser les ressources et donc abaisser l’impact environnemental du cluster IO, des jobs courts issus de def.q pourront passer à hauteur de 25% de la partition. Donc, le temps d’attente maximum engendré par cette mesure n’excédera pas 1h.
synchronisation bi-annuelle (voir avec Vanessa pour le texte)
De nouveaux usages possibles :
Portail OpenOnDemand : https://io-ood.meso.umontpellier.fr
pour monitorer les noeuds du cluster : https://io-ood.meso.umontpellier.fr/node/io-control/3000/d/node-exporter-slurm/node-exporter-slurm?orgId=1
pour ouvrir un virtual desktop
migration du scratch :
TRIER : mettre de côté toutes les données que vous souhaitez transférer sur le nouveau scratch en les mettant avec la commande mv dans un répertoire dédié en racine de votre scratch, par exemple new_scratch
Transférer ensuite vos données depuis l’ancien scratch vers le nouveau scratch en tapant la commande suivante depuis le cluster Muse : nohup rsync -avP ~/scratch/new_scratch/ io-login.meso.umontpellier.fr:~/scratch_$USER/ &
| une migration de scratch, c’est comme un déménagement, le transfert des données est long et lourd, il ne faut prendre que le strict nécessaire ! |
Lire la doc et vous connecter au cluster IO :
la doc du cluster : https://docs.meso.umontpellier.fr/fr/HPC
les spécifications du cluster: https://docs.meso.umontpellier.fr/fr/HPC/CLUSTER/cluster-io-specifications
compatibilité logiciels : vérifier que les logiciels sur l’ancien cluster fonctionnent sur le nouveau cluster
lancer ses premiers jobs de test sur la partition cpu
Contacter le support en cas de problème : https://isdm-tickets.meso.umontpellier.fr (et éviter le contact par mail au risque de ne jamais avoir de réponse)
disown (exemple : rsync -avP ~/scratch/new_scratch/ io-login.meso.umontpellier.fr:~/scratch_$USER/ faire Ctrl+Z; taper bg; puis disown )