dr. christian vecchiola postdoctoral research fellow [email protected] cloud computing and...
Post on 21-Dec-2015
218 views
TRANSCRIPT
Dr. Christian VecchiolaPostdoctoral Research Fellow
Cloud Computing and Distributed Systems (CLOUDS) Lab
Dept. of Computer Science and Software Engineering
The University of Melbourne
Distributed System Models
Most concepts aredrawn from Chapter 2© Pearson Education
Most concepts aredrawn from Chapter 1© Pearson Education
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Outline Introduction Architectural Models– Characterization– Software Layers– System Architectures – Design Challenges/Requirements
Fundamental Models– Interaction– Failure– Security
Summary
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Introduction
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Introduction
Overview– 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
–We will study distributed system models from different perspectives• Structure, organization, and placement of components• Interactions• Fundamental properties of systems
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Characterization– The structure and the organization of systems and
the relationship among their components should be designed with the following goals in mind:• To cover the widest possible range of circumstances.• To face the possible difficulties and threats.• To meet the current and possibly the future demands.
– Architectural models provide both:• a pragmatic starting point• a conceptual view
to address these challenges.
In terms of implementation models and basic blocks
In terms of logical view of the system, interaction flow, and components
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Characterization– Challenges (more…)• Widely varying models of use
– High variation of workload, partial disconnection of components, or poor connection.
• Wide range of system environments– Heterogeneous hardware, operating systems, network, and
performance.
• Internal problems– Non synchronized clocks, conflicting updates, various hardware
and software failures.
• External threats– Attacks on data integrity, secrecy, and denial of service.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Characterization– Observations• Widely varying models of use
– The structure and the organization of systems allow for distribution of workloads, redundant services, and high availability.
• Wide range of system environments– A flexible and modular structure allows for implementing different
solutions for different hardware, OS, and networks.
• Internal problems– The relationship between components and the patterns of
interaction can resolve concurrency issues, while structure and organization of component can support failover mechanisms.
• External threats– Security has to be built into the infrastructure and it is fundamental
for shaping the relationship between components.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Characterization–What is an architectural model?
An architectural model of a distributed system is concerned with the placement of its parts and the
relationship between them.
It defines the way in which the components of systems interact with one another and the way in which they
are mapped onto an underlying network of computers.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Characterization– A Distributed System is ultimately composed by
processes communicating over a network.– A first (rough) classification can be done by
discriminating the process types:• Server processes• Client processes• Peer processes• (Possible variations and compositions)
– Such classification leads to a first categorization of architectural models.
Client-Server Systems
Peer-to-Peer Systems
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Characterization– Some Examples:• Client Server Model
– Placement: two distinct roles (1 server, multiple clients)– Relationship: the server provide services, the clients consume
them– Communication: asymmetric
• Peer-to-Peer Model– Placement: one single role, the peer– Relationship: all the peer have the same responsibilities– Communication: symmetric
client server
peer
peer
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Model
Characterization– Other models• Mobile Code based Systems
– Code is dynamically moved among hosts» Web applets (Java, Flash)» Mobile agents
– Security is a concern
• Ad-hoc Systems (based on proximity networks)– High dynamism and volatility of system components– More heterogeneity in the devices connected to the system– Limited capabilities (often)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Software Layers– Despite the specific model used for
describing/implementing a system a reference software architecture can be defined.
– A software architecture..• ..identifies the organization of a software system
(single or multi-computer)• ..can be expressed in terms of cooperating
– layers (very general, applicable to all the systems)– modules (for component-based systems)– services (more appropriate for DS and SOA)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Software Layers–Why layers?• Breaking up complexity• Decomposition of
– functions– responsibilities
• Different levels of abstraction• Well proven model
– TCP/IP Stack– ISO/OSI Architecture
Layer N
Layer 1
Layer 0
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Software Layers– Layers in Distributed Systems
Application & Services
Middleware
Operating System
Computer and Network Hardware
Platform- Comprises mostly hardware and OS- Provides basic services to upper level: - Process communication - Process coordination and management - Resource management- Examples: - Intel x86/Windows - Intel x86/Solaris - PowerPC/Mac OS X, Intel x86/MAC OS X - Intel x86/Unix(Linux)….
Middleware- Masks heterogeneity- Provides convenient programming model- Composed of distributed processes or objects- Communication support & resource sharing - RPC / RMI - Event notification - Shared data placement/retrieval/replication-Examples - CORBA / Microsoft DCOM - Java RMI / .NET Remoting - Web Services - ISO/ITU-T RM-ODP
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Software Layers–Middleware• Common stratus for developing application services• Infrastructure component that ties together the
different parts of the distributed system• Modern examples
– Sun J2EE– Microsof .NET– IBM WebSphere – IBM BlueCloud– Manjrasoft Aneka – Google AppEngine
Cloud Computing Platforms (PaaS)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures–Middleware is the layer where most of the
architectural model realizations take place.– A layered architecture allows for a partition of
responsibilities among the different layers of the system.
– At the middleware level a further distribution of responsibilities and functions between components takes place.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Different architectural models partition such
responsibilities in different ways.– This partitioning has an impact on:
• Performance• Reliability• Security
– In deciding how to make this partitioning several trade-offs apply.
– We will investigate the different advantages/disadvantages of the most common models.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Software Architectures– Client Server Model• Mostly cited in the case of distributed systems.• Most widely employed.• Based on:
– Two roles: server and client– Communication pattern:
» asymmetric» request (client) – response (server)
• Examples– HTTP, SMTP, DNS, NNTP
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Software Architectures– Client Server Model
Time
Server
Client
t2
t3t1
t4
t1: request timet2: server process timet3: response timet4: roundtrip time
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms System Architectures
– Client-Server• Two-tier model (classic)
• Three-tier (when the server, becomes a client)
• Multi-tier (cascade model)
Architectural Models
client server
client Server/client server
client Server/clientserver
Server/client
server
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Peer-to-Peer Model• All the processes play a similar role.• No distinction between server and client that are
played by each component.• Cooperative interaction.• Avoids centralization and potential SPOF• More difficult to manage• Provides a better scalable infrastructure (1000s hosts)• Examples
– P2P File sharing (OpenNAP, eMule, etc..)– Distributed Hash tables
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Model
System Architectures– Peer-to-Peer model
peer
peer
peer
peer
peer
peer
peer
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architecture– Variations of the previous two models• Multiple Server (kind of multi-tiers)• Cache and Proxy architectures• Mobile Code• Mobile Agents• Network Computers• Thin Clients• Mobile devices and ad-hoc networking
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Services provided by multiple servers• Extension of the Client-Server Model• A server response can be the result of
– a cascade request-response (multi-tier model)– the collaboration of several processes which might be
» partitioned in several nodes» replicated in several nodes
• Examples:– Web page content as composition of…
» Database queries» Static content embedding» Web Service calls
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Proxy Servers and Caches• A cache is a store of recently used data object that is
closer than the object themselves.• Proxy servers uses caches to maintain a copy of the
content that is frequently accessed, in order to– increase availability of content– increase the performance of requests serving– reduce the traffic load on a wider scale– make accessible content, not accessible otherwise (e.g.
firewalls)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Proxy Servers and Caches• Examples
– Web Browser cache» The web browser maintains copies of the recently
visited pages on a local store» This version of the pages is returned to the use r when
he or she looks for the same page» Specific HTML tags can control the validity of the
cached web pages– Web Proxy Server
» The caching mechanism is similar..
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Proxy Servers and Caches• Caching in action!
1st Request
2nd Request
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures–Mobile Code• Mobile code generally refers to an application,
component, or a program that can migrate during its life cycle.• To certain extent, it is also considered mobile code, a
software component that is dynamically downloaded and integrated to an existing application.– Example:
» Applet or Flash in a browser.» Dynamic plug-ins.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms System Architectures
–Mobile Code – Applet model
Architectural Models
Server
Client
Browser process space
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures–Mobile Agents• Mobile Agents incarnate a better example of mobile
code.• They are programs that can migrate among different
hosts, during their life cycle and carry their computation along the way.• Main problem with mobility:
– reconstruction of state
• Two main models:– Strong mobility full state persistence (stack frame)– Weak mobility partial state persistence (checkpointing)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures–Mobile Agents• Possible uses of mobile agents:
– Information collection– Computation locality
» Mobile agents can move computation in situ» This approach is useful when the data size is huge
• Disadvantages– Security threats (host and guest)– Compatibility of the hosting environment
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Network Computer and Thin Clients• Network computers provide terminals
– whit the minimum required software installed locally– that download operating systems and application software
from a remote file server
• In this model:– Applications are run locally– Files (and data in general) are managed remotely– A minimal computational capacity (memory and CPU) is
required.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures– Network Computer and Thin Clients• Thin Client constitute a software layer that provide a
GUI access to a remote machine where application are executed.• Comparison with Network Computers
– Same management costs– No download of OS and software locally
• Disadvantage:– Low performance for highly demanding graphical
applications.
• Example:– X-11, VNC, Remote Desktop..
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
System Architectures–Mobile devices and spontaneous interoperation• Mobile devices involve mobile hardware and not
mobile software.• Mobile devices
– migrate among different computing environments– adapt themselves/ integrate with existing environment
• Main problems– Variable connectivity– Relocation of services– Transition between different networks– Discoverability of services
Mobnility Trasparency
Context Awareness &Spontaneous Interaction
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Interfaces and Objects– A distributed systems is a set of cooperating
processes.– Processes communicate among each others• At low level
– Message passing– Raw communication with sockets
• At high level– By using specific and well defined interfaces– Remote Objects
This patterns provides a more flexible and dynamic partitioning of the responsibilities if compared to the static Client-Server model.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Distributed Architectures Challenges–Main goal of DS: Sharing Resources– History:
• 1960 – First Timesharing systems• 60s – Multiuser operating systems (UNIX)• 70s – 80s First Distributed Systems (devices sharing)• 80s Clusters• 90s Grids• …. Clouds
– Still today…
Sharing data & resources on a large scale is still a challenge!
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Distributed Architecture Challenges– In particular the following aspects have to be
considered:• Performance• Quality of Service• Data and Replica management (caching)• Dependability
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Performance Issues– They arise from the limited processing and
communicating capacities of computers and networks.– What to consider:
• Responsiveness– Interactive application need to be responsive– Bottlenecks can be at each level of the communication stack
• Throughput– This is a common measure for DS– Heterogeneity in a DS may affect throughput
• Load-balancing– DS allow for concurrent execution without competition– Lack of competition can be obtained by
» decentralizing processing » data & services replication
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Quality of Service– QoS concerns non-functional properties of the
system.– By non-functional we mean that:
• A QoS evaluation is not intended to verify whether a operates correctly from a logical point of view.
• A QoS evaluation provides insights on the behavior of the system from the point of view of parameters that characterize how a service operating correctly performs its task.
– Example - File Server: • a functional parameter might be the capability of retrieving a file• QoS parameters are: guaranteed bandwidth, reliability
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Quality of Service– Parameters of interest for Distributed Systems• Reliability & Security:
– How much the system is robust?– What are the security measures put in place (protocols,
standards, encryption level)?
• Performance– Throughput, load balancing, responsiveness.
• Adaptability– How much the system is able to meet the changing
requirements?
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Data Replication and Caching– Performance is the major issue in DS deployment– How can we address performance loss?• Data replication and load balancing
– We can increase the throughput
• Data caching– We can reduce the service time
Data caching poses the problem of obsolete information and different strategies can be implied to avoid the use of content
not anymore valid.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Data Replication and Caching– Obsolete content detection and management• The web caching protocol uses two strategies
– Cache validation– Expiration time on cache content
• How they work– Each content maintained in the cache has an expiry date.– The expiry date of a cached item can be checked against the
server, which will return a fresh copy in case of expiration.– The browser or the proxy do not need to check every time:
» Server sends current time and expiry time for response» Browser (proxy) can estimate whether to request a
fresh copy or not.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Dependability–What is dependability?
“The value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her.”
– In systems engineering… “..the trustworthiness of a computing system which allows reliance to be
justifiably placed on the service it delivers ..”
[IFIP 10.4 Working Group on Dependable Computing]
“ dependability (is) the collective term used to describe the availability performance and its influencing factors : reliability performance, maintainability performance and maintenance support performance”
[Technical Committee 56 Dependability – IEC]
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Dependability– In other words…
– How can we measure dependability?• Attributes: Availability, Reliability, Safety, Integrity, Confidentiality,
Maintainability.
–What tampers dependability?• Threats: Faults, Errors, Failures.
–What can we do to ensure dependability?• Means: Prevention, Fault-tolerance, Forecasting.
How much we can trust, rely on a system?
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Design Requirements
Dependability– In particular…• Fault tolerance:
– Dependable application in order to be reliable should keep operating in the presence of hardware, software, and network faults.
– In order to achieve reliability, redundancy (i.e. data & services replication, message retransmission) is applied.
• Security:– Sensitive data must be placed only on hosts that can actively
respond to attacks, and safely protect information.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
A different perspective…– Architectural Models
• Internal organization, placement of components, and interaction patterns
– Design Requirements• Thoughts on performance and reliability characteristics of
distributed systems
– Fundamental Models• Based on the fundamental properties that can give insights on
– characteristics of the system– associated failure an security risks it might exhibit
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
What is a model?– It provides only essential elements to consider for
reasoning and understanding the system behavior. – Addresses the following questions:
• What are the main entities in the system?• How do they interact?• What are the characteristic that affect their individual and collective
behavior?
– We use a model for…• Making relevant assumptions about the system modeled.• Making generalizations concerning what is possible or not possible.
These generalization assume the form of algorithms or properties that are guaranteed (i.e. dependent on logical analysis or mathematical proof)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Aspect to consider for DS– Interaction
• DS are constituted by interacting processes • Interaction can be:
– Communication (message passing)
– Coordination (information flow)
– Failure• Faults occurs usually in distributed environment• A classification of them helps understanding the weakness of the
systems and the possible counter-actions.
– Security• Modularity and openness expose the system to threats• It is necessary to classify the attacks and devises potential
resistance measures.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Facts:• Communication takes place with delays (often of
considerable duration)• Delays and the absence of global time limit the
accuracy with which we can coordinate processes.
–What are the element of interest?• Performance Communication Channels• Computer Clocks and Timing Events• Synchronous vs Asynchronous models• Event Ordering
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Performance Communication Channels• Various implementations• In general the following elements are important:
– Latency» Time taken for transmitting the first bit of a string of bytes» Delay in accessing the network (varies according to load)» Time taken by communication service and OS for processing
– Bandwidth» Total amount of information transmissible in the unit of time
– Jitter » Variation in the time taken to deliver a message
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Computer Clocks and Timing Events• Each computer has its own internal clock.• Two processes running on different computers will
end up to have a different clock (and timestamps for events)• Computer clocks drift from the perfect time at
different rates.• Without corrections such clocks will vary
considerably over a long period of time.• Possible solutions:
– GPS (ok for open spaces) – Timing protocols (variable to message delays)
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Synchronous vs Asynchronous Models• Synchronous Systems (Assumptions)
– Process step execution time has known lower and upper bounds.– Each message transmission over a channel has a bounded time.– Local clock drift rate from real time has a known bound.
• Asynchronous Systems – None of the previous assumptions are valid.– Heterogeneity in all of the three aspects.
• Observations:– It is possible to suggest likely upper and lower bound.– It is very difficult to provide accurate realistic values.– The use of synchronous system models is not realistic but might be
helpful in designing initial versions of the system.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Event Ordering• Sequence of events is important• The execution of a system can be described in terms
of the sequence of events that occur in it• Clocks cannot be synchronized perfectly across a
distributed system.• It is possible to order events in the absence of global
clock?
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Event Ordering – The meeting problem
m1X
t2 t3t1
Y
Z
A
m2
m3
send send send
receive
receive receive
receive receive
receive
receivereceivereceive
Inbox of A:…23 Z Re: Meeting24 X Meeting25 Y Re: Meeting….
Can A reconstruct the proper sequence?
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Interaction Model– Event Ordering• Logical Time (Lamport 1978) can help reconstruct the
sequence ordering of events in absence of global clock.• A number is assigned to each event.• This number represents the logical order of the event
in the sequence.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Failure Model–What is failure?
• Process and communication may depart from what is the expected behavior.
–What is a failure model?• Defines the ways in which failure may occur in order to provide
understanding of the effects it can cause.
– Observations• Different kinds of failures can be addressed differently• Different kinds of failures denote different (major or minor)
problems• Classification of failures is then important.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Failure Model– Taxonomy of Failures• Applies to Processes and Communication• [Hadzilacos and Tueg, 1994]
– Categorization:• Omission Failures• Arbitrary or Byzantine Failures• Timing Failures
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Failure Model– Omission Failures• Characterization
– A process or a communication channel fails in performing what it is supposed to do.
• Possible Types:– Process omission Failures
» Process crashes (fail-stop if can be detected, complete crash or abnormal residual behavior?)
– Communication channel Omission Failures» Dropping messages (channel omission)» Send-omission failures» Receive-omission failures
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Failure Model– Arbitrary Failures or Byzantine Failures• Characterization
– Worst possible failure semantics.– Any type of any error can occur.
• Types:– Process arbitrary failures
» Insertion of invalid data.» Invalid execution paths.
– Channel arbitrary failures» Message content corruption» Unintended messages delivered» Duplication
Easily detectable by the communication software.
Difficult to detect by simply checking whether the process responds to
the invocation..
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Failure Model– Timing Failures• Synchronous Systems
– An operation executes beyond its time limits.
• Asynchronous Systems– Difficult to characterize, since there are no bounds on the
time.
• Solutions:– Real-time operating systems
• Where to:– Multimedia computer with audio and video channels.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Failover Model–Masking Failures• It is possible to construct reliable services from
components that exhibit failures.• Failure detection is important to identify the wrong
behavior and then provide a counter-measure– Data replication– Checksums and error correction– Message retransmissions
• A failure can be …– … completely masked – … turned into an acceptable failure
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– The security of a distributed system can be
achieved by• Securing the processes composing the system.• Securing the channels they use to communicate.• Protecting the objects they encapsulate by
unauthorized access.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Protecting objects• Avoiding unauthorized access• Identifying
– who is accessing what– what permission does he/she have on the object
• Each service request operating on sensitive objects has to occur under a specific authority– Concept of Security Principal– Concept of Access Rights.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Protecting objects• Example
Sensitive Object
Internet <Untrusted Zone>
Security Service
User
Request + Credentials
Server
Principal + Access Rights
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Securing Processes and their Interactions• Process interact through
– Message passing– Publicly available interfaces
• Assumptions– The communication channel is untrusted– Potential misuses of the services exposed by the process
• Observations– How can we protect processes from the enemy?– What are the potential threats?
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Identifying the Enemy• Malicious entity (user or program) capable of
– sending message through the network to any process– reading or copying any message between a pair of processes– impersonating one end point of the communication
m1 m1’
m1
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Architectural Models
Security Model– Classification of Threats• Threats to Processes
– Impersonation (generation, alteration of network packets)– Threats to both servers (requests) and clients (responses)
• Threats to Communication Channels– Injection, alteration of messages– Message copy– Threats for privacy and integrity– Countermeasure: secure channels
• Denial of Service: generation of false request• Mobile Code: untrusted, unknown, potentially
harmful
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Countermeasures• Cryptography and shared secrets
– Processes shared a secret helping them communicating safely– The shared secret can be used as key to encrypt messages over an
unsecure channel– Cryptography: science of keeping message secures– Encryption: process of altering a message so that its content cannot
be read by unintended receivers.
• Authentication– The knowledge of the secret ensures the identity of both endpoints– The secret can be used to identify the sender
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Countermeasures• Secure Channels
– Encryption and Authentication can be used to build a secure channel.
– A secure channel can be considered as a service layer on top of existing communication services.
– It is a communication channel that connects a pair of processes, each of which acts on behalf of a principal.
• Channel properties.– Each end point knows who resides on the other end point.– The channel ensures privacy and integrity of messages.– Each message includes a physical and logical time-stamp to
prevent copies.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Use of Security Models• The techniques discussed in this section constitute the
fundamental blocks to build a security infrastructure.• Additional issues arises in a real system
– Performance vs Security: security measure introduce processing costs.
– Other threats beyond the ones listed can be considered» Human factor» Geo-location
• A careful analysis of all the aspects of a DS (hardware, software, network, and human) allows to build a threat model.
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Fundamental Models
Security Model– Use of Security Models• The threat model lists all the potential attacks that the
systems might be exposed to.• Security costs have to be balanced against these
attacks• Bottom line:
– “how much your enemy is willing to pay to break your security?”
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Summary
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Summary
What do we have learnt?– Architectural Models
• An architectural model of a distributed system is concerned with the placement of its parts and the relationship between them.
• It defines the way in which the components of systems interact with one another and the way in which they are mapped onto an underlying network of computers.
– Design Requirements• Focus on performance, quality of service, dependability and security
– Fundamental models• What is a model and its characteristics• 3 Fundamental models
– Interaction model– Communication model– Security model
Dis
trib
uted
Sys
tem
Mod
els
Dis
trib
uted
Sys
tem
s P
rinc
iple
s an
d Pa
radi
gms
Questions?