Dist System Guha 04

8/2/2019 Dist System Guha 04

1/60

Distributed Systems and Applications

Ratan Guha

School of Computer Science

University of Central Florida

Orlando, FL 32816

[email protected]

August 3, 2004
mailto:[email protected]:[email protected]


2/60

Module Objectives

Important principles of distributedsystems

Some of the paradigms of distributedsystems

High Level Architecture (HLA)


3/60

Topics on Principles of Distributed

Systems

Communication Processes

Naming Synchronization

Consistency and replication Fault tolerance


4/60

Some of the Paradigms of

Distributed Systems

Object based systems CORBA, DCOM, GLOBE

Distributed file systems

Sun NFS, CMU Coda

Document-based systems WWW, LOTUS Notes

Coordination-based systems Sun Jini


5/60

High Level Architecture

The HLA is a software architecture forcreating computer models or simulations

out of component models or simulations

The HLA contains much that is generic to

distributed computer systems

The HLA is used to build distributedsystems


6/60

Text and Recommended Books

A. S. Tanenbaum and M. van Steen,DistributedSystems Principles and Paradigms, Prentice Hall

Inc., 2002.

Recommended books G. Coulouris, J. Dollimore, and T. Kindberg,

Distributed Systems Concepts and Design, Third

Edition, Addison Wesley, 2001.

F. Kuhl, R. Weatherly, J. Dahmann, Creating Computer

Simulation Systems, Prentice Hall Inc., 1999.


7/60

Course on Distributed Systems and

Applications

Principles of Distributed Systems

High Level Architecture


8/60

Outline of This Lecture

Background of students

General Concepts

Important ideas on principles of distributed

computing systems in the context of the class Discussion about the class

Discussion about the laboratory (afternoon)


9/60

Background of Students Completed core courses in computer science

However some of the students also completed

advanced required elective courses in computer

architecture, operating systems etc.

Students did not have any course on Computer

Networks


10/60

Definition of a Distributed System (1)

A distributed system is:

A collection of independent

computers that appears to itsusers as a single coherent

system.


11/60

Definition of a Distributed System (2)

1.1

A distributed system organized as middleware.Note that the middleware layer extends over multiple machines.


12/60

Transparency Descr ipt ion

AccessHide differences in data representation and how aresource is accessed

Location Hide where a resource is located

Migration Hide that a resource may move to another location

RelocationHide that a resource may be moved to anotherlocation while in use

Replication Hide that a resource may be shared by severalcompetitive users

ConcurrencyHide that a resource may be shared by severalcompetitive users

Failure Hide the failure and recovery of a resource

PersistenceHide whether a (software) resource is in memory oron disk

Different forms of transparency in a distributed system.


13/60

Hardware Concepts

1.6

Different basic organizations and memories in distributed

computer systems


14/60

Multiprocessors

Bus-based

Crossbar switch based

Switching network based


15/60

Homogeneous Multicomputer

Systems

1-9

a) Grid

b) Hypercube


16/60

Software Concepts

Syst em Descr ipt ion Main Goal

DOSTightly-coupled operating system for multi-processors and homogeneousmulticomputers

Hide and managehardwareresources

NOSLoosely-coupled operating system forheterogeneous multicomputers (LAN andWAN)

Offer localservices to remoteclients

MiddlewareAdditional layer atop of NOS implementinggeneral-purpose services

Providedistributiontransparency

An overview between DOS (Distributed Operating Systems)

NOS (Network Operating Systems)

Middleware


17/60

Network Operating System (1)


18/60

Network Operating System (2)

1-20

Two clients and a server in a network operating system.


19/60

General structure of a distributed

system as middleware


20/60

Comparison between Systems

Dist ribu t ed OS

I tem Mult iproc. Mult icomp.

Degree of transparency Very High High Low High

Same OS on all nodes Yes Yes No No

Number of copies of OS 1 N N N

Basis forcommunication

Sharedmemory

Messages Files Model specific

Resource managementGlobal,central

Global,distributed

Per node Per node

Scalability No Moderately Yes Varies

Openness Closed Closed Open Open

Network

OS

Middleware-

based OS


21/60

Clients and Servers

General interaction between a client and a server.


22/60

Idea Stressed

Memory hierarchy

Architecture

Operating system

Performance

Cost


23/60

Communication

Network architecture

Remote procedure call

Synchronous communication

Asynchronous communication


24/60

Layered Protocols (1)

Layers, interfaces, and protocols in the OSI model.

2-1


25/60

Remote Procedure Call

Conventional procedure call

Remote procedure call Client and Server Stubs

Parameter passing Extended RPC models

Doors

Asynchronous RPC

Deferred synchronous RPC


26/60

Communication

Synchronous communication

Asynchronous communication


27/60

Persistence and Synchronicity in Message-

Oriented Communication

Persistent asynchronous communication

Persistent synchronous communication

Transient asynchronous communication Receipt-based transient synchronous communication

Delivery-based transient synchronous communication

at message delivery

Response-based transient synchronous communication


28/60

Persistence and Synchronicity in

Communication (1)

a) Persistent asynchronous communication

b) Persistent synchronous communication

2-22.1


29/60


Communication (2)

2-22.2

c) Transient asynchronous communication

d) Receipt-based transient synchronous communication


30/60


Communication (3)

e) Delivery-based transient synchronous communication atmessage delivery

f) Response-based transient synchronous communication


31/60

Processes

Threads

Code migration

Fuggetta, A., Picco, G. P., and Vigna, G.Understanding Code Mobility, IEEE

Transaction on Sofyware Engineering, Vol

24, No. 5, pp 342 -361 (1998)


32/60

Models for Code Migration

Alternatives for code migration.


33/60

Naming

The implementation of the name space

Internet Domain Name System


34/60

Name Spaces (1)

A general naming graph with a single root

node.


35/60

Name Space Distribution (1)

An example partitioning of the DNS name space,

including Internet-accessible files, into three layers.


36/60

Name Space Distribution (2)Item Global Administrational Managerial

Geographical scale of network Worldwide Organization Department

Total number of nodes Few Many Vast numbers

Responsiveness to lookups Seconds Milliseconds Immediate

Update propagation Lazy Immediate Immediate

Number of replicas Many None or few None

Is client-side caching applied? Yes Yes Sometimes

A comparison between name servers for implementing nodes from alarge-scale name space partitioned into a global layer, as an

administrational layer, and a managerial layer.


37/60

Implementation of Name Resolution

(1)

The principle of iterative name resolution.


38/60

Implementation of Name Resolution (2)

The principle of recursive name resolution.


39/60

Implementation of Name Resolution (3)

Server fornode

Shouldresolve

Looks upPasses tochild

Receivesand caches

Returns torequester

cs # -- --

#

#

#

##

#

#

vu # ##

ni # #

##

root # ##

##

Recursive name resolution of . Name

servers cache intermediate results for subsequentlookups.


40/60

Implementation of Name Resolution

(4)

The comparison between recursive and iterative name

resolution with respect to communication costs.


41/60

Synchronization

Physical clock

Logical clock

Global state

Election algorithms

Mutual exclusion algorithms


42/60

Physical Clocks

1 sec = Cesium 133 atom make 9,192,631,770

transitions

International Atomic Time (TAI) [average]

Universal Coordinated Time (UTC)

Clock synchronization Clock synchronization algorithms

Cristians algorithm

Berkeley algorithm

Averaging algorithms


43/60

Logical Clocks

Lamport timestamps

Totally-ordered multicasting

Vector timestamps


44/60

Global State Local state of each process, together

with the messages that are currently intransit

Chandy and Lamport idea of distributed

snapshot


45/60

Election Algorithms The Bully algorithm

A Ring algorithm

The Bully Algorithm (1)


46/60


The bully election algorithm Process 4 holds an election

Process 5 and 6 respond, telling 4 to stop

Now 5 and 6 each hold an election



47/60


d) Process 6 tells 5 to stop

e) Process 6 wins and tells everyone


48/60

A Ring Algorithm

Election algorithm using a ring.

Mutual Exclusion:


49/60

A Centralized Algorithm

a) Process 1 asks the coordinator for permission to enter a critical region.Permission is granted

b) Process 2 then asks permission to enter the same critical region. The

coordinator does not reply.c) When process 1 exits the critical region, it tells the coordinator, whenthen replies to 2


50/60

A Distributed Algorithm

a) Two processes want to enter the same critical region at the samemoment.

b) Process 0 has the lowest timestamp, so it wins.

c) When process 0 is done, it sends an OK also, so 2 can now enterthe critical region.


51/60

A Toke Ring Algorithm

a) An unordered group of processes on a network.

b) A logical ring constructed in software.


52/60

ComparisonAlgorithm

Messages per

entry/exit

Delay before entry

(in message times)Problems

Centralized 3 2 Coordinator crash

Distributed 2 ( n 1 ) 2 ( n 1 )Crash of any

process

Token ring 1 to 0 to n 1Lost token,process crash

A comparison of three mutual exclusion algorithms.


53/60

Replication and Consistency

Object replication

Data-centric consistency models

Client-centric consistency models

Consistency protocols

Data Centric Consistency Models


54/60

Data-Centric Consistency Models

The general organization of a logical data store,physically distributed and replicated acrossmultiple processes.


55/60

Data-Centric Consistency Models Strict Consistency

Linearizability and Sequential Consistency

Casual Consistency

FIFO Consistency

Weak Consistency

Release Consistency Entry Consistency


56/60

Quorum-Based Protocols

Three examples of the voting algorithm:

a) A correct choice of read and write set

b) A choice that may lead to write-write conflicts

c) A correct choice, known as ROWA (read one, write all)


57/60

Fault Tolerance Basic concepts

Failure models

Use of redundancy

Two-phase and three-phase commit

Checkpointing

Message logging


58/60

Basic Concepts Dependability Includes

Availability

Reliability Safety

Maintainability


59/60

Discussion About the Class Homework Laboratory assignments

Reading of papers

Mid term examination

Final examination

Final project

Programming project

Writing term paper


60/60

Comments about the course

Students liked programming with HLA

Some students enjoyed reading papers

Some concepts were difficult

Some students did not have enough

background

Date post:	05-Apr-2018
Category:	Documents
Upload:	shivraj-wagh
View:	231 times
Download:	0 times

Dist System Guha 04

Documents