Just shy of proper LUN count...

[pgsengstock]

Hi all,

Lengthier suggestions are appreciated, but I'm really just polling right now...

So, we only have 6 Xserve RAID data LUNs (3x full 14x 750GB chassis) for our SAN volume (our metadata is on a dedicated Xserve RAID controller, 3x 180GB, 2+1 RAID1 mirror). I'm trying to figure out the best way to reconfigure our volume for optimum performance, given that we're straying from the "multiple of 4" rule for video pools. This is to serve 32 lab clients, which are a mix of video workstations and animation/web design workstations, depending on the time of day. Here are our options:

- one big pool with all six LUNs (which is what we had been doing)
- one pool of 4 and one pool of 2 (courtesy Xsan's default SD Video config, though it complains about the number of LUNs during setup)
- three identical pools, each with 2 LUNs (similar to Xsan's default General File Server config)

We're in a tough spot because we have students trying to edit-in-place video (big data transactions), at the same time other students are working on animation and web design (small data transactions). The video editors complain about file drops when the animators are in class and the animators complain about generally slow reads/saves when the editors are in class. It usually isn't an issue until later in the semester, when our lab is packed with everyone trying to finish their projects. I'm just trying to find a happy configuration for all, given the hardware constraints. The cvlog's sysavg looks good with any of these configs, but I just don't if I can trust one config over the other.

At present, I've got 6x 6+1 RAID5 LUNs, with every two assigned to their own data pool (third configurtion listed above). Stripe breadth is 32K for each pool (including the metadata pool) and the block allocation size is 16K. I got this per the equation:

[MattG]

IMO, the latter: three pools of 2 LUNs each. Then provide a round robin allocation strategy so that a new pool is available as each student writes. I assume you blow away the volume at the end of each semester, so that is why I recommend round robin. I like to make everyone equally as miserable as far as bandwidth availability and access latency, and three pools with 2 LUNs each will guarantee that.

[pgsengstock]

Matt,

Thanks for the reply. Is there any big disadvantage to going with just one big video pool (all 6 of my LUNs)? The stripe breadth equation doesn't work for this, so I don't know what stripe breadth or block size to set. What would you recommend, in that case?

The big problem is that everyone is asking more and more of this SAN, beyond what it was built for.

I just tested 24 clients on it with DiskFire, and the results don't look too promising...


Pete

[abstractrude]

2 luns per pool with round robin is your best bet here. its the psudeo perfect solution for final cut and multiple editors. perfect would be 2 stripe groups of 4 as symmetrical is muy bueno as stornext striping is done in a symmetrical method.

you have 24 editors doing HD? or SD?

Do you have any resources to get more gear? because i would build two separate volumes in this situation,
can you build a second metadata volume on the other side of your metadata chassis?
bump the memory up in your controllers, go with two volumes and build one for gfx and one for video. two luns for graphics four luns for video.

volume1:
data luns 4. 1 stripe group

volume2:
data luns 2. 1 stripe group

set block size and breadth accordingly.

[MattG]

The problem with 6 LUNs in one pool is that performance does not scale beyond what it would be with 4 LUNs.

Xsan is software, and has to tell the client how to split up the breadth of the blocks that are being sent to each LUN. Ideally, a burst of 1024K of data gets sent through the fibre to or from the storage. That number is a binary number. This means you have to give those blocks a binary number of LUNs to interact with, or the math will be complicated. When the math gets complicated, and because this is software, we lose performance when trying to calculate how 1024K of data gets striped onto 6 LUNs.

If you had 8 LUNs, we would be recommending a single storage pool. But because you have 6, we're recommending splitting that into 3 groups of 2 (a binary number!) LUNs each.

Why not split it into one group of 4 and one group of 2? Because as the files were written to the volume, there would be a mysterious intermittent nature between acceptable and terrible bandwidth availability, depending on which of the two pools were being written to. You don't want that sense of mystery to pervade itself amongst your users. Be consistent. Make everyone as miserable as the other. Three groups of 2.

[ravi]