| Author |
Message
|
| tsf |
 Posted: Fri Feb 09, 2018 5:47 pm Post subject: Configure MQ Cluster with MQIPT |
 |
|
Newbie
Joined: 09 Feb 2018
Posts: 6
|
I have read the following article about configuring MQIPT clustering support.
MQIPT1 and MQIPT2 are configured to use TCP 1415 as listener.
But I cannot find cluster sender/receiver channel in LONDON MQ server and NEWYORK MQ server to use TCP 1415 for connection. Is it normal?
(LONDON Server)
DEFINE CHANNEL(TO.LONDON) +
CHLTYPE(CLUSRCVR) TRPTYPE(TCP) +
CLUSTER(INVENTORY) +
CONNAME('10.10.6.7(1414)')
DEFINE CHANNEL(TO.NEWYORK) +
CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
CLUSTER(INVENTORY) +
CONNAME('10.9.20.5(1414)')
(NEWYORK Server)
DEFINE CHANNEL(TO.NEWYORK) +
CHLTYPE(CLUSRCVR) TRPTYPE(TCP) +
CLUSTER(INVENTORY) +
CONNAME('10.9.20.5(1414)')
DEFINE CHANNEL(TO.LONDON) +
CHLTYPE(CLUSSDR) TRPTYPE(TCP) +
CLUSTER(INVENTORY) +
CONNAME('10.10.6.7(1414)')
On the other hand, is it mandatory for cluster queue manager to enable SOCKS when integrate MQIPT with IBM MQ servers?
Thanks!
TSF |
|
| Back to top |
|
 |
| tsf |
| Posted: Fri Feb 09, 2018 5:50 pm Post subject: |
|
|
Newbie
Joined: 09 Feb 2018
Posts: 6
|
Supplement: https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ipt.doc/ipt4111_.htm
mqipt.conf on MQIPT1
------------------------
Name=LONDON to NEWYORK
ListenerPort=1415
Destination=10.9.20.5
DestinationPort=1414
SocksServer=true
[route]
Name=MQIPT1 to LONDON
ListenerPort=1414
Destination=10.7.20.2
DestinationPort=1414
mqipt.conf on MQIPT2
------------------------
[route]
Name=NEWYORK to LONDON
ListenerPort=1415
Destination=10.10.6.7
DestinationPort=1414
SocksServer=true
[route]
Name=MQIPT2 to NEWYORK
ListenerPort=1414
Destination=10.9.1.2
DestinationPort=1414 |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Feb 10, 2018 9:24 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You cannot have 2 routes with different destinations listening on the same port on the same MQIPT server. It will get confused and not know which route to use.
You need to determine a different listener port for each route.
I see that you have 2 MQIPT servers but are only using one on each route.
Otherwise you would need on each server 2 ports, one for the inbound route, one for the outbound route...
The way you call the routes is a little bit bizarre. Usually you have to first call your own IPT because it allows access to outside and resides in the DMZ.
So the logical path would be
QM1 <-> IPT1 <-> IPT2 <-> QM2
In the referenced info the set up was for using mqipt in a cluster and it makes sense there to have
QM1 -> IPT2 -> QM2 and
QM2 -> IPT1 -> QM1
As each an every QM would place it's nearest IPT into the cluster receiver conname channel. Locally your network might still need to route the call to the corresponding route on the local IPT server to the sender qmgr. (nating)...
So QM2 sends to IPT1 (1414) and the network (nating) would now need to transform this to IPT2(1415). The route on the IPT2 at 1415 points to IPT1(1414).
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tsf |
| Posted: Mon Feb 12, 2018 2:46 am Post subject: |
|
|
Newbie
Joined: 09 Feb 2018
Posts: 6
|
I understand that different route with different destination should use differetn listener port on the same MQIPT server.
Refer to the example from IBM website
https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.ipt.doc/ipt4111_.htm
The cluster network consists of 2 MQIPT between 2 cluster queue mangers as below:
LONDON (QM1) <-> MQIPT1 <-> MQIPT2 <-> NEW YORK (QM2)
I am not sure which IP address and listener port should be defined in the CONNAME parameter in cluster receiver channel and cluster sender channel.
Below is my deduction. Please comment.
1) Define the IP address and listener port of nearest MQIPT in the cluster receiver channel
- Cluster receiver channel on LONDON (QM1), define the IP address and listener port of MQIPT1 (i.e 10.10.6.7, TCP 1414)
- Cluster receiver channel on NEW YORK (QM2), define the IP address and listener port of MQIPT2 (i.e 10.9.20.5, TCP 1414)
2) Define the IP address and listener port of further MQIPT in the cluster sender channel
- Cluster sender channel on LONDON (QM1), define the IP address and listener port of MQIPT2 (i.e 10.9.20.5, TCP 1414)
- Cluster sender channel on NEW YORK (QM2), define the IP address and listener port of MQIPT12 (i.e 10.10.6.7, TCP 1414)
When MQ message is required to send from LONDON(QM1) to NEW YORK(QM2) through MQIPT1 and MQIPT2.
mqipt.conf on MQIPT1
------------------------
Name=LONDON to NEWYORK
ListenerPort=1415
Destination=10.9.20.5
DestinationPort=1414
SocksServer=true
[route]
Name=MQIPT1 to LONDON
ListenerPort=1414
Destination=10.7.20.2
DestinationPort=1414
mqipt.conf on MQIPT2
------------------------
[route]
Name=NEWYORK to LONDON
ListenerPort=1415
Destination=10.10.6.7
DestinationPort=1414
SocksServer=true
[route]
Name=MQIPT2 to NEWYORK
ListenerPort=1414
Destination=10.9.1.2
DestinationPort=1414
According to the above route definition in MQIPT1 and MQIPT2, the work flow of MQ message is below.
MQ Client (10.7.20.1) -> LONDON (10.7.20.2,TCP 1414) -> MQIPT1 (TCP 1414/1415?) -> MQIPT2 (TCP 1414/1415?) -> NEW YORK (102.9.1.2,TCP 1414)
How LONDON (QM1) route MQ message to NEW YORK (QM2) via TCP 1415? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 12, 2018 5:46 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Your example 1 is right.
The cluster receiver needs to have in it's conname the nearest MQIPT.
This way there is no delay when multiple qmgrs in London access that qmgr.
The problem comes with accessibility of that nearest MQIPT. The cluster concept requires each qmgr in the cluster to be accessible from each other qmgr in the cluster.
So what happens if the LONDON MQIPT is not accessible from the NEW YORK qmgr? This is where network and natting will have to come into play.
It is expected that the NEW YORK and LONDON MQIPTs can talk to each other.
So the route from the NEW YORK qmgr to the LONDON MQIPT will have to go through the NEW YORK MQIPT. At the same time the port will need to be translated so that the correct route on the MQIPT is chosen.
So what is set up as
LDNIPT(1414) on the NY qmgr is routed to NYIPT(1415).
Of course this would be easier to setup if all the MQIPTs would have been setup with the same port for a specific route.
Hope this helps.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tsf |
| Posted: Tue Feb 13, 2018 5:54 am Post subject: |
|
|
Newbie
Joined: 09 Feb 2018
Posts: 6
|
I really do not understand about how to setup NAT for NEW YORK (QM2). Please provide more details about NAT.
Do you mean that setup PAT as below?
Source: MQIPT2 (IP: 10.9.20.5, TCP Port 1415)
Destination: MQIPT1 (IP: 10.10.6.7, TCP Port 1414)
How LONDON (IP: 10.7.20.2) route MQ traffic to MQIPT1 (IP: 10.7.20.5)?
How NEW YORK (IP: 10.9.1.2) route MQ traffic to MQIPT2 (IP: 10.9.1.3)?
Is LONDON required to configure IP address of MQIPT1 (i.e. 10.7.20.5) as its default gateway)?
Is NEW YORK required to configure IP address of MQIPT2 (i.e. 10.9.1.3) as its default gateway)?
According to IBM URL, it mentions about the configuration of SOCKS client as below:
1) Point the client to MQIPT as the SOCKS proxy
2) Enable SOCKS V5 support
3) Disable use authentication
4) Only make remote connections to the MQIPT
How to configure SOCKS client to 1) point MQIPT as the SOCKS proxy and 4) only make remote connections to MQIPT?
When configuring MQIPT with MQ cluster, is it mandatory to enable SOCKS server on MQIPT?
Is it mandatory to configure MQIPT with two different IP addresses when integrate with MQ cluster? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 14, 2018 6:49 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Seems to me you're making more out of it as there is.
Simple information:
NY cluster receiver has NYIPT(1414)
LDN cluster receiver has LDNIPT(1414)
Now trying to send a message to NY means that there is a tcp / ip connection from LDNQMGR to NYIPT(1414).
If your network does not support that connection, you will need to get the network engineers involved.
Typically you would have an existing connection in LDNIPT(1415) to NYIPT(1414).
Now your network guys need to make following happen:
any calls to NYIPT(1414) from within the LDNQMGR subnet needs to be routed to LDNIPT(1415).
This would happen at the network layer and be completely transparent to the MQ Admin.
Hope this clarifies it a bit.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
