HUS VM: Tier 1.5 from HDS

HUS VM: What is in the name?

Ordinarily I wouldn’t spend much time on the name of a product, especially an HDS product where the incumbent Master Namer seems adamant on starting every product name with the word Hitachi.  But a name can often tell you can tell you a lot about something..

So, while the HDS sales crew might be spouting this as entry level enterprise, the detail hidden within the name suggests something more midrange –

1. HUS VM = Hitachi Unified Storage Virtual Midrange. 

2. The internal factory name at Hitachi Japan is HM700, with the HM standing for High-end Midrange, or High Midrange.

So while the marketing and sales guys might want to use the term “enterprise” or “entry level enterprise” to describe this kit, the engineers seem to want to refer to it as midrange.

My personal opinion is that it’s about as tier 1.5 as you can get.  Taking up residence right in the neighbourhood of the likes of 3PAR, XIV and high end VNX.  And for HDS that’s a good place to be, as this is a juicy market segment that HDS don’t have decent play for.

Internally at HDS the product was developed under code name “Wister Lake”.

But HDS Suck at Tier 1.5

HDS’s previous forays in to this space (the gap between their modular AMS/HUS and the enterprise USP/VSP) have been dire.  Technologies like NSC 55 and USP VM have been real text book examples of square pegs and round holes.  And only the most gullible or die hard HDS shops would have had the misfortune of purchasing these technologies.  But this time it could well be different, as this is most definitely not an artificially cropped VSP with arbitrary and artificial limits slapped on to it.  This genuinely is something specifically designed for that tier 1.5 market.  Almost like a 3PAR.

HUS VM: Hardware

From a hardware perspective, HUS VM is a brand spanking new hardware platform designed specifically for the tier 1.5 market.

It should be no surprise that there is a custom ASIC at the heart of the system.  After all, Hitachi is an engineering led organisation with a deep history in ASIC design. 


Should customers care that there is an ASIC inside though?

In answer to the question above, the technologist inside of me wants to answer “Yes”.  I like well designed technology and think that 3PARs implementation of thin technologies inside their ASIC has worked wonders for them.  All marketing and corporate BS aside , the 3PAR implementation of thin provisioning and space efficiency technologies is second to none in the market.  This I am certain is due in no small portion to its implementation of thin technologies within its ASIC. 

I also personally believe, and feel it is borne out in experience, that at the very high end, ASICS and custom silicon still has a place.  Even the most die hard advocates of “commodity everything” still slap custom silicon all over their products (whether it be for inline encryption or whatever else) albeit they might not always design the custom silicon in-house.

However, even the technologist within me wonders whether this requirement for custom silicon holds water in the more midrange segment, where high and predictable performance are not mandatory. 

Now while HUS VM has an ASIC at it’s heart, Hitachi have been stripping functionality out of the ASIC where possible.

The diagram above also points out that this could be viewed as a dual controller architecture, one that is very different from that of its Tier 1.5 neighbours 3PAR and XIV, which sport a more grid like approach.  However, the above architecture (HDS call the controllers “clusters”) it should be pointed out that this is the same as it is in VSP, where the controllers are tightly coupled via PCIe.  And as with VSP, all paths to a LUN are active, none of this ALUA smoke and mirrors.

Scalability doesn’t look overly great to me though.  Two controllers that look like it would be complicated to enable a scale-out approach of adding more controllers.

As the pictures below show, it bears the ugly HDS trademark bezels that make it look like it’s from the 1980’s, but the important thing is that it is radically different in its design to VSP – much better suited for tier 1.5 –

HUS VM logic boxes

HUS VM Cache and Main boardsHUS VM front photoRear HUS VM photo

From a hardware perspective below are some details that may be of interest –

Cache 256GB
Max Number of Drives 1,152
Max Front end ports 32 (48 if you have no internal drives)
Front end ports 8Gbps FC
Backend 32 x Native 6Gbps SAS
Drive form factor 2.5-inch SFF or 3.5-inch LFF
CPUs 2 x 8 core Intel Xeon (partitioned as 4 x 4 core for firmware compatibility with VSP F/W)


I’ve purposely not included any IOPS or MB/sec figures as I tend not to give much weight to them.  Suffice to say its sits snuggly between the low and high end offerings already available from HDS.

HUS VM frames

HDS are marketing this with a capacity sweet spot of between 20-180TB, although it can scale larger.  This is a good fit too as a VSP tends not to be very compelling from a price perspective until you start getting comfortably north of 100TB, probably north of 150TB.

While on the topic of hardware I should point out that there is a pair of clustered BlueArc/HNAS file servers inside (nestled in between the block storage controllers below and the disk drives above).  The file servers have 32GB cache, 6 x 1GigE and 4 x 10GigE, with 4 x 4Gbps FC for connecting to the block controllers.  May be a bit more on the file side of things later…..

HUS VM: Software

From a software and firmware perspective this baby runs the high end code found in the USP and VSP platforms, DKCMain.

There’s no fancy name for the firmware at HDS, nothing so fancy as "Enginuity”, “ONTAP”, or even “SiliconFS”.

Now this is a two edged sword.  With one edge of the sword you get all of the features (Dynamic Provisioning/Thin Provisioning, Dynamic Tiering, heterogeneous virtualisation, replication…) reliability and street cred of the USP/VSP code, but you also get all of the legacy.  Things like old fashioned parity groups etc.  While I’m not a fan of the legacy in the likes of DKCMain and Enginuity, I have to think that this is a good move from Hitachi.  This gives instant credibility when entering the tier 1.5 market and HDS are backing HUS VM with the same 100% data availability guarantee that has come with the USP V and VSP (if it doesnt meet this you get credits to use with HDS Confused smile).

With it running the same DKCMain code as the VSP, this means that implementation details such as the infamous 42MB page size for thin provisioning and space reclamation is exactly the same between VSP and HUS VM.  Also the same braod range of 3rd party arrays can be virtualised behind it….. 

Going with the VSP firmware also creates a nice option for existing HDS customers who might have USP/VSP technology in their main data centres but would like to put something a little smaller and cheaper in their smaller/remote data centres, but something with the ability to replicate back to the main data centres.  TrueCopy replication technologies including HUR work between USP/VSP <—> HUS VM…..

I should point out that at the time of release, some of the more high end configurations, such as 3DC configurations, are not available for HUS VM.  And that the cut of DKCMain firmware available for HUS VM is based on a code freeze from earlier in the year so may lack some of the most recent tweaks available for the VSP.  But I expect this will catch up over time.

HUS VM may also be a good fit if you already have scripted DR for USP/VSP as this will work seamlessly with HUS VM.

While on the topic of software, the HUS VM will be managed by the pretty, but ultimately frustrating, Hitachi Command Suite software.  So, a single management interface to manage all Hitachi storage products (well almost, as there is still the occasional requirement to break out in to some of the old interfaces that look and feel like 1980’s websites).  Moving in the right direction though…

Unified? Hmmm Kind of.

As previously mentioned there is a pair of clustered BlueArc file servers included in HUS VM.

Under the hood the block and file components are bolted together somewhat like CLARiiON and Celera in VNX – block controllers owning all of the disks with file heads that talk to the block controllers over internal FC connections.  The way that the block and file code components are implemented is also very similar to VNX, with the block (DKCMain), and file (BlueArc SiliconFS) packaged and running entirely separately a’ la Flare and Dart on VNX.

I suppose this works for a first cut, but its my opinion that it is somewhat frankenstorage (the same goes or VNX).  However, this is only my opinion, and I am open to the potential that for high end configurations this may be the best way to implement unified storage.  VNXe does things slightly differently in the low end of the EMC portfolio and Data ONTAP certainly does it in a more unified way in the low and midrange (and NetApp would argue also in the high end).  To me it’s ugly, and ugly might be functional but it doesn;t mean I have to like it.

I’ll say this, it’s a sight more unified than anything HP have Winking smile

But in HP’s defence, is unified something that fits well in the tier 1.5 space?  I do wonder how the price point will work out for file services in an HUS VM!

One final point on File, there is no scale-out like Isilon/OneFS.  But then again there isn’t from EMC in a unified packaging either.  The strongest play in the unified with scale-out file space is NetApp.


On the topic of the ASIC.  I know most people don’t think customers should care about such detail.  Well may be that is the case at the low end, but I personally think that it matters in tier 1.5 and above.  The discerning storage customer should care, because at the end of the day it does makes a difference and more fool you if you believe it doesn’t.

Still on hardware, Hitachi now has 3 platforms to develop and maintain.  How much of a strain will that be?

One thing that is certainly missing in my opinion is some form of flash cache.  We already see this in VNX and in the guise of PAM in NetApp systems.  Using flash as a cache extension like this, while it can have its drawbacks and subtleties, is often a very useful technology. 

While it’s not earth shattering and is merely plugging a gap that HDS have had in their portfolio for too long, it is about time that HDS had a decent play in tier 1.5 and this genuinely looks like it might be about as close as you can get to tier 1 without paying the tier 1 price premium (assuming they don’t charge too close to VSP type prices).

7 comments for “HUS VM: Tier 1.5 from HDS

  1. Bob log
    September 26, 2012 at 3:49 pm

    Is there any play for object storage in this offering?
    HCP unified in to the box would make for a more clean implementation once you get over the few tens of TB IMHO. A large scale HCP is almost storage by cabling. A step up platform that also does the NAS gateway would be something.
    Lets hope the sales people don't kill this product by expecting VSP prices for less product.

  2. V
    September 26, 2012 at 7:13 pm

    any sign of HDT, Nigel ?

  3. September 26, 2012 at 9:59 pm

    V – Yes HDT is supported. The cut of the DKCMain microcode running the block side of things is from the June VSP release, so fundamental features like HDT are in there.

    Bob – No native HCP configuration but I hear what you’re saying.

    And as for the pricing, I certainly hope it comes in at a compelling price point because I think HDS are fighting an uphill battle here as this is not their traditional stomping ground.

  4. Erlon
    November 28, 2013 at 7:17 pm

    Hi, do you have a higher resolution of the HUS-VM rear?? 

  5. Alexander
    May 9, 2014 at 6:37 pm

    Dear Nigel.
    Can you please elaborate on this statement "Technologies like NSC 55 and USP VM have been real text book examples of square pegs and round holes.  And only the most gullible or die hard HDS shops would have had the misfortune of purchasing these technologies."
    This is from you post about HUSVM
    I do not dispute your statement regarding NSC55 (I simply do not know whether you are right or wrong) but my impression of USPVM is entirely different than what you express.
    Also, could you provide sources that supports your claims.

    I hope to hear from you.
    Best Alexander.

  6. May 9, 2014 at 6:56 pm

    Hi Alexander from HDS UK.

    Thanks for your comment. Honestly, my statement was more about NSC than it was USP VM. Though I do still stand by the statement. And I think it’s backed up by the fact that from people I know, it wasn’t that well accepted in the market. And did HP even re-brand it??? Hmm may be they did in the XP10K. Either way neither really took off.

    All of the complexity of enterprise, packaged for the SME. Seriously I think square peg in round hole is a perfect analogy. Trying to hammer that USP SW and butchered-HW into a 19-inch rack and trying to price it accordingly. Didn’t work IMO, as evidenced by it’s lack or market uptake and the obvious fact that Hitachi Ltd were working on HUS VM (at the very least on the drawing board). So that’s my thoughts around square peg and round hole.

    Then…. Of the NSC 55 and USP VM sales, how many were to existing HDS customers, and how many to net-new customers? I obviously I don’t know, but I highly doubt that many new customers were won based on either platform. Agree I don’t have the facts, but I get around and speak with enough people to get a feel for things. These are old tech’s now and I’ve destaged those memories from my on-premise brain off to AWS Glacier…. ;-) But my overriding memories of them is that they were square pegs in round holes and not well accepted in the market.


Leave a Reply

Your email address will not be published. Required fields are marked *


You can add images to your comment by clicking here.