Servicios de Asignación y Planificación de Recursos Grid Grupo de Computación Grid Instituto de Física Corpuscular (CSIC/UV) Valencia Álvaro Fernández

Servicios de Asignación y Planificación de Recursos Grid

Grupo de Computación Grid Instituto de Física Corpuscular (CSIC/UV)

Valencia

Álvaro Fernández Casaní

IFIC - INSTITUTO DE FÍSICA CORPUSCULAR

Jornadas Técnicas RedIris 2003


2

Contenido

Problemática de la gestión de recursos Servicios grid Arquitectura de servicios utilizada en el proyecto Eu-

Crossgrid Componentes:

Scheduling Agent Resource Selector Aplication Launcher

Conclusiones y Trabajo Futuro


3

PROBLEMÁTICA DE LA GESTIÓN DE RECURSOS

GRID aúna recursos distribuidos heterogéneos, pertenecientes a diferentes organizaciones

Diferentes tipos de recursos: Hardware Software Red Tiempo Datos

Objetivo: Proveer acceso eficiente a estos recursos Acceso transparente y simple Requerimientos de varios usuarios Organización temporal

Problemas: Sistema heterogéneo y dinámico


4

RESOURCE MANAGERS

Diferencia entre planificadores locales, y de alto nivel Planificadores locales:

Acceso a recursos locales Control de:

Políticas Seguridad Accounting

Planificación basada en reducir tiempo de respuesta de ejecución los trabajos: algoritmos FCFS, BackFilling, List Schedulling

Planificadores alto nivel: Sobre múltiples planificadores locales Acciones:

Descubrir recursos Recoger información y decidir cuáles usar Ejecución

Planificación basada en políticas de coste de acceso, prioridades, accounting


5

SERVICIOS PARA LA GESTIÓN DE RECURSOS

Para soportar la gestión de recursos los planificadores de alto nivel, se valen de servicios en forma de middleware:

Acceso a los recursos/planificadores locales (GRAM) Sistemas de información (GIS, MDS, GMA)

Por encima de estos: Resource Brokers (Datagrid WMS)

Selección de recursos: Matchmaking Envío de Trabajos: Job Submission Service Base de datos de trabajos: Logging and bookeeping

Scheduling Agents Decisiones de planificación dependiendo de requerimientos

estáticos y dinámicos Ampliación de selección de recursos


6

Proyecto Crossgrid: objetivos en planificación de recursos

Soportar servicios de planificación de recursos para aplicaciones interactivas, intentado garantizar un compromiso entre la utilización de recursos y el speed-up de la aplicación

Principalmente: Soporte para aplicaciones paralelas (MPI) sobre uno o

varios recursos (sites) distribuidos Soporte a aplicaciones interactivas con requerimientos

de alta prioridad Soporte a aplicaciones compuestas de múltiples

subprocesos: DAGs Primeros prototipos basados en Middleware Datagrid

(version 1.4.8)


7

ARQUITECTURA GENERAL

GSI

Job Manager

Llamadas al API Gram para pedir reserva del recurso

Y creacion de procesos

Llamadas al API del MDSPara localizar recursos

Preguntar el estadoActual del recurso

Crear

RSL Library

Parse

PeticiónCreación de

procesos

Process

Process

Process

Control y Monitorización

ResourceBroker / SA MDS: Grid Index Info Server

Gatekeeper (CE)

MDS: Grid Resource Info Server

Local Resource Manager


Creacion de callbacksPara notificar cambios

De estado

SCHEDULING

WN WN

WN WNStorage Element (SE)

UI

PORTAL/RAS


8

Principales componentes del RB/SA

Ejecución típica de pasos de scheduling para 1 trabajo por el Scheduling Agent:

1 - Recepción del trabajoResource Searcher: 2 - Búsqueda de recursos 3 – Planificación y

Prioridades 4 – Reserva TemporalAplication Launcher: 5 - Envío del trabajo 6 - Monitorización 7 - Finalización

RS

AL

ResourceBroker / SA

Gatekeeper (CE)

MDS/RGM

A

Condor-G

ResourceManagement


9

1 – Recepción del trabajo

El usuario manda su trabajo junto con una descripción del mismo al RB/SA

Descripción en JDL Especifica tipo de trabajo, requerimientos, función de

preferencia El RB/SA mantiene lista de trabajos recibidos

Guarda el estado de cada uno Permite reenvío de los trabajos que pudieran fallar Contacta el RS para la siguiente fase: búsqueda de recursos

ResourceBroker / SA

JobType= mpich-g2NumCpus = 7Executable = “my_app”Requirements = “RH 6.2”Rank = AverageSI


10

2 – Resource Selector: Búsqueda de recursos

Se utiliza los Classads (Condor) para localizar recursos que cumplan requerimientos del trabajo.

Tiene en cuenta autorización y requerimientos de datos Sólo se utilizan CEs dónde se está autorizado (pre-match) Se utilizan campos del JDL para los requerimientos de datos:

OutputSE, InputData, DataAccess Protocol Se buscán CEs con el OutputSE cerca Se prefieren CEs con mayor número de archivos esté también

en el OutputSE Se utiliza el matchmaking simple (1 a 1) para trabajos batch, y set-

matching (1 a muchos) para trabajos paralelos

Llamadas al API del MDSPara localizar recursosResource

Broker / SAMDS: Grid Index Info Server

MDS: Grid Resource Info Server


JOB

CE1 CE2

CE3

RS


11

Matching 1 a 1

matching 1 a 1 (trabajos batch secuenciales): selecciona un CE que cumpla todos los requerimientos,

ordenado por la función de preferencia: 1º) Búsqueda de sites (CE) que cumplan requerimientos

del trabajo Sistema operativo, software instalado, disponibilidad de

datos, etc. Matching 1 a 1

2º) Ordenación de sites (CE) por función de preferencia: Se consultan principalmente los requerimientos dinámicos: Cpus libres, memoria disponible, Matching 1 a 1

Para trabajos mpi con requerimientos de múltiples recursos se utiliza set matching (matching 1 a muchos)


12

Set-matching para trabajos mpi

Necesitamos hacer un set-matching de un trabajo con varios recursos Ahora debemos:

1º) Igual al anterior, búsqueda de sites (CE) que cumplan requerimientos estáticos (cada recurso debe cumplirlo)

Sistema operativo, software instalado, etc. Matching 1 a 1

2º) Con los recursos anteriores, formar grupos de CE que conjuntamente cumplan requerimientos

Cpus libres, espacio en disco disponible total Matching 1 a muchos

se ordenan con el siguiente criterio:1. Grupos con menor número de CEs son seleccionados primero

(Preferible ejecutar sobre un único CE)2. Para grupos con el mismo número de CEs, se ordenan con la funcion

de preferencia (ponderada con el número de cpus libres que aportan)

Para correr trabajos en un único CE se puede utilizar mpich-p4 Para correr trabajos en distintos CEs se utiliza mpich-g2


13

Ej. Búsqueda recursos para trabajo mpich-g2 sobre varios sites

JobType= “mpich-g2”NumCpus = 7Executable = “my_app”Requirements = “RH 6.2”Rank = AverageSI

RS

CE5FreeCPUs=8AverageSI=2000

CE5


CE3


CE1 CE2FreeCPUs=2AverageSI=3500

CE2


CE4

CE

CE

Soporta mpich-g2

No soporta mpich-g2


14

Ej. Búsqueda recursos para trabajo mpich-g2 sobre varios sites

Estrategia de búsqueda: 1 – CEs con todas los

requerimientos y cpus libres:

JobType= “mpich-g2”NumCpus = 7Executable = “my_app”Requirements = “RH 6.2”Rank = AverageSI

RS


CE5


CE3


CE1 CE2FreeCPUs=2AverageSI=3500

CE2


CE4


CE1

2 - Grupos de CEs que conjuntamente cumplan requerimientos y cpus libres:

CE2 CE4CE2 + CE4FreeCPUs=7AverageSI=2428

CE3 CE4CE3 + CE4FreeCPUs=8AverageSI=1625

CE3 CE4CE2

CE

CE

Soporta mpich-g2

No soporta mpich-g2


15

3 - Prioridades

Cuando tenemos varios trabajos podemos establecer prioridades entre ellos:

En el JDL se indica una prioridad relativa a otros trabajos Establecen el orden de búsqueda de recursos y envío de

trabajos Pueden servir para parar trabajos menos prioritarios

(batch) y ejecutar trabajos interactivos Pare esto se necesita un método de apropiación de

recursos “preemtion mechanism”) y suspensión temporal de trabajos.


16

4 - Reserva temporal

Puede que se produzca el caso de que al mandar un trabajo mpi a varios sites se produzca interbloqueo con otro:

Los procesos esperan a que todos estén inicializados para empezar

Puede haber diferencias entre los datos del SI y la información real

Un trabajo puede estar esperando que se inicie un proceso en un nodo ocupado por otro trabajo que espera al primero.

Para solucionarlo se establece un sistema de reservas temporales en el RB que afecta al RS

Se reservan el número de cpus en cada recurso No se tienen en cuenta para siguientes selecciones del RS Cuando acaba el trabajo o falla se quita misma.


17

5 - Aplication Launcher: Ejecución del trabajo

El siguiente paso es enviar el trabajo de forma fiable a los recursos.

El AL es responsable de mandar el ejecutable y los distintos ficheros (GridFtp) al CE o grupo de estos donde se ejecuta el trabajo.

Recibe del Resource Selector la lista de recursos ordenados donde enviar el trabajo

Se utilizan las prioridades para determinar el orden de envío de trabajos

Para un trabajo, se prepara script que se manda a Condor G:

Es un gestor sobre Globus (GRAM) para reenvío fiable de trabajos fallidos.

No toma ninguna decisión de planificación


18

Tipos de trabajos

Dependiendo del tipo de trabajo se utilizará una u otra aproximación:

Trabajos “batch”: se manda al CE/JobManager y su planificador local decide cuándo se ejecuta y en qué WN

Trabajos “mpich-p4”: se manda al CE/Jobmanager indicando trabajo mpi:

Se manda un solo trabajo que será el que ejecute los siguientes pasos. Condor-G permite el envío del mismo

Se reservan a través del planificador local los nodos (WN) necesarios

Se ejecuta mpirun sobre los nodos (WN) reservados


19

Tipos de trabajos (II)

Trabajos “mpich-g2”: MPICH-G2: implementación mpi para correr sobre globus.

Utiliza los servicios globus de autenticación, asignación de recursos, movimiento de ficheros, salida de datos

Se mandan n diferentes trabajos, que son coordinados por el AL.

Ejecución simultánea en recursos: utilización de librería DUROC

Condor-G no da soporte a múltiples rsl, por lo que se utiliza el “universo scheduler” y se llama a programa lanzador auxiliar del AL.

Requieren que los WN tengan direcciones públicas (RS lo tiene en cuenta)


20

Envío de Trabajos Mpich-G2 El Aplication Launcher manda un script por cada tarea(proceso)

mpich-g2 a Condor-G Condor-G envía cada tarea a su correspondiente CE, que lo envíara

a su planificador local Cuando el script finalmente se ejecuta en un WN, realiza las

funciones para obtener ficheros, etc.. Y lanza el ejecutable real Este ejecutable espera en una barrera (DUROC), enviando mensaje

de sincronización al AL Una vez que el AL ha recibido el mensaje de sincronización de

todas las tareas, manda la orden de ejecución Puede haber problemas:

Si falla la red, nodos, una tarea, AL AL puede quedarse esperando indefinidamente, esperando la

sincronización Soluciones:

Matar todos los procesos Quitar trabajo de la cola y volverlo a mandar a otros recursos (RS)


21

6 y 7 - Monitorización y Finalización

Durante la ejecución del trabajo se utiliza Condor-G para monitorizar el funcionamiento y ejecución.

Todos los cambios de estado se guardan en base de datos permanente.

Cuando el trabajo falla se puede reenviar a este u otro recurso

Al finalizar se recoge la salida del programa y se guarda en el RB/SA. Los datos puedes ser obtenidos desde por el usuario desde ese momento.

Se liberan todos los recursos ( almacenamiento en memoria secundaria, etc).


22

Trabajo Futuro

Incluir métodos de preemción de trabajos secuenciales, para aplicaciones interactivas más prioritarias.

Mejora de la escalabilidad del sistema. Distribuir los componentes para mejorar la estabilidad.

Métodos de selección de recursos basados en predicciones e información dinámica sobre el estado de la red.

Pasar los servicios actuales a la nueva versión de Datagrid 2.X.

Soporte nativo a trabajos interactivos y DAGs en esta versión.


23

Conclusiones

Servicios de gestión de recursos para aplicaciones secuenciales y paralelas mpi sobre uno o varios clusters:

Scheduling Agent Resource Searcher Aplication Launcher

Basado en middleware Datagrid (v1.4.8), y éste en Condor-G y Globus.

Componentes implementados sobre el RB de edg, todavía entidad centralizada. Pasando ahora a arquitectura distribuída.

Desarrollos de métodos de selección múltiple de recursos, reserva temporal, aplicación de prioridades y ejecución de las aplicaciones secuenciales y paralelas.


24

Más información…

Álvaro Fernández ( [email protected]) Miquel A. Senar ([email protected]) Elisa Heyman ([email protected]) Proyecto Crossgrid (http://www.eu-crossgrid.org)

¿Preguntas ahora?

Documents

Servicios de Asignación y Planificación de Recursos Grid Grupo de Computación Grid Instituto de Física Corpuscular (CSIC/UV) Valencia Álvaro Fernández