Chapter 2. Director architecture
Red Hat OpenStack Platform director uses OpenStack APIs to configure, deploy, and manage Red Hat OpenStack Platform (RHOSP) environments. This means that integration with director requires that you integrate with these OpenStack APIs and supporting components. The benefits of these APIs are that they are well documented, undergo extensive integration testing upstream, are mature, and make understanding how director works easier for those that have a foundational knowledge of RHOSP. Director automatically inherits core OpenStack feature enhancements, security patches, and bug fixes.
Director is a toolset that you use to install and manage a complete RHOSP environment. It is based primarily on the OpenStack project TripleO, which is an abbreviation for "OpenStack-On-OpenStack". This project uses RHOSP components to install a fully operational RHOSP environment. This includes new OpenStack components that provision and control bare metal systems to use as OpenStack nodes. This provides a simple method for installing a complete RHOSP environment that is both lean and robust.
Director uses two main concepts: an undercloud and an overcloud. Director is a subset of OpenStack components that form a single-system OpenStack environment, also known as the undercloud. The undercloud acts as a management system that can create a production-level cloud for workloads to run. This production-level cloud is the overcloud. For more information about the overcloud and the undercloud, see the Director Installation and Usage guide.
Figure 2.1. Architecture of the undercloud and the overcloud
Director includes tools, utilities, and example templates that you can use to create an overcloud configuration. Director captures configuration data, parameters, and network topology information and uses this information in conjunction with components such as ironic, heat, and Puppet to orchestrate an overcloud installation.
2.1. Core components and overcloud
The following components are core to Red Hat OpenStack Platform director and contribute to overcloud creation:
- OpenStack Bare Metal Provisioning service (ironic)
- OpenStack Orchestration service (heat)
- TripleO and TripleO heat templates
- Composable services
- Containerized services and Kolla
2.1.1. OpenStack Bare Metal Provisioning service (ironic)
The Bare Metal Provisioning service provides dedicated bare metal hosts to end users through self-service provisioning. Director uses ironic to manage the life-cycle of the bare metal hardware in the overcloud. Ironic uses its own API to define bare metal nodes.
To provision OpenStack environments with director, you must register your nodes with ironic by using a specific driver. The main supported driver is the Intelligent Platform Management Interface (IPMI) as most hardware contains some support for IPMI power management functions. However, Bare Metal Provisioning also contains vendor specific equivalents, such as HP iLO, Cisco UCS, or Dell DRAC.
Ironic controls the power management of the nodes and gathers hardware information or facts using an introspection mechanism. Director uses the information from the introspection process to match nodes to various OpenStack environment roles, such as Controller nodes, Compute nodes, and Storage nodes. For example, a discovered node with 10 disks is usually provisioned as a Storage node.
Figure 2.2. Use the Bare Metal Provisioning service controls the power management of the nodes
If you want to have director support for your hardware, you must have driver coverage in the Bare Metal Provisioning service.
Heat is an application stack orchestration engine. You can use heat to define elements for an application before you deploy it to a cloud. Create a stack template that includes a number of infrastructure resources, for example, instances, networks, storage volumes, and elastic IPs, with a set of parameters for configuration. Use heat to create these resources based on a given dependency chain, monitor the resources for availability, and scale if necessary. You can use these templates to make application stacks portable and to achieve repeatable results.
Figure 2.3. Use the heat service to define elements for an application before you deploy it to a cloud
Director uses the native OpenStack heat APIs to provision and manage the resources associated with overcloud deployment. This includes precise details such as defining the number of nodes to provision per node role, the software components to configure for each node, and the order in which director configures these components and node types. Director also uses heat to troubleshoot a deployment and make changes post-deployment.
The following example is a snippet from a heat template that defines parameters of a Controller node:
NeutronExternalNetworkBridge: description: Name of bridge used for external network traffic. type: string default: 'br-ex' NeutronBridgeMappings: description: > The OVS logical->physical bridge mappings to use. See the Neutron documentation for details. Defaults to mapping br-ex - the external bridge on hosts - to a physical name 'datacentre' which can be used to create provider networks (and we use this for the default floating network) - if changing this either use different post-install network scripts or be sure to keep 'datacentre' as a mapping network name. type: string default: "datacentre:br-ex"
Heat consumes templates included with the director to facilitate the creation of an overcloud, which includes calling ironic to power the nodes. You can use the standard heat tools to view the resources and statuses of an in-progress overcloud. For example, you can use the heat tools to display the overcloud as a nested application stack. Use the syntax of heat templates to declare and create production OpenStack clouds. Because every partner integration use case requires heat templates, you must have some prior understanding and proficiency for partner integration.
Puppet is a configuration management and enforcement tool you can use to describe and maintain the end state of a machine. You define this end state in a Puppet manifest. Puppet supports two models:
- A standalone mode in which you run instructions in the form of manifests locally
- A server mode in which Puppet retrieves its manifests from a central server, called a Puppet Master
You can make changes in two ways:
- Upload new manifests to a node and execute them locally.
- Make modifications in the client/server model on the Puppet Master.
Director uses Puppet in the following areas:
On the undercloud host locally to install and configure packages according to the configuration in the
By injecting the
openstack-puppet-modulespackage into the base overcloud image, the Puppet modules are ready for post-deployment configuration. By default, you create an image that contains all OpenStack services for each node.
- Providing additional Puppet manifests and heat parameters to the nodes and applying the configuration after overcloud deployment. This includes the services to enable and start the configuration depending on the node type.
Providing Puppet hieradata to the nodes. The Puppet modules and manifests are free from site or node-specific parameters to keep the manifests consistent. The hieradata acts as a form of parameterized values that you can push to a Puppet module and reference in other areas. For example, to reference the MySQL password inside of a manifest, save this information as hieradata and reference it within the manifest.
To view the hieradata:
[root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file openstack::controller::mysql_root_password: ‘redhat123'
To reference the hieradata in the Puppet manifest:
[root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest mysql_root_password => hiera(‘openstack::controller::mysql_root_password')
Partner-integrated services that need package installation and service enablement can create Puppet modules to meet their requirements. For more information about obtaining current OpenStack Puppet modules and examples, see Section 4.2, “Obtaining OpenStack Puppet modules”.
2.1.4. TripleO and TripleO heat templates
Director is based on the upstream TripleO project. This project combines a set of OpenStack services with the following goals:
- Store overcloud images by using the Image service (glance)
- Orchestrate the overcloud by using the Orchestration service (heat)
- Provision bare metal machines by using the Bare Metal Provisioning (ironic) and Compute (nova) services
TripleO also includes a heat template collection that defines a Red Hat-supported overcloud environment. Director, using heat, reads this template collection and orchestrates the overcloud stack.
2.1.5. Composable services
Each aspect of Red Hat OpenStack Platform is broken into a composable service. This means that you can define different roles that use different combinations of services. For example, you can move the networking agents from the default Controller node to a standalone Networker node.
For more information about the composable service architecture, see Chapter 6, Composable services.
2.1.6. Containerized services and Kolla
Each of the main Red Hat OpenStack Platform (RHOSP) services run in containers. This provides a method to keep each service within its own isolated namespace separated from the host. This has the following effects:
- During deployment, RHOSP pulls and runs container images from the Red Hat Custom Portal.
podmancommand operates management functions, like starting and stopping services.
- To upgrade containers, you must pull new container images and replace the existing containers with newer versions.
Red Hat OpenStack Platform uses a set of containers built and managed with the
Red Hat OpenStack Platform uses Ansible to drive certain functions in relation to composable service upgrades. This includes functions such as starting and stopping services and performing database upgrades. These upgrade tasks are defined within composable service templates.