19Z603-DISTRIBUTED

COMPUTING
 SYLLABUS
INTRODUCTION, MESSAGE PASSING AND RPC : Definition - System models -
Design issues of distributed operating systems - Message Passing: Features and
Issues–Buffering - Process addressing - Failure handling RPC: Model -
Implementation - Stub generation - RPC Messages - Marshaling - Server
management – Call semantics (10)

SYNCHRONIZATION : Clock synchronization - Physical clocks - Logical clocks -

Election algorithms – Mutual exclusion- Deadlocks (8)

PROCESS AND RESOURCE MANAGEMENT: Process migration: Features -

Mechanism. Resource Management: Load balancing approach - Load sharing
approach (9)

CLOUD AS A DISTRIBUTED ENVIRONMENT : The Vision of Cloud Computing -

Defining a Cloud - Historical Developments -Cloud Computing Reference Model
–Cloud Deployment Models - Public, Private, Community, Hybrid Clouds - Cloud
Delivery Models - IaaS, PaaS, SaaS - Characteristics and Benefits - Challenges. (8)

CLOUD TECHNOLOGIES : Technologies for Infrastructure as a service - Platform

as a Service– Software as a service – Cloud Storage: MapReduce, GFS, HDFS -
Cloud container: Docker. (10)
2
 TEXT BOOKS AND REFERENCES

TEXT BOOKS:
1. Pradeep K Sinha , "Distributed Operating Systems: Concepts and Design",
Prentice Hall of India, New Delhi, 2009.
2. Rajkumar Buyya, Christian Vecchiola, Thamarai Selvi S , "Mastering Cloud
Computing", Tata McGraw Hill Education Private Limited,, New Delhi, 2013.

REFERENCES:
1. Andrew S Tanenbaum, Marteen Van Steen , "Distributed Systems
Principles and Paradigms", Pearson Education / Prentice Hall of India, New
Delhi, 2007.
2. George Coulouris, Jean Dollimore , "Distributed Systems Concept and
Design", Pearson Education, New Delhi, 2006.
3. David S Linthicium , "Cloud Computing and SOA Convergence in your
Enterprise", Pearson, USA, 2010.
4. Sébastien Goasguen , "Docker in the Cloud -Recipes for AWS, Azure,
Google, and More", O‘Reilly Media, USA, 2016.

3
 COURSE OUTCOMES

CO1: Depict the issues, models of distributed systems and

Describe message passing and develop RPC based client-
server programs

CO2:Analyze and apply synchronization, deadlock

management techniques

CO3:Paraphrase, apply process management and resource

management in distributed systems

CO4:Understand the concepts, key technologies and

strengths of cloud computing

CO5: Explore different cloud programming tools and

technologies and deploy cloud based application
Computer
Architecture
Multiprocessors
1.Tightly Coupled
Systems(Parallel Processing
Systems)
◦ Single System Memory Shared
by all Processors
◦ Small
CPU and
CPUlimited
CPU bandwidth
MEMORY

INTERCONNECTION HARDWARE

5
Computer
Architecture
2. Loosely Coupled
Systems(Distributed Computing
Systems)
•Processors have their
and communicate own local
between
them
memory
•Expandable and Unlimited
no of processor

6
 Distributed Computing
System
 A of inte
collection
processors connected r
communicati
by a
network in on
which
each
its own processor
memoryhas
and
local
peripherals andother
communication
between any two processors of
the system takes place by
message passing over the
communication network
Evolution of Distributed
Computing Systems
Early Computers
Job SetUp Time
 Batch Processing
 Multiprogramming
Multiple user can access
 Time Sharing (resource share and access from
different place)
 Mini Computers
 Workstation
 MicroProcessors
 LANs/WANs

◦ Merging of Computers and Networking-

Distributed Computing Systems(1970s)
8
Distributed Computing System
Models
Distributed Computing
Systems

Mini

Computer

Work Station
Work Station-
Server Processor 9
Mini Computer
Model

10
Mini Computer
Model
 Different databases on different
remote machines
 Extension of time sharing systems
 Multiple users simultaneous login

Exampl
e
ARPAN
ET
11
Work Station
Model

12
 Work Station Model
Idle workstation in big
campus
 Issues
◦ Finding idle ws
◦ How to transfer job
◦ Suppose if it starts working?
 Allow remote process to share the
resources of the workstation along
with its own logged on users
processes.
Kill the remote process
Migrate remote process back to its
home workstation 13
Work Station Server
Model

14
 Work-Station Server
- Consists of few minicomputers and several
Model
workstations interconnected by a communication
network.
 Diskful workstations-Work station model is a
Network of personal workstations, each with its own disk and
a local file system
 Diskless workstations
 Cheaper-few minicomputers equipped with large, fast
disks that are accessed over the network
 Diskless Workstation are preferred-Backup and H/W
maintenance are easier
 No process migration needed
 Request Response protocol is used to access the services
of the server machines 15
Processor Pool
Model Terminals

16
 Processor Pool
 Most of the time user does not need
Model computing power but once in a
while user needs a very large amount
of computing power for a short time.
 In workstation server model, processor is
allocated to each user but in Processor poor
model
 Processors are gathered-Users share
whenever needed
 Terminals are diskless workstations
 Run Server- Special server manages and
allocated the processors in the pool to
different users on a demand basis
17
 Processor Pool
As Model
compared to workstation -server model ,
Processor Pool Model
 Allows Better utilization of processors
 Provides Greater Flexibility- System services
can be easily expanded without the need to
install any more computers
 Considered to be unsuitable for high
performance interactive applications –
especially those using graphics or window
systems
- due to slow speed of communication between
the computer on which the application program
is executed and the terminal via which the user is
18
 Hybrid
 Model
Out of the four models WS-Server
model is widely used for building
distributed computing systems Because
Suitable for interactive jobs
Processor-pool model is suitable for
Massive applications which need
computations
Hybrid model is based on the WS-Server
model but with the addition of a pool of
processors
Processors in the pool can be allocated
dynamically for computations that are too
large for workstations 19
Hybrid
Model
Processo Ws-
r pool server
model model
Hybrid
model
20
What is a Distributed
OS?

o
s

Networ Distribut
k ed
OS OS
21
Differenc
es
•A network operating system is made up of software and associated
protocols that allow a set of computer network to be used together.
• A distributed operating system is an ordinary centralized operating
system but runs on multiple independent CPUs.
Metrics Network O S Distributed O S
Syste The Users are aware Virtual Uniprocessor
m that multiple
Image systems are used
The User knows in Unaware of this
which machine his job information
is executed
User know where his/her Does not know
information is stored
Explicit commands Same Commands
for file transfer
Control over file Automatic
placement is manual

22
Differenc
es
Metrics Network O S Distributed O S
Autonomy Each Computer is Not independent
independent
Have local OS Common OS
Degree of autonomy is Low
high
Fault Little or No fault High Fault tolerance
Tolerance tolerance
capability
Capabilit
y
Example Microsoft Windows Server AIX operating system for IBM
2003, Microsoft Windows RS/6000 computers.
Server 2008, UNIX, Linux Solaris operating system for
SUN multiprocessor
workstations. .

23
 ISSUES I N
DESIGNING
DISTRIBUTED
OS
 Differences in the complexity of the Design
between traditional system and Distributed
system
 Centralized Os-User can request status
information and it is available
Distributed OS- cannot
about the system have
and not Complete
available to the
information
user.
 Centralized Os- Resources are
nearer Distributed Os-Far away
 Centralized Os- Common Clock
Distributed OS- No Common clock, Lack of
Up to date information (Delivery of messages –24
ISSU
ES
 Transparenc
y
Reliability
Flexibility
Performance
Scalability
Heterogene
ity 25
 ISSUES I N
DESIGNING
ADISTRIBUTED
lot of OS
issues But
flexible,
efficient,
reliable,
secure,
and
easy to 26
 Transparen
 cy
Single Virtual Uniprocessor image
 Eight
forms of transparency - ISO 1992
Reference Model for Open Distributed
Processing
 Access transparency
 Location transparency,
 Replication transparency,
 Failure transparency,
 Migration transparency
 Concurrency transparency,
 Performance transparency, and
27
 Transparen
cy transparency
 Access
 User should not be able to
recognize a resource as local or
remote
 Remote resources in the same
way as local
 Uniform system calls
 Suitable for limited types of
application due to its
Performance limitations
28
 Transparen
cy
Name
Transparen
Location cy
Transparen
cy User
Mobilit
y
29
Transparen
cy Transparency
Name
 Name of resource does not reveal
physical location of the resource
Movement of files need not change the
names
Resource names are unique
User Mobility
Same resources from different
locations are accessed with same
name.
 Users access to resources without
any extra effort 30
 Transparen
cyReplication
 Creating Replicas of files and resources
Transparency
on different nodes of distributed systems
–Better performance and reliability
 Should be transparent to users
 Issues
 Naming of replicas (name of replica
should be mapped to user supplied
name by the system)
 Replication control (No.of copies?
When to create? Where to place?)
31
 Transparen
cy
 Failure Transparency
• Masking from users- partial failure in the
system
• DOS will continue to function in
degraded form when failure occurs.
 communication link failure,
 a machine failure, or
 storage device crash
 All types of failures cannot be handled in
a user transparent manner.
 Theoretically possible, Practically
not justified 32
Transparen
cy Transparency –
Migration
(Performance ,Reliability, Security)
 Migration decisions should be automatic
 Migration should not require any change in
name
 If the receiver process migrates to another
location before receiving messages from
the sender , IPC should ensure that
migrated process receives the message.
Concurrency Tranparency
 Multiple user- spatially separated use the
system concurrently
 Concurrent update of the same file by two
processes should not be allowed
33
Transparen
cy Event Access request to
resources -> properly
Ordering ordered
Property
Concurrency
Resource
No sharing
No
Deadlock mechanism Starvatio
Property n
Property

Mutual
Exclusion
Property
34
 Transparen
cy
Performance Transparency
To allow the system to be automatically reconfigured
 Processor – Loads should be distributed(No Idle
Processors)
 Processing capability should be uniformly
distributed among the available jobs
Requirement
Intelligent resource allocation and migration
facility
Scaling Transparency
To allow system to expand without disturbing the
user activities.
Requirement
 Use of Open System Architecture 35
2.Reliability DS expected to be more
reliable – Due to Multiple
instances of resources

Reliabilit Fault-Mechanical or
y algorithmic defect that
may generate an error.

Fault Fault Fault

Avoidan Detection/Recov
Toleran ery
ce ce
Fault->Failure

36
Reliability
System Failure
• Fail-stop –System stop functioning
after changing to the state in which
failure can be detected
• Byzantine –System continues to
function but produces wrong result.
System bugs causes this failure.
Reliabili
ty
1. Fault Avoidance
Designing the components to minimize the occurrence of
faults
Use high reliability components
The Designers of software components has to test to
make the hardware components highly reliable .
2.Fault Tolerance
Ability of the system to function in the event of partial
system failure
Techniques to improve fault tolerance
i. Redundancy Techniques
To avoid single point of failure -Hardware
and software components are replicated.
Additional system overhead is needed to
maintain replicas to ensure that they are consistent. 38
Reliabili
ty
 How much replication is enough?
System is said to be k-fault tolerant if it
can continue to function even in the
event of the failure of k components.

 K fail stop failures – k+1 replicas

 K byzantine failure - min 2k+1 replicas
(voting mechanism)
ii. Distributed Control
 Distributed control mechanism is used
in name servers, scheduling algo to
avoid single points of failure.

39
3.Fault Detection and Recovery
Use of H/W and S/W mechanism
to determine the occurrence of failure
and then to correct system to an
acceptable state.
Techniques:
i. Atomic Transactions
• Collection of operations that
takes place indivisibly in presence of
failure
• All operations goes to completion
or none- incase of failure data object
restore to original state if system
supports trans mechanism
Reliabili
ty
ii. Stateless Servers

Client
-
serve
r
Statef Statele
ul ss
41
Stateful Server: Depends on
history of serviced request.

Stateless Server – Crash

Recovery- Easy- No client state info
is maintained.
Reliabili
tyiii. Acknowledgements and time-
outs based retransmissions
Node crash/Communication link
failure-message lost
Duplicate messages are a
problem here
Detection and
handling of Duplicate
messages
- Generating and assigning
Sequence Numbers to 4
3
3.Flexibility
Why DOS should be flexible?
Ease of modification - Some parts of
design needs to be replaced/modified if
bugs detected or not suitable for
changed system
Ease of enhancement –User should
have the flexibility to add new service
or the change the existing style.
The important design factor is
Designing the kernel
Monolithicof the OS
Kernel
Kern
el Micro 44
 Flexibili
 Kernel of an OS is its central controlling
ty that provides basic system facilities
part
with separate address space inaccessible
to user processes. User cant replace or
modify
 Monolithic Kernel
◦ All functions are provided by the kernel
◦ Big structure
◦ UNIX
◦ Micro Kernel
 To Keep Kernel as small as possible
 OS provides minimum facilities -
Services provided is IPC -Low Device
mgmt and Mem. Management
 other services are implemented as 45
Flexibili
ty

Node Node Node

1 2 n
User User User
Applications Applications Applications
• Monolithi • Monolithi • Monolithi
c Kernel c Kernel c Kernel
Network Hardware

MONOLITHIC
KERNEL

46
 Microkern
1
el
Node Node
2
Node
n
User User User
Applicatio Applicatio Applicatio
ns ns ns
Server / Server / Server /
Manager Manager Manager
Modules Modules Modules

Microkern Microkern Microkern

el el el

Network
Hardware
47
Flexibility
Monolithic Model Microkernel Model

Major OS services are provided by the Only minimal facilities and

kernel services are provided
Kernel has a large monolithic structure Size of the kernel is small
No such thing User level server processes
services
Large size reduces flexibility Increased flexibility
Reduced Configurability Highly modular in nature
complex Easy to modify
complex Easy to add services
Changes can be done by interrupting Without interrupting users, the
users changes can be performed In the
OS
No the servers have to use some
form of message-based
interprocess communication
mechanism
No Message passing requires
context
 Performan
ce
 Design principles in
Performance are
order to achieve Good

1. Batch if possible
◦ Large chunks of data- transfer instead of
small across network
◦ Piggybacking acknowledgement (Message
Exchange)
2. Cache whenever possible
◦ Makes data available
◦ Saving large amount of Computing time and
bandwidth
 Senders
3.Minimize Stack data
copying to Message buffer
 Message buffer in sender address space to
 Data path to send the message
message buffer in kernel address space
 From kernel to Network Interface Board
 Receiving Same in reverse
49
Performan
ce
 4. Minimize network traffic.
◦ migrating a process closer to the
resources
◦ to cluster two or more processes
that frequently communicate
with each other on the same
node of the system
 5. Take advantage of fine-grain
parallelism for multiprocessing
◦ Threads-used for structuring the
server processes- Simultaneously
service requests from clients
◦ 50
Scalabili
ty
 capability of a system to adapt to
increased service load.
PRINCIPLES FOR DESIGNING SCALABLE
SYSTEMS
1. Avoiding centralized entities (such as
single file server or single database)
•The failure of the centralized entity often
brings the entire system down. Hence, the
system cannot tolerate faults
• Even if the centralized entity has enough
processing and storage capacity, the
capacity of the network saturated
•In a wide-area network consisting
several interconnected LAN increases
network traffic. 51
Scalabili
ty
 2. Avoid centralized algorithms.
◦ This algorithm collects information from
all nodes.
◦ Processing info on single node and
distributing the results to rest of the
nodes- Not acceptable from a scalable
point of view.
Eg: Scheduling algo – selects lightly
loaded node -host selection time too
long.
 The complexity of the algorithm is
O(n2)
◦ It creates heavy network traffic and
quickly
◦ consumes network bandwidth.Therefore,52
 Heterogene
ity
Interconnected set of dissimilar
hardware and software
 Incompatibilities in heterogeneous
DS:
◦ Communication protocols
◦ Topologies
◦ Servers operating at different
node of system may be different.
Pros
-Provides Flexibility – Different
computer platforms for different
applications. 53
Heterogene
ity
•We need translator which converts
each format in the system to the
format used in receiving node.
•n formats – (n-1) pieces of translation
software at each node – n(n-1) pieces
of translation software in the system.
• Complex

Intermediate standard data format –

Less no. of conversions
 Securi
ty
In a centralized system, all users are
authenticated by the system at login time.
- system can easily check whether a user is
authorized to perform the requested
operation on an accessed resource.
 In a distributed system this is not
possible.
 So Design should include to know
◦ Sender of the message should know
that the message was received by the
intended receiver
◦ Message sent by a genuine sender
◦ The content of the message is not
55
MESSAGE
PASSING
 Introductio
n communicating with each
Processes
other
 Distributed operating systems
provide IPC Methods for sharing
information are
1.Original sharing, or shared-data
Messag
approach e
Sharing
2.Copy sharing,
Originalor message-passing
Copy
Sharing sharing
approach
Basic Methods for sharing
data

Original Sharing

Copy sharing
Message Passing
System
subsystem of a distributed operating
system
 provides a set of message-
based IPC protocols.
enables processes to
communicate by exchanging
messages
simple communication primitives,
such as send and receive.
Desirable Features of a Good
Message Passing System
 Simplicity
 Uniform
Semantics
 Efficiency
 Reliability
 Correctness
 Flexibility
 Security
 Portability
 Simplicit
y
Message Passing System should
be
 Simple
 Easy to Use
 Straight forward to construct
new applications
 Clean and Simple Semantics
of IPC Protocols
Uniform Semantics

Local
Communicati
on

Inter
process
communicati
on
Remote
Communicati
on
 Efficienc
If MPS yis not Efficient – IPC expensive
Optimization techniques to improve
efficiency
Avoiding the costs of establishing
and terminating connections
between same pair of processes for
each message exchange.
Minimizing the costs of maintaining
the connections
Piggybacking of acknowledgment of
previous messages with the next
 Reliabilit
y
Ds are prone to different catastrophic
events such as node crash or
communication link failure.
Acknowledgments and retransmissions
on the basis of timeouts
Detecting and handling
duplicates
Generating and assigning appropriate
sequence numbers to messages
Correctne
ss MPS has IPC protocols for group communication
Issues related to
correctness are
 Atomicity - Message sent to every
Receivers or none
Ordered delivery - Messages arrive at
all receiver in order
 Survivability -Messages will be
Delivered correctly despite of partial
failure.
Survivability is a difficulty property to
achieve.
 Flexibilit
 IPC y should be
primitives such that the
users have the flexibility to choose and
specify the types and levels of reliability
and correctness requirements
 have the flexibility to permit any kind of
control flow between the cooperating
processes, including synchronous and
asynchronous send/receive.
 Securi
ty
 Secure end-to-end communication.
STEPS :
 Authentication of the receiver of
a message by the sender
 Authentication of the sender of
a message by its receiver
 Encryption of a message before
sending it over the network
 Portabili
ty
Message passing
system should
be portable
Portabilit
y The applications
•Use of external data
representation formats
written using
•Design of high level primitives of IPC
primitive for IPC protocol for
MPS - To hide
protocol of MPS
heterogeneous nature of should be
network
 Issues in IPC Message
Passing
Message- Block of Information
formatted by a sending process such
that its meaningful to the receiving
process

It consist of fixed length header and a

variable size collections of typed data
object
Issues in IPC Message
PassingFIXED LENGTH HEADER
Actua Structral Sequen Addresses
l information ce
Data Number Type No Sending Receiving
or of / Msg address Address
Pointe bytes ID
r to
data For identifying lost
Specifies and duplicate
whether data messages
to be passed
on to receiver
is included
within the
message or it
contains a
pointer to the
data.
 Issues in IPC Message

Passing
Who is the sender?
 Who is the receiver?
Is there One or more receivers?
Message guaranteed to have been accepted by its receivers?
Does the Sender needs to waits for reply?
Node crash? What to do?
If the receiver not ready to accept the message? Will the message
be discarded or stored in a buffer? - Buffering? (Buffer is full)
Outstanding Messages? – how to choose the order to service the
outstanding message?