See all ›

3 CitationsSee all ›

18 ReferencesSee all ›

1 Figure# C2LP: Modelling Load Propagation and Evaluation through the Cloud Components

**Abstract**

Due scale and dynamism of Cloud computing, there is a need for new tools and techniques for its management. This paper proposes an approach to model the load flow in cloud components using a double weighted Directed Acyclic Multigraphs. Such model enables the comparison, analysis and simulation of clouds, which assist the cloud management with the evaluation of modifications in the cloud structure and configuration. The existing solutions either do not have mathematical background, which hinders the comparison and production of structural variations in cloud models, or have the mathematical background, but are limited to a specific area (e.g. energy-efficiency), which does not provide the support the dynamic nature of clouds and to the different needs of the managers. Our model instead has a formal mathematical background and is generic. To this aim, we present its formalisation and algorithms that supports the load propagation and the states of services, systems, third-parties providers and resources, such as: computing, storage and networking. To demonstrate the applicability of our solution, we have implemented a software framework for modelling Infrastructure as a Service, and conducted numerical experiments with hypothetical loads.

Figures

C2LP: Modelling Load Propagation and Evaluation through the Cloud Components

Rafael de Souza Mendes⇤, Rafael Brundo Uriarte†, Carlos Becker Westphall⇤

⇤Federal University of Santa Catarina, Florian´

opolis, Brazil

emails: rafael.mendes@posgrad.ufsc.br, westphal@inf.ufsc.br

†IMT Institute for Advanced Studies Lucca, Italy

email: rafael.uriarte@imtlucca.it

Abstract—Due scale and dynamism of Cloud computing, there

is a need for new tools and techniques for its management.

This paper proposes an approach to model the load ﬂow in

cloud components using a double weighted Directed Acyclic

Multigraphs. Such model enables the comparison, analysis and

simulation of clouds, which assist the cloud management with

the evaluation of modiﬁcations in the cloud structure and conﬁg-

uration. The existing solutions either do not have mathematical

background, which hinders the comparison and production of

structural variations in cloud models, or have the mathematical

background, but are limited to a speciﬁc area (e.g. energy-

efﬁciency), which does not provide the support the dynamic

nature of clouds and to the different needs of the managers.

Our model instead has a formal mathematical background and is

generic. To this aim, we present its formalisation and algorithms

that supports the load propagation and the states of services,

systems,third-parties providers and resources, such as: computing,

storage and networking. To demonstrate the applicability of

our solution, we have implemented a software framework for

modelling Infrastructure as a Service, and conducted numerical

experiments with hypothetical loads.

Keywords-Cloud Computing; Management; Simulation; Multi-

graph.

I. INTRODUCTION

The management of pooled resource according to high-

level policies is a central requirement of the as a service

model, as fostered by cloud computing (CC). A decision-

making in the scale of clouds, where there exist many possible

conﬁgurations and complex data ﬂows, is challenging and is

still an open issue in the ﬁeld. In order to use the well-

established approaches of decision theory[1] and managerial

science [2] for the CC management, it is necessary to employ

formal models to represent the managed elements and the ﬂow

of the service loads. Furthermore, such a model is also required

for the evaluation of possible actions, and for the analysis of

cloud components and its hierarchy, which are usually carried

out by the management of a cloud operation. We highlight

this lack of formal models based in our previous efforts to

develop methods to CC autonomic management [3][4][5] and

formalisms based on Service Level Agreement (SLA) [6].

Currently, the existing solutions which provide CC models

can be classiﬁed into two main groups: general models, usually

represented by the simulators; and speciﬁc models, devised

for a particular ﬁeld (e.g., energy saving). The former lack a

mathematical formalisation that enables the comparisons with

variations on the modellings. The latter usually have the formal

mathematical background but, since they are speciﬁc, they do

not support reasoning on different management criteria and

encompass only cloud elements related to the target area.

To address this gap in the literature, we analyse the

domain elements and characteristics to propose the Cloud

Computing Load Propagation (C2LP) graph-based model, a

formal schema to express the load ﬂow through the cloud

computing components. Considering that a load express the

amount of work to process services in systems or resources,

the modelling of the load ﬂows enables cloud managers to

performance several types of analysis about the cloud structure

and behaviour. For example, it enables the comparison of

different cloud structures, the distinction of load bottlenecks,

the quantitative analysis of the load propagation and of the

effects of processing a load in a cloud. In more general

terms, such solution uniﬁes heterogeneous abstraction levels

of managed elements into a single model and can assist the

decision-making tasks in processes, such as: load balance,

resource allocation,scale up/down and migrations. Moreover,

simulations performed using our model, can be useful to

predict the consequences of managerial decisions and external

events, as well as the evolution of baseline behaviour.

More speciﬁcally, we model the basic components of

CC, the services,systems,third-party clouds that implement

services and the resources in which system are deployed

over: computing,storage,networking. Our model is based

in Directed Acyclic Multigraphs. This formalism enables the

manager to access consolidated analytical mathematical tools

to, e.g., measure the components interdependencies, which

is used to improve the availability and resource allocation.

In order to demonstrate the applicability and advantages of

C2LP model, we present a use case where our model is used

to compare and evaluate different managerial conﬁgurations

over several quantitative behaviour in load propagation and

evaluation.

This article is organised as follows. Section II discusses the

existing cloud models, the works that inspired the deﬁnition

of this model and the background information necessary for

the appreciation of this work. In Section III, we present

an overview about the model, formalise it, the propagation

algorithm, and the evaluation process. Section IV describes

the implementation and the analysis performed on a use case.

Finally, in Section V, we discuss the limitations and the future

directions for the research.

II. RELATED WORKS

This section presents the related works that propose models

to describe and simulate clouds. We have analysed them from

acloud provider management perspective, considering their

Published at ICN 2016: The Fifteenth International Conference on Networks

capacity to: express general cloud models, deﬁne components

in distinct abstraction levels; compare structures; simulate be-

haviours and provide formal speciﬁcations with mathematical

background. Table I summarises this comparison.

We grouped the proposals into two classes: general and

speciﬁc. General models are usually associated with simulators

and are used to evaluate numerous criteria at the same time.

On the other hand, speciﬁc models are commonly associated

with particular criterion evaluation, such as: performance [7],

security [8][9], accounting [10][11] or energy [12].

All analysed works of the ﬁrst group, i.e., CloudSim

[13], GreenCloud [14], iCanCloud [15], EMUSIM [16] and

MDCSim [17], are data-centre oriented, thus requiring exten-

sions to enable the abstraction of important cloud elements,

such as services and systems. One exception, the EMULSIM

framework, allows the modelling of application and, from

theses models, the estimation of some performance measures

but it also depends on data-centre elements, such as: virtual

machines and physical machines. The limitation of the existing

generic solutions to deal with abstract elements and their lack

of mathematical background hinders the comparison and pro-

duction of structural variations in cloud modellings, which, in

turn, limits their capacity to test the performance of managerial

methods.

On the other hand, the solutions in the second group, i.e.,

the ones speciﬁcally devised for an area, present in-depth

analysis, based on robust formalisms, such as queue theory

[12] [7], probability [8], fuzzy uncertainty [11] and heuristics

[10]. However, these models do not ﬁt well in integrated

management methods that intent to ﬁnd optimal conﬁgurations

considering several criteria of distinct types. Moreover, speciﬁc

optimisation models usually are sensible to structural changes,

having no robustness to support the dynamic nature of the

clouds.

The comparison between the related works is schematised

in the Table I, where: column “Class” speciﬁes if a work is gen-

eral or speciﬁc; “Formalism” evaluates the mathematical back-

ground that support the models; the column “Components”

presents the capacity of a model express cloud components in

different abstraction levels; the ability to compare structures

is depicted in column “Comparison”; and, “Simulation” ex-

presses the capacity to perform simulations using the models.

Considering the gap in the existing cloud modelling tech-

niques, our proposal intents to model the load propagation

and evaluation functions over a graph to obtain expressiveness,

whilst keeping the mathematical background. We opt to model

the “load ﬂow” because it is one of the most important

information for managerial decisions, such as: load balance,

resource allocation, scale up/down and migrations.

III. MODELLING LOAD FLOW IN CLOUDS

This section discusses, the main components of cloud

structures and proposes a formal model based on a directed

acyclic multigraph, to represent the load ﬂow in clouds.

Subsection III-A presents the structural model and its main

components. In Subsection III-B, we formally deﬁne the data

structures to represent loads,conﬁgurations,states and func-

tions. Finally, Subsection III-C discusses the computational

details of the propagation of the loads and the evaluation of

the states for each cloud component.

Model Class Formalism Components Comparison Simulation

CloudSim [13] General -⌅-⌅

GreenCloud [14] General -⌅-⌅

iCanCloud [15] General -⌅-⌅

EMUSIM [16] General -⌅-⌅

MDCSim [17] General -⌅-⌅

Chang[12] Speciﬁc ⌅ ⇤ ⌅ ⇤

P¨

uschel [11] Speciﬁc ⌅ ⇤ ⌅ ⇤

Nesmachnow [10] Speciﬁc ⌅ ⇤ ⌅ ⇤

Silva. [8] Speciﬁc ⌅ ⇤ ⇤ ⇤

Vilaplana [7] Speciﬁc ⌅ ⇤ ⌅ ⇤

C2LP General ⌅ ⌅ ⌅ ⇤

TABLE I: Comparison between related models. ⌅represents

a feature, ⇤a partially covered one and -when the feature is

not supported.

A. Modelling Clouds with C2LP

In C2LP, the structural arrangement of cloud elements is

based in a directed acyclic multigraph (DAM). The nodes of

the graph represent components of the model and can be of

four types.

•Computing,Storage and Networking resources, which are

the base of any cloud service. These components are

always leaf nodes.

•Systems, which are abstractions that orchestrate resources

that provide and implement services. They can be, e.g.,

applications and platforms. In the model, systems must be

directly linked to at least one of each type of resource:

computing, storage and networking. Nevertheless, these

resources might be replaced by other systems or third-

party services. In such cases, the relationship between

the system and the element that represents the resource

(i.e., another system or the third-party service) must be

explicitly deﬁned using stereotypes (virtual computing,

virtual networking or virtual storage).

•Third-Party Services, which might represent: (i) resources

to system components, when the relation is explicitly

annotated with the appropriated stereotype, and (ii) entire

systems which provide services and abstract the under-

lying layers (e.g., email services). The latter models, for

example, hybrid clouds or composed services.

•Services, which are interfaces between the cloud and the

consumers. They are invocated with speciﬁcation of the

consumer’s needs and, in this model, they are converted

into loads.

Directed edges in our model deﬁne to which elements

each cloud component can transmit load. Nodes have two

main processes: propagation of the load; and evaluation of

the impact of the load in the node itself. Remarkably, the

resources components do not propagate load and are the only

nodes that actually run the assigned load, while other elements

are abstract (e.g., applications, middlewares, platforms and

operations systems). Moreover, we consider in the model also

the conﬁgurations settings of nodes, which impact on the

propagation and evaluation processes.

The cloud offer services and receives requests from con-

sumers. Requests are then propagated to other nodes using a

propagation function that deﬁnes to which linked node, the

division and in which form the load will be propagated. Since

loads might have different forms, we model these relations

enabling multiple edges between nodes, which simpliﬁes the

understanding of the model. For example, a service transmits

Figure 1: Example of the propagation of loads and the

evaluation processes using the C2LP model.

10 GFLOPS and 100 gb of data to third-party service. This

relation is modelled using two edges, one for each type of

load. In case of change in the structure (e.g., a cheaper storage

provider) the model can be adjusted simply by remove the

storage edge between these nodes and adding it to this new

third-party provider.

The evaluation process measures the impact of the load

in the resources components and, consequently, on the other

nodes of the structure. This process is performed in each node

using an evaluation function, which receives three parameters:

the conﬁguration of the node, the load deﬁned in the edges

and the results of the evaluation of nodes which it propagated

load (other nodes under it). In case of resources components,

the function uses only the conﬁguration and edge loads for the

evaluation.

Figure 1 presents the modelling of a scenario, in which a

cloud provides two services: an email and Infrastructure-as-a-

Service (IaaS). The IaaS is provided by a third-party cloud.

The email service instead, employs a system component to

represent a software email server (in this case a Postﬁx). This

component uses local computing and networking and storage

from a third-party cloud. The relation (edge) between these

components is annotated accordingly.

In the proposed scenario, we exemplify the load propa-

gation with a request from consumers to send 2 new emails

using the email service. These two emails are converted by the

service component into a 2 transactions load and this load is

propagated to the resources linked to the server into different

types of load.

The evaluation process of this scenario uses different

metrics in each node and is marked as “result:“. For example,

in the service level, the load of 2 emails was measured in

ﬁnancial cost and energy necessary to complete the request.

B. Formalisation of the Model

Formally, in C2LP model, a cloud Ccan be expressed as

C=(V,E,⌧V,,,,,,0,0), where:

•Vis the set of nodes V={v1,v

2,...,v

n}of the

multigraph, such that every item in Vrepresents one

element of the cloud and have one respective node-weight

wv, that usually is a vector of values;

•Eis the set of directed edges where E=

{e1,e

2,...,e

m}|e=(v, v0), that describes the ability of

a source node vto transmit a load to node v0, such that

each emhave also a respective edge-weight wv,v0;

•⌧V:V!TVis a bijective function which

maps the nodes with the respective type, where

the set TVis the set of types of nodes, such

that TV={0computing0,0storage0,0networking0,

0system0,0service0,0third party0};

•:E{!system,!thirdparty }!{none, vC omputing,

vStorage, vNetworking}is a function which maps the

edges that have systems and third-party services as target

with the respective stereotype, characterising the relation

between the source element with the target;

•represents the set of propagation functions, where

={f1,f

2,...,f

v}and is a bijective function

:V!that maps each node for the respective

propagation function. Each function in the set is deﬁned

as fv:Nn,Ri!Ro, where: the set Nnrepresents the

space where the n-tuple for the conﬁguration; the set

Rirepresents the space where the n-tuple of incoming

edge-weights is contained; and, Rois the space where

the n-tuple of the outgoing edge-weights is contained.

To simplify the model and the algorithms, we consider

that conﬁgurations are stored in the node-weight, such

that wconf

vrepresents the conﬁguration part of the node-

weight vector.

•is the set of sets that contains the evaluation functions

for the leaf nodes, such that must exist one function

per distinct evaluation metric (e.g., energy use, CO2

emission, . . . ). Then, ={1,2,...k}, such that

k={gn+1,g

n+2,...,g

m}. Each set kis related

with a leaf node v2V[leaf]through the bijective

function :V[leaf]!. Every gn+mis stored in

a distinct position of the node-weight vector of the

respective node – representing a partial state of v–

such that the full new state can be computed through

the expression: w0

v=(c1,...,c

n,g

n+1(c1,...,c

n,w

i

v),

gn+2(c1,...,c

n,w

i

v),...,g

n+m(c1,...,c

n,w

i

v)), where:

c1,...,c

nis the n-tuple with the conﬁguration part of

the node-weight wv;wi

vis the n-tuple with all incoming

edge-weights w⇤,v of v; and w0

vis the new node-weight

(full state) for v. The complete evaluation procedure is

detailed in the Figure 3;

•0is the set of sets that holds the evaluation functions

for non-leaf nodes. Therefore, 0={0

1,0

2,...,0

l},

such that each set 0

l={g0

n+1,g

0

n+2,...,g

0

m}con-

tains the evaluation functions g0

n+m. Every 0

lis as-

sociated with a non-leaf node vthrough the bijective

function 0:Vnonleaf !0. Since the result of

each function g0

n+mis stored in a distinct position

of w0

v, it represents a partial state of the respective

node v. A new full state of non-leaf nodes can be

computed through the expression: w0

v=(c1,...,c

n,

1: procedure BREADHTFIRSTPROPAGATION(C,WV,WE).

Requires a cloud model C=(V,E, ⌧V,,,), the

set of node-weights WV|8v2V^9!wv2WVand

the set of edge-weights WE|8ev,v02E^9!wv,v02

WE.

2: queue ?

3: enqueue(⇤)

4: repeat

5: v dequeue()

6: for each u2successorSet(v)do

7: enqueue(u)

8: end for .enqueues the sucessor of each node

9: fv (v)

10: wconf

v conf igurationP art(wv).gets the

conﬁg. part of the node-weight (state).

11: wi

v (w1,v,w

2,v,...,w

u,v).builds the

incoming edge-weights in a tuple wi

v.

12: wo

v fv(wconf

v,w

i

v).w

o

vcontains the result of

the propagation function.

13: for each wv,u 2wo

vdo

14: WE WEwv,u .replaces the old value

of wv,u.

15: end for.assign the values for the outgoing edges

of v.

16: until queue 6=?

return WE

17: end procedure

Figure 2: Breadth-ﬁrst algorithm used for the load

propagation.

g0

n+1(c1,...,c

n,w

i

v,w

0

uv),g

0

n+2(c1,...,c

n,w

i

v,w

0

uv),

...,g

0

n+m(c1,...,c

n,w

i

v,w

0

uv)); where w0

vis the new

node-weight of v,c1,...,c

nis the n-tuple with the

conﬁguration part wconf

vof the node-weight, wi

vis the

n-tuple with the incoming edge-weights e⇤,v of v, and

w0

uvis a tuple which puts together all node-weights of

the successors of v(see Figure 3 for details).

The main objective of these formalisms is to specify the

data structures that support a model validation, the load propa-

gation, and elements evaluations. The details of each procedure

concerned to propagation and evaluations are described in the

Subsection III-C.

C. Details on the Propagation and Evaluation

The load propagation consists in a top-down process for

which uses the breadth-ﬁrst approach. In a breadth-ﬁrst algo-

rithm, the loads are propagated to the neighbours nodes before

moving to the next level nodes. In the speciﬁc case on C2LP the

algorithm starts from the loads on the services, corresponding

to the requests received from consumers.

The propagation process uses a queue with the service

nodes (the roots of the graph). Then, a node vis picked

from this queue and all its children are placed into the queue.

Afterwards, a function fv=(v)is executed to distribute the

load, that is, to deﬁne all edge-weights for the outgoing edges

of v. This procedure is repeated while the queue is not empty.

The well deﬁned method is detailed in the Figure 2

When the load is propagated to resources components (leaf

nodes), they execute the load. This execution requires power

and resources and can be evaluated in several forms. For

example, energy (kw),performance,availability,accounting,

security,CO2emissions and other cloud speciﬁc features units.

This evaluation process takes every function gn+m2kin

order compute each partial states, storing them into a position

of the new node-weight w0

v. A ﬁner description can be deﬁned

as: w0

v=(wconf

v,g

n+1(wconf

v,w

i

v),...,g

n+m(wconf

v,w

i

v),

such that w0

vrepresents the a posteriori state for the node

v,wconf

vare the conﬁgurations (a priori state) of v,wi

vare

the incoming edge-weights of v, and gn+m2(v)are the

evaluation functions associated with the node.

The evaluations also comprehend the non-leaf nodes since

the load also passes through then and it is useful, e.g., to

understand the load distribution and to identify bottlenecks.

In the case of non-leaf nodes, the evaluation requires also the

evaluation results of the bottom nodes. Therefore, this process

is performed from the leaves to the roots using a depth-ﬁrst

approach.

The evaluation in the resources occurs according to several

models that converts the conﬁguration, loads and the results

of other evaluations into node-weights.

A non-leaf node receives the tuples (config , loads,

children states), and evaluates by the processing

of all g0

n+m20(v)functions. A representation

of this process can be described as: w0

v=

(wconf

v,g

0

n+1(wconf

v,w

i

v,w

0

uv),...,g

0

n+m(wconf

v,w

i

v,w

0

uv),

such that w0

vrepresents the new node-weight (a posteriori

state) for the node v,wconf

vare the conﬁguration part (a

priori state) of node-weight into v,wi

vrepresent the incoming

edge-weights of v,w0

uvare the computed node-weights of

the successors of v, and g0

n+m20(v)are the evaluation

functions associated with the node.

The complete evaluation process is detailed in the Figure

3, where a stack is used to perform a depth-ﬁrst computation.

The ﬁrst non-visited child of a current node is placed into the

stack and will be used as current node. When all children of a

node are evaluated, then the node is evaluated. If the node is a

leaf node the gfunctions are used to compute the evaluations,

otherwise, the g0functions are used instead.

IV. EXPERIMENTS AND RESULTS

This section presents, numerical experiments with the C2LP

model, based on a service modelling. These experiments serve

to: test the applicability of the model; present a concrete

example of modelling; and, demonstrate the model capacity

for quantitative behaviours generation combining variations

of propagation and evaluation functions.

To perform these experiments we have implemented a

use case using our model. This use case exempliﬁes the

model’s usage and serves to test its feasibility. The example of

model’s usage was made using hypothetical functions, since

its objective is to prove the generation of simulations, the

propagation and the evaluation. Nevertheless our model can

be used for modelling real-world clouds, provided that the

propagation and evaluation functions are adjusted to the cloud

instance.

As use case, we deﬁned a IaaS service where consumers

perform ﬁve operation: deploy VM,undeploy VM,start VM,

stop VM, and execute tasks. To meet the demand on this

services, we designed a hypothetical cloud infrastructure with

which is possible to generate quantitative scenarios of propaga-

tion and evaluation – in a combinatorial fashion. Using this hy-

pothetical infrastructure, we have tested some managerial con-

1: procedure DEPTHFIRSTEVAL U AT I O N (C,WV,WE).

The same input described in Figure 2.

2: ?.initializes the set of visited nodes.

3: stack ?.initializes the stack.

4: push(⇤).starts from the hypothetical node.

5: while stack 6=?do

6: v peek() .gets a node without to remove it.

7: for each u2successorSet(v)do

8: if u/2then

9: push(u)

10: continue while

11: end if

12: end for .if the for loop ends, all successors have

been evaluated.

13: wconf conf igurationP art(wv).gets the

conﬁg. part for v.

14: wi

v (w1,w

2,...,w

u,v).builds the n-tuple

with the incomings of v.

15: if isLeaf(v)then

16: w0

v (wconf

v,g

n+1(wconf

v,w

i

v),...,

gn+m(wconf

v,w

i

v)),8gn+m2(v)

.computes the partial states and builds

the new node-weight.

17: else

18: w0

uv (w0

u1,w

0

u2,...,w

0

uo).

builds the computed node-weights for all

u|9ev,u 2E.

19: w0

v (wconf

v,g

0

n+1(wconf

v,w

i

v,w

0

uv),...,

g0

n+m(wconf

v,w

i

v,w

0

uv)),8g0

n+m20(v).

computes the partial states and builds the

new node-weight.

20: end if

21: WV WVw0

v.replaces the old state of v

into the node-weights.

22: if v/2then

23: [v

24: end if .puts vin the visited set if it is not there.

25: v pop() .gets and removes vfrom the stack.

26: end while

return WV

27: end procedure

Figure 3: Depth-ﬁrst algorithm to evaluate in speciﬁc metrics

the impact of the load in each node.

ﬁgurations related to load distribution over the cloud elements,

in order to evaluate the average utility for all quantitative

scenarios. At end, the conﬁgurations which achieve the best

average utility for all quantitative scenarios were highlighted,

depicting the ability of the model to simulate conﬁguration

consequences for purposes of to select conﬁgurations.

A. Use Case Modelling

To deal with the consumers’ loads (deploy, undeploy, start,

stop and execute), the infrastructure manages: the service

interface; systems, such as load balancers,cloud managers

and cloud platforms; and resources, such as servers,storages

and physical networks. All operations invoked by consumers

represent an incoming load in the service interface, which

is propagated to resources. In the resources the loads are

evaluated to provide measures about performance,availability,

accounting,security and CO2emissions. These evaluations are

then executed also for systems and, at end, for the service

interfaces.

The modelling of the use case was devised considering

21 components: 1 service, 9 systems, and 11 resources. The

services represent the interface with customers. In this use

case, the systems are: a load balancer; two cloud manager

systems; and six cloud platforms. Also, between the resources

there are: 8 physical computing servers (6 work servers and 2

managerial), 2 storages (1 work storage and 1 managerial), and

1 physical network. A detailed list of components is presented

in Annex VI.

Regarding the edges and loads, each consumer’s operation

is modelled as an incoming edge in a service interface node

– with the respective loads in the edge-weights. The service

node forwards the loads for a load balancer system, where

the propagation function decides to which cloud manager the

load will be sent, whereas the manager servers, the manager

storage and the physical network receive the loads by its

operation. In the cloud mangers, the propagation function must

decide to which cloud platform the loads will be sent and, at

the same time, generate loads for the managerial resources. The

cloud platform system effectively converts its loads into simple

resource loads when uses the work server,work storage and

physical network. The complete relation of load propagation

paths is presented in Annex VI, where an element at the left

side of an arrow can propagate loads for an element at the

right. Furthermore, a graphical representation of these tables,

which depicts the graph as a whole, is also presented in Annex

VI.

Besides the node and the edges, the use case model

required the deﬁnition of: •4types of propagation functions

– one for the service and tree for each type of system; •6

types of leaf evaluation functions – two speciﬁc performance

evaluations, one for computing resources and another for stor-

age and networking; plus, four common evaluation functions

(availability, accounting, security and CO2emissions) for each

type of resource; •5types of non-leaf evaluations functions.

We have modelled the possible combinations to dis-

tribute the loads {1-deployVM,2-undeployVM,3-startVM,4-

stopVM,5-compute}as a partition set problem [18], resulting

in 52 distinct possibilities of load propagation. Also, we

introduced 2possible conﬁgurations in each leaf evaluation

functions regards to the constants into them. For example,

the performance of a computing resource depends of its

capacity, that can be: a= 50GFLO P s or b= 70GF LOP s.

Considering 5distinct evaluation functions over 11 leaf nodes,

we have got (25)11 =2

55 possible distinct conﬁgurations to

test.

B. Evaluations

The numerical experiments were performed running the

propagation procedure, followed by the evaluation of every

simulation. For each possible propagation were tested and

summarised the 255 conﬁgurations for evaluation functions.

Then, we analysed the average time (p, in seconds), average

availability (av, in %), average accounting (ac, in currency

units), average security (s, in % of risk of data exposition),

and average of CO2emissions (c, in grammes). Each value

was normalised according to the average for all propagations,

tested and summarised in a global utility function, described

in (1) – where the overlined variables represent the normalised

Criteria Conﬁguration

Code 11221 11231 11232 11212

Time 180.59976 180.5999 180.60004 180.59991

Availability 0.9979606 0.99795955 0.9979587 0.99795926

Accounting 78.69924 78.69926 78.699234 78.699265

Security 0.9979606 0.99795955 0.9979587 0.99795926

Emissions 82848.31 82848.14 82848.51 82848.74

Utility 1.0526400204 1.0526410547 1.0526477776 1.0526491889

TABLE II: Summary of average evaluations for each

conﬁguration.

values.

Such results enable cloud managers to choose the best

scenario according to the priorities of the policy or to provide

input for decision-making process, such as Markov Chains.

u=(av +s(p+ac +c)) (1)

The best four results of the ﬁfty two numerical experiments

are presented in the Table II in ascendant ordering, where the

conﬁguration that achieve the best average utility is highlighted

as bold. The code line in the table represents the propagation

conﬁguration, whereas the other lines contains the values got

for each distinct evaluation type. In the last row is presented

the average utility deﬁned in Equation 1. To represent conﬁg-

uration we have adopted a set partition notation to express

the propagation paths, such that each position in the code

represents a type of load: 1-deploy, 2-undeploy, 3-start, 4-stop,

and 5-compute. Considering that at leaves of the propagation

graph there are 6 cloud platforms, a code 11212 indicates that

the loads of type 1,2 and 4 were allocated on cloud platform 1,

whereas the loads 3 and 5 ware allocated in the cloud platform

2.

V. C ONCLUSION

Several solutions have been proposed to model clouds.

However, to the best of our knowledge, none at the same time

is general and has mathematical formalism, which are essential

characteristics for the consolidation of analytical methods.

In this study, we have presented an approach with these

characteristics to model clouds based in Directed Acyclic

Multigraph, which has the ﬂexibility of general models and

the formalism of the speciﬁcs. Therefore, C2LP is a ﬂexible

well-formed modelling tool to express ﬂow of loads through

the cloud components. This model supports the speciﬁcation

of elements in distinct abstraction levels, the generation of

combinatorial variations in a use case modelling and the

evaluation of the consequences of different conﬁguration in

the load propagation.

We developed a simulation software tool for the modelling

of IaaS services and demonstrated the applicability of our

approach through a use case. In this use case, we simulated

several graph network theoretic analysis, evaluated and com-

pared different conﬁgurations and, as a result, supplied the

cloud managers with a numeric comparison of cost and beneﬁts

of each conﬁguration. These experiments, demonstrated that

this tools provides an essential support for the management of

cloud.

ACKNOWLEDGEMENT

The present work was done with the support of CNPq

agency, through the program Ciˆ

encia sem Fronteiras (CsF),

and the company Eletrosul Centrais El´

etricas S.A. – in Brazil.

The authors also would like to thank the professor Rocco De

Nicola and the group of SysMA research unit in Institute for

advanced studies Lucca (IMT).

REFERENCES

[1] Itzhak Gilboa, “Theory of Decision under Uncertainty,” Cambridge

University Press, 2009.

[2] Cliff Ragsdale, “Modeling & Decision Analysis,” Thomson, 2008.

[3] Rafael Mendes et al., “Decision-theoretic planning for cloud com-

puting,” In ICN 2014, The Thirteenth International Conference on

Networks, Iaria, vol. 7, no. 3 & 4, 2014, pages 191–197.

[4] Alexandre A. Flores, Rafael de S. Mendes, Gabriel B. Br¨

ascher, Carlos

B. Westphall, and Maria E. Villareal, “Decision-theoretic model to

support autonomic cloud computing,” In ICN 2015, The Fourteenth

International Conference on Networks, Iaria, vol. 8, no. 1 & 2, 2015,

pages 218–223.

[5] Rafael Brundo Uriarte, “Supporting Autonomic Management of Clouds:

Service-Level-Agreement, Cloud Monitoring and Similarity Learning,”

PhD thesis, IMT Lucca, 2015.

[6] Rafael Brundo Uriarte, Francesco Tiezzi, and Rocco De Nicola, “SLAC:

A formal service-level-agreement language for cloud computing,” In

Proceedings of the 2014 IEEE/ACM 7th International Conference on

Utility and Cloud Computing, IEEE Computer Society, 2014, pages

419–426.

[7] Jordi Vilaplana, Francesc Solsona, and Ivan Teixid´

o, “A performance

model for scalable cloud computing,” In 13th Australasian Symposium

on Parallel and Distributed Computing (AusPDC 2015), ACS, vol. 163,

2015, pages 51–60.

[8] Paulo F Silva, Carlos B Westphall, and Carla M Westphall, “Model

for cloud computing risk analysis,” ICN 2015, Iaria, vol. 8, no. 1 & 2,

2015, page 152.

[9] Nada Ahmed and Ajith Abraham, “Modeling cloud computing risk

assessment using machine learning,” In Afro-European Conference for

Industrial Advancement, Springer, 2015, pages 315–325.

[10] Sergio Nesmachnow, Santiago Iturriaga, and Bernabe Dorronsoro,

“Efﬁcient heuristics for proﬁt optimization of virtual cloud brokers,”

Computational Intelligence Magazine, IEEE, vol. 10, no. 1, 2015, pages

33–43.

[11] Tim P ¨

uschel, Guido Schryen, Diana Hristova, and Dirk Neumann,

“Revenue management for cloud computing providers: Decision mod-

els for service admission control under non-probabilistic uncertainty,”

European Journal of Operational Research, Elsevier, vol. 244, no. 2,

2015, pages 637–647.

[12] Chunling Cheng, Jun Li, and Ying Wang, “An energy-saving task

scheduling strategy based on vacation queuing theory in cloud com-

puting,” Tsinghua Science and Technology, IEEE, vol. 20, no. 1, 2015,

pages 28–39.

[13] Rodrigo N. Calheiros, Rajiv Ranjan, Anton Beloglazov, Csar A. F.

De Rose, and Rajkumar Buyya, “Cloudsim: a toolkit for modeling and

simulation of cloud computing environments and evaluation of resource

provisioning algorithms,” Software: Practice and Experience, Wiley

Online Library, vol. 41, no. 1, 2011, pages 23–50.

[14] Dzmitry Kliazovich, Pascal Bouvry, and Samee Ullah Khan, “Green-

Cloud: a packet-level simulator of energy-aware cloud computing data

centers,” The Journal of Supercomputing, Springer, 2012, page 1263–

1283.

[15] Alberto N ´

u˜

nez et al., “iCanCloud: A ﬂexible and scalable cloud

infrastructure simulator,” Journal of Grid Computing, Springer, vol.

10, no. 1, 2012, pages 185–209.

[16] Rodrigo N Calheiros, Marco AS Netto, C ´

esar AF De Rose, and

Rajkumar Buyya, “EMUSIM: an integrated emulation and simulation

environment for modeling, evaluation, and validation of performance

of cloud computing applications,” Software: Practice and Experience,

Wiley Online Library, vol. 43, no. 5, 2013, pages 595–612.

[17] Seung-Hwan Lim, Bikash Sharma, Gunwoo Nam, Eun Kyoung Kim,

and Chita R Das, “MDCSim: A multi-tier data center simulation,

platform,” In Cluster Computing and Workshops, 2009. CLUSTER’09.

IEEE International Conference on, IEEE, 2009, pages 1–9.

[18] Touﬁk Mansour, “Combinatorics of Set Partitions,” CRC Press, 2012.

VI. APPENDIX I: IMPLEMENTATION DETAILS

CS - computing service CP21 - platform 21 WS12 - work server 12

LB - load balancer CP22 - platform 22 WS13 - work server 13

CM1 - cloud manager 1 CP23 - platform 23 WS21 - work server 21

CM2 - cloud manager 2 MS1 - manager server 1 WS22 - work server 22

CP11 - platform 11 MS2 - manager server 2 WS23 - work server 23

CP12 - platform 12 MSTO - manager storage WSTO - work storage

CP13 - platform 13 WS11 - work server 11 PN - physical network

TABLE III: The cloud elements – nodes of the graph.

5

! CS CM1 5

! CP11 CP11 !WS11 CP21 !PN

CS 5

! LB CM1 5

! CP12 CP11!PN CP21!WSTO

LB 5

! CM1 CM1 5

! CP13 CP11!WSTO CP22!W22

LB 5

! CM2 CM1 !PN CP12!WS12 CP22 !PN

LB !MS1 CM2 !MS2 CP12 !PN CP22 !WSTO

LB !MS2 CM2 !MSTO CP12 !WSTO CP23 !W23

LB !WSTO CM2 5

! CP21 CP13!W13 CP23 !PN

LB !PN CM2 5

! CP22 CP13!PN CP23 !WSTO

CM1 !MS1 CM2 5

! CP23 CP13 !WSTO

CM1 !MSTO CM2 !PN CP21 !W21

TABLE IV: The load propagation relations – edges of the graph.

Computing

Service

Load

Balancer Cloud

Manager 2

Cloud

Manager 1

Manager

Server 1

Platform

11

Manager

Server 2

Phisical

Network

Platform

12

Platform

13

Platform

21

Platform

22

Platform

23

Work

Server 11

Work

Server 12

Work

Server 13

Work

Server 21

Work

Server 22

Work

Server 23

Work

Storage

Manager

Storage

Figure 4: Graphical representation of structural arrangement for the modelling use case.

Types Declarations Deﬁnitions

service (w1,··· ,w

5)fCS

7! (w0

1,··· ,w

0

5).wnis the weight for n

! CS).

w0

nis the weight for (CS n

! LB).

w0

n=wn|8w0

n2fCS.

balancer (c1,...,c

5,w

1,··· ,w

5)fLB

7!.

(w0

1,...,w

0

14)

cn2{CM1,CM2}, are the conﬁgurations which represent the targets of

each load wn|16n65.

w0

n=⇢wnif cn=CM1

0otherwise

16n65

.

w0

n+5 =⇢wnif cn=CM2

0otherwise

16n65

.

w0

1>n>5, are the weights in the edges LB 5

! CM1.

w0

6>n>10, are the weights in the edges LB 5

! CM2.

w0

11 =1Gf lop, is the a constant computing load in LB!MS1.

w0

12 =1Gf lop, is the a constant computing load in LB!MS2.

w0

13 =50GB, is the a constant storage load in LB!MSTO.

w0

14 =w1+40, is the load over LB!PN, such that w1is the VM image

size in GB, comes from deploy VM operation, and 40 is a constant value in GB

for the another operations.

cloud manager (c1,...,c

5,w

1,··· ,w

5)fCMn

7!

(w0

1,...,w

0

18)

cn2{CPm1,CPm2,CPm3}, are the conﬁgurations which represent

the targets of each load wn|16n65.

w0

n=⇢wnif cn=CPm1

0otherwise

16n65

.

w0

n+5 =⇢wnif cn=CPm2

0otherwise

16n65

.

w0

n+10 =⇢wnif cn=CPm3

0otherwise

16n65

.

w0

16 =1Gf lop, is the a constant computing load in CMn!MSn.

w0

17 =50GB, is the a constant storage load in CMn!MSTO.

w0

18 =w1+40, is the load over CMn!PN, such that w1is the VM image

size in GB, comes from deploy VM operation, and 40 is a constant value in GB

for the another operations.

cloud platform (w1,··· ,w

5)fCPnn

7! (w0

1,w

0

2,w

0

3).w1,··· ,w

5, are the main loads come from the service, associatively, w1–

deploy VM, w2– undeploy VM, w3– start VM, w4– stop VM, and w5–

compute tasks.

w0

1,w0

2and w0

3are, respectively, the edge-weight for the arcs CPnn!WSnn,

CPnn!WSTO and CPnn!PN, where:

w0

1=w1w2+w3w4+w5;

w0

2=w1w2+1MB;

w0

3=w1+w3w4+1MB.

TABLE V: Propagation functions.

Types Functions

computing speciﬁc functions performance (duration): d(load)= load

capacity , where load is expressed in GFlop, capacity is a constant of 70GFLOPs and

dis the total time to resolve the load.

energy increment (kWh): energyincrement (load)here is considered a linear function which returns the amount of energy

necessary to process the load above the average consumption of standby state. For computing have been considered 0.001kW

per GFLOP.

storage and network speciﬁc functions performance (duration): d(load)= load

capacity , where load is expressed in GByte, capacity is a constant of 1GBps and dis

the total time to resolve the load. For the networking resources this concept is intuitively associated with the network throughput,

however, for storage is necessary to explain that the performance refers to throughput of the data bus.

energy increment (kW): energyincrement (load)for data transmission is assumed as linear, and was here considered 0.001kW

per GB transferred.

common functions availability:av(load)=1pfault(d(load)), where pfault is the probability which a fault occurs during the load

processing. Here will be considered a linear naive probability, such that pfault(d)=d⇥0.01.

accounting:ac(load)=priceenergy ⇥energ ytotal, where priceenerg y is a constant of 0.38US$/kW

or 0.58US$/kW , depending on node conﬁguration; and energytotal =energyincr ement(load)+

energyaver age(d(load)), such that energyaverage(d(load)) = d(load)⇥0.1kW is the shared energy spent

by the cloud by time slot, and energyincrement (load)is the increment of energy result of resource usage.

security (risk of data exposition): s(load)=1pexposure (load), where pexposure(load)is the probability that

the load processing results in data exposure and s(load)is the trustability of the operation. The pexposure(load)is calculated

as 0.001 for each second of operation.

CO2emission:c=energytotal ⇥400, where energ ytotal was deﬁned in the accounting evaluation function and

400 is a constant which represents the grammes of CO2per kW .

TABLE VI: Evaluation functions for leaf nodes.

Types Declarations Deﬁnitions

performance maximum duration of loads sent for successor

nodes.

pv(w1,...,w

5,w

0

1,...,w

0

n)=max(w0

1[p],...,w

0

n[p]), where pv

represents the total time to process the incoming loads, and w0

n[p]represents

the speciﬁc part of in the node-weight of nsuccessor nodes, regards to the

duration to process the loads sent by the node v.

availability the product of the availability of successor nodes

according to the sent loads.

avv(w1,...,w

5,w

0

1,...,w

0

n)=Qw0

n[av], where avvrepresents the

total availability of a node vaccording its dependencies, and w0

n[av]represents

the availability part in node-weights of the successors of v, related to the loads

sent.

accounting the sum of costs relative to the sent loads for

successor nodes.

acv(w1,...,w

5,w

0

1,...,w

0

n)=Pw0

n[ac], where acvis the total cost

related to vand regards to the loads processed in the successors, and w0

n[ac]

is the accounting part of the successors’ node-weight.

security the product of security (regards to data exposition)

of successor nodes according to the sent loads.

sv(w1,...,w

5,w

0

1,...,w

0

n)=Qw0

n[s], where svrepresents the total

security measure of a node v, and w0

n[s]represents the security measure part

in node-weights of the successors of v, related to the loads sent.

CO2emission the sum of total emissions relative to the loads

sent to the successor nodes.

cv(w1,...,w

5,w

0

1,...,w

0

n)=Pw0

n[ac], where cvis the total CO2

emission associated with a node v, and w0

n[ac]is the node-weight part

associated with the emissions caused by the loads sent from v.

TABLE VII: Evaluation functions for non-leaf nodes.

Project

(Goals and some results):
Goal 1:
Cloud identity management: A survey on privacy strategies
https://www.researchgate.net/publication/316116828_Cloud_identity_management_A_survey_on_privacy_strategi…" [more]

Project

FIELD
Multidisciplinary, PTT Methods, PTT Applications, Gamification of a collaborative research
IN BRIEF
.The RG PTT Collaboration Pool Research Project will focus then on the process necessar…" [more]

Project

A smart contract is the formalisation of an agreement, whose terms, such as payment, confidentiality and quality, are automatically enforced by relying on a previously agreed transaction protocol. …" [more]

Article

Autonomic Cloud Computing management requires a model to represent the elements into the managed computing process. This paper proposes an approach to model the load flow through abstract and concrete cloud components using double weighted Directed Acyclic Multigraphs. Such model enables the comparison, analysis and simulation of clouds, which assist the cloud management with the evaluation of... [Show full abstract]

Conference Paper

The essential characteristics of Cloud computing are scalability, elasticity, and heterogeneous resource pooling. However, managing these systems is challenging due to their complexity and dynamism. Using Autonomic Computing to achieve self-management is a prominent approach to respond these challenges. The fundamental basis for the decision making process of such systems is the updated status... [Show full abstract]

Conference Paper

Cloud computing emerged in the last years as a novel approach to deal with computational resources. The amount of resources available seems infinite, resources are charged per use (usually by the hour), provisioning or releasing resources is performed on demand and quickly. In addition, everyday more and more features are included by cloud providers in their cloud services menu. These... [Show full abstract]

Data provided are for informational purposes only. Although carefully collected, accuracy cannot be guaranteed. Publisher conditions are provided by RoMEO. Differing provisions from the publisher's actual policy or licence agreement may be applicable.

This publication is from a journal that may support self archiving.

Learn more