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 (Cinderis 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 associationyet.

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 aboutdeterministic trafficto the storage device. That is, "storage" is more than the array -it's therelationshipbetween the storage deviceandits 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 speakingforthem!), 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.