Keywords

1 Introduction

Cloud computing is a novel paradigm [16] that has gained a great interest in both industrial and academic sectors. It consists of providing a set of virtualized resources (servers, virtual machines, services, etc.) as on-demand services. These resources are offered by cloud providers according to three fundamental service models: infrastructure as a service (IaaS), platform as a service (PaaS), and software as a service (SaaS). The cloud has many characteristics that make it very attractive such as high availability, flexibility and cost effectiveness. However, the most appealing feature for cloud users, and what distinguishes the cloud from the other models, is the elasticity property [23]. In cloud systems [11], elasticity allows to efficiently control resources provisioning according to workload fluctuation, in a way to maintain an adequate quality of service (QoS) while minimizing operating cost. Such behavior is implemented by an elasticity controller, an entity usually based on a closed control loop [22], that decides of the elasticity actions to be triggered (scaling up/down actions [13]).

In the last few years, many academic researches for providing elastic management at different cloud scopes were proposed such as [1, 6, 10, 14, 21]. However, a little attention has been given to modeling and describing the cloud systems’ elasticity controller and its behaviors. In fact, this task can be particularly challenging as these behaviors rely on many overlapping factors such as the available resources, current workload, etc. Managing these dependencies significantly increases the difficulty of modeling cloud systems’ elasticity controller. To address this challenge, formal methods characterized by their efficiency, reliability and precision, present an effective solution to deal with all of these aspects.

In this paper, we aim to take a first step towards providing a formal modeling approach that reduces the complexity of designing cloud systems and the elasticity controller behavior. Precisely, we adopt bigraphical reactive systems (BRS) [17, 18] as a semantic framework for specifying structural and behavioral aspects of elastic cloud systems. We use bigraphs and bigraphical reaction rules to address both aspects. Reaction rules describe the elastic behavior of a cloud system at service and infrastructure levels according to multiple adaptation rules that are executed by the elasticity controller.

The remainder of the paper is structured as follows. In Sect. 2, we introduce the elasticity controller and identify its components and role in the management of cloud elasticity. We briefly introduce, in Sect. 3, the BRS formalism, apply its modeling approach to specify elastic cloud systems and describe their elastic behaviors my means of adaptation rules. An example of the elasticity management is proposed and evaluated in Sect. 4. In Sect. 5, we review the state of art on formal specification of elastic cloud systems and the use of BRS. Finally, Sect. 6 summarizes the paper and discusses future work.

2 The Elasticity Controller

In elastic cloud systems, resources provisioning can be adjusted by an elasticity controller. It decides the adaptation rules to be triggered, in order to scale the cloud system, in such a way that resource provisioning matches the minimum requirements, as closely as possible. This is done with taking into account many factors as the available resources, current workload, system state, etc. [23]. Structurally, the elasticity controller is usually considered as a closed control loop derived from the IBM’s autonomic control loop known as MAPE for Monitoring, Analyse, Planification and Execution [22]. In [14, 19], the controller is considered to be constituted by different entities, that interact with each other, to implement the main phases of the control loop. Monitoring and Execution phases are usually considered to be handled by entities that monitor the system (by the means of sensors) and apply actions (using effectors) that the Planification decides, according to flaws that the Analyse identifies.

In our previous work [19], we have provided a cloud systems’ design structured in three parts: the front-end, the back-end and the elasticity controller. In this paper, we focus on the elasticity controller and the managed back-end that we see as the cloud hosting environment, i.e., servers, virtual machine instances (VMs) and service instances. We abstract the front-end part through the incoming requests which the cloud system receives from clients.

The challenging part here is how to implement a logic that enables the elasticity controller to ensure auto-adaptation behaviors over a managed cloud system. This is accomplished by triggering adaptation rules according to particular conditions, which represent elasticity anomalies to repair. In the next Section, we will adopt a bigraphical approach to model both structural and behavioral aspects of the back-end and the elasticity controller. We introduce elasticity strategies to describe the elasticity controller’s behavior by means of bigraphical reaction rules.

3 Formalizing Elastic Cloud Systems with BRS

3.1 BRS Overview

Bigraphical reactive systems (BRS) are a recent formalism introduced by Milner [18], for modeling the temporal and spatial evolution of computation. It provides a graphical model that emphasizes both connectivity and locality. A BRS consists of a set of bigraphs and a set of reaction rules, which define the dynamic evolution of the system by specifying how the set of bigraphs can be reconfigured.

Graphical Notation and Interface.

Figure 1 depicts an example of a bigraph representation. Dashed rectangles denote regions describing separate parts of the system. Nodes are depicted by circles and represent the physical or logical components of the system. Each node has a type, called control, denoted by the labels A and B. A signature is the set of controls of a bigraphs. A node can have zero, one or many ports which represent possible connections. Ports are depicted by bullets. In the example, connections are represented as links, depicted by curvy lines, which may connect ports and names (x, y and z). They can be considered as (potential) links to other bigraphs. Sites, modeled with gray squares, encode parts of the model that have been abstracted away. A bigraph’s B possibilities to interact with its external environment are visible through its interface. For example, B: 0 → < 2, {x, y} > indicates that B has zero sites, two regions and its names are x and y. Note that a bigraph also has algebraic notations that are equivalent to the graphical ones. For instance, merge product F | G denotes the juxtaposition of bigraphs F and G which is then placed inside a single region. Nesting operation F.G allows to place bigraph G inside F and parallel product (||) term may be used to compose bigraphs by juxtaposing their roots and merging their common names. More details about Bigraphs can be found in [17].

Fig. 1.
figure 1

Example of a bigraph

Full size image

Bigraphs Sorting.

Classification of controls and links for a bigraph is performed using sorts. A sorting discipline is a triple \( \Sigma = \left\{ {\Theta ,{\text{K}},\Phi } \right\}, \) where \( \Theta \) is a non-empty set of sorts, K is a signature, and \( \Phi \) is a set of formation rules. A formation rule is a set of properties a bigraph has to satisfy. Disjunctive sorts are written as \( \widehat{ab} \), expressing that a node can either be of sort a or sort b.

Bigraphical Reactive Systems.

A Bigraphical Reactive System (BRS) consists of a set of bigraphs representing the state of the system, and a set of reaction rules, defining how the system evolves (by going from one state to another). A reaction rule Ri is a pair (R, R’), where redex R and reactum R’ are bigraphs that have the same interface. The evolution of a system St is derived by checking if R is a match in St (as reference to bigraph matching [4]) and by substituting it with R’ to obtain a new system St’. This is made with triggering the suitable reaction rule Ri. The evolution is noted \( St\mathop \to \limits^{Ri} St \)’.

3.2 A BRS Model for Elastic Cloud Systems

An elastic cloud system is represented by a bigraph CS involving all cloud architectural elements. The bigraph CS is obtained by the parallel composition of the hosting environment (back-end) and the elasticity controller bigraphs (noted B and E) [19]. The sorting logic introduces mapping rules and expresses all the constraints and formation rules, that CS needs to satisfy, to ensure proper and precise encoding of the cloud semantics into BRS concepts. Formal definitions are given in what follows.

Definition 1.

Formally, a bigraph \( CS \) modeling a elastic cloud system is defined as follows.

$$ CS = (V_{CS} ,E_{CS} ,ctrl_{CS} ,CS^{P} ,CS^{L} ):I_{CS} \to J_{CS} $$

  • \( V_{CS} \,and\,E_{CS} \) are sets of nodes and edges of the bigraph CS.

  • \( ctrl_{CS} : V_{CS} \to K_{CS} \) a control map that assigns each node \( v \in V_{cs} \) with a control \( k \in K_{cs } \).

  • \( CS^{P} = (V_{CS} ,ctrl_{CS} ,prnt_{CS} ):m_{CS} \to n_{CS} \) is the place graph of CS where \( prnt_{CS} : m_{CS} \,{ \uplus }\,V_{CS} \to V_{CS} \,{ \uplus }\, n_{CS} \) is a parent map. mCS and nCS are the number of sites and regions of the bigraph CS.

  • \( CS^{L} = (V_{CS} ,E_{CS} ,ctrl_{CS} , link_{CS} ): X_{CS} \to Y_{CS } \) represents link graph of CS, where \( link_{CS} : X_{CS} \,{ \uplus }\,P_{CS} \to E_{CS} \,{ \uplus }\,Y_{CS} \) is a link map, XCS and YCS are respectively inner and outer names and \( P_{CS} \) is the set of ports of CS.

  • \( I_{CS} = \left\langle {m_{CS} ,X_{CS} } \right\rangle \,and\,J_{CS} = \left\langle {n_{CS} ,Y_{CS} } \right\rangle \) are the inner and outer interfaces of the cloud system bigraph CS.

Definition 2.

The sorting discipline associated to CS is a triple \( \Sigma _{CS} = \left\{ {\Theta _{CS} ,{\text{K}}_{CS} ,\Phi _{CS} } \right\}, \) where \( \Theta _{CS} \) is a non-empty set of sorts. K CS is its signature, and \( \Phi _{CS} \) is a set of formation rules associated to the bigraph. Table 1 gives for each cloud concept the mapping rules for BRS equivalence. This consists of the control associated to the entity, its arity (number of ports), its associated sort and graphical notation. Sorts are used to distinguish node types for structural purposes and constraints while controls identify states and parameters a node can have. For instance, a server noted \( {\text{SE}} \) has control \( {\text{SE}}^{\text{L}} \) when it is overloaded and \( {\text{SE}}^{\text{U}} \) when unused. A client request, noted \( {\text{q}}_{\text{c}} \), is addressed to a service category identified by the parameter “c”. Also, all nodes representing servers are of sort \( e \) and all requests from all clients are of sort \( q \).

Table 2 gives the formation rules Φi that bring construction constraints over the BRS specification.

Formation rules give structural constraints over the BRS model. Rule Φ0 specifies that servers are at the top of the hierarchical order of the deployed entities in back-end bigraph. Rules Φ1–3 give the structural disposition of a hosting environment where a server hosts VMs, a VM runs service instances and a service instance handles requests. All connections are port-to-port links to illustrate possible communication capabilities between the different cloud entities. In Φ6–7, we use the name w, for workload, to illustrate the connection the cloud system has with its abstracted front-end part. A server is linked to its hosted entities, that represent the resources virtualization (VMs), and a VM is linked to the service instances it is running.

The back-end is managed by the elasticity controller through c-name edges for control. The entities are monitored by the Monitor node that captures events the Evaluator analyses and then triggers actions that the Effector applies. Φ11 states that the monitor, effector and evaluator entities are always linked. Figure 2 represents a bigraph example which expresses a back-end of a cloud system where two servers (SE), two VMs and two service instances (S) are deployed. V-edges stand for virtualization and s-edges for services. The elasticity controller bigraph is connected to the back-end with c-name. Squares numbered 1–6 are sites representing parts of the system that are abstracted away.

In Rules Φ4–5 and 9, active elements may take part is reactions while passive ones won’t. The possible adaptation rules the elasticity controller can take over a cloud system to manage its elasticity will be presented in the next Section.

Table 1. Controls and sorts for the bigraph CS
Full size table
Table 2. Conditions of formation rule ΦCS for the bigraph CS
Full size table
Fig. 2.
figure 2

An example of cloud system bigraph CS

Full size image

3.3 The Elasticity Controller’s Behavior

The behavior of the elasticity controller is given as bigraphical reactive rules expressing the dynamicity of an elastic cloud system. In our previous work [19], we defined multiple possible horizontal, vertical, migration and marking actions that the elasticity controller may use to reshape a cloud system at multiple levels.

In this Section, we redefine a set of reaction rules that model the horizontal actions over the cloud hosting environment (servers, VMs and service instances). In addition, we introduce some elasticity strategies that the elasticity controller uses to manage a cloud’s elasticity. Table 3 gives the defined actions.

Reaction rules Ri express the possible actions that can be applied over a cloud system. A reaction is triggered when the left-hand side of the rule, that defines a bigraph (redex), is a match (or occurs) in CS [4]. The redex bigraph is replaced by the right-hand side of the reaction that represents the reactum bigraph. Sites nested within different entities (servers, VMs and services) expressed with d, are used to abstract the elements that are not included in the reaction. The specified rules define the horizontal scale elasticity actions, at different cloud levels, for provisioning (R1–3) and de-provisioning (R4–6) resources by scaling-out and scaling-in the hosting environment.

Table 3. Reaction rules modeling elasticity actions in the cloud
Full size table

Elasticity Strategies.

The defined reaction rules are not sufficient to express the logic that enables the elasticity controller to manage a cloud system’s elasticity. This logic is provided through elasticity strategies that implement the elasticity controller. A strategy describes a behavior to be adopted to manage the elastic behavior in the system. It consists of a set of actions that are triggered in case the specified conditions become true and takes the form [13] IF condition (s) THEN actions(s). In our model, we can encode the strategy conditions by Bilog predicates [9], while the actions are modelled by bigraphical reaction rules. For instance, a strategy that executes the condition \( (CS\,{ \vDash \upvarphi } ) \) takes the form below.

$$ strat:if\,CS\,{ \vDash \upvarphi }\,then\,R $$

Where φ is a predicate and Bφ its bigraph encoding where \( CS\,{ \vDash \upvarphi } \) is true iff Bφ is a match in CS. In what follows, we present some strategies with bigraphical representation.

Strategy 1: Hosting Environment Provisioning

When the cloud workload increases by receiving growing number of client requests, the hosting environment needs to scale-out in a way to ensure availability along with performance. Strategy 1 can be expressed with three complementary actions that operate at service and infrastructure level as shown in Table 4.

The predicate \( {\upvarphi }1 \) expresses that service instances of a certain category are overloaded and need to scale-out. The bigraph \( B_{{{\upvarphi }1}} \mathop = \limits^{\text{def}} ({\text{SE}}1.({\text{VM}}1.\,(S1_{c1}^{L} .{\text{d}}1)|(S2_{c1}^{L} .{\text{d}}2))) \) is one possible expression of the predicate for instance. Reaction rule \( R1 \) is triggered to create a new service instance of the category \( c1 \). At infrastructure level, when \( (CS\, { \vDash \upvarphi }2) \) is true, the elasticity controller replicates VM instances by triggering rule \( R2 \) and new servers are turned online by triggering \( R3 \), when \( (CS\, { \vDash \upvarphi }3) \) is true. Also, \( {\upvarphi }2 \) and \( {\upvarphi }3 \) can for example be encoded using bigraphs \( B_{{{\upvarphi }2}} \mathop = \limits^{\text{def}} ({\text{SE}}1.({\text{VM}}1^{L} .\,(d1)|{\text{VM}}2^{L} .(d2)), \) respectively \( B_{{{\upvarphi }3}} \mathop = \limits^{\text{def}} ({\text{SE}}1^{L} .({\text{d}}1)|{\text{SE}}2^{L} .(d2)). \)

Table 4. Strategy 1 definition
Full size table

Strategy 2: Hosting Environment De-provisioning

When workload drops, the hosting environment is likely to be over-provisioned and has to scale-in. Elasticity controller performs this behavior at service and infrastructure levels by applying strategy 2 as defined is Table 5.

For instance, if bigraph \( B_{{{\upvarphi }4}} \mathop = \limits^{\text{def}} ({\text{SE}}1.({\text{VM}}1.(S1.{\text{d}}1)|(S2^{U} ))) \) is a match in \( {\text{CS}} \), it means that condition \( (CS\, { \vDash \upvarphi }4) \) is true and the controller triggers reaction rule \( R4 \). The resulting bigraph would be \( B'\mathop = \limits^{\text{def}} ( {\text{SE}}1.({\text{VM}}1.(S1.{\text{d}}1))) \).

Note that more strategies can be specified to perform load-balancing and vertical scale elasticity using the remaining mechanisms defined in [20].

Table 5. Strategy 2 definition
Full size table

4 Tool Support

The approach presented is this paper is supported by MoveElastic, a framework introduced in [20], for modeling and verifying elastic cloud systems. The framework is based on the integration of the bigraphical cloud system model in Maude, an implementation of Rewriting Logic [7, 8]. It enables the specification and execution of elastic behaviors along with the formal verification of elasticity properties.

In the following example, we will present a qualitative evaluation of the two defined strategies through a simple use case.

Example.

We present an example of a cloud system to illustrate how the elasticity controller ensures the elastic behavior of a managed cloud system. Consider a voting service running in a private cloud system, with one online server hosting two VM instances and each VM is running five service instances. We consider arbitrary capacity thresholds for each hosting entity (server, VM and service instance). E.g., a server can host up to 4 VM instances, a VM can run up to 10 service instances and a service instance can receive up to 50 client requests at a time. Note that each entity is marked overloaded if its upper threshold is reached and is marked unused when its load reaches zero. Consider an arbitrary workload activity showing a progressive peak of 2500 client requests (phase 1) then slowly drops (phase 2). Graphs shown in Figs. 3, 4 and 5 give the evolution, within 10 time units, of the cloud system as it provisions when the workload rises and de-provisions when it drops. Reconfigurations when the system scales-out/in are actions the elasticity controller triggers when the thresholds are reached.

This scenario shows the high reactivity [24] that the elasticity controller provides. We can see that workload variations have no impact over performance and that infrastructure costs are well controlled. During phase 1, the growing demand is rapidly handled in such a way that the actual capacity slightly overpaces it, this enables eventual further requests to be directly handled before any adaptation is required. Figures 3, 4 and 5 show that the system’s processing capacity is never fully achieved and is always half used at the least. Moreover, unnecessarily provisioned resources are rapidly released during phase 2 to prevent from high financial impacts.

From observing the graphs, we can deduce that the elasticity controller operates according to two action plans. The plans \( AP1 \) and \( AP2 \) below show the controller’s behavior during phase 1 and phase 2 and correspond to strategy 1 and strategy 2. The symbol \( * \) indicates zero or more applications of an action or a sequence of actions.

$$ AP1 = \left( {\left( {R1* \to R2} \right)* \to R3} \right)*\quad \quad AP2 = \left( {\left( {R4* \to R5} \right)* \to R6} \right)* $$

It is interesting to see how the cloud system evolves and how elasticity is provided in a cross layered management (infrastructure and service levels). This example is very simple, but it perfectly shows how complex can be the management of even a small cloud system with a single application running with a weak recorded activity comparing to the reality.

Fig. 3.
figure 3

Service instances provisioning

Full size image
Fig. 4.
figure 4

VMs provisioning

Full size image
Fig. 5.
figure 5

Servers provisioning

Full size image

5 Related Work

There have been multiple research studies in the literature using formal methods to specify cloud systems’ elastic behaviors. In [3], authors have proposed a formalization based on the CLTLt(D) temporal logic, of several concepts and properties related to the behavior of elastic cloud systems. Qualitative properties of cloud systems have been formally introduced and detailed, such as Elasticity and Resources management, and have been evaluated using an automated verification tool. In this work, precise cloud composition has been abstracted and cloud resources are seen as virtual machines. Authors of [2] have adopted a Petri nets formalization to describe cloud-based business processes’ elastic behaviors. Elastic strategies for routing, duplicating and consolidating cloud components at service scope have been provided and compared in terms of reliability and performances. In their work, authors focus on the application layer of a cloud configuration and the infrastructure details are not addressed in the model.

In our previous work [19], we introduced a formal approach based on bigraphical reactive systems for modeling both structural and behavioral aspects of elastic cloud systems. Precisely, cloud elastic behaviors are represented in terms of client/application interactions and elasticity methods at distinct levels using bigraphical reaction rules.

In this paper, we have focused on the back-end part of a cloud system to specify two strategies that describe the elasticity controller behaviors my means of bigraphical reaction rules. The defined strategies can be combined to provide a cross-layered elasticity in such a way that the auto-adaptation stability requirements are ensured [25]. This can be made by applying priority levels between and inside the strategies to avoid loops and rules multi-triggering issue. Besides, model-checkers associated to BRS, such as BigMCFootnote 1, can be used to verify safety and liveness properties. We consider the BRS formal framework to be suitable in terms of modeling capabilities and we have attempted to illustrate its potential at cloud service and infrastructure levels.

Also, several studies have shown the efficiency and the potential of the BRS Theory to encode and describe complex considerations and behaviors. In [15], authors use BRS as a framework to model Multi Agent Systems. They describe how properties and desiderata for a given BRS specification can be expressed by means of spatial and temporal logics. Precisely, by combining a temporal logic like CTL on top of Bilog, which is a spatial logic for bigraphs [9]. This would enable property-aware matchings and rewritings of bigraphs using tools like BigRED [12] and LibBigFootnote 2. In [5], an extension of BRS called stochastic BRS with sharing (SBRS) is used to model the 802.11 wireless networks protocol. Authors show that conditional reaction rules can be specified to describe very precise matching reactions using Bilog predicates. Our goal is to provide a precise property-aware modeling and validation using these solutions.

6 Conclusion

In this paper, we have provided a view of cloud systems including all cloud components that are involved in elastic behaviors. The structural and behavioral aspects of elastic cloud systems have been formalized using the Bigraphical Reactive Systems formalism. Precisely, we use bigraphs to express the structural aspects and bigraphical reactive rules to express the behavioral ones. These behaviors implement the elasticity controller and have been formally expressed by means of two elasticity strategies, for provisioning and de-provisioning cloud systems at service and infrastructure levels. The introduced concepts are illustrated through an example of a managed cloud system where the elastic behaviors are evaluated.

In this present work, we attempt to take a first step towards the formalization of cloud systems elastic behaviors. In the next step, we plan to enlarge our specifications to provide a cross-layered elasticity management of a cloud configuration (at service and infrastructure scopes). Furthermore, we aim to evaluate and experiment our strategies using the MoveElastic framework over cloud examples and case studies. Finally, our objective is to provide a complete executable and verifiable formalization of elastic cloud systems.