This guide shows how to configure and deploy NetApp ONTAP Cinder driver in a Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 control plane. After reading this, you’ll be able to define the proper environment files and deploy single or multiple ONTAP Cinder backends in RHOSO control plane.
Note
For more information about RHOSO, please refer to its documentation pages.
Warning
RHOSO 18.0 is based on OpenStack Antelope release. Features included after Antelope release are not available in RHOSO 18.0
In order to deploy NetApp Cinder back ends, you should have the following requirements satisfied:
NetApp ONTAP storage controllers deployed and ready to be used as Cinder back ends. See ONTAP Configuration for more details.
Deploy the RHOSO control plane on an OpenShift cluster configured with three master nodes and three worker nodes.
RHOSO control plane where Cinder services will be installed.
Ensure network connectivity between the storage backend, the Red Hat OpenShift cluster, and the Compute nodes.
Install the OpenStack Operator for Red Hat OpenStack Services on OpenShift (RHOSO), create a RHOSO control plane on a Red Hat OpenShift Container Platform cluster, and use the OpenStack Operator to deploy a RHOSO data plane.
To configure a single NetApp Cinder backend, Open your OpenStackControlPlane CR file, and add the following parameters to the cinder template.
openstack_control_plane.yaml
spec:
...
cinder:
template:
cinderAPI:
...
cinderScheduler:
...
cinderBackup:
...
cinderVolumes:
ontap-iscsi:
networkAttachments:
- storage
- storageMgmt
customServiceConfigSecrets:
- <secret_name>
customServiceConfig: |
[netapp-ontap-backend]
volume_backend_name=netapp-ontap-backend
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_protocol=iscsi
#Set above protocol to fcp in case of fcp backend
netapp_storage_family=ontap_cluster
consistencygroup_support = True
netapp_vserver=vs_iscsi_rhoso
netapp_server_port=80
max_over_subscription_ratio=1.0
reserved_percentage=5
netapp_driver_reports_provisioned_capacity = true
...
Refer the following example for NFS backend:
spec:
...
cinder:
template:
cinderAPI:
...
cinderScheduler:
...
cinderBackup:
...
extraMounts:
- extraVol:
- mounts:
- name: nfs-config-1
mountPath: /etc/cinder/nfs_shares
subPath: nfs_shares
readOnly: true
propagation:
- ontap-nfs
volumes:
- name: nfs-config-1
secret:
secretName: <config-secret-name>
cinderVolumes:
ontap-nfs:
networkAttachments:
- storage
- storageMgmt
customServiceConfigSecrets:
- <secret_name>
customServiceConfig: |
[ontap-nfs-backend]
volume_backend_name=ontap-nfs-backend
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_protocol=nfs
netapp_storage_family=ontap_cluster
consistencygroup_support = True
netapp_vserver=vs_cinder_nfs
nfs_shares_config = /etc/cinder/nfs_shares
nfs_mount_options = vers=4
...
Modify the parameter values according to your NetApp ONTAP backend configuration. Run “oc apply -f openstack_control_plane.yaml -n openstack” command to apply the changes.
Note
The section covering the secret associated with the customServiceConfigSecrets should precede applying the new control plane. The secret should be created prior to it being referenced in the control plane CRD
Note
Create a server connection secret for an alternative back end to prevent placing server connection information directly in the OpenStackControlPlane CR.
The following is an example of the contents of a configuration file:
[netapp-ontap-backend]
netapp_server_hostname = <netapp_ip>
netapp_login = <netapp_user>
netapp_password = <netapp_password>
netapp_vserver = <netappvserver>
Create the secret based on the configuration file: oc create secret generic <secret_name> –from-file=secret-config.yaml
Note
Cloud admin can provide the NFS export in file, create the required secret and use the OpenStackControlPlane CRD extraMounts feature to provide files to the openstack-cinder services.
The following is an example of the contents of secret creation
apiVersion: v1
kind: Secret
metadata:
name: <config-secret-name>
type: Opaque
stringData:
nfs_shares: |
<data-mgt-ip>:/<vol-junction-path>
Refer How to accessing extra files for the storage driver
See Configuration options for ONTAP with NFS (Antelope) and Configuration options for ONTAP with iSCSI (Antelope) and Configuration options for ONTAP with FCP (Antelope) for a complete list of the available Cinder Configuration Options.
If you are coming from an RHOSP-17.1 background, the following table maps each THT configuration parameter to the corresponding Cinder configuration option. The Cinder template in the OpenStackControlPlane CR uses only the Cinder configuration option parameters.
THT Parameter Name |
Cinder Configuration Option |
Required/Optional |
Description |
|---|---|---|---|
|
|
Required |
The name used by Cinder to refer to the Cinder backend. |
|
|
Required |
Administrative user account name used to access the storage system. |
|
|
Required |
Password for the administrative user account specified in the |
|
|
Required |
The hostname or IP address for the storage system or proxy server. The value of this option should be the IP address of the cluster management LIF. |
|
|
Optional |
The TCP port to use for communication with the storage system or proxy server. If not specified, ONTAP drivers will use 80 for HTTP and 443 for HTTPS. |
|
|
Required |
The storage family type used on the storage system; valid values are |
|
|
Required |
The storage protocol to be used. Valid options are |
|
|
Required |
Transport protocol for communicating with the storage system or proxy server. Valid options include |
|
|
Required |
This option specifies the storage virtual machine (previously called a Vserver) name on the storage cluster on which provisioning of block storage volumes should occur. |
|
|
Optional |
The file referenced by this configuration option will contain a list of NFS shares specified by |
|
|
Optional |
For NFS protocol only. Mount options passed to the nfs client. See section of the nfs man page for details. |
|
|
Optional |
For NFS protocol only. This option specifies the path of the NetApp copy offload tool binary. Ensure that the binary has execute permissions set which allow the effective user of the |
|
|
Optional |
This option defines the type of operating system for all initiators that can access a LUN. This information is used when mapping LUNs to individual hosts or groups of hosts. Default is ‘linux’. |
|
|
Optional |
This option is only utilized when the Cinder driver is configured to use iSCSI off Fibre Channel. It is used to restrict provisioning to the specified FlexVol volumes. Specify the value of this option as a regular expression which will be applied to the names of FlexVol volumes from the storage backend which represent pools in Cinder. |
|
|
Optional |
Availability zone for this volume backend. If not set, the storage_availability_zone option value is used as the default for all backends. |
Table 8.1. NetApp Cinder THT Configuration Parameters
In order to configure multiple NetApp Cinder backends, you need to define all of the backends on OpenStackControlPlane CR.
Open your OpenStackControlPlane CR file, openstack_control_plane.yaml, and add the following parameters to the cinder template to configure the multiple backends.
netapp-multi-backend.yaml
This file defines the multiple Cinder share backend
netapp-multi-iscsi-backend.yaml and its parameters.
spec:
...
cinder:
template:
cinderAPI:
...
cinderScheduler:
...
cinderBackup:
...
cinderVolumes:
ontap-iscsi-primary:
networkAttachments:
- storage
- storageMgmt
customServiceConfigSecrets:
- <secret_name>
customServiceConfig: |
[rhoso_netapp_iscsi_1]
volume_backend_name=rhoso_netapp_iscsi_1
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_protocol=iscsi
#Set above protocol to fcp in case of fcp backend
netapp_storage_family=ontap_cluster
consistencygroup_support = True
netapp_vserver=vs_iscsi_rhoso
netapp_server_port=80
max_over_subscription_ratio=1.0
reserved_percentage=5
netapp_driver_reports_provisioned_capacity = true
ontap-iscsi-sec::
networkAttachments:
- storage
- storageMgmt
customServiceConfigSecrets:
- <secret_name>
customServiceConfig: |
[rhoso_netapp_iscsi_2]
volume_backend_name=rhoso_netapp_iscsi_2
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_protocol=iscsi
#Set above protocol to fcp in case of fcp backend
netapp_storage_family=ontap_cluster
consistencygroup_support = True
netapp_vserver=vs_iscsi_rhoso_sec
netapp_server_port=80
max_over_subscription_ratio=1.0
reserved_percentage=5
use_multipath_for_image_xfer=True
netapp_driver_reports_provisioned_capacity = true
...
Refer the following example for NFS multi backends:
spec:
...
cinder:
template:
cinderAPI:
...
cinderScheduler:
...
cinderBackup:
...
extraMounts:
- extraVol:
- mounts:
- name: nfs-config-1
mountPath: /etc/cinder/nfs_shares
subPath: nfs_shares
readOnly: true
propagation:
- rhoso_netapp_nfs_1
volumes:
- name: nfs-config-1
secret:
secretName: <config-secret-name>
- extraVol:
- mounts:
- name: nfs-config-2
mountPath: /etc/cinder/nfs_shares
subPath: nfs_shares
readOnly: true
propagation:
- rhoso_netapp_nfs_2
volumes:
- name: nfs-config-2
secret:
secretName: <config-secret-name>
cinderVolumes:
ontap-nfs-primary:
networkAttachments:
- storage
- storageMgmt
customServiceConfigSecrets:
- <secret_name>
customServiceConfig: |
[rhoso_netapp_nfs_1]
volume_backend_name=rhoso_netapp_nfs_1
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_protocol=nfs
netapp_storage_family=ontap_cluster
consistencygroup_support = True
netapp_vserver=vs_cinder_nfs_1
nfs_shares_config = /etc/cinder/nfs_shares
nfs_mount_options = vers=4
ontap-nfs-sec::
networkAttachments:
- storage
- storageMgmt
customServiceConfigSecrets:
- <secret_name>
customServiceConfig: |
[rhoso_netapp_nfs_2]
volume_backend_name=rhoso_netapp_nfs_2
volume_driver=cinder.volume.drivers.netapp.common.NetAppDriver
netapp_storage_protocol=nfs
netapp_storage_family=ontap_cluster
consistencygroup_support = True
netapp_vserver=vs_cinder_nfs_2
nfs_shares_config = /etc/cinder/nfs_shares
nfs_mount_options = vers=4
...
Modify the parameter values according to your NetApp ONTAP backend configuration.
Run “oc apply -f openstack_control_plane.yaml -n openstack” command to apply the changes or edit the OpenStackControlPlane CR file.
Wait until RHOSO creates the cinder volume pod, run “oc get openstackcontrolplane -n openstack” command to check the status.
Note
Each back end needs its own secret. The cloud admin must create a separate secret for each back end.
After RHOSO openstackcontrolplane is deployed, run the following command to check if the Cinder services are up. Creating the control plane also creates an OpenStackClient pod that you can access through a remote shell (rsh) to run OpenStack CLI commands.
[root@rhel92-rhosp ~]# oc rsh openstackclient
sh-5.1$ openstack service list
Create the volume types mapped to the deployed back ends:
sh-5.1$ openstack volume type create rhoso_netapp_nfs_1
sh-5.1$ openstack volume type set rhoso_netapp_nfs_1 --property volume_backend_name=ontap-primary-backend
sh-5.1$ openstack volume type create rhoso_netapp_nfs_2
sh-5.1$ openstack volume type set rhoso_netapp_nfs_2 --property volume_backend_name=ontap-sec-backend
sh-5.1$ openstack volume type create rhoso_netapp_iscsi_1
sh-5.1$ openstack volume type set rhoso_netapp_iscsi_1 --property volume_backend_name=ontap-primary-backend
sh-5.1$ openstack volume type create rhoso_netapp_fc_1
sh-5.1$ openstack volume type set rhoso_netapp_fc_1 --property volume_backend_name=ontap-sec-backend
Make sure that you’re able to create Cinder volumes with the configured volume types:
sh-5.1$ openstack volume create --type rhoso_netapp_nfs_1 --size 1 rhoso_volume_nfs_1
sh-5.1$ openstack volume create --type rhoso_netapp_nfs_2 --size 1 rhoso_volume_nfs_2
sh-5.1$ openstack volume create --type rhoso_netapp_iscsi_1 --size 1 rhoso_volume_iscsi_1
sh-5.1$ openstack volume create --type rhoso_netapp_fc_1 --size 1 rhoso_volume_fc_1
This document is licensed under Apache 2.0 license.