Big Symm is not the cat’s meoww
By: Christophe Bertrand on April 20, 2009
Comments(3 ) | Contact Christophe
Thank you for your comment on my previous post, Barry. It’s a pleasure to see you on these pages. I have to admit I found your post both utterly amusing and actually a little bit disturbing because many of your facts are wrong. So, let me point out a few important issues that need clarification here:
1) Where is Big Symm’s Storage Virtualization? You allude to this question in your previous comment. EMC Open Replicator may be able to migrate data, but stops short of supporting ongoing storage virtualization and intelligent, heterogeneous tiered storage. BTW, Universal Volume Manager (UVM) has “stuck” by many accounts, bringing a ubiquitous enterprise level feature/function capability to midrange storage and applications, including many CX arrays. Maybe this has to do with the V-Max static bin file/mapping architecture that makes it essentially impossible to do ongoing external virtualization. So what you’ve got is really a Big Symm.
2) I believe the published literature for the V-Max indicates support for 1000’s of concurrent migrations. Come on Barry, that’s your marketing folks talking! The Big Symm is still limited to only 4 concurrent active migrations. So there is a significant difference between the ability to “actively” migrate, as opposed to “concurrently schedule”.
3) We actually do support 64 LUNs in Hitachi Tiered Storage Manager, not 8 as you suggested in your response.
4) Your legal comments about REPLICATION were TOTALLY MISLEADING. I think you already read Claus’ blog.
Back to my earlier post, it seems that the “Tigon” ended up being a DNA experiment that did not quite produce the expected results.
I thought really needed to let you know 
Comments (3 )
Post a Comment
.
the storage anarchist on 20 Apr 2009 at 1:42 pm
I have no idea where you get your information, but you need to get updated. You seem to be stuck in a pre-2001 time warp of some sort.
1) There is no “static BIN file” in V-Max…in fact, V-Max provides both dynamic and concurrent configuration changes through direct system calls instead of config file changes. Tis is partially why VLUN on V-Max can move volumes faster than USP-V.
2) I have no idea where you got the number 4. The published documentation and release notes for V-Max says that the current limit of VLUN relocations is 128 per Engine, so 8 Engines=1024 concurrent moves. THe system can actually do a lot more, but we decided to limit to 128 for now. I know, I sit with the rest of Symmetrix management in the weekly development project review meetings (marketing isn’t invited to these meetings, FYI).
3) TSM allows up to 64 moves to be QUEUED, but will only relocate 8 volumes at a time, during which time application response time can as much as double or triple under the load (unlike V-Max). There is also up to 15 minutes of delay between each group of moves.
Plus, replication must be paused on all 64 queued volumes before they are queued, and cannot be re-enabled until they are all moved.
4) I stand corrected.
Thanks for letting everyone know that you are still ill-informed about V-Max…you really should try to get the truth instead of continuing to embarrass yourselves and your company with misinformation.
John F. on 21 Apr 2009 at 6:30 pm
Hi Barry,
“There is no “static BIN file” in V-Max”
There is a bin file however. How is this different from the DMX implementation? How is it updated, and how often? Inquiring minds want to know…
Thanks in advance
John
the storage anarchist on 24 Apr 2009 at 5:07 am
John –
It will probably benefit more EMC customers if we ask/answer these sorts of questions over on my blog. I’m sure Christophe would prefer we not commandeer his blog as a training manual for EMC storage administrators.
But since you asked, configuration changes on V-Max are effected via direct syscalls, and the changes are immediately logged in the BIN file for use should the system ever have to be restarted (eg after a manual or automatic shutdown). Enginuity 5773 operates similarly for DMX3 & DMX4, although not all config changes are dynamic on those platforms.