OpenStack’s file-share service for the cloud, known by its project development name "Manila," is making progress...
toward achieving "full-blown core" status.
The OpenStack Manila shared-file system service became generally available on Aug. 26, 2014, when the open source OpenStack community formally designated Manila as an incubated project, according to Greg Loughmiller, a technical marketing engineer in the cloud solutions group at NetApp. During a Jan. 29 Storage Networking Industry Association-sponsored webcast, Loughmiller did a deep dive into Manila.
Manila followed other storage-focused OpenStack community efforts such as Swift object storage and Cinder block storage. Loughmiller said the Manila work began approximately two years ago, and efforts continue to vault the project to core status in 2015. Contributors to the project include employees from NetApp, EMC, HP, Mirantis, Red Hat and SUSE.
We caught up with Loughmiller for an introduction and update on the OpenStack Manila file-based storage service.
How would you describe Manila for those who are unfamiliar with it?
Loughmiller: Manila is a community-driven open source project to create a file-share service for an OpenStack multi-tenant cloud environment. The Manila file-share service provides a self-service model for users to provision and manage CIFS and/or NFS within an OpenStack infrastructure. Manila functions as the storage provisioning control plane in OpenStack for the shared file systems. The file shares are designed to be consumed by OpenStack Compute instances, but the service is also intended to be accessible as an independent capability in line with the modular design established by other OpenStack services.
How does Manila work, and what are its most important features?
Loughmiller: Manila provides a vendor-neutral API for the provisioning and attaching of file system-based storage to OpenStack instances [which are virtual machines]. You need storage -- either generic storage as part of your OpenStack environment or vendors' storage made available to Manila. For example, there’s a GlusterFS driver, a NetApp driver, as well as an EMC driver. Those are available right now with the Juno version of OpenStack. In the next release of OpenStack, called Kilo, there are several more drivers being made available, like GPFS by IBM and Red Hat, NFS-Ganesha, ZFS from Oracle and Huawei. Many companies and platforms are beginning to write drivers for Manila. So, Manila isn’t necessarily a storage platform but rather an enabler for storage platforms to be used within an OpenStack environment.
Manila is similar in architecture to the OpenStack Block Storage project, Cinder. Requests for file shares can be made via the OpenStack GUI interface, named Horizon, via command line interface or via a REST API interface. Those requests are passed to the Manila scheduler process, which makes provisioning decisions for each share request based on the capacity and capabilities of the storage made available to Manila. The Manila scheduler process then hands off the request to the appropriate Manila share process to physically provision the storage entity.
One important point to note is that Manila is part of the control plane and is not within the data path of the file share. Manila will orchestrate and make available the data path between the storage and the OpenStack Nova instance or instances.
Was the demand for Manila coming from vendors or end users?
Loughmiller: I think it was a combination of both. Ultimately, the demand came from their desire to move applications into a private cloud they use with OpenStack. Those applications had been using NFS file systems, for example. And they wanted to make it a self-service model for the provisioning of file-based storage. Without the ability to have shared file systems, it placed limitations on moving a certain type of application structure into the private cloud using OpenStack.
What do you foresee as the prime use cases for OpenStack Manila and for what types of end users will it be most important?
Loughmiller: The goal of Manila is to do for shared file-system storage, such as CIFS and NFS, what Cinder did for the block storage in OpenStack. The majority of the capacity of storage delivered in 2012 was for file shares. There are many applications and users that use file shares as part of their infrastructure. This prohibited a potentially large user community from being part of an OpenStack multi-tenant cloud. Manila is meant to bridge that gap for the users of shared file systems that want to have the capability to deploy a self-service, IaaS-like model, for those applications.
What types of companies or vertical industries have expressed interest in Manila?
Loughmiller: There have been various types of verticals and IT organizations looking at what Manila can do for their cloud strategy for applications that use shared file systems. The community has seen interest from the telecom, communications and health care industries, as well as universities.
There have been complaints about certain OpenStack projects being hard to use. Is Manila ready for prime time, so to speak?
Loughmiller: It's getting close. Is it like a Red Hat Linux that’s been around for 10 years? No, it’s not like that. But it is a little bit further along in its early lifecycle than some of the other projects. One of the things that the core team continues to do is improve and fix bugs as people use it. There are quite a few proofs of concepts out there right now. We know of a couple companies that are working in their environments to move this into a production state.
The generic drivers, the generic piece of Manila, is pretty strong. The vendor drivers are the ones that still need some time to mature more, but they are getting better as more development is focused on them.
What's your estimate of when Manila will be ready for prime time?
Loughmiller: The objective within the next six to 12 months is to get this from what OpenStack calls an incubated project to become effectively a full-blown core project of OpenStack. There are reviews and requirements that the core team has to go through before the technical committee would give it a designation as a core project.
Should you choose OpenStack Cinder and Swift for storage?