Email delivery: Hate phishing emails? You'll love DMARC

What is EMC's ViPR about? Is it really the first all-singing and all-dancing storage management and virtualisation product EMC claims it is?

ViPR is a combination of a file, block and object storage virtualisation suite and a storage management product. It is broadly similar to several other storage virtualisation products, but distinct from them in its separation of data and control paths and its inclusion of object storage.

The comparable products are:

• DataCore SANsymphony
• HDS VSP
• IBM SAN Volume Controller (SVC)
• Melio SANbolic and other VSAs (Virtual Storage Appliances), like StorMagic's SvSAN
• NetApp V-Series

We can differentiate it from these various kinds of storage virtualisation and management fairly easily.

Unlike NetApp's V-Series and HDS' VSP, which virtualises third-party arrays and presents them as ONTAP FAS arrays or HDS VSP arrays, ViPR will present its virtualised physical arrays as virtual storage arrays with block, file or object access characteristics.

Unlike VSAs, ViPR virtualises actual physical storage arrays instead of virtualising storage attached to servers and turning that into a SAN (Storage Area Network). DataCore virtualisation products are a type of VSA too, focussed on block storage.

EMC says ViPR does its management out of the data path, and in a control plane, unlike an earlier and unsuccessful storage virtualisation product called Invista.

EMC ViPR schematic

ViPR is hard to get hold of, partly because it takes physical file, block and object arrays, abstracts them, and presents them as virtual files^*, block and object arrays. But why bother taking a VMAX block array, abstracting it, and presenting it as a virtual VMAX block array? That merely wastes CPU cycles in a chase-your-own tail exercise.

Heterogeneous device management

If that was what you used ViPR for, then yes, you’d be chasing your own tail, but that would be the wrong use case. ViPR is a way of managing heterogenous legacy and new storage resources and providing common management functions across them, including provisioning, metering and multi-tenancy, so that customers save money by centralising their overall storage management resource and making it more efficient.

Indeed, EMC's head ViPR man, Amitabh Srivastava, president of its advanced systems division, said in a briefing that the main initial benefit for ViPR customers will be storage management savings as ViPR can be the management point for VMAX, VNX, Isilon and Atmos arrays: "A checkbox in ViPR can do the 31 steps needed to provision something" in an underlying physical array.

Srivastava also commented: "It's automated. People make errors; not if, but when. We fix it so these errors are never made."

The beauty of ViPR for EMC is that it is extensible. The underlying storage arrays will be extended to add in Centera and the forthcoming XtremIO flash array. NetApp's ONTAP arrays are going to be supported as will commodity storage - see the diagram above.

SRM example

But here, on the ViPR roadmap, we're entering territory that could be labelled "Here be dragons" and which has skewered heterogeneous storage management products before. Remember AppIQ? It was bought by HP in 2005 and was a storage resource management (SRM) software product that managed different suppliers arrays using the SMI-S standard. It wasn't enough, and multi-vendor SRM products have, by and large, become extinct.

ViPR is going to be a multi-vendor SRM product; but only if EMC, the targeted third party storage array suppliers, or third-parties write the software modules needed to connect ViPR to the storage arrays currently on the market. Moreover, they’ll then need to keep it current as those products get refreshed and their capabilities change and develop.

Ask yourself, why HP would want to write a ViPR interface module for StoreServ? What HP interest would be served in doing that? Pretty much none. Ditto for Dell, IBM, Fujitsu and HDS. El Reg thinks EMC is providing a NetApp interface because one module gets them to all the ONTAP products, and NetApp is EMC's single biggest standalone storage vendor competitor.

Cloud storage economics

ViPR is also intended as a way for cloud storage economics to come to EMC customers, without ripping and replacing the EMC legacy kit installed there. The idea is that commodity storage could be used, with ViPR providing the upper-level storage array functionality seen in VMAX, VNX, Isilon and Atmos arrays; EMC's relatively expensive proprietary gear.

You won't get native VMAX, VNX, Isilon or Atmos performance, but economics are preferred over performance in the envisaged use-cases.

What does commodity storage mean? ViPR has to link to it and issue instructions to it; so we’re looking at a processor and storage enclosure at minimum, and not just a JBOD. That processor has to run software and, unless commodity storage runs a standard operating system, there will have to be specific ViPR connection modules for reach flavour of commodity storage.

You won't, El Reg thinks, be able to provision a ViPR set up with commodity storage components like you populate an empty Drobo with disk drives.

ViPR interface modules

Since it's commodity storage from a supplier then either that supplier or EMC has to write the ViPR interface module. What help will EMC give a commodity storage supplier (for example, someone like Infotrend) to write a ViPR interface module and so provide them with an entry into EMC's customer base and say: "Get your block, file or interface storage off my cheap kit instead of paying through the nose for VNX or Atmos?"

What incentive does EMC have to do that?

EMC could do it if it could ensure the commodity storage was kept in a fenced-off enclosure for specific use cases that didn't affect VMAX, VNX, Isilon and Atmos revenues. That will be challenging.

Like previous multi-vendor SRM products, and previous multi-vendor storage virtualisation products, ViPR could fail to fulfil its potential because of the practical difficulties of keeping ViPR interface modules current with the underlying hardware's software revision level – not to mention developing interfaces for a sufficiently broad set of heterogeneous storage hardware suppliers’ kit.

It could equally fail because it does not enable the entry of expensive proprietary array-eating commodity storage beasts into EMC's customer base, and so ViPR users do not get cloud storage economics.

If Srivastava and his team can negotiate these two fearsome obstacles in the way of ViPR crossing the chasm into commercial popularity then they will have achieved a momentous thing. Good luck to them ®

Bootnote

* Srivastava said: "We will put a file head on top of the control path, alongside Objects and HDFS."

5 ways to reduce advertising network latency