Péndulo: clúster nocturno

Transcripción

1 Péndulo: clúster nocturno Proyecto de Fin de Carrera de modalidad empresas o instituciones Realizado por: Rocío Carrillo González (firma) Dirigido por: Juan Iturbe Barrenetxea (firma) Supervisado por: Sebastián Dormido Canto (firma) Tribunal calificador: Presidente: D./D a... (firma) Secretario: D./D a... (firma) Vocal: D./D a... (firma) Fecha de lectura y defensa:... Calificación:...

2 2

3 3 Resumen del proyecto El proyecto Péndulo consiste en la construcción de un clúster de cálculo reutilizando los activos existentes en la Universidad del País Vasco/Euskal Herriko Unibertsitatea (UPV/EHU). Utiliza como nodos los ordenadores de las aulas informáticas, pero dado que las aulas se utilizan en horario docente para sus actividades normales, el clúster funciona únicamente durante las noches, fines de semana, festivos y periodos vacacionales. Se compone de un servidor (front-end), para el que se ha empleado un servidor retirado de los servicios de la UPV/EHU; y 80 nodos de cálculo repartidos en dos salas. Se dispone además de dos nodos de pruebas. Puesto que los nodos no están activos en horario laboral, resulta de gran importancia minimizar las tareas de mantenimiento en los nodos, centralizándolas en el servidor o automatizándolas para su ejecución durante la noche. El arranque de aulas y clonado de los equipos se hace mediante un servidor de imágenes. Palabras clave Cálculo computacional, arquitecturas paralelas, clústeres, arranque remoto.

4 4 Abstract The project Péndulo consists in the construction of a Computing cluster reusing the assets of the University of the Basque Country (UPV/EHU). It uses as nodes the computers of the computer rooms, but since the rooms are used in teaching schedule for their normal purposes, the cluster works only during the nights, weekends and holidays. It is made up of a server (front-end) for which a retired server of the services of the UPV/EHU has been used, and 80 distributed computing nodes placed in two different rooms. Furthermore, two more nodes are available for tests. As nodes are not active in labour schedule, it is very important to minimize the maintenance tasks in the nodes, centralizing them in the server or programming them to be executed during the night. The computers booting and cloning is done using a server of images. Key Words Scientific computing, parallel architecture, cluster, remote booting.

5 A todos los estudiantes

6 6

7 Agradecimientos En primer lugar, quiero dar las gracias a mi director por ser el verdadero padre del proyecto, ya que concibió la idea del clúster a tiempo parcial que fue el germen del actual Péndulo. A los chicos del CIDIR, por su paciencia resolviendo las miles de dudas y problemas que me iban surgiendo. Y en especial a Edu, por todo su trabajo y su esfuerzo, sin el cual el proyecto no hubiera podido llegar a lo que es hoy. No puedo olvidar a mis amigos, que han soportado mi mal humor en las épocas de mayor estrés, y que han tenido la paciencia de leer todo lo que yo escribía aún no entendiendo nada de informática. Sin su ayuda este documento hubiera resultado ininteligible en ciertas ocasiones. Por último, quisiera agradecer a todo el mundo que de una forma u otra ha estado implicado en el desarrollo de este trabajo, su paciencia y apoyo. Leoia, 13 de marzo de

8 8

9 Prólogo La más larga caminata comienza con un paso Proverbio hindú Los equipos de investigación y sus áreas de conocimiento son cada vez más amplios y requieren de una potencia de cálculo cada vez mayor. Por esa razón, la demanda de recursos de cálculo computacional dentro de la universidad crece de año en año. La Universidad del País Vasco/Euskal Herriko Unibertsitatea ofrece a sus investigadores la máquina de cálculo ARINA desde el año 2004, facturándose en función de su utilización. Dada la creciente necesidad de cálculo de los investigadores, esta máquina ha tenido que ser ampliada en dos ocasiones. Aún así, algunos grupos de investigación se han visto en la necesidad de adquirir y montar clústeres de uso privado o buscar recursos en otros clústeres como por ejemplo el MareNostrum del BSC (Barcelona Supercomputing Center). Por otro lado, la universidad dispone de numerosas aulas informáticas, tanto docentes como de libre uso para sus alumnos. Estas aulas son utilizadas en horario diurno durante la semana laboral, estando sus equipos apagados fuera de estas horas. Por un lado la necesidad creciente de potencia de cálculo, y por otro lado, la existencia de recursos infrautilizados en la universidad dibujan la situación de partida que ha dado origen al proyecto Péndulo. 9

10 10 En el 2005 surge la idea, a partir de trabajos en otras universidades, de montar un clúster que podría estar disponible mientras las aulas permanecieran cerradas al público. Bautizamos el proyecto con el nombre de Péndulo por dos razones. Por un lado, el proyecto piloto nació en el edificio de la Biblioteca del Campus de Leioa de cuyo techo colgaba un enorme Péndulo de Foucault. Por otro lado, dado que nuestros ordenadores oscilarían continuamente entre sistemas operativos, y entre clúster y aula docente, el nombre nos pareció muy descriptivo. Rocío Carrillo

11 Índice general 1. Introducción Cálculo científico Paralelización Supercomputación Clúster de cálculo Ventajas de un clúster de cálculo Tipos de clústeres de cálculo Funcionamiento y componentes Antecedentes Situación de partida El proyecto piloto Péndulo Objetivos y Requisitos del nuevo Péndulo Condiciones de funcionamiento Otros requerimientos Desarrollo del proyecto Configuración inicial Nuevo Sistema Operativo Sistema de almacenamiento global Nuevo Servidor y conexión a la cola de pruebas Nuevo gestor de colas Autentificación de usuarios mediante LDAP Conexión del aula de cursos Desaparición del aula de campus original Problemas encontrados Coordinación entre departamentos

12 12 ÍNDICE GENERAL Clonación de equipos SuSE Linux Caracteres en la terminal de log in Otros problemas Gestión del clúster Arranque Dual Gestión de colas Gestión de usuarios Instalación de software Automatización de tareas Sistema de almacenamiento temporal global Monitorización Web Otras tareas de monitorización y mantenimiento Pruebas Prueba de programas Pruebas del funcionamiento de las colas Análisis de rendimiento Pruebas con el programa VASP Pruebas con el programa NWChem en el Aula de Campus Otras pruebas Paralelización entre switches Optimización de tamaño de paquete para NFS Presupuesto Planificación de tareas Planificación inicial Desviación de lo planificado Lista de tareas y plazos reales Resumen de gastos Conclusiones y líneas futuras Objetivos conseguidos Líneas futuras Medios utilizados

13 ÍNDICE GENERAL 13 A. Glosario de términos y acrónimos 119 A.1. Acrónimos A.2. Definiciones y aclaraciones de términos B. Listados de código 127 B.1. Scripts de Rembo B.2. Scripts de gestión del sistema B.3. Scripts de gestión de usuarios y cuentas B.4. Scripts del sistema de colas B.5. Scripts de monitorización

14 14 ÍNDICE GENERAL

15 Índice de figuras 1.1. Nanotubo simple Nanotubo complejo Ley de Amdahl División de tareas en OpenMP División de tareas en MPI Máquina de cálculo Arina Aula de campus, de libre uso para los alumnos Configuración del aula piloto Distribución por switches Adición del aula de cursos. Convivencia entre distintos S.O Sistema de almacenamiento global Nuevo Servidor y cola de pruebas Recorrido de datos de un cálculo para su ejecución Conexión del aula de cursos Configuración actual de Péndulo Formulario Web de solicitud de cuenta. Validación LDAP Formulario Web de solicitud de cuenta. Obtención de datos Sistema de archivos de Péndulo Página Web de monitorización Pruebas de paralelización en Arina y Péndulo: Tiempo de CPU Pruebas de paralelización en Arina y Péndulo: Coeficiente de paralelización Pruebas en Péndulo con VASP optimizado: Tiempo de CPU Pruebas en Péndulo con VASP optimizado: Coeficiente de paralelización Molécula de la penicilina Pruebas paralelización Aula Campus: Tiempo de CPU

16 16 ÍNDICE DE FIGURAS 5.7. Pruebas paralelización Aula Campus: Walltime Pruebas paralelización: Una CPU por nodo Pruebas paralelización: Dos CPU por nodo Pérdida de velocidad en las comunicaciones entre switches Diagrama Gantt inicial Diagrama Gantt de seguimiento 10/2006 a 06/ Diagrama Gantt de seguimiento 07/2007 a 03/ Leyenda para el Gantt de seguimiento Comparación del Gantt inicial y el de seguimiento

17 Índice de Tablas 5.1. Tiempos de ejecución en Arina y Péndulo Tiempos de ejecución en Péndulo con el nuevo VASP Tiempos de ejecución en el Aula de Campus Tiempos de ejecución según switches Comparativa velocidad NFS según tamaño de paquete Comparativa velocidad NFS según switches Planificación inicial Fechas y plazos reales de las tareas realizadas Comparativa entre las duraciones planificadas y reales

18 18 ÍNDICE DE TABLAS

19 Índice de listados 4.1. Startup script administrar (fragmento) Startup script info B.1. Página inicial de REMBO arranquedell.shtml B.2. Script de arranque normal B.3. Script de arranque para Linux B.4. Script menu_admin B.5. Script administrar B.6. Script restaurar_linux B.7. Script restaurar_windows B.8. Script crea_imagenlinux B.9. Script crea_imagenwindows B.10.Script crear_particiones B.11.Script cldo B.12.Script ascp B.13.Script confignet B.14.Script de inicio administrar B.15.Script de inicio del almacenamiento global B.16.Script de inicio del almacenamiento local B.17.Script de apagado del almacenamiento B.18.Script bin_wrapper B.19.Script ahorrar_energia B.20.Script de inicio para el demonio de backup B.21.Script genera-cuenta B.22.Script genera-passwd.pl B.23.Script qsub B.24.Script qsub_arina B.25.Script qsub_pendulo B.26.Script qsub_all en Arina

20 20 ÍNDICE DE LISTADOS B.27.Script qsub_all en Péndulo B.28.Script de ejemplo para qsub B.29.Prólogo del sistema de colas B.30.Script qdel_all B.31.Script qdel_arina B.32.Script qdel_pendulo B.33.Script qstat_arina B.34.Script qstat_pendulo B.35.Script rqstat B.36.Script qqstat B.37.Script qqstat B.38.Script kill_server_jobs B.39.Script comprobar_encendidos B.40.Script limpiar_queue_scratch B.41.Script monitoring_cpu B.42.Script web.sh B.43.Script figure1.sh B.44.Script figure2.sh

21 Capítulo 1 Introducción En este capítulo se hace una introducción a los clústeres de cálculo de manera que pueda entenderse correctamente la descripción del desarrollo del proyecto en posteriores capítulos. Comenzaré con una breve introducción al cálculo científico y a la supercomputación (super computing) en general, para después centrar mi exposición en los distintos tipos de clúster existentes y sus componentes. Incluiré además una breve referencia a la paralelización (parallel computing) como recurso para el cálculo computacional y especialmente para la computación de altas prestaciones Cálculo científico El cálculo computacional o cálculo científico es una actividad de la Ciencia que construye modelos matemáticos y aplica técnicas numéricas para resolver problemas científicos, de ciencias sociales, problemas de ingeniería, etc. Estos modelos requieren gran cantidad de cálculos y son a menudo ejecutados en supercomputadores o plataformas de computación distribuida. La característica más notable del cálculo científico es su naturaleza multidisciplinaria, siendo la base para proyectos de investigación en múltiples campos de aplicación, como pueden ser por ejemplo: 1. Simulación de materiales y moléculas a escala atómica. 2. Modelado de biopolímeros (proteínas, ADN, etc.) a nivel estructural y dinámica molecular. 3. Climatología y Meteorología: predicciones meteorológicas y simulación de propagación de contaminantes. 21

22 22 Paralelización Figura 1.1: Nanotubo simple. Fuente: En química, se denominan nanotubos a estructuras tubulares cuyo diámetro es del orden del nanómetro. Figura 1.2: Nanotubo complejo. Fuente: 4. Predicciones bursátiles y gestión empresarial. 5. Aplicaciones de Bioinformática. 6. Estudio de fármacos y enfermedades. 7. Análisis del genoma humano. Se puede afirmar que cuanto más y mejores sean los recursos destinados a ese cálculo científico, más y mejores podrán ser los avances en la investigación. El avance tecnológico se ha visto, además, acompañado de una mayor demanda de recursos. Así por ejemplo, los investigadores que en un principio se planteaban cálculos con teorías sencillas sobre estructuras simples como la de la figura 1.1, ahora se atreven con teorías más completas sobre sistemas más complejos como el de la figura Paralelización Las prestaciones del hardware no crecen indefinidamente sino que tienden a saturarse, de tal forma que resulta mucho más barato adquirir dos sistemas con ciertas prestaciones, que un sistema con el doble de prestaciones. Si la tarea que debe realizarse pudiera repartirse equitativamente entre dos sistemas que la ejecutaran de forma simultánea, se obtendrían los resultados en el mismo tiempo pero con un coste mucho inferior. Podemos definir un computador paralelo como un conjunto de elementos de proceso independientes que operan de forma conjunta para resolver problemas de elevado coste computacional en un tiempo razonable"[dhrs03]. De esta forma, la computación

23 Capítulo 1. Introducción 23 paralela o procesamiento en paralelo consiste en acelerar la ejecución de un programa mediante su descomposición en fragmentos que pueden ejecutarse de forma simultánea, cada uno en su propia unidad de proceso". Idealmente podríamos utilizar n ordenadores para multiplicar por n la velocidad de cálculo. No obstante, por regla general los problemas no pueden dividirse perfectamente en partes totalmente independientes y equilibradas. Existen partes que deben realizarse en serie, y en ocasiones las tareas necesitan interaccionar entre ellas. Todo ello reporta una disminución en la capacidad. Podemos decir que un algoritmo tiene un mayor o menor grado de paralelismo o es más o menos escalable en función de que sea más o menos divisible en partes independientes con igual coste computacional. En raras ocasiones un cálculo en n ordenadores acelera en más de n veces 1. Llamamos aceleración (speedup) a la relación entre el tiempo que necesita un procesador (t s ) y el tiempo que necesitan M procesadores idénticos para realizar el mismo trabajo. La aceleración no crece linealmente con el número de procesadores, sino que tiende a saturarse. Según la Ley de Amdahl 2, si llamamos f a la fracción del programa que no se puede dividir en tareas paralelas, el tiempo de computación necesario para ejecutar el programa en M procesadores (t p (M)) será: t p (M) = f t s + (1 f) t s M, 0 f 1 El efecto de esta saturación de la aceleración puede verse en la figura 1.3. Cuando f =0, un programa lanzado a 32 procesadores se ejecuta 32 veces más rápido que en un procesador; sin embargo, cuando f =0.05 un programa lanzado a 32 procesadores sólo se ejecuta 13 veces más rápido que al lanzarlo a un procesador. Para utilizar la paralelización en un entorno de cálculo es necesario programarla específicamente. Existen varios estándares para realizarlo, por ejemplo: Para sistemas de memoria compartida: POSIX Threads y OpenMP. Para sistemas de memoria distribuida (modelo de paso de mensajes): MPI 3 y PVM 4. 1 Este procso de superescalado se puede dar debido a la mayor memoria caché agregada, pero como ya se ha mencionado esto se da raras veces. 2 Sólo tiene en cuenta qué parte del código se ejecuta en serie y qué parte paraleliza de forma ideal. 3 Message Passing Interface (Interfaz de Paso de Mensajes). A pesar de estar diseñado como paso de mensajes, algunas implementaciones de MPI suelen estar también optimizadas para sistemas de memoria compartida. 4 Parallel Virtual Machine (Máquina Paralela Virtual).

24 24 Paralelización % 24 speed up codigo en serie 0% 5% % Cores Figura 1.3: Ley de Amdahl. POSIX Threads es un estándar de POSIX 5 para hilos de ejecución concurrentes. Las librerías que lo implementan suelen llamarse Pthreads, y normalmente se usan en sistemas UNIX, aunque también existen las implementaciones para Windows. OpenMP es más fácil de implementar que MPI pero suele ser menos eficiente. Como se trata de un sistema de memoria compartida, sólo pueden utilizarse los procesadores de 10 un único nodo. Así, para calcular el sumatorio de diez términos s = an (figura 1.4) podemos dividir el problema en dos sumatorios de cinco términos y mandarlo a dos procesadores que actúen de forma concurrente. La variable a es una constante que se encuentra almacenada en el mismo espacio de memoria al que acceden las dos ejecuciones concurrentes. La paralelización con MPI es más difícil de implementar pero ofrece un mejor rendimiento. Permite usar muchos nodos diferentes puesto que no se comparte el espacio de memoria. Para calcular el sumatorio anterior, tal como se muestra en la figura 1.5, todos los procesadores ejecutan una copia del programa, realizando comunicaciones periódicas para intercambiar resultados, y accediendo cada uno a su espacio de memoria para leer las distintas copias de la constante a. PVM es una librería para el cómputo paralelo en un sistema distribuido de computadoras. Está especialmente diseñado para permitir que una red de computadoras heterogénea 5 Portable Operating System Interface for unix (Interfaz de Sistema Operativo Portátil basado en UNIX). Persigue generalizar las interfaces de los sistemas operativos para que una misma aplicación pueda ejecutarse en distintas plataformas. N=1

25 Capítulo 1. Introducción 25 s= 10 N=1 an s1= 10 N=6 an s=s1+s s= an s1= N=6 N=1 Master an s=s1+s2 s2= 5 N=1 an 10 5 s= s2= an s=s1+s2 N=1 an N=1 Figura 1.4: División de tareas en OpenMP. Figura 1.5: División de tareas en MPI. comparta sus recursos de cómputo (como el procesador y la memoria RAM) para disminuir el tiempo de ejecución de un programa al distribuir la carga de trabajo en varias computadoras Supercomputación Para almacenar la gran cantidad de información necesaria para la investigación, procesarla y visualizarla, se precisa una gran potencia de cálculo. La supercomputación es la herramienta que proveerá de esa potencia de cálculo al proyecto de investigación. Existen gran variedad de tecnologías y configuraciones, y por tanto, más de una clasificación posible. La siguiente división es una de ellas: 1. Registros vectoriales. Esta tecnología, creada por Seymour Cray 6, permite la ejecución de muchas operaciones aritméticas en paralelo. Los procesadores vectoriales forman parte de los supercomputadores tradicionales, como la Cray MPP (Massively Parallel Processors, Procesadores Masivamente Paralelos). Consiste en la utilización de cientos o miles de microprocesadores estrechamente coordinados. Se trata de un único computador con múltiples CPUs comunicadas por un bus de datos. 3. Clústeres. Es una forma de computación distribuida en la que se utiliza un conjunto de orde- 6 Puede encontrarse una biografía en [Wika]. 7 Supercomputadora vectorial realizada por Cray Research, Inc. (CRI). Fue la computadora más veloz en el mundo cuando fue lanzada, remplazando a la X-MP (también de CRI) en ese puesto. Fue desplazada del primer puesto por la ETA-10G en Sólo realiza cálculos matemáticos muy complejos y operaciones lógicas de alto nivel.

26 26 Clúster de cálculo nadores de uso general interconectados por redes locales. Se verá más información sobre este tema en el apartado siguiente. La palabra clúster viene del inglés cluster, que significa literalmente racimo. 4. Grid. Es un nuevo modelo de computación distribuida en el cual todos los recursos de un número indeterminado de computadoras son englobados para ser tratados como un único superordenador de manera transparente. El término grid se refiere a una infraestructura que permite la integración y el uso colectivo de ordenadores de alto rendimiento, redes y bases de datos que son propiedad y están administrados por diferentes instituciones. Su propósito es facilitar la integración de recursos computacionales heterogéneos. A medida que el uso de Internet se extiende, proliferan los proyectos de computación distribuida en los que software especiales aprovechan el tiempo ocioso de ordenadores personales para realizar grandes tareas a bajo costo. Las tareas se dividen en bloques de cálculo independiente que no se comunicarán en varias horas. En esta categoría entran los proyectos BOINC 8, Folding@home 9, SETI@home 10 y PRIME 11. Una Supercomputadora, o Superordenador, es una computadora con capacidades de cálculo muy superiores a las disponibles en las máquinas de escritorio habituales [Wikc]. Por su alto costo, el uso de superordenadores está limitado. Los clústeres son la alternativa económica a las grandes supercomputadoras Clúster de cálculo En un clúster de cálculo muchas computadoras individuales interactúan entre sí como si de una sola máquina se tratase. Las tareas se dividen en tareas más pequeñas que llamaremos subtareas y que puedan realizarse de forma paralela en varios ordenadores, reduciendo el tiempo de cálculo necesario. 8 Berkeley Open Infrastructure for Network Computing (Infraestructura Abierta de Berkeley para la Computación en Red). Es una infraestructura para la computación distribuida, desarrollada originalmente para el proyecto SETI@home, pero que actualmente se utiliza para diversos campos como física, medicina nuclear o climatología. La intención de este proyecto es obtener una capacidad de computación enorme utilizando ordenadores personales. [BOI] 9 Proyecto de computación distribuida diseñado para realizar simulaciones por ordenador de plegamiento de proteínas. [FOL] 10 Se utilizan computadoras repartidos por de todo el planeta para buscar vida extraterrestre. [SET] 11 Proyecto destinado a la búsqueda de números primos. [PRI]

27 Capítulo 1. Introducción 27 Las aplicaciones paralelas escalables requieren buen rendimiento; redes de comunicaciones escalables, de baja latencia y que dispongan de gran ancho de banda; y acceso rápido a archivos Ventajas de un clúster de cálculo Los componentes comunes para PCs y redes han visto un gran avance, lo que ha hecho que un clúster sea un sistema muy atractivo para el procesamiento paralelo en cuanto a su relación coste/rendimiento. Podemos enumerar varias ventajas en su utilización: Utilizan hardware disponible en el mercado y de bajo coste. Su sistema de comunicación se basa en redes de área local rápidas. Son sistemas escalables, de manera que pueden ampliarse fácilmente. Además puede sustituirse fácilmente cada computador defectuoso sin afectar al grupo, lo cual hace que se gane en disponibilidad. Pueden utilizar software de libre distribución, abaratando aún más los costes Tipos de clústeres de cálculo En función de que cada computador del clúster esté o no exclusivamente dedicado a él, podemos clasificar los clústeres en Beowulf 12 (dedicado) y NOW 13 (no dedicado). Un sistema Beowulf agrupa varios nodos minimalistas 14 conectados placa a placa, que se dedican exclusivamente para tareas del clúster. En un sistema NOW, por el contrario, los equipos son computadores completos que pueden dedicarse a otras tareas distintas de las del clúster y que se comunican normalmente mediante un switch (conmutador) central. En base a sus características podemos clasificar los clústeres entre clústeres de alto rendimiento, de alta disponibilidad o de alta eficiencia. HPC - High Performance Cluster, Clúster de Alto Rendimiento. Son clústeres en los cuales se ejecutan tareas que requieren de gran capacidad computacional. 12 En 1994, Thomas Sterling y Don Becker trabajando en el CESDIS (Center of Excellence in Space Data and Information Sciences) bajo el patrocinio de ESS (Earth and Space Sciences), diseñaron un proyecto basado en clúster de Computación al que se llamó Beowulf. El prototipo inicial consistió en 16 procesadores DX4 conectados por red Ethernet a 10Mbps.[Beo]. 13 Network Of Workstations (Red de Estaciones de Trabajo). 14 Constan básicamente de la placa base, una CPU, memorias y dispositivos de comunicaciones.

28 28 Clúster de cálculo HAC - High Availability Cluster, Clúster de Alta Disponibilidad. Su objetivo es proveer disponibilidad y fiabilidad. Estos clústeres tratan de brindar la máxima disponibilidad de los servicios que ofrecen. La fiabilidad se provee mediante software que detecta fallos y permite recuperarse frente a los mismos, mientras que en hardware se evita tener un único punto de fallos. HTC - High Throughput Cluster, Clúster de Alta Eficiencia. Son clústeres cuyo objetivo de diseño es el ejecutar la mayor cantidad de tareas en el menor tiempo posible Funcionamiento y componentes En la estructura de un clúster de cálculo podemos diferenciar los siguientes componentes: Componentes hardware: Front-end, también llamado servidor de gestión. Desde el front-end se distribuyen las tareas y trabajos a los nodos del clúster. Debido a que todos los nodos de cálculo dependen de él para recibir trabajos es conveniente dotarle de una infraestructura de Alta Disponibilidad o utilizar elementos hardware redundantes. Nodos de computación. Red de interconexión. Se suele utilizar redes Ethernet Gigabit ya que presenta un coste muy competitivo. Componentes software, por regla general se utilizan herramientas de software libre: Sistema Operativo. El más utilizado es Linux, en sus distintas distribuciones. Herramientas para programación paralela. Incluye herramientas de desarrollo en distintos lenguajes, librerías para la paralelización como MPI y PVM de las que ya se ha hablado en la sección 1.2, etc. Software de gestión de colas, herramientas de administración y monitorización. Software específico de cálculo.

29 Capítulo 1. Introducción 29 A grandes rasgos el funcionamiento de un clúster de cálculo puede resumirse como sigue: 1. Un usuario se conecta al front-end y lanza un cálculo (trabajo). 2. El front-end envía el trabajo a los nodos de computación solicitados. 3. Los nodos ejecutan las operaciones y al terminar enviarán los resultados de nuevo al front-end. 4. El front-end se encarga de presentar el resultado final al usuario.

30 30 Clúster de cálculo

31 Capítulo 2 Antecedentes En este capítulo se describen los recursos para cálculo científico en la Universidad del País Vasco/Euskal Herriko Unibertsitatea (en adelante UPV/EHU), así como la problemática y la situación de partida que da lugar al proyecto Péndulo. Finalmente se hace un resumen del proyecto piloto Situación de partida Los investigadores utilizan cálculo científico para obtener la información, analizarla y visualizarla, y poder sacar las conclusiones oportunas. Los equipos de investigación y sus áreas de conocimiento son cada vez más amplios y requieren de una potencia de cálculo cada vez mayor. Esto hace que la demanda de recursos de cálculo computacional dentro de la universidad crezca de año en año. La UPV/EHU ofrece a sus investigadores la máquina de cálculo Arina [SGI] desde el año 2004, facturándose en función de su utilización. 1 Dada la creciente necesidad de cálculo de los investigadores, esta máquina ha tenido que ser ampliada en dos ocasiones. Tras la última ampliación de Arina durante diciembre de 2007, su configuración es la siguiente: 280 cores Itanium2. Dos servidores de gestión y compilación. 14 Nodos con cuatro cores (núcleos de procesamiento) y 28 nodos con ocho cores. 40 microprocesadores Opteron. Hay un servidor de gestión y compilación y cinco nodos de cálculo. Cada nodo tiene cuatro procesadores Opteron dual core. 1 La tarifa de utilización de los nodos de cálculo es de 0.06 euros por hora de cálculo y CPU utilizadas. No obstante, el acceso al servidor es gratuito, pudiendo ser utilizado para realizar compilaciones y otros trabajos previos a la ejecución del cálculo. 31

32 32 Situación de partida Figura 2.1: Máquina de cálculo Arina. Características de almacenamiento. Además de los discos locales de cada nodo se tiene un sistema de archivos global para cálculo HP-SFS de 4.7 TB de capacidad, de escritura y lectura paralela en discos y basado en tecnología Lustre. Red de comunicaciones. Los servidores de acceso están conectados a los nodos y entre ellos mediante una red Ethernet interna. Los nodos de cálculo se comunican a través de una red Infiniband. A pesar de estas ampliaciones, algunos grupos de investigación se han visto en la necesidad de adquirir y montar clústeres de uso privado o buscar recursos en otros clústeres como por ejemplo el MareNostrum del BSC (Barcelona Supercomputing Center). 2 Por otro lado, la universidad dispone de numerosas aulas informáticas docentes y de libre uso. Las aulas docentes son utilizadas para clases prácticas y están repartidas por 2 Recientemente se le ha concedido 6 años de cálculo en este clúster a uno de los usuarios de Arina, que ha consumido en un mes.

33 Capítulo 2. Antecedentes 33 Figura 2.2: Aula de campus, de libre uso para los alumnos. las distintas facultades. Las aulas de libre uso se ponen a disposición de los alumnos para que puedan realizar sus trabajos con las herramientas adecuadas, además de proporcionar acceso a Internet. Estas aulas son utilizadas únicamente en horario laboral, estando sus equipos apagados fuera de estas horas, fines de semana y periodos vacacionales. Por un lado la necesidad creciente de potencia de cálculo, y por otro lado, la existencia de recursos infrautilizados en la universidad dibujan la situación de partida que ha dado origen al proyecto Péndulo El proyecto piloto Péndulo A finales del año 2005 surge la idea de construir un clúster con los ordenadores de las aulas docentes y de libre uso a partir de lo que ya se había trabajado en otras universidades, como el proyecto clusterus [FSR + 02] y el proyecto de la Universidad Autónoma de Madrid financiado por el MCyT 3 [Gar03]. En un principio se hicieron algunos estudios con herramientas como ROCKS 4 y OS- 3 Ministerio de Ciencia y Tecnología. 4 Distribución Linux Open-Source que permite construir clústeres de forma sencilla, y que incluye herramientas de computación y monitorización [ROC].

34 34 El proyecto piloto Péndulo CAR 5 sobre Red Hat, pero ninguna de ellas se adaptaba bien a nuestros requerimientos: El front-end del clúster debía poder pertenecer a un dominio diferente de aquel al que pertenecen los ordenadores del aula de campus. El front-end sólo dispondría de una tarjeta de red. De manera que no se podría utilizar una como interfaz local, para los ordenadores del aula de campus, y otra como interfaz abierta a Internet. La configuración de la red existente no se puede modificar, ya que el aula debe seguir funcionando normalmente durante el día, como servicio al alumnado. Las direcciones IP de los equipos no son locales sino públicas. Se deben mantener dos sistemas operativos en el mismo disco, Windows para uso de alumnos y Linux para el funcionamiento del clúster. Ya que no se pudo encontrar ninguna herramienta preconfigurada que pudiera cumplir perfectamente todos los requisitos, se decidió instalar un sistema nuevo, configurar manualmente el conjunto de programas y utilidades necesario para cualquier arquitectura paralela y después particularizarla para satisfacer los requisitos específicos. Para el desarrollo del proyecto piloto se escogió el Aula de Campus, localizada en el edificio de la Biblioteca Central, en la que se dispone de 60 ordenadores y que es utilizada por los alumnos según el horario y calendario escolares. El resultado fue un clúster muy básico pero prometedor, cuya configuración puede verse en la sección 4.1 (página 39). Con este proyecto se pretendía estudiar la viabilidad de un clúster de cálculo científico a tiempo parcial. 5 Open Source Cluster Application Resources (OSCAR) es un conjunto de aplicaciones que facilita la creación de un clúster de alta disponibilidad tipo Beowulf (Ver apartado ). Funcionan sobre un sistema Linux previamente instalado. [OSC]

35 Capítulo 3 Objetivos y Requisitos del nuevo Péndulo El ánimo de este clúster es atender la necesidad de recursos de cálculo del que se hablaba en el apartado 2.1 (página 31), intentando dar una utilización más eficiente a los recursos de los que ya se dispone. Se tiene la intención de poder aprovechar los ordenadores de las aulas informáticas como nodos de cálculo durante el horario en que dichas aulas permanecen inactivas: noches, fines de semana, festivos y períodos vacacionales. De este modo se alterna entre uso docente y uso investigador del aula, lo que dio origen al nombre de Péndulo Condiciones de funcionamiento Las premisas que deben regir el funcionamiento de este clúster de investigación a tiempo parcial son las siguientes: 1. (R.1) Se pretende disponer de una arquitectura lo más parecida posible al clúster Arina. Esto ofrece dos ventajas: Por un lado, se puede aprovechar el conocimiento que se posee al tener este clúster ya funcionando. Por otro lado, los investigadores, usuarios finales de Péndulo, tendrán un sistema parecido al que ya conocen. 2. (R.2) Todo el software necesario (sistema operativo, compiladores, gestor de colas, etc.) deberá ser de uso gratuito, de acuerdo con el tipo de licencia normal en la comunidad académica. 35

36 36 Condiciones de funcionamiento Este software debe ser apropiado, esto es, utilizable por un amplio y significativo número de grupos de investigación. 3. (R.3) En todo momento, tanto en el periodo de desarrollo del clúster como en la explotación posterior, deben minimizarse las interferencias con la actividad normal del aula. (R.3.1) El uso y mantenimiento de las aulas deberá realizarse en coordinación con el resto de departamentos que hacen uso de ellas o las gestionan. Por ejemplo: coordinar los horarios habituales y los eventos especiales (cursos que ocupen las salas, etc.); coordinarse con el servicio de incidencias informáticas para los equipos que fallen; con los departamentos encargados de administrar servicios como el firewall institucional o la infraestructura de red. 4. (R.4) Las aulas deben quedar operativas en el horario requerido, evidente por ser éste su fin primario. A la hora establecida para el cierre del aula al público, los ordenadores se apagan automáticamente y vuelven a arrancar en una partición con sistema operativo Linux, bajo el cual funcionan las aplicaciones para cálculo. En horario próximo a la apertura de la sala al público, tiene lugar su apagado remoto y reinicio en la partición Windows en la que trabajan los alumnos. 5. (R.5) Debe haber un servidor accesible en todo momento a los investigadores, para que puedan trabajar con independencia de que los nodos de cálculo estén activos o no. Los usuarios podrán compilar sus propios programas y lanzar los trabajos que deseen en cualquier momento, independientemente de que los nodos estén o no en funcionamiento. El equipo que actúe de servidor o front-end debe estar disponible siempre, y se encargará de repartir los trabajos a realizar entre las distintas colas de trabajo. En dicho servidor se encolarán los trabajos que se vayan lanzando a cualquier hora, hasta que los equipos estén disponibles para ejecutarlos. Se deben establecer políticas de prioridad para evitar, por ejemplo, que un único usuario monopolice el uso del clúster. Puede ser necesario abrir procedimientos para la petición de nuevos programas que se necesiten, así como para solicitudes de nuevas cuentas de cálculo.

37 Capítulo 3. Objetivos y Requisitos del nuevo Péndulo Otros requerimientos A partir del estudio piloto ya realizado se plantearon los siguientes objetivos que deben cumplirse en el desarrollo del proyecto: 1. (R.6) Elegir un sistema operativo apropiado sobre el que se ejecutarán los programas. Deben evaluarse las compatibilidades con el software de cálculo que habitualmente usan los investigadores. En el proyecto piloto se ha usado Debian como sistema operativo, por considerarlo muy competitivo en entornos de escritorio. No obstante, las herramientas que utilizan los usuarios del clúster ARINA se distribuyen normalmente sólo para los sistemas operativos Red Hat y SuSE Linux. Queda patente entonces que el sistema operativo utilizado no era el más idóneo, por lo que será necesario evaluar las opciones y elegir la más apropiada. 2. (R.7) Ampliar el número de nodos incluyendo nuevas aulas. La intención es extender el proyecto al mayor número posible de aulas informáticas. Considerando el problema escalable, el objetivo primario es montar dos aulas con sus respectivas configuraciones y horarios de funcionamiento particulares. A partir de ahí, añadir nuevas aulas no debe suponer ningún problema. 3. (R.8) Estudiar la viabilidad de integrar elementos heterogéneos. El proyecto se desarrollará manteniendo, al menos de forma temporal, la sala del estudio piloto que, como ya se ha dicho, funciona bajo el sistema operativo Debian. Con esto se pretende estudiar la viabilidad de integrar elementos heterogéneos. Este estudio podría ser interesante en el caso de querer obtener, por ejemplo, soporte técnico de terceros en el equipo que actúe a modo de servidor del clúster. De este modo, instalando el sistema operativo Red Hat en el servidor puede obtenerse este soporte, sin tener que asumir el gasto de instalar un sistema operativo de pago en todos los nodos de ejecución. 4. (R.9) Su mantenimiento debe ser mínimo.

38 38 Otros requerimientos Todas las acciones deben estar automatizadas y deberán poder hacerse de manera remota. Así por ejemplo: (R.9.1) los equipos deben encenderse y apagarse automáticamente al llegar la hora; (R.9.2) las actualizaciones del sistema operativo, librerías y nuevas versiones de compiladores y programas deberán poder realizarse en todos los nodos a la vez, mediante un conjunto mínimo de comandos; (R.9.3) otras tareas de mantenimiento, como por ejemplo la creación de cuentas de usuario, deben poder realizarse automáticamente y de forma que afecte a todos los nodos implicados.

39 Capítulo 4 Desarrollo del proyecto Este capítulo explicará el proceso seguido para llegar desde la configuración inicial del aula piloto hasta la situación actual. Se expondrán los cambios realizados siguiendo la cronología real en que se han llevado a cabo, para acabar con una relación de problemas surgidos. El apartado 4.8 expone los detalles adicionales sobre cómo se ha llevado a cabo la implementación de las distintas áreas y fases del desarrollo Configuración inicial El proyecto piloto tenía una configuración muy básica que se muestra en la figura 4.1 consistente en: 60 ordenadores con 1 procesador, 512MB de memoria RAM, discos duros de 40 u 80 GB. La velocidad del procesador es diferente según los casos: 23 equipos a 2.6 GHz, con 40 GB de disco duro. 30 equipos a 2.8 GHz, con 80 GB de disco duro. 7 equipos a 3.0 GHz, con 40 GB de disco duro. Servidor: equipo de sobremesa con las mismas características de hardware que los nodos. Dos configuraciones: Windows, para el uso por parte de los alumnos. Linux Debian Sarge, para su uso computacional. 39

40 40 Configuración inicial Disco local (NFS) Unidad virtual exportado desde el servidor /home 30 GB /software RAM 512 MB 1 cpu Conexion ethernet 100 Mbps servidor pendulo llpa01 - llpa30 (30 ordenadores) llpa31 - llpa60 (30 ordenadores) RAM 512M /home 30G RAM 512M /home 30G /scratch 15GB /software /scratch 55GB /software 1 cpu 1 cpu Figura 4.1: Configuración del aula piloto.

41 Capítulo 4. Desarrollo del proyecto 41 Los equipos exportan los directorios /home y /software desde su servidor mediante tecnología NFS (Network File System, Sistema de archivos de red). NFS es un protocolo de nivel de aplicación, según el Modelo OSI 1. Es utilizado para sistemas de archivos distribuidos en un entorno de red de computadoras de área local. Posibilita que distintos sistemas conectados a una misma red accedan a ficheros remotos como si se tratara de locales. El objetivo es que sea independiente de la máquina, el sistema operativo y el protocolo de transporte. Por defecto está incluido en los Sistemas Operativos UNIX y las distribuciones Linux. Se dedica una partición en cada nodo de 15 o 55 GB, en función del tamaño del disco, para almacenar cálculos intermedios. Esta partición se llama scratch 2. El servidor gestionaba los cálculos (trabajos) de los usuarios y el reparto de los trabajos a los diferentes nodos mediante la herramienta gratuita N1GE de SUN, que funciona como gestor de colas para los cálculos. Los equipos de los que se disponía no eran todos iguales entre sí en cuanto a velocidad de procesador y se encontraban conectados a switches (conmutadores) diferentes. Con el fin de maximizar el rendimiento de los nodos, éstos se dividieron en grupos (colas) de trabajo de acuerdo con los siguientes criterios, tal y como se muestra en la figura 4.2: Todos los equipos de una cola deben tener la misma velocidad de procesador. De esta manera se evita que haya nodos más rápidos que tengan que esperar a que un nodo más lento termine su tarea, para poder continuar con la ejecución del trabajo. Todos los nodos de una cola deben conectarse al mismo switch. Así, los nodos no pierden tiempo para comunicarse entre sí porque la comunicación es más directa, viéndose mejorada la velocidad de los cálculos paralelos. En la sección se exponen los resultados de las pruebas realizadas para medir la pérdida de velocidad al comunicar nodos de distintos switches. Esta configuración inicial tenía varios problemas: El Sistema Operativo elegido para el Aula Piloto (Debian Sarge) nos daba problemas al no ser el más común en entornos de cálculo. 1 Open System Interconnection (modelo de referencia de Interconexión de Sistemas Abiertos). Modelo de red descriptivo creado por ISO. 2 El término scratch, viene del inglés y se utiliza con el sentido de algo inacabado o temporal. Por ejemplo, scratch paper quiere decir papel de borrador.

42 42 Configuración inicial Figura 4.2: Distribución por switches.

43 Capítulo 4. Desarrollo del proyecto 43 El software debía instalarse de manera local en todos los nodos, lo cual hacía que el mantenimiento fuera complicado. Un gestor de colas distinto al de Arina, por ser gratuito. Esto derivaba en una mayor complicación para los usuarios. Los directorios personales de los usuarios eran diferentes a los que ya tenían en Arina. Pocas aplicaciones. Los programas se instalaban bajo demanda de los usuarios, lo cual hacía que no siempre estuvieran disponibles en el momento en el que los necesitaban. Las cuentas de usuario debían crearse localmente en todos los nodos. Esto incrementa mucho el tiempo y la complicación de crear las cuentas, ya que los nodos no están disponibles cuando se crea la cuenta, y no siempre se encienden todos los nodos. El proyecto piloto ya no existe puesto que los ordenadores originales de Péndulo han sido retirados por el CAU 3. En su lugar se han puesto nuevos ordenadores de un modelo mucho más potente 4. Según la política adoptada por la UPV/EHU, el cambio de equipos en las aulas puede realizarse cada tres años. Muy rara vez se hará antes, ya que mientras los equipos se encuentren en garantía se arreglarán o se sustituirán por otros del mismo modelo. En ocasiones, y según la necesidad, pueden durar 5 o más años Nuevo Sistema Operativo El primer paso fue elegir un nuevo Sistema Operativo. Los paquetes de software y librerías de cálculo no suelen construirse para Debian, por lo que nos veíamos obligados a recompilar estos paquetes, incrementando el mantenimiento del sistema, las incompatibilidades y los conflictos entre los programas. Una opción barajada para el nuevo S.O. fue Red Hat Linux, ya que la UPV/EHU tiene un contrato con la empresa para proveer a los equipos de explotación con dicho S.O., 3 El CAU (Centro de Atención a Usuarios) es una sección del CIDIR (Centro de Informática de Docencia, Investigación y Red). El CAU se encarga entre otras cosas de mantener los equipos informáticos de los centros y facultades de la UPV/EHU. 4 Se trata de equipos DELL OPTIPLEX 745, con procesadores Intel Core2 a 2.13 GHz, con arquitectura de 64 bits. Disponen de 1GB de memoria RAM y 80GB de disco duro.

44 44 Sistema de almacenamiento global y ofrece además mantenimiento. No obstante, finalmente nos decantamos por opensuse Linux en su versión 10 [SUS]. La razón fundamental de esta decisión es que este S.O. además de ser bastante habitual en entornos de cálculo, es de libre distribución. Péndulo es un proyecto de bajo costo y no se pretende una alta fiabilidad. De hecho se asume que varios equipos actuando como nodos puedan fallar en un momento dado sin mayores consecuencias ya que existen nodos de sobra. Se prepararon los equipos del Aula de Cursos (5 a planta del edificio de la Biblioteca) con opensuse Linux 10.1 y se estableció la misma configuración que en el aula piloto. Los ordenadores de esta nueva aula son más potentes y los trabajos consiguen mejores tiempos 5. En esta decisión también ha influido el hecho de que gran parte de los usuarios de Arina (y potenciales usuarios de Péndulo) usan el programa de química GAUSSIAN, que necesita las librerías LINDA para paralelizar los cálculos. Estas librerías no estaban disponibles en el momento de tomar la decisión para la versión de Red Hat de la que la UPV/EHU tiene licencia. Hasta la desaparición del Aula piloto en junio del pasado año, ambas aulas con sendos sistemas operativos han convivido de manera satisfactoria con el servidor antiguo (lgpxrs.lgp.ehu.es), cuyo S.O es también Debian Sarge. (Ver figura 4.3) 4.3. Sistema de almacenamiento global Para almacenar resultados intermedios de los cálculos se utiliza la carpeta scratch en cada nodo, como ya se explicó en la sección 4.1, pero este sistema no sirve cuando en los cálculos paralelos desde varios nodos debe accederse a esa información (memoria compartida). El scratch global es un espacio de disco compartido por varios ordenadores agrupados en una cola. Lo utilizan para almacenar resultados intermedios de sus cálculos y así poder comunicarse de manera más eficiente. Antes de emplear este sistema, los archivos temporales compartidos por varios nodos debían almacenarse en el directorio personal del usuario en el servidor cuya conexión a través de la red es mucho menos directa y más lenta. Para implementar el scratch global, se utiliza uno de los ordenadores por cada cola. Dichos ordenadores no se utilizan como nodos de cálculo sino que se dedican exclusivamente a almacenar los ficheros necesarios (servidores de scratch). Para evitar fallos puntuales en los servidores de scratch, cualquier ordenador puede actuar como servidor 5 En la sección se puede ver un análisis del rendimiento de los ordenadores de estas aulas.

45 Capítulo 4. Desarrollo del proyecto 45 Figura 4.3: Adición del aula de cursos. Convivencia entre distintos S.O.

46 46 Sistema de almacenamiento global Figura 4.4: Sistema de almacenamiento global. cuando detecta que ningún servidor está disponible. Los ordenadores del Aula de Campus tenían discos duros de diferente tamaño (40 GB y 80 GB). Sin embargo, los ordenadores utilizados como servidores de scratch eran siempre ordenadores con discos grandes. De esta forma, la configuración hasta la desaparición del Aula de Campus ha sido la mostrada en la figura 4.4. El funcionamiento del sistema de almacenamiento global es el que se detalla a continuación: Cuando un nodo arranca realiza las siguientes acciones: 1. Comprueba si existe un servidor de scratch disponible para su cola. 2. Si lo hay, monta el directorio scratch del servidor mediante NFS con nombre gscratch (global scratch) y será el mismo lugar físico para todos los nodos de

47 Capítulo 4. Desarrollo del proyecto 47 la cola. 3. Si no existe aún un servidor, el nodo se auto-elige como el nuevo servidor de scratch y se deshabilita en el sistema de colas, de manera que no se puedan ejecutar cálculos en él. El script 6 que permite realizar estas acciones se incluye en el listado B.15 en la página 138. Cuando un nodo se apaga realiza las siguientes acciones: 1. Comprueba qué nodo actúa de servidor de scratch para su cola. 2. Si es él mismo, espera un tiempo extra a que terminen de apagarse el resto de nodos 7 y vuelve a habilitarse en el sistema de colas para la siguiente ocasión. 3. Si no es él, desmonta el directorio gscratch y continúa con sus operaciones de apagado. El código incluido en el listado B.17 en la página 141, es el encargado de realizar estas acciones Nuevo Servidor y conexión a la cola de pruebas El nuevo servidor para Péndulo es un Power Edge 1750 de la marca DELL con 4 CPUs Intel Xeon 2 8 GHz. Dicho equipo es un servidor retirado de la Facultad de Ciencias Económicas y Empresariales de Bilbao en la que era utilizado como servidor de autenticación de aulas. Dicho servidor se ha preparado con opensuse Linux En un primer momento, se conectó únicamente a Arina y a una cola de pruebas para ir construyendo la nueva configuración de manera segura. Esta configuración se muestra en la figura 4.5 y se describe a continuación. La idea es que los usuarios puedan lanzar sus trabajos a las colas de Arina o las de Péndulo de manera equivalente. La manera de lograrlo es la siguiente: El servidor de cálculo Arina exporta su directorio home al servidor de Péndulo mediante una conexión Gigabit. 6 Un script es un fichero de texto que contiene una secuencia de instrucciones que el intérprete de comandos del sistema operativo ejecuta una a una. 7 Lo normal es que se apaguen todos los nodos a la vez.

48 48 Nuevo Servidor y conexión a la cola de pruebas Figura 4.5: Nuevo Servidor y cola de pruebas.

49 Capítulo 4. Desarrollo del proyecto 49 Figura 4.6: Recorrido de datos de un cálculo para su ejecución. Cuando el usuario lanza un cálculo (trabajo) desde Arina destinada a una cola de Péndulo, la información necesaria se copia del directorio home a queue_scratch que está disponible en todos los nodos como el nuevo directorio home. Al terminar el trabajo, los resultados vuelven a copiarse de queue_scratch al home de Arina. Este funcionamiento se muestra en la figura 4.6. Las líneas naranjas muestran el recorrido de los datos cuando se lanza el script; y las líneas verdes el recorrido al terminar el trabajo. Cuando la línea es discontinua no hay realmente movimiento de ficheros sino que indica que están disponibles en ambos sitios mediante NFS. Esto es un primer paso hacia una integración transparente de Péndulo con Arina. Las

50 50 Nuevo Servidor y conexión a la cola de pruebas ventajas para el usuario son claras: dispone de un único punto de acceso para todos los recursos Nuevo gestor de colas Inicialmente Arina utilizaba el gestor de colas PBS Pro, que es un paquete software de pago. Ya que Péndulo es un proyecto de bajo costo, era necesario un sistema de colas gratuito, y por ello el gestor de colas utilizado en el antiguo servidor del proyecto piloto era N1 SGE de Sun, de uso libre. Esta diversidad de gestores se traducía en una mayor complicación de uso para los usuarios y dificultaba enormemente la pretendida integración transparente con Arina, de la que se habla en el apartado 3.1, página 35. Actualmente, Arina utiliza el gestor Torque que también es de uso libre, y por tanto, este es el gestor de colas que se ha implantado en el nuevo servidor Péndulo. En la sección se comentará algo sobre el funcionamiento de las colas Autentificación de usuarios mediante LDAP Una de las mejoras más notables ha sido la implantación de la autentificación de usuarios remota mediante un servidor LDAP 8. El servidor simplifica en gran medida la creación de nuevas cuentas de usuario, al eliminar la necesidad de crear cuentas locales en todos los nodos. Las cuentas son creadas en el servidor y cada vez que los procesos de usuario deben conectarse a los nodos, se validan contra el servidor LDAP. La puesta en marcha de este servidor sirve de precedente y pruebas para una futura mejora potencial en el sistema de autentificación de usuarios en Arina, que todavía se hace de manera local. En la sección se verán más detalles sobre la gestión de cuentas de usuario. En el proceso de puesta en marcha de la autentificación de usuarios mediante LDAP se han seguido los siguientes pasos: 1. Instalación en el servidor: Instalar servidor openldap [OPEa]. Implementar seguridad para el tráfico de LDAP: Todo el tráfico de LDAP va en plano por la red, lo que puede ser un riesgo de seguridad. La solución es 8 Lightweight Data Access Protocol

51 Capítulo 4. Desarrollo del proyecto 51 configurar los clientes y servidores para que establezcan una conexión segura vía TLS/SSL 9. El servidor necesita un certificado, que generamos mediante la orden siguiente: openssl req -new -newkey rsa:1024 -days 365 -nodes -x509 -keyout lgua02.pem -out lgua02.pem 2. Incluir los datos de usuarios en el directorio LDAP. Para ello se ha utilizado la herramienta Migration tools [MTO]. Esta herramienta lo componen una serie de scripts programados en lenguaje perl que extraen la información existente en los ficheros de configuración del sistema operativo (por ejemplo /etc/passwd) creando ficheros en formato LDIF 10. Los datos de los ficheros LDIF creados se han incluido en el directorio LDAP mediante el comando ldapadd. 3. Instalación en los nodos: Instalar los paquetes yast2_ldap_client, openldap2_client, pam_ldap y nss_ldap Configurar el ClienteLDAP en yast 11 dentro del apartado Servicios de red con las siguientes opciones: Autenticación de usuarios: Usar LDAP. Direcciones de servidores LDAP: IP del servidor DN base de LDAP: dc=lgp,dc=ehu,dc=es Obtenido mediante la opción Obtener DN Opción LDAP TLS/SSL activada. Opción LDAP Versión 2 desactivada. Comprobar que existe una línea con la cadena +::: en los ficheros passwd y group del directorio /etc/ del nodo. Esta es la forma de decirle al sistema que utilice validación vía LDAP. 4. Instalación de otras herramientas en modo gráfico para la gestión del servidor LDAP: Luma 9 Transport Layer Security/Secure Sockets Layer 10 LDAP Data Interchange Format 11 Gestor de paquetes y configuración en SuSE.

52 52 Conexión del aula de cursos Disco local (NFS) Unidad virtual exportado desde el servidor (NFS) Unidad virtual exportado desde otro nodo /home 30 GB /software RAM 512 MB 1 cpu S.O. Debian Sarge RAM 1 GB 4 cpu /home (lgua00) /software /queue_scratch Conexión ethernet 1 Gbps /home 268 GB Conexion ethernet 100 Mbps servidor pendulo Conexión ethernet 100 Mbps S.O. SuSE Linux nuevo servidor péndulo (lgua02) servidor arina (lgua00) /queue_scratch /home /scratch 55G /software Aula de campus (60 ordenadores) Aula de cursos (20 ordenadores) 1-2 cpu /gscratch 55G RAM 512M /home 30G RAM 512M /home 30G Cola pruebas (2 ordenadores) S.O. SuSE Linux /scratch 15-55G /software /scratch 55G /software 1 cpu S.O. Debian Sarge 1 cpu S.O. SuSE Linux Figura 4.7: Conexión del aula de cursos mientras los servidores de Péndulo nuevo y viejos conviven. JXplorer Para cada usuario y grupo se guarda la información de acceso (nombre de usuario y contraseña) junto con otros datos de relevancia Conexión del aula de cursos Una vez probada que la nueva configuración funciona correctamente, se procede a conectar el aula de cursos al nuevo servidor. Se ha creado una nueva cola dentro del gestor de colas, y han sido necesarias algunas modificaciones para que dicha aula pueda ser utilizada igualmente por el nuevo servidor (lgua02) y el antiguo (lgpxrs), hasta que se den por terminadas las pruebas en el nuevo Péndulo. La figura 4.7 muestra esta configuración Desaparición del aula de campus original Como ya se ha comentado antes, los ordenadores del aula piloto han sido retirados por el CAU, y se han sustituido por otros más potentes. Se ha creado una imagen nueva

53 Capítulo 4. Desarrollo del proyecto 53 Disco local (NFS) Unidad virtual exportado desde el servidor (NFS) Unidad virtual exportado desde otro nodo /home RAM 30 GB 512 MB 1 cpu /software S.O. Debian Sarge RAM /home 1 GB (lgua00) 4 cpu /software /queue_scratch Conexión ethernet 1 Gbps /home 268 GB Conexion ethernet 100 Mbps servidor pendulo Conexión ethernet 100 Mbps S.O. SuSE Linux nuevo servidor péndulo (lgua02) servidor arina (lgua00) /queue_scratch /home /scratch 55G /software Aula de campus (60 ordenadores) Aula de cursos (20 ordenadores) 1-2 cpu /gscratch 55G RAM 512M /scratch 15-55G /home 30G /software RAM 512M /scratch 55G /home 30G /software Cola pruebas (2 ordenadores) S.O. SuSE Linux Nuevo Aula de campus (60 ordenadores) 2 cpu RAM 1 cpu S.O. Debian Sarge 1 cpu S.O. SuSE Linux 1GB Figura 4.8: Configuración actual de Péndulo. para este modelo, y se han clonado los nuevos equipos del aula utilizando un servidor de imágenes y arranque remoto Rembo 12. De esta manera, el nuevo Aula de Campus queda integrada en el nuevo servidor y el gestor de colas, siendo la configuración actual, tal y como se muestra en la figura 4.8. Las características actuales de los nodos del clúster son las siguientes: Aula de cursos: 20 ordenadores con 1 cpu, 1GB Memoria RAM, discos duros de 80GB. Aula de campus: 60 ordenadores con 2 cpu, 1 GB Memoria RAM, discos duros de 80GB. Cuando quede probada la funcionalidad del clúster, se eliminará también el servidor antiguo. Los nodos del nuevo aula de campus se han dividido en cuatro grupos (campus1, campus2, campus3 y campus4) en función del switch al que están conectados, con objeto de minimizar los retardos 13. Cada grupo constituye una cola de ejecución, de manera que 12 Más información sobre Rembo en la sección Los nodos pierden menos tiempo para comunicarse entre sí porque la comunicación es más directa, viéndose mejorada la velocidad de los cálculos paralelos. En la sección se exponen los resultados de las pruebas realizadas para medir esa pérdida de velocidad al comunicar nodos de distintos switches.

54 54 Problemas encontrados los trabajos lanzados en paralelo se ejecutarán dentro de una misma cola, y por tanto, utilizando un mismo switch (Ver sección 4.8.2). Para la implementación del sistema de almacenamiento global del que se habló en la sección 4.3, se ha decidido utilizar dos nodos como servidores de scratch: uno para los equipos de los grupos campus1 y campus3, y el otro para los otros dos grupos. Se utilizan sólo dos nodos en lugar de cuatro a raíz de los resultados obtenidos en las pruebas de la sección Problemas encontrados Durante el desarrollo del proyecto han surgido diversas dificultades de tipo logístico, de coordinación interdepartamental, informático, etc. a las que ha habido que hacer frente Coordinación entre departamentos Dado que las aulas utilizadas para la construcción de Péndulo no están enteramente dedicadas al proyecto, su funcionamiento se ve en ocasiones alterado por otros eventos de mayor prioridad. Esto nos obliga a mantener una estrecha relación con otros departamentos de la UPV/EHU con objeto de coordinar nuestras actividades de la manera más satisfactoria para todos. Así por ejemplo, en los meses de septiembre y octubre las aulas se dedican a la matriculación de alumnos. Dado que se considera algo crítico, durante ese tiempo los ordenadores no funcionan como nodos del clúster por la noche, con objeto de minimizar posibles fallos e interferencias. También es posible que desde el departamento informático se realicen tareas de mantenimiento en las aulas y durante algún tiempo no estén disponibles los ordenadores para su uso por parte del clúster. Otro ejemplo de esta necesidad de coordinación lo constituye el hecho de que durante los periodos vacacionales se cortaba tradicionalmente la corriente al edificio de la Biblioteca Central. En dicho edificio se encuentran las aulas que conforman el clúster Péndulo, y la falta de corriente hacía, por supuesto, que éste no estuviera operativo. Para preparar el modelo de equipo existente en el Aula de Cursos no disponíamos de ordenadores de prueba y fue necesario utilizar los equipos del propio aula. Cuando el aula se utiliza para su fin primario (el de impartir cursos) no se puede trabajar sobre esos equipos. En ocasiones esos cursos duran semanas enteras y otras veces surgen de manera

55 Capítulo 4. Desarrollo del proyecto 55 imprevista, lo que obliga a cambiar el plan de trabajo de un día para otro. En este sentido, la solución empleada para el nuevo Aula de Campus fue conseguir un ordenador de pruebas del mismo modelo sobre el que ir preparando la nueva imagen Clonación de equipos SuSE Linux Al clonar un equipo con sistema operativo SuSE Linux en otro 14 nos encontramos con un problema. SuSE puede detectar que la dirección MAC de la tarjeta de red es distinta, pero al tener guardada la configuración de la tarjeta de red anterior es incapaz de arrancar de manera satisfactoria las aplicaciones de red. La solución a este problema pasa por realizar lo siguiente: 1. Cambiar el nombre del fichero ifcfg-eth-id-mac localizado en el directorio /etc/sysconfig/network/ (donde en lugar de la cadena MAC aparece su identificador) por el nombre ifcfg-eth0. 2. Borrar el fichero /etc/udev/rules.d/30-net_persistent_names.rules o la línea en la que se define la configuración del equipo anterior dentro de ese fichero. En el segundo paso, resulta más fácil borrar el fichero que sólo la línea. Puesto que este fichero se crea cada vez que arranca el equipo, es necesario borrarlo siempre para evitar que pueda fallar en futuras clonaciones. Para ello se ha creado un script de arranque (confignet) cuyo código puede examinarse en el listado B.13 en la página 135. Se dan más detalles sobre los scripts de arranque para Linux en el apartado 4.8.5, pero básicamente es un fragmento de código que el equipo ejecuta siempre al arrancar o al apagarse, según los casos. En este caso, los equipos ejecutan el script confignet sólo al arrancar para borrar el fichero /etc/udev/rules.d/30-net_persistent_names.rules del que ya habíamos hablado Caracteres en la terminal de log in Los ordenadores deben estar disponibles para los alumnos (u otros usuarios) a una hora determinada de la mañana. Para ello se lanza un shutdown de manera remota para que terminen su funcionamiento en Linux y puedan encenderse de nuevo en Windows. Pero en ocasiones los equipos no se apagaban correctamente y seguían funcionando en Linux. Esto constituía una intromisión en el funcionamiento normal del aula lo que 14 Para clonar los equipos se utiliza un servidor REMBO, del que se hablará en la sección 4.8.1

56 56 Problemas encontrados hacía incumplir uno de los objetivos prioritarios enumerados en la sección 3.1: deben minimizarse las interferencias con la actividad normal del aula. Cuando un ordenador arranca en Linux, y tras cargar el sistema operativo, se pide un usuario y contraseña en lo que llamaremos terminal de log in 15. En los ordenadores que no se apagaban se pudo observar una característica : tenían caracteres escritos en su terminal de log in. Dado que resulta imposible controlar la gente que puede pasar por las aulas fuera de su horario de apertura (personal de limpieza, de seguridad, conserjes, etc.) lo adecuado es no permitir que entren caracteres en dicha terminal. La forma de solucionarlo fue comentar en el fichero /etc/inittab la siguiente línea: 1:2345:respawn:/sbin/mingetty --noclear tty1 Esto hace que la terminal tty1, que es la que aparece por defecto se desactive y no acepte caracteres por la entrada estándar. En su defecto habrá que utilizar las terminales tty2 y siguientes para entrar a un nodo concreto Otros problemas El desarrollo de un proyecto tan complejo tiene diversos puntos de fallo que hay que controlar. Algunos de los problemas que han ocurrido tienen su origen en la instalación de programas no específicamente desarrollados para la arquitectura y sistema operativo que nos atañe. A continuación se enumeran algunos de los variados problemas que se han ido solucionando a medida que iban surgiendo. Problemas con el scratch global Se detectó un problema en el sistema de almacenamiento global. Los nodos que actúan de servidor de scratch global escriben su nombre en el fichero correspondiente a la cola a la que van a exportar el equipo. El origen del problema era que cuando un servidor de scratch global deja de funcionar o no se apaga correctamente no borraba su nombre de esos ficheros. De manera que al día siguiente, los nodo intentaban montar de nuevo el scratch global desde el equipo que había dejado de funcionar, y como no respondía se quedaban indefinidamente esperando. Para evitar este problema se han propuesto dos medidas: 15 En inglés, to log in significa entrar en un ordenador.

57 Capítulo 4. Desarrollo del proyecto 57 Solución 1: Borrar los ficheros con los nombres diariamente para que los equipos no intenten montar un disco que no está disponible. Esta medida se ha realizado mediante un cron o tarea programada (Ver sección para más información sobre tareas programadas). Solución 2: Establecer un timeout o cuenta atrás para que cuando un equipo espera más del tiempo establecido a que responda el servidor de scratch global, el equipo borre el nombre de ese servidor y se ponga a él mismo como nuevo servidor de scratch global. Esta medida está aún pendiente de implementar. Logs excesivos de LDAP Uno de los problemas que surgió al implantar LDAP es que se creaban demasiados logs (registros) y llegó a llenarse el disco duro (partición /). Como resultado el sistema no funcionaba correctamente. Los pasos seguidos para solucionarlo fueron los siguientes: 1. En el fichero /etc/ldap/slapd.conf cambiamos loglevel a 8. Al principio no se podía escribir porque el disco duro estaba al 100 %. Por eso antes hubo que vaciar los logs del sistema: # :>/var/log/syslog 2. Editamos el fichero /etc/syslog.conf, añadiendo la siguiente línea al final: local4.* /var/lob/ldap.log:wq 3. Reiniciar syslog. 4. Reiniciar ldap. Problemas con el firewall corporativo En las pruebas realizadas en el Aula de Cursos se detectaron problemas con las librerías de paralelización MPICH. Encontramos que también existían ciertos problemas con rsh 16. Tras estudiar la situación se consiguió por fin averiguar que la causa de los problemas estaban causados por el firewall corporativo de la UPV/EHU que no permitía cierto tráfico necesario para el clúster entre nodos y servidor. Se informó del problema al departamento de Redes del CIDIR, que se encargó de solucionarlo. 16 Remote shell, para ejecutar comandos en ordenadores remotos. Las comunicaciones durante un cálculo no es necesario cifrarlas.

58 58 Gestión del clúster Proceso que ocupa el 100 % de la CPU El proceso update-status ocupaba de vez en cuando el 100 % de la CPU en los nodos. Dicho proceso tiene que ver con las actualizaciones del sistema operativo. Sin embargo, no nos interesa que esté ocupando las CPUs. La solución fue desactivarlo mediante la orden siguiente: # chkconfig novell-zmd off 4.8. Gestión del clúster Arranque Dual Citando lo que ya se ha dicho anteriormente, la convivencia entre clúster y aulas docentes debe regirse por lo siguiente: A la hora establecida para el cierre del aula al público, los ordenadores se apagan automáticamente y vuelven a arrancar en una partición con sistema operativo Linux, bajo el cual funcionan las aplicaciones para cálculo. En horario próximo a la apertura de la sala al público, tiene lugar su apagado remoto y reinicio en la partición Windows en la que trabajan los alumnos. Los ordenadores arrancan en el sistema adecuado sirviéndose de un servidor REMBO 17 La configuración y mantenimiento de este tipo de servidores es complejo. Para la gestión de imágenes y equipos se programan scripts en una variante del lenguaje C, llamado Rembo-C, utilizando una API 18 propia que contiene funciones específicas para manejar el arranque remoto y la creación de imágenes. Los nodos serán despertados en Linux mediante la herramienta etherwake [ETH], que hace uso de las MAC de los equipos para despertarlos. Es necesario que los equipos tengan activado Wake on LAN. Para ello, en la configuración de la BIOS, se cambia la opción Remote Booting a On. Dado que la opción por defecto es Off, hubo que cambiar manualmente todos los equipos uno a uno. Inicialmente se crearon scripts para gestionar este funcionamiento dual pero actualmente, y a partir de los scripts creados, el CAU se encarga de la gestión y mantenimiento del actual servidor REMBO. 17 REMote BOoting, Arranque Remoto. Actualmente el software ha sido adquirido por IBM [IBM], que lo ha integrado en otro producto llamado IBM Tivoli software portfolio [TIV]. Puede encontrarse un manual sobre el antiguo REMBO en [REM]. 18 Application Programming Interface, Interfaz de Programación de Aplicaciones.

59 Capítulo 4. Desarrollo del proyecto 59 Dentro de un servidor REMBO, existe una lista de los equipos a los que debe prestar servicio. Estos equipos están divididos en grupos según el modelo o características especiales del grupo. Los grupos que nos atañen son dos, uno por cada aula que actualmente está operativa para el clúster: Aula_Cursos_Dell y Aula_Campus_Dell. La página principal con el que arrancan los ordenadores de ambos grupos se ha llamado arranquedell.shtml el cual se muestra en el listado B.1 (página 127). Esta página de inicio se muestra durante 10 segundos esperando a que el usuario interaccione mediante los botones que muestra. En caso de que no se lleve a cabo ninguna acción en el transcurso de esos 10 segundos, el script evaluará la hora del sistema, y en función de esta hora ejecutará uno de estos dos scripts: arranquen ormaldell (Listado B.2, página 129) Por el día, de 8:45 a 19:30, arrancará la partición Windows para el uso de los alumnos. arranquelinux (Listado B.3, página 130) Por la noche, de 19:30 a 8:45, arrancará la partición Linux para el funcionamiento del clúster. La página de inicio arranquedell.shtml contiene dos botones: 1. Arranque para alumnos: Ejecuta el script arranquenormaldell mencionado anteriormente, que arranca Windows de la forma habitual. 2. Administrar: Al pulsar sobre este botón, se ejecuta el script menu_admin cuyo código se muestra en el listado B.4 (página 130). Esta parte debe estar protegida bajo contraseña, lo que conseguimos utilizando la función Logon() de la API de REMBO, que pide un usuario y contraseña válidos en el servidor. Si la validación del usuario es correcta se ejecuta el script administrar (Listado B.5) que abre otra ventana con varias acciones: Arranque Linux: ejecuta el script arranquelinux ya mencionado. Resulta útil cuando se quiere arrancar un equipo determinado en Linux fuera del horario nocturno. Restaurar Linux (Listado B.6, página 131): restaura la partición Linux del disco duro con la imagen que está cargada en el servidor Rembo para el tipo de equipos que lo ha solicitado. Para que funcione puede ser necesario ejecutar antes el script para Partir el disco.

60 60 Gestión del clúster Restaurar Windows: restaura la partición Windows, según la imagen cargada en el servidor Rembo. Su código se muestra en el listado B.7 (página 131). Al igual que en el caso anterior, puede ser necesario ejecutar antes el script para Partir el disco. Crear imagen Linux (Listado B.8, página 131): crea una imagen de la partición Linux, para cargarla en el servidor Rembo y poder utilizarla posteriormente para clonar otros equipos. Crear imagen Windows (Listado B.9, página partición Windows para cargarla y clonarla posteriormente. 132): Crea una imagen de la Partir disco: Crea las particiones del disco, para poder clonar después cada partición Windows y Linux por separado. Deberá ejecutarse antes de restaurar por primera vez cualquier imagen en un disco. Su código lo ejecuta el script crear_p articiones que se muestra en el listado B.10 de la página 132. En la sección B.1 se muestran los scripts ya citados, programados con objeto de gestionar el arranque dual Gestión de colas Los nodos que componen el clúster Péndulo se dividen en grupos (como ya se ha visto en las secciones 4.1 y 4.6) que llamaremos colas 19. Los trabajos lanzados en paralelo se ejecutan siempre dentro de una misma cola. Como todos los equipos de una misma cola están conectados al mismo switch, conseguimos que las comunicaciones entre tareas de un mismo trabajo sean más directas y no añadan retrasos innecesarios. Las colas existentes en el clúster son las siguientes: La cola pruebas contiene únicamente dos ordenadores que no están destinados al público en general. Se utilizan durante todo el día para pruebas de programas y configuraciones. La cola cursos abarca los 20 ordenadores que se encuentran en el Aula de Cursos (Ver sección 4.5). Las colas campus1, campus2, campus3 y campus4 abarcan los 60 equipos existentes en el Aula de Campus divididos según los switches a los que están conectados. 19 Realmente, aunque en un principio sí se utilizaban las colas del gestor de colas para dividir los equipos, actualmente se utilizan grupos de nodos (nodesets). No obstante a lo largo del documento se utiliza la palabra cola para referirnos a estos nodesets.

61 Capítulo 4. Desarrollo del proyecto 61 Para gestionar las colas y trabajos se utiliza el gestor de colas Torque [TOR], junto con el scheduler Maui [MAU]. Torque gestiona los cálculos, conoce sus propiedades y las de los nodos. El scheduler Maui se encarga de gestionar el orden de los cálculos. La división de ordenadores en colas debe hacerse en ficheros de configuración de Torque y Maui. En nuestro caso, se definen propiedades a cada nodo del sistema de colas. El fichero /var/spool/torque/server_priv/nodes contiene tantas líneas como nodos forman el sistema de colas, y el formato de cada línea es el siguiente: nombre_del_equipo [lista_de_propiedades] Por ejemplo, si el equipo nodo1 pertenece a la cola de pruebas, la línea que le corresponde en dicho fichero será: nodo1 pruebas También en el fichero de configuración del scheduler Maui (maui.cfg) se definen estas propiedades. Se han creado dos grupos de usuarios para el sistema de colas: penduloadm. Está destinado para albergar únicamente a los usuarios relacionados con la administración del sistema. Este grupo es el único que tiene permiso para ejecutar trabajos en la cola pruebas. pendulousers. Incluye a todos los usuarios del clúster. Tiene permisos para ejecutar trabajos en las colas cursos, campus1, campus2, campus3 y campus4. Para que los usuarios puedan ejecutar trabajos en las colas, deben tener los permisos adecuados. Para ello se utiliza el fichero /var/spool/torque/server_priv/acl_groups/normal en el que se han incluido los nombres de esos dos grupos (penduloadm y pendulousers). Para lanzar programas a las colas se usa el siguiente comando qsub script_file donde el archivo script_file contiene las directivas para el gestor de colas y los comandos a ejecutar para poner el trabajo en marcha.

62 62 Gestión del clúster Un script de ejemplo es el que se plantea en el listado B.28 (página 159). En dicho script se ejecuta en paralelo el programa a.out, utilizando el directorio de scratch global. Las directivas del gestor de colas son las que comienzan con #PBS: #PBS -l nodes=2:ppn=2 Se pide utilizar 2 nodos y 2 CPUs por nodo (2 CPUs en total). #PBS -l walltime=1:30:45 Selecciona un tiempo máximo de ejecución de 1 hora, 30 minutos y 45 segundos. #PBS -l mem=512mb Reserva 512 Mb de memoria RAM. Existen multitud de directivas para el gestor de colas. A continuación se describen algunos ejemplos más 20 : Sobre solicitud de nodos: PBS -l nodes=nodo1:ppn=2+nodo2:ppn=1 Pedimos dos procesadores del nodo1 y uno del nodo2. PBS -l nodes=1:ppn=1:cursos Pedimos un procesador de un nodo con la propiedad cursos, es decir, de la cola cursos Para el envío de sobre el estado de la ejecución de trabajos: #PBS -M micuenta@lg.ehu.es #PBS -m be Mediante la primera directiva se define una dirección de correo electrónico. Mediante la segunda, se le pide al gestor de colas que nos mande un trabajo cuando el programa entra en ejecución (b) y cuando termina (e). Podemos escoger una de las acciones (b o e) o las dos. Una vez mandado el trabajo a la cola, obtendremos en la salida estándar el número de identificación del proceso, por ejemplo: 159.lgua02 20 Para mayor información puede consultarse el manual en [TOR].

63 Capítulo 4. Desarrollo del proyecto 63 Tras la ejecución, el archivo script.e159 contendrá los posibles errores y el archivo scrip.o159 contendrá la salida estándar del programa. Las órdenes para el gestor de colas se pueden indicar directamente en el comando, en vez de en el script, usando a la hora de enviar el trabajo lo siguiente: qsub -l nodes=[val]:ppn=[val],mem=[val],cput=[val] script_file Uno de los requisitos buscados era disponer de una arquitectura lo más parecida posible al clúster Arina (Ver sección 3.1). De esta forma se pretendía conseguir que los usuarios tuvieran un sistema cuyo funcionamiento ya conocían. En este punto se ha ido más allá intentando buscar una integración mayor de Péndulo y Arina. Así por ejemplo, es posible lanzar los trabajos de Arina a Péndulo, de Péndulo a Arina y de cualquiera de ellos a Péndulo y Arina a la vez. El usuario sólo debe conocer unos comandos básicos: qsub: Es el comando utilizado para lanzar un trabajo en la máquina desde la que se manda. qsub_arina: Para mandar un trabajo a la máquina Arina. qsub_pendulo: Para mandar los trabajos a Péndulo. qsub_all: Para mandar el trabajo seleccionado a las dos máquinas (Péndulo y Arina). Se ejecutará realmente en aquella en la que primero entre a ejecución, y no en las dos. La forma de implementar todo esto ha sido mediante varios scripts que se describirán a continuación. El comando qsub es un comando propio del gestor de colas Torque para encolar un trabajo y posteriormente pasar a ejecutarlo. El ejecutable de Torque ha sido renombrado como qsub_original y en su lugar se ha creado un script (llamado qsub) que ha pasado a reemplazarlo. El código de este script en Péndulo puede verse en el listado B.23 y tiene dos tareas fundamentales: Manejar el sistema de almacenamiento (Ver sección 4.8.6) de manera transparente al usuario. La utilización del sistema de almacenamiento a la hora de lanzar trabajos a las colas se explica en la sección 4.4, y en especial en la figura 4.6 (página 49).

64 64 Gestión del clúster Evitar que las subtareas que compone el trabajo lanzado vayan a nodos de distintas colas. Esto se consigue mediante la opción: NODESET=ONEOF:FEATURE:cursos:campus1:campus2:campus3:campus4\. Este script no permite lanzar trabajos en la cola de pruebas, para ello se ha creado el script qsub_admin en el que la línea en la que se llama a qsub_original en el listado B.23 se sustituye por la siguiente: /usr/local/torque/bin/qsub_original $list $subscript El script qsub_arina se utiliza para lanzar un trabajo a Arina desde Péndulo. Su código para Péndulo puede verse en el listado B.24. En Arina este comando es un simple enlace a su script qsub. El script qsub_pendulo es el equivalente en Arina. Su código se muestra en el listado B.25. En Péndulo es un enlace al script qsub. El script qsub_all se utiliza para mandar un trabajo a los dos clústeres. Entrará en ejecución en uno de los dos (el primero que quede libre) y se borrará de la cola del otro. El script para lanzar desde Arina se muestra en el listado B.26, y el utilizado para lanzar desde Péndulo puede verse en el listado B.27. Ambos scripts realizan la siguiente secuencia de acciones: 1. Se capturan los parámetros elegidos. 2. Para Péndulo se modifican las opciones cuando los procesadores por nodo solicitados exceden de 2, o existen etiquetas adicionales propias de Arina. 3. Se guarda el identificador del trabajo en Arina junto al identificador del trabajo en Péndulo y otro identificador que llamaremos id (para luego poder borrarlo si es necesario) y se lanza el trabajo a Arina y a Péndulo. En este punto queda aún por realizar el filtrado de las directivas del gestor de colas cuando éstas se añaden directamente al script lanzado. Cuando los trabajos entran en ejecución ejecutan un prólogo que se encuentra en el fichero /var/spool/torque/mom_priv/prologue. Su código para Péndulo puede verse en el listado B.29. Básicamente lo que hace es comprobar si existe un trabajo en Arina con el mismo valor de la variable id y si lo encuentra borrarlo utilizando el comando qdel_arina (listado B.31) que envía una orden vía rsh al servidor de Arina para que borre el trabajo de la cola. El prólogo en Arina tiene el mismo funcionamiento, pero utilizará el script qdel_pendulo (listado B.32) para borrar el trabajo de la cola de Péndulo.

65 Capítulo 4. Desarrollo del proyecto 65 Si se desea borrar un trabajo lanzado con qsub_all, deberá utilizarse el comando qdel_all que lo borrará tanto de la cola de Arina como de la de Péndulo (listado B.30). Para controlar el estado de las colas se han creado también los scripts: qstat_arina: para ver el estado de las colas de Arina desde Péndulo. (Listado B.33). qstat_pendulo: para ver el estado de las colas de Péndulo desde Arina. (Listado B.34). rqstat, qqstat y qqstat filtran los trabajos según su estado sea running, queued o starving. (Listados B.35 a B.37). Se pueden establecer políticas de prioridad mediante el comando qmgr. Para evitar, por ejemplo, que un usuario monopolice el uso del clúster se puede establecer un número máximo de trabajos por usuario o grupo (Ver el apéndice Commands Overview en el manual de Torque [TOR]) Gestión de usuarios Cuando un nuevo usuario desea poder utilizar las máquinas de cálculo debe solicitar una cuenta de usuario. Para ello se ha habilitado un formulario Web cuyo funcionamiento es el siguiente: 1. Validación del usuario. El formulario Web está accesible a todo el mundo, pero únicamente el personal de la UPV/EHU debe poder utilizarlo. Para ello se hace una validación mediante nombre de usuario y contraseña contra el LDAP corporativo (Ver figura 4.9). Puede ser que personal de fuera de la UPV/EHU (alumnos, investigadores externos, etc.) necesite una cuenta para utilizar las máquinas de cálculo. En ese caso necesitará un aval perteneciente a la UPV/EHU que solicite la cuenta en su lugar. 2. Obtención de datos. Una vez la validación del usuario ha tenido lugar, se pide una serie de datos necesarios para generar la cuenta. En la figura 4.10 se muestra el formulario para el caso de solicitud de cuenta con aval. Si la cuenta no necesita aval, se pide sólo la parte de datos de la cuenta.

66 66 Gestión del clúster Figura 4.9: Formulario Web de solicitud de cuenta. Validación LDAP. 3. Procesar la nueva cuenta. Tras pulsar el botón Enviar, se escribe en un fichero llamado datos-form-pendulo una línea con la información de la nueva cuenta. Además esa misma línea es enviada vía para poder conocer al momento que una nueva cuenta ha sido solicitada. En el fichero datos-form-pendulo se va almacenando la información de todas las cuentas pendientes de crear. Cuando se estima conveniente, estas cuentas son creadas utilizando el script genera-cuenta cuyo código puede verse en el listado B.21. Los pasos que realiza el script son los siguientes: 1. En primer lugar descarga desde la Web el fichero datos-form-pendulo con la información de las cuentas pendientes de crear. 2. Una vez descargado lo imprime para que se pueda ver que los datos son correctos. Si algo no es correcto, se debe editar el fichero para corregirlo. 3. El siguiente paso es crear las cuentas de manera local en el servidor. Por cada línea del fichero datos-form-pendulo se realizan las siguientes acciones: a) El script genera el grupo del usuario a partir del dato pasado como jefedegrupo desde el formulario Web, pero antes de crearlo y asignarlo al usuario mues-

67 Capítulo 4. Desarrollo del proyecto 67 Figura 4.10: Formulario Web de solicitud de cuenta. Obtención de datos.

68 68 Gestión del clúster tra una lista de los grupos parecidos ya existentes, y nos da la posibilidad de cambiar el grupo que debe tener el usuario. b) Se genera además una contraseña de manera aleatoria de 7 caracteres, entre ellos dos cifras. Para ello se utiliza el script genera passwd.pl que se muestra en el listado B.22. c) Finalmente se crea la cuenta del usuario utilizando el grupo y contraseña ya establecidos. 4. A continuación se hacen las modificaciones oportunas en el servidor LDAP local para que los nodos reconozcan las nuevas cuentas. Esto se hace con dos instrucciones: Mediante la instrucción ldapadd se añaden los nuevos usuarios, y los grupos en caso de que haya sido necesario generar nuevos grupos. Utilizando una instrucción ldapmodify se añaden los nuevos usuarios al grupo pendulousers. Como ya se ha visto en la sección 4.8.2, este grupo tiene permisos para ejecutar trabajos en el sistema de colas. Esta es, por tanto, la forma de añadir los usuarios al sistema de colas. 5. Se crean después los directorios de scratch para los usuarios en /queue_scratch. 6. A continuación se procede a borrar los datos del fichero datos-form-pendulo en el servidor. Previamente se comprueba que no existan nuevos datos de cuentas que pudieran haber sido solicitadas en el proceso de crear las actuales. Una vez las cuentas han sido creadas se envía una carta al avalista o al titular de la cuenta con la información básica: nombre de usuario, contraseña y nombre del servidor. A partir de ese momento el usuario ya puede utilizar el clúster. Uno de los objetivos descritos en la sección establecía que el mantenimiento del clúster debía ser mínimo. Además se especificaba que el proceso de creación de cuentas de usuario debía ser automático y de forma que afectara a todos los nodos. El script genera-cuenta y el formulario Web de solicitud de cuentas son la forma de cumplir dicho objetivo Instalación de software La instalación del software de cálculo se hace íntegramente en el servidor, en la partición /software y se exporta mediante NFS a los nodos (Ver figura 4.11 en página 74).

69 Capítulo 4. Desarrollo del proyecto 69 De esta forma se facilita el mantenimiento, ya que el software está localizado en un único sitio y además se encuentra disponible en todo momento. Además se instala software en previsión de necesidades de los usuarios y no bajo demanda. De hecho, la política seguida es instalar el mismo software de cálculo instalado en Arina, salvo por problemas de compilación o de licencias. Desde el directorio /software/bin se puede acceder a todos los ejecutables de los programas de cálculo. Inicialmente eran enlaces a los ejecutables originales de los programas instalados en /software, pero actualmente se han ido creando varios scripts envoltorio (wrappers). Cada wrapper se encarga de cargar las librerías y exportar las variables de entorno necesarias para ejecutar cada programa, y después ejecuta el programa al que envuelve. Esto hace que puedan convivir programas compilados con distintas versiones de compiladores, puesto que cada wrapper cargará las librerías del compilador adecuado en cada caso. Se ha creado un script llamado bin_wrap.sh (ver listado B.18) cuyo objetivo es facilitar la creación de wrappers. Por ejemplo, puede crear todos los ejecutables de un programa de cálculo determinado. A continuación se enumeran los programas y utilidades para cálculo que se han instalado en Péndulo: Librerías: MPICH: Message Passing Interface. Librerías para paralelización [MPI]. Open MPI: Librerías para paralelización mediante MPI [OPEb]. MKL: Math Kernel Library. Librerías matemáticas de Intel, incluyen las librerías LAPACK y BLAS [MKL]. ScaLAPACK: Scalable LAPACK. Librerías LAPACK paralelizadas [SCA]. FFTW: Fastest Fourier Transform in the West [FFT]. BLACS: Basic Linear Algebra Communication Subprograms. Compiladores de Intel en las versiones 9.1 y 10.0 [INT]: ifort para lenguaje Fortran. icc para lenguaje C. icpc para lenguaje C++. Programas de cálculo:

70 70 Gestión del clúster VASP: Vienna Ab-initio of Simulation Package. Programa de cálculo desarrollado por la Universidad de Viena para dinámica molecular [VAS]. ABINIT: También para dinámica molecular [ABI]. Espresso: open-source Package for Research in Electronic Structure, Simulation, and Optimization [ESP]. Mathematica: programa matemático que incluye cálculo numérico, simbólico, visualización y lenguaje de programación [MAT]. WIEN2k: Programa de cálculo para dinámica molecular [WIE]. Molden: Paquete para visualizar estructuras y densidades electrónicas [MOL]. NWChem: Paquete de química computacional. [NWC]. Xmakemol: Paquete para visualizar estructuras atómicas [XMA]. Grace: herramienta WYSIWYG para hacer gráficos en dos dimensiones de datos numéricos [GRA]. Scilab: Programa matemático de cálculo numérico [SCI] Automatización de tareas Uno de los requisitos del proyecto (Ver sección 3.2, página 3.2) es que el mantenimiento del mismo debe ser mínimo. Las acciones a realizar deben hacerse de manera remota y afectando a todos los nodos a la vez. Para solventarlo se crearon los scripts cldo y ascp. Por otra parte, cuando es necesario realizar una tarea de mantenimiento en uno o más nodos de una o más colas es necesario esperar a que estén disponibles, y esto ocurre fuera del horario laboral. La solución a este problema viene con el script administrar. Scripts cldo y ascp En ocasiones es necesario ejecutar un comando en todos los nodos o en un grupo de nodos concreto a la vez. Para ello se ha creado el script cldo mostrado en el listado B.11 (página 133). El script obtiene la lista de nodos del fichero /var/spool/torque/server_priv/nodes. Este fichero forma parte de los ficheros de configuración del sistema de colas (Ver sección 4.8.2) de manera que siempre estará actualizado. Contiene tantas líneas como nodos forman el sistema de colas, y el formato de cada línea es el siguiente:

71 Capítulo 4. Desarrollo del proyecto 71 nombre_del_equipo [lista de propiedades] En la lista de propiedades se definen entre otras cosas los grupos o colas en que se dividen los equipos. La sintaxis para utilizar el script cldo es la siguiente: # cldo listanodos command Como se puede ver en el listado citado, el script lanza el comando definido por el usuario en el parámetro command a un conjunto de nodos del sistema de colas. El script realiza dos acciones diferentes en función del parámetro listanodos: 1. Si listanodos = all, se lanza el comando a todos los nodos definidos en el sistema de colas. 2. En otro caso, el parámetro listanodos se convierte en un patrón. Según ese patrón se eligen los nodos que formarán parte del grupo al que se lanzará la orden. Así por ejemplo, si ejecutamos el siguiente comando en una terminal: # cldo campus uname, el resultado es que todos los nodos con la cadena campus en su lista de propiedades ejecutarán el comando uname. El script cldo utiliza el comando ssh para mandar las órdenes a los nodos a través de la red. Pero esto no sirve para copiar un fichero en múltiples nodos a la vez. Para ello se ha creado el script ascp cuyo código puede verse en el listado B.12 (página 134). Su funcionamiento es similar al de cldo, pero en lugar del parámetro command necesitamos dos parámetros: El parámetro fichero indica la ruta del fichero que queremos copiar en los nodos. El parámetro destino indica la carpeta de destino en la que se copiará el fichero. Esta carpeta debe existir en todos los nodos. La sintaxis para utilizar el script ascp es, por tanto, la siguiente: # ascp listanodos fichero destino,

72 72 Gestión del clúster donde listanodos tiene el mismo significado que en el script cldo y se utiliza también de la misma manera. Los scripts cldo y ascp tienen un problema: sólo se ejecutan en aquellos nodos que están encendidos. Cuando éstos están apagados habrá que esperar a que se enciendan, o utilizar el sistema descrito a continuación. Script administrar Existen tareas que los nodos deben ejecutar periódicamente para su mejora y mantenimiento. Pero dado que no están disponibles en horario laboral, la única manera de que ejecuten estas tareas es dejarlas programadas para que las ejecuten cuando se enciendan. El script administrar se encarga de que los nodos ejecuten las tareas pendientes. Su código puede verse en el listado B.14 de la página 136. Se trata de un script de arranque de Linux o startupscript 21. Los startupscripts aceptan un parámetro que puede tomar varios valores (start, stop, restart, etc.) y en función del valor de ese parámetro se realizarán acciones diferentes. El script administrar sólo acepta los valores start y stop para el parámetro. Si no se le pasan parámetros, se toma la opción start por defecto. Se define la función usage() para imprimir una ayuda con la sintaxis del script cuando los parámetros pasados no son correctos. Tal y como se muestra en el listado 4.2, cuando un nodo ejecuta administrar con la opción start (startup=true), los nodos ejecutan todo el contenido del directorio /home/admin/encender/all. De igual forma, cuando el script se ejecuta con la opción stop (startup=false) los nodos ejecutan el contenido del directorio /home/admin/apagar/all. 1 i f [ " $startup " = true ] ; then Listado 4.1: Fragmento del script administrar. #Ejecutamos l o c o r r e s p o n d i e n t e a todos l o s equipos a l encender. 4 f o r i in $ ( l s /home/admin/ encender / a l l ) do /home/admin/ encender / a l l / $ i 7 done 21 Se definen de acuerdo con la Linux Standard Base Specification (LSB) (Ver [LSB]). También se puede encontrar información al respecto en [PAC].

73 Capítulo 4. Desarrollo del proyecto e l s e #Ejecutamos l o c o r r e s p o n d i e n t e a todos l o s equipos a l apagar. f o r i in $ ( l s /home/admin/ apagar / a l l ) 13 do /home/admin/ apagar / a l l / $ i done 16 f i Estos directorios son exportado vía NFS desde el servidor (ver figura 4.8) y por tanto se encuentran disponibles en todos los nodos. Su contenido son enlaces a scripts concretos encargados de realizar tareas específicas: Script encender_scratch_local. Se verá más adelante en la sección Scripts encender_scratch_global y apagar_scratch. Ya se ha visto en la sección 4.3 (página 44). El sistema operativo se encarga de ejecutar los startup scripts con la opción start cuando arranca, o con la opción stop cuando se apaga. Para ello, el startup script debe tener un bloque de información con una sintaxis específica en la que se definen las instrucciones para que el sistema operativo pueda ejecutarlo correctamente. El bloque para el script de arranque administrar se muestra en el listado 4.2 extraído del listado B.14. Listado 4.2: Información para el startup script administrar. 1 ### BEGIN INIT INFO # Provides : a d m i nistrar # Required S t a r t : $network $remote_fs portmap n f s s e r v e r 4 # Required Stop : $network portmap # Default S t a r t : 3 5 # Default Stop : # D e s c r i p t i o n : I n i c i a n d o t a r e a s de a d m i n i s t r a c i o n. ### END INIT INFO Se definen las siguientes instrucciones: Provides: Indicamos que el script provee el servicio que llamaremos administrar. Required-Start: Se definen los servicios que deben estar en funcionamiento para que administrar pueda empezar a arrancarse. En este caso, los servicios de red y sistemas de ficheros remotos entre otros.

74 74 Gestión del clúster /home 268 GB Conexión ethernet 1 Gbps /home (lgua00) /software /queue_scratch Disco local (NFS) Unidad virtual exportado desde el servidor (NFS) Unidad virtual exportado desde otro nodo servidor arina (lgua00) nuevo servidor péndulo (lgua02) Conexión ethernet 100 Mbps /home /home /software /software /scratch 55G /scratch 55G Nodo actuando como servidor de scratch global. /gscratch 55G /gscratch 55G Otro nodo en funcionamiento normal. Figura 4.11: Sistema de archivos de Péndulo. Required-Stop: Indica qué servicios necesitan que esté apagado para iniciar su apagado. Default-Start/Default-Stop: Especifica los niveles de ejecución 22 en los que por defecto el servicio administrar se arrancará (niveles 3 y 5) o apagará (niveles 0, 1, 2 y 6) Sistema de almacenamiento temporal global Desde que un usuario lanza un cálculo a una cola hasta que obtiene los resultados en su directorio personal, la información se va pasando de un sitio a otro de manera completamente transparente para el usuario. Al lanzar el trabajo se copian los ficheros de su directorio personal al directorio /queue_scratch, en una carpeta con su nombre de usuario. Será desde ahí realmente desde donde se lance el trabajo a ejecución y no desde su directorio personal (/home). 22 Para más información sobre los niveles de ejecución (runlevel) ver [RUN].

75 Capítulo 4. Desarrollo del proyecto 75 El directorio /queue_scratch está disponible en todos los nodos como /home por lo que constituye el directorio personal del usuario en esos nodos. La razón de que no se haga directamente desde /home es que dicho directorio se exporta vía NFS desde el servidor Arina. Si el /home de Arina tuviera que estar disponible en los nodos podrían darse algunos problemas: Problemas de rendimiento: Podría haber muchos nodos escribiendo a la vez en los discos duros de Arina, bloqueando recursos que deben ser de alta disponibilidad y rendimiento. Problemas de seguridad: Puesto que los nodos están en la red pública de la UPV/EHU y no en la red local privada del clúster Arina (en la que también se encuentra el servidor de Péndulo) debería abrirse el acceso desde el exterior a las máquinas propias de Arina, lo cual no resulta recomendable en términos de seguridad. La figura 4.11 muestra toda esta configuración del almacenamiento. En el directorio /queue_scratch del servidor existe una carpeta para cada usuario de Péndulo. Esta carpeta se crea al generar la nueva cuenta, como ya se ha visto en la sección Su utilización a la hora de lanzar trabajos a las colas se explica en la sección 4.4, y en especial en la figura 4.6 (página 49). El funcionamiento del sistema de almacenamiento global y los scripts utilizados para implementarlo ya han sido descritos en la sección 4.3. En cuanto a la creación de los directorios locales de scratch en los nodos, el funcionamiento es el siguiente: 1. Al encenderse se crea un directorio para cada usuario. Esto se hace mediante el script de inicio encender_scratch_local que se incluye en el listado B Al apagarse se borra el contenido de la carpeta /scratch. Su implementación está contenida en el script apagar_scratch (listado B.17) del que ya se habló en la sección 4.3. Necesitamos alguna forma de controlar el acceso al disco duro por parte de los usuarios del clúster. Para ello se ha instalado el paquete quota, que nos permite asignar una cuota de disco a cada usuario.

76 76 Gestión del clúster Monitorización Web Figura 4.12: Página Web de monitorización. Para monitorizar el estado de las colas y la ocupación del clúster se ha creado una aplicación Web en PHP 23 a la que se puede acceder en la dirección En ella se puede visualizar datos sobre los trabajos encolados, la ocupación de los nodos, etc. Esta Web se actualiza cada cinco minutos. La figura 4.12 muestra el apartado de ocupación semanal y estado actual de los nodos. La aplicación obtiene los datos que muestra de dos ficheros: Fichero queue.txt: Contiene información sobre el estado actual de las colas. Fichero general: Contiene información sobre la ocupación de los nodos y su estado 23 PHP Hypertext Pre-processor, inicialmente Personal Home Page tools. Lenguaje de programación interpretado usado normalmente para la creación de páginas Web dinámicas.

77 Capítulo 4. Desarrollo del proyecto 77 actual. Estos ficheros, junto a las figuras que muestran la ocupación semanal y mensual del clúster se suben al servidor Web cada cinco minutos. El script web.sh que se muestra en el listado B.42 es el encargado de generar estos ficheros y las figuras, y posteriormente subirlo al servidor Web. Este script se ejecuta cada cinco minutos gracias a una tarea programada con la utilidad crontab. Para programar una tarea con crontab debe seguirse el siguiente procedimiento: Ejecutar el comando # crontab tarea, donde tarea es un fichero cuyo contenido tiene la siguiente forma: min hora dia_mes mes dia_semana accion_a_realizar También es posible ejecutar # crontab -e e incluir esa misma línea. Para programar la tarea web.sh la línea adecuada es la siguiente: 2-57/5 * * * * /MONITORWEB/web.sh 2-57/5: Cada cinco minutos entre el minuto 2 y el 57. : Todas las horas del día. : Todos los días del mes. : Todos los meses del año. : Todos los días de la semana. /MONITORWEB/web.sh: Ejecutar el script web.sh. El script web.sh (ver listado B.42) realiza la siguiente secuencia de acciones: 1. Completa el fichero general con la siguiente información: Fecha actual (fecha de actualización de los datos) Número de procesadores totales definidos en el sistema. Número de procesadores usados en ese momento. Número de procesadores no disponibles.

78 78 Gestión del clúster Uso mensual del clúster: Para cada mes transcurrido se escribe una línea con el tiempo de cálculo consumido y el porcentaje de ocupación, tanto del mes actual como los acumulado hasta la fecha. 2. Completa el fichero queue.txt con la información del estado de los trabajos en las colas. 3. Crea dos figuras con la información sobre ocupación de las CPUs. Esto se hace mediante una llamada a los scripts figura1.sh y figura2.sh (listados B.43 y B.44), que utilizan los programas Scilab [SCI] y Gnuplot [GNU] para crear los diagramas. 4. Sube los ficheros creados al servidor Web. Los scripts figura1.sh y figura2.sh obtienen los datos de ficheros contenidos en el directorio /sof tware/n odes_status/. En esos ficheros se escribe la información sobre el estado de carga de los nodos cada quince minutos. El encargado de recopilar esa información y escribirla en el directorio /sof tware/n odes_status/ es el script monitoring_cpu que se muestra en el listado B.41. Este script se ejecuta cada quince minutos gracias a la siguiente tarea programada con crontab: */15 * * * * /software/nodes_status/monitoring_cpu Otras tareas de monitorización y mantenimiento Existen otras tareas necesarias en la gestión de Péndulo. Las más destacables se describen a continuación. Borrar archivos temporales El directorio /queue_scratch se creó para servir de puente entre los directorios personales del servidor Arina y los de los nodos de Péndulo (Ver secciones 4.4 y 4.8.6) a la hora de lanzar trabajos a las colas. En ocasiones se acumulan ficheros temporales de los cálculos (sobre todo si éstos fallan) que después no se borran. Para evitar una acumulación excesiva de estos ficheros se ha creado el script limpiar_queue_scratch que se muestra en el listado B.40. Este script busca los ficheros localizados en el directorio /queue_scratch que no pertenezcan al usuario root y que tengan una antigüedad de más de 60 días, los borra y deja un log con el nombre de los ficheros borrados.

79 Capítulo 4. Desarrollo del proyecto 79 Este script se ha programado con la utilidad crontab para ejecutarse todos los viernes a las 15:00 horas: * * 5 /root/bin/limpiar_queue_scratch Comprobar que los equipos se encienden En ocasiones algunos nodos de Péndulo no se encienden correctamente al llegar su hora. Esto puede deberse a varios motivos: El servidor REMBO no ha respondido correctamente y el nodo no ha sabido cómo arrancarse. Esto puede ocurrir por problemas propios del servidor o por un fallo de red. La red eléctrica de las aulas ha sido cortada (Ver sección 4.7 cuando habla de coordinación entre departamentos). Algún componente del nodo ha dejado de funcionar (discos duros, sobrecalentamiento de la placa base, etc.) Para controlar el encendido de los equipos se ha creado el script comprobar_encendidos que se ejecuta diariamente a las 21:30 horas. Tal y como se muestra en el listado B.39 la secuencia de acciones que realiza es la siguiente: 1. Averigua el estado de los nodos sirviéndose del comando diagnose propio del scheduler Maui. 2. Obtiene los datos históricos de los nodos que no se han encendido los últimos días y la actualiza con la nueva información de estado obtenida. 3. Envía un informando de los nodos que no responden, indicando cuántos días llevan sin responder. De esta forma podemos conocer qué nodos llevan fallando varios días seguidos, lo que hace sospechar una avería. Se emplea la utilidad crontab para programar esta tarea diaria, incluyendo la línea siguiente: * * * /queue_scratch/admin/bin/comprobar_encendidos

80 80 Gestión del clúster Matar trabajos en el servidor En ocasiones, los usuarios utilizan el servidor para lanzar cálculos de prueba antes de lanzarlo al clúster. Esto puede hacer que el servidor se sature y no pueda funcionar normalmente. Con objeto de evitarlo se seguirá la política de matar los trabajos que lleven más de una hora en ejecución. Para ello se ha creado el script kill_server_jobs que comprueba el tiempo de ejecución de los procesos cada diez minutos, mediante la tarea programada con crontab: 05,15,25,35,45,55 * * * * /root/bin/kill_server_jobs El script mostrado en el listado B.38 realiza las siguientes acciones: 1. Identificar los procesos que llevan más de una hora en ejecución que no pertenezcan a los usuarios root, bbuser y ldap. 2. Matar uno a uno los procesos. 3. Informar al usuario y al administrador de que se ha matado cada proceso. 4. Dejar información en un fichero de log. Ahorrar energía A partir de media noche, y con objeto de ahorrar energía eléctrica, si los nodos de Péndulo no se están usando se apagarán automáticamente. Esto se hace mediante un script llamado ahorrar_energia.sh (Listado B.19). El script comprueba si existen trabajos en la cola y en caso contrario apaga los nodos. Para que se ejecute de domingo a viernes a las 0:30 horas, se ha incluido una línea en el crontab: 30 0 * * 1,2,3,4,5,7 /queue_scratch/admin/bin/ahorrar_energia De lunes a viernes se da la orden de encender los equipos en Linux, de manera que el viernes se quedan encendidos hasta el lunes. Pero si apagamos los equipos a las 0:30 del sábado por no existir trabajos en cola a esa hora, el clúster no estará disponible para los investigadores que quieran trabajar durante todo el sábado. Por esta razón el script se ejecuta sólo de domingo a viernes.

81 Capítulo 4. Desarrollo del proyecto 81 Actualizaciones periódicas Con objeto de mantener el clúster al día es necesario realizar actualizaciones periódicas: Actualizar el sistema operativo y sus paquetes básicos. Estar al tanto de las nuevas versiones de compiladores, librerías y demás software de cálculo que va saliendo al mercado. Bigbrother y Backup diarios Para ayudar en el mantenimiento del servidor del clúster, se ha incluido el equipo en los servicios de Bigbrother 24 y Backup 25 que proporciona la UPV/EHU. Para ello ha sido necesario realizar algunos cambios en la configuración e instalar ciertos paquetes. Para el servicio de Backup instalamos un cliente para hacer copias de seguridad. Para ello tenemos el paquete lgtoclnt i686.rpm. Nos interesa fundamentalmente hacer copias de las particiones / y /software, puesto que el directorio /home es de Arina y los backup se realizan allí. Necesitamos también un script de inicio (como los que ya se ha visto en la sección 4.8.5, página 72) que arrancará el demonio Networker. El código de dicho script se muestra en el listado B.20. Para el servicio de Bigbrother ha sido necesario seguir el siguiente procedimiento: 1. Crear un usuario llamado bbuser Extraer e instalar el paquete correspondiente al cliente de BigBrother (bb19c.tar) 3. Editar el ficero bb-proctab incluyendo la lista de procesos que queremos controlar. Firewall Para el servicio de cortafuegos se utiliza SuseFirewall2 que viene instalado por defecto con el sistema operativo. El servidor tiene dos tarjetas de red, una interna y otra externa: Para la interfaz interna se permite el tráfico únicamente con los servidores de Arina. 24 Herramienta de monitorización de equipos. [BIG]. 25 Para realizar copias de seguridad diarias de los datos solicitados.

82 82 Gestión del clúster Para la interfaz externa se ha permitido el tráfico desde ciertas direcciones: 1. Servidor de monitorización Bigbrother. 2. Servidor de Backup corporativo. 3. Servidores de DNS Nodos del clúster. 5. El antiguo servidor de Péndulo. Se permite también el tráfico ssh y ntp 27. El firewall en los nodos debe permitir el tráfico de: Los propios nodos. Los servidores de Rembo que les prestan servicios de arranque remoto. Protocolo SSH. 26 Domain Name System. 27 Network Time Protocol

83 Capítulo 5 Pruebas 5.1. Prueba de programas. Todo el código generado ya sea en los scripts creados para la gestión del clúster como en las aplicaciones Web desarrolladas (monitor Web y solicitud de cuentas), ha sido probado de manera individual (por funciones o subprogramas) o con pruebas de caja negra 1 siguiendo los diferentes casos de uso. Los programas se fueron depurando y ampliando en función de los errores encontrados, los cambios en las necesidades y nuevas ideas. Las pruebas de caja negra para la aplicación Web de solicitud de cuentas han consistido en crear cuentas falsas en los siguientes casos: 1. Cuenta con aval: a) Personal de la UPV/EHU: estudiante, PAS 2, y PDI 3. b) Persona de fuera de la UPV/EHU. 2. Cuenta sin aval: PAS y PDI Pruebas del funcionamiento de las colas. Se hicieron varias pruebas con el gestor de colas Torque y el scheduler Maui. Dichas pruebas intentan demostrar que: 1. Los trabajos no se mezclan en nodos de diferentes colas. 1 Se estudian las entradas y salidas del programa sin importar el funcionamiento interno [CCGE03]. 2 Personal de Administración y Servicios 3 Personal Docente e Investigador 83

84 84 Análisis de rendimiento. 2. Los trabajos no entran a ejecutarse cuando las colas están en estado de reserva. El procedimiento de reserva es el que se utiliza para impedir que los trabajos entren en ejecución durante el día si por alguna causa encuentran nodos libres. 3. Los trabajos devuelven los resultados correctamente al directorio personal del usuario. 4. Se utiliza sólo el disco local (scratch) o se utiliza el disco compartido (scratch global) de manera correcta Análisis de rendimiento. Las pruebas realizadas para el análisis de rendimiento son pruebas de aceleración que miden el grado en que el clúster paraleliza los cálculos. Para ello, se ha lanzado el mismo cálculo a 1, 2, 4, 8 y 16 procesadores y se compara con el tiempo de paralelización ideal Pruebas con el programa VASP Las pruebas realizadas en el aula piloto estuvieron encaminadas a medir la pérdida de velocidad entre switches (Ver sección 5.4.1) y a encontrar el tamaño de paquete óptimo para NFS (Ver sección 5.4.2). Para estas pruebas se utilizó un cálculo con el programa VASP. Este mismo cálculo fue a su vez ejecutado en el Aula de Cursos y en la máquina de cálculo Arina, con objeto de comparar el rendimiento y la velocidad en los dos clústeres. Los resultados obtenidos en el Aula de Cursos apenas difieren de los obtenidos en el aula piloto 5. En la tabla 5.1 se recogen para cada clúster los tiempos de ejecución en segundos y los coeficientes de paralelización de dicho cálculo. Para calcular el coeficiente de paralelización se usa la fórmula siguiente: coef iciente = 1 walltime cpu_number La representación gráfica de estos datos se ve en las figuras 5.1 y 5.2. Como puede observarse, el cálculo no paraleliza bien para un número de procesadores mayor de cuatro. 4 El tiempo de paralelización ideal es el resultado de dividir el tiempo de ejecución para el cálculo en un único procesador, entre el número de procesadores empleado. 5 Utilizando siempre el mismo switch.

85 Capítulo 5. Pruebas 85 Figura 5.1: Pruebas de paralelización en Arina y Péndulo. Representa los datos de la tabla 5.1. Compara el tiempo de CPU empleado para un cálculo lanzado a 1, 2, 4, 8 y 16 procesadores en las dos máquinas.

86 86 Análisis de rendimiento. Figura 5.2: Pruebas de paralelización en Arina y Péndulo. Representa los datos de la tabla 5.1. Compara los coeficientes de paralelización para un cálculo lanzado a 1, 2, 4, 8 y 16 procesadores en las dos máquinas.

87 Capítulo 5. Pruebas 87 Número de Tiempo de ejecución Coef. paralelización CPUs Péndulo Arina Péndulo Arina ,82 0, ,75 0, ,35 0, ,17 - Tabla 5.1: Tiempos de ejecución real en segundos y coeficientes de paralelización de un cálculo con el programa VASP lanzado a 1, 2, 4, 8 y 16 procesadores en las máquinas de cálculo Arina y Péndulo. Número de Tiempo de ejecución Coef. paralelización CPUs A. Cursos A. Campus A. Cursos A. Campus Tabla 5.2: Tiempos de ejecución real en segundos y coeficientes de paralelización de un cálculo con el programa VASP tras ser optimizado en las aulas de Péndulo. En un intento de acelerar la ejecución del programa VASP en Péndulo, éste fue recompilado con nuevas versiones de compiladores. Además, en el mismo cálculo anterior se modificaron algunas opciones para la ejecución. El resultado fue un gran incremento en la capacidad de paralelización. En la tabla 5.2 se recogen los tiempos de ejecución en segundos y los nuevos coeficientes de paralelización para las dos aulas actualmente activas (Aula de Cursos y Aula de Campus). La representación gráfica de estos datos se ve en las figuras 5.3 y 5.4. Del resultado de las pruebas podemos concluir que unas mayores capacidades hardware para el clúster no lo son todo. La optimización de los programas al compilarlos y la elección de adecuadas opciones a la hora de ejecutar los cálculos puede acelerar mucho la velocidad de los cálculos. Por eso es importante: por un lado, estar al tanto de las versiones mejoradas de compiladores y otros paquetes software que van saliendo; y por otro, realizar test de rendimiento en cada nueva configuración (cambio en redes

88 88 Análisis de rendimiento. Figura 5.3: Pruebas de paralelización en las aulas de Péndulo. Representa los datos de la tabla 5.2. Compara el tiempo de CPU empleado para un cálculo lanzado a distinto número de procesadores.

89 Capítulo 5. Pruebas 89 Figura 5.4: Pruebas de paralelización en las aulas de Péndulo. Representa los datos de la tabla 5.2. Compara los coeficientes de paralelización para un cálculo lanzado a distinto número de procesadores.

90 90 Análisis de rendimiento. Número de Tiempo de CPU Walltime Tiempo CPUs 1 cpu/nodo 2 cpu/nodo 1 cpu/nodo 2 cpu/nodo ideal Tabla 5.3: Tiempos de ejecución en segundos de un cálculo con el programa NWChem lanzado a 1, 2, 4, 8 y 16 procesadores utilizando una y dos CPUs por nodo. o en equipos) que se ponga en marcha y adecuar las opciones de ejecución en función de los resultados. Resumiendo, ptimizando los programas en la compilación y seleccionando las opciones adecuadas se pueden incrementar las capacidades del clúster sin aumentar el equipamiento hardware Pruebas con el programa NWChem en el Aula de Campus Para las pruebas de aceleración en el nuevo Aula de Campus se ha utilizado el programa NWChem. Se trata de un cálculo para la optimización de la molécula de penicilina (Ver figura 5.5) al nivel de teoría B3LYP/6-31.El cálculo VASP utilizado para las pruebas en el aula piloto y el Aula de Cursos se quedaba pequeño para estos ordenadores mucho más potentes y fue necesario utilizar este nuevo cálculo más complejo. El mismo cálculo se ha lanzado a 1, 2, 4, 8 y 16 procesadores utilizando un sólo procesador de los dos que tienen los ordenadores Figura 5.5: Molécula de la penicilina. del Aula de Campus; y también a 2, 4, 8 y 16 procesadores utilizando siempre los dos procesadores de cada nodo. Para cada prueba se han utilizado siempre nodos de la misma cola, es decir, no se mezclan nodos conectados a distintos switches. La tabla 5.3 recoge los tiempos de ejecución de los cálculos en segundos. Como puede verse en la figura 5.6, un cálculo necesita menos tiempo de CPU si sólo utiliza un procesador de cada nodo, quedando el otro libre. Esto se debe a que los recursos compartidos por los dos procesadores (memoria, buses, etc.) están dedicados exclusivamente al core ocupado. Sin embargo, tal y como observamos en la figura 5.7, el tiempo real de ejecución (walltime) es muy similar tanto si se utiliza un procesador por nodo como los dos. Esto

91 Capítulo 5. Pruebas 91 Figura 5.6: Pruebas de paralelización en el Aula de Campus. Representa los datos de la tabla 5.3. Compara el tiempo de CPU empleado para un cálculo lanzado a 1, 2, 4, 8 y 16 procesadores, en función de si se utiliza un procesador por nodo o los dos.

92 92 Análisis de rendimiento. Figura 5.7: Pruebas de paralelización en el Aula de Campus. Representa los datos de la tabla 5.3. Compara el walltime (tiempo real) empleado para un cálculo lanzado a 1, 2, 4, 8 y 16 procesadores, en función de si se utiliza un procesador por nodo o dos.

93 Capítulo 5. Pruebas 93 Figura 5.8: Pruebas de paralelización en el Aula de Campus. Representa los datos de la tabla 5.3. Compara los resultados para un cálculo lanzado a 1, 2, 4, 8 y 16 procesadores, utilizando únicamente un procesador por nodo. Figura 5.9: Pruebas de paralelización en el Aula de Campus. Representa los datos de la tabla 5.3. Compara los resultados para un cálculo lanzado a 1, 2, 4, 8 y 16 procesadores, utilizando siempre dos procesadores por nodo. se debe al retardo que se introduce en las comunicaciones entre nodos. Para cálculos cuyas tareas no necesitan apenas comunicarse resultará más eficiente, si hay nodos de sobra, lanzar los cálculos a un sólo procesador por nodo. A medida que las comunicaciones entre tareas van creciendo la ventaja proporcionada por un menor tiempo de CPU se irá reduciendo hasta llegar a invertirse la tendencia. Por tanto, para cálculos cuyas tareas necesitan mayor comunicación, lo más eficiente es agrupar las tareas en los procesadores de un mismo nodo. Para cálculos cuyas tareas no necesitan apenas comunicarse resultará más eficiente lanzar los cálculos a un sólo procesador por nodo. Al contrario, si las tareas necesitan mayor comunicación será preferible utilizar los dos procesadores de los nodos.

94 94 Otras pruebas Número de Tiempo en Tiempo en Tiempo de Tiempo CPUs 1 switch 2 switches CPU ideal Tabla 5.4: Tiempos de ejecución en segundos de un cálculo VASP en nodos de 1 o 2 switches. Datos representados en la figura Otras pruebas En esta sección se detallan los resultados de las pruebas llevadas a cabo para analizar problemas relacionados con las aulas, como por ejemplo, cuellos de botella en la red Paralelización entre switches Se han realizado algunas pruebas para medir la pérdida de eficiencia o de velocidad al utilizar nodos conectados a distintos switches. Estas pruebas son la justificación de por qué se han dividido los equipos del Aula de Campus en cuatro colas diferentes en función del switch al que están conectados. La tabla 5.4 recoge los tiempos de ejecución en segundos de un cálculo realizado con el programa VASP para cálculos de estructura atómica. El cálculo no paraleliza bien para un número de procesadores mayor de cuatro 6. Aún así, nos sirve para analizar la pérdida de velocidad en las comunicaciones. En el estudio se emplearon los ordenadores del aula piloto. En la figura 5.10 podemos ver la representación gráfica de los datos de la tabla 5.4. El tiempo ideal es el resultado de dividir el tiempo de ejecución del programa en una única CPU entre el número de CPUs empleado. Como puede verse, el Tiempo de CPU real apenas dista del tiempo ideal. No obstante, a medida que aumenta el número de CPUs se puede notar un incremento en el retardo debido a las comunicaciones. Este incremento es aún mayor cuando se utilizan nodos de dos switches diferentes. Los resultados de estas pruebas nos llevaron a dividir los equipos en colas en función del switch al que están conectados. 6 Como se ha visto en la sección 5.3.1, posteriormente el programa VASP fue recompilado y sus opciones de ejecución fueron modificadas, logrando un gran incremento en la capacidad de paralelización. No obstante, los cálculos para medir la pérdida de velocidad entre switches no se repitieron con la nueva versión. Se ha considerado que los cálculos ya realizados eran suficientes para probar esa pérdida de velocidad y justificar la división por colas en función del switch.

95 Capítulo 5. Pruebas 95 Figura 5.10: Pérdida de velocidad en las comunicaciones entre switches. Representa los datos de la tabla 5.4. Es la base para la decisión de la división de equipos en colas por switches.

96 96 Otras pruebas Resumiendo, aunque el tiempo de CPU no difiere mucho del tiempo ideal, a más número de CPUs se introduce mayor retardo debido a las comunicaciones. El retardo es aún mayor al utilizar nodos de switches diferentes, por lo que se ha decidido separar los nodos en colas en función de los switches Optimización de tamaño de paquete para NFS Tal y como se comentó en secciones anteriores los nodos utilizan tecnología NFS para el sistema de almacenamiento. En concreto, cogen los directorios /home y /software desde el servidor y el directorio /gscratch desde otro nodo y lo montan en su propio sistema de ficheros. Para ello se necesita añadir una línea en el fichero /etc/fstab de los nodos por cada directorio que se monta, o utilizar el comando mount con las opciones adecuadas. Para el directorio /home la línea es la siguiente: lgua02:/home /home nfs rw,rsize=8192,wsize= NFS empaqueta los datos en porciones (paquetes) para viajar a través de la red. Las opciones rsize y wsize definen el tamaño del paquete de datos que leerá o escribirá respectivamente vía NFS. Para averiguar cuál es el tamaño de paquete óptimo para la configuración de Péndulo se han hecho pruebas que miden la velocidad de escritura para distintos tamaños de paquete. El procedimiento seguido para realizarlas es el que se describe a continuación: 1. Desmontamos /home mediante la orden: # umount /home Antes de ello sería necesario comprobar que ningún usuario está usando ese directorio. 2. Montamos de nuevo el directorio /home para probar como tamaño de paquete 1024 bytes. #mount lgua02:/home /home -o rw,wsize= Escribimos un fichero de ceros de 1 6 GB y calculamos el tiempo que tarda en hacerlo. # time dd if=/dev/zero of=/home/lgbcagor/medidas_rdto/test

97 Capítulo 5. Pruebas 97 Tamaño Intentos invis paquete Intento 1 Intento 2 Intento 3 Intento 4 Intento 5 Media m08s 3m03s 3m11s 3m08s 3m13s 3m07s m47s 2m52s 2m59s 3m00s 2m53s 2m54s m24s 2m24s 2m24s 2m24s 2m24s 2m24s m22s 2m22s 2m22s 2m22s 2m24s 2m23s m22s 2m22s 2m22s - - 2m22s m22s 2m22s m22s Tabla 5.5: Comparativa de medidas de velocidad tomadas para NFS en /home según el tamaño del paquete. bs=16k count=100k El fichero debe ser por lo menos dos veces mayor que la memoria RAM, para que no se quede almacenado en ella. 4. Volvemos a repetir el proceso (puntos 1 a 3) hasta cinco veces, para asegurarnos de que las medidas son significativas y no se ven distorsionadas por momentos puntuales de mucho tráfico. Como puede observarse, no existen desviaciones notorias en estas medidas. Repetiremos este proceso para tamaños de paquete cada vez mayor (2048, 4096, 8192, etc.) hasta que la mejora en el tiempo sea despreciable. Los resultados obtenidos en estas mediciones se resumen en la tabla 5.5. A la vista de estos resultados, el tamaño de paquete elegido ha sido de 8192 bytes, puesto que con tamaños mayores no existía una mejora significativa. El tamaño de paquete elegido para utilizar con NFS ha sido 8192 bytes por no existir mejoras significativas con tamaños mayores. Por otra parte, también se han realizado pruebas para evaluar el rendimiento de la escritura en el scratch global. En ellas se ha medido la velocidad de escritura desde un nodo al directorio de scratch global, en los siguientes casos: 1. Cuando ambos (nodo y servidor de scratch) se encuentran conectados al mismo switch. 2. Cuando el nodo y el servidor de scratch están conectados a switches distintos.

98 98 Otras pruebas Prueba Intento 1 Intento 2 Intento 3 Media Distinto switch 2m23s 2m23s 2m23s 2m23s Mismo switch 2m22s 2m22s 2m22s 2m22s Concurrente 1 4m46s 4m51s 4m51s 4m49s Concurrente 2 4m46s 4m48s 4m50s 4m48s Tabla 5.6: Comparativa de medidas de velocidad tomadas para NFS en /gscratch según switches. 3. Cuando dos nodos escriben en el mismo directorio de scratch global al mismo tiempo (Escritura concurrente). En este caso se han tomado nodos conectados a un switch diferente al del servidor de scratch. El tamaño de paquete utilizado para estas pruebas ha sido de 8192 bytes. El procedimiento seguido es similar al que se ha descrito para las pruebas de escritura en /home: 1. Montamos en el directorio /gscratch el directorio /scratch del nodo $equipo_scratch que actúa como servidor de scratch global. # mount $equipo_scratch:/scratch /gscratch -o rw,wsize= Escribimos un fichero de ceros de 1 6GB: # time dd if=/dev/zero of=/gscratch/lgbcagor/test 3. Desmontamos: # umount /gscratch 4. Repetimos el proceso con el resto de casos. bs=16k count=100k Los resultados de las pruebas realizadas se recogen en la tabla 5.6. Las dos últimas filas de la tabla 5.6 resumen los datos obtenidos en las pruebas de escritura concurrente. Cada fila corresponde a los datos obtenidos por cada uno de los dos nodos empleados en la prueba. A la vista de los resultados, podemos decir que la velocidad de escritura cuando se utilizan nodos en distintos switches no se ve aumentada de manera significativa. Por lo tanto, se puede concluir que no supone ningún inconveniente utilizar únicamente dos equipos como servidores de scratch global para las cuatro colas (o switches) existentes en el Aula de Campus, en lugar de cuatro servidores de scratch. Por esta razón, ha sido esa la configuración adoptada finalmente para este aula. No obstante, se está monitorizando la red con la herramienta MRTG 7 [MRT] con objeto de detectar problemas de saturación 7 Multi Router Traffic Grapher.

99 Capítulo 5. Pruebas 99 de los ordenadores de scratch global. En ese caso sería necesario poner más equipos como servidores de scratch global. Los resultados obtenidos en la escritura concurrente indican que se necesita prácticamente el mismo tiempo para escribir dos ficheros a la vez desde dos nodos distintos, que escribir los ficheros uno detrás del otro. Resumiendo, ya que la velocidad de escritura al utilizar nodos en distintos switches no se ve aumentada de manera significativa, se ha decidido emplear únicamente dos equipos como servidores de scratch global para las cuatro colas del Aula de Campus. Además se necesita el mismo tiempo para escribir dos ficheros a la vez que uno detrás de otro.

100 100 Otras pruebas

101 Capítulo 6 Presupuesto Este capítulo resume la planificación de tareas y actividades con sus respectivos tiempos, costes y recursos empleados en el proyecto, con objeto de conseguir los objetivos planteados. Se plantea además una comparación con la planificación inicial proyectada en el documento de Anteproyecto, justificando las desviaciones Planificación de tareas En esta sección se hace un resumen de las tareas planificadas inicialmente, las cuales fueron ya presentadas en el documento de Anteproyecto, para después comparar con la secuencia real de actividades y plazos seguidos en su realización. En la sección se puede encontrar una justificación de las desviaciones que ha sufrido el plan inicial Planificación inicial Inicialmente se identificó la siguiente división de tareas en la realización futura del proyecto: 1. Análisis de la situación inicial y toma de decisiones acerca de las salas de ordenadores, herramientas y sistema operativo a utilizar. 2. Formación sobre las herramientas, entorno de programación, etc. 3. Implantación Instalación de la primera sala Instalación del sistema operativo en un nodo. 101

102 102 Planificación de tareas Instalación de programas básicos y configuración Integrar con el servidor Debian de manera que sea compatible su utilización Instalar y configurar el resto de equipos utilizando un servidor de imágenes Realizar pruebas de ejecución en paralelo Trasladar a la segunda sala Instalar los equipos utilizando un servidor de imágenes Realizar la configuración particular de la sala Integrar las dos salas con sus funcionamientos particulares en el mismo servidor Implementar herramientas para la monitorización del estado del clúster (nodos que fallan, estado de las colas de trabajos, etc.), el análisis de rendimiento y tasas de ocupación. 4. Fase de pruebas Funcionamiento de las colas de trabajos en todas las salas Análisis de rendimiento: aceleración o velocidad de ejecución de los trabajos en paralelo y tasas de ocupación Análisis de problemas relacionados con las aulas: exceso de temperatura, cuellos de botella en la red, etc. 5. Fase de mantenimiento Atención y administración de usuarios: Crear nuevas cuentas, resolver dudas y problemas, vigilar el uso correcto y eficiente del clúster, etc Actualizaciones del sistema operativo, programas, nuevas versiones de compiladores, librerías, etc Revisión y monitorización de los elementos del clúster, asegurándose de su correcto funcionamiento (tanto del hardware como del software). Habrá que mostrar atención a los fallos en ordenadores debidos a un exceso de temperatura o un uso intensivo de disco duro y otros recursos computacionales.

103 Capítulo 6. Presupuesto 103 invis Fecha de Fecha de Tiempo de Lista de tareas comienzo finalización trabajo (días) 1. Análisis 20/11/ /11/ Formación 27/11/ /03/ Implantación 11/12/ /06/ Instalación primera sala 11/12/ /03/ Instalación segunda sala 20/03/ /05/ Integración con el servidor 10/05/ /05/ Herramientas de monitorización 31/05/ /06/ Pruebas 21/06/ /07/ Mantenimiento 19/07/ /09/ Tabla 6.1: Lista de tareas y fechas de la planificación inicial. Figura 6.1: Diagrama Gantt inicial. La tabla 6.1 recoge las estimaciones de tiempo para esta lista de tareas inicial. Se tomó una dedicación de cuatro horas diarias como media, con una semana laboral de cinco días, respetándose períodos vacacionales (Navidad, Semana Santa y el mes de Agosto) y días festivos, así como los períodos de exámenes en la UNED. El diagrama Gantt de la figura 6.1 representa la cronología de las tareas inicialmente planteadas y las dependencias entre ellas Desviación de lo planificado Durante el desarrollo del proyecto, hubo que cambiar la secuencia de tareas planteada en el apartado anterior para adaptarse a las circunstancias del proyecto: La retirada de un servidor de autenticación de los servicios de la UPV/EHU hizo posible incorporarlo al servicio. El nuevo servidor llegó tras instalar la primera sala (Aula de Cursos) y se comenzó inmediatamente con su instalación y configuración.

104 104 Planificación de tareas Los equipos antiguos del Aula de Campus fueron, como ya se ha dicho, sustituidos por otros más potentes. Esto ocurrió antes de poder comprobar si el aula piloto funcionaba con el nuevo servidor. En ciertas ocasiones, resultaba imposible avanzar en la tarea diaria establecida por varias razones: 1. Aula de Cursos ocupada por impartición de cursos. 2. No disponibilidad de los equipos por razones de mantenimiento por parte del CAU. 3. No disponibilidad de los equipos por necesidades del funcionamiento de la UPV/EHU, como ocurre por ejemplo en períodos de matriculación de alumnos. 4. Problemas de red y corriente. En estos casos se alteraba la secuencia de tareas establecida, y se pasaba a realizar tareas independientes de dichos problemas 1. También los plazos de ejecución previstos se vieron alterados fundamentalmente por dos razones: 1. Períodos de baja por enfermedad. 2. Ocupación en otras necesidades del servicio, como la creación de formularios Web para petición de software y solicitud de tiempo de cálculo Lista de tareas y plazos reales La lista de tareas finalmente llevadas a cabo se muestra en la siguiente división: 1. Análisis de la situación inicial, y toma de decisiones acerca de las salas de ordenadores, herramientas y sistema operativo a utilizar. 2. Formación sobre las herramientas, entorno de programación, etc. 3. Implantación Instalación de la primera sala Instalación del sistema operativo en un nodo. 1 Por ejemplo, la tarea 3.4 (implementación de herramientas para la monitorización).

105 Capítulo 6. Presupuesto Instalación de programas básicos y configuración Integrar con el servidor Debian de manera que sea compatible su utilización Instalación del cliente LDAP Instalar y configurar el resto de equipos utilizando un servidor de imágenes Integrar la primera sala y el aula piloto con sus funcionamientos particulares en el servidor Instalación del nuevo servidor Instalación del sistema operativo Configuración del sistema Instalación de programas Instalación del servidor LDAP Instalación y configuración del gestor de colas Torque y el scheduler Maui Trasladar a la segunda sala Instalación del sistema operativo en los nodos de pruebas (2 modelos) Instalación de programas básicos y configuración Integrar con el nuevo servidor Instalar y configurar el resto de equipos utilizando un servidor de imágenes Integrar las dos salas en el nuevo servidor Implementar herramientas para la monitorización del estado del clúster, el análisis de rendimiento y tasas de ocupación. 4. Pruebas Funcionamiento de las colas de trabajos en todas las salas y realizar pruebas de ejecución en paralelo Análisis de rendimiento: aceleración o velocidad de ejecución de los trabajos en paralelo y tasas de ocupación Análisis de problemas relacionados con las aulas: exceso de temperatura, cuellos de botella en la red, etc. 5. Fase de mantenimiento.

106 106 Planificación de tareas invis Fecha de Fecha de Tiempo de Lista de tareas comienzo finalización trabajo (días) 1. Análisis Formación Implantación 10/10/ /02/ Instalación primera sala 10/10/ /03/ ,5 3.2 Instalación nuevo servidor 29/03/ /05/ Instalación segunda sala 23/04/ /06/ Integración con el servidor 01/02/ /02/ Herramientas de monitorización ,5 4. Pruebas ,5 5. Mantenimiento ,5 6. Documentación 05/02/ /02/ Tabla 6.2: Fechas y plazos reales de las tareas realizadas Atención y administración de usuarios: Crear nuevas cuentas, resolver dudas y problemas, vigilar el uso correcto y eficiente del clúster, etc Actualizaciones del sistema operativo, programas, nuevas versiones de compiladores, librerías, etc Revisión y monitorización de los elementos del clúster, asegurándose de su correcto funcionamiento (tanto del hardware como del software). Habrá que mostrar atención a los fallos en ordenadores debidos a un exceso de temperatura o un uso intensivo de disco duro y otros recursos computacionales Corrección de errores en código en scripts y aplicaciones Web. 6. Documentación Documentación y comentarios en scripts Diario de laboratorio Memoria del proyecto Documentación para presentaciones oficiales del proyecto. El orden en el que se plantean no tiene por qué coincidir en todos los casos con la ejecución cronológica de las tareas. En la tabla 6.2 se resume de manera aproximada, los plazos y duración de las tareas enumeradas. Las fechas no aparecen cuando éstas se encuentran demasiado salteadas en el tiempo.

107 Capítulo 6. Presupuesto 107 invis Tiempo (días) Nombre de la tarea Planificado Real Análisis 5 0 Formación Implantación (suma de subtareas) Implantación: Instalación primera sala 45 54,5 Implantación: Nuevo servidor 0 38 Implantación: instalación segunda sala Implantación: Integración con el servidor 10 1 Implantación: Herramientas de monitorización 15 17,5 Pruebas 20 31,5 Mantenimiento 20 25,5 Documentación 0 15 Tiempos totales 190 días 222 días Tabla 6.3: Comparativa entre las duraciones planificadas y reales. En la tabla 6.3 puede verse las diferencias entre lo planificado y lo real en relación a las duraciones de las actividades. Las figuras 6.2 y 6.3 muestran los diagramas de Gantt para la cronología real de las tareas. El gráfico ha sido realizado en PHP con los datos extraídos del diario de laboratorio que recoge la información acerca de las actividades que se realizan diariamente. Como puede verse en la figura 6.4: Los fines de semana, periodos vacacionales y festivos están marcados en color gris. Los periodos de baja por enfermedad, días de consulta médica y días no trabajados por realización de exámenes están marcados con color naranja. Los días dedicados a trabajos del departamento no relacionados con el desarrollo del proyecto están marcados en color verde. La lista de tareas puede verse en la primera columna de la figura 6.2. La segunda columna es el número de días que se ha dedicado algo de tiempo a la realización de la tarea. La tercera columna es la suma del tiempo dedicado a cada tarea. Ya que hay días en los que se realiza más de una tarea, el tiempo dedicado ese día se divide entre las tareas realizadas. En la figura 6.5 pueden verse gráficamente las desviaciones en la secuencia de tareas planificadas y ejecutadas.

108 108 Planificación de tareas Figura 6.2: Diagrama Gantt de seguimiento 10/2006 a 06/2007.

109 Capítulo 6. Presupuesto 109 Figura 6.3: Diagrama Gantt de seguimiento 07/2007 a 03/2008.