OpenStack Director

Red Hat Enterprise Linux OpenStack Platform director

Orgad Kimchi

Senior Cloud Architect

December 1st, 2015

OpenStack Director

Agenda

• Undercloud & Overcloud

• Previous Installers

• RHEL OSP Director

• RHEL OSP Director Workflow

• RHEL OSP Director Best Practices

OpenStack Director

Basic Layout of Undercloud and Overcloud

OpenStack Director

Undercloud• The Undercloud installs and configures the Overcloud.

• It is a single-system OpenStack installation that includes

components for provisioning and managing the OpenStack

nodes that comprise of your OpenStack environment (the

Overcloud).

• The Undercloud is the main director node.

OpenStack Director

Undercloud

• The Undercloud provides planning functions

for users to assign Red Hat Enterprise Linux

OpenStack Platform roles, including Compute,

Controller, and various storage roles.

OpenStack Director

Undercloud• Bare metal system control - The Undercloud uses the

Intelligent Platform Management Interface (IPMI) of each

node for power management control and a PXE-based service

to discover hardware attributes and install OpenStack to each

node.

• This provides a method to provision bare metal systems as

OpenStack nodes.

OpenStack Director

Undercloud

• Orchestration - The Undercloud provides and

reads a set of YAML templates to create an

OpenStack environment.

OpenStack Director

Overcloud

• The Overcloud is the resulting Red Hat

Enterprise Linux OpenStack Platform

environment created using the Undercloud.

• This includes one or more of the following

node types:

OpenStack Director

Overcloud• Controller - Nodes that provide administration, networking,

and high availability for the OpenStack environment. • A default Controller node contains the following components:

Horizon, Keystone, Nova API, Neutron Server, Open vSwitch, Glance, Cinder Volume, Cinder API, Swift Storage, Swift Proxy, Heat Engine, Heat API, Ceilometer, MariaDB, RabbitMQ.

• The Controller also uses Pacemaker and Galera for high availability functions.

OpenStack Director

Overcloud• Compute - Nodes used to provide computing resources for

the OpenStack environment.

• A default Compute node contains the following components:

Nova Compute, Nova KVM, Ceilometer Agent, Open vSwitch

• Storage - Nodes that provide storage for the OpenStack

environment.

OpenStack Director

Previous Installers

OpenStack Director

Packstack• Packstack was the original installer that was used to deploy

OpenStack on Red Hat based systems; that included RHEL, CentOS, Fedora, and Scientific Linux.

• Packstack is a CLI-only tool, i.e. there's no user interface outside of a command-line driven interface and uses Puppet to drive the installation and configuration of OpenStack components by connecting to required hosts over SSH.

OpenStack Director

Packstack

• Today, it's considered more of a "PoC

Installer", used to get a very limited

OpenStack environment up and running very

quickly.

OpenStack Director

RHEL OSP Installer (Staypuft)

• Based on the initial OpenStack Foreman

Installer (OFI), the RHEL OSP Installer,

internally codenamed "Staypuft".

• The RHEL OSP Installer (the default

deployment tool for OSP 5.0 and OSP 6.0).

OpenStack Director

SpinalStack

• Through acquisition of eNovance, Red Hat attained a wealth of experience and expertise in deploying OpenStack at scale, and in production.

• In addition to the personnel, Red Hat gained access to high quality tools and utilities that were built up from scratch for automating the deployment of OpenStack.

• SpinalStack was one of these tools; a highly customisable deployment tool, based on Puppet and Jenkins.

OpenStack Director

OpenStack Director

OpenStack Director

RHEL OpenStack Platform Director

In short, OSP director is Red Hat's new

installation, configuration, and monitoring toolset for RHEL OSP deployments.

OSP director is a convergence of years of upstream engineering work, established tooling created inhouse and tools that came to us via acquisition to create a best of breed deployment tool that's

in line with the overall direction of the OpenStack project.

OpenStack Director

RHEL OpenStack Platform Director• To have a tool that went beyond simply installing an

OpenStack environment; previous tools would be 'fire and forget' - once it's installed, the tool has done it's job.

• But what about ongoing operational tasks? Upgrades, patching, monitoring of the environment, capacity planning, utilisation metrics, etc.

• We needed more than just an installation tool

OpenStack Director

RHEL OpenStack Platform Director• OSP director is made up of many different components,

converging technologies obtained from the upstream OpenStack deployment projects (namely, TripleO and associated Ironic)

• As they have matured and become ready for production usage, and also components/features from existing homebrew toolsets.

• When director was initially proposed, the architecture looked like the following-

OpenStack Director

RHEL OpenStack Platform Director

OpenStack Director

RHEL OpenStack Platform Director• The idea was to use upstream, integrated OpenStack

components like TripleO and Ironic to provide the RESTful

native API for configuration and deployment.

• But to use our expertise in production deployments to ensure

that any hardware preparation and any images created are

completely tested and validated using SpinalStack features.

OpenStack Director

RHEL OSP Director mechanisms

• Like most OpenStack deployment tools, Installing the Installer• Identification of the target hosts - the one's we're installing

onto• Content management for the software to be deployed• Defining the topology and configuration of the deployment

OpenStack Director

RHEL OSP Director mechanisms

• Bare metal provisioning via automated hardware control• Software rollout and configuration management• Making modifications to an already director-deployed

environment

OpenStack Director

RHEL OSP Director Features• A common, unified CLI for deployment of undercloud and

overcloud. Using familiar, native OpenStack tools.

• We're able to deploy the underlying deployment cloud, as well as the production cloud, using a common underlying API.

OpenStack Director

RHEL OSP Director Features

• Automated health checking, benchmarking, and role assignment based on node characteristics.

• This gives us the ability to ensure that we make best use of our hardware and are able to identify any equipment performing below the expected metrics.

OpenStack Director

RHEL OSP Director • OSP director uses a variety of OpenStack components to

achieve it's goal of deployment, more specifically:• TripleO for the creation of images and environment

templates• Ironic for baremetal control• Heat for component definition, ordering, and deployment• Puppet for post-instantiation configuration.

OpenStack Director

TripleO

• TripleO is a project that aims to allow administrators to deploy a production cloud (where workloads will run) via an existing deployment OpenStack environment (utilising a subset of OpenStack components).

• The production cloud is known as the "overcloud" and the underlying OpenStack deployment cloud is known as the "undercloud".

OpenStack Director

OpenStack Director Features

OpenStack Director

RHEL OSP Director

• The ability to deploy a highly available, multi-

controller RHEL OSP environment based on

the existing HA reference architecture.

• Utilising pacemaker and HAproxy for service

availability and recovery.

OpenStack Director

RHEL OSP Director Features• Light integration with Red Hat Satellite. • Today we have integration with Satellite as a content store;

we do not use Satellite for bare-metal provisioning,• But we do have the ability to have hosts automatically

registered for asset tracking and subscription consumption.

OpenStack Director

RHEL OSP Director Features• Automated sanity checking during deployment.

• Throughout the deployment OSP director will ensure that

components are laid out correctly with the desired

configuration, and will finally be checked for API conformity

and OpenStack functionality by utilising Tempest.

OpenStack Director

RHEL OSP Director Features• The ability to scale the overcloud.

• We're focussing heavily on operational/day-to-day tasks with

the OSP director - one of the key things that operators will

want to do is to increase capacity where required, we can

increase the number of nodes per role.

OpenStack Director

RHEL OSP Director Features

• Automated upgrades between major versions

of RHEL OSP in the overcloud.

• One thing that previous deployment tooling

couldn't accomodate was the ability to both

patch, and upgrade major RHEL OSP versions.

OpenStack Director

RHEL OSP Director Features• Automated deployment and integration of Ceph.

• Ceph as a storage backend is now the default and

recommended storage backend for RHEL OSP.

• OSP director can deploy, and scale Ceph, for block,

ephemeral, and image storage.

• As per previous deployment tools, the Ceph monitors reside

on the controllers.

OpenStack Director

Deployment Workflow

Red Hat Confidential - NDA Required

36

Deployment Workflow

OpenStack Director

Deployment Workflow Overview• Environment Preparation Prepare your environment (bare metal or virtual)

• Install undercloud

• Undercloud Data Preparation Create images to establish the overcloud

• Register hardware nodes with undercloud

• Introspect hardware

• Create flavors (node profiles)

OpenStack Director

Deployment Workflow Overview• Deployment Planning Configure overcloud roles

– Assign flavor (node profile to match desired hardware specs)

– Assign image (provisioning image)

– Size the role (how many instances to deploy)

• Configure service parameters

• Create a Heat template describing the overcloud (auto-generated from above)

OpenStack Director

Deployment Workflow Overview• Deployment Use Heat to deploy your template

• Heat will use Nova to identify and reserve the appropriate

nodes

• Nova will use Ironic to startup nodes and install the correct

images

• Per-node Setup When each node of the overcloud starts it will

gather its configuration metadata from Heat Template

configuration files

OpenStack Director

Deployment Workflow Overview• Hiera files are distributed across all nodes and Heat applies

puppet manifests to configure the services on the nodes

• Puppet runs in multiple steps, so that after each step there can be test triggered to check progress of the deployment and allow easier debugging.

• Overcloud Initialization Services on nodes of the overcloud are registered with Keystone

OpenStack Director

Best Practices

OpenStack Director

RHEL OSP Director Best Practices• The overcloud nodes will be deployed from the undercloud

machine and therefore the machines need to have have their network settings modified to allow for the overcloud nodes to be PXE boot’ed using the undercloud machine.

• As such, the setup requires that:• All overcloud machines in the setup must support IPMI

OpenStack Director

RHEL OSP Director Best Practices

• A management provisioning network is setup for all of the overcloud machines.

• One NIC from every machine needs to be in the same broadcast domain of the provisioning network.

OpenStack Director

RHEL OSP Director Best Practices

• The provisioning network NIC should not be the same NIC that you are using for remote connectivity to the undercloud machine.

• During the undercloud installation, a openvswitch bridge will be created for Neutron and the provisioning NIC will be bridged to the openvswitch bridge.

• As such, connectivity would be lost if the provisioning NIC was also used for remote connectivity to the undercloud machine.

OpenStack Director

RHEL OSP Director Best Practices

• The overcloud machines can PXE boot off the NIC that is on the private VLAN.

• This required disabling network booting in the BIOS for all NICs other than the one we wanted to boot and then ensuring that the chosen NIC is at the top of the boot order (ahead of the local hard disk drive and CD/DVD drives).

OpenStack Director

RHEL OSP Director Best Practices

• For each overcloud machine you have: the MAC address of the NIC that will PXE boot on the provisioning network the IPMI information for the machine (i.e. IP address of the IPMI NIC, IPMI username and password)

OpenStack Director

More Information

Project Overview - https://www.rdoproject.org/RDO-Manager

Director Installation and Usage https://access.redhat.com/documentation/en-

US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/index.html

OpenStack Director

THANK YOUplus.google.com/+RedHat

linkedin.com/company/red-hat

youtube.com/user/RedHatVideos

facebook.com/redhatinc

redhatstack.com

twitter.com/RedHatNews