Shared File Systems service provides a set of services for management of shared file systems in a multi-project cloud environment. The service resembles OpenStack block-based storage management from the OpenStack Block Storage service project. With the Shared File Systems service, you can create a remote file system, mount the file system on your instances, and then read and write data from your instances to and from your file system.
The Shared File Systems service serves same purpose as the Amazon Elastic File System (EFS) does.
The Shared File Systems service can run in a single-node or multiple node configuration. The Shared File Systems service can be configured to provision shares from one or more back ends, so it is required to declare at least one back end. Shared File System service contains several configurable components.
It is important to understand these components:
- Share networks
- Shares
- Multi-tenancy
- Back ends
The Shared File Systems service consists of four types of services, most of which are similar to those of the Block Storage service:
manila-api
manila-data
manila-scheduler
manila-share
Installation of first three – manila-api
, manila-data
, and manila-scheduler
is common for almost all deployments. But configuration of manila-share
is backend-specific and can differ from deployment to deployment.
- Key concepts
- Share management
- Share types
- Share group types
- Share groups
- Share snapshots
- Share servers
- Share server management
- Share server limits (Since Wallaby release)
- Security services
- Share migration
- Share replication
- Multi-storage configuration
- Networking
- Troubleshoot Shared File Systems service
- Profiling the Shared File Systems service
- Upgrading the Shared File System service
- Share revert to snapshot
- Share server migration
- Manila share features support mapping
- Capabilities and Extra-Specs
- Group Capabilities and group-specs
- Export Location Metadata
Supported share back ends
The manila share service must be configured to use drivers for one or more storage back ends, as described in general terms below. See the drivers section in the Configuration Reference for detailed configuration options for each back end.
- Container Driver
- ZFS (on Linux) Driver
- NetApp Clustered Data ONTAP
- Isilon Driver
- VNX Driver
- Dell EMC Unity driver
- Requirements
- Supported shared filesystems and operations
- Supported Network Topologies
- Pre-Configurations
- Backend configurations
- Supported MTU size
- IPv6 support
- Pre-Configurations for IPv6 support
- Supported share creation in mode that driver does not create and destroy share servers (DHSS=False)
- Snapshot support
- Pre-Configurations for Snapshot support
- To snapshot a share and create share from the snapshot
- To manage an existing share server
- To un-manage a Manila share server
- To manage an existing share
- To un-manage a Manila share
- To manage an existing share snapshot
- To un-manage a Manila share snapshot
- Supported security services
- IO Load balance
- Default filter function
- Restrictions
- API Implementations
- Driver options
- Generic approach for share provisioning
- GlusterFS driver
- GlusterFS Native driver
- CephFS driver
- Supported Operations
- Prerequisites
- Authorizing the driver to communicate with Ceph
- Enabling snapshot support in Ceph backend
- Configuring CephFS backend in manila.conf
- Space considerations
- Creating shares
- Allowing access to shares
- Mounting CephFS shares
- Known restrictions
- Security
- The
manila.share.drivers.cephfs.driver
Module
- GPFS Driver
- Huawei Driver
- HDFS native driver
- Hitachi NAS Platform File Services Driver for OpenStack
- HPE 3PAR Driver for OpenStack Manila
- Infortrend Driver for OpenStack Manila
- Macrosan Driver for OpenStack Manila
- Pure Storage FlashBlade Driver for OpenStack Manila
- Tegile Driver
- NexentaStor5 Driver for OpenStack Manila
- Windows SMB driver
- Zadara VPSA Driver for OpenStack Manila