⁠Chapter 6. Provisioning Red Hat Enterprise Linux OpenStack Platform

6.1. Deployments
6.1.1. Creating a Deployment
6.1.2. New Deployment Settings
6.1.3. Editing a Deployment
6.1.4. Removing a Deployment
6.2. Assigning Hosts to Deployment Roles
6.2.1. Assigning a Host to a Deployment Role
6.2.2. Unassigning a Host from a Deployment
6.3. Configuring Host Networking
6.3.1. Configuring Networking on a Host
6.3.2. Bonding Modes
6.4. Configuring Fencing
6.4.1. Configuring Fencing on High-Availability Nodes
6.5. Deployment Configurations
6.5.1. Viewing the Configuration of a Deployment
6.5.2. Editing Service Parameters
6.5.3. Importing a Deployment Configuration
6.5.4. Exporting a Deployment Configuration
6.6. Provisioning Red Hat Enterprise Linux OpenStack Platform
6.6.1. Provisioning Red Hat Enterprise Linux OpenStack Platform
6.6.2. Retrieving Service Details
6.6.3. Logging In
6.6.4. Next Steps
The installer provisions Red Hat Enterprise Linux OpenStack Platform using deployments. A deployment is a collection of settings that defines the hosts on which services are to be provisioned, options such as whether to use Neutron networking or Nova networking as the networking back end, and key parameters for several of the services to be provisioned.
Two of the key considerations when you create a new deployment are the networking back end, and the volume driver for the Block Storage (Cinder) service:
Networking Back Ends
RHEL OpenStack Platform offers two networking back ends: Nova networking, and Neutron networking. Nova networking has been deprecated in the OpenStack technology roadmap, but still remains available. For information on each of these back ends, including how to decide which back end is suitable for your environment and how to configure the options available to each back end, see "Choose a Network Back End" in Deploying OpenStack: Learning Environments (Manual Setup).
Volume Drivers
A volume driver is the storage back end that the Block Storage service uses to provide block storage to Compute nodes in a RHEL OpenStack Platform environment. The default implementation is to use LVM, but you can also choose from NFS storage, Ceph storage, or EqualLogic storage. For more information on each of the volume drivers and how to configure the options available to each volume driver, see "Volume Drivers" in the Configuration Reference Guide.

⁠6.1. Deployments

A deployment maps OpenStack services to hosts in your environment and installs these services to their assigned hosts. This includes various options for high availability controllers, Neutron or Nova networking, and a choice of messaging service. A deployment also provides specific parameters to customize each service. Deployments provide mechanisms to define all aspects of an OpenStack environment and help scale the environment in the future.
The following diagram outlines the topology of a sample deployment that uses high availability:
⁠
The topology of a sample deployment with high availability

Figure 6.1. The topology of a sample deployment with high availability

There are seven hosts in this deployment. The server icon at the top of the diagram represents the installer. The server icon beneath the installer represents controller nodes. Because this deployment uses high availability, there are three hosts assigned to this role so that the environment can continue to function in the event of a failure on any of the three nodes. The three server icons directly beneath the controller nodes represent compute nodes. The first two compute nodes were added when the RHEL OpenStack Platform environment was provisioned. The third compute node, Compute N, represents additional compute nodes that can be added to the environment after it has been provisioned to enable horizontal scaling. The final server icon in the diagram represents a Ceph OSD node.
The nodes in this deployment communicate with each other and with external networks over the four following networks:
  • The yellow network represents a public network that only the installer uses. This network allows the installer to communicate with external network resources such as the Content Delivery Network. It is configured manually on the host where the user interface is installed. Moreover, access to the dashboard from external networks can also be enabled by placing public API traffic on the same subnet as the provisioning network described below, or by optionally creating a dedicated subnet for this network traffic type and configuring external routing.
  • The green network represents the provisioning network that the installer defines when you install the user interface. This network carries traffic between the installer and the hosts in the deployment. This is the network that the installer uses to boot hosts using PXE, and to set up and configure hosts when you provision a RHEL OpenStack Platform environment. While the installer defines this network when you install the user interface, you must also create a subnet to carry this network traffic when you create a deployment. Moreover, while this network traffic type is carried over a dedicated subnet in this deployment, this network traffic type can be shared with any of the network traffic types carried by the blue network outlined below. The subnet that carries this network traffic type must be assigned to every host in the deployment.
  • The blue network represents a private network that carries network traffic between the nodes in a RHEL OpenStack Platform environment. This network carries management, cluster management, administrative API, storage, and storage clustering network traffic. The subnet that carries these network traffic types must be assigned to every host in the deployment.
  • The red network represents a public network that carries network traffic between instances in the RHEL OpenStack Platform environment and external networks. This network provides external network connectivity to virtual machines. A dedicated subnet must be created to carry this type of network traffic. The subnet that carries this network traffic type is only assigned to controller nodes.

⁠6.1.1. Creating a Deployment

Create a deployment for provisioning a RHEL OpenStack Platform environment. For information on each of the options available when configuring networking and services, see Section 6.1.2, “New Deployment Settings”.
⁠

Procedure 6.1. Creating a Deployment

  1. Click OpenStack Installer → New deployment.
  2. Configure deployment settings:
    ⁠
    The Deployment Settings step

    Figure 6.2. The Deployment Settings step

    1. Enter a name for the deployment in the Name field.
    2. Enter a description in the Description field.
    3. Select either Controller / Compute or High Availability Controllers / Compute in the High Availability section.
    4. Select either Neutron Networking or Nova Network in the Networking section.
    5. Select either RabbitMQ or Qpid as the message broker in the Messaging Provider section.

      Note

      As of Red Hat Enterprise Linux OpenStack Platform 5, RabbitMQ replaces QPid as the default (and recommended) message broker.
    6. Ensure Red Hat Enterprise Linux OpenStack Platform 5 with RHEL 7 is selected in the Platform section.
    7. Select Generate random password for each service in the Service Password section to generate a random password for each service, or select Use single password for all services and enter a password in the Password and Verify fields to set the same password for all services.
    8. Optionally, enter a list of custom repositories in the Custom repos text area. Multiple custom repositories must be added on separate lines, and each custom repository must take the form of a base URL.
    9. Click Next.
  3. Configure network traffic:
    ⁠
    The Network Configuration step

    Figure 6.3. The Network Configuration step

    1. Drag and drop the available network traffic types into the section for a subnet.
    2. Create new subnets if you require a new subnet to which to assign a network traffic type:
      1. Click New Subnet.
      2. Enter a name to represent the subnet in the user interface in the Name field.
      3. Select External DHCP or No existing DHCP from the DHCP server list.
        Setting DHCP server to External DHCP means an external DHCP server exists on the subnet and the Installer sets the boot mode of clients on this subnet to use DHCP.
        Setting DHCP server to No existing DHCP means no DHCP server exists on the subnet and the Installer assigns static IP addresses to clients on the subnet. These static IP addresses are recorded in the Installer's database, which gives the Installer a DHCP-like capability. If you select No Existing DHCP and the subnet is to carry the Public API network traffic type, you must enter the address of a machine that can act as a gateway in the Gateway field. If you select No existing DHCP, you can also specify the IP Range Start and the IP Range End.
      4. Enter the network address in the Network Address field. This address must be in CIDR notation. For example, XX.XX.XX.0/24.
      5. Optionally, enter a VLAN ID for the subnet in the VLAN field.
      6. Click Create Subnet.
    3. Click Next.

    Note

    By default, all network traffic types except External is assigned to the default subnet. Because the External network traffic type is required and cannot be assigned to the same subnet as other network traffic types, you must create a dedicated subnet for this network traffic type. You can then drag and drop network traffic types to subnets as required, or to the Available Network Traffic Types section to disable optional network traffic types.
  4. In the Services Overview step, review the list of services to be provisioned, and click Next.
    ⁠
    The Services Overview step

    Figure 6.4. The Services Overview step

  5. Configure service options:
    ⁠
    The Services Configuration step

    Figure 6.5. The Services Configuration step

    • Neutron

      Options for this service are only available if you selected Neutron Networking in the Deployment Settings step.
      1. Select a Tenant Network Type.
      2. Select a Core Plugin Type.

    • Nova

      Options for this service are only available if you selected Nova Network in the Deployment Settings step.
      1. Select a Tenant Network Type.
      2. Enter a Floating IP range for external network.
      3. Enter a Fixed IP range for tenant networks.

    • Glance

      1. Select a driver backend from the Choose Driver Backend radio boxes.

    • Cinder

      1. Select one or more driver backends from the Choose Driver Backend check boxes.
  6. Click Submit.

⁠6.1.2. New Deployment Settings

This section outlines the options available when you create a new deployment.

⁠6.1.2.1. Network Configuration Settings

The following table outlines the different network traffic types available in the Network Configuration step of creating a new deployment.
⁠

Table 6.1. Network Configuration Settings

Network Traffic Type Description   
Provisioning/PXE Communication with the installer. For example, to provision hosts and to allow hosts to boot over the network using the PXE service that the installer provides.   
Management Private communication amongst services.   
External Communication between instances in the RHEL OpenStack Platform environment and external network resources. This network traffic type cannot be placed on the same subnet as other network traffic types.   
Cluster Management Pacemaker cluster management communication.   
Admin API Administrative communication amongst services.   
Public API Access to the REST API and the Horizon dashboard.   
Tenant Tenant network communication for instances in the RHEL OpenStack Platform environment.   
Storage Storage-related communication. This network traffic type is optional.   
Storage Clustering Storage-related communication for replication and data checks in Ceph clusters. This network traffic type is optional.   

⁠6.1.2.2. Services Configuration Settings

The following table outlines the options available in the Services Configuration step of creating a new deployment.
⁠

Table 6.2. Services Configuration Settings

Service Option Description  
Neutron Tenant Network Type The type of network used for tenant networks. You can choose from the following options:
  • VXLAN Segmentation: Virtual extensible LAN. A network layout that extends the functionality of a VLAN by providing a larger network segment ID range and other features.
  • GRE Segmentation: Generic routing encapsulation segmentation. A network layout in which tunnels are used to segregate and carry network traffic over individual tenant networks.
  • VLAN Segmentation: A network layout in which multiple isolated networks are defined. If you choose this option, you must also specify the tenant VLAN range.
  • Flat: A simple network layout in which all instances are members of the same network.
 
  Core Plugin Type
The core network plugin. You can choose from the following options:

ML2 Core Plugin

The modular layer 2 plugin. If you select this plugin, you can select the following ML2 mechanism drivers:
  • Open vSwitch: A software-defined networking virtual switch designed to supersede the heritage Linux software bridge. Open vSwitch provides switching services to virtualized networks with support for industry-standard NetFlow, OpenFlow, and sFlow.
  • L2 Population: Enables horizontal scaling of broadcast, multicast, and unicast traffic on large overlay networks. L2 population implements a partial mesh for ARP resolution and MAC learning traffic whereby this traffic is sent only to the necessary agent by encapsulating it as a targeted unicast.
  • Cisco Nexus: Enables configuration of Cisco Nexus switches. If you select this option, you must enter the Switch Hostname, Switch IP Address, Switch Login, Switch Password, SSH Port, and Port Mappings. You can add additional switches by clicking Add Another Switch.

N1KV Core Plugin

The Cisco 1000v plugin. If you select this plugin, you must also specify the details of a virtual supervisor module:
  • VSM IP: The IP address of the virtual supervisor module.
  • VSM Password: A password with which to authenticate with the virtual supervisor module.
 
Nova Tenant Network Type
  • Flat with DHCP: A simple network layout in which all instances are members of the same network, and the DHCP service is also provided.
  • VLAN: A network layout in which multiple isolated networks are defined. If you choose this option, you must also specify the tenant VLAN range.
 
  Floating IP range for external network A range of IP addresses to be used for external networks. Ranges must be entered using CIDR notation. For example, XX.XX.XX.0/24.  
  Fixed IP range for tenant networks A range of IP addresses to be used for tenant networks. Ranges must be entered using CIDR notation. For example, XX.XX.XX.0/24.  
Glance Choose Driver Backend The driver to use for back-end storage of images. You can choose from the following options:
  • Local File: The local file system. This option is only available in deployments without high availability.
  • Ceph: Ceph storage.
  • NFS: Network file system storage. If you select this option, you must also specify the NFS address in the network path text field.
 
Cinder Choose Driver Backend The volume driver to use for back-end storage. You can choose from the following options:
  • LVM: Logical volume manager storage. This option is only available for deployments without high availability.
  • NFS: Network file system storage. If you select this option, you must also specify the NFS address in the NFS URI text field.
  • Ceph: Ceph storage.
  • EqualLogic for EqualLogic storage attached network systems. If you select this option, you must also specify the details of the storage attached network, including the SAN IP Addr, SAN Login, SAN Password, Pool, and Group.
 

⁠6.1.3. Editing a Deployment

Edit the properties of an existing deployment. The new properties are applied to Red Hat Enterprise Linux OpenStack Platform environments newly provisioned using that deployment.

Important

Editing the properties of a deployment and repeating the provisioning of a Red Hat Enterprise Linux OpenStack Platform environment to apply those change is not supported.
⁠

Procedure 6.2. Editing a Deployment

  1. Click OpenStack Installer → Deployments to open the OpenStack Deployments page.
  2. Click the name of a deployment to open the details page for that deployment.
  3. Click the name of the deployment to edit the name, and click Save when complete to make the change persistent.
  4. Click the description of the deployment to edit the description, and click Save when complete to make the change persistent.
  5. Optionally, click the Revisit Setup Wizard button to open the setup wizard and configure further options such as the messaging broker and the password with which to authenticate services.

⁠6.1.4. Removing a Deployment

Remove an existing deployment from the user interface. Removing a deployment does not affect any existing environments that have been provisioned based on that deployment.
⁠

Procedure 6.3. Removing a Deployment

  1. Click OpenStack Installer → Deployments.
  2. Click the Delete button for the deployment to remove.
  3. Click OK when prompted.