Entregable D4 20 de diciembre de 2017 Soluciones de RICAP para un uso eficiente de infraestructuras computacionales Entregable D4 20 de diciembre de 2017

Define la arquitectura óptima Para paralelizar una aplicación científica acoplada (sus partes no son independientes), hay que definir la granularidad de la división (cuán pequeñas hacemos las particiones) En un cálculo HTC, la división es de todas y cada una de las partes del cálculo independientes La granularidad es una medida de la cantidad de computación de un proceso software Se considera como el segmento de código escogido para su procesamiento paralelo Define la arquitectura óptima

Ejemplo de granularidad

El siguiente paso es analizar cómo reducir el tiempo de ejecución ¿Por qué no se ejecuta eficientemente? ¿Dónde se encuentran los puntos críticos del código? Principio de Pareto o Regla 80/20 Paralelizar aquellas partes idóneas para ellas Optimización

La optimización se produce a partir de varios factores Tipo de procesador Procesos de Entrada / Salida en el código Uso y acceso a la memoria de la infraestructura Llamadas al sistema Conocimiento del código Es muy común el uso de herramientas para saber cómo se comporta el código (profiling) Indican qué partes del código consume más recursos

Algunos ejemplos de técnicas a tener en cuenta Procesador Opciones de compilación para optimización secuencial y paralelización automática Técnicas de optimización para mejorar la explotación de la arquitectura y de la memoria caché Inclusión de directivas de paralelización en el código Entrada/Salida Reorganizar E/S para evitar muchas peticiones cortas Funciones para mapear ficheros en memoria Funciones para indicar al sistema el uso de las páginas de fichero en memoria

Algunos ejemplos de técnicas a tener en cuenta Memoria virtual Técnicas de optimización para mejorar la explotación de la memoria virtual Funciones para indicar al sistema el uso de las páginas de fichero en memoria Conocimiento del código Aplicación de distintos modelos para un mismo dato de entrada Bucles Cálculos más pesados

Ya se dispone de Una infraestructura paralela o distribuida Un código adaptado para su ejecución en esa infraestructura ¿Se pueden usar todos los procesadores de los que dispone la infraestructura? La respuesta es NO

Las infraestructuras computacionales a partir de cierto tamaño están Compartidas por varios usuarios Gestionadas por administradores Con permisos para el uso de los recursos superiores a los de los usuarios Los administradores implementan reglas de uso (AUP) que delimitan El software que está instalado El nº de recursos al que cada usuario puede acceder El empleo de esos recursos para que la máquina esté operativa de la forma más eficiente posible

Se instalan programas destinados a la gestión de los recursos computacionales y una buena calidad de servicio (QoS) Sistemas de colas batch Las peticiones de trabajos a ejecutarse (con un nº de recursos solicitados) se encolan para irles dando prioridad Portable Batch System (PBS, Slurm) que provee una serie de comandos con los que se ejecuta el envío de trabajos Sistema de gestión de carga para entornos distribuidos HTC Librerías que permiten la coordinación e intercomunicación de los trabajos paralelos o distribuidos MPI, OpenMP, DRMAA… Herramientas de monitorización de recursos y sistemas de información de sites

Algunas de estas labores las puede hacer también el usuario Para conseguir esa optimización del uso de la infraestructura, es conveniente realizar labores de Configuración y mantenimiento de los recursos Planificación de qué recursos se asignan a qué cálculo/usuario Aprovisionamiento de recursos Algunas de estas labores las puede hacer también el usuario Implementación de herramientas que permiten definir cómo se va a ejecutar el trabajo Estas labores pueden ser Manuales, automáticas o semiautomáticas Estáticas o dinámicas

Planificación y gestión en HPC

Ejemplos típicos de políticas de uso de un supercomputador Nº máximo de procesadores permitidos a un único usuario Nª máximo de trabajos permitidos a un único usuario Nº máximo de procesadores y trabajos permitidos a un grupo de usuarios Tiempo máximo que puede durar un trabajo ejecutándose Porcentaje reservado para la ejecución de trabajos paralelos Los gestores de recursos disponen de algoritmos de planificación que gestionan la carga del supercomputador acorde a las políticas anteriores Estos algoritmos también se pueden diseñar e implementar para que actúen sobre el gestor de recursos

Para ello, se necesita de Para mejorar la eficiencia o resolver fallos de ejecución, se realiza la migración de tareas Secuenciales Paralelas Contendores Para ello, se necesita de Gestor de recursos LRMS (Slurm, PBS…) Librería de puntos de chequeo (DMTCP, BLCR…) Librería de paso de mensajes MPI (MPICH3, MVAPICH2…) Hipervisores de entornos virtualizados (KVM, Xen) Gestores de entornos virtualizados (OpenNebula, OpenStack…)

Puede ser útil la compactación de tareas Para liberar recursos que requieran de trabajos paralelos Para dejar parte del supercomputador libre con el fin de realizar trabajos de configuración, actualización, apagado… Aumentar la localidad para reducir el tiempo empleado en la gestión de los recursos (overhead), por ejemplo, el ancho de banda de procesos con pasos de mensajes MPI

A veces, por el contrario, se aumentará el rendimiento planificando tareas en distintos nodos Cuando se migran tareas, también ha de tenerse en cuenta cuáles son las más demandantes de recursos (en uso de memoria, por ejemplo) para ver cuáles van antes y cuáles van después

¿Qué pasa si tenemos un cálculo paralelo de 1 millón de tareas y una falla? ¿Hemos de empezar de nuevo con el coste energético y computacional que eso origina? Relacionado con la migración de tareas se encuentra la tolerancia a fallos El código y el sistema están preparados para responder a posibles errores imprevistos Se hace mediante metodologías de puntos de chequeo (checkpointing) y detección proactiva de errores (SW y HW) Dan robustez al sistema, lo que redunda principalmente en que las ejecuciones sean desatendidas

Planificación, aprovisionamiento y gestión en HTC Algunos de los conceptos anteriormente citados son válidos, pero el escenario es distinto Sites heterogéneos distribuidos geográficamente Distintos recursos (potencia de cálculo, memoria, etc.) Distintas configuraciones Distinto ancho de banda para acceder a ellos Mover volúmenes de datos más o menos grandes Mayor posibilidad de fallos El problema de ajustar carga de trabajo y recursos disponibles es por definición es NP-Completo Nondeterministic Polynomial time Únicamente se pueden hallar soluciones sub-óptimas

El mayor problema en este tipo de infraestructuras es que los Sistemas de Información (IS) no publican información real Nº de trabajos que se aceptan o Máquinas Virtuales (MV) que se pueden levantar Por usuario Por Organización Virtual Estado en el que se encuentran los recursos Las infraestructuras HTC son mucho más dinámicas ¿Cómo hago la división de mi cálculo para que se ejecute de forma eficiente? ¿Qué posibilidades existen de provisionar (“reservar”) recursos por anticipado?

La planificación de tareas en entornos HTC es objeto de varias líneas de investigación Replicación de tareas M/N (con M>N) La proporción M/N se obtiene a través de la tasa media de finalización de tareas en el sistema Bolsa de tareas (Bag of tasks) Agrupamiento de tareas Se determina el tamaño del chunk ≡ nº de samples Pero en general… No se ha tenido en cuenta el carácter dinámico de la infraestructura No se ha estimado el overhead Las soluciones se han probado en simuladores

Pending Prolog Execution Epilog Infraestructura física Computación Grid Gestión de trabajos computacionales Infraestructura virtualizada Computación en la nube Gestión de MM.VV y trabajos

DINÁMICO Pending Prolog Execution Epilog Estatus de la infraestructura Número de tareas a ejecutar

DINÁMICO DINÁMICO Pending Prolog Execution Epilog Tamaño de los ficheros de entrada/salida Puede conocerse antes de la ejecución Conexión de red local y remota Aproximadamente constante para cada site

DINÁMICO Pending Prolog Execution Epilog Rendimiento del sitio remoto Aproximadamente constante para cada site Fluctuaciones dependiendo del uso

Posibilidades para la planificación y aprovisionamiento de recursos Pending Prolog Execution Epilog Métodos vinculantes iniciales (early-binding): la carga se planifica antes de que se asignen los recursos Métodos vinculantes finales (late-binding): se actúa sobre la asignación de recursos (provisioning)

Posibilidades para la planificación y aprovisionamiento de recursos Pending Prolog Execution Epilog Métodos vinculantes iniciales (early-binding): la carga se planifica antes de que se asignen los recursos Métodos vinculantes finales (late-binding): se actúa sobre la asignación de recursos (provisioning)

El punto de partida es que hay que modelar problemas complejos que generalmente siguen un patrón (Muchas) Simulaciones + Matemáticas Números aleatorios para inicializar simulaciones Tareas simples e independientes Estadística u operaciones diversas para unir los resultados Inicialización (I): tiempo constante y/o variable Simulación (S): tiempo variable Análisis de los resultados (R): tiempo constante y/o variable Tejec = Ic + Iv· N + Sv· N + Rc + Rv· N ~ a· N + b (con N = número de samples)

Se hace un estudio de cómo se ejecuta el código de interés en cada site (profiling) Realizar 1, 10, 100, 1.000… simulaciones (u otra serie) Obtener a y b (recordemos que Tejec ~ a· N + b) Ejecutar el benchmark Whetstone en el mismo site Adecuado para monoprocesadores Normalizar Repetir este proceso en varios sites para evitar distorsiones

Se actualiza la información de cada site Cada vez que cambia algo en él (memoria, CPU…) o aparece uno nuevo Globus Monitoring & Discovering System Después de cada ejecución Rendimiento Eficiencia, tareas fallidas, slots disponibles Tiempo de cola Ancho de banda Los resultados tras cada ejecución se ponderan Fórmula de Biessel Las ejecuciones nuevas cuentan más que las viejas

Con toda esa información, se diseña un algoritmo que decide cómo y dónde se ejecuta el código Para tener una eficiencia optimizada Para alcanzar una política de tiempo máximo de espera de resultados Se implementa una herramienta que con ese algoritmo (u otro, ha de ser modular) sirva como interfaz para el usuario Utiliza información estática y dinámica Actúa en 2 niveles: recurso local y remoto Produzca un overhead lo menor posible

Posibilidades para la planificación y aprovisionamiento de recursos Pending Prolog Execution Epilog Métodos vinculantes iniciales (early-binding): la carga se planifica antes de que se asignen los recursos Métodos vinculantes finales (late-binding): se actúa sobre la asignación de recursos (provisioning)

La planificación se desarrolla para mejorar el rendimiento de El objetivo es implementar metodologías que actúen directamente sobre los recursos remotos más allá de una obtención precisa de su información Se sigue una estrategia de caballo de Troya (trabajos pilotos o pilot jobs) Aprovisionamiento de recursos La planificación se desarrolla para mejorar el rendimiento de La ejecución del código cumpliendo los requisitos computacionales del mismo Las MM.VV. que se hayan iniciado (si estamos en la nube) La localización de los datos para la distribución de trabajos

Aunque no únicamente, se desarrolla sobre infraestructuras federadas En la nube, se actúa sobre IaaS (Infrastructure-as-a-Service) Correo-e, Escritorio remoto, Aplicaciones… Entorno de desarrollo, BBDD, Serv. Web MV, Servidores, Almacenamiento, Red…

Los sistemas de pilotos (pilot systems) han de Ser capaces de gestionar grid y cloud E incluso clústeres locales y computación voluntaria Ser compatibles con aplicaciones ya portadas a HTC Mejorar la productividad y rendimiento previo Ser interoperables con estándares ya desarrollados para distintas infraestructuras Ser configurables por el usuario para adaptarse a las necesidades del código Gestionar adecuadamente trabajos de corta duración Peor escenario para pilot systems

Legacy Application GWpilot Factory GWcloud Execution Driver Server CLI task launching applications Launching applications GWpilot Factory pilots GWcloud Execution Driver Server task CLI DRMAA BES Scheduler GridWay Core OCCI GWcloud Information Driver task HTTPS pull IaaS Federation abstraction LDAP Top BDII Provider A Provider B Federated IaaS Cloud task

Como en el caso anterior, se diseña un algoritmo que decide cómo y dónde se ejecuta el código y se implementa una herramienta que sirva como interfaz para el usuario Para reducir el overhead en la nube, lo ideal es levantar una MV para cada trabajo Si estamos en la nube y estamos accediendo a una infraestructura privada, hay que tener en cuenta el coste económico además Es posible acoplar herramientas de early- y late-binding para maximizar el uso de la infraestructura (stacking)

Existe una variedad de herramientas que implementan las metodologías explicadas anteriormente Algunas de ellas son módulos integrados en los gestores de recursos (LRMS) Aquí se mostrarán algunos resultados de las herramientas desarrolladas en el CIEMAT Early-binding  Montera Late-binding  GWpilot

Montera es una aplicación Phyton residente en el área de usuario API para la creación de chunks y controlar la ejecución local Plantilla name=isdep.sh num_samples=5000 input_files=isdep.sh, lgv_LHD_ion_2species. files.tar.gz, crea_input, config_mag_LHD.ini output_files=output${TASK_ID}.tar.gz scheduling_policy=dytss max_profiling time (optional) environment_variables (optional Comando final run.montera template.mt

Dynamic Trapezoidal Self Scheduling Algoritmo implementado para Montera Asymptotic performance Half performance length Necesita Profiling de los Monte Carlo (o códigos muy desacoplados) Profiling de los Recursos Funcionamiento (simplificado) Más samples a los recursos más potentes (chunk) Replicación de tareas para evitar cuellos de botella en tiempo real, no sólo al principio

Deadline Policy (Entorno real de producción EGI) Ejecución de tantas tareas de FAFNER2 como sea posible en 2.000 s

Adaptación a slots libres (ce01-tic.ciemat.es)

DyTSS (Entorno real de producción EGI) 5.000 partículas (~ 10% de un caso real de estudio de FastDEP) UMD es el planificador más usado en EGI GridWay es el planificador en el que está basado Montera   Montera Scheduler/Montera [hh:mm] GridWay UMD Walltime 60:26 1,16 1,62

Walltime GW / Walltime Montera DyTSS (Entorno real de producción EGI) 4·108 partículas (caso real de estudio de BeamNRC) Simulated samples Walltime GW / Walltime Montera   50 tasks 100 tasks 250 tasks 10 4 0,7 0,9 4,6 10 6 1,1 1,4 2,4 10 8 1,8 1,5 1,3

Comparativa de sistemas de pilotos

GWpilot ( DKEsG – Entorno real de producción EGI) 5·105 tareas independientes (configuración estándar del TJ-II)

GWpilot (Entorno real de producción EGI FedCloud) 4·108 partículas (caso real de estudio de BeamNRC)

GWpilot + DyTSS (Entorno real de producción EGI FedCloud) 2·107 partículas (caso real de estudio de Nagano)

Referencias y ampliación de contenido Computación de Altas Prestaciones y Aplicaciones – Ignacio Martín Llorente (Coord. Máster Ingeniería Informática UCM) Ejecución eficiente de códigos Monte Carlo en infraestructuras Grid – Manuel A. Rodríguez Pascual (tesis doctoral) Planificación multinivel eficiente con aprovisionamiento dinámico en Grids y Clouds – Antonio J. Rubio Montero (tesis doctoral)

Red Iberoamericana de Computación de Altas Prestaciones (RICAP) http://www.red-ricap.org RICAP is partially funded by the Ibero-American Program of Science and Technology for Development (CYTED), Ref. 517RT0529.