Herramienta para la construcción de un cluster y la distribución de carga entre los nodos Rubén A. González García 1, Gabriel Gerónimo Castillo 2 1 Universidad Juárez Autónoma de Tabasco, Av. Universidad s/n, Zona de la Cultura, Villahermosa, Tabasco. México mcruben@nuyoo.utm.mx 2 Universidad Tecnológica de la Mixteca, Carretera a Acatlima Km. 2.5, Huajuapan de León, Oaxaca. México gcgero@nuyoo.utm.mx Resumen. En el presente trabajo se plantea el desarrollo de una herramienta de soporte para clusters basada en la distribución y ejecución remota de procesos. Se describen los diferentes módulos que integran a nuestra herramienta, y la manera de trabajar de cada uno de ellos. Se muestran algunas pruebas que se realizaron con la herramienta que llamamos MicroCluster y las mejoras a realizar. Palabras claves: Cluster, proceso, demonio. 1 Introducción Recientemente, el uso de clusters en aplicaciones de alto rendimiento ha empezado a popularizarse debido a diferentes factores, entre los cuales podemos citar los siguientes: el poder de cómputo de las computadoras personales ha aumentado, mayor velocidad en las redes LAN y la consolidación de aplicaciones y sistemas de código abierto. Para realizar la construcción de un cluster existen diferentes configuraciones, las cuales se diferencian en los siguientes aspectos: tipos de computadoras que conforman los nodos del cluster, sistemas operativo de los nodos, tipo de red y protocolos utilizados, software de soporte para el cluster y aplicaciones. En todos estos aspectos, existe una gran actividad de investigación, especialmente en el desarrollo de software de soporte para clusters y en el desarrollo de aplicaciones. En el aspecto de desarrollo de software de soporte para clusters se encuentran varias categorías, como: bibliotecas de funciones, herramientas de desarrollo, software de administración y modificaciones al kernel. Lo que presentamos en este artículo pertenece a la categoría de software de administración, los cuales permiten al usuario de aplicaciones y administradores de sistemas, configurar la ejecución de aplicaciones y distribución de carga entre los nodos del cluster. Aunque existen en forma libre algunos de estos software tales como OpenMosix [1], Condor [2] y LUI [3], pretendemos iniciar el desarrollo de un software similar, libre y de código abierto. A continuación describiremos como se encuentra implementado dicho software.
2 Desarrollo de la herramienta - MicroCluster La herramienta que llamamos MicroCluster integra varias computadoras conectadas a través de una red IP para formar un cluster con la siguiente funcionalidad: ejecución de procesos no interactivos en máquinas remotas y monitoreo de la carga de trabajo de las computadoras del cluster. Una de las computadoras del cluster desempeña el papel de administrador. Dicho administrador se encarga de recolectar información sobre la carga de trabajo del cluster y de enviar los procesos a las computadoras con menor carga. El administrador puede ser definido explícitamente por el operador del MicroCluster (mediante un archivo de configuración) o puede ser elegido automáticamente al iniciar el cluster. El sistema MicroCluster consta de tres programas (run, rund y monitor) que se describen en las siguientes secciones. 2.1 Ejecución de procesos remotos - run El programa run permite al operador o usuario del cluster, ejecutar procesos de manera remota en cualquier computadora del MicroCluster. El usuario puede especificar el host en el cual se deberá ejecutar el programa. En caso de omisión, el programa run solicitará al demonio administrador (rund) la dirección IP de la computadora con menor carga de trabajo y a esta le solicitará la ejecución del proceso. El algoritmo general del programa run es el siguiente: - Obtiene nombre y parámetros del programa a ejecutar - Obtiene dirección del host remoto (sí es necesario, consulta al administrador rund local) - Establece una conexión con el host (rund) remoto - Envía el archivo del programa a ejecutar - Envía el archivo stdin local - Espera ejecución - Recibe resultados de ejecución y los envía hacia el archivo stdout local - Recibe errores de ejecución y los envía hacia el archivo stderr local 2.2 Demonio del MicroCluster - rund Este programa es el demonio del MicroCluster y debe ejecutarse en cada una de las computadoras que forme el cluster. rund es un programa concurrente con la siguiente estructura: El hilo monitor se encarga de calcular periódicamente (cada segundo) el porcentaje de utilización del CPU local. El hilo monitord se encarga de informar al solicitante (puerto UDP 7000) la carga de trabajo calculada por el hilo monitor, durante el último segundo.
El hilo pedidord se crea solamente en la máquina administradora y es el encargado de solicitar periódicamente la carga de trabajo a cada computadora (a monitord) mediante un broadcast. Este hilo no espera las respuestas de las computadoras, sino que solamente se limita a emitir una solicitud de envío de carga. Antes de enviar una nueva petición, guarda la información recolectada por recolectord y limpia el buffer de recolección. Esto permite detectar todos los hosts activos dentro del MicroCluster y eliminar los hosts inactivos de la lista. El hilo recolectord se ejecuta solamente en la máquina administradora y es el encargado de recolectar (UDP 7001) la información de la carga de trabajo de cada computadora (enviada por monitord). La información recibida se almacena en un buffer de recolección. Por simplicidad, se decidió que el hilo pedidord se creara dentro de monitord, debido que ambos utilizan un socket común creado por monitord. Nuevamente, la combinación de pedidord y recolectord permite al sistema obtener información actualizada sobre la carga de trabajo del cluster, además de evitar el riesgo de mantener en la lista, hosts inactivos o de ignorar hosts activos. Además permite hacer un uso eficiente de la red al reducir al mínimo el número de mensajes. El hilo administradord se ejecuta solamente en la máquina administradora y se encarga de informar (a través del puerto 7002 de UDP) la carga de trabajo de cada computadora del MicroCluster. Según la petición recibida, administradord envía la información de todos los hosts del cluster (para el programa Monitor) o del host más desocupado (para el programa run). En la figura 1 se puede observar la interacción de los submódulos de rund y otros módulos que forman a MicroCluster. Hasta aquí, todas estas funciones se implementaron aprovechando las facilidades ofrecidas por los hilos POSIX. Sin embargo, las funciones siguientes se implementaron por conveniencia mediante la creación de procesos hijos (sin memoria compartida) utilizando la función fork y exec. El proceso de usuario es el programa que el usuario mandó a ejecutar y se crea mediante la llamada a la función exec. Es importante señalar que exec reemplaza al proceso que lo invocó (en consecuencia no regresa el control a este) y por lo tanto es necesario ejecutarlo desde un contexto diferente al proceso rund inicial (rund 0) y no desde un hilo. Cuando rund(0) acepta una conexión (TCP 7000), este crea un proceso hijo rund(1) mediante fork. A partir de ese momento, mientras rund(0) regresa a esperar otra conexión, rund(1) recibe a través de la red, el comando a ejecutar. Además recibe el archivo del programa ejecutable, lo almacena temporalmente en su directorio de trabajo y establece los atributos de ejecución. Posteriormente invoca a la función ejecuta (sigue siendo parte de rund(1)) en la cual se crean las tuberías adecuadas (pipes) para la comunicación bidireccional con el proceso de usuario. Adicionalmente, rund(1) se encarga de recibir a través de la red la información de la entrada estándar (stdin) para el proceso de usuario, la cual fue enviada por el programa run desde la máquina administradora. Al terminar la
ejecución del proceso de usuario, se envían los resultados y los errores (stdout y stderr) producidos durante la ejecución del mismo. 7000 7001 7002 7000 rund (0) monitord administradord rund (1) rund (1) monitor recolectord rund (2) rund (2) pedidord de usuario de usuario Figura 1. Módulos de MicroCluster. La simbología utilizada en la figura 1 se describe en la tabla 1. Símbolo Descripción Flujo de instrucciones (hilo o proceso) Memoria compartida Reemplazo de proceso Creación de un hilo Creación de un proceso hijo Ejecución de un programa Comunicación mediante los archivos stdin, stdout y stderr Comunicación mediante archivos tipo fifo Comunicación TCP (la flecha apunta hacia el módulo que espera) Comunicación UDP (la flecha apunta hacia el módulo que espera) Red IP Tabla 1. Simbología utilizada en la figura 1.
Es necesario ejecutar el proceso de usuario desde un proceso aparte ya que la llamada a exec no devuelve el control, el proceso no puede ser rund(1), ya que este necesita retomar el control al terminar el proceso de usuario, para poder enviar los resultados al usuario (programa run), por lo tanto, es necesario crear un nuevo proceso rund(2) mediante fork. Antes de invocar a exec y perder el control, el proceso rund(2) redirecciona sus archivos de entrada y salida estándar (stdin, stdout y stderr) hacia las tuberías (pipes) que creó rund(1) antes de la llamada a fork. Este redireccionamiento no solo afecta a rund(2) sino también al proceso de usuario. Adicionalmente rund(0) se encarga de leer el archivo de configuración rund.conf, y de decidir de manera coordinada, quien será el administrador en caso de que no se haya especificado alguno explícitamente. Por último, rund(0) borra el archivo correspondiente al programa ejecutado. 2.3 Graficador de carga Monitor Este programa se encarga de graficar la carga de trabajo de cada computadora del MicroCluster. Para ello, Monitor hace una petición a localhost:7002 a través de UDP. Este programa también es un programa concurrente formado por dos clases, la clase main y la clase Monitor. La clase main se ejecuta en un ciclo infinito enviando periódicamente peticiones UDP al administrador, mientras la clase Monitor es un hilo cuyo método run se encarga de recibir la carga de trabajo del MicroCluster, como una colección de paquetes UDP independientes cuyo número es desconocido. 3 Pruebas utilizando MicroCluster Se formó un MicroCluster con 5 computadoras personales con diferentes características y con diferentes versiones de Linux. Las computadoras estaban conectadas mediante una red Ethernet 100 BTX. Además de estas 5 computadoras, en la red había aproximadamente otras 20 computadoras activas (en el mismo segmento). Al ejecutar programas intensivos en cómputo se notó una pequeña variación en los tiempos. Por ejemplo, primos es un programa para calcular los números primos en el rango de 1 a 10,000,000. Mediante el comando: time. /run -h 148.236.62.254 prog/primos, se mandó a ejecutar el programa primos al host remoto 148.236.62.254, desde la máquina administradora del MicroCluster. Dicha ejecución tomó un tiempo total de 18.13 segundos. Al ejecutar el mismo programa primos directamente (sin hacer uso del software MicroCluster) en el host 148.236.62.254, mediante el comando: time primos, este tomó un tiempo total de 17.55 segundos para ejecutarse. Este resultado nos muestra que la sobrecarga de trabajo, en la ejecución remota de un programa mediante el uso de MicroCluster, es sumamente pequeña aún para programas con un tiempo de ejecución relativamente corto. Cabe mencionar que el host 148.236.62.254 es una laptop con procesador Celeron a 700 Mhz con 128 MB de RAM.
También se midió la sobrecarga de trabajo que representa ejecutar los programas rund y Monitor en una máquina administradora y rund en una máquina no administradora. En la tabla 2 se muestra, para diferentes equipos de cómputo, el porcentaje de utilización del CPU por parte de los programas rund y Monitor. Obsérvese que en algunos casos, la sobrecarga de trabajo fue menor al 0.1%. Este porcentaje disminuye conforme aumenta la capacidad de procesamiento del CPU. Procesador % de utilización del CPU al ejecutar rund y Monitor (administradora) % de utilización del CPU al ejecutar únicamente rund Pentium II / 300 MHz 2% al 3% Menos del 0.5% Pentium Pro Dual/200 MHz 1% Menos del 0.1% Celeron / 700 MHz Menos del 1% Menos del 0.1 % Celeron / 1.7 GHz Menos de 0.1% Menos del 0.1 % Tabla 2. Sobrecarga de trabajo en la ejecución de MicroCluster. 4 Conclusiones y trabajos a futuro La demanda de mayor poder de procesamiento por parte de los usuarios de aplicaciones de cómputo intensivo, así como la necesidad de lograr un mejor aprovechamiento de los recursos, ha llevado a una creciente proliferación en el uso de clusters. Frecuentemente, debido a la falta de herramientas estándares apropiadas para todo tipo de aplicaciones y configuraciones de clusters, es necesario que los usuarios tengan que desarrollar por sí mismos sus propias herramientas y aplicaciones. El presente trabajo es una contribución para todas aquellas personas que quieran iniciarse en el desarrollo de software de soporte para clusters. Existen características susceptibles en el software MicroCluster para ser mejoradas, tales como: capacidad para ejecutar programas interactivos, mejorar aprovechamiento del ancho de banda de la red, planificación y despacho de procesos tomando en cuenta no solamente la carga de trabajo sino también la capacidad de procesamiento de los hosts, la memoria disponible, ubicación de datos y programas, y configurar un sistema de archivos compartidos que permita a todos los nodos del cluster tener una visión idéntica del sistema de archivos. Referencias [1] OpenMosix, an Open Source Linux Cluster Project. [online] http://www.openmosix.com/ [2] The Condor Project. [online] http://www.cs.wisc.edu/condor/ [3] R. Ferri., Remote Installation of heterogeneous Linux Clusters using LUI, Sys admin, Vol. 10, No. 4, Abril 2001, pp. 50-57.