Clutter of Concepts

Anyone starting out with OpenStack Manila will be faced with a tide of terms and names that have their own meanings in a Manila context. First and foremost is "the share": The share is the OpenStack resource you use to work at the OpenStack API level. Users create shares or delete them, take snapshots of shares, or restrict the access permissions for their own shares. Shares support various protocols, including CIFS and NFS.

The back end is directly connected to the share: In Manila, a back end means an instance of the Manila file share service that communicates with an external storage solution. This is operated by the share servers (i.e., a Manila-specific server that connects a back end to a share). Back ends may be any devices or services that provide storage on demand.

The share servers are a bridge construction: They are usually real VMs that start the respective back end automatically on the basis of user requirements. If a back end manages its share servers itself, it can start them from the outset so that they run in the corresponding virtual network and so that access works via the target VMs.

Not all back ends can even deal with share servers. Many back ends for special storage devices, such as NetApp or EMC, instead focus on connecting shares to the target VMs without using a separate VM as an intermediate station. These back-end drivers are marked accordingly, and Manila automatically makes sure that other network settings are used when connecting VMs with these shares.

A Fork of Cinder

At the beginning of the Manila development is a fork of OpenStack Cinder – the block storage component – which is not surprising, because although the objective of Manila is to manage shared filesystems, there are also fundamental similarities between the two types of storage, such as handling the storage for specific VMs. For both Cinder and Manila, it is still necessary to connect a storage to one VM or, as is the case with Manila, multiple VMs, by fixed assignment.

Handling memory in the background is also similar between Manila and Cinder. Neither service offers storage itself, and neither therefore has its own disk space. Instead, both services assume that the admin will provide configurable storage that they split into small pieces as required and then pass onto individual VMs.

The design of Manila then is unsurprisingly oriented on that of Cinder. Like Cinder, Manila consists of an API (i.e., the typical OpenStack solution) that allows users to send commands to the service. A separate component selects one of the available storage back ends, which then activates manila-share. This service configures a filesystem share that is then available to VMs. However, Manila is significantly more closely integrated in the concept of VMs in OpenStack than users of Cinder would know – or expect.

The Delicate Issue of Network

The basis of these differences points once again to the delicate issue of software-defined networking (SDN). OpenStack provides its own component called Neutron that takes care of all aspects of SDN. Typical OpenStack clouds strictly separate the private networks of individual customers – based on the assumption that a customer's network traffic will never come into contact with the traffic of another network.

This is not a problem for Cinder: Cinder communicates directly with the OpenStack virtualization component Nova and pins new block devices on VMs via the hot-plug function of the hypervisor (i.e., via KVM in most cases). Therefore, it is enough if Nova and Cinder can communicate with each other via the cloud's management network.

Manila, on the other hand, must rely on the VMs being able to communicate in a private network with an NFS share, which – depending on the setup – might be located in a different private network. The problem can be solved in multiple ways in OpenStack. Option one is to create a shared network that all connected VMs can access. Option two is to allow access via router in OpenStack.

Option three builds on the approach of attaching a share directly to a private network so that only VMs within the network can access the share. This option may be the safest because it prevents unauthorized external access; however, it also makes it impossible to use shares in several projects at the same time.

Which network options are available in a setup depends on the back end being used. Drivers that support share servers are inherently flexible: A separate VM is launched that can be connected in the existing virtual networks. Anyone who uses one of the manufacturer-specific drivers instead must do without this luxury. The storage network and the private customer networks are often on different layers in the network stack (layer 2 vs. layer 3). Manila then makes new plans and builds a bridge construction, such as via an OpenStack router or via a previously specified shared network.