Slashdot Mirror
The Pros and Cons of Mainframe Linux
magellan writes "There is a good article on LinuxWorld.com that goes over some of the pros and cons of Linux on the mainframe. The author, Paul Murphy is an old mainframer and current UNIX user, as well as a frequent contributor to LinuxWorld.com, so he has some good insights.
"
Linux the utility OS, runs anywhere. I have it on Intel & Alpha at home. What hardware do you want to make sing today :-)
What OS do you want to abuse today?
I was about to spend 5 million dollars on a new zSeries setup, but after reading the article I thought "maybe my laptop is good enough for now".
-... ---
-atrowe: Card-carrying Mensa member. I have no toleranse for stupidity.
"tolerance"? . . . oh, the irony.
Besides pricing, the more high end the server goes... the more I will lean toward solaris.
I am linux-biased folks are going to / me for this.... but I am speaking from experience.
Um, Solaris, Irix, and HP/UX (shudder) are *NOT* mainframe operating systems.
MVS and OS/390 are mainframe operating systems.
You are talking out of your nether regions, especially when you call linux's TCP/IP stack inferior to HP/UX. I have adminned every operating system mentioned above except Irix, and you sir are grossly incorrect.
Of course, the use for Linux on a mainframe _is_ as a low- to medium server, running virtually atop VM. I have not sen anybody seriously advocate running Linux as the base OS on such a machine.
/Janne
Trust the Computer. The Computer is your friend.
UNIX was designed to get away from the mainframe usage paradigm, not reinforce it. Read the article. It yields good insight into the differences between the Mainframe Way (machine resources are more important than user demands) and the UNIX Way (users needs are more important than the machine's).
Funnily enough I just came across this article on ZDNet that talks about how Linux isn't a very good long term server solution. Its here at http://zdnet.com.com/2100-1104-909084.html
Linux was never ported to the 486 and Pentium. As they support the same instruction set as the 386, no porting was necessary. Sure, over time enhancements were made to take advantage of specific features of various x86 features, but that's not porting.
And GNU has nothing to do with porting of Linux to any platform.
And your corporate mainframe doesn't run NT. Or if it does, you're using a definition of "mainframe" with which I was not previously familiar.
And preemptive multithreading and protected process management is not new to 2.4.5. That's something that has been in every Unix since, oh, about 1970. It's also something that has been in every enterprise-class system in the past twenty years. I would hardly call it a boon to admins.
AFAIK, there are no mainframes that run NT. And I've never seen one with a USB port, either. Your post makes absolutely no sense from a mainframe perspective. What are you talking about with "dual boot"? Mainframes can run multiple simultaneous LPARs, which are virtual machines sort of like VMware provides, but nobody ever boots a mainframe if they can avoid it. And mainframers don't use the word "boot" anyway, since individual components of the mainframe can be individual restarted. Mainframers IPL from the HMC, which is the analogous operation to rebooting. Mainframes run VM, MVS, OS/390, and similar. They don't run NT or OpenBSD (though OpenBSD could probably be ported). There is no graphics console device on a mainframe, so how the hell could you run NT?
Much server work looks like this: request comes in from network, appropriate program gets loaded, maybe talks to a database, runs for less than a second, returns results to network, exits. Typically, a large fraction of the resources used go into the "appropriate program gets loaded" step, doing the same startup ritual over and over.
There are two UNIX/Linux solutions to that startup overhead problem. One is to build the transaction program into the network application (as in Apache/mod_perl/php). Note that this uses an interpreter to protect the network application from bugs in transaction programs, which is a major performance hit.
The other approach is to use the regular UNIX/Linux program launch facilities to run a separate program for each transaction (as in CGI programs.) This is safer and easier to maintain, because the CGI programs each run in their own processes, but the cost of program loading (which might include initializing a Perl or Java environment) often dwarfs the cost of doing the useful work.
A mainframe transaction processor basically maintains process images which are ready to run a transaction, with all loading complete. When a process is needed to run a transaction, it's made by copying one of those process images (with read-only or copy-on-write sharing of pages) and launching it to do the job. The new process runs for a short period and exits. This is a facility that Linux/UNIX lack, because they were intended for interactive use, not server-side transactions.
Because Linux has copy-on-write semantics for fork(II), it's should be possible to do a high performance transaction facility under Linux. A transaction program initializes itself by loading everything it needs, but without any per-transaction data available. It then goes into a loop waiting for work, and on each request, forks off a copy of itself to do the job. Each copy does one transaction and exits. If it crashes or gets corrupted, only one transaction is affected. Note that there are no expensive exec(II) calls involved in starting a new transaction.
Has this been done? It's obvious enough that somebody has probably tried it.
That ain't big iron! The only system that runs both of those is the Alpha. And the Alpha ain't a mainframe.
Best Slashdot Co
First of all, way to go Slashdot, this article has been out for quite some time. It's received a lot of attention on the Linux 390 mailing list as a Sun FUD campaign as it places a fully loaded z900 on par with 80 Dell servers and the zSeries in general on par with mid-range Sun equipment (and others).
;) so it is my job to know about what a z800 can do for us.
First, I'm fairly qualified to talk about what the zServer can do. For those of you who don't remember, I'm one of the guys that helped win a z800 for Clarkson University that will be used in our Open Source Institute. I'm also the technical lead for COSI (whatever that means
Some history, Clarkson University has always had a very good relationship with IBM: they employ a large amount of Clarkson students and graduates (including me, in the Extreme Blue program. So if you think that biases my opinion, well too bad as I've talked with the guys making sure that Linux runs and is fully integrated on the Linux platform and one of the original Linux S390 authors Boas Betzler.
All of these people have real experience with what the zSeries can do, as do I since I've seen it in action. A zServer is unique in the sense that you can (with the right model) run Linux S390, VM, zOS and other guest operating systems in Logical Partitions. These all act independantly of one another just as if they were seperate machines on a network. This is great if you have DB2 with maybe a web frontend because both of those machines can talk at memory speed via HiperSockets and the only outside link is the network connection to the web server, which is at Gigabit speed (did I mention that you can do full speed gigabit with one of these things on multiple interfaces?).
This article basically says that you can take a midrange Sun server and do everything that a z800 can do but much better. I don't know of any Sun Server that can run N Linux clients in a VM at full speed.
They aren't the solution to every problem, but a zServer certainly is a better solution that what is presented in the article. I really don't have the time to go in to detail with everything as it's a lengthy article but suffice it to say that this is no where near 100% accurate.
No it wasn't. GNU is a license, and licenses are notoriously bad for writing code (or doing anything except sit on a disk or shelf). Linus wrote Linux for the 386, but there was nothing stopping you running it on the 486 even on day 1. In fact, even today, you can run 386 code on a Pentium IV. The only disadvantage is that you'll not get the best optimizations. The GNU license was applied for version 0.12 in Jan 1992, before it was really a practical OS, and in March 1992, it became 0.95, and was really a usable OS.
darn, I had hoped to get "+1 funny", but I got "-1 not funny you star trek goof" instead. oh well.
The Kruger Dunning explains most post on
I'll grant the point of the paragraph - that UNIX process/destruction occurs more often that MVS address space creation or even task creation. And I'll buy that some "UNIX CPUs" can handle multiple instruction streams. But have any really implemented a single-cycle context switch?
I checked, and yes, the IBM site did say "31-bit" mode. Won't this break a lot of Linux apps?
"Linux' inferior TCP/IP stack"
Zero copy networking not good enough for you? You want networking that somehow zips packets along without even touching them except by telepathy?
Back under your bridge, troll.
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
You are incorrectly aggregating mainframes, shared-memory multiprocessors (SMP/NUMAs), and clusters as massively parallel machines.
Linux makes a great operating system for certains classes of massively parallel machines: clusters. It is low-cost and has a decent MPI (message-passing interface) implementation. It also runs on commodity hardware. Don't be surprised if you see the next ASCI supercomputer using Linux as the OS for each node.
You are correct in that Linux is not a good operating system for larger shared-memory multiprocessors. It lacks the fine-grained locking necessary to run the same kernel instance across dozens of processors.
I can't comment on mainframes because I am unaware of their architecture. I do know that high-end UNIX servers and mainframes are different beasts. The former focus on performance while the latter prefers uptime above all. I also believe that IBM, the kind of mainframes, has not used UNIX as their traditional operating system. Thus you are comparing apples to oranges. Linux makes a perfectly decent "mainframe OS" if you are partitioning the machine into multiple virtual machines.
Also please elaborate on "Linux' inferior TCP/IP stack". And "inferior handling of multi-threading on a large scale". Are Solaris light-weight processes any better?
There is another article on ZDNET link that roasts Linux on the mainframe. I think people were too harsh toward sun when they published their report, but the reality is that Linux is not ready for the mainframe YET.
Gee! Someone used Linux and inferior in the same sentence ! Don't you know you will be banned from /. for eternity?
Your sig here!
I work for a large shop and here are my experiences running Linux on the Mainframe.
First, I'm a mainframe person. I like the mainframe. I've used Linux at home for about 6 years so I was chosen to be on a "proof of concept" with running Linux under VM. I've been doing OS/390 & z/OS support for about 4 years. I'm in the "30 & under" crowd and I've seen both the Unix & mainframe side of support.
We've played with TurboLinux, SuSE, & the RedHat beta for the zSeries. We're running zVM 4.2.
First, lots of things work really well. It was strange seeing the normal Linux boot messages appearing in zVM. We've been primarily using the 2.4 series kernel, but we have tested things with the 2.2 series. We've played with Oracle, WebSphere, DB2 Connect, Samba, Apache, IBM HTTPD server. The only technical problem we really had was Samba caused kernel crashes. Some patches from the IBM z/Linux site fixed it.
The biggest problems we have had are philosophical and percepteion based. Here are some of the difficulties:
We had to force our customers to a shared outage window. Even VM needs to be IPLed every year or so. If they can't tolerate a 6 hour window every quarter or 6 months, we won't support them on the zSeries. A second box could make it a true zero downtime machine, but we are initially targeting the low usage, non critical machines.
Lots of people have the delusion that the zSeries processor is hundreds of times faster than other processors. It isn't. It's fast, but not several magnitudes faster than the other processors out there. It's also not designed for heavy computational applications. Don't try, you'll hate the results. It can be done on a limited basis, but don't try and compute PI. It works better on I/O related applications which are traditional mainframe strengths.
A lot of the code on the zSeries for Linux is the first generation to be released there. A lot of the performance perks for that platform are not there yet. If there is enough adoption, ISVs will make the performance better, but right now a lot of them are testing the water.
Some people have the illusion that if you take a piece of crap application on Solaris or NT and run it on Linux, it will run better. The OS typically doesn't make your piece of crap any better.
When people buy an Intel or Solaris server, they typically get the most memory & disk space they can afford. This is the worst thing to do under VM. We had a lot of people want 2GB of RAM and 100GB of disk space. Later analysis showed they could survive with much less memory (some as little as 128M) and used almost none of the disk. The reason for this is simple. Whey you buy a Sun or Intel server, upgrading them is a pain, so you do the pain up front. Under VM you can change the amount of memory & allocate more disk very easily. This was a big learning curve for people, and not just the Unix people. The major difference we found in the memory is because Linux uses it as disk cache. On the zSeries the hardware has lots of it's cache on on it.
People needed to understand they were sharing CPU & memory. Performance tuning has a very big impact. On Intel or Sun who cares if your application is looping endlessly. On VM everyone cares. Lots of our Unix sysadmins really hated this fact and the customers couldn't fathom it. You want to put applications with LOW USAGE on this platform. The idea behind sharing is that nobody needs all of the CPU all of the time. If you run at 100% on a 4-way Pentium CPU, you won't like sharing CPU with dozens of other virtual servers and they won't like sharing with you. This was probably the most difficult thing to stress to the users.
This isn't emulating Intel. It took a while to get people to understand that VM wasn't emulating an Intel machine and that the nice pre-compiled intel binaries don't work. Lots of people went out looking for software from ISVs and the ISVs said "Sure we support Linux". What they didn't say is "We support Linux/390". There is a very big difference. Linux is not just Linux on Intel and it took some education to get this through to the users.
Once we convinced people that it isn't running Intel, they tried to recompile their favorite programs and found out that for some applications a "simple" recompile wasn't enough. I would imagine that the power-pc folks had similar problems, but some programs take a little investigation.
There were some really nice aspects of running on a zSeries.
Disaster Recovery is easier. Mainframe DR has been established for decades and it isn't terribly different with Linux on the mainframe. Much more simple than having dozens of individual machines to recover.
The hardware never fails. It may be expensive, but CPUs have a 30 year mean time to failure, the disk is all raid, multiple IO chanels help ensure there is not single point of failure. Hardware can typically be swapped out without taking an outage. CPUs can by dynamically added.
If you want to copy an existing virtual server and make a test copy, that can be done in minutes. That makes it really nice for developers who want to do the "what if I do this" tests.
VM's programmable operator facility makes for some nice system automation. You can also create Rexx scripts for your operations so they never even need to logon to Linux to do certain work.
Creating a new server is easy. No more running through the install screens. Once you have one customized, just use it as a template for new servers.
We were able to have certain drives shared as read-only across all images. This makes support a little easier. We made one Linux have the drive read-write. When we changed it there, we just unmounted & remounted it on the other images (a Rexx script made that painless) and it was magically everywhere. We can even take down the read-write linux to be sure something isn't accidentally changed. We've been experimenting with sharing lots of Linux mount points this way. We estimate we can concentrate about 100GB down to 2 GB which cuts down the overall cost. The majority of code on all Linux images are the same and will tolerate being shared, so as long as your environment is stable and you do some planning, you can dramatically cut down on disk usage. The amount of disk you save is directly related to the number of images your machine can handle.
The virtual-linux to virtual-linux IP traffic happends at memory-to-memory speed. It's also very nice not to worry about network issues when trying to debug a problem because there is no physical network.
Recovery is easier if an image won't boot. Just attach the drive to another, running image and fix the problem. No need to physically go to the machine.
Sorry to ramble, but this is what we have found. Linux on the zSeries has it's place and does work, but it's not a solution to every problem. Few things are.
Not to be a GNU pundit, but...
> And GNU has nothing to do with porting of Linux to any platform.
... is demonstratably false. Whether or not the individual people who port the Linux kernel to a new architecture are or are not GNU affiliates is, simply put, irrelevant. The first step to getting Linux (or BSD, or whatever) on a new system is porting GCC to its architecture. While this is sometimes done by the people responsible for the Linux porting effort, most of the time this is done by members of the GCC team -- getting a new port to work without breaking all the others requires a great deal of cooperation and support.
Not to mention a working linker. Assembler. The list goes on. Who wrote those?
Lately I've heard a lot of Linux weenies dissing GNU and RMS as out-dated hippies who are prone to overestimating their importance. Unfortunately for these people, GNU is the only reason Linux exists. It's not like Linus wrote his kernel and there just happened to be a binutils chain, compiler, libc, etc just sitting there, ripe for the taking without someone doing a HECK of a lot of work. Probably more work than goes into developing the Linux kernel itself.
Unlike some morons, I'm not here trying to say that Linux/Linus don't deserve a lot of credit; they do. But people who disagree with RMS and his policies often decide that that makes it okay to write revisionist history and downplay his importance to the OSS movement. Without him, there is no movement. Like him or not, don't forget it.
First I must say that my story is a long time ago (like the author of the article). I was an operator on an IBM 3083 17 years ago and left a few months after they had installed VM. We had the mainframe connected to the comanies bottlings plants across the whole country (running system 36 minis) and during the day, especially later in the afternoon most of the various plant's accounts/processing data would come in. The night shift would then start the accounting and processing jobs around 7PM and run them through the night and a few hours before the morning shift came in the Storage backup system would run (HSM) and then during the day the coders would do their thing etc.
The whole point of VM (and the mainframe) was that it is optimised for business systems, AFAIK, and unlike heavy scientific computing loads, there is seldom a need for incredible processing power in the CPU, but there is a need for distributed processes and extremely good I/O since most business tasks are often thrashing around on the disk getting and updating customer/financial info etc.
I don't think the zSeries would be doing as well as it is (eBay, Swedish and Japanese telcos etc) if there wasn't some advantage to this system. Probably, what sways a lot of these deals is that if your machine has any problems IBM will have a technician there pronto and their staff (at least in those days) were very professional and well trained.
Early mainframes were expensive. CPU time metered and charged by the second. Only large corporations or government could afford them. Second generation mainframes topped out at essentially 64k bytes (7074 had 10,000 10-digit decimal words storage).
Solaris, Irix, and HP/UX were designed as big UNIX, (which is something rather different from small mainframe). Each probably based on Berkely UNIX and each trying to distinguish itself as something special. The big UNIX did encroach on the mainframes turf, often doing more, better and cheaper.
"Thank you for your interest. We are performing system maintenance at this time. LinuxWorld will return shortly."
If you still have the article somewhere can you please post a link to it?
Thank you