Andrew S. Tanenbaum
Robbert van Renesse
Hans van Staveren
Abstract
The Amoeba project is a research effort aimed at understanding how to connect multiple computers in a seamless way [16, 17, 26, 27, 31]. The basic idea is to provide the users with the illusion of a single powerful timesharing system, when, in fact, the system is implemented on a collection of machines, potentially distributed among several countries. This research has led to the design and implementation of the Amoeba distributed operating system, which is being used as a prototype and vehicle for further research. In this article we will describe the current state of the system (Amoeba 4.0), and show some of the lessons we have learned designing and using it over the past eight years. We will also discuss how this experience has influenced our plans for the next version, Amoeba 5.0.
Amoeba was originally designed and implemented at the Vrije Universiteit in Amsterdam, and is now being jointly developed there and at the Centrum voor Wiskunde en Informatica, also in Amsterdam. The chief goal of this work is to build a distributed system that is transparent to the users. This concept can best be illustrated by contrasting it with a network operating system, in which each machine retains its own identity. With a network operating system, each user logs into one specific machine—his home machine. When a program is started, it executes on the home machine, unless the user gives an explicit command to run it elsewhere. Similarly, files are local unless a remote file system is explicitly mounted or files are explicitly copied. In short, the user is clearly aware that multiple independent computers exist, and must deal with them explicitly.
In contrast, users effectively log into a transparent distributed system as a whole, rather than to any specific machine. When a program is run, the system—not the user—decides upon the best place to run it. The user is not even aware of this choice. Finally, there is a single, system-wide file system. The files in a single directory may be located on different machines, possibly in different countries. There is no concept of file transfer, uploading or downloading from servers, or mounting remote file systems. A file's position in the directory hierarchy has no relation to its location.
The remainder of this article will describe Amoeba and the lessons we have learned from building it. In the next section, we will give a technical overview of Amoeba as it currently stands. Since Amoeba uses the client-server model, we will then describe some of the more important servers that have been implemented so far. This is followed by a description of how wide-area networks are handled. Then we will discuss a number of applications that run on Amoeba. Measurements have shown Amoeba to be fast, so we will present some of our data. After that, we will discuss the successes and failures we have encountered, so that others may profit from those ideas that have worked out well and avoid those that have not. Finally we conclude with a very brief comparison between Amoeba and other systems.
Before describing the software, however, it is worth saying something about the system architecture on which Amoeba runs.
- 1 Accetta, M., Baron, R., Bolosky W., Golub, D., Rashid, R., Tevanian, A., and Young, M. Mach: A new kernel foundation for Unix Development. In Proceedings of the Summer Usenix Conference (Atlanta, CA, July 1986).Google Scholar
- 2 Baalbergen, E.H., Verstoep, K., and Tanenbaum, A.S. On the design of the Amoeba configuration manager. In Proceedings of the 2d International Workshop on Software Configuration Management ACM, N.Y., (1989). Google ScholarDigital Library
- 3 Bal, H.E., Van Renesse, R., and Tanenbaum, A.S. Implementing distributed algorithms using remote procedure call. In Proceedings of the National Computer Conference, AFIPS (1987), pp. 499-505.Google Scholar
- 4 Bal, H.E., and Tanenbaum, A.S. Distributed programming with shared data. IEEE Conference on Computer Languages, IEEE (1988), pp. 82-91.Google ScholarCross Ref
- 5 Birrell, A.D., and Nelson, B.J. Implementing remote procedure calls. ACM Trans. Comput. Syst. 2 (Feb. 1984), 39-59. Google ScholarDigital Library
- 6 Cheriton, D.R. The V distributed system. Commun. ACM 31 (March 1988), 314-333. Google ScholarDigital Library
- 7 Dalal, Y.K. Broadcast protocols in packet switched computer networks. Ph.D. dissertation, Stanford Univ., 1977. Google ScholarDigital Library
- 8 Dennis, J., and Van Horn, E. Programming semantics for multiprogrammed computation. Commun. ACM 9 (March 1966), 143- 155. Google ScholarDigital Library
- 9 Evans, A., Kantrowitz, W., and Weiss, E. A user authentication scheme not requiring secrecy in the computer. Commun. ACM 17 (Aug. {1974), 437-442. Google ScholarDigital Library
- 10 Feldman, S.I. Make--A program for maintaining computer programs. SoftwaremPractice and Experience 9 (April 1979), 255-265.Google ScholarCross Ref
- 11 Johnson, S.C. Yaccmyet another compiler compiler. Bell Labs Tech. Rep., Bell Labs, Murray Hill, N.J., 1978.Google Scholar
- 12 Kaashoek, M.F., Tanenbaum, A.S., Flynn Hummel, S., and Bal, H.E. An efficient reliable broadcast protocol. Oper. Syst. Rev. 23 (Oct 1989), 5-19. Google ScholarDigital Library
- 13 Lawler, E.L., and Wood, D.E. Branch and bound Methods A Survey. Oper. Res. 14 (July 1966), 699- 719.Google ScholarDigital Library
- 14 Marsland, T.A., and Campbell, M. Parallel search of strongly ordered game trees. Comput. Surv. 14 (Dec. 1982), 533-551. Google ScholarDigital Library
- 15 Mullender, S.J., and Tanenbaum, A.S. A distributed file service based on optimistic concurrency control. In Proceedings of the Tenth Symposium Operating System Principles (Dec. 1985), pp. 51-62. Google ScholarDigital Library
- 16 Mullender, S.J., and Tanenbaum, A.S. The design of a capabilitybased distributed operating system. Comput.J. 29 (Aug. 1986), 289-299.Google ScholarCross Ref
- 17 Mullender, S.J., van Rossum, G., Tanenbaum, A.S., van Renesse, R., van Staveren, J.M. Amoeba--A distributed operating system for the 1990s. IEEE Comput. 23 (May 1990), 44-53. Google ScholarDigital Library
- 18 Ousterhout, J.K., Cherenson, A.R., Douglis, F., Nelson, M.N., and Welch, B.B. The sprite network operating system. IEEE Comput. 21 (Feb. 1988), 23-26. Google ScholarDigital Library
- 19 Peterson, L., Hutchinson, N., O'Malley, S., and Rao, H. The xkernel: A platform for accessing Internet resources. IEEE Comput. 23 (May 1990), 23-33. Google ScholarDigital Library
- 20 Pu, C., Noe, J.D., Proudfoot, A. Regeneration of replicated objects: A technique and its Eden implementation. In Proceedings of the 2nd International Conference on Data Engineering (Feb. 1986), pp. 175-187. Google ScholarDigital Library
- 21 Rozier, M., Abrossimov, V., Armand, F., Boule, I., Gien, M., Guillemont, M., Hermann, F., Kaiser, C., Langlois, S., Leonard, P., and Neuhauser, W. CHORUS distributed operating system. Comput. Syst. I (Fall 1988), 299-328.Google Scholar
- 22 Schroeder, M.D., and, Burrows, M. Performance of the firefly RPC. in Proceedings of the Twelfth ACM Symposium of Operating System Principles, ACM, N.Y. (Dec. 1989), 83-90. Google ScholarDigital Library
- 23 Steiner, J.G., Neuman, C., and Schiller, J.I. Kerberos An Authentication Service for Open Network Systems. In Proceedings of the Usenix Winter Conference, USENIX Assoc. (1988), pp. 191-201.Google Scholar
- 24 Stonebraker, M. Operating system support for database management. Commun. ACM 24 (July 1981) 412- 418. Google ScholarDigital Library
- 25 Tanenbaum, A.S. A Unix clone with source code for operating systems courses. Oper. Syst. Rev. 21 (Jan. 1987), 20-29. Google ScholarDigital Library
- 26 Tanenbaum, A.S., Mullender, S.J., and Van Renesse, R. Using sparse capabilities in a distributed operating system, in Proceedings of the Sixth International Conference on Distributed Computer Systems, IEEE (1986), 558- 563.Google Scholar
- 27 Tanenbaum, A.S., and Van Renesse, R. Distributed operating systems. Comput. Surv. 17 (Dec. 1985), 419-470. Google ScholarDigital Library
- 28 Tanenbaum, A.S., and Van Renesse, R. A critique of the remote procedure call paradigm. In Proceedings of Euteco '88 (1988), pp. 775-783.Google Scholar
- 29 Van Renesse, R., Tanenbaum, A.S., Van Staveren, H., and Hall, J. Connecting RPC-based distributed systems using wide-area networks. In Proceedings of the Seventh International Conference on Distributed Computing Systems, IEEE (1987), pp. 28- 34.Google Scholar
- 30 Van Renesse, R. Tanenbaum, A.S., and Wilschut, A. The design of a high-performance file server. In Proceedings of the Ninth International Conference on Distributed Computer Systems, IEEE (1989), pp. 22-27.Google ScholarCross Ref
- 31 Van Renesse, R., Van Staveren, H., and Tanenbaum, A.S. Performance of the world's fastest distributed operating system. Oper. Syst. Rev. 22 (Oct. 1988), 25-34. Google ScholarDigital Library
- 32 Van Renesse, R., Van Staveren, H., and Tanenbaum, A.S. Performance of the Amoeba-distributed operating system. Software--Practice and Experience 19 (March 1989) 223- 234. Google ScholarDigital Library
- 33 Van Rossum, G. AIL--A classoriented stub generator for Amoeba. In Proceedings of the Workshop on Experience with Distributed Systems, J. Nehmer, Ed., Springer Verlag, N.Y., 1990. To be published.Google Scholar
- 34 Welch, B.B. and Ousterhout, J.K. Pseudo devices: User-level extensions to the Sprite file system. In Proceedings of Summer USENIX Conference (June 1988), pp. 37-49.Google ScholarCross Ref
Index Terms
- Experiences with the Amoeba distributed operating system
Recommendations
Amoeba: A Distributed Operating System for the 1990s
A description is given of the Amoeba distributed operating system, which appears to users as a centralized system but has the speed, fault tolerance, security safeguards, and flexibility required for the 1990s. The Amoeba software is based on objects. ...
The DUNIX distributed operating system
DUNIX is an operating system that integrates several computers, connected by a packet switching network, into a single UNIX machine. As far as the users and their software can tell, the system is a single large computer running UNIX. This illusion is ...
Reviews
Jason Gait
Amoeba is an ambitious distributed operating system implemented on a widely scattered ensemble of machines. Amoeba aspires to be much more than a conventional network operating system in which each machine retains its visibility and must be dealt with independently. The authors do not mention the positive side of network operating systems and the primary reason for their evolution: the preservation of local autonomy and control. The Amoeba system architecture presupposes a workstation for each user where tasks that require fast interactive responses are carried out. The heart of Amoeba is the concept of a pool of processors. Each machine in the pool is allocated dynamically to a specific program and is returned to the pool when the program finishes. Conventional operating system services, such as directory and file services, are provided by dedicated machines that are responsible for specific services. Some Amoeba machines are dedicated as gateways between separated local area networks, which are connected via one of several wide area technologies. Amoeba gateways are responsible for hiding grubby wide-area details from the rest of the system. The Amoeba machines all run the same small kernel, responsible only for multithread processes, IPC, and I/O. Amoeba does not support virtual memory. The Amoeba presentation layer is object-based. Each Amoeba object, such as a directory or file, is managed by a server. Amoeba locates a server by broadcasting a request for service within the local area; local servers respond with their address. A service is located across a gateway by virtue of having published its address at the gateway. Unwillingly, it seems, Amoeba attempts to realize a UNIX system call interface. Amoeba does not support the signal, fork, or exec system calls, but it has an adequate infrastructure for 100 common utility programs that partly define a UNIX user environment. Local network IPC performance seems to be roughly comparable to the V-kernel and is superior to most protocol-heavy UNIX IPC. Amoeba implements a system-wide file system that incorporates location transparency. The important file server for Amoeba, optimized for high performance, is the Bullet Server. The Bullet Server stores files in 30-kbyte extents, both on disk and in memory, and moves files about the network as integral objects. Amoeba does not incorporate page caching in the network. The Bullet Server never overwrites a file, but creates a new version whenever a file is updated. Old versions of files can only be explicitly deleted by their owners. The efficiencies in the Bullet Server come from two optimizations: at boot time the Bullet Server copies the file system metadata into memory and keeps it there, and files no larger than 30 kbytes are retrieved from disk in one access and sent across the network in one message. The Bullet Server only understands capabilities; a separate name server translates user object names (represented as ASCII strings) into capabilities (represented as 128-bit numbers) that the Bullet Server uses to access files. In the authors' evaluation of the successes of Amoeba, they express satisfaction with the object system, capabilities, the performance of IPC, directory service, file service, the basic design of the wide area protocols, the processor pool, and overall performance. They express dissatisfaction with the IPC packet acknowledgment protocol, lack of support for multicast, asynchronous IPC, non-preemptable threads, lack of an IPC timeout protocol, the performance of the wide-area protocols, the quality of the UNIX emulation, and the lack of support for link encryption. They promise that the next version of Amoeba will correct these perceived problems. The authors are undecided about some areas, including the lack of support for virtual memory, the split between directory service and file service, and the lack of support for process migration. Early on, Amoeba realized a small, efficient window management system. The authors made a reluctant, too hasty and too commercial, decision to switch to X-W indows. I have a couple of additional reservations about Amoeba. I am not content with the decision to dedicate physical machines from the pool of processors to single (multithreaded) programs. This seems to be a waste of CPU bandwidth, especially when the MIPS rating of candidates for the pool of processors is rising exponentially and virtual machine technologies are well known. In the past, distributed systems of all flavors have optimized for the local case. Amoeba optimizes for the remote case under the assumption that remote operations will be more common than local operations in an environment where remote operations are adequately supported. Although the authors are pleased with this optimization, to me it is a Scots verdict.
Access critical reviews of Computing literature here
Become a reviewer for Computing Reviews.
Comments