Grid Manager - Administración remota de los recursos de un Grid

Texto completo

(1)GRID MANAGER. Autor Luis Carlos Beltrán Vallés Proyecto de Grado Grupo Comit Administración remota de los recursos de un Grid. Asesor Harold Castro Barrera Ingeniero de Sistemas y Computación Doctor en Informática Profesor Asociado de la Universidad de los Andes. Universidad de los Andes Facultad de Ingeniería Programa Ingeniería de Sistemas y Computación Bogotá – 2007. 1.

(2) Índice INTRODUCCIÓN .............................................................................................................4 1. Problemática.............................................................................................................5 2. Requerimientos Funcionales..................................................................................6 1.1 R1 – Mostrar información relevante del estado de cada equipo..............6 1.2 R2 – Encender remotamente un equipo ......................................................6 1.3 R3 – Apagar remotamente un equipo...........................................................6 1.4 R4 – Reiniciar remotamente un equipo........................................................6 1.5 R5 – Verificar porcentaje de uso del procesador de un equipo ...............6 1.6 R6 – Verificar porcentaje de uso de memoria de un equipo.....................7 1.7 R7 – Validar usuarios de la aplicación .........................................................7 3. Requerimientos no funcionales .............................................................................8 3.1 La aplicación cliente debe ser presentada como una página web dinámica ........................................................................................................................8 3.2 Se debe desarrollar la aplicación sobre un contenedor J2EE..................8 3.3 Almacenamiento de usuarios del sistema en un directorio LDAP...........8 4. Modelo .......................................................................................................................9 4.1 Package grid.model.vo....................................................................................9 4.1.1 RemoteComputerVO.............................................................................10 4.1.2 GridUserVO.............................................................................................11 4.1.3 LDAPServices.........................................................................................11 4.1.4 GridClusterVO ........................................................................................12 4.2 Package grid.model.ejb.................................................................................12 4.2.1 GridClusterBean.....................................................................................12 4.3 Package grid.model.interfaces.....................................................................13 4.3.1 GridClusterHome ...................................................................................13 4.3.2 GridCluster..............................................................................................13 4.4 Package grid.model.web...............................................................................14 4.4.1 SignInSevlet............................................................................................14 4.4.2 ClusterInfoServlet...................................................................................15 5. Diseño......................................................................................................................16 5.1 Obtención de la información relevante de cada máquina.......................16 5.2 Encender, Reiniciar y Apagar remotamente un equipo...........................17 5.3 Validar Usuarios.............................................................................................18 6. Implementación......................................................................................................19 6.1 Posibles Estados de los recursos ...............................................................20 6.1.1 Offline.......................................................................................................21 6.1.2 Online-‘sistema operativo del grid’......................................................21 6.1.3 Online-‘otro sistema operativo’ ............................................................21 6.2 Obtención del estado de un recurso...........................................................21 6.2.1 Ping del Host...........................................................................................22 6.2.2 Verificación del sistema operativo.......................................................22 6.2.3 Verificación de sesiones activas..........................................................22. 2.

(3) 6.3 Servicios de GridManager............................................................................23 6.3.1 Directorio LDAP......................................................................................23 6.3.2 Iniciar Sesión ..........................................................................................25 6.3.3 Cargar información de los recursos....................................................26 6.3.4 Encender Remotamente.......................................................................28 6.3.5 Apagar remotamente.............................................................................31 6.3.6 Reiniciar Remotamente.........................................................................32 6.3.7 Obtener uso de procesador y memoria..............................................33 6.3.8 Cerrar Sesión..........................................................................................33 6.4 Servicios activos para cada estado.............................................................34 6.4.1 Servicios Estado Offline........................................................................34 6.4.2 Servicios Estado encendido sin usuarios activos.............................35 6.4.3 Servicios Estado encendido con usuarios activos............................36 Conclusiones ..................................................................................................................38 BIBLIOGR AFÍA...............................................................................................................40. 3.

(4) INTRODUCCIÓN La tecnología informática y computacional, en las últimas décadas, ha presentado una gran evolución. Mientras en los 70’s lo que se imponía eran las aplicaciones de arquitectura batch, hoy en día es muy común que los sistemas informáticos sean distribuidos y estén basados en distintos tipos de tecnología [1]. En especial, el desarrollo de sistemas de grids (mallas) ha tenido una gran acogida en el último decenio. Su importancia radica en la capacidad de compartir recursos, dando la apariencia de que todos ellos fueran uno solo. De ese modo, se pueden adaptar redes de computadores para que funcionen como una sola ‘súper máquina’ a la cual se le pueden asignar trabajos de mayor dificultad. A pesar de ser una tecnología joven, se han desarrollado herramientas que permiten el uso de mallas dentro de redes de computadores, especialmente en redes LAN. Tal es el caso de Globus [2] y Sun Grid [3], que ofrecen una serie de servicios que permiten utilizar los recursos de una red como si fuera una malla.. Hoy en día, la Universidad de los Andes cuenta con algunos centros de cómputo con grids instalados. Tal es el caso de la sala Waira y Zion, del departamento de Ingeniería de Sistemas y Computación, y las salas del departamento de Física. El enfoque de estas mallas es la investigación y desarrollo de esta tecnología.. 4.

(5) 1. Problemática En el desarrollo y puesta en funcionamiento de aplicaciones dentro de los grids instalados en la Universidad de los Andes, se ha presentado la necesidad de poder disponer de los recursos que componen las mallas en cualquier momento. Más aun, surge el problema de lanzar trabajos a las máquinas sin necesidad de que los usuarios tengan que estar presentes en las salas. En especial, un usuario debería poder trabajar en estos grids desde la comodidad de su casa. Grid Manager se plantea como una aplicación web con la cual un usuario puede administrar, de. manera. remota, los. recursos. que. componen. un. grid.. Específicamente, la aplicación pretende brindar las herramientas necesarias para conocer los equipos con los que el grid cuenta: los que están disponibles, los que no lo están y los que pueden estarlo. Sobre estos equipos, posteriormente, sería posible ejecutar una serie de servicios y aplicaciones, dependiendo del estado en que se encuentren. La idea nace de la necesidad de poder disponer de los recursos de un grid, cuando estos están disponibles, sin tener que configurarlos manualmente. Este documento muestra la forma en que fue desarrollada la aplicación: los requerimientos, el modelo utilizado y su implementación. De igual forma, se describirán las tecnologías utilizadas en el proyecto, y la manera en que fueron desarrolladas.. 5.

(6) 2. Requerimientos Funcionales La aplicación desarrollada ofrece servicios administrativos que permiten a un usuario manipular los recursos de un grid de manera remota. Estos servicios se basaron en los siguientes requerimientos funcionales:. 2.1. R1 – Mostrar información relevante del estado de cada equipo. Un usuario debe poder observar información relevante de cada uno de los computadores que hacen parte del grid. Específicamente, se debe tener información del estado del computador (encendido, apagado, sistema operativo actualmente corriendo, entre otros), host de la máquina y dirección mac de la tarjeta de red.. 2.2. R2 – Encender remotamente un equipo. Cuando un equipo está en estado ‘apagado’, la aplicación debe permitir al usuario encender remotamente la máquina.. 2.3. R3 – Apagar remotamente un equipo. La aplicación debe permitir a un usuario apagar cualquier equipo del grid, siempre y cuando éste no esté siendo usado por algún usuario local.. 2.4. R4 – Reiniciar remotamente un equipo. La aplicación debe permitir a un usuario reiniciar cualquier equipo del grid, siempre y cuando éste no esté siendo usado por algún usuario local.. 2.5. R5 – Verificar porcentaje de uso del procesador de un equipo. Un usuario debe poder verificar el porcentaje de uso de procesador de cada uno de los equipos.. 6.

(7) 2.6. R6 – Verificar porcentaje de uso de memoria de un equipo. Un usuario debe poder verificar el porcentaje de uso de memoria de cada uno de los equipos.. 2.7. R7 – Validar usuarios de la aplicación. La aplicación debe poder verificar que tipo de usuarios pueden acceder a sus servicios.. 7.

(8) 3. Requerimientos no funcionales Hay que tener en cuenta que la aplicación se basa en una arquitectura cliente – servidor. Más aun, se espera que el cliente pueda correr desde cualquier máquina (independiente de su arquitectura), por lo cual se definen los siguientes requerimientos no funcionales:. 3.1. La aplicación cliente debe ser presentada como una página web dinámica. Lo que se espera es que cualquier usuario del sistema pueda acceder fácilmente al GridManager desde un browser, sin necesidad de tener que instalar y configurar el cliente.. 3.2. Se debe desarrollar la aplicación sobre un contenedor J2EE. El uso de un contenedor, en este caso, permitirá manejar otros requerimientos no funcionales del sistema, tales como el ciclo de vida, escalabilidad y seguridad de la aplicación.. 3.3. Almacenamiento de usuarios del sistema en un directorio LDAP. El uso de un directorio ldap permite almacenar información relevante de un usuario, sin la necesidad de agregar al sistema una base de datos, exclusivamente para el manejo de esta información (dado que en un principio no se necesita ninguna base de datos para la aplicación).. 8.

(9) 4. Modelo Para satisfacer los requerimientos no funcionales del sistema, se realizó el análisis teniendo en cuenta que la aplicación se desarrollaría sobre la herramienta JBoss. Igualmente, la validación de usuarios se implementó por medio de un directorio ldap. En un principio, el diagrama de clases es el siguiente:. 4.1. Package grid.model.vo. En este package están aquellos objetos que pueden ser conocidos por cualquier otra clase del modelo. Contiene las siguientes clases:. 9.

(10) 4.1.1 RemoteComputerVO Esta clase encapsula los servicios que deberán ofrecer aquellos computadores que hacen parte del grid. Debe poder almacenar y administrar la información relevante de cada computador. Igualmente, debe permitir modificar los estados del mismo. Su diagrama de clases es el siguiente:. 10.

(11) 4.1.2 GridUserVO Esta clase encapsula la información que se almacena de cada usuario del sistema. Su diagrama de clases es el siguiente:. 4.1.3 LDAPServices Esta clase encapsula los servicios de verificación de usuarios en el directorio LDAP del sistema. Permite obtener todos los usuarios del sistema, al igual que validar el login y password de cada uno de ellos. Su diagrama de clases es el siguiente:. 11.

(12) 4.1.4 GridClusterVO Esta clase administra todos los recursos que pertenecen al grid. Es el encargado de cargar la información de los RemoteComputersVO del sistema, y de invocar los servicios de cada máquina específica. La información inicial de las máquinas (tales como IP y MAC de cada computador) se almacena en un archivo inicial de configuración. Su diagrama de clases es el siguiente:. 4.2. Package grid.model.ejb. En este package se almacenan las clases que implementan los servicios que permiten al contenedor administrar el ciclo de vida de los objetos.. 4.2.1 GridClusterBean Esta clase simplemente implementa los servicios de la interfaz SessionBean, y extiende los servicios de la clase GridClusterVO. Estos son los servicios que le permiten al contenedor administrar el ciclo de vida del módulo.. 12.

(13) 4.3. Package grid.model.interfaces. En este package se almacenan las interfaces de servicios que ofrecen los módulos del sistema. Para el caso específico, contiene las dos interfaces de servicios de la clase GridClusterBean. 4.3.1 GridClusterHome Permite a aquellos que quieran acceder al módulo obtener una instancia de la implementación de los servicios de GridCluster. Su diagrama de clases es el siguiente:. 4.3.2 GridCluster Esta clase contiene todos los servicios ofrecidos por el módulo. Su diagrama de clases es el siguiente:. 13.

(14) 4.4. Package grid.model.web. Este package contiene los servlets que permiten al sistema interactuar vía http con los clientes de la aplicación.. 4.4.1 SignInSevlet Esta clase implementa los servicios de HttpServlet, en los cuales permite a un usuario autenticarse dentro del sistema. Igualmente, contiene las constantes con los nombre de los atributos de una sesión. Su diagrama de clases es el siguiente:. 14.

(15) 4.4.2 ClusterInfoServlet Esta clase implementa los servicios de HttpServlet, con los cuales permite a un usuario invocar los servicios ofrecidos por la interfaz GridCluster. Igualmente, permite obtener la información relevante de todos los computadores del sistema. Su diagrama de clases es el siguiente:. 15.

(16) 5. Diseño En el diseño de la aplicación, se tuvo en cuenta que los objetos que iban a tener mayor responsabilidad en el sistema serían las instancias de la clase RemoteComputerVO. La razón es que es en esta clase donde se deben implementar los servicios que se pueden ejecutar sobre cualquier máquina remota. Los siguientes diagramas de clase están basados en los requerimientos funcionales del sistema.. 5.1. Obtención de la información relevante de cada máquina. En este diagrama se muestra cómo se obtiene la información de las máquinas del grid. Un usuario únicamente interactúa con el sistema a través de las páginas jsp. La información del grid se va a cargar cuando el usuario acceda a la página GridManagerHome.jsp. Al desplegarse ésta página, y cuando se invoca dentro del método POST la acción ‘refreshInfo’, el servlet ClusterInfoServlet obtiene una instancia de la interfaz GridCluster, que le permite obtener la información del cluster. Esta información es retornada al servlet por medio de un arreglo de objetos RemoteComputerVO. Es sobre éstas instancias donde se pueden invocar los servicios de GridManager. En particular, sobre cada máquina se pueden invocar métodos getIp(), getMac(), getOS(), entre otros (esto se representa en el diagrama con el método getInfo()).. 16.

(17) 5.2. Encender, Reiniciar y Apagar remotamente un equipo. Una vez obtenida la información de los RemoteComputerVO del sistema, se pueden invocar los servicios directamente sobre estos objetos. Para el caso del encendido remoto, basta con que el usuario indique sobre cual computador quiere ejecutar el método wakeOnLan(), y el servlet llamará al método desde el objeto correspondiente. En los otros dos casos solo cambia el servicio invocado.. 17.

(18) 5.3. Validar Usuarios. Para éste caso, el usuarios invoca los servicios de validación desde la página SignIn.jsp, a través del método POST. El servlet, al recibir la invocación, llama al método validateUser() de la clase LDAPServices, que devuelve un objeto GridUserVO con la información completa del usuario autenticado. Si se da el caso en que la información suministrada no es correcta, el GridUserVO devuelto es una referencia nula.. 18.

(19) 6. Implementación Para el desarrollo e implementación de la aplicación, fue necesaria una investigación exhaustiva acerca de las tecnologías que permitieran desarrollar los requerimientos propuestos. Más aún, fue necesario definir los estados en los que cada recurso del grid podía estar.. Como se mencionó anteriormente, la aplicación se desarrolló sobre un contenedor de aplicaciones Jboss (específicamente la versión 3.2.7), y por ende, su implementación se hizo sobre el lenguaje java. La aplicación fue probada en el servidor Default de Jboss, y la interfaz gráfica se desarrolló por medio de jsp. No obstante, se requiere de algunas configuraciones previas para que el sistema funcione. Debido a que la aplicación usa conexiones ssh para comunicarse con las máquinas remotas, es necesario instalar en estos equipos servidores que soporten este tipo de conexiones (normalmente en Linux no hay problemas, pero Windows no ofrece un servidor ssh por defecto). En particular, se instaló el software OpenSSH.exe para Windows [4], autorizando las cuentas de administradores para realizar este tipo de conexiones remotas.. Igualmente, es necesario habilitar en Windows la opción de Escritorio remoto. De esta forma, si se da el caso en que la máquina esté iniciada en Windows, sin que haya ningún usuario con sesión, la aplicación puede comunicarse con la máquina sin problemas. Otro aspecto a tener en cuenta es la configuración del firewall activo en cada una de las máquinas. Es necesario que se concedan los permisos necesarios para que las conexiones remotas dentro de la red LAN se puedan establecer sin problemas. Esta configuración depende del tipo de firewall utilizado en las máquinas, por lo que no se hace mayor profundidad en su explicación.. 19.

(20) Para el directorio LDAP del sistema, es necesario instalar también un servidor LDAP en la máquina local donde se corra la aplicación servidor (es decir, donde se corra Jboss y se realice el deployment del programa). Para este caso, se utilizó la aplicación OpenLDAP para Linux [5], cu ya configuración se tratará más adelante. Es importante tener en cuenta que para realizar las comunicaciones ssh desde la aplicación java, se utilizó la librería Ganymed SSH-2 [6]. Esta implementación permite realizar las conexiones con los host remotos de manera más transparente. Por último, los usuarios de la aplicación deben tener permisos de root (en el caso de Linux) o de administrador (en el caso de Windows) para acceder a los servicios ofrecidos por GridManager (esto se debe a que algunas de estas funciones requieren éste tipo de validaciones, no cualquier usuario puede accederlas).. Los resultados son enunciados a continuación.. 6.1. Posibles Estados de los recursos. Una de las herramientas que se quiere implantar para la administración de un grid es poder disponer, en cualquier momento, de aquellas máquinas que no están siendo usadas, para posteriormente poder asignarles trabajo. Para lograrlo, se requiere tener información actualizada del estado en que se encuentran los equipos cuando la aplicación de administración está siendo utilizada. Para llevar a cabo esta función, se han definido los siguientes estados:. 20.

(21) 6.1.1 Offline Un equipo se encuentra en este estado cuando el hardware está apagado. Se entiende, por lo tanto, que el computador no está siendo utilizado. Por lo tanto, el recurso está disponible en su totalidad.. 6.1.2 Online-‘sistema operativo del grid’ Es cuando en una máquina se está corriendo el sistema operativo en el que está instalado el grid. Para el caso específico de la sala Waira, el grid está montado sobre un sistema operativo Linux, por lo que el estado seria ‘Online-Linux’.. 6.1.3 Online-‘otro sistema operativo’ Es cuando en una máquina se está corriendo un sistema operativo en el que no está instalado el grid. Para el caso específico de la sala Waira, el grid no puede ejecutarse cuando la máquina está corriendo el sistema operativo Windows XP.. A estos dos últimos estados se les debe asociar dos subestados: cuando el computador está siendo usado por un usuario local o cuando está completamente libre. Es importante definir estos casos para saber que nivel de disponibilidad tiene el recurso. Si el computador está siendo utilizado de manera local, algunas funciones de la aplicación no podrán ser efectuadas (por ejemplo, reiniciar o apagar el equipo remotamente). Por el contrario, si no hay ningún usuario local, la máquina está disponible en su totalidad.. 6.2. Obtención del estado de un recurso. Para. definir los. estados. de. cada máquina, se utilizan los. procedimientos:. 21. siguientes.

(22) 6.2.1 Ping del Host Dentro de las funciones de Java, específicamente las de la clase InetAddress, el método ‘isReachable(int timeout)’ nos permite hacer ping del host correspondiente. Si el resultado devuelto es false, se asume que el computador remoto está en estado Offline. Por el contrario, si el ping fue exitoso, se debe verificar que sistema operativo está cargado actualmente, y si algún usuario está utilizando el computador localmente.. 6.2.2 Verificación del sistema operativo Sabiendo si el computador está encendido, nos permite realizar conexiones ssh. El problema ahora radica en que tipo de comandos deben ser enviados en estas conexiones. Para saberlo, se necesita primero saber que sistema operativo se está corriendo (Linux o Windows).. En el caso de Linux, el comando que nos devuelve el sistema operativo en curso es ‘uname –a’; en el caso de Windows, el comando es ‘cmd %os%’.. 6.2.3 Verificación de sesiones activas Como se mencionó anteriormente, un subestado posible de un computador encendido es que haya algún usuario local utilizándolo. Para ser más específicos, se define un que una máquina está siendo utilizada cuando hay una sesión activa de un usuario local.. Por lo tanto, antes de definir que tipo de servicios de. GridManager pueden ser ejecutados en una máquina encendida, se debe verificar si hay sesiones activas o no (por ejemplo, no se debería poder apagar un computador si éste está siendo utilizado por alguien más). Para el caso de Windows, no hay comandos por defecto que le permitan a un usuario remoto verificar si hay sesiones activas o no en el sistema. Para solventar esta falencia, Microsoft ofrece las herramientas PsTools [7], que brindan los. 22.

(23) comandos necesarios para este tipo de tareas. Para instalar estos programas basta con descomprimir el archivo de extensión zip dentro de la carpeta ‘system32’ de Windows. Una vez instalado, el comando que nos brinda la información de usuarios con sesiones activas es ‘psloggedon –l –x \\HOST’ (donde Host es la IP de la máquina de la cual se requiere la información). Cuando se obtiene el buffer de resultados, basta con verificar si en alguna de las líneas obtenidas existe una que no contenga la cadena “NT AUTHORITY”, que no sea vacía y que comience con ‘\t’ (un TAB). Para el caso de Linux, e xiste el comando ‘who’.. 6.3. Servicios de GridManager. La aplicación desarrollada ofrece una serie de servicios que se ejecutan sobre recursos remotos, que hacen parte del grid. Estos servicios pueden ser llamados por los usuarios de la aplicación, siempre y cuando la máquina sobre la cual quieren ser ejecutados se encuentre en el estado necesario para hacerlo (estas asociaciones entre estado – servicio se describen en el siguiente numeral).. 6.3.1 Directorio LDAP Como se mencionó anteriormente, la idea es tener un directorio LDAP en la máquina remota donde se va a correr el servidor de la aplicación. En este directorio se almacena la información relevante de los usuarios autorizados. Esta información incluye: •. Nombre del usuario. •. Login de usuario. •. Password de usuario (almacenado con cifrado simple de 4 bytes). •. Tipo de usuario (por ejemplo, estudiante o profesor). •. Proyecto (proyecto actual en el cual trabaja). 23.

(24) La información de usuario debe estar almacenada bajo el cn:’Login’, donde la palabra login debe ser reemplazada por el login de usuario. Por lo tanto, éste debe ser único.. El formato del dn es el siguiente: dn: cn=horus,dc=uniandes,dc=edu,dc=co dc: root description: root DIT objectClass: top objectClass: dcObject objectClass: organization o: root. Para configurar el dn, en la instalación, se tiene como dn base: Dn: cn=horus, dc=uniandes, dc=edu, dc=co. El usuario dn es: Dn: cn=Manager, cn=hours, dc=uniandes, dc=edu,dc=co Password: secret La información de cada uno de los usuarios del sistema se almacena en el directorio de la siguiente manera: dn: cn=LOGIN DE USUARIO, cn=horus,dc=uniandes,dc=edu,dc=co userPassword:: bG9sYQ== (Password representado en 4 bytes) description: Tipo de usuario objectClass: top. 24.

(25) objectClass: person sn: Proyecto Actual en el que trabaja cn: NOMBRE DEL USUARIO. En dado caso que se necesite cambiar algo de esta configuración, es necesario modificar. directamente. en. la. clase. ‘grid.model.vo.LDAPService.java’. las. constantes ‘dn’, ‘userDn’ y ‘rootPw’.. Es importante aclarar que el directorio LDAP es independiente de la aplicación. Es decir, GridManager solo tiene los servicios necesarios para obtener la información de los usuarios registrados en éste directorio, mas es la encargada de configurar y agregar estos usuarios. Para realizar estas tareas, se pueden utilizar otro tipo de aplicaciones (para este caso se utilizó el freeware LDAP Browser\Editor Versión 2.8.2) [8].. 6.3.2 Iniciar Sesión Por otro lado, todo usuario debe iniciar una sesión en el sistema para poder acceder a los demás servicios de GridManager. Una sesión es iniciada cuando un usuario es autenticado dentro del sistema. Para autenticarse, el usuario debe acceder a la página ‘%Jboss_server%\GridManager\SignIn.jsp’, la cual ofrecerá la opción de ingresar el login y password de un usuario.. 25.

(26) Una vez iniciada la sesión, el usuario podrá acceder a los demás servicios de la aplicación. Para el caso específico, los servicios de la clase LDAPService.java permiten autenticar el login y password ingresados. Por otro lado, la sesión es manejada como un objeto HttpSession, y por ende, es manejada en su totalidad por los servlets del sistema.. 6.3.3 Cargar información de los recursos Existe información básica que debe proporcionársele al sistema para que se ejecute correctamente. No obstante, no es lo suficientemente grande para requerir el uso de una base de datos que la almacene. Por esta razón, se decidió almacenar estos datos en un archivo de configuración. Éste se encuentra bajo el directorio ‘/data/Cluster.config’ dentro del path del proyecto. Para que pueda ser cargado correctamente, una vez que se realice el deploy del proyecto dentro de. 26.

(27) Jboss, es necesario que en la clase ‘GridClusterVO.java’, en la constante ‘config’, se ingrese el path completo de ubicación del archivo. La información que contiene este archivo es la siguiente: •. gridSize: en esta variable se almacena el número de computadores que hacen parte del grid. •. numComputersPerRow: en esta. variable se indica el número de. computadores que se quieren mostrar por fila (los computadores son desplegados por filas y columnas). •. BCast: indica la dirección IP con la cual se hace broadcast dentro de la red LAN del grid.. •. HOST: Indica el host de una máquina. •. MAC: Indica la dirección MAC de la tarjeta de red de una máquina. Un ejemplo del archivo es el siguiente: #Archivo de configuración del grid #Numero de computadores que componen el grid gridSize=2 #Numero de computadores por fila numComputersPerRow=1 #Dirección Broadcast Bcast=255.255.255.255 #Lista de Host - Mac's de los computadores del grid HOST=192.168.1.194 MAC=00:40:F4:D6:31:4F. 27.

(28) Hay que aclarar que las variables HOST – MAC de un computador deben ingresarse consecutivamente. De igual manera, cualquier línea que comience con el símbolo ‘#’ será tomada como comentario.. 6.3.4 Encender Remotamente Para resolver el problema de encendido remoto de las máquinas, se aprovechó la herramienta de Wake On LAN (WOL) ofrecida por los computadores de última generación. Ésta tecnología consiste en el envío de un paquete ‘mágico’ dentro de la red LAN en la que se encuentra el computador. La tarjeta de red de la máquina, al reconocer el paquete, envía las señales necesarias para que el computador se encienda [9].. Para poder utilizar WOL, es necesario cumplir los siguientes requisitos: •. Bios y Tarjeta de red compatibles con ésta tecnología. •. Cable WOL que conecta la bios con la tarjeta de red (independiente de la conexión común que hay entre estos dos dispositivos). Ésta conexión brinda a la tarjeta de red un voltaje mínimo para mantenerse encendida, aun cuando la máquina esté apagada.. •. Habilitar dentro de las opciones de la bios el encendido WOL (puede variar dependiendo de la bios de la máquina).. •. Habilitar los paquetes broadcast dentro de la red LAN del grid.. Comúnmente, los computadores de éste milenio ya vienen adaptados para usar esta tecnología. De modo que no hay que preocuparse tanto por las. 28.

(29) configuraciones de hardware. Los dos últimos requisitos son los que realmente interesan. Una vez configurada la máquina, la tarjeta de red estará a la espera de su ‘paquete mágico’. correspondiente. cuando el. computador. esté. apagado,. suspendido o hibernado. Éste paquete consiste en un mensaje (en codificación hexadecimal) que inicia con 6 bytes inicializados en 255 (FFFFFFFFFFFF), seguidos por la MAC de la tarjeta de red repetida 16 veces. Éste mensaje es enviado en un broadcast a toda la red LAN. Cuando el computador está apagado, y la opción WOL está activa, la tarjeta de red verifica en el mensaje recibido el patrón de los 6 bytes (cualquier otro paquete es descartado). Una vez recibido, comprueba si la dirección MAC repetida en el mensaje concuerda con la propia. Si se da esa situación, procede a encender el computador [9]. El siguiente screenshot muestra un ejemplo del ‘paquete mágico’ capturado por el analizador de protocolos Ethereal:. 29.

(30) Como se puede observar, el destino del mensaje es la dirección de broadcast de la LAN. Igualmente, en la codificación Hexadecimal del datagrama, se puede observar que después del Header del mensaje están los 6 bytes inicializados en 255 y seguidamente las 16 repeticiones de la dirección MAC 00:06:5B:E1:9E:5D.. Ésta tecnología funciona muy bien. El problema que surgió posteriormente fue la imposibilidad de elegir remotamente el sistema operativo que se deseaba cargar. La dificultad radica en que aun cuando la tarjeta de red permanece encendida mientras el computador está apagado, ésta no tiene asignada ninguna dirección IP hasta el momento en que algún sistema operativo sea iniciado y cargado. Por lo tanto, si hay más de un sistema operativo instalado en la máquina (como es el caso de las salas de cómputo de sistemas, que tienen instalado tanto Linux como Windows), no es posible decidir desde el GridManager cuál de todos iniciar. Por lo tanto, el bootloader de la máquina iniciará el sistema operativo por defecto.. Para el caso específico de la sala Waira y la sala Zion, el bootloader utilizado localmente para seleccionar los distintos sistemas operativos es el Grub de Linux. El nuevo problema que surge es que el sistema operativo que se carga por default desde el Grub es Windows XP (y no Linux). Por lo tanto, cuando se enciende una máquina por medio de WOL, se cargará por default Windows XP. Lo realmente deseable sería que el computador cargara el sistema operativo en el que se encuentra instalado el Grid (para el caso específico, Linux). Por lo tanto, se buscó suplir ésta necesidad.. Una solución propuesta fue el delegar al servidor la función de almacenar el kernel de los sistemas operativos disponibles, y que en el momento de iniciarse un equipo, el servidor fuera el que decidiera cuál sistema operativo cargar [10]. El problema sería agregar tanta carga funcional al servidor, y reconfigurar todas las máquinas de las salas para que carguen remotamente un kernel.. 30.

(31) Otra alternativa fue seguir iniciando por default Windows XP. Una vez cargado, la idea sería reiniciar el sistema, pero que ahora se pudiera cargar por defecto Linux. Para hacer esto, hay que modificar directamente los archivos de inicio del bootloader. El problema que surge para esta alternativa es la imposibilidad de escribir desde Windows sobre los archivos de inicio de Linux (ya que el grub está instalado en las particiones Linux). Esta solución sería posible si se usara el Bootloader de Windows en vez del grub [11]. Para éste caso, simplemente sería sobrescribir el archivo boot.ini de Windows, cambiando el sistema operativo default según sea la necesidad. La ventaja es que desde Linux si se puede acceder a las particiones de Windows. El único inconveniente que se podría dar es que las particiones de Windows estén en formato NTFS (dado que Linux no trabaja sobre ese formato). Si se da esta situación, habría que crear una partición FAT 32 pequeña (512 MB) en la cual se almacenen los archivos de inicio (entre ellos el b oot.ini), y de esta manera no se tendría ningún problema en editar los archivos de inicio desde Linux.. 6.3.5 Apagar remotamente Lo que se busca con este servicio es que un usuario de GridManager pueda en cualquier momento apagar los equipos del grid (siempre y cuando éstos se encuentren en un estado válido para ser apagados). Para efectuar estas acciones, la aplicación utiliza comandos específicos de cada sistema operativo, que permiten apagar las máquinas. Para ejecutar estos comandos, es necesario tener permisos de root (para Linux) o de administrador (para Windows). En el caso de Linux, el comando utilizado es el siguiente [12]:. poweroff’. 31.

(32) En Windows, el comando utilizado es el siguiente [13]: shutdown –f –s. La opción –f obliga a las aplicaciones que estén corriendo a cerrarse. La opción –s indica que lo que se busca es apagar el computador (no hibernar, ni suspender, ni reiniciar). Ésta opción da un lapso de 30 segundos para que las aplicaciones sean cerradas. Después de este tiempo cierra todos los procesos activos.. 6.3.6 Reiniciar Remotamente Lo que se busca con éste servicio es que un usuario de GridManager pueda reiniciar cualquier equipo que haga parte del grid, siempre y cuando éste esté en un estado válido para ejecutar ese servicio. Al igual que en el apagado remoto, se utilizan comandos específicos de cada sistema operativo para efectuar ésta acción.. Para el caso de Linux, el comando utilizado es el siguiente [12]: shutdown ‘#’ –r En este caso, al comando shutdown se le agrega el parámetro –r, que indica que lo esperado es que se reinicie el sistema. Igualmente, como se hizo en el caso de apagado, el símbolo ‘#’ es reemplazado por 0. En Windows, el comando utilizado es el siguiente [13]:. shutdown –f –r. 32.

(33) Lo que cambia con el comando utilizado para apagar el sistema es la opción –r, en ve z de utilizar la opción –s. Este parámetro indica que lo que se busca es reiniciar el sistema.. 6.3.7 Obtener uso de procesador y memoria Lo que se busca con este servicio es obtener el porcentaje de uso de procesador y memoria de las máquinas. Específicamente, se obtiene esta información para aquellos equipos que estén corriendo el sistema operativo Linux (debido a que el grid solo corre en éstas máquinas). La finalidad de este servicio es que un usuario sepa que carga de trabajo tiene un computador, para que posteriormente pueda decidir si le asigna trabajo o no.. En Linux, el comando utilizado para obtener esta información es el siguiente [12]: ps –aux. La repuesta obtenida de éste comando es la lista de procesos activos en el sistema. Cada línea contiene un proceso distinto, el porcentaje de uso de memoria y el porcentaje de uso de procesador. Lo que se hace simplemente es sumar todos los porcentajes individuales y obtener el valor ponderado.. 6.3.8 Cerrar Sesión Este servicio simplemente cierra la sesión http existente entre el usuario y los servidores de la aplicación. Antes de hacerlo, debe invalidar todos los atributos de sesión, y finalmente redirigir al usuario a la página de inicio (SignIn.jsp).. 33.

(34) 6.4. Servicios activos para cada estado. Es importante, para efectos de la aplicación, definir que servicios pueden ser ejecutados sobre cualquiera de las máquinas del grid. Esto va a depender directamente del estado en el que se encuentre el recurso.. Para el caso de usuarios sin sesión activa, el único servicio al que pueden acceder es el de autenticación de usuarios, que se realiza a través del jsp SingIn.jsp. Una ve z autenticado el usuario, puede acceder a los demás servicios del sistema.. De igual manera, todo usuario que tenga una sesión activa dentro de la aplicación, puede acceder a los servicios de cerrar sesión y actualizar información. Al cerrar sesión, el usuario quedará inhabitado para acceder a los demás servicios del sistema, y solo podrá volver a tener esos privilegios cuando se vuelva a autenticar. Al actualizar la información, se vuelve a verificar el estado de todos los equipos.. 6.4.1 Servicios Estado Offline Para este caso, el único servicio que puede ser ejecutado sobre la máquina remota es el de encendido remoto. No hay forma de realizar ninguna otra operación sobre una máquina si ésta no tiene algún sistema operativo corriendo.. La siguiente imagen muestra un ejemplo de la opción ofrecida para una máquina en estado offline. El computador de identificador 1 se encuentra en estado offline. Por lo tanto, solo se ofrece la opción de encendido.. 34.

(35) 6.4.2 Servicios Estado encendido sin usuarios activos En un computador que se encuentra con un sistema operativo corriendo, y en el cual no hay ningún usuario activo, se pueden ejecutar los servicios de apagar y reiniciar. Se dan estos privilegios dado que no se afectará a ningún usuario que pueda estar usando el computador, ya que estos servicios solo pueden ser detenidos por el mismo usuario que los ejecutó.. La siguiente imagen muestra la lista de opciones que se ofrecen para una máquina en éste estado. Se puede observar que el computador con identificador 1 tiene 2 casillas para elegir si desea apagar o reiniciar el equipo.. 35.

(36) 6.4.3 Servicios Estado encendido con usuarios activos En este caso, el estado del computador no permite ejecutar los servicios de apagar y reiniciar el equipo. La razón es que si hay alguien usando la máquina, no se tienen los permisos necesarios para usarla con libertad. Si se ejecutan éste tipo de servicios, el usuario local podría perder su trabajo. Por lo tanto, se le da prioridad a las sesiones activas frente a las sesiones remotas.. La siguiente imagen muestra que al equipo con identificador 1 no se le da ninguna opción para acceder a los servicios de apagar y reiniciar. Además, se agregar una línea que informa que existe uno o más usuarios activos.. 36.

(37) 37.

(38) Conclusiones El gran logro obtenido en el desarrollo de éste proyecto de grado es la posibilidad de poder administrar los recursos de un grid de manera remota. Específicamente, por medio de GridManager, un usuario puede acceder a una serie de servicios, que le permiten poner a su disposición los computadores del grid, para que puedan ser utilizados y posteriormente asignarles trabajo. Esto responde a la necesidad inicial de poder disponer de los recursos de un grid sin tener que estar presentes para configurarlos.. Sin el uso de herramientas de este tipo, una persona que quisiera utilizar el grid de manera remota (a través de otro tipo de aplicaciones), solo contaría con aquellas máquinas que estuvieran encendidas y corriendo en el sistema operativo Linux. Por medio de esta aplicación, un usuario puede encender, reiniciar o apagar los equipos (siempre y cuando el equipo no esté siendo usado de manera local), teniendo la posibilidad de contar con más computadores para sus tareas. Un ejemplo específico es cuando un usuario quiere, desde su hogar, asignar tareas al grid en horas de la noche. Si las máquinas estuvieran apagadas, no se podría llevar a cabo este tipo de acciones. Pero con el uso de GridManager, el usuario puede encender las máquinas necesarias, y posteriormente apagarlas cuando terminen con sus tareas. Otro aspecto importante es que la aplicación puede ser usada por administradores de redes LAN para controlar el estado de los equipos de manera remota. De ese modo, cuando se desee encender o apagar las máquinas, no es necesario que el administrador esté presente. Podría hacerlo desde cualquier otro sitio. En particular, desde su casa. Por otro lado, el uso de la tecnología Wake On LAN, permitió desarrollar el servicio más relevante de la aplicación: encender una máquina remota. La razón es que. 38.

(39) cuando un equipo está encendido y corriendo algún sistema operativo, es fácil crear una comunicación directa, que facilita a su vez el desarrollo de servicios remotos. En cambio, cuando el computador está apagado, no hay forma de crear una conexión directa, de tal manera que no se podría mandar un estímulo directo a la máquina para que se encendiera. Por esta razón, WOL fue una solución efectiva, ya que a pesar de no tener una conexión directa con el recurso, permite encender máquinas específicas dentro de una red LAN.. No obstante, fue una alternativa que no dio solución a otros requerimientos. En especial, lo que no se pudo lograr en el desarrollo de este proyecto fue elegir remotamente el sistema operativo que se deseaba cargar. Como se mencionó anteriormente, a pesar de que WOL permita encender remotamente la máquina, no brinda alternativas para poder pasar parámetros al bootloader. Por lo tanto, no es posible indicarle al Grub el sistema operativo que se desea cargar.. Las otras alternativas tampoco brindaron mayores alcances. Aunque pueden llegar a ser implementadas, y se planteó brevemente su desarrollo, requiere de muchos cambios en la configuración de las máquinas. En especial, la alternativa más viable fue la de usar el bootloader de Windows en vez del Grub, y crear una partición FAT 32 de unos 512 MB que compartieran ambos sistemas operativos. En esta partición se almacenarían los archivos de inicio. Bastaría con modificar en estos archivos el sistema operativo por defecto, para que al reiniciar el equipo se iniciara otro SO. Dado que GridManager ofrece la opción de reiniciar un equipo remoto, solo faltaría agregar las funciones necesarias para realizar la modificación de éstos archivos. Lamentablemente, esto requiere la reconfiguración de todas las máquinas.. 39.

(40) BIBLIOGRAFÍA 1. Greenfield, J. and Short, K. Software Factories: Assembling applications with patterns, models, frameworks and tools. Pp 8 – 23 2. Globus. Welcome to Globus. [Versión Electrónica] http://www.globus.org/. Visitada 08/01/2007 3. Sun Grid. Welcome to Sun Grid. [Versión Electrónica] http://www.network.com/. Visitada 08/01/2007 4. Open ssh. Servidor gratuito ssh para Windows. [Versión Electrónica] http://freessh.org/. Visitada 03/12/2006 5. OpenLDAP.. Servidor. LDAP. gratuito.. [Versión. Electrónica]. http://www.openldap.org/. Visitada 15/11/2006 6. Ganymed SSH – 2. for Java. Librería para conexiones ssh-2 desde java.. [Versión Electrónica] http://www.ganymed.ethz.ch/ssh2/. Visitada 12/12/2006 7. PsTools. Administración remota para S.O. Windows. [Versión Electrónica] http://www.microsoft.com/technet/sysinternals/utilities/pstools.mspx.. Visitada. 03/01/2007 8. LDAP Browser\Editor versión 2.8.2. Aplicación para administrar servidores LDAP. [Versión Electrónica] http://www-unix.mcs.anl.gov/~gawor/ldap/. Visitada 18/11/2006. 40.

(41) 9. Intel.com. Network Connectivity – Throubleshooting Remote Wake-Up Issues. [Versión Electrónica] http://www.intel.com/support/network/sb/cs-008459.htm. Visitada 24/08/2006. 10. Linux. remote. booting. a. diskless. Computer.. [Versión. Electrónica]. http://www.comptechdoc.org/os/linux/howtos/Howtoremoteboot/index.html. Visitada 14/08/2006. 11. Booting. Linux. from. Windows’. Boot. Manager.. [Versión. Electrónica]. [Versión. Electrónica]. http://www.tprthai.net/bootmgr.htm. Visitada 15/11/2006. 12. Alphabetical. directory. of. Linux. commands.. http://www.linuxdevcenter.com/linux/cmd/. Visitada 13/12/2006. 13. An a–z Index of the Windows NT/XP command line. [Versión Electrónica] http://www.ss64.com/nt/. Visitada 13/12/2006 14. LANStart.. Installation. of. the. Networkcard.. [Versión. Electrónica]. http://www.spettel.de/lanstart/e_installation.html. Visitada 22/08/2006 15. Gentoo ES. WOL (Wake On L AN). [Versión Electrónica] http://www.gentooes.org/node/507. Visitada 22/08/2006 16. Annoyances.org. Getting Wake On LAN to work. [Versión Electrónica] http://www.annoyances.org/exec/show/article04-101. Visitada 23/08/2006. 41.

(42)