Storage: Yesterday, Today, and Tomorrow (Part 1)

(This post is the first of a series of posts I will be publishing over the next few weeks on storage paradigm shifts, focusing on NetApp’s new DataONTAP 8.1 Cluster-Mode)

For a few years now, we’ve heard the catch phrase, even from me, that:

“Virtualization Changes Everything.”

Well, I think that’s right.  But I think in our industry, it tends to get focused on the server hypervisors, and people tend to get tunnel-visioned into thinking about virtual server architectures, and how to do more with less.

What if we applied the same M.O. to storage?
What if the most valuable lesson we have learned from VMware is the idea of doing more with less…not particularly “how”?


(We’ll come back to those in a bit…)

The storage industry has been all wrapped up in itself in recent years competing with each other over things like dedupe, thin provisioning, unified management, and various backup & recovery mechanisms.  It turns into a bunch of hoopla about who does what better, and ultimately leaves customers with nothing to really be excited about.  Each vendor comes out with the “new feature” but no one has really changed the game in quite a few years.  NetApp is going to tell you that dedupe did.  True, but that was ~2008.  EMC is gonna come at you and tell you that VNX is, but taking everything out of the fridge and wrapping it up in cling film and calling it “Unified,” isn’t really getting it done.

Well, I’m here to tell you:  It’s time that changed.

Think back for a second to the early part of the 2000’s… call it the pre-virtualization era, if you will.  Purpose-built silo’s, hosting purpose-built applications, driven by purpose-built employees, using 10% of resources allocated to them.  No matter what position you want to take, this could definitely be identified as a “root cause” for the rampant adoption of virtualization.

(Side note:  The fact that 100% of software vendors have still not embraced virtualization, and that we still have to deal with certain devs that “don’t support running XYZ app in a VM” baffles me every day.)

So, that takes care of the servers.  But what about the storage?

Well, you could make the argument that some are still operating under the same-ol’ “purpose-built” M.O.   The cool thing I always appreciated, even as a customer before, about DataONTAP was the idea of the central operating system.  No matter what platform or model number I wanted, the commands were the same.  That’s often taken for granted, so I want to repeat that:  No matter what platform or model number, the commands are always the same.

As a customer, I POC’ed both Equalogic (pre-Dell) and EMC gear, and it just didn’t resonate with me.  I’m being honest here, taking the NetApp shirt off for a minute.  But what did resonate with me was the idea that one man CAN really run a giant datacenter, given the proper tooling, centralized mgmt software, and a consistent platform to host it all.  VMware.

For all of you that think VMware is successful because of it’s hypervisor, that’s just not the case.  They’re successful (in my humble opinion) because of the centralized model of their management portfolio.  They embraced a common framework with vCenter, CIM, and the plugin extensibility.  You can literally run an entire datacenter, or multiple datacenters from a single common interface.  For those of you running heavily-virtualized shops today, this needs no explaining… you know exactly what I’m talking about.

I would argue that this, too, would equate to a lot of NetApp’s success.  DataONTAP.  Metal is simply a means to scale.  From the smallest ONTAP-v VSA, all the way up to our flagship FAS6280, the commands to provision a volume, or configure an interface, or add disks to an aggregate, are all the same.  THAT, my friends, is what’s important. Yea, snapshots and dedupe and thin provisioning are cool and all, but… well, you get my point.  THIS is the definition of “Unified.”  For the exact same reasons that it is for VMware.

So, let’s take this a bit further, and revisit a point I brought up earlier…

What if DataONTAP could do for storage what VMware did for servers?
What if you could lump multiple storage controllers into a logical “cluster” like ESXi hosts?
What if you could connect hosts to logical VM-like entities that could move among any node in that cluster?
What if you could “vMotion” a storage controller between cluster nodes without loss of service?
What if you could multipath to that storage “VM” from a variety of hostOS’s and protocols?

Well, it’s here.  And it’s called DataONTAP 8.1 Cluster-Mode.  More technical details coming in followup posts over the next week, including how it will work specifically with vSphere.

Give me your feedback below!

Does the idea and promise of this excite you?
Interested in testing out the RC versions? (you can with your NOW account!)
What questions do you have about it that you need answered?  (So I can include them in a followup post!)
What apprehensions would you have about clustered shared storage?

You can read Part 2 of this series HERE!


  1. Ed Grigson

    I’m looking forward to this series Nick. We’ve got a bunch of controllers in 7 mode and I know very little about cluster mode. The ability to scale out sounds like a good step.

    Can you cover the upgrade/migration aspects in a post? I know we’ve got 32 bit and 64 bit aggregates to migrate (looking forward to 8.1’s seemless moves for this) but I’m sure there’s enough for a chunky article.

    1. Nick Howell


      Great hearing from you!  Glad you’ll be keeping an eye on the series!

      I cannot speak to the specifics of the migration path roadmap.  That’s more for the DataONTAP engineers.  However, if I were a betting man, and we go on previous trends (like the one you mentioned about 32->64bit aggr’s…there wasn’t one in 8.0.x but there will be in 8.1), we will likely not see a seamless migration path from one to the other in the initial release (8.1).  But I would bet that it is certainly stewing around in their heads on how to get it done in later releases.

      Right now, you “enable” cluster-mode by flipping a switch in Maintenance Mode during bootup to tell it to boot as C-mode (hopefully this hasn’t changed since last I built one and I’m not telling you a lie…).  So in order to do this, a reboot at minimum is required.

      Thanks for the post suggestion.  I’ll definitely dig into it with the DOT team and get some meat for a good post.


      1. Guest

        I seriously doubt it. In 8.1.x I’d expect a better migration path through the ability to Snapmirror data between the two types of systems. However, I cannot envisage a magic bullet approach to upgrading. Lets hope the ONTAP monkeys prove me wrong :-)

Leave a Comment

Sign Up

New membership are not allowed.