1. Slurm

Slurm es un sistema de Código Abierto, tolerante a fallos y altamente escalable de gestión de clústeres y de programación de trabajos para grandes y pequeños clústeres de Linux. Incluye su propio administrador de recursos y un sistema de gestión de usuarios, por lo que no se necesita emplear TorquePBS + MAUI. Por favor vea nuestra guía de inicio rápido con SLURM

2. Acceso

Las conexiones SSH a nuestro clúster son públicas, solo necesita un cliente SSH y conectarse al servidor LOGIN.UCLV.HPC.CU por el puerto 2222.

Si se producen varios intentos fallidos de acceso mediante SSH, el sistema puede bloquear de forma permanente la IP de origen. En caso de no poder acceder mediante SSH puede contactarnos mediante la dirección de correo soporteuclv@listas.hpc.cu

Sí, mediante el comando UNIX passwd. No obstante, la nueva contraseña debe ser equivalente en fortaleza al generado aleatoriamente inicialmente o sea poseer al menos 10 caracteres que contengan mayúsculas y minúscualas, así como caracteres numéricos y especiales. Puede generar contraseñas fuertes en passwordsgenerator.net

El uso de una contraseña débil puede comprometer el acceso a nuestro clúster por lo que se recomienda encaracidamente emplear contraseñas generadas aleatoriamente y que cumplan los requerimientos anteririores.

Tenga presente que periodicamente hacemos auditorías de seguridad sobre las contraseñas para identificar las débiles

3. Ejecución de trabajos

El nodo de login está pensado primeramente para la carga e instalación de módulos de software científicos, subida de trabajos y monitoreo, así como post-procesamiento de datos y administración. En términos de hardware no necesariamente tiene que poseer la misma capacidad de un nódo de cómputo por lo que los trabajos deben ser subidos a la cola de procesamiento para ser desplegados en los nodos de cómputo.

I.e. what values of N and n should be used in the batch script directives:

#SBATCH –nodes=N
#SBATCH –ntasks=n

or, equivalently, on the command line as

sbatch –nodes=N –ntasks=n jobscript ?

Since the HPCS allocates entire nodes to jobs, the most important parameter is N, as this will determine the resources made available to the job and also the rate of charge. By default SLURM will assume that all the processor cores and memory in each allocated node are available to the job. The number of tasks n is passed into the job environment for the benefit of SLURM-aware software, e.g. to influence the number of MPI tasks started.

The important pieces of information are:

  • Sandy Bridge (Darwin) nodes each have 16 CPU cores and 63900 MB of usable memory;
  • Westmere (Darwin) nodes each have 12 CPU cores and 35700 MB of usable memory
  • Tesla (Wilkes) nodes each have 12 CPU cores and 63900 MB of usable memory.

The simplest case is that in which either mpirun/mpiexec or srun are going to launch a task on every CPU core in the allocated nodes. Here one merely has to decide what multiple of 16 (for Sandy Bridge) or 12 (for Westmere or Tesla) will be the total number of tasks, and this immediately determines n and N. E.g. 32 tasks on Sandy Bridge would obviously imply n=32 and N=2.

The situation becomes more complex if, for example, 16 MPI tasks would require more than 63900 MB of memory on a Sandy Bridge node, or if each task was designed to spawn additional threads thus requiring additional CPU cores per task. In both of these scenarios, it would be necessary to communicate to MPI to launch fewer than 16 tasks per node. The template job submission scripts will take care of this based on the supplied values of N and n. Assume that only p such tasks will fit in a single node. Now one needs to decide what multiple of p will be the total number of tasks, and this immediately determines n and N. E.g. if p=8, then 32 tasks on Sandy Bridge would imply n=32 andN=4.

El programador de colas usa un sofisticado algoritmo para determinar qué trabajo debe correrse y cuándo, en base a factores como la calidad de servicios del trabajo que a sido solicitado, cuanto tiempo lleva el trabajo esperando,

whether the project to which the user belongs is achieving its “fair share” of resources, and whether the job can “backfill” resources reserved by a larger job already scheduled to start.

More technically, priority is based on QOS factor, fair share factor and queue time factor. For more information about what this means, please see the SLURM documentation.

Please bear in mind that for a busy system, on which jobs typically have a running time of 12 or 36 hours, it should not be considered unreasonable to have a large job wait 12 hours in the queue before it receives an opportunity to run. Also the scheduler can only operate on the basis of the information provided at submission time – if you have a 30 minute job but just use the default of 12 hours’ walltime when submitting, expect to wait longer to run than if you’d stated 30 minutes correctly. This is obvious, because it is easier to find room for smaller blocks of resources than larger ones (at least on a finite cluster) and the scheduler here would assume you needed a block of core hours 24 times too big.

4. General

Hay muchas, muchas introducciones a los comandos de UNIX en la web.

También puedes consultar la recopilación de comandos “Thirty Useful Unix Commands“.

Load More