2.010: pity the fool

V-Max sure has gotten under the skin of the HDS and their bloggers.

Not only has the pitiful HDS marketing machine rushed out yet another overhyped and underwhelming (green eggs and HAM) announcement, but every HDS blogger seems determined to take as many uninformed pot-shots of FUD at a product they clearly have not even yet begun to comprehend.

And it’s not just the bloggers who clearly don’t get it: a customer recently told me about some Hitachi marketing materials he has seen that attacked V-Max based entirely upon a Hitachi “suspicion” about the architectural utility of the Virtual Matrix. Seems based on that (mistaken) “suspicion” Hitachi’s conclusion is that V-Max simply cannot work. PERIOD.

When you don’t understand how something works, I guess all you CAN do is make sh*t up!

The latest blatantly uninformed attempt to discredit V-Max comes from HDS’ Christophe Bertrand as he delves deep into the FUD-bucket. In his latest post he tries to cast aspersions against V-Max while trying to deflect several of my very, shall-we-say, PESKY observations about the limitations of TSM – especially when it comes to relocating volumes that are being replicated.

Historically, Chris tends to mislead through incompletely reasoned logic and abject blind bias (I’ve suggested to him on more than one occasion that he is insulting the intelligence of his audience, but he still persists with his blissfully ignorant attacks). And he doesn’t fail to follow form with his latest…

In fact, it’s almost as if Christophe is Mr. T reincarnated (remember THOSE silly adverts?)!
 

quit yo’ jibba jabba

For those of you who can’t decipher what Chris is REALLY saying, here's the translation into the King’s English:

1. As Chris confirms, TSM cannot currently relocate LUNs while they are being replicated. Customers are indeed out of compliance during any LUN migration (not so with V-Max’s Virtual LUN migration).
2. And did we all know before Chris explained it that it isn’t even possible to relocate a LUN that is being Synchronously replicated until the latest USP-V Beta?
3. And lets not forget, TSM limits you to QUEUING a maximum of 64 LUN migrations, but only executes them in groups of 8 at a time, with a 15-minute pause in between groups. If' you’re needing to relocate a large # of volumes (like say, during a tech refresh), you are in for a long wait. And a massive impact on performance for the duration of the move to boot. 
   
   On the other hand, EMC’s Open Replicator/Live Migration and Virtual LUN both can migrate hundreds or even thousands of LUNs concurrently, without disrupting replication and WITHOUT impact on response times of running applications!
4. And yes indeed folks, here we are a year later, and Hitachi is only just now shipping the exact same Flash Drives as EMC, with the exact same MTBF ratings as the drives EMC began shipping a year ago. Chris makes it sound like the MTBF suddenly got better, which is anything but true.
   
   And indeed EMC took the leadership position in driving down costs AND ensuring enterprise-class reliability of EFDs. But lacking EMC’s experience and understanding of the technology, Hitachi configures these EFDs with less usable capacity than EMC, resulting in a higher $/GB than EMC.
5. Despite all the assertions to the contrary, Hitachi has nothing like either LUN-level or sub-LUN Fully Automated Storage Tiering (FAST) in their portfolio nor on their roadmap – and Chris confirms by not responding to my challenge to demonstrate otherwise. EMC is charting a course to a new way of deploying storage that will capitalize on the lowest $/GB as offered by SATA drives combined with the lowest $/IOPS as enabled by solid-state Enterprise Flash.
   
   Meanwhile Hitachi is caught flat-footed and indeed has no response – nothing, nada, zip and zilch. Nothing but crickets…
6. In marketing-land, there is an eternity of difference between "capable of" and "actually doing". A massive subset of - dare I say MAJORITY - of Hitachi/ HP/ Sun installed base wisely chooses NOT to use Hitachi’s external storage virtualization CAPABILITY, and thereby they avoid suffering the performance impact, risks of data loss and vendor Trojan Horse lock-in that is inherently introduced by adding another layer to their storage infrastructure. And with V-Max today supporting over TWO PETABYTES of usable capacity, many are now asking themselves whether all the UVM hype is really necessary (much less realistic).
7. As IDC and Gartner both note this quarter, a mere 12,500 USP-V+USP-VMs in over 4 years is barely enough to beat out the DS8000 for 2nd place in enterprise storage market share, leaving Symmetrix in sole command of #1 for what – the 16th consecutive year?
8. As the smart people over at Wikibon point out, utilizing storage that is over 4 years old is not only increasing the risk of data loss (NEWS FLASH: disk drives DO wear out, which is why maintenance contract prices increase as the drives get older), Running old storage also has a disgracefully negative impact on energy efficiency. New storage is more reliable, more efficient, and has less impact on our environment.
9. Upon closer inspection (and a weeks worth of prying eyes), HAM is today near-universally recognized as more marketing hype than practical reality: it requires proprietary host software and operational intervention of many hosts, it does not provide the promised active-active data clustering, and it doesn't work for mainframe or Oracle RAC or most other clustered server environments. Thus, UVM customers remain trapped with no way to non-disruptively upgrade to a next-gen USP-V/VM platform (if such a thing ever shall exist).
10. Fortunately, EMC’s Open Replicator/Live Migration coupled with PowerPath Migration Enabler offers customers a more efficient and non-disruptive means to migrate off of older storage onto either DMX or V-Max…and not just from Symmetrix storage – EMC’s solution provides non-disruptive or minimally disruptive migration off of most Fibre Channel storage…TODAY. And SRDF has provided HA with array fail-over for years…

Given the growing rumors that HP will soon replace USP-V with their own native clustered EVA storage arrays, plus the obvious demise of Sun as a reseller once Oracle takes over, we should probably be asking ourselves: How soon the USP-V will go the way of the Hitachi Mainframe!

Needless to say, you can all rest assured that the jungle cat that is V-Max will be increasingly painful in HDS' future – however short that future may be!

 

Another post by the storage anarchist!

 

technorati tags: EMC, V-Max, Symmetrix, Hitachi, USP-V, HAM, UVM, Open Replicator, PPME, PowerPath, HHAM, EFDs, Enterprise Flash Drives, FAST, Flash, Green IT, DMX, SATA

Comments

[soikki]

Dear Anarchist, as a customer, I'd like to know the following:

-When will the V-Max be able to migrate "normal" luns to and from "thin luns"?

-When will the V-Max no longer lock the itself during lun migration (it does it on beginning and end)

-When will V-Max be able to migrate thin-luns to other thin-luns?

-When will the V-Max get rid of the legacy problems, such as having to make meta-luns in order to grow a lun? This is so medieval...

-Talking of meta-luns, even srdf from dmx or v-max requires the meta configuration on luns...

-Will there be a possibility to easily grow a thin lun (meta is not the answer)

-will there be "zero page reclaim" type functionality for thin luns?

With current _functionality_ there is no much reason for having V-Max. HW looks nice though.

Pleas, do write about subjects that matter to customers, persons that use the storage arrays.

Just feeding the FUD -machine will not help any of us.

I'd like to announce that the old time capacity provisioning is over: It is utter nonsense to format the box full of hypers, and then create meta's every time a volume is provisioned (fat volumes)

In my opinion, the new era of capacity provivioning is something like this (a few points here only)

-volumes are created as they are provisioned (on most cases, thin volumes)

-meta's or luse's don't matter. When created, the volume gets it's size instantly.

-volumes can be expanded easily, no meta's or luse's

-volumes can be migrated from tier-to-tier, no matter what is the internal storage array config of the volume

BTW, Clariion GUI is one step into the right direction, I think that many companies could use that as an example. Although also it has some development to do. But so do all things :)

Why, oh why, do these blogs never handle this kind of matters? Stop making war, make our storage wiser.

-Soikki

[Dave]

T Lives-- I love it! I just checked Youtube. For the series, over 600K views with a 4.5 rating by nearly 1500 people. Not too shabby...Go figure.

Remember the viral video challenge I put forth way back in Nov of 2007 on this blog? (see comments):
http://thestorageanarchist.typepad.com/weblog/2007/11/0049-hds-rifs-m.html#more

No one ever claimed the $1,000 prize I put up!

[the storage anarchist]

Soikki -

I'm sure you'll understand that I cannot answer questions about future capabilities in a public forum like this. If you'd like to discuss with your EMC account team under NDA, I'll be happy to answer all of your questions.

Allow me to clear up one thing, though. V-Max does not "lock up" during LUN migrations - there are a few I/O's on the migrated LUN that take longer to service as the LUN id's are swapped, but applications should not notice these any more than they would notice a temporary SAN congestion.

At least we agree on at least one thing: old-time provisioning should be retired, in favor of Virtual Provisioning. Even if customers don't take full advantage of "thin" provisioning (you can pre-allocate a Virtual Device), they will realize the objective of just-in-time provisioning, wide striping, and (in 2010) Fully Automated Storage Tiering at the sub-LUN level.

Interesting times, to be sure!

[soikki]

Thanks Barry, yes it is good to hear that at least you have ~same vision about how the provisioning should be done. I recommend that you try to get the same vision more widespread in your company.

The sub-lun level FAST looks very promising.

About the symmetrix lock during migrations (and other limitations also) see EMC's document "Best Practices for Nondisruptive Tiering via EMC® Symmetrix® Virtual LUN" and check ie. pages 10-13.

Some copy-paste:
"Upon submission, the external Symmetrix configuration lock (lock15) is placed on the array in order to perform the first of two configuration changes during the migration."

"The release of the configuration lock allows other migrations, or configuration changes"

[the storage anarchist]

Like I said, the lock is held for mere fractions of a second, after which you can configure additional migrations (or config changes).

And in fact, the lock duration is so short, you can configure as many as 1024 concurrent LUN migrations (128 per engine). Hitachi allows you to queue only 64, and those are performed only 8 at a time.

FYI - Locks are an inherent part of ANY computing architecture that allows for massive paralellism, as does Symmetrix. There are always operations that require the assurance that only one process is modifying data at a time. Through a concerted effort over the past several years, Symmetrix engineering has reduced the duration of virtually all configuration change locks, enabling not only non-disruptive code upgrades, on-line LUN migration, and even on-line configuration changes and storage allocation operations. I'm sure there are still opportunities to improve, but things have improved significantly since the pre-DMX days.

[williamwbishop]

I shudder as I think of it not locking and someone else coming along and moving something while my script is completing. This is one area, I really hope they don't "fix".

[Nigel]

HP dropping the USP V in favour of clustered EVAs - come one Barry you just made that one up didn't you.

I like a lot of what the EVA does, but it is not in the same league as the USP V - even if you clustered a bunch of them. EVA firmware has a buggy reputation and doesnt scale particularly well.

As for your comment suggesting that a massive subset or even majority of the USP V/XP24000/Sun WhateverTheyCallIt install base not using external storage. Surely you just made that one up too? I barely see a USP V these days without external storage hung off the back.

Obviously the question of whether or not this is wise or presents additional risk is another conversation. But from my experience most customers are doing it.

Oh and I really liked the Mr. T adverts. But then that probably says a lot about me :-S

Nigel

[the storage anarchist]

Hey, Nigel, How goes it!?

Didn't make up the clustered EVA thing, sorry - been hearing it from multiple sources (that I can't quote yet). The rumours include new HW, new SW and a couple years of strategic "stealth" development in order to stop sending storage margin $'s to Japan.

And I rarely find anyone running external storage behind their USP-Vs, other than to migrate the data off. Unfortunately, USP-V migration is so slow, it may APPEAR that their old storage is permantently behind it, but that's just an illusion.

And the Mr. T adverts ultimately got that marketing staff fired from HDS. Be careful with your alignments :^)

[williamwbishop]

I'm going to have to differ on the external storage on the HDS, I've seen a lot of them, with a lot of sites really liking it...which was one of the reasons we requested the licensing for it with the one we bought. We'll primarily use it for migration (which I've heard no complaints about), but I intend to leave my old archives on it (what do I care about the few ms penalty for using it if it's archival?). Anyway, I don't really care about the end results, I just like watching you guys fighting--it's good fun. ;-)

[soikki]

A lot of customers are using USP-V and external array behind it. It makes tiering really easy: have the tier 0 and tier 1 on the USP, and rest on the external array(s). With the dynamic provisioning, zero page reclaim and migration features of TSM, this makes quite a good tiered platform.

I just hope someone else comes up with same features but better software. Or HDS makes serious upgrade to the SW.