Db2 pureScale – The Deployment Journey [10 Years On]

Earlier this year Db2 pureScale deployments were made available as a bring-your-own-license (BYOL) option through the AWS Marketplace with a pre-packaged template and point/click interface. This significantly simplifies the deployment process.  It facilitates setting up a pureScale cluster from what used to be weeks or months to less than an hour. With a beaming and contented smile, I reflect on the pureScale deployment journey, what it was and what it is now.

Click image to enlarge

pureScale born – Data Sharing now on Db2

Arguably one of IBM’s most important features for Db2, pureScale was announced more than 10 years ago, back in October 2009. It quickly caught the attention of the industry.  Based on leading System Z data sharing technology, Db2 pureScale integrates IBM technologies to keep critical systems highly performant and highly available.

The initial deployment however had stringent requirements – IBM Power servers, AIX as the operating system, and InfiniBand network to allow for high-speed, low-latency communication between the members and the PowerHA pureScale servers. It was no surprise then that our team had to go to the only place that housed a pureScale environment in Europe, the IBM Labs in Boeblingen, Germany to gain some hands-on experience on Db2 V9.8.

pureScale – Deployment restrictions eased

It quickly became apparent that the uptake on pureScale was quite restricted due to the required pre-requisite hardware stack. In 2011, with Db2 V9.8.3, you could now deploy pureScale on IBM System X servers housing SUSE Linux Enterprise Server. A high-speed RDMA network to connect the CFs and the database members could now be built on either InfiniBand or 10 Gigabit Ethernet architecture.

In later fixpaks of Db2 V9.8 and V10.1, the restriction of deploying pureScale only on IBM System X servers was relaxed and more commodity x86 servers and RHEL.

pureScale using TCP/IP – Deployment restrictions eased, again!

Many years back, I was working on a pureScale POC with one of our customers. Availability was the primary objective for this customer and as such pureScale fitted the bill perfectly, or so I thought. Even though the customer decided to use 10GE RoCE (RDMA over Converged Ethernet) as the cluster interconnect, it quickly became apparent that for Linux-based configurations, only Mellanox adapters were supported for pureScale. The lead time on deciding to procure these new adapters and then actually get them meant other things took priority for the customer and the POC was put on hold, unfortunately. And we lost a potential pureScale customer, due to a deployment restriction.

Then came Db2 10.5.4 “Cancun Release” and we had a solution for customers with a highly available SLA requirement. One of the pureScale deployment options in that release was RDMA-less pureScale. A pureScale cluster could now be set up without requiring specific InfiniBand or 10GE RoCE adapters for the cluster interconnect. TCP/IP sockets can be used instead for the cluster interconnect.  This deployment option:

• Addressed customer needs where availability is more of a paramount SLA than enhanced performance in a production environment.
• Made it easier for customers to deploy pureScale and evaluate the technology in test or development systems.
• Allowed for pureScale to be implemented in virtualized environments, like VMware.

2-node pureScale – Ease of licensing

There was still a glitch though. pureScale was only available in Db2 Advanced Enterprise Server Edition (AESE). This meant that even though customers loved the high availability pureScale provided, they simply could not justify the additional licensing cost of moving from their current Db2 Workgroup Server Edition (WSE) or Enterprise Server Edition (ESE) up to the corresponding AESE in order to use pureScale.

To address this, IBM introduced the Business Application Continuity (BAC) offering in Db2 10.5.5, which was a purchasable option on top of WSE and ESE that allowed you to create a two member active/admin pureScale cluster. The active member could be used to run your application workloads and the other admin member was not only available as a standby in case that active member was unavailable, but also allowed to run administrative operations like Backup, Restore, Runstats, Reorgs, and many others. In terms of licensing, only the active member needed to be fully licensed (for either WSE or ESE plus BAC). The licensing of the admin member fell under Db2’s warm/idle standby licensing which meant a much-reduced cost.

With Db2 11.1 came a much-simplified installation and deployment process for pureScale. Many of the pureScale installation processes had been simplified, making the adaption of pureScale much easier. Furthermore, the distinct 2 member (active/admin) pureScale cluster capability we talked about earlier was made available in all Db2 11.1 Editions. This allowed customers to address their high availability needs without having to move from their current Db2 edition. I loved that!

pureScale – Deployment could not get easier

Finally, pureScale deployment gets even simpler and faster with the availability of pureScale and Db2 V11.5.6 on AWS Marketplace earlier this year. An on-premise pureScale deployment could take weeks or months to set up the cluster – including sizing, hardware procurement, physical setup, and Db2 instance configuration. Now, on AWS with the 1-click automated process, deployment of the pureScale cluster can be done in less than 60 minutes. The current listing on AWS Marketplace has been updated to coincide with the current Db2 11.5.8 software release, and pureScale with HADR is available across AWS regions on both RHEL and SLES.

Quite a deployment journey for Db2 pureScale. Given it is the cream of the crop when it comes to Db2 high availability, I would encourage everyone to a take look at the pureScale on AWS Marketplace option. And I am sure you will be pleasantly surprised at the ease of deployment.

• Share