System Integrations with OpenStack Architecture Based Clouds

System Integrations with OpenStack Architecture Based Clouds Jianwen Chen, George Africa, Chandra Aiyer, Rhonda Childress, Ron Gottschalk IBM Global S...
Author: Jade West
4 downloads 0 Views 1MB Size
System Integrations with OpenStack Architecture Based Clouds Jianwen Chen, George Africa, Chandra Aiyer, Rhonda Childress, Ron Gottschalk IBM Global Service 601 Pacific Highway, St. Leonards, NSW 2065, Australia [email protected], [email protected], [email protected], [email protected], [email protected] Abstract— In this paper, we study and propose the solution architectures to address a number key challenges to the system integrations with OpenStack architecture based clouds. We present the architecture designs and deployment models for enterprises to integrate OpenStack based cloud with VMware technology, Oracle Virtualization technology, public or private clouds that are not using OpenStack architecture, and to build and manage an OpenStack cloud across the enterprise data centers in different locations.

environment. A number of major challenges are in system integration area, such as how the enterprises should integrate their current virtualization environments with open stack architecture, how the enterprises can integrate OpenStack based cloud with other private or public clouds they are consuming, and how they can do cloud orchestration across hybrid clouds by using single dashboard and functional components of OpenStack architecture.

Keywords- System Integrations; OpenStack Architecture Integration; Cloud Computing; Deployment Model; Hybrid Clouds; Virtualization Technology; Pattern

In our paper, we will study these key challenges and present our solution architectures to address and resolve these challenges, specifically from system integration perspectives.

I.

INTRODUCTION

Cloud computing is an emerging area from both industrial and academic research sides. Cloud computing is a model for enabling ubiquitous, convenient, on-demand 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 [1]. In terms of deployment models, Cloud can be typically defined as Public Cloud, Private Cloud and Hybrid Cloud. OpenStack is a cutting-edge technology, it is a cloud operating system and also a management software that control large pools of compute nodes, storage, and networking resources throughout a datacenter, all managed through a dashboard that gives administrators control while empowering their users to provision resources through a web interface [1]. Today, OpenStack architecture has more and more formed the open standards of industry to manage and provide Infrastructure-as-a-Service (IaaS) in cloud systems [2][3]. The goal of OpenStack architecture is to produce the ubiquitous Open Source cloud computing platform that will meet the needs of public and private cloud providers regardless of size, by being simple to implement and massively scalable. Many commercial companies have announced the OpenStack architecture as their cloud strategy and released the commercial cloud systems and products that are based on OpenStack architecture. IBM, Ubuntu, Canonical, REDHAT, Rackspace, Microsoft, VMware, HP, AT&T, Cisco, NetApp have released their different types of OpenStack based products in the area of cloud platform, cloud management, network or storage [4][5][6][7]. However, nowadays there are a lot of challenges for enterprises to adopt OpenStack architecture providing cloud services in their real business

978-1-4799-5927-3/15/$31.00 ©2015 IEEE

Challenge 1: The first challenge we will study is how to bridge OpenStack architecture and VMware Technology [5]. OpenStack is for building IaaS private clouds, and VMware vSphere is the industry’s leading and reliable virtualization and cloud computing X86 based platform. In this paper, we will study and present a solution architecture that outlines how the enterprise can adopt OpenStack architecture based cloud while it already uses VMware technology in its business. Challenge 2: The second challenge we will study is integrating OpenStack architecture with Oracle virtualization technology. We will discuss how an enterprise can adopt open stack architecture and integrate with Oracle Virtual Machine (OVM) that maybe in use for its business. We will present a deployment model and a real case study of integrating an OpenStack system with OVM systems in a bank business. Challenge 3: The third challenge we will study is integrating an OpenStack based cloud with other public or private clouds that are using different architectures. We will present a solution architecture for an enterprise to build an OpenStack based private cloud and integrate with other clouds it is consuming, such as Amazon AWS or IBM SoftLayer. Challenge 4: The fourth challenge we will study is how to design, implement and manage an OpenStack based cloud across multiple data centers in different locations. In the last part of the paper, we will explore how cloud services can be provided beyond IaaS level by developing patterns using OpenStack Architecture.

II.

BRIDGING OPENSTACK ARCHITECTURE AND VMWARE TECHNOLOGY

OpenStack architecture is for building IaaS private clouds, and VMware vSphere is the industry’s leading platform in virtualization of X86 environments. How should the enterprise adopt and use an OpenStack based cloud if it has already adopted VMware technology in business? In this section, we present a solution architecture to enable enterprise users to build and use OpenStack as a cloud platform on top of a VMware technology and infrastructure. Before we present the solution architecture to bridge OpenStack architecture and VMware technology, let’s look at a high level overview of key functional components of OpenStack architecture in the latest OpenStack Icehouse release[1][4].

Within OpenStack architecture, the following components are responsible for managing compute, storage and networking resources in the virtual environment: • Horizon is Dashboard for management. • Nova is for Compute Nodes Service. • Cinder is for Block storage Service. • Swift is for Objective Storage Service. • Glance is for Image Management. • Neutron is for Network Service. • Keystone is for Identity Management. • Ceilometer is for billing service. These functional components work together to provide to provide IaaS cloud services. The following diagram presents our solution framework to integrate OpenStack architecture with VMware technology.

In this architecture model, OpenStack functional components work and integrate with VMware architecture components so OpenStack based cloud can be built up and implemented on top of VMware architecture components. Nova Compute Node integrates with vSphere, i.e. vCenter and ESX hypervisor. The vSphere presents itself as one type hypervisor to Nova Compute Node. OpenStack Neutron networking service integrates with VMware NSX Driver and Controller components to provide network service in environment. Cinder Block Volume Service, Swift Objective Storage Service and Glance Image Service integrate with vCenter Datastore and VMware VSAN storage to provide storage service for the management of volume storage and objective storage. VMware VSAN storage can process and handle rule based storage function request hence easily integrating with OpenStack Cinder storage architecture. Horizon Dashboard and Keystone are components integrate with all other components in OpenStack architecture to provide management dashboard and identity service across the whole cloud environment. By using the integration architecture above, an enterprise that has VMware technology in their business does not have to manage two virtualized environments – OpenStack based cloud and VMware virtualization environment. Instead, enterprise can manage VMware environment through the management stack of OpenStack cloud. Nova Compute Node can integrate with multiple type of hypervisors beyond VMware hypervisor such as Nova KVM and Nova Xen, hence OpenStack based cloud can provide more extensive integrations beyond VMware technology. OpenStack simplifies management of resources across heterogeneous hypervisors, enabling clients to switch hypervisors or run mixed environments easily. The following

diagram presents the OpenStack architecture integrating with different type hypervisors.

There is plenty of flexibility and variation on using the standard deployment model to deploy an OpenStack based cloud, and place the major deployment components to fit into the real business need.

III.

INTEGRATING OPENSTACK ARCHITECTURE WITH ORACLE VIRTUALIZATION TECHNOLOGY

In this section, we will discuss how an enterprise can adopt an OpenStack architecture and integrate with Oracle virtualization technology in use in its business. We present a deployment model in this section for deploying and integrating an OpenStack architecture with an Oracle Virtual Machine (OVM) environment, this architecture model has been used to deploy an OpenStack cloud and integrate with an OVM environment in a real bank business.

As presented in the architecture diagram below, we propose a 3 layer deployment model to deploy OpenStack architecture cloud in an oracle virtualization environment, and integrate it with Oracle virtualization technology. This deployment model has been used and adopted in a real bank business. We have used standard OpenStack deployment model and Oracle VM deployment model presented in [8] as the reference architecture.

The standard deployment model of OpenStack architecture has three major deployment components: • OpenStack Controller: it is a management stack that has Horizon, Keystone, Nova controller and Glance functional components reside on. It can be deployed as a cluster for high availability service if required. • Compute Nodes: These are compute components to be managed from controller. These compute nodes can be managed by different hypervisors supported by OpenStack architecture, it could be in same or different physical locations. • Storage component: These are storage components to be managed from controller. Storage type can be Cinder block volume storage or Swift objective storage. In this three layer deployment model, we propose an OpenStack controller centralization layer, an OpenStack

controller region layer and a managed Oracle virtualization environment. •

At centralization layer of OpenStack Controller, Horizon dashboard, Keystone identity management, and Ceilometer metering components are deployed in this layer as the management components of Oracle VM environments. This layer is located and implemented in a remote data centre. We deployed these components in a centralized layer in order to manage other virtualization environments beyond Oracle VMs.



The region layer of OpenStack Controller is implemented in a local data center. Nova API, Scheduler, Cert, Consoleauth, Novancproxy are deployed in this layer to control Nova OVM compute nodes. Glance API and Registration are deployed for image controlling. Cinder API, Scheduler and Volume are deployed to manage block volumes used by OVM compute nodes. My SQL and Msg Q are implemented for database and message communication between all components at this controller layer. We also deployed a number of Neutron components - Neutron Server, DHCP, Metadata, l3, and Orchestration Plugin to manage network connection over OVM virtualization environment.



Inside managed Oracle virtualization environment, we deployed Nova compute nodes on Oracle VM server. Oracle VM server use Xen Hypervisor, Dom0 is the control domain of Xen Hypervisor and is used to manage VMs in other domains. Nova Compute and Neutron vSwitch agent are deployed within Dom0. Libvirt is used for connecting Oracle VMs to OpenStack, Xen is fully supported by Libvirt driver. Open vSwitch and Libvirt are also deployed in Dom0 of Hypervisor .

OpenStack, using Neutron, presents a complete Software Defined Network (SDN) solution. Users can define isolated networks with any address space and connect between those networks with virtual routers. Users can define firewall rules without the need to touch or change any element of the physical network topology. Furthermore, there is a complete abstraction between the physical topology and the virtual networks so that multiple virtual networks can share the same physical resources without any security or address space concerns. In OpenStack, Neutron is supported with Open vSwitch. The management and virtual machine networks can share the same physical connection and be separated with VLANs. In our implementation in the bank business, we used Oracle VM Release 3.3, Oracle VM uses the latest hardware drivers and Open vSwitch in this release.

IV.

INTEGRATING OPENSTACK BASED CLOUD SYSTEM WITH OTHER CLOUDS

Nowadays, enterprises can have different private, public or hybrid clouds in their business. These clouds may or may not be built upon the OpenStack architecture. If an enterprise wants to build an OpenStack based private cloud, meanwhile it is the existing consumer of other public cloud services such as Amazon AWS or IBM SoftLayer, how can orchestration be executed across the hybrid cloud systems? In this section, we present a solution architecture to integrate an OpenStack based cloud with other clouds in different architectures.

In our proposed architecture above, we use OpenStack Horizon as a dashboard to manage cloud services in a hybrid cloud environment. In this model, each cloud is presented as one region of the OpenStack architecture based cloud. The region cloud can be a simple OpenStack region using KVM hypervisor, or an OpenStack region using VMware virtualization environment, or a Public Cloud Gateway region that having other clouds in different architectures underneath. We set up the public clouds that enterprising is consuming as an additional region of the OpenStack cloud, hence the enterprise can manage the hybrid clouds from the OpenStack dashboard through the Public Cloud Gateway (PCG). The following diagram presents the functional components of a Public Cloud Gateway to connect an OpenStack cloud to clouds in other architectures. Nova API and Glance API are two fundamental REST APIs developed to communicate and manage computes and images of public clouds. Common Service Broker (CSB) is another component of PCG, it ccommunicates with other public clouds directly. The Common Service Broker can be developed using AWS SDK. Nova API and

Glance API interact with CSB through the internal interface of PCG.

V.

INTEGRATING WITH DATA CENTERS IN DIFFERENT LOCATIONS

In a real business environment, an enterprise can have multiple data centers that are in different locations. In this section, we will discuss how an OpenStack based cloud can be built across different data centers and locations and how to build and configure a centralized management across different data centers. We will present a deployment model of OpenStack architecture for use to integrate different data centers and locations. In the architecture diagram below, we propose and illustrate how the components of OpenStack controller can be deployed at different remote and regional data centers, and work together to mange compute and storage nodes in OpenStack cloud. To address the real business needs, the managed virtualization environments can locate in different data centers and use different virtualization technologies such as VMWare and OVM under our model.

In our solution architecture, we deploy Horizon, Keystone, Ceilometer and Heat components in a remote data center to form a centralization layer of OpenStack Controller that manages all regions of an OpenStack cloud. These components will provide dashboard, identity, billing and metering, and pattern management to orchestrate the whole OpenStack private cloud. In this architecture, Netron, Glance, Nova Cinder, MySQL server and Msg Q are deployed in local data center of each region as the OpenStack Region Controller to manage nodes in each region. The following sub-components are essential deployment components for each region controller. • Neutron Server, Neutron DHCP, Neutron Metadata, Neutron l3, Neutron Orchestration Plugin to provide network management. • Nova API, Nova Scheduler, Nova Cert, Nova Consoleauth, Nova Novancproxy to provide nodes management. • Cinder API, Cinder Scheduler and Cinder Volume to provide storage management. • Glance API and Glance Registration to provide image management. • MySQL server to hold OpenStack data and Msg Q to provide internal message communication. In each managed virtualization environment, we deployed the following OpenStack sub-components: • Neutron Open vSwitch agent, Neutron Metadata agent, Neutron DHCP agent, Neutron Plugin agent, and Neutron l3 agent are deployed to enable the network management at nodes level. • Nova Compute to enable and communicate with compute nodes. • In a VMware virtualization environment, VMware NSX Driver/Controller is used for network communication with Neutron sub-components and network connection to VMWare Hypervisor. • In an Oracle virtualization environment, Libvirt is used for network communication with Neutron subcomponents and network connection to Xen Hypervisor. OpenStack provides a Software Defined Network architecture, hence it is very flexible and dynamic to provide and configure multi-tier networks across multiple data centres. The following diagram presents a multi-tier network topology can be used in the multiple data centre scenario.

By using Heat component and template, pattern can be developed and managed to provide automation, standardization, and life cycle management at IaaS level. It can be further integrated and leveraged to manage database and middleware to provide Platform-as-a-Service level cloud service as the result of further development in future.

VII. CONCLUSIONS

VI.

DEVELOP AND MANAGE PATTERN USING OPENSTACK ARCHITECTURE

Patterns can provide benefits to enterprises by delivering standardization, simplicity, speed and expertise. Topology and Orchestration Specification for Cloud Applications (TOSCA) [9] is a standard [10][11] to describe cloud services, the relationships between components of the service, and the operational behavior of the services. Hence, TOSCA has formed a standard to develop patterns in cloud environments. OpenStack architecture has defined a similar standard for specifying resources and the orchestrations for managing infrastructure and application lifecycles. OpenStack Heat is the template-driven engine in OpenStack that allows application developers to describe and automate the deployment of infrastructure. Heat uses a flexible template language that can specify compute, storage, and networking configurations as well as detailed post-deployment activity to automate the full provisioning of infrastructure as well as services and applications [1][2][3][4].

In this paper, we study and propose the solution architectures to address a number of major challenges to integrating an OpenStack architecture based cloud with other virtualization technologies and other clouds in different architectures. We also present a few deployment models that have been used in the real business of enterprises to integrate and manage VMware virtualization environment, Oracle virtualization environment, AWS or SoftLyer cloud systems in a OpenStack architecture, and build an OpenStack cloud across the enterprise data centers in different locations. REFERENCES [1] OpenStack, www.openstack.org [2] Open Source, Initiative.opensource.org [3]Stackalytics, www.stackalytics.com/. [4] Jacek Artymiak and Lisa-Marie Namphy, “Open Stack Technology Breaking the Enterprise Barrier”, HP Press. [5] “Operational Model SCO on VMWare,” IBM Redbook. [6] “IBM SCO User Guide V2.3”, IBM Redbook. [7]Ubuntu, “OpenStack Juju Documentation”, https://juju.ubuntu.com/docs/config-openstack.html [8] “Getting Started with Oracle VM, Oracle Linux and OpenStack”, an Oracle White Paper, August, 2014. [9]TOSCA Specification, “Version 1.0, Committee Specification 01, 18 March November 2013”, http://docs.oasis-open.org/tosca/TOSCA/v1.0/cs01/TOSCA-v1.0-cs01.pdf. [10] "Intellectual Property Rights (IPR) Policy | OASIS", OASIS. [11] Sheriff, Lucy (23 February 2005). "OASIS open standards not open enough · The Register".