Db2

I have utilized HADR since it was first added to DB2, and TSAMP for HA automation since 2013.  I am currently testing out Pacemaker for HA automation.  Historically, I have implemented with, and without, Primary VIPs depending on the year and the environment.  My usual considerations are Configuration Management, Split Brain risk, failover time, supportability, Network Team considerations, and anything else I may be forgetting.  This specific implementation spans subnets, so there are VLAN considerations.  I have found a few pertinent discussions here and have reviewed those.

Given such an implementation, does anyone have experiences, recommendations, thoughts, etc. they are willing to share on the topic of to VIP or not to VIP?

Thanks in advance, if you do!

#Db2

------------------------------
Jim Pearon
Contractor
Winsupply
Moraine OH
------------------------------

The primary reason I have a used VIP is to have application able to connect to the new primary database in case of a database failover (or failback)

Since you mention the implementation spans subnets you need to implement an Overlay IP instead. This is documented in below link for AWS implementation.

https://www.ibm.com/support/pages/setting-two-node-db2-pacemaker-cluster-overlay-ip-virtual-ip-aws-db2-v11580

We have used Pacemker Overlay IP and has worked flawlessly in our tests. I appreciate in some applications you can provide two IP addresses however it was not the case for our app and I have not tested it.

We have however tested the use of ACR  (Automatic Client reroute) for our setup and found Pacemker Overlay IP provides much faster failover time and worked every time. In comparison ACR was a hit or a miss.

I have utilized HADR since it was first added to DB2, and TSAMP for HA automation since 2013.  I am currently testing out Pacemaker for HA automation.  Historically, I have implemented with, and without, Primary VIPs depending on the year and the environment.  My usual considerations are Configuration Management, Split Brain risk, failover time, supportability, Network Team considerations, and anything else I may be forgetting.  This specific implementation spans subnets, so there are VLAN considerations.  I have found a few pertinent discussions here and have reviewed those.

Given such an implementation, does anyone have experiences, recommendations, thoughts, etc. they are willing to share on the topic of to VIP or not to VIP?

Thanks in advance, if you do!

#Db2

------------------------------
Jim Pearon
Contractor
Winsupply
Moraine OH
------------------------------

Thank you for this, @Divaker Goel !

I will share that on a FileNet P8 Platform implementation with multiple databases on a server, I observed better time-to-live for the application (JDBC Type 4 connections) using ACR.  However I attributed this to the application needing to connect to multiple databases in order to begin processing, and the VIPs depending on all other resources to come online, led to the quicker time-to-live for the application.  Of course this testing was completed long ago in Db2 v10.1 with TSAMP handling the automation, and currently with Pacemaker having quicker time-to-live than TSA it would interesting to retest that application in v11.5 with Pacemaker.

Thanks again!

The primary reason I have a used VIP is to have application able to connect to the new primary database in case of a database failover (or failback)

Since you mention the implementation spans subnets you need to implement an Overlay IP instead. This is documented in below link for AWS implementation.

https://www.ibm.com/support/pages/setting-two-node-db2-pacemaker-cluster-overlay-ip-virtual-ip-aws-db2-v11580

We have used Pacemker Overlay IP and has worked flawlessly in our tests. I appreciate in some applications you can provide two IP addresses however it was not the case for our app and I have not tested it.

We have however tested the use of ACR  (Automatic Client reroute) for our setup and found Pacemker Overlay IP provides much faster failover time and worked every time. In comparison ACR was a hit or a miss.

I have utilized HADR since it was first added to DB2, and TSAMP for HA automation since 2013.  I am currently testing out Pacemaker for HA automation.  Historically, I have implemented with, and without, Primary VIPs depending on the year and the environment.  My usual considerations are Configuration Management, Split Brain risk, failover time, supportability, Network Team considerations, and anything else I may be forgetting.  This specific implementation spans subnets, so there are VLAN considerations.  I have found a few pertinent discussions here and have reviewed those.

Given such an implementation, does anyone have experiences, recommendations, thoughts, etc. they are willing to share on the topic of to VIP or not to VIP?

Thanks in advance, if you do!

#Db2

------------------------------
Jim Pearon
Contractor
Winsupply
Moraine OH
------------------------------

Hi Jim,

I have tested various Pacemaker configurations a while ago, with and without VIP (and ACR), albeit in an AWS VPC (where the failover across subnets, i.e. Availability Zones, is enabled via the AWS Overlay IP addresses).

What I found was, unsurprisingly, that when both VIP (Overlay IP) and ACR are used, the application switching is as seamless as it can get following a DB failover.

I wrote two ebooks on the subject, which you can download (for free :-) from here:

    Automating HADR failovers with Pacemaker

    Configuring Db2 Pacemaker HADR cluster with QDevice in AWS

Hope this helps in your research, even if it's not strictly what you asked for!

Some time later, after I've done all of the above (research, testing, ebooks), I have stumbled upon the following articles which describe how an even more seamless application switchover can be configured:

    Operation of automatic client reroute for connections to Db2 on Linux, UNIX, and Windows systems from Java clients

    Operation of automatic client reroute for connections to the Db2 server from an application other than a Java application

 I haven't had the time (yet) to test the "seamless failover", as described in the articles above, but am planning to, and if this really works as described then the applications will truly never be aware of any failovers taking place on the DB level!

Regards, Damir

Thank you for this, @Divaker Goel !

I will share that on a FileNet P8 Platform implementation with multiple databases on a server, I observed better time-to-live for the application (JDBC Type 4 connections) using ACR.  However I attributed this to the application needing to connect to multiple databases in order to begin processing, and the VIPs depending on all other resources to come online, led to the quicker time-to-live for the application.  Of course this testing was completed long ago in Db2 v10.1 with TSAMP handling the automation, and currently with Pacemaker having quicker time-to-live than TSA it would interesting to retest that application in v11.5 with Pacemaker.

Thanks again!

The primary reason I have a used VIP is to have application able to connect to the new primary database in case of a database failover (or failback)

Since you mention the implementation spans subnets you need to implement an Overlay IP instead. This is documented in below link for AWS implementation.

https://www.ibm.com/support/pages/setting-two-node-db2-pacemaker-cluster-overlay-ip-virtual-ip-aws-db2-v11580

We have used Pacemker Overlay IP and has worked flawlessly in our tests. I appreciate in some applications you can provide two IP addresses however it was not the case for our app and I have not tested it.

We have however tested the use of ACR  (Automatic Client reroute) for our setup and found Pacemker Overlay IP provides much faster failover time and worked every time. In comparison ACR was a hit or a miss.

I have utilized HADR since it was first added to DB2, and TSAMP for HA automation since 2013.  I am currently testing out Pacemaker for HA automation.  Historically, I have implemented with, and without, Primary VIPs depending on the year and the environment.  My usual considerations are Configuration Management, Split Brain risk, failover time, supportability, Network Team considerations, and anything else I may be forgetting.  This specific implementation spans subnets, so there are VLAN considerations.  I have found a few pertinent discussions here and have reviewed those.

Given such an implementation, does anyone have experiences, recommendations, thoughts, etc. they are willing to share on the topic of to VIP or not to VIP?

Thanks in advance, if you do!

#Db2

------------------------------
Jim Pearon
Contractor
Winsupply
Moraine OH
------------------------------