Hitachi NAS Platform File Services Driver for OpenStack¶

Hitachi NAS Platform Storage Requirements¶

This Hitachi NAS Platform File Services Driver for OpenStack provides support for Hitachi NAS Platform (HNAS) models 3080, 3090, 4040, 4060, 4080 and 4100 with NAS OS 12.2 or higher. Before configuring the driver, ensure the HNAS has at least:

• 1 storage pool (span) configured.
• 1 EVS configured.
• 1 file system in this EVS, created without replication target option and should be in mounted state. It is recommended to disable auto-expansion, because the scheduler uses the current free space reported by the file system when creating shares.
• 1 Management User configured with “supervisor” permission level.
• Hitachi NAS Management interface should be reachable from manila-share node.

Also, if the driver is going to create CIFS shares, either LDAP servers or domains must be configured previously in HNAS to provide the users and groups.

Supported Operations¶

The following operations are supported in this version of Hitachi NAS Platform File Services Driver for OpenStack:

• Create and delete CIFS and NFS shares;
• Extend and shrink shares;
• Manage rules to shares (allow/deny access);
• Allow and deny share access;
  • IP access type supported for NFS shares;
  • User access type supported for CIFS shares;
  • Both RW and RO access level are supported for NFS and CIFS shares;
• Manage and unmanage shares;
• Create and delete snapshots;
• Create shares from snapshots.

Driver Configuration¶

This document contains the installation and user guide of the Hitachi NAS Platform File Services Driver for OpenStack. Although mentioning some Shared File Systems service operations and HNAS commands, both are not in the scope of this document. Please refer to their own guides for details.

Before configuring the driver, make sure that the nodes running the manila-share service have access to the HNAS management port, and compute and network nodes have access to the data ports (EVS IPs or aggregations).

The driver configuration can be summarized in the following steps:

1. Configure HNAS parameters on manila.conf;
2. Prepare the network ensuring all OpenStack-HNAS connections mentioned above;
3. Configure/create share type;
4. Restart the services;
5. Configure OpenStack networks.

[DEFAULT]``
...
enabled_share_backends = hitachi1
enabled_share_protocols = CIFS,NFS
...

[hitachi1]
share_backend_name = HITACHI1
share_driver = manila.share.drivers.hitachi.hnas.driver.HitachiHNASDriver
driver_handles_share_servers = False
hitachi_hnas_ip = 172.24.44.15
hitachi_hnas_user = supervisor
hitachi_hnas_password = supervisor
hitachi_hnas_evs_id = 1
hitachi_hnas_evs_ip = 10.0.1.20
hitachi_hnas_file_system_name = FS-Manila

Step 2 - Prepare the Network¶

In the driver mode used by Hitachi NAS Platform File Services Driver for OpenStack, driver_handles_share_servers (DHSS) as False, the driver does not handle network configuration, it is up to the administrator to configure it. It is mandatory that HNAS management interface is reachable from a manila-share node through admin network, while the selected EVS data interface is reachable from OpenStack Cloud, such as through neutron flat networking. Here is a step-by-step of an example configuration:

Manila-Share Node:

eth0: Admin Network, can ping HNAS management interface.

eth1: Data Network, can ping HNAS EVS IP (data interface). This interface is only required if you plan to use Share Migration.

Network Node and Compute Nodes:

eth0: Admin Network, can ping HNAS management interface.

eth1: Data Network, can ping HNAS EVS IP (data interface).

The following image represents the described scenario:

Run in Network Node:

$ sudo ifconfig eth1 0
$ sudo ovs-vsctl add-br br-eth1
$ sudo ovs-vsctl add-port br-eth1 eth1
$ sudo ifconfig eth1 up

Edit /etc/neutron/plugins/ml2/ml2_conf.ini (default directory), change the following settings as follows in their respective tags:

[ml2]
type_drivers = flat,vlan,vxlan,gre
mechanism_drivers = openvswitch

[ml2_type_flat]
flat_networks = physnet1,physnet2

[ml2_type_vlan]
network_vlan_ranges = physnet1:1000:1500,physnet2:2000:2500

[ovs]
bridge_mappings = physnet1:br-ex,physnet2:br-eth1

You may have to repeat the last line above in another file in the Compute Node, if it exists is located in: /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini.

Create a route in HNAS to the tenant network. Please make sure multi-tenancy is enabled and routes are configured per EVS. Use the command “route-net-add” in HNAS console, where the network parameter should be the tenant’s private network, while the gateway parameter should be the flat network gateway and the “console-context –evs” parameter should be the ID of EVS in use, such as in the following example:

$ console-context --evs 3 route-net-add --gateway 192.168.1.1 10.0.0.0/24

$ manila type-create hitachi False

$ manila type-key hitachi set dedupe=True

$ neutron net-create --tenant-id <DEMO_ID> hnas_network
--provider:physical_network=physnet2 --provider:network_type=flat

$ neutron subnet-create --tenant-id <DEMO_ID> --gateway <GATEWAY>
--name hnas_subnet <NETWORK_ID> <SUBNET_CIDR>

$ neutron router-interface-add <ROUTER_ID> <SUBNET_ID>

Manage and Unmanage Shares¶

Manila has the ability to manage and unmanage shares. If there is a share in the storage and it is not in OpenStack, you can manage that share and use it as a manila share. Hitachi NAS Platform File Services Driver for OpenStack use virtual-volumes (V-VOLs) to create shares. Only V-VOLs with a quota limit can be used by the driver, also, they must be created or moved inside the directory ‘/shares/’ and exported (as NFS or CIFS shares). The unmanage operation only unlinks the share from OpenStack, preserving all data in the share.

To manage shares use:

$ manila manage [--name <name>] [--description <description>]
[--share_type <share_type>] [--driver_options [<key=value> [<key=value> ...]]]
<service_host> <protocol> <export_path>

Where:

To unmanage a share use:

$ manila unmanage <share_id>

Where:

Additional Notes¶

• HNAS has some restrictions about the number of EVSs, file systems, virtual-volumes and simultaneous SSC connections. Check the manual specification for your system.
• Shares and snapshots are thin provisioned. It is reported to manila only the real used space in HNAS. Also, a snapshot does not initially take any space in HNAS, it only stores the difference between the share and the snapshot, so it grows when share data is changed.
• Admins should manage the tenant’s quota (manila quota-update) to control the backend usage.
• By default, CIFS snapshots are disabled when the share is mounted, since it uses tree-clone to create snapshots and does not guarantee point-in-time replicas when the source directory tree is changing, also, changing permissions to read-only does not affect already mounted shares. So, enable it if your source directory can be static while taking snapshots. Currently, it affects only CIFS protocol. For more information check the tree-clone feature in HNAS with man tree-clone.

The manila.share.drivers.hitachi.hnas.driver Module¶

class HitachiHNASDriver(*args, **kwargs)

Bases: manila.share.driver.ShareDriver

Manila HNAS Driver implementation.

Driver versions:

1.0.0 - Initial Version.
2.0.0 - Refactoring, bugfixes, implemented Share Shrink and
        Update Access.
3.0.0 - New driver location, implemented support for CIFS protocol.
3.1.0 - Added admin network export location support.
4.0.0 - Added mountable snapshots, revert-to-snapshot and
        manage snapshots features support.

create_share(context, share, share_server=None)

Creates share.

Parameters:

context – The context.RequestContext object for the request share – Share that will be created. share_server – Data structure with share server information. Not used by this driver.

Returns:

Returns a list of dicts containing the EVS IP concatenated with the path of share in the filesystem. Example for NFS: [ { ‘path’: ‘172.24.44.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: True } ] Example for CIFS: [ { ‘path’: ‘172.24.44.10id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10id’, ‘metadata’: {}, ‘is_admin_only’: True } ]

create_share_from_snapshot(context, share, snapshot, share_server=None)

Creates a new share from snapshot.

Parameters:

context – The context.RequestContext object for the request share – Information about the new share. snapshot – Information about the snapshot that will be copied to new share. share_server – Data structure with share server information. Not used by this driver.

Returns:

Returns a list of dicts containing the EVS IP concatenated with the path of share in the filesystem. Example for NFS: [ { ‘path’: ‘172.24.44.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: True } ] Example for CIFS: [ { ‘path’: ‘172.24.44.10id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10id’, ‘metadata’: {}, ‘is_admin_only’: True } ]

create_snapshot(context, snapshot, share_server=None)

Creates snapshot.

Parameters:	context – The context.RequestContext object for the request snapshot – Snapshot that will be created. share_server – Data structure with share server information. Not used by this driver.

delete_share(context, share, share_server=None)

Deletes share.

Parameters:	context – The context.RequestContext object for the request share – Share that will be deleted. share_server – Data structure with share server information. Not used by this driver.

delete_snapshot(context, snapshot, share_server=None)

Deletes snapshot.

Parameters:	context – The context.RequestContext object for the request snapshot – Snapshot that will be deleted. share_server – Data structure with share server information. Not used by this driver.

ensure_share(context, share, share_server=None)

Ensure that share is exported.

Parameters:

context – The context.RequestContext object for the request share – Share that will be checked. share_server – Data structure with share server information. Not used by this driver.

Returns:

Returns a list of dicts containing the EVS IP concatenated with the path of share in the filesystem. Example for NFS: [ { ‘path’: ‘172.24.44.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: True } ] Example for CIFS: [ { ‘path’: ‘172.24.44.10id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10id’, ‘metadata’: {}, ‘is_admin_only’: True } ]

ensure_snapshot(context, snapshot, share_server=None)

Ensure that snapshot is exported.

Parameters:

context – The context.RequestContext object for the request. snapshot – Snapshot that will be checked. share_server – Data structure with share server information. Not used by this driver.

Returns:

Returns a list of dicts containing the EVS IP concatenated with the path of snapshot in the filesystem or None if mount_snapshot_support is False. Example for NFS: [ { ‘path’: ‘172.24.44.10:/snapshots/id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10:/snapshots/id’, ‘metadata’: {}, ‘is_admin_only’: True } ] Example for CIFS: [ { ‘path’: ‘172.24.44.10id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10id’, ‘metadata’: {}, ‘is_admin_only’: True } ]

extend_share(share, new_size, share_server=None)

Extends a share to new size.

Parameters:	share – Share that will be extended. new_size – New size of share. share_server – Data structure with share server information. Not used by this driver.

get_network_allocations_number()

Track allocations_number in DHSS = true.

When using the setting driver_handles_share_server = false does not require to track allocations_number because we do not handle network stuff.

manage_existing(share, driver_options)

Manages a share that exists on backend.

Parameters:

share – Share that will be managed. driver_options – Empty dict or dict with ‘volume_id’ option.

Returns:

Returns a dict with size of the share managed and a list of dicts containing its export locations. Example for NFS: { ‘size’: 10, ‘export_locations’: [ { ‘path’: ‘172.24.44.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10:/shares/id’, ‘metadata’: {}, ‘is_admin_only’: True } ] } Example for CIFS: { ‘size’: 10, ‘export_locations’: [ { ‘path’: ‘172.24.44.10id’, ‘metadata’: {}, ‘is_admin_only’: False }, { ‘path’: ‘192.168.0.10id’, ‘metadata’: {}, ‘is_admin_only’: True } ] }

manage_existing_snapshot(snapshot, driver_options)

Manages a snapshot that exists only in HNAS.

The snapshot to be managed should be in the path /snapshots/SHARE_ID/SNAPSHOT_ID. Also, the size of snapshot should be provided as –driver_options size=<size>. :param snapshot: snapshot that will be managed. :param driver_options: expects only one key ‘size’. It must be provided in order to manage a snapshot.

Returns:	Returns a dict with size of snapshot managed

revert_to_snapshot(context, snapshot, share_access_rules, snapshot_access_rules, share_server=None)

Reverts a share to a given snapshot.

Parameters:

context – The context.RequestContext object for the request snapshot – The snapshot to which the share is to be reverted to. share_access_rules – List of all access rules for the affected share. Not used by this driver. snapshot_access_rules – List of all access rules for the affected snapshot. Not used by this driver. share_server – Data structure with share server information. Not used by this driver.

shrink_share(share, new_size, share_server=None)

Shrinks a share to new size.

Parameters:	share – Share that will be shrunk. new_size – New size of share. share_server – Data structure with share server information. Not used by this driver.

snapshot_update_access(context, snapshot, access_rules, add_rules, delete_rules, share_server=None)

Update access rules for given snapshot.

Drivers should support 2 different cases in this method: 1. Recovery after error - ‘access_rules’ contains all access rules, ‘add_rules’ and ‘delete_rules’ shall be empty. Driver should clear any existent access rules and apply all access rules for given snapshot. This recovery is made at driver start up.

2. Adding/Deleting of several access rules - ‘access_rules’ contains all access rules, ‘add_rules’ and ‘delete_rules’ contain rules which should be added/deleted. Driver can ignore rules in ‘access_rules’ and apply only rules from ‘add_rules’ and ‘delete_rules’. All snapshots rules should be read only.

Parameters:	context – Current context snapshot – Snapshot model with snapshot data. access_rules – All access rules for given snapshot add_rules – Empty List or List of access rules which should be added. access_rules already contains these rules. delete_rules – Empty List or List of access rules which should be removed. access_rules doesn’t contain these rules. share_server – None or Share server model

unmanage(share)

Unmanages a share.

Parameters:	share – Share that will be unmanaged.

unmanage_snapshot(snapshot)

Unmanage a share snapshot

Parameters:	snapshot – Snapshot that will be unmanaged.

update_access(context, share, access_rules, add_rules, delete_rules, share_server=None)

Update access rules for given share.

Parameters:

context – The context.RequestContext object for the request share – Share that will have its access rules updated. access_rules – All access rules for given share. add_rules – Empty List or List of access rules which should be added. access_rules already contains these rules. delete_rules – Empty List or List of access rules which should be removed. access_rules doesn’t contain these rules. share_server – Data structure with share server information. Not used by this driver.