DIETA

DIET es un software para computación en malla . Como middleware , DIET se sitúa entre el sistema operativo (que gestiona los detalles del hardware ) y el software de aplicación (que se ocupa de la tarea computacional específica). DIET se creó en el año 2000. ^{[ 1 ]} Fue diseñado para computación de alto rendimiento. Actualmente, su desarrollo corre a cargo de INRIA , la École Normale Supérieure de Lyon , el CNRS , la Universidad Claude Bernard Lyon 1 y SysFera. Es software de código abierto publicado bajo la licencia CeCILL .

Al igual que NetSolve/GridSolve y Ninf, DIET cumple con el estándar GridRPC del Open Grid Forum . ^{[ 2 ]}

El objetivo del proyecto DIET es desarrollar un conjunto de herramientas para construir servidores de computación. Los recursos distribuidos se gestionan de forma transparente mediante el middleware. Puede funcionar con estaciones de trabajo, clústeres , redes distribuidas y nubes .

DIET se utiliza para gestionar la red Décrypthon instalada por IBM en seis universidades francesas ( Burdeos 1 , Lille 1 , París 6 , ENS Lyon, Crihan en Rouen, Orsay ).

Por lo general, los entornos GridRPC constan de cinco componentes diferentes: clientes que envían problemas a los servidores, servidores que resuelven los problemas enviados por los clientes, una base de datos que contiene información sobre los recursos de software y hardware, un planificador que elige un servidor apropiado en función del problema enviado y la información contenida en la base de datos, y monitores que obtienen información sobre el estado de los recursos computacionales.

La arquitectura de DIET sigue un diseño diferente. Está compuesta por:

1. Un cliente es la aplicación que utiliza DIET para resolver problemas. Los clientes pueden conectarse a DIET desde una página web, mediante una API o a través de un programa compilado.
2. Un Agente Maestro (AM) recibe solicitudes de computación de los clientes. El AM recopila las capacidades de computación de los servidores y selecciona uno según criterios de programación. La referencia del servidor seleccionado se devuelve al cliente. Un cliente puede conectarse a un AM mediante un servidor de nombres específico o una página web que almacena las ubicaciones de los distintos AM.
3. Un agente local (AL) se encarga de transmitir solicitudes e información entre los agentes móviles (AM) y los servidores. La información almacenada en un AL consiste en la lista de solicitudes y, para cada uno de sus subárboles, el número de servidores que pueden resolver un problema determinado e información sobre los datos distribuidos en dicho subárbol. Dependiendo de la topología de red subyacente, se puede implementar una jerarquía de AL entre un AM y los servidores.
4. Un demonio de servidor (SeD) es el punto de entrada de un servidor de computación. Administra un procesador o un clúster. La información almacenada en un SeD es la lista de datos disponibles en un servidor (posiblemente con su distribución y la forma de acceder a ellos), la lista de problemas que se pueden resolver en él y toda la información relativa a su carga (por ejemplo, capacidad de CPU, memoria disponible).

Se desarrollaron dos enfoques:

• La Universidad de Franche-Comté desarrolló una extensión multi-MA . Estos agentes maestros están conectados mediante un grafo de comunicación. Varias plataformas DIET se comparten interconectando sus respectivos agentes maestros (MA). Los clientes solicitan los SeD disponibles a su MA como de costumbre. Si el MA encuentra un SeD disponible que pueda resolver el problema, devuelve su referencia al cliente. Si no encuentra un SeD, reenvía la solicitud a otros MA, quienes a su vez pueden reenviarla a otros, y así sucesivamente. Cuando un MA encuentra un SeD que puede resolver la solicitud del cliente, devuelve su referencia al MA del cliente, quien a su vez devuelve la referencia al cliente. El cliente puede entonces usar ese SeD para resolver su problema.
• También se diseñó una extensión P2P Multi-MA llamada DIET_j. La agregación de diferentes jerarquías DIET independientes (una arquitectura multijerárquica) podía gestionarse mediante el paradigma P2P. Este enfoque se basaba en la caja de herramientas JXTA - J2SE para el descubrimiento y la conexión bajo demanda de MA. Este proyecto ya no recibe mantenimiento.

Para la gestión del flujo de trabajo, DIET utiliza una entidad adicional llamada MA DAG . Esta entidad puede funcionar en dos modos: uno en el que define la programación completa del flujo de trabajo (ordenación y asignación) y otro en el que define únicamente la ordenación para su ejecución. La asignación se realiza posteriormente por el cliente, quien utiliza el Agente Maestro para localizar el servidor donde deben ejecutarse los servicios del flujo de trabajo.

DIET proporciona cierto grado de control sobre el subsistema de planificación mediante planificadores enchufables. ^{[ 3 ]} Cuando una solicitud de servicio de una aplicación llega a un SeD, este crea un vector de estimación de rendimiento, una colección de valores de estimación de rendimiento pertinentes al proceso de planificación de dicha aplicación. Los valores que se almacenan en esta estructura pueden ser valores proporcionados por CoRI (Colectores de Información de Recursos) o valores personalizados generados por el propio SeD. El diseño del subsistema del vector de estimación es modular.

CoRI genera un conjunto básico de valores de estimación de rendimiento que se almacenan en el vector de estimación y se identifican mediante etiquetas definidas por el sistema. Información estática, como el número de núcleos, la memoria total, el número de bogomips y la velocidad del disco duro, etc., así como información dinámica, como el tiempo previsto para resolver un problema en el recurso dado y la carga media de la CPU, se transfiere del demonio del servidor al agente planificador para proporcionar información pertinente para una mejor planificación. Como se mencionó anteriormente, estos datos se utilizan en correlación con la posibilidad de planificación basada en la aplicación en DIET: el demonio del servidor, que comprende mejor las necesidades de la aplicación, puede solicitar una planificación específica basándose en la información almacenada en este vector.

En DIET se han integrado tres gestores de datos diferentes:

1. DTM de la Universidad de Franche-Comté (no vigente);
2. JuxMEM de IRISA (no mantenido); ^{[ 4 ]}
3. DAGDA de la Escuela Normal Superior de Lyon .

Los recursos paralelos suelen ser accesibles mediante un LRMS (Sistema de Gestión de Recursos Locales), también conocido como sistema de procesamiento por lotes. DIET proporciona una interfaz con varios LRMS existentes para ejecutar trabajos: LoadLeveler (en recursos de IBM), OpenPBS (una bifurcación del conocido sistema PBS ) y OAR (el planificador de lotes utilizado por la red de investigación Grid'5000 , desarrollado por IMAG en Grenoble). La mayoría de los trabajos enviados son trabajos paralelos, codificados según el estándar MPI con una instanciación como MPICH o LAM.

En 2009 se creó una extensión en la nube para DIET. ^{[ 5 ]} De este modo, DIET puede acceder a los recursos de la nube a través de dos proveedores de nube existentes:

1. Eucalyptus , que es un software de código abierto desarrollado por la Universidad de California, Santa Bárbara .
2. Amazon Elastic Compute Cloud , que es un software comercial que forma parte de los servicios de computación en la nube de Amazon.com .

• Sitio web del proyecto Décrypthon
• Sitio web de DIETA
• Sitio web de SysFera