Experiences of Running Linux on a Mainframe 325
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.' "
of course mainframes are still alive... (Score:1)
Re:Running on a mainframe and the mainframe concep (Score:1)
Re:HILARIOUS - That one deserves better than -1... (Score:1)
I actually did this once, based on originality of the troll, but it got promptly moderated down all the way to -1. It was such a good troll that it actually lived up to the very definition of troll: To fish in; to seek to catch fish from. Here on /., the Usenet sense should prevail, namely: The well-constructed troll is a post that induces lots of newbies and flamers to make themselves look even more clueless than they already do, while subtly conveying to the more savvy and experienced that it is in fact a deliberate troll. If you don't fall for the joke, you get to be in on it. It would seem to me that most /. moderators can't spot the difference between flamebait, offtopic and troll, and sadly Cmdrtaco promotes this by tagging troll as something inherently bad. It's not.
Re:Linux zealots shoot themselves in the foot agai (Score:1)
Re:Running on a mainframe and the mainframe concep (Score:1)
Someone here on slashdot has a sig that's quite appropriate here: "the average slashdotter seems to think the entire internet could be run of a cluster of beige boxes running linux."
Grow a clue people. This is almost as bad as the idiots who scream beowulf when someone asks about high availability and fail-over.
Re:Open-source mainframes (Score:1)
He has a great story about them not needing floating point stuff at their site but wanting to drive some peripherals without a compatible interface. To cut things short, they ripped out the floating point board and replaced it with a driver for this peripheral.
All was fine until they got an external consultant in to help with debugging part of their system software. Apparently it took him several weeks to get his head around the fact that occassionally the application would appear to do a floating point division and then discard the result - of course this was actually flushing a buffer.
*sigh*
closest I ever got was wiring morse keys into a joystick port - hardware hacking just isn't what it used to be.
Hitachi kicks IBM and Amdahl's ass (Score:1)
Re:Mainframe Power (Not!) (Score:1)
You can get large amounts of storage and redundancy on a starfire. But it still isn't a mainframe, although it is still a damn good high end Unix server.
article... (Score:1)
Re:Two words: Web Hosting. (Score:1)
To paraphrase my reply to the previous comment to my original message: To not spend $[foo] for a shiny new PC, you must first have spent $[foo] * a a large number for the box which allows you to "just fire up a partition" to add a VM. :-)
Re:Nice trick... but that's about it. (Score:1)
Whoa there! I never said VMWare replaced this, but rather the idea of Linux running under a virtualized system was first (?) demonstrated under VMWare.
Re:GPL violation? (Score:2)
Re:Can you say "Security" (Score:2)
Re:Running on a mainframe and the mainframe concep (Score:2)
Funny, I've been hearing this for ten years now. "The Mainframe is dead." "Unix is dead." Sure. It's beyond me why people try to predict the future in this industry. I've yet to see someone who can do it without emabarrassing himself horribly.
Running linux on these things I guess would be a waste because I am sure that some crappy mainframe OS would work a little better.
What makes you think so? IBM did the port after all; I would assume they know what they're doing. Besides, if the mainframe OS is crappy (which they aren't) why would it be better???
Re:Running on a mainframe and the mainframe concep (Score:2)
Re:Nice trick... but that's about it. (Score:2)
I assure you that I did read the article in its entirety(sp?) before responding. However now to your points:
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.Perhaps it would be ideal for some but personally I prefer seperate boxes for a lot of things. Catastrophic failures being one. What good is a hot swap box if the box is flooded (water) / destroyed by fire / millitant admin with an axe, etc. Before everyone screams "Backups" (and I agree with them) think of this: if your $Million machine is toast there's nowhere to put the tape and I would imagine delivery on a shiny new mainframe wouldn't be a next day thing. 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.
I also disagree with your "near idealism" about everything in one box. I would certainly not want my router / firewall / X term / webserver / database in one box. However the idea of the mainframe where every "sub box" is a totally seperate entity is a great idea. But for most cases, the sheer co$t of this compared to a standard cluster and frontend/backend solution must also be addressed. How many standard machines would you need to replace (taking into account the savings you made in configuring/adminning only one box) with an S/390 to make it profitable?
Let me perhaps modify my opinion a little: The S/390 port could be useful, but is definately of fringe usefulness when all factors are taken into account.
Re:Running on a mainframe and the mainframe concep (Score:2)
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.
Beowulf? For billing applications? Do you know how complex parallel programming is?
And how do you like the idea of maintaining 200 PCs: I'd suggest it's a lot more difficult and expensive than maintaining one mainframe. Especially when most mainframe components are 100% hot-swappable: hell, you can do a microcode update on these things without any downtime.
Of course you'd have multiple printers, although the last mainframe printer I was attached to did 120 ppm, and had its own monitor.
--
Re:Yes - "n" webservers ALWAYS better than 1 (Score:2)
A S/390 has fault tolerance features that the PC world can only dream of. Failover and sustainability are really not a problem in mainframe world, believe me.
--
ha "best webserver" (Score:2)
nWo for life!
------------
a funny comment: 1 karma
an insightful comment: 1 karma
a good old-fashioned flame: priceless
Re:MVS has a unix interface (OpenEdition 0S 390) (Score:2)
...except for a native character set of ASCII or a superset thereof. :-)
I don't know to what extent the ASCII/EBCDIC problem gets in the way of using the UNIX environment on OS/390 (e.g., requiring that the code be checked to make sure it doesn't assume that "A" through "Z" form a contiguous set of character codes - and doesn't assume that the characters you get in from a TCP connection from an HTTP client are in the native character set of the C compiler and the file system and...), but if it gets in the way of Just Recompiling, perhaps that was some of the rationale.
Re:Few points... (Score:2)
What about Microway's [microway.com] Alpha-based systems? $1995 for a 533MHz 21164...
Your Working Boy,
Buzzz... Wrong statistics (Score:2)
Sorry, but you are figuring your reliability the wrong way around. If you only need 1 or 2 boxes worth of horsepower, then, yes, 8 boxes provides high availability.
OTOH, if you are attempting to gang multiple Intel boxes together to replace mainframe capacity (ignoring I/O bandwidth in this example), then the more boxes you have, the greater the chance one of them will be down.
Let's give PC hardware a break, and assume 99% reliability instead of your figure of 90%. If you need 50 Intel boxes to replace a mainframe, at 99% reliability each, then overall reliability (all 50 machines working at the same time) is 0.9^50, or about a 60% chance. In other words, at any one time, there is a 40% chance 1 of your boxes is down. If you need at least 50 working boxes, then you better have >50 boxes linked together.
It gets worse with more boxes. Do you need 100 boxes working all the time? The odds of keeping 100 boxes running (each with an individual chance of 99%) is 0.9^100, or about 36.6%.
Meanwhile, that mainframe you were so keen to dump probably had an uptime availibility of at least 99.95%.
High quality trolling posts (Score:2)
But this is a high-quality troll. Has Jesus Christ ever checked out segfault.org? You'd fit in over there.
What you get with a mainframe is not the mainframe (Score:2)
When I was fulltime in MVS ESA world we planned for WEEKS for an IPL (reboot) because they happened maybe twice a year for planned upgrades and never from unplanned events. In fact it was a ground breaking event when we got a VTAM upgrade that didn't make us regen VTAM following LU/PU changes. And 3745FEP's and NCP? Forget it, I've never seen one crash. Ever. In 20+ years. ESCON Channel I/O is 136Mbps or 17MBs out of the box and there are many approaches to multiply that in the aggregate. Throughput? We put CICS in its own region running as an uninterrupted communications task on a low end 9021-200 and got 500tps almost 8 years ago.
The problem though with putting freenix on a mainframe though is the fs. Native freenix fs structure probably can't be implemented well over the native IO or over the native mainframe file structures, PDS's etc.
--OT-- I want experience with S/390s (Score:2)
I'm currently an admin with a few years' experience on various flavors of unix-alikes on peecee hardware. I'd love to get some experience on big iron, but I'm not sure how to go about that.
If anyone is willing to spend a few hours a week mentoring, I'd love the opportunity to learn from someone in the Boston Metro area with experience. You have scut work to be done? I'll do it, if I get to learn. I'm busy, but I can spare a few hours a week. If you're interested and like to teach, please drop me a line (jerkbob_at_pobox_dot_com [mailto]).
Apologies again about the OT post...
--
A host is a host from coast to coast...
Re:Mainframe web hosting (truly virtual!) (Score:2)
Service includes:
100 Meg of disk space
Free name registration
50 Gigbytes transfer / month.
One time setup fee of US $3,000,000 due at signing.
Re:Nice trick... but that's about it. (Score:2)
These are expensive contracts for big time players.
Re:Nice trick... but that's about it. (Score:2)
Why?
The concept of a "virtual machine" extends not only to the user-mode instructions, but to the system-mode instructions as well.
The standard end user operating system, CMS, runs entirely in system mode with memory protection turned off! Or at least it thinks it is
So, even if you found a way to inject executable code into the kernel, and get the kernel to run your code in system mode, the only damage you can do is to your running kernel. You are still kept inside of a black box, and can't interfere with any other virtual machines.
Re:Them Brontos... (Score:2)
We just rolled out our 3090 last week. Cut it up and sold it for scrap. $5,000,000 brand new in 1989. I think we got $3000 for it
I don't miss the 3380s though. They were a different story. Those disk drives were NOT sealed, and we have a crappy, dusty machine room. We used to have a 3380 failure about once a week. Finally, we replaced our 3380 strings with 3390s, then Hitachis, which don't seem to crash (knock on beige colored steel
Re:Yes - "n" webservers ALWAYS better than 1 (Score:2)
It's about the thickness of your wrist, and uses a locking connector. I believe that it requires a wrench to detach the power cord from the motor-generator.
Yes
If there is a power spike on the lines, the power spike is absorbed by the momentum of the physically rotating flywheel, thus protecting the mainframe. Beats the hell out of a "surge suppressor" any day.
This is standard equipment on a 3090.
Oh yes, and we have direct connections to two Commonwealth Edison power substations. If there is a blackout on our primary substation, a HUGE, frightening looking switch is automatically thrown, and the mainframe power is switched over to the other substation
Re:Running on a mainframe and the mainframe concep (Score:2)
This Linux port is actually the first credible Unix implementation for the 390. (i.e. something that systems programmers are excited about, as opposed to disgusted by.)
Re:Wow! (Score:2)
Been there, done it ;-)
Most of them run NetBSD with ease. I have actually used some of them as file servers and despite their pathetic CPU power (around a 286-386) they stuff a 10MB ether to the point of congestion (unfortunately there are no higher speed interfaces for them).
They suck for web servers, DNS or whatever else where latency and execution speeds are crucial but they make damn good fileservers after you replace the hard drives with a recent SCSI. And after such surgery they just work. Boot them once and forget them forever.
Best web-server? I doubt it! (Score:2)
(hits with a baseball bat that is.)
Re:Running on a mainframe and the mainframe concep (Score:2)
I have said for 18 years now that we must use the right technology for each system. As much as that may hurt some
Mainframes and their OS is extremely good at processing enormous volumes of data and transactions. They are real bad at interactive processing and should not do that. Linux is one flavour of the very good Unix system that is excellent for servers and power workstations. With the introduction of Linux, Unix will be accessible to the "common user", there is a bit left but it will be there Real Soon Now (tm).
I have seen to many projects becoming disasters because of using the wrong technologies. Let's stop the bickering and try to collectively use computer technology wisely.
Re:GPL violation? (Score:2)
The latter is Not bundled AFAIK with any distribution but must be obtained directly from Lucent's website. But the latter driver does support all the features of the card. It seems that here Lucent decided to cover their arses by writing a wrapper to their proprietary bit that was source GPL talking to the pcmcia_cs and the kernel.
So, which is right? Just including a binary or do you Need to write a wrapper?
mainframe linux = mainframe NT? (Score:2)
Could mainframe linux enable mainframe NT?
Install linux into a mainframe VM,
then install VMWare under the linux host,
then install NT under that.
It's sufficiently recursive to make me smile if nothing else. And we haven't even talked about squeezing Transmeta codemorphing in there somewhere. {chuckle}
Re:Wow! (Score:2)
As far as old DEC boxes, I was using UNIX (specifically 4.2 and 4.3 BSD) on VAXes back in the mid 80's. DEC hardware was the original host for UNIX (the PDP-7), and was the most popular hardware for UNIX in the 70's (PDP-11 family). I know for sure that NetBSD still has support for at least some of the VAX hardware, and you can get licenses from SCO (the current USL owner) for free to run older versions of UNIX (V6/V7) on PDP-11's. Once you get a V7 license you can get a copy of the 2.11 BSD distributions from I believe an organization called the PDP-11 preservation society.
Re:Wow! (Score:2)
Mainframe web hosting (truly virtual!) (Score:2)
OK, all you entreprenuers, are you listening? I would LOVE to host in an environment like this,
assuming it could be done for a price that's competitive with colocation/dedicated box services. From the numbers I saw in the article, it seems (at least as far as HW goes) you might be able to be very competitive indeed.
Call me when you want to beta-test. Or even sell.
Re:Running on a mainframe and the mainframe concep (Score:2)
2. Last time I checked, IBM's revenue was larger than Dell's, Gateway's, Compaq's, and HP's. Combined. Tell me again about IBM's economic failure?
Re:Running on a mainframe and the mainframe concep (Score:2)
Re:Irrelevant if your network card is saturated (Score:2)
Though, a 100Base network can't actually do 100Mbps between hosts. 100Mbps is simply the number of symbls that can be put on the channel.
With ethernet overhead, and other protocol overhead, including handshaking, you'll find the maximum throughput for something using tcp is around 85Mbps. And that's if only two hosts are talking.
Re:Where mainframes still have the advantage (Score:2)
Then in 1990, they predicted that the mainframe would be gone in 10 years, this time because of PCs and servers. Result: IBM is selling more mainframes than ever before.
Now you are predicting the same thing. What you are doing is the exact same thing that previous people did; you are ignoring the ability of the mainframe to improve just as much as PCs. The mainframe is ALWAYS going to be around, because there will always be a need for massive amounts of computational ability and I/O. The PC may improve, but the mainframe will also.
When you buy a PC for 2-3 thousand dollars, you are getting pretty low end stuff, compared to a mainframe which costs $100,000 on up.
For money you get honey, and what you get with a mainframe is a machine that is designed to work and keep on working, no matter what.
Re:Define mainframe (Score:2)
There is some overlap, classic supercomputers, like mainframes, have very high performance I/O and memory systems. Both tend to have huge amounts of RAM and disk space. The word size on a supercomputer is usually equivalent to the size of a double precision floating point variable. The IBM 360/370/390 is a 32-bit architecture although its main memory address space is much larger than 32-bits. The mainframe has a hierarchial memory system (L1 cache, L2 cache, main memory, bulk memory) where the classic supercomputer does not have a cache. The supercomputer streams operand vectors from memory to vector processing units in the CPU and the results are streamed back to memory.
Re:Can you say "Security" (Score:2)
Script kiddies are a problem, but mainly to the 95% of sites that aren't maintained, the ones that have admins who read bugtraq, etc, are fine.
If you're on the ball as an admin, you shouldn't have many script kiddy problems.
This was Moderated Up YESTERDAY (Score:2)
It got a 4, which I guess it deserves, but posting the same thing twice is a bit weak.
The original is here - in the EBay story [slashdot.org], BTW.
Re:This was Moderated Up YESTERDAY (Score:2)
Damnit! I knew reading Slashdot all day everyday was a sin, but I just thought I'd just lose my job.. not my eternal soul!
Re:Running on a mainframe and the mainframe concep (Score:2)
Now the desktop/small server products are tremendously powerful (200-900 MHz is a ridiculous amount of processor power) and are often underused because they are so cheap (Hello, SETI@Home!). The "minicomputer" devices have taken over many of the former "mainframe" applications, and many actually use parallel microcomputer designs (ie, Sequent, Stratus). The "mainframe" has fairly fast processors and is surrounded with very fast I/O devices and I/O processors. When dealing with the huge amount of data which global companies produce and manipulate, often parallelization of data handling is more complicated than using big iron.
Remember, IBM also sold a lot of IBM PCs. They lost a lot of PC business to competitors, particularly when they tried to require MicroChannel use. Most PCs just don't use so much data that they needed MicroChannel, and the additional licensing expenses just weren't worth the minor benefits. During the same time period there was a gap in their minicomputers with their old-tech S/36 before the AS/400 was developed. The big iron is flashy, but a lot more people needed the smaller machines. And there was a lot more competition once the microcomputer technology provided engineers with fast processor components for competing designs.
Re:Linux zealots shoot themselves in the foot agai (Score:2)
Evangelists, please remember this the next time Microsoft gets its panties twisted about "scalability".
Microsoft: "Our OS scales from a hatchback to an SUV"
Linux: "Our OS scales from a motorcycle to a freight train"
Re:Running on a mainframe and the mainframe concep (Score:2)
By the same token, Linux will blow a mainframe also-ran Unix out of the water.
Re:Mainframe Advantage (Score:2)
Professionally doing the e-commerce thing, I am constantly running into the same problems: bandwidth and performance. It's not enough that the program does X, but that it has to do so much X in so little time on our hardware.
This may be an interesting development. A lot of these new outfits can get capital for the asking but not developers. Thus, mainframes are easy to pick up, but mainframe developers are almost impossible to hire. An S/390 Linux port allows you to use your existing Unix staff, with some mainframe sysadmins and minimal retraining, to use high-bandwidth hardware.
obSlashdot: What happens if you make a Beowulf cluster of mainframes? ;^>
Re:The time has come... (Score:2)
On a side note, I wonder about the "submitted" stories sometimes. Often you see that So-an-So writes "blah blah blah" where blah blah blah has a consistently similar style, often correlated to the individual who stuck the story up on slashdot. But maybe it's just me.
Re:Running on a mainframe and the mainframe concep (Score:2)
Re:best damned webserver? (Score:2)
Re:GPL violation? (Score:2)
I'm not sure this matters though. Section 2b of GPL V2 states:
"You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
Notice the phrase "that in whole or in part contains".
Naturally, the driver itself is probably not derivative of other drivers, except for trivial similarities. However the distribution and more to the point the kernel at runtime is a work that includes GPL'd components
Allowing clean room developed code to be linked (even at runtime) to GPL'd code would be a huge loophole in GPL. It would allow you both to create proprietary dervied works, and to expropriate components of GPL'd works for incorporation in closed products, simply by partitioning the code into sections by licensing.
I believe GPL 2 envisions this:
"If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works."
The question is, can the network driver "be reasonably considered indepependent and separate". (And to a lesser degree, is the network driver distributed as a separate work.)
Any thoughts?
Re:Yes - "n" webservers ALWAYS better than 1 (Score:2)
Sure, but do you roll your own, or do you buy it nicely packaged up in a cabinet with complete system wide support from the vendor?
GPL violation? (Score:2)
Isn't redistributing a kernel with a non-free module a violation of section 2b of the GPL (the viral clause)?
Re:Can you say "Security" (Score:2)
The latest OS390 versions come with their own Web server, which is a variant of Apache (the variant part comes because of a difference in the way mainframes handle processes). So that part is already there.
Now, if you run the real Apache on Linux on your S390, by their nature you have thousands and thousands of people who know the strengths and weaknesses of those packages. Only a relative handful of people in world could hack an OS390 system.
How many of you, if you discovered a buffer overflow situation that would let you enter a command string on such a system, would know what to do?
Garg
Re:Running on a mainframe and the mainframe concep (Score:2)
Re:Running on a mainframe and the mainframe concep (Score:2)
It all depends on: a) your application, b) your choice of networking hardware and software. Flops-intensive software will fare *very* well on a Beowulf. I/O-intensive stuff (like retrieving huge amounts of data off an RDBS) would most likely be better off on a mainframe.
Check out this site [beowulf-underground.org] and tune up your cluster...
engineers never lie; we just approximate the truth.
Wrong. (Score:2)
Intel hardware has a long way to go before it can touch big iron for sheer I/O throughput, which is what a mainframe customer wants. 16-way is barely the right order of magnitude.
Win2K is so hideously unstable that it has no place in the *real* machine room. MS claim 99.95% reliability. Well, that sucks. Given three minutes for a reboot, that's one crash every two days. If I have 5,000 users logged on, I can't afford that sort of downtime. I need genuine 24*7 availability. That means a system that can cope with 5,000 users, a number of whom are developers, hacking away processing tens of millions of records a day and never crash. Not once. Given an operational life of maybe ten years I won't tolerate a single unplanned outage. Sorry, guys, but the only boxes that do that are mainframes.
Having said that, I'd quite like to run Linux in a VM.
Re:Running on a mainframe and the mainframe concep (Score:2)
Name me one bank running their systems on a cluster of PC's!
I'm an MVS contractor, makeing a nice living from working on these "neolithic dinosaurs". Last year I worked for HSBC - the Hong Kong Shanghai Banking Corp. They are known as Midland over here in the UK. I know what banks run their stuff on, and it sure as hell isn't a Beowolf Cluster!
No flames intended but you're talking a whole crock of shit here!
Don't forget Amdahl. (Score:2)
Talk about IBM clones... B-) It's hard to get more accurate than one done in the company started by the guy that used to design 'em for IBM.
Re:Running on a mainframe and the mainframe concep (Score:2)
There are still some places where the dirt cheap PC style boxes have not infiltrated. As many people have pointed out, mainframes can handle much higher transaction volumes and have much better uptime figures than any other kind of system.
Also, remember that many of the outfits that use mainframes have huge amounts of legacy code in production that might not port so easily to a beowolf cluster, or anything else.
The costs are huge but you need to put them in perspective. I was talking with one of the local Sun techs in my area and he had recently been out to work on an Starfire that a client kept as a hot spare. This is a $2 million dollar machine and it's just the backup! The tech thought it was overkill but the client, a major brokerage house, does $4 million an hour in transactions. The spare machine would pay for itself ini preventing only 30 minutes of downtime.
For the organizations that really need them, the big iron is still worth every penny.
Read the fscking article (Score:2)
HH
Re:um, why? (Score:2)
And are IBM 'brain dead' for porting Linux to their own mainframes? I don't think so.
HH
Re:Nice trick... but that's about it. (Score:2)
That's so odd, I would think the cool factor of seeing see the room of mainframe would be exponential greater than a room of PC based machines (even 1GHz Athlons w/SCSI...). A "room of machine", that's funny, like my neighbour trying to borrow a "cup of sofa" from me.
<i>something inside me says not to trust a single box</i><br><br>
Here, Here! With any other configuration, having everything on one box would send a spike of fear into my spine. But this configuration, something says to me: "Have no worries". Must be those thrice-damned subliminal messages again. Still, mainframes were built good, and if you have ever used hot-swap-able components, you will understand the utter joy of them.
Re:Nice trick... but that's about it. (Score:2)
Well, actually, it (probably still) is. Some years ago while working in a mainframe computing center I was told that IBM had actually hired a Boeing to fly a whole mainframe over the Atlantic because they had no adequate hardware in Europe and the still needed to honor their 24-hour service contract.
At that time (more than 10 years ago) the company I worked for estimated that they would go bankrupt if they lost computing service for 72 hours. I would guess that time has decreased by now. If you are that dependant on computers, you really care about the quality and speed of your service contract.
Re:Running on a mainframe and the mainframe concep (Score:2)
hanging off a PC that was acting as something other than a controller? When did you hear about PCs churning out billing statements for a million customers twice a month? (And finishing the actual print job in a day?) It's just a
matter of tuning your platform to the task, and mainframes are seriously tuned for big volume.
Sounds like the job for a lot of PCs with load balancing or perhaps some form of a beowulf cluster for the actual processing. 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.
Re:best damned webserver? (Score:2)
One last point in favor of mainframes is one very few people think about until it's too late - ease of service. Hardware, especially hardware that's being run at full capacity 24/7, breaks. When it breaks, it's nice if you can replace it easily. This is where PC's really suck and mainframes are quite nice - they are designed to be serviced, often while running. Your ethernet board died? No problem - swap in a new one without rebooting (I assume IBM can do that? I'm sure someone will flame me with a correction if necessary :) Redundant power supplies are also quite nice.
This is not saying that a mainframe is right for *every* webserver, but when you lose millions a day for going down, even a small increase in reliability or ease of service may well be worth the extra cash up front!
Re:Irrelevant if your network card is saturated (Score:2)
Well, the one I work for does. As a hint, it was "attacked" two weeks ago. The traffic this site gets is what I base my comments on.
Re:Yes - "n" webservers ALWAYS better than 1 (Score:2)
Its a lot harder to yank out two hundred power cords than one.
Re:Yes - "n" webservers ALWAYS better than 1 (Score:2)
Thats certainly for transactions, not serving html.
Yes - "n" webservers ALWAYS better than 1 (Score:2)
Irrelevant if your network card is saturated (Score:2)
While a mainframe may be able to handle all of the CPU needs for EBay, no single network card can handle all of the traffic in an affordable fashion. And even if one did, EBay would be silly to put all of their eggs in one basket, regardless of its power.
Re:best damned webserver? (Score:2)
A trained chimp can support an intel box. If its too much hassle - go with a colocation service that does it for you. Still cheaper than a mainframe.
The point with webserving is granularity. Think of webservers as grains of sand - you add or subtract them at will to increase performance or to fix problems. In this contect a mainframe is a large rock, which doesn't work well in webserving environments.
WEb serving is fairly light on processors - its heavy on network connectivity and disk I/O, with an emphasis of 100% uptime. With these requirements, it doesn't make sense to use mainframes, and I don't think anyone would reasonably advocate using them in this capacity.
Take a tour of a colocation like globalcenter - it will put things in perspective.
Re:Mainframe Advantage (Score:2)
Actually, you can virtualize a whole bunch of Linux systems on one mainframe and Beowulf them.
Talk about ridiculous extremes.
Anomalous: inconsistent with or deviating from what is usual, normal, or expected
Mainframe Power (Score:2)
Okay, so it costs UKP1,000,000+, but so what?!! Solaris is (basically no cost), Linux is free.
The power's there, plus the flexibility. Also, if you know Linux, you know Solaris.
Re:Can you say "Security" (Score:2)
Can you say "Security" (Score:3)
Re:Running on a mainframe and the mainframe concep (Score:3)
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.
Where the mainframe excels (Score:3)
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.
--
Re:Running on a mainframe and the mainframe concep (Score:3)
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...
Re:Running on a mainframe and the mainframe concep (Score:3)
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 ?
Re:Nice trick... but that's about it. (Score:3)
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!
Re:Nice trick... but that's about it. (Score:3)
Next time, read the article. Trust me, you will be a better person for it.
Mainframe Advantage (Score:3)
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.
Re:Running on a mainframe and the mainframe concep (Score:3)
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
S/390 for LinuxPlanet (Score:3)
Looks like a mainframe should be standard equipment for any site mentioned on slashdot.
Wow! (Score:3)
Next thing you know, they'll be porting it to those old DEC boxes that all the universities have laying around.
Re:best damned webserver? (Score:4)
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
Re:Running on a mainframe and the mainframe concep (Score:4)
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.
Wow, an unexpected Holy War (Score:4)
Re:Running on a mainframe and the mainframe concep (Score:5)
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_.
Re:Linux zealots shoot themselves in the foot agai (Score:5)
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. ;)
Re:best damned webserver? (Score:5)
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
Re:Running on a mainframe and the mainframe concep (Score:5)
Wrong word. (Score:5)
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.
Open-source mainframes (Score:5)
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...
Re:Linux zealots shoot themselves in the foot agai (Score:5)
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.