Red Hat Enteprise Linux Open Stack Platfrom Director
-
Upload
orgad-kimchi -
Category
Technology
-
view
592 -
download
1
Transcript of Red Hat Enteprise Linux Open Stack Platfrom Director
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