Para realizar estas prácticas es necesario conectarse a tecgrid03.epv.uniovi.es con el nombre de usuario que te indique el profesor.

Para entender estas prácticas es interesante que conozcas la arquitectura del grid sobre el que vas a hacer prácticas. Este grid está formado por dos clusters, que vamos a denominar mesa1 y mesa3. Cada cluster tiene su propio gestor de trabajos; en ambos es Condor. Además, cada cluster tiene una máquina con una dirección IP pública y globus instalado para hacer de front-end al cluster. Estos front-ends son tecgrid03.epv.uniovi.es y tecgrid01.epv.uniovi.es. En cada cluster hay otros tres ordenadores además del front-end, denominados mXnY, siendo X el número de mesa e Y un número de 2 a 4. Estas máquinas tienen direcciones privadas.

Para realizar cualquier trabajo en un grid es necesario tener un certificado de usuario. Para solicitarlo, ejecutar la siguiente orden:

$> grid-cert-request

El programa pregunta el nombre y una palabra de paso para proteger el fichero con la clave privada. Su función es generar una clave privada y una petición de certificación. Lee la información que te da el programa y asegúrate de descubrir dónde estan ambos ficheros.

Como te indica el programa, debes enviarle la petición de certificación al administrador de la entidad certificadora. Envíalo siguiendo las instrucciones que te indica el programa y avisa al profesor, que es el administrador de la entidad certificadora y debe firmarlo como root@tecgrid03.epv.uniovi.es.

El administrador de la entidad certificadora devolverá un fichero que debes almacenar en $HOME/.globus/usercert.pem.

En $HOME/.globus deberías tener al menos los ficheros usercert.pem y userkey.pem. Verifícalo:

$> ls $HOME/.globus
total 12
-rw-r--r-- 1 joaquin joaquin 2749 mar  6 18:21 usercert.pem
-r-------- 1 joaquin joaquin  963 mar  6 17:18 userkey.pem

El fichero userkey.pem contiene la clave privada, cifrada y con permisos de fichero muy restringidos: sólo puede leerlo el usuario. El fichero usercert.pem es el certificado y contiene la clave pública. No está cifrado y puede ser distribuido libremente.

Para ver el contenido del certificado, ejecuta la siguiente orden:

$> grid-cert-info -f $HOME/.globus/usercert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 16 (0x10)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: O=Grid, OU=GlobusTest, OU=simpleCA-tecgrid03.epv.uniovi.es, CN=Globus Simple CA
        Validity
            Not Before: Mar  6 17:18:53 2009 GMT
            Not After : Mar  6 17:18:53 2010 GMT
        Subject: O=Grid, OU=GlobusTest, OU=simpleCA-tecgrid03.epv.uniovi.es, OU=epv.uniovi.es, CN=Joaquin
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:bf:95:7f:24:99:d5:ca:2e:76:10:2a:38:39:da:
                    97:34:f0:fb:cc:7e:c3:8c:b3:0b:b7:ea:10:8a:e8:
                    3f:f9:de:d0:31:e3:c2:82:ad:c8:4b:51:1c:ba:3a:
                    5f:5e:f9:34:65:b3:72:81:06:eb:2e:2b:f3:82:70:
                    17:73:a4:67:3a:8f:02:b8:ad:5d:9a:ff:bd:8f:95:
                    6d:8c:e9:61:1e:22:99:cb:4f:c6:f9:d3:1e:f3:07:
                    ac:d6:42:03:ab:8a:8a:71:9a:ac:9c:c0:cb:00:0a:
                    6b:c4:e3:a5:4e:ec:87:f3:3a:eb:67:72:ed:d8:4e:
                    85:49:eb:24:eb:e0:8b:00:43
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type:
                SSL Client, SSL Server, S/MIME, Object Signing
    Signature Algorithm: md5WithRSAEncryption
        4e:e1:66:46:f8:75:bb:aa:81:b0:27:53:04:56:6a:ea:e6:2e:
        c0:2e:bf:7a:a4:a3:61:a0:12:b9:46:7f:63:10:81:c7:03:9e:
        91:63:9a:92:e6:05:cf:42:be:55:d3:d0:4b:d2:02:ed:14:e1:
        f3:2e:51:d5:54:7c:d2:11:0a:20:78:7e:a7:9f:61:00:7c:db:
        62:c0:cb:2d:86:86:a4:c8:33:32:c0:eb:18:4a:9d:fb:25:3e:
        e5:a8:35:be:06:42:24:02:e3:6d:b7:44:ef:c6:c2:5c:e4:b5:
        ee:67:99:73:76:eb:57:72:fd:09:0c:a1:fe:91:48:77:7d:ed:
        4a:03

Como se puede observar, la entidad certificadora es simpleCA-tecgrid03.epv.uniovi.es. Otro dato importante es la validez del certificado. Como se puede observar, en este caso es de un año.

Verifica que el proceso ha funcionado correctamente ejecutando la siguiente orden:

$> grid-proxy-init -verify -debug

Si todo ha ido bien, debería decir, entre otras cosas, Proxy Verify OK.

Esta orden creará un proxy con tus credenciales. El proxy es un fichero en /tmp. La orden te ha dado el nombre del fichero, aunque no necesitarás conocerlo. Otra información que te ofrece es la fecha en la que caduca el proxy. Después de esa fecha, necesitarás crear un proxy nuevo para trabajar con el grid.

Para conocer la información del proxy que tienes activo en cualquier momento, puedes ejecutar esta orden:

$> grid-proxy-info

Como se puede comprobar, el certificado está otorgado por el certificado del usuario. Esto muestra la cadena de confianza: CA → certificado de usuario → certificado proxy.

El certificado proxy contiene la clave privada generada para hacer de proxy y la correspondiente clave pública. Muestra los contenidos del proxy usando grid-cert-info, especificando la ruta completa al proxy que te ha dado la orden anterior:

$> grid-cert-info -file /ruta/al/proxy/nombreFichProxy

Para que puedas ejecutar trabajos, el administrador del grid tiene que haber añadido tu identidad al grip mapfile. Tu identidad la puedes obtener con:

$> grid-cert-info -subject

Comprueba que el administrador te ha añadido al fichero /etc/grid-security/grid-mapfile. Tu identidad debe haber sido mapeada al usuario jobrun, que es quien ejecuta trabajos en este grid.

Otra comprobación que puedes hacer es ejecutar la orden siguiente:

$> globusrun -a -r tecgrid03.epv.uniovi.es

La salida debe ser GRAM Authentication test successful.

Por defecto, grid-proxy-init crea un proxy válido por 12 horas. Se puede especificar la duración con el parámetro valid en la invocación:

$> date
$> grid-proxy-init -valid 0:1
$> grid-proxy-info

El proxy generado es válido por un minuto. grid-proxy-info muestra el tiempo de validez que resta. Deberías ver menos de un minuto. Si ejecutas grid-proxy-info de nuevo, deberías ver que es todavía menos.

Para ver qué ocurre cuando expira un proxy, espera a que pase llegue a cero el tiempo de validez mostrado en grid-proxy-info. Ahora tendrás un proxy, pero será inválido porque ha expirado. Ejecuta la orden para comprobar si puedes lanzar trabajos:

$> globusrun -a -r tecgrid03.epv.uniovi.es

Debería darte un error indicando que el proxy ha expirado y, por lo tanto, el cliente no ha podido autenticarte con el servidor.

En las siguientes secciones necesitarás un proxy válido. Genera uno que te dure al menos toda la sesión de prácticas.

En esta sección se va a ver cómo ejecutar trabajos utilizando GRAM2, es decir, la versión de GRAM que no utiliza servicios web.

Comienza haciendo una prueba que consista en ejecutar un trabajo muy sencillo en tecgrid03.epv.uniovi.es:

$> globus-job-run tecgrid03.epv.uniovi.es /bin/echo Hello World
Hello World

La utilidad globus-job-run permite ejecutar trabajos en sitios remotos. Los trabajos tienen que tener la ruta completa (empezando por /). Por ejemplo, para ejecutar hostname, ejecútalo en primer lugar en la máquina local para comprobar que funciona:

$> hostname
tecgrid03.epv.uniovi.es

A continuación, descubre dónde está el ejecutable:

$> which hostname
/bin/hostname

En este caso, la máquina remota está instalada de la misma forma, así que los ejecutables están en la misma ruta que en la máquina local. Por lo tanto para ejecutar el trabajo sobre la máquina remota tienes que ejecutar la siguiente orden:

$> globus-job-run tecgrid01.epv.uniovi.es /bin/hostname
tecgrid01.epv.uniovi.es

Utiliza which para descubrir dónde están los siguientes ejecutables:

Ejecutando estas órdenes en la máquina remota, descubre el identificador de usuario con el que se ejecutan los trabajos en ella, su entorno de ejecución, en qué directorio se ejecuta por defecto (será el $HOME remoto), los procesos que está ejecutando la máquina y el tiempo que lleva encendida.

$> globus-job-run tecgrid01.epv.uniovi.es /bin/sh -c "grep jobrun /etc/passwd | wc -l"

Utiliza la orden ls sobre la máquina remota. Verás muchos ficheros. Intenta crear tú un fichero con la siguiente orden:

$> globus-job-run tecgrid01.epv.uniovi.es /bin/sh -c "echo Soy $USER > usuario-$USER.txt"

Ejecuta a continuación esta orden:

$> globus-job-run tecgrid01.epv.uniovi.es /bin/sh -c "ls -l usuario-*.txt"

Si otros alumnos han llegado hasta esta parte de la práctica, deberías ver sus ficheros. Esto demuestra que todos estáis ejecutando con el mismo usuario en la máquina remota. Ten en cuenta que esto hace que tus ficheros sean accesibles para otros compañeros.

GRAM permite ejecutar trabajos con distintos gestores de trabajos que sirven de adaptadores a gestores de recursos locales (Local Resource Managers, LRMs). En los clusters instalados en este curso hay disponibles dos: fork, que ejecuta el trabajo con la orden fork() de Unix, y Condor.

A continuación se va a investigar cuál es más rápido lanzando un trabajo ejecutando estas órdenes:

$> time globus-job-run tecgrid01.epv.uniovi.es/jobmanager-condor /bin/hostname
$> time globus-job-run tecgrid01.epv.uniovi.es/jobmanager-fork /bin/hostname

Como podrás comprobar, no hacía falta la orden time para ver cuál era más rápido porque la diferencia es muy apreciable: fork es mucho más rápido que Condor lanzando órdenes. Sin embargo, fork no permite más que ejecutar en el front-end, mientras que Condor permite que la orden se ejecute en cualquier nodo del cluster y abre la posibilidad al procesamiento paralelo.

Fíjate en los nombres que han devuelto las órdenes anteriores: fork siempre devuelve el del front-end, pero Condor te ha podido devolver el de uno cualquiera de los nodos del cluster.

Hasta ahora se ha utilizado GRAM2 para lanzar trabajos, pero la versión actual de gestión de trabajos en GT4 es GRAM4, que está basada en servicios web.

Para ejecutar un trabajo se usa la orden globusrun-ws. Por ejemplo, ejecuta lo siguiente:

$> globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -s -job-command /bin/echo Hello World
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:24e03e7e-0bda-11de-8bd7-0050fca9a8bb
Termination time: 03/09/2009 12:10 GMT
Current job state: Active
Current job state: CleanUp-Hold
Hello World
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Todos los conceptos que se han visto para GRAM2 (rutas de ejecutables, planificadores locales) siguen siendo válidos para GRAM4. En el caso de los planificadores locales, la forma de seleccionar cuál se utiliza es mediante la opción -factory-type. En el Grid de prácticas puede tener los valores Fork o Condor. Prueba cuál es la diferencia de tiempo en utilizar uno u otro con GRAM4:

$> time globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -factory-type Fork -s -job-command /bin/hostname
$> time globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -factory-type Condor -s -job-command /bin/hostname

A continuación se va a ejecutar una aplicación de ejemplo que no sea una orden de las incluidas en el sistema operativo. La aplicación generará números pseudo-aleatorios.

Antes de empezar, para trabajar con tus ficheros sin interferencias de otros alumnos, vas a crear un directorio en la máquina remota. Ejecuta la siguiente orden, sustituyendo HOME_REMOTO por el HOME que descubriste antes:

$> globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -factory-type Fork -s -job-command /bin/mkdir /HOME_REMOTO/$USER

Primero se va a probar la aplicación en la máquina local. Créala con la siguiente orden:

$> cat > genr

#! /bin/sh
NLINES=$1
NDIGITS=$2
awk "BEGIN {
  for (i = 0 ; i < $NLINES; i++ ) {
    print int(rand() * 10^$NDIGITS )
  }
}"

Dale permisos de ejecución:

$> chmod +x genr

Haz una ejecución local para probar que funciona correctamente:

$> ./genr 5 8
23778751
29106573
84581385
15220829
58553734

Intenta ejecutar la aplicación en tecgrid01.epv.uniovi.es sustituyendo HOME_REMOTO:

$> globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -factory-type Fork -s -job-command /HOME_REMOTO/$USER/genr 5 4

No funciona. ¿Por qué? Porque en la máquina remota no está genr. Una forma de solucionar el problema es copiar utilizando GridFTP el archivo a la máquina remota antes de ejecutar:

$> globus-url-copy file:///$HOME/genr gsiftp://tecgrid01.epv.uniovi.es/HOME_REMOTO/$USER/
$> globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -factory-type Fork -s -job-command /bin/chmod +x /HOME_REMOTO/$USER/genr
$> globusrun-ws -submit -F tecgrid01.epv.uniovi.es:9443 -factory-type Fork -s -job-command /HOME_REMOTO/$USER/genr 5 4

Globus Toolkit 4 introdujo WSRF (Web Services Resource Framework) para tener servicios web con recursos con estado. Algunos ejemplos de recursos con estado son los servicios de envío de GRAM4, los trabajos individuales de GRAM4, los servicios de RFT, los trabajos de RFT, el servicio de Index de MDS y el de registro.

Para acceder a recursos WS se utiliza un pequeño documento en XML llamado Endpoint Reference (EPR). Un EPR identifica un servicio web y un recurso específico. El cliente de GRAM4 (globusrun-ws) y el de RFT (rft) generan EPRs automáticamente.

Vamos a crear un EPR para el recurso de evío de trabajos de GRAM4 con Condor:

$> cat > gram.epr

<factoryEndpoint
  xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
  xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">

  <wsa:Address>
    https://tecgrid01.epv.uniovi.es:9443/wsrf/services/ManagedJobFactoryService
  </wsa:Address>

  <wsa:ReferenceProperties>
    <gram:ResourceID>Condor</gram:ResourceID>
  </wsa:ReferenceProperties>
</factoryEndpoint>

El EPR contiene el URL para el servicio web de GRAM4 dentro del elemento Address y un elemento ReferenceProperties que identifica el gestor de trabajos Condor dentro de ese servicio.

En ocasiones anteriores se han usado las opciones -F y -Ft de globusrun-ws para especificar qué máquina y qué gestor de trabajos utilizar. Ahora vamos a utilizar el fichero EPR anterior con la opción -Ft:

$> globusrun-ws -submit -Ff gram.epr -s -job-command /usr/bin/whoami
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:106267e4-0bf6-11de-aeb1-0050fca9a8bb
Termination time: 03/09/2009 15:30 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
nobody
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Cada trabajo que se envía a GRAM4 es también un recurso WS. Para comprobarlo, vamos a enviar un trabajo en modo "por lotes" (batch), lo que significa que globusrun-ws no esperará a que el trabajo acabe y, en su lugar, escribirá el fichero job.epr con el EPR del trabajo:

$> globusrun-ws -submit -Ff gram.epr -s -o job.epr -batch -job-command /bin/sleep 60s
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:4b7b2654-0bf6-11de-880e-0050fca9a8bb
Termination time: 03/09/2009 15:32 GMT

Mira el contenido del fichero generado:

$> cat job.epr
<ns00:EndpointReferenceType xmlns:ns00="http://schemas.xmlsoap.org/ws/2004/03/addressing">
<ns00:Address>https://156.35.171.90:9443/wsrf/services/ManagedExecutableJobService</ns00:Address>
<ns00:ReferenceProperties>
  <ResourceID xmlns="http://www.globus.org/namespaces/2004/10/gram/job">464a3e10-0bf4-11de-85e0-d960773ed70a</ResourceID>
</ns00:ReferenceProperties>
<wsa:ReferenceParameters xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"/>
</ns00:EndpointReferenceType>

Para monitorizar el trabajo, se puede utilizar la opción -monitor:

$> globusrun-ws -monitor -j job.epr -s
Current job state: Active
Current job state: CleanUp-Hold
Current job state: CleanUp
Current job state: Done
Requesting original job description...Done.
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Hasta el momento se ha especificado qué aplicación ejecutar y con qué argumentos a través de la línea de comandos. Sin embargo, en ocasiones, en especial cuando se quiere ejecutar el mismo trabajo varias veces, es más cómodo utilizar un fichero de descripción de trabajos.

Crea un fichero de descripción de trabajos sencillo:

$> cat > miTrabajo.xml

<job>
  <executable>/bin/hostname</executable>
</job>

Ejecuta el trabajo con esta orden:

$> globusrun-ws -submit -Ff gram.epr -s -f miTrabajo.xml
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:ab9ad83e-0bf8-11de-a6ca-0050fca9a8bb
Termination time: 03/09/2009 15:49 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
m1n2.atc
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Para especificar argumentos para la aplicación, se usa la etiqueta <argument>, como por ejemplo:

<job>
  <executable>/bin/sleep</executable>
  <argument>5</argument>
</job>

En lugar de especificar la dirección del gestor de trabajos y el trabajo en ficheros distintos, se puede poner todo en el fichero de descripción de trabajos:

$> cat > miTrabajo.xml

<job xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
    xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job">
  <factoryEndpoint>
    <wsa:Address>
      https://tecgrid01.epv.uniovi.es:9443/wsrf/services/ManagedJobFactoryService
    </wsa:Address>
    <wsa:ReferenceProperties>
      <gram:ResourceID>Fork</gram:ResourceID>
    </wsa:ReferenceProperties>
  </factoryEndpoint>
  <executable>/bin/date</executable>
</job>

Cuando se incluye el gestor de trabajos en la descripción del trabajo, ya no es necesario el parámetro -Ft para ejecutar:

$> globusrun-ws -submit -s -f miTrabajo.xml
Submitting job...Done.
Job ID: uuid:c5f64d2a-0bf9-11de-9522-0050fca9a8bb
Termination time: 03/09/2009 15:57 GMT
Current job state: Active
Current job state: CleanUp-Hold
Sun Mar  8 16:56:22 CET 2009
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Pero la mayor ventaja de los ficheros de descripción de trabajos es que se puede especificar la transferencia de ficheros (puesta en escena, staging) antes de la ejecución, evitando tener que transferirlos manualmente como se hizo en el ejemplo anterior con genr. La puesta en escena no se puede indicar por la línea de comandos.

A continuación se va a repetir el ejercicio de genr pero haciendo la puesta en escena con GRAM4. En primer lugar, se debe copiar el ejecutable a un directorio accesible por RFT en la máquina local, por ejemplo /tmp. Cópialo con la siguiente orden:

$> mkdir /tmp/$USER
$> cp genr /tmp/$USER

A continuación, se debe crear el fichero de descripción de trabajos:

$> cat > miTrabajo.xml

<job>
    <executable>${GLOBUS_USER_HOME}/genr</executable>
    <argument>5</argument>
    <argument>4</argument>
    <fileStageIn>
        <transfer>
            <sourceUrl>gsiftp://tecgrid03.epv.uniovi.es:2811/tmp/_MY_USER_/genr</sourceUrl>
            <destinationUrl>file:///${GLOBUS_USER_HOME}/_MY_USER_/genr</destinationUrl>
        </transfer>
    </fileStageIn>
</job>

En esta descripción aparecen dos nuevos conceptos:

Antes de ejecutar el trabajo, se debe sustituir el nombre del usuario en el fichero de descripción:

$> sed -i "s/_MY_USER_/$USER/" miTrabajo.xml

Ejecuta el trabajo con esta orden:

$> globusrun-ws -submit -Ff gram.epr -S -s -f miTrabajo.xml
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:0bb2af20-0e52-11de-a40a-0050fca9a8bb
Termination time: 03/12/2009 15:34 GMT
Current job state: StageIn
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
2377
2910
8458
1522
5855
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Una ventaja de esta orden es que no es necesario poner permisos de ejecución a los ficheros transferidos: RFT copia automáticamente los permisos de ejecución originales.

Además de poner en escena ficheros, también se pueden retirar de la escena como parte del trabajo. El siguiente ejemplo ilustra cómo hacerlo:

$> cat > miTrabajo.xml

<job>
    <executable>${GLOBUS_USER_HOME}/_MY_USER_/genr</executable>
    <argument>5</argument>
    <argument>4</argument>
    <stdout>${GLOBUS_USER_HOME}/_MY_USER_/genr.out.${GLOBUS_USER_NAME}</stdout>
    <fileStageIn>
        <transfer>
            <sourceUrl>gsiftp://tecgrid03.epv.uniovi.es:2811/tmp/_MY_USER_/genr</sourceUrl>
            <destinationUrl>file:///${GLOBUS_USER_HOME}/_MY_USER_/genr</destinationUrl>
        </transfer>
    </fileStageIn>
    <fileStageOut>
        <transfer>
            <sourceUrl>file:///${GLOBUS_USER_HOME}/_MY_USER_/genr.out.${GLOBUS_USER_NAME}</sourceUrl>
            <destinationUrl>gsiftp://tecgrid03.epv.uniovi.es:2811/tmp/_MY_USER_/</destinationUrl>
        </transfer>
    </fileStageOut>
    <fileCleanUp>
        <deletion>
            <file>file:///${GLOBUS_USER_HOME}/_MY_USER_/genr</file>
        </deletion>
        <deletion>
            <file>file:///${GLOBUS_USER_HOME}/_MY_USER_/genr.out.${GLOBUS_USER_NAME}</file>
        </deletion>
    </fileCleanUp>
</job>

Antes de ejecutar el trabajo, se debe sustituir el nombre del usuario en el fichero de descripción:

$> sed -i "s/_MY_USER_/$USER/" miTrabajo.xml

También se deben dar permisos de escritura en el directorio de salida:

$> chmod o+w /tmp/$USER

Ejecuta el trabajo con esta orden:

$> globusrun-ws -submit -Ff gram.epr -S -s -f miTrabajo.xml
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:1871d640-0e53-11de-a594-0050fca9a8bb
Termination time: 03/12/2009 15:41 GMT
Current job state: StageIn
Current job state: Pending
Current job state: Active
Current job state: StageOut
2377
2910
8458
1522
5855
Current job state: CleanUp-Hold
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.

Comprueba que ha llegado bien la salida:

$> cat /tmp/$USER/genr.out.jobrun
2377
2910
8458
1522
5855

El componente MDS de Globus Toolkit tiene un servicio llamado Index Service que es útil cuando hay varios servicios con los que se desea interactuar para monitorizarlos o descubrirlos. Este servicio puede recoger propiedades de recursos de varios recursos WS y hacerlas accesibles en un solo lugar. Las instalaciones por defecto de Globus tienen un servicio de índice con información básica. Para ver la que ofrece el del Grid de prácticas, ejecuta esta orden:

$> wsrf-query -s https://tecgrid03.epv.uniovi.es:9443/wsrf/services/DefaultIndexService | less

Para ver, por ejemplo, qué gestores de trabajos permite utilizar Globus, se puede ejecutar esta orden:

$> wsrf-query -z none -s \
https://tecgrid03.epv.uniovi.es:9443/wsrf/services/DefaultIndexService \
"//*[local-name()='Address']/text()[contains(.,'ManagedJobFactoryService')]|//*[local-name()='GLUECE']"

https://156.35.171.92:9443/wsrf/services/ManagedJobFactoryService<ns1:GLUECE xmlns:ns1="http://mds.globus.org/glue/ce/1.1">
 <ns1:ComputingElement ns1:Name="default" ns1:UniqueID="default">
  <ns1:Info ns1:GRAMVersion="4.0.7" ns1:HostName="tecgrid03.epv.uniovi.es" ns1:LRMSType="Fork" ns1:LRMSVersion="1.0" ns1:TotalCPUs="1"/>
  <ns1:State ns1:EstimatedResponseTime="0" ns1:FreeCPUs="0" ns1:RunningJobs="0" ns1:Status="enabled" ns1:TotalJobs="0" ns1:WaitingJobs="0" ns1:WorstResponseTime="0"/>
  <ns1:Policy ns1:MaxCPUTime="-1" ns1:MaxRunningJobs="-1" ns1:MaxTotalJobs="-1" ns1:MaxWallClockTime="-1" ns1:Priority="0"/>
 </ns1:ComputingElement>
</ns1:GLUECE>https://156.35.171.92:9443/wsrf/services/ManagedJobFactoryService<ns1:GLUECE xmlns:ns1="http://mds.globus.org/glue/ce/1.1">
 <ns1:ComputingElement ns1:Name="default" ns1:UniqueID="default">
  <ns1:Info ns1:GRAMVersion="4.0.7" ns1:HostName="tecgrid03.epv.uniovi.es" ns1:LRMSType="Condor" ns1:LRMSVersion="" ns1:TotalCPUs=""/>
  <ns1:State ns1:EstimatedResponseTime="0" ns1:FreeCPUs="0" ns1:RunningJobs="0" ns1:Status="enabled" ns1:TotalJobs="0" ns1:WaitingJobs="0" ns1:WorstResponseTime="0"/>
  <ns1:Policy ns1:MaxCPUTime="-1" ns1:MaxRunningJobs="-1" ns1:MaxTotalJobs="-1" ns1:MaxWallClockTime="-1" ns1:Priority="0"/>
 </ns1:ComputingElement>
</ns1:GLUECE>https://156.35.171.92:9443/wsrf/services/ManagedJobFactoryService

Los gestores de trabajo se muestran con el atributo LRMSType.

Como se puede comprobar, el formato de salida no es adecuado para un humano. Por ello Globus proporciona también el servicio WebMDS, que presenta los datos de MDS mediante una página web. No se va a probar sobre el Grid de prácticas porque no está instalado. Pruébalo sobre un Grid de ejemplo introduciendo esta dirección en un navegador web:

http://mds.globus.org:8080/webmds

Puedes ver la lista de recursos del servicio local por defecto y también unos formularios de ejemplo con distintas consultas.