IBM Saves $250M Running Linux On Mainframes 274
coondoggie writes "Today IBM will announce it is consolidating nearly 4,000 small computer servers in six locations onto about 30 refrigerator-sized mainframes running Linux, saving $250 million in the process. The 4,000 replaced servers will be recycled by IBM Global Asset Recovery Services. The six data centers currently take up over 8 million square feet, or the size of nearly 140 football fields."
A pleasure to work with, as well.. (Score:5, Informative)
Re:Must be SCO jacked up the rates... (Score:1, Informative)
SCO UNIX runs on the x86 architecture, that was the basis of the claim that Linux contained copyrighted SCO code. IBM's Linux on POWER solutions run on, um, POWER :)
Really this is just a slashvertisement - it's great they're using Linux on a mainframe, but they're just IBM mainframes running multiple Linux instances, rather than multiple IBM servers running Linux. Honestly, on IBM hardware, I'd prefer IBM's OSes, but they're marketing the fact that you can have a high-powered, highly efficient, highly available consolidation solution that runs your existing Linux apps
Re:No (Score:4, Informative)
Re:System z Mainframes (Score:5, Informative)
Part of that is because IBM will customize the machines to your heart's content. The sky and your budget are the only limits. They leave a good many of the loadout details (xGB/TB of RAM, DASD storage size, # of CPUs per card, # of CPU cards, even number of mainframes - they can be chained in parallel). You should look at the Z series hardware specs [ibm.com] for the general details and look up what details you don't know.
If you're looking for benchmarks or comparisons to x86/x86-64 or other commodity architectures good luck - they are nearly impossible to find. This is due to the implementations being on entirely different scales. The best comparison you an find is the MIPS per CPU. You can find some slightly stale numbers here [isham-research.co.uk] (BTW: an LPAR [wikipedia.org] is something that's been around on mainframes for several decades - one LPAR can run up to several hundred x86 VMs concurrently).
Re:$250M?? (Score:5, Informative)
Combine IT salary for 3-5 years, power over 3-5 years, etc. etc. and that number makes sense.
Re:single points of failure (Score:5, Informative)
These are machines that don't break, period. We're talking the types of machines that run the major banking systems of the world and the like. They simply do not go down. In this situation, if one of the 133 apps buggers up, it's only that VM that's shot. You just nuke it and restart it, the rest of the machine just keeps ticking along.
Re:single points of failure (Score:3, Informative)
Re:A very confusing endeavor for us (Score:2, Informative)
Re:$250M?? (Score:4, Informative)
Re:IBM's been doing this for-ever, dude. (Score:5, Informative)
Re:single points of failure (Score:1, Informative)
And I think your disaster recovery example is a bit far-fetched
Re:System z Mainframes (Score:3, Informative)
When I started out the "hot" PC, the best you could get, was a 4Mhz Z80 running CP/M. I had one of those at home and at work, I worked the operating system of a very old (even then) CDC mainframe. It was a CDC6600. We had a Z80 emulator that ran on the 6600 and we could emulate a Z80 at about 20 times real time. Not bad, a virtual PC running on a mainframe in the late 1970's
Us software people really need to get off the ball and think of something new rather then just re-implementing 40 year old ideas on ever cheaper and faster hardware.
Re:single points of failure (Score:3, Informative)
From what we were told, IBM z/OS mainframes are the *most* reliable platform to host software services (but of course, they'd say that).
The following is from memory, as best as I can remember it, and may not be 100% accurate:
The 'z' in 'z/OS' stands for 'zero downtime'. z System mainframes are engineered for 99.999% availability, or less than 3 minutes of downtime a year (we were actually quoted 'less than 5 minutes', but (1 - 99.999%) * 365.25 * 12 * 60 = 2.63). Apparently, they quite easily meet this requirement - we were told that it is not uncommon for systems to remain online for 10 years or more without failing.
Up to 32 z System mainframes can be clustered in a 'sysplex'. Each mainframe is divided into several LPARs (Logical Partitions), each which can host several VMs. If an application fails, the automated recovery service will attempt to restart it, either on the same VM, a different VM, a different LPAR or a different mainframe in the sysplex, as appropriate in the situation. It is also possible to host a redundant sysplex in a different site, which mirrors data and which the primary sysplex can failover to in the case of failure.
IBM mainframes are used in many major corporations around the world, particularly those where the cost of downtime is very high (think thousands of dollars a second).
Re:System z Mainframe Specs (Score:2, Informative)
One is that the things you find on IBM's website are designed for CEOs and CIOs who don't really care about technical details -- only "solutions"
The second is that the specs themselves aren't well-defined. As an earlier poster pointed out, you don't buy one of these things off the shelf. You tell IBM what you want to do with it, and you work with them to construct not just a mainframe, but all of the storage and other add-ons that come along.
And finally, the third reason is that the specs don't line up with anything you likely work with normally... (If they did, you'd know where to find them.)
Here are some specs for the z9 Enterprise Class:
http://www-03.ibm.com/systems/z/z9ec/specificatio
Simplified you are looking at 54 CPUs with 512GB of memory.
The CPUs themselves are basically Power6 processors, but thats really simplifying everything down.
Each CPU is actually a "book" of CPUs. Several run at once on the same data. If any disagree, the instruction is rerun on a different CPU. Entire backup books (in addition to the 54) kick-in if a problem is detected.
Additionally, the z/Series comes with a bunch of "Specialty" CPUs. You can get 27 CPUs that do nothing but process Java work natively. Or ones that handle DB2 workload. Or even special processors optimized for the linux kernel. Oh and don't forget the built-in hardware crypto CPUs.
Memory and I/O and Power and everything else works pretty much the same way on a mainframe. And all of it is hot-swapable. (Even the Emergency Power Off switch can be replaced while the system is running).
The hardware specs are impressive, but the biggest deal about these boxes is that they don't go down. Most people I talk to question the idea of consolidating servers into one box because of "single point of failure" concerns. This is where the mainframe shines. These things have MTBF of decades, and will just churn away forever.
Re:single points of failure (Score:4, Informative)
The Linux on these machines is running under z/VM, in multiple virtual machines. When one of them has a software fault, you reboot that one's VM and keep going; the other 132 Linux-running VMs run without noticing anything happened. (It is possible for z/VM to fault, sure. But it's an OS with 40 years of refinement in the "100% uptime" mainframe culture, and its task is just managing the virtual machines.) When something goes wrong with the hardware, the fault tolerance and self-healing features keep things running, and you fix the faulty element with a hot-swap. A properly set-up datacenter is going to minimize external risks, with backup power and such. Proper choice of datacenter location will minimize natural disaster risk.
So, yeah, the big risk is human failure, and these IBM-built, IBM-owned datacenters are presumably going to have extensively trained IBM-employed mainframe personnel, which minimizes that risk.
Now, if some cable company cuts the fiber optic lines . . .
No, You Don't Need Different LPARs for RHEL 4 & (Score:4, Informative)
There are a lot of errors in your comments, unfortunately. Of course you can run Red Hat and SuSE concurrently in a single LPAR under z/VM, and multiple versions thereof. This has always been true, ever since Linux began running on mainframes many years ago. You might want to have more than one LPAR to run more than one version of (first level) z/VM, but you don't need many. Two or three for z/VM and Linux is typical and just fine. And it's not as if LPARs are in short supply on mainframes: up to 60 are available on a single machine (30 on the smaller model), so "spending" 1 to 3 is no big deal.
Re: Investing in new mainframes, come on, get real. It's so easy to find market data because companies like Gartner and IDC publish it, and IBM just announced its 8th straight quarter of mainframe hardware growth, something that hasn't happened since before Y2K. It's impossible to do that with "a few showboat customers."
And no, you simply cannot approach the level of virtualization these machines offer on any other system, at least for typical business computing, and still offer reliable service to users. In fact, in IBM's case many of the software licenses are presumably "free," and they still found big cost savings by taking 4,000 machines down to 30. For the rest of the world the mathematics in such situations are even more compelling.
I was that soldier (Score:4, Informative)
Re:A pleasure to work with, as well.. (Score:3, Informative)
OS/2 was declared dead 10000 times (even by fans) while it was getting some new graphic drivers actually purchased from Sci-Tech software.
If you are a PowerPC (G4/G5) user and in desperate need for non beta, working Java 6, you simply install PPC-Linux and install IBM supported, non beta Java 6 along with CPU acceleration to it. That is the system and OS which Nvidia/ATI refuses to ship a basic binary driver or Adobe doesn't even bother to check for Flash support.
That is how they get that image. In fact, impossible in short term but lets say Apple tells "I am not shipping any OS X updates for PowerPC, buy Intel", it would take 2-3 months for IBM to ship AIX 5L bootable install for PowerPC Macs or start coding mainboard etc. support to Linux kernel themselves.