Congratulations to EMC and their software teams for announcing ViPR. Since we have been selling software defined storage for a number of years – and now have many more times customers than Vmware did when EMC bought them (and more than 10x than 3PAR when they went public for example) – I take exception to the lead in the press release proclaiming ViPR as “the world’s first Software Defined Storage platform…”
Nonetheless, ViPR appears to be a real step forward towards software defined storage. And EMC deserves a lot of credit for again showing a willingness to risk aspects of their core business in order to keep up with customer requirements.
If you are one of the folks to read this blog regularly, you know we have shared a simple definition of SDS. You can read more about it here. Our definition is based on countless discussions with our cloud and enterprise customers who have shared with us why they started down the journey to software defined storage in the first place.
Basically it is 1) Abstract away the underlying hardware. 2) Achieve flexibility through the ability to handle multiple data access methods and data types. 3) Be truly software defined – through an architecture and set of APIs that allows, for example, orchestration software to manage the storage and to determine to what extent it is meeting application requirements.
If you look at what we know about ViPR – I think it is software that is policy driven that delivers object storage and that also manages and possibly virtualizes block and file storage. I gathered this especially from the more detailed write up over onEFYTimes.
It’s difficult to glean much from a press storm and I know that things will be much clearer once we see more detail from EMC and customers but let’s look at early indications of how ViPR might shape up based on those criteria.
- Abstraction
- ViPR: ViPR does not, it appears, add a consistent set of storage management capabilities over any hardware – it exposes and manages those that are already available on the hardware. If you are on an array with snapshots – congratulations, you’ve got (some sort of) snap shots. On the other hand if you are on a JBOD, no luck. Additionally, of course, ViPR does not open up the on disk format as it is generally not in the data path. This means vendor lock–in remains and arguably increases as ViPR hooks into your Vmware environment.
- NexentaStor: Conversely NexentaStor runs on any hardware, including high performance SSDs to deliver caching, and of course JBODs and does deliver that consistent set of capabilities irrespective of the underlying hardware. But – NexentaStor really prefers JBODs to legacy storage arrays and it is extremely likely that ViPR will be better able to manage heterogenous storage arrays, especially those from EMC, than NexentaStor does; NexentaStor can virtualize them but is not aware of their underlying capabilities in a way that ViPR will be.
- Achieve flexibility. The basic difference is that NexentaStor is broader and more flexible that we think ViPR will be when it ships thanks, again, to controlling everything from the on disk format to the access methods. On the other hand, while Nexenta has sponsored open source object approaches we are not shipping today a object storage solution whereas ViPR will include object. Whether we will ship object by the time ViPR ships is yet to be seen.
- A lot depends on to what extent ViPR can actually virtualize the underlying resources by combining them into pools that include SSDs; NexentaStor has this ability today which is why we have partners shipping JBODs with cache achieving 1 million IOPS and more. On the other hand, the promised capability of ViPR to turn object into file and vise–versa could be important.
- I am hopeful that in this area ViPR will be a massive step forward vs. legacy arrays which are essentially black-holes for your data, each requiring a different set of expertise to manage and built to address a different silo of data.
- What needs to be seen is how ViPR will handle putting the right data on the right underlying array. Whereas with NexentaStor the configurations themselves, such as the block sizes used to write the data disk, are themselves variable in the case of ViPR the software has make sure that, for example, video files needed for streaming are stored on underlying Isilon arrays whereas structured data like Oracle remains on VNX and presumably high random I/O workloads from larger cloud and Vmware deployments are served from XtremeIO.
- Being software defined this is arguably the most vague section of our fairly vague definition of software defined storage.Today, however, IF ViPR is routing data sets based on application requirements to the right underlying array – per the point above – than it may well have the architecture necessary to close the application management loop. By comparison, NexentaStor can absolutely eliminate the need for deep storage engineering with solutions like VSA for VDI. In this solution the customer must simply enter the number and type of desktops and NexentaStor – with integration code for VDI – does the rest AND, crucially, tests and manages the system to insure that the requirements are being met.
- Nexenta, however, built the VSA for VDI business logic in part in hopes of seeing others in the industry run with the task. Arguably orchestration solutions like aspects of OpenStack and CloudStack and even VMTurbo should pick up the baton if they are truly going to be the brain inside the software defined data center. It may be that EMC with ViPR and of course Vmware will lead the industry in creating an open approach to characterizing application requirements and using them to simplify management.
- Please note – plaintive request – what the storage layer really needs is something like the recently announced Project Daylight from IBM, Cisco, Juniper and of course the Linux Foundation. I think even Nicra / Vmware / EMC is joining that effort to open up the control layer. Read more about Project Daylight here
- In the meantime, Nexenta’s upcoming Metis utility – which ties application logic to details like pool configurations – is growing in value and importance with integration into our and our partner’s Salesforce for example and ServiceNow and other management solutions in the future. However, again, Nexenta cannot be the business logic of a software defined data center on our own. The industry needs to come together here and maybe ViPR will be a catalyst to make that happen.