Original URL: https://www.theregister.com/2009/02/09/emc_should_rev_invista/

Why EMC should really rev InVista

Put up, or put down?

By Chris Mellor

Posted in Channel, 9th February 2009 10:31 GMT

Comment InVista is a stunning flop that EMC is refusing to shut down. Why? Is EMC in a state of denial, or does it have a plan?

EMC announced InVista as a storage array management and virtualization platform, a storage router based in a SAN fabric, in May 2005. It ran as an out-of-band appliance connected to a fabric switch and became one of three possibilities for customers to manage virtualized multi-platform storage arrays in a SAN environment, from within or at the edge of the SAN fabric.

The other two were IBM's in-fabric SVC (SAN Volume Controller) and Hitachi Data System's fabric-edge USP. Latterly NetApp has joined this fray, with the V series virtualising NetApp head that layers ONTAP-ness over third-party arrays attached to it.

SVC unit sales are up past 15,000, the USP is in the 10,000 plus area, and best guess there are several thousand V series boxes out in the field. InVista? Think very low hundreds and pilot sites. That's crazy.

Put aside arguments about whether such storage controllers should be in-band or out of the data path and think about virtualized servers. A data centre with most or all of its servers virtualized will need to provision storage for applications instanced as virtual machines. So an ESX (or Hyper-V in future) sysadmin will want to point-and-click at a screenful of options to do this, or use a pre-configured storage template.

That sysadmins will need to specify the type of storage services needed, these kind of things:

That's nine items here. Sysadmins will not want to have to do this for every storage array product type. Inside an IBM environment the users will not want nine different interfaces to the separate DS4000, DS6000, DS8000, XIV and SOFS boxes.

In HP-land they won't want nine different interfaces to individual HP storage products like MSA, EVA, XP and ExDS. NetApp customers won't relish separate and different interface sets for FAS, nearline, V series and VTL boxes. Eager EMC customers will really not want different interface sets to each of the Symmetrix, Clariion, Celerra and Centera and Atmos products they have.

Some things it makes sense to do at the individual array level; others, the stuff that's common at an intent level across arrays, is best done at a functional layer above individual arrays and before the virtualised servers. This isn't hard to understand; it's just common sense.

For storage suppliers with either a unified storage environment - step forward NetApp and present ONTAP - or a unified storage controller product - step forward HDS (USP) and IBM (SVC) and NetApp again (V series) - then boy, do you have a ready-made single storage product set interface to a virtualised server environment. Think ESX/Hyper-V sysadms causing storage provisioning and management requests to your storage controller which you fan out and translate to the individual storage products behind that controller and/or within your unified environment. The storage products are just on tap, as it were.

Oh, and the ESX/Hyper-V environment interface with the storage controller needs to be dynamic so that storage resources and service levels can be readjusted in real time as circumstances change.

Now, in my arrogant humble opinion, customers with virtualized server environments in enterprise data centres will not care a jot where the unified storage environment functionality is, as long as they get it presented to them.

So is EMC, having driven customers into adopting virtualized server data centres, and seen them loving it every step of the way, going to hand the fulfilment of said customers' needs for a unified storage provisioning and management interface to its competitors? Will it let HDS, IBM and NetApp walk away with these particular spoils and have its own storage arrays virtualized behind their controllers?

Surely not. EMC is much more likely to give a major kick in the pants to InVista and turn it into a dynamic ESX-facing virtualized storage resource provisioning and management interface layer that will work with Hyper-V too. It might even be shipped as a VM itself.

Dell, HP and Sun ought to get their arses in gear, too (although not so much HP - at least it's got its LSI SVSP software for mid-range arrays). ®