Openstack: the Cloud OS - Technical Report

University of Duisburg-Essen Paluno

Software Systems Engineering

Prof. Dr. Klaus Pohl

OpenStack: The Cloud OS - Technical Report -

Hasan Mohamed Ibou

Supervisor: Dr. Clarissa Marquezan

25.10.2013 OpenStack: The Cloud OS Technical Report

Hasan Mohamed Ibou Supervisor: Dr. Clarissa Marquezan

Universiy of Duisburg-Essen Paluno - The Ruhr Institute for Software Technology Gerlingstraÿe 16 45127 Essen, Germany [email protected] [email protected]

1 2

Abstract This report covers OpenStack as an IaaS (Infrastructure as a Service) management system in context of cloud computing. The goals of this study are: learn the basics of cloud computing, learn more about OpenStack as a cloud OS (Operating System) and retrieve information and concert data out of OpenStack for the monitoring and opti- mizing of machines on both the physical and logical level. The researched informations in this report should serve the goal of manipulating and monitoring the possibilities of a cloud under OpenStack and the entities of a cloud such as cloud-based applications while considering the physical and the virtual level of the machines in order to optimize each entity of the cloud system to get the cloud environment as a big picture running more eectively, eciently, and in the best case, automatically. This document is structured as following: it starts with an introduction to cloud computing and OpenStack. It then investigates the linking of OpenStack to the ap- propriate cloud computing level. After combining both topics, it previews the core components of OpenStack individually and mentions the important sub-components of the core components of OpenStack. The report is divided in three parts and ends with a conclusion previewing the results of this study.

Keywords: Cloud Computing, OpenStack, Cloud OS, IaaS-Management-System 3

Acknowledgment: I would like to thank Dr. Clarissa Cassales Marquezan for the great help in writing this document. Preface

The aim of this record is to help everyone who is interested in learning about the cloud OS OpenStack under a technical point of view. The report helps giving a basic introduction to cloud computing and OpenStack by describing the components of OpenStack and the way the whole system works together. Intended Audience

This technical report is for everyone who has a very basic background in computer science and want to learn the basics of cloud computing and manipulating clouds with OpenStack. 4

Contents

1 Introduction to Cloud Computing ...... 7 1.1 Denition ...... 7 1.2 Service Models of Cloud Computing ...... 7 1.3 Types of Clouds and Cloud Comparison ...... 8 1.3.1 Types of Clouds ...... 8 1.3.2 Cloud Comparison ...... 9 1.4 Summary ...... 9 2 Introduction to OpenStack ...... 10 2.1 Infrastructure Management Systems (Stacks) ...... 10 2.2 OpenStack ...... 10 2.2.1 The Project and The Goals ...... 10 2.2.2 Project Releases ...... 11 2.2.3 Community and Users ...... 11 2.3 Components of OpenStack ...... 12 2.4 Installation Architecture of OpenStack ...... 13 2.4.1 Single Node ...... 13 2.4.2 Two and Multi Node ...... 14 2.4.3 Requirements ...... 14 2.5 Conceptual and Logical Architecture ...... 15 2.6 Summary ...... 16 3 Components of OpenStack ...... 17 3.1 Dashboard - Horizon ...... 17 3.2 Compute - Nova ...... 18 3.2.1 nova-api ...... 19 3.2.2 nova-api-metadata ...... 19 3.2.3 nova-compute ...... 19 3.2.4 nova-schedule ...... 20 3.2.5 nova-conductor ...... 20 3.2.6 nova-network ...... 20 3.2.7 nova-novncproxy ...... 20 3.2.8 nova-xvpnvncproxy ...... 20 3.2.9 nova-consoleauth ...... 20 3.2.10 nova-dhcpbridge ...... 20 3.2.11 nova-console ...... 20 3.2.12 nova-cert ...... 20 3.2.13 euca2ools ...... 21 3.2.14 nova-objectstore ...... 21 3.2.15 nova ...... 21 3.2.16 nova-manage ...... 21 3.2.17 The queue ...... 21 3.2.18 SQL database ...... 21 3.3 Object Store - Swift ...... 23 3.3.1 Proxy server (swift-proxy-server) ...... 23 3.3.2 Account servers ...... 23 5

3.3.3 Container servers ...... 23 3.3.4 Object servers ...... 23 3.3.5 Other processes ...... 24 3.4 Image Store - Glance ...... 24 3.4.1 glance-api ...... 24 3.4.2 glance-registry ...... 24 3.4.3 A database ...... 24 3.4.4 A storage ...... 24 3.4.5 Other processes ...... 25 3.5 Identity - Keystone ...... 25 3.5.1 keystone ...... 25 3.6 Network - Quantum ...... 25 3.6.1 quantum-server ...... 26 3.6.2 plug-ins and agents ...... 26 3.7 Block Storage - Cinder ...... 26 3.7.1 cinder-volume ...... 26 3.7.2 cinder-api ...... 26 3.7.3 cinder-scheduler ...... 27 3.8 Summary and Conclusion ...... 27 6

List of Figures

1 Cloud computing services and layers [1, 2] ...... 8 2 Dierence between basic types of Clouds[1, 2] ...... 9 3 OpenStack Releases [5, 6] ...... 11 4 Components of OpenStack [6] ...... 13 5 OpenStack Hardware Recommendations for Production[6] . . . . 14 6 Logical Architecture of OpenStack [6] ...... 16 7 OpenStack Dashboard [6] ...... 17 8 Functions of Compute Sub-Components [6] ...... 19 9 Database Schema [6] ...... 22 1 Introduction to Cloud Computing 7

1 Introduction to Cloud Computing

This part12gives an introduction to cloud computing by answering the questions: What is cloud computing?, What are the service models of cloud computing?, and What are the deployable arts of clouds?

1.1 Denition Cloud computing[2] revolutionizes the services and business domain. It opens up big opportunities for research and production with its powerful features such as scalability, performance, and reduced upfront investments. Especially, pay-as-you-go and service-orientation are important functionalities for business today. Cloud computing uses virtualization as a key enabling technology that is simulating logical hardware resources from physical resources[3]. But what is cloud computing? The National Institute of Standards and Technology (NIST) has the following denition for cloud computing[2]: Cloud computing is a model for enabling ubiquitous, convenient, on - demand network access to a shared pool of congurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management eort or service provider interaction.

1.2 Service Models of Cloud Computing Cloud Computing provides its resources as services. There are currently six provided services[2]: Infrastructure as a Service (IaaS), Network as a Service (NaaS), Platform as a Service (PaaS), Identity and Policy Management as a Service (IPMaaS), Data as a Service (Daas), and Software as a Service (SaaS). These services ll into three main cloud computing layers, which are: hardware, system, and application. Figure 1 shows the services with the associated layers.

1 Main source of this document: ocial OpenStack documentaries 2 Considered version: OpenStack Grizzly 1 Introduction to Cloud Computing 8

Service \ Layer Hardware System Application Main Service Software as a Service (SaaS) x Data as a Service (Daas) x SaaS Identity&Policy Manage as a Service (IPMaaS) x Platform as a Service (PaaS) x Paas Network as a Service (NaaS) x IaaS Infrastructure as a Service (IaaS) - logical - x

Fig. 1: Cloud computing services and layers [1, 2]

The mentioned six services could be abstractly grouped in three main services[1]: 1. Infrastructure as a Service (IaaS): consists of hardware (such as CPUs, RAMs, Storage, and Network), and logical infrastructure (such as virtual machines VMS). 2. Platform as a Service (PaaS): provides frameworks and operating systems for software development. 3. Software as a Service (SaaS): contains applications running on the logical layer. Each of these three layers could be provided separately by dierent cloud service providers such as Amazon or IBM and then combined to t the organization's needs. However, all of them could be provided as a package of services by a single cloud provider such as Google, for example[1].

1.3 Types of Clouds and Cloud Comparison This section explains the dierent types of clouds based on the dierent implementations of clouds with the aspects that inuence the decision of choosing a cloud type. After that, the section makes a comparison between the basic types of clouds in order to better understand these types.

1.3.1 Types of Clouds The dierent implementations of clouds depend on the needs and purposes of a cloud. The dierent implementations cause dierent types of clouds. The future needs and use of the cloud - whether in research or production - determines the cloud's type. Also cost, security, and customariness widely inuence the decision of choosing the correct cloud type wildly[1]. The main types of clouds are public and private clouds. There are dierent combinations of private and public clouds such as hybrid, and community clouds. The most common types of clouds are named below[1][4]:

I Public Clouds: cloud resources are open for public use. I Private Clouds: cloud resources are owned or leased by a single organization. 1 Introduction to Cloud Computing 9

I Hybrid Clouds: composition of dierent types of clouds to enable a service. I Community Clouds: cloud resources are shared by several organizations. I Virtual Private Clouds (VPC): private clouds over public ones via vpn. After mentioning the types of clouds, next is a short comparison between public, private, and virtual private clouds.

1.3.2 Cloud Comparison The public and private clouds are the basic types of clouds[1]. The other types of clouds could be delivered from public and private clouds as well as virtual private clouds. The main dierences between public, private, and virtual private clouds is shown in gure 2 [2].

Aspect \ Cloud Public Private Virtual Private Cost low high low Customization no yes yes Privacy low high high

Fig. 2: Dierence between basic types of Clouds[1, 2]

Public clouds have generally low cost as an advantage, but they are neither secure nor customizable. On the other hand, private clouds are secure and highly customizable but they have pretty high cost. Virtual private Clouds combine the advantages of both public and private clouds by providing more security and customization ability with low cost. The decision of choosing the right cloud must be very precise, which is why the design of clouds is very important process before purchasing infrastructure[1, 2]. Every aspect and possible use of the cloud must be planned and considered correctly before the implementation phase. This simplies achieving the purpose of the cloud correctly.

1.4 Summary This part has mentioned a denition of cloud computing, a description of resources of cloud computing, and has summarized them in three main services: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). It concludes with a dierentiation between dierent types of clouds and some important aspects to consider when choosing a cloud type. 2 Introduction to OpenStack 10

2 Introduction to OpenStack

This part names dierent infrastructure management software systems such as OpenNeubla or Eucalyptus. It then reviews OpenStack by giving basic information about the goals of the OpenStack project, a list with versions of Open- Stack, examples of universities and companies where OpenStack is currently deployed, and views both the conceptual and logical architecture of the Open- Stack projects. Finally, it lists the components of OpenStack and shows the dierent installation architectures of OpenStack with the recommended hardware requirements.

2.1 Infrastructure Management Systems (Stacks) There are dierent software and systems to manage cloud Infrastructure and data centers generally on an IaaS (Infrastructure as a service) level. These systems are often informally called Stacks. Some of these Stacks are open-source and some are commercial. Stacks deliver implementations for public, private, or another type of clouds. Examples of current cloud infrastructure systems are: HP CloudSystem, IBM CloudBurst, ElasticStack, OpenStack, etc. The most used open-source alternatives are: OpenStack, OpenNebula and Eucalyptus. The development of OpenNeubla and Eucalyptus has started in the middle of 2008, while the development of OpenStack has started in late 2011. OpenStack has a large community and support of several big companies and organizations which lead to relatively rapid development, despite the late start of development. On October 17, 2013, Havana is scheduled to be be published as the eighth release of OpenStack. One of the OpenStack project objectives is: being the ubiquitous software choice for building cloud infrastructures. Actually, OpenStack is currently achieving the objective of becoming a standard choice for cloud infrastructure in many research and production organizations. The next section gives a more detailed information on this.

2.2 OpenStack This section denes OpenStack, names the goals of the OpenStack project, lists the releases of OpenStack, and gives an overview of organizations where OpenStack is currently deployed.

2.2.1 The Project and The Goals The OpenStack Project is [6] an open-source cloud computing platform for public and private cloud. The Project focuses initially on[5] Infrastructure as a Service (IaaS) oering. The main objective of the OpenStack project is: [6] to produce the ubiquitous Open Source Cloud Computing platform that will meet the needs of public and private clouds regardless of size, by being simple to implement and massively scalable which derives the goals of OpenStack: being a standard software for cloud infrastructure, simplicity, and scalability. Embrace 2 Introduction to OpenStack 11 of openness is [5] a core value behind the project with both open standards and open code. OpenStack has been released under the Apache 2.0 license. OpenStack also encourages standard through the OpenStack API. Rackspace3 and NASA4 [5] have originally started the OpenStack project in September 2012. Companies like [6] AT&T, Rackspace, HP, IBM, Canonical, Red Hat, SUSE, Cisco, Dell, and Intel are only some examples of more than 1505 supporter companies with a very active and large community of contributers.

2.2.2 Project Releases The OpenStack project has a large and active global community, leading to rapid development. The rst version Austin was released on the October 21, 2010 and the release date of the new release Havana should be the October 17, 2013. October 21, 2010. Figure 3 lists the releases of the OpenStack project.

Release Name Release Date Havana 17.10.2013 Grizzly 04.04.2013 Folsom 27.09.2012 Essex 05.04.2012 Diablo 22.09.2011 Cactus 15.04.2011 Bexar 03.02.2011 Austin 21.10.2010

Fig. 3: OpenStack Releases [5, 6]

2.2.3 Community and Users The large and extremely active community [5] leads to rapid development as seen in 2.2.2. The community consists of many developers, translators, and supporters from both academic and enterprise eld. The OpenStack project has active forums, a well structured wiki, clear documentations, mailing lists and, IRC-channel. The users of OpenStack are [5] researches, corporations, service providers, or data centers who are looking to deploy large-scale cloud deployments for private or public clouds. Currently, there are [6] 1216 organizations that rely on OpenStack such as Harvard University and CERN7 from the research area or PayPal and Cisco in in the eld of enterprise.

3 Hosting organization in USA 4 Space agency in USA 5 full list: http://www.openstack.org/foundation/companies/ 6 http://www.openstack.org/user-stories/ 7 The European Organization for Nuclear Research 2 Introduction to OpenStack 12

2.3 Components of OpenStack There are currently seven core components [6] of OpenStack: Compute, Object Storage, Identity, Dashboard, Block Storage, Network, and Image Service. Each of them has a code name. Below, there is a short description for each component.

I Compute (codenamed "Nova"): provides virtual computing servers on demand.

I Object Store (codenamed "Swift") : allows storing and retrieving les.

I Identity (codenamed "Keystone"): provides authentication and authorization for other OpenStack services and also provides a catalog of services within a particular OpenStack cloud.

I Dashboard (codenamed "Horizon"): provides a web-based GUI (Graph- ical User Interface) for all other OpenStack services. Dashboard allows managing of virtual machines (VMS) manipulation operations.

I Block Storage (codenamed "Cinder"): supplies a block storage to guest VMS.

I Network (codenamed "Quantum"): provides Network as a Service(NaaS) between devices managed by other OpenStack services (mostly Compute).

I Image (codenamed "Glance"): provides a catalog and repository for virtual disk images that are mostly used in Compute.

Figure 4 shows the relationship between the core components of OpenStack. 2 Introduction to OpenStack 13

Fig. 4: Components of OpenStack [6]

2.4 Installation Architecture of OpenStack OpenStack uses a share-nothing policy and messaging-based architecture[6] that allows a exible architectures. Each of the components (or widely sub components) is runnable on dierent server. The components are connected to each other via HTTP (Hypertext Transfer Protocol) and AMQP (Advanced Mes- sage Queue Protocol). That means that each component could separately work on a dierent machine. There are basically three types of possible installation architectures of OpenStack.

I Single node: one server runs all the components. Mostly used for practice and learn purposes.

I Two nodes: cloud controller server (all components of: compute - without the sub-component nova-compute, Image, Object Store, authentication, and Dashboard services) and another server runs only the sub-component nova-compute

I Multiple nodes: can be achieved by simply adding another nova-compute server to the two node architecture and copying the nova.conf le to the new nova-compute server.

2.4.1 Single Node The single node architecture is useful for earning and practicing purposes. It is an easy and very fast way to get hands on OpenStack quickly without deeper 2 Introduction to OpenStack 14 learning about the conguration and installation process for each component. All that is needed is a Linux-based server8 and a DevStack 9 installation. De- vStack can be downloaded at http://devstack.org.

2.4.2 Two and Multi Node The single node architecture is only try-oriented and is not recommended for production use at all. The production architecture typically contains two (or more) nodes (at least 2 servers and one client). This architecture is of course exible and highly scalable for production needs. It also allows the three copies concept of having three data backups by connecting to a database.

2.4.3 Requirements Figure 5 shows the recommended hardware requirements for OpenStack for production purposes. Minimum hardware requirements for Single Node (test environment) are: dual-core processor with 2 GB of RAM and two network cards (one could be virtual). A Controller Node in a Two Node environment runs network, volume, API, scheduler, and image services while Compute Node runs the VMS. In Cloud Controller Node: a quad core server with 12 GB of RAM would be more than sucient and two NICs are recommended but not re- quired. In Compute Node: AMD processor with SVM (Secure Virutal Machine Mode also called AMD-V) extensions or Intel processor with VT (virtualization technology) extensions.

Node Recommended Hardware Processor: 64-bit x86 Memory: 12 GB RAM Cloud Controller Disk space: 30 GB (SATA, SAS or SSD) Volume storage: two disks with 2 TB (SATA) Network: one card with 1 Gbps NIC10 Processor: 64-bit x86 Memory: 32 GB RAM Compute Disk space: 30 GB (SATA) Network: two cards with 1 Gbps NICs

Fig. 5: OpenStack Hardware Recommendations for Production[6]

Hint: The idea of putting this section directly at this place is to give an early chance to get hands on OpenStack easily and fast without the need to go deeper into the report using DevStack. This could be useful for a reader who want just to use OpenStack in order to test the environment or test applications on it. 8 Most used: Ubuntu or Fedora server cloud edition 9 DevStack is an opinionated script to quickly create an OpenStack development environment 2 Introduction to OpenStack 15

There is an easy way to test an elastic web application on the cloud using TryStack (trystack.org) that allows trying the application on a pre-installed OpenStack environment with no need to install OpenStack on own machines.

2.5 Conceptual and Logical Architecture The goal of OpenStack is [6] to deliver a massively scalable cloud OS (operating system). The design used [6] to achieve this is service-orientated design as shown in gure 4. That means that each component of OpenStack is [6] designed (on a conceptual level) as a divided service which oers and consumes from other services. The services collaborate [6] with each other and are integrated through application programming interfaces (APIs). These APIs are [6] mostly the same as end user APIs. This conceptual design allows [6] an implementation of selected services if other services are not needed. Modules, on the other hand (and on a logical level), are [6] organized according to the function they implement. The modules are classied [6] according to their type. There are [6] four types of modules used in the OpenStack project: daemon: runs as a daemon (background process), script: a script run by an external module when some event happens, client: a client for accessing the Python bindings for a service and

CLI: a Command Line Interpreter. Figure 6 shows the logical architecture of the OpenStack project. 2 Introduction to OpenStack 16

Fig. 6: Logical Architecture of OpenStack [6]

2.6 Summary Part two has named dierent infrastructure management systems (or Stacks) such as OpenNebula. After that, it has given an overview of the OpenStack project goal, which is: becoming a standard software for cloud infrastructure with focus on simplicity and scalability. It has then shown the available releases and the active community behind the project. This part has also answered the question of where OpenStack is currently deployed and used. After that, it was shown that the design of OpenStack is service-oriented and the types of modules are: daemon, script, client, and CLI (Command Line Interpreter). At the end of this part, the single-node and multi-node have been presented as main installation architectures of OpenStack with a look on the recommended hardware requirements for each of both architectures. This part concludes with giving an advice on getting OpenStack fast using DevStack or testing web applications on a ready-to-use OpenStack environment using TryStack. 3 Components of OpenStack 17

3 Components of OpenStack

This part focuses on the core components of OpenStack without mentioning other OpenStack projects (such as OpenStack - Ceilometer a Metering Project). This part reviews the core services of OpenStack separately by naming the sub-components and entities for each core service. The key features of the components will also be covered to give a better description for each component. his part concludes with the results of this report.

3.1 Dashboard - Horizon Dashboard is a web application that provides an end user and administrator interface in order to manage other OpenStack services. Dashboard is deployed via mod_wsgi (python) in Apache. Dashboard basically represents the provided interactions with other OpenStack APIs. Dashboard is also customizable for dierent providers and has a database that has a small capacity but relies on other data services. Dashboard allows managing instances (VMS), images, key pairs, volumes, containers, etc. The console of an instance (VM) could be also accessed directly from the dashboard. Figure 7 shows the dashboard interface that can can be accessed through the local host address within a web browser.

Fig. 7: OpenStack Dashboard [6] 3 Components of OpenStack 18

Some examples [7] of Dashboard features:

I User and Security Management: manipulation of users, groups (tenants), roles, projects, key pairs, assigning oating IPs, etc.

I Instance Management: creating, terminating, launching, starting, stopping of instances or accessing the consoles of the launched instance.

I Volume & Network Management: attaching volumes or creating network resources.

I Flavor Management: managing of dierent avors (hardware templates), adjusting hardware congurations for specic instances or dening new ones.

I Image and Volume Management: editing or deleting images, creating volumes and snapshots (save a state of a VM for later use).

I Object Store Management: creating, deleting containers and objects. 3.2 Compute - Nova Compute is the heart of OpenStack. It manages all the activities associated with the life cycle of a VM instance. Compute combines dierent processes together to execute user requests into running virtual machines. Compute manages compute resources, networking, authorization, and other core processes in the cloud. However, Compute does not provide any virtualization by itself; instead, it uses an API to interact with hypervisors. The API of Compute is compatible with the EC2 API of Amazon Web Services. Some features of OpenStack Compute:

I Instance life cycle management I Compute resources management I Network and Authorization

I REST-based API I Hypervisor independence. The sub-components of Compute are shown together with the function for each sub-component in Figure 8. 3 Components of OpenStack 19

Sub-Component Function nova-api API nova-api-metadata API

nova-compute Computing Core nova-schedule Computing Core nova-conductor Computing Core

nova-network Networking for VMS nova-dhcpbridge Networking for VMS

nova-consoleauth Console Interface nova-novncproxy Console Interface nova-console Console Interface nova-xvpnvncproxy11 Console Interface nova-cert Console Interface

nova-objectstore Image Management euca2ools Image Management

nova CLI12 & Interface nova-manage CLI & Interface The queue CLI & Interface The SQL database CLI & Interface

Fig. 8: Functions of Compute Sub-Components [6]

3.2.1 nova-api basically deals with end user API requests. The nova-api supports OpenStack Compute API, Amazon's EC2 API, and a special admin API.

3.2.2 nova-api-metadata Accepts meta data requests from instances. The nova-api-metadata can only be used with an multi-node architecture.

3.2.3 nova-compute A main worker daemon (background process) that creates and terminates VM instances via hypervisor APIs. The nova-compute accepts actions from the queue and performs system commands while updating the states in a database. 3 Components of OpenStack 20

3.2.4 nova-schedule The nova-schedule takes a virtual machine instance request from the queue and determines on which compute server host this request should run.

3.2.5 nova-conductor A new module added to the Grizzly release deals with the database access of nova-compute. The nova-conductor eliminates the direct accesses to the database made by nova-compute for security and upgrade aspects. The nova- conductor should be deployed in dierent node where nova- compute is deployed.

3.2.6 nova-network The nova-network is a worker daemon that accepts networking calls from the queue and performs network-oriented tasks. This functionality is being migrated to OpenStack Networking.

3.2.7 nova-novncproxy A daemon for providing a proxy for accessing running instances through a VNC connection. The nova-novncproxy supports browser-based novnc clients.

3.2.8 nova-xvpnvncproxy A daemon is a proxy for accessing running instances through a VNC connection. The nova-xvpnvncproxy supports a Java client specically designed for OpenStack.

3.2.9 nova-consoleauth A daemon for authorizing user's tokens that console proxies provide. The nova- consoleauth is needed for running the console proxies.

3.2.10 nova-dhcpbridge The nova-dhcpbridge is a script for tracking and recording IP addresses in a database using dnsmasq's dhcp-script. The same functionality with dierent script is also provided by OpenStack Networking.

3.2.11 nova-console An old daemon which is no longer used with the Grizzly release. The nova- xvpnvncproxy is used instead.

3.2.12 nova-cert A daemon to manage x509 certicates. 3 Components of OpenStack 21

3.2.13 euca2ools A client and not provided by OpenStack itself but euca2ools can be supported by OpenStack. It is a set of CLI (command line interpreter) commands for managing resources of the cloud. 13

3.2.14 nova-objectstore A daemon that provides an interface in S3 (a programming language). The nova-objectstore daemon is used for registering images in the image management service. The nova-objectstore translates the requests of euca2ools from s3 into OpenStack Image requests.

3.2.15 nova A client that enables submitting the administrator's or user's commands.

3.2.16 nova-manage A client for submitting administrator commands.

3.2.17 The queue A central hub for passing messages between daemons. Usually implemented with RabbitMQ, it is possible with any AMPQ such as Apache Qpid or Zero MQ.

3.2.18 SQL database Stores build-time and run-time states of instances, networks, and projects. The- oretically, any database with an SQL-Alchemy is supported by OpenStack Com- pute, but currently sqlite3, MySQL, and PostgreSQL are widely used. Some important tables are describes below. Tables of Nova-DB: networks: Information about networks dened by Compute such as vpn address or gateway. instances: Describes VM-oriented information such like state, location, or address of a VM. xed_ips: Allocating and assigning of xed addresses to VMS in a network. oating_ips: Allocating and assigning of oating addresses to VMS in a network. volumes: Representation of volumes attached to VMS. projects: Information about projects including project manager.

13 For more information see http://www.eucalyptus.com/eucalyptus- cloud/documentation/2.0 3 Components of OpenStack 22 services: Registered services and the current state of each service auth_tokens: Mapping of API request with users key_pairs: Pair keys for SSH connections users: Contains information about users containing admin privileges

Fig. 9: Database Schema [6]

Schema: The schema of tables of nova-DB visualizes the tables and describes the relationships between them. The schema is shown in gure9. A detailed 3 Components of OpenStack 23 list14 of the tables and attributes is added to the Appendix. Compute turns user commands to VMS with the help of dierent APIs, computing cores, command line interpreters, console Interfaces, and other Open- Stack services and interfaces. These subcomponents of Compute interacts with each other to provide runnable and accessible virtual machines in the cloud.

3.3 Object Store - Swift Object Store provides [7] a distributed and consistent virtual object store (les and containers) service for OpenStack. Object Store is like Amazon Web Ser- vices - Simple Storage Service (S3). The Object Store stores objects distributed across nodes, has built-in redundancy and fail-over management, is extremely scalable, and is capable of archiving and media streaming. The architecture of Object Store is [6] distributed to prevent any failure and to scale horizontally. Some features [7] of OpenStack Object Store:

I Large Storage of (large)objects I Redundancy of data I Archiving and media streaming capability I Data container for VMS and cloud applications

I Security, backup, and scalability Object Store consist of the following sub-components:

3.3.1 Proxy server (swift-proxy-server) The swift-proxy-server accepts [6] user requests via Object Store API or just HTTP, accepts les uploading and meta data modications, and listens to web browsers to serve les.

3.3.2 Account servers Account servers serve and manage [6] accounts dened within Object Store.

3.3.3 Container servers Container servers serve and manage [6] containers (folders) mapping within Object Store.

3.3.4 Object servers Object servers serve and manage [6] les in Object Store.

14 https://docs.google.com/spreadsheet/ccc?key=0AsUHVTZg__ridEE3cjdrTWZaRGxtSXd0dVRUT0ZsdlE&hl=en_US#gid=0 3 Components of OpenStack 24

3.3.5 Other processes Periodic processes with housekeeping tasks such as [6] consistency, availability state, auditors, updaters, and reapers. Authentication is handled through WSGI (Web Server Gateway Interface) middle ware OpenStack Network. The OpenStack Object Store generally manipulates and manages the data in the OpenStack project through several servers such as object, container, account, and proxy servers. Object Store uses other processes to ensure consistency and availability and is accessible through Object Store API or HTTP.

3.4 Image Store - Glance Image Store handles and manages the images used by the VMS. Image Store also has a central role in the IaaS big picture. It accepts API requests from users or OpenStack Compute and stores its les in Object Store. Some features [6] of OpenStack Image Store:

I Image and image status Identifying I Image registering

I Image meta data and Image retrieving Image Store has the following [6] sub-components:

3.4.1 glance-api The glance-api accepts [6] image API calls for image discovery, retrieval, and storage.

3.4.2 glance-registry The glance-registry stores, processes, and retrieves [6] meta data about images (size, type, etc.).

3.4.3 A database A database to store [6] image meta data. As in other OpenStack components it is freely selectable but MySQL or SQlite are the mostly used.

3.4.4 A storage A storage for the actual image les. Object Store is the default image repository [6] but this is congurable. The Image Store project also supports normal le systems, RADOS, Amazon S3, and HTTP (some of these choices are limited to read-only). 3 Components of OpenStack 25

3.4.5 Other processes Periodic processes to support [6] caching, consistency and availability. The Image Store project delivers and manages image service to the Open- Stack project. It checks, identies, and registers VM images. It accepts user and Compute calls via API and stores their les in OpenStack Object Store by default.

3.5 Identity - Keystone The OpenStack Identity provides [6] an integration service for policy, catalog, token, and authentication in the OpenStack project. Identity handles API requests from other internal or external services and provides congurable catalog, policy, token, and identity services. For each sub-service provides Identity a backend to allow dierent uses of this sub-service. The widely used backends are LDAP, SQL, and Key Value Stores (KVS). The Identity project is mostly used for authentication of other OpenStack services. Some features [7] of OpenStack Identity:

I Provides information about user type. I Managing the access to other OpenStack services. The OpenStack Identity have a core sub-component which is:

3.5.1 keystone The keystone deals with [6] the API requests of other OpenStack services. The Identity project manages the authentication inside the OpenStack project using an API and provides several standard backends such as LDAP, SQL, or Key Value Stores.

3.6 Network - Quantum Network manages [6] the network connectivity within the OpenStack project. The Network service is needed and used by other OpenStack services and especially OpenStack Compute. The Network service is congurable because of the plug-in architecture. Some features [7] of Network:

I Network is exible to achieve dierent needs of applications. I Managing dierent IP addresses (static, dynamic, and oating). I Provides dening user networks. I Supporting extended network services such as Intrusion Detection Systems (IDS), rewalls, and VPNs. The main sub-components of the OpenStack Network are: 3 Components of OpenStack 26

3.6.1 quantum-server The quantum-server deals [6] with the API requests. It routes the API request to the correct plug-in.

3.6.2 plug-ins and agents The plug-ins and the agents in Network execute [6] the actual networking tasks such as porting, creating (sub)networks, and IP addressing). The common used agents in Network are layer 3 (Dynamic Host IP addressing. Network provides and manages the networking tasks in OpenStack. Network deals primarily with Compute to provide network resources to the VMS. The Network supports dierent plug-ins and agents for: Cisco virtual and physical switches, Nicira NVP, NEC OpenFlow, Open vSwitch, Linux bridging, and the Ryu Network Operating System.

3.7 Block Storage - Cinder Block Storage OpenStack project provides [6] storage (volume) as a service for the OpenStack Compute. In previous versions, this used to be done via nova- volume in Compute. Block Storage separates the block storage that was part of OpenStack Compute (nova-volume) into its own service. The API of Block Storage deals with requests for the manipulation of volumes or snapshots. Some of the features [7] of Block Storage:

I Integration with Compute I Performance with no central databasing

I Unlimited storage The main sub-components of OpenStack Block Storage are:

3.7.1 cinder-volume The cinder-volume executes, reads, and writes [6] operations to a database of Block Storage to update states of volumes or snapshots. The cinder-volume also interacts with some other processes (for example, cinder-scheduler) through a message queue just like other OpenStack services that interact with each other or with other sub-services of OpenStack. The cinder-volume supports other storage services (through drivers) such as IBM, SolidFire, NetApp, Nexenta, Zadara, linux iSCSI, etc.

3.7.2 cinder-api The cinder-api basically deals [6] with the API requests and delivers them to cinder-volume which executes them. 3 Components of OpenStack 27

3.7.3 cinder-scheduler The cinder-scheduler is a daemon that chooses [6] the optimal provider node on which to create the needed volume. The cinder-scheduler works like nova- scheduler (Compute) or OpenStack schedulers. The Block Storage OpenStack project mainly provides volume to VMS cre- ated by Compute and primarily interacts with it or with other services via an API. The Block Storage service supports other storage services via drivers such as IBM, SolidFire, NetApp, and many others.

3.8 Summary and Conclusion Cloud computing is getting more important for both research and production elds. As discussed in part one, cloud computing brings powerful features with it such as scalability, performance, and reduced upfront investments, especially the pay-as-you-go concept and the service-orientation trend. The six cloud computing resources mentioned in part one have been classied in three main layers: Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). The most used clouds currently are public and private clouds. As a combination of public and private clouds other clouds could be delivered by, for example, virtual private clouds. Because clouds are getting so important nowadays, the cloud management systems are also becoming important for their capability to manage and monitor the clouds. The second part of this report has previewed dierent cloud infrastructure management systems such as OpenNebula. These systems are associated to the IaaS layer in cloud computing as discussed in part one. OpenStack has been introduced in part two as an example of a cloud OS. The reason to choose OpenStack is the ef- fort behind the project to standardize the system in order to become the best cloud OS available, which basically is one of the OpenStack project goals next to simplicity and scalability as covered in part two. With eight releases between 2010 and 2013, OpenStack is actually achieving its goals with the support of a huge community of research, commercial, and open source organizations. After discussing the OpenStack project and its main goals, this report has introduced the core components of the system in a technical point of view starting with the description of the core components of OpenStack: Dashboard, Compute, Object Store, Image Store, Identity, Network, Block Storage and ending with naming the subcomponents of each of them and mentioning the main types of modules used in OpenStack which are: daemon, script, client, and CLI (Command Line Interpreter). The third part has also discussed the features of these components and how the components can work together. In the appendix, a Compute data model is presented as an example of the data structure used in building OpenStack. 3 Components of OpenStack 28

References

[1] Qi Zhang, Lu Cheng and Raouf Boutaba: Cloud Computing state of the art and research challanges (2010)

[2] Minqi Zhou, Rong Zhang, Dadan Zeng, Weining Qian: Services in the Cloud Computing Era-A Survey (2010) [3] Mahjoub, Mdhaar, Ben Halima, Jmaiel: A comparative study of the current Cloud Computing technologies and oers (2011)

[4] Dana Petcu: Invitation to Journey in the Era of Cloud Computing (2012) [5] Ken Pepple: Deploying OpenStack (2011) [6] ocial OpenStack documentaries and website [7] Atul Jha, Johnson D, Kiran Murari, Murthy Raju, Vivek Cherian, Yogesh Girikumar: OpenStack Beginner's Guide v3.0, 7 (2012) Appendix: Data Model of Compute database Model Field Type Attr Short Description Example Service id Integer PK Unique Id 1,2... host String running host name localhost binary String type of service nova-compute topic String AMQP topic name compute-host1 report_count Integer Not Null, Default 0 number of "report_state" called disabled Boolean Default False disable flag availability_zone String default nova service's zone nova ComputeNode id Integer PK Unique Id service_id Integer relation Service(disabled = false) Service reference Id vcpus Integer num of vcpu 4 memory_mb Integer memory size by mb 2048 local_gb Integer local disk size by gb 40 vcpus_used Integer num of used vcpu 2 memory_mb_used Integer size of used memory by mb 1024 local_gb_used Integer size of used local disk by gb 20 hypervisor_type Text name of hypervisor libvirt hypervisor_version Integer version of hypervisor. use for live 1 migration. if source/dest hypervisor version is not same, fail to migration cpu_info Text cpu details info represented as json # '{"arch":"x86_64", format # "model":"Nehalem", # "topology":{"sockets":1, "threads":2, "cores":3}, # "features":["tdtscp", "xtpr"]}' Certificate id Integer PK Unique Id user_id String certificate's user shida project_id String certificate's project dev project file_name String public key file name newcerts/inbound.pem Instance id Integer PK, Auto Increment Unique Id name String instance name i-XXXXXX, i-XXXXXX-rescure user_id String instance owner user shida project_id String instance owned project dev project image_ref String referenced image id ami-xxxxxxxx kernel_id String referenced kernel image id aki-xxxxxxxx ramdisk_id String referenced ramdisk image id ari-xxxxxxxx server_name String name represented OSAPI new-server-test launch_index Integer index of launch sequence key_name String keypair name mykey key_data Text public key fingerprint 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8 power_state Integer code of power state NOSTATE = 0x00 RUNNING = 0x01 BLOCKED = 0x02 PAUSED = 0x03 SHUTDOWN = 0x04 SHUTOFF = 0x05 CRASHED = 0x06 SUSPENDED = 0x07 FAILED = 0x08 BUILDING = 0x09

vm_state String value of vm state ACTIVE = 'active' BUILDING = 'building' REBUILDING = 'rebuilding' PAUSED = 'paused' SUSPENDED = 'suspended' RESCUED = 'rescued' DELETED = 'deleted' STOPPED = 'stopped' MIGRATING = 'migrating' RESIZING = 'resizing' ERROR = 'error'

task_state String value of instance task state SCHEDULING = 'scheduling' BLOCK_DEVICE_MAPPING = 'block_device_mapping' NETWORKING = 'networking' SPAWNING = 'spawning' IMAGE_SNAPSHOT = 'image_snapshot' IMAGE_BACKUP = 'image_backup' UPDATING_PASSWORD = 'updating_password' RESIZE_PREP = 'resize_prep' RESIZE_MIGRATING = 'resize_migrating' RESIZE_MIGRATED = 'resize_migrated' RESIZE_FINISH = 'resize_finish' RESIZE_REVERTING = 'resize_reverting' RESIZE_CONFIRMING = 'resize_confirming' RESIZE_VERIFY = 'resize_verify' REBUILDING = 'rebuilding' REBOOTING = 'rebooting' PAUSING = 'pausing' UNPAUSING = 'unpausing' SUSPENDING = 'suspending' RESUMING = 'resuming' RESCUING = 'rescuing' UNRESCUING = 'unrescuing' DELETING = 'deleting' STOPPING = 'stopping' STARTING = 'starting'

memory_mb Integer userd memory 1024 vcpus Integer used vcpu 2 local_gb Integer used local disk 20 hostname String running host name host String reference of ComputeNode instance_type_id Integer reference for InstanceTypes user_data Text instance user_data reservation_id String reservation id r-xxxxxx scheduled_at DateTime time of scheduled launched_at DateTime time of spawn instance terminated_at DateTime time of terminated availability_zone String running zone name nova display_name String User editable field for display in user- my first instance facing UIs display_description String User editable field for display in user- Django + MySQL facing UIs launched_on Text first launched host info compute1 locked Boolean instance lock flag. When server.lock api called this flag turn on os_type String Linux/Windows or others Linux architecture String x86/i386 vm_mode String mode of vms. para virtualization or pvhvhvm hardware virtualization uuid String universal unique id for live migration compute1-xxxxxxxx root_device_name String device name for EBS boot /dev/sda config_drive String values for vsa volume /dev/sdh access_ip_v4 String ip for connect to the instance 64.142.4.112 access_ip_v6 String ip for connect to the instance 2001:0DB8:AC10:FE01 VirtualStorageArra id Integer PK, Auto Increment y name String name of vsa vsa-xxxxxxxx display_name String display in user-facing UIs My vsa display_description String display in user-facing UIs used for database store project_id String vsa owned project name dev project availability_zone String vsa joined zone instance_type_id Integer reference for InstanceTypes image_ref String vc_count Integer default 0 vol_count Integer defaut 0 status String InstanceActions id Integer PK instance_id Integer FK Instance action String action name for OSAPI extension add_tweedle error Text error string InstanceTypes id Integer PK name String Unique memory_mb Integer vcpus Integer local_gb Integer flavorid Integer Unique swap Integer Not Null, default 0 swap size associate with flavor rxtx_quota Integer Not Null, default 0 It looks deprecate rxtx_cap Integer Not Null, default 0 capacity of virtual network as mbps 100 Volume id Integer PK, Auto Increment name String name of volume vol-xxxxxxxx user_id String shida project_id String dev_project snapshot_id String snapshot id which volume's source snap-xxxxxxxx host String host name of nova-volume localhost size Integer size of volume by gb 2 availability_zone String availability zone name nova instance_id Integer FK: volume attached instance id Instances.id(Volume.deleted=false) mountpoint String device name of attached /dev/sdh attach_time String time of attached status String status of volume in-useavailablecreatingdeletingerrorerror_deleteing attach_status String status of attach/dettach attacheddetached scheduled_at DateTime launched_at DateTime terminated_at DateTime display_name String display_description String provider_localtion String ISCSI provider location :, provider_auth String ISCSI provider authentication volume_type_id Integer reference for VolumeTypes VolumeMetadata id Integer PK key String meta data key value String meta data value volume_id Integer FK: Volume.volume_id VolumeTypes id Integer PK name String Unique VolumeTypeExtraS id Integer PK pecs key String extra spec key value String extra spec value volume_type_id Integer FK: VolumeTypes.id Quota id Integer PK project_id String Index quota for project resource String type of quota hard_limit Integer quota value SnapShot id Integer PK name String name of snapshot snap-xxxxxxxx volume_name String name of source volume vol-xxxxxxxx user_id String owned user id shida project_id String owned project id dev project volume_id Integer source volume id 1 status String snapshot status availableactivedeletingerror progress String snapshot creation progress 1 volume_size Integer size of source volume 10 display_name String display_description String BlockDeviceMappi id Integer PK, Auto Increment ng instance_id Integer FK: Instance.id device_name String device name /dev/sdb delete_on_termination Boolean default false flag of deletion volume when instance terminated snapshot_id Integer FK:Snapshots.id used for EBS booting volume_id Integer FK:Volume.id used for EBS booting volume_size Integer size of volume no_device Boolean flag of device exist or not ExportDevice id Integer PK shelf_id Integer composite key(blade_id) blade_id Integer composite key(shelf_id) volume_id Integer FK:Volumes.id IscsiTarget id Integer PK target_num Integer iscsi target number host String iscsi target host volume_id Integer FK: Volumes.id SecurityGroupInsta id Integer PK nceAssociation security_group_id Integer FK: SecurityGroups.id instance_id Integer FK:Instances.id SecurityGroups id Integer PK name String security group name description String security group description user_id String owned user id project_id String owned project id SecurityGroupIngr id Integer PK essRule parent_group_id Integer FK: SecurityGroups.id protocol String tcp/udp/icmp from_port Integer acceptance port to_port Integer acceptance port cidr String CIDR 0.0.0.0 group_id Integer FK: SecurityGroups.id SecurityGroup we're granting access for ProviderFirewallRu id Integer PK le protocol String tcp/udp/icmp from_port Integer acceptance port to_port Integer acceptance port cidr String CIDR 0.0.0.0 KeyPair id Integer name String keypair name user_id String owned user fingerprint String fingerprint public_key Text RSA public key Migration id Integer PK source_compute String source host name shida dest_compute String destination compute name shida2 dest_host String destination host name shida2 old_instance_type_id Integer reference for InstanceType new_instance_type_id Integer reference for InstanceType instance_uuid String FK:Instances.uuid status String migration status Network id Integer PK label String network name used for iptables chain project1-net1

injected Boolean default false cidr String Unique cidr_v6 String Unique multi_host Boolean default false gateway_v6 String netmask_v6 String netmask String bridge String bridge_interface String gateway String broadcast String dns1 String dns network definition when vps is on 192.168.0.1

dns2 String dns network definition when vps is on 192.168.0.1

vlan Integer vpn_public_address String vpn_public_port Integer vpn_private_address String dhcp_start String start address of dhcp 192.168.100.1 project_id String associated project dev project priority Integer network priority. append for Quantum

host String host name uuid String VirtualInterface id Integer PK address String Unique network_id Integer FK:Network.id instance_id Integer FK:Instances.id uuid String fixed_ipv6 String FixedIp id Integer PK address String ip address network_id Integer FK: Network.id virtual_interface_id Integer FK:VirtualInterface.id instance_id Integer FK:Instances.id allocated Boolean default: false virtual interface is set leased Boolean default: false dhcp bridge has leased the ip reserved Boolean default: false host String host name FloatingIp id Integer PK address String ip address fixed_ip_id Integer FK: FixedIp.id project_id String associated project host String host name auto_assigned Boolean default: false flag to associate ip when instance started AuthToken token_hash String PK user_id String request's user shida server_management_url String api server url http://localhost/services/Cloud

storage_url String Swift or other s3 service url https://cdn.swiftdrive.com/v1/CF_xer7_34 cdn_management_url String url of rackspace cdn https://cdn.swiftdrive.com/v1/CF_xer7_34 User id String PK shida name String user name Takahiro Shida access_key String user access key secert_key String user secret key is_admin Boolean flags for admin or not Project id String project id dev project name String project fully qualified name Project for development description String project description project_manager String owner of this project shida UserProjectRoleAs user_id String PK, FK:User.id shida sociation project_id String PK, FK:Project.id dev project role String PK admin UserRoleAssociati user_id String PK, FK:User.id on role String PK UserProjectAssoci user_id String PK, FK:User.id ation project_id String PK, FK:Project.id ConsolePool id Integer PK address String console accessible address username String password String console_type String public_host_name String host String compute_host String Console id Integer PK instance_name String name of instance instance_id Integer reference for Instances.id password String login password port Integer console opened port pool_id Integer FK: ConsolePool.id InstanceMetadata id Integer PK key String metadata key value String metadata value instance_id Integer FK:Instances.id InstanceTypeExtra id Integer PK Specs key String spec key value String spec value instance_id Integer FK:Instances.id Zone id Integer PK api_url String nova-api component's url username String user name of grant to access zone by using scheduler password String user name of grant to access zone by using scheduler weight_offset Float default: 0.0 scheduling weight weight_scale Float default: 1.0 scheduling weight AgentBuild id Integer PK Xen Agent mechanizum hypervisor String hypervisor name libvirt os String instance os name Ubuntu architecture String instance architecture type x86_64 version String url String md5hash String