Este documento describe los pasos a seguir para la instalación de Torque PBS. PBS, sigla de Portable Batch System, consiste en un resource manager para batch systems. En líneas generales, se trata de un sistema de encolado de trabajos batch flexible, que permite especificar requerimientos de los trabajos, administrar distintas colas con diferentes características, y ejecutar, cancelar y monitorear los diferentes trabajos.

Este documento no realiza presunciones respecto de software ya instalado, excepto por aquellas herramientas indicadas expresamente en la sección de prerrequisitos.

1.2 Definiciones de términos y abreviaturas

Los siguientes términos y abreviaturas son utilizados en el presente documento:

Término o Abreviatura	Definición
GT	Globus Toolkit, cuando la sigla sea seguida por un número, éste se referirá a la versión
GRAM	Globus Resource Allocation and Management
XML	Extensible Markup Language
WS	Web Service
CA	Certificate Authority (entidad certificadora)

1.3 Referencias

A continuación se detallan los documentos relacionados:

Documento	Descripción

2 Conceptos generales

2.1 Batch System

Un batch system es un conjunto de recursos (computadoras, sistemas de almacenamiento, etc.) que se combinan para presentar una visión abstracta de un sistema capaz de ejecutar tareas (en general batch, es decir, no interactivas). El agrupamiento de recursos facilita la administración. Los trabajos pueden correr en las máquinas que satisgafan en número y características los requerimientos de dicho trabajo.

En los batch systems existen cuatro tipos distintos de componentes: el nodo master, los nodos de envío de trabajos o interactivos, los nodos de cómputo, y los recursos. El nodo master es aquel en el que corre el servidor de PBS (pbs_server). Los nodos de envío de trabajos permiten a los usuarios enviar y hacer un seguimiento de sus trabajos, y contienen los comandos cliente de PBS. Los nodos de cómputo son donde se ejecuta el trabajo, y en ellos corre el proceso que lanza, destruye, y administra los trabajos enviados (pbs_mom), los nodos de cómputo también reciben el nombre de moms. Las distintas máquinas pueden cumplir uno o más de los roles correspondientes a los tipos de nodos mencionados. Los recursos incluyen las computadoras, redes, sistemas de almacenamiento, etc.

2.2 Resource manager

Un resource manager es un componente de software que provee la funcionalidad de bajo nivel para lanzar, retener, cancelar y monitorear trabajos. Los trabajos tienen características respecto de sus requerimientos y son colocados en una (o una de varias) colas, teniendo en cuenta dichas características.

2.3 Scheduler

Un scheduler es un componente de software que decide dónde, cuándo, y cómo correr trabajos de acuerdo con una serie de políticas, prioridades, y límites. El scheduler de un batch system consulta y controla al resource manager (PBS en este caso) en lo que respecta a trabajos encolados para correr y requerimientos de los mismos.

Las políticas de un scheduler se ajustan para optimizar el uso de recursos y minimizar el tiempo de los trabajos, respetando prioridades, criterios de asignación de recursos, y demás condicionamientos.

2.4 Flujo básico

El ciclo de vida de un trabajo se divide en las etapas de creación, envío (submission), ejecución, y finalización. La etapa de creación consiste en, por lo general, la escritura de un script que contiene parámetros y directivas de PBS, mediante líneas que comienzan con #PBS (existen otras maneras de enviar trabajos, en particular mediante el uso del comando echo y pipes, como se explica en la sección de Comandos del shell). La etapa de envío consiste en hacer submit del trabajo a PBS (por ejemplo, mediante el comando qsub, explicado en la sección de Comandos del shell). Una vez que se decide correr el trabajo (ya sea mediante los comandos de PBS o bien porque así lo decide el scheduler), el mismo entra en la etapa de ejecución. Para ejecutarse, el trabajo es enviado al primer nodo en la lista de nodos reservados para el mismo. Este nodo se denominada "nodo de ejecución" o "Mother Superior". El trabajo procurará hacer uso de los otros nodos asignados, que se conocen como "sister moms". La etapa de finalización incluye, por default, la copia de la salida estándar y de error al directorio desde el cuál se envió el trabajo.

3 Prerrequisitos

make
tar

4 Configuración previa

4.1 Creación del usuario torque

En primer lugar, se crea un usuario que será el administrador de Torque. Este usuario tendrá los roles de operador y manager del servidor, y será quien inicialmente podrá enviar trabajos al resource manager (luego otros usuarios también podrán hacerlo si se actualiza la configuración de PBS).

Para crear el usuario torque, ejecutar:

Como usuario root:

adduser torque

4.2 Configuración de ssh

4.2.1 Acceso sin password

Para poder copiar los datos a y desde los nodos de cómputo, debe permitirse que TORQUE pueda ejecutar comandos scp sin necesidad de un password.

Para ello, debe obtenerse una clave de ssh:

Como el usuario desde el cual se desea enviar trabajos, y como el usuario administrador de torque:

ssh-keygen -t rsa

Dejar en blanco la passphrase cuando se solicite. Este comando generará los archivos id_rsa e id_rsa.pub (clave privada y pública respectivamente) dentro del directorio .ssh del home del usuario.

El archivo id_rsa.pub debe ser copiado a cada una de las máquinas en las que se requiera acceso por ssh/scp, en dichas máquinas:

Como el usuario correspondiente al del ssh-keygen de la otra máquina:

cat id_rsa.pub >> .ssh/authorized_keys

rm id_rsa.pub (el archivo transferido puede borrarse una vez agregado al authorized_keys)

De esta manera, el archivo authorized_keys contendrá las claves públicas de los usuarios autorizados a acceder por ssh/scp a la máquina en la que se encuentra este archivo, sin utilizar password. Cabe aclarar que el archivo authorized_keys deberá contener también el contenido del archivo id_rsa.pub del usuario de la misma máquina en la que se ejecuta el comando cat que agrega el contenido a dicho archivo. Los permisos recomendados para el archivo authorized_keys se corresponden con el modo 600 del comando chmod.

Además, debe realizarse un acceso por ssh o por scp al resto de las máquinas, utilizando el full-qualified domain name, de forma que los fingerprint de cada host con el que se tendrá comunicación queden agregados al archivo known_hosts, también del directorio .ssh.

El procedimiento descripto debe realizarse en forma cruzada para todas las máquinas que deban comunicarse entre sí.

4.2.2 Wrappers para los comandos

Para utilizar Torque a través de Globus, se emplea el GRAM PBS jobmanager de globus, representado por el archivo jobmanager-pbs del GT. Dicho jobmanager genera scripts para PBS que ejecutan los comandos de ssh de manera no compatible con las últimas versiones de OpenSSH. Esto es así dado que las opciones deben pasarse al comando ssh en la forma -oOpcion=yes/no o bien -o"Opcion yes/no", pero el jobmanager mencionado lo hace de la manera -oOpcion yes/no. El espacio debe ser salvado por comillas o bien reemplazado por un =.

El workaround que se propone, dado que el archivo jobmanager-pbs es binario, consiste en escribir un wrapper para el comando ssh, que realice el reemplazo del espacio por el signo =.

El wrapper de ssh tiene el siguiente contenido:

#!/bin/bash

export PARAMETROS=`echo $@ | sed "s/-o$[A-Za-z]*$ yes/-o\1=yes/g" | sed "s/-o$[A-Za-z]*$ no/-o\1=no/g"`

/usr/bin/ssh-original $PARAMETROS

A su vez, es necesario escribir un wrapper para el comando scp, dado que la generación de un wrapper de ssh interfiere con el funcionamiento de dicho comando, que utiliza internamente ssh.

El wrapper de scp tiene el siguiente contenido:

#!/bin/bash

/usr/bin/scp-original -S /usr/bin/ssh-original $@

Estos dos wrappers deben generarse en todas las máquinas (master, cómputo y clientes), renombrando el comando original a ssh-original o scp-original según corresponda. Los comandos, generalmente, se ubicarán en el directorio /usr/bin.

4.3 Configuración de directorios compartidos

El GRAM PBS jobmanager de globus requiere un file system compartido para su correcto funcionamiento, de manera de poder acceder a los scripts generados para PBS para su ejecución. De todas maneras, con compartir el subdirectorio .globus del home de los usuarios en los que se utilice PBS, es suficiente. En general, esto no debería representar un problema, dado que en un cluster, al menos el directorio home, suele ser compartido.

Los directorios se pueden compartir por NFS o bien utilizando otro protocolo. Se ejemplifica en este caso la manera de hacerlo a través de SAMBA, compartiendo únicamente el subdirectorio .globus del usuario, que en este caso se denominará usupbs.

Para publicar el directorio compartido, en la máquina en la que realmente residirán los archivos deberá incluirse en el archivo smb.conf:

[homeusupbs]

path=/home/usupbs/.globus

browsable=yes

writable=yes

valid users = usupbs

Luego, este directorio puede ser montado en otras máquinas mediante el comando:

Como root, posicionado en /home/usupbs:

mount -t smbfs -o username=usupbs,password=password,workgroup=WORKGROUP,uid=usupbs,gid=usupbs //MAQUINA_SAMBA/homeusupbs .globus

Donde debe reemplazarse password por el password del usuario usupbs, WORKGROUP por el workgroup correspondiente (indicado en el archivo smb.conf), y MAQUINA_SAMBA por el IP o nombre de la máquina que expone el directorio compartido.

Se requiere para el procedimiento descripto el paquete smbfs. El directorio se desmonta normalmente con el comando umount.

4.4 Igualación de uids y gids

Para que los directorios puedan ser compartidos de la manera indicada en la sección de "Configuración de directorios compartidos", y lograr un correcto funcionamiento, es necesario que los ids numéricos de Linux de los usuarios y grupos correspondientes a los directorios compartidos sean iguales en todas las máquinas. En general, esto no representa un problema, ya que en los clusters se suele utilizar un mismo archivo /etc/passwd para todas las máquinas, o bien establecer sistemas mediante NIS o LDAP que permiten que el funcionamiento sea el adecuado.

Sin embargo, de ser necesario realizar una igualación de estos ids, el procedimiento a seguir consiste en:

Cambiar el id del grupo correspondiente mediante el comando:

groupmod -g nuevogid usupbs

Luego debe actualizarse el gid de los archivos que hayan quedado "huérfanos" al realizar este cambio, mediante el comando:

find usupbs -group viejogid -print | xargs -t chgrp usupbs

Cambiar el id del usuario correspondiente mediante el comando:

usermod -g usupbs -u nuevouid usupbs

Los archivos del directorio /home/usupbs verán su uid actualizado en forma automática. Para otros directorios deberá ejecutarse, en forma análoga a lo hecho para el gid:

find usupbs -user viejouid -print | xargs -t chown usupbs

En todos estos ejemplos, se asume que el usuario y grupo se llaman usupbs.

5 Instalación de Torque

5.1 Instalación de TORQUE

Para instalar Torque PBS, obtener en primer lugar el archivo tar.gz correspondiente de http://www.clusterresources.com/downloads/torque/.

Descomprimir dicho archivo en un directorio en la máquina que será el servidor de PBS (nodo master) y ejecutar configure, make y make install como se indica.

Como un usuario con permisos sobre el directorio en el que se descomprimirá el archivo:

tar -xzvf torque-2.1.2.tar.gz

cd torque-2.1.2

./configure --with-scp --enable-syslog

make

su -c 'make install'

Las opciones --with-scp y --enable-syslog indican, respectivamente, que se debe utilizar scp para las transferencias de archivos (en lugar de rcp, es recomendable utilizar scp) y que debe habilitarse el reporte de errores mediante el syslog.

5.2 Configuración del servidor

5.2.1 Configuración básica

En primer lugar, es necesario inicializar la base de datos que guardará las configuraciones de Torque. También es necesario configurar una primera cola básica. Ambos objetivos se consiguen mediante la ejecución del comando que a continuación se indica.

Como root, desde el directorio en el que se descomprimió el .tar.gz:

./torque.setup torque

Donde torque es el nombre del usuario que actuará como administrador. La cola básica configurada se llamará batch.

5.2.2 Especificación de los nodos de cómputo

El servidor de PBS debe conocer cuáles son los nodos de cómputo. Para ello, el archivo nodes del subdirectorio server_priv, dentro del directorio de torque (en general, /var/spool/torque) contiene los nombres de los nodos, uno por línea. Opcionalmente, puede contener también la cantidad de procesadores del nodo, indicando np=cantidad a continuación del nombre de dicho nodo.

Ejemplo:

nodo1 np=2

nodo2

5.2.3 Configuración de las colas

La configuración de las colas se realiza mediante la interfaz provista por la utilidad qmgr.

El comando qmgr -c 'p s' desde el shell, o bien la acción print server desde la interfaz de qmgr, permite ver la configuración del servidor de pbs y de las colas definidas.

Dicha interfaz permite también modificar la configuración. Algunos comandos de ejemplo son:

set server managers += usuario@nodo

set server operators += usuario@nodo
set queue batch keep_completed = 2

(configuración de una cola específica, indicando retener el estado de "completo" para los trabajos, durante la cantidad de segundos especificada, antes de salir).

5.3 Generación de paquetes de distribución

A fines de que los nodos de cómputo y los nodos cliente puedan funcionar como tales, es necesario generar paquetes de distribución en el servidor, como se indica:

Como un usuario con permisos sobre el directorio en que se descomprimió el .tar.gz:

make packages

El comando indicado generará los paquetes autodescomprimibles torque-package-server-linux-i686.sh, torque-package-mom-linux-i686.sh, torque-package-clients-linux-i686.sh, torque-package-devel-linux.i686.sh, torque-package-doc-linux-i686.sh.

5.4 Configuración de nodos de cómputo

En los nodos de cómputo, existirá un archivo server_name dentro del directorio de Torque (en general, /var/spool/torque). Dicho archivo contiene el nombre del nodo servidor, por ejemplo: nodo1. También existe otro archivo, config, dentro del subdirectorio mom_priv. Dicho archivo contiene líneas en forma de variables. Para indicar el nombre del servidor, se hace de la forma $pbsserver nodo1.

En cada nodo de cómputo, será necesario instalar el paquete correspondiente, torque-package-mom-linux-i686.sh. Previamente habrá que copiar el paquete a la máquina en la que se instalará.

Como root:

torque-package-mom-linux-i686.sh --install

5.5 Configuración de nodos clientes

Para que un nodo pueda enviar trabajos, debe ser configurado como cliente. Esto se hace mediante la instalación del paquete correspondiente, torque-package-clients-linux-i686.sh.

Como root:
torque-package-clients-linux-i686.sh --install

5.6 Scheduler

El scheduler es el componente que se encarga de elegir un trabajo de una cola, en algún momento, elegir dónde debe correr, y lanzarlo. Un scheduler muy utilizado con Torque es Maui. También existe la posibilidad de utilizar Moab, un suite más amplio que incluye funcionalidades adicionales.

Si bien Torque está más orientado a ser utilizado como resource manager, viene con un scheduler básico. Para lanzar dicho scheduler, en la máquina servidor de pbs ejecutar:

Como root:

pbs_sched

6 Configuración posterior

6.1 Administradores y operadores

Es posible agregar usuarios para que sean administradores o bien operadores de PBS. Los usuarios managers pueden utlizar todas las funcionalidades del batch system, en particular para realizar acciones administrativas sobre el propio batch system, sus colas y trabajos (pueden, por ejemplo, crear y borrar colas). Los usuarios operadores pueden utilizar algunas de las funcionalidades del batch system (pueden, por ejemplo, configurar atributos del server y las colas).

Para configurar los administradores y operadores, ejecutar el comando qmgr, y luego, según corresponda:

set server managers += usuario@nodo

set server operators += usuario@nodo

Para salir de la interfaz del qmgr, ingresar el comando quit.

7 Prueba de la instalación

Para probar la instalación, deberá reiniciarse el servidor (en caso que se haya alterado la configuración, lo que es muy probable si se acaba de instalar), mediante los comandos indicados en la sección de Comandos del shell. El estado de los nodos puede verificarse mediante el comando pbsnodes -a.

Luego deberá enviarse un trabajo, mediante el comando qsub. Puede desactivarse el scheduler si se desea observar el trabajo en la cola con mayor detenimiento, en cuyo caso deberá apelarse al comando qrun. El estado de la cola se consulta mediante el comando qstat.

La salida del trabajo tendrá como nombre nombreTrabajo.oId y la salida de error nombreTrabajo.eId, donde Id es el id del trabajo y nombreTrabajo el nombre de dicho trabajo (si no se especifica, será STDIN si se utiliza el comando echo y un pipe para enviar el trabajo mediante qsub, o el nombre del script indicado si se utiliza qsub con un script).

8 Comandos del shell

8.1 Prendido y apagado de servidores

Para encender el servidor de pbs, ejecutar (como root) pbs_server. Para deternerlo, hacerlo con el comando qterm.

Para encender el servidor de cómputo de pbs, ejecutar (como root) pbs_mom. Para detenerlo, hacerlo con el comando momctl -s.

Para encender el scheduler de pbs (si se utiliza el scheduler provisto por Torque), ejecutar (como root) pbs_sched. Para detenerlo, hacerlo con pkill pbs_sched.

8.2 Estado de los nodos

Para ver el estado de los nodos, ejecutar el comando pbsnodes -a.

8.3 Estado de las colas y los trabajos

Para ver el estado de las colas, ejecutar qstat o bien qstat -q para ver el estado por id de trabajo, o por cola (respectivamente).

Para ver el estado completo de los trabajos, ejecutar qstat -f, indicando opcionalmente un id de trabajo a continuación.

8.4 Envío de trabajos

Para enviar trabajos, hacerlo con el comando qsub. El usuario que ejecuta dicho comando debe estar autorizado para enviar trabajos en la configuración del qmgr. El comando qsub puede ejecutarse de dos maneras:

1) Mediante pipes, de la forma echo "comando" | qsub

2) Mediante un script, de la forma qsub script.sh (dicho script contendrá instrucciones para PBS mediante líneas que comenzarán con #PBS).

El comando qsub acepta modificadores para indicar los recursos requeridos por el trabajo (en particular, la opción -l para especificar nodos), el nombre del trabajo, que será el nombre del archivo de salida (con la opción -N, de otra forma será STDIN para la forma 1, y el nombre del script para la forma 2), y otras opciones.

8.5 Ejecución de trabajos

La ejecución de trabajos está determinada, en principio, por el scheduler. No obstante, PBS provee un comando qrun, que en su forma más simple se ejecuta como qrun id_trabajo, que permite correr un trabajo. Este comando acepta modificadores, en particular el modificador -H permite indicar el nodo en el que se desea que tenga lugar la ejecución, lo cual puede resultar útil para pruebas y debug.

9 Interfaz con Globus GRAM

9.1 Build del jobmanager de globus

Para poder enviar trabajos a un cluster PBS vía Globus, es necesario contar con el GRAM PBS jobmanager de Globus. Por default, dicho jobmanager no viene instalado. En el directorio $GLOBUS_LOCATION/etc/grid-services pueden encontrarse los archivos que representan los distintos jobmanagers instalados. Inicialmente, en dicho directorio se encontrará el archivo jobmanager-fork, y el symlink jobmanager apuntando al mismo. Este symlink convierte a fork el jobmanager por default.

El procedimiento para hacer el build del jobmanager para PBS se describe a continuación.

En la máquina que contiene el pbs server:

Asegurarse que el container de Globus esté apagado.

Como usuario globus:

export X509_USER_CERT=/etc/grid-security/containercert.pem

export X509_USER_KEY=/etc/grid-security/containerkey.pem

grid-proxy-init

Asegurarse que los comandos de PBS (qsub, qstat, pbsnodes) estén el en PATH (si se instalaron los comandos en /usr/local/bin, esto será así).

export PBS_HOME=/var/spool/torque

Acceder al directorio donde se encuentran los fuentes de Globus:

make gt4-gram-pbs

make install

9.2 Configuración del jobmanager de globus

Para configurar el jobmanager recién compilado:

Como usuario globus:

cd $GLOBUS_LOCATION/setup/globus

./setup-globus-job-manager-pbs --remote-shell=ssh

De esta manera se configura el GRAM PBS jobmanager y se le indica que utilice ssh/scp (en vez de rsh/rcp).

9.3 Configuración para WS-GRAM

Para poder enviar trabajos utilizando WS-GRAM (por ejemplo, mediante globusrun-ws), es necesario configurar también los sudoers.

Como root:

visudo

Editar el archivo de forma que quede:

cat sudoers

# /etc/sudoers

# This file MUST be edited with the 'visudo' command as root.

# See the man page for details on how to write a sudoers file.

# Host alias specification

# User alias specification

# Cmnd alias specification

# User privilege specification

root ALL=(ALL) ALL

globus ALL=(usupbs,globus) NOPASSWD: /opt/gt4/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /opt/gt4/libexec/globus-job-manager-script.pl *

globus ALL=(usupbs,globus) NOPASSWD: /opt/gt4/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile /opt/gt4/libexec/globus-gram-local-proxy-tool *

Además del usuario para el que se realice la configuración (en este ejemplo usupbs) y del usuario globus, pueden aparecer otros usuarios también autorizados para la utilización de WS GRAM. Este procedimiento debe realizarse en todos los nodos.

10 Prueba de la interfaz de PBS con Globus

Se ejemplifican a continuación algunos comandos que pueden ejecutarse para probar el GRAM PBS jobmanager.

10.1 Prueba para GRAM (Pre-WS)

Para enviar un trabajo mediante globus-job-run, ejecutar:

globus-job-run nombreHost.nombreOrg.com/jobmanager-pbs /bin/hostname -f

En este ejemplo, se utiliza el comando hostname que permitirá, si se ejecuta varias veces el comando desde distintas consolas, observar que el nodo elegido resulta ser distinto cada vez, según la decisión realizada por el scheduler.

También es posible realizar pruebas con staging, para lo cual el comando a ejecutar será:

globus-job-run nombreHost.nombreOrg.com/jobmanager-pbs -s ejecutable

Utilizando globusrun, la prueba tendría la forma:

globusrun -o -r nomberHost.nombreOrg.com/jobmanager-pbs '&(executable="/bin/hostname")(arguments="-f")'

10.2 Prueba para WS-GRAM

Para enviar un trabajo mediante globusrun-ws, ejecutar:

globusrun-ws -submit -F https://MAQUINA_CONTAINER:8443/wsrf/services/ManagedJobFactoryService -Ft PBS -s -c /bin/hostname -f

Donde MAQUINA_CONTAINER representa la máquina (por ejemplo, el IP) en la que corre el container de globus.

11 Portlets para uso de PBS

11.1.1 Patch para la clase GRAMJobManager

Esta sección documenta un patch desarrollado para el portlet gp-job-submission, utilizado dentro del portal del proyecto. Originalmente, este portlet no permitía el envío de trabajos al recurso jobmanager-pbs.

La modificación consiste en reemplazar, en la clase GRAMJobManager.java, la línea:

String contact = newJob.getHost() + ":" + newJob.getPort(); (línea 88 del archivo original)

Por las siguientes líneas:

String contact = "";
f (newJob.getHost().matches("^.*/.*$")) {
<   String[] tmpStr = newJob.getHost().split("/");
   contact = tmpStr[0] + ":" + newJob.getPort() + "/" + tmpStr[1];
} else {
   contact = newJob.getHost() + ":" + newJob.getPort();
}

11.1.2 Recurso del archivo portlet.xml

Esta sección documenta las modificaciones al contenido del archivo portlet.xml, para el caso particular del portlet gp-job-submission, utilizado en el proyecto. La modificación consiste en incluir nombreHost.nombreOrg.com/jobmanager-pbs como recurso, de la siguiente manera:

<init-param>

<name>resources</name>

<value>.,nombreHost.nombreOrg.com,nombreHost.nombreOrg.com/jobmanager-pbs</value>

</init-param>

Go to top