Red Hat OpenStack Platform 17.1 with Dell PowerFlex
Executive summary
Overview
Audience
Terminology
We value your feedback
Product Overview
Product overview
PowerFlex family
PowerFlex software-defined infrastructure enables broad consolidation across the data center, encompassing almost any type of workload and architecture. The software-defined architecture offers automation and programmability of the complete infrastructure and provides scalability, performance, and resiliency to enable effortless adherence to stringent workload SLAs.
The PowerFlex family provides a foundation that combines compute and high-performance storage resources in a managed unified fabric. PowerFlex comes in flexible deployment options (rack, appliance, or custom nodes and in the public cloud) that enables independent (two-layer), HCI (single-layer), or mixed architectures. PowerFlex is ideal for high-performance applications and databases, building an agile private/hybrid cloud, or consolidating resources in heterogeneous environments.
Figure 1. PowerFlex family
PowerFlex software components
PowerFlex with NVMe over TCP (NVMe/TCP)
NVMe is a family of open specifications that defines an industry standard for both a logical interface and a communication protocol for accessing block storage across an internal PCIe fabric or through external fabrics such as TCP/IP and FC. NVMe is designed to take advantage of the internal parallelism and low latency inherent in flash-based media SSDs.
NVMe/TCP is an extension of the NVMe base specification that defines the binding of the NVMe protocol to message-based fabrics using TCP. By binding the NVMe protocol to TCP, NVMe/TCP enables the efficient end-to-end transfer of commands and data between NVMe hosts and NVMe controller devices by any standard Ethernet-based TCP/IP networks.
Figure 2. PowerFlex with NVMe/TCP
From PowerFlex release 4.x, support for NVMe/TCP has been added for on-premises deployment with the introduction of a new Storage Data Target (SDT) component installed in the storage layer. The NVMe initiator in the operating system or hypervisor communicates with the SDT, which then communicates with the Storage Data Server (SDS). The NVMe initiator is part of the kernel of the application host operating system or hypervisor.
For more information, see PowerFlex with NVMe over TCP.
PowerFlex deployment architectures
PowerFlex software-defined infrastructure excels in deployment flexibility. PowerFlex can be deployed in a two-layer (independent compute and storage layers), single-layer (hyperconverged Infrastructure, or HCI), or a mixture of the two architectures (mixed).
Figure 3. PowerFlex deployment architectures
PowerFlex consumption options
PowerFlex CSI/CSM
Red Hat Enterprise Linux
Red Hat OpenStack Platform 17.1
OpenStack components
RHOSP uses Red Hat OpenStack Platform Director as the toolset for installing and managing an OpenStack environment. The deployment includes the concept of undercloud and overcloud, which forms the entire OpenStack platform.
Undercloud (director)
The director node is installed as a RHEL VM and is the main management node that contains the RHOSP director toolset. The director is installed on the undercloud VM and acts as a single point for the installation, configuration, and management of the OpenStack environment (overcloud).
Figure 5. Red Hat OpenStack Platform Block diagram
The key functions of the undercloud are:
- RHOSP services: The undercloud uses RHOSP service components as its base tool set. Each service operates within a separate container on the undercloud.
- Environment planning: The undercloud helps in planning your overcloud environment and tag nodes to appropriate clusters of controller and compute nodes, and allows custom roles.
- Bare metal system control: The undercloud inspects each node and discovers its hardware attributes using an OOB network to communicate to IPMI and PXE controls.
- Orchestration: The undercloud provides a set of yaml templates and allows customization by allowing us to pass environment files during overcloud deployment.
Overcloud
The overcloud is the resulting Red Hat OpenStack environment that is created by the undercloud. The solution described in this document deploys a cluster of controller and compute nodes. All customizations are passed as yaml files during the deployment to create the final overcloud environment. Pacemaker acts as the cluster resources manager and provides high availability (HA) to all the OpenStack controller nodes in the cluster. A Cinder container in the overcloud controller is responsible for communicating with the backend PowerFlex.
Controller node
A controller node is responsible for providing key services for administering, managing, and upgrading the RHOSP overcloud environment. This controller node provides various services, such as dashboard (Horizon), authentication (Keystone), image storage (Glance), networking (Neutron), orchestration (Heat), and HA.
Compute node
A compute node is a part of every OpenStack overcloud deployment, providing compute services (Nova) to host VM instances running on a Red Hat hypervisor. Each compute node runs KVM/QEMU, Open vSwitch, OpenStack Telemetry, and other services.
Chapter 3 Deployment considerations
Deployment considerations
Overview
Node considerations
Planning node deployment roles
Network planning
Storage planning
Architecture overview
Introduction
Logical architecture
The following figure provides an overview of the logical architecture of RHOSP 17.1 on PowerFlex:
Figure 6. Logical architecture
The undercloud VM is the component that is used to deploy overcloud nodes. RHEL 9.2 is the base operating system for all the RHOSP components, including the undercloud and overcloud nodes. This solution deployed two different profiles for overcloud nodes:
- Controller VMs: Three PowerEdge servers are configured with RHOSP controller profile. PowerFlex SDC is installed on each node, helping the cinder driver to communicate with PowerFlex.
- Compute nodes: Three servers are configured with RHOSP compute profile and installed SDC on each node. These nodes are responsible for hosting the customer workloads.
In this solution, PowerFlex Manger acts as the REST API gateway that communicates with the MDM component in the PowerFlex cluster.
PowerFlex Manager deploys the PowerFlex storage-only (SO) cluster on four bare metal servers. The PowerFlex storage cluster consists of the MDM, SDS, and LIA components. A single PowerFlex protection domain with multiple storage pools is configured on PowerFlex. The PowerFlex storage pool topology consists of four SO nodes with 10 SSD disks in each of the four SO nodes in the PowerFlex system.
Cinder on the overcloud controller nodes communicates using the PowerFlex Manager IP address for storage operations. From OpenStack, volumes are created, deleted, or mounted to the VMs which are running on OpenStack compute nodes.
Network architecture
The following diagram shows the network architecture of this solution.
Figure 7. Network design of RHOSP with Dell PowerFlex
At the physical layer, two supported TOR switches are used for redundancy and load-balancing purposes. A peer link is configured on both the TOR switches.
Each PowerFlex storage-only node is connected to the TOR switches. The network ports are trunked with the TOR switches. The NICs handle management, data1, data2, data3, and data4 network traffic for PowerFlex. The management network operates in active-backup (mode1) bonding with the data1 and data2 networks, while the data3 and data4 networks are dedicated to the SDS network and are not bonded. This network configuration provides redundancy and fault tolerance, with two dedicated networks for PowerFlex data transfer. Dedicated VLANs are used to separate management and data network traffic.
The following table shows the different VLANs that are used for PowerFlex SO nodes and their purposes:
Table 5. Network details for PowerFlex storage-only nodes
|
Network type |
Configuration |
|
Management |
Mode1 bond - (interface1 port1 and interface2 port1) |
|
PowerFlex Data 1 |
interface1 port1 |
|
PowerFlex Data 2 |
Interface2 port1 |
|
PowerFlex Data 3 |
Interface1 port2 |
|
PowerFlex Data 4 |
Interface2 port2 |
Each overcloud node is connected to the TOR switches. The OpenStack network is configured as follows in this solution:
- Interface1 port1: Configured with an OpenStack provision/control plane network as a native VLAN. This network is used for pxe booting during provisioning and in deploying overcloud, as explained in Chapter 5 RHOSP Deployment.
- Interface2 port2: OpenStack networks are separated with different VLANs and are trunked at the TOR switches. The virtual bridge network configuration environment file is used to allow all the networks.
Note: See the sample network configuration files YAML files for provisioning overcloud network resources and YAML files for provisioning bare metal nodes.
The following table shows the network details of the RHOSP used in this solution:
Table 6. RHOSP network and its subnet
|
Network type |
Subnet used |
Configuration |
|
Provisioning and Control plane (used for PXE) |
192.168.105.0/24 |
Interface1 port1 (configured as native VLAN is for PXE booting).
|
|
Other OpenStack networks:
|
|
Bridge – interface2 port1 Associated with the virtual bridge which carries different VLANs for respective networks such as internal API, Tenant, Storage, External, and so on. This network is created automatically during the overcloud deployment using network environment files. |
Note: The external network must have Internet connectivity and should be reachable for undercloud.
- The PowerFlex data1 network is configured on interface 1 port 2, while the data2 network is configured on interface 2 port 2 of the overcloud nodes. Data networks are not teamed, and they carry dedicated SDS-SDC traffic. Data networks are used for communication between PowerFlex compute and storage nodes.
For information about network configuration in an OpenStack environment, see Network planning.
RHOSP deployment
Overview
Director (undercloud) installation
Provisioning overcloud
Provisioning the overcloud networks
RHOSP provides isolated overcloud networks so that the user can host specific types of network traffic in isolation.
For more information about the networks, see Network planning.
To configure the network resources for the RHOSP physical network environment, perform the following tasks:
- Configure and provision the network resources for overcloud.
- Configure and provision the network Virtual IPs for overcloud.
Configuring and provisioning overcloud network definitions
Configure the physical network for overcloud in a YAML-format network definition file. The provisioning process creates a heat environment file from the network definition file that contains network specifications. During overcloud deployment, this heat environment file is included in the deployment command.
Perform the following steps:
- Initialize stackrc.
[stack@director ~] $ source ~/stackrc
- Copy the sample network definition template from /usr/share/openstack-tripleo-heat-templates/network-data-samples to the environment file directory:
(undercloud) [stack@director ~] $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network-data.yaml
- Edit the network-data.yaml file according to the environment requirements. This file holds the information about the list of networks and its details. Here is a sample file for one network:
- name: External
name_lower: external
vip: true
mtu: 1500
subnets:
external_subnet:
ip_subnet: 10.x.x.x/x
allocation_pools:
- start: 10.x.x.x
end: 10.x.x.x
gateway_ip: 10.x.x.x
vlan: xx
For examples of customized network environment files, see network-data.yaml.
- Configure any other networks and attributes to suit the environment. For more information about the properties used to configure network attributes in the network definition file, see creating the network definition file.
- To provision the overcloud network, run the following command:
(undercloud) [stack@director ~]$ openstack overcloud network provision \
--output <deployment_file> \
/home/stack/templates/<networks_definition_file>
Where:
- deployment_file is the name of the heat environment file to generate for inclusion in the deployment command, for example, /home/stack/templates/overcloud-networks-deployed.yaml
- networks_definition_file is the name of the networks definition file, for example, network-data.yaml
- When network provisioning is completed, run the following command to verify the created networks and subnets:
(undercloud) [stack@director ~]$ openstack network list
(undercloud) [stack@director ~]$ openstack subnet list
Figure 8. Provisioned network and its subnet list
(undercloud) [stack@director ~]$ openstack network show <network>
(undercloud) [stack@director ~]$ openstack subnet show <subnet>
Configuring and provisioning network VIPs for the overcloud
Configure the network Virtual IPs (VIPs) for overcloud in a YAML-format network VIP definition file. The provisioning process creates a heat environment file from the VIP definition file that contains VIP specifications. This heat environment file is used in the deployment command for the overcloud.
Perform the following steps:
- Initialize stackrc:
[stack@director ~]$ source ~/stackrc
- Copy the sample network VIP definition template from /usr/share/openstack-tripleo-heat-templates/network-data-samples to the environment file directory:
(undercloud) [stack@director ~]$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/ vip-data-default-network-isolation.yaml /home/stack/templates/vip-data.yaml
- Edit the vip-data.yaml file in accordance to with the environment requirements, as shown in the following code snippet:
- network: <network>
dns_name: <dns_name>
name: <vip_name>
ip_address: <vip_address>
subnet: <subnet>
Where:
- <network> is the name of the network where the IP address is allocated, for example, internal_api or storage.
- <dns_name> is the optional FQDN ,for example, overcloud.
- <vip_name> is the optional VIP name.
- <vip_address> is the optional virtual IP address for the network.
- <subnet> is the optional name of the subnet to use when creating the virtual IP port. This name is required for routed networks.
For sample customized network environment files, see vip-data.yaml.
For more information about the properties that are used to configure network VIP attributes in the network VIP definition file, see creating the network VIP definition file.
- To provision the network VIP, run the following command:
(undercloud) [stack@director ~]$ openstack overcloud network vip provision \
--stack <stack> \
--output <deployment_file> \
/home/stack/templates/<vip_definition_file>
Where-
- <stack> is the name of the stack for which the network VIPs are provisioned, for example, overcloud.
- <deployment_file> is the name of the heat environment file to generate for inclusion in the deployment command, for example /home/stack/templates/overcloud-vip-deployed.yaml.
- <vip_definition_file> is the name of VIP definition file, for example, vip_data.yaml.
- When network VIP provisioning is completed, run the following command to verify created VIPs.
(undercloud) [stack@director ~]$ openstack port list
Figure 9. Provisioned network VIP list
- Run the following command to view details of a specific port:
(undercloud) [stack@director ~]$ openstack port show <port>
Provision bare metal overcloud nodes
This solution uses bare metal for the overcloud deployment. To configure an RHOSP environment, you must:
- Register the bare metal nodes for overcloud.
- Provide the director with a hardware inventory of the bare metal nodes.
- Configure the quantity, attributes, and network layout of the bare metal nodes in a node definition file.
- Assign an appropriate resource class to each bare metal node to match its designated role.
Registering bare metal nodes for the overcloud
The director requires a node definition template, which must be created in json or yaml format. This file contains the hardware and power management details of the overcloud nodes. See nodes.json for an example file. For information about creating a json file, see baremetal node json.
Perform the following steps:
- Initialize stackrc:
[stack@director ~]$ source ~/stackrc
- Create and save a template to stack the user’s home directory (/home/stack/<filename>.json) and verify the formatting and syntax:
(undercloud) [stack@director ~]$ openstack overcloud node import --validate-only ~/<filename>.json
- Import the bare metal node template into the director to register each node inthe director:
(undercloud) [stack@director ~]$ openstack overcloud node import ~/<filename>.json
- When the node registration and configuration are complete, verify that the director has successfully registered the nodes:
(undercloud) [stack@director ~]$ openstack baremetal node list
Figure 10. Registered bare metal node list
Prepare the hardware inventory of the bare metal nodes
The director needs the hardware inventory of the nodes in the RHOSP deployment for profile tagging, benchmarking, and manual root disk assignment.
This solution uses an automatic introspection process to collect the hardware information of each node. This process causes each node to boot an introspection agent over PXE, which collects hardware data from the node and then sends it back to the director. The director stores the hardware data in the OpenStack internal database.
Perform the following steps:
- Initialize stackrc:
[stack@director ~]$ source ~/stackrc
- Run the pre-introspection validation group to check the introspection requirements:
(undercloud) [stack@director ~]$ validation run --group pre-introspection --inventory <inventory_file>
Where:
<inventory_file> is the name and location of the Ansible inventory file, for example, ~/tripleo-deploy/undercloud/tripleo-ansible-inventory.yaml.
- Review the results of the validation report:
(undercloud) [stack@director ~]$ validation history show
(undercloud) [stack@director ~]$ validation history get --full <UUID>
Note: A FAILED validation does not prevent deploying or running Red Hat OpenStack Platform, but it can indicate a potential issue with the environment.
- Run introspection on all the nodes together:
(undercloud) [stack@director ~]$ openstack overcloud node introspect --all-manageable -–provide
Where:
- The all-manageable option introspects only nodes in a managed state.
- The provide option resets all nodes to an available state after introspection
- Introspect one node at a time.
- Move the node into the manage state:
(undercloud) [stack@director ~]$ openstack baremetal node manage [NODE UUID]
where the node UUID can be recorded using the OpenStack baremetal node list command - Run the introspection process on the specific node:
(undercloud) [stack@director ~]$ openstack overcloud node introspect --provide [NODE UUID]
- Monitor the progress of the introspection in a separate terminal window using the following commands.
- For the introspection process:
(undercloud) [stack@director ~]$ sudo tail -f /var/log/containers/ironic-inspector/ironic-inspector.log - For information about low-level commands such as iDRAC operations:
(undercloud) [stack@director ~]$ sudo tail -f /var/log/containers/ironic/ironic-conductor.log - For information about DHCPOFFER/DHCPREQUEST/DHCPACK requests
(undercloud) [stack@director ~]$ sudo tail -f /var/log/containers/ironic-inspector/dnsmasq.log
- Review the introspection information about the node:
(undercloud) [stack@director ~]$ openstack baremetal introspection data save <UUID> | jq . > <filename>
- Review the network interface details:
(undercloud) [stack@director ~]$ openstack baremetal introspection interface list [NODE UUID]
(undercloud) [stack@director ~]$ openstack baremetal introspection interface show [NODE UUID] [INTERFACE]
- Retrieve RAM, CPU, and NIC information about the nodes:
(undercloud) [stack@director ~]$ openstack baremetal introspection data save UUID | jq .numa_topology
Provisioning the bare metal nodes
The provisioning process creates a heat environment file from the node definition file. The heat environment file contains the node specifications that are configured in the node definition file, including node count, predictive node placement, custom images, and custom NICs. The process also provisions the port resources for all networks that are defined for each node or role in the node definition file. During overcloud deployment, this heat environment file is incorporated into the deployment command.
Perform the following steps:
- Initialize stackrc:
[stack@director ~]$ source ~/stackrc
- Create the overcloud-baremetal-deploy.yaml node definition file and define the node count and other attributes for each role to provision. This solution uses the following sample files:
- Node definition file: Overcloud-baremetal-deploy.yaml
- NIC template/network layout in Jinja2 templates: controller.j2 and compute.j2
- The first NIC is responsible for PXE (for provisioning) and control plane and network access.
- The second NIC will carry VLAN traffic for all networks.
For more information about network configuration, see Network planning.
Note: Use the template in /usr/share/ansible/roles/tripleo_network_config/templates to create your own NIC templates.
- Provision the overcloud nodes using the node definition file:
(undercloud) [stack@director ~]$ openstack overcloud node provision \
--stack <stack> \
--network-config \
--output <deployment_file> \
/home/stack/templates/<node_definition_file>
Where:
- <stack>:is the name of the stack for which the bare-metal nodes are provisioned. If not specified, the default is overcloud.
- The --network-config optional argument is included to provide the network definitions to the cli-overcloud-node-network-config.yaml Ansible playbook. If you do not use --network-config to provide the network definitions, you must configure the {{role.name}}NetworkConfigTemplate parameters in the network-environment.yaml file; otherwise the default network definitions are used.
- <deployment_file> is the name of the heat environment file to generate the deployment command, for example, /home/stack/templates/overcloud-baremetal-deployed.yaml.
- <node_definition_file> is the name of the node definition file, for example, overcloud-baremetal-deploy.yaml
- Monitor the provisioning progress in a separate terminal:
(undercloud) [stack@director ~]$ watch openstack baremetal node list
When provisioning is successful, the node state changes from available to active.
If the node provisioning fails because of a node hardware or network configuration failure, remove the failed node before running the provisioning step again. For more information, see Removing failed bare-metal nodes from the node definition file.
- View unified view of nodes including allocations and ports using the metalsmith tool:
(undercloud) [stack@director ~]$ metalsmith list
Figure 11. Provisioned node list
- Verify the association of hostnames in line with the node definition file:
(undercloud) [stack@director ~]$ openstack baremetal allocation list
Designate the overcloud nodes for specific roles by using custom resource classes or the profile capability. For more information, see the following documentation:
Configuring and deploying overcloud
Post deployment operations
Overcloud deployment validation
Validation steps
Perform the following steps:
- Verify overcloud status: Run the deployment status command:
(undercloud) [stack@director ~]$ openstack overcloud status
Figure 12. Overcloud deployment status
- Access overcloud: The director generates a script to configure and help authenticate interactions with the overcloud from the director host. The director saves this file, overcloudrc, into the stack users’ home directory.
- Run the following command to source the overcloud RC file.
(undercloud) [stack@director ~]$ source ~/overcloudrc
(overcloud) [stack@director ~]$
This command loads the necessary environment variables to interact with the overcloud from the director host’s CLI.
- List all the available endpoints:
(overcloud) [stack@director ~]$ openstack endpoint list
Figure 13. Endpoint list
- Find the IP address of the overcloud node and make a note of it:
(undercloud) [stack@director ~]$ openstack hypervisor list
Figure 14. Compute server list
- Connect overcloud nodes: Each node in the overcloud also contains a user called tripleo-admin. The undercloud ‘stack’ user has SSH access to this user on each node.
- Connect the node using the tripleo-admin user and the node’s IP address:
(undercloud) [stack@director ~]$ ssh tripleo-admin@<controller/compute-ip>
- Query the OpenStack cluster from the controller and ensure that the cluster is in good health:
[tripleo-admin@overcloud-controller-0 ~]$ sudo pcs status
- Verify cinder configuration: Verify that the cinder.conf file on the controller VM contains all the required PowerFlex information from cinder.yaml, or whether the user can verify the contents of /etc/cinder/cinder.conf in the controller VM: /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
For example:
[DEFAULT]
enabled_backends = tripleo_dellemc_powerflex
[tripleo_dellemc_powerflex]
Backend_host=hostgroup
Volume_driver=cinder.volume.drivers.dell_emc.powerflex.driver.PowerFlexDriver
san_login=<login>
san_password=<password>
san_ip=<Powerflex Manager IP>
powerflex_storage_pools=Domain1:Pool1,Domain2:Pool2
volume_backend_name= tripleo_dellemc_powerflex
san_thin_provision=True
……
- If the cinder.conf file has not yet been updated, manually update it and then restart the cinder containers:
Make changes in /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
Restart the service:
[tripleo-admin@overcloud-controller-0 ~]$ sudo podman ps | grep cinder
[tripleo-admin@overcloud-controller-0 ~]$ sudo podman restart <cinder_container_ID>
For more information about the cinder configuration file for PowerFlex, see Dell PowerFlex Backend Deployment Guide for RHOSP 17.1.
Install the PowerFlex SDC package
Install and configure the SDC package on all controller and compute nodes. This is necessary for the Glance and Nova services to expose PowerFlex volumes as block devices to the application that resides on the SDC server.
Perform the following steps:
- Before proceeding with the SDC installation, ensure that the PowerFlex data1 and data2 networks have been configured.
- Copy the PowerFlex SDC and LIA packages onto both the controller and compute nodes and install them:
$ MDM_IP=<IPaddress> rpm -ivh EMC-ScaleIO-sdc-<build_version>.x86_64
$ TOKEN=<password> rpm -ivh EMC-ScaleIO-lia-<build_version>.x86_64
- Verify that the SDC is up and running. To do this:
- Log in to the primary MDM and query all SDCs. The MDM lists all the overcloud nodes on which you have installed the SDC. Verify the connectivity and availability@
$ scli --login --management_system_ip <powerflex_manager_ip> --username admin --password <password>
$ scli --query_all_sdc
Alternatively:
- Log in to the PowerFlex Manager UI. Go to Block --> Hosts and verify that the overcloud nodes are listed.
Figure 15. SDC list
- Connector configuration: Before using attach/detach volume operations, ensure that the PowerFlex connector is configured. On each node where PowerFlex SDC is installed:
- Create /opt/emc/scaleio/openstack/connector.conf if it does not exist:
$ mkdir -p /opt/emc/scaleio/openstack
$ touch /opt/emc/scaleio/openstack/connector
- For each PowerFlex backend section in cinder.conf, create the same section in /opt/emc/scaleio/openstack/connector.conf and populate it with passwords. For example:
[tripleo_dellemc_powerflex]
san_password = POWERFLEX_PASSWD
replicating_san_password = REPLICATION_SYSTEM_POWERFLEX_PASSWD # if applicable
[tripleo_dellemc_powerflex]
san_password = POWERFLEX_PASSWD
replicating_san_password = REPLICATION_SYSTEM_POWERFLEX_PASSWD # if applicable
Note: To apply the changes, you will need to reboot each node on which the SDC kernel module (scini) runs.
Verify Horizon access
Creating a volume type
To configure OpenStack to point to the newly configured cinder backend:
- Create a new cinder volume type. These volumes will be mapped to the set of capabilities of the storage back-end driver. To do this:
- Log in to Horizon using the admin credentials you obtained in Verify Horizon access.
- Click the Admin tab on the top left side and select Volume Type from the Volume drop-down menu.
- Select Create Volume Type.
- Update the name and description details, and then click Create Volume Type.
Figure 16. Create volume type
- Create the extra specs parameter for newly created volumes. To do this:
- Select new volume type > View Extra Specs from the drop-down menu.
Figure 17. Add extra specs
- Click Create and update the value of the volume_backend_name key. Ensure that this value is same as the volume backend name that is specified in the cinder configuration file.
Figure 18. Volume Type Extra Spec: volume backend
- Verify that the extra specs have been created properly.
Note: For information about command-line operations ,see RHOSP 17.1 Command line interface reference and Block Storage Service(cinder) CLI .
For overcloud post installation tasks, see Performing Overcloud Post-installation Tasks.
Solution validation
Solution validation
Testing Cinder operations
The Cinder driver is designed and tested to work with PowerFlex as storage backend. Perform the following steps for PowerFlex volume creation from OpenStack Horizon.
- Log in to Horizon using the admin credentials.
- On the Project tab, click Volume.
- Select Create Volume and update the following fields as required: Volume Name, Description, Volume Source, Type (select Creating Volume Type), Size (in multiples of 8 GB), and Availability Zone (select Nova). Click Create Volume.
- Verify that the new volume is displayed in the PowerFlex presentation server UI under Volume and that:
- Users can perform operations such as attach/detach volume to an instance.
- User can create multiple volumes for different projects.
Figure 19. List of volumes created from different projects.
For more information, see Cinder Administration.
Table 7. Validated cinder functionality with PowerFlex
|
Features/Functions |
Dell PowerFlex |
|
Create/delete volume |
Yes |
|
attach/detach volume |
Yes |
|
Extend/resize volume |
Yes |
|
Create/delete & attach/detach snapshot |
Yes |
|
Create volume from snapshot |
Yes |
|
Create boot volume/snapshot from boot volume |
Yes |
|
Create volume from volume |
Yes |
|
Create image from volume |
Yes |
|
Extend an Attached Volume |
Yes |
|
Thin & thick provisioning |
Yes |
|
Volume migration |
Yes |
|
Multi-Attach Support |
Yes |
Note: To verify Nova, Glance, or operations related to any other OpenStack service using the Horizon dashboard, see OpenStack Dashboard User Documentation.