Shared Filesystems service

Available since MOSK 24.3

MOSK Shared Filesystems service (OpenStack Manila) provides Shared Filesystems as a service. The Shared Filesystems service enables you to create and manage shared filesystems in your multi-project cloud environments.

Note

MOSK does not support the Shared Filesystems service for the clusters with Tungsten Fabric as a networking backend.

Service architecture

The Shared FileSystems service (OpenStack Manila) consists of manila-api, manila-scheduler, and manila-share services. All these services communicate with each other through the AMQP protocol and store their data in the MySQL database:

  • manila-api

    Provides a stable RESTful API, authenticates and routes requests throughout the Shared Filesystem service

  • manila-scheduler

    Responsible for scheduling and routing requests to the appropriate manila-share service by determining which backend should serve as the destination for a share creation request

  • manila-share

    Responsible for managing Shared Filesystems service devices, specifically the backend ones

The diagram below illustrates how the Shared FileSystems service components communicate with each other.

Untitled Diagram

Shared Filesystems drivers

MOSK ensures support for different kind of equipment and shared filesystems by means of special drivers that are part of the manila-share service. Also, these drivers determine the ability to restrict access to data stored on a shared filesystem, list of operations with Manila volumes, and types of connections to the client network.

Driver Handles Share Servers (DHSS) is one of the main parameters that define the Manila workflow including the way the Manila driver makes clients access shared filesystems. Some drivers support only one DHSS mode, for example, the LVM share driver. Others support both modes, for example, the Generic driver. If the DHSS is set to False in the driver configuration, the driver does not prepare the share server that provides access to the share filesystems and the server and network setup should be performed by the administrator. In this case, the Shared Filesystems service only manages the server in its own configuration.

Untitled Diagram

If the driver configuration includes DHSS=True, the driver creates a service virtual machine that provides access to shared filesystems. Also, when DHSS=True, the Shared Filesystems service performs a network setup to provide client’s access to the created service virtual machine. For working with the service virtual machine, the Shared Filesystems service requires a separate service network that must be included in the driver’s configuration as well.

The following are descriptions of drivers supported by the MOSK Shared Filesystems service.

Generic driver

The generic driver is an example for the DHSS=True case. There are two network topologies for connecting client’s network to the service virtual machine, which depend of the connect_share_server_to_tenant_network parameter. If the connect_share_server_to_tenant_network parameter is set to False, which is default, the client must create a shared network connected to a public router. IP addresses from this network will be granted access to the created shared filesystem. The Shared Filesystems service creates a subnet in its service network where the network port of the new service virtual machine and network port of the clent’s router will be connected to. When a new shared filesystem is created, the client’s machine is granted access to it through the router.

Untitled Diagram

If the connect_share_server_to_tenant_network parameter is set to True, the Shared Filesystems service creates the service virtual machines with two network interfaces. One of them is connected to the service network while the other one is connected to the client’s network.

Untitled Diagram

CephFS driver

Available since MOSK 25.1 TechPreview

The CephFS driver is a DHSS=False driver. The CephFS driver can be configured to use the Ceph protocol to provide shares. However, MOSK does not support the NFS Ganesha protocol.

The main advantages of using a direct connection to CephFS through the Ceph protocol over using the NFS protocol include:

  • Simplified setup

    No third-party services are required between the client and CephFS, whereas an NFS layer can introduce an additional point of failure.

  • No additional load balancing

    Making NFS highly available requires setting up additional load balancers, which is unnecessary with direct CephFS access.

  • Enhanced access control

    CephFS shares can be restricted using cephx authentication, whereas NFS only allows access restrictions based on IP addresses.

For the CephFS driver to function, the manila-share service must have access to the Storage Access network. To mount created shares, the client must have access to the Storage Access network, the share URL, and credentials. The URLs and credentials for created shares are exposed to clients through the Manila API.

Note

Due to the existing limitation for Ceph clusters, Ceph Monitor services are only accessible on the MOSK LCM network. Therefore, both the manila-share service and clients require access to the MOSK LCM network. By default, manila-share already have access to this network. However, to enable access for external clients, for example, client VMs, routing must be configured between the client VM and the MOSK LCM network.

Untitled Diagram

The risks of direct connection of client VMs to the Storage Access Network include:

  • A malicious host on the same network may attempt to attack or scan other clients or the Ceph cluster

  • A malicious host may intercept and manipulate communication, acting on behalf of a valid client or Ceph cluster (a man-in-the-middle attack)

The following measures can help reduce these risks:

  • Ensure that port security is enabled on client VM ports connected to Ceph networks, which is enabled by default on OpenStack networks

  • Ensure that the Ceph cluster and client use the msgr2 protocol with CRC and secure modes enabled, which are enabled by default for MOSK deployments

  • Configure OpenStack security groups for client VM ports to allow traffic only from trusted hosts

Enabling Shared Filesystems service

The Shared Filesystems service is not included into the core set of services and needs to be explicitly enabled in the OpenStackDeployment custom resource.

To install the OpenStack Manila services, add the shared-file-system keyword to the spec:features:services list:

spec:
  features:
    services:
      - shared-file-system

The above configuration installs the Shared Filesystems service with the generic driver configured.

Enabling CephFS driver for Shared Filesystems service

Available since MOSK 25.1 TechPreview

Caution

MOSK does not support enabling both the generic driver and CephFS driver in the same environment. If the CephFS driver is enabled in an environment where the generic driver was previously enabled, the CephFS driver will replace the generic one.

The CephFS driver is not enabled by default in the Shared Filesystems service. To enable the CephFS driver:

  1. Verify that CephFS is enabled in the Ceph cluster as described in Configure Ceph Shared File System (CephFS).

  2. Add the following configuration to the OpenStackDeployment object:

    spec:
  features:
    manila:
      share:
        backends:
          cephfs:
            type: statefulset
            values:
              conf:
                manila:
                  DEFAULT:
                    enabled_share_backends: cephfs
                  cephfs:
                    share_backend_name: cephfs
                    share_driver: manila.share.drivers.cephfs.driver.CephFSDriver

See also