Implementación de sistema de monitorización OG3 en el supercomputador MareNostrum 5

Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca Grado en Ingeniería Informática - Tecnologías de la Información Memoria del Trabajo Final de Grado TÍTULO: IMPLEMENTACIÓN DE UN SISTEMA DE MONITORIZACIÓN OG3 EN EL SUPERCOMPUTADOR MARENOSTRUM 5 AUTOR: BAÑO VACA, ANTONY JOEL DIRECTOR: BARTOLOMÉ, JAVIER PONIENTE: MARIN TORDERA, EVA FECHA DE PRESENTACIÓN: FEBRERO, 2025 (Q1 2024-2025) Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 2 RESUMEN Este Trabajo de Fin de Grado tiene como objetivo desarrollar e implementar un sistema de monitorización para el supercomputador MareNostrum 5, que recientemente ha entrado en producción. Este sistema está diseñado para facilitar la supervisión en tiempo real de los nodos y la infraestructura asociada en entornos de computación de alto rendimiento (HPC). RESUM Aquest Treball de Fi de Grau té com a objectiu desenvolupar i implementar un sistema de monitoratge per al supercomputador MareNostrum 5, que recentment ha entrat en producció.Aquest sistema està dissenyat per facilitar la supervisió en temps real dels nodes i la infraestructura associada a entorns de computació d'alt rendiment (HPC). ABSTRACT This Final Degree Project aims to develop and implement a monitoring system for the MareNostrum 5 supercomputer, which has recently entered production. This system is designed to facilitate real-time monitoring of the nodes and associated infrastructure in High Performance Computing (HPC) environments. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 3 Índice de contenido Glosario de signos, símbolos, abreviaturas, acrónimos y términos........................................................................8 1. Introducción..........................................................................................................................................................10 1.1. Motivación.......................................................................................................................................................10 1.2. Actores implicados........................................................................................................................................11 2. Justificación...........................................................................................................................................................12 2.1. Identificación del problema........................................................................................................................12 2.2. Soluciones existentes...................................................................................................................................12 2.3. Solución elegida.............................................................................................................................................13 3. Alcance...................................................................................................................................................................14 3.1. Objetivos..........................................................................................................................................................14 3.2. Requisitos........................................................................................................................................................14 3.3. Obstáculos y riesgos.....................................................................................................................................15 4. Metodología de trabajo......................................................................................................................................16 5. Planificación inicial...............................................................................................................................................17 5.1. Descripción de las tareas............................................................................................................................17 5.1.1. Gestión del proyecto..............................................................................................................................17 5.1.2. Tareas de desarrollo...............................................................................................................................18 5.2. Recursos..........................................................................................................................................................20 5.3. Estimaciones y diagrama de Gantt............................................................................................................20 6. Presupuesto inicial..............................................................................................................................................23 6.1. Identificación y estimación de los costes................................................................................................23 6.1.1. Recursos humanos.................................................................................................................................23 6.1.2. Recursos materiales................................................................................................................................25 6.1.3. Contingencias...........................................................................................................................................26 6.1.4. Imprevistos................................................................................................................................................26 6.1.5. Presupuesto total....................................................................................................................................27 6.2. Control de gestión.........................................................................................................................................27 7. Informe de sostenibilidad y análisis ético.....................................................................................................28 7.1. Matriz de sostenibilidad...............................................................................................................................28 7.2. Punto de vista ambiental.............................................................................................................................28 7.3. Punto de vista económico...........................................................................................................................30 7.4. Punto de vista social ....................................................................................................................................30 7.5. Implicaciones éticas .....................................................................................................................................31 7.6. Relación con los Objetivos de Desarrollo Sostenible (ODS)...............................................................32 8. Planificación final.................................................................................................................................................33 8.1. Desviaciones en las tareas de gestión.....................................................................................................33 8.2. Desviaciones en las tareas de desarrollo................................................................................................33 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 4 8.3. Diagrama de Gantt actualizado.................................................................................................................35 8.4. Coste final........................................................................................................................................................36 8.5. Metodología de trabajo................................................................................................................................37 8.6. Integración de conocimientos de la UPC................................................................................................38 9. Estudio de herramientas externas..................................................................................................................39 9.1. Monitorización histórica de jobs................................................................................................................39 9.1.1. Plugin de Slurm........................................................................................................................................39 9.1.2. ElasticSearch.............................................................................................................................................39 9.1.3. Kibana.........................................................................................................................................................39 9.1.4. Flujo del sistema en MN5......................................................................................................................40 9.2. Monitorización de rendimiento.................................................................................................................40 9.2.1. Telegraf.......................................................................................................................................................40 9.2.2. InfluxDB......................................................................................................................................................40 9.2.3. Grafana.......................................................................................................................................................41 9.2.4. Flujo del sistema en MN5......................................................................................................................41 10. Estudio de herramientas internas...................................................................................................................42 10.1. Perf_D...............................................................................................................................................................42 10.1.1. Arquitectura..............................................................................................................................................42 10.1.2. Funcionalidades principales.................................................................................................................42 10.1.3. Integración con herramientas externas............................................................................................43 10.1.4. Plugins específicos..................................................................................................................................43 10.1.5. Uso de Mojolicious..................................................................................................................................43 10.1.6. Estructura de directorios.......................................................................................................................43 10.2. OG3...................................................................................................................................................................44 10.2.1. Características principales.....................................................................................................................44 10.2.2. Estructura del código de OG3..............................................................................................................44 10.2.3. Interfaz gráfica del sistema...................................................................................................................45 10.2.4. Funcionalidades del sistema.................................................................................................................46 10.2.5. Representación gráfica por estados...................................................................................................47 10.3. Flujo del sistema............................................................................................................................................48 11. Migración OG3.....................................................................................................................................................49 11.1. Razones............................................................................................................................................................49 11.2. ¿Por qué se ha elegido PyQt 5?..................................................................................................................49 11.3. ¿Cómo se realizó la migración?..................................................................................................................50 11.3.1. Análisis del código de OG3...................................................................................................................50 11.3.2. Definición de requisitos.........................................................................................................................51 11.3.3. Diseño de arquitectura..........................................................................................................................51 11.3.4. Desarrollo del prototipo........................................................................................................................51 11.3.5. Migración de funcionalidades..............................................................................................................52 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 5 11.3.6. Pruebas y optimización..........................................................................................................................52 11.4. Diferencias entre OG3 y OG3v2................................................................................................................53 11.5. Beneficios de la migración a OG3v2.........................................................................................................53 11.6. Diagrama de flujo de OG3v2......................................................................................................................54 11.7. Diagrama de clases de OG3v2...................................................................................................................55 11.8. Documentación técnica OG3v2.................................................................................................................56 11.9. Disponibilidad del código fuente...............................................................................................................56 12. Implementación de OG3v2 en CTE-AMD......................................................................................................57 12.1. Descripción.....................................................................................................................................................57 12.2. Arquitectura de monitorización.................................................................................................................57 12.3. Instalación de Perf_D....................................................................................................................................59 12.4. Adaptación de Perf_D...................................................................................................................................61 12.5. Implementación de OG3v2.........................................................................................................................64 12.6. Pruebas y validación.....................................................................................................................................65 13. Implementación de OG3v2 en MareNostrum 5..........................................................................................71 13.1. Descripción.....................................................................................................................................................71 13.2. Arquitectura de monitorización.................................................................................................................71 13.3. Instalación Perf_D..........................................................................................................................................73 13.4. Adaptación Perf_D.........................................................................................................................................75 13.5. Implementación OG3v2...............................................................................................................................79 13.6. Pruebas y validación.....................................................................................................................................80 14. Actualizaciones y funcionalidades nuevas de OG3v2................................................................................87 15. Futuro de OG3v2 y Perf_D.................................................................................................................................90 15.1. Implementación de la Partición Acelerada (ACC)..................................................................................90 15.2. Posibles funcionalidades de los nodos monitorizados........................................................................90 15.3. Ampliación de funcionalidades generales en OG3v2 y Perf_D..........................................................91 16. Conclusiones........................................................................................................................................................92 17. Agradecimientos..................................................................................................................................................93 18. Bibliografía.............................................................................................................................................................94 ANEXO..................................................................................................................................................................................95 generate_positions.py................................................................................................................................................95 generate_tags.py..........................................................................................................................................................98 Diagrama de clases completo OG3v2..................................................................................................................100 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 6 Índice de tablas Tabla 1: Horas dedicadas, dependencias y recursos utilizados en cada tarea.................................................21 Tabla 2: Salarios brutos de diferentes roles basándonos en Glassdoor............................................................23 Tabla 3: Estimación del coste de los recursos humanos para cada tarea..........................................................24 Tabla 4: Costes de adquisición de los recursos de hardware personal..............................................................25 Tabla 5: Estimación del coste de los recursos materiales del proyecto..............................................................26 Tabla 6: Estimación del coste por contingencias......................................................................................................26 Tabla 7: Estimación del coste por imprevistos...........................................................................................................26 Tabla 8: Estimación del presupuesto inicial del proyecto.......................................................................................27 Tabla 9: Matriz de sostenibilidad del proyecto..........................................................................................................28 Tabla 10: Coste real de recursos humanos................................................................................................................36 Tabla 11: Coste estimado y real de contingencias....................................................................................................36 Tabla 12: Coste estimado y real total...........................................................................................................................37 Tabla 13: Estado de colores de los nodos de cómputo..........................................................................................47 Tabla 14: Diferencias entre OG3 y OG3v2..................................................................................................................53 Índice de figuras Figura 1: Diagrama de Gantt planificación inicial.....................................................................................................22 Figura 2: Diagrama de Gantt final................................................................................................................................35 Figura 3: Flujo de herramientas de monitorización histórica de jobs en MN5.................................................40 Figura 4: Flujo de herramientas de monitorización de rendimiento en MN5 .................................................41 Figura 5: Flujo de OG3 y Perf_D....................................................................................................................................48 Figura 6: Prototipo de la ventana principal de OG3v2............................................................................................52 Figura 7: Diagrama de flujo de OG3v2........................................................................................................................54 Figura 8: Diagrama de clases simplificado de OG3v2.............................................................................................55 Figura 9: Estructura del repositorio de OG3v2 en GitLab......................................................................................56 Figura 10: Diagrama arquitectura monitoring CTE-AMD .......................................................................................58 Figura 11: Datos de los nodos del clúster CTE-AMD ..............................................................................................65 Figura 12: Datos de los jobs del clúster CTE-AMD ..................................................................................................65 Figura 13: Visualización lógica de los nodos del clúster CTE-AMD .....................................................................66 Figura 14: Visualización física de los nodos del clúster CTE-AMD ........................................................................66 Figura 15: Visualización de la lista de trabajos de los nodos del clúster CTE-AMD.........................................66 Figura 16: Visualización del resumen de trabajos de los nodos del clúster CTE-AMD...................................67 Figura 17: Acción checkjob para el job 1166351 en CTE-AMD ............................................................................67 Figura 18: Acción sljcf para el job 1166351 en CTE-AMD.......................................................................................68 Figura 19: Acción monitoring del nodo amd27 .......................................................................................................69 Figura 20: Visualización lógica de los nodos del clúster CTE-AMD corregida...................................................70 Figura 21: Visualización física de los nodos del clúster CTE-AMD corregida.....................................................70 Figura 22: Diagrama arquitectura monitoring MN5................................................................................................72 Figura 23: Datos de los nodos del clúster MN5 ......................................................................................................80 Figura 24: Datos de los jobs del clúster MN5 ..........................................................................................................80 Figura 25: Visualización lógica de los nodos del clúster MN5-GPP......................................................................81 Figura 26: Visualización física de los nodos del clúster MN5-GPP.......................................................................81 Figura 27: Visualización de la lista de trabajos ejecutándose de los nodos del clúster MN5-GPP..............82 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 7 Figura 28: Visualización del resumen de trabajos de los nodos del clúster MN5-GPP..................................82 Figura 29: Acción checkjob para el job 14108755 en MN5-GPP..........................................................................83 Figura 30: Acción sljcf para el job 14108755 en MN5-GPP...................................................................................83 Figura 31: Acción monitoring de los mútiples nodos que ejecutan un job en MN5-GPP..............................84 Figura 32: Visualización de la pestaña ELEGIBLE en MN5-GPP............................................................................85 Figura 33: Visualización de la pestaña BLOCKED en MN5-GPP............................................................................85 Figura 34: Visualización lógica de los logins del clúster MN5-GPP.......................................................................86 Figura 35: Menú de métricas en el clúster CTE-AMD..............................................................................................87 Figura 36: Menú de métricas en el clúster MN5-GPP..............................................................................................87 Figura 37: Layout de la infraestructura de MN5 .......................................................................................................88 Figura 38: Layout de la infraestructura de MN5-GPP..............................................................................................88 Figura 39: Visualización física de los nodos pertenecientes a los racks g[46-60] del clúster MN5-GPP.....89 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 8 Glosario de signos, símbolos, abreviaturas, acrónimos y términos BSC: Barcelona Supercomputing Center, instalación científica y centro pionero de la supercomputación en España, ubicado en Barcelona. Bug: Error o fallo en un programa de software que provoca que este no funcione como se esperaba. Clúster: Conjunto de computadoras interconectadas que trabajan juntas como un único sistema para mejorar el rendimiento, la disponibilidad y la escalabilidad. Daemon: Tipo de programa especial que se ejecuta en segundo plano, en vez de ser controlado directamente por el usuario. DNS: Sistema de nombres jerárquico que funciona sobre una base de datos distribuida y que permite traducir los nombres de dominio a direcciones IP. HPC: Tipo de computación que utiliza superordenadores y clústeres de servidores para ejecutar tareas de elevada complejidad. HA: Alta disponibilidad. HTTP: Protocolo de la capa de aplicación que permite el intercambio de documentos y multimedia en la web. HTTPS es su versión segura. IBMS: Infiniband Monitoring System, herramienta desarrollada por ATOS para supervisar la red de interconexión Infiniband en MN5. Job: Unidad de trabajo que representa una tarea o conjunto de tareas a ejecutar en un sistema de cómputo, como cálculos, simulaciones o procesos específicos. Suele ser gestionado por un sistema de colas que asigna los recursos necesarios para su ejecución. LFS: Load Sharing Facility, sistema de gestión de colas de jobs utilizado en entornos HPC. Permite distribuir trabajos entre los nodos de un clúster, optimizando el uso de recursos y monitorizando el estado de los trabajos en tiempo real. Logs: Registros detallados que generan los sistemas, aplicaciones o servicios, documentando eventos, acciones o errores que ocurren durante su funcionamiento que permiten a los administradores o desarrolladores identificar y solucionar problemas. MN5: MareNostrum 5, es el superordenador más avanzado del BSC, diseñado para tareas de HPC. Se utiliza para investigaciones científicas y tecnológicas en áreas como inteligencia artificial, simulaciones climáticas y genómica. Monitorización: Uso de un sistema que controla constantemente el estado en el que se encuentran un conjunto de servidores y servicios para detectar posibles desviaciones en su funcionamiento esperado. Nodo: Unidad básica de un clúster de computación que representa un dispositivo físico o virtual encargado de realizar tareas específicas o alojar recursos de cómputo. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 9 Plugin: Componente de software diseñado para ampliar o añadir funcionalidades específicas a una aplicación principal sin modificar su código base. Pre-exaescala: Supercomputadores diseñados para acercarse a un nivel de rendimiento donde se pueda realizar 1 exaflop (1018 operaciones de punto flotante por segundo que equivale a un trillón de cálculos por segundo), pero su rendimiento total está ligeramente por debajo. Por lo general, suelen alcanzar decenas o centenares de petaflops (1015 operaciones de punto flotante por segundo). Rack: estructura física estándar utilizada para montar y organizar equipos electrónicos como servidores, switches de red, dispositivos de almacenamiento, y otros componentes propios de un centro de datos. Servidor: Conjunto de hardware y/o software que ofrece un servicio a sus usuarios. SSH: Protocolo de transporte que permite acceder a máquinas remotas a través de la red. TTL: Time To Live, es un concepto utilizado en computación para definir el tiempo de vida útil de un dato o recurso antes de que se considere obsoleto o sea descartado. Workflow: Flujo de trabajo, es una secuencia estructurada de tareas, procesos o pasos que se llevan a cabo para completar una actividad específica. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 16 4. Metodología de trabajo Para llevar a cabo el desarrollo de este proyecto, se optó por una metodología ágil que permitió una constante evaluación y ajuste del trabajo según las necesidades identificadas. Se estableció un plan de trabajo temporal que sirvió de referencia y se realizaron reuniones semanales para el seguimiento del progreso. Estas reuniones, dependiendo de la disponibilidad, se llevaron a cabo de manera presencial o mediante videoconferencias utilizando la herramienta Zoom [1]. Durante estas reuniones, se discutieron los avances y las tareas pendientes, se tomaron decisiones sobre las próximas acciones a realizar, y se dejaron registrados los puntos tratados para mantener un historial organizado. Un ejemplo de los apuntes de una reunión sería el siguiente: Personas presentes: Antony Baño Sergi Moré Javi Bartolome Puntos tratados: AB: Implementación de filtros por usuario. JB: Cuando se deselecciona un job, el filtro previamente aplicado debería mantenerse. AB: Pestaña de monitoring operativa. JB: Añadir como fecha de inicio de las métricas el inicio del job. AB: Implementación de degradados (gradient). AB: Reubicación de los logins al final. AB: Pendiente combinar las funcionalidades de filtrado y degradados (gradient). AB: ACC (funcionalidad adicional). JB: Eliminar. Añadir como trabajo futuro. AB: Función Checknode. JB: Eliminar. Añadir como trabajo futuro AB: Pendiente añadir el proyecto al repositorio de GitLab para que pueda ser probado. Próximas acciones (Next): AB: Finalizar el sistema de filtrado. AB: Configurar en el monitoring la fecha de inicio como el inicio del job. AB: Subir el código a GitLab para que el equipo pueda probarlo. Próxima reunión: 09/01/24 - 14:00h. Cronograma: OG3v2 mostrando datos del MN5: 04/12/2024. Finalización del código: 31/12/2024. Entrega de la memoria: 26/01/2025. Defensa: 3-5 de febrero de 2025. Además, se mantuvo un contacto constante a través de la plataforma de mensajería interna del BSC, Rocket Chat [2], para resolver dudas y coordinar tareas. Este enfoque ágil y flexible prevé garantizar que el proyecto avance de manera eficiente y que las prioridades pudieran adaptarse a medida que surjan nuevos desafíos o necesidades. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 17 5. Planificación inicial En este apartado se comenta y se especifica la planificación temporal de las tareas que se llevaran a cabo con tal de cumplir los diferentes objetivos y requisitos que se han definido en el apartado de alcance del proyecto. Comienza el proyecto el día 16 de septiembre de 2024, con el inicio de su gestión, teniendo como fecha final el 26 de enero de 2025. Esto significa que disponemos de unas 18 semanas para su realización, incluyendo la preparación para la defensa oral con la memoria ya entregada. Se calcula una dedicación de 5 horas diarias para la realización del proyecto, de manera que se prevé dedicar 630 horas en total entre la fecha de inicio y la fecha final. 5.1. Descripción de las tareas Para facilitar la comprensión de la planificación, las tareas de este proyecto están divididas en dos secciones principales, la de gestión y la de desarrollo. La planificación previa mejorará la organización y permitirá reaccionar más eficientemente en caso de inconvenientes. 5.1.1. Gestión del proyecto Esta sección, incluye todas las tareas relacionadas con la gestión del proyecto. G1 - Introducción y alcance (25 horas): Consiste en la realización de un documento donde se describirá el contexto personal y el alcance del proyecto, marcando unos objetivos y requisitos a cumplir. También se ha de justificar la realización de este proyecto, identificar el problema, describir las soluciones existentes y justificar la solución elegida. G2 - Planificación (15 horas): Consiste en la realización de un documento donde se describirá la planificación temporal, nombrando y describiendo las diferentes tareas que se llevaran a cabo durante el desarrollo del proyecto, con una estimación del tiempo que se dedicará a cada una de ellas. Se plasmarán también los posibles obstáculos y riesgos que puedan aparecer. Dependencias: G1 G3 - Gestión económica y de sostenibilidad (20 horas): Consiste en la realización de un documento donde se hará una estimación de presupuesto y sostenibilidad. Dependencias: G2 G4 - Documentación de la fase de seguimiento ( 25 horas): Consiste en preparar una entrega provisional del proyecto para la tutora de la UPC, Eva Marin, para que pueda ver el progreso del proyecto. Dependencias: G3 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 18 G5 - Documentación de OG3v2 en GitLapOp (15 horas): Consiste en acabar de documentar el contenido final del código de OG3v2, así como redactar un archivo INSTALL y README para que los actores implicados en el proyecto puedan probar y validar el sistema. Dependencias: G4 G6 - Documentación de la fase final (35 horas): Consiste en acabar de documentar el contenido final o faltante del proyecto. Dependencias: G5 G7 - Preparación de la defensa oral del proyecto (25 horas): Consiste en preparar la presentación del trabajo, que se llevara a cabo delante de un tribunal. Dependencias: G6 G8 - Reuniones periódicas con el director (30 horas): Cada semana como mínimo se llevará a cabo una reunión con el director del trabajo y otros miembros del departamento de Operaciones para comprobar el estado de las tareas y para la resolución de dudas. G9 - Reuniones periódicas con la tutora de la UPC (10 horas): Cada dos semanas como mínimo se llevará a cabo una reunión con la tutora de la UPC para comprobar el estado de las tareas, obtener un punto de vista diferente al del cliente (BSC) y seguir documentando correctamente la memoria del proyecto. 5.1.2. Tareas de desarrollo Esta sección, incluye todas las tareas relacionadas con el desarrollo técnico del proyecto. TD1 - Estudio de herramientas externas de monitorización y sistema de colas de jobs (15 horas): Consiste en investigar herramientas externas de monitorización como Grafana, ElasticSearch, etc, así como estudiar el sistema de colas de jobs (Slurm), para entender su funcionamiento. TD2 - Estudio Perf_D (10 horas): Consiste en analizar la herramienta Perf_D, con el fin de comprender su arquitectura, su funcionamiento, las métricas disponibles y sus posibilidades de adaptación para clústeres del BSC, ya sean pequeños o grandes. Dependencias: TD1 TD3 - Estudio OG3 (30 horas): Consiste en analizar el código actual de OG3, entender su funcionalidad, identificar las limitaciones existentes y planificar la migración de perl/perlTK a python/PyQt. Dependencias: TD2 TD4 - Migración OG3 a python/PyQt (150 horas): Consiste en reescribir y optimizar el código de OG3 en python/PyQt, modernizando la herramienta para que sea escalable y compatible con las necesidades del MN5. Dependencias: TD3 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 19 TD5 - Instalación Perf_D en clúster pequeño (5 horas): Consiste en instalar Perf_D en un clúster pequeño, como paso previo para su implementación en MN5, garantizando que el sistema funcione correctamente en un entorno reducido y controlado. Dependencias: TD2 TD6 - Adaptación Perf_D en clúster pequeño (20 horas): Consiste en ajustar Perf_D para que recopile métricas específicas y se integre con los recursos disponibles en el clúster pequeño, asegurando que las las modificaciones necesarias cumplen con los requisitos del proyecto. Dependencias: TD5 TD7 - Implementación OG3v2 en clúster pequeño (20 horas): Consiste en desplegar OG3v2 en el clúster pequeño, integrándolo con Perf_D y ajustando sus funcionalidades para asegurar su correcta operación en este entorno de prueba. Dependencias: TD6 TD8 - Pruebas y validación OG3v2 y Perf_D en clúster pequeño (10 horas): Consiste en realizar pruebas para validar el correcto funcionamiento de OG3v2 y Perf_D en el clúster pequeño, comprobando la integración, la visualización de métricas y el rendimiento general del sistema. Dependencias: TD4 y TD7 TD9 - Instalación Perf_D en MN5 (10 horas): Consiste en instalar Perf_D en MN5, preparando el sistema para recopilar métricas en el entorno de producción. Dependencias: TD8 TD10 - Adaptación Perf_D en MN5 (40 horas): Consiste en ajustar Perf_D para que funcione correctamente en MN5, adaptándose a su arquitectura y configuraciones específicas, y asegurando la recopilación eficiente de métricas. Dependencias: TD9 TD11 - Implementación OG3v2 en MN5 (30 horas): Consiste en desplegar OG3 en MN5, integrándolo con Perf_D y ajustándolo a las necesidades del supercomputador, como el manejo de grandes volúmenes de datos. Dependencias: TD10 TD12 - Actualización e implementación de nuevas funcionalidades en OG3v2 (60 horas): Consiste en añadir y ajustar funcionalidades específicas en OG3v2, como nuevos filtros y gráficos, así como mejorar la experiencia de usuario con visualizaciones avanzadas. Dependencias: TD11 TD13 - Pruebas y validación OG3v2 y Perf_D en MN5 (30 horas): Consiste en realizar pruebas exhaustivas para validar el correcto funcionamiento e integración de OG3v2 y Perf_D en MN5, asegurando que cumplen con los objetivos establecidos en términos de rendimiento, visualización y confiabilidad. Dependencias: TD12 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 20 5.2. Recursos Los recursos humanos que participaran en el proyecto son los actores implicados. Por lo tanto, el trabajo será realizado únicamente por el autor, con la guía y el soporte del director y un administrador de sistemas asignado para la supervisión del desarrollo del proyecto. En cuanto al hardware , se utilizará un ordenador portátil Dell Inc. Latitude 7420 , con un sistema operativo Ubuntu 22.04.5 LTS, proporcionado al estudiante por parte del BSC al comenzar el convenio de prácticas. También se dispondrá de accesos a los clústeres que se quieren monitorizar, dando permisos al mismo usuario HPC del autor, o facilitando usuarios con permisos suficientes para que el autor pueda trabajar sin inconvenientes a la hora de realizar tareas de desarrollo. Para acabar, se dará un espacio de trabajo con buena conexión a Internet para que el autor pueda hacer uso de las diferentes herramientas de comunicación que el BSC utiliza, como Zoom, Rocket Chat, NextCloud [3]; Google Meet para las reuniones con la tutora de la UPC; Ganttproject [4] para la gestión de tareas y planificación de entregas, Power Point para preparar la presentación y la defensa oral. 5.3. Estimaciones y diagrama de Gantt Con el fin de relacionar las tareas de gestión y desarrollo, se ha generado una tabla con el número de horas dedicadas a cada una de ellas, sus dependencias y los recursos utilizados para poder hacerlas, y un diagrama de Gantt utilizando la aplicación Ganttproject. ID Tarea Tiempo (h) Dependencias Recursos Tareas de gestión del proyecto 200 G1 Introducción y alcance 25 PC (NextCloud) G2 Planificación 15 G1 PC (NextCloud, Ganttproject) G3 Gestión económica y de sostenibilidad 20 G2 PC (NextCloud) G4 Documentación de la fase de seguimiento 25 G3 PC (NextCloud) G5 Documentación de OG3v2 en GitLapOp 15 G4 PC (GitLabOp) G6 Documentación de la fase final 35 G5 PC (NextCloud) G7 Preparación de la defensa oral del proyecto 25 G6 PC (NextCloud, PowerPoint) G8 Reuniones periódicas con el director 30 PC (Zoom, RocketChat) G9 Reuniones periódicas con la tutora de la UPC 10 PC (Google Meet) Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 21 Tareas de desarrollo del proyecto 430 TD1 Estudio de herramientas externas de monitorización y sistema de colas de jobs 15 PC (Scire, NextCloud) TD2 Estudio Perf_D 10 TD1 PC (Scire, NextCloud) TD3 Estudio OG3 30 TD2 PC (Scire, NextCloud) TD4 Migración OG3 a python/PyQt 150 TD3 PC (Visual Studio Code) TD5 Instalación Perf_D en clúster pequeño 5 TD2 PC (usuario HPC) TD6 Adaptación Perf_D en clúster pequeño 20 TD5 PC (usuario HPC) TD7 Implementación OG3v2 en clúster pequeño 20 TD6 PC (usuario HPC) TD8 Pruebas y validación OG3v2 y Perf_D en clúster pequeño 10 TD4 y TD7 PC (Visual Studio Code, usuario HPC) TD9 Instalación Perf_D en MN5 10 TD8 PC (usuario HPC) TD10 Adaptación Perf_D en MN5 40 TD9 PC (usuario HPC) TD11 Implementación OG3v2 en MN5 30 TD10 PC (usuario HPC) TD12 Actualización e implementación de nuevas funcionalidades en OG3v2 60 TD11 PC (Visual Studio Code, usuario HPC) TD13 Pruebas y validación OG3v2 y Perf_D en MN5 30 TD12 PC (Visual Studio Code, usuario HPC, GitLabOp) TOTAL: 630 Tabla 1: Horas dedicadas, dependencias y recursos utilizados en cada tarea Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 22 Figura 1: Diagrama de Gantt planificación inicial Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 23 6. Presupuesto inicial El propósito de este apartado es detallar y justificar los costes que implica el proyecto. Esta estimación servirá como referencia para evaluar la viabilidad económica del proyecto y garantizar su cumplimiento dentro de los límites presupuestarios establecidos. 6.1. Identificación y estimación de los costes El presupuesto inicial del proyecto es una estimación de los recursos económicos necesarios para llevar a cabo su desarrollo. Este presupuesto se basa en el análisis de las tareas planificadas y los factores que intervienen en su ejecución, como los recursos humanos, hardware , software y otros gastos asociados. Además, se incluye un margen adicional para posibles imprevistos que puedan surgir durante el proceso. 6.1.1. Recursos humanos En esta sección se calcularán los costes relacionados con los recursos humanos, es decir, los salarios de las personas que trabajarán en el proyecto. El coste por hora de trabajo dependerá del rol que desempeñe cada participante, y se utilizará como referencia la plataforma Glassdoor [5], que proporciona datos sobre salarios aproximados en diferentes posiciones laborales. Para este cálculo, también se considerará el porcentaje que las empresas deben tributar a la Seguridad Social en España, que es del 33% sobre el salario bruto de cada empleado. En este proyecto, la mayor parte de los roles y tareas serán asumidos por el propio autor, quien actuará como desarrollador y responsable técnico. Sin embargo, el rol de Systems Team Manager será desempeñado por el director y el administrador de sistemas asignado al proyecto, quienes ofrecerán supervisión y asesoramiento. A continuación, se presenta una estimación aproximada del coste asociado a cada rol involucrado en el proyecto: 1. Desarrollador de software (Software Developer - SD): Este rol implica la implementación y prueba del sistema, así como la migración de OG3 y la adaptación de Perf_D. 2. Operador de sistemas (System Operator - SO): Este rol implica la supervisión diaria de los sistemas de monitorización, asegurando que las herramientas implementadas funcionen correctamente y resolviendo posibles incidencias técnicas que puedan surgir. 3. Administrador de sistemas (Systems Team Manager - STM): Este rol implica la supervisión general del proyecto, validación de tareas y asesoramiento técnico. Rol Salario bruto Salario bruto + Seguridad Social System Operator - SO 10 €/h 13,3 €/h Software Developer - SD 20,12 €/h 26,76 €/h Systems Team Manager - STM 21,84 €/h 29,05 €/h Tabla 2: Salarios brutos de diferentes roles basándonos en Glassdoor Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 24 Una vez sabemos cuánto paga la empresa por cada rol que tomará el autor, podemos hacer una estimación del coste que tendrán los recursos humanos para la realización del proyecto. ID Tarea Tiempo (h) Rol Coste (€) Tareas de gestión del proyecto 200 3.733,4 G1 Introducción y alcance 25 SO 332,5 G2 Planificación 15 SO 199,5 G3 Gestión económica y de sostenibilidad 20 SO 266 G4 Documentación de la fase de seguimiento 25 SO 332,5 G5 Documentación de OG3 en GitLapOp 15 SD 401,4 G6 Documentación de la fase final 35 SO 465,5 G7 Preparación de la defensa oral del proyecto 25 SO 332,5 G8 Reuniones periódicas con el director 30 SO y STM 1.270,5 G9 Reuniones periódicas con la tutora de la UPC 10 SO 133 Tareas de desarrollo del proyecto 430 11.221,6 TD1 Estudio de herramientas externas de monitorización y sistema de colas de jobs 15 SO 199,5 TD2 Estudio Perf_D 10 SO 133 TD3 Estudio OG3 30 SO 399 TD4 Migración OG3 a python/PyQt 150 SD 4.014 TD5 Instalación Perf_D en clúster pequeño 5 SO 66,5 TD6 Adaptación Perf_D en clúster pequeño 20 SO y SD 801,2 TD7 Implementación OG3v2 en clúster pequeño 20 SO 266 TD8 Pruebas y validación OG3 y Perf_D en clúster pequeño 10 SO y SD 400,6 TD9 Instalación Perf_D en MN5 10 SO 133 TD10 Adaptación Perf_D en MN5 40 SO y SD 1.602,4 TD11 Implementación OG3v2 en MN5 30 SO 399 TD12 Actualización e implementación de nuevas funcionalidades en OG3v2 60 SD 1.605,6 TD13 Pruebas y validación OG3v2 y Perf_D en MN5 30 SO y SD 1.201,8 TOTAL: 630 14.955 Tabla 3: Estimación del coste de los recursos humanos para cada tarea Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 25 6.1.2. Recursos materiales En cuanto a los recursos materiales: Hardware: para el desarrollo del proyecto, se utilizará principalmente un ordenador portátil proporcionado por el BSC, concretamente un Dell Latitude E7420. Por otro lado, el proyecto contará con clústeres a monitorizar del BSC. Estos clústeres tienen uno o más servidores heads que gestionan las operaciones de control y supervisión de la máquina. Los servidores utilizados pertenecen a la infraestructura ya existente del BSC, por lo que no suponen un coste económico adicional, dado que forman parte del entorno habitual de los proyectos de investigación. Software: se prevé el uso de herramientas de código abierto, que ofrecen una amplia gama de soluciones sin coste asociado, facilitando la implementación de sistemas de monitorización eficientes y adaptables. Otros costes: también se consideran otros gastos relacionados con la amortización del espacio de trabajo, como el coste de limpieza, electricidad y seguridad. No obstante, en el caso del BSC, estos costes no se atribuyen específicamente al proyecto, ya que las oficinas son utilizadas por numerosos equipos de forma diaria y la infraestructura ya está amortizada debido a su antigüedad. Hardware personal Coste(€) Dell Latitude E7420, 11th Gen Intel® Core™ i7-1185G7 @ 3.00GHz × 8 1.500 Pantalla Dell x2 380 Ratón Logitech 10 Teclado Logitech 20 TOTAL: 1.910 Tabla 4: Costes de adquisición de los recursos de hardware personal Hace falta calcular correctamente cuál es la parte proporcional del coste de adquisición de los recursos de hardware personal para el proyecto. En España, hacienda permite amortizar el hardware en cuatro años, una vez transcurra este tiempo se han de renovar por obsolescencia. Por lo tanto, como cada año se trabajan alrededor de 225 días, siendo 7,5 horas cada día, disponemos de 1.687,5 horas por año. Por lo tanto, el coste del hardware durante la realización del proyecto es de: 657€ ∗ 630ℎ 1.687,5ℎ ∗ 4𝑎ñ𝑜𝑠 =413.910€ ∗ ℎ 6.750ℎ = 61,32€ Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 32 independientemente del género, la edad, la diversidad funcional o cualquier otra característica personal. Se ha empleado un lenguaje inclusivo en la documentación y comunicación. Uso responsable de los recursos: Durante el desarrollo, se priorizó la utilización eficiente de los recursos disponibles, minimizando el impacto ambiental y evitando el desperdicio. Privacidad y seguridad: Aunque el sistema no maneja datos personales, se ha asegurado de que toda la información utilizada para la monitorización y gestión de los clústeres respete la seguridad de la infraestructura y la privacidad de los usuarios. Transparencia y documentación: Todo el código y las metodologías utilizadas se han documentado exhaustivamente, permitiendo la ejecución del proyecto por otros desarrolladores y asegurando su accesibilidad a los interesados. Beneficio social y profesional: El proyecto tiene como objetivo mejorar la productividad y eficiencia del Barcelona Supercomputing Center (BSC), beneficiando directamente a investigadores, usuarios y personal técnico, promoviendo el desarrollo profesional de quienes interactúan con la herramienta. 7.6. Relación con los Objetivos de Desarrollo Sostenible (ODS) El proyecto contribuye directamente a varios de los Objetivos de Desarrollo Sostenible (ODS) promovidos por las Naciones Unidas. A continuación, se destacan los principales: ODS 9: Industria, innovación e infraestructura: Este proyecto mejora la infraestructura tecnológica del BSC al optimizar las herramientas de monitorización de clústeres. Contribuye a garantizar una gestión eficiente y sostenible de los recursos computacionales, apoyando la innovación en el campo de la supercomputación. ODS 12: Producción y consumo responsables: Al implementar una herramienta que detecta y resuelve problemas de rendimiento de manera eficiente, se promueve el uso responsable de los recursos computacionales, reduciendo el consumo energético y minimizando el desperdicio. ODS 13: Acción por el clima: La mejora en la gestión y optimización de los clústeres reduce la huella de carbono asociada al funcionamiento del supercomputador MareNostrum 5, contribuyendo a los esfuerzos por combatir el cambio climático. ODS 4: Educación de calidad (indirectamente): Este proyecto fomenta el aprendizaje y la innovación tecnológica, beneficiando a estudiantes e investigadores que dependen de los recursos del BSC para sus trabajos académicos y científicos. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 33 8. Planificación final Durante el transcurso de la realización del proyecto, se han identificado y gestionado desviaciones tanto en las tareas de gestión como en las de desarrollo. Estas desviaciones se atribuyen principalmente a la inexperiencia inicial en la planificación y ejecución de tareas. A continuación, se detallan las desviaciones y ajustes realizados, así como el presupuesto final, la metodología de trabajo empleada y la integración de conocimientos adquiridos durante la formación en la UPC. 8.1. Desviaciones en las tareas de gestión Durante la fase de gestión, se presentaron algunas desviaciones relacionadas con la planificación inicial del proyecto: Reorganización de tareas: Algunas tareas administrativas, como la documentación preliminar y la creación de entregables intermedios, requirieron más tiempo del estimado debido a la necesidad de realizar antes tareas de desarrollo. Reuniones adicionales: Aunque inicialmente se planificaron reuniones semanales con el director y quincenales con la tutora, en ciertos momentos fue necesario aumentar la frecuencia de estas reuniones para resolver dudas y adaptar el enfoque del proyecto. Revisión del diagrama de Gantt: Se ajustó el diagrama para priorizar tareas que tuvieron retrasos imprevistos, como la preparación de la memoria final, que se extendió debido a revisiones y correcciones. 8.2. Desviaciones en las tareas de desarrollo Las tareas de desarrollo del proyecto también experimentaron algunos cambios: Tiempo adicional en la migración a Python/PyQt: La complejidad de trasladar el código desde Perl a Python fue mayor de lo esperado, especialmente al implementar nuevas funcionalidades y optimizar el código existente. Pruebas en los clústeres del BSC: La adaptación y validación de herramientas como Perf_D y OG3v2 en el clúster pequeño (CTE-AMD) requirió más tiempo del planificado debido a problemas técnicos relacionados con la compatibilidad. Estos problemas de compatibilidad eran debido a la arquitectura del clúster, los nodos de cómputo recopilan métricas utilizando Netdata [7], se encuentra un bug y se descubre que nunca se limpian los datos almacenados en caché (/var/), lo que provoca que las métricas almacenadas en influxDB de algunos nodos no sean en tiempo real y haya que aumentar el TTL de la métrica para poder tener en cuenta este valor y visualizarlos en OG3v2. Por tema de prioridad de tareas, se decidió dejar incompleta la monitorización de este clúster y empezar la adaptación de las herramientas en MN5 que era el clúster que verdaderamente nos interesaba monitorizar. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 34 Implementación de funcionalidades nuevas: Se añadieron funcionalidades no contempladas en la planificación inicial, para mejorar la visualización del sistema. Funcionalidades como la posibilidad de seleccionar los nodos y sus jobs asociados mediante la selección por grupo de racks. Aun así, por falta de tiempo, se tuvo que dividir la capacidad de MN5 para monitorizar únicamente la Partición de Propósito General (GPP), no monitorizando la Partición Acelerada (ACC) que contiene GPUs. En general, estas desviaciones fueron gestionadas reasignando prioridades y tiempo, con el objetivo de mantener el nivel de calidad del proyecto. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 35 8.3. Diagrama de Gantt actualizado Figura 2: Diagrama de Gantt final Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 36 8.4. Coste final Tendremos que tener en cuenta, si ha habido desviaciones en el desarrollo del proyecto, de ser así, habrá que calcular el coste final, partiendo de las desviaciones que se tomaron en cuenta en el presupuesto inicial: Desviación de las horas totales: Horas totales estimadas - Horas reales estimadas (200h+430h) - (220h+470h) = (630h) - (690h) = - 60 h, existe desviación Tendremos que calcular, sabiendo el total de horas reales, el coste de recursos humanos actualizado, tomando como base el presupuesto inicial. Tarea Tiempo (h) Rol Coste (€) Tareas de gestión del proyecto 200 3.733,4 Desviación tareas de gestión del proyecto 20 SO 266 Tareas de desarrollo del proyecto 430 11.221,6 Desviación tareas de desarrollo del proyecto 40 SD 1070,4 TOTAL: 690 16.291,4 Tabla 10: Coste real de recursos humanos Desviación en el coste de recursos humanos Coste estimado de recursos humanos - Coste real de recursos humanos (14.955€) - (16.291,4€) = - 1336,4€, existe desviación Desviación en el coste de recursos materiales Coste estimado de recursos materiales - Coste real de recursos materiales (61,32€) - (61,32€) = 0€, no existe desviación Tendremos que calcular, sabiendo el coste real de recursos humanos y materiales, el coste real de contingencias. Recursos Contingencia estimada(€) Contingencia real(€) Humanos 1.495,5 1.336,4 Materiales 6,132 0 Coste TOTAL: 1.501,632 1.336,4 Tabla 11: Coste estimado y real de contingencias Podemos observar que el coste de desviación de recursos humanos se encuentra dentro del rango del presupuesto inicial por contingencias. Desviación en el coste de contingencias Coste estimado de contingencias - Coste real de contingencias (1.501,632€) - (1.336,4€) = 165,232€, no existe desviación Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 37 Los imprevistos por conocimientos técnicos y problemas con las pruebas de validación ya los tuvimos en cuenta dentro del presupuesto de contingencias, en la desviación por imprevistos solo tendré en cuenta fallos técnicos en el hardware personal (portátil), por el que estuve un día (5h) sin poder avanzar en el desarrollo del proyecto. Desviación en el coste por imprevistos Coste estimado de imprevistos - Coste real de imprevistos (280,11€) - (6,65€) = 273,46€, no existe desviación Sabiendo los costes de las desviaciones de recursos humanos y materiales, además de las contingencias y los imprevistos que han podido surgir durante el proyecto, podremos calcular el coste final. Tipo de coste Presupuesto inicial (€) Coste real(€) Recursos humanos 14.955 16.291,4 Recursos materiales 61,32 61,32 Contingencias 1.501,632 -165,232 Imprevistos 280,11 -273,46 Coste final: 16.798,07 15.914,03 Tabla 12: Coste estimado y real total Desviación en el coste total Coste estimado total - Coste real total (16.798,07€) - (15.914,03) = 884,04€ El coste total del proyecto sería de 15.914,03€, siendo un coste que estaría dentro del presupuesto inicial. 8.5. Metodología de trabajo La metodología de trabajo no recibió ningún cambio al propuesto en la planificación inicial. Sobre la comunicación de los actores implicados: –El volumen de reuniones semanales con el director siguió siendo el mismo. –La cantidad de reuniones con la tutora de la UPC pasaron de ser cada quince días a cuando el autor veía necesario reunirse con ella, puesto que, al principio de la ejecución de las tareas de desarrollo, no existían tantos cambios significativos en el resultado del proyecto. –La comunicación diaria entre el autor, el director y el administrador de sistemas asignado fue a través de un canal creado en Rocket Chat con la finalidad de hablar únicamente del proyecto. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 38 8.6. Integración de conocimientos de la UPC La realización de este proyecto, ha permitido aplicar conocimientos adquiridos durante los años estudiados en la UPC. A continuación, se destacan algunas de las asignaturas cuya formación han ayudado en el desarrollo de este proyecto: INEP (Introducción a la Ingeniería del Software) y AMEP (Ampliación a la Ingeniería del Software): Ayudaron a comprender las metodologías necesarias para estructurar, planificar y gestionar proyectos de software complejos. INDI (Interacción y Diseño de Interfaces): Proporcionó conocimientos para diseñar interfaces intuitivas y funcionales, como las empleadas en la migración a Python/PyQt. ESC1 y ESC2 (Estructura de Computadores 1 y 2): Ayudaron a comprender el funcionamiento de los sistemas hardware y software . PACO (Paralelismo y Concurrencia): Fue crucial para gestionar múltiples procesos concurrentes, especialmente en la comprensión de un entorno de alto rendimiento como el de MareNostrum 5. ADSO (Administración de Sistemas Operativos): Proporcionó conocimientos sobre Linux y redes, automatización de instalaciones y configuración de software y dependencias, hosts y servicios. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 39 9. Estudio de herramientas externas Las herramientas externas desempeñan un papel crucial en la infraestructura del BSC al complementar las capacidades internas con soluciones probadas y versátiles. La integración de estas herramientas externas permite al BSC aprovechar tecnologías maduras y ampliamente adoptadas, asegurando una alta confiabilidad y soporte constante. La razón de utilizar múltiples herramientas radica en la complejidad de las infraestructuras HPC y la diversidad de datos que necesitan ser procesados. Cada herramienta está diseñada para cumplir un propósito específico y la combinación de ellas asegura que se puedan abordar de manera efectiva los distintos aspectos de la monitorización. 9.1. Monitorización histórica de jobs La monitorización histórica de jobs es esencial para comprender el comportamiento pasado del clúster, analizar patrones de uso y detectar posibles problemas relacionados con la gestión de trabajos. Este proceso permite almacenar información detallada sobre los trabajos ejecutados, como recursos consumidos, tiempos de ejecución y estado final. 9.1.1. Plugin de Slurm El plugin de Slurm [8] es una extensión diseñada para integrar la monitorización de trabajos en el sistema de colas de Slurm. Este plugin captura información detallada de los trabajos, como el tiempo de inicio, el tiempo de finalización, el consumo de CPU y memoria, y los nodos utilizados. Los datos recolectados son enviados a una base de datos para su almacenamiento y análisis. Esta integración facilita una visión detallada del rendimiento de los trabajos y permite correlacionar métricas de los nodos con las tareas ejecutadas. El código del plugin fue desarrollado en 2014 en BSC como proyecto/tesis de Master dentro del departamento de Operaciones y se incluyó dentro del código de Slurm en 2015. 9.1.2. ElasticSearch ElasticSearch [9] es una base de datos orientada a documentos que se utiliza para almacenar grandes volúmenes de datos generados por el sistema de monitorización de jobs. Su capacidad de indexar y buscar datos de manera rápida y eficiente permite analizar rápidamente métricas históricas relacionadas con los trabajos, como el uso de recursos o fallos detectados. ElasticSearch es una herramienta ideal para gestionar logs y datos estructurados, ofreciendo escalabilidad y alta disponibilidad. 9.1.3. Kibana Kibana [10] es una herramienta de visualización que trabaja en conjunto con ElasticSearch. Permite representar gráficamente los datos históricos de trabajos almacenados, creando dashboards interactivos y filtros personalizados para explorar métricas específicas. Con Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 40 Kibana, los administradores pueden visualizar de manera intuitiva el rendimiento de los trabajos, identificar cuellos de botella y realizar análisis detallados para optimizar la ejecución de los mismos. 9.1.4. Flujo del sistema en MN5 Este flujo permite realizar un análisis de datos sobre los jobs finalizados, sabiendo cómo se han distribuido los recursos y cómo cada proyecto/usuario solicita o utiliza recursos en un clúster. Es especialmente útil para sistemas de alto rendimiento donde los recursos son limitados y compartidos entre múltiples usuarios. Figura 3: Flujo de herramientas de monitorización histórica de jobs en MN5 9.2. Monitorización de rendimiento La monitorización de rendimiento se centra en el análisis en tiempo real del uso de los recursos del sistema, como CPU, memoria, almacenamiento y redes. Este enfoque permite identificar rápidamente anomalías, garantizar el rendimiento esperado del clúster y optimizar su funcionamiento. 9.2.1. Telegraf Telegraf [11] es un agente de recopilación de datos ligero y altamente configurable que captura métricas de rendimiento del hardware y el software. Se utiliza para recolectar información de CPU, memoria, disco, redes y otros componentes del sistema. Este agente puede extraer datos de múltiples fuentes y enviarlos a bases de datos como InfluxDB para su almacenamiento y análisis. Telegraf es una herramienta fundamental para la monitorización de rendimiento debido a su flexibilidad y capacidad de integración 9.2.2. InfluxDB InfluxDB [12] es una base de datos orientada a series temporales diseñada específicamente para manejar grandes volúmenes de datos relacionados con el tiempo, como métricas de rendimiento. Los datos recopilados por Telegraf se almacenan en InfluxDB, donde pueden ser consultados de manera eficiente para análisis históricos o en tiempo real. Su capacidad de manejar métricas detalladas de rendimiento lo convierte en una herramienta clave en la arquitectura de monitorización. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 41 9.2.3. Grafana Grafana [13] es una plataforma de visualización de datos que se utiliza para crear dashboards interactivos y representaciones gráficas de las métricas de rendimiento almacenadas en InfluxDB. Con Grafana, los administradores pueden monitorear en tiempo real el estado del clúster, identificar patrones de uso y detectar problemas de rendimiento de manera intuitiva. Su capacidad para personalizar gráficos y alertas permite una gestión más eficiente del clúster y una respuesta proactiva ante posibles problemas. 9.2.4. Flujo del sistema en MN5 Este flujo permite supervisar en tiempo real el rendimiento de los nodos de cómputo en entornos HPC. Las métricas clave, como uso de CPU, memoria y temperatura, se recopilan en cada nodo mediante Telegraf y se agregan de forma jerárquica en los servidores de servicio (como gsXX y asXX). Posteriormente, estos servidores de servicio envían la información agregada a dos bases de datos InfluxDB redundadas, que se encuentran alojadas en los servidores de monitorización. Las métricas almacenadas en InfluxDB son visualizadas en Grafana, lo que facilita la detección de problemas y la optimización del clúster. Este diseño jerárquico garantiza un uso eficiente de los recursos y la continuidad del servicio, además de permitir que las alertas sean gestionadas rápidamente ante cualquier anomalía detectada. Figura 4: Flujo de herramientas de monitorización de rendimiento en MN5 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 48 10.3. Flujo del sistema Perf_D se encarga de recopilar, procesar y almacenar datos de los clústeres y OG3 actúa como una capa superior que traduce esta información en visualizaciones comprensibles y accesibles. De esta forma, Perf_D y OG3 trabajan en conjunto para proporcionar una solución integral de monitorización y análisis en los clústeres. Figura 5: Flujo de OG3 yPerf_D El desarrollo de herramientas internas como Perf_D y OG3 permite al BSC optimizar el rendimiento y la monitorización de sus clústeres, asegurando una integración perfecta con sistemas de gestión como Slurm y ajustándose a las demandas específicas de cada entorno, como la visualización avanzada o el manejo de datos de alto rendimiento. Además, estas herramientas ofrecen la flexibilidad de adaptarse a los cambios tecnológicos, sin depender de soluciones externas que podrían no cubrir todos los requerimientos o representar costes adicionales. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 49 11. Migración OG3 La herramienta OG3, desarrollada originalmente en Perl/PerlTK, ha demostrado ser una herramienta fundamental para la monitorización y visualización de los clústeres del BSC. Sin embargo, la evolución de las necesidades de monitorización, el salto exponencial en la carga de trabajo con la implementación de MareNostrum 5 y las limitaciones técnicas y de mantenimiento asociadas al código original hacen necesario migrar y optimizar OG3 hacia una tecnología más moderna y sostenible. 11.1. Razones Obsolescencia de PerlTK: Tk [15], aunque funcional, es una biblioteca menos utilizada en la actualidad, lo que dificulta encontrar desarrolladores familiarizados con ella y soporte actualizado. Su última versión estable (8.6.5) es de hace más de 8 años. Aumento de complejidad: El incremento en la cantidad de nodos, la incorporación de GPUs y las nuevas métricas introducidas por Perf_D requieren una herramienta más flexible y capaz de manejar cargas de trabajo mayores. Mantenimiento y escalabilidad: El mantenimiento del código en Perl presenta desafíos significativos, especialmente para incorporar nuevas funcionalidades y mejorar la experiencia del usuario. 11.2. ¿Por qué se ha elegido PyQt 5? PyQt [16] es un framework basado en Python que permite desarrollar interfaces gráficas avanzadas y ha sido elegido para esta migración debido a sus múltiples ventajas, entre ellas: Soporte comunitario y actualizaciones Python es uno de los lenguajes de programación más utilizados en la actualidad, y PyQt cuenta con una comunidad activa que garantiza soporte técnico, documentación extensa y actualizaciones frecuentes. Experiencia de usuario mejorada Permite crear interfaces gráficas modernas e intuitivas que ofrecen una experiencia visual y funcional mucho más atractiva en comparación con PerlTK. Compatibilidad multiplataforma PyQt es compatible con sistemas operativos como Linux, Windows y macOS, lo que asegura la portabilidad del sistema en diferentes entornos del BSC. Interoperabilidad con Perf_D Python facilita la integración directa con las APIs REST de Perf_D, lo que simplifica la obtención y representación de métricas. Facilidad de aprendizaje y uso Python es conocido por su curva de aprendizaje suave y su sintaxis clara, lo que reduce el tiempo necesario para el desarrollo. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 50 La versión elegida de PyQt para el desarrollo y migración del código de OG3 es la Qt 5.15 [17], la razón de esta elección se debe a su estabilidad comprobada en entornos de producción, y su soporte extendido, lo que garantiza menos problemas de compatibilidad y una transición más fluida en comparación con la versión 6, que aún presenta cambios significativos y menor adopción en proyectos existentes. 11.3. ¿Cómo se realizó la migración? El proceso de migración de OG3 a OG3v2 fue llevado a cabo de manera estructurada, asegurando que cada etapa cubriera las necesidades funcionales y técnicas de la nueva aplicación. A continuación, se describen en detalle cada uno de los pasos realizados para que cada punto sea claro y entendible. 11.3.1. Análisis del código de OG3 El primer paso fue realizar un análisis exhaustivo del código existente en OG3, con el objetivo de entender su estructura, funcionalidades y posibles puntos de mejora. Este análisis incluyó: Identificación de módulos principales: –Se identificaron las partes del código que representaban funcionalidades críticas. Por ejemplo, el código de OG3 contenía módulos como OgTk::Board y OgTk::Data, que manejaban las representaciones visuales y los datos. Identificación de dependencias críticas: –Se revisaron las bibliotecas externas utilizadas por OG3, como Tk (para la interfaz gráfica) y otros módulos de Perl, para determinar si estaban desactualizados o representaban un riesgo para la continuidad del proyecto. –Se identificaron las interacciones con el backend, especialmente la forma en que OG3 se conectaba con los sistemas de datos para obtener información sobre nodos, métricas y jobs. –Dependencias relacionadas con configuraciones específicas del clúster, como los parámetros que eran únicos para ciertos entornos. Análisis de puntos débiles: –Se identificaron áreas problemáticas, como la falta de modularidad del código, donde múltiples funciones estaban entrelazadas, lo que dificultaba su mantenimiento. –Se detectaron problemas de escalabilidad, ya que OG3 mostraba una disminución del rendimiento al manejar miles de nodos y trabajos simultáneamente. El resultado de esta etapa fue un documento que sirvió como base para definir los requisitos de OG3v2. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 51 11.3.2. Definición de requisitos Con base en los hallazgos del análisis, se definieron los requisitos funcionales y no funcionales para OG3v2. Esto incluyó: Requisitos funcionales: –Visualización de nodos y trabajos en un tablero interactivo. –Soporte para filtros avanzados por clústeres, métricas, nodos y jobs. –Actualización automática de datos cada cierto intervalo de tiempo. Requisitos no funcionales: –Escalabilidad para manejar clústeres de gran tamaño. –Interfaz de usuario moderna y fácil de usar. –Rendimiento óptimo incluso en sistemas con miles de nodos. 11.3.3. Diseño de arquitectura La arquitectura de OG3v2 fue rediseñada para superar las limitaciones del diseño monolítico de OG3. Se adoptó un enfoque modular basado en el patrón Modelo-Vista-Controlador (MVC): Modelo: Encapsula la lógica de negocio (por ejemplo, gestión de datos sobre nodos y trabajos). La clase Data se encargó de cargar y estructurar los datos. Vista: Gestiona la representación visual de los datos. Se utilizaron QGraphicsView y QGraphicsScene para renderizar el tablero de nodos, y QTableWidget para mostrar las listas de trabajos. Controlador: Coordina la interacción entre el modelo y la vista. Por ejemplo, responde a las interacciones del usuario (como eventos de clic y cambios de configuración que fueron gestionadas mediante señales y slots de PyQt5) y actualiza la vista en tiempo real. 11.3.4. Desarrollo del prototipo En esta etapa, se creó un prototipo inicial para validar el diseño de la nueva aplicación. El prototipo incluía: Una ventana principal con pestañas para las listas de jobs (running, elegible y blocked). Un tablero básico de nodos implementado con QGraphicsView yQGraphicsScene. Funcionalidades básicas como la carga de datos en un archivo. El objetivo del prototipo fue verificar que PyQt5 cumplía con las necesidades técnicas y que las funcionalidades críticas podían implementarse de manera efectiva. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 52 Figura 6: Prototipo de la ventana principal de OG3v2 11.3.5. Migración de funcionalidades Las funcionalidades existentes en OG3 se migraron de forma incremental para minimizar errores y garantizar la estabilidad del sistema: Migración de la gestión de datos: –La lógica para cargar y procesar datos fue implementada en la clase Data. –Se rediseñaron los métodos para que fueran más eficientes y compatibles con estructuras de datos modernas, como diccionarios y listas en Python. Migración de la Interfaz gráfica: –Las listas de trabajos fueron recreadas utilizando QTableWidget, permitiendo una visualización dinámica y personalizable. –El tablero de nodos fue rediseñado con QGraphicsView, lo que permitió incluir características interactivas como zoom, desplazamiento y gradientes. 11.3.6. Pruebas y optimización Una vez migradas las funcionalidades clave, se realizaron pruebas exhaustivas para asegurar la estabilidad y el rendimiento de OG3v2: Pruebas funcionales –Se verificó que cada funcionalidad de OG3 estuviera correctamente implementada en OG3v2. –Se probaron casos de uso comunes, como filtrar trabajos, cambiar métricas y seleccionar nodos en el tablero. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 53 Pruebas de rendimiento –Se evaluó el comportamiento de OG3v2 con diferentes volúmenes de datos para asegurar que pudiera manejar clústeres grandes sin disminuir el rendimiento. Pruebas de Usuario –Se tomó en cuenta el feedback de los usuarios para ajustar la experiencia y corregir errores. Optimización del código –Se mejoraron procesos como la actualización del tablero y la representación gráfica, minimizando el uso de recursos. 11.4. Diferencias entre OG3 y OG3v2 Algunas de las diferencias entre OG3 y OG3v2 son: Categoría OG3 OG3v2 Tecnología base Perl y TK Python y PyQt5 Interfaz gráfica Simple, algo anticuada. Moderna y adaptativa. Interactividad Básica: desplazamiento y zoom limitado y no completamente optimizado. Mejorada: soporte completo para desplazamiento y zoom, vistas personalizables. Rendimiento Limitado al manejar grandes volúmenes de datos o clústeres complejos. Optimizado para grandes clústeres gracias a QGraphicsView y QGraphicsScene. Mantenimiento Código modular pero difícil de expandir o mantener. Código modular facilitando la escalabilidad y el mantenimiento. Documentación técnica Limitada y dispersa. Completa, centralizada y con guías claras para desarrolladores y usuarios. Visualización Representación básica. Representación mejorada y configurable. Escalabilidad Limitada para infraestructuras grandes. Capacidad para manejar cientos o miles de nodos con múltiples clústeres simultáneamente. Tabla 14: Diferencias entre OG3 y OG3v2 11.5. Beneficios de la migración a OG3v2 Algunos de los beneficios con la migración de OG3 fueron: Mayor rendimiento: Una estructura de código más optimizada y moderna que permite a OG3v2 gestionar la carga de trabajo de MN5 de manera eficiente. Sostenibilidad a largo plazo: Uso de herramientas modernas para asegurar que el proyecto sea viable y mantenible en los próximos años. Colaboración más amplia: Facilitar la incorporación de nuevos desarrolladores al proyecto gracias al uso de un lenguaje y framework ampliamente adoptados. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 54 11.6. Diagrama de flujo de OG3v2 El diagrama de flujo es una representación visual que describe el flujo de ejecución principal de la aplicación. Este diagrama facilita la comprensión de las secuencias lógicas, decisiones y procesos clave que ocurren dentro del sistema. El diagrama de flujo para OG3v2 incluye los siguientes elementos principales: 1. Inicio de la aplicación: –Carga de dependencias y módulos (PyQt5 y OgQt) –Inicialización de los objetos principales (tableros, listas de trabajos, datos) 2. Interacción del usuario: –Eventos como clics en botones, selección de métricas o cambios en las configuraciones del tablero. –Respuestas de la aplicación, como actualizaciones en tiempo real del tablero y las listas. 3. Gestión de datos: –Actualización de los datos desde el backend. –Transformación y visualización de los datos en gráficos o tablas. 4. Redibujado y renderización: –Actualización visual del tablero en función de las métricas seleccionadas y filtros aplicados. 5. Cierre de la aplicación: –Liberación de recursos, detención de temporizadores y salida segura del sistema. Figura 7: Diagrama de flujo de OG3v2 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 55 11.7. Diagrama de clases de OG3v2 El diagrama de clases representa la estructura de la aplicación desde la perspectiva de la programación orientada a objetos. Detalla las relaciones entre las clases principales, los atributos y métodos que poseen, y cómo interactúan entre sí. En OG3v2, el diseño basado en PyQt5 introduce una arquitectura modular con las siguientes clases: 1. MyApp: –Clase principal que representa la aplicación. –Controla las ventanas, pestañas y la interacción con el usuario. 2. Board: –Representa el tablero principal para mostrar nodos y jobs. –Maneja la lógica de visualización, como la selección de nodos y la actualización de colores. 3. Data: –Clase encargada de la obtención, transformación y actualización de los datos desde las fuentes externas. 4. List: –Maneja las listas de trabajos (running, elegible, blocked), incluyendo la estructura de columnas y eventos asociados. Figura 8: Diagrama de clases simplificado de OG3v2 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 56 11.8. Documentación técnica OG3v2 Para garantizar el buen uso del sistema migrado y su correcta comprensión, se ha elaborado una documentación que incluye dos archivos principales: README.md: Este archivo proporciona una descripción clara y detallada de las funcionalidades principales de OG3v2 para que los usuarios comprendan sus capacidades y aprendan a interactuar con la aplicación de manera eficiente. INSTALL.md: Este archivo guía a los usuarios desde la descarga del código hasta la ejecución del programa principal, asegurando que se cumplan todos los requisitos previos. Además, explica cómo instalar dependencias mediante un archivo requirements.txt, facilitando la instalación en distintos sistemas operativos. Su enfoque práctico permite que cualquier persona pueda configurar la aplicación correctamente. Ambos archivos han sido diseñados para ser claros, concisos y accesibles tanto para desarrolladores experimentados como para nuevos usuarios. 11.9. Disponibilidad del código fuente El código de OG3v2, está disponible en el repositorio oficial del Barcelona Supercomputing Center (BSC) alojado en GitLab [18]. Esto garantiza que el proyecto sea accesible para los equipos técnicos del BSC y cualquier colaborador autorizado. Figura 9: Estructura del repositorio de OG3v2 en GitLab Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 57 12. Implementación de OG3v2 en CTE-AMD El CTE-AMD [19] es un clúster de alto rendimiento diseñado para aplicaciones que requieren gran capacidad de cómputo y aceleración mediante GPUs. Este clúster se monitorizó antes que MN5 debido a su arquitectura de hardware similar, ya que también dispone de GPUs. El objetivo principal de esta fase fue familiarizarme con el entorno, comprender la interacción entre Perf_D y OG3v2, y aprender a configurar y analizar la conexión entre ambos sistemas. Esta experiencia resultó clave para simplificar y agilizar la implementación de OG3v2 en MN5, al contar con una base sólida de conocimientos y prácticas desarrolladas en el CTE-AMD. A continuación se describe CTE-AMD y las tareas que se tuvieron que hacer para la implementación de OG3v2. 12.1. Descripción CTE-AMD cuenta con la siguiente configuración: Nodos de cómputo: 33 nodos, cada uno equipado con: Procesador: 1 x AMD EPYC 7742 a 2.250 GHz, con 64 núcleos y 2 hilos por núcleo, totalizando 128 hilos por nodo. Memoria: 1024 GiB de memoria principal, distribuidos en 16 módulos de 64 GiB a 3200 MHz. Almacenamiento local: 1 SSD de 480 GB. GPUs: 2 x AMD Radeon Instinct MI50 con 32 GB cada una. Interconexión: Red Infiniband HDR100 de un solo puerto Mellanox. Sistema de archivos: Acceso a GPFS a través de dos enlaces de cobre de 10 Gbit. Nodo de inicio de sesión: 1 nodo dedicado para la conexión de usuarios y tareas de gestión. Sistema operativo: Rocky Linux release 8.5 (Green Obsidian). Esta configuración hace que el CTE-AMD sea ideal para aplicaciones que se benefician de la aceleración por GPU, ofreciendo un entorno para cargas de trabajo intensivas en cómputo. 12.2. Arquitectura de monitorización El sistema de monitorización del clúster CTE-AMD se basa en una arquitectura robusta que permite la recopilación, análisis y visualización de métricas de los nodos y la infraestructura asociada. Funcionamiento general: La arquitectura del sistema se organiza en contenedores Docker [12], lo que garantiza independencia del hardware y permite desplegar el sistema de monitorización en clústeres con diferentes arquitecturas. Esta modularidad también facilita la configuración y escalabilidad del sistema según las necesidades específicas del clúster. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 64 permitirá comprobar que todo funcione correctamente y verificar que no se almacenen errores en los registros ( logs ) del sistema, accesibles a través de journalctl. 12.5. Implementación de OG3v2 Como se ha mencionado anteriormente en el estudio de Perf_D, la comunicación de OG3v2 con Perf_D se realiza a través de peticiones HTTP que pasan por un proxy ubicado en el servidor opsmon01. Para añadir un clúster nuevo a OG3v2, tendremos que modificar el archivo og3_proxy ubicado en el directorio /bsc/og3-proxy-server/ de la máquina opsmon01. Para ello, tendremos que añadir una nueva entrada en el hash $clusters para especificar: –el nombre del nuevo clúster, –la dirección del nodo head (host), –y el puerto en el que se estará escuchando el daemon perf_d. opsmon01:~ # cat /bsc/og3-proxy-server/og3_proxy my $clusters = { amd => { host => "amdhead2", port => 9091}, ... }; Esto permitirá que el proxy enrute las solicitudes a la instancia de Perf_D del nuevo clúster. Además, tendremos que añadir el nuevo clúster también al código de OG3v2. Modificamos la clase Data agregando una nueva entrada en el diccionario CLUSTERS. Esta entrada debería de contener las propiedades necesarias para el nuevo clúster: –Dirección del servidor (addr) –URL del sistema de monitorización (monitoring) –Nodo head (sshhead) –Cualquier otra configuración específica como isldap (indica si el clúster utiliza autenticación LDAP o no). self.UA = requests.Session() self.SRV = "http://opsmon01:9090/" self.CLUSTERS = { "amd": { "addr": f"{self.SRV}amd/", "monitoring": "http://amdhead2.bsc.es/d/LCYkx3FMz/netdata-dashboard?orgId=1&", "sshhead": "amdhead2", "isldap": "false" }, } Una vez hayamos hecho estas modificaciones actualizaremos el proxy y el servicio de perf_d. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 65 12.6. Pruebas y validación Algunas de las pruebas que se hicieron para la validación de la integración de CTE-AMD como clúster monitorizado por OG3v2 fueron: –Verificación de la recopilación de datos en la ruta de nodos Figura 11: Datos de los nodos del clúster CTE-AMD –Verificación de la recopilación de datos en la ruta de jobs Figura 12: Datos de los jobs del clúster CTE-AMD Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 66 –Visualización de los nodos y sus etiquetas en OG3v2 según su posición lógica Figura 13: Visualización lógica de los nodos del clúster CTE-AMD –Visualización de los nodos y sus etiquetas en OG3v2 según su posición física Figura 14: Visualización física de los nodos del clúster CTE-AMD –Visualización de la lista de trabajos que están ejecutándose Figura 15: Visualización de la lista de trabajos de los nodos del clúster CTE-AMD Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 67 –Visualización del resumen de trabajos de la lista de jobs que están ejecutándose Figura 16: Visualización del resumen de trabajos de los nodos del clúster CTE-AMD –Creación de la pestaña para la acción checkjob de un job en específico Figura 17: Acción checkjob para el job 1166351 en CTE-AMD Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 68 –Creación de la pestaña para la acción sljcf de un job en específico Figura 18: Acción sljcf para el job 1166351 en CTE-AMD –Configuración de los umbrales de valores de las métricas # Rangos de limites de las diferentes métricas self.THRESHOLD = { 'load_one': [0.5, 1.5, 2.5, 3.5], 'cpu_load_one': [0.25, 0.75, 1.04, 1.15], 'temperature': [21, 24, 26, 29], 'fanpower': [0, 7, 14, 25] } Nos damos cuenta que pese haber configurado los umbrales de las métricas a mostrar, no se muestran correctamente los colores de los nodos. Indagando nos encontramos con la problemática de que Netdata, no está recogiendo los valores de las métricas del nodo correctamente y el almacenamiento del valor es aleatorio. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 69 –Apertura de la pestaña de monitoring para el nodo de un job en el navegador web Figura 19: Acción monitoring del nodo amd27 Vemos que esta acción no devuelve ningún dato y no se puede visualizar tampoco carga de trabajo alguna de algún job ejecutándose en este nodo. Analizando diferentes respuestas de consultas a la base de datos (InfluxDB) que almacena el valor de las métricas de los nodos, podemos ver que en algunos casos el último valor es del día anterior en lugar del valor del último minuto y el penúltimo valor es de hace años, por lo que el TTL de 60 segundos no sirve, siempre dibujará el nodo de color blanco (hay valor pero fuera de rango, fuera del TTL para poder tomarlo en cuenta). –Query de los 3 últimos valores de una métrica específica a InfluxDB [root@amdhead2 bsc099499]# wget -O result.json 'http://localhost:8086/query?pretty=true&u=root&p=&db=graphite&q=SELECT * FROM "netdata.system.load.load1" GROUP BY host ORDER BY time DESC limit 3' ... [root@amdhead2 bsc099499]# cat result.json { "results": [ { "statement_id": 0, "series": [ { "name": "netdata.system.load.load1", Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 70 "tags": { "host": "amdlogin1" }, "columns": [...], "values": [ ["2024-09-29T23:59:50Z", 1.79], ["2021-07-19T05:17:25Z", 0.0542269], ["2021-07-19T05:17:15Z", 0.06] ] }, Se cambia el TTL a 31536000 segundos (1 año) para que, en caso de que se deba a esto, pinte el nodo de cualquier otro color que no sea blanco y efectivamente, funciona. –Visualización de los nodos y sus etiquetas en OG3v2 según su posición lógica corregida Figura 20: Visualización lógica de los nodos del clúster CTE-AMD corregida –Visualización de los nodos y sus etiquetas en OG3v2 según su posición física Figura 21: Visualización física de los nodos del clúster CTE-AMD corregida Debido a este imprevisto, se ha perdido bastante tiempo, por lo que se decide priorizar la tarea de empezar con la monitorización de MN5 en OG3v2, dejando la monitorización de este clúster pendiente de actualizar/reiniciar Netdata en cada nodo para que recoja las métricas de rendimiento correctamente. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 71 13. Implementación de OG3v2 en MareNostrum 5 El MareNostrum 5 [20] es un supercomputador pre-exaescala alojado en el BSC. Proporciona una infraestructura de alto rendimiento para aplicaciones que requieren una gran capacidad de cómputo y aceleración mediante GPUs. A continuación se describe MN5 y las tareas que se tuvieron que hacer para la implementación de OG3v2. 13.1. Descripción La configuración de MN5 se beneficia de la avanzada arquitectura del supercomputador, que incluye 2 particiones principales: Partición de Propósito General (GPP): Compuesta por 6.480 nodos basados en procesadores Intel Sapphire Rapids, cada uno configurado con: Procesadores: 2x Intel Xeon Platinum 8480+ a 2 GHz, con 56 núcleos cada uno, totalizando 112 núcleos por nodo. Memoria: 256 GB de memoria principal DDR5 por nodo, con 216 nodos equipados con 1.024 GB para tareas que requieren mayor capacidad de memoria. Almacenamiento local: 960 GB en NVMe para almacenamiento temporal. Interconexión: Red InfiniBand NDR200 compartida por dos nodos, proporcionando un ancho de banda de 100 Gb/s por nodo. Partición Acelerada (ACC): Consta de 1.120 nodos que combinan procesadores Intel Sapphire Rapids y GPUs NVIDIA Hopper, cada uno configurado con: Procesadores: 2x Intel Xeon Platinum 8460Y+ a 2,3 GHz, con 40 núcleos cada uno, totalizando 80 núcleos por nodo. GPUs: 4x NVIDIA Hopper H100 con 64 GB de memoria HBM2 cada una, optimizadas para tareas de inteligencia artificial y simulaciones numéricas intensivas. Memoria: 512 GB de memoria principal DDR5 por nodo. Almacenamiento local: 480 GB en NVMe. Interconexión: 4x conexiones InfiniBand NDR200, proporcionando un ancho de banda total de 800 Gb/s por nodo. 13.2. Arquitectura de monitorización El sistema de monitorización del clúster MN5 se basa en herramientas robustas para la recopilación, análisis y visualización de métricas en nodos de cómputo, nodos de servicio, y otros elementos del clúster, como switches. Funcionamiento general: El sistema utiliza Telegraf, InfluxDB, Grafana yIcinga2 para la recopilación de métricas, almacenamiento de datos, visualización, y gestión de alertas. Además, emplea ElasticSearch y Kibana para el manejo de logs . Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 72 Diagrama y flujo del sistema: Figura 22: Diagrama arquitectura monitoring MN5 Componentes principales y flujo del diagrama –Nodos de cómputo: oLos nodos de cómputo envían métricas mediante Telegraf, que actúa como agente de recopilación. oLas métricas se redirigen a través de los nodos de servicio. –Telegraf: oHerramienta central para la recopilación de métricas del hardware , sistema operativo y aplicaciones. oUtiliza plugins: –Input Plugins: Para recolectar métricas. –Output Plugins: Para almacenar datos en InfluxDB o enviarlos a otros sistemas. –Aggregator Plugins: Para agregar datos (promedios, totales, etc). –Processor Plugins: Para transformar y filtrar métricas antes del almacenamiento. –Nodos de servicios: oReciben las métricas desde los nodos de cómputo. oActúan como intermediarios para garantizar que las métricas lleguen a los nodos de monitorización principales (mon1 ymon2). –Nodos de monitorización (mon1 y mon2): oInfluxDB: base de datos de series temporales para almacenar métricas recolectadas. Configurada para almacenamiento eficiente y consulta rápida. oGrafana: Utilizado para la visualización de métricas mediante dashboards interactivos. Los dashboards son replicados automáticamente entre mon1 y mon2 para garantizar consistencia y alta disponibilidad. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 73 oKibana: Proporciona herramientas para explorar y analizar logs almacenados en ElasticSearch. Ofrece visualizaciones específicas para el monitoreo de trabajos y eventos en el sistema. oIcinga2: Sistema de alertas configurado para enviar notificaciones cuando se detectan anomalías, como servicios caídos o sobrecargas. –Planificadores (Schedules): oGestionan y organizan los jobs que los usuarios envían al clúster. oDeterminan en qué nodos de cómputo se ejecutará cada job, teniendo en cuenta factores como disponibilidad de recursos, prioridades, y políticas del sistema. oInteractúan con el sistema de colas, Slurm. oGeneran registros detallados ( logs ) de los trabajos, como tiempos de inicio, finalización, y consumo de recursos utilizando ElasticSearch. 13.3. Instalación Perf_D La instalación y configuración de Perf_D requiere varios pasos clave que aseguran que el daemon funcione correctamente en el entorno del clúster. Punto de partida A diferencia del punto de partida en el clúster pequeño (CTE-AMD), en esta etapa ya estamos familiarizados con Perf_D, dado que logramos instalarlo correctamente. Por lo tanto, el punto de partida en este caso será la versión de Perf_D previamente instalada en el clúster CTE-AMD. Preparación del entorno De igual manera que en el clúster pequeño, nos aseguramos que el entorno cumple con los requisitos necesarios para ejecutar Perf_D: –Perl 5 instalado. –Framework Mojolicious disponible. –Acceso root al sistema para instalar y configurar servicios. A diferencia de la preparación del entorno en CTE-AMD, en MN5 no se otorgó acceso root debido a la criticidad del sistema y la necesidad de preservar su estabilidad, dado que cualquier error en la configuración podría comprometer el rendimiento o la operación del clúster. No obstante, se asigno un usuario icinga con los permisos necesarios para la instalación y configuración de los servicios, permitiendo reiniciar y modificar el servicio Perf_D si era requerido. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 80 13.6. Pruebas y validación Algunas de las pruebas que se hicieron para la validación de la integración de MN5 como clúster monitorizado por OG3v2 fueron: –Verificación de la recopilación de datos en la ruta de nodos Figura 23: Datos de los nodos del clúster MN5 –Verificación de la recopilación de datos en la ruta de jobs Figura 24: Datos de los jobs del clúster MN5 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 81 –Visualización de los nodos y sus etiquetas en OG3v2 según su posición lógica Figura 25: Visualización lógica de los nodos del clúster MN5-GPP –Visualización de los nodos y sus etiquetas en OG3v2 según su posición física Figura 26: Visualización física de los nodos del clúster MN5-GPP Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 82 –Visualización de la lista de trabajos que están ejecutándose Figura 27: Visualización de la lista de trabajos ejecutándose de los nodos del clúster MN5-GPP –Visualización del resumen de trabajos de la lista de jobs que están ejecutándose Figura 28: Visualización del resumen de trabajos de los nodos del clúster MN5-GPP Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 83 –Creación de la pestaña para la acción checkjob de un job en específico Figura 29: Acción checkjob para el job 14108755 en MN5-GPP –Creación de la pestaña para la acción sljcf de un job en específico Figura 30: Acción sljcf para el job 14108755 en MN5-GPP Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 84 –Configuración de los umbrales de valores de las métricas # Rangos de limites de las diferentes métricas self.THRESHOLD = { 'cpu_temp': [45, 50, 60, 70], 'load_one': [0.5, 1.5, 2.5, 3.5], 'cpu_load_one': [0.25, 0.75, 1.04, 1.15], 'mem_free': [21474836480, 53687091200, 107374182400, 214748364800], } A diferencia del clúster CTE-ADM, no nos encontramos con problemas de ttl, los valores recibidos por Telegraf y almacenados en InfluxDB son correctos y en tiempo real. Por lo que, una vez configurados los umbrales de las métricas que mostramos se pintan los nodos dependiendo del valor de la métrica y en el umbral en el que se encuentre. –Apertura de la pestaña de monitoring para múltiples nodos que se encuentran ejecutando un job en el navegador web Figura 31: Acción monitoring de los mútiples nodos que ejecutan un job en MN5-GPP En este panel se pueden analizar, para los múltiples nodos seleccionados, métricas clave como la carga de CPU, el uso de la memoria y el estado general de los nodos, lo que permite identificar patrones, optimizar el rendimiento y detectar posibles problemas en tiempo real. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 85 –Visualización de la pestaña ELEGIBLE con su respectiva lista de trabajos y resumen Figura 32: Visualización de la pestaña ELEGIBLE en MN5-GPP –Visualización de la pestaña BLOCKED con su respectiva lista de trabajos y resumen Figura 33: Visualización de la pestaña BLOCKED en MN5-GPP Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 86 –Visualización de los logins y sus etiquetas en OG3v2 según su posición lógica Figura 34: Visualización lógica de los logins del clúster MN5-GPP –Últimos pasos en la validación de OG3v2 En este punto, nuestro objetivo principal se ha logrado, se ha implementado un sistema de monitorización OG3v2 en MN5. Sin embargo, debido a los imprevistos causados durante todo el desarrollo del proyecto, ya sea por la falta de conocimiento, retrasos en la correción de errores, etc, solo se ha implementado OG3v2 para la Partición de Propósito General (GPP). Se realiza una última reunión para hablar del cumplimiento de requisitos, en el que se habla de diferentes puntos a tratar: –Debido al poco tiempo de margen, se decide implementar la partición de Acelerada (ACC) en un futuro. –Se mencionan posibles funcionalidades que tendría la partición de Acelerada. –Se mencionan posibles funcionalidades que tendrían los nodos de los clústeres monitorizados. –Se recomienda subir el código a un repositorio de GitLab compartido con el departamento de Operaciones. –Validación de los actores implicados en el proyecto Se procede a desplegar la herramienta en un repositorio de GitLab para que los actores implicados en el proyecto puedan testearla en busca de bugs a corregir en un plazo corto de tiempo. Una vez ha habido feedback de los posibles errores que se muestran en la ejecución de la herramienta, se procede a corregir cada uno de los errores indicados, hasta haber solucionado todos. Algunos de los errores corregido fueron: –La combinación de filtrado, poder mantener el filtrado de nodos y jobs a la vez. –La selección de nodos según el job seleccionado. –La combinación del filtrado de nodos y jobs junto al gradiente. –Mantener el estado de filtrado o selección de nodos pasados 60 segundos (actualización de los datos de OG3v2 por defecto). Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 87 14. Actualizaciones y funcionalidades nuevas de OG3v2 A lo largo del proyecto, OG3v2 ha sido sometido a varias actualizaciones y se han incorporado nuevas funcionalidades para mejorar su capacidad de supervisión y gestión de los clústeres. Algunas de las nuevas funcionalidades añadidas por mi serían: Tipos de métricas dependiendo del clúster: En la versión original de OG3 desarrollada en Perl, los clústeres compartían un conjunto único de métricas, lo que generaba incongruencias al mostrar métricas inexistentes para determinados clústeres. Para solucionar este problema, he desarrollado una funcionalidad en OG3v2 que asegura que cada vez que se cambia de clúster, las métricas mostradas correspondan únicamente a aquellas que estén siendo monitorizadas por el clúster seleccionado en ese momento. Esto garantiza una visualización más precisa y evita confusiones al supervisar métricas específicas. Figura 35: Menú de métricas en el clúster CTE-AMD Figura 36: Menú de métricas en el clúster MN5-GPP Visualización física de los nodos por racks Con la intención de mejorar la experiencia del usuario, se ha buscado facilitar la supervisión de los nodos de cómputo de manera que se puedan visualizar de forma física, como si los vieras alojado en el rack al que pertenece. Este tipo de visualización ya se conseguía en anteriores clústeres monitorizados mostrando los nodos en filas como si fueran un rack, uno al lado del otro. Sin embargo, dado que la Partición de Propósito General (GPP) de MN5, contiene una gran cantidad de nodos, concretamente 6.480, puede resultar un poco peliagudo para Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 88 el usuario tener que estar todo el rato desplazando el tablero para poder visualizar los nodos de un rack en concreto. Por ejemplo, podemos ver en una sola vista, todos los nodos del clúster CTE-AMD ( Figura 21 ), pero no podemos ver todos los nodos de GPP de MN5 ( Figura 26 ). Figura 37: Layout de la infraestructura de MN5 Figura 38: Layout de la infraestructura de MN5-GPP Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 89 Los 6.480 nodos de cómputo de GPP se dividen en 90 racks, repartidos en 6 filas y 15 columnas, cada rack aloja 72 nodos, repartidos en 36 filas y 2 columnas. Sabiendo esto, he diseñado una visualización nueva teniendo como referencia el layout de la infraestructura de los racks de la partición de GPP de MN5 y he creado los archivos: –positions_physical_racks.json: define las posiciones de los nodos en el tablero físico por racks de OG3v2. –tags_physical_racks.json: define las etiquetas de los nodos en el tablero físico por racks de OG3v2. A diferencia de la visualización physical_nodes, en la visualización physical_racks se quieren ver todos los nodos del clúster en una única vista, por lo que habrán posiciones de los nodos que no serán únicas, sino que habrá que seleccionarlas diciendo que racks queremos ver. Por lo tanto, para solucionar este conflicto, he añadido la funcionalidad de seleccionar grupos de 15 racks dependiendo del rack al que se seleccione con el ratón. Figura 39: Visualización física de los nodos pertenecientes a los racks g[46-60] del clúster MN5-GPP De esta manera podremos controlar que el usuario pueda visualizar los nodos de los racks que elija seleccionar sin la necesidad de irse desplazando por el tablero, y sólo dándole click al rack que quiera ver. De igual manera, para que haya coherencia entre los nodos que se encuentran en la vista y la lista de trabajos, se ha filtrado la tabla de trabajos para que se muestren únicamente los jobs que están ejecutándose en los nodos visibles (seleccionando los nodos que tienen un job running y opacando los que no). Para finalizar, se ha deshabilitado la opción de filtrar los nodos estando en este tipo de visualización, ya que se están filtrando por racks seleccionados y no tendría sentido combinar estas dos acciones. Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 96 offset_x = ((block-1) * 3 + (r - 1)) * rack_spacing current_posx1 = initial_posx1 + offset_x current_posx2 = initial_posx2 + offset_x posy = initial_posy # Reiniciamos posy al valor inicial para cada rack for b in range(1, 73): # 72 nodos por rack # Formateamos el nombre de cada nodo key = f"gs{gs:02}r{r}b{b:02}" # Alternamos entre current_posx1 (izquierda) y current_posx2 (derecha) posx = current_posx1 if b % 2 != 0 else current_posx2 # Asignamos los valores de posx y posy para el nodo data[key] = {"posx": posx, "posy": posy} # Reducimos posy en node_spacing_y después de cada par de nodos if b % 2 == 0: posy -= node_spacing_y return data def generate_positions_physical_racks(): data = {} posy = 4.0 posx = 2.0 row1 = 3.0 row2 = 5.0 # Generamos los valores para los 90 racks for r in range(1, 91): # Formateamos el nombre de cada rack key = f"r_g{r:02}" # Asignamos valores de posx y posy para el rack data[key] = {"posy": posy, "posx": posx} if r == 7 or r == 22 or r == 37 or r == 52 or r == 67 or r == 82: posx += row1 elif r == 11 or r == 26 or r == 41 or r == 56 or r == 71 or r == 86: posx += row2 else: # Incrementamos posx para el siguiente rack posx += 1.55 if r == 60: posy += 4.0 # Cada 15 racks, reiniciamos posx y aumentamos posy en 39 if r % 15 == 0: posx = 2.0 posy += 6.5 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 97 # Parámetros iniciales initial_posx1 = 32.5 # posición x de los nodos impares en el primer rack initial_posx2 = 33.5 # posición x de los nodos pares en el primer rack initial_posy = 41.5 # posición y inicial para cada rack rack_spacing = 3.0 # separación horizontal entre racks node_spacing_y = 1.0 # separación vertical entre nodos block = 0 # Generamos los valores para cada rack independiente for gs in range(1, 31): # Racks de 01 a 30 if gs % 5 == 1 and gs > 1: block = 1 initial_posy = 41.5 else: block += 1 for r in range(1, 4): # r1, r2, r3 son racks independientes # Calculamos el desplazamiento horizontal para cada rack (combinación única de gs y r) offset_x = ((block-1) * 3 + (r - 1)) * rack_spacing current_posx1 = initial_posx1 + offset_x current_posx2 = initial_posx2 + offset_x posy = initial_posy # Reiniciamos posy al valor inicial para cada rack for b in range(1, 73): # 72 nodos por rack # Formateamos el nombre de cada nodo key = f"gs{gs:02}r{r}b{b:02}" # Alternamos entre current_posx1 (izquierda) y current_posx2 (derecha) posx = current_posx1 if b % 2 != 0 else current_posx2 # Asignamos los valores de posx y posy para el nodo data[key] = {"posx": posx, "posy": posy} # Reducimos posy en node_spacing_y después de cada par de nodos if b % 2 == 0: posy -= node_spacing_y return data def save_json(data, filename): # Guardamos en un archivo JSON with open(filename, "w") as json_file: json.dump(data, json_file, indent=4) print(f"Archivo {filename} generado exitosamente.") def main(): save_json(generate_positions_logical(), "positions_logical.json") save_json(generate_positions_physical_nodes(), "positions_physical_nodes.json") save_json(generate_positions_physical_racks(), "positions_physical_racks.json") if __name__ == "__main__": main() Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 98 generate_tags.py import json def generate_tags_logical(): data = {} posy = 2 # Generamos los valores para los 90 racks for gs in range(1,31): for r in range(1, 4): posy += 1 # Formateamos el nombre de cada rack key = f"gs{gs:02}r{r}" # Asignamos valores de posx y posy data[key] = {"posy": posy, "posx": 0} posy += 2 posx = 0 for i in range(1, 5): # Para glogin1, glogin2, glogin3, glogin4 key = f"glogin{i}" data[key] = {"posy": posy, "posx": posx} posx += 5 return data def generate_tags_physical_nodes(): data = {} posy = 2.5 posx = 1.5 # Generamos los valores para los 90 racks for r in range(1, 91): # Formateamos el nombre de cada rack key = f"g{r:02}" # Asignamos valores de posx y posy para el rack data[key] = {"posy": posy, "posx": posx} # Incrementamos posx para el siguiente rack posx += 3.0 # Cada 15 racks, reiniciamos posx y aumentamos posy en 39 if r % 15 == 0: posx = 1.5 posy += 39.0 return data def generate_tags_physical_racks(): data = {} posy = 2.5 posx = 1.5 Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 99 row1 = 3.0 row2 = 5.0 # Generamos los valores para los 90 racks for r in range(1, 91): # Formateamos el nombre de cada rack key = f"r_g{r:02}" # Asignamos valores de posx y posy para el rack data[key] = {"posy": posy, "posx": posx} if r == 7 or r == 22 or r == 37 or r == 52 or r == 67 or r == 82: posx += row1 elif r == 11 or r == 26 or r == 41 or r == 56 or r == 71 or r == 86: posx += row2 else: # Incrementamos posx para el siguiente rack posx += 1.55 if r == 60: posy += 4.0 # Cada 15 racks, reiniciamos posx y aumentamos posy en 39 if r % 15 == 0: posx = 1.5 posy += 6.5 # Parámetros iniciales initial_posx = 32.25 # posición x inicial para cada rack initial_posy = 5.0 # posición y inicial para cada rack rack_spacing = 3.0 # separación horizontal entre racks block = 0 # Generamos los valores para cada rack independiente for gs in range(1, 31): # Racks de 01 a 30 if gs % 5 == 1 and gs > 1: block = 1 else: block += 1 for r in range(1, 4): # r1, r2, r3 son racks independientes # Calculamos el desplazamiento horizontal para cada rack posx = ((block-1) * 3 + (r - 1)) * rack_spacing + initial_posx posy = initial_posy g_index = (gs - 1) * 3 + r key = f"g{g_index:02}" # Asignamos los valores de posx y posy para el nodo data[key] = {"posx": posx, "posy": posy} return data def save_json(data, filename): Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 100 # Guardamos en un archivo JSON with open(filename, "w") as json_file: json.dump(data, json_file, indent=4) print(f"Archivo {filename} generado exitosamente.") def main(): save_json(generate_tags_logical(), "tags_logical.json") save_json(generate_tags_physical_nodes(), "tags_physical_nodes.json") save_json(generate_tags_physical_racks(), "tags_physical_racks.json") if __name__ == "__main__": main() Diagrama de clases completo OG3v2 ```mermaid classDiagram class MyApp { -job_list_running : List -job_list_elegible : List -job_list_blocked : List -data_object : Data -board : Board -metric_selected : str -display_config_selected : str -cluster_selected : str -invert : bool -unit : str -metrics_menu : list[str] -open_tabs : dict -tabs : dict -status_labels : dict -timer : QTimer -is_updating : bool +__init__() +createTabs() +createRunningTab(tab : QWidget) +createElegibleTab(tab : QWidget) +createBlockedTab(tab : QWidget) +createStatusBar() +createJobsLists() +update_metric(selected_option : str) +change_display_config(selected_option : str) +update_data() +refresh() +refresh_gradient(scale_factor : int, unit : str, adjust_min : bool, adjust_max : bool) +update_gradient() +change_cluster(selected_option : str) Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 101 +change_filt() +toggle_filt() +select_row(row : int, job_list : List) +row_selection_changed(job_list : List, current_row : int) +toggle_reverse_colors() +joblist_menu(list_type : str, position : QPoint) +create_job_tab(job : str, list_type : str, action : str) +close_tab(tab_id : str) +open_info(job_id : str) +toggle_grad() +keyPressEvent(event : QKeyEvent) +refresh_gradient(scale_factor : int, unit : str, adjust_min : bool, adjust_max : bool) +closeEvent(event : QCloseEvent) } class Board { -node_width : int -node_height : int -nodes_begin_x : int -nodes_begin_y : int -node_items : dict -rack_items : dict -related_racks : list -TOTAL_NODES : int -USED_NODES : int -GRADIENT : int -GRADMIN : float -GRADMAX : float -REVERSE : bool -TEXT_COLOR : str -FONT_SIZE : int -current_zoom : float -min_zoom : float -max_zoom : float -zoom_factor : float -select_row : int -select_nodes : list -is_active_selection : bool -filter_nodes : bool -filter_text_nodes : str -display_value : str -NODES : dict -JOBS : dict -POSITIONS : dict -TAGS : dict -METRIC : str -STATUS_BAR : dict -JOB_LIST : object -CANVAS : QWidget -scene : QGraphicsScene Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 102 -graphics_view : QGraphicsView +__init__() +adjust_scrollbars() +build(canvas: QWidget, data_object: object, job_list: object, status_bar: dict, metric_selected: str) +change_display_config(data_object: object, display: str) +change_metric(metric: str) +clear_board() +draw() +eventFilter(source: object, event: QEvent) -> bool +expand_node_range(node_range: str) -> list +filter_jobs_by_nodes() +filter_jobs_by_racks(selected_racks: list) +filter_jobs_by_text() +filter_nodes_by_racks(selected_racks: list) +get_color(value, alive: int, metric: str, suspend: int = None) -> str +get_grad_max() -> float +get_grad_min() -> float +get_nodes_for_job(job_ids: list | str) -> list +get_related_racks(rack_name: str) -> list +get_starttime_for_job(job_id: str) -> int | None +gradient(num: float) -> str +highlight_table_jobs(job_ids: list) +on_node_click(rect: QGraphicsRectItem) +on_node_hover_enter(rect: QGraphicsRectItem) +on_node_hover_leave() +on_rack_click(rack_name: str) +on_rack_hover_enter(rect: QGraphicsRectItem) +on_rack_hover_leave() +reset_job_filter() +reset_node_colors() +reverse_colors(state: bool) +select_jobs_for_node(node_name: str) +select_nodes_for_job(job_ids: list | str = None) +select_racks() +set_grad_max(grad_max: float) +set_grad_min(grad_min: float) +set_gradient(value: bool) +set_initial_first_rack_group() +set_initial_zoom(display_value: str) +update(data_object: object = None) +zoom_in() +zoom_out() @staticmethod +bytes_to_human(bytes: int, mul: int = 1024) -> str } class Data { Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 103 -NODES : dict -JOBS : dict -RUNNING : dict -ELEGIBLE : dict -BLOCKED : dict -POSITIONS : dict -TAGS : dict -MAX : float -MIN : float -DATE : str -ADDR : str -METRIC : str -DISPLAY : str -CLUSTER : str -CLUSTERS : dict -UA : requests.Session -SRV : str -count_attempt : int -CONFIG : dict +__init__() +build(metric: str, display: str) +update() +get_active_jobs() +get_remaining(job: str) -> int | None +get_nodes() +reset_node_data() +reset_job_data() +get_positions(display_config: str) +get_tags(display_config: str) +get_cpu_load_one() +get_cpu_avg_temp() +get_load_data() +reset_load_data() +checkjob(job: str) -> str +sljcf(job: str) -> str +monitoring_addr() -> str | None +set_metric(metric: str) +get_metric() -> str +set_display(display: str) +get_display() -> str +set_cluster(cluster: str) +get_cluster() -> str +get_max() -> float +get_min() -> float } class List { -table_widget : QTableWidget -last_selected_row : int Implementación de un sistema de monitorización OG3 en el supercomputador MareNostrum 5 Antony Joel Baño Vaca 104 -COLID : list -HEADER : list -COLFORMAT : list -COLWIDTH : list -TYPE : list -SORTCOL : int -SORTASC : bool -FONTSIZE : int -BFONT : str -LIMIT : int | None -TOTAL : bool -filter_entry : QLineEdit -summary_frame : QFrame -summary_layout : QVBoxLayout -JOB_LIST : dict +__init__() +set_selected(row: int) +get_selected(row: int) -> QTableWidgetItem | None +set_limit(limit: int | None) +get_limit() -> int | None +set_total(total: bool | None) +get_total() -> bool | None +register_column(col_id: str, name: str, format_str: str, col_type: str, width: int, sort_def: str | None, sort_dir: bool | None) +register_job_list(job_list: dict, cluster: str) +build(parent_job_widget: QWidget, parent_summary_widget: QWidget, type_list: str) +update(table_widget: QTableWidget) +apply_filter() +filter_jobs_by_partition(jobs: dict, partition: str = "gpp") -> dict +get_visible_jobs() -> list +change_sort(col: int) +sort_table(col: int, sort_func: callable) +sort_alpha(value: str) -> str +sort_num(value: str) -> int | float +sort_time(value: str) -> int | float +sort_date(value: str) -> datetime } MyApp --> Board MyApp --> Data MyApp --> List Board --> Data ```