2

There is a very acute problem with the distribution of sessions through the balancer in case of recovery of one of the fallen nodes.

I will describe briefly how the interaction of the two modules is arranged:

On the one hand, an application on WebShere Application Server (hereinafter referred to simply as WAS)

On the other hand, it is not known which application

Between them - 2 WebSphere MQ servers

WAS applications connect to WebShere MQ through a balancer

The second side connects directly to the MQ servers (because it can distribute connections by itself)

schema

When a problem occurs:

  1. One of the MQ servers crashes. At this point, all sessions are distributed by the balancer to one of the remaining MQ servers. The second application also continues to work with only one MQ server. There is no problem.
  2. It takes some time and the MQ server is restored to work. The second application instantly restores connections to the second MQ server. The balancer continues to keep all sessions on one node, since this JMS and connection pool are quite sufficient (here it is probably worth saying that the application works only through the queue connection factory and without activation specifications). Thus, WAS servers do not read the messages that application 2 places on the server MQ until the connection pool is insufficient and a new session is opened, which is already distributed by the balancer to the second MQ. But this period can be very long and 50% of messages will fall into timeouts (by application 2).

Hence the question.

Is it possible to somehow organize the process so that when restoring the second MQ, part of the sessions on the balancer will either be transferred to the second MQ server, or a new session (instantly) from the WAS side will just be generated (for example, if we start using activation specification maybe) ?

TheDESTROS
  • 375
  • 3
  • 9
  • 1
    If the app on the left is only servicing requests from the app on the right, under current IBM MQ v9.1 LTS and lower one option is to deploy the application twice to each WAS server where each instance is configured to connect directly to a single IBM MQ queue manager. In this way when one MQ server goes down each WAS instance still has connections to the other server to service requests going to the available server, and when the down server comes back up they each will reconnect to and service connections on that queue manager. – JoshMc Sep 15 '19 at 12:48
  • 1
    In MQ v9.1 CD (Continuous Delivery) IBM is adding a new feature called Consistency Cluster where the queue manager and the client work together to keep connections load balanced across the available queue managers. With this new feature when the 2nd queue manager is restored the 1st queue manager will notify half of the connected clients disconnect and reconnect to the 2nd queue manager. – JoshMc Sep 15 '19 at 12:51
  • Thanks for the comments. We came to the conclusion that it is easier to get rid of the balancer and just connect immediately to two MQs. It really is much easier. – TheDESTROS Dec 11 '19 at 08:05
  • Wrote this up as an answer with a link to documentation on the second option. – JoshMc Feb 20 '20 at 14:25
  • Thank you for the accept. – JoshMc Mar 04 '20 at 12:30

1 Answers1

1

If the app on the left side of the diagram is only servicing requests from the app on the right, under current IBM MQ v9.1 LTS and lower one option is to deploy the application twice to each WAS server where each instance is configured to connect directly to a single IBM MQ queue manager bypassing the load balancer. In this way when one MQ server goes down each Websphere application server still has connections from one application instance to the other MQ server to service requests going to the available MQ server, and when the down MQ server comes back up the second application instance on each Websphere application server will reconnect to and service connections on that queue manager.

In MQ v9.1 CD (Continuous Delivery) IBM is adding a new feature called uniform clusters where the queue manager and the client work together to keep connections load balanced across the available queue managers. With this new feature when the 2nd queue manager is restored the 1st queue manager will notify half of the connected clients disconnect and reconnect to the 2nd queue manager.

See IBM Knowledge Center page IBM MQ 9.1.x>IBM MQ>Planning>Architectures based on multiple queue managers>Planning your distributed queues and clusters>Designing clusters>Uniform clusters>Automatic application balancing:

When there are at least as many instances of the same application as there are queue managers, the uniform cluster constantly ensures that every queue manager has at least one instance of the application connected.

JoshMc
  • 184
  • 7