Somebody asked me on Twitter the other day if our arrays allowed a pair of host HBAs to concurrently access a single LUN though two different controllers - telling me a competitor was saying we couldn't. Well, that was pretty whacked because our clustered architecture is designed specifically for that purpose. What they probably meant to say was that their own product couldn't do it. Anyway, it got the juices flowing for a new SWCSA vid!
If you are wondering how to get the most out of VMware's v-Sphere multipathing options, you need to make sure your storage array allows you to access individual LUNs through multiple controllers at the same time.
Why would you limit yourself to one controller per LUN, like Clariion, Netapp and HDS among others when you can balance the load dynamically across multiple HBAs and controllers with 3PAR InServ arrays with mesh-active controllers. To be clear, this industry-leading clustered storage capability is designed into all our arrays, from our mid-range F Class arrays to our enterprise T Class arrays.
OK, so InServ can do Active-Active.
Big whoop.
Symmetrix V-Max can do Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active-Active.
That's Active*128 simultaneously, with absolute cache coherency and assured end-to-end data integrity, *AND* while replicating writes to multiple local and remote replicas.
What's more, EMC PowerPath/VE (Virtual Edition) can dynamically load balance across all of those targets, ensuring that each ESX server is maximizing its utilization of both the 128 targets AND the multiple HBAs in the server - making it inarguably the most efficient of the referenced v-Sphere multi-pathing options.
We seem to have slightly different definitions of "industry leading clustered storage," my friend ;-)
Posted by: the storage anarchist | August 14, 2009 at 12:09 PM
T800 has up to 128 host facing fiber channel ports and can take I/O down any/all of them for any/all LUNs. In fact you can get more than 128 host facing fiber channel ports if you wanted to, just reconfigure some of the disk facing ports to be host facing. I suppose in an extreme case if you only had 1 disk shelf you could have 190 host facing fiber channel ports.
Anyways, just wanted to gripe to Mark about vSphere support, since I just got an email from the support dept we are upgrading to 2.2.4MU4 and they say that vSphere isn't on the "certified" list. I think it'll be fine though!
My vSphere hosts are happy with 4 paths, and 1 HBA per system.
Posted by: nate | August 14, 2009 at 01:19 PM
Thanks Nate, I think Anarchist was talking about controller engines and not ports, but his 128 number is only 120 more engines than EMC supports today. There is a Max of 8 engines - which is the same number of nodes in a 3PAR InServ T800.
And of course we do all that stuff regarding absolute cache coherency and assured data integrity and while replicating data.
Customers pay extra for Powerpath/VE when they could get v-Sphere's native multipathing to work amazingly well for free with a 3PAR InServ. But the bonus of Powerpath is paying more to EMC's professional services organization to set it up and maintain it!
So, it looks like we are only behind in charging customers for professional services to make it work.
And how does all this high end capability of our mid-range F Class arrays compare with V-Max's mini-me - the Clariion? It leaves Clariion way behind. A customer can get the same high end capabilities of a T Class or V-Max array but with a mid range F Class.
Posted by: marc farley | August 14, 2009 at 01:32 PM
Nate, I just did a quick double take on the certification front. We were certified by VMware on the day v-Sphere announced - for active active. Our own cert matrix includes v-Sphere (ESX 4.0) too. You will be fine.
Posted by: marc farley | August 14, 2009 at 01:44 PM
PMSL Marc - 120 more than they support today... how spot on is that statement.
SVC is of course part of the same elite band in the 8 category today :)
Posted by: Barry Whyte | August 14, 2009 at 02:28 PM
Bar Why-Tar! I had to look up PMSL. How did I not know that???
Posted by: marc farley | August 14, 2009 at 04:10 PM
@storage anarchist: There's medication for the symptoms of grumpiness and anger that you are constantly exhibiting. Take a happy pill, would ya?
;)
Posted by: Bill | August 14, 2009 at 04:13 PM
ROFLMAO @ Marc :)
Posted by: Barry Whyte | August 14, 2009 at 04:17 PM
What is it with the number 8? Whether it be 3PAR, or EMC, or Fujitsu, or BlueArc, or Exanet. Myself I haven't noticed a storage system either NAS or SAN that has on the market today something that goes beyond 8 nodes. I just find it curious that so many companies are at 8.
Posted by: nate | August 14, 2009 at 04:51 PM
N8,
8 just works 8 that way, I guess.
Posted by: marc farley | August 14, 2009 at 04:55 PM
(8 is so Jon and Kate)
ROTFLMAOWPIMP
V-Max has 8 engines indeed, but each engine is actually two independent nodes ("directors"). So ours actually goes to ELITE SIXTEEN (today)!
(In reality, SVC is really just 4ea. 2-node clusters and there are quite a few less than 128 front-end ports in the standard 4x2 config. Hosts can only access storage mapped to the 2-node IO group they are connected to, and I'm pretty sure there's no cross-I/O group cache coherency so you can't actually Read+Write the same LUN over all 8 nodes simultaneously...right Mr. Whyte?).
Oh, and by the way - CLARiiON is actually Active-Active these days.
Posted by: the storage anarchist | August 14, 2009 at 06:37 PM
Anarchist, your "me too" mention about Clariion proves my point about the term "active active" being as useful as "cloud".
EMC's documentation on Clariion's Asymmetric Active/Active feature is very clear about the negative performance impact of multipathing across both controllers. In a nutshell, the guidance provided is intended to make sure customers do NOT try to use it for performance and dynamic load balancing. That doesn't help v-Sphere customers very much that are trying to get the most I/O from their storage.
3PAR's F Class has a much more advanced architecture for supporting virtual server I/O workloads.
Posted by: marc farley | August 15, 2009 at 09:44 AM
All seeing aint so good. Just look at multi-cored CPU and cache snooping - a MAJOR bottleneck in modern system design. Why would you want more than 8 ports to service an I/O ? esoecially if its going to slow it down.
As I've always said when asked about SVC's 8 port per vdisk model - its not how many, but how much you can do with what you've got. When the bus behind the port can sustain its 100% bandwidth, who needs to double or quadruple to number of ports. When the processor behind the port can equal that...
Its not what you have, but what you do with it that counts ;)
Posted by: Barry Whyte | August 15, 2009 at 04:58 PM
@marc/@anarchist; The note about Clariion being active/active and the footnote is classic EMC.
Recently we evaluated 3Par against vMax and had to go through the usual EMC tactics. I was led to believe that the vMax thin/virtual provisioning was good and was 'automatic' except the EMC team gave me a best practice document that was 120+ pages :-) If it was so easy why did I need a vMax best practice document at all!
Posted by: ExFlixer | August 17, 2009 at 05:13 PM
I don't know about all this storage talk... I came here for the sweet Farley Blues!
Posted by: Chris Fricke | August 17, 2009 at 05:36 PM