Integration of CLEVER Clouds with Third Party Software Systems Through a REST Web Service Interface

Transcription

1 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, Messina, Italy. {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 providers with open source tools is not totally clear. Moreover, the integration between an 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. INTRODUCTION Cloud computing brings a new level of efficiency and economy in delivering resources on demand, thus representing much more than a form of cheap computing. In fact, cloud computing offers more than a pay-per-use model including IT Efficiency, that allows companies to minimize the costs and Business Agility, that allows to companies to 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 virtual context, allowing to treat traditional hardware resources like a pool of virtual ones. In addition virtualization enables the ability of migrating resources, regardless of the underlying real physical infrastructure. Therefore, using virtualization and aggregating virtual 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 of the major commercial providers supplying ondemand VMs to their clients (i.e., other clouds, organizations, governments, ICT companies, or single desktop/web/mobile human end-users) are Amazon and Rackspace. 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 publicly accessible interfaces, but also providing to its clients a flexible and agile private infrastructure to run service workloads within their administrative domains. In this context an important issue needing to be addressed is the integration between the cloud IaaS provider with third party software systems through publicly accessible interfaces. The CLoud-Enabled Virtual EnviRonment (CLEVER) [3] (official web site: 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 the feature of the middleware itself, 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 a /12/$ IEEE

2 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. II. THE CLEVER IAAS CLOUD ARCHITECTURE A. Overview The CLEVER middleware is based on the architecture schema depicted in Figure 1, which shows a cluster of n nodes (also an interconnection of clusters could be analyzed) 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. 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: /12/$ IEEE

3 Communication between CM and HM for exchanging information on the cluster state and sending specific commands; Communication between the administrators and CM using the ad-hoc client interface. As previously discussed, in order to implement the intermodule 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. 2. Activity diagram of the external communication. As the Figure 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, during the life-cycle of the cloud 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 an admin console software client 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. More specifically, the admin consoles and the active Cluster Manager interact on a reserved XMMP administration room. Figure 3 depicts what happen when and administrator give a command to CLEVER. In step 1 the administrator gives a command to Fig. 3. Execution of a command on the CLEVER cloud. 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 the CLEVER 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 plug-in. After that, 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. HOW TO INTEGRATE CLEVER WITH THIRD PARTY SYSTEMS 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. As 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, /12/$ IEEE

4 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 URL rest/set?server/port/ username/password/ nickname/room rest/username?command/ option1/option2/...? value1&value2/... rest/verify/username rest/invalidate rest/set/ttl?value Description Logs a third party system Sends a CLEVER command TABLE I Verifies access credentials Invalidates the session Sets the session TTL REST WEB SERVICES EXPOSED BY THE ADMIN REST PORTAL Fig. 4. Integration of CLEVER with different third party software systems. admin software clients, the interesting thing is that the only 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, after that 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 REST Portal. 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, after authentication and session establishment, commands to CLEVER. Examples of web services allowing to perform management tasks on CLEVER are the following: It returns to third- Fig. 5. Sequence diagram for the authentication and session establishment of a third party system on CLEVER through the Admin REST Portal party-system the list of Cluster Managers of the current CLEVER administration domain. It returns to third-party-system the list of allocated VMs on the ing-clever-master administrative domain. 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. It allows third-party-system to stop a VM named /12/$ IEEE

5 Rest-test on the ing-clever-master administrative domain. the gathered results showing the mean values considering the times of the four simulated third party software systems. IV. EXPERIMENTS In this Section, we present several experiments regarding the simultaneously management of different third party systems on the 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 confidence interval (at 95%) indicates the goodness of our analysis. 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 the starting of four VMs. Considering the four third party systems, a slight difference in times for the allocation of VMs is due to different scheduling conditions sometims causing aborting and re-submission of requests. For example, having a look to the graph of Figure 6, System 1 implies about 340 msec for starting its own VM 4, instead system 3 implies 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 summarized Fig. 6. Mean values for each one of the four systems sending VM starting requests to CLEVER through the Admin REST Portal. Fig. 7. Mean values of four systems sending VM starting requests to CLEVER through the Admin REST Portal. V. RELATED WORKS 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 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 /12/$ IEEE

6 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. VI. CONCLUSIONS AND REMARKS 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. REFERENCES [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 [2] B. Sotomayor, R. Montero, I. Llorente, and I. Foster, Virtual Infrastructure Management in Private and Hybrid Clouds, Internet Computing, IEEE, vol. 13, pp , Sept.-Oct [3] F. Tusa, M. Paone, M. Villari, and A. Puliafito., CLEVER: A CLoud- Enabled Virtual EnviRonment, in 15th IEEE Symposium on Computers and CommunicationsS Computing and Communications, ISCC 10. Riccione, June [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 [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 [6] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman, L. Youseff, and D. Zagorodnov, The Eucalyptus Open-Source Cloud- Computing System, in Cluster Computing and the Grid, CCGRID 09. 9th IEEE/ACM International Symposium on, pp , May [7] Canonical switches to OpenStack for Ubuntu Linux cloud. Jan [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, HPCC th IEEE International Conference on, pp , June [9] OpenStack: Open source software for building private and public clouds. Jan [10] Resources and Services Virtualisation without Barriers (Reservoir) European Project, [11] ComnetCloud: CometCloud/CometCloud/- CometCloud Home Page.html /12/$ IEEE