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