Theory of Operation: Storage Service Catalog and Cinder Volume Types¶

The Storage Service Catalog (SSC) is a concept that describes a set of capabilities that enables efficient, repeated, and consistent use and management of storage resources by the definition of policy-based services and the mapping of those services to the backend storage technology. It is meant to abstract away the actual technical implementations of the features at a storage backend into a set of simplified configuration options.

Important

For the complete list of features supported by NetApp drivers, refer to the Cinder Driver Support Matrix

The storage features are organized or combined into groups based on the customer needs to achieve a particular scenario or use case. Based on the catalog of the storage features, intelligent provisioning decisions are made by infrastructure or software enabling the storage service catalog. In OpenStack, this is achieved together by the Cinder filter scheduler and the NetApp driver by making use of volume type extra-specs support together with the filter scheduler. There are some prominent features which are exposed in the NetApp driver including mirroring, deduplication, compression, and thin provisioning.

When the NetApp driver is used with ONTAP systems, you can leverage extra specs with Cinder volume types to ensure that Cinder volumes are created on storage backends that have certain properties (e.g. QoS, mirroring, compression) configured.

Extra specs are associated with Cinder volume types, so that when users request volumes of a particular volume type, they are created on storage backends that meet the list of requirements (e.g. available space, extra specs, etc). You can use the specs in Table 4.11, “NetApp supported Extra Specs for use with Cinder volume Types” below when defining Cinder volume types with the cinder type-key command.

Extra spec	Type	Products Supported	Description
`netapp_aggregate`	String	ONTAP	Limit the candidate volume list to only the ones on a specific aggregate.
`netapp_raid_type`	String	ONTAP	Limit the candidate volume list based on one of the following raid types: `raid4`, `raid6` and `raid_dp`.
`netapp_disk_type`	String	ONTAP	Limit the candidate volume list based on one of the following disk types: `ATA`, `BSAS`, `EATA`, `FCAL`, `FSAS`, `LUN`, `MSATA`, `SAS`, `SATA`, `SCSI`, `XATA`, `XSAS`, or `SSD`.
`netapp_hybrid_aggregate`	Boolean	ONTAP	Limit the candidate volume list to only those on hybrid aggregates.
`netapp:qos_policy_group` [2]	String	ONTAP	Specify the name of a QoS policy group, which defines measurable Service Level Objectives (SLO), that should be applied to the Cinder volume at the time of volume creation. Ensure that the QoS policy group is defined within ONTAP before a Cinder volume is created. The QoS policy group specified will be shared among all Cinder volumes whose volume types reference the policy group in their extra specs. Since the SLO is shared with multiple Cinder volumes, the QoS policy group should not be associated with the destination FlexVol volume. If you want to apply an SLO uniquely on a per Cinder volume basis use Cinder backend QoS specs. See Table 4.1.
`netapp_flexvol_encryption`	Boolean	ONTAP	Limit the candidate volume list to only the ones that have Flexvol Encryption (NVE) enabled on the storage controller. NVE is a software-based technology for encrypting data at rest, one volume at a time.
`netapp_mirrored`	Boolean	ONTAP	Limit the candidate volume list to only the ones that are mirrored on the storage controller.
`netapp_dedup`	Boolean	ONTAP	Limit the candidate volume list to only the ones that have deduplication enabled on the storage controller.
`netapp_compression`	Boolean	ONTAP	Limit the candidate volume list to only the ones that have compression enabled on the storage controller.
`thin_provisioning_support`	Boolean	ONTAP	Limit the candidate volume list to only the ones that support thin provisioning on the storage controller.

Table 4.11. NetApp supported Extra Specs for use with Cinder volume Types

[2]	Please note that this extra spec has a colon (:) in its name because it is used by the driver to assign the QoS policy group to the OpenStack Block Storage volume after it has been provisioned.