su4.01.01 Notice d’utilisation du cluster de calcul CRONOS#
Résumé
Ce document est une présentation succincte du serveur de calcul Cronos , serveur de calcul interne EDF commun à la R&D et DIPNN.
On donne les consignes de base et les particularités de ce serveur que tout utilisateur doit avoir assimilées pour pouvoir utiliser la machine.
On fournit aussi quelques informations sur le lancement de calcul.
` <#_Toc384310253>`_
Présentation#
Le serveur de calcul est composé de:
5 nœuds de connexion pour les utilisateurs («frontales»),
plus de 1500 nœuds de calcul de (48 cœurs par nœud) sans disque local (partition cn),
environ 300 nœuds de calcul (48 cœurs par nœud) avec 1 To de disque local (partition bm),
2 nœuds avec une grande quantité de mémoire et 1 To de disque local (partition tm),
70 nœuds pour la visualisation graphique (partition vn).
Les caractéristiques détaillées sont disponibles sur: https://si-scientifique.edf.fr/index.php/CRONOS_Section
Les frontales de connexion sont accessibles avec l’alias cronos.hpc.edf.fr qui répartit la charge sur les 5 frontales. En cas de souci, il est possible de choisir explicitement une des frontales (ex. cronos2.hpc.edf.fr).
Remarque
Tout incident, toutes questions sur le serveur doivent être adressésau support informatique. L’équipe de code_aster/salome_meca n’a aucundroit d’administration sur le serveur.
Caractéristiques des nœuds de calcul#
Les nœuds de calcul sont des machines qui ne sont pas accessibles aux utilisateurs directement. Les calculs soumis en batch (avec le gestionnaire Slurm) seront exécutés automatiquement sur un ou plusieurs nœuds, par le système, de façon transparente pour les utilisateurs.
Il n’est pas possible de se connecter directement sur les nœuds de calcul, par contre le fait de disposer d’un calcul s’exécutant en batch sur un ou plusieurs nœuds de calcul autorise l’utilisateur à ouvrir une connexion ssh qui sera immédiatement interrompue dès l’arrêt du job associé.
Il est important de comprendre la différence entre les nœuds des partitions cn et bm.
Les nœuds de calcul de la partition cn ne disposent pas de disque local. Lors des calculs avec code_aster, les objets en mémoire peuvent être déplacés sur disque pour libérer la mémoire. Sur les nœuds cn, le «disque» est en fait en mémoire et donc en quantité limité.
C’est pourquoi, par défaut, les calculs sont dirigés vers l’une ou l’autre des partitions en fonction des ressources demandées.
Sur ces deux points, on donne des explications au paragraphe 3.4 .
Interlocuteurs des utilisateurs#
Cronos est intégralement exploitée par EDF DSP.
Il faut contacter votre support informatique habituel pour tout incident ou demande informatique (problème d’exploitation, de connexion, perte de mot de passe, augmentation de quota, problème avec les classes de batch…).
En cas de problème de lancement de code_aster, vous pouvez contacter l’équipe code_aster/salome_meca sur Teams Equipe codeaster ou bien en émettant une fiche REX.
Demande de création d’un compte#
L’accès au serveur se fait avec le compte et le mot de passe Calibre/Scibian.
Il faut demander l’accès auprès de votre correspondant informatique.
Pour les stagiaires ou les doctorants, la demande de compte doit être faite par leur responsable EDF.
Remarque
P our les personnes dépendant de la DPINN, il faut demander au Responsable d’Utilisation Principal de code_aster & salome_meca pour avoir accès aux répertoires de code_aster.
Espace disque#
Consulter la page concernant l’architecture du cluster pour les détails, les quotas.
En résumé, l’utilisateur dispose: /home/<nni> et /scratch/users/<nni>.
Pour le partage de données entre utilisateurs, il existe des espaces projets (demander au correspondant informatique).
L’espace disponible et la politique de sauvegarde sur chaque répertoire sont précisés sur: https://si-scientifique.edf.fr/index.php/Architecture_CRONOS_Clusters_EN ` <https://si-scientifique.edf.fr/index.php/Architecture_CRONOS_Clusters_EN>`_
Première connexion au serveur#
L’accès à la machine s’effectue par la commande ssh:
ssh cronos.hpc.edf.fr
Pour avoir un export du DISPLAY automatique vers la machine de l’utilisateur, il faut ajouter –X:
username@dsp0123456:~$ ssh -X cronos.hpc.edf.fr
…
username@crfront1:~$ echo $DISPLAY
localhost:12.0
Le DISPLAY est positionné sur «localhost:12» ce qui correspond à un renvoi automatique vers l’écran de l’ordinateur source. Le numéro du DISPLAY, ici 12, est incrémenté automatiquement par le serveur et l’utilisateur n’a pas à s’en soucier.
La présence d’un système de protection (parefeu) rend impossible la connexion ssh sortante et la recopie de fichier scp depuis les serveurs frontaux. Il faut impérativement se placer sur la station cible pour pouvoir recopier un fichier:
username@dsp0123456:~$ scpcronos.hpc.edf.fr:chemin-fichier-source fichier-local
Configuration pour une authentification sans mot de passe#
En général, la connexion vers le serveur peut se faire sans que le mot de passe ne soit demandé, grâce au système Kerberos. À l’ouverture d’une session sur la machine locale, un serveur délivre un ticket valable un certain temps (10 heures par exemple) qui permet ensuite de se connecter à d’autres services autorisés sans authentification supplémentaire pendant cette période. Ceci fonctionne sur les machines locales Scibian.
La possibilité de connexion sans mot de passe est utilisée par salome_meca/astk pour exécuter des calculs à distance, suivre l’avancement des calculs, etc. Il arrive que la session soit plus longue que la durée de validité du ticket. Il est donc préférable d’ajouter en plus la possibilité de se connecter sans mot de passe grâce aux clés SSH.
On montre ici comment configurer l’accès sans mot de passe, basée sur des échanges de clés cryptées privées/publiques.
Application au serveur de calcul#
Pour rendre la connexion sans mot de passe possible depuis une machine locale vers Cronos, il faut remplacer dans les étapes du paragraphe suivant:
user1 par le login de la machine locale (pour Calibre ce sera le NNI);
machine1 par le mot complet de la machine locale;
user2 par le login sur le cluster Cronos, i.e. le NNI;
machine2 par cronos.hpc.edf.fr
Seule la connexion sans mot de passe depuis une machine locale vers le cluster est nécessaire.
Mise en œuvre#
étape 1 - vérifier l’existence des clés RSA:
user1@machine1: ~$cd ~/.ssh
user1@machine1: ~/.ssh$ ls id_rsa*
id_rsa id_rsa.pub
Si ces fichiers existent, il faut passer à l’étape 3 (recopie des clés). Remplacer les clés existantes aura pour conséquence de casser l’accès sans mot de passe déjà effectué pour d’autres machines.
Si ces fichiers n’existent pas, il faut passer à l’étape 2 (génération des clés).
étape 2 - générer les clés de type RSA sur la machine locale, si elles n’existent pas :
user1@machine1: ~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa): ne rien écrire, taper entrée
Created directory “/home/user1/.ssh”.
Enter passphrase (empty for no passphrase): ne rien écrire, taper entrée
Enter same passphrase again: ne rien écrire, taper entrée
Your identification has been saved in /home/user1/.ssh/id_rsa.
Your public key has been saved in /home/user1/.ssh/id_rsa.pub.
The key fingerprint is:
5d:90:be:07:93:6d:61:e1:e8:43:0f:44:c6:19:d1:c2 user1@machine1
The key’s randomart image is:
+–[ RSA 2048]—-+
| +B*.. |
| oE++ |
| *.+=o.* |
| +=+o |
| S +=. |
| *…* |
| *.* |
| |
| |
+—————–+
étape 3 - copier la clé de la Machine1 vers la Machine2:
user1@machine1 :~$ ssh-copy-id user2@machine2
The authenticity of host “machine2” can’t be established.
RSA key fingerprint is 4f:35:5f:7e:ba:61:8c:b2:f0:13:bd:a3:b3:a9:e9:04.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added “machine2” (RSA) to the list of known hosts.
user2@machine2’s password:
Now try logging into the machine, with « ssh “user2@machine2” », and check in:
.ssh/authorized_keys
to make sure we haven’t added extra keys that you weren’t expecting.
étape 4 - se connecter à la Machine2
user1@machine1: ~$ssh user2@machine2
Il est maintenant possible de se connecter sans mot de passe.
Fichier de configuration#
Dans le cas où les logins sur les Machine1 et Machine2 sont les mêmes, il n’est pas nécessaire de les préciser.
Dans le cas où les logins sont différents, il peut être utile d’utiliser le fichier de configuration ssh pour définir des alias de nom. Il doit se trouver dans le répertoire .ssh et s’appeler config. S’il n’existe pas, il faut le créer.
user1@machine1: ~$cd ~/.ssh
user1@machine1: ~/.ssh$ gedit config
Le fichier pourra ressembler à ceci:
ForwardX11 yes
StrictHostKeyChecking no
ForwardX11 yes permet d’activer par défaut l’option -Xpermettant de rediriger le DISPLAY.
Remarque#
Une sécurité supplémentaire est parfois présente lorsque l’on utilise SSH (cela dépend des machines): la première connexion à une nouvelle machine doit être validée par l’utilisateur:
username@clau5cjc:~$ ssh xxx.hpc.edf.fr
The authenticity of host “xxx.hpc.edf.fr (10.114.116.21)” can’t be established.
RSA key fingerprint is 4f:35:5f:7e:ba:61:8c:b2:f0:13:bd:a3:b3:a9:e9:04.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added “xxx.hpc.edf.fr,10.114.116.21” (RSA) to the list of known hosts.
username@xxx.hpc.edf.fr’s password:
Lorsque l’utilisateur accepte la connexion (en tapant yes), l’adresse RSA de la machine distante est ajoutée dans un fichier sur le poste de l’utilisateur. Lors des connexions suivantes, la machine sera déjà autorisée et le message ne sera pas affiché.
Utilisation de code_aster sur Cronos#
À partir de salome_meca 2021, le serveur devrait déjà être configuré. Dans les versions précédentes, il est nécessaire de suivre les étapes ci-dessous.
Ajout du serveur Cronos dans SALOME/AsterStudy#
Après s’être assuré que l’on pouvait se connecter depuis son poste local vers Cronos sans mot de passe (utilisation d’une clé SSH), on peut faire la configuration du nouveau serveur dans salome_meca.
Dans salome_meca 2020, il ne faut pas utiliser le nom complet cronos.hpc.edf.fr puisqu’il y avait une configuration automatique dans AsterStudy pour paramétrer le répertoire de travail pour Eole et Gaia.
Mode opératoire:
Lancer salome_meca et ouvrir le module JobManager;
Dans la partie en bas à droite «Resource Catalog», ajouter un serveur en renseignant les valeurs suivantes:
Dans «Hostname», ne pas renseigner le nom avec le nom de domaine hpc.edf.fr (voir ci-dessous);
Dans «Working Directory», renseigner son propre NNI;
En renseignant, «cronos» dans «hpc.edf.fr», il faut s’assurer qu’on peut y accèder. Faire «ssh cronos» pour le vérifier. Si ce n’est pas le cas, il faut éditer (ajouter le cas échéant) le fichier $HOME/.ssh/config et y insérer:
Host cronos
HostName cronos.hpc.edf.fr
Après cela, «ssh cronos» doit être fonctionner et être équivalent à «ssh cronos.hpc.edf.fr».
Ajout du serveur Cronos dans astk#
Après s’être assuré que l’on pouvait se connecter depuis son poste local vers Cronos sans mot de passe (utilisation d’une clé SSH), on peut faire la configuration du nouveau serveur dans l’interface ASTK.
Mode opératoire:
Aller dans ASTK / Configuration / Serveurs;
Sur la liste à choix en haut de la fenêtre, sélectionner le dernier choix «Nouveau Serveur»;
Entrer un nom, par exemple «cronos»;
Concernant les autres champs, se reporter à la capture suivanteet ne pas oublier de remplacer NNI par son propre NNI:
Cliquer sur bouton «Rafraîchir maintenant!»
Localisation des outils#
Sur Cronos, les commandes courantespour lancer astk, as_run ou salome sont accessibles dans /software/restricted/simumeca/aster/bin.
nni@crfront1: ~$ls /software/restricted/simumeca/aster/bin
as_run astk salome
Il est préférable d’utiliser ces liens qui pointent vers les véritables chemins d’installation pour accéder aux dernières mises à jour des produits.
Lancement de calculs en batch#
L’accès aux nœuds de calculs pour y lancer des processus interactif n’étant pas autorisé, l’unique moyen de lancer des calculs est de passer par le gestionnaire de batch. Le gestionnaire de batch utilisé est slurm. On pourra se reporter au document suivant:
https://si-scientifique.edf.fr/index.php/SLURM_CRONOS_Clusters_EN
On y trouvera en particulier comment exécuter sur des nœuds de calculs des commandes en interactif. Le principe est de réserver des ressources avec salloc, puis de se connecter en interactif au nœud de calcul alloué.
Voir aussi les commandes utiles:
cce_mqinfo: donne des détails sur les files disponibles
cce_mpinfo: donne des informations sur la disponibles des nœuds de calculs
cee_mpp: liste les jobs de l’utilisateur (équivalent de squeue)
Choix des classes de batch en fonction de la mémoire#
Il y a trois partitions principales pour le lancement de calcul: cn, bm et tm.
Il faut choisir la bonne partition en fonction du calcul à effectuer.
Avec AsterStudy, il suffit de donner le nom de la partition à utiliser dans les paramètres de lancement (onglet «Advanced/Server partition»).
Avec astk, on peut aussi renseigner le nom de la partition dans le menu «Options/classe».
De plus, quand le lancement est géré par astk, si la partition n’a pas été donnée par l’utilisateur, elle est choisie automatiquement (en fonction des cas fréquents).
La mémoire disponible par nœud est de:
192 ou 384 Go pour cn (5 fois plus de nœuds que bm)
384 ou 768 Go pour bm
6 To pour tm
Le critère considère la mémoire demandée par nœud. Si on demande 8 Go pour un calcul séquentiel, la mémoire demandée par nœud est de 8 Go. S’il s’agit d’un calcul parallèle avec 6 processus par nœud, la mémoire demandée par nœud est de 24 Go.
Dans tous les cas, on ne change pas la mémoire réservée pour code_aster. On modifie uniquement la mémoire maximale pour le job.
Le choix automatique est le suivant:
Si la mémoire par nœud est inférieure à 64 Go, on choisit la partition cn et on demande 96 Go de plus pour le job (soit par exemple 24 + 96 dans l’exemple précédent) qui pourront être utilisés comme «disque».
Si la mémoire par nœud est supérieure à 300 Go, on choisit la partition bm.
Si la mémoire par nœud est supérieure à 700 Go, on choisit la partition tm.
L’objectif est d’utiliser les nœuds cn quand cela est possible puisqu’ils sont bien plus nombreux.