25% of new disks allocated immediately?

[Subversive]

Hi, we have a 3Par 7200 system. Started with 2 shelves, each with 18x 450GB. We just added a 3rd shelf, with 8x100GB SSD, planning to set up an AO configuration. I haven't configured a new CPG yet for the SSD drives or anything, but they are already showing 25% allocated. Can someone explain why this is?

3parnewdisksadded.PNG (17.59 KiB) Viewed 27636 times

[Architect]

That is probably reserved spare space. Remember you are looking at the raw utilisation of the total drive. Do a showpd -c -p -devtype SSD, and look at the colums to see what the chunklets are used for.

[edit]

By the way, these are the different sparing algorithm you can choose (System wide for a 7000 series, V-series is different afaik):
Minimal: 1x biggest disk size worth of chunklets per 24 drives with no minimum
Default: 1x biggest disk size worth of chunklets per 24 drives with an enforced 2 disk minimum
Maximal: 1x biggest disk size worth of chunklets per installed type per enclosure
(your current sparing algorithm can be viewed with a showsys -param)

And as far as i have learned:
SSD spares to SSD.
FC* spares to FC.
NL spares to FC and NL.
*FC =Fast Class

So that would explain why for 8 drives you have 2 drives of spares chunks on SSD?
(it should show you are using default at the moment, according to above rules)

[/edit]

Is there any reason why you've put all the SSD's into 1 cage and not spread them over at least 2 cages?

[Architect]

Regarding the AO and SSD CPG configuration, this is how i would typically set it up:

- I would go for a 3+1 CPG configuration for SSD, created from CLI (to be sure the right stepsize is being used).
e.g. raid 1 would not make much sense as these drives can support like around 20k seq. iops and around 2k fully random iops of the ugliest kind. In my experience there are not much systems (none) that have regions so hot that it will overdrive SSD before it has filled SSD completely. With Raid 5 3+1 you would utilize the 8 drives optimal wasting only the minimum amount of space on raid overhead.
- I'd create the AO set with T0 as SSD and T1 as FC (never set a wrong class of drives at the T-levels, as AO uses fixed values per T-level to determine when regions need to go up or down)
- i'd set the mode to "performance" so it will try to fill the SSD drives as much as possible (let them work for their money, you've paid enough for them)

Set AO to run at the most idlest period, and configure the schedule from CLI so you can configure AO to run with a compactcpg in trimonly mode, so in your case it will never do any needless, lengthy, and performance degrading CPG compact jobs. (with only one CPG per tier there is no need to compact).

Assuming weekdays are the most used and weekends show a completely different AO profile, i'd setup AO to run weekdays only, using the full last 24 hours as a measuring period.

Lets assume your most idle period is 3 AM after backup and all AO tasks should be finished before 6AM as then the first users drop in again and we need full performance again

In that case the CLI command to schedule AO would look like this:

Code: Select all

createsched "startao -btsecs -24h -maxrunh 3 -compact trimonly <AO_CONFIG_NAME>" "0 3 * * 2-6" AO_RUN_3AM_TUE_SAT

*Create the schedule with a local 3par account, preferably a dedicated system account only used to run AO tasks with, as the credentials from the user that creates the AO task will be used to run the task, but 3paradm would be fine as well.

Explanation the option of above command:
-btsecs -24h: Look back 24 hours from this moment as a measurement period for AO
-maxrunh 3: Do not run longer than 3 hours (3AM +3 hrs = 6AM)
-compact trimonly: Force AO not to start a full compactcpg after AO is completed, just do a trim
<AO_CONFIG_NAME>: Name of the AO CFG you are using (do a showaocfg to see the name)
"0 3 * * 2-6": Crontab style time notation (Minutes, Hours, Day of Month, Month, Days of Week where 0 = sunday and 6 = Saturday)
AO_RUN_3AM_TUE_SAT: Name of the schedule in the schedtask list

[Richard Siemers]

I've asked/argued this point myself with HP.

I would open a ticket, explain your concern and ask them if its possible to use FC spares for SSD. Let us know what they do/say!

[Architect]

that wouldn't be wise (if it is even possible at all).
Once a disk would fail, you would have a serious performance impact as SSD storage is now being served by FC drives.

[afidel]

Unless you really care about your backup/batch job performance I'd seriously consider running AO against your production hours (ie we run ours at 6PM against the previous 12 hours as 6-6 are our prime user interactive hours, we don't care about hot blocks during backups or any nightly batch jobs, this obviously varies with business requirements)

[Architect]

It depends on the customer i guess.
Most I work with have a main usage cycle during local time, but are open 24/7 for other countries etc. So we run AO in the least used hours in that case.

If you do not measure your backup and batch job processes however it can bite you in the proverbial a**, as these blocks will travel down to NL because they are not measured and heavy batch processing and high speed backup dumps would overdrive the NL-Tier, causing overall bad performance. That is the main reason I advice to look back a full day, and not only at the production hour.

but if you are a small company, and nothing much is happening during the night, i can fully understand that parts of the day do not need to be included in the monitoring.

[Richard Siemers]

that wouldn't be wise (if it is even possible at all).
Once a disk would fail, you would have a serious performance impact as SSD storage is now being served by FC drives.

Even on a bad day with an SSD drive failure using FC as spares, you will net 13% better results than using SSD as spare. The majority of his system's data is already on FC, and the goal is to move as much of the hot data into SSD as possible. My suggestion accomplishes this 24% to 13% better than the existing config.

FC Spared, no failed SSD = 726 gb usable SSD, 24% improvement
FC Spared, 1 failed SSD = 634 gb usable SSD, 13% improvement
SSD spared, No fail = 552 gb usable SSD

Add on top of that, the low failure rate of SSDs, and the time it takes for HP to replace one... pretty sure the system will operate in the +24% range the majority of the year.

[Architect]

I agree on your numbers, but my point is more the predictability. If a drive crashes, the performance would go down. Performance at unexpectly goes down is an ugly thing. What if FC was driven to 90% of it's capacity (io-wise) and the ssd fails. It would be driven over 100% and the performance would go down more then you'd expect, or like. Personally i'd never design that.

Anyway, i think this is more a theoretical discussion, as that it is not possible (as far as i know) to spare ssd to FC.