services from multiple Cloud providers are used at the same time for deploying applications that can satisfy fine-grained customer requirements. Inter-Cloud ...
2014 IEEE 3rd International Conference on Cloud Networking (CloudNet)
An OVF Toolkit Supporting Inter-Cloud Application Splitting Gaetano F. Anastasi, Emanuele Carlini, Massimo Coppola, Patrizio Dazzi, and Marco Distefano Istituto di Scienza e Tecnologie dell’Informazione (ISTI) Consiglio Nazionale delle Ricerche (CNR) Italy Email: {gaetano.anastasi, emanuele.carlini, massimo.coppola, patrizio.dazzi, marco.distefano}@isti.cnr.it
To foster the cooperation across different cloud technologies, several standards have been recently proposed and they are acquiring a growing popularity for dealing with specific aspects of Cloud Computing. For instance, we can cite Open Cloud Computing Interface (OCCI) [2], a protocol and API for dealing with common cloud management such as deployment, autonomic scaling and monitoring; Open Virtualization Format (OVF) [3], a standard for creating packages for cloud applications in order to address the portability and deployment of such applications in different virtualization platforms; SLA@SOI [4], a standard framework for defining and managing Service-Level Agreements (SLAs) in the Cloud, delivered with a supporting toolkit; OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) [5], a standard intended to enhance the portability of cloud applications by enabling the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services. If on the one hand the definition of new standards promotes the interoperability between different Clouds, on the other hand it calls for tools able to recognize and manipulate them. This paper focuses on the OVF Toolkit, a tool we developed to parse, manipulate and render Cloud applications expressed according to the OVF format, that describes applications in terms of appliances, pre-built software solutions treated as a unit. The OVF Toolkit satisfies two main requirements: (a) creating a software abstraction of the application from an OVF file, in a manner that other software or systems can leverage such application representation for reasoning; (b) allows for transparently splitting an application package into many packages, that can be independently deployed in different Clouds. The paper is organized as follows. In Section II, we motivate with cost savings the need for a tool capable of manipulating OVFs and thus allowing for splitting applications on different Cloud providers. Section III presents the main concepts of the OVF standard and introduces the terminology used throughout this manuscript. Section IV describes the proposed OVF Toolkit in details, whilst Section V describes a broker architecture that can effectively leverage the proposed toolkit, giving an insight of how such toolkit can be practically used in Inter-Cloud scenarios. Section VI describes some experiments performed by using an implementation of the
Abstract—The Open Virtualization Format (OVF) is a software packaging standard designed to support the portability and deployment of applications in different virtualization platforms. Ease interoperability and portability among cloud providers is of paramount importance to mitigate vendor lock-in and fostering cooperation among different cloud technologies. To this end, the researcher community is spending a lot of effort in investigating cloud broker and cloud federation solutions. However, we feel that the community still misses an open-source reference tool for the management of these operations when it comes to the OVF standard. With the aim to fill this gap, we propose the OVF Toolkit, an open tool to parse, render, and split OVF files. This paper describes the principal design decisions, the implementation, and the capabilities of the toolkit, as well as its experimental evaluation. Keywords-Cloud Computing, Utility programs, Software libraries, Open Virtualization Format.
I. I NTRODUCTION Nowadays, Cloud Computing is one of the most popular and interesting computational paradigms, due to its unquestionable benefits, such as potential cost reductions offered by the pay-per-use model, flexibility and scalability, fault-tolerance, and increased availability. Many vendors have seen business opportunities in Cloud Computing and hundreds of providers1 are testing themselves in the market. In this scenario, the research community has advanced one step further, by envisioning Inter-Cloud Computing [1] where services from multiple Cloud providers are used at the same time for deploying applications that can satisfy fine-grained customer requirements. Inter-Cloud Computing offers many benefits to customers, such as the mitigation of the vendor lock-in problem, an improved reliability and a geographic distribution that can overcome issues of compliance with laws and regulations (e.g., data privacy laws are very different between EU and USA). In the Inter-Cloud environment, interoperability and portability are of paramount importance, especially for overcoming the vendor lock-in problem, that occurs when a customer is so tightly-coupled to a single cloud provider, that the cost of switching from that provider’s technology to another would be too high making the customer unable to migrate. 1 http://www.spamina.com/eng/cloud
hosting providers list.php
978-1-4799-2730-2/14/$31.00 ©2014 IEEE
96
2014 IEEE 3rd International Conference on Cloud Networking (CloudNet)
toolkit. Such experiments are devoted to evaluating different parsing technologies and validating the functionalities of the toolkit. Finally, Section VII presents the related work and Section VIII draws conclusions. As a note, to foster further research in this field and to make our results reproducible, we publicly release the source code of the proposed toolkit2 .
NO SPLIT - 25% SPLIT - 25% NO SPLIT - 50% SPLIT - 50%
NO SPLIT - 75% SPLIT - 75% NO SPLIT - 100% SPLIT - 100%
1500
Total Cost
1400
II. M OTIVATIONS The ability of parsing and rendering OVFs constitutes the fundamental brick that allow applications to receive in input and return in output files expressed according to the OVF format. Besides, supports able to provide more complex types of operations on OVF files can simplify the exploitation of application expressed in this file format and facilitate their adoption and diffusion. In our paper we focus on a specific kind of manipulation: application splitting. As briefly introduced in the previous section, OVF Applications can be seen as a collection of appliances. Each appliance can be characterized by requirements, features and various attributes. Clearly, a different set of requirements leads to different resources that have to be exploited to properly deploy such entities: greater are the requirements, more powerful are the resources to be exploited. It is assumable that Clouds providing more powerful resources are more expensive than standard Clouds. Given such assumption, to satisfy the requirements of a Cloud application with at least one appliance requiring special resources, the application as a whole needs to be deployed on an expensive Cloud. Conversely, if it would be possible to “extract” from such application only the entities requiring special resources, the remaining of the application could be deployed on a standard, cheaper, Cloud. Figure 1 depicts the saving that can be achieved when exploiting an application splitting support. On the X-axis is reported the ratio of appliances per application that expose special requirements. The figure reports different trends, each corresponding to a different application stream composed by a different percentage of applications with at least one appliance with special requirements. It is easy to see that the maximum savings can be achieved when a significant part of the applications is composed by a small ratio of special entities. On the Y -axis is reported the cost that a tenants would pay if run their applications, both by exploiting a splitting support (SPLIT) and without using it (NO SPLIT). As an example consider the application stream in which the 75% of applications have at least one appliance with special requirements. If no splitting support is available the overall execution cost is 1400, independently from the ratio of “special” appliances per application. With a splitting support the cost depends on the percentage of “special” appliances for each application, from slightly below 1100 to 1400.
1300 1200 1100 1000 0.2
0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 Percentage of Applications with Special Requirements
Figure 1.
Saving by Splitting
III. OVF S PECIFICATION The OVF [3] is a packaging standard designed by Distributed Management Task Force (DMTF) to address the portability and deployment of virtual appliances. A virtual appliance (or appliance) is a pre-built software solution, comprised of one or more Virtual Machines (VMs) that are packaged, maintained, updated and managed as a unit. OVF allows for packaging all the information necessary to distribute appliances, enabling cross-platform portability and simplified deployment across different virtualization platforms, including cloud environments. The standard specifies the format of an OVF package that is composed by different files. In particular, the application description can be found in the OVF file that has extension .ovf. In a nutshell, the OVF File is an XML document used for encoding information of the appliances composing an application. The outermost element of an OVF is the tag Envelope that contains the following information: • •
•
•
•
The version number; The list of references to all external files that are part of the package, such as ISO files and disk image files (such references are defined by the References element and its File child elements); The metadata information about resources in common between the different appliances, defined by the Section elements; The description of the content, specified as information about a single VM (VirtualSystem element) or eventually aggregated in hierarchical collections (VirtualSystemCollection element); The optional information about locales.
For the sake of simplicity, we do not consider all the elements that can compose an OVF. Instead, we focus on a simple but representative OVF File, as the one depicted in Figure 2, where each box represents an OVF element. Such elements are described in the following.
2 https://github.com/gaetanofan/ovf-toolkit
97
2014 IEEE 3rd International Conference on Cloud Networking (CloudNet)
OVF Networks Disks SharedDisks VirtualSystemCollection VirtualSystem
Figure 2.
Structure of an OVF File Figure 3.
1) Networks: The NetworkSection element lists all the logical networks used in the OVF package. The NetworkSection is a valid element only at the outermost envelope level and it has Network elements as children. Each Network element shall have a unique name within the document, specified by using the ovf:name attribute. 2) Disks: The DiskSection element contains metainformation about virtual disks. This element is valid only as a direct child of the Envelope element. Each virtual disk is represented by a Disk element under this section. It shall have an unique identifier specified in ovf:diskId attribute and shall refer to an existing References\File element. The reference is done by indicating the File#ovf:id attribute in the ovf:fileRef attribute of the disk. 3) Shared Disks: The SharedDiskSection is similar to the DiskSection from the XML Schema point-of-view, in the sense that it contains meta-information about virtual disks (usually referring to the File element) and is valid only as a child of the Envelope element. However, when using the DiskSection, multiple virtual systems can reference the same disk but it will be seen as an individual private disk by the guest part of the virtualization software. Instead, the SharedDiskSection allows for specifying virtual disks that can be shared among different virtual systems at runtime. 4) Virtual Systems: The VirtualSystem is the element that describes a single VM. Multiple virtual systems can be grouped in a VirtualSystemCollection to be considered as a logical unit. Each VM requires some virtual hardware to be run e.g., memory, CPU(s), disks, networks. In the OVF, such virtual resources are specified in the VirtualHardwareSection element, usually one element for each VirtualSystem. The various items in the VirtualHardwareSection can refer to other elements in the document. For instance, a virtual disk for a VM can use one of the disks contained in the OVF package, by referring to the unique ovf:diskId attribute declared in the DiskSection element.
The OVF Tree Structure
The OVF Toolkit consists of three main building blocks, each taking into account a different aspect of the toolkit: • The OVF Data Structures. The toolkit provides two different in-memory representations of the concept of application for modeling the relationships between all the elements of the application; • The OVF Parser. It transforms an OVF file into an OVF Data structure; • The OVF Renderer. Given an OVF Data Structure, it performs the rendering of that structure into an OVF file. The next sections present each of those modules, discussing their implementation details and APIs. A. The OVF Data Structures The OVF Toolkit provides two different data structures to represent the application described by an OVF file: the OVF Tree Structure and the OVF Graph Structure (also referred as application graph in the following). Figure 3 depicts the OVF Tree Structure, in which the information is contained in two main entities, called ApplicationDescriptor and ApplianceDescriptor. These two entities contain the information relative to the OVF as defined in Section III. For each application, there is a bijective correspondence between the number of appliances and the number of VirtualSystem elements in the OVF. The representation of the application is a tree structure in which the root element is an ApplicationDescriptor. The ApplicationDescriptor is the container for the whole application, and contains at least one appliance defined by the ApplianceDescriptor. In turn, every appliance contains all the information extracted directly from the OVF document parsed and exposes methods to retrieve and manage all the properties of that appliance. By leveraging JGraphT (see www.jgrapht.org), a Java library that provides mathematical graph-theory objects and algorithms, the toolkit can provide the OVF Graph Structure, a graph representation of the application, in which vertexes are instances of ApplianceDescriptor and edges are virtual networks connecting those appliances. The graph representation is fundamental for the application splitting process because it provides an intuitive way to represents connections between appliances. The OVF Data Structures are the main outcome of the OVF Parser module, that is described in the following.
IV. T HE OVF T OOLKIT The OVF Toolkit software is a standalone library that can be used to parse, validate, manage and render OVF files. Essentially, it aims at organizing the information on applications described in OVF files, making it easily available to others software modules through an API and a set of functionalities.
98
2014 IEEE 3rd International Conference on Cloud Networking (CloudNet)
QBrokage
A
Application Queue OVF Parser
A
OVF
OVF Monitoring and Net estimator
parse
Allocator
D F
E
render
D
split F lit
Figure 5.
OVF
B
C
sp
Providers
Figure 4.
B
C
Mapping
lit
sp
render
OVF
E render
OVF
OVF Parsing, Splitting and Rendering
Broker Architecture
V. U SE C ASE The OVF capabilities of packaging appliances in a standard way can be effectively leveraged in Inter-Cloud scenarios, The OVF Parser is the module that reads an OVF file and where applications (or part of them) should be transparently builds the OVF Data Structures representing the application. deployed in different Clouds. This module uses JAXP (see https://jaxp.java.net/) as Java API For highlighting when, where and how the OVF Toolkit for processing XML files. can be leveraged in such scenarios, we briefly introduce In the early design phase of the OVF Parser we decided QBrokage [6], an Inter-Cloud architecture that can use the to decouple the parsing functionality from the creation of functionality of the OVF Toolkit for easing its cloud brokering the OVF class objects, i.e. class objects are not constructed tasks. Please note that the toolkit is flexible enough for through automatic XML binding. We believe that this solution being used in other use cases. As an example, it has been allows us to better construct a coherent abstract representation already used in the Contrail EU project in a Cloud Federation of an application, considering that the mutual relationships architecture [7]. between different elements described in the OVF files must be As depicted in Figure 4, customers may submit applications considered when constructing class objects. As an example, to the Broker by using the OVF format, which permits to an appliance should contain information on a disk only if describe applications in terms of appliances, composed by a that disk has been declared on the DiskSection and there set of VMs inter-connected by virtual networks. Both VMs is a correspondence on the id of the relevant item in the and networks can be characterized by resources requirements. VirtualHardwareSection. The OVF Parser depicted in Figure 4 is part of the OVF The OVF Parser exposes its API by using the facade class Toolkit and can be used for parsing OVFs given in input, for ParserManager. A ParserManager object can be constructed constructing an application graph as described in Section IV. by using input OVF files in different formats, i.e., disk file, The application representation is then enqueued by the broker URI and String. Apart from the methods allowing to create/re- on the Application Queue, which buffers the current request trieve an application representation as previously described, for application mapping and manages the delivery to the the API also allows for directly retrieving information about Mapping component. applications, including appliances, disks, networks, etc. Some The Mapping component computes a set of mapping plans, of these methods are listed in the following: considering properties of datacenters and applications. A mapping plan associates each VM of an application to a datacenter. • getAppliances(): retrieves the IDs of all appliances This component effectively leverages the functionality of the in the application; OVF Toolkit by using the graph representation constructed • getApplianceDisks(applianceID): gets the from the OVF for coherently splitting the application among disks associated to an appliance; different datacenters. Additional useful information for the • getApplianceImages(applianceID): gets the Mapping component may come from the Monitoring and image file associated to an appliances; • getApplianceNetworks(applianceID): gets Net estimator component, which provides a view on (i) the characteristic of the network connecting the datacenters and the virtual networks associated to an appliance; • getApplianceVirtualSystems(applianceID): (ii) the state of the providers. Once the mapping plans are computed, those serve as input gets the Virtual System associated to an appliance; for the Allocator, that tries to allocate VMs by considering one mapping plan at time. Basically, this component dealing C. The OVF Renderer with runtime error that can happen when effectively contacting The OVF Renderer is the module of OVF Toolkit that the cloud providers for allocating VMs. This component can generates an OVF file starting from an OVF Data Structure. leverage the OVF Renderer for rendering OVFs starting from The OVF Renderer exposes the interfaces that allow the sub-graphs obtained as a split of the original application generation of a valid OVF document from congruent instances graph. For example, consider an application graph composed of ApplicationDescriptor or ApplianceDescriptor. of vertexes A, B, C, D, E, F and the following mapping plan: B. The OVF Parser
99
2014 IEEE 3rd International Conference on Cloud Networking (CloudNet)
OVF Toolkit DOM StAX
6000
milliseconds
5000
OVF
4000 3000
parse
render
validate
2000
tags colletions
1000 0 0
Figure 6.
50
100 150 Virtual System number
Figure 7.
200
Parsing time of OVF Toolkit, DOM vs StAX
A to datacenter 1; B, C, D to datacenter 2; E, F to datacenter 3. The Allocator exploits the OVF Renderer for generating three different OVFs that will be send to the corresponding datacenter for the deployment. The whole process of parsing, splitting and rendering is depicted in Figure 5. It is worth to note that information on former edges of the graph connecting new sub-graphs e.g., edge A, B is preserved in the OVF Data Structures inside the ApplianceDescriptor. It is a duty of the Allocator, in case of successful deployment, to create network links on the provider and put in place techniques such as Software Defined Networks (SDNs) or Virtual Private Networks (VPNs) for ensuring connections between VMs on different providers or datacenters. VI. E XPERIMENTS This section describes some experiments for evaluating different parsing technologies and validating the toolkit. We run all the experiments on a Intel Core i7 machine, with 4 cores and 12GB RAM. A. Parsing Evaluation This experiment focuses on the evaluation of two parsing techniques implemented and offered by the JAXP API. We were interested to measure the time needed for parsing an OVF file and build the OVF Tree Structure as depicted in Figure 3. First, we measured the parsing time by using the Document Object Model (DOM) technique. This parsing model builds an in memory tree representation of the application, which is then queried through XPath to build a consistent OVF Tree Structure that checks mutual references between objects (see Section IV). Then we repeated the experiments parsing the same files with the StAX interface of JAXP, that implements an event-driven XML parsing. Through this method we generate a sequence of events that are processed by the StAX parser. The sequence is generated so that the OVF Tree Structure can be built without intermediate steps. We executed the experiments using several OVF files (defining different applications) that differ to each other in the number of virtual systems, and consequently in the size in bytes. We varied the virtual systems defined from 1 up to 200 with the dimension of files varying from 4kB up to 345kB.
OVF
plain XML parsing
Validation Process
Figure 6 shows the parsing times in milliseconds averaging the outcomes of 20 independent runs. From the plot we can notice that the DOM parsing is exponential, whereas using the StAX API leads to a fairly stable parsing time, well under the second with any application size. For this reason the StAX API has been chosen as the default parsing library for the OVF Toolkit implementation and it has been used in the validation experiments described in the following. B. OVF Toolkit validation As mentioned above, the OVF Toolkit can (i) parse of OVF files (ii) build an in-memory graph-like representation of applications to enable complex operation (e.g. splitting) and, (iii) render OVF files In this subsection an experimental validation of such features is presented. The first experiment was set up as follows. We created an OVF file containing a single VirtualSystemCollection with 100 VirtualSystem. For each VirtualSystem the disk and network section were taken randomly from a pool respectively of 5 and 10 items. Note that by randomizing the network, we make sure that two different OVF files correspond to different application graphs. After creating an OVF, we applied the procedure depicted in Figure 7. The OVF file is parsed with the OVF Toolkit and the relative application graph is created. Then the graph is rendered back into an OVF file. At this point the rendered OVF file may be not syntactically identical to the original, due to the fact that the graph does not retain the disposition of the VirtualSystem tags. However, what is important here is that the “semantic” of the produced OVF would be the same than the original. To check this equality we parsed again the produced OVF, this time with an external DOM parser. Then we query the DOM to check whether the amount and content of VirtualSystem tags match. We repeated this whole process for 100 different OVF files, always obtaining the semantic equality we target. The second experiment specifically targets the application splitting. The rationale of the experiment and the methodology is similar to the previous experiment. The difference is that, in this case, we render different OVF files for each sub-graph of the application (see also Figure 5). Thus, the data structures obtained from these files have to be merged for re-creating the whole application graph and fall back to the case of previous experiment. Even in this case we repeated the whole process for 100 different OVF files, always obtaining the semantic equality.
100
2014 IEEE 3rd International Conference on Cloud Networking (CloudNet)
VII. R ELATED W ORK In this paper we focus on the OVF standard, considering that it is already popular and it could be widely adopted in Inter-Cloud scenarios for submitting cloud applications. In such scenarios, the appliances composing an application can be allocated in different Clouds, in a manner that is transparent to the application. Different efforts are needed for reaching this goal but many steps are going in this direction. For instance, the SDN approach by Luo and Chen [8] allows the VMs of an application to establish private virtual networks among them and manage the routing between different Clouds. Also, some API abstraction approaches [9], [10] allow for managing different cloud resources without caring of vendor specific differences. In particular, δ-cloud [9] provides APIs and drivers needed for connecting to Cloud providers. It enables the management of resources belonging to different clouds by means of several APIs. These APIs work as wrappers around different Clouds, abstracting their differences and easing their conjunct management. Libcloud [10] is a Python library aimed at interacting with many of the popular cloud service providers using a unified API. It was created to simplify the task of creating services that inter-operate also when deployed on different Clouds. Besides the above mentioned approaches, if we focus on OVF, there are a few that are closer to ours, addressing the manipulation of OVF as a way to let different Clouds interoperate. Among them we can cite ovf4one [11], a tool for OpenNebula [12] that receives in input Cloud applications expressed as OVF files and generates an equivalent set of OCCI calls to deploy such application on a target Cloud running OpenNebula. To this end, ovf4one provides an OCCI RESTful interface. This tool faces a problem that is similar to ours, but from a different viewpoint. Our focus is to provide a tool that accept OVF and, after some manipulations, outputs one or more OVF(s), still remaining provider agnostic. Instead, ovf4one is focused on enabling OpenNebula to manage application expressed according to the OVF format. Another OVF parser has been released to the community along with Claudia [13], an open-source tool aimed at governing Cloud-based services (e.g., how services are scaled up/down and in/out). Claudia can deploy services among public or private Clouds by using Virtual Infrastructure Managers, such as OpenNebula, through a plug-in driver mechanism that will orchestrate the allocation of virtual resources. In order to perform the goals it has been designed for, Claudia makes use of an OVF parser that its authors made publicity available. Unfortunately, their parser is neither no longer maintained nor compliant with recent OVF specifications. VIII. C ONCLUSION This paper presented the OVF Toolkit, a tool for OVF file parsing, rendering and splitting. One of the aims of the tool is to ease the integration and the exploitation of the OVF file format, that can be an effective standard for describing Cloud applications. By means of its ability to split Cloud applications, the OVF Toolkit is particularly useful for cloud
brokers, as showed in the presented use case. Also, we gave an idea of the advantages that can derive from the exploitation of an application splitting support, by showing the savings that tenants can obtain by properly decomposing their applications. Finally, the paper reported the validation activities we conducted and the evaluation of parsing performances. An empirical evidence shows that the OVF Toolkit is able to scale very well when the size of OVF files grows. In the future we plan to enhance the tool by introducing new features. A useful support that we are considering to include in the next releases of the tool consists in the OVF decoration, to enable the creation of extended OVFs. These OVFs can embed custom attributes leading special abilities or tailored decisions, e.g., special rules for elasticity, specific contextualization support, Quality of Service (QoS) attributes. ACKNOWLEDGMENTS The authors acknowledge the support of Project FP7257438, Contrail (Open Computing Infrastructures for Elastic Services), Project FP7-256980 NESSoS (Network of Excellence on Engineering Secure Future Internet Software Services and Systems) and Project FP7-318786 Midas (Model and Inference Driven, Automated Testing of Services Architectures). The authors also thank the student Giacomo Maestrelli for his help in the implementation. R EFERENCES [1] R. Buyya, R. Ranjan, and R. N. Calheiros, “Intercloud: Utility-oriented federation of cloud computing environments for scaling of application services,” Algorithms and Architectures for Parallel Processing, vol. 6081/2010, no. LNCS 6081, p. 20, 2010. [2] “Open Cloud Computing Interface - Core,” Open Grid Forum, Specification, Jun. 2011. [3] “Open Virtualization Format Specification, Version 2.1,” DMTF, Specification, 2013. [4] J. Happe, W. Theilmann, A. Edmonds, and K. Kearney, “A reference architecture for multi-level sla management,” in Service Level Agreements for Cloud Computing, P. Wieder, J. M. Butler, W. Theilmann, and R. Yahyapour, Eds. Springer New York, 2011, pp. 13–26. [Online]. Available: http://dx.doi.org/10.1007/978-1-4614-1614-2 2 [5] “Topology and Orchestration Specification for Cloud Applications,” OASIS, Specification, Nov. 2013. [6] G. F. Anastasi, E. Carlini, M. Coppola, and P. Dazzi, “QBrokage: a Genetic Approach for QoS Cloud Brokering,” in Cloud Computing (CLOUD), 2014 IEEE 7th Int. Conference on, June 2014, p. (To Appear). [7] E. Carlini, M. Coppola, P. Dazzi, L. Ricci, and G. Righetti, “Cloud federations in contrail,” in Euro-Par 2011: Parallel Processing Workshops. Springer, 2012, pp. 159–168. [8] M.-Y. Luo and J.-Y. Chen, “Software defined networking across distributed datacenters over cloud,” in Cloud Computing Technology and Science (CloudCom), 2013 IEEE 5th International Conference on, vol. 1, Dec 2013, pp. 615–622. [9] (2014, Jun.) Deltacloud. [Online]. Available: http://deltacloud.org/ [10] (2014, Jun.) Libcloud. [Online]. Available: https://libcloud.apache.org/ [11] (2014, Jun.) OVF4ONE. [Online]. Available: https://github.com/tnais/ ovf4one [12] R. Moreno-Vozmediano, R. S. Montero, and I. M. Llorente, “Iaas cloud architecture: From virtualized datacenters to federated cloud infrastructures,” Computer, vol. 45, no. 12, pp. 65–72, 2012. [13] D. Mor´an, L. M. Vaquero, and F. Gal´an, “Elastically ruling the cloud: specifying application’s behavior in federated clouds,” in Cloud Computing (CLOUD), 2011 IEEE International Conference on. IEEE, 2011, pp. 89–96.
101
