wiki:ColasPBS

Version 3 (modified by lluis, 12 years ago) (diff)

--

Introducción

Un clúster es una agrupación de unidades de computación el cual permite trabajar con unidades individuales o cualquier subconjunto de ellas. Las unidades de computación pueden ser de muchos tipos y tener muchas características distintas, por lo general con una unidad de cálculo (core) y una memória (particular del core o compartida con otros). Un clúster suele tener much@s usuari@s que querrán ejecutar distintas aplicaciones. Un gestor de colas es el software encargado de manejar las aplicaciones que se quieren ejecutar en un determinado clúster.

Gestor de colas

Para que un clúster funcione adecuadamente para tod@s us usuari@s y el gestor de colas pueda hacer su trabajo, l@s usuari@s sólo tienen que interactuar con el gestor por medio de jobs. Estos jobs son peticiones de recursos del clúster (número de cores, tiempo de ejecución...) necesarios poder lanzar la aplicación del usuari@. El gestor de colas será el encargado de permitir la ejecución de la petición si hay suficientes recursos disponibles en el clúster. En caso contrario, el trabajo se quedará encolado, a la espera de que haya los recursos suficientes requeridos en el job. De esta manera, todas las peticiones de l@s usuari@s son centralizadas y manejadas automáticamente por el gestor de colas. Este gestor de colas puede a su vez, estar siguiendo unas directrices de prioridades de ejecución determinadas por otros softwares buscando maximizar el rendimiento del clúster.

El sistema de colas del clúster del Grupo de Meteorología de Santander (Diciembre 2010) es el sistema de colas PBS (Portable Batch System).

Job

Un job del clúster tiene unos cuantos requerimientos básicos tales como:

  • número de cores: el número de unidades de cálculo que se requieren para la ejecución del job.
  • cola de ejecución: etiqueta que se le da a un grupo de cores. Determina los cores que tendrán que compartir todos los jobs que se manden en concreto a una cola. Es muy común que un clúster se compartimente en distintas colas a modo de intentar maximizar el rendimiento de un clúster. Estas colas pueden compartir cores entre ellas y estar asignadas a proyectos y/o grupos de usarios distintos.
  • wall-time: determina el tiempo de ejecución del job dentro del clúster. Una vez pasado este tiempo el job y su aplicación seran detenidos forzosamente. Es un muy común que en los clústers se ejectuen antes los jobs con un wall-time pequeño que con uno de grande

La pericia de l@s usuari@s en saber escoger adecuadamente los requerimientos de sus jobs, determinará el éxito a la hora de que se ejecuten sus jobs.

Las unidades básicas que constituyen un clúster son:

  • nodos: computadoras que contienen una estructura parecida a un ordenador común. Con una o mas cpus que a su vez pueden contener 2, 4, 8, 16 o más cores. Memoria total y espacio de almacenamiento (en uno o varios discos duros).
  • switch: unidad de interconnexión entre nodos
  • unidad de almacenamiento: máquina constituida por un conjunto de discos duros. Suele tener tres espacios básicos:
    • HOME: Es un directorio particular de cada usuario al cual se accede al iniciar una sesión/job en el clúster
    • datos: datos necesarios para trabajar con las aplicaciones de los usuarios del clúster
    • trabajo: espacio en donde se almacenan los resultados de los jobs
    • Lo mas común es que todas las unidades de almacenamiento sean visibles des de todos los nodos de un clúster

Infraestructura del GMS

La infraestructura del Grupo de Meteorología de Santander (GMS) es la siguiente (diciembre 2010).

NOTA IMPORTANTE: la ejecución de jobs se hace sólo desde la máquina llamada mar

  • nodos:
    • nodos viejos: 9 nodos de 1 cpu de 2 cores y 2 GB de memória (nodos [001]-[009])
    • nodos menos viejos: 26 nodos de 2 cpus de 4 cores y 8 GB de memória (nodos [010]-[025])
    • nodos nuevos: 12 nodos de 2 cpus de 8 cores y 16 GB de memória (nodos [031]-[036], [041]-[046])
  • Almacenamiento: visible desde todos los nodos con:
    • /oceano/gmeteo/users/[usario]: HOME del usuario llamado [usuario]
    • /oceano/gmeteo/DATA: almacenamiento de todos los datos (observaciones, GCMs, RCMs, ...)
    • /oceano/gmeteo/WORK: directorio de trabajo
    • /software: directorio con todas las aplicaciones

Los requerimientos de un job en una cola PBS

En esencia los gestores colas son muy parecidos entre sí. Sólo cambia parte de su semántica.

En la gestión de colas PBS existen dos términos para referirse a la unidad cálculo: el node y el cpp. Un node equivalen a las unidades físicas de cálculo (las cpus) que integran distintas cantidades de cores cpp (2, 4, 8, 16,...)

Las peticiones se hacen por un conjunto de flags. El envio del job al gestor de la cola se puede hacer añadiendo todas las directrices en la línea de comandos de la aplicación, o por medio de una script (archivo de texto con instrucciones de sistema). En según que circumstancias nos va interesar hacerlo de una manera u otra, pero las dos son equivalentes. La estructura tipo de un script (llamado por ejemplo job.pbs) de colas tiene la siguiente estructura (se añaden todas las opciones a modo de ejemplo):

{{{#!/bin/bash ### Job name #PBS -N [jobname] ### Max run time #PBS -l walltime=[HH]:[MM]:[SS] ### Queue name #PBS -q [queueNAME] ### Job mail #PBS -M [emailCOUNT] ### Standard error output #PBS -e [rutaArchivo] ### Standard output #PBS -o [rutaArchivo] ### Dependecy #PBS -W afterany:[jobid] ### Number of nodes and processors per node #PBS -l nodes=[N]:ppn=[M]

cd ${PBS_O_WORKDIR

[aplicacion]}}}}

En esta plantilla se muestra la sintaxis de los siguientes requerimientos/especificaciones: tiene que cambiar los argumentos que estén entre []:

  • -N [jobname] : nombre del job
  • -l walltime=[HH]:[MM]:[SS] : duración del job (en [horas]:[minutos]:[segundos]).
  • -q [queue] : nombre de la cola a la cual se manda el job
  • -M [emailCOUNT]: dirección de correo donde se quiere que mande un job terminado (por lo general al correo del sistema)
  • -e [rutaArchivo]: ruta del archivo en donde se quiere almacenar la salida estandard del error del job (si no se indica se construye en el directorio donde está el script el archivo ${PBS_JOBNAME}.e${PBS_JOBID})
  • -o [rutaArchivo]: ruta del archivo en donde se quiere almacenar la salida estandard del job (si no se indica se construye en el directorio donde está el script el archivo ${PBS_JOBNAME}.o${PBS_JOBID})
  • -W afterany:[jobid]: el job se mandará a la cola cuando otro job anterior (el número [jobid]) termine su ejecución (no importa como termine)
  • -l nodes=[N]:ppn:[M] : número de nodos ([N]) y número de cores a coger de cada nodo ([M]), al cual se quiere mandar el job

El job se mandaría a la cola con la instrucción: qsub job.pbs

o bien por la línea de comandos en una línea como sigue: {{{qsub -N [jobname] -l walltime=[HH]:[MM]:[SS] -q [queueNAME] -M [emailCOUNT] -e [rutaArchivo] -o [rutaArchivo] -W afterany:[jobid] -l nodes=[N]:ppn=[M] [aplicacion] }}}

Todos los jobs tienen un número que los identifica que se llama [jobid]. En el clúster del GMS tiene el siguiente formato: [jobid].ce01.macc.unican.es. Cada job tiene associado los siguientes valores PBS:

  • Job ID: identificador del trabajo (asignado por PBS).
  • Username: propietario del trabajo (usuario que lo envió).
  • Queue: cola en la que reside el trabajo.
  • Jobname: nombre del trabajo dado por el usuario o establecido por PBS en caso de no especificarse.
  • NDS: número de nodos solicitados.
  • TSK: número de tareas solicitadas.
  • Req'd Memory: cantidad de memoria solicitada.
  • Req'd Time: tiempo de reloj (wallclock) solicitado.

Instrucciones cola PBS

Hay distintas instrucciones para gestionar los jobs de un usuario:

  • qsub [archivo].pbs envio del job [archivo].pbs a la cola
  • qdel [jobid] terminar forzosamente el job con id [jobid]
  • qstat permite ver el estado de los jobs gestionados. Tiene también distintos flags (se muestran los mas usuales):
    • -n1 muestra todos los nodos a los cuales se ha mandado un job (con tantas veces el nombre del nodo, cómo cores cogidos)
    • -u [usuario] muestra todos los jobs de [usuario] Por lo general mestra en lista los trabajos que concidan con los criterios escogidos con la siguiente estructura:

{{{[jobid] [usuario] [queue] [jobname] [SessID] [NDS] [TSK] [Req' Memory] [Req' time] [S] [Time] }}}

Los estados [S] que puede tener un job en la cola son:

  • E el trabajo está saliendo después de finalizar su ejecución.
  • H el trabajo está capturado (Hold, ej. esperando que termine otro)
  • Q el trabajo está en cola, elegible para su ejecución.
  • R el trabajo está ejecutándose.
  • T el trabajo está en transición (moviéndose a otra localización).
  • W el trabajo está a la espera de alcanzar el tiempo de ejecución.
  • S el trabajo está suspendido.

ejemplos

Wall time insuficiente

Tomamos un job sencillo de ejemplo escrito en un fichero llamado prueba.pbs. Este job deja una espera de 60 segundos. {{{#!/bin/bash ### Job name #PBS -N prueba ### Max run time #PBS -l walltime=00:00:10 ### Queue name #PBS -q grid ### Number of nodes and processors per node #PBS -l nodes=1:ppn=1

cd ${PBS_O_WORKDIR}

rm ${PBS_JOBNAME}.e* rm ${PBS_JOBNAME}.o*

sleep 60}}}

Lanzando el job obtendríamos: {{{[lluis@mar CursilloPBS]$ qsub prueba.pbs 307065.ce01.macc.unican.es [lluis@mar CursilloPBS]$ qstat | grep prueba 307065.ce01 prueba lluis 0 R grid [lluis@mar CursilloPBS]$ qstat -n1 | grep prueba 307065.ce01.macc.uni lluis grid prueba 23057 1 -- -- 48:00 R -- wn001 [lluis@mar CursilloPBS]$ ls prueba.pbs}}} Pasados los 60 segundos... {{{[lluis@mar CursilloPBS]$ ls prueba.e307065 prueba.o307065 prueba.pbs}}} Al mirar el contenido de los ficheros: {{{[lluis@mar CursilloPBS]$ cat prueba.o307065 [lluis@mar CursilloPBS]$ cat prueba.e307065 =>> PBS: job killed: walltime 43 exceeded limit 10}}} El tiempo dado al job es insuficiente.

Mandar el job a un nodo en concreto

Si se quiere mandar el job a un nodo en concreto se substituye la línea PBS -l nodes=1:ppn=1 por:

{{{#PBS -l nodes=wn[nnn].macc.unican.es

}}} Donde [nnn] es el nodo requerido

Ocupar toda la memória de un nodo con un único job

Para ocupar toda la memória de un nodo con un único job, bastará con pedit todos los cores de un nodo de la cola. Así, si queremos toda la memória de los nodos de la cola dinamica, requeriríamos:

{{{#PBS -l nodes=1:ppn=8

}}}

Lanzar un job interactivo

A la hora de hacer pruebas es muy útil abrir una sessión interactiva en un nodo del clúster. Esto se hace mandando un job interactivo. La sessión que se habra durará todo el tiempo que se quiera hasta que no se le mande la instrucción de salida exit. La sintaxis es:

{{{qsub -I -l nodes=1 -q [queue]

}}} NOTA: A la hora de lanzar este tipo de jobs se tiene que ser muy consciente de que se está ocupando un nodo del clúster. Tendría que utilizarse sólo para realizar pruebas que no sean muy largas. Para lanzar jobs muy largos mejor prepararse una script de shell.

Attachments (6)

Download all attachments as: .zip