Integration of CLEVER Clouds with Third Party Software Systems ...

Integration of CLEVER Clouds with Third Party Software Systems Through a REST Web Service Interface Antonio Celesti, Francesco Tusa, Massimo Villari and Antonio Puliafito Dept. of Mathematics, Faculty of Engineering, University of Messina Contrada di Dio, S. Agata, 98166 Messina, Italy. e-mail: {acelesti, ftusa, mvillari, apuliafito}@unime.it

Abstract— Nowadays, a typical scenario in the panorama of cloud computing includes an IaaS cloud provider offering ondemand VM hosting services to its clients. In this field, famous examples of large scale commercial providers are Amazon and Rackspace. However, how to arrange analogous services with open source tools is not totally clear. Moreover, the integration between the IaaS cloud middleware with third party legacy software systems, today, represents a difficult task to accomplish. CLEVER is an open source cloud IaaS middleware allowing the allocation and management of VMs. In this paper, through the development of a REST interface, we discuss how a CLEVERbased cloud provider can be integrated with third party systems, hence satisfying their VM allocation requests. Keywords- Cloud Computing; CLEVER; IaaS; System Integration.

I. I NTRODUCTION Cloud computing offers more than a “pay-per-use model” including IT Efficiency and Business Agility, that allow companies to minimize costs and maximize their revenues, using the IT as a competitive weapon against the rapid times to market [1]. Nowadays, in the panorama of cloud computing, concepts such as large-scale, abstraction, and virtualization are highly interesting topics. In addition, cloud computing has also to address the dynamic resource management involving different providers and legacy systems across the Internet. In order to provide a flexible use of resources, cloud computing delegates its functionalities in a virtualization context, treating traditional hardware resources like a pool of virtualized ones. In addition virtualization enables the ability of migrating resources, regardless of the underlying real physical infrastructure. Therefore, using virtualization and aggregating virtualized resources, also mapped in different physical hardware, clouds provide services at three different levels: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) [1]. Currently, considering IaaS clouds, examples like Amazon, Microsoft, and Rackspace represent the major commercial providers able to supply to their clients (i.e., other clouds,

organizations, governments, ICT companies, or single desktop/web/mobile human end-users) on-demand VMs. At the same time, interest is growing in open source tools that let organizations build their own IaaS clouds using their internal computing resources [2]. The main purpose of such clouds is not only to provide and sell computing capacity over the Internet through public web interfaces, but also providing to their clients a flexible and agile private infrastructure to run service workloads within their administrative domains. In this context an important issue to be addressed is the integration between the cloud IaaS provider with third party software systems through public web interfaces. The CLoud-Enabled Virtual EnviRonment (CLEVER1 ) [3], is a research open source project designed at the University of Messina, representing a Virtual Infrastructure Management (VIM) middleware for the administration of IaaS clouds. Differently from the other middleware existing in the literature, CLEVER also provides a simple and easily accessible interface by means of it is possible to access a widely range of its features. Typically, using CLEVER, administrators can control the cloud using and interactive administration console. In this paper, in order to address a scenario in which different third party legacy software systems can access to CLEVER features, we developed a REST-based web service administration tool compatible with the Open Cloud Computing Interface (OCCI). The main contribution of this paper is to study how the middleware reacts to concurrent VM allocation requests coming from different third party software systems. The rest of the paper is organized as follows: Section II provides an overview of the CLEVER architecture. In Section III, we discuss how to integrate the CLEVER middleware with other third-party software systems. Experiments and the performance analysis are presented in Section IV. An overview of other related works is provided in Section V. Conclusions and lights to the future are summarized in Section VI. 1 official

web site: http://clever.unime.it

II. T HE CLEVER I AA S C LOUD A RCHITECTURE A. Overview The CLEVER middleware is based on the architectural schema depicted in Figure 1, which shows a cluster of n nodes each containing a host level management module (Host Manager). A single node may also include a cluster level management module (Cluster Manager). All the entities interact exchanging information by mean of the Communication System based on the XMPP. The set of data necessary to enable the middleware functioning is stored within a specific Database deployed in a distributed fashion.

Fig. 1.

CLEVER architecture.

Figure 1 shows the main components of the CLEVER architecture, which can be split into two logical categories: the software agents (typical of the architecture itself) and the tools they exploit. To the former set belong both Host Manager and Cluster Manager: •

•

Host manager (HM) performs the operations needed to monitor the physical resources and the instantiated VMs; moreover, it runs the VMs on the physical hosts (downloading the VM image) and performs the migration of VMs (more precisely, it performs the low level aspects of this operation). To carry out these functions it must communicate with the hypervisor, hosts’ OS and distributed file-system on which the VM images are stored. This interaction must be performed using a plug-ins paradigm. Cluster Manager (CM) acts as an interface between the clients (software entities, which can exploit the cloud) and the HM agents. CM receives commands from the clients, performs operations on the HM agents (or on the database) and finally sends information to the clients. It also performs the management of VM images (uploading, discovering, etc.) and the monitoring of the overall state of the cluster (resource usage, VMs state, etc. ). At least one CM has to be deployed on each cluster but, in order to ensure higher fault tolerance, many of them should exist. A master CM will exist in active state while the other ones will remain in a monitoring state.

Regarding the tools such middleware components exploit, we can identify the Distributed Database and the XMPP Server, as it is shown in Figure 1.

B. Internal/External Communication The main CLEVER entities, as already stated, are the Cluster Manager and the Host Manager modules, which include several sub-components, each designed to perform a specific task. In order to ensure as much as possible the middleware modularity, these sub-components are mapped on different processes within the Operating System of the same host, and communicate each other exchanging messages. CLEVER has been designed for supporting two different types of communication: intra-module (internal) communication and inter-module (external) communication. 1) Intra-module (Internal Communication): The intramodule communication involves sub-components of the same module. Since they essentially are separated processes, a specific Inter Process Communication (IPC) has to be employed for allowing their interaction. In order to guarantee the maximum flexibility, the communication has been designed employing two different modules: a low level one implementing the IPC, and an high-level one instead acting as interface with the CLEVER components, which allows access to the services they expose. For implementing the communication mechanism, each module virtually exchanges messages (horizontally) with the corresponding peer exploiting a specific protocol (as the horizontal arrows indicate in Figure). However, the real message flow in the one indicated by the vertical arrows: when the Component Communication Module (CCM) of the Component A aims to send a message to its peer on a different Component B, it will exploit the services offered by the underlying IPC module. Obviously, in order to correctly communicate, the CCM must be aware of the interface by means of these services are accessible. If all the IPC were designed according to the same interface, the CCM will be able to interact with them regardless both their technology and implementation. Looking into the above mentioned mechanism, when the Component A needs to access a service made available from the Component B, it performs a request through its CCM. This latter creates a message which describes the request, then formats the message according to the selected communication protocol and sends it to its peer on the Component B by means of the underlying IPC module. This latter in fact, once received the message, forwards it to its peer using a specific container and a specific protocol. The IPC module on the Component B, after that such a container is received, extracts the encapsulated message and forwards it to the overlying CCM. This latter interprets the request and starts the execution of the associated operation instead of the Component A. 2) Inter-module (External Communication): When two different hosts have to interact each other, the inter-module communication has to be exploited. The typical use cases refer to: •

•

Communication between CM and HM for exchanging information on the cluster state and sending specific commands. Communication between the administrators and CM us-

ing the ad-hoc client interface. In order to implement the inter-module communication mechanism, an XMPP server must exist within the CLEVER domain and all its entities must be connected to the same XMPP room. When a message has to be transmitted from the CM to an HM, as represented in Figure 2, it is formatted and then sent using the XMPP. Once received, the message is checked from the HM, for verifying if the requested operation can be performed. Fig. 3.

Fig. 2.

Activity diagram of the external communication.

As Figure 2 shows, two different situations could lay before: if the request can be handled, it is performed sending eventually an answer to the CM (if a return value is expected), otherwise an error message will be sent specifying an error code. C. The Administration Console For different reasons such as fault tolerance goals, inside a CLEVER cloud, during its operating, the role of the Cluster Manager can be played by different devices. Therefore, it is needed to smoothly enable one or more administrators to control the cloud sending commands to the Cluster Coordinator active in that particular moment. For this reason, the CLEVER project provides a software client used as the administration console allowing to manage the cloud. As for the external communication among devices, also the interaction among the admin console and the active Host Manager takes place using XMPP. Furthermore, more admin consoles along with the active Cluster Manager interact each other through a reserved XMMP administration room. Figure 3 depicts what happens when an administrator gives a command to CLEVER. In step 1 the administrator gives a command to his/her admin console client. In step 2 the admin console creates a correspondent XML CLEVER Request message with ID 1 and forwards it on the XMPP administration room on which are connected both administrators and the active Cluster Manager. The XML CLEVER Request message is caught by the active Cluster Manager, which generates another CLEVER message for a target Host Manager making an association between the ID of

Execution of a command on the CLEVER cloud.

the CLEVER admin console client and the ID of the generated XML Request CLEVER message. In step 3 the Cluster Manager sends the message in the XMPP room on which takes place the external communication between CLEVER components (i.e., active Cluster Manager and Host Managers). The CLEVER Request message is caught by the destination Host Manager, which interprets the message and, by means of internal communication mechanisms, it queries its target plugin. When the Host Manager has received the response from its plug-in, in step 4 it envelops an XML CLEVER Response message with the same ID of step 2 and sends it on the XMPP room of the external communication. In step 5, the Cluster Manager catches the CLEVER Response message, checks the ID of the message in order to pick out a correspondence with the console ID checking its cash, and if a matching exists it create an XML CLEVER Response message marking it with the ID of the admin console client which has sent the command at step 2. In step 6, the admin console client catches the CLEVER Response message of step 5, interprets it, and displays the output in human readable way. III. H OW TO I NTEGRATE CLEVER WITH T HIRD PARTY S YSTEMS In this Section, we discuss an approach for the integration of a CLEVER-based IaaS cloud provider with different third party software systems. Considering a real business scenario, these latter can be different administrative domains held, for example, by other clouds, organizations, universities, or ICT companies. In order to encourage the adoption of CLEVER, in this Section, we propose a mechanism based on a REST web service interface. Because CLEVER is a highly modular project, the adoption of a REST-based web service interface has not consistently impacted the original design pattern. As depicted in Figure 4 the original project has been extended in order to support, besides human administrators, also third party software systems interacting with CLEVER through a REST web service interface. In order to do so, besides the “Admin Console Client with a common line interface (CLI), we developed the “Admin REST Portal”. This latter represents a point of access for different systems enabled to access CLEVER through the Internet. Comparing the two admin software clients, the interesting thing is that the only

Fig. 4.

Integration of CLEVER with different third party software systems.

change is made in the front-end (CLI vs. REST interface), whereas the back-end mechanisms for the interaction with the active Cluster Manager is the same. In fact, considering the “Admin REST Portal”, a request coming from a software system is forwarded through the REST web service interface, it is scheduled and processed formatting and forwarding the corresponding CLEVER message request to the “Administration XMPP Room”. To this regard, from the point of view of CLEVER the messaging on the external communication XMPP channel is the same for both the Admin clients. In fact, the message flow of a request coming from the “Admin REST Portal” is the same of a request coming from the admin console client. Considering the “Admin REST Portal”, third party systems access to CLEVER services through the HTTP protocol and its four methods: GET, PUT, POST e DELETE. The choice of the REST technology is driven by the higher performance compared to other web service technologies such as SOAP. Considering the front-end, the interactions of different systems accessing CLEVER are isolated, as well as for traditional web applications, by means of a session tracking mechanism. The developed REST web services are summarized in Table III. In order to allow a third party system to access CLEVER, it is needed a preliminary phase of authentication and session establishment. Figure 5 depicts the corresponding sequence diagram. The messaging flow for the other web services depicted in Table III is analogous. The most important web service is the one depicted in the second row of Table III. It allows to third party system to send commands to CLEVER, after its authentication and session establishment. The followings are several examples of web services allowing to perform management tasks on CLEVER: •

•

•

http://localhost:8080/WS/rest/third-partysystem?listclustermanager. It returns to “thirdparty-system” the list of Cluster Managers of the current CLEVER administration domain. http://localhost:8080/WS/rest/third-partysystem/listvms/-h/ing-clever-master. It returns to “third-party-system” the list of allocated VMs on the “ing-clever-master” administrative domain. http://localhost:8080/WS/rest/third-party-

URL http://address:port/WS/ rest/set?server/port/ username/password/ nickname/room http://address:port/WS/ rest/username?command/ option1/option2/...? value1&value2/... http://address:port/WB/ rest/verify/username http://address:port/WB/ rest/invalidate http://address:port/WB/ rest/set/ttl?value

Description

Logs a third party system

Sends a CLEVER command Verifies access credentials Invalidates the session Sets the session TTL

TABLE I REST WEB SERVICES EXPOSED BY THE “A DMIN REST P ORTAL”

Fig. 5. Sequence diagram for the authentication and session establishment of a third party system on CLEVER through the “Admin REST Portal”

•

system?startvm/-h/ing-clever-master/-onlycreate/n/Rest-test. It allows “third-party-system” to start a VM named “Rest-test” on the “ing-clever-master” administrative domain. http://localhost:8080/WS/rest/third-partysystem?stopvm/-h/ing-clever-master/-n/Rest-test. It allows “third-party-system” to stop a VM named “Rest-test” on the “ing-clever-master” administrative domain. IV. E XPERIMENTS

In this Section, we present several experiments regarding the simultaneously management of different third party systems on CLEVER cloud. More specifically, we considered a scenario

including four third party systems, each one simultaneously sending four VM start requests to CLEVER through the “Admin REST Portal”. For simplicity, we assumed that each system is already authenticated and operating on a valid session. Moreover, we assumed that all the involved VMs are equal. In order to arrange a testbed representing such a scenario, we simulated the four software system on four different hosts connected through a Local Area Network (LAN) with the active Cluster Manager. In order simulate a situation where each software system sends the VM starting requests simultaneously, we synchronize the four hosts using the NTP protocol. Experiments have been performed on Ubuntu OS, and on hardware CPU Intel(R) Core(TM)2 Duo T9400 2,53 GHz, RAM 4 GB. As experiments have been performed in a dedicated LAN, they are not affected by network latency. The measures we present are the results that we have obtained on average of more proofs for each experiment and the 95% of confidence interval. Figure 6 depicts the mean values of the time needed for a task of four VM starting requests for each one of the four third party systems. The x-axis represents the number of started VMs, whereas the y-axis represents the time. Experiments show how each simulated system takes about the same time of other ones for starting four VMs. Considering the four third party systems, a slight difference in times for the allocation of VMs is due to different scheduling conditions sometime causing aborting and re-submission of requests. For example, having a look to the graph of Figure 6, System 1 employs about 340 msec for starting its own VM 4, instead System 3 employs about 380 msec for starting its own VM4. However the slight gap on analogous tasks performed by different third party systems prove the goodness of the scheduler of the “Admin REST Portal” server. Figure 7 summarizes the

Fig. 6. Mean values for each one of the four systems sending VM starting requests to CLEVER through the Admin REST Portal.

gathered results showing the mean values considering the times of the four simulated third party software systems. V. R ELATED W ORKS Hereby we describe the current state-of-the-art in cloud computing analyzing the main existing middleware implementations. Before such a description it is interesting to point out

Fig. 7. Mean values of four systems sending VM starting requests to CLEVER through the Admin REST Portal.

the results of Sempolinski and Thain work published in 2010 [4]. They provided a comparison among three widely used architectures: Nimbus, Eucalyptus and OpenNebula. They remarked how the projects are aimed at different goals, but a clear convergence is recognizable. The authors posed three main questions, one about who has a complete cloud computing software stack. It is common in the three architectures that the actual cloud controller is only a small part of the overall system. The second one is who is really customizable. These are open-source projects, and the appeal of setting up a private cloud, as opposed to using a commercial one, is that the administrator can have more control over the system. They support standard API interfaces (i.e., front-end that uses a subset of the EC2 interface), and they are often one of these customizable components. The last one is about the degree of transparency in the user interface. One of the main shared opinions in the commercial cloud setting is the black-box nature of the system. The individual user, is not aware where, physically, his VMs are running. In a more customizable open-source setting, however, opportunities exist for a greater degree of explicit management with regard to the underlying configuration of physical machine and the location of VMs on them. We remark as the authors of such a work have not recognized any features suitable for the cross cloud management. Nimbus [5] is an open source toolkit that allows to turn a set of computing resources into an Iaas cloud. It was conceived from designers originally becoming from the GRID world. Nimbus comes with a component called workspace-control, installed on each node, used to start, stop and pause VMs, implements VM image reconstruction and management, securely connects the VMs to the network, and delivers contextualization. Nimbus’s workspace-control tools work with Xen and KVM but only the Xen version is distributed. Nimbus provides interfaces to VM management functions based on the WSRF set of protocols. There is also an alternative implementation exploiting Amazon EC2 WSDL. Its Federation system exploits the GRID-like existing functionalities. It leverages Virtual Organization (VOs) of GRID for controlling the access on virtual resources.

Eucalyptus [6] is an open-source cloud-computing framework that uses the computational and storage infrastructures commonly available at academic research groups to provide a platform that is modular and open to experimental instrumentation and study. Eucalyptus addresses several crucial cloud computing questions, including VM instance scheduling, cloud computing administrative interfaces, construction of virtual networks, definition and execution of service level agreements (cloud/user and cloud/cloud), and cloud computing user interfaces. Not far past Eucalyptus was adopted as Virtualization Manager in the Ubuntu Core, but recently there is not longer support (Canonical switches to OpenStack for Ubuntu Linux Cloud [7]). The federation is out of the scope for them. OpenNebula [8] can be primarily used as a virtualization tool to manage virtual infrastructures in a data-center or cluster, which is usually referred as Private Cloud. Only the more recent versions of OpenNebula are trying to supports Hybrid Cloud to combine local infrastructure with public cloud-based infrastructure, enabling highly scalable hosting environments. OpenNebula also supports Public Clouds by providing Cloud interfaces to expose its functionalities for virtual machine, storage and network management. The middleware tries to manage the federated resources but considering the approach they use for interact with physical servers (SSH remote shell commands), it is quite hard to accomplish real federation achievements. OpenNebula is mainly aimed at interoperability through OCCI interface. A separated analysis has to be faced with OpenStack [9] middleware because it operates in the direction of an open middleware for Clouds. NASA leads the project aiming to allow any organization to create and offer cloud computing capabilities using open source software running on standard hardware. Openstack has three sub-projects that is OpenStack Compute, OpenStack Object Store and OpenStack Imaging Service. In particular OpenStack Compute is software for automatically creating and managing large groups of virtual private servers. Open-Stack Storage is software for creating redundant, scalable object storage using clusters of commodity servers to store terabytes or even petabytes of data. It uses the shared nothing (SN) (Shared Nothing (SN) an architectural philosophy in which the platform is fully distributed and each node is independent and self-sufficient, and there is no single point of contention across the system. OpenStack Image Service is necessary for discovering, registering, and retrieving virtual machine images. RESERVOIR [10] is project that aims to support the emergence of Service-Oriented Computing as a new computing paradigm. In this paradigm, services are software components exposed through network-accessible, platform and language independent interfaces, which enable the composition of complex distributed applications out of loosely coupled components. COMETCloud [11]is a framework that was born during the GRID era, and it is aimed for using distributed computation with a Peer to Peer approach. The developers of COMET are using Eucalyptus for leveraging Clouds capabilities. To drawing new cloud systems, it is important to initially

take into account concepts of “intra” and “inter” requirements and capabilities. In our view a Virtual Infrastructure Manager middleware has to satisfy these following “intra” features in order to meet as much as possible the compelling cloud architectural requirements: local virtual resources management, load-balancing, fault tolerance, intra-cloud security, intra-cloud business models, intra-cloud networking, intracloud monitoring, etc. As well the VIM has to provide these following “inter” features: Cloud Federation, Composability, and Orchestration of resources, distributed virtual resources management, inter-cloud security, inter-cloud business model, inter-cloud networking, inter-cloud monitoring, etc. CLEVER was designed keeping mind these goals, adding as much as possible and at the early stage many functionalities. VI. C ONCLUSIONS AND R EMARKS CLEVER is an open source middleware for the realization of IaaS cloud providers. In this paper, we specifically test its performance considering a scenario including different third party systems using the CLEVER virtualization infrastructure by means of an “Admin REST Portal”. Experiments demonstrate how CLEVER suits this scenario also well acting in situation of peak of requests coming from different third party systems. CLEVER is a modular open source middleware. Currently, different research initiative are developing plug-in(s) in CLEVER for different purposes. Regarding the “Admin REST Portal”, in future works we plan to add further management tasks also improving the security. R EFERENCES [1] Sun Microsystems, Take your business to a Higher Level - Sun cloud computing technology scales your infrastructure to take advantage of new business opportunities, guide, April 2009. [2] B. Sotomayor, R. Montero, I. Llorente, and I. Foster, “Virtual Infrastructure Management in Private and Hybrid Clouds,” Internet Computing, IEEE, vol. 13, pp. 14–22, Sept.-Oct. 2009. [3] F. Tusa, M. Paone, M. Villari, and A. Puliafito., “CLEVER: A CLoudEnabled Virtual EnviRonment,” in 15th IEEE Symposium on Computers and CommunicationsS Computing and Communications, 2010. ISCC ’10. Riccione, June 2010. [4] P. Sempolinski and D. Thain, “A Comparison and Critique of Eucalyptus, OpenNebula and Nimbus,” in The 2nd IEEE International Conference on Cloud Computing Technology and Science, July 2010. [5] C. Hoffa, G. Mehta, T. Freeman, E. Deelman, K. Keahey, B. Berriman, and J. Good, “On the Use of Cloud Computing for Scientific Workflows,” in SWBES 2008, Indianapolis, December 2008. [6] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youseff, and D. Zagorodnov, “The Eucalyptus Open-Source CloudComputing System,” in Cluster Computing and the Grid, 2009. CCGRID ’09. 9th IEEE/ACM International Symposium on, pp. 124–131, May 2009. [7] Canonical switches to OpenStack for Ubuntu Linux cloud. http://www.zdnet.com/blog/open-source/canonical-switches-toopenstack-for-ubuntu-linux-cloud/8875, Jan 2012. [8] B. Sotomayor, R. Montero, I. Llorente, and I. Foster, “Resource Leasing and the Art of Suspending Virtual Machines,” in High Performance Computing and Communications, 2009. HPCC ’09. 11th IEEE International Conference on, pp. 59–68, June 2009. [9] OpenStack: Open source software for building private and public clouds. http://www.openstack.org/, Jan 2012. [10] Resources and Services Virtualisation without Barriers (Reservoir) European Project, http://www.reservoir-fp7.eu/. [11] ComnetCloud: http://nsfcac.rutgers.edu/ CometCloud/CometCloud/CometCloud Home Page.html.