The OpenStack Manila file share service is growing up.
During a Storage Networking Industry Association (SNIA)-sponsored webcast this week, Ben Swartzlander, a NetApp architect who is the project team lead for Manila, outlined the new features in the OpenStack Liberty release that is due for general availability next week. He also gave a preview of the upcoming Mitaka release, which he estimated would be ready in late April 2016.
“There’s an infinite list of ideas for ways to enhance Manila,” Swartzlander said, “so I don’t think we’re going to run out of new things to work on for a long time.”
The Liberty release of the OpenStack Manila file-based storage service introduces some experimental APIs and features that people can use with the understanding those new capabilities could change in the future.
“It enables us to get features out into the hands of users and get feedback on them before we pour the concrete, so to speak,” Swartzlander said.
With Liberty, Swartzlander said the community focused on documentation to bring Manila up to par with the rest of the OpenStack projects, which include Swift object and Cinder block storage. Manila contributors also open sourced the generic server image, which Swartzlander admitted is “something we should have done earlier.”
Other new features in the Liberty release of OpenStack Manila include:
–Oversubscription, which Swartzlander said is “basically thin provisioning your storage and having Manila manage the degree to which you oversubscribe your backend.” He said users could oversubscribe by a factor of 2x or 10x or whatever they are comfortable with.
–Expanding/shrinking of shares. (A share is an instance of a shared file system.) Swartzlander said the new expand/shrink feature is important “because you don’t always know how much space you’re going to need from the beginning.”
–Micro-versions, which Swartzlander described as “basically a fine-grained version of the API, so that every time you make a change to the API, we increment the version number.” He said, “The servers and clients are implemented in such a way that they can negotiate down to a version that is in common between that server and that client so that in case things have changed in the API, they can find a common version and speak that version and maintain compatibility over a wider range of releases.”
–Consistency groups, an experimental feature that allows users to snapshot multiple shares as a unit. Swartzlander cited a potential use case with storage for a database. “Maybe I want to have the table space on relatively large performing storage, and I want to have my database logs on really fast storage to maximize my database performance, and without costing too much,” he said. “But to back up my database, I need to be able to take a consistent snapshot of those two shares. ‘Consistency groups’ enables you to do that.”
–Mount automation of shares. The feature would enable users to intercept operations such as the creation of shares or granting access to a share and trigger a script to automate the mounting of the shares. He said there are different ways to do automation, but this feature covers many use cases.
“One of the major differences between block storage and shared file systems is exactly how the storage gets attached from where the bytes are to where the client is using the storage,” Swartzlander explained. “With block storage, you have a hypervisor in the middle, and the hypervisor has an API where you can tell it, ‘Go connect to this and get that storage and then provide it through to the guests.’ And the guests just see the new hard disk pop up, and the operating system then sees the new block device, and it can automate doing what needs to be done.
“With the shared file system, the mounting is actually direct from that guest [virtual machine] VM through to the backend,” he said. “The hypervisor isn’t really involved in that process, and so getting the clients to automatically mount the storage is a challenge that we’ve been aware of since the beginning of the project.”
–Share migration, an experimental feature that permits the movement of a share from one storage controller to another. Share migration will be administrator-controlled initially, according to Swartzlander.
“The use case for something like this would be evacuation of a storage controller for maintenance,” he said. “Perhaps you want to do load balancing. You have one storage controller that’s working really hard and another one that’s not working hard enough. You can move some stuff around.”
Swartzlander added that share migration would form the basis of future features such as re-typing a share, changing the type of an existing share, changing the availability of an existing share and changing the security domain.
Areas of focus for the upcoming Mitaka release include “Migration 2.0,” additional first-party open source drivers supported by the community, improved support for rolling upgrades and high availability, and share replication.
Swartzlander said the latter feature would allow Manila to configure a share to be replicated to a different availability zone. In the event of a power failure, fire or flood in the data center, users would be able to switch to the replicated copy of the data to keep an application running, he said.
“The goal is to support a wide variety of implementations,” Swartzlander said. “We have, for example, a proposal to do active-active replication or active-passive replication. Synchronous or asynchronous are both supported depending on what the vendor wants to implement and what the administrator wants to enable.”