Original URL: http://www.theregister.co.uk/2010/08/23/hp_inserv_eva/
A 3PARised HP lineup
Whither EVA and XP?
Suppose HP succeeds in buying 3PAR and its InServ arrays; what will that mean for the current EVA and XP storage arrays, block access devices that compete with 3PAR's T-Class (XP) and F-Class (EVA):
The EVA is classic modular mid-range array technology which is evolving, it is generally understood, to becoming a set of storage enclosures hooked up to storage processors that run storage personality software: P6000 (EVA); P4000 (LeftHand iSCSI array personality); and X9000 (Ibrix) scale-out file storage personality.
The XP is based on the idea of a scalable and highly-intelligent virtualising array controller, the USP-V, to which is attached back-end drive enclosures. This controller has a proprietary HDS architecture which is generally understood to be being refreshed in the next month or two.
The InServ array also has a proprietary controller, ASIC-based, which is used for lightning-fast internal networking and also for ensuring storage volumes don't contain deleted file space through thin reclamation and similar processes.
The entry-level F-Class is a quad-controller array with the same architecture as the high-end T-Class. In other words its controller functionality doesn't consist of software alone which could, in theory, be ported to an Intel server, like the HP EVA software. That means that transitioning HP EVA users to 3PAR F-Class users would not be simple, not at all.
It's arguable that the F-Class is a more sophisticated and advanced storage architecture and set of functionalities than the EVA. In that case HP would do best to keep faith with its EVA customers by continuing the P6000 development and interposing both the F-Class and InServ T-Class as a higher tier of storage above the Intel-based mid-range.
Naturally it would provide a common management facility and data migration between the P600/P4000 block-access storage personalities and the InServ arrays.
It would also have to solve the problem of what to do about the XP customer base whose systems would be obsoleted and whose customer loyalty would be under attack from HDS. HP could provide a close integration between the XP base and InServ arrays by simply having the XP USP-V controller manage the InServ, which it can readily do.
Then it might develop the InServ controller so it too can manage other arrays, from both HP and third-party suppliers, thus enabling the InServ to manage XP arrays and so craft a neat about-face. Naturally again there would be storage tiering and provisioning and protection across both the XP and InServ environments from a single point.
Such an InServ facility would also be a means of integrating the InServ with HP's other storage products; the P6000, P4000, X9000 and so forth.
The XP-InServ issue is a solvable problem in the words with a reasonably straightforward migration path. The EVA-InServ issue is only solvable, at this first look, by first keeping them in different markets and avoiding product overlap in future, and then by having the InServ manage these mid-range HP arrays.
Of course this is back-of-an-envelope hack-flackery and Donatelli, the magic Ninja turtle of the storage business, may well have other ideas. ®