You get to be the judge.
If you have been anywhere close to the storage industry for the last several months you’ve noticed that software-defined storage (SDS) is all the rage. One of the difficulties has been pinning down exactly what SDS means. In my post “How do you define Software-defined Storage,” I pointed to a definitive piece of work by IDC laying out a complete taxonomy for SDS (they call it Software-based Storage). In the report, IDC describes three key attributes that IT managers can look for in identifying software-based storage solutions.
- A software-based storage solution is software. It is designed to run on commodity hardware and leverage commodity persistent data resources. This is in contrast to most traditional storage systems that, while they may have software microcode at their core, depend on some custom application-specific integrated circuit (ASIC), a specialized processor or a controller to perform some or all of their storage functions.
- A software-based storage solution offers a full suite of storage services.
- A software-based storage solution federates physical storage capacity from multiple locations like internal disks, flash systems, other external storage systems and soon from the cloud and cloud object platforms.
Next week at IBM Edge, I expect to hear a lot of conversation on SDS and, in particular, the IBM Storwize family software platform. Although the SDS craze is a relatively recent phenomenon, IBM has been investing in and tuning the Storwize family software platform for more than a decade. IBM clients first began federating physical storage in 2003, and today the total capacity under Storwize software management is on its way to an exabyte.
From its beginnings in 2003, the Storwize family software platform was designed to be portable, leveraging commodity hardware engines for its compute needs. In fact, the internal code name for the Almaden Research Center project was Compass (Commodity Parts Storage System). The technical motivation behind the decision was cost. IBM recognized that broad market dynamics would push the price and performance curve for Intel-based processors much more quickly than any custom-designed ASIC or specialized processor could keep up. In the early days, the decision was ridiculed by IBM competitors, most of whom were building high margin disk systems on custom hardware. Today, there are still some vendors who argue against the idea of SDS on commodity hardware. See the recent post by Hu Yoshida “Software Defined Storage is not about commodity storage.”
The first commodity hardware engines to house the Storwize family software platform were the IBM 2145 SAN Volume Controller engine and the Cisco MDS 9000 Caching Service Module. The Cisco engine was short-lived, but the IBM SAN Volume Controller engine is now in its seventh generation and processes about 800% more input/output operations per second (IOPS) than the original engine, proving exactly what IBM had hoped when it chose to ride the commodity price and performance curve. This current generation engine holds the Storage Performance Council SPC-1 benchmark record for the fastest external storage system at over 520,000 IOPS. Along the way, other commodity-based engines in a variety of configurations have joined the family. There are federating systems with no storage capacity of their own, systems with internal solid-state drives to speed the input/output (I/O) of other federated storage, and systems that carry their own serial attached SCSI (SAS) disk and flash capacity to augment other federated capacity. There are entry models, midrange models, enterprise models and even models that are embedded in the IBM PureSystems family converged infrastructure.
The beauty in the Storwize family software platform is not only that it runs on commodity engines and federates capacity from a wide variety of internal disks, flash systems and other external storage systems, but also that it accomplishes this using a single software code base across the entire range.
As IDC noted, one of the foundational requirements of an SDS platform is that it provide a complete set of storage services. If not, IT managers would be forced to weigh the tradeoff between commodity cost efficiency and missing storage services that are traditionally offered by high-margin disk arrays on custom hardware. Ten years into its development, the IBM Storwize family software platform solves the dilemma in grand manner. Check out the following features:
Deep in traditional array capabilities:
- Synchronous mirroring
- Asynchronous mirroring
Efficient by design:
- Real-time compression giving up to 5x more usable capacity on all federated storage without impacting application performance
- Thin provisioning
- Streamlined human interface that Edison Group testing has shown saves of over 47 percent in administrator time and is 31 percent less complex versus performing the same set of tasks on physical storage
- EasyTier automated tiering places the hottest data on the highest performing storage for up to 3x improvement in I/O performance with as little as 5 percent of your total infrastructure on flash.
- Active-active data center configurations federating storage capacity from two physical locations into a single instance of a virtual storage volume; used in conjunction with active-active virtual server capabilities like VMware vMotion over distance or IBM PowerVM Live Partition Mobility, can enables transparent site switching.
- OpenStack Cinder driver can automatically deploy federated storage capacity with new cloud workloads
- Integration with IBM PureSystems family for rapid deployment and management simplicity in converged cloud infrastructure
What do you think? Is IDC’s taxonomy a good measure of what the software-defined storage craze is all about? Does the IBM Storwize family software platform hit the mark as software-defined storage?