Red Hat OpenStack Administration I: Core Operations for Domain Operators

After completing this section, you should be able to provide remote file sharing services for common application file share storage use cases.

Domain operators can advise cloud users about using the file share service to handle their applications file sharing needs. Any application that uses NFS or CIFS distributed files and moves to the cloud requires the file sharing service as an abstraction layer between the application and the file share back end.

Replication of data in the cloud is necessary to provide high availability in a shared file system. For example, a production database requires high available data. Highly available data is also necessary to provide data protection. Should a disaster happen, having shared storage ensures that data is not lost.

Shared file systems must support user facing APIs allowing users with the admin role to create shares. APIs permit administrators to configure back-ends, add and remove share replicas, and to manage snapshots and access rules. An ideal NAS, or network attached storage architecture provides one back end storage shared by many different tenants. Network isolation guarantees tenant security.

Cloud users should be able to mount shares from anywhere without assistance from an administrator. However, they are restricted by the rules that state which shares they are allowed to use. This is different to Linux, where users do not have the rights to the mount command. Linux uses an auto-mounter, to give regular users on-demand access to shares that they would not have the right to mount.

The OpenStack Shared File System service enables tenant users to provision and manage network accessible shared file systems or shares. Tenant users access the shares from instances as remote file systems. The OpenStack Shared File System service helps overcome the challenges that arise while automating the provisioning and management of legacy file based storage resources for scalable cloud applications, while still maintaining efficient isolation for multitenancy.

Manila is designed with the ideal NAS architecture in mind. Manila supports several different protocols, including NFS, CIFS, CephFS, MAPRFS, HDFS, and GlusterFS. It offers many different features, including quota control, tenant driven share replication, snapshots for cloning, and access control and authentication services.

Manila supports three types of replication. Writable replication supports creating writable share replicas. Replicas provide read/write access and are synchronously mirrored. Readable replicas are read-only. The secondary replicas provide read access and the primary replica has write access. Disaster Recovery or dr replicas are not accessible until they are promoted to either writable or readable.

The Shared File System service is comprised of several processes. The manila-api server exposes the functionalities of the OpenStack Shared File System service to the tenant users. The manila-scheduler is responsible for deciding which of the storage back ends will serve the share creation API request. The manila-share service coordinates with the back-end storage systems that accommodate the shares.

Figure 6.3: The OpenStack Shared File System service architecture

NFS-Ganesha acts as a mediator between the tenant users' instances and the back-end storage of the shared file system. It can be configured to allow or deny tenant users access to a specific shared file system. When a client requests to mount a share, the NFS-Ganesha server verifies the access rights of the requester set on the share and allows or denies the request accordingly. If it allows a client to mount the share, any operation the client invokes on the share is redirected to the appropriate back-end storage provider. NFS-Ganesha is also compatible with the Kerberos authentication system to implement Kerberos-enabled NFS shares.

The CephFS native driver for the OpenStack Shared File System service allows the shared file systems to be exported via the CephFS share protocol. Clients interested in mounting such shares should have the native Ceph client installed. The CephFS native driver uses the cephx authentication system to identify and authorize users that can access the shared file systems.

Based on the preconfigured access policies of the shared file systems for the cephx users, the CephFS native driver coordinates with the Red Hat Ceph Storage cluster services to update the capabilities of the cephx user to grant the requested operation. Clients must use the appropriate user ID and secret key while mounting the shared file system or the requested mount operation will fail.

Verify the status of the manila-api, manila-scheduler, and the manila-share processes. Use the podman commands to verify the status of the containerized Red Hat OpenStack Platform services as opposed to the systemctl commands for the systemd unit based services.

[user@demo ~(admin)]$ podman ps --format="{{.Names}}\t{{.Status}}" |
> grep manila
openstack-manila-share-podman-0\tUp 6 weeks ago
manila_scheduler\tUp 6 weeks ago
manila_api\tUp 6 weeks ago

Use the manila service-list command to confirm that the manila services and enabled and up.

[user@demo ~(admin)]$ manila service-list --columns Binary,Status,State
+------------------+---------+-------+
| Binary           | Status  | State |
+------------------+---------+-------+
| manila-scheduler | enabled | up    |
| manila-share     | enabled | up    |
+------------------+---------+-------+

Use the manila-type create command to create the share type. The false argument represents the value of the driver_handles_share_servers parameter. If you wish to dynamically scale the share nodes, set this value to true. This command requires administrative privileges.

[user@demo ~(admin)]$ manila type-create cephfstype false
+----------------------+--------------------------------------+
| Property             | Value                                |
+----------------------+--------------------------------------+
| ID                   | a30447a6-7641-49e5-a139-ebe9cadfcc52 |
| Name                 | cephfstype                           |
| Visibility           | public                               |
| is_default           | -                                    |
| required_extra_specs | driver_handles_share_servers : False |
| optional_extra_specs |                                      |
| Description          | None                                 |
+----------------------+--------------------------------------+

Use the manila create command to create a share. Shares can be created by users who do not have administrative privileges. The --share-type option helps to classify the shares based on the back-end storage providers. In this example, the value 1 indicates that the size of the share would be 1 GB. Note that the status of the share is creating. To confirm that the share is created properly, use the manila list command. The status should be available.

[user@demo ~(admin)]$ manila create --name demo-share
> --share-type cephfstype cephfs 1
+---------------------------------------+---------------------------------------+
| Property                              | Value                                 |
+---------------------------------------+---------------------------------------+
| id                                    | eeeb351b-813b-44fd-9c07-b21b7a054a23  |
| size                                  | 1                                     |
| availability_zone                     | None                                  |
| created_at                            | 2020-07-01T12:17:20.000000            |
| status                                | creating                              |
| name                                  | demo-share                            |
...output omitted...
| share_proto                           | CEPHFS                                |
...output omitted...
| share_type_name                       | cephfstype                            |
| access_rules_status                   | active                                |
...output omitted...

Create the cephx user using the ceph auth get-or-create command on the ceph node. Ensure you save the secret key of the user. This user will be used to authenticate while mounting the CephFS share in the instance. This command creates the client.cloud-user cephx user while authenticating as the client.manila user, using the key-ring file /etc/ceph/ceph.client.manila.keyring that has the secret key for the user. The secret key can then be copied to any instance where the share is mounted.

[user@demo ~(admin)]$ sudo podman exec -t \
> ceph-mon-controller0 \
> ceph --name=client.manila \
> --keyring=/etc/ceph/ceph.client.manila.keyring \
> auth get-or-create client.cloud-user > /root/cloud-user.keyring
[user@demo ~(admin)]$ cat /root/cloud-user.keyring
[client.cloud-user]
    key = AQBim/xeS3QuOhAAYVL9KmztP3J9806Rqpn0KQ==

Grant the appropriate access rights for the cephx user on the share using the manila access-allow command.

[user@demo ~(admin)]$ manila access-allow demo-share cephx cloud-user
+--------------+--------------------------------------+
| Property     | Value                                |
+--------------+--------------------------------------+
| id           | de5de800-7f85-4dfc-9479-695e400efe25 |
| share_id     | eeeb351b-813b-44fd-9c07-b21b7a054a23 |
| access_level | rw                                   |
| access_to    | cloud-user                           |
| access_type  | cephx                                |
| state        | queued_to_apply                      |
| access_key   | None                                 |
| created_at   | 2020-07-01T14:42:00.000000           |
| updated_at   | None                                 |
| metadata     | {}                                   |
+--------------+--------------------------------------+

Use the manila share-export-location-list command to trace the export path location of the share. Use the native Ceph client to mount the share with its appropriate export path location.

[user@demo ~(admin)]$ manila share-export-location-list \
> demo-share --columns Path
+------------------------------------------------------------------------+
| Path                                                                   |
+------------------------------------------------------------------------+
| 172.24.3.1:6789:/volumes/_nogroup/a4596547-c673-4bcf-8ae6-40fa52287bd2 |
+------------------------------------------------------------------------+

Shared file systems have many different use cases. A shared file system provides central management, disaster recovery, high availability, and scalability. Many systems require all of those services, for example SAP, Database-as-a-service, and big data.

Shared file systems can also support legacy enterprise applications until they are re-architectured for the cloud. Cross tenant data sharing can be achieved with a multi-attach volume or using a shared file system. Manila also provides shared file systems with IP based access control which can be accessed concurrently by multiple instances.

Manila provides a storage solution for hybrid cloud shares, the storage of heat templates to be used across networks and projects, and a storage space for DevOps and containers.

It is possible to create, manage, and delete shares using the Dashboard. Shares can be created by cloud users who do not have administrative privileges. However, the creation of ceph clients and ceph keys can only be achieved using the CLI.

Navigate to Project+Share → Shares. Click +Create Share to create a new share. Enter a Share Name, the protocol to use, the size, the share type, the availability zone, and click Create.

In the action menu for a particular share, click Manage Rules. Click +Add Rule. In the Add Rule window you can define the access type, the access level and who should have access. In our example, the user is cloud-user as that user has access to the instances created. After clicking on create to create the rule, note the Access Key in the Dashboard. The rule requires a Status of active.

Figure 6.4: Share rule creation in the Dashboard