Hi,

The IBM DB2 Version 8.2 Automatic Client Reroute Facility article is listed at site.
http://www-128.ibm.com/developerwork...512zikopoulos/

We want to have automative client reroute when ever there is failover. is there any better solution available other than this.


Thanks in advance.

It works well ouut of the box for type 2 driver (DB2 runtime client), but requires some extra coding for type 4 driver connections (universal driver) in order to persist the alternative server information.

Also, for either connection, your application will need retry logic if you get the specific error message that a re-route has occured.

Thanks for the reply.

Actually we have couple of Client Applications using DB2. For some applications it is possible to write re-route logic. For example the applications written in java can have the re-route logic. But In Crystal Reports the database URL(jdbc:db2://server:50000/database) is hardcoded, which can not be changed on the fly. So re-route logic cannot be written for Crystal Reports.

The requirement is: with out changing the DB server credentials hardcoded in the application , the application should access the DB Server available online whethere primary or secondary.

Is there any solution available for this problem?

Thanks in advance.

Well, before you read my response, I'll have to say that my practical experience with such client reroute is very limited...

From what I understand, the automatic client reroute facility is a db2 thing and therefore requires your client to have had prior knowledge about alternate servers from the 'unavailable' db2 instance it is trying to connect to ... In other words, if you boot a Windows machine and try to connect to a db2 instance that is not available, you will not be able to connect, as the server is not available to return the alternate server's information ...
Regarding the re-try logic, it is because when a failover happens, the in-flight transactions are rolled back and a message needs to be passed back to the application ... In case of Crystal Reports, I would think that you may not get any message back unless you are in the middle of a report generation (ie, a Unit of work) when the instance goes down ... Otherwise, if a connection already exists or an alternate location is in driver's static memory(for type-4 jdbc) or in the directory cache (for appls using the db directory), the re-route will be seamless.


As far as your question on better approach goes, I would think that you have to consider other sophisticated HA products - that are hardware/network level HAs instead of just DB level HAs.

HTH

Sathyaram

There "may be" some additional DB2 HA options coming from IBM shortly.

Thanks for the reply.

It seems that HA options will work.

In the article An Overview of High Availability and Disaster Recovery for DB2 UDB available at URL
http://www-128.ibm.com/developerwork...304wright.html .
Following software listed under "Specialized HA software option" Heading

1) High Availability Cluster Multiprocessing (HACMP - AIX)
2) Microsoft Cluster Server (MSCS) - Windows
3) Sun Cluster - Sun
4) Steeleye's Lifekeeper - Linux and Windows

Where it is mentioned that [B]No changes to application or client needed.[/B]

The same article says "When a failover takes place, all applications are disconnected, and the client returns a communication error condition to the application." ... This scenario is not much different from the automatic client reroutes. The main difference here is that rerouting is outside the scope of the db2 instance ... So, any client will be able to access the server irrespective of whether it knew about the instance's location before ..

I think your best HA solution will depend on many factors .. Though avoiding application rewite is one factor, it is not everything ... For best results, you'll have to look at the bigger picture ... say, what is the point to have the database up and running when your application server is down ..

HTH

Sathyaram

Thanks for the reply.

Yes your are correct in saying about think about big picture.

Right now our major concern is DB. and we are also analysing about Application server HA with clustring etc.

Let me talk about DB.

I assume Specialized HA software option will sovle the issue.

Here is the list of HA software.

1) IBM Tivoli (Tivoli System Automation TSA)
2) High Availability Cluster Multiprocessing (HACMP - AIX)
3) Microsoft Cluster Server (MSCS) - Windows
4) Sun Cluster - Sun
5) Steeleye's Lifekeeper - Linux and Windows

We are thinking about IBM Tivoli - TSA as a remedy for our problem. With out modifiying the client code Java, Crystal Reports etc. TSA claim to provide the facility to access the alternate resource.

In TSA we can Set Up Highly Available (HA) IP Addresses by involing redundant network interface cards (NICs).

So here is the architecture.

T1 is a system with TSA on it.
Pd is a primary database system with redundant network interface cards .
Sd is a secondary(stand by) database system with redundant network interface cards . HADR is also established between Pd and Sd

Heart beats of both Pd and Sd are monitered by T1 and it automatically shift the Sd to Pd and Pd to Sd whenever there is failover at Pd and vise versa.
Tivoli handles the automatically shift from secondary to primary and primary to secondary.

So Tivoli solve my two problems:
1) Make an IP Addresse Highly Available (HA) with redundant network interface cards at both the servers Pd and Sd.
2) Automatically Shift the Sd to Pd. and No transaction loss as they claim.

Thanks for your valueable comments.

Istikhar Ahmad.
Systems Architect.
www.lmkr.com

In my experience, Tivoli TSA does not work well with HADR, although it is free (with DB2 HADR) and there are some improvements in DB2 V9 HA scripts that may help. Veritas VCS (with HADR agent) seems to work better than TSA with HADR, but is an extra expense.

IBM "may" be introducing some new HA solutions shortly, so if you can hang-on for a month or two, I would not commit to any new architecture. You may be able to get more details from you local IBM marketing team (if you have a non-disclosure agreement in place).

Thanks for your reply.

Can you please provide some details what sort of issues were there while using Tivoli for for HADR.

Whether automatic switching was not working?
Any configuration issue?
etc?

Please comment

Thanks
Istikhar
istikhar@gmaila.com

One of the biggest issues is that TSA is not idiot proof, which is a problem IMO for software that is designed to manage a HA cluster.

For example, with TSA you cannot issue normal DB2 commands to start and stop a DB2 instance (db2start, db2stop), or to do an HADR takeover (TAKEOVER HADR ON DATABASE database-alias), you must issue special TSA commands (or invoke HA scripts that come with DB2) instead of the normal DB2 commands for these functions. If you do issue the regular DB2 commands by mistake (which someone may do by instinct in a crisis situation), then your HADR cluster may become hosed if it is under the control of TSA.

For any software of this type, one of the main problems is trying to determine when a HADR takeover by force should be issued by the cluster manager if the primary server goes down. Unfortunately, this is not done in TSA by actually trying to connect to any databases, rather it is done by monitoring certain DB2 processes and certain resources (like network connections). This is not foolproof IMO. If an instance crashes, TSA will restart the Db2 instance and not do a takeover (if you use the supplied HA scripts).

One hint that I will offer is that if you have a public network (for application tier access to the database server) and a private network (for HADR replication between the primary and standby servers) then you need to make the public network a “critical resource.” Otherwise TSA may assume that since it can reach the primary server (from the standby server) via the private network, that everything is OK even though the public network to the primary server is down and the applications cannot reach the database.

The other suggestion is that you use the V9 DB2 HA scripts and V9 clients (type 2 or type 4). The client code was upgraded, and the HA scripts that come with V9 have been improved, even though there were no real changes to HADR itself in the V9 DB2 server code. You could use the V9 HA scripts with Version 8 server, and use the V9 clients with the V8 server, but these combinations are probably not supported by IBM.

The "automatic switching" a dual issue in that you want an automatic takeover to the standby to occur when the primary is not available, and you want the applications to perform automatic client reroute when the takeover occurs. One of the problems with V8 clients (especially the V8 type 4 clients) is that there is a TCP/IP timeout issue as to how long the client should wait on a hung connection (which would occur if the primary server crashed) before it gives up and tries the standby. This is not an issue with a planned takeover (not by force) when both servers are up and running, as would happen when you did a takeover to do maintenance on the primary server.

If you never make a mistake when issuing TSA commands, and use the latest version of DB2 clients and server (V9) then I would say TSA may work OK for you.

Marcus,
Thanks for your detailed reply.

Istikhar