Question

I work for a large corporation that runs a lot of x86 based servers on which we run JVMs.

We have experimented successfully with VMWare ESX to get better usage out of our data center. But these still consume a lot of power per processing unit.

I had a mad idea that we should resurrect mainframes, we could host either lots of JVMs or virtual machines.

Has anyone tried this? Are there any good cost-benefits?

Do you lose flexibility? E.g. we have mainframes in other parts of the company but they seem to have much more rigid usage of the machines.. lots of change control, long lead times etc

Was it helpful?

Solution

All this assumes you’re talking about Java on Z/OS and not running Linux VM’s on the mainframe to take advantage of the cost savings that come with fewer machines.

My thoughts on virtualization are at the end of this and it’s probably the route you want to look at but I’ll start out with Z/OS since it’s what mainframes are traditionally associated with and what I have familiarity with. I have some experience with mainframe Java.

The short answer is, it depends, but probably not. What exactly are your applications? The mainframe is a difficult environment compared to x86 servers. If you're running I/O-intensive workloads under something like Websphere, it might be worth it, assuming your mainframe is underutilized.

In my experience, Java is horribly slow on a mainframe but that’s because the system I used was set up for developer flexibility rather than performance. That just goes to prove performance tuning on the mainframe is usually much more complicated then on an average server since mainframes will be running many more workloads then a generic x86 server.

Remember that the mainframe is designed primarily for I/O throughput and can outperform any normal x86 server at that. It was not designed to do a lot of computationally intensive calculations so won’t outperform a small cluster of x86 servers if your doing a lot of math.

The change controls on mainframes are there for a good reason - if one x86 server has a problem, you reboot it. If a mainframe has a problem, every second that it’s down is costing the company money. You also have to take into account any native code your apps depend on or third party libraries that may use native code. All that code would have to be ported.

Configuration of a mainframe also takes a lot longer on average then on an x86 server. I would suggest that, if you want to seriously look into this, you make a better business case than power savings, such as tight integration with current business apps and start out small either with a proof of concept or a new application. One that is not business critical, that can be implemented to take advantage of the mainframes strengths.

IBM mainframes can also run Linux in either native mode or a virtualized environment similar to VMWare. Unless your company is the exception to the rule, your Linux instances would run as virtual machines. I haven’t had much experience with this but, if your app depends on no native code and runs under Linux, it would probably work on a mainframe running Linux. For more info about Linux on mainframes see this link.

OTHER TIPS

IBM makes a special Java co-processor that you should seriously consider. I would not run Java on the general engines as this may increase MPU charges for licensed software.

We have extensive experience running Java under Windows, Linux and on IBM SystemI (or iSeries, or AS/400, depending on IBM's mood that year) minicomputers. It is my opinion that the mini-computer platform seems to deliver much less bang for your buck against modern multi-core x86 CPU's.

Note that Java benefits more readily from having multiple cores available than typical software today, because of it's inherently multithreaded nature - this would be even more true as you run multiple JVMs.

That said, you will typically be capable of getting many more CPU cores available with better bandwidth to access memory on a mini or mainframe, and better throughput on disk subsystems (overall) so these systems may very well scale much better as you toss more JVMs on them.

IBM allows this. Some of their mainframes can hold Java accelerator processors that run the bytecode natively for more performance. They also have DB2 accelerators, and possibly some for XML operations.

I've never gotten to play with any of them, but I'd sure love to.

Though I've been in the Industry since 1975, I'm no longer sure what a "mainframe" is. My current development machine has four 3GHZ processors in it, 8GB of RAM, and 750GB of disk space (RAID 1, so it's really double that), and two 19-inch flatscreen monitors.

That's because I'm there on a contract. The employees all have much more powerful boxes than mine.

I understand that the server machines, especially the database servers, are much faster.

Mainframe?

Depending on you workload this is worth looking at!

There are a bewildering number of options available to you just using the IBM hardware:

  1. Its definately worth considering the add on java processors. (these are actually not that different form the standard cpus its just they are restricted to java jvm workloads -- and -- most importantly are excluded from cpu based software license pricing).

  2. You can run multple Linux VMs each ruuning thier own Java app.

  3. You can run multiple native VMs running thier minimalist operating system used to be called DOS but they change the name every couple of years. The software licenses are cheaper than the main OS, but it has very limited functionality which turns out to be an advantage if you are running self contained applications.

  4. You can run in the monster z/OS environment either:-

a. Within USS (Unix System Services) which is pretty much a full UNIX OS running inside the parent z/OS.

b. Run your java app in its own started task (== unix daemon).

c. Run your app inside CICS. (Probably not as you need to use CICS/Java API where you would normally use Servlet/J2EE APIs so you app would require a rewrite.)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top