Year of the Mainframe? Not Quite, Say Linux Grids 222
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."
"medial" tasks? (Score:1, Interesting)
Medial tasks? I think you mean menial tasks [google.com]. Although there are such things as medial equations in algebra, I believe, but I don't think you were referring to those.
I hate to go into grammar police mode, but it bugs me when people misunderstand the usage of common phrases by replacing one or more words with another. I have actually heard people say "for all intensive purposes," hahaha. (as opposed to "for all intents and purposes"). And then there are all the weird expressions we do use, that are redundant or just make no sense: hot water heater, end result, safe haven, advance warning, vin number, atm machine.
we don't need mainframes, but standalones may lack (Score:5, Interesting)
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.
Re:What are they trying to prove ? (Score:4, Interesting)
Re:What are they trying to prove ? (Score:3, Interesting)
Re:Costs (Score:3, Interesting)
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?
Re:Linux Niche (Score:2, Interesting)
Why didn't you purchase a music player/camera that handles files as it should; as a mass storage device?
Don't get me wrong, I understand your point, and even agree with it to an extent, but I have a valid point too. The root issue is really bad commercial interests combined with bad consumerism.
On the flip side, and a better example I think, I am in the process of setting up a small recording studio. I have my choice of going computer based, or dedicated console based.
If I go computer based I'm likely to use a Mac, because I can just boot it up, download Audacity, plug in an interface and start recording. With Linux, even though I have some familiarity with it, I will be facing days to weeks of just trying to find the information I need to start hacking the system into functionality; with no guarantee it will ever be fully functional the way I would like.
And I'd really rather spend that time being artisticly creative.
If I go dedicated console based you might think that my troubles were really over, just plug it in and works, but noooooooooo!
This gets back to my first point and illustrates that it isn't a Linux problem, it's a vendor problem.
The console I would be inclined to buy is a nifty little 24 track, but. .
And it's obnoxious.
My alternate choice is a 32 track (capacity I don't really need) at nearly twice the cost (I'd rather spend that money on better mics and monitors, ya know, shit that will effect the sound), but it behaves properly as a storage device and handles wav natively. Transfer files by plugging in the cable, dragging and dropping.
And for all I know deep in their little hearts they both run on top of Linux. It isn't an OS problem, it's a vendor problem.
. .
With the majority of them trying to find some sneaky way to fuck you out of a few pennies by using nonstandard this or that. I've got an idea; don't let them. Buy gear that operates properly.
And unlike my own predicament you could save money by not buying an iPod.
And then as a side effect there would be no Linux issue.
KFG
Re:What are they trying to prove ? (Score:3, Interesting)
I recently had a request to install a new type of medical irradiator (products, not people)in lieu of an older model. The new one doesn't use a radioactive source, and instead uses xray tubes. It was the cat's ass - no radiation safety officer required, no NRC hassles, and another part of he company did an ROI and the results were great. But when I looked at the specs, the cycle time was slower, it had 1/2 the capacity, and the xray tube needed replacement after a certain number of cycles, and it wasn't a cheap part.
Skeptical, I requested a copy of the "ROI". It was a 2 page narrative saying how great the new unit was, and how the staff was so much more comfortable with it. Not a dollar sign to be found. So I ran my own ROI, with the criterion being a 10 year payback. Guess what: not only didn't it have a 10 year payback, it didn't have a payback EVER. The added maintenance costs, plus the added personnel due to the slower cycle times, never ever made up for the increased licensing costs and paperwork.
And it STILL took me 2 more months to explain to the end users why I wasn't going to buy the new unit.
Actual performance numbers (Score:5, Interesting)
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).