Comments on: LUN Stacker

By: Martin

Martin — Wed, 05 Nov 2008 10:18:00 +0000

The ability to concatenate multiple LUNs into a single LUN would be incredibly useful; I can do it at the host level but it’s a bit of a ball-ache for the sysadmins.

It would be neat to do the stacking in the SAN; can’t see it ever happening and I imagine it will always be done with host tools. Why? Once you’ve done it and moved it into our new wide-striped world, you can resize LUNs etc pretty much at will. I’m hoping that the sheer proliferation of LUNs to support misguided DBAs will slowly vanish as wide-striping and automated movement of blocks becomes more and more mainstream.

By: Globe Treader™ - © Kiran Ghag

Globe Treader™ - © Kiran Ghag — Wed, 05 Nov 2008 05:03:00 +0000

we try to stick to standard LUN “block size” to make data movement easy. VxDMP is used to move blocks around as discussed. This also allows to stack luns from diff storages to create bigger volume on host if one storage runs out of space.

This requires that the arrays in question are supported by veritas. we didnt go for SVC/USPV because it adds another comaptibility level between host and storage array.

Most vendors do not suggest/support mixing drive speeds in a RAID group or meta lun combination. Primary reason for that being performance driven by lowest performer. In similar manner, having blocks stacked from different storage means, lowest performer array drives the performance again unless storage level cache is able to absorb the I/O peaks most of the time…

By: Chris M Evans

Chris M Evans — Tue, 04 Nov 2008 20:36:00 +0000

Barry, yes, sort of; I was meaning that SVC sees all the blocks that comprise a LUN and therefore it has to read/write them in the same way that the Brocade DMM product would do in the fabric, so SVC is ideally positioned (if it knew how) to dynamically stack a LUN onto a new virtual one. Obviously the practicalities of executing on that are much, much more complicated, but my point was that SVC sees all the data coming through it.

By: BarryWhyte

BarryWhyte — Tue, 04 Nov 2008 19:58:00 +0000

I see I need to get you down here sooner rather than later

So what you describe is kind of applicable to SVC. The beauty is you simply create arrays and luns and present to SVC. You then pool those luns with the same characteristics, performance, redundancy etc.

Now the “host” LUN provisioning is from the pool, and you don’t really know where the actual blocks are – somewhere on that pool – but since they all act the same, it doesn’t matter. You can then offload the “striping / pooling” from the LVM layer to the SVC, and simply create a large enough LUN for the given application. At any time you decide to migrate from one pool to another you simply say ‘do it’ and behind the scenes the data gets move – host see’s not change, just the “host LUN” that was presented.

Unless I’m missing the point you were making?