Learning OpenStack Networking (Neutron) - Second Edition - Sample Chapter
Learning OpenStack Networking (Neutron) - Second Edition - Sample Chapter
P U B L I S H I N G
Sunil Sarat
$ 44.99 US
28.99 UK
E x p e r i e n c e
D i s t i l l e d
Learning OpenStack
Set up and maintain your own cloud-based Infrastructure
as a Service (IaaS) using OpenStack
Sa
m
pl
C o m m u n i t y
Alok Shrivastwa
Learning OpenStack
Learning OpenStack
ee
Alok Shrivastwa
Sunil Sarat
Sunil Sarat is the vice president of Cloud and Mobility Services at Microland Ltd, an
India-based global hybrid IT infrastructure services provider.
He played a key role in setting up and running emerging technology practices dealing
with areas such as public/private cloud (AWS and Azure, VMware vCloud Suite,
Microsoft, and OpenStack), hybrid IT (VMware vRealize Automation/Orchestration,
Chef, and Puppet), enterprise mobility (Citrix Xenmobile and VMware Airwatch), VDI
/app virtualization (VMware Horizon Suite, Citrix XenDesktop/XenApp, Microsoft
RDS, and AppV), and associated transformation services.
He is a technologist and a business leader with an expertise in creating new practices/
service portfolios and in building and managing high performance teams, strategy
definition, technology roadmaps, and 24/7 global remote infrastructure operations.
He has varied experiences in handling diverse functions such as innovation/
technology, service delivery, transition, presales/solutions, and automation.
He has authored white papers, blogs, and articles on various technology- and
service-related areas. Also, he is a speaker at cloud-related events and reviews
technical books. He has reviewed the books Learning Airwatch and Mastering
VMware Horizon 6, Packt Publishing.
He holds various industry certifications in the areas of compute, storage, and
security and also has an MBA degree in marketing.
Besides technology and business, he is passionate about filmmaking and is a
part-time filmmaker as well.
For more information, you can visit his Linkedin profile at https://www.linkedin.
com/in/sunilsarat or follow him at @sunilsarat.
Preface
The cloud is the new IT paradigm, and has moved beyond being probable to being
inevitable. No one can ignore it. Organizations are embracing the cloud for various
reasons such as agility, scalability, capex reduction, and a faster time to market their
products and services. There are choices available in terms of the following:
Ownership and control, with the options of public, private, or hybrid cloud
Preface
This book is an attempt to provide all the information that is just about sufficient to
kickstart your learning of OpenStack and build your own cloud. In this book, you will
be introduced to all major OpenStack services, the role they play, installation, and the
basic configuration and troubleshooting of each of these services. This book takes a
more practical-oriented approach to learning, as the knowledge from each chapter will
culminate in you being able to build your own private cloud by the time you finish
reading this book. We hope you will enjoy reading this book and more importantly
find it useful in your journey towards learning and mastering OpenStack.
Preface
Chapters 7, Your OpenStack Cloud in Action, stitches all the pieces together and
presents how all of the components come together to provide IaaS to users while
highlighting the role each of these components plays. This also introduces aspects
such as user and tenant management using GUI and CLI, network management,
services request, and template creation.
Chapter 8, Taking Your Cloud to the Next Level, introduces two OpenStack optional
components, Ceilometer and Heat. It discusses Heat, Heat API, Heat CF API,
Heat Engine, and Heat Orchestration Templates. This chapter also discusses data
collection, alarms, and meters in Ceilometer, and how can this be used to provide
billing and usage reporting.
Chapter 9, Looking Ahead, introduces the various distributions of OpenStack and
vendor offerings based on OpenStack. It also discusses different use cases where
OpenStack is being used and concludes by briefly touching upon the roadmap.
Appendix, New Releases, introduces the major differences between the last three
releases of OpenStack.
An Introduction to OpenStack
Enterprises traditionally ran their IT services by running appropriate applications on
a set of infrastructures and platforms. These were comprised of physical hardware in
terms of compute, storage, and network along with software in terms of hypervisors,
operating systems, and platforms. A set of experts from infrastructure, platform, and
application teams would then put the pieces together and get a working solution
tailored to the needs of the organization.
With the advent of virtualization and later on cloud, things have changed to a
certain extent, primarily in the way things are built and delivered. Cloud, which
has its foundations in virtualization, delivers a combination of relevant components
as a service; be it Infrastructure as a Service (IaaS), Platform as a Service (PaaS),
or Software as a Service (SaaS). In this book, we will only discuss how to provide
a system with IaaS using an OpenStack-based private cloud. The key aspect of
providing a system with IaaS is cross-domain automation. The system that helps
us achieve this is called a Cloud Service Orchestrator or Cloud Platform or Cloud
Controller. For the purposes of this book, we will refer to OpenStack as the Cloud
Service Orchestrator. The Cloud Service Orchestrator or, simply put, the orchestrator
is primarily responsible for the following:
[1]
An Introduction to OpenStack
Some of the choices in the FOSS segment for the orchestrators are as follows:
OpenStack
Apache CloudStack
Open Nebula
Cisco Intelligent Automation for the cloud (CIAC) and UCS Director
BMC Atrium
The basic building blocks of a private cloud and how OpenStack is different
from commercial orchestrators in building a private Cloud
Choosing an orchestrator
There are some key differences between commercial orchestrators, such as vRealize
Automation and CIAC, and FOSS orchestrators, such as OpenStack. While both of
them attempt to provide IaaS to users, it is important to understand the difference
between both the types of orchestrator in order to appropriately design your Cloud.
[2]
Chapter 1
Let's begin with commercial orchestrators; these provide a base IaaS to their users.
They normally sit on top of a virtualized environment and enable an automated
provisioning of compute, storage, and network, even though the extent of
automation varies. As a part of the toolset, they also typically have a workflow
engine, which in most cases provides us with an extensibility option.
The commercial orchestrators are a better choice when the entire orchestration needs
to be plugged in to the current IT processes. They work wonderfully well when
extensibility and integration are major tasks of the cloud environment, which is
typically seen in large enterprises given the scale of operations, the type of business
critical applications, and the maturity of IT processes.
In such large enterprises, in order to take full advantage of the private cloud, the
integration and automation of the orchestrator in the IT systems of the company
becomes necessary. This kind of orchestration is normally used when minimum
changes are anticipated to be made to the applications. A primary use case of this is
IaaS, where virtual machines are provisioned on a self-service basis and a very small
learning curve is involved.
FOSS orchestrators are less extensible, but more standardized in terms of offerings.
They offer standardized services that a user is expected to use as building blocks
to offer a larger solution. In order to take full advantage of the FOSS orchestrators,
some amount of recoding of applications is required as they need to make use of
the newly offered services. The use cases here are both IaaS and PaaS (for example,
Database as a Service, Message Queue as a Service, and so on).
For this reason, the APIs that are used among the FOSS orchestrators need to have
some common ground. This common ground that we are talking about here is
Amazon Web Services (AWS) API compatibility, as Amazon has emerged as the
gold standard as far as the service-oriented cloud architecture is concerned. At the
time of writing the book, OpenStack Nova still had AWS EC2 API compatibility,
but this may be pushed out to the StackForge project.
[3]
An Introduction to OpenStack
Commercial orchestrators
The following block diagram shows the different building blocks of a cloud that are
normally seen in a private implementation with a commercial orchestrator:
Virtualized
Datacenter
Metering &
Billing
API Endpoints
Monitoring
ITIL Toolset
Orchestrator
VM
CMDB
Configuration
Management
IPAM
VM
Virtualization
App
VM
Compute
Network
Storage
As we can see, in this private cloud setup, additional blocks such as Self Service
Portal, Metering & Billing, and Workflows & Connectors sit on top of an already
existing virtualized environment to provision a virtual machine, a stack of virtual
machines, or a virtual machine with some application installed and configured over it.
While most of the commercial orchestrators are extensible, some of them have
prebuilt plugins or connectors to most commonly used enterprise toolsets.
[4]
Chapter 1
OpenStack
Ceilometer
OpenStack doesn't natively support integration with enterprise toolsets, but in lieu
of this, it provides more standardized services. OpenStack feels and behaves more
like a public cloud inside an enterprise and provides more flexibility to a user. As
you can see in the following diagram, apart from VM provisioning, services such as
database, image storage, and so on are also provisioned:
Horizon
API Endpoints
VM
Nova
Neutron
Block
Store
Image
Store
DB
Cinder
Virtualized
Datacenter
Hadoop
Virtualization
Compute
Tiered
VM
Network
Storage
DNS
Please note that some of these services, which are provided as a part of the standard
offering by OpenStack, can be also be orchestrated using commercial orchestrators.
However, this will take some efforts in terms of additional automation and integration.
OpenStack
Commercial orchestrator
Yes
Yes
Connectivity to enterprise
toolsets
Yes
Yes
Somewhat
[5]
An Introduction to OpenStack
Feature
OpenStack
Commercial orchestrator
Enterprise control
Yes
Standardized prebuilt
services
Yes
No (Except virtual
machines)
EC2-compatible API
Yes
No
OpenStack architecture
The following architecture diagram explains the architecture of the base components
of the OpenStack environment. Each of these blocks and their subcomponents will be
dealt with in detail in the subsequent chapters:
[6]
Chapter 1
Heat (Orchestration)
Horizon (Dashboard)
Nova
(Compute)
Neutron
Trove
(DBaaS)
Sahara
(Big Data)
Ironic
(Bare
Metal)
Designate
(DNS)
AQMP
Glance
(Image)
Zaqar
(Notifications)
Cinder
(Block
Storage)
Swift
(Object
Store)
Barbican
(Key Management)
The gray boxes show the core services that OpenStack absolutely needs to run. The other
services are optional and are called Big Tent services, without which OpenStack can run, but
we may need to use them as required. In this book, we look at the core components and also
look at Horizon, Heat, and Ceilometer in the Big Tent services.
Each of the previously mentioned components has their own database. While
each of these services can run independently, they form relationships and have
dependencies among each other. As an example, Horizon and Keystone provide
their services to the other components of OpenStack and should be the first ones to
be deployed.
[7]
An Introduction to OpenStack
Service relationships
The following diagram expands on the preceding block diagram and depicts the
different relationships amongst the different services:
Heat (Orchestrate)
Horizon
UI
Networking
Neutron
Monitor
Celiometer
Provisioning
Nova
Image
Virtual
Machine
Glance
Block Storage
Cinder
Store
Image
Swift
Keystone
Authentication
Service relationships
The service relationship shows that the services are dependent on each other. It is to
be noted that all the services work together in harmony to produce the end product
as a Virtual Machine (VM). So the services can be turned on or off depending
on what kind of virtual machine is needed as the output. While the details of the
services are mentioned in the next section, if, as an example, the VM or the cloud
doesn't require advanced networking, you may completely skip the installation and
configuration of the Neutron service.
[8]
Chapter 1
Release name
Components
Austin
Nova, Swift
Bexar
Cactus
Diablo
Essex
Folsom
Grizzly
Havana
Icehouse
Juno
Kilo
Liberty
At the time of writing, the only fully supported releases were Juno,
Kilo, and Liberty. Icehouse is only supported from the security
updates standpoint in the OpenStack community. There are,
however, some distributions of OpenStack that are still available on
older releases such as that of Icehouse. (You can read more about
different distributions in the last chapter of the book.).
Service functions
It is important to know about the functions that each of these services performs. We
will discuss the different services of OpenStack. In order to understand the functions
more clearly, we will also draw parallels with the services from AWS. So if you ever
want to compare your private cloud with the most used public cloud, you can.
Please refer to the preceding table in order to see the services that are available in a
particular OpenStack release.
[9]
An Introduction to OpenStack
Keystone
This service provides identity and access management for all the components of
OpenStack. It has internal services such as identity, resource, assignment, token,
catalog, and policy, which are exposed as an HTTP frontend.
So if we are logging in to Horizon or making an API call to any component, we have
to interact with the service and be able to authenticate ourselves in order to use it.
The policy services allow the setting up of granular control over the actions allowed
by a user for a particular service. The service supports federation and authentication
with an external system such as an LDAP server.
This service is equivalent to the IAM service of the AWS public cloud.
Horizon
Horizon provides us with a dashboard for both self-service and day-to-day
administrative activities. It is a highly extensible Django project where you can add
your own custom dashboards if you choose to. (The creation of custom dashboards is
beyond the scope of this book and is not covered here).
Horizon provides a web-based user interface to OpenStack services including Nova,
Swift, Keystone, and so on.
This can be equated to the AWS console, which is used to create and configure
the services.
Nova
Nova is the compute component of OpenStack. It's one of the first services available
since the inception as it is at the core of IaaS offering.
Nova supports various hypervisors for virtual machines such as XenServer, KVM,
and VMware. It also supports Linux Containers (LXC) if we need to minimize
the virtualization overhead. In this book, we will deal with LXC and KVM as our
hypervisors of choice to get started.
It has various subcomponents such as compute, scheduler, xvpvncproxy,
novncproxy, serialproxy, manage, API, and metadata. It serves an EC2 (AWS)compatible API. This is useful in case you have a custom system such as ITIL tool
integration with EC2 or a self-healing application. Using the EC2 API, this will run
with minor modifications on OpenStack Nova.
Nova also provides proxy access to a console of guest virtual machines using the
VNC proxy services available on hypervisors, which is very useful in a private cloud
environment. This can be considered equivalent to the EC2 service of AWS.
[ 10 ]
Chapter 1
Glance
Glance service allows the storage and retrieval of images and corresponding
metadata. In other words, this will allow you to store your OS templates that you
want to be made available for your users to deploy. Glance can store your images in
a flat file or in an object store (such as Swift).
Swift
Swift is the object storage service of OpenStack. This service is primarily used to
store and retrieve Binary Large Object (BLOBs). It has various subservices such as
ring, container server, updater, and auditors, which have a proxy server as
their frontend.
The swift service is used to actually store Glance images. As a comparison, the EC2
AMIs are stored in your S3 bucket.
The swift service is equivalent to the S3 storage service of AWS.
Cinder
Cinder provides block storage to the Nova VMs. Its subsystems include a volume
manager, a SQL database, an authentication manager, and so on. The client uses
AQMP such as Rabbit MQ to provide its services to Nova. It has drivers for various
storage systems such as Cloud Byte, Gluster FS, EMC VMAX, Netapp, Dell Storage
Centre, and so on.
This service provides similar features to the EBS service of AWS.
Neutron
Previously known as Quantum, Neutron provides networking as a service. There
are several functionalities that it provides such as Load Balancer as a Service and
Firewall as a Service. This is an optional service and we can choose not to use this,
as basic networking is built into Nova. Also, Nova networking is being phased
out. Therefore, it is important to deal with Neutron, as 99 percent of OpenStack
implementations have implemented Neutron in their network services.
The system, when configured, can be used to create multi-tiered isolated networks.
An example of this could be a full three-tiered network stack for an application that
needs it.
This is equivalent to multiple services in AWS such as ELB, Elastic IP, and VPC.
[ 11 ]
An Introduction to OpenStack
Heat
Heat is the core orchestration service of the orchestrator. What this means is that
you can script the different components that are being spun up in an order. This
is especially helpful if we want to deploy multicomponent stacks. The system
integrates with most of the services and makes API calls in order to create and
configure different components.
The template used in Heat is called Heat Orchestrator Template (HOT). It is actually
a single file in which you can script multiple actions. As an example, we can write a
template to create an instance, some floating IPs and security groups, and even create
some users in Keystone.
The equivalent of Heat in AWS would be the cloud formation service.
Ceilometer
Ceilometer service is used to collect metering data. There are several subsystems in
the Ceilometer such as polling agent, notification agent, collector, and API. This also
allows the saving of alarms abstracted by a storage abstraction layer to one of the
supported databases such as Mongo DB, Hbase, or SQL server.
Trove
Trove is the Database as a Service component of OpenStack. This service uses Nova
to create the compute resource to run DBaaS. It is installed as a bunch of integration
scripts that run along with Nova. The service requires the creation of special images
that are stored in Glance.
This is equivalent to the RDS service of AWS.
Sahara
Sahara service is the Big Data service of OpenStack; it is used to provision a Hadoop
cluster by passing a few parameters. It has several components such as Auth
component, Data Access Layer, Provisioning Engine, and Elastic Data Processing.
This is very close to getting the MapReduce AWS service in your very own cloud.
[ 12 ]
Chapter 1
Designate
The Designate service offers DNS services equivalent to Route 53 of the AWS.
The service has various subsystems such as API, the Central/Core service, the Mini
DNS service, and Pool Manager. It has multiple backend drivers that can be used,
examples being PowerDNS, BIND, NSD, and DynECT. We can create our own
backend drivers as well.
Ironic
The Ironic service allows bare metal provisioning using technologies such as the
PXE boot and the Intelligent Platform Management Interface (IPMI). This will
allow bare metal servers to be provisioned provided we have the requisite drivers
for them.
Please remember that the requisite networking elements have to be configured, for
example, the DNS, DHCP configuration and so on, which are needed for the PXE
boot to work.
Zaqar
Zaqar is the messaging and notification service of OpenStack. This is equivalent to
the SNS service from AWS. It provides multitenanted HTTP-based messaging API
that can be scaled horizontally as and when the need arises.
Barbican
Barbican is the key management service of OpenStack that is comparable to KMS
from AWS. This provides secure storage, retrieval, provisioning and management
of various types of secret data such as keys, certificates, and even binary data.
Manila
Manila provides a shared filesystem as a service. At the moment, it has a single
subcomponent called the manila-manage. This doesn't have any equivalent in the
AWS world yet. This can be used to mount a single filesystem on multiple Nova
instances, for instance a web server with shared assets, which will help to keep the
static assets in sync without having to run a block-level redundancy such as DRBD
or continuous rsyncs.
[ 13 ]
An Introduction to OpenStack
Murano
Murano is an application catalog, enabling application developers and cloud
administrators to publish various cloud-ready applications in a catalog format.
This service will use Heat at the backend to deliver this and will only work on
the UI and API layer.
Magnum
Magnum introduces Linux Containers such as Dockers and Kubernetes (by Google)
to improve migration option. This service is in some ways like Trove, it uses
an image with Docker installed on it and orchestrates Magnum with Heat. It is
effectively Container as a Service (CaaS) of OpenStack.
Kolla
Kolla is another project that is focused on containers. While it did make its first
appearance in Kilo, it was majorly introduced in the Liberty release. This is aimed
at better operationalization by containerizing OpenStack itself. That means, we can
now run the OpenStack services in containers, and thereby make governance easier.
At the time of writing, the Kolla project supported services such as Cinder, Swift,
Ceph, and Ironic.
Congress
Congress is another project focused on governance. It provides Policy as a Service,
which can be used for compliance in a dynamic infrastructure, thereby maintaining
the OpenStack components to be compliant to the enterprise policy.
Core service
Dependent on
Keystone
True
None
Horizon
False
Keystone
[ 14 ]
Chapter 1
Service name
Core service
Dependent on
Glance
True
Swift
Keystone
Horizon
Swift
True
Keystone
Nova
True
Keystone
Horizon
Glance
Cinder (Optional)
Neutron (Optional)
Heat
False
Keystone
Cinder
False
Keystone
Neutron
False
Keystone
Ceilometer
False
Keystone
Trove
False
Keystone
Nova
Nova
Glance
Sahara
False
Keystone
Nova
Glance
Swift
Keystone
Magnum
False
Heat
Nova
Glance
Swift
Keystone
Murano
False
Heat
Service dependency
[ 15 ]
An Introduction to OpenStack
Keystone
Horizon
Nova
Cinder
Swift
Glance
In the optional section, we will choose Neutron. This should help us in getting
a pretty robust cloud with the essential features rolled out in no time.
Service layout
We will be installing these components on virtual machines for our learning
purposes; we will use four different virtual machines to run our cloud:
Controller node
Network node
Compute node
Storage node
[ 16 ]
Chapter 1
The following diagram shows the kind of services that will be hosted in each of
the different nodes in the rest of the book. We will identify the servers with the
previously mentioned names:
Controller Node
Compute Node
Network Node
Storage Node
Keystone
Hypervisor
Open vSwitch
Block Storage
Nova Mgmt
Open vSwitch
Network Plugin
Object Storage
Horizon
Nova
DHCP Agent
Neutron Mgmt
Network Plugin
L3 Agent
Storage Mgmt
Controller node
The controller node will house the manager services for all the different OpenStack
components such as message queue, Keystone, image service, Nova management,
and Neutron management.
Network node
The network node server will house Neutron components such as the DHCP Agent,
the L3 Agent, and Open vSwitch. This node will provide networking to all the guest
VMs that spin up in the OpenStack environment.
Compute node
The compute node will have the hypervisor installed on itself. For the purpose of this
setup, we will use LXC or KVM to keep things simple. It also houses network agents.
[ 17 ]
An Introduction to OpenStack
Storage node
The storage node will provide block and object storage to the rest of the OpenStack
services. This will be the node that needs to be connected to the iSCSI storage in
order to create different blocks.
Operating system
We will use Linux Ubuntu 14.04 as the operating system of choice to install and
configure the different components. All the previously mentioned nodes should be
running Ubuntu.
Network layout
Since we are going to use Neutron, the following network architecture needs to be
followed:
Tunnel network: This network is used to tunnel the traffic between the
compute nodes and the network node and is available on all the compute
and the network nodes. There can be more than one if we are going for a
multi-tiered environment.
Storage network: This connects the compute and storage nodes. This is used
as a separate network to ensure that there is no network congestion.
External network: This is connected only to the network node and can be
accessed using Neutron. The elastic IPs are configured on this network.
The following diagram shows the different connections in our network. The compute
node is connected to all the networks except the external network. It is to be noted
that the storage and the tunnel network can be completely internal networks. The
management network is primarily the one that needs to be accessible from the LAN
of the company, as this will be the network that the users will need to reach in order
to access the self-service portal:
[ 18 ]
Chapter 1
Network Node
Management Network
External Network
Internet
Tunnel Network
Compute Node
Storage Network
Storage Node
Controller Node
Network connectivity
For the purpose of learning, let's set up the network ranges that we will use in our
installation. The following is the table of the network range:
Network Name
IP Range
Management Network
172.22.6.0/24
Tunnel Network
10.0.0.0/24
Storage Network
192.168.10.0/24
External Network
192.168.2.0/24
Network ranges
Since we are using this in the lab network, the external network is assumed and will
need to be changed depending on the routing rules.
[ 19 ]
An Introduction to OpenStack
Summary
In this chapter, we were introduced to orchestrators, both commercial and FOSS.
At a very high level, we looked at the differences between these two types of
orchestrators and the appropriate use cases for OpenStack. We also looked at the
basic building blocks of a private cloud and their correlation in the OpenStack world.
We looked at the OpenStack architecture and services. And finally, we covered the
lab setup that would be required to learn the deployment of your private cloud using
OpenStack.
We start our journey in the next chapter by learning to install and configure the
common components that form the basis of most of the OpenStack services. The key
topic covered, however, would be installation and configuration of Keystone, which
is the core authentication and authorization service of OpenStack
[ 20 ]
www.PacktPub.com
Stay Connected: