Verify Share Network

SFS are shared among different users and machines by using a share network. EUMETSAT clouds should already contain a pre-configured share network to use for your file shares. Verify the existence of this share network by running the command

openstack share network list

You should see an entry like this

If no share network is available in your cloud, please open a ticket with the support team to resolve the issue.

Create a File share

File shares can be created using the OpenStack CLI. First it is recommended to check what types of SFS are available in your cloud, to do that, run 

openstack share type list

which, by default, will only show the two types available, general_performance and high_performance. 

Then create a file share with the following commands

openstack share create --name <share_name> --description <description> --share-type <share_type> --share-network <share_network> NFS <size>

where <share_name> is the name of the newly created share, with some optional <description> , and a <share_type>  from the ones above. The value of <share_network_id> is the name or ID of the share network created in the previous step. Lastly <size> is the required size in GB of the file share.

To see the list of shares in the cloud run the command

openstack share list

and to see the details of a specific file share, one can do

openstack share show <share_name_or_id>

Add the VM to the Share Network

In order for a VM to have access to a SFS it needs to be able to trace a route to the SFS via a share network. At EWC this is achieved via a specific private network, typically called sfs_network_<project_id>, and a router that provides a static route to the share network. When provisioning an instance, add the sfs network to the list of networks for the VM (usually in addition to private). First run the command

openstack network list

which will show you the name and ID of the network. Then use this when provisioning by following the instructions in EWC OpenStack API access - How to create a VM using the OpenStack CLI.

If the instance has already provisioned, one can add the VM to the network at any point afterwards with the command

openstack server add network <instance> <network>

In order to find out the IP that was assigned to the network, just check the details of the VM with

openstack server show <instance>

which will have a line that looks like

with the IP address of the VM in the SFS network. This IP will be necessary to give the VM access to the SFS later on, so make note of it.

In order to ensure that the VM has access to the share network through the router, the security groups for the VM's port in the SFS network must allow egress to the required IPs. The pre-configured security groups default, ssh and ssh-http-https, among others, have the right permissions to access the SFS, so make sure that these are added to the VM when provisioning it or at any time afterwards.

Grant access to the SFS to a VM

By default no VM has direct access to the newly created SFS. In order to give access to a VM with IP <instance_ip> , do

openstack share access create <share> ip <instance_ip>

where <share>  can the name or ID of the file share to give access to. If read-only access is required, this can be specified with the option --access-level ro . Furthermore, to give access to a range of IPs, one can use the CIDR format, e.g. 10.0.0.0/24.

One can list the IPs that have access to the share with the command

openstack share access list <share>

with <share> , as usual, the name or id of the share.

Access can be denied at any time with

openstack share access delete <access_id>

Mount file share to a VM

Even if the file share is accessible to the VM, one can not read or write on it until it is mounted to a directory in the VM. In order to do so, first create an appropriate directory on the VM

mkdir <path>/<to>/<local>/<share>

 then grab the export path for the file share. This can be found by doing

openstack share show <share_name_or_id>

under the export_locations field. It is recommended to use the path with the preferred=True  keyword. An example output that has the right information can be seen here

Then mount the selected export path into the created directory

sudo mount <share_export_path> <path>/<to>/<local>/<share>

To make the SFS persistent after reboot, which you almost certainly want to do, edit the mounts table (e.g. sudo nano /etc/fstab ) and add a line like the following:

<share_export_path> <path>/<to>/<local>/<share> nfs defaults,<rw/ro> 0 0

for example, to mount the share shown before in the /local/sfs directory, with read-write permissions, the line will look like

10.214.37.37:/share_a8d18d6b_8d18_42fc_b4d1_7498d833ebe0 /local/sfs nfs defaults,rw 0 0

To test this, unmount the share with sudo umount /sfs-test  and then run sudo mount -a .  This should cause the share to mount again if you have everything correct, otherwise you'll see an error message.  If it worked, it's then safe to reboot the machine to test mounting on boot up.   If it didn't work, don't reboot until you've fixed it or commented out the entry as it may prevent a proper boot up.

Resizing an existing file share

The size of SFS is specified at the creation of the file share. However it is possible to change the size at a later time. In order to do that one can use the command

openstack share resize <share> <new_size>

where <share> is the name or ID of the share to resize and <new_size>  is the new required size in GB.

Note that if the new size is smaller than the original size, the resizing will fail to avoid data loss.