PROTOCOLO GESTION DE COLAS

En cluster Imarpe-HPC
Generalidades
SGE (Sun Grid Engine), es el acronomo utilizado para en referencia a la aplicacion
de Gestion de Ejecucion de aplicaciones en Cluster, en forma particular en el
cluster HPC-Imarpe. Esta aplicacion es parte de la instalacion que realiza ROCLS
CLUSTER v 6.2 , como parte del paquete de Rools de herramientas que pone a
disposicion de los usuarios del mismo. Si bien el acronimo incluye la letra S al
inicio, esta se debe a que inicialmente fue creada por Sun Systems, mas hoy en
dia es considerada como software libre y el nombre formal es Open Grid
Scheduler Grid Engine, este en uso para el clutser la version 2011.11p1

Objetivo del presente Protocolo

Proporcionar al administrador del cluster de conocimientos sobre herramientas
necesarias para la correcta ejecucion de modelos wrf y roms sobre el Cluster
HPC-Imarpe, orientado a la generacion de simulaciones.
Estos conocimiento se agruparan por protocolos orientados a la ejecucion de
tareas especificas asi como listados de comandos a ser usados a discrecion del
Administrador.

Definiciones preliminares (Glosario de Terminos)

Managers
Tienen el total dominio de las funcionalidades para la manipulacin del Sistema
Grid Engine, Por defecto, los superusers poseen este tipo de privilegios.
Operadores
Usuarios que pueden ejecutar los mismos comandos que los managers excepto
que no pueden cambiar configuraciones. El operador se asume que se encargan
de mantener las operaciones en si.
Users
Usuarios que puede enviar Jobs al Grid y ejecutarlos si es que poseen un login
USER en al menos un cluster para ese fin. Los Users no tienen privilegios de
gestin del cluster o gestin de colas.
Owners
Usuarios que pueden suspender o reanudar y habilitar o deshabilitar colas que
ellos posean. Tpicamente, users y owners pueden ser los managers, operators o
usuarios. Estos privilegios son necesarios para el uso exitoso de este tipo de perfil
de usuario en GE.
Jobs
Instancias de ejecucin de modelos, lanzados a travs de SUN GRID ENGINE y
que son administrados por el Sheduler Job. Donde permanecen en espera o son
ejecutados.
Queues
Son contenedores de distintos tipos de js recursos correspondientes para la
ejecucin de jobs.
Ticket Policies
Determinan las prioridades con la cuales se ejecutan los Jobs. Se empieza con un
nmero determinado de tickets, los mismos que son consumidos mediante la
ejecucin de los Jobs respectivos.Existen tres tipos de tickets policies: share tree
(fairly-share), el functional y finalmente el override. La ponderacin final de los
tickets en su conjunto establece la prioridad con la cual es ejecutado en job en el
cluster.
Share tree policy.- Asigna a los Jobs un uso compartido de los recursos del cluster.
Este ticket debe ser usado cuando se desea un uso standard y equitativamente
compartido de los recursos del mismo.
Functional policy.- Asigna tickets basado en 4 categoras funcionales:users,
departments, Project y jobs. Este tipo de ticket deber ser usado cuando de desee
asignar prioridades relativas entre las tipificaciones antes mencionadas.
Overrride policy.- Es el tipo mas simple de ticket ya que asigna prioridades para la
ejecucin de Jobs de forma temporal. De alguna forma asegura que los Jobs con
baja prioridad de ejecucin pueda ser ejecutado posteriormente.

Tickets de urgencia (urgency policies)

Wait time policy.- Se acumula cuando un job se encuentra en modo de espera por
falta de recursos. Cuanto mayor sea el tiempo de espera, mayor es su prioridad al
momento de ser ejecutado.
Deadline policy.- La misma este directamente relacionada a deadline time, el cual
es el tiempo asignado a un job para su ejecucin, cuando el momento de termino
se acerca, se asigna de forma automtica una alta prioridad para su ejecucin
dentro del tiempo establecido.
Administracion General de SGE
La misma puede realizar de dos formas:
(1) Linea de comandos
(2) Interfase Grafica qmon
En este manual de protocolo se especificarn las dos formas

Administracin de Usuarios
Consiste en la asignar privilegios a los usuarios ya existentes del Cluster HPC-
Imarpe, para el uso del gestor SGE. Existen tres tipos de Usuarios:
Administradores (Managers), Operadores (Operators). Propietarios (Owners) y
Usuarios en general (Users)

Usuarios Administradores (Managers)

Tienen todos los privilegios para manipular SGE. Por defecto el superuser del
cluster tiene esta condicion de usuario.

Usuarios Operadores (Operators)

Tienen casi todos los privilegio del los Administradores con excepcion de:
i. Cambios en la configuracion del SGE
ii. Gestion de colas (queues). Los owners de colas no poseen permisos de
administrador

Usuarios Propietarios (Owners)

Los propietarios de colas (queues), pueden suspender o inhabilitar las colas que
ellos posean. Tambien los trabajos que de ellas dependan. Los propietarios de
colas no poseen ningon otro privilegio de administracion. En general se asigna
este tipo de privilegios a los Jefes de Areas o de Proyecto, que tiene usuarios bajo
mando.

Usuarios en general (Users)

Tienen ciertos permisos de acceso. No poseen privilegios de gestion del
DESDE LINEA DE COMANDOS
Comando Descripcin
qconf -am ClusterUser Adicionar Manager a SGE
qconf -dm ClusterUser Eliminar Manager de SGE
qconf -sm Mostrar managers de SGE
qconf -ao ClusterUser Adicionar Operadores al SGE
qconf -do ClusterUser Eliminar Operadores a SGE
qconf -so Mostrar Operadores

CON INTERFASE GRAFICA QMON

Desde una misma ventana es posible el acceso a todas las operaciones de
gestin de usuarios detalladas en formas de comandos. Los usuarios mageres y
operators, son de definicion e interactuan de forma directa con SGE, mas los
Userset(conjunto o grupo de Usuarios son importantes ya que son el insumo
principal para las Colas (queues).
La figura siguiente muestra el grupo test001, cuyos usuarios son wrf y roms
(Usuarios declarados en el Cluster Imarpe HPC.
Procedimiento de envi de Jobs al clster
LANZAMIENTO DESDE LINEA DE COMANDOS
1. Navegar hacia el Directorio donde se encuentra el archivo binario ejecutable,
as como tambin los archivos de datos de entrada 1
2. Preparacin de script con ordenes hacia SGE
3. Lanzamiento con con: $ qsub lanza_wrf.sh (o lanza_roms.sh)
4. De inmediato el sistema SGE enva un mensaje con ID asignado al JOB en el
sistema llamado Job-ID (es un numero mayor a 10), de la siguiente forma
5. $ Your Job 104 (lanza_wrf.sh) has been submitted
Los scripts se detallan a continuacin:
lanza_roms.sh
#!/bin/bash
#$ -S /bin/bash
#$ -q all.q
# The batch system should use the current directory as working directory.
#$ -cwd
# Name your job. Unless you use the -o and -e options, output will
# go to a unique file name.ojob_id for each job.
#$ -N RomsDaniel
# Redirect output stream to this file.
#$ -o output.dat
# Join the error stream to the output stream.
#$ -j yes
# Send status information to this email address.
#$ -M [email protected]
# Send me an e-mail when the job has finished.
#$ -m eb
# Specify the amount of virtual memory given to each MPI process
# in the job.
#$ -l h_vmem=30G
# Use the parallel environment "openmpi-fillup", which assigns as many processes
# as available on each host. Start 18 MPI processes across an arbitrary number of
# hosts. For each process, SGE will reserve one CPU-core.
#$ -pe mpich 50
## ALTERNATIVE
/share/apps/intel/impi/2017.2.174/intel64/bin/mpirun -np 18 ./roms roms.in

lanza_wrf.sh
#!/bin/bash
#$ -S /bin/bash

1
En ROMS es: Ruta de Instalacin/Roms_Tools/Run/ROMS_FILES
En WRF es: Ruta de Instalacin/Test/em_real
#$ -q all.q
# The batch system should use the current directory as working directory.
#$ -cwd
# Name your job. Unless you use the -o and -e options, output will
# go to a unique file name.ojob_id for each job.
#$ -N wrfDaniel
# Redirect output stream to this file.
#$ -o output.dat
# Join the error stream to the output stream.
#$ -j yes
# Send status information to this email address.
#$ -M [email protected]
# Send me an e-mail when the job has finished.
#$ -m eb
# Specify the amount of virtual memory given to each MPI process
# in the job.
#$ -l h_vmem=30G
# Start 18 MPI processes across an arbitrary number of
# hosts. For each process, SGE will reserve one CPU-core.
#$ -pe mpich 220
## ALTERNATIVE
/share/apps/intel/impi/2017.2.174/intel64/bin/mpirun -np 200 ./wrf.exe

Explicacin detallada (lanza_wrf.sh y lanza_roms.sh poseen la misma

estructura)
LINEA DE CODIGO FUNCION
#!/bin/bash Cabecera de script
#$ -S /bin/bash Interprete bash
#$ -q all.q Usar queue (cola) all.q
# The batch system should use the current directory as working
directory.
#$ -cwd Ejecutar en este mismo
directorio
# Name your job. Unless you use the -o and -e options, output will
# go to a unique file name.ojob_id for each job.
#$ -N RomsDaniel Nombre de Job en SGE
# Redirect output stream to this file.
#$ -o output.dat Archivo de salida de
informacin
# Join the error stream to the output stream.
#$ -j yes Juntar el archivo de error con
el de salida de datos
# Send status information to this email address.
#$ -M [email protected] Correo por defecto para envio
de sucesos en SGE
# Send me an e-mail when the job has finished.
#$ -m aeb Enviar correo cuando el
lanzamiento del modelo
(a)bort, (b)egin y (e)nd
# Specify the amount of virtual memory given to each MPI
process
# in the job.
#$ -l h_vmem=30G Memoria asignada a job, en
 cada nodo
# Use the parallel environment "openmpi-fillup", which assigns as
many processes
# as available on each host. Start 18 MPI processes across an
arbitrary number of
# hosts. For each process, SGE will reserve 1 CPU-core.
#$ -pe mpich 50 Usar el parallel environment
(entorno en paralelo), llamado
mpich y reserva 50
procesadores del cluster
## ALTERNATIVE
/share/apps/intel/impi/2017.2.174/intel64/bin/mpirun -np Lanzar mpirun Intel sobre 18
18 ./roms roms.in procesadores (deben ser
siempre menos que los que
han sido reservados)

Operaciones sobre Jobs ya cargados a SGE

Comando Descripcin
$ qhold Job-ID Suspender Job
$ qrls Job-ID Reanudar Job
$ qalter Job-ID Cambiar privilegios de ejecucin de un
Job que aun esta espera
$ qdel Job-ID Borrar un Job de SGE

LANZAMIENTO CON INTERFASE GRAFICA QMON

1. Ejecutar qmon
$ qmon
 Lanza_wrf.s
h Activar
2. Activar Submit Jobs (Datos Generales) CheckBox

Lanzar JOB

Activar
CheckBox

Seleccionar
archivo Job
Script

3. Activar Submit Jobs (Datos Avanzados)

mpich 200

wrf
4. Seleccionar archivo Job Script

5. Monitoreo
Lnea de Comandos
Comando Descripcin
$ qstat Una vista del Job
$ qstat -f Una vista del Job y su distribucin en
los nodos
$ qhost Carga de job en los nodos
MEDIANTE INTERFASE GRAFICA
Desde Qmon Activar Job Control
La interfase grafica nos presenta tres tipos de Jobs: Pendientes de Ejecucion
(pending Jobs), En ejecucin (Running Jobs) y Terminados (Finished Jobs)
En la misma ventana, estando seleccionado el Job de nuestro inters, es posible
Suspender (Suspend), Reanudar (Resume), Borrar (Delete). De la misma forma
que se ha mostrado en las opciones accesibles a travs de la lnea de comandos.
Procedimiento de gestin de Colas (Queues)
Las colas son paquetes de recursos prestos a ser usados por parte de Jobs SGE
bajo la tutela de los Owners (propietarios), definidos en SGE. Para el lanzamiento
de un Job, no es obligatorio en crear una Cola especifica para el mismo, ya que
existe la Cola para Todos, que es una cola por defecto que puede ser usada por
todo Job, que se desee lanzar sin que este asignado a una como tal.

Los criterios de creacin de colas son variados, desde usuarios de una misma
aplicacin hasta grupos de trabajo de un rea determinada de la institucin. En
nuestro caso, se han creado colas para los siguientes tipos de usuarios:

Creacin de colas (queue)

Comando Descripcion
$ qconf -aq nombre_cola Crea cola con editor vi, bajo plantilla
existente
$ qconf -sql Muestra todas las colas existentes
$ qconf -sq Queue_nombre Muestra propiedades de una cola en
particular
$ qconf -scl Lista de recursos disponibles via el
objeto complexes
$ qconf -sc complex_nombre Recursos aisgnados a un objeto
complexe
Ejemplos de Salida de datos (Creacion de cola con aparicion de plantilla en Editor
VI)
[wrf@frontend-hpc ~]$ qconf -aq ColaEjemplo

qname ColaEjemplo
hostlist NONE
seq_no 0
load_thresholds np_load_avg=1.75
suspend_thresholds NONE
nsuspend 1
suspend_interval 00:05:00
priority 0
min_cpu_interval 00:05:00
processors UNDEFINED
qtype BATCH INTERACTIVE
ckpt_list NONE
pe_list make
rerun FALSE
slots 1
tmpdir /tmp
shell /bin/csh
prolog NONE
epilog NONE
shell_start_mode posix_compliant
starter_method NONE
suspend_method NONE
resume_method NONE
terminate_method NONE
notify 00:00:60
owner_list NONE
user_lists NONE
xuser_lists NONE
subordinate_list NONE
complex_values NONE
projects NONE
xprojects NONE
calendar NONE
initial_state default
s_rt INFINITY
h_rt INFINITY
s_cpu INFINITY
h_cpu INFINITY
s_fsize INFINITY
h_fsize INFINITY
s_data INFINITY
h_data INFINITY
s_stack INFINITY
h_stack INFINITY
s_core INFINITY
h_core INFINITY
[wrf@frontend-hpc ~]$ qconf -sql
ColaEjemplo
all.qs_rss INFINITY
h_rss INFINITY
s_vmem INFINITY
h_vmem INFINITY
qname ColaEjemplo
hostlist NONE
seq_no 0
load_thresholds np_load_avg=1.75
suspend_thresholds NONE
nsuspend 1
suspend_interval 00:05:00
priority 0
min_cpu_interval 00:05:00
processors UNDEFINED
qtype BATCH INTERACTIVE
ckpt_list NONE
pe_list make
rerun FALSE
slots 1
tmpdir /tmp
shell /bin/csh
prolog NONE
[wrf@frontend-hpc ~]$ qconf -sql
ColaEjemplo
all.qepilog NONE
shell_start_mode posix_compliant
starter_method NONE
suspend_method NONE
resume_method NONE
terminate_method NONE
notify 00:00:60
owner_list NONE
user_lists NONE
xuser_lists NONE
subordinate_list NONE
complex_values NONE
projects NONE
xprojects NONE
calendar NONE
initial_state default
s_rt INFINITY
h_rt INFINITY
s_cpu INFINITY
h_cpu INFINITY
s_fsize INFINITY
h_fsize INFINITY
s_data INFINITY
h_data INFINITY
s_stack INFINITY
h_stack INFINITY
s_core INFINITY
h_core INFINITY
s_rss INFINITY
h_rss INFINITY
s_vmem INFINITY
h_vmem INFINITY

Ejemplos de Salida de datos (Listado de Colas Existentes)

[wrf@frontend-hpc ~]$ qconf -sql

ColaEjemplo (Cola creada en el ejemplo anterior)
all.q
ACL (Access Lists)
Comando Descripcin
% qconf -sul Muestra las listas disponibles en SGE
% qconf -su acl_nombre Detalles de lista determinada

En nuestro caso analizaremos algunos ejemplos de salida realizados en el Cluster

HPC-Imarpe
Ejemplos De salida
[wrf@frontend-hpc ~]$ qconf -sul
Test001 (Conjunto de usuarios creados como Test)
arusers
deadlineusers
defaultdepartment

[wrf@frontend-hpc ~]$ qconf -su Test001

name Test001
type ACL
fshare 0
oticket 0
entries roms,wrf