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."

6 of 274 comments (clear)

  1. 2000 sq feet per small computer? by Anonymous Coward · · Score: 5, Interesting

    The article says that the data centers required for the 4000 "small computer servers" aggregate to about 8 million square feet. It takes IBM 2000 square feet to house a small computer? Also, saving $250 million suggests that it costs them something over $60K per "small computer" even ignoring the price of the new mainframes. Amazing.

  2. My employer recently 'consolidated' too. by MarcQuadra · · Score: 5, Interesting

    My employer recently 'consolidated' their server farm too. We used to have a room with fifty aging Dell PowerEdge servers, each running independently, requiring massive support, cooling, and electricity.

    Now we have ten VM servers running all the migrated services, PLUS a room with about fifty aging Dell PowerEdge servers, each running independently, requiring massive support, cooling, and electricity.

    I never thought 'consolidation' would require so much more space, electricity, air conditioning, and upgrades to core switches and UPS units.

    --
    "Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
  3. IBM's been doing this for-ever, dude. by crovira · · Score: 5, Interesting

    I had to maintain some software that was running on a aging 370 mainframe. The 370 was emulating a 360 which was emulating a 1401.

    It was pension and payroll software and it was legally blessed.

    It was such a frigging song and dance trying to get anything done that it was cheaper and faster for the company to emulate their butts off rather than trying to go through the management and the unions and the employees.

    But I did learn about optimizing instruction fetches by scattering the compiled code around the circumference of a magnetic drum so that the drum would have rotated around beneath the read head in time for the next instruction.

    Try and tell that to the young people of today, and they wont believe you, eh Obadiah?

    --
    MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
  4. A very confusing endeavor for us by DutchSter · · Score: 4, Interesting

    Where I work we currently run two mainframes in a sysplex environment for all the core transactions. It's a very optimized environment and handles millions of financial transactions a day. In mid-2006, IBM started giving us zLinux engines to "try out" and they gave us all of the software we needed to make a go of it. Kind of like a playground drug dealer, they hoped that by giving us a bit for free we'd get hooked and become dedicated customers. The problem was, for the type of workload that typically runs on our servers (high CPU, moderate I/O) we were experiencing poor performance on the mainframe VMs. IBM sent all their engineers out to help make tweaks and tune all sorts of things. Despite all the tuning and tweaking that took place, we could never get a single engine to perform better than a $5,000 server. Keep in mind that a single engine was retailing for around $80,000 after discounts.

    We did some calculations and determined that for the price of a zLinux engine we could buy an entire rack of high-end HP servers that would outperform the single engine by a factor of 200:1. Again, maybe it was just the workload we were doing, but even IBM couldn't figure it out and our server work profile isn't exactly uncommon. Granted you can cram a lot of guests onto a host system provided that none of the guests want to use more than 10% of their CPU at any given time, but that defeats the purpose. I could probably run a VMWare host with 100 guests and call it a success, provided they all sat idle.

    It was kind of funny because the IBM engineers would shake their heads and admit that for our workload it just wasn't going to work out. Then the next week the sales guy would call and ask if we were ready to buy that third mainframe since he just read the engineer's report and our visit was obviously a smashing success.

    I'm not knocking the whole Linux on the mainframe concept, I'm just sharing our experience and how the whole thing seemed to be like someone in IBM Marketing declared "we need to sell Linux on the mainframe" and the Dilberts were forced to sell a product that worked about as well as a chocolate fireguard. It was a very awkward experience and even the IBM engineers seemed like they were stuck in an uncomfortable position of supporting sales for a product that even moderately demanding customers wouldn't be able to run with.

    Personally I consider Linux on the mainframe to be on par with running Linux on an iPhone. Sure you probably can, but does it actually do anything uniquely useful for the business? I have a hard time selling technology to the CIO on the grounds that because it's Linux it's a good business decision regardless of the context.

  5. It's just an endless cycle by ogren · · Score: 5, Interesting

    I still haven't seen any conclusive evidence that Linux on mainframe is a good idea. I'm sure running 30 new mainframes is going to cost less than 4000 aging servers. Just about anything would be less expensive than 4000 aging servers.

    But I bet that a small farm of modern medium sized servers running Linux on VMWare would be even less expensive. Or Solaris/Niagara. Why would you want to run an open source operating system, whose major benefits are openness and affordability on the what is literally the most expensive and most proprietary computing platform in the world!

    These server consolidation projects are just giant boondoggles spawned because the server sprawl finally got insane. It's an endless cycle:

    A. Giant server consolidation project that takes 4000 servers down to 30 servers.
    B. Department B complains that Department A's application keeps hanging and consuming all of the CPU. They demand their own hardware "for availability reasons".
    C. Vendor C demands dedicated hardware for licensing/capacity planning/supportability reasons. Rather than constantly bicker with the vendor over supportability they get dedicated hardware.
    D. Department D complains that the IT department is charging outrageous prices for time sharing on the mainframe. After all a dedicated server only costs $XXX.
    E. Suddenly there are 4000 servers again.
    F. IT department spends some insane amount of money on infrastructure to manage the 4000 servers.
    G. IT department budget gets insanely large trying to manage that much stuff.
    H. Some CIO gets the idea that all of this money managing servers is ridiculous and we should do a server consolidation project.
    I. IT department spends an even larger amount of money on the latest super high availability gear and consulting services so that the can run 4000 commodity servers inside a few big servers. All because it will "cost less to maintain".
    J. Go back to A.

  6. Amplification re: CPU Sparing by BBCWatcher · · Score: 4, Interesting

    Actually, on a System z9 EC (Enterprise Class), a single CPU chip failure is not a "Call Home" repair event. Only the second CPU chip failure would result in an automatic call, while your business keeps running of course. (There are a minimum of two spares in each machine.) The average time to first failure for a particular machine is somewhere in the many decades range.

    OK, just for fun (because it never actually happens in the real world), what happens with a triple failure? If you happen to have a "fully configured" mainframe -- all processors turned on -- then.... your business still keeps running. Yes, the system might lose some processing capacity, but it keeps running. The higher priority stuff (from a business view) takes precedence automatically, and life goes on. This is all on a single machine still.

    If you've got an S18, S28, S38, or S54 model, then, at your business's convenience, the faulty hardware can be replaced. (You might do this at night, for example.) The repair technician tells the mainframe to "evacuate" memory on a portion of the machine while the OS and applications keep chugging along, possibly with reduced capacity, often not. (Depends on what configuration you choose.) When the evacuation is complete, the technician can pull a processor/memory group (called a "book"), insert the new one, bring the new one online, and... everything still keeps running. Again, this is all on a single machine -- no clusters required for any of this.