Distributed Systems - PowerPoint PPT Presentation

1 / 56
About This Presentation
Title:

Distributed Systems

Description:

Concealment from the user and the application programmer of the separation of ... Failure transparency: enables the concealment of faults, allowing users and ... – PowerPoint PPT presentation

Number of Views:32
Avg rating:3.0/5.0
Slides: 57
Provided by: Car8174
Category:

less

Transcript and Presenter's Notes

Title: Distributed Systems


1
Distributed Systems
  • (lecture 3 - 04/10/06)( - Challenges )
  • - Architectural models- Fundamental models

2
Sistemi Distribuiti
  • Vi ricordo che ...
  • Iscrizione OBBLIGATORIA al corso da effettuarsi
    tramite bacheche elettroniche .....
    sis.dei.unipd.it) (seguire il link Informazioni
    delle strutture-Dipartimento di Ingegneria
    dellInformazione-Liste di iscrizione ad appelli
    o corsi-Iscrizione a un appello o corso e poi
    selezionare dalla lista Sistemi Distribuiti)
  • Iscrizioni aperte dal 2 al 6 ottobre

3
Summary of lecture 2Distributed Systems Design
Challenges ...
  • Heterogeneity ... Middleware, VM
  • Openness ... Key software interfaces
  • Security ... encryption and knowledge of identity
  • Scalability
  • Failure handling ... recovery
  • Concurrency ... synchronisation and communication
  • Transparency ...

4
Transparency
  • Concealment from the user and the application
    programmer of the separation of components in a
    Distributed Systems, so that the system is
    perceived as a whole rather than as a collection
    of independent component

5
Transparencies
  • Access transparency enables local and remote
    resources to be accessed using identical
    operations.
  • Location transparency enables resources to be
    accessed without knowledge of their physical or
    network location (for example, which building or
    IP address).
  • Concurrency transparency enables several
    processes to operate concurrently using shared
    resources without interference between them.
  • Replication transparency enables multiple
    instances of resources to be used to increase
    reliability and performance without knowledge of
    the replicas by users or application programmers.

6
  • Failure transparency enables the concealment of
    faults, allowing users and application programs
    to complete their tasks despite the failure of
    hardware or software components.
  • Mobility transparency allows the movement of
    resources and clients within a system without
    affecting the operation of users or programs.
  • Performance transparency allows the system to be
    reconfigured to improve performance as loads
    vary.
  • Scaling transparency allows the system and
    applications to expand in scale without change to
    the system structure or the application
    algorithms.

7
  • Common design problems
  • Different modes of use
  • Different infrastructures
  • Non syncronized clocks
  • Conflicting data updates
  • Many modes of failures
  • Attack on data integrity
  • Denial of service

8
Models ...
  • Shared properties and common design problems can
    be represented in the form of descriptive models
  • Each model is intended to provide an abstract,
    simplified but consistent description of a
    relevant aspect of the design

9
  • Architectural models are concerned with
  • the placement of parts and the relationship
    between them
  • The mapping onto the underlying network of
    computers
  • Fundamentals models
  • interaction
  • failure
  • security

10
System architectures
  • Software layers
  • Architectural models
  • client-server, peer processes,
  • mobile code, agents,...

11
Software Layers
12
Middleware provides...
  • support for distributed processes/objects
  • suitable for applications programming
  • communication via
  • remote method invocation (Java RMI), or
  • remote procedure call (Sun RPC)
  • services infrastructure for application
    programs
  • naming, security, transactions, event
    notification, ...
  • products CORBA, DCOM

13
  • Support a higher level of abstraction for
  • Communication between group of processes
  • Notification of events
  • Replication of shared data
  • Multimedia data transmission in real time

14
Important layers
  • Platform
  • lowest-level hardwaresoftware
  • common programming interface, yet
  • different implementations of operating system
  • facilities for co-ordination communication
  • Middleware
  • programming support for distributed computing

15
  • Object Management Groups Common Object Request
    Broker Architecture
  • (CORBA)
  • Microsoft Distributed Component Object Model
    (DCOM)
  • ISO/ITU-Ts Reference Model for Open Distributed
    Processing (RM-ODP)

16
The layered view...
  • though appropriate for simple types of resource
    data sharing
  • e.g. databases of names/addresses/exam grades
  • too restrictive for more complex functions?
  • reliability, security, fault-tolerance, etc,
    need access to applications data
  • see end-to-end argument Saltzer, Reed
  • Clarke

17
  • Some communiction-related functions can be
    completely and reliably implemented only with the
    knowledge and help of the application standing at
    the end points of the communication systems
  • Saltzer, J.H., Read, D.P. and Clarke, D. (1984).
    End-to-End Arguements in System Deisgn. ACM
    Transactions on Computer Systems Vol. 2, No 4,
    pp. 277-288

18
  • Checks, error-correction mechanism and security
    are at many levels ...
  • Checking the correctness within the communication
    systems could not be enough

19
Architectural models
  • Define
  • software components (processes, objects)
  • ways in which components interact
  • mapping of components onto the
    underlying network
  • Why needed?
  • to handle varying environments and usage
  • to guarantee performance

20
Main types of models
  • Client-server
  • first and most commonly used
  • Multiple servers
  • to improve performance and reliability
  • e.g. search engines (1000s of computers)
  • Proxy servers
  • to reduce load on network, provide access
    through firewall
  • Peer processes
  • when faster interactive response needed

21
Client server
22
Client-Server Systems
23
(No Transcript)
24
Peer processes
25
A distributed application based on peer processes
26
Multiple servers
27
Proxy servers
28
Client server and mobility
  • Mobile code
  • downloaded from server, runs on locally
  • e.g. web applets
  • Mobile agent (code data stato)
  • travels from computer to another
  • collects information, returning to origin.
    Beware! Security risks

29
Web applets
30
  • Network computers
  • Thin clients ... See X-11
  • Mobile devices forming spontaneous networks

31
Spontaneous networks ...
  • Easy connection to a LAN
  • Easy integration with local services
  • Limited connectivity
  • Security and privacy
  • Discovery serviceregistrationlookup

32
(No Transcript)
33
Design Requirements for DSs
  • Judging how good the architecture is...
  • Performance
  • how fast will it respond?
  • Quality of Service
  • are video frames and sound synchronised?
  • Dependability
  • does it work correctly?

34
Performance
  • Responsiveness
  • fast interactive response delayed by remote
    requests
  • use of caching, replication
  • Throughput
  • dependent on speed of server and data
    transfer
  • Load balancing
  • use of applets, multiple servers

35
Quality of Service (QoS)
  • Non-functional properties experienced by users
  • Deadline properties
  • hard deadlines (must be met within T time
    units)
  • soft deadlines (there is a 90 chance that
    the video frame will be delivered within T time
    units)
  • multimedia traffic, video/sound synchronisation
  • depend on availability of sufficient resources
  • Adaptability
  • ability to adapt to changing system
    configuration

36
Dependability
  • Correctness
  • Reliability
  • Security
  • Cost-effectiveness
  • adaptability

37
Dependability
  • Correctness
  • correct behaviour wrt specification
  • e.g. use of verification
  • Fault-tolerance
  • ability to tolerate/recover from faults
  • e.g. use of redundancy
  • Security
  • ability to withstand malicious attack
  • e.g. use of encryption, etc

38
Fundamental models
  • Interaction model ... It reflects communication
    delays and limited accuracy
  • Failure model ...
  • Security model ...

39
Interaction model
  • It deals with communication and coordination
  • Distributed Algorithms ...
  • No matter how communication channels are realized
    ....
  • Latency
  • Bandwidth
  • Jitter
  • Clock drift

40
  • Synchronous distributed systems
  • Clock drift
  • Execution step
  • Message transmission time
  • Asynchronous distributed systems
  • Agreement problem

41
  • Event ordering
  • Occurred before
  • Occurred after
  • concurrent

42
Figure 2.8Real-time ordering of events
43
  • A message is received after it is sent
  • Replies are sent after receiving messages

44
then ...Interaction model
  • Synchronous distributed systems
  • Step execution, message trasmission time and
    clock drift are bounded.
  • Asynchronous distributed systems
  • Temporal ordering of events ... Logical time

45
Failure model
  • To provide an understanding of the effects of
    failures .... DSs expected to continue if failure
    has occurred
  • Omission failures
  • Process omission failures ... A stop, A crash ...
    A clean crash ...

46
  • Communication omission failures
  • Send-omission
  • Receive-omission
  • Channel-omission
  • The communication channel does not transport a
    message from the out buffer to the in buffer

47
Figure 2.9Processes and channels
48
Failure issues
  • Types of failures
  • omission, stopping, timing/performance
  • arbitrary (called Byzantine)
  • corrupt message, wrong method called, wrong
    result

49
Omission and arbitrary failures
50
Figure 2.10Omission and arbitrary failures
51
Figure 2.11Timing failures
52
Security models
  • Protecting objects ... Access rights
  • Securing processes and their interaction
  • Enemy (adversary) modeling

53
Figure 2.12Objects and principals
54
Figure 2.13The enemy
55
  • Cryptography and shared secrets
  • Authentication
  • Secure channels

56
Figure 2.14Secure channels
B
Principal
A
Principal
p
Process
Secure channel
Process
q
Write a Comment
User Comments (0)
About PowerShow.com