UNIVERSIDAD DE CASTILLA-LA MANCHA

Transcripción

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

UNIVERSIDAD DE CASTILLA-LA MANCHA

Transcripción

Documentos relacionados

pinturas - Gonzalez Y Gonzalez, Galería de arte | Lima

thursday may 7, 2015 6-9 pm - Lexington

ENFERMEDADES GENETICAS

-ST CARTILLA DEMO CORPORATE DIGITAL baja

(Visor de factura electrónica) (pdf

ENFERMEDADES GENETICAS

Sistema de Detección y Reconocimiento Facial de Conductores

Guión de prácticas

tesis - DCC - Universidad de Chile