Universidad Politecnica´ de Madrid Facultad de Informatica´
Proyecto fin de carrera
Sistema de recuperacion´ automatica´ de un supercomputador con arquitectura de cluster
Autor: Juan Morales del Olmo Tutores: Pedro de Miguel Anasagasti Oscar´ Cubo Medina
Madrid, septiembre 2008 La composicion´ de este documento se ha realizado con LATEX. Diseno˜ de Oscar Cubo Medina.
Esta obra esta´ bajo una licencia Reconocimiento-No comercial-Compartir bajo la misma licencia 2.5 de Creative Commons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.5/ o envie una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Las ideas no duran mucho. Hay que hacer algo con ellas.
Santiago Ramon´ y Cajal
A todos los que he desatendido durante la carrera
Sinopsis
El continuo aumento de las necesidades de computo´ de la comunidad cient´ıfica esta´ ocasionando la proliferacion´ de centros de supercomputacion´ a lo largo del mundo. Desde hace unos anos˜ la tendencia es ha utilizar una arquitectura de cluster para la construccion´ de estas maquinas.´
Precisamente la UPM cuenta con uno de estos computadores. Se trata de Magerit, el segundo super- computador mas´ potente de Espana˜ que se encuentra alojado en el CeSViMa y que alcanza los 16 TFLOPS.
Los nodos de computo´ de un sistema de estas caracter´ısticas trabajan exhaustivamente casi sin des- canso, por eso es frecuente que vayan sufriendo problemas. Las tareas de reparacion´ de nodos consumen mucho tiempo al equipo de administracion´ de CeSViMa y no existen herramientas que agilicen estas labo- res.
El objetivo de este proyecto es dotar de cierta autonom´ıa a Magerit para que pueda recuperar de forma automatica´ sus nodos de computo´ sin la intervencion´ de los administradores del sistema.
Al final de este proyecto se obtendra´ un sistema software inedito´ que controlara´ y mantendra´ el buen funcionamiento de los nodos de computo´ de un cluster formado por mas´ de 1200 maquinas.´
– I –
Agradecimientos
Quisiera dar las gracias a todas las persona que de alguna manera me han ayudado a terminar y disfrutar la carrera:
A mis padres, Jose Luis y Carmen por apoyarme y preocuparse tanto por mi y mis estudios en estos 5 anos˜ de carrera.
A mis hermano Luis, por alegrarme tanto el d´ıa a d´ıa y siempre estar dispuesto a echar la ultima.´
A mis abuelas, Nica y Santos por ensenarme˜ a mirar la vida desde otra perspectiva.
Al resto de mi familia por todo el animo´ que me han dado.
A Clara, por todo.
A mis companeros˜ del CeSViMa, a Oscar por haberme ensenado˜ lo que no esta´ en los escritos. A Fernando por proteger a capa y estada, y tratar tan bien a los suyos. A Carlos por ensenarme˜ que el saber no ocupa lugar, solo´ en los cajones. A Victor por los ratos de aprendizaje y los cables que me ha echado. A Santi por estar siempre en el despacho y siempre abierto a una buena charla.
A Pedro por haberme dado la oportunidad de trabajar en CeSViMa y por las ayudas prestadas.
A mis companeros˜ de aquella practica´ de cuyo nombre no quiero acordarme, Adri, Geno, Giorgi y Clara.
A mis companeros˜ de clase, Bego, Sara, David, Riqui, Mario, Sergio y Anto.
A la gente de Histrion,´ por tantos buenos momentos figurando.
Y a todo aquel que crea que debe que estar aqu´ı y que me sepa disculpar por mi mala memoria.
– III –
Indice´ general
Sinopsis ...... I
Agradecimientos ...... III
Indice´ general ...... V
Indice´ de figuras ...... XI
Indice´ de cuadros ...... XIII
Acronimos´ ...... XV
PARTE IINTRODUCCIONYOBJETIVOS´
1. Introduccion...... ´ 3
1.1. CeSViMa ...... 3
1.2. Magerit ...... 5
1.3. Necesidades que cubre el proyecto ...... 6
1.4. Objetivos ...... 6
1.5. Estructura de la Memoria ...... 7
– V – Indice´ general
PARTE IIESTADO DE LA CUESTION´
2. Desarrollo de un sistema software ...... 11
2.1. Ciclos de vida ...... 11
2.1.1. Ciclos de vida de referencia ...... 14
2.1.1.1. Secuencial o en cascada ...... 14
2.1.1.2. Prototipado ...... 15
2.1.1.3. Espiral ...... 15
2.2. Paradigmas ...... 17
2.2.1. Estructurado ...... 17
2.2.2. Orientado a objetos ...... 17
2.2.3. Agentes moviles´ ...... 19
2.2.4. Basado en el conocimiento ...... 19
3. El supercomputador Magerit ...... 21
3.1. BladeCenter JS20 y JS21 ...... 22
3.2. BladeCenters ...... 23
3.2.1. Management Module (MM) ...... 24
3.2.2. Modulos´ de entrada salida ...... 25
3.3. Servidores ...... 26
3.4. Almacenamiento ...... 27
3.4.1. General Parallel File Sistem (GPFS) ...... 28
3.5. Comunicaciones ...... 28
3.5.1. Gigabit Ethernet ...... 29
3.5.2. Myrinet ...... 30
3.6. Configuracion´ software ...... 31
3.7. Ejecucion´ de trabajos ...... 31
3.7.1. LoadLeveler ...... 32
3.8. Gestion´ ...... 32
– VI – Indice´ general
4. Magerit Monitor and Management System ...... 33
4.1. Filosof´ıa ...... 33
4.2. Arquitectura ...... 34
4.3. Diseno˜ ...... 35
4.3.1. Modelo vista controlador (MVC) ...... 35
4.3.2. Configuracion´ ...... 36
4.3.3. Base de datos ...... 36
4.4. Normativas ...... 36
4.4.1. Documentacion´ ...... 37
4.4.2. Codificacion´ ...... 37
4.4.3. Gestion´ de versiones ...... 38
4.5. Tecnolog´ıas ...... 38
4.5.1. PHP Hypertext Pre-processor (PHP) ...... 39
4.5.2. Zend Framework ...... 39
4.5.3. MySQL ...... 40
4.5.4. Subversion ...... 41
4.5.5. Eclipse ...... 41
PARTE IIIDESARROLLODELPROYECTO
5. Recuperacion´ Automatica´ ...... 45
5.1. Contexto ...... 45
5.2. Recuperacion´ manual ...... 47
5.3. Analisis´ inicial ...... 48
5.3.1. L´ımites ...... 48
5.3.2. Interaccion´ con el sistema ...... 49
5.3.3. Problemas ...... 49
5.3.4. Viabilidad ...... 51
5.3.5. Proceso de desarrollo ...... 52
– VII – Indice´ general
6. Recuperador Secuencial ...... 53
6.1. Requisitos ...... 53
6.2. Diseno˜ ...... 54
6.2.1. Proceso de recuperacion´ ...... 54
6.2.2. Modelo del dominio ...... 54
6.2.3. Acciones de Recuperacion´ ...... 55
6.3. Resultados ...... 59
7. Recuperador Paralelo ...... 61
7.1. Requisitos ...... 61
7.2. Diseno˜ ...... 62
7.2.1. Proceso de recuperacion´ ...... 62
7.2.2. Modelo del dominio ...... 63
7.2.3. Acciones de Recuperacion´ ...... 64
7.2.4. Hilos de ejecucion´ ...... 65
7.2.4.1. Hilo WatchDog ...... 66
7.2.4.2. Hilos Recoverer ...... 66
7.3. Resultados ...... 68
8. Recuperador Distribuido ...... 71
8.1. Requisitos ...... 71
8.2. Diseno˜ ...... 72
8.2.1. Proceso de recuperacion´ ...... 73
8.2.2. Modelo del dominio ...... 73
8.2.3. Acciones de Recuperacion´ ...... 74
8.2.4. Comunicacion´ entre recuperadores ...... 76
8.2.5. Informes efectivos ...... 78
8.3. Resultados ...... 79
9. Diseno˜ de un recuperador experto ...... 81
– VIII – Indice´ general
9.1. Justificacion´ del metodo´ elegido ...... 81
9.1.1. Justificacion´ de las tecnicas´ de representacion´ simbolica´ utilizadas . . . . . 83
9.2. Conclusiones ...... 85
PARTE IVCONCLUSIONESYL´INEASFUTURAS
10. Conclusiones ...... 89
10.1. Analisis´ de esfuerzo ...... 90
10.2. L´ıneas Futuras ...... 91
PARTE VANEXOS
A. Detalles del diseno˜ de un recuperador experto ...... 95
A.1. Descripcion´ del modelo ...... 95
A.1.1. Vocabulario conceptual: jerarqu´ıa de marcos ...... 95
A.1.1.1. Componentes hardware ...... 97
A.1.1.2. Maquinas´ ...... 100
A.1.1.3. Componentes Software ...... 102
A.1.2. Relaciones Efecto-Causa ...... 104
A.1.3. Diferenciacion´ ...... 105
A.1.3.1. Relaciones causa-efecto ...... 105
A.1.3.2. Conocimiento circunstancial ...... 106
A.1.3.3. Refino ...... 107
A.1.3.4. Cualificacion´ ...... 108
A.1.4. Estrategias de combinacion´ ...... 108
A.1.5. Producciones ...... 108
A.1.6. Prioridades ...... 109
A.1.7. Estrategias ...... 110
A.1.8. Acciones ...... 110
– IX – Indice´ general
A.1.9. Efectos ...... 110
A.2. Ejemplos de funcionamiento ...... 111
A.2.1. Ejemplo 1: Existen fallos graves ...... 111
A.2.2. Ejemplo 2: No hay fallos graves ...... 118
Bibliograf´ıa ...... 123
– X – Indice´ de figuras
1.1. El supercomputador Magerit ...... 5
2.1. Complejidad del universo software ...... 11
2.2. Clasificacion´ de la incertidumbre ...... 12
2.3. Ciclo de vida secuencial ...... 14
2.4. Ciclo de vida prototipado ...... 15
2.5. Ciclo de vida en espiral ...... 16
3.1. Diagrama de bloques de un nodo JS20 ...... 23
3.2. Esquema general del supercomputador ...... 24
3.3. Parte frontal de un BladeCenter ...... 25
3.4. Parte trasera de un BladeCenter ...... 26
3.5. Arquitectura de red de Magerit ...... 29
4.1. Modulos´ que forman el sistema Magerit Management and Monitoring System . . . . 34
4.2. Arquitectura del patron´ de diseno˜ MVC ...... 35
5.1. Sistemas necesarios para un blade operativo ...... 46
– XI – Indice´ de figuras
5.2. Casos de uso del recuperador automatico´ ...... 50
6.1. Diagrama de dominio del recuperador secuencial ...... 55
6.2. Diagrama de clases de los Recovers ...... 57
6.3. Diagrama de secuencia de una recuperacion´ fallida ...... 58
6.4. Diagrama de clases del patron´ Command ...... 59
6.5. Diagrama de clases del patron´ Composite ...... 60
7.1. Diagrama de dominio del recuperador paralelo ...... 63
7.2. Diagrama de clase del patron´ Memento ...... 67
7.3. Memento de ejemplo 1 ...... 68
7.4. Memento de ejemplo 2 ...... 68
8.1. Diagrama de dominio del recuperador distribuido ...... 73
8.2. Diagrama de clases de los Recovers en el recuperador distribuido ...... 75
8.3. Ejemplo de ejecucion´ de una Remote Procedure Call (RPC) ...... 77
8.4. Ejemplo del correo electronico´ enviado ...... 78
9.1. Arquitectura del metodo´ utilizado para el diagnostico´ y la recuperacion´ de fallos en Magerit 82
9.2. Estructura del metodo´ producir y ordenar ...... 83
9.3. Pasos de inferencia del metodo´ producir y ordenar ...... 84
A.1. Jerarqu´ıa de marcos del modelo ...... 96
A.2. Diagrama de diagnosticar en el ejemplo 1 ...... 114
A.3. Diagrama de priorizar en el ejemplo 1 ...... 115
A.4. Diagrama de reparar en el ejemplo 1 ...... 118
A.5. Diagrama de diagnosticar en el ejemplo 2 ...... 120
– XII – Indice´ de cuadros
1.1. Instituciones y maquinas´ que componen la Red Espanola˜ de Supercomputacion´ (RES) . 4
2.1. Clasificacion´ de los sistemas software ...... 12
2.2. Ciclos de vida segun´ la incertidumbre ...... 13
9.1. Roles dinamicos´ que intervienen en el metodo´ producir y ordenar ...... 84
10.1. Estimaciones de esfuerzo ...... 90
A.1. Descripcion´ del marco clase hardware ...... 97
A.2. Descripcion´ del marco clase hdd ...... 97
A.3. Descripcion´ del marco clase memoria ...... 98
A.4. Descripcion´ del marco clase myrinet ...... 98
A.5. Descripcion´ del marco clase planar ...... 99
A.6. Descripcion´ del marco clase red ...... 99
A.7. Descripcion´ del marco clase maquina´ ...... 100
A.8. Descripcion´ del marco clase switch ...... 100
A.9. Descripcion´ del marco clase servidor ...... 100
– XIII – Indice´ de cuadros
A.10.Descripcion´ del marco clase magerit ...... 100
A.11.Descripcion´ del marco clase blade ...... 101
A.12.Descripcion´ del marco clase software ...... 102
A.13.Descripcion´ del marco clase ssh ...... 102
A.14.Descripcion´ del marco clase loadl ...... 103
A.15.Descripcion´ del marco clase gpfs ...... 103
A.16.Descripcion´ del marco clase local-scratch ...... 103
A.17.Descripcion´ del marco clase central-manager ...... 104
– XIV – Acronimos´
ATA Advanced Technology Attachment
BSC Barcelona Supercomputing Center. Centro de Supercomputacion´ de Barcelona
CD-ROM Compact Disc Read Only Memory. Disco compacto de solo lectura
CeSViMa Centro de Supercomputacion´ y Visualizacion´ de Madrid. Mas´ informacion´ en la pagina´ 3
CIEMAT Centro de Investigaciones Energeticas,´ Medioambientales y Tecnologicas´
CLI Command Line Interface. Interfaz de l´ınea de comando
CPU Central Processing Unit. Unidad central de proceso
DDR Double Data Rate. Doble tasa de datos
DIM Diskless Image Management
FLOPS Floating Point Operations per Second.Numero´ de operaciones en coma flotante por segundo
Gbps Giga Bits per Second. Giga bits por segundo
GPFS General Parallel File Sistem. Sistema de ficheros paralelo general
HTTP HyperText Transfer Protocol. Protocolo de transferencia de hipertexto
HTTPS Secure HTTP. Protocolo de transferencia de hipertexto seguro
– XV – Acronimos´
IBM International Business Machines
IDE Integrated Drive Electronics. Dispositivo con electronica´ integrada
IP Internet Protocol
M3S Magerit Management Monitoring System. Sistema de gestion´ y monitorizacion´ de Magerit
Mbps Mega Bits per Second. Mega bits por segundo
MVC Modelo vista controlador
MM Management Module. Unidad de gestion´
NFS Network File System. Sistema de ficheros de red
OPM Optical Pass-thru Module.Modulo´ de conexion´ optica´
PC Program Counter. Contador de programa
PEAR PHP Extension and Application Repository. Repositorio de aplicaciones y extensiones de PHP
PHP PHP Hypertext Pre-processor. Acronimo´ recursivo de Preprocesador de Hipertexto PHP
POWER Performance Optimization With Enhanced RISC
RAID Redundant Array of Independent Drives. Conjunto redundante de discos independientes
RAM Random Access Memory. Memoria de acceso aleatorio
RES Red Espanola˜ de Supercomputacion´
RISC Reduced Instruction Set Computer. Computadora de juego de instrucciones reducido
RPC Remote Procedure Call. Llamada a procedimiento remoto rpms Revoluciones por minuto
SAPI Server Application Programming Interface. Interfaz de programacion´ de uso del servidor
SATA Serial Advanced Technology Attachment
SCM Sistemas de manejo de configuracion´ del software
SMTP Simple Mail Transport Protocol
SQL Structured Query Language. Lenguaje de consulta estructurado
– XVI – Acronimos´
SOAP Simple Object Access Protocol
SSH Secure Shell
UPM Universidad Politecnica´ de Madrid. Mas´ informacion´ en la pagina´ 3
UPS Uninterruptible Power Supply. Sistema de alimentacion´ ininterrumpida
USB Universal Serial Bus. Bus serie universal
W3C World Wide Web Consortium
XML eXtensible Markup Language
– XVII –
Parte I
Introduccion´ y objetivos
Cap´ıtulo 1
Introduccion´
En la actualidad, la necesidad de potencia de computo´ requerida por la comunidad cient´ıfica esta´ en constante aumento. Para satisfacer esta necesidad es necesario contar con computadores capaces de hacer estos complejos calculos´ a velocidades que permitan obtener resultados en tiempos razonables.
Para ello, la Universidad Politecnica´ de Madrid (UPM) cuenta con el mayor centro de supercompu- tacion´ de la Comunidad de Madrid: el Centro de Supercomputacion´ y Visualizacion´ de Madrid (CeSViMa). Este centro alberga y administra el supercomputador Magerit, el segundo mas´ potente de Espana.˜
1.1. CeSViMa
La UPM es fundada en 1971 agrupando las escuelas de ensenanzas˜ tecnicas,´ la ma- yor´ıa de estos centros fundados en los siglos XVIII y XIX, ya existentes en Madrid. De todos los estudios que hoy forman la UPM, los primeros en iniciar su andadura fueron los de arquitectura mientras que la escuela mas´ recientemente incorporada es la Facultad de Informatica.´
A finales del ano˜ 2004, la UPM y el Centro de Investigaciones Energeticas,´ Medioambientales y Tec- nologicas´ (CIEMAT) decidieron aunar esfuerzos para crear el CeSViMa. Este centro nace con el objetivo dotar a la Comunidad de Madrid de una infraestructura capaz de dar soporte a sus investigadores. Situa- do en el Parque Cient´ıfico y Tecnologico´ de Montegancedo, se centra en el almacenamiento masivo de informacion,´ computacion´ de altas prestaciones y visualizacion´ interactiva avanzada. Poco despues,´ un segundo acuerdo entre la UPM e International Business Machines (IBM), dota al CeSViMa del segundo su-
– 3 – Cap´ıtulo 1. Introduccion´ percomputador mas´ potente de Espana˜ (Magerit). Tambien´ se dota al centro de una sala de visualizacion´ 3D interactiva y de un escaner´ terrestre.
Ante la necesidad de aumentar la capacidad de calculo´ que da servicio a la comunidad cient´ıfica, se inauguro´ en marzo de 2007 la Red Espanola˜ de Super- computacion´ (RES), auspiciada por el Ministerio de Educacion´ y Ciencia. Fue en- tonces cuando se procedio´ a realizar una actualizacion´ del supercomputador Ma- reNostrum situado en el Barcelona Supercomputing Center (BSC), en la cual se sustituyeron los blades JS20 por blades JS21, ambos de IBM, con lo que se duplico´ su capacidad de computo.´ La mitad de dichos blades se utilizo´ para ampliar Magerit y el resto se repartio,´ a partes iguales, para crear una estructura distribuida de Supercomputadores en diferentes emplazamientos de la geograf´ıa espanola.˜ En Junio de 2008 finaliza una segunda ampliacion´ de Magerit que termina con la sustitucion´ de 168 de los blades JS20 por JS21. En el momento de escribir estas l´ıneas la RES presenta la configuracion´ que se describe en la Tabla 1.1.
Nodo Maquina´ Blade No blades Procesadores Potencia (TFLOPS)
Barcelona MareNostrum JS21 2.560 10.240 62,0 Madrid Magerit JS20/JS21 1.204 2.744 16,0 Cantabria Altamira JS20 256 512 4,5 Canarias LaPalma JS20 256 512 4,5 Malaga´ Picasso JS20 256 512 4,5 Valencia Tirant JS20 256 512 4,5 Zaragoza CaesarAugusta JS20 256 512 4,5
Cuadro 1.1: Instituciones y maquinas´ que componen la RES
El acceso al servicio se gestiona mediante un comite´ de acceso, integrado por cient´ıficos encargados de valorar cada una de las solicitudes de acceso y planificar el acceso a los recursos disponibles. Los recursos se asignan por un periodo de 4 meses, tras lo cual es necesario presentar una nueva solicitud de acceso.
Cada uno de los centros gestiona internamente los proyectos y grupos que le son asignados en cada periodo por el comite´ de acceso. Ademas,´ cada uno de los centros dispone de un 20 % del uso de los recursos. Este reparto no es as´ı para el CeSViMa, el cual tiene acceso al 40 % de la maquina,´ ya que, cuando se inauguro´ la RES, el CeSViMa ya contaba con un supercomputador en propiedad, cuyos nodos no proceden del MareNostrum.
– 4 – 1.2. Magerit
1.2. Magerit
Magerit esta´ compuesto por 1036 nodos eServer BladeCenter JS20 cada uno de los cuales dispone de 2 procesadores PPC de 2’2 GHz con 4 GB de RAM, as´ı como 168 nodos eServer BladeCenter JS21 con 4 procesadores PPC 2’3GHz con 8GB de RAM. Para su interconexion´ se utiliza una red Myrinet de fibra optica´ de altas prestaciones junto con redes auxiliares Gigabit para su control y gestion.´
El sistema dispone de una capacidad de almacenamiento local de unos 192 TB, proporcionado por 256 discos de 750 GB, que utiliza un sistema distribuido y tolerante a fallos.
La conexion´ exterior se realiza a traves´ de RedIRIS mediante enlaces de 1Gb y 10 Gb.
Figura 1.1: El supercomputador Magerit
Esta´ ubicado en una sala acondicionada especialmente para su uso, la cual tambien´ debe estar en perfectas condiciones para el correcto funcionamiento del sistema. Esta sala cuenta con maquinas´ de re- frigeracion´ exclusivas, sistemas de deteccion´ y extincion´ de incendios, sistemas de deteccion´ de l´ıquidos, sistemas de alimentacion´ ininterrumpida, etc.
Debido a sus dimensiones, el sistema esta´ configurado para procesar paquetes de trabajos en modo batch. Para ello se utiliza un gestor de colas que planifica los distintos trabajos con el doble objetivo de
– 5 – Cap´ıtulo 1. Introduccion´ maximizar el uso de la potencia del computador y procesar los trabajos de los distintos usuarios de la forma mas´ rapida´ posible.
1.3. Necesidades que cubre el proyecto
Magerit es el segundo computador mas´ potente de Espana,˜ en el que actualmente estan´ ejecutando 24 horas al d´ıa proyectos de mas´ de 200 usuarios y alrededor de 80 grupos de investigacion.´ Por lo tanto es una maquina´ necesariamente de alta disponibilidad que debe ser lo mas´ estable posible para que los cient´ıficos puedan ejecutar sus calculos´ sin problemas.
Para ilustrar la importancia del buen funcionamiento de esta maquina´ se puede resenar˜ que un d´ıa de parada de la misma es equivalente a la perdida´ de 3,75 anos˜ de ejecucion´ en una maquina´ biprocesador de las que actualmente se utilizan para los ordenadores de sobremesa. Otro dato significativo es que si fallan un 2 % de los nodos de computo´ un determinado d´ıa, ese d´ıa se habran´ perdido el equivalente a 24 d´ıas de trabajo en el mismo ordenador de referencia.
Cada uno de los nodos que integran Magerit es equivalente a un ordenador personal, en los que puede fallar cualquier componente hardware o software. El equipo de administracion´ de CeSViMa trabaja para que todos los sistemas que forman parte del cluster funcionen a pleno rendimiento durante veinticuatro horas al d´ıa los trescientos sesenta y cinco d´ıas del ano.˜ Lograr este resultado es una tarea realmente complicada si tenemos en cuenta que revisar todos los nodos cada d´ıa en busca de aver´ıas y repararlos, no es una tarea sencilla. Ademas´ precisar´ıa del trabajo de entre cinco y siete personas dedicadas en exclusiva a esta labor que, en el mejor de los casos, solo´ podr´ıan revisar una o dos veces el buen funcionamiento de todos los nodos, eso sin tener en cuenta el tiempo que se necesita para arreglar o detectar las aver´ıas que pueden darse en cada maquina.´
Pese a la potencia hardware de dicho equipo, viene acompanado˜ de solo´ unas pocas herramientas de gestion´ y administracion´ del sistema. El equipo de CeSViMa detecto´ esta deficiencia y comenzo´ el proyecto Magerit Management Monitoring System (M3S) que consiste en el desarrollo de un conjunto de herramientas que simplifican la gestion´ del supercomputador Magerit. Mi trabajo se enmarca dentro del M3S y consiste en un modulo´ de recuperacion´ automatica´ de nodos.
1.4. Objetivos
Este proyecto tiene como objetivo principal el diseno,˜ implementacion´ e implantacion´ de un sistema software que facilite la reparacion´ de aver´ıas en los nodos de computo´ de Magerit.
El sistema debera´ ser capaz de:
– 6 – 1.5. Estructura de la Memoria
Comprobar periodicamente´ el estado de los nodos de computo´ del supercomputador.
En caso de detectar alguna incidencia, realizar una serie de tareas predefinidas para intentar sub- sanarla de forma automatica.´
Avisar de la incidencias detectadas.
Comunicar las acciones que ha llevado a cabo para intentar solucionar las incidencias encontradas.
Generar un registro de actuaciones realizadas.
Ser deshabilitado inmediatamente a voluntad de los administradores para que no interfiera en las labores de estos.
Ser habilitado en cualquier momento para que continue´ con sus funciones.
Ser suficientemente rapido´ para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.
Ejecutar sin interferir en los calculos´ de los usuarios.
Ejecutar sobrecargando el sistema lo menos posible.
1.5. Estructura de la Memoria
Este documento se compone de tres partes fundamentales que se centran en conocimientos necesarios para entender el proyecto, la descripcion´ del proyecto en s´ı y las conclusiones alcanzadas al termino´ del proyecto.
En la parte del estado de la cuestion´ se explican los ciclos de vida y las metodolog´ıas que han sido estudiadas para la realizacion´ del proyecto, la arquitectura de Magerit tanto hardware como software y el proyecto Magerit Management Monitoring System (M3S) donde se enmarca mi trabajo.
En la parte del desarrollo del proyecto se describe todo el contexto de la recuperacion´ automatica´ y las fases por las que ha pasado el proyecto. En todo este bloque se hace inca pie´ en las decisiones de diseno˜ y los problemas que se han ido dando a lo largo del desarrollo.
La ultima´ parte expone las conclusiones alcanzadas as´ı como las l´ıneas futuras del proyecto.
Por ultimo,´ se incluye un apendice´ que describe el estudio de una solucion´ alternativa para el mismo problema.
– 7 –
Parte II
Estado de la cuestion´
Cap´ıtulo 2
Desarrollo de un sistema software
Este cap´ıtulo describe los ciclos de vida y paradigmas que se han estudiado para seguir durante el desarrollo de este proyecto. Algunos de ellos han sido puestos en practica´ en detrimento de otros. A lo largo de esta memoria se argumentan las decisiones tomadas.
2.1. Ciclos de vida
El ciclo de vida determina las fases que deben llevarse a cabo para la realizacion´ del proyecto desde que se plantea el problema (habitualmente por parte del cliente) hasta que es resuelto por un sistema informatico.´ El ciclo de vida suele elegirse en funcion´ de la complejidad del sistema a desarrollar.
La complejidad de un sistema software es la composicion´ de la complejidad descriptiva (cantidad de informacion´ para describir el sistema) y la complejidad por incertidumbre (cantidad de informacion´ necesaria para resolver cualquier incertidumbre asociada con el sistema) [18].
Figura 2.1: Complejidad del universo software
– 11 – Cap´ıtulo 4
Ciclo de Vida
Cap´ıtulo 2. Desarrollo de un sistema software El ciclo de vida determina las fases que deben llevarse a cabo para la realizacion´ del proyecto desde que se planteaEs normal el problema que cuando (habitualmente crece el tamano˜ de por un parte proyecto del tambi cliente)en´ crezca hasta la que incertidumbre es resuelto sobre por este, un ya sistema informseaatico.´ porque Los se ciclos incluyen de conceptos vida suelen ambiguos asociarse o por simple al proceso vaguedad de adesarrollo la hora de definir software los requisitos. pero, debido Es a la evoluciporon´ esto de los que sistemas a la hora deinform decidiraticos,´ el ciclo actualmente de vida a utilizar tienden sea am aplicarseas´ acertado a fijarnos todo el en proceso la incertidumbre del desarrollo informqueatico.´ alberga Existen el proyecto multiples´ que enciclos sus l´ıneas de vida de c queodigo.´ abarcan diversos problemas segun´ sus caracter´ısticas. Por ello tambiExistenen´ m existenultiples´ diversas ciclos de clasificaciones, vida que abarcan diversos siendo una problemas de las seg posiblesun´ sus caracter la clasificaci´ısticas.on´ Una por posi- el grado de incertidumbreble clasificaci queon´ es admiten. segun´ el grado de incertidumbre que admiten.
A náli n ó sis de riesgos
ficaci Segundo ciclo lani P Primer ciclo
Esencia
E val ía uación Fases
Ingenier
Cascada Espiral Búsqueda
- Grado de incertidumbre +
Tamaño pequeño Tamaño medio. Problema prácticamente Problema claramente definido. Problema mal definido. indefinido Requisitos estables Requisitos variables Imposible generar requisitos. Experiencia del equipo de Experiencia insuficiente del No existen referencias similares. desarrollo en las técnicas equipo de desarrollo.
Figura 2.2: Clasificacion´ de la incertidumbre Figura 4.1: Clasificacion´ de la incertidumbre
Los ciclos de vida comprenden desde el modelo en el que el problema esta´ completamente definido Los ciclos de vida comprenden desde el modelo en el que el problema esta´ completamente definido de forma estable (incertidumbre m´ınima) al desconocimiento del problema y de la forma de obtener la de forma estable (incertidumbre m´ınima) al desconocimiento del problema y de la forma de obtener solucion´ (incertidumbre maxima).´ La mayor´ıa de los problemas se encuentran en un punto intermedio. la solucion´ (incerti-dumbre maxima),´ aunque la mayor´ıa de los problemas se encuentran en un punto Cuanto menor sea la incertidumbre, el problema sera´ mas´ sencillo de resolver y, por tanto, su ciclo de
vida sera´ mas´ directo y viceversa. – 31 – Los sistemas software se pueden clasificar segun´ su incertidumbre como muestra la Tabla 2.1. [17]
Problema Solucion´ Tipo
Muy conocido y estable Muy conocida y estable S Muy conocido y estable No muy conocida e inestable P No muy conocido e inestable No muy conocida e inestable E
Cuadro 2.1: Clasificacion´ de los sistemas software
Esta clasificacion´ determina en gran medida la incertidumbre que alberga un sistema:
– 12 – 2.1. Ciclos de vida
Escasa incertidumbre (S): Se trata de problemas completamente definidos en los que no existen nece- sidades variables por parte del cliente (por lo que es posible fijar unos requisitos estables) y el equipo de desarrollo tiene experiencia en sistemas similares.
Incertidumbre media (P): Los problemas de este tipo se caracterizan por necesidades variables por par- te del cliente o escasa experiencia del equipo de desarrollo en sistemas similares o en las tecnicas´ a emplear. Esta indeterminacion´ puede producir cambios introducidos por el cliente o durante el descubrimiento de las tecnicas.´
Alta incertidumbre (E): Se trata de sistemas muy poco definidos con necesidades incompletas o sin experiencia por parte del equipo de desarrollo. En estos casos es necesario realizar un proceso de busqueda´ (dirigida o no) de la solucion.´
Incertidumbre Ciclos de vida
Escasa (S) Ciclo de vida secuencial o en cascada
Media (P) Prototipos
Espiral de Bohem
• Incremental
• Evolutivo
Alta (E) Espiral de Bohem
• Evolutivo
Busqueda´
Cuadro 2.2: Ciclos de vida segun´ la incertidumbre
A continuacion´ se va a hacer un estudio de los ciclos de vida de referencia mas´ usuales, mas´ adelante se argumenta la eleccion´ final realizada.
– 13 – Cap´ıtulo 2. Desarrollo de un sistema software
2.1.1. Ciclos de vida de referencia
En la Figura 2.2 se plantean los ciclos de vida mas´ usuales que mejor se adaptan a las caracter´ısticas del sistema a desarrollar.
2.1.1.1. Secuencial o en cascada
Se trata de la primera formalizacion´ del proceso de desarrollo software propuesta por Royce [25], introduciendo una cierta disciplina en la ingenier´ıa del software que permite corregir algunas deficiencias como la pronta codificacion´ sin analisis´ y diseno.˜
Figura 2.3: Ciclo de vida secuencial
Modela el ciclo de vida clasico´ (ingenier´ıa del sistema, analisis,´ diseno,˜ codificacion,´ pruebas y mantenimiento) con un enfoque secuencial en el que cada fase es completamente finalizada antes de comenzar la siguiente. Esto es posible unicamente´ si el problema esta´ muy definido y es estable desde el principio, es decir, hay escasa incertidumbre. Debido a la evolucion´ de las tecnolog´ıas y el mayor tamano˜ de los proyectos junto a la aparicion´ de requisitos variables, se introduce una re-alimentacion´ al finalizar cada fase que palia levemente los problemas del ciclo de vida secuencial en estas circunstancias. A pesar de la re-alimentacion,´ el ciclo de vida es bastante r´ıgido, siendo muy complicado introducir cambios de forma sencilla en el sistema.
– 14 – 2.1. Ciclos de vida
2.1.1.2. Prototipado
El prototipado [11], surge como respuesta a los requisitos variables producidos por la existencia de partes mal definidas o mal comprendidas. Para esas partes se construye un prototipo, que puede ser en papel o computadora, centrado en la interfaz hombre-sistema, en alguna funcionalidad o bien puede simular una parte del sistema real y de esta manera comprobar la adecuacion´ al cliente.
Figura 2.4: Ciclo de vida prototipado
Una variacion´ de este ciclo de vida es el prototipado rapido,´ en el cual se crea un primer prototipo que es utilizado en las primeras fases para analizar las necesidades del cliente y extraer de esta forma los requisitos de partes no definidas. Es deseable poder evolucionar este primer prototipo para generar el sistema final, aunque no siempre es posible o rentable. El uso de prototipos se ha incluido como una fase mas´ en otros ciclos de vida. Esta tecnica,´ como herramienta de analisis,´ es muy aconsejable para evitar el rechazo del cliente o cuando la interfaz de usuario sea una parte muy importante del sistema.
2.1.1.3. Espiral
El ciclo de vida en espiral [2], se basa en sucesivos ciclos de experimentacion´ y aprendizaje, a traves´ de los cuales se incrementa la funcionalidad, dando lugar a sucesivas versiones del software cada vez mas´ completas.
La primera iteracion´ se centra en la parte fundamental del sistema y las sucesivas iteraciones cons- truyen el sistema, sobre la base formada por los ciclos previos, de forma incremental. En cada ciclo se plantean cuatro fases (planificacion,´ analisis´ de riesgos, ingenier´ıa y evaluacion)´ que recubren e incre- mentan las tradicionales. Al incluir en cada ciclo el analisis´ de riesgos y la evaluacion´ junto al desarrollo
– 15 – Cap´ıtulo 2. Desarrollo de un sistema software
Figura 2.5: Ciclo de vida en espiral incremental, es posible responder a los distintos riesgos que plantea la existencia de incertidumbre en los desarrollos tomando las acciones correctoras necesarias.
Basandose´ en este esquema de sucesivas iteraciones surgen dos modelos:
Incremental: Debido a las necesidades variables, el problema no se trata como un todo, sino que se realiza el desarrollo completo de un subconjunto y seguidamente se construye sobre este otro subconjunto, incrementando as´ı el sistema.
Evolutivo: Al igual que el incremental, se plantea un desarrollo por fases, pero en este caso variando lo realizado, mientras que crece poco a poco hasta lograr el sistema requerido. Su mayor incon- veniente es que se plantea desde un inicio la modificacion´ de lo realizado en las primeras fases. El ciclo de vida evolutivo permite un desarrollo mas´ flexible que el incremental, puesto que per- mite realizar una busqueda´ de la solucion´ retractandose´ (modificando) cuando se detecta una gran desviacion´ entre el sistema desarrollado y el requerido.
Un enfoque erroneo´ del desarrollo en espiral es considerar que cada ciclo equivale a una cascada. La cascada avanza todo el desarrollo, por lo que es imposible realizar ajustes correctivos puesto que ya ha sido desarrollada toda la fase para todo el sistema. La espiral por su parte solo realiza una parte del sistema, que puede incluso no ser ninguna actividad de ingenier´ıa de software, como aprender nuevas tecnicas.´
– 16 – 2.2. Paradigmas
2.2. Paradigmas
Un paradigma de programacion´ es una coleccion´ de modelos conceptuales que juntos modelan el proceso de construccion´ de un programa y determinan, al final, su estructura [1]. Esa estructura concep- tual de modelos esta´ pensada de forma que esos modelos determinan la forma correcta de los programas y controlan el modo en que pensamos y formulamos soluciones.
Existen muchos paradigmas de programacion´ y no hay uno mejor que los demas´ sino que hay situa- ciones en las que un paradigma resulta mas´ apropiado.
A continuacion´ se describen los paradigmas de programacion´ que estan´ relacionados con el proyecto. Algunos han sido puestos en practica´ mientras que otros solamente han sido estudiados para su uso y posteriormente descartados.
2.2.1. Estructurado
La idea original del diseno˜ estructurado fue presentada en la decada´ de los 70, por Larry Constantine [6]. El diseno˜ estructurado enfoca el problema a traves´ del flujo de datos que lo describe, es decir, describe el problema como una serie de datos de entrada que sufren diversas transformaciones como consecuencia de la accion´ de diferentes procesos. Como consecuencia, se obtienen unos flujos de salida que llegan a los receptores de la informacion.´
El diseno˜ estructurado permite que el problema gu´ıe a la solucion.´ Ayuda a resolver la compleji- dad de los grandes sistemas a traves´ de la estructuracion´ de estos en cajas negras, y su organizacion´ en una jerarqu´ıa apropiada para su posterior implementacion.´ Ofrece tambien´ un conjunto de criterios para evaluar la calidad de un diseno˜ con respecto al problema que pretende resolver. Utiliza tecnicas´ y herramientas, fundamentalmente graficas,´ para realizar disenos˜ de facil´ comprension,´ basandose´ es una serie de notaciones bastante conocidas como son los diagramas de flujo de datos (DFD), el diagrama entidad/relacion´ (E/R), etc.
Resumiendo, mediante el diseno˜ estructurado se crea una jerarqu´ıa de modulos´ para implantar las especificaciones obtenidas en la fase de analisis.´
2.2.2. Orientado a objetos
Segun´ el paradigma de la programacion´ orientado a objetos un programa es un conjunto de objetos interrelacionados, que trabajan conjuntamente en la resolucion´ de un problema, enviandose´ mensajes unos a otros. Cada objeto es una instancia de una clase, que puede definirse de forma informal como un conjunto de objetos de caracter´ısticas similares.
– 17 – Cap´ıtulo 2. Desarrollo de un sistema software
La programacion´ orientada a objetos ofrece caracter´ısticas que flexibilizan los disenos˜ y aumentan la reutilizacion´ de codigo:´
Abstraccion:´ Cada objeto en el sistema sirve como modelo de un agente abstracto que puede realizar trabajo, informar y cambiar su estado, y comunicarse con otros objetos en el sistema sin revelar como´ se implementan estas caracter´ısticas. Los procesos, las funciones o los metodos´ pueden tambien´ ser abstra´ıdos y cuando lo estan,´ una variedad de tecnicas´ son requeridas para ampliar una abstraccion.´
Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstraccion.´ Esto permite aumentar la cohesion´ de los com- ponentes del sistema. Algunos autores confunden este concepto con el principio de ocultacion,´ principalmente porque se suelen emplear conjuntamente.
Principio de ocultacion:´ Cada objeto esta´ aislado del exterior, es un modulo´ natural, y cada tipo de ob- jeto expone una interfaz a otros objetos que especifica como´ pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificacion´ por quien no tenga derecho a acceder a ellas, solamente los propios metodos´ internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos len- guajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstraccion.´
Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizara´ el comportamiento correspondiente al objeto que se este´ usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocacion´ de un comportamiento en una referencia producira´ el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en tiempo de ejecucion,´ esta ultima´ caracter´ıstica se llama asignacion´ tard´ıa o asignacion´ dinamica.´ Algunos lenguajes proporcionan medios mas´ estaticos´ (en ”tiempo de compilacion”)´ de polimorfismo, tales como las plantillas y la sobrecarga de operadores.
Herencia: las clases no estan´ aisladas, sino que se relacionan entre s´ı, formando una jerarqu´ıa de cla- sificacion.´ Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir (y extender) su comportamiento sin tener que volver a implementarlo. Esto suele hacer- se habitualmente agrupando los objetos en clases y estas en arboles´ o enrejados que reflejan un
– 18 – 2.2. Paradigmas
comportamiento comun.´ Cuando un objeto hereda de mas´ de una clase se dice que hay herencia multiple.´
Mientras que en la programacion´ estructurada solo´ se escriben funciones que procesan datos, los programadores que emplean este´ paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitandoles´ que realicen sus metodos´ por s´ı mismos, delegando la responsabilidad a su vez en otros objetos si es necesario.
2.2.3. Agentes moviles´
Los agentes moviles´ basan su filosof´ıa en mover el codigo´ a los datos en vez de los datos al codigo´ . Representan un nuevo paradigma de programacion´ en el desarrollo de aplicaciones en red. En determi- nadas aplicaciones distribuidas representan la solucion´ ideal para el diseno,˜ implementacion´ y manteni- miento de las mismas mediante una delegacion´ de tareas que requiere la visita de diversas plataformas o entornos de ejecucion´ por red. Este paradigma permite:
La reduccion´ de la carga de trafico´ por la red ya que se eliminan todos los mensajes t´ıpicos de los procedimientos cliente-servidor. Ademas´ se mueve el codigo´ hacia los datos y es que normalmente pesa menos el codigo´ que los datos que hay que procesar.
La mejora de la latencia de la red o tiempo de respuesta desde que se realiza una solicitud hasta que se recibe el resultado pedido. Este tiempo es especialmente cr´ıtico en redes de gran tamano˜ como Internet.
La eliminacion´ de potenciales limitaciones f´ısicas en la maquina´ cliente, derivando las operaciones no realizables por la maquina´ local a otra maquina´ que s´ı sea capaz de realizarlas.
El rapido´ despliegue de aplicaciones. Una vez montadas las agencias de agentes (entornos de ejecucion´ de los agentes) en las maquinas´ que van a formar la red solo´ hace falta crear los agentes en alguna agencia y dejar que migren a su gusto.
Todas estas caracter´ısticas han alentado mucha investigacion´ sobre este paradigma, pero por ser muy reciente no existen demasiadas plataformas de desarrollo y ademas´ las existentes no se encuentran en un estado del todo maduro.
2.2.4. Basado en el conocimiento
La construccion´ de sistemas de la informacion´ se ha basado de forma tradicional en un enfoque de proceso de datos siguiendo diversos paradigmas de organizacion´ del software que han evolucionado
– 19 – Cap´ıtulo 2. Desarrollo de un sistema software desde las primeras propuestas de programacion´ estructuradas a los mas´ recientes enfoques (orientacion´ a objetos, agentes software, etc). Por otra parte, en el campo de la inteligencia artificial se han desarrollado tecnicas´ de representacion´ del conocimiento y metodos´ de resolucion´ de problemas que han permitido plantear la arquitectura basada en el conocimiento. Estos sistemas basados en el conocimiento (tambien´ sistemas expertos) se caracterizan porque:
Simulan la forma natural de resolver problemas observada en las personas.
Encuentra la solucion´ del problema mediante un proceso de busqueda´ dirigida por criterios es- pec´ıficos de un dominio.
Este paradigma da como resultado metodos´ de resolucion´ de problemas formalizados como con- juntos de inferencias que resuelven los problemas utilizando el conocimiento almacenado en bases de conocimiento.
Las inferencias se suelen basar en procesos de busqueda´ t´ıpicos de la inteligencia artificial. El cono- cimiento suele estar representado de forma descriptiva con tecnicas´ de inteligencia artificial como reglas, marcos, restricciones, redes bayesianas o logica´ difusa entre otras. Este conocimiento esta´ estructurado en clases que son el resultado de un analisis´ detenido del conocimiento requerido para resolver un pro- blema. Estas clases van desde el conocimiento propio de un dominio pasando por el conocimiento sacado de la practica´ de los expertos hasta el conocimiento de control, que determina cual´ es el siguiente paso a dar dentro de un proceso de busqueda.´
Estas son algunas de las ventajas que proporcionan los sistemas expertos:
Alta reusabilidad de las bases de conocimiento, por ejemplo los conocimientos propios del un dominio concreto se pueden usar siempre que uno trate de realizar un sistema experto para resolver problemas del mismo dominio.
Mucha flexibilidad para ser modificados o ampliados ya que el conocimiento se encuentra forma- lizado de manera declarativa y esta´ desligado de cualquier inferencia.
Mucha capacidad para resolver problemas que no estan´ completamente definidos o que necesitan modelar la heur´ıstica propia de la experiencia de los profesionales en el campo.
Son sistemas muy intuitivos de utilizar para el usuario ya que su interfaz suele estar basada en lenguaje natural.
Tienen una arquitectura que facilita el aprendizaje por parte del sistema mediante la obtencion´ de nuevo conocimiento que engordara´ las bases de conocimiento ya utilizadas.
– 20 – Cap´ıtulo 3
El supercomputador Magerit
Magerit es un cluster´ formado por 1204 nodos de computo.´ Cada uno de estos nodos es un ordenador estandar de 64 bits adaptado para sistemas de alta densidad, es decir, gran cantidad cantidad de nodos en un espacio reducido.
Estos nodos se organizan en grupos de 14 unidades para ser insertados en los llamados BladeCenters. Los nodos que pertenecen a un BladeCenter comparten los switch de comunicaciones, de control y la alimentacion´ aunque son maquinas´ completamente individuales.
Ademas´ de la capacidad de almacenamiento local de cada nodo, se dispone de 192TB de almace- namiento principal proporcionado por 266 discos de 750GB en Redundant Array of Independent Dri- ves (RAID). Sobre estos discos se utiliza un sistema de ficheros GPFS accesible desde cualquier nodo.
Tambien´ se dispone de un total de 19 servidores IBM pSeries. Estos servidores realizan los accesos al sistema de almacenamiento en disco y proporcionan la imagen del sistema operativo, durante la secuencia de arranque, a cada uno de los nodos de computo´ que tienen a su cargo. 17 de estos servidores son IBM p5 510, mientras que los 2 restantes son IBM p4. El sistema de ficheros GPFS es servido por una serie de servidores IBM Power5 y Power4. Ademas´ de servir y controlar el sistema GPFS tambien´ proporcionan las imagenes´ de los blades que tienen a su cargo.
La interconexion´ entre los distintos componentes del sistema, tanto nodos como servidores, se lleva a cabo mediante tres redes diferentes.
Dos redes Gigabit Ethernet para el trafico´ del sistema de ficheros GPFS y las imagenes´ de los nodos as´ı como una red auxiliar de gestion.´
– 21 – Cap´ıtulo 3. El supercomputador Magerit
Una red Myrinet de alta velocidad dedicada exclusivamente al trafico´ de las aplicaciones de usua- rio. Es una red de muy baja latencia (alrededor de 2µs) y gran ancho de banda (2Gbps) lo que la hace ideal para trabajos en los que los nodos de computo´ deben pasarse datos entre ellos a gran velocidad, evitando as´ı esperas en los calculos.´
3.1. BladeCenter JS20 y JS21
En Magerit coexisten nodos eServer BladeCenter JS20 y eServer BladeCenter JS21, ambos de IBM con las siguientes caracter´ısticas:
Procesadores. Cada uno de los procesadores con que cuenta, 2 los JS20 y 4 los JS21, trabaja a una frecuencia de reloj de 2.2GHz los JS20 y 2.3GHz los JS21. Cada uno de ellos posee 32KB de cache´ de datos de nivel 1, 64KB de cache´ de instrucciones de nivel 1 y 512KB de cache´ de nivel 2.
Los procesadores estan´ interconectados con el resto del sistema mediante un interfaz dedicado para el controlador de memoria y para el puerto de entrada/salida. Este interfaz soporta un ancho de banda maximo´ agregado de 8.8GBps.
Memoria. El subsistema de memoria esta´ compuesto por el controlador de memoria y 4 modulos´ de memoria DDR1 333MHz (PC2700) cada uno de ellos de 1GB en los JS20 y 2GB en los JS21.
Entrada/Salida. El subsistema de entrada/salida esta´ conectado a los subsistemas de procesador y me- moria mediante un enlace que soporta un ancho de banda agregado de 1.6Giga Bits per Second (Gb- ps). El subsistema de entrada salida se divide en dos partes claramente diferentes:
Controlador Gigabit Ethernet. Cada nodo incluye un controlador Gigabit Ethernet Broadcom BCM 5704s, el cual provee del mecanismo primario para conectar al nodo al resto del sistema. Este controlador dota al nodo de dos interfaces independientes. Cada interfaz esta´ conectado a un modulo´ de entrada salida del BladeCenter por medio de los midplanes del mismo.
Tarjeta Myrinet. Cada nodo tiene conectada una tarjeta Myrinet de fibra optica.´ Esta tarjeta se usa para conectar el nodo a la red Myrinet de alta velocidad.
Controlador Integrated Drive Electronics (IDE). Cada nodo incluye un controlador IDE y dos conecto- res capaces de albergar discos duros IDE de 2,5 pulgadas.
En Magerit hay dos tipos de nodos con finalidades diferentes:
Login o interactivos. Son la puerta de acceso a Magerit. Cuando un usuario desea acceder a la maquina´ se conecta aleatoriamente a uno de estos nodos. Una vez dentro, las unicas´ operaciones permitidas
– 22 – The architecture of the BladeCenter JS20 is illustrated by the diagram in 3.2. BladeCenters Figure 2-7.
PowerPC PowerPC 970 970 BSMP or or 970FX 970FX
6.4 GBps 6.4 GBps or or 8.8 GBps 8.8 GBps 5.3 GBps Memory Controller and Host I/O Bridge PC2700 ECC (Northbridge) Memory Modules
1.6 GBps
Chassis 1.06 GBps Midplanes Gigabit Ethernet Controller HyperTransport PCI-X Tunnel 1.06 GBps Expansion Card
800 MBps
USB HyperTransport I/O Hub Controllers
IDE Controller
Boot FLASH
Super I/O
IDE IDE Real Time NVRAM UART Disk Disk Clock
Figure 2-7 BladeCenter JS20 block diagram
The BladeCenter JS20 includes both base features and a range of optional features.Figura We describe 3.1: eachDiagrama of these in de the bloques sections dethatun follow. nodo JS20
en ellos son las de edicion´ de documentos, compilacion,´ generacion´ de scripts, monitorizacion´ de
trabajos, etc. No esta´ permitida la ejecucion´ de c omputosChapter´ 2. Hardware paralelos components en estos 23 nodos y, si se detecta, esta´ sera´ automaticamente´ abortada.
Nodos de computo.´ Estos nodos estan´ dedicados exclusivamente a la ejecucion´ de trabajos de usuari, por lo que ningun´ usuario excepto los administradores tienen acceso a ellos. Cuando un usuario lanza un trabajo en un nodo interactivo, este´ pasa al sistema de colas que se encarga de analizar los recursos necesarios, los disponibles en la maquina´ y planificar su ejecucion´ en un subconjunto de nodos de computo.´ Una vez que el trabajo a finalizado, el nodo pasa a ejecutar el siguiente trabajo que le sea asignado por el planificador. Hay un total de 1190 nodos de computo.´
3.2. BladeCenters
Los BladeCentrers estan´ disenados˜ para instalarse en un rack estandar´ de 19 pulgadas. Cada uno de los BladeCenters ocupa 7 unidades del rack, por lo que se pueden instalar un maximo´ de 6 BladeCenters por rack.
– 23 – Cap´ıtulo 3. El supercomputador Magerit
Nodos interactivos (login)
login1 login2 login3 login4
Nodos de cómputo
Figura 3.2: Esquema general del supercomputador
En el frontal del BladeCenter se distinguen las catorce bah´ıas destinadas a alojar nodos y la bah´ıa multimedia, compuesta por un CD-ROM y un puerto USB, que puede asignarse a un unico´ blade.
En la parte trasera del BladeCenter se distinguen las siguientes partes:
Un Management Module (MM)
Dos parejas de fuentes de alimentacion´ redundantes de 2000W cada una
Dos ventiladores
Un switch Gigabit Ethernet
Un switch Myrinet Optical Pass-thru Module (OPM)
3.2.1. Management Module (MM)
El MM proporciona las funciones siguientes:
Configuracion´ inicial del BladeCenter
Definir y gestionar usuarios que pueden acceder remotamente a la unidad de gestion´
Apagar o encender nodos remotamente
– 24 – 2.1 Overview of the BladeCenter infrastructure
The BladeCenter JS20 is designed to be installed in the IBM ^ BladeCenter Type 8677. This section reviews the BladeCenter infrastructure that is relevant to the installation of the BladeCenter JS20.
2.1.1 BladeCenter chassis The core component of the BladeCenter infrastructure is the BladeCenter chassis. Figure 2-1 illustrates the front view of the BladeCenter chassis. The BladeCenter chassis is designed to be installed in an industry standard 19-inch rack. Each BladeCenter chassis occupies seven rack units. You can install up to six BladeCenter chassis in a single 42U rack such as the IBM NetBAY42 Enterprise Rack.
In the front view of the BladeCenter chassis, you see these standard features: Fourteen bays where you can install blade servers A media bay containing one CD-ROM drive, one diskette drive, and a 3.2. BladeCenters Universal Serial Bus (USB) port that can be dynamically assigned to any single blade server in the BladeCenter chassis
Figure 2-1 BladeCenter chassis front view
8 The IBM Eserver BladeCenterFigura JS20 3.3: Parte frontal de un BladeCenter
Asignar los interfaces de la bah´ıa multimedia a un determinado nodo
El MM esta´ conectado a cada uno de los nodos y a los interfaces de entrada salida por medio de buses que discurren a lo largo del midplane del BladeCenter.
El MM posee conectores por medio de los cuales se pueden conectar al mismo un teclado, raton´ y pantalla de una consola para gestionar el BladeCenter localmente.
Tambien´ se puede acceder a estas funciones por medio del interfaz de red de diversas formas:
Usando un navegador web (HTTP o HTTPS)
Por medio de la l´ınea de mandatos con un cliente telnet o SSH
3.2.2. Modulos´ de entrada salida
Los modulos´ de entrada salida permiten la comunicacion´ entre los nodos de un BladeCenter, entre BladeCenters y entre estos´ y el mundo exterior. Se pueden instalar un maximo´ de cuatro modulos´ de en- trada salida segun´ las necesidades. En Magerit, unicamente´ se utilizan dos: Switch Ethernet y el modulo´ OPM.
Los diferentes tipos de modulos´ de entrada salida, proporcionan conectividad con dos tipos de redes diferentes:
Redes de area´ local
– 25 – Figure 2-2 illustrates the rear view of the BladeCenter chassis. In the rear of the BladeCenter chassis, you see these standard features: One management module One bay where you can install an optional redundant Management Module Four bays where you can install optional input/output (I/O) modules A redundant pair of power supply modules Two bays where you can install an additional pair of redundant power supply Cap´ıtulo 3. El supercomputadormodules Magerit A redundant pair of blowers
Figure 2-2 BladeCenter chassis rear view
Figura 3.4: Parte trasera de un BladeCenter
Myrinet Chapter 2. Hardware components 9
En cada uno de los BladeCenters de Magerit hay instalado un modulo´ de cada uno de los tipos descritos anteriormente.
3.3. Servidores
Cada uno de los 19 servidores con los que cuenta Magerit dispone de cuatro microprocesadores POWER5 a 2GHz y 4GB de memoria RAM. Ademas´ tienen cuatro discos duros SATA, dos de 70GB y dos de 300GB. Uno de los discos de 70GB alberga el sistema operativo local del servidor, mientras que uno de los de 300GB esta´ dedicado exclusivamente a contener las imagenes´ del sistema operativo de los 70 nodos que tiene a su cargo. Estas imagenes´ son identicas´ y es el servidor el encargado de exportarlas mediante NFS. En el proceso de arranque de los nodos, estos´ piden la imagen del sistema operativo a su servidor y la montan adecuadamente.
Cada uno de ellos tambien´ tiene asignada la gestion´ de una parte del sistema de ficheros GPFS. Para que una parte del GPFS sea visible a toda la maquina,´ los servidores que se encargan de la gestion´ de esa parte deben haberla montado correctamente. Para realizar el acceso a disco a alta velocidad, cada uno de los servidores esta´ equipado con dos tarjetas de fibra optica´ dedicadas en exclusiva a esta labor.
– 26 – 3.4. Almacenamiento
Cuando un nodo desea acceder a disco, solicita la operacion´ a su servidor y sera´ este el encargado de realizar ese acceso, devolviendo los datos le´ıdos o el resultado de la escritura al nodo que lo solicito.´ En caso de que ese servidor no sea el que da acceso a esa parte del sistema de ficheros, pasara´ la informacion´ al servidor correspondiente que hara´ la operacion´ y retornara´ los datos correspondientes.
De los 19 servidores hay uno de ellos cuya configuracion´ es radicalmente distinta al resto. Es el engargado de centralizar la gestion´ de toda la maquina,´ entre la que se encuentra el gestor de colas en- cargado de la planificacion.´ Gracias a este servidor se facilitan enormemente las tareas de administracion´ de la maquina´ puesto que el´ dispone de acceso a todos los componentes que integran Magerit: nodos de computo,´ BladeCenters, servidores, switches de comunicaciones e, incluso, el sistema de refrigeracion´ de la sala. En este servidor estan´ alojadas las bases de datos de configuracion´ y de usuarios, la aplicacion´ que se ha desarrollado en este proyecto y otra serie de aplicaciones desarrolladas por el CeSViMa para la gestion´ y control de Magerit.
3.4. Almacenamiento
El sistema de almacenamiento de informacion´ principal de Magerit esta´ formado por 266 discos duros SATA de 750GB de capacidad a 7500 rpms, lo que proporcionan una capacidad bruta de 192TB.
Los discos son gestionados por Storage Managers DS4100 de IBM con 2 tarjetas de acceso de fibra optica.´ Cada uno de los Storage Manager tiene a su vez una expansion´ EXP100. Las expansiones no tienen tarjetas de fibra, pero estan´ conectados directamente a los Storage Manager por lo que en conjunto suman 28 discos. Estos sistemas estan´ disenados˜ para ofrecer una alta disponibilidad y ser tolerantes a fallos. Las principales caracter´ısticas que poseen son:
Controladoras RAID duales de alto rendimiento con puertos de 2Gbps
Soporte de RAID 5
512 MB de cache,´ 256 MB por controladora, con proteccion´ por bater´ıas de hasta 3 d´ıas de auto- nom´ıa
Fuentes de alimentacion´ redundantes
La configuracion´ logica´ de los discos dentro de un Storage Manager es la siguiente:
Los 28 discos disponibles en cada Storage Manager y expansion´ se dividen en cinco grupos de cinco discos sobre los que se crea un RAID5 de 1 TB de capacidad util.´ Los tres discos sobrantes se configuran como HotSpare, es decir, reemplaara´ a cualquier disco del array cuando este´ falle.
– 27 – Cap´ıtulo 3. El supercomputador Magerit
Consecuentemente, para perder los datos de un array de discos completo, es necesario que fallen los cinco discos del array en un breve lapso de tiempo.
Ademas´ del RAID5 y los discos de HotSpare, el acceso a todos los sistemas de ficheros de Magerit de forma paralela se realiza gracias a GPFS, un sistema de acceso paralelo y tolerante a fallos desarrollado por IBM.
3.4.1. General Parallel File Sistem (GPFS)
El sistema de ficheros GPFS es una solucion´ de gestion´ de discos compartidos de altas prestaciones que proporciona un acceso rapido´ y efectivo a la informacion´ almacenada en un cluster.
Este sistema de ficheros es tolerante a fallos y de acceso paralelo, lo que lo hace ideal para este tipo de maquinas´ en las pueden manejarse datos cr´ıticos que no sea recomendable perder por algun´ fallo. Ademas´ funciona muy bien con ficheros de grandes dimensiones, como pueden ser los generados por simulaciones biologicas´ o medicas.´
Magerit dispone de cuatro sistemas de ficheros, cada uno de ellos para distintos fines, que pasamos a describir:
/gpfs/home/ en el´ se encuentran los directorios personales de los usuarios. Este directorio se utiliza para almacenar el trabajo y datos personales de cada usuario. Tiene activado un sistema de cuotas que limita su uso a 10GB por usuario.
/gpfs/projects/ proporciona un espacio compartido por todos los miembros de un grupo de proyecto, por lo que se usa para almacenar los datos o codigo´ que sean usados por diferentes miembros de un mismo proyecto. Tambien´ tiene activado el sistema de cuotas, que dependera´ del espacio solicitado por el jefe de proyecto al hacer la peticion´ de recursos.
/gpfs/scratch/ es el espacio de almacenamiento masivo y temporal de la maquina.´ Cada usuario puede usar este espacio para almacenar la informacion´ necesaria durante la ejecucion´ de los trabajos. Tiene activado el sistema de cuotas, que depende de cada proyecto.
/gpfs/apps/ contiene las aplicaciones y bibliotecas instaladas en Magerit.
3.5. Comunicaciones
Para la interconexion´ de los diferentes componentes de Magerit se dispone de tres redes de comuni- caciones independientes: dos redes Gigabit Ethernet y una red Myrinet de fibra optica´ de alta velocidad.
– 28 – 3.5. Comunicaciones
El esquema general de la forma de interconectar las distintas redes de Magerit se puede apreciar en la Figura 3.5.
Switch Myrinet
Red Myrinet (10.11.0.0/16)
64 TB disco Nodos de proceso Nodos E/S (Interactivos)
Conexiones 1Gbps
Gigabit interna Gigabit IP Pública (10.12.0.0/16) (138.x.x.x)
Conexión externa (1Gbps)
UPM
Figura 3.5: Arquitectura de red de Magerit
Gracias a esta arquitectura de red, la parte de gestion´ de Magerit no influye en los calculos´ de los nodos y estos,´ a su vez, tampoco crean ningun´ problema sobre el trafico´ de datos.
3.5.1. Gigabit Ethernet
Magerit dispone de dos redes Gigabit Ethernet completamente independientes.
La red 10.12.0.0 es la que mas´ trafico´ soporta, ya que por ella circulan las imagenes´ del sistema ope- rativo que los servidores env´ıan a los nodos durante la secuencia de arranque de estos.´ Tambien´ circulan todos los datos que deben ser le´ıdos o escritos en el GPFS. Debido a la gran cantidad de ficheros a los que se accede simultaneamente´ y al tamano˜ medio de los mismos (varios GB usual- mente) el ancho de banda ocupado es muy alto. A esta red estan´ conectados tanto los servidores como los nodos de computo.´
– 29 – Cap´ıtulo 3. El supercomputador Magerit
La red 10.13.0.0 utilizada por el equipo de administracion´ de Magerit para realizar tareas de gestion´ de la maquina´ tales como acceso a los nodos v´ıa SSH, acceso al MM, acceso a los servidores, etc. A esta red estan´ conectados todos los servidores, as´ı como todos los BladeCenters. Los nodos de computo´ no estan´ directamente conectados a esta red, pero se puede acceder a ellos por medio de los MM de los BladeCenters. A esta red tambien´ estan´ conectadas las maquinas´ enfriadoras para poder monitorizarlas remotamente.
Para la interconexion´ de todos los elementos, Magerit cuenta con dos switches Gigabit Ethernet CIS- CO 6509 de altas prestaciones denominados switchA y switchB. Ambos switches estan´ interconectados entre ellos para que, accediendo desde el exterior, se pueda tener acceso a todos los elementos de la maquina.´
Cada uno de los switches cuenta con nueve tarjetas de 48 bocas de red para la conexion´ de todas las maquinas.´ El switchA, que da soporte a la red 10.12.0.0, ademas´ cuenta con una tarjeta de fibra optica´ que proporciona la red externa del centro. El switchB da soporte exclusivamente a las maquinas´ conectadas a la red 10.13.0.0.
Todos los elementos que deben tener una direccion´ IP externa, estan´ conectados a una tarjeta del switchA que tiene configuradas las direcciones IP publicas.´ A esta tarjeta estan´ conectados los nodos de login, los sistemas de seguridad de la sala, y la Uninterruptible Power Supply (UPS) para su monitoriza- cion´ externa.
3.5.2. Myrinet
Myrinet es una red disenada˜ para la interconexion´ de clusters de altas prestaciones. Sus productos han sido desarrollados por Myricom desde 1995, y desde entonces han ido mejorando en rendimiento, hasta obtener en la actualidad latencias de 3 µs y anchos de banda de 2Gbps, llegando incluso a alcanzar los 10Gbps. Una de sus principales caracter´ısticas, ademas´ de su rendimiento, es que el procesamiento de las comunicaciones de red se hace a traves´ de chips integrados en las tarjetas de red de Myrinet (Lanai chips), descargando a la CPU de parte del procesamiento de las comunicaciones.
Myrinet f´ısicamente consiste en dos cables de fibra optica,´ upstream y downstream, conectados con un unico´ conector. La interconexion´ se suele realizar mediante conmutadores y encaminadores. Estos dispositivos suelen tener capacidades de tolerancia a fallos, con control de flujo, control de errores y monitorizacion´ de la red. La primera generacion´ de productos Myrinet obten´ıa anchos de banda de 512 Mbps, la segunda de 1280 Mbps, Myrinet 2000 obtiene 2Gbps y la ultima,´ Myri-10G llega a los 10Gbps, y puede interoperar con 10Gb Ethernet.
– 30 – 3.6. Configuracion´ software
Las especiales caracter´ısticas de Myrinet hacen que sea altamente escalable, gracias a la tecnolog´ıa existente de conmutadores y routers, y su presencia en el tramo de clusters de gran tamano˜ es importante. Actualmente el 3,6 % de los clusters que aparecen en la lista TOP500 utilizan esta tecnolog´ıa.
En cuanto al middleware de comunicacion,´ la inmensa mayor´ıa esta´ desarrollado por Myricom. Des- tacan las librer´ıas a bajo nivel GM y MX, las implementacion´ de MPI MPICH-GM y MPICH-MX y las implementaciones de Sockets de alto rendimiento Socktes-GM y Sockets-MX.
Magerit cuenta con un total de seis switches Myrinet. Cinco de ellos son modelo M3-CLOS-ENCL. Cada uno de ellos cuenta con 16 tarjetas M3-SW32-16F de 16 bocas a las que se conectan todos los nodos de computo´ mediante cables de fibra optica.´ Tambien´ disponen de 4 tarjetas M3-4SW32-16Q de 16 bocas para la interconexion´ entre los switches. Para que todos los switches puedan transferirse datos entre ellos, se dispone de un switch trocal M3-SPINE-ENCL. Este switch dispone de 16 tarjetas M3-4SW32-16Q a las que se conectan el resto de switches.
3.6. Configuracion´ software
Todos los nodos de computo´ de Magerit usan el sistema operativo SusE SLES9 (Linux 2.6.5). En el proceso de arranque, cada uno de los nodos monta el sistema operativo mediante el protocolo Network File System (NFS).
Para que todos los nodos tengan una copia identica´ del sistema operativo, se dispone de un nodo con una configuracion´ diferente al resto. Este es el nodo llamado master. En el´ se halla la copia maestra del sistema operativo. Cada vez que es necesario hacer una modificacion´ que afecte a toda la maquina´ (nuevos usuarios, entradas en el crontab, etc.) se hace sobre la copia local de este nodo para despues´ sincronizar los cambios con el resto de las maquinas.´
Para hacer estas sincronizaciones se usa el paquete de herramientas Diskless Image Management (DIM). DIM es un paquete compuesto por una serie de scripts desarrollado por Peter Morjan con las cuales es posible gestionar las imagenes´ del sistema operativo desde una unica´ copia para despues´ sincronizarlo con el resto de imagenes´ que hay instaladas en los servidores de la maquina,´ para mantener la coherencia entre ellas.
3.7. Ejecucion´ de trabajos
En Magerit ejecutan trabajos batch. Para gestionar la ejecucion´ de estos trabajos es necesario dispo- ner de un gestor de colas que asigne los diferentes trabajos a las CPUs libres en un determinado momento. Este gestor de colas se denomina LoadLeveler.
– 31 – Cap´ıtulo 3. El supercomputador Magerit
3.7.1. LoadLeveler
LoadlLeveler es una aplicacion´ distribuida que se compone de:
Un Central Manager que ejecuta en el servidor de gestion,´ ver Seccion´ 3.3, y que gestiona las colas de trabajos, distribuyendo la carga entre los nodos que esten´ disponibles.
Un demonio Loadl corriendo en cada nodo de computo´ del cluster. Este demonio es el que se comunica con el Central Manager para transmitirle la disponibilidad del blade.
Este gestor de colas permite ejecutar trabajos secuenciales o paralelos en un cluster, reservando los recursos (nodos de computo)´ que necesitan los distintos trabajos. Este proceso de asignacion´ depen- dera´ de los recursos solicitados por el trabajo, la disponibilidad de dichos recursos en la maquina´ y las pol´ıticas de ejecucion´ que se hayan definido.
Para poder enviar un trabajo al supercomputador es necesario definirlo en un Job Command File es- pecificando los recursos que deben reservarse. LoadLeveler se encargara´ de buscar y reservar los recursos indicados entre los disponibles, optimizando el uso de la maquina´ y reduciendo el tiempo de espera de los distintos usuarios. En resumen, el gestor se encarga de maximizar la eficiencia del supercomputador.
3.8. Gestion´
El objetivo de los administradores de CeSViMa es que este conjunto heterogeneo´ de maquinas´ y pro- gramas software que forman Magerit este´ disponible para la comunidad cient´ıfica veinticuatro horas al d´ıa los trescientos sesenta y cinco d´ıas del ano.˜ Es frecuente que debido a errores de programacion´ o al uso exhaustivo que dan los programas de calculo´ cient´ıfico a los nodos de computo,´ estos´ dejen de estar operativos. Un nodo no operativo no es capaz de ejecutar los programas que se encuentren en la cola de trabajos ya sea porque esta´ apagado o porque el demonio Loadl, ver Subseccion´ 3.7.1, no esta´ corriendo adecuadamente en el nodo.
Ademas´ de eso los administradores deben preocuparse por gestionar las cuentas de usuario que dan acceso a la maquina,´ contabilizar y restringir las horas de ejecucion´ que cada grupo de investigacion´ consume o reparar las aver´ıas hardware o los fallos software que sucedan en Magerit entre otras cosas.
Las unicas´ herramientas de gestion´ que provee Magerit son las prestadas por el Management Module de cada uno de los 86 BladeCenters, esto obligo´ al equipo de CeSViMa a desarrollar un conjunto de herramientas que simplificasen la gestion´ del supercomputador Magerit.
– 32 – Cap´ıtulo 4
Magerit Monitor and Management System
Magerit Management Monitoring System (M3S) es el nombre del proyecto que comenzo´ el grupo de administracion´ de CeSViMa en 2007 y que tiene el objetivo de crear una plataforma software que facilite toda las labores de administracion´ del supercomputador Magerit. Las tareas mas´ importantes que cubre el proyecto son monitorizar la maquina´ y su la sala, administrar las cuentas de usuarios, llevar la contabilidad de las horas que ejecuta cada proyecto de investigacion,´ elaborar informes de uso y mantener la maquina´ a pleno rendimiento.
Actualmente solo´ esta´ implantado en el CeSViMa pero como todos los supercomputadores de la RES comparten la misma arquitectura y a sus usuarios es posible que el M3S tambien´ se instale en otros nodos de la red.
4.1. Filosof´ıa
El M3S tiene como premisa automatizar lo maximo´ posible todas las labores del equipo de adminis- tracion´ que sean propias de la gestion´ de Magerit. Ademas´ debe ser simple y directo de cara al usuario, eliminando todo lo superfluo de manera que no distraiga o ralentice al administrador.
De esta manera el sistema presenta interfaces por comandos y por web, ademas´ de utilizar el correo electronico´ de manera habitual para avisar al equipo de administracion´ de incidentes o para mandarle informes.
– 33 – Cap´ıtulo 4. Magerit Monitor and Management System
4.2. Arquitectura
El sistema se ha disenado˜ desde un primer momento con el objetivo de que sea facilmente´ ampliable, por eso tiene una arquitectura modular. Actualmente se compone de los modulos´ que se pueden ver en la Figura 4.1.
M3S
Recuperación Gestión usuarios Monitorización Contabilidad automática
Figura 4.1: Modulos´ que forman el sistema Magerit Management and Monitoring System
Modulo´ framework: Tiene como mision´ la de proporcionar un mecanismo estandar´ de inclusion´ de funcionalidad en el sistema. Asimismo, proporcionara´ dos servicios basicos´ a todos los modulos:´
1. Unificacion´ de la interfaz externa, ya sea con el usuario o con otros sistemas que precisen acceder a el.´
2. El sistema tiene una importante componente de almacenamiento de informacion´ para gestio- nar adecuadamente el supercomputador Magerit. Esta necesidad precisa la inclusion´ de un mecanismo de almacenamiento y gestion´ de dicha informacion.´
Modulo´ de usuarios: Permite gestionar y controlar los usuarios existentes en el sistema. Mediante este modulo´ se automatizan de cierta forma las tareas de alta y baja de usuarios. Ademas´ se encarga del env´ıo de notificaciones a usuarios y de proporcionar datos a otros modulos´ del sistema acerca de los usuarios.
Modulo´ de contabilidad: Tiene como objetivo recopilar informacion´ sobre el uso de la maquina´ que realizan los usuarios, permitir la consulta de estos datos por el equipo del CeSViMa y crear informes completos sobre el uso de Magerit y las actividades de los investigadores de cada proyecto.
Modulo´ de monitorizacion:´ Permite automatizar la monitorizacion´ del estado del supercomputador Ma- gerit y su sala, para detectar posibles fallos del sistema en el menor tiempo posible.
– 34 – 4.3. Diseno˜
Modulo´ de recuperacion´ automatica:´ Es el caso de estudio de este proyecto. El objetivo de este modulo´ es comprobar periodicamente´ el estado del sistema y, en caso de detectar alguna incidencia, realizar una serie de tareas predefinidas para intentar subsanarla de forma automatica.´
4.3. Diseno˜
El diseno˜ del M3S es orientado a objetos, metodolog´ıa descrita en la pagina´ 17. La metodolog´ıa clasica´ estructurada fue desestimada ya que la aplicacion´ a desarrollar no se basa exclusivamente en la gestion´ de datos. Ademas´ la necesidad de ampliar la funcionalidad del proyecto en el futuro empujaba hacia un diseno˜ modular en el que unos modulos´ diesen servicio a otros. La metodolog´ıa orientada a objetos favorece la reutilizacion´ de codigo´ y aumenta la flexibilidad de la arquitectura que es una caracter´ıstica crucial para disenos˜ que no estan´ cerrados desde un primer momento.
4.3.1. Modelo vista controlador (MVC)
Para mejorar la escalabilidad permitiendo que la aplicacion´ crezca sin problemas, y facilitar la modi- ficacion´ y el mantenimiento, el modulo´ framework estructura toda la aplicacion´ segun´ el patron´ de diseno˜ MVC.
Figura 4.2: Arquitectura del patron´ de diseno˜ MVC
Modelo: Esta es la representacion´ espec´ıfica de la informacion´ con la cual el sistema opera, usuarios, maquinas,´ etc. La logica´ de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo cambiar el numero´ de serie de un blade si el formato introducido es erroneo.´
– 35 – Cap´ıtulo 4. Magerit Monitor and Management System
Vista: Este presenta el modelo en un formato adecuado para manejarse por el usuario. Por ejemplo mostrando las temperaturas de los blades en un mapa de la sala.
Controlador: Este responde a eventos, usualmente acciones del usuario e invoca acciones en el modelo y probablemente en la vista. En el caso del M3S el controlador esta´ estructurado usando un patron´ de comando [10] que encapsula las acciones y simplifica su extension.´
4.3.2. Configuracion´
La configuracion´ de la aplicacion´ se guarda en un fichero que se lee cada vez que se ejecuta una llamada al programa. En este fichero se guarda informacion´ como el nombre de la base de datos y el servidor en el que esta´ esta´ alojada, as´ı como el nombre del servidor de correo para posibles notificaciones que deban hacerse al equipo de administracion.´
Tambien´ hay un flag que indica si la aplicacion´ esta´ en desarrollo o en produccion.´ Este flag es muy importante, puesto que en el proceso de desarrollo se usa una base de datos de pruebas en la que no se guardan datos cr´ıticos. Para estos datos se usa una base de datos diferente que solo se utiliza cuando la aplicacion´ entra en la fase de produccion.´
4.3.3. Base de datos
El M3S tiene una componente muy alta de almacenamiento y gestion´ de datos por lo que utiliza un gestor de bases de datos relacional. La base de datos es utilizada a traves´ de una abstraccion,´ ver Subsec- cion´ 4.5.2 en la pagina´ 39, que permite programarla como si se tratara de una base de datos orientada a objetos integrandola´ perfectamente con el Modelo del patron´ MVC descrito en la Subseccion´ 4.3.1.
4.4. Normativas
Para unificar el producto, teniendo en cuenta que trabajaran´ varias personas en el proyecto, se ha he- cho necesaria la definicion´ de una serie de normas de documentacion´ e implementacion´ a aplicar durante el desarrollo del M3S. Ambas normativas se basan en el entorno elegido para el desarrollo: sistema opera- tivo Linux, el paradigma orientado a objetos y el lenguaje de programacion´ PHP. El unico´ inconveniente de la aplicacion´ de estas normativas es, al principio, el tiempo invertido en definir una clara normativa y plasmarla en el documento para desarrolladores pero, sobre todo plasmarla en el codigo´ durante la implementacion.´ Se asume el sobre esfuerzo ya que facilita enormemente el mantenimiento del sistema.
– 36 – 4.4. Normativas
4.4.1. Documentacion´
Todo el proceso sera´ documentado a traves´ de un formato electronico.´ Asimismo, todo el codigo´ sera´ comentado utilizando la documentacion´ proporcionada por el propio entorno. De esta forma es posible generar automaticamente´ ayuda integrada en el entorno de desarrollo evitando incoherencias y desfases entre el codigo´ y la documentacion.´
As´ı, la normativa de documentacion´ se aplicara´ a cualquier documento que sea redactado durante la realizacion´ del desarrollo y define multiples´ aspectos tanto de formato como de contenido de los mismos, como pueden ser su nomenclatura, control de versiones, control de acceso, maquetacion,´ contenido, etc.
El objetivo perseguido es unificar todas las caracter´ısticas de la documentacion´ para facilitar el in- tercambio de informacion´ entre los distintos desarrolladores, ya sea para utilizar la funcionalidad de la aplicacion,´ mejorarla o mantenerla.
4.4.2. Codificacion´
Por otro lado, la normativa de codificacion´ sera´ la recomendada por PHP Extension and Application Repository (PEAR) en su estandar´ de codificacion´ [21]. Esta normativa definira´ los aspectos de las fuentes de los programas desarrollados, como pueden ser:
La normativa de codificacion´ pretende unificar el estilo de programacion´ y documentacion´ del codigo´ para lograr crear un codigo´ legible por cualquier desarrollador, independientemente de quien´ lo escribio,´ facilitando de esta forma su mantenimiento y mejora.
Con el fin de obtener una maxima´ legibilidad del proyecto desarrollado, todo el codigo´ incluido ha sido debidamente documentado:
Con la eleccion´ de identificadores (variables y etiquetas) significativos.
Incorporando comentarios al principio de cada modulo´ (comentarios de prologo)´ que indiquen: la funcion´ del modulo,´ una descripcion´ de su interfaz y de los argumentos que tenga y una historia del modulo´ (autor, fecha de creacion´ y modificacion).´
Asimismo, se incorporaran´ comentarios descriptivos en el cuerpo del modulo´ para describir las funciones de procesamiento.
La forma en que aparece el codigo´ fuente es una contribucion´ importante a la legibilidad del mismo, por ello el sangrado (o indentado) realza las construcciones logicas´ y los bloques de codigo.´
– 37 – Cap´ıtulo 4. Magerit Monitor and Management System
Los datos se deben declarar en aquellos lugares que proporcionan un acceso rapido´ a la hora de identificarlos dentro de una sentencia. Es normal declararlos al principio del modulo´ con un determinado orden.
Las sentencias deber ser simples y faciles´ de seguir, para lo cual se debera´ evitar el uso de compli- cadas comparaciones condicionales, de comparaciones con condiciones negativas, usar parentesis´ para dar mas´ legibilidad a la sentencia, no utilizar sentencias de iteracion´ con muchos anidamien- tos, usar varias l´ıneas para sentencias largas, etc.
Las entradas/salidas deben ser cuidadosamente codificadas, ya que son origen de multiples´ errores dif´ıciles de localizar al primer instante. Por ello es importante mantener un formato de entrada simple, validar todos los datos de entrada, usar indicativos de fin de datos en lugar de especificar el numero´ de datos a leer, etc.
Las variables privadas se precederan´ de subrayados para distinguirlos.
Las clases y propiedades seran´ nombres (con adjetivo opcional).
Los metodos´ seran´ verbos (con nombre o adjetivo opcional).
4.4.3. Gestion´ de versiones
La gestion´ de versiones es muy importante en cualquier desarrollo mediano o grande de software, mas´ si cabe al estar desarrollado por varias personas por un espacio de tiempo prolongado. Es importante estructurar el repositorio para conservar el estado del codigo´ controlado en todo momento. Subversion (Subseccion´ 4.5.4) almacena todos los datos versionados en un repositorio central. Para facilitar el uso de este gestor, Subversion recomienda crear un arbol´ de ficheros y directorios. Su estructura, seguida en este proyecto, consta de tres directorios en el primer nivel de la jerarqu´ıa llamados branches, tags, y trunk.
trunk directorio bajo el cual se lleva el desarrollo principal del proyecto “l´ınea principal”
branches directorio que alojar´ıa las diferentes ramas con nombre de la l´ınea principal de desarrollo
tags directorio donde las ramas son creadas, y quizas´ destruidas, pero nunca modificadas
4.5. Tecnolog´ıas
A continuacion´ se describen las tecnolog´ıas utilizadas en el desarrollo del M3S. Para la realizacion´ del trabajo se ha optado por implementar toda la aplicacion´ en PHP, un lenguaje dinamico´ muy potente
– 38 – 4.5. Tecnolog´ıas que puede ser utilizado tanto para desarrollo web como para implementacion´ de aplicaciones de scripting como es el caso que nos ocupa. El servidor de bases de datos es MySQL server debido a su potencia y a que es el sistema gestor de bases de datos gratuito mas´ utilizado actualmente en todo el mundo, como se describe en la Subseccion´ 4.5.3. Todo el codigo´ de la aplicacion´ se ha implementado utilizando el entorno de desarrollo Eclipse. Se decidio´ hacer uso de Eclipse puesto que es un entorno de desarrollo integrado gratuito y que soporta gran cantidad de plugins que aumentan su potencia en el uso de PHP y otros lenguajes de programacion.´
4.5.1. PHP Hypertext Pre-processor (PHP)
PHP [23] es un lenguaje sencillo, es rapido´ a pesar de ser interpretado, multiplataforma y dispone de una gran cantidad de librer´ıas que facilitan much´ısimo el desarrollo de aplicaciones. PHP se ideo´ prin- cipalmente para ayudar a los programadores web a generar paginas´ dinamicas´ facilmente´ pero, en la actualidad, puede utilizarse como un potente lenguaje de scripting, es decir, se va a utilizar para generar codigo´ que es le´ıdo por el interprete´ del lenguaje y ejecutado en la maquina´ local sin necesidad de un servidor web que muestre la salida.
Desde la version´ 4.3.0, PHP soporta un nuevo tipo de Server Application Programming Interface (SAPI) llamada Command Line Interface (CLI). Como el nombre implica, este tipo de SAPI se centra en la creacion´ de aplicaciones que pueden correr desde la l´ınea de mandatos con PHP, como es el caso del M3S.
PHP permite escribir codigo´ estructurado u orientado a objetos indistintamente, aunque el soporte de objetos es deficiente hasta la llegada de PHP 5.
4.5.2. Zend Framework
Zend Framework [31] es un framework de desarrollo software simple, de codigo´ abierto para PHP disenado˜ para eliminar los detalles de la codificacion´ y proporcionar una serie de clases que facilitan en gran medida el desarrollo de aplicaciones en PHP. Su potencia radica en su diseno˜ altamente modular, haciendo que el codigo´ de las aplicaciones programadas con este framework sea altamente reusable y facil´ de mantener.
La mayor parte de las clases de Zend Framework estan´ escritas para incluirse dentro de proyectos que implementen servicios web pero, usadas de forma individual, pueden ser de gran utilidad en cualquier desarrollo que se realice sobre PHP. En nuestro caso, hemos usado sobre todo clases que:
facilitan la gestion´ de argumentos por l´ınea de comandos.
– 39 – Cap´ıtulo 4. Magerit Monitor and Management System
abstraen la base de datos realcional pudiendo programarla como si se tratara de una bases de datos orientada a objetos.
facilitan la creacion´ y env´ıo de correo electronico´
facilitan la integracion´ de un registro (Log) en la aplicacion.´
4.5.3. MySQL
Actualmente MySQL [20] es el servidor de bases de datos relacionales mas´ utilizado en el mercado, al formar parte del cuarteto LAMP (Linux, Apache, MySQL y PHP)
Entre las numerosas caracter´ısticas de MySQL destacan las siguientes:
Acceso a las bases de datos de forma simultanea´ por varios usuarios y/o aplicaciones.
Seguridad en forma de permisos y privilegios, de modo que determinados usuarios tendran´ permiso para consultar o modificar determinadas tablas. Esto permite compartir datos sin que peligre la integridad de la base de datos.
Structured Query Language (SQL) es un lenguaje muy potente para consulta de bases de datos, usa un motor que permite ahorrar una enorme cantidad de trabajo.
SQL es tambien´ un lenguaje estandarizado, de modo que las consultas son facilmente´ portables a otros sistemas y plataformas. Esto,´ unido al uso de PHP proporciona una portabilidad enorme.
Escalabilidad, que permite manipular bases de datos enormes.
Proporciona sistemas de almacenamiento transaccionales y no transaccionales.
Esta´ escrito en C y C++, probado con multitud de compiladores y dispone de APIs para muchas plataformas diferentes.
Permite manejar multitud de tipos para columnas y registros de longitud fija o variable.
Soporte a grandes bases de datos. MySQL Server soporta bases de datos que contienen 60.000 tablas y cerca de 5.000.000.000.000 de registros.
Permite conexiones entre diferentes maquinas´ con distintos sistemas operativos.
Multihilo, con lo que puede beneficiarse de sistemas multiprocesador.
– 40 – 4.5. Tecnolog´ıas
4.5.4. Subversion
Subversion [26] es una solucion´ libre y de codigo´ fuente abierto para el control de versiones. Esto es, Subversion maneja ficheros y directorios a lo largo del tiempo. Los ficheros se almacenan en un repositorio central. El repositorio es practicamente´ lo mismo que un servidor de ficheros ordinario, salvo que recuerda todos los cambios que se hayan hecho a sus ficheros y directorios. Esto permite que se puedan recuperar versiones antiguas de ficheros y examinar la historia de cuando´ y como´ cambiaron los datos, y quien´ hizo el cambio. Esta es la razon´ por la que mucha gente piensa que Subversion, y los sistemas de control de versiones en general, son una especie de ”maquinas´ del tiempo”.
Algunos sistemas de control de versiones tambien´ son Sistemas de manejo de configuracion´ del software (SCM). Estos sistemas estan´ disenados˜ espec´ıficamente para manejar arboles´ de codigo´ fuente, y tienen muchas caracter´ısticas que son espec´ıficas para el desarrollo de software - tales como el enten- dimiento nativo de los lenguajes de programacion,´ o proporcionan herramientas para compilar software. Subversion, sin embargo, no es uno de estos sistemas; es un sistema general que puede ser utilizado para manejar cualquier coleccion´ de ficheros, incluyendo codigo´ fuente.
El uso de Subversion durante el desarrollo del proyecto ha sido de gran utilidad puesto que se han generado una gran cantidad de ficheros de codigo´ fuente que estan´ relacionados entre s´ı y con otros proyectos que se llevan a cabo dentro del CeSViMa. Es por ello por lo que en ciertos momentos varios usuarios modifiquen el mismo fichero y, gracias a Subversion, se mantengan todos los cambios sin que haya conflictos entre versiones.
4.5.5. Eclipse
Eclipse [24] es una plataforma de software de codigo´ abierto independiente de una plataforma para desarrollar lo que el proyecto llama “Aplicaciones de cliente enriquecido”, opuesto a las “aplicaciones cliente liviano” basadas en navegadores. Sin embargo, tambien´ se puede usar para otros tipos de aplica- ciones desarrolladas en cualquier lenguaje de programacion.´
Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundacion´ Eclipse, una organizacion´ independiente sin animo´ de lucro que fomenta una comunidad de codigo´ abierto y un conjunto de productos complemen- tarios, capacidades y servicios.
En el caso que nos ocupa se ha optado por el uso de Eclipse puesto que se integra perfectamente con PHP y con el resto de herramientas utilizadas en el desarrollo de la aplicacion,´ por ejemplo, Eclipse posee un pugin para Subversion que trabaja directmente con repositorios sin necesidad de aplicaciones externas.
– 41 –
Parte III
Desarrollo del proyecto
Cap´ıtulo 5
Recuperacion´ Automatica´
En este cap´ıtulo se definen todos los conceptos que enmarcan el proceso de recuperacion´ automatica.´ La recuperacion´ automatica´ imita el procedimiento que realiza un administrador para recuperar un nodo de forma manual as´ı que se explicaran´ dichos pasos en la Seccion´ 5.2. Ademas´ se definen los l´ımites de esta recuperacion´ y los principales problemas que presenta realizar una implementacion´ totalmente automatica´ de dicho proceso de recuperacion´ en la Seccion´ 5.3.
5.1. Contexto
Una de las labores que mas´ tiempo consume a los administradores de Magerit es la de volver a poner a disposicion´ de los usuarios los nodos de computo´ que van quedando inutiles´ por aver´ıas en sus componentes hardware o por “cuelgues” de sus componentes software.
Se da con relativa frecuencia que el sistema operativo o cualquiera de los demonios que corren sobre el´ fallen a consecuencia del uso intensivo al que les someten los calculos´ de los usuarios. Otra causa por la que fallan estos sistemas son los errores de programacion´ que contienen los programas de los usuarios o las librer´ıas que utilizan. Estos fallos de programacion´ son mas´ graves ya que suelen provocar una ca´ıda masiva de blades en el cluster.
Las aver´ıas de los componentes f´ısicos se dan con menos frecuencia pero tampoco es inusual que aparezcan. Hay que tener en cuenta que estamos hablando de un cluster que contiene aproximadamente 1200 computadores mas´ o menos convencionales sometidos a una carga muy elevada.
– 45 – Cap´ıtulo 5. Recuperacion´ Automatica´
El sistema de recuperacion´ automatica´ realizara´ operaciones de recuperacion´ a los nodos de computo´ que no esten´ completamente operativos. Un nodo esta´ completamente operativo si es capaz de ejecutar los trabajos que le mande el planificador central del sistema de balanceo de carga (LoadLeveler).
Como ya se explico´ en la pagina´ 31, el planificador de carga, Central Manager, ejecuta en el servidor de gestion´ y va repartiendo la cola de trabajos batch entre los diferentes nodos de trabajo segun´ estos vayan quedando libres. Para esta labor es necesario que en cada nodo se ejecute un demonio llamado Loadl que es el encargado de “hablar” con el Central Manager. Para que este demonio se ejecute correc- tamente deben funcionar bien un conjunto de subsistemas que son los susceptibles de ser controlados por el modulo´ de recuperacion´ automatica:´
El nodo, obviamente, debe estar encendido con el sistema operativo arrancado.
El nodo debe tener 4GB de memoria RAM.
El nodo debe tener la red Myrinet perfectamente configurada.
El nodo debe tener montada una particion´ en su disco duro local. Esta particion´ esta´ disponible para que los programas de los usuarios manejen datos temporales y locales de cada nodo.
El nodo debe tener montadas las particiones que el sistema de ficheros distribuido GPFS ofrece. Las peticiones que se hacen a estos sistemas de ficheros las atienden en cada nodo unos demonios que son los encargados de comunicarse con los servidores, que sirven elGPFS.
El nodo debe tener correctamente arrancado el demonio sshd ya que, aunque de el´ no dependa el Loadl, el despliegue de los trabajos que hace el Central Manager lo realiza conectandose´ por ssh a cada nodo que va a ejecutar el trabajo del usuario.
En la Figura 5.1 se muestran los sistemas que van a ser tenidos en cuenta por el sistema de recupera- cion´ automatica´ y sus dependencias.
Figura 5.1: Sistemas necesarios para un blade operativo
– 46 – 5.2. Recuperacion´ manual
5.2. Recuperacion´ manual
El sistema de recuperacion´ automatica´ imitara´ la forma de actuar de los administradores cuando recuperan nodos de computo.´ A continuacion´ se realiza una descripcion´ de los pasos y razonamientos por los que un administrador pasa desde que descubre que un nodo no esta´ operativo hasta que resuelve el problema.
1. Lo primero que hace sospechar a un administrador de que un nodo no puede ejecutar trabajos es que no se encuentre en la lista de nodos que maneja el LoadLeveler. Esto quiere decir que el nodo que falta no tiene arrancado el Loadl. Para determinar la causa hay que conectarse al nodo por ssh.
2. Si el blade no tiene conexion´ por ssh es posible que este´ apagado, con el sistema operativo sin cargar o con el demonio sshd sin funcionar. Para descubrirlo lo primero es saber si esta´ apagado. Si aparece en off hay que encenderlo y esperar que arranque. Si parece que no esta´ apagado se puede comprobar la consola de arranque para ver en que´ paso se encuentra. Si esta´ parado en algun´ punto este´ indicara´ el error, normalmente hardware, si por el contrario muestra un dialogo´ de login hay que entrar y reiniciar el sshd que con casi toda seguridad arreglara´ el problema de conexion.´
3. En el momento que el administrador tiene conexion´ por ssh puede preguntar por el estado del Loadl. Si esta´ arrancado lo para y vuelve a arrancar porque es posible que este´ “colgado”. Si esta´ parado lo hay que comprobar son los subsistemas de los que depende, mostrados en la Figu- ra 5.1. El propio arranque del Loadl puede realizar este chequeo por nosotros.
4. El disco duro local se comprueba mirando que la particion´ llamada local scratch este´ bien montada sobre este´ dispositivo.
5. La memoria se comprueba verificando que el sistema operativo ve una memoria principal de 4 GB.
6. Para comprobar la Myrinet hay que mirar la lista de nodos que es capaz de ver por dicha red, si esta´ solo´ es muy probable que la tarjeta de Myrinet este´ estropeada.
7. Para comprobar el GPFS hay que mirar que esten´ bien montados los sistemas de ficheros que sirven los servidores por este protocolo. Si no estan´ todos el administrador solicita el montado de dichos volumenes,´ y espera a que la operacion´ termine. Dependiendo de la carga de los servidores es posible que tarde del orden de minutos incluso que no llegue nunca a montar. Es posible que esten´ montados pero que aparezcan como rancios, es senal˜ de que el sistema de ficheros esta´ en un estado inconsistente lo que sugiere un apagado del blade inmediato para no perjudicar a los servidores.
– 47 – Cap´ıtulo 5. Recuperacion´ Automatica´
8. Una vez comprobados todos los subsistemas se puede arrancar el Loadl sin problemas con lo que el nodo vuelve a estar operativo.
5.3. Analisis´ inicial
Antes de empezar el desarrollo del proyecto es aconsejable realizar un analisis´ del problema que per- mita valorar la viabilidad del sistema a desarrollar ademas´ de caracterizar el problema para poder elegir entre ciclos de vida, Seccion´ 2.1, y paradigmas de programacion,´ Seccion´ 2.2 definiendo en consecuencia el proceso de desarrollo.
5.3.1. L´ımites
1. Como ya se ha visto, para arreglar los fallos de componentes software lo que hay que hacer es reconfigurar el nodo, o “rearrancar” procesos, o reiniciar todo el blade. Estas incidencias son re- cuperables por un administracion´ que trabaja en remoto y no necesitan de intervencion´ f´ısica para solventarse ya que estos procesos de recuperacion´ se limitan a la ejecucion´ de una serie de coman- dos.
Sin embargo las aver´ıas de los componentes hardware no son reparables desde remoto sino que se necesita la sustitucion´ manual de la pieza afectada por una nueva. Estos fallos suelen provocar que el nodo afectado este´ fuera de produccion´ durante mas´ tiempo, en concreto el tiempo que se tarda en conseguir el recambio y realizar la sustitucion.´
Viendo como´ se solucionan los fallos de componentes software y de componentes hardware de un nodo, se pude establecer un primer l´ımite a la efectividad de un recuperador automatico´ (no robotizado), las incidencias relacionadas con los programas son solventables pero las aver´ıas en piezas f´ısicas no lo son, como mucho se pueden diagnosticar y comunicar a los administradores.
2. Por otro lado, es obvio pensar que las acciones que un recuperador automatico´ puede realizar son aquellas para las que ha sido programado, lo que no es tan obvio es pensar que no se pueden pro- gramar acciones de recuperacion´ que los propios administradores del sistema desconocen. Hay que tener en cuenta que en un sistema tan complejo como Magerit influyen much´ısimos subsistemas que necesitan funcionar al un´ısono para que todo transcurra con normalidad. No es posible cono- cer todas las configuraciones de todos los programas que ejecutan en cada nodo y mucho menos sus errores de programacion.´ Por consiguiente podemos identificar otro l´ımite a un recuperador automatico´ en el conocimiento que tengan los administradores del sistema que se desea recuperar. Este l´ımite no es muy preocupante porque, por lo general, los errores que no saben arreglar los
– 48 – 5.3. Analisis´ inicial
administradores son errores extranos˜ y que por lo tanto no se ganar´ıa mucho tiempo teniendo su recuperacion´ automatizada.
5.3.2. Interaccion´ con el sistema
En un recuperador automatico´ la interaccion´ con el usuario es escasa ya que pretende ser un proceso lo mas´ automatico´ posible. La ejecucion´ no la inicia directamente el usuario sino que es lanzada por el planificador de tareas (cron) cada cierto tiempo.
El proceso de recuperacion´ puede entorpecer las labores del administrador por ello el usuario podra´ des- habilitar la ejecucion´ del recuperador automatico:´
En un nodo concreto por si se quiere recuperar a mano, o si esta´ retirado de produccion´ y no se quiere que el recuperador lo vuelva a incluir.
En toda la maquina´ a la hora de hacer paradas tecnicas,´ arranques controlados o pruebas de cual- quier tipo.
Cuando lo desee, el usuario debe ser capaz de habilitar las acciones del recuperador automatico´ tanto en un nodo concreto como en toda la maquina.´
El sistema debe poder informar en todo momento sobre el estado de la recuperacion´ automatica.´ Principalmente se debe mostrar la lista de nodos en los que la recuperacion´ automatica´ esta´ deshabilitada.
Por ultimo,´ el sistema debe notificar al usuario el resultado de las acciones de recuperacion,´ indicando los pasos que no han podido realizarse correctamente y facilitando informacion´ util´ para el diagnostico´ del problema.
En la Figura 5.2 se muestran estas interacciones como casos de uso.
5.3.3. Problemas
En este primer analisis´ se han identificado varios problemas que pueden complicar el desarrollo facilmente´ si no son tenidos en cuenta desde el principio.
1. Lo primero que llama la atencion´ de este programa es que es muy peligroso si se descontrola ya que es capaz de parar procesos cr´ıticos o incluso de reiniciar los nodos que no deber´ıa reiniciar afectando a los calculos´ de los usuarios, que en el peor de los casos pueden llevar mas´ de una semana ejecutando.
– 49 – Cap´ıtulo 5. Recuperacion´ Automatica´
Figura 5.2: Casos de uso del recuperador automatico´
Para ilustrar la prudencia con la que debe actuar el recuperador se puede recurrir a un s´ımil en el campo del derecho: Es “menos malo” dejar a un criminal en libertad que encarcelar a un inocente. Siguiendo esta premisa, solo´ se realizaran´ acciones de recuperacion´ sobre un sistema si tenemos total certeza de que no funciona correctamente.
Solucion:´ La unica´ solucion´ valida´ para evitar este problema es tener mucho cuidado a la hora de disenar˜ y hacerlo siempre con esa premisa en mente.
2. Otro problema que presenta la realizacion´ de un recuperador automatico´ es que ejecuta acciones en un computador que no esta´ funcionando correctamente y por tanto puede verse afectado por ese comportamiento errante.
– 50 – 5.3. Analisis´ inicial
Solucion:´ No se puede hacer que un sistema que estamos arreglando funcione mejor para que el recuperador ejecute sin problemas, por lo tanto la solucion´ pasa por adaptarse y hacer el sistema mas´ robusto y tolerante a fallos.
3. Como se ha podido comprobar en la descripcion´ del metodo´ manual, el proceso de recuperacion´ de un nodo encadena una serie de decisiones basadas en los resultados de la ejecucion´ de man- datos. Esto puede degenerar, si se hace un diseno˜ puramente algor´ıtmico, en un codigo´ con tal anidamiento de condiciones que se vuelva inmanejable.
Ademas´ hay que tener en cuenta que el codigo´ debe ser facil´ de modificar porque es muy probable que el proceso de recuperacion´ cambie si cambian configuraciones del software o si los adminis- tradores encuentran metodos´ mejores.
Solucion:´ En este punto es donde mas´ nos va a ayudar que el M3S imponga el desarrollo utili- zando el paradigma de la programacion´ orientada a objetos, ver Seccion´ 4.3. Este paradigma nos facilitara´ la tarea de hacer mas´ flexible el codigo´ y nos obligara´ a disenar˜ sin caer en el excesivo anidamiento de condiciones.
4. Una fase primordial de todo desarrollo software es la fase de pruebas del programa. Esta fase va a presentar un problema anadido.˜ El recuperador automatico,´ al estar muy unido a la arquitectura de un nodo de computo,´ no podra´ probarse realmente sobre otros computadores que no sean los blades de Magerit. Ademas,si´ lo unimos al primer problema, es arriesgado probarlo en blades que esten´ siendo usados por los usuarios.
Solucion:´ Podr´ıa simularse el comportamiento de los blades programando baldes virtuales para probar sobre estos el recuperador automatico´ pero el sobre esfuerzo que supone esto es a priori demasiado elevado. Un remedio pasa por probar el codigo´ por partes y cuando todas las partes esten´ bien probadas reservar nodos de Magerit para hacer las ultimas´ pruebas reales sobre ellos.
5.3.4. Viabilidad
Los l´ımites que se han identificado en la pagina´ 48 son perfectamente asumibles. Que las aver´ıas hardware no sean arregladas por el recuperador no supone mucho contratiempo, ademas´ de que el sis- tema es capaz de ayudar al diagnostico´ del problema. En cuanto al l´ımite relacionado con la falta de conocimiento del sistema tampoco restringe radicalmente las posibilidades del recuperador ya que los problemas que s´ı estan´ bien resueltos son precisamente los que se dan con mas´ frecuencia.
– 51 – Cap´ıtulo 5. Recuperacion´ Automatica´
Los requisitos que describe la interaccion´ con el sistemas no conllevan ningun´ riesgo ya que son perfectamente abarcables por la infraestructura de la que dispone el M3S. El usuario puede introducir las ordenes´ por la l´ınea de comandos y recibir los resultados por correo electronico.´
Por ultimo,´ todos los problemas que se han identificado tienen una solucion´ apropiada. Un desarrollo que tenga en cuenta los problemas y por supuesto sus soluciones no tiene por que´ complicarse hasta el punto de ser inabordable.
Este analisis´ inicial determina que es viable el desarrollo del proyecto y como conclusion´ define el proceso de desarrollo mas´ a apropiado para un sistema con las caracter´ısticas ya estudiadas.
5.3.5. Proceso de desarrollo
Como el recuperador automatico´ es un modulo´ para el M3S casi todo el proceso de desarrollo esta´ ya definido por el.´ Se puede consultar la normativa del proyecto en la Seccion´ 4.4 que empieza en la pagi-´ na 36.
Queda por determinar el ciclo de vida, ver Seccion´ 2.1, que se va a seguir durante el desarrollo. Para determinar la incertidumbre que alberga el problema utilizare´ la Tabla 2.1. El problema, la recuperacion´ de nodos, es bastante conocido aunque si nos fijamos en el tercero de los problemas identificados no es del todo estable. En cuanto a la solucion,´ no es conocida a priori y con toda seguridad surgiran´ cambios a medida que se descubren las tecnicas.´ Esto clasifica el recuperador automatico´ como un sistema con incertidumbre media, casi alta, para el cual esta´ aconsejado un ciclo de vida en espiral o uno basado en prototipos. De los dos se ha optado por el ciclo de vida en espiral evolutivo ya que es el mas´ flexible y se adaptara´ mejor al extra de incertidumbre que rodea a la inestabilidad del problema.
Como consecuencia de este ciclo de vida se han desarrollado varias iteraciones que resultaron en varios recuperadores automaticos.´ La solucion´ ha ido evolucionando hasta la tercera y definitiva. Primero se desarrollo´ un recuperador secuencial, paso´ a desarrollarse un segundo recuperador, esta vez paralelo, y un conjunto de nuevas necesidades hizo que se tuviera que crear el definitivo recuperador distribuido.
– 52 – Cap´ıtulo 6
Recuperador Secuencial
Cada iteracion´ en el ciclo de vida en espiral cuenta con una etapa de analisis´ de riesgo en la que se identifican los requisitos que se van a tener en cuenta en dicha vuela. A continuacion´ se realiza el diseno,˜ la implementacion,´ las pruebas del sistema y finalmente se realiza la evaluacion´ del cliente. Durante todo el proceso se van identificando necesidades que seran´ cubiertas, si as´ı se planifica, en la siguiente iteracion.´
6.1. Requisitos
La etapa de analisis´ de riesgos determino´ los requisitos a cubrir en esta primera iteracion.´
En fase el desarrollo se centro´ en la logica´ de recuperacion´ de nodos y en las caracter´ısticas de informes ya que se identificaron como las cruciales por conllevar el mayor riesgo.
En esta fase se abordaron los siguientes requisitos funcionales:
1. Detectar incidencias:
Se analiza el estado de cada nodo en busca de irregularidades.
Se lanzaran´ las acciones de recuperacion´ sobre los nodos con incidencias.
2. Detectar e implementar las secuencias de recuperacion´ automaticas:´
Se intenta recuperar el funcionamiento normal del nodo, es decir arrancar los demonios del LoadLeveler y del Ssh.
– 53 – Cap´ıtulo 6. Recuperador Secuencial
Dirigiremos el orden de las acciones de recuperacion´ en funcion´ de los errores que devuelvan las que van siendo ejecutadas.
3. Notificar resultados:
Se mantendra´ un registro de las acciones ejecutadas en cada nodo segun´ se van realizando.
Se debe notificar por mail las acciones realizadas y los resultados obtenidos.
Tambien´ los siguientes requisitos no funcionales:
1. Ejecutar sin necesitar la atencion´ de los administradores.
2. Ser suficientemente rapido´ para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.
3. Ejecutar sin interferir en los calculos´ de los usuarios.
4. Ejecutar sobrecargando el sistema lo menos posible.
6.2. Diseno˜
El diseno˜ de este recuperador parte de que va a ejecutar en el servidor de gestion´ descrito en la pagi-´ na 26, invocando los mandatos de recuperacion´ sobre los nodos de forma remota a traves´ del protocolo Ssh.
6.2.1. Proceso de recuperacion´
Este primer recuperador automatico´ recupera nodos secuencialmente. Para saber los nodos que no estan´ operativos consulta el estado del LaodlLeveler de la maquina.´ De esa manera sabemos los nodos que no son visibles por el Cenral Manager y que deben ser recuperados.
A continuacion´ se va recorriendo la lista de nodos defectuosos ejecutando las acciones de recupera- cion´ que correspondan a cada uno. Al final de la ejecucion´ se manda al administrador el informe con las acciones que se han llevado a cabo y sus resultados.
6.2.2. Modelo del dominio
Observando las tareas que hay que realizar en esta fase saltan a la vista varios conceptos que deben estar presentes en el diseno.˜
– 54 – 6.2. Diseno˜
Recoverer: Es el punto de inicio del algoritmo de recuperacion.´ El recuperador es el encargado de analizar los nodos en busca de irregularidades y de lanzar las acciones de recuperacion´ sobre los nodos que no esten´ operativos. Al final del proceso notificara´ las acciones realizadas.
Recover: Una recuperacion´ es una accion´ que se puede llevar a cabo sobre un blade o un subsistema de este´ para intentar solucionar la incidencia. Las recuperaciones seran´ mas´ o menos complejas, formando unas parte de otras si es necesario, es decir, un Recover puede estar compuesto de varios Recovers.
Report: Representa el informe de salida del proceso de recuperacion.´ Va siendo rellenado por las accio- nes de recuperacion´ a medida que se van ejecutando. Tiene la capacidad de guardarse en una base de datos y de enviarse por correo electronico´ para el seguimiento por parte de los administradores de Magerit.
Blade: Representa el blade, tanto la parte hardware como la software. Es un concepto central del M3S. Contiene la informacion´ de estado y caracter´ısticas del blade. Ademas´ realiza mandatos de admi- nistracion´ sobre el blade f´ısico, como encenderlo, apagarlo o arrancarle servicios.
Log: Es el encargado de mantener un registro de las acciones de recuperacion´ que se ejecutan sobre blades y los resultados de las mismas.
En la figura 6.1 se muestra el diagrama de dominio de esta primera fase. Como se puede ver, existen varias recuperaciones (Recover) en el sistema.
Figura 6.1: Diagrama de dominio del recuperador secuencial
6.2.3. Acciones de Recuperacion´
Este punto se centra en explicar el concepto Recover. Es el concepto mas´ importante y en el cual se han empleado mas´ horas de diseno.˜
– 55 – Cap´ıtulo 6. Recuperador Secuencial
En un principio se identifico´ la recuperacion´ de un blade como un proceso en el que se van probando mandatos sobre el sistema que se quiere reparar y en funcion´ de lo que devuelven estos mandatos se ejecutan otros.
Lo mas´ intuitivo es hacer una clase que contenga la ’inteligencia’ suficiente para realizar todo ese algoritmo. En la fase de analisis´ de riesgos, se creo´ un prototipo intentando probar esta idea y se descu- brio´ rapidamente´ que el codigo´ se hac´ıa, a medida que crec´ıa, inmanejable. Esto no es sorprendente ya que durante el analisis´ inicial ya se identifico´ este problema, ver Subseccion´ 5.3.3.
En un analisis´ mas´ exhaustivo se llego´ a apreciar este algoritmo como una serie de acciones de recuperacion´ que se realizan sobre los subsistemas del blade para repararlos. Cuando se logra reparar un subsistema, es decir, una accion´ de recuperacion´ ha ejecutado con exito,´ se dejan de ejecutar acciones de recuperacion´ sobre este.´ Si una accion´ de recuperacion´ fracasa, se intentara´ ejecutar otra accion´ de recuperacion´ sobre el mismo subsistema.
Este planteamiento llevo´ a pensar en la primera caracter´ıstica del concepto Recover. En principio, un Recover no es mas´ que una accion´ de recuperacion,´ sobre un sistema, que se ejecuta con exito´ o fracaso. De esta manera se puede encapsular en cada Recover la ejecucion´ de uno o varios mandatos sobre el blade y la posterior verificacion´ de su resultado.
Falta anadir˜ al modelo la logica´ de transicion´ entre acciones de recuperacion.´ Una primera carac- ter´ıstica de esta logica,´ es que para reparar un subsistema que funciona mal, lease´ ejecutar un Recover, se van realizando secuencialmente una serie de intentos para subsanar el problema. Estos intentos no son mas´ que otras acciones de recuperacion.´
Siguiendo este razonamiento se llego´ a la segunda caracter´ıstica de un Recover. Las acciones de recuperacion´ pueden estar compuestas por un conjunto de acciones de recuperacion´ que se ejecutan como intentos sucesivos de reparar un sistema.
Al atender a las dos caracter´ısticas que debe cumplir un Recover, en un ejercicio de s´ıntesis, se llega a la conclusion´ de que un Recover es una composicion´ de otros Recovers, ya sean estos´ simples o tambien´ compuestos, que se ejecuta con exito´ o fracaso.
Volviendo a la logica´ de transicion´ entre acciones de recuperacion´ vemos que efectivamente sobre un sistema danado˜ se realizan una serie de intentos por recuperarlo. Pero si este sistema esta´ compuesto por subsistemas, el Recover debera´ ser mas´ inteligente e identificar que´ subsistema es el que falla para ejecutar su accion´ de recuperacion´ y no las de los subsistemas que no fallan.
Finalmente estas observaciones llevaron a caracterizar un Recover como:
1. Un Recover es una accion´ sobre un sistema que se ejecuta con un resultado de exito´ o fracaso.
– 56 – 6.2. Diseno˜
2. Un Recover es una composicion´ de mas´ Recovers ya sean simples o tambien´ compuestos.
3. Un Recover ejecuta con exito´ si y solo´ si alguno de los Recover que lo componen ejecuta con exito.´
4. Un Recover simple (no esta´ compuesto por otro Recover) resulta con exito´ si resuelve el problema que tiene el sistema sobre el que se ejecuta.
El concepto Recover aplicado a la recuperacion´ de un blade de Magerit genera el diagrama de clases que se expresa en la figura 6.2. El diagrama esta´ simplificado, todos los Recovers que aparecen en el diagrama estan´ compuestos por otros. Los que parecen simples en realidad se componen de los intentos de reparacion,´ es decir acciones de recuperacion´ simples.
Figura 6.2: Diagrama de clases de los Recovers
Al observar las semejanzas con la figura 5.1, se ve claramente la correspondencia entre la jerarqu´ıa de subsistemas y la jerarqu´ıa entre recuperadores. Hay que aclarar que “LocalScratch” es el nombre del volumen que monta el disco duro local.
Todos los Recover heredan el metodo´ Run() y varios atributos. Los Recover de los que se compone estan´ ordenados en el vector steps.El metodo´ Run() crea el Recover que indique el numero´ de intentos, llamado tries, dentro del vector de nombres de Recovers, steps. Cuando lo ha creado con el blade sobre el que tiene que actuar llama al metodo´ Run() de este Recover recien´ creado. Durante toda la ejecucion´ se van registrando las acciones realizadas tanto en el informe, Report como en el Log. Por supuesto muchos Recover sobrecargan el metodo´ Run(),por ejemplo los simples lo que debe hacer este metodo´ es realizar las acciones finales sobre el blade.
Por ejemplo, supongamos que el SshRecover, el recuperador del demonio sshd esta´ compuesto por tres recuperadores simples que intentan recuperar la conexion´ de maneras diferentes. El metodo´ Run() del SshRecover no esta´ sobrecargado, su implementacion´ es la que hereda del Recover, mientras que los recuperadores simples, implementan los comandos propios de la recuperacion.´
– 57 – Cap´ıtulo 6. Recuperador Secuencial
Cuando se detecta el fallo del conexion´ se llama al mandato Run() del SshRecover, que tiene el siguiente estado:
Steps = {SshRecover 1, SshRecover 2, SshRecover 3}
Tries = 0
El metodo´ Run() del SshRecover crea una instancia del Recover que se encuentre en el vector steps en la posicion´ que indique el numero´ de intentos que se han ejecutado ya. En este caso se creara´ un objeto de la clase SshRecover 1 porque la variable tries vale 0.
A continuacion´ se invocara´ el metodo´ Run() del SshRecover 1 que realizara´ la accion´ de recupera- cion´ del ssh que sea, por ejemplo reiniciar el demonio sshd. Si la accion´ tiene exito´ la recuperacion´ del ssh acabar´ıa, si por el contrario la accion´ de recuperacion´ no termina con exito´ el estado del SshReco- ver cambiara´ pasando a haber realizado un intento, lo que se indica con la variable tries valiendo 1, y ejecutara´ el siguiente Recover de la lista de pasos steps.
Si ninguno de los tres intentos tiene exito,´ la recuperacion´ del ssh, el metodo´ Run() del SshRecover , terminara´ en fracaso. Este escenario se describe en la Figura 6.3.
Figura 6.3: Diagrama de secuencia de una recuperacion´ fallida
– 58 – 6.3. Resultados
Esta es la manera en la que funcionan todos los Recovers a excepcion´ de los Recovers de sistemas que dependen de subsistemas para ejecutar correctamente. Este es el caso del LoadlRecover o del Blade- Recover. Ambas acciones de recuperacion´ sobrecargan el metodo´ Run() para poder determinar cual´ de los subsistemas esta´ fallando y ejecutar su accion´ de recuperacion´ correspondiente.
En este modelo se han utilizado ideas de patrones de diseno˜ [10].Por ejemplo, un Recover es una clara implementacion´ del patron´ Command.
Figura 6.4: Diagrama de clases del patron´ Command
El creador del Recover es el que le asigna el receptor de sus acciones (blade). Ademas´ todos los Recovers tiene un metodo´ para ejecutar su accion.´
Otro patron´ del que se han tomado ideas ha sido el Composite, figura 6.5. No se ha implementado tal cual ya que no es necesaria una composicion´ dinamica´ de Recovers, pero se ha tomado la estructura del patron.´ Todas las acciones de recuperacion´ heredan de Recover ya sean compuestas o simples. Las simples son las llamadas hojas (leaf ) en el patron.´
6.3. Resultados
Durante la etapa de pruebas de esta primera fase se detecto´ que el diseno˜ es valido´ en general, pero dada la dimension´ del supercomputador Magerit la ejecucion´ de la recuperacion´ de toda la maquina´ era extremadamente lenta y es que en la recuperacion´ de algunos nodos llegaba a tardar cerca de 10 minutos.
– 59 – Cap´ıtulo 6. Recuperador Secuencial
Figura 6.5: Diagrama de clases del patron´ Composite
Ademas´ se encontraron problemas serios de robustez como se hab´ıa predicho en el analisis´ inicial, ver Subseccion´ 5.3.3. Algunas acciones de recuperacion,´ al ejecutar comandos en los nodos afectados, dejaban el recuperador automatico´ “colgado”. Esto es debido a que los nodos sobre los que se esta´ ac- tuando, como tienen algun´ fallo, no son capaces de responder correctamente a llamadas corrientes y hacen que el proceso se quede en eterna espera, o que termine inesperadamente.
Estos dos problemas obligaron a afrontar una revision´ completa del modelo llevada a cabo en la segunda fase del desarrollo del proyecto.
– 60 – Cap´ıtulo 7
Recuperador Paralelo
La segunda fase de desarrollo se inicia para solucionar los problemas que se presentaron al final de la primera fase y completar las funcionalidades que no fueron implementadas en la primera iteracion.´
7.1. Requisitos
Principalmente hay que modificar el proceso de recuperacion´ para hacerlo mas´ rapido.´ El otro pro- blema que ten´ıa la version´ secuencial era la poca tolerancia a fallos. Ademas´ queda por implementar la opcion´ de habilitar y deshabilitar la recuperacion´ automatica.´
Del analisis´ de riesgos, teniendo en cuenta estos problemas se identifican los siguientes requisitos funcionales:
1. Mejorar la rapidez:
Hay que paralelizar la ejecucion´ del sistema implementando diferentes hilos de ejecucion.´
Hay que hacer que estos hilos de ejecucion´ esten´ sincronizados. Dos hilos no deben reparar un mismo blade al mismo tiempo.
Algunas acciones de recuperacion´ requieren esperar un tiempo a que el blade pueda comple- tar los mandatos. Estos tiempos muertos se puede aprovechar para atender a otro blade.
El informe debe seguir enviandose´ en un solo mail y no uno por trabajador.
2. Mejorar la robustez:
– 61 – Cap´ıtulo 7. Recuperador Paralelo
Es inevitable que alguno de los hilos de ejecucion´ se quede colgado por acciones de recupera- cion´ que no terminan nunca. Hay que recordar que estamos intentando reparar (y ejecutando en) sistemas que no se encuentran en buenas condiciones.
Hay que controlar los hilos que estan´ ejecutando caoticamente´ para poder pararlos y arrancar otros en sus lugares.
3. Poder ser deshabilitado inmediatamente a voluntad de los administradores para que no interfiera en las labores de estos. Puede hacerse de forma global o especificando los nodos individualmente.
4. Poder ser habilitado en cualquier momento para que continue´ con sus funciones. Puede hacerse de forma global o especificando los nodos individualmente.
Se siguen manteniendo los requisitos no funcionales de la iteracion´ anterior:
1. Ejecutar sin necesitar la atencion´ de los administradores.
2. Ser suficientemente rapido´ para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.
3. Ejecutar sin interferir en los calculos´ de los usuarios.
4. Ejecutar sobrecargando el sistema lo menos posible.
7.2. Diseno˜
En esta iteracion´ se han anadido˜ los conceptos necesarios para paralelizar el codigo´ y controlar la concurrencia introducida en el modelo. Se describen a continuacion´ los nuevos conceptos y los cambios realizados con respecto a la anterior iteracion.´
7.2.1. Proceso de recuperacion´
El proceso de recuperacion´ ha cambiado desde la version´ secuencial. Se sigue ejecutando en el ser- vidor de gestion´ y accediendo remotamente a los nodos para invocar los comandos de recuperacion.´ Lo que se ha modificado es que ahora, evidentemente, se realizan las acciones de recuperacion´ en paralelo.
En el recuperador paralelo, despues´ de identificar todos los nodos con incidencias se crean varios pro- cesos que se encargan de recuperarlos. Cuando no quedan blades sin atender se manda al administrador el informe con las acciones que se han llevado a cabo todos los procesos y sus resultados.
– 62 – 7.2. Diseno˜
7.2.2. Modelo del dominio
Observando las tareas que hay que realizar en esta fase se han identificado varios conceptos que deben estar presentes en el diseno.˜
Figura 7.1: Diagrama de dominio del recuperador paralelo
WatchDog: Es el punto de inicio del algoritmo de recuperacion.´ Es el encargado de analizar los nodos en busca de irregularidades y de crear los tiques de los nodos que tienen algun´ problema.
Ademas´ el WatchDog es el proceso encargado de vigilar que los recuperadores hagan bien su trabajo. Si un tique lleva demasiado tiempo cogido por un recuperador, el WatchDog tendra´ que matar ese proceso, liberar el tique y crear otro proceso recuperador.
Tambien´ esperara´ a que todos los recuperadores terminen antes de mandar el Report.
Recoverer: Los recuperadores son los procesos encargados de realizar las acciones de recuperacion´ sobre los nodos de computo.
Su tarea consiste en coger un tique libre y llevar a cabo las acciones que pueda. Solo´ soltara´ un tique en caso de conseguir recuperar el blade, no conseguir recuperarlo, o llevar a cabo una accion´ de recuperacion´ que conlleve una espera.
Terminan de ejecutar cuando no quedan tiques que atender.
Ticket: Un tique informa de que existe una anomal´ıa en un nodo de computo´ ademas´ de si esta´ siendo atendido por un Recoverer y desde cuando.
Es necesario crear el sistema de tiques en la base de datos, de tal forma que las peticiones sobre los tiques no se vean afectadas por condiciones de carrera.
Como hay acciones de recuperacion´ que conllevan largas esperas por parte de los recuperadores, estos podran´ soltar el tique que poseen para poder coger otro mientras dura la espera. Los tiques
– 63 – Cap´ıtulo 7. Recuperador Paralelo
deberan´ guardar el momento en el que se puedan volver a coger, y el estado en el que se libero´ para que el recuperador que lo coja sepa por donde seguir.
Recover: Una recuperacion´ es una accion´ que se puede llevar a cabo sobre un blade o un subsistema de este para intentar solucionar la incidencia. Las recuperaciones seran´ mas´ o menos complejas, formando unas parte de otras si es necesario, es decir, un Recover puede estar compuesto de varios Recovers.
Report: Representa el informe de salida del proceso de recuperacion.´ Va siendo rellenado por las accio- nes de recuperacion´ a medida que se van ejecutando. Tiene la capacidad de guardarse en una base de datos y de enviarse por correo electronico´ para el seguimiento por parte de los administradores de Magerit.
Blade: Representa el blade, tanto la parte hardware como la software. Es un concepto central del M3S. Contiene la informacion´ de estado y caracter´ısticas del blade. Ademas´ realiza mandatos de admi- nistracion´ sobre el blade f´ısico, como encenderlo, apagarlo o arrancarle servicios.
Log: Es el encargado de mantener un registro de las acciones de recuperacion´ que se ejecutan sobre blades y los resultados de las mismas.
7.2.3. Acciones de Recuperacion´
En esta nueva version´ las acciones de recuperacion´ comprueban antes de ejecutar si no estan´ desha- bilitadas, en caso de estarlo terminan con fracaso.
El concepto Recover no ha cambiado, pero a las caracter´ısticas identificadas en la fase anterior hay que anadirle˜ una nueva. Ahora las acciones de recuperacion´ pueden quedar a medias y pueden ser reanu- dadas en el punto en el que quedaron.
Esto ha obligado a cambiar la caracterizacion´ del resultado de un Recover:
El resultado de la ejecucion´ de un Recover puede ser:
Exito.´
Fracaso.
Un tiempo durante el que esta´ pospuesta la recuperacion.´
Si es un Recover compuesto, puede senalar˜ el siguiente Recover que ha de ejecutar.
Esta medida complica el concepto Recover ya que lo contamina con ideas que no son del comporta- miento en si de una accion´ de recuperacion.´ Lo que sucede es que el requisito de que una accion´ pueda
– 64 – 7.2. Diseno˜ reanudar su ejecucion´ despues´ de un tiempo es del ambito´ de la eficiencia del programa y no del modelo del dominio.
La composicion´ de Recovers no ha sido alterada. Puede verse el diagrama de clases resultante en la figura 6.2 en la pagina´ 57.
7.2.4. Hilos de ejecucion´
Los objetivos de esta segunda fase eran conseguir mas´ rapidez y robustez. Ambos se han alcanzado con la creacion´ de varios hilos de ejecucion.´
Para coordinar las acciones de todos estos hilos he creado un sistema de tiques inspirado en los sis- temas llamados bugtracker [28][3] que por ejemplo utilizan los administradores en CeSViMa para atender a los usuarios. Cuando un usuario tiene un problema manda un correo electronico´ explicando lo que le pasa. Ese correo es dirigido hasta este sistema que lo etiqueta y crea un tique asociado al mensaje. Cuando alguien de CeSViMa atiende un tique este´ queda asignado de tal forma que no puede ser atendido por dos personas al mismo tiempo. Cuando el problema es solucionado el tique se cierra y desaparece de los tiques abiertos. El sistema de tiques que se ha implementado para sincronizar los hilos de ejecucion´ funciona igual.
Cada Ticket guarda la siguiente informacion:´
El blade que tiene la incidencia.
El pid del Recoverer que lo esta´ atendiendo.
El Report de las acciones que se le han realizado a ese blade.
El timestamp de creacion.´
El timestamp de la ultima´ vez que fue cogido.
El timestamp del momento en el que deja de estar pospuesta la recuperacion´ del blade.
El Memento, que es el estado del Recoverer en el momento que solto´ el tique. Este concepto se explica mas´ adelante.
El sistema de tiques se encarga de controlar el acceso a dichos tiques de manera que no se den condiciones de carrera entre los hilos que necesitan manejarlos.
En el recuperador paralelo tenemos dos clases de hilos de ejecucion.´ La clase de hilo que ejecuta al WatchDog, que es unico´ durante la ejecucion´ del sistema, y la que ejecuta a un Recoverer, de estos
– 65 – Cap´ıtulo 7. Recuperador Paralelo hilos hay varios durante la ejecucion´ del sistema, el numero´ var´ıa segun´ la configuracion´ deseada pero su cantidad optima´ esta´ entre 7 y 8 hilos trabajadores.
7.2.4.1. Hilo WatchDog
Por un lado tenemos a la clase WatchDog, que es ejecutada por el proceso principal. Este proceso es el encargado de vigilar tanto a los nodos, como a los procesos de recuperacion.´
En la primera etapa de su ciclo de vida analiza el estado del LoadlLeveler de todos los nodos en busca de fallos. Cuando encuentra un nodo que no esta´ operativo crea un Ticket en el sistema de tiques, y continua´ con la busqueda.´
La segunda etapa de su ciclo de vida es la de vigilar a los Recoverers. Cada cinco minutos despierta y mira que haya tiques que lleven cogidos por un Recoverer demasiado tiempo, si es as´ı, mata el proceso Recoverer, libera el Ticket y crea un Recoverer nuevo. Esta es la forma de aumentar la tolerancia a fallos, de esta manera siempre tenemos el mismo numero´ de trabajadores ejecutando y no aseguramos de que van a terminar por atender a todos los blades.
Cuando no quedan mas´ tiques el WatchDog le dice al Report que se env´ıe y termina su ejecucion.´
7.2.4.2. Hilos Recoverer
Por otro lado tenemos la clase Recoverer. En su metodo´ constructor hace un fork del programa principal y se pone a reparar nodos. El´ no es el encargado de buscar nodos con problemas, eso ya lo han hecho otros (el WatchDog), el Recoverer es el encargado de ir atendiendo a los nodos que han sido identificados como no operativos.
El ciclo de vida de un Recoverer consiste en ir cogiendo Tickets a traves´ del sistema de tiques para intentar resolverlo, el proceso muere cuando no quedan mas tiques libres en el sistema.
Un Recoverer cerrara´ un Ticket cuando consiga reparar la aver´ıa del blade o cuando ningun´ Recover sea capaz de repararla.
Un Recoverer liberara´ un Ticket cuando el resultado del Recover ejecutado sea un tiempo de espera. Al liberar el tique se debera´ guardar en el´ el estado en el que se encontraba el Recoverer en el proceso de recuperacion.´ Cuando un Recoverer coge un tique que ya hab´ıa sido asignado antes debe recuperar el estado y continuar en ese punto de la recuperacion.´
Para disenar˜ la recuperacion´ de un estado anterior Recoverer se ha utilizado el patron´ Memento [10]. As´ı los trabajadores “recuerdan” por donde iban y siguen a partir de ese punto. En la figura 7.2 se puede ver la estructura del patron.´
– 66 – 7.2. Diseno˜
Figura 7.2: Diagrama de clase del patron´ Memento
Para poder continuar el proceso de recuperacion´ un Recoverer debe de conocer las acciones de recu- peracion´ y el numero´ de intentos que se han realizado en cada Recover, pero solo´ las de la jerarqu´ıa que conduce hasta el ultimo´ Recover ejecutado.
El comportamiento es similar al de la reanudacion´ de un proceso en un sistema operativo clasico.´ En un sistema operativo un proceso sigue ejecutando como si no hubiese parado porque guarda entre otras cosas, un recuerdo, una traza de lo que ha ido ejecutando hasta el momento. Ese recuerdo es la pila. As´ı sabe que´ camino de llamadas, dentro de la jerarqu´ıa de funciones, ha seguido su ejecucion.´
Siguiendo con el s´ımil, un proceso tambien´ guarda el Program Counter (PC), pero en nuestro caso no es necesario guardar por donde´ hay que seguir ya que todo Recover, como buen Command [10] solo´ ejecuta a traves´ de su metodo´ Run().
Estos conceptos son los que se han utilizado para disenar˜ el estado del Memento. El estado es una pila que guarda en cada elemento, el nombre del Recover y su variable tries, es decir, el numero´ de intentos que lleva esa accion´ de recuperacion.´
Para explicar el funcionamiento se plantea el siguiente escenario. Un Recoverer sobre un blade que tiene problemas de Ssh habra´ ejecutado en este orden: BladeRecover, SshRecover y las primera ac- cion´ de recuperacion´ simple SshRecover1. Al ejecutar el primer intento de recuperar el Ssh el proceso quedo´ pospuesto unos minutos, con lo que el Recoverer libero´ el tique guardando el Memento que se ve en la figura 7.3.
Cuando ha pasado el tiempo que el proceso fue pospuesto otro Recoverer ha cogido el tique y ha recuperado el Memento. Como el blade sigue sin estar operativo el Recoverer elimina el primer elemento de la pila, el ultimo´ Recover que ejecuto´ y crea el que se encuentra inmediatamente despues,´ le actualiza su atributo tries con el valor que guarda la pila + 1. Lo siguiente es ejecutar SshRecover y SshRecover2. Este segundo intento s´ı termina inmediatamente y con exito´ as´ı que el Recoverer cierra el tique y pide uno libre.
– 67 – Cap´ıtulo 7. Recuperador Paralelo
Figura 7.3: Memento de ejemplo 1
La figura 7.4 representa el estado en el momento en el que se cierra el tique.
Figura 7.4: Memento de ejemplo 2
7.3. Resultados
El recuperador paralelo, despues´ de pasar la etapa de pruebas, se ha podido comprobar que funciona mucho mas´ rapido´ que el recuperador secuencial (mas´ de 800 nodos en 40 minutos) y de manera muy robusta. Manda informes completos de todas las acciones de recuperacion´ que se realizan y permite deshabilitar las acciones de recuperacion´ de forma global o blade a blade individualmente.
El principal problema que presenta este recuperador paralelo es que tiene una logica´ de recuperacion´ muy agresiva y sobrecarga mucho a los servidores. Es un problema que se ha dado principalmente porque no se detecto´ en el analisis´ inicial. El fallo tambien´ se encontraba en la version´ secuencial pero como era tan lenta no llegaba a sobrecargar los servidores. El problema esta´ en la perseverancia de algunas acciones de recuperacion´ que a base de reintentos hac´ıan demasiadas peticiones a los servidores, los cuales se ve´ıan desbordados por las peticiones simultaneas´ de muchos blades intentando recuperarse. Concretando, el SshRecover era capaz de reiniciar hasta tres veces un nodo que no consegu´ıa arrancar el sshd con sus correspondientes peticiones a los servidores para que les diesen su imagen de disco. Otro ansioso era el GpfsRecover que ped´ıa a los servidores hasta tres veces que le permitieran montar el gpfs
– 68 – 7.3. Resultados si no se montaba inmediatamente, con lo que aumentaba la congestion´ de los servidores y las esperas para montar el sistema de ficheros distribuido en otros nodos.
Otro error que se ha detectado en esta version,´ que ya se encontraba en la anterior, ha sido lo poco efectivos que son los informes tan extensos. Entre tantas acciones realizadas no quedaba claro que´ nodos se hab´ıan recuperador y cuales no, importando solamente a los administradores lo que ha salido mal. Este error se ha detectado en esta segunda iteracion´ porque el sistema estuvo funcionando un tiempo.
La ultima´ pega que se le achaca a esta version´ es su limitada escalabilidad. Si la maquina´ crece en numero´ de nodos, para mantener la velocidad habr´ıa que crear mas´ procesos llegando a sobrecargar el servidor de gestion´ y sus interfaces de red.
– 69 –
Cap´ıtulo 8
Recuperador Distribuido
Estra iteracion´ surge solo´ para solucionar los problemas de la iteraacion´ anterior. En esta fase no se anade˜ nueva funcionalidad al recuperador.
8.1. Requisitos
La etapa de analisis´ de riesgos se enfrentaba al estudio de como´ mejorar los informes, graduar la agresividad del sistema y hacer mas´ escalable la solucion.´
Ahora mismo se tiene un recuperador automatico´ paralelo pero totalmente centralizado en el servi- dor de gestion.´ El recuperador actual tiene toda la “inteligencia” centralizada lo que fuerza a una gran transferencia de datos. Parece que lo mas´ logico´ es acercar esa “inteligencia” a los sistemas que se hayan que controlar. Es un pensamiento similar al paradigma de los agentes moviles´ Subseccion´ 2.2.3, donde se mueven los algoritmos hacia los datos y no al reves.´
Una posible aproximacion´ ser´ıa la de implementar el concepto Recoverer como un agente que se mueve entre los blades con problemas y recupera in situ el sistema danado.˜ Sin embargo existen varios problema en este enfoque. El primero, es el poco desarrollo que han tenido las plataformas de agentes moviles´ siendo demasiado arriesgado embarcarse en una tecnolog´ıa as´ı. El segundo ya se ha tratado en este documento, los nodos son sistemas inestables y un agente que se quede colgado en una accion´ de recuperacion´ no va a poder migrar y se perder´ıa la informacion´ que contuviese dicho agente. Ademas´ la tecnolog´ıa de agentes moviles´ obliga a instalar una agencia de agentes en cada nodo, lo que consumir´ıa muchos recursos en los blades, que deben ser utilizados exclusivamente para realizar calculos.´
– 71 – Cap´ıtulo 8. Recuperador Distribuido
Otra aproximacion,´ mas´ acertada, es similar a la que utilizan los satelites´ y sondas espaciales. Estos sistemas son totalmente autonomos´ y, si por ejemplo, no reciben comunicaciones desde tierra en un tiempo intentaran´ reiniciar su modulo´ de comunicaciones para tratar de solucionar el problema.
Utilizando este enfoque, cada nodo ser´ıa un sistema autogestionado que se recuperar´ıa de sus errores enviando su informe de estado a un recuperador central, el cual si no tiene noticias de algun´ nodo durante un tiempo determinado lo reiniciar´ıa para que se pudiese recuperar.
Del analisis´ de riesgos salen una serie de requisitos funcionales:
1. Mejorar los informes:
Solo´ se notificara´ a los administradores las recuperaciones que no han terminado satisfacto- riamente. En cada informe se debe incluir informacion´ concisa de los subsistemas que no funcionan adecuadamente.
2. Distribuir el sistema:
Distribuir el recuperador automatico´ haciendo que los nodos se autogestionen. Reducir la insistencia de las acciones de recuperacion´ para que los servidores no sufran tanto. Mantener el control sobre el sistema en todo momento. Hay que seguir pudiendo deshabilitar las acciones de recuperacion´ inmediatamente.
Y un conjunto de requisitos no funcionales:
1. Ejecutar sin necesitar la atencion´ de los administradores.
2. Ser suficientemente rapido´ para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.
3. Ejecutar sin interferir en los calculos´ de los usuarios.
4. Ejecutar sobrecargando el sistema lo menos posible, incluyendo los servidores.
8.2. Diseno˜
En esta iteracion´ se han eliminado muchos conceptos introducidos en la fase anterior ya que no eran necesarios. En el recuperador distribuido no hay hilos de ejecucion´ que sincronizar y cada recuperador solo´ atiende al nodo sobre el que ejecuta. Se ha vuelto en muchos aspectos al recuperador secuencial y se han ampliado acorde a las necesidades de distribucion´ del nuevo sistema.
– 72 – 8.2. Diseno˜
8.2.1. Proceso de recuperacion´
Esta es la version´ del recuperador que mas´ cambia el proceso de recuperacion.´ Ahora existen varias piezas ejecutando en computadores diferentes.
Por un lado se tienen los recuperadores automaticos´ que ejecutan en cada nodo cada cierto tiempo. Estos procesos comprueban que el estado del nodo es correcto, si hay algun´ fallo lo intentar recuperar, y finalmente informan del estado en el que se encuentra el blade. Para no sobrecargar el sistema los recuperadores antes de empezar a reparar el nodo duermen un tiempo aleatorio de tal manera que se que no se ejecuten al mismo tiempo todas las acciones de recuperacion´ de todos los nodos.
Por otro lado se encuentra el recuperador central, que sigue ejecutando en el servidor de gestion.´ Este proceso anota las “senales˜ de vida” que dan los recuperadores de los blades y si encuentra que algun´ nodo lleva demasiado tiempo sin dar senales˜ de vida lo reinicia. Para evitar que un nodo sea reiniciado indefinidamente se define un numero´ maximo´ de reinicios seguidos. Ademas´ es el encargado de notificar a los administradores de las tareas de recuperacion´ que no se han podido completar correctamente.
8.2.2. Modelo del dominio
Observando las tareas que hay que realizar en esta fase se han identificado varios conceptos que deben estar presentes en el diseno.˜
Figura 8.1: Diagrama de dominio del recuperador distribuido
Recoverer: Es el encargado de secuenciar el proceso de recuperacion.´ Primero pide que los Recovers chequeen el estado del blade, segundo, si algo ha fallado inicia las acciones de recuperacion´ del sistema que ha fallado y tercero, decide si hay que enviar el Report al CenterRecover o no.
– 73 – Cap´ıtulo 8. Recuperador Distribuido
Recover: Una recuperacion´ es una accion´ que se puede llevar a cabo sobre un blade o un subsistema de este para intentar solucionar la incidencia. Las recuperaciones seran´ mas´ o menos complejas, formando unas parte de otras si es necesario, es decir, un Recover puede estar compuesto de varios Recovers.Cada accion´ de recuperacion´ sabe comprobar el estado del sistema sobre el que actua.´
Marker: Es el encargado de gestionar las marcas que las acciones de recuperacion´ hacen para recordar, de una ejecucion´ a otra, el punto de la recuperacion´ por el que iban. Por ejemplo, la marca que planifica el apagado del nodo para la siguiente ejecucion.´
Report: Representa el informe de salida del proceso de recuperacion.´ Va siendo rellenado por las ac- ciones de recuperacion´ a medida que se van ejecutando. Es enviado desde los blades hasta el recuperador central y contiene el estado del blade, los sistemas que funcionan mal y como´ se han detectado los errores.
Log: Es el encargado de mantener un registro de las acciones de recuperacion´ que se ejecutan sobre el blade y los resultados de las mismas.
CentralRecoverer: Es el encargado de anotar los tiempos de los Reports enviados desde los blades, de esta manera si encuentra que algun´ nodo lleva demasiado tiempo sin dar senales˜ de vida lo reinicia para que el recuperador del blade pueda recuperarlo una vez que arranque de nuevo. Ademas´ notifica a los administradores de los errores no recuperados.
Blade: Representa el blade, tanto la parte hardware como la software. Es un concepto central del M3S. Contiene la informacion´ de estado y caracter´ısticas del blade. Ademas´ realiza mandatos de admi- nistracion´ sobre el blade f´ısico, como encenderlo o apagarlo.
8.2.3. Acciones de Recuperacion´
Las acciones de recuperacion´ en esta iteracion´ parten de la idea que se forjo´ en el recuperador secuen- cial, eliminando las caracter´ısticas introducidas en el recuperador paralelo. Las acciones de recuperacion´ vuelven a terminar con exito´ o fracaso exclusivamente. A partir de ah´ı, en esta version´ el concepto ha cambiado por dos factores, la ejecucion´ de forma local y la disminucion´ de la agresividad del sistema.
Para el recuperador distribuido las acciones de recuperacion´ realizan dos funciones:
1. Recuperacion:´ atribuido al metodo´ Run().
2. Diagnostico:´ atribuido al nuevo metodo´ Check().
El Recoverer en la primera version,´ o el WatchDog en la segunda, era el que buscaba los nodos no operativos, eso se hac´ıa as´ı porque solo´ se buscaba nodos con problemas en el LoadlLeveler, ahora
– 74 – 8.2. Diseno˜ que es mucho menos costoso ejecutar mandatos sobre el blade se puede realizar el chequeo completo del sistema. Es logico´ que cada accion´ de recuperacion´ sepa comprobar el estado del sistema en el que esta´ especializado as´ı que en esta tercera version´ cada Recover tiene un metodo´ Check() que realiza la comprobacion,´ devuelve si existe algun´ error, y actualiza el Report.
Aprovechando esta nueva capacidad cada Recover termina su ejecucion´ comprobando si ha tenido exito´ o no, ejecutando su propio metodo´ Check(). De esta manera, si el estado ha cambiado el Report sera´ modificado en consecuencia.
Como se puede ver en Figura 8.2 la composicion´ de Recovers no ha variado, pero se ha introducido en relacion´ un nuevo atributo (subRecovers) que es un vector representa las dependencias jerarquicas´ entre subsistemas que se puede ver en la Figura 5.1 de la pagina´ 46. Los diagnosticos´ son los que necesitan este nuevo atributo ya que para comprobar que un sistema funciona correctamente hay que comprobar antes que todos sus subsistemas funcionan correctamente.
Figura 8.2: Diagrama de clases de los Recovers en el recuperador distribuido
Las jerarqu´ıas quedan as´ı:
BladeRecover. subRecovers = { SshRecover, LoadlRecover }
LoadlRecover. subRecovers = { GpfsRecover, MyriRecover, MemRecover, LocalScratchRecover }
Para realizar el diagnostico´ completo del nodo basta llamar al comando Check() del BladeRecover ya que este´ llamara´ secuencialmente a los Check() de sus subRecovers. El SshRecover comprobara´ que mantiene la conectividad por ssh mientras que el LoadlRecover ejecutara´ los Check() de todos sus sub- Recovers antes de comprobar si tiene el demonio Loadl arrancado. El diagnostico´ devolvera´ si alguno de los recuperadores ha encontrado algun´ fallo ademas´ de tener, al final de la ejecucion´ un diagnostico´ completo en el Report.
– 75 – Cap´ıtulo 8. Recuperador Distribuido
En esta version´ se han eliminado la mayor´ıa de reintentos para no sobrecargar los servidores. Ahora mismo solo´ se reintenta montar una vez el Gpfs trancurridos 10 minutos desde el primer intento. El mismo GpfsRecover comprueba si no se ha montado el volumen transcurridas 2 horas desde el primer intento, y si esto pasa planifica la parada del blade. Este procedimiento es posible porque va dejando “marcas” de que´ ha ido ejecutando y cuando´ lo hizo, de tal manera que en las siguientes ejecuciones se puede comprobar y actuar en consecuencia. Toda la gestion´ de estas senales˜ la facilita el Marker.
Otra medida que se ha tomado para no saturar los servidores es que las acciones de recuperacion´ de los nodos no puedan reiniciar el blade, lo que pueden hacer es apagarlo y esperar a que el recuperador central vuelva a encender el nodo cuando crea conveniente. De esta manera se evita que un recuperador quede fuera de control y se reinicie continuamente pidiendo que le sirvan su imagen de disco cada vez.
8.2.4. Comunicacion´ entre recuperadores
Al distribuir la aplicacion´ surge un nuevo problema, la comunicacion´ entre procesos remotos. Son muchos los blades que deben de comunicarse con el CentralRecover al mismo tiempo por lo que se tuvo que pensar en un metodo´ de comunicacion´ que no saturara al servidor de gestion.´ Ademas´ se buscaba una solucion´ sencilla y que ofreciera garant´ıas ya que, por lo general, la comunicacion´ remota entre objetos suele requerir de mucho soporte de software para su uso.
La comunicacion´ entre objetos remotos es un tema muy extenso en el area´ de los sistemas distribuidos y existen multiples´ soluciones de implementar una RPC. Las mas´ habituales actualmente, sobre todo en el ambito´ de los servicios web, son soluciones basadas en eXtensible Markup Language (XML) como XML- RPC o Simple Object Access Protocol (SOAP). Otra solucion´ bastante usada, y mas´ sencilla, es utilizar las caracter´ısticas de serializacion´ propias de PHP, que codifica cualquier objeto o estructura de datos en un formato almacenable con el fin de transmitirlo a traves´ de la red.
Estas tecnolog´ıas suelen utilizar el protocolo HyperText Transfer Protocol (HTTP) para el transporte del mensaje, pero se descarto´ utilizar HTTP ya que es demasiado pesado para un servidor web procesar a la vez 1200 conexiones que requieren procesado PHP. Estudiando conexiones mas´ ligeras lo mas´ facil´ es utilizar como medio de transporte el correo electronico.´ Es una solucion´ contemplada por el World Wide Web Consortium (W3C) para el env´ıo de mensajes SOAP sobre Simple Mail Transport Protocol (SMTP) por lo que no parece descabellada su implementacion´ [29].
El servidor de correo que esta´ instalado en el servidor de gestion´ ha demostrado que es capaz de gestionar una gran cantidad de correos electronicos´ en muy poco tiempo sin afectar al rendimiento de la maquina´ y haciendo llegar todos los correros a su destinatario. Esto nos asegura que no vamos a saturar el servidor de gestion´ de Magerit a causa de los correos enviados por los recuperadores de los blades,
– 76 – 8.2. Diseno˜ aunque estos´ se env´ıen al mismo tiempo.
La idea es hacer que cada correo electronico´ que llegue a una direccion´ concreta del servidor de gestion´ se redirija a la entrada estandar´ del recuperador central, y que este´ lea el cuerpo del mensaje el cual contendra´ una RPC. Por comodidad la RPC sera´ un vector de PHP serializado que contendra´ el nombre del metodo´ a ejecutar y los argumentos correspondientes. Para evitar problemas de seguridad el cuerpo del correo va codificado y protegido mediante una firma digital.
Se puede ver un la secuencia de acciones que se realizan para ejecutar una RPC con el metodo´ pro- puesto en la Figura 8.3.
Figura 8.3: Ejemplo de ejecucion´ de una RPC
– 77 – Cap´ıtulo 8. Recuperador Distribuido
8.2.5. Informes efectivos
Uno de los requisitos de esta iteracion´ era el de mejorar los informes que se mandan a los adminis- tradores de Magerit.
Para conseguirlo se pretendio´ notificar solo´ las recuperaciones que no han terminado satisfactoria- mente y ademas,´ en cada informe solo´ se debe incluir informacion´ concisa de los subsistemas que no funcionan adecuadamente.
Despues´ de algunos prototipos se detecto´ que mejor que grandes explicaciones de las acciones que se han llevado a cabo, lo mas´ descriptivo para los administradores son las propias salidas de los mandatos sobre los que se detectaron los errores.
Ademas´ de dichas salidas, los informes deben incluir informacion´ acerca del estado de recuperacion´ en el que se encuentra el nodo afectado. Por ejemplo, es apropiado avisar claramente cuando se vaya a apagar un nodo, o decir cuantas´ veces se ha reiniciado en un corto espacio de tiempo.
Un ejemplo de un informe se puede ver en la Figura 8.4.
Figura 8.4: Ejemplo del correo electronico´ enviado
– 78 – 8.3. Resultados
8.3. Resultados
El recuperador distribuido funciona mucho mas´ rapido´ que las anteriores versiones ya que en un lapso de 5 minutos ejecuta las acciones de recuperacion´ sobre toda la maquina.´
Esta version´ ha corregido el problema de sobrecarga de los servidores de disco con lo que se prueba como una solucion´ altamente escalable. Hay que aclarar que en el intervalo de tiempo entre que se dejo´ de usar el recuperador paralelo y se instalo´ el recuperador distribuido Magerit ha sufrido un transado y una reconfiguracion´ que ha redundado en una mayor estabilidad del sistema. Por eso las comparaciones con la anterior version´ no son faciles´ de hacer.
Ahora los informes ayudan a los administradores a saber que´ fallos se estan´ dando en los nodos. Es un buen sistema para determinar errores graves en Magerit ya que si ocurre una ca´ıda masiva y todos los nodos, por ejemplo, muestran errores en el Gpfs es posible que el problema lo tengan los servidores.
Un defecto que se ha detectado es que en ca´ıdas masivas el buzon´ de correo de los administradores se inunda de mensajes de fallo, siendo mas´ comodo´ enviar un solo informe con un pequeno˜ analisis´ de los fallos que se han dado, para por ejemplo, poder decir que la mayor´ıa de los nodos han fallado por culpa del LoadlLeveler.
En lineas generales el sistema ahorra tiempo a los administradores de Magerit y anticipa la deteccion´ de errores mayores.
– 79 –
Cap´ıtulo 9
Diseno˜ de un recuperador experto
De forma paralela a la realizacion´ del recuperador distribuido se estudio´ las posibilidades del para- digma basado en el conocimiento, ver Subseccion´ 2.2.4, a la hora de enfrentarse al mismo problema de crear un recuperador automatico´ para Magerit.
Este estudio no es tan´ exhaustivo como el recuperador desarrollado como parte central de este pro- yecto, solo´ pretende hacer un boceto de los que ser´ıa un recuperador en este paradigma y tratar de sacar de el´ las ventajas y desventajas que supone frente al producto desarrollado sin tener en cuenta el nivel del conocimiento.
9.1. Justificacion´ del metodo´ elegido
Para la realizacion´ de este sistema se ha tenido que realizar una combinacion´ de varios metodos´ de resolucion´ de problemas [19]. Se han combinado el diagnostico´ causal (cubrir y diferenciar) y la planificacion´ jerarquica´ HTN y se ha tenido que crear un metodo´ para comunicar los diagnosticos´ del primer metodo´ con los planes del segundo. La estructura resultante es la mostrada en la figura 9.1.
Se Evaluo´ la posibilidad de utilizar clasificacion´ heur´ıstica, pero este metodo´ no aprovechaba todo el conocimiento que se tiene sobre el dominio. Parec´ıa que el metodo´ mas´ indicado era el de diagnostico´ re- presentando el modelo como componentes. Lo malo de esta solucion´ es que pretende hacer un simulador del sistema a estudiar y detectar discrepancias entre el sistema real y el modelo simulado. En este caso es inabordable realizar una simulacion´ de Magerit, con lo que este metodo´ quedaba fuera de alcance.
Seguidamente se intento´ imitar la forma en la que se resolvio´ el problema de gestion´ de redes de comunicaciones en el proyecto EXPERNET. En este proyecto se utilizo´ clasificacion´ jerarquica´ y plani-
– 81 – Cap´ıtulo 9. Diseno˜ de un recuperador experto
Figura 9.1: Arquitectura del metodo´ utilizado para el diagnostico´ y la recuperacion´ de fallos en Magerit
ficacion´ jerarquica´ HTN. Lo malo de la clasificacion´ jerarquica´ es que no se adecuaba a mi dominio, se buscaba un diagnostico´ que explicara s´ıntomas encontrados en Magerit.
Por descarte parec´ıa que el metodo´ adecuado para la fase de diagnostico´ era el diagnostico´ basado en modelos causal, es decir el metodo´ cubrir y diferenciar. Este´ es el que se ha utilizado porque queda a medio camino entre la heur´ıstica y la simulacion.´
Para la fase de recuperacion´ desde un primer momento el estudio se centro´ en la planificacion´ jerarquica´ HTN porque es un metodo´ eficiente de resolver problemas complejos en los que se tiene un sistema con un estado determinado y se necesita planificar una serie de acciones para cambiar el es- tado de dicho sistema. En el dominio del problema el sistema es evidente que se trata de Magerit y las acciones a realizar distan desde registrar el estado de los componentes hasta sustituir un aparato averiado pasando por reiniciar servicios colgados.
Para conectar ambos metodos´ se ha creado uno nuevo entre medias, producir y ordenar, que recoge las causas que sugiere el metodo´ cubrir y diferenciar y crea la gu´ıa que utilizara´ el metodo´ de planificacion´ jerarquica´ HTN para sugerir un plan al administrador.
– 82 – 9.1. Justificacion´ del metodo´ elegido
Figura 9.2: Estructura del metodo´ producir y ordenar
El metodo´ consta de dos inferencias:
producir: Esta inferencia traduce las causas que sugiere el diagnostico´ a las acciones que deberan´ ser refinadas en la etapa de planificacion.´ Las causas que no tienen produccion´ simplemente no gene- ran una accion.´ Estas causas suelen ser poco importantes, o transitorias, de manera que no merecen la atencion´ por parte del administrador.
Esta inferencia es doblemente util´ ya que ademas´ de traducir causas a acciones tambien´ deshecha aquellas causas insignificantes.
Se basa en el conocimiento que se encuentra en la base de conocimiento de producciones.
ordenar: Esta inferencia utiliza el conocimiento de la base de conocimiento de prioridades para ordenar las acciones de manera que el plan resultante tenga sentido. De esta forma podemos, por ejemplo, encender un nodo de computo´ antes de tratar de solucionar problemas en su software o reparar antes los fallos hardware que los software.
La salida de esta inferencia es un conjunto de acciones que funcionaran con el rol dinamico´ de gu´ıa para la planificacion´ jerarquica´ HTN.
9.1.1. Justificacion´ de las tecnicas´ de representacion´ simbolica´ utilizadas
Las tecnicas´ utilizadas han sido las marcadas por los metodos´ cubrir y diferenciar y planificacion´ jerarquica´ HTN. Ambos metodos´ imponen el uso de reglas y de estructuras.
– 83 – Cap´ıtulo 9. Diseno˜ de un recuperador experto
INFERENCIA producir DATOS: causas BASES DE CONOCIMIENTO: producciones RESULTADOS: acciones
INFERENCIA ordenar DATOS: acciones BASES DE CONOCIMIENTO: prioridades RESULTADOS: guıa´
Figura 9.3: Pasos de inferencia del metodo´ producir y ordenar
Rol dinamico´ Significado Representacion´
causas Causas sugeridas por el diagnostico´ conjunto de ternas marco instan- cia - atributos - valor acciones Conjunto de acciones que hay que ejecutar conjunto de estructuras para gestionar los errores propuestos por las causas gu´ıa Conjunto de acciones ya ordenadas segun´ las conjunto de estructuras refinara´ el metodo´ de planificacion´ jerarquica´ HTN
Cuadro 9.1: Roles dinamicos´ que intervienen en el metodo´ producir y ordenar
El metodo´ producir y ordenar, como es una mera conexion´ entre los dos anteriores, se adapta a dichas tecnicas´ de representacion´ simbolica.´
La modificacion´ que se ha introducido en los metodos´ originales [19] es que en vez de utilizar las ter- nas concepto-atributo-valor se ha pasado a una representacion´ de propiedades de marcos. Se ha buscado esta tecnica´ de representacion´ por varios motivos:
1. La riqueza expresiva de los marcos es superior a la de las ternas concepto-atributo-valor ya que, por ejemplo permite generalizar propiedades para varios conceptos por medio de las inferencias de herencia. Esta riqueza ha simplificado mucho las bases de conocimiento as´ı como las inferencias de los metodos´ producir y ordenar y de la planificacion´ jerarquica´ HTN. En el metodo´ cubrir y diferenciar no se ha utilizado esta caracter´ıstica ya que ha sido mas´ facil´ describir las relaciones
– 84 – 9.2. Conclusiones
causales de manera mas´ concreta.
2. El conocimiento sobre el dominio que se ten´ıa en mente estaba estructurado de manera similar a una jerarqu´ıa de marcos.
3. El sistema pretende ser lo mas´ automatico´ posible pero el metodo´ cubrir y diferenciar interactua´ mucho con el usuario. Los valores activos de los marcos, como se-necesita, me permiten elegir entre preguntar al usuario o ejecutar algun´ comando externo que de´ la informacion´ que se esta´ bus- cando.
4. Se han rellenado algunas ranuras de marcos clase con conjuntos de acciones. Esto ha permitido simplificar enormemente las acciones y estrategias del metodo´ de planificacion.´
Concretando, para recuperar todo sistema software hay que seguir unas acciones comunes y en un punto dado del plan ejecutar unas acciones de recuperacion´ concretas de cada sistema software. En la solucion´ propuesta la propiedad ’acciones-recuperacion’´ del marco que representa dicho software contiene un conjunto de acciones, representadas en estructuras, que son las necesarias para recuperar el sistema. Esto permite hacer el sistema mas´ flexible ya que si anadimos˜ mas´ sistemas a controlar no hace falta que modifiquemos la logica´ del modelo de planificacion´ sino solo´ tendremos que definir una propiedad del marco clase que estamos definiendo.
Para no cansar con detalles de bajo nivel se han colocado la descripcion´ del modelo y los ejemplos de ejecucion´ en un apendice´ de este documento. Se pueden consular en el Apendice´ A que se encuentra en la pagina´ 95.
9.2. Conclusiones
La gran ventaja de este enfoque es que anade˜ una flexibilidad imposible de conseguir con la metodo- log´ıa orientada a objetos. Aunque el diseno˜ que se ha realizado en los distintos recuperadores esta´ muy estructurado y es facil´ de extender tendra´ que ser un programador el que lo haga. Sin embargo para un administrador es mucho mas´ facil´ cambiar un fichero con reglas causa-efecto y as´ı modificar el compor- tamiento o extenderlo.
Una desventaja es que a priori estas soluciones se basan mucho en la interaccion´ con el usuario, y esa es una de las cosas que no buscabamos´ en un recuperador automatico.´
Sin embargo, la desventaja mas´ grande que encuentro es que para centrarse en la recuperacion´ de nodos, en donde el diagnostico´ y las acciones de recuperacion´ son bastante concretas, no es necesario aumentar tanto la complejidad de la aplicacion.´ Solo´ tendr´ıa sentido plantear una solucion´ as´ı si deseamos
– 85 – Cap´ıtulo 9. Diseno˜ de un recuperador experto tener bajo control toda la maquina´ ya que ah´ı intervienen razonamientos mas´ complejos y planes de recuperacion´ mas´ elaborados.
Una buena practica´ ser´ıa integrar la idea de base de conocimiento con reglas claras en el recuperador tradicional y as´ı permitir que los administradores sean capaces de ampliar las acciones de recuperacion´ del recuperador automatico.´
– 86 – Parte IV
Conclusiones y l´ıneas futuras
Cap´ıtulo 10
Conclusiones
El proyecto ha conseguido realizar un sistema de recuperacion´ automatica´ distribuida que cumple con los todos los objetivos que se marcaron en un principio:
Comprobar periodicamente´ el estado de los nodos de computo´ del supercomputador.
En caso de detectar alguna incidencia, realizar una serie de tareas predefinidas para intentar sub- sanarla de forma automatica.´
Avisar de la incidencias detectadas.
Generar un registro de actuaciones realizadas.
Ser deshabilitado inmediatamente a voluntad de los administradores para que no interfiera en las labores de estos.
Ser habilitado en cualquier momento para que continue´ con sus funciones.
Ser suficientemente rapido´ para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.
Ejecutar sin interferir en los calculos´ de los usuarios.
Ejecutar sobrecargando el sistema lo menos posible.
El recuperador automatico´ distribuido facilita el trabajo de administracion´ sobre Magerit y ahorra tiempo a los administradores de la maquina.´ Ademas,´ ahora la maquina´ se recupera de errores incluso
– 89 – Cap´ıtulo 10. Conclusiones cunado no hay administradores gestionandola.´ Otra mejora son los informes de errores que facilitan el seguimiento de incidencias y la elaboracion´ de partes de aver´ıas.
La aplicacion´ es facil´ de usar a traves´ de la l´ınea de comandos y proporciona ayuda sobre las fun- cionalidades que ofrece. Otro aspecto a destacar es la calidad del codigo´ escrito, que sigue la normativa del M3S y cerca del 40 % de las l´ıneas son comentarios. Ademas´ otro factor que demuestra la calidad del producto es la arquitectura del software. Se han utilizado tecnicas´ avanzadas en el diseno˜ de software y as´ı se ha expresado durante todo este documento. Pretende ser un valor anadido˜ el inca pie´ que se ha hecho en describir los razonamientos efectuados a la hora de disenar˜ el sistema. Es poco usual que se expliquen detenidamente los pasos que se dan hasta llegar al diseno˜ final y pretende ser esta´ una lectura beneficiosa para el que intente entender la mentalidad que se puede emplear para realizar aplicaciones de este tipo.
El resultado de este proyecto es un sistema informatico´ que es capaz de dotar de cierta autonom´ıa al supercomputador Magerit. El supercomputador ahora es capaz de solucionar algunos de los problemas que se pueden dar en sus componentes.
10.1. Analisis´ de esfuerzo
Este proyecto comenzo´ en septiembre de 2007 y concluyo´ en agosto de 2008 aunque durante este tiempo se realizaron muchas otras labores dentro de CeSViMa. Se estima que se han empleado 825 horas en el conjunto del proyecto. Ya que el ciclo de vida ha sido en espiral se han unidos las horas de las tres iteraciones que se han empleado en cada fase.
Fase Estimacion´ horas Porcentaje
Familiarizacion´ con el sistema a recuperar 55 6,67 % Analisis´ de riesgos 54,5 6,61 % Diseno˜ 163,5 19,82 % Implementacion´ 218 26,42 % Pruebas 109 13,21 % Documentacion´ 225 27,27 %
Total 825 100 %
Cuadro 10.1: Estimaciones de esfuerzo
Durante este tiempo se ha estimado que la familiarizacion´ con Magerit duro´ 55 horas, el analisis´ de
– 90 – 10.2. L´ıneas Futuras riesgos ha consumido unas 54 horas, el diseno˜ ha levado 163 horas, la implementacion´ ha supuesto el grueso del desarrollo y ha cubierto 218 horas, se han destinado 109 horas a la realizacion´ de pruebas y por ultimo,´ a documentar el proyecto se han dedicado 225 horas.
10.2. L´ıneas Futuras
El sistema se ha disenado˜ de forma que sea muy flexible a modificaciones con lo que esta´ orientado a que se sigan haciendo mejoras y anadidos.˜
Lo primero que habr´ıa que hacer es resolver los defectos encontrados en la ultima´ iteracion´ del proyecto. Para mejorar el sistema de avisos a los administradores se podr´ıa introducir una etapa entre medias de la recepcion´ de los mensajes al CentralRecoverer y el env´ıo del aviso al administrador de tal manera que se recopilaran los informes y se unificara la informacion´ a entregar.
Se podr´ıa aprovechar el estudio realizado sobre la ingenier´ıa del conocimiento e incluir en el recupe- rador distribuido las ventajas detectadas en el diseno˜ del sistema experto descritas en el Cap´ıtulo 9.
Para poder analizar los fallos que tiene Magerit ser´ıa muy conveniente incluir un modulo´ de data mining en el M3S que fuera capaz de realizar estad´ısticas de errores o elaboracion´ de historicos,´ con el objetivo de ayudar a los administradores a detectar carencias de configuracion´ en la maquina.´ Otro avance en este sentido es la integracion´ del recuperador automatico´ en la interfaz web de la consola de gestion´ que ya proporciona el M3S.
No puede faltar el comentario de que es posible que el proyecto, si demuestra un rendimiento optimo,´ llegue a mas´ computadores fuera del CeSViMa ya que la Red Espanola˜ de Supercomputacion´ (RES) dispone de mas´ supercomputadores con la misma arquitectura de Magerit.
Mas´ a largo plazo, y aprovechando que el diseno˜ del sistema esta´ bastante desacoplado de la arqui- tectura de Magerit se puede pensar en hacer un framework para sistemas de recuperacion´ automaticos.´ Ser´ıa util´ ya que los supercomputadores se quedan desfasados en no mucho tiempo y estan´ en continua ampliacion,´ sin ir mas´ lejos el CeSViMa ya esta´ planeando adquirir nuevos equipos de arquitecturas distin- tas a la de Magerit con lo que la adaptacion´ del recuperador automatico´ a las nuevas maquinas´ sera´ una necesidad no dentro de mucho tiempo.
– 91 –
Parte V
Anexos
Apendice´ A
Detalles del diseno˜ de un recuperador experto
En este apartado se describen los detalles de bajo nivel del diseno˜ del recuperador basado en la ingenier´ıa del conocimiento que se describe en el Cap´ıtulo 9 de la pagina´ 81.
Primero se puede ver la descripciond´ el modelo y despues´ dos ejemplos de como´ ejecutar´ıa el recu- perador.
A.1. Descripcion´ del modelo
En la figura 9.1 se puede contemplar una vision´ del modelo. Como se puede ver en el diagrama todas las inferencias utilizan una base de conocimiento que se llama ’componentes Magerit’, en esta se encuentra definido el conjunto de hechos en forma de jerarqu´ıa de marcos que explicare´ a continuacion.´ Mas´ adelante pasare´ a explicar una a una las bases de conocimiento que lo componen.
A.1.1. Vocabulario conceptual: jerarqu´ıa de marcos
Como se puede ver en la figura A.1 el modelo se ajusta a los componentes principales de Magerit. Las relaciones en gris son relaciones ’ad-hoc’, estan´ diferenciadas solo´ por legibilidad. No he incluido las propiedades en el diagrama para no complicarlo.
El componente central es el balde ya que es sobre el que se centra el analisis´ de diagnostico´ del sistema.
– 95 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
Figura A.1: Jerarqu´ıa de marcos del modelo
La herencia en el modelo es simple, ningun´ marco es subclase de mas´ de un marco clase.
Cabe destacar que el valor activo Si-Necesito por defecto lo he definido como PREGUNTAR/EJE- CUTAR porque para la implantacion´ del sistema ser´ıa bueno que las consultas no fuesen interactivas con el administrador, sino que se pudiera ejecutar un programa externo que devolviera el valor. En las propiedades que no exista este programa externo se deber´ıa preguntar al administrador.
A continuacion´ describire´ cada uno de los marcos clase definiendo cada una de sus propiedades.
– 96 – A.1. Descripcion´ del modelo
A.1.1.1. Componentes hardware
MC-hardware Tipo Car. Valores perm. Si necesito (*) nombre Caracteres 1/1 PREGUNTAR/ EJECUTAR (*) estado Caracteres 1/1 apagado, $h.parte-de = $Y → $Y.estado encendido (*) aver´ıa Caracteres 1/1 presente, PREGUNTAR/ EJECUTAR no-presente acciones-cambio conjunto 1/1 {} PREGUNTAR/ EJECUTAR de estruc- turas (*) parte-de Marco 0/n ∧MC- hardware
Cuadro A.1: Descripcion´ del marco clase hardware
MC-hdd Tipo Car. Valores perm. Si necesito acciones-cambio conjunto 1/1 {sacar-viejo(), meter- de estruc- nuevo()} turas sub-clase Marco 1/1 ∧MC-hardware parte-de Marco 1/1 ∧MC-blade
Cuadro A.2: Descripcion´ del marco clase hdd
– 97 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
MC-memoria Tipo Car. Valores perm. Si necesito (*) tamano˜ Decimal 1/1 [0..4] GB PREGUNTAR/ EJECU- TAR acciones-cambio conjunto 1/1 {quitar-estatica(),´ sacar- de estruc- viejos(), meter-nuevos()} turas sub-clase Marco 1/1 ∧MC-hardware parte-de Marco 1/1 ∧MC-blade
Cuadro A.3: Descripcion´ del marco clase memoria
MC-myrinet Tipo Car. Valores perm. Si necesito (*) blades-visibles Entero 1/1 [1..1198] PREGUNTAR/ EJECU- TAR acciones-cambio conjunto 1/1 {apretar-palanca(), sacar- de estruc- vieja(), meter-nueva()} turas sub-clase Marco 1/1 ∧MC-hardware parte-de Marco 1/1 ∧MC-blade
Cuadro A.4: Descripcion´ del marco clase myrinet
– 98 – A.1. Descripcion´ del modelo
MC-planar Tipo Car. Valores perm. Si necesito acciones-cambio conjunto 1/1 {quitar-estatica($viejo),´ sacar- de estruc- memorias($viejo), sacar- turas hdd($viejo), desatornillar- soporte-hdd($viejo), sacar- conector-hdd($viejo), sacar- myrinet($viejo), sacar- frontal($viejo), quitar-pegatina- id($viejo), desatornillar- soporte-myrinet($viejo), meter-memoria($nuevo), meter-conector-hdd($nuevo), atornillar-soporte-hdd($nuevo), meter-hdd($nuevo), atornillar- soporte-myrinet($nuevo), meter-myrinet($nuevo), poner- frontal($nuevo), poner-pegatina- id($nuevo) } sub-clase Marco 1/1 ∧MC-hardware parte-de Marco 1/1 ∧MC-blade
Cuadro A.5: Descripcion´ del marco clase planar
MC-red Tipo Car. Valores perm. Si necesito acciones-cambio conjunto 1/1 {consultar-ibm()} de estruc- turas sub-clase Marco 1/1 ∧MC-hardware parte-de Marco 1/1 ∧MC-blade
Cuadro A.6: Descripcion´ del marco clase red
– 99 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
A.1.1.2. Maquinas´
MC-maquina´ Tipo Car. Valores perm. Si necesito (*) conexion´ Caracteres 1/1 timeout, rechazada, lenta, PREGUNTAR/ EJECUTAR correcta (*) carga Caracteres 1/1 sobrecarga, media, nula PREGUNTAR/ EJECUTAR sub-clase Marco 1/1 ∧MC-hardware
Cuadro A.7: Descripcion´ del marco clase maquina´
MC-switch Tipo Car. Valores perm. Si necesito (*) nombre Entero 1/1 10, 11, 12 PREGUNTAR/ EJECUTAR acciones-cambio conjunto 1/1 {consultar-ibm()} de estruc- turas sub-clase Marco 1/1 ∧MC-maquina´
Cuadro A.8: Descripcion´ del marco clase switch
MC-servidor Tipo Car. Valores perm. Si necesito sub-clase Marco 1/1 ∧MC-maquina´
Cuadro A.9: Descripcion´ del marco clase servidor
MC-magerit Tipo Car. Valores perm. Si necesito (*) cola Caracteres 1/1 existente, inexistente PREGUNTAR/ EJECUTAR (*) error-generalizado-red12 Caracteres 1/1 presente, no-presente PREGUNTAR/ EJECUTAR (*) error-generalizado-red13 Caracteres 1/1 presente, no-presente PREGUNTAR/ EJECUTAR central-manager Marco 1/1 ∧MC-central-manager sub-clase Marco 1/1 ∧MC-maquina´
Cuadro A.10: Descripcion´ del marco clase magerit
– 100 – A.1. Descripcion´ del modelo
MC-balde Tipo Car. Valores perm. Si necesito (*) ocupacion´ Caracteres 1/1 libre, asignado PREGUNTAR/ EJECU- TAR servidor-gpfs Marco 1/1 ∧MC-servidor hdd Marco 1/1 ∧MC-hdd memoria Marco 1/1 ∧MC-memoria myrinet Marco 1/1 ∧MC-myrinet planar Marco 1/1 ∧MC-planar red12 Marco 1/1 ∧MC-red red13 Marco 1/1 ∧MC-red ssh Marco 1/1 ∧MC-ssh loadl Marco 1/1 ∧MC-loadl gpfs Marco 1/1 ∧MC-gpfs local-scratch Marco 1/1 ∧MC-local-scratch sub-clase Marco 1/1 ∧MC-maquina´
Cuadro A.11: Descripcion´ del marco clase blade
– 101 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
A.1.1.3. Componentes Software
MC-software Tipo Car. Valores perm. Si necesito (*) nombre Caracteres 1/1 PREGUNTAR/ EJECU- TAR (*) estado Caracteres 1/1 parado, colgado, correcto PREGUNTAR/ EJECU- TAR acciones-recuperacion´ conjunto 1/1 {} de estruc- turas
Cuadro A.12: Descripcion´ del marco clase software
MC-ssh Tipo Car. Valores perm. Si necesito (*) instancias Entero 1/1 PREGUNTAR/ EJECU- TAR acciones-recuperacion´ conjunto 1/1 { comprobar-etc-nologin(), de estruc- parar-servicio($s), arrancar- turas servicio($s) } sub-clase Marco 1/1 ∧MC-software parte-de Marco 1/1 ∧MC-blade
Cuadro A.13: Descripcion´ del marco clase ssh
– 102 – A.1. Descripcion´ del modelo
MC-loadl Tipo Car. Valores perm. Si necesito (*) instancias Entero 1/1 PREGUNTAR/ EJECU- TAR acciones-recuperacion´ conjunto 1/1 { parar-servicio($l), de estruc- arrancar-servicio($l) } turas sub-clase Marco 1/1 ∧MC-software parte-de Marco 1/1 ∧MC-blade
Cuadro A.14: Descripcion´ del marco clase loadl
MC-gpfs Tipo Car. Valores perm. Si necesito (*) estado Caracteres 1/1 desmontado, montado PREGUNTAR/ EJECU- TAR acciones-recuperacion´ conjunto 1/1 { mmstartup(), montar($g) de estruc- } turas sub-clase Marco 1/1 ∧MC-software parte-de Marco 1/1 ∧MC-blade
Cuadro A.15: Descripcion´ del marco clase gpfs
MC-local-scratch Tipo Car. Valores perm. Si necesito (*) estado Caracteres 1/1 desmontado, montado PREGUNTAR/ EJECU- TAR acciones-recuperacion´ conjunto 1/1 { montar($l) } de estruc- turas sub-clase Marco 1/1 ∧MC-software parte-de Marco 1/1 ∧MC-blade
Cuadro A.16: Descripcion´ del marco clase local-scratch
– 103 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
MC-central-manager Tipo Car. Valores perm. Si necesito acciones-recuperacion´ conjunto 1/1 {} de estruc- turas sub-clase Marco 1/1 ∧MC-software parte-de Marco 1/1 ∧MC-magerit
Cuadro A.17: Descripcion´ del marco clase central-manager
A.1.2. Relaciones Efecto-Causa
Esta base de conocimiento del metodo´ cubrir y diferenciar indica para cada s´ıntoma (o causa inter- media) las posibles causas que lo explican.
E1: $blade.red12.conexion´ = timeout → $blade.estado = apagado
E2: $blade.red12.conexion´ = timeout → $blade.red12.funcionamiento = incorrecto
E3: $blade.red13.conexion´ = timeout → $blade.estado = apagado
E4: $blade.red13.conexion´ = timeout → $blade.red13.funcionamiento = incorrecto
E5: $blade.red12.conexion´ = rechazada → $blade.ssh.estado = parado
E6: $blade.red12.conexion´ = rechazada → $blade.ssh.estado = colgado
E7: $blade.red13.conexion´ = rechazada → $blade.ssh.estado = parado
E8: $blade.red13.conexion´ = rechazada → $blade.ssh.estado = colgado
E9: $blade.red12.conexion´ = lenta → $blade.carga = sobrecarga
E10: $blade.red12.conexion´ = lenta → $switch12.carga = sobrecarga
E11: $blade.red13.conexion´ = lenta → $blade.carga = sobrecarga
E12: $blade.red13.conexion´ = lenta → $switch13.carga = sobrecarga
E13: $blade.red12.funcionamiento = incorrecto → $blade.red12.aver´ıa = presente
E14: $blade.red12.funcionamiento = incorrecto → $switch12.aver´ıa = presente
E15: $blade.red13.funcionamiento = incorrecto → $blade.red13.aver´ıa = presente
– 104 – A.1. Descripcion´ del modelo
E16: $blade.red13.funcionamiento = incorrecto → $switch13.aver´ıa = presente
E17: $blade.ocupacion´ = libre → $blade.estado = apagado
E18: $blade.ocupacion´ = libre → $magerit.cola = inexistente
E19: $blade.ocupacion´ = libre → $magerit.central-manager.estado = reservando
E20: $blade.ocupacion´ = libre → $blade.loadl.estado = colgado
E21: $blade.ocupacion´ = libre → $blade.loadl.estado = parado
E22: $blade.loadl.estado = parado → $blade.aver´ıa = presente
E23: $blade.loadl.estado = parado → $blade.gpfs.estado = desmontado
E24: $blade.loadl.estado = parado → $blade.local-scratch.estado = desmontado
E25: $blade.aver´ıa = presente → $blade.planar.aver´ıa = presente
E26: $blade.aver´ıa = presente → $blade.hdd.aver´ıa = presente
E27: $blade.aver´ıa = presente → $blade.myrinet.aver´ıa = presente
E28: $blade.aver´ıa = presente → $blade.memoria.aver´ıa = presente
E29: $blade.gpfs.estado = desmontado → $blade.red12.funcionamiento = incorrecto
E30: $blade.gpfs.estado = desmontado → $blade.servidor-gpfs.carga = sobrecarga
E31: $blade.local-scratch.estado = desmontado → $blade.hdd.aver´ıa = presente
A.1.3. Diferenciacion´
A.1.3.1. Relaciones causa-efecto
Esta base de conocimiento del metodo´ cubrir y diferenciar indica la necesidad de observar un cierto hecho para cuando se presente cierta causa.
M1: $blade.estado = apagado → $blade.red12.conexion´ = timeout
M2: $blade.estado = apagado → $blade.red13.conexion´ = timeout
M3: $blade.carga = sobrecarga → $blade.red12.conexion´ = lenta
M4: $blade.carga = sobrecarga → $blade.red13.conexion´ = lenta
– 105 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
M5: $blade.red12.conexion = correcta → $blade.estado = encendido
M6: $blade.red13.conexion = correcta → $blade.estado = encendido
M7: $blade.red12.conexion = lenta → $blade.estado = encendido
M8: $blade.red13.conexion = lenta → $blade.estado = encendido
M9: $blade.red12.conexion = correcta → $blade.ssh.estado = correcto
M10: $blade.red13.conexion = correcta → $blade.ssh.estado = correcto
M11: $blade.red12.conexion = lenta → $blade.ssh.estado = correcto
M12: $blade.red13.conexion = lenta → $blade.ssh.estado = correcto
M13: $blade.red12.aver´ıa = presente → $blade.red12.conexion´ = timeout
M14: $blade.red13.aver´ıa = presente → $blade.red13.conexion´ = timeout
M15: $switch12.aver´ıa = presente → $magerit.error-generalizado-red12 = presente
M16: $switch13.aver´ıa = presente → $magerit.error-generalizado-red13 = presente
M17: $magerit.central-manager.estado = reservando → $magerit.cola = presente
M18: $blade.loadl.instancias = 0 → $blade.loadl.estado = parado
M19: $blade.gpfs.estado = desmontado → $blade.loadl.estado = parado
M20: $blade.local-scratch.estado = desmontado → $blade.loadl.estado = parado
M21: $blade.hdd.aver´ıa = presente → $blade.local-scratch.estado = desmontado
M22: $blade.myrinet.blade-visibles = 1 → $blade.myrinet.aver´ıa = presente
M23: $blade.memoria.tamano˜ < 4GB → $blade.memoria.aver´ıa = presente
M24: $blade.estado = encendido → $blade.planar.aver´ıa = no-presente
A.1.3.2. Conocimiento circunstancial
Esta base de conocimiento del metodo´ cubrir y diferenciar indica la credibilidad de las hipotesis´ teniendo en cuenta solo´ observaciones circunstanciales.
C1: $blade.red12.conexion´ = timeout y $blade.red13.conexion´ = timeout → PREFERIR ($blade.estado = apagado, $blade.red12.aver´ıa = presente)
– 106 – A.1. Descripcion´ del modelo
C2: $blade.red12.conexion´ = timeout y $blade.red13.conexion´ = timeout → PREFERIR ($blade.estado = apagado, $blade.red13.aver´ıa = presente)
C3: $blade.red12.conexion´ = lenta y $blade.red13.conexion´ = lenta → PREFERIR ($blade.carga = so- brecarga, $switch12.carga = sobrecarga)
C4: $blade.red12.conexion´ = lenta y $blade.red13.conexion´ = lenta → PREFERIR ($blade.carga = so- brecarga, $switch13.carga = sobrecarga)
C5: $blade.ocupacion´ =libre → PREFERIR ($blade.estado = apagado, $magerit.cola = inexistente)
C6: $blade.ocupacion´ =libre → PREFERIR ($blade.loadl.estado = apagado, $magerit.cola = inexisten- te)
C7: $blade.ocupacion´ =libre → PREFERIR ($blade.loadl.estado = colgado, $magerit.cola = inexistente)
C8: $blade.ocupacion´ =libre → PREFERIR ($blade.estado = apagado, $magerit.central-manager.estado = reservado)
C9: $blade.ocupacion´ =libre → PREFERIR ($blade.loadl.estado = apagado, $magerit.central-manager.estado = reservado)
C10: $blade.ocupacion´ =libre → PREFERIR ($blade.loadl.estado = colgado, $magerit.central-manager.estado = reservado)
C11: $blade.loadl.estado = parado → PREFERIR ($blade.gpfs.estado = desmontado, $blade.aver´ıa = pre- sente)
C12: $blade.loadl.estado = parado → PREFERIR ($blade.local-scratch.estado = desmontado, $blade.aver´ıa = presente)
C13: $magerit.error-generalizado-red12 = presente → PREFERIR ($switch12.aver´ıa = presente, $bla- de.red12.aver´ıa = presente)
C14: $magerit.error-generalizado-red13 = presente → PREFERIR ($switch13.aver´ıa = presente, $bla- de.red13.aver´ıa = presente)
A.1.3.3. Refino
Esta base de conocimiento del metodo´ cubrir y diferenciar indica la necesidad de refinar un s´ıntoma preguntando informacion´ de mas´ detalle sobre dicho s´ıntoma, lo que permite discriminar mejor entre hipotesis.´
– 107 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
R1: $blade.ocupacion´ = libre → PREGUNTAR ($blade.loadl.instancias = 0)
R2: $blade.aver´ıa = presente → PREGUNTAR ($blade.myrinet.blade-visibles = 1)
R3: $blade.aver´ıa = presente → PREGUNTAR ($blade.memoria.tamano˜ < 4GB)
R4: $blade.red12.funcionamiento = incorrecto → PREGUNTAR ($magerit.error-generalizado-red12 = presente
R5: $blade.red13.funcionamiento = incorrecto → PREGUNTAR ($magerit.error-generalizado-red13 = presente
R6: $blade.ssh.estado = {colgado, parado} → PREGUNTAR ($blade.ssh.instancias = 0)
A.1.3.4. Cualificacion´
Esta base de conocimiento del metodo´ cubrir y diferenciar indica las condiciones que pueden anular relaciones efecto-causa.
N1: $blade.red12.conexion´ = rechazada y $blade.ssh.instancias = 0 → NO-EVOCA ($blade.red12.conexion´ = rechazada, $blade.ssh.estado = colgado)
N2: $blade.red13.conexion´ = rechazada y $blade.ssh.instancias = 0 → NO-EVOCA ($blade.red13.conexion´ = rechazada, $blade.ssh.estado = colgado)
N3: $blade.ocupacion´ = libre y $magerit.cola = inexistente → NO-EVOCA ($blade.ocupacion´ = libre, $magerit.central-manager.estado = reservando)
A.1.4. Estrategias de combinacion´
Esta base de conocimiento del metodo´ cubrir y diferenciar indica las excepciones al principio de parquedad para la generacion´ de combinaciones.
F1: $blade.ocupacion´ = libre y $magerit.central-manager.estado = reservado y $magerit.cola = presente → COMBINAR($magerit.cola = presente, $magerit.central-manager.estado = reservando)
A.1.5. Producciones
Esta base de conocimiento del metodo´ producir y ordenar indica si una hipotetica´ causa merece tener una accion´ que gu´ıe el proceso de recuperacion.´ Esta´ representada mediante reglas.
– 108 – A.1. Descripcion´ del modelo
D1: $blade.estado = apagado → encender($blade)
D2: $blade.ssh.estado = parado → reparar($blade.ssh)
D3: $blade.ssh.estado = colgado → reparar($blade.ssh)
D4: $switch12.carga = sobrecarga → registrar($switch12)
D5: $blade.red12.aver´ıa = presente → reparar($blade.red12)
D6: $blade.red13.aver´ıa = presente → reparar($blade.red13)
D7: $switch12.aver´ıa = presente → reparar(switch12)
D8: $switch13.aver´ıa = presente → reparar(switch13)
D9: $blade.loadl.estado = colgado → reparar($blade.loadl)
D10: $blade.gpfs.estado = desmontado → reaparar($blade.gpfs)
D11: $blade.local-scratch.estado = desmontado → reaparar($blade.local-scratch)
D12: $balde.planar.aver´ıa = presente → reparar($blade.planar)
D13: $balde.hdd.aver´ıa = presente → reparar($blade.hdd)
D14: $balde.memoria.aver´ıa = presente → reparar($blade.memoria)
D15: $balde.myrinet.aver´ıa = presente → reparar($blade.myrinet)
D16: $blade.servidor-gpfs.carga = sobrecarga → registrar($blade.servidor-gpfs)
A.1.6. Prioridades
Esta base de conocimiento del metodo´ producir y ordenar indica las prioridades de orden de ejecucion´ que existen entre las acciones que actuaran´ como gu´ıa para el proceso de recuperacion.´ Obedecen a criterios generales por lo que se ve muy favorecida por la representacion´ con marcos. Esta´ representada mediante reglas.
O1: instancia($X, switch) → antes(reparar($X), reparar($blade))
O2: parte-de(X, blade) → antes(reparar($switch12), reparar($X))
O3: antes(reparar($X), registrar($Y))
O4: sub-clase(X, hardware) y sub-clase(Y, software) → antes(reparar($X), reparar($Y))
– 109 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
O5: sub-clase(X, hardware) y parte-de(Y, X) → antes(reparar($X), encender($Y))
O6: antes(reparar($blade.gpfs), reparar($blade.loadl))
O7: antes(reparar($blade.local-scratch), reparar($blade.loadl))
A.1.7. Estrategias
Esta base de conocimiento del metodo´ de planificacion´ jerarquica´ HTN indica los criterios que se han de seguir para la seleccion´ de las estrategias.
Esta base de conocimiento ha quedado muy simple gracias a que mucha de la labor de escoger entre estrategias la realiza la produccion´ de acciones segun´ las hipotesis´ de diagnostico.´
S1: reparar(X) → gestionar-reparacion(X)´
S2: recuperar(X) y sub-clase(X, hardware) → recuperar-hardware(X)
S3: recuperar(X) y sub-clase(X, software) → recuperar-software(X)
A.1.8. Acciones
Esta base de conocimiento del metodo´ de planificacion´ jerarquica´ HTN indica las acciones de las que consta cada estrategia. Se expresa en forma de lista ordenada.
Esta base de conocimiento queda muy simplificada por la utilizacion´ de las ranuras de los marcos ’acciones-recuperacion’´ y ’acciones-cambio’. Estas dos propiedades contienen listas de acciones concre- tas espec´ıficas de cada concepto.
A1: gestionar-reparacion(X)´ → comprobar-error(X), registrar(X), recuperar(X)
A2: recuperar-hardware($X) → sacar-de-produccion($X),´ solicitar-recambio($X), $X.acciones-cambio, finalizar-cambio($X)
A3: recuperar-software($X) → $X.acciones-recuperacion´
A.1.9. Efectos
Esta base de conocimiento del metodo´ de planificacion´ jerarquica´ HTN indica los efectos que tienen las acciones concretas cuando se aplican.
X1: sacar-produccion(X)´ y parte-de(X, Y) y instancia($Y, blade) → $Y.estado := apagado
– 110 – A.2. Ejemplos de funcionamiento
X2: finalizar-cambio($X) → BORRAR-INSTANCIA($X)
X3: encender(X) y sub-clase(X, maquina) y $X.estado = apagado → $X.estado := encendido
A.2. Ejemplos de funcionamiento
A.2.1. Ejemplo 1: Existen fallos graves
En este primer ejemplo pretendo ilustrar todo el proceso del sistema experto desde el diagnostico´ hasta las acciones del plan de recuperacion´ que el sistema sugiere al administrador de Magerit.
Para ello solo´ basta con observar el s´ıntoma de que la conexion´ a un blade falla por encontrar un tiempo de espera largo:
observaciones = {$blade.red12.conexion´ = timeout}
combinaciones = {}
eventos = {$blade.red12.conexion´ = timeout}
1. cubrir(eventos → hipotesis-de-causa)´
REGLAS
E1: $blade.red12.conexion´ = timeout → $blade.estado = apagado
E2: $blade.red12.conexion´ = timeout → $blade.red12.funcionamiento = incorrecto
hipotesis-de-causa´ = {$blade.estado = apagado, $blade.red12.funcionamiento = incorrecto}
2. diferenciar(hipotesis-de-causa,´ observaciones → hipotesis-de-causa,´ eventos)
REGLAS
M1: $blade.estado = apagado → $blade.red12.conexion´ = timeout
M2: $blade.estado = apagado → $blade.red13.conexion´ = timeout
M1 se satisface con las observaciones
PREGUNTA-SISTEMA: ¿$blade.red13.conexion´ = timeout?
RESPUESTA: $blade.red13.conexion´ = rechazada
Se rechaza la hipotesis-de-causa:´ $blade.estado = apagado
R4: $blade.red12.funcionamiento = incorrecto → PREGUNTAR ($magerit.error-generalizado-red12 = presente
PREGUNTA-SISTEMA: ¿$magerit.error-generalizado-red12 = presente?
– 111 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
RESPUESTA: $magerit.error-generalizado-red12 = no-presente
eventos = {$blade.red13.conexion´ = rechazada, $magerit.error-generalizado-red12 = no-presente}
hipotesis-de-causa´ = {$blade.red12.funcionamiento = incorrecto}
3. cubrir(eventos → hipotesis-de-causa)´
REGLAS
E7: $blade.red13.conexion´ = rechazada → $blade.ssh.estado = parado
E8: $blade.red13.conexion´ = rechazada → $blade.ssh.estado = colgado
hipotesis-de-causa´ = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado, $bla- de.ssh.estado = colgado}
4. diferenciar(hipotesis-de-causa,´ observaciones → hipotesis-de-causa,´ eventos)
REGLAS
R6: $blade.ssh.estado = {colgado, parado} → PREGUNTAR ($blade.ssh.instancias = 0)
PREGUNTA-SISTEMA: ¿$blade.ssh.instancias = 0?
RESPUESTA: $blade.ssh.instancias = 0
N2: $blade.red13.conexion´ = rechazada y $blade.ssh.instancias = 0 → NO-EVOCA ($blade.red13.conexion´ = rechazada, $blade.ssh.estado = colgado)
Cancelamos la hipotesis-de-causa:´ $blade.ssh.estado = colgado
eventos = {$blade.ssh.instancias = 0}
hipotesis-de-causa´ = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado}
5. cubrir(eventos → hipotesis-de-causa)´
no hay reglas para $blade.ssh.instancias = 0
6. diferenciar(hipotesis-de-causa,´ observaciones → hipotesis-de-causa,´ eventos)
no hay reglas para las hipotesis-de-causa´
hipotesis-de-causa´ = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado}
observaciones = {$blade.red12.conexion´ = timeout, $blade.red13.conexion´ = rechazada, $magerit.error- generalizado-red12 = no-presente, $blade.ssh.instancias = 0}
7. combinar (hipotesis-de-causa,´ observaciones → combinaciones)
como $blade.red12.funcionamiento = incorrecto no es causa final:
combinaciones = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado}
– 112 – A.2. Ejemplos de funcionamiento
eventos = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado}
8. cubrir(eventos → hipotesis-de-causa)´
REGLAS
E13: $blade.red12.funcionamiento = incorrecto → $blade.red12.aver´ıa = presente
E14: $blade.red12.funcionamiento = incorrecto → $switch12.aver´ıa = presente
hipotesis-de-causa´ = {$blade.red12.aver´ıa = presente, $switch12.aver´ıa = presente ,$blade.ssh.estado = parado}
9. diferenciar(hipotesis-de-causa,´ observaciones → hipotesis-de-causa,´ eventos)
REGLAS
M13: $blade.red12.aver´ıa = presente → $blade.red12.conexion´ = timeout
M15: $switch12.aver´ıa = presente → $magerit.error-generalizado-red12 = presente
ya sabemos que $blade.red12.conexion´ = timeout, tambien´ sabemos que $magerit.error-generalizado- red12 = no-presente con lo que rechazamos $switch12.aver´ıa = presente
eventos = {}
hipotesis-de-causa´ = {$blade.red12.aver´ıa = presente, $blade.ssh.estado = parado}
observaciones = {$blade.red12.conexion´ = timeout, $blade.red13.conexion´ = rechazada, $magerit.error- generalizado-red12 = no-presente, $blade.ssh.instancias = 0}
10. combinar (hipotesis-de-causa,´ observaciones → combinaciones)
todas las hipotesis-de-causa´ son causas finales entonces:
causas-finales = {$blade.red12.aver´ıa = presente, $blade.ssh.estado = parado}
Como no hay mas´ combinaciones la etapa de diagnostico´ ha concluido con una solucion´ que explica todas las observaciones:
causas = {$blade.red12.aver´ıa = presente, $blade.ssh.estado = parado}
Comienza la etapa de priorizar:
1. producir (causas → acciones)
REGLAS
todas las causas son importantes y producen accion:´
D2: $blade.ssh.estado = parado → reparar($blade.ssh)
– 113 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
Figura A.2: Diagrama de diagnosticar en el ejemplo 1
D5: $blade.red12.aver´ıa = presente → reparar($blade.red12)
acciones = {reparar($blade.ssh), reparar($blade.red12)}
2. ordenar (acciones → gu´ıa)
antes reparamos los componentes hardware que los software
O4: sub-clase(X, hardware) y sub-clase(Y, software) → antes(reparar($X), reparar($Y))
gu´ıa = {reparar($blade.red12), reparar($blade.ssh)}
Comienza la etapa de recuperacion:´
gu´ıa = {reparar($blade.red12), reparar($blade.ssh)}
El estado es el que hemos ido descubriendo durante el diagnostico,´ es decir las observaciones del metodo´ cubrir y diferenciar.
estado = {$blade.red12.conexion´ = timeout, $blade.red13.conexion´ = rechazada, $magerit.error-generalizado- red12 = no-presente, $blade.ssh.instancias = 0}
La accion´ es la primera de la gu´ıa
accion´ = reparar($blade.red12)
1. seleccionar( accion,´ estado → estrategias )
– 114 – A.2. Ejemplos de funcionamiento
Figura A.3: Diagrama de priorizar en el ejemplo 1
REGLAS
S1: reparar(X) → gestionar-reparacion(X)´
estrategias = {gestionar-reparacion($blade.red12)´ }
estrategia = {gestionar-reparacion($blade.red12)´ }
2. refinar( estrategia → subplanes )
REGLAS
A1: gestionar-reparacion(X)´ → comprobar-error(X), registrar(X), recuperar(X)
subplanes = {{comprobar-error($blade.red12), registrar($blade.red12), recuperar($blade.red12)}}
subplan = {comprobar-error($blade.red12), registrar($blade.red12), recuperar($blade.red12)}
gu´ıa = {comprobar-error($blade.red12), registrar($blade.red12), recuperar($blade.red12), reparar($blade.ssh)}
accion´ = {comprobar-error($blade.red12)}
3. aplicar( estado, accion´ → estado)
no hay reglas que cambien el estado
plan = {comprobar-error($blade.red12)}
gu´ıa = {registrar($blade.red12), recuperar($blade.red12), reparar($blade.ssh)}
accion´ = {registrar($blade.red12)}
4. aplicar( estado, accion´ → estado)
no hay reglas que cambien el estado
– 115 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
plan = {comprobar-error($blade.red12), registrar($blade.red12)}
gu´ıa = {recuperar($blade.red12), reparar($blade.ssh)}
accion´ = {recuperar($blade.red12)}
5. seleccionar( accion,´ estado → estrategias )
REGLAS
S2: recuperar(X) y sub-clase(X, hardware) → recuperar-hardware(X)
estrategias = {{recuperar-hardware($blade.red12)}}
estrategia = {recuperar-hardware($blade.red12)}
6. refinar( estrategia → subplanes )
REGLAS
A2: recuperar-hardware($X) → sacar-de-produccion($X),´ solicitar-recambio($X), $X.acciones-cambio, finalizar-cambio($X)
subplanes = {{sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12), $blade.red12.acciones-cambio, finalizar-cambio($blade.red12)}}
subplan = {sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12), $blade.red12.acciones-cambio, finalizar-cambio($blade.red12)}
gu´ıa = {sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12), $blade.red12.acciones-cambio, finalizar-cambio($blade.red12), reparar($blade.ssh)}
accion´ = sacar-de-produccion($blade.red12)´
7. aplicar( estado, accion´ → estado)
REGLAS
X1: sacar-produccion(X)´ y parte-de(X, Y) y instancia($Y, blade) → $Y.estado := apagado
anado˜ al estado $blade.estado = apagado
estado = {$blade.red12.conexion´ = timeout, $blade.red13.conexion´ = rechazada, $magerit.error- generalizado-red12 = no-presente, $blade.ssh.instancias = 0, $blade.estado = apagado}
plan = {comprobar-error($blade.red12), registrar($blade.red12), sacar-de-produccion($blade.red12)´ }
gu´ıa = { solicitar-recambio($blade.red12), $blade.red12.acciones-cambio, finalizar-cambio($blade.red12), reparar($blade.ssh)}
accion´ = solicitar-recambio($blade.red12)
– 116 – A.2. Ejemplos de funcionamiento
8. aplicar( estado, accion´ → estado)
no hay reglas que cambien el estado
plan = {comprobar-error($blade.red12), registrar($blade.red12), sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12)}
gu´ıa = { $blade.red12.acciones-cambio, finalizar-cambio($blade.red12), reparar($blade.ssh)}
Sustituimos $blade.red12.acciones-cambio por su valor
gu´ıa = { consultar-ibm(), finalizar-cambio($blade.red12), reparar($blade.ssh)}
accion´ = consultar-ibm()
9. aplicar( estado, accion´ → estado)
no hay reglas que cambien el estado
plan = {comprobar-error($blade.red12), registrar($blade.red12), sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12), consultar-ibm()}
gu´ıa = { finalizar-cambio($blade.red12), reparar($blade.ssh)}
accion´ = finalizar-cambio($blade.red12)
10. aplicar( estado, accion´ → estado)
REGLAS
X2: finalizar-cambio($X) → BORRAR-INSTANCIA($X)
como se ha cambiado el componente, la instancia del componente antiguo ya no tiene sentido, por eso la borramos del estado con el procedimiento BORRAR-INSTANCIA.
estado = {$blade.red13.conexion´ = rechazada, $magerit.error-generalizado-red12 = no-presente, $blade.ssh.instancias = 0, $blade.estado = apagado}
plan = {comprobar-error($blade.red12), registrar($blade.red12), sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12), consultar-ibm(), finalizar-cambio($blade.red12)}
gu´ıa = { reparar($blade.ssh)}
accion´ = reparar($blade.ssh)
LLegados a este punto podemos ver que la gu´ıa ahora contiene la segunda de las producciones que creo´ la etapa de priorizar. Vemos que el orden se ha mantenido y podemos predecir que el plan que despliegue esta gu´ıa ira´ despues´ del que ya tenemos.
Como el arbol´ de busqueda´ es practicamente´ el mismo muestro el resultado final del metodo´ de planificaion´ jerarquica´ HTN y de todo el proceso:
– 117 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
plan-final = {comprobar-error($blade.red12), registrar($blade.red12), sacar-de-produccion($blade.red12),´ solicitar-recambio($blade.red12), consultar-ibm(), finalizar-cambio($blade.red12), comprobar-error($blade.ssh), registrar($blade.ssh), comprobar-etc-nologin(), parar-servicio($blade.ssh), arrancar-servicio($blade.ssh)}
exito´ = VERDADERO
Figura A.4: Diagrama de reparar en el ejemplo 1
La interaccion´ con el usuario ha sido:
PREGUNTA-SISTEMA: ¿$blade.red13.conexion´ = timeout?
RESPUESTA: $blade.red13.conexion´ = rechazada
PREGUNTA-SISTEMA: ¿$magerit.error-generalizado-red12 = presente?
RESPUESTA: $magerit.error-generalizado-red12 = no-presente
PREGUNTA-SISTEMA: ¿$blade.ssh.instancias = 0?
RESPUESTA: $blade.ssh.instancias = 0
A.2.2. Ejemplo 2: No hay fallos graves
Este segundo ejemplo esta´ planteado para ilustrar que el metodo´ que propongo distingue cuando las causas que explican los s´ıntomas observados son comunes, o poco graves. As´ı, si no encuentra causas graves, no planteara´ ningun´ plan de accion´ ya que no sera´ necesario que el administrador se preocupe por el estado de Magerit.
En este ejemplo observamos que la conexion´ a un blade es lenta.
observaciones = {$blade.red12.conexion´ = lenta}
– 118 – A.2. Ejemplos de funcionamiento
combinaciones = {}
eventos = {$blade.red12.conexion´ = lenta}
1. cubrir(eventos → hipotesis-de-causa)´
REGLAS
E9: $blade.red12.conexion´ = lenta → $blade.carga = sobrecarga
E10: $blade.red12.conexion´ = lenta → $switch12.carga = sobrecarga
hipotesis-de-causa´ = {$blade.carga = sobrecarga, $switch12.carga = sobrecarga}
2. diferenciar(hipotesis-de-causa,´ observaciones → hipotesis-de-causa,´ eventos)
REGLAS
M3: $blade.carga = sobrecarga → $blade.red12.conexion´ = lenta
M4: $blade.carga = sobrecarga → $blade.red13.conexion´ = lenta
M3 se cumple porque ya sabemos que $blade.red12.conexion´ = lenta
PREGUNTA-SISTEMA: ¿$blade.red13.conexion´ = lenta?
RESPUESTA: $blade.red13.conexion´ = lenta
eventos = {$blade.red13.conexion´ = lenta}
3. cubrir(eventos → hipotesis-de-causa)´
REGLAS
E11: $blade.red13.conexion´ = lenta → $blade.carga = sobrecarga
E12: $blade.red13.conexion´ = lenta → $switch13.carga = sobrecarga
hipotesis-de-causa´ = {$blade.carga = sobrecarga, $switch12.carga = sobrecarga, $switch13.carga = sobrecarga}
observaciones = {$blade.red12.conexion´ = lenta, $blade.red13.conexion´ = lenta}
4. diferenciar(hipotesis-de-causa,´ observaciones → hipotesis-de-causa,´ eventos)
REGLAS
usando el conocimiento circunstancial:
C3: $blade.red12.conexion´ = lenta y $blade.red13.conexion´ = lenta → PREFERIR ($blade.carga = sobrecarga, $switch12.carga = sobrecarga)
C4: $blade.red12.conexion´ = lenta y $blade.red13.conexion´ = lenta → PREFERIR ($blade.carga = sobrecarga, $switch13.carga = sobrecarga)
– 119 – Cap´ıtulo A. Detalles del diseno˜ de un recuperador experto
solo´ nos queda una hipotesis-de-causa´ = {$blade.carga = sobrecarga}
eventos = {}
observaciones = {$blade.red12.conexion´ = lenta, $blade.red13.conexion´ = lenta}
5. combinar (hipotesis-de-causa,´ observaciones → combinaciones)
la unica´ hipotesis-de-causa´ es causa final con lo que:
causas-finales = {$blade.carga = sobrecarga}
Una sola causa justifica los s´ıntomas observados
Esta causa es la entrada del metodo´ producir y ordenar. En este ejemplo se ve la otra utilidad de este metodo,´ ademas´ de conectar el diagnostico´ con el plan de reparacion´ filtra las causas que no se consideran importantes.
causas = {$blade.carga = sobrecarga}
Figura A.5: Diagrama de diagnosticar en el ejemplo 2
1. producir (causas → acciones)
no hay ninguna regla que produzca una accion.´ Que un blade este´ sobrecargado no parece motivo suficiente para realizar ningun procedimiento de reparacion,´ seguramente lo mejor en este caso es eso, no hacer nada y esperar a que se libere solo.
2. ordenar (acciones → gu´ıa)
no hay acciones que ordenar
– 120 – A.2. Ejemplos de funcionamiento
De esta manera la gu´ıa que se le pasa al metodo´ de planificacion´ jerarquica´ HTN es vac´ıa. Este metodo´ ante una gu´ıa vac´ıa lo que hace es terminar con:
exito´ = VERDADERO
La interaccion´ con el usuario ha sido:
PREGUNTA-SISTEMA: ¿$blade.red13.conexion´ = lenta?
RESPUESTA: $blade.red13.conexion´ = lenta
Este es el resultado del proceso completo, no hace falta hacer nada, todo parece ir bien.
– 121 –
Bibliograf´ıa
[1] F. Alonso Amo, L. Mart´ınez Normand, and F. Segovia Perez.´ Modelos de desarrollo de programas. 2002.
[2] B. W. Boehm. Software engineering economics. 1981.
[3] BugTracker. http://es.wikipedia.org/wiki/Bugtracker, 2008.
[4] CeSViMa. http://www.cesvima.upm.es/, 2008.
[5] B. Collins-Sussman, B. W. Fitzpatrick, and C. M. Pilato. Version Control with Subversion. 2007.
[6] L. Constantine and E. Yourdon. Structured design : fundamentals of a discipline of computer program and systems design. 1978.
[7] CTAN. http://ctan.org/, 2008.
[8] Drupal. http://drupal.org/, 2008.
[9] X. Ferre´ Grau and M. I. Sanchez´ Segura. Desarrollo Orientado a Objetos con UML. 2003.
[10] E. Gamma, R. Helm, R. Johnson, and J. M. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series). Addison-Wesley Pro- fessional, 11 1994.
[11] H. Gomma. A software design method for real-time systems. 1995.
[12] IBM. http://www.ibm.com/, 2008.
– 123 – Bibliograf´ıa
[13] IBM. http://www.redbooks.ibm.com/, 2008.
[14]S.K ung,¨ O. L., and S. Large. TortoiseSVN. Un cliente de Subversion para Windows. 2007.
[15] C. Larman. UML y Patrones. 1999.
[16] LaTeX. http://www.latex-project.org/, 2008.
[17] M. Lehman. Programs, life cycles and laws of software evolution. Journal of Systems and Software, 1980.
[18] N. Medinilla and I. Gutierrez.´ La incertidumbre como herramienta en la ingenier´ıa del software. IEEE America´ Latina vol.5, 2007.
[19] M. Molina. Metodos´ de resolucion´ de problemas. 2006.
[20] MySQL. http://www.mysql.com/, 2008.
[21] PEAR. http://pear.php.net/manual/en/standards.php, 2008.
[22] PEAR. http://pear.php.net/, 2008.
[23] PHP. http://www.php.net/, 2008.
[24] E. Project. http://www.eclipse.org/, 2008.
[25] W. W. Royce. Managing the development of large software systems: concepts and techniques. 1970.
[26] Subversion. http://subversion.tigris.org/, 2008.
[27] Tortoise. http://tortoisesvn.net/, 2008.
[28] R. Tracker. http://www.bestpractical.com/rt/, 2008.
[29] W3C. http://www.w3.org/TR/2007/REC-soap12-part0-20070427/, 2007.
[30] Wikipedia. http://es.wikipedia.org/, 2008.
[31] Zend. http://framework.zend.com/, 2008.
– 124 –