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."
As an admittedly non-initiate in linux (I run osx), this seems very much what linux is
good for, rather than for a desktop os, where difficulty of setup would be a severe
handicap. I've always believed that open-source suffers from the in-house-tool
mentality, which assumes the end user is extremely sophistacted. As an engineer,
I can testify to my lack of desire to make the UI more than bare-bones.
Maxim
While it is quite possible they meant 'menial', as that is the common phrase, they might also have meant just what they said.
http://dictionary.reference.com/search?q=medial
2. pertaining to a mean or average; average.
The Grid is used for complex, processor-intensive tasks, I'm sure. The regular daily cruft is probably still done on the old mainframe. Those would be 'medial tasks'. If they made it into a monitor instead of a system that does processing, that might be considered menial. (I'm having a hard time finding 'menial' tasks a computer can do...)
http://dictionary.reference.com/search?q=menial
1. lowly and sometimes degrading: menial work.
Sooo... If you're going to be grammar police, please do your homework first.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
'I'm gonna get medial on your ass' said the mainframe.
I'm an idiot, with my entire college time spent doing statistics, I should have sorted the numbers into order before picking the middle one.
HOWEVER point remains!
The mainframe is many years old and they only managed to beat it by up to 70% with 120 machines? Either that thing is awesome or they suck with their grid.
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.
the consulting group or whomwever spun up the new project wanted a paticular result so they aimed for it.
Most likely they didn't know how to program the mainframe to get the results they wanted but they did know how to use the solution they came up with
or
they knew how to do the mainframe side to the fullest potential of the machine but that wasn't cool enough so they redefined what good results were.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
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.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
It sounds like a Linux grid is an excellent solution here - however, it also sounds like their software is not exactly performing perfectly:
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
Really?
Frankly that sounds like the software is in severe need of reworking! If their machines are 20 years old that's bad enough, but if they have 20 year-old software that needs to be rewritten every time a new type of car is added, it's time for a redesign.
Ok, I say pasghetti, but only because it is fun.
I often have trouble remembering which way is out of bed in the morning.
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.
How easy is it to install Photoshop on Linux? MS Office? iTunes? Logic? Vienna Symphonic Instruments?
Okay, so if I don't want to use the most popular online music store, never google for a tutorial on how to accomplish ___ with my graphics tools, don't like books, and don't need to exchange files with people who work for a living, there's always GIMP, OO and some programmerware media app I could use, and why would I want to compose music for orchestra on my computer?
Aw come on. Isn't this really all a mute point?
Interested in open source engine management for your Subaru?
It sounds to me like a mainframe is still probably the best fit for this organization. Few solutions can match the efficiency, streamlined-goodness of an IBM mainframe. Where I work, a city government, we run two fairly beefy iSeries (AS/400s), one that runs accounting, utility billing and operation, and income tax operations, and another that runs public safety operations. I love them. No down time - ours are brought down about once a year, and usually that is because the power is out and our generators are about to run out of juice. Hands down the most stress-free aspect of our operation. That alone is worth something. The users also love it for the most part. While IBM's client access can be intimidating for most users at first (text!?!? what is this, the 70's?), once they adjust to it they tend to love how quickly one can skate through repetitive tasks. Nevertheless, it is not for everyone. If you don't have tons of data that needs to be reliably and efficiently accessed all day everyday, then you're probably better off going elsewhere. If anything, because most users, who can barely log in to windows reliably, find client access to be something of a magic black box that they cannot begin to comprehend (my favorite help desk call: "can you flip the magic switch for me?"). At the same time, I've seen the same users who can still barely operate a mouse, open a AS/400 session and go to town like a computer virtuoso. I guess what I'm trying to say is, IBM mainframe solutions definitely have their ups and downs, but for the right applications, they are irreplaceable.
"In God we trust, all others we monitor." -- Unofficial NSA motto
[i]It would be intresting to see exactly what the cost to implement a new lameframe system with equivalent performance would cost. ANybody got some rough numbers?[/i]
That's kind of like asking "how much would a brand new 386 system cost to replace this old 386?".
According to my mainframe hardware charts, my company still has a 2066, which we use for an extremely low-volume business unit. The 2066-02 is pushing 10 years old, uses a 2 engine CPU complex (think SMP), and has a processing power rating of ~77 MIPS. For comparison, our standard box is a 2084 with an 8 engine complex, and a power rating of ~1600 MIPS.
Think of it this way; if someone told you they'd replaced a 386 with a handful of Palm pilots, would you really be impressed?
- Despite popular opinion, I am not perfect.
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).
- Despite popular opinion, I am not perfect.
- 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.
Comparing a Linux grid system with a mainframe is comparing apples and oranges. The mainframe's strength has never been raw computing power. Mainframes have practically zero downtime and massive I/O capabilities. If you can swap a Linux array in for a mainframe and have results this good, you were using the mainframe for a task to which it wasn't suited to begin with.
"The problem with internet quotations is that many are not genuine" -Abraham Lincoln
I know Grid is the buzzword of the day, but this isn't a grid. It's a cluster, or perhaps a beowulf, but it is not a grid. Buying a bunch of identical boxes and installing identical software on them doesn't make a grid.
One of the key features of a grid is that it "coordinates features that are not subject to centralized control". (What Is The Grid, Ian Foster, ANL). Grids by definition cross organizational or management boundaries. You can't buy a grid any more than you can buy an Internet. You can buy a network. You can buy a cluster. You can't buy a grid.