October 2005Distributed systems: Introduction1 Distributed Systems: Introduction.

October 2005 Distributed systems: Introduction 1

Distributed Systems:

Introduction


Overview of chapters

• Introduction – Ch 1: Characterization of distributed systems

– Ch 2: System models

• Coordination models and languages

• General services

• Distributed algorithms

• Shared data

• Building distributed services


Introduction: Overview

• Definitions

• Examples• Resource sharing and the Web

• Types of concurrency

• Challenges

• Architectural models

• Fundamental Models

• Summary


Definitions

Distributed system =– Hardware or software components,

– Network

– Communication, coordination by message passing.

• Consequences:– Concurrency

– No global clock

– Independent failures

• Motivation– Resource sharing


Definitions (cont.)

Distributed algorithm =

– collection of cooperating algorithms

– using message passing

– examples:

• mutual exclusion: to prevent different processes to

use the same resource simultaneously


Overview

• Definitions• Examples • Resource sharing and the Web• Types of concurrency• Challenges• Architectural models• Fundamental Models • Summary


Examples

• Examples of distributed systems:

– Internet & intranets

– Distributed UNIX

– Mobile & ubiquitous computing

– Commercial applications

• History


Example 1: Internet

intranet

ISP

desktop computer:

backbone

satellite link

server:

network link:


Example 1: Internet (cont.)

= A vast interconnected collection of computer networks

– collection of intranets connected by backbones

• ISPs: connectivity + services

• Services: WWW, Email, file transfer


Example 1: Intranets

the rest of

email server

Web server

Desktopcomputers

File server

router/firewall

print and other servers

other servers

print

Local areanetwork

email server

the Internet

LANLAN

LAN


Example 1: Intranets (cont.)

= portion of internet– A collection of LAN’s connected through backbones– Connected to internet through routers+ Separate administration+ Local security policies

• Motivation– Internet applications: WWW, Email, file transfer– More resource sharing

• Sharing files, printers, databases, • Avoiding the installation of software through services over

the intranet (using “thin clients”)

• Firewall: filtering messages at router


Example 2: Distributed Unix

• Origin: Bell labs, 1975• Interprocess communication: BSD UNIX• Distributed operating system =

Operating system of

– a collection of autonomous computers

– linked by computer network

– equipped with distributed software

– to ….. create for the users a single integrated computing facility

A technical

achievement !


Example 2: Distributed Unix (cont)

• wide spread components (SUN license)– Remote Procedure Calling (RPC)– Network File System (NFS)– Network Information Service (NIS)


Example 2: Distributed Unix (cont)

• Applied research– remove limitations of original UNIX

– improve scaling

• Result .. – new generation of distributed systems

– Examples: Mach, Amoeba, Andrew (file system), Kerberos (security)

openmodular

extensible

*


Example 3: Mobile & ubiquitous computing

Laptop

Mobile

PrinterCamera

Internet

Host intranet Home intranetWAP

Wireless LAN

phone

gateway

Host site



• Miniaturization & wireless networking– Laptops– Handheld devices: Personal Data Assistent,

mobile phones, video/digital camera’s,…– Wearable computers: smart watches, smart

cards, …– Embedded devices: washing machines, cars,

hi-fi systems,…

=> Mobile computing:=> Ubiquitous computing


• Mobile computing: moving computing devices in and out intranets

– Transparent access to home intranet– Access to local resources at remote site Location-aware computing

• Ubiquitous computing– Small computing devices everywhere– Communication between devices



Challenges– Discovery of resources– Automated reconfiguration of host intranet

and mobile device when entering or leaving– Cope with limited connectivity– Privacy and security to

• Users

• Visited environment



Example 4: Commercial applications

• E-commerce– On-line retail, home banking

• Airline reservation systems• Telecommunication

– Audio and video: real-time traffic

• Healthcare– Global access to patient information

• Manufacturing– Resource planning and control

• …


Examples (cont)

• History– 1950s: programmers reserve computers– 1960s: batch processing on mainframes– 1970s: time sharing on mainframes and

minicomputers– 1980s: personal computers

• first: in isolation• later: integrated in networks distributed file systems

– 1990s: distributed systems• increased integration; • middleware

– 2000s: ??? ubiquitous computing


Overview

• Definitions


• Types of Concurrency

• Challenges



• Summary


Types of Concurrency

Interleaved computation (single processor)– Job = execution of one program– Concurrent job = cooperating subtasks/threads– interleaved execution– threads communicate via shared memory– a single clock

=> events can be ordered


Parallel computing (Multiprocessor)– job = execution of one program– job = cooperating subtasks/threads– real concurrency– threads communicate via shared memory– a single clock

events can be ordered

• E.g. SIMD: Single Instruction/Multiple Data



Distributed computing:– job = execution of many procedures– Job = many cooperating tasks– a single process can have subtasks/threads– real concurrency– processes communicate via message passing – multiple clocks

=> only partial order for events



Types of ConcurrencyParallel versus Distributed

• “parallel” hardware:

– identical processors,

– regular interconnection structure

• small granularity of tasks

• frequent communication between tasks

• homogeneity: tasks perform

similar functions

• Clock synchronised

• “distributed” hardware:

– different types of processors and

– networks

• large granularity of tasks• less frequent communication between

tasks

• inhomogeneity: tasks perform

different functions• synchronized execution of tasks


Comparison (cont.) Local concurrency versus Distributed

Fundamental realities: Co-located Distributed

Communication Fast Slow

Failures Full failure Independent failures Network can partition

Concurrent issues Only with multiple threads Inherited

Secure Yes No

*


Overview

• Definitions


• Types of Concurrency

• Challenges



• Summary


Challenges

• Heterogeneity

• Openness

• Security

• Scalability

• Failure handling

• Concurrency

• Transparency


• Heterogeneity at many levels– Networks (ethernet, token ring, .. )

– Computer hardware

– Operating systems (different API to internet)

– Programming languages

– Implementations by different developer (data structures)

• Solutions … middleware– Java RMI

– CORBA

– Implement uniform high level API

Challenges: Heterogeneity

Remote procedures

Remote method invocation

Remote event notification

Distributed transactions


Challenges: Openness• Open systems

– enables adding system extensions without disruption or

duplication of existing services

• How?– Uniform communication mechanism

• to enable distributed programming

– Published and standard interfaces• to access shared resources

• Result– open distributed systems– heterogeneous hardware possible


Challenges: Security

• Attacks against – Confidentiality/privacy– Integrity of messages– Authentication of user: simulating false

identity– Availability : unauthorized use of resources

• Accessing files, printers, …• Denial of service: blocking server by overwhelming

it with requests • Mobile code performing unauthorized operations


Challenges: Scalability

• major challenge!

– Control cost of physical resources ( cost < O(n), n number of users)

– Control performance loss ( loss < O(log n), n size of data)

– Prevent software resources running out (e.g. IP addresses)

– Avoid performance bottlenecks

• general techniques:– Replication & partitioning of data,

– Caching of data

– multiple servers

allow scaling up the system

while keeping the same software


Challenges: Scalability

• Computers vs. Web servers in the Internet

Date Computers Web servers Percentage

1993, July 1,776,000 130 0.008

1995, July 6,642,000 23,500 0.4

1997, July 19,540,000 1,203,096 6

1999, July 56,218,000 6,598,697 122001, July 125,888,197 31,299,592 25

42,298,3712003, July


Challenges: Failure handling

• Partial failures Difficult to handle

• Techniques used:– Detecting failures (e.g. checksums)

– Masking failures (e.g. message retransmission)

– Tolerating failures (e.g. browser announces server not available)

– Recovery from failures (e.g. save & restore state) – Redundancy: replicating services


Challenges: Concurrency

• The problem:– different clients simultaneous accessing a

shared resource

• Solutions – limit the number of users to 1

• (inefficient and restrictive)

– allow concurrent executions • non-trivial• Synchronization tools are needed

– Known techniques e.g. semaphores


Challenges: Transparency

• A system is transparent for a feature if the feature is unobservable for the user

• Examples: – rlogin : local versus remote computer

– Java RMI: local versus remote object• Message to local or remote object is the same

– GSM: location is transparent

• Increase of uniformity!


Challenges: Transparency

• Access: identical access to local and remote resources

• Location: access to resources without knowledge of their physical/network location

• Concurrency• Replication• Failure• Mobility: allows movement of resources

• Performance• Scaling


Overview

• Definitions• Examples• Resource sharing and the Web• Types of Concurrency• Challenges• Architectural models• Fundamental Models • Summary


Architectural Models

• A model of a system= certain aspect of a system

= abstract view on a system making abstraction

of all properties not related to the selected aspect


Architectural models

• Focus on organization and interaction of the distributed system:– Different component objects/processes– their way of communication

• Architecture has major impact on quality of system– Architecture determines to great deal whether

the system will meet present and expected future demands.



• Architecture: structure in terms of separately specified components

• Overall goal: structure will meet present and likely future demands

• Major concerns: make system– Reliable– Manageable– Adaptable– Cost-effective



• Architectural model– Simplifies & abstracts functions of components– Placement of components– Interrelationships between components

• Overview– Software layers– System architectures– Design requirements


Architectural models:Software layers

Applications, services

Computer and network hardware

Platform

Operating system

Middleware



• Platform– Various implementations– Provides communication & cooperation

between processes

• Middleware



• Middleware– Purpose

• Mask heterogeneity

• Provide convenient programming model

– Raises level of communication activities• Remote method invocation: RMI, CORBA, DCOM

• Group communication

• Notification of events

• Partitioning, replication of shared data

– Provides infrastructural services• Naming, transactions, persistent storage



• Middleware: limitations

end-to-end argument

– Some aspects require support at application level


Architectural models:System architectures

• Overview– Client-server: different roles

• n-Tier Architectures

• Multiple servers

• Proxy servers and caches

• Mobile code

– Peer-to-peer: cooperation as peers



• Client-server model– defines roles for 2 interacting entities– client:

• needs a particular service• sends request to server• gets (after some time) reply

– server:• awaits requests from clients• performs requested function

– server can be client of another server



• Client-server model

Server

Client

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:



• One-tier application architecture:

Presentation

Processing

Data

mainframe

Terminals, or

PC + terminal emulation

Net

wor

k



• Two-Tier Architecture– 2 entities used in the distributed application:

• at the user desktop:

user interface + %(application)

• at the database server:

%(application) + database

– thin <> fat client

• thin: no application code at desktop, only GUI

• fat: all application code at desktop



• Two-Tier Architecture: thin client

Presentation

Processing

Data

mainframe

Net

wor

kPC



• Two-Tier Architecture: fat client

Presentation

Processing

Data

mainframe

Net

wor

kPC



• Two-Tier Architecture: issues– update of code at clients: hard (many different

systems) thin clients

– application code executed at mainframe: performance bottleneck

fat clients



• Multi-Tier Architecture– 3 entities used in the distributed application:

• at the user desktop:

user interface

• at the application server

application logic

• at the database server:

data



• Multi-Tier Architecture:

Data

mainframe

Net

wor

k Presentation

Processing

PC

Application server



• Multi-Tier Architecture: issues– opportunities for

• better performance

• more flexibility

– interactions between 3 parties• more cooperation overhead

• need for transactions?



• Services provided by multiple servers

Server

Server

Server

Service

Client

Client



• Services provided by multiple servers– Partition objects

• Examples: DNS, WWW

– Replicated copies of objects• Examples: Sun NIS

• Increases performance & availability

• Improves fault tolerance



• Proxy servers and caches

Client

Proxy

Web

server

Web

server

serverClient

+ Reduce load on network & web servers

- Consistency!



• Mobile code– Good interactive response– Potential security threat

a) client request results in the downloading of applet code

Web server

ClientWeb serverApplet

Applet code

Client

b) client interacts with the applet



• Mobile agents= Running program (code + data)+ Travels from computer to computer→ Local access to data→ Potential security threat



• Client-server model + variations– Simple approach to sharing

– Centralization of service provision & management

→ Poor scaling

• Observations– Functionality

today’s desktop >> yesterday’s servers

– Always-on broadband connections

→ Peer-to-peer



• Peer processes

Application

Application

Application

Peer 1

Peer 2

Peer 3

Peers 5 .... N

Sharableobjects

Application

Peer 4



• Peer-to-peer– Exploit resources in a large number of participating

computers

– Shared objects distributed over participants

– Replication to distribute load & to provide resilience

→ More complex architecture

– Examples: • Antecedents: DNS, Netnews/Usenet, Grapevine name

registration

• Napster, Ivy file system


Architectural models: Design requirements

• Minimal requirement: – maintain functionality of a non-distributed system

• added value:– extended resource access– extended application interface for explicit sharing, fault tolerance,

etc.– advanced end user applications: CSCW (computer supported

cooperative work)

• QoS …– Reliability– Security– Performance– Adaptability


User RequirementsQuality of service

• Reliability and availability– reliability = measure of the likelihood of the

system to deviate from the designed behaviour– increased by enabling failure detection and

recovery– highly reliable services often worse

response– fault tolerant system: detects failures and either

• fails gracefully (predictably)• masks the fault



• Security: new problems– privacy and integrity of users data in network

packets• by tampering the network cable

• by connecting a machine to read and/or inject data packets

– openness to interface with system software• not all machines are physically secure

• e.g. a bogus file server could be created



• Performance– Responsiveness– Throughput

• Processing speed at clients & servers + data transfer rate

– Balancing computational load


Overview

• Definitions• Examples• Resource sharing and the Web• Comparison: distributed versus ...• Challenges• Architectural models• Fundamental Models • Summary


Fundamental models

• System model gives answers to– What are the main entities in the system?– How do they interact?– What are characteristics that affect individual

& collective behavior?

• Purpose of model:– Make explicit all relevant assumptions– Make generalizations concerning what is

possible or impossible


Fundamental models

• Aspects captured in our models:– Interaction: time aspects– Failure– Security


Fundamental models:Interaction model

• Time is important– E.g. multimedia application requires timeliness– E.g. Event ordering problem in email Inbox

Item From Subject

23 Z Re:Meeting

24 X Meeting

25 Y Re:Meeting



• How to avoid the email ordering problem? – No problem if clock synchronization

– Clock synchronization is sometimes impossible



• No global notion of time

• Synchronisation of time impossible due to: – Performance variations:

• Latency (time between start of sending and end of receiving)

• Bandwidth

• Processing time for messages

– Computers have different clock drift rates

Synchronous model

Asynchronous model



• Synchronous distributed systems– Upper & lower bounds for

• Time to execute processing step

• Message transmission

• Clock drift rate

– Allow• Use of timeouts to detect process failure

• Guarantee of timeliness (multimedia)

• Partial clock synchronisation



• Asynchronous distributed systems– No time bounds – Many systems are asynchronous

• E.g. Internet• Due to sharing of processors & communication

channels • Often offer the best performance (because no

resources are wasted)

– Consequences:• Clock synchronization impossible• No guarantee of timeliness possible



• Solution to ordering problem– With (perfect) clock synchronization

no problem

– In asynchronous model• Facts:

– Ordering possible within a single process– Send m before receive m

Event ordering possible• Implementation: logical clocks



• Event orderingsend

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


Fundamental models

• Aspects captured in models:– Interaction– Failure– Security


Fundamental models:Failure model

• How can distributed systems fail?– Partial failures– of • processes

• communication channels

• Taxonomy– Process <> communication channels– Kind of failure: • Omission

• Arbitrary

• Timing



• Omission failure= Failure to perform an action– Processes:

• Subclasses:– Crash no further execution

– Fail-stop crash + detection possible

• Consequences for asynchronous systems– Failure not detectable

– Reaching agreement impossible

– Communication:



• Omission failure– Communication:

• Send-omission

• Receive-omission

• Channel-omissionprocess p process q

Communication channel

send

Outgoing message buffer Incoming message buffer

receivem



• Arbitrary or Byzantine failures:= Worst possible failure semantics

• Any behavior possible

– Processes:• Omit processing steps

• Perform unintended steps

– Communication• Message contents corrupted

• Non-existing message delivered

• Messages delivered twice

• Rare: checksums, sequence numbers



Class of failure Affects DescriptionFail-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-omissionProcess A message is put in a process’s incoming message

buffer, 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.



• Timing failures– Applicable in synchronous systems

Class of Failure Affects Description

Clock Process Process’s local clock exceeds the bounds on itsrate of drift from real time.

Performance Process Process exceeds the bounds on the intervalbetween two steps.

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



• Masking failures– Approach:

• Hide

• Convert to a more acceptable failure

– Examples:• Checksums: corrupted message omission failure

• Retransmission of message: hide omission failure


Fundamental models

• Aspects captured in models:– Interaction– Failure– Security


Fundamental models:Security model

• Avoid unauthorized use of resources

• Secure processes and interactions

Communication channel

Copy of m

Process p Process qm

The enemym’



• Based on architectural model with – Clients– Servers: manage objects

Network

invocation

resultClient

Server

Principal (user) Principal (server)

ObjectAccess rights


Protecting objects• Protecting objects/resources by

– giving access rights to users– associating with each invocation an authority (a user

with access rights) who allows for the use of the object or asked for it

e.g. user asks a remote process to print something on his printer the authority here is the user

• authority = PRINCIPAL • principal is user or process• server checks identity of authority and checks its

access rights• Works only if communication is secure



• Securing processes and interactions– Threats to processes

• False identification of sender of message

– Threats to communication channels• Copy, alter, inject messages

– Denial of service• Overload resource (channel, processor)



• Defeating security threats– Cryptography– Shared secretsAuthenticationSecure channels

Principal A

Secure channelProcess p Process q

Principal B



• Uses of model– Security straightforward? NO

• Processing cost

• Management cost

• Inconvenience for users

– Approach:• Analysis of all threats

• Acceptable cost


Overview

• Definitions• Examples• Comparison: distributed versus ...• Resource sharing and the Web• Challenges• Architectural models• Fundamental Models • Summary


Summary• Distributed systems:

– Computers– Processes– Messages– No common clock– Partial failures


Summary

• Challenges– Heterogeneity– Openness– Security– Scalability– Failure handling – Concurrency– Transparency


Summary• Architectural models:

– Variations on client-server+ Large scale resource sharing+ Management of concurrent updates+ QOS

• Reliability

• Security

• Performance

• adaptability


Summary• Fundamental models:

– Interaction– Failure– security


Distributed Systems:

Introduction

October 2005Distributed systems: Introduction1 Distributed Systems: Introduction.

Documents

Transcript of October 2005Distributed systems: Introduction1 Distributed Systems: Introduction.