Towards a Formal Model for Cloud Computing Elasticity

2014 IEEE 23rd International WETICE Conference

Towards a Formal Model for Cloud Computing Elasticity Hamza Sahli∗ , Chafia Bouanaka§ , and Ahmed Taki Eddine Dib‡ LIRE Laboratory, University of Constantine II Constantine, Algeria ∗ [email protected] ,§ [email protected], and ‡ [email protected]

resources elasticity. In addition to their graphical aspect and rigorous basis, Milners BRS are capable of representing both locality and connectivity constituting main concepts of cloud computing. A bigraphical reactive system consists of a category of bigraphs and a set of reaction rules providing them the ability to reconfigure themselves. Therefore, BRS are very suitable to formalize cloud computing fundamental architectural aspects and their shape shifting. The formalization is achieved by defining a cloud bigraph, which is composed of two independent regions (physical or logical). For instance, the client and service provider may represent these regions. Interactions between these two regions are defined via reaction rules. Nevertheless, formal specifications based on BRS would not be enough to execute and analyze the underlying cloud architectural behavior. Hence, Maude language [5] intervenes here to implement the obtained cloud bigraphical models. Maude is a highlevel language and a high-performance system supporting executable specification. It will be used to define executable and analyzable formal specifications for cloud computing architecture elasticity. We aim in this paper to propose a formal specification of the cloud architecture and its dynamics via a judicious coupling of BRS and Maude to express and analyze dynamic cloud architectures. The graphical representation of cloud architecture and its structural dynamics are first specified with BRS and then mapped to Maude executable specifications. The rest of the paper is organized as follows. In section II, we introduce Bigraphical Reaction Systems (BRS) and recall fundamental elements of Maude language. Section III presents our bigraphical specification of cloud dynamic architecture. Section IV shows how Maude language may execute specifications of cloud architecture and its elasticity. The given formalization approach is illustrated through an execution example in section V. In section VI, we present related work. Finally, some concluding remarks and ongoing work rounds up the paper.

Abstract—Cloud computing is an emerging topic in the ITindustry; it brings new design challenges and security issues, as resources rapid availability and quick scalability. Since formal methods provide a reliable mathematical basis giving rise to safely analyzable models, we aim in this paper to propose a formal framework for cloud computing architectural elasticity. Bigraphical Reactive Systems are adopted as a semantic framework for their graphical aspect and rigorous basis. Then, Maude language is used to implement the obtained cloud bigraphical model. Maude system allows us to execute and analyze the formal specification of cloud computing architecture and its elasticity. Keywords-cloud computing; reconfiguration; formal methods; bigraphs; Bigraphical Reactive System; Maude;

I. INTRODUCTION Cloud computing [1] is actually one major concept in the IT evolution. From a purely operational and technical viewpoint, cloud computing is a deployment model of computing resources tending to capitalize such resources, but still maintaining their rapid availability. So, basic idea beyond cloud computing is to provide a poll of computing resources as on demand services, that users can consume according to their needs by paying only their real consumption. Such flexibility and cost effectiveness make cloud computing models very attractive. Although cloud computing offers numerous benefits, it brings new security risks and challenges as high level of resources availability, which introduces the very important concept of rapid elasticity. Elasticity goes beyond a simple flexible and dynamic allocation and deallocation of resources on the fly. It implies a permanent reconfiguration of the underlying network and its associated controls. According to [2] the lack of a convenient methodology in workload profiling for elastic systems exposes designers to the risk of missing the identification of critical usage scenarios that might lead to emergent behaviors and could jeopardize the application execution. Therefore, adopting formal methods to model cloud computing architecture and its behavior can be very effective to address this methodological lack, since they provide a reliable mathematical basis that results on safely analyzable and easily verifiable cloud models. In this work, Bigraphical Reactive Systems (BRS) [3] are adopted as a semantic framework to formalize cloud 978-1-4799-4249-7/14 $31.00 © 2014 IEEE DOI 10.1109/WETICE.2014.18

II. PREREQUISITES ON BIGRAPHS AND MAUDE A. PRELIMINARIES OF BIGRAPHS Bigraphical reactive systems were initially introduced by R. Milner [3] to provide a completely graphical intuitive 359

2) Dynamical aspects: Bigraphs structural dynamics is expressed via reaction rules; each one defines a redex bigraph to be transformed to a reactum bigraph. Formally, a reaction rule takes the form (R, R , n) where R : m → J is a redex, R : m → J is a reactum and n : m → m is a map of ordinals [4]. The category of all bigraphs and their reaction rules constitute a BRS.

formal model capable of representing at the same time connectivity and locality of distributed entities which coincides strongly with cloud computing concepts. 1) Structural Aspects: A bigraph is the combination of two independent structures place and link graphs. The place graph represents system entities geographical distribution. The link graph is a hypergraph representing interconnections between these entities. Within a BRS, system entities are represented by nodes and interactions between them are represented by edges (see Fig. 1). A node can be dotted with ports representing connexion points to edges or inner/outer names. A control is also associated to each node; consisting of node type identifier that belongs to a set called signature. Each control indicates node number of ports , which controls are atomic for empty nodes and which of the non-atomic controls are active or passive. The inner names and outers names of a bigraph indicate connecters to which other bigraphs or roots can be connected. Sites represent holes into which a root or node can be nested, they are considered as an abstraction indicating the presence of other elements. Definition [4]: a bigraph is formally defined by G = (V, E, ctrl, GP , GL ) : I → J, I =< m, x >, J =< n, y >, where: • V and E represent finite sets of nodes and edges respectively. • ctrl : V → K a control map that assigns a control to each node. The signature K is a set of controls. P L • G and G are Place and Link graphs respectively. • I and J represent inner and outer names (interfaces) respectively of the bigraph G.

Figure 1.

B. PRELIMINARIES OF MAUDE Maude [5] is a formal declarative programming language based on rewriting logic [6, 7] supporting executable specification. Introduced initially by Jos Meseguer, Maude is a simple, expressive and powerful language. It is considered among the best languages in the field of algebraic specification and concurrent systems modelling. Maude system includes two main components CoreMaude and Full-Maude. Core-Maude component implements a rewriting engine and provides basic constructs of Maude language. Full-Maude component is a meta-level application written in Core-Maude and extending it with object oriented concepts such as objects, configurations and messages . A configuration has typically a multi-set structure made up on objects and messages and is declared as follows: -*- : Configuration Configuration → Configuration An object in a given configuration is represented by < O : C | a1 : v1,...,an : vn >, where O is object identifier, C is a class identifier; ai represents an attribute identifier and vi its actual value. The dynamic behavior of object oriented systems is specified using rewrite rules. A rewrite rule consists of two parts. The left hand side of a rule represents the initial configuration being satisfied so that the rewriting rule can be triggered. The right hand side of a rule represents the final state. Consider the following rule: rl [ r1 ] : < O : C | a1 : v1 > => < O : C | a1 : v1 + v3 >, the rewrite rule r1 modifies a1 attribute value of object O.

The anatomy of bigraphs

III. A BIGRAPHICAL MODEL FOR CLOUD COMPUTING ARCHITECTURE

In addition to the graphical representation, a term algebraic language is defined to specify bigraphs, language primary operations and elements are summarized in Table I.

Before presenting our formal bigraphical model of cloud architecture, we briefly recall cloud computing basic architectural elements.

Table I TERMS LANGUAGE FOR BIGRAPHS Term

Signification

U ||V

Juxtaposition of roots

U |V

Juxtaposition of nodes

U ◦V

Composition

U ·V

Nesting( U contains V)

/x · U

U with outer name x replaced by an edge

A. Fundamental Cloud architectural Aspects At a high level of abstraction, cloud computing system is considered as a set of computing resources (e.g. data centers, servers, services) that are distributed across multiple computing sites, and are often referred to as nodes. These resources are provided as on demand services; that users (clients) can consume. Thus, two types of entities are identified in cloud computing: front-end and back-end interacting via the Internet.

360

The front-end represents client interface to be used to access the cloud. Clients are classified into two kinds: end users, i.e., simple cloud service consumers and developers (independent software vendor), i.e., costumers exploiting the cloud (e.g. Google Apps, Codeita ) to host their applications. The back-end is the cloud service provider. It provides a complete system for allocating the required resources to execute user applications and managing the entire system flow. The cloud contains many resources as: • Data centers: physical facilities used to gather cloud computing resources and components. • Load balancers: devices responsible of service requests rooting and resources provision. • Servers: represent infrastructures of calculation and execution. • Virtual machines (VMs): abstractions of the underlying infrastructure.

load balancer while the second port is used to communicate with different clients. To allow cloud architecture elasticity by dynamically deploying new resources as data centers, load balancers or servers, virtual machines and services, we expect site 4, site 3, site 2 and site 1.

B. Bigraphical Model of Cloud Computing Architecture

A generic algebraic specification of cloud bigraph is as follows: Cx |d0||DC.(LBx |SE.(V M.(S|d1)|d2)|d3)|d4 The signature associated to a cloud bigraph is as follows: K = { L: (0, active), N :( 2, atomic)}, L and N represent controls associated to the different nodes. The different nodes types used in the model and their associated controls are summarised in Table III.

Figure 2.

Bigraphs represent a sophisticated tool to formalize architectural cloud computing elements. In Table II we summarize fundamental elements intervening in cloud architecture and their corresponding ones in BRS theory. Table II CORRESPONDENCE BETWEEN CLOUD COMPUTING AND BRS CONCEPTS

Bigraphical model of cloud computing architecture

Table III NODES TYPES OF CLOUD COMPUTING ARCHITECTURE

Cloud architecture element

Bigraph element

Node

Control

Attribute

Arity

Meaning

Client, Data center, Load balancer, Server, Service, Virtual machine.

Node

C

N

Atomic

2

Client

DC

L

Active

0

Data center

Physical or logical Location of the Client and the Cloud

Root

LB

N

Atomic

2

Load balancer

Various types of Links between the different elements

Edge/Hyper Edge

SE

L

Active

0

Server

VM

L

Active

0

Virtual machine

Abstract elements

Site

S

N

Atomic

2

Service

Generally, a cloud bigraph is composed of two different roots (0, 1) (see Fig. 2) representing client and cloud physical/logical locations. Each client (denoted by C) is dotted with two ports, the first port is connected to an outer name x to be used when connecting to the cloud, the second port is used as a direct communication medium between clients and services. Site 0 in root 0 indicates that there might be other clients in this root. Root 1 defines a back end entity of cloud architecture. It may contain a data center node (denoted by DC), responsible of gathering cloud components. The LB node represents a load balancer; it has two ports, the first port is connected to an inner name x representing communication interface with clients while the second port is used for communicating with the rest of DC node components. LB node is responsible of service requests rooting and resources provision. The rest of the nodes denoted by SE, VM and S represent respectively a server, virtual machine and service. Service node has two ports, the first one used to connect to a

C. Modelling Cloud Computing Architectural Reconfiguration Albeit, bigraphs are enough to formally specify cloud architectural components and their interaction scheme, they are not sufficient to represent cloud architectural behavior. Therefore, Cloud architecture dynamics is formalized using reaction rules expressing changes of form in terms of shape shifting or elasticity while preserving cloud architectural constraints. A number of reaction rules; expressing cloud architecture dynamics, are defined. As an example, we consider a virtual machine migration reaction rule (see Fig. 3). It expresses the fact that a virtual machine may migrate from an excessively loaded host server to a less loaded server. A loaded server is expressed in our model by the absence of a site in this server. In the redex below, we can see an excessively loaded server (denoted SE).

361

previously identified nodes. Such model to model transformation, BRS to maude specifications for instance is automatically realized through BiCloud2Maude tool that we have implemented for this purpose. We present in what follows Maude formal specification treating structural aspects of cloud computing architecture and its dynamics. A. Mapping of Structural Aspects Cloud bigraphs nodes are mapped into classes with respect to their hierarchy; preserved via a judicious choice of class attributes types. The various classes are declared in MANAGE-SERVICE-IN-CLOUD module (see Fig. 4).

Figure 3.

Virtual machine migration reaction rule

x/Dxe0e1 ||DC.(LBxe0e2 |SE.(V M.(Se1e2 ))|d3)|d4 →

Figure 4.

x/Dxe0e1 ||DC.(LBxe0e2 |SE|SE1.(V M.(Se1e2 |d1)|d2)|d3|d4

The presented rules are just few examples of many other reaction rules that can be expressed through our model as client interaction with the cloud (e.g. service deployment, connection/disconnection from the cloud/service) or to cloud architecture elasticity (e.g. service instance replication, service migration to other virtual machine). Table IV shows the algebraic specifications of some of these reaction rules.

As shown in Fig. 4, we have maintained the same cloud architectural components identified in our cloud bigraph specification. client, data center, load balancer, server, virtual machine and service nodes are all transformed to classes while client type (developer, end user) is expressed via subclasses of client class. Nodes hierarchy is expressed troughs attributes of type set of objects identifier (set Oid). For example, the DataCenter class has two attributes loadbalancers and servers of type setOid representing load balancers and servers actually contained within the given DataCenter object. Boolean attributes connected, loaded and saturate represent the possible states of respectively LoadBlancer, Server, Vm objects.

Table IV REACTION RULES EXAMPLES Connecting client to a service reaction rule x/EUxe0 ||DC.(LBxe0e2 |SE.(V M.(Se2 )|d2)|d3)|d4

→

x/EUxe0e1 ||DC.(LBxe0e2 |SE.(V M.(Se2e1 )|d2)|d3)|d4

Deploying a new service reaction rule x/EUxe0e1 |Dxe0 ||DC.(LBxe0e2 |SE.(V M.(Se1e2 |d1)|d2)|d3)|d4

→

B. Mapping of Dynamic Aspects

x/EUxe0e1 |Dxe0e3 ||DC.(LBxe0e2 |SE.(V M.(Se1e2 |S1e2e3 )|d2)|d3)|d4

Once initial configuration is automatically generated by BiCloud2Maude tool reflecting cloud bigraph architecture, we need to specify architectural dynamics via rewrite rules. These rewrite rules correspond to reactions rules mapping in Maude. Our mapping rules of bigraph cloud architecture and dynamics are specified in our specification, MANAGESERVICE-IN-CLOUD module; contains the rewrite rules declarations. For the sake of the presentation, we only give virtual machine migration rewriting rule (see Fig. 5).

Service migration reaction rule x/Dxe0e1 ||DC.(LBxe0e2 |SE.(V M.(Se1e2 )|d2)|d3)|d4

Classes syntactic declarations

→

x/Dxe0e1 ||DC.(LBxe0e2 |SE.(V M |V M 1.(Se1e2 |d1)|d2)|d3)|d4

IV. IMPLEMENTING BIGRAPHICAL CLOUD MODEL BRS present an elegant solution to model cloud computing architecture and its dynamics. Yet, the existing tools around BRS, as BigMC [8], BPLTool [9] and DBtk [10], are very limited and specific to some application domains. Maude language presents an excellent solution to implement the obtained cloud bigraphical model. It is very expressive and it has useful tools developed around it. Cloud architecture bigraph is mapped to an initial configuration module called MANAGE-SERVICE-IN-CLOUDCONF acting as a starting point in our specification and containing a set of classes instances corresponding to the

Figure 5.

362

Virtual machine migration rewriting rule

Rewrite rules in this specification are all declared as nonexecutable for the following reasons. Executing rules that contain objects with some attributes of type Set Oid (object identifier) requires a controlled execution via strategies to avoid eventual inconsistencies, since the rewrite engine cannot control such execution. Thus, the designer might defined his own execution strategies indicating execution paths to be explored. In our case, a strategy is defined in MANAGE-SERVICE-INCLOUD-CONF module as a sequence of rules application. Figure 6.

V. MODEL EXECUTION RESULTS In this section, we present a scenario of cloud architecture shape shifting via executing a set of reaction rules and thus rewrite rules. We consider that a developer client is connecting to a cloud in order to deploy a new service (e.g. word-processing service). Let us suppose that the cloud architecture is actually composed of a single instance of each cloud component (data center, load balancer, server virtual machine and service). After service deployment, we suppose that the host server becomes excessively loaded. Thus, service host virtual machine has to migrate to another server. We present here a scenario of cloud architecture shape shifting via executing a set of reaction rules and thus rewrite rules. We consider a developer client is connecting to a cloud in order to deploy a new service (e.g. word-processing service). Let us suppose that the cloud architecture is actually composed of a single instance of each cloud component (data center, load balancer, server virtual machine and service . After service deployment, we suppose that the host server becomes excessively loaded. Thus, service host virtual machine has to migrate to another server. From the previous scenario, we exploit BiCloud2Maude environment to edit a cloud bigraph, generate the initial configuration and execute a set of reconfiguration rules on the obtained configuration. BiCloud2Maude environment is composed of a BiCloud Editor and BiCloud2Maude Generator tools. • BiCloud Editor: is a graphical editor, based on EMF/GMF framework, for editing cloud bigraphs and their dynamics via reaction rules. • BiCloud2Maude Generator: is an XML parser tool implemented in Java using the JDOM API (Java Document Object Model); it allows generating MANAGESERVICE-IN-CLOUD-CONF module defining the initial cloud configuration corresponding to the cloud bigraph previously edited with BiCloud Editor. The initial configuration of cloud architecture bigraph is obtained by a simple click on BiCloud2Maude Generator tool. It receives an XML file as input and generates a Maude specification called MANAGE-SERVICE-INCLOUD-CONF. The obtained specification file is edited with Maude Workstation in Fig. 6.

Generated file visualised with Maude Workstation

Using the obtained initial configuration representing initial state of the cloud architecture and by applying Deploying a new service rewrite rule and Virtual machine migration one in sequence, as a strategy shown in Fig. 7, we obtain the resulting configuration of Fig. 8 that represents the execution final state.

Figure 7.

Execution strategy of a cloud shape shifting

As shown in Fig. 8, a new service named ServiceWR is created in VM1, we can also observe that VM1 has changed its host server (migrate from loaded server1 to server2).

Figure 8.

The resulting final state

VI. RELATED WORK In the context of formalizing cloud computing and cloud elasticity, researchers focusing on cloud computing formalization have proposed few works. T. Grandison et al. [11] tries to tackle the lack of consensus or base comprehension on technical constituents of a cloud by presenting an initial formal definition of cloud computing. H. Dong et al. [12] provide some discussion on the relationship between cloud computing and virtualization and tries also to propose a formal definition of cloud

363

computing from the viewpoint of virtualization. In [13] Y. Jarraya et al., a formal framework for the specification of virtual machines migration and the associated security policies in the cloud is presented using a process algebra approach, it allows verifying the preservation of the global security policy within the new configuration after virtual machines migration. L. Freitas et al. [14] present an abstract formalization of federated cloud workflows using the Z notation. A. Gambi et al. [2] define a systematic modelbased test generation framework that enables testing the elastic properties of cloud systems. In [15] Z. Benzadri et al., a formal specification adopting Bigraphical Reactive Systems is proposed for cloud services and customers and their interaction schemes. K. Klai et al. [16] propose a formal model adopting Petri nets for describing elasticity mechanisms and their strategies for service-based business processes in cloud environments. M. Amziani et al. [17] propose a formal model for service-based business processes elasticity and a framework to evaluate elasticity strategies. An extension of the approach to support stateful servicebased business processes have been proposed in [18].

[2] A. Gambi, A. Filieri, and S. Dustdar, ”Iterative test suites refinement for elastic computing systems”, In Proceedings of the 2013 9th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2013). ACM, New York, USA, pp. 635-638. [3] R. Milner, ”Bigraphs and their algebra”, In Proceedings of the LIX Colloquium on Emerging Trends in Concurrency Theory (LIX 2006), Electronic Notes in Theoretical Computer Science, Volume 209, Elsevier, 2008, pp. 5-19. [4] R. Milner, ”The Space and Motion of Communicating Agents”, Cambridge University Press, 2009. [5] M. Clavel, F. Duran, S. Eker, P. Lincoln, N. Martf-Oliet, J. Meseguer, and C. L. Talcott, ”All About Maude”, A HighPerformance Logical Framework, volume 4350 of Lecture Notes in Computer Science. Springer, 2007. [6] J. Meseguer, ”Conditional Rewriting Logic as a unified Model of Concurrency”, Theoretical Computer Science , 1992 ,pp. 73-55. [7] N. Marti-Oliet, and J. Meseguer, ”Rewriting logic: Roadmap and bibliography”, Theoretical Computer Science 285(2), 2002, pp. 121154. [8] G. Perrone, S. Debois, and T. Hildebrandt , ”A model checker for bigraphs”, In Ossowski, S., Lecca, P., eds.: SAC, ACM , 2012, pp. 1320-1325. [9] A.J. Glenstrup , T.C. Damgaard, L. Birkedal, and E. Hjsgaard , ”An implementation of bigraph matching”, Technical Report 2010-135.Copenhagen : IT-Universitetet Kobenhavn, 2010. [10] G. Bacci , D. Grohmann, and M. Miculan, ”Dbtk: A toolkit for directed bigraphs”, 2009. [11] T. Grandison, E.M. Maximilien, S. Thorpe, and A. Alba, ”Towards a formal definition of a computing cloud”, 6th World Congress on Services, SERVICES 2010, IEEE Computer Society 2010, pp 191-192. [12] H. Dong, Q. Hao, T. Zhang, and B. Zhang ”Formal discussion on relationship between virtualization and cloud computing”, In Parallel and Distributed Computing, Applications and Technologies (PDCAT), 2010 International Conference on, 2010, pp. 448-453. [13] Y. Jarraya, A. Eghtesadi, M. Debbabi, Y. Zhang, and M. Pourzandi, ”Cloud calculus: Security verification in elastic cloud computing platform”, In International Symposium on Security in Collaboration Technologies and Systems (SECOTS 2012), IEEE Press, 2012, pp. 447-454 [14] L. Freitas, and P. Watson, ”Formalising workflows partitioning over federated clouds: Multi-level security and costs”, In Services (SERVICES), 2012 IEEE Eighth World Congress on, 2012, pp. 219-226. [15] Z. Benzadri, F. Belala, and C. Bouanaka, ”Towards a Formal Model for Cloud Computing”, In ICSOC 2013 Workshops, 2013. [16] K. Klai, and S. Tata, ”Formal Modeling of Elastic ServiceBased Business Processes”, Services Computing (SCC), 2013 IEEE International Conference on , pp. 424-431, 2013. [17] M. Amziani, T. Melliti, and S. Tata, ”Formal Modeling and Evaluation of Service-Based Business Process Elasticity in the Cloud”, 22nd IEEE International Conference on Collaboration Technologies and Infrastructure ( WETICE 2013), Hammamet, Tunisia, 2013, pp. 284–291. [18] M. Amziani, T. Melliti, and S. Tata, ”Formal Modeling and Evaluation of Stateful Service-Based Business Process Elasticity in the Cloud”, On the Move to Meaningful Internet Systems OTM 2013 Conferences, Springer, 2013.

VII. CONCLUSION In this work, we have proposed a modelling and execution formal approach where elastic cloud computing architecture models can be specified. Therefore, we have presented two models. A BRS (for Bigraphical Reactive Systems) based model for designing and reconfiguring cloud architectures. Cloud Bigraphs graphical and formal basis simplify considerably cloud architectures readability. Unfortunately, BRSs lack operational tools to execute and verify the obtained specifications. To overcome this problem, we have proposed a mapping engine to obtain an executable formal specification implemented in Full Maude language. The automatically generated specifications and reconfiguration rules execution is realized with respect to system integrity and consistency via a Maude strategy. To assist designers of cloud architectures and their structural dynamics, we have implemented the proposed models within a BiCloud2Maude environment. The later combines the expressive power and performance characteristics of BRSs and Maude respectively. This coupling has been achieved through BiCloud Editor and BiCloud2Maude Generator tools. In our ongoing work, we plan to formally analyze and verify some cloud architectures inherent properties as service availability and denial of service. R EFERENCES [1] P. Mell, and T. Grance, ”The nist definition of cloud computing”, Technical Report, National Institute of Standards and Technology (NIST), Gaithersburg, MD, 2011, pp. 800-145.

364