La ameba SISTEMA OPERATIVO DISTRIBUIDO UN INFORME DE ESTADO DE

La ameba SISTEMA OPERATIVO DISTRIBUIDO UN INFORME DE ESTADO DE

Andrew S. Tanenbaum M. Frans Kaashoek Robbert van Renesse Henri E. Bal del

Departamento de Matemáticas e Informática Vrije Universiteit Amsterdam, Países Bajos

abstracto

como el precio de los chips de la CPU sigue disminuyendo rápidamente, pronto será económicamente viable para construir sistemas informáticos que contienen un gran número de procesadores. La cuestión de cómo esta potencia informática debe ser organizado, y qué tipo de funcionamiento es apropiado Sys- tem surge a continuación. Nuestra investigación durante la última década se ha centrado en estas cuestiones, y condujo al diseño de un sistema operativo distribuido, llamado ameba, que está diseñado para sistemas con un gran número de equipos. En este documento describimos ameba, su filosofía, su diseño, sus aplicaciones, y algo de experiencia.

1. Introducción El costo de los chips de la CPU se espera que siga disminuyendo durante el próximo decenio, dando lugar a sistemas que contienen un gran número de procesadores. Conectar todos estos pro- cessors utilizando tecnología estándar (por ejemplo, una LAN) es muy fácil. La parte difícil es el diseño y la implementación de software para gestionar y utilizar toda esta potencia informática en una forma conveniente. En este documento describimos un sistema operativo distribuido que hemos escrito, llamado ameba (Mullender et al., 1990; Tanenbaum et al., 1990; Van de Renesse et al., 1989), que creemos que es apropiado para los sistemas distribuidos de la década de los noventa.

Una idea fundamental subyace ameba: para el usuario, el sistema completo debe parecerse a un solo equipo. Con esto queremos decir que el modelo actual en el que la red comput ers- sólo puede compartir recursos con considerable dificultad tendrá que ser sustituido por un modelo en el que la colección completa de hardware para el usuario parece ser un monoprocesador tradicio- nales del sistema de tiempo compartido. Los usuarios no deben ser conscientes de que las máquinas que están utilizando, o cuántas máquinas que están utilizando, o donde están ubicadas estas máquinas. Tampoco deben ser conscientes de que sus archivos están almacenados o cuántas copias se mantienen o qué se utilizan algoritmos de replicación. A los usuarios, debe existir un único sistema integrado que se ocupan. Es tarea del sistema operativo y los compiladores para proporcionar al usuario con la ilusión de un solo sistema y, al mismo tiempo, gestionar eficientemente los recursos necesarios para apoyar esta ilusión.

Este es el reto que nos hemos fijado en el diseño de amebas. Aunque no estamos en absoluto terminado, y sigue siendo necesaria una investigación considerable, en este documento nos

- 2-

presentar un informe de estado de ameba y nuestros pensamientos acerca de cómo es probable que evolucione.

El esquema de este papel es como sigue. En la Sec. 2 discutiremos el tipo de configuración de hardware para ameba que ha sido diseñado. En la Sec. 3 comenzaremos nuestra discusión de amebas, empezando con el micronúcleo. Dado que gran parte de la tradicio- nales de la funcionalidad del sistema operativo está fuera del micronúcleo, funcionando como servidor de procesos, en la Sec. 4 trataremos algunos de estos servidores. Luego en la Sec. 5, vamos a debatir unas pocas aplicaciones de ameba hasta la fecha. En la Sec. 6 tomamos un breve vistazo a cómo ameba puede ser utilizada en redes de área amplia. En la Sec. 7 hablamos de nuestras experiencias con amebas, buenas y malas. Las secciones 8 y 9 se comparan a otros sistemas de amebas y resumir nuestras conclusiones, respectivamente.

2. Modelo de la ameba ameba antes de describir cómo está estructurado, es útil primero esbozar el tipo de configuración de hardware para el que está diseñada la amiba, ya que difiere bastante de lo que la mayoría de las organizaciones tienen en la actualidad. La fuerza impulsora detrás del sistema architec- tura es la necesidad de incorporar un gran número de CPUs de forma sencilla. En otras palabras, ¿qué hacer cuando se puede pagar 10 o 100 CPU por usuario? Una solución es darle a cada usuario una personal 10 nodos de 100 nodos o multiprocesador. No creemos, sin embargo, esta es una manera eficaz de gastar el presupuesto disponible. La mayoría del tiempo, casi todos los procesadores estará inactivo, lo que de por sí no es tan malo. Sin embargo, algunos usuarios querrán ejecutar programas paralelos, y no será capaz de aprovechar todos los ciclos de CPU inactiva porque están en otras máquinas personales de usuarios.

En lugar de este enfoque multiprocesador personal, creemos que el mejor modelo es el mostrado en la Fig. 1. En este modelo, toda la potencia informática se encuentra en uno o más pro- cessor piscinas. Cada procesador piscina consta de un número considerable de CPU, cada una con su propia memoria local y su propia conexión a la red. En la actualidad, tenemos un prototipo de sistema operativo, que consta de tres bastidores de equipos de 19 pulgadas estándar, cada una con 16 equipos de una sola placa (68020 y 68030, con 3-4M de RAM por CPU). Cada CPU tiene su propia conexión Ethernet; memoria compartida no está presente. Aunque sería fácil construir un 16 nodos multiprocesadores de memoria compartida, no sería fácil construir un nodo 1000- multiprocesadores de memoria compartida. Así, nuestro modelo no supone que ninguna de las CPU compartir memoria física, a fin de hacer posible la escala del sistema. Sin embargo, si la memoria compartida está presente, puede ser utilizado para optimizar el paso de mensajes sólo haciendo memoria a memoria copiando en lugar de enviar mensajes a través de la LAN.

Procesadores de piscina no son "propiedad" de cualquier usuario. Cuando un usuario escribe un comando, el sistema automáticamente y asigna dinámicamente uno o más procesadores para que com- my. Cuando se completa el comando, los procesadores son liberados y regresar a la piscina, esperando el siguiente comando, muy probablemente de un usuario diferente. Si hay una piscina de shor- tage de procesadores, procesadores individuales son timeshared, con nuevos empleos que están siendo asignados a la mayoría de las CPU ligeramente cargado. El punto importante a tener en cuenta aquí es que este modelo es muy diferente de los sistemas actuales, en los que cada usuario tiene exactamente un per- sonal workstation para todas sus actividades informáticas. La piscina del modelo de procesador es más flexible y permite una mejor distribución de los recursos.

El segundo elemento de nuestra arquitectura es la estación de trabajo. Es a través de la colabora- ción que el usuario accede al sistema. Aunque ameba no prohíbe que ejecuta el usuario

: 3-

Procesador estaciones piscina

WAN Gateway

servidores especializados (Archivo, Base de datos, etc)

Fig. 1. La ameba la arquitectura del sistema.

programas en la estación de trabajo, normalmente el único programa que se ejecuta no es el gestor de ventanas. Por esta razón, X-terminales también pueden ser utilizadas como estaciones de trabajo.

...