Conclusions

El gestor de recursos OpenPBS es el sistema de gestión de colas de trabajos parecido a sus competidores Platform LSF o GridEngine.

Un gestor de recursos distribuidos permite que varios usuarios, grupos y proyectos puedan trabajar juntos usando una infraestructura compartida como, por ejemplo, un clúster de computación de alto rendimiento.

En el entorno de OpenPBS la existencia de colas no tiene mucha importancia para el usuario. El usuario simplemente tiene que especificar los recursos que requiere su trabajo y

OpenPBS se ocupa en colocarlo en la cola de trabajos más adecuada.

3.1.1 Funcionamiento.

OpenPBS presenta como funcionamiento principal los siguientes puntos resumidos a continuación:

 Pone trabajos en colas y planifica su ejecución junto con MAUI.

 Organiza los trabajos con el nodo de ejecución más apropiado.

proyecto B).

En el caso particular de un usuario que está interesado en el envío de determinado trabajo, el sistema OpenPBS se rige por los siguientes pasos:

1. Aceptar la solicitud de ejecutar un trabajo (job) del usuario. 2. Poner el trabajo en un área pendiente (cola).

3. Manda el trabajo desde el área pendiente al nodo más adecuado. 4. Gestiona el trabajo mientras se ejecuta.

5. Devuelve los resultados y guarda la información sobre la ejecución (accounting) en cuanto termine el trabajo.

Como modo de ejemplo en el caso de requerimientos de recursos de un trabajo se muestra lo siguiente:

 En el caso de que el trabajo requiera una licencia de software.

 El trabajo prefiere un nodo con una gran cantidad memoria.

 Un trabajo requiere un nodo con una gran cantidad de memoria.

 Un trabajo requiere un nodo con GPU.

 Un trabajo paralelo requiere 500 núcleos CPU.

Para la utilización de OpenPBS se hace necesaria la utilización de determinados comandos capaces de lograr la correcta ejecución del mismo. (Ver Anexo V)

3.1.2 Entorno del Usuario (Modules).

Diferentes programas como aplicaciones, compiladores o librerías requieren que las correspondientes variables de entorno estén definidas para que se ejecuten correctamente. Típicas variables del entorno que se definen en un Shell de Linux son por ejemplo el PATH

donde se encuentran los binarios de programa, el MANPATH que indica donde se encuentran las páginas de manuales o el LD_LIBRARY_PATH que indica caminos

del programa.

Es posible definir estas variables de forma permanente en el perfil del usuario pero eso suele crear problemas cuando se desea usar diferentes versiones de una aplicación, usar una vez el compilador gcc y en otro momento un compilador de Intel o crear varias versiones de programas con diferentes librerías MPI.

La herramienta modules permite el cambio rápido de un entorno a otro debido a que permite cargar o borrar las variables necesarias para un programa ejecutando un comando sencillo y avisa si hay conflictos entre un entorno ya definido con otro que el usuario quiere cargar. También es posible que un módulo cargue otros módulos para facilitar el uso y poder crear paquetes de módulos.

El clúster consta con una lista de los programas que posee y los que por necesidades determinadas se le van incorporando, para acceder a estos programas se debe utilizar

module load nombre_módulo. Muchos de los programas listados tienen múltiples versiones, para ver las que se encuentran disponibles se trabaja con, module avail.

La Tabla II: Comandos básicos en la interfaz del clúster:

module avail Muestra los módulos de entornos de programas disponibles

moduleload<prog> Carga el entorno del programa <prog> de la versión por defecto

moduleload<prog>/ <vers> Carga el entorno del programa <prog> de la versión <vers>

module list Muestra los módulos cargados actualmente module unload<prog>/<vers> Quita el entorno del <prog>/<vers>

Los usuarios no pueden conectarse a los nodos computacionales, por lo que la ejecución de trabajos en los nodos computacionales tiene que realizarse, obligatoriamente, a través del sistema de colas Torque/PBS. El sistema de colas registrará por orden cada una de las solicitudes enviadas y las emitirá, para su ejecución en los nodos computacionales, cuando estén disponibles los recursos requeridos.

El envío de trabajos se realiza a través del comando qsub, cuyo argumento obligatorio es el nombre de un script de shell. El script tiene que disponer de permisos de ejecución. Dentro del script, el usuario debe indicar las acciones que se realizarán en los nodos, una vez que los recursos requeridos estén disponibles. (Ver Anexo VI)

Las opciones de configuración de Torque/PBS se dan en gran medida al sistema de colas PBS el cual permite a los usuarios configurar diferentes aspectos de la ejecución de los trabajos. Las instrucciones de configuración Torque/PBS se indican en los scripts a través de líneas que comienzan (sin espacios) con #PBS. También es posible indicar estas opciones directamente como argumentos de qsub en la línea de comandos. (Ver Anexo VII) Por defecto, el entorno de ejecución del sistema Torque/PBS define algunas variables de entorno que pueden ser utilizadas dentro de los scripts. Los scripts son los encargados de mandar al clúster las instrucciones a seguir a partir de las exigencias requeridas por el archivo a codificar y el trabajo a enviar. (Ver Anexo VIII)

3.1.4 Colas del sistema.

Existen 4 colas del sistema limitadas por el tiempo, cantidad de nodos y núcleos a emplear y una cola de usuario (Default) que se encarga de enrutar para las colas del sistema de acuerdo a las necesidades de los trabajos. Nunca el usuario puede acceder directamente a las colas del sistema.

Se ha definido una cola llamada TEST para ejecuciones de pruebas con nodos de bajos recursos en la que se pueden realizar ensayos para verificar que todo lo programado funcione. (Ver Anexo IX)

a la cola del sistema adecuada, teniendo en cuenta los parámetros: Tiempo (walltime), número de nodos (nodes) y número de cores (npp).

 La cola test es de acceso directo, esto quiere decir que los usuarios pueden acceder a ella de forma directa utilizando el parámetro #PBS -q test dentro del script de ejecución del trabajo. Es una cola con tiempo máximo de ejecución de 2 horas, que utiliza nodos de bajos recursos, pensada para que los usuarios puedan probar los scripts antes de lanzarlos.

 Máxima cantidad de trabajos que un usuario puede ejecutar concurrentemente en cada cola.

Existen ciertas limitaciones con respecto a las colas que se resumen a continuación:

 No se deben ejecutar los trabajos directamente en las colas de ejecución, siempre debe utilizarse la cola Default.

 Hay un límite sobre la cantidad de trabajos por usuario en cada cola.

La cola test, debe ser utilizada para el desarrollo, prueba y depuración de códigos. Los ciclos de producción no están permitidos en la cola Test. Las cuentas de usuarios están sujetas a suspensiones si se determina que se utiliza la cola Test para la informática de la producción. En particular, no se permite el trabajo "encadenamiento" en la cola de depuración. El encadenamiento se define como el uso de un script por lotes que ejecute otro

script por lotes.

Los trabajos bloqueados por un tiempo superior a las 36 horas serán eliminados del sistema.

3.1.5 Herramientas de monitoreo.

El HPC (Portal of High Performance Cluster) presenta dos herramientas a utilizar: GANGLIA e ICINGA de las cuales la primera es la implementada en el trabajo que se desarrollará. (Ver Anexo IX )

GANGLIA no es más que un sistema de monitoreo distribuido escalable para los sistemas de computación de alto rendimiento, como los clústers y grids. Se basa en un diseño jerárquico dirigido a las federaciones de clústers. Aprovecha las tecnologías ampliamente

XDR (eXternal Data Representation) para el transporte de datos compacto, portátil y RRDtool (Round Robin Database Tool) para el almacenamiento de datos y visualización. Utiliza los datos cuidadosamente diseñando estructuras de datos y algoritmos para lograr bajos gastos generales por nodo y alta concurrencia. La aplicación es considerada robusta, ha sido portada a un amplio conjunto de sistemas operativos y arquitecturas de procesamiento, se encuentra actualmente en uso en miles de grupos de todo el mundo. Se ha utilizado para vincular grupos a través de los campus universitarios y en todo el mundo y puede escalar para llegar a manejar grupos de hasta 2000 nodos.