ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Configure MQ Cluster with MQIPT

Post new topic  Reply to topic
 Configure MQ Cluster with MQIPT « View previous topic :: View next topic » 
Author Message
tsf
PostPosted: Fri Feb 09, 2018 5:47 pm    Post subject: Configure MQ Cluster with MQIPT Reply with quote

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
View user's profile Send private message
tsf
PostPosted: Fri Feb 09, 2018 5:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sat Feb 10, 2018 9:24 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
tsf
PostPosted: Mon Feb 12, 2018 2:46 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Mon Feb 12, 2018 5:46 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
tsf
PostPosted: Tue Feb 13, 2018 5:54 am    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Wed Feb 14, 2018 6:49 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Installation/Configuration Support » Configure MQ Cluster with MQIPT
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.