AnsweredAssumed Answered

Why you do not use the Harting Calculation to estimate HyperPAV requirements

Question asked by Ron Hawkins Employee on Aug 5, 2013

“Harting's Calculation” was a very, very, very (did I say very) simple way of arriving at an alias value for the original PAV implementation, but it never provided a correct answer. Now with HyperPAV, 250GB and 1TB volumes it is definitely broken. I would suggest that it is the method of last resort, and that we try our best to advise customers not to use this sizing technique.

 

If a customer is going to use it, then they should know that it is not a good method for volumes over 10K Cyls in size, and will be will likely be a less than optimal value for HyperPAV. Three examples to support my position:

 

Example 1 – 3390-54 with 65,520 Cyls

This is approximately 55.68GB/volume, so the Harting Calculation says 0.25(55.68/3)=4.6. That means each LCU will have a Base/Alias ratio of 45/211.

 

Example 2 – 3390-A with 262668 Cyls

This is approximately 232.2GB/volume, so the Harting Calculation says 0.25(232.2/3)=19.4. That means each LCU will have a Base/Alias ratio of 13/243.

 

Example 3– Three Tier HDT pool

That’s 232.2GB per volume, or is it? If Harting were to be a robust methodology it would require uniform IO rates and device characteristics, something that does not usually occur with a HDT pool. With the variety of IO profiles that can be executing at SSD, HDD and Nearline speed it is far more important to look at concurrent IO rates to the IO load, rather than the storage capacity.

 

For customers that are already using HyperPAV the method I recommend to review existing HyperPAV aliases is to add the fields R783HAIU and R783HIOQ from the RMF Type 78 subtype 3 records and analyze every LCU on every LPAR to estimate the optimal required aliases.

 

R783HAIU = HWM*IN-USE*HYPERPAV*ALIASES

R783HIOQ = HWM*OF IO-S QUEUED

 

Remember that Aliases are allocated and used by z/OS, the storage simply supports them. It is really an operating system problem, so every LPAR must be analyzed uniquely. I suggest using the maximum alias value found for any LPAR as the value used for that LCU on every system.

 

For example from customer data, when I sum R783HAIU and R783HIOQ I get the following maximums for a week from four LPARS:

 

 

 


LCU
IDENTIFIER


SYSTEM
ID


the
largest
value, sum_alias_iosq


0098


SYSB


39


SYSI


2


SYSL


1


SYSM


3

 

Do not sum the four values and assign 45 aliases. To simplify maintaining HCD I suggest assigning the maximum for this LCU, 39, to each of the four LPAR. The aliases are assigned from z/OS, so with four LPARs and 39 aliases it is possible for 156 aliases to be used on this LCU, which is the maximum of 39 per LPAR.

 

There are separate hardware features that manage concurrent IO from multiple LPARS, known as Multiple Device Allegiance and Logical Device Allegiance. These do not use aliases.

 

 

Ron

 

 

 

 

Outcomes