HPE Alletra MP B10000 Share Driver¶
The HPE Alletra MP B10000 Manila driver provides NFS file services to OpenStack using the HPE Alletra MP B10000 file service capabilities.
Supported Operations¶
The following operations are supported with HPE Alletra MP B10000:
Create/delete NFS shares
Allow/deny NFS share access
Extend shares
Manage existing shares
Unmanage shares
Create/delete snapshots
Manage/unmanage snapshots
Revert to snapshot
Mountable snapshot
Share networks are not supported. Shares are created directly on the HPE Alletra MP B10000 array without the use of a share server or service VM. Network connectivity is set up outside of Manila.
Note
Most operations described in this document can also be performed through the OpenStack Horizon dashboard. This document focuses on CLI commands.
Requirements¶
On the HPE Alletra MP B10000 array:
Device version 10.5.0 or later.
The HPE Alletra MP B10000 file service must be enabled.
Note
Device version 10.6.0 or later is required for snapshot operations.
Share Types¶
When creating a share, the share type will be used to determine where and how the share will be created.
Manila requires that the share type includes the driver_handles_share_servers
extra-spec. This ensures that the share is created on a backend that supports
the requested driver_handles_share_servers (share networks) capability. For the
HPE Alletra MP B10000 driver, this option must be set to False.
Creating a Share Type¶
To create a share type for the HPE Alletra MP B10000 backend:
$ openstack share type create alletra_nfs False
$ openstack share type set alletra_nfs --extra-specs share_backend_name=hpealletra1
Share Type Extra Specs¶
The following driver-specific extra specs are supported by Alletra MP B10000:
- hpe_alletra_b10000:reduce
When the value is set to
true(orfalse), shares of this reduce type are created on the backend. The reduce setting is applied at share creation time and cannot be changed for existing shares.The
reduceparameter controls thecompressionanddedupecapabilities of the share:If reduce = true: compression = true, dedupe = true
If reduce = false: compression = false, dedupe = false
If the reduce key is not provided, its value defaults to
true.Alternatively, you can use the
compressionanddedupeparameters directly instead ofreduce, but you cannot specify bothreduceandcompression/dedupein the same share type.Example using reduce:
$ openstack share type set alletra_nfs --extra-specs hpe_alletra_b10000:reduce=true
Example using compression and dedupe as alternative:
$ openstack share type set alletra_nfs --extra-specs compression=true dedupe=true
- hpe_alletra_b10000:squash_option
The value can be set to
root_squash,all_squash, orno_root_squash. Any access rules added to the Alletra backend will be created with this squash option. If the share type is modified to change the squash option, the next share access rule update will use the new squash option value.If not provided, the squash option defaults to
root_squash.Example:
$ openstack share type set alletra_nfs --extra-specs hpe_alletra_b10000:squash_option=root_squash
The following common extra specs are also supported by Alletra MP B10000:
- compression
Controls whether compression is enabled on the share.
When specifying
compression, you must also specifydedupewith the same value (bothtrueor bothfalse). You cannot usecompressiontogether withhpe_alletra_b10000:reduce.Example:
$ openstack share type set alletra_nfs --extra-specs compression=true dedupe=true
- dedupe
Controls whether data deduplication is enabled on the share.
When specifying
dedupe, you must also specifycompressionwith the same value (bothtrueor bothfalse). You cannot usededupetogether withhpe_alletra_b10000:reduce.Example:
$ openstack share type set alletra_nfs --extra-specs dedupe=true compression=true
- thin_provisioning
Controls whether thin provisioning is enabled on the share.
This extra spec must be set to
trueor not specified at all. Setting it tofalseis not supported by this driver.Example:
$ openstack share type set alletra_nfs --extra-specs thin_provisioning=true
- snapshot_support
Controls whether snapshots are enabled for shares of this type. Set to
Trueto allow snapshot creation. Requires device version 10.6.0 or later.Example:
$ openstack share type set alletra_nfs --extra-specs snapshot_support=True
- revert_to_snapshot_support
Controls whether shares of this type can be reverted to a snapshot. Requires
snapshot_support=True. Requires device version 10.6.0 or later.Example:
$ openstack share type set alletra_nfs --extra-specs revert_to_snapshot_support=True
- mount_snapshot_support
Controls whether snapshots of this share type can be directly mounted by clients. Requires
snapshot_support=Trueandsnapshot_inherit_share_access_support=True. Requires device version 10.6.0 or later.Example:
$ openstack share type set alletra_nfs --extra-specs mount_snapshot_support=True snapshot_inherit_share_access_support=True
- snapshot_inherit_share_access_support
Must be set to
Truewhenmount_snapshot_supportisTrue. On Alletra MP B10000, snapshot access rules are always inherited from the parent share and cannot be managed independently. Requires device version 10.6.0 or later.Example:
$ openstack share type set alletra_nfs --extra-specs snapshot_inherit_share_access_support=True
Note
Modifying share type extra specs after shares have been created is not recommended, as it will cause inconsistency between the share type definition and the actual backend share properties. Backend share characteristics like reduce, compression, and dedupe cannot be changed after creation.
Managing Share Access¶
A share must have access rules configured before it can be accessed by clients. IP-based access rules are required for NFS shares.
Note
When no Manila access rules are configured, the driver will block all IP addresses by setting a default access rule of 0.0.0.0 with read-only and root_squash permissions on the backend Alletra B10000 array. You must explicitly create access rules to allow client access.
For CLI commands and more information on managing access rules, see manage access to share.
Extending Shares¶
The driver supports extending shares to increase their size.
For CLI commands and more information on extending shares, see share resize.
Note
The share size shown in Manila includes filesystem metadata and other overhead. Client-usable space will be less than the displayed share size.
Managing Existing Shares¶
The driver supports bringing existing shares on the HPE Alletra array into Manila management using the manage operation.
Prerequisites for Manage Operation¶
Before managing an existing share, ensure the following requirements are met:
Share type compatibility: The backend share
reducevalue must match thehpe_alletra_b10000:reducevalue from the share type. If they don’t match, the manage operation will fail. Associate the correct share type. Default reduce value (if share type doesn’t have this key) istrue. Similarly, if the share type usescompressionanddedupeparameters instead ofreduce, those values must also match the backend share’s compression and deduplication settings.No existing access rules: The backend share must have either an empty access rules list or only the default 0.0.0.0 access rule with read-only and root_squash. If other access rules exist, clear them from the backend share before managing:
$ setsharesetting -remove <ipaddr_list> <sharesetting_name>
Filesystem size alignment: The filesystem size of the backend fileshare must be a multiple of 1024 MiB (1 GiB). If not, the manage operation will fail. Manila logs will indicate how much MiB to expand the backend filesystem.
To expand size by a specific amount (e.g., 500 MiB):
$ setfilesystem -size 500 <filesystem_name>
Ensure Shares Operation¶
The driver supports the ensure_shares operation, which validates that shares
exist on the backend and updates their status in Manila. Shares found on
the backend are updated with the latest export locations. Shares not found
on the backend are marked with error state.
The ensure_shares operation for the driver is executed only in case of service restarts after configuration changes in /etc/manila/manila.conf.
If the backend fileshare export path changes due to file port IP change or other reasons, the administrator must manually trigger the ensure shares command in OpenStack to update the latest export paths.
Refer to recalculating the shares export location for details on manually triggering the ensure shares operation.
Snapshot Operations¶
The driver supports creating and deleting snapshots (snapshot_support),
reverting a share to its last snapshot (revert_to_snapshot_support),
and exporting snapshots for mounting (mount_snapshot_support).
Note
When mount_snapshot_support is set to True in the share type,
snapshot_inherit_share_access_support must also be set to True.
On Alletra MP B10000, snapshot access rules are always inherited from
the parent share and cannot be managed independently.
Managing Existing Snapshots¶
The driver supports bringing existing snapshots on the HPE Alletra array into Manila management using the manage operation.
The provider_location required by manage snapshot is the
backend snapshot filesystem name on the Alletra array.
Prerequisites for Manage Snapshot Operation¶
Before managing an existing snapshot, ensure the following:
Snapshot state must match share type: If
mount_snapshot_supportisTrue, the backend snapshot filesystem must be in online state. Otherwise, it must be in offline state.To change the snapshot filesystem state on the Alletra array:
$ setfilesystem -online <filesystem_name> $ setfilesystem -offline <filesystem_name>
Filesystem size alignment: The backend snapshot filesystem size must be a multiple of 1 GiB. If not, the manage operation will fail.
Driver Capabilities¶
The HPE Alletra MP B10000 driver reports the following capabilities:
Storage protocol: NFS
driver_handles_share_servers: False
Thin provisioning support
Dedupe and compression support
Share extend support
Manage/unmanage share support
Snapshot support (create/delete)
Revert to snapshot support
Mountable snapshot support
Manage/unmanage snapshot support
Restrictions and Limitations¶
The HPE Alletra MP B10000 driver has the following restrictions:
Only NFS protocol is supported; CIFS/SMB is not supported
Share networks are not supported (driver_handles_share_servers must be False)
Share shrink is not currently supported
Creating a share from a snapshot is not supported
Share migration is not supported
Share replication is not supported
Share groups and consistency groups are not supported
Security services (LDAP, Active Directory, Kerberos) are not supported
Only IP-based access rules are supported for NFS shares
Troubleshooting¶
Common Issues¶
- Share creation fails
Verify the HPE Alletra MP B10000 file service is enabled
Check connectivity to the WSAPI endpoint
Ensure the configured user has sufficient permissions
- Access rules not working
Verify network connectivity between client and array’s file ports
Check that the IP address in the access rule is correct
Ensure the share type’s squash_option is appropriate for your use case
- Manage operation fails
Clear all access rules from the backend share
Verify filesystem size is a multiple of 1 GiB
Ensure share type’s reduce value matches the backend share
The manila.share.drivers.hpe.alletra_mp_b10000.hpe_alletra_driver Module¶
- class HPEAlletraFeatureSupportHandler(device_version)
Bases:
object- R5_MIN_DEVICE_VERSION = '10.5.0'
- R6_MIN_DEVICE_VERSION = '10.6.0'
- check_min_r5_device_version()
- check_min_r6_device_version()
- validate_min_driver_version()
Validate that device version meets minimum requirements.
- class HPEAlletraMPB10000ShareDriver(*args, **kwargs)
Bases:
ShareDriverDriver for the HPE Alletra MP B10000 File
Version history:
1.0.0 - Initial version 1.1.0 - Support snapshot functionalities
- ALLETRA_REST_API_TIMEOUT = 120
- VERSION = '1.1.0'
- create_share(context, share, share_server=None)
Create a new manila managed share on backend.
- create_snapshot(context, snapshot, share_server=None)
Creates a snapshot of a share
- delete_share(context, share, share_server=None)
Remove a share from manila and backend
- delete_snapshot(context, snapshot, share_server=None)
Is called to remove snapshot.
- Parameters:
context – Current context
snapshot – Snapshot model. Share model could be retrieved through snapshot[‘share’].
share_server – Share server model or None.
- do_setup(context)
Driver initialization
- ensure_shares(context, shares)
Ensure shares exist on backend and return their current state.
Only returns updates for shares that need status changes. Shares that are already available on the backend are not included in the response, preserving their current state.
- extend_share(share, new_size, share_server=None)
Expand share size
- get_backend_info(context)
Return backend configuration info for ensure_shares validation.
- get_network_allocations_number()
Returns number of network allocations for creating VIFs.
Drivers that use Nova for share servers should return zero (0) here same as Generic driver does. Because Nova will handle network resources allocation. Drivers that handle networking itself should calculate it according to their own requirements. It can have 1+ network interfaces.
- manage_existing(share, driver_options)
Bring an existing backend share into manila management
- manage_existing_snapshot(snapshot, driver_options)
Brings an existing snapshot under Manila management.
If provided snapshot is not valid, then raise a ManageInvalidShareSnapshot exception, specifying a reason for the failure.
This method is invoked when the snapshot that is being managed belongs to a share that has its share type with
driver_handles_share_serversextra-spec set to False.- Parameters:
snapshot – ShareSnapshotInstance model with ShareSnapshot data.
- Example::
{ ‘id’: <instance id>, ‘snapshot_id’: < snapshot id>, ‘provider_location’: <location>, … }
- Parameters:
driver_options – Optional driver-specific options provided by admin.
Example:
{ 'key': 'value', ... }
- Returns:
model_update dictionary with required key ‘size’, which should contain size of the share snapshot, and key ‘export_locations’ containing a list of export locations, if snapshots can be mounted.
- revert_to_snapshot(context, snapshot, share_access_rules, snapshot_access_rules, share_server=None)
Reverts a share (in place) to the specified snapshot.
Does not delete the share snapshot. The share and snapshot must both be ‘available’ for the restore to be attempted. The snapshot must be the most recent one taken by Manila; the API layer performs this check so the driver doesn’t have to.
The share must be reverted in place to the contents of the snapshot. Application admins should quiesce or otherwise prepare the application for the shared file system contents to change suddenly.
- Parameters:
context – Current context
snapshot – The snapshot to be restored
share_access_rules – List of all access rules for the affected share
snapshot_access_rules – List of all access rules for the affected snapshot
share_server – Optional – Share server model or None
- snapshot_update_access(context, snapshot, access_rules, add_rules=None, delete_rules=None, share_server=None)
Update access rules for a mountable snapshot.
Alletra snapshots always inherit the parent share’s access rules, so the driver reports snapshot_inherit_share_access_support and the backend offers no way to set independent snapshot rules. Nothing is applied here.
- unmanage(share)
Remove from manila management without deleting backend share
- unmanage_snapshot(snapshot)
Remove snapshot from manila management without deleting backend
- update_access(context, share, access_rules, add_rules, delete_rules, update_rules, share_server=None)
Modify share access rules
- class HPEAlletraMPB10000ShareDriverHelper(rest_client, **kwargs)
Bases:
objectDriver helper for the HPE Alletra MP B10000 File
- class HPEAlletraPrivateStorageHandler(private_storage)
Bases:
object- PS_BE_FILESYSTEM_NAME = 'alletra_be_filesystem_name'
- PS_BE_SHARESETTING_NAME = 'alletra_be_sharesetting_name'
- PS_BE_SHARE_ID = 'alletra_be_share_id'
- PS_BE_SHARE_NAME = 'alletra_be_share_name'
- PS_BE_SNAP_FILESYSTEM_ID = 'alletra_be_snap_filesystem_id'
- PS_BE_SNAP_FILESYSTEM_NAME = 'alletra_be_snap_filesystem_name'
- PS_BE_SNAP_SHARESETTING_NAME = 'alletra_be_snap_sharesetting_name'
- PS_BE_SNAP_SHARE_ID = 'alletra_be_snap_share_id'
- PS_BE_SNAP_SHARE_NAME = 'alletra_be_snap_share_name'
- delete_share_by_id(fe_share_id)
- delete_snapshot_by_id(fe_snapshot_id)
- get_share_by_id(fe_share_id)
- get_snapshot_by_id(fe_snapshot_id)
- update_share_by_id(fe_share_id, be_share_id, be_share_name, be_filesystem_name, be_sharesetting_name)
Update private storage with backend share details.
- update_snapshot_by_id(fe_snapshot_id, be_share_id, be_filesystem_id, be_share_name, be_filesystem_name, be_sharesetting_name)
Update private storage with backend snapshot details.