| Author |
Message
|
| MaxMax |
 Posted: Tue Apr 10, 2007 7:22 am Post subject: MQ sender channels via 2 independent network connections |
 |
|
Newbie
Joined: 10 Apr 2007
Posts: 6
|
My company (company A) has MQ connection to another company (company B). Connection can be established via 2 network connections. One connection is seen on B side as IP 1.1.1.1 another is seen on B side as IP 2.2.2.2. By default only one channel is active. So, CONNECTION NAME on B side sending channel is statically set to 1.1.1.1.
Company A always connects to B MQ IP 3.3.3.3.
When network connection goes down IP routing changes automatically. Company A can reach company B through another link. Company A can send messages via MQ to B. But B tries to send replies to the down 1.1.1.1 while currently active connection is 2.2.2.2.
I've proposed to B to make some kind of monitoring of a sender channels on their side and dynamically change CONNECTION NAME for the sender channel. This proposal was rejected.
How can we overcome this issue?
Can MQ clustering help to do it? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Apr 10, 2007 8:12 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
What you want here is mutiple channels participating at the same xmitq. Only one channel can run at a time.
When one channel is down (network prob) stop it and start the next channel using this same xmitq. This way no message has to wait and if in multihopping your next hop is down (main route) you can always start the alternate route...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| MaxMax |
| Posted: Tue Apr 10, 2007 11:58 pm Post subject: |
|
|
Newbie
Joined: 10 Apr 2007
Posts: 6
|
| fjb_saper wrote: |
What you want here is mutiple channels participating at the same xmitq. Only one channel can run at a time.
When one channel is down (network prob) stop it and start the next channel using this same xmitq. This way no message has to wait and if in multihopping your next hop is down (main route) you can always start the alternate route...
Enjoy |
This solution (channel switching in the terms of IBM) was also proposed to company B, i.e. 2 channels to one transmition queue. Only one channel is active.
But this solution was rejected. Because due to a company's B corporate policy dynamic changes are prohibited.
Any ideas?
Company B proposes to use clustering. But I have no idea how can clustering help us to resolve potential problems with network connection failures.
Sender channel on side A is always active because IP routing changes automatically in case of network failures. Problem is on the side of company B. Sender channel (company B MQ) points to inactive IP address and they don't want to do any dynamic modifications.
I have a stupid idea 
---only for company A---
Don't use dynamic routing for MQ.
Create 2 Qmanagers -
Qmanager1 for connection 1.1.1.1
Qmanager2 for connection 2.2.2.2
Notify company B about this changes.
Enforce company B to create 2 QManagers one points to Qmanager1 and IP 1.1.1.1 while another points to Qmanager2 and IP 2.2.2.2
By default Qmanager1 is active.
When network failure occures sender channel (company A) goes down.
Trigger executes some programm.
Program create something like a flag.
According to existance of this flag application that uses MQ adds to each message tag REPLYTOQMGR(QMANAGER2).
After that inject via SNMP IP route to the Cisco device
and voila  |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 11, 2007 3:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Configure DNS, with a name that resolves to both addresses.
DNS will round-robin the IP addresses that are given back. Each time the channel tries to resolve the name it will try a different address. So if one address is down, normal channel retry should cause the other address to be picked.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MaxMax |
| Posted: Wed Apr 11, 2007 3:47 am Post subject: |
|
|
Newbie
Joined: 10 Apr 2007
Posts: 6
|
| jefflowrey wrote: |
Configure DNS, with a name that resolves to both addresses.
DNS will round-robin the IP addresses that are given back. Each time the channel tries to resolve the name it will try a different address. So if one address is down, normal channel retry should cause the other address to be picked. |
Thank you for advice but this solution is unacceptable.
Reasons:
1. Company B must change connection name from IP address to hostname
2. Company B must configure mainframe for DNS.
3. Company B must configure DNS server.
I have no influence onto the company B.
4. Last but not least - MQ is used for business critical services. Round robin can give me 50/50 successful result for connection. It is VERY BAD. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 11, 2007 5:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, you've already rejected the more workable solutions.
You can't put an network load balancer in place, becuase you're using server channels, not client channels.
You can't convince the other side to do anything on an automatic or dynamic basis.
MQ clustering across network boundaries is a very bad idea, too. You would have to set up two queue managers for them to connect to, each of which was always listening on a fixed IP address.
Maybe you can look at using requester/sender pairs instead of sender/receiver pairs. Then all communications would be initiated at your end.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 11, 2007 1:30 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Clustering will work if you connect to multiple qmgrs in the cluster and there is at least one route open...
However be aware that in order to work you will need the cluster receiver to be accessible from all qmgrs in the cluster under the same cluster receiver info.
Usually this is done through DNS and name resolution especially with Natting and firewalls between.
On top of this you speak of mission/time critical apps. Be aware that if cluster resolution has to reroute your message because the direct route is not available it will cost you a considerable amout of time. If the message is a reply to message your request will most probably have timed out by the time you receive the rerouted message...
See Jeff's earlier post:
The best bet you have here is to switch from a push model to a pull model and use the requester channel with a server channel @ B. Make sure the Requester channel holds the right information for the connection in use when you start it.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 11, 2007 1:37 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
This is about the only situation where I'd recommend using more than one cluster - except I wouldn't recommend using clustering here at all.
Clustering across network boundaries is very difficult, as clusters always want to establish a fully connected network. So if some qmgrs in the cluster are *never* going to be visible across the network boundary - there's going to be a lot of errors on all qmgrs that can't see those qmgrs about the channels not starting. So to do clustering correctly across this kind of network boundary, I would set up a special cluster just for the boundary and overlap it with another cluster for my MQ network.
Then the special cluster is just a gateway cluster.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
