When Worlds Collide – Running DB2 for LUW on System z (Part 1 of 2)

By Julian Stuhler posted Aug 29, 2013 07:38 AM


Ever since IBM introduced DB2/2 for its OS/2 operating system back in 1987, the DB2 community has been divided into two camps: those that mainly use DB2 for z/OS on IBM’s high-end System z mainframes, and those that spend most of their time using DB2 for Linux, UNIX and Windows (DB2 for LUW) running on a distributed platform.

While the two products share a common ancestry and are largely compatible from an application development perspective, they are highly optimised for their respective operating systems and server platforms, and are therefore quite different under the covers.

Several factors are combining to make it increasingly attractive for organisations to bring the worlds of System z and DB2 for LUW together. This two-part article examines these factors and the potential impact from a DB2 perspective, and provides some references for those interested in learning more. In this first part, we’ll be taking a look at how and why Linux runs in a System z environment.

A Brief History Lesson

To begin, let’s forget about the “UW” part of “DB2 for LUW” as we’re really concentrating on Linux for the rest of this article. While it’s not impossible to run UNIX or even Windows workloads on System z hardware (take a look at this announcement), most of the action is currently with Linux

Linux has been around since the early 1990s, and runs on a wide variety of platforms and architectures. However, it wasn’t until 1998 that two separate initiatives (one an internal IBM project and one an independent effort which was subsequently mothballed) began work on porting the open source OS to the System z platform. Two years later in May 2000, IBM announced availability of two Linux distributions targeted at System z, which were offered by SuSE and TurboLinux. Later the same year Red Hat, another leading Linux distributor, announced support for System z. SuSE and Red Hat remain today as the two main options for what has become known as Enterprise Linux. You can find out more about these two distributions here and here.

A Hardware Perspective

From a hardware perspective, nothing special is required to run Enterprise Linux and any System z server could dedicate some or all of its general purpose Central Processors (CPs) to a Linux environment. However this would be a bad choice from a cost perspective, as those CPs would still count towards the overall processing capacity total that IBM and other vendors use to determine z/OS software fees.

In order to address this problem IBM introduced Integrated Facility for Linux (IFL) processors in 2000. IFLs are physically identical to a System z CP, but run different microcode that limits allowable workload to Linux only. This makes them considerably cheaper to purchase than a standard CP, but perhaps more importantly means they don’t count towards z/OS processing capacity and therefore don’t impact other software licence fees. This approach makes it possible for organisations to install IFLs on existing System z servers and run Linux alongside traditional z/OS workloads in a very cost-effective manner.

For customers without any need to run a z/OS workload, it’s even possible to purchase a System z server that only has IFLs installed and is therefore completely dedicated to running Linux workloads. This is known as an IBM Enterprise Linux Server (ELS) and can scale from a single IFL/core in a low-end zBC12, to as many as 101 in a fully-configured zEC12. This is perhaps the purest implementation of IBM’s strategy of bringing the traditional System z reliability and scalability benefits to the world of Linux: you won’t find any mention of “mainframe”, “z/OS” or even “System z” anywhere on the IBM ELS Web pages.

Linux on System z

Let’s look at a few of the specific implementation scenarios for running Enterprise Linux on a System z server. First, it’s important to understand that Linux is a first-class operating system capable of running on the “bare metal.” In other words, it sits alongside z/OS, z/VSE and z/VM as a primary OS option for System z, and is not dependent on any of them. Having said that, it’s very unusual to see a single Linux instance consuming an entire System z server in this way.

In a typical configuration, IBM’s PR/SM hypervisor would be used to create multiple logical partitions (LPARs), any one of which could be used to host Linux alongside more traditional z/OS workloads as shown on the left of Figure 1 below. More commonly, IBM’s z/VM hypervisor would be installed on an LPAR and used to quickly provision multiple Linux virtual instances, as shown on the right of the same diagram. This is a highly efficient way of sharing system resources, and it’s not unusual for a single System z server to host many hundreds (or even thousands) of virtual Linux machines concurrently on a single System z server.


Figure 1- Enterprise Linux Topology

z/VM can trace its roots back to the 1960s, but has been available in its current form since October 2000. It is enjoying a significant renaissance as a result of its utility in large-scale Linux implementations, with in-depth skills very much in demand in the marketplace. The latest releases have introduced valuable new functionality such as live guest relocation (the ability to move an active virtual machine from one z/VM instance to another) and support for larger memory configurations. More information is available in the Reference Materials section at the end of this article.

The Enterprise Linux Value Proposition

So it’s possible to run Linux on System z, but why would you want to? Here are a few considerations:

  • Resilience. Most traditional Linux workloads run on some form of Intel x86-based server. This architecture originated in the late 1970s and was designed for use in personal computers. Since that time it has also been pressed into much more demanding server duties and although it has been incrementally enhanced to improve both its processing power and reliability, most “normal” x86 servers offer only limited hardware redundancy. As a result the Mean Time Between Failure (MTBF) for a single x86 server is widely regarded as being measured in months. In sharp contrast, IBM’s System z platform is generally accepted as being the most resilient technology available today. It makes extensive use of redundant hardware within each server, seamlessly utilising spare components in the event of a failure without impacting the workload (and subsequently allowing failed components to be transparently replaced). This all results in an industry-leading MTBF: a single IBM zEnterprise server running z/OS V1.12 has a quoted MTBF of 30 years[1]. The ability to run Linux workloads on a highly resilient server platform such as System z has some obvious benefits for mission-critical applications.
  • Operational Costs. This one may be a bit more of a surprise, but there are plenty of situations where it makes good financial sense to consolidate a large number of x86 Linux servers into a single System z Server. These break down as follows:
    • Software licence costs. These can be dramatically lower: for IBM software such as DB2 or Websphere, a z196 IFL processor is classed as a single core and only equates to 120 PVUs, but an Intel X5670 processor with 6 cores has a much higher PVU rating of 420, despite being generally less powerful. The situation is even more pronounced with some other vendors licencing arrangements. For example Oracle currently charges by the CPU core, making software running on an IBM IFL just 17% of the price of that same Intel X5670.
    • Power and Environmentals. Today’s System z servers are not the power-hungry behemoths of yesteryear: a fully configured z196 has a maximum power draw of 27.4 kW. Consolidating many individual x86 servers into a single Enterprise Linux server can produce a significant reduction in server power usage, as well as a reduction in expensive data centre floor space and air conditioning requirements.
    • Hardware and OS Administration. Significant productivity savings are possible in a consolidated environment though centralised backup and recovery, and in general system administration overheads.
    • Performance. For I/O-bound workloads, the superior capabilities of a System z platform can provide a significant boost to performance compared to a typical x86 server. Further benefits can be realised through a reduction in network traffic. For example, a Java application accessing DB2 for z/OS data on the same System z server can utilise the hipersockets feature to eliminate much of the network overhead between the application server and the database. Finally, the industry-leading workload balancing capabilities within PR/SM, z/VM and WLM allow limited compute resources to be efficiently allocated across many different workloads according to business priority. This in turn allows for much higher average CPU utilisation rates, enabling an Enterprise Linux Server to handle much larger consolidated workloads than would otherwise be possible.           

More information on the value proposition can be found within the IBM ELS Web pages, and many customers are taking heed of these messages. An astonishing 20% of the worldwide installed System z computing capacity is currently devoted to running Linux workloads, and this proportion is set to grow as IBM focuses on these workloads as one of the major opportunities for growing the platform in the future. Over 120 new customers signed up for System z servers in the past 12 months, and a large proportion of these are Linux consolidation projects.


System z is no longer just about running traditional mainframe workloads. Linux workloads can exploit the industry-leading reliability and scalability offered by the System z server hardware while providing some compelling cost savings.

In part 2 of this article, we take a look at how this capability can be explicitly used from a DB2 perspective.

Reference Materials and Additional Reading




Sep 18, 2013 12:42 PM

Cost Comparison

Hi Nadir.

As you can appreciate, there are a lot of different factors to take into account for any platform comparison so it's very difficult to make generalisations. I have seen some compelling cost justification / ROI cases for specific customer situaitons that IBM has helped to put together - these take into account the various factors I highlighted in Part 1 of the article (licence fees, environmentals, admin costs, etc), but are very workload and environment dependent.

Sep 12, 2013 10:12 PM

Cost comparison for running linux on z-series vs p-series or intel hardware

Thanks a lot for your informative article - would it be possible to receive some helpful sample hardware cost estimates from IBM for running Red Hat or SuSE linux on z-series vs p-series?

Sep 05, 2013 04:17 AM

Looking forward to part 2

Thanks Hemanshu. I will indeed be covering application servers, DB2 for LUW and DB2 connect in Part 2, along with a few other things!

Aug 31, 2013 08:56 AM

Looking forward to part 2

Looking forward to next part  and  Guest LANs are virtual networks Hypervisor Z/VM ,  Application server  & DB2 LUW