sistema de recuperación automática de un supercomputador ... · los nodos de computo de un...
TRANSCRIPT
Universidad Politecnica de Madrid
Facultad de Informatica
Proyecto fin de carrera
Sistema de recuperacion automatica de unsupercomputador con arquitectura de
cluster
Autor: Juan Morales del Olmo
Tutores: Pedro de Miguel AnasagastiOscar 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 CreativeCommons. Para ver una copia de esta licencia, visite http://creativecommons.org/licenses/by-nc-sa/2.5/ o envie unacarta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
Las ideas no duran mucho. Hay que hacer algocon 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 I INTRODUCCION Y OBJETIVOS
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 II ESTADO 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 III DESARROLLO DEL PROYECTO
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 IV CONCLUSIONES Y LINEAS FUTURAS
10. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . 89
10.1. Analisis de esfuerzo . . . . . . . . . . . . . . . . . . . . . . 90
10.2. Lıneas Futuras . . . . . . . . . . . . . . . . . . . . . . . . 91
PARTE V ANEXOS
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 2. Desarrollo de un sistema software
Es normal que cuando crece el tamano de un proyecto tambien crezca la incertidumbre sobre este, ya
sea porque se incluyen conceptos ambiguos o por simple vaguedad a la hora de definir los requisitos. Es
por esto que a la hora de decidir el ciclo de vida a utilizar sea mas acertado fijarnos en la incertidumbre
que alberga el proyecto que en sus lıneas de codigo.
Existen multiples ciclos de vida que abarcan diversos problemas segun sus caracterısticas. Una posi-
ble clasificacion es segun el grado de incertidumbre que admiten.
Capıtulo 4
Ciclo 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. Los ciclos de vida suelen asociarse al proceso de desarrollo software pero, debido a la
evolucion de los sistemas informaticos, actualmente tienden a aplicarse a todo el proceso del desarrollo
informatico. Existen multiples ciclos de vida que abarcan diversos problemas segun sus caracterısticas.
Por ello tambien existen diversas clasificaciones, siendo una de las posibles la clasificacion por el grado
de incertidumbre que admiten.
Grado de incertidumbre +-
Fases
Cascada
Tamaño pequeño
Problema claramente definido.
Requisitos estables
Experiencia del equipo de
desarrollo en las técnicas
Tamaño medio.
Problema mal definido.
Requisitos variables
Experiencia insuficiente del
equipo de desarrollo.
Problema prácticamente
indefinido
Imposible generar requisitos.
No existen referencias similares.
Inge
nier
ía
Plani
ficac
ión
Evaluación
Esencia
Primer ciclo
Segundo ciclo
Análisis de riesgos
Espiral Búsqueda
Figura 4.1: Clasificacion de la incertidumbre
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 solucion (incerti-dumbre maxima), aunque la mayorıa de los problemas se encuentran en un punto
– 31 –
Figura 2.2: Clasificacion de la incertidumbre
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
solucion (incertidumbre maxima). La mayorıa de los problemas se encuentran en un punto intermedio.
Cuanto menor sea la incertidumbre, el problema sera mas sencillo de resolver y, por tanto, su ciclo de
vida sera mas directo y viceversa.
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 –
3.2. BladeCenters
Chapter 2. Hardware components 23
The architecture of the BladeCenter JS20 is illustrated by the diagram in Figure 2-7.
Figure 2-7 BladeCenter JS20 block diagram
The BladeCenter JS20 includes both base features and a range of optional features. We describe each of these in the sections that follow.
PowerPC970or
970FX
Memory Controller and Host I/O Bridge(Northbridge)
PowerPC970or
970FX
PC2700 ECCMemory Modules
6.4 GBpsor
8.8 GBps
5.3 GBps
HyperTransport PCI-X Tunnel
HyperTransport I/O Hub
GigabitEthernet
Controller
Expansion Card
6.4 GBpsor
8.8 GBps
1.6 GBps
800 MBps
1.06 GBps
1.06 GBps
BSMP
Super I/O
IDEDisk
IDEDisk UART
BootFLASH
NVRAMReal Time Clock
USBControllers
IDE Controller
ChassisMidplanes
Figura 3.1: Diagrama de bloques de un nodo JS20
en ellos son las de edicion de documentos, compilacion, generacion de scripts, monitorizacion de
trabajos, etc. No esta permitida la ejecucion de computos paralelos en estos 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
login1 login2 login3 login4
Nodos interactivos
(login)
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 –
3.2. BladeCenters
8 The IBM Eserver BladeCenter JS20
2.1 Overview of the BladeCenter infrastructureThe 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 chassisThe 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
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
Figura 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 –
Capıtulo 3. El supercomputador Magerit
Chapter 2. Hardware components 9
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 modules
� A redundant pair of blowers
Figure 2-2 BladeCenter chassis rear view
Figura 3.4: Parte trasera de un BladeCenter
Myrinet
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.
Conexión externa
(1Gbps)
Red Myrinet
(10.11.0.0/16)
UPM
Switch Myrinet
Gigabit interna
(10.12.0.0/16)
Gigabit IP Pública
(138.x.x.x)
Conexiones 1Gbps
64 TB discoNodos E/S
(Interactivos)
Nodos de proceso
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
Gestión usuarios Monitorización Recuperación automática Contabilidad
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
para gestionar los errores propuestos por las
causas
conjunto de estructuras
guıa Conjunto de acciones ya ordenadas segun las
refinara el metodo de planificacion jerarquica
HTN
conjunto de estructuras
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 recuperadorexperto
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,
encendido
$h.parte-de = $Y→ $Y.estado
(*) averıa Caracteres 1/1 presente,
no-presente
PREGUNTAR/ EJECUTAR
acciones-cambio conjunto
de estruc-
turas
1/1 {} PREGUNTAR/ EJECUTAR
(*) 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
de estruc-
turas
1/1 {sacar-viejo(), meter-
nuevo()}
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
de estruc-
turas
1/1 {quitar-estatica(), sacar-
viejos(), meter-nuevos()}
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
de estruc-
turas
1/1 {apretar-palanca(), sacar-
vieja(), meter-nueva()}
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
de estruc-
turas
1/1 {quitar-estatica($viejo), sacar-
memorias($viejo), sacar-
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
de estruc-
turas
1/1 {consultar-ibm()}
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,
correcta
PREGUNTAR/ EJECUTAR
(*) 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
de estruc-
turas
1/1 {consultar-ibm()}
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
de estruc-
turas
1/1 {}
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
de estruc-
turas
1/1 { comprobar-etc-nologin(),
parar-servicio($s), arrancar-
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
de estruc-
turas
1/1 { parar-servicio($l),
arrancar-servicio($l) }
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
de estruc-
turas
1/1 { mmstartup(), montar($g)
}
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
de estruc-
turas
1/1 { montar($l) }
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
de estruc-
turas
1/1 { }
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. Kung, 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 –