UNSOLVED
J
JeremyBradshaw
17 Posts
0
1820
March 18th, 2014 09:00
VNX File OE 7.1 - LUN considerations (size/count)
I'm hoping others have contemplated this scenario and can help me out - "EMC VNX Unified Best Practices for Performance" states the following for creating pool LUN's in a FAST pool for file:
1- Create approximately 1 LUN for every 4 drives in the storage pool.
2- Create LUNs in even multiples of 10 (does this mean 20, 40, 60, 80, 100 and not 10, 30, 50, 70, 90?)
3- Number of LUNs = (number of drives in pool divided by 4), rounded up to nearest multiple of 10. (guess not (in reference to above question).
4- Make all LUNs the same size.
5- Balance LUN ownership across SPA and SPB.
6- Leave 5% available in the pool for relocations and recovery operations.
Regarding 1, 2, and 4 - the scenario of expanding the pool (e.g. purchasing more disks due to demand) doesn't seem to be a forethought here. Can anyone comment on what is best in the following situation:
We had 8 1TB disks in r6 6+2, and so I created 10 512GB LUNs in order to follow the 1 LUN for every 4 disks (that's 2 LUNs) rounded up to the nearest 10 (that makes 10 LUNs. In order to get the most space from 10 LUNs, I sized them at 512GB.
Now, we purchased 8 2TB disks and expanded the pool. At this point the number of LUNs in the pool based on the formula is still 10 LUNs. I'm not sure what I should do:
1- Increase the size of the existing LUNs.
2- Create 10 more LUNs of the same size (the newly available capacity won't divide by 512GB so this will waste a lot more than the required 5% free space in the pool).
3- Place the data from the CIFS shares somewhere else, blow away my file system and start over with a better design of LUN size/count which is future-friendly.
This is interesting, I have pretty much the same question and this happened to be the top most post when I came here to post!
I am trying to come up with a new vnx 5200 design. We have 17 NL SAS drives, 17 SAS drives and 3 FLASH drives for Fast Cache.
I want RAID10 so the 17th drive is really a hot spare for each tier.
So in a 16 drive RAID 10 group of SAS for this example (we have 600GB drives) that's 4800 GB according to RAID 10 calculations. So the math on the LUNS is 4, but we would round up to 10 LUNS, 5 on each SP. Sounds pretty balanced... but then I am confused at LUN sizing. They say to save 5% for reallocation / recovery operations. Well is that 5% out of the total storage of 4800 GB (which would be 240 GB), or 5% less of my calculated 480 GB per LUN? If its 5% out of the total storage of 4800 GB, then I'm really making all 10 LUNS 456GB ... NOT 480 GB.
Same situation for our NL SAS drives but they are 2TB, so the overall pool is 16384 GB and 5% less for reallocation / recovery would be 819 GB.
Rainer_EMC
6 Operator
•
8645 Posts
600
0
Posted March 18th, 2014 10:00
1- You shouldnt do – NEVER change the size of a LUN that is used for NAS – I think we even prohibit it
3 – I don’t think its worth it if you don’t have problems.
I would try to find a compromise between the BP guidelines.
Chances are all your existing LUNs are already striped by AVM.
How many 512GB LUNs could you create ?
If you used the BP for just the new disks – what would be the size / number ?
Sounds good.
I also contemplate going RAID6 for the NL SAS and SAS. RAID6 or higher is safe for more than 6 drives. According to this recommendation 16 drives would work for RAID 6, and then I would have a hot spare in each storage tier. http://www.smbitjournal.com/2012/11/choosing-a-raid-level-by-drive-count/
However I would be very concerned with write penalty. Though with Fast Cache I have to wonder if that would negate it. According to an EMC engineer that sized the system based on our current Celerra NX4, he said RAID6 plus fast cache would give us 1000 IOPS more than our 95% percentile usage which only seems to occur at night when backups are running. So either way we will see an upgrade... just I want it to be the best bang for the buck and I'm leaning towards RAID 10 due to the better write performance. Though the space would be nice if we went RAID-6. Oh boy, options galore.
JeremyBradshaw
17 Posts
600
0
Posted March 18th, 2014 11:00
Rainer_EMC wrote:
1- You shouldnt do – NEVER change the size of a LUN that is used for NAS – I think we even prohibit it
3 – I don’t think its worth it if you don’t have problems.
I would try to find a compromise between the BP guidelines.
Chances are all your existing LUNs are already striped by AVM.
How many 512GB LUNs could you create ?
If you used the BP for just the new disks – what would be the size / number ?
If I filled up the remaining space in the pool, (leaving 5% free), I could get 29.64 512GB LUNs, so I guess I'd round up to 30.
If I used BP for just the new disks, it would be 10 LUNs @ 1060GB each.
It really just doesn't seem like the best practices have a good logic or scalability. -->Edit: I just read your other post describing the logic so I half take back this statement.
BTW, there is no production data on this file system yet so I'm able to blow it away and start fresh.
JeremyBradshaw
17 Posts
483
0
Posted March 18th, 2014 11:00
I'm reading it as that the 5% is of the entire pool. Pretty sure it means, when you create all of your LUN's make sure the pool's subscribed % stays below 95%.
You're on a 5200, my question is around a 5300, but I'll be setting up two 5700's in the near future (using 3TB NL-SAS in Raid6 6+2). Maybe I'll throw these models into the tags list for the thread.
JeremyBradshaw
17 Posts
483
0
Posted March 18th, 2014 18:00
I think I might need to ask this a different way. Can anyone suggest a good rule of thumb for the LUN size in a file pool as well as a minimum/maximum for both LUN size and count?
It is clear they need to be in multiples of ten and that they need to be the same size. However the 1for every 4 drives rounding up to nearest 10 rule doesn't scale or take into account maximizing available capacity, IF you a) make your LUNs as big as necessary to get 95% full pool and b) need to expand your pool later with a different size multiple then the original config.
I'm thinking if I go with 50GB for the LUN size then I could almost always be able to add a multiple of 10 and would be able to hone in on 95% pool utilization. However I can't for the life of me find if or why a high number of LUNs in a file pool is bad for performance.
Rainer_EMC
6 Operator
•
8645 Posts
601
0
Posted March 19th, 2014 03:00
Well – if there is no production data on it and its not big work to blow it away then I would do that and start fresh
That case you could make all LUNs the same size and give AVM maximum flexibility in terms of striping
JeremyBradshaw
17 Posts
601
0
Posted March 19th, 2014 03:00
Would you think 50gb luns is okay? With 16tb now in the pool that's roughly 320 Luns. When I setup our two 5700's they're going to have 16*3tb NL-SAS and 32*3tb NL-SAS respectively so they'll both be well over 16tb pool capacity and so way more than 320 50gb Luns will be needed.
JeremyBradshaw
17 Posts
332
0
Posted March 19th, 2014 03:00
This is slightly hijacking my thread:). I still am digging for answers to my original question around LUN size/count in a dedicated FAST pool for file.
Rainer_EMC
6 Operator
•
8645 Posts
600
0
Posted March 18th, 2014 10:00
Here are the reasons behind this best practice:
- You want to evenly balance LUNs across SP’s – that’s why the number should be even
- Performance is best with AVM when it is able to stripe across 5 LUNs
- Same size LUNs is so that AVM can stripe
- Having multiple LUNs available to a data mover is better for performance since its then got multiple queue
So the rules just try to fit this into a calculation that can be easily followed.
As with every best practice it doesn’t fit every config so you adapt it and try to follow the meaning