One of the things that always happens when a new term comes up in our industry is confusion about what it really means. This is after the phase when everyone claims that the term is actually not new and is something that they've been doing all along. I've already blogged about that phase of SDS here.
Now we are in the (very healthy) phase where we all argue about what the term REALLY means. This is really good progress!!
One thing that I'm seeing consistently on the web is references to things that look suspiciously like Storage Hypervisors being defined as Software Defined Storage. Let's be clear: Storage Hypervisors are a very good thing, but they are not the same as SDS.
SDS is a Storage Management Architectural Pattern that allows for the remote management and configuration of storage assets. Storage Virtualization is a technique for creating "virtual" storage assets (LUNS, Shares, Objects) on top of heterogeneous storage platforms.
Let's say you had four arrays from four different manufacturers. To make this simple, let's say they're all block devices that support iSCSI (yes, simplistic but stay with me here). If I were to apply an SDS style architecture, I would simply create a control plane (like ViPR from EMC) to manage them. Whenever I wanted to do anything (provision a LUN, unmask a LUN, turn on Dedupe, etc.) I would go to the SDS control plane and issue my requests. I would be ignorant of the underlying implementation (it's an ABSTRACTED control plane) but what I get back is an IP address pointing to the iSCSI end point on the actual SAN that I already had. Thus, SDS allows me to abstract the management of my SAN but does not fundamentally change my data path. Got it? OK...
Let's take the same example, and install a Storage Hypervisor. In this case, I install an appliance (either virtual or physical) and that appliance then mounts LUNs against my existing four arrays. See the immediate difference here? In this case, the Storage Hypervisor is the consumer of the storage. Then, the storage hypervisor does it what it does (formats with it's own file system, adds meta data, etc.) and then RE-PRESENTS this storage to the actual clients. This can be in the form of new LUNS or shares or whatever. AT THE SAME TIME, this storage hypervisor might have a very slick SDS style abstracted management layer. However, these are totally separate things.
For an example of this, take a look at the V-Series from NetApp. These are basically NetApp head units that mount LUNs from non NetApp arrays. They then format the luns with WAFL and pretend they're disks. This is a great example of a "storage hypervisor" but not really SDS since it does not offer an abstracted control plane.
Got it? Awesome!!
