An Introduction to the
Amoeba Distributed
Operating System
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.
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-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.
Workstations
ii.
Processor Pool
iii.
Specialized Servers
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.
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 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.
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
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
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