The CX LUNs madness!

[...] This post was mentioned on Twitter by Enrico Signoretti. Enrico Signoretti said: New blog post: The CX LUNs madness! http://bit.ly/aK4bJB [...]

Well, both have their advantages. By the list of things you mention above, there is no way for me to actually pre-allocate all blocks on a LUN when using Compellent arrays. But what if I want to do just that thing for an important database?

There are trade offs for any choice I make, and high levels of automation usually means that you decrease the number of choices or parameters I can tune to my desire. I’m not saying the Compellent way is bad, but I don’t think either one is better since they just use different concepts when provisioning storage.

Bas

I don’t think you got what I was saying in that blog post.

FLARE LUNs are thick LUNS, MetaLUNs are thick LUNs concatenated or striped together. so the basic LUN is a FLARE LUN you expand them by putting them into MetaLUNs.

Pools are LUNs created from file system extents. Most if not all provisioning will probably be done from Pools from FLARE 30 onwards. Today Thin LUNs are supported from Pools, thick LUNs in the next release.

It would be more interesting to read about what goes on inside the offerings you’re reselling at a deeper level then what we’ve been engaged in this morning.

@Bas
Actually it is possible to preallocate a LUN, and in some extreme special environment we’ve done it. But Compellent works using “thin” as default, not the other way around.

@Storagezilla
We’re putting up technical articles on how Compellent works internally, and maybe you should check them here:

http://www.cinetica.it/2010/04/02/how-compellent-storage-center-works-part-1/
http://www.cinetica.it/2010/04/06/how-compellent-storage-center-works-part-2/

And more are coming, you should check them because I’m not sure that you know how Compellent really works internally, and vendors competitive analysis are a bit narrow focused.

Mark,
I clearly got the message, CX is way too complex to administer than desired.
CX has the ability to provision different kinds of LUNs, each type has a different behavior/constraints and needs different competencies: one provisioned by “experts”, one by “architects”, one by “administrators”, do astronauts have any role?

My take is only about the fact that Compellent is simpler to use because it has only one way to do things by just administrators (no astronauts required).

I’m seeing that you are discussing with others about “dealing with legacy“, maybe I’m rougher than others but I’m not the only who looks for simplicity.

ciao,

Storage administrators aren’t experts?

That’s idiotic. Of course they are.

Maybe those you’re dealing with aren’t but Storage Administration is a trade like any other, be it electricians, plumbers, carpenters or stone masons. They need to work at their trade and understand what they’re doing to get the most out of the storage, Fabio’s own posts on the topic show how understanding the internals alone gets the best out of the platform.

Simplicity is there for anyone who wants it with Virtual Provisioning but so is the ability to design more involved storage architectures.

You’re on a losing battle with that one.

Mark,
You are not focusing on the point.
Compellent is simpler to use than CX: ease of use means less TCO.
Customers don’t want complexity they need only one way to provision and manage storage not many ways, each one with constraints and limitations.
You wrote a post where you speak about experts, architects and admins to provision LUNs not me. Compellent needs only a storage admin to provision fully featured LUNs ( *without constraints* ).

E

Besides the constraints of having to dedicate all four of it’s PCIe slots and it’s PCI-X slot to the backend storage to even approach the drive number the system is supposed to support all while offering the hosts .5GB of write cache.

CX Thin LUNs are as easy to provision as Compellant LUNs and you can add hundreds of drives to a Thin Pool without having to dedicate nearly every port in the system to do it.

Data Progression was a nice trick. So nice everyone is starting to do it.

Mark,
I see that you have abandoned the field of license fees and the one of ease of use,

now PCI, cache and automated tiered storage? Ok, I’m ready.

about PCI:
PCI is the same standard that EMC is using in its arrays, the main difference between Compellent and EMC is that CML uses standard PCI slots/cards and your company prefer a closed approach.
From a technical point of view Compellent has a maximum of 18 FC ports per controller (total of 36) and the big advantage is that you can configure the system to fit at best your needs!
If necessary , You can also reconfigure your hardware BE,FE loops without service disruption! CX has only fixed configurations: if you buy a CX-120 and you need to upgrade to a cx-480 you need to update controllers, cabling and so on (BTW, you need to stop your operation to do this!!!!).

here: http://www.emc.com/collateral/hardware/white-papers/h5534-intro-clariion-cx4-series-ultraflex-tech-wp.pdf
I find a lot of limits in your machines: max # of Raid groups, Max # of LUNs, Max # of virtual storage pools, etc, etc, etc, etc. Pages and pages of limits. none of them are present in Compellent.
The most interesting thing are the limits of thin provisioning: only raid 5 or 6!, max 512/2048 thin Luns (depends on cx model), max # disks per pool 180.
Some customers will be forced to buy bigger systems only to avoid constraints of your provisioning model!!!
All these limits and constraints are not present in Compellent.

the Cache:
the CX 960 has a big cache, it is indispensable because your old architecture is cache dependent.
Your write cache is 4.5GB for your CX-480 (page 7 of the document shown), you need it to mitigate the write penalty of RAID5/6 and, probably, other operations. Compellent has no write penalty because each write is performed on the fastest tracks of the speediest disks in RAID10 and then migrated to other tiers of disks/RAID levels due to its architecture.

How you use the cache? Really, I don’t know but some systems use cache as a repository for snapshots/replica bitmaps/journals for example! I will be very curious to know how much cache is used for caching!
BTW, on the Compellent side you have two caches per controller 3GB read (not mirrored) and 0,5 write (mirrored), so you have a total of 6+0,5 GBs.
I don’t know how EMC cache works but I know very well about Compellent: the cache has dynamic blocks, each write allocates only the needed space: if you write 8Kb blocks you will have a lot of blocks cached.
In many traditional storage arrays the cache block is fixed (or there are fixed partitioning techniques), if we assume a standard 64Kb block size for cache we will find that Compellent has a good chance to store as many block as a 4GB write cache!

About FAST (automated tiered storage).
FASTv2 will be available in Q3, now you haven’t an usable Sub-LUN automated tiered storage. Actual EMC offering is very poor and incompatible with other CX features! i.e. FASTv1 doesn’t support thin LUNs.
Sad to see that you are speaking about FASTv2 since the beginning of 2009.

last but not least, about Q3.
Please stop to speak about product that your company will release in a future, try to speak about what you have and what is working today.