Contents
Hitachi HNAS manila driver¶
Driver Version 1.0¶
This OpenStack manila driver provides support for Hitachi Data Systems (HDS) NAS Platform Models 3080, 3090, 4040, 4060, 4080 and 4100.
HNAS Storage Requirements¶
Before using Hitachi HNAS manila driver, use the HNAS configuration and management utilities, such as GUI (SMU) or SSC CLI to create a storage pool (span) and an EVS. Also, check that HNAS/SMU software version is 12.2 or higher.
Supported Operations¶
- The following operations are supported in this version of manila HNAS driver:
- Create and delete NFS shares;
- Extend NFS shares;
- Manage rules to NFS shares (allow/deny access);
- Manage and unmanage NFS shares;
- Create and delete snapshots;
- Create shares from snapshots.
Driver Configuration¶
To configure the driver, make sure that the controller and compute nodes have access to the HNAS management port, and compute and neutron nodes have access to the data ports (EVS IPs or aggregations). If manila-share service is not running on controller node, it must have access to the management port. The driver configuration can be summarized in the following steps:
In the following sections we cover steps 3, 4, 5, 6 and 7. Steps 1 and 2 are not in the scope of this document.
Step 3 - HNAS Parameters Configuration¶
The following parameters need to be configured in the [DEFAULT] section of /etc/manila/manila.conf:
| [DEFAULT] | ||
|---|---|---|
| Option | Description | |
| enabled_share_backends | Name of the section on manila.conf used to specify a backend. E.g. enabled_share_backends = hnas1 | |
| enabled_share_protocols | Specify a list of protocols to be allowed for share creation. For Hitachi driver this must be: NFS | |
The following parameters need to be configured in the [backend] section of /etc/manila/manila.conf:
| [hnas1] | |
|---|---|
| Option | Description |
| share_backend_name | A name for the backend. |
| share_driver | Python module path. For Hitachi driver this must be: manila.share.drivers.hitachi.hds_hnas.HDSHNASDriver |
| driver_handles_share_servers | DHSS, Driver working mode. For Hitachi driver this must be: False |
| hds_hnas_ip | HNAS management interface IP for communication between manila node and HNAS. |
| hds_hnas_password | This field is used to provide password credential to HNAS. Either hds_hnas_password or hds_hnas_ssh_private_key must be set. |
| hds_hnas_ssh_private_key | Set this parameter with RSA/DSA private key path to allow the driver to connect into HNAS. |
| hds_hnas_evs_id | ID or Label from EVS which this backend is assigned to (ID and Label can be listed by CLI “evs list” or EVS Management in HNAS Interface). |
| hds_hnas_evs_ip | EVS IP for mounting shares (this can be listed by CLI “evs list” or EVS Management in HNAS Interface). |
| hds_hnas_file_system_name | Name of the file system in HNAS, located in the specified EVS. |
| hds_hnas_cluster_admin_ip0* | If HNAS is in a multi-node cluster, set this parameter with the IP of the cluster’s admin node. |
| hds_hnas_stalled_job_timeout* | Tree-clone-job commands are used to create snapshots and create shares from snapshots. This parameter sets a timeout (in seconds) to wait for jobs to complete. Default value is 30 seconds. |
* Non mandatory parameters.
Below is an example of a valid configuration of HNAS driver:
Step 4 - Prepare the Network¶
In the driver mode used by HNAS Driver (DHSS = 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 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:
The following image represents the described scenario:
Run in Neutron Node:
Edit /etc/neutron/plugins/ml2/ml2_conf.ini (default directory), change the following settings as follows in their respective tags:
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
Step 6 - Restart the services¶
Restart all manila services (manila-share, manila-scheduler and manila-api) and neutron services (neutron-*). This step is specific to your environment. If you are running in devstack for example, you have to log into screen (screen -r), stop the process (Ctrl^C) and run it again. If you are running it in a distro like RHEL or SUSE, a service command (e.g. service manila-api restart) is used to restart the service.
Step 7 - Configure the Network¶
In Neutron Controller it is necessary to create a network, a subnet and to add this subnet interface to a router:
Create a network to the given tenant (demo), providing the DEMO_ID (this can be fetched using keystone tenant-list), a name for the network, the name of the physical network over which the virtual network is implemented and the type of the physical mechanism by which the virtual network is implemented:
Create a subnet to same tenant (demo), providing the DEMO_ID (this can be fetched using keystone tenant-list), the gateway IP of this subnet, a name for the subnet, the network ID created on previously step (this can be fetched using neutron net-list) and CIDR of subnet:
Finally, add the subnet interface to a router, providing the router ID and subnet ID created on previously step (can be fetched using neutron subnet-list):
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.