Sistema operativo distribuido amoeba

A principio de los aos 90, se evidenci que el entorno de la computacin seguira sufriendo grandes cambios, como consecuencia principalmente del progreso tecnolgico. Teniendo presente estos hechos podramos clasificar la historia de las computadoras modernas en las siguientes reas: *1970: Timesharing ( 1 supercomputadora, muchos usuarios) *1980: Computadora Personal (1 computadora por usuario) *1990: Computacin Paralela ( muchas computadoras por usuarios) En los aos 70 , las computadoras eran enormes, caras y ubicadas en centros de computadoras como si fuera un gran mausoleo al poder computacional. De hecho varias organizaciones posean una maquina dedicada. En los aos 80, los precios cayeron de manera vertiginosa hasta el punto de que cada usuario poda poseer una computadora dedicada. Surge entonces la necesidad de compartir y estar conectados a travs de una red, de manera a poder ingresar a las otras computadoras y compartir documentos, etc. En los aos 90 se dio una reduccin an mayor de los precios por lo que es posible tener varios equipos de computadoras en una sola placa e inclusive en un solo chip. Surge entonces el ambiente adecuado para la construccin de sistemas con decenas e inclusive cientos de computadoras por usuario, distribuidos quizs en un rea amplia, estos sistemas son los referenciados como Sistemas Distribuidos y Paralelos.El desarrollo de esta idea trae consigo la pregunta natural sobre que tipos de software ser necesario para esta clase de sistemas, esa plataforma (software) es la proveda por el sistema operativo Paralelo y Distribuido Amoeba. Amoeba nace como respuesta a la necesidad de desarrollo de software para computacin paralela y distribuida. Desde 1980, un grupo de investigadores de la Universidad de Vrije (Amsterdam - Holanda) liderados por el Prof. Andrew S. Tanembaum decide desarrollar un sistema operativo distribuido de propsito general diseado para un entorno con varias computadoras. Los objetivos que guiaron este desarrollo son los siguientes: * Distribucin: conectar varias mquinas.

*Paralelismo: permitir que trabajos individuales usen mltiples CPUs fcilmente. *Transparencia: que el conjunto de procesadores acte como un sistema nico. *Performance: lograr todo lo anterior de manera eficiente. Otro objetivo clave es la transparencia. En el entorno de trabajo de Amoeba, el conjunto de mquinas acta como un sistema integrado nico. En general, los usuarios no tienen conocimiento del nmero ni ubicacin de los procesadores que ejecutan sus comandos, como tampoco conocen la cantidad ni la ubicacin de los servidores de archivo que manejan sus archivos de trabajo. Para el usuario promedio, el uso de Amoeba es igual al uso de un sistema tradicional de tiempo compartido como Unix. Ponindolo en otros trminos, Amoeba no tiene el concepto de "mquina origen". Cuando un usuario entra al sistema, entra a ste como un todo y no a una mquina especfica. Las mquinas no tienen poseedores. El shell inicial, el cual se inicializa al entrar el usuario, se ejecuta en cierta mquina arbitraria, pero al ser iniciados los comandos, en general no se ejecutan en la misma mquina que el shell. En vez de esto el sistema busca de manera automtica la mquina con la menor carga para ejecutar cada nuevo comando. Durante el curso de una larga sesin en la terminal, los procesos que se ejecutan a cargo de un usuario cualquiera estarn ms o menos dispersos en todas las mquinas del sistema, dependiendo de la carga. Descripcion Tecnica de amoeba. Antes de proseguir es de inters describir la arquitectura sobre la que el sistema Amoeba puede ejecutarse. Arquitectura del sistema Amoeba se dise con dos hiptesis respecto al hardware: 1. Los sistemas tienen un nmero muy grande de CPU. 2. Cada CPU tendr cientos de megabytes de memoria. La arquitectura del sistema Amoeba est constituida principalmente de cuatro componentes. Primero se encuentran las estaciones de trabajo (Workstations), una por usuario, estas estaciones de trabajos son las utilizadas por los usuarios para realizar tareas que necesiten respuesta interactiva. Las estaciones de trabajos no poseen discos, y son utilizadas principalmente como estaciones inteligentes para realizar manejo de ventanas X (estacin X). Segundo, est el pool de procesadores, un grupo de procesadores que se alocan de manera dinmica de acuerdo con la necesidad, y luego son devueltos al pool.

Tercero, los servidores especializados, servidores tales como: Servidores de archivos, de directorio, de impresin, etc. Cada servidor est dedicado a realizar una tarea determinada, en algunos casos existen varios servidores que proveen el mismo servicio. En general un servidor es una mquina dedicada para este propsito. Cuarto son lo gateways, que son utilizados para la conexin de sistemas Amoeba en distintas ciudades o pases en un solo sistema uniforme. Los gateways aslan a Amoeba de las peculiaridades de los protocolos que suelen utilizarse en las WAN. Todas las mquinas Amoeba ejecutan lo que se dio a llamar microkernel, el cual provee bsicamente procesos multihebrados, servicios de comunicacin, I/O, y algunas cosas ms. La idea bsica detrs de este kernel es mantenerlo pequeo, para maximizar su confiabilidad, y permitir tanto como sea posible que el sistema se ejecute como proceso usuario. Operaciones Remotas La combinacin de las operaciones de pedido desde un cliente y la respuesta de un servidor a un cliente recibe el nombre de operacin remota. Los mensajes de pedido y de respuesta estn constituidos de una cabecera y un buffer, las cabeceras son de 32 bytes, y los bufers pueden ser de hasta 30 kilobytes. La cabecera de pedido tiene el capability del objeto en el que se va a operar, el cdigo de operacin, y un rea limitada (8bytes) para los parmetros de la operacin. Cuando un servidor se prepara para recibir pedidos de los clientes, ejecuta la primitiva get_request, que lo bloquea. Cuando un mensaje de pedido llega, el servidor se desbloquea y los parmetros formales de la llamada a get_request se llenan con la informacin del pedido que est ingresando. El servidor realiza la tarea y devuelve un mensaje usando la primitiva put_reply. En el lado del cliente, para invocar a una operacin remota, el proceso utiliza la primitiva do_operation. Esta operacin enva el mensaje de pedido al servidor. La cabecera del pedido contiene el capability del objeto a ser manipulado y los parmetros relacionados con la operacin. El proceso que realiz el pedido queda bloqueado hasta que se reciba la respuesta, en ese momento los tres parmetros son llenados y se retorna un estado que puede tener uno de tres valores posibles: 1. El pedido ha sido enviado y tambin ejecutado. 2. El pedido no ha sido enviado o ejecutado. 3. El estado es desconocido. El tercer caso puede ocurrir cuando el pedido fue enviado, pero no hubo respuesta alguna. Esta situacin ocurre si un servidor ha cado durante la operacin remota. Dada cualquiera de esta condiciones Amoeba garantiza que el mensaje fue

enviado a lo ms una vez. Si se retorna un estado 3, es tarea de la aplicacin o del sistema en tiempo de ejecucin realizar las rutinas de recuperacin.

Llamada a procedimientos remotos. Una llamada a procedimiento remoto consiste en algo ms que un intercambio de mensajes pedido / respuesta; el cliente debe colocar su capability, cdigo de operacin, y parmetros en el buffer de pedidos, y al recibir la respuesta debe desempaquetar los resultados. El servidor se encarga de comprobar el capability, extraer el cdigo de operacin y los parmetros de el pedido, y realizar la llamada al procedimiento encargado de ejecutar la solicitud correspondiente, el resultado de este procedimiento se coloca en el buffer de respuesta. Si existen diferentes tipos de representacin de datos entre el cliente y el servidor, estos deben ser manejados. El procedimiento de colocar los parmetros y los resultados en un buffer de mensaje recibe el nombre de marashalling, y no tiene un costo trivial por lo que la codificacin y el diseo del mismo tiene que ser muy cuidadoso. La generacin automtica de este tipo de stubs desde la cabecera del procedimiento es imposible. Algunas informaciones esenciales estn perdidas. Al escribir las rutinas se utilizaron varias piezas de informacin derivada para realizar el trabajo: 1- El buffer es utilizado solamente para recibir informacin desde el servidor de archivos; es solo un parmetro de entrada, y por lo tanto no debera ser enviado al servidor. 2- La longitud mxima del buffer se da en el parmetro n_bytes. La longitud real del buffer es el valor devuelto si es que no ha ocurrido ningn error. 3- File_cap es especial; pues define el servicio que debe ser llevado a cabo por la operacin remota. 4- El generador de stubs no conoce cual es el cdigo de operacin del servidor para read_file. Para poder realizar la generacin automtica de stubs, la interfaz entre el cliente y el servidor debe contener la informacin que hemos listado, adems de la informacin sobre la representacin de tipos para todas las combinaciones lenguaje/maquina que se estn utilizando. De este modo, las especificaciones de interfaz debern tener un mecanismo de herencia que permita que las interfaces de mas bajo nivel puedan ser compartidas por otras interfaces. AIL (Amoeba Interface Languaje) es un lenguaje en el cual puede ser especificada la informacin para la generacin de stubs eficientes de manera tal que el compilador de AIL pueda producir stubs de manera automtica. Desde esta especificacin, AIL puede generar el stub del cliente del ejemplo que hemos visto con el cdigo correcto para el marshalling. Tambin se puede generar

el loop principal del servidor, que contiene el cdigo de marshalling correspondientes a los stubs clientes. Las especificaciones dan cuenta a AIL de que los segmentos de cdigo correspondiente a las operaciones para el siple_file_server se pueden alocar en el rango de 1000 a 1999; cuenta adems cuales de los parmetros son parmetros de entrada al servidor, cuales son de salida y cuales cumplen ambas funciones, adems establece que el tamao mximo del buffer es de NBYTES, y que el tamao actual es de n bytes.

Procesos y hebras. Un proceso en Amoeba consiste de uno o mas hebras que se ejecutan en paralelo. Todas las hebras de un proceso comparten el mismo espacio de direccionamiento, pero cada uno tiene una porcin dedicada de ese espacio para utilizar como su pila privada, cada una tiene su propio contador de programa. Desde el punto de vista del programador, cada hebra es como un proceso secuencial, excepto que las hebras de un proceso pueden comunicarse utilizando memoria compartida, para conseguir esto, las hebras pueden sincronizarse entre s utilizando mutexes o semforos. El propsito de tener mltiples hebras en un procesos es aumentar el desempeo a travs del paralelismo, y proveer aun un modelo semntico razonable para el programador. Por ejemplo, un servidor de archivos puede ser programado como un proceso con mltiples hebras, Cuando llega un pedido, este puede ser asignado a alguna de las hebras para manejarlo. Esa hebra primero revisa un cache interno para ver si es que se encuentra el dato solicitado. Si no, se realiza un RPC con un servidor de discos remoto a fin de obtener los datos. Mientras espera la respuesta de el disco, la hebra queda bloqueada y no podr manejar ningn otro pedido. De todos modos, estos nuevos pedidos pueden ser asignados a otras hebras en el mismo proceso para trabajar mientras que la primera hebra del proceso se encuentra bloqueada. De este modo, mltiples pedidos pueden ser manejados de manera simultnea, permitiendo que cada hebra trabaje de manera secuencial. El objetivo de tener que todas las hebras compartan el espacio de direccionamiento es hacer que sea posible que todas las hebras puedan tener un acceso directo a un cache comn, esto no sera posible si cada hebra tiene su propio espacio de direcciones La planeacin de las hebras dentro de un proceso se lleva a cabo con un cdigo interno al proceso. Cuando una hebra se bloquea ya sea porque no tiene trabajo que hacer o porque est esperando una respuesta remota, se llama al planificador, la hebra queda bloqueada y una nueva hebra puede iniciar su ejecucin. De este modo las hebras son efectivamente corrutinas. No existen hebras supeditadas, en el sentido de que una hebra en estado de ejecucin ser obligada a parar por el hecho de que su ejecucin a durado demasiado tiempo. Una hebra no necesita preocuparse de que cuando est en camino de actualizar un dato en alguna tabla crtica ser detenido por un comando de finalizacin y

alguna hebra iniciar su ejecucin para utilizar la tabla. Se asume que todas las hebras de un proceso fueron codificadas por el mismo programador de manera que se comportarn de o una manera cooperativa. SERVIDORES As como se ha descrito el Amoeba kernel solo maneja la comunicacin y algn administrador pequeo de procesos. El kernel se encarga de enviar y recibir mensajes, planear procesos, y algo de manejo a bajo nivel de la memoria. Todo lo dems se lleva a cabo por medio de procesos del usuario. Todas las funciones restantes que estn normalmente asociado con el entorno del sistema operativo son llevadas a cabo por servidores, que no son ms que procesos del usuario. De este modo los usuarios que no estn contentos con los servicios prestados por un manejador de archivos pueden codificar el propio y usarlo. Servidor de memoria y procesos. En varias aplicaciones, los procesos necesitan una manera de crear subprocesos. En UNIX, un subproceso se crea con la primitiva fork, mediante la misma se crea una copia exacta del proceso original. Este proceso puede ejecutarse por un tiempo determinado, hasta que ejecute la primitiva exec para sobreescribir la imagen del ncleo con un nuevo programa. En un sistema distribuido, este modelo no es atractivo. La idea de construir en primer lugar una copia exacta de un procesos, posiblemente remoto, y eliminarlo despus de poco tiempo de ejecucin es ineficiente. Consecuentemente, Amoeba utiliza una estrategia diferente. Los conceptos claves son segmentos y descriptores de procesos. Un segmento es un bloque continuo de memoria que contiene cdigo o datos. Cada segmento tiene el capability que permite al dueo realizar operaciones sobre el mismo, estas operaciones incluyen lectura y escritura. Un descriptor de procesos, es una estructura de datos que provee informacin sobre los procesos stunned (aturdidos), o sea un proceso que aun no ha sido inicializado o en estado de migracin. El descriptor posee cuatro componentes. El primero describe los requerimientos para el sistema en donde el proceso ser ejecutado: la clase de mquina, que conjunto de instrucciones, memoria mnima disponible, utilizacin de instrucciones especiales tales como floating point, y otros requerimientos. El segundo componente describe la plataforma del espacio de direccionamiento: nmero de segmentos, y por cada segmento, el tamao, la direccin virtual, y el modo en que se mapea. Adems del capability de un archivo o segmento que contiene la informacin almacenado en el segmento. El tercer componente describe el estado de cada hebra de control: puntero del stack, top y bottom del stack, contador del programa, una palabra que contiene el estado del

procesador, y los registros. Las hebras se pueden bloquear con algunas llamadas del sistema, este hecho tambin se puede informar con el descriptor del proceso. El cuarto componente es una lista de puertos para los que el proceso es un servidor.Un proceso se crea siguiendo los pasos: 1. Obtener el descriptor del proceso para el binario desde el sistema de archivos. 2. Crear un segmento local o un archivo e inicializarlo al entorno inicial del proceso. El entorno consiste de un grupo de los llamados capabilities, y los argumentos al proceso. 3. Modificar el descriptor del proceso para hacer que el segmento de entorno recin creado sea el primer segmento. 4. Enviar el descriptor del proceso a la mquina donde va ha ser ejecutado. Cuando el descriptor del proceso llega a la mquina en donde ser ejecutado, el servidor de memoria extrae los capabilities para los segmentos remotos, y usando las mismas extrae el segmento de cdigo y de datos de donde quiera que se encuentren realizando en la mayora de los casos operaciones READ. De este modo, la ubicacin fsica de las mquinas involucradas carece de significado e importancia.Una vez conseguidos todos los segmentos el proceso est completo y puede iniciarse su ejecucin. En este instante se enva al solicitante de la ejecucin, un capability, este puede ser utilizado para matar al proceso, leer y escribir en su memoria, etc. El servidor de archivos. En lo que respecta e importa al sistema un servidor de archivo no es ms que un proceso usuario. Consecuentemente, durante el curso de la existencia de Amoeba se escribieron una variedad de servidores de archivos; en particular podramos citar al que se est utilizando en la actualidad el bullet server que ha sido diseado para obtener lo mximo en desempeo. Dedicaremos algunas palabras adicionales a este programa del entorno del usuario. La cada de los precios de los discos y de la memoria RAM desde la pasada dcada nos obliga a cambiar la forma tradicional de concebir el diseo de un servidor de archivos; en particular abandonar la idea de guardar los archivos como una coleccin de bloques de tamao fijo; todos los archivos se guarda de manera contigua, tanto en el disco como en la memoria del servidor. A pesar de que esto implica un poco de desperdicio en materia de espacio de discos y memoria por causa de la alta fragmentacin, se obtiene una ganancia elevada en el desempeo que justifica el pequeo incremento en el costo de adquirir un disco de 800MB en lugar de uno de 500MB para almacenar archivos que ocupan 500MB.

El bullet server es un deposito de archivos inmutable, con operaciones principales como read-file y create-file. Cuando un proceso realiza un pedido de read-file, el bullet server puede transferir el archivo entero al cliente en una sola RPC, amenos que sea de un tamao mayor que el mximo permitido (30.000 bytes) en este caso se necesitar ms de un RPC. El cliente puedo luego editar o en todo caso modificar el archivo de manera local. Cuando ha terminado, el cliente realiza un RPC create-file para crear una nueva versin. La ltima versin permanece intacta hasta que sea borrada de manera explcita o recolectado como basura. Ntese que diferentes versiones de un archivo tiene diferentes capabilities, de manera que pueden coexistir.Los archivos se guardan de manera contigua en el disco, y se guarda una copia en la memoria cache del servidor (actualmente 12 MB). Cuando un archivo solicitado no se encuentra disponible en esta memoria, se carga desde el disco a travs de una sola operacin DMA almacenndolo en el cache de manera contigua (a diferencia de los sistemas de archivo convencionales no se utiliza ningn tipo de bloques en el sistema de archivos). En la operacin create-file se puede pedir la respuesta antes (para aumentar la velocidad) o despus, (para saber que se escribi con xito) de que el archivo se escriba en el disco.El servidor de directorios Otro servidor importante es el servidor de directorios (tambin conocido como servidor soap). Este servidor maneja directorios y nombres de las rutas de acceso y las asocia con las capabilities. Para realizar operaciones sobre un archivo, el proceso pide al servidor de directorios que busque el nombre de la ruta de acceso. En una bsqueda exitosa, el servidor retorna la capability del archivo. Toda operacin posterior sobre dicho archivo ya no necesita el uso del servidor de directorios. La separacin del sistema de archivos en dos servidores aumenta la flexibilidad y hace a cada parte ms sencilla, puesto que slo maneja un tipo de objeto. A diferencia de los archivos, los directorios no son inmutables, as que se pueden aadir o eliminar entradas de los directorios existentes. Los propios directorios son objetos y estn protegidos por capabilities, que a su vez se pueden almacenar en otros directorios permitiendo la existencia de rboles jerrquicos de directorios y estructuras ms generales. Aunque el servidor de directorios se puede utilizar simplemente para almacenar pares (nombre de archivo - capability) tambin puede soportar un modelo ms general considerando que el nombre de archivo hace referencia a un objeto y para el mismo se pueden definir varias capabilities. En cualquier sistema distribuido, en particular aquellos que desean utilizar redes de rea amplia, es difcil tener el concepto de un nico directorio raz global. En Amoeba, cada usuario tiene su propio directorio raz. Este directorio contiene las

capabilities no slo de los subdirectorios privados del usuario, sino tambin de varios directorios pblicos con programas del sistema y otros archivos compartidos. Los principales servicios del servidor de directorios son: creacin de nuevos directorios, eliminacin de directorios, aadido de informacin a los directorios ya existentes, reemplazo de la informacin contenida en un directorio, obtencin del conjunto de capabilities correspondientes a un objeto especfico del directorio, etc. Para la implementacin del servidor de directorios se utiliza un vector de parejas de capabilities en una particin simple del disco. Este vector no utiliza el servidor de archivos porque se debe actualizar con frecuencia. AMOEBA Y LA COMUNICACIN EN GRUPOS Los servicios en Amoeba por lo general son direccionados por puertos, que son en realidad nmeros aleatorios grandes. Cuando un servicio se inicia genera un nuevo puerto y registra el puerto con el servicio de directorio. Un cliente puede mirar el puerto utilizando el mismo servicio (el de directorio) y solicitar a su propio kernel que enve mensajes a un determinado puerto. El kernel se encargar de mapear el puerto a una direccin de red. Si mutiples servidores se encuentran monitoreando ese mismo puerto, solamente uno de ellos obtendr el mensaje. Los grupos en este sistema son cerrados, de modo que, un proceso que no es miembro y desea comunicarse con un grupo puede usar RPC (o eventualmente convertirse en miembro del grupo). La razn por la cual esto se implement de este modo es que un cliente no necesita saber si el servicio provedo consiste de mltiples servidores que utilizan un canal broadcast para comunicarse entre s, o se trata solo de un servidor. Adems, el proveedor del servicio no tiene por que saber si el solicitante es un grupo o un solo cliente. Estas decisiones se tomaron para estar acorde con el paradigma cliente/servidor: un cliente sabe que las operaciones estn disponibles, pero no tiene necesidad de saber como estos servicios estn implementados. Otros aspectos de Amoeba Amoeba corre sobre las siguientes arquitecturas hardware: Sun 4c y MicroSPARC SPARCstations Intel 386/486/Pentium/Pentium Pro (IBM AT bus, PCI bus) 68030 VME-bus boards (Force CPU-30) Sun 3/60 & Sun 3/50 workstation

SOFTWARE II
NOMBRE: Iliana Elizabeth Segura Dirzo GRADO: 4A TURNO: Matutino MAESTRO: Ezequiel Santillan PROYECTO: Sistema Operativo Distribuido Amoeba