In lecture 1...
TDDD36
Secure Mobile Systems
Systems Software
Lecture 4: Distributed Systems Models
• We looked at Distributed systems as
one possible realisation of Concurrent
processes
• This time we look at some basic
concepts for modelling, and design
principles for distributed systems
Simin Nadjm-Tehrani
Real-time Systems Laboratory
Department of Computer and Information Science
Linköping University
Project course TDDD36
Systems Software module
25 pages
Autumn 2012
Project course TDDD36
Systems Software module
Applications
•
•
•
•
Banking systems
On-line access & electronic services
Peer-to-Peer networks
Distributed control
2 of 25
Autumn 2012
Common in all these?
Distributed model of computing:
•
•
•
•
– Cars, Airplanes
• Sensor and ad hoc networks
– Buildings, Environment
Multiple processes
Disjoint
j
address spaces
p
Inter-process communication
Collective goal
• M2M communication
Project course TDDD36
Systems Software module
3 of 25
Autumn 2012
Distributed Systems
A distributed system is one in which the failure of a
computer you did not even know existed can render
your own computer unusable.
Leslie Lamport
Project course TDDD36
Systems Software module
4 of 25
Autumn 2012
Networking vs. Dist. systems
• “Networking” treats the internal mechanisms
for inter-process communication:
– Routing
– Error control (reliable transmission)
– Flow control (low level treatment of
overloads)
As if it were one computer
running a service for a user!
• “Distributed systems” treats the application
view of the architecture for communication and
cooperation
Project course TDDD36
Systems Software module
5 of 25
Autumn 2012
Project course TDDD36
Systems Software module
6 of 25
Autumn 2012
1
This lecture
• Basic aspects affecting design
• Distributed systems architectures and
models
Project course TDDD36
Systems Software module
Overview
Why is it hard to get it right?
• Variations in workload, connectivity,
mobility, requirements
• Heterogeneity in systems environment,
hardware, operating systems, and
networks
• Consequences of timing and failure
issues
• Security threats, and distributed attacks
7 of 25
Autumn 2012
Project course TDDD36
Systems Software module
Architectural models
• Placement of processes and data across
a network of computers
• Patterns of communication to achieve
functional and extra(non)-functional
properties
Common application models
• Client-Server systems
– Some nodes act as provider of a service and
some nodes as requester of a service
– Multi-tier extensions allow some servers to
act as clients of another server in their turn
• Peer-to-Peer systems
What are these?
• Challenges: Scalability, interoperability
Project course TDDD36
Systems Software module
8 of 25
Autumn 2012
9 of 25
Autumn 2012
– All nodes can be both a provider and a
requester
Project course TDDD36
Systems Software module
10 of 25
Autumn 2012
Variations to basic models
• Multi-tier servers
Mobile code
• Local interaction after downloading code
from server
– Web server as a client of a local file server
– DNS servicing other Internet servers
• Multiple-server clusters
– Service processing divided among replicated
on-line store servers
– Load balancing among IP-telephony servers
– The cloud
Client
Client
Web Server
Applet
Web Server
• Proxy servers
– Acting as front-end or as cache
Project course TDDD36
Systems Software module
11 of 25
Autumn 2012
Project course TDDD36
Systems Software module
12 of 25
Autumn 2012
2
Architectural models
Interoperability
Application, Services
• Placement of processes and data across
a network of computers
• Challenges: Scalability, interoperability
Project course TDDD36
Systems Software module
13 of 25
Autumn 2012
Platform
Middleware
• Patterns of communication to achieve
functional and extra(non)-functional
properties
Operating System
Computer and Network Hardware
Project course TDDD36
Systems Software module
Programmer’s interface
• Middleware masks heterogeneity
14 of 25
Autumn 2012
The role of middleware
• Providing services that are common for
a range of applications
applications
• Least level of service provided
middleware
OS of
machine 1
OS of
machine 2
OS of
machine 3
OS of
machine 4
• But: Heavy middleware diminishes
scalability
NETWORK
Project course TDDD36
Systems Software module
– Interoperability
– Location and communication transparency
15 of 25
Autumn 2012
Project course TDDD36
Systems Software module
Design requirements
• Sharing resources
16 of 25
Autumn 2012
Distributed system models
• What is a model good for?
– Data: consistency & concurrent updates
• Performance
– Response time: service time, middleware
services,
i
operating
ti
system
t
overheads,
h d
communication time
– Throughput: measure of work done,
function of load and processing/transfer rate
• Quality of service
• What do we know about a design?
– Assumptions
– Outcomes: what we can guarantee, and
what we cannot guarantee
• Interaction/failure/security model
– Adapting performance and dependability
Project course TDDD36
Systems Software module
17 of 25
Autumn 2012
Project course TDDD36
Systems Software module
18 of 25
Autumn 2012
3
Two interaction models
• Asynchronous: No relation between
computation rate at different nodes, No
bound on message exchange delay,
Clock drift rates are arbitrary
• Synchronous: Bounded message
exchange delay, Related processing
rates at different nodes, Clock drift rates
bounded
Project course TDDD36
Systems Software module
19 of 25
Autumn 2012
Implications
• Synchronous:
– Local clocks can be used to implement
timeouts
– Lack of response from another node can be
interpreted as detection of failure
• Asynchronous:
– In the absence of global (synchronised) time
one cannot relate clocks at different nodes
Project course TDDD36
Systems Software module
Fundamental models
• What is a model good for?
Failure models
• We will look into more detail into failure
and related notions in next lecture
• For now...
• Distributed systems can fail in nodes or
channels
• Node failures:
• What do we know about a design?
– Assumptions
– Outcomes: what we can guarantee, and
what we cannot guarantee
–
–
–
–
• Interaction/failure/security model
Project course TDDD36
Systems Software module
20 of 25
Autumn 2012
21 of 25
Autumn 2012
Crash
Channel failures?
Omission
timing
Byzantine (arbitrary)
Project course TDDD36
Systems Software module
Fundamental models
22 of 25
Autumn 2012
Security model
• What is a model good for?
• Security in a distributed system can be
achieved by securing
• What do we know about a design?
– the nodes/processes
– the channels used for interaction
– the encapsulated objects against
unauthorised use
– Assumptions
– Outcomes: what we can guarantee, and
what we cannot guarantee
• Interaction/failure/security model
Project course TDDD36
Systems Software module
23 of 25
Autumn 2012
Project course TDDD36
Systems Software module
24 of 25
Autumn 2012
4
Threat model
• Identifying the adversary model helps to
identify
– Threats to channels
– Threats to processes and potential for denial
of service
• This helps to identify appropriate
counter measures
– Secure channels, access control and
monitoring activities
Project course TDDD36
Systems Software module
25 of 25
Autumn 2012
5