guía de usuario de magerit -...

CeSViMa, Facultad de Informática (UPM) • Campus de Montegancedo • Boadilla del Monte • 28660, Madrid (España)

Guía de usuario de Magerit

Enero 2008

Versión 1.2

Esta página se ha dejado en blanco intencionadamente.

CeSViMa, Facultad de Informática (UPM) • Campus de Montegancedo • Boadilla del Monte • 28660, Madrid (España)

Centro de Supercomputación y Visualización de Madrid

Guía de usuario de Magerit

Copyright © 2006-2007 Centro de Supercomputación y Visualización de Madrid, Universidad Politécnica de Madrid

Todos los derechos reservados.

El contenido de este documento es propiedad del CeSViMa (UPM). Ninguna parte de este documento puede ser

reproducida, almacenada, transmitida o utilizada para un uso distinto para el que fue suministrada de manera

alguna ni por ningún medio, ya sea mecánico, digital, óptico o químico, sin permiso previo expreso del Centro,

excepto en citas o reseñas siempre que se mencione la fuente de las mismas.

Guía de usuario de Magerit – i –

Contenidos

CONTENIDOS ............................................................................................. I

ÍNDICE DE FIGURAS ................................................................................... III

ÍNDICE DE TABLAS ...................................................................................... V

CAPÍTULO 1. INTRODUCCIÓN ........................................................................ 1

1.1. Última versión de la documentación ............................................................................... 1

1.2. Contactar con el CeSViMa ............................................................................................... 2

1.3. Agradecimientos en publicaciones .................................................................................. 2

CAPÍTULO 2. VISIÓN GENERAL ...................................................................... 3

2.1. Conexión a Magerit .......................................................................................................... 4

2.1.1. Cambio de contraseña ................................................................................................................. 5

2.2. Usuarios y grupos ............................................................................................................ 5

2.3. Sistemas de ficheros ........................................................................................................ 6

2.3.1. Gestión de cuotas de disco .......................................................................................................... 7

2.4. Transferencia de ficheros ................................................................................................ 8

CAPÍTULO 3. EJECUCIÓN DE TRABAJOS........................................................... 9

3.1. Colas disponibles ............................................................................................................. 9

3.2. Resumen de órdenes ..................................................................................................... 10

3.3. Definición del trabajo ..................................................................................................... 11

3.3.1. Directivas y variables ................................................................................................................ 12

3.3.2. Trabajos por pasos (steps) ........................................................................................................ 13

Contenidos

– ii – Guía de usuario de Magerit

CAPÍTULO 4. PREGUNTAS FRECUENTES (FAQ) .............................................. 17

4.1. Gestión de trabajos ........................................................................................................ 17

4.2. Sistema de ficheros ....................................................................................................... 18

4.3. Compilación .................................................................................................................. 19

4.4. Errores típicos ...............................................................................................................20

4.5. Miscelánea .....................................................................................................................20

CAPÍTULO 5. SSH EN WINDOWS ................................................................. 21

5.1. PuTTy: cliente SSH ........................................................................................................ 21

5.2. Descarga de ficheros ...................................................................................................... 23

5.3. Conexiones gráficas ....................................................................................................... 23

Guía de usuario de Magerit – iii –

Índice de figuras

Figura 1 Esquema general del supercomputador ...................................................................... 4

Figura 2 Arquitectura de red ..................................................................................................... 6

Figura 3 Plantilla de un Job Command File ............................................................................. 11

Figura 4 Plantilla de un Step Job Command File .................................................................... 15

Figura 5 Configuración de PuTTY para conectarse a Magerit ................................................. 22

Figura 6 Configuración de WinSCP para intercambiar ficheros con Magerit ......................... 23

Guía de usuario de Magerit – v –

Índice de tablas

Tabla 1 Estados de un trabajo .................................................................................................. 10

Tabla 2 Variables de entorno definidas por LoadLeveler ....................................................... 12

Tabla 3 Variables disponibles en las directivas de trabajo ...................................................... 12

Guía de usuario de Magerit – 1 –

Capítulo 1. Introducción

Esta Guía de usuario de Magerit, supercomputador perteneciente al Centro de Super-

computación y Visualización de Madrid (CeSViMa), proporciona la información bási-

ca que precisa un nuevo usuario, ya familiarizado con los sistemas Unix/Linux, para

utilizar el sistema dirigiéndolo en sus primeros pasos.

En este documento se proporciona una visión global del sistema y los elementos que

lo componen. También se describen los recursos disponibles en el supercomputador,

cómo utilizarlo para investigación, etc.

Posteriormente se describe cómo acceder al sistema, con sencillos ejemplos de cómo

configurar el envío de trabajos a ejecutar y realizar las acciones más habituales. Tam-

bién se incluye un pequeño resumen de las preguntas más habituales cuando se utili-

za el sistema.

Finalmente, se indica cómo configurar el entorno de trabajo para poder conectarse

correctamente a Magerit desde un entorno Microsoft Windows, incluyendo la instala-

ción y configuración de un cliente de SSH y un servidor gráfico X.

1.1. Última versión de la documentación

Debido a las características del sistema, es muy difícil mantener la documentación

constantemente actualizada. La información más completa es esta guía de iniciación.

La última versión estará disponible en la página web del CeSViMa

(www.cesvima.upm.es).

Asimismo, la documentación más reciente, noticias y cualquier otra información de

interés se encontrarán disponibles en dicha página web.

http://www.cesvima.upm.es/

Introducción

– 2 – Guía de usuario de Magerit

1.2. Contactar con el CeSViMa

Si tras la lectura de la documentación proporcionada existen dudas o surgen proble-

mas durante el uso del supercomputador, se puede contactar con el Centro de Aten-

ción a Usuarios en la dirección [email protected]. En el mensaje se debe

indicar, de la forma más clara posible:

La duda o problema surgido

Día, fecha y/o hora aproximados en la que se detectó el problema

Toda la información extra de la que se disponga, como el identificador del tra-

bajo, mensajes de error, ficheros de log, etc.

En el menor tiempo posible, y por correo electrónico, se atenderá su consulta.

1.3. Agradecimientos en publicaciones

Los usuarios necesariamente deberán incluir un agradecimiento explícito en todas las

publicaciones relacionadas con el proyecto para el que ha servido de soporte CeSVi-

Ma, utilizando la siguiente fórmula:

El autor con agradecimiento reconoce los recursos informáticos, conocimientos

técnicos y asistencia proporcionada por el Centro de Supercomputación y Visua-

lización de Madrid (CeSViMa) y la Red española de Supercomputación.

O su equivalente en inglés:

The autor thankfully acknowledges the computer resources, technical expertise

and assistance provided by the Centro de Supercomputación y Visualización de

Madrid (CeSViMa) and the Spanish Supercomputing Network.

mailto:[email protected]


Capítulo 2. Visión general

El supercomputador Magerit consta de 1200 eServer BladeJS20. Cada uno de ellos

dispone de 2 microprocesadores PPC de 2.2 GHz, 4GB de memoria RAM y 40GB de

almacenamiento local en disco. El sistema operativo utilizado es SuSe SLES9 (Linux

2.6.5).

Además de la capacidad local de cada nodo, se dispone de 65TB de almacenamiento

proporcionado por 265 discos de 250GB en RAID. Sobre estos discos se utiliza un sis-

tema General Parallel File System (GPFS)1 accesible desde cualquier nodo (ver sec-

ción 2.3 más adelante).

Magerit dispone de dos tipos diferentes de nodos:

Interactivos o de login: Estos nodos tienen habilitado el acceso desde el exte-

rior mediante SSH y son utilizados para compilar, enviar y monitorizar los

trabajos en el supercomputador. En estos nodos no se permite la ejecución de

cómputos que serán eliminados de forma automática.

Cómputo: encargados de realizar los trabajos enviados desde los nodos inter-

activos a través del gestor de colas. Estos nodos se encuentran completamente

aislados sin conexión desde el exterior.

La interconexión del CeSViMa con el exterior se realiza a través de RedIRIS mediante

enlaces de 1Gbps y 10Gbps. Las conexiones internas de los nodos se realizan median-

te dos redes diferentes:

1 Se trata de un sistema de ficheros de alto rendimiento con tolerancia a fallos desarrollado por IBM.

Visión general


Red Myrinet: es una red de fibra óptica y alto rendimiento utilizada para las

comunicaciones de las aplicaciones paralelas. Proporciona un ancho de banda

de 2Gbps con latencias de 3μs.

Red Gigabit: utilizada por los nodos para cargar el sistema operativo, comu-

nicaciones del sistema de ficheros GPFS y labores de gestión y administración

evitando la sobrecarga de la red Myrinet.

Figura 1 Esquema general del supercomputador

2.1. Conexión a Magerit

Para poder acceder al sistema es necesario disponer de un identificador de usuario

junto con su clave de acceso asociada, que se generarán al crear las cuentas de usua-

rio tras recibir las solicitudes.

El acceso al sistema se realiza mediante un conjunto de nodos denominados interac-

tivos. Estos nodos tienen habilitado el acceso desde el exterior mediante el protocolo

Visión general


SSH2 y permiten utilizar consolas alfanuméricas o la interfaz gráfica KDE3. El número

de nodos interactivos varía en función de las necesidades del servicio, accediéndose a

ellos mediante la dirección magerit.cesvima.upm.es que redirigirá automáticamente a

uno cualquiera de los nodos disponibles.

2.1.1. Cambio de contraseña

El cambio de la palabra clave se realiza única y exclusivamente en el nodo denomina-

do login1 (una vez iniciada sesión en cualquiera de los nodos de acceso es posible

conectarse mediante SSH). Para realizar el cambio se utiliza el habitual mandato

passwd.

La nueva clave tiene únicamente validez inmediata en el nodo que ha realizado el

cambio (login1). El cambio de clave tiene una demora de propagación a los restan-

tes nodos interactivos de un máximo de 15 minutos, intervalo en el que se podrán ob-

servar problemas para iniciar una nueva sesión.

2.2. Usuarios y grupos

Los usuarios disponen de una cuenta única en el sistema que pertenecerá a un grupo,

relacionado con la entidad en la que desempeña su labor, con la forma A00000. El

código de usuario estará identificado con el DNI del usuario precedido de la letra ’u’

(u87654321).

Asimismo, cada proyecto dispondrá un de un grupo específico que tendrá un identifi-

cador único con la forma A12345678. Cada uno de los usuarios que colaboren con el

proyecto estará asignado al grupo de dicho proyecto.

2 El resto de los protocolos estándar (telnet, FTP...) se encuentran deshabilitados por motivos de segu-

ridad. En el Capítulo 5 se dispone de más información acerca de cómo utilizar el protocolo SSH en

Windows.

3 Esta funcionalidad podrá desactivarse por sobrecarga en los nodos interactivos

login as: userlogin

Password: ********

+------------------------------------------------------------+

| |

| Welcome to Magerit (CeSViMa) |

| ============================== |

| |

| Please, contact [email protected] for questions |

| |

| www.cesvima.upm.es |

+------------------------------------------------------------+

Login?:~ >

Visión general


2.3. Sistemas de ficheros

Todos los nodos tienen acceso a un sistema de ficheros compartido con una capaci-

dad total de unos 65 TB. Este espacio se distribuye entre cuatro sistemas de ficheros

diferentes, cada uno de ellos pensado para distintos fines:

/gpfs/home en el que se encuentran los directorios personales de los usuarios4. Este

directorio puede utilizarse para almacenar su trabajo y datos personales aun-

que tiene activado el sistema de cuotas que limita su uso a 10 GB.

Figura 2 Arquitectura de red

/gpfs/projects proporciona un espacio compartido por todos los miembros del grupo,

por lo que puede utilizarse para almacenar los datos o código que sean usados

por múltiples usuarios del mismo proyecto.

4 El sistema está montado en dos puntos, siendo accesible tanto en /home como en /gpfs/home

Visión general


Como en el caso anterior, su uso está controlado mediante un sistema de cuo-

tas asignadas a cada grupo, es decir, se considera el total de espacio usado in-

dependientemente del miembro que lo utiliza. La coordinación del uso de este

espacio de almacenamiento recae sobre el investigador principal.

/gpfs/scratch es el espacio de almacenamiento masivo y temporal de la máquina.

Cada usuario puede utilizar este espacio para almacenar información necesa-

ria durante la ejecución de los trabajos.

Al igual que los otros dos sistemas, el espacio puede ser controlado por cuotas

a nivel de grupo. Además, los archivos con una antigüedad superior a una se-

mana son eliminados automáticamente de este sistema de ficheros.

/gpfs/apps contiene las aplicaciones y bibliotecas que ya se encuentran instaladas en

Magerit. Para solicitar la instalación de nuevas aplicaciones es necesario con-

tactar con el centro de atención a usuarios ([email protected]).

Las modificaciones especiales sobre aplicaciones no estarán disponibles, de

forma general, en la zona pública y deberán instalarse en la zona personal del

usuario o en la zona compartida de proyectos.

Las aplicaciones sin limitaciones en su uso estarán disponibles para todos los

usuarios del sistema mientras que las aplicaciones con restricciones en su uso

estarán en directorios privados con control de acceso. Si un usuario desea uti-

lizar una aplicación con restricciones de licencia deberá enviarnos una copia

de la licencia para que se le permita el acceso.

No se realiza ningún tipo de copia de seguridad (backup) de los datos de ninguno de

los sistemas de ficheros por lo que es responsabilidad de cada usuario y/o investiga-

dor principal realizar y gestionar sus propias copias de seguridad.

2.3.1. Gestión de cuotas de disco

Algunos sistemas de ficheros tienen habilitado el control de uso mediante un sistema

de cuotas. Las cuotas pueden establecerse de forma individual para cada usuario (se

contabilizan todos los ficheros cuyo dueño es el usuario) o a nivel de grupo (se conta-

bilizan todos los ficheros de los miembros del grupo independientemente del propie-

tario del mismo).

En el primer caso, cuotas individuales, cada usuario deberá gestionar su espacio dis-

ponible, mientras que en el segundo será el jefe de proyecto el encargado de gestionar

de forma apropiada dicho espacio.

Para consultar los límites de cuota asignados se puede utilizar el habitual mandato

quota: la cuota de usuario mediante quota -v y la de grupo mediante quota -v

-g A12345678 indicando el identificador de grupo que se desea utilizar.

Si un usuario o proyecto necesita una capacidad de almacenamiento mayor que la

asignada, el jefe del proyecto deberá solicitar dicha ampliación en la dirección appli-

[email protected], justificando los motivos y la capacidad que se precisa.




Visión general


2.4. Transferencia de ficheros

Magerit dispone de diversos servicios diferentes de transferencia de ficheros, tanto

entre el sistema y los ordenadores de los usuarios como entre dos o más sitios de la

RES.

Los métodos de transferencia seguros (scp y sftp) están habilitados en todos los

nodos de login. Estos métodos cifran toda la información que se intercambia entre los

dos sitios. Un ejemplo básico de uso sería:

u@local> scp [login]@mag-ftps.cesvima.upm.es:/remote local

u@local> scp local [login]@mag-ftps.cesvima.upm.es:/remote

Y, en el caso de usar sftp:

u@local> sftp login]@mag-ftps.cesvima.upm.es

sftp> put localfile

sftp> get localfile

Para transferencias de grandes volúmenes de información, la sobrecarga que supone

el cifrado produce que las transferencias no sean muy eficientes. En estos casos se re-

comienda el uso del protocolo ftps. Este protocolo cifra la información de autentica-

ción pero el intercambio de datos se realiza sin cifrar. De esta forma se incrementa

notablemente el rendimiento de las transferencias.

Para utilizar este protocolo es necesario disponer de un cliente adecuado que se co-

necte a la dirección mag-ftps.cesvima.upm.es. El cliente recomendado es gftp

(http://gftp.seul.org/) que ya se encuentra instalado en magerit en /gpfs/apps/ftps.

El cliente debe estar compilado habilitando el soporte de SSL:

./configure –prefix=[your_prefix] –with-ssl

make

make install

También es necesario deshabilitar la verificación del certificado estableciendo la op-

ción verify_ssl_peer 0 en el fichero ~/.gftp/gftprc.

Tras realizar esta configuración, sería posible realizar una sesión como la siguiente:

u@local> gftp-text ftps://[login]@mag-ftps.cesvima.upm.es

gftp> lcd [your path]

gftp> cd /gpfs/projects/A00000

gftp> mget *

gftp> mput localfile

gftp> quit

http://gftp.seul.org/


Capítulo 3. Ejecución de trabajos

La ejecución de trabajos en el sistema se gestiona, única y exclusivamente, mediante

el gestor de colas LoadLeveler. Este gestor de colas permite ejecutar en el supercom-

putador tanto trabajos secuenciales como paralelos, reservando los recursos (nodos)

que necesiten los distintos trabajos. Este proceso dependerá de los recursos solicita-

dos por el trabajo, la disponibilidad de dichos recursos en la máquina y las políticas

de ejecución que se hayan definido.

Para poder enviar un trabajo al supercomputador es necesario definirlo en un Job

Command File especificando los recursos que deben reservarse. LoadLeveler se en-

cargará de buscar y reservar los recursos indicados entre los disponibles, optimizando

el uso de la máquina y reduciendo el tiempo de espera de los distintos usuarios. En

resumen, el gestor se encarga de maximizar la eficiencia del supercomputador.

Por lo tanto, los pasos para poder ejecutar un trabajo en la máquina se resumen en:

1. Conectarse a uno de los nodos interactivos.

2. Preparar el ejecutable que se desee enviar al supercomputador

3. Preparar la definición del trabajo a enviar.

4. Enviar el trabajo al gestor de colas.

3.1. Colas disponibles

LoadLeveler gestiona un conjunto de colas de trabajos con diferentes características,

que denomina class. Cada una de ellas tiene definidos una serie de límites diferentes

Ejecución de trabajos


(número de tareas, tiempo de ejecución...), por lo que se debe buscar la más adecuada

a las características del trabajo.

Cada usuario tendrá acceso a un conjunto de colas determinado que se puede consul-

tar con el mandato llclass -l. Además, todos los usuarios disponen de acceso a

dos colas especiales:

debug se utiliza únicamente para verificar las aplicaciones antes de mandarlas a las

colas de ejecución definitiva. Cada usuario puede ejecutar procesos en esta co-

la con una duración máxima de 10 minutos.

interactive son trabajos secuenciales que únicamente ejecutan en los nodos interacti-

vos (login) pero no se debe confundir con la ejecución directa de trabajos en

los nodos de acceso. Su uso es muy puntual permitiendo la ejecución de apli-

caciones gráficas, compilación, postproceso, etc.

3.2. Resumen de órdenes

Desde el punto de vista del usuario, LoadLeveler expone una interfaz muy sencilla.

Esta interfaz se resume en las siguientes órdenes:

llclass muestra los distintos tipos de colas que puede utilizar el usuario. Utilizando

la opción -l se mostrará información detallada de los límites de cada una de

ellas.

llcancel suprime un trabajo de la cola de ejecución.

llq muestra el estado de los trabajos de un usuario o grupo (opción -g) en el siste-

ma. Con la opción –l se mostrará información detallada de los mismos.

En el listado se muestran distintos estados del trabajo que se resumen en la

Tabla 1.

llsubmit envía un trabajo para su ejecución.

llw muestra la posición del primer trabajo del usuario que está en la cola de ejecu-

ción.

Para obtener más información de estos mandatos se recomienda consultar las pági-

nas del manual5.

Tabla 1 Estados de un trabajo

Estado Abreviatura Estado Abreviatura

Canceled CA Starting ST Completed C Submission Error SX Complete Pending CP System Hold S Deferred D System User Hold HS Idle I Terminated TX NotQueued NQ User Hold H Not Run NR Vacated V

5 http://www.redbooks.ibm.com/abstracts/sg246038.html

http://www.redbooks.ibm.com/abstracts/sg246038.html



Estado Abreviatura Estado Abreviatura

Pending P Vacate Pending VP Rejected X Checkpointing CK Reject Pending XP Preempted E Removed RM Preempt Pending EP Remove Pending RP Resume Pending MP Running R

3.3. Definición del trabajo

La definición de un trabajo se realiza mediante un fichero de texto que se denomina

Job Command File. Este fichero es al mismo tiempo un script que se encargará de

iniciar la ejecución del trabajo. A este fichero de órdenes (script) se le añaden directi-

vas especiales que indican el tipo de trabajo y los recursos que precisa. El gestor Lo-

adLeveler sólo procesará las directivas propias, que comienzan por #@, mientras que

el resto de las líneas se considerarán comentarios.

Figura 3 Plantilla de un Job Command File

#!/bin/bash

# Start job description ---------------------------------------------

#@ group = [A12345678]

#@ class = [class_name]

#@ job_type = [parallel|serial]

#@ initialdir = ~/Documents/program_dir

#@ output = res_dir/program.$(schedd_hostname).$(jobid).$(stepid).out

#@ error = res_dir/program.$(schedd_hostname).$(jobid).$(stepid).err

#@ restart = no

#@ requirements = (Feature == "myrinet")

#@ total_tasks = number of tasks

#@ blocking = unlimited

#@ wall_clock_limit = hh:mm:ss

#@ queue

# End job description -----------------------------------------------

# Start execution ---------------------------------------------------

# Environment

export MP_EUILIB=gm

export OBJECT_MODE=64

export MP_RSH=ssh

# Reserved nodes

NPROCS=‘cat ${LL_MACHINE_LIST} | wc -l‘

# Run our program

mpirun -np ${NPROCS} -machinefile ${LL_MACHINE_LIST} ./program

# End execution -----------------------------------------------------

La plantilla de definición de un trabajo (Figura 3) se compone de:



La primera línea del script indica qué shell debe utilizarse para interpretar la

zona ejecutable del mismo.

Seguidamente se presentan todas las directivas que definen el trabajo como

comentarios del script (precedidos de #).

Finalmente se dispone del código ejecutable que prepara, lanza la ejecución y

recupera los resultados.

Este código puede utilizar las variables de entorno que define LoadLeveler

(Tabla 2).

En esta parte es muy importante la variable $LL_MACHINE_LIST en la que

encuentra el listado de nodos asignados al proceso. En la Figura 3 se muestra

el modo recomendado de utilizar dicha variable para lanzar una ejecución.

Tabla 2 Variables de entorno definidas por LoadLeveler

Variable Descripción

LOADL_STEP_CLASS Clase del trabajo LOAD_STEP_ID Identificador del trabajo LOAD_STEP_INITDIR Directorio de trabajo LOAD_STEP_OUT Redirección de salida estándar LOAD_STEP_ERR Redirección de error estándar LOAD_STEP_OWNER Propietario del trabajo LOAD_STEP_TYPE Tipo de trabajo (SEQUENTIAL o PARALLEL) LL_MACHINE_LIST Ruta al fichero con el listado de nodos reservados para la ejecución LL_MASTER_NODE Nodo maestro del trabajo

3.3.1. Directivas y variables

Las directivas permiten indicar al LoadLeveler las características del trabajo que se

desea ejecutar. Todas las directivas tienen el formato #@ directiva [= valor] y

pueden utilizar las variables descritas en la siguiente tabla:

Tabla 3 Variables disponibles en las directivas de trabajo

Variable Descripción

$(host) Nombre de la máquina donde ejecuta $(domain) Dominio de la máquina donde ejecuta $(schedd_host) Nombre de la máquina que planifica el trabajo $(schedd_hostname) Nombre y dominio de la máquina que planifica el trabajo $(jobid) Identificador único del trabajo $(stepid) Número de paso de este trabajo

queue es una directiva especial que indica que debe enviarse el trabajo. Debe ser la

última directiva de LoadLeveler que aparezca en el fichero.

job_type=tipo-trabajo indica si se trata de trabajos secuenciales (serial) o parale-

los (parallel).

class=nombre clase indica a qué cola debe enviarse el trabajo. Mediante esta directi-

va se determina implícitamente los límites máximos del trabajo que se ejecu-

ta.



initial_dir=ruta directorio permite establecer el directorio de trabajo del script. To-

das las rutas especificadas (output, error...) se consideran relativas a este di-

rectorio inicial.

output=fichero indica dónde se redirige la salida estándar de todos los procesos. La

actualización de esta redirección no es inmediata pudiendo retardarse algunas

horas.

error=fichero indica dónde se redirige la salida de error de todos los procesos. La ac-

tualización de esta redirección es prácticamente inmediata.

total_task=N indica el número de procesos (CPUs) que se necesitan. El gestor de co-

las se encargará de buscar y reservar CPUs libres hasta completar este núme-

ro.

node_usage=compartición permite reservar nodos en ejecución exclusiva. Se reco-

mienda utilizar la opción shared que permite que procesos de distintos tra-

bajos utilicen los recursos del mismo nodo (cada uno utiliza una CPU por

ejemplo).

Si un trabajo utiliza el valor not_shared todos los recursos del nodo se re-

servará en exclusiva para este trabajo y ningún otro podrá ejecutar simultá-

neamente. Esta opción puede incrementar sensiblemente el tiempo de espera

en cola del proceso mientras se logra la reserva exclusiva de los nodos necesa-

rios por lo que no se recomienda su uso salvo necesidad.

requirements=expresion permite especificar las necesidades especiales que deben

cumplir los nodos, como versiones de programas, hardware especial... Como

en Magerit todos los nodos son idénticos, la única opción que debe especifi-

carse es (Feature == "myrinet").

blocking=unlimited|2 Esta directiva indica cuantos procesadores deben asignarse en

cada nodo. En Magerit indicar el valor 2 significa reservar los nodos en exclu-

siva con lo que se puede incrementar notablemente el tiempo de espera hasta

empezar la ejecución.

restart=no Indica que no se desea que se vuelva a encolar el trabajo de forma au-

tomática si éste es desalojado durante la ejecución. Esto evita que se consu-

man horas de cómputo sin control del usuario.

wall_clock_limit=hh:mm:ss Especifica el tiempo máximo que el proceso va a estar

ejecutando.

Si el proceso supera el tiempo indicado, el gestor de colas abortará su ejecu-

ción.

3.3.2. Trabajos por pasos (steps)

Los trabajos por pasos permiten ejecutar una secuencia de acciones con dependencias

entre ellas o conjuntos de pruebas individuales con diferentes datos de entrada. To-

dos los pasos se definen en un único job command file aunque cada uno de ellos pue-

de solicitar diferentes recursos y ejecutar distintas acciones.



La definición de un trabajo por pasos no difiere sustancialmente de un trabajo nor-

mal: En un trabajo normal, existe un único bloque de directivas de LoadLeveler que

finalizan con la directiva #@ queue , mientras que en los trabajos por pasos exis-

tirán varios bloques de directivas, cada uno asociado a un paso.

Generalmente, la configuración de directivas se hereda entre los distintos bloques

siendo únicamente imprescindible una directiva #@ queue por cada paso. Las únicas

directivas que no se heredan en el caso de trabajos paralelos son job_type y to-

tal_tasks.



Figura 4 Plantilla de un Step Job Command File

#!/bin/bash

# Start first step description --------------------------------------

#@ group = [A12345678]

#@ class = [class_name]


#@ initialdir = ~/Documents/program_dir

#@ output = res_dir/program.$(schedd_hostname).$(jobid).$(stepid).out

#@ error = res_dir/program.$(schedd_hostname).$(jobid).$(stepid).err

#@ restart = no

#@ requirements = (Feature == "myrinet")

#@ total_tasks = number of tasks

#@ blocking = unlimited

#@ wall_clock_limit = hh:mm:ss

#@ queue

# End first step description ----------------------------------------

# Start second step description -------------------------------------

#@ step_name = post

#@ dependency = (work == 0)


# class inherit

# initialdir inherit

# output inherit

# error inherit

# restart inherit

# requirements inherit

# blocking inherit

# wall_clock_limit inherit

#@ total_tasks = number of tasks [If job_type = parallel]

#@ queue

# End second step description ---------------------------------------

# Start execution ---------------------------------------------------

# Environment

export MP_EUILIB=gm


export MP_RSH=ssh

# Reserved nodes

NPROCS=‘cat ${LL_MACHINE_LIST} | wc -l‘

# Run our program

case $LOADL_STEP_NAME in

work) mpirun -np ${NPROCS} -machinefile ${LL_MACHINE_LIST} ./program

;;

post) mv output $PERM

;;

*) echo "Nothing to do for $LOADL_STEP_NAME"

;;

esac

# End execution -----------------------------------------------------



En los trabajos por pasos aparecen dos nuevas directivas:

dependency= (step_name op exit_status) permite establecer una dependencia que

controla el inicio del trabajo. Es posible indicar múltiples condiciones de de-

pendencia utilizando los operadores y-lógico (&&) y o-lógico (||).

Las dependencias se especifican comparando el nombre del paso del que de-

pende y qué código de finalización que retorna. Se pueden utilizar todos los

operadores de comparación: ==, !=, <, >, <=, >=

Existen dos códigos de finalización especiales asignados automáticamente por

el LoadLeveler para indicar algunas condiciones de su estado:

CC_NOTRUN, código numérico 1002, que indica que el trabajo aún no se ha

ejecutado debido a que no se cumplen sus dependencias

CC_REMOVED, código numérico 1001, que indica que el trabajo se ha elimi-

nado del sistema. Por ejemplo, cuando se cancela (llcancel)

step_name permite definir un nombre simbólico al trabajo para su referencia, habi-

tualmente, en una directiva dependency.


Capítulo 4. Preguntas frecuentes (FAQ)

4.1. Gestión de trabajos

He enviado un trabajo al sistema ¿Cómo puedo saber el estado en el que se en-

cuentra?

Cada usuario puede ver sus trabajos enviados al sistema mediante la instruc-

ción llq, y los enviados por su grupo mediante llq -g. Es posible generar

un informe más detallado añadiendo la opción -l (llq -l | less).

Mi trabajo queda encolado pero no entra a ejecutar ¿estoy haciendo algo mal?

En Magerit se ejecutan trabajos de múltiples usuarios que se planifican de

forma batch. Esto hace que haya trabajos de otros usuarios en el sistema y no

se pueda planificar inmediatamente.

Cada uno de los usuarios puede ver únicamente sus trabajos o los de su grupo.

Es posible conocer qué posición ocupa nuestro primer trabajo en la cola glo-

bal (considerando todos los usuarios) mediante el mandato llw, aunque este

puesto puede variar dependiendo de múltiples circunstancias.

¿Puedo hacer que mi trabajo esté menos tiempo esperando?

El trabajo puede especificar el tiempo máximo que utilizará mediante la direc-

tiva #@ wall_clock_limit=hh:mm:ss. De esta forma será más fácil que el

planificador pueda poner en ejecución un trabajo que precisa una ventana de

consumo más pequeña.

Preguntas frecuentes (FAQ)


Sin embargo, el uso de esta directiva puede ser negativo. Cuando se cumple el

tiempo especificado, el sistema forzará el fin de la ejecución independiente-

mente del estado en el que se encuentre. Por ello se recomienda usar una hol-

gura de seguridad al especificar el tiempo.

¿Cuál es la mejor forma de ejecutar varios trabajos que tienen dependencias entre

ellos?

Existen dos formas de hacerlo. La primera es que cada trabajo encole los tra-

bajos que dependen de él (el script del job file acaba con un llsubmit

<trabajo dependiente>). Otra forma es definir steps en el job file como

se indica en la sección 3.3.2.

¿Cuál es la mejor forma de ejecutar un conjunto de pruebas con múltiples combi-

naciones de parámetros de entrada?

En este caso se puede mandar un trabajo por cada combinación de paráme-

tros a ejecutar o definir steps en el job file como se indica en la sección 3.3.2.

La diferencia es la gestión siendo más sencillo controlar múltiples steps (se

envía una única vez).

4.2. Sistema de ficheros

¿Dónde puedo almacenar información compartida por los usuarios de mi proyec-

to?

Cada proyecto tiene un espacio asignado en /gpfs/projects. Este directo-

rio es accesible por todos los miembros de dicho proyecto y es el sitio indicado

para almacenar ficheros de datos, resultados, librerías o programas que utilice

todo el grupo.

Si es necesario almacenar grandes cantidades de información es necesario

ponerse en contacto con el equipo de administración.

¿Dónde puedo almacenar información temporal?

Cada proyecto dispone de un espacio en /gpfs/scratch para almacenar in-

formación temporal durante la ejecución del programa. Este sistema de fiche-

ros tiene unos límites de cuota elevados aunque, en caso de saturación, se bo-

rran los ficheros con una antigüedad superior a una semana.

Si se precisa almacenan un gran volumen de información o mantener datos

durante un periodo de tiempo mayor es necesario ponerse en contacto con el

equipo de administración.

¿Cómo afecta el uso del sistema de ficheros GPFS al rendimiento de mi aplica-

ción?

El sistema GPFS puede ser un cuello de botella del sistema cuando múltiples

procesos del trabajo precisan acceder a él durante la ejecución. Una posible



mejora del rendimiento es utilizar en su lugar el directorio local temporal

(/scratch).

Cada nodo dispone de un espacio local para almacenar información temporal

en /scratch. Este espacio es local al nodo y, por lo tanto, no es accesible

desde ningún otro nodo ni cuando finalice la ejecución en curso.

La forma habitual de utilizar este espacio consistiría en iniciar la ejecución

copiando la información necesaria al directorio, leer o escribir los datos en di-

cho directorio y volcar la información de los discos locales al GPFS al finalizar

la ejecución.

4.3. Compilación

¿Qué compiladores están disponibles?

Están disponibles dos familias de compiladores completas: IBM XL (xlc, xlC,

xlf, xlf90, xlf95 y las versiones thread-safe) y GNU GCC (gcc, g77, g++).

Para facilitar el uso de estos compiladores en aplicaciones Message Passing

Interface (MPI) se dispone de un conjunto de wrappers (mpicc, mpiCC,

mpif77, mpif90) que, por omisión, utilizan los compiladores de IBM. Este

comportamiento puede modificarse redefiniendo las variables:

export MP_CC=gcc

export MP_CXX=g++


export MP_EUILIB=gm

¿Qué opciones de compilación debería utilizar?

Las opciones recomendadas son:

-O[2|3] -qstrict -qtune=ppc970 -qarch=ppc970 -qcache=auto

Se desaconseja el uso de un nivel de optimización superior a -O3 puesto que

pueden introducir errores importantes en el proceso de compilación.

¿Qué formato de binario se genera por defecto?

Depende del compilador empleado. Si se utilizan las versiones originales de

las dos familias de compiladores IBM XL y GNU GCC generan binarios de 32

bits mientras que los recubrimientos MPI generan versiones de 64 bits.

Para modificar este comportamiento es posible utilizar las opciones -m64 o -

m32 (compiladores IBM XL), -q64 o -q32 (compiladores GNU) o definir la va-

riable OBJECT_MODE (versiones MPI)



4.4. Errores típicos

Al ejecutar el job se obtiene: bad interpreter: No such file or

directory

La codificación del retorno de carro es incorrecta, posiblemente usa la codifi-

cación de Windows, y el sistema o es capaz de interpretarlo.

En este caso basta con ejecutar la orden dos2unix sobre el job file para sub-

sanar el problema.

El trabajo no escribe nada en la salida

El sistema tiene un sistema de buffering activo en la salida estándar para me-

jorar el rendimiento reduciendo el número de operaciones de entrada/salida.

Es posible que la salida quede almacenada en el buffer del nodo que la produ-

ce y no se actualice en el sistema de ficheros.

Al acceder desde otro nodo, éste no verá los datos actualizados, la información

se actualizará en el sistema de ficheros pasado el tiempo o al finalizar el traba-

jo.

Obtengo la línea de error: bash: line 90: ulimit: core file size:

cannot modify limit: Operation not permitted

Se trata de un fallo en los scripts de gestión del trabajo que no afecta al fun-

cionamiento del mismo y está pendiente de solución.

4.5. Miscelánea

¿Dónde se puede conseguir más información?

La principal fuente de información es la página web del CeSViMa

(www.cesvima.upm.es) o enviar un correo electrónico al centro de atención al

usuario [email protected].

Mi pregunta no aparece en este FAQ

Puede que se haya añadido recientemente y esté en la última versión del do-

cumento. Esta información está disponible en la página web

www.cesvima.upm.es.

¿Cómo puedo contactar con el CeSViMa?

Las formas de contacto están en la sección 1.2 (en la página 2) de este docu-

mento.





Capítulo 5. SSH en Windows

El protocolo SSH permite establecer conexiones seguras entre dos ordenadores co-

nectados mediante una red no segura como Internet. Una vez establecida la conexión

entre los dos puntos, todo el tráfico entre ellos es cifrado, por lo que se dificulta la po-

sibilidad de interceptarlo. Este protocolo reemplaza a varios de los protocolos exis-

tentes como telnet, rlogin, ftp...

Magerit únicamente soporta como protocolo de conexión SSH. Sin embargo, es nece-

sario configurar adecuadamente el cliente para permitir conexiones. La mayoría de

las distribuciones Unix/Linux tienen soporte de SSH incluido por lo que no es nece-

sario realizar ningún proceso de configuración. Sin embargo, en el caso de los siste-

mas Windows, es necesario instalar y configurar un par de herramientas.

5.1. PuTTy: cliente SSH

El cliente recomendado para utilizar SSH en sistemas Windows es PuTTy6, un pro-

grama libre cuyo código es la base de prácticamente la totalidad de las aplicaciones

Windows que usan SSH.

Es posible descargar únicamente el ejecutable o un paquete de utilidades completo.

En cualquiera de los dos casos, es necesario crear un perfil con la configuración apro-

piada. Para ello basta con replicar la configuración mostrada en Figura 5 y almace-

narla.

Aunque no es necesario, se aconseja configurar la codificación en UTF-8 (categoría

Window > Translation)

6 http://www.putty.nl/

http://www.putty.nl/

SSH en Windows


Figura 5 Configuración de PuTTY para conectarse a Magerit

SSH en Windows


5.2. Descarga de ficheros

La copia de información en Magerit se debe realizar utilizando el protocolo SSH. Si se

ha instalado el paquete completo de PuTTy se dispone de una aplicación de consola

que permite realizar esta labor indicado el origen y el destino mediante la sintaxis

pscp [email protected]:~/fichero fichero_local

pscp fichero_local [email protected]:~/

También es posible utilizar la aplicación WinSCP7, que es una interfaz gráfica que

permite las transferencias entre la máquina Windows y un servidor remoto. La confi-

guración necesaria para Magerit puede verse en la Figura 6

Figura 6 Configuración de WinSCP para intercambiar ficheros con Magerit

5.3. Conexiones gráficas

Las interfaces gráficas en los sistemas Linux utilizan una arquitectura cliente-

servidor. La pantalla es gestionada por el denominado Servidor X y las distintas apli-

caciones son clientes de dicho servidor. Esta arquitectura permite ejecutar programas

en cualquier máquina y presentar los resultados en el servidor de la máquina local.

Para hacer uso de esta funcionalidad desde Windows necesario instalar un Servidor

X. Existen varios servidores disponibles, siendo una opción muy recomendable

Xming8, una aplicación libre y ligera.

Una vez instalado se debe ejecutar el servidor (la aplicación denominada Xming) an-

tes de utilizar aplicaciones gráficas. Es recomendable configurarlo para que ejecute al

7 http://winscp.net/ 8 http://www.straightrunning.com/XmingNotes/ o http://sourceforge.net/projects/xming

http://winscp.net/eng/docs/lang:es

http://www.straightrunning.com/XmingNotes/

http://sourceforge.net/projects/xming

SSH en Windows


iniciar la sesión. Tras tener el servidor activo en el sistema, es necesario configurar

apropiadamente el cliente SSH para que permita las conexiones X11. Si se utiliza co-

mo cliente de SSH PuTTy, se debe habilitar la opción mostrada en la imagen inferior

de la Figura 5.