Date post: | 14-Nov-2014 |
Category: |
Technology |
Upload: | majong-devjfu |
View: | 1,525 times |
Download: | 1 times |
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
Software Architecture: Foundations, Theory, and Practice
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: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
Deployment Activities
Planning Modeling Analysis Implementation
7
Software Architecture: Foundations, Theory, and Practice
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.
Software Architecture: Foundations, Theory, and Practice
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.
Software Architecture: Foundations, Theory, and Practice
Conflicting QoS Dimensions
Durability
ResourceMonitorModifyResourceMap
Latency
Schedule
10
Objective is to minimize latency and maximize durability There is no optimal deployment architecture!
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Resolving Trade-Offs between QoS Dimensions
Commander
Durability
ResourceMonitorModifyResourceMap
Latency
Schedule
Durability
ResourceMonitorModifyResourceMap
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
Software Architecture: Foundations, Theory, and Practice
Troop
Durability
ResourceMonitorModifyResourceMap
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
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
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
Software Architecture: Foundations, Theory, and Practice
Deployment Modeling
13
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
Deployment Analysis
17
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
1. Are both deployments valid? 2. Which of the two deployments is “better”?3. Does the selected deployment have required properties?
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
Deployment Implementation
Release Install Activate Deactivate Update Adapt Reconfigure De-install or remove De-release or retire
19
Software Architecture: Foundations, Theory, and Practice
Software Deployment Life Cycle
20
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Deployment Tool Support – An Example
21
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
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
Software Architecture: Foundations, Theory, and Practice
Mobility and Quality of Service
24
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
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