Towards a Standards-based Cloud Service Manager

Amine Ghrab

, Sabri Skhiri

, Hervé Kœner

and Guy Leduc

Eura Nova R&D, Mont-Saint-Guibert, Belgium

Electrical Engineering and Computer Science Department, University of Liège, Liège, Belgium

Keywords:

Cloud Computing, OCCI, Service Management.

Abstract:

Migrating services to the cloud brings all the beneﬁts of elasticity, scalability and cost-cutting. However, mi-

grating services among different cloud infrastructures or outside the cloud is not an obvious task. In addition,

distributing services among multiple cloud providers, or on a hybrid installation requires a custom implemen-

tation effort that must be repeated at each infrastructure change. This situation raises the lock-in problem

and discourages cloud adoption. Cloud computing open standards were designed to face this situation and to

bring interoperability and portability to cloud environments. However, they target isolated resources, and do

not take into account the notion of complete services. In this paper, we introduce an extension to OCCI in

order to support complete service deﬁnition and management automation. We support this proposal with an

open-source framework for service management through compliant cloud infrastructures.

1 INTRODUCTION

Cloud computing provides an infrastructure empha-

sizing resources multiplexing, data locality, and elas-

ticity. However, current offerings still present inher-

ent interoperability and portability issues. Interoper-

ability enables different services deployed on differ-

ent cloud infrastructures to exchange through com-

mon interfaces, without the need to provide a speciﬁc

adapter for each separate API. Portability introduces

common formats by which services are described and

deployed independently from the provider.

To tackle these issues, we operated at the IaaS

Service Manager level and we selected Open Cloud

Computing Interface (OCCI)

as the cloud manage-

ment interface. Reservoir (Rochwerger et al., 2009)

proposes a well deﬁned architecture as well as an

open source implementation. Within this architecture,

services are comprised as sets of inter-related vir-

tual machines along with their attached storage, net-

works and conﬁguration settings. Service managers

help users switch from individual VM management to

whole services management, thus focusing more on

their business goals. On the other hand, OCCI pro-

vides common mechanisms for services description,

discovery and management. The OCCI-based service

deﬁnition is processed by the service manager which

http://occi-wg.org

then handles the deployment, provisioning and SLA

enforcement of the service.

In this paper we propose two contributions, (1) we

extend the OCCI standard to support cloud service

managers, and (2) we provide a reference implemen-

tation as an open-source tool to seamlessly manage

the services deployed within standards-based cloud

offerings.

The paper is organized in three parts. To solve the

above-mentioned issues, Section 2 introduces our ap-

proach based on cloud computing open standards and

highlights the design and implementation of our so-

lution. Section 3 proposes future research directions

to tackle the remaining issues. Section 4 describes

related works and how our solution goes beyond the

state of the art.

2 OCCI SERVICE MANAGER

2.1 OCCI

OCCI is an initiative from the Open Grid Forum

(OGF)

to provide a standard RESTful Protocol and

API for the management of cloud resources. Open-

Nebula and OpenStack already provide OCCI com-

pliant interfaces (Edmonds et al., 2012).

http://www.ogf.org/

127

Ghrab A., Skhiri S., Koener H. and Leduc G..

Towards a Standards-based Cloud Service Manager.

DOI: 10.5220/0004372201270130

In Proceedings of the 3rd International Conference on Cloud Computing and Services Science (CLOSER-2013), pages 127-130

ISBN: 978-989-8565-52-5

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

Resources representation is based on a type sys-

tem described in the core model document of the

speciﬁcation (Metsch et al., 2010c). Within this

model, a hierarchy governs cloud resources, which

eases their classiﬁcation and thereof their identiﬁca-

tion. The central type of the OCCI model is Resource

which represents the resources offered by the cloud

provider. Resources relationships are modeled using

Link. Resource and Link inherits both from Entity,

which is an abstract class complementing Category.

Category is used for uniquely typing and identifying

resources within the underlying system. Category is a

superclass for Kind and Mixin. Kind deﬁnes resource

characteristics and serves as the base of the classiﬁ-

cation system. Mixin enables dynamic addition and

removal of capabilities from the resource. Action is

attached to mixins and kinds and denotes the opera-

tions a resource could perform.

An extension of the core model to cover IaaS level

is depicted in the infrastructure model (Metsch et al.,

2010a). The extensibility of OCCI enables to repre-

sent a wide range of resources and perform complex

operations on them, such as management of databases

and key-value stores (Edmonds et al., 2011a).

The third document released by OGF is the OCCI

HTTP speciﬁcation (Metsch et al., 2010b). Resources

in this representation are identiﬁed and accessed using

unique URI. As it is a RESTful API, the management

of resources is done through the basic HTTP oper-

ations POST, GET, PUT and DELETE that perform

Create, Retrieve, Update and Delete operations.

The purpose of OCCI is not to cover all possible

cloud management tasks, instead it offers a common

infrastructure on top of which cloud offerings could

be built (Edmonds et al., 2011b). Obviously, the set

of supported operations is limited compared to those

offered by speciﬁc cloud offerings. However, exten-

sions to OCCI or direct use of the providers API re-

mains as available options.

2.2 OCCI Extension

A service manager should provide a uniform manage-

ment interface to handle the deployment and the mon-

itoring of whole interrelated entities while encapsu-

lating low-level management details. Here we sug-

gest an extension to the core speciﬁcation of OCCI

and we built our service manager atop. The extension

introduces the concepts related to cloud IaaS service

management such as Service, Role, Group and depen-

dency (see Fig. 1):

1. Role: A conﬁgured virtual machine fulﬁlling a

speciﬁc functionality, such as a DBMS.

2. Service: A set of interconnected roles serving a

determined goal, such as web portal.

3. Group: A set of roles with the same initial con-

ﬁguration. The elasticity aspect of the service is

reﬂected by adding and removing group members.

4. Dependency: Describe an order relationship be-

tween roles. If role A needs a role B to be avail-

able before being able to start, then A is called

dependent on B.

A typical use case is a web service which could be

deﬁned as a set of interdependent roles that the user

selects, classiﬁes within groups and deﬁnes their de-

pendencies. Figure 2 depicts such scenario.

Resource

+summary: string

+occi.service.state:Enum

Service

+occi.service.state: Enum

Role

+occi.group.max: int

+occi.group.min: int

+occi.group.size : int

Group

+occidependency.priority: int

Dependency

+summary: string

Link

target

source

links

1 1..*

Figure 1: Service Manager Class Diagram.

Figure 2: Service Deployment Example.

2.3 Implementation

We have implemented OCCI Service Manager

a proof-of-concept for our extension to the OCCI

model. The framework allows the user to deﬁne the

https://github.com/KoenerHerve/Service-Manager

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

128

service, to start it and to dynamically allocate under-

lying resources. The descriptions of the resources and

the users proﬁles are stored in a MySQL database.

The OCCI Service Manager offers a web interface

and a RESTful API to enable users to start, stop vir-

tual machines and to retrieve different monitoring in-

formation. The framework is written in Ruby and

built using the Sinatra

light-weight framework. It

stands as a middleware between end-users and the

OpenNebula OCCI server.

The ﬁrst step to deﬁne a service is to deﬁne the

roles which compose it. To create a role, the user

speciﬁes the OS template and links it to a subsequent

mixins. Mixins allow the user to specify the dynamic

add-ons of the role. For instance, we can specify

that the virtual machines of a certain role uses Cen-

tOS template and acts as an Nginx load balancer. The

second step is to deﬁne the different dependencies be-

tween roles. For instance, a load balancer depends on

web server roles before it could be started.

When the user wants to start a service, the applica-

tion starts all the virtual machines of the roles deﬁned

for the service. If the virtual machines of a certain

role have dependencies the OCCI Service Manager

starts ﬁrst the dependencies. When a virtual machine

is started, the OCCI Service Manager conﬁgures it au-

tomatically according to the mixins linked to the role

of this virtual machine. A service is started on each

of the virtual machines and acts as an agent allowing

the execution of remote commands. Once all virtual

machines are started and conﬁgured the state of the

service is set to running.

The user can perform CRUD operations on the

service or on the roles which compose it. He can also

change the behavior of the virtual machines of a cer-

tain role by linking it to another Mixin at runtime. The

roles provisioning process is depicted on Figure 3.

3 FUTURE WORKS

A service manager is assigned two main tasks. First,

resources provisioning and deployment, which our

tool already supports. Second, monitoring and

SLA compliance enforcement. Currently, we do

not include monitoring modules. We envision inte-

grating Ganglia

as our distributed monitoring sys-

tem. Scheduling helps optimize resource utilization.

Haizea

is a potential candidate to integrate schedul-

ing within our service manager. Accounting and

http://www.sinatrarb.com/

http://ganglia.sourceforge.net/

http://opennebula.org/software:ecosystem:haizea

Specify Dependencies

Start Service

Init

End

Dependencies Checking

Choose Roles

Start Base VMs

Satisfied

NOT Satisfied

VM Configuration using local Agents

Service Up

Retrieve Service

Config.

MySQL DB

Figure 3: Service provisioning process.

billing is another responsibility of a service manager.

Users are granted permissions, follow their consump-

tion and control their budget through this features. We

plan to integrate this component with a friendly user

interface for better visualization. We are also consid-

ering enriching the service manager with further fea-

tures such as full service cloning and snapshotting.

4 RELATED WORKS

Cloud providers APIs are unique and platform-

speciﬁc with no interoperability mechanisms between

them. An approach to tackle this issue is by pro-

viding a speciﬁc driver per API, as implemented by

Rightscale

and Scalr

. Deltacloud

is providing a

single entry point to developers, while maintaining a

driver per API backend.

Both approaches are interesting and widely

adopted. However, they remain dependent on the

providers proprietary APIs. They have to adapt their

drivers to meet each change on these APIs. Moreover,

they introduce an additional layer to the architecture

which might increase latency. To deal with this, we

chosen to rely on open standards. Here the API main-

tenance is handled by the cloud provider that comply

with the standards.

http://www.rightscale.com

http://scalr.net/

http://deltacloud.apache.org/

TowardsaStandards-basedCloudServiceManager

129

Claudia is a service manager supporting service

management on multiple cloud providers (Moran,

2012). The structure of the service is described using

an extension of OVF (Rodero-Merino et al., 2010).

Claudia implements a driver per API approach to sup-

port different cloud providers. In addition, it also

provides an OCCI implementation. We consider that

since OCCI is designed for service management, it

ﬁts natively better as a service descriptor than OVF.

HP IaaS Aggregator is developed by HP for the

purpose of providing common interface and descrip-

tion of IaaS services across multiple IaaS service

providers (Lee et al., 2011). It’s based on the Com-

mon Information Model(CIM)

standard, a DMTF

model to describe entities and their attributes. The

IaaS Aggregator is a cloud management console sup-

porting resources lifecycle management. OCCI is

built from the ground up to support resources man-

agement on the cloud, while CIM is a general purpose

standard for representing resources as a set of objects

and their relationships. Furthermore, network topol-

ogy descriptions are not very well supported by CIM

(Ghijsen et al., 2012).

5 CONCLUSIONS

Currently customers who plan to migrate their ser-

vices to the cloud face the threat of being locked-

in. As interoperability and portability are traditional

drivers for standards development, we decided to refer

to cloud computing open standards as the backbone to

solve these problems.

Targeting cloud computing end-users, we built our

solution as an open-source service manager. We have

ﬁrst extended the OCCI standard to support service

management. We then implemented the solution. The

result is a tool that abstracts the underlying vendors

APIs details. It helps users deploy and manage their

services seamlessly among open standards compliant

clouds. The project is in progress, further works needs

to be done in order to provide a complete solution that

covers advanced cloud service management features.

On the open standards side, speciﬁcations need to be

enriched in order to cover more cloud functionalities

and gain market acceptance.

ACKNOWLEDGEMENTS

We wish to thank Salim Jouili for his comments on

the draft.

http://dmtf.org/standards/cim

REFERENCES

Edmonds, A., Metsch, T., and Papaspyrou, A. (2011a).

Open cloud computing interface in data management-

related setups. volume 1, pages 23–48. Springer.

Edmonds, A., Metsch, T., and Papaspyrou, A. (2011b).

Open Cloud Computing Interface in Data

Management-Related Setups, volume 1, pages

23–48. Springer.

Edmonds, A., Metsch, T., Papaspyrou, A., and Richardson,

A. (2012). Toward an open cloud standard. Internet

Computing, IEEE, 16(4):15–25.

Ghijsen, M., van der Ham, J., Grosso, P., and de Laat, C.

(2012). Towards an infrastructure description lan-

guage for modeling computing infrastructures. In

Parallel and Distributed Processing with Applications

(ISPA), 2012 IEEE 10th International Symposium on,

pages 207–214. IEEE.

Lee, B., Yan, S., Ma, D., and Zhao, G. (2011). Aggregating

iaas service. In SRII Global Conference (SRII), 2011

Annual, pages 335–338. IEEE.

Metsch, T., Edmonds, A., et al. (2010a). Open cloud com-

puting interface–infrastructure. In Standards Track,

no. GFD-R in The Open Grid Forum Document Se-

ries, Open Cloud Computing Interface (OCCI) Work-

ing Group, Muncie (IN).

Metsch, T., Edmonds, A., et al. (2010b). Open cloud

computing interface–restful http rendering. In Stan-

dards Track, no. GFD-R in The Open Grid Forum

Document Series, Open Cloud Computing Interface

(OCCI) Working Group, Muncie (IN).

Metsch, T., Edmonds, A., and Nyrén, R. (2010c). Open

cloud computing interface–core. In Open Grid Fo-

rum, OCCI-WG, Speciﬁcation Document. Available

at: http://forge. gridforum. org/sf/go/doc16161.

Moran, D. (2012). Claudia Service Management Platform,

page 113. Information Science Reference.

Rochwerger, B., Breitgand, D., Levy, E., Galis, A., Nagin,

K., Llorente, I., Montero, R., Wolfsthal, Y., Elmroth,

E., Cáceres, J., et al. (2009). The reservoir model and

architecture for open federated cloud computing. IBM

Journal of Research and Development, 53(4):4–1.

Rodero-Merino, L., Vaquero, L., Gil, V., Galán, F., Fontán,

J., Montero, R., and Llorente, I. (2010). From in-

frastructure delivery to service management in clouds.

Future Generation Computer Systems, 26(8):1226–

1240.

CLOSER2013-3rdInternationalConferenceonCloudComputingandServicesScience

130