sergiobuj/backfill.md

Descripción:

Existe la posibilidad de que cuando Condor no tiene trabajo para ejecutar o que los trabajos que siguen en cola no tengan máquinas disponibles, se inicie el modo Backfill. Backfill es aprovechar el tiempo disponible de la máquina para ejecutar trabajos que necesitan mucho tiempo de computación.

Hasta la versión actual (CondorVersion: 7.6.6 Jan 17 2012 BuildID: 401976) el único sistema de Backfill soportado por Condor es [boinc.berkeley.edu BOINC], sistema para computación con recursos de voluntarios creado por la Universidad de California en Berkeley.

Proyectos con BOINC

BOINC se conecta automáticamente una vez es iniciado con el servidor del proyecto(s) para descargar las tareas que debe realizar. En principio se está colaborando con el proyecto de la Universidad de Antioquia (grupo PECET) que tiene almacena el proyecto en [http://www.worldcommunitygrid.org WCG].

Para contribuir con el proyecto se debe especificar las condiciones del uso de máquina y proyectos mediante el sitio web de WCG y usar la llave de identificación del perfil para iniciar BOINC con un proyecto determinado.

Proyecto: http://www.worldcommunitygrid.org
Usuario ID: <Llave que se encuentra en el perfil en WCG>

Un ejemplo de uso de BOINC en una máquina sin el uso de Condor+Backfill se debe lanzar así:

 $ boinc-client -no_gui_rpc --attach_project www.worldcommunitygrid.org llave-del-perfil

Configurar modo Backfill en Condor

El modo Backfill de Condor no está configurado por defecto y se deben especificar algunas opciones para permitir que se ejecute BOINC una vez Condor se encuentra sin tareas o la máquina no tiene tareas asignadas.

La siguiente configuración debe hacerse en el archivo de configuración local de Condor en cada máquina que se quiere usar con Backfill. El archivo suele estar en /etc/condor/condor_config.local y solo se debe añadir la siguiente configuración.

## Enable Backfill ##
ENABLE_BACKFILL = TRUE
BACKFILL_SYSTEM = BOINC
START_BACKFILL = $(StateTimer) > (1 * $(MINUTE))
EVICT_BACKFILL = FALSE
## Configure BOINC ##
BOINC_HOME = /boinc
BOINC_Executable = /share/apps/BOINC/boinc
BOINC_Universe = vanilla
BOINC_InitialDir = $(BOINC_HOME)
BOINC_Output = $(BOINC_HOME)/boinc.out
BOINC_Error = $(BOINC_HOME)/boinc.err
BOINC_Owner = boinc
BOINC_Arguments = -no_gui_rpc --attach_project www.worldcommunitygrid.org llave-del-perfil

La anterior configuración le especifica a Condor, mediante el uso de variables de Condor, que debe permitir el modo Backfill en esa máquina, que debe esperar un tiempo determinado para iniciar Backfill, la forma en que debe ejecutar BOINC y también donde debe descargar y guardar los datos requeridos para el procesamiento.

Errores comunues

Si después de modificar el archivo de configuración y esperar el tiempo de inicio de Backfill no se ha iniciado Backfill+BOINC, se sugiere revisar lo siguiente:

Se instaló BOINC correctamente.
Se reconfiguró Condor mediante el uso del comando condor_reconfig.
El usuario que ejecuta BOINC existe en la máquina (variable de Condor BOINC_Owner).
El usuario que ejecuta BOINC tiene permisos de escritura y lectura en el "home" de BOINC (variable de Condor BOINC_Home).
La máquina se encuentra efectivamente desocupada.
Revisar los archivos de Log de Condor, tanto el 'Startd', 'Master' y los terminados en 'boinc'.

Condor+Backfill en archivo Extend de RocksClusters

Para permitir el uso de Backfill en Clusters de Rocks (usando el Rollo de Condor) se puede usar un archivo de extensión de configuración que Rocks usa cuando instala un nodo con ese nombre. Estos archivos se encuentran en el directorio /export/rocks/install/site-profiles/<VERSION DE ROCKS>/nodes/ del 'Rocks-Front'.

Un ejemplo de un archivo de extensión se encuentra en [https://gist.github.com/2697185 extend-compute.xml]. El archivo se debe encontrar ahí antes de iniciar la instalación de los nodos.

Notas:

Se recomienda instalar BOINC en un directorio compartido del cluster (En Rocks /export/apps/ para ser accedido desde los nodos en /share/apps/).
En el archivo de extensión se especifica la instalación de las librerías BLAS y LAPACK, pero no son necesarias para el funcionamiento de Condor+Backfill+BOINC. Se deben tener los RPM de BLAS y LAPACK en la ruta de RPMS de Rocks para que se puedan instalar, de lo contrario se deben eliminar los <package> * </package> que los especifican.

Condorfy

Descripción:

Condorfy es una aplicación web que permite la creación de archivos .condor mediante un formulario.

Proyecto:

El código del proyecto se encuentra en la cuenta de Github de Sergio Botero con el nombre de condorfy. El proyecto fue iniciado por Sergio Botero y se encuentra actualmente para uso en CONDORFY.

La Aplicación:

Condorfy es una aplicación web hecha en Ruby con Sinatra. Consta de un formulario HTML del que se genera el archivo dependiendo de la lógica que se encuentra en la documentación de condor sobre el envío de trabajos al cluster (Versión 7.8 al momento). La aplicación permite descargar un archivo que está listo para ser usado con el comando condor_submit así:

 $ condor_submit myjob.condor

Posibles mejoras:

Se debe incluir una forma de cargar solo los ejecutables que se tengan disponibles en el cluster (una lista dada por el administrador del cluster). Lo mismo para las arquitecturas, sistemas operativos y cantidad de memoria que se pueda requerir a los trabajos.

Evolución:

La idea que se tiene es que desde el condorfy, después de especificar el archivo .condor, se pueda cargar el ejecutable por parte del usuario y desde la misma aplicación web se pueda hacer el envío del trabajo al cluster, evitando así que los usuarios tengan que hacer uso de SSH y demás métodos para acceder al cluster.

There are two machines/locations involved in the installation. The hub as HUB and the cluster controller as CLUSTER. Through this installation the $HOME directory on CLUSTER will refer to the home directory of the user that will be used to submit the jobs to the cluster (for most purposes would be any user other than root).

INSTALLATION

HUB

apt-get install hubzero-app-submit
apt-get install hubzero-submit-server
apt-get install hubzero-submit-distributor

MOVING FILES AROUND

Files can be easily transfered between HUB and CLUSTER using the scp command.

HUB

cd to the submit directory (/opt/submit by default) and add the public key found in ssh/submit_rsa.pem to the authorized keys file on CLUSTER $HOME/.ssh/authorized_keys.

CLUSTER:

Create directories submit, log, bin and scratch.

$ mkdir -p $HOME/submit/log
$ mkdir -p $HOME/bin
$ mkdir -p $HOME/scratch

HUB:

Copy the scripts needed for the Batch System that is going to be used from BatchMonitors/<YOUR BATCH SYSTEM> directory to CLUSTER $HOME/submit

Copy file LogMessage.py to CLUSTER $HOME/submit

Copy files from the Scripts/<YOUR BATCH SYSTEM> directory to CLUSTER $HOME/bin

In case it exists, remove file /etc/submit/config

CLUSTER:

Make sure the files in $HOME/bin are executable, this can simply be done using: $ chmod +x $HOME/bin/*

HUB:

Check the ownership of the file monitorJobDB, it should belong to gridman and group gridman. To change it simply # chown gridman.gridman monitorJobDB

Use visudo to give permissions over the bin/update_known_hosts file adding this entry: ALL ALL=NOPASSWD:/opt/submit/bin/update-known-hosts

The path should be changed in case that the installation was made on a different directory.

FILL IN CONFIGURATION FILES

HUB:

Add information to sites.dat

[venue_name]
venues = <comma separated list of venues>
remoteBatchSystem = <PBS or CONDOR or...>
remotePpn = <Has to be specified, if unknown set to 1>
checkProbeResult = false
remoteScratchDirectory = <path on CLUSTER $HOME/scratch>
siteMonitorDesignator = monitor_name
venueMechanism = <ssh or local>
remoteUser = <username on the CLUSTER>

Add information to monitors.dat

[monitor_name]
venue = <venue_name>
remoteUser = <username on the CLUSTER>
venueMechanism = <ssh or local>
remoteMonitorCommand = <path on CLUSTER $HOME/submit/MONITOR-SCRIPT>

Where MONITOR-SCRIPT should be changed to match the script according to your Batch System.

EDIT FILES

HUB:

Edit file /etc/hubzero/maxwell.conf and add the lines following lines (3) before the hub information.

visualization_params="""
submit_target tcp://<SUBMIT_SERVER_LOCATION>:830
"""

CLUSTER:

Edit the monitor file on $HOME/submit/MONITOR-SCRIPT to set this variables.

SITEDESIGNATOR = monitor_name #Same as HUB monitors.dat
MONITORROOT = <Adjust path to $HOME/submit>
MONITORLOGLOCATION = <Adjust path to $HOME/submit/log>

If you are using CONDOR and the executables are already in the user PATH set this:

CONDOR_ROOT = ""
CONDOR_CONFIG = ""

DONE!

HUB: Start or Restart submon and submit-server daemons.

# /etc/init.d/submit-server start
# /etc/init.d/submon start

	require 'sinatra'
	require 'redcarpet'
	require 'rdiscount'
	require 'sinatra/reloader'

	get '/:file/?' do
	options = [:hard_wrap, :filter_html, :autolink, :no_intraemphasis, :fenced_code, :gh_blockcode]
	Redcarpet.new(File.read(File.join(File.dirname(__FILE__), "#{params[:file]}.md")), *options).to_html
	end

sergiobuj/backfill.md

Select an option

No results found

Select an option

No results found

Descripción:

Proyectos con BOINC

Configurar modo Backfill en Condor

Errores comunues

Condor+Backfill en archivo Extend de RocksClusters

Notas:

Condorfy

Descripción:

Proyecto:

La Aplicación:

Posibles mejoras:

Evolución:

INSTALLATION

HUB

MOVING FILES AROUND

HUB

CLUSTER:

HUB:

CLUSTER:

HUB:

FILL IN CONFIGURATION FILES

HUB:

EDIT FILES

HUB:

CLUSTER:

DONE!