Software-Defined Storage: How To Pick The Right Flavor

The number of storage vendors that claim to be software-defined is reaching epidemic proportions. But the actual software-defined part of storage leaves a lot of room for interpretation. After all, most storage vendors utilize software to deliver most, if not all, of the storage features they provide to customers. Those customers are having a difficult time sorting out what is truly software-defined and what is simply a retread of an older technology.

At Storage Switzerland, we define software-defined storage (SDS) as the abstraction of storage services from the physical storage hardware. That's it. But I believe in keeping definitions simple. Adding more specifics to the definition typically means adding features that are exclusive to one vendor or another.

Admittedly, that definition also provides room for interpretation. I believe that SDS, like cloud storage, is one of those categories in which a lot of products can claim some form of membership. However, that shouldn't cause problems for you as an IT professional, as long as you stay focused on the problems you're trying to solve and look for a tool that solves those problems.

[Rumors of the imminent death of flash storage are greatly exaggerated. Read Flash Storage Extinct Soon?]

There are several vendor categories within the SDS market, each one taking a different approach. First are vendors that essentially represent the next generation of storage virtualization. They abstract storage services from the physical hardware and apply those services across multiple vendors' hardware solutions. Some of these vendors have opened their platform to allow other third parties to add services, creating an App Store-like storage resource. This approach prevents you from getting locked in on both physical hardware and software services.

Another category includes vendors that do more than just abstract data services. They also abstract storage controller hardware and often place that processing load into the virtual infrastructure, where it runs on the same host with applications. This can offer benefits such as virtual machine-level performance tuning. In some cases they use storage internal to the hosts and aggregate it into a pool of storage, eliminating the dedicated storage network altogether.

Both of these approaches replace disparate data services with a single data-services type from a single supplier. That means you must depend on that supplier to provide all basic storage software capabilities, which were likely well-vetted in the storage system you had previously. The payoff comes from simplified operations -- there is a single snapshot command allowing you to buy commodity hardware in the future. However, all of these systems are in-band: All storage I/O must flow through them, so they must have plenty of processing power and also high availability.

What if your existing data services are very good, and you're reluctant to replace them with something new and untested? A third category of SDS, which abstracts the management of the storage, but uses the capabilities that are already in place, might make sense. For example, suppose you need to take a snapshot of a volume: You initiate that command from a central console and it is pushed down to the actual storage system for execution. The snapshot is still generated from a single command across storage types, but you use the service of the existing array. In this SDS approach, you gain the operational advantages of abstraction without having to reinvent the data services wheel.

Another advantage of this type of abstraction is that it can be more out of band -- it does not need to be involved in every I/O. This means that it does not add latency to storage communication and requires less processing power to operate. It also means that if the SDS console fails, storage-data delivery can continue.

So which SDS approach is best for you? As always, that depends on your needs. If your storage systems need a data services upgrade and you plan to buy more storage systems soon, then one of the first two types may be for you. If you have silos of name-brand storage, but want to consolidate the operation of those systems, the third type might be more appealing. If you're simply looking to refresh your storage system and replace it all with a single system, SDS may not be a fit for you at all.

George Crump is president and founder of Storage Switzerland, an IT analyst firm focused on storage and virtualization systems. He writes InformationWeek's storage blog and is a regular contributor to SearchStorage, eWeek, and other publications.

Battle lines are forming behind hardware-centric and virtual approaches to software-defined networking. We size up strengths and weaknesses. Also in the SDN Skirmish issue of InformationWeek: Anonymity has a role in business communities. (Free registration required.)