Dr. Christian - PowerPoint Presentation

Slide1

Dr. Christian VecchiolaPostdoctoral Research Fellowcsve@unimelb.edu.auCloud Computing and Distributed Systems (CLOUDS) Lab Dept. of Computer Science and Software EngineeringThe University of Melbourne

Distributed System Models

Most concepts are

drawn from Chapter 2© Pearson Education

Most concepts are

drawn from Chapter

1

© Pearson EducationSlide2

OutlineIntroductionArchitectural ModelsCharacterizationSoftware LayersSystem Architectures Design Challenges/RequirementsFundamental Models

InteractionFailureSecurity

SummarySlide3

IntroductionSlide4

IntroductionOverviewDistributed system models helps in…..classifying and understanding different implementations..identifying their weaknesses and their strengths..crafting new systems outs of pre-validated building blocks

We will study distributed system models from different perspectivesStructure, organization, and placement of componentsInteractions

Fundamental properties of systemsSlide5

Architectural ModelsSlide6

Architectural ModelsCharacterizationThe structure and the organization of systems and the relationship among their components should be designed with the following goals in mind:To cover the widest possible range of circumstances.To face the possible difficulties and threats.To meet the current and possibly the future demands.Architectural models provide both:a pragmatic starting pointa conceptual view to address these challenges.

In terms of implementation models and basic blocks

In terms of logical view of the system, interaction flow, and componentsSlide7

Architectural ModelsCharacterizationChallenges (more…)Widely varying models of useHigh variation of workload, partial disconnection of components, or poor connection.Wide range of system environmentsHeterogeneous hardware, operating systems, network, and performance.Internal problemsNon synchronized clocks, conflicting updates, various hardware and software failures.External threatsAttacks on data integrity, secrecy, and denial of service.Slide8

Architectural ModelsCharacterizationObservationsWidely varying models of useThe structure and the organization of systems allow for distribution of workloads, redundant services, and high availability.Wide range of system environmentsA flexible and modular structure allows for implementing different solutions for different hardware, OS, and networks.Internal problemsThe relationship between components and the patterns of interaction can resolve concurrency issues, while structure and organization of component can support failover mechanisms.External threats

Security has to be built into the infrastructure and it is fundamental for shaping the relationship between components.Slide9

Architectural ModelsCharacterizationWhat is an architectural model?

An architectural model of a distributed system is concerned with the

placement

of its parts and the relationship between them.It defines the way in which the

components of systems

interact with one another

and the way in which they are

mapped onto an underlying network of computers

.Slide10

Architectural ModelsCharacterizationA Distributed System is ultimately composed by processes communicating over a network.A first (rough) classification can be done by discriminating the process types:Server processesClient processesPeer processes(Possible variations and compositions)Such classification leads to a first categorization of architectural models.

Client-Server Systems

Peer-to-Peer SystemsSlide11

Architectural ModelsCharacterizationSome Examples:Client Server ModelPlacement: two distinct roles (1 server, multiple clients)Relationship: the server provide services, the clients consume themCommunication: asymmetricPeer-to-Peer ModelPlacement: one single role, the peer

Relationship: all the peer have the same responsibilitiesCommunication: symmetric

client

server

peer

peerSlide12

Architectural ModelCharacterizationOther modelsMobile Code based SystemsCode is dynamically moved among hostsWeb applets (Java, Flash)Mobile agentsSecurity is a concernAd-hoc Systems (based on proximity networks)High dynamism and volatility of system componentsMore heterogeneity in the devices connected to the system

Limited capabilities (often)Slide13

Architectural ModelsSoftware LayersDespite the specific model used for describing/implementing a system a reference software architecture can be defined. A software architecture....identifies the organization of a software system (single or multi-computer)..can be expressed in terms of cooperating layers (very general, applicable to all the systems)modules (for component-based systems)services (more appropriate for DS and SOA)Slide14

Architectural ModelsSoftware LayersWhy layers?Breaking up complexityDecomposition of functionsresponsibilitiesDifferent levels of abstractionWell proven modelTCP/IP StackISO/OSI Architecture

Layer N

Layer 1

Layer 0Slide15

Architectural ModelsSoftware LayersLayers in Distributed Systems

Application & Services

Middleware

Operating System

Computer and Network Hardware

Platform

- Comprises mostly hardware and OS

Provides basic services to upper

level:

- Process communication

- Process coordination and management

- Resource management

Examples:

-

Intel x86/Windows

- Intel x86/Solaris

- PowerPC/Mac OS X, Intel x86/MAC OS X

- Intel x86/Unix(Linux)….

Middleware

- Masks heterogeneity

Provides convenient programming model

Composed of distributed processes or objects

Communication support & resource sharing

- RPC / RMI

- Event notification

- Shared data placement/retrieval/replication

Examples

-

CORBA /

Microsoft DCOM

- Java RMI / .NET

Remoting

- Web Services

- ISO/ITU-T RM-ODPSlide16

Architectural ModelsSoftware LayersMiddlewareCommon stratus for developing application servicesInfrastructure component that ties together the different parts of the distributed systemModern examplesSun J2EEMicrosof .NETIBM WebSphere IBM BlueCloud

Manjrasoft Aneka Google AppEngine

Cloud Computing Platforms (

PaaS

)Slide17

Architectural ModelsSystem ArchitecturesMiddleware is the layer where most of the architectural model realizations take place.A layered architecture allows for a partition of responsibilities among the different layers of the system.At the middleware level a further distribution of responsibilities and functions between components takes place.Slide18

Architectural ModelsSystem ArchitecturesDifferent architectural models partition such responsibilities in different ways.This partitioning has an impact on:PerformanceReliabilitySecurityIn deciding how to make this partitioning several trade-offs apply.We will investigate the different advantages/disadvantages of the most common models.Slide19

Architectural ModelsSoftware ArchitecturesClient Server ModelMostly cited in the case of distributed systems.Most widely employed.Based on:Two roles: server and clientCommunication pattern: asymmetricrequest (client) – response (server)ExamplesHTTP, SMTP, DNS, NNTPSlide20

Architectural ModelsSoftware ArchitecturesClient Server Model

Time

Server

Client

t2

t3

t1

t4

t1: request time

t2: server process time

t3: response time

t4: roundtrip timeSlide21

System ArchitecturesClient-ServerTwo-tier model (classic)Three-tier (when the server, becomes a client)Multi-tier (cascade model)Architectural Models

client

server

client

Server/client

server

client

Server/client

server

Server/client

serverSlide22

Architectural ModelsSystem ArchitecturesPeer-to-Peer ModelAll the processes play a similar role.No distinction between server and client that are played by each component.Cooperative interaction.Avoids centralization and potential SPOFMore difficult to manageProvides a better scalable infrastructure (1000s hosts)ExamplesP2P File sharing (OpenNAP,

eMule, etc..)Distributed Hash tablesSlide23

Architectural ModelSystem ArchitecturesPeer-to-Peer model

peer

peer

peer

peer

peer

peer

peerSlide24

Architectural ModelsSystem ArchitectureVariations of the previous two modelsMultiple Server (kind of multi-tiers)Cache and Proxy architecturesMobile CodeMobile AgentsNetwork ComputersThin ClientsMobile devices and ad-hoc networkingSlide25

Architectural ModelsSystem ArchitecturesServices provided by multiple serversExtension of the Client-Server ModelA server response can be the result of a cascade request-response (multi-tier model)the collaboration of several processes which might bepartitioned in several nodesreplicated in several nodesExamples:Web page content as composition of…Database queries

Static content embeddingWeb Service callsSlide26

Architectural ModelsSystem ArchitecturesProxy Servers and CachesA cache is a store of recently used data object that is closer than the object themselves.Proxy servers uses caches to maintain a copy of the content that is frequently accessed, in order toincrease availability of contentincrease the performance of requests servingreduce the traffic load on a wider scalemake accessible content, not accessible otherwise (e.g. firewalls) Slide27

Architectural ModelsSystem ArchitecturesProxy Servers and CachesExamplesWeb Browser cacheThe web browser maintains copies of the recently visited pages on a local storeThis version of the pages is returned to the use r when he or she looks for the same pageSpecific HTML tags can control the validity of the cached web pagesWeb Proxy ServerThe caching mechanism is similar..Slide28

Architectural ModelsSystem ArchitecturesProxy Servers and CachesCaching in action!

1st Request

2nd RequestSlide29

Architectural ModelsSystem ArchitecturesMobile CodeMobile code generally refers to an application, component, or a program that can migrate during its life cycle.To certain extent, it is also considered mobile code, a software component that is dynamically downloaded and integrated to an existing application.Example: Applet or Flash in a browser.Dynamic plug-ins.Slide30

System ArchitecturesMobile Code – Applet modelArchitectural Models

Server

Client

Browser process spaceSlide31

Architectural ModelsSystem ArchitecturesMobile AgentsMobile Agents incarnate a better example of mobile code.They are programs that can migrate among different hosts, during their life cycle and carry their computation along the way.Main problem with mobility: reconstruction of stateTwo main models:Strong mobility  full state persistence (stack frame)Weak mobility

 partial state persistence (checkpointing)Slide32

Architectural ModelsSystem ArchitecturesMobile AgentsPossible uses of mobile agents:Information collectionComputation locality Mobile agents can move computation in situThis approach is useful when the data size is hugeDisadvantagesSecurity threats (host and guest)Compatibility of the hosting environmentSlide33

Architectural ModelsSystem ArchitecturesNetwork Computer and Thin ClientsNetwork computers provide terminals whit the minimum required software installed locallythat download operating systems and application software from a remote file serverIn this model:Applications are run locallyFiles (and data in general) are managed remotelyA minimal computational capacity (memory and CPU) is required.Slide34

Architectural ModelsSystem ArchitecturesNetwork Computer and Thin ClientsThin Client constitute a software layer that provide a GUI access to a remote machine where application are executed.Comparison with Network ComputersSame management costsNo download of OS and software locallyDisadvantage:Low performance for highly demanding graphical applications.Example:X-11, VNC, Remote Desktop..Slide35

Architectural ModelsSystem ArchitecturesMobile devices and spontaneous interoperationMobile devices involve mobile hardware and not mobile software.Mobile devices migrate among different computing environmentsadapt themselves/ integrate with existing environmentMain problemsVariable connectivityRelocation of servicesTransition between different networks

Discoverability of services

Mobnility

Trasparency

Context Awareness &

Spontaneous InteractionSlide36

Architectural ModelsInterfaces and ObjectsA distributed systems is a set of cooperating processes.Processes communicate among each othersAt low levelMessage passingRaw communication with socketsAt high levelBy using specific and well defined interfacesRemote Objects

This patterns provides a more flexible and dynamic partitioning of the responsibilities if compared to the static Client-Server model.Slide37

Design RequirementsSlide38

Design RequirementsDistributed Architectures ChallengesMain goal of DS: Sharing ResourcesHistory:1960 – First Timesharing systems60s – Multiuser operating systems (UNIX)70s – 80s First Distributed Systems (devices sharing)80s Clusters90s Grids…. CloudsStill today…

Sharing data & resources on a large scale is still a challenge!Slide39

Design RequirementsDistributed Architecture ChallengesIn particular the following aspects have to be considered:PerformanceQuality of ServiceData and Replica management (caching)DependabilitySlide40

Design RequirementsPerformance IssuesThey arise from the limited processing and communicating capacities of computers and networks.What to consider:ResponsivenessInteractive application need to be responsiveBottlenecks can be at each level of the communication stackThroughputThis is a common measure for DSHeterogeneity in a DS may affect throughputLoad-balancing

DS allow for concurrent execution without competitionLack of competition can be obtained by decentralizing processing

data & services replicationSlide41

Design RequirementsQuality of ServiceQoS concerns non-functional properties of the system.By non-functional we mean that:A QoS evaluation is not intended to verify whether a operates correctly from a logical point of view.A QoS evaluation provides insights on the behavior of the system from the point of view of parameters that characterize

how a service operating correctly performs its task.Example - File Server: a functional parameter might be the capability of retrieving a file

QoS parameters are: guaranteed bandwidth, reliabilitySlide42

Design RequirementsQuality of ServiceParameters of interest for Distributed SystemsReliability & Security:How much the system is robust?What are the security measures put in place (protocols, standards, encryption level)?PerformanceThroughput, load balancing, responsiveness.AdaptabilityHow much the system is able to meet the changing requirements?Slide43

Design RequirementsData Replication and CachingPerformance is the major issue in DS deploymentHow can we address performance loss?Data replication and load balancingWe can increase the throughputData cachingWe can reduce the service time

Data caching poses the problem of obsolete information and different strategies can be implied to avoid the use of content

not anymore valid.Slide44

Design RequirementsData Replication and CachingObsolete content detection and managementThe web caching protocol uses two strategiesCache validationExpiration time on cache contentHow they workEach content maintained in the cache has an expiry date.The expiry date of a cached item can be checked against the server, which will return a fresh copy in case of expiration.The browser or the proxy do not need to check every time:Server sends current time and expiry time for response

Browser (proxy) can estimate whether to request a fresh copy or not.Slide45

Design RequirementsDependabilityWhat is dependability? “The value showing the reliability of a person to others because of his/her integrity, truthfulness, and trustfulness, traits that can encourage someone to depend on him/her.”In systems engineering… “..the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers ..” [IFIP 10.4 Working Group on Dependable Computing]

“ dependability (is) the collective term used to describe the availability performance and its influencing factors : reliability performance, maintainability performance and maintenance support performance

” [Technical Committee 56 Dependability – IEC]Slide46

Design RequirementsDependabilityIn other words… How can we measure dependability?Attributes: Availability, Reliability, Safety, Integrity, Confidentiality, Maintainability.What tampers dependability?Threats: Faults, Errors, Failures.What can we do to ensure dependability?

Means: Prevention, Fault-tolerance, Forecasting.

How much we can trust, rely on a system?Slide47

Design RequirementsDependabilityIn particular…Fault tolerance:Dependable application in order to be reliable should keep operating in the presence of hardware, software, and network faults.In order to achieve reliability, redundancy (i.e. data & services replication, message retransmission) is applied.Security:Sensitive data must be placed only on hosts that can actively respond to attacks, and safely protect information.Slide48

Fundamental ModelsSlide49

Fundamental ModelsA different perspective…Architectural ModelsInternal organization, placement of components, and interaction patternsDesign RequirementsThoughts on performance and reliability characteristics of distributed systemsFundamental ModelsBased on the fundamental properties that can give insights oncharacteristics of the system

associated failure an security risks it might exhibitSlide50

Fundamental ModelsWhat is a model?It provides only essential elements to consider for reasoning and understanding the system behavior. Addresses the following questions:What are the main entities in the system?How do they interact?What are the characteristic that affect their individual and collective behavior?We use a model for…Making relevant assumptions about the system modeled.Making generalizations concerning what is possible or not possible. These generalization assume the form of algorithms or properties that are guaranteed (i.e. dependent on logical analysis or mathematical proof)Slide51

Fundamental ModelsAspect to consider for DSInteractionDS are constituted by interacting processes Interaction can be:Communication (message passing)Coordination (information flow)FailureFaults occurs usually in distributed environmentA classification of them helps understanding the weakness of the systems and the possible counter-actions.

SecurityModularity and openness expose the system to threatsIt is necessary to classify the attacks and devises potential resistance measures.Slide52

Fundamental ModelsInteraction ModelFacts:Communication takes place with delays (often of considerable duration)Delays and the absence of global time limit the accuracy with which we can coordinate processes.What are the element of interest?Performance Communication ChannelsComputer Clocks and Timing EventsSynchronous

vs Asynchronous modelsEvent OrderingSlide53

Fundamental ModelsInteraction ModelPerformance Communication ChannelsVarious implementationsIn general the following elements are important:LatencyTime taken for transmitting the first bit of a string of bytesDelay in accessing the network (varies according to load)Time taken by communication service and OS for processingBandwidthTotal amount of information transmissible in the unit of time

Jitter Variation in the time taken to deliver a messageSlide54

Fundamental ModelsInteraction ModelComputer Clocks and Timing EventsEach computer has its own internal clock.Two processes running on different computers will end up to have a different clock (and timestamps for events)Computer clocks drift from the perfect time at different rates.Without corrections such clocks will vary considerably over a long period of time.Possible solutions: GPS (ok for open spaces) Timing protocols (variable to message delays)Slide55

Fundamental ModelsInteraction ModelSynchronous vs Asynchronous ModelsSynchronous Systems (Assumptions)Process step execution time has known lower and upper bounds.Each message transmission over a channel has a bounded time.Local clock drift rate from real time has a known bound.Asynchronous Systems None of the previous assumptions are valid.Heterogeneity in all of the three aspects.

Observations:It is possible to suggest likely upper and lower bound.It is very difficult to provide accurate realistic values.

The use of synchronous system models is not realistic but might be helpful in designing initial versions of the system.Slide56

Fundamental ModelsInteraction ModelEvent OrderingSequence of events is importantThe execution of a system can be described in terms of the sequence of events that occur in itClocks cannot be synchronized perfectly across a distributed system.It is possible to order events in the absence of global clock?Slide57

Fundamental ModelsInteraction ModelEvent Ordering – The meeting problem

m1

X

t2

t3

t1

Y

Z

A

m2

m3

send

send

send

receive

receive

receive

receive

receive

receive

receive

receive

receive

Inbox of A:

…

23 Z Re: Meeting

24 X Meeting

25 Y Re: Meeting

….

Can A reconstruct the proper sequence?Slide58

Fundamental ModelsInteraction ModelEvent OrderingLogical Time (Lamport 1978) can help reconstruct the sequence ordering of events in absence of global clock.A number is assigned to each event.This number represents the logical order of the event in the sequence.Slide59

Fundamental ModelsFailure ModelWhat is failure? Process and communication may depart from what is the expected behavior.What is a failure model?Defines the ways in which failure may occur in order to provide understanding of the effects it can cause.ObservationsDifferent kinds of failures can be addressed differentlyDifferent kinds of failures denote different (major or minor) problemsClassification of failures is then important.Slide60

Fundamental ModelsFailure ModelTaxonomy of FailuresApplies to Processes and Communication[Hadzilacos and Tueg, 1994]Categorization:Omission FailuresArbitrary or Byzantine FailuresTiming FailuresSlide61

Fundamental ModelsFailure ModelOmission FailuresCharacterizationA process or a communication channel fails in performing what it is supposed to do.Possible Types:Process omission FailuresProcess crashes (fail-stop if can be detected, complete crash or abnormal residual behavior?)Communication channel Omission FailuresDropping messages

(channel omission)Send-omission failuresReceive-omission failuresSlide62

Fundamental ModelsFailure ModelArbitrary Failures or Byzantine FailuresCharacterizationWorst possible failure semantics.Any type of any error can occur.Types:Process arbitrary failuresInsertion of invalid data.Invalid execution paths.Channel arbitrary failuresMessage content corruptionUnintended messages delivered

Duplication

Easily detectable by the communication software.

Difficult to detect by simply checking whether the process responds to the invocation..Slide63

Fundamental ModelsFailure ModelTiming FailuresSynchronous SystemsAn operation executes beyond its time limits.Asynchronous SystemsDifficult to characterize, since there are no bounds on the time.Solutions:Real-time operating systemsWhere to:Multimedia computer with audio and video channels.Slide64

Fundamental ModelsFailover ModelMasking FailuresIt is possible to construct reliable services from components that exhibit failures.Failure detection is important to identify the wrong behavior and then provide a counter-measureData replicationChecksums and error correctionMessage retransmissionsA failure can be …… completely masked … turned into an acceptable failureSlide65

Fundamental ModelsSecurity ModelThe security of a distributed system can be achieved bySecuring the processes composing the system.Securing the channels they use to communicate.Protecting the objects they encapsulate by unauthorized access.Slide66

Fundamental ModelsSecurity ModelProtecting objectsAvoiding unauthorized accessIdentifyingwho is accessing whatwhat permission does he/she have on the objectEach service request operating on sensitive objects has to occur under a specific authorityConcept of Security PrincipalConcept of Access Rights.Slide67

Fundamental ModelsSecurity ModelProtecting objectsExample

Sensitive Object

Internet

<

Untrusted

Zone>

Security Service

User

Request +

Credentials

Server

Principal + Access RightsSlide68

Fundamental ModelsSecurity ModelSecuring Processes and their InteractionsProcess interact throughMessage passingPublicly available interfacesAssumptionsThe communication channel is untrustedPotential misuses of the services exposed by the process ObservationsHow can we protect processes from the enemy?What are the potential threats?Slide69

Fundamental ModelsSecurity ModelIdentifying the EnemyMalicious entity (user or program) capable of sending message through the network to any processreading or copying any message between a pair of processesimpersonating one end point of the communication

m1

m1’

m1Slide70

Architectural ModelsSecurity ModelClassification of ThreatsThreats to ProcessesImpersonation (generation, alteration of network packets)Threats to both servers (requests) and clients (responses)Threats to Communication ChannelsInjection, alteration of messagesMessage copyThreats for privacy and integrityCountermeasure: secure channelsDenial of Service: generation of false request

Mobile Code: untrusted, unknown, potentially harmfulSlide71

Fundamental ModelsSecurity ModelCountermeasuresCryptography and shared secretsProcesses shared a secret helping them communicating safelyThe shared secret can be used as key to encrypt messages over an unsecure channelCryptography: science of keeping message securesEncryption: process of altering a message so that its content cannot be read by unintended receivers.AuthenticationThe knowledge of the secret ensures the identity of both endpoints

The secret can be used to identify the senderSlide72

Fundamental ModelsSecurity ModelCountermeasuresSecure ChannelsEncryption and Authentication can be used to build a secure channel.A secure channel can be considered as a service layer on top of existing communication services.It is a communication channel that connects a pair of processes, each of which acts on behalf of a principal.Channel properties.Each end point knows who resides on the other end point.The channel ensures privacy and integrity of messages.Each message includes a physical and logical time-stamp to prevent copies.Slide73

Fundamental ModelsSecurity ModelUse of Security ModelsThe techniques discussed in this section constitute the fundamental blocks to build a security infrastructure.Additional issues arises in a real systemPerformance vs Security: security measure introduce processing costs.Other threats beyond the ones listed can be consideredHuman factorGeo-locationA careful analysis of all the aspects of a DS (hardware, software, network, and human) allows to build a

threat model.Slide74

Fundamental ModelsSecurity ModelUse of Security ModelsThe threat model lists all the potential attacks that the systems might be exposed to.Security costs have to be balanced against these attacksBottom line:“how much your enemy is willing to pay to break your security?”Slide75

SummarySlide76

SummaryWhat do we have learnt?Architectural ModelsAn architectural model of a distributed system is concerned with the placement of its parts and the relationship between them.It defines the way in which the components of systems interact with one another and the way in which they are mapped onto an underlying network of computers.Design RequirementsFocus on performance, quality of service, dependability and security

Fundamental modelsWhat is a model and its characteristics

3 Fundamental modelsInteraction modelCommunication modelSecurity modelSlide77

Questions?