How To Understand Cloud Computing, Interoperability, And Security In A Hybrid Cloud

Mapping of Cloud Standards to the Taxonomy of

Interoperability in IaaS

Ralf Teckelmann and Christoph Reich Department of Computer Science Hochschule Furtwangen University, Germany Email:{ralf.teckelmann, rch}@hs-furtwangen.de

Anthony Sulistio

Department of Applications, Models and Tools HPC Center Stuttgart (HLRS), Germany

Email: [email protected]

Abstract—The idea behind cloud computing is to deliver Infrastructure-, Platform- and Software-as-a-Service (IaaS, PaaS and SaaS) over the Internet on an easy pay-per-use business model. However, current offerings from cloud providers are based on proprietary technologies. As a consequence, consumers run into a risk of a vendor lock-in with little flexibility in moving their services to other providers. This can hinder the advancement of cloud computing to small- and medium-sized enterprises. To address these issues, standardization efforts have to take place in order to support further developments in the clouds. Standardized exchange mechanisms and interfaces are crucial in order to facilitate interoperability. In this paper, we look at several cloud standards, such as Open Virtualization Format, Open Cloud Computing Interface, and Cloud Data Management Interface, and analyze them against a taxonomy in order to point out their role for interoperability in IaaS. The taxonomy presents important IaaS topics, such as access mechanism, virtual appliance, security, and service-level agreement.

Keywords-cloud computing, interoperability, OVF, OCCI, CDMI

I. INTRODUCTION

The service models of cloud computing consist of

Infras-tructure as a Service (IaaS), Platform as a Service (PaaS)

and Software as a Service (SaaS) [1]. They differ in the

complexity of the provisioned capability, and how customers can access or use them. IaaS is marked through the provision of basic computing capabilities for customers. In PaaS, users have control only of their applications, and to a certain extend the configuration of hosting environments. In the SaaS model, customers just use a certain application running on a cloud infrastructure.

Currently, offerings from clouds, such as Amazon Web Services (AWS) [2], Rackspace [3], and Flexiant’s FlexiS-cale [4], are based on proprietary middleware [5]. Thus, resulting in isolated environments. This isolation obstructs the further advancement of cloud computing. New models, e.g. federations, are not feasible without interoperability [6]. The same applies to the enforcement of Service-Level Agreements (SLA) in a hybrid cloud and the management of logically-grouped virtual machines (VMs).

The aforementioned issues lead to a series of disadvantages for customers, such as vendor lock-in and high migration costs. To address these, standardization efforts have to take place in order to support further developments in the cloud.

Standardized exchange mechanisms and interfaces are crucial in order to facilitate interoperability [7]. It is also important that the standardization process should apply to the evolution of cloud.

In our previous work [8], we present a taxonomy of interop-erability for IaaS. The taxonomy discusses all important issues, such as access mechanism and security, to outline the needs and trends in current developments aiming for interoperability for IaaS. Important developments, such as the rise of Virtual Appliances (VAs) over VMs and the adoption of SLAs to clouds, are also considered.

In this paper is organized as follows. Section II give a brief explanation to the taxonomy of interoperability and classification of cloud standards. The core of this work is a mapping of these standards againsts the taxonomy, and is presented in Section III. Section IV gives an analysis and discussion of the standards, whereas Section V provides some related work. Finally, Section VI concludes the chapter and gives future work.

II. CLASSIFICATION OFIAAS STANDARDS

Figure 1 gives an overview of the taxonomy categories, which can be seen as essential building blocks towards an interoperability for IaaS [8].

Access Mechanism

Virtual Appliance

Security

Storage Service-Level Other

Agreement Interoperability of IaaS Taxonomy

Network

Fig. 1: Interoperability of IaaS Taxonomy.

The first category shown in Figure 1 isAccess Mechanism, where several access types and important topics of service dis-covery are discussed.Virtual Applianceis the second category and deals with the interoperability of computational resources. Next is Storage, where it discusses storage organization and management as important areas for interoperability. The fourth category is Network that focuses on addressing issues re-garding to high-level communications. Afterwards,Securityis considered in this taxonomy.Service Level Agreement (SLA)is discussed next, especially in the area of architecture, template format, and monitoring of SLA objectives. Finally, theOther

category is intended for topics like consensus & regulations, and audit standards not in scope of this paper.

In the following, IaaS standards are presented and analyzed against the taxonomy elaborated in Figure 1:

Open Virtualization Format(OVF) [9] [10] is a preliminary

standard of the Distributed Management Task Force (DMTF). It claims to be a hypervisor-neutral, efficient, extensible open specification for packaging and distribution of VAs [10]. Through the packaging of VM images with installed operating systems (OSs), the application software and a description of the overall system, OVF provides a configured pre-packaged software environment. Through the additional ap-plication of sources OVF also allows automated runtime con-figuration depending on the virtual environment the provided VA is instantiated in. Moreover, OVF decouples the platform from the appliance through this mechanism and proposes a single standardized information exchange mechanism.

Open Cloud Computing Interface (OCCI) [11] [12] is

de-veloped by the Open Grid Forum (OGF). The development of OCCI follows the idea of the fast provision of a minimalistic interface, which is extended later and therefore offers high extensibility. It provides a RESTful interface using HTTP as transport protocol [11]. OCCI does not use XML or JSON, it founds on HTTP key-value pairs in the header of requests or responses, instead. Its purpose is to represent a standardized front-end API of a cloud management system and to expose a Resource-oriented Architecture (ROA).

Cloud Data Management Interface (CDMI) [13] is a

stan-dard of the Storage Networking Industry Association (SNIA), and its purpose is the founding of a basis for rich cloud storage management interfaces [13]. CDMI is intended to be implemented above or besides other storage interfaces even if they are not applicable to clouds. A comprehensive meta data model should allow the concurrent access and guarantee appropriate data handling. All in all, the meta data model of CDMI is its key component offering a complex data structure through a container model and a object-oriented perspective on data. CDMI also provides discovery capabilities.

III. MAPPING OFSTANDARDS TO THETAXONOMY CLASSIFICATIONS

A. Classification of Virtual Appliance Conformance

TABLE I: Virtual Appliance Conformance Classification

OVF OCCI CDMI

Lifecycle

– Stages × n/a

– Update Management × × n/a

Virtualization Platform

– Image Format n/a

– Licence ∗ n/a n/a

Virtualization Manager

– Migration n/a × n/a

– Adaptors n/a

= fulfilled_∗= partially ful._×= not ful. n/a = not applicable The idea of a Virtual Appliance (VA) is to deliver a ser-vice as a complete software stack installed on one or more

VMs, as proposed by Distributed Management Task Force (DMTF) [10]. A VA description is more than the XML-based summary of VM descriptions, where it consists of Lifecycle,

Virtualization Platform andVirtualization Manager.

There are two important topics of the VA Lifecycle, i.e.

Stages and Update Management. According to DMTF, the

lifecycle of a VA consists of five stages: 1) Development, 2)

Package, 3)Distribute, 4)Deploy, and 5)Retirement. The core characteristics of a Virtualization Platform are

Virtual Disk Format, Licence, Host Operating System (OS),

Host Architecture, andVirtualization Technology. The current landscape of virtual disk formats (VDFs) is heterogeneous, like VMware’s Virtual Machine Disk (VMDK), Microsoft’s Virtual Hard Disk (VHD), and QEMU’s qcow. However, most of them are proprietary. To advocate interoperability, the support of various VDFs is recommended.

AVirtualization Manageris responsible for managing VAs

on physical hosts. For interoperability, an important task is to move the VAs to different hosts and/or cloud providers. Therefore, Migration is an essential task for the manager. Other relevant interoperability issues areAdaptors/Connectors

for an integration of an API in a modular way that allows the translation of operations and commands from one API to the function set of another. Table I shows the results of the analysis of the standards in terms of VA.

OVF provides interoperability, mainly because of the ab-sence of alternatives for the realization of VAs. As ambassador of the VA model, OVF supports all according functionalities, but suffers considerably in terms of update management, since currently, one viable solution is to move from a conventional software patching to a redeployment [14]. Therefore, OVF does not fulfill the requirements for this topic. In case of image formats, OVF fulfills the requirements, but only because its image format independence. Licensing is a problem, because OVF is an open standard of the DMTF, but no license terms are donated.

Neither the requirements on the VA lifecycle stages nor in terms of management consideration that OCCI fulfills the requirements. Furthermore, it is not able to provide a migration process for VM or VA. However, OCCI can be realized in an adaptor fashion in front of or besides other interfaces of the virtualization manager. Additionally, the Creative Commons - Share Alike v3.0 license fulfills the requirements on open source licenses.

CDMI fulfills the requirements on images formats through independence. It is able to handle all kinds of files. CDMI can also be adopted in an adaptor fashion in front of or besides other interfaces of storage. CDMI is an open standard, but license terms are not donated. Virtual appliance conformance is not significantly for the CDMI, nevertheless it fulfills all applicable requirements.

B. Storage Classification

Two important topics in terms of storage interoperability are

ManagementandOrganization. The former addresses storage

TABLE II: Storage Classification Results

OVF OCCI CDMI

Management – Backup × – Replication × × – Snapshots _× Organization – Image – Schemes

= fulfilled_∗= partially ful._×= not ful. n/a = not applicable latter points out several kinds of storage organization, which are important to prevent incompatibility

Table II shows the classification results against the storage category of the taxonomy.

The applicability of the management functions depends on the availability of the functions because OVF does not provide an API the functions are not supported. Nevertheless, the application of such functionalities to OVF is possible, but proprietary. The discussed considerations about the storage organization in case of images, especially VA images is applicable to OVF. This applies to the availability of file system storage as well as object storage either intelligent or not. The reason is the possibility to provide OVF packages as a set of multiple files or single package. The classification shows that OVF is flexible in terms of storage organization, but does not fulfill any requirements in the management section, because of the absence of an API.

OCCI proposes a combination of OCCI and CDMI for age management. However, OCCI supports a small set of stor-age manstor-agement capabilities and essential operations. Backup and snapshot functions are part of this set, but replication is not considered. Therefore, OCCI satisfies only two of the three requirements. In the area of storage organization OCCI supports all kinds of schemes mentioned in the according section, so it fulfills the requirements. The described intelligent object storage scenario is also realizable, because OCCI is only the front-end interface. As mentioned in the introduction OCCI proposes a resource oriented architecture were object storage applies well to ROA, but the placement of file system storage should be applicable as well.

CDMI provides all considered functionalities and supports all mentioned storage organization schemes. CDMI offers a comprehensive set ofexported protocols enabling the utiliza-tion of several common storage kinds.

C. Network Classification

TABLE III: Network Classification Results

OVF OCCI CDMI

Addressing – IP Mobility ∗ × n/a – LISP ∗ × n/a High-level communication – HTTP n/a – XMPP n/a × ×

= fulfilled∗= partially ful.×= not ful. n/a = not applicable

Two important topics in terms of network interoperability,

i.e.AddressingandApplication-level communication. A major

problem for cloud computing is the need to have a reliable remote access to applications and their underlying VMs, even when they are being moved between subnets within a cloud or to others. Therefore, network addressing plays an important role for interoperability.

The results of the classification against the consideration in the category of networking are summarized in Table III. The consideration apply on all presented standards and are pointed out in the following.

The OVF specification does not consider about IP Mobility (IPv4 and IPv6 protocols), hence, the application of it could be problematic. Locator Identifier Separation Protocol (LISP) for a single IP address to be used for multiple purposes is not considered as well, but through the characteristic of LISP being an infrastructure solution this is not crucial. Never-theless, OVF lacks of flexibility in the networking category, because IP addresses are hard-coded into the XML files and are not dynamically replaceable in case of secured packages (SHA-1 digests in manifest file). In case of Dynamic Host Configuration Protocol (DHCP) this is not as problematic, but OVF stays inflexible.

OCCI does not consider IP Mobility or LISP. But, because of its placement as front-end interface and the management of VMs, it should be. This is an enormous lacking. OCCI strongly depends on HTTP as high-level transport protocol, but XMPP is not considered at all. Hence, the requirement of the focusing on HTTP is fulfilled.

CDMI is a high-level interface, therefore only considers about high-level communication. Nevertheless, it strongly de-pends on HTTP and is not applicable to XMPP. Therefore it, fulfills the standpoint of the taxonomy to focus on HTTP.

D. Security Classification

TABLE IV: Security Classification Results

OVF OCCI CDMI

Authentication n/a × × Authorization n/a × Accounting n/a _{× ×} Encryption – Communication n/a – Data n/a ∗ ∗

User Management n/a _{× ∗}

Verification × ∗

= fulfilled∗= partially ful.×= not ful. n/a = not applicable Important security topics for a cloud interoperability are

Authentication, Authorization and Accounting/Logging. Next

important topics areEncryption mechanisms for communica-tion and data, User Management, and a description about a service discovery specific topicVerification.

Table IV shows the classification results in terms of the security considerations. Several topics have to be discussed in more detail. Hence, the results are reviewed in the following.

OVF achieves strong protection through its verification mechanism. In detail, OVF defines a verification mechanisms founding on a single file containing SHA-1 digest of all files of the package. This file is secured via a certificate-based sig-nature. Hence, every modification is detectable. Furthermore, the DMTF recommends a verification procedure, which should be applied before a OVF package is used for instantiation.

In terms of the taxonomy and interoperability, security is a big problem for OCCI. It proposes HTTP basic authenti-cation as sufficient and does not concern about authorization, accounting or verification. Therefore it does not fulfill any of the taxonomies requirements in this areas. Transport Layer Security (TLS) provides adequate communication security, so OCCI fulfills this requirement. In case of data encryption OCCI fails, but this point has to be considered in conjunction to CDMI. Through HTTP basic authentication and the absence of single sign-on considerations OCCI does not fulfill the requirements on user management as well.

CDMI does not propose a strong authentication mechanism and accounting of accesses and events is not considered as well. But it follows the common way using Access Control Lists (ACLs) to control access and authorization. along with the former standards it does provide TLS for communication. CDMI considers data encryption, but does not make a concrete statement and so does not fulfill the requirements.

Single Sign-On (SSO) capabilities are not present in the CDMI specification, but it recommends protection and save handling of sensitive data. The same applies to the topic ver-ification. The presence of these considerations is a advantage against other standards not considering them, because it gives space for future addition.

E. SLA Classification

TABLE V: SLA Classification Results

OVF OCCI CDMI

Architecture n/a × ×

Template Format × n/a n/a

Monitoring n/a × ×

SLA Objectives × n/a n/a

= fulfilled∗= partially ful.×= not ful. n/a = not applicable Service Level Agreement (SLAs) are ubiquitous in modern IT systems, and thus, they have to be discussed in terms of interoperability [15] [16] [17] [18]. Four important SLA topics are Architecture, Template Format, Monitoring and

SLA Objectives. The results of the SLA classification are

summarized in Table V. They are elaborated to the according standard in the following.

OVF provides a description file, which contains all informa-tion about the VA, but no places for related SLA Objectives (SLOs), KPIs or simple metrics and measurement values are available. Even if it provides aEulaSectionfor the end user license agreement, it only contains plain text and does not possess a machine-readable structure. However, assuming the usage of SHA-1 digests, the static parameters within the

description are static and do not comply to the required dynamic. Hence, OVF does not fulfill the requirements in this area.

OCCI as a front-end API has to be capable of exposing SLA management functionalities in case it should be utilizable as API for a SLA management entity. Because OCCI does not, it does not fulfill the taxonomy recommendations. The same applies for monitoring functionalities either dynamic or static. The results for CDMI correspond to the ones of OCCI. CDMI provides a frontend API, but no monitoring or SLA management functions are available. Hence, CDMI is weak in the area of SLAs.

IV. ANALYSIS ANDDISCUSSION

The last section classified several standardization efforts against the taxonomy with very different results. One char-acteristic the newly proposed OCCI and CDMI have in com-mon is their REST-orientation. But sadly, their data format confirms the statement of the taxonomy that interoperability is cumbered, because of the adoption of different incompatible formats. An agreement or best practices about this issues are necessary. Furthermore, both present front-end interfaces to hide other possibly proprietary ones behind. This is a interest-ing approach, because they have to have a very extensible model to do so, applying very well with the need to be extensible for future cloud use cases and scenarios. Both CDMI and OCCI utilize HTTP query service discovery, while other relevant standards are very weak in this area.

One enormous lack of OCCI in terms of interoperability is its inability to support VAs/OVF, especially the result in the inability to support possibly-related complex systems. This lack is also crucial looking forward to PaaS and SaaS scenarios, where the number of user API decreases, but the administration API grows in order to automate administration tasks for large scale virtual environments.

With respect to storage, CDMI presents an interesting and powerful approach making it necessary to implement and compare it against other storage interfaces. OCCI provides a small set of storage functionalities, but also refers to CDMI for storage management. HTTP is the transport protocol for both CDMI and OCCI.

In the area of security OVF presents a satisfying model, whereas OCCI and CDMI do not in matters of what should be expected related to their purposes. Neither OCCI nor CDMI have a strong authentication mechanism. All standards lack of adequate accounting and logging capabilities and data encryption considerations.

Neither of the respective standards provides sufficient SSO capabilities. OCCI and CDMI does not provide verification mechanisms. Only OVF provides sufficient characteristics.

The SLA topic is barely covered. OVF envisions space for license agreements, but not in a machine-readable format. Furthermore, the approach of dynamic SLOs is not achievable in case of OVF without sacrificing the verification security of the VA description. This is a crucial point. Again, the front-end interfaces OCCI and CDMI lack of according capabilities.

Overall, the consensus about the presented standards con-centrates on the according development institutions and com-munities, apart from OVF, which became widely accepted and adopted.

V. RELATEDWORK

Other publications focus on specific problems, such as re-quirements [18], security [19], semantic-based [20], or mainly express some considerations [7] and use cases [21]. However, several publications analyze the cloud computing paradigm through the establishment of taxonomies [17] [5] [15]. This has the advantage to be able to structure the components and define their borders, comprehensiveness and influences on other topics.

Rimal et al. [17] focus on a high-level architectural observa-tion of cloud funcobserva-tionalities and capabilities. They use these criteria to compare few cloud providers and their offerings. However, they do not focus on IaaS and interoperability. This makes their taxonomy more general. Moreover, they focus only on existing cloud offerings, but not on current developments and standards.

Prodan and Osterman [5] also utilize a taxonomy to summa-rize the elements in a cloud environment, but from a general perspective. This reflects in the analysis of several cloud providers and web hosting providers against their proposed taxonomy. Similarly, the difference to our work lies in the specialization on IaaS, interoperability and the analysis of different technologies.

On the other hand, Bernstein et al. [15] focus on an intercloud communication by discussing multiple problems and providing solutions to them. The result of their work is a set of protocols, which can be utilized to achieve an intercloud communication. In their work, the use of open standards is essential in order to achieve interoperability. However, this approach focuses only on the communication part, but not considering current trends or other important topics, such as virtual appliance, security, storage and SLA.

VI. CONCLUSION ANDFUTUREWORK

In this paper, we present our work in comparing existing cloud standards and offerings with the topics and criteria presented in the aforementioned taxonomy. More specifically, we look at several cloud standards, such as Open Virtualization Format, Open Cloud Computing Interface, and Cloud Data Management Interface, and analyze them against the taxonomy in order to point out their role for interoperability in IaaS.

The taxonomy itself spans over many essential cloud com-puting topics, such as access mechanism, virtual appliances (VAs), security, Service-Level Agreements (SLAs), and gen-eral recommendations. Thus, the taxonomy outlines a detailed picture of the significant characteristics.

As for future work, the use of Information Technology Infrastructure Library (ITIL) to provide interoperability is an interesting area to explore. In addition, further work is needed to compare existing cloud offerings with the aforementioned standards.

ACKNOWLEDGMENT

This work was partially-carried out under the HPC-EUROPA2 project (project number: 228398), with the support of the European Community - Research Infrastructure Action of the FP7.

REFERENCES

[1] P. Mell and T. Grance, “The NIST Definition of Cloud Computing,” National Institute of Standards & Technology, Tech. Rep., Oct. 7, 2009. [2] Amazon Web Services, http://aws.amazon.com, Dec. 2010.

[3] Rackspace, http://www.rackspacecloud.com/index.php, Dec. 2010. [4] Flexiscale, http://www.flexiant.com/products/flexiscale/, Dec. 2010. [5] R. Prodan and S. Ostermann, “A Survey and Taxonomy of Infrastructure

as a Service & Web Hosting Cloud Providers,” inProceedings of the Intl. Conference on Grid Computing, Banff, Canada, Oct. 13–15, 2009. [6] B. Rochwerger, D. Breitgand, E. Levy, A. Galis, K. Nagin, I. Llorente, R. Montero, Y. Wolfsthal, E. Elmroth, J. Caceres, M. Ben-Yehuda, W. Emmerich, and F. Galan, “The RESERVOIR Model and Architecture for Open Federated Cloud Computing,”IBM Journal of Research and Development, vol. 53, no. 4, pp. 4:1–4:11, July 2009.

[7] G. S. Machado, D. Hausheer, and B. Stiller, “Considerations on the Inter-operability of and between Cloud Computing Standards,” inProceedings of the 27th Open Grid Forum (OGF27), Banff, Canada, Oct. 12–15, 2009. [Online]. Available: http://www.csg.uzh.ch/publications/ogf27-g2cnet-discussion-cc-standards-finalversion.pdf

[8] R. Teckelmann, A. Sulistio, and C. Reich, “A Taxonomy of Interop-erability for IaaS,” in Cloud Computing: Methodology, System, and Applications – Part 1 Chapter 3, L. Wang, R. Ranjan, J. Chen, and B. Benatallah, Eds. CRC, Taylor & Francis LLC, Aug. 2011. [9] Open Virtualization Format Specification, Distributed Management Task

Force, Jan. 12, 2010, dSP0243 Version 1.1.0.

[10] Open Virtualization Format White Paper, Distributed Management Task Force, Feb. 2009, dSP2017 Version 1.0.0. [Online]. Available: http://www.dmtf.org/standards/published documents/DSP2017 1.0.0.pdf [11] Open Grid Forum. (2010) Open cloud computing interface core & models. . [Online]. Available: http://forge.ogf.org/sf/wiki/ do/viewPage/projects.occi-wg/wiki/CoreAndModels

[12] Open Grid Forum. (2010) Open cloud computing interface infrastructure. . [Online]. Available: http://forge.ogf.org/sf/wiki/ do/viewPage/projects.occi-wg/wiki/Infrastructure

[13] Storage Networking Industry Association, “Cloud data management interface,” Storage Networking Indus-try Association, Tech. Rep., 2010. [Online]. Avail-able: http://www.snia.org/tech activities/standards/curr standards/cdmi/ CDMI SNIA Architecture v1.0.pdf

[14] Introduction to Cloud Computing Architecture, 1st ed., Sun Microsys-tems, June 2009, white Paper.

[15] D. Bernstein, E. Ludvigson, K. Sankar, S. Diamond, and M. Mor-row, “Blueprint for the Intercloud – Protocols and Formats for Cloud ComputingInteroperability,” in Proceedings of the 4th International Conference on Internet and Web Applications and Services (ICIW), Venice/Mestre, Italy, May 24–28 2009.

[16] D. Hilley, “Cloud Computing: A Taxonomy of Platform & Infrastructure-level Offerings,” Georgia Institute of Technology, Tech. Rep., 2009.

[17] B. P. Rimal, E. Choi, and I. Lumb, “A Taxonomy and Survey of Cloud Computing Systems,” inProceedings of the 5th International Conference on Networked Computing, Seoul, Korea, Aug. 25–27 2009.

[18] A. V. Parameswaran and A. Chaddha, “Cloud Interoperability and Standardization,”SETLabs Briefings, vol. 7, no. 7, pp. 19–27, 2009. [On-line]. Available: http://www.infosys.com/research/publications/setlabs-briefings/Documents/cloud-interoperability-standardization.pdf [19] W. Li, L. Ping, and X. Pan, “Use Trust Management Module to Achieve

Effective Security Mechanisms in Cloud Environment,” inProceedings of the International Conference On Electronics and Information Engi-neering (ICEIE), Kyoto, Japan, Aug. 1–3, 2010.

[20] Cloud4SOA, http://www.cloud4soa.eu/, Dec. 2010. [Online]. Available: http://www.cloud4soa.eu/

[21] Distributed Management Task Force,Interoperable Clouds – A White Paper from the Open Clouds Standards Incubator, Nov. 2009, dSP-IS0101. [Online]. Available: http://www.dmtf.org/about/cloud-incubator/DSP IS0101 1.0.0.pdf