Programando para una Grid

En anteriores posts, comenté sobre los proyectos AjMessages y AjAgents:

AjMessages- hacia un procesador de mensajes

Agentes usando Concurrency and Coordination Runtime (CCR)

Una de las capacidades que tiene AjMessages es comunicar distintas instancias del programa, que pueden ejecutar en diferentes máquinas servidoras. Se le pueden enviar mensajes de configuración dinámica, lo que permite que a cada máquina se le pueda dar un trabajo distinto. También puede configurarse para que una acción (elemento mínimo direccionable dentro de una aplicación AjMessages) pueda ser atendida en distintas máquinas. AjAgents apunta a que también en algún momento tenga agentes distribuidos, pero por ahora es una aplicación local.

AjMessages se podría distribuir de forma que un servidor pueda controlar otras instancias del sistema:

Quisiera enumerar aquí algunas de los escenarios de uso de un sistema que pueda ejecutar en una grilla de servidores, lo que se llama Grid Computing. Como toda “buzzword” tecnológica, puede tener un alcance amplio, pero tratemos de definirla.

Según el excelente artículo introductorio de la gente de IBM:

New to Grid Computing

Grid Computing permite unir un pool de servidores, sistemas de almacenamiento, y redes, en un gran sistema único, de manera que podamos manejar todos esos recursos múltiples a una tarea. Para el usuario, o la aplicación, el sistema aparece como un gran sistema único de computación.

En el caso de AjMessage, siguiendo las ideas de Fabriq, ese efecto se consigue porque los distintos servidores ejecutan una o varias aplicaciones, y sus acciones, de manera transparente.

El concepto de Grid Computing permite obtener mayor capacidad de procesamiento, sin necesidad de tener un gran sistema de hardware o software, sino apelando a repartir la carga y distribuyendo la tarea entre máquinas de línea. Dependiendo del sistema que organice esa distribución, podemos agregar más máquinas, obteniendo mejores resultados, sin necesidad de cambiar la aplicación.

Imaginen que podemos tener un conjunto de servidores, formando una grilla, y brindar ese conjunto a los usuarios que lo necesiten, para en algún momento resolver alguna tarea. Me imagino un Grid as a Service, que seguramente alguien ya está implementando.

Pero concentrémonos hoy en el tema: ¿qué casos de uso, escenarios, podemos imaginar para usar una grid?

He aquí la lista que estuve confeccionando:

- Resolución de algoritmos genéticos: Un problema que tal vez no tenga un algoritmo normal de resolución, o cuya complejidad crezca con su tamaño de forma exponencial, puede llegar a ser un reto siguiendo procedimientos tradicionales. Con algoritmos genéticos, podemos ir probando soluciones parciales, y mediante cambio y selección, ir descubriendo mejores soluciones. Es claro que eso se puede hacer en paralelo, siendo ideal para ser dado como tarea a una grid. Me gustaría procesar algo como lo de http://www.darwinathome.org.

- Búsqueda en árbol: en muchos problemas de inteligencia artificial, es necesario explorar ramas en un árbol de búsqueda. Uno de los casos donde se aplica, es en el análisis de jugadas de un juego, pero también en decisiones de negocio y planeamiento. Me imagino una grilla colaborando en la decisión de la próxima jugada en un juego de Go, uno de los problemas difíciles de la inteligencia artificial actual, ver ….)

- Araña e indexador en la web: la tarea de examinar un sitio, tomar el contenidos de sus páginas, analizarlas, detectar enlaces, y seguir explorando a partir de ellos, es una tarea que bien puede ser repartida. Mientras un nodo consigue el contenido de otra página, va generando tareas para otros nodos, como analizar las páginas enlazadas desde la actual en proceso.

- Trabajo en lote: podría darse a una red el trabajo de procesar gran cantidad de información que sea “partible”, desde transformaciones de una tabla de base de datos, hasta análisis de logs para generar estadísticas. Si la entrada es divisible, el proceso de cada parte puede ser enviado a un nodo distinto. Por ejemplo, un nodo se puede ocupar de transformar los datos de una tabla de transacciones, pero sólo los de enero, mientras que otro se ocupa de procesar los de otro mes

- Distribución de listas de correo electrónico: Un caso típico, si somos una empresa que brinda este servicio, al llegar un correo electrónico destinado a una lista que mantenemos, delegamos el envío de cada email en particular, con personalización incluida por ejemplo, a nodos de la grilla.

- Procesamiento de mensajes: Podemos necesitar recibir mensajes XML, y aplicarle transformaciones, o en base a su contenido, derivarlos a un proceso u otro. Las transformaciones y controles se los podemos deriva a nodos de la grilla. Si aumenta el caudal de mensajes entrantes, simplemente aumentamos la cantidad de nodos de procesamiento.

- Ejecución de un workflow: Siguiendo con la generalización, podemos diseñar un flujo de trabajo, cada uno de sus pasos puede ejecutarse en nodos diferentes. Habrá nodos que puedan ejecutar más de un paso, y habrá pasos de toma de decisiones. Me imagino como caso concreto, la ejecución de todos los pasos ante un nuevo tenant, en un sistema encargado de provisioning de un sistema brindado como Software as a Service.

- Map Reduce: Es un modelo de programación para procesar grandes conjuntos de datos. Se especifica una función Map que procesa un par clave/valor de entrada, genera pares clave/valor intermedios, en general varios. Hay otra función Reduce que se aplica a todos los pares clave/valor intermedios que compartan la misma clave. Por ejemplo, una función Map puede recibir un documento a procesar, genera pares palabra/documento por cada palabra relevante que encuentre, y la función Reduce toma esos pares de una misma palabra, para generar una lista de documentos que contengan a esa palabra. Para una explicación más detallada, ver un “paper” de Google Labs MapReduce: Simplified Data Processing on Large Clusters.

Creo que hay varias implementaciones de estos escenarios en grillas y otras soluciones. Me gustaría armar una prueba de concepto, usando el AjMessages o similar como base.

Cambiando la óptica, se puede pensar en exponer la grilla con uno o varios web services, e implementar alguna forma de poder “sembrar” trabajos desde otros sistemas en la grilla. Se me ocurre sembrar:

- Assemblies completos, e invocación de algunos métodos en clases y objetos a determinar.

- Programas en lenguajes de scripting, controlados por razones de seguridad

- Agentes, que pueden consistir en assemblies o en código para una máquina virtual de agentes

- Programas escritos en DSLs Domain Specific Language, uno o varios lenguajes que algunos nodos de la grilla entiendan.

Semejante grilla se puede brindar como servicio a otros sistemas. Surge el concepto de Grid as a Service, el alquiler de su consumo, el control del nivel de servicio, y demás, que algún software de control deberá proveer.

Ya escribiré en particular sobre Grid Computing, por ahora puede consultar el ya mencionado artículo de IBM:

New to Grid Computing

y una interesante implementación de código abierto en Java:

GridGain

(El gráfico del comienzo de este artículo está “inspirado” en uno de GridGain, pero los nodos se pueden comunicar entre sí, y repartir su trabajo, siguiendo la indepedencia de localización de cada acción en AjMessage).

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/

This entry was posted in 1389, 3282, 3463, 6149. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>