Professional Documents
Culture Documents
003 VMWare Whitepaper Screen
003 VMWare Whitepaper Screen
March 2014
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.
01 09
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.
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 2013. 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
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. M
aintain 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. R
un 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. D
eploy 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.
OpenStack Havana: The open source software for building private and public clouds
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.
03 09
VMware vSphere Design
OVERVIEW
OPENSTACK DESIGN
Horizon
CLI
Dashboard
Region One
AZ1
AZ2
OpenStack Cloud
04 09
Logical Ubuntu Cloud on vSphere Design
Networks
Instances Instances
(vSphere VMs) (vSphere VMs)
Nova Cloud Controller
Keystone Nova
MAAS Cinder API Compute
Glance API VM
OpenStack Dashboard Cluster 1
Ceph Rados Gateway
Nova
Compute
JuJu MySQL VM
Nagios RabbitMQ Management Network
Ceph Cluster 1
Nodes (x3)
VM Network
Virtual Networks
Design Notes:
• A floating network (not shown) is optional
•E ach 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
•T his 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
•A s 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)
•O penStack services shown in the Management Cluster can be distributed
to other clusters depending on resource availability (not shown)
05 09
VMWARE ESXI HYPERVISORS
VM Attribute Specification
Number of CPUs 2
Memory 4 GB
Disk 1 20 GB
Disk 2 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:
VMWare Management Only for vSphere, not related to the OpenStack infrastructure
MAAS dynamically manages DHCP and DNS for all the OpenStack nodes using
the Management Network.
The MAAS node will also provide the Ubuntu Precise 12.04 LTS base images
to the VMs in the Ubuntu Cloud via PXE boot through the same network.
06 09
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.
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:
•T
he vSphere datastores used for the instances should not be used for any
other purpose
•D
isconnect any other datastore from the ESXi hosts not to be used for the
instances: http://docs.openstack.org/havana/config-reference/content/
vmware.html
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.
Ceph RADOS Gateway will frontend the stored images and OpenStack Glance
will point to it.
07 09
VM Specification
VM Attribute Specification
Number of CPUs 2
Memory 4 GB
Disk 1 20 GB
Disk 2 20 GB
VM IMAGE STORAGE
08 09
CONCLUSION
09 09
© Canonical Limited 2014. 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.