El Problema

 

La definición habitual de Sistema Operativo es ``el software que abstrae y multiplexa de forma segura los recursos físicos del sistema'' [158]. Esto no quiere decir que dichos recursos deban estar confinados en un único nodo. ¿Por qué entonces construimos Sistemas Operativos Distribuidos alrededor de núcleos que abstraen y multiplexan sólo recursos locales?

Es cierto que dichos servicios pueden luego distribuirse si utilizamos un kernel centralizado que implemente mecanismos y abstracciones básicas, como viene siendo habitual desde la aparición de sistemas como el kernel V [35, 38]. Incluso es posible hacerlo si utilizamos un sistema monolítico [128]. Pero esto no resuelve el problema de que el sistema no está distribuido en realidad y no está multiplexando transparentemente los recursos locales y remotos.

Una desventaja fundamental de los Sistemas Operativos Distribuidos actuales es su falta de adaptabilidad  debida al suministro de abstracciones alejadas del hardware. Esto provoca una gestión inadecuada e ineficiente de los recursos [98] dado que dicha gestión se efectúa siempre de acuerdo con abstracciones diseñadas para aplicaciones ``típicas'', considerando el comportamiento normal (en el caso medio) de las mismas [85, 116]. Dichas aplicaciones no existen en la realidad, baste citar como ejemplo el comportamiento de alguna de estas aplicaciones ``típicas'' en Entrada/Salida (E/S):

• Editores, compiladores, sistemas de ventanas, procesadores de texto y correctores ortográficos tienen comportamientos muy distintos entre sí: lecturas y escrituras aleatorias, poco frecuentes y de escasa entidad; grandes lecturas y escrituras aleatorias de forma esporádica; lecturas secuenciales y escrituras aleatoria.
• Incluso considerando sólo editores:
  • El editor Emacs tiende a leer y escribir ficheros completos, absorbiendo gran parte de la capacidad del sistema.
  • El editor Vi tiende a utilizar con mesura los recursos del sistema y lee sólo lo que considera estrictamente necesario.
  • El editor Textedit realiza grandes cantidades de E/S para implementar su interfaz gráfico comportándose justo al contrario en el acceso a los ficheros editados.

Claramente, no existe ninguna abstracción que pueda satisfacer de forma óptima tan dispares necesidades.

Además, dado que un SO tradicional está abstrayendo y ocultando los recursos disponibles, el problema no es solucionable: las aplicaciones no pueden emplear abstracciones diseñadas ``a medida'' de tal modo que la gestión de sus recursos sea la mejor posible [151]. Para que pudiesen hacerlo deberían tener disponibles los recursos que el Sistema Operativo les oculta.

Aunque hay diversos enfoques que permiten la construcción de sistemas adaptables [59, 34, 18, 71, 116], esencialmente, todos tratan de permitir que los usuarios puedan utilizar directamente el hardware disponible. En sistemas distribuidos esto provocaría la pérdida de la transparencia, la duplicación de trabajo y problemas de gestión de recursos en la distribución el sistema [52]. Esta es la principal causa de que no existan Sistemas Operativos Distribuidos Adaptables (SODAs).

La mala gestión de recursos en los sistemas distribuidos, debida al intento de suministrar abstracciones de propósito general, se ve claramente en la distinción entre:

• Sistemas distribuidos, que pretenden alcanzar en eficacia a los sistemas centralizados. Su objetivo es meramente permitir el uso de recursos distribuidos con la simplicidad de los sistemas centralizados y la misma eficiencia.
• Sistemas paralelos, que utilizan la distribución de los recursos para superar en eficiencia (mediante el empleo de paralelismo) a los sistemas centralizados.

Puede apreciarse que el énfasis de los primeros en el suministro de abstracciones de propósito general obstaculiza, la mayoría de las veces, a aquellas aplicaciones que desean extraer el paralelismo existente en la red. Las aplicaciones paralelas habitualmente utilizan abstracciones ``a medida'' diseñadas para el aprovechamiento del paralelismo y estas abstracciones no tienen cabida en sistemas distribuidos que prentenden, sencillamente, ofrecer el equivalente a un sistema centralizado que operase en un conjunto de nodos.

Lo que es más, el uso de núcleos centralizados para realizar Sistemas Operativos Distribuidos hace que las abstracciones suministradas (al margen de su eficiencia) no sean adecuadas para las aplicaciones distribuidas; véanse por ejemplo [104, 112, 65, 168]. Otra prueba de esta observación es el uso de enfoques similares en la construcción de aplicaciones distribuidas tanto en SSOO distribuidos basados en kernel como en sistemas monolíticos centralizados [123, 145, 79].

Los emuladores de Sistemas Operativos que ejecutan sobre kernels centralizados [51] --los cuales han sido diseñados supuestamente para distribuir servicios-- no son una excepción y son incapaces de utilizar más de una máquina a no ser que estén programados explícitamente para tal fin. A modo de ejemplo basta citar el emulador del SO Linux desarrollado por la OSF (Open Software Foundation) para ejecutar sobre el kernel Mach. Dicho kernel se considera a menudo un sistema distribuido, incorpora gestión de memoria distribuida y es capaz de operar ``transparentemente'' sobre una red de nodos. Sorprendentemente, el emulador de Linux es incapaz de aprovechar la distribución de recursos ofrecida por Mach. Algo debe fallar en el modelo de distribución, ya clásico, empleado por Mach: un kernel que gestiona recursos locales sobre el que realizar servicios distribuidos.

El problema expuesto, cuya raíz está en el uso de núcleos centralizados [20] y no adaptables para la realización de un sistema distribuido, podría concretarse aún mas en estos tres puntos:

• La realización de abstracciones distribuidas sobre abstracciones centralizadas (habitualmente) proporcionadas por el núcleo. Esto conduce a la re-implementación parcial o total de los servicios ya suministrados por el sistema para conseguir la distribución de los mismos. Así, es típico implementar un modelo distribuido de procesos usando otro centralizado suministrado por el núcleo [19]. Si éste último estuviese distribuido dicha repetición no sería necesaria, con el consiguiente incremento en eficiencia y simplicidad. La consecuencia es que las aplicaciones que utilizan la distribución de un modo diferente al impuesto por el sistema se ven dañadas. ¿Cuantos Sistemas Operativos Distribuidos pueden utilizarse como Sistemas Paralelos?
• Las abstracciones del núcleo son pesadas, ocultan y simplifican demasiado el hardware y están alejadas del mismo. Esto, que aparentemente parece ventajoso, empeora la fiabilidad, la flexibilidad y el rendimiento del sistema tal y como se dice en [59]. El uso de otro nivel más de abstracción (para distribuir servicios) sólo empeora la situación. En muchos casos, abstracciones de poco nivel de abstracción se implementan sobre otras de más alto nivel. Los sistemas de memoria distribuía compartida (DSMs) [97] son un claro ejemplo de ello. A este fenómeno lo denominamos inversión de abstracciones.  No se trata de que las aplicaciones no utilicen abstracciones, se trata de que el SO no debe imponer las suyas ¡sean adecuadas o no!
• El compromiso entre adaptabilidad y transparencia en la distribución que se introduce, de modo artificial al utilizar un núcleo centralizado. Dado que el nivel inferior (el núcleo) no mantiene la transparencia en la distribución (es centralizado) y que la transparencia de distribución debe ofrecerse en un nivel superior, si el usuario adapta el sistema (obviando con ello el nivel superior) puede perder parte o toda la transparencia.

  Lo opuesto también sucede, para mantener la transparencia en la distribución del sistema es preciso sacrificar su adaptabilidad en gran medida, dejando inflexibles aquellas partes esenciales para la distribución del mismo (imponiendo los protocolos y algoritmos empleados para distribuir los servicios). Así pues aparece un compromiso, artificialmente, entre ambos aspectos.

  Basta considerar que la transparencia y el suministro de servicios distribuidos lo suministran componentes externos al núcleo: si estos se pueden reemplazar se puede perder la transparencia y la distribución del sistema, si no se pueden reemplazar se pierde en adaptabilidad (hay más servicios ``impuestos'').