Distributed operating system amoeba case study

Distributed operating system amoeba case study

• 1.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal Distributed Operating System Case Study Amoeba - Amoeba is a distributed operating system: it makes a collection of CPUs and I/O equipments act like a single computer. - It also provides facilities for parallel programming where that is desired. Introduction and Background: - Amoeba originated at the Vrije Universiteit, Amsterdam, The Netherlands in 1981 as a research project in distributed and parallel computing. - It was designed primarily by Andrew S. Tanenbaum and three of his Ph. D. students, although many other people also contributed to the design and implementation. - By 1983, an initial prototype, Amoeba 1.0, was operational. - New group and collaboration with wide-spread distributed system project designed Amoeba 3.0, which unlike the earlier versions, was based on RPC. - Using Amoeba 3.0, it was possible for clients in Tromso to access servers in Amsterdam transparently, and vice-versa. - Evolved for several years, description here of Amoeba 5.2 Research Goals: - Many research project in distributed operating systems, have started with an existing system (e.g. UNIX) and added new features, such as networking and a shared file system, to make it more distributed. - The Amoeba project took a different approach, and developed a new system from scratch. - The primary goal of project was to build a transparent distributed operating system. - To the average uses, using Amoeba is like using a traditional timesharing system like UNIX- one logs in, edits and compiles programs, moves files around, and so on, the difference is that each of these actions makes use of multiple machines over the network. - These include process servers, file servers, directory servers, compute servers and other machines, but the user is not aware of any of this. At the terminal, it just looks like a timesharing system. - Important distinction of Amoeba to other machines is that Amoeba has no concept of “home machine” i.e. when a user logs in, it is to the system as a whole, not to a specific machine. - Machines do not have owners. The initial shell, started upon login, runs on some arbitrary machine, but as commands are started up, in general they do not run on the same
• 2.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal machine as the shell. Instead the system automatically looks around for the most lightly loaded machine to run each new command on. - Amoeba is highly location transparent. - A simple example of transparency of Amoeba is amake, when the user types amake, all the necessary compilations happen, as expected, except that the system(and not the user) determines whether they happen sequentially or parallel, and on which machine or machines this occurs. - A secondary goal of Amoeba is to provide a testbed for doing distributed and parallel programming. Orca language has been designed for Amoeba. The Amoeba System Architecture: - Amoeba was designed with two assumptions:  Systems will have a very large number of CPUs.  Each CPU will have tens of megabytes of memory. - Instead of personal multiprocessor approach, in the model of Amoeba, all computing power is located in one or more processor pools. - A processor pool consists of a substantial number of CPUs, each with its own local memory and network connection. - Shared memory is not required or even expected, but if it is present it could be used to optimize message passing by doing memory-to-memory copying instead of sending messages over the network. - The CPUs in a pool can be of different architectures, for example a mixture of 680x0, 386, SPARC machines. - Amoeba has been designed to deal with multiple architectures and heterogeneous architectures.
• 3.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal - It is even possible for children of single process to run in different architectures. - Pool processors are not owned by any one user. When a user types a command, the operating system dynamically chooses one or more processors on which to run that command. - When the command completes, the processes are terminated and the resources held go back into the pool, waiting for the next command. - If there is shortage of pool processors, individual processors are timeshared, the new processes being assigned to the most lightly loaded CPUs. - The second element of Amoeba architecture is the terminal. It is through the terminal that the user accesses the system. The typical Amoeba terminal is an X terminal, with a large bit-mapped screen and a mouse. - The pool processors are inherently cheaper than workstations because they consist of just a single board with a network connection. - There is no keyboard, monitor or mouse, and the power supply that can be shared by many boards. - Thus, instead of buying 100 high-performance workstations for 100 users, one can buy 50- high performance pool processors and 100 X terminals for the same price. - To avoid any confusion, the pool processors do not have to be single board computers. If these are not available, a subset of existing personal computers or workstations can be designated as pool processors. - They also do not need to be located in a single room. The pool processors can be even in different countries. - Another important component of Amoeba configuration consists of specialized servers, such as file servers, which for hardware or software reason need to run on different processors. - Servers provide services, i.e. works for clients. - Servers are generally running all the time for better performance. The Amoeba Microkernel: - Amoeba consists of two basic pieces:  a microkernel, which runs on every processor, and  a collection of servers, that provide most of the traditional operating system functionality.
• 4.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal - The Amoeba microkernel runs on all machines in the system. - The microkernel has four primary functions: i. Manage processes and threads, ii. Provide low-level memory management support, iii. Support communication, iv. Handle low-level I/O - Like most operating systems, Amoeba supports the concept of a process. Amoeba supports both : a process with one thread and a process with multiple threads. Such a process has a single address space, a set of registers, a program counter and a stack. - Threads can allocate and deallocate blocks of memory, called segments. These segments can be read and written, and can be mapped into and out of the address space of the process to which the calling thread belongs. The process may have at least one segment or many more of them. Segments can be used for text, data, stack, or any other purpose the process desires. - Two forms of communications are provided in Amoeba: point- to – point communication and group communication. Point-to-point communication is based on the model of a client sending a message to the server, then blocking until the server has sent a reply back. Group communication allows a message to be sent from one server to multiple destinations. - In Amoeba, for each of the I/O device attached to a machine, there is a device driver in the kernel. The driver manages all I/O for the device. - Device drivers communicate with the rest of the system by the standard request and reply messages. A process, such as a file server, that needs to communicate with the disk driver, sends it request messages and get back replies, the client does not have to know that server is talking to driver. - Both point-to-point and group communication make use of a specialized protocol called FLIP.
• 5.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal The Amoeba Servers: - Everything that is not done by the kernel is done by the server processes. - The idea behind this design is to minimize kernel size and enhance flexibility. - By not building the file system and other standard services into the kernel, they can be changed easily and multiple versions can run simultaneously for different user populations. - Amoeba is based on client-server model. Clients are typically written by the users and servers are typically written by the system programmers, but users are free to write their own servers if they wish. - Central to the entire software design is the concept of an object, which is like an abstract data type. - Objects are managed by servers. When a process creates an object, the server that manages the object returns to the client a cryptographically protected capability for the object. - To use the object later, the proper capability must be presented. All the objects in the system, both hardware and software, are named, protected, and managed by capabilities. Among the objects supported this way are files, directories, memory segments, screen windows, processors, disks, and tape drivers. - All the standard servers have stub procedures in the library. To use a server, a client normally just calls the stub, which marshals the parameter, sends the message, and blocks until the reply comes back. This mechanism hides all the details of the implementation from the user. A stub compiler is available for users who wish to produce stub procedures for their own servers. - Probably the most important server is the file server known as the bullet server. It provides primitives to manage files, creating them, reading them, deleting them and so on. Unlike most file servers, the files it creates are immutable. Once created a file cannot be modified but it can be deleted. Immutable files make automatic replication easier since they avoid many of the race conditions inherent in replicating files that are subject to being changed during the replication process. - Another important server is directory server (also k/a soap server). It is the directory server that manages the directories and path names and maps them onto capabilities. To read a file, the process asks a directory server to look of the path name. On a successful lookup, the directory server returns the capability for the file (or other object). Then subsequent operations on the file do not use the directory server, but go straight to the file server. - Splitting the file system into these two components increases flexibility and makes each one simpler, since it only has to manage one type of object (directories or files), not two. - Other standard servers are present for handling object replication, starting processes, monitoring servers for failures, and communicating with the outside world. User servers perform a wide variety of application-specific tasks.
• 6.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal Objects and Capabilities of Amoeba: - Object : The basic unifying concept underlying all the Amoeba servers and the services they provide is the object. An object is an encapsulated piece of data upon which certain well- defined operations may be performed. It is in essence, an abstract data type. Objects are passive. They do not contain processes or methods or other active entities that “do” things. Instead, each object is managed by a server process. To perform an operation on an object, the client does an RPC with the server, specifying the object, the operation to be performed, and optionally, any parameters needed. The server does the work and returns the answer. Clients are unaware of the locations of the objects they use and the servers that manage these objects. Capabilities: Objects are named and protected in a uniform way, by special tickets, called capabilities. To create an object, the client does an RPC with the appropriate server specifying what it wants. The server then creates the object and returns a capability to the client. On subsequent operations, the client must present the capability to identify the object. A capability is just a long binary number. When a client wants to perform an operation on an object, it calls a stub procedure that builds a message, containing the object’s capability and then traps to the kernel. The kernel extracts the Server port field from the capability and looks it up in its cache to locate the machine on which the server resides. If the port is not in the cache, it is located by broadcasting. The servers are addressed via server ports only and are publicly known and stable for years. The rest of the information in the capability is ignored by the kernels and passed to the server for its own use. The Object field is used by the server to identify the specific object in question.
• 7.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal The Rights field is a bit map telling which of the allowed operations the holder of the capability may perform. The Check field is used for validating the capability. PROCESS MANAGEMENT IN AMOEBA: - A process in Amoeba is basically an address space and a collection of threads that run in it. Process: - A process is an object in Amoeba. When a process is created, the parent process is given the capability for the child process, just as with any other newly created object. Using this capability, the child can be suspended, restarted, signaled or destroyed. - Process management in Amoeba is handled at three different levels: At the lowest levels are the process servers, which are kernel threads running on every machine. To create a process on a given machine, another process does an RPC with that machine’s process server, providing it with necessary information. At the next level up we have a set of library procedures that provide a more convenient interface for user programs. Finally the simplest way to create a process is to use the run server, which does most of the work of determining where to run the new process. Amoeba communications: - Point –to –point communication,RPC - Group communication *Each standard server defines a procedural interface that clients can call. These library routines are stubs that pack the parameters into messages and invoke the kernel primitives to send the message. During message transmission, the stub, and hence the calling thread, are blocked. When the reply comes back, the stub returns the status and results to the client. - Amoeba uses a custom protocol called FLIP (Fast Local Internet Protocol) for actual message transmission. This protocol handles both RPC and group communication and is below them in protocol hierarchy. In OSI terms, FLIP is a network layer protocol, whereas RPC is more of the connectionless transport or session-protocol (the exact location is arguable, since OSI was designed for connection-oriented networks), Conceptually FLIP can be replaced by another network layer protocol, such as IP. Requirement of FLIP:
• 8.
  Compiled By: RamuAryan Pandey Kathmandu,Nepal -