Shared Filesystems service¶
Available since MOSK 22.5 TechPreview
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.
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 back end should
serve as the destination for a share creation request
manila-share
Responsible for managing Shared Filesystems service devices, specifically the back-end 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 divers 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.
Let’s describe the Generic driver as 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.
Enabling the 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