22 deployment and_mobility

Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.

Deployment and Mobility

Software ArchitectureLecture 22

Software Architecture: Foundations, Theory, and Practice

What Are Deployment and Mobility?

Deployment is the process of placement of a system’s software components on its hardware hosts

Changing the deployment of a component during runtime is called migration or redeployment

Migration or redeployment is a type of software system mobility Mobility entails a superset of deployment

issues

2


Deployment and Mobility Challenges Widely distributed target processors Target processors embedded inside

heterogeneous devices Different software components may require

different hardware configurations System lifespans may stretch over decades Software system evolution is continuous

(requiring redeployment) Mobile code may mandate that running, stateful

components be redeployed

3


Software Architecture and Deployment A system is deployed to a set of hosts or sites Each site provides a set of resources needed by

the system’s components Hardware Network Peripheral devices System software Other application software Data resources

Resources may be exclusive or sharable4


How Is Deployment Changing ?

Then Complete Installation

procedure for software system on CD ROM

Entire software system installation

Now Software producers

and consumers cooperating and negotiating.

“Update” of Software Systems

5

All this because of high connectivity


Deployment, Architecture, and Quality of Service

Deployment Architecture: allocation of s/w components to h/w hosts hc deployment architectures are possible for a given system

Many provide the same functionality Provide different qualities of service (QoS)

6


Deployment Activities

Planning Modeling Analysis Implementation

7


Deployment PlanningHow do we find and effect a deployment architecture

that improves multiple QoS dimensions?

8

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.


Scenario with a Single QoS Dimension

9

ResourceMonitorModifyResourceMap

Latency

Schedule

Objective is to minimize latency The optimal deployment architecture is

deployment 1Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.


Conflicting QoS Dimensions

Durability


Latency

Schedule

10

Objective is to minimize latency and maximize durability There is no optimal deployment architecture!



Resolving Trade-Offs between QoS Dimensions

Commander

Durability


Latency

Schedule

Durability


Latency

Schedule

11

Allows expression of optimization in terms of a single scalar value

A utility function denotes a user’s preferences for a given rate of improvement in a QoS dimension

Guiding Insight System users have

varying QoS preferences for the system services they access


Troop

Durability


Latency

Schedule

Commander

Exchange Plan

CreatePlan

Security

Dispatcher

0

10

20

30

40

50

60

70

80

0% 100% 200% 300% 400% 500% 600% 700%

Uti

lity

x

QoS Change Rate

Troop, Latency, Exchange Plan

Troop, Latency, Schedule

Troop, Durability, Exchange Plan

Troop, Durability, Schedule

Troop, Security, Exchange Plan

Troop, Security, Schedule

Commander, Latency, Exchange PlanCommander, Latency, Schedule

Commander, Durability, Exchange Plan

12


0

2

4

6

8

10

12

14

16

18

20

0 5 10 15 20 25

Latency (ms)

Dura

bility

(hours

)

x

Dep 1

Dep 2

Dep 3

Dep 4

Dep 5

Dep 6

Dep 7

Dep 8

Dep 9

Dep 10

Dep 11

Dep 12

Dep 13

Dep 14

Dep 15

Dep 16

Dep 17

Dep 18

Dep 19

Dep 20

Dep 21

Dep 22

Dep 23

Dep 24

Dep 25

Dep 26

Dep 27

0

5

10

15

20

25

30

35

40

0 5 10 15 20 25

Latency (ms)

Sec

urity

x

Dep 1

Dep 2

Dep 3

Dep 4

Dep 5

Dep 6

Dep 7

Dep 8

Dep 9

Dep 10

Dep 11

Dep 12

Dep 13

Dep 14

Dep 15

Dep 16

Dep 17

Dep 18

Dep 19

Dep 20

Dep 21

Dep 22

Dep 23

Dep 24

Dep 25

Dep 26

Dep 27

0

5

10

15

20

25

30

35

40

0 2 4 6 8 10 12 14 16 18 20

Durability (hours)

Sec

urity

x

Dep 1

Dep 2

Dep 3

Dep 4

Dep 5

Dep 6

Dep 7

Dep 8

Dep 9

Dep 10

Dep 11

Dep 12

Dep 13

Dep 14

Dep 15

Dep 16

Dep 17

Dep 18

Dep 19

Dep 20

Dep 21

Dep 22

Dep 23

Dep 24

Dep 25

Dep 26

Dep 27

A Slightly Larger Scenario


Deployment Modeling

13



Modeling Architectural Elements Define sets that specify system elements

and their properties Set C of software components

C = {ResourcesMap, SendMessage, Display, …}

Set CP of software component properties

CP = {size, reliability, …} Other sets

H of hardware nodes, N of network links, I of logical links, S of services, Q of QoS, U of users

HP of hardware params, NP of network link params, CP of software component params, IP of logical link params

Define functions that quantify system properties Function cParam:C×CP→R

cParam(ResourcesMap, size) = 150 Other functions

hParam, nParam, IParam, sParam14


Modeling QoS Dimensions

15

Define QoS functions qValue:S×Q×DepSpace →

R quantifies the achieved

level of QoS given a deployment

qValue(Schedule, Latency, Dep 1) = 1ms

Define users’ preferences in terms of utility qUtil:U×S×Q×R →

[MinUtil,MaxUtil] represents the accrued

utility for given rate of change

qUtil(Commander, Schedule, Latency, 0.25) = -1


Modeling System Constraints

16

A set PC of parameter constraints PC={memory, bandwidth,…}

A function pcSatisfied:PC×DepSpace → [0,1] 1 if constraint is satisfied 0 if constraint is not satisfied

Functions that restrict locations of s/w components loc:C×H → [0,1]

loc(c,h)=1 if c can be deployed on h loc(c,h)=0 if c cannot be deployed on h

colloc:C×C → [-1,1] colloc(c1,c2)=1 if c1 has to be on the same host as

c2 colloc(c1,c2)=-1 if c1 cannot be on the same host as

c2 colloc(c1,c2)=0 if there are no restrictions


Deployment Analysis

17


1. Are both deployments valid? 2. Which of the two deployments is “better”?3. Does the selected deployment have required properties?


Deployment Analysis Strategies

Different strategies with different strengths Most of them offer approximate solutions

1. Mixed Integer Non-linear Programming (MINLP)2. Mixed Integer Linear Programming (MIP)3. Heuristic-based strategies

A. GreedyB. GeneticC. Decentralized

18


Deployment Implementation

Release Install Activate Deactivate Update Adapt Reconfigure De-install or remove De-release or retire

19


Software Deployment Life Cycle

20



Deployment Tool Support – An Example

21



Software Mobility Mobile computing involves the movement of human

users together with their hosts across different physical locations This is also referred to as physical mobility

Movement of software across hardware hosts during the system’s execution, that action is referred to as code mobility or logical mobility

If a software module that needs to be migrated contains runtime state, then the module’s migration is known as stateful mobility

If only the code needs to be migrated, that is known as stateless mobility

22


Mobility Paradigms Remote evaluation

Re-deploy needed component at runtime from a source host to a destination host

Install component on the destination host Ensure that the system’s architectural configuration

and any architectural constraints are preserved Activate the component Executed the component to provide the desired

service Possibly de-activate and de-install

Code-on-demand Same as remote evaluation, but roles of target and

destination hosts are reversed Mobile agent

Migration of a stateful software component that needs some remote resources to complete its task 23


Mobility and Quality of Service

24



Closing Thoughts

It may be impractical or unacceptable to bring systems down for upgrades (Re)deployment is thus necessary

Architecture as a set of principal design decisions naturally encompasses (re)deployment

Maintaining the relationship between architectural model and implementation stems degradation

25

22 deployment and_mobility

Technology

Transcript of 22 deployment and_mobility