How Many Mainframes Do You Need?
I'd like to spend a few moments discussing, in general terms, how many mainframes you should own. I find there's some confusion on this point, particularly in my part of the world. When I say "mainframes" I'm referring to System z machines, including dedicated external coupling facility (CF) machines. Let's look at each case:
The mainframe is the original (and the best) cloud computing provider. Thus "zero" may be the correct answer, letting someone else run the mainframe(s) somewhere on the planet. For example, if you are developing applications or middleware, you can get a complete z/OS virtual machine for as little as $350 per month. Great deal! Of course, if you're a business or government, you may simply want more direct control over your most critical information systems, for a variety of reasons....
Huge numbers of customers own (or lease) only one System z machine. That one machine delivers exceptional availability and reliability all by itself, running huge numbers of applications and databases concurrently, managed according to business priorities.
Some people forget that it is possible (and common) to configure a full logical Sysplex within one mainframe. For example, if you want to implement DB2 data sharing, you can, even on a single machine. With such a configuration, and with a little planning, you can still maintain continuous business service even while performing such tasks as z/OS and DB2 release upgrades. You can also maintain continuous service while performing most forms of hardware maintenance, such as microcode upgrades.
If you have only one mainframe, there are a few limitations. For example, if your data center catches fire and burns to the ground, you will experience a service interruption and lose any local transactions recorded since your last backup to an off-site archive. How long the service interruption lasts depends on what sort of business recovery contract you have. Also, when you want to upgrade the mainframe model technology (from a z9 to a z10, for example), there could be a planned service interruption. However, you may be able to avoid that interruption if you position the new machine alongside the old one, configure it as an additional Sysplex member, gracefully shift workload over, then retire the old machine or move it to a disaster recovery center to become your "new" second machine. Finally, if you have a really huge amount of total workload you may need more than one machine. (There may be other reasons why one machine is not sufficient, but these are the most common.)
With two machines you can configure a Parallel Sysplex with two physical members (and almost any number of LPAR members) using internal coupling facilities (ICFs). A 100% ICF implementation is much more attractive now than in the past, thanks to some technical improvements beginning with z/OS 1.8. If there's some extremely rare double-catastrophic failure affecting one machine, a physical Sysplex provides extra protection and convenience. You can also stretch this Sysplex across longer distances using Geographically Dispersed Parallel Sysplex (GDPS) technology, protecting against site-wide failures.
Alternatively, you can have one primary machine and then keep one (sometimes "N-1" or "N-2" older technology) machine at another site, even without GDPS. If the primary site fails (fire, flood, whatever), there will be a service interruption without GDPS, but you will have the technical ability to recover at your own second site rather than rely exclusively on an outside contract.
Sometimes, for (non-IBM) software licensing reasons, having a second and much smaller machine makes financial sense. This machine is popularly known as a "penalty box."
As before, if two machines do not provide enough capacity (because you're "really, really big"), then you might need more.
Like one and two machine configurations, tri-machine configurations are quite popular. Usually that means a pair of machines (and Parallel Sysplex with ICFs) at a primary data center plus one machine for disaster recovery at another site, perhaps with some form of GDPS for zero or near-zero delay in recovery. This configuration recognizes the operational convenience of having a true physical Sysplex at the primary site, for catching problems there before resorting to what could be a complex cross-site switchover. Generally such a configuration is a concession to the other servers in the primary data center, which aren't as talented at DR switchover.
More Than Three Mainframes
Do you need more than three System z machines? Maybe. Of course, one possible reason is that you're really, really, really huge, and even a trio of System z10 Enterprise Class Model E64 machines will not satisfy your growing workload demands. In fairness, that's rare. Another possible reason is that there's still good cause (and a strong technical-business case) for adding (usually one) dedicated external coupling facility machine, usually a System z10 BC rather than an EC to minimize space, power, and cooling costs. Some organizations even have more than one disaster recovery site — usually a "near" site and a "far" site — and need more machines.
In summary, mainframes are not like distributed servers. You simply don't need many System z machines; they provide uniquely ultra-concentrated computing throughput and quality. For perspective, even a single System z mainframe is quite arguably superior in delivering higher availability and reliability than multiple clusters of distributed servers. Also keep in mind that you do not need separate physical machines for development and testing — LPARs accomplish that.
With that background, to determine the correct number of System z machines for your environment, sit down and chat with a knowledgeable architect who can match your business requirements to an appropriately parsimonious configuration, using the latest "best practices" to optimize the solution.
|by Timothy Sipples||March 23, 2009 |
Permalink | Comments (2) | TrackBack (0)
A Couple Important Preview Announcements
Last week IBM issued two "preview" announcements. IBM seems to be getting more open about discussing product trends and directions, and the most recent examples are CICS Transaction Server Version 4.1 for z/OS and z/OS 1.11.
CICS Transaction Server is arguably the most significant and important transaction manager and application environment for business and government. (Others might argue IMS. I would argue that both are.) The Version 4.1 preview announcement is fascinating. Atom feeds from CICS? Java 6? PHP? Yes, really. But what I find particularly refreshing is that IBM plans to make a beta version of CICS Transaction Server Version 4.1 for z/OS openly available for public Internet download starting sometime this month, and there's no charge for the beta. How about giving it a spin?
Most people already understand and appreciate z/OS's famous reliability characteristics. But now IBM is talking up z/OS 1.11's "failure avoidance" characteristics, the ability for the operating system to keep the operators (and their users) out of trouble. ("Dave, are you sure you want to do that?") IBM is also boldly claiming that customers can move to z/OS 1.11, enjoy the new functions, and consume no more (and probably less) CPU. Nobody else in the operating system business seems so focused on performance improvements, so that too is refreshing.
CICS TS 4.1 becomes generally available in the second or third quarter, and z/OS 1.11 becomes generally available in September.
|by Timothy Sipples||March 2, 2009 |
Permalink | Comments (0) | TrackBack (0)
The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.