HPE Storage Users Group

Questions on CPGs

1) A CPG is not a disk group per se since any disk can exist in multiple CPGs right?

2) A CPG does not have a total size (disgregard TP on this) since those disks, unfiltered, could be in multiple CPGs right?

The CPG concept takes some getting used to.

Hello Scooby,

1) Correct, a disk can be (and usually is) in several CPGs. In my case, I utilize 4 types of CPGs. First is to differentiate between SATA and FC, and that is a hard separation of spindles... I have no CPGs that span both FC and SATA (I also don't have subvolume tiering)... The other 2 types I employ dictate raid type, and inner/outer track preference. I use raid5 with cage availability for production CPGs using the "fast" outer tracks (in my case thats 5+1), but for dev CPGs I use magazine availability (raid5 8+1) and the "slow" inner tracks. As you can see, my DEV and Prod share the same spindles, just one prefers the slow tracks, and the other prefers the fast ones. You can also use it to segregate data as well, such as if you're following a DB best practice to the letter... have data on even numbered magazines and logs on odd numbered ones, but for all other data use all magazines.

2) Thats true too, although you can set limits if you like/need per CPG. Multiple CPGs can pull free space from the drives. First come first serve, this could get tricky when you have a special CPG for say database logs that can only grow on certain disks, and you have other CPGS that can grow anywhere. Monitoring freespace on a PD level, or using a CPG strategy that does not limit PDs may be desirable. If a special CPG limited to portion of the systems starts to get full, I believe you can edit it to be less restrictive, and it will use the new disks for growth as well. At that both the majority of the data will be on the original set of disks, and you could use Dynamic Optimizer to rebalance that if you like.

I'm not sure I am completely used to the CPG concept yet either. I started on Inserv 2.2.4 and back then the CPGs were limited to 64 VVs, but they recommended only using 32. I was told that with 2.3.1 those limitations have been changed/removed/fixed but I've been sticking with 32 per until I learn more about it.

I believe that 3PAR standard is to steer customers to leaving the CPGs wide open with access to all the disks of the same type (FC vs SATA, unless you have Sub-Volume Tiering which I don't) and let the Inserv's wide striping do its thing. They can separate physical disk by usage, such as commonly a best practice for Databases, and I have never read anything from 3PAR that refutes that strategy, probably to play nice. Perhaps on smaller systems with a low spindle count, this might be necessary... However, my personal experience with several hundred spindles is that it is not needed and wide striping works as advertised. By all means, have this conversation with your 3PAR/HP technical sales engineer, or support to get specific recommendations tailored to your environment.

What is what you are referring to as "Sub-Volume Tiering"?

Sub-Volume Tiering is where you can have one LUN that is dynamically spread accross different types of disk, such as SSD, FC and SATA. It moves the high IO chunks to SSD and the low IO chunks to SATA. I don't have it, so I'm not sure how it works in relation to CPGs.

How do you control platter placement?

Found the answer to my question: Through the GUI you can edit the cpg - advanced settings gives options "fast" or "slow".

Is setting some CPGs to "fast" and some to "slow" really a good idea?

First lets assume your disks are (fairly) empty. Now create 2 VVs, one each of "fast" and "slow". So the VVs get allocated at opposite sides of the platter. You have now guaranteed that every time you want to access a "slow" VV you have to seek the disk head the full stroke distance, and then a second full stroke to get back to your "fast" VV again.

The only time I can see a net gain is when 99% of your accesses are "fast" (and you rarely ever go over to the "slow" VVs) and your "slow" VVs occupy a significant portion (data volume) of the disk so that getting them out of the way improves your short stroke seek times. But in that case, would it not make a lot more sense to have your "slow" data on NL disk anyway? Large data set that is hardly ever accessed sounds like NL to me.

rmurtagh wrote:Is setting some CPGs to "fast" and some to "slow" really a good idea?

First lets assume your disks are (fairly) empty. Now create 2 VVs, one each of "fast" and "slow". So the VVs get allocated at opposite sides of the platter. You have now guaranteed that every time you want to access a "slow" VV you have to seek the disk head the full stroke distance, and then a second full stroke to get back to your "fast" VV again.

I see your point, if I had it to do over, I would probably not use the fast/slow settings. However, since I am already down that path, and my storage is currently 65% full... I'll point out that my production chunks are consolidated to the outer tracks, and less fragmented with other tiers of data peppered within them. Hopefully "Interupt coallescing" does its job and mitigates some of that head thrashing you described.