Robbert van Renesse

Distributed operating systems

In the past five years, distributed operating systems research has gone through a consolidation phase. On a large number of design issues there is now considerable consensus between different research groups. In this paper, an overview cf recent research in distributed systems is given. In turn, the paper discusses overall system structure, protection issues, file system designs, problems and solutions for fault tolerance and a mechanism that is rapidly becoming very important for efficient distributed systems design: hints. An attempt was made to provide sufficient references to interesting research projects for the reader to find material for more detailed study.

Experiences with the Amoeba distributed operating system

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.nAmoeba 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.nIn 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 files position in the directory hierarchy has no relation to its location.nThe 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.nBefore describing the software, however, it is worth saying something about the system architecture on which Amoeba runs.

Performance of the world's fastest distributed operating system

Distributed operating systems have been in the experimental stage for a number of years now, but few have progressed to the point of actually being used in a production environment. It is our belief that the reason lies primarily with the performance of these systems---they tend to be fairly slow compared to traditional single computer systems. The Amoeba system has been designed with high performance in mind. In this paper some performance measurements of Amoeba are presented and comparisons are made with UNIX on the SUN, as well as with some other interesting systems. In particular, short remote procedure calls take 1.4 msec and long data transfers achieve a user-to-user bandwidth of 677 kbytes/sec. Furthermore, the file server is so fast that it is limited by the communication bandwidth to 677 kbytes/sec. The real speed of the file server is too high to measure. To the best of our knowledge, these are the best figures yet reported in the literature for the class of hardware used.

The Amoeba distributed operating system—a status report

Abstract As the price of CPU chips continues to fall rapidly, it will soon be economically feasible to build computer systems containing a large number of processors. The question of how this computing power should be organized, and what kind of operating system is appropriate then arises. Our research during the past decade has focused on these issues and led to the design of a distributed operating system called Amoeba which is intended for systems with large numbers of computers. Amoeba, its philosphy, design, applications and some experience with it are described here.

The evolution of a distributed operating system

AMOEBA is a research project to build a true distributed operating system using the object model. Under the COST11-ter MANDIS project this work was extended to cover wide-area networks. Besides describing the system, this paper discusses the successive versions in the implementation of its model, and why the changes were made. Its purpose is to prevent ourselves and others from making the same mistakes again, and to illustrate how a distributed operating system grows in sophistication and size.

FLIP; an Internetwork Protocol for Supporting Distributed Systems

Most modern network protocols give adequate support for traditional applications such as file transfer andremote login. Distributed applications, however, have different requirements (e.g., efficient at-most-once remote procedure call even in the face of processor failures). Instead of using ad hoc protocols to meet each of the new reqmrements, we have designed a new protocol, called the Fast Local Internet Protocol (FLIP), that provides a clean and simple integrated arwmmchto these new requirements. FLIP is an unreliable message protocol that provides both point-to-point communication and multicast communication, and requires almost no network management. Furthermore, by using FLIP we have simplified higher-level protocols such as remote procedure call and group communication, and enhanced support for process migration and security. A prototype implementation of FLIP has been built as part of the new kernel for the Amoeba distributed operating system, and isin daily use. Measurements of its performance are presented,

Making distributed systems palatable

Designing and implementing a distributed system is easy compared to the task of convincing people to use it. In a university Computer Science Dept., people generally use UNIX and are not at all interested in moving to a different environment, no matter how wonderful it may be. In this paper we report on how we have implemented a UNIX environment for the Amoeba distributed operating system [1], in order to make the transition from UNIX to Amoeba as simple as possible.

Functional specialization in distributed operating systems

A distributed operating system provides the same functionality and interface as a monolithic operating system. That is, for both systems the goal is to make the computing and storage facilities as provided by the hardware available to the users of the system. In distributed operating system new hardware can be added to the system to increase the storage or computing power, or to increase the availability of the storage and computing services. During and after this addition, the interface to the system remains unchanged. Transparency of access is a key concept.The top-level interface consists of sophisticated command interpreters and editors, supported by a high-resolution graphical window system. This software is run by workstations. Workstations are powerful computer units, consisting of a CPU, memory, a bitmap display, keyboard, a pointing device such as a mouse, and a network interface. In addition, workstations are often equipped with a disk. The CPU is at least as powerful as those used in traditional computer systems, and the amount of memory is equivalent or even larger.A workstation is dedicated to one individual. Consequently, the workstation is idle most of the time. It is therefore tempting to use it as the main computing resource for the owner and perhaps others as well. It could also be used autonomously from the rest of the system in case of a failure. We are opposed to these uses of workstations, since we believe that workstations should only provide the top-level interface. In this paper we will outline our reasons for this, and show how this principle has been applied in the Amoeba distributed operating system.