Ubuntu OpenStack on VMware vsphere: A reference architecture for deploying OpenStack while limiting changes to existing infrastructure

Transcription

1 TECHNICAL WHITE PAPER Ubuntu OpenStack on VMware vsphere: A reference architecture for deploying OpenStack while limiting changes to existing infrastructure A collaboration between Canonical and VMware March 2014 Copyright Canonical

2 Summary Canonical, the Ubuntu and OpenStack experts, and VMware, the virtualization experts, have combined their collective experience in customer facing deployments. The team has built a series of reference architectures to help customers explore the benefits of OpenStack within their data centers. The reference architecture in this paper is intended for organizations with existing VMware data center deployments or expertise who want to limit changes to their underlying VMware infrastructure, but see benefits in a common abstraction and orchestration layer via OpenStack open APIs and Dashboard to control compute workloads

3 UBUNTU OPENSTACK PLUS VMWARE A PERFECT MATCH IN THE EVOLUTION OF THE DATA CENTER Organizations strive for increased operational efficiency and agility within their data centers which is why the old methodology of a single server per application evolved into server virtualization. This technology helped reduce data center hardware sprawl by consolidating multiple workloads per server resulting in higher hardware utilization. Prior to virtualization, the procurement, racking, stacking, provisioning, and networking of hardware generated overhead and took time. VMware quickly established itself as the leader in this space with a range of solutions to suit different organizations needs. As the server virtualization footprint grew, organizations began to segregate and tailor deployments to various hypervisor stacks depending on cost, test and development workloads versus production deployments, compliance, etc. This led to virtual machine (VM) sprawl and it became difficult to manage and scale applications running across the different hypervisors, servers, brands, etc. The advent of cloud computing, especially private clouds, promised to alleviate this problem by creating a coherent environment that is easier to manage and scale. The OpenStack project is one of the prime examples in this area. OpenStack is an open source computing platform for public and private clouds. It is one of the largest and fastest growing open source projects to date. OpenStack takes a set of heterogenous and isolated hypervisors (i.e. KVM, ESXi, Xen, LXC), storage and networks across a data center or multiple data centers and turns them into pools of resources. All managed and consumed via open APIs and a web-based dashboard. Ubuntu quickly established itself as the reference platform to develop and deploy OpenStack. And Canonical, the commercial sponsor of Ubuntu and platinum member of the OpenStack project, became the leader in helping organizations adopt and deploy Ubuntu OpenStack as their public or private cloud technology. VMware joined the OpenStack project as a gold member in 2012 and announced a collaborative partnership with Canonical in The goal of this partnership was to aid organizations in their adoption of OpenStack, especially in combining it with their existing VMware infrastructure. OpenStack as a control layer above pools of resources in the data center has benefits; however, organizations have heavy investments both financially and in staff technical competency with established VMware technologies, so how can they reap the benefits of a next generation cloud platform in OpenStack, while still getting the best out of their existing VMware hypervisor base? What s the best approach to educate their staff on OpenStack? OpenStack APIs allow users to customize and configure down to the network level and VMware NSX is one of the most advanced and feature rich SDN solutions available today working seamlessly with OpenStack, ESXi and KVM, but how can this be done without major disruptions? What changes are needed to applications to achieve an open cloud using multiple hypervisors i.e. KVM for web tier apps and VMware ESXi for more heavyweight backend applications? 02 09

4 Given the above pressures and scenarios organizations face in their adoption of OpenStack, VMware and Canonical created a collection of OpenStack migration best practices based on our experiences together in the field. A high-level overview of OpenStack migration options is given below, from the least to most invasive : 1. Maintain the existing VMware vcenter technology stack and deploy OpenStack services as VMs running on top of VMware s ESXi hypervisor. To minimize changes to the established VMware infrastructure even further, deploy OpenStack nova-network rather than OpenStack Neutron with an SDN. This allows organizations to familiarize and educate themselves on OpenStack (APIs) while maintaining a consistent and known infrastructure. This environment is for proof of concept only. 2. Run OpenStack control services as hosts within VMware vcenter, but offer OpenStack compute options on multiple hypervisors, e.g. KVM and ESXi. Implement VMware NSX as the SDN for a richer network topology. Use OpenStack regions or host aggregates to allow users the choose which compute hypervisor to deploy their workload on. In this approach, developers learn to make their workloads/applications hypervisor-agnostic by moving from failover to fault resistant cloud oriented designs. The data center infrastructure changes are minimally invasive. 3. Deploy OpenStack control services on bare-metal hardware or on an open source hypervisor such as KVM. Allow for multiple hypervisors (KVM, VMware ESXi, Xen, etc.) for OpenStack compute services and run VMware NSX as the SDN solution. This design encourages vendor diversity within the data center and turns a heterogeneous set of hypervisors, storage and network options into pools of resources available and configured on-demand. In the next sections, we will outline the reference architecture specific to migration option number one. This migration option contains our recommended configuration, design, and implementation path matching real-world deployments KEY ELEMENTS OF REFERENCE ARCHITECTURE OpenStack Havana: The open source software for building private and public clouds Ubuntu Long-term Support: The reference operating system for OpenStack deployments and development VMware vcenter version 5.1 or greater: The platform for managing VMware vsphere environments INTENDED AUDIENCE This paper assumes the reader is experienced with VMware vcenter and Ubuntu. The reader should be familiar with OpenStack services (Compute, Keystone, etc.) along with techniques to scale and segregate an OpenStack deployment

5 VMware vsphere Design OVERVIEW The OpenStack components are installed as Virtual Machines in a vsphere Cluster. This approach provides the following benefits: High availability via vsphere HA Better use of the hardware Flexibility to scale up and scale out easily as required Flexibility to adjust the specifications of each component ( RAM, Disk, vcpu, etc. ) Faster deployment times OPENSTACK DESIGN Logical Ubuntu Openstack Cloud Design CLI Horizon Dashboard Auth & API Region One AZ1 AZ2 OpenStack Cloud 04 09

6 Logical Ubuntu Cloud on vsphere Design Networks Management Cluster (vsphere) Virtual Networks VM Cluster 1 (vsphere) VM Cluster N (vsphere) MAAS Nova Cloud Controller Keystone Cinder API Glance API OpenStack Dashboard Ceph Rados Gateway Nova Compute VM Cluster 1 Instances (vsphere VMs) Instances (vsphere VMs) JuJu Ceph Nodes (x3) Nagios MySQL RabbitMQ Nova Compute VM Cluster 1 Management Network VM Network Virtual Networks Design Notes: A floating network (not shown) is optional Each vsphere cluster is associated with a nova-compute. One cannot map multiple clusters to the same nova-compute, otherwise the clusters would get merged to look like a single hypervisor thereby removing the option of having clusters in different OpenStack availability zones This setup allows for one nova service and one nova.conf for both clusters and each is represented as a separate nova-compute hypervisor instance to the OpenStack Nova scheduler As of this writing, using one nova.conf for both clusters is not recommended since there is no established method to define clusters into individual OpenStack availability zones. OpenStack component HA is achieved via Juju and Metal-as-a-Service (MAAS) OpenStack services shown in the Management Cluster can be distributed to other clusters depending on resource availability (not shown) 05 09

7 VMWARE ESXI HYPERVISORS VM Attribute Number of CPUs Memory Number of vnic ports Disk 1 Disk 2 Specification 2 4 GB 1 (Management network) 20 GB 20 GB Network OVERVIEW Virtual networks exist to attach the VMs vnics to the right physical networks. These are the vsphere networks for the environment: vsphere Network Management VM Network VMWare Management Description Network for the Ubuntu Cloud components: SSH traffic to access Ubuntu Cloud Components Internal Traffic between Ubuntu Cloud Components PXE booting iscsi Ceph Storage Ceph Object Storage Flat network for the OpenStack instances traffic Only for vsphere, not related to the OpenStack infrastructure In this design, OpenStack Havana is implemented with nova-network. OpenStack Neutron plus VMware NSX would be a recommended next step, but was not selected in this design. DHCP AND DNS FOR THE OPENSTACK COMPONENTS MAAS dynamically manages DHCP and DNS for all the OpenStack nodes using the Management Network. The MAAS node will also provide the Ubuntu Precise LTS base images to the VMs in the Ubuntu Cloud via PXE boot through the same network

8 MANAGEMENT NETWORK ISOLATION This design consists of one main network called the Management Network. Depending on your network configuration, you can connect a cloud portal or clients to this network to access the OpenStack APIs from other networks via routing. For security reasons this network should be isolated and only accessible from trusted services like a portal or a management client machine. Because this design is entirely on top of VMware vsphere running novanetwork, OpenStack security groups are not available. As of this writing, OpenStack compute security group functionality is only achievable on vsphere when used in combination with VMware NSX SDN solution. Storage Each availability zone should have a Tier 2 SAN with sufficient resources for the planned workload available to be distributed via vsphere datastores to each vsphere cluster. Notes: The vsphere datastores used for the instances should not be used for any other purpose Disconnect any other datastore from the ESXi hosts not to be used for the instances: vmware.html OPENSTACK INSTANCES STORAGE The OpenStack Instances are stored in a dedicated vsphere datastore. BLOCK STORAGE WITH CINDER USING THE VMWARE DRIVER OpenStack Cinder is handled using the VMware driver released with OpenStack Havana. Note: The current Cinder Juju Charm needs manual configuration after deployment to set up the VMware driver. OBJECT STORAGE WITH CEPH RADOS GATEWAY A minimal configuration of Object Storage is needed to deploy OpenStack instances via Juju. For that purpose Ceph RADOS Gateway will be deployed with a default configuration in 3 VMs. Ceph RADOS Gateway will frontend the stored images and OpenStack Glance will point to it

9 VM Specification The recommended specs for the Ceph VMs: VM Attribute Number of CPUs Memory Number of vnic ports Disk 1 Disk 2 Specification 2 4 GB 1 (Management network) 20 GB 20 GB VM IMAGE STORAGE The storage of the VM templates (images) is handled by the OpenStack Glance. Glance provides multi-tenant image storage services for an OpenStack deployment. In this design, to maximise availability of the images, Object Storage with Ceph RADOS Gateway will be used

10 CONCLUSION This OpenStack reference architecture provides a common abstraction and orchestration layer via OpenStack open APIs and Dashboard to control compute workloads while limiting changes to pre-existing VMware infrastructure. This approach allows organizations to extend the ROI of their infrastructure investment while developing and enhancing employees skills around a next generation platform in OpenStack. The cost saving extends further as teams understand the OpenStack paradigm enough to determine which workloads/ applications should remain legacy and which ones be upgraded to cloud centric fault tolerant designs early in the infrastructure migration process. About Canonical and Ubuntu OpenStack Leading enterprises depend on Canonical to assist, guide and support them in making the most of their OpenStack-based production cloud offerings. Based on our experience of helping seven of the top 10 telcos and service providers, as well as numerous large organizations deploy production clouds, we have created tightly integrated cloud technologies that minimise deployment risk and speed time to market. Ubuntu OpenStack pre-integrates all the infrastructure, software, tools and services that companies need to achieve cloud success. With a tried-and-tested reference architecture and deployment methodology, we can help enterprises deploy clouds faster, and ensure that cloud services meet user requirements for performance and availability. As an integrated element of the Ubuntu OpenStack proposition, Canonical supports every stage of cloud deployment, from design and implementation, to ongoing technical support. We provide companies with an efficient, production ready and cost effective route to the open-source cloud. For more information, and to get in touch, please visit:

11 Canonical Limited Ubuntu, Kubuntu, Canonical and their associated logos are the registered trademarks of Canonical Limited. All other trademarks are the properties of their respective owners. Any information referred to in this document may change without notice and Canonical will not be held responsible for any such changes. Canonical Limited, Registered in England and Wales, Company number C Registered Office: One Circular Road, Douglas, Isle of Man IM1 1SB VAT Registration: GB