Chapter 3. Choosing a Deployment Type
Deploying pure HCI is simpler, as it involves invoking an environment file that adds the Ceph-OSD services to the Compute role. Deploying mixed HCI involves defining a custom role, flavor, and networking settings for HCI nodes. As both HCI types offer contrasting deployment approaches, determine which type is more suitable for your environment.
The following sub-sections walk through each deployment type. For either deployment type, create a
/home/stack/templates/ directory to store any custom environment files and Heat templates.
3.1. Pure HCI
To deploy Red Hat OpenStack with pure, use the following environment file:
This environment file redefines the Compute role by adding the
CephOSD service to it. By default, the
hyperconverged-ceph.yaml environment file assumes that you are using an isolated
StorageMgmt network, and configures the Compute ports accordingly.
If you are not using an isolated
StorageMgmt network, disable the
StorageMgmtPort service. To do this:
Create a new environment file named
~/templates/containing the following:
During the deployment process (Section 6.1, “Deploying Pure HCI”), invoke
~/templates/hyperconverged-non-isolated.yamlwhen you run
openstack overcloud deploy. This environment file must be invoked last to ensure that it overrides the others correctly.
Proceed to Chapter 4, Configuring Resource Isolation on Hyper-converged Nodes for instructions on mitigating resource contention between Compute and Ceph Storage services.
3.2. Mixed HCI
The Overcloud usually consists of nodes in predefined roles such as Controller nodes, Compute nodes, and different storage node types. Each of these default roles contains a set of services defined in the core Heat template collection on the director node. However, the architecture of the core Heat templates provides a method to:
- Create custom roles
- Add and remove services from each role
This allows us to define a new role both Compute and Ceph OSD services. This effectively co-locates both services, allowing you to deploy them together on the same hyper-converged node.
3.2.1. Creating a Custom Role for HCI Nodes
On the undercloud, default roles are defined in the following file:
Copy this file to the custom templates directory you created (namely,
$ cp usr/share/openstack-tripleo-heat-templates/roles_data.yaml ~/templates/roles_data_hci.yaml
To define a new role that co-locates both Compute and Ceph OSD, create a role that combines the services of both
CephStorage entries. To do this, add a new role named
~/templates/roles_data_hci.yaml, copy the
Compute role services to
OsdCompute, and add the Ceph OSD service:
- name: OsdCompute # 1 CountDefault: 1 # 2 disable_upgrade_deployment: True ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::CephOSD # 3 - OS::TripleO::Services::Timezone [...]
Red Hat OpenStack Platform supports deployments that feature both hyper-converged and non-hyper-converged Compute nodes. If you do not want to deploy any non-hyper-converged Compute nodes, set the
CountDefault: parameter of the
Compute role to
- name: Compute CountDefault: 0 disable_upgrade_deployment: True ServicesDefault: - OS::TripleO::Services::CACerts - OS::TripleO::Services::CephClient - OS::TripleO::Services::CephExternal - OS::TripleO::Services::Timezone - OS::TripleO::Services::Ntp [...]
You can use the CountDefault: parameter to define how many nodes to assign to each role. However, we recommend that you do so in a separate Heat template, as described later in Section 6.2, “Deploying Mixed HCI”.
3.2.2. Configuring Port Assignments for the Custom Role
The default Heat templates in
/usr/share/openstack-tripleo-heat-templates/ provide the necessary network settings for the default roles. These settings include how IP addresses and ports should be assigned for each service on each node.
Custom roles (like
OsdCompute in Section 3.2.1, “Creating a Custom Role for HCI Nodes”) do not have the required port assignment Heat templates, so you need to define these yourself. To do so, create a new Heat template named
~/templates containing the following:
resource_registry: OS::TripleO::OsdCompute::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml # 1 OS::TripleO::OsdCompute::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api.yaml OS::TripleO::OsdCompute::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage.yaml OS::TripleO::OsdCompute::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml OS::TripleO::OsdCompute::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant.yaml OS::TripleO::OsdCompute::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt.yaml
3.2.3. Creating and Assigning a New Flavor
As mentioned in Section 1.1, “Assumptions”, you should have already registered and tagged each node with a corresponding flavor. However, since deploying mixed HCI involves defining a new OsdCompute role, you also need to create a new flavor for it:
To create a new role named
$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 osdcomputeNote
For more details about this command, run
openstack flavor create --help.
Map this flavor to a new profile, also named
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="osdcompute" osdcomputeNote
For more details about this command, run
openstack flavor set --help.
Tag nodes into the new
$ ironic node-update UUID add properties/capabilities='profile:osdcompute,boot_option:local'