An Introduction to the Amoeba Distributed Operating System Apan Qasem Computer Science Department Florida State University

Transcription

1 An Introduction to the Amoeba Distributed Operating System Apan Qasem Computer Science Department Florida State University Abstract The Amoeba Operating System has been in use in academia, research and industry for quite some time. It is a powerful micro kernel based distributed operating system. A brief description of this unique distributed operating system is presented in this paper. The paper begins with some background information on research activities in Amoeba. This discussion is followed by a look at the system architecture for this operating system. The major portion of the paper focuses on some of the key design issues of Amoeba. Among these are communication primitives, naming and protection, resource management, fault tolerance and services. The paper concludes with a discussion on how the Amoeba OS compares with some of the other distributed operating systems.

2 1. Background The dramatic price decrease of microprocessors in the early 80s had a major influence on the computer industry in a number of ways. One of the key changes was noticed in the development of new distributed systems. Organizations began to move away from the more expensive mainframe set-up and decided to adopt a more efficient and economical system that made use of a large number of microprocessors. The advent of distributed systems required the development of new kind of software that could manage the system. A research group under the direction of Prof. Andrew S. Tanenbaum at the Vrije University was one of the first to take up the challenge of developing a new distributed operating system. These pioneers started their research back in 1980 with the aim of coming up with an operating system that would allow seamless interconnection of multiple processors distributed over a network. [1] The Amoeba distributed operating system is the result of years of research conducted by this group. Amoeba is a powerful microkernel-based operating system that turns a collection of workstations into a transparent distributed system. Transparency has been a key issue in the design of Amoeba. In general, the users are not aware of the number and location of the processors that run their commands, or of the number and location of the file servers that store their files. [2] Thus Amoeba presents the user with an illusion of an old-

3 fashioned time-sharing system whereas in reality the system is a collection of machines on a network that may potentially expand to several countries. Amoeba has been in use in the industry for over ten years now. However, it is an ongoing research project and new versions of the operating system are being released quite frequently. Amoeba has been implemented on various platforms including MicroSPARC SPARCstation, Sun 3/50 and Sun 3/60 workstation and Intel 386/486/Pentium. Amoeba is available free to researchers and educators and for special commercial prices and conditions to corporate, government and other users. [1] The rest of the paper takes a somewhat detailed look at the system architecture, the design goals and some the key design issues of this unique operating system. 2. System Architecture Before talking about the design principles of the operating system it is perhaps a good idea to look at the kind of system architecture for which Amoeba has been designed. Although, it is technically possible to run Amoeba on a single microcomputer, the authors of the software recommend a minimal configuration for running the Amoeba operating system. A typical Amoeba system should consist of four functional classes of machines: [3] i. i. Workstations

4 ii. ii. Processor Pool iii. iii. Specialized Servers iv. iv. Gateway The workstations are used by the users to access the system. These workstations are not total dumb terminals, however they have very limited processing power. None of the heavy duty processing is done at the workstations level. Usually, workstations do window management, and let users perform basic editing and tasks that require fast interactive response. Many of the Amoeba systems use simple X-terminals as workstations. The set of pool processors does all the heavy-duty computations. The processors are not owned by the users, they are dynamically allocated to users as required. These processors can be part of a multiprocessor or a multicomputer, be a collection of singleboard computers or be a group of workstations allocated for this purpose. Usually, each pool processor has several megabytes of private memory, that is, pool processors need not have any shared memory (but it is not forbidden). Communication is performed by sending packets over the LAN. [2] A typical Amoeba configuration would also have a set of specialized servers for performing special tasks in the system. Examples of specialized servers include, file servers and directory servers. The specialized server may run on any of the pool processors or on dedicated hardware as desired.

5 Finally there s the Gateway, a special server that connects an Amoeba system to the wide-area-network in a transparent manner. The special Gateway is needed because Amoeba uses a special protocol called FLIP for data transfer rather TCP/IP which is used on the Internet. The main job of the Gateway is to convert data between these two different protocols. 3. Design Issues In designing Amoeba the authors had four major goals in mind: [2] Distribution Parallelism Transparency Performance Tanenbaum and his research group wanted to create an operating system that would connect a large number of computers over a distributed network in a transparent way. They also wanted the ability of parallel computation in the system. That is in this system a single job or program can use multiple processors to gain speed. For example, a branch and bound problem such as the Traveling Salesman Problem can use tens or even hundreds of CPUs, if available, all working together to solve the problem more quickly. Finally, there s the issue of performance. And the issue of performance is the one that s most relevant to the discussion on the key design choices that follows. In designing Amoeba the authors tried to keep things as simple as possible while at the same time they

6 tried to maximize the performance. Some of the key design issues of the Amoeba operating system are presented next. 3.1 Communication Primitives A minimal Remote Procedure Call model is used for communication between clients and servers in the Amoeba system. The client sends a request to the server and blocks until it receives a reply. On the other hand, the server upon receiving a request processes it and then sends back a reply with result of the operation. Thus the communication involves exchanging just two types of messages: REQUEST and REPLY. This was a deliberate design choice made by the authors in order to keep things simple and make the communication faster. [4] The RPC mechanism however involves more than just exchanging REQUEST-REPLY messages. In its request the client needs to specify the object (described in the next section) on which the operation is to be performed, the kind of operation that needs to be performed and also the associated parameters. Since, Amoeba operates on a distributed system every remote procedure call involves the marshalling and unmarshalling of parameters. To deal with this situation a special language called the Amoeba Interface Language (AIL) has been developed. [2] AIL generates the stub procedures and handles the marshalling and unmarshalling of parameters. This way, all the details of a remote procedure call are hidden to the user thus preserving the transparency of the system.

7 For increased performance the FLIP network protocol is used for communication within an Amoeba system. [2] Although, this requires the use of a special Gateway server to communicate with a WAN, it greatly increases the communication speed within the system 3.2 Naming and Protection The naming and protection scheme in Amoeba depends on two fundamental concepts: objects and capabilities. An object is conceptually an abstract data type on which certain operations are defined. For example, a directory is an object to which certain operations can be applied, such as ``enter name'' and ``look up name.'' Amoeba primarily supports software objects, but hardware objects also exist. Each object is managed by a server process to which RPCs can be sent. Each RPC specifies the object to be used, the operation to be performed, and any parameters to be passed [2] A capability on the other hand provides a handle on the object. In the Amoeba model a capability is just a number that is generated by a server when it first receives a request for object creation form the client. Once the capability has been generated the client has to use it for all future operations on that particular object. Each capability also consists of the rights and privileges of users on that particular object. Thus this simple object-based model handles the entire naming and protection scheme in Amoeba maintaining its transparency and adding to its simplicity. 3.3 Resource Management

8 A collection of dedicated servers or pool processors applies a variety of techniques to manage resources on an Amoeba system. For every machine on the system there is a resource manager, a process that keeps track and controls the resources for that particular machine. There is also a dedicated server called the Process Server that keeps track of which processors are free and which are not in the process pool. It is use the job the process server to allocate a processor or a group of processors for a particular task. Keeping up with the notion of transparency, the allocation of processors for a particular task is kept totally transparent to the user. The user has no control over which processors are going perform the computation. [4] The Amoeba operating system also uses a special server called the Bank Server that handles allocation of shared resources. The Bank Server provides a general mechanism for resource management using accounting techniques. The idea behind this is to allocate a number of tokens or virtual money to each process upon creation. Throughout it s lifetime the process spends the virtual money in order to gain access to shared resources. Process priority is determined by the amount of virtual money they possess. That is a process with higher priority process would have a higher income and therefore have a greater chance of acquiring a shared resource for which it is competing with a lower priority process. [4] 3.4 Fault Tolerance

9 The Boot Service handles fault tolerance in the Amoeba operating system. Each server can register with the Boot Service at startup. The Boot Service polls all registered servers. If a server does not respond in time, it is declared broken. The boot server then sends a request to the process server to start a new copy of the server. The RPC mechanism in Amoeba is setup in such a way that if a client a does not receive a reply form the server within a certain it times and then resends the request. This timeout mechanism combined with the Boot Service provides for a very robust system. Since, the client resends the request after timeout and the each server is polled periodically by the boot service, the worst that can happen in case of a server crash is that the client would need to send more than one request. We should note that there is no possibility of either the client hanging indefinitely because it did not receive a reply form the server. Again, all of this is left transparent to the user. [4] 4. Amoeba Compared with Other Distributed OS

10 References 1. The Amoeba WWW Page, 2. Tannenbaum, A.S., and Sharp, Gregory J.: The Amoeba Distributed Operating System, 3. Tannenbaum, A.S., Renesse, R. van, Sharp, Gregory J., and Staveren, Hans van: Experiences with the Amoeba Distributed Operating System Communication of the ACM, vol. 33, pp , Dec Tannenbaum, A.S., and Renesse, R. van: Distributed Operating Systems, ACM Computing Surveys, vol 17, pp