UNIVERSIDAD DE CASTILLA-LA MANCHA ... - Grupo ARCO
UNIVERSIDAD DE CASTILLA-LA MANCHA ... - Grupo ARCO
UNIVERSIDAD DE CASTILLA-LA MANCHA ... - Grupo ARCO
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
<strong>UNIVERSIDAD</strong> <strong>DE</strong> <strong>CASTIL<strong>LA</strong></strong>-<strong>LA</strong> <strong>MANCHA</strong><br />
ESCUE<strong>LA</strong> SUPERIOR <strong>DE</strong> INFORMÁTICA<br />
INGENIERÍA<br />
EN INFORMÁTICA<br />
Plataforma para el despliegue y administración<br />
remota de sistemas heterogéneos en red<br />
Ignacio Díez Arias<br />
Julio, 2010
<strong>UNIVERSIDAD</strong> <strong>DE</strong> <strong>CASTIL<strong>LA</strong></strong>-<strong>LA</strong> <strong>MANCHA</strong><br />
ESCUE<strong>LA</strong> SUPERIOR <strong>DE</strong> INFORMÁTICA<br />
Departamento de Tecnologías y Sistemas de la Información<br />
PROYECTO FIN <strong>DE</strong> CARRERA<br />
HYDRA: Heterogeneous system deployment<br />
and remote administration<br />
Autor: Ignacio Díez Arias<br />
Director: David Villa Alises<br />
Julio, 2010
TRIBUNAL:<br />
Presidente:<br />
Vocal 1:<br />
Vocal 2:<br />
Secretario:<br />
FECHA <strong>DE</strong> <strong>DE</strong>FENSA:<br />
CALIFICACIÓN:<br />
PRESI<strong>DE</strong>NTE VOCAL 1 VOCAL 2 SECRETARIO<br />
Fdo.: Fdo.: Fdo.: Fdo.:
c○ Ignacio Díez Arias. Se permite la copia, distribución y/o modificación de este documento<br />
bajo los términos de la GNU Free Documentation License (GFDL), versión 1.3 o cualquier<br />
versión posterior publicada por la Free Software Foundation, sin secciones invariantes. Tal<br />
como exige la licencia, se adjunta una copia de la misma en el apéndice D.<br />
Este documento ha sido editado en Emacs y maquetado con L A TEX. Las imágenes han sido<br />
generadas con inkscape y dia.
Resumen<br />
A día de hoy no es raro encontrar instituciones, empresas e incluso hogares en los<br />
que se utilizan distintos sistemas operativos, o varias instancias del mismo, en cada<br />
ordenador. Cuando se trata de unas pocas máquinas, no es necesario utilizar ninguna<br />
herramienta auxiliar para gestionarlos. Sin embargo, a medida que crece el número de<br />
ordenadores a controlar, administrar tantos sistemas operativos puede ser una tarea<br />
tediosa; sobre todo si la configuración cambia con cierta frecuencia.<br />
En este documento se estudiarán los problemas que plantea la gestión de este tipo<br />
de entornos; y se describirá un sistema que sirve como solución ante dichos problemas,<br />
proporcionando una herramienta de gestión remota y sencilla.<br />
Como resultado de este proyecto, se aporta el sistema HYDRA, cuyo objetivo principal<br />
es conseguir facilitar al administrador las tareas de gestión y administración de<br />
un conjunto de nodos: instalar aplicaciones en todos los ordenadores, restaurar los que<br />
no funcionen correctamente, añadir o quitar un sistema operativo, etc. Usando como<br />
base un middleware de comunicaciones se crearon las herramientas necesarias para instalar<br />
varios sistemas operativos en cada nodo, pudiendo configurar una planificación<br />
temporal de las instalaciones.<br />
Para ello, se particionarán los discos duros de los nodos y se copiarán los ficheros de<br />
cada sistema operativo en su partición correspondiente, quedando los sistemas instalados<br />
de forma nativa. Posteriormente, se configurará un gestor de arranque que permita<br />
elegir cuál de ellos arrancar.
Agradecimientos<br />
✭✭Toda historia tiene un final feliz,<br />
sólo hay que saber cuándo parar de contarla✮✮<br />
Neil Gaiman, The Sandman<br />
...y ésta ha llegado al suyo. Ha sido un camino largo, demasiado para el gusto de<br />
todos. Pero lo importante no es terminar el camino rápido, sino hacerlo.<br />
Durante este tiempo he intentado aprender de todas las personas que me han rodeado,<br />
y he de decir que he aprendido mucho. Tengo que agradecérselo a la gente del grupo<br />
Arco: Félix, Fernando, JuanCarlos y en general, todos los demiurgos, por hacerme un<br />
hueco en el grupo y ayudarme a crecer profesionalmente.<br />
Mención especial dentro de ese conjunto para mi director David, y para Paco, pues<br />
ellos son los que me han sufrido más de cerca y también de los que más he aprendido,<br />
a veces en contra de mi voluntad.<br />
No puedo olvidarme tampoco de ✭✭los de abajo✮✮, la gente del labo: José Luis (Lucas),<br />
Miguel Ángel, Cleto, Tobías, Javibot, Manolo, Peris, Sergio, Richard, Óscar, Chanque,<br />
... Gente con la que puedes contar tanto para irte de fiesta y divertirte como nunca,<br />
como para dar el callo y trabajar duro al día siguiente. Gracias por ayudarme y echarme<br />
una mano siempre que lo he necesitado (que han sido muchas veces).<br />
Gracias también a mis amigos de fuera de la Escuela: Marina, Lorenzo, Fede, Virginia<br />
y toda la gente de volley, por darme ánimos y apoyo cuando lo necesitaba.<br />
Y por último y por lo tanto, más importante, tengo que dar las gracias a mis<br />
padres por aguantarme todos estos años. Es por todos conocido el hecho de que muchos<br />
✭✭informáticos✮✮ (no todos) se transforman en máquinas de von Neumann andantes, que<br />
aplican la lógica en todo lo que hacen, hablan con expresiones raras y muestran un<br />
comportamiento errático. Ellos lo han sufrido de primera mano y aún así, me siguen<br />
aguantando.<br />
Gracias a todos.
A mis padres
Índice general<br />
Índice general<br />
XIII<br />
Índice de figuras<br />
XIX<br />
Índice de Tablas<br />
XXI<br />
1. Introducción 1<br />
1.1. Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . . . . 3<br />
2. Objetivos del Proyecto 5<br />
2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5<br />
2.2. Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6<br />
3. Estado del Arte 9<br />
3.1. Cargadores de Arranque . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11<br />
3.3. Sistemas de Ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14<br />
3.4. Utilidades y herramientas de base . . . . . . . . . . . . . . . . . . . . . 15<br />
3.4.1. WoL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.4.2. PXE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15<br />
3.4.3. FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16<br />
3.4.4. TFTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17<br />
3.4.5. NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.4.6. unionfs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.4.7. MAD Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18<br />
3.5. Middlewares de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.5.1. ZeroC Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.5.2. CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.5.3. Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
3.6. Aplicaciones de Clonado . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.6.1. PartImage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.6.2. Ghosting for Unix . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.6.3. NTFS Clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
3.6.4. Clonezilla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24<br />
3.7. Distribución de Software . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
3.7.1. UDPCast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.7.2. ZeroInstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25<br />
3.7.3. Fully Automated Installation . . . . . . . . . . . . . . . . . . . 26<br />
3.7.4. System Imager . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
3.7.5. DRBL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27<br />
3.7.6. LTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
3.7.7. SLIM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28<br />
3.7.8. Userful Multiplier . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
3.7.9. rootz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
3.8. Herramientas para despliegue . . . . . . . . . . . . . . . . . . . . . . . 29<br />
3.8.1. Virtual Appliances . . . . . . . . . . . . . . . . . . . . . . . . . 29<br />
3.8.2. MetaOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
3.8.3. Installable Units . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
3.8.4. Kadeploy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31<br />
3.9. Gestión de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33<br />
3.10. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34<br />
4. Método de Trabajo y Herramientas 37<br />
4.1. Método de Trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37<br />
4.2. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.2.1. Lenguajes de Programación . . . . . . . . . . . . . . . . . . . . 39<br />
4.2.2. Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39<br />
4.2.3. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.4. Documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . 40<br />
5. Desarrollo 43<br />
5.1. Especificación de Requisitos . . . . . . . . . . . . . . . . . . . . . . . . 44<br />
5.2. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46<br />
5.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50<br />
5.3.1. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
5.4. Entorno de Desarrollo y Pruebas . . . . . . . . . . . . . . . . . . . . . 51<br />
5.4.1. Plan de Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . 55<br />
5.5. Incrementos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62<br />
5.5.1. Incremento 1: Información del Sistema . . . . . . . . . . . . . . 62<br />
5.5.2. Incremento 2: Particiones . . . . . . . . . . . . . . . . . . . . . 64<br />
5.5.3. Incremento 3: Instalar imágenes . . . . . . . . . . . . . . . . . . 65<br />
5.5.4. Incremento 4: Manager . . . . . . . . . . . . . . . . . . . . . . . 67<br />
5.5.5. Incremento 5: Delegados . . . . . . . . . . . . . . . . . . . . . . 69<br />
5.5.6. Incremento 6: Optimizaciones . . . . . . . . . . . . . . . . . . . 70<br />
5.6. Bridge ethernet y servidor DHCP/PXE . . . . . . . . . . . . . . . . . . 75<br />
5.7. Tamaño del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76<br />
6. HYDRA 79<br />
6.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80<br />
6.2. Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80<br />
6.2.1. La red IceGrid . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.2.2. Agente de Base de Datos . . . . . . . . . . . . . . . . . . . . . . 82<br />
6.2.3. Preparación de imágenes . . . . . . . . . . . . . . . . . . . . . . 82<br />
6.2.4. Generación de la Configuración . . . . . . . . . . . . . . . . . . 84<br />
6.3. Delegados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84<br />
6.4. HostInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85<br />
6.5. Installer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
6.6. Hydra-admin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87<br />
7. Caso de Estudio: ESI 91<br />
7.1. Situación Actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91<br />
7.2. Implantación de HYDRA . . . . . . . . . . . . . . . . . . . . . . . . . . 95<br />
8. Conclusiones y Trabajo Futuro 99<br />
A. Manual de Usuario 103<br />
A.1. Gestión de Imágenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104<br />
A.2. Gestión de Despliegues . . . . . . . . . . . . . . . . . . . . . . . . . . . 105<br />
A.3. Gestión de Equipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107<br />
B. Terminología 109<br />
C. Acrónimos y Siglas 111<br />
D. GNU Free Documentation License 115<br />
Bibliografía 121
Índice de figuras<br />
3.1. Tabla de Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12<br />
3.2. Esquema de funcionamiento de PXE . . . . . . . . . . . . . . . . . . . 16<br />
3.3. Invocaciones remotas con semántica de invoación local, típicas de los<br />
middlewares de comunicaciones . . . . . . . . . . . . . . . . . . . . . . 19<br />
3.4. Estructura de Ice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21<br />
3.5. Estructura de CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . 22<br />
3.6. Estructura de Java RMI . . . . . . . . . . . . . . . . . . . . . . . . . . 23<br />
3.7. Installable Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30<br />
3.8. Funcionamiento de Kadeploy2 . . . . . . . . . . . . . . . . . . . . . . . 32<br />
4.1. Desarrollo Incremental . . . . . . . . . . . . . . . . . . . . . . . . . . . 38<br />
5.1. Diagrama de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 47<br />
5.2. Diagrama de Casos de Uso para el Delegado y el Manager . . . . . . . 49
5.3. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 51<br />
5.4. Diagrama E/R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52<br />
5.5. Esquema de la BBDD . . . . . . . . . . . . . . . . . . . . . . . . . . . 53<br />
5.6. Diagrama de Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54<br />
5.7. Estructura de red de HYDRA . . . . . . . . . . . . . . . . . . . . . . . 76<br />
5.8. Líneas por lenguaje de programación . . . . . . . . . . . . . . . . . . . 77<br />
6.1. Proceso de preparación de una Imagen . . . . . . . . . . . . . . . . . . 80<br />
6.2. Flujo de trabajo en HYDRA . . . . . . . . . . . . . . . . . . . . . . . . 84<br />
6.3. Diagrama de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 86<br />
6.4. Secuencia de instalación en un nodo . . . . . . . . . . . . . . . . . . . . 88<br />
6.5. Pantalla de arranque (GRUB) de un nodo . . . . . . . . . . . . . . . . 89<br />
7.1. Pantalla de selección de máquina virtual . . . . . . . . . . . . . . . . . 92<br />
7.2. Esquema de las máquinas virtuales en los laboratorios . . . . . . . . . . 94
Índice de Tablas<br />
3.1. Tipos de Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13<br />
3.2. Comparativa de herramientas de clonado . . . . . . . . . . . . . . . . . 25<br />
3.3. Comparativa de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 32<br />
5.1. Lineas de código por módulo . . . . . . . . . . . . . . . . . . . . . . . . 77<br />
5.2. Estimación de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
1<br />
Introducción<br />
Existen numerosos entornos (empresas, instituciones, etc.) en los que se trabaja<br />
con una gran cantidad de nodos, que pueden ser desde ordenadores de sobremesa<br />
a estaciones de trabajo, nodos de computación, tabletPC,...; en definitiva, distintos<br />
tipos de hardware, en los que deben ejecutarse distintos tipos de software. Es decir,<br />
existe gran heterogeneidad tanto a nivel hardware como software.<br />
En un entorno con estas características, instalar el software necesario en cada equipo<br />
y mantenerlos actualizados y libres de errores puede llegar a ser una tarea laboriosa<br />
y que consume una ingente cantidad de tiempo. En este tipo de sistemas, desde el<br />
punto de vista de la administración, las tareas de gestión de la configuración y del<br />
mantenimiento son mucho más complejas que en los sistemas homogéneos, ya que cada<br />
nodo tiene unas características y restricciones específicas que difieren de las del resto<br />
(drivers de tarjeta gráfica, tamaño y tipo de disco duro,...). Además, cada usuario o<br />
grupo de usuarios puede necesitar ejecutar distintos sistemas operativos, lo que dificulta<br />
aún más la gestión de la configuración.<br />
Una primera alternativa planteada en el ámbito de la administración de grandes<br />
conjuntos de ordenadores es el uso de máquinas virtuales para tratar de homogeneizar<br />
el acceso a los nodos. Sin embargo, esta solución no suele ser la óptima, precisamente<br />
por esa homogeneización, ya que la capa de virtualización enmascara las características<br />
intrínsecas de cada máquina, haciéndolas a todas iguales. Esto es un problema si se
2<br />
CAPÍTULO 1. INTRODUCCIÓN<br />
quiere aprovechar al máximo el hardware de los equipos. Además, consume una cantidad<br />
nada despreciable de recursos que, de otra forma, podrían ser aprovechados por<br />
los usuarios.<br />
En los laboratorios docentes de la ESI se pueden observar de primera mano estos<br />
problemas, lo que crea una motivación adicional para desarrollar un sistema que facilite<br />
el uso de los ordenadores, tanto por parte de los alumnos como de los profesores y<br />
administradores. En el uso de los laboratorios se observó que el empleo de máquinas<br />
virtuales no era del todo aceptado: algunos profesores tenían problemas para poder<br />
realizar de forma efectiva las actividades que requerían sus asignaturas. Además, cada<br />
asignatura necesita de un conjunto de aplicaciones diferentes, que corren sobre distintos<br />
sistemas operativos, con dependencias que pueden entrar en conflicto con las de otras<br />
asignaturas, etc.<br />
Todos estos problemas se podrían evitar si los sistemas operativos se instalaran de<br />
forma nativa en los equipos. Sin embargo, hacer esto en todas las máquinas una a una<br />
implicaría un consumo de tiempo colosal, pues habría que examinar cada ordenador<br />
para determinar la configuración que necesita en base a su hardware. Después, habría<br />
que ir instalando máquina por máquina cada sistema operativo hasta que todo el<br />
conjunto estuviese listo.<br />
No obstante, esta tarea se puede automatizar. Se pueden crear herramientas que<br />
permitan inspeccionar el nodo para saber qué hardware específico posee, y se le pueden<br />
transmitir ficheros y realizar operaciones de forma remota. Una imagen especialmente<br />
preparada para un conjunto de nodos iguales podría copiarse de forma automática y<br />
dejar el nodo listo para su uso, sin intervención humana.<br />
En este documento se presenta el sistema HYDRA, que utiliza estas ideas para<br />
resolver los problemas derivados de administrar un conjunto de computadores con<br />
varios sistemas operativos. El sistema pretende dar soporte y automatizar las tareas de<br />
mantenimiento de estos escenarios, desde la instalación de un sistema operativo, hasta<br />
restaurar la configuración de un nodo, pasando por la aplicación de actualizaciones o<br />
parches.<br />
Con el sistema propuesto, los administradores podrán reducir el tiempo que dedican<br />
a instalar nuevos SSOO y recuperar o solucionar incidencias; y los usuarios podrán
1.1. ESTRUCTURA <strong>DE</strong>L DOCUMENTO 3<br />
disponer del SO con configuraciones personalizadas, con las aplicaciones y configuración<br />
que necesiten, incluso en el caso de que éstas cambien periódicamente.<br />
1.1. Estructura del Documento<br />
A continuación se detalla la estructura que seguirá el documento, con una pequeña<br />
descripción de lo que se puede encontrar en cada capítulo.<br />
Capítulo 2: Objetivos del Proyecto Aquí se encuentran recopilados los problemas<br />
detectados y los objetivos que se han marcado para el proyecto, tanto generales<br />
como específicos.<br />
Capítulo 3: Estado del Arte En este capítulo se realiza un estudio sobre las herramientas<br />
ya existentes en el mercado relacionadas con los problemas que se<br />
abordan en el proyecto.<br />
Capítulo 4: Método de Trabajo y Herramientas Este capítulo describe la metodología<br />
seguida para el desarrollo del proyecto, así como las herramientas utilizadas.<br />
Capítulo 5: Desarrollo Estudio del problema a resolver, análisis de requisitos, y<br />
diseño del sistema final.<br />
Capítulo 6: HYDRA En esta parte se encuentra una descripción detallada del sistema<br />
desarrollado, su estructura lógica y física, y las herramientas creadas para<br />
su elaboración.<br />
Capítulo 7: Caso de Estudio: ESI Este capítulo describe el sistema actual implantado<br />
en la ESI para intentar solventar los mismos problemas que HYDRA, y cómo<br />
la aplicación del nuevo sistema puede mejorar la situación actual.<br />
Capítulo 8: Conclusiones y Trabajo Futuro Para terminar, se realizará una evaluación<br />
de los objetivos alcanzados y el trabajo que queda por realizar.<br />
Anexo A: Manual de Usuario Pequeño manual de usuario para explicar el manejo<br />
de la herramienta de administración del sistema, y las distintas funcionalidades<br />
que ofrece.
4<br />
CAPÍTULO 1. INTRODUCCIÓN<br />
Anexo B: Terminología Definiciones de algunos de los conceptos más importantes<br />
del proyecto.<br />
Anexo C: Acrónimos y Siglas Listado de los acrónimos y siglas utilizados en este<br />
documento, y su significado.<br />
Anexo D: GNU Free Documentation License Texto de la licencia con que se libera<br />
este documento.
2<br />
Objetivos del Proyecto<br />
En este capítulo...<br />
Contenidos<br />
2.1. Objetivo General . . . . . . . . . . . . . . . . 5<br />
2.2. Objetivos Específicos . . . . . . . . . . . . . 6<br />
Para delimitar el alcance del proyecto y qué tareas deberá ser capaz de realizar una<br />
vez acabado, se definirán a continuación una serie de objetivos que permitirán<br />
entender mejor los problemas detectados y las soluciones a aportar.<br />
2.1. Objetivo General<br />
En definitiva, lo que se persigue con este proyecto es conseguir una herramienta que<br />
facilite la labor tanto al administrador de sistemas como a los usuarios, en entornos<br />
de trabajo en los que se utilizan varios sistemas operativos en cada máquina, y que<br />
permita a los usuarios utilizar todos los recursos de cada nodo sin limitaciones.
6<br />
CAPÍTULO 2. OBJETIVOS <strong>DE</strong>L PROYECTO<br />
El objetivo de este proyecto es desarrollar un sistema ligero y poco intrusivo que<br />
facilite la administración de la configuración del conjunto de nodos, permitiendo instalar<br />
varios SO en cada uno, de manera automática y teniendo en cuenta además que<br />
dicha configuración puede cambiar con cierta frecuencia (semanal o incluso diaria).<br />
2.2. Objetivos Específicos<br />
Para poder llevar a cabo esta tarea, es necesario cumplir una serie de requisitos.<br />
Entre los principales objetivos a cubrir se encuentran:<br />
Instalación automática y masiva La principal finalidad es poder distribuir aplicaciones<br />
y SSOO en un número elevado de computadores de forma automática y<br />
completamente desatendida, de forma que ni los administradores ni los usuarios<br />
deban tener en cuenta los detalles de gestión.<br />
Acceso a periféricos La utilización de una máquina virtual impide el acceso a los<br />
dispositivos que ésta no emule en su totalidad, lo que restringe, por ejemplo,<br />
la utilización de ciertos periféricos, puertos USB o la aceleración por hardware<br />
de las tarjetas gráficas. Utilizar el sistema operativo de forma nativa evita estos<br />
inconvenientes.<br />
Mayor rendimiento Al suprimir la máquina virtual, todas las prestaciones de la<br />
computadora quedan a disposición de las aplicaciones de usuario, lo que se traduce<br />
en un mejor aprovechamiento de la máquina.<br />
Integridad de datos Mediante el uso de la herramienta de administración del sistema,<br />
será muy sencillo restaurar un equipo cuyos datos o configuración se hayan<br />
visto comprometidos, por ejemplo por un ataque o por un mal uso por parte de los<br />
usuarios. Bastará con indicarle al sistema que vuelva a configurar ese equipo desde<br />
cero, y se hará de forma automática siguiendo los parámetros preestablecidos<br />
para esa máquina concreta.<br />
Configuración a medida Cada usuario podrá crear una o varias imágenes, y configurarlas<br />
como él quiera, con los programas y el software totalmente adaptado a<br />
sus necesidades específicas.
2.2. OBJETIVOS ESPECÍFICOS 7<br />
Planificación Los usuarios podrán planificar el funcionamiento del sistema, de forma<br />
que la gestión de los despliegues e instalaciones pueda realizarse de manera<br />
automática. De esta forma se reduce la carga de trabajo del personal de administración<br />
de sistemas.<br />
El sistema debe ser flexible, ya que las imágenes de los sistemas que se quieran arrancar<br />
cambiarán frecuentemente, se añadirán aplicaciones nuevas, e incluso se añadirán<br />
o eliminarán sistemas enteros. En caso de que algún ordenador vea comprometida la<br />
integridad de sus datos, debe ser muy fácil y rápido poder devolverlo a un estado<br />
seguro.<br />
La velocidad también es un factor importante, ya que se pretenden aprovechar los<br />
periodos de inactividad de los nodos (típicamente los periodos de descanso de la empresa<br />
o institución donde se instale) para realizar la instalación y dejar los ordenadores<br />
preparados para el turno siguiente.<br />
El sistema final debería ser capaz de manejar varias imágenes de sistemas operativos<br />
distintos, con sus aplicaciones instaladas, y arrancar la que corresponda. También<br />
debería proporcionar una manera sencilla de modificar y actualizar las imágenes en los<br />
servidores cuando los usuarios necesiten instalar nuevas aplicaciones o, simplemente,<br />
actualizar las existentes.<br />
La gestión debería ser fácil, simple y remota, para poder manejar y configurar<br />
cualquier máquina sin necesidad de tener que desplazarse físicamente hasta ella. Desde<br />
un ordenador que actuaría como administrador, deberían poder controlarse todos<br />
los demás, ver su estado, restaurarlos en caso de fallos, añadir/borrar/modificar las<br />
imágenes de trabajo, etc.<br />
Como motivación subyacente al desarrollo del proyecto, se pretende implantar HY-<br />
DRA como sistema de gestión de los laboratorios docentes de la ESI, y quizá también<br />
de todo su parque informático. Para mejorar el sistema actualmente en uso, es necesario<br />
evitar el uso de máquinas virtuales. De esta forma no sólo se ahorrarían los recursos<br />
que ocupan las máquinas virtuales, sino que además no habría limitación a la hora de<br />
utilizar los ordenadores.
3<br />
Estado del Arte<br />
En este capítulo...<br />
Contenidos<br />
3.1. Cargadores de Arranque . . . . . . . . . . . 10<br />
3.2. Particiones . . . . . . . . . . . . . . . . . . . 11<br />
3.3. Sistemas de Ficheros . . . . . . . . . . . . . 14<br />
3.4. Utilidades y herramientas de base . . . . . 15<br />
3.5. Middlewares de Comunicaciones . . . . . . 19<br />
3.6. Aplicaciones de Clonado . . . . . . . . . . . 23<br />
3.7. Distribución de Software . . . . . . . . . . . 25<br />
3.8. Herramientas para despliegue . . . . . . . . 29<br />
3.9. Gestión de Red . . . . . . . . . . . . . . . . . 33<br />
3.10. Conclusiones . . . . . . . . . . . . . . . . . . 34<br />
A<br />
ntes de iniciar el diseño de cualquier proyecto, es necesario informarse sobre las<br />
herramientas ya existentes sobre la misma temática, para ver si algunos de los<br />
problemas que se pretende resolver están ya solucionados, aunque sea en parte. Si es
10<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
posible reutilizar herramientas ya probadas y validadas, el proyecto ganará en fiabilidad<br />
y su desarrollo será menos costoso.<br />
En este capítulo se presenta una pequeña introducción a los conceptos y herramientas<br />
que se emplearon para la elaboración del proyecto, así como una descripción<br />
de varios sistemas y herramientas que versan sobre la misma problemática que este<br />
proyecto, y que intentan resolver algunos problemas similares a los planteados.<br />
3.1. Cargadores de Arranque<br />
Los cargadores de arranque son pequeños programas que se ejecutan al inicio del<br />
equipo, cuya tarea es cargar el kernel del sistema operativo y, finalmente, pasarle el<br />
control. En la mayoría de las arquitecturas hardware, los cargadores de arranque se<br />
alojan en el Master Boot Record (MBR), cuya capacidad es tan sólo de 512 Bytes, por<br />
lo que suelen dividirse en varias etapas. La primera etapa (que reside en el MBR) la<br />
lee la BIOS, y se ocupa de cargar la segunda etapa desde su ubicación, generalmente<br />
en otra parte del disco duro.<br />
La segunda etapa ejecuta el cargador del sistema operativo, y suele presentar un<br />
menú para que el usuario decida cuál quiere arrancar. El cargador cede entonces el<br />
control al kernel del sistema operativo, que se ocupa de cargar los controladores de<br />
dispositivos y demás programas para el control del sistema, hasta finalmente cargar<br />
los programas de usuario. Normalmente, los usuarios consideran el proceso de carga<br />
finalizado cuando el sistema es capaz de responder a los eventos del exterior (periféricos<br />
de entrada).<br />
GRUB y LILO<br />
Son los dos cargadores más extendidos en el mundo POSIX. Funcionan prácticamente<br />
igual, aunque GRand Unified Bootloader (GRUB) tiene la ventaja de contar con<br />
una consola de línea de comandos. Esto resulta útil cuando existe algún error y no se<br />
puede cargar el sistema operativo. En el caso de LInux LOader (LILO) sería necesario<br />
arrancar el equipo desde otro dispositivo, editar la configuración y reiniciar.
3.2. PARTICIONES 11<br />
Aunque son producto de la comunidad GNU, ambos pueden arrancar otros sistemas<br />
operativos mediante mecanismos de chain-loading, que consisten en utilizar los<br />
cargadores de arranque de los otros sistemas operativos, en lugar de intentar cargar el<br />
SO directamente.<br />
Loadlin<br />
Se trata de un cargador de arranque un tanto especial, que sirve para arrancar Linux<br />
desde Microsoft Disk Operating System (MS-DOS) o Windows (95, 98 y ME), una vez<br />
que éstos estaban en ejecución, quitándolos de la memoria y pasándole el control al<br />
kernel Linux. Este tipo de cargador también se conoce como ✭✭calzador✮✮, y no operan<br />
desde el MBR.<br />
Cargadores por Red<br />
Es posible también arrancar un equipo informático a través de la red. En este<br />
caso, el sistema operativo se encuentra almacenado en otro computador, que actúa de<br />
servidor, y se transfieren los ficheros por protocolos ligeros, por ejemplo, TFTP. Es<br />
necesario disponer de una configuración especial en el servidor y que la tarjeta de red<br />
y el BIOS del cliente tengan soporte para el proceso.<br />
3.2. Particiones<br />
Las particiones son divisiones lógicas realizadas en el disco duro, para dedicarlas<br />
a cometidos específicos, o evitar la pérdida de todos los datos en caso de que ocurra<br />
algún fallo en el disco: mientras que una partición puede verse afectada, las otras se<br />
mantendrían a salvo.<br />
En el disco duro, y concretamente en el MBR, se almacena una estructura conocida<br />
como Tabla de Particiones. En esta estructura se describen las particiones existentes en<br />
el disco. La tabla empieza en la dirección 0x1BE y ocupa 64 Bytes, con 4 entradas de 16<br />
Bytes cada una. Al final se encuentra la palabra 0xAA55 (55 AA en codificación littleendian)<br />
que es la firma de registro de inicio (Boot Record Signature). En la figura 3.1
12<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
01B0 ‖ CD 10 AC 3C 00 75 F4 C3 E7 F9 07 00 00 00 80 01<br />
01C0 ‖ 01 00 07 FE FF FF 3F 00 00 00 8D F2 34 0C 00 FE<br />
01D0 ‖ FF FF 83 FE FF FF CC F2 34 0C 1F F5 E8 02 00 FE<br />
01E0 ‖ FF FF 82 FE FF FF EB E7 1D 0F FA E7 1D 00 00 FE<br />
01F0 ‖ FF FF 83 FE FF FF E5 CF 3B 0F 9C 75 E0 0D 55 AA<br />
Partición NTFS<br />
Partición Linux<br />
Partición Swap<br />
Partición Linux<br />
Figura 3.1: Tabla de Particiones<br />
se muestran los últimos 80 Bytes del MBR de un disco duro, y se puede observar la<br />
tabla de particiones, en la que se han resaltado las 4 entradas.<br />
Las particiones pueden ser de 3 tipos:<br />
Primarias Son el primer tipo de partición que se creó, divisiones crudas del disco, y<br />
contienen únicamente un sistema de ficheros. Debido al reducido espacio disponible<br />
en el MBR, la tabla de particiones sólo puede albergar 4 particiones primarias.<br />
Una entrada de este tipo en la tabla de particiones tiene la siguiente estructura:<br />
Indicador de arranque (1 Byte) Usado por los sistemas DOS para indicar<br />
una partición arrancable. El valor 0x80 indica que es arrancable (o activa);<br />
0x00, inactiva.<br />
Comienzo de la partición (3 Bytes) Coordenadas en codificación Cylinder,<br />
Head, Sector (CHS) del inicio de la partición.<br />
Tipo de partición (1 Byte) Descriptor del tipo de partición. Algunos tipos<br />
interesantes de particiones se muestran en la tabla 3.1<br />
Final de la Partición (3 Bytes)<br />
formato CHS.<br />
Último sector de la partición, también en<br />
LBA (3 Bytes) Sector de inicio de la partición, esta vez en formato Logical<br />
Block Addressing (LBA). Este formato de direccionamiento es más sencillo<br />
que el CHS, ya que numera los sectores consecutivamente, en lugar de utilizar<br />
3 coordenadas.<br />
Tamaño (4 Bytes) Tamaño de la partición en sectores. Esto implica que, con<br />
512 Bytes por sector, la mayor partición posible es de unos 2.048 GiB.
3.2. PARTICIONES 13<br />
Código Tipo<br />
0x04 FAT-16 menor de 32 MB<br />
0x05 Partición Extendida<br />
0x06 FAT-16 mayor de 32 MB<br />
0x07 HPFS o NTFS<br />
0x0B FAT-32<br />
0x0C FAT-32 con extensión INT-13<br />
0x0F Partición extendida más allá del cilindro 1024<br />
0x82 Linux Swap<br />
0x83 Linux ext2/ext3/ext4/reiserfs y otros<br />
Tabla 3.1: Tipos de Particiones<br />
Extendidas Son un tipo especial de partición primaria, creado para solucionar la<br />
limitación en el número máximo de particiones primarias. En realidad es una<br />
estructura en forma de lista enlazada, utilizada para albergar dentro particiones<br />
lógicas, no datos.<br />
Lógicas o Secundarias Estas particiones sí que contienen datos y siempre están contenidas<br />
en una partición extendida.<br />
La entrada correspondiente a una partición extendida no contiene el mismo formato<br />
que la de una primaria, sino que indica otro sector, que será un Extended Boot Record<br />
(EBR), en el que se aloja otra tabla de particiones. Esta tabla también es un poco<br />
diferente, ya que es para las particiones lógicas. La tabla contiene la información sobre<br />
la partición lógica y, si procede, el enlace a otro EBR, donde se encuentra la siguiente<br />
partición lógica.<br />
Cabe destacar que, mientras los sistemas DOS y Windows sólo podían arrancar<br />
desde una partición primaria, otros gestores como GRUB y LILO buscan en la tabla<br />
de particiones su segunda etapa (ver sección 3.1) en lugar de los datos del sistema<br />
operativo. Esta segunda etapa es capaz de arrancar desde cualquier partición del disco,<br />
independientemente de su tipo.
14<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
3.3. Sistemas de Ficheros<br />
La información se guarda en los dispositivos en forma de bloques, usualmente de<br />
512 Bytes, pero el sistema de ficheros proporciona una abstracción (el fichero) que<br />
representa un conjunto de bloques relacionados entre sí. De hecho, un sistema operativo<br />
seguro no dejará que los procesos manejen bloques: el fichero es la unidad mínima de<br />
almacenamiento del sistema de ficheros.<br />
Un sistema de ficheros es una estructura de datos que permite manejar y gestionar<br />
la información almacenada en un dispositivo.<br />
Cada sistema operativo suele utilizar sus propios sistemas de ficheros, aunque normalmente<br />
son capaces de manejar otros, para aumentar la interoperabilidad. El tipo de<br />
sistema de ficheros que utilice un determinado SO será uno de los factores clave para<br />
poder darle soporte en HYDRA.<br />
A cada fichero se le asigna una serie de atributos, que es información útil para la<br />
gestión del archivo:<br />
Nombre Una cadena de texto para identificar el archivo. Algunos SSOO permiten<br />
que un fichero tenga más de un nombre.<br />
Ubicación Indica el dispositivo y la zona de almacenamiento del mismo para el fichero.<br />
En la mayoría de los casos ni siquiera se puede consultar.<br />
Tipo Indica la clase de información que almacena (imagen, audio, texto...). Dependiendo<br />
del tipo, pueden existir operaciones especializadas para el mismo.<br />
Tamaño Tamaño actual del fichero en Bytes.<br />
Permisos Información para el control de acceso al fichero.<br />
Fecha Información sobre cuándo se creó el fichero, cuándo se accedió a él, la última<br />
vez que fue modificado, etc.<br />
Usuario El identificador del usuario que creó el fichero.<br />
Sólo los dos primeros son realmente indispensables, el resto son opcionales, por lo<br />
que puede que algunos sistemas de ficheros no cuenten con algunos de estos atributos.
3.4. UTILIDA<strong>DE</strong>S Y HERRAMIENTAS <strong>DE</strong> BASE 15<br />
3.4. Utilidades y herramientas de base<br />
Existe una gran cantidad de programas, herramientas y protocolos que proporcionan<br />
funcionalidades de propósito general necesarias para los objetivos de cualquier proyecto.<br />
A continuación se estudian algunas de las más relevantes para este trabajo.<br />
3.4.1. WoL<br />
Wake on Lan (WoL) es una tecnología que permite arrancar o despertar ordenadores<br />
de una misma red de forma remota. La máquina ✭✭despertador✮✮ envía un mensaje<br />
especial a la Local Area Network (<strong>LA</strong>N), destinado a la dirección Medium Access<br />
Control (MAC) de la máquina que se pretende despertar. De hecho, el mensaje consiste<br />
en 6 Bytes de ✭✭unos✮✮ seguidos de la dirección MAC destino repetida 16 veces. Si la<br />
BIOS y la tarjeta de red del nodo destino lo soportan, el ordenador destino iniciará el<br />
arranque.<br />
3.4.2. PXE<br />
La utilidad Preboot eXecution Environment (PXE) [Int99] brinda la oportunidad<br />
de poder arrancar un ordenador por red, independientemente de los medios de almacenamiento<br />
disponibles o de los sistemas operativos instalados en él.<br />
Un ordenador configurado para arrancar con PXE enviará una petición de arranque<br />
por red antes de intentar arrancar desde su disco duro (en caso de tenerlo). Esta petición<br />
no es más que un paquete DHCP especial, que será recibido por el servidor de DHCP.<br />
El servidor, que también es un servidor PXE, le envía por la red los ficheros necesarios<br />
para el arranque. Para ello, el servidor debe tener también un servidor de ficheros<br />
instalado y configurado, como por ejemplo, TFTP. El sistema operativo que se ejecuta<br />
en el cliente se encuentra almacenado en un directorio que se exporta por Network File<br />
System (NFS). Cuando el cliente necesita ejecutar algo, accede a los ficheros a través<br />
de la red (ver figura 3.2).
16<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
Figura 3.2: Esquema de funcionamiento de PXE<br />
3.4.3. FTP<br />
El protocolo FTP, descrito originalmente en la RFC 114 [Bhu71] en 1971, es uno<br />
de los primeros protocolos creados para redes informáticas. Define el mecanismo para<br />
copiar ficheros de un host a otro, utilizando una conexión TCP/IP. Posee conexiones<br />
separadas para control y datos, y permite autenticación por contraseña.<br />
La intención de este protocolo era proporcionar un mecanismo para que los usuarios<br />
pudieran acceder a los ficheros de un host remoto sin necesidad de tener que iniciar<br />
una sesión o saber cómo usar el sistema remoto; lo que el autor denomina ✭✭hacer uso<br />
indirecto de la computadora✮✮.<br />
Se consigue por tanto que los usuarios tengan una forma estandarizada de acceder<br />
a los recursos de otros equipos, abstrayendo los detalles del sistema operativo, forma<br />
de almacenamiento...<br />
El protocolo FTP permite la transferencia de cualquier tipo de fichero, desde archivos<br />
de texto ASCII hasta imágenes del núcleo, e incluso ofrece una petición para<br />
ejecutar comandos en el host remoto.
3.4. UTILIDA<strong>DE</strong>S Y HERRAMIENTAS <strong>DE</strong> BASE 17<br />
La especificación original definía las siguientes peticiones:<br />
Identify Identifica al usuario en la máquina remota.<br />
Retrieve Descarga un fichero.<br />
Store Sube un fichero.<br />
Append Añade datos a un fichero.<br />
Delete Borra un fichero.<br />
Rename Renombra un fichero.<br />
addname Añade nombres a un fichero (ver sección 3.3).<br />
deletename Elimina nombres de un fichero.<br />
Lookup Recupera los atributos de un fichero.<br />
Open No transfiere datos, sino que abre el fichero especificado. Las peticiones siguientes<br />
se tratan sobre el fichero abierto hasta que llegue la petición de cierre.<br />
Close Cierra un fichero.<br />
Execute Ejecuta el fichero especificado, que debe ser un programa ejecutable.<br />
Posteriormente, se añadieron diversas funcionalidades, como el listado y la navegación<br />
de directorios.<br />
3.4.4. TFTP<br />
La RFC 1350 [Sol92] define el protocolo TFTP, que es una versión más ligera y<br />
reducida de FTP, utilizada para transferir ficheros entre dos ordenadores de forma<br />
rápida y sencilla. Al contrario que FTP, TFTP trabaja sobre User Datagram Protocol<br />
(UDP), en lugar de Transmission Control Protocol (TCP), y sólo puede leer y escribir<br />
ficheros entre dos hosts; no permite manejar directorios ni autenticación.
18<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
3.4.5. NFS<br />
NFS es un protocolo desarrollado por Sun Microsistems que permite incorporar<br />
(montar) un sistema de ficheros remoto al sistema de ficheros local a través de la<br />
red. Con él se puede acceder a los ficheros del sistema remoto de forma totalmente<br />
transparente, como si formara parte del sistema local.<br />
El protocolo fue diseñado para que fuera totalmente independiente de la arquitectura<br />
de la red, el sistema operativo y los protocolos de transporte. Para ello se utilizaron<br />
activamente las primitivas de Remote Procedure Call (RPC) y el estándar eXternal<br />
Data Representation (XDR), que define una forma común de representar un conjunto<br />
de datos a través de una red. [SBC + 99]<br />
Los servidores NFS son servidores sin estado, de forma que cuando una petición<br />
falla, el cliente no necesita saber porqué, simplemente reintenta hasta que la petición<br />
tiene éxito, lo que simplifica el protocolo.<br />
3.4.6. unionfs<br />
Con unionfs 1 [WZ04] se pueden unir varios sistemas de ficheros distintos para hacer<br />
que formen uno sólo. También puede utilizarse para permitir realizar escrituras en<br />
ficheros de un medio de sólo-lectura: la rama de sólo lectura se combina con otra de<br />
lectura-escritura que reside en memoria, de forma que se pueden realizar cambios sobre<br />
los ficheros, aunque éstas no serán permanentes. El ejemplo más representativo de este<br />
uso son los LiveCD que permiten realizar cambios en el sistema de ficheros mientras<br />
está en uso, pero los cambios no son permanentes entre sesiones.<br />
3.4.7. MAD Project<br />
El proyecto MAD 2 reúne un conjunto de implementaciones de protocolos para transporte<br />
unidireccional multicast de información. Mediante la combinación de dichos protocolos<br />
se consigue control de congestión a través de la descripción de sesiones FLUTE.<br />
1 http://www.filesystems.org/project-unionfs.html<br />
2 http://mad.cs.tut.fi/
3.5. MIDDLEWARES <strong>DE</strong> COMUNICACIONES 19<br />
Figura 3.3: Invocaciones remotas con semántica de invoación local, típicas de los middlewares<br />
de comunicaciones<br />
En particular, el protocolo File Delivery over Unidirectional Transport (FLUTE) es<br />
aplicable a la distribución de ficheros grandes y pequeños a muchos hosts, usando sesiones<br />
de distribución de varios segundos o más. Por ejemplo, FLUTE podría emplearse<br />
para el despliegue de grandes actualizaciones de software a varios hosts simultáneamente.<br />
[PLL + 04]<br />
3.5. Middlewares de Comunicaciones<br />
Un middleware de comunicaciones permite al programador abstraerse de las complejidades<br />
y heterogeneidades de las capas inferiores (red, lenguaje de implementación,<br />
localización, arquitectura hardware, sistema operativo, etc.), facilitando la programación<br />
de aplicaciones y sistemas distribuidos.<br />
3.5.1. ZeroC Ice<br />
Internet Communications Engine (Ice) [HS09] es un middleware de comunicaciones<br />
orientado a objetos desarrollado por la empresa ZeroC bajo licencia GPL, y en la
20<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
actualidad lo utilizan empresas como Skype, Hewlett-Packard (HP), Indra e incluso<br />
Boeing, en su proyecto Future Combat Systems. 3<br />
Entre los servicios que ofrece, se encuentran transparencia de localización, despliegue<br />
de ficheros (IcePatch2 ), clustering (IceGrid), canales de eventos (IceStorm),<br />
persistencia (Freeze) y rutado software a nivel de aplicación (Glacier).<br />
El funcionamiento de Ice se basa en una arquitectura cliente/servidor, en la que<br />
los clientes realizan invocaciones remotas a los servidores como si fueran invocaciones<br />
locales (figura 3.3). Las operaciones que los clientes pueden invocar sobre los servidores<br />
se describen en un fichero escrito en lenguaje Specification Language for Ice (Slice),<br />
que define un contrato de interfaz entre ambas partes. Existen en Ice utilidades para<br />
traducir la interfaz Slice a los lenguajes de programación más comunes; concretamente,<br />
la distribución estándar proporciona traductores a C++, C#, Python, Java y Ruby. El<br />
cliente instancia un objeto que implementa dicha interfaz y que actuará de proxy del<br />
objeto remoto (ver figura 3.4). La implementación del objeto remoto que procesa las<br />
peticiones se llama sirviente, y se comunica con el middleware a través de un adaptador<br />
de objetos.<br />
Un adaptador de objetos es el contenedor donde se alojan los objetos del servidor<br />
que se deben acceder desde el cliente. El adaptador se encarga de traducir las peticiones<br />
de los clientes a los métodos específicos de los objetos. También es el responsable de<br />
crear los proxies que se le pasan a los clientes, ya que es quien tiene los datos sobre sus<br />
interioridades (tipos, identidades, detalles de transporte...)<br />
Para poder comunicarse con el exterior, el adaptador de objetos está asociado con<br />
uno o más endpoints. Si un adaptador de objetos está asociado con varios endpoints,<br />
los objetos que contiene podrán ser invocados de varias maneras. La representación<br />
textual de un endpoint tiene la siguiente forma:<br />
tcp -h 161.67.27.15 -p 4061<br />
Esto significa que el sirviente está escuchando en la interfaz cuya dirección es<br />
161.67.27.15, en el puerto 4061, y que utiliza el protocolo TCP para transmitir.<br />
3 Fuente: http://www.zeroc.com/customers.html
3.5. MIDDLEWARES <strong>DE</strong> COMUNICACIONES 21<br />
Figura 3.4: Estructura de Ice (ZeroC [HS09])<br />
Como es posible que varios sirvientes estén utilizando el mismo endpoint, es necesario<br />
que cada uno posea una identidad única dentro del sistema distribuido. Esta<br />
identidad se le asigna (bien por el programador, bien automáticamente) cuando el sirviente<br />
se añade al adaptador de objetos. De esta forma, se puede localizar un objeto<br />
unívocamente mediante su identidad y su endpoint:<br />
MiObjeto -t : tcp -h 161.67.27.15 -p 4061<br />
Esto es, precisamente, el proxy. La opción -t (twoway) significa que la comunicación<br />
es en ambos sentidos, se realiza una petición y se espera una respuesta. Si se hubiera<br />
indicado -o (oneway) significaría una invocación sin respuesta.<br />
3.5.2. CORBA<br />
Common Object Request Broker Architecture (CORBA) es un estándar [OMG08]<br />
del Object Management Group (OMG) que define un conjunto de protocolos y mecanismos<br />
que conforman un modelo de comunicaciones para sistemas distribuidos. Es uno de<br />
los middleware más usados y extendidos. De hecho, Ice nació a partir de muchas de las<br />
ideas de CORBA 4 , por lo que la arquitectura general es muy parecida (ver figura 3.5).<br />
Dispone también de un lenguaje de especificación de interfaces (Interface Definition<br />
4 Se puede ver una comparativa de ambos middlewares en http://www.zeroc.com/iceVsCorba.html
22<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
Figura 3.5: Estructura de CORBA (OMG [OMG08])<br />
Language (IDL)), así como de estructuras para los proxies, esqueletos y adaptadores<br />
de objetos, similares a las de Ice.<br />
Al ser una definición de un estándar, no existe una implementación oficial como<br />
ocurre con Ice, si no que cada organismo puede realizar su propia implementación.<br />
3.5.3. Java RMI<br />
Desarrollado por Sun Microsistems, Java Remote Method Invocation (RMI) es<br />
un middleware exclusivamente para aplicaciones Java. La interfaz entre el cliente y<br />
el servidor se especifica mediante el uso de clases abstractas (interface) de Java, que<br />
contienen los prototipos de los métodos que el servidor proporciona a los clientes.<br />
En primer lugar, el servidor hace públicos los objetos que serán accesibles remotamente.<br />
Después, los clientes deben localizar dichos objetos, para lo cual pueden o bien<br />
utilizar el RMI simple naming facility (el servidor debe haber registrado los objetos<br />
en el rmiregistry), o bien intercambiar referencias de objetos con el servidor. Una vez<br />
hecho esto, los clientes pueden invocar los métodos remotos de los objetos del servidor.
3.6. APLICACIONES <strong>DE</strong> CLONADO 23<br />
Figura 3.6: Estructura de Java RMI (Sun Microsistems on-line Training)<br />
3.6. Aplicaciones de Clonado<br />
Algunas herramientas se dedican al clonado de ficheros, particiones o discos completos,<br />
lo que puede ser útil para el proyecto. Se describen a continuación.<br />
3.6.1. PartImage<br />
PartImage 5 es una herramienta ideada para realizar copias de seguridad, aunque<br />
también se puede utilizar para realizar instalaciones de sistemas. Facilita la creación<br />
de imágenes de particiones, comprimiéndolas con gzip para ahorrar espacio.<br />
Tiene dos desventajas graves: las particiones deben ser exactamente del mismo<br />
tamaño que las que se guardaron, y las particiones se restauran en local (sin red), por<br />
lo que habría que ir ordenador por ordenador haciendo la copia. Además, el sistema<br />
que se quiera copiar debe ser desmontado previamente.<br />
3.6.2. Ghosting for Unix<br />
Ghosting for Unix (G4U) 6 es otra herramienta de clonado de discos duros (o particiones<br />
solamente). Primero, es necesario descargar las 2 imágenes de disquete o la<br />
5 http://www.partimage.org/<br />
6 http://www.feyrer.de/g4u/
24<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
imagen ISO en CD del programa, y con ella, hacer una imagen del disco duro a clonar<br />
y subirla a un servidor FTP.<br />
Después, en el ordenador destino, se arranca con el CD o el disquete y se clona<br />
desde el servidor FTP. La imagen que se crea es binaria, es decir, el disco o partición<br />
se copia bit a bit, obviando la información del sistema de ficheros o las particiones.<br />
Esto hace que sea muy probable perder información si los discos duros del servidor y<br />
el cliente no son del mismo tamaño.<br />
Esto, junto con el hecho de tener que arrancar cada ordenador manualmente es<br />
inaceptable, sobre todo cuando se tiene un número elevado de ordenadores que gestionar.<br />
3.6.3. NTFS Clone<br />
Se trata de una herramienta 7 que trabaja a nivel de sectores del disco duro, para<br />
clonar un sistema de ficheros de tipo NTFS de Windows y almacenarlo en un fichero,<br />
una imagen o enviarlo a la salida estándar.<br />
Es muy útil para hacer copias de seguridad, y puede emplearse para duplicar la<br />
información de un disco duro a varios. Sin embargo, sólo permite duplicar sistemas de<br />
ficheros NTFS, por lo que su utilidad es limitada.<br />
3.6.4. Clonezilla<br />
Clonezilla 8 es otra herramienta de clonado de particiones (o discos enteros). Puede<br />
trabajar con diferentes sistemas de ficheros, lo que permite usarlo con varios sistemas<br />
operativos.<br />
Está basado en Diskless Remote Boot in Linux (DRBL), Partition Image, NTFS<br />
Clone y UDPCast; por lo que sus ventajas e inconvenientes son los que ya se han<br />
comentado en esas herramientas.<br />
7 http://www.linux-ntfs.org/doku.php?id=ntfsclone<br />
8 http://www.clonezilla.org/
3.7. DISTRIBUCIÓN <strong>DE</strong> SOFTWARE 25<br />
Herramienta Multicast Unidad Multiplataforma<br />
Part Image<br />
Particiones<br />
Ghosting for Unix<br />
SO<br />
NTFS Clone N/A Particiones<br />
Clonezilla<br />
Particiones<br />
Tabla 3.2: Comparativa de herramientas de clonado<br />
3.7. Distribución de Software<br />
Hay también herramientas especializadas en la distribución masiva de grandes cantidades<br />
de software, que se describen en esta sección.<br />
3.7.1. UDPCast<br />
Se trata de una herramienta de transferencia de ficheros basada en el protocolo UDP<br />
para enviar datos simultáneamente a varios destinos a la vez mediante multicast. 9<br />
Para poder instalar un sistema operativo en varias máquinas al mismo tiempo<br />
mediante UDPCast es necesario que todas tengan la misma configuración hardware:<br />
mismo procesador, mismos periféricos e, incluso, la misma configuración de disco duro<br />
(particiones, sectores, clusters. . . ).<br />
Un ordenador se elige como servidor y se configura para que distribuya la imagen<br />
(sólo permite una). El resto se arranca (mediante disquete, CD o red) como ✭✭receptores✮✮<br />
y cuando todos están listos, comienza la transmisión.<br />
3.7.2. ZeroInstall<br />
ZeroInstall 10 es un sistema desarrollado por Thomas Leonard. Con él pretende complementar<br />
los sistemas de instalación tradicionales de las distribuciones GNU/Linux,<br />
9 http://udpcast.linux.lu/<br />
10 http://0install.net/
26<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
en las que, como medida de seguridad, únicamente el administrador puede instalar<br />
programas.<br />
Los principales objetivos y características de ZeroInstall son:<br />
Todos los usuarios pueden instalar programas En la mayoría de las distribuciones,<br />
es necesario recurrir al administrador del sistema para instalar cualquier<br />
programa. ZeroInstall pretende dotar a todos los usuarios del sistema de la posibilidad<br />
de instalar el software que necesiten.<br />
No importa dónde se encuentre el software para instalarlo Normalmente, las<br />
distribuciones de GNU/Linux tienen unos servidores llamados repositorios o mirrors<br />
en los que se encuentran las aplicaciones disponibles. Es posible que una<br />
aplicación exista pero no esté disponible en dichos repositorios. Con ZeroInstall<br />
esto no es problema, ya que utiliza la versión publicada en la página del desarrollador,<br />
sin necesidad que la distribución la empaquete en su formato particular.<br />
No importa si el software está ya instalado Tradicionalmente, primero se instala<br />
la aplicación y luego se ejecuta. ZeroInstall directamente la lanza, manejando<br />
la descarga y el almacenamiento temporal (caché) automáticamente. Puede elegirse<br />
si borrar o conservar lo que se haya descargado para futuras ejecuciones sin<br />
necesidad de volver a descargarlo.<br />
Cuando un usuario quiere ejecutar una aplicación, debe especificar una Universal<br />
Resource Locator (URL), en la que se encuentra el programa. Previamente, el programa<br />
debe haber sido adaptado para poder ser ejecutado en estas circunstancias. Dicha<br />
adaptación se basa principalmente en crear un paquete que contenga todo los recursos<br />
del programa, de forma que las rutas sean siempre auto-contenidos en el paquete.<br />
3.7.3. Fully Automated Installation<br />
Este proyecto, iniciado por Thomas Lange en la Universidad de Colonia 11 en 1999<br />
como proyecto personal, sirve para instalar una imagen de GNU/Linux en varios ordenadores<br />
de forma automática.<br />
11 http://www.informatik.uni-koeln.de/fai/
3.7. DISTRIBUCIÓN <strong>DE</strong> SOFTWARE 27<br />
Soporta varias configuraciones y la imagen a instalar puede ser de prácticamente<br />
cualquier distribución. Permite no sólo instalar un sistema GNU desde cero, sino que<br />
además es posible actualizar el sistema sin necesidad de reinstalar.[GLR99]<br />
Su funcionamiento se realiza en 3 pasos: primero, se arranca el cliente por PXE;<br />
después, se monta por NFS una imagen mínima de un sistema GNU/Linux sin hacer<br />
uso de los discos locales; y por último, se realiza la instalación.<br />
Sin embargo, no es posible tener varios sistemas operativos disponibles, sólo instala<br />
uno. Tampoco permite elegir qué sistema instalar, si no que sólo se puede instalar el<br />
que se haya configurado en el servidor. Aún así, se eligió para formar parte del proyecto<br />
de la ciudad de Munich para migrar los cerca de 14000 ordenadores de sus empleados<br />
públicos a software libre. [LIM]<br />
3.7.4. System Imager<br />
Este sistema 12 es similar al anterior en cuanto a objetivos se refiere, aunque trabaja<br />
de forma distinta. En lugar de arrancar un kernel por NFS, arranca un Linux empotrado<br />
propio (Brian’s Own Embedded Linux (BOEL)). Se trata de un kernel mínimo, que<br />
contiene sólo lo necesario para poder lanzar alguno de los clientes que utiliza para la<br />
distribución: BitTorrent, Flamethrower o Secure SHell (SSH). Estos clientes se ocupan<br />
de descargar del servidor el resto de binarios del BOEL y los ficheros de la imagen que<br />
se va a instalar. [Fin00]<br />
La imagen a instalar se obtiene desde un ✭✭Golden Client✮✮, que es una máquina<br />
funcional, que se configura como se quiere que queden las demás. No se pueden instalar<br />
varias imágenes en cada ordenador, ni permite una planificación horaria del sistema.<br />
3.7.5. DRBL<br />
DRBL permite arrancar un ordenador vacío por red, mediante PXE y NFS. El<br />
ordenador servidor contiene una imagen de un SO que le transfiere a los clientes por<br />
red, que lo montan con NFS.<br />
12 http://wiki.systemimager.org/index.php/Main Page
28<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
Cuenta con un servidor en el que se configura la imagen que arrancarán los clientes.<br />
Para mejorar la eficiencia, recomiendan configurar el servidor con varias tarjetas de red<br />
y desactivar SELinux.<br />
No permite la instalación de sistemas operativos, sino que los clientes arrancan<br />
el SO desde el servidor. En realidad, todos los ficheros se encuentran en el servidor,<br />
exportados mediante NFS. Los clientes se conectan al servidor y descargan los ficheros a<br />
medida que los van necesitando. Mientras que el servidor puede ser cualquier ordenador,<br />
pues sólo se encarga de servir ficheros y autenticar usuarios, los clientes deben tener la<br />
potencia de cálculo suficiente para ejecutar los programas.<br />
3.7.6. LTSP<br />
Linux Terminal Server Project (LTSP) 13 es un concepto parecido al de DRBL.<br />
Se trata de un proyecto orientado a rehabilitar los ordenadores antiguos y con pocas<br />
prestaciones que ya no se utilizan, convirtiéndolos en terminales ligeros que se conectan<br />
a un servidor para ejecutar sus aplicaciones. El servidor recibe las entradas de los<br />
terminales y ejecuta las tareas, enviándoles los resultados.<br />
Se está implantando con bastante éxito en escuelas e institutos de EEUU como<br />
forma de ahorrar costes.<br />
3.7.7. SLIM<br />
El proyecto Single Linux Image Management (SLIM) [LWH + 04] se desarrolla en el<br />
Departamento de Informática de la Universidad de Tokio 14 .<br />
Es el mismo concepto de terminal ligero que utiliza LTSP, aunque SLIM permite<br />
a los usuarios de los terminales elegir qué sistema operativo desean arrancar.<br />
13 http://www.ltsp.org<br />
14 http://slim.cs.hku.hk/
3.8. HERRAMIENTAS PARA <strong>DE</strong>SPLIEGUE 29<br />
3.7.8. Userful Multiplier<br />
Es una aplicación que permite compartir el escritorio de un ordenador con hasta 10<br />
ordenadores más, a través de las tarjetas de vídeo y aprovechando el tiempo de CPU<br />
desaprovechado al haber un sólo usuario en la máquina. 15<br />
Es necesario ampliar el hardware del ordenador servidor con tarjetas de vídeo,<br />
teclados, ratones y todos los periféricos que se quieran usar. Es decir, permite tener un<br />
ordenador con 10 monitores, teclados y ratones.<br />
3.7.9. rootz<br />
Según sus propios creadores 16 :<br />
✭✭rootz es un sistema de reparto de software basado en chroot. En otras<br />
palabras, es una herramienta que te ayuda a ejecutar aplicaciones sin descargarlas<br />
e instalarlas; simplemente, ejecutarlas✮✮.<br />
El cliente se conecta a un servidor, donde localiza una distribución live y la monta en<br />
el sistema de ficheros local vía HTTPFS, pudiendo acceder entonces mediante chroot<br />
a todos sus recursos.<br />
3.8. Herramientas para despliegue<br />
3.8.1. Virtual Appliances<br />
En [SHWW08] se describe un modelo para simplificar el despliegue de servicios<br />
mediante Virtual Appliances. Estas appliances están respaldadas por máquinas virtuales,<br />
y sólo se centran en el despliegue de aplicaciones, sin considerar la distribución de<br />
SSOO. Por ello, no se tienen en cuenta aspectos como la preparación y configuración<br />
15 http://www2.userful.com/products/userful-multiplier<br />
16 http://vamosproject.org/rootz
30<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
Figura 3.7: Tipos de IU ([DGV04])<br />
de los nodos (particiones, sistema de ficheros, plataforma hardware, etc.), necesidades<br />
específicas de cada SO para el arranque, etc.<br />
Cada appliance consiste en una máquina virtual en la que se instala el software<br />
específico que se quiere distribuir. Proporcionan mecanismos para configurarlas a través<br />
de unos agentes. Estos agentes pueden interactuar entre sí para resolver dependencias<br />
y configurar piezas de software de dos appliances distintas (por ejemplo, con Apache<br />
en una appliance y MySQL en otra; Apache necesita la funcionalidad de MySQL).<br />
3.8.2. MetaOS<br />
Una solución propuesta por Zhang y Zhou[ZZ07] describe un escenario en el que los<br />
programas están almacenados en un servidor central, y los usuarios los ejecutan bajo<br />
demanda desde otros equipos, desligando así el almacenamiento del programa de su<br />
ejecución. La administración se vuelve más sencilla, ya que los programas se encuentran<br />
ubicados en un sólo equipo.<br />
3.8.3. Installable Units<br />
Draper et al. [DGV04] definieron un esquema XML para describir unidades de<br />
instalación Installable Units (IU), con la intención de crear un estándar común para<br />
que dichas unidades de instalación pudieran ser manejadas por cualquier tecnología de<br />
instalación. Su trabajo estaba orientado a paquetes, aplicaciones, plug-ins, etc., sin dar<br />
un soporte específico a la instalación de SSOO.
3.8. HERRAMIENTAS PARA <strong>DE</strong>SPLIEGUE 31<br />
Las IU se dividen en varios tipos (figura 3.7):<br />
Smallest Installation Unit (SIU) Son las unidades más pequeñas. Consisten en el<br />
software a instalar y una serie de metadatos relevantes para la instalación.<br />
Container Insallable Unit (CIU) Contienen varias SIU y CIU. Se distribuyen a<br />
cada instancia de un destino concreto.<br />
Solution Module (SM) Un SM incluye IUs que pueden asociarse cada una a una<br />
topología distinta.<br />
rootIU Es la IU de más alto nivel dentro del IU Deployment Descriptor (IUDD). El<br />
IUDD más simple sólo contiene un SIU dentro del rootIU.<br />
Además de estos tipos, también se describen mecanismos para hacer referencia a IUs<br />
que están en otro descriptor, o crear un descriptor ✭✭mayor✮✮ como agregado de varios<br />
root IUs. También se pueden describir algunos tipos más de relaciones y establece un<br />
mecanismo de comprobaciones (de versión, propiedades, etc.)<br />
3.8.4. Kadeploy<br />
Kadeploy [GLV + 06] es un sistema pensado para gestionar la configuración de un<br />
grid o cluster de computadores. Los nodos tienen siempre un sistema instalado (al que<br />
denominan entorno de referencia), y varias particiones en el disco duro previamente<br />
establecidas. Un entorno consiste en un archivador tar que contiene la imagen del<br />
sistema operativo y los programas que el usuario desea utilizar.<br />
Cuando un usuario quiere usar el grid con un entorno específico, indica en qué partición<br />
debe alojarse (esta decisión recae sobre el usuario) y Kadeploy realiza el despliegue<br />
y reinicia los nodos, que arrancarán esa partición. Una vez que termine de usar los<br />
equipos, éstos se vuelven a reiniciar, esta vez para arrancar el entorno de referencia.<br />
Dado que los usuarios deben conocer qué particiones hay y cuáles están disponibles,<br />
y Kadeploy no proporciona ninguna solución para automatizar la gestión de esta información,<br />
en entornos complejos esto puede llegar a ser problemático. Tampoco provee<br />
mecanismos para asignar entornos a nodos concretos, por lo que el hardware de todos<br />
los nodos del grid deben ser iguales.
32<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
Figura 3.8: Funcionamiento de Kadeploy2<br />
Sistema<br />
UDP Cast N/A N/A<br />
Zero Install Apps.<br />
FAI SO (1)<br />
System Imager SO (1)<br />
DRBL SO N/A<br />
LTSP<br />
Apps.<br />
SLIM<br />
SO<br />
Userful Multiplier N/A<br />
rootz Apps. N/A<br />
Kadeploy2 SO<br />
Unidad<br />
Arranque Remoto<br />
Libre<br />
Multiplataforma<br />
Desatendido<br />
Tabla 3.3: Comparativa de Sistemas
3.9. GESTIÓN <strong>DE</strong> RED 33<br />
3.9. Gestión de Red<br />
La gestión de red es un proceso necesario para asegurar la correcta operación de un<br />
sistema. Esta gestión debe ser transparente al usuario y estar integrada en el sistema. La<br />
naturaleza abierta de los sistemas distribuidos y las redes informáticas hace necesaria<br />
la existencia de arquitecturas de gestión estándares que faciliten su implementación.<br />
El sistema propuesto en este documento comparte algunos aspectos con los procesos<br />
de gestión de redes. Al ser un sistema complejo que manejará varias decenas de nodos,<br />
será necesario monitorizar el estado de cada uno, para saber qué está pasando en cada<br />
momento. Es crucial también comprobar que la información almacenada es correcta y<br />
completa, así como asegurar la robustez del sistema y su recuperación ante posibles<br />
fallos.<br />
Hay tres arquitecturas principales en la gestión de redes: el modelo Open System<br />
Interconnection (OSI), el modelo Telecommunications Management Network (TMN) y<br />
el modelo Simple Network Management Protocol (SNMP) o internet.<br />
La arquitectura OSI divide la gestión de red en cinco áreas funcionales:<br />
Configuración Abarca la descripción del sistema (qué equipos hay, topología de la<br />
red) y la configuración del mismo, manipulando los parámetros que controlan<br />
su funcionamiento. También se encarga de instalar nuevo software o retocar el<br />
existente y añadir nuevos dispositivos.<br />
Fallos Se encarga de detectar, aislar y eliminar los fallos que aparezcan. Para ello<br />
necesita de mecanismos para monitorizar la red y el sistema, para diagnosticar<br />
el fallo, para solucionarlo y para informar del mismo.<br />
Prestaciones Continua las tareas de la gestión de fallos, para garantizar la calidad<br />
de servicio en el futuro, comprobando los parámetros que miden la calidad del<br />
servicio<br />
Usuarios Se concentra en identificar, autenticar y monitorizar a los usuarios, para<br />
generar estadísticas de uso y asignar recursos a las cuentas.<br />
Seguridad Se trata de proteger los recursos (información, servicios, infraestructuras)<br />
de ataques externos o de un uso inadecuado. Para ello se definen políticas de uso
34<br />
CAPÍTULO 3. ESTADO <strong>DE</strong>L ARTE<br />
y acceso, se verifica la integridad de los datos, se monitoriza y notifica el estado<br />
del sistema y las violaciones de la política...<br />
El modelo TMN se basa en la arquitectura OSI adaptándolo al sector de las telecomunicaciones.<br />
La principal diferencia es que posee una red exclusiva dedicada a la<br />
gestión, aparte de la red gestionada.<br />
El modelo SNMP utiliza una arquitectura gestor-agente junto con una base de datos<br />
(Management Information Base (MIB)) en la que se representa la información de los<br />
elementos gestionados. Se basa en dos conceptos fundamentales: el objeto utilizado para<br />
representar un recurso concreto debe ser igual en cualquier sistema (es una variable de<br />
la MIB); y debe usarse un esquema común de representación, conocido como Structure<br />
of Management Information (SMI).<br />
3.10. Conclusiones<br />
Como se ha podido observar, existen numerosas herramientas que ofrecen funcionalidades<br />
de clonado de discos y distribución de aplicaciones. Sin embargo, no son<br />
adecuadas para los objetivos que se persiguen. Clonar discos supondría tener el disco<br />
duro del ordenador principal configurado como se quiera que se configuren los ordenadores<br />
de los laboratorios, pero esto implicaría que todos tendrían que ser exactamente<br />
iguales (mismos componentes, mismos periféricos, mismas particiones). Sin embargo, lo<br />
normal es que, a medida que se va renovando el ✭✭parque informático✮✮ de cualquier organización,<br />
los ordenadores cuenten con distintos modelos de procesadores, de tarjetas<br />
gráficas y de red, distintos discos duros, etc.<br />
Otra característica común es que la mayoría de ellas hacen copias enteras: si sólo se<br />
pretende instalar una nueva aplicación habría que volver a clonar todo el disco duro,<br />
lo cual no es óptimo.<br />
Las herramientas de despliegue de aplicaciones no son suficientes para copiar un<br />
sistema operativo completo, con toda su configuración; y por otro lado, las aplicaciones<br />
de grids se centran en la configuración y la gestión del conjunto de ordenadores, y en la<br />
mayoría de los casos son soluciones creadas a medida para el grid en el que se utilizan.
3.10. CONCLUSIONES 35<br />
Tampoco hay una aplicación que permita planificar el uso que se pretende hacer de<br />
los nodos y los SSOO.
4<br />
Método de Trabajo y Herramientas<br />
En este capítulo...<br />
Contenidos<br />
4.1. Método de Trabajo . . . . . . . . . . . . . . 37<br />
4.2. Herramientas . . . . . . . . . . . . . . . . . . 39<br />
Seguidamente, se explicará el método de trabajo que ha guiado la elaboración del<br />
proyecto, así como una lista de las herramientas utilizadas y una breve descripción<br />
de cada una.<br />
4.1. Método de Trabajo<br />
El sistema fue concebido desde un principio para ser construido como un sistema distribuido,<br />
lo que permitía la creación de componentes independientes que funcionarían<br />
por separado, aunque no tendrían utilidad práctica individualmente.
38<br />
CAPÍTULO 4. MÉTODO <strong>DE</strong> TRABAJO Y HERRAMIENTAS<br />
Figura 4.1: Desarrollo Incremental<br />
Los requisitos del sistema estaban claros desde el inicio, por lo que se pudo diseñar<br />
la arquitectura del sistema casi completamente desde las primeras etapas del proyecto.<br />
Dado que se pretende construir un sistema cómodo para el usuario, la interacción<br />
con el mismo era de suma importancia para obtener realimentación sobre el correcto<br />
desarrollo del proyecto.<br />
Estas razones nos llevaron a elegir una metodología de prototipado incremental,<br />
ya que nos permitía tener prototipos funcionales de los distintos componentes desde las<br />
primeras fases para, una vez acabados, ir ensamblándolos y para montar el sistema final.<br />
Además, la funcionalidad del núcleo principal puede conseguirse en una fase temprana<br />
del desarrollo.<br />
En esta metodología, se identifican a grandes rasgos los servicios que ofrecerá el<br />
sistema. Después, se definen incrementos, cada uno de los cuales proporcionará una<br />
porción de la funcionalidad del sistema. Una vez identificados los incrementos, los requisitos<br />
del primero de ellos se describen más detalladamente, y se desarrolla. Después,<br />
se integra con el sistema y el cliente puede empezar a usarlo. Es entonces cuando se<br />
empiezan a concretar los requisitos del siguiente incremento. Este proceso tiene varias<br />
ventajas: [Som04]<br />
Los clientes no tienen que esperar a que el sistema esté completo para poder<br />
empezar a utilizarlo.<br />
Los incrementos iniciales pueden usarse como prototipo, y obtener experiencia<br />
para la hora de definir los requisitos de los incrementos posteriores.<br />
Existe bajo riesgo de fallo total del proyecto, aunque se pueden encontrar problemas<br />
en algunos incrementos.
4.2. HERRAMIENTAS 39<br />
Los incrementos más importantes se entregan al principio, por lo que son, inevitablemente,<br />
los que se someten a más pruebas.<br />
4.2. Herramientas<br />
4.2.1. Lenguajes de Programación<br />
Python - Lenguaje de programación interpretado, multiparadigma y orientado a objetos,<br />
creado por Guido van Roosum. Se escogió por su flexibilidad y la facilidad<br />
que ofrece para crear prototipos rápidamente.<br />
C++ - Lenguaje compilado y orientado a objetos, creado por Bjarne Stroustrup. Se<br />
utilizó para las tareas que necesitaban ser ejecutadas con mayor eficiencia, bien<br />
por restricciones de tiempo o de recursos.<br />
bash - Uno de los múltiples intérpretes de comandos de los sistemas UNIX. Se crearon<br />
algunos scripts bash para automatizar tareas en los nodos y en la preparación de<br />
imágenes.<br />
4.2.2. Desarrollo<br />
ZeroC Ice - Internet Communications Engine (Ice) [HS09] es un middleware de comunicaciones<br />
orientado a objetos, de propósito general y que permite construir<br />
aplicaciones distribuidas con poco esfuerzo, desarrollada por la empresa ZeroC. 1<br />
De los servicios ofrecidos por Ice, se han utilizado en especial:<br />
IceGrid<br />
IcePatch2<br />
IceBox<br />
libparted - GNU Parted es un paquete industrial para crear, destruir, redimensionar,<br />
comprobar y copiar particiones y los sistemas de ficheros que contienen. Mediante<br />
esta librería se pudo obtener la información sobre los discos duros. [FSFb]<br />
1 http://www.zeroc.com/ice.html
40<br />
CAPÍTULO 4. MÉTODO <strong>DE</strong> TRABAJO Y HERRAMIENTAS<br />
pyunit - Librería estándar de facto para pruebas unitarias (UNIT) en Python. Equivalente<br />
a JUnit para Java. [PYU]<br />
atheist - Framework para pruebas automáticas desarrollado en el grupo Arco.<br />
Debian - Distribución del sistema operativo GNU/Linux.<br />
GNU Make - Herramienta que controla la generación de ejecutables y otro código<br />
no-fuente a partir de los ficheros de código fuente de un programa. [SMS04]<br />
GCC - Compilador libre para C/C++ [Sta03]<br />
Subversion - Sistema de control de versiones (repositorio).<br />
GNU Emacs - Editor de textos extensible y personalizable [Sta07]. Utilizado para el<br />
desarrollo y la documentación.<br />
4.2.3. Aplicaciones<br />
PXE - Herramienta para arranque por red sin utilizar el disco duro. [Int99]<br />
dnsmasq - Servidor DHCP y relay de DNS. [Kel]<br />
ebtables - Puente ethernet y administrador de tablas de tramas. Su función es configurar,<br />
mantener y configurar las tablas de reglas para las tramas ethernet en el<br />
kernel Linux. [SFB]<br />
VirtualBox - Completo virtualizador de propósito general para hardware x86 [Sun].<br />
GRUB - Gestor de arranque que permite elegir qué sistema operativo arrancar de<br />
entre los que están instalados en el ordenador. [FSFa]<br />
4.2.4. Documentación<br />
Inkscape - Programa para la creación de gráficos vectoriales.<br />
Dia - Herramienta para la creación de diagramas UML.
4.2. HERRAMIENTAS 41<br />
L A TEX - Sistema de maquetado de textos orientado a la producción de documentos<br />
técnicos y científicos. Es el estándar de facto para la comunicación y publicación<br />
en la comunidad científica.
5<br />
Desarrollo<br />
En este capítulo...<br />
Contenidos<br />
5.1. Especificación de Requisitos . . . . . . . . . 44<br />
5.2. Casos de Uso . . . . . . . . . . . . . . . . . . 46<br />
5.3. Diseño . . . . . . . . . . . . . . . . . . . . . . 50<br />
5.4. Entorno de Desarrollo y Pruebas . . . . . . 51<br />
5.5. Incrementos . . . . . . . . . . . . . . . . . . . 62<br />
5.6. Bridge ethernet y servidor DHCP/PXE . . 75<br />
5.7. Tamaño del proyecto . . . . . . . . . . . . . 76<br />
Este capítulo describe el proceso de desarrollo del proyecto, desde la especificación<br />
de requisitos al diseño de los distintos componentes. Se detalla también el entorno<br />
en el que se ha desarrollado el proyecto, así como el plan de pruebas y algunos detalles<br />
de implementación que tuvieron que añadirse por cuestiones arquitecturales.
44<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
5.1. Especificación de Requisitos<br />
Partiendo del análisis realizado a los objetivos del proyecto, descritos en el capítulo<br />
2, se definieron los siguientes requisitos funcionales:<br />
Elegir SO En los ordenadores deben quedar instalados varios sistemas operativos. Se<br />
debe poder elegir cuál de ellos se desea arrancar.<br />
Uso de los SSOO Una vez elegido el sistema operativo, éste deberá ejecutarse de<br />
forma nativa, y ser completamente funcional.<br />
Instalar aplicación Debe ser posible instalar nuevas aplicaciones en los SSOO añadidos<br />
al sistema. Cuando se pretenda instalar una aplicación nueva para ser usada<br />
en las aulas, ésta se instalará en la imagen existente en el servidor principal.<br />
Posteriormente será necesario actualizar los hosts que vayan a utilizarla.<br />
Actualizar SO Realizar cambios sustanciales en el sistema operativo. De la misma<br />
forma que se instala una nueva aplicación, debe ser posible poner al día el sistema<br />
operativo con actualizaciones de seguridad, parches, nuevas versiones del kernel,<br />
etc.<br />
Restaurar PC Si la configuración o los datos de algún PC se corrompen, es necesario<br />
llevarlo de nuevo a un estado inicial conocido. La restauración consistirá básicamente<br />
en volver a instalar la imagen que se ha estropeado.<br />
Instalación de SSOO Instalar sistemas operativos en los ordenadores. HYDRA instalará<br />
los sistemas operativos que se descargue del servidor central. Primero deberá<br />
crear las particiones necesarias.<br />
Se prevé un conflicto relativo a la configuración del SO:<br />
diferentes configuraciones para diferente hardware.<br />
drivers de la tarjeta gráfica.<br />
Discos Duros I<strong>DE</strong>/SATA (hda/sda).<br />
Nombres de host: cada ordenador debe tener su propio nombre de host,<br />
creado de forma automática y sin que se repita en la red. Además, es deseable<br />
que dicho nombre sea el mismo independientemente de la imagen que se haya<br />
arrancado.
5.1.<br />
ESPECIFICACIÓN <strong>DE</strong> REQUISITOS 45<br />
Despliegues Especificación de qué imágenes tendrá cada nodo. Los usuarios deben<br />
poder elegir:<br />
en qué nodos quieren instalar cada imagen (ya que no todas las imágenes<br />
son necesarias en todos los nodos)<br />
qué días de la semana debe instalarse (no es necesario que cada imagen<br />
esté disponible todos los días)<br />
Se construirá un horario con las imágenes que hacen falta en cada nodo cada día.<br />
El sistema será capaz de interpretarlo y aprovechar los periodos de inactividad<br />
para instalar las imágenes correspondientes.<br />
Recabar información Obtener información sobre los ordenadores de forma remota.<br />
Debe ser posible recabar información sobre el hardware de los nodos, para poder<br />
tomar decisiones sobre qué controladores o software específico necesitan.<br />
Particionar HDD Particionar el disco duro para alojar los distintos sistemas operativos.<br />
El sistema debe particionar de forma adecuada el disco duro de la máquina,<br />
para poder instalar los sistemas operativos necesarios.<br />
Con estos requisitos podemos describir a grandes rasgos la manera en que funcionará<br />
el sistema: un usuario crea una imagen del sistema operativo que quiere instalar<br />
en los nodos, la sube al servidor de HYDRA y la añade al sistema (copiar los ficheros<br />
al servidor e indicar al sistema la existencia de una nueva imagen son conceptos y procesos<br />
distintos). El usuario indica también en qué ordenadores y qué días de la semana<br />
quiere que esté disponible.<br />
El sistema debe tener alguna forma de iniciar la instalación periódicamente, momento<br />
en el que calcula qué imágenes deben ser copiadas en cada nodo; después se<br />
inicia la instalación. Los nodos que deban modificarse son despertados mediante WoL<br />
y se les transmiten los ficheros. Una vez terminada la instalación, se apagan, quedando<br />
listos para su uso normal. Cuando un usuario inicie un nodo, se le presentará un<br />
menú para que escoja qué SO desea utilizar.<br />
En este momento se identificaron también algunos conceptos que se van a utilizar<br />
para el desarrollo del proyecto. Estos conceptos son:
46<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Imágenes Una imagen es un contenedor que alberga un sistema operativo completo<br />
en su interior. Actualmente, las imágenes de HYDRA pueden ser ficheros de<br />
VirtualBox (extensión .vdi) creados de forma estática (ver sección A.1 en la<br />
página 104) o bien un directorio que contiene los ficheros del SO.<br />
Despliegue Un despliegue es un conjunto de datos que representa la configuración<br />
que especifica un usuario. Cada despliegue indica:<br />
qué imágenes instalar<br />
en qué nodos instalarlas<br />
cuándo deben estar disponibles<br />
Restricciones Las restricciones permiten a los usuarios filtrar de manera automática<br />
los nodos en los que instalar las imágenes. Por ejemplo, un usuario podría desear<br />
instalar una imagen sólo en aquellos nodos cuya memoria RAM sea mayor de<br />
cierta cantidad. Para ello, deben indicar 3 parámetros:<br />
Propiedad La propiedad que desean utilizar como criterio.<br />
Operador El operador de comparación (, =)<br />
Valor El valor de referencia para la comparación (cantidad de memoria, nombre<br />
del fabricante, etc.)<br />
En cuanto a los usuarios, pueden desempeñar dos roles: el de Gestor, que serán los<br />
usuarios habituales del sistema; y el de Administrador. Los administradores no utilizan<br />
el sistema como tal, si no que se encargan de instalarlo y realizar algunas tareas de<br />
mantenimiento cuando sea necesario.<br />
5.2. Casos de Uso<br />
El análisis de estos requisitos, nos llevó a identificar los casos de uso del sistema<br />
que se pueden ver en la figura 5.1, y que se describen a continuación:<br />
Añadir imagen Un usuario añade una imagen al sistema. La imagen ha sido copiada<br />
previamente a un directorio conocido del servidor central y el usuario indica al
5.2. CASOS <strong>DE</strong> USO 47<br />
Figura 5.1: Diagrama de Casos de Uso
48<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
sistema dónde se encuentra, con qué nombre quiere identificarla y el tipo de<br />
sistema de ficheros que contiene. Posteriormente, el sistema realizará las acciones<br />
necesarias para preparar la imagen para su despliegue e instalación en los nodos.<br />
Listar imágenes Un usuario desea obtener una lista con las imágenes que hay actualmente<br />
en el sistema, junto con las características de cada una.<br />
Actualizar imagen Un usuario necesita reemplazar una imagen existente en el sistema<br />
con otra. Para ello le indica al sistema qué imagen necesita actualizar y el<br />
fichero que contiene la nueva imagen.<br />
Borrar imagen Se desea eliminar una imagen del sistema.<br />
Crear despliegue Cuando un usuario desea que una o más imágenes (que hayan sido<br />
previamente añadidas al sistema) sean instaladas en los nodos, deberá crear un<br />
despliegue en el que almacenar dicha información.<br />
Listar despliegues Un usuario quiere obtener una lista con los despliegues que hay<br />
en el sistema, y consultar sus características.<br />
Modificar despliegue Se desea modificar la información de un despliegue para cambiar<br />
las imágenes que instala, o los nodos en los que las instala, o los días que el<br />
despliegue es ejecutado.<br />
Borrar despliegue Se borra un despliegue del sistema. No implica el borrado de las<br />
imágenes asociadas.<br />
Crear grupo La única forma unívoca de identificar a un nodo es mediante su dirección<br />
MAC. Dado que es un dato difícil de manejar por las personas, la creación de un<br />
grupo permite asignar un nombre a un conjunto de direcciones MAC, de forma<br />
que sea más fácil crear despliegues.<br />
Establecer delegado Permite especificar un Delegado para un nodo o un grupo de<br />
nodos. Los Delegados permiten jerarquizar el sistema para no saturar la red ni el<br />
Manager.<br />
Listar nodos El usuario pide una lista con los nodos registrados en el sistema.<br />
Restaurar nodo El funcionamiento de un nodo es defectuoso y es necesario volver a<br />
instalarlo, aunque el sistema lo considere como actualizado.
5.2. CASOS <strong>DE</strong> USO 49<br />
Figura 5.2: Diagrama de Casos de Uso para el Delegado y el Manager<br />
Instalar Iniciar la instalación de los nodos.<br />
También existen una serie de casos de uso en la interacción del Delegado y el<br />
Manager con los nodos, como muestra la figura 5.2.<br />
Despertar El Delegado envía un mensaje al nodo para encenderlo, a través de WoL.<br />
Obtener información El Manager utiliza el servidor HostInfo (ver secciones 6.4<br />
y 5.3) del nodo para recuperar la información sobre éste.<br />
Instalar El Manager le indica al nodo las imágenes que tiene que instalar y dónde<br />
puede encontrarlas (a qué Delegado pedírselas).<br />
Apagar Una vez concluida la instalación, el Manager indica al nodo que se apague.
50<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
5.3. Diseño<br />
Una vez analizados los requisitos del proyecto, se pasó a la fase de diseño, en la<br />
que se pasó a dar forma a la estructura básica del sistema y se definieron los distintos<br />
componentes y las interacciones entre ellos.<br />
En primer lugar es necesario definir la manera en que se va a interactuar con los<br />
nodos, ya que es necesario recabar información sobre su hardware y manipular su disco<br />
duro para instalar las imágenes. En un primer momento se pensó en crear una partición<br />
con un sistema mínimo, residente en cada nodo, que contuviera todas las herramientas<br />
necesarias. Esto representaba varios problemas, ya que a la hora de instalar habría que<br />
tener en cuenta esta partición, para no borrarla; además, si algún usuario la arrancara<br />
(por error o premeditadamente), podría tener consecuencias imprevistas. Por ello, se<br />
optó por un sistema de arranque remoto con PXE que no necesita disco duro, lo que<br />
permite además que el nodo quede completamente ✭✭limpio✮✮ después de la instalación.<br />
Una vez arrancado el nodo, hay que recoger información sobre él, poder particionar<br />
el disco duro, copiar ficheros, etc., para instalar los SSOO. Para ello se desarrollaron dos<br />
componentes independientes cuyas interioridades se explicarán en las secciones 6.4 HostInfo<br />
y 6.5 Installer. Estos componentes se implementaron como servicios Ice, de forma<br />
que pudieran ser invocados de forma remota e independiente.<br />
En un primer momento existió también un tercer componente, Partitioner, encargado<br />
de realizar tareas de creación de la tabla de particiones, crear las particiones<br />
propiamente dichas, y darles formato. Más tarde este componente fue empotrado en<br />
el Installer ya que el flujo de trabajo era siempre el mismo, de forma secuencial, y por<br />
tanto no tenía sentido contar con un componente aislado para estas tareas. HostInfo<br />
se mantuvo separado ya que podría ser interesante poder usarlo fuera del proceso de<br />
instalación.<br />
Los Delegados aparecieron como una medida preventiva: si un gran número de<br />
nodos iban a descargarse varias imágenes desde el Manager, la red podría saturarse,<br />
además de colapsar el Manager. Por eso se decidió crear el rol de Delegado, que sería<br />
un ordenador encargado de servir las imágenes a un subconjunto del total de nodos.<br />
Para poder controlar mejor el proceso, se optó por colocar también en el Delegado el<br />
servidor DHCP/PXE.
5.4. ENTORNO <strong>DE</strong> <strong>DE</strong>SARROLLO Y PRUEBAS 51<br />
Figura 5.3: Diagrama de Componentes<br />
5.3.1. Base de Datos<br />
La base de datos almacena todo tipo de información sobre el sistema, desde la<br />
configuración hardware de cada nodo hasta la planificación de las instalaciones, pasando<br />
por los grupos de nodos, las imágenes y los despliegues.<br />
Para averiguar las tablas y campos que harían falta, primero se trazó un diagrama de<br />
Entidad/Relación (E/R) (figura 5.4) para tener una idea general de dónde se encuentra<br />
cada dato y cómo se relaciona con los demás.<br />
El resultado es una base de datos muy sencilla, como muestra la figura 5.5, en la que<br />
se obtiene una tabla por cada entidad, más algunas tablas adicionales para representar<br />
las relaciones entre ellas. En el fichero tables-def.sql se puede ver la definición en<br />
SQL de la base de datos completa.<br />
5.4. Entorno de Desarrollo y Pruebas<br />
Para el desarrollo del proyecto era necesario poder simular de alguna manera el<br />
entorno en el que se pretende implantar el sistema, ya que no era posible utilizar un
52<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Figura 5.4: Diagrama E/R
5.4. ENTORNO <strong>DE</strong> <strong>DE</strong>SARROLLO Y PRUEBAS 53<br />
Figura 5.5: Esquema de la BBDD<br />
conjunto amplio de ordenadores para las pruebas. Se utilizaron dos formas distintas<br />
para ello.<br />
La primera y principal consistió en montar una red privada con un switch, en la que<br />
se conectaron varios ordenadores. Uno de ellos cumplía el papel de servidor principal<br />
(HYDRA Manager), y se encargaba de proporcionar el arranque por PXE y servir las<br />
imágenes. Un segundo ordenador desempeñaba el rol de Delegado (ver secciones 5.6<br />
y 6.3) mientras que el resto eran PCs que hacían las funciones de los nodos finales.<br />
La segunda manera de emulación consistía en utilizar máquinas virtuales, aunque su<br />
excesiva lentitud y enorme consumo de recursos hacían que se usaran sólo en contadas<br />
ocasiones.<br />
Todos los PCs, propiedad del grupo de investigación Arco, estaban equipados con<br />
un sistema operativo Debian GNU/Linux, a excepción de los “nodos”, que arrancaban<br />
la imagen especial de HYDRA (basada también en Debian).
54<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Figura 5.6: Diagrama de Clases
5.4. ENTORNO <strong>DE</strong> <strong>DE</strong>SARROLLO Y PRUEBAS 55<br />
5.4.1. Plan de Pruebas<br />
Durante el desarrollo del proyecto, se creó una batería de pruebas automáticas,<br />
basadas en PyUnit [PYU] para las pruebas de caja blanca y en Atheist [VMA] para las<br />
de caja negra, encargadas de comprobar que el funcionamiento del código es el correcto.<br />
Gracias a estas pruebas, es fácil comprobar toda la funcionalidad del proyecto de una<br />
manera rápida, lo que permite detectar fallos en poco tiempo y con gran precisión.<br />
Además, el testeo periódico del proyecto permite saber si los cambios que se han<br />
realizado desde la última ejecución de las pruebas han cambiado el comportamiento de<br />
lo que ya había, facilitando la tarea de integrar de nuevas funciones. A continuación se<br />
describe el plan de pruebas que se diseñó para el sistema.<br />
Añadir Imagen<br />
Precondiciones La imagen debe existir.<br />
Prueba La imagen se añade al sistema y queda a disposición de los clientes.<br />
Postcondiciones La imagen queda almacenada en el Manager y registrada en la<br />
BBDD.<br />
Tests Negativos<br />
Se especifica un fichero que no existe<br />
No se especifica un fichero de imagen<br />
No se indica nombre para la imagen<br />
No se indica el tipo de sistema de ficheros<br />
No se puede contactar con el Manager<br />
Añadir Despliegue<br />
Precondiciones Las imágenes del despliegue deben haber sido añadidas previamente<br />
al sistema.
56<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Prueba Se añade un despliegue al sistema, con nodos, restricciones, imágenes y días<br />
en los que debe instalarse.<br />
Postcondiciones Los nodos incluidos en él deben marcarse como ”sucios”<br />
El despliegue se ha añadido con los datos correctos.<br />
Tests Negativos<br />
No se indica nombre para el despliegue<br />
No se indica el calendario<br />
No se indican imágenes<br />
No se indican nodos<br />
Alguna MAC no es válida<br />
Algún día no es válido<br />
Alguna imagen no existe<br />
No se puede contactar con el Manager<br />
Crear <strong>Grupo</strong><br />
Precondiciones El grupo no existe<br />
Prueba Se agrupan varios nodos bajo un mismo nombre.<br />
Postcondiciones El grupo existe y todos los nodos especificados pertenecen a él.<br />
Tests Negativos<br />
No se indica nombre<br />
No se indican nodos<br />
No se puede contactar con el Manager<br />
Modificar Imagen<br />
Precondiciones<br />
La imagen antigua debe existir en el sistema.
5.4. ENTORNO <strong>DE</strong> <strong>DE</strong>SARROLLO Y PRUEBAS 57<br />
El fichero de la imagen nueva debe existir.<br />
Prueba Se actualiza una imagen con otra más reciente.<br />
Postcondiciones La imagen antigua contiene los ficheros de la imagen nueva.<br />
Tests Negativos<br />
No se puede contactar con el Manager<br />
Se indica un fichero que no existe<br />
La imagen antigua no existe<br />
No se indica imagen antigua<br />
No se indica imagen nueva<br />
Modificar Despliegue<br />
Precondiciones El despliegue debe existir en el sistema<br />
Prueba Cambiar algún parámetro de un despliegue; por ejemplo, ponerle una restricción<br />
más, o hacer que se instale en otros nodos.<br />
Postcondiciones El despliegue tiene los valores nuevos<br />
Tests Negativos<br />
No se puede contactar con el Manager<br />
Se especifica un despliegue que no existe<br />
No se indican imágenes<br />
No se indican nodos<br />
No se indica calendario<br />
Establecer Delegado<br />
Precondiciones Ninguna.<br />
Prueba Establecer un nodo como delegado de otros nodos.
58<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Postcondiciones El Delegado aparece como tal.<br />
Tests Negativos<br />
No se indican nodos<br />
No se indica delegado<br />
No se puede contactar con el Manager<br />
Restaurar Nodo<br />
Precondiciones El nodo debe aparecer como actualizado.<br />
Prueba Marcar un nodo para forzar que se reinstale.<br />
Postcondiciones El nodo debe aparecer como sucio.<br />
Tests Negativos<br />
No se puede contactar con el Manager<br />
No se indica nodo<br />
Añadir Restricción<br />
Precondiciones Ninguna.<br />
Prueba Añadir una restricción al sistema.<br />
Postcondiciones La restricción queda registrada en el sistema.<br />
Tests Negativos<br />
No se puede contactar con el Manager<br />
Falta la propiedad<br />
Falta la operación<br />
Falta el valor
5.4. ENTORNO <strong>DE</strong> <strong>DE</strong>SARROLLO Y PRUEBAS 59<br />
Borrar Imagen<br />
Precondiciones La imagen debe existir en el sistema<br />
Prueba Una imagen se elimina del sistema.<br />
Postcondiciones<br />
La imagen no está en el sistema<br />
Los despliegues que la contenían ya no lo hacen<br />
Tests Negativos<br />
La imagen no existe<br />
No se puede contactar con el Manager<br />
No se indica la imagen<br />
Borrar Despliegue<br />
Precondiciones El despliegue debe existir en el sistema.<br />
Prueba Se elimina un despliegue del sistema.<br />
Postcondiciones El despliegue no está en el sistema<br />
Tests Negativos<br />
No se puede contactar con el Manager<br />
No se especifica despliegue<br />
El despliegue indicado no existe<br />
Realizar Instalación<br />
Precondiciones La imagen debe existir en el sistema.<br />
Prueba Instalar una imagen en un nodo.<br />
Postcondiciones Todos los ficheros de la imagen deben estar también en el nodo.
60<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Obtener Información<br />
Precondiciones El nodo debe estar encendido y ejecutando un servidor HostInfo.<br />
Prueba Obtener información del nodo.<br />
Postcondiciones La información obtenida concuerda con la esperada.<br />
Obtener lista de nodos<br />
Precondiciones El Manager debe estar activo.<br />
Prueba Se pide al Manager la lista de los nodos.<br />
Postcondiciones La lista obtenida es la esperada.<br />
Montar una imagen<br />
Precondiciones El fichero de la imagen existe y no está ya montada.<br />
Prueba Se monta el fichero de imagen.<br />
Postcondiciones El fichero aparece en la lista de dispositivos montados del sistema<br />
operativo.<br />
Desmontar una imagen<br />
Precondiciones La imagen está montada.<br />
Prueba Se desmonta la imagen.<br />
Postcondiciones El fichero de la imagen no aparece en la lista de dispositivos montados<br />
del sistema operativo.
5.4. ENTORNO <strong>DE</strong> <strong>DE</strong>SARROLLO Y PRUEBAS 61<br />
Publicar una imagen<br />
Precondiciones La imagen no está publicada.<br />
Prueba Se publica la imagen.<br />
Postcondiciones En el Manager se ha creado un servidor IcePatch2 que sirve la<br />
imagen.<br />
Despublicar una imagen<br />
Precondiciones La imagen está publicada.<br />
Prueba Se despublica la imagen.<br />
Postcondiciones No existe ningún servidor IcePatch2 en el Manager que corresponda<br />
a la imagen.<br />
Borrar un nodo<br />
Precondiciones El nodo se encuentra registrado en el Manager.<br />
Prueba Se borra el nodo.<br />
Postcondiciones El nodo ya no se encuentra registrado en el Manager.<br />
Despertar nodo<br />
Precondiciones El Delegado está activo<br />
Prueba Se pide al Delegado que despierte un nodo<br />
Postcondiciones<br />
El Delegado ejecuta el comando wakeonlan correctamente.<br />
El nodo está activo y responde.
62<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
5.5. Incrementos<br />
Tal como se explicó en la sección 4.1, el desarrollo del proyecto está dividido en<br />
incrementos, que se detallan a continuación.<br />
5.5.1. Incremento 1: Información del Sistema<br />
Objetivos<br />
Obtener información de un ordenador<br />
Análisis<br />
Para poder actuar de forma remota sobre los ordenadores, eran necesarias algunas<br />
de herramientas que nos permitan realizar las acciones que deseemos. Se hace necesario<br />
poder obtener información de un PC en cuestión, por lo que habrá que desarrollar<br />
alguna herramienta que permita recabar datos sobre la configuración hardware del<br />
ordenador, el estado de los discos duros, etc.<br />
Implementación<br />
Para recabar información sobre los ordenadores se desarrolló la herramienta HostInfo.<br />
Dicha herramienta realiza un diagnóstico del ordenador en busca de la siguiente<br />
información:<br />
Procesador:<br />
Número de CPUs<br />
Velocidad de la CPU<br />
Arquitectura (Intel, Advanced Micro Devices (AMD), PowerPc...)<br />
Carga de trabajo
5.5. INCREMENTOS 63<br />
Memoria:<br />
Memoria RAM total del sistema<br />
Memoria RAM libre (y por inferencia, memoria usada)<br />
Red:<br />
Dirección IP<br />
Dirección ethernet (MAC)<br />
Disco Duro:<br />
Número de discos duros<br />
Particiones de cada disco<br />
Sistema de ficheros de cada partición<br />
Tamaño total de cada partición<br />
Tarjeta Gráfica:<br />
Fabricante (marca)<br />
Modelo<br />
Cantidad de memoria<br />
Información del Nodo:<br />
Nombre de host<br />
Sistema Operativo<br />
Versión del núcleo (kernel)<br />
HostInfo ofrece métodos para recabar estas informaciones por separado y se ejecuta<br />
como un servidor que queda a la espera que se produzcan dichas invocaciones. La<br />
interfaz del módulo HostInfo puede verse en el listado 5.1.<br />
Como puede apreciarse en el código, cada tipo de información puede solicitarse<br />
por separado, de forma que sólo se invocan las operaciones que hacen falta. Al ser un<br />
servicio que se incluirá en todos los nodos, también se añadieron con posterioridad las<br />
operaciones para apagar y reiniciar el nodo; se optó por añadirlas a este servidor por<br />
ser dos operaciones muy sencillas y considerar que no tenían entidad suficiente como<br />
para formar parte de un servidor propio.
64<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
#include <br />
module HYDRA {<br />
};<br />
interface HostInfo {<br />
MEMInfo getMEMInfo ();<br />
CPUInfo getCPUInfo ();<br />
GPUInfo getGPUInfo ();<br />
HDDInfoSeq getHDDInfo ();<br />
NICInfo getNETInfo ();<br />
NodeInfo getNodeInfo ();<br />
LoadInfo getLoadInfo ();<br />
void shutdown ();<br />
void reboot ();<br />
};<br />
Listado 5.1: Slice para HostInfo<br />
5.5.2. Incremento 2: Particiones<br />
Objetivos<br />
Crear tabla de particiones<br />
Crear particiones<br />
Formatear particiones<br />
Análisis<br />
Para instalar sistemas operativos completos es necesario poder realizar particiones<br />
en los discos duros y dar formato a las mismas con el sistema de ficheros adecuado,<br />
para poder alojar los sistemas operativos.<br />
Implementación<br />
Para esta tarea, se desarrolló el Partitioner, que permite realizar particiones de forma<br />
remota en un ordenador. En realidad, se trata de un front-end de la herramienta
5.5. INCREMENTOS 65<br />
/∗ −∗− mode : C++ −∗− ∗/<br />
# ifndef P A R T I T I O N E R I C E<br />
# define P A R T I T I O N E R I C E<br />
#include <br />
module HYDRA {<br />
interface Partitioner {<br />
int writePartitionList ( PartitionSeq partList , string device );<br />
int makePartition ( long start , long end , string filesystem ,<br />
string device );<br />
int createPartitionTable (string device );<br />
};<br />
};<br />
# endif<br />
Listado 5.2: Slice para Partitioner<br />
parted de GNU/Linux. Es decir, Partitioner recoge los datos de cómo se desea estructurar<br />
el disco (tipo de la tabla de particiones, formato y tamaño de cada partición. . . )<br />
y utiliza el programa parted para realizar las operaciones. El listado 5.2 muestra las<br />
operaciones que ofrece la herramienta.<br />
5.5.3. Incremento 3: Instalar imágenes<br />
Objetivos<br />
Copiar imágenes a particiones<br />
Instalar gestor de arranque<br />
Análisis<br />
Una vez que los discos están debidamente particionados y formateados hay que<br />
realizar la instalación propiamente dicha. Esto implica que hay que poner los medios<br />
necesarios para poder transmitir los ficheros hacia los ordenadores destino, y escribirlos<br />
en la partición que les corresponda.
66<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
#include <br />
module HYDRA {<br />
};<br />
interface Installer {<br />
int createDir (string path );<br />
int install (string serverEndpoints , string partition , string<br />
imageName );<br />
int installGrub (string directory , string device );<br />
int restoreImage (string directory , string imageName );<br />
int updateBootMenu (string mountPoint , string partition , stringSeq<br />
imagelist );<br />
};<br />
Listado 5.3: Slice para Installer<br />
Después, se debe proceder a la instalación de un gestor de arranque que permita<br />
elegir al inicio entre los distintos sistemas operativos instalados. Dicho gestor debe<br />
actualizarse cada vez que se instale un sistema nuevo o se elimine alguno existente.<br />
Implementación<br />
La instalación de las imágenes la lleva a cabo una tercera herramienta, Installer.<br />
Utilizando IcePatch como intermediario, el instalador obtiene del servidor (Ice-<br />
Patch2Server) los ficheros de cada imagen, y los coloca en la partición correspondiente.<br />
Cada sistema operativo ha tenido que ser preparado previamente para su transmisión<br />
(ver sección 6.2.3).<br />
La herramienta Installer es la encargada de colocar los ficheros en sus particiones<br />
correspondientes, así como de deshacer los cambios que se realizan en la preparación<br />
(sección 6.2.3). También se encarga de instalar y actualizar el gestor de arranque. La<br />
interfaz de Installer se muestra en el listado 5.3.
5.5. INCREMENTOS 67<br />
5.5.4. Incremento 4: Manager<br />
Objetivos<br />
Adición de imágenes<br />
Gestión de calendario<br />
Recuperación de nodos con fallos<br />
Análisis<br />
Una vez que se dispone de las herramientas básicas, se hace necesaria la implementación<br />
de una utilidad que permita el manejo de imágenes en el servidor, para poder<br />
añadirlas, indicar en qué ordenadores deben instalarse, etc.<br />
Debe ser posible indicar al sistema que un ordenador ha de ser reinstalado; es decir,<br />
forzar la reinstalación en un nodo aunque el sistema considere que está actualizado.<br />
Esto puede ser necesario en caso de que la integridad de los datos de un nodo se<br />
haya visto vulnerada (configuración corrupta, ficheros perdidos, etc.). Debe ser posible<br />
recuperar dicho ordenador de forma sencilla, mediante una simple reinstalación del<br />
software.<br />
También debe poder especificarse un calendario de utilización de los ordenadores.<br />
Cada usuario o administrador, al añadir su imagen, podrá indicar qué días necesita<br />
que esté instalada en los ordenadores, y en cuáles de ellos.<br />
Implementación<br />
Para poder instalar un nodo automáticamente, se utilizó el arranque por PXE, de<br />
forma que el ordenador pudiera arrancar pero no utilizase el disco duro. De esta forma,<br />
no interferiría con el proceso de instalación.<br />
En el nodo maestro de la red (el Registry en la terminología de Ice) se colocó la aplicación<br />
central del sistema HYDRA. Esta aplicación, llamada Manager, es la encargada
68<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
de recibir las peticiones de los usuarios (añadir/borrar imágenes, crear configuraciones,<br />
etc.) y coordina la instalación de las imágenes en los ordenadores.<br />
Cuando un equipo arranca por PXE, se le sirve un sistema operativo mínimo y<br />
especialmente configurado para HYDRA. Una vez que dicho sistema está en marcha,<br />
lanza un nodo de IceGrid que se registra en la red de HYDRA. Entre otras cosas, el<br />
Manager posee una serie de observadores 1 que le notifican automáticamente cuando<br />
un nodo se pone en marcha. Gracias a ellos, se da cuenta de que hay un nuevo nodo<br />
en el sistema e inicia en él el proceso de instalación. En primer lugar, coloca una<br />
instancia de las herramientas básicas (HostInfo, Partitioner e Installer) en el nodo. A<br />
continuación, mediante invocaciones remotas a la herramienta adecuada, crea una serie<br />
de particiones en el disco duro para, acto seguido, copiar cada imagen en una partición.<br />
Una vez copiadas todas las imágenes, instala el gestor de arranque en el nodo.<br />
El último paso es evitar que el ordenador arranque por PXE. Si no se realizara<br />
este paso, cuando un usuario encendiera el ordenador para usarlo, éste arrancaría por<br />
PXE e iniciaría de nuevo el proceso de instalación. Por lo tanto, una vez terminada<br />
la instalación es necesario cambiar la configuración del servidor DHCP que sirve el<br />
arranque PXE para que no responda a las peticiones que procedan de la dirección<br />
hardware (MAC) del ordenador que acaba de ser instalado.<br />
Restaurar Ordenador<br />
Restaurar un ordenador es un proceso muy sencillo teniendo en cuenta que ya<br />
disponemos de arranque por PXE. Aunque el sistema operativo del ordenador se halla<br />
corrompido y no funcione correctamente, la imagen que se le sirve por PXE sí lo hará.<br />
Por lo tanto, para restaurar un ordenador sólo es necesario marcarlo como “sucio”<br />
para asegurar que en la próxima actualización el ordenador arrancará por PXE y se<br />
instalarán las imágenes de nuevo, aunque en la base de datos figure como actualizado.<br />
Adición de imágenes y Gestión de Calendario<br />
Una vez que el usuario ha creado una imagen, debe añadirla al sistema para que<br />
éste pueda distribuirla a los ordenadores. El usuario indicará al Manager el fichero que<br />
contiene la imagen y los días de la semana que necesita que esté disponible. En ese<br />
1 Patrón de diseño “Observer” [GHJV95]
5.5. INCREMENTOS 69<br />
<br />
<br />
<br />
<br />
Monday<br />
AmpliacionSSOO . vdi<br />
SistemasDistribuidos . vdi<br />
<br />
<br />
Tuesday<br />
ingenieriaSW I . vdi<br />
AC ati . vdi<br />
AC nvidia . vdi<br />
<br />
<br />
Listado 5.4: hydra.xml<br />
momento, el Manager montará la imagen y realizará el proceso de preparación descrito<br />
en la sección 6.2.3.<br />
Para que la información relativa a las imágenes y su horario no se pierda entre<br />
distintas ejecuciones del programa, se creará un fichero XML donde se almacenarán<br />
los ficheros que contienen imágenes y su horario asociado. El listado 5.4 muestra un<br />
ejemplo real del fichero XML.<br />
5.5.5. Incremento 5: Delegados<br />
Objetivos<br />
Manager como servicio remoto<br />
Jerarquización de la instalación (Delegados)<br />
Análisis<br />
Una vez construido un prototipo completamente funcional, el siguiente paso consistió<br />
en convertir el Manager en un servicio remoto, para que los usuarios puedan
70<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
añadir las imágenes desde cualquier ordenador, sin necesidad de acceder físicamente al<br />
ordenador principal.<br />
Tener algunas decenas de clientes descargando imágenes de sistemas operativos enteros<br />
desde un único servidor puede suponer un colapso en la red. Es posible evitar esta<br />
saturación añadiendo nodos que sirvan como Delegados del Manager. El Delegado sólo<br />
necesita almacenar algunas imágenes (no todas, como el Manager, y sólo las servirá a<br />
unos cuantos ordenadores.<br />
Implementación<br />
Implementar el Manager como un servicio remoto implica la construcción de dos<br />
programas: uno que actuará como servidor (el Manager propiamente dicho) y otro que<br />
será el cliente que invocará peticiones al servidor. El tipo de peticiones que podrán<br />
solicitar los clientes está descrito en la interfaz existente entre ambos (listado 5.5).<br />
El Manager incorpora un objeto en su interior, llamado HydraCore, que le proporciona<br />
funciones auxiliares para realizar operaciones básicas, tales como montar y<br />
desmontar una imagen, realizar el icepatch2calc de una imagen en un hilo aparte,<br />
crear o borrar un servidor... De esta forma, tenemos separadas las funcionalidades que<br />
se le ofrecen al cliente (capa de presentación) de los detalles de implementación (capa<br />
de dominio), consiguiendo un menor acoplamiento entre los componentes del sistema.<br />
5.5.6. Incremento 6: Optimizaciones<br />
Objetivos<br />
Base de Datos<br />
Creación de la abstracción “despliegue”<br />
Uso de restricciones en los despliegues<br />
Creación de grupos de ordenadores<br />
Operaciones CRUD
5.5. INCREMENTOS 71<br />
# ifndef M A N A G E R I C E<br />
# define M A N A G E R I C E<br />
#include <br />
#include <br />
module HYDRA {<br />
interface Query {<br />
DeploymentSeq listDeployments ();<br />
Ice :: StringSeq listNodes (string order );<br />
OSimageSeq listImages ();<br />
DelegateSeq listDelegates ();<br />
Ice :: StringSeq listConstraints ();<br />
OSimage getImage (string imgname );<br />
Deployment getDeployment (int depid );<br />
HostDescription getHostInfo (string nodenane );<br />
Ice :: StringSeq getGroup (string name );<br />
void showConfig ();<br />
};<br />
interface Directory extends Query {<br />
int addDeployment ( Deployment dep ) throws ConflictException ,<br />
ObjectNotExistException ;<br />
int addImage ( OSimage img ) throws ConflictException ;<br />
int addConstraint (string prop , string oper , string value );<br />
void modifyDeployment (string oldname , Deployment dep )throws<br />
ObjectNotExistException ;<br />
void updateImage (string oldimage , string newimage ) throws<br />
ObjectNotExistException ;<br />
void deleteDeployment (string name ) throws<br />
ObjectNotExistException ;<br />
void deleteImage (string imgname ) throws<br />
ObjectNotExistException ;<br />
};<br />
};<br />
# endif<br />
void deleteConstraint (int constID ) throws<br />
ObjectNotExistException ;<br />
void setDelegate (string delegate , string group , Ice :: StringSeq<br />
maclist );<br />
void createNodeGroup (string name , Ice :: StringSeq maclist );<br />
Ice :: StringSeq getDirtyNodes (string delegate );<br />
Ice :: StringSeq getImagesForDelegate (string delegatename );<br />
int restoreNode (string macaddress );<br />
void startInstallation ();<br />
Listado 5.5: Slice para Manager
72<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Mejora de Installer<br />
Análisis<br />
Se decidió cambiar la forma de almacenar la configuración de las imágenes, nodos,<br />
despliegues, etc. en una base de datos en lugar de utilizar el formato XML. Una base<br />
de datos es más flexible, rápida y sencilla a la hora de almacenar, recuperar y buscar<br />
la información.<br />
Para simplificar un poco todo lo relacionado con la instalación, se define la abstracción<br />
despliegue, que representará la manera en que los usuarios describirán al sistema<br />
cómo quieren que se instalen las imágenes.<br />
También se añadirá la posibilidad de especificar ciertas restricciones en los despliegues,<br />
de forma que las imágenes de un despliegue sólo se instalarán en aquellos<br />
ordenadores que cumplan las restricciones (por ejemplo, que tengan una tarjeta gráfica<br />
de un determinado fabricante).<br />
Para simplificar al usuario la adición de despliegues, se podrán especificar grupos<br />
de ordenadores. Así, si un usuario va a utilizar siempre los mismos ordenadores, podría<br />
agruparlos bajo un identificador y luego utilizar dicho identificador en lugar de listar<br />
todos los ordenadores cada vez.<br />
Como en cualquier herramienta de gestión, es necesario disponer de operaciones<br />
Create Retrieve/Read Update Delete (CRUD) sobre los distintos tipos de datos: imágenes,<br />
despliegues, restricciones, calendario y grupos. Se dará soporte a dichas operaciones.<br />
Por otra parte, se observó que el proceso de instalación en un nodo sigue siempre<br />
los mismos pasos, y no necesita coordinarse con el Manager para nada. Por lo tanto,<br />
no es necesario que el Manager esté constantemente invocando operaciones sobre los<br />
distintos HostInfo, Partitioner e Installer: basta con pasar al Installer la configuración<br />
que debe tener el nodo, y él sólo puede realizar todo el proceso. Como resultado de<br />
esto, el módulo Partitioner desapareció, y su funcionalidad fue integrada en Installer.<br />
El listado 5.3 muestra la interfaz de Installer, en la que se aprecia la nueva simplicidad.
5.5. INCREMENTOS 73<br />
Implementación<br />
Despliegues<br />
No todas las imágenes deben instalarse en todos los nodos, ni van a ser usadas todos<br />
los días. La información sobre estas situaciones viene expresada como un despliegue.<br />
Un despliegue es una entidad abstracta que contiene información sobre:<br />
qué imágenes deben instalarse<br />
en qué nodos deben instalarse (incluyendo restricciones)<br />
qué días de la semana han de estar disponibles<br />
Base de Datos<br />
En este punto, se tomó la decisión de crear una base de datos en la que almacenar<br />
toda la información relativa al sistema (propiedades de los nodos, imágenes, calendario,<br />
etc.) en lugar de tenerla repartida en varios archivos. El fichero XML del calendario se<br />
eliminó, así como el que guardaba la información sobre las imágenes.<br />
Para crear la base de datos, primero se estudiaron las relaciones entre los distintos<br />
componentes del sistema, para tener una visión general de los flujos de información.<br />
Estas relaciones se describen en la figura 5.4.<br />
De este diagrama se pueden inferir las tablas que tendrá la base de datos. El esquema<br />
final de la BD queda representado en la figura 5.5.<br />
La tabla node almacena información sobre los nodos y sus propiedades. Cuando un<br />
nodo se registra en la red de HYDRA, se obtienen sus propiedades con HostInfo<br />
y se almacenan aquí. Como índice (clave primaria) de la tabla se ha utilizado la<br />
dirección MAC del nodo, por ser un valor único y además, vinculado al propio<br />
ordenador.<br />
La tabla image guarda las imágenes que se han añadido al sistema: su nombre, qué tipo<br />
de SO contienen y en qué fichero están.
74<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
La tabla constraint contiene las restricciones que se hayan definido en el sistema.<br />
Cada registro está formado por tres campos, que definen la restricción: el nombre<br />
de la propiedad, la operación que aplicarle y el valor de comparación.<br />
La tabla deployment guarda una lista de los despliegues añadidos al sistema. Al ser<br />
despliegue una entidad compuesta, la información de un despliegue completo no<br />
está recogida en esta tabla, sino en cuatro tablas más:<br />
La tabla imageset indica qué imágenes contiene cada despliegue.<br />
En la tabla nodeset se relaciona cada despliegue con el conjunto de nodos<br />
en los que debe instalarse.<br />
La tabla constraintset contiene las restricciones asociadas a cada despliegue.<br />
Por último, con la tabla calendar se indica qué días de la semana debe<br />
estar el despliegue instalado.<br />
La tabla configuration es la tabla clave del sistema. Se genera automáticamente<br />
cada vez que se inicia un ciclo de actualizaciones, a partir de la información<br />
almacenada en las demás tablas. En ella se describe explícitamente qué imagen<br />
debe instalarse en cada ordenador, una vez tenidos en cuenta el calendario y las<br />
restricciones.<br />
La tabla group<br />
indica los nodos que pertenecen a un grupo.<br />
La tabla delegate indica qué nodo actúa como delegado para otro nodo.<br />
Restricciones<br />
Las restricciones aportan gran flexibilidad a la hora de definir los despliegues. Por<br />
ejemplo, si hay dos modelos de tarjetas gráficas en los ordenadores de un mismo aula,<br />
cada uno de ellos necesita una imagen que contenga los drivers correspondientes. Si no<br />
se utilizara este mecanismo de restricciones, el usuario tendría que saber exactamente<br />
qué ordenadores tienen un modelo y cuáles el otro.<br />
Con las restricciones, se puede hacer que esta distinción sea automática. El usuario<br />
puede añadir un despliegue que instale la imagen InfGrafica ATI.vdi en los ordenadores<br />
cuya tarjeta gráfica sea marca ATI Technologies Inc. (ATI) (gfxVendor == ATI)
5.6. BRIDGE ETHERNET Y SERVIDOR DHCP/PXE 75<br />
y la imagen InfGrafica NV.vdi en aquellos cuya tarjeta sea nVidia (gfxVendor ==<br />
nVidia)<br />
<strong>Grupo</strong>s<br />
El uso de grupos fue una mejora incorporada por comodidad más que por funcionalidad.<br />
Permite unir varios nodos bajo un alias. De esta forma, no es necesario indicar<br />
una lista de 30 nodos cada vez que se desee realizar una operación sobre ellos; bastará<br />
con referirse al nombre del grupo. Esta funcionalidad está especialmente pensada<br />
para agrupar los nodos de un mismo recinto aunque, por supuesto, pueden agruparse<br />
bajo cualquier otro criterio.<br />
La información sobre qué nodos contiene un grupo está en una tabla de la base de<br />
datos, y a la hora de realizar operaciones sobre el grupo, éste será sustituido por la<br />
lista de nodos automáticamente.<br />
5.6. Bridge ethernet y servidor DHCP/PXE<br />
Para realizar la instalación, cada nodo debe arrancar por PXE una imagen especialmente<br />
preparada, que contiene las herramientas necesarias para comunicarse con el<br />
Manager de HYDRA y ejecutar la instalación. El caso ideal es que este servidor PXE<br />
se encuentre en el servidor DHCP central del organismo donde se implante HYDRA,<br />
aunque esto no siempre es posible. Por eso, cada Delegado puede actuar como servidor<br />
PXE para los nodos que supervisa. Esto puede tener graves consecuencias en el caso de<br />
que Manager y Delegados se encuentren en redes distintas (por motivos de seguridad,<br />
por ejemplo), como muestra la figura 5.7.<br />
Si éste es el caso, es probable que se quiera evitar la intromisión en la configuración<br />
de red existente. Los Delegados tienen un servidor DHCP para el arranque por PXE<br />
que puede configurarse para que otorgue direcciones de la red a la que pertenece el<br />
Delegado, sin interferir con el servidor principal. En este caso, el Delegado debe hacer<br />
de gateway para los nodos, por lo que tiene que ser también configurado para actuar<br />
como bridge ethernet, de forma que los nodos puedan acceder a la red pública.
76<br />
CAPÍTULO 5. <strong>DE</strong>SARROLLO<br />
Figura 5.7: Estructura de red de HYDRA<br />
5.7. Tamaño del proyecto<br />
El proyecto ha tenido una duración total de 27 meses, aunque no todos se han<br />
dedicado al desarrollo. Durante la primera fase, fue necesario estudiar y aprender a<br />
manejar las herramientas que se iban a emplear, y encontrar una configuración funcional<br />
para el entorno de desarrollo supuso un esfuerzo mayor del esperado.<br />
A modo de resumen, se exponen en esta sección algunos datos sobre el tamaño del<br />
proyecto en líneas de código (tabla 5.1), un gráfico con los lenguajes empleados en el<br />
desarrollo (figura 5.8) y una estimación del coste del proyecto basada en el modelo<br />
Cocomo (tabla 5.2).
5.7. TAMAÑO <strong>DE</strong>L PROYECTO 77<br />
Módulo Líneas de Código Lenguajes<br />
Manager 3.322 Python:3163<br />
bash:76<br />
SQL:72<br />
Makefile:11<br />
Pruebas 1.105 Python:1025<br />
C++:55<br />
Makefile:25<br />
Installer 622 C++:599<br />
Makefile:23<br />
HostInfo 605 C++:444<br />
ANSIC:134<br />
Makefile:27<br />
Interfaces Slice 188 Slice:188<br />
Tabla 5.1: Lineas de código por módulo<br />
C++<br />
1098 (18.31%)<br />
Slice 188 (3.13%)<br />
bash 160 (2.67%)<br />
ANSIC 134 (2.23%)<br />
Makefile 131 (2.18%)<br />
SQL 72 (1.20%)<br />
Python<br />
4215 (70.27%)<br />
Figura 5.8: Líneas por lenguaje de programación<br />
Costes del Proyecto<br />
Total de líneas físicas de código (SLOC) 5.810<br />
Esfuerzo de desarrollo en personas-año (personas-mes) 1’79 (21’53)<br />
(modelo de esfuerzo P ersonasMes = 3 · KSLOC 1,12 )<br />
Estimación de Calendario, en Años (Meses) 0’61 (7’32)<br />
(modelo de calendario Meses = 2,5 · P ersonasMes 0,35 )<br />
Número estimado de desarrolladores (Esfuerzo/Calendario) 2’94<br />
Coste Total Estimado de Desarrollo<br />
68.200 e<br />
(salario medio: 15.840 e/año)<br />
Tabla 5.2: Estimación de costes del proyecto (Generado usando sloccount, de David A.<br />
Wheeler)
6<br />
HYDRA<br />
En este capítulo...<br />
Contenidos<br />
6.1. Interfaces . . . . . . . . . . . . . . . . . . . . 80<br />
6.2. Manager . . . . . . . . . . . . . . . . . . . . . 80<br />
6.3. Delegados . . . . . . . . . . . . . . . . . . . . 84<br />
6.4. HostInfo . . . . . . . . . . . . . . . . . . . . . 85<br />
6.5. Installer . . . . . . . . . . . . . . . . . . . . . 86<br />
6.6. Hydra-admin . . . . . . . . . . . . . . . . . . 87<br />
Para comprender mejor la arquitectura del sistema, se explica a continuación el<br />
funcionamiento de cada uno de los elementos que componen el sistema HYDRA.
80<br />
CAPÍTULO 6. HYDRA<br />
Figura 6.1: Proceso de preparación de una Imagen<br />
6.1. Interfaces<br />
Todos los componentes fueron diseñados como parte de un sistema distribuido. Para<br />
que interactúen entre sí, se diseñó una serie de interfaces que definen la forma en que dos<br />
componentes concretos pueden intercambiar información. Para ello se utilizó el lenguaje<br />
Slice, proporcionado por la librería de Ice. Todas las interfaces pueden consultarse en<br />
el directorio slices/ del proyecto.<br />
Existe también un fichero que define las estructuras de datos comunes para todos<br />
los componentes (imágenes, despliegues, particiones,...)<br />
6.2. Manager<br />
El Manager es, junto con el instalador, el núcleo del sistema HYDRA. Una de sus<br />
principales funciones es procesar las peticiones que los usuarios realizan a través de la<br />
interfaz de administración, e interactuar con la base de datos.<br />
También se encarga de poner a punto los Delegados enviándoles las Imágenes que<br />
van a necesitar cuando éstos despierten a los nodos. El Manager es el único nodo que<br />
contiene todas las Imágenes del sistema. Cuando se inicia el proceso de instalación,<br />
cada Delegado recibirá únicamente las Imágenes que necesita servir a los nodos que<br />
están a su cargo.
6.2. MANAGER 81<br />
El Manager posee una serie de observadores que le informan sobre la actividad de<br />
los nodos, para poder coordinar el proceso de instalación. Cuando un nodo (sea del tipo<br />
que sea) se levanta, el Manager lo detecta y realiza determinadas acciones dependiendo<br />
del tipo del nodo, que viene determinado por los primeros caracteres de su nombre<br />
(pxe- para los nodos han arrancado en modo instalación, del- para los delegados). En<br />
todos los casos, contacta con el servidor HostInfo que hay en el nodo para obtener la<br />
información del nodo y almacenarla en la base de datos.<br />
Es también el responsable de montar y desmontar las Imágenes, crear o borrar<br />
servidores, preparar las Imágenes, guardar y recuperar información de la base de datos...<br />
En definitiva, es el coordinador de todos los procesos que se realizan en HYDRA.<br />
El proceso de montar y desmontar las Imágenes hace referencia a la incorporación<br />
de la Imagen en el sistema de ficheros principal del Manager. Esto es necesario para la<br />
preparación de la Imagen y su distribución, como se verá más adelante.<br />
La creación de servidores es parte imprescindible de la distribución de Imágenes. Al<br />
terminar de preparar una Imagen, se crea un servidor que se encarga específicamente<br />
de servir los ficheros de esa Imagen en particular.<br />
6.2.1. La red IceGrid<br />
Para crear la red de HYDRA se utilizó el servicio IceGrid, que proporciona facilidades<br />
para crear y gestionar de forma sencilla un grid de nodos. La estructura de<br />
IceGrid está formada por un nodo principal, llamado Registry, y una serie de nodos.<br />
Juntos, el Registry y los nodos cooperan para manejar la información y los procesos<br />
que conforman las aplicaciones. Cada aplicación asigna una serie de servidores a unos<br />
nodos. En la red HYDRA, el Manager es el nodo que hace las funciones de Registry.<br />
El Registry mantiene un registro persistente de esta información, mientras que<br />
los nodos se encargan de ejecutar y monitorizar los servidores que se les han asignado<br />
[HS09]. Es posible utilizar técnicas de replicación en el Registry en el caso de<br />
necesitar tolerancia a fallos. 1 En el Registry se coloca también el servicio de localización<br />
de Ice, que permite localizar servicios en distintos servidores dentro de la red<br />
HYDRA<br />
1 Puede verse un vídeo de demostración en http://arco.esi.uclm.es/es/dobs
82<br />
CAPÍTULO 6. HYDRA<br />
6.2.2. Agente de Base de Datos<br />
Para interactuar con la base de datos, se incorporó al Manager un agente que<br />
se encarga de hacer que dichas operaciones sean transparentes. Es decir, el Manager<br />
no ejecuta sentencias SQL, si no que invoca operaciones para almacenar Despliegues,<br />
obtener Imágenes, etc. Si en un futuro cambiase el modelo de la base de datos, o se<br />
utilizara otra forma de almacenamiento de la información, tan sólo el agente se vería<br />
afectado. Sólo habría que programar un nuevo agente que fuera capaz de manejar el<br />
nuevo modelo de persistencia.<br />
6.2.3. Preparación de imágenes<br />
Una de las tareas más importantes que realiza el Manager es la preparación de<br />
las Imágenes para su distribución. La herramienta utilizada para el despliegue de las<br />
Imágenes es IcePatch2, que es un servicio del middleware Ice. IcePatch2 permite ahorrar<br />
ancho de banda de dos maneras: en primer lugar, no transmite los ficheros tal cual los<br />
encuentra, sino que los comprime antes con bzip. Por otra parte, una vez comprimido<br />
cada fichero, calcula el código MD5 [Riv92] correspondiente a cada uno, y almacena<br />
esta información en un fichero de texto, llamado IcePatch2.sum. Ambas operaciones<br />
las realiza el comando icepatch2calc.<br />
Una vez hecho esto, se utiliza icepatch2server para crear un servidor al que conectarse<br />
para descargar los ficheros. Cuando un cliente se conecta al servidor (mediante<br />
icepatch2client), descarga los ficheros comprimidos y el fichero .sum, que le servirá en<br />
primera instancia para detectar errores en la transmisión. Si todo ha ido bien, descomprimirá<br />
los ficheros y borrará los comprimidos.<br />
El fichero .sum tiene una segunda finalidad, y es que permite detectar cambios.<br />
Cuando alguien actualice la Imagen almacenada en el servidor, es de suponer que<br />
dicha actualización no afectará a todos los ficheros (aunque podría ser así, no es lo<br />
habitual). El uso del fichero .sum permite saber qué ficheros han cambiado o han sido<br />
añadidos o eliminados, y transmitir únicamente dichos cambios.
6.2. MANAGER 83<br />
La idea, por tanto, es realizar la preparación con icepatch2calc en la Imagen y<br />
dejarla lista para su distribución. Sin embargo, el empleo de IcePatch2 tiene algunos<br />
inconvenientes que hubo que resolver.<br />
El primero de ellos se debe a los enlaces simbólicos. icepatch2calc no trata los enlaces<br />
como ficheros normales, sino que los sigue, accediendo al fichero al que apuntan en lugar<br />
de al propio enlace. Esto hace que no los añada a la lista de ficheros a transmitir, lo<br />
que deja muchos enlaces importantes (como por ejemplo, los que indican qué núcleo<br />
debe arrancarse) sin distribuir, haciendo que el sistema quede inutilizable. También<br />
nos tropezamos con los enlaces a ficheros especiales y ficheros de dispositivo, lo que<br />
hacía por ejemplo que icepatch2calc intentara añadir el contenido de un CD o de los<br />
dispositivos stdin, stdout y stderr, entre otros.<br />
Para evitar esto, es necesario añadir un paso previo en el que todos los enlaces<br />
simbólicos se almacenan en un fichero comprimido y después se borran. El fichero<br />
comprimido será el que se distribuya hacia los ordenadores clientes y luego será el<br />
instalador quien se ocupe de restaurarlos en el lugar que les corresponda.<br />
El segundo inconveniente implica a los permisos y los propietarios de los ficheros. Al<br />
descomprimir los ficheros, todos pertenecen al usuario que esté ejecutando el proceso<br />
icepatch2client, ya que es el que los está creando en ese momento. Esto es grave, porque<br />
impide por ejemplo que los usuarios puedan acceder a sus propios ficheros, incluidos<br />
los usuarios del sistema 2 . Además, algunos permisos como el bit sticky, el bit SUID y<br />
el bit SGID han de ser restaurados de forma especial.<br />
Por ello, fue necesario utilizar una aplicación auxiliar llamada metastore que almacenara<br />
la información sobre los permisos, el propietario y el grupo de cada archivo<br />
en un fichero. Este fichero, llamado permissions.hydra, se almacena junto al fichero<br />
IcePatch2.sum y se distribuye con la Imagen. El instalador, explicado en la sección 6.5,<br />
será el que invoque durante la instalación a la función complementaria de metastore 3 ,<br />
que se encargará de restaurar los permisos originales de cada fichero.<br />
Una vez hecho esto, ya se puede llamar a icepatch2calc de forma que prepare el<br />
sistema para su despliegue. El proceso completo puede observarse en la figura 6.1.<br />
2 Usuarios que representan servicios del sistema<br />
3 http://david.hardeman.nu/software.php
84<br />
CAPÍTULO 6. HYDRA<br />
1. Los usuarios suben las Imágenes al<br />
Manager, para que las prepare, y<br />
crean la configuración que necesitan<br />
(Despliegues).<br />
2. Se invoca la orden de iniciar la instalación.<br />
3. Los Delegados se descargan la configuración<br />
y las Imágenes (si procede)<br />
desde el Manager.<br />
4. El Delegado despierta a los nodos, y<br />
les sirve las Imágenes.<br />
Figura 6.2: Flujo de trabajo en HYDRA<br />
6.2.4. Generación de la Configuración<br />
Una de las primeras acciones que realiza el Manager cuando se da la orden de iniciar<br />
la instalación es generar la configuración de las Imágenes que deben ir en cada nodo.<br />
En la base de datos, esta información está almacenada en forma de Despliegues: cada<br />
despliegue indica una serie de imágenes que deben instalarse en unos nodos concretos<br />
y en unos días concretos. Por supuesto es posible que varios Despliegues indiquen<br />
Imágenes para los mismos nodos y los mismos días. Por eso, el Manager consulta toda<br />
la información de la base de datos y calcula qué Imágenes necesitará cada nodo en ese<br />
día.<br />
6.3. Delegados<br />
Los Delegados son los encargados de distribuir las Imágenes a los nodos que supervisan.<br />
De esta manera se consigue una estructura jerárquica, para aumentar la<br />
escalabilidad del sistema a medida que aumente el número de nodos. El SO de los<br />
Delegados puede instalarse como una Imagen más de HYDRA, pudiendo incluso crear<br />
varios niveles de Delegados y Nodos en caso de que fuera necesario.
6.4. HOSTINFO 85<br />
Cuando se inicia el proceso de instalación, los Delegados se descargan o actualizan<br />
desde el Manager las Imágenes que necesitan para sus nodos. Esta parte requirió una<br />
pequeña modificación de la librería IcePatch, ya que cuando se realiza un parcheo,<br />
los archivos comprimidos se borran. Dado que se pretende retransmitir los ficheros<br />
descargados en el Delegado hacia los Nodos, fue necesario añadir una opción extra al<br />
comando icepatch2client para que mantuviera los ficheros comprimidos al terminar<br />
la distribución.<br />
Una vez obtenidas, los Delegados despiertan a los nodos mediante WoL, y se encargan<br />
de distribuirles las Imágenes. Cuando un nodo termina su instalación con éxito, el<br />
Delegado evita que arranque por PXE la próxima vez. De esta forma, arrancará desde<br />
el disco duro, con alguno de los SSOO que se le acaban de instalar. La figura 6.2<br />
muestra un esquema de este proceso.<br />
En los Delegados también está toda la estructura necesaria para el arranque por<br />
PXE, el servidor DHCP, etc., tal como se vio en la sección 5.6.<br />
6.4. HostInfo<br />
El módulo HostInfo permite al Manager obtener información acerca de los nodos.<br />
Se ejecuta en el nodo y recaba información sobre el disco duro, las particiones, el<br />
hardware, el sistema operativo, etc. Dicha información se envía al Manager, para que<br />
conozca el estado de los nodos, y así poder decidir qué acciones deben realizarse sobre<br />
la máquina.<br />
HostInfo se ejecuta al inicio del arranque por PXE, de forma que la información<br />
recogida sobre el nodo esté siempre actualizada en caso de que el hardware del nodo<br />
cambie. El listado 5.1 muestra la interfaz del módulo escrita en Slice, donde se puede<br />
ver la información que recaba y las operaciones que se pueden invocar sobre él.<br />
La forma de obtener la información es muy variada. El sistema operativo que ejecutan<br />
los nodos y en el que se ejecuta el HostInfo es un GNU/Linux mínimo, así que se<br />
puede obtener gran parte de la misma con comandos del sistema. Así, con la salida de los<br />
comandos ifconfig, uptime, uname y lspci obtenemos los datos correspondientes a<br />
tarjetas de red, carga de trabajo, sistema operativo y tarjeta gráfica, respectivamente.
86<br />
CAPÍTULO 6. HYDRA<br />
Figura 6.3: Diagrama de Componentes<br />
La información acerca del procesador y la memoria puede consultarse directamente en<br />
los ficheros que el sistema operativo crea a tal efecto en el directorio /proc. Por último,<br />
para saber cuántos discos duros hay en el sistema y qué particiones tiene cada uno se<br />
utilizó la librería libparted.<br />
En una revisión posterior se le añadieron dos funciones adicionales para poder<br />
apagar y reiniciar el nodo remotamente. A pesar de que la semántica de dichas funciones<br />
no cae en el contexto del servicio HostInfo, se decidió ubicarlas aquí por varias razones:<br />
en primer lugar, HostInfo es el único servicio que va a ser instalado en todos los nodos<br />
que se conecten a la red HYDRA independientemente de su rol (Manager, Delegado,<br />
Nodo...), de forma que así podrían controlarse todos los nodos. Por otro lado, son dos<br />
funciones tan simples que se consideró que no tenían relevancia suficiente para alojarlas<br />
en un sirviente propio.<br />
6.5. Installer<br />
El módulo de instalación se encarga de instalar las Imágenes y configurar los nodos.<br />
Recibe una estructura que describe la configuración que debe tener el nodo, incluyendo<br />
particiones, imágenes, etc. (ver listado 6.1). Esta estructura consiste en una lista de<br />
particiones, otra lista con los nombres de las imágenes que va a instalar y el delegado<br />
al que debe pedirle las imágenes.
6.6. HYDRA-ADMIN 87<br />
struct Partition {<br />
string name ; // /dev/hda1<br />
long size ;<br />
// in kB<br />
long free ;<br />
// in kB<br />
string mountPoint ;<br />
string fs; // vfat, etx3<br />
};<br />
sequence PartitionSeq ;<br />
struct NodeSetup {<br />
PartitionSeq partitions ;<br />
string delegate ;<br />
Ice :: StringSeq imgnames ;<br />
};<br />
Listado 6.1: Configuración de Nodo<br />
Una vez que tiene la información necesaria, escribe una nueva tabla de particiones<br />
(lo cual borra el particionado anterior) y crea las nuevas particiones. Después, comienza<br />
a copiar las imágenes de los sistemas operativos en las particiones, en el mismo orden<br />
en el que se especificaron. Para ello, monta la partición correspondiente y se pone<br />
en contacto con el delegado para pedirle los ficheros. Al terminar de transferir una<br />
imagen, hay que desempaquetar los enlaces simbólicos que se archivaron en el proceso<br />
de preparación de la imagen y restaurar los permisos y los propietarios de cada fichero<br />
(ver sección 6.2.3).<br />
Cuando el proceso termina, instala un gestor de arranque (GRUB), que permitirá al<br />
usuario escoger cuál de ellas arrancar. El menú del GRUB está configurado para que<br />
muestre los nombres de las imágenes, de forma que sea fácil identificar cuál de ellas se<br />
quiere arrancar (figura 6.5).<br />
6.6. Hydra-admin<br />
Hydra-admin es la aplicación que los usuarios utilizarán para comunicarse con el<br />
Manager y realizar operaciones sobre la configuración del sistema. Permite la administración<br />
de imágenes, despliegues, delegados, restricciones, etc. Para una completa guía<br />
de la herramienta, puede consultarse el apéndice A: Manual de Usuario.
88<br />
CAPÍTULO 6. HYDRA<br />
Figura 6.4: Secuencia de instalación en un nodo
6.6. HYDRA-ADMIN 89<br />
Figura 6.5: Pantalla de arranque (GRUB) de un nodo
7<br />
Caso de Estudio: ESI<br />
En este capítulo...<br />
Contenidos<br />
7.1. Situación Actual . . . . . . . . . . . . . . . . 91<br />
7.2. Implantación de HYDRA . . . . . . . . . . 95<br />
Una de las razones que motivaron el desarollo de este proyecto fue el sistema que<br />
hay implantado actualmente en la ESI para gestionar el parque informático de<br />
sus laboratorios docentes. En este capítulo se analizará dicho sistema, y se expondrán<br />
las ventajas que aportaría la instalación de HYDRA, así como una valoración de la<br />
infraestructura que necesitaría.<br />
7.1. Situación Actual<br />
Actualmente, cuando un alumno se sienta delante de un ordenador de un laboratorio<br />
y lo enciende, se arranca un sistema Fedora GNU/Linux que, automáticamente al<br />
iniciar sesión, presenta al alumno una pantalla de selección (ver figura 7.1). En esta
92<br />
CAPÍTULO 7. CASO <strong>DE</strong> ESTUDIO: ESI<br />
Figura 7.1: Pantalla de selección de máquina virtual<br />
ventana el alumno debe escoger la máquina virtual correspondiente a la asignatura<br />
sobre la que desee trabajar.<br />
Existe un servidor principal en el que están almacenados todos los ficheros de las<br />
imágenes VMWare de las diferentes asignaturas. Estas imágenes se encuentran en<br />
un directorio que está exportado por NFS para los ordenadores de las aulas, pero<br />
sólo en modo lectura. Para poder escribir y guardar cambios se utilizará un fichero<br />
distinto al de la máquina virtual, como se explicará más adelante. Cabe destacar que,<br />
mientras que la imagen del sistema es única para todos los usuarios, el fichero que<br />
contiene las modificaciones es propio de cada usuario; es decir, cada usuario tiene un<br />
fichero de modificaciones por cada imagen (la figura 7.2 ilustra esta situación). Una<br />
vez seleccionada la imagen que se desea utilizar, se ejecuta el virtualizador VMWare,<br />
que arrancará la imagen deseada, y el alumno puede entonces trabajar.<br />
El uso de máquinas virtuales puede parecer una buena solución, ya que permite<br />
reinstalar un ordenador entero en unos minutos en caso de que fuera necesario, sin que<br />
el sistema principal (Fedora) se vea afectado. Sin embargo, también tiene inconvenientes,<br />
como se explicó en el capítulo 2.<br />
El acceso de bajo nivel queda sesgado, lo que lleva a una situación paradójica: se<br />
puso la máquina virtual para que no fuera necesario trabajar en el sistema original<br />
(Fedora), pero ciertas asignaturas necesitan acceso de bajo nivel, por lo que tuvieron<br />
que acabar utilizando la Fedora para trabajar.
7.1. SITUACIÓN ACTUAL 93<br />
Es el caso de Animación para la Comunicación, en la que el software estudiado<br />
requiere aceleración gráfica para trabajar. Sin embargo, desde la máquina virtual no se<br />
puede acceder a una tarjeta gráfica ATI o nVidia, sino a tarjetas genéricas emuladas.<br />
Por ejemplo, en Virtualbox, la tarjeta gráfica aparece como ✭✭InnoTek Systemberatung<br />
GmbH Virtualbox Graphics Adapter✮✮, cuando en realidad debería constar como ✭✭nVidia<br />
Corporation NV34 [GeForce FX 5200]✮✮. En la asignatura de Interfaces y Periféricos<br />
realizan las prácticas utilizando un MS-DOS simulado, un sistema operativo que no se<br />
utiliza desde hace más de 10 años. En las asignaturas de redes, es necesario configurar<br />
las máquinas virtuales como Network Address Table (NAT), y los SSOO huéspedes<br />
reciben direcciones IP privadas, y direcciones MAC simuladas, con el ✭✭ruido✮✮ que eso<br />
implica para la docencia.<br />
Los profesores, además, deben seguir un proceso bastante engorroso si quieren cambiar<br />
algo en alguna de las máquinas virtuales. Sirva como ejemplo la siguiente sección,<br />
en la que se explica el proceso de actualización de una imagen.<br />
Es especialmente llamativo también el caso de un curso que se iba a impartir sobre<br />
tecnología Android. El curso, ofrecido por INDRA, requería que los alumnos descargaran<br />
una versión de la herramienta Eclipse y un plugin para el mismo. Hubo que<br />
descargar la versión de la web porque la versión instalada de serie en las máquinas<br />
virtuales no permitía, como es lógico, la instalación de plugins sin privilegios de súper<br />
usuario, mientras que la versión de la web puede instalarse siendo usuario normal.<br />
Los problemas comenzaron ya en la descarga, pues la escasa velocidad de la red<br />
hizo que este paso se alargara mucho más de lo esperado. Pero lo peor fue a la hora de<br />
instalar y ejecutar el programa, pues la máquina virtual consumía tantos recursos que<br />
hacía que el programa (que también es bastante pesado) se ejecutara a una velocidad<br />
inaceptable. Los ponentes hicieron un esfuerzo extra, pero el curso no se pudo impartir<br />
al 100 % y los conferenciantes señalaron que era ✭✭la escuela con peores recursos en la<br />
que habían estado✮✮.<br />
Actualizar una Imagen<br />
Es habitual que los profesores necesiten actualizar las imágenes que utilizan en su<br />
asignatura para instalar nuevos programas o ficheros, actualizaciones del SO, etc. A<br />
continuación se describe el proceso que deben seguir. Para el ejemplo se supone el uso
94<br />
CAPÍTULO 7. CASO <strong>DE</strong> ESTUDIO: ESI<br />
FEDORA<br />
/home/imagen/...<br />
.../usuario/imagen.vmdk<br />
(instalación)<br />
Montado<br />
por NFS<br />
VMWARE<br />
SERVIDOR<br />
/home/imagen/...<br />
.../config/usuario/imagen.vmdk<br />
(modificaciones)<br />
Copia<br />
Figura 7.2: Esquema de las máquinas virtuales en los laboratorios<br />
de una imagen que contiene un sistema GNU/Linux, aunque el proceso es similar para<br />
cualquier otro.<br />
1. En primer lugar, es necesario conseguir una copia de la imagen original que no<br />
esté congelada con un snapshot. 1<br />
2. Iniciar la máquina virtual, y actualizar/instalar lo que sea menester.<br />
3. Si se modifica el núcleo del sistema operativo, es necesario recompilar las vmware-tools.<br />
Para ello:<br />
Instalar cabeceras del núcleo, compilador, etc.<br />
En la ventana de VMWare, ejecutar la opción VM⇒Install VMWare<br />
Tools. Aparecerá una imagen de CD montada en /media/VMWareTools,<br />
que contiene el código fuente de las herramientas en formato rpm y gzip.<br />
Instalar el código fuente.<br />
Ejecutar el script de instalación (vmware-config-tools.pl), que compilará<br />
las herramientas.<br />
Sustituir el módulo para el driver de red (pcnet32) por vmxnet.<br />
4. Una vez actualizado el software, apagar la máquina virtual.<br />
1 Una imagen congelada no puede ser modificada, sólo leída.
7.2. IMP<strong>LA</strong>NTACIÓN <strong>DE</strong> HYDRA 95<br />
5. Es recomendable (aunque opcional) desfragmentar el fichero de la imagen, para<br />
reducir su tamaño y mejorar los tiempos de acceso:<br />
vmware−vdiskmanager −d<br />
imagen . vmdk<br />
6. Si el disco (fichero .vmdk) procede de una clonación, es posible que su nombre<br />
sea distinto al del original. Se puede renombrar:<br />
vmware−vdiskmanager −n nombreactual . vmdk nombrenuevo . vmdk<br />
Una vez renombrado, es necesario actualizar el fichero .vmx para que la referencia<br />
al disco virtual siga siendo correcta.<br />
7. Crear un snapshot del estado de la máquina virtual apagada. Con esto se consigue<br />
un nuevo fichero .vmdk que contendrá las modificaciones que se efectúen sobre<br />
la imagen, manteniendo ésta en su estado original. También se modificará la<br />
referencia del fichero .vmx para que apunte al fichero de snapshot.<br />
8. El disco virtual congelado, debe ubicarse en /home/imagen/usuario. Esta será la<br />
ruta que se exporta con permisos de sólo lectura, como se comentó anteriormente.<br />
9. El disco virtual que contiene las modificaciones realizadas al fichero de snapshot<br />
debe colocarse en /home/imagen/config/usuario. Los ficheros de esta carpeta<br />
se re-copian en cada PC del laboratorio en el arranque de la máquina virtual.<br />
10. Asignar permisos de lectura, al menos para el grupo, ya que en los PC de los<br />
laboratorios el usuario no coincide con el del servidor de las máquinas virtuales.<br />
También debe actualizarse el fichero version para que el PC del laboratorio reemplace<br />
los ficheros de configuración por los nuevos, por ejemplo con el comando:<br />
date > version<br />
7.2. Implantación de HYDRA<br />
La adopción de HYDRA como sistema de despliegue de imágenes supondría una<br />
gran mejora tanto en rendimiento como en experiencia de usuario para los profesores<br />
y los alumnos.
96<br />
CAPÍTULO 7. CASO <strong>DE</strong> ESTUDIO: ESI<br />
Los profesores podrían tener tantas imágenes como quieran para sus asignaturas,<br />
completamente personalizadas y configuradas por ellos mismos, y la actualización de<br />
las mismas se reduce a copiar la imagen nueva en el servidor y ejecutar un comando<br />
(ver la sección A.1 del Manual de Usuario). Además, el sistema permite la planificación<br />
semanal de las imágenes, instalando cada día las que van a ser necesarias.<br />
Los alumnos, por su parte, se olvidarán del engorro de trabajar con máquinas virtuales<br />
que les quitan recursos. Ahora, todo el equipo queda a disposición del usuario,<br />
mejorando la velocidad de ejecución de los programas. También tendrán acceso a los dispositivos<br />
reales del PC, en lugar de manejar los dispositivos virtualizados. Las prácticas<br />
de la asignatura de Interfaces y Periféricos, mencionada antes como ejemplo, podrían<br />
realizarse ahora en un MS-DOS nativo. Aunque podrían también utilizar GNU/Linux,<br />
Windows, Solaris o cualquier sistema soportado. O, por qué no, hacer una práctica en<br />
cada sistema, para ampliar conocimientos.<br />
Si por accidente un ordenador se corrompiera, el profesor podría ordenar al sistema<br />
que restaurase la configuración del nodo en cuestión, y en apenas unos minutos volvería<br />
a estar operativo.<br />
Instalar HYDRA en la ESI, no supondría modificar casi la infraestructura existente.<br />
El Manager debería ir colocado en un servidor de la red DMZ, ya que es una máquina<br />
que contendrá información ✭✭sensible✮✮. Sería lógico ubicarlo en el servidor que alberga<br />
actualmente las imágenes para las máquinas virtuales. Para actuar de Delegados pueden<br />
usarse los PCs que tienen asignados los profesores, aunque aquí sí que habría que<br />
cambiar un poco la red, para que tuviera la topología que muestra la figura 5.7.<br />
Para comparar, veamos cómo serían los pasos a realizar con HYDRA para el mismo<br />
ejemplo de actualizar una imagen. Se entiende por tanto, que el profesor ya subió en su<br />
momento la imagen al Manager, por lo que habría una copia de la imagen ✭✭preparada✮✮<br />
en el Manager y una copia ✭✭limpia✮✮ en el ordenador del profesor. Para actualizarla,<br />
tendría que hacer los siguiente:<br />
1. Acceder al entorno de la imagen (a través de la máquina virtual o con chroot si<br />
es un directorio) y actualizar como convenga. Es necesario aclarar en este punto<br />
que el uso de la máquina virtual se limita a la actualización de la imagen por<br />
parte del profesor; es decir, no se usa en los laboratorios. Se optó por este método<br />
por ser el más cómodo para el usuario crear imágenes.
7.2. IMP<strong>LA</strong>NTACIÓN <strong>DE</strong> HYDRA 97<br />
2. Salir del entorno de la imagen (VirtualBox) y copiarla de nuevo al Manager,<br />
mediante FTP, SSH o cualquier otro mecanismo disponible.<br />
3. Mediante la aplicación de administración, ejecutar el siguiente comando:<br />
hydra−admin .py update−image nombre antigua −f ruta img nueva<br />
La imagen quedaría entonces actualizada y en la próxima instalación se actualizaría<br />
en los nodos que correspondiese.
8<br />
Conclusiones y Trabajo Futuro<br />
Se ha presentado un sistema que soluciona el problema de gestionar un conjunto de<br />
nodos en el que existe gran heterogeneidad tanto a nivel hardware como software,<br />
con una herramienta orientada a facilitar la labor del administrador del cluster y a<br />
mejorar la experiencia de sus usuarios.<br />
Se han logrado cubrir los objetivos propuestos en el capítulo 2, con un sistema que<br />
permite instalar masivamente y de forma remota varios SSOO, que puede planificarse<br />
y cuya gestión es sencilla. La instalación se realiza de forma totalmente automática,<br />
desatendida por el administrador, y los sistemas operativos se ejecutan de forma nativa<br />
en los nodos, evitando la virtualización.<br />
Instalación automática y masiva Es posible instalar sistemas operativos en varios<br />
nodos, de forma totalmente automática, desde el arranque de los nodos hasta el<br />
particionado de los discos y la copia de los ficheros.<br />
Acceso a periféricos Los SSOO instalados pueden tener la configuración que los<br />
usuarios necesiten, incluyendo drivers específicos para los dispositivos concretos<br />
de los nodos.<br />
Mayor rendimiento Al suprimir la máquina virtual, se consiguió un ahorro de memoria<br />
y CPU que ahora queda a disposición de los usuarios.
100<br />
CAPÍTULO 8. CONCLUSIONES Y TRABAJO FUTURO<br />
Integridad de datos Un nodo mal configurado puede ser restablecido de forma automática.<br />
Configuración a medida Cada usuario puede crear Imágenes de SSOO con la configuración<br />
y programas que necesite.<br />
Planificación El sistema contempla la posibilidad de organizar el uso de las Imágenes<br />
de acuerdo a una planificación semanal, para un mejor aprovechamiento.<br />
Como hito adicional, es posible instalar la Imagen del sistema Fedora que se<br />
utiliza actualmente en los laboratorios, por lo que la compatibilidad es completa y<br />
ambos sistemas pueden coexistir.<br />
Queda sin embargo trabajo por delante, para hacer de HYDRA un sistema mucho<br />
más potente y flexible. Actualmente sólo están soportadas las imágenes de sistemas<br />
UNIX, aunque en breve se podrán utilizar sistemas Windows y esperamos en un futuro<br />
poder distribuir más sistemas, como MacOS de Apple o Solaris de Sun. También se<br />
está trabajando en una interfaz gráfica, tanto web como de escritorio para la herramienta<br />
de administración, de forma que su manejo sea aún más sencillo.<br />
Otro avance a corto plazo será la modificación de la librería Ice para soportar<br />
transporte multicast, lo que permitirá la instalación simultánea de las Imágenes en<br />
todos los nodos, acelerando el proceso de manera significativa.<br />
Una funcionalidad alternativa del sistema sería el manejo de imágenes que no contuvieran<br />
sistemas operativos, sino solamente datos. Tan sólo habría que definir este<br />
tipo especial para tenerlo en cuenta a la hora de instalar el gestor de arranque, y que<br />
no la contara como una partición a arrancar. Con este nuevo uso podrían, por ejemplo,<br />
distribuirse imágenes con texturas y modelos 3D para las clases de Animación para la<br />
Comunicación.<br />
Además, HYDRA no tiene porqué quedarse en una aplicación de PC: en un futuro<br />
pueden desarrollarse versiones de sus componentes adaptadas a las arquitecturas de<br />
PDA, PocketPC, o los teléfonos de nueva generación que están apareciendo en el mercado,<br />
de forma que cualquier empresa pueda administrar de forma sencilla el conjunto<br />
de todas sus herramientas informáticas.
101<br />
Por último, cabe destacar que este trabajo ha sido el tema de un artículo aceptado<br />
para el Simposio Nacional de Tecnologías de la Información y las Comunicaciones en<br />
la Educación (SINTICE) 2010.
A<br />
Manual de Usuario<br />
En este capítulo...<br />
Contenidos<br />
A.1. Gestión de Imágenes . . . . . . . . . . . . . 104<br />
A.2. Gestión de Despliegues . . . . . . . . . . . . 105<br />
A.3. Gestión de Equipos . . . . . . . . . . . . . . 107<br />
Para que el usuario interactúe con el Manager, se desarrolló una herramienta llamada<br />
hydra-admin que le permite efectuar todas las tareas que desee realizar con<br />
HYDRA. Es una herramienta con una Interfaz de Línea de Comandos (CLI), en la que<br />
se especifica la acción a realizar y las opciones que necesite dicha acción:<br />
hydra−admin .py [ OPCIONES ]<br />
A continuación se describe el manejo de dicha herramienta para cada una de las<br />
acciones posibles.
104<br />
APÉNDICE A. MANUAL <strong>DE</strong> USUARIO<br />
A.1.<br />
Gestión de Imágenes<br />
Un usuario puede crear, modificar y borrar Imágenes del sistema. Previamente,<br />
las Imágenes deben haber sido copiadas al servidor principal, donde se encuentra el<br />
Manager. Al hablar de Imagen nos referimos a un ✭✭contenedor✮✮ en el que se encuentran<br />
los ficheros de un sistema operativo completo. Actualmente, dichas Imágenes pueden<br />
ser de dos tipos:<br />
Ficheros .vdi de VirtualBox El usuario puede crear un disco de VirtualBox y utilizarlo<br />
como Imagen. El único requisito es que dicho disco haya sido creado como<br />
un disco de tamaño fijo. Esto es muy importante, ya que el sistema no podrá manejar<br />
imágenes de expansión dinámica.<br />
Directorio del sistema de ficheros Es posible añadir un directorio como Imagen.<br />
Esto permite, por ejemplo, distribuir un sistema operativo que se encuentra en<br />
un disco duro externo que ha sido montado previamente en el sistema de ficheros.<br />
Adición y Eliminación de Imágenes<br />
Para añadir una imagen al sistema, se utilizará la siguiente instrucción:<br />
hydra−admin .py add−image [−n | −−name ] NOMBRE [−f | −−file ] FICHERO<br />
[−t | −−fs−type ] TIPO [−−folder ]<br />
FICHERO La ruta completa (en el Manager) al fichero .vdi o directorio que contiene la<br />
imagen.<br />
NOMBRE Un nombre que asignar a la imagen. No debe haber dos imágenes con el mismo<br />
nombre. Puede utilizarse la asignatura para la que se va a usar, por ejemplo.<br />
TIPO El tipo del sistema de ficheros de la imagen. Esto se utilizará para dar formato<br />
a la partición donde se alojará la imagen.<br />
--folder Indica que la Imagen está almacenada en un directorio.
A.2. GESTIÓN <strong>DE</strong> <strong>DE</strong>SPLIEGUES 105<br />
El sistema añadirá la Imagen, la montará (en caso de ser necesario), y además<br />
la preparará para su publicación y la pondrá en disposición de ser distribuida. Estas<br />
operaciones pueden tardar algunos minutos.<br />
Para quitar una Imagen del sistema bastará con conocer su nombre y ejecutar la<br />
orden siguiente. El sistema la eliminará de la base de datos, aunque no borrará el<br />
fichero .vdi (o el directorio) que la contiene.<br />
hydra−admin .py delete−image NOMBRE<br />
Listar Imágenes<br />
Mediante esta instrucción el programa le mostrará al usuario una lista con las<br />
imágenes que se encuentren en ese momento registradas en el sistema, con todas sus<br />
características.<br />
hydra−admin .py<br />
list−images<br />
Actualizar una Imagen<br />
En este caso, NOMBRE hace referencia a una Imagen existente en el sistema, que es<br />
la que se pretende actualizar, y FICHERO es el contenedor de la Imagen con los nuevos<br />
datos.<br />
hydra−admin .py update−image NOMBRE [−f | −−file FICHERO ]<br />
A.2.<br />
Gestión de Despliegues<br />
Una vez que el usuario ha añadido las Imágenes que necesita, debe especificar en<br />
qué ordenadores y qué días quiere que se instalen. Para ello debe crear uno (o más)<br />
Despliegues.
106<br />
APÉNDICE A. MANUAL <strong>DE</strong> USUARIO<br />
Crear y Eliminar Despliegues<br />
hydra−admin .py add−deployment −n NOMBRE −i IMAGEN [,IMG2 ,IMG3 , ...]<br />
−d DIA [,DIA2 ,DIA3 , ...] [−g GRUPO ] [ MACLIST ]<br />
NOMBRE Un nombre para el Despliegue. No puede haber dos Despliegues con el mismo<br />
nombre.<br />
IMAGEN Nombre de una imagen que exista en el sistema. Puede especificarse más de<br />
una separando los nombres por comas.<br />
DIA Días de la semana (lunes, martes...) en que las Imágenes de este Despliegue deben<br />
estar instaladas en los nodos.<br />
GRUPO Nombre de un grupo de nodos. De esta forma no es necesario especificar una a<br />
una sus direcciones MAC.<br />
MACLIST Lista de direcciones MAC de los nodos, separada por espacios.<br />
A la hora de indicar los nodos, se puede optar por dar el nombre de un grupo, un<br />
conjunto de direcciones MAC o ambas. No indicar ningún nodo dará un error como<br />
resultado.<br />
Si se desea eliminar un Despliegue del sistema, se ejecutará la orden siguiente:<br />
hydra−admin .py delete−deployment NOMBRE<br />
Listar Despliegues<br />
Si un usuario necesita información sobre los despliegues existentes en el sistema,<br />
ejecutará lo siguiente:<br />
hydra−admin .py<br />
list−deployments<br />
La ejecución de esta instrucción retornará una lista con los Despliegues actualmente<br />
registrados en el sistema, mostrando sus nombres, Imágenes, calendario y nodos<br />
asociados.
A.3.<br />
GESTIÓN <strong>DE</strong> EQUIPOS 107<br />
Modificar Despliegues<br />
Puede ser necesario cambiar la descripción de un despliegue, para añadir o quitar<br />
una imagen, modificar el calendario, etc. Para ello, existe la siguiente instrucción:<br />
hydra−admin .py update−image NOMBRE [−f | −−file FICHERO ]<br />
A.3.<br />
Gestión de Equipos<br />
Listar Nodos<br />
Mediante esta instrucción puede obtenerse una lista con todos los nodos del sistema,<br />
junto con todas sus características.<br />
hydra−admin .py<br />
list−nodes<br />
Restaurar Nodo<br />
Si algún nodo se ha estropeado y necesita ser reinstalado, apunte su dirección MAC<br />
y ejecute:<br />
hydra−admin .py restore−node MACLIST<br />
Crear <strong>Grupo</strong><br />
orden:<br />
Para crear un grupo de nodos y juntarlos bajo un mismo nombre, utilice la siguiente<br />
hydra−admin .py group −n NOMBRE MACLIST<br />
Establecer Delegado
108<br />
APÉNDICE A. MANUAL <strong>DE</strong> USUARIO<br />
hydra−admin .py delegate [−−hostname NOMBRE | −m MAC ] [−g GRUPO ]<br />
MACLIST<br />
Esta instrucción permite asignar un Delegado para un conjunto de nodos. El Delegado<br />
puede especificarse bien por su nombre de host (con la opción -hostname) o por<br />
su dirección MAC (con la opción -m). La lista de nodos puede indicarse con un nombre<br />
de grupo, con una lista de direcciones MAC o con ambas.
B<br />
Terminología<br />
Imagen - Contenedor que alberga un sistema de ficheros en su interior, el cual corresponde<br />
a un sistema operativo completo y funcional. Puede ser un fichero de<br />
VirtualBox o un directorio.<br />
Despliegue - Entidad abstracta que describe las Imágenes que hay que instalar en<br />
unos nodos determinados (los cuales deben cumplir ciertas restricciones), y qué días<br />
de la semana deben estar instaladas.<br />
Manager - Ordenador en el cual se almacenan los sistemas operativos y desde el que<br />
se distribuirán. También es el encargado de decidir qué Imágenes hay que instalar<br />
y coordina las tareas de instalación.<br />
Nodo - Todo aquel ordenador que pertenece a la red HYDRA y es susceptible de ser<br />
supervisado por el Manager.<br />
Delegado - Es un tipo especial de nodo que actúa de intermediario entre el Manager<br />
y un conjunto de nodos. Se encarga de despertarlos y enviarles las Imágenes que<br />
necesiten.
C<br />
Acrónimos y Siglas<br />
Arco<br />
AMD<br />
ANSI<br />
ATA<br />
ATI<br />
BD<br />
BIOS<br />
BOEL<br />
CHS<br />
CIU<br />
CLI<br />
CORBA<br />
CRUD<br />
Arquitectura y Redes de Computadores<br />
Advanced Micro Devices<br />
American National Standards Institute<br />
Advanced Technology Attachment<br />
ATI Technologies Inc.<br />
Base de Datos<br />
Basic Input Output System<br />
Brian’s Own Embedded Linux<br />
Cylinder, Head, Sector<br />
Container Insallable Unit<br />
Interfaz de Línea de Comandos<br />
Common Object Request Broker Architecture<br />
Create Retrieve/Read Update Delete
112<br />
APÉNDICE C. ACRÓNIMOS Y SIG<strong>LA</strong>S<br />
DHCP<br />
DMZ<br />
DNS<br />
DOS<br />
DRBL<br />
E/R<br />
EBR<br />
ESI<br />
FAI<br />
FLUTE<br />
FS<br />
FTP<br />
G4U<br />
GFDL<br />
GNU<br />
GRUB<br />
HDD<br />
HP<br />
HTTP<br />
Dynamic Host Configuration Protocol<br />
De-Militarized Zone<br />
Domain Name System<br />
Disk Operating System<br />
Diskless Remote Boot in Linux<br />
Entidad/Relación<br />
Extended Boot Record<br />
Escuela Superior de Informática<br />
Fully Automated Installation<br />
File Delivery over Unidirectional Transport<br />
File System<br />
File Transfer Protocol<br />
Ghosting for Unix<br />
GNU Free Documentation License<br />
GNU is Not Unix<br />
GRand Unified Bootloader<br />
Hard Disk Drive<br />
Hewlett-Packard<br />
Hyper Text Transfer Protocol<br />
HTTPFS HTTP File System<br />
HYDRA<br />
Ice<br />
I<strong>DE</strong><br />
Heterogeneous sYstem Deployment and Remote Administration<br />
Internet Communications Engine<br />
Integrated Device Electronics
113<br />
IDL<br />
IP<br />
ISO<br />
IU<br />
IUDD<br />
<strong>LA</strong>N<br />
LBA<br />
LILO<br />
LTSP<br />
MAC<br />
MBR<br />
MIB<br />
Interface Definition Language<br />
Internet Protocol<br />
International Standards Oganization<br />
Installable Units<br />
IU Deployment Descriptor<br />
Local Area Network<br />
Logical Block Addressing<br />
LInux LOader<br />
Linux Terminal Server Project<br />
Medium Access Control<br />
Master Boot Record<br />
Management Information Base<br />
MS-DOS Microsoft Disk Operating System<br />
NAT<br />
NFS<br />
NTFS<br />
OMG<br />
OSI<br />
RMI<br />
PC<br />
PDA<br />
PXE<br />
RFC<br />
Network Address Table<br />
Network File System<br />
New Technology File System<br />
Object Management Group<br />
Open System Interconnection<br />
Remote Method Invocation<br />
Personal Computer<br />
Personal Digital Assistant<br />
Preboot eXecution Environment<br />
Request For Comments
114<br />
APÉNDICE C. ACRÓNIMOS Y SIG<strong>LA</strong>S<br />
RPC<br />
SATA<br />
Remote Procedure Call<br />
Serial ATA<br />
SINTICE Simposio Nacional de Tecnologías de la Información y las Comunicaciones<br />
en la Educación<br />
SIU<br />
Slice<br />
SLIM<br />
SM<br />
SMI<br />
SNMP<br />
SO<br />
SSOO<br />
SSH<br />
SQL<br />
TCP<br />
TFTP<br />
TMN<br />
UDP<br />
UML<br />
URL<br />
USB<br />
WoL<br />
XDR<br />
XML<br />
Smallest Installation Unit<br />
Specification Language for Ice<br />
Single Linux Image Management<br />
Solution Module<br />
Structure of Management Information<br />
Simple Network Management Protocol<br />
Sistema Operativo<br />
Sistemas Operativos<br />
Secure SHell<br />
Standard Query Language<br />
Transmission Control Protocol<br />
Trivial File Transfer Protocol<br />
Telecommunications Management Network<br />
User Datagram Protocol<br />
Unified Modelling Language<br />
Universal Resource Locator<br />
Universal Serial Bus<br />
Wake on Lan<br />
eXternal Data Representation<br />
eXtended Markup Language
D<br />
GNU Free Documentation License<br />
Version 1.3, 3 November 2008<br />
Copyright c○ 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.<br />
http://fsf.org/<br />
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.<br />
Preamble<br />
The purpose of this License is to make a manual, textbook, or other functional and useful document “free” in the<br />
sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it,<br />
either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get<br />
credit for their work, while not being considered responsible for modifications made by others.<br />
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in<br />
the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.<br />
We have designed this License in order to use it for manuals for free software, because free software needs free<br />
documentation: a free program should come with manuals providing the same freedoms that the software does. But this<br />
License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether<br />
it is published as a printed book. We recommend this License principally for works whose purpose is instruction or<br />
reference.<br />
APPLICABILITY AND <strong>DE</strong>FINITIONS<br />
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright<br />
holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free
116<br />
APÉNDICE D. GNU FREE DOCUMENTATION LICENSE<br />
license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to<br />
any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if<br />
you copy, modify or distribute the work in a way requiring permission under copyright law.<br />
A “Modified Version” of the Document means any work containing the Document or a portion of it, either<br />
copied verbatim, or with modifications and/or translated into another language.<br />
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively<br />
with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related<br />
matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a<br />
textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of<br />
historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political<br />
position regarding them.<br />
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant<br />
Sections, in the notice that says that the Document is released under this License. If a section does not fit the above<br />
definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant<br />
Sections. If the Document does not identify any Invariant Sections then there are none.<br />
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts,<br />
in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words,<br />
and a Back-Cover Text may be at most 25 words.<br />
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification<br />
is available to the general public, that is suitable for revising the document straightforwardly with generic<br />
text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing<br />
editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for<br />
input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup,<br />
has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is<br />
not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.<br />
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format,<br />
LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript<br />
or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque<br />
formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML<br />
for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript<br />
or PDF produced by some word processors for output purposes only.<br />
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to<br />
hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any<br />
title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the<br />
beginning of the body of the text.<br />
The “publisher” means any person or entity that distributes copies of the Document to the public.<br />
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or<br />
contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific<br />
section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.)<br />
To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled<br />
XYZ” according to this definition.<br />
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the<br />
Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards<br />
disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on<br />
the meaning of this License.<br />
VERBATIM COPYING<br />
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that<br />
this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced
117<br />
in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical<br />
measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may<br />
accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the<br />
conditions in section 3.<br />
You may also lend copies, under the same conditions stated above, and you may publicly display copies.<br />
COPYING IN QUANTITY<br />
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering<br />
more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that<br />
carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the<br />
back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must<br />
present the full title with all words of the title equally prominent and visible. You may add other material on the covers<br />
in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy<br />
these conditions, can be treated as verbatim copying in other respects.<br />
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many<br />
as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.<br />
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a<br />
machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computernetwork<br />
location from which the general network-using public has access to download using public-standard network<br />
protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must<br />
take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent<br />
copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque<br />
copy (directly or through your agents or retailers) of that edition to the public.<br />
It is requested, but not required, that you contact the authors of the Document well before redistributing any large<br />
number of copies, to give them a chance to provide you with an updated version of the Document.<br />
MODIFICATIONS<br />
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above,<br />
provided that you release the Modified Version under precisely this License, with the Modified Version filling the role<br />
of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of<br />
it. In addition, you must do these things in the Modified Version:<br />
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of<br />
previous versions (which should, if there were any, be listed in the History section of the Document). You may<br />
use the same title as a previous version if the original publisher of that version gives permission.<br />
B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications<br />
in the Modified Version, together with at least five of the principal authors of the Document (all of its principal<br />
authors, if it has fewer than five), unless they release you from this requirement.<br />
C. State on the Title page the name of the publisher of the Modified Version, as the publisher.<br />
D. Preserve all the copyright notices of the Document.<br />
E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.<br />
F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified<br />
Version under the terms of this License, in the form shown in the Addendum below.
118<br />
APÉNDICE D. GNU FREE DOCUMENTATION LICENSE<br />
G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document’s<br />
license notice.<br />
H. Include an unaltered copy of this License.<br />
I. Preserve the section Entitled “History”, Preserve its Title, and add to it an item stating at least the title, year,<br />
new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled<br />
“History” in the Document, create one stating the title, year, authors, and publisher of the Document as given<br />
on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.<br />
J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the<br />
Document, and likewise the network locations given in the Document for previous versions it was based on.<br />
These may be placed in the “History” section. You may omit a network location for a work that was published at<br />
least four years before the Document itself, or if the original publisher of the version it refers to gives permission.<br />
K. For any section Entitled “Acknowledgements” or “Dedications”, Preserve the Title of the section, and preserve<br />
in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given<br />
therein.<br />
L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers<br />
or the equivalent are not considered part of the section titles.<br />
M. Delete any section Entitled “Endorsements”. Such a section may not be included in the Modified Version.<br />
N. Do not retitle any existing section to be Entitled “Endorsements” or to conflict in title with any Invariant<br />
Section.<br />
O. Preserve any Warranty Disclaimers.<br />
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and<br />
contain no material copied from the Document, you may at your option designate some or all of these sections as<br />
invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These<br />
titles must be distinct from any other section titles.<br />
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified<br />
Version by various parties—for example, statements of peer review or that the text has been approved by an organization<br />
as the authoritative definition of a standard.<br />
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover<br />
Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of<br />
Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes<br />
a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on<br />
behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher<br />
that added the old one.<br />
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for<br />
publicity for or to assert or imply endorsement of any Modified Version.<br />
COMBINING DOCUMENTS<br />
Document with other documents released under this License, under the terms defined in section 4 above for modified<br />
versions, provided that you include in the combination all of the Invariant Sections of all of the original documents,<br />
unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve<br />
all their Warranty Disclaimers.<br />
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be<br />
replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the<br />
title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher<br />
of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant<br />
Sections in the license notice of the combined work.
119<br />
In the combination, you must combine any sections Entitled “History” in the various original documents, forming<br />
one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled<br />
“Dedications”. You must delete all sections Entitled “Endorsements”.<br />
COLLECTIONS OF DOCUMENTS<br />
You may make a collection consisting of the Document and other documents released under this License, and<br />
replace the individual copies of this License in the various documents with a single copy that is included in the collection,<br />
provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.<br />
You may extract a single document from such a collection, and distribute it individually under this License, provided<br />
you insert a copy of this License into the extracted document, and follow this License in all other respects regarding<br />
verbatim copying of that document.<br />
AGGREGATION WITH IN<strong>DE</strong>PEN<strong>DE</strong>NT WORKS<br />
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on<br />
a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation<br />
is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the<br />
Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not<br />
themselves derivative works of the Document.<br />
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document<br />
is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the<br />
Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise<br />
they must appear on printed covers that bracket the whole aggregate.<br />
TRANS<strong>LA</strong>TION<br />
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms<br />
of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but<br />
you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant<br />
Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty<br />
Disclaimers, provided that you also include the original English version of this License and the original versions of those<br />
notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a<br />
notice or disclaimer, the original version will prevail.<br />
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section<br />
4) to Preserve its Title (section 1) will typically require changing the actual title.<br />
TERMINATION<br />
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License.<br />
Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights<br />
under this License.<br />
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated<br />
(a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently,<br />
if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
120<br />
APÉNDICE D. GNU FREE DOCUMENTATION LICENSE<br />
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies<br />
you of the violation by some reasonable means, this is the first time you have received notice of violation of this License<br />
(for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.<br />
Termination of your rights under this section does not terminate the licenses of parties who have received copies<br />
or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a<br />
copy of some or all of the same material does not give you any rights to use it.<br />
FUTURE REVISIONS OF THIS LICENSE<br />
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from<br />
time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new<br />
problems or concerns. See http://www.gnu.org/copyleft/.<br />
Each version of the License is given a distinguishing version number. If the Document specifies that a particular<br />
numbered version of this License “or any later version” applies to it, you have the option of following the terms and<br />
conditions either of that specified version or of any later version that has been published (not as a draft) by the Free<br />
Software Foundation. If the Document does not specify a version number of this License, you may choose any version<br />
ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide<br />
which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently<br />
authorizes you to choose that version for the Document.<br />
RELICENSING<br />
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes<br />
copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody<br />
can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site<br />
means any set of copyrightable works thus published on the MMC site.<br />
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons<br />
Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future<br />
copyleft versions of that license published by that same organization.<br />
“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.<br />
An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published<br />
under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC,<br />
(1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.<br />
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at<br />
any time before August 1, 2009, provided the MMC is eligible for relicensing.
Bibliografía<br />
[Bhu71]<br />
A. Bhushan. File transfer protocol. RFC 114, Internet Engineering Task<br />
Force, April 1971. On-line: .<br />
[DGV04] Christine Draper, Randy George, y Marcello Vitaletti. Installable unit<br />
deployment descriptor for autonomic solution management. International<br />
Workshop on Database and Expert Systems Applications, 0:742–<br />
746, 2004. doi:http://doi.ieeecomputersociety.org/10.1109/<strong>DE</strong>XA.<br />
2004.1333563.<br />
[Fin00]<br />
Brian Elliott Finley. Va systemimager. En ALS’00: Proceedings of the 4th<br />
annual Linux Showcase & Conference, pages 11–11, Berkeley, CA, USA,<br />
2000. USENIX Association.<br />
[FSFa] FSF. Grand unified bootloader. On-line: [ene 2010].<br />
[FSFb] FSF. libparted. On-line: [ene 2010].<br />
[GHJV95]<br />
[GLR99]<br />
E. Gamma, R. Helm, R. Johnson, y J. Vlissided. Design Patterns. Addison<br />
Wesley, 1995.<br />
Mattias Gärtner, Thomas Lange, y Jens Rühmkorf. The fully automatic<br />
installation of a linux cluster. Informe Técnico 379, Zentrum für Angewandte<br />
Informatik Köln, Lehrstuhl Jünger, 1999.
122 BIBLIOGRAFÍA<br />
[GLV + 06]<br />
Y. Georgiou, J. Leduc, B. Videau, J. Peyrard, y O. Richard. A tool for<br />
environment deployment in clusters and light grids. En Parallel and Distributed<br />
Processing Symposium, 2006. IPDPS 2006. 20th International, page<br />
8 pp., april 2006. doi:10.1109/IPDPS.2006.1639691.<br />
[HS09] Michi Henning y Mark Spruiell. Distributed Programming with Ice, 2009.<br />
[Int99]<br />
Intel. Preboot execution environment (pxe) specification. Informe técnico,<br />
Intel Corp., 1999.<br />
[Kel] Simon Kelley. dnsmasq. On-line: [may 2010].<br />
[LIM] Proyecto limux. (en alemán). On-line: .<br />
[LWH + 04]<br />
David C. M. Lee, C. L. Wang, Daniel H.F. Hung, Roy S.C. Ho, y Francis<br />
C.M. Lau. On managing execution environments for utility computing.<br />
Informe técnico, Department of Computer Science and Information Systems,<br />
University of Hong Kong, 2004.<br />
[OMG08] OMG. Common object request broker architecture (corba) specification.<br />
Informe Técnico rev 3.1, Object Management Group,<br />
2008. On-line: .<br />
[PLL + 04] T. Paila, M. Luby, R. Lehtonen, Vincent Roca, y Robert Walsh. FLUTE -<br />
file delivery over unidirectional transport. RFC 3926, Internet Engineering<br />
Task Force, October 2004. On-line: .<br />
[PYU] pyunit. On-line: [ene 2010].<br />
[Riv92]<br />
[SBC + 99]<br />
[SFB]<br />
R. Rivest. The MD5 Message-Digest algorithm. RFC 1321, Internet Engineering<br />
Task Force, April 1992. On-line: .<br />
S. Shepler, C. Beame, B. Callaghan, M. Eisler, D. Noveck, D. Robinson,<br />
y R. Thurlow. NFS version 4 protocol. RFC 3530, Internet Engineering<br />
Task Force, December 1999. On-line: .<br />
Bart De Schuymer, Nick Fedchik, y Grzegorz Borowiak. ebtables. On-line:<br />
[may 2010].
BIBLIOGRAFÍA 123<br />
[SHWW08] Changhua Sunand, Le He, Qingbo Wang, y Ruth Willenborg. Simplifying<br />
service deployment with virtual appliances. En Services Computing, 2008.<br />
SCC ’08. IEEE International Conference on, volume 2, pages 265 –272,<br />
july 2008. doi:10.1109/SCC.2008.53.<br />
[SMS04]<br />
[Sol92]<br />
Richard Stallman, Rolan McGrath, y Paul D. Smith. GNU/Make A Program<br />
for Directed Compilation. GNU Press, Junio 2004.<br />
K. Sollins. The TFTP protocol (revision 2). RFC 1350, Internet Engineering<br />
Task Force, July 1992. On-line: .<br />
[Som04] Ian Sommerville. Ingeniería del Software. Addison Wesley, séptima<br />
edición, May 2004. On-line: .<br />
[Sta03]<br />
Richard M. Stallman. Using GCC: The GNU Compiler Collection. Free<br />
Software Foundation, 2003.<br />
[Sta07] Richard Stallman. GNU Emacs Manual, decimosexta edición, 2007.<br />
[Sun]<br />
SunMicrosystems. Virtualbox. On-line: [ene 2010].<br />
[VMA] David Villa, Cleto Martín, y Óscar Aceña. Atheist. On-line: [may 2010].<br />
[WZ04]<br />
[ZZ07]<br />
C. P. Wright y E. Zadok. Unionfs: Bringing File Systems Together. Linux<br />
Journal, 2004(128):24–29, December 2004.<br />
Yaoxue Zhang y Yuezhi Zhou. 4vp: A novel meta os approach for streaming<br />
programs in ubiquitous computing. Advanced Information Networking and<br />
Applications, International Conference on, 0:394–403, 2007. doi:http:<br />
//doi.ieeecomputersociety.org/10.1109/AINA.2007.6.