Slashdot Mirror
Year of the Mainframe? Not Quite, Say Linux Grids
OSS_ilation writes "IBM touted 2006 as a resurgence year for the mainframe, but not so fast. At R.L. Polk and Co., one of the oldest automobile analytics firms in the U.S., an aging mainframe couldn't cut it, so the IT staff looked elsewhere. Their search led to a grid computing environment — more specifically, a grid computing environment running Linux on more than 120 Dell servers. The mainframe's still there, apparently, but after an internal comparison showed the Linux grid outperforming the mainframe by 70% with a 65% reduction in hardware costs, Polk seemed content banishing the big box to a dark, lonely corner for more medial tasks."
You use the mainframe when you want error recovery at every step of the way. One of them even runs two CPU pipelines in lockstep so that a failing CPU can be safely isolated without crashing the app that was running on it.
The mainframe also gives you nice IO and super-efficient virtualization.
Workload doesn't need all that? Gee, maybe it's not a workload for the mainframe.
a 2066-002 is midway up the 'Baby Freeway' z800 mainframe line. It has 2 CP's and benchmarks 1.0-1.2x the performance of a 9672-R36 itself a 4-5 year old model in the middle of the pack.
Besides, performance has never been the strong point of a mainframe. In fact most mainframes performance is laughable (a while ago IBM had to ask Seti@Home to remove the results for the early Z series because they were comparable with a 386SX. The primary selling points of a mainframe are the resource control and reliability.
Does the grid mentioned in the article offer the same level of PHB friendly resource control (CPU, IO, etc) for multiple concurrently running applications? Doubt it.
Does the grid mentioned in the article offer the same level of reliability and reproducibility of the result? I have some doubts. Most mainframes have 2+ CPUs doing the same task and either flagging a fault on differences or deciding who is right using a "voting" system. This is done on a per instruction basis and cannot be directly simulated in a grid. At best you can do per-task/procedure result comparison which is not the same as it will flag errors considerably later and has higher probability of overall error when using the same number of components.
Someone is either comparing apples and oranges, or being a fanboy or not knowing what mainframe is for or all of these at the same time.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
I just recently installed Ubuntu (Edgy Eft) on a brand new laptop. I found no previous testimonials or guides about the model I chose, but googling seemed to indicate that all the components had drivers. While I did have a couple of issues that made installation not quite as painless and grandparent, your post severely understates how far Linux has gotten.
And then you want to get your sound working on your newer laptop?
Worked with ALSA out of the box.
Okay, where do I set the wireless password? I know I saw that somewhere before.
Using Network Manager, there is a wireless icon in the top right of the window with a list of accessible networks. Selecting an encrypted one brings up a prompt for a password (the first time you use it).
Oh, the Dlink-chip-du-jour isn't supported out of the box, I have to go find some more development drivers for it, if I can.
Unfortunately, some hardware manufacturers give no Linux support at all, but in fact almost all wireless adapters work. Go with Centrino, and you will be fine.
Hmmmm, how do I suspend this and hibernate it properly?
Both worked perfectly out of the box.
Hmmm, where did my scrolling regions go on my trackpad?
They were enabled and working out of the box.
Now, time for a presentation; install openoffice, that works fine, good. Okay, now to switch to external monitor. Hmmm, Fn-Monitor doesn't work.
The hotkey for switching to external monitor worked out of the box, with all three modes (internal, external, both) working.
To this I can add (in response to others) that both my iPod and my Camera worked straight out of the box, as did Internet access over my bluetooth phone. The only thing I have run into which didn't work was an HP scanner - it turns out that scanners are a real quagmire with no uniform drivers and that HP give lousy support, a little Googling told me this and that an Epson would have worked...
Not only is it an apples and oranges comparison between an old mainframe and a new custom-built grid, but the software was completely different.
According to this the original software was probably poorly designed:
> the mainframe took on the persona of a lumbering behemoth. This was especially the case when the IT staff had to accommodate new
> business requirements such as a car dealership adding a new type of vehicle to its inventory. Each update required a
> major rework of the program
Hmmm, massive software reworks to handle new vehicles types? Yikes.
And who knows what the author of the article meant by this:
> Isiminger said his IT staff moved from the mainframe to a grid using high-performance code developed in Assembler and PL/1,
> business logic in COBOL, proprietary mainframe development tools, flat file processing, VSAM and some IMS.
Most of the above actually sounds like what would be running on the mainframe.
In any event, it sounds like the your typical scenario - the data requirements grew wildly beyond what was originally envisioned and designed for. The new solution (both hardware and software) were designed for a far larger amount of data.
The more interesting question now is how well would a new mainframe compare?
- initial cost: mainframes can be hand for as little as $100k, and may cost less than 50 dual-cpu dell servers
- labor cost: one mainframe is most likely cheaper to support than 50 servers - especially when you consider requirement for absolute consistency between the 50
- adaptability: the grid has some benefits here with easy additions and subtractions from the gird - but grid performance relies upon problems that can be easily partitioned. The mainframe has extremely mature virtualization - easily allowing new lpars (separate hosts) to be created and managed without so much of the overhead of pc based virtualization products.
- There's no central control over resources.
- System uses open standards.
- System provides non-trivial quality of service.
Here, at least the first point is not fulfilled. So yes, they've built a cluster. A cluster like hundreds of others, used since the early 90s. It's 2007, isn't it? I'm impressed!It really depends on what your workload is and what you are trying to accomplish. I've seen Linux on the mainframe be a horrible thing and I've seen it be a pretty cool thing that worked wonderfully. If you are trying to do heavy math processing on a mainframe then it probably won't get you the bang for your money. On the other hand, heavy IO will probably work very well. You also get the benefit of being able to run hundreds (or even thousands) of Linux guests on one single server. That conserves physical space, electricity, software license costs, and the hardware is extremely reliable (which is part of the reason it is so expensive). It also makes disaster recovery much more straight forward.
Even IBM will tell you that there are some applications that you should not run on a zSeries processor. I've been in meetings where IBM has said that some types of workload will not perform well on a zSeries processor and you should consider Intel or some other platform.
There is no "one size fits all". Anyone who says there is "one size" is probably selling something.
The caveat to this system is that it would need some pretty heavy networking, even if optimised, and there could be latency issues. Still, I like this idea better than a mainframe.
And this caveat kills the deal. The problem has always been that networks simply can't compete with the throughput of native devices. Consider this:
Yeah, a multiframe is a nice idea, but it just doesn't work for the IO intensive workloads of business.
And the interesting thing is that it will always be this way. The maximum throughput of a bus is inversely related to the length of the conduit. The internal busses of computers, whose max length is typically measured in centimeters, and typically have 16,32, or 64 data lines, will always be able to outperform the network type busses. For example, USB has one "data line". Ethernet has 4. EIDE has 16, and PCI 32. It comes down to a simple matter of math and physics, and no amount of technological progress will change this.
The society for a thought-free internet welcomes you.