Universidad Polit´ecnica de Madrid
Facultad de Inform´atica
Proyecto fin de carrera
Sistema de recuperaci´on autom´atica de un
supercomputador con arquitectura de
cluster
Autor
: Juan Morales del Olmo
Tutores
: Pedro de Miguel Anasagasti
´Oscar Cubo Medina
Las ideas no duran mucho. Hay que hacer algo con ellas.
Santiago Ram´on y Cajal
Sinopsis
El continuo aumento de las necesidades de c´omputo de la comunidad cient´ıfica est´a ocasionando la proliferaci´on de centros de supercomputaci´on a lo largo del mundo. Desde hace unos a˜nos la tendencia es ha utilizar una arquitectura declusterpara la construcci´on de estas m´aquinas.
Precisamente laUPMcuenta con uno de estos computadores. Se trata de Magerit, el segundo super-computador m´as potente de Espa˜na que se encuentra alojado en elCeSViMay que alcanza los 16TFLOPS.
Los nodos de c´omputo de un sistema de estas caracter´ısticas trabajan exhaustivamente casi sin des-canso, por eso es frecuente que vayan sufriendo problemas. Las tareas de reparaci´on de nodos consumen mucho tiempo al equipo de administraci´on deCeSViMay 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 autom´atica sus nodos de c´omputo sin la intervenci´on de los administradores del sistema.
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 a˜nos 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 ense˜narme 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 compa˜neros del CeSViMa, a Oscar por haberme ense˜nado lo que no est´a en los escritos. A
Fernando por proteger a capa y estada, y tratar tan bien a los suyos. A Carlos por ense˜narme que el saber no ocupa lugar, s´olo 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 enCeSViMay por las ayudas prestadas.
A mis compa˜neros de aquella pr´actica de cuyo nombre no quiero acordarme, Adri, Geno, Giorgi y Clara.
A mis compa˜neros de clase, Bego, Sara, David, Riqui, Mario, Sergio y Anto. A la gente de Histri´on, por tantos buenos momentos figurando.
´Indice general
Sinopsis . . . I
Agradecimientos . . . III
´Indice general . . . V
´Indice de figuras . . . XI
´Indice de cuadros . . . XIII
Acr´onimos . . . XV
PARTEI INTRODUCCION Y OBJETIVOS´
1. Introducci´on . . . 3
1.1. CeSViMa . . . 3
1.2. Magerit . . . 5
1.3. Necesidades que cubre el proyecto . . . 6
1.4. Objetivos . . . 6
PARTEII 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 m´oviles . . . 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. M´odulos 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. Configuraci´on software . . . 31
3.7. Ejecuci´on de trabajos . . . 31
3.7.1. LoadLeveler . . . 32
´Indice general
4. Magerit Monitor and Management System . . . 33
4.1. Filosof´ıa . . . 33
4.2. Arquitectura . . . 34
4.3. Dise˜no . . . 35
4.3.1. Modelo vista controlador (MVC) . . . 35
4.3.2. Configuraci´on . . . 36
4.3.3. Base de datos . . . 36
4.4. Normativas . . . 36
4.4.1. Documentaci´on . . . 37
4.4.2. Codificaci´on . . . 37
4.4.3. Gesti´on 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
PARTEIII DESARROLLO DEL PROYECTO 5. Recuperaci´on Autom´atica . . . 45
5.1. Contexto . . . 45
5.2. Recuperaci´on manual . . . 47
5.3. An´alisis inicial . . . 48
5.3.1. L´ımites . . . 48
5.3.2. Interacci´on con el sistema . . . 49
5.3.3. Problemas . . . 49
5.3.4. Viabilidad . . . 51
6. Recuperador Secuencial . . . 53
6.1. Requisitos . . . 53
6.2. Dise˜no . . . 54
6.2.1. Proceso de recuperaci´on . . . 54
6.2.2. Modelo del dominio . . . 54
6.2.3. Acciones de Recuperaci´on . . . 55
6.3. Resultados . . . 59
7. Recuperador Paralelo . . . 61
7.1. Requisitos . . . 61
7.2. Dise˜no . . . 62
7.2.1. Proceso de recuperaci´on . . . 62
7.2.2. Modelo del dominio . . . 63
7.2.3. Acciones de Recuperaci´on . . . 64
7.2.4. Hilos de ejecuci´on . . . 65
7.2.4.1. HiloWatchDog . . . 66
7.2.4.2. HilosRecoverer . . . 66
7.3. Resultados . . . 68
8. Recuperador Distribuido . . . 71
8.1. Requisitos . . . 71
8.2. Dise˜no . . . 72
8.2.1. Proceso de recuperaci´on . . . 73
8.2.2. Modelo del dominio . . . 73
8.2.3. Acciones de Recuperaci´on . . . 74
8.2.4. Comunicaci´on entre recuperadores . . . 76
8.2.5. Informes efectivos . . . 78
8.3. Resultados . . . 79
´Indice general
9.1. Justificaci´on del m´etodo elegido . . . 81
9.1.1. Justificaci´on de las t´ecnicas de representaci´on simb´olica utilizadas . . . 83
9.2. Conclusiones . . . 85
PARTEIV CONCLUSIONES Y L´INEAS FUTURAS 10. Conclusiones . . . 89
10.1. An´alisis de esfuerzo . . . 90
10.2. L´ıneas Futuras . . . 91
PARTEV ANEXOS A. Detalles del dise˜no de un recuperador experto . . . 95
A.1. Descripci´on del modelo . . . 95
A.1.1. Vocabulario conceptual: jerarqu´ıa de marcos . . . 95
A.1.1.1. Componentes hardware . . . 97
A.1.1.2. M´aquinas . . . 100
A.1.1.3. Componentes Software . . . 102
A.1.2. Relaciones Efecto-Causa . . . 104
A.1.3. Diferenciaci´on . . . 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. Cualificaci´on . . . 108
A.1.4. Estrategias de combinaci´on . . . 108
A.1.5. Producciones . . . 108
A.1.6. Prioridades . . . 109
A.1.7. Estrategias . . . 110
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
´Indice de figuras
1.1. El supercomputador Magerit . . . 5
2.1. Complejidad del universo software . . . 11
2.2. Clasificaci´on 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 unBladeCenter . . . 25
3.4. Parte trasera de unBladeCenter . . . 26
3.5. Arquitectura de red de Magerit . . . 29
4.1. M´odulos que forman el sistemaMagerit Management and Monitoring System . . . . 34
4.2. Arquitectura del patr´on de dise˜noMVC . . . 35
5.2. Casos de uso del recuperador autom´atico . . . 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 recuperaci´on fallida . . . 58
6.4. Diagrama de clases del patr´on Command . . . 59
6.5. Diagrama de clases del patr´on Composite . . . 60
7.1. Diagrama de dominio del recuperador paralelo . . . 63
7.2. Diagrama de clase del patr´on 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 losRecoversen el recuperador distribuido . . . 75
8.3. Ejemplo de ejecuci´on de unaRemote Procedure Call(RPC) . . . 77
8.4. Ejemplo del correo electr´onico enviado . . . 78
9.1. Arquitectura del m´etodo utilizado para el diagn´ostico y la recuperaci´on de fallos en Magerit 82 9.2. Estructura del m´etodo producir y ordenar . . . 83
9.3. Pasos de inferencia del m´etodo 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
´Indice de cuadros
1.1. Instituciones y m´aquinas que componen la Red Espa˜nola de Supercomputaci´on (RES) . 4
2.1. Clasificaci´on de los sistemas software . . . 12
2.2. Ciclos de vida seg´un la incertidumbre . . . 13
9.1. Roles din´amicos que intervienen en el m´etodo producir y ordenar . . . 84
10.1. Estimaciones de esfuerzo . . . 90
A.1. Descripci´on del marco clase hardware . . . 97
A.2. Descripci´on del marco clase hdd . . . 97
A.3. Descripci´on del marco clase memoria . . . 98
A.4. Descripci´on del marco clase myrinet . . . 98
A.5. Descripci´on del marco clase planar . . . 99
A.6. Descripci´on del marco clase red . . . 99
A.7. Descripci´on del marco clase m´aquina . . . 100
A.8. Descripci´on del marco clase switch . . . 100
A.10.Descripci´on del marco clase magerit . . . 100
A.11.Descripci´on del marco clase blade . . . 101
A.12.Descripci´on del marco clase software . . . 102
A.13.Descripci´on del marco clase ssh . . . 102
A.14.Descripci´on del marco clase loadl . . . 103
A.15.Descripci´on del marco clase gpfs . . . 103
A.16.Descripci´on del marco clase local-scratch . . . 103
Acr´onimos
ATA Advanced Technology Attachment
BSC Barcelona Supercomputing Center. Centro de Supercomputaci´on de Barcelona
CD-ROM Compact Disc Read Only Memory. Disco compacto de solo lectura
CeSViMa Centro de Supercomputaci´on y Visualizaci´on de Madrid. M´as informaci´on en la p´agina 3 CIEMAT Centro de Investigaciones Energ´eticas, Medioambientales y Tecnol´ogicas
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. N´umero 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
IBM International Business Machines
IDE Integrated Drive Electronics. Dispositivo con electr´onica integrada
IP Internet Protocol
M3S Magerit Management Monitoring System. Sistema de gesti´on y monitorizaci´on de Magerit
Mbps Mega Bits per Second. Mega bits por segundo
MVC Modelo vista controlador
MM Management Module. Unidad de gesti´on
NFS Network File System. Sistema de ficheros de red
OPM Optical Pass-thru Module. M´odulo de conexi´on ´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. Acr´onimo recursivo dePreprocesador de Hipertexto PHP
POWER Performance Optimization With EnhancedRISC
RAID Redundant Array of Independent Drives. Conjunto redundante de discos independientes RAM Random Access Memory. Memoria de acceso aleatorio
RES Red Espa˜nola de Supercomputaci´on
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 programaci´on de uso del servidor
SATA SerialAdvanced Technology Attachment
SCM Sistemas de manejo de configuraci´on del software SMTP Simple Mail Transport Protocol
Acr´onimos
SOAP Simple Object Access Protocol
SSH Secure Shell
UPM Universidad Polit´ecnica de Madrid. M´as informaci´on en la p´agina 3 UPS Uninterruptible Power Supply. Sistema de alimentaci´on ininterrumpida
USB Universal Serial Bus. Bus serie universal
W3C World Wide Web Consortium
Parte I
Cap´ıtulo 1
Introducci´on
En la actualidad, la necesidad de potencia de c´omputo requerida por la comunidad cient´ıfica est´a en constante aumento. Para satisfacer esta necesidad es necesario contar con computadores capaces de hacer estos complejos c´alculos a velocidades que permitan obtener resultados en tiempos razonables.
Para ello, la Universidad Polit´ecnica de Madrid (UPM) cuenta con el mayor centro de
supercompu-taci´on de la Comunidad de Madrid: el Centro de Supercompusupercompu-taci´on y Visualizaci´on de Madrid (CeSViMa).
Este centro alberga y administra el supercomputador Magerit, el segundo m´as potente de Espa˜na.
1.1.
CeSViMaLaUPM es fundada en 1971 agrupando las escuelas de ense˜nanzas t´ecnicas, 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 laUPM, los primeros en iniciar su andadura fueron los
de arquitectura mientras que la escuela m´as recientemente incorporada es la Facultad de Inform´atica.
A finales del a˜no 2004, laUPMy el Centro de Investigaciones Energ´eticas, Medioambientales y
Tec-nol´ogicas (CIEMAT) decidieron aunar esfuerzos para crear elCeSViMa. Este centro nace con el objetivo
su-percomputador m´as potente de Espa˜na (Magerit). Tambi´en se dota al centro de una sala de visualizaci´on 3D interactiva y de un esc´aner terrestre.
Ante la necesidad de aumentar la capacidad de c´alculo que da servicio a la comunidad cient´ıfica, se inaugur´o en marzo de 2007 la Red Espa˜nola de Super-computaci´on (RES), auspiciada por el Ministerio de Educaci´on y Ciencia. Fue en-tonces cuando se procedi´o a realizar una actualizaci´on del supercomputador
Ma-reNostrum situado en elBarcelona Supercomputing Center(BSC), en la cual se sustituyeron los blades JS20 por blades JS21, ambos deIBM, con lo que se duplic´o su capacidad de c´omputo. La mitad de dichos
blades se utiliz´o para ampliar Magerit y el resto se reparti´o, a partes iguales, para crear una estructura distribuida de Supercomputadores en diferentes emplazamientos de la geograf´ıa espa˜nola. En Junio de 2008 finaliza una segunda ampliaci´on de Magerit que termina con la sustituci´on de 168 de los blades JS20 por JS21. En el momento de escribir estas l´ıneas laRESpresenta la configuraci´on que se describe
en la Tabla 1.1.
Nodo M´aquina Blade Noblades 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 M´alaga 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 m´aquinas que componen laRES
El acceso al servicio se gestiona mediante un comit´e 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 comit´e de acceso. Adem´as, cada uno de los centros dispone de un 20 % del uso de los recursos. Este reparto no es as´ı para elCeSViMa, el cual tiene acceso al 40 % de la m´aquina, ya que,
cuando se inaugur´o laRES, elCeSViMaya contaba con un supercomputador en propiedad, cuyos nodos
1.2. Magerit
1.2. Magerit
Magerit est´a 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 interconexi´on se utiliza una red Myrinet de fibra ´optica de altas prestaciones junto con redes auxiliares Gigabit para su control y gesti´on.
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 conexi´on exterior se realiza a trav´es de RedIRIS mediante enlaces de 1Gb y 10 Gb.
Figura 1.1:El supercomputador Magerit
Est´a ubicado en una sala acondicionada especialmente para su uso, la cual tambi´en debe estar en perfectas condiciones para el correcto funcionamiento del sistema. Esta sala cuenta con m´aquinas de re-frigeraci´on exclusivas, sistemas de detecci´on y extinci´on de incendios, sistemas de detecci´on de l´ıquidos, sistemas de alimentaci´on ininterrumpida, etc.
Debido a sus dimensiones, el sistema est´a configurado para procesar paquetes de trabajos en modo
maximizar el uso de la potencia del computador y procesar los trabajos de los distintos usuarios de la forma m´as r´apida posible.
1.3. Necesidades que cubre el proyecto
Magerit es el segundo computador m´as potente de Espa˜na, en el que actualmente est´an ejecutando 24 horas al d´ıa proyectos de m´as de 200 usuarios y alrededor de 80 grupos de investigaci´on. Por lo tanto es una m´aquina necesariamente de alta disponibilidad que debe ser lo m´as estable posible para que los cient´ıficos puedan ejecutar sus c´alculos sin problemas.
Para ilustrar la importancia del buen funcionamiento de esta m´aquina se puede rese˜nar que un d´ıa de parada de la misma es equivalente a la p´erdida de 3,75 a˜nos de ejecuci´on en una m´aquina 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 c´omputo un determinado d´ıa, ese d´ıa se habr´an 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 administraci´on deCeSViMatrabaja para que todos los sistemas que forman parte delclusterfuncionen a pleno rendimiento durante veinticuatro
horas al d´ıa los trescientos sesenta y cinco d´ıas del a˜no. 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. Adem´as precisar´ıa del trabajo de entre cinco y siete personas dedicadas en exclusiva a esta labor que, en el mejor de los casos, s´olo 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 m´aquina.
Pese a la potencia hardware de dicho equipo, viene acompa˜nado de s´olo unas pocas herramientas de gesti´on y administraci´on del sistema. El equipo de CeSViMa detect´o esta deficiencia y comenz´o el
proyectoMagerit Management Monitoring System(M3S) que consiste en el desarrollo de un conjunto de herramientas que simplifican la gesti´on del supercomputadorMagerit. Mi trabajo se enmarca dentro del M3Sy consiste en un m´odulo de recuperaci´on autom´atica de nodos.
1.4. Objetivos
Este proyecto tiene como objetivo principal el dise˜no, implementaci´on e implantaci´on de un sistema software que facilite la reparaci´on de aver´ıas en los nodos de c´omputo de Magerit.
1.5. Estructura de la Memoria
Comprobar peri´odicamente el estado de los nodos de c´omputo del supercomputador.
En caso de detectar alguna incidencia, realizar una serie de tareas predefinidas para intentar sub-sanarla de forma autom´atica.
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 contin´ue con sus funciones.
Ser suficientemente r´apido para que una ca´ıda masiva sea solucionada antes de lo que lo har´ıa un administrador.
Ejecutar sin interferir en los c´alculos 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 descripci´on del proyecto en s´ı y las conclusiones alcanzadas al t´ermino del proyecto.
En la parte del estado de la cuesti´on se explican los ciclos de vida y las metodolog´ıas que han sido estudiadas para la realizaci´on del proyecto, la arquitectura deMagerit tanto hardware como software y
el proyectoMagerit Management Monitoring System(M3S) donde se enmarca mi trabajo.
En la parte del desarrollo del proyecto se describe todo el contexto de la recuperaci´on autom´atica y las fases por las que ha pasado el proyecto. En todo este bloque se hace inca pi´e en las decisiones de dise˜no 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.
Parte II
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 pr´actica 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 realizaci´on del proyecto desde que se plantea el problema (habitualmente por parte del cliente) hasta que es resuelto por un sistema inform´atico. El ciclo de vida suele elegirse en funci´on de la complejidad del sistema a desarrollar.
La complejidad de un sistema software es la composici´on de la complejidad descriptiva (cantidad de informaci´on para describir el sistema) y la complejidad por incertidumbre (cantidad de informaci´on necesaria para resolver cualquier incertidumbre asociada con el sistema) [18].
Cap´ıtulo 2. Desarrollo de un sistema software
Es normal que cuando crece el tama˜no de un proyecto tambi´en 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 m´as acertado fijarnos en la incertidumbre que alberga el proyecto que en sus l´ıneas de c´odigo.
Existen m´ultiples ciclos de vida que abarcan diversos problemas seg´un sus caracter´ısticas. Una posi-ble clasificaci´on es seg´un 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 realizaci´on del proyecto desde
que se plantea el problema (habitualmente por parte del cliente) hasta que es resuelto por un sistema
inform´atico. Los ciclos de vida suelen asociarse al proceso de desarrollo software pero, debido a la
evoluci´on de los sistemas inform´aticos, actualmente tienden a aplicarse a todo el proceso del desarrollo
inform´atico. Existen m´ultiples ciclos de vida que abarcan diversos problemas seg´un sus caracter´ısticas.
Por ello tambi´en existen diversas clasificaciones, siendo una de las posibles la clasificaci´on 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 Plan
ificaci ón Ev aluaci ón Esencia Primer ciclo Segundo ciclo Análi sis d
e ries gos
Espiral Búsqueda
Figura 4.1:
Clasificaci´on de la incertidumbre
Los ciclos de vida comprenden desde el modelo en el que el problema est´a completamente definido
de forma estable (incertidumbre m´ınima) al desconocimiento del problema y de la forma de obtener
la soluci´on (incerti-dumbre m´axima), aunque la mayor´ıa de los problemas se encuentran en un punto
– 31 –
Figura 2.2:Clasificaci´on de la incertidumbre
Los ciclos de vida comprenden desde el modelo en el que el problema est´a completamente definido de forma estable (incertidumbre m´ınima) al desconocimiento del problema y de la forma de obtener la soluci´on (incertidumbre m´axima). La mayor´ıa de los problemas se encuentran en un punto intermedio. Cuanto menor sea la incertidumbre, el problema ser´a m´as sencillo de resolver y, por tanto, su ciclo de vida ser´a m´as directo y viceversa.
Los sistemas software se pueden clasificar seg´un su incertidumbre como muestra la Tabla 2.1. [17]
Problema Soluci´on 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:Clasificaci´on de los sistemas software
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 clienpar-te o escasa experiencia del equipo de desarrollo en sispar-temas similares o en las t´ecnicas a emplear. Esta indeterminaci´on puede producir cambios introducidos por el cliente o durante el descubrimiento de las t´ecnicas.
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 b´usqueda (dirigida o no) de la soluci´on.
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
B´usqueda
Cuadro 2.2:Ciclos de vida seg´un la incertidumbre
2.1.1. Ciclos de vida de referencia
En la Figura 2.2 se plantean los ciclos de vida m´as 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 formalizaci´on 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 codificaci´on sin an´alisis y dise˜no.
Figura 2.3:Ciclo de vida secuencial
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 adecuaci´on al cliente.
Figura 2.4:Ciclo de vida prototipado
Una variaci´on de este ciclo de vida es el prototipado r´apido, 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 m´as en otros ciclos de vida. Esta t´ecnica, como herramienta de an´alisis, 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 experimentaci´on y aprendizaje, a trav´es de los cuales se incrementa la funcionalidad, dando lugar a sucesivas versiones del software cada vez m´as completas.
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.
Bas´andose 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 modificaci´on de lo realizado en las primeras fases. El ciclo de vida evolutivo permite un desarrollo m´as flexible que el incremental, puesto que per-mite realizar una b´usqueda de la soluci´on retract´andose (modificando) cuando se detecta una gran desviaci´on entre el sistema desarrollado y el requerido.
2.2. Paradigmas
2.2. Paradigmas
Un paradigma de programaci´on es una colecci´on de modelos conceptuales que juntos modelan el proceso de construcci´on de un programa y determinan, al final, su estructura [1]. Esa estructura concep-tual de modelos est´a 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 programaci´on y no hay uno mejor que los dem´as sino que hay situa-ciones en las que un paradigma resulta m´as apropiado.
A continuaci´on se describen los paradigmas de programaci´on que est´an relacionados con el proyecto. Algunos han sido puestos en pr´actica mientras que otros solamente han sido estudiados para su uso y posteriormente descartados.
2.2.1. Estructurado
La idea original del dise˜no estructurado fue presentada en la d´ecada de los 70, por Larry Constantine [6]. El dise˜no estructurado enfoca el problema a trav´es 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 acci´on de diferentes procesos. Como consecuencia, se obtienen unos flujos de salida que llegan a los receptores de la informaci´on.
El dise˜no estructurado permite que el problema gu´ıe a la soluci´on. Ayuda a resolver la compleji-dad de los grandes sistemas a trav´es de la estructuraci´on de estos en cajas negras, y su organizaci´on en una jerarqu´ıa apropiada para su posterior implementaci´on. Ofrece tambi´en un conjunto de criterios para evaluar la calidad de un dise˜no con respecto al problema que pretende resolver. Utiliza t´ecnicas y herramientas, fundamentalmente gr´aficas, para realizar dise˜nos de f´acil comprensi´on, bas´andose es una serie de notaciones bastante conocidas como son los diagramas de flujo de datos (DFD), el diagrama entidad/relaci´on (E/R), etc.
Resumiendo, mediante el dise˜no estructurado se crea una jerarqu´ıa de m´odulos para implantar las especificaciones obtenidas en la fase de an´alisis.
2.2.2. Orientado a objetos
La programaci´on orientada a objetos ofrece caracter´ısticas que flexibilizan los dise˜nos y aumentan la reutilizaci´on de c´odigo:
Abstracci´on: 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 c´omo se implementan estas caracter´ısticas. Los procesos, las funciones o los m´etodos pueden tambi´en ser abstra´ıdos y cuando lo est´an, una variedad de t´ecnicas son requeridas para ampliar una abstracci´on.
Encapsulamiento: Significa reunir a todos los elementos que pueden considerarse pertenecientes a una
misma entidad, al mismo nivel de abstracci´on. Esto permite aumentar la cohesi´on de los com-ponentes del sistema. Algunos autores confunden este concepto con el principio de ocultaci´on, principalmente porque se suelen emplear conjuntamente.
Principio de ocultaci´on: Cada objeto est´a aislado del exterior, es un m´odulo natural, y cada tipo de
ob-jeto expone una interfaz a otros obob-jetos que especifica c´omo pueden interactuar con los obob-jetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificaci´on por quien no tenga derecho a acceder a ellas, solamente los propios m´etodos 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 abstracci´on.
Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo
nombre, al llamarlos por ese nombre se utilizar´a el comportamiento correspondiente al objeto que se est´e usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocaci´on de un comportamiento en una referencia producir´a el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en tiempo de ejecuci´on, esta ´ultima caracter´ıstica se llama asignaci´on tard´ıa o asignaci´on din´amica. Algunos lenguajes proporcionan medios m´as est´aticos (en ”tiempo de compilaci´on”) de polimorfismo, tales como las plantillas y la sobrecarga de operadores.
Herencia: las clases no est´an aisladas, sino que se relacionan entre s´ı, formando una jerarqu´ıa de
2.2. Paradigmas
comportamiento com´un. Cuando un objeto hereda de m´as de una clase se dice que hay herencia m´ultiple.
Mientras que en la programaci´on estructurada s´olo se escriben funciones que procesan datos, los programadores que emplean ´este paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicit´andoles que realicen sus m´etodos por s´ı mismos, delegando la responsabilidad a su vez en otros objetos si es necesario.
2.2.3. Agentes m´oviles
Los agentes m´oviles basan su filosof´ıa enmover el c´odigo a los datos en vez de los datos al c´odigo.
Representan un nuevo paradigma de programaci´on en el desarrollo de aplicaciones en red. En determi-nadas aplicaciones distribuidas representan la soluci´on ideal para el dise˜no, implementaci´on y manteni-miento de las mismas mediante una delegaci´on de tareas que requiere la visita de diversas plataformas o entornos de ejecuci´on por red. Este paradigma permite:
La reducci´on de la carga de tr´afico por la red ya que se eliminan todos los mensajes t´ıpicos de los procedimientos cliente-servidor. Adem´as se mueve el c´odigo hacia los datos y es que normalmente pesa menos el c´odigo 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 tama˜no como Internet.
La eliminaci´on de potenciales limitaciones f´ısicas en la m´aquina cliente, derivando las operaciones no realizables por la m´aquina local a otra m´aquina que s´ı sea capaz de realizarlas.
El r´apido despliegue de aplicaciones. Una vez montadas las agencias de agentes (entornos de ejecuci´on de los agentes) en las m´aquinas que van a formar la red s´olo hace falta crear los agentes en alguna agencia y dejar que migren a su gusto.
Todas estas caracter´ısticas han alentado mucha investigaci´on sobre este paradigma, pero por ser muy reciente no existen demasiadas plataformas de desarrollo y adem´as las existentes no se encuentran en un estado del todo maduro.
2.2.4. Basado en el conocimiento
desde las primeras propuestas de programaci´on estructuradas a los m´as recientes enfoques (orientaci´on a objetos, agentes software, etc). Por otra parte, en el campo de la inteligencia artificial se han desarrollado t´ecnicas de representaci´on del conocimiento y m´etodos de resoluci´on de problemas que han permitido plantear la arquitectura basada en el conocimiento. Estos sistemas basados en el conocimiento (tambi´en sistemas expertos) se caracterizan porque:
Simulan la forma natural de resolver problemas observada en las personas.
Encuentra la soluci´on del problema mediante un proceso de b´usqueda dirigida por criterios es-pec´ıficos de un dominio.
Este paradigma da como resultado m´etodos de resoluci´on 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 b´usqueda t´ıpicos de la inteligencia artificial. El cono-cimiento suele estar representado de forma descriptiva con t´ecnicas de inteligencia artificial como reglas, marcos, restricciones, redes bayesianas o l´ogica difusa entre otras. Este conocimiento est´a estructurado en clases que son el resultado de un an´alisis 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 pr´actica de los expertos hasta el conocimiento de control, que determina cu´al es el siguiente paso a dar dentro de un proceso de b´usqueda.
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 est´a desligado de cualquier inferencia.
Mucha capacidad para resolver problemas que no est´an 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.
Cap´ıtulo 3
El supercomputador Magerit
Magerit es un cl´uster formado por 1204 nodos de c´omputo. 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 llamadosBladeCenters.
Los nodos que pertenecen a unBladeCenter comparten los switch de comunicaciones, de control y la
alimentaci´on aunque son m´aquinas completamente individuales.
Adem´as de la capacidad de almacenamiento local de cada nodo, se dispone de 192TB de
almace-namiento principal proporcionado por 266 discos de 750GBen Redundant Array of Independent Dri-ves(RAID). Sobre estos discos se utiliza un sistema de ficherosGPFSaccesible desde cualquier nodo.
Tambi´en se dispone de un total de 19 servidoresIBMpSeries. 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 c´omputo que tienen a su cargo. 17 de estos servidores sonIBM p5 510, mientras que los 2 restantes sonIBMp4. El sistema de ficheros GPFS es servido por una serie de
servidores IBM Power5 y Power4. Adem´as de servir y controlar el sistema GPFS tambi´en proporcionan las im´agenes de los blades que tienen a su cargo.
La interconexi´on entre los distintos componentes del sistema, tanto nodos como servidores, se lleva a cabo mediante tres redes diferentes.
Una red Myrinet de alta velocidad dedicada exclusivamente al tr´afico 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 c´omputo deben pasarse datos entre ellos a gran velocidad, evitando as´ı esperas en los c´alculos.
3.1. BladeCenter JS20 y JS21
En Magerit coexisten nodoseServer BladeCenter JS20yeServer BladeCenter JS21, ambos deIBM
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.2GHzlos JS20 y 2.3GHzlos JS21. Cada uno de ellos posee 32KBde cach´e de
datos de nivel 1, 64KBde cach´e de instrucciones de nivel 1 y 512KBde cach´e de nivel 2.
Los procesadores est´an 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 m´aximo agregado de 8.8GBps.
Memoria. El subsistema de memoria est´a compuesto por el controlador de memoria y 4 m´odulos de
memoriaDDR1 333MHz(PC2700) cada uno de ellos de 1GBen los JS20 y 2GBen los JS21.
Entrada/Salida. El subsistema de entrada/salida est´a 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 est´a conectado a un m´odulo de entrada salida delBladeCenterpor medio de losmidplanesdel 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.
ControladorIntegrated Drive Electronics(IDE). Cada nodo incluye un controladorIDEy dos
conecto-res capaces de albergar discos durosIDEde 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 m´aquina
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.
PowerPC 970
or 970FX
Memory Controller and Host I/O Bridge (Northbridge) PowerPC 970 or 970FX PC2700 ECC Memory Modules 6.4 GBps or 8.8 GBps 5.3 GBps
HyperTransport PCI-X Tunnel
HyperTransport I/O Hub
Gigabit Ethernet Controller Expansion Card 6.4 GBps or 8.8 GBps 1.6 GBps 800 MBps 1.06 GBps 1.06 GBps BSMP Super I/O IDE
Disk DiskIDE UART
Boot FLASH NVRAM Real Time Clock USB Controllers IDE Controller Chassis Midplanes
Figura 3.1:Diagrama de bloques de un nodo JS20
en ellos son las de edici´on de documentos, compilaci´on, generaci´on de scripts, monitorizaci´on de trabajos, etc. No est´a permitida la ejecuci´on de c´omputos paralelos en estos nodos y, si se detecta, ´esta ser´a autom´aticamente abortada.
Nodos de c´omputo. Estos nodos est´an dedicados exclusivamente a la ejecuci´on de trabajos de usuari,
por lo que ning´un 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 m´aquina y planificar su ejecuci´on en un subconjunto de nodos de c´omputo. 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 c´omputo.
3.2.
BladeCenters
LosBladeCentrersest´an dise˜nados para instalarse en unrackest´andar de 19 pulgadas. Cada uno de
losBladeCentersocupa 7 unidades delrack, por lo que se pueden instalar un m´aximo de 6BladeCenters
login1 login2 login3 login4
Nodos interactivos (login)
Nodos de cómputo
Figura 3.2:Esquema general del supercomputador
En el frontal del BladeCenterse distinguen las catorce bah´ıas destinadas a alojar nodos y la bah´ıa
multimedia, compuesta por unCD-ROMy un puertoUSB, que puede asignarse a un ´unico blade.
En la parte trasera delBladeCenterse distinguen las siguientes partes:
UnManagement Module(MM)
Dos parejas de fuentes de alimentaci´on redundantes de 2000W cada una Dos ventiladores
Un switch Gigabit Ethernet
Un switch MyrinetOptical Pass-thru Module(OPM)
3.2.1. Management Module(MM)
ElMMproporciona las funciones siguientes:
Configuraci´on inicial delBladeCenter
3.2. BladeCenters
8 The IBMEserver BladeCenter JS20
2.1 Overview of the BladeCenter infrastructure
The BladeCenter JS20 is designed to be installed in the IBM ^ BladeCenter Type 8677. This section reviews the BladeCenter infrastructure that is relevant to the installation of the BladeCenter JS20.
2.1.1 BladeCenter chassis
The core component of the BladeCenter infrastructure is the BladeCenter chassis. Figure 2-1 illustrates the front view of the BladeCenter chassis. The BladeCenter chassis is designed to be installed in an industry standard 19-inch rack. Each BladeCenter chassis occupies seven rack units. You can install up to six BladeCenter chassis in a single 42U rack such as the IBM NetBAY42 Enterprise Rack.
In the front view of the BladeCenter chassis, you see these standard features:
Fourteen bays where you can install blade servers
A media bay containing one CD-ROM drive, one diskette drive, and a 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 unBladeCenter
Asignar los interfaces de la bah´ıa multimedia a un determinado nodo
ElMMest´a conectado a cada uno de los nodos y a los interfaces de entrada salida por medio de buses que discurren a lo largo delmidplanedelBladeCenter.
ElMMposee conectores por medio de los cuales se pueden conectar al mismo un teclado, rat´on y
pantalla de una consola para gestionar elBladeCenterlocalmente.
Tambi´en se puede acceder a estas funciones por medio del interfaz de red de diversas formas:
Usando un navegador web (HTTPoHTTPS)
Por medio de la l´ınea de mandatos con un clientetelnetoSSH
3.2.2. M´odulos de entrada salida
Los m´odulos de entrada salida permiten la comunicaci´on entre los nodos de unBladeCenter, entre BladeCentersy entre ´estos y el mundo exterior. Se pueden instalar un m´aximo de cuatro m´odulos de
en-trada salida seg´un las necesidades. En Magerit, ´unicamente se utilizan dos: Switch Ethernet y el m´odulo
OPM.
Los diferentes tipos de m´odulos de entrada salida, proporcionan conectividad con dos tipos de redes diferentes:
Cap´ıtulo 3. El supercomputador Magerit
Chapter 2. Hardware components 9
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 unBladeCenter
Myrinet
En cada uno de los BladeCenters de Magerit hay instalado un m´odulo 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 2GHzy 4GBde memoriaRAM. Adem´as tienen cuatro discos durosSATA, dos de 70GBy dos
de 300GB. Uno de los discos de 70GBalberga el sistema operativo local del servidor, mientras que uno
de los de 300GBest´a dedicado exclusivamente a contener las im´agenes del sistema operativo de los 70 nodos que tiene a su cargo. Estas im´agenes son id´enticas y es el servidor el encargado de exportarlas medianteNFS. 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 tambi´en tiene asignada la gesti´on de una parte del sistema de ficherosGPFS. Para
que una parte delGPFSsea visible a toda la m´aquina, los servidores que se encargan de la gesti´on de esa
3.4. Almacenamiento
Cuando un nodo desea acceder a disco, solicita la operaci´on a su servidor y ser´a este el encargado de realizar ese acceso, devolviendo los datos le´ıdos o el resultado de la escritura al nodo que lo solicit´o. En caso de que ese servidor no sea el que da acceso a esa parte del sistema de ficheros, pasar´a la informaci´on al servidor correspondiente que har´a la operaci´on y retornar´a los datos correspondientes.
De los 19 servidores hay uno de ellos cuya configuraci´on es radicalmente distinta al resto. Es el engargado de centralizar la gesti´on de toda la m´aquina, entre la que se encuentra el gestor de colas en-cargado de la planificaci´on. Gracias a este servidor se facilitan enormemente las tareas de administraci´on de la m´aquina puesto que ´el dispone de acceso a todos los componentes que integran Magerit: nodos de c´omputo,BladeCenters, servidores, switches de comunicaciones e, incluso, el sistema de refrigeraci´on
de la sala. En este servidor est´an alojadas las bases de datos de configuraci´on y de usuarios, la aplicaci´on que se ha desarrollado en este proyecto y otra serie de aplicaciones desarrolladas por elCeSViMapara la
gesti´on y control de Magerit.
3.4. Almacenamiento
El sistema de almacenamiento de informaci´on principal de Magerit est´a formado por 266 discos durosSATAde 750GBde capacidad a 7500rpms, lo que proporcionan una capacidad bruta de 192TB.
Los discos son gestionados porStorage Managers DS4100de IBMcon 2 tarjetas de acceso de fibra
´optica. Cada uno de los Storage Manager tiene a su vez una expansi´onEXP100. Las expansiones no tienen
tarjetas de fibra, pero est´an conectados directamente a losStorage Managerpor lo que en conjunto suman
28 discos. Estos sistemas est´an dise˜nados para ofrecer una alta disponibilidad y ser tolerantes a fallos. Las principales caracter´ısticas que poseen son:
ControladorasRAIDduales de alto rendimiento con puertos de 2Gbps
Soporte deRAID5
512MBde cach´e, 256MBpor controladora, con protecci´on por bater´ıas de hasta 3 d´ıas de
auto-nom´ıa
Fuentes de alimentaci´on redundantes
La configuraci´on l´ogica de los discos dentro de unStorage Manageres la siguiente:
Los 28 discos disponibles en cadaStorage Managery expansi´on se dividen en cinco grupos de cinco
discos sobre los que se crea unRAID5 de 1TBde capacidad ´util. Los tres discos sobrantes se configuran
Consecuentemente, para perder los datos de unarrayde discos completo, es necesario que fallen los
cinco discos delarrayen un breve lapso de tiempo.
Adem´as delRAID5 y los discos deHotSpare, el acceso a todos los sistemas de ficheros de Magerit de
forma paralela se realiza gracias aGPFS, un sistema de acceso paralelo y tolerante a fallos desarrollado
porIBM.
3.4.1. General Parallel File Sistem(GPFS)
El sistema de ficheros GPFSes una soluci´on de gesti´on de discos compartidos de altas prestaciones
que proporciona un acceso r´apido y efectivo a la informaci´on 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 m´aquinas en las pueden manejarse datos cr´ıticos que no sea recomendable perder por alg´un fallo. Adem´as funciona muy bien con ficheros de grandes dimensiones, como pueden ser los generados por simulaciones biol´ogicas o m´edicas.
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 10GBpor 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 c´odigo que sean usados por diferentes miembros de un mismo proyecto. Tambi´en tiene activado el sistema de cuotas, que depender´a del espacio solicitado por el jefe de proyecto al hacer la petici´on de recursos.
/gpfs/scratch/ es el espacio de almacenamiento masivo y temporal de la m´aquina. Cada usuario puede
usar este espacio para almacenar la informaci´on necesaria durante la ejecuci´on 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
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 disco
Nodos E/S (Interactivos) Nodos de proceso
Figura 3.5:Arquitectura de red de Magerit
Gracias a esta arquitectura de red, la parte de gesti´on de Magerit no influye en los c´alculos de los nodos y ´estos, a su vez, tampoco crean ning´un problema sobre el tr´afico 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 m´as tr´afico soporta, ya que por ella circulan las im´agenes del sistema
ope-rativo que los servidores env´ıan a los nodos durante la secuencia de arranque de ´estos. Tambi´en circulan todos los datos que deben ser le´ıdos o escritos en elGPFS. Debido a la gran cantidad de
ficheros a los que se accede simult´aneamente y al tama˜no medio de los mismos (variosGB
La red 10.13.0.0 utilizada por el equipo de administraci´on de Magerit para realizar tareas de gesti´on
de la m´aquina tales como acceso a los nodos v´ıaSSH, acceso alMM, acceso a los servidores, etc.
A esta red est´an conectados todos los servidores, as´ı como todos losBladeCenters. Los nodos de
c´omputo no est´an directamente conectados a esta red, pero se puede acceder a ellos por medio de losMMde losBladeCenters. A esta red tambi´en est´an conectadas las m´aquinas enfriadoras para
poder monitorizarlas remotamente.
Para la interconexi´on de todos los elementos, Magerit cuenta con dos switchesGigabit Ethernet CIS-CO 6509de altas prestaciones denominadosswitchAyswitchB. Ambos switches est´an interconectados
entre ellos para que, accediendo desde el exterior, se pueda tener acceso a todos los elementos de la m´aquina.
Cada uno de los switches cuenta con nueve tarjetas de 48 bocas de red para la conexi´on de todas las m´aquinas. ElswitchA, que da soporte a la red 10.12.0.0, adem´as cuenta con una tarjeta de fibra ´optica que
proporciona la red externa del centro. ElswitchBda soporte exclusivamente a las m´aquinas conectadas a
la red 10.13.0.0.
Todos los elementos que deben tener una direcci´on IP externa, est´an conectados a una tarjeta del switchAque tiene configuradas las direccionesIPp´ublicas. A esta tarjeta est´an conectados los nodos de
login, los sistemas de seguridad de la sala, y laUninterruptible Power Supply(UPS) para su
monitoriza-ci´on externa.
3.5.2. Myrinet
Myrinet es una red dise˜nada para la interconexi´on de clusters de altas prestaciones. Sus productos han sido desarrollados porMyricom 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, adem´as de su rendimiento, es que el procesamiento de
las comunicaciones de red se hace a trav´es de chips integrados en las tarjetas de red de Myrinet (Lanai chips), descargando a laCPUde parte del procesamiento de las comunicaciones.
Myrinet f´ısicamente consiste en dos cables de fibra ´optica,upstreamydownstream, conectados con
un ´unico conector. La interconexi´on se suele realizar mediante conmutadores y encaminadores. Estos dispositivos suelen tener capacidades de tolerancia a fallos, con control de flujo, control de errores y monitorizaci´on de la red. La primera generaci´on de productos Myrinet obten´ıa anchos de banda de 512
Mbps, la segunda de 1280Mbps, Myrinet 2000 obtiene 2Gbpsy la ´ultima, Myri-10G llega a los 10Gbps, y
3.6. Configuraci´on 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 tama˜no es importante. Actualmente el 3,6 % de los clusters que aparecen en la lista TOP500 utilizan esta tecnolog´ıa.
En cuanto almiddlewarede comunicaci´on, la inmensa mayor´ıa est´a desarrollado porMyricom.
Des-tacan las librer´ıas a bajo nivelGMyMX, las implementaci´on deMPI MPICH-GMyMPICH-MXy las
implementaciones deSocketsde alto rendimientoSocktes-GMySockets-MX.
Magerit cuenta con un total de seis switches Myrinet. Cinco de ellos son modeloM3-CLOS-ENCL.
Cada uno de ellos cuenta con 16 tarjetasM3-SW32-16Fde 16 bocas a las que se conectan todos los nodos
de c´omputo mediante cables de fibra ´optica. Tambi´en disponen de 4 tarjetasM3-4SW32-16Qde 16 bocas
para la interconexi´on entre los switches. Para que todos los switches puedan transferirse datos entre ellos, se dispone de un switch trocalM3-SPINE-ENCL. Este switch dispone de 16 tarjetas M3-4SW32-16Qa
las que se conectan el resto de switches.
3.6. Configuraci´on software
Todos los nodos de c´omputo de Magerit usan el sistema operativo SusESLES9(Linux 2.6.5). En el
proceso de arranque, cada uno de los nodos monta el sistema operativo mediante el protocoloNetwork File System(NFS).
Para que todos los nodos tengan una copia id´entica del sistema operativo, se dispone de un nodo con una configuraci´on diferente al resto. Este es el nodo llamadomaster. En ´el se halla la copiamaestra
del sistema operativo. Cada vez que es necesario hacer una modificaci´on que afecte a toda la m´aquina (nuevos usuarios, entradas en elcrontab, etc.) se hace sobre la copia local de este nodo para despu´es
sincronizar los cambios con el resto de las m´aquinas.
Para hacer estas sincronizaciones se usa el paquete de herramientas Diskless Image Management
(DIM).DIMes un paquete compuesto por una serie descriptsdesarrollado por Peter Morjan con las cuales
es posible gestionar las im´agenes del sistema operativo desde una ´unica copia para despu´es sincronizarlo con el resto de im´agenes que hay instaladas en los servidores de la m´aquina, para mantener la coherencia entre ellas.
3.7. Ejecuci´on de trabajos
En Magerit ejecutan trabajosbatch. Para gestionar la ejecuci´on de estos trabajos es necesario
dispo-ner de un gestor de colas que asigne los diferentes trabajos a lasCPUslibres en un determinado momento.
3.7.1. LoadLeveler
LoadlLeveleres una aplicaci´on distribuida que se compone de:
Un Central Manager que ejecuta en el servidor de gesti´on, ver Secci´on 3.3, y que gestiona las
colas de trabajos, distribuyendo la carga entre los nodos que est´en disponibles.
Un demonio Loadl corriendo en cada nodo de c´omputo delcluster. Este demonio es el que se
comunica con elCentral Managerpara transmitirle la disponibilidad delblade.
Este gestor de colas permite ejecutar trabajos secuenciales o paralelos en un cluster, reservando los recursos (nodos de c´omputo) que necesitan los distintos trabajos. Este proceso de asignaci´on depen-der´a de los recursos solicitados por el trabajo, la disponibilidad de dichos recursos en la m´aquina y las pol´ıticas de ejecuci´on que se hayan definido.
Para poder enviar un trabajo al supercomputador es necesario definirlo en unJob Command File
es-pecificando los recursos que deben reservarse.LoadLevelerse encargar´a de buscar y reservar los recursos
indicados entre los disponibles, optimizando el uso de la m´aquina y reduciendo el tiempo de espera de los distintos usuarios. En resumen, el gestor se encarga de maximizar la eficiencia del supercomputador.
3.8. Gesti´on
El objetivo de los administradores deCeSViMaes que este conjunto heterog´eneo de m´aquinas y
pro-gramas software que formanMagerit est´e disponible para la comunidad cient´ıfica veinticuatro horas al
d´ıa los trescientos sesenta y cinco d´ıas del a˜no. Es frecuente que debido a errores de programaci´on o al uso exhaustivo que dan los programas de c´alculo cient´ıfico a los nodos de c´omputo, ´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 est´a apagado o porque el demonioLoadl, ver Subsecci´on 3.7.1, no est´a corriendo
adecuadamente en el nodo.
Adem´as de eso los administradores deben preocuparse por gestionar las cuentas de usuario que dan acceso a la m´aquina, contabilizar y restringir las horas de ejecuci´on que cada grupo de investigaci´on consume o reparar las aver´ıas hardware o los fallos software que sucedan enMageritentre otras cosas.
Las ´unicas herramientas de gesti´on que proveeMageritson las prestadas por elManagement Module
Cap´ıtulo 4
Magerit Monitor and Management System
Magerit Management Monitoring System (M3S) es el nombre del proyecto que comenz´o el grupo
de administraci´on de CeSViMa en 2007 y que tiene el objetivo de crear una plataforma software que
facilite toda las labores de administraci´on del supercomputadorMagerit. Las tareas m´as importantes que
cubre el proyecto son monitorizar la m´aquina y su la sala, administrar las cuentas de usuarios, llevar la contabilidad de las horas que ejecuta cada proyecto de investigaci´on, elaborar informes de uso y mantener la m´aquina a pleno rendimiento.
Actualmente s´olo est´a implantado en elCeSViMapero como todos los supercomputadores de laRES
comparten la misma arquitectura y a sus usuarios es posible que elM3Stambi´en se instale en otros nodos
de la red.
4.1. Filosof´ıa
ElM3Stiene como premisa automatizar lo m´aximo posible todas las labores del equipo de adminis-traci´on que sean propias de la gesti´on deMagerit. Adem´as debe ser simple y directo de cara al usuario,
eliminando todo lo superfluo de manera que no distraiga o ralentice al administrador.
4.2. Arquitectura
El sistema se ha dise˜nado desde un primer momento con el objetivo de que sea f´acilmente ampliable, por eso tiene una arquitectura modular. Actualmente se compone de los m´odulos que se pueden ver en la Figura 4.1.
M3S
Gestión usuarios Monitorización Recuperación
automática Contabilidad
Figura 4.1:M´odulos que forman el sistemaMagerit Management and Monitoring System
M´odulo framework: Tiene como misi´on la de proporcionar un mecanismo est´andar de inclusi´on de
funcionalidad en el sistema. Asimismo, proporcionar´a dos servicios b´asicos a todos los m´odulos:
1. Unificaci´on 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 informaci´on para gestio-nar adecuadamente el supercomputadorMagerit. Esta necesidad precisa la inclusi´on de un
mecanismo de almacenamiento y gesti´on de dicha informaci´on.
M´odulo de usuarios: Permite gestionar y controlar los usuarios existentes en el sistema. Mediante este
m´odulo se automatizan de cierta forma las tareas de alta y baja de usuarios. Adem´as se encarga del env´ıo de notificaciones a usuarios y de proporcionar datos a otros m´odulos del sistema acerca de los usuarios.
M´odulo de contabilidad: Tiene como objetivo recopilar informaci´on sobre el uso de la m´aquina que
realizan los usuarios, permitir la consulta de estos datos por el equipo delCeSViMay crear informes
completos sobre el uso deMagerity las actividades de los investigadores de cada proyecto.
4.3. Dise˜no
M´odulo de recuperaci´on autom´atica: Es el caso de estudio de este proyecto. El objetivo de este m´odulo
es comprobar peri´odicamente el estado del sistema y, en caso de detectar alguna incidencia, realizar una serie de tareas predefinidas para intentar subsanarla de forma autom´atica.
4.3. Dise˜no
El dise˜no delM3Ses orientado a objetos, metodolog´ıa descrita en la p´agina 17. La metodolog´ıa cl´asica
estructurada fue desestimada ya que la aplicaci´on a desarrollar no se basa exclusivamente en la gesti´on de datos. Adem´as la necesidad de ampliar la funcionalidad del proyecto en el futuro empujaba hacia un dise˜no modular en el que unos m´odulos diesen servicio a otros. La metodolog´ıa orientada a objetos favorece la reutilizaci´on de c´odigo y aumenta la flexibilidad de la arquitectura que es una caracter´ıstica crucial para dise˜nos que no est´an cerrados desde un primer momento.
4.3.1. Modelo vista controlador (MVC)
Para mejorar la escalabilidad permitiendo que la aplicaci´on crezca sin problemas, y facilitar la modi-ficaci´on y el mantenimiento, el m´oduloframeworkestructura toda la aplicaci´on seg´un el patr´on de dise˜no MVC.
Figura 4.2:Arquitectura del patr´on de dise˜noMVC
Modelo: Esta es la representaci´on espec´ıfica de la informaci´on con la cual el sistema opera, usuarios,
m´aquinas, etc. La l´ogica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo cambiar el n´umero de serie de unbladesi el formato introducido es
Vista: Este presenta el modelo en un formato adecuado para manejarse por el usuario. Por ejemplo
mostrando las temperaturas de losbladesen 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 delM3Sel controlador est´a estructurado usando un patr´on
de comando [10] que encapsula las acciones y simplifica su extensi´on.
4.3.2. Configuraci´on
La configuraci´on de la aplicaci´on se guarda en un fichero que se lee cada vez que se ejecuta una llamada al programa. En este fichero se guarda informaci´on como el nombre de la base de datos y el servidor en el que ´esta est´a alojada, as´ı como el nombre del servidor de correo para posibles notificaciones que deban hacerse al equipo de administraci´on.
Tambi´en hay unflagque indica si la aplicaci´on est´a en desarrollo o en producci´on. Esteflages 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 aplicaci´on entra en la fase de producci´on.
4.3.3. Base de datos
ElM3Stiene una componente muy alta de almacenamiento y gesti´on de datos por lo que utiliza un
gestor de bases de datos relacional. La base de datos es utilizada a trav´es de una abstracci´on, ver Subsec-ci´on 4.5.2 en la p´agina 39, que permite programarla como si se tratara de una base de datos orientada a objetos integr´andola perfectamente con el Modelo del patr´onMVCdescrito en la Subsecci´on 4.3.1.
4.4. Normativas
Para unificar el producto, teniendo en cuenta que trabajar´an varias personas en el proyecto, se ha he-cho necesaria la definici´on de una serie de normas de documentaci´on e implementaci´on a aplicar durante el desarrollo delM3S. Ambas normativas se basan en el entorno elegido para el desarrollo: sistema
opera-tivoLinux, el paradigmaorientado a objetosy el lenguaje de programaci´onPHP. El ´unico inconveniente