Thin Volumes and AO

[skumflum]

In the ”HP 3PAR StoreServ Storage best practices guide” the recommended best practice is that no thin provisioning volumes should be directly associated with SSD CPGs if SSDs are used in OA configuration. The thin provisioning volumes should only be associated with FC CPGs.
Okay, so if I WANT a SSD only volume I should make this a thick? Likewise with NL?

We have the following objective:
1. Use thin as much as possible
2. Provisioning volumes in “silver, gold and platinum”-type’s performance wise
3. Have an option open for creating a volume above “platinum” level for pure SSD

We have about 2.5% capacity in SSD

What would you guys recommend?

[ailean]

We don't use AO or SSDs yet but I'm wondering if they are suggesting that if using AO you should start your Thin Volumes on FC and let AO move only the hot blocks up to the SSD so that SSD is only inhabited by hot data and not wasted on inactive stuff and that AO spends more time moving smaller amount of hot blocks rather then moving larger amounts of cold blocks down the tiers.
My understanding is that AO works best with repeatable every day IO patterns or seasonal ones but if you have something that's more random which must be prioritised for best performance it's best to manually place it on that tier.

[skumflum]

We don't use AO or SSDs yet but I'm wondering if they are suggesting that if using AO you should start your Thin Volumes on FC and let AO move only the hot blocks up to the SSD so that SSD is only inhabited by hot data and not wasted on inactive stuff and that AO spends more time moving smaller amount of hot blocks rather then moving larger amounts of cold blocks down the tiers.
My understanding is that AO works best with repeatable every day IO patterns or seasonal ones but if you have something that's more random which must be prioritised for best performance it's best to manually place it on that tier.

The “silver, gold and platinum” will be best effort, not guaranteed performance. Its balance… from the storage team perspective we want to maximize the cost of our hardware utilization.
I can’t predict the IO pattern because the volumes will be occupied with VMs of different nature. There is properly many dead files on fileservers, SQL servers with occasionally high IO demands and unpredictable IO from Terminal Servers

[Richard Siemers]

Code: Select all

Best practice: If SSDs are used in Adaptive Optimization configurations, no thin provisioning volumes should be directly associated with SSD CPGs. The thin provisioning volumes should only be associated with FC CPGs. 
This will help ensure that SSD capacity is consumed by Adaptive Optimization and will allow this capacity to be safely used to 95 percent or even 100 percent.

Thin is safe for NL as well as FC. The point they are making is that if you mix your SSD up and use it BOTH for a TPVV and for AO, then you run into a problem of manually managing how much SSD space AO can have so that the TPVV will always have enough space to grow as needed, best to use Thick SSD for your above platinum level.

[skumflum]

Code: Select all

Best practice: If SSDs are used in Adaptive Optimization configurations, no thin provisioning volumes should be directly associated with SSD CPGs. The thin provisioning volumes should only be associated with FC CPGs. 
This will help ensure that SSD capacity is consumed by Adaptive Optimization and will allow this capacity to be safely used to 95 percent or even 100 percent.

Thin is safe for NL as well as FC. The point they are making is that if you mix your SSD up and use it BOTH for a TPVV and for AO, then you run into a problem of manually managing how much SSD space AO can have so that the TPVV will always have enough space to grow as needed, best to use Thick SSD for your above platinum level.

This make sense but but would it not also be true for NL?

What about:

Silver : AO - FC/NL cost
gold: AO - FC/NL/SSD balance
platinum: No-AO - SSD Thick

But maybe it is a bad idea to make mixed AO configurations? If NL / FC moves too much down the NL drives, the 3tier NL/FC/SSD wille be pressed at FC?

[afidel]

You could set the AO to use an NL CPG that has a growth limit of say 80% of your NL free space leaving room for your TPVV to expand. When using thin provisioning it's always a balancing act between utilization and safety =)

Btw this reminded me that I wish that growth limit had a percentage free space metric as an option so you didn't have to go in and modify your CPG whenever you add capacity.

[hdtvguy]

What I think they mean is that if you use SSD in AO you should not make the bad volume in SSD and let AO move data in and out of SSD. The logic being is SSD space would traditionally be small and if the volume lives there all new blocks would go there and would need to be move out by AO rather than letting AO move the more ideal blocks in.

Our approach to AO is to have different AO groups.
For databases we have the following 3 tiers:
FC 15k Raid 1
FC 15k Raid 5 3+1
SAS 10K raid 5 5+1

We create the volumes in the Raid 1 set because our feeling is that we want databases to get the benefit of Raid 1 up front until AO moves stale blocks down.

For our VM system we do:
FC 15K Raid 5 3+1
SAS 10K Raid 5 5+1
NL 7K 5+1

In this scenario we create the volumes in the SAS middle tier since the odds that the VM will need higher performing disk is low and then we let AO move the little bit of hot blocks up to top tier and the bulk of the data migrates down to AO.

Basically you need to remember that net new blocks get created in the CPG defined in the volume when you created it. The AO moves data up or down as it feels it needs.

So let's look at it like this. If you create an AO config with the following 3 tiers;
SSD
FC
NL

and create volumes with the CPG in SSD then all new data blocks written land in SSD and will stay there until AO feels they need to move. Thus if SSD is a small percentage of your capacity you may run out of SSD space of cause AO to keep moving data out and then trying to move more relevant data in. AO can only move so much data in a given time so you want to layout your CPGs and default CPG for each volume trying to have the bulk of the data land where it will stay a otherwise AO and in turn the array has a lot of work to do,to keep moving data around.

We also create dedicated Copy Space CPGs that do not participate in any AO configs .

[mugurs]

@skumflum
Could you be more specific about where did you find that doc?

thanks,
mugurs

[skumflum]

@skumflum
Could you be more specific about where did you find that doc?

thanks,
mugurs

I used to find it by google "3par best practices", and it's still the second from the top, but HP removed it. HP website is a big digital maze although you can find most doc in the “Enterprise Library” http://h20195.www2.hp.com/v2/erl.aspx?keywords=3PAR+StoreServ&logic=OR&query=yes

I’ve attached a previously downloaded copy (don’t know if I violate any copyrights so please don’t sue me HP). I don’t know if this documents is valid anymore so please take it for what it is.