Download full-text PDF

C2LP: Modelling Load Propagation and Evaluation through the Cloud Components

Conference Paper (PDF Available)  · February 2016with2,538 Reads
DOI: 10.13140/RG.2.1.3483.3682
Conference: Conference: ICN 2016 - The Fifteenth International Conference on Networks, At Lisbon, Portugal, Volume: 1
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.
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
IMT Institute for Advanced Studies Lucca, Italy
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 config-
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 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.
Keywords-Cloud Computing; Management; Simulation; Multi-
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
configurations and complex data flows, is challenging and is
still an open issue in the field. 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 flow
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 classified into two main groups: general models, usually
represented by the simulators; and specific models, devised
for a particular field (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 specific, 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 flow 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 flows 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 unifies 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 specifically, 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 configurations
over several quantitative behaviour in load propagation and
This article is organised as follows. Section II discusses the
existing cloud models, the works that inspired the definition
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.
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, define components
in distinct abstraction levels; compare structures; simulate be-
haviours and provide formal specifications with mathematical
background. Table I summarises this comparison.
We grouped the proposals into two classes: general and
specific. General models are usually associated with simulators
and are used to evaluate numerous criteria at the same time.
On the other hand, specific 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 first 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
On the other hand, the solutions in the second group, i.e.,
the ones specifically 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 fit well in integrated
management methods that intent to find optimal configurations
considering several criteria of distinct types. Moreover, specific
optimisation models usually are sensible to structural changes,
having no robustness to support the dynamic nature of the
The comparison between the related works is schematised
in the Table I, where: column “Class” specifies if a work is gen-
eral or specific; “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 flow” because it is one of the most important
information for managerial decisions, such as: load balance,
resource allocation, scale up/down and migrations.
This section discusses, the main components of cloud
structures and proposes a formal model based on a directed
acyclic multigraph, to represent the load flow in clouds.
Subsection III-A presents the structural model and its main
components. In Subsection III-B, we formally define the data
structures to represent loads,configurations,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] Specific ⌅ ⇤ ⌅ ⇤
uschel [11] Specific ⌅ ⇤ ⌅ ⇤
Nesmachnow [10] Specific ⌅ ⇤ ⌅ ⇤
Silva. [8] Specific ⌅ ⇤ ⇤ ⇤
Vilaplana [7] Specific ⌅ ⇤ ⌅ ⇤
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 defined 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 specification of the
consumer’s needs and, in this model, they are converted
into loads.
Directed edges in our model define 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 configurations 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 defines 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 simplifies 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 configuration of the node, the load defined 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 configuration and edge loads for the
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 Postfix). 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
financial 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
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=
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
v}and is a bijective function
:V!that maps each node for the respective
propagation function. Each function in the set is defined
as fv:Nn,Ri!Ro, where: the set Nnrepresents the
space where the n-tuple for the configuration; 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 configurations are stored in the node-weight, such
that wconf
vrepresents the configuration 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
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)), where:
nis the n-tuple with the configuration 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
such that each set 0
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
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
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
config. part of the node-weight (state).
11: wi
v (w1,v,w
u,v).builds the
incoming edge-weights in a tuple wi
12: wo
v fv(wconf
vcontains the result of
the propagation function.
13: for each wv,u 2wo
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-first algorithm used for the load
uv)); where w0
vis the new
node-weight of v,c1,...,c
nis the n-tuple with the
configuration part wconf
vof the node-weight, wi
vis the
n-tuple with the incoming edge-weights e,v of v, and
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-first approach. In a breadth-first algo-
rithm, the loads are propagated to the neighbours nodes before
moving to the next level nodes. In the specific 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 define all edge-weights for the outgoing edges
of v. This procedure is repeated while the queue is not empty.
The well defined 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 specific 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 finer description can be defined
as: w0
such that w0
vrepresents the a posteriori state for the node
vare the configurations (a priori state) of v,wi
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-first
The evaluation in the resources occurs according to several
models that converts the configuration, 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
such that w0
vrepresents the new node-weight (a posteriori
state) for the node v,wconf
vare the configuration 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-first computation.
The first 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.
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 exemplifies 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
As use case, we defined a IaaS service where consumers
perform five 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-
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
config. part for v.
14: wi
v (w1,w
u,v).builds the n-tuple
with the incomings of v.
15: if isLeaf(v)then
16: w0
v (wconf
.computes the partial states and builds
the new node-weight.
17: else
18: w0
uv (w0
builds the computed node-weights for all
u|9ev,u 2E.
19: w0
v (wconf
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-first algorithm to evaluate in specific metrics
the impact of the load in each node.
figurations related to load distribution over the cloud elements,
in order to evaluate the average utility for all quantitative
scenarios. At end, the configurations which achieve the best
average utility for all quantitative scenarios were highlighted,
depicting the ability of the model to simulate configuration
consequences for purposes of to select configurations.
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
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
Besides the node and the edges, the use case model
required the definition of: 4types of propagation functions
– one for the service and tree for each type of system; 6
types of leaf evaluation functions – two specific 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 configurations 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 configurations to
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 configurations 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 Configuration
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
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 fifty two numerical experiments
are presented in the Table II in ascendant ordering, where the
configuration that achieve the best average utility is highlighted
as bold. The code line in the table represents the propagation
configuration, whereas the other lines contains the values got
for each distinct evaluation type. In the last row is presented
the average utility defined in Equation 1. To represent config-
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
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 flexibility of general models and
the formalism of the specifics. Therefore, C2LP is a flexible
well-formed modelling tool to express flow of loads through
the cloud components. This model supports the specification
of elements in distinct abstraction levels, the generation of
combinatorial variations in a use case modelling and the
evaluation of the consequences of different configuration 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 configurations and, as a result, supplied the
cloud managers with a numeric comparison of cost and benefits
of each configuration. These experiments, demonstrated that
this tools provides an essential support for the management of
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).
[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
[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,
“Efficient heuristics for profit optimization of virtual cloud brokers,
Computational Intelligence Magazine, IEEE, vol. 10, no. 1, 2015, pages
[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–
[15] Alberto N ´
nez et al., “iCanCloud: A flexible 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] Toufik Mansour, “Combinatorics of Set Partitions,” CRC Press, 2012.
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.
! 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
! 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.
Balancer Cloud
Manager 2
Manager 1
Server 1
Server 2
Server 11
Server 12
Server 13
Server 21
Server 22
Server 23
Figure 4: Graphical representation of structural arrangement for the modelling use case.
Types Declarations Definitions
service (w1,··· ,w
7! (w0
1,··· ,w
5).wnis the weight for n
! CS).
nis the weight for (CS n
! LB).
balancer (c1,...,c
1,··· ,w
cn2{CM1,CM2}, are the configurations which represent the targets of
each load wn|16n65.
n=wnif cn=CM1
n+5 =wnif cn=CM2
1>n>5, are the weights in the edges LB 5
! CM1.
6>n>10, are the weights in the edges LB 5
! CM2.
11 =1Gf lop, is the a constant computing load in LB!MS1.
12 =1Gf lop, is the a constant computing load in LB!MS2.
13 =50GB, is the a constant storage load in LB!MSTO.
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
1,··· ,w
cn2{CPm1,CPm2,CPm3}, are the configurations which represent
the targets of each load wn|16n65.
n=wnif cn=CPm1
n+5 =wnif cn=CPm2
n+10 =wnif cn=CPm3
16 =1Gf lop, is the a constant computing load in CMn!MSn.
17 =50GB, is the a constant storage load in CMn!MSTO.
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
7! (w0
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.
2and w0
3are, respectively, the edge-weight for the arcs CPnn!WSnn,
CPnn!WSTO and CPnn!PN, where:
TABLE V: Propagation functions.
Types Functions
computing specific 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 specific 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)=d0.01.
accounting:ac(load)=priceenergy energ ytotal, where priceenerg y is a constant of 0.38US$/kW
or 0.58US$/kW , depending on node configuration; 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 defined 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 Definitions
performance maximum duration of loads sent for successor
n[p]), where pv
represents the total time to process the incoming loads, and w0
the specific 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.
n[av], where avvrepresents the
total availability of a node vaccording its dependencies, and w0
the availability part in node-weights of the successors of v, related to the loads
accounting the sum of costs relative to the sent loads for
successor nodes.
n[ac], where acvis the total cost
related to vand regards to the loads processed in the successors, and w0
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.
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.
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.
(Goals and some results): Goal 1: Cloud identity management: A survey on privacy strategies…" [more]
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]
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]
    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
    May 2014
      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
      November 2012
        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]
        Discover more