Repositorio Institucional de Documentos

Proyecto Fin de Carrera de Ingeniería en Informática Desarrollo de un Sistema de Información para la Red Española de Supercomputación Víctor Civitani Monzón Codirector: Guillermo Losilla Anadón Codirector: Arturo Giner Gracia Instituto de Biocomputación y Física de Sistemas Complejos (BIFI) Ponente: Eduardo Mena Nieto Departamento de Informática e Ingeniería de Sistemas Área de Lenguajes y Sistemas Informáticos Abril 2011 i It always seems impossible, until it is done. Nelson Mandela Agradecimientos A mis directores, Guillermo Losilla y Arturo Giner, que han logrado que me sienta integrado y a gusto en el BIFI desde el primer momento, por su atención y ayuda constantes, por esa actitud positiva que siempre me han transmitido. A mi ponente Eduardo Mena, por su disposición y atención continua a todo tipo de consultas, por sus consejos e ideas que han simplicado tanto trabajo y que me han sacado de varios apuros. A todos mis amigos que han estado ahí apoyándome y soportándome a lo largo de toda la carrera, Miguel, José Miguel, Carlos, Ruth, Esther, Álvaro, y todos los que me dejo en el tintero sin quererlo. A todos mis compañeros y amigos del CPS, Eduardo, José Ignacio, Toni, Andy, Cynthia, Jose Antonio, Luis, Manu, José, Luis Javier, Luisa... tantos a quien recordar en tan poco espacio. No habría sido lo mismo sin ellos. Por último, pero no por ello menos importante, a mis padres Santiago y M a del Pilar, sin ellos todo ésto no habría sido posible, a mis hermanas Elisa y Raquel y a mis cuñados Jacobo y Javier, sin olvidarme de mis sobrinillas, todos ellos han estado siempre ahí, apoyándome, tanto en los buenos momentos como en los más difíciles y de tensión. A todos vosotros, gracias de corazón. Desarrollo de un sistema de información para la Red Española de Supercomputación RESUMEN El Proyecto Fin de Carrera que se detalla en esta memoria ha sido realizado en el Instituto de Biocomputación y Física de Sistemas Complejos (BIFI), dentro del área de supercomputación. Se ha iniciado en octubre del 2010 y su duración ha sido de unos seis meses. Para su realización se ha contado con la codirección de Guillermo Losilla y Arturo Giner, y con Eduardo Mena como ponente. El objetivo nal del proyecto ha sido diseñar e implementar un sistema de información que permita recopilar datos de los diferentes nodos de la Red Española de Supercomputación (RES) y mostrar dichos datos a los usuarios mediante un interfaz Web. El sistema almacena la información que se recopila de los diferentes nodos y geoposiciona dicha información sobre un mapa. Posee una estructura modular y es interoperable, permitiendo ser usado en distintos sistemas operativos y navegadores Web, y provee un interfaz que permite un acceso Web seguro y con distintos niveles de autorización a la información almacenada en el sistema. El proyecto ha constado de tres fases: la primera ha sido el estudio previo de las tecnologías, donde se ha invertido bastante tiempo, la segunda y tercera han sido diseño e implementación, que se han realizado casi a la par. Durante la documentación se ha conseguido tener una idea global del funcionamiento de la RES, de forma que se han obtenido todos los detalles necesarios para la realización del proyecto. También se ha buscado información acerca de las posibles herramientas que se pueden utilizar durante el desarrollo. Se ha analizando la información obtenida, y se ha realizado una selección de las herramientas a usar, empezando así la fase de diseño, donde se ha decidido utilizar una base de datos de la cual los usuarios obtienen la información mediante un Applet de Java que usa World Wind para geolocalizar los datos, y los nodos son los encargados de actualizar la base de datos mediante el uso de scripts, de forma que es lo más automatizado posible. Finalmente, el desarrollo ha consistido en hacer realidad el diseño previo mediante las herramientas elegidas, que se han procurado que fueran Software Libre. Por ello las herramientas utilizadas han sido la base de datos MySQL, la API de la NASA World Wind Java SDK, el lenguaje Java para realizar el applet principal de la interfaz, NetBeans, Subversion, PHPMyAdmin, Gimp, Dia, Ganttproject, OpenOce y L A TEX. Al nalizar el desarrollo del proyecto se han cumplido todos los objetivos iniciales, y se ha dejado el sistema en un estado estable que tiene grandes posibilidades con vistas al futuro. Índice general I Memoria 1 1. Introducción 3 1.1. Contexto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Motivación .............................. 4 1.3. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Trabajoprevio ............................ 5 1.5. Abordando el problema . . . . . . . . . . . . . . . . . . . . . . . 5 1.6. Métodos, técnicas y herramientas empleadas . . . . . . . . . . . . 6 1.7. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . 7 2. Análisis del sistema de información 9 2.1. Descripción del sistema . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.1. La Red Española de Supercomputación . . . . . . . . . . 9 2.1.2. Requisitos de la aplicación . . . . . . . . . . . . . . . . . . 11 2.2. Estudio previo de las tecnologías . . . . . . . . . . . . . . . . . . 11 2.2.1. Tecnologías existentes . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Selección de tecnologías a utilizar . . . . . . . . . . . . . . 13 3. Diseño del sistema 15 3.1. Arquitectura del sistema de información . . . . . . . . . . . . . . 15 3.2. Recolección de información . . . . . . . . . . . . . . . . . . . . . 16 3.2.1. Origen y tipo de datos a recolectar . . . . . . . . . . . . . 16 3.2.2. Privacidad de los datos . . . . . . . . . . . . . . . . . . . 17 3.3. Basededatos............................. 18 3.4. Interfaz ................................ 19 3.4.1. Diseño visual . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4.2. Diseño de programación . . . . . . . . . . . . . . . . . . . 21 4. Implementación y Despliegue 23 4.1. Implementación y despliegue en Caesaraugusta . . . . . . . . . . 23 4.1.1. La Base de Datos . . . . . . . . . . . . . . . . . . . . . . . 24 4.1.2. El interfaz Web . . . . . . . . . . . . . . . . . . . . . . . . 27 4.1.3. Administrador Web de la base de datos . . . . . . . . . . 29 4.2. Pruebas del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3. Despliegue en los demás nodos . . . . . . . . . . . . . . . . . . . 31 vii Capítulo 1 Introducción En este capítulo se realiza una introducción al sistema de información que se ha desarrollado. Se describe el contexto en el que se ha realizado el proyecto nal de carrera, su alcance y objetivo, cómo se ha abordado el problema y nalmente, se concluye con una descripción del contenido del resto de secciones de la memoria. 1.1. Contexto del proyecto Tras realizar en Suecia el último curso de la carrera, el autor de éste proyecto decidió buscar un PFC relacionado con las áreas que más le han gustado durante sus estudios. Mediante las listas de correo de la Universidad de Zaragoza (softlibre y púlsar concretamente) se puso en contacto con Guillermo Losilla y encontró un PFC bastante interesante, ya que le permitía realizar un proyecto de forma íntegra, donde tuvo la oportunidad de participar en todas las fases, desde el diseño inicial hasta la implementación nal. Por ello, el proyecto se ha realizado en las instalaciones del Instituto de Biocomputación y Física de Sistemas Complejos (BIFI) de la Universidad de Zaragoza, usando como base el nodo de la Red Española de Supercomputación (RES) CAESARAUGUSTA, para posteriormente terminar de implementarse en el resto de los nodos. La RES es una red de infraestructuras al servicio de la I+D en España en el área de la supercomputación, con núcleo en el supercomputador Marenostrum del BSC (Barcelona Supercomputing Center  Centro Nacional de Supercomputación). Fue creada por el MICINN (Ministerio de Ciencia e Innovación) en 2007, con el objetivo de dar soporte a los servicios que la comunidad cientíca demandaba en este campo. Actualmente la RES está formada por 8 nodos, que están distribuidos por toda la geografía española. La Universidad de Zaragoza participa en la RES con el nodo CAESARAUGUSTA, instalado en la Facultad de Ciencias y que es gestionado por el BIFI, un instituto de investigación universitario creado el 8 de Octubre de 2002, por decreto 311/2002 del Gobierno de Aragón, a instancia de la Universidad de Zaragoza. 3 4 CAPÍTULO 1. INTRODUCCIÓN Los nodos de la RES generan diariamente una cantidad ingente de información de diversa índole: usuarios y grupos asignados a cada nodo, disponibilidad y estado de los sistemas, monitorización de la red, accounting ... Hasta hoy, dicha información se ha gestionado con varias herramientas de forma aislada, siendo parte de ella accesible sólo de forma local en cada nodo. Dada esta situación, se ha decidido realizar un proyecto interno en la RES que consiste en recopilar toda esta información y hacerla accesible desde la Web, de forma segura y con distintos niveles de autorización a los datos. De forma que se pueda tener una visión general del estado de toda la RES de forma rápida y sencilla. Dicho proyecto interno ha sido asignado al BIFI, y ha sido el objetivo de este proyecto nal de carrera. 1.2. Motivación Los computadores están siendo de gran ayuda a la comunidad cientíca, gracias a ellos se pueden realizar simulaciones de los experimentos antes de realizaros, ahorrando tiempo y dinero. Además de los datos obtenidos en las simulaciones, también se genera una gran cantidad de información que ayuda a controlar el estado de las máquinas, especialmente importante cuando hablamos de cientos de procesadores trabajando conjuntamente en una misma tarea. Toda esta información es útil, pero si está dispersa se hace más complejo conocer el estado global de un sistema. Además, si se dispone en España de una red de supercomputación, es interesante poder enseñar a los usuarios que el sistema funciona, para que vean las estadísticas y el entorno sobre el que trabajan, de forma que puedan disponer de una información actualizada y centralizada. También es interesante poder mostrar la RES a otra gente que no la usa pero que puede ser un usuario potencial, de manera que las personas puedan tener conocimiento de la existencia de la RES. Pero hasta ahora no existía nada que permitiera lo anterior, toda la información estaba dispersa y no era posible dar a conocer la existencia de la RES de una forma visualmente atractiva. Dado que no se había realizado nada al respecto todavía, ha resultado ser un proyecto bastante estimulante, ya que ha permitido participar al autor por primera vez en todas las fases de un proyecto informático real. 1.3. Objetivos del proyecto Dada la naturaleza del proyecto, los objetivos han estado marcados por los requerimientos del proyecto interno de la RES. Se requería un Sistema de Información especíco para un entorno concreto perfectamente denido. Por lo tanto, los objetivos principales de este proyecto han sido los siguientes: Estudiar las tecnologías involucradas, así como las herramientas y frameworks de desarrollo ya existentes que puedan ser utilizados en el proyecto. En concreto, para la parte de recolección de datos de los nodos, analizar las herramientas ampliamente extendidas en entornos de supercomputación 1.4. TRABAJO PREVIO 5 como son Nagios, Ganglia o Munin. Estudiar la aplicabilidad de frameworks de desarrollo basados en mapas como Google Maps, OpenStreetMap y World Wind, con el objeto de posicionar la información geográcamente en la fase de desarrollo del interfaz Web. Analizar, diseñar e implementar el sistema que recopile y almacene toda la información distribuida geográcamente. Buscar un desarrollo lo más modular e interoperable posible, de manera que añadir un nuevo parámetro a monitorizar o desarrollar un nuevo interfaz no suponga modicaciones costosas en el sistema. Desarrollar el interfaz que provea un acceso Web seguro y con distintos niveles de autorización a la información almacenada en el sistema. Dadas las características de la RES como sistema de información distribuido, se hace énfasis en la geolocalización de la información. Desde el principio se han tenido en cuenta los objetivos mencionados, y se han mantenido durante todo el desarrollo del proyecto sin ser alterados. Estos objetivos coinciden además con las tres fases en que se ha dividido el proyecto, estando cada fase destinada a cumplir uno de los objetivos. 1.4. Trabajo previo Cuando se ha empezado a trabajar en el proyecto, lo primero que se ha hecho es conocer la situación en la que estaba la RES, conocer su estructura organizativa interna, comprender cómo funcionan los nodos y qué se hace en ellos. Se podía prever que el proyecto constaba de dos grandes fases, la recopilación de datos y la visualización de éstos, por lo que se ha podido realizar paralelamente un estudio previo de las tecnologías existentes, para ver cuales se podían utilizar y qué herramientas eran las más convenientes para realizar el proyecto. Las primeras semanas han sido de pura documentación, para desarrollar un sistema de información es necesario comprender bien el entorno sobre el que se va a trabajar y del que se quiere extraer la información. Las fases de análisis y diseño se basan en un buen conocimiento del sistema con el que se trabaja, por ello se ha dedicado bastante tiempo a entender la organización y funcionamiento de la RES. 1.5. Abordando el problema Tras estudiar el sistema sobre el que se debía trabajar y entender su estructura, era necesario más información para poder diseñar un sistema de información acorde a los requisitos de la RES. Como se había previsto, el proyecto constaba de dos partes, recopilación de datos y visualización de éstos. En este momento ya se sabía al menos de qué datos se trataban, de dónde obtenerlos y de qué forma se debían mostrar. Se decidió dividir el proyecto en esas dos fases, de forma que la recopilación de datos fuera independiente a su visualización, empezando así el desarrollo modular del proyecto. 6 CAPÍTULO 1. INTRODUCCIÓN Era necesario, por lo tanto, buscar información para ver las opciones que había para almacenar los datos y para mostrarlos. Una vez que se tuvo la información suciente como para poder tomar decisiones, se empezó a pensar en el diseño, tanto del almacenamiento como de la visualización. Se vió que era posible trabajar en paralelo y esa ha sido la opción elegida para desarrollar el proyecto, construir un sistema de almacenamiento de datos a la vez que mostraba dichos datos, de forma que se ha podido ir visualizando el resultado conforme el proyecto iba avanzando. 1.6. Métodos, técnicas y herramientas empleadas El trabajo previo realizado ha servido para conocer el entorno, entender el problema que se estaba abordando y obtener la información necesaria para elegir las herramientas adecuadas. Desde el BIFI se apuesta por un uso preferente del software libre, por lo que se ha procurado potenciar su uso durante el desarrollo del proyecto, siendo usado como entorno principal de desarrollo el sistema operativo OpenSuse 11.3, con un entorno de escritorio KDE 4.4.4, instalados sobre una máquina de 64 bits que usa el kernel de Linux 2.6.34.7-0.5. La comunicación entre los codirectores, ponente y proyectante ha sido uida, utilizando reuniones periódicas donde se informaba del estado del proyecto y donde se daban las directrices oportunas para continuar con el desarrollo. También se realizaban críticas constructivas con intención de resolver los problemas y solucionar los fallos, se analizaban posibles mejoras y se resolvían dudas sobre la implementación. También se ha utilizado de forma asídua el correo corporativo del BIFI como herramienta de comunicación interna entre los codirectores y el proyectante. Desde el comienzo se ha utilizado un repositorio SVN exclusivo para el proyecto, usando para ello un servidor del BIFI donde almacenan otros repositorios. En dicho repositorio se ha guardado todo documento relativo al proyecto, de forma que se ha tenido un control total sobre la versión de los documentos e información sobre la persona que los ha modicado, así como los comentarios aportados con cada actualización del repositorio. Se ha utilizado principalmente el cliente de KDE KDESvn, que permite una manipulación sencilla e intuitiva de los cheros del repositorio, y muestra de una forma gráca bastante clara las diferencias de los cheros. Además, Netbeans ha sido congurado para usar dicho repositorio, por lo que se han guardado todos los cambios realizados en la programación del código fuente principal. Se ha ido comprobando el correcto funcionamiento del sistema cada cierto tiempo en distintos navegadores, utilizándose principalmente los navegadores Firefox, Opera y Google Chrome desde OpenSuse, y ocasionalmente los navegadores IE, Firefox, Opera y Safari desde MS Windows. También se ha comprobado el funcionamiento en MAC OS X con Safari, para lograr la interoperabilidad que se especica en los objetivos. Finalmente, se ha utilizado OpenOce, VIM, Kate y L A TEXcomo principales editores de texto, para la manipulación de imágenes se ha utilizado GIMP y DIA para los diagramas E/R de la base de datos y otros diagramas de la memoria. 1.7. ESTRUCTURA DE LA MEMORIA 7 1.7. Estructura de la memoria El presente documento está dividido en dos bloques: el documento principal de la memoria y los anexos. El documento principal está estructurado de la siguiente manera: 1. Introducción: En este capítulo se realiza una breve introducción al proyec- to, su contexto, su motivación, los objetivos a conseguir, un resumen de lo realizado y su entorno de realización. 2. Análisis del sistema de información: En este capítulo se realiza una descripción del sistema sobre el que se ha trabajado, se analizan los requisitos de la aplicación y se detalla y explica el resultado del estudio realizado de las tecnologías existentes. 3. Diseño del sistema: En este capítulo se detalla el diseño realizado del sistema de información. 4. Implementación y Despliegue: En este capítulo se realiza una descripción de la implementación, de los problemas encontrados y la solucion dada. También se explica el despliegue del servidor que almacena la base de datos y el interfaz Web, y de cómo se debe realizar el despliegue en cada nodo. 5. Conclusiones: En este capítulo se detallan las conclusiones, el cronograma del proyecto, el grado de cumplimiento de objetivos, mi opinión personal y posibilidades de mejora para el futuro. Tras estos capítulos, se incluye la bibliografía utilizada para el desarrollo del proyecto, terminando así el documento principal de la memoria que es seguido de los diversos anexos donde se profundiza más en ciertos aspectos del proyecto. 8 CAPÍTULO 1. INTRODUCCIÓN Capítulo 2 Análisis del sistema de información En este capítulo se realiza una descripción y análisis del sistema sobre el que se ha trabajado y se detallan sus requisitos. Se comentan las herramientas estudiadas que se pueden utilizar para el desarrollo del proyecto y se razona la elección realizada. 2.1. Descripción del sistema En esta sección se realiza una descripción del sistema sobre el que se ha realizado el proyecto. Se detalla la estructura de los nodos de la RES y su organización. Finalmente se describen los requisitos que se han esperado de la aplicación nal. 2.1.1. La Red Española de Supercomputación Actualmente la RES está compuesta por 8 nodos situados en diferentes puntos de España, estos nodos y localidades son: Altamira en Cantabria, Atlante y La Palma en Canarias, Caesaraugusta en Zaragoza, Magerit en Madrid, Marenostrum en Barcelona, Picasso en Málaga y Tirant en Valencia. Los 8 nodos de la RES usan una arquitectura similar, todos ellos usan PPC64, Marenostrum está formado por 10240 IBM PowerPC 970MP a 2.3 GHz con 20 TBytes de memoria, Magerit por 2408 IBM PowerPC 970FX a 2.2 GHz con 4.7 TBytes de memoria y el resto de nodos están formados por 512 IBM PowerPC 970FX a 2.2 GHz, con 1 TByte de memoria. Es importante destacar que la potencia de cálculo por procesador es prácticamente la misma en todos los nodos, ya que esto es fundamental a la hora de distribuir la carga de trabajo en los nodos. Al tener la misma potencia de cálculo, podemos hablar en términos de horas de cálculo, ya que una hora de cálculo en un nodo será igual de productiva que en cualquier otro nodo. Por ello, cuando alguien solicita un supercomputador de la RES, lo que realmente solicita y se le concede son horas de cálculo. De esta forma, es fácil organizar las tareas a ejecutar entre los distintos procesadores, y se pueden distribuir de forma equitativa las tareas entre los 8 nodos. 9 10 CAPÍTULO 2. ANÁLISIS DEL SISTEMA DE INFORMACIÓN Así mismo, es también importante destacar que la estructura de cada nodo es similar, y que usan los mismos sistemas y scripts para recopilar la información, ya que ello nos permite diseñar aplicaciones sobre un nodo sabiendo que es portable a los demás. El esquema lógico de un nodo cualquiera de la RES es el que se puede observar en la Figura 2.1. Figura 2.1: Esquema lógico de un nodo de la RES Cada nodo puede usar el 20% de las horas de cálculo para tareas propias (excepto Atlante, que posee un mayor porcentaje por ser propiedad del ITC), y el otro 80% está gestionado por el comité de Acceso de la RES. Estas horas pueden ser de dos tipos, A y B, cuya diferencia es la prioridad. Aquellos trabajos que posean horas de cálculo de tipo A tendrán prioridad en las colas de trabajos sobre aquellos que sean de tipo B. A la hora de solicitar horas de computación, un grupo de investigación debe rellenar un formulario y su solicitud es analizada por una comisión. De las solicitudes se obtienen datos como el nombre del grupo de investigación, un responsable y una forma de contacto. Estos datos se usan para identicar a los usuarios y para realizar estadísticas de uso. Cada 4 meses se organizan las horas de cálculo de los nodos, y estos períodos son: Marzo-Junio, Julio-Octubre y Noviembre-Febrero. Los usuarios han de solicitar las horas de trabajo para cada período, y deben procurar respetar el número de horas asignado. Una vez realizadas todas las solicitudes, la comisión se encarga de gestionar los recursos y asigna un determinado número de horas en un nodo concreto a cada grupo según las peticiones. Se observa que la información que hay que recopilar es bastante estática a excepción de las horas solicitadas y consumidas por los grupos. La información más dinámica corresponde a la información interna de cada nodo, como son los trabajos que se están ejecutando en el momento, las horas consumidas y 2.2. ESTUDIO PREVIO DE LAS TECNOLOGÍAS 11 el estado de los nodos (CPU's activas, memoria consumida, espacio en disco disponible, etc). 2.1.2. Requisitos de la aplicación La aplicación a desarrollar requería que la información recopilada fuera mostrada sobre un mapa, de forma que los datos se posicionaran sobre el mapa, donde geográcamente les correspondiera. Los datos requerían ser visibles única y exclusivamente por las personas autorizadas a ello, hay información que es pública e información que es privada, visible solo por determinados nodos o grupos de usuarios. Por lo tanto, requería una securización de los datos y un acceso por niveles a éstos. Con vistas a posibles cambios en el futuro, se requería que la aplicación tuviera una estructura modular, de forma que se pueda modicar la parte visual sin afectar a la base de datos y vice-versa . Finalmente, se pretendía que la parte visual pudiera ser accesible por el máximo número de usuarios posibles, por lo que era recomendable que pudiera ser accesible desde cualquier ordenador, lo cual implica que se adaptara a diferentes sistemas operativos y entornos de escritorio. Visto todo esto, podemos armar que la aplicación tenía unos requisitos bien denidos desde el principio: Permitir posicionar la información geográcamente sobre un mapa. Obtener una estructura lo más modular posible, de manera que añadir un nuevo parámetro a monitorizar o desarrollar un nuevo interfaz no suponga modicaciones costosas en el sistema. Obtener una aplicación lo más interoperable posible, que permita ser usada en distintos sistemas operativos y desde diferentes navegadores Web. Desarrollo de un interfaz que provea un acceso Web seguro y con distintos niveles de autorización a la información almacenada en el sistema. 2.2. Estudio previo de las tecnologías En esta sección se explica el estudio realizado sobre las tecnologías existentes que pudieran utilizarse durante el desarrollo del proyecto, y se explican las decisiones tomadas. 2.2.1. Tecnologías existentes Durante el proceso de documentación, se realizó un estudio de las tecnologías existentes que se podrían utilizar para el desarrollo del proyecto, y se redactó un informe que se puede contemplar íntegramente en el Anexo A. Dicho informe tenía como función informar detalladamente de las posibilidades que había a los directores de proyecto. En esta sección se realiza un resumen de dicho documen- to. En el estudio que se realizó se ha dividido en dos categorías las posibles herramientas a usar: por un lado, herramientas que sirvan para la recopilación 18 CAPÍTULO 3. DISEÑO DEL SISTEMA Se ha establecido que en la aplicación haya cuatro grupos diferenciados con sus respectivos permisos, que son los siguientes: Guest : usuario invitado de la aplicación. Puede ver cualquier dato público. Resuser : usuarios de la RES. Pueden ver cualquier dato público y cualquier dato privado relativo a su aplicación. Sysadmin : administradores de los nodos. Pueden ver cualquier dato público y los datos privados asociados al nodo que administren. Boss : un usuario con todos los permisos, el cual puede ver todos los datos, públicos y privados. Tras conocer los datos, los permisos y los usuarios, se ha realizado una tabla en la que se reejan todos estos datos de forma resumida, que puede observarse en la Tabla 3.1. hhhhhhhhhhhhhhhhhhh h INFORMACION TIPO DE USUARIO ANONIMO USUARIO DE LA RES ADMINISTRADOR DE NODO ROOT ESTATICA DE NODOS: todo todo todo todo descripción hardware + email de soporte + red RedIRIS ESTATICA DE USUARIOS: applications applications applications todo applications + groups + users geoposicionadas, horas y geoposicionadas, horas y geoposicionadas, horas y su lider (no gids ni resto su lider (no gids ni resto su lider (no gids ni resto de usuarios) de usuarios). De su de usuarios). De las application, todo (gid applications de su nodo, y users) todo (gid y users) VPN de la RES: topología nada nada todo todo estática + monitorización (ancho de banda, latencia, mrtg) DINAMICA:% de jobs running jobs (para la running jobs (para la además de lo anterior, una todo running sobre el total barra dinámica) y 3 barra dinámica) y 3 selección de las 5-10 grácas posible y grácas de grácas como las grácas como las más signicativas de monitorización públicas del BSC para públicas del BSC para monitorización de su nodo MareNostrum MareNostrum ACCOUNTING nada accounting (horas y accounting (horas y espacio todo espacio consumido,% consumido) de las application absoluto) de su de su nodo application Tabla 3.1: Tabla de usuarios y permisos. 3.3. Base de datos Para la base de datos se ha decidido utilizar MySQL, por su potencia y disponibilidad en el nodo en el que se iba a desplegar la base de datos. Por lo tanto, el diseño se ha realizado teniendo en cuenta las posibilidades de MySQL, por lo que se ha tratado de usar al máximo las propiedades del gestor. Inicialmente, se iba a plantear una aplicación cliente-servidor, donde el servidor se conectara a la base de datos, pero tras hablar con Eduardo Mena, se ha visto que es posible y recomendable usar las vistas que ofrece MySQL de las tablas en vez de implementar una aplicación cliente-servidor. El problema ha surgido con la privacidad de los datos, ya que ningún usuario debe ver más datos que los que le pertenecen dado su nivel de acceso. Pero como MySQL permite generar vistas de las tablas y restringir su uso de lectura y escritura a determinados usuarios, se ha podido resolver el problema del acceso a los datos por nivel de autorización. La solución ha sido sencilla, se han generado 3.4. INTERFAZ 19 unas vistas públicas, unas privadas y unas relativas a cada usuario particular, dando los permisos oportunos de lectura a las vistas a cada usuario. Para realizar el esquema E/R, se ha tenido en cuenta los resultados del estudio previo realizado. Tras el análisis realizado en la sección 3.2.1 parece claro que las entidades principales serían: nodo, aplicación, usuario de la RES, usuario anónimo, administrador de nodo, usuario global, grupo de la RES e institución. Los atributos de dichas entidades son los datos que se pueden asociar directamente a cada una de ellas. Al diseño inicial se han añadido dos entidades más, una independiente del resto con los datos de RedIRIS, para mostrar los datos de la red, y otra con los grácos que se obtienen en los nodos que muestran el estado de las máquinas. Por problemas que se comentarán más adelante se ha decidido no incluir los atributos de las imágenes en la entidad Nodo y crear una entidad aparte con dichas imágenes. En la Figura 3.2 se muestra el Modelo E/R de la base de datos simplicado. Debido al tamaño del diagrama sólo aparecen las entidades. Se puede observar el modelo E/R más detalladamente en el Anexo B. Figura 3.2: Modelo básico E/R de la base de datos Para llegar al modelo nal se ha usado principalmente el libro de Navathe [1], donde se detalla muy bien el diseño de las bases de datos y ha sido un libro de referencia frecuentemente utilizado durante el diseño de la base de datos. 3.4. Interfaz A la hora de diseñar el interfaz, se ha tenido en cuenta en todo momento que iba a ser un interfaz para la Web. Esto ha implicado que el ratón sea para el usuario la principal forma de interacción con el interfaz, y como ayuda se ha pensado en el uso de ciertos atajos de teclado. 20 CAPÍTULO 3. DISEÑO DEL SISTEMA 3.4.1. Diseño visual El diseño debía ser algo sencillo, de forma que un usuario pudiera acceder de forma rápida a la información que busca. Además, debía de ser posible visualizar la máxima información posible a la vez que ésta se posicionaba sobre el mapa. Debido a que se le ha dado más importancia a la geolocalización de la información, se ha decidido darle un mayor protagonismo al mapa sobre el que se situa la información, pero a la vez, no se ha querido perder la posibilidad de mostrar una información adicional y más especíca. Por ello, se ha decidido desde el principio que la aplicación debía mostrar el mapa con la información principal geolocalizada sobre él, y junto al mapa se debía mostrar información más especíca cuando el usuario lo requisiera. Tras analizar las posibilidades que ofrecía World Wind y Java, se ha diseñado una pantalla principal dividida verticalmente en dos sobre la que se mostrarían todos los datos, cuyo boceto inicial puede observarse en la Figura 3.3. En dicha gura, podemos observar que la parte derecha ocupa la mayor parte, es donde se sitúa el mapa y la información principal. Cuando el usuario pasa el ratón sobre un objeto del mapa, aparece un globo relativo al objeto sobre el que aparece la información básica del objeto. Figura 3.3: Boceto inicial de la ventana principal. En la parte de la izquierda, se sitúa un panel donde se muestra información más detallada mediante pestañas. Cada vez que el usuario selecciona un obje- to del mapa, se abre una pestaña con información especíca del objeto. Hay diferentes tipos de pestañas, cada uno diseñado especícamente para mostrar un tipo de información. Las pestañas pueden mostrar información de nodos, instituciones, aplicaciones de la RES, capas del programa, y diferentes pestañas de información y ayuda sobre el applet. La división de los paneles no está jada a un tamaño concreto, el usuario puede jugar con su posición. Si lo desea, puede cerrar el panel de la izquierda y ver el mapa al máximo tamaño posible, o incluso puede hacer que el mapa no se vea y mostrar sólo el panel de la izquierda con la información detallada. El diseño inicial también ha incluido una pantalla inicial donde el usuario debe identicarse para poder acceder a la información. Ocupa toda la pantalla y 3.4. INTERFAZ 21 desaparece tras iniciar la sesión. Al terminar la sesión, el usuario vuelve a dicha pantalla. Esta pantalla inicial permite al usuario que no tenga una cuenta de acceso poder iniciar sesión como invitado, desde la que accede a todos los datos públicos. El diseño de esta pantalla puede observarse en la Figura 3.4. Figura 3.4: Boceto inicial de la ventana de login. Tras nalizar el diseño inicial e iniciar la implementación, se ha visto que era conveniente realizar algunas modicaciones para mejorar el diseño. Las principales modicaciones han sido las siguientes: Mejora en el panel de información: los atajos de teclado son de gran ayuda, pero es necesario poder abrir todas las pestañas con el ratón. Por ello, se ha añadido un pequeño menu encima de las pestañas que permite al usuario abrir las principales pestañas de navegación y ayuda. Integración de la pantalla de acceso: para evitar confusiones al usuario y procurar que el aspecto visual sea similar, se ha integrado la pantalla inicial de acceso en el panel izquierdo, desactivando la visualización del mapa y la información hasta que no se haya acreditado el usuario. Tras implementar las nuevas mejoras, se ha observado que el resultado es el deseado y su nuevo diseño es mejor que el inicial, logrando una aplicación más sencilla y óptima para el usuario. 3.4.2. Diseño de programación Hasta ahora, se ha visto todo lo relativo al diseño gráco de la interfaz. El diseño modular de su programación se ha realizado durante el principio de la fase de desarrollo. Inicialmente no se conocía bien la API de World Wind, y se ha ido aprendiendo sobre ella tras realizar diferentes pruebas al inicio del desarrollo. El diseño inicial de los módulos a programar ha sido un boceto sencillo en el que se ha puesto de maniesto la intención de separar la parte gráca de la recopilación de datos, a la vez que se ha tratado de modularizar la programación. 22 CAPÍTULO 3. DISEÑO DEL SISTEMA La idea básica ha sido usar 4 módulos diferentes: uno para solicitar datos a la base de datos, otro para controlar las ventanas, el tercero para manejar los diferentes objetos con información y el cuarto para mostrar datos sobre el mapa, tal y como se puede observar en la Figura 3.5. Dichos módulos serían lo sucientemente independientes entre sí como para poder realizar cambios en uno de ellos sin que afectaran al resto. La mayor carga de trabajo la realizaría el controlador de ventanas, quien se encargaría de centralizar toda la gestión y toda la información pasaría por él. En el próximo capítulo se detallará más el diseño usado para programar la aplicación. Figura 3.5: Módulos iniciales del interfaz. Las echas indican la dirección del ujo de información. Capítulo 4 Implementación y Despliegue En este capítulo se va a comentar el proceso de implementación de la aplicación y su despliegue tanto en el nodo de Caesaraugusta como en el resto de los nodos. El proceso ha sido realizado a la par, ya que se ha querido comprobar su correcto funcionamiento multiplataforma desde el principio. Además, al ser un applet, se ha preferido comprobar su comportamiento al ser alojado en un servidor Web real, en vez de realizar pruebas locales. También se comentan los problemas encontrados y las soluciones aportadas, ya que durante la fase de implementación se han encontrado algunos problemas que han provocado ligeros cambios en el diseño original. 4.1. Implementación y despliegue en Caesaraugusta El proyecto se ha desarrollado usando solo el nodo de Caesaraugusta, y en esta sección se detalla el proceso. Debido a que todos los nodos poseen una estructura similar, como ya se ha visto en la Figura 2.1, y que utilizan los mismos programas de monitorización (al menos para obtener los datos que manejamos en la aplicación), se puede realizar la conguración sobre un nodo concreto, sabiendo que la conguración servirá para los demás. Se observó que muchos de los scripts desarrollados por el BSC usados por Caesaraugusta estaban en inglés, al igual que casi toda la información que se envía a los administradores semanalmente sobre el accounting , por lo que se decidió realizar el desarrollo en inglés. Nos ha parecido la opción más razonable, ya que muchos investigadores que usan la RES son extranjeros, y dado el carácter informativo de la aplicación se ha creido oportuno tratar de usar un lenguaje que es ampliamente extendido dentro del ámbito de investigación. Como ya se ha visto al hablar de la arquitectura del sistema de información en la sección 3.1, la interfaz Web se conecta directamente a la base de datos y ofrece a los usuarios la información geoposicionada sobre un mapa. Para poder realizar las pruebas y comprobar que todo funcionaba correctamente, se ha decidido usar una misma máquina para alojar el applet y la base de datos, por 23 24 CAPÍTULO 4. IMPLEMENTACIÓN Y DESPLIEGUE lo que se ha congurado el servidor monitor de Caesaraugusta con MySQL y Apache. Lo primero que se ha empezado a implementar ha sido la base de datos, ya que se sabía que su estructura nal iba a marcar el desarrollo del applet, debido a que las clases de java iban a ser muy parecidas a las entidades de la base de datos. 4.1.1. La Base de Datos En Caesaraugusta se utiliza el sistema operativo SUSE Linux Enterprise (SLES) 10, por lo que usando el gestor de paquetes de Yast se ha podido instalar MySQL 5.0.26 sin problemas. Una vez instalado, se ha realizado la conguración inicial de MySQL, creando el usuario root y borrando las bases de datos y usuarios de pruebas que se generan inicialmente. Se ha comprobado que estuviera activada la opción de control de transacciones, para evitar posibles pérdidas en los datos cuando sean guardados en la base de datos. También se ha comprobado que se pudiera utilizar el motor de almacenamiento InnoDB, que es el encargado de realizar el control de las transacciones, y se han realizado sencillas pruebas para comprobar su correcto funcionamiento. Tras estas comprobaciones, ya estaba preparado MySQL para ser usado en la aplicación, por lo que se ha creado la base de datos resdata que contiene todas las tablas necesarias para este proyecto y el usuario mysql, con permisos totales sobre dicha base de datos, para evitar el uso del usuario root, y así poder administrar sin problemas la base de datos durante la realización del proyecto. La implementación nal es como se ha mostrado en la Figura 3.2, y el diseño completo con sus atributos se puede observar en el Anexo B. Para rellenar la base de datos se espera que a largo plazo se use un método totalmente automatizado, que recoja los datos del BSC y los carge en la base de datos creada para este proyecto. Pero sabiendo que iba a ser un proceso largo, se han realizado sencillos scripts que recogen la misma información directamente de los nodos, y la almacenan en la base de datos. Los scripts recopilan la siguiente información: Grupos y usarios de un nodo : cada 24 horas se comprueba los cambios del sistema y se actualiza la base de datos. Se actualizan los campos de las entidades USERS, RESUSER y RESGROUP. Estado del nodo : cada 10 minutos se recopila la información sobre la carga del nodo, algunas grácas del estado del nodo, los trabajos que están corriendo y los que están esperando en colas. También se recopila información de las quotas de los usuarios cada hora, de forma que se conoce el espacio consumido por los grupos. Con todos estos datos se actualiza la entidad NODE, IMAGES y APPLICATION. Para recopilar la información, los scripts obtienen la información de Ganglia, MOAB 1 y otros scripts que se han generado en el BSC. 1 Moab Workload Manager es un metascheduler , un sistema avanzado de administración y planicación de trabajos para clusters, grids y sistemas de computación bajo demanda. 4.1. IMPLEMENTACIÓN Y DESPLIEGUE EN CAESARAUGUSTA 25 Los atributos relativos a VPNSTATUS se pueden automatizar, y tanto la base de datos como la interfaz Web están listos para recoger y mostrar los datos. Pero debido a que en Caesaraugusta todavía no está activa la VPN, no se pueden obtener los valores para rellenar la base de datos. Desafortunadamente, hay muchos atributos y entidades que no se pueden actualizar o crear de forma automatizada actualmente. Dichos datos son los siguientes: Nuevas aplicaciones : no se pueden crear de forma automatizada, ya que los datos obligatorios para crearlas (entre ellos la clave primaria) no se pueden obtener de los nodos, es una información que está centralizada en el BSC. Instituciones : actualmente no se almacena en ningún lugar las coordenadas de las distintas instituciones, por lo que hay que buscarlas e introducirlas manualmente. Datos de RedIRIS : no se almacenan tampoco en ningún lugar, pero como son datos estáticos, se ha creado un script inicial que inserta en la base de datos la información de RedIRIS al crearse las tablas. Como se ha comentado en el diseño de la base de datos, se han creado vistas de las tablas, de forma que los usuarios de la RES y los invitados de la aplicación Web sólo tienen permisos de lectura sobre las vistas, y los usuarios creados para actualizar los datos desde los distintos nodos, tienen permiso de modicación sobre algunas vistas y permisos de insertar datos sobre otras. Podemos distinguir los siguientes tipos de usuarios de MySQL (no de la aplicación Web): Nodo : Hay un usuario por cada nodo, se utiliza en los scripts para actualizar la base de datos. Usuario de la RES : Tiene permisos de lectura sobre los datos relativos a su grupo y de la aplicación que desarrolla. Líder de una aplicación : Tiene permisos de lectura sobre los datos relativos a su grupo y de la aplicación que lidera. Administrador de nodo : Tiene permisos de lectura sobre los datos relativos a su nodo. Superusuario : Tiene permisos de lectura de todo. Invitado : Tiene permisos de lectura sólo de los datos públicos. Como vemos, son muy parecidos a los usuarios y permisos de la Tabla 3.1, y su diferencia como usuarios de MySQL estriba sólo en los permisos que tienen sobre las diferentes vistas. Mediante este sistema de vistas podemos garantizar una seguridad sobre el acceso a los datos, ya que podemos controlar qué usuarios acceden a qué datos. Podemos distinguir los siguientes tipos de vistas: Públicas : tienen acceso de lectura a todos los datos públicos. Privadas de acceso total : tienen acceso de lectura a todos los datos. 26 CAPÍTULO 4. IMPLEMENTACIÓN Y DESPLIEGUE De grupo : tienen acceso de lectura a todos los datos relativos al grupo y a la aplicación que desarrolla el grupo. De líder de aplicación : tiene acceso de lectura a los datos relativos a la aplicación que lidera. De administrador : tienen acceso de lectura a todos los datos relativos al nodo que administran. De usuario : tienen acceso de lectura a sus propios datos de usuario. De nodo : tienen permiso de inserción en determinadas tablas y de actualización sólo de sus datos en otras, de forma que no modiquen datos que no les pertenecen. En el Anexo B se puede contemplar una descripción completa de todas las vistas, usuarios, atributos y entidades del modelo E/R así como la transformación del modelo E/R a las tablas de MySQL. Problemas encontrados Durante la implementación se comprobó que había un problema que no esperábamos para subir imágenes a la base de datos usando el tipo de dato BLOB, un objeto que contiene un binario de longitud variable. El problema consistió en que a la hora de subir las imágenes a la base de datos, sólo funcionaba de forma local, no remotamente. Para añadir una imagen se utilizaba la función de MySQL load_le(), la cual obtiene un chero que se puede introducir como un dato binario en cualquier celda de tipo BLOB. Esta llamada, si se hace remotamente, no funciona, pues MySQL trata de obtener el chero en la máquina local y no en la remota. Para solucionarlo, se modicó un poco el diseño, y en vez de ser los nodos los que subieran las imágenes, sería un script situado en la máquina monitor de Caesaraugusta el que se encargara de recoger las imágenes de los diferentes nodos, guardarlas en un directorio local y entonces introducirlas en la base de datos. Para evitar sobrecargar la entidad NODE, y poder realizar un borrado de las imágenes de forma sencilla, se creó una nueva entidad, llamada IMAGES, que es donde se almacenan todas las imágenes. De esta forma, el único dato que se obtiene mediante el método pull son las imágenes del estado de los nodos. Además, realizando este cambio, se evita un problema de seguridad, ya que para que un usuario pueda guardar imágenes en MySQL necesita el permiso File , el cual es global para toda la base de datos y tiene problemas de seguridad. Si se usa indebidamente se pueden escribir cheros en cualquier carpeta en la que el proceso mysqld tenga permisos. Como medida de seguridad no se permite sobreescribir cheros, pero un usuario malintencionado podría crear cheros indenidamente y saturar el sistema de cheros de la máquina. 4.1. IMPLEMENTACIÓN Y DESPLIEGUE EN CAESARAUGUSTA 27 4.1.2. El interfaz Web Como se ha comentado en el apartado 2.2, para realizar la interfaz Web se ha utilizado la API World Wind Java SDK (versión 0.6.679.14208), y tras probar su funcionamiento en Eclipse y NetBeans, se ha decidido realizar el desarrollo en NetBeans 6.8 por su ligereza y mejor integración con la API, siendo Java 1.6.0_22 el lenguaje principal de programación usado. Para usar la API World Wind en NetBeans, se ha empezado un nuevo proyec- to en NetBeans, donde se han añadido todos los paquetes de la API y las librerías adicionales necesarias: jogl y gluegen , la primera es una librería gráca y la segunda una librería que permite realizar llamadas a C desde Java. Una vez que se ha logrado realizar un applet mínimo, y se ha entendido el funcionamiento de la API, se han ido añadiendo funcionalidades y módulos progresivamente para realizar la interfaz que se ha diseñado. A continuación se realiza un resumen de lo que se ha desarrolado en la interfaz Web, y en el AnexoB se puede contemplar una descripción más detallada. Durante la implementación se ha utilizado javadoc para documentar todas las clases. Dado que el desarrollo del applet implica constantes llamadas a las funciones de la API de World Wind, se ha optado por adjuntar la documentación javadoc del paquete implementado junto a la documentación javadoc ya existente de la API, de forma que todo futuro desarrollador pueda entender fácilmente el código fuente. Dicha documentación se puede encontrar en el CD adjunto, en la carpeta /otrosAnexos/javadoc. Se ha creado un nuevo paquete llamado reswwja (RES World Wind Java Applet), donde se ha incluido todo el código desarrollado para generar la nueva aplicación, de forma que se genera un chero .jar que los navegadores pueden bajar para ejecutar el applet. La estructura del paquete es la siguiente: reswwja : contiene los cheros html que contienen el applet así como la clase principal del applet. reswwja.db : contiene la clase con las funciones necesarias para obtener datos de la base de datos. reswwja.images : contiene todas las imágenes usadas por el applet. reswwja.infoObjects : contiene todas las clases de los objetos más usados por el applet, que coinciden con las entidades vistas en el esquema E/R de la base de datos. reswwja.window : contiene las clases necesarias para manipular las ventanas del applet, el mapa del mundo y todos los objetos que se sitúan sobre el mapa. La interacción entre los paquetes es la que se muestra en la Figura 4.1. En la gura podemos observar que la implementación nal diere un poco del diseño inicial. El módulo que se pensó que podía ser el que situaría los elementos sobre el mapa ha desaparecido para integrarse en el de las ventanas y se ha creado otro nuevo, que almacena todas las imágenes del applet. 34 CAPÍTULO 5. CONCLUSIONES 5.2. Desarrollo del proyecto El proyecto ha estado marcado en todo momento por una fase contínua de documentación. Conforme se iban realizando las diferentes tareas, siempre he tenido que investigar y documentarme sobre la tarea que estaba realizando en ese momento. Por ello, exceptuando la primera fase de análisis previo del sistema, el diseño e implementación se han solapado, como puede observarse en la Figura 5.1. Mientras se desarrollaba el diseño inicial, se observaban las posibles mejoras y problemas del diseño, por lo que se modicaba conforme a los nuevos datos obtenidos en la documentación u observados durante la implementación. Figura 5.1: Diagrama Gantt del avance del proyecto. Otro hecho importante es la documentación propia del proyecto. Desde el principio el proyecto se fue documentando, de forma que los codirectores tenían acceso al estado actual del proyecto y a toda la información relativa a él. Esto es signicativo, dado que a la hora de nalizar el proyecto tras seis meses de trabajo, la documentación estaba prácticamente realizada, sólo ha sido necesario reorganizarla y presentarla adecuadamente. Toda persona que quiera continuar con el desarrollo de este proyecto podrá encontrar la información adecuada para poder realizar dicha tarea. La dedicación del proyecto ha sido completa desde octubre hasta comienzos de abril, realizando una pequeña pausa de dos semanas en febrero para realizar los últimos exámenes que me quedaban. Durante este tiempo he dedicado unas 7 horas diarias a la realización del proyecto. 5.3. Posibles mejoras y vías de desarrollo El estado actual del proyecto tiene bastantes aspectos que pueden ser mejorados, y las posibilidades del desarrollo futuro son innumerables, aquí se detallan algunas de ellas: Mejorar la automatización de la actualización de la base de datos. Actualmente se actualiza con los scripts desarrollados para tal efecto que se 5.3. POSIBLES MEJORAS Y VÍAS DE DESARROLLO 35 ejecutan en cada nodo, pero a largo plazo se espera que la base de datos esté sincronizada con la del BSC. Durante las últimas semanas del proyecto se iniciaron las conversaciones con los encargados de las bases de datos del BSC, por lo que es una mejora que podría realizarse antes de lo esperado. Automatizar la creación de los usuarios de MySQL. Debido a que hay ciertos datos que no se pueden actualizar y añadir en la base de datos de forma automática, la creación de los usuarios de MySQL conlleva una pequeña intervención humana. Es de esperar que en un futuro no sea necesaria dicha intervención, ya que todos los datos estarán disponibles en la base de datos. Por ejemplo, algunos de los datos que no se pueden obtener automáticamente son las coordenadas de las instituciones o a qué institución pertenece un usuario. Desarrollar una segunda vista, que en vez de mostrar los datos relativos a un nodo, muestre los datos relativos a un grupo. Actualmente se muestran los datos desde el punto de vista de un nodo, es decir, al selecionar un determinado nodo se muestran los datos asociados a él. Si se implementa una segunda vista, podría obtenerse la información desde otro punto de vista, más interesante para un usuario de la RES, ya que el punto de vista actual es más interesante para un administrador de un nodo o para una persona ajena a la RES. Mejorar el sistema de seguridad mediante un cifrado SSL. En los últimos días del desarrollo se recibió un certicado de TERENA que permite tanto cifrar como rmar, que podría ser utilizado para cifrar las comunicaciones con la base de datos y rmar de paso los cheros .jar que el navegador ha de descargar. Desarrollar un método por el cual los datos de la VPN que conecta los nodos se actualice en la base de datos. Actualmente, tanto la base de datos como el interfaz Web están preparados para mostrar dichos datos, pero al carecer el nodo Caesaraugusta de conexion VPN no ha podido ser posible estudiar la forma en que los datos puedan ser introducidos en la base de datos. Añadir nuevas capas, objetos o datos a monitorizar en la base de datos. Según se utilice esta aplicación, podrán observarse nuevas formas de uso o de parámetros a monitorizar, que gracias al desarrollo modular se podrán implementar con facilidad. Estas son algunas de las posibles mejoras y vías de desarrollo que se podrían realizar, y nos permiten darnos cuenta de las grandes posibilidades que tiene este proyecto. Visto todo esto, podemos ver que el proyecto, pese a estar en una fase estable, está en los comienzos de su vida, si continúa su desarrollo podrá mejorar y cambiar de una forma sorprendente para todos aquellos que lo hemos visto en su actual estado. 36 CAPÍTULO 5. CONCLUSIONES 5.4. Opinión personal Durante los seis meses que he estado en el BIFI desarrollando este Proyecto Fin de Carrera, tengo que destacar que he estado muy a gusto trabajando con las personas que me han dirigido y ayudado a realizar el proyecto. El entorno laboral ha sido inmejorable, algo imprescindible para poder trabajar en un equipo. A nivel personal, estoy satisfecho con el trabajo realizado, me ha permitido tomar parte de todas las fases de un proyecto: análisis, diseño, implementación y puesta en producción. He podido aprender y trabajar en diferentes áreas que es lo que buscaba, e integrar todo ello en un único proyecto. Por otro lado, he de agradecer el grado de libertad que me han otorgado mis codirectores, su contínuo apoyo y paciencia. Creo que gracias al buen ambiente que generaban he podido terminar este proyecto satisfactoriamente, no habría sido lo mismo sin ellos. Así mismo, debo agradecer a mi ponente toda la ayuda y los consejos proporcionados, gracias a los cuales he podido simplicar muchas tareas. Bibliografía [1] Ramez Elmasri, Shamkant B. Navathe: Fundamentos de sistemas de bases de datos, Pearson Addison Wesley (2007) [2] B. Shuwartz: MySQL Avanzado, ANAYA Multimedia (2009) [3] K. Mukhar, T. Lauinger, J. Carnell: Fundamentos de bases de datos con java: JDBC, SQL, J2EE, EJB, JSP, XML, ANAYA Multimedia (2002) [4] J. Gerner: LAMP: desarrollo web con Linux, Apache, MySQL y PHP 5, ANAYA Multimedia (2006) [5] A. Ford: Apache 2 Pocket Reference, O'Reilly Media (2008) [6] R. Bowen K. Coar: Apache Cookbook, second edition, O'Reilly Media (2007) [7] F.J. Ceballos Sierra: Java 2: Interfaces grácas y aplicaciones para internet, RA-MA (2008) [8] J.R. Garcia-Bermejo Giner: Java 2, Pearson educación (2001) [9] C. Deaix Remy: Programación shell en Unix/Linux SH (BOURNE), KSH, BASH, ENI (2010) [10] C. Newham: Learning the BASH shell, O'Reilly & associates (2005) [11] P. Katchero: El gran libro de Linux, MP Ediciones (2006) [12] F. Mittelbach, M. Goossens, J. Braams, D. Carlisle, C. Rowley: The LaTeX Companion, Second Edition, Addison-Wesley Professional (2004) [13] H. Kopka, P. W. Daly: Guide to LaTeX, Fourth Edition, Addison-Wesley Professional (2003) [14] K. Goelker: GIMP 2 for Photographers, Rocky Nook (2006) [15] GanttProject: http://www.ganttproject.biz/ Último acceso: abril 2011. [16] Documentación de Ganglia: http://sourceforge.net/apps/trac/ganglia/wiki Último acceso: enero 2011. 37 38 BIBLIOGRAFÍA [17] Nagios: http://wiki.nagios.org/index.php/Main_Page Último acceso: enero 2011. [18] Documentación de Munin: http://munin-monitoring.org/wiki/Documentation Último acceso: enero 2011. [19] Google Maps API: http://code.google.com/apis/maps/index.html Último acceso: enero 2011. [20] Openlayers: http://openlayers.org/ Último acceso: enero 2011. [21] World Wind API: http://worldwind.arc.nasa.gov/java/ Último acceso: enero 2011. [22] Documentación de MySQL: http://dev.mysql.com/doc/ Último acceso: enero 2011. [23] Documentación de Java: http://download.oracle.com/javase/1.4.2/docs/api/index.html Último acceso: abril 2011. [24] Documentación de PHPMyAdmin: http://www.phpmyadmin.net/documentation/ Último acceso: abril 2011.