Separate Silos

Those involved with OpenStack quickly get the impression that the subject of cloud storage has finally been solved, because at a key point in the setup, OpenStack Cinder makes sure virtual machines (VMs)are provided with storage in the form of persistent block devices (Figure 1). However, you will quickly notice that Cinder still has shortcomings – namely, at the point which persistent, shared storage, rather than just persistent storage, is requested. NFS and CIFS implement this shared storage in classic computing environments, but Cinder has no solution whatsoever for this use case, leaving you out in the cold.

Figure 1: Cinder might take care of storage in OpenStack, but it only handles persistent block storage.

Yet, just as in classic setups, a cloud environment has the need for shared storage, so cloud customers also should be able to access shared memory from several VMs – and even beyond the boundaries of their own project. One of OpenStack's biggest strengths is its modularity, so it is no wonder that a component has been created that addresses the issue of shared memory: OpenStack Manila [1]. The aim of this module is to make it possible for VMs to use NFS and CIFS in OpenStack (Figure 2). In this article, I explain the project in detail, highlight the weaknesses in the implementation, and explain which setups can be implemented in OpenStack using Manila.

Figure 2: Manila attaches the shared filesystems shares to VMs and allows them to be used.

Usage Scenarios

Why are shared filesystems in clouds important? After all, you have other ways to make files available for several VMs at the same time (i.e., Amazon's S3 protocol, which involves applications storing statistical user data in an object store). A classic example is web shop assets (e.g., product images). They rarely change but are required by multiple clients at the same time.

Images are so well suited for object storage because they are binary objects, so each image is stored in S3 and is referenced from within the application with its full S3 path. The customer's web browser downloads the respective image directly from S3; in the end, the website looks just as the provider desires.

Unfortunately, there is a snag when it comes to legacy applications. Web shops, for example, normally assume that their assets are stored on a central shared filesystem, which the website links reference. NFS is usually used in this case, so anyone wanting to put such an application on the cloud has multiple options.

One option is to convert the web shop software so that it can load its statistical data from S3-compatible storage. This may be pedagogically correct, but the plan often fails in reality because the web shops are proprietary software, and the source code isn't even available to the web shop operator.

Even if the source code is available, porting to S3 capability isn't exactly easy: S3 modules might be available for common scripting languages in web design (e.g., for PHP); however, weeks or months go by before a large environment such as a web shop is completely converted and tested in this manner.

From the perspective of the website operator, there are certainly strong reasons not to change too much in the web application and instead to upgrade externally the functions that can best be used to run the application.

Clash of Culture: NFS and OpenStack

OpenStack and NFS can fundamentally be operated together without separate components. The simplest scenario is to start the VMs of a setup on a private network and then run an NFS server on one of the VMs.

However, what sounds good in theory is only really practical to a limited extent: Such a setup doesn't offer the option of also making the contents of the NFS server available to VMs that are not on the same private network. Specifically, this can mean the provider needs to keep these (identical) images in several locations on the cloud. Given the usual method of invoicing for clouds (pay per use), this isn't a very attractive option.

The problem illustrates the fundamental contradiction when combining OpenStack and the shared filesystem that Manila attempts to resolve: OpenStack does not provide the option to make filesystems available to different clients beyond the limits of private networks. However, this is just what Manila aims to achieve; incidentally, it also insists on turning NFS or CIFS shares into qualified resources.

Qualified Resources

The second major difference from a DIY solution is hidden in the term "qualified resources": OpenStack Manila provides an option for managing NFS or CIFS shares directly at the OpenStack level. You can now create and delete NFS shares using commands directly via the cloud APIs; you can also directly configure access to these shares at the API level. Manila therefore looks after the NFS server operation, and users don't need to worry about this issue anymore. In the best case scenario, a simple mouse click in the OpenStack dashboard is enough to access a NFS share that can then be connected to all individual VMs.

Another advantage is that, in principle, it is possible to use OpenStack resources directly from the various automation and orchestration solutions. Users also can create an NFS share automatically in a template for the OpenStack orchestration Heat service, which starts many VMs at the same time and creates matching networks. If NFS were running in a manually installed VM project instead, this very type of control would be impossible.