Hi guys, hope someone can answer this question for me, i have alot of experience in storage, EMC, NETAPP for a few years, started a new Job, and 3 par is going in, i am going on training on Feb, but have some questions.
basically i dont get CPG's ?
I understand chuncklets, that makes sense, as mini-virtual disks ? what i dont understand is why you have the options to create different RAID sets, 4+1 , 6 + 2 etc. is this to set performance characteristics ?
Also i dont understand the space/sizing.
So if my array is full of 900GB SAS drives, and i create a 6+2 CPG, does that mean the CPG has a total capacity of 5.4TB ? or does this raid setting just define the performance of the CPG, and the CPG can grow to what you set the limit to ?
these questions probably sound dumb, but coming from EMC and NETAPP its very different.
many thanks
MArk
questions from a 3 Par Newbie
-
- Posts: 390
- Joined: Fri Jun 27, 2014 2:01 am
Re: questions from a 3 Par Newbie
First of all, read this document:
http://h20565.www2.hp.com/hpsc/doc/publ ... -c03606434
It's not the latest one but most of all is there.
http://h20565.www2.hp.com/hpsc/doc/publ ... -c03606434
It's not the latest one but most of all is there.
Re: questions from a 3 Par Newbie
Agree read the concepts guide.
3PAR is reservationless so there's no concept of having to create upfront constructs such as aggregates, pools or raid groups, space is really just a set of chunklets that are assembled and torn down on demand based on the policies (CPG's) you associate with a volume. As such the system will just assemble space on demand and this can be tricky if you're looking for absolutes, since depending on the CPG config, space can be allocated on demand in different ways to different volumes, so best try not to compare with EMC, Netapp or traditional raid systems
At a basic level CPG's are just a logical construct (not physical), the best way to think of them is as a policy or template that outlines how volumes associated with a given CPG should consume space as it is demanded by incoming writes. The CPG itself doesn't consume space as such, it just provides an aggregate view of the space consumed by all volumes associated with that CPG, but it's handy way to manage and monitor the layout and space consumption across multiple volumes.
Different stripe sizes are used for multiple purpose. Performance is one, as the smaller the stripe the smaller the parity calculation overhead, but this is minor unless you're really pushing the limits. Efficiency is another since the larger the stripe the less parity overhead and so the greater the space efficiency. Availability since a larger stripe size also carries a mathematically higher likely hood of an overlap failure and the variable stripe sizes allow the system to automatically guarantee things like cage level availability and to re-tune the system to best fit the changing physical layout over time.
Regardless of the number of disks you can create as many CPG's as you like since they won't consume space it's just a policy that directs how a volume will grow. Once you then create and associate a volume with that CPG say 1TB @ 6+2 then the system will create a minimal amount of logical disk space behind each controller as a buffer for incoming writes. Each of these logical disks will follow the CPG policy e.g 900GB, Fast Class, Raid 6, 6+2 meaning each logical disk will be made up of multiple independent stripes of 6 data +2 parity all glued together to form a single volume. As the volumes space is consumed over time these logical disks will automatically grow to accommodate the new data.
When you have multiple volumes associated with the same CPG they will share this underlying space, and the volumes associated with given CPG can grow to consume all available space assuming you have over provisioned that space. Typically you will have different CPG's with the associated volumes growing in different ways at differing rates since they're all thin provisioned
Parity overheads for the different stripes will be as follows.
2+1 & 4+2 = 33.3%
3+1 & 6+2 = 25%
4+1 & 8+2 = 20%
5+1 & 10+2 = 16.7%
6+1 = 14.3%
7+1 & 14+2 = 12.5%
8+1 = 11.11%
3PAR is reservationless so there's no concept of having to create upfront constructs such as aggregates, pools or raid groups, space is really just a set of chunklets that are assembled and torn down on demand based on the policies (CPG's) you associate with a volume. As such the system will just assemble space on demand and this can be tricky if you're looking for absolutes, since depending on the CPG config, space can be allocated on demand in different ways to different volumes, so best try not to compare with EMC, Netapp or traditional raid systems
At a basic level CPG's are just a logical construct (not physical), the best way to think of them is as a policy or template that outlines how volumes associated with a given CPG should consume space as it is demanded by incoming writes. The CPG itself doesn't consume space as such, it just provides an aggregate view of the space consumed by all volumes associated with that CPG, but it's handy way to manage and monitor the layout and space consumption across multiple volumes.
Different stripe sizes are used for multiple purpose. Performance is one, as the smaller the stripe the smaller the parity calculation overhead, but this is minor unless you're really pushing the limits. Efficiency is another since the larger the stripe the less parity overhead and so the greater the space efficiency. Availability since a larger stripe size also carries a mathematically higher likely hood of an overlap failure and the variable stripe sizes allow the system to automatically guarantee things like cage level availability and to re-tune the system to best fit the changing physical layout over time.
Regardless of the number of disks you can create as many CPG's as you like since they won't consume space it's just a policy that directs how a volume will grow. Once you then create and associate a volume with that CPG say 1TB @ 6+2 then the system will create a minimal amount of logical disk space behind each controller as a buffer for incoming writes. Each of these logical disks will follow the CPG policy e.g 900GB, Fast Class, Raid 6, 6+2 meaning each logical disk will be made up of multiple independent stripes of 6 data +2 parity all glued together to form a single volume. As the volumes space is consumed over time these logical disks will automatically grow to accommodate the new data.
When you have multiple volumes associated with the same CPG they will share this underlying space, and the volumes associated with given CPG can grow to consume all available space assuming you have over provisioned that space. Typically you will have different CPG's with the associated volumes growing in different ways at differing rates since they're all thin provisioned
Parity overheads for the different stripes will be as follows.
2+1 & 4+2 = 33.3%
3+1 & 6+2 = 25%
4+1 & 8+2 = 20%
5+1 & 10+2 = 16.7%
6+1 = 14.3%
7+1 & 14+2 = 12.5%
8+1 = 11.11%
Re: questions from a 3 Par Newbie
Thanks for the replies, Its starting to make sense now !!
kind regards
Mark
kind regards
Mark
-
- Posts: 71
- Joined: Tue May 27, 2014 11:23 am
Re: questions from a 3 Par Newbie
I wrote a post on this while ago that hopefully simplifies the concept: http://wp.me/p4wKu7-6g
Twitter @d8taDude
Re: questions from a 3 Par Newbie
Yep 3PARDude's article on this is great and I've also stumbled upon this one from Phil Gilbert, both do an excellent job of explaining the underlying layout.
http://www.phillgilbert.co.uk/home/storage/hp-3par-raid
http://www.phillgilbert.co.uk/home/storage/hp-3par-raid
Re: questions from a 3 Par Newbie
Think it was the sizing that was confusing me, I though the CPG would be limited to the raid group type you selected, but I can see this isn't the case. it just a container, so one CPG could in theory consume the whole array space.
regards
Mark
regards
Mark
-
- Posts: 390
- Joined: Fri Jun 27, 2014 2:01 am
Re: questions from a 3 Par Newbie
No.
A CPG is basically defined by:
- device type e.g. class disk
- raid and striping
- name ^^
- availibility
If your array only contains FC 600gb for example, then, yes, your CPG (VVs provisioned by it) would consumme whole array space.
A CPG is basically defined by:
- device type e.g. class disk
- raid and striping
- name ^^
- availibility
If your array only contains FC 600gb for example, then, yes, your CPG (VVs provisioned by it) would consumme whole array space.