PDF de programación - Administración de Sistemas Operativos III - Curso de Computación Científica en Clusters

Luis P. García González

Servicio de Apoyo a la Investigación Tecnológica

Universidad Politécnica de Cartagena

  Sistema de gestión de trabajos y

recursos de computación

  Herramienta para que el usuario aproveche las

capacidades del sistema de computación.

  Herramienta para que el administrador del sistema

pueda asegurar un uso equitativo del sistema
(cumplimiento de las políticas de uso).

¿Qué hace un sistema de gestión de trabajos?

  PONER EN COLA: tareas para ser ejecutadas en un computador. El

usuario envía tareas o “trabajos” al gestor de recursos, y éstos son
puestos en cola hasta que el sistema esté preparado para
ejecutarlos.

  PLANIFICAR: seleccionar que trabajos se van a ejecutar, cuando y

donde, conforme a una determinada política con el objetivo de
maximizar los recursos (tiempo de computación y tiempo de los
usuarios).

  MONITORIZAR: realizar un seguimiento de la utilización de los

recursos del sistema y asegurar que se están aplicando las políticas
de uso.

Dominio público:

  Torque/Maui: Teraescale Open-Source Resource and QUEue Manager. Proyecto

que surge a partir de OpenPBS (desarrollado por la NASA en los 90)
http://www.clusterresources.com

  Sun Grid Engine: Proyecto de la empresa SUN destinado a entorno distribuidos y

heterogeneos http://gridengine.sunsource.net/

  Condor: Proyecto que se centra en la utilización eficiente de recursos

computacionales no dedicados. http://www.cs.wisc.edu/condor/description.html

  SLRUM: Simple Linux Utility for Resource Management. Proyecto GNU de fácil

instalación, con un diseño modular que permite ampliar su funcionalidad a través de
su API y plug-ins. https://computing.llnl.gov/linux/slurm/

Comerciales:

  Platform LSF: Load Shared Facility. El sistema de gestión de trabajos para entornos
de computación de alto rendimiento lider en el mercado. (5 millones de CPUs están
siendo gestionadas por este producto).
http://www.platform.com/workload-management/high-performance-computing

  Altair PBSPro: Versión comercial y mejorada del proyecto OpenPBS.

http://www.pbsworks.com/

  MOAB: Versión comercial y mejorada del proyecto MAUI.

http://www.clusterresources.com

 

IBM LoadLeveler: http://www-03.ibm.com/systems/software/loadleveler/index.html

  Centro de SuperComputación de Murcia: 1 nodo de 128 cores Intel Itanium-2 y 102

nodos Intel Xeon (816 cores). Load Shared Facility.

  Centro de SuperComputación de Castilla y León: 304 nodos Intel Xeon Quad

Core (2432 cores). Sun Grid Engine.

  Centro Nacional de Supercomputación (BSC): 2560 nodos de IBM PowerPC 970

(10240 procesadores) y 1 nodo de 256 cores Intel Itanium-2. SLRUM+MOAB.

  Centro de SuperComputación de Extremadura: 2 nodos de 128 cores cada uno

Intel Itanium-2. Load Shared Facility.

  Centro de SuperComputación de Cataluña: 128 procesadores Intel Itanium, 224

cores Intel Xeon, 132 cores AMD Opteron 275. Load Shared Facility.

  Centro de SuperComputación de Galicia: 142 nodos de 16 cores Intel Itanium 2

(2272 cores), 1 nodo de 128 cores y 1 nodo de 128 cores. Sun Grid Engine.

  Centro de SuperComputación y Visualización de Madrid: 1204 nodos de IBM

PowerPC (2744 cores). SLRUM+MOAB.

Diagrama de los Componentes de Torque y funcionalidades

Comandos

Torque

Kernel

pbs_mom: Es el proceso que pone el
pbs_server: Todos los comandos y
trabajo en ejecución. Se denomina
resto de componentes se comunican
informalmente MOM al tratarse de la
con el servidor vía una red IP. La
madre de todos los trabajos en
función principal es la de proporcionar
ejecución. MOM pone un trabajo en
Servidor
JOBS
los servicios batch básicos tales como
ejecución cuando recibe una copia del
pbs_server
recibir/crear un trabajo batch, modificar
trabajo desde pbs_server. MOM crea
el trabajo y proteger el trabajo ante
una nueva sesión lo más idéntica
caídas del sistema.
posible a la del usuario que mandó el
trabajo, además es el encargado de
devolver al usuario la salida del
trabajo.

pbs_sched: Es el proceso que
implementa las políticas de uso
definidas, controlando cuando cada
trabajo se ejecuta y en que recursos.
MOM
El Planificador se comunica con los
pbs_mom
MOMs para interrogarles sobre el
estado de los recursos del sistema y
con el Servidor para conocer la
existencia de trabajos a ejecutar.

Planificador
pbs_sched

BATCH

JOB

1.  Descargar Torque desde http://clusterresources.com/downloads/torque
2.  Extraer el paquete descargado:

$ tar zxvf torque-2.4.5.tar.gz
$ cd torque-2.4.5

3.  Configurar (uso de scp para transferencia de archivos) y compilar:

$ script make-torque-<fecha>.txt
$ ./configure –with-rcp=scp
$ make
$ exit



# Unos 10 minutos

4. 

Instalar:

$ su -
$ make install

# Requiere instalación como root

5.  Crear paquetes para los nodos de computación:

$ make packages

6. 

Instalar el paquete MOM en los nodos de computación:

$ ssh root@ccc-nodo1 /apps/sources/torque-2.4.5/
torque-package-mom-linux-i686.sh --install

7.  Configurar el sistema para que pbs_server, pbs_sched sean servicios:

$ cp contrib/init.d/pbs_server /etc/init.d
$ cp contrib/init.d/pbs_sched /etc/init.d
$ chkconfig --add pbs_server
$ chkconfig --add pbs_sched

8.  Establecer pbs_mom en los clientes como servicio:

$ scp contrib/init.d/pbs_mod root@ccc-nodo1:/etc/init.d
$ ssh root@ccc-nodo1 chkconfig --add pbs_mom
$ ssh root@ccc-nodo1 chkconfig --list pbs_mom

1.  Ejecutar script de inicialización de Torque:

$ ./torque.setup root

2.  Especificar los nodos de computación (/var/spool/torque/server_priv/nodes):

$ qmgr –c ‘create node ccc-nodo1’
$ qmgr –c ‘set node ccc-nodo1 np=4’

3.  Comprobar que son vistos por el gestor de recursos:

$ pbsnodes –l

4.  Configuración de Torque en los nodos de computación y arranque:

$ cat /var/spool/torque/server_name
$ cat /var/spool/torque/pbs_environment
$ service pbs_mom start

5.  Comprobar que se ven los nodos de computo desde el servidor:

$ pbsnodes -a

6.  Añadir usuarios con privilegios de administración:

$ qmgr

Qmgr: set server managers += ccc@ccc-server1
Qmgr: quit

7.  Comprobar el funcionamiento de la configuración básica:

$ qstat –q

$ qmgr –c ‘p s’
$ su – inv1

$ echo “sleep 30” | qsub
$ qstat



# Verificar conf. colas
# Verificar conf. servidor
# NO SE PUEDEN LANZAR TRABAJOS COMO ROOT

# Ver estado del trabajo

8.  En este punto el trabajo se encontrará en el estado Q y no se ejecutará:

Time Use S Queue
Job id
-------------- -------------- ------- -------- - -----
0.ccc-server
STDIN
Q batch

Name

User



inv1

0

9.  Hace falta un planificador (scheduler). Se puede usar el que viene con

Torque (pbs_sched) u otro más avanzado como MAUI:

$ service pbs_sched start

10.  Cambiar el tiempo en el que un trabajo se mantiene en el estado C:

$ qmgr –c ‘set server keep_completed=10’

11.  scheduler_iteration: El tiempo, en segundos, entre intentos del servidor

para planificar trabajos. Valor por defecto 10 minutos. Recomendable
bajarlo a 5 minutos para un cluster pequeño:

$ qmgr –c ‘set server scheduler_iteration=300’

12.  node_check_rate: Tiempo, en segundos, que un nodo puede estar sin

responder antes de considerarlo no disponible (down). Valor por defecto 10
minutos:

$ qmgr –c ‘set server node_check_rate=150’

13.  node_ping_rate: Indica el intervalo máximo, en segundos, entre sucesivos
ping enviados desde el pbs_server al pbs_mom para determinar el estado
del nodo. Valor por defecto 5 minutos:
$ qmgr –c ‘s s node_ping_rate=150’

14.  tcp_timeout: Especifica el timeout, en segundos, en el socket TCP entre el

pbs_server y el pbs_mom. Valor por defecto 6 segundos.

1.  Aumentar el número de descriptores de archivos:
$ ulimit -n
$ vi /etc/init.d/pbs_mom
ulimit –n 32768
2.  Límites en las sesiones interactivas: 2 métodos
$ cat /etc/security/limit.conf

$ cat /etc/profile
# 256 Mbytes memoria física
# 128 Mbytes segmento de datos
# 15 minutos uso CPU
if [ ! “$PBS_ENVIRONMENT” ] ; then
if [ ! `whoami` != root ] ; then
ulimit –m 256000
ulimit –d 128000
ulimit –t 900
fi
fi

  Ejemplo de script de definición de trabajo para Torque:

#!/bin/bash
#PBS –N ejemplo1
#PBS –l nodes=1,walltime=00:01:00
#PBS –q batch
#PBS –m ae

date
sleep 10
date

  Envío al sistema de colas y monitorización:

$ qsub mitrabajo.pbs
$ qstat

  Por omisión sólo root y el usuario que mandó el trabajo y root podrá verlo:
$ qmgr –c ‘s s query_other_jobs=true’

#!/bin/bash
#PBS -lnodes=1:ppn=1,vmem=5GB
#PBS -m e
#PBS -M [email protected]

module load gaussian
export GAUSS_SCRDIR=${GAUSS_SCRDIR}/$PBS_JOBID
mkdir $GAUSS_SCRDIR
# Escribir todo, hasta los chk que queremos recuperar
# en scratch local
cd $GAUSS_SCRDIR
# El archivo de entrada lo tenemos en el mismo directorio desde el
# que mandamos el trabajo y queremos que el log vaya tambien alli
g03 < $PBS_O_WORKDIR/test594.com > $PBS_O_WORKDIR/test594.log
# Si hay algun archivo de checkpoint lo copiamos
cp *.chk $PBS_O_WORKDIR
# Eliminamos el resto de archivos generados y que no hacen falta
# asi como el directorio de trabajo

rm -fr $GAUSS_SCRDIR

  Si el equipo desde el que se envía trabajos es distinto al del servidor:
$ qmgr –c ‘set server submit_hosts=ccc-login’

  Establecer el máximo número de trabajos que un usuario puede tener en el

sistema:

$ qmgr –c ‘set server max_user_run=4’

  Definir cola para trabajos sólo secuenciales:

$ qmgr –c ‘create queue secuen’
$ qmgr –c ‘s q secuen resources_max.nodect = 1’
$ qmgr –c ‘s q secuen queue_type = Execution’
$ qmgr –c ‘s q secuen max_user_run = 5’
$ qmgr –c ‘s q secuen max_user_queuable = 10’
$ qmgr –c ‘s q secuen enabled = true’
$ qmgr –c ‘s q secuen started = true’
$

  Envío de múltiples trabajos (JOBS ARRAYS): Cuando se desea mandar un

núm