This week has been the semi-annual OpenStack Summit in Atlanta, GA. In a rare occurrence I’ve been able to be here as an attendee, which has given me wide insight into a world of Open Source development I rarely get to see outside of some interpersonal conversations with DevOps people. (If you’re not sure what OpenStack is, or what the difference is between it and OpenFlow, OpenDaylight, etc., you may want to read an earlier blog I wrote that explains it in plain English).
On the first day of the conference there was an “Ask the Experts” session based upon storage. Since i’ve been trying to work my way into this world of Programmability via my experience with storage and storage networking, I figured it would be an excellent place to start. Also, it was the first session of the conference.
During the course of the Q&A, John Griffith, the Program Technical Lead (PTL) of the Cinder project (Cinder is the name of the core project within OpenStack that deals with block storage) happened to mention that he believed that Cinder represented software-defined storage as a practical application of the concept.
I’m afraid I have to respectfully disagree. At least, I would hesitate to give it that kind of association yet.
What Cinder Is
Cinder is a way of handling storage elements inside an OpenStack environment. When I say storage, I’m talking about the actual storage elements that hold data. For example, Cinder has the capability of handling (among other things):
- Volumes (creation, deletion, attaching, detaching, extending)
- Snapshots (creation deletion, listing)
- Cloning
- Migration from one volume to another
If you take a look at the matrix I linked to, you’ll see a propensity for iSCSI support, with limited FC and NFS capabilities, It’s an impressive list of support, although the extent to which Cinder features are supported by all these vendors is unclear to me.
What Cinder Is Not
Cinder, however, does not take into consideration the bulk of storage systems today. That is, the 11 Billion ports of Fibre Channel that currently exist as part of a holistic system of storage networking. This is not including the hundreds of millions of FCoE ports, nor the thousands (millions?) of ports using Lossless iSCSI.
The issue as I see it is that it appears the approach is to identify these protocols as simply having a way to reach a storage end-point. To that end, you can create a “software-defined” solution if this is simply a matter of getting there.
A storage system, however, is about deterministic traffic to the storage device. That is, “storage” is more than the array – it’s the relationship between the storage device and its network.
Storage is more than the sum of its parts.
To me, this is too great an omission. In order to be able to say that storage is “software-defined,” it is a requirement that storage as a system be not just considered, but accommodated and expected.
It’s best not to think of this in terms of protocols, but rather whether or not the storage traffic is deterministic. Once you realize that the paradigm for storage is dependent upon this, you realize just how much further we have to go with Cinder’s current approach (Neutron, too).
There is a reason why storage has such an intimate and symbiotic relationship with its corresponding network. Performance is only one of those concerns – reliability, accessibility, availability, and traffic contention are all important factors that each have their own consequences in a data center.
Cinder’s networking cousin within OpenStack, Neutron makes no provision for storage networks either. It appears that a ‘reliable, un-congested network for storage’ is just the working assumption.
In storage networking, however, that is the exact opposite of the paradigm that we use. When we plan for storage accessibility – especially block storage (upon which we run financial traffic, booting images, database applications, etc.) we plan in advance for how heavily the network is going to be taxed by adding additional devices.
Currently neither Cinder nor Neutron provides for such a capability.
What Cinder Needs
Developers for Cinder (and Neutron?) need to understand this tightly-coupled relationship better. Personally, while I can’t program my way out of a paper bag, I may not be able to help contribute code or design elements to the projects itself.
But there are many, many people who can. I know that there is a lot of debate about standards technology within the Open Source community, but many of these problems have been considered and solved in the past 20 years. Organizations like the T11 and the Fibre Channel Industry Association (FCIA), as well as the Storage Networking Industry Association (SNIA), have spent years pondering these problems and working through vendor-neutral solutions.
Speaking as a member of the Board of Directors for both organizations (but not speaking for them!), I know from personal experience the depth of knowledge that can be a rich source to the developer community. I know for a fact that both groups want to work closely with the community to share knowledge and work towards the next level of technological innovation.
Why reinvent the wheel?
Call to Action
I would like to invite individuals from both groups – the developer/Open Source community and the storage standards groups to cross-pollinate ideas. There are certainly opportunities to engage and participate, to learn. For instance, there is no cost to attend a T11 meeting and it’s open to anyone who’s interested!
Likewise, I highly encourage the established storage networking people – and this includes vendors who participate in those associations – to reach out to the developer counterparts. Attend the summits (whether they be OpenStack, OpenDaylight, OpenFlow, etc.). Most importantly, contribute your expertise into the Open Source community.
Only then can we actually achieve what I believe John Griffith is driving the Cinder project towards, and I believe he deserves all the assistance he can get from everyone who has it within their capacity to make a better storage environment.
Hi J,
I agree but you have to take into account the birthplace Openstack came from as well as the pathway it has traveled in a fairly short timeframe. Hooking up people from the Cinder community and the likes of the SNIA Storage Developers Conference members/attendees would be a very good push in the right direction.
Cheers from DownUnder,
Erwin
Hi Erwin –
Yup. I completely agree. Considering where the OS community has its roots, I get your point. Through some of the conversations about what people want to do with it, though, it’s surprising to me how many of them are willing to re-invent the wheel when they don’t have to. I would really like to see them capitalize on the hard work (and mistakes!) that have already been made in order to get OS to succeed even faster.
Hope you’re keeping warm. 🙂
J