Uno de los principales problemas que trae aparejada la implementación de la computación grid es la forma en que se administrarán los recursos que son parte de su infraestructura.
Los recursos que utiliza la computación grid se dividen en:
- Recursos que forman parte de la infraestructura, tales como recursos de hardware, de software y de red.
- Recursos que forman parte de los requerimientos; por ejemplo, el tiempo que se dispone de los recursos de infraestructura, los datos requeridos para un proceso dado, etc.
Por ser un sistema de cómputo distribuido, la computación grid presenta problemas típicos de éstos, por ejemplo a la hora de acceder a los recursos de cómputos y a los de red. Como se trata de un sistema dinámico los recursos cambian, y por lo tanto se deben utilizar sistemas que se encarguen de buscar recursos disponibles. De la misma forma en que se pueden agregar nodos que aporten recursos, más tarde pueden desaparecer, reduciéndose los recursos que aportaban y el software que pudieran tener. También puede haber pérdida de recursos por una falla en las comunicaciones.
Para optimizar las infraestructuras distribuidas que forman el grid y facilitar su utilización, surge la necesidad de una arquitectura global que se encargue de prestar los servicios de asignación y planificación de recursos. Un ejemplo de esto es el proyecto CrossGrid que está orientado a aplicaciones paralelas e interactivas.
Este proyecto grid se centra en la utilización de un middleware que tiene la tarea de planificar y seleccionar eficientemente los recursos. A tal efecto cuenta con un Resource Broker como entidad principal, que presta servicios para la ejecución de trabajos secuenciales. Cuando un usuario envíe un trabajo éste será el encargado de buscar y seleccionar los recursos necesarios.
Para dar respaldo en el control de aplicaciones paralelas interactivas se cuenta con extensiones de los servicios prestados por el Resource Broker. Una de estas extensiones es el Scheduling Agent, una extensión de la funcionalidad que proporciona el Resource Broker como punto de acceso al Grid para el usuario y capaz gestionar los recursos y hacer que los procesos se ejecuten de manera transparente.
En esta arquitectura, los recursos disponibles se identifican como nodos de computación. Estos nodos representan una granja local compuesta por diferentes nodos de trabajo. También existen nodos de almacenamiento desde donde se tendrá acceso a los datos.
Cuando se debe realizar un trabajo, el encargado de verificar que recursos están disponibles es el Resource Selector. La asignación de dichos recursos dependerá si se trata de un trabajo secuencial o paralelo. Si se trata de un trabajo secuencial se deberá ejecutar en una única granja y requerirá un solo nodo de trabajo o CPU. A tal efecto existirá una lista de posibles granjas que podrían realizar el trabajo, estando ordenadas según algunas preferencias (tiempo ocioso de CPU, memoria, etc.). Un trabajo que requiera procesamiento paralelo necesitará varias CPUs y habrá que tener en cuenta que primero se tratarán de seleccionar granjas con todos sus procesadores libres, para evitar tener que establecer una comunicación entre clusters y sufrir la latencia producida por sus comunicaciones. Luego se intentará formar grupos de granjas que reúnan el número de CPUs libres requeridas. Y por último se tendrá un ordenamiento de grupos de menor a mayor cantidad de granjas diferentes y para los que igualen en elementos se utilizará una función de ponderación de sus componentes.
Un problema que surge de la utilización de estas listas de recursos es que puede ocurrir que no se encuentren actualizadas completamente en tiempo real, y puede darse el caso en que el Resource Broker o el Scheduling Agent considere una CPU como libre cuando realmente esté ocupada. Para evitar esto se trabaja con un método de reserva locales temporales. Una vez decidido a qué grupo se asignarán esos recursos, se los reserva por un espacio de tiempo y no serán tenidos en cuenta para trabajos siguientes.
También se utiliza el concepto de prioridades que permite que una aplicación se ejecute antes que otra. En el caso en que todos los recursos estén ocupados, se podrá decidir qué tarea será suspendida temporalmente para dar paso a otra de mayor prioridad.
Una vez realizadas todas las consideraciones sobre los recursos y prioridades se debe permitir la ejecución del trabajo. El encargado de enviar los ejecutables de forma confiable es el Application Launcher, que hará la distribución a todos los recursos seleccionados que se encuentren implicados en la realización del trabajo.
Hasta aquí se ha dado una aproximación de cómo interactúan los distintos componentes del grid para que un paquete de procesamiento enviado por un usuario se resuelva de la forma más eficiente y transparente posible.