introds slides

8/13/2019 IntroDS Slides

1/17

Frank Eliassen, Ifi/UiO 1

Introduction toDistributed Systems (DS)

INF5040 autumn 2006

lecturer: Frank Eliassen


What is a distributedsystem?

Definition [Coulouris & Emmerich] A distributed system consists of hardware andsoftware components located in a network ofcomputers that communicate and coordinate theiractions only by passing messages.

Definition [Lamport] A distributed system is a system that prevents youfrom doing any work when a computer you havenever heard about, fails.


2/17


Types of distributed systemDistributed Computing Systems

Used for high performance computing tasksCluster computing systemsGrid computing systems

Distributed Information SystemsSystems mainly for management and integration ofbusiness functionsTransaction processing systemsEnterprise Application Integration

Distributed Pervasive SystemsMobile and embedded systemsHome systemsSensor networks


A distributed system organized asmiddleware

Layer of software offering a single-system viewOffers portability and interoperabilitySimplifies development of distributed applicationsand services

Distributedapplicationsand services

DISTRIBUTION MIDDEWAREPlatform Independent API

Platform Dependent API

. . .Local OS

1Local OS

2Local OS

n

- transaction oriented (ODTP XA)- message oriented(IBM MQSeries)- remote procedure call (X/Open DCE)- object-based (CORBA, COM, Java)


3/17


Implications of distributed systemsIndpendent failure of components partial failure & incomplete information

Unreliable communication Loss of connection and messages. Message bit errors

Unsecure communication Possibility of unauthorised recording and modification of messages

Expensive communication Communication between computers usually has less bandwidth, longer

latency, and costs more, than between independent processes on thesame computer

Concurrency components execute in concurrent processes that read and update

shared resources. Requires coordinationNo global clock makes coordination difficult


Requirements leading todistributed systems

resource sharing the possibility of using available resources any where

openness an open system can be extended and improved incrementally

scalability serve more users, provide shorter response times

fault tolerance

maintain availability even when individual components failheterogeneity network and hardware, operating system, programming

languages, implementations by different developers


4/17


Resource sharing

The opportunity to use available hardware,software or data any where in the systemResource managers control access, offer ascheme for naming, and controls concurrency

A resource manager is a software module thatmanages a resource of a particular type

A resource sharing model describes howresources are made availableresources can be usedservice provider and user interact with each other


Models for resource sharing

Client-server resource modelServer processes act as resource managers, and offer services(collection of procedures)Client processes send requests to servers

Object-based resource model Any entity in a process is modeled as an object with a messagebased interface that provides access to its operations

Any shared resource is modeled as an object


5/17


Openness

An open DS can be extended and improved incrementallyRequires a uniform IPC mechanism and publication ofcomponent interfaces (e.g., subject to standardisation)

IETF RFC: Protocol specifications (www.ietf.org)OMG: interface specifications etc. (www.omg.org)

New components can be integrated with existingcomponents


Concurrency

Components in DS execute in concurrentprocessesComponents access and update shared resources(e.g., variables, data bases, device drivers)Integrity of the system may be violated ifconcurrent updates are not coordinated

Preservation of integrity requires concurrencycontrol where concurrent access to the sameresource is synchronized


6/17


Scalability

A system is scalable if it remains effective when there isa significant increase in the amount of resources andnumber of users

Internet: no of users and services has grown enormously

Scalability denotes the ability of a system to handle anincreasing future loadRequirements of scalability often leads to a distributedsystem architecture (several computers)


Scalability : challengesControlling the costs of physical resources

A system with n users is resource-scalable if the amount ofresources required to support them is at most O( n )

Controlling the performance loss (when the amount ofdata increases)

A system is performance scalable if the time it takes to accesshierarchically ordered data is at most O(log n ) where n is theamount of data

Preventing software resources running out:

Dimension data structures o.a. such that the system can meetfuture requirements (difficult cf. IP addresses) Avoiding performance bottlenecks

require decentralized algorithms (partitioning, caching andreplication)


7/17


Failure handling

Hardware, software and network fail!!DS must maintain availability even in cases wherehardware/software/network have low reliabilityFailures in distributed systems are partial

makes error handling particularly difficultMany techniques for handling failures

Detecting failures (checksum o.a)Masking failures (retransmission in protocols, replication )Tolerating failures (as in web-browsers)

Recovery from failuresRedundancy (replicate servers in failure-independent ways)


Heterogeneity

Variations and differences that must be handlednetwork The Internett-protocol is implemented over many different networks

Hardware difference in representation of data types on different processorsoperating system API to the same protocol and services varies

programmng languages different representation of character set and data structurs

implementation by different developers ensure that different programs can communicate

requires agreement on a number of things (cf. standards)


8/17


Transparency

Transparency hides the consequences ofdistributionTransparency has different dimensionsThese represents different properties adistributed system might have (metric to assessthe design of a system)


Access transparency

Enables local and remote resources/componentsto be accessed using identical operationsExample: File system operations in NFSExample : Navigation in wwwExample : SQL-queries in distributed data bases

Components that do not have transparentaccess can not easily be moved to anothercomputer


9/17


Location transparency

Enables local and remote resources/components to beaccessed without knowledge of their locationExample: File system operations in NFSExample : Web pages (URLs) in wwwExample : Tables in distributed databases


Other transparencydimensions (Coulouris)

Concurrency transparencyReplication transparencyFailure transparencyMobility transparency

Performance transparencyScaling transparency


10/17


Distribution transparencies

Access

transparency

Access

transparency

Location

transparency

Location

transparency

Mobilitytransparency

Mobilitytransparency

Replicationtransparency

Replicationtransparency

Concurrencytransparency

Concurrencytransparency

Scalingtransparency

Scalingtransparency

Performancetransparency

Performancetransparency

Failuretransparency

Failuretransparency


Summary

Distributed systems:harware and software-components located in a network of computersthat communicates and coordinates their actions exclusively by sendingmessages

Consequences of distributed systemsIndependent failure of componentsUnsecure communicationNo global clock

Requirements like resource sharing, openness, scalability, faulttolerance and heterogeneity can be satisfied by distributed systemsDistributed systems organized as middleware

Harvest potential advantages of distributed systems withouthaving to pay for all their challenges and problems(transparency)


11/17


Design of distributedobjects

INF5040 autumn 2006

lecturer: Frank Elassen



Many has experience with design of localobjects that are all located in theexecution environment of a OOprogramming languageDesign of distributed objects is different!


12/17




Local vs distributed objects

References Activation/deactivationMigration/mobilityPersistenceLatency for method calls

ConcurrencyCommunicationSecurityMany pit falls!!


13/17


Object references

References to objects in OOPS are usuallypointers to memory cellsReferences to distributed objects are morecomplex

location informationsecurity informationreferences to object type

References to distributed objects are larger(e.g., 350 byte i Orbix)


Activation/deactivation

Objects in OOPS reside in main memory duringtheir whole life timeThis does not always suit distributed objects

no of objectsobjects can be used over a long period of timesome servers must be shut down from time to timewithout stopping the applications

Distributed object implementations areread into main memory (activation)removed from main memory (deactivation)


14/17


Activation/deactivation

Issues:repository for implementationsassociation between objects and processesexplicit vs implicit activationwhen to deactivate objects?how to handle concurrent calls

Who decides?Designer?Programmer?

Administrator?


PersistenceStateless vs stateful objectsStateful objects must store its state in a persisentrepository between

object-deactivation andobject-activation

Can be achieved bymaking an external representation for file systemmap to relational databaseobject database

Decided at object design time


15/17


Object life cycle

Objects in OOPS exist in a single virtual machineDistributed objects can be created on differentcomputersDistributed objects can be copied or moved fromone computer to an otherRemoval of objects by garbage collection isdifficult in a distributed environment

Java RMI: reference counting Jini: leases

Life cycle must be considered at design time ofdistributed objects


Latency of method callsTo execute a local method call requires a fewhundred nanoseconds

A remote method call requires between 0.1 og 10milliseconds, or more interfaces of distributed objects must beconstructed such that

methods perform larger processing taskshighly frequent method calls are not required


16/17


Parallelism

Execution of objects in OOPSsequentialconcurrent with multiple threads

Distributed objects execute in parallelCan be used to accelerate computations


CommunicationMethod calls in OOPS are synchronous

Alternatives for distributed objects:synchronous requestsoneway requestsdeferred synchronous requestsasynchronous requests

Who decides for each call?designer of service?designer of client?

How to document?


17/17


Security

Security in OO applications can be handled atsession levelObjects in OOPS do not have to be written in aparticular wayFor distributed objects

Who issues the method call?How do we know that the client is the one he claims tobe?How can we decide whether to grant the client the right touse the service?

How can we prove that we have delivered the service toenable later billing for the use of the service?


Summary

Design of distributed objects is different from design ofprograms where all object are located in the sameprocessMany pit falls!!

introds slides

Documents