Amoeba
| ||||
Sistema operativo Amoeba. Es un SO distribuido simple y flexible. En dicho sistema el kernel se limita a suministrar ciertos servicios básicos y el resto de funcionalidad está implementado mediante servidores que ejecutan como tareas de usuario. Los servicios suministrados por el kernel incluyen threads, segmentos de memoria, mecanismos de IPC (RPCs y mensajes) y E/S . Podemos decir que fue un sistema innovador y, en muchos sentidos, un adelantado a su tiempo.
Requisitos Generales
El sistema operativo distribuido Amoeba, se puede ejecutar en diferentes tipos y marcas de computadoras. La intención es que se debe ejecutar en una red con al menos cinco computadoras. A pesar de lo que es hoy técnicamente posible ejecutar la ameba con sólo un procesador, no es una forma satisfactoria para el uso del sistema. De un sistema autónomo (con máquinas de secundaria tal vez más) la máquina principal debe estar equipado con al menos 64 MB de RAM (128 MB recomendado) y por lo menos con 500 MB de espacio en disco. Es, después de todo, un sistema operativo distribuido.
Para obtener buenos resultados desde el sistema que debe tener un equipo distinto del servidor de archivos, una estación de trabajo por usuario (para ejecutar la interfaz de usuario) y un grupo de procesadores de la piscina para realizar el trabajo real y ejecutar varios servidores.
Distribución
Amoeba distribuye no sólo los servicios ``tradicionales del sistema operativo, sino también servicios de más bajo nivel de abstracción tales como el acceso a los bloques de memoria en disco y los procesadores. En Off exploramos la distribución del sistema a un nivel de abstracción inferior. En cuanto a IPC, dos de las contribuciones más interesantes desprendidas del trabajo efectuado por los arquitectos de Amoeba son (1) la combinación de un modelo de nombrado basado en capabilities con un sistema de IPC basado en RPCs que permite distribuir los servicios del sistema con grandes niveles de transparencia y (2) la sugerencia de que los mecanismos básicos de IPC empleados en SSOO distribuidos deben facilitar tanto la implementación de RPCs como la de envío de mensajes . A nuestro juicio, Spring ha dado un paso atrás al considerar que toda la IPC entre objetos está realizada mediante RPCs. En todos aquellos casos en que no se espera respuesta del servidor estamos consumiendo recursos innecesariamente. Lamentablemente, en la época en que se diseñó Amoeba (que fue un sistema adelantado a su tiempo, como ya pasó con MULTICS) no se valoraba demasiado la adaptabilidad como parámetro deseable en la construcción de SSOO (en parte porque había problemas mas acuciantes por resolver). Así, elementos como la gestión básica de memoria (la implementación de los ``segmentos) están contenidos por completo en el núcleo del sistema en Amoeba. No es factible adaptar el funcionamiento de los mismos, lo cual hace que la flexibilidad del sistema de gestión de memoria no sea muy superior a la de Spring o Mach.
Aplicaciones
En realidad el problema de Amoeba no es la falta de adaptabilidad per-se. El problema principal radica en que Amoeba se centra en ocultar a las aplicaciones la distribución del sistema suministrando una imagen de sistema único (por ejemplo, la asignación de procesadores se realiza de modo centralizado, eliminado cualquier posibilidad de adaptar la política de asignación de procesos a procesadores). En Off en cambio, aunque el sistema considera un conjunto de recursos distribuidos, las aplicaciones pueden controlar la asignación y uso de recursos para evitar la pérdida de eficiencia que ocasiona el suministro de una transparencia total en cuanto a distribución de recursos. Por ejemplo, en Off una aplicación puede asegurarse de que aquellos recursos utilizados intensivamente se encuentran siempre en el nodo local; En Amoeba esto es difícil puesto que todo el sistema se esfuerza en ocultar la distribución a las aplicaciones, aunque esto sea con el loable propósito de hacerles el trabajo más fácil. Aunque habrá que esperar a tener un SO completo y en producción operando sobre Off para corroborarlo, esperamos que la distribución de recursos a un nivel de abstracción inferior y la cesión de la práctica totalidad de políticas de asignación y revocación de recursos a las aplicaciones, evite esta fuente de ineficiencia en nuestro sistema. Finalmente, el modelo de hardware contemplado por Amoeba hace que la gestión de recursos no se realice de forma simétrica. Amoeba especializa la operación de los nodos en el sistema de tal modo que unos están dedicados a servir como pool de procesadores, otros como terminales de usuario y otros como servidores de bloques de datos para sistemas de ficheros. Tratar de emplear un nodo para una tarea que no es su tarea primaria es luchar contra la concepción de Amoeba. Esquemas más radicales de aprovechamiento de recursos que contemplen todos los recursos presentes en la red por igual se ven dificultados en cierta medida por el diseño de los servicios del sistema. Aunque es cierto que esto se debe principalmente a la implementación de los servidores fuera del núcleo de Amoeba y no a la arquitectura del núcleo en sí.
