
I’m just about old enough to remember the tail end of the “downsizing” craze where IT departments became obsessed with the idea of distributed computing and cheap, commodity hardware. This followed the shift from mainframe to mid-range, where the former was deemed terribly uncool and ushered out in preference of a diverse collection of largely incompatible and still somewhat expensive proprietary minicomputers. Many of the later minis purported to be “open” and offered some promise of interoperability/portability, but they rarely delivered much in this sense. Similarly, commodity - typically x86 - hardware promised to be cheap, but for medium to large installations its use often results in unmanageable sprawl and underutilisation, all as part of a wider spectrum of general inefficiency that contributes to hidden and unanticipated costs.
Fast forward to 2009 and you’re lucky if as a geek in gainful employment you can exist a single day without hearing yet another tale concerned with the wondrous Cloud. There are those, myself included, that have likened the Cloud to the fabled (I’m not that old) mainframe computer bureau service of years gone by. Of course very little is actually new, and when people got excited about the advent of UNIX clustering I couldn’t help but think “(very) poor man’s VMScluster”. More recently with the virtualisation frenzy I was immediately minded of the IBM hypervisor technology, VM, that has been quietly managing heavyweight workloads such as banking systems and keeping them out of the news for the last 30+ years.
Of late there have been a growing number of reports that the mainframe is making a comeback, that sales are on the up, and you can pick up a brand new system - an entry level IBM z/10 - for around $100,000. They’ve also shrunk in size, and as far back as the late 90s deskside systems were available that would happily run from a domestic power outlet. But aren’t they slow? Well, no, not any more, as a current z/10 CPU packs 4 cores and clocks at speeds upwards of 4.4GHz.
One of the biggest breakthroughs, however, has been the availability of Linux on IBM mainframe. Making it finally possible to leverage the wide ranging benefits of not only Linux but an immeasurably large ecosystem of F/OSS tools, middleware and applications etc all running on top of monotonously reliable, highly consolidated and dynamic infrastructure.
They are smaller and cheaper than ever, have legendary reliability, can consolidate like nothing else and now run Linux. Perfect, right? Well, I still had some concerns and needed convincing of the overall mainframe value proposition. Fortunately on Wednesday I was able to make it along to a Linux Live workshop at IBM Bedfont Lakes, where some of these concerns were addressed and I got to learn more about the practicality of running Linux on mainframe.
Ease of management
Isn’t the mainframe environment arcane and hard to manage?
At the hands-on workshop we were given access to a mainframe over in New York, taught z/VM (current version of the IBM hypervisor) basics and how to install Linux within our freshly created VM. In one day. Yes, z/VM is somewhat arcane and how could it not be when you consider VM has been around for over 40 years. However, once you get used to IBM parlance (e.g. a disk is called a DASD and you don’t boot, you “IPL”) it’s actually quite simple [1]. Possibly even elegantly simple. Of course there is more to z/VM than the very basic administration skills we were taught, but I’m reasonably confident that the more advanced features would be easy enough to get to grips with. And once you have the distro installer running it’s Linux from that point on - no different than if you were running Linux on your PC or netbook etc.
More recent z/VM developments include facilities such as virtual network switches that are implemented in memory, thus offering extremely low latency virtual network links between VMs and physical network interfaces. Combine this feature with possibilities such as firewalls that are implemented via z/Linux VMs and the mainframe is starting to look like a data centre in a box. Making the efforts of others who are trying to build exactly this via commodity hardware in shipping containers appear somewhat clumsy. That these in-system virtual network switches are managed via the same interface as VMs themselves can only serve to reduce management complexity.
Lock-in
What about vendor lock-in?
Well, this depends on how you view the composite platform and I’ve come to regard z/VM as a toolset for managing the underlying hardware. The fact that this combination is completely proprietary and there is, as far as I am aware, no direct competition means that you are to some extent at the mercy of IBM when it comes to pricing, support, upgrades and discounts etc. However, if your workloads run on top of Linux and you treat z/VM as simply an extension of the hardware your switching costs should be kept at a minimum.
This is a very different situation to 10, 20 or 30 years ago where mainframes would be running applications on top of an O/S such as MVS and built using CICS etc. Then your non-IBM options were few, if you had any at all. Whereas now, through running workloads on Linux it should be relatively easy to migrate to a different architecture, providing don’t make use of proprietary Linux applications that are only available for z/Architecture or dig yourself a hole by investing heavily in z/VM-specific operational support systems and processes.
Cost
They may have come down in price but don’t mainframe CPUs still cost orders of magnitude more than commodity processors?
The cost consideration is perhaps not so simple… I’ve seen some great TCO figures from IBM in support of the mainframe, but cannot help marvel at the simple cost of a single mainframe CPU. Although I am coming round to the idea that the mainframe in many cases may still work out cheaper than commodity hardware, and here’s why:
RAS
You’re going to be hard pushed to beat the mainframe in this respect, and reliability, availability and serviceability all contribute to the total cost of ownership. You can engineer for this with commodity hardware but the costs soon add up… Whereas this stuff is built into the mainframe’s foundations and doing things like swapping CPUs whilst booted and running workloads, or clustering multiple machines into a single system image is business as usual. And when you purchase a mainframe you are not just acquiring a system, but rather instead a commitment to a guaranteed level of service. The cost model and support framework is not the same as when you acquire commodity kit and go about bolting on support, and the opportunity for vendor finger pointing born out of the associated relationship complexity is much reduced.
Consolidation
It’s hard to compete with hardware and hypervisor technology that has enjoyed a very close relationship and evolved together over 40+ years. Intel and AMD may be adding instructions to their CPUs to better support for virtualisation, but z/Architecture and z/VM have been designed to fit together hand-in-glove. Something that is made apparent when you hear of single image systems playing host to tens of thousands of Linux virtual machines.
Performance
The “general purpose” CPUs may be damned expensive, but the mainframe is not constrained by a Jack of All Trades CPU that must service every aspect of the system. Instead it benefits from assist processors that handle things such as I/O and cryptographic operations, thereby freeing up the mainframe’s main CPUs to concentrate on the meat of the matter. How else do you think an early 80s mainframe managed to service 500+ concurrent users with its single CPU and 16Mb of RAM? Oh, and with current hardware you need to take into account things such as the masses of cache available and hardware support for SMP. Performance does not equate to simply the number of cores multiplied by clock speed…
Conclusion
As you step back and look at the bigger picture Linux on z/Series + z/VM starts to look increasingly attractive. The industry’s eventual acceptance of F/OSS and widespread moves to standardise on the Linux O/S, coupled with a shift to service-oriented IT, increasingly constrained budgets, a heightened sensitivity to green issues (power consumption) and a ceaselessly growing dependency upon on-line services all serve to strengthen the case. We may be about to witness the mainframe’s second coming.
I still need convincing that the mainframe can offer best price/performance for everyone, and suspect that it will be most attractive to traditional IT departments that often have demanding SLAs, multiple environments which will benefit from rapid cloning and deployment and roll-back agility (e.g. Dev -> Test -> QA -> Live, and Live -> Upgrade Test etc), and perhaps where many VMs will be running at lower utilisation. I would be hard pushed to imagine it to be cost effective to host, say, a farm of high transactional volume web proxies and static asset servers all running under Linux on mainframe. Although I’m happy to be proved wrong.
There is still room for improvement, and I for one would like to see the mainframe proposition evolve further to the point where it truly can replace a data centre filled with servers, switches, firewalls, other network devices and operational support systems. But doing so through leveraging F/OSS and implementing as much functionality as possible on top of Linux running inside a VM. Leaving z/VM to provide virtual hardware and virtual links between these instances, and to manage the underlying resources appropriately. Here re-use is key to both lowering development costs and doing the right thing and not, whether by accident or by design, locking the customer into the mainframe platform. Trust is critical.
I also believe that in order for Linux on z/VM to gain widespread support it must be accessible to the wider F/OSS community. Why restrict this technology to customers who have already signed up else have a large budget and are about to? If you want geeks to get excited about your technology and to work with you to foster adoption you need to give them the opportunity to play with it and to build on it. IBM used to produce a PC card that turned a desktop into a tiny System/390 - the P/390. It would serve IBM well to build a similar product and that is affordable, e.g. a single z/10 processor, or cut down version of, on a PCI card. It ought also to allow the community to run z/VM via the F/OSS emulator Hercules. Neither of these routes to operating z/VM is going to result in lost sales. These configurations would not be eligible for support, nobody in their right mind would run a production workload on them and only a fool would attribute the inevitably poor performance under emulation to IBM’s technology. IBM and the z/Linux community could only stand to gain.
[1] Disclosure: I’d previously done limited tinkering with the public domain IBM VM/370 running via the Hercules emulator.
Share This
Tags: Linux, Infrastructure as a service, Virtualisation, Mainframe, Opensource // Add Comment »