Guide to successful OpenStack

adoption and deployment

April 2020

Introduction
OpenStack is an essential component of every modern organisation which
uses private cloud for DevOps agility and flexibility. Over the last few years it
has evolved and become a de-facto standard for implementing cloud
computing platforms. It is one of the three most active open source projects in
the world with 1,125 developers from 165 organisations involved in the Train
release development [1]. According to 451 Research’s Market Monitor (Open
Source Software, OpenStack) from September 2019, its combined market size
worldwide is $7.7B.

At Canonical, we’ve seen hundreds of successful OpenStack deployments for

various customers across different market sectors. However, OpenStack is
complex and many organisations have tried and failed. Therefore, is the problem
OpenStack itself or adoption and implementation of OpenStack?

In this whitepaper, we demonstrate how organisations can benefit from a

successful OpenStack deployment when using the right adoption process and
tooling, broken down into the following five phases: design, model, deploy,
operate and transfer.

[1]
https://www.openstack.org/videos/summits/shanghai-2019/global-collaboration-driving-innovation-in-a-multi-billion-dollar-market
 Challenges with OpenStack adoption
The following challenges are typically faced with OpenStack adoptions
by organisations:

• Lack of resources - OpenStack is a large ecosystem system and can grow very
fast. Usually a dedicated team is required to maintain it. This may be a blocker
for small and mid-size organisations, pushing them towards public clouds which
are often more costly and may not meet necessary security requirements.

• Lack of knowledge - Where to start the journey? Which distribution to use?

There are dozens of questions that have to be answered before the deployment
even starts. This lack of specialist knowledge may slow down the decision
making process, result in vendor lock-in and subsequent re-work post
deployment. Long term, an organisation may not be able to upgrade as quickly
as they would like, suffer inflated total cost of ownership (TCO) or not be able
to scale their architecture.

• Lack of experience - Even a knowledgeable and properly trained team can

struggle from a lack of OpenStack experience. Bad decisions made at the
beginning will result with a lot of rework during the later phases. Lack of
experience may result in selecting non-scalable architectures and bad
hardware choices.

• Security concerns - As OpenStack is a complex ecosystem, security has to be

addressed at various layers. While we do not recommend leaving your
OpenStack insecure, over-engineering may kill the project. It is important to
find the right balance.

• Ineffective tools - While traditional configuration management tools like Bash

scripts and Ansible playbooks are suitable for small deployments, they do not
scale and can quickly become ineffective. Canonical’s Charmed OpenStack uses
Juju charms to ensure that your OpenStack is deployable, maintainable and
upgradable.

• Ongoing operations - potential challenges don’t stop once the OpenStack cloud
is deployed. Consideration needs to be given to the ongoing operations and
upgrades which can become complex and fragile. If an organisation has selected
a vendor whose support has ceased or they don’t have the internal knowledge,
then effective management of the Openstack can be at risk.

At Canonical, we’ve deployed OpenStack hundreds of times. This experience has

resulted in the design of a process and tools which significantly accelerate and
simplify the entire process.

2
 OpenStack adoption process
A successful OpenStack adoption is a process which usually follows five phases:
design, model, deploy, operate and transfer. Read the following sections to learn
about the challenges faced during each phase and how Canonical’s Charmed
OpenStack helps to overcome them.

1. Design

The OpenStack adoption process starts with answering very basic questions.
What to build? Which reference architecture to use? From which vendors to
purchase hardware? Which hypervisor and SDN solution to choose? And last, but
not least, what about the security? All of those questions have to be answered
before the actual work starts.

This is a serious blocker if there are no people in the organisation who are
knowledgeable and experienced enough to make those decisions. It is very
common that bad decisions at the beginning of the process results in an extreme
amount of rework post-deployment. In addition, the wrong selection of hardware
can lead to costly replacements.

Therefore, the adoption process should always start with the design phase.
During this phase, the requirements are gathered and get transitioned into
deliverables based on the input from analytics and architects. At the end of the
phase, it is clear what is going to be built, when and with associated costs.

In order to help with the design phase, Canonical offers a consulting option. It is
available under the Private Cloud Build (PCB) package and includes a two-week
delivery of OpenStack on-site. PCB comes with a reference hyper-converged
architecture, which can be customised to the organisation’s requirements, and is a
result of years of experience with OpenStack deployments and operations. As
Canonical excels in real production environments, at least 12 nodes are required
to start. Moreover, PCB includes certified hardware options from various vendors
which avoids the headache of testing and integration.

3
 What is Private Cloud Build?
Private Cloud Build (PCB) is a package which includes OpenStack delivery within two weeks based on a
reference architecture, certified hardware options and a toolset which consists of the following components:
• MAAS for bare-metal machines provisioning,
• Juju for OpenStack services modelling,
• OpenStack Charms for OpenStack services deployment and operations,
• sets of scripts for MAAS and Juju installation, and configuration.

Using PCB leverages the Infrastructure-as-Code (IaC) approach, making the deployments repeatable and
drastically reduces the time required to deploy OpenStack.
PCB uses hyper-converged architecture which means that all nodes in the cloud are equal. All provide
compute, network and storage resources, while OpenStack control services get deployed in high availability
(HA) mode and are scattered across the cluster. LXD containers are used to provide isolation between the
control plane and the data plane. Using a hyper-converged architecture allows the use of the same hardware
across the entire cluster, maximises hardware usage and simplifies scale-out operations. All of those result in
reduced operational costs.
Canonical also offers the PCB Plus package which includes on-site workshops as an additional service. During
those workshops, an optimal, customised design is prepared. A bunch of add-ons are available too. Those
include custom SDN solutions, storage options or integration with third-party tools. Once the design is
approved, Canonical provides on-site delivery.
Refer to Table 1 in Appendix for more information on PCB features and pricing.

Security is an important aspect of every cloud environment. Canonical uses

Ubuntu Server LTS (Long Term Support) as a base for all OpenStack deployments.
Due to the usage of the latest Linux kernel and availability of the Kernel Livepatch
Service, Ubuntu is considered one of the most secure Linux distributions. An
additional layer of security is introduced by isolating the control plane from the
data plane by packaging OpenStack control services in LXD containers. Finally,
OpenStack services can be deployed with hardening turned on by default which
allows you to benefit from years of security best practices.

2. Model

Typically, the design phase is followed directly by the deploy phase. Although the
model phase brings its own benefits, it is usually considered a waste of time by
organisations. This is because there are no tools which could translate the model
into a real implementation. But what if such tools did exist?

Canonical uses Juju as the application modelling tool. Juju allows users to define
a model of the OpenStack deployment in the form of a YAML (YAML Ain’t Markup
Language) file. This model usually includes the following information:

• number of machines being deployed with their hardware specification,

• applications being deployed and their configuration,
• number of application units being deployed and placement of the units,
• relations between the applications.

4
 The YAML file with model definition is called a Juju bundle. The bundle can later
be used to deploy OpenStack based on the defined model. Parts of the
OpenStack Base bundle can be found below:

machines:
‘0’:
series: bionic
‘1’:
series: bionic
…
services:
neutron-gateway:
charm: cs:neutron-gateway-275
num_units: 1
options:
bridge-mappings: physnet1:br-ex
data-port: br-ex:eno2
openstack-origin: cloud:bionic-train
to:
- ‘0’
neutron-api:
charm: cs:neutron-api-281
num_units: 1
options:
flat-network-providers: physnet1
neutron-security-groups: true
openstack-origin: cloud:bionic-train
to:
- lxd:1
...
relations:
- - neutron-gateway:neutron-plugin-api
- neutron-api:neutron-plugin-api
...

But how does it all work? The simplicity comes from the charms. Charms abstract
operational complexity in a form of primitives. They are collections of scripts and
metadata which contain the entire logic required to install, configure, connect
and manage applications. During the deploy phase, Juju places charms on the
machines hosting application units and orchestrates the execution of primitives
exposed by the charms. As a result, the whole OpenStack installation and
configuration process gets automated and the model created during this phase
gets materialised.

Although the idea is great, creating a Juju bundle that deploys OpenStack
according to the pre-defined design can also be challenging. However, Canonical
maintains basic OpenStack bundles which can be customised according to
requirements. The PCB package includes bundle creation according to the agreed
specification. Once created you can deploy your cloud, destroy it and deploy it
again as many times as you want. The process is fully repeatable and reusable.

5
 3. Deploy

Even if properly designed and modelled, a manual OpenStack installation and

configuration is complex and can take weeks. This is because OpenStack consists
of various inter-connected components which have to be carefully configured to
work together.

Obviously, there are various tools which allow automated OpenStack installation
in a single-node or even in multi-node scenarios. But what if your OpenStack
model is not trivial? What if you require an integration with an extraordinary SDN
solution or a non-default storage system? And what if your OpenStack model is
really big? This is where the complexity starts growing exponentially and raises
the need for abstraction.

But before you can even install a single package, the underlying infrastructure has
to be prepared. As OpenStack usually runs on bare-metal, physical hardware and
network equipment has to be installed and configured first. Adopting a reference
architecture can accelerate this process. Once all machines are racked and cabled,
the entire cloud can be deployed in less than an hour. This is where PCB with
MAAS, Juju and OpenStack charms comes in again.

Juju can transform a model into a real deployment by

What is MAAS?
Metal-As-A-Service (MAAS) is an infrastructure
provisioning tool which can be used to
provision bare-metal, virtual and container
machines on demand. It allows fully automated
installations of Ubuntu, CentOS, RHEL, ESXi
and Windows on real servers, turning the data
centre into a bare-metal cloud. Apart from its
provisioning capabilities, MAAS provides
features like network discovery, machine
inventory, hardware testing and more.
using the concept of charms which expose primitives for
performing various operational tasks. Charms are placed
by Juju on machines being deployed. The execution of
primitives is later orchestrated by Juju to make sure that
they are executed in the proper order. The primitives (aka
charm’s hooks and actions) define the exact steps required
to perform certain actions. For example, they contain all
necessary information required to install OpenStack
Keystone units, scale the application up and connect it to
a database. As a result the whole OpenStack installation
and configuration process gets abstracted. What is
defined in the model, gets deployed in the environment.

Where do the machines come from though? Those are provided by MAAS. Since
OpenStack is usually deployed on bare-metal, MAAS turns those machines on,
installs Ubuntu LTS on them, performs an initial network and storage
configuration, creates KVM virtual machines and LXD containers, if required, and
transfers access rights to Juju, so that it can start placing charms on them.

This is a big step forward - being able to provision bare-metal on demand.

However, the MAAS and Juju environment has to exist on its own before. Physical
machines have to be registered to MAAS prior to being provisioned. There can be
hundreds of them, again. PCB solves this problem by providing a set of scripts for
MAAS and Juju installation, and configuration. The entire infrastructure gets
defined in a bunch of YAML files allowing to benefit from the IaC approach and to
kick-off the entire OpenStack installation from three manually installed machines
with Ubuntu Server LTS.

6
 4. Operate

A successful deployment is just the first step towards an OpenStack private cloud.
After the initial success, best practice is to re-deploy to make sure that the entire
process is fully repeatable. This shouldn’t be a problem if the deploy phase was
handled properly. But after that, organisations cannot wait further and have to
start onboarding tenants. There is no more time for de-deployments. And this is
when the biggest challenges are usually faced.

Day-2 comes in. It turns out that the requirements were not initially gathered
carefully and the cluster is quickly running out of capacity. Fortunately, there are
some spare nodes which can be borrowed, but how quickly can they be made part
of the cluster? Can the OpenStack scale-out on demand? Even though it is a
perfect example, scaling out the cluster is just the beginning of the journey with
OpenStack operations.

Day-500 comes in. After one and half years of operating the OpenStack cloud, it
is needed to upgrade it to the latest stable version. Although the entire process is
fully supported by the upstream, it is so complex and fragile that most of the
OpenStack vendors made a decision not to support it. Instead, they have been
encouraging their customers to re-deploy. But if you are operating a production
cloud you cannot just re-deploy. Deploying a new cloud and migrating the
workloads is a burdensome and time-consuming process.

OpenStack operations are hard. The entire ecosystem is very complex. But what if
all of those complex operations could be automated? Juju goes beyond the initial
deployment. It also provides service orchestration capabilities which means that
complex operations such as scaling out the cluster, relocating application units or
database recovery can be fully automated. Again, the simplicity comes from the
charms which expose those complex operational tasks in a form of primitives. By
committing to an ongoing development and maintenance of the OpenStack
Charms, Canonical has been the only OpenStack vendor which supports
OpenStack upgrades on the live environments.

In order to allow customers to plan the upgrade process in advance, Canonical’s

Charmed OpenStack provides a very clear release cadence and upgrade path.
Every six months an interim release of Charmed OpenStack becomes available. It
is supported by Canonical for eighteen months. Moreover, every two years an
LTS release comes in which is supported for five years. Charmed OpenStack
releases are usually tied to Ubuntu releases. Upgrades between consecutive
releases are fully supported. Charmed OpenStack release cadence is depicted on
the figure below:

7
 OpenStack U LTS
Ubuntu 20.04 LTS
OpenStack U
OpenStack Train
OpenStack Stein
OpenStack Rocky
OpenStack Queens LTS
Ubuntu 18.04 LTS
OpenStack Queens
OpenStack Pike
OpenStack Ocata
OpenStack Newton
OpenStack Mitaka LTS
Ubuntu 16.04 LTS
OpenStack Mitaka
OpenStack Kilo
OpenStack Icehouse LTS
Ubuntu 14.04 LTS
OpenStack Icehouse

2014 2015 2016 2017 2018 2019 2020 2021 2022 2023

Ubuntu LTS release support Matching OpenStacK release support Extended support for customers

Source: https://ubuntu.com/about/release-cycle

But OpenStack operations is just one thing. The entire system has to be
maintained down to the operating system level. Ongoing system and kernel
upgrades are regular security best practices. PCB comes with the Landscape
service which provides centralised management capabilities for Ubuntu machines.
It can be used to automate system updates and upgrades, apply the latest
security patches and create repositories. Moreover, by subscribing to the Ubuntu
Advantage for Infrastructure (UA-I) support package, users get access to the
Kernel Livepatch Service which allows to apply critical kernel patches without
rebooting the machine.

PCB provides an integrated Logging, Monitoring and Alerting (LMA) stack which is
another essential toolset in performing daily operational tasks. It consists of the
ELK stack, Nagios, Prometheus and Grafana. Using the LMA stack enables
OpenStack administrators with centralised logging platform, metrics collection,
health monitoring and capacity monitoring.

As the entire ecosystem is large, upskilling the personnel becomes a critical

factor. In order to help with this process, Canonical offers a series of trainings
which are delivered on-site by an experienced professional covering topics
including Ubuntu Server, MAAS, OpenStack and Kubernetes.

8
 5. Transfer

There are situations where all of the above are not sufficient. For example, what if
it is found that there is a critical security vulnerability which is affecting the
environment? Security patches and bug fixes usually become available within a
few days, but what if the cloud needs patching in a few hours? Or what if there is
no in-house knowledge to fix a simple issue? And finally, what if an organisation
doesn’t have people to operate OpenStack at all?

Canonical offers two types of services which assist with OpenStack operations.
This includes support services and managed services. The support services are
offered under the UA-I package and include critical security patches, 24/7
support, production-grade SLAs, ESM (Extended Security Maintenance) and
more. These aim to ensure maximum uptime and stability, however, OpenStack is
still operated by the customer. UA-I comes in three variants: Essential, Standard
and Advanced.

In order to allow customers to fully offload the risk associated with OpenStack
operations, Canonical also provides fully-managed services. In this case the cloud
is operated by a geographically-distributed team of Canonical’s cloud experts,
while the customer can fully focus on maximising the business value brought by
OpenStack. The service includes both the host and all guests. The UA-I cost is
included in the service price.

9
 Conclusion
Although OpenStack is a complex system consisting of various inter-connected
services, its adoption process can be handled painlessly by following a proven
adoption process consisting of design, model, deploy, operate and transfer
phases. Following this approach allows customers to bypass the challenges
related to OpenStack deployments and operations, and benefit from production-
grade stability brought by Canonical’s Charmed OpenStack. As a result they can
save budget spent on dedicated headcounts and focus on maximising the value
brought by the cloud platform rather than struggling with its adoption.

Canonical provides tools which assist organisations at each phase of the adoption
process. This includes reference architecture, hardware recommendations, MAAS
for infrastructure provisioning, Juju for OpenStack services modelling and
OpenStack charms which allow transforming the model into a deployment. All of
them are included in the PCB package. A complementary UA-I package provides
support services. As OpenStack operations tend to be even more challenging
than the initial deployment process, the fully managed services option allows
customers to transfer operations responsibilities from their internal IT
department to Canonical’s team of dedicated cloud experts.

Learn more

For more information about Charmed OpenStack, please visit our website
or read the following materials:
• From VMware to Charmed OpenStack webinar and whitepaper
• OpenStack made easy whitepaper
• BT turns to Canonical to enable next generation 5G cloud core

To get started with Charmed Openstack, follow the

instructions on the install page or get in touch.

© Canonical Limited 2020. Ubuntu, Kubuntu, Canonical and their associated logos are the registered trademarks
of Canonical Ltd. 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 110334C Registered Office:
12-14 Finch Road, Douglas, Isle of Man, IM99 1TT VAT Registration: GB 003 2322 47
Appendix

Package Private Cloud Build Private Cloud Build Plus Add-ons

Cost
Minimum node count
Containerised Control Plane
High Availability
Monitoring and
performance trending
Security updates
Log Aggregation
Upgrades
Disaster Recovery
Workshop
Architecture
Hypervisors
Live migration
Identity
Core Block Storage
Additional
Storage Options
Virtual Networking
Network Topology
IPv6 Support
Tuning Options
Encryption
Security Extensions
Handover Documentation
OpenStack Services
Cost
$75,000 $150,000 Starting at $25,000
12 (Hyperconverged) Architecture-dependent
or 15 (Converged)
from Approved BOMs
Included
Full L2-based OpenStack HA
including MAAS, Juju & Landscape infrastructure
Nagios, Prometheus, Grafana Integration with custom
monitoring systems
Landscape Landscape and optional
offline updates
Included, powered by Elasticsearch and Greylog Custom log integration
Included with Managed Service OpenStack and OS upgrade
services available
Guaranteed Control Plane rebuilds Full DR Plan with automation
included with Managed Service
Included (remote) Included (on-site)
Hyperconverged Custom Architecture Custom bundle with
or Converged (standard components only) add-on components
with optional offline
deployment
KVM KVM
Yes
Keystone Keystone with SAML
LDAP or Active federated identity services
Directory backends
Ceph RBD with 3x replication and bcache acceleration
RADOSGW RADOSGW or Swift Other third-party SAN
Object Storage* and NAS integration
Neutron/OVS with Adds Provider Networks, Third-party SDN Integration
VxLAN & GRE tunneling Neutron BGP, Neutron DVR (CPlane, Juniper
Contrail, Cisco ACI)
NIC bonding, up to 4 NIC bonding, unlimited
segregated underlay underlay L2 network
L2 networks segregation
Tenant networks only
As standard CPU Pinning SR-IOV
Huge Pages DPDK-enabled OVS
GPU passthrough
Infiniband and more
No encryption Control Plane & Storage HSM support (via
(Ceph, at rest) OpenStack Barbican)
Apparmor MAC-based Apparmor MAC-based
Design Overview Design Overview
Tenant Onboarding Plan Tenant Onboarding Plan
Charm Bundle Charm Bundle
Deployment Guide Low Level Design
Deployment Guide
Nova KVM Designate
Neutron Gateway/API Ceilometer
CEPH OSD/MON Aodh
Nova Cloud controller Gnocchi
Keystone Heat
Rabbit MQ MySQL
Cinder Horizon
Glance
$75,000 $150,000 Starting at $25,000

Table 1. PCB features and pricing.