Thursday March 01, 2007
Once again, "Mainframe Linux vs. Unix"
I just saw the article Mainframe Linux vs. Unix by Ken Milberg, touting mainframe Linux over Unix. I hope responding to his articles doesn't become a habit I have to maintain, but as with my previous post, this article has enough tilt and mistakes to provoke a response.First, Mr. Milberg says Today's new breed of smaller, cheaper mainframes, paired with the Linux operating system, look like an attractive alternative to Unix on RISC or SPARC servers. One wonders why he feels obligated to specify SPARC, when this applies equally to IBM's POWER - unless this is illustrating a pro-IBM slant (Mr. Milberg edits for IBM web periodicals and is an IBM partner), not to mention the obvious that "RISC or SPARC" is redundant, since SPARC is a RISC chip. Oh well, and we haven't even gotten past the first sentence.
He goes on to say This article compares the features and performance of Linux on the mainframe -- in this case, the IBM System z Server -- and compares it with Unix, in terms of its availability, features and performance. It does nothing of the sort; I wish it did. The article doesn't compare features or performance of mainframe Linux with anything other than by repeating stereotypes. One of the problems with mainframe Linux (and mainframe in general) is that IBM does not publish benchmarks describing its performance, even though they do that with all their other platforms. None of the public benchmarks that are familiar to the open systems world have yet been published. You can only speculate why! Open Systems require Open benchmarking.
Unfortunately, the article just rehashes stale stereotypes about mainframe performance. For example, it refers to "Maximum I/O bandwidth" without quantifying it. Many years ago mainframes certainly had superior I/O bandwidth compared to other platforms, but today's high end open servers use the same high end storage arrays from vendors like Hitachi, Sun, and EMC, and drive them flat out. Sun E15Ks were clocked at over 1 million disk I/Os per second, and over 18GB/second data transfer. I don't think mainframe Linux can get close to that, and possibly not z/OS either, but it could be proven if IBM were willing to run benchmarks in their labs and publish them. Those old assumptions are obsolete: it makes no sense to describe a high-end Sun server as "mid-range" in comparison to a mainframe when it has several times as many CPUs and several times as much RAM. Trying to be fair and not just a vendor zealot, I'm sure the same kind of comparison can be made using IBM's System p RISC machines. Mainframes are no longer the biggest iron in the data center, and the other benefits attributed to mainframes are now shared by other vertically scaled systems that apparently surpass mainframes in power at far less cost.
The article goes on to say Linux on the mainframe becomes a natural evolutionary step for their business' mission-critical applications. Virtually any application that runs Linux on Wintel computers will run on System z, with only a simple recompile. To the first part, one must ask "Why would that be a natural step?". The second part is simply false: while many open systems applications do in fact port easily to mainframe, it's far from "virtually any". Little things like big-endian vs. little-endian crop up, for example. And much of the software you expect simply won't be there, especially for vendor products - the ISV portfolio on mainframe Linux is a fraction of the size of what's available on Intel/AMD platform.
The article goes on to say if a company has a server farm of 200 distributed servers, it can be easily be consolidated into either one or two System boxes, hosting 60-70 Linux servers in a high-availability environment that can scale. Your definition of "easy: will vary, and this is only true if those systems are very under-loaded, as by and large those Linux servers are running on Intel or AMD chips that are faster than System z (rule of thumb: 4 Mhz of Intel == about 1 MIPS of mainframe - as far as such crude rules go). Just do the exact same thing on a 4- or 8-CPU AMD or Intel server using VMware or Xen, at a tiny fraction of the cost, plus the ability to do things like VMotion that don't exist on the mainframe. We at Sun will be glad to sell you a nice server that will do that very well, and so will our competitors at HP, Dell, and IBM too. That's a good thing: vendor competition leads to better price/performance and innovation. By contrast, there is only one vendor you can go to for a mainframe - leading to monopoly price economics.
What else: VM mode allows for thousands of Linux guests per IFL and will probably be the best fit for most installations. VM is definitely the right way to run mainframe Linux if you're going to do that, but scale back your expectations by a factor of 10 or 100. Thousands of penguins per IFL? Aint gonna happen. (If you're wondering what an IFL is: that's an IBM CPU neutered so it can't run z/OS.)
Discussing the UNIX-ish environment on z/OS: The Unix implementation is not native, runs in EBCDIC mode and is just not the most popular of systems in IBM land With that I cannot disagree. It's certified as UNIX, but is alien to the rest of the z/OS environment, and barely used.
Under "Support" the article says If you are already using Linux, why would you want to migrate to Unix? It is more expensive to staff Unix engineers and administrators than their Linux or mainframe counterparts. Uh, well, it could be due to the superior support and capabilities in the Unixes, not a (possibly imaginary) price difference for the admins. Oh, and mainframe Linux engineers/admins are mainframe guys (by definition), and have to have both mainframe and Linux skills. Treat those guys really well if you find them: there aren't that many, and you won't be successful without their skills.
Under "Flexibility" he says Linux, being open source, lends itself to faster innovation, as well as more timely releases of bug fixes. The open source community delivers faster because it does not have to go through the endless development cycles of commercial-based operating systems. Let's point out the obvious here: Solaris is open sourced, so maybe you can apply this problem to AIX. And what about those pesky design and QA cycles. Do you really want to get rid of them? The conclusion is also wrong: look at the innovations in Solaris 10, such as DTrace, ZFS, Solaris Containers, and Fault Management Architecture. There's plenty of innovation in Solaris that Linux people have expressed appreciation of, and sometimes envy.
Regarding "Open", the article says: Anyone that has worked on AIX, Solaris and HP-UX, will tell you that Unix is certainly not Unix. On the other hand, the Linux distributions may have some differences, but the underlying kernel is the same. I'll say it again: Solaris is Open Source. And, the second part is quite wrong. The kernel levels in different distros are different. More important, the administrative tools and conventions are extremely different on the different distros. Even the selection of packages is different. Just as a skilled individual can go between different Unixes, a skilled individual can go between different Linuxes - but it doesn't "just happen" as this article misleadingly states. (For the record: I've worked with Red Hat, SuSE, Debian, Gentoo, Slackware, and Ubuntu - believe me, it's not transparent.)
More misleading stuff about zLinux software being free. Does the article really mean to imply that one can modify source code to WebSphere or Oracle if it's running on Linux? This comes under a bullet section titled "Price", which unfortunately omits the main cost factors: the price of the expensive hardware, the price for the hypervisor, and the price of the service contracts for the "free" Linux. Prepare for sticker shock. Combined with misleading stuff about mainframe security, when that's a property of the operating system (z/OS or z/VM), not the chipset it runs on.
Near the end of the article, the author says Most of the cons of moving to Linux are eliminated by running Linux on System z. Really? How has that been shown? For example, you cannot say that Linux will not scale as much as Unix on System z. Sure I can. It would be interesting to compare this to IBM's AIX/ESA for mainframe if it were still alive, or to the OpenSolaris port if that completes. You cannot make the argument that there is lack of hardware integration and support, as IBM provides that on the mainframe, unlike running Linux on Wintel. For a price, of course. And it's not called "Wintel", when the OS isn't Windows.
To put this in perspective: let's go back to the smaller, cheaper mainframes mentioned in the beginning. That is $95,000 for a single CPU rated at 28 MIPS, no disk, no operating system. Outstanding by the standards of traditional mainframe pricing years ago, but for perspective: I can emulate 30 MIPS of mainframe on my laptop using a program like Hercules, for a cost of maybe $1K or $2K. Let me say that again: I can use emulation software to pretend to be a mainframe - outperforming that $95K IFL despite a 50x or 100x performance hit due to using software to pretend to be silicon - and still outperform that "cheap" mainframe while spending only 1/50th the price.
There may be articles showing that mainframe Linux is a good thing, but this is not one of them.
I'm convinced that at best there is only very marginal applicability for mainframe Linux, as almost anything you can do with it can be done at a fraction of the cost on other platforms. I say this despite my respect for individuals I know who are working on it, and my nostalgia and respect for the platform, especially VM. I suggest to anyone considering this platform: Don't believe me or anyone else. Demand price/performance guarantees, public benchmarks, and real suitability for the applications you intend it for, and disregard the hype.
Posted by jsavit
[Sun] ( March 01, 2007 02:41 PM )
Permalink
| Comments[25]
" ... Linux distributions may have some differences, but the underlying kernel is the same."
Horsehockey! Red Hat and SUSE uses different kernel revisions (RHEL4=2.6.9; SLES9=2.6.5; SLES10=2.6.16; RHEL5=2.6.18). Don't think for a minute these dot-revs don't make a difference. They do!
I work for a company who provides Linux drivers for its hardware. Guess what, every supported Linux distro has a different kernel revision, and therefore has a different driver, with different source required! This is not just a case of regression testing, it is serious custom development for each kernel revision!
As for all of the supposed benefits of the mainframe (reliability, scalability, I/O, etc.) most of these are not requirements for low-utilization Linux servers! These qualities are valuable for big, important applications, like DB2 on zOS for your brokerage account. Not an Apache Tomcat development server.
For larger, more important Linux apps (databases, appservers), there is clustering available (i.e., Oracle RAC) to provide reliability and scalability.
So, the only thing zLinux offers the Linux customer is consolidation. But you can do that on VMware with a medium sized x86 server, and you don't even need to recompile!
Mainframes are not obsolete, as there is still a need for highly reliable business systems with deterministic I/O. But Linux on the Mainframe IS obsolete!
Posted by Mark on March 01, 2007 at 09:02 PM MST #
Posted by c0t0d0s0.org on March 02, 2007 at 02:39 AM MST #
To put this in perspective: let's go back to the smaller, cheaper mainframes mentioned in the beginning. That is $95,000 for a single CPU rated at 28 MIPS, no disk, no operating system. Outstanding by the standards of traditional mainframe pricing years ago, but for perspective: I can emulate 30 MIPS of mainframe on my laptop using a program like Hercules, for a cost of maybe $1K or $2K. Let me say that again: I can use emulation software to pretend to be a mainframe - outperforming that $95K IFL despite a 50x or 100x performance hit due to using software to pretend to be silicon - and still outperform that "cheap" mainframe while spending only 1/50th the price.
I'm convinced that at best there is only very marginal applicability for mainframe Linux, as almost anything you can do with it can be done at a fraction of the cost on other platforms.
---
With all due respect, I think you're completely missing the point.
First, CPU usage:
Try doing anything, anything at all on your laptop with CPU usage > 80%
Then try again on a Z with CPU usage at 98-99%, and notice how it still works.
Second, high availability:
z Systems are reputable for their very high availability, high speed I/O (laptop disks at 7200rpm?) and tolerance to faults (almost every element has a spare waiting to replace the first one should it break) There is a reason why banks don't run on laptops, don't you think?
Third and last, volume:
You're just not using a Z if you have 4 servers sitting in a corner.
95K for an IFL? Yeah right, what's it in comparison with 100 servers and the power, cooling and staff to plug/reboot/hammer them though?
You make some valid points, you fail terribly at some others though.
Posted by Dam on August 02, 2007 at 02:48 AM MST #
Hang on a bit! The point wasn't that you should replace a z800 with a laptop, but that the price performance Milberg claimed for the new z boxes is still far off the pace set by every other platform. Naturally, if I were to replace a z "for real" I would do it with a server product, but even there we have the same problem for z: a low-end server with 10K RPM disks is going to massively outperform that IFL at a tiny fraction of the price.
Remember that I'm jokingly talking about outperforming a z even while emulating it in software. For real workloads, you never would do such a thing, and would simply run apps with the native CPU architecture.
To your other points: sorry to disappoint you, but Solaris can indeed cope with completely saturated CPUs and still give fine performance, using the resource manager built into it. That z boxes can do that is a testament to the resource managers in z/VM and z/OS, but doesn't apply when Linux is the OS running. Don't even get me started on the challenges of trying to run z Linux on heavily loaded machines. Did I mention that I wrote a book on VM performance, and a few years ago co-taught a class on zLinux performance?
The same story applies to reliability: I am not suggesting that your bank run their production transaction processing on laptops! That would be silly. Of course they would continue to use server-quality machines: but they could be servers with far better price/performance than System z. Since there's competition in open systems space, that provides real value to businesses you can't get with monopoly hardware.
Finally, consolidation is a great idea, and if this was 10 years ago, VM would be the only game in town for virtual machines (did I mention that I have deep knowledge of VM, including teaching internals classes and running one of the largest VM datacenters in the world?). But things are different now, and you can consolidate multiple servers onto a single platform using the several powerful new forms of virtualization available today: Xen, VMware, Solaris Containers, Logical Domains. You can do the very same thing you ask for, but the price and performance are orders of magnitude better.
Thanks for posting, though. I always like having a conversation.
Posted by Jeff Savit on August 02, 2007 at 04:35 PM MST #
Sure, Solaris and AIX boxes run fine, but they're just not fault tolerant in my opinion.
Regarding virtualization, IBM's been running "virtualized" OSes for 30 years, and only now do other vendors catch up and go "OI look, new hype, *virtualization*".
LPARs are nothing new here.
I fear that XEN or VM wouldn't be able to handle the same workload as a z9 with multiple LPARs each running z/VM.
It's just about different business needs in my opinion, get "middle" range boxes for medium sized businesses and volumes, get a zFridge for your post-human needs.
Cheers for the reply, glad to see there's discussion to be had.
Posted by Dam on August 03, 2007 at 08:29 AM MST #
To your points: just to add non-Sun examples (to show I'm not being a Sun zealot), Tandem and Stratus for years had high availability features much more than mainframes, much more than Z. For Sun, I think you should look again: current Sun servers have things like instruction retry that used to be mainframe only. Solaris has predictive fault management architecture (FMA) that takes components offline before they fail. Having worked extensively in both worlds, I have to say that it's hard to make point for point comparisons because the two worlds do things differently, but you can no longer claim without proof that z owns the reliability title. Things have changed (and btw, I recall plenty of OS/390 and VM crashes. Everybody crashes some times!)
By the way, neither z/VM nor zLinux have anything like FMA. Linux on Z doesn't even know how to handle common problems like "I have an error on this part of the disk and need to assign an alternate track". When you look at reliability you can't just look at the box: it's the total of the box, the OS, and the app. On Z, that really means z/OS, not z/VM with Linux (Alas - I really like VM much more, even though I did internals work in both VM and MVS flavors).
You're right that IBM has been doing virtualization 30 years, and credit to them for their innovation. I first worked as a VM systems programmer in 1976, so I know they were there (VM/370 Release 3). The point is that things have changed, and they are no longer the only game in town. In many ways, mainframe VM (now called z/VM) has been leapfrogged, and lacks features available in, for example, VMware. IBM, for example, is trying to catch up to VMware for features like VMotion and memory ballooning.
Basically, anything you can do with zLinux can you can do for a fraction of the cost with PCs and VMware or Xen. Really. And you don't have to port code or go looking for RPMs that don't exist on Z. Forget about consolidating Windows apps on zLinux - that's a port not a conversion. And guess what - over 80% of VMware consolidations are Windows. In that market, zLinux is at best marginal - file and print is what people do, and even that's hard on Z. That Z with multiple LPARs costs a few million bucks; the x4600s that would run rings around it would cost a tiny fraction of it...
Thanks for responding - it's good to have a dialogue. Cheers, Jeff
Posted by Jeff Savit on August 03, 2007 at 02:09 PM MST #
Posted by brindleoak on August 05, 2007 at 12:07 AM MST #
Hi brindleoak,
My goodness- we have a little party going on now!
I certainly agree that it can be "tricky" to get things to work in the real world - on both mainframes and other systems.
I _must_ point out, though, that I'm at Sun Microsystems, not Microsoft. Even though we're on less contentious relations now, it would not be the recommendation of people at Sun that you use SQL Server or Windows for an enterprise application. We would recommend Solaris, which is definitely an enterprise OS, and one of the databases that runs on it, such as Oracle, MySQL, PostgresSQL, and indeed DB2 itself, if you wanted the database you were familiar with on mainframe.
regards, Jeff
Posted by Jeff Savit on August 07, 2007 at 02:30 PM MST #
I find all of the comments interesting. By the way a single IFL on a z9 is 580 Mips, not 28 mips. The 28 mips is the lowest you can configure for a general purpose processor. IFL's run at the full capacity of the processor.
Regards...
Posted by Don on January 19, 2008 at 05:44 PM MST #
Don, you are right that a z9 EC engine is rated around 580 MIPS, but it also costs a lot more than the 28 MIPS $95,000 z800 model I was citing as the lowest entry cost for going an IBM mainframe. And, a z9 BC has a lower MIPS count, so it all depends on which machine you want to compare and price.
Note that when not running an IFL, a z9 EC single CPU system will set you back about $900,000 for those 580 MIPS, plus $2K or $3K per month for maintenance.
Then add the costs for DASD and software, which is going to be much more expensive than the CPUs. Monopoly prices apply just as much to the mainframe software market as they do for the mainframe hardware market.
Just for the fun aspect: on a 2 year old desktop PC, I've been able to run Hercules with instruction kernels exceeding 70 MIPS! 70 MIPS of emulated mainframe on my PC (about $1K on today's market) compares pretty favorably to 580 MIPS on the "real thing" for over 100 times as much money.
I could easily run one simulated mainframe CPU cruncher instance per installed CPU, and get a current 4-way Intel or AMD server to exceed 250 MIPS.
Let's not forget, the point of showing how much mainframe I can +emulate+ purely in software on a modern CPU is to illustrate how far off the pace the mainframe is compared to other CPUs. In real life, we would run Linux or Solaris applications natively, not emulated at a cost of 10^2 native instructions per emulated instruction.
Posted by Jeff Savit on January 19, 2008 at 07:42 PM MST #
I believe you're still misunderstanding the capacity of an IFL engine.
As a previous post pointed out, the IFL engines running Linux aren't capped - they run at the full native speed of the processor.
There's no such thing as a 28 MIPS IFL processor - it would in fact be the 580 MIPS cited, and that capacity indeed costs $95,000. The 28 MIPS engines you refer to are only available as so-called "general purpose" engines (the engines that run z/OS).
Another dimension you don't mention is that IFLs move up when you do your processor upgrades.
Let's say you spend your $95K for an IFL on your z9 processor. A few weeks ago, IBM announced the next processor family, the z10, which features 4.4Ghz processors having over 900 MIPS per engine. The $95K you spent on that prior generation IFL entitles you to run an IFL on your z10 at no additional charge, in this case giving you substantially more capacity essentially free.
Posted by Vince Re on March 19, 2008 at 08:47 AM MST #
Hi Vince,
I guess this blog touched a nerve. The original post is over a year ago, and it still draws comments.
I get it, really. An IFL is not performance knee-capped and includes upgrade entitlement. IBM has such a high margin on Z that it is willing to give away processors crippled to not run z/OS in order to attract business.
But, did you see the estimate reported at SHARE that a single IFL engine costs $500K once you factor in disks, software licenses, maintenance, and (I guess) RAM? That was reported on the mainframe Linux mailing list. Look, just licensing z/VM is going to be about $20K (higher if that's the only CPU licensed, IIRC), and licensing Red Hat or SuSE is going to be $11K, $15K or more for that CPU depending on support level. So, the $95K (which I think is $125K when not z8xx) starts growing.
And lets come back to the point I made back in January: the reason I brought up the emulated MIPS is to show the orders of magnitude difference in price/performance. If I can +emulate+ one or two hundred MIPS on a 2 or 4-way Intel or AMD server that costs a few thousand dollars, then that means the native performance (running applications natively on Intel or AMD) is HUNDREDS of times higher. Even with the discounted price of an IFL engine. When an IFL provides several THOUSAND MIPS for a kilobuck, then we're talking something competitive.
Posted by Jeff Savit on March 19, 2008 at 04:10 PM MST #
Sun colleague Patrick McGehearty sent me the following cogent discussion and said I could add it to the comments:
The emulation example may not be fully convincing since there are so many ways to do emulation. And laptops are also a distraction. Let's go back to the crude rule of thumb: 1 Mainframe MIPS = 4MHz on Intel. That's probably the right order of magnitude, provided you have comparable memory, IO, etc.
So when we look at a 900 MIPS mainframe processor that should be in the range of a 3.6GHz Intel processor, plus or minus. While there's a lot of fudge in that estimate, the bottom line is that a mainframe processor is NOT dramatically better than the comparable generation RISC or Intel or AMD processor. And it may even be slower. If it was dramatically faster, IBM would be bragging about it with Open benchmarks, like they do with their Power6 processor.
On the cost side of things, let's skip the laptops. Those systems have trivial IO and memory and aren't designed with a primary focus on reliability. Instead, look at the serious top-end servers offered by Sun, HP, and IBM/Power6. All of these systems have Unix-derived high reliability options, with track records for working on reliabliity going back at least to the early 90's. Yes, they weren't up to mainframe standards 15-20 years ago, just as Windows might not be today, but Solaris/Sparc, at least, improving and can match up well on both the standard measures and in real world production behavior.
Without a current price book I can't be exact in comparing the best cost/performance complete mainframe from IBM with one from Sun. However, I'd be surprised if Sun did not have at least a 5 to 1 cost/performance advantage if you look at the total cost (HW, SW, power, cooling, support). In some cases, I'd expect 20 to 1. The idea that a single processor system could be worth near $1 million is just ridiculous, when you can buy a well configured 4 processor RISC or CISC (and have vendors compete for your business on price) system that can easily handle several times the load for well under $300K.
For legacy applications where the cost of porting is high, mainframes have a place. For anything else, I can't see it.
Advice to mainframe admins: if you are smart enough to learn mainframe management, Linux/Solaris/Unix management is well within your ability to learn. Unless you plan to retire soon, start expanding your skills because the growth potential of the mainframe business looks really poor to me.
Posted by Jeff Savit on March 20, 2008 at 10:00 AM MST #
"What else: VM mode allows for thousands of Linux guests per IFL and will probably be the best fit for most installations. VM is definitely the right way to run mainframe Linux if you're going to do that, but scale back your expectations by a factor of 10 or 100. Thousands of penguins per IFL? Aint gonna happen. (If you're wondering what an IFL is: that's an IBM CPU neutered so it can't run z/OS.)"
Actually you need to scale those expectation back by a factor of "thousands" comared to today's x86 hardware. The IFL we have (all resources allocated to a single VM) can't keep up with an x86 server from 2 years ago in our testing. Tasks that take the IFL an hour to finish can be done in 2 minutes on one of our Xen guests (sitting on the same host as a DB server no less). Also, as far as IO performance is concerned - we're getting close to 3 times the throughput even on the internal RAID arrays on our x86 servers as we get on the IFL with internal MF disks (my guess is the CPU is the biggest limiter here). Don't buy the hype without making IBM prove the thing will do what they say it will - with YOUR WORKLOADS.
Posted by Josh on June 04, 2008 at 03:34 PM MST #
Josh,
Thanks for your comments, which I definitely agree with. That sounds like the results from Clarkson U, where low-cost Xeon and even Pentium III outperformed their System z, using Xen for their hypervisor.
If you can share your results, please send them to me. I always like seeing actual data.
regards, Jeff
Posted by Jeff Savit on June 05, 2008 at 07:08 AM MST #
Just to make it more fun, what your opinion about Solaris now available for z ??
Posted by Tore on October 28, 2008 at 02:57 AM MST #
Comment about the one million cpu.
Yes, that is to expensive, but fact is that
if you already have a mainframe, then
it make sense and is cost effective to
start one or more IFL:s. And as someone said above, thousands Linux per IFL is not reality, it's more like 20-50 depending on load and purpose.
I know a big company having two mainframes and that runs zVM and zLinux at about the same price or lower than std racks. But it all depends on the mainframe already beeing there, and what prices you can get from IBM.
Posted by Tore on October 28, 2008 at 03:07 AM MST #
One IFL almost = 3.6 GHz ??
Yes, if counting that one only and ignoring the rest.
In a z9 or z10 there is 8 IO cpus dedicated to take care of IO only, and they are the same kind as the IFL (speed and so on).
So when running a Database server you actually have access to 9 CPU:s with this speed. And even more if you count the two or three power cpu:s in each OSA(network adapter).
So you can't just compare the speed of x number of IFLs to x number of x86 cpus. It all depends on the type of load.
And there is load that because of this is cost effective to run in z box.
Posted by Tore on October 28, 2008 at 03:15 AM MST #
Oh yeah, having OpenSolaris for z makes an interesting proposition. Here's how I take it: we at Sun love Solaris and would rather people run it than any other OS, Linux included. So, if some people deploy OpenSolaris on z instead of z/Linux, then we think that's pretty cool.
At the same time, we know there are far better platforms to run Solaris than on z: On SPARC, Intel, and AMD you have the full, tested, and supported implementation on far better price and performance (with vendor choice and competition), and with a massive portfolio of products and services. Those platforms are by far the superior business solution, including for consolidation of virtualized instances.
But, if you have spare CPU cycles on a z you already have, don't plan to reduce it, and want to get experience with OpenSolaris there - and bring a new form of competition to a place that (since AIX on mainframe is long gone, and UTS barely exists), then that can be a good thing.
Posted by Jeffrey Savit on October 28, 2008 at 06:49 AM MST #
(this is for Tore's post starting with"Comment about the one million cpu.")
I partially agree with you: if you already own a box, and it has excess capacity, and you have staff with the required specialized skills, you may as well populate it with more work. But don't let it lead you to committing more money to a more expensive platform.
Keep in mind the "sunk cost fallacy" (Google that term!) and realize that you shouldn't be pouring more money into an expensive item just because you already expended a lot there.
Posted by Jeffrey Savit on October 28, 2008 at 06:58 AM MST #
(This is for Tore's post beginning "One IFL almost = 3.6 GHz ??")
First, a reminder that the origin of the 4:1 rule of thumb that derives that 3.6: it comes from a well-known mainframe performance expert, not from me. As with all rules of thumbs it should be taken in context.
While it's true there are other co-processors on a z, it's easy to mythologize them. All modern servers have auxiliary hardware that offloads I/O processing from the "regular" CPUs. As shown in the June 4 comment from Josh, current x86 servers have been seen to completely smoke mainframes even doing I/O. So, this business about "extra processors" doesn't translate into actual performance that makes up for the shortfall in CPU performance and the extremely high prices on z.
BTW: My personal testing with OSA leaves me unimpressed compared with the GbE and higher available on any modern computer.
Posted by Jeff Savit on October 28, 2008 at 07:38 AM MST #
We have two IFLs currently pushing 16 guests on zVM. Anytime one of them goes CPU crazy and starts reporting that it is using 100% CPU (via top), the other guests start to suffer and we get support calls saying applications are running slow. Magically the calls go away when we quit the CPU intensive processing.
Posted by Anonymous on December 18, 2008 at 03:10 PM MST #
There are several things that have to be watched out for: One is that "top" within the Linux guest is totally unreliable for determining the CPU utilization when running in a z/VM guest. There was recent argument about this among z/Linux users, but even at recent Linux kernel levels the number reported by "top" may not be anywhere near reality. That's something to think about when considering z/Linux...
The other thing to know is that there are several ways that a z/Linux guest under z/VM can go into a hang or unresponsive state. The most common is caused by going into a VM scheduler queue called an "eligible list" designed to prevent excessive storage (RAM) overcommittment. A guest in that queue is not serviced at all - even for long periods of time. There are things you can do to alleviate this, but you need to know how to tune VM.
On the other hand, the problem may be as simple as setting priorities ("SHARE" values) for the guests. Again, having the right data and knowing how to interpret it is key. This is not a simple environment to do performance work on.
You need a REAL performance monitor to do this correctly. I absolutely do NOT recommend using z/Linux, but if you do, you should get the products from Velocity Software. Tell them I told you :-)
Posted by Jeffrey Savit on December 18, 2008 at 05:53 PM MST #
Hi Jeff:
I used to work in Finance in that same large brokerage firm as you that no longer exists.
My question is more specific. If I were to rehost existing mainframe applications on a beefed up Unix Solaris platform what is the ball park figure that I can expect to pay for everything to be up and running?
Posted by Adrian Miranda on January 26, 2009 at 02:35 PM MST #
Hi Adrian,
I'm going to make a very serious answer, and I'm not at all flippant: the answer is "it depends".
Several parts of the answer:
1. How much machine resource is needed? That's the easy part. You can crudely estimate for a first cut, and then refine as you get a working prototype of the migrated application. It will be a lot less money, as I know from experience.
2. The big part: how "as close to identical do you need?" and "how big is the application in terms of software complexity, and how hard will it be to migrate the application?" So, if it's a small FOCUS or SAS application, it's going to be a walk in the park (move the data, minor tweaks to the FOCUS or SAS code). If it's a simple batch application for a very few reports in COBOL based on flat files, also will be easy (move the data, minor tweaks to COBOL source). If it's a sizeable CICS application with hundreds of transactions, thousands of COBOL source files, some BAL modules, many DB2 tables and VSAM files, thousands of tapes out on a silo, etcetera, then it's a different story entirely. It's doable and can save a LOT of money, and I would recommend one of Sun's partners that have a thriving business doing exactly that (like with Unikix), and with tremendous cost savings to customers, but there's no way to answer a "how much does it cost" via a blog entry!
E-mail me, and I'll be glad to talk with you and see if I can help. We can also trade war stories about the company that no longer is there... :-(
Posted by Jeffrey Savit on January 26, 2009 at 02:52 PM MST #