| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Mixed Cluster and non-cluster setup benefits? |
View previous topic :: View next topic |
| Author |
Message
|
| lamtbs |
 Posted: Fri Mar 27, 2020 9:22 pm Post subject: Mixed Cluster and non-cluster setup benefits? |
 |
|
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 |
|
 |
| bruce2359 |
| Posted: Sat Mar 28, 2020 4:54 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| PeterPotkay |
| Posted: Sat Mar 28, 2020 5:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
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 |
|
|
| bruce2359 |
| Posted: Sat Mar 28, 2020 8:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
| gbaddeley |
| Posted: Sun Mar 29, 2020 2:56 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
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 |
|
|
| lamtbs |
| Posted: Mon Mar 30, 2020 4:27 am Post subject: |
|
|
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 |
|
|
| Vitor |
| Posted: Mon Mar 30, 2020 4:58 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Mon Mar 30, 2020 5:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 |
|
|
|
|
|
|
|
Page 1 of 1 |
|
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
|
|
|
|
