DB2 HADR – clustered Meeting servers

I needed to create a cluster of Sametime Meeting servers to ensure high availability. With WebSphere (like Domino) this is relatively easy but what about the database? DB2 HADR (High Availability and Disaster Recovery) ensures that two databases are kept in sync with each other in case one of the databases fails.

HADR does this by creating a primary and standby database. The primary is always in use whilst the standby is kept in sync using internal processes to ship database log buffers to it. A process at the standby server then replays the log records directly to the standby database. If the primary fails the standby database can be promoted to primary to take over responsibilities.

  • This is not a seamless fail over, it requires manual interaction to promote the standby database.
  • To achieve seamless fail over other tools such as TSA or HACMP must be used.
  • The standby cannot be accessed, only the primary can be read or written to.
  • In DB2 v9.7 the standby can be used for reads but if you cannot write to it I am unsure of the effect this might have on Sametime.

Instead of installing the limited use (CZLF7ML) version of DB2 for Linux I opted to use the full version (C1X0UEN) which gave me greater control over user accounts and install directory. I decided to use the GUI to set up HADR, good thing about it is that at almost every step you can see the command that the GUI is compiling should you wish to script it next time round.

Screen shots detailing HADR set up.

The deployment plans for the Meeting servers both have to point to the same DB2 fqhn as defined in the “Connect to DB2 databases” in the SSC. If the primary DB2 server should fail WebSphere will not be able to read/write to it even if the standby has been promoted to the primary. To fix this Automatic Client Reroute can be used within WebSphere.

You need to make each DB2 server aware of the other so that when a client connects it knows how to reroute it should it fail. You need to run the following command on each server referencing the other in the command line.

./db2 update alternate server for database STMS using hostname db2.acme.com port 50000

Log in to the SSC and go to Resources – JDBC – Data sources. You will see a number of JDBC data sources, normally two for each Meeting node and two for the cluster.

Click on each (checking at the bottom of the page that it references STMS and not STSC) and then select “WebSphere Application Server data source properties” on the right hand side.

Under “DB2 automatic client reroute options” you have options of adding alternate servers and the ports they listen on. You configure your second database here. Make sure the changes synchronise with your nodes and that the applications servers are restarted afterwards.

If your primary database fails WebSphere will then connect to the alternate DB2 server as long as the alternate server has been made the primary.