A great deal of the world’s data is managed on IBM^® z/OS^® and OS/390^® servers running DB2^® Universal Database™ (DB2 UDB) software (herein after referred to as DB2 UDB for z/OS), and for a good reason: The z/OS operating environment is characterized by an highly available architecture that is well suited for mixed workloads.

DB2 Connect delivers a complete set of drivers that includes JDBC, SQLJ, ODBC, CLI, OLE DB and a high-speed native ADO.NET data provider for the entire DB2 UDB family. However, unlike competing products that offer simple drivers, DB2 Connect employs a sophisticated communication server infrastructure, a federated database, application development tools, and a tight integration with DB2 UDB for z/OS. This integration ensures that distributed applications get the full benefit of the IBM eServer™ zSeries^®  (zSeries) architecture and delivers the benefits of continuous application availability and policy-based workload distribution throughout the enterprise.

One of the most frequently asked questions I get from clients is, “What benefits can I get from DB2 Connect and zLinux”? My answer: “Lots!”

The most important of these benefits may be a continuation of the zSeries server environment. Quite honestly, most clients that have zSeries servers love them – they know how to manage them, they’re reliable, and they can pretty much handle whatever you “throw” at them. Running DB2 Connect on a zLinux partition is a great choice for many reasons and in this article, I’ll discuss some of them.

Get your zSeries Characteristics for Less

From a cost perspective, installing DB2 Connect on a zLinux partition can be an attractive proposition. Imagine that I told you that you could get all the benefits that you love about your zSeries hardware box for the price of a distributed workstation … and that’s exactly the case with DB2 Connect on a zLinux partition.

IBM sells zLinux engines through its Integrated Facility for Linux (IFL) engine program, which yields much lower hardware acquisition costs than z/OS-based engines on the same hardware.

Ultimately, an IFL is a central processor dedicated specifically to Linux workloads on an IBM eServer zSeries. The attractively priced IFL processor enables you to purchase additional processing capacity exclusively for Linux workloads, without affecting the MSU rating or the IBM eServer™ zSeries^® model designation. This means that an IFL will not increase charges for zSeries software running on general purpose (standard) processors in the server.

An IFL has the same functionality as a general-purpose central processor on a zSeries server. Support for On/Off Capacity on Demand (O/O CoD) and Capacity Upgrade on Demand (CUD) allows you to add one or more IFLs, without disruption. HiperSockets™ can be used for communication between Linux images, or Linux and other operating system images on the same zSeries system (more on that later in this article).
 
Finally, IFLs are managed by PR/SM™ in logical partitions with dedicated central processors. The implementation of an IFL requires a Logical Partition (LPAR) definition, and depending on the model of your server; the number of them that you can have may vary.

Figure 1: An example of an IFL.

Quite simply, IFL gives you the ability to leverage all the “buy” benefits of your zSeries hardware at an attractive price. In fact, DB2 Connect is one of the most popular workloads running on zLinux today.

Finally, when you run Linux, you have access to free middleware such as an application server that you may want to leverage to lower costs even more.

Security

The zSeries server has the ability to encrypt data at the disk level, across a communications channel (to protect against channel or network sniffers), the data in the buffers, and so on. Since this is all hardware-assisted (shown as follows) there are significant performance advantages by leveraging this feature of the hardware:

Figure 2: The zSeries server has the ability to encrypt data at the disk level, across a communications channel.

Today’s Biggest Hardware Trend: Consolidation

DB2 Connect on zLinux represents not only an opportunity to extend the value proposition of the zSeries hardware at an attractive price (via the IFL engines mentioned in the previous section), but also provides a strategy by which you can consolidate older UNIX or Windows-based DB2 Connect servers.

Consider the simplicity you can add to your environment (cabling, floor space, cooling space, and more) from the scenario illustrated below:

Figure 3: Add simplicity to your environment through hardware consolidation.

You can transform the physical middle-tier in figure 3 into a logical one and get performance gains (more on that later in the article) and TCO advantages in return: that’s a hard proposition not to consider, given today’s tight budgets.

The Original On-demand Computing Environment

Before IBM ever coined the term “On Demand,” zLinux partitions and their associated workloads were on-demand computing environments. Think about it: It’s easy to create new zLinux partitions in an existing zSeries environment. If you are in need of some more capacity, just “snap off” another IFL engine. If you’ve got an existing IFL engine that needs more compute resources, dynamically add more engines/CPU power or memory on the fly.

When you look at today’s data delivery requirements, this can be quite a benefit and   “there for the taking” when installing DB2 Connect on zLinux. The retail industry illustrates these advantages quite well. In retail, the data-delivery environment typically ramps up from transactions to reporting. Be it in response to analysis on a marketing campaign or quarter-end reporting, there are significant peaks and valleys with data delivery requirements. At quarter-end, fiscal analysts are bound to hit their systems harder and harder with more queries. In response to this, the system administrator can allocate more resource to the zLinux partition and remove those resources when the demand subsides.

Supercharge your Data Flows with Hipersockets

When you think about what DB2 Connect does, at its nucleus, it’s really about sending bytes of information (which you can natively encrypt if you’re using DB2 Connect V8.2 or later) over a wire protocol. Typically, in the non-zLinux world, you’ll see 100 MB Ethernet and GB Ethernet being used; these are pretty fast, and have relatively low latency.

When you install DB2 Connect on an IFL partition, you can use Hipersockets to support this communication flow. Hipersockets has less than one MS latency and has an extremely high throughput rate. In fact, Hipersockets is by far the fastest and highest throughput option for connecting DB2 Connect servers to DB2 UDB for z/OS databases.

The following chart illustrates an example of the benefits that Hipersockets can offer your environment. You can see the much higher levels of performance, even when compared to the state-of-the-art GB Ethernet connectivity that Hipersockets offers.

Figure 4: Charting the benefits that Hipersockets can offer your environment.

How’s that possible? The origin of the speed advantage for Hipersockets is easy to understand when you think about it. Unlike other communication mechanisms that require data to traverse a TCP/IP communication stack, a network adapter, and the “wire,” Hipersockets simply transfers data from one location in memory to another. The savings in CPU cycles and latency are significant as you can see in the previous figure.

All the Benefits with Flexibility

When you deploy DB2 Connect on a zLinux partition, you can leverage all of the benefits outlined in this article and mix them with the flexible architecture that is DB2 Connect. From direct connections through a Java client to tiered architecture, you can choose the topology that’s best for you.

For example, as of DB2 Connect V8.2, the Type 4 JDBC driver has a royalty-free redistribution license so that you can embed this connectivity code (it’s about two MB) directly into your applications without concern for distribution licensing. In fact, this driver is the same driver that is used for z/OS-to-z/OS communications. A unified driver provides a more seamless migration path and consistent code execution across the DB2 family.

As opposed to a direct connection through a Java client, you can also use DB2 Connect as a gateway in a number of different ways. There are added benefits when using DB2 Connect as a gateway. For example, you get access to a lot of other features that DB2 Connect offers like the free DB2 Everyplace mobile database infrastructure (bundled as Mobility-on-Demand in DB2 Connect), federation capabilities that include Informix IDS^®, the entire DB2 UDB family, XML, WebSphere^® MQSeries^®, application development plug-ins for your favorite IDEs (like Visual Studio.NET or Rational Application Developer^®), monitoring capabilities, and more.

Figure 5: DB2 Connect used as a simple gateway.

If you’re using Web-based technologies, you can install DB2 Connect on separate partitions and create DB2 Connect server farms that are isolated from your application server farms. You’ll still get the benefits of DB2 Connect on zLinux and free up resources on the application servers as opposed to collocating them. With that said, DB2 Connect doesn’t have a lot of overheard, and this approach could add some complexity to your server infrastructure, but depending on your environment, it may be a good one (there are clients who use this approach quite successfully). The following is an example:

Figure 6: DB2 Connect on separate partitions with DB2 Connect
server farms that are isolated from application server farms.

You could choose to collocate a cluster of applications servers with your DB2 Connect server (my personal favorite). This provides a number of benefits, the most important of which is the ability to reuse the application server infrastructure you created for the Web server farm (for example: fail-over, load balancing, and more). For more information about the benefits of collocating DB2 Connect with an application server for high availability, or general information about how to configure DB2 Connect for high availability, see “High Availability and your DB2 Connect Server” by Paul Zikopoulos and Leon Katsnelson.

Figure 7: Collocating a DB2 Connect server and application server.

Sharing A Real-world Example of the Benefits of DB2 Connect on zLinux

I worked with a client who was an existing DB2 Connect customer. This client was struggling with a plethora of older server boxes that were being reused for gateway connectivity. All of these servers were based on different architectures (RISC^®, SPARC^®, and so on) and different operating systems (Windows^®, Linux, Solaris, and so on). All of that heterogeneity produced a management nightmare of patches, inconsistent response times due to each server’s  TCP/IP stack implementation, and other characteristics (like the integer math performance of the underlying processor — something very important to consider when dealing with DB2 Connect). At the same time, this client had excess zSeries resources (e.g., disk, CPU) that were not being used. These resources were readily available and would be easy to allocate to Linux on zSeries

This client decided to migrate to DB2 Connect for zLinux. The end result? Transaction times were cut in half, stability increased because of the simplified environment, scalability improved, and managing it all became a lot easier. Your mileage may vary, but if you have some capacity on your zSeries and you’re using a DB2 Connect strategy, you may want to consider migrating to DB2 Connect for zLinux as well.

--

Paul C. Zikopoulos, BA, MBA, is an award-winning writer and speaker with the IBM Database Competitive Technologies team. He has more than nine years of experience with DB2 products and has written numerous magazine articles and books about it. Paul has co-authored the books: DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). Currently he is writing a book on the Apache Derby/IBM Derby database. You can reach him at: paulz_ibm@msn.com.

Trademarks
DB2, DB2 Connect, DB2 Universal Database, Informix, WebSphere MQ, Rational Application Developer, z/OS, zSeries, and IBM are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both.

Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

Disclaimer

The opinions, solutions, and advice in this article are from the author’s experiences and are not intended to represent official communication from IBM nor an endorsement of any products listed within. Neither the author nor IBM is liable for any of the contents in this article. The accuracy of the information in this article is based on the author’s knowledge at the time of writing.