sistema de recuperación automática de un supercomputador ... · los nodos de computo de un...

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.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.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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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 –


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:



administrador.


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.


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


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 –


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.




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.



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 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 –


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 –


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:



administrador.


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


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.


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 –





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.



nistracion sobre el blade fısico, como encenderlo o apagarlo.


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 –


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 –


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 –


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 –


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.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


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 –


MC-memoria Tipo Car. Valores perm. Si necesito

(*) tamano Decimal 1/1 [0..4] GB PREGUNTAR/ EJECU-

TAR


de estruc-

turas

1/1 {quitar-estatica(), sacar-

viejos(), meter-nuevos()}



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


de estruc-

turas

1/1 {apretar-palanca(), sacar-

vieja(), meter-nueva()}



Cuadro A.4: Descripcion del marco clase myrinet

– 98 –


MC-planar Tipo Car. Valores perm. Si necesito


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) }



Cuadro A.5: Descripcion del marco clase planar

MC-red Tipo Car. Valores perm. Si necesito


de estruc-

turas

1/1 {consultar-ibm()}



Cuadro A.6: Descripcion del marco clase red

– 99 –


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


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


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


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


Cuadro A.10: Descripcion del marco clase magerit

– 100 –


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


Cuadro A.11: Descripcion del marco clase blade

– 101 –


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


de estruc-

turas

1/1 { comprobar-etc-nologin(),

parar-servicio($s), arrancar-

servicio($s) }

sub-clase Marco 1/1 ∧MC-software


Cuadro A.13: Descripcion del marco clase ssh

– 102 –


MC-loadl Tipo Car. Valores perm. Si necesito

(*) instancias Entero 1/1 PREGUNTAR/ EJECU-

TAR


de estruc-

turas

1/1 { parar-servicio($l),

arrancar-servicio($l) }



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


de estruc-

turas

1/1 { mmstartup(), montar($g)

}



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


de estruc-

turas

1/1 { montar($l) }



Cuadro A.16: Descripcion del marco clase local-scratch

– 103 –


MC-central-manager Tipo Car. Valores perm. Si necesito


de estruc-

turas

1/1 { }


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



E5: $blade.red12.conexion = rechazada→ $blade.ssh.estado = parado

E6: $blade.red12.conexion = rechazada→ $blade.ssh.estado = colgado



E9: $blade.red12.conexion = lenta→ $blade.carga = sobrecarga

E10: $blade.red12.conexion = lenta→ $switch12.carga = sobrecarga



E13: $blade.red12.funcionamiento = incorrecto→ $blade.red12.averıa = presente

E14: $blade.red12.funcionamiento = incorrecto→ $switch12.averıa = presente


– 104 –



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


M3: $blade.carga = sobrecarga→ $blade.red12.conexion = lenta


– 105 –


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


M15: $switch12.averıa = presente→ $magerit.error-generalizado-red12 = 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 –


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 –


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)



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 –


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)


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 –


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.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



hipotesis-de-causa = {$blade.estado = apagado, $blade.red12.funcionamiento = incorrecto}

2. diferenciar(hipotesis-de-causa, observaciones→ hipotesis-de-causa, eventos)

REGLAS



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 –


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}


REGLAS



hipotesis-de-causa = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado, $bla-

de.ssh.estado = colgado}


REGLAS

R6: $blade.ssh.estado = {colgado, parado} → PREGUNTAR ($blade.ssh.instancias = 0)

PREGUNTA-SISTEMA: ¿$blade.ssh.instancias = 0?

RESPUESTA: $blade.ssh.instancias = 0



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}


no hay reglas para $blade.ssh.instancias = 0


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 –


eventos = {$blade.red12.funcionamiento = incorrecto, $blade.ssh.estado = parado}


REGLAS



hipotesis-de-causa = {$blade.red12.averıa = presente, $switch12.averıa = presente ,$blade.ssh.estado

= parado}


REGLAS



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}


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 –


Figura A.2: Diagrama de diagnosticar en el ejemplo 1


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 –


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)}



– 115 –


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)


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 –




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()




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)


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}


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 –


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 –


combinaciones = {}

eventos = {$blade.red12.conexion = lenta}


REGLAS



hipotesis-de-causa = {$blade.carga = sobrecarga, $switch12.carga = sobrecarga}


REGLAS



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}


REGLAS



hipotesis-de-causa = {$blade.carga = sobrecarga, $switch12.carga = sobrecarga, $switch13.carga

= sobrecarga}

observaciones = {$blade.red12.conexion = lenta, $blade.red13.conexion = lenta}


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 –


solo nos queda una hipotesis-de-causa = {$blade.carga = sobrecarga}

eventos = {}

observaciones = {$blade.red12.conexion = lenta, $blade.red13.conexion = lenta}


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 –


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 –

http://es.wikipedia.org/wiki/Bugtracker

http://www.cesvima.upm.es/

http://ctan.org/

http://drupal.org/

http://www.ibm.com/

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 –

http://www.redbooks.ibm.com/

http://www.latex-project.org/

http://www.mysql.com/

http://pear.php.net/manual/en/standards.php

http://pear.php.net/

http://www.php.net/

http://www.eclipse.org/

http://subversion.tigris.org/

http://tortoisesvn.net/

http://www.bestpractical.com/rt/

http://www.w3.org/TR/2007/REC-soap12-part0-20070427/

http://es.wikipedia.org/

http://framework.zend.com/

sistema de recuperación automática de un supercomputador ... · los nodos de computo de un...

Documents