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."

Comments

Re:Linux Niche

[Alioth]

The difficulty of desktop Linux is really a myth these days. I recently set up Fedora Core 6 on a laptop. Setting up FC6 as a desktop is now trivially easy. It roughly consisted of inserting a CD-ROM, booting it, clicking OK and Next a few times then feeding it disks until it finished.

Installing extra software was equally trivial. There is a GUI to start off the Applications menu for installing more software. It downloads and installs the software all as one step. No need to download it, run a separate installer or scroll through pages of impeneterable EULA.

To add extra applications to this GUI application installer - mainly multimedia applications - all it required was clicking on a link on Livna's web page to add the Livna repository. (Like Mac OS X, you're asked for the administrative password on application install).

Installing Fedora Core and extra applications and extra application repositories is actaully easier than doing the same on Windows, and about the equivalent difficulty of doing the same on Mac OS X.

For third-party applications, there is Autopackage: http://autopackage.org/ - which provides a distro-independent method of installing applications. It's reminiscent of things like the Mac OS X application installer (for apps you can't simply drag to the Applications folder) or the InstallShield types of installers for Windows. Except unlike InstallShield installers, it has the ability to resolve and fetch dependencies (ever tried to install Microsoft BizTalk? Complex and unweildy because you must manually install several dependencies, each with their own dependencies. Autopackage does away with this dependency hell).

What are they trying to prove ?

[Ksempac]

So a NEW system outperforms an OLD system. I fail to see how this is a news.

If they had compared a NEW mainframe with the NEW grid, then we would have been able to draw some conclusions about which one is better. But saying "We bought a new system, its better than the old one" proves nothing.

Re:What are they trying to prove ?

[Archtech]

Yes, you have put your finger on the glaring weakness in this story. Once you see that it was an OLD mainframe versus a PRESENT-DAY Linux grid, you realise that no useful conclusions can be drawn. (Although, as others have noted, the narrowness of the margin achieved suggests that the mainframe would win easily in a fair contest).

These "old-versus-new" comparisons are the stock-in-trade of marketing and PR departments, which are perpetually issuing press releases bragging that the latest Foowhatzit Humdinger 24-processor with thousands of GB of storage outperformed someone's 10-year old VAX or AS/400. To Slashdotters, that's a subdued "Wow!" (that they would attempt such barefaced trickery, that is) and on to something potentially interesting. But to the broad masses who know nothing about computers, it is quite impressive. PHB readers habitually skip over all the "techie details" anyway, so they probably come away with the desired message: "We need Foowhatzit Humdingers, and we need 'em now!"

People with arts degrees are big on quoting Mies van der Rohe's "God is in the details". Perhaps it's time they realised that "God is in the numbers" too.

right tool for right job

[r00t]

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.

Re:right tool for right job

[mwvdlee]

You are thinking of the old Tandem machines, I think they're called Himalaya now, or whatever. Those are failsafe machines which are supposed to have zero downtime on hardware problems.

The Mainframe discussed in the topic is an IBM one, most likely a predecessor of the current zSeries machines (OS/390).

So Linux beat it. I guess they just had tasks which weren't fit for large scale processing behemoths like mainframes anyway. I dare bet the Linux grid would be a lot slower if it had to batch processes a few hundred MB worth of data. And despite all the claims about Linux stability, mainframes boast far superious uptime (a few minutes of scheduled downtime a year and no unscheduled downtime; everything can be hotswapped, including CPU's and memory). Although the increase of real-time processing decreases the need for mainframes a bit, the ever increasing processing load still makes them invaluable to large companies.

we don't need mainframes, but standalones may lack

[jimstapleton]

what we need is "multiframes"

Consider an virual operating system, that can run on one or more other operating systems. This operating system is actually a set of nodes, one node per machine (or one node per CPU), with command nodes and worker nodes.

Command nodes distribute the workload and exist for redundancy. If one goes down, all others have a backup of it's data and state, and the next most senior node takes over.

Worker nodes then take the tasks and interface with the users via a standard shell.

Files can be distributed amongst the nodes for speed and redundancy, and if a node that needs a file doesn't have it, ant can request the file and temporarily have it locally. Each node will have a list of what files exist, and where they exist.

UI tasks are written to run solely on the machine of the user, but data crunching tasks are written to be split between nodes.

Thus, a person just goes to his or her machine, and interacts with it like a normal machine, except, rather than having a logon for his machine, he or she will have a logon for the multiframe.

Also, because of this setup, a multifram could work on top of multiple operating systems (say an office that is 50% windows for the normal users, and then 35% Linux for the devs, 10% FreeBSD for other devs, 5% HPUX/Sun for some server, and all machines coudl contribute to the multiframe.

The multifram could also have recorded statistics of uptimes and drops for various nodes, performance statistics for load balancing, etc.

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.

Year of the Mainframe?

[dbneeley]

As others have pointed out, the comment left a great deal out.

For example, any mainframe that can be replaced by 120 PC compute nodes isn't well utilized and/or is completely outmoded.

I had a chat with a gentleman once who participated in a replacement of multiple PC servers with a mainframe--but it entailed replacing 7,000 servers with a relatively high-end machine.

The result was that power and real estate savings alone paid for the mainframe--which had more capacity for future expansion as needed.

As always, proper implementation of the right equipment for the job is always crucial--and a shallow analysis that doesn't cover all the variables is simply misleading at best.

Re:"medial" tasks?

[bconway]

Aw come on. Isn't this really all a mute point?

Actual performance numbers

[spookymonster]

We still have a 2066 in our shop. According to my power charts, the 2066 rates approximately 77 MIPS. If the Dells are giving a 70% performance increase, that means roughly 130 MIPS, or 1.1 MIPS per server.

In comparison, our standard model mainframe (a 2084) kicks up about 1600 MPS. Assuming the performance numbers for the Dell grid were to scale (the safe money says it doesn't), that translates into almost 1450 Dells. Keep in mind, that's not even a top of the line mainframe...

Let's not even start on hardware maintenance (which would you rather do: hot swap a power supply on 1 system, or 25?), network overhead, shared DASD, coupling facilities and RRS (think: Beowulf clusters).