Slashdot Mirror
Experiences of Running Linux on a Mainframe
xneilj writes, "Linuxplanet has an interesting article where a guy decided to install the native Linux on the company mainframe in their lunch hour. Interesting article if you're wondering why anybody would pay seven figures for a box when you can get a high-end pc machine for a fraction of that. Author Scott Courtney reckons if you put Linux on it 'the mainframe of today may in fact be the best damned Web server you ever saw.' "
Anyone ever hear of a 390 getting jacked? I didn't think so.
Read the whole article, or read it again. On S/390, Linux is a tool that runs in a partition under the native OS. The article isn't advocating ditching VM, he's talking about adding Linux to the S/390's toolset. Need a webserver, DNS, etc? Set up a partition, allocate DASD, copy a new Linux image over, set it up.
As the article states, $400 a seat for mainframe power and reliability is pretty cheap, and you're soon going to see IBM offering end-to-end Linux server solutions, featuring S/390, RS/6000s, PC Servers, and probably AS/400 in the near future (I know there's a third-party port in the works, but IBM will probably beat them to market). IBM shops will be able to come close to Write Once, Run Everywhere, and in the case of S/390, on a machine that almost never falls down and can handle an insane volume of I/O. Don't think that won't appeal to the bean-counters.
slashdot broke my sig
Where the mainframe excels is in its I/O channel. You can, for example, move gigabytes of data from one disk to another (or from disk to tape, or whatever) generating only one CPU interrupt. The channel is intelligent enough to do this kind of thing. That's why people tend to be surprised when they find out that the mainframe that just moved a few hundred million records around without breaking a sweat only has 64 MB of memory and a not-so-hot CPU.
Getting Linux onto the mainframe is a very important step, but it's only part of the picture. Facilities then need to be introduced to take advantage of the advanced I/O facilities that are available.
The Intel-PC world's attempt to imitate a mainframe's channel is Intelligent Input/Output (I2O). It does something similar, with intelligent peripherals designed to take the processing load off the main CPU. Mainframes have had this for decades. The Commodore 64 did, as well (I believe the article touched on this, actually). Now the PC world is finally catching up.
Alan Cox is working on getting I2O support worked into the Linux kernel. If the kernel interfaces for I2O are done with a sufficient level of abstraction, it is entirely possible that IBM could adapt them to use on an S/390 box as well.
--
Tired of FB/Google censorship? Visit UNCENSORED!
KwsNI dun said:
Actually, a Beowulf cluster probably wouldn't be the right tool for the job there (it'd be rather akin to using a butter-knife to tighten a flathead slotted screw--it'd work, but there are better tools for the job).
Beowulfs are very good if you need to do processing that can be done very well in parallel such as some formulas. They do not do so well if you a) have to do a lot of parallel work quickly (for that, a supercomputer like a Cray is probably better suited) or b) especially if you have to move and/or work with a massive amount of data (which is what mainframes are used for mostly and which is a job they do very well).
Besides, the entire purpose of Linux on mainframe boxen isn't to link a mess of S/390s into a Beowulf cluster (which, while it would make a very large box, it would be slower than a comparable Cray or even SGI Challenge series). The major purpose of porting Linux to a virtual machine S/390 is twofold--for "bare metal" runs it's basically an alternative to AIX (which, while reliable, is a horrid bastard child of *nix and the entire IBM REXX mess--for a fair amount of stuff which compiles "out of the box" on most *nixes, you have to add REXX scripts in AIX), while the port for "virtual machines" in S/390 (the one largely concentrated on in the article, by the way) is meant largely as a more user-friendly (at least to us folks used to *nixes and OS's invented in the last 25 years or so) alternative to the traditional IBM VM OS's (most notably MVS, VM/CMS, and VM/ESA--I've had experience with VM/CMS, by the way, and trust me when I say that *nix is far friendlier ;) that can also be used to add capabilities that have not existed for IBM/Amdahl "Big Iron" so far (like X-terms--other than VAXen and a few abortive NT ports, there isn't such an animal as a GUI for mainframes--it's all CLI terminals; also, stuff like PPP accounts can be set up (good for unis that may still have some old 3090 VM/CMS boxen about--IBM isn't officially supporting most OS's for the 3090s anymore, VM/CMS has a real dearth of Internet apps, and the daemons that DO exist do have some serious security flaws [most notably IBM VM SMTP--which can be anonymously relay-raped in its default install--and the default mail client which had serious problems in the early 80s with worms being transmitted]) and whatnot).
FWIW--there are a lot of places still using Big Iron, and not necessarily because they have a ton of legacy Fortran or COBOL (yuck) code that has been around since 1965. :) Insurance companies and banks, for example, commonly still use Big Iron because, well, Big Iron is about the only thing that won't choke on the massive amounts of data it must deal with reliably on a regular basis. (Supercomputers might be able to deal with it, but storage is iffy, supercomputers tend to be more temperamental than most Big Iron, and the amount of supercomputer needed tends to be quite a bit more than the average amount of Big Iron costs. Beowulfs are good for small- to medium-sized applications, but would barf on the amount of info needed and/or the nodes required (there is a limit to how many boxen may be linked in a Beowulf cluster; part of this is due to transmission speeds, but part of it is due to limitations of the Beowulf code itself); also, Beowulf clusters can fall down go boom if one node falls down goes boom.)
To give an example of, say, the average group that might use and NEED Big Iron--how about the US Census Bureau. They have to put in something around 250-270 million records in their databases every ten years; in addition to that, they have to keep databases (for comparison and updates, as well as to tabulate trends across decades) of anywhere from 100 million-250 million records--one for nearly every person in the country.
Yes, this is actually stored by computer--I happen to live nearish one of the four big processing centres for the Census Bureau in the US. They basically input everything on terminals from the census forms, thousands of people do...which are ultimately stored on Big Iron and on media totalling anywhere from terabytes to possibly even exabytes of data.
Damn near everything SHORT of a Really Huge Big Iron system is going to choke, hard, on this amount of info. (Especially so when you consider that a fair amount of older data is probably stored on tape or removable big-platter hard disks--usually using legacy storage systems which may not even be commercially sold anymore--which are being converted to more modern storage media capable of handling terabytes of data at a time.) I like Linux as much as anyone (and freely admit to being a Slackware and SuSE bigot ;) but a Beowulf cluster just isn't going to handle that. Not even if you built it from Alphas. Not even if you built it from bloody Playstation 2s. :)
You mentioned the IRS--well, they've got comparable storage and data handling requirements as the Census Bureau does, only worse. :) They have to maintain upwards of 100 million records which must be entered and updated yearly (just from people who fill out tax returns)...plus records from W2 forms filled out by employers of the folks associated with those 100 records...plus trends must be done on ALL these records, and previously archived records which may stretch back as far as 30-35 years or so (again, often on legacy systems and data--good old removable disk packs and 9-track tapes) in order to flag folks (who might be remiss on paying their taxes) for audits...we're talking literally hundreds of terabytes or MORE of data that the IRS must go through on a yearly basis! It's actually kind of impressive that their systems don't barf more than they do when one thinks of the sheer amounts of data they go through...
-Windigo The Feral (NYAR!)
A mainframe is NOT a thing of the past !!! What do
...
you think manages your bank account, possibly your
salary, certainly your IRS account and probably
your pension fund ??? Mainframes, that's what.
Most of the concepts that we enjoy in Linux: high
reliability, scalability, etc..., have been present on mainframes for **ages**. I am not
flaming, but you have to give each one its due
What really sets these machines apart (in my personal experience since more than 25 years)
are two things: reliability, and high throughput.
These machines were designed from the ground up
to serve **hundreds** (sometimes thousands)
of simultaneous **active** users. You have the
hardware facilities to serve literally thousands
of concurrent I/Os (this explains the price,
of course).
Now about linux: I think that's a good move on
IBM's part (who sponsored the port): as I see it,
their long-range view would be: one OS (and one
set of applications tailored to this OS) on every
possible hardware platform. Then application ports
would truly be re-compilations only, which profits
IBM too (as software developer, and also in the
support department)...
If D. Miller could port Linux to high-end Sun machines with 15 processors, why not on IBM mainframe ?
I assure you that I did read the article in its entirety(sp?) before responding
/.er) that you should take into account proper security (rooms/locks/guards?/fire control/waterproofing/etc.) into account when spending the money to purchase a six-figure piece of equipment. I mean, that's just common sense (that I learned from the Gospel according to O'Reilly). I can't see the difference from losing one machine in a building due to fire/flood to losing 20 machines in a building for the same reason.
Then I apologize for accusing you with ignorance.
What good is a hot swap box if the box is flooded (water) / destroyed by fire / millitant admin with an axe, etc
A point was brought up (either by the author OR a
I would imagine delivery on a shiny new mainframe wouldn't be a next day thing
Depends. I don't have enough information about purchasing mainframes to know if IBM would toss out another expensive mainframe while the insurance claims/warranty/guarantee/etc claims get tossed around. But, I would hope that IBM would send one as soon as economically feasible.
With commodity hardware I can (at worst) steal my home machine, buy a dozen more at your local outlet and be back up and running from backups in a matter of hours.
You're kidding, right? Boy, I must be configuring something wrong; when I rebuild a system, it generally takes me a very long time to rebuild one system from backups, much less multiple systems. Of course, I am no system administrator. But truly, I think your estimate about rebuilding a network is too optimistic. Maybe you mean "kludging together something with baling twine, duct tape, and spit, until I have enough time to rebuild it properly".
I would certainly not want my router / firewall / X term / webserver / database in one box
Oops, I didn't mean it *that* way. Of course, you want all your servers and routers on seperate machines, due to redundancy, the KISS principle and security reasons. But with multiple OSes running on multiple distinct and unconnected partitions, running completely independant, but on the same hardware, that's just ideal. One instance of Linux/FreeBSD for a router, one for Apache, one for SAMBA, etc, with the same security risks as having them on seperate boxen.
But for most cases, the sheer co$t of this compared to a standard cluster and frontend/backend solution must also be addressed
Agreed, you would need to replace a lot of machines to make this a money saving, but:
1) A lot of companies have a lot of machines. Enough to make this profitable? Would the profit margin hit at 20 servers, with 200 low-end workstations? 50 servers, with 1000 LEWSs? I knew a few mid-range Canadian businesses that have the 20/200 setup.
2) Pure bragging rights. Lousy reason, sure. Something that should be taken into account. You betcha.
3) Politics. Multiply reasons in 2) by a factor of ten for reasons.
Financially, I would very much like to see the math to see where the break even line is. I smell an "Ask Slashdot" question, can you?
If anything, Tzanger, you made me think, which is more than I can accuse most of the people I have talked to today. Thanks!
"Don't mind me cutting myself on Occam's Razor"
I disagree with most of your ports. Some of the ideas of author of the Linux/Mainframe article (if you would have read the article) are very valid. It would be near perfection having a single piece of hardware, properly partitioned, to become your router, your DNS server, multiple and independant but linked web/ftp servers, file servers, X11 servers, print servers, and then having a couple partitions for actual user processes; all of which on a piece of hardware that is 100% hot swappable, and can have a partition rebuilt in less than a minute. And with the massive I/O of a mainframe, to boot.
Next time, read the article. Trust me, you will be a better person for it.
"Don't mind me cutting myself on Occam's Razor"
Although I've read articles in the past that have noted IBM running linux on the 370, I liked this more detailed article.
It should be noted that a Mainframe has huge ammounts of I/O bandwidth. I've seen five year old mainframes put new as/400's to shame. By all rights the 400 has more processing power, but the mainframe has such huge ammounts of bandwidth that it can move the information around quicker. When you think of a web server you realize that the actual program isn't all that complicated. Most of the CPU time is dedicated to feeding I/O out to the TCP stack. A mainframe may not be as powerful as the as/400 or a new Xeon, but it has a lot of smaller processors, and they aren't wasting cycles waiting for I/O to give them something to crunch.
Also you could have multiple high speed printers I really can't believe that you need a mainframe to increase something that is on the device end like a printer.
And here is where you betray your ignorance of things mainframe. Mainframe devices are much faster than similir devices in the PC world. A mainframe printer connects like a network device does and utilizes huge transfer rates. Mainframes are built for IO. IO from tapes, to tapes, to printers. Mainframes exist for IO.
Beowulf clusters are built for parallel processes -- think solving intractable differential equations through simulation like weather models where the state of point A influences its neighbors.
Billing and accounting systems don't have the same kind of dependance between data points. It's just that there is a massive number of them.
And they need to be processed quickly. Some of the files I work with every day have 7 million records with 2K of data per record. That 14GB just for that dataset and we get a new dataset every month. And that's just one file. I use about 10 different files. My company has literally tens of thousands of data files on tape cartridges in the mainframe data center. I can process *any* of them on request in a matter of minutes. I could process those 7 million records of data in a half hour if I had the machine all to myself. That's about 9 MBytes/sec of sustained throughput *with* calculations on every one of 7 million records in that time.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Anomalous: deviating from what is usual, normal, or expected
Canard: a false or unfounded repor
Unable to connect to the database. Please email.
Looks like a mainframe should be standard equipment for any site mentioned on slashdot.
Next thing you know, they'll be porting it to those old DEC boxes that all the universities have laying around.
Actually it depends on what you're doing. I can't comment on Linux specifically on S/390 but I can comment on OS/390 running on S/390.
One of the problems that server farms can face is the issue of support. If you install 8 intel boxes you must support 8 intel boxes. Generally speaking, supporting server is easier than multiple smaller boxes. The problem also isn't with making a 99.99999% availablility, but with making a site scalable for a large amount of traffic. If you need a few dozen servers to handle the traffic and availability, a single S/390 platform may give you better response and reliability.
The other issue that makes S/390 a good platform is that the hardware is extremely reliable. I read that the CPUs have an average failure rate of 1 failure every 30 years. Not too shabby and if it does fail the entire box doesn't crash, the underlying microcode just makes that CPU unavailable and will notify IBM support. If you have a spare CPU available it will even turn the spare on so you don't loose processing power. I've also heard rumors that future releases of S/390 will allow you to dynamically turn on CPUs so if you run out of processing power you can perform an upgrade with one command and never taking down the box.
Another advantage (as the article mentions) is disaster recovery situations. Mainframe DR plans have been in place for decades. Again backing up and restoring 1 system is typically much easier than multiple smaller servers. The hardware is also much more standardized than PC platforms so finding a DR site is not terribly difficult.
Also, don't let the cost of the mainframe fool you. They are a lot cheaper than you might believe. The old style of mainframes needed plumbing for the water which made the costs very expensive. The newer CMOS boxes don't require external plumbing and have a footprint the size of a large filing cabinet. So size & plumbing are no longer a problem like they were 15 years ago.
I'm not saying that S/390 will make other servers obsolete, but if you have the need and the money it definitely gives you an attractive alternative. Also don't forget that some people estimate that 60-80% of the world's data still resides on these old boxes.
As for the rational of running a free OS on a mainframe, that would be attractive to some because the software costs can quickly add up on a mainframe. Generally speaking the faster the mainframe you have, the more expensive the software becomes. A free OS could result in a huge budget savings for a company.
Again, it won't be for everyone (heck it won't be attractive to most people), but for some this will definitely be a good solution to a difficult problem.
Just my $0.02
Sure, the dozen PIII's will match the Big Iron in MIPS/FLOPS, but it would take a hundred times as many to match the sheer I/O bandwidth of those monsters. An old, low-end IBM 9x2 will handle 4,000 GB of I/O per second and love it. A high end PC will perhaps handle two, and totally thrash. Assume I'm wrong, and a PC could push 10 GB. You'd still need 400 computational nodes + 40 managerial nodes + 2 controller nodes == 442 PC's to match the performance of ONE old mainframe.
Used 9x2, $20,000.
442 PIII@$1800, $795,600. Which is cost effective?
When you're doing simple processing of huge data sets, like bank account updates or IRS 10-40 return valitation, it isn't adding up numbers that bogs. It's the contunual process of [retreive x][save x][print x]. Beowulf clusters have their place, and not as replacements for mainframes.
.sig: Now legally binding!
A PC vs Big Iron Holy War was definitely not what I was expecting with this article. Having worked with computers in various industries, I can tell you one thing, all of this stuff has its place. I was at a large loan servicing shop (like over a million loans) and I can tell you - you cannot configure any PC hardware to do what their MID-range box did. Over a 2 year period, not ONE server bounce, all the while hundreds of users logged in constantly, running massive batch jobs every night, printing out over ONE MILLION statements at a time etc. etc. etc. I am certainly not knocking the PC, I love 'em. But I do like the positive tone of this article, IMHO Big-Iron stuff is way way misunderstood by folks who haven't any experience with them. Heck, even I scoffed at the things until I got a chance to work with them. (PS I know my website's down - gimme a break, I have a full time job, ya know?)
mas cerveza, por favor politically incorrect stu
I think you are glossing over years of interesting history and computer architecture. IBM's mainframe division might have lost mililions because of PCs, but not because PCs were superior computing platforms for big data.
PCs won for the same reason that we have traffic problems on our highways--everybody wants to be a driver and doesn't want to share. This was, it seems, part of the rationale for the federally funded development of the internet (well, ARPANET): getting scientists to share computing resources bought with federal money (c.f. A History of Modern Computing, Ceruzzi 1998, p 296). This is of course the same phenomenon that drove minicomputers, which were also replaced by PCs. I'm not saying this is bad, well, not in the case of computing anyway.
But PCs still suck at any number of computing tasks, and aren't really improving in areas that can't be mass marketed. That's why my lab bought a very expensive dual Alpha machine instead of spending that money on the 5-to-20 equivalently clocked P-IIIs (these numbers come from real computations). Not to mention a farm of PCs can only handle embarassingly parallel computations at the same speed has the Alpha, and require more programming effort than the Alpha. The Alpha isn't even close to a mainframe, either.
And I haven't even gotten to bandwidth issues that sponsered this thread (well, they're part of the 5-to-20 figure above, in some ways). IBM lost on mainframes because they dealt _only_ with mainframes. DEC lost with minicomputers because they too were arrogant/ignorant about PCs. And while Intel seems to acknowledge the information appliance ideas, they're x86 tech will only go so far (we can hope, can't we?). But just as information appliances aren't the best choice for PC-type tasks, PCs aren't aren't the best choice for mainframe-sized loads.
Oversimplification is a marketing tool. It has no place in intelligent discussion, where flippant remarks are better replaced by _questions_.
Some anonymous coward dun said:
*chuckle* Methinks someone doesn't quite get the point with the mention of scalability...
1) Big Freakin' Deal that you can run Office 97 under Win98. For the applications we're talking about here (mainframe stuff--numbercrunching and storing) "pretty" stuff like Office 97 or GUIs in general are neither helpful nor necessary (in fact, they'd be a detriment to the Job that the Big Iron is doing).
1a) I would far from call any Microsoft product "reliable". Yes, this includes Office, Win95/98/NT/2000/3.1/CE/Me/[insert latest marketing spin from Micro$oft here], and IE. Yes, I know of what I speak here--I've had to do more than one repair job when supposedly well-configured Microsoft apps and OS's suddenly developed severe cases of incontinence. :P Compared with some of the stuff I have to put up with re Microsoft stuff (hint: OS's are not supposed to corrupt their essential files over time, nor are they supposed to lock when running programs [necessitating a hard reboot and scandisk], nor are they supposed to crap themselves after 49 days of uptime because even Microsoft acknowledges that neither Win95 nor WinNT are stable enough to stay up longer than that, thus a 49-day reboot is coded in), even beta builds of Linux are marvels of stability :)
1b) Please call me when a version of Windows is widely available for Really Big Iron, such as is used for databases for insurance companies and the US Census Bureau. ;) (AFAIK, they don't exist--not even WinNT ports (the largest iron WinNT was ever ported to, BTW, were Sun and Alpha ports--and those two ports are supposedly being discontinued). Most of 'em don't use *nixes, either--they use stuff you've probably never heard of like MVS, VM/CMS, VM/ESA, etc.) 2) The point wasn't on "who had more apps" or "who was prettier". It was "Who can run the base OS on more stuff"...which Linux beats Microsoft, hands down. (Itsys are teeny even compared to WinNT boxen, and with the recent ports to run as virtual machines under mainframes (not to mention the Linux/VAX project, the Linux/3090 project, etc.) Linux has probably just surpassed NetBSD as the OS which can run under the maximum number of architectures.) It's rather a different cock-fight than the usual comparisons, mind. 2a) I'm not sure that the virtual-machine versions of Linux are quite ready for prime-time (at least for what mainframes tend to be used for), but at least the option IS available should one want to run Linux as a shell (as opposed to a traditional mainframe virtual-machine OS like VM/ESA or MVS). Compared to the OS's that do tend to be used with mainframes, Linux is a fair sight more user-friendly; more people nowadays are familiar with *nixes in general (if from nothing else but student email accounts or computer science courses) than most mainframe OS's. Also--and this may be a shock to you to hear this--using Linux as a virtual engine actually would make it easier for users to set up stuff like Internet accounts--including PPP services for folks who want to use Windows from home. ;)
(As a minor data point to add to that--the University of Louisville recently retired its old 3090 (which had been formerly used in EMCS and IS courses, then [when email first started becoming widely available and the EMCS and IS departments had largely gone to either PCs, an RS/9000, or a combination of SGI, HP, and DEC Alpha boxen] was used as the primary Internet account server for the Arts and Sciences school) in exchange for a DEC Alpha box. This was done for many reasons, partly because PPP is easier to set up on the Alphas and partly because IBM no longer officially supports VM/CMS on the 3090s [which was a Bad Thing, especially since they also no longer accepted security patches for Internet utils and daemons; at the time, there were two rather serious security bugs for IBM VM SMTP that were being widely abused, and I spent much of a summer giving the two unofficial patches to universities who'd been relay-raped by mailbombers :P]. If a virtual-machine version of Linux had been available for the 3090, it's possible they could have kept it in service a while longer instead of selling the thing off for scrap metal. :P)
3) You talk of things being "ready for the desktop"--most mainframes aren't because they have no real need to be. Realistically, the most useful setup for a Linux VM on a mainframe would be either for Internet-related network services (sorry, but Linux does have better support there anymore--at least sendmail and qmail do have protection against relay-raping and are regularly fixed to close any security holes found) or for a shell alternative for folks who are already used to working on *nixes at a shell prompt (instead of them having to learn the command sets for Yet Another OS). It's fairly obvious that you've never done much work with a mainframe--otherwise, you'd realise that there is no freaking desktop...these are Big Machines, things that fill up entire rooms complete with false floors to hide the miles of cable and Halon extinguisher systems. You aren't going to get right at a terminal, and you probably aren't even going to use an X-term with these beasts (unless the Linux VM running has it set up to do so); if you access these things directly at all instead of sending stuff back and forth across a network with the mainframe being basically a virtual disk, you're going to do it the old-fashioned, CLI, type-in-the-commands-on-a-TN3270 way.
Needless to say, unless and until some kind of Windows port makes it to such Big Iron, whether or not it's "ready for the desktop" is completely and utterly moot! Unless a Linux VM is installed and set up to use X-terms, you aren't going to get a pretty interface--the closest the OS the VM is running and your Windows box are going to get is with your Windows box running a terminal emulator like TeraTerm or VT3270. It's going to be done by text, the way Big Iron has always done it since we got away from programming boxen by switching plugs and relays and valves (vacuum tubes for us Yanks) around and went to punchcards and old Teletype terminals instead, before the nutty folks down at Xerox PARC came up with the idea of GUIs in the first place.
(And before you ask--yes, I know what I speak of here, too. I was at U of L back in the days when the 3090 was actively being used to teach Fortran, and also when it was used as the Arts and Sciences Internet server--U of L actually had set up a mess of old VT100 terminals because, other than through a terminal program, that was the only way the students could read their mail! Graphical interfaces for VM/CMS and most other mainframe OS's that run in virtual machines plain don't exist; Internet apps that most folks take for granted (un-relay-rapable mail servers, such things as even text-based WWW clients, etc.) had to be found or just weren't available, and tended to be years behind their *nix and/or Windoze equivalents. Needless to say, life got easier for the A&S students when they retired the old 3090 and got the nice Alpha server running OSF/1 ;) I wasn't QUITE there in the days of punchcards, but apparently they were still being used as late as the early 80's there--that's how long the 3090 was around--and the things were never really designed for anything much besides big databases and number-crunching and maybe BITNET connections. Most of the OS's for Big Iron actually date back to the days before CRTs became widely available, especially the Big Iron using virtual machine OS's. In fact, the ONLY Big Iron I know of at ALL that uses anything close to a GUI are a) the Alpha and Sun ports of Windows NT and b) a terminal and configuration program for OS/2 designed to act as a console for booting AS/400 boxen running OS/400 (in other words, the OS/2 program largely replaces the blinkenlights). There's no need for being "desktop pretty" if all you're doing with the thing is using it as a big-arse server (which most mainframes are)--most of the time you might not even be doing direct interaction with it anyway, and if you have to a CLI works wonderfully. ;)
-Windigo The Feral (NYAR!)
This discussion keeps referring to 90% and 99% uptime as giving credit to PC hardware. I have, in 5 years, with 4 Linux servers, seen 3 hd crashes, 1 network card, 2 modems, and 1 motherboard go down. Each one of these was what I would consider a major crash (You say modem crashing is minor but these were internal and at the time primary IP devices).
.1% likelyhood of failure with some accumulation of likelyhood being more accurate (I.E a working new pc is unlikely to fail if it is entirely working but at 5 years the likelyhood of a harddrive or powersupply failure is probably 1%.).
Given that several hundred day uptime has been my experience with downtown being planned, I would say that standard pc availability is closer to
That being said, I do not think that the issue hereis cost of replacing parts or the costs involved in running high availabilty. Just adding hotswappable redundant power and fan, and hotswappable raid, good power conditioning, and decent backup+hotspare gives you acceptable performance. One of the reasons we consider the Beowulf cluster as economical is the notion that to increase performance you just buy commodity hardware and replace out old/worn machines. The process of doing so is probably not much different than the hotswappable parts of a mainframe.
Obviously the issue is the I/O involved with typical mainframe applications. Most PC users simply have no capacity to understand what bandwidth really is necessary for many real life applications. Someone mentioned 9 million record databases at 2k. Considering demographic data regularly run at credit card companies to determine NEW customers (where they are using 100million name lists), the person using a 9 million record database is actually a mid range user. Having tested a standard Pentium class PC with SQL, I find that over a million records makes queries very slow (30 seconds-2 minutes) Now certainly I could thrown more power, but larger databases create geometrical demands as the order of magnitude changes.
Having worked for the City of New York in the late 80's, I installed one of the first PC based LAN's and database solutions and I can tell you the benefit of this versus the Mainframe with their terminals had nothing to do with performance. It had to do with the politics of wanting to add fields, add reports, and prioritization of work demands. Centralizing computing power meant that changes to a database might require 6-10 months simply to add a field. This led to bastardization of fields, and what can only be refered to as DENORMALIZATION of data.
Statistical analysis was even more cumbersome. A question being asked by a new commisioner would require new statistical analysis, and the response would be needed quickly. But the request for a new report would require a bureaucratic nightmare.
Because of this many tasks were being done by hand by large staffs (8 people ddedicated to a single report).
When we recieved PC's, I was hired to handle the databases (relatively large 10-100 thousand primary keys) and the ability to create a new statistical model to view data being made in 1 day instead of half a year changed the way things were done. I had seen reports that took 2 weeks that were monthly reports and required a 8 people turn into 30 minute processing jobs that required 1.
The growth of the PC in departments was not because of the performance. it was because MIS departments were notoriously self-empowered and there was no way for a small department to influence their priorties.
People seem to be under the perception that the mainframe was somehow unsuitable, but it was always clear to us that the issue was management of the resources and a need by computer savvy managers to have their own programmers with their own priorities.
My father, a mainframe COBOL programmer/analyst for 30 years was pleased to see Linux sharing some of the same concepts as he was familiar with. However we both are well aware that the sort of performance he was used to programming (batches of 100million records overnight) is just not available nor are the management features. Hell, you can't even RUN COBOL in Linux.
In any case, I really think a major reason that there is so much anti-mainframe perspective is that mainframes have so often been considered expensive not for the uninitiated's touch, by the generation of programmers who were raised with the PC. They haven't used them, haven't considered what a COMPUTER is on a fundamental level, and don't have appreciation for the kind of programming that was done 30-40 years ago. My father used to brag about being able to write largescale applications in 8k of ram but with unlimited storage, a computer that fit in a room, but barely.
Of course Mainframes aren't dead, and of course IBM made money even when it lost the lead with PC's. IBM gives away mainframes. It doesn't need to earn a cent from hardware. It has the largest patent library in the world, and sells techniques, not technology. Its Supercomputers, Mainframes, Mini's PC's and palmtops are part of a SERVICE oriented drive to provide solutions to problems. The reason Linux is important to them is that they envision a POSIX compliant standards OS that they can run from top to bottom with no additional learning curve at each stage. No doubt THEY would not suggest a mainframe for solutions in which a Beowulf cluster or a multiple high availability cluster would be superior in cost. They would make their money supporting their user with whatever was the most effective solution for the pay. If we consider the world through the PC Vs Mainframe religious war view, then we lose the opportunity to evaluate just how much the PC has evolved into a personal mainframe, and just what we can accomplish in the next 10 years with Linux in the commodity market as well as what Linux can bring to the Mainframe market.
I think the article brought up several excellent examples of how a mainframe webserver farm might be advantageous. CoLocation is a bastard solution intended to move the machine closer to the bandwidth since we can't seem to provide fibre effectively to the location. As Media requirements change, colocation will stop being valuable (renting shelfspace atsomeone elses facility and losing physical access? Not acceptable)
Anyone with usage requirements that need a 390 is not going to care about the cost of multiple T3's. The idea that a new client could be granted a FULL operating environment that could be backedup as an image, could be given increased performance, storage, network facilities based on a level of service agreement, all sounds exciting.
Where we now have burstable T1's for growing companies that allow you to pay for the usage you actually see rather than spending based on your MAXIMUM usages, we would see every facility adapt to the usage. Suddenly see a 10fold increase in server usage? Instead of having to run around to solve a problem you didn't have a day ago, you could have a service agreement that would automaticly up your billing rate as your performance was increased. The benefits would not be just the ability to support a website with a 10million hit per day but to also support a 100000 sites that each MIGHT grow into a 10million hit per day site, without requiring capital costs to address that expansion, and reducing the cost of failure not in terms of system failure, but in BUSINESS failure.
Isn't that one of the benefits of Linux? To allow a company to take a risk without the costs inherent in the high end solutions? This article merely points out that the same benefit exists at every level of hardware.
Sorry for the rant... Well not really.:)
DLG
The whole point of modern mainframes can be summed up in one word: VOLUME. Regardless of the ground that has been covered by intel and co., the different OS developers, and the various efforts to develop high capacity I/O interfaces, your standard PC platform just doesn't have the ability to handle the sheer volume of data that your average mainframe deals with. PC's have a long way to go before they can even begin to encroach on the mainframe realm of computing.
The whole point of modern mainframes can be summed up in one word: VOLUME.
Sorry, but that's the wrong word. Volume is necessary, but you can get that with either big machines or clusters of little ones.
The word you want is RELIABILITY.
And by reliability I don't mean just uptime (although that's a piece of it). I mean the machine does not drop bits. Period. Even though the PIECES of it are dropping bits all over the place. (When you have square feet of silicon intercepting cosmic ray secondaries and rattled by thermal vibration it's unaviodable.)
I know of at least one mainframe multi-CPU unix clone (UTS) which has sites with uptimes measured in years. In fact the last time I heard there were software patches that had been enqueued to be loaded the next time it went down, which have been waiting for years as well.
The CPUS are automatically switched out when they fail and manually switched back in once they're fixed. The show goes on. And the processes that were running on the cpu as it failed still do their computation correctly - because the broken bits were caught and fixed as the CPU/memory/whatever hiccupped.
Many of the people who are putting together clusters of machines of lower reliability - including those in the management of at least one mainframe company - haven't grokked that concept.
The more computations you do, the more likely you are to be hit with an error. If your process is mission critical you can use hardware that catches AND FIXES the error, or you can try to write software that detects and recovers.
The software solution is the MUCH harder problem. The hardware fix - which is the mainframe solution - is expensive. But when you're dealing with millions of bucks per hour of downtime, or perhaps per dropped bit (as phone companies, brokerages, banks, and the like are), you can afford it. Mainframes (less peripherals), redundancy and all, have been under a megabuck a pop for some years.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Well, it just isn't so. Granted that clusters and desktops may even equal a mainframe's raw processing power, but a mainframe's real strength lies in its massive I/O capacity... you can connect huge arrays (even RAID arrays) of high-speed disk drives and have them work near rated transfer speed. No desktop comes even close to that.
Over 25 years ago I worked on a Burroughs B6700 mainframe. We had full source (at zero cost) to the OS, compilers, utilities and so forth, and had a great time mucking around with these, fine-tuning stuff, fixing bugs and even implementing new Algol constructs. For some weird reason Burroughs rarely used our fixes, though :-). BTW we also had full hardware schematics - not that these were of much use...
Wrongo! Mainframe = "Serious Business Machine". Nothing will get an MIS director's attention like saying "See, Linux can run both on your PC and on that million dollar IBM mainframe that runs your core business. Windows can't."
Remember, what caused the PC to catch on was not the "home user", but the business world. The PC caught on because MIS directors saw it as a "Serious Business Machine" in contrast to competitors that were "game machines". To these guys, Microsoft is the "johnny-come-lately" that they are not all that comfortable with. For them, IBM is still king. Saying that Linux will run on their big iron while Windows won't says to that that Linux is a serious operating system while Windows is a toy.