Antes de empezar hay que conectarse a tecgrid03.epv.uniovi.es en caso de que no lo estés ya. La conexión debe ser ssh, por lo que es necesario utilizar un cliente que soporte este protocolo. Se recomienda utilizar el PuTTY.

Crearemos un directorio para contener los ficheros con los que se va a trabajar.

$> mkdir ~/integra/datos
$> cd ~/integra/datos

Antes de poder ejecutar comandos sobre globus tenemos que obtener un proxy.

$> grid-proxy-init
Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-tecgrid03.epv.uniovi.es/OU=atc/CN=Rosco
Enter GRID pass phrase for this identity:
Creating proxy ................................ Done
Your proxy is valid until: Fri Feb  6 06:30:23 2009

Establecemos la variable de entorno $HOST para que contenga el nombre de la máquina sobre la que vamos a trabajar.

$> export HOST=tecgrid03.epv.uniovi.es
$> echo $HOST
tecgrid03.epv.uniovi.es

El grid de datos está compuesto por diversas herramientas que llevan a cabo diversas funciones. En nuestro caso, Hadoop proporciona un sistema de ficheros distribuido, SRM proporciona el interfaz a dicho sistema y Globus proporciona las herramientas de transferencia y de gestión de réplicas. Para facilitar la utilización de todas estas herramientas de forma integrada se han desarrollado varios programas. Se puede consultar su código fuente en el directorio /opt/atcgrid/bin.

Para copiar y registrar ficheros en el grid, en ocasiones denominado gridizar ficheros, se va a utilizar el comando atc_cr.py.

Primero vamos a crear un fichero.

$> cat > $USER-gfile

Escribe algo y pulsa Ctrl-D. Haz un listado del contenido del fichero y verifica que está bien.

A continuación vamos a copiar y registrar el fichero en el grid.

$> atc_cr.py $USER-gfile
Trying to copy by SRM...
file ruf-gfile copied in srm://tecgrid01.epv.uniovi.es//hdfs
Trying to copy by SRM...
file ruf-gfile copied in srm://tecgrid03.epv.uniovi.es//hdfs
Trying to register LFN...
file ruf-gfile registered in rls://tecgrid01.epv.uniovi.es
Trying to add LFN...
New PFN for ruf-gfile added in rls://tecgrid01.epv.uniovi.es
Trying to register LFN...
file ruf-gfile registered in rls://tecgrid03.epv.uniovi.es
Trying to add LFN...
New PFN for ruf-gfile added in rls://tecgrid03.epv.uniovi.es

Fíjate en lo que ha hecho el comando anterior. Primero ha copiado el fichero en el sistema de ficheros HDFS de cada uno de dos clusters. Para ello ha utilizado SRM, la interfaz de los elementos de almacenamiento. Internamente SRM ha utilizado GridFTP. Posteriormente, se han registrado estos ficheros en el servidor de RLS.

El lugar donde se copian y registran los ficheros del grid queda determinado por los ficheros de configuración que se encuentran en /opt/atcgrid/conf. El fichero atc-pfn indica las localizaciones donde se copiarán los ficheros. El fichero atc-lrc indica los servidores LRC donde se registrarán los ficheros. Por último, el fichero atc-rli indicará que servidores se utilizan como RLI. Comprueba el contenido de los ficheros.

Como habrás observador los dos clusters sirven tanto de localización física, servidores de LRC y servidores de RLI. En este caso se trabajo con una redundancia total entre ambos clusters. Si alguno de ellos deja de funcionar, el grid no se vería afectado. Esta es una de las características del grid: la tolerancia a fallos.

Podemos comprobar el registro que se ha hecho del fichero que acabamos de utilizar.

$> globus-rls-cli query rli lfn $USER-gfile rls://$HOST
  ruf-gfile: rls://tecgrid01.epv.uniovi.es:39281
  ruf-gfile: rls://tecgrid03.epv.uniovi.es:39281

Como se puede observar, hay dos servidores que proporcionan información acerca de la localización física del fichero. Podemos preguntar a uno de ellos.

$> globus-rls-cli query lrc lfn $USER-gfile rls://$HOST
  ruf-gfile: srm://tecgrid01.epv.uniovi.es//hdfs/ruf-gfile
  ruf-gfile: srm://tecgrid03.epv.uniovi.es//hdfs/ruf-gfile

La respuesta nos indica que dicho nombre lógico (LFN) está asociado a dos físicos (PFN). El acceso a dicho fichero se podría realizar en cualquiera de las dos localizaciones físicas.

De la tarea de consulta de un fichero registrado en el grid y de su transferencia se encarga el comando atc_cp. Por ejemplo se podría utilizar para transferir este fichero hasta el directorio actual:

$> atc_cp.py $USER-file $USER-file2
Trying to query rli...
Trying to query LRC server in rls://tecgrid01.epv.uniovi.es ...
Connecting LRC server rls://tecgrid01.epv.uniovi.es:39281:
Trying to transfer by SRM...
srm://tecgrid01.epv.uniovi.es//hdfs/ruf-gfile -> transfer OK
 successful transfer

Algunos trabajos del grid están pensados para procesar ficheros de datos. Para facilitar la ejecución de este tipo de trabajos existe el comando atc_submit. Este comando recibe un fichero de descripción de trabajo similar al de condor donde se pueden incluir ordenes de transferencia de ficheros registrados en el grid. El comando se encarga de transformar este fichero de descripción de trabajo de manera oportuna. Básicamente permite utilizar de forma sencilla el grid de datos y el de computación.

Vamos a crear un trabajo de ejemplo.

$> mkdir ~/integra/depen
$> cd ~/integra/depen
$> cat > depen.sub

Universe      = grid

grid_resource = gt4 $$(gatekeeper_url) $$(job_manager_type)
requirements = (TARGET.gatekeeper_url =!= UNDEFINED) && \
               (TARGET.job_manager_type =!= UNDEFINED)

Executable    = /usr/bin/wc
arguments	= -m _USER_-gfile
output        = depen.out
error         = depen.error
log           = depen.log
should_transfer_files   = YES
when_to_transfer_output = ON_EXIT
transfer_input_files = lfn://_USER_-gfile
Queue 1

Sustituímos _USER_.

$> sed -i "s/_USER_/$USER/" depen.sub
$> cat depen.sub
Universe      = grid

grid_resource = gt4 $$(gatekeeper_url) $$(job_manager_type)
requirements = (TARGET.gatekeeper_url =!= UNDEFINED) && \
               (TARGET.job_manager_type =!= UNDEFINED)

Executable    = /usr/bin/wc
arguments       = -m ruf-gfile
output        = depen.out
error         = depen.error
log           = depen.log
should_transfer_files   = YES
when_to_transfer_output = ON_EXIT
transfer_input_files = lfn://ruf-gfile
Queue 1

El trabajo es muy sencillo. Simplemente calcula cuantos caracteres hay almacenados en el fichero que subimos anteriormente al grid. A continuación vamos a transformar el trabajo.

$> atc_submit.py depen.sub
File new_depen.sub ready to be submitted
Try to execute: condor_submit new_depen.sub

El comando anterior ha creado un nuevo fichero con la transformación.

$> cat new_depen.sub
EXECUTABLE = $ENV(ATCGridHome)/bin/wrapper_atc_run
TRANSFER_EXECUTABLE = TRUE
ARGUMENTS =  /usr/bin/wc -m ruf-gfile to_download_from_grid:  ruf-gfile
Universe      = grid

grid_resource = gt4 $$(gatekeeper_url) $$(job_manager_type)
requirements = (TARGET.gatekeeper_url =!= UNDEFINED) && \
               (TARGET.job_manager_type =!= UNDEFINED)

output        = depen.out
error         = depen.error
log           = depen.log
should_transfer_files   = YES
when_to_transfer_output = ON_EXIT
Queue 1

La transformación permite que el trabajo que se ejecute sea un wrapper, denominado wrapper_atc_run, cuyo cometido es realizar la transferencia de los ficheros solicitados (Staging) y ejecutar el trabajo real que hemos indicado.

A continuación enviamos el trabajo a condor.

$> condor_submit new_depen.sub
Submitting job(s).
Logging submit event(s).
1 job(s) submitted to cluster 1022.

Cuando termine podemos comprobar los resultados obtenidos.

$> cat depen.out
Execution on m3n3.atc
Trying to query rli...

Trying to query LRC server in rls://tecgrid01.epv.uniovi.es ...

Connecting LRC server rls://tecgrid01.epv.uniovi.es:39281:

Trying to transfer by SRM...

srm://tecgrid01.epv.uniovi.es//hdfs/ruf-gfile -> transfer OK

 successful transfer

/usr/bin/wc -m ruf-gfile command launched
32 ruf-gfile

La última parte del fichero de salida contiene el número de caracteres del fichero utilizado como argumento del trabajo.