What is new in the IBM DB2 with BLU Acceleration Pattern version 188.8.131.52?
Hendrik van Run 310001AHXF Visits (7632)
IBM released version 184.108.40.206 of the DB2 with BLU Acceleration Pattern on 4th December 2015. Although previous versions of this pattern type were made available through IBM Fix Central, this latest version of the pattern can also be obtained through IBM Passport Advantage.
Update: Make sure to review the Frequently Asked Questions here as well, they provide additional useful information for this pattern.
Downloading from IBM Passport Advantage
PureApplication System clients should automatically be entitled to this, PureApplication Service and PureApplication Software clients require a separate license agreement to be in place. And on that subject, it is worth spelling out that the DB2 with BLU Acceleration Pattern actually installs and configures DB2 10.5 Advanced Workgroup Server Edition (so that is what your license needs to cover). For reference, this
IBM DB2 with BLU Acceleration Pattern V1.2.3 Multiplatform Multilingual (CN86WML)
Installing the new pattern type
Once downloaded, you can simply run the commands below from the Pure CLI to import the new pattern type:
>>> newpattern = depl
For sake of completeness, this pattern is supported on both Intel and POWER implementations of PureApplication System and PureApplication Software (and on Intel PureApplication Service). Note that we support both RHEL 6.6 and 7.1 (Intel) as well as AIX 6.1 and 7.1 (POWER).
Specify desired DB2 Fix Pack level
The first major change in this new version is the ability to specify the exact DB2 Fix Pack level within the Virtual System Pattern or at deployment time. Previously the Fixpack level was determined by the version of the pattern type that was installed and enabled in the catalog. As shown below, the DB2 software component now offers a selection of DB2 10.5 Fixpack 4, 5 or 6.
Note however that the 220.127.116.11 pattern type only contains the Fix Pack 6 binaries. The entries for Fix Pack 5 and Fix Pack 4 correspond to version 18.104.22.168 and 22.214.171.124 of the pattern type respectively. So if you would like to use Fix Packs 4, 5 and 6 you must have pattern types 126.96.36.199, 188.8.131.52 and 184.108.40.206 installed!
Finally, there is now an option to install a Fix Pack at deployment time as well. For example, when DB2 10.5 Fix Pack 7 ships you could simply deploy DB2 10.5 Fix Pack 6 and automatically apply Fix Pack 7 at deployment time (instead of applying this after deployment). I will add some more details about this here shortly.
Configure a Virtual IP Address for a DB2 HADR database
For some time we have been able to install and configure a DB2 database with HADR configured through a Virtual System Pattern using the DB2 software component and script packages. However we always had to rely on DB2 Automatic Client Re-routing (ACR) in order to leverage the additional increase in resilience delivered by HADR. In other words, each DB2 cilent must "know" about the hostname/IP address of both the primary and standby DB2 VM. The new pattern type introduces the ability to automatically configure and setup a Virtual IP Address (VIP) that can act as a single end point for the DB2 HADR database. In other words, a DB2 client only needs to be configured with the VIP and no longer requires knowledge of the individual primary and standby hostnames/IP addresses. The Virtual System Pattern Default DB2 OLTP Pattern with HADR and VIP for Linux provides a good starting point for using DB2 HADR with a VIP.
When examining the aforementioned Virtual System Pattern in more detail, you will notice that there is a new add-on DB2 VIP Linux add NIC used to assign an additional IP address to the Virtual System Instance at deployment time. This refers back to the name of the DB2 database that is to be configured with HADR. Note that the use of an add-on here is required in order to obtain an additional IP address from the IP group at deployment time.
Once deployed, the VIP from the DB2 HADR Virtual System Instance can be obtained from the stdout of the add-on DB2 VIP Linux add NIC. Note that this was from a deployment on PureApplication System, where eth0 is assigned to the cloud management network, eth1 to the data network and eth2 is used as second virtual network interface on the same data network.
*** searching for NIC with MAC address 00:50:56:ae:39:60 *** It is Red Hat Enterprise Linux Server release 7 *** iface eth2 has MAC address 00:50:56:ae:39:60 *** INTF=eth2 *** provided address 172.18.173.4 is of type IPv4 *** configuring eth2 with IP address 172.
A final note on the implementation of DB2 HADR through the DB2 BLU Acceleration Pattern on PureApplication. IBM Tivoli System Automation (TSA) software is used to assign the role of primary and standby to the DB2 databases on both VMs. Some clients wonder what is used as the tiebreaker for TSA, as this is currently not documented in the IBM Knowledge Center. At deployment time, the pattern will obtain the default gateway of the IP group used for the data network (eth1 on PureApplication System) and this is configured as the tiebreaker. Ping requests are sent to the default gateway at regular internals, so the implication of this is that the default gateway and external network must allow for ICMP traffic!