EMC ViPR virtues & vexations, but no virtualization

EMC ViPR went GA (general availability) last week. You may recall that EMC announced ViPR at EMCWorld2013 (see my blog post on the EMCWorld2013 day 1). At that time details were a bit sketchy but more information was provided earlier last week as a preview to going GA.

ViPR is first and foremost a framework for managing heterogenous storage systems. With ViPR in place you can do all your storage provisioning, monitoring and management through ViPR operating panels and policy automation.

At GA ViPR supports EMC VMAX, VNX, VPLEX, Isilon, RecoverPoint and NetApp storage systems. Over time EMC will add more storage systems and commodity storage solutions as they are requested by their customer base.

ViPR Virtues

Essentially ViPR has split open the control and data planes of enterprise storage. The first iteration works mostly at the control plane level but the framework of control and data plane isolation should work just as well here as it does for software defined networking.  ViPR is releasing just one data plane service at GA, that being an object storage interface to storage under management.

I am always surprised by how far storage management has advanced over the past decade or so. The last time I defined volumes was using an op-panel on a storage system with soft keys. Today everything can be done via GUIs or CLI scripts. But most customers say it’s still not enough. I was on a podcast just last week with Howard Marks, DeepStorage Founder and Chief Scientist, and  Dheeraj Pandey, CEO of Nutanix. Dheeraj mentioned that “the enemy of IT is time.” By that he meant that the time to deploy services is always too long and needs to shrink considerably.

Well with ViPR the hope is that you no longer have to understand five or more different operational environments. Rather you can get by with just an understanding of ViPR storage management, leaving the complexities of dealing with individual underlying storage operations consoles to ViPR from now on.

ViPR can handle the reporting, configuring/provisioning, snapshotting (I believe), setting up/tearing down replication activities and most of the other mundane tasks of managing storage solutions today. In doing this it reduces of the requirements for special purpose storage admins (NetApp, VMAX, VNX) and transitions them to being ViPR admins, which makes them more universally applicable. I suppose you may still need to configure new storage systems with a minimal interface and a single LUN/file system the old fashion way and then ViPR can take over from there.

When ViPR supports commodity storage the intent is that ViPR control and data plane services will support snapshot and replication services using commodity storage alone.

Replication services and BC/DR capabilities are being supplied through RecoverPoint and VPLEX for the moment for the underlying storage but eventually ViPR should be able to handle the native storage system services for these facilities as well.

ViPR is written in Java and EMC expects to release additional functionality in a more incremental fashion than they have for past products.

As for the data plane, ViPR starts out with support for object storage interface which can be used with VMAX, VNX, NetApp storage solutions. The object storage data service is just the first of many planned data services, with HDFS scheduled to come out before the end of the year. And a file service planned after that.

ViPR ships as a VMware vAPP. It’s a 100% software solution and EMC will provide a test (non-production) version free of charge to anybody and Academic organizations can have ViPR for production use for free as well.

EMC is also planning to publish all of ViPR’s API information and will foster an Open Platform approach to extending ViPR functionality. They don’t intend to be the only developers on this platform.

They also plan to offer a ViPR Online Service offering for ViPR developers that has all the storage that is currently supported behind a ViPR cluster that can be accessed to test ViPR enhancements in real time with real hardware.

The base ViPR control plane is licensed on a GB/month basis with price breaks for more capacity under management.  Pricing for the base Controller Platform will start at $0.01/GB/Month and will go down to $0.005/GB/Month at the highest capacity levels.  If you want the Object Data Service as well as the Controller Platform the pricing starts at $0.02/GB/Month and goes down to $0.01/GB/Month.  To get a true picture of TCO one needs to add the cost of the underlying storage to ViPR’s price.

ViPR Vexations

Java is very flexible and easier to develop functionality in,  but using it for data services seems a bit of a stretch. While object and perhaps HDFS may not have problems with reduced response latencies, it’s unclear what other data services can support similar responsiveness. Yes flash everywhere can help and maybe that becomes the solution if you want better responsiveness but ViPR data services today don’t seem to support server side flash.

CDMI and SMI-S are not being mentioned anywhere here. These industry standard approaches to managing storage or cloud data should be a critical early deliverable. EMC says their customers aren’t asking for them which is why there not being planned for.  But ViPR represents yet another set of APIs, developers will need to code to support storage  management. I suppose the upside is that EMC will take the lower half of this API on for themselves to support enterprise class storage systems.

Is EMC the right company to create and support ViPR in the future?

As ViPR moves beyond VMware into OpenStack, Hyper-V and other virtualization solutions, VMware becomes a less likely company to host this effort and EMC is probably the only place in the EMC family of companies, where it continues to make sense. Nonetheless,  it seems EMC would not be the best place to host an open storage management framework. For example, the lack of Dell, HDS, HP and IBM storage support under ViPR probably has more to do with EMC’s current install base rather than storage strict popularity in hypervisor installations.

ViPR seems to take a somewhat constrained approach to defining software defined storage. I think splitting the control and data plane for storage makes a great deal of sense but until you get into the data path, some of what you want to do is much harder than it needs to be.

EMC mentioned data gravity as being the thing that differentiates storage from networking and server virtualization solutions. By gravity I assume they mean the difficulty in moving TB of data around a data center. It looks like EMC is going to try to support data migrations like this using a sort of control and data plane hybrid solution but it’s hard for me to see how this could be provided non-disruptively without being more intimately involved in the data path/data plane.

ViPR is not storage virtualization

When I think of software defined storage I think of more automation, more heterogeneous management and extreme storage virtualization. ViPR has the first two but expressly ignores the third. I suppose if you want storage virtualization you can use NetApp, VMAX or even VPLEX to do it underneath the covers of ViPR but it seems to me that an essential data service would be (virtualized) block storage and for that matter virtualized file services..

Yes, it’s harder to do, and yes it’s ultimately a potential performance bottleneck and functionality choke point but what we all want is storage virtualization and better management automation. ViPR really doesn’t deliver on that half of this.


ViPR is an interesting approach. EMC seems to be of the opinion that better management is the thing that most customers want and they may be right. Better, more universal storage management can help storage admins to be more productive, reducing their time and effort. With better management comes more automation in my mind and ViPR has the promise of more automation by publishing their APIs and providing a more standardized CLI support for more storage. This will help too.

The lack of storage virtualization is another matter. I suppose when you get down to it, storage virtualization provides better centralized management and non-disruptive migration of data. ViPR already provides the better management piece of the puzzle. If they can also supply highly optimized, non-disruptive data migration, without encountering all the problems of storage virtualization maybe this is the way to go.

Stay tuned as EMC ViPR rolls out more functionality.

Photo Credit(s): Dodge viper seen from the front by Martina Rathgens

9 thoughts on “EMC ViPR virtues & vexations, but no virtualization

  1. Ray – did you ignore Isilon on purpose? Isilon is supported by ViPR as well. Just curious. This presents interesting opportunities to leverage scale-out in a ViPR environment.

  2. Nice summary Ray, thanks for posting. As I think about ViPR I have to come to the conclusion that it's a nice attempt but falls short in a key area – a universal control plane cannot fix product deficiencies. If a storage array doesn't support dedupe, thin provisioning, or [pick your favorite feature], ViPR can't add it. Instead of plugging NetApp into ViPR and de-tuning it, it might be a better idea to plug EMC into a NetApp V-Series gateway and rev it up. You'd get both data management and storage virtualization without the monthly fee. Disclosure: I am a NetApp employee.


    1. Larry,

      Thanks for the comment. I would have to say that ViPR has a ways to go to prove it's overall value that's just not there today. From my perspective, how well they play in the data plane will determine how useful it is in the long run. But they have gone out of their way to leave it alone as much as they can.


Comments are closed.