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 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 services communicate with each other.
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.
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.
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.
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.
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:
Verify that CephFS is enabled in the Ceph cluster as described in Configure Ceph Shared File System (CephFS).
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