Distributed Operating System

Mahesh GoyaniAssistant Professor,

1

© Mahesh Goyani

L D College of Engineering

Ahmedabad, Gujarat, INDIA

E-Mail: mgoyani@gmail.com

Web Site: www.maheshgoyani.in

A.Y: 2015-2016

Last Updated On: 07.08.2015

LECTURE NOTES ON

INTRODUCTION TO

2

© Mahesh Goyani

INTRODUCTION TO

DISTRIBUTED OPERATING SYSTEMS

COURSE DETAIL

TEXT BOOKS

Title Distributed Operating Systems

Author Andrew S. Tanenbaum

Publication Prentice Hall

3

© Mahesh Goyani

COURSE DETAIL

REFERENCE BOOKS

Title Distributed Operating Systems – Concepts & Design

Author Pradeep K. Sinha

Publication PHI

Title Advanced Concepts in Operating Systems

4

© Mahesh Goyani

Title Advanced Concepts in Operating Systems

Author Mukesh Singhal, N.G.Shivaratri

Publication Tata McGraw Hill

� Basics of Operating Systems

� C Language

� Basic UNIX Commands

� Shell Scripting

� Socket Programming

COURSE DETAIL

PREREQUISITE

5

© Mahesh Goyani

INTRODUCTION

6

© Mahesh Goyani

INTRODUCTION

� Review of OS Concepts

� Introduction to Distributed System

� Definition & Goal

� Hardware Concepts

� Software Concepts

� Design Issues

DISTRIBUTED OPERATING SYSTEM

ROADMAP

� Design Issues

7

© Mahesh Goyani

� Enhancement in microelectronic technology: 8 bit � 16 bit � 32 bit � 64 bit

� Availability of Fast, inexpensive, cost effective computers:

� Price / performance gain: 1011

� Price performance ratio favors use of interconnected, multi processor in place

of single, high speed processor

� Invention of high speed computer network: LAN & WAN

DISTRIBUTED OPERATING SYSTEM

MOTIVATION

� Invention of high speed computer network: LAN & WAN

� 64 Kbps to 10/100/1000 MBPS networks

� Centralized Approach � Distributed Approach

8

© Mahesh Goyani

� Definition: “A distributed system is a collection of independent computers that

appear to the users of the system as a single computer”

� Two aspects:

� HARDWARE: Machines are autonomous

� SOFTWARE: User think of a system as a single computer

� Example: E-Commerce business, Bank with large number of branches

DISTRIBUTED OPERATING SYSTEM

GOAL

� Example: E-Commerce business, Bank with large number of branches

� Each user’s workstation + Pool of processors

� Single file system

� Acts like classical single processor time sharing system

9

© Mahesh Goyani

� Driving force: Economy

� Grosch’s Law: Computing power of a CPU is proportional to the square of its

price. (Valid for mainframe computers only ☺ )

� Microprocessor technology has better price/performance ratio

� 10,000 CPU * 50 MIPS = 5,00,000 MPIS

� Single processor need to execute instruction in 0.002 ns : Impossible

GOALS

1. ADVANTAGE OF DS OVER CS

� Single processor need to execute instruction in 0.002 ns : Impossible

� Einstein's theory of relativity: Light can travel 0.6 mm in 0.002 ns

� Distributed system: Allows many users to work together

� Parallel system: To achieve maximum speed up on a single problem

10

© Mahesh Goyani

� Some applications are inherently distributed (Bank, Supermarket chain)

� Local decisions are made locally

� Updates query locally whole the day

� Computer Supported Cooperative Work – CSCW: Work together �

� Computer Supported Cooperative Games – CSCG: Play together ☺

� Higher reliability

GOALS

1. ADVANTAGE OF DS OVER CS

� Higher reliability

� Dominant consideration in critical applications like nuclear plant

� Incremental Growth

� Adding or changing mainframe can create havoc

11

© Mahesh Goyani

� Why not independent machine ?

1. Data sharing – Reservation systems

2. Sharing expensive resources like color printer, phototypesetter etc

3. Enhanced person to person communication: Electronic mail

A. Faster than paper mail

B. Does not require both party to be online at same time like telephone

GOALS

2. ADVANTAGES OF DC OVER INDEPENDENT PCS

B. Does not require both party to be online at same time like telephone

C. Unlike FAX, it is editable

4. Heterogeneous computing environment

A. Let jobs run on the most appropriate machine, rather than owner’s

machine

B. Reliable

12

© Mahesh Goyani

� Problems:

1. Software:

A. OS, Programming language, transparency ?

2. Communication network

A. Loss of message

B. Saturated network needs replacement

GOALS

3. DISADVANTAGES OF DS

B. Saturated network needs replacement

3. Easy way of data sharing

A. security

� Despite of these problems, many people feel that advantages of DS outweigh

the disadvantages

13

© Mahesh Goyani

CLASSIFICATION

14

© Mahesh Goyani

CLASSIFICATION

� Each DS consists of multiple CPUs, which can be organized in different ways

� Flynn’s Classification (1972):

1. SISD: All traditional uniprocessor computers at home and office

2. SIMD: Array processor, Some super computer

3. MISD: No known computer

4. MIMD: All DS

HARDWARE CONCEPT

FLYNN’S CLASSIFICATION

4. MIMD: All DS

15

© Mahesh Goyani

HARDWARE CONCEPT

CLASSIFICATION BY TANENBAUM

Parallel & Distributed

Computers

Multi processors Multi computers

MIMD

Tightly Coupled

(Less delay, High Data rate)

Loosely Coupled

(High delay, Low Data rate)

16

© Mahesh Goyani

Multi processors

(Shared Memory)

Parallel system

Multi computers

(Local Memory)

Distributed System

Bus Switched Bus Switched

Sequent,

Encore

Ultra computer,

RP3

Workstation on

LAN

Hypercube,

Transputer

� CPUs are connected to common bus along with memory

� Typical bus has 32 or 64 bit address, data and control line

� B reads same as A writes: Coherent

� Bus becomes bottleneck with as few as 4-5CPUs

� Solution � Cache memory (Hit + Miss) � Memory becomes incoherent

� Write through cache: When word is written to cache, its updated in memory

HARDWARE CONCEPT

1. BUS BASED MULTIPROCESSOR

� Write through cache: When word is written to cache, its updated in memory

� Snoopy cache: When write occurs in memory, cache entry is either removed

or updated with new value in memory (Always coherent)

� Support up to 64 processors

17

© Mahesh Goyani

CPU

Cache

CPU

Cache

CPU

CacheMemory

BUS

� To build multiprocessor with more than 64

processors different method is needed

� Crossbar switch:

� Divide memory in modules

� Connect memory module by cross bar switch

� CPUs can access memory simultaneously

HARDWARE CONCEPT

2. SWITCHED MULTIPROCESSOR

M M M M

C

C

C

C

Cross point Switch

� CPUs can access memory simultaneously

� No two CPUs can access same memory cell at

same time

� Downside: NM*NC cross point switches

� Omega switch: Fewer switches

� With ‘n’ CPUs and ‘n’ memory units, omega

network requires (nlog2n)/2 switching stage.

� Downside: Delay18

© Mahesh Goyani

C

C

C

C

M

M

M

M

2 X 2 Omega Switch

Cross bar Switch

� Hierarchical approach: Local + Shared memory

� NUMA: Non uniform memory access

� CPU can access its local memory quickly but accessing anybody else’s

memory is slower

� NUMA have better average access times than machines based on omega

networks

HARDWARE CONCEPT

2. SWITCHED MULTIPROCESSOR

networks

� Complications: Placement of program and data

19

© Mahesh Goyani

� Building multi computer without shared memory is easy

� Each CPU has direct access to its own local memory

� Problem: How CPUs communicate with each other

� CPU to CPU traffic is several orders of magnitude lower than CPU to Memory

� Bus need not be high speed backplane bus due to reduced traffic

HARDWARE CONCEPT

3. BUS BASED MULTI COMPUTERS

20

© Mahesh Goyani

Local

Memory

CPU

Workstation

Local

Memory

CPU

Workstation

Local

Memory

CPU

Workstation

Bus

� CPU has direct access to its private memory

� Grid: Suitable for problem that have an inherent 2D nature

� Path length grows in order of square root of number of CPUs

� Hypercube: n dimensional cube ( here n = 4 )

� Expand it to five dimension, add set of two interconnected cubes to figure

� Message have to make several hops to reach to destination

HARDWARE CONCEPT

4. SWITCHED MULTI COMPUTERS

� Message have to make several hops to reach to destination

� Path length grows in logarithmic order of number of CPUs

� For n-dimensional hypercube, each CPU is connected to n CPUs

� 16, 384 CPUs are available nowadays

21

© Mahesh Goyani

Grid Hypercube

TYPES OF OPERATING SYSTEM

22

© Mahesh Goyani

TYPES OF OPERATING SYSTEM

� Image of system presented to user is determined by software

� Unlike hardware, OS can not be distinguished cleanly.

� Roughly classified as,

� Loosely coupled software

� Allows users and machines to be independent of each other

� Interaction is limited, e.g. communication over LAN

SOFTWARE CONCEPT

SOFTWARE CONCEPTS

� Interaction is limited, e.g. communication over LAN

� If network goes down, independent machine can still continue to work

� Tightly coupled software

� Evaluating chess board on multiple processor simultaneously

� Software for such system require support from both – application program

and OS

23

© Mahesh Goyani

� Loosely coupled software on loosely coupled hardware

� Most common combination

� E.g. Collection of workstations connected by a LAN

� All machine has its own OS

� All command runs locally, right on the work station

� Sometimes possible to login in to another workstation by remote login

SOFTWARE CONCEPT

1. NETWORK OPERATING SYSTEM

� Sometimes possible to login in to another workstation by remote login

� rlogin machine � Remote Login

� rcp machine1:file1 machine2:file2 � Remote file copy

24

© Mahesh Goyani

� This form of communication is extremely primitive

� One approach is to provide shared file system: File Server

� File Server maintain file in hierarchical structure

� Client can import or mount and unmount directories

SOFTWARE CONCEPT

1. NETWORK OPERATING SYSTEM

� Different client have different view to

File System

25

© Mahesh Goyani

File System

� Client and server can run different OS,

but should agree on common file format

� Very limited coordination

� NOS are loosely coupled software on loosely coupled hardware

� Next evolution: Tightly coupled software on same loosely coupled (i.e. multi

computer) hardware: Single machine image / Virtual uniprocessor

� User should not have any idea about existence of multiple CPUs in system

� Characteristics of DS:

1. There must be single, global IPC mechanism, for local and remote

SOFTWARE CONCEPT

2. TRUE DISTRIBUTED SYSTEM

1. There must be single, global IPC mechanism, for local and remote

communication.

2. Process management (create, destroy, start, stop etc) must be same

3. File system must look same every where (e.g. file name length, visibility)

4. Same system call interface � identical kernels run on all CPUs

5. Kernel has control to manage own local resources: Swapping, Paging,

Scheduling26

© Mahesh Goyani

� Tightly coupled software on tightly coupled hardware

� Special purpose machine exists, like database machine

� Example: Unix with multiple CPUs: N CPU improve performance N fold

� Key characteristic: Single RUN QUEUE in shared memory

� Initial execution would be slow due to cache miss.

� If possible, allocate the same CPU to the process which comes back after

SOFTWARE CONCEPT

3. MULTIPROCESSOR TIMESHARING SYSTEM

� If possible, allocate the same CPU to the process which comes back after

performing I/O � To improve performance

� Busy waiting is preferable in case of short I/O

� Differs from other systems in organization of file : Lock cache

27

© Mahesh Goyani

Process A

Running

Cache

Process B

Running

Cache

Process C

Running

Cache OS

BUS

Run Queue: D, E

A (Running)

B (Running)

Disk

C (Running)

D (Ready)

E (Ready)

SOFTWARE CONCEPT

COMPARISON OF OS

Item NOS DOS MOS

Does it look like a virtual uniprocessor? NO YES YES

Do all have to run same OS? NO YES YES

How many copies of OS are there ? N N 1

28

© Mahesh Goyani

How is communication achieved ? Shared files Messages Shared Memory

Are agreed upon network protocols required ? YES YES NO

Is there a single run queue ? NO NO YES

Does file sharing have well defined semantics? Usually NO YES YES

DESIGN ISSUES

29

© Mahesh Goyani

DESIGN ISSUES

� Big Question: How to achieve single system image ?

� Transparency can be achieved at two different levels:

1. Hide distribution from user: make command in UNIX to compile the

program � Compilation may proceed in parallel on any machines

2. System call interface can be designed in such a way so that existence of

DESIGN ISSUES

1. TRANSPARENCY

multiple processor is not visible

30

© Mahesh Goyani

DESIGN ISSUES

1. TRANSPARENCY

Type Meaning

Location Users can not tell where software (database, files) and hardware (CPU,

printer) resources are located. Machine1:prog.c is not acceptable

Migration Resources can move at will without changing their names: Directory

hierarchy. /games/news � /work/news

31

© Mahesh Goyani

Replication User can not tell how many copies exists ( Server forms a ring to

serve/forward user request and replicate heavily used files)

Concurrency Multiple users can share resources automatically (Lock the resource so

multiple user can not access simultaneously)

Parallelism Activities can happen parallel without user knowing (hardest to

achieve). Evaluate chess board on multiple CPU

� In case of printer, user don’t wont transparency

� We are in learning mode, so there must be a way to correct error or backtrack

� Design seem reasonable now may later prove to be wrong later

� Monolithic Kernel: Today's’ centralized OS augmented with network facility

and integration of remote services

� System calls are made by trapping the kernel, having the work performed

there, and having the kernel return desired result to user process

DESIGN ISSUES

2. FLEXIBILITY

there, and having the kernel return desired result to user process

� Machines have their own disk and manage their own local file system: UNIX

� Only advantage is performance – Faster than micro kernel (SPRITE)

32

© Mahesh Goyani

File Server

Micro Kernel

Directory

Server

Micro Kernel

Process

Server

Micro Kernel

Network

User

Micro Kernel

User

Monolithic Kernel

Includes file, directory and

process management

� Micro Kernel: More flexible, provides following services

1. IPC mechanism

2. Some memory management

3. Small amount of low level process management & Scheduling

4. Low level I/O

� Unlike monolithic kernel, it does not provide file system, directory structure,

DESIGN ISSUES

2. FLEXIBILITY

� Unlike monolithic kernel, it does not provide file system, directory structure,

full process management or much system call handling

� All other OS services are implemented in user space like read file, write file…

� Easy to implement, install and debug services

� This method is highly modular with well defined interface

� User are free to write their own service

� E.g: AMOEBA

33

© Mahesh Goyani

� One machine goes down, some other machine serve the purpose

� Aspects of Reliability:

1. Availability: Refers to the fraction of time that the system is usable.

� Availability can be improved by replicating resources or by enhancing

the design such that critical components are not accessed

simultaneously

DESIGN ISSUES

3. RELIABILITY

simultaneously

� Highly reliable system must be highly available.

� More copies � Better availability � Chances of inconsistency

2. Security: Resources must be protected

3. Fault tolerance: Proper arrangement of closely connected servers

� Performance degradation

34

© Mahesh Goyani

� No meaning of conquering other design issues if system does not perform well

� Running the application on DS should not be worst then running it on single

processor system

� Performance matrices:

� Response time: Time required to finish a single job

� Throughput: Number of jobs per hour

DESIGN ISSUES

4. PERFORMANCE

� Throughput: Number of jobs per hour

� System Utilization: CPU usage

� Network capacity consumed: Bandwidth used

� To optimize performance in DS, minimize number of messages

� Do all task on single machine (Hardly appropriate in DS)

� Fine grained : large number of small computation, high interaction � Local

� Coarse gained : large computation, low interaction, little data � Remote35

© Mahesh Goyani

� Network may grow with growth of business

� Expand the network by adding machines

� Minitel terminal in France � Telephone database

� Terminals are ready so can be extended to use mail service, other database etc

� Guiding principle in DS: AVOID CENTRALIZED COMPONENTS

DESIGN ISSUES

5. SCALABILITY

36

© Mahesh Goyani

Concept Example

Centralized component A single mail server for all users

Centralized Table A single online telephone book

Centralized Algorithm Doing routing based on complete information

Potential bottlenecks that should be avoided

� Only decentralized algorithm should be used:

1. No machine has complete information about the system state

2. Machine make decisions based only on local information

3. Failure of one machine does not ruin the algorithm

4. There is no implicit assumption that a global clock exists

DESIGN ISSUES

5. SCALABILITY

37

© Mahesh Goyani

Mahesh Goyani has completed his graduation in Computer Engineering from SCET, VNSGU,

Surat in 2005 with distinction. He received his Master Degree in field of Computer

Engineering with 9.38 CPI (81.03 %) from BVM College, SPU, Anand in 2009. He has secured

1st rank twice in university during his master degree. His area of interest is Image Processing,

Computer Algorithms and Computer Graphics. He has also done graduation in Gujarati

literature from Gujarat University in 2014.

Publication: He has published many research papers in national and international journals and conferences. He

was invited as a SESSION CHAIR in International Conference on Engineering, Science and Information Technology,

AUTHOR’S PROFILE

38

© Mahesh Goyani

was invited as a SESSION CHAIR in International Conference on Engineering, Science and Information Technology,

Tirunelveli, Tamilnadu, Sept - 2011. He has published three books - two on Computer Graphics and one on Design

and Analysis of Algorithms.

Editorial: He is the member of technical review committee of International Journal of Computer Science & Issues

(IJCSE, Mauritius), Electronics & Telecommunication Research Institute (ETRI, Korea), International journal of

Engineering & Technology (IJET, Singapore), International journal of Computer Science & Information Security

(IJCSIS, Pittsburg, USA). He has worked as a program committee member and reviewer in many International

Conferences and Journals. He is also a life time member of ISTE technical society.

Web Site: www.maheshgoyani.in