Hello all. Just became a member of the 3par family (F400). I thought I completely grasped the concept of a CPG, but my findings would say otherwise. I have a mix of FC and NL drives.
I created a CPG as FC-R5-3+1-Cage Avail-256k set size. I then went to create another CPG with the same parameters (I am using it as a folder in a sense to give different admins their own CPG). I chose the same parameters in the UI. Then I went back into the UI and it showed my Port availability. Can I not have 2 CPGs with the same raid type span the same pool of drives? Thanks.
Another CPG Question
Re: Another CPG Question
You can have many CPG sharing the same pool of drives, when it comes to cage and port avail they are about the same security according to the 3PAR People i have talked too.
Not much documentation around on the difference between them on the net
Not much documentation around on the difference between them on the net
Re: Another CPG Question
There appears to be a bug in the IMC in v4.2.1.3. It shows port availability but according to the cli, it is cage availability.
cli% showcpg -sdg
-----(MB)------
Id Name Warn Limit Grow Args
0 Windows-FC-R5-SS4 - - 8192 -t r5 -p -devtype FC
1 Windows-NL-R6-SS8 - - 8192 -t r6 -ssz 8 -p -devtype NL
2 vSphere-NL-R6-SS8 - - 8192 -t r6 -p -devtype NL
3 vSphere-FC-R5-SS4 - - 8192 -t r5 -ssz 4 -p -devtype FC
cage avail is the default but 3 of the 4 above CPGs show port avail in the UI. I am going to open a case with HP. Wish me luck.
cli% showcpg -sdg
-----(MB)------
Id Name Warn Limit Grow Args
0 Windows-FC-R5-SS4 - - 8192 -t r5 -p -devtype FC
1 Windows-NL-R6-SS8 - - 8192 -t r6 -ssz 8 -p -devtype NL
2 vSphere-NL-R6-SS8 - - 8192 -t r6 -p -devtype NL
3 vSphere-FC-R5-SS4 - - 8192 -t r5 -ssz 4 -p -devtype FC
cage avail is the default but 3 of the 4 above CPGs show port avail in the UI. I am going to open a case with HP. Wish me luck.
Re: Another CPG Question
Hello
If you refer to the release notes, there are some known issues with the IMC.
In case of differences between the IMC and the CLI, the CLI version is always the correct one.
You can try to logout then login again from the IMC.
If you refer to the release notes, there are some known issues with the IMC.
In case of differences between the IMC and the CLI, the CLI version is always the correct one.
You can try to logout then login again from the IMC.
Re: Another CPG Question
I opened a case with HP about this one. After 2 weeks, I got the reply. See below:
Sorry for the delay. I had really to dig a lot and consult many people to get an answer to your question.
There is some History behind ïŠ First generations of InServ where using DC-1 cages. These were daisy chained. So each cage was connected to the next one in a chain. At the time, the most serious concern wasn’t to lose a cage, but a port. Losing a port could break a daisy chain and therefore it was considered as even worse than losing a single cage. So at the time, another availability concept for CPGs was introduced: Port Availability. Which literally means: You can afford to break a daisy chain and your CPG will be still available.
For DC1 cages, Port Availability is even better than cage availability.
Today, with DC-3 and DC-4 cages, no daisy chaining is involved. Every cage has 2 individual connections to 2 different nodes working in pairs. We don’t connect cages to each other anymore.
So for your InServ, cage availability is the same thing as port availability even if in the InForm OS perspective port availability is considered “higher†than cage availability.
For recent F InServs, cage availability is always displayed as port availability. Because the system senses that port availability is affordable and switch to that mode.
So what you see in the IMC is normal and there is no issue with the InServ nor with the presentation. The port/cage display in an artifact which can be explained by historical background.
Sorry for the delay. I had really to dig a lot and consult many people to get an answer to your question.
There is some History behind ïŠ First generations of InServ where using DC-1 cages. These were daisy chained. So each cage was connected to the next one in a chain. At the time, the most serious concern wasn’t to lose a cage, but a port. Losing a port could break a daisy chain and therefore it was considered as even worse than losing a single cage. So at the time, another availability concept for CPGs was introduced: Port Availability. Which literally means: You can afford to break a daisy chain and your CPG will be still available.
For DC1 cages, Port Availability is even better than cage availability.
Today, with DC-3 and DC-4 cages, no daisy chaining is involved. Every cage has 2 individual connections to 2 different nodes working in pairs. We don’t connect cages to each other anymore.
So for your InServ, cage availability is the same thing as port availability even if in the InForm OS perspective port availability is considered “higher†than cage availability.
For recent F InServs, cage availability is always displayed as port availability. Because the system senses that port availability is affordable and switch to that mode.
So what you see in the IMC is normal and there is no issue with the InServ nor with the presentation. The port/cage display in an artifact which can be explained by historical background.
- Richard Siemers
- Site Admin
- Posts: 1333
- Joined: Tue Aug 18, 2009 10:35 pm
- Location: Dallas, Texas
Re: Another CPG Question
Sorry I didn't get to this sooner...
I've noticed that too. Also you can do a showld from the command line, it will show you both the "Avail" which is what you set it to, and the "CAvail" which is what its currently running at.
I have some tiers of storage set to MAG and just by the luck of things, they are actually running at port avail.
I've noticed that too. Also you can do a showld from the command line, it will show you both the "Avail" which is what you set it to, and the "CAvail" which is what its currently running at.
I have some tiers of storage set to MAG and just by the luck of things, they are actually running at port avail.
Richard Siemers
The views and opinions expressed are my own and do not necessarily reflect those of my employer.
The views and opinions expressed are my own and do not necessarily reflect those of my employer.