Diferencias
Muestra las diferencias entre dos versiones de la página.
Ambos lados, revisión anteriorRevisión previaPróxima revisión | Revisión previa | ||
es:centro:servizos:hpc [2017/06/16 12:24] – [Introducción] jorge.suarez | es: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 | + | ====== |
- | ===== Instrucciones rápidas de uso del cluster | + | [[ https:// |
- | ---------------- | + | ===== Descripción |
- | Un guión resumido del uso del cluster para la realización de un trabajo sería el siguiente: | + | |
- | - [[ es: | + | El clúster está compuesto en la parte de cómputo por: |
- | | + | * 9 servidores para cómputo general. |
- | - [[ es: | + | * 1 "fat node" para trabajos que requieran mucha memoria. |
+ | * 4 servidores para computo con GPU. | ||
+ | |||
+ | Los usuarios solo tienen acceso directo | ||
+ | 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 | ||
+ | | hpc-login2 | ||
+ | | hpc-node[1-2] | Dell R740 | ||
+ | | hpc-node[3-9] | ||
+ | | | ||
+ | | hpc-gpu[1-2] | ||
+ | | hpc-gpu3 | ||
+ | | hpc-gpu4 | ||
+ | ===== Conexión al sistema ===== | ||
+ | Para acceder al clúster, hay que solicitarlo previamente a través de [[https:// | ||
+ | El acceso se realiza mediante una conexión SSH al nodo de login: | ||
+ | <code bash> | ||
+ | ssh < | ||
+ | </ | ||
- | ===== Introducción | + | ===== |
- | ------------- | + | <note warning> No se hace copia de seguridad de ninguno de los sistemas de ficheros del cluster!!</ |
- | El Cluster de Computación de Altas Prestaciones | + | 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 usuarios, hay que solicitar la creación de una carpeta en el almacenamiento compartido que solo será accesible por los miembros del grupo.\\ | ||
+ | ^ Directorio | ||
+ | | Home | %%$HOME%% | ||
+ | | Scratch local | ||
+ | | Carpeta de grupo | %% $GRUPOS/< | ||
+ | %%* el almacenamiento es compartido%% | ||
+ | === AVISO IMPORTANTE === | ||
+ | El sistema compartido de archivos tiene un mal rendimiento cuando trabaja con muchos archivos de tamaño pequeño. Para 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 | ||
+ | truncate ejemplo.ext4 | ||
+ | </ | ||
+ | * Crear un sistema de archivos en el fichero de imagen: | ||
+ | <code bash> | ||
+ | ## mkfs.ext4 | ||
+ | ## -T small opciones optimizadas para archivos pequeños | ||
+ | ## -m 0 No reservar espacio para root | ||
+ | mkfs.ext4 | ||
+ | </ | ||
+ | * Montar la imagen | ||
+ | <code bash> | ||
+ | ## Por defecto queda montada en / | ||
+ | sudo mount_image.py ejemplo.ext4 | ||
+ | </ | ||
+ | * Para desmontar | ||
- | Un **cluster | + | El script |
+ | < | ||
+ | --mount-point path < | ||
+ | --rw <-- (opcional)Por defecto | ||
+ | </ | ||
+ | El script | ||
+ | < | ||
+ | --mount-point | ||
+ | </ | ||
+ | ===== Transferencia | ||
+ | === SCP === | ||
+ | Desde tu máquina local al cluster: | ||
+ | <code bash> | ||
+ | scp filename < | ||
+ | </ | ||
+ | Desde el cluster a tu máquina local: | ||
+ | <code bash> | ||
+ | scp filename < | ||
+ | </ | ||
+ | [[https:// | ||
+ | === SFTP === | ||
+ | Para transferir múltiples archivos | ||
+ | <code bash> | ||
+ | < | ||
+ | sftp> | ||
+ | sftp> ls | ||
+ | sftp> cd < | ||
+ | sftp> put < | ||
+ | sftp> get < | ||
+ | sftp> quit | ||
+ | </ | ||
+ | [[https:// | ||
+ | === RSYNC === | ||
+ | [[ https:// | ||
+ | === 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 < | ||
+ | ## Desmontar | ||
+ | fusermount -u < | ||
+ | </ | ||
+ | [[https:// | ||
- | Un **sistema de gestión de colas** (//SGC//) es un software | + | ===== Software disponible ===== |
+ | Todos los nodos tienen el software | ||
+ | | ||
+ | | ||
+ | | ||
+ | En los nodos con GPU, además: | ||
+ | * nVidia Driver 510.47.03 | ||
+ | * CUDA 11.6 | ||
+ | | ||
- | La dinámica de funcionamiento de un sistema | + | Para usar cualquier otro software no instalado en el sistema |
- | - El usuario solicita | + | - Usar Modules con los módulos que ya están instalados (o solicitar |
- | - El sistema registra la solicitud en una de sus colas de entrada((Típicamente //batch//)) y, según | + | - Usar un contenedor |
- | - En función de la prioridad de la cola de sistema (a menores recursos necesarios, mayor prioridad) | + | - Usar Conda |
+ | Un módulo es la solución más sencilla para usar software sin modificaciones o dependencias difíciles | ||
+ | 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 | ||
+ | Conda es la mejor solución si lo que se necesita es la última versión de una librería | ||
- | 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, | ||
- | ==== Descripción del hardware | + | ==== Uso de modules/ |
- | El clúster ctcomp2 es un clúster heterogéneo, | + | [[ https:// |
- | * inode1-7: Cada nodo HP Proliant dispone de 4 procesadores AMD Opteron 6262 HE (16 núcleos) y 256 GB de RAM(menos el nodo1 y el master que tienen 128GB). | + | <code bash> |
- | * node11-15: Cada nodo Dell PowerEdge M910 está equipado con 2 procesadores Intel Xeon L7555 (8 núcleos, 16 hilos) y 64 GB de RAM. | + | # Ver los módulos disponibles: |
- | * node16-20: Cada nodo Dell PowerEdge M620 está equipado con 2 procesadores Intel Xeon E5-2650L (8 núcleos, 16 hilos) y 64 GB de RAM. | + | module avail |
- | * La conexión con el cluster es de 1Gb, pero internamente los nodos computacionales están conectados entre sí a través de varias redes 10 GbE. | + | # Cargar |
+ | module < | ||
+ | # Descargar un módulo: | ||
+ | module unload < | ||
+ | # 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 < | ||
+ | </ | ||
- | [[ es: | ||
- | ==== Descripción del software ==== | ||
- | La gestión de los trabajos en el clúster se realiza a través del sistema de colas PBS/Torque. Para mejorar la eficiencia energética del cluster se utiliza un sistema de encendido y apagado de nodos bajo demanda llamado CLUES. | ||
- | * [[http:// | ||
- | * [[http:// | ||
- | * [[http:// | ||
- | En el siguiente enlace se encuentra la lista de servicios disponibles | + | ==== Ejecución de contenedores de software ==== |
+ | === uDocker ==== | ||
+ | [[ https:// | ||
+ | udocker está instalado como un módulo, así que es necesario cargarlo | ||
+ | <code bash> | ||
+ | ml uDocker | ||
+ | </ | ||
+ | === Apptainer/ | ||
+ | [[ https:// | ||
+ | Apptainer/ | ||
- | [[es: | ||
- | ===== Colas de usuario ===== | ||
- | ------------- | ||
- | El sistema PBS del clúster '' | + | ==== CONDA ==== |
+ | [[ https://docs.conda.io/en/ | ||
+ | Miniconda es la versíon mínima | ||
+ | <code bash> | ||
+ | # Obtener miniconda | ||
+ | wget https:// | ||
+ | # Instalarlo | ||
+ | sh Miniconda3-py39_4.11.0-Linux-x86_64.sh | ||
+ | # Inicializar miniconda para el shell bash | ||
+ | ~/ | ||
+ | </ | ||
- | Independientemente del tipo de cola que se utilice para el envío de trabajos, | + | ===== Uso de SLURM ===== |
- | los únicos parámetros que puede solicitar el usuario son el **número | + | El gestor |
+ | <note tip>El término CPU identifica a un core físico | ||
+ | == Recursos disponibles == | ||
+ | <code bash> | ||
+ | hpc-login2 ~]# ver_estado.sh | ||
+ | ============================================================================================================= | ||
+ | NODO | ||
+ | ============================================================================================================= | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | ============================================================================================================= | ||
+ | TOTALES: [Cores : 3/688] [Mem(MB): 270000/ | ||
+ | hpc-login2 ~]$ sinfo -e -o " | ||
+ | # Hay un alias para este comando: | ||
+ | hpc-login2 ~]$ ver_recursos | ||
+ | NODELIST | ||
+ | hpc-fat1 | ||
+ | hpc-gpu[1-2] | ||
+ | hpc-gpu3 | ||
+ | hpc-gpu4 | ||
+ | hpc-node[1-2] | ||
+ | hpc-node[3-9] | ||
- | Las colas de usuario son '' | + | # Para ver el uso actual |
- | | + | hpc-login2 ~]$ sinfo -N -r -O NodeList,CPUsState,Memory, |
+ | # Hay un alias para este comando: | ||
+ | hpc-login2 ~]$ ver_uso | ||
+ | NODELIST | ||
+ | hpc-fat1 | ||
+ | hpc-gpu3 | ||
+ | hpc-gpu4 | ||
+ | hpc-node1 | ||
+ | hpc-node2 | ||
+ | hpc-node3 | ||
+ | hpc-node4 | ||
+ | hpc-node5 | ||
+ | hpc-node6 | ||
+ | hpc-node7 | ||
+ | hpc-node8 | ||
+ | hpc-node9 | ||
+ | </ | ||
+ | ==== Nodos ==== | ||
+ | Un nodo es la unidad de computación de SLURM, y se corresponde con un servidor físico. | ||
+ | <code bash> | ||
+ | # Mostrar | ||
+ | hpc-login2 ~]$ scontrol show node hpc-node1 | ||
+ | NodeName=hpc-node1 Arch=x86_64 CoresPerSocket=18 | ||
+ | | ||
+ | | ||
+ | | ||
+ | Gres=(null) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | </ | ||
+ | ==== Particiones ==== | ||
+ | Las particiones en SLURM son grupos lógicos de nodos. En 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* | ||
+ | # Cuando | ||
+ | </ | ||
+ | ==== Trabajos ==== | ||
+ | Los trabajos | ||
+ | Un trabajo (JOB) consiste | ||
- | * '' | + | ==== Sistema |
- | < | + | La cola a la que se envíe cada trabajo define |
- | ct$ qsub -q short script.sh | + | <code bash> |
+ | # Mostrar | ||
+ | hpc-login2 ~]$ sacctmgr show qos | ||
+ | # Hay un alias que muestra solo la información más relevante: | ||
+ | hpc-login2 ~]$ ver_colas | ||
+ | Name Priority | ||
+ | ---------- | ||
+ | | ||
+ | interactive | ||
+ | urgent | ||
+ | long | ||
+ | | ||
+ | admin | ||
+ | small | ||
</ | </ | ||
- | * '' | + | # Priority: es la prioridad relativa de cada cola. \\ |
- | < | + | # DenyonLimit: |
- | ct$ qsub -q bigmem script.sh | + | # UsageFactor: |
+ | # MaxTRES: límites por cada trabajo \\ | ||
+ | # MaxWall: tiempo máximo que puede estar el trabajo en ejecución \\ | ||
+ | # MaxTRESPU: límites globales por usuario \\ | ||
+ | # MaxJobsPU: Número máximo de trabajos que un usuario puede tener en ejecución. \\ | ||
+ | # MaxSubmitPU: | ||
+ | |||
+ | ==== 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 | ||
+ | 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 )%% | ||
+ | |||
+ | A mayores puede ser interesante añadir los siguientes parámetros: | ||
+ | | -J | ||
+ | | -q | ||
+ | | -o | ||
+ | | | ||
+ | | -C | ||
+ | | | %%--exclusive%% | ||
+ | | -w | %%--nodelist%% | ||
+ | |||
+ | == 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 | ||
+ | |||
+ | == Calculo de la prioridad == | ||
+ | Cuando se envía un trabajo al sistema de colas, lo primero que ocurre es que se comprueba si los recursos solicitados entran dentro de los límites fijados en la cola correspondiente. Si supera alguno se cancela el envío. \\ | ||
+ | Si hay recursos disponibles el trabajo se ejecuta directamente, | ||
+ | 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. | ||
+ | < | ||
+ | hpc-login2 ~]$ sshare | ||
+ | User RawShares | ||
+ | ---------- ---------- ----------- ----------- ----------- | ||
+ | | ||
+ | 1 0.500000 | ||
+ | user_name | ||
</ | </ | ||
- | * '' | + | # RawShares: |
- | < | + | # NormShares: Es la cantidad anterior normalizada a los recursos asignados en total.\\ |
- | ct$ qsub -q interactive | + | # RawUsage: Es la cantidad de segundos/ |
+ | # NormUsage: Cantidad anterior normalizada al total de segundos/ | ||
+ | # FairShare: El factor FairShare entre 0 y 1. Cuanto mayor uso del cluster, más se aproximará | ||
+ | |||
+ | == Envío | ||
+ | - sbatch | ||
+ | - salloc | ||
+ | - srun | ||
+ | |||
+ | |||
+ | 1. SBATCH \\ | ||
+ | Sirve para enviar | ||
+ | <code bash> | ||
+ | # Crear el script: | ||
+ | hpc-login2 ~]$ vim trabajo_ejemplo.sh | ||
+ | #!/bin/bash | ||
+ | #SBATCH --job-name=prueba | ||
+ | #SBATCH --nodes=1 | ||
+ | #SBATCH --ntasks=1 | ||
+ | #SBATCH --cpus-per-task=1 | ||
+ | #SBATCH --mem=1gb | ||
+ | #SBATCH --time=00: | ||
+ | #SBATCH --qos=urgent | ||
+ | #SBATCH --output=prueba_%j.log | ||
+ | |||
+ | echo "Hello World!" | ||
+ | |||
+ | hpc-login2 ~]$ sbatch trabajo_ejemplo.sh | ||
+ | </ | ||
+ | 2. SALLOC \\ | ||
+ | Sirve para obtener | ||
+ | <code bash> | ||
+ | # Obtener 5 nodos y lanzar un trabajo. | ||
+ | hpc-login2 ~]$ salloc -N5 myprogram | ||
+ | # Obtener acceso interactivo | ||
+ | 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 | ||
</ | </ | ||
- | Las colas de sistema son '' | + | ==== Uso de los nodos con GPU ==== |
- | | + | Para solicitar específicamente una asignación de GPUs para un trabajo hay que añadir |
- | | + | | %%--gres%% |
- | * '' | + | | %%--gpus o -G%% | Solicitud |
- | | + | También existen las opciones %% --gpus-per-socket, |
- | * '' | + | 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: | ||
+ | </ | ||
+ | ==== 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 < | ||
+ | ## Cancelar un trabajo: | ||
+ | hpc-login2 ~]$ scancel < | ||
+ | ## Lista de trabajos recientes | ||
+ | hpc-login2 ~]$ sacct -b | ||
+ | ## Información histórica detallada de un trabajo: | ||
+ | hpc-login2 ~]$ sacct -l -j < | ||
+ | ## Información de debug de un trabajo para troubleshooting: | ||
+ | hpc-login2 ~]$ scontrol show jobid -dd < | ||
+ | ## Ver el uso de recursos de un trabajo en ejecución: | ||
+ | hpc-login2 ~]$ sstat < | ||
+ | </ | ||
+ | ==== Controlar la salida de los trabajos ==== | ||
+ | == Códigos de salida == | ||
+ | Por defecto estos son los códigos de salida de los comandos: | ||
+ | ^ SLURM command | ||
+ | | salloc | ||
+ | | srun | El más alto de entre todas las tareas ejecutadas o 253 para un error out-of-mem | ||
+ | | sbatch | ||
+ | == 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=< | ||
+ | | %%-o, --output=< | ||
+ | | %%-e, --error=< | ||
+ | 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 pattern//: Igual que filename pero con un fichero definido por un [[ https:// | ||
- | La siguiente tabla resume las características de las colas de usuario | + | **SBATCH: |
+ | Por defecto "/ | ||
+ | | %%-i, --input=< | ||
+ | | %%-o, --output=< | ||
+ | | %%-e, --error=< | ||
+ | La referencia de filename_pattern está [[ https:// | ||
- | ^ Cola | + | ==== Envío de correos ==== |
- | | ::: ^ Procesos | + | Se pueden configurar los JOBS para que envíen correos en determinadas circunstancias usando estos dos parámetros |
- | | '' | + | | %%--mail-type=< |
- | | '' | + | | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | | '' | + | |
- | * Procesos: Número máximo de procesos por trabajo en esta cola. | ||
- | * Nodos: Número máximo de nodos en los que se ejecutará el trabajo en esta cola. | ||
- | * Memoria: Cantidad de memoria virtual máxima usada de modo concurrente por todos los procesos del trabajo. | ||
- | * Trabajos/ | ||
- | * Tiempo máximo (horas): tiempo real máximo durante el que el trabajo puede estar en ejecución. | ||
- | * Prioridad: Prioridad de la cola de ejecución frente a las otras. Un valor más alto expresa una mayor prioridad. Nótese que esto implica que ante la falta de otros criterios, cualquier trabajo enviado con qsub sin definir parámetros se ejecutará en np1 con los límites de dicha cola. | ||
+ | ==== Estados de los trabajos en el sistema de colas ==== | ||
+ | <code bash> | ||
+ | hpc-login2 ~]# squeue -l | ||
+ | JOBID PARTITION | ||
+ | 6547 defaultPa | ||
+ | |||
+ | ## Ver estado de uso de las colas del cluster: | ||
+ | hpc-login2 ~]$ estado_colas.sh | ||
+ | JOBS PER USER: | ||
+ | -------------- | ||
+ | | ||
+ | | ||
+ | |||
+ | JOBS PER QOS: | ||
+ | -------------- | ||
+ | | ||
+ | long: 1 | ||
+ | |||
+ | JOBS PER STATE: | ||
+ | -------------- | ||
+ | | ||
+ | | ||
+ | ========================================== | ||
+ | Total JOBS in cluster: | ||
+ | </ | ||
+ | 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:// | ||
+ | Si un trabajo no está en ejecución aparecerá una razón debajo de REASON:[[ https:// |