LUN design best practice

[admin]

     Hey All,
Another thread just made me re-think the LUN design I was planning, here is what I was thinking:

500 concurrent users (mostly light weight users)

8Gb FC SAN:

• 74 x 10K 300GB SAS drives
  
• 25 x 15K 146GB SAS drives
  
• SAN does not allow for global hot spares
  

LUN Plan:

• LUN1: 14 x 300GB 10K SAS drives (RAID 10 + hot spare)
  
• LUN2: 14 x 300GB 10K SAS drives (RAID 10 + hot spare)
  
• LUN3: 14 x 300GB 10K SAS drives (RAID 10 + hot spare)
  
• LUN4: 14 x 300GB 10K SAS drives (RAID 10 + hot spare)
  
• LUN5: 12 x 300GB 10K SAS drives (RAID 10 + hot spare)
  
• LUN6: 12 x 146GB 15K SAS Drives (RAID 10 + hot spare)
  
• LUN7: 10 x 146GB 15K SAS Drives (RAID 10 + hot spare)
  

My original idea was to have these different LUNS so that if one LUN experienced BAD I/O activity, the user experience would be ok on the other LUN's.  I just read a post suggesting a 40 spindle LUN.

So now I am thinking about these questions:

• Do I have anything to gain by having few LUNs with more spindles? 
  
• If the number of users stays the same, than does it really matter? 
  

Thanks,

Drew

[mittim12]

Less LUNS will end up being less datastores to manage.   The downside is the more desktops you pack on a LUN is more opportunity to saturate the LUN with boot storms or other high IO intensive task.   Do you have cache available to offload some of those typs of scenerios?

[admin]

Yeah, that is sort of what I thought too.  I tried to find a good balance between I/O saturation and# of datastores.

The SAN I have is an HP p2000, and it doesn't have any peristent cache that I am aware of.

http://h10010.www1.hp.com/wwpc/us/en/sm/WF25a/12169-304616-241493-241493-241493-4118559.html

Each controller a has a cache, but I am pretty sure that is internal to the controller and I can't place files there....

From the Quick Specs:

2GB transportable read/write cache (per controller).

Thanks,
Drew