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

By Julian Stuhler posted Sep 16, 2013 09:06 AM


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 part 1 of this article, we looked at some of the hardware and operating system considerations for running Linux workloads on a System z server, together with an overview of the value proposition. In this part we’ll be concentrating on how this capability can be used specifically from a DB2 point of view.

Please note that throughout this article I’m using the generic term “zLinux” to refer to either SuSE Linux Enterprise Server or Red Hat Enterprise Linux running on a System z server.

Application Servers Accessing DB2 for z/OS

One of the sweet-spots for running Linux workloads on a System z server is for application server consolidation projects. Distributed application servers typically have relatively low average utilisation rates (20% or less is not uncommon) while System z servers are well-known for their ability to consistently run at 90-100% utilisation. Application servers handling global workloads can make consolidation even more attractive, as utilisation peaks are often shifted according to local time-zones, such as the example shown in Figure 1.

 Average Server Utilization - DB2 for z/OS

Figure 1 - Typical Global Application Server Load Distribution

If your existing architecture has a large number of distributed application servers connecting to DB2 for z/OS as a back-end data store, there may be some compelling cost and performance benefits for consolidating. For sites that do not have an existing System z server, a dedicated ELS (Enterprise Linux Server) can start to make financial sense when consolidating as few as 20 distributed servers. If you already have a System z running other workloads that happens to have the required IFL (Integrated Facility for Linux) capacity available, the sweet spot could be lower still.

The potential performance benefits of such consolidation projects become apparent when you start to compare the network topology of a typical three-tier application architecture with that of a zLinux environment. The top half of Figure 2 shows a typical distributed scenario, with full network hops between the client and the application server, and the application server and DB2 for z/OS. For some data-intensive applications, the elapsed time required to traverse that second network link can be a significant proportion of the overall end-to-end response time.

 Comparing Traditional 3-Tier Architecture with zLinux and HiperSockets

Figure 2 – Comparing Traditional 3-Tier Architecture with zLinux and HiperSockets

The lower part of the diagram shows an equivalent set-up with the application servers hosted within a zLinux partition on the same System z server that DB2 for z/OS resides on[1]. Although the first network hop remains as before, the second one between the application servers and DB2 for z/OS can use the HiperSockets feature to greatly reduce the elapsed time for network communications. The HiperSockets feature allows two TCP/IP nodes on the same physical System z server to bypass a large part of the network stack, effectively providing a “virtual socket” at each end of the network and enabling communication at memory speeds. This can provide a significant performance boost to data-intensive applications, as well as removing any need for encryption between app server and DB2.

Of course, this kind of approach assumes that you are able to easily and cost-effectively port your application from the existing distributed environment to zLinux. Fortunately this process is usually relatively straightforward for Java applications due to the hardware-isolated nature of the Java Virtual Machine (JVM) execution environment. If you’re using IBM Websphere Application Server (WAS) there’s a directly equivalent product for zLinux which uses the same concepts, definitions and terminology so a simple “lift and shift” strategy is possible. Other Java application servers such as JBoss can also be hosted by zLinux, with the only limitation being a requirement to use IBM’s specially-tailored JDK (Java Development Kit) for hosting applications. Likewise, other middleware/infrastructure components such as HTTP servers, monitoring tools, messaging servers and database systems can be transferred to the zLinux environment (more on the database part below). The IBM Global Solutions Directory currently lists over 800 software packages (both IBM and non-IBM) that will run on zLinux.

If high availability is important, it’s possible to run a Websphere Application Server cluster within a zLinux environment, with WAS nodes residing on separate zLinux Virtual Machines to improve resilience, as shown in Figure 3. As all of the VMs use the same pool of system resources (IFLs, storage, etc), those resources used by a failed VM are available for use by the surviving VM when they take on a greater proportion of the workload. Of course, if the back-end database is DB2 for z/OS then data sharing and Dynamic Virtual IP Addressing (DVIPA) can be used in order to increase the resilience of that part of the architecture[2].

 High Availability with WAS Clustering on zLinux

Figure 3 – High Availability with WAS Clustering on zLinux

DB2 Connect is worth a quick mention. Until a few years ago it was quite common to see DB2 Connect “gateway” servers, responsible for providing mainframe connectivity for a wide variety of distributed clients, and these gateways were often a good candidate for consolidation onto zLinux so they could take advantage of the benefits outlined above. Today this approach has fallen out of favour, as Java application servers tend to use local data drivers to connect directly to DB2 and gateways are not required[3].

It should be noted that many skills are as portable as the applications themselves. From an application development and administration perspective, the major practical difference between a distributed and a zLinux consolidated environment is the TCP/IP address of the server you connect to! Of course, some additional z/VM administration skills will also be required to manage the virtualisation side, but these are typically needed only by a very small proportion of the overall support and development team.

Finally, no discussion of application servers would be complete without considering SAP applications. IBM has forged a close and productive partnership with the ERP vendor and a large number of the new features in each release of DB2 for z/OS are typically aimed at SAP applications. Those customers running distributed SAP application servers using DB2 for z/OS as a back end RDBMS are an ideal example of the sort of consolidation opportunity we’ve been considering above: SAP uses the classic 3-tier architecture, is relatively data-intensive and a complete development / test / production environment typically requires tens of SAP application servers. SAP formally supports both the SuSE Linux Enterprise Server and Red Hat Enterprise Linux distributions for its application servers, and both IBM and SAP have plenty of public customer case studies documenting this approach. There is also an IBM Redbook dedicated to this subject, which I have included in the references section at the end of this article.

DB2 for LUW on System z

So far, we’ve concentrated on zLinux workloads accessing DB2 for z/OS but of course it’s possible to also run DB2 for Linux, UNIX and Windows on a zLinux environment[4]. Although there’s a specific product code for the z editions, this is essentially the same product as DB2 for LUW folks already know and love.  For example, here are the DB2 editions/versions that IBM currently certify as being compatible with SuSE Linux Enterprise Server (SLES) 11 System z:

  • DB2 Workgroup Server Edition (V9.1)
  • DB2 Advanced Workgroup Server Edition (V10.5)
  • DB2 Enterprise Server Edition (V9.1, V9.5, V9.7. V10.1, V10.5)
  • DB2 Advanced Enterprise Server Edition (V9.7, V10.1, V10.5)

Note the absence of any of the Express or Developer Editions from this list. More significantly, the DB2 pureScale continuous availability feature[5] cannot be implemented within a zLinux environment. So, even though porting a DB2 for LUW application to zLinux will allow you to take advantage of System z’s legendary hardware resilience, if you need true continuous availability you will have to stick with pureScale on another hardware platform[6] or consider using a DB2 for z/OS data sharing group instead of DB2 LUW.

Leaving these restrictions aside, the situation is quite similar to the one we looked as previously with just porting the application servers: DB2 for LUW will behave as it does within any other Linux environment and the administration and monitoring can remain largely unchanged.

 Porting Both Application Servers and DB2 Database to zLinux

Figure 4 – Porting Both Application Servers and DB2 Database to zLinux

Figure 3 shows a DB2 for LUW application being ported to a zLinux environment. Note that z/VM also supports the use of “Virtual HiperSockets” between guest instances, effectively emulating the HiperSockets feature within each VM image and thereby providing “virtual, virtual sockets”! This allows very efficient communication between application server and database VMs (even more efficient than “real” HiperSockets).

Although pureScale cannot be implemented under zLinux, the DB2 for LUW HADR (High Availability Disaster Recovery) feature can. This allows a secondary DB2 instance (usually situated in a separate z/VM LPAR) to be designated as a backup to the primary server. Database changes made to the primary server are replicated the backup server in near-real time, and in the event of a failure on the primary the backup server is able to take over with only a temporary disruption to the application service. As shown in Figure 4, IBM’s Tivoli Storage Manage Systems Automation (TSM/SA) can also be deployed within a zLinux to detect failures, automate the takeover process and further reduce application downtime.

 High Availability on zLinux using WAS Clustering and HADR

Figure 5 – High Availability on zLinux using WAS Clustering and HADR

Finally, it’s also worth noting that the DB2 Database Partitioning Feature (DPF) is supported in a zLinux environment. This allows a single logical DB2 database to be partitioned across multiple nodes, each of which may reside on its own zLinux Virtual Machine. Individual nodes communicate with each other via the Fast Communication Manager (FCM). This architecture does not provide the continuous availability advantages of pureScale – the loss of any single partition means that tables containing data on the unavailable partition cannot be accessed until the partition is available again – but it can offer significant scalability advantages over a single, non-partitioned, DB2 for LUW instance.

A Few Words on Analytics

This article has focused on running operational DB2 applications within a zLinux environment. However both IBM and other vendors offer a large number of tools for analytics and warehousing that will also operate quite happily within a zLinux environment. DB2 for LUW (or other vendor’s databases) are more commonly used for analytics than DB2 for z/OS, especially with the advent of the revolutionary BLU technology in DB2 for LUW 10.5[7].

The challenge with this scenario is that the bulk of the operational data needed to feed the analytics engines resides within the mainframe environment for many customers. In these cases, there can be some compelling reasons to host the analytics within a zLinux environment hosted on the same System z server as the operational data. This subject will be covered in a future article.


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 and performance savings. Whether your applications access DB2 for z/OS, DB2 for LUW or another vendor’s RDBMS, it’s worth taking a closer look at what the upside of a consolidation exercise might be for your environment.

Reference Materials and Additional Reading

IBM Redbook: IBM Tivoli Storage Manager in a Clustered Environment

[1] As discussed in the first part of this article, it is common for zLinux instances to be hosted as virtual machines under the control of z/VM rather than natively installing zLinux on an LPAR, but z/VM has been omitted from this diagram for clarity.

[2] Note that the DB2 for z/OS members in a data sharing group would typically be distributed over two or more z/OS LPARs for resilience. This has not been shown in the diagram for clarity.

[3] Please note that a valid DB2 Connect licence is still required when accessing a DB2 for z/OS (or DB2 for iSeries) host, even if the IBM Data Server Driver (aka JCC driver) is used on the application server rather than a full install of DB2 connect. Although it’s now quite old, this article contains a great explanation of the licencing rules.

[4] It’s also possible to run other Linux RDBMS products such as Oracle in a zLinux environment, but we’re focusing on DB2 in this article.

[5] pureScale is a feature available for no additional charge as part of DB2 Advanced Workgroup Server Edition and Advanced Enterprise Server Edition V10.5. It is a clustering solution based on the same concepts and technology as DB2 for z/OS data sharing / parallel sysplex, and delivers excellent scalability and resilience for DB2 for LUW applications.

[6] Up until recently, pureScale was only supported on IBM POWER and System x servers. As of DB2 10.1 FP2 or DB2 10.5 FP1, non-IBM x86 servers are also supported. See here for more details.

[7] Please note that, at the time of writing, some BI application server components of IBM Infosphere Warehouse / DB2 for LUW AESE 10.5 are not yet supported within a zLinux environment. 


1 comment
1 view



Oct 25, 2013 05:35 AM

Good coverage and articulation on the subject...

It is always comparing apples and oranges with distributed systems and mainframe. zLinux provides an compelling alternatives to deploy distributed workloads and integrate with legacy applications with high level of QoS.

I am interested to see, how this topology works with data integration scenarios. For example, data comes from various systems (mostly batch & some near real time) and the target data store is DB2 on zOS. What factors should be considered to have ETL tool (like DataStage) to provide extract & transformation either on Distributed or zLinux platform including constraints, risks associated with this. Any thoughts?.