Applies to SUSE OpenStack Cloud 8

20 Installing Manila and Creating Manila Shares #

20.1 Installing Manila #

The OpenStack Shared File Systems service (Manila) provides file storage to a virtual machine. The Shared File Systems service provides a storage provisioning control plane for shared or distributed file systems. The service enables management of share types and share snapshots if you have a driver that supports them.

The Manila service consists of the following components:

manila-api
manila-data
manila-scheduler
manila-share
messaging queue

These Manila components are included in example SUSE OpenStack Cloud models based on Nova KVM, such as entry-scale-kvm, entry-scale-kvm-mml, and mid-scale-kvm. General installation instructions are available at Chapter 12, Installing Mid-scale and Entry-scale KVM.

If you modify one of these cloud models to set up a dedicated Cloud Lifecycle Manager, add manila-client item to the list of service components for the Cloud Lifecycle Manager cluster.

The following steps install Manila if it is not already present in your cloud data model:

Log in to the Cloud Lifecycle Manager.
Apply Manila changes in control_plane.yml.
```
ardana > cd /var/lib/ardana/openstack/my_cloud/definition/data/
```
Add manila-client to the list of service components for Cloud Lifecycle Manager, and both manila-api and manila-share to the Control Node.

Run the Configuration Processor.

ardana > cd ~/openstack
ardana > git add -A
ardana > git commit -m "manila config"
ardana > cd ~/openstack/ardana/ansible/
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml

Deploy Manila

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts percona-deploy.yml
ardana > ansible-playbook -i hosts/verb_hosts manila-deploy.yml

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts ardana-gen-hosts-file.yml
ardana > ansible-playbook -i hosts/verb_hosts ardana-reconfigure.yml
ardana > ansible-playbook -i hosts/verb_hosts clients-deploy.yml

If Manila has already been installed and is being reconfigured, run the following for the changes to take effect:

ardana > ansible-playbook -i hosts/verb_hosts manila-stop.yml
ardana > ansible-playbook -i hosts/verb_hosts manila-start.yml

Verify the Manila installation

ardana > cd
ardana > . manila.osrc
ardana > . service.osrc
ardana > manila api-version
ardana > manila service-list

The Manila CLI can be run from Cloud Lifecycle Manager or controller nodes.

Note

The manila-share service component is not started by the manila-deploy.yml playbook when run under default conditions. This component requires that a valid backend be configured, which is described in Section 20.3, “Configure Manila Backend”.

20.2 Adding Manila to an Existing SUSE OpenStack Cloud Environment #

Add Manila to an existing SUSE OpenStack Cloud installation or as part of an upgrade with the following steps:

Add the items listed below to the list of service components in ~/openstack/my_cloud/definition/data/control_plane.yml. Add them to clusters that have server-role set to CONTROLLER-ROLE (applies to entry-scale models).
- manila-client
- manila-api
If your environment uses a dedicated Cloud Lifecycle Manager, add magnum-client to the list of service components for the Cloud Lifecycle Manager in ~/openstack/my_cloud/definition/data/control_plane.yml.

Commit your configuration to the local git repo.

ardana > cd ~/openstack/ardana/ansible
ardana > git add -A
ardana > git commit -m "My config or other commit message"

Run the configuration processor.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml

Update deployment directory.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml

Deploy Manila.

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts percona-deploy.yml
ardana > ansible-playbook -i hosts/verb_hosts manila-deploy.yml
ardana > ansible-playbook -i hosts/verb_hosts ardana-gen-hosts-file.yml
ardana > ansible-playbook -i hosts/verb_hosts ardana-reconfigure.yml
ardana > ansible-playbook -i hosts/verb_hosts clients-deploy.yml

Verify the Manila installation.

ardana > cd
ardana > . manila.osrc
ardana > . service.osrc
ardana > manila api-version
ardana > manila service-list

The Manila CLI can be run from the Cloud Lifecycle Manager or controller nodes.

Proceed to Section 20.3, “Configure Manila Backend”.

20.3 Configure Manila Backend #

20.3.1 Configure NetaApp Manila Back-end #

Note

An account with cluster administrator privileges must be used with the netapp_login option when using Share Server management. Share Server management creates Storage Virtual Machines (SVM), thus SVM administrator privileges are insufficient.

There are two modes for the NetApp Manila back-end:

driver_handles_share_servers = True
driver_handles_share_servers = False This value must be set to False if you want the driver to operate without managing share servers.

More information is available from NetApp OpenStack

The steps to configure a NetApp Manila back-end are:

Configure a back-end in the Manila configuration file, following the directions and comments in the file.
```
ardana > cd ~/openstack/my_cloud
ardana > vi config/manila/manila.conf.j2
```

Commit your configuration to the local Git repo.

ardana > cd ~/openstack/ardana/ansible
ardana > git add -A
ardana > git commit -m "My config or other commit message"

Run the configuration processor.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml

Update deployment directory.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml

Run reconfiguration playbook.

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts manila-reconfigure.yml

Restart Manila services.

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts manila-stop.yml
ardana > ansible-playbook -i hosts/verb_hosts manila-start.yml

Note

After the manila-share service has been initialized with a backend, it can be controlled independently of manila-api by using the playbooks manila-share-start.yml, manila-share-stop.yml, and manila-share-status.yml.

20.3.2 Configure CephFS Manila Backend #

Configure a back-end in the Manila configuration file, ~/openstack/my_cloud vi config/manila/manila.conf.j2.

To define a CephFS native back-end, create a section like the following:

[cephfsnative1]
driver_handles_share_servers = False
share_backend_name = CEPHFSNATIVE1
share_driver = manila.share.drivers.cephfs.driver.CephFSDriver
cephfs_conf_path = /etc/ceph/ceph.conf
cephfs_protocol_helper_type = CEPHFS
cephfs_auth_id = manila
cephfs_cluster_name = ceph
cephfs_enable_snapshots = False

Add CephFS to enabled_share_protocols:

enabled_share_protocols = NFS,CIFS,CEPHFS

Edit the enabled_share_backends option in the DEFAULT section to point to the driver’s back-end section name.
According to the environment, modify back-end specific lines in ~/openstack/my_cloud vi config/manila/manila.conf.j2.

Commit your configuration to the local Git repo.

ardana > cd ~/openstack/ardana/ansible
ardana > git add -A
ardana > git commit -m "My config or other commit message"

Run the configuration processor.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost config-processor-run.yml

Update deployment directory.

ardana > cd ~/openstack/ardana/ansible
ardana > ansible-playbook -i hosts/localhost ready-deployment.yml

Run reconfiguration playbook.

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts manila-reconfigure.yml

Restart Manila services.

ardana > cd ~/scratch/ansible/next/ardana/ansible
ardana > ansible-playbook -i hosts/verb_hosts manila-stop.yml
ardana > ansible-playbook -i hosts/verb_hosts manila-start.yml

Note

After the manila-share service has been initialized with a back-end, it can be controlled independently of manila-api by using the playbooks manila-share-start.yml, manila-share-stop.yml, and manila-share-status.yml.

For more details of the CephFS Manila back-end, see OpenStack CephFS driver.

20.4 Creating Manila Shares #

Manila can support two modes, with and without the handling of share servers. The mode depends on driver support.

Mode 1: The back-end is a generic driver, driver_handles_share_servers = False (DHSS is disabled). The following example creates a VM using Manila share image.

ardana > wget http://tarballs.openstack.org/manila-image-elements/images/manila-service-image-master.qcow2
ardana > . service.osrc;openstack image create --name
"manila-service-image-new" \
--file manila-service-image-master.qcow2 --disk-format qcow2 \
--container-format bare --visibility public --progress
ardana > openstack image list (verify manila image)
ardana > openstack security group create manila-security-group \
--description "Allows web and NFS traffic to manila server."
ardana > openstack security group rule create manila-security-group \
--protocol tcp --dst-port 2049
ardana > openstack security group rule create manila-security-group \
--protocol udp --dst-port 2049
ardana > openstack security group rule create manila-security-group \
--protocol tcp --dst-port 22
ardana > openstack security group rule create manila-security-group \
--protocol icmp
ardana > openstack security group rule list manila-security-group (verify manila security group)
ardana > openstack keypair create --public-key ~/.ssh/id_rsa.pub mykey
ardana > openstack network create n1
ardana > openstack subnet create s1 --network n1 --subnet-range 11.11.11.0/24
ardana > openstack router create r1
ardana > openstack router add subnet r1 s1
ardana > openstack router set r1 ext-net
ardana > openstack network list
ardana > openstack server create manila-vm --flavor m1.small \
--image IMAGE_ID --nic net-id=N1_ID --security-group manila-security-group \
--key-name myKey
ardana > oenstack floating ip create EXT-NET_ID
ardana > openstack server add floating ip manila-vm EXT-NET_ID

Validate your ability to ping or connect by SSH to manila-vm with credentials manila/manila.

Modify the configuration:

ardana > vi
    /etc/manila/manila.conf.d/100-manila.conf

Make changes in [generic1] section

service_instance_name_or_id = MANILA_VM_ID
service_net_name_or_ip = MANILA_VM_FLOATING_IP
tenant_net_name_or_ip = MANILA_VM_FLOATING_IP

Create a share type. OpenStack docs has detailed instructions. Use the instructions for manila type-create default_share_type False

Restart Manila services and verify they are up.

ardana > systemctl restart openstack-manila-api \
openstack-manila-share openstack-manila-scheduler
ardana > manila service-list

Continue creating a share

ardana > manila create NFS 1 --name SHARE
ardana > manila list (status will change from  creating to available)
ardana > manila show share1
ardana > manila access-allow SHARE ip INSTANCE_IP

Mount the share on a Compute instance

ardana > mkdir ~/test_directory
tux > sudo mount -vt nfs EXT-NET_ID:/shares/SHARE-SHARE-ID ~/test_folder

Mode 2: The back-end is NetApp, driver_handles_share_servers = True (DHSS is enabled). Procedure for driver_handles_share_servers = False is similar to Mode 1.

Modify the configuration

ardana > vi /etc/manila/manila.conf.d/100-manila.conf

Add a backendNetApp section

share_driver = manila.share.drivers.netapp.common.NetAppDriver
driver_handles_share_servers = True
share_backend_name=backendNetApp
netapp_login=NetApp_USERNAME
netapp_password=NetApp_PASSWORD
netapp_server_hostname=NETAPP_HOSTNAME
netapp_root_volume_aggregate=AGGREGATE_NAME

Add to [DEFAULT] section

enabled_share_backends = backendNetApp
default_share_type = default1

Create a Manila share image and verify it

ardana > wget http://tarballs.openstack.org/manila-image-elements/images/manila-service-image-master.qcow2
ardana > . service.osrc;openstack image create manila-service-image-new \
--file manila-service-image-master.qcow2 --disk-format qcow2 \
--container-format bare --visibility public --progress
ardana > openstack image list (verify a Manila image)

Create a share type. OpenStack docs has detailed instructions. Use the instructions for manila type-create default_share_type True .

Restart services

ardana > systemctl restart openstack-manila-api openstack-manila-share \openstack-manila-scheduler
ardana > manila service-list (verify services are up)

Continue creating a share. OCTAVIA-MGMT-NET can be used as PRIVATE_NETWORK in this example.

ardana > manila share-network-create --name demo-share-network1 \
--neutron-net-id PRIVATE_NETWORK_ID --neutron-subnet-id PRIVATE_NETWORK_SUBNET_ID
ardana > manila create NFS 1 --name share2 --share-network demo-share-network1

20.5 Troubleshooting #

If manila-list shows share status in error, use storage aggregate show to list available aggregates. Errors may be found in /var/log/manila/manila-share.log

if the compute nodes do not have access to Manila back-end server, use the manila-share service on controller nodes instead. You can do so by either running sudo systemctl stop openstack-manila-share on compute to turn off its share service or skipping adding "manila-share" to compute hosts in the input-model (control_plane.yml in /var/lib/ardana/openstack/my_cloud/definition/data).