Techno Musings

HTSM and VM don’t restrict migrations for local or remote copy functions so that is an error on your part.  Early only this was a limitation however it has been removed over time.

As to concurrency of volume migration processes.  Your numbers are incorrect again, go figure!  (Note I checked documentation, specification and conferred with engineering here in Japan so I would take this as gospel.)  Each USP-V can support up to 64 concurrent migrations and each HTSM instance can support unlimited Storage Domains.  All of which means we can dispatch equal to or greater than the number of concurrent migrations across several USP-V or USP or NSC or USP-VM systems as you can with the V-Max.

Note that HTSM does throttle the number of migrations intentionally, but this is a tunable parameter that we don’t have in the documentation as we are trying to protect our users.  Since we’ve had the feature that you are bragging about now, FAST, since well roughly 2004 and we have a significant market experience with this kind of thing we’ve learned to protect our users so that they can avoid operational errors and usability slips and mistakes.  The reason for the throttling is that the VM operations share the pool of concurrency with the Shadow Image operations.  So we limit the maximum number dispatched to each USP-V at a time. However in the spirit of showing our maximum possible here you go — note that the number to dispatch to each USP-V is an internally configurable system parameter which we’ve intentionally not documented again to protect out users based upon our long market experience.  Further when you consider user security and data privacy, HTSM and the USP-V also support either shredding or erasure of the source LUNs as we recognized that the migration process can leave a stale copy around and customers, for some use cases may want to ensure, that they are protecting their privacy.  We did this because unlike the V-Max the USP-V can easily be used to swap out aging equipment either at the end of the depreciation cycle or from a 3rd party, like the DMX-4.  This equipment may actually go back to the company holding the leasing paper, or to Hitachi who has just taken out a competitor, and having some assurance of privacy is critically important. (Note we have another form called our BED technology which is wire speed encryption.)  Barry, I don’t see that kind functionality anywhere in your materials can you let me know if you are indeed protecting the customer’s privacy post migration?

V-Max forces the customer, yet again, into a forklift upgrade scenario that continues to be a source of competitive disadvantage for EMC — you know you were the guys who said that what we were doing on the USP with UVM was impossible, and EMC has no resolution in site, what ever happened to Invista anyway?  Hey at least we can turn that aging DMX-4 into something worthwhile reclaimed capacity, what can EMC do with with the archaic DMX-4?  So assert my point again: EMC copies Hitachi when it comes to real innovation.  If you are quibbling about the maximum number of concurrent migrations, well here is my conclusion that is a weak argument.  However, it is nice to see that you are enticing us to copy EMC’s real R&D: sales promotion!  This confirms my suspicions all along.

Now that I’m done with the sparring, you’ve not responded to my olive branch: a joint post across both of our blogs either in a rigorous debate or to mutually explore a topic.  This is the second hint at such a request, but this time in my post and not as a comment.

UPDATE

Nigel made a great comment just to improve the usability and readability of this post.  To do that I’m posting Barry’s original comments on this post as a PNG here.  I did that because I want to be clear on not censoring since Barry is so sensitive about that topic right now.

More to come…

Tweet

Posted in Tech Talk

Comments (6 )

Post Comment

[...] Michael Hay » Blog Archive » My Response to Barry Tags: charity, competition, customer-talk, events, flash, green, japan, legal, open-source, personal, storage [...]

Well, Michael, all I can say is that something must be lost in translation between your sources and the XP24000 in our labs running the latest microcode. 8 concurrent transfers maximum, and remote replication must be suspended during the migration - and no way around those restrictions that we can find. And this has been confirmed by numerous customers running all 3 vendor-variants of the USP-V; we can’t ALL be making this up. Maybe what’s shipping isn’t what’s in your labs?

Given the measured ~2x impact on response times during the migration (in addition to the 1ms overhead of UVM for external volumes in the first place), it is no surprise that you’d have an undocumented throttle on this “to protect your users”.

V-Max instead dynamically adjusts its copy rate based on the workload and the migration’s impact on performance. A little smarts goes a long way in maximizing throughput (and the customer experience).

Your customers tell me that the net effect of the arbitrary hidden throttle and the performance impact is that TSM/UVM migrations are long, tedious, slow and painful…V-Max can effect a migration up to 128 times FASTER. I know that the Japanese are oft noted for their “100 year plan” approach to things, but customers really expect migrations to be a little faster than that (:> that’s a good one, you have to admit).

And yes indeed, both DMX and V-Max can securely erase drives, either automatically (e.g. after hot-failover and before a failing drive is pulled), or the entire array after the data has been migrated off. Thanks for asking. Protecting customer information is indeed the Prime Directive for enterprise storage.

But you and your compatriots really should take the time to understand the difference between FAST and V-Max’ Virtual LUN features. Virtual LUN is similar to TSM (except that it doesn’t need an undocumented throttle to “protect users” - yes, I’m rubbing it in). FAST (Fully Automated Tiered Storage), on the other hand, will automate the process of relocating data to different tiers based on workloads and customer-defined performance, price and energy policies. Hitachi have nothing like it, and you continually embarrass yourselves by asserting that you do (heck, you only recently even figured out how to get Flash and SATA tiers into your aging platform!)

Mixing up FAST and Virtual LUNs isn’t so good for the credibility of the Red Team (which doesn’t bother me, really). Your lack of understanding does provide for a good chuckle in customer/prospect discussions - even ardent HDS supporters have to admit that you guys just don’t get this Flash/FAST/SATA stuff yet.

And when you do, I’m sure you’ll try to copy FAST. Just like you did with SATA, Flash, large cache, multi-site replication, copy-on-write snapshots, PowerPath, etc.

But remember my prior advice: being first is meaningful only until there is a second. Then what matters is which is best. You win no prizes with your “copycat” arguments. You go ahead an proudly pin “First” on your product/features; I’ll be busy tagging them “Best.”

By the way, Symmetrix Virtual Provisioning isn’t a sales promotion - it is free to all customers henceforth. No strings, no limits, no dependencies. That’s another BEST: 100% free trumps “first 10TB at no charge” in anybody’s book.

As to the olive branch: sure - I’d love to jointly explore a topic with you. Shoot me an email with a few suggestions, and we’ll work out the logistics.

Oh, and you really need to chat with your blogger pals about censoring my comments. Christophe is no better than a snake-oil charlatan if he won’t actually publish my responses to his challenges.

Meant to say that I’ll be tagging Symmetrix implementations as “BEST” (I’m sure you’ll have fun with that typo

Hi Michael,

An interesting post. However, you dont introduce or give any background to what Barry initially said and what you are arguing about - its just straight in at the deep end. I think some links to what you and Barry have said previously on the matter would be helpful. I read a lot of blogs so have a general feel for what you are arguing about but some of your other readers might have better things to do with their time than read a ton of storage blogs :-S

Just a thought.

Nigel, thanks I’ll make relevant modifications in a little bit to make this a bit easier to follow.

Barry, what version of HTSM and of the USP-V firmware are you using?

Post a Comment