In Db2 11.5 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 simplified the deployment process. It facilitates setting up a pureScale cluster from what used to be weeks or months to less than an hour. With the newly released Db2 12.1, pureScale now comes packaged with Pacemaker on Linux instead of TSA and continues to be easier to deploy. 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
pureScale deployment got even simpler and faster with the availability of pureScale and Db2 V11.5.6 on AWS Marketplace. 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. On AWS with the 1-click automated process, deployment of the pureScale cluster can be done in less than 60 minutes. 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.
TSA-less pureScale on Linux
I for one have had my fair share of hair-pulling episodes with TSA and there was no tear to shed when I found out that with Db2 12.1 on Linux comes the final episode of the journey to replace TSA with the well-established, industry recognised Pacemaker as the clustering solution of choice for Db2. This will allow for better recovery times, ease of deployment, and much more flexibility. Pacemaker prerequisites are automatically checked as part of the db2prereqcheck utility and Pacemaker is installed automatically as part of the Db2 install utilities (db2_install and db2setup). The upgrade process to pureScale 12.1 is also seamless from TSA to Pacemaker. This makes not only the deployment of a fresh Db2 12.1 pureScale install, but also an upgrade to Db2 12.1 pureScale easy. Additionally, to further ease deployment, there is now one utility (db2cm) for all configuration of Pacemaker and GPFS across all HA deployments with text-based diagnostic logging for all Pacemaker cluster activities.