Sistema de Regeneración de Nodos de Red

Transcripción

1 Sistema de Regeneración de Nodos de Red Diego Marcos Jorquera 1, Francisco Maciá Pérez 2 y Juan Carlos Monllor Pérez 2 1 ACK, Consultores e Ingenieros de Sistemas, S.L. dmj@ack-sistemas.com 2 Departamento de Tecnología Informática y Computación, Universidad de Alicante AP. 99, 03080, Alicante, España {pmacia, jcarles}@dtic.ua.es Resumen. Con independencia del nombre que se le dé informática como utility, informática autogestionable o informática autónoma, la automatización será una de las constantes en cualquier gran estrategia TIC que se pretenda abordar en un futuro próximo. El presente documento propone un sistema de regeneración de nodos sistema de recuperación ante desastres, que se enmarca dentro de los servicios encaminados a fortalecer la seguridad de los sistemas de información, mejorar la fiabilidad de la información y las infraestructuras, y ofrecer un mayor grado de confianza en las TIC por parte de empresas, administraciones y usuarios. El servicio propuesto está orientado a solventar una de las tareas que más preocupa y que más tiempo ocupa a los administradores de sistemas informáticos y redes de comunicaciones: conseguir mantener la operatividad de sus sistemas en cualquier momento, con independencia de su naturaleza y con la menor intervención posible por parte del administrador. Introducción En la actualidad la administración de las redes de computadores se ha convertido en una de las tareas más complejas dentro del ámbito de las nuevas tecnologías. Su realización conlleva normalmente un alto consumo tanto en recursos humanos como en aplicaciones e infraestructuras de apoyo. Esta complejidad está justificada, fundamentalmente, por el gran número y variedad de tareas que implica el mantenimiento de una red: Seguridad: realización de copias de seguridad de los datos, sistemas de autenticación, protección de datos, sistema de defensa como antivirus, o sistemas de filtrado como cortafuegos o control de contenidos. Operatividad: duplicación de servidores, sistemas de balanceo de carga o continuidad del negocio.

2 Monitorización: estadísticas de uso de los recursos, supervisión de los servicios o controles de la actividad. Inventario: recopilación de datos referentes al hardware, software o de los usuarios. Mantenimiento del software: instalación de sistemas operativos o aplicaciones, configuración de sistemas y actualización de los mismos. Todo ello provoca que los administradores tengan que emplear un elevado número de herramientas, cada una de las cuales cubre un subconjunto, no necesariamente disjunto, de servicios y plataformas. Estas herramientas suelen necesitar un elevado grado de especialización para su correcta utilización y, por lo tanto, requieren de administradores con un alto nivel de formación. Motivado por el estudio y resolución de estos problemas nace el grupo de Redes dentro del seno de la unidad singular de investigación de redes de computadores e informática industrial (i2rc) del Departamento de Tecnología Informática y Computación de la Universidad de Alicante. Su principal objetivo es aportar nuevos modelos que contemplen de manera unificada tanto los problemas y requerimientos convencionales como aquéllos más novedosos. El trabajo del Grupo se centra en la gestión de redes e integración de tecnologías, orientando sus estudios a las aplicaciones en sistemas distribuidos, especialmente a los componentes software distribuidos. En este documento se presenta un sistema de regeneración de nodos (denominado Gaia), cuyo objetivo es centralizar y automatizar la gestión de las redes de comunicaciones y de los dispositivos que la conforman. En concreto, el sistema materializa el concepto de reinstalación remota, distribuida y desatendida: reconfiguración y reinstalación del software de equipos a través de la infraestructura de red [1]. El núcleo central de Gaia proporciona un sistema de regeneración de equipos que automatiza de forma segura y rápida las operaciones de instalación y mantenimiento nodos de red: Poner en marcha un nuevo equipo o subred. Instalar software, incluido el sistema operativo en una máquina. Agregar un nuevo paquete software. Restaurar la actividad de un equipo ante un error software Gaia está basado en un micro-núcleo de sistema operativo (Gaia-kernel), bajo el que se ejecutan los servicios encargados de realizar las acciones de reinstalación (p.ej.: dar formato a discos y descomprimir archivos). El núcleo de Gaia proporciona independencia del hardware de los nodos, de sus sistemas operativos y de la infraestructura de red de comunicaciones que se utilice. La principal ventaja de Gaia es su alto grado de automatización y desatención por parte de los administradores de red.

3 Funcionalidad del sistema de regeneración El objetivo fundamental de este sistema es el de recopilar toda la información almacenada en cada uno de los nodos de nuestra red, transferirlas y almacenarlas en un repositorio. Esta información podrá ser posteriormente recuperada y transferida al nodo original de manera que el estado del equipo podrá ser restaurado al mismo que el estado en el que se encontraba en el momento en que se realizó su copia. El sistema de regeneración podría ser entendido como un sistema avanzado de copia de seguridad que, en vez de limitarse a almacenar únicamente la información sensible de nuestros nodos, tendría como ámbito de trabajo la totalidad de los datos almacenados en las unidades del equipo. Esta información incluiría: Sistemas operativos Aplicaciones Datos (documentos, correos, ) Configuraciones En un proceso inicial se realiza una fotografía del contenido del equipo, almacenando en un servidor todos los datos anteriormente descritos así como la ubicación actual de los mismos. En el posterior proceso de regeneración el sistema restaurará el equipo con los datos tal cual se almacenaron, restableciendo el contenido de los ficheros modificados, restituyendo los eliminados y borrando los creados. Los procesos de almacén y restauración podrán realizarse tantas veces como se considere necesario, pudiendo almacenarse diferentes imágenes de datos del equipo, de manera que se podría regenerar el estado del mismo con cualquiera de estas imágenes. Una de las características principales que debe cumplir el sistema de regeneración es contar con un alto grado de automatización y desatención en los procesos de almacén y restauración. Ello nos permitirá mejorar las tareas de administración de la red, reduciendo en lo posible la intervención de los operarios en el mantenimiento de las redes de ordenadores. Las diferentes posibilidades de uso que aporta el sistema de regeneración nos facilita gran medida la administración de la red, automatizando algunas de las operaciones más costosas a las que se suele enfrentar un administrador Recuperación de nodos ante caídas La principal utilidad del sistema de regeneración es la recuperación de nodos ante caídas. Cuando un nodo deja de estar operativo parcial o totalmente el proceso a seguir normalmente consiste en la reinstalación de parte o la totalidad del software instalado, incluyendo sistema operativo, drivers de dispositivos, aplicaciones,, así como la configuración de todos estos elementos. Esta tarea conlleva un alto coste temporal que se ve reflejado normalmente en un alto índice de ocupación de los recursos humanos, ya que suelen ser procesos que requieren de la atención y supervisión de un experto para su realización. Cuando el error afecta al sistema operativo el proceso se complica aun más ya que en estos casos normalmente es necesaria la reinstalación de la totalidad del software

4 del equipo. Por lo tanto la regeneración deberá ser posible incluso en casos drásticos en los que el equipo no puede arrancar ni siquiera el sistema operativo. El sistema de regeneración mejoraría sustancialmente este proceso aportando dos ventajas claras, una reducción en el coste temporal y un mayor índice de desatención o automatización. Mediante el sistema de regeneración se puede establecer unos niveles más altos de calidad de servicio y aporta características fundamentales hoy en día como son: la calidad de servicio (QoS), alta disponibilidad de los equipos, tolerancia a fallos y continuidad del servicio. Mantenimiento periódico de equipos En algunos escenarios la regeneración del los nodos no es requerida en casos de fallos extremos o malfuncionamiento del sistema sino que forma parte de la estrategia de mantenimiento periódico de la red. Es el caso de por ejemplo aulas informática donde el manejo continuo de los equipo, en muchos casos por multitud de diferentes usuarios, produce una rápida degeneración en la configuración de dichos equipos. Por ello se requiere una reinstalación periódica, muchas veces planificadas en el tiempo, para asegurar uno niveles de calidad aceptables en los servicios prestados por el sistema. Para estos casos el sistema de regeneración nos facilitaría la labor mediante reinstalaciones automáticas y desatendidas de los equipos que incluso podrían planificarse para ser realizadas en periodos de reposo o baja carga de la red. Replicación de sistemas Otra utilidad de permitiría el sistema de regeneración de nodos es la replicación de configuraciones software entre varios equipos. Mediante la replicación toda la información obtenida de un equipo podría utilizarse para regenerar uno o más equipos diferentes de manera que tendríamos configuraciones idénticas repartidas por nuestra red. Este uso del sistema es muy útil en escenarios como aulas de informáticas, laboratorios de prácticas, bibliotecas, etc., donde la configuración de todos los equipos suele ser muy parecidas si no idéntica. Este proceso podría ser considerado como una clonación de configuraciones software entre equipos. Para que no existan conflictos posteriores después de realizar una clonación suele ser necesaria una personalización del equipo para otorgarle datos de configuración propios como direcciones IP, nombre de equipo, etc. El uso de este proceso es altamente ventajoso en el caso de la puesta en marcha renuevas redes de computadores donde los nodos inicialmente no cuentan con ningún software instalado. Migración a otras plataformas hardware Una de las funcionalidades que también aportaría el sistema de regeneración es el cambio del hardware o la migración a otras plataformas hardware. Un claro ejemplo de esto sería la sustitución del disco duro de un equipo, ya sea por un error hardware como por una sustitución para obtener, si fuera el caso, una mayor capacidad. En vez

5 de realizar una reinstalación manual del equipo, una vez cambiado el disco, podría utilizarse el sistema de regeneración para realojar todos los datos que habíamos almacenado en el repositorio en el nuevo disco. Otro ejemplo claro de utilización del sistema de regeneración sería la migración total a otra plataforma hardware. Sería el caso en el que por ejemplo un usuario necesitara cambiar de equipo. Podría realizar una imagen de su equipo actual y reinstalarla posteriormente en el nuevo equipo, conservando así su anterior configuración. Control de inventario y gestión de configuraciones La información de inventario constituye uno de los pilares fundamentales del sistema de regeneración. Mediante el inventario el agente de regeneración obtiene la configuración de cada equipo con el que opera, retroalimentando esta información según se van modificando los componentes hardware o software de estos equipos. Complementando el inventario con información adicional referente a usuarios, localización de equipos, configuraciones de red, etc., se obtiene un base de datos que nos permite tener un mejor control de la red y aporta nuevas características al sistema de regeneración que facilitan la automatización de los procesos de mantenimiento. Servidor GAIA Nivel de Aplicación Cliente GAIA DHCP HTTP NFS MySQL Transferencia de archivos Nivel de Servicios NFS MySQL Transferencia de archivos SSL TCP/IP FS Proc MEM Virtual Nivel de Sistema Operativo SSL TCP/IP FS Proc MEM Virtual NIC I/O CPU MEM NIC I/O CPU MEM NIC I/O CPU MEM Nivel Hardware I/O CPU MEM RED DE COMUNICACIONES Figura 1. Arquitectura del sistema de regeneración GAIA. Tecnologías implicadas Realizar un sistema que contemple las características requeridas de independencia de la red, del nodo y del sistema operativo, lo convierte en un proyecto de complejidad y dimensiones muy grande. Para que esto fuera así tendríamos que rescribir nuestra aplicación para diversas plataformas y tendríamos que soportar multitud de sistemas

6 de archivo, ya que no olvidemos que nuestra principal labor consistiría en la recopilación y la posterior restauración de la información almacenada en nuestras unidades. Para evitar la realización de un sistema excesivamente complejo y con un mantenimiento muy costoso, lo que se plantea es la reutilización de plataformas ya desarrolladas que nos faciliten la creación de una aplicación específica que realice el proceso de almacenaje y restauración. Sistema operativo base (núcleo de Gaia) Conseguir una independencia respecto del sistema que se desea regenerar, sin tener que adaptar el agente de regeneración a cada plataforma, pasa por utilizar un único sistema operativo donde se ejecuta de manera exclusiva el agente. Una de las plataformas que nos aporta la base necesaria para nuestra aplicación es Linux. Las características de Linux que la convierten en un entorno apropiado para nuestro sistema son: Soporte para múltiples arquitecturas hardware. Existen diferentes distribuciones de Linux para varias plataformas hardware destacando las basadas en Intel 386 y superiores, Digital Alpha, Sun SPARC y Macintosh. Soporte de múltiples sistemas de archivo. Linux puede acceder a multitud de sistemas de archivo con lo que se facilita el acceso a la información almacenada en las unidades. Algunos de los sistemas de archivo soportados son ext2, ext3, fat, vfat, ntfs, xfs, minix, xenix, hfs o iso9660. Para el caso de sistemas de archivos no soportados, Linux nos ofrece un interfaz estándar de acceso a las unidades y particiones del equipo mediante el uso de dispositivos de bloques, característicos de los sistemas Unix. Soporte de múltiples tipos de red. Linux es un sistema operativo muy orientado al trabajo en red, principalmente con los protocolos TCP/IP aunque también soporta otros tipos de estándares como AX.25, X.25, IPX, PPP, DDP, Netrom, Appletalk o Netware. Posibilidad de rescribir o adaptar el código. Linux es un proyecto de código abierto con lo que se facilita enormemente la posibilidad de adaptar las funcionalidades del sistema operativo p para incorporar mejoras. Escalabilidad. Linux aporta diversas herramientas y tecnologías que permiten que los sistemas desarrollados bajo esta plataforma puedan escalarse de manera que se puede incrementar la capacidad e almacenamiento o el rendimiento de nuestras aplicaciones. Seguridad. Linux es un sistema operativo robusto que contempla multitud de estrategias orientadas a la seguridad, tanto a nivel de acceso al sistema como en el almacén de datos o las comunicaciones Sistema diskless. Linux al igual que otros sistemas operativos permite un funcionamiento diskless de los equipos. Esta tecnología permite a un equipo arrancar el sistema operativo y tener acceso a sus datos y aplicaciones sin necesidad de leer de ningún dispositivo de

7 almacenamiento local. Para ello se utilizan diversas tecnologías de red que veremos a continuación y que nos serán de gran utilidad. Por otra parte Linux nos da la posibilidad de usar diferentes tecnologías para resolver un mismo problema pudiendo considerarse estas como piezas de un puzzle que podemos ir intercambiando unas con otras, o incluso desarrollando nuevas, para obtener un mismo resultado. Sistema de archivo remoto El principal problema que se nos plantea a la hora de diseñar un sistema de regeneración de nodos es decidir dónde reside el agente de regeneración. El agente no puede ser una aplicación clásica que instalaríamos en el equipo que deseamos regenerar. Pensemos por ejemplo que ocurriría si el problema que se nos plantea es que nuestro disco duro, unidad donde reside el sistema operativo de nuestro equipo, se formatea accidentalmente o se corrompe por un mal apagado del equipo. Si el agente estuviera en este sistema de archivos también dejaría de estar accesible con lo que no sería posible la regeneración. Tener el agente instalado en un segundo disco u otra partición del disco principal tampoco soluciona el problema ya que este soporte también es susceptible de errores o pérdidas. Parece claro pues que el agente de regeneración deberá situarse fuera del nodo que deseamos regenerar. En una primera solución podría considerarse situar el agente en una unidad externa o en un medio de almacenamiento portable como podría ser un CD-ROM. En caso de caída del sistema sólo tendríamos que insertar el CD-ROM en la unidad apropiada y lanzar el agente que residiría en esta. Linux nos permite de manera completa y muy flexible situar una instancia del sistema operativo en un CD-ROM utilizando el sistema de archivos ISO9660 como base y unidades en memoria (ramdisk) para los procesos que requieran escribir ficheros. Un claro ejemplo de esto es la distribución de KNOPPIX [6] que nos permite arrancar un Linux muy completo desde un único CD-ROM. El inconveniente de este esquema es que se requiere que un operario introduzca el CD-ROM en el equipo a regenerar con lo que no podríamos por ejemplo automatizar o planificar reinstalaciones desatendidas de nodos. Una solución más elegante consistiría en utilizar un sistema de archivos remoto que nos permitiría montar nuestro sistema de archivos raíz desde un servidor de archivos mediante protocolos de red específicos. Ejemplos de sistemas de archivos remotos que son soportados por Linux serían: NFS (File Network System). Es un protocolo que nos permite montar un directorio situado en un equipo servidor en un directorio local al nodo cliente. Es un protocolo muy utilizado en entornos Unix. [2] SAMBA. Permite montar carpetas compartidas por equipos Windows. También permite compartir archivos y otros recursos como impresoras entre nodos Linux y Windows.[7] Coda File System. Este protocolo también nos permite motar sistema de archivos remotos. Tiene características adicionales importantes como

8 caché persistente en el lado del cliente y permite incluso el funcionamiento en caso de desconexiones. [8] NFS Servidor Figura 2. Esquema de funcionamiento de NFS. En nuestro caso vamos a utilizar NFS por ser un protocolo altamente difundido y con una gran compatibilidad entre diferentes tipos de servidores. Por lo tanto en un equipo servidor dispondremos de dos sistemas de archivos completos. Uno será el principal del servidor, es decir, el sistema operativo, aplicaciones y datos del servidor. Por otra parte, en uno de los directorios del servidor, lo que tendremos es otro sistema de archivos completo y diferente al primero que será el sistema de archivos que utilizará el nodo cliente para iniciar Linux. En el sistema de archivos del cliente residirá el agente de regeneración que, una vez iniciado el sistema operativo en el nodo cliente, realizará los procesos de recopilación de información o regeneración. El mismo sistema de archivo podrá ser usado por más de un cliente para realizar la regeneración, de manera que no sería necesario repetirlo por cada uno de los clientes que tienen que interaccionar con el sistema. Linux nos permite asociar directamente un sistema de archivos NFS como directorio raíz de un cliente mediante unas opciones especiales del núcleo que se configuran a tal efecto antes de su compilación. Autoconfiguración de red Utilizar un sistema de archivos remoto conlleva un problema. Cuando el núcleo de Linux termina su carga y procede a montar su sistema de archivo raíz que consistirá como hemos comentado en un directorio remoto mediante NFS, necesita unos datos de configuración mínimos para utilizar los protocolos de red necesarios. En concreto NFS está basado en TCP/IP por lo que el cliente necesita saber por lo menos que dirección IP tiene que usar como propia para establecer estas comunicaciones.

9 Para obtener la dirección IP del nodo cliente no podemos usar un sistema de almacenamiento local ya que recordemos que es precisamente ese sistema el que queremos regenerar y que por ejemplo puede ser una unidad que ha sido formateada. Para solucionar este problema existen diversos protocolos que nos facilitan la obtención de la dirección IP de un equipo. A estos protocolos se les suele denominar protocolos de autoconfiguración de red. El funcionamiento de estos se puede resumir de la siguiente manera: El equipo cliente que desea saber su dirección IP obtiene la dirección MAC de su tarjeta de red. Esta dirección está grabada en la propia tarjeta y consta de seis bytes que identifican de manera univoca cada NIC. El equipo cliente manda un paquete mediante un protocolo de autoconfiguración de red solicitando su IP. El paquete va dirigido a la dirección de broadcast y contiene la dirección MAC del cliente. Un servidor de la red recibirá la solicitud y contestará informando al cliente de su dirección IP. Para ello el servidor normalmente tendrá una tabla que asocia a cada MAC su dirección IP asociada. Algunos de los protocolos de autoconfiguración existentes y que podemos encontrar para Linux son: RARP (Reverse Address Resolution Protocol). Es el más básico de los protocolos de autoconfiguración que vamos a comentar. Se trata de un protocolo de nivel de red mediante el que se solicita la dirección IP asociada a una MAC. La función es justamente la inversa a la del protocolo ARP (Address Resolution Protocol) que nos proporciona la MAC de un equipo del que sólo conocemos su IP. El protocolo RARP pude ser usado también para obtener direcciones de protocolos diferentes al IP. [4] BOOTP (BOOTstrap Protocol). Es un protocolo perteneciente al conjunto TCP/IP. Se sitúa sobre la capa UDP utilizando el puerto 68 [3]. Con BOOTP además de obtener la dirección IP del equipo en cuestión también se obtienen otros datos de interés para la configuración de red como son: o IP del servidor o Nombre del servidor o Nombre del archivo de arranque DHCP (Dynamic Host Configuration Protocol). DHCP, al igual que BOOTP, es un protocolo del conjunto TCP/IP que ofrece información detallada para la autoconfiguración. La diferencia y gran ventaja de este protocolo es que la asignación de la IP se puede realizar de manera dinámica. Para ello en vez de definir en una tabla las concordancias de las direcciones MAC con las IP s, en el protocolo DHCP se puede definir un rango de IP s de manera que estas se van reservando y ofreciendo a los diferentes clientes que solicitan una configuración. Las IP s son reutilizadas de manera que si un equipo se apaga su IP puede ser asignada a otro que se enciende en ese momento. [5]

10 Estos tres protocolos también se pueden activar mediante una opción en el núcleo de Linux de manera que en el arranque del sistema operativo se determinaría automáticamente la dirección IP del cliente. Mi dirección MAC es 00:54:21:1A:40:BD Cuál es mi dirección IP? (1) (2) Servidor Tu IP es: MAC IP :47:B0:87:56: :54:21:1A:40:BD :67:AA:98:01:FC :10:2A:12:84: Figura 3. Esquema de autoconfiguración IP. Carga del núcleo y control remoto Así pues mediante un sistema de archivo remoto como nfs y un protocolo de atoconfiguración de red podemos iniciar nuestro sistema Linux sin necesidad de acceder a ninguna unidad local del equipo. Sin embargo aun nos queda pendiente una cuestión importante para poder iniciar nuestro sistema, tenemos que obtener el núcleo de Linux. Al igual que consideramos en el apartado de los sistemas de archivos remotos la opción más obvia es la de recuperar el núcleo de una de las unidades del equipo. Si descartamos la unidad del sistema por las razones de seguridad, que también habíamos comentados, las opciones se restringen a cargar el núcleo de dispositivos como disquetes o CD-ROM s. Esto como también se vio conlleva una pérdida en aspectos como la falta de automatización y desatención del sistema de regeneración. Una alternativa que se puede plantear y que en la actualizad es más que factible es el uso de tecnologías de inicio remoto de equipos como es el PXE. PXE es una especificación de Intel [9] que permite a un equipo obtener por red un sistema de arranque para el equipo. Para ello en una ROM situada en la tarjeta de red del equipo se sitúa una implementación del protocolo que en el arranque del equipo toma el control del sistema de arranque y transfiere de un equipo servidor el código de arranque especificado. Esto se realiza básicamente mediante el uso de dos protocolos de red que son sobre los que se fundamenta PXE: DHCP y TFTP.

11 CARGADOR IP NÚCLEO DHCP TFTP Figura 4. Esquema de carga de núcleo con PXE. Mediante DHCP el equipo consigue averiguar sus datos de configuración de red y la IP del servidor de arranque. DHCP también le dice la ruta del archivo de arranque para el equipo. Una vez tiene esos datos y mediante TFTP (Trivial File Transfer Protocol) el equipo transfiere el proceso de arranque desde el servidor. Por último se cede el control al proceso de arranque transferido (el cargador) que será el encargado de continuar con el arranque, en nuestro caso obtendrá el núcleo de Linux y las opciones de arranque necesarias mediante TFTP y lo iniciará. Este cargador se podría considerar como los cargadores clásicos de Linux (por ejemplo LILO o Grub) con la diferencia de que los datos en vez de obtenerse de una unidad local se transfieren por red. Un ejemplo de cargador de Linux mediante PXE es PXELINUX, un derivado del cargador SYSLINUX que fue originalmente desarrollado para el arranque de Linux desde disquete [10]. PXELINUX permite establecer en el servidor una configuración personalizada para cada uno de los equipos o grupo de equipos, con un núcleo y unas opciones de arranque diferentes. La desventaja del uso de PXE es que es necesario que la tarjeta de red de nuestros equipos tenga integrado este protocolo. Si no lo tuviera una opción válida sería grabar una implementación de PXE en una ROM e insertarla en la tarjeta. Para casos en los que esto último no fuera posible tendríamos que usar sistemas de almacenamiento externos como por ejemplo un disquete, donde situaríamos o bien directamente el núcleo o bien una implementación de PXE. Sistema de transferencia de archivos El sistema de trasferencia de archivos que se utiliza para el transporte de la información desde los clientes hasta el repositorio y viceversa, es un componente fundamental dentro del sistema de regeneración. Para ello las soluciones son muchas y de diferentes características. Por ejemplo NFS, comentado anteriormente, podría utilizarse como protocolo de transporte, si bien no nos da un resultado óptimo para la transferencia masiva de información. Protocolos como FTP o su versión segura con SSH (SFTP), establecen un protocolo

12 más orientado a la transferencia de archivos, si bien su rendimiento tampoco es muy elevado. Cliente Administración Control de acceso mediante tarjetas inteligentes (SmartCard) Servidor de Autenticación Directorio, Perfiles y Certificados Dir Entorno de Almacenamiento y repositorio software Cliente Regeneración Navegador Web Internet Router/ Proxy/ Firewall Servidor Web HTML DB DB DB DB Sistema de Información Agente Regeneración Cliente ubicuo de regeneración (PDA, portátil, Móvil,...) Agente Regeneración Interfaz Servidor de Aplicaciones Lógica de Negocio Figura 5. Escenario de desarrollo del Sistema de Regeneración de Nodos. El hecho de que la información a transferir sea de un alto volumen y que, como se verá mas adelante, en algunos casos se transmita a más de un cliente simultáneamente, hace necesario plantear la incorporación protocolos de transmisión que reduzcan la información de control de la comunicación, ganando así en velocidad y escalabilidad. Muchos de estos protocolos están basados en comunicaciones multicast como es el caso de Multicast File Transfer Protocol MFTP [11] o Bulk Multicast Transfer Protocol BMTP [12]. Principales procesos de Gaia Para tener una visión completa sobre el funcionamiento de Gaia a continuación se describen procesos de almacenamiento y regeneración del sistema, así como otros procesos avanzados que se pueden realizar. Proceso de almacenamiento Una vez hemos descrito las tecnologías que vamos a utilizar para arrancar nuestro sistema Linux que es donde reside el agente de regeneración, pasamos a describir el proceso completo con el que realizaríamos el almacenamiento de la información de un equipo, en este caso de un PC. Primero, una vez arrancamos el equipo, la BIOS del equipo pasa el control al PXE de la tarjeta de red. Este solicita los datos de configuración de red mediante una petición broadcast de DHCP y el servidor de DHCP nos responde con la IP del equipo y el resto de los datos de configuración.

13 Mediante TFTP se transfiere el cargador de linux (PXELINUX) desde el servidor. La dirección del servidor y la localización del cargador nos fueron suministradas en la respuesta DHCP. Una vez iniciado el cargador éste obtiene las opciones de arranque para este equipo y el núcleo de Linux a utilizar mediante TFTP. El núcleo se carga en memoria y se lanza con los datos de configuración obtenidos. El núcleo realiza el arranque del sistema y termina montando el sistema de archivos del servidor NFS. El núcleo pasa el control al proceso INIT el cual continúa con la carga del sistema: servicios, configuraciones, etc. Por último se cede el control al agente de regeneración. El agente obtiene la configuración de todas las unidades del equipo, determinando la información de las particiones y sistemas de archivos incluidos en estas. Esta información se almacena un el servidor de inventario. Este servidor dispondrá de un gestor de bases de datos (por ejemplo MySQL) donde iríamos almacenando las configuraciones de nuestros equipos. Por último el agente recogería toda la información de los sistemas de archivo lo comprimiría y lo almacenaría en un servidor de repositorio. Al recoger la información si el sistema de archivos es conocido por nuestro sistema almacenaríamos información sobre los archivos existentes en la partición, de manera que incluso se podría almacenar o restaurar información parcialmente, por ejemplo una aplicación en concreto. Si no se conoce el sistema de archivos tendríamos que almacenar toda la información de la partición, incluyendo las zonas no utilizadas del disco, con lo que el proceso no sería óptimo. Los cinco servicios utilizados para el sistema de regeneración (DHCP, TFTP, NFS, inventario y repositorio) se podrían separar en cinco servidores diferentes. Incluso podríamos tener varios servidores para cada servicio (escalabilidad vertical) para mejorar el rendimiento del sistema o proporcionar tolerancia a fallos. Estos servicios también podrían residir todos en un único servidor, o establecer cualquier agrupamiento que se considere. Una configuración apropiada para sistemas no muy grandes sería agrupar los tres primeros en un único servidor de arranque y los dos últimos en un servidor de almacenamiento. Proceso de regeneración El proceso de regeneración operaría de forma similar al proceso de almacenamiento. De la misma forma el equipo arrancaría Linux que terminaría iniciando el agente de regeneración. Este obtendría la configuración actual del equipo y la compararía con la almacenada en el servidor de inventario. En caso de que existan diferencias, por ejemplo con el tamaño de un disco, el agente reajustaría los datos para realojar la información almacenada. Los datos se obtendrían del repositorio descomprimiéndose antes de realojarlos en el equipo. El agente tendrá que particionar o formatear unidades en caso de ser necesario. Procesos avanzados Los procesos de almacenamiento y regeneración que acabamos de ver se pueden considerar procedimientos básicos que actúan de manera global, ya que almacenan y

14 regeneran toda la información, devolviendo al equipo al estado en el que se encontraba en el momento en que se almacenó. A continuación veremos una serie de procesos avanzados que nos permitirán mejorar y flexibilizar estos procesos básicos. Instalación de paquetes individuales Uno de los aspectos en los que nos puede ser útil el sistema de regeneración es en el despliegue de datos o aplicaciones dentro de nuestra red. Supongamos por ejemplo que contamos con un aula de equipos informáticos donde queremos instalar un nuevo software en todos los equipos. Mediante el sistema de regeneración el proceso se puede simplificar de la siguiente manera. El agente de regeneración realiza una copia de uno de los equipos antes de instalar el nuevo software. Posteriormente se instala el paquete en dicho equipo. El agente de regeneración podrá hacer ahora otra copia del equipo, pero en este caso se trataría de una copia diferencial. El agente solamente almacenaría los archivos nuevos o modificados. También se encargaría de obtener los cambios realizados en la configuración del equipo, por ejemplo los datos modificados en el registro en caso de tratarse de un sistema Windows. Por último el agente de regeneración podría instalar este paquete en el resto de los equipos del aula, repitiendo la configuración del equipo origen en los demás. A este paquete se lo podría denominar un paquete incremental, y su contenido podría ser de cualquier tipo: aplicaciones, datos, drivers, etc. Ampliando el concepto que acabamos de ver podríamos descomponer la instalación completa de un equipo en un conjunto de paquetes que iríamos almacenando de manera incremental. Primero instalaríamos en un equipo el sistema operativo y crearíamos su paquete. Después instalaríamos cada una de las aplicaciones y las iríamos almacenando, así hasta que completemos el proceso de instalación de un equipo. Una vez finalizado tendríamos en el repositorio un conjunto de paquetes individuales e incrementales. Después para instalar o regenerar cualquier equipo sólo tenemos que indicarle que conjunto de paquetes necesita cada uno. De esta manera podemos personalizar nuestra red con diferentes configuraciones de equipo. Para facilitar el trabajo se puede almacenar en el servidor de inventario cual es la configuración que deseamos para cada equipo, así como un conjunto de configuraciones prototipo que nos ayuden en las tareas de creación de nuevas configuraciones. De esta manera ahorraríamos espacio, ya que cada unidad software sólo se almacenaría una vez, y ganaríamos mucho en flexibilidad y adaptabilidad de los equipos en la red. Se podría incluso definir diferentes configuraciones para un mismo equipo y regenerarlo completamente cada vez que por ejemplo un usuario diferente hace uso de el. Un claro ejemplo de esto serían los laboratorios de prácticas para los alumnos que necesitan tener software o sistemas operativos específicos en función de la asignatura que se está impartiendo en cada momento. Para poder crear los paquetes incrementales el sistema tiene que poder soportar el sistema de archivos del equipo ya que tiene que ser capaz de almacenar información referente a los archivos existentes.

15 Planificación de reinstalaciones Otro aspecto importante a la hora de realizar las reinstalaciones de los equipos es la planificación de estas. Dado que el proceso de reinstalación provoca una perdida temporal de la operatividad del equipo, ya que este arranca el sistema Linux que contiene el agente, es conveniente que las reinstalaciones se realicen en horarios de nulo o bajo uso de los mismos, por ejemplo por la noche. Para ello es fundamental incorporar un sistema de planificación de los procesos de reinstalación. El principal problema de estas planificaciones es que, llegado el momento, el servidor necesitará arrancar los equipos para que se cargue el agente de regeneración. Para ello nos podemos valer de la tecnología Wake-on-LAN. Esta tecnología nos permite encender de manera remota nuestros equipos. Para ello el servidor simplemente tiene que mandar un paquete especial a la dirección MAC del equipo en cuestión, este equipo al recibir el paquete iniciará el arranque del mismo. Para que esto sea posible el equipo tiene que suministrar corriente a la tarjeta de red incluso cuando esté está apagado. Hoy en día la mayoría de las placas base y tarjetas de red que se fabrican soportan esta tecnología. Procesos pre y post instalación Si bien con la separación de los paquetes de instalación en fracciones más pequeñas conseguíamos más flexibilidad a al hora de personalizar la configuración de un equipo, seguimos teniendo el inconveniente de que los clientes reinstalados no dejarían de ser copias exactas (totales o parciales) de un equipo original. En algunos casos será necesario poder programar antes o después de la instalación de cada paquete individual la ejecución de una serie de comandos que nos permitan realizar acciones de configuración y retoques finales para el correcto funcionamiento del software. Un ejemplo claro de esto sería el proceso de personalización con los datos propios de cada equipo (desclonificación). Mediante este proceso podríamos otorgar a cada equipo su nombre de red o su dirección IP (en caso de ser estática), etc. Otras acciones que podríamos realizar mediante estos procesos son: el registro de las aplicaciones que lo requieran, el borrado de archivos temporales o la comprobación de prerrequisitos a la hora de instalar un determinado paquete. Administración de Gaia Otro de los aspectos a contemplar en nuestro sistema de regeneración es su administración. Para esto proponemos una administración lo más sencilla posible que nos permita configurar y gestionar la herramienta de regeneración y que nos sirva a la vez como utilidad de consulta y monitorización del sistema. Para ello proponemos una administración basada en web que nos permitiría la gestión de la herramienta desde cualquier nodo que pueda acceder al sistema mediante un navegador web estándar.

16 HTTP DHCP TFTP NFS Inventario Repositorio Figura 6. Esquema de administración basada en web. Así pues en un equipo servidor se activaría un servicio web encargado de, tras recibir las peticiones del cliente web, realizar las operaciones oportunas en el sistema para materializar dicha petición. Figura 7. Página web de administración de Gaia. Desde la web de administración se pode realizar las tareas de gestión del sistema de regeneración como son: Gestión de inventario: alta, modificación, borrado y consulta de los equipos cliente a regenerar. Gestión de particiones: administración de las particiones existentes en cada uno de los clientes. Gestión de tamaños, tipos de sistema de archivos, etc. Gestión de configuración: creación y mantenimiento de perfiles de equipos o laboratorios.

17 Gestión del sistema: control del espacio libre en el repositorio, gestión de servicios. Servidor de aplicaciones Implementar un sistema de administración general, que cubra todas las necesidades actuales de nuestra red, y que permita una evolución del mismo sin que ésto conlleve cambios drásticos en su arquitectura, es unos de los objetivos más importantes que debe plantearse. Afrontar el sistema con tecnologías clásicas como podría ser el paradigma cliente-servidor, supondría un gran esfuerzo, no sólo para su realización, sino también, para sus futuras adaptaciones. En la actualidad los sistemas basados en componentes [13] [14], como es el caso de J2EE, ofrecen una solución mucho más modular y adaptable, y con la que, además, obtenemos importantes características para nuestro sistema como son un alto grado de escalabilidad, independencia de la plataforma o independencia del dispositivo de representación de la información. Otra de las características que hacen atractiva esta solución es la posibilidad de incorporar de manera relativamente sencilla otros sistemas de terceros. En la Figura 8 se muestra un esquema de una plataforma propuesta siguiendo un patrón de diseño modelo-vista-controlador (MVC). Para dicho modelo, el controlador estará constituido por servlets; las vistas se generarán con páginas activas JSP (exentas de código) y el modelo hará referencia al núcleo de la aplicación, diseñado sobre una plataforma middleware de componentes software distribuidos EJB. El sistema de mantenimiento debe permitir gestionar todos los recursos del sistema. Por un lado, la propia infraestructura hardware (servidores, dispositivos de networking) y software (servidores Web, de aplicaciones, repositorio de componentes, servidor SQL, etc.). Por otro lado, deberá proporcionar herramientas para las gestión de los recursos del sistema: usuario, inventario, configuraciones de equipos, paquetes software, imágenes de datos, etc. Todo esto, a través de una interfaz normalizada, accesible desde cualquier dispositivo y lugar, mediante un navegador Web estándar. En este diseño el motor de trabajo básico de Gaia, así como los sistemas de repositorio e inventario, se tratarían como sistemas heredados a los que accedería el sistema general mediante protocolos estándares como XML. Tanto el agente de regeneración como la web de configuración del sistema tendrían su acceso al servidor web mediante unas relaciones B2B o B2C respectivamente. Utilizando este modelo, para la evolución del sistema, simplemente tendríamos que ir completando la lógica de negocio, incorporando nuevas funcionalidades o utilizando sistemas ya existentes mediante la conexión con sistemas heredados.

18 Sistema de gestión Sistemas Heredados Cliente Servidor web Servidor de aplicaciones Agente de regeneración SOAP <<Servlet>> Controlador Controlador B2B B2B <<SessionBean>> Controlador de or de generador Lógica de negocio Sistema de backup Sistema de backup Núcleo de Gaia Navegador SOAP HTTP SSL HTML <<Servlet>> Controlador de de trabajo <<JSP>> Controlador de dela vista <<SessionBean>> Controlador or de de gestión Sistema Siste de información de información Paquete Paquete de de adaptación Directorio Certificad. usuarios orio Digitales cad. usuarios Digitales Inventario Config. Licencias Paquetes Software ncias Software etes Software Software Figura 8. Arquitectura del sistema de administración. Posibles Escenarios de desarrollo Algunos de los posibles escenarios en los que podría desplegarse el sistema de regeneración se describen a continuación. Escenarios de Intranet simples Este primero está basado en pequeñas redes locales de pequeñas o medianas organizaciones. En este caso, el servidor de regeneración está contenido en un único equipo, configurado como nodo de red tipo appliance, preparado para conectar (a la red) y (tras asignar una IP válida) operar. Esta opción proporciona un dispositivo con un mantenimiento mínimo, a cambio de perder prestaciones de configuración avanzada o de no proporcionar servicio a través de redes de área amplia. Escenarios de Intranet complejos El segundo escenario proporciona una configuración compleja del servicio de regeneración, de forma que cada uno de sus componentes se despliega en equipos diferentes: servidor Web para la interfaz, servidor de aplicaciones para los componentes y la lógica de negocio, servidor de datos para el sistema de información y, finalmente, servidor de autenticación para perfiles, directorio de usuarios y certificaciones. En este escenario se facilitan todas las posibilidades del servicio (a costa de una interfaz de gestión más completa y compleja) y nos permitirá estudiar su adaptabilidad a los cambios en la infraestructura y, sobre todo, su capacidad para escalar.

19 Escenarios de Extranet Obviamente, se trata del escenario más complejo y completo en el que, además de las características recogida en los anteriores escenarios, se añade la posibilidad de despegar el servicio a través de redes de área amplia y a partir de múltiples servidores de regeneración en diferentes ubicaciones. A continuación se presenta un análisis de diferentes escenarios reales en los que podría aplicarse el servicio de regeneración. Profesiones liberales: abogados, arquitectos. Se trata de profesiones en las que en la actualidad resulta casi imprescindible disponer de una infraestructura informática mínima. Sin embargo, su volumen no justifica, la mayor parte de las veces, el gasto que conlleva su mantenimiento cuando éste incluye una disponibilidad 24x7. En este caso, bien a través de Colegios profesionales o por suscripción a un proveedor de servicios, se puede gestionar la instalación, actualización y recuperación de estos equipos de manera remota, compartiendo los gastos de infraestructuras con otros usuarios. Grandes compañías con sedes o sucursales distribuidas: bancos, aseguradoras. El escenario más habitual es el de un parque informático complejo y distribuido en el que, a excepción de las sedes principales, no se justifica una gestión local de los nodos. Por otra parte, muchos de estos nodos podrían estar repetidos en cada sucursal (cajeros, pequeños servidores locales, terminales de operación, ). En la actualidad, la gestión remota a través de redes WAN es inviable debido a que resulta casi imposible asegurar que los equipos estarán disponibles en los tiempos requeridos. La utilización de líneas dedicadas resulta muy costosa y, en caso de disponerse, las tareas de mantenimiento no suelen justificar el uso del enorme ancho de banda que precisan para realizar su función. El sistema propuesto, gracias a la tecnología que utiliza, puede operar sobre redes tan económicas como Internet, asegurando la disponibilidad de los sistemas en el tiempo adecuado. Educación. Entidades como colegios, institutos y universidades pueden aprovechar la capacidad del sistema de regeneración para instalar y mantener actualizados grandes laboratorios de ordenadores personales en los que se precisa múltiples configuraciones en muy breve espacio de tiempo (cambio de clases, reinstalaciones nocturnas, ) y se dispone de una infraestructura de red muy limitada. Gobierno. Los organismos oficiales, por sus especiales características en las que confluyen la mayor parte de los requerimientos operativos citados hasta el momento, constituyen ecosistemas ideales en los que el sistema de regeneración de nodos puede aportar un elemento de cohesión a sus infraestructuras, adaptándose tanto a la diversidad de entornos en los que debe desplegarse, como a la de sus necesidades de operatividad: seguridad, privacidad, redundancia, disponibilidad, QoS, volumen de información, Operadoras de cable. Uno de los grandes problemas a los que se enfrentan los actuales proveedores de cable que pretenden distribuir servicios a través de este medio es la gestión remota de las terminales de los potenciales miles de usuarios necesitan instalar en sus hogares para acceder a los mismos. El sistema propuesto, permitiría un control, gestión, actualización y, sobre todo, regeneración de dichos terminales remotamente, de un modo eficaz y sencillo, a través de su propia infraestructura de comunicaciones (ver fig. 9).

20 Satélite Downlink hacia el subscriptor Uplink hacia el satélite BD RA Nodo a Regenerar Internet RA SIA RIA BD RIA Contexto NRS Figura 9. Posible escenario de aplicación del sistema de regeneración de nodos que integra distintas tecnologías Internet, cable y transferencia masiva de información a través de satélites. Conclusiones En este artículo se ha realizado una revisión bastante amplia de la arquitectura de Gaia, así como de muchas de las tecnologías que se ven implicadas en este sistema. En la actualidad Gaia se encuentra implantada como sistema central de su política de seguridad y mantenimiento en diferentes organizaciones de ámbito muy plural. Esta implantación proporciona una realimentación que posibilita su evolución, siempre dentro de los objetivos principales establecidos de automatización y desatención de los procesos de gestión de redes de computadores. Uno de los problemas abiertos en la actualidad y sobre los que estamos investigando es la incorporación de mecanismos de difusión masiva de información a través de redes de área amplia que mejoren los procesos de comunicación en la regeneración de los equipos. También estamos interesados en proporcionar una interfaz de gestión mucho más amigable, versátil e integrada dentro del esquema global de servicios y aplicaciones basadas en grandes redes de comunicaciones como Internet. Referencias 1. Maciá Pérez, F.: Modelos de Administración de Redes Heterogéneas de Computadores. Sistema de Regeneración de Nodos de Red. Tesis Doctoral. Servicio de Publicaciones de la Universidad de Alicante, julio Sun Microsystems, Inc.: RFC 1094, NFS: Network File System Protocol Specification. Request for Comments. Marzo 1989.

21 3. Croft, B. y Gilmore, J.: RFC 951, BOOTSTRAP PROTOCOL (BOOTP). Request for Comments. Septiembre Finlayson, R., Mann, T., Mogul, J. y Theimer, M.: RFC 903, A Reverse Address Resolution Protocol. Request for Comments. Junio Droms, R.: RFC 1531, Dynamic Host Configuration Protocol. Request for Comments. Octubre Web oficial de KNOPPIX Web oficial de SAMBA Web oficial de CODA File System Web oficial de Intel Web oficial de SYSLINUX. 11. Millar, K., Robertson. K., Tweedly, A., White, M.: StarBusrt Multicast File Transfer Protocol (MFTP) Specification. Internet Draft. Febrero Morris, R.: Bulk Multicast Transport Protocol. Procedings of INFOCOM 97. Abril Sing, I, Brydon, S., Murray G., Ramachandran, V., Violleau T, Stearns, B.: Designing Web Services with the J2EE(TM) 1.4 Platform : JAX-RPC, SOAP, and XML Technologies, Second Edition. Ed: Pearson Education, Sing, I, Stearns, B, Jonson, M: Design Enterprise Applications with J2EE Plantaform, Second Edition. Ed: Addison-Wesley, ISBN