Author |
Message
|
mgrx |
Posted: Thu Oct 01, 2015 9:02 am Post subject: Multi-instance queue manager and F5 Load balancing |
|
|
 Novice
Joined: 01 Oct 2015 Posts: 20
|
Hi,
Background:
We are about to rebuild our integration infrastructure and planning on utilizing the Multi-instance queue manager functionality on the queue manager we use as gateway towards customers and business partners. At the same time we will most likely purchase F5 BIG-IP. We could solve the High Availability and one IP with a external software (Veritas, Redhat Cluster Suite and so on), but if we can save money and use F5 embedded functionality that would be great!
I have a few questions, and hoping to get some help on the subject:
(I realize that the questions below might be better suited for F5 Salesteam, however I believe that alot of people might wondering about this here)
Can the F5 BIG-IP be used to handle QMGR <-> QMGR connectivity (ie. sender - receiver channels)?
Multi-instance queue manager still has the listener port open on the standby node, how can I find a way to detect that the standby node is not used?
PS.
I know that we could use the active and standby address in CONN/CCDT, but we would like to avoid that towards our customers/business partners to simply their integration towards our frontend. There is also alot of different versions and adapters connecting and compability is a must. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Oct 01, 2015 9:30 am Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mgrx wrote: |
Can the F5 BIG-IP be used to handle QMGR <-> QMGR connectivity (ie. sender - receiver channels)? |
No, or at least not directly. The sender / receiver MCAs keep a sequence number to ensure there's no message loss. If the F5 is spraying (or even moving) the traffic so the sender is no longer talking to the receiver it was a moment ago, the channel will go into retry. This is manageable if you're just using the F5 to switch from an active to a passive once in a blue moon, though frankly I'd advise against it - if you get used to seeing retrying channels, you start to assume it's the F5 and miss when it's actually a problem. If the F5 is spraying traffic, it's unworkable.
mgrx wrote: |
Multi-instance queue manager still has the listener port open on the standby node, how can I find a way to detect that the standby node is not used? |
Ask NFS which node has the file lock. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Thu Oct 01, 2015 9:35 am Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
mgrx wrote: |
PS.
I know that we could use the active and standby address in CONN/CCDT, but we would like to avoid that towards our customers/business partners to simply their integration towards our frontend. There is also alot of different versions and adapters connecting and compability is a must. |
Putting client connections (SVRCONN / CLNTCONN) connections through an F5 works fine; synchronous connection with no sequence numbers. Be aware that the F5 must be configured to route all the traffic for a single MQ connection to the same queue manager. So if you make 20 client connections through the F5 to 2 queue managers, 10 of them will go to one queue manager, 10 to the other but the next MQ operation on that thread through the F5 must go to the same queue manager the connection was routed to or you'll get 2009 / 2019 errors. This is not the default, as the F5 is built to spray web service requests with no thought to where the last HTTP POST was directed. I believe the F5 refers to a session configured the way an MQ client needs it to be as "sticky" - consult the documentation and/or someone who knows a lot more about this than I do.
 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mgrx |
Posted: Thu Oct 01, 2015 1:28 pm Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Novice
Joined: 01 Oct 2015 Posts: 20
|
Vitor wrote: |
No, or at least not directly. The sender / receiver MCAs keep a sequence number to ensure there's no message loss. If the F5 is spraying (or even moving) the traffic so the sender is no longer talking to the receiver it was a moment ago, the channel will go into retry. This is manageable if you're just using the F5 to switch from an active to a passive once in a blue moon, though frankly I'd advise against it - if you get used to seeing retrying channels, you start to assume it's the F5 and miss when it's actually a problem. If the F5 is spraying traffic, it's unworkable.
|
I see, yes if we use it .. it will be in a active/passive solution. but I guess its not the best solution to the problem.
Vitor wrote: |
Ask NFS which node has the file lock. |
Oh, good idea, but then the F5 needs access to shared filesystem.. guess that managable though.
Vitor wrote: |
Putting client connections (SVRCONN / CLNTCONN) connections through an F5 works fine; synchronous connection with no sequence numbers. Be aware that the F5 must be configured to route all the traffic for a single MQ connection to the same queue manager. So if you make 20 client connections through the F5 to 2 queue managers, 10 of them will go to one queue manager, 10 to the other but the next MQ operation on that thread through the F5 must go to the same queue manager the connection was routed to or you'll get 2009 / 2019 errors. This is not the default, as the F5 is built to spray web service requests with no thought to where the last HTTP POST was directed. I believe the F5 refers to a session configured the way an MQ client needs it to be as "sticky" - consult the documentation and/or someone who knows a lot more about this than I do. |
Well, as it would be an active/passive installation I guess we are fine on that front atleast. (SVRCONN/CLNTCONN).
I read some posts on the F5 and MIQM on this forum, and i think it was mqjeff(?) who wrote something about moving the virtual IP with an MQ service in a MI setup, would that actually work without some kind of external software for HA?
anyhow,,
Thanks alot Vitor, really appreciate it! |
|
Back to top |
|
 |
zpat |
Posted: Thu Oct 01, 2015 10:00 pm Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Vitor wrote: |
No, or at least not directly. The sender / receiver MCAs keep a sequence number to ensure there's no message loss.
|
Sequence number is not checked for non-persistent messages - so if this is the requirement it will work. Look at the NPM setting. _________________ Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Oct 02, 2015 3:09 am Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mgrx wrote: |
Multi-instance queue manager still has the listener port open on the standby node, how can I find a way to detect that the standby node is not used?
|
It need not be. This is a choice depending on how you are running your MQ Listener...
So how are you running & starting your MQ Listener ? (Specifics please)  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mgrx |
Posted: Fri Oct 02, 2015 4:12 am Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Novice
Joined: 01 Oct 2015 Posts: 20
|
fjb_saper wrote: |
It need not be. This is a choice depending on how you are running your MQ Listener...
So how are you running & starting your MQ Listener ? (Specifics please)  |
Well, the tests I have been doing have been with CONTROL(QMGR). If thats what you mean? |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Oct 02, 2015 6:14 am Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mgrx wrote: |
fjb_saper wrote: |
It need not be. This is a choice depending on how you are running your MQ Listener...
So how are you running & starting your MQ Listener ? (Specifics please)  |
Well, the tests I have been doing have been with CONTROL(QMGR). If thats what you mean? |
That's what I meant. You mean to say that on the passive side if you run netstat -an | grep mqport it shows as listening when the qmgr is in standby?
And does not show up when the qmgr is shut down (not running in standby)? _________________ MQ & Broker admin |
|
Back to top |
|
 |
mgrx |
Posted: Fri Oct 02, 2015 8:54 am Post subject: Re: Multi-instance queue manager and F5 Load balancing |
|
|
 Novice
Joined: 01 Oct 2015 Posts: 20
|
fjb_saper wrote: |
mgrx wrote: |
fjb_saper wrote: |
It need not be. This is a choice depending on how you are running your MQ Listener...
So how are you running & starting your MQ Listener ? (Specifics please)  |
Well, the tests I have been doing have been with CONTROL(QMGR). If thats what you mean? |
That's what I meant. You mean to say that on the passive side if you run netstat -an | grep mqport it shows as listening when the qmgr is in standby?
And does not show up when the qmgr is shut down (not running in standby)?
|
Well.. yes... so the port is suppose to go down as soon as the qmgr goes standby?
Then there must be some kind of misconfiguration somewere or bug..
Code: |
[root@foo ~]# runmqsc QM1 <<< "DISPLAY LISTENER(*) ALL"|grep -A4 CONTROL && dspmq -x && netstat -an |grep 1414
LISTENER(SYSTEM.DEFAULT.LISTENER.TCP) CONTROL(QMGR)
TRPTYPE(TCP) PORT(1414)
IPADDR( ) BACKLOG(0)
DESCR( ) ALTDATE(2015-09-02)
ALTTIME(10.25.52)
QMNAME(QM1) STATUS(Running)
INSTANCE(foo) MODE(Active)
INSTANCE(bar) MODE(Standby)
QMNAME(QM2) STATUS(Running)
INSTANCE(foo) MODE(Active)
INSTANCE(bar) MODE(Standby)
tcp 0 0 :::1414 :::* LISTEN |
Code: |
[root@bar ~]# !netstat
netstat -an |grep 1414
tcp 0 0 :::1414 :::* LISTEN |
When the qmgr is shutdown the port is down..
PS.. QM2 has 1415 as listening port if there is any confusion. (not part of discussion). |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri Oct 02, 2015 11:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
are you sure that QM2 is not running 2 listeners one on 1414 and one on 1415?
what happens if both qmgrs are active on the same host. Does the standby host still show an active mq port?
Can you show the output on the standby qmgr of ps -ef |grep runmqlsr ?  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mgrx |
Posted: Fri Oct 02, 2015 11:25 am Post subject: |
|
|
 Novice
Joined: 01 Oct 2015 Posts: 20
|
Code: |
[root@foo ~]# dspmq -x
QMNAME(QM1) STATUS(Running)
INSTANCE(foo) MODE(Active)
INSTANCE(bar) MODE(Standby)
QMNAME(QM2) STATUS(Running)
INSTANCE(foo) MODE(Active)
INSTANCE(bar) MODE(Standby)
[root@foo ~]# ps -ef|grep runmqlsr
root 600 31209 0 21:17 pts/0 00:00:00 grep runmqlsr
mqm 21035 21000 0 Oct01 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m QM2 -t TCP -p 1415
mqm 32051 32024 0 18:37 ? 00:00:00 /opt/mqm/bin/runmqlsr -r -m QM1 -t TCP -p 1414 |
Code: |
[root@bar ~]# dspmq -x
QMNAME(QM1) STATUS(Running as standby)
INSTANCE(foo) MODE(Active)
INSTANCE(bar) MODE(Standby)
QMNAME(QM2) STATUS(Running as standby)
INSTANCE(foo) MODE(Active)
INSTANCE(bar) MODE(Standby)
[root@bar ~]# ps -ef|grep runmqlsr
mqm 25479 24465 0 Sep02 ? 00:00:10 /opt/mqm/bin/runmqlsr -r -m QM1 -t TCP -p 1414 |
Code: |
# dspmqinst | grep -i ver
Version: 8.0.0.2 |
Atleast it seems to be working as expected at QM2 installation, but they are very much the same configuration. (except names and ports).
The good news is that I now know that the listener is suppose to shut down when the qmgr enters standby mode.
Could it be that i ran into some kind of bug?  |
|
Back to top |
|
 |
fjb_saper |
Posted: Sat Oct 03, 2015 4:05 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
If the runmqlsr process on foo for QM1 was created from the OS
Code: |
runmqlsr -r -m QM1 -p 1414 & |
it will not go away when the queue manager shuts down because it was never under qmgr control.
In fact under windows 8.1 MQ8.0.0.3 it doesn't even show up when running display lsstatus(*) all.... (ran start "lsr" runmqlsr -r -m QM1 -p 1414 when the queue manager was down... and yes the process survived qmgr shutdown)
Try running
on foo
You can then move the qmgr to foo and back to bar and see if the listener stays active and the port open... You might have to use the -f force flag...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mgrx |
Posted: Sat Oct 03, 2015 11:24 am Post subject: |
|
|
 Novice
Joined: 01 Oct 2015 Posts: 20
|
fjb_saper wrote: |
If the runmqlsr process on foo for QM1 was created from the OS
Code: |
runmqlsr -r -m QM1 -p 1414 & |
it will not go away when the queue manager shuts down because it was never under qmgr control.
|
I get that, however the listener is configured in the qmgr with control(qmgr).
fjb_saper wrote: |
In fact under windows 8.1 MQ8.0.0.3 it doesn't even show up when running display lsstatus(*) all.... (ran start "lsr" runmqlsr -r -m QM1 -p 1414 when the queue manager was down... and yes the process survived qmgr shutdown)
|
fjb_saper wrote: |
Try running
on foo
You can then move the qmgr to foo and back to bar and see if the listener stays active and the port open... You might have to use the -f force flag...
Have fun  |
Yeah, gonna play around with this a bit more! Ill get back after some more testing, thanks!  |
|
Back to top |
|
 |
|