According to
market analysis
perhaps as many as 14,000 small to medium businesses, half of them in the
US, still running older, small configuration, mainframe gear. With both Hitachi and Amdahl out
of the US mainframe market and IBM committed to upgrading its entire line to the PowerPC architecture found in the current zSeries machines, these companies are being forced to decide between switching and upgrading. How do you decide what’s the best course for your organization?
|
Note that an IBM “MIPS” is a relative measure applicable only within mainframe families. Thus a z900-1G2 is rated at 476 MIPS and really is about twice as powerful as the 239 MIPS z900-101 but it is meaningless to compare these numbers to the 21,000 MIPS generated by a Sun Fire 15K.
MIPS originally refered to millions of System 360 instructions per second, |
The usual argument heard against change is that the hardware
environment is driven by the need to support existing software and that this
software, often custom-developed for the organization, is specific to the installed
environment. In the majority of cases that installed environment is a sub-100 MIPS
VM/VSE System 390 or earlier machine.
In most cases organizations using these older machines also have Windows-based PC
servers and desktops installed and thus face the usual cost, management, and
reliability issues associated with that environment.
IBM’s primary response to these companies is to suggest running a
combination of mainframe and Linux software on its smallest mainframe: the z800. The pitch is that
this allows the consolidation of the older mainframe applications along with most of the Microsoft
Windows server functions on one relatively low cost, high reliability, machine whose operation is understood by the staff in place.
IBM’s fallback offering also provides for consolidation and concurrent operation of
Linux and mainframe software on one machine, but reverses the mainframe-Linux split. Thus,
instead of running Linux as a mainframe process, IBM proposes emulating the mainframe as a Linux
process running on an IBM Netfinity server with two Intel processors.
A corporate executive committee
facing a choice between these two upgrade options needs five categories of information:
- Organizational information — about workloads, skills, tolerance for change, and
available resources; - Information on the approximate cost and capabilities for the z800 option;
- Information on the approximate cost and capabilities for the Netfinity option;
- Judgmental information about the relative benefits of the two approaches; and,
- Information about available or near-term alternatives.
Since this article isn’t about a specific organization we can’t address the first point, but let’s consider the other
four.
The z800 option
IBM tells a company considering an upgrade that it can consolidate to a z800 by
converting much of its Windows server load to Linux and running Linux alongside
a more traditional mainframe operating environment on the z800.
The z800 is made by Hitachi (and sold as an Hitachi in Japan) for sale by IBM as
the low end of the zSeries architecture.
When fully licensed (mainframes are shipped fully configured, with customer
access to the hardware regulated through licensing) the z800 can support as many as
four SMP CPUs currently maxing out at about 920MHz with a rumored next
generation on the way that goes to about 1.4GHz.
The smallest z800 is the model 0E1. This licenses one traditional mainframe CPU
subsystem (an “engine” in IBMese) at 40 MIPS and one at 192 MIPS (770MHz) dedicated to running
Linux — the latter is known as an Integrated Facility for Linux (IFL). This configuration has a list price of about $240,000 with or without the IFL enabled.
With it, the monthly maintenance on this unit comes to about $2,563. (Note that a fully licensed
four-way z800 with 32GB of memory lists at about $1.4 million plus $12,800 per month in maintenance.)
zVM, needed to run more than one Linux
instance, has a one-time cost of $22,500. SuSE Linux pre-installed with
support adds an estimated $35,000 up front and $1,200 per month.
Although users can hook up most existing ESCON (think SCSI2)
peripherals, dual 840GB RAID Enterprise Storage Server (ESS) IBM F20 arrays
on dual FICON (Fibre Channel connectors; about 100MB/sec at $16,000 each)
bring the base system list cost to about $480,000.
| z800-0E1 Basic Cost Summary | |||
|---|---|---|---|
| Component | Capital | Monthly | Three Year Total |
| Base z800-0E1 | $240,000 | $2,563 | $332,268 |
| zVM, SuSE for IFL | $35,000 | $1,200 | $78.200 |
| 2 x 840GB ESS Disk Arrays | $252,000 | $3,150 | $365,400 |
| Total | $775,868 | ||
Notes:
|
|||
Notice that this table doesn’t include the software needed on the traditional
mainframe side of the machine. Those numbers are a
wash for this decision because we’re going to be comparing the same
mainframe software, at the same price, on the z800 in native mode to running it
on Intel under a Linux emulator.
You should be aware, however, that mainframe software costs compare to Unix costs about the way
hardware costs do. Nearly all software is subject to separate licensing with rates grouped
roughly by hardware capability. For example, the entry level z800-0E1 is
nominally classified into the
zELC (zSeries entry license charge) rate group within which
typical monthly license rates look like:
- Program 5740-XXH, feature 4004; provides RACF, the basic user access control facility
for around $882; - IBM C/C++ compilers cost around $793
- TCP/IP connectivity for VM/VSE is $89;
- DFSORT runs around $309; and
- the IMS V7 Database adds $3,686.
You can find IBM announcement letter 202-036 (pricing structure) and letter 202-295 (actual
pricing) by searching annoucements on www1.ibmlink.ibm.com by
letter number.
Performance on the mainframe side of the base z800-0E1 is licensed at 40 MIPS or
around one-third of one engine plus the benefit of a system assist processor
managing disks on four Fibre Channel connectors. At the hardware level, think of this
as roughly comparable to a 330MHz Macintosh workstation with lots of RAM and
a 400MB/sec FireWire connection to a buffered disk pack.
In traditional applications, however, you get a lot more apparent throughput on the z800
because the usage pattern is different. For example,
the batch-oriented nature of much mainframe processing eliminates most of the
process switching overheads involved in desktop operation; and,
both the OS and the applications are typically intensively optimized to
exert minimum resource “footprints” on the machine during processing.
Performance on the Linux side is licensed for full use of one “engine” plus access
to the system assist processor for I/O and related tasks. Under zVM this licensing
amounts to about 192 MIPS.
Two IBM documents
tell us roughly how well Linux under zVM on a zSeries engine performs. The first one, an IBM RedPaper on
Server Consolidation with Linux on Zseries includes the following:
Sample simple calculation (not a official sizing):
100 Intel single-CPU machines
Clock speeds of 200MHz
5% CPU utilization
Putting the workload onto a z800 running at 80% CPU utilization
The workload can be handled with 2 – 3 processors (CPUs).
In other words, 100 x 200 x 0.05 = 1,000 Intel cycles per second maps to between two
and three z800 engines.
Another IBM publication, on
Performance Tuning Linux for the zSeries suggests that the
performance problem isn’t rooted as much in the core Linux code as in process switching, device emulation,
and related functions that map Linux I/O to zVM’s memory and storage management.
Working with a dual-IFL z900 these authors, who were focused on
performance tuning, not benchmarking, got swapping to a zVM-managed RAM disk up into the 40MB/sec
range and achieved, after choosing an experimental high-performance driver and
hacking it, a 120MB/sec read rate using eight physical disks hooked up via four Fibre Channels.
If all of this looks incredibly lame to you relative to modern Intel gear, recognize that the
real difference here is one of philosophy, not hardware.
Unix resources are cheap and we size to meet user response time expectation while being
unconcerned about overall utilization rates. In the mainframe world resources are
extremely expensive, sizing is based on average demand, and the focus is on
keeping system utilization high.
This mainframe approach works where the workload can be forced into
a pattern under which the machine is dedicated to each of its jobs for long enough
that the overhead associated with task switching, and the OS enabling this, can be
stripped away. That applies to ’60s-style batch processing and its current
derivitives, but not to the interactive workloads for which both Microsoft and Unix operating systems
are designed.
That difference in philosophy underlies a major problem with the IBM consolidation argument. Getting
to 90% or higher utilization makes perfect sense in the mainframe world because anything less wastes
expensive machine cycles. Within that worldview, having 10 PC servers running 2GHz CPUs at 5%
utilization is utterly unprofessional, and consolidating them to a single maxed-out two-way z800 is a
sensible solution. In reality, however, the Intel cycles involved are so cheap that the problem they’re
addressing doesn’t exist, and if you were to really do this, your
users would experience dramatic performance slowdowns and come gunning for
your head, because that higher utilization would be achieved by making most of them wait
most of the time.
Emulating the mainframe under Linux
Flex-ES, from Fundamental Software, is a fully
IBM-certified implementation of a zSeries in software. It requires at least a dual-processor box functionally tying up one CPU to emulate a mainframe engine and making
some demands on the second in emulation of the mainframe’s system assist
processor (SAP) to manage I/O requests.
|
Note that Flex is currently offered only under SCO Unix, but the Linux version is available to developers and you have to think somebody in IBM is pushing to make it the default commercial choice real soon now. |
Performance reports on this product
vary, with most observers agreeing that Flex running on a dual 1GHz Intel Pentium III server produces
about 20 zSeries equivalent MIPS. Some reports
go as high as 120 MIPS for a dual 2.8GHz machine. Most agree, furthermore, that the
emulator’s use of standard Unix disks and I/O channels produces spectacularly faster I/O than the mainframes most often replaced or augmented with Flex on Intel.
Several resellers offer technical information on their Web sites. Zframe, for
example, provides reasonable detail about key functions and issues on its
site. Another reseller, T3 Technologies,
claims more than 250 installations and offers a range of
customer success stories on its site.
Flex-ES pricing is not, however, shared with the unwashed. Peter Ward at
Funsoft says production licenses are sold through resellers who set their own prices, because customers need support along with the software.
On the other hand, here’s what Fundamental said in a 1998 press release:
FLEX-ESL Approximately 8 MIPS. Base system includes 128 megabytes of main
memory, internal RAID disk subsystem, and limited disk (
FLEX-ESO Approximately 22 MIPS. Base system includes 256 megabytes of main
memory, internal RAID disk subsystem, and limited disk (5 gigabytes
mirrored). This system is also expandable, with additional disk, channels,
and memory available at commodity pricing. This offering is machine software
group rated by FSI as a Group 35. List price: $43,978
On the basis of other comments I’ve received,
I believe that the going price for a pre-installed Flex-ES
license is somewhere around $800 per MIPS plus the cost of the
underlying hardware.
If so, an 18 MIPS installation on a dual processor
Netfinity X235 with 2GB, 2 x 2.8GHz Xeons, and dual RAID controllers, each with eight
36GB, 15K RPM drives, should run to about $35,000, with the 80 MIPS version going for
about $92,000.
Thus an x235, as above, with Flex-ES licensing to 40 MIPS and a 2TB IBM FAStT600
Storage Array with Linux host adapters should come to about $107,000.
|
In practice most people would probably use two machines, because hardware costs are low enough that the comfort of being able to split the load in normal times while having an online spare available for emergencies would outweigh cost considerations. But even full duplication still produces better than a 70% saving relative to the z800 approach. |
Maintenance fees are not published, but overall this looks like it provides about a
$600,000 direct saving over the z800 option while providing
functionally identical mainframe power and leaving most of the system available,
most of the time, to run Linux work at many times the speed of the z800 IFL.
Relative benefits
Given that both the cost and performance cases work out dramatically in favor of
running the Flex-ES mainframe emulator on a Linux machine rather than emulating
Linux on a mainframe, we need to ask whether there might not be offsetting benefits
to the z800 solution that can be taken into account.
The IBM community likes to talk about two issues here:
reliability of service (RAS) and virtualization/partitioning.
Both are issues of great importance to the mainframe community. While they were
certainly applicable with respect to the problems around whose solution they
evolved, they are generally valueless with respect to the decision under
consideration here.
z800 RAS facilities, implemented at the hardware,
microcode, and systems code levels, are generally not accessible
to Linux. Under zVM a minor hardware or software fault doesn’t stop the machine, but any
Linux instance affected fails and has to be restored.
At the hardware level most mainframe RAS features are leftovers from the early
days of computing when the electronics were much less reliable. Most of the conditions these
features were designed to cope with no longer exist; for example, CPU and related failures,
although once common, are now extremely rare. Thus any remaining mainframe reliabililty advantage
over a Sun or high-end Intel box running Unix lies almost entirely in management
practice, not in hardware or software.
More subtly, multiple IBM publications (e.g.
Linux on IBM zSeries and S/390: Large Scale Linux Deployments)
on operating multiple Linux instances in a production environment strongly
recommend sharing as much of Linux as possible between instances and managing those
shared files directly under VM. You do this for performance reasons, but it has an
odd consequence:
- to the extent that root users, or setuid processes, on virtual instances can affect the system, this
defeats virtualization as a means of isolating instances from each other; and, - to the extent that root users, or setuid processes, cannot affect their
own systems, the result isn’t Linux — it’s more like a better CMS (the interactive shell
layer in zVM) than a real operating system.
Virtualization and its cousin partitioning are virtual machine technologies which
evolved as ’60s solutions to the problem of enforcing barriers between production and
development users in an age of assembler programmers, 64K main memories, and
multi-million-dollar minimum machine investments.
Partitioning splits a machine by grouping resources at the microcode level to form
two or more virtual machines sharing the base hardware but unable to directly
interact with each other. Virtualization runs one or more independent copies of an
operating environment on a machine.
In the early days of computing these technologies
offered a cheap way of setting up safe development and testing environments without having to
buy second and third machines. Today, of course, that cost problem no longer
exists: a high-end development workstation
like a Sun Blade 2000 may run $20,000 while a four-way test server from a vendor like Dell goes for less
than $12,000, but that doesn’t stop people from going right on solving it.
Consider, for example, the logic
of buying a 24-CPU, $1.2 million Sun Fire 6800 to get a 24-CPU system with
192GB of symetrically accessible RAM, and
then partitioning it three ways to get the
equivelent of a grid network with three V880s worth $125,000 each. Then recognize
that no one sells a big machine
into a mainframe shop without providing this kind of partitioning capability.
Similarly there are multiple virtualization solutions for all major versions of Unix, and better solutions already built into the OSes being virtualized.
For example, software from Virtuozzo lets you create as many
as 2,500 separate Linux instances on that Netfinity while it’s running VM/VSE under Flex, but
the basic Linux already on that box will natively let you run 2,500 independent
user processes without the overhead of virtualization.
There may be instances where partitioning and virtualization for Linux make sense,
but I’m unable to think of any that might pertain to the situation faced by the
14,000 or so small to medium enterprises on whose systems this article
is focused. For them, getting a pair of Netfinities running Linux and licensing
Flex-ES for one of them is clearly preferable for both cost and performance reasons.
Other alternatives
Staffing, like mainframe software pricing, isn’t an issue for the two upgrade options
discussed so far.
You pay the same rates, and need the same skills, whether
you get your MIPS from a z800 or Flex-ES on Intel. Similarly, you use the same
software, and need the same skills, whether your Linux cycles come from a mainframe IFL or an
Intel box.
However, if the corporate executive committee wants to take a broader view of its responsibilities
and consider alternatives to upgrading, the IT staff’s ability to find, judge, implement, and support
those alternatives quickly becomes an issue.
Surprisingly, this staffing-related issue actually creates a subtle advantage for
Flex-ES in organizations with deeply entrenched IT leadership. In those situations, executive
committee members will generally see that
buying into the z800-based upgrade locks the company into the mainframe for
at least a few more years. What they may not see, however, is that hiding the MIPS requirement
in an Intel box running Linux
reduces psychological barriers to change and makes it much easier for the organization to use some of its
$600,000 or so in savings to bring in non-mainframe staff and thus pave the way for
more radical change downstream.
At that time, or immediately in less constrained organizations, members of the
IT steering committee can start asking other questions, including:
- Is the software tying the company to the mainframe actually
necessary? Or is the organization caught in a chicken-and-egg situation with some people
using the software
to constrain process change and others using the processes to constrain software change? - Can the software, and the business processes it models, be replaced with a commercial
alternative or Linux freeware? - If the organization has the software source code, why not just port it to Unix (BSD, Linux, or Solaris)?
- If the organization doesn’t have full source, are the binaries sufficiently old that the
system can be made to run under MVS3.8 or VM/370R6? If so it may be possible to use the Hercules mainframe emulator without paying for
additional licensing and so save real money. Hercules is an open source effort not blessed by IBM but able to run most
applications and IBM operating environments on almost any flavor of Unix. Since several IBM OSes — including the MVS
and VM releases mentioned — have become public domain, users of sufficiently old code
may be able to implement it entirely without licensing fees. - Does the organization have license loopholes available to it? Are there, for example, maximum
total cost agreements under which critical licenses have become perpetual? Does the organization have the
right to port the software to hardware of comparable power? Do the disaster recovery conditions allow
the organization to drop the old mainframe off a bridge, call that a disaster, and use the licenses
under Hercules instead?
Realistically there probably are no business applications running on the sub-100 MIPS mainframes
targeted by Flex and the z800-0E1 that couldn’t be simply ported to Unix and run under something
like Linux or BSD on a sub-$1,000 Intel box. Unfortunately that reality remains largely irrelevant
to those involved in decisions of this type as long as neither the information nor the supportive
environment needed to make it happen is available to them.
Both are available where the stakes are larger.
Sun, for example, has several mainframe rehosting programs aimed at companies with high-end System 390 or
zSeries gear where spending a couple of million on Sun Fire 6800 class equipment can produce enormous savings, but it has nothing in place to support the transition for the company whose mainframe computing needs could be met on a Sun Blade 150 for about $1,995.
The Hercules open source S/390 emulator has the potential to change that, in part because it, unlike
Flex, which has significant assembler components, compiles and runs on non-x86 equipment like SPARC-
and Itanium-based machines. The biggest factor holding it back is
real or imagined opposition to it from IBM.
I got no answer from IBM on whether it will license its products under Hercules,
but industry rumor has it that IBM will not, and the rumor, true or not, is enough to scare most
people away from Hercules for mission-critical applications.
As a result, a company like Sun or Red Hat could provide an invaluable service to the
Unix community by seeking legal clarification of IBM’s approach to licensing products
under Hercules, perhaps by seeking an amendment or clarification to the 1997
agreement to set aside the consent decree that would otherwise have forced IBM to do so.
With a clear positive ruling on licensing of mainframe tools for use with Hercules, that product’s open source nature would allow the general Unix community to welcome those 14,000 or some small to medium
businesses to the Intel-dominated world of Linux and small, fast, cheap computing.
Paul Murphy wrote and published The Unix Guide to Defenestration. Murphy is a 20-year veteran of the IT consulting industry.
