chapter 2: system models. objectives to provide students with conceptual models to support their...
TRANSCRIPT
Objectives To provide students with
conceptual models to support their study of distributed systems.
To motivate the study of many of the design problems and solutions.
Provide a high-level view of the distribution of functionality between components and the relationships between them.
Models determine the distribution of data and computational tasks among the physical nodes of the system.
Helpful when evaluating the performance, reliability, scalability and other properties of distributed systems.
Architectural Models
Architectural models (cont.)
Architectural model consider: placement of the components
across a network of computers - define useful pattern for distribution data or workload
interrelationship between components – functional pattern of communication between them.
Architectural models (cont.)
Software Layers
What is “Software architecture”?
- structuring of software as layers or modules in a single computer
- services offered & requested between process located in same or different computer
Fig. 2.1: Software & hardware service layers in DS
Applications, services
Computer and network hardware
Platform
Operating system
Middleware
2 main types of architecture model:~ Client-server model~ Peer-to-peer model
Client-server model can be modified by:~ Partitioning of data or replication at
cooperating servers~ Caching of data by proxy servers & clients~ Use of mobile code & agents~ Requirement to add & remove mobile
devices in a convenient manner
Architectural models (cont.)
Fig. 2.2: Clients invoke individual servers
Server
Client
Client
invocation
result
Serverinvocation
result
Process:Key:
Computer:
Peer-to-peer model ~ Process involved in task/activity play
similar roles~ interactively cooperating as peers
without any distinction between client and server process
~ exploit resources in a large number of participating computers for fulfillment of a given task
Architectural models (cont.)
Fig. 2.3: A distributed application based on peer processes
Application
Application
Application
Peer 1 Peer 2
Peer 3
Peers 5 .... N
Sharable objects
Application
Peer 4
Variation derived based on factor: ~ use multiple servers and caches to ↑
performance & resilience~ use mobile code & mobile agent~ user need for ↓ cost computers with
limited hardware resources that are simple to manage
~ requirement to add & remove mobile devices in a convenient manner
Architectural models (cont.)
Proxy servers & caches:Cache ~ Store of recent used data object that is closer
than object themselves. ~ When a new object is received at a computer,
cache store, replacing some object necessarily.
~ Caches may be allocated with each client @ they may be allocated at proxy server.
Proxy server ~ ↑ availability & performance of services by
reduced load of WAN and web servers~ May be used to access remote web servers
through a firewall
Architectural models (cont.)
Fig. 2.6: Web appletsa) Client request results in the downloading of applet code
Web server
ClientWeb serverApplet
Applet codeClient
b) Client interacts with the applet
Applet are well-known and widely used example of mobile code.
Fig. 2.7: Thin clients & compute servers
Thin
Client
Application
Process
Network computer or PCCompute server
network
Thin client
~ software layer that supports a window based user interface on a computer
~ local to the user while execution application programs on a remote computer.
Issues that addressed in the design of DS.
3 fundamental models:~ Interaction Model~ Failure Model~ Security Model
Fundamental Models
Interaction Model~ Synchronous DS by Hadzilacos &
Touge[1994] - time to execute each step of process has
known lower & 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 a known bounded time
Fundamental Models (cont.)
Interaction Model~ Asynchronous DS has no bounds on: - process execution speed: -> a process step may take only a
picoseconds and another a century.
- message transmission delays -> a message from process A to B
may be delivered in negligible time & another make take several years
- clock drift rate
Fundamental Models (cont.)
Interaction Model~ Event Ordering - Event (sending or receiving message)
at one process occurred before, after or concurrently with another event at another process
- Execution of a system can be in terms of events & ordering despite the lack of accurate clock
Fundamental Models (cont.)
Fig. 2.8: Real-time ordering of events
send
receive
send
receive
m1 m2
2
1
3
4X
Y
Z
Physical time
Am3
receive receive
send
receive receive receivet1 t2 t3
receive
receive
m2
m1
Failure Model~ Hadzilacos & Touge [1994] provide a
taxonomy distinguish between failure of process & communication channel:
- Omission failure - Arbitrary failure- Timing failure
Fundamental Models (cont.)
Fig.2.9: Processes and channels
process p process q
Communication channel
send
Outgoing message buffer
Incoming message buffer
receivem
Fig. 2.10: Omission & arbitrary failures
Class of failure Affects Description
Fail-stop Process Process halts and remains halted. Other processes may
detect this state.
Crash Process Process halts and remains halted. Other processes may
not be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer never
arrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not put
in its outgoing message buffer.
Receive-omission Process A message is put in a process’s incoming message
buffer, but that process does not receive it.
Arbitrary
(Byzantine)
Process or
channel
Process/channel exhibits arbitrary behaviour: it may
send/transmit arbitrary messages at arbitrary times,
commit omissions; a process may stop or take an
incorrect step.
Fig. 2.11: Timing failures
Class of Failure Affects Description
Clock Process Process’s local clock exceeds the bounds on its
rate of drift from real time.
Performance Process Process exceeds the bounds on the interval
between two steps.
Performance Channel A message’s transmission takes longer than the
stated bound.
Security Model~ Securing the processes & the
channels used for their interaction ~ Protecting objects that they
encapsulated against unauthorized access
Fundamental Models (cont.)
Fig. 2.12: Objects & principals
Network
invocation
resultClient
Server
Principal (user) Principal (server)
ObjectAccess rights