Deploying a hyperconverged infrastructure
Understand and configure Hyperconverged Infrastructure on the Red Hat OpenStack Platform overcloud
Abstract
Providing feedback on Red Hat documentation Copy linkLink copied to clipboard!
We appreciate your input on our documentation. Tell us how we can make it better.
Use the Create Issue form to provide feedback on the documentation for Red Hat OpenStack Services on OpenShift (RHOSO) or earlier releases of Red Hat OpenStack Platform (RHOSP). When you create an issue for RHOSO or RHOSP documents, the issue is recorded in the RHOSO Jira project, where you can track the progress of your feedback.
To complete the Create Issue form, ensure that you are logged in to Jira. If you do not have a Red Hat Jira account, you can create an account at https://issues.redhat.com.
- Click the following link to open a Create Issue page: Create Issue
- Complete the Summary and Description fields. In the Description field, include the documentation URL, chapter or section number, and a detailed description of the issue. Do not modify any other fields in the form.
- Click Create.
Chapter 1. Configuring and deploying a Red Hat OpenStack Platform hyperconverged infrastructure Copy linkLink copied to clipboard!
1.1. Hyperconverged infrastructure overview Copy linkLink copied to clipboard!
Red Hat OpenStack Platform (RHOSP) hyperconverged infrastructures (HCI) consist of hyperconverged nodes. In RHOSP HCI, the Compute and Storage services are colocated on these hyperconverged nodes for optimized resource use. You can deploy an overcloud with only hyperconverged nodes, or a mixture of hyperconverged nodes with normal Compute and Red Hat Ceph Storage nodes.
You must use Red Hat Ceph Storage as the storage provider.
Use BlueStore as the back end for HCI deployments to make use of the BlueStore memory handling features.
Hyperconverged infrastructures are built using a variation of the deployment process described in Deploying Red Hat Ceph and OpenStack together with director. In this deployment scenario, RHOSP director deploys your cloud environment, which director calls the overcloud, and Red Hat Ceph Storage. You manage and scale the Ceph cluster itself separate from the overcloud configuration.
Instance HA is not supported on RHOSP HCI environments. To use Instance HA in your RHOSP HCI environment, you must designate a subset of the Compute nodes with the ComputeInstanceHA role to use the Instance HA. Red Hat Ceph Storage services must not be hosted on the Compute nodes that host Instance HA.
Red Hat OpenStack Platform 17.1 only supports Red Hat Ceph Storage 6 for new deployments. Red Hat Ceph Storage 5 is not supported in new deployment scenarios.
All HCI nodes in supported Hyperconverged Infrastructure environments must use the same version of Red Hat Enterprise Linux as the version used by the Red Hat OpenStack Platform controllers. If you wish to use multiple Red Hat Enterprise versions in a hybrid state on HCI nodes in the same Hyperconverged Infrastructure environment, contact the Red Hat Customer Experience and Engagement team to discuss a support exception.
For HCI configuration guidance, see Configuration guidance.
Chapter 2. Deploying HCI hardware Copy linkLink copied to clipboard!
This section contains procedures and information about the preparation and configuration of hyperconverged nodes.
Prerequisites
- You have read Deploying an overcloud and Red Hat Ceph Storage in Deploying Red Hat Ceph and OpenStack together with director.
2.1. Cleaning Ceph Storage node disks Copy linkLink copied to clipboard!
Ceph Storage OSDs and journal partitions require factory clean disks. All data and metadata must be erased by the Bare Metal Provisioning service (ironic) from these disks before installing the Ceph OSD services.
You can configure director to delete all disk data and metadata by default by using the Bare Metal Provisioning service. When director is configured to perform this task, the Bare Metal Provisioning service performs an additional step to boot the nodes each time a node is set to available.
The Bare Metal Provisioning service uses the wipefs --force --all command. This command deletes all data and metadata on the disk but it does not perform a secure erase. A secure erase takes much longer.
Procedure
Open
/home/stack/undercloud.confand add the following parameter:clean_nodes=true
clean_nodes=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Save
/home/stack/undercloud.conf. Update the undercloud configuration.
openstack undercloud install
openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.2. Registering nodes Copy linkLink copied to clipboard!
Register the nodes to enable communication with director.
Procedure
-
Create a node inventory JSON file in
/home/stack. Enter hardware and power management details for each node.
For example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the new file.
Initialize the stack user:
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Import the JSON inventory file into director and register nodes
openstack overcloud node import <inventory_file>
$ openstack overcloud node import <inventory_file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<inventory_file>with the name of the file created in the first step.Assign the kernel and ramdisk images to each node:
openstack overcloud node configure <node>
$ openstack overcloud node configure <node>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. Verifying available Red Hat Ceph Storage packages Copy linkLink copied to clipboard!
Verify all required packages are available to avoid overcloud deployment failures.
2.3.1. Verifying cephadm package installation Copy linkLink copied to clipboard!
Verify the cephadm package is installed on at least one overcloud node. The cephadm package is used to bootstrap the first node of the Ceph Storage cluster.
The cephadm package is included in the overcloud-hardened-uefi-full.qcow2 image. The tripleo_cephadm role uses the Ansible package module to ensure it is present in the image.
2.4. Deploying the software image for an HCI environment Copy linkLink copied to clipboard!
Nodes configured for an HCI environment must use the overcloud-hardened-uefi-full.qcow2 software image. Using this software image requires a Red Hat OpenStack Platform (RHOSP) subscription.
Procedure
-
Open your
/home/stack/templates/overcloud-baremetal-deploy.yamlfile. Add or update the
imageproperty for nodes that require theovercloud-hardened-uefi-fullimage. You can set the image to be used on specific nodes, or for all nodes that use a specific role:Specific nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow All nodes configured for a specific role
Copy to Clipboard Copied! Toggle word wrap Toggle overflow In the
roles_data.yamlrole definition file, set therhsm_enforceparameter toFalse.rhsm_enforce: False
rhsm_enforce: FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the provisioning command:
openstack overcloud node provision \ --stack overcloud \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yaml
(undercloud)$ openstack overcloud node provision \ --stack overcloud \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
Pass the
overcloud-baremetal-deployed.yamlenvironment file to theopenstack overcloud deploycommand.
2.5. Designating nodes for HCI Copy linkLink copied to clipboard!
To designate nodes for HCI, you must create a new role file to configure the ComputeHCI role, and configure the bare metal nodes with a resource class for ComputeHCI.
Procedure
-
Log in to the undercloud as the
stackuser. Source the
stackrccredentials file:source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Generate a new roles data file named
roles_data.yamlthat includes theControllerandComputeHCIroles:openstack overcloud roles generate Controller ComputeHCI -o ~/roles_data.yaml
(undercloud)$ openstack overcloud roles generate Controller ComputeHCI -o ~/roles_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open
roles_data.yamland ensure that it has the following parameters and sections:Expand Section/Parameter Value Role comment
Role: ComputeHCIRole name
name: ComputeHCIdescriptionHCI roleHostnameFormatDefault%stackname%-novaceph-%index%deprecated_nic_config_nameceph.yaml-
Register the ComputeHCI nodes for the overcloud by adding them to your node definition template,
node.jsonornode.yaml. Inspect the node hardware:
openstack overcloud node introspect --all-manageable --provide
(undercloud)$ openstack overcloud node introspect --all-manageable --provideCopy to Clipboard Copied! Toggle word wrap Toggle overflow Tag each bare metal node that you want to designate for HCI with a custom HCI resource class:
openstack baremetal node set \ --resource-class baremetal.HCI <node>
(undercloud)$ openstack baremetal node set \ --resource-class baremetal.HCI <node>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<node>with the ID of the bare metal node.Add the
ComputeHCIrole to your/home/stack/templates/overcloud-baremetal-deploy.yamlfile, and define any predictive node placements, resource classes, or other attributes that you want to assign to your nodes:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Open the
baremetal.yamlfile and ensure that it contains the network configuration necessary for HCI. The following is an example configuration:Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteNetwork configuration in the
ComputeHCIrole contains thestorage_mgmtnetwork. CephOSD nodes use this network to make redundant copies of data. The network configuration for theComputerole does not contain this network.See Configuring the Bare Metal Provisioning service for more information.
Run the provisioning command:
openstack overcloud node provision \ --stack overcloud \ --network_config \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yaml
(undercloud)$ openstack overcloud node provision \ --stack overcloud \ --network_config \ --output /home/stack/templates/overcloud-baremetal-deployed.yaml \ /home/stack/templates/overcloud-baremetal-deploy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Monitor the provisioning progress in a separate terminal.
watch openstack baremetal node list
(undercloud)$ watch openstack baremetal node listCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe
watchcommand renews every 2 seconds by default. The-noption sets the renewal timer to a different value.-
To stop the
watchprocess, enterCtrl-c. -
Verification: When provisioning is successful, the node state changes from
availabletoactive.
2.6. Defining the root disk for multi-disk Ceph clusters Copy linkLink copied to clipboard!
Ceph Storage nodes typically use multiple disks. Director must identify the root disk in multiple disk configurations. The overcloud image is written to the root disk during the provisioning process.
Hardware properties are used to identify the root disk. For more information about properties you can use to identify the root disk, see Properties that identify the root disk.
Procedure
Verify the disk information from the hardware introspection of each node:
openstack baremetal introspection data save <node_uuid> --file <output_file_name>
(undercloud)$ openstack baremetal introspection data save <node_uuid> --file <output_file_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Replace
<node_uuid>with the UUID of the node. Replace
<output_file_name>with the name of the file that contains the output of the node introspection.For example, the data for one node might show three disks:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Replace
Set the root disk for the node by using a unique hardware property:
(undercloud)$ openstack baremetal node set --property root_device='{<property_value>}' <node-uuid>-
Replace
<property_value>with the unique hardware property value from the introspection data to use to set the root disk. Replace
<node_uuid>with the UUID of the node.NoteA unique hardware property is any property from the hardware introspection step that uniquely identifies the disk. For example, the following command uses the disk serial number to set the root disk:
(undercloud)$ openstack baremetal node set --property root_device='{"serial": "61866da04f380d001ea4e13c12e36ad6"}' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0
-
Replace
- Configure the BIOS of each node to first boot from the network and then the root disk.
Director identifies the specific disk to use as the root disk. When you run the openstack overcloud node provision command, director provisions and writes the overcloud image to the root disk.
2.6.1. Properties that identify the root disk Copy linkLink copied to clipboard!
There are several properties that you can define to help director identify the root disk:
-
model(String): Device identifier. -
vendor(String): Device vendor. -
serial(String): Disk serial number. -
hctl(String): Host:Channel:Target:Lun for SCSI. -
size(Integer): Size of the device in GB. -
wwn(String): Unique storage identifier. -
wwn_with_extension(String): Unique storage identifier with the vendor extension appended. -
wwn_vendor_extension(String): Unique vendor storage identifier. -
rotational(Boolean): True for a rotational device (HDD), otherwise false (SSD). -
name(String): The name of the device, for example: /dev/sdb1.
Use the name property for devices with persistent names. Do not use the name property to set the root disk for devices that do not have persistent names because the value can change when the node boots.
Chapter 3. Configuring the Red Hat Ceph Storage cluster for HCI Copy linkLink copied to clipboard!
This chapter describes how to configure and deploy the Red Hat Ceph Storage cluster for HCI environments.
3.1. Deployment prerequisites Copy linkLink copied to clipboard!
Confirm the following has been performed before attempting to configure and deploy the Red Hat Ceph Storage cluster:
- Provision of bare metal instances and their networks using the Bare Metal Provisioning service (ironic). For more information about the provisioning of bare metal instances, see Configuring the Bare Metal Provisioning service.
3.2. The openstack overcloud ceph deploy command Copy linkLink copied to clipboard!
If you deploy the Ceph cluster using director, you must use the openstack overcloud ceph deploy command. For a complete listing of command options and parameters, see openstack overcloud ceph deploy in the Command line interface reference.
The command openstack overcloud ceph deploy --help provides the current options and parameters available in your environment.
3.3. Ceph configuration overrides for HCI Copy linkLink copied to clipboard!
A standard format initialization file is an option for Ceph cluster configuration. This initialization file is then used to configure the Ceph cluster with either the cephadm bootstap --config <file_name> or openstack overcloud ceph deploy --config <file_name> commands.
Colocating Ceph OSD and Compute services on hyperconverged nodes risks resource contention between Red Hat Ceph Storage and Compute services. This occurs because the services are not aware of the colocation. Resource contention can result in service degradation, which offsets the benefits of hyperconvergence.
Resource allocation can be tuned using an initialization file to manage resource contention. The following creates an initialization file called initial-ceph.conf and then uses the openstack overcloud ceph deploy command to configure the HCI deployment.
The osd_memory_target_autotune option is set to true so that the OSD daemons adjust their memory consumption based on the osd_memory_target config option. The autotune_memory_target_ratio defaults to 0.7. This indicates 70% of the total RAM in the system is the starting point from which any memory consumed by non-autotuned Ceph daemons are subtracted. Then the remaining memory is divided by the OSDs, assuming all OSDs have osd_memory_target_autotune set to true. For HCI deployments, set the mgr/cephadm/autotune_memory_target_ratio to 0.2 to ensure more memory is available for the Compute service. The 0.2 value is a cautious starting point. After deployment, use the ceph command to change this value if necessary.
A two NUMA node system can host a latency sensitive Nova workload on one NUMA node and a Ceph OSD workload on the other NUMA node. To configure Ceph OSDs to use a specific NUMA node not used by the Compute workload, use either of the following Ceph OSD configurations:
-
osd_numa_nodesets affinity to a numa node -
osd_numa_auto_affinityautomatically sets affinity to the NUMA node where storage and network match
If there are network interfaces on both NUMA nodes and the disk controllers are NUMA node 0, use a network interface on NUMA node 0 for the storage network and host the Ceph OSD workload on NUMA node 0. Host the Nova workload on NUMA node 1 and have it use the network interfaces on NUMA node 1. Setting osd_numa_auto_affinity to true to achieve this configuration. Alternatively, the osd_numa_node could be set directly to 0 and a value would not be set for osd_numa_auto_affinity so that it defaults to false.
When a hyperconverged cluster backfills as a result of an OSD going offline, the backfill process can be slowed down. In exchange for a slower recovery, the backfill activity has less of an impact on the collocated Compute workload. Red Hat Ceph Storage has the following defaults to control the rate of backfill activity:
-
osd_recovery_op_priority = 3 -
osd_max_backfills = 1 -
osd_recovery_max_active_hdd = 3 osd_recovery_max_active_ssd = 10NoteIt is not necessary to pass these defaults in an initialization file as they are the default values. If values other than the defaults are desired for the inital configuration, add them to the initialization file with the required values before deployment. After deployment, use the command ‘ceph config set osd’.
3.4. Configuring time synchronization Copy linkLink copied to clipboard!
The Time Synchronization Service (chrony) is enabled for time synchronization by default. You can perform the following tasks to configure the service.
Time synchronization is configured using either a delimited list or an environment file. Use the procedure that is best suited to your administrative practices.
3.4.1. Configuring time synchronization with a delimited list Copy linkLink copied to clipboard!
You can configure the Time Synchronization Service (chrony) to use a delimited list to configure NTP servers.
Procedure
-
Log in to the undercloud node as the
stackuser. Configure NTP servers with a delimited list:
openstack overcloud ceph deploy \ --ntp-server "<ntp_server_list>"openstack overcloud ceph deploy \ --ntp-server "<ntp_server_list>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<ntp_server_list>with a comma delimited list of servers.openstack overcloud ceph deploy \ --ntp-server "0.pool.ntp.org,1.pool.ntp.org"openstack overcloud ceph deploy \ --ntp-server "0.pool.ntp.org,1.pool.ntp.org"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.2. Configuring time synchronization with an environment file Copy linkLink copied to clipboard!
You can configure the Time Synchronization Service (chrony) to use an environment file that defines NTP servers.
Procedure
-
Log in to the undercloud node as the
stackuser. -
Create an environment file, such as
/home/stack/templates/ntp-parameters.yaml, to contain the NTP server configuration. Add the
NtpServerparameter. TheNtpServerparameter contains a comma delimited list of NTP servers.parameter_defaults: NtpServer: 0.pool.ntp.org,1.pool.ntp.org
parameter_defaults: NtpServer: 0.pool.ntp.org,1.pool.ntp.orgCopy to Clipboard Copied! Toggle word wrap Toggle overflow Configure NTP servers with an environment file:
openstack overcloud ceph deploy \ --ntp-heat-env-file "<ntp_file_name>"openstack overcloud ceph deploy \ --ntp-heat-env-file "<ntp_file_name>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<ntp_file_name>with the name of the environment file you created.openstack overcloud ceph deploy \ --ntp-heat-env-file "/home/stack/templates/ntp-parameters.yaml"openstack overcloud ceph deploy \ --ntp-heat-env-file "/home/stack/templates/ntp-parameters.yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.4.3. Disabling time synchronization Copy linkLink copied to clipboard!
The Time Synchronization Service (chrony) is enabled by default. You can disable the service if you do not want to use it.
Procedure
-
Log in to the undercloud node as the
stackuser. Disable the Time Synchronization Service (chrony):
openstack overcloud ceph deploy \ --skip-ntpopenstack overcloud ceph deploy \ --skip-ntpCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.5. Configuring a top level domain suffix Copy linkLink copied to clipboard!
You can configure a top level domain (TLD) suffix. This suffix is added to the short hostname to create a fully qualified domain name for overcloud nodes.
A fully qualified domain name is required for TLS-e configuration.
Procedure
-
Log in to the undercloud node as the
stackuser. Configure the top level domain suffix:
openstack overcloud ceph deploy \ --tld "<domain_name>"openstack overcloud ceph deploy \ --tld "<domain_name>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow Replace
<domain_name>with the required domain name.openstack overcloud ceph deploy \ --tld "example.local"openstack overcloud ceph deploy \ --tld "example.local"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.6. Configuring the Red Hat Ceph Storage cluster name Copy linkLink copied to clipboard!
You can deploy the Red Hat Ceph Storage cluster with a name that you configure. The default name is ceph.
Procedure
-
Log in to the undercloud node as the
stackuser. Configure the name of the Ceph Storage cluster by using the following command:
openstack overcloud ceph deploy \ --cluster <cluster_name>$ openstack overcloud ceph deploy \ --cluster central \
Keyring files are not created at this time. Keyring files are created during the overcloud deployment. Keyring files inherit the cluster name configured during this procedure. For more information about overcloud deployment see Section 5.8, “Initiating overcloud deployment for HCI”
In the example above, the Ceph cluster is named central. The configuration and keyring files for the central Ceph cluster would be created in /etc/ceph during the deployment process.
Troubleshooting
The following error may be displayed if you configure a custom name for the Ceph Storage cluster:
monclient: get_monmap_and_config cannot identify monitors to contact because
If this error is displayed, use the following command after Ceph deployment:
cephadm shell --config <configuration_file> --keyring <keyring_file>
For example, if this error was displayed when you configured the cluster name to central, you would use the following command:
cephadm shell --config /etc/ceph/central.conf \
--keyring /etc/ceph/central.client.admin.keyring
cephadm shell --config /etc/ceph/central.conf \
--keyring /etc/ceph/central.client.admin.keyring
The following command could also be used as an alternative:
cephadm shell --mount /etc/ceph:/etc/ceph export CEPH_ARGS='--cluster central'
cephadm shell --mount /etc/ceph:/etc/ceph
export CEPH_ARGS='--cluster central'
3.7. Configuring network options with the network data file Copy linkLink copied to clipboard!
The network data file describes the networks used by the Red Hat Ceph Storage cluster.
Procedure
-
Log in to the undercloud node as the
stackuser. Create a YAML format file that defines the custom network attributes called
network_data.yaml.ImportantUsing network isolation, the standard network deployment consists of two storage networks which map to the two Ceph networks:
-
The storage network,
storage, maps to the Ceph network,public_network. This network handles storage traffic such as the RBD traffic from the Compute nodes to the Ceph cluster. -
The storage network,
storage_mgmt, maps to the Ceph network,cluster_network. This network handles storage management traffic such as data replication between Ceph OSDs.
-
The storage network,
Use the
openstack overcloud ceph deploycommand with the--crush-hierarchyoption to deploy the configuration.openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --network-data network_data.yamlopenstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --network-data network_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantThe
openstack overcloud ceph deploycommand uses the network data file specified by the--network-dataoption to determine the networks to be used as thepublic_networkandcluster_network. The command assumes these networks are namedstorageandstorage_mgmtin network data file unless a different name is specified by the--public-network-nameand--cluster-network-nameoptions.You must use the
--network-dataoption when deploying with network isolation. The default undercloud (192.168.24.0/24) will be used for both thepublic_networkandcluster_networkif you do not use this option.
3.8. Configuring network options with a configuration file Copy linkLink copied to clipboard!
Network options can be specified with a configuration file as an alternative to the network data file.
Using this method to configure network options overwrites automatically generated values in network_data.yaml. Ensure you set all four values when using this network configuration method.
Procedure
-
Log in to the undercloud node as the
stackuser. - Create a standard format initialization file to configure the Ceph cluster. If you have already created a file to include other configuration options, you can add the network configuration to it.
Add the following parameters to the
[global]section of the file:-
public_network -
cluster_network ms_bind_ipv4ImportantEnsure the
public_networkandcluster_networkmap to the same networks asstorageandstorage_mgmt.The following is an example of a configuration file entry for a network configuration with multiple subnets and custom networking names:
[global] public_network = 172.16.14.0/24,172.16.15.0/24 cluster_network = 172.16.12.0/24,172.16.13.0/24 ms_bind_ipv4 = True ms_bind_ipv6 = False
[global] public_network = 172.16.14.0/24,172.16.15.0/24 cluster_network = 172.16.12.0/24,172.16.13.0/24 ms_bind_ipv4 = True ms_bind_ipv6 = FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Use the command
openstack overcloud ceph deploywith the--configoption to deploy the configuration file.openstack overcloud ceph deploy \ --config initial-ceph.conf --network-data network_data.yaml
$ openstack overcloud ceph deploy \ --config initial-ceph.conf --network-data network_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.9. Configuring a CRUSH hierarchy for an OSD Copy linkLink copied to clipboard!
You can configure a custom Controlled Replication Under Scalable Hashing (CRUSH) hierarchy during OSD deployment to add the OSD location attribute to the Ceph Storage cluster hosts specification. The location attribute configures where the OSD is placed within the CRUSH hierarchy.
The location attribute sets only the initial CRUSH location. Subsequent changes of the attribute are ignored.
Procedure
-
Log in to the undercloud node as the
stackuser. Source the
stackrcundercloud credentials file:$ source ~/stackrc-
Create a configuration file to define the custom CRUSH hierarchy, for example,
crush_hierarchy.yaml. Add the following configuration to the file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Replace
<osd_host>with the hostnames of the nodes where the OSDs are deployed, for example,ceph-0. -
Replace
<rack_num>with the number of the rack where the OSDs are deployed, for example,r0.
-
Replace
Deploy the Ceph cluster with your custom OSD layout:
openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --osd-spec osd_spec.yaml \ --crush-hierarchy crush_hierarchy.yamlopenstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --osd-spec osd_spec.yaml \ --crush-hierarchy crush_hierarchy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
The Ceph cluster is created with the custom OSD layout.
The example file above would result in the following OSD layout.
Device classes are automatically detected by Ceph but CRUSH rules are associated with pools. Pools are still defined and created using the CephCrushRules parameter during the overcloud deployment.
Additional resources
See Red Hat Ceph Storage workload considerations in the Red Hat Ceph Storage Installation Guide for additional information.
3.10. Configuring Ceph service placement options Copy linkLink copied to clipboard!
You can define what nodes run what Ceph services using a custom roles file. A custom roles file is only necessary when default role assignments are not used because of the environment. For example, when deploying hyperconverged nodes, the predeployed compute nodes should be labeled as osd with a service type of osd to have a placement list containing a list of compute instances.
Service definitions in the roles_data.yaml file determine which bare metal instance runs which service. By default, the Controller role has the CephMon and CephMgr service while the CephStorage role has the CephOSD service. Unlike most composable services, Ceph services do not require heat output to determine how services are configured. The roles_data.yaml file always determines Ceph service placement even though the deployed Ceph process occurs before Heat runs.
Procedure
-
Log in to the undercloud node as the
stackuser. - Create a YAML format file that defines the custom roles.
Deploy the configuration file:
openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --roles-data custom_roles.yaml$ openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --roles-data custom_roles.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3.11. Configuring SSH user options for Ceph nodes Copy linkLink copied to clipboard!
The openstack overcloud ceph deploy command creates the user and keys and distributes them to the hosts so it is not necessary to perform the procedures in this section. However, it is a supported option.
Cephadm connects to all managed remote Ceph nodes using SSH. The Red Hat Ceph Storage cluster deployment process creates an account and SSH key pair on all overcloud Ceph nodes. The key pair is then given to Cephadm so it can communicate with the nodes.
3.11.1. Creating the SSH user before Red Hat Ceph Storage cluster creation Copy linkLink copied to clipboard!
You can create the SSH user before Ceph cluster creation with the openstack overcloud ceph user enable command.
Procedure
-
Log in to the undercloud node as the
stackuser. Create the SSH user:
$ openstack overcloud ceph user enable <specification_file>Replace
<specification_file>with the path and name of a Ceph specification file that describes the cluster where the user is created and the public SSH keys are installed. The specification file provides the information to determine which nodes to modify and if the private keys are required.For more information on creating a specification file, see Generating the service specification.
NoteThe default user name is
ceph-admin. To specify a different user name, use the--cephadm-ssh-useroption to specify a different one.openstack overcloud ceph user enable --cephadm-ssh-user <custom_user_name>It is recommended to use the default name and not use the
--cephadm-ssh-userparameter.If the user is created in advance, use the parameter
--skip-user-createwhen executingopenstack overcloud ceph deploy.
3.11.2. Disabling the SSH user Copy linkLink copied to clipboard!
Disabling the SSH user disables cephadm. Disabling cephadm removes the ability of the service to administer the Ceph cluster and prevents associated commands from working. It also prevents Ceph node overcloud scaling operations. It also removes all public and private SSH keys.
Procedure
-
Log in to the undercloud node as the
stackuser. Use the command
openstack overcloud ceph user disable --fsid <FSID> <specification_file>to disable the SSH user.-
Replace
<FSID>with the File System ID of the cluster. The FSID is a unique identifier for the cluster. The FSID is located in thedeployed_ceph.yamlenvironment file. Replace
<specification_file>with the path and name of a Ceph specification file that describes the cluster where the user was created.ImportantThe
openstack overcloud ceph user disablecommand is not recommended unless it is necessary to disablecephadm.ImportantTo enable the SSH user and Ceph orchestrator service after being disabled, use the
openstack overcloud ceph user enable --fsid <FSID> <specification_file>command.NoteThis command requires the path to a Ceph specification file to determine:
- Which hosts require the SSH user.
- Which hosts have the _admin label and require the private SSH key.
- Which hosts require the public SSH key.
For more information about specification files and how to generate them, see Generating the service specification.
-
Replace
3.12. Accessing Ceph Storage containers Copy linkLink copied to clipboard!
Preparing container images in the Installing and managing Red Hat OpenStack Platform with director guide contains procedures and information on how to prepare the registry and your undercloud and overcloud configuration to use container images. Use the information in this section to adapt these procedures to access Ceph Storage containers.
There are two options for accessing Ceph Storage containers from the overcloud.
3.12.1. Cacheing containers on the undercloud Copy linkLink copied to clipboard!
The procedure Modifying images during preparation describes using the following command:
sudo openstack tripleo container image prepare \ -e ~/containers-prepare-parameter.yaml \
sudo openstack tripleo container image prepare \
-e ~/containers-prepare-parameter.yaml \
If you do not use the --container-image-prepare option to provide authentication credentials to the openstack overcloud ceph deploy command and directly download the Ceph containers from a remote registry, as described in Downloading containers directly from a remote registry, you must run the sudo openstack tripleo container image prepare command before deploying Ceph.
3.12.2. Downloading containers directly from a remote registry Copy linkLink copied to clipboard!
You can configure Ceph to download containers directly from a remote registry.
The cephadm command uses the credentials that are configured in the containers-prepare-parameter.yaml file to authenticate to the remote registry and download the Red Hat Ceph Storage container.
Procedure
-
Create a
containers-prepare-parameter.yamlfile using the procedure Preparing container images in the Installing and managing Red Hat OpenStack Platform with director guide. -
Add the remote registry credentials to the
containers-prepare-parameter.yamlfile using theContainerImageRegistryCredentialsparameter as described in Obtaining container images from private registries. When you deploy Ceph, pass the
containers-prepare-parameter.yamlfile using theopenstack overcloud ceph deploycommand.openstack overcloud ceph deploy \ --container-image-prepare containers-prepare-parameter.yamlopenstack overcloud ceph deploy \ --container-image-prepare containers-prepare-parameter.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow NoteIf you do not cache the containers on the undercloud, as described in Cacheing containers on the undercloud, then you should pass the same
containers-prepare-parameter.yamlfile to theopenstack overcloud ceph deploycommand when you deploy Ceph. This will cache containers on the undercloud.
Chapter 4. Customizing the Red Hat Ceph Storage cluster for HCI Copy linkLink copied to clipboard!
Red Hat OpenStack Platform (RHOSP) director uses a default configuration to deploy containerized Red Hat Ceph Storage. You can customize Ceph Storage by overriding the default settings.
Prerequisites
- The servers are deployed and their storage networks configured.
-
The deployed bare metal file as output by
openstack overcloud node provision -o ~/deployed_metal.yaml ….
4.1. Configuration options Copy linkLink copied to clipboard!
There are several options for configuring the Red Hat Ceph Storage cluster.
Procedure
-
Log in to the undercloud node as the
stackuser. Optional: Use a standard format initialization (ini) file to configure the Ceph cluster.
Create the file with configuration options.
The following is an example of a simple configuration file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Save the configuration file.
Use the
openstack overcloud ceph deploy --config <configuration_file_name>command to deploy the configuration.Replace
<configuration_file_name>with the name of the file you created.openstack overcloud ceph deploy --config initial-ceph.conf
$ openstack overcloud ceph deploy --config initial-ceph.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Optional: Send configuration values to the
cephadm bootstrapcommand:openstack overcloud ceph deploy --force \ --cephadm-extra-args '<optional_arguments>' \Replace
<optional_arguments>with the configuration values to provide to the underlying command.NoteWhen using the arguments
--log-to-fileand--skip-prepare-host, the commandopenstack overcloud ceph deploy --force \ --cephadm-extra-args '--log-to-file --skip-prepare-host' \is used.
4.2. Generating the service specification (optional) Copy linkLink copied to clipboard!
The Red Hat Ceph Storage cluster service specification is a YAML file that describes the deployment of Ceph Storage services. It is automatically generated by tripleo before the Ceph Storage cluster is deployed. It does not usually have to be generated separately.
A custom service specification can be created to customize the Red Hat Ceph Storage cluster.
Procedure
-
Log in to the undercloud node as the
stackuser. Generate the specification file:
openstack overcloud ceph spec deployed_metal.yaml -o <specification_file>Replace
<specification_file>with the name of the file to generate with the current service specification.NoteThe
deployed_metal.yamlcomes from the output of theopenstack overcloud node provisioncommand.
- Edit the generated file with the required configuration.
Deploy the custom service specification:
openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --ceph-spec <specification_file>
openstack overcloud ceph deploy \ deployed_metal.yaml \ -o deployed_ceph.yaml \ --ceph-spec <specification_file>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Replace
<specification_file>with the name of the custom service specification file.
-
Replace
4.3. Ceph containers for Red Hat OpenStack Platform with Red Hat Ceph Storage Copy linkLink copied to clipboard!
You must have a Ceph Storage container to configure Red Hat Openstack Platform (RHOSP) to use Red Hat Ceph Storage with NFS Ganesha. You do not require a Ceph Storage container if the external Ceph Storage cluster only provides Block (through RBD), Object (through RGW), or File (through native CephFS) storage.
RHOSP 17.1 will deploy Red Hat Ceph Storage 6.x (Ceph package 17.x). The Ceph Storage 6.x containers are hosted at registry.redhat.io, a registry that requires authentication. For more information, see Container image preparation parameters.
4.4. Configuring advanced OSD specifications Copy linkLink copied to clipboard!
Configure an advanced OSD specification when the default specification does not provide the necessary functionality for your Ceph Storage cluster.
Procedure
-
Log in to the undercloud node as the
stackuser. Create a YAML format file that defines the advanced OSD specification.
The following is an example of a custom OSD specification.
data_devices: rotational: 1 db_devices: rotational: 0
data_devices: rotational: 1 db_devices: rotational: 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow This example would create an OSD specification where all rotating devices will be data devices and all non-rotating devices will be used as shared devices. When the dynamic Ceph service specification is built, whatever is in the specification file is appended to the section of the specification if the
service_typeisosd.NoteCustom OSD specification files should not have a full OSD specification.
The following is an example of a full OSD specification:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Custom OSD specification files should not have multiple YAML documents in the same file.
The following is an example of multiple YAML documents in the same file:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Configure OSD specifications with these requirements using the Red Hat Ceph Storage command line tools after the initial deployment of your environment. For more information, see Deploying Ceph OSDs using advanced service specifications in the Red Hat Ceph Storage Operations Guide.
- Save the specification file.
Deploy the specification:
openstack overcloud ceph deploy \ --osd-spec <osd_specification_file>Replace
<osd_specification_file>with the name of the specification file you created.$ openstack overcloud ceph deploy \ --osd-spec osd_spec.yaml \
Additional resources
For a list of OSD-related attributes used to configure OSDs in the service specification, see Advanced service specifications and filters for deploying OSDs in the Red Hat Ceph Storage Operations Guide.
4.5. Migrating from node-specific overrides Copy linkLink copied to clipboard!
Node-specific overrides were used to manage non-homogenous server hardware before Red Hat OpenStack Platform 17.0. This is now done with a custom OSD specification file. See Configuring advanced OSD specifications for information on how to create a custom OSD specification file.
4.6. Enabling Ceph on-wire encryption Copy linkLink copied to clipboard!
Enable encryption for all Ceph Storage traffic using the secure mode of the messenger version 2 protocol. Configure Ceph Storage as described in Encryption and Key Management in the Red Hat Ceph Storage Data Hardening Red Hat OpenStack Platform to enable Ceph on-wire encryption.
Additional resources
For more information about Ceph on-wire encryption, see Ceph on-wire encryption in the Red Hat Ceph Storage Architecture Guide.
Chapter 5. Customizing the storage service for HCI Copy linkLink copied to clipboard!
Red Hat OpenStack Platform (RHOSP) director provides the necessary heat templates and environment files to enable a basic Ceph Storage configuration.
Director uses the /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml environment file to add additional configuration to the Ceph cluster deployed by openstack overcloud ceph deploy.
For more information about containerized services in RHOSP, see Configuring a basic overcloud with the CLI tools in Installing and managing Red Hat OpenStack Platform with director.
5.1. Configuring Compute service resources for HCI Copy linkLink copied to clipboard!
Colocating Ceph OSD and Compute services on hyperconverged nodes risks resource contention between Red Hat Ceph Storage and Compute services. This occurs because the services are not aware of the colcation. Resource contention can result in service degradation, which offsets the benefits of hyperconvergence.
Configuring the resources used by the Compute service mitigates resource contention and improves HCI performance.
Procedure
- Log in to the undercloud host as the stack user.
Source the stackrc undercloud credentials file:
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Add the
NovaReservedHostMemoryparameter to theceph-overrides.yamlfile. The following is a usage example.parameter_defaults: ComputeHCIParameters: NovaReservedHostMemory: 75000parameter_defaults: ComputeHCIParameters: NovaReservedHostMemory: 75000Copy to Clipboard Copied! Toggle word wrap Toggle overflow
The NovaReservedHostMemory parameter overrides the default value of reserved_host_memory_mb in /etc/nova/nova.conf. This parameter is set to stop Nova scheduler giving memory, that a Ceph OSD needs, to a virtual machine.
The example above reserves 5 GB per OSD for 10 OSDs per host in addition to the default reserved memory for the hypervisor. In an IOPS-optimized cluster, you can improve performance by reserving more memory per OSD. The 5 GB number is provided as a starting point that you can further refine as necessary.
Include this file when you use the openstack overcloud deploy command.
5.2. Configuring a custom environment file Copy linkLink copied to clipboard!
Director applies basic, default settings to the deployed Red Hat Ceph Storage cluster. You must define additional configuration in a custom environment file.
Procedure
-
Log in to the undercloud as the
stackuser. Create a file to define the custom configuration.
vi /home/stack/templates/storage-config.yaml-
Add a
parameter_defaultssection to the file. Add the custom configuration parameters. For more information about parameter definitions, see Overcloud parameters.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteParameters defined in a custom configuration file override any corresponding default settings in
/usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml.- Save the file.
Additional resources
The custom configuration is applied during overcloud deployment.
5.3. Enabling Ceph Metadata Server Copy linkLink copied to clipboard!
The Ceph Metadata Server (MDS) runs the ceph-mds daemon. This daemon manages metadata related to files stored on CephFS. CephFS can be consumed natively or through the NFS protocol. By default, Ceph MDS is deployed on the Controller node. You can deploy Ceph MDS on its own dedicated node.
Red Hat supports deploying Ceph MDS with the native CephFS and CephFS NFS back ends for the Shared File Systems service (manila).
Procedure
To enable Ceph MDS, use the following environment file when you deploy the overcloud:
/usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yaml
/usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Additional resources
5.4. Ceph Object Gateway object storage Copy linkLink copied to clipboard!
The Ceph Object Gateway (RGW) provides an interface to access object storage capabilities within a Red Hat Ceph Storage cluster.
When you use director to deploy Ceph, director automatically enables RGW. This is a direct replacement for the Object Storage service (swift). Services that normally use the Object Storage service can use RGW instead without additional configuration. The Object Storage service remains available as an object storage option for upgraded Ceph clusters.
There is no requirement for a separate RGW environment file to enable it. For more information about environment files for other object storage options, see Section 5.5, “Deployment options for Red Hat OpenStack Platform object storage”.
By default, Ceph Storage allows 250 placement groups per Object Storage Daemon (OSD). When you enable RGW, Ceph Storage creates the following six additional pools required by RGW:
-
.rgw.root -
<zone_name>.rgw.control -
<zone_name>.rgw.meta -
<zone_name>.rgw.log -
<zone_name>.rgw.buckets.index -
<zone_name>.rgw.buckets.data
In your deployment, <zone_name> is replaced with the name of the zone to which the pools belong.
Additional resources
- For more information about RGW, see the Red Hat Ceph Storage Object Gateway Guide.
- For more information about using RGW instead of Swift, see the Backing up Block Storage volumes guide.
5.5. Deployment options for Red Hat OpenStack Platform object storage Copy linkLink copied to clipboard!
There are three options for deploying overcloud object storage:
Ceph Object Gateway (RGW)
To deploy RGW as described in Section 5.4, “Ceph Object Gateway object storage”, include the following environment file during overcloud deployment:
-e environments/cephadm/cephadm.yaml
-e environments/cephadm/cephadm.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow This environment file configures both Ceph block storage (RBD) and RGW.
Object Storage service (swift)
To deploy the Object Storage service (swift) instead of RGW, include the following environment file during overcloud deployment:
-e environments/cephadm/cephadm-rbd-only.yaml
-e environments/cephadm/cephadm-rbd-only.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow The
cephadm-rbd-only.yamlfile configures Ceph RBD but not RGW.NoteIf you used the Object Storage service (swift) before upgrading your Red Hat Ceph Storage cluster, you can continue to use the Object Storage service (swift) instead of RGW by replacing the
environments/ceph-ansible/ceph-ansible.yamlfile with theenvironments/cephadm/cephadm-rbd-only.yamlduring the upgrade. For more information, see Performing a minor update of Red Hat OpenStack Platform.Red Hat OpenStack Platform does not support migration from the Object Storage service (swift) to Ceph Object Gateway (RGW).
No object storage
To deploy Ceph with RBD but not with RGW or the Object Storage service (swift), include the following environment files during overcloud deployment:
-e environments/cephadm/cephadm-rbd-only.yaml -e environments/disable-swift.yaml
-e environments/cephadm/cephadm-rbd-only.yaml -e environments/disable-swift.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow The
cephadm-rbd-only.yamlfile configures RBD but not RGW. Thedisable-swift.yamlfile ensures that the Object Storage service (swift) does not deploy.
5.6. Configuring the Block Storage Backup Service to use Ceph Copy linkLink copied to clipboard!
The Block Storage Backup service (cinder-backup) is disabled by default. It must be enabled to use it with Ceph.
Procedure
To enable the Block Storage Backup service (cinder-backup), use the following environment file when you deploy the overcloud:
`/usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml`.
`/usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml`.
5.7. Configuring multiple bonded interfaces for Ceph nodes Copy linkLink copied to clipboard!
Use a bonded interface to combine multiple NICs and add redundancy to a network connection. If you have enough NICs on your Ceph nodes, you can create multiple bonded interfaces on each node to expand redundancy capability.
Use a bonded interface for each network connection the node requires. This provides both redundancy and a dedicated connection for each network.
See Provisioning the overcloud networks in the Installing and managing Red Hat OpenStack Platform with director guide for information and procedures.
5.8. Initiating overcloud deployment for HCI Copy linkLink copied to clipboard!
To implement the changes you made to your Red Hat OpenStack Platform (RHOSP) environment, you must deploy the overcloud.
Prerequisites
-
Before undercloud installation, set
generate_service_certificate=falsein theundercloud.conffile. Otherwise, you must configure SSL/TLS on the overcloud as described in Enabling SSL/TLS on overcloud public endpoints in the Hardening Red Hat OpenStack Platform.
If you want to add Ceph Dashboard during your overcloud deployment, see Adding the Red Hat Ceph Storage Dashboard to an overcloud deployment in Deploying Red Hat Ceph Storage and Red Hat OpenStack Platform together with director.
Procedure
Deploy the overcloud. The deployment command requires additional arguments, for example:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow The example command uses the following options:
-
--templates- Creates the overcloud from the default heat template collection,/usr/share/openstack-tripleo-heat-templates/. -
-r /home/stack/templates/roles_data_custom.yaml- Specifies a customized roles definition file. -
-e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/cephadm.yaml- Sets the director to finalize the previously deployed Ceph Storage cluster. This environment file deploys RGW by default. It also creates pools, keys, and daemons. -
-e /usr/share/openstack-tripleo-heat-templates/environments/cephadm/ceph-mds.yaml- Enables the Ceph Metadata Server. -
-e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml- Enables the Block Storage Backup service. -
-e /home/stack/templates/storage-config.yaml- Adds the environment file that contains your custom Ceph Storage configuration. -
-e /home/stack/templates/deployed-ceph.yaml- Adds the environment file that contains your Ceph cluster settings, as output by theopenstack overcloud ceph deploycommand run earlier. --ntp-server pool.ntp.org- Sets the NTP server.NoteFor a full list of options, run the
openstack help overcloud deploycommand.
-
Chapter 6. Verifying HCI configuration Copy linkLink copied to clipboard!
After deployment is complete, verify the HCI environment is properly configured.
6.1. Verifying HCI configuration Copy linkLink copied to clipboard!
After the deployment of the HCI environment, verify that the deployment was successful with the configuration specified.
Procedure
- Start a ceph shell.
Confirm NUMA and memory target configuration:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Confirm specific OSD configuration:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Confirm specific OSD backfill configuration:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Confirm the
reserved_host_memory_mbconfiguration on the Compute node.sudo podman exec -ti nova_compute /bin/bash bash-5.1$ grep reserved_host_memory_mb /etc/nova/nova.conf
$ sudo podman exec -ti nova_compute /bin/bash bash-5.1$ grep reserved_host_memory_mb /etc/nova/nova.confCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Chapter 7. Scaling hyperconverged nodes Copy linkLink copied to clipboard!
To scale HCI nodes up or down, the same principles and methods for scaling Compute nodes or Red Hat Ceph Storage nodes apply.
7.1. Scaling up hyperconverged nodes in HCI environments Copy linkLink copied to clipboard!
To scale up hyperconverged nodes in HCI environments follow the same procedure for scaling up non-hyperconverged nodes. For more information, see Adding nodes to the overcloud.
When you tag new nodes, remember to use the right flavor.
7.2. Scaling down hyperconverged nodes in HCI environments Copy linkLink copied to clipboard!
To scale down hyperconverged nodes in HCI environments you must rebalance the Ceph OSD services on the HCI node, migrate instances from the HCI nodes, and remove the Compute nodes from the overcloud.
If you are using director-deployed Red Hat Ceph Storage, it is important to understand the impact of replacing Controller nodes. The Ceph Monitor service runs on the Controller nodes and is typically assigned IP addresses from the Storage network. These Ceph Monitor service IP addresses are associated with VM instances where Red Hat Ceph Storage is used. They are not dynamically updated if the Ceph Monitor service IP address changes during replacement of the Controller node. This could result in a storage outage, especially if multiple Controller nodes are replaced. Each VM instance would have to be migrated, rebooted, or shelved and unshelved to resolve the IP address change and the resulting outage.
Reuse the IP addresses of the removed Ceph Monitor service instances instead of using new IP addresses to avoid this situation.
For an example, see the fixed_ip configuration example in Step 5 of Provisioning bare metal nodes for the overcloud.
Use the following command on a Controller node to find the current Ceph Monitor service IP addresses:
sudo cephadm shell -- ceph mon stat
$ sudo cephadm shell -- ceph mon stat
Procedure
- Disable and rebalance the Ceph OSD services on the HCI node. This step is necessary because director does not automatically rebalance the Red Hat Ceph Storage cluster when you remove HCI or Red Hat Ceph Storage nodes. For more information, see Scaling the Ceph Storage cluster in Deploying Red Hat Ceph Storage and Red Hat OpenStack Platform together with director for more information.
- Migrate the instances from the HCI nodes. For more information, see Migrating virtual machines between Compute nodes in the Configuring the Compute service for instance creation guide.
- Remove the Compute nodes from the overcloud. For more information, see Removing Compute nodes.
Appendix A. Additional information Copy linkLink copied to clipboard!
A.1. Configuration guidance Copy linkLink copied to clipboard!
The following configuration guidance is intended to provide a framework for creating Hyperconverged Infrastructure environments. This guidance is not intended to provide definitive configuration parameters for every Red Hat OpenStack Platform installation. Contact the Red Hat Customer Experience and Engagement team for specific guidance and suggestions that fit your specific environment.
A.1.1. Cluster sizing and scale out Copy linkLink copied to clipboard!
The Red Hat Ceph Storage Hardware Guide provides recommendations for IOPS optimized, throughput optimized, and cost and capacity optimized Ceph deployment scenarios. Follow the recommendation that best represents your deployment scenario and add the NICs, CPUs, and RAM required to support the Compute workload.
An optimal, small footprint configuration consists of seven nodes. Unless you have a requirement for IOPS optimized performance in your environment and you are using all flash storage, the throughput optimized deployment scenario should be used.
Three node Ceph Storage cluster configurations are possible. In this configuration, you should:
- use all flash storage.
-
set the
replica_countparameter to 3 in theceph.conffile. -
set the
min_sizeparameter to 2 in theceph.conffile.
If a node leaves service in this configuration, IOPS continue. To retain 3 copies of the data, replication to the third node is queued until it returns to service. Data is then backfilled to the third node.
HCI configurations of up to 64 nodes have been tested. Some HCI environment examples have been documented up to 128 nodes. Large clusters such as these can be considered with a Support Exception and Consulting Services engagement. Contact the Red Hat Customer Experience and Engagement team for guidance.
A deployment with two NUMA nodes can host a latency sensitive Compute workload on one NUMA node and Ceph OSDs services on the other. If there are network interfaces on both nodes, and the disk controllers are on node 0, use a network interface on node 0 for the Storage network and host the Ceph OSD workload on node 0. Host the Compute workload on node 1 and configure it to use the network interfaces on node 1. When acquiring hardware for your deployment, be mindful of which NICs will use which nodes and attempt to split them between storage and workload.
A.1.2. Capacity planning and sizing Copy linkLink copied to clipboard!
The throughput optimized Ceph solution defined in the Red Hat Ceph Storage Hardware Guide provides a balanced solution for most deployments that do not require optimization for IOPS. In addition to the configuration guidelines provided with the solution, note the following when creating your environment:
- The allotment of 5 GB of RAM per OSD ensures OSDs have sufficient operational memory. Ensure your hardware can support this requirement.
- CPU speed should match the storage medium in use. The advantages of faster storage mediums such as SSDs can be negated by CPUs too slow to support them. Similarly, a fast CPU can be more efficiently used by faster storage mediums. Balance CPU and storage medium speed so that neither becomes a bottleneck for the other.
A.2. Guides and resources for the configuration of your hyperconverged infrastructure environment Copy linkLink copied to clipboard!
The following guides contain additional information and procedures that can aid in the configuration of your hyperconverged infrastructure environment.
Deploying Red Hat Ceph and OpenStack together with director
- This guide provides information about using the Red Hat OpenStack Platform director to create an overcloud with a Red Hat Ceph Storage cluster. This includes instructions for customizing your Ceph cluster through the director.
Installing and managing Red Hat OpenStack Platform with director
- This guide provides guidance on the end-to-end deployment of a Red Hat OpenStack Platform environment. This includes installing the director, planning your environment, and creating an OpenStack environment with the director.
Configuring Red Hat OpenStack Platform networking
- This guide provides details on Red Hat OpenStack Platform networking tasks.
Configuring persistent storage
- This guide details the different procedures for using and managing persistent storage in a Red Hat OpenStack Platform environment. It also includes procedures for configuring and managing the respective OpenStack service of each persistent storage type.
Configuring the Bare Metal Provisioning service
- This guide provides details on the installation and configuration of the Bare Metal Provisioning service in the overcloud of a Red Hat OpenStack Platform environment to provision and manage physical machines for cloud users.
Hardening Red Hat OpenStack Platform
- This guide provides good practice advice and conceptual information about hardening the security of a Red Hat OpenStack Platform environment.
- This document outlines the major features, enhancements, and known issues in this release of Red Hat OpenStack Platform.