I am a big admirer of VNX and i would like to ask a couple of questions about the functionality of pools:
1- If i dont have FAST VP enabled, is there a point in having 2 disk types in the same pool? If yes, how will the system decide how to spread the LUN on the private raid groups?
2- If i have a LUN residing in a pool of 1 disk type, is this LUN spread over ALL the disks in the pool? or over certain "private raid groups" ?
3- If i have a LUN residing in a pool of 1 disk type and i add more disks to the pool, will i get performance enhancements assuming that i had performance bottlenecks from lack of spindles? i.e: will the LUN be redistributed over the new disks that i add to the pool? Is there a manual operation required after adding new disks?
4- If FAST VP is enabled on a pool, when does relocation happen? If the scheduler says all days, all hours. When does the relocation happen and under what conditions?
5- Can i create a LUN that will be used by data movers (for file access) from a pool which i am using for block access?
1) don't see the point, i assume it will deploy on private raid groups based on the tier you specify and it will stay there. Might as well create distinct pool for each tier.
2) it will be spread over as many private groups as possible in 1g slice increments
3) if you are on flare 32, whenever you add disk to an existing pool it will rebalance automatically the LUNs onto the new drives. After that it will stay pat if you don't have FAST license.
4) it's a scheduled process, it collect stats all day and during the specified time window it start moving slices around.
5) yes (i have ), for performance consideration EMC recommends to use dedicated pools for File.
Can you please explain how i can assess the impact of "Thin" LUN when compared to a "Thick" LUN? How much of a performance impact will there be?
Is there a specific best practice that if a certain LUN is larger than a certain size, it is advisable to create it as a Thin Lun or maybe a certain number of IOPs?
i have not seen any numbers (maybe our EMC friends and USPEED gurus can chime in), the only numbers i have seen is 10% overhead on pool LUNs versus traditional raid group LUNs (metadata management for pool LUNs). I have not seen any best practices that state thin better for workload xyz and thick better for workload abc. Maybe heavy random write workloads would benefit from thick LUNs because when you create a thick LUN its 1g slices will be not only reserved but also fully allocated (new to flare 32). In my shop we decided to provision everything as thick LUNs because while over subscription is great, we can't procure storage fast enough if one or more systems starts consuming storage really fast. We rely on host side over subscription (thin VMs).
i have not seen any numbers (maybe our EMC friends and USPEED gurus can chime in), the only numbers i have seen is 10% overhead on pool LUNs vs traditional raid group LUNs (metadata management for pool LUNs). I have not seen any best practices that state thin better for workload xyz and thick better for workload abc. Maybe heavy random write workloads would benefit from thick LUNs because when you create a thick LUN its 1g slices will be not only reserved but also fully allocated (new to flare 32). In my shop we decided to provision everything as thick LUNs because while over subscription is great, we can't procure storage fast enough if one or more systems starts consuming storage really fast. We rely on host side over subscription (thin VMs).
dynamox
11 Legend
•
20419 Posts
•
87439 Points
640
0
Posted April 19th, 2013 05:00
1) don't see the point, i assume it will deploy on private raid groups based on the tier you specify and it will stay there. Might as well create distinct pool for each tier.
2) it will be spread over as many private groups as possible in 1g slice increments
3) if you are on flare 32, whenever you add disk to an existing pool it will rebalance automatically the LUNs onto the new drives. After that it will stay pat if you don't have FAST license.
4) it's a scheduled process, it collect stats all day and during the specified time window it start moving slices around.
5) yes (i have ), for performance consideration EMC recommends to use dedicated pools for File.