I am working on a High Availability solution using multi-instance queue managers and F5 BigIP/LTM host which holds the pool of active and passive MQ nodes. The BigIP configuration will have a health check script which will identify the active and passive nodes for the MI queue manager and redirect the client connections to the active node all the time. In order to achieve this I like to know all the internal checks performed by a multi-instance queue manager before switching from Active node to passive node so that I can apply the same logic on our health check scripts. Also I like to know whether BigIP configuration supports a MQ health check?
Multi-instance queue managers compete for leased file locks on an NFS4 file system. The passive node activates when it acquires the lock. F5 will not be able to use the same method to check on QMgr health.
The best advice is to use the functionality built into MQ. As of the end of next month (September 2015) all versions of MQ in support by IBM can use a multi-instance CONNAME. So if you need F5 to find the active QMgr as of next month, the only possible reason is that the clients are on an unsupported version of MQ. Hopefully, that's a higher priority issue than configuring F5 to duplicate native MQ functionality - assuming your company is paying for IBM support and expects to receive it when a PMR is opened.
That said, to configure F5 with MQ you should set it up for TCP half-connect and then to poll the MQ listener port on each of the two IP addresses. If it can connect, then the live IP is the active QMgr and the other IP in the pair is a QMgr that has failed or is in standby. There are cases in which the MQ listener is up but the application cannot connect, for example when the QMgr is quiescing, but it's the app's job to deal with those types of connection issues. F5 cannot shield the app from that.