An Overview of the Amoeba Distributed Operating System Mallikarjuna Reddy Srinivas Vadlamani University of California Irvine

Outline Introduction What is Amoeba? Design goals Architecture Communication primitives Resource management Priority Mechanism Summary Acknowledgements

Motivation for Distributed Systems Fall in microprocessor prices during early 80’s Mainframes set-up expensive Search for efficient and economical substitutes Goals Distributed Resource Management High Availability Simplicity Parallelism Transparency scalability fast file system Due to advances in integrated circuit technology in the early 80s, prices of microprocessors fell. With mainframe set-ups extremely expensive, people started searching for alternatives that could be efficient and economical. This led to development of the area of distributed systems.

Design Goals of Amoeba Distribution: connecting together many machines Transparency: collection of computers acting like a single system Parallelism: allowing individual jobs to use multiple CPUs Example: the traveling salesman problem Fault Tolerance Boot Service Performance: achieving all of the above in an efficient manner We have already seen the first two – distribution and transparency – and are fairly obvious. Parallelism is allowing a task to be executed by dividing it among multiple CPUs and then merging the results. A typical example could be the classic TSP. If we have tens or even thousands of CPUs at our disposal, then we can break the problem into pieces and have them executed by all the CPUs in parallel, and later merge the results from all of them. The performance goal is to achieve all the other goals in an efficient and economical manner.

Architecture Workstations Used by users to access the system Limited processing power but not “dumb” Pool Processors Heavy duty computation Dynamically allocated to user tasks Can be multicomputers or multiprocessors Specialized Servers Example: File or Directory servers Gateway Connects Amoeba to a WAN Converts data between FLIP and TCP/IP The Amoeba architecture has 4 components. Workstations are used by the users to access the system, and they have some processing capability although limited. This is to allow execution of tasks with a high expected response time – like graphical input/output. Then there is a pool processors, which is a group of computers that actually do all the heavy duty computation. They are not owned by any user, and are only dynamically allocated to the user’s tasks. Examples of Specialized servers are file servers and directory servers. Lastly, we have a gateway that connects the Amoeba system to a WAN. As we shall later see, Amoeba uses a FLIP protocol for internal communication. So, for getting connected to a WAN, which normally uses TCP/IP, we need a gateway that can do the protocol conversion. We will talk about FLIP soon.

Architecture contd... WAN This is a graphical representation of the Amoeba system: We have the pool processors, all interconnected with Amoeba running on them. Now, we have the individual users accessing the system from workstations. The pool processors are abstracted so that the users think they are working on a uniprocessor, which is how transparency is achieved. Here we have a specialized server, which could be a file server. Here again, the user does not know, where and how his file data is handled by the system. Now, we have another specialized server, and this could be a directory server. Finally, here is the gateway that connects the Amoeba system to the WAN. It does FLIP to TCP/IP and back data conversion.

Communication Primitives Remote procedure call based FLIP protocol for communication: Fast Local Internet Protocol Advantage: increased performance over TCP/IP Disadvantage: need a gateway to connect the LAN to a WAN Amoeba Interface Language (AIL) Generates stubs Handles marshalling/unmarshalling of parameters Preserves transparency of the system The communication is RPC based; the client generates a request, marshals the parameters and sends them across to the server; the sever unmarshalls the data, processes the request, and sends back the results to the client. They use the FLIP, which stands for Fast Local Internet Protocol. The advantage of this protocol is its enhanced performance in terms of speed over TCP. However, the disadvantage is that now we have to use a gateway to connect the system to a WAN. To preserve transparency, the system uses the Amoeba Interface Language which is similar to the compilers that we have for RPC. The AIL does stuff like generating stubs, handling marshalling and unmarshalling of parameters, and lets the user not worry about such communication details.

Resource Management Computation done by processor pools Resource Manager on each node Tracks and controls resources on its node Dedicated Process Server Tracks which processors are free Allocates tasks to a group of processors Preserves transparency Allocation process is unknown to the user User has no control over allocation As was seen in the previous slides, computation is done by pool processors. The way resource allocation is done is by having a resource manager at each node that tracks and controls resources on that node, and having a centralized dedicated process server that tracks which processors are free, so tasks could be allocated to them. Again, transparency is preserved by not letting the user be aware of the resource mechanism.

Priority Mechanism A Bank Server Analogy with a monetary bank Regulates access to shared resources Example of a shared resource is processing power of CPUs On initiation each process gets some number of tokens Can be thought of as “virtual money” held by the process To gain access to shared resources, process has to expend money At any given moment, the “richest” process gets access to the shared resource Amoeba has a priority mechanism, where it has a designated bank server that regulates access to shared resources like processing power of CPUs utilized by a user’s process. The bank server is analogous to a monetary bank. Each time a process starts, it is given some virtual money, which it uses to gain access to shared services. At any given amount, the process with the most virtual money is given access to the shared process. The mechanism is much more elaborate than could be described here. This is only a very brief description of the mechanism.

Summary Architectural Features Transparent distributed computing using a large number of processors Support for parallel computing Micro-kernel architecture High performance communication using RPC and FLIP Weaknesses Not compatible with UNIX Virtual memory not supported (for performance reasons) Performs poorly when there is insufficient memory No NFS support

Acknowledgements Andrew S. Tanenbaum et al The Amoeba Distributed Operating System – A Status Report Apan Qasem, CS Dept, Florida State University An Introduction to the Amoeba Distributed Operating System Yasir Ali An Overview of the Amoeba Distributed Operating System Kingsley Cheung, Gernot Heiser, School of Computer Science and Engineering, University of NSW, Sydney, Australia A Resource Management Framework for Priority-Based Physical Memory Allocation