HP: Flash is better in than out. Better for us, er, our customers
All-solid-state arrays stuffed in StoreServ, no need to buy a rival silo
HP is going to implement its all-flash arrays inside the StoreServ (3PAR) architecture and operating environment. This sets it at odds with every other all-flash array supplier and other believers of external flash silos.
Of course there's also the added benefit that this tactic may prevent HP's StoreServ customers from buying in competing all-flash arrays to speed up their applications.
An all-flash array (AFA) is a storage array using flash modules that are not treated as quasi-hard disk drives, as is the case with a hybrid disk drive array (which has SSDs in HDD-format slots and a disk-drive focused operating system). The AFA has a flash-focused operating system that takes care of reads and writes to the flash modules, flash data integrity, wear-levelling, power management and so forth.
Above the flash layer it has the standard array host I/O functions - optimised for flash speed, of course, and which do not assume disk latencies. Typically, an AFA will use deduplication and compression to ensure maximal use of the flash capacity. AFA startups including GreenBytes, Kaminario, Nimbus Data, Pure Storage, Skyera, SolidFire, Violin Memory, Whiptail and others have each built or are building products like this, saying a ground-up designed operating system is essential to get the best out of an AFA.
Back-end array integration can wait
What about integrating the AFA with whatever disk drive arrays customers might have? Well, the AFA is seen as a sever supercharger: you buy it because your apps, such as VDI, are running too slowly and they need a mega kick up the ass. Which is what flash does, delivering a Nitro-like jolt to server-array I/O.
Back-end array integration has to wait, and each AFA producer will have to write their own software to do this, to move data back and forth between whatever back-end arrays they support and their own AFA. It's part of the reason Violin has made a data management software deal with Symantec; no AFA is an island, excerpt most of them are, but they shouldn't be. No customer with an eye towards support costs, etc wants to buy another storage silo...
The chart above shows this approach.
Two mainstream storage suppliers are going this route as well, choosing to buy in an AFA rather than build their own. IBM has bought RamSan vendor TMS. EMC has bought AFA startup XtremIO. Fujitsu is reselling Violin Memory arrays.
We do not know what Dell is doing in this area. We do know that NetApp has a MARS project to develop a all-flash array and that developing product does not appear to run under NetApp's DataONTAP operating system. Which leaves HP...
HP: Beware of rivals bearing flash boxes
Our understanding after taking to HP execs is that HP has decided to build an AFA inside the StoreServ (3PAR) architecture and InServ operating environment - on the basis that there are several basic flash management features already built into the 3PAR ASIC used in StoreServ arrays and also the InServ operating system in those arrays. These features are:
- Small size of logical pages in a flash memory
- ASIC's hardware controller has built-in thin-provisioning
- 3-tier virtualisation of chunklets, logical disks and then volumes or LUNs
- Controller node and mesh architecture
- StoreOnce Catalyst deduplication
HP has described its StoreServ approach as "polymorphic" - in that it is able to handle data in file, block or object form and scale out and up. Here we see an AFA box being integrated into the approach, as this chart shows.
We can envisage that pretty much whatever two StoreServ arrays can do in terms of talking to each other and exchanging data, an AFA StoreServe could do too - ie, federation with Peer Motion data mobility (software that provides storage mobility and federation across devices), replication, and Adaptive Optimisation (HP/3PAR's automated tiering feature).
We might envisage three use scenarios for this StoreServ Flash box:
- As a fast flash array inserted in the data path between a bunch of accessing servers and back-end StoreServ arrays
- As a separate module inside an existing StoreServ array
- As a server-located flash array connecting the servers on a PCIe-class link at very high-speed
HP says that the federation (PDF feature will allow customers to "non-disruptively shift data between any model HP 3PAR StoreServ system without additional management layers" or appliances.
Disaster recovery and failover might be a bit of a stretch though.
Built-in buy-in tie-in
HP's customers are being told that, yes, they can have AFA speed and functionality but within their existing StoreServ environment - likely a persuasive argument for customers to consider if they were thinking of buying AFAs to speed up sluggish apps. It would be essentially the same performance as a startup or competitor's AFA box but without that silo'd architecture grief that will come with it. Instead it will all be integrated within the StoreServ environment.
As an aside, this is a very NetApp-like approach and, no doubt, NetApp users would love the MARS project to be an ONTAP-integrated product.
HP execs said that the StoreServ flash array would be designed so that it could use NAND flash storage or some form of post-NAND non-volatile storage such as HP's own Memristor technology, Phase Change Memory or something else. It's open about this.
So HP will not only deliver a NAND all-flash array, but provide the architecture and environment that will support the transition to a post-NAND non-volatile array as well. It's a seductive message and could close out lots of competitor AFA incursions into HP's storage customer base. ®