Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    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 10 which is the Newton release of OpenStack is typically deployed using OSP Director, the deployment tool for Red Hat OpenStack. RHOS Platform 10 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:

    Ceilometer, 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:

    Ceilometer, 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
Controllers

    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
    • Management network used for OpenStack API traffic
    • External network leading to the internet which is used to pull packages from external repos

    While for some enterprise workloads, hyperconverged computes could work well, Juniper recommends separating computes from storage nodes in order to guarantee storage SLAs. Juniper suggests the deployment architecture model displayed in Figure 3 with the specifications listed in Table 1.

    Figure 3: Deployment Architecture

    Deployment Architecture

    Table 1: Deployment Architecture Specifications

    Role

    Model

    Quantity (1 Rack)

    Quantity (Additional Rack)

    Leaf TOR Switches

    Basic Network Fabric

    QFX5100-48S

    2

    2

    Advanced Network Fabric

    QFX5100-48S

    4

    4

    SmartNIC

    QFX5200-32C

    2

    2

    Spine Switches

    Basic Network Fabric

    QFX10002-72Q

    2

    2 for every 18 racks

    Advanced Network Fabric

    QFX10002-72Q

    4

    4 for every 36 racks

    Gateway Router

    MX480

    2

    -

    Management Switch

    EX4300-48T

    2

    2

    Modified: 2018-01-28