| Author |
Message
|
| rabee_nawash |
 Posted: Wed May 04, 2016 12:12 pm Post subject: F5 and MQ Gateway |
 |
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
Dears,
I have a situation where there is a queue manager gateway in front of two nodes of IIB, the customer want to add another MQ Gway QM , the consumers are different applications which not all of them support communicating with two gateways, so they suggest to add F5 between the consumers and GWs to do the load balancing. Is this acceptable scenario and is there a specific configuration we need to do on the QW level. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed May 04, 2016 12:21 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Lots of discussion here about F5 and MQ.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| hughson |
| Posted: Wed May 04, 2016 2:03 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
It is acceptable to put F5 BigIP between clients and queue manager, but not between queue manager and queue manager.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Thu May 05, 2016 2:37 am Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
Thank you, I read all the related discussions regarding F5 with MQ ,
But my question if F5 is only used for load balancing And not for fail over as the discussions says, how the client channel table will be configured since the ip will be only for the vertical ip provided through f5.
Another thing in this scenario why I still need the gateways, I can do the load balancing directly to the IIB queue manager.? Did any body configured similar setup |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Fri May 06, 2016 11:18 pm Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
| Hi masters, any clue from your side will be so much appreciated |
|
| Back to top |
|
|
| hughson |
| Posted: Fri May 06, 2016 11:59 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
If you have a router such as F5's BigIP balancing the connections between your two desired backends, then the CCDT only needs one entry with the hostname/IP Address that does said balancing.
However, if you are using a CCDT, then you don't need F5 to do the balancing because you can put all your entries for direct connectivity to each back end and the clients will do some semblance of balancing themselves. Just make sure that CLNTWGHT is non-zero.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Sat May 07, 2016 1:59 am Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
| Thank you Morag, this means that I should create the same Queue managers names , I believe this is not best practice |
|
| Back to top |
|
|
| hughson |
| Posted: Sat May 07, 2016 2:07 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| rabee_nawash wrote: |
| Thank you Morag, this means that I should create the same Queue managers names , I believe this is not best practice |
I'm confused. What means you need to have the same named queue managers?
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| rabee_nawash |
| Posted: Sat May 07, 2016 5:37 am Post subject: |
|
|
Apprentice
Joined: 01 Dec 2014
Posts: 27
|
| I mean if I will define the channel to connect to f5 ip, what is the queue manager name which I should specify is it for the queue manager in gateway 1 or gateway 2 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat May 07, 2016 6:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rabee_nawash wrote: |
| I mean if I will define the channel to connect to f5 ip, what is the queue manager name which I should specify is it for the queue manager in gateway 1 or gateway 2 |
How about you don't fill in that information and only fill in hostname(or ip), channel name and port? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat May 07, 2016 1:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| hughson wrote: |
However, if you are using a CCDT, then you don't need F5 to do the balancing because you can put all your entries for direct connectivity to each back end and the clients will do some semblance of balancing themselves. Just make sure that CLNTWGHT is non-zero.
|
One big benefit of doing it this way is that the source IP address will be seen by the Queue Manager as the actual client. If you go thru the F5 for load balancing, the source IP address seen will be that of the F5, which makes CHLAUTH rules based on IP address useless. The F5 option also eliminates a very important trouble shooting option - what source IP address has a queue open.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| hughson |
| Posted: Sat May 07, 2016 1:40 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| rabee_nawash wrote: |
| I mean if I will define the channel to connect to f5 ip, what is the queue manager name which I should specify is it for the queue manager in gateway 1 or gateway 2 |
You don't have to specify a queue manager name in a client application, specifically for such setups.
You should certainly have each queue manager uniquely named as per the guidelines from IBM.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| jcv |
| Posted: Mon May 09, 2016 7:58 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| hughson wrote: |
| It is acceptable to put F5 BigIP between clients and queue manager |
I don't know if rabee_nawash needs XA transaction management, but in that case both such CCDT with multiple qmgr entries and F5 are not acceptable, for the same reason, for the time being. Right? |
|
| Back to top |
|
|
| hughson |
| Posted: Mon May 09, 2016 2:57 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Very well said. It's all about state. If your connection is stateless then you can use such a router.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| jcv |
| Posted: Fri May 13, 2016 6:36 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
Let me summarize this to see if I understand that correctly.
First, there is a persistence (or stickiness) router setting which controls that after connection is established all subsequent requests are passed to the same node within that connection. When session replication is not possible between nodes, such as in case of two regular qmgrs behind an external load balancer, sticky session is conditio sine qua non.
Second, there is a connection affinity for automatic client reconnection: if connection is broken, mq client may try to reconnect automatically inline to only the original qmgr where connection was originally established. Or to any available qmgr: that is no affinity.
Third, there is a connection affinity for additional connection that is supposed to be established to the same qmgr as some previous. Such as with child sessions of an MDB connection that should connect to the same queue manager as the parent browsing connection, XA transaction manager and application connection, application issuing one connection for putting request and another for getting reply, when it arrives to the same qmgr (that one is an opposite problem to sticking to the same connection when reply may arrive to a different qmgr (due to a qmgr cluster LB)), etc...
Basically, there is no way at the moment to tell mq client to which qmgr it is supposed to connect when confronted with options that enable it to connect to "wrong" qmgr.
So there are basically three possible ways of dealing with that problem.
First is to rewrite application code so that it doesn't issue excessive connections when it can work with only one. That applies to XA and MDB as well.
Second is to implement connection replication between qmgrs.
Third is to implement changes in mq client code so that preffered (or mandatory) qmgr connection destination can be passed at connect time as an optional argument. Right? |
|
| Back to top |
|
|
|
|
