Introduction Architecture Models Fundamental Models Summary Chapter 2: System Model.
-
Upload
moris-morrison -
Category
Documents
-
view
223 -
download
0
Transcript of Introduction Architecture Models Fundamental Models Summary Chapter 2: System Model.
• Introduction• Architecture Models• Fundamental Models• Summary
Chapter 2: System Model
Introduction
• Why do we need model?– Each model is intended to provide an abstract, simplified
but consistent description of a relevant aspect of distributed system design
• Architecture model– defines the way in which the components of systems interact with one
another and the way in which they are mapped onto the underlying network of computers
– Client/Server vs. Peer to Peer– variants of C/S
partition of data or replication as cooperating servers caching of data by proxy servers and clients use of mobile code and mobile agents requirement to add and remove mobile devices in a convenient manner
Introduction …continued
• Fundamental model– concerned with a more formal description of the properties that are
common in all of the architectural models– The interaction model deals with performance and with
the difficulty of setting time limits in a distributed system– The failure model attempts to give a precise specification
of the faults that can be exhibited by processes and communication channels
– The security model discusses the possible threats to processes and communication channels
• Introduction• Architecture Models• Fundamental Models• Summary
Chapter 3: System Model
Concepts
• What does the architecture model consider?– The placement of the components across a network of
computers – seeking to define useful patterns for the distribution of data and workload
– The interrelationships between the components – their functional roles and patterns of communication between them
• Software layers– Originally refer to the structuring of software as layers
or modules in a single computer– Recently in terms of services offered and requested
between processes located in the same or different computers
Software layer
• Software and hardware service layers in distributed systems
• Platform– The lowest-level hardware and software layers, e.g., Intel x86/Wi
ndows, SPARC/SunOS, PowerPC/MacOS• Middleware
– A layer of software, mask heterogeneity, provide a convenient programming model to application programmers
– Examples: RPC, RMI, CORBA, DCOM, Isis(group communication system)
– Limitations: some systems require support at the application level e.g., In case of transferring large email message, TCP provides some
error detection and correction, but it can’t recover from major network interruptions. So the mail transfer service at the application layer is required.
– ‘ the end-to-end argument’ [1984] some communication-related functions can be completely and relia
bly implemented only with the knowledge and help of the application standing at the end points of the communication system
Counter to the view of middleware supporters (transparency entirely)
Software and hardware service layers in distributed systems
Applications, services
Computer and network hardware
Platform
Operating system
Middleware
System architectures
• What is system architecture?– The division of responsibilities between system
components (applications, server and other processes) and the placement of the components on computers in the network
• Main distributed system architectures1. Client-Server model
– Be Historically the most important and remain the most widely employed
– Servers may in turn be clients of other servers2. Services provided by multiple servers
– Partition the set of service objects on different servers, e.g. workflow system
– Maintain replicated service objects on several hosts, e.g. Sun NIS
3. Proxy servers and caches– A cache is a store of recently used data objects that is
closer than the objects themselves– E.g., web page cache at web browser or web proxy server
Clients invoke individual servers
Server
Client
Client
invocation
result
Serverinvocation
result
Process:Key:
Computer:
A service provided by multiple servers
Server
Server
Server
Service
Client
Client
Web Proxy Server
Client
Proxy
Web
server
Web
server
serverClient
System architectures … continued
4. Peer processes ( peer to peer )– All of the processes play similar roles, interacting cooperativel
y as peers to perform a distributed activity or computation without any distinction between clients and servers
– Maintain consistency of application-level resources and synchronize application level action when necessary
– E.g., a peer-to-peer whiteboard
A distributed application based on peer processes
Coordination
Application
code
Coordination
Application
code
Coordination
Application
code
Variations on the client-server model
• Reasons of variation– The use of mobile code and mobile agents– Users need for low-cost computers with limited hardware resources– The requirement to add and remove mobile devices in a convenient
manner• Several variations: 1. Mobile code
– good interactive response, e.g., applet2. Mobile agent
– A running program that travels from one computer to another in a network carrying out a task on someone’s behalf, e.g., agilet[IBM], worm[Xerox PARC]
3. Network Computers– Download its operating system and any application software
from a remote file server– All the application data and code is stored by a file server, so
users may migrate
Web applets
a) client request results in the downloading of applet code
Web server
ClientWeb serverApplet
Applet code
Client
b) client interacts with the applet
Variations on the client-server model … continued
4. Thin client– A software layer that supports a window-based user
interface on a computer that is local to the user while executing application programs on a remote computer
– Drawback : high latencies– Implementation: X-11, VNC[AT&T 1998]
5. Spontaneous networking – The form of distribution that integrates mobile devices and
other devices into a given network– Key features: easy connection to a local network, easy
integration with local services– Key design issues
Convenient connection and integration Limited connectivity: mobile device move around
continuously, disconnection Security and privacy Discovery Services: registration service, lookup service
Thin clients and compute servers
ThinClient
ApplicationProcess
Network computer or PCCompute server
network
Spontaneous networking in a hotel
Internet
gateway
PDA
service
Music service
serviceDiscovery
Alarm
Camera
Guestsdevices
LaptopTV/PC
Hotel wireless
network
Design requirements for distributed architectures
• Performance issues– Responsiveness: determined by the load and performance of the server a
nd network, delays in the client and server operating system’s communication and middleware services as well as code of the service
– Throughput: the rate at which computational work is done, the throughput of the intervening software layers is important
– Balancing computational loads• Dependability issues
– Fault tolerance: redundancy, e.g., data and processes be replicated, messages be retransmitted
– Security: e.g. locate sensitive data in computers that can be secured effectively against attack
• Quality of service– Reliability, security– Performance: ability to meet timeliness guarantees– Adaptability: meet changing system configurations and resource – Availability: have necessary computing and network resources at the app
ropriate times ( the abbreviation QoS)• Use of caching and replication, e.g. Web caching protocol
• Introduction• Architecture Models• Fundamental Models• Summary
Chapter 3: System Model
Fundamental models
• A system model should address the following questions– What are the main entities in the system?– How do they interact?– What are the characteristics that affect their individual
and collective behavior?
• Purpose of a model– Make explicit all the relevant assumptions about the
system we are modeling– Make generalizations concerning what is possible or
impossible by logical analysis and mathematical proof
• Fundamental models intend to discuss– Interaction– Failure– Security
Interaction model
• Examples of interaction in distributed system– DNS, NIS: multiple server processes cooperate with one another – P2P voice conference system: with strict real-time constraints
• Distributed algorithm: a definition of the steps to be taken by each of the processes of which the system is composed, including the transmission of messages between them– Difficult to describe all the states, because of failures of processes
and message transmissions• Two significant factors affecting interacting processes
– Communication performance is often a limiting characteristic Latency – the delay between the sending of a message by one process
and its receipt by another. Including: Network delay, Accessing delay, OS delay
Bandwidth – total amount of information that can be transmitted over it in a given time
Jitter – variation in the time taken to deliver a series of messages– Impossible to maintain a single global notion of time
Clock drift rate – the relative amount that a computer clock differs from a perfect reference clock
Timing event: e.g., GPS, Logical time
Two variants of the interaction model
• Synchronous distributed system– The time to execute each step of a process has know 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 a known bound
• Asynchronous distributed system – no bounds on – process execution speeds: e.g. each step may take an
arbitrarily long time– Message transmission delays: e.g. a message may be
received after an arbitrarily long time – Clock drift rates: the drift rate of a clock is arbitrary
• Examples of synchronous DS and asynchronous DS– Asynchronous DS: email, ftp– Synchronous DS: VOD, voice conference system
Event ordering
• Example: disorder of messages– A group including X, Y, Z and A– X send “Meeting” to all; Y and Z reply “Re: Meeting” to all– At A, the messages received are Z.”Re: Meeting”, X.”Meetin
g”, Y.”Re: Meeting”• Logical time[Lamport 1978]
– Provide an ordering among the events at processes running in different computers in a distributed system
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
• Failure model: defines the ways in which failure may occur in order to provide an understanding of the effects of failures and defeat the failures
• Failure models:1. Omission failures
– A process or communication channel fails to perform actions that it is supposed to do
– Process omission failure: Crash Fail-stop: Crash that can be detected by other processes
certainly, e.g., by timeouts in synchronous DS– Communication omission failures: dropping messages
Send omission, receive omission, channel omission– Benign failuresprocess p process q
Communication channel
send
Outgoing message buffer Incoming message buffer
receivem
Failure model …continued
2. Arbitrary (Byzantine) failures– the worst possible failure semantics– Arbitrarily omit intended processing steps or take unintended proce
ssing steps. E.g., return a wrong value in response to an invocation– Arbitrary failures in process is hard to be detected, Arbitrary failures
in communication channel exist but rare, by recognize and reject the faulty msgsClass of failure Affects Description
Fail-stop Process Process halts and remains halted. Other processes maydetect this state.
Crash Process Process halts and remains halted. Other processes maynot be able to detect this state.
Omission Channel A message inserted in an outgoing message buffer neverarrives at the other end’s incoming message buffer.
Send-omission Process A process completes a send, but the message is not putin its outgoing message buffer.
Receive-omissionProcess A message is put in a process’s incoming messagebuffer, but that process does not receive it.
Arbitrary(Byzantine)
Process orchannel
Process/channel exhibits arbitrary behaviour: it maysend/transmit arbitrary messages at arbitrary times,commit omissions; a process may stop or take anincorrect step.
Failure model …continued
3. Timing failures– Applicable in synchronous distributed system, but not
asynchronous DS
• Masking failures– Hide, e.g., replicated servers– convert, e.g., Checksum: arbitrary failure -> omission failure
• Reliability of one-to-one communication– Validity – any message in the outgoing message buffer is
eventually delivered to the incoming message buffer– Integrity – the message received is identical to one sent, and
no messages are delivered twice, against retransmit protocols and malicious messages
– Reliable communication is defined in terms of validity and integrity
Class of Failure Affects DescriptionClock 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
• The security of a distributed system – The processes – The communication channels– The objects
• Protecting the objects– Access rights: who is allowed to perform the operations of
an object– Principal: the authority who has some rights on the object
Network
invocation
resultClient
Server
Principal (user) Principal (server)
ObjectAccess rights
Securing processes and their interactions
• The enemy– Threats to processes
To servers: invocate with a false identity, e.g. cheating a mail server
To clients: receive false result, e.g. stealing account password
– Threats to communication channels Copy, alter or inject messages Save and replay, e.g., retransfer money from one account to
another– Denial of service: excessive and pointless invocation on
services or message transmissions in a network, resulting in overloading of physical resources (network bandwidth, server processing capacity)
– Mobile code: malicious mobile program, e.g. Trojan horse attachment
Communication channel
Copy of m
Process p Process qm
The enemym’
Securing processes and their interactions … continued
• Defeating security threats– Cryptography and shared secrets
Identify each other by the shared secrets that are only known by themselves. Cryptography is the base.
– Authentication – proving the identities supplied by their senders
– Secure channels Each process knows reliably the identities of the principal on
whose behalf the other process is executing Ensure the privacy and integrity of the data transmitted
across it Each message includes physical or logical time stampPrincipal A
Secure channelProcess p Process q
Principal B
• Introduction• Architecture Models• Fundamental Models• Summary
Chapter 3: System Model
Summary
• Architecture models– Client / Server, e.g. Web, FTP, NEWS– Multiple Servers, e.g. DNS– Proxy and Cache, e.g. Web Cache– Peer process– Variations of C/S
Mobile code, mobile agent, network computer, thin client, spontaneous networks
• Fundamental models– Interaction models – synchronous DS and asynchronous DS– Failure models – omission failures, arbitrary failures and
timing failures– Security model - the enemy and the approaches of
defeating them