Slashdot Mirror
IBM Saves $250M Running Linux On Mainframes
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."
We (Bigattichouse's Vectorspace Database) went through their Linux certification (as well as Grid cert), and they were a pleasure to work with - providing expert advice and patience in every step of the process. Not exactly on topic, I guess, but I thought I'd share. They really seem to embrace the engineering and spirit of Linux.
meh
When they came for the communists, I said "He's next door. Take him away. Goddam commies."
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 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 (BTW: an LPAR is something that's been around on mainframes for several decades - one LPAR can run up to several hundred x86 VMs concurrently).
US Democracy:The best person for the job (among These pre-selected choices...)
They're probably computing cost over the expected lifetime.
Combine IT salary for 3-5 years, power over 3-5 years, etc. etc. and that number makes sense.
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.
...si hoc legere nimium eruditionis habes...
Not quite. They are engineered (as they have been for decades) for stability and were designed to handle that kind of load. Its CPU/RAM/storage are redundant, so that if something in the system goes down, new resources are allocated. Additionally, shops will have multiple mainframes just for that kind of redundancy. Its kind of like saying your car is a "single point of failure" - sure, it is, but they were engineered for the purpose of being reliable.
According to another article it is saving the $250M over 5 years, predominately from reduced running costs
A game has objectives and is competitive, anything else is just play
Hi, yes and no. 370 runs 360 code but, as too often even today, people coded to bypass the OS. Old devices, drums, paper / magnetic card readers, terminals, channels, etc. Even todays systems have the idea, VM especially, of 80 column cards, punches, readers, etc and if used correcly they work wonders, trust me, 360 architecture is one of the best even today. The problems is that not too many people any more want to learn the basics, i.e. Priciples of Operation ( any 3xx, a good book to read, required reading, IMHO ). Search on which OS version macro libraries Linux ( 370 HAL ) was first compiled on 360/370, you will be amazed. Emulations in 360-xxx mostly mean address space differences ( 24/31/32/64/.. ) and some added machine code / functionality, done by OS/hardware. And of course a long time trapping the floating point was/is(?) one if you didn't have the fp hardware installed.
Last week, I attended a presentation at IBM's Australian Development Lab in West Perth, where a lot of the z/OS-related code is maintained and developed.
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).
Yeah, if somebody hits the Big Red Switch, there's going to be a problem. But, if they don't, well, it's a mainframe.
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 . . .
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 involved in a migration to the zOS architecture three years ago. I am currently involved in a similar exercise for a British telecoms company whose name escapes me. In both cases the principle was perfectly sound, but the reality rapidly starts to come down to what can be migrated, when, and why. At IBM application compatibility was a major consideration, and ultimately prevented key parts of the system from being migrated. At the current site, surprise surprise, the problems are the same, plus reluctance to do the work (upgrades, work required on the client's part, age of applications and Plain Old Politics). I wish IBM good luck, and perhaps because there is a better integration of operations and systems they might succeed, but I would be willing to bet that by the end of the process, they will have reached about 80% of their target.