This post is more than 5 years old
3 Posts
0
961
January 16th, 2014 12:00
Pool Binding and FAST
I'm looking for some general information regarding how the pool a device is bound to affects its FAST policy. This is theoretical, but if you bound a LUN to a SATA pool, but gave it a FC/EFD FAST policy... The question came out of reaching a subscription limit on a pool that I would normally use with a certain FAST policy... The above example is extreme, but I was curious what affect it would have on performance.
0 events found
No Events found!
SYMCLIGuy
98 Posts
0
January 16th, 2014 13:00
What you are trying to do can't be done. FAST has a requirement that the device be boudn to a pool that is contained within the policy the device is associated with. If your device is bound to the SATA pool, you will be blocked from associating the device with a policy that only contains EFD and FC.
Is there something preventing you from increasing the subscription limit on the pool you would normally bind the device to?
SYMCLIGuy
98 Posts
0
January 16th, 2014 14:00
Hit Add Reply too soon :-)
It is also not recommended to bind devices to SATA in a FAST VP configuration. Even with allocation by policy enabled, the majority of new allocations for a device are going to come from the pool the device is bound to. As the SATA tier is typically configured as RAID 6 this can cause the WP count in the array to dramatically increase, which can impact the overall performance of the array - a write to RAID 6 results in 6 back end IOs (3 reads and 3 writes).
Storagesavvy
474 Posts
2
January 17th, 2014 12:00
SYMCLIGuy is correct, the Bind Pool must be in the policy, and the minimum % for any tier in a policy is 1%...
If you are trying to prevent a pool out-of-space condition from causing an outage, what you can do is use bind-to-policy in 5876 code rather than the original bind to pool. Effectively you bind the LUN to the FC pool, as an example) and associate the policy that has EFD 5%, FC 100%, SATA 1% (I'm making up random numbers as an example. New writes come in to the bind pool (FC in this example) and then FAST tiers them up or down.
if the FC pool were to fill up however, since bind-to-policy is enabled, new writes will spill into any other tier that is enabled in the policy (EFD and SATA) in this case. Limiting SATA to 1% means that only 1% of the LUN will ever be tiered down to SATA by the FASTVP policy engine, but doesn't necessarily limit writing data to that pool in the spillover condition. the LUN will breach the FASTVP policy and when FASTVP is able to, it will fix the tiering for that LUN to bring it back in-policy.
I would be that there are at least 1% of blocks in the TDEV that are rarely, if ever, touched and could safely sit in SATA.. If not far more than 1%.