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 IndexGeneral IBM MQ SupportMixed Cluster and non-cluster setup benefits?

Post new topicReply to topic
Mixed Cluster and non-cluster setup benefits? View previous topic :: View next topic
Author Message
lamtbs
PostPosted: Fri Mar 27, 2020 9:22 pm Post subject: Mixed Cluster and non-cluster setup benefits? Reply with quote

Acolyte

Joined: 07 Nov 2005
Posts: 57
Location: Hong Kong

Hi all,

Customer is considering a mixed of clustered and non-cluster QMs for resilience, to protect from MQ cluster failure or cluster bug.

Say Hong Kong and Singapore are connected over MQ, HK have QM1 and QM2 in cluster; while a QM3 connected with sender-receiver channel. When SGP send a request, he will have to send some request over the cluster and some over the sender-receiver channel side.

Has anyone done similar technology "backup" before? (sender/receiver backing up cluster technology)?
Your pros and cons opinions and comments?

Thank you!
Back to top
View user's profile Send private message Send e-mail MSN Messenger
bruce2359
PostPosted: Sat Mar 28, 2020 4:54 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Other than posting here, what research have you done comparing and contrasting MQ clusters vs. non MQ clusters? What have you discovered?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Sat Mar 28, 2020 5:03 am Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

If you are truly and honestly worried about the cluster technology you won't use it at all. Since you are going to use it, you are choosing to trust it.

The decision to have QM3 in the cluster or out of the cluster should not be based on fear of clustering. If you can solve the business requirement of getting data to/from QM3 with regular SNDR/RCVR channels alone then go for it.

Sometimes overly complicated solutions tend to have more downtime over the life of the solution than a more simple topology, usually due to human error causing the downtime trying to work in that complex environment.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
bruce2359
PostPosted: Sat Mar 28, 2020 8:39 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

Your research should have lead you to something like this: the most significant benefit of MQ clusters is the ability to have multiple destination queues (with the same name) across multiple queue managers. This contributes to continuous operation, which leads to higher availability.

SDR/RCVR and CLUSSDR/CLUSRCVR channels operate similarly - and reliably: SDR/CLUSSDR channels (processes) extract a message from a transmission queue and press it onto the network. RCVR/CLUSRCVR channels remove a message from the network and deliver it to the destination queue (or dead-letter queue).

In my decades of MQ support, connectivity issues were NOT the fault of MQ internals - NIC cards, network cables, router/bridge/gateway issues, TCP issues, telecom provider issues, and so on.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
gbaddeley
PostPosted: Sun Mar 29, 2020 2:56 pm Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

Quote:
Customer is considering a mixed of clustered and non-cluster QMs for resilience, to protect from MQ cluster failure or cluster bug.

MQ clusters have the same exposure to failures or bugs as MQ distributed (sdr/rcvr/svr/rqstr) topologies. So there is no argument or reason for considering any other position.

We use MQ clusters where there is a design requirement to use its features. We don't use MQ clusters with external partners (over internet VPNs).
We use MQ distributed where simple point-to-point is all that's required.
_________________
Glenn
Back to top
View user's profile Send private message
lamtbs
PostPosted: Mon Mar 30, 2020 4:27 am Post subject: Reply with quote

Acolyte

Joined: 07 Nov 2005
Posts: 57
Location: Hong Kong

Thank you for all your comments, in fact, I am not even sure there is a "cluster failure" as such, as we are not like powerHA kind of clustering technology.

If I have to define a "cluster failure / bug" scenario, it would be like
- failure of 1 of the 2 FR QM?
- a repository screwed up?
- the cluster process "amqrrmfa" failure?
- cluster channel failing?

Any of these happening won't affect QM operations as QM caches the definition it needs, so they will all survive as least for some while. Only new definitions cannot be seen / refresh. So from an operation point of view, the cluster just won't "crash" and cause stoppage. Agree?

(Stoppage is what this customer is concerning about)
Back to top
View user's profile Send private message Send e-mail MSN Messenger
Vitor
PostPosted: Mon Mar 30, 2020 4:58 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

lamtbs wrote:
If I have to define a "cluster failure / bug" scenario, it would be like
- failure of 1 of the 2 FR QM?
- a repository screwed up?
- the cluster process "amqrrmfa" failure?
- cluster channel failing?

Any of these happening won't affect QM operations as QM caches the definition it needs, so they will all survive as least for some while. Only new definitions cannot be seen / refresh. So from an operation point of view, the cluster just won't "crash" and cause stoppage. Agree?

(Stoppage is what this customer is concerning about)


So let's just walk down these a bit.

If one of the FRs fails, you can still add definitions because one FR is still running; that's the point of having 2. The other will sync up when it comes back. If both fail then you're correct in your assertion that everything will keep running but adding new definitions will not be possible. A repository "screwed up" is the same as the FR being down; if the queue manager can't read the data, it will nose dive.

The cluster process failing presents the same risk surface as a point to point channel MCA process failing. In both instances there will be loss of functionality and in both cases the queue manager will attempt to recover the lost process. How is your client mitigating the risk of a channel process failing in a way the queue manager cannot recover it, and why can't they apply the same methodology to the cluster process?

The "cluster channel" is the same point to point MCA but defined automatically, so I repeat my previous comments.

The only scenario where this makes a lick of sense is if the non-clustered connection goes through a different network route (physically) so in the event of a network outage traffic can still flow. You could use this to link critical queue managers together but you wouldn't use both simultaneously because such backup networks tend to be too slow and/or too expensive for routine use.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Mon Mar 30, 2020 5:19 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
Location: US: west coast, almost. Otherwise, enroute.

lamtbs wrote:
(Stoppage is what this customer is concerning about)

With regard to “stoppages,” how does your company evaluate and select o/s software? DB software? Hardware platform? Telecom providers?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportMixed Cluster and non-cluster setup benefits?
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.