This post is about whether to run coupling facility (CF) LPARs using general purpose processors (GCPs).
It might be in the category of “you can but do you think you should?”
I’d like to tackle this from three angles:
And the reason I’m writing about this now is the usual one: Recent customer experiences and questions.
What kind of performance do you need? This is a serious question; “Quam celerrime” is not necessarily the answer. 🙂
A recent customer engagement saw CF structure service times of around 1500μs. This is alarming because I’m used to seeing them in the range 3-100μs. This does, of course, depend on a number of factors. And this was observed from SMF 74 subtype 4 data.
You might be surprised to know I thought this was OK. The reason is that the request rate is extraordinarily low.
So what’s wrong with the inherent performance of CF LPARs in the GCP Pool? Nothing – so long as they are using dedicated engines, or at any rate not getting delayed while other LPARs are using the GCP engines.
But see Economics below.
So just like running on shared CF engines, really.
So the customer with the 1500μs service time was using a CF LPAR in the GCP pool capped with a very low weight. So, basically starved of CPU.
It turns out that the request rate being very low means the applications aren’t seeing delays and there is no discernible effect on the coupled z/OS systems. And that’s what really counts.
By the way, the word is “resilience”. (Even the phone I’m writing this on says so.) I’m having to get used to people saying “resiliency” (which my phone is accepting of but not volunteering).
Having the CF LPARs in the same machine as the coupled z/OS LPAR has resilience considerations. Lose the machine and you have recovery issues.
Note the previous paragraph doesn’t mention processor pools. That was deliberate; it doesn’t matter which pool the CF LPAR processors are in, from the resilience point of view.
The significant question is one of economics: If you’re running on GCP pool engines these, of course, cost more than ICFs.
For modern pricing schemes I don’t think CF LPARs in the GCP pool cost anything in terms of IBM software. But there might well be software pricing schemes where they do.
And then there’s the question of maintenance.
All in all, the economics of placing a CF LPAR in the GCP pool will depend on spare capacity.
Yes you can, and just maybe you should. But only if the performance and economic characteristics are good enough. They might well be.
And you’ll see I’ve deliberately couched this in terms of “this is little different from any Shared CF engine situation”. The main difference being the economics.
One final point: if you need to have a CF LPAR and you’re on sufficiently old hardware you might have little choice but to squeeze it into a GCP pool. But do it with your eyes open. Unless you’d like to consider the benefits of a z16 A02 or z15 T02 – eg for production Sysplex designs .
One thought on “CF LPARs In The GCP Pool?”
Around 2003, I was in a shop where a just-installed standalone coupling facility was getting terrible response time as evidenced by the figures displayed in RMF Monitor 3. It turned out that IBM had misconfigured the CF to only have one CPU enabled. Only one synchronous I/O could occur at a time and asynchronous I/Os had to wait in line. The fix was easy -enable more CPUS. but embarrassing to IBM.