Here's how the z9 109 works.
Just counting CPs/IFLs/zAAPs/ICFs -- "characterizable" engines -- you have
four hardware models up to 38-way:
2094-A08, -B18, -C28, -D38.
The A book has your two spares, then it's 10 characterizable engines per
book in B, C, and D. Fill a z9 with all four 10-way books and you've got
your 38 (40 minus the 2 spares). I'm not counting SAPs, but those are
there. Nothing disruptive yet -- add your books as you expand.
Now, how do you get to the 54-way? Well, each book has more engines, so
these "super books" are physically different. (Well, OK, maybe not
*physically* -- just more hardware onboard that passed full certification
testing. Regardless, they're functionally different. This ain't no
jumper for a CE to pull.) If you're switching from the 38-way path over
to the 54-way, it's disruptive because all four books change. There's
only one 54-way configuration: all four (highest density) books installed.
Each book has four more characterizable engines. So your A book has 12
(plus the 2 spares) and then B, C, and D each have 14. (Technically the
spares could be on any book in that configuration, I suppose, since all
-S54 units will ship with all four books installed.)
You can order an -S54 with but one engine turned on -- just one IFL, even.
This you might do if you wanted to start on the path which could take you
all the way to 54-way, but your initial needs were much smaller. (You can
forecast a fast and high capacity ramp-up.) Or if you had some rather
unusual workload (massive *and* infrequent spikes -- superbowl.com kind of
stuff) and you wanted to turn on lots of capacity for short durations.
Now, in the very unlikely event an engine fails, obviously you can operate
for a long time if need be thanks to spares and such without any impact
whatsoever. You have even more leeway if you're not bumping right up
against your physically installed limits (regardless of model). If you're
at least on a -B18 hardware model you can replace books now
nondisruptively -- and even with no performance impact in many cases.
For example, suppose you've got a -B18 hardware model and you've got 10
engines turned on (in any CP/IFL/zAAP/ICF combination). I believe what
happens is that you can turn everything on in the A book (your 8 plus 2
spares) to get your 10-way, quiesce the B book, then replace the B book.
Or vice versa (move to B, quiesce A, replace A). If you have 11 engines
turned on with a -B18, obviously you're going to have one engine less in
capacity during the book replacement. So what you do (typically) is plan
for a situation where you have to replace a book, figure out what minimum
peak capacity you'll need, and then get the "right" number of books for
your situation. In the -S54 model (all four books installed) you don't
worry about the number of books but, instead, you might worry about the
number of frames in the Sysplex. (If you have 50 engines turned on, for
example, you're going to get knocked down to "only" 40 engines if you need
to replace a book. If 40 isn't enough for your minimum peak emergency
scenario, you buy another frame.)
If you order an -A08, a book replacement is always disruptive (to the
frame). You only have one.
There are some additional nuances here concerning memory which I'm
skipping.
Regarding comments about 54-way seeming like an insane amount of
horsepower, perhaps it is. Actually, strike that -- it *is* an insane
amount of horsepower. But what was it Bill Gates said, "640K ought to be
enough for anybody"? :-) Some day, certainly in my lifetime, it'll seem
quaint. :-)
Honestly there are some customers who have hundreds of z990 engines who
will certainly appreciate the -S54 flavor of the z9, and many more
customers who will enjoy the -A08, -B18, -C28, -D38 models. (I wonder a
little bit about the -D38 model. My totally uninformed suspicion is that
the -D38 won't see many initial orders but it'll be a post-install upgrade
configuration almost exclusively.) But the other thing I want to
underscore is that, whenever IBM stretches the limits of the high-end,
everybody benefits at least indirectly. The z9 now opens up z990 (and
zAAPs) to more customers. There are now five major 64-bit models to choose
from -- and perfectly timed for the 2007 z/OS "31-bit doomsday." The
64-bit range is huge (~26 MIPS up to the moon with vast choices in
between), and you've got code compatibility across all five. ("Economic"
code compatibility is another thing. I'm thinking Java in particular
here. zAAP really is wonderful, so z890/z990/z9 do have the edge for that
sort of work. If you're on z800/z900 or getting there I'd recommend IFLs
for any substantial Java work if Linux meets your quality of service needs
-- and very often it does. But nobody is making any software that I'm
aware of that's marked "won't work on a z900 or z800," and I don't see
that happening for many years if ever.)
Regarding the SMP effect discussions, IMHO it's all rather academic
because, honestly, "It depends" (on the workload). I do know PR/SM is
awfully good at what it does, and so's z/VM, so could you have a 54-way
-S54 carved up with thousands of Linux guests in an IFL-only configuration
(for example)? Absolutely -- and you wouldn't be quibbling about the
difference between 53 and 54, either. If the 54th engine adds "only" 50%
of a full engine -- to pick something that's much worse than what I
suspect for this example workload -- so what? It's still scores more
Linux images (for example) and is still a bargain compared to racks full
of Intel servers (and associated labor and risk).
My microwave oven has 10 (100?) times more processing power than it needs
to bake a potato, but I simply don't care about how "wasteful" that is
because the embedded processor probably costs a nickel. Likewise, in its
own way and scale, mainframe MIPS and memory are falling in price very,
very quickly. (Even software is, too, thanks to some recent
business-friendlier ways of doing business.) I used to worry about bytes,
then I stopped worrying about bytes and started worrying about kilobytes,
now it's megabytes, and before long it'll be gigabytes. I don't worry if
I drop a nickel on the sidewalk -- I don't hire a hundred dollar search
party to find it.
Which is not to say that the IBM engineers don't keep finding new and
interesting ways to shove 0.1% more workload through with each individual
technical improvement. (They work in very fine grained performance areas
in many cases. They're also working on quantum entanglement to bust the
speed of light, so they think big, too.) It's also not to say that people
like us shouldn't worry about very small increments of performance. Partly
because it's about the art of being an enterprise IT professional -- and
wringing that last bit of efficiency out of the overall systems on behalf
of our grateful corporate and government masters (shareholders and
taxpayers). Partly it's because it's a good instinct to have, because
it's the difference between people who don't understand enterprise
application scalability and those that do. (The first step to
understanding enterprise application scalability issues is actually
worrying about it. Way too many people don't worry at all -- and get hurt
way too late in the development process.)
Anyway, I'm good at ranting on IBM-MAIN every so often, aren't I? Sorry
about that again. :-)
>If I understand it right, you need to have unoccupied processors in
>another books if you want to change one book. If you have 54
>processors, there are no free processors left in cage.
>Marian
>> Seems to me the likelihood of me having to worry about "non-disruptive"
book
>> replacement
>> ...
>> The announcement has a twist.
>> If you ever get to a 54-way, it's a disruptive upgrade.
>> But, it implies the others aren't.
>> I wonder why.
- - - - -
Timothy F. Sipples
Consulting Software Architect, Enterprise Transformation
IBM Americas zSeries Software
NEW Phone: +1 312 529 1612 (effective 1 September 2005)
E-Mail: [EMAIL PROTECTED] (PGP key available.)
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
