GlusterFS Native driver
GlusterFS Native driver uses GlusterFS, an open source distributed file system,
as the storage backend for serving file shares to manila clients.
A manila share is a GlusterFS volume. This driver uses flat-network
(share-server-less) model. Instances directly talk with the GlusterFS backend
storage pool. The instances use ‘glusterfs’ protocol to mount the GlusterFS
shares. Access to each share is allowed via TLS Certificates. Only the instance
which has the TLS trust established with the GlusterFS backend can mount and
hence use the share. Currently only ‘rw’ access is supported.
Network Approach
L3 connectivity between the storage backend and the host running the manila
share service should exist.
Supported shared filesystems
- GlusterFS (share protocol: glusterfs,
access by TLS certificates (cert access type))
Multi-tenancy model
The driver does not support network segmented multi-tenancy model. Instead
multi-tenancy is supported using tenant specific TLS certificates.
Supported Operations
- Create share
- Delete share
- Allow share access (rw)
- Deny share access
- Create snapshot
- Delete snapshot
- Create share from snapshot
Requirements
- Install glusterfs-server package, version >= 3.6.x, on the storage backend.
- Install glusterfs and glusterfs-fuse package, version >=3.6.x, on the manila
host.
- Establish network connection between the manila host and the storage backend.
Manila driver configuration setting
The following parameters in manila’s configuration file need to be set:
- share_driver =
manila.share.drivers.glusterfs.glusterfs_native.GlusterfsNativeShareDriver
- glusterfs_servers = List of GlusterFS servers which provide volumes
that can be used to create shares. The servers are expected to be of
distinct Gluster clusters (ie. should not be gluster peers). Each server
should be of the form [<remoteuser>@]<glustervolserver>.
The optional <remoteuser>@ part of the server URI indicates SSH
access for cluster management (see related optional parameters below).
If it is not given, direct command line management is performed (ie.
manila host is assumed to be part of the GlusterFS cluster the server
belongs to).
- glusterfs_volume_pattern = Regular expression template
used to filter GlusterFS volumes for share creation. The regex template can
contain the #{size} parameter which matches a number (sequence of digits)
and the value shall be interpreted as size of the volume in GB. Examples:
manila-share-volume-\d+$, manila-share-volume-#{size}G-\d+$; with
matching volume names, respectively: manila-share-volume-12,
manila-share-volume-3G-13”. In latter example, the number that matches
#{size}, that is, 3, is an indication that the size of volume is 3G.
The following configuration parameters are optional:
Host and backend configuration
- SSL/TLS should be enabled on the I/O path for GlusterFS servers and
volumes involved (ie. ones specified in glusterfs_servers),
as described in http://www.gluster.org/community/documentation/index.php/SSL.
(Enabling SSL/TLS for the management path is also possible but not
recommended currently.)
- The manila host should be also configured for GlusterFS SSL/TLS (ie.
/etc/ssl/glusterfs.{pem,key,ca} files has to be deployed as the above
document specifies).
- There is a further requirement for the CA-s used: the set of CA-s involved
should be consensual, ie. /etc/ssl/glusterfs.ca should be identical
across all the servers and the manila host.
- There is a further requirement for the common names (CN-s) of the
certificates used: the certificates of the servers should have a common
name starting with glusterfs-server, and the certificate of the host
should have common name starting with manila-host.
- To support snapshots, bricks that consist the GlusterFS volumes used
by manila should be thinly provisioned LVM ones (cf.
https://gluster.readthedocs.org/en/latest/Administrator%20Guide/Managing%20Snapshots/).
Known Restrictions
- GlusterFS volumes are not created on demand. A pre-existing set of
GlusterFS volumes should be supplied by the GlusterFS cluster(s), conforming
to the naming convention encoded by glusterfs_volume_pattern. However,
the GlusterFS endpoint is allowed to extend this set any time (so manila
and GlusterFS endpoints are expected to communicate volume supply/demand
out-of-band). glusterfs_volume_pattern can include a size hint (with
#{size} syntax), which, if present, requires the GlusterFS end to
indicate the size of the shares in GB in the name. (On share creation,
manila picks volumes at least as big as the requested one.)
- Certificate setup (aka trust setup) between instance and storage backend is
out of band of manila.
- For manila to use GlusterFS volumes, the name of the trashcan directory in
GlusterFS volumes must not be changed from the default.
The manila.share.drivers.glusterfs.glusterfs_native.GlusterfsNativeShareDriver Module
GlusterFS native protocol (glusterfs) driver for shares.
Manila share is a GlusterFS volume. Unlike the generic driver, this
does not use service VM approach. Instances directly talk with the
GlusterFS backend storage pool. Instance use the ‘glusterfs’ protocol
to mount the GlusterFS share. Access to the share is allowed via
SSL Certificates. Only the instance which has the SSL trust established
with the GlusterFS backend can mount and hence use the share.
Supports working with multiple glusterfs volumes.
-
class GlusterfsNativeShareDriver(*args, **kwargs)
Bases: manila.share.driver.ExecuteMixin, manila.share.drivers.glusterfs.layout.GlusterfsShareDriverBase
GlusterFS native protocol (glusterfs) share driver.
Executes commands relating to Shares.
Supports working with multiple glusterfs volumes.
API version history:
1.0 - Initial version.
1.1 - Support for working with multiple gluster volumes.
-
GLUSTERFS_VERSION_MIN = (3, 6)
-
get_network_allocations_number()
-
supported_layouts = ('layout_volume.GlusterfsVolumeMappedLayout',)
-
supported_protocols = ('GLUSTERFS',)