Distributed Systems’ Models
Dr. Rajkumar Buyya
Cloud Computing and Distributed Systems (CLOUDS)
Laboratory
Departmnt of Computing and Information Systems
The University of Melbourne, Australia
http://www.cloudbus.org/652
Most concepts are
drawn from Chapter 2
© Pearson Education
Some ideas from
Chapter 1
Presentation Outline
Introduction
Architectural Models
Software Layers
System Architectures
Client-Server
Clients and a Single Server, Multiple Servers, Proxy Servers with
Caches, Peer Model
Alternative Client-Sever models driven by:
Mobile code, mobile agents, network computers, thin clients, mobile
devices, and spontaneous networking
Design Challenges/Requirements
Fundamental Models – formal description
Interaction, failure, and security models.
Summary
2
Introduction
Real world systems should be designed to
function correctly in ALL circumstances/scenarios.
Distributed system models helps in…
..classifying and understanding different implementations
..identifying their weaknesses and their strengths
..crafting new systems outs of pre-validated building blocks
3
Architectural Models
An Architectural model of a distributed system
is concerned with the placement of its parts
and relationship between them. Examples:
Client-Server (CS) and peer-to-peer models.
CS can be created/modified by:
The partitioning of data/replication at cooperative
servers
The caching of data by proxy servers or clients
The use of mobile code and mobile agents
The requirements to add or remove mobile devices.
4
Architectural Models
Simplifies and abstracts the functions of individual
components
The placement of the components across a network of
computers – define patterns for the distribution of data and
workloads
The interrelationship between the components – i.e.,
functional roles and the patterns of communication
between them.
5
Architectural Models
Architectural Model - simplifies and abstracts
the functions of individual components:
An initial simplification is achieved by classifying
processes as:
Server processes
Client processes client
client server
server
Peer processes
Cooperate and communicate in a symmetric manner to
perform a task.
peer
peer
6 peer
peer
Client Server Basic Model:
Clients invoke individual servers
Client invocation invocation Server
result result
Server
Client
Key:
Process: Computer:
Client processes interact with individual server processes in a separate computer
in order to access data or resource. The server in turn may use services of other
servers.
Example:
A Web Server is often a client of file server.
Browser search engine -> crawlers other web servers.
7
Client-Server Architecture Types
Two-tier model (classic)
client
client server
server
Three-tier (when the server, becomes a client)
client
client Server/client
Server/client server
server
Multi-tier (cascade model)
server
server
client
client Server/client
Server/client Server/client
Server/client
server
server
8
Clients and Servers
General interaction between a client and a server.
9
A service provided by multiple servers
Service
Server
Client
Server
Client
Server
Services may be implemented as several server processes in separate host computers.
Example: Cluster based Web servers and apps such as Google, parallel databases Oracle
10
Proxy servers (replication transparency) and
caches: Web proxy server
Client Web
server
Proxy
server
Client Web
server
A cache is a store of recently used data.
11
Peer Processes: A distributed application based
on peer processes
Peer 2
Peer 1
Application
Application
Sharable Peer 3
objects
Application
Peer 4
Application
Peers 5 .... N
All of the processes play similar roles, interacting cooperatively as peers to
perform distributed activities or computations without distinction between clients
and servers. E.g., music sharing systems Gnutella, Napster, Kaza, etc.
Distributed “white board” – users on several computers to view and interactively
12 modify a picture between them.
P2P with a Centralized Index Server
(e.g. Napster Architecture)
peer
peer
peer
peer
peer
peer
peer
peer
peer
peer
peer
peer
peer
peer
13
Variants of Client Sever Model: Mobile code
and Web applets
a) client request results in the downloading of applet code
Client Web
Applet code server
b) client interacts with the applet
Web
Client Applet server
Applets downloaded to clients give good interactive response
Mobile codes such as Applets are potential security threat, so the
browser gives applets limited access to local resources (e.g. NO
access to local/user file system).
14
Variants of Client Sever Model: Mobile Agents
A running program (code and data) that travels from one
computer to another in a network carrying out an autonomous
task, usually on behalf of some other process
– advantages: flexibility, savings in communications cost
– virtual markets, software maintain on the computers within an
organization.
Potential security threat to the resources in computers they visit.
The environment receiving agent should decide which of the local
resource to allow. (e.g., crawlers and web servers).
Agents themselves can be vulnerable – they may not be able to
complete task if they are refused access.
15
Thin clients and compute servers
Compute server
Network computer or PC
Thin network Application
Client Process
Network computer: download OS and applications from the
network and run on a desktop (solve up-gradation problem) at
runtime.
Thin clients: Windows-based UI on the user machine and
application execution on a remote computer. E.g, X-11 system.
16
Presentation Outline
Introduction
Architectural Models
Software Layers
System Architectures
Client-Server
Clients and a Single Sever, Multiple Servers, Proxy Servers with
Caches, Peer Model
Alternative Client-Sever models driven by:
Mobile code, mobile agents, network computers, thin clients, mobile
devices and spontaneous networking
Design Challenges/Requirements
Fundamental Models – formal description
Interaction, Failure, and Security models.
Summary
17
Lecture Overview (II)
Fundamental Models are concerned with a formal description of
the properties that are common in all of the architectural models.
All architectural models are composed of processes that
communicate with each other by sending messages over a
computer networks.
Fundamental Models that addressing; time synchronization,
message delays, failures, security issues; are:
Interaction Model – deals with performance and the difficulty of
setting of time limits in a distributed system.
Failure Model – specification of the faults that can be exhibited by
processes
Security Model – discusses possible threats to processes and
communication channels.
18
Interaction Model
Computation occurs within processes;
The processes interact by passing messages,
resulting in:
Communication (information flow)
Coordination (synchronization and ordering of events)
between processes.
Two significant factors affecting interacting
processes in a distributed system are:
Communication performance is often a limiting
characteristic.
It is impossible to maintain a single global notion of time.
Examples of Interaction Model ???
19
Interaction Model:
Performance of Communication Channel
The communication channel in our model is realized in a variety of
ways in DSs. E.g., by implementation of:
Streams
Simple message passing over a network - continuous flow of data, can be bi-directional
Communication over a computer network has performance
characteristics:
Latency:
A delay between the start of a message’s transmission from one
process to the beginning of reception by another.
Bandwidth:
the total amount of information that can be transmitted over in a given
time.
Communication channels using the same network, have to share the
available bandwidth.
Jitter
The variation in the time taken to deliver a series of messages. It is
very relevant to multimedia data.
20
Interaction Model:
Computer clocks and timing events
Each computer in a DS has its own internal clock, which can be
used by local processes to obtain the value of the current time.
Therefore, two processes running on different computers can
associate timestamp with their events.
However, even if two processes read their clocks at the same
time, their local clocks may supply different time.
This is because computer clock drifts from perfect time and their
drift rates differ from one another.
Even if the clocks on all the computers in a DS are set to the
same time initially, their clocks would eventually vary quite
significantly unless corrections are applied.
There are several techniques to correct time on computer clocks.
For example, computers may use radio receivers to get readings
from GPS (Global Positioning System) with an accuracy about 1
microsecond.
21
Interaction Model:
Two variants of the interaction model
In a DS it is hard to set time limits on the time taken for process
execution, message delivery or clock drift.
Synchronous DS – hard to achieve:
The time taken to execute a step of a process has known lower
and upper bounds.
Each message transmitted over a channel is received within a
known bounded time.
Each process has a local clock whose drift rate from real time
has known bound.
Asynchronous DS: There is NO bounds on:
Process execution speeds
Message transmission delays
Clock drift rates.
22
Interaction Model:
Event Ordering
In many DS applications we are interested in
knowing whether an event occurred before,
after, or concurrently with another event at
other processes.
The execution of a system can be described in
terms of events and their ordering despite the lack
of accurate clocks.
Consider a mailing list with:
users X, Y, Z, and A.
23
Real-time ordering of events
send receive receive
X
1 m1 4
m2
send
receive
Y 2 3 Physical
receive time
send
Z
receive receive
m3 m1 m2
A
receive receive receive
t1 t2 t3
24
Inbox of User A looks like:
Item From Subject
23 Z Re: Meeting
24 X Meeting
26 Y Re: Meeting
Due to independent delivery in message delivery, message may
be delivered in different order.
If messages m1, m2, m3 carry their time t1, t2, t3, then they can
be displayed to users accordingly to their time ordering.
25
Failure Model
In a DS, both processes and communication
channels may fail – i.e., they may depart from
what is considered to be correct or desirable
behavior.
Types of failures:
Omission Failure
Arbitrary Failure
Timing Failure
26
Processes and channels
process p process q
send m receive
Communication channel
Outgoing message buffer Incoming message buffer
Communication channel produces an omission failure if it
does not transport a message from “p”s outgoing
message buffer to “q”’s incoming message buffer. This is
known as “dropping messages” and is generally caused
by a lack of buffer space at the receiver or at gateway or
by a network transmission error.
27
Omission and arbitrary failures
Class of failure
Affects Description
Fail-stop Process
Process halts and remains halted. Other processe
detect this state.
Crash Process
Process halts and remains halted. Other processe
not be able to detect this state.
Omission AChannel
message inserted in an outgoing message buffer
arrives at the other end’s incoming message buff
Send-omission A process completes send,
Process a but the
put in its outgoing message
message buffer.
is not
Process
eceive-omissionA message is put in a process’s incoming messag
buffer, but that process does not receive it.
Arbitrary Process
Process/channel
or exhibits arbitrary behaviour: it
(Byzantine)send/transmit
channel arbitrary messages at arbitrary ti
commit omissions; a process may stop or take an
incorrect step.
28
Timing failures
Class of Failure
Affects Description
Clock Process
Process’s local clock exceeds the bounds
rate of drift from real time.
Performance Process
Process exceeds the bounds on the interv
between two steps.
Performance Channel
A message’s transmission takes longer th
stated bound.
29
Masking Failures
It is possible to construct reliable services from
components that exhibit failures.
For example, multiple servers that hold replicas of data can
continue to provide a service when one of them crashes.
A knowledge of failure characteristics of a
component can enable a new service to be designed
to mask the failure of the components on which it
depends:
E.g. checksums are used to mask corrupted messages.
30
Security Model
The security of a DS can be achieved by
securing the processes and the channels
used in their interactions and by protecting
the objects that they encapsulate against
unauthorized access.
31
Protecting Objects: Objects and principals
Access rights Object
invocation
Client
result Server
Principal (user) Network Principal (server)
Use “access rights” that define who is allowed to perform operation on a
object.
The server should verify the identity of the principal (user) behind each
operation and checking that they have sufficient access rights to perform
the requested operation on the particular object, rejecting those who do
not.
32
The enemy
Copy of m
The enemy
m’
Process p m Process q
Communication channel
To model security threats, we postulate an enemy that is capable of
sending any process or reading/copying message between a pair of
processes
Threats form a potential enemy: threats to processes, threats to
communication channels, and denial of service.
33
Defeating security threats: Secure channels
Principal A Principal B
Process p Secure channel Process q
Encryption and authentication are use to build secure channels.
Each of the processes knows the identity of the principal
(user/server) on whose behalf the other process is executing and
can check their access rights before performing an operation.
34
Summary
Most DSs are arranged accordingly to one of a
variety of architectural models:
Client-Server
Clients and a Single Sever, Multiple Servers, Proxy Servers
with Cache, Peer Model
Alternative Client-Sever models driven by:
Mobile code, mobile agents, network computers, thin clients,
mobile devices and spontaneous networking
Fundamental Models – formal description
Interaction, failure, and security models.
The concepts discussed in the module play an
important role while architecting DS and apps
35
Fundamental Models
Fundamental models are concerned with a formal
description of the properties that are common in the
architectural models
The issues such as time synchronization, message
delays, failures, security are addressed as:
Interaction Model – deals with performance and the
difficulty of setting of time limits in a distributed system.
Communication and processing delays are unpredictable.
Failure Model – specification of the faults that can be
exhibited by processes
Secure Model – discusses possible threats to processes
and communication channels.
36
