Generic Back End

Detractors like to accuse the OpenStack developers of reinventing the wheel at every possible opportunity. But the Manila developers have exposed that as a prejudice: Anyone who wants to use Manila without special storage can use the generic back end, which is directly connected with Cinder when correctly configured (Figure 3). This back end configures a volume in Cinder according to the configuration set for Manila by the cloud admin. Nova then launches a VM that uses this volume.

Figure 3: Anyone running Manila with the generic back end needs to make sure the service can communicate with Nova, Neutron, and Cinder.

In this scenario, Nova relieves Manila of all the network work: The freshly launched VM simply receives its own port in the virtual customer network. The back end then configures a service for the desired protocol – usually NFS or CIFS – on that VM and finally displays the path for access to the created volume. Only the obligatory mount command is missing on the VMs to use the shared filesystem.

Manufacturer-Specific Back Ends

The generic back end naturally creates a large amount of overhead during this process; even the VM eats up resources and costs hard cash, depending on the invoicing model. Many manufacturers of storage solutions therefore have a vested interest in providing Manila users with alternative drivers for their products. For example, the NetApp driver for Manila makes sure that the shares of an ONTAP instance are directly inserted in Manila and are available to VMs through Manila. EMC and HP Enterprise follow similar approaches for their storage solutions (i.e., Isilon, 3PAR).

IBM's general parallel filesystem (GPFS) has a back-end driver, as does GlusterFS and the Quobyte data center filesystem, which is also POSIX-compatible. Manila thus effectively addresses practically every OpenStack setup: If you use one of the storage solutions with a private driver, you use that driver. Alternatively, the generic driver for Cinder is an option.

Using Shares Efficiently

Creating a share is one thing, but managing the drive efficiently is another: In everyday life, it might be necessary to enlarge or reduce the existing share. Admins might also want to create snapshots of the respective share for backup purposes to access them later after a restore.

The good news is that the features mentioned are already provided in the Manila code. The bad news is that features available on an individual basis strongly depend on the driver for the back-end storage being used. Technically speaking, this wouldn't be feasible any other way. For example, how is Manila supposed to create snapshots on a ONTAP device from NetApp without using the NetApp internal tools for this purpose?

In practical terms, however, this just means that the quality of the Manila driver for the respective back-end storage is crucial. It is a good tradition that companies that want to connect to Manila with their storage solution maintain their Manila drivers themselves. Anyone who wants to use the corresponding features effectively is best off taking a look at the mapping of share drivers and features [2] in the Manila documentation when planning their setup to make sure the storage driver really fits the requirements (Figure 4).

Figure 4: On the OpenStack website, the Manila project provides a good overview of the existing drivers and their capabilities.