2. Presentation#
The calculation server is composed of:
5 connection nodes for users (« front ends »),
more than 1500 compute nodes (48 cores per node) without a local disk (cn partition),
approximately 300 compute nodes (48 cores per node) with 1 TB of local disk (BM partition),
2 nodes with a large amount of memory and 1 TB of local disk (tm partition),
70 nodes for graphical visualization (vn partition).
Detailed specifications are available on: < https://si-scientifique.edf.fr/index.php/CRONOS_Section >` https://si-scientifique.edf.fr/index.php/CRONOS_Section`_
The login interfaces are accessible with the alias cronos.hpc.edf.fr which distributes the load on the 5 front ends. In case of problems, it is possible to explicitly choose one of the front ends (e.g. cronos2.hpc.edf.fr).
Note
Any incident, any questions about the server must *be addressed to IT support. The code_aster/salome_meca team has**no administration rights on the server. *
2.1. Characteristics of compute nodes#
Compute nodes are machines that are not accessible to users directly. Calculations submitted in batch (with the Slurm manager) will be executed automatically on one or more nodes, by the system, transparently for users.
It is not possible to connect directly to the calculation nodes, on the other hand, the fact of having a calculation running in batch on one or more calculation nodes allows the user to open an ssh connection which will be immediately interrupted as soon as the associated job is stopped.
It is important to understand the difference between the nodes in the cn and mb partitions.
The compute nodes in the cn partition do not have a local disk. When calculating with code_aster, objects in memory can be moved to disk to free up memory. On cn nodes, the « disk » is in fact in memory and therefore in a limited quantity.
This is why, by default, calculations are directed to one or the other of the partitions according to the resources requested.
On these two points, explanations are given in paragraph 3.4.
2.2. User contact persons#
Cronos is fully operated by EDF DSP.
You must contact your usual IT support for any computer incident or request (operating problem, connection problem, password loss, quota increase, problem with batch classes…).
In case of problems launching code_aster, you can contact the code_aster/salome_meca team on `Teams Team codeaster < https://teams.microsoft.com/l/team/19%3A3049719acc97450ca6c237fa341635bc%40thread.skype/conversations?groupId=f34ca4c1-9e38-4558-8334-44a6424134fa&tenantId=e242425b-70fc-44dc-9ddf-c21e304e6c80>`_ or by issuing a `sheet < https://aster.retd.edf.fr/rex/> #dnt_ifmokifepfmfkmeibbmkibhndkemlkpd`_.
2.3. Request to create an account#
Access to the server is done with the Calibre/Scibian account and password.
You must request access from your IT correspondent.
For interns or doctoral students, the account request must be made by their EDF manager.
note
P For people dependent on DPINN, you must ask the main user manager of code_aster & salome_meca to have access to the code_aster directories.
2.4. Disk space#
Consult the cluster architecture page for details and quotas.
<nni>In summary, the user has: /home/ <nni>and /scratch/users/.
For the sharing of data between users, there are project areas (ask the IT correspondent).
The available space and the backup policy on each directory are specified on: < https://si-scientifique.edf.fr/index.php/Architecture_CRONOS_Clusters_EN >` https://si-scientifique.edf.fr/index.php/Architecture_CRONOS_Clusters_EN`_ < https://si-scientifique.edf.fr/index.php/Architecture_CRONOS_Clusters_EN >``_
2.5. First connection to the server#
Access to the machine is done by the ssh command:
ssh cronos.hpc.edf.fr
To have an automatic export of DISPLAY to the user’s machine, you must add —X:
username @dsp0123456: ~$ ssh -X cronos.hpc.edf.fr
…
username @crfront1: ~$ echo $ DISPLAY
localhost:12.0
username @crfront1: ~$
The DISPLAY is set to « localhost:12 » which corresponds to an automatic referral to the source computer screen. The number DISPLAY, here 12, is automatically incremented by the server and the user does not have to worry about it.
The presence of a protection system (firewall) makes it impossible to send an outgoing SSH connection and to copy scp files from the front servers. It is imperative to be on the target station to be able to copy a file:
username @dsp0123456: ~$ scpcronos.hpc.edf.fr:path-source-file-local-file
2.6. Setting up for passwordless authentication#
In general, the connection to the server can be done without requiring the password, thanks to the Kerberos system. When a session is opened on the local machine, a server issues a ticket valid for a certain time (10 hours for example) which then allows you to connect to other authorized services without additional authentication during this period. This works on local Scibian machines.
The possibility of logging in without a password is used by salome_meca/astk to execute calculations remotely, monitor the progress of calculations, etc. Sometimes the session is longer than the validity period of the ticket. It is therefore preferable to also add the possibility of logging in without a password using the SSH keys.
Here we show how to configure passwordless access, based on private/public encrypted key exchanges.
2.6.1. Compute server application#
To make it possible to connect without a password from a local machine to Cronos, you must replace in the steps in the following paragraph:
user1 by the login of the local machine (for Calibre it will be NNI);
machine1 with the full word of the local machine;
user2 by logging in to the Cronos cluster, i.e. NNI;
machine2 by cronos.hpc.edf.fr
Only passwordless login from a local machine to the cluster is required.
2.6.2. Implementation#
step 1 - check the existence of keys RSA:
user1 @machine1: ~$cd ~/.ssh
user1 @machine1: ~/.ssh$ ls id_rsa*
id_rsa id_rsa.pub
If these files exist, you must go to step 3 (recopying the keys) . Replacing the existing keys will result in breaking the passwordless access already made for other machines.
If these files do not exist, you must go to step 2 (key generation).
step 2 - generate RSA keys on the local machine, if they don’t existe:
user1 @machine1: ~$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user1/.ssh/id_rsa) : write nothing, type enter
Created directory “/home/user1/.ssh” .
Enter passphrase (empty for no passphrase) : don’t write anything, type enter
Enter same passphrase again: don’t write anything, type enter
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:6 D:61:E1:E1:E 8:43:0 F:44:C 6:19:D1:C2 user1 @machine1
The key’s randomart image is:
+– [RSA 2048] —-+
| +B*.. ****|
| oE++ |
| *. +=o.****|*
| +=+o |
| S +=. |
| *… ****|*
| *.****|*
| |
| |
+—————–+
step 3 - copy the key from Machine1 to Machine2:
user1 @machine1 : ~$ ssh-copy-id user2 @machine2
The authenticity of host “machine2” can’t be established.
RSA key fingerprint is 4f: 35:5 f:7e:ba: 61:8 c:b2:f 0:13:bd:a3:b3:a9:e 9:e 9: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.
step 4 - connect to Machine2
user1 @machine1: ~$ssh user2 @machine2
It is now possible to log in without a password.
2.6.3. Configuration file#
If the logins on Machine1 and Machine2 are the same, it is not necessary to specify them.
In case the logins are different, it may be useful to use the ssh configuration file to define name aliases. It should be in the.ssh directory and be called config. If it does not exist, it must be created.
user1 @machine1: ~$cd ~/.ssh
user1 @machine1: ~/.ssh$ gedit config
The file may look like this:
ForwardX11 yes
StrictHostKeyChecking no
ForwardX11 yes allows you to activate by default the -X option allowing you to redirect DISPLAY.
2.6.4. note#
An additional security is sometimes present when using SSH (it depends on the machines): the first connection to a new machine must be validated by the user:
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:5 f:7e:ba: 61:8 c:b2:f 0:13:bd:a3:b3:a9:e 9:e 9: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:
When the user accepts the connection (by typing yes), the RSA address of the remote machine is added to a file on the user’s computer. During subsequent connections, the machine will already be authorized and the message will not be displayed.