02 - distributed systems - técnico lisboa - autenticação · 02 - distributed systems ......

02 - Distributed Systems

● Definition

● (Dis)advantages

● Challenges

● Models

– Physical

– Architectural

– Fundamental

● Coulouris 1

● Coulouris 2

● Saltzer_84.pdf

2/58

Definition

● Distributed Systems

– Distributed System is a collection of independent computers that appear to its users as a single coherent system

● Examples of Distributed Systems:

– Computer cluster in a university

– Rent-a-Car database and reservation system

– SETI@home

– WWW

– Cloud

3/58

Parallel vs Distributed Systems

● A concurrent system could be Parallel or Distributed:

● Two possible Views to make the distinction

● View 1:

– Parallel System : A particular tightly-coupled form of distributed computing

– Distributed System: A loosely-coupled form of parallel computing

● View 2:

– Parallel System:processors access a shared memory to exchange information

– Distributed System: uses a “distributed memory”. Massage passing is used to exchange information between the processors as each one has its own private memory.

4/58

AdvantagesOver Centralized Systems

● Economics:– lower (price/performance) ratio

● Speed:– May have a more total computing power than a centralized system

– Enhanced performance through load distributing.

● Inherent Distribution:– Some applications are inherently distributed

● Availability and Reliability:– No single point of failure.

– The system survives even if a small number of machines crash

● Incremental Growth:

– Can add computing power on to your existing infrastructure

5/58

Advantagesover Independent PCs● Computation:

– can be shared over multiple machines

● Shared management of system:

– backups & maintenance...

● Data Sharing:– many users can access the same common database

● Resources Sharing:– can share expensive peripherals

● Flexibility:

– Spreading workload over the system CPUs.

6/58

Disadvantages

● Software:

– Developing a distributed system software is hard

– Creating OSs / languages that support distributed systems concerns

● Network:

– When network is overloaded/messages lost, rerouting/rewiring the network is costly/difficult

● Security :

– more sharing leads to less security especially in the issues of confidentiality & integrity

● Incremental growth is hard in practice

– due to changing of hardware and software

7/58

Distributed Systems

● Challenges

– Heterogeneity

– Openness

– Security

– Scalability

– Failure handling

– Concurrency

– Transparency

– Quality of service

8/58

Heterogeneity

● Applies to the following elements:

– Networks

– Hardware

– Operating Systems

– Programming languages

– Multiple implementations by different developers

9/58

Openness

● Capability of a system to be:

– Extended

– Implemented in various ways

● Determined by degree of

– How new services can be added

– How can be accessed by multiple clients

● Open systems

– Have interfaces published

– Are based on uniform communication mechanisms

– Can be built from heterogenous components● But components must be conform published standards

10/5

8

Security

● Security for resources has three components:

– Confidentiality● Protection agains disclosure to unauthorized individuals

– Integrity● Protection agains alteration and corruption

– Availability● Protection agains interference with the means to access the

resources

11/5

8

Sclability

● A system is scalable if

– Remain effective when there is an increase number of users

● Challenges

– Control the cost of physical resources

– Control performance lost

– Prevent SW resources starvation

– Avoid performance bottlenecks

12/5

8

Failure handling

● Fails produce incorrect results or stop services

● Failures handling techniques:

– Detecting failures

– Masking failures

– Tolerating failures

– Recovering from failures

– Redundancy

13/5

8

Concurrency

● Resources can be accessed simultaneously

– By multiple clients

● Serialization of requests limits throughput

● Concurrent processing should be allowed

– Shared resources should operate correctly in concurrent environment

● Server● Services● Objects

– Operations should be guarded

14/5

8

Transparency

● Concealment

– Of separation/distributions of components

– From the user and programmer

● System is perceived as a whole

– Rather than a collection of components

15/5

8

Transparency

● Access transparency

– Local and remote resources are accessed using the same operations

● Location transparency

– Resources can be accessed without knowledge of physical and network location

● Concurrency transparency

– Processes can operate concurrently using shared resources without interference between them

16/5

8

Transparency

● Replication transparency

– Multiple instances of a resource can be used without knowledge of the replicas by the users or application programmers

● Failure transparency

– Faults should be concealed

– Users and programs should complete their tasks despite failures of HW or components

● Mobility transparency

– Resources and clients can move within the system without affecting the operation of users and programs

17/5

8

Transparency

● Performance transparency

– Systems can be reconfigured to improve performance as loads vary

● Scaling transparency

– System and application can scale without change to the system structure and algorithms

● Network transparency

– Access● Local vs remote

– Location● Location independent addresses

18/5

8

Quality of service

● Users are provided with a functionality with a certain quality level

● Quality of service is affected by non-functional properties:– Reliability

– Security

– Performance

● Adaptability to changing configuration and resources

– Important aspect to Quality of service

● Performance

– Usually defined in terms of responsiveness and throughput

● QoS– Capability of a system to to meet pre-defined deadlines

– Reliability, security or performance

19/5

8

Physical models

● Early Distributed Systems– Late 70/early 80s

– 10..100 nodes

– Local network / Homogeneous / Few services

● Internet scale– 90s

– Internet based / Network of networks / Static

– Global / Heterogeneous (but server or client) / Open

● Contemporary– Mobile nodes (Wifi, GSM)

– Ubiquitous (embedded in objects and environment)

– Systems of systems (cloud)

– New level of heterogeneity (architecture and capabilities)

20/5

8

Physical models

21/5

8

Architectural models

● What entities are communicating in a DS?

– Communication entities● How they communicate?

– Communication paradigms● What roles and responsibilities they have?

● How are they mapped on the physical infrastructure?

22/5

8

Architectural models

23/5

8

Architectural modelsCommunication entities

● Processes

– DS = Processes + IPC

– Some systems don't have processes

– Most systems have threads ● the real communication endpoint

● Objects

– Migrations of OO to DS● OO Designs and OO programming

– Natural decomposition unit for a problem

– Accessed by and interface

24/5

8

Architectural modelsCommunication entities

● Components

– Provide interface like objects

– Specify assumption● Dependencies are explicit and used to pair components● Contracts

● Web services

– Implementation of Objects and Components● On the WEB

– Identified by a URL

– Defined/described/discovered by XML

25/5

8

Architectural modelsCommunication paradigms● Remote invocation

– Request-reply protocols● Low level● Programmer creates/sends messages● Example: HTTP

26/5

8


– Remote procedure calls● Attributed to Birrel and Nelson (84)● RPC system hides

– Distribution– Encoding/decoding messages– Passing of message– Semantic of the procedure call

● Supports client/server– Server offer set of operations (by interfaces)– Clients call those operations directly as if local

● Access and location transparency – (minimal)

27/5

8


– Remote method invocation● Resembles RPC

– But in a world of objects● Client objects invoke methods on remote objects● Underling details are hidden ● May support

– Object identity– Pass objects as parameter

● Tight integration to OO languages

28/5

8


– Two-way relationship (sender ↔ receiver)● Receiver identity is know● Both parties exist simultaneously at the same time

– Direct communication

● Indirect communication

– Space uncoupling● Sender does not know who is sending to

– Time decoupling● Senders and receiver do not need to exist at the same time

29/5

8

Architectural modelsCommunication paradigms● Indirect communication

– Group communication● Delivery of messages to groups of recipients● One-to-many communication● Communication relies on groups abstraction

– Recipients join groups

– Publish-subscribe● Information dissemination/ distributed events● Producers(publishers) distribute

– Information items of interest (events)● Consumers register the interest or events to receive

30/5

8


– Message Queues● Point-to-point communication channel● Producer places message on Queue● Consumer retrieves message● Consumers are notified of message availability

– Tuples space● Communication of performed by the access to shared

structured data (tuples)● Add tuples to the persistent tuple space● Consumers can read or deleted existing tuples● Can be client server or P2P

31/5

8


– Distributed Shared Memory● DSM systems provide a view of a shared memory space

– Composed of data on multiple remote nodes● Programmers are presented with the abstraction of

reading/writing local memory– All accesses are to local address space– Although data can be on a remote node

● Infrastructure guarantees– Copies of data are provided in a timely manner– Synchronization and consistency of data

32/5

8

Architectural modelsRoles and responsibilities● Client-Server

– Client processes interact with individual servers● (pottenctially) In separate hosts● To access shared resources

– Servers can also be clients

33/5

8

Architectural modelsRoles and responsibilities● Peer-to-peer

– All processes have similar roles● Interacting cooperatively as peers● No distinctions between client or server

– Resources owned by users● Can be put to use to support the service● Resources increase with the number of

users

– Data objects are shared and distributed

● Distribution and replication increases complexity

34/5

8

Architectural modelsPlacement

● Where to place entities on the physical model?

– Distribute service among several servers

● Data may be partitioned● Data may be replicated

– Caching● Store of recently used data

– Locally to the client– On a separate server

● Objects are retrieved from cache

– If available

35/5

8

● Mobile code

– Code is downloaded from the server● Executed on the client● No network delays

Architectural modelsPlacement

● Mobile agents

– Code (and data) roams on computers● Executes on behalf of other● Invokes local services● Lower execution time

– Code transfer + local invocation vs remote invocation

36/5

8

Architectural modelsArchitectural patterns

● Layering

– Related to abstraction

– Each layer offers an abstraction

– Higher layers not aware of “lower” implementations

Applications, services

Computer and network hardware

Platform

Operating system

Middleware

37/5

8

Architectural modelsArchitectural patterns● Tiered

– Related to composition

– Complements layerings● Layering: vertical organization of services into layers● Tiering: Distribution of a given layer into appropriate servers

– Presentation logic

– Application logic

– Data logic

38/5

8

Architectural modelsArchitectural patterns● 2-Tiered`

39/5

8

Architectural modelsArchitectural patterns● 3-Tiered

40/5

8

Architectural modelsArchitectural patterns● Thin-Client

– Moves complexity away from end-user● Client has no logic only presentation

ThinClient

ApplicationProcess

Network computer or PCCompute server

network

41/5

8

Architectural modelsArchitectural patterns● Proxy

– Offers the same interface as the server

– Located on the local client

– Is contacted and redirect calls to remote note● Offers location transparency

– Can encapsulate other functionalities● Placement policies of replication● Caching

42/5

8

Architectural modelsArchitectural patterns● Brokerage

– Supporting interoperability

43/5

8

Fundamental models

● Describe the general and fundamental characteristics of a DS

– Not how it is implemented

● Define the assumptions about the system

● Allows the generalization about (imp)possibilities

– General purpose algorithms

– Desirable properties that are guaranteed

● Interaction

● Failure

● Security

44/5

8

Fundamental modelsInteraction

● Assumptions about the communication channels

– Latency: delay between start of message transmission and receiving

● Time taken on transmission● Delay assessing network● Time of message processing (on the OS)

– Bandwidth: Amount of information that can be transmitted on a give time

– Jitter: variation in time take to deliver a series of messages

45/5

8


● Assumptions about computer clocks

– Each computer has local clock● Used to obtain current time

– Simultaneous clock read render different values● Clocks on computers drift at different rates

–

46/5

8


● Synchronous Distributed Systems

– Time to execute each step● Has lower bound● Has higher bound

– Messages● Are received within a known bounded time

– Process clocks● Drift rate has known bound

– Can be built if● It is possible to guarante previous bounds

47/5

8


● Asynchronous Distributed Systems

– There are no bounds for ● Process execution speed● Message transmission delays● Clock drift rates

– Internet● Good example● No limits to server or network load

– Email● May take days to arrive● Servers can have drifted clock

48/5

8

Fundamental modelsFailure

● In a DS processes and communication can fail

● Failure model defines how failures can occur

– In order to provide understanding of their effects

● Omission failures

– Process omission failures: ● process does not execute the task (crashes)● Can be detected using timeouts

– Communication omission failures● A sent message is not delivered to the receptor

– Both benign

49/5

8


● Arbitrary (Bynzatine) failures

– Any error can occur

– A process set wrong values in data items

– A process answers a wrong values

– A process arbitraly fails● No way to distinguish Process fail from no answer :(

– A message gets corrupted

– A bogus messages is created

– A messages is intercepted from delivery

– A messages is delivered twice

50/5

8


Class of failure Affects Description

Fail-stop Process Process halts and remains halted. Other processes may detect this state.

Crash Process Process halts and remains halted. Other processes may not be able to detect this state.

Omission Channel A message inserted in an outgoing message buffer never arrives at the other end’s incoming message buffer.

Send-omission Process A process completes a send, but the message is not put in its outgoing message buffer.

Receive-omission

Process A message is put in a process’s incoming message buffer, but that process does not receive it.

Arbitrary (Byzantine)

Process or Channel

Process/channel exhibits arbitrary behavior: it may send/transmit arbitrary messages at arbitrary times, commit omissions; a process may stop or take an incorrect step.

51/5

8


● Timing failures

– Applicable to synchronous systems● With limits to execution, delivery times and clock drifts

Class of failure Affects Description

Clock Process Process’s local clock exceeds the bounds on its

Performance Process Process exceeds the bounds on the interval between two steps.

Performance Channel A message’s transmission takes longer than the stated bound.

52/5

8

Fundamental modelsMasking failures

● A reliable system can be composed of

– Unreliable components that exhibit failures

● Knowledge of each component failures

– Allows a service to mask them

● Hiding a failure

– e.g. retrying

● Converting to a more acceptable failure

– Recovering an old version of the file

53/5

8

Fundamental modelsReliability on one-to-one communication

● Basic communication channels

– can exhibits failures (e.g. omission)

– But can be used to build a service that masks some failures

● Provides reliable communication

● Reliable communication

– Validity: any message is eventually delivered

– Integrity: the received message is identical to the sent one

54/5

8

Network Platform

● Networking issues

– Performance

– Scalability

– Reliability

– Security

– Mobility

– QoS

● Types of networks

– Personal Area

– (wireless) Local Area

– (wireless) Wide Area

– (wireless) Metropolitan Area

● Handled by the platform

– OS + HW

– Low level protocols

55/5

8

Middleware

● SW layer that

– Provides a programming abstraction

– Masks underlying heterogeneity● Network, HW, OS, programming languages

– Provides a uniform computational model● To be used by programmers of distributed applications● RMI, remote event notification, distributed transactions, ...

56/5

8

Middleware

57/5

8

MiddlewareLimitations

● Some application rely only on middleware

– If suitable for client-serves can use RPC● Name/Address database

● Not all issues can be handled by middleware

– Some dependability aspects

● Large file transfer over unreliable link

– TCP offers some error detection and correction

– TCP does not recover from major network interruption

– If service offers a new level of fault tolerance● Must maintain a progress level ● Must resumes transmission with a new TCP connection

58/5

8

MiddlewareLimitations

● End-to-end argument

– Saltzer et al (84)

● Some communication functions can only be completely and reliably implemented

– With knowledge and help of the application standing at the end points of the communication system

● In the previous case:

– TCP does now how to restart a file transmission

– Client must know where to restart

– Server must receive information about restart

02 - distributed systems - técnico lisboa - autenticação · 02 - distributed systems ......

Documents