Home | Engineering | Distributed Systems - CS6601 | Distributed Systems - CS8603 | Case Study of a Distributed Operating System

Chapter: Distributed Systems - Communication in Distributed System

Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

Case Study of a Distributed Operating System

The Amoeba System Architecture

Case Study of a Distributed Operating System

 

Introduction to Amoeba

 

       Originated at a university in Holland, 1981

       Currently used in various EU countries

 

       Built from the ground up. UNIX emulation added later

       Goal was to build a transparent distributed operating system

 

       Resources, regardless of their location, are managed by the system, and the user is unaware of where processes are actually run

 

 

The Amoeba System Architecture

 

       Assumes that a large number of CPUsare available and that each CPU ha 10s of Mb of memory

 

       CPUs are organised into processor pools

 

        CPUs do not need to be of the same architecture (can mix SPARC, Motorola PowerPC, 680x0, Intel, Pentium, etc.)

 

        When a user types a command, system determines which CPU(s) to execute it on. CPUs can be timeshared.

 

        Terminals are X-terminals or PCs running X emulators

 

        The processor pool doesn't have to be composed of CPU boards enclosed in a cabinet, they can be on PCs, etc., in different rooms, countries,...

 

        Some servers (e.g., file servers) run on dedicated processors, because they need to be available all the time

The Amoeba Microkernel

 

       The Amoeba microkernel is used on all terminals (with an on-board processor), processors, and servers

 

       The microkernel

 

o   manages processes and threads

 

o   provides low-level memory management support

 

o   supports interprocess communication (point-to-point and group)

 

o   handles low-level I/O for the devices attached to the machine

 

The Amoeba Servers: Introduction

 

       OS functionality not provided by the microkernel is performed by Amoeba servers

 

       To use a server, the client calls a stub procedure which marshalls parameters, sends the message, and blocks until the result comes back

 

Server Basics

 

       Amoeba uses capabilities

       Every OS data structure is an object, managed by a server

       To perform an operation on an object, a client performs an RPC with the appropriate server, specifying the object, the operation to be performed and any parameters needed.

       The operation is transparent (client does not know where server is, nor how the operation is performed)

       Capabilites

 

To create an object the client performs an RPC with the server

 

Server creates the object and returns a capability

 

To use the object in the future, the client must present the correct capability


 

The check field is used to protect the capability against forgery

 

Object protection

When an object is created, server generates random check field, which it stores both in the capability and in its own tables

 

The rights bits in the capability are set to on

 

The server sends the owner capability back to the client Creating a capability with restricted rights


Client can send this new capability to another process

 

Process Management

 

       All processes are objects protected by capabilities

       Processes are managed at 3 levels

 

by process servers, part of the microkernel by library procedures which act as interfaces

 

by the run server, which decides where to run the processes

       Process management uses process descriptors

 

Contains:

 

platform description process' owner's capability etc

 

Memory Management

 

       Designed with performance, simplicity and economics in mind

       Process occupies contiguous segments in memory

       All of a process is constantly in memory

       Process is never swapped out or paged

 

Communication

 

       Point-to-point (RPC) and Group

The Amoeba Servers

 

The File System

 

       Consists of the Bullet (File) Server, the Directory Server, and the Replication Server

 

The Bullet Server

 

       Designed to run on machines with large amounts of RAM and huge local disks

       Used for file storage

       Client process creates a file using the create call

       Bullet server returns a capability that can be used to read the file with

 

       Files are immutable, and file size is known at file creation time. Contiguous allocation policies used

 

The Directory Server

 

       Used for file naming

       Maps from ASCII names to capabilities

       Directories also protected by capabilities

       Directory server can be used to name ANY object, not just files and directories

 

The Replication Server

 

       Used for fault tolerence and performance

       Replication server creates copies of files, when it has time

 

Other Amoeba Servers

 

The Run Server

 

       When user types a command, two decisions have to be made

 

o   On which architecture should the process be run?

 

o   Which processor should be chosen?

 

       Run server manages the processor pools


 

       Uses processes process descriptor to identify appropriate target architecture

 

       Checks which of the available processors have sufficient memory to run the process   Estimates which of the remaining processor has the most available compute power

 

The Boot Server

 

       Provides a degree of fault tolerance

       Ensures that servers are up and running

 

       If it discovers that a server has crashed, it attempts to restart it, otherwise selects another processor to provide the service

 

       Boot server can be replicated to guard against its own failure

 

 


Tags : Distributed Systems - Communication in Distributed System
Study Material, Lecturing Notes, Assignment, Reference, Wiki description explanation, brief detail

OTHER SUGEST TOPIC