IT Is Power. Try Living Without A Single Breadboard For A Day.

Don MacVittie

Subscribe to Don MacVittie: eMailAlertsEmail Alerts
Get Don MacVittie via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: SOA & WOA Magazine, F5 Networks

Blog Feed Post

Given Enough Standards, Define Anarchy

Time to rethink what has seemed natural all along

If a given nation independently developed twelve or fourteen governmental systems that all sat side-by-side and attempted to cooperate but never inter-operate, then anarchy would result. Not necessarily overnight, but issues about who is responsible for what, where a given function is best handled, and more would spring up nearly every day.


Welcome to storage networking. Over the years this field has grown more independent standards than WarCraft has users. Many of them were required for the times, hardware, connectivity, whatever. Others were required because a given vendor thought they were going to corner the market with this new thing… But there are many.

And the storage market has matured. We all know how to use NAS, we’re all up on SAN, we are moving past these infrastructure elements and worrying more and more about what’s stored upon them and how to get it from where it’s stored to where it is needed. Time to rethink what has seemed pretty natural all along. I’ll give you an overview of those getting the most noise, even if they’re not necessarily the ones with the most data running through them, and then let’s talk about it for a bit, shall we?CableMess

  • AoE ATA over Ethernet. In essence, sending SATA commands over the ethernet wire to a target that understands what to do with them. Uses Ethernet, not TCP/IP.
  • CIFS Good old fashioned windows file sharing over TCP/IP. Used and abused in every enterprise on the planet to map remote folders to servers/desktops via TCP/IP.
  • ExpEther A completely new one to me, but essentially PCI Express shared between multiple computers that can accommodate storage devices.
  • FCoE Fiber Channel Over Ethernet. Put an ethernet connection between client and host, and replace your FC HBA with an FCoE HBA, and Bing! The catch is, of course, that the target needs to support FCoE.
  • iSCSI Same as FCOE and AoE except it works with SCSI block commands over TCP/IP. Not a bad little protocol but certainly requires more setup than CIFS or NFS.
  • NFS The age-old UNIX file sharing protocol. Interchangeable with CIFS (oh please, it is too, the only difference is which the target supports), lends itself to UNIX/Linux better than CIFS (surprise!), and is (slightly) less chatty.
  • SATA/SAS/SCSI these have been channeled out just about every port on your laptop from USB to Ethernet, but they’re really designed as a way to talk directly to disk on your computer.
  • There are so many more… The mind, it hurts…

And no, convergence doesn’t solve the problem, while it might limit remote wired FC, it doesn’t settle on a single protocol.

We Have But One Need – store our data.

We have such a mish-mash of solutions floating about our data centers today that it sometimes makes me wonder how it all works together. There are iSCSI and NAS targets that have Fiber Channel behind them, and in some cases that FC is FCoE, there are SATA SANs out there that take FC in and use SATA out the back – not so unusual in today’s marketplace, but truly odd if you think about it – we’re going through protocol conversion just to write a block of data to disk. All iSCSI has something behind it, NAS, SAN, Direct Attached JBOD… It’s ugly. Very very ugly.

I am not the industry visionary to move things along here – I have other responsibilities - but someone needs to get a group of independent people together (sorry storage vendors, you’d muck up the works, even though your technical expertise is the best in the world for this), and put forward a single protocol for communications with storage. Maybe I’m a dreamer, but I think the time has come. When competing drive manufacturers required different standards to stay competitive, this type of hokey-pokey made a lot more sense. When Fiber Channel was horribly expensive and Windows or Novell file servers packed with disk were the dirt-cheap option, this also made sense. Today, most of the reasons put forward for continuing with a dozen or more ‘standards’ are, to quote General Sherman Potter from MASH… Horse pucky. The few that are real – like using different storage types for different functions – could be answered in a new standard and still only use a single protocol. They are also largely created by the environment in which storage grew up, and a fresh look would resolve them.

How disks communicate with your computer is a pure hardware problem that doesn’t need to leak into the protocol discussion, only “how do I connect to a remote bit of storage” that could be extended to the cloud, is the same set of steps for every instance, is securable by industry-standard encryption methods, uses a single transport medium (ethernet) and is publicly documented so that customers and vendors alike get the benefits.


image That would free storage vendors to worry about add-on functionality, simplify interoperability testing, and provide an understandable and easy-to-access API to third party developers. To me the only negative is that you’d have to get the storage vendors to all support it, without embrace-and-extend, when they’re already slating development hours for things that increase their competitive edge. But that “only negative” is enough to make me believe it won’t happen – at least won’t happen any time soon. Because storage vendors are still vendors, and they still have to focus resources where they’re going to bring them business, and the storage world has long believed that interoperability provides customers with mobility, and when a single customer is as much as hundreds of thousands of dollars a year, you don’t spend your limited dev time making it easier for them to leave your stable.

So the short summary is that this is technologically feasible, but it would take an herculean effort to get it implemented across server and storage vendors. Technically, a couple of the above protocols come close to this, but they’re not intuitive to configure, and I think that’s a key also. If you have to learn SAN terminology to set up a remote disk, that’s too much.

Will this happen? Well, hard drive vendors figured it out a few years ago, but only after the market had been reduced to a couple of vendors, so I honestly don’t know. I think that customers would be better served by a long shot, and innovation would grow, but there has to be a driving reason for vendors to buy in, and historically speaking that reason isn’t there… Or arrays would have homogenous management tools built in.

Read the original blog entry...

More Stories By Don MacVittie

Don MacVittie is founder of Ingrained Technology, A technical advocacy and software development consultancy. He has experience in application development, architecture, infrastructure, technical writing,DevOps, and IT management. MacVittie holds a B.S. in Computer Science from Northern Michigan University, and an M.S. in Computer Science from Nova Southeastern University.