Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Cluster Design Overview


A typical layout of the control plane infrastructure needed to support a small or medium OpenStack cluster is displayed in Figure 1. Red Hat OpenStack (RHOS) Platform 13 which is the Queen’s release of OpenStack is typically deployed using OSP Director, the deployment tool for Red Hat OpenStack. RHOS Platform 13 is based on the OpenStack Triple-O project which has two primary components, an undercloud and an overcloud.

Figure 1: Basic Layout of an Undercloud and an Overcloud
Basic Layout of an Undercloud
and an Overcloud

The undercloud deploys and configures the overcloud. The undercloud is responsible for specifying the environment and roles for the different controller, compute, and storage components, provision the bare metal system and orchestrate the provisioning on the overcloud. In order to achieve these functions, the undercloud uses the following OpenStack services:

Glance, Heat, Ironic, Keystone, Nova, Neutron, and Swift.

The overcloud is the resulting Red Hat OpenStack platform which is created using the undercloud where the actual OpenStack services run. The overcloud hosts the virtualized workloads running the cloud applications. The overcloud controller runs the following OpenStack services:

Cinder, Glance, Heat, Horizon, Keystone, Nova, Neutron, Pacemaker, Swift and Galera for HA services.

The undercloud host runs the OSP Director VM which is responsible for deploying the overcloud on the four other overcloud controller hosts, as displayed in Figure 2. Each overcloud controller host has a few VMs that host the controller services related to Contrail and OpenStack.

  • CC refers to the contrail controller which constitutes the contrail configuration and control node

  • CA refers to Contrail Analytics

  • CADB refers to Contrail Analytics DB

  • OS refers to the Red Hat OpenStack controller

  • AFX refers to AppFormix which is an operations and monitoring tool that helps to manage the day 2 operations of the cluster

Figure 2: Undercloud and Overcloud Controllers
Undercloud and Overcloud

In order to establish communication between the various OpenStack services, the following six fundamental networks are essential in this deployment:

  • Internal API network used for the actual VM data traffic

  • Provisioning network used to provision the overcloud controller hosts base OS using the undercloud host’s ironic service

  • Storage network used to carry Ceph-related storage traffic

  • Storage management used for Ceph control and management traffic

  • External network leading to the internet which is used to pull packages from external repos

  • Tenant network used for communication between Contrail Networking components

While for some enterprise workloads, hyperconverged computes could work well, in order to guarantee storage SLAs, separating computes from storage nodes is recommended as displayed in the Figure 3 deployment architecture model..

Figure 3: Deployment Architecture
Deployment Architecture