Software-defined Storage from Nexenta: Evan Powell, Nexenta CEO
Recently, people have started to apply the term “software-defined storage” (SDS) to our NexentaStor and to OpenStorage approaches more generally.
That prompted us to look at what we really mean when we use that term.
Already I’m seeing a rush towards the “Software-defined” label. Consider “Software-defined networking.” It appears that $1.26bn gets people’s attention. Thank you VMware (and Nicira, and EMC)!
The promise of a software-defined data center is simple: fix IT once and for all. If you compare the data center to highly controlled and automated processes in manufacturing, IT still lags behind. You’ve got highly paid experts deploying box X and another highly paid expert connecting it to box Y, where another highly paid expert runs application Z and then turns around and complains about the other so-called experts not being expert enough. Those companies that have nailed IT have achieved competitive advantage because the average data center is a mess filled with proprietary, dated technologies that don’t work well together.
The software-defined data center promises flexibility, end to end flow through provisioning and management, and application awareness so that applications can be deployed, on demand, and can access appropriate resources from the data center, also on demand. Again, at the highest level, the goal is to fix IT so that the benefits of the incredible ongoing exponential improvements in hardware flow through to end users thanks to a software and services stack that just works to improve competitive advantage.
But first, before we talk in detail about what SDS is, here are a few approaches that do not pass the sanity check as being SDS:
Storage hardware that is driven by APIs. Don’t get me wrong. It’d be great if storage hardware companies supported up-to-date Rest-APIs. But that is surely not enough to warrant a rebranding as SDS.
Storage software that works with one and only one vendor’s hardware.
Again, it is great to be able to drive storage hardware via software. Actually I’m not sure how else you’d do it. But claiming that your management UI or even your multi-system management capabilities somehow make you SDS is a stretch at best.
Anything sold by a legacy storage hardware vendor. OK, perhaps my bias is showing here. However, a hardware company suddenly claiming they are a software company is a zebra changing its stripes. You cannot suddenly become a software company because you have software developers. You have a value chain entirely predicated on selling expensive hardware with on-disk formats that lock customers into your products. And now you want to back away from that model and pivot to being a software-centric business that offers choice? That’d be a great pivot to make; IBM did something similar and it is astounding that they pulled it off. Customers get this so they tend to want to buy software from software companies.
Something that ONLY works as a virtual storage appliance. It must be possible to provide a consistent storage solution across virtual and physical infrastructures alike. Needless to say, this applies to folks that can run on one, and only one, VSA as well, since that even further reduces the flexibility and ubiquity needed to achieve SDS.
Something that sacrifices fundamental data storage capabilities. If your solution is Windows-based or otherwise not truly enterprise class, you are not yet ready for enterprises. I suppose that is tautological. Still, worth reiterating. Just because the future is software-defined storage does not mean that the features enterprises have demanded in the past on their arrays are no longer needed—most still must remain.
Enough with describing what SDS is not. What is it as we see it?
In short: software-defined storage is an approach to data storage and management that virtualizes the underlying hardware and enables the flexibility and dynamism promised by virtualization to both be fully achieved and to be extended into the management of storage. Software-defined storage is a fundamental component of software-defined data centers. Key attributes include:
Openness: Systems that are inherently closed and proprietary lack the flexibility of open systems. This openness should extend from on-disk formats through APIs and business models.
Ubiquity: Solutions should be widely available, and work with all major protocols. This implies two things. First, it implies some kind of open source or freemium distribution model, so the solution can achieve widespread distribution. Second, it implies you’ve got to be able to serve block, file, and object protocols.
Abstraction: This is all about separation of the data from the data control layers. Amongst other things, this means that JBODs rule. Everything—from RAID through HA and replication and NFS, CIFS, and other protocols―should be delivered as software that can define the attributes on the storage in the server or on the JBOD on the fly, as needed.
Service Level Agreements / Application Awareness: If a product or service is to be considered software-defined storage, it must be possible to inherit SLA requirements from the compute level or from the overall data center business logic. We agree with VMware’s approach here as far as we understand it; and we fully anticipate CloudStack and OpenStack will head in a similar direction, being able to pass along requirements from the application provisioning and management layer through the entire stack, including storage. Self-provisioning storage, based on application requirements, is an example, similar to our own NexentaVSA for View.
Collapsing Compute, Storage, and Networking: For software-defined storage to become reality, the storage protection, replication, cloning, and other capabilities must be able, for certain use cases, to be run co-resident on the compute boxes. In practice, this ironically can mean moving aspects of that logic off the storage capabilities on-box so that storage itself delivers services that then are instantiated, as needed, on the physical device or rack. Our own cloud-wide deduplication capabilities, which we are including in our contributions to the OpenStack Swift community, are good examples of this kind of cloud or data center-wide capability enabled by collapsing just the right part of the storage onto the box (in this case a Swift box) while retaining other aspects logically off the box in a distributed fashion.
At Nexenta, we take the above vision seriously enough that we are looking at every line of code (with more than several million lines to look at) in NexentaStor and NexentaVSA for View, including changing aspects of the underlying ZFS technology, to insure that they are in alignment with our vision of software-defined storage. We are listening to some of our largest current users who need to manage thousands of NexentaStor instances across their cloud in a centralized manner through policies controlled by their cloud management frameworks.
We view NexentaVSA for View, our improvements to Swift, and forthcoming code-named NexentaSwift and NexentaHadoop solutions, as proof that SDS is coming. We have a pure software-only business model. And a relentless focus on data integrity, data protection, flexibility, high performance, and freedom from vendor lock-in in everything we do. We believe that Nexenta and OpenStorage approaches more broadly give the IT industry the best hope for transforming the 42% of IT spending that storage now absorbs into a better solution that reflects the requirements of emerging dynamic, software-defined data centers.
Stay tuned. And please contribute to the debate over what SDS is and what it is NOT. If the storage industry does this right, we can bring openness and a fundamentally more flexible approach to storage to market in the months and years to come, thereby freeing IT from the lock-in and legacy approaches of dominant storage vendors. This is about more than Nexenta or even about storage—this is about fixing IT once and for all. I look forward to hearing your thoughts.