Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Ambos lados, revisión anteriorRevisión previa
Próxima revisión
Revisión previa
es:centro:servizos:hpc [2017/06/16 13:31] – [Acceso al cluster y copia de archivos] jorge.suarezes:centro:servizos:hpc [2024/03/13 10:38] (actual) – [Envío de un trabajo al sistema de colas] fernando.guillen
Línea 1: Línea 1:
-====== Computación de Altas Prestaciones (HPC) ======+====== Cluster de Computación de Altas Prestacións (HPC) ctcomp3  ====== 
 +[[ https://web.microsoftstream.com/video/f5eba154-b597-4440-9307-3befd7597d78 | Video de la presentación del servicio (7/3/22) ]] 
 +====Descripción =====
  
 +El clúster está compuesto en la parte de cómputo por:
 +  *  9 servidores para cómputo general.
 +  *  1 "fat node" para trabajos que requieran mucha memoria.
 +  *  4 servidores para computo con GPU.
 + 
 +Los usuarios solo tienen acceso directo al nodo de login, de prestaciones más limitadas y que no debe usarse para computar. \\
 +Todos los nodos están interconectados por una red a 10Gb. \\
 +Hay un almacenamiento distribuido accesible desde todos los nodos con 220 TB de capacidad conectado mediante una doble red de fibra de 25Gb. \\
 +\\
 +^  Nombre                    ^  Modelo      ^  Procesador                                      Memoria  ^  GPU                         ^
 +|  hpc-login2                |  Dell R440    1 x Intel Xeon Silver 4208 CPU @ 2.10GHz (8c)  |  16 GB    |  -                           |
 +|  hpc-node[1-2]              Dell R740    2 x Intel Xeon Gold 5220 @2,2 GHz (18c)        |  192 GB    -                           |
 +|  hpc-node[3-9]              Dell R740    2 x Intel Xeon Gold 5220R @2,2 GHz (24c)        192 GB    -                           |
 +|  hpc-fat1                  |  Dell R840    4 x Xeon Gold 6248 @ 2.50GHz (20c)              1 TB      -                           |
 +|  hpc-gpu[1-2]  |  Dell R740    2 x Intel Xeon Gold 5220 CPU @ 2.20GHz (18c)    192 GB    2x Nvidia Tesla V100S       |
 +|  hpc-gpu3                  |  Dell R7525  |  2 x AMD EPYC 7543 @2,80 GHz (32c)              |  256 GB    2x Nvidia Ampere A100 40GB  |
 +|  hpc-gpu4                  |  Dell R7525  |  2 x AMD EPYC 7543 @2,80 GHz (32c)              |  256 GB    1x Nvidia Ampere A100 80GB  |
  
-===== Acceso al cluster y copia de archivos =====+===== Conexión al sistema ===== 
 +Para acceder al clúster, hay que solicitarlo previamente a través de [[https://citius.usc.es/uxitic/incidencias/add|formulario de incidencias]]. Los usuarios que no tengan permiso de acceso recibirán un mensaje de "contraseña incorrecta".
  
-El acceso se hace a través de una máquina que actúa como //frontend// a través de //ssh//Para más información, consulta [[ es:centro:servizos:hpc:acceso_al_cluster | cómo acceder al cluster y copiar ficheros]]. +El acceso se realiza mediante una conexión SSH al nodo de login: 
 +<code bash> 
 +ssh <nombre_de_usuario>@hpc-login2.inv.usc.es 
 +</code>
  
-Antes de acceder por primera vezlee atentamente la sección de introducción que sigue para entender cómo funciona el sistema. También encontrarás información que te servirá de referencia más adelante.+=====  Almacenamiento, directorios y sistemas de ficheros  ===== 
 +<note warning> No se hace copia de seguridad de ninguno de los sistemas de ficheros del cluster!!</note> 
 +El HOME de los usuarios en el cluster está en el sistema compartido de ficheros, por lo que es accesible desde todos los nodos del cluster. Ruta definida en la variable de entorno %%$HOME%%. \\ 
 +Cada nodo tiene una partición local de 1 TB para scratch, que se borra al terminar cada trabajo. Se puede acceder mediante la variable de entorno %%$LOCAL_SCRATCH%% en los scripts. \\ 
 +Para datos que deban ser compartidos por grupos de usuarioshay que solicitar la creación de una carpeta en el almacenamiento compartido que solo será accesible por los miembros del grupo.\\ 
 +^  Directorio        ^  Variable                Punto de montaje              Capacidad 
 +|  Home              |  %%$HOME%%              |  /mnt/beegfs/home/<username>  |  220 TB*    | 
 +|  Scratch local      %%$LOCAL_SCRATCH%%      varía                        |  1 TB       | 
 +|  Carpeta de grupo  |  %% $GRUPOS/<nombre>%%  |  /mnt/beegfs/groups/<nombre>  |  220 TB*    | 
 +%%* el almacenamiento es compartido%% 
 +=== AVISO IMPORTANTE === 
 +El sistema compartido de archivos tiene un mal rendimiento cuando trabaja con muchos archivos de tamaño pequeñoPara mejorar el rendimiento en ese tipo de escenarios hay que crear un sistema de archivos en un fichero de imagen y montarlo para trabajar directamente sobre él. El procedimiento es el siguiente: 
 +  * Crear el fichero de imagen en tu home: 
 +<code bash> 
 +## truncate image.name -s SIZE_IN_BYTES 
 +truncate ejemplo.ext4 -s 20G 
 +</code> 
 +  *  Crear un sistema de archivos en el fichero de imagen: 
 +<code bash> 
 +## mkfs.ext4 -T small -m 0 image.name 
 +## -T small opciones optimizadas para archivos pequeños 
 +## -m 0 No reservar espacio para root  
 +mkfs.ext4 -T small -m 0 ejemplo.ext4 
 +</code> 
 +  * Montar la imagen (usando SUDO) con el script  //mount_image.py//
 +<code bash> 
 +## Por defecto queda montada en /mnt/imagenes/<username>/ en modo solo lectura. 
 +sudo mount_image.py ejemplo.ext4 
 +</code> 
 +  * Para desmontar la imagen usar el script //umount_image.py// (usando SUDO)
  
-===== Introducción =====+El script de montaje tiene estas opciones: 
 +<code> 
 +--mount-point path   <-- (opcional)Con esta opción crea subdirectorios por debajo de /mnt/imagenes/<username>/<path> 
 +--rw                  <-- (opcional)Por defecto se monta readonly, con esta opción se monta readwrite. 
 +</code> 
 +El script de desmontaje tiene estas opciones: 
 +<code>solo admite como parámetro opcional el mismo path que hayas usado para el montaje con la opción  
 +--mount-point  <-- (opcional) 
 +</code> 
 +=====  Transferencia de ficheros y datos  ===== 
 +=== SCP === 
 +Desde tu máquina local al cluster: 
 +<code bash> 
 +scp filename <username>@hpc-login2:/<ruta> 
 +</code> 
 +Desde el cluster a tu máquina local: 
 +<code bash> 
 +scp filename <username>@<hostname>:/<ruta> 
 +</code> 
 +[[https://man7.org/linux/man-pages/man1/scp.1.html | Página del manual de SCP]] 
 +=== SFTP === 
 +Para transferir múltiples archivos o para navegar por el sistema de archivos. 
 +<code bash> 
 +<hostname>:~$ sftp <user_name>@hpc-login2 
 +sftp> 
 +sftp> ls 
 +sftp> cd <path> 
 +sftp> put <file> 
 +sftp> get <file> 
 +sftp> quit 
 +</code> 
 +[[https://www.unix.com/man-page/redhat/1/sftp/ | Página del manual de SFTP]] 
 +=== RSYNC === 
 +[[ https://rsync.samba.org/documentation.html | Documentación de RSYNC ]] 
 +=== SSHFS === 
 +Requiere la instalación del paquete sshfs.\\ 
 +Permite por ejemplo montar el home del equipo del usuario en hpc-login2: 
 +<code bash> 
 +## Montar 
 +sshfs  <username>@ctdeskxxx.inv.usc.es:/home/<username> <punto_de_montaje> 
 +## Desmontar 
 +fusermount -u <punto_de_montaje> 
 +</code> 
 +[[https://linux.die.net/man/1/sshfs | Página del manual de SSHFS]]
  
-==== Funcionamiento básico de un clúster de computación ====+===== Software disponible ===== 
 +Todos los nodos tienen el software básico que se instala por defecto con AlmaLinux 8.4, particularmente: 
 +  * GCC 8.5.0 
 +  * Python 3.6.8 
 +  * Perl 5.26.3 
 +En los nodos con GPU, además: 
 +  * nVidia Driver 510.47.03 
 +  * CUDA 11.6 
 +  * libcudnn 8.7
  
-El Cluster de Computación de Altas Prestaciones (HPC, //High Performance Computing//) proporciona a los investigadores una una infraestructura compartida que sirve como plataforma adecuada a la ejecución de procesos computacionalmente costosos.+Para usar cualquier otro software no instalado en el sistema u otra versión del mismo hay tres opciones: 
 +  - Usar Modules con los módulos que ya están instalados (o solicitar la instalación de un nuevo módulo si no está disponible) 
 +  - Usar un contenedor (uDocker o Apptainer/Singularity) 
 +  - Usar Conda 
 +Un módulo es la solución más sencilla para usar software sin modificaciones o dependencias difíciles de satisfacer.\\ 
 +Un contenedor es ideal cuando las dependencias son complicadas y/o el software está muy personalizado. También es la mejor solución si lo que se busca es reproducibilidad, facilidad para su distribución y trabajo en equipo.\\ 
 +Conda es la mejor solución si lo que se necesita es la última versión de una librería o programa o paquetes no disponibles de otra forma.\\
  
-Un **cluster de computación** se compone de un conjunto de nodos interconectados mediante una red dedicada que puede actuar como un único elemento computacional. Esto proporciona una gran potencia, permitiendo la ejecución de trabajos paralelos muy grandes o muchas ejecuciones pequeñas de forma concurrente. 
  
-Un **sistema de gestión de colas** (//SGC//) es un software que planifica la ejecución de los trabajos que se encuentra habitualmente en los sistemas de este tipo, ya que permite una gestión eficiente de los recursos con múltiples usuarios. En este clúster está instalado el sistema **PBS/TORQUE**.+==== Uso de modules/Lmod ==== 
 +[[ https://lmod.readthedocs.io/en/latest/010_user.html | Documentación de Lmod ]] 
 +<code bash> 
 +# Ver los módulos disponibles: 
 +module avail 
 +# Cargar un módulo: 
 +module <nombre_modulo> 
 +# Descargar un módulo: 
 +module unload <nombre_modulo> 
 +# Ver módulos cargados en tu entorno: 
 +module list 
 +# Puede usarse ml como abreviatura del comando module: 
 +ml avail 
 +# Para obtener información sobre un módulo: 
 +ml spider <nombre_modulo> 
 +</code>
  
-La dinámica de funcionamiento de un sistema de este tipo es la siguiente: 
-        - El usuario solicita la ejecución de una tarea((Normalmente un script de //bash//)) con unos recursos determinados. 
-        - El sistema registra la solicitud en una de sus colas de entrada((Típicamente //batch//)) y, según la cantidad de recursos solicitados, la deriva a una cola de sistema determinada ((Llamadas //np1//, //np2//, //np4//...)). 
-        - En función de la prioridad de la cola de sistema (a menores recursos necesarios, mayor prioridad) y de la disponibilidad de los recursos en el sistema, la tarea se enviará a uno o varios de los nodos computacionales. Al terminar la ejecución, se devolverá la salida generada. 
  
-Lo habitual es que la ejecución tenga que **esperar en la cola** hasta que los recursos estén disponibles y preparados. Además, resulta imposible realizar así ejecuciones de manera interactiva((Sin embargo, existe una cola interactiva especial para ejecuciones interactivas, orientada a solucionar problemas en las ejecuciones)). 
  
-==== Descripción del hardware ==== +==== Ejecución de contenedores de software ==== 
-El clúster **ctcomp2** es un clúster heterogéneo, formado por 8 nodos computacionales //HP Proliant BL685c G7//, 5 nodos //Dell PowerEdge M910// y 5 nodos //Dell PowerEdge M620//.+=== uDocker ==== 
 +[[ https://indigo-dc.gitbook.io/udocker/user_manual | Manual de uDocker]] \\ 
 +udocker está instalado como un móduloasí que es necesario cargarlo en el entorno: 
 +<code bash> 
 +ml uDocker 
 +</code>
  
-^ Nombre del nodo ^ Modelo ^ Núcleos por nodo (NUMAs, Sockets, Cores/socket, Threads/core) ^ Memoria RAM ^ +=== Apptainer/Singularity === 
-| node1-7 | HP Proliant BL685c G7 | 64 (8, 4, 8, 2) | 128GB | +[[ https://sylabs.io/guides/3.8/user-guide/ Documentacion de Apptainer/Singularity ]] \\ 
-| inode11-15 | Dell PowerEdge M910 | 64 (4, 4, 8, 1) | 64GB +Apptainer/Singularity está instalado en el sistema de cada nodopor lo que no es necesario hacer nada para usarlo.
-| inode16-20 | Dell PowerEdge M620 | 32 (22, 8, 2) | 64GB |+
  
-Internamente los nodos computacionales están conectados entre sí a través de varias redes 10 GbE dedicadas. La conexión desde el exterior es de 1Gb. 
  
-Casi todos los nodos, a excepción de //node1// e //inode20// se apagan cuando no se están utilizando durante un rato, lo que podría causar retrasos de varios minutos en la cola aunque el cluster aparentemente esté desocupado.+==== CONDA ==== 
 +[[ https://docs.conda.io/en/latest/miniconda.html | Documentacion de Conda ]] \\ 
 +Miniconda es la versíon mínima de Anaconda y solo incluye el gestor de entornos conda, Python y unos pocos paquetes necesarios. A partir de ahí cada usuario solo descarga instala los paquetes que necesita. 
 +<code bash> 
 +# Obtener miniconda 
 +wget https://repo.anaconda.com/miniconda/Miniconda3-py39_4.11.0-Linux-x86_64.sh 
 +# Instalarlo  
 +sh Miniconda3-py39_4.11.0-Linux-x86_64.sh 
 +# Inicializar miniconda para el shell bash 
 +~/miniconda3/bin/conda init bash 
 +</code>
  
-[[  es:centro:servizos:hpc:referencia_bios|Información técnica de los procesadores y opciones de BIOS]] +===== Uso de SLURM ===== 
-==== Descripción del software ==== +El gestor de colas en el cluster es [[ https://slurm.schedmd.com/documentation.html | SLURM ]]. \\ 
-El sistema operativo es //Debian GNU/Linux 8.6 (jessie)//+<note tip>El término CPU identifica a un core físico de un socket. El hyperthreading está desactivado, por lo que cada nodo tiene disponibles tantas CPU como (nº sockets) * (nº cores físico por socket) tenga.</note> 
 +== Recursos disponibles == 
 +<code bash> 
 +hpc-login2 ~]# ver_estado.sh 
 +============================================================================================================= 
 +  NODO     ESTADO                        CORES EN USO                           USO MEM     GPUS(Uso/Total) 
 +============================================================================================================= 
 + hpc-fat1    up   0%[--------------------------------------------------]( 0/80) RAM 0%     --- 
 + hpc-gpu1    up   2%[||------------------------------------------------]( 1/36) RAM47%   V100S (1/2) 
 + hpc-gpu2    up   2%[||------------------------------------------------]( 1/36) RAM47%   V100S (1/2) 
 + hpc-gpu3    up   0%[--------------------------------------------------]( 0/64) RAM 0%   A100_40 (0/2) 
 + hpc-gpu4    up   1%[|-------------------------------------------------]( 1/64) RAM: 35%   A100_80 (1/1) 
 + hpc-node1   up   0%[--------------------------------------------------]( 0/36) RAM:  0%     --- 
 + hpc-node2   up   0%[--------------------------------------------------]( 0/36) RAM:  0%     --- 
 + hpc-node3   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node4   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node5   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node6   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node7   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node8   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 + hpc-node9   up   0%[--------------------------------------------------]( 0/48) RAM:  0%     --- 
 +============================================================================================================= 
 +TOTALES: [Cores : 3/688] [Mem(MB): 270000/3598464] [GPU: 37]
  
-El sistema de colas que gestiona los trabajos es PBS/Torque, apoyado por CLUES para mejorar la gestión de energía.+hpc-login2 ~]$ sinfo -e -o "%30N  %20c  %20m  %20f  %30G " --sort=N 
 +# Hay un alias para este comando: 
 +hpc-login2 ~]$ ver_recursos 
 +NODELIST                        CPUS                  MEMORY                AVAIL_FEATURES        GRES                            
 +hpc-fat1                        80                    1027273               cpu_intel             (null)                          
 +hpc-gpu[1-2]                    36                    187911                cpu_intel             gpu:V100S:                    
 +hpc-gpu3                        64                    253282                cpu_amd               gpu:A100_40:                  
 +hpc-gpu4                        64                    253282                cpu_amd               gpu:A100_80:1(S:0)              
 +hpc-node[1-2]                   36                    187645                cpu_intel             (null)                          
 +hpc-node[3-9]                   48                    187645                cpu_intel             (null)
  
-  * [[http://docs.adaptivecomputing.com/maui/index.php|MAUI 3.3.1]] +# Para ver el uso actual de los recursos(CPUS (Allocated/Idle/Other/Total)) 
-  * [[http://docs.adaptivecomputing.com/torque/4-1-7/help.htm|Torque 4.1.3]+hpc-login2 ~]$ sinfo -N -r -O NodeList,CPUsState,Memory,FreeMem,Gres,GresUsed 
-  * [[http://www.grycap.upv.es/clues/eng/index.php|CLUES 0.88]]+# Hay un alias para este comando: 
 +hpc-login2 ~]$ ver_uso 
 +NODELIST            CPUS(A/I/O/T)       MEMORY              FREE_MEM            GRES                GRES_USED 
 +hpc-fat1            80/0/0/80           1027273             900850              (null)              gpu:0,mps:
 +hpc-gpu3            2/62/0/64           253282              226026              gpu:A100_40:      gpu:A100_40:2(IDX:0- 
 +hpc-gpu4            1/63/0/64           253282              244994              gpu:A100_80:1(S:0)  gpu:A100_80:1(IDX:0) 
 +hpc-node1           36/0/0/36           187645              121401              (null)              gpu:0,mps:
 +hpc-node2           36/0/0/36           187645              130012              (null)              gpu:0,mps:
 +hpc-node3           36/12/0/48          187645              126739              (null)              gpu:0,mps:
 +hpc-node4           36/12/0/48          187645              126959              (null)              gpu:0,mps:
 +hpc-node5           36/12/0/48          187645              128572              (null)              gpu:0,mps:
 +hpc-node6           36/12/0/48          187645              127699              (null)              gpu:0,mps:
 +hpc-node7           36/12/0/48          187645              127002              (null)              gpu:0,mps:
 +hpc-node8           36/12/0/48          187645              128182              (null)              gpu:0,mps:
 +hpc-node9           36/12/0/48          187645              127312              (null)              gpu:0,mps:
 +</code> 
 +==== Nodos ==== 
 +Un nodo es la unidad de computación de SLURM, y se corresponde con un servidor físico. 
 +<code bash> 
 +# Mostrar la información de un nodo: 
 +hpc-login2 ~]$ scontrol show node hpc-node1 
 +NodeName=hpc-node1 Arch=x86_64 CoresPerSocket=18  
 +   CPUAlloc=0 CPUTot=36 CPULoad=0.00 
 +   AvailableFeatures=cpu_intel 
 +   ActiveFeatures=cpu_intel 
 +   Gres=(null) 
 +   NodeAddr=hpc-node1 NodeHostName=hpc-node1 Version=21.08.6 
 +   OS=Linux 4.18.0-305.el8.x86_64 #SMP Wed May 19 18:55:28 EDT 2021  
 +   RealMemory=187645 AllocMem=0 FreeMem=166801 Sockets=2 Boards=1 
 +   State=IDLE ThreadsPerCore=1 TmpDisk=0 Weight=1 Owner=N/A MCS_label=N/
 +   Partitions=defaultPartition  
 +   BootTime=2022-03-01T13:13:56 SlurmdStartTime=2022-03-01T15:36:48 
 +   LastBusyTime=2022-03-07T14:34:12 
 +   CfgTRES=cpu=36,mem=187645M,billing=36 
 +   AllocTRES= 
 +   CapWatts=n/
 +   CurrentWatts=0 AveWatts=0 
 +   ExtSensorsJoules=n/s ExtSensorsWatts=0 ExtSensorsTemp=n/
 +</code> 
 +==== Particiones ==== 
 +Las particiones en SLURM son grupos lógicos de nodosEn el cluster hay una única partición a la que pertenecen todos los nodos, por lo que no es necesario especificarla a la hora de enviar trabajos. 
 +<code bash> 
 +# Mostrar la información de las particiones: 
 +hpc-login2 ~]$ sinfo 
 +defaultPartition   up   infinite     11   idle hpc-fat1,hpc-gpu[3-4],hpc-node[1-9] 
 +# Cuando se incorporen al cluster ctgpgpu7 y 8 apareceran como los nodos hpc-gpu1 y 2 respectivamente. 
 +</code> 
 +==== Trabajos ==== 
 +Los trabajos en SLURM son asignaciones de recursos a un usuario durante un tiempo determinadoLos trabajos se identifican por un número correlativo o JOBID\\ 
 +Un trabajo (JOB) consiste en uno o más pasos (STEPS), cada uno consistente en una o más tareas (TASKS) que usan una o más CPUHay un STEP por cada programa que se ejecute de forma secuencial en un JOB y hay un TASK por cada programa que se ejecute en paraleloPor lo tanto en el caso más simple como por ejemplo lanzar un trabajo consistente en ejecutar el comando hostname el JOB tiene un único STEP y una única TASK.
  
-El sistema permite compilar ejecutar código en C++JavaPythonROctave... Puedes consultar el catálogo completo de software disponible en el siguiente enlace[[es:centro:servizos:hpc:referencia_software | Información del software disponible]] +==== Sistema de colas (QOS) ==== 
-===== Sistema de colas =====+La cola a la que se envíe cada trabajo define la prioridad,los límites también el "coste" relativo para el usuario. 
 +<code bash> 
 +# Mostrar las colas 
 +hpc-login2 ~]$ sacctmgr show qos 
 +# Hay un alias que muestra solo la información más relevante: 
 +hpc-login2 ~]$ ver_colas 
 +      Name    Priority                                  MaxTRES     MaxWall            MaxTRESPU MaxJobsPU MaxSubmitPU  
 +----------  ---------- ---------------------------------------- ----------- -------------------- --------- -----------  
 +   regular         100                cpu=200,gres/gpu=1,node=4  4-04:00:00       cpu=200,node=4        10          50  
 +interactive        200                                   node=1    04:00:00               node=1                   1  
 +    urgent         300                        gres/gpu=1,node=1    04:00:00               cpu=36                  15  
 +      long         100                        gres/gpu=1,node=4  8-04:00:00                              1           5  
 +     large         100                       cpu=200,gres/gpu=2  4-04:00:00                              2          10  
 +     admin         500                                                                                                  
 +     small         150                             cpu=6,node=2    04:00:00              cpu=400        40         100  
 +</code> 
 +# Priority: es la prioridad relativa de cada cola\\ 
 +# DenyonLimit: el trabajo no se ejecuta si no cumple los límites de la cola \\ 
 +# UsageFactor: el coste relativo para el usuario de ejecutar un trabajo en esa cola \\ 
 +# MaxTRESlímites por cada trabajo \\ 
 +# MaxWalltiempo máximo que puede estar el trabajo en ejecución \\ 
 +# MaxTRESPUlímites globales por usuario \\ 
 +# MaxJobsPUNúmero máximo de trabajos que un usuario puede tener en ejecución. \\ 
 +# MaxSubmitPUNúmero máximo de trabajos que un usuario puede tener en total encolados y en ejecucuón.\\ 
 +  
 +==== Envío de un trabajo al sistema de colas ==== 
 +== Especificación de recursos == 
 +Por defecto, si se envía un trabajo sin especificar nada el sistema lo envía a la QOS por defecto (regular) y le asigna un nodo, una CPU y 4GB de RAM. El límite de tiempo para la ejecución del trabajo es el de la cola (4 días y 4 horas).  
 +Esto es muy ineficiente, lo ideal es especificar en la medida de lo posible al menos tres parámetros a la hora de enviar los trabajos: 
 +  -  %%El número de nodos (-N o --nodes), tareas (-n o --ntasks) y/o CPU por tarea (-c o --cpus-per-task).%% 
 +  -  %%La memoria (--mem) por nodo o la memoria por cpu (--mem-per-cpu).%% 
 +  -  %%El tiempo estimado de ejecución del trabajo ( --time )%%
  
-El sistema de colas tiene cuatro **colas de entrada** y ocho **colas del sistema**Un usuario envía un trabajo a una cola de entrada y, en función de los recursos solicitados, se envían a una u otra cola de sistema.+A mayores puede ser interesante añadir los siguientes parámetros: 
 +|  -J    %%--job-name%%  |Nombre para el trabajoPor defecto: nombre del ejecutable 
 +|  -q    %%--qos%%       |Nombre de la cola a la que se envía el trabajo. Por defecto: regular 
 +|  -o    %%--output%%    |Fichero o patrón de fichero al que se redirige toda la salida estandar y de error. 
 +|        %%--gres%%      |Tipo y/o número de GPUs que se solicitan para el trabajo | 
 +|  -C    %%--constraint%%  |Para especificar que se quieren nodos con procesadores Intel o AMD (cpu_intel o cpu_amd) 
 +|    |  %%--exclusive%%  |Para solicitar que el trabajo no comparta nodos con otros trabajos. 
 +|  -w  |  %%--nodelist%%   |Lista de nodos en los que ejecutar el trabajo  |
  
-Para enviar un trabajo al sistema de colas, se utiliza el comando ''qsub''Por defecto se envía a la cola de entrada //batch//Si el clúster se encuentra muy saturado, puede ser interesante especificar la cola //short// o //bigmem//.+== Cómo se asignan los recursos == 
 +Por defecto el método de asignación entre nodos es la asignación en bloque ( se asignan todos los cores disponibles en un nodo antes de usar otro)El método de asignación por defecto dentro de cada nodo es la asignación cíclica  (se van repartiendo por igual los cores requeridos entre los sockets disponibles en el nodo)
  
-^ Cola ^ Número máximo de trabajos encolados((Solo cuentan los trabajos que no han sido aún enviados a una cola del sistema, así que esto no quiere decir que solo puedas enviar ese número de trabajos)) ^ Características ^ Ejemplo ^ +== Calculo de la prioridad == 
-| ''batch'' | 256 | Es la cola por defecto| ''qsub trabajo.sh'' +Cuando se envía un trabajo al sistema de colaslo primero que ocurre es que se comprueba si los recursos solicitados entran dentro de los límites fijados en la cola correspondienteSi supera alguno se cancela el envío\\ 
-| ''short'' | 256 | Cola especial con mayor prioridad para trabajos de como máximo 12 horas, 16 procesos, 5 nodos y 32GB | ''qsub -q short trabajo.sh''+Si hay recursos disponibles el trabajo se ejecuta directamente, pero si no es así se encola. Cada trabajo tiene asignada una prioridad que determina el orden en que se ejecutan los trabajos de la cola cuando quedan recursos disponibles. Para determinar la prioridad de cada trabajo se ponderan 3 factores: el tiempo que lleva esperando en la cola (25%)la prioridad fija que tiene la cola(25%) el fairshare del usuario (50%). \\ 
-| ''bigmem'' | 8 | Otra cola especial con mayor prioridad para trabajos de, específicamente, 64 procesos un nodo. Es obligatorio especificar esos recursos (''nodes=1:ppn=64''). | ''qsub -q bignmem -l nodes=1:ppn=64 trabajo.sh'' | +El fairshare es un cálculo dinámico que hace SLURM para cada usuario y es la diferencia entre los recursos asignados y los recursos consumidos a lo largo de los últimos 14 días.  
-| ''interactive''| Cola especial para trabajar de forma interactivaDebe llamarse de forma especial| ''qsub -q interactive -I'' |+<code bash> 
 +hpc-login2 ~]$ sshare -l  
 +      User  RawShares  NormShares    RawUsage   NormUsage   FairShare  
 +---------- ---------- ----------- ----------- -----------  ----------  
 +                         1.000000     2872400                0.500000  
 +                       0.500000     2872400    1.000000    0.250000  
 +user_name         100    0.071429        4833    0.001726    0.246436 
 +</code> 
 +# RawShares: es la cantidad de recursos en términos absolutos asignada al usuario. Es igual para todos los usuarios.\\ 
 +# NormShares: Es la cantidad anterior normalizada a los recursos asignados en total.\\ 
 +# RawUsage: Es la cantidad de segundos/cpu consumida por todos los trabajos del usuario.\\ 
 +# NormUsage: Cantidad anterior normalizada al total de segundos/cpu consumidos en el cluster.\\ 
 +# FairShare: El factor FairShare entre 0 y 1. Cuanto mayor uso del cluster, más se aproximará a 0 y menor será la prioridad.\\
  
-Los recursos que se pueden solicitar y que determinarán la cola del sistema utilizada son:+== Envío de trabajos == 
 +  - sbatch 
 +  - salloc 
 +  - srun
  
-  * El número de nodos 
-  * El número de núcleos por nodo 
-  * El tiempo de ejecución 
  
-La memoria máxima asignada depende de la cola del sistema que se utilice finalmente, así que estará determinada por el resto de parámetros.+1. SBATCH \\ 
 +Sirve para enviar un script al sistema de colas. Es de procesamiento por lotes y no bloqueante. 
 +<code bash> 
 +# Crear el script: 
 +hpc-login2 ~]$ vim trabajo_ejemplo.sh 
 +    #!/bin/bash 
 +    #SBATCH --job-name=prueba            # Job name 
 +    #SBATCH --nodes=1                    # -N Run all processes on a single node    
 +    #SBATCH --ntasks=1                   # -n Run a single task    
 +    #SBATCH --cpus-per-task=1            # -c Run 1 processor per task        
 +    #SBATCH --mem=1gb                    # Job memory request 
 +    #SBATCH --time=00:05:00              # Time limit hrs:min:sec 
 +    #SBATCH --qos=urgent                 # Cola 
 +    #SBATCH --output=prueba_%j.log       # Standard output and error log
  
-Los recursos pueden solicitarse de dos formas: como comentarios al inicio del script, o con el parámetro ''-l'' (que tiene precedencia). Puedes ver [[:es:centro:servizos:hpc:escribir_script:ejemplos|ejemplos de trabajos]] para ver cómo se especifican estos recursos.+    echo "Hello World!"
  
-Comprueba los límites existentes en las colas del sistema, para determinar la mejor elección de recursos posible:+hpc-login2 ~]$ sbatch trabajo_ejemplo.sh  
 +</code> 
 +2. SALLOC \\ 
 +Sirve para obtener de forma inmediata una asignación de recursos (nodos). En cuanto se obtiene se ejecuta el comando especificado o una shell en su defecto.  
 +<code bash> 
 +# Obtener 5 nodos y lanzar un trabajo. 
 +hpc-login2 ~]$ salloc -N5 myprogram 
 +# Obtener acceso interactivo a un nodo (Pulsar Ctrl+D para terminar el acceso): 
 +hpc-login2 ~]$ salloc -N1  
 +# Obtener acceso interactivo a un nodo de forma EXCLUSIVA 
 +hpc-login2 ~]$ salloc -N1 --exclusive 
 +</code> 
 +3. SRUN \\ 
 +Sirve para lanzar un trabajo paralelo ( es preferible a usar mpirun ). Es interactivo y bloqueante. 
 +<code bash> 
 +# Lanzar un hostname en 2 nodos 
 +hpc-login2 ~]$ srun -N2 hostname 
 +hpc-node1 
 +hpc-node2 
 +</code>
  
-^              ^  Límites                                                                                                                  |||||| 
-^ Cola              ^ Núcleos((parámetro ''ppn'')) ^ Nodos((parámetro ''nodes''))  ^ Memoria (GB)((Determinada por el resto de parámetros))  ^ Trabajos/usuario((Si se alcanza este número de trabajos, los trabajos restantes permanecerán en la cola de entrada mientras no se liberen trabajos en la cola de sistema))  ^ Tiempo máximo (horas)  ^ Prioridad((Mayor número = mayor prioridad))  ^ 
-| ''np1''          | 1         | 1      | 1,99          | 300               | 672                    | 6                                            | 
-| ''np2''          | 2         | 2      | 3,75          | 150               | 192                    | 5                                            | 
-| ''np4''          | 4         | 4      | 7,5           | 75                | 192                    | 4                                            | 
-| ''np8''          | 8         | 5      | 15            | 40                | 192                    | 4                                            | 
-| ''np16''         | 16        | 5      | 31            | 20                | 192                    | 3                                            | 
-| ''np32''         | 32        | 5      | 63            | 10                | 288                    | 2                                            | 
-| ''np64''         | 64        | 5      | 127           | 5                 | 384                    | 1                                            | 
-| ''parallel''     | 32-160    | 5      | 64            | 15                | 192                    | 3                                            | 
  
-Puedes leer más sobre [[es:centro:servizos:hpc:escribir_script |cómo preparar los trabajos para su envío al gestor de colas]] y cómo [[ es:centro:servizos:hpc:envio_trabajo|enviar y gestionar trabajos una vez enviados]].+==== Uso de los nodos con GPU ==== 
 +Para solicitar específicamente una asignación de GPUs para un trabajo hay que añadir a sbatch o srun las opciones:  
 +|  %%--gres%%  |  Solicitud de gpus por NODE  |  %%--gres=gpu[[:type]:count],...%% 
 +|  %%--gpus o -G%%  |  Solicitud de gpus por JOB  |  %%--gpus=[type]:count,...%% 
 +También existen las opciones %% --gpus-per-socket,--gpus-per-node y --gpus-per-task%%,\\ 
 +Ejemplos: 
 +<code bash> 
 +## Ver la lista de nodos y gpus: 
 +hpc-login2 ~]$ ver_recursos 
 +## Solicitar 2 GPU cualesquiera para un JOB, añadir: 
 +--gpus=2 
 +## Solicitar una A100 de 40G en un nodo y una A100 de 80G en otro, añadir: 
 +--gres=gpu:A100_40:1,gpu:A100_80:1  
 +</code> 
 + 
 + 
 +==== Monitorización de los trabajos ==== 
 +<code bash> 
 +## Listado de todos los trabajos en la cola 
 +hpc-login2 ~]$ squeue 
 +## Listado de los trabajos de un usuario             
 +hpc-login2 ~]$ squeue -u <login> 
 +## Cancelar un trabajo: 
 +hpc-login2 ~]$ scancel <JOBID> 
 +## Lista de trabajos recientes 
 +hpc-login2 ~]$ sacct -b 
 +## Información histórica detallada de un trabajo: 
 +hpc-login2 ~]$ sacct -l -j <JOBID> 
 +## Información de debug de un trabajo para troubleshooting: 
 +hpc-login2 ~]$ scontrol show jobid -dd <JOBID> 
 +## Ver el uso de recursos de un trabajo en ejecución: 
 +hpc-login2 ~]$ sstat <JOBID> 
 +</code> 
 +==== Controlar la salida de los trabajos ==== 
 +== Códigos de salida == 
 +Por defecto estos son los códigos de salida de los comandos: 
 +^  SLURM command  ^  Exit code  ^ 
 +|  salloc  |  0 en caso de éxito, 1 si no se puedo ejecutar el comando del usuario 
 +|  srun  |  El más alto de entre todas las tareas ejecutadas o 253 para un error out-of-mem 
 +|  sbatch  |  0 en caso de éxito, si no, el código de salida correspondiente del proceso que falló 
 + 
 +== STDIN, STDOUT y STDERR == 
 +**SRUN:**\\ 
 +Por defecto stdout y stderr se redirigen de todos los TASKS a el stdout y stderr de srun, y stdin se redirecciona desde el stdin de srun a todas las TASKS. Esto se puede cambiar con: 
 +|  %%-i, --input=<opcion>%%    |  
 +|  %%-o, --output=<opcion>%%   | 
 +|  %%-e, --error=<opcion>%%   | 
 +Y las opciones son: 
 +  * //all//: opción por defecto. 
 +  * //none//: No se redirecciona nada. 
 +  * //taskid//: Solo se redirecciona desde y/o al TASK id especificado. 
 +  * //filename//: Se redirecciona todo desde y/o al fichero especificado. 
 +  * //filename pattern//: Igual que filename pero con un fichero definido por un [[ https://slurm.schedmd.com/srun.html#OPT_filename-pattern | patrón ]
 + 
 +**SBATCH:**\\ 
 +Por defecto "/dev/null" está abierto en el stdin del script stdout y stderror se redirigen a un fichero de nombre "slurm-%j.out". Esto se puede cambiar con: 
 +|  %%-i, --input=<filename_pattern>%% 
 +|  %%-o, --output=<filename_pattern>%% 
 +|  %%-e, --error=<filename_pattern>%% 
 +La referencia de filename_pattern está [[ https://slurm.schedmd.com/sbatch.html#SECTION_%3CB%3Efilename-pattern%3C/B%3E | aquí ]]. 
 + 
 +==== Envío de correos ==== 
 +Se pueden configurar los JOBS para que envíen correos en determinadas circunstancias usando estos dos parámetros (**SON NECESARIOS AMBOS**): 
 +|  %%--mail-type=<type>%%  |  OpcionesBEGIN, END, FAIL, REQUEUE, ALL, TIME_LIMIT, TIME_LIMIT_90, TIME_LIMIT_50. 
 +|  %%--mail-user=<user>%%  |  La dirección de correo de destino. 
 + 
 + 
 + 
 +==== Estados de los trabajos en el sistema de colas ==== 
 +<code bash> 
 +hpc-login2 ~]# squeue -l 
 +JOBID PARTITION     NAME     USER      STATE       TIME  NODES NODELIST(REASON) 
 +6547  defaultPa  example <username>  RUNNING   22:54:55      1 hpc-fat1 
 + 
 +## Ver estado de uso de las colas del cluster: 
 +hpc-login2 ~]$ estado_colas.sh 
 +JOBS PER USER: 
 +-------------- 
 +       usuario.uno: 
 +       usuario.dos: 
 + 
 +JOBS PER QOS: 
 +-------------- 
 +             regular: 
 +                long:  1 
 + 
 +JOBS PER STATE: 
 +-------------- 
 +             RUNNING: 
 +             PENDING: 
 +========================================== 
 +Total JOBS in cluster: 
 +</code> 
 +Estados (STATE) más comunes de un trabajo: 
 +  * R RUNNING Job currently has an allocation. 
 +  * CD COMPLETED Job has terminated all processes on all nodes with an exit code of zero.  
 +  * F FAILED Job terminated with non-zero exit code or other failure condition. 
 +  * PD PENDING Job is awaiting resource allocation. 
 +  
 +[[ https://slurm.schedmd.com/squeue.html#SECTION_JOB-STATE-CODES Lista completa de posibles estados de un trabajo ]].\\ 
 + 
 +Si un trabajo no está en ejecución aparecerá una razón debajo de REASON:[[ https://slurm.schedmd.com/squeue.html#SECTION_JOB-REASON-CODES | Lista de las razones ]] por las que un trabajo puede estar esperando su ejecución.