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 » General IBM MQ Support » QM failover - same QM name different IP SDR/RCVR channels

Post new topic  Reply to topic
 QM failover - same QM name different IP SDR/RCVR channels « View previous topic :: View next topic » 
Author Message
tumpsme44
PostPosted: Thu Sep 14, 2017 10:18 pm    Post subject: QM failover - same QM name different IP SDR/RCVR channels Reply with quote

Novice

Joined: 02 Feb 2017
Posts: 15

1)I created 2 identical QM (TEST_RCVR) on 2 linux boxes having different IPs hosting a local queue and a RCVR channel
This was NOT a MQ Multi-instance setup and NO shared filesystem between them

2) I created another QM (TEST_SDR) on a 3rd linux box and connected to the QM created earlier via a SDR channel with a connection list specifying the IPs of the 2 boxes ('IP1(port), IP2(port)')

I created a remote queue pointing to the local queue on step 1

3) Initially the SDR connected to IP1 as expected on QM (TEST_RCVR)
I sent a few messages to the QR which was received on the QM (TEST_RCVR) on Box1

4) I stopped box1 QM (TEST_RCVR)

and sent few more messages to the QR. The channel connected to the box 2 QM (TEST_RCVR) and messages were received.

The test were performed a few more times, with box1 stopped and sometimes with box 2 stopped.

Query- I thought the channel sequence number will play up in doing the above test and a reset channel will need to be issued to come out of the error. But I didnt see that happening..any reason why?

This is v8 MQ I am using.
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Sep 15, 2017 2:39 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

The reason this does not cause a problem is that channels use XmitQ, Channel Name AND Target Machine Address as the key for synchronisation information. The channels are quite capable, therefore, of maintaining a different sequence number between lots of different partners. You can see this if you issue a DIS CHS(*) SAVED command.

If you don't see any records then you probably made the common mistake of sending non-persistent messages rather than persistent ones. This is another reason why you don't have sequence number problems.

However, despite not having problems in this simple scenario it is probably only a matter of time before you do. The problem is the shared transmission queue. When a channel goes INDOUBT transmission queue must speak to the same Queue Manager next. This is because it is not really the channel that is indoubt - it is the queue that is indoubt. You can not start another channel until the INDOUBT is RESOLVED. Since the channel can not do it automatically you would have to do this manually (or rig up some event handler that always issued a BACKOUT or whatever).

If you really have two possible locations you COULD send a message but would prefer one location over another why not use MQ Clustering? Or, if you are just after an HA solution why not use MQ Multi-instance? It seems you are trying to use MQ in a way that you know, in your heart, you are not supposed to do.

Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
tumpsme44
PostPosted: Fri Sep 15, 2017 3:04 am    Post subject: Reply with quote

Novice

Joined: 02 Feb 2017
Posts: 15

Thanks Paul for the valuable explanation.

We are not going for clustering as our QMs are behind FWs (exposing NATTED IPs) fronted by MQ IPTs. They need to get feeds from several 3rd party several Gov Hosted QMs and respond back, which may or maynot choose to join our cluster.

We are planning to do MQ MI per site (there are 2 site) and have a F5 Load balancer in front which will expose 2 External facing IPs to which the downstream MQ SDR channel will connect. The 2 sites will operate in Active/standby config.

The 2 sites are 1000s of miles apart and shared disk for MQ MI/ HA wont be possible.

Is there any other way to do this apart from resetting the sequence number on the SDR/RCVR site..or any other recommendation for the design to achieve this topology?

Thanks in advance
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Sep 15, 2017 3:15 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

You wouldn't want, or set up, external queue managers to be part of your cluster.

Ever.

At all.

You can use MQIPT to bridge from those external queue managers, whether those are clustered or not, into your queue managers - as you already do - whether your internal queue managers are clustered or not.

If you are using back level MQ software, you should explain that software increases in risk as it gets older. The older the software, the more likely you are to experience errors that are already fixed, or security problems (like not supporting TLS1.2) that prevent you from establishing actually secure connections.

These are at least three separate issues - whether or not to cluster your queue managers, whether or not to let ezternal queue managers join your cluster (NEVER DO THIS!!!!!) and how can you convince management to keep MQ up to date, at least no more than 1 full release behind, and ideally no more than one FP behind.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
tumpsme44
PostPosted: Fri Sep 15, 2017 3:19 am    Post subject: Reply with quote

Novice

Joined: 02 Feb 2017
Posts: 15

MQJeff- Undertood and hence not going for a cluster.

But what could be an alternative is the question to achieve Active/standby which are separated 1000s of miles apart and shared disk is out of question...and with SDR/RCVR channels in play
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri Sep 15, 2017 3:29 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

tumpsme44 wrote:
MQJeff- Undertood and hence not going for a cluster.


To be very clear - the only thing I said about using clusters was that you should *Not* extend an internal cluster to a business partner cluster.

tumpsme44 wrote:
But what could be an alternative is the question to achieve Active/standby which are separated 1000s of miles apart and shared disk is out of question...and with SDR/RCVR channels in play


The choice of channel has nothing to do with the choice of HA method.

MQIPT will provide the endpoint that the other queue manager talks to.

If you can't use the same disk (shared or not) at both sides of that 1000s of miles apart, then you can't make any single queue manager HA.

MQIPT can, as far as I remember, change which queue manager is being talked to. When you move a SDR channel to point to another queue manager, you will have to reset the channel to be in sync. I think if you reset the receiver side, that will also reset the sender side.

As far as I remember.

However, it is pretty early here and I may be missing something obvious.
_________________
chmod -R ugo-wx /


Last edited by mqjeff on Fri Sep 15, 2017 3:33 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Sep 15, 2017 3:29 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

Well, if you can't use clustering and you can't use MI then I can't immediately think of a better proposal than having two channels reading the same transmission queue.

I am not sure I understand the need for the complexity of an F5 though - why not just use a comma separated list of IP address in the connection name ? I assume that these Sender channels are not going to be coming up and down frequently.

As far as 'problems' for the channel. It might come down to what is the content of the messages. Are they idempotent? By that I mean would duplicates cause harm ? If not then having an event handle (or whatever that issues a RESOLVE CHANNEL BACKOUT) each time the channel starts might not be too hard. As I said before I don't think sequence numbers are you problem, it is indoubt messages.

However, if you need once and exactly once delivery then you have a more difficult problem which I can't think of an easy solution for. The only solution I can think of is to have two transmission queues and use an event handle (or whatever) to change your Queue Manager alias to point to the 'current' best target - and re-jig remaining message. (This is essentially what MQ Clusters does for you). However, it is pretty late here and I may be missing something obvious.

Regards,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
exerk
PostPosted: Fri Sep 15, 2017 4:51 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

mqjeff wrote:
...I think if you reset the receiver side, that will also reset the sender side.

As far as I remember...

Other way around Jeff. In theory you can parse the receiving queue manager logs and identify the out-of-sequence number and reset the RCVR to that stated, but in practice I've never found it to work if the SDR is knocking on the door.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
tumpsme44
PostPosted: Fri Sep 15, 2017 5:44 am    Post subject: Reply with quote

Novice

Joined: 02 Feb 2017
Posts: 15

hmm
Back to top
View user's profile Send private message
PaulClarke
PostPosted: Fri Sep 15, 2017 9:44 am    Post subject: Reply with quote

Grand Master

Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand

Is it possible that we are dismissing MQ Clusters too early. If you had an MQ Cluster for each of these remote locations - so that only your IPT machines (DMZ) and the remote partner is in the cluster and they only had authority to put to particular queues would that not be sufficient? I know that MQ Clusters used to be a little all-or-nothing as far as security was concerned but I thought that they had been tightened up with generic profiles and the like. That, coupled with IPT/DMZ and using multiple clusters feels as though one ought to get a reasonably secure and workable system.

I haven't actually worked with clusters for some considerable time so we need a security expert to chime in here (T.Rob?) and say whether it is doable?

Cheers,

Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com
Back to top
View user's profile Send private message Visit poster's website
mqjeff
PostPosted: Mon Sep 18, 2017 2:52 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

It's reasonable to cluster external customers with gateway queue managers. It's a terrible idea to cluster external queue managers with internal queue managers.

I'm not sure if MQIPT can be a cluster endpoint by itself.

But it would still provide a reasonable security layer between external customers and a set of gateway queue managers in a cluster.

You should use sdr/rcvr channels between this gateway cluster and your internal cluster, just on general shirt, vest, jacket and overcoat principles. (belt and suspenders hold things up. This protects things in layers)

You might also want to use MQIPT between the gateway qmgr and the internal cluster - but that might be adding a slicker when it's not raining.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » QM failover - same QM name different IP SDR/RCVR channels
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.