NAVAL POSTGRADUATE SCHOOL THESIS

Transcription

1 NAVAL POSTGRADUATE SCHOOL MONTEREY, CALIFORNIA THESIS THREE-DIMENSIONAL SPACE TO ASSESS CLOUD INTEROPERABILITY by Sallouha Fazai March 2013 Thesis Advisor: Second Reader: Man-Tak Shing Albert Barreto III Approved for public release; distribution is unlimited

2 THIS PAGE INTENTIONALLY LEFT BLANK

3 REPORT DOCUMENTATION PAGE Form Approved OMB No Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instruction, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA , and to the Office of Management and Budget, Paperwork Reduction Project ( ) Washington DC AGENCY USE ONLY (Leave blank) 2. REPORT DATE March TITLE AND SUBTITLE Three-Dimensional Space to Assess Cloud Interoperability 6. AUTHOR(S) Sallouha Fazai 7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) Naval Postgraduate School Monterey, CA SPONSORING /MONITORING AGENCY NAME(S) AND ADDRESS(ES) N/A 3. REPORT TYPE AND DATES COVERED Master s Thesis 5. FUNDING NUMBERS 8. PERFORMING ORGANIZATION REPORT NUMBER 10. SPONSORING/MONITORING AGENCY REPORT NUMBER 11. SUPPLEMENTARY NOTES The views expressed in this thesis are those of the author and do not reflect the official policy or position of the Department of Defense or the U.S. Government. IRB Protocol Number N/A. 12a. DISTRIBUTION / AVAILABILITY STATEMENT Approved for public release; distribution is unlimited 12b. DISTRIBUTION CODE A 13. ABSTRACT (maximum 200 words) Cloud computing is an emerging technology that promises the reduction of IT costs (personnel, software, and hardware) for enterprises, as well as individual users. Despite this appealing offer, this technology has still not been widely adopted in the enterprise IT. Users are still worried about vendor lock-in; they will not be able to move their data and applications from one cloud provider to another easily or return to in-house IT. Currently, users do not have the means to specify and assess the interoperability level of the cloud provider that they desire to entrust their IT operations. In this thesis work, we provide a three-dimensional space to assess and visualize the interoperability level of any cloud provider so that cloud users can select the provider s services that better fit their interoperability needs. 14. SUBJECT TERMS Cloud computing, Interoperability, cloud provider, and lock-in 15. NUMBER OF PAGES PRICE CODE 17. SECURITY CLASSIFICATION OF REPORT Unclassified 18. SECURITY CLASSIFICATION OF THIS PAGE Unclassified 19. SECURITY CLASSIFICATION OF ABSTRACT Unclassified 20. LIMITATION OF ABSTRACT NSN Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std UU i

4 THIS PAGE INTENTIONALLY LEFT BLANK ii

5 Approved for public release; distribution is unlimited THREE-DIMENSIONAL SPACE TO ASSESS CLOUD INTEROPERABILITY Sallouha Fazai Lieutenant Junior Grade, Tunisian Navy Computer Engineering, Tunisian Navy, 2007 Submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE IN INFORMATION TECHNOLOGY MANAGEMENT from the NAVAL POSTGRADUATE SCHOOL March 2013 Author: Sallouha Fazai Approved by: Man-Tak Shing Thesis Advisor Albert Barreto III Second Reader Dr. Dan Boger Chair, Department of Information Sciences iii

6 THIS PAGE INTENTIONALLY LEFT BLANK iv

7 ABSTRACT Cloud computing is an emerging technology that promises the reduction of IT costs (personnel, software, and hardware) for enterprises, as well as individual users. Despite this appealing offer, this technology has still not been widely adopted in the enterprise IT. Users are still worried about vendor lock-in; they will not be able to move their data and applications from one cloud provider to another easily or return to in-house IT. Currently, users do not have the means to specify and assess the interoperability level of the cloud provider that they desire to entrust their IT operations. In this thesis work, we provide a three-dimensional space to assess and visualize the interoperability level of any cloud provider so that cloud users can select the provider s services that better fit their interoperability needs. v

8 THIS PAGE INTENTIONALLY LEFT BLANK vi

9 TABLE OF CONTENTS I. INTRODUCTION...1 A. THESIS STRUCTURE...2 II. OVERVIEW OF CLOUD COMPUTING...3 A. CONCEPT...3 B. SERVICE MODELS SaaS PaaS IaaS...6 C. DEPLOYMENT MODELS...6 D. CLOUD STANDARDS Open Cloud Computing Interface (OCCI) Open Virtualization Format (OVF) Cloud Data Management Interface (CDMI) Standards under Development...10 III. CLOUD INTEROPERABILITY...11 A. CONCEPT Vertical Dimension Horizontal Dimension...12 B. USE CASES...12 C. CHALLENGES Portability and Mobility Security, Privacy, and Trust Management...13 D. REQUIREMENTS Technology...14 a. Virtualization...15 b. Security Mechanism...15 c. Service Architecture...15 d. Data Format Management...16 a. Management Interface...16 b. Provisioning/Scheduling...16 c. Security...17 d. Monitoring/Reporting...17 e. Metering/Usage/Billing...17 f. SLA and QoS...17 g. Auditing Policy...18 a. Internal Policy...19 b. Geographical Policy...19 vii

10 IV. E. THREE-DIMENSIONAL SPACE FOR CLOUD INTEROPERABILITY Description of the Three-dimensional Space...20 a. Technology Dimension...20 b. Management Dimension...20 c. Policy Dimension Comparing Cloud Services Using the Three-dimensional Space..22 CASE STUDY: USING THE THREE-DIMENSIONAL SPACE TO COMPARE THE INTEROPERABILITY LEVELS OF TWO CLOUD PROVIDERS...23 A. OPENSTACK CLOUD Overview OpenStack Interoperability...26 B. OPENNEBULA CLOUD Overview OpenNebula Interoperability...30 C. COMPARISON OF OPENSTACK AND OPENNEBULA Visualization of Interoperability in the Three-dimensional Space...34 V. CONCLUSIONS AND RECOMMENDATIONS...37 A. THESIS SUMMARY...37 B. LIMITATIONS AND RECOMMENDATIONS...37 C. FUTURE WORK Cloud Auditing SLA and QoS Policy...39 LIST OF REFERENCES...41 INITIAL DISTRIBUTION LIST...47 viii

11 LIST OF FIGURES Figure 1. Overview of the Different Service Models of Cloud Computing (From [9] )...5 Figure 2. Control and Management Responsibilities of the Cloud Provider and the Cloud User (From [10])...5 Figure 3. Place of the OCCI in the Provider Architecture (From [11])...8 Figure 4. Overview of Openstack Architecture (From [40])...24 Figure 5. Overview of OpenNebula Architecture (From [60])...29 Figure 6. OpenStack (OS) and OpenNebula (ON) Interoperability...36 ix

12 THIS PAGE LEFT INTENTIONALLY BLANK x

13 LIST OF TABLES Table 1. Comparison of OpenStack and OpenNebula...33 xi

14 THIS PAGE INTENTIONALLY LEFT BLANK xii

15 LIST OF ACRONYMS AND ABBREVIATIONS ACL AD ANSI API AWS CDMI CLI CPU CSA DMTF EBS GUI HTTP HTTPS ICITS iscsi/lvm ISO IT KVM LDAP LXC NIST qcow QEMU QoS oauth OCA OCC Access Control List Active Directory American National Standard Institute Application Programming Interface Amazon Web Service Cloud Data Management Interface Command Line Interface Central Processing Unit Cloud Security Alliance Distributed Management Task Force Elastic Block Storage Graphical User Interface HyperText Transfer Protocol HyperText Transfer Protocol Secure InterNational Committee for Information Technology Standards Internet Small Computer System Interface/Logical Volume Manager International Organization for Standardization Information Technology Virtual-based Virtual Machine Lightweight Directory Access Protocol Linux Containers International Institute of Standards and Technology QEMU Copy on Write Quick EMUlator Quality of Service Open Authentication Protocol OpenNebula Cloud API Open Cloud Consortium xiii

16 OCCI OGF REST SLA RPC RSA SAML SNIA SQL SOA SSH SSL S3 swauth UML VM VMDK VMFS VNC XML Open Cloud Computing Interface Open Grid Forum Representational State Transfer Service Level Agreement Remote Procedure Call Ron Rivest, Adi Shami, and Leonard Adleman (algorithm for public key encryption) Security Assertion Markup Language Storage Networking Industry Association Structured Query Language Services Oriented Architecture Secure Shell Secure Socket Layer Amazon Simple Storage Service Authentication middleware for Swift Unified Modeling Language virtual Machine Virtual Machine Disk Virtual Machine File System Virtual Network Computing Extensible Markup Language xiv

17 ACKNOWLEDGMENTS The true sign of intelligence is not knowledge but imagination. Albert Einstein I would like to thank my thesis advisor, Professor Man-Tak Shing, for his guidance, constructive criticism, patience, and the unlimited time that he devoted to this work, regardless of his hectic schedule. I also would like to thank my second reader, Albert Barreto, an Information Sciences lecturer. His recommendations helped me shift focus from network security to emerging technology, and specifically, to cloud computing, which is gaining greater attention from industry and academia. The change was the start of a new journey that would be considered as the first takeoff into the cloud technology. I also would like to thank him for the time that he devoted to read this work and provide constructive feedback. I am thankful to Mr. Richard Cook and Donna Cuadrez for the time they devoted to read and edit this thesis. I am grateful to my parents, brothers, sisters, and friends for their unlimited support. Thanks to everyone who contributed to making my stay in Monterey enjoyable. xv

18 THIS PAGE INTENTIONALLY LEFT BLANK xvi

19 I. INTRODUCTION Cloud computing is an evolving technology that promises the reduction of IT expense by reducing maintenance, licensing and hardware expenditures. It succeeded in attracting the attention of industry, and the competition in this domain led to the emergence of different cloud providers, such as Google, Microsoft, and Apple. The number of cloud providers is likely going to increase. The lack of standardization, due to the infancy of this technology and the reluctance of cloud providers to adhere to standards, led to different cloud implementations. Building an interoperable cloud ecosystem becomes a mandatory requirement to free cloud users from provider lock-in, thereby stimulating cloud adoption. Indeed, users will be unwilling to move to the cloud unless they know that they can move seamlessly their data and applications from one cloud to another. Research efforts devoted to cloud interoperability have provided various solutions, such as gateways (middleware) and plugins or drivers to allow interaction among different cloud platforms. Organizations such as DMTF, OVF, and CSA focused on developing cloud standards. However, cloud interoperability is still challenging since the provided solutions have limitations. The use of gateways degrades performance as the number of systems increases, and it requires the development of a translator and adaptor for each protocol [1]. The plugin and driver approach needs an extensive coding effort to respond to the speedy increase of the number of cloud providers [2]. In addition, standardization efforts were hindered primarily because of the reluctance of cloud providers to follow these standards [3]. Moreover, these standards (e.g., OCCI, OVF, and CDMI) could not provide solutions to all the interoperability issues [4], and the specific implementation options that are included in these standards led to different cloud implementations, while using the same standard [1]. Considering the limitation of the aforementioned solutions to resolving cloud interoperability issues, this thesis focuses on providing a framework to assess the 1

20 interoperability level of any cloud provider. This framework will help users select the cloud services that better fit their interoperability needs and help cloud providers to improve the interoperability level of their services. A. THESIS STRUCTURE In Chapter II, we provide an overview of cloud technology: concept, service models, service deployments, and cloud standards. In Chapter III, we focus on cloud interoperability. We present main use cases and highlight challenging issues. We then identify interoperability requirements. We end this chapter with the presentation of a three-dimensional space for assessing cloud interoperability. Chapter IV is devoted to a case study: comparison of the interoperability levels of two major cloud providers, OpenStack and OpeNebula, to demonstrate the usage of the three-dimensional space and its benefits. We start this chapter with a study and analysis of the cloud platforms provided by both cloud providers, and we end it with a discussion and visualization of the interoperability levels of the two cloud platforms in the threedimensional space. In Chapter V, we provide a summary of this thesis work. We present its limitations and provide recommendations. Finally, we highlight several areas of interest that still need more attention from the academic, research, and industrial sectors, in order to achieve cloud interoperation. 2

21 II. OVERVIEW OF CLOUD COMPUTING A. CONCEPT Several computing paradigms, such as cluster computing, grid computing, virtualization, and Web2.0, enabled the birth of cloud computing [5]. Since its birth in late 2007, this technology has gotten many definitions; there is still no common standard to define it. In effect, it is defined as a collection of distributed computers that provides resources and services over a network depending on customer demand [6]. Another definition considers cloud computing as a collection of network-enabled services that guarantees to provide a scalable, easy accessible, reliable, and personalized computing infrastructure, based on demand with low-cost [7]. In 2011, NIST released an informal definition of this emerging technology, and claimed that this definition will change over time depending on the evolution of cloud computing: Cloud computing is a model for enabling ubiquitous, convenient, ondemand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is composed of five essential characteristics, three service models, and four deployment models [8]. The cloud computing paradigm aims to free cloud users from hardware and software dependency. It requires possession of a web browser to access these resources over a network (generally, the Internet). According to the latest NIST draft [8], cloud computing is characterized by the following characteristics that differentiate it from other computing paradigms, such as grid computing (GC) and virtualization. On-demand self-services: cloud computing provides services that can be accessed on demand easily by the customer. The customer is billed based on time of usage of these services. This billing type is referred as pay as you go. Broad network access: access to cloud services is guaranteed to diverse users using a standard mechanism. 3

22 Resource pooling: cloud services can be accessed by different customers simultaneously based on their demands, and typically, without caring about the location of these resources. Rapid elasticity: cloud services should be quickly and easily provisioned without limitations. Measured service: the use of cloud-computing services should be controlled, monitored, and recorded to avoid any problem that may occur between customers and cloud providers. B. SERVICE MODELS Many different concepts are used in research to describe cloud models, such as SaaS (Software as a Service), PaaS (Platform as a service), IaaS (Infrastructure as a Service), SaaS (Storage as a Service), and HaaS (Hardware as a Service). In this thesis, we will adopt the NIST models which are SaaS (Software as a Service), PaaS, and IaaS [8]. These models are defined according to services offered and customer ability to control and manage the compounds of the cloud infrastructure (e.g., applications, network, servers, operating systems, storage). Figure 1 provides an overview of the different service models, and Figure 2 shows the scope of control and management responsibilities of the cloud resources for the cloud provider and user (cloud service consumer). 4

23 Figure 1. Overview of the Different Service Models of Cloud Computing (From [9] ) Figure 2. Control and Management Responsibilities of the Cloud Provider and the Cloud User (From [10]) 5

24 1. SaaS The customer does not possess any control or management privileges over the cloud infrastructure (e.g., network, storage, computing resources, operating system) or applications, except very restricted application configuration settings. The customer just accesses the cloud applications through a web browser, or any other interface, and uses these applications. This model, frees the customer from installing software and paying a licensing cost. Google Docs and Microsoft Office Web Apps are examples of SaaS implementations. 2. PaaS The customer does not possess any management or control privileges over the cloud infrastructure. The customer can only deploy and manage his/her own applications and specify the settings of the application hosting environment. Google App Engine and Amazon Web Services (AWS) are examples of PaaS implementations. 3. IaaS This model offers a virtual cloud infrastructure (e.g., computing resources, networks, storage) where the customer can select and configure the cloud platform that will host his/her applications, data, and software (e.g., operating systems). Users do not have any control over the physical or virtual cloud infrastructure. They may have limited control over specific network devices (e.g., host firewall). GoGrid s Cloud Servers and Amazon EC2 are examples of IaaS implementations. C. DEPLOYMENT MODELS NIST distinguishes four deployment models for cloud computing: public, private, community, and hybrid. When the cloud infrastructure is reserved only to one organization regardless of its location (on or off premises), the cloud is referred to as private cloud. The organization can take charge of the management responsibilities of its cloud, or delegate them to a third party. In contrast, the cloud infrastructure that is accessible by the public or a large number of organizations and is normally owned by a cloud service seller is referred to as public cloud. Organizations that have common 6

25 interests (e.g., mission, security requirements) may agree to build a shared cloud. This cloud is referred to as community cloud. Regardless of whether it is on or off premises, it can be managed by these organizations or another party. The combination of two or more types of clouds, with the ability to move applications and data within these clouds, is referred to as hybrid cloud [8]. D. CLOUD STANDARDS The competition among cloud providers led to different proprietary cloud implementations that resulted in provider lock-in. This lock-in hindered the adoption of cloud computing. Research efforts conducted by non-profit working groups, such as OGF, DMTF, and SNIA, focused on standardization to stimulate the evolution and adoption of cloud computing. Many standards were developed and others are still under development. These standards aim to build an interoperable cloud ecosystem, where cloud users can move their data and applications from one cloud provider to another without any difficulty. In this section, we provide an overview of these standards. 1. Open Cloud Computing Interface (OCCI) OCCI is an open standard developed by OGF that aims to offer provider neutral tools to manage cloud resources. It was originally developed to support IaaS interoperability and later extended to include SaaS and PaaS. It focuses mainly on integration, portability, and interoperability. OGF is collaborating with other working groups, such as DMTF and SNIA, to improve cloud interoperability. As shown in Figure 3, OCCI acts as intermediate or interface between the cloud provider and users (end users or another system). The OCCI has a modular core that supports only specific cases, yet it can be expanded using renderings 1 and extensions. It has a default RESTful HTTP rendering. In order to adhere to the OCCI standard, OGF specifies mandatory requirements to guarantee an acceptable level of compatibility between different OCCI implementations [11]. 1 Renderings: define how to interact with the core model. 7

26 Figure 3. Place of the OCCI in the Provider Architecture (From [11]) OCCI is not just specification; it has many real implementations. We cite mainly the following projects (for other projects and more details, see this link ): Eucalyptus: a broadly used, open-source software for the deployment of private and hybrid cloud. It aims to provide an interoperable IaaS without imposing infrastructure restrictions. It exposes the existing infrastructure as a web service [12]. RESERVOIR (Resources and Services Virtualization without Barriers): a European Union project for the deployment and management of complex IT systems. OCCI is used to integrate RESERVOIR project and the SLA@SOI project (SLA@SOI is also a European project that focuses on SLA) [13]. OpenStack: an open operating system for building public and private cloud computing developed by NASA and RackSpace. Many other organizations joined the project later, such as HP, DELL, CISCO, and RedHat[14]. The Morfeo Claudia Platform: a cloud platform for the dynamic control of service provisioning and scalability for IaaS cloud. It can be extended through Tcloud to include PaaS and SaaS [15]. OpenNebula: an open source solution for the management of cloud data centers. It aims to provide a solution to the management of these data centers without imposing infrastructure restrictions [16]. 8

27 LibVirt: a toolkit for the management of an operating system instance running of virtual machine [17]. 2. Open Virtualization Format (OVF) OVF is an open standard developed by DMTF to provide an open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines, thereby guaranteeing portability among different virtualization platforms. OVF is a platform and vendor neutral format that can be used for single VM or multiple VMs. A virtual appliance 2 autonomously configures and modifies its configuration; therefore, there is a separation between the virtualization platform and appliance. OVF supports all the existing virtual hard-disk formats, and it can be extended to include new formats. OVF format can be extended either by adding new sections or expanding existing sections. OVF has a certification and integration mechanism that enables the platform to check the provenance and integrity of the virtual appliance. This gives more transparency to users [18]. 3. Cloud Data Management Interface (CDMI) CDMI is a SNIA interface for the management of the data stored in the cloud. The mechanisms that are used to manage data are referred to as control path and the mechanisms of data storage and retrieval are referred to as data path. CDMI features allow clients to manage their data and the containers containing this data. This interface offers management functionalities that include container and domain management, security access, monitoring and billing information. These capabilities are exposed, so they can be discovered by CDMI clients. It is compatible with standardized and proprietary data path interfaces and legacy systems, and it can be deployed above them or at the same level. CDMI is based on the notion of objects. It has five types of objects data, container, domain, queue, and capability and it has different metadata models that are used to manage the stored data. We mainly cite HTTP metadata, data system metadata, user metadata, and storage system metadata. SNIA interface enables the migration of data and metadata seamlessly from one cloud provider to another. It is on its 2 Virtual appliance is software installed on one or many virtual machines, and delivered as services. 9

28 way to becoming an ANSI and ISO standard. An open source implementation of this interface is available. There is an existing implementation of the integration of OCCI and CDMI (R2AD) and integration with OVF is under development [19]. 4. Standards under Development OCC is focusing on large data clouds. It is working to provide a unified cloud interface that unifies different cloud APIs to enable cloud interoperability [20]. IEEE is also working to provide a portability standard referred to as IEEE P2301, Draft Guide for Cloud Portability and Interoperability Profiles (CPIP), and a standard to allow two different cloud implementations to interact with each other referred to as IEEE P2302, Draft Standard for Intercloud Interoperability and Federation (SIIF) [21]. 10

29 III. CLOUD INTEROPERABILITY Although a big concern, security will not impede the adoption of cloud computing. Interoperability remains the main hindrance. With the emerging proprietary cloud implementations (e.g., EC2, Google Apps, and Microsoft Azure), cloud customers, and especially enterprises, are reluctant to move to the cloud because of vendor lock-in. They are afraid that if they are no longer satisfied with the provided services for financial, QoS, or any other reasons, they will not be able to seamlessly move to another cloud or return to in-house services. Moreover, cloud customers are unable to combine different cloud services to get the best of the bread. In this chapter, we focus on cloud interoperability: concept, use cases, and challenges. We then identify the interoperability requirements, and we end this chapter by presenting a three-dimensional space that can be used to assess the cloud provider s interoperability level. A. CONCEPT Generally, interoperability means the ability of different systems to communicate and interact with each other. Since cloud computing is an evolving technology, defining cloud interoperability is challenging [22]. The concept evolves as the technology evolves. In an interoperable cloud system, different cloud platforms (on or off premises) should be able to collaborate [23]. Cloud interoperability includes data, applications, physical or virtual machines, and other features, such as management, provisioning, policy, SLA, and QoS [3]. Cloud interoperability has the following two dimensions of focus [24]. 1. Vertical Dimension Vertical dimension is concerned only with the interoperability of a single cloud provider to the end user s devices and applications. This means that users are able to access, retrieve, store, and process their data and they can run their own applications using any device connected to the internet (e.g., laptop, desktop, and iphone). Briefly, the vertical dimension frees users from device and location dependency. 11

30 2. Horizontal Dimension Interoperability is addressed among different cloud providers. This dimension can be referred to as the cloud to cloud interoperability as described in [25]. The horizontal dimension aims to unlock the provider lock-in so users will be able to move seamlessly from one provider to another or combine services from different clouds. The horizontal dimension includes technical issues as well as other incompatibility issues, such as privacy, contracts, QoS, and security policy. B. USE CASES scenarios are: Cloud interoperability involves different scenarios. Generally, the most common C. CHALLENGES Using multiple cloud providers: either because of the limitation of one cloud provider or for other reasons, such as finance, QoS, and SLA, cloud users are willing to combine different cloud services to get the best of the bread. Combining cloud technology and in-house IT: organizations may want to combine their own IT infrastructure and applications with the cloud. For instance, they may want to use in-house IT to manage their critical assets and move unclassified information and remaining applications to the cloud. Changing the cloud provider: for whatever reasons, cloud users may need to move to another provider. Cloud federation: due to an unexpected increase in usage of the cloud resources, or for other reasons that could affect the operation of any cloud provider such as security breaches, bankruptcy, and natural disasters a cloud provider may become unable to provide services to its customers, so the provider requests services from one or more other cloud providers. Standardization is a key enabler for cloud-to-cloud interoperability, yet due to the infancy of this technology, mature standards are lacking to overcome the challenges that are hindering cloud interoperation. Actually, major cloud providers are unwilling to follow standards. Every provider implements its proprietary solutions to protect its assets [26, 27]. We can classify these challenges into the following three categories. 12

31 1. Portability and Mobility Moving VMs, data, and applications across the cloud, as well as integrating inhouse IT with the cloud, or combining cloud resources or services from different cloud providers, is still impracticable. It may require a lot of coding efforts or the use of middleware, which causes performance degradation as the number of cloud providers increases, especially for the combination or integration scenario. Cloud providers frequently offer IaaS, SaaS, and PaaS as a one stack. This makes portability and mobility difficult, because these services are highly correlated [28]. 2. Security, Privacy, and Trust Despite the improvements in authentication, identification, and integrity mechanisms in the cloud, we still lack a strong authentication mechanism for a single provider, as well as across different cloud providers. Data needs protection, whether it is in transit, or stored. Since data moves from one cloud provider to another, holding one entity liable in case of privacy violation, for example is impossible. In addition, different legislation systems around the world remain big challenges to cloud interoperability [27]. 3. Management Cloud interoperation requires the automation of all the management tasks across cloud provider boundaries, yet automation is still not achieved, even for a single cloud provider [29]. D. REQUIREMENTS Interoperability requirements are driven from the user s needs and expectations, not the cloud provider s. Providers normally look for user lock-in to protect their assets. In this section, we classify interoperability requirements into three categories: technology (the technology used by the provider to build its cloud), management, and policy. For each category, we identify the attributes to assess the interoperability level from a user perspective. SaaS and PaaS cannot be separated from the IaaS; PaaS is implemented over IaaS, and SaaS implemented over PaaS [29]. As stated earlier in this chapter, cloud 13

32 providers usually offer these services as one stack. Therefore, we look at the three service models as one stack with a main focus on PaaS/IaaS since it is the basic foundation of SaaS. 1. Technology In order to build an interoperable cloud ecosystem, the technology used by each cloud provider (virtualization, security mechanism, data representation) to build its own cloud, should be able to communicate with any other cloud provider s technology. This communication should guarantee cloud portability and mobility. Portability and mobility refer to the ability to move data, applications, images or VMs among different cloud platforms or providers. Urquhart 3 referred to portability as the ability to move an image in a "down" state, and boot it at its destination, and mobility as the ability to move a live compute workload without losing client connections or in-flight state [32]. As cloud technology evolves, the user s expectation from the cloud evolves too. Therefore, in this research, we will consider a combination of these two concepts. Cloud users may wish to move their applications, data, and VMS in a down state, as well as in-flight state. Cloud portability and mobility targets three main cloud resources: VMs, data, and applications. VMs: The ability to import locally created VMs into the cloud and move VMs across different cloud platforms or providers or hypervisors4 with minimum effort. For instance, reconfiguration of network settings is not needed [22]. VMs can be in down state or running. OVF is a step toward VM portability and mobility. Application: The ability to seamlessly move applications (including legacy applications) and their related data from one cloud to a different one and run these applications at the destination successfully. Application portability includes the migration of running applications with the required monitoring and management features [30]. The use of standardized cloud APIs could facilitate application portability [31]. Data: Data in the cloud are either stored in structured (e.g., database) or unstructured (file) forms. Data portability in the cloud is not restricted to just moving data from one location to another. Data portability depends on the applications that use this data. While moving from one cloud provider to another, cloud users need to be able to use their data in the new cloud s 3 Market strategist for Cloud computing. 4 Called also VM manager; controls different guest operating systems at the host machine. 14

33 cloud services equivalent applications. Data is not just users data. It may include data related to management and policy [32]. Achieving data portability requires platform-neutral data format, standardization of data import and export, and compatible or platform independent tools to access and store data in cloud [22], [33]. We identify the following attributes to assess the portability and mobility level of a. Virtualization The virtualization technology should offer a complete abstraction of the cloud provider infrastructure (hardware and software). Users just need a device connected to the Internet (e.g., ipad, Laptop, iphone) to access the cloud. In addition, they can access and manage their data and deploy their applications in the cloud without imposing the use of specific software (e.g., OS, web browser, programming language). Virtualization should also comply with the following requirements: Enable the migration of workloads (applications and VMs) in down state or on the fly among different clouds. Hypervisor should be OS neutral and support any existing VM format. An open, secure, portable, efficient, and flexible format for the packaging and distribution of one or more virtual machines [28]. b. Security Mechanism The deployed security mechanism should not inhibit communication with other clouds having a similar security level. It should also offer an acceptable level for the protection of the transmission of data, VMs, and applications. We focus mainly on authentication and integrity. c. Service Architecture Cloud services should be able to communicate with each other independent of their providers. How these services are designed is critical to achieving this goal. They should be designed following standards and design principles that support cloud interoperability. Following SOA principles (composability, discovery, autonomy, 15

34 loose coupling, abstraction, and standardized service contract) as proposed in [25, 34] leads to building interoperable cloud services. d. Data Format Independent of how the data is stored in data centers, cloud providers should provide tools that allow the conversion of data from one format to another and export of data, in order to allow data portability around the cloud. 2. Management Moving data, applications, and VMs around the cloud, is not enough to build an interoperable cloud ecosystem. A fundamental interoperability requirement is providing efficient management tools that allow users to monitor, provision, and control different cloud resources [35]. The ability to move from one cloud provider to another, requires checking security policy, SLA, QoS, reliability, and so on. To achieve these objectives, we need unification, automation, and openness of management activities of each cloud provider. We identify the following attributes to assess the interoperability level of provider management capabilities. a. Management Interface Cloud interoperation requires a unified and user-friendly interface for the management of services pooled from different clouds, with the least effort and interaction with the cloud provider, as stated in NIST definition of cloud computing [8]. Cloud providers are required either to provide this interface, or allow their services to be controlled by the management tools of a third party. Users can delegate the management task to the provider. b. Provisioning/Scheduling The cloud provider should provide an automatic engine that allows the allocation of its resources, as well as other cloud resources. The usage of cloud resources varies, based on user demands. If demands exceed the provider s capabilities, the 16

35 provision engine allows for the allocation of resources from other providers [36]. Resources should be published in a public directory so they can be discovered. c. Security An implemented security mechanism that guarantees the protection of user data and applications as desired. Users need an automatic engine to assess the security level of the provider s services before using them. For the scope of our work, we focus mainly on authentication and integrity. d. Monitoring/Reporting The cloud platform should provide secure and reliable tools that allow users to monitor the services they are using. These tools should alert users when there is an anomaly, such as performance degradation, increase in usage, or unavailability of service. The monitoring information should be registered for a fixed period stated clearly in the SLA or the provider s policy to avoid problem that may arise between the users and the provider. e. Metering/Usage/Billing Cloud providers should provide a reliable pricing model, such as pay as you go, so users cannot be locked out because of the payment strategy. Providers should also offer monitoring tools for users to monitor usage and pricing, so they can make informed decisions. For example, in the case of a price increase, they can either stop or change providers. f. SLA and QoS The automatic negotiation of SLAs is a critical requirement for cloud interoperation. Cloud platforms should provide an engine that supports this functionality. The negotiation should be based on QoS metrics (e.g., performance, availability, cost, reliability, security) as stated in [27]. Since cloud user demands change over time, the SLA implementation should be flexible enough to accommodate this change. 17

36 g. Auditing Checking the compliance of the cloud providers with regulations, SLA, security policy and standards, and so on increases trust between users and cloud providers. Providing the necessary tools and information to allow automatic evaluation of the cloud services is a paramount step toward an interoperable cloud ecosystem. For reliability and objectivity, we suggest that this functionality be carried out by a third trusted party which uses standardized auditing methods and publishes the audited reports openly. As discussed in [37], we are looking for a near real-time auditing capability to evaluate the offered services. 3. Policy To build an interoperable cloud ecosystem, cloud users want to move their data and applications from one cloud provider to another without changes that could affect the level of the provided services. The provider s technology is not the only obstacle to cloud interoperation. Policy can be a major impediment. For instance, providers who follow standards and best practices can build interoperable cloud implementations, yet their policies can hinder this interoperation. In fact, it is very likely that providers will have different policies: how they handle contracts, how long they keep user s records, or how often they do backups. In addition to the diversity of provider policies, legislation systems can impose barriers to cloud interoperation. Each country has its own rules concerning privacy, data protection, reliability, liability, and other issues that relate to the cloud. For instance, Europe is more conservative about privacy information than the USA [38]. Inside the same country, rules may differ at the municipal as well as the state level. Cloud interoperability mandates two fundamental requirements. First, automated and standardized engine to allow cloud providers implement their cloud policies. Second, since provider s policy cannot go beyond legislative requirements, a standard legislative system that handles all cloud issues is needed. Thereby, the provider s policy cannot be restricted because of geographical location. We propose the following attributes to assess the interoperability level of the provider s policy. 18

37 a. Internal Policy The cloud provider should provide a full, clear, and detailed description of its policy (security plan, contract management). Provider should state any constraint, requirement or obligation that should be considered in order to access its services. b. Geographical Policy Cloud providers should provide information about the physical location of their services and the legislative rules (privacy, liability, or any other rule related to cloud computing) that must be respected in order to comply with the regulation requirements of this location. E. THREE-DIMENSIONAL SPACE FOR CLOUD INTEROPERABILITY Cloud users care about maintaining the same level of services, while moving around the cloud or combining different clouds. They may also wish to keep the same SLA, security level, and QoS. Before adopting any cloud provider, users need answers to many questions to assess the interoperability level of the provider services. These questions include: Independent of the software and hardware that they have, can users access to the provider s services? Does the provider technology allow users to move easily their data, applications, and VMs to another cloud either on the fly or in a down state? Can users pool services from other providers and still control and manage all the pooled services in a unified way? Does the provider policy allow users to move across the cloud while maintaining the same level of services? Will Geographical regulation pose a problem? We build a three-dimensional space to provide and visualize a unified answer to all these questions. In this section, first we start by presenting the three-dimensional space. Then, we discuss how interoperability is evaluated at each dimension. 19

38 1. Description of the Three-dimensional Space a. Technology Dimension This dimension evaluates the interoperability level of the technology used by the provider to build its own cloud, but does not consider the management capability or the tools used to implement policy. It evaluates the portability and mobility level of the provider s services; that is, whether cloud users are able to move their applications, data, and VMS without facing technical problems. We will use the following attributes to evaluate the interoperability of the provider s technology Virtualization technology Service architecture Security mechanism Data format The interoperability level is considered low in cases where the virtualization technology, the security mechanism, the service architecture, or the data format prevents the interaction with other cloud services. Significant efforts (time and money) are needed to achieve interoperability. The interoperability level is considered medium in cases where users are able to move their data, applications and VMs in a down state, yet they cannot move them in an in-flight state. The provider services do not support cloud mobility. The interoperability level is considered high in cases where the provider s services support cloud portability and mobility. There may be minor issues, but they can be resolved easily without waste of time and money. b. Management Dimension This dimension evaluates only the provider management capabilities. It helps users to know whether the provider s management tools support cloud interoperability. As explained earlier in this thesis, the interoperability level of the management capabilities will be evaluated based on the following attributes: Management interface Provisioning/Scheduling capabilities Metering/Usage/Billing capabilities 20

39 Monitoring/Reporting capabilities SLA and QoS Security (Does the provider have a mechanism for user authentication and data protection, and can users automatically evaluate the security level of this mechanism?) Auditing capability Automation plays a critical role in the evaluation of management capabilities. We associate a low interoperability level when the provider management capability does not meet the basic requirements that support cloud interoperability, such as: the cloud provider does not provide a management interface that allows users to manage different cloud services; its services cannot be managed by third party tools; or the pricing model does not support cloud interoperability. A lot of manual interaction with the cloud provider is required to resolve management issues. A medium interoperability level is achieved when the cloud provider s management capabilities allow users to manage (provision and monitor) different cloud services in a unified way, or the provider services can be managed by third party tools. The provider still lacks automated tools that enable automatic SLA negotiation, security assessment, and auditing. A high level is achieved when the provider management capabilities is fully automated. c. Policy Dimension This dimension evaluates the interoperability level of the provider s policy. It helps users to assess whether this policy is able to interact with any other provider s policy without being locked because of geographical regulations or constraints imposed by the provider. Transparency, automation, and standardization play a critical role in the evaluation process. A high level of interoperability is associated with policy that does not stand as barrier to cloud collaborations. The provider policy is expressed in a standardized way and can automatically interact with any other policy without being hindered by geographical regulations (e.g., universal agreement on legislation, best practices and standardization for the security policy). Attaining this level is still infeasible 21

40 because it goes beyond the provider level to include political issues that should be tackled at the regional, national, and international level. The interoperability level is considered medium when the provider policy is able to interact automatically with any other policy within the same geographical boundaries. Legislation requirements still prevent wider cloud interoperation. The interoperability level is considered low when the provider s policy is not automated or still lacks information about either the provider internal policy or the geographical regulations. 2. Comparing Cloud Services Using the Three-dimensional Space The three aforementioned dimensions help cloud users to assess the interoperability level of the cloud provider services based on the technology used to build the cloud, management capabilities, and policy. Users can consider using the three dimensions together, or they may use two or only one of the dimensions in case they want to make tradeoffs. For example, some cloud users may not care about the management capabilities, and they only want to avoid technical and policy issues while moving from one cloud to another. Therefore, the interoperability level of the provider s services can be defined by the following equation. α, β, and are weights defined by the cloud user and Ltech, Lmang, and Lpol respectively represent the interoperability levels at each dimension, technology, management, and policy which can be low, medium, and high. The levels low, medium, and high can be replaced respectively by 1, 2, and 3 to quantify the interoperability levels so they can be compared easily. 22

41 IV. CASE STUDY: USING THE THREE-DIMENSIONAL SPACE TO COMPARE THE INTEROPERABILITY LEVELS OF TWO CLOUD PROVIDERS Open source cloud-computing projects are gaining great attention. Unlike proprietary solutions, these projects are speeding the evolution and adoption of cloud computing. They help to save licensing costs and build an interoperable cloud environment, where users do not need to worry about vendor lock-in. Since the source code is open, either new or existing cloud providers can adopt successful cloud solutions, and reuse them in building their own clouds. This leverages cloud interoperability. Examples of these projects include: OpenStack, Eucalyptus, OpenNebula, and Nimbus. In this chapter, we will use the three-dimensional space presented in Chapter III to assess the interoperability level of two major IaaS cloud providers: OpenStack and OpenNebula. We start by providing an overview of the two cloud platforms provided by these providers, and then we discuss the interoperability level of each platform using one dimension at a time. We end this chapter with a comparison of the interoperability levels of the two cloud platforms. A. OPENSTACK CLOUD 1. Overview OpenStack is a cloud operating system developed by NASA and Rackspace for building private and public clouds licensed under Apache license version 2.0, and written in Python. More than 190 companies support this project (e.g., Dell, HP, IBM, Cisco, RedHat). The OpenStack project was originally composed of three separate components: a compute service known as Nova; an object storage service known as Swift; and an image service known as Glance. Other components were added to later releases. For now, Folsom release includes these additional components: Dashboard, referred to as Horizon; an identity service, known as Keystone; network service, known as Quantum; and block storage service, known as Cinder. As shown in Figure 4, these services interact with each other through RESTful APIs. Users can interact directly with these services through their APIs, or by using Dashboard. Keystone is the default authentication mechanism for all OpenStack services [39-41]. 23