University of Pisa and Scuola Superiore Sant’Anna
MSc in Computer Science and Networking
Resource-aware
Management Protocols for
Composite Cloud Applications
Candidate
Supervisors
Stefano Russo
Antonio Brogi
Jacopo Soldani
iii
Abstract
Management protocols [1] permit specifying the behaviour of management operations of multi-component applications. The goal of this thesis is to propose an extension of management protocols to model and analyse composite cloud application by taking into account resource consumption metrics based on cost models for IaaS. After analysing some recent research efforts detailing resource utilisation in IaaS, we define a resource-aware extension of management protocols that permits specifying and analysing the amount of resources needed to manage (the components of) a TOSCA application.
iv
Contents
Abstract ... iii Chapter 1 Introduction ... 1 Chapter 2 Background ... 4 2.1 TOSCA ... 42.2 Management Protocol for Cloud Applications ... 5
2.2.1 Definition of Management Protocols ... 6
2.2.2 Analysis of Management Protocols ... 7
Chapter 3 Motivating Scenario ... 10
3.1 The application Thinking... 10
v
Chapter 4
Resource Utilisation and Costs in IaaS ... 17 4.1 Existing Approaches for Estimating Resources Utilisation in IaaS ... 18 4.2 Summary View and Metrics we will Consider ... 22
Chapter 5
Resource-aware Management Protocols ... 26 5.1 Definition of Resource-aware Management Protocols ... 27 5.2 Analysis of Resource-aware Management Protocols ... 31
Chapter 6
Conclusions ... 38
vi
List of Figures
Figure 1: TOSCA Service Template [4]. ... 4
Figure 2: Topology of the Thinking application [5]. ... 11
Figure 3: Management protocol for Mongo's node type. ... 12
Figure 4: Management protocol for nodes of type Docker. ... 12
Figure 5: Management protocol for ThoughtsAPI's node type. ... 13
Figure 6: Management protocol for ThoughtsGUI's node type... 15
Figure 7: Two examples of Plans. ... 16
Figure 8: Application provisioning model using IaaS interface [7]. ... 18
Figure 9: Resource-aware management protocol for Maven’s node type. ... 28
Figure 10: Resource-aware management protocol for Node’s node type. ... 29
Figure 11: Resource-aware management protocol for Mongo’s node type. ... 29
Figure 12: Resource-aware management protocol for ThoughtsAPI’s node type. ... 30
Figure 13: Resource-aware management protocol for ThoughtsGUI’s node type. ... 30
Figure 14: Capacity evaluation and resource utilisation of Plan (a) in Fig.7. ... 34
1
Chapter 1
Introduction
Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resource that can be rapidly provisioned and released with minimal management effort or service provider interaction. This kind of computing model allows to serve a wide range of consumers, from personal users who need a small virtual disk, to large enterprise users who outsource processing and storage on a large-scale [2]. For instance, Infrastructure-as-a-Service (IaaS) providers offer processing, storage, network and other fundamental computing resources that customers can rent to deploy their applications. The objective of this master thesis is to propose an approach to analyse the management of composite cloud applications, which also takes into account the IaaS resource utilised while managing such applications. More precisely, the thesis’ goal is to permit determining the amount of resources required to perform sequential/workflow plans coordinating the management of a composite cloud application, as well as to permit checking whether such management plans exceed the amount of IaaS resources actually available for an application (e.g., the actual amount of resources rented from a cloud provider).
TOSCA (Topology and Orchestration Specification for Cloud Application [3] permits describing the structure of a cloud application as a typed, directed topology graph, whose nodes represents application components, and whose arcs represents dependencies among such components. Each node of a topology can also be associated with the corresponding
2
component’s requirements, the operations to manage it, the capabilities it features, and the policies applied to it.
Management protocols [1] are an extension of TOSCA that permits specifying the management behaviour of the nodes in an TOSCA application topology. The management behaviour of each node is specified as a finite state machine, whose states and transitions are associated with conditions defining the consistency of the states of the node and constraining the executability of its management operations. Such conditions are defined on the requirements of a node, and each requirement of a node has to be fulfilled by a capability of another node. As a consequence, the management behaviour of a composite application can be easily derived by composing the management protocols of its nodes according to the dependencies defined in its topology.
Unfortunately, in their current version, TOSCA and management protocols do not permit indicating which/how much IaaS resources are needed to stay in a certain configuration of a composite application or to execute a management plan changing the actual configuration of an application. For this reason, we propose a resource-aware extension of management protocols that allows specifying the resources needed to manage composite cloud applications. Resource-aware management protocols will permit describing which/how much resources are needed by each application component (when it is in a state and when it is performing a management operation), as well as to determine which/how much resources are needed by a whole application (to reside in a certain configuration, or to execute a management plan changing its actual configuration).
In this perspective, the first phase of our work was devoted to analysing some recent research efforts dealing with resource management in IaaS platforms. We analysed state-of-the-art approaches modelling resource utilisation, with a particular focus on the resources they model, and the parameters they use to meter such resources. At the end of this phase, we identified a set of resources (viz., computation, memory storage, network) and a set of metrics which should be considered when modelling and analysing resource utilization.
The second phase of our work was devoted to defining a resource-aware extension of management protocols. We indeed extended management protocols to permit describing the amount of computation, memory, storage and network utilised by an application component (both when it resides in a state and when it is performing a management operation). We then
3
correspondingly extended the way management protocols are combined, hence allowing to automate several analyses concerning the resource utilisation of whole TOSCA applications (e.g., determining the maximum amount of resources needed to execute a management plan, or checking whether a management plan is feasible – meaning that it does not exceed a given amount of available resources).
The rest of this thesis is organized as follows. Chapter 2 provides the necessary background on TOSCA and management Protocols. Chapter 3 illustrates a motivating scenario that further motivates the needs of a resource-aware extension of management protocols. Chapter 4 describes some research efforts dealing with resource management in IaaS. Chapter 5 discusses how management protocols can be extended to model the resource utilisation aspects, and how the proposed extension permits to automate the above mentioned analyses. Chapter 6 draws some concluding remarks and discusses future work.
4
Chapter 2
Background
2.1 TOSCA
TOSCA [4] is an emerging standard whose main goal is to enable the creation of portable cloud applications and the automation of their deployment and management. It aims at addressing the following three issues in cloud application management: (i) automated application deployment and management, (ii) portability of application description and their management, and (iii) interoperability and reusability of components. Each cloud application is represented as a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒, which is composed by 𝑇𝑜𝑝𝑜𝑙𝑜𝑔𝑦𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 and of optional management Plans.
5
The 𝑇𝑜𝑝𝑜𝑙𝑜𝑔𝑦𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 is essentially a typed graph describing the structure of the composite cloud application, whose nodes (𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒) represent the application components, while whose edges (𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠ℎ𝑖𝑝𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒𝑠) model the relation between these application components. The availability of an abstract topology description is necessary to achieve the goal of automating the deployment of an application. Each application component appears in the topology as a 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 that is in turn typed by means of 𝑁𝑜𝑑𝑒𝑇𝑦𝑝𝑒𝑠. The purpose of 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 is to define application-specific features of components like property values or QoS, while 𝑁𝑜𝑑𝑒𝑇𝑦𝑝𝑒 defines (i) the observable properties of an application component, (ii) the possible states of its instances, (iii) its requirements, (iv) the capabilities it offers to satisfy other component's requirements, and (v) its management operations. 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠ℎ𝑖𝑝𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 defines the structure of a generic relationship between source and target components and it is in turn typed by means of 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠ℎ𝑖𝑝𝑇𝑦𝑝𝑒𝑠. 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠ℎ𝑖𝑝𝑇𝑦𝑝𝑒𝑠 describe the properties of relationship occurring among components. 𝑃𝑙𝑎𝑛𝑠 specify the deployment and/or the management aspects of an application. Each Plan allows to express higher level of management utilizing a workflow that models the management operations offered by the nodes in the topology, hence allowing to describe the management of the whole cloud application.
2.2 Management Protocol for Cloud Applications
Management protocols [1] are an extension of TOSCA that permits to determine the behaviour of management operations and their relations with states, requirements and capabilities. In particular, they give a formal way to specify how management operations affect states, how operations or states depend on requirements, or which capabilities are concretely provided in a certain state. Management protocol describe TOSCA components by means of finite state machines whose states and transitions are associated with conditions on the components' requirements and capabilities. This extension permits to automate useful analyses, like determining the validity of a management plan or which plans reach certain system configuration.
6
2.2.1 Definition of Management Protocols
Let 𝑁 be a TOSCA 𝑁𝑜𝑑𝑒𝑇𝑦𝑝𝑒, and let us denote its states, requirements, capabilities, and management operations with 𝑆𝑁, 𝑅𝑁, 𝐶𝑁, and 𝑂𝑁, respectively. Management protocols [1] permit modelling the management behaviour of 𝑁 by describing whether and how the management operations of 𝑁 depend (i) on other operations of the same node, and/or (ii) on operations of other nodes providing the capabilities that satisfy the requirements of 𝑁.
(i) The first kind of dependencies is described by specifying relationships between states and management operations of 𝑁. More precisely, to describe the order in which the operations of 𝑁 can be executed, a transition relation 𝜏 specifies whether an operation 𝑜 can be executed in a state 𝑠, and which state is reached by executing 𝑜 in 𝑠.
(ii) The second kind of dependencies is described by associating transitions and states with sets of requirements to indicate that the corresponding capabilities are assumed to be provided. More precisely, the requirements associated with a transition 𝑡 specify which are the capabilities that must be offered to allow the execution of 𝑡. Instead, the requirements associated with a state of 𝑁 specify which capabilities must (continue to) be offered by other nodes in order for 𝑁 to (continue to) work properly.
To complete the description, each state 𝑠 of 𝑁 is associated with the capabilities provided by 𝑁 in 𝑠.
Definition 2.1. Let 𝑁 = 〈𝑆𝑁, 𝑅𝑁, 𝐶𝑁, 𝑂𝑁, 𝑀𝑁〉 be a 𝑁𝑜𝑑𝑒𝑇𝑦𝑝𝑒, where 𝑆𝑁, 𝑅𝑁, 𝐶𝑁, and 𝑂𝑁 are the sets of its states, requirements, capabilities, and management operations. 𝑀𝑁= 〈𝑠̅𝑁, 𝜌𝑁, 𝜒𝑁, 𝜏𝑁〉 is the management protocol of 𝑁 where
- 𝑠̅𝑁 ∈ 𝑆𝑁 is the initial state,
- 𝜌𝑁 : 𝑆𝑁 → 2𝑅𝑁 is a function indicating, for each state 𝑠 ∈ 𝑆𝑁, which conditions on the requirements of 𝑁 must hold,
- 𝜒𝑁 ∶ 𝑆𝑁→ 2𝐶𝑁 is a function indicating which capabilities are concretely offered by 𝑁 in each state 𝑠 ∈ 𝑆𝑁,
7
- 𝜏𝑁⊆ 𝑆𝑁 𝑥 2𝑅𝑁 𝑥 𝑂𝑁 𝑥 𝑆𝑁 is a set of quadruple modelling the transition relation (i.e., 〈𝑠, 𝐻, 𝑜, 𝑠′〉 ∈ 𝜏𝑁 means that in state 𝑠, and if condition 𝐻 holds, o is executable and
leads to state 𝑠′). □
Management protocols (as per Definition 2.1) allow operations to have non-deterministic effects (e.g., a state may have two outgoing transitions corresponding to the same operation and leading to different states). This form of non-determinism is not acceptable when managing TOSCA applications. The analysis presented below (and in Antonio Brogi et al. [1]) focuses on deterministic management protocols (i.e., protocols ensuring deterministic effects when performing an operation in a state).
Definition 2.2. Let 𝑁 = 〈𝑆𝑁, 𝑅𝑁, 𝐶𝑁, 𝑂𝑁, 𝑀𝑁〉 be a 𝑁𝑜𝑑𝑒𝑇𝑦𝑝𝑒. The management protocol 𝑀𝑁= 〈𝑠̅𝑁, 𝜌𝑁, 𝜒𝑁, 𝜏𝑁〉 is deterministic if and only if
∀〈𝑠1, 𝐻1, 𝑜1, 𝑠1′〉, 〈𝑠
2, 𝐻2, 𝑜2, 𝑠2′〉 ∈ 𝜏𝑁∶ (𝑠1 = 𝑠2 ∧ 𝑜1 = 𝑜2) ⇒ 𝑠1′ = 𝑠2′.
□
2.2.2 Analysis of Management Protocols
This section describes different analyses that can be performed on the management protocols of a TOSCA application (e.g., checking the validity of a 𝑃𝑙𝑎𝑛, determining its effects, or discovering 𝑃𝑙𝑎𝑛𝑠 that allow to reach certain system configurations), which were first presented in [1].
Formally, the semantics of the management protocol of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 is defined by a labelled transition system over configurations that denote the states of the 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒𝑠 of 𝑆. The transition
𝐺〈𝑜,𝑁→ 𝑖〉𝑆𝐺′
denotes that operation 𝑜 can be executed on 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁𝑖, when the global state of 𝑆 is 𝐺, making 𝑆 evolve into new global state 𝐺′.
Below the formal definition of global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 is reported, which also introduces a shorthand notation to denote the capability connected to a requirement in a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒.
8
Definition 2.3. A global state of 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 is denoted by a set
{(𝑁1, 𝑠1), … , (𝑁𝑚, 𝑠𝑚)}
where 𝑁1, . . . , 𝑁𝑚is the set of 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 in 𝑆, and where 𝑠𝑖 is a state of 𝑁𝑖 (viz. 𝑠𝑖 ∈ 𝑆𝑁𝑖).
We denote by 𝐺̅ the initial global state of 𝑆 in which each 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 is in its initial state (𝐺̅ = {(𝑁1, 𝑠̅1), … , (𝑁𝑚, 𝑠̅𝑚)}).
We also denote by 𝑐𝑎𝑝𝑆(𝑟) the (partial) function associating a requirement 𝑟 with the
capability connected to 𝑟 in 𝑆 by means of a 𝑅𝑒𝑙𝑎𝑡𝑖𝑜𝑛𝑠ℎ𝑖𝑝𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒. □
Now it is possible to formally define the semantics of the management protocols in a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆. The management operation 𝑜 can be executed on a 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁𝑖, only if all the requirements needed by 𝑁𝑖 to perform 𝑜 are satisfied by the capabilities provided by (other) 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒𝑠 in 𝑆.
Definition 2.4. The semantics of the management protocols in a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 is
modelled by a transition system whose configurations are the global states of 𝑆, and where the transition relation is defined by the following inference rule:
𝐺 ={(𝑁1, 𝑠1), … , (𝑁𝑖, 𝑠𝑖), … , (𝑁𝑚, 𝑠𝑚)} 𝐺′ ={(𝑁1, 𝑠1), … , (𝑁𝑖, 𝑠𝑖′), … , (𝑁𝑚, 𝑠𝑚)} 〈𝑠𝑖, 𝐻, 𝑜, 𝑠𝑖′〉 ∈ 𝜏𝑁𝑖 ∀𝑟 ∈ 𝐻 ∶ 𝑐𝑎𝑝𝑆(𝑟) 𝑖𝑠 𝑑𝑒𝑓𝑖𝑛𝑒𝑑 ∧ 𝑐𝑎𝑝𝑆(𝑟) ∈ ⋃ 𝜒𝑁𝑗(𝑠𝑗) 𝑚 𝑗=1 𝐺〈𝑜,𝑁→ 𝑖〉𝑆𝐺′ □
This definition permits to model the evolution of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 when a sequence of management operations is executed:
𝐺0〈𝑜→ 1,𝑁𝑖1〉𝑆𝐺1→ 〈𝑜2,𝑁𝑖2〉𝑆… 〈𝑜→ ℎ,𝑁𝑖ℎ〉𝑆𝐺ℎ.
It is worth observing that while Definition 2.4 checks that the requirements needed by a 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁𝑖 to perform an operation 𝑜 are satisfied by the capabilities provided by the (other) 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒𝑠 in 𝑆, it does not check whether after performing 𝑜 the requirements assumed by (the states of) all 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒𝑠 will continue to be satisfied. The following notion introduce the notion of consistent global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒.
9
Definition 2.5. A global state {(𝑁1, 𝑠1), … , (𝑁𝑚, 𝑠𝑚)} of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 is consistent if
and only if
∀𝑖 ∈ {1. . 𝑚}, ∀𝑟 ∈ 𝜌𝑁𝑖(𝑠𝑖) ∶ 𝑐𝑎𝑝𝑆(𝑟) 𝑖𝑠 𝑑𝑒𝑓𝑖𝑛𝑒𝑑 ∧ 𝑐𝑎𝑝𝑆(𝑟) ∈ ⋃ 𝜒𝑁𝑗(𝑠𝑗) 𝑚
𝑗=1 .
□
Definition 2.4 and 2.5 allow to formally characterise the validity of a sequence of management operations.
Definition 2.6. A sequence 𝑜1𝑜2 . . . 𝑜𝑛 of management operations is valid from a global state 𝐺0 of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 if and only if:
𝐺0〈𝑜→ 1,𝑁𝑖1〉𝑆𝐺1→ 〈𝑜2,𝑁𝑖2〉𝑆… 〈𝑜→ 𝑛,𝑁𝑖𝑛〉𝑆𝐺𝑛
and each 𝐺𝑖 is a consitent global state. □
The validity of a TOSCA 𝑃𝑙𝑎𝑛 descends immediately from Definition 2.6.
Definition 2.7. Let 𝐺 be a global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆. A 𝑃𝑙𝑎𝑛 𝑃 for 𝑆 is valid from 𝐺
if and only if all its sequential traces are valid in 𝐺. □
It is possible that check validity of 𝑃𝑙𝑎𝑛𝑠 may not be enough, as their sequential traces may reach different global state, hence it is also interesting characterize deterministic 𝑃𝑙𝑎𝑛𝑠.
Definition 2.8. Let 𝐺 be a global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆. A valid 𝑃𝑙𝑎𝑛 𝑃 for 𝑆 is
deterministic from 𝐺 if and only if all its sequential traces reach the same global state 𝐺′. □
It is also interesting to compute the effects of a valid 𝑃𝑙𝑎𝑛 𝑃 on the states of the components of a TOSCA 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒, as well as on the requirements that are satisfied and the capabilities that are available. Such effects can be directly determined from the global state(s) reached by performing the sequential traces of 𝑃. Moreover, the problem of finding whether there is a deployment 𝑃𝑙𝑎𝑛 which starts from the initial global state 𝐺̅ and achieves a specific goal (e.g., bringing some components of an application to specific states or making some capabilities available) can be solved with a breadth-first search of the reachable global states. The same approach also works in the case of generic management plans (i.e., plans starting from a generic global state 𝐺) and it permits to find the sequential 𝑃𝑙𝑎𝑛𝑠 (if any) allowing to reach a certain goal from whatever starting 𝐺.
10
Chapter 3
Motivating Scenario
3.1 The application Thinking
Consider the web application Thinking [5] that allows end-users to share what they are thinking about, so that all other users can read it. Fig.2 illustrates the topology of such application, represented in TOSCA [6]. Thinking is composed by three main components:
- 𝑀𝑜𝑛𝑔𝑜, an instance of MongoDB that is exploited to permanently store the collection of thoughts shared by end-users,
- 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼, which is a Dropwizard-based REST API that permits remotely accessing the collection of shared thoughts, and
- 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼, which is a web-based graphical user interface that interacts with 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 to permit retrieving and adding thoughts to the shared collection.
11
Figure 2: Topology of the Thinking application [5].
We provide below some additional details about the components forming the topology of the
Thinking application.
𝑀𝑜𝑛𝑔𝑜
𝑀𝑜𝑛𝑔𝑜 offers a MongoEndpoint capability (that is used to satisfy the corresponding requirement of 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼), and a property that permits specifying how to map the ports of the container onto the ports of the host. It also offers the operations to Run, Create, Start,
Stop and Delete the container.
The management protocol of 𝑀𝑜𝑛𝑔𝑜 is illustrated in Fig. 3. Its initial state is
Unavailable, where 𝑀𝑜𝑛𝑔𝑜 is not providing any capability and where it can perform Run or Create to become Running or Stopped, respectively. 𝑀𝑜𝑛𝑔𝑜 can transit from its Stopped
state to its states Running or Unavailable by executing the operations Start or Delete, respectively. From the Running state, 𝑀𝑜𝑛𝑔𝑜 can return to be Stopped by executing the operation Stop. States Unavailable and Stopped are not associated with any requirement or capability. State Running instead specifies that, in such state, 𝑀𝑜𝑛𝑔𝑜 continues to provide its
12 Unavailable Running Stopped R:{} C:{} R:{} C:{MongoEndp} R:{} C:{} {} {} Run {} {} Start {} {} Stop {} {} Delete {} {} Create
Figure 3: Management protocol for 𝑀𝑜𝑛𝑔𝑜's node type.
𝑀𝑎𝑣𝑒𝑛 and 𝑁𝑜𝑑𝑒
𝑀𝑎𝑣𝑒𝑛 and 𝑁𝑜𝑑𝑒 are both of type Docker and their structure is similar to that of 𝑀𝑜𝑛𝑔𝑜. They offer a capability to satisfy the requirements of other components, a property for specifying the port mappings, and their management operations are Run, Create, Start, Stop, and Delete. Unavailable Running Stopped R:{} C:{} R:{} C:{Container} R:{} C:{} {} {} Run {} {} Start {} {} Stop {} {} Delete {} {} Create
13
As illustrated by Fig. 4, the management protocol of 𝑀𝑎𝑣𝑒𝑛 and 𝑁𝑜𝑑𝑒 is also analogous to that of 𝑀𝑜𝑛𝑔𝑜, with the only difference that 𝑀𝑎𝑣𝑒𝑛 and 𝑁𝑜𝑑𝑒 continue to provide the Container capability in their Running state (instead of the MongoEndpoint capability offered by 𝑀𝑜𝑛𝑔𝑜).
𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼
𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 is a Dropwizard application, which offers a REST API as a resource on a given port. Such information can be specified with dedicated properties. 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 also offers an APIEndpoint capability (that is used to satisfy the corresponding requirement of 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼), and the set of management operations implementing its lifecycle. It also requires a MavenContainer where to be installed, and a MongoEndpoint where to connect.
R:{} C:{} Uninstalled Installed R:{} C:{} Configured R:{MongoEndp} C:{} Working R:{MavenCont, MongoEndp} C:{ApiEndp} {MavenCont} {} Setup {MavenCont, MongoEndp} {} Configure {MavenCont, MongoEndp} {} Run {MavenCont, MongoEndp} {} Stop {MavenCont, MongoEndp} {} Configure {MavenCont} {} Uninstall {MavenCont} {} Uninstall
Figure 5: Management protocol for 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼's node type.
The management behaviour of 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 is displayed in Fig. 5. Its states are
Uninstalled (initial), Installed, Configured, and Working. States Uninstalled and Installed are
not associated with any requirement or capability, while states Configured and Working specify that the capability corresponding to the MongoEndpoint requirement must continue to be provided in order for 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 to continue to work properly. State Working also
14
specifies that the capability corresponding to the MavenContainer requirement must continue to be provided, and that 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 continues to provide the APIEndpoint capability when in such state. Finally, all transitions bind their executability to the availability of the capability that satisfies the MavenContainer requirement. Configure, Run, and Stop bind their executability also to the availability of the capability that satisfies MongoEndpoint requirement.
𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼
𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼 is a web-application offering a web-based GUI for connecting to the Thinking application. 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼 can be reached at a given port, which can be specified through the dedicated property, and it offers the operations to manage its lifecycle. To effectively run, it also requires a container where to be installed and the endpoint of the API where to connect to (through its requirements NodeJSContainer and APIEndpoint, respectively).
The management protocol of 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼 is illustrated in Fig. 6. Its states are
Uninstalled (initial), Installed, Configured, Running, and Working. States Uninstalled and
Installed are not associated with any requirement or capability, while states Running,
Configured, and Working specify that the capabilities corresponding to the indicated
requirements must continue to be provided in order for 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼 to continue to work properly. All transitions bind their executability to the availability of the capability that satisfies the NodeJSContainer requirement. The transition targeting or outgoing from Working bind their executability also to the availability of the capability that satisfies APIEndpoint requirement.
15 R:{} C:{} Uninstalled Installed R:{} C:{} Configured R:{MongoEndp} C:{} Working R:{MavenCont, MongoEndp} C:{ApiEndp} {NodeJSCont} {} Setup {NodeJSCont, APIEndp} {} Configure {NodeJSCont} {} Uninstall {NodeJSCont} {} Uninstall {NodeJSCont} {} Run Running R:{NodeJSCont} C:{} {NodeJSCont,APIEndp} {} Configure {NodeJSCont, APIEndp} {} Run {NodeJSCont, APIEndp} {} Stop {NodeJSCont, APIEndp} {} Configure {NodeJSCont, APIEndp} {} Configure
Figure 6: Management protocol for 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼's node type.
3.2 Understanding Thinking’s resource utilisation
Suppose now that we wish to deploy the application Thinking [5] on an IaaS Cloud, and that we wish to understand which/how much resources are needed by its components. TOSCA [3] permits describing the topology of the application Thinking, and management protocols [1] permit specifying the management behaviour of each of its application component. The latter is enough to check the validity of deployment/management 𝑃𝑙𝑎𝑛𝑠, but it is currently not possible to model and analyse the resources needed to actually enact such 𝑃𝑙𝑎𝑛𝑠. This means that it is not possible to compare valid 𝑃𝑙𝑎𝑛𝑠 based on resource utilisation (to pick the “best” one), nor to check whether the execution of a 𝑃𝑙𝑎𝑛 requires more resources than those actually available.
16 (a)
(b)
Figure 7: Two examples of 𝑃𝑙𝑎𝑛𝑠.
Consider, for instance, the two deployment 𝑃𝑙𝑎𝑛𝑠 in Fig. 7, which are both valid (according to Definition 2.7). How much resources are needed to execute each 𝑃𝑙𝑎𝑛? Which 𝑃𝑙𝑎𝑛 is “better” (in terms of resource utilisation)? Are both 𝑃𝑙𝑎𝑛𝑠 “feasible” (viz., executable without exceeding the amount of resources rented/available)?
The above-mentioned analyses can be performed manually, by executing each 𝑃𝑙𝑎𝑛 and by metering the resources it utilises. This is however a time-consuming and error-prone process, which must be repeated whenever a component is changed or a new component is added to the application topology (as any change in an application may result in changing its resource utilisation).
Our objective is instead to permit automatically determining the resources need to execute a 𝑃𝑙𝑎𝑛, and to check whether such 𝑃𝑙𝑎𝑛 is feasible. A solution is to extend management protocols to provide a compositional modelling of the resource utilisation of each component in an application, hence allowing to automatically analyse the resource utilisation of (𝑃𝑙𝑎𝑛𝑠 managing) such application.
17
Chapter 4
Resource Utilisation and Costs in IaaS
The objective of this chapter is to provide an overview of the challenging topic of resource management in Infrastructure-as-a-Service (IaaS) cloud environments [7]. After a brief introduction, we analyse some recent research efforts concerning resource utilisation models in IaaS platforms, and we try to identify the most significant metrics for resource utilisation. We then summarize the result of our analysis, and we identify a set of resource consumption metrics to be included in management protocols.
Managing resources in a cloud environment is a hard problem due to the scale of modern data centers, the heterogeneity of resource types and their interdependencies, the variability of the load [8]. In the context of IaaS, the key challenge of this problem is understood as the process of determining the amount of resources that cloud-based applications need during their life-cycle operations, with the goal of reducing resource waste and achieving the best possible performances [7]. At any time, resources need to be allocate to effectively handle workload fluctuation since continuous changes occur autonomously and unpredictably, while providing QoS to the end users.
Following Michael Ambrust et al. [9] we assume the presence of three “actors” in a cloud environment: Cloud Provider, Cloud User, End User. From a cloud resource management perspective, these roles can be outlined as follows. A Cloud Provider manages the hardware infrastructure and she is responsible of their correct allocation in order to meet SLA agreed with Users. A Cloud User uses clouds to host applications and she is responsible of meeting SLA with her costumer. End Users generate workloads that are processed using IaaS resources;
18
they do not play a direct role but their behaviour influences the management decision of the previous two “actors”.
Figure 8: Application provisioning model using IaaS interface [8].
Available resources must be managed in the best possible way, meaning that user can deploy and execute her application by obtaining the desired performances and consuming the least amount of resources (as cloud platform follow a pay-per-use pricing model). Measuring resources and service consumption is hence fundamental, both for Cloud providers (who rent out resources) and for Cloud users (who pay rented resources).
4.1 Existing Approaches for Estimating Resources Utilisation in IaaS
This section discusses some state-of-the-art cost models related to Infrastructure-as-a-Service environment. In IaaS Cloud, the end user is offered a virtualized environment (Virtual Machine instances) that mainly comprises CPU, memory, storage and network resources. Through careful analysis of some proposed cost models, we aim at identifying the main physical and logical resources that are involved in the execution process of an application in an IaaS architecture and how these are modelled through a set of parameters. Our goal is to choose some metrics that address the previously discussed resource management problem, and use
19
them in the next chapter to extend management protocols with the concept of resource utilization.
We now present some of these works dealing with VM energy consumption issues and storage device characteristics, with the goal of providing a more detailed view of how the individual components are studied in the virtual environment. Power metering becomes a topic of interest for the rapidly growing of cloud infrastructure, in this context, reducing the amount of energy consumed by computing resources not only results in a reduction in the operating costs of data centers, but also has a positive effect on the environment. The main resources that have a considerable impact on power consumption model are cpu, memory banks, disk arrays and network cards.
Among the possible approaches proposed to model the cost of virtual machine hosting, Aman Kansal et al. [10] propose a power models to infer power consumption from resource usage at runtime, identifying challenges that arise when applying such models to VM power metering. The cpu consumption may depend on various factors such as active subunits, specific instruction executed, on-chip cache usage and frequency used. Memory is the second most important physical resource that has a considerable impact on the total energy consumption, in particular to correct estimate the memory usage it is necessary to take into account the read and write throughput. The storage system is considered one of the main bottleneck in computer system performance responsible of 14% of the overall consumed energy in virtualized environment, hence observe the number of bytes read and written to represents the energy consumed by disk over a time period considered.
Selome Tesfatsion et al. [11] present a resource management framework that aim to reduce energy consumption of servers by both VM resizing (CPU and memory) and physical CPU frequency scaling. The performance model describes the relationship between an application's resource allocation and its performance. The power model of this work describes a relationship between resource allocation and power usage of a server, considering processor and memory the two largest consumers of power in today's servers. Once defined these two model it is possible to shape the optimal reconfiguration, if any, to minimize power consumption and meet performance target. The new configuration, based on application performance goal, may result in changes in cpu frequency, number of cores and memory allocation.
20
The storage analysis it is not considered by Selomone Tesfatsion et al. [11], as well as by Pedro Castroa et al. [12]which study the considerable impact that RAM can have on the total energy consumption, particularly in data centers with large amounts of this memory, showing that the energy consumption increases as a function of the amount of RAM. Traditionally the common strategy consists in reducing the consumption of a single type of resource like cpu, but the rapid growing of multi-core architectures has forced servers to have large amount of random-access-memory, leading to the situation where power consumed by RAM has become non-negligible, as already noted in the past by Kevin Lim at al. [13].
Other approaches addressing VMs energy consumption without considering the impact of storage and network devices are those proposed by Maxime Colmant et al. [14] and by Bhavani Krishnan et al. [15].
As pointed out in some of the approaches studied, storage is considered one of the most difficult model to study due to the lack of accurate analysis of power states and the impact of disk's hardware caches. Several works have attempted to propose cost models for storage devices considering energy consumption and storage device wear out, but unfortunately some of them are difficult to apply on VMs.
Zhichao Li et al. [16] introduce in the storage analysis problem other characteristics, in addition to performances, that becomes relevant like energy efficiency and durability. The cost model illustrates the importance of costs perspective as well as performances, evaluating the system under a variety of workloads and parameters.
Yan Li et al. [17] consider that power of devices alone cannot reflect the energy consumption analysis. Existing studies on storage mainly focused on the power consumption without paying enough attention to the amount of work required by I/O workload. The capability workloads require the storage system to provide a specific amount of I/O bandwidth/IOPS/latency. The cost model proposed consider each category of workloads and allow detection of most energy efficient or cost-efficient device for a specific workload.
Differently from previous works, Hamza Ournoughi et al. [18] define a cost model taking into account the virtualization environment of IaaS, the storage system characteristics in addition to energy and QoS related parameters. They present an accurate cost model for VM's persistent storage that takes into account the non-recurring cost, VM I/O workload execution
21
and storage migration costs, storage system performance, power and wear out cost. This work introduces the meaning of VM storage which refers to the storage of its virtual disk image and VM migration that represents the migration of VM's processes, memory and its corresponding persistent storage. The model is composed of three parts for a given monitoring period. The non-recurring cost (considered as constant parameter) refers to the fixed expenses that do not depend on cloud environment, this includes for example data center space purchase, resource setup and human resources. The execution cost refers to the I/O workload execution of a VM stored on a given device. This is composed of energy and wear out costs. The former is calculated as the energy unitary price multiplied by the total energy consumed during I/O workload by all hardware components. To obtain the power usage of a given device first it is necessary to distinguish between different working modes: operating mode, idle mode and standby/sleep mode. The model also considers VM storage migration costs performed between a source and a destination physical devices. This operation incurs in energy cost due to the copy of the image and war out costs calculated as the amount of data written during the migration to the minimum transfer rate.
Traditional research works on network communication and bandwidth optimization mainly focus on rich connectivity at the edge of the network and dynamic routing protocols to balance the traffic loads [19]. With the increasing presence of communication intensive applications in the cloud, network bandwidth factor can be effective on performance and can be a criterion for evaluations too. For example, if the bandwidth is too low to provide service to customers, performance will be low too.
M.Rajesh et al. [20] in his document discussed about how the virtual machine approach can improve the efficiency, power utilisation and availability of costly hardware resources. In particular, such document identified network utilisation metrics and critical networking features, with the goal of analyse network I/O application environment of virtualized cloud.
Yiduo Mei et al. [21] present an extensive performance study of network I/O workloads in a virtualized cloud environment. By studying a set of representative workloads in cloud-based data center, which compete for either cpu or network I/O resources, presents a detailed analysis on different factors that can impact the throughput performance. At the end illustrate
22
an in-depth discussion on the performance impact of collocating applications that compete for either CPU or network I/O resources.
4.2 Summary View and Metrics we will Consider
In the previous section we listed some of the most frequent resources involved in the problem of resource management. We presented different approaches, some related to VM energy consumption, others concerning storage devices, with the goal to estimate the overall cost of an IaaS infrastructure. From the above, computation, memory, storage and networking turn out to be the resources of interest to analyse the behaviour of a complex application from the point of view of resources utilisation1. Our goal is to better describe, through a careful selection of resource consumption metrics, the relation between management operations and infrastructure resources needed to deploy and execute a target cloud-based application. We detail below what are the main characteristics and related performance parameters of IaaS components, after this description we will select the resource consumption metrics of interest that give a contribution to our management model.
• Computation refers to the use of processing resources or the amount of work handled to compute intensive data/job processing in the cloud and could vary depending on the amount and type of managed computing tasks. Taking into account the previous state-of-the-art research there are several factors to consider when metering this metric (such as cpu frequency, cpu voltage) that are related to the energy consumption. Executing a task requires knowledge of the amount of computing resource it needs, number of cores could be a good parameter to determine this amount of capacity. For example, many HPC applications began as single processor programs. If these applications take too long on a single core or need more memory than is available, they need to be modified so they can run on scalable systems. Fortunately, many of the most used HPC applications are already available for scalable
1 Energy is another feature that emerges from cost models previously discussed. As energy also depends on the
hardware characteristics of data centers, and since our objective is to analyze composite cloud applications (by abstracting from the actual data center where they will run), we shall not include energy in our model.
23
systems. Not all applications require large numbers of cores for effective performance, while others are highly scalable.
• Memory is designed to temporarily store data for fast access. Cloud environment is dynamic and volatile so there is a strong need to adopt dynamic memory allocation trends, because of the increasing request of cores in the cloud system combined with the rapid adoption of virtualization technology. This metric is often associated with the concept of read/write throughput expressed in bytes per sends. Measuring memory bandwidth is a good way for understanding how well your application uses cache memory. From the point of view of the operation executed during the application life-cycle it is necessary to take into account the amount of RAM needed to perform specific task. All system and application programs reserve memory either at startup or during the course of operation. Memory is reserved for inputting data, for additional software instructions or for the creation of control structures such as a stack.
• Storage refers to saving data to an off-site storage system maintained by a third-party. In this case redundancy is key features to guarantee that the information could be accessed at any given time. The most common value from a disk manufacturer is how much throughput a certain disk can deliver. For an accurate analysis we evaluate the number of bytes read and written as well as the service times for those reads/writes. Input/output operations per seconds is also relevant, as the amount of read or write operations that could be done in a second will also give additional information from performance point of view. Another factor of interest is the size of each IO request that depends on the operating system and the application/service that need disk access.
• Network refers to all network components that interconnect with a high-bandwidth more physical machine. One critical aspect to manage is the topology, which significantly impacts performance and fault tolerance. Another key aspect, more directly tied to resource management, concerns how to provide predictable latency and bandwidth in a data center network.
24
In the context of Infrastructure-as-a-Service, we understand resource management as the process of allocating computing, memory, storage, and networking resources to applications, in a way that seeks to jointly meet the objectives of Cloud Users (who rent resources for running their applications), and Cloud Providers (who rent out resources to make revenue) []. Based on the above presented analysis, we identified four main types of resources. Namely, computational and memory resources that allow the deployment, execution and use of applications, as well as storage and network services that can be used “standalone” or in conjunction with computational resources.
According to the definition of Infrastructure-as-a-Service [2] and following our analysis of IaaS we can summarize the most interesting metrics (from an application's perspective) for measuring resource utilisation as in Table 2.
With the objective of permitting to analyse all resources previously described, we shall select the most representative utilisation metric for each of such resources. For each resource, we indeed select the resource utilisation metric that is most discussed among the above mentioned research efforts (viz., number of logical cores, memory utilisation in MB, storage utilisation in MB, and network I/O traffic in MB per seconds – shown with a ✓ in Table 2). The management of cloud application depends on a large part on the resource utilisation of the underlying infrastructure. The objective of this chapter was to select suitable resource consumption metrics in order to extend the management protocols [1] (by adding the notion of “resource utilisation”). Such extension allows as to better planning, managing and optimizing resource utilisation, hence allowing to increase application performances while at the same time reducing costs.
25
Resources Metrics Considered in our analysis
Computation Number of cores ✓
Average cpu utilisation
Cpu time
Cpu frequency and voltage
Memory Utilised memory in MB ✓
Number of bytes read and written
Storage Utilised storage in MB ✓
Number of bytes read and written
Network Network I/O traffic in MB/s ✓
Total number of bytes sent and received
Table 1: Main resource consumption metric classified by computation, memory, storage network. The last column shows which parameter have been chosen to be included in our model.
26
Chapter 5
Resource-aware Management Protocols
The standard language TOSCA [3] allows to specify how to automatically deploy and manage complex cloud applications. Management protocols [1] allow to describe the behaviour of applications, specifying the management operations and their relations with states, requirements and capabilities. It is however not possible to indicate how much resources are needed to perform (sequences of) management operations. Given a valid deployment/management plan, it is hence not possible to identify the amount of resources it needs to be executed, nor whether it requires more resources than those have been rented from a Service Provider.In this chapter, we propose a resource-aware extension of management protocols that permits specifying the amount of resources needed by an application component to stay in a state or to perform a management operation. We then show how the proposed extension allows to analyse the management of a TOSCA application by taking also into account the resources utilised by its components (e.g., determining the maximum amount of resources needed to execute a valid management plan, or checking whether a valid plan is also feasible – meaning that it never utilises more resources than those available).
27
5.1 Definition of Resource-aware Management Protocols
Let be 𝑁 a 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 modelling an application component. We hereby define a resource-aware extension of management protocols, that permits describing the resource utilisation of 𝑁 when it is in a state and when it is making a transition from one state to another.
We first define the “universe” of all possible resources utilised by a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆. From the analysis on cost models for IaaS presented in Chapter 3, the resulting resources of interest to analyse the behaviour of a complex cloud application are computation, memory, storage and network. The universe includes one utilisation metric for each of such resource (see Table 2 in Chapter 3).
Definition 5.1. The universe 𝑈 = ℕ×ℕ×ℕ×ℕ of all possible combinations of resource utilisations is the set of all quadruples 〈𝑢𝑐𝑜𝑟𝑒𝑠, 𝑢𝑚𝑒𝑚𝑜𝑟𝑦, 𝑢𝑠𝑡𝑜𝑟𝑎𝑔𝑒, 𝑢𝑛𝑒𝑡𝑤𝑜𝑟𝑘〉, where:
- 𝑢𝑐𝑜𝑟𝑒𝑠 is the number of logical cores utilised, - 𝑢𝑚𝑒𝑚𝑜𝑟𝑦 is the memory utilised in MB, - 𝑢𝑠𝑡𝑜𝑟𝑎𝑔𝑒 is the storage utilised in MB, - 𝑢𝑛𝑒𝑡𝑤𝑜𝑟𝑘 is the network utilised in MB/s.
□ We can now extend the definition of management protocol introducing a new function 𝜐𝑁
which associates the resources consumed by a 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁 with states and transition. More precisely, 𝜐𝑁 describes the resource consumption of 𝑁 in a state and how much
computation, memory, storage, and network are utilised by 𝑁 in order to perform a change of its state from 𝑠 to 𝑠′.
Definition 5.2. Let 𝑁 = 〈𝑆𝑁, 𝑅𝑁, 𝐶𝑁, 𝑂𝑁, 𝑀𝑁〉 be a 𝑁𝑜𝑑𝑒𝑇𝑦𝑝𝑒, where 𝑆𝑁, 𝑅𝑁, 𝐶𝑁, and 𝑂𝑁 are the sets of its states, requirements, capabilities, and management operations. 𝑀𝑁= 〈𝑠̅𝑁, 𝜌𝑁, 𝜒𝑁, 𝜏𝑁, 𝜐𝑁〉 is the management protocol of 𝑁 where
- 𝑠̅𝑁 ∈ 𝑆𝑁 is the initial state,
- 𝜌𝑁 : 𝑆𝑁 → 2𝑅𝑁 is a function indicating, for each state 𝑠 ∈ 𝑆𝑁, which conditions on the requirements of 𝑁 must hold,
28
- 𝜒𝑁 ∶ 𝑆𝑁→ 2𝐶𝑁 is a function indicating which capabilities are concretely offered by 𝑁 in each state 𝑠 ∈ 𝑆𝑁,
- 𝜏𝑁⊆ 𝑆𝑁 × 2𝑅𝑁 × 𝑂
𝑁 × 𝑆𝑁 is a set of quadruple modelling the transition relation 〈𝑠, 𝐻, 𝑜, 𝑠′〉 means that in state 𝑠, and if condition 𝐻 holds, o is executable and leads to state 𝑠′,
- 𝜐𝑁 ∶ 𝑆𝑁∪ 𝜏𝑁 → 𝑈 is a function indicating the resources utilised by 𝑁 when it is in state 𝑠 ∈ 𝑆𝑁 or when it is executing a transition 〈𝑠, 𝐻, 𝑜, 𝑠′〉 ∈ 𝜏𝑁. □
Example 5.1. Figs. 9-13 show the resource-aware extension of management protocols of
Thinking’s nodes composing our motivating scenario, previously detailed in Chapter 2.
Consider for instance, the resource-aware management protocol of 𝑀𝑎𝑣𝑒𝑛 (Fig. 9). The latter extends the management protocol in Fig. 4 by indicating the resource utilisation of 𝑀𝑎𝑣𝑒𝑛. Such resources utilisation is described by adding a label 𝑈, which permits describing computation, memory, storage and network employed by 𝑀𝑎𝑣𝑒𝑛 when it is in a state and when it is making a transition. For instance, in its state Stopped, 𝑀𝑎𝑣𝑒𝑛 only needs 200MB of storage. When executing Start (in the state Stopped), 𝑀𝑎𝑣𝑒𝑛 exploits 1 core, 50MB of memory, 50MB of storage and 20MB of network.
Unavailable Running Stopped R:{} C:{} R:{} C:{Container} R:{} C:{} {} {} Run {} {} Start {} {} Stop {} {} Delete {} {} Create U:<0,0,0,0> U:<1,150,200,50> U:<0,0,200,0> U:<1,200,250,150> U:<1,50,50,20> U:<1,150,200,100> U:<1,70,60,30> U:<1,50,20,0>
29 Unavailable Running Stopped R:{} C:{} R:{} C:{Container} R:{} C:{} {} {} Run {} {} Start {} {} Stop {} {} Delete {} {} Create U:<0,0,0,0> U:<1,100,200,80> U:<0,0,160,0> U:<1,70,40,40> U:<1,80,80,20> U:<1,100,200,100> U:<1,50,30,20> U:<1,60,20,0>
Figure 10: Resource-aware management protocol for 𝑁𝑜𝑑𝑒’s node type in our motivating scenario.
Unavailable Running Stopped R:{} C:{} R:{} C:{MongoEndp} R:{} C:{} {} {} Run {} {} Start {} {} Stop {} {} Delete {} {} Create U:<0,0,0,0> U:<1,180,150,40> U:<0,0,100,0> U:<1,270,90,150> U:<1,50,30,20> U:<1,40,10,0> U:<1,150,100,100> U:<1,50,20,30>
30 R:{} C:{} Uninstalled Installed R:{} C:{} Configured R:{MongoEndp} C:{} Working R:{MavenCont, MongoEndp} C:{ApiEndp} {MavenCont} {} Setup {MavenCont, MongoEndp} {} Configure {MavenCont, MongoEndp} {} Run {MavenCont, MongoEndp} {} Stop {MavenCont, MongoEndp} {} Configure {MavenCont} {} Uninstall {MavenCont} {} Uninstall
U:<0,0,0,0> U:<0,0,50,0> U:<1,80,170,50> U:<1,190,350,70> U:<1,50,160,100> U:<1,100,190,40> U:<1,240,100,100>
U:<1,80,20,10>
U:<1,100,190,40> U:<1,100,70,0>
U:<1,100,70,0>
Figure 12: Resource-aware management protocol for 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼’s node type in our motivating scenario.
R:{} C:{} Uninstalled Installed R:{} C:{} Configured R:{MongoEndp} C:{} Working R:{MavenCont, MongoEndp} C:{ApiEndp} {NodeJSCont} {} Setup {NodeJSCont, APIEndp} {} Configure {NodeJSCont} {} Uninstall {NodeJSCont} {} Uninstall U:<0,0,0,0> U:<0,0,100,0> U:<1,100,160,60> U:<1,180,70,40> U:<1,70,160,80> U:<1,90,100,60> U:<1,100,130,90> U:<1,70,20,40> U:<1,90,100,60> U:<1,120,40,10> U:<1,120,40,10> {NodeJSCont} {} Run Running R:{NodeJSCont} C:{} U:<1,160,90,50> {NodeJSCont, APIEndp} {} Configure U:<1,90,100,60> U:<1,100,130,90> {NodeJSCont, APIEndp} {} Run {NodeJSCont, APIEndp} {} Stop {NodeJSCont, APIEndp} {} Configure {NodeJSCont, APIEndp} {} Configure U:<1,90,100,60>
31
5.2 Analysis of Resource-aware Management Protocols
In this section, we define the semantics of the resource-aware management protocols of a whole application (viz., a TOSCA 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒). Formally, the semantics of the resource-aware management protocol of 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 can be defined by a labelled transition system over configurations that denotes the states of the 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒s of 𝑆. Intuitively, a transition
𝐺〈𝑜,𝑁→ 𝑖,𝜔〉𝑆𝐺′
denotes that operation 𝑜 can be executed on 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁𝑖 by utilising 𝜔 resources to perform the corresponding transition. Such transition can be performed when the global state of 𝑆 is 𝐺, making 𝑆 to evolve into new global state 𝐺′.
The labelled transition system we define in this section is a proper extension of the labelled transition system in Definition 2.4. The extension accounts for resource utilisation, by allowing to compose resource-aware management protocols, and by allowing to observe the amount of resources utilised to perform a transition.
Definition 5.3. The semantics of the resource-aware management protocols in a
𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 is modelled by a labelled transition system whose configurations are the global states of 𝑆, and where the transition relation is defined by the following inference rule:
𝐺 ={(𝑁1, 𝑠1), … , (𝑁𝑖, 𝑠𝑖), … , (𝑁𝑚, 𝑠𝑚)} 𝐺′ ={(𝑁1, 𝑠1), … , (𝑁𝑖, 𝑠𝑖′), … , (𝑁𝑚, 𝑠𝑚)} 〈𝑠𝑖, 𝐻, 𝑜, 𝑠𝑖′〉 ∈ 𝜏𝑁𝑖 ∀𝑟 ∈ 𝐻 ∶ 𝑐𝑎𝑝𝑆(𝑟) 𝑖𝑠 𝑑𝑒𝑓𝑖𝑛𝑒𝑑 ∧ 𝑐𝑎𝑝𝑆(𝑟) ∈ ⋃ 𝜒𝑁𝑗(𝑠𝑗) 𝑚 𝑗=1 𝜔 = 𝜐𝑁𝑖(〈𝑠𝑖, 𝐻, 𝑜, 𝑠𝑖′〉) 𝐺〈𝑜,𝑁→ 𝑖,𝜔〉𝑆𝐺′ □
The above inference rule defines how the global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 is updated when a node performs a transition 〈𝑠𝑖, 𝐻, 𝑜, 𝑠𝑖′〉 ∈ 𝜏𝑁𝑖. It updates the corresponding rule in
32
transition 〈𝑠𝑖, 𝐻, 𝑜, 𝑠𝑖′〉 ∈ 𝜏𝑁𝑖, which is computed by applying the function 𝜐𝑁𝑖 to such
transition.
This definition permits to model a new evolution of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 when a sequence of management operations is executed:
𝐺0〈𝑜→ 1,𝑁𝑖1,𝜔1〉𝑆𝐺1 → 〈𝑜2,𝑁𝑖2,𝜔2〉𝑆… 〈𝑜→ ℎ,𝑁𝑖ℎ,𝜔ℎ〉𝑆𝐺ℎ.
After defining the management behaviour of a composite application, we can now perform an analysis of the resources consumed by a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒. First of all, in order to simplify the notation, we introduce some shorthand notations to denote the resources utilised by a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 when its global state is 𝐺, and to denote the resources utilised by a single 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁𝑖 in a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 when the global state of 𝑆 is 𝐺
Definition 5.4. Given a global state 𝐺 = {(𝑁1, 𝑠1), … , (𝑁𝑚, 𝑠𝑚)}, we denote the resource utilisation of a global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆 by 𝜐(𝐺), which is defined as follows:
𝜐(𝐺) = ∑ 𝜐𝑁𝑖(𝑠𝑖)
〈𝑁𝑖,𝑠𝑖〉∈𝐺
where
∀ 〈𝑎, 𝑏, 𝑐, 𝑑〉 ∧ 〈𝑎′, 𝑏′, 𝑐′, 𝑑′〉 ∈ 𝑈 ⟹ 〈𝑎, 𝑏, 𝑐, 𝑑〉 + 〈𝑎′, 𝑏′, 𝑐′, 𝑑′〉 = 〈𝑎 + 𝑎′, 𝑏 + 𝑏′, 𝑐 + 𝑐′, 𝑑 + 𝑑′〉.
We also denote amount of resources utilised by a 𝑁𝑜𝑑𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑁𝑖 in the global state 𝐺 by 𝜐𝑁𝑖(𝐺), which is defined as follows:
𝜐𝑁𝑖(𝐺) = 𝜐𝑁𝑖(𝑠𝑖) with 〈𝑁𝑖, 𝑠𝑖〉 ∈ 𝐺
□
We can now focus on the analysis of management plans. Given a valid management plan we can determine the capacity of such plan in a global state 𝐺, viz., we can determine the amount of resources employed to execute such plan in 𝐺.
Definition 5.5. Let 𝑆 be a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒, and let 𝐺𝑖 be a global state of 𝑆. Let also 𝑜1, … , 𝑜𝑛 be a valid sequence of operations such that
33
The maximum amount of resources utilised by 𝑆 to perform 𝑜1, … , 𝑜𝑛 is defined as follows:
𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦(𝐺0, 𝑜1, … , 𝑜𝑛) = max {𝜐(𝐺0), max
𝑗=1…𝑛{𝜐(𝐺𝑗−1) − 𝜐𝑁𝑖𝑗−1(𝐺𝑗−1) + 𝜔𝑗, 𝜐(𝐺𝑗)} }
□
𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦 evaluates the maximum between the resource utilised by 𝑆 in the global state 𝐺0 and while executing each transition corresponding to 𝑜𝑗 (for 𝑗 = 1. . 𝑛). The amount of resources used in each transition is computed as the maximum between:
- The amount of resources used in the global state reached by executing the transition (viz., 𝜐(𝐺𝑗)), and
- the amount of resources used in the global state in which the transition is operated (viz., 𝜐(𝐺𝑗−1)), to which it is removed the resource utilised by the node operating the transition (viz., 𝜐𝑁𝑖𝑗−1(𝐺𝑗−1) + 𝜔𝑗), and to which it is added the amount 𝜔𝑗 of resources used by the same node to execute the transition, and
The Capacity of a TOSCA 𝑃𝑙𝑎𝑛 descends immediately from that of its sequential trances (which can be computed as indicated in Definition 5.5).
Definition 5.6. Let 𝐺 be a global state of a 𝑆𝑒𝑟𝑣𝑖𝑐𝑒𝑇𝑒𝑚𝑝𝑙𝑎𝑡𝑒 𝑆. The maximum amount of
resources needed by 𝑆 to execute a 𝑃𝑙𝑎𝑛 𝑃, denoted by 𝐶𝑎𝑝𝑎𝑐𝑖𝑡𝑦(𝐺, 𝑃), is the maximum among the capacities of all the sequential traces of 𝑃 in 𝐺. □ Example 5.2. Tab. 3 and 4 illustrate the global state evolution (on the left side) according to
𝑃𝑙𝑎𝑛 (a) and (b) together with the resource utilisation (on the right side) of every 𝐺𝑖/transition. We determine from the initial global state 𝐺0 (where 𝑀𝑎𝑣𝑒𝑛, 𝑁𝑜𝑑𝑒 and 𝑀𝑜𝑛𝑔𝑜 are Unavailable while 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐴𝑃𝐼 and 𝑇ℎ𝑜𝑢𝑔ℎ𝑡𝑠𝐺𝑈𝐼 are Uninstalled) the resources required for each transition and for each global state reached by performing the sequential traces of these two plans. Through this example we show also how the resource exploitation changes according to the type of the operation performed (e.g., executing the Create-Start sequence rather than Run to make 𝑁𝑜𝑑𝑒 Running) and the order in which they are executed. By determining the capacities of 𝑃𝑙𝑎𝑛s (a) and (b), it is then possible to compare the resources they need and pick which is the most convenient (see Tab. 2).
34
Maven Node Mongo ThoughtsAPI ThoughtsGUI Unavailable Unavailable Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Unavailable Running Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Installed Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Installed Installed
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Installed Installed
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Configured Installed
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Working Installed
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Working Running
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Working Working
Figure 14: Capacity evaluation and resource utilisation of 𝑃𝑙𝑎𝑛 (a) in Fig.7.
𝐺0 𝐺1 𝐺2 𝐺3 𝐺4 𝐺5 𝐺6 𝐺7 𝐺8 𝐺9 〈0,0,0,0〉 〈1,100,200,80〉 〈2,250,400,130〉 〈2,250,450,130〉 〈2,250,550,130〉 〈3,430,700,170〉 〈4,510,820,220〉 〈4,620,1000,240〉 〈5,780,990,290〉 〈5,800,970,280〉 〈1,70,40,40〉 〈2,300,450,230〉 〈3,300,560,230〉 〈3,320,610,210〉 〈3,520,640,280〉 〈4,90,50,60〉 〈4,670,750,270〉 〈5,720,1030,330〉 Node : Run Maven : Run ThoughtsAPI : Setup ThoughtsGUI : Setup Mongo : Run ThoughtsAPI : Configure ThoughtsAPI : Run ThoughtsGUI : Run ThoughtsGUI : Configure 〈5,710,1000,300〉
35
Maven Node Mongo ThoughtsAPI ThoughtsGUI Unavailable Unavailable Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Unavailable Stopped Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Unavailable Running Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Stopped Running Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Uninstalled Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Installed Uninstalled
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Installed Installed
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Unavailable Installed Running
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Stopped Installed Running
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Installed Running
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Configured Running
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Working Running
Maven Node Mongo ThoughtsAPI ThoughtsGUI Running Running Running Working Working
Figure 15: Capacity evaluation and resource utilisation of 𝑃𝑙𝑎𝑛 (b) in Fig.7.
𝐺0 𝐺1 𝐺2 𝐺3 𝐺4 𝐺5 𝐺6 𝐺7 𝐺8 𝐺9 〈0,0,0,0〉 〈0,0,160,0〉 〈1,100,200,80〉 〈1,100,400,80〉 〈2,250,400,130〉 〈2,250,450,130〉 〈2,250,550,130〉 〈3,410,540,180〉 〈3,410,640,180〉 〈4,590,690,220〉 〈1,100,200,100〉 〈1,80,80,20〉 〈2,250,400,180〉 〈2,150,250,100〉 〈3,300,560,230〉 〈3,320,610,210〉 〈3,350,580,220〉 〈4,560,640,280〉 〈4,460,560,210〉 Node : Create Node : Start Maven : Create Maven : Start ThoughtsAPI : Setup ThoughtsGUI : Setup ThoughtsGUI : Run Mongo : Create Mongo : Start 𝐺10 𝐺11 𝐺12 〈5,690,830,260〉 〈5,670,810,270〉 〈5,830,740,320〉 〈5,780,990,290〉 〈5,780,960,320〉 〈5,860,900,270〉 ThoughtsAPI : Configure ThoughtsAPI : Run ThoughtsGUI : Run
