Blogs

New IBM DB2 release simplifies deployment and key management

Post Comment
IBM Distinguished Engineer & Chief Db2 LUW Chief Architect, IBM

The recent IBM announcement of IBM DB2 for Linux, Unix and Windows (LUW) Version 11 represented a very significant milestone release of the next-generation, enterprise-scale database for transaction and analytical operations. DB2 LUW provides high-impact advances for a wide variety of workloads, from modest online transaction processing (OLTP) and analytical workloads to large, highly mission-critical OLTP and warehousing workloads.

This technical overview of the key features in this release is presented in two parts. This first installment focuses on some of the high-value, core advances in security, availability and performance. The second installment focuses on other exciting features for analytical workloads, including a new massively parallel processing (MPP) capability for the IBM BLU Acceleration technology that delivers in-memory speeds to—and well beyond—the petabyte range.

Core database advances

If you’ve been following DB2 in recent years, you may have noticed all the excitement around in-memory, BLU Acceleration and IBM DB2 pureScale continuous availability and scale technologies drowning out information about other interesting new capabilities in the core database. On the heels of this release, no time like the present to emphasize some of the key features in Version 11.1 that apply to many DB2 LUW deployments, including good ol’ single-node DB2 deployments using traditional row organized tables.

To begin, DB2’s internal algorithms have been revamped to improve internal access to its buffer pool pages, especially for pages that are commonly accessed. This change can significantly reduce contention and enhance performance. These improvements are particularly noteworthy for workloads that involve very hot data and very high concurrency levels—for example, those with hundreds or thousands of connections. In extreme cases, the improvement can be truly dramatic. For example, two recent cases measured in the lab resulted in 58 percent and 110 percent overall throughput increase: 

http://www.ibmbigdatahub.com/sites/default/files/blog_image1.png

Another great example of a core improvement in Version 11.1 is in the upgrade process. Recognizing that many organizations still have databases on older releases, especially Version 9.7, had we continued the usual practice of supporting older databases, all your Version 9.7 databases would have required a double-hop upgrade to get to Version 11.1. As a result, Version 11.1 increases the number of back-level releases that can be directly upgraded to Version 11.1 to include Version 9.7. This increase allows you to start benefitting from the capabilities in DB2 LUW Version 11.1, with significantly less time and effort.

In addition, Version 11.1 enables you to eliminate the need to take an offline backup as part of the upgrade process. Note: This improvement requires your starting point to be at Version 10.5 Fix Pack 7 (FP7) or later, and currently is supported on DB2 single-node or DB2 pureScale deployments.

In past releases, an offline backup was required just prior to upgrade to help ensure recoverability in the event of a significant set of component failures during or just after the upgrade process. For example, if you experience a complete disk subsystem failure during or shortly after the upgrade, you can recover by restoring that offline backup, repeating the upgrade and then rolling forward as necessary. DB2 LUW Version 11.1 upgrade support enables you to recover with a combination of restoring a prior online backup taken before the upgrade and subsequent roll-forward operations. This approach should significantly reduce downtime during upgrades.

DB2 LUW Version 11.1 also helps eliminate the need to re-initialize High Availability Disaster Recovery (HADR) standby databases during upgrade. Note: This improvement also requires the starting point to be at Version 10.5 FP7 or later, and is currently supported on single-node HADR deployments.

This approach can save massive amounts of time, especially for large landscapes with up to hundreds of HADR pairs. In prior DB2 releases, each HADR standby needed to be re-initialized after upgrade through the restoration of a fresh backup. When upgrading to Version 11.1, the primary upgrade operations can be replicated to HADR standby databases, thus eliminating the need for re-initializing the standby(s).

A variety of other interesting core improvements are included in DB2 LUW Version 11.1: 

  • A wide variety of new SQL support
  • New support for aggregate, user-defined functions (UDFs)
  • Many new SQL functions
  • A new VARBINARY data type
  • Exploitation of hardware backup and log compression on POWER7+ and later processors
  • Several more to be discussed in an upcoming blog post

Enterprise key management and security

DB2 LUW Version 10.5 FP5 provided support for DB2-native encryption. This support gave DB2 clients an easy way to ensure all their data at rest is encrypted. It came along with a built-in mechanism for storing and managing master keys, through a per-instance local keystore file. This simple solution has been extremely popular for protecting data at rest for individual DB2 instances. However, it does not provide integration with centralized mechanisms for managing master keys.

DB2 LUW Version 11.1 builds on top of the native encryption solution by adding support for storing and managing master keys through the industry standard Key Management Interoperability Protocol (KMIP) 1.1 standard. This support allows DB2 LUW to participate in an enterprise-level key management strategy. For example, an organization using a KMIP-compliant keystore, such as IBM Security Key Lifecycle Manager, to manage master keys for all its file system encryption can use that same keystore in Version 11.1. And that same keystore can manage all the master keys used for DB2 native encryption.

Setting up DB2 to interact with the KMIP keystore is fairly easy. You specify two simple configuration updates, as shown in the following example in which isklm.cfg is the name of a flat file that contains the host, port and other information describing the KMIP-compliant keystore. You also configure a Secure Sockets Layer (SSL) connection by creating and exchanging SSL certificates with the KMIP keystore to facilitate secure transfer of master keys over the network: 

update dbm cfg using keystore_type kmip

update dbm cfg using keystore_location /home/myhome/keystores/isklm.cfg

http://www.ibmbigdatahub.com/sites/default/files/blog_image_2_revised.png

In addition, note that there are several KMIP-compliant keystores in the market. DB2 LUW Version 11.1 supports any keystore that complies with the KMIP 1.1 protocol. And if you’re currently using the per-instance local keystore file and would like to convert to a KMIP-compliant keystore after upgrading to Version 11.1, you can do so using the db2p12tokmip utility.

KMIP support is not the only security advance in the release. If you are using native encryption on POWER8, Version 11.1 now takes advantage of the hardware encryption acceleration available on this processor, which can provide a significant performance improvement for workloads over encrypted databases. Version 11.1 also adds support for encrypting the data in motion between an HADR primary and standby, using the SSL protocol—which is available initially on x86 Linux.

And Version 11.1 also provides a sneak peek technology preview of Public Key Cryptography Standard 11 (PCKS11) support for hardware security modules (HSMs), which are highly reliable and secure hardware and software appliances particularly designed for managing keys. Note: The technology preview is intended to provide a taste of future capability that may or may not materialize. It is not currently supported and intended for production use.

Simplified deployment and availability advances

Many clients using DB2 pureScale for mission-critical workloads shared that it is easier to install and deploy than other cluster databases, requiring fewer steps and including an integrated install of the cluster manager software. That said, other clients have told us that installing DB2 pureScale could be simpler still. We agree, and this consideration received significant focus during development of DB2 LUW version 11.1. The goal was to make DB2 pureScale install as closely to a single-node install as possible. Version 11.1 includes several enhancements: 

  • A significant reduction in the steps necessary for a complete deploy
  • A significant reduction in the steps necessary for setting up storage redundancy with pureScale
  • Highly significant usability improvements relating to prerequisite checking and informational and action messages 

Several valuable core availability and manageability improvements were made in Version 11.1. One example is the capability to now use synchronous replication with the HADR solution for DB2 pureScale. Many clients were looking for this DB2 pureScale capability to ensure a recovery point objective (RPO) = 0 disaster recovery (DR) solution. Another example is the ability to use inplace online reorg on an individual partition of a range-partitioned table—for example:

 ... reorg ... inplace ... allow write access ... on data paritition p1 ...

This approach allows for dividing and conquering reorg jobs by avoiding monolithic reorgs on very large tables, and instead doing them partition by partition. It allows reorgs to be focused only on partitions that have high levels of INSERT/UPDATE/DELETE activity and to avoid more static partitions that may not benefit from reorganization.

Another DB2 LUW Version 11.1 highlight is the capability to now deploy DB2 pureScale on IBM Power systems with little endien Linux operating systems. This approach works with both the vanilla Transmission Control Protocol/Internet Protocol (TCPIP)—aka sockets—as well as higher-speed Remote direct memory Access (RDMA) over Converged Ethernet (RoCE) networks. And, expectedly, it provides all of DB2 pureScale’s availability advantages, including online member recovery and rolling updates, and DB2 pureScale’s very strong scalability attributes. Here is an example of the throughput scaling experienced in the lab for an example OLTP workload running both TCP/IP, and RoCE: 

http://www.ibmbigdatahub.com/sites/default/files/blog_image_3.png

Stay tuned for upcoming posts for more information about the release of DB2 Linux, UNIX and Windows Version 11.1. Also, watch a DB2 technology review webinar, and continue your research on the next-generation database software by downloading a 90-day trial.