ANÁLISIS DE TÉCNICAS DE AJUSTE Y DISTRIBUCIÓN DE CARGAS COMPUTACIONALES EN SISTEMAS MULTIAGENTE

Transcripción

1 XXV Jornadas Automática Ciudad Real, l 8 al 10 septiembre 2004 ANÁLISIS DE TÉCNICAS DE AJUSTE Y DISTRIBUCIÓN DE CARGAS COMPUTACIONALES EN SISTEMAS MULTIAGENTE Diego Ceñal Álvarez (el_kano@hotmail.com) Plaza l Bierzo, Nº6 4ºD, 24010, León, España. Jose Ramón Villar Flecha (diejvf@unileon.es), Angel Alonso Alvarez (dieaaa@unileon.es), Isaías Garcia (dieigr@unileon.es) y Carmen Benavis (diecbc@unileon.es) Área Ingeniería Sistemas y Automática, Departamento Ingeniería Eléctrica y Electrónica, Universidad León, Campus Vegazana s/n León. España. RESUMEN Este trabajo forma parte un proyecto global cuyo objetivo es sarrollar un sistema basado en conocimiento para teoría control. Es un proyecto multidisciplinar, en el que se abarcan temáticas tan dispares como las bases datos o aspectos propios la inteligencia artificial. El objetivo esta parte l trabajo es sarrollar una plataforma multiagente sobre la que pueda correr, forma eficiente, un sistema basado en conocimiento, permitiendo llevar a cabo una distribución las tareas a realizar entre varios equipos, facilitando un balanceo la carga l sistema y, en general, el uso eficiente los recursos disponibles. Palabras Clave: Balanceo Carga, Agentes, OpenMosix, Sistema Distribuidos, Sistemas Multiagente. 1. INTRODUCCIÓN Los Sistemas Basados en Conocimiento (KBS) son una rama la Inteligencia Artificial [1] y, básicamente, se componen una base conocimiento (KB), que refleja la estructura conceptual l dominio, y una serie métodos resolución problemas, usados para cidir y construir las acciones a realizar [8]. La base conocimiento se compone ontologías, que son las especificaciones formales conceptos y métodos propios l dominio, objetos que representan algún tipo elemento real y las relaciones existentes entre todos estos elementos. Toda esta información referente al dominio en cuestión be estar a disposición l sistema. El proyecto CEKB (Control Engineering Knowledge Base), combina todos los aspectos la ingeniería control y la ingeniería conocimiento forma que el objetivo final es generar un sistema basado en conocimiento sobre ingeniería control, el cual queda reflejado en la figura 1. Petición Ontología Conceptos Solucionadores Problemas Sistema Basado en el Conocimiento para INGENIERÍA DE CONTROL Instancias Aplicaciones Cálculo y Visualización Planificación Base Conocimiento Ontología Métodos Otras Bases Conocimiento Figura 1 : Estructura CEKB Respuesta Aprendizaje Automático Otros sensores y actuadores con el mundo real Cabe stacar la base conocimiento que ocupa la posición central y las aplicaciones que hacen uso la misma están distribuidas alredor ella. El sistema recibirá peticiones entrada por medio un modulo que actúa interfaz. El modulo planificador es el encargado solucionar la petición utilizando los métodos y conceptos existentes en la base conocimiento y el resultado será vuelto por otro modulo que actúa interfaz salida. Los métodos utilizados para resolver los problemas que encuentran finidos ntro la base conocimiento, pero para que estos puedan ejecutarse es necesario disponer unas librerías externas, que son las únicas que tienen la capacidad ejecutar dichos métodos. A estas librerías se les llama Solucionadores Problemas. Para llevar a cabo algunas estas operaciones será necesario realizar cálculos complejos, por lo que resulta más apropiado la utilización aplicaciones especificas para estos cálculos, como por ejemplo MATLAB, por lo que el sistema be contar con algún tipo interfaz que le permita comunicarse con estas aplicaciones.

2 Dentro l proyecto CEKB tiene un peso importante una tecnología en auge nominada programación agentes [2], que aunque no influye en el objetivo final l sistema, facilita su sarrollo y da nuevas características muy interesantes para el funcionamiento general l mismo. El uso la tecnología agente tiene el objetivo implementar la comunicación entre cada uno los elementos, los cuales se encontraran dispersos, y la posibilidad realizar balanceo carga ntro los equipos utilizados. El objetivo esta parte l trabajo es sarrollar una plataforma multiagente [12] sobre la que pueda correr, forma eficiente, un sistema basado en conocimiento, permitiendo llevar a cabo una distribución las tareas a realizar entre varios equipos, facilitando un balanceo la carga l sistema y, en general, el uso eficiente los recursos disponibles. En la sección 2 se hablará sobre OpenMosix, plataforma referencia para nuestro sistema. En la sección 3 se dará una visión l sistema sarrollado. En la sección 4 se mostraran las conclusiones extraídas y futuras líneas trabajo. 2. OPENMOSIX Para esta técnica balanceo cargas distribuida vamos a utilizar y adaptar las ias extraídas l proyecto cluster OpenMosix. La justificación esta en que dicho proyecto no es un mero planteamiento teórico, existen actualmente gran cantidad clusters comerciales operativos en todo el mundo basados en esta tecnología en empresas tan importantes como Google. Debido a esto queda claro que es una herramienta suficientemente contrastada y, amás, código libre y con una gran cantidad documentación. 2.1 HISTORIA El proyecto OpenMosix [11] es un fork libre l proyecto Mosix [9]. El proyecto Mosix fue sarrollado por el profesor Amman Barak y su equipo en la Universidad Hebrea Jerusalén entre 1977 y 1979 como parte un proyecto financiado originalmente por el DARPA [3] para crear un cluster máquinas PDP-11/45, usadas por las fuerzas aéreas estados unidos, sobre un sistema operativo Unix 6 Bell Labs. Debido a los buenos resultados obtenidos, el profesor Barak continuó trabajando en este proyecto, naciendo así Mosix como tal, realizando sucesivas migraciones a lo largo los años para adaptar el código a los nuevos equipos. En 1998 se cidió migrar a Linux todo el código Mosix bido a la inminente saparición los sistemas operativos utilizados hasta ese momento y para seguir la tenncia natural existente en esa época. Un año spués esta migración, el profesor Barak se vio obligado a liberar el código Mosix bido a la influencia la licencia GPL bajo la que fue sarrollado el kernel Linux. Esto provocó una gran aceptación por parte la comunidad Linux y comenzaron a llegar aportaciones y colaboraciones sinteresadas para mejorar o parchear Mosix, pero esto no fue l agrado l profesor Barak, el cual en el año 2002 cambió la licencia Mosix retirando el recho modificación l código todos los elementos que le fue posible. En ese momento, un grupo sarrolladores Mosix, lirados por Moshe Bar, tomó la última versión Mosix que se podía mostrar que cumplía la licencia GPL y comenzó el proyecto OpenMosix. A partir este momento, OpenMosix tubo un gran impulso, gracias a la colaboración numerosos programadores que aportaron parches y corrigieron errores en el código, hasta el punto que OpenMosix se ha convertido en un cluster viable y perfectamente funcional para ámbitos profesionales y manteniendo su licencia GPL QUE ES Y COMO FUNCIONA OpenMosix [6] es un conjunto parches l kernel y unas utilidas y bibliotecas área usuario que permiten tener un sistema SSI [7] completo para Linux, por lo cual, en pocas palabras, su objetivo es que los procesos puedan migrar ntro los nodos l cluster Linux para conseguir un mejor aprovechamiento los recursos disponibles, siempre forma transparente al usuario. Los principales aspectos por los que un proceso migra un nodo a otro son: por sobrecarga uso l procesador l nodo origen, se pasan procesos las CPU más sobrecargadas a las que tengan menos carga, y por exceso swap memoria, teniendo por stino migración aquellos nodos que tengan menor uso memoria y, por lo cual, los que minimicen la necesidad swap para los procesos. Todo este se evalúa teniendo en cuenta el coste la migración, para evitar migraciones continuas Ida y Vuelta entre dos máquinas. El molo migración OpenMosix es Fork and Forget, una vez se produce la división un

3 proceso en dos partes, padre e hijo, estos dos elementos podrán ejecutarse en nodos distintos si así se mejora el aprovechamiento general l cluster, sin que esto suponga un problema comunicación entre estas dos partes, puesto que padre e hijo seguirán comunicándose forma local, como si ambos estuviesen en el mismo nodo y es OpenMosix el que se encarga la gestión los mensajes cuando ambas partes no están en el mismo nodo. 2.3 MIGRACIÓN El concepto migración procesos consiste en que un proceso se ejecuta en un nodo diferente al que lo generó. Cuando se produce una migración, en el nodo raíz (en el que se creó en proceso) se siguen realizando las llamadas al kernel y aquellas instrucciones que no puen ejecutarse en este nodo por falta información o recursos, serán transmitidas al nodo ejecución l proceso gracias a las modificaciones que los parches OpenMosix han realizado en el kernel los equipos. El algoritmo equilibrado automático carga es completamente distribuido, cada nodo ci localmente si va a migrar alguno los procesos que esta ejecutando y el stino lo ci cuando el nodo que toma la cisión esta sobrecargado basándose en los datos l uso l cluster recolectados por el propio nodo y almacenados localmente. Esto permite crear un cluster miles equipos sin que exista un punto critico fallo o un cuello botella (punto sobrecarga) para todo el cluster. En el caso la caída un nodo l cluster únicamente se verán afectados los procesos ejecutados y los creados por dicho nodo. La función coste l algoritmo se basa en el uso los recursos l cluster, incluyendo el uso memoria y procesador entre otros parámetros, e intenta maximizar el uso los recursos. Es un algoritmo tipo greedy, por lo cual es muy simple y eficiente, y eso junto con que el algoritmo solo se lanza en un nodo cuando en dicho nodo se ha alcanzado un nivel carga importante, hace que el calculo la migración no sobrecargue más aun el nodo. Cada nodo, forma inpendiente, realiza preguntas a un grupo nodos escogidos forma aleatoria entre todos los nodos l cluster y estos le informan sobre su estado y carga. Con el tiempo, un nodo consigue tener una información base suficiente para por tomar cisiones útiles y razonadas en cuanto a la migración. Como cada nodo solo dispone información un subconjunto nodos l cluster, podría ocurrir que alguna cisión individual no sea la más optima con respecto a todos los nodos disponibles, pero en el aspecto general la toma cisiones si es optima. 3. APLICACIÓN DESARROLLADA 3.1. INTRODUCCIÓN El trabajo realizado ha tomado como base las ias planteadas por el proyecto cluster OpenMosix, aunque aun no se han implementado todas ellas. Como acabamos ver, OpenMosix planteaba un sistema distribuido para el balanceo carga, forma que si un equipo fallase en un momento terminado, solo se viesen afectadas aquellas tareas que hayan sido solicitadas s el dicho nodo y aquellas que, siendo solicitadas por un nodo ajeno, se estuviesen ejecutando en el nodo que ha fallado. Amás, este planteamiento buscaba una fácil escalabilidad, forma que en el momento en que introdujésemos un nuevo equipo formando parte la red existente, por si solo y spués un tiempo relativamente corto, fuese capaz formar parte la red y, por lo cual, capaz también recibir y enviar solicitus ejecución. Los puntos anteriormente planteados, así como los aspectos referidos a un balanceo carga transparente en el sistema, han sido alcanzados por nuestra aplicación. A continuación se presentara una pequeña scripción la plataforma sarrollo, una explicación la aplicación y, más alante, una scripción más exhaustiva dicha aplicación con el planteamiento original OpenMosix JADE Y FIPA Para sarrollar nuestra aplicación utilizaremos una herramienta llamada JADE (Java Agent Developement Framework) [5], la cual esta basada en el estándar FIPA (Fundation for Intelligent Physical Agents) [4]. FIPA es una asociación cuyo objetivo es promocionar el sarrollo las tecnologías agentes inteligentes y, para facilitar este proceso, da unas especificaciones acordadas internacionalmente en las que se finen conceptos y estándares para el sarrollo sistemas multiagente. Se proporciona una arquitectura abstracta para un sistema multiagente, finiendo una plataforma agentes, los lenguajes que utilizan para comunicarse, los protocolos a seguir para realizar dichas comunicaciones, los elementos necesarios para por mantener la plataforma en funcionamiento, etc.

4 Dentro JADE se incluyen dos productos: una plataforma agentes ( acuerdo a lo indicado en el estándar FIPA) y un paquete para el sarrollo agentes en Java. JADE esta codificado en su totalidad en Java, forma que cualquier sarrollador pue sarrollar el código para sus agentes basándose en las librerías proporcionadas por JADE. Dentro una plataforma agentes tenemos los siguientes componentes: AMS (Agent Management System), el agente encargado supervisar el funcionamiento y el control acceso a la plataforma. Solo pue asistir un AMS por plataforma. Es el proveedor l servicio ciclo vida y paginas blancas, guardando un listado con todos los intificadores los agentes que hay en la plataforma junto con la información con respecto a su estado. Los nuevos agentes se registran en el AMS para obtener su intificación, que se llama AID. DF (Directory Facilitator), es el agente proveedor l servicio paginas amarillas la plataforma, que consiste en mantener un registro los diferentes servicios que se ofrecen en la plataforma y que agente los ofrece. ACC (Agent Comunication Channel) es el agente encargado controlar el intercambio mensajes tanto ntro la propia plataforma como con plataformas remotas. Estos agentes generalmente trabajan en segundo plano permitiendo a nuestros agentes realizar diferentes operaciones DESCRIPCIÓN DE LA APLICACIÓN La plataforma sarrollada se basa en tres tipos agentes, que son: Agentes Distribuidores, son los encargados mantener en funcionamiento la plataforma. Deberá existir uno y solo uno en todos los nodos nuestra red y tiene dos tareas generales encomendadas: o Gestionar la información l entorno, cada uno los nodos be almacenar información l estado carga otros nodos (si el número nodos es pequeño, se pregunta a todos, si el número es gran, se pregunta a un subconjunto). Amás esta información be actualizarse forma periódica, puesto que va a utilizarse para terminar cuales son los nodos más capaces. Este proceso tiene dos partes, por un lado, se ben realizar consultas periódicas al resto nodos y por otra se ben contestar todas las consultas recibidas otros nodos. o Decidir la ejecución las tareas, es cir, cuando se quiera ejecutar algo en un nodo, berá enviar una solicitud al agente distribuidor que se esta ejecutando en ese nodo y será este quien que se encargue que la tarea solicitada se ejecute en el mejor lugar posible (que pue ser el nodo local o cualquier otro nodo la plataforma), forma completamente transparente a quien hizo la solicitud. Agentes Tarea, aquellos agentes que saben hacer cosas, es cir, los agentes que disponen l código aquellas tareas que puen ser requeridas ntro la plataforma. No existen limites en cuanto al número o tipo estos agentes en cada una los nodos, pudiendo no haber ninguno. Cada uno estos agentes pue ser capaz ejecutar una o varias tareas, según como haya sido programado. Estos agentes permanecen a la espera las solicitus ejecución los agentes distribuidores tanto su nodo como los otros nodos. Agentes servicio, son los encargados realizar las solicitus ejecución una terminada tarea. Su objetivo es simplemente solicitar al agente distribuidor su nodo la ejecución una tarea y esperar a que el agente distribuidor conteste. Si la respuesta l agente distribuidor es negativa, el agente servicio esperará un tiempo preterminado, y volverá a realizar la solicitud. Como hemos comentado anteriormente, uno los agentes tienes que ejecutar tres tareas diferentes y completamente inpendientes (Realizar las peticiones información, Contestar a las peticiones recibidas y Distribuir las tareas). Para que esto sea posible se utilizan los Behaviours (comportamientos), ofrecidos por JADE, que siguen una lógica muy similar a la los hilos ejecución Java. De esta forma un mismo agente arranca varios comportamientos, lo que da una sensación ejecución paralela dichas

5 Figura2. Mantenimiento la información l entorno. Figura 3: Comunicación completa para la tramitación una solicitud ejecución.

6 aplicaciones. Otra solución podría ser disponer un agente para cada una las acciones, forma que no fuese necesario utilizar los behaviours, pero esta solución no aportaría ventajas ejecución y, sin embargo, se produciría una sobrecarga los recursos la plataforma agentes. Por lo cual es recomendable el uso los comportamientos. En la scripción los agentes se pue observar que los agentes distribuidores y los agentes tarea permanecen a la espera solicitus, actuando forma pasiva y reaccionando únicamente cuando un agente servicio realiza una solicitud, por lo que se podría cir que son los agentes servicio los que ponen en marcha el sistema. En la figura 2 se muestra el proceso comunicación para mantenimiento información l entorno y en la figura 8 se muestra el proceso una solicitud ejecución una tarea. En la figura 3 se puen observar el proceso comunicación completo, con todas las variantes posibles, en el que un agente servicio solicita la ejecución una tarea llamada TAREA X. 4. CONCLUSIONES Y TRABAJOS FUTUROS El sistema presentado en este trabajo es una primera aproximación a la distribución la carga computacional con el uso agentes. Actualmente hay muy pocos trabajos que se centren en este aspecto, y menos aun tal y como se ha planteado esta aplicación, puesto que el objetivo final seria una sistema agentes que funcionase forma equivalente a un cluster SSI. Se ha obtenido un sistema operativo y fácil utilizar y modificar por un sarrollador cualquiera que lo quiera utilizar para ejecutar sus propias tareas. Pero, como ya hemos dicho, esta es una primera fase sobre la que necesitamos realizar futuras modificaciones como son: Realizar las modificaciones que aproximen más aun el resultado al funcionamiento OpenMosix, como son: separar las acciones llevadas a cabo por el Agente Distribuidor forma que se ejecuten en dos agentes, mejorar los filtros mensajes. Evaluar las ventajas o sventajas rivadas modificar la política ejecución prioritaria, sustituyéndola por otra política en la que solo se tome como referencia la carga l equipo en el que se encuentra el agente, inpendientemente que sea local o remoto. Con estos primeros cambios se intentaría mejorar las cotas tiempo l sistema actual, aunque existen ciertos aspectos que son pendientes la plataforma JADE, como es el caso las búsquedas en el DF, las cuales ben asumirse. Una vez realizadas estas modificaciones, las cuales se orientan únicamente a mejorar el funcionamiento l sistema, pasaríamos a introducir nuevas funcionalidas, como por ejemplo, evaluar las cargas cada tarea, forma que a la hora terminar el stino una tarea, se tenga en cuenta el índice carga dicha tarea, o buscar algún método que ampliase la capacidad ejecución las tareas, forma que no se ban ceñir únicamente a código java programado para ese fin. 5. REFERENCIAS [1] Gómez Sanz, J. J., Metodologías para el sarrollo sistemas multi-agente, Departamento Sistemas Informáticos y Programación, Facultad Informática, Universidad Complutense. [2] Gomoluch y Schoroer, Information agents on the move: A survey on load-balancing with mobile agents. Departamento Computación, City University Londres. 2001, 12 Abril. [3] [4] [5] [6] [7] [8] Musen, M. A., Morn Arquitectures for Intelligent Systems: Reusable Ontologies and Problem-Solving Methods In C.G. Chute, Ed., AMIA Annual Symposium, Orlando, FL, 1998, pp [9] Santo Orcero, D., El Proyecto Cluster SSI OpenMosix, [11] Santo Orcero, D., Los Clusters SSI, Todo Linux, no. 23, pp , [12] Stefik, M., Knowledge Systems, Morgan Kaufmann Publishers, Inc., 1995.