Distribución de recursos

 

Cada aplicación considera el nodo local como una cache de los recursos disponibles en todo el sistema distribuido. En el caso de aplicaciones centralizadas, éstas se limitan a utilizar dicha cache ignorando la ubicación de los recursos (pensando que son locales). En cambio, las distribuidas pueden solicitar la asignación de recursos en las ubicaciones que deseen y controlar la revocación de tal modo que se mantengan en el nodo local (en la cache) los recursos convenientes (revocando primero aquellos recursos que sea más barato traer al nodo local, y no aquellos que sea costoso volver a obtener debido a su ubicación u otros factores). En este sentido es crucial que el kernel permita a las aplicaciones escoger las unidades de recurso que han de revocarse, de otro modo el sistema escogería él mismo las unidades a revocar y ello sin tener una idea exacta de para qué se emplea cada una de ellas.

Sorprendentemente, en un DAMN, no hay un único modelo de distribución de recursos. El kernel permite que peticiones locales al sistema puedan operar con recursos remotos, eso es todo lo que hace.

Por un lado, una aplicación centralizada se puede distribuir ``automáticamente'' interponiendo entre ella y el sistema un algoritmo distribuido de asignación y revocación de recursos. De este modo la distribución será como sigue:

• Ante una petición de recursos, el algoritmo de asignación puede solicitar recursos remotos (o locales) al kernel.
• La aplicación realizará peticiones al sistema empleando dichos recursos de manera transparente. Sean éstos locales o remotos, el kernel atenderá las peticiones.
• Ante una eventual revocación, el algoritmo de revocación empleado puede optar por eliminar primero los recursos que sean mas ``baratos'' en términos de posición y uso.

Por otro lado, una aplicación distribuida puede emplear algoritmos específicos de asignación y revocación sin necesidad de conformarse con un algoritmo general que funcione bien en el caso medio.

Un posible modelo para implementar estos algoritmos de asignación y revocación podría ser el campo computacional [163], donde las relaciones entre distintos objetos se tienen en cuenta para crear, destruir y migrar objetos.

Por último, conviene dejar claro que en un DAMN no sólo se distribuyen las IPCs, esto es, no sólo se permiten interacciones entre elementos en distintos nodos. Para cualquier servicio del sistema, la operación se procesa en el nodo local tanto como sea posible. Cuando el sistema ve que el recurso es remoto es la propia implementación del servicio la que contacta con el nodo remoto usando protocolos específicos de cada aplicación (esto es, realizando una up-call). Esto no es lo mismo que emplear una IPC distribuida que alcanza un núcleo remoto sin que el local se entere de ello. Si se distribuyen sólo las IPCs podemos tener problemas en el uso de referencias a memoria de usuario en las llamadas al sistema (una referencia local no es válida en el nodo remoto). Estas pueden ocasionar mensajes extra en la red o el envió de datos innecesarios.

A modo de ejemplo, la figura 2.5 muestra (a) cómo las aplicaciones utilizan la distribución del sistema en kernels centralizados convencionales con IPC distribuida (como en el caso de Mach con un netmsgserver que extiende la IPC de Mach a la red) y (b) cómo pueden emplear su propia distribución en un DAMN.

  
Figure: Distribución del sistema en kernels (a) y DAMNs (b).

En la figura se aprecian varios procesos de usuario (círculos) que efectúan llamadas a servicios del sistema (línea continua) y a servicios de un proceso remoto (línea discontinua). En el caso de un kernel tradicional todos los procesos de usuario se ven obligados a utilizar un mismo protocolo de transporte. En un DAMN cada aplicación puede utilizar su propio transporte (un servicio de datagramas, uno orientado a conexión, con o sin cifrado, etc.).

Lo que es más, en el caso de la llamada al sistema, un kernel tradicional no permite llamadas al sistema desde otros nodos. Es el propio kernel el que, imponiendo su modelo de distribución, utiliza el sistema de transporte para permitir que sus abstracciones utilicen recursos remotos (como denota la separación en varios tramos del camino de la llamada al sistema en la figura). En un DAMN el sistema se limita a encaminar aquellas peticiones dirigidas a recursos remotos al servidor especificado por la aplicación involucrada. Esto afecta tanto a las llamadas a servicios del sistema como a los mensajes de aplicación dirigidos a otros procesos de usuario.