| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| HA queue manager behaviour |
« View previous topic :: View next topic » |
| Author |
Message
|
| fjb_saper |
 Posted: Thu Jun 27, 2019 5:03 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I'd say open an RFE requesting that the appliance recognizes the split qmgr on its own and attempts to fix it on the standby side on its own....
Typically this should not happen... One way to avoid it from happening is when you shut down bot appliances to make sure you observe a certain order on shutdown and the opposite order on restart.
If you perform one sided shutdown (for maintenance) remember to wait long enough after restart of the idle appliance before switching for the idle appliance to catch up to the data it missed during shutdown... You may want to add to the RFE a request to not switch to the preferred side while the side is not up to date with its logs.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| emiranda |
| Posted: Fri Jun 28, 2019 4:47 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| emiranda wrote: |
... And excuse me if I sound too astonished, but IBM's answer in the PMR was that "Essentially, the current behaviour is suitable for Customers who prioritise service availability over individual messages."
Does it sound outrageously nutty or it is just in my head???  |
Looks like IT IS only in my head... 
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 28, 2019 3:37 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You have a properly configured pair of appliances with persistent, committed, non expiring messages sitting a queue and you can demonstrate MQ sometimes duplicated and other times deleted them? And the PMR's response was essentially "working as designed"?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| emiranda |
| Posted: Fri Jun 28, 2019 10:54 pm Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| PeterPotkay wrote: |
| You have a properly configured pair of appliances with persistent, committed, non expiring messages sitting a queue and you can demonstrate MQ sometimes duplicated and other times deleted them? And the PMR's response was essentially "working as designed"? |
Yeap!
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jun 29, 2019 7:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Meaning if you have two appliances in an HA pair, you have to be very careful and not set a preference for the side it runs on. You need to be very careful to start them in reverse shutdown order or you will submit yourself to the log inconsistency and always check after start up that this situation did not occur....
You will also need to verify before any qmgr move from one side to the other of the HA system whether the logs are up to date on both sides... otherwise you're in for problems...
Essentially what IBM is telling us is that there are no built in safety measures to avoid starting in a split log functionality.
Set up an RFE asking IBM to force an override by the user, if the current situation may cause a split log situation...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| emiranda |
| Posted: Mon Jul 01, 2019 3:32 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| fjb_saper wrote: |
| Meaning if you have two appliances in an HA pair, you have to be very careful and not set a preference for the side it runs on. You need to be very careful to start them in reverse shutdown order or you will submit yourself to the log inconsistency and always check after start up that this situation did not occur.... |
Yes, and that's what IBM's suggesting us to do, to get really smart around monitoring, checking and reacting to a situation they didn't foresee! Is that the solution? REALLY?!? The queue manager can be hostage of log inconsistency because the IBM MQ Appliance HA solution is careless about a partitioned status! That's what it is!
| fjb_saper wrote: |
You will also need to verify before any qmgr move from one side to the other of the HA system whether the logs are up to date on both sides... otherwise you're in for problems...
Essentially what IBM is telling us is that there are no built in safety measures to avoid starting in a split log functionality. |
Most likely... so either they should let you know clearly in the documentation (let alone sales talk!) that the HA solution MUST be carefully monitored and enhanced if you care about the integrity of your messages, otherwise your queue manager might fail to do what a queue manager is (or was?) made for: guaranteed delivery of persistent messages once and once only! Otherwise, back to the drawing board! 
| fjb_saper wrote: |
| Set up an RFE asking IBM to force an override by the user, if the current situation may cause a split log situation... |
Despite the fact that there's no commitment to RFEs, I don't think this is a enhancement, but a defect, and should be addressed by a fix/APAR. After all, it's MQ's reputation that we're talking about, isn't it?
I'd love to hear from other MQ Appliance users what they think of the current HA solution? Are they running real persistent messaging in production environment, or using them for developers/administrators playground? Did they buy the appliances thinking they were buying a "better" MQ solution? Or did they buy something else, which doesn't need to adhere to the principles of MQ? Because MAYBE, just MAYBE, we all together could thicken the plot of integrity over availability, and ask for a fix, before I go down the uncertain road of RFEs.
P.S.: I googled "Kafka free trial"; luckily a link to a free copy of Franz Kafka's book "The Trial" came first! 
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jul 01, 2019 5:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| emiranda wrote: |
| ...a queue manager is (or was?) made for: guaranteed delivery of persistent messages once and once only!... |
To be somewhat pedantic, IBM uses the term assured delivery. The use of the word guarantee would, I suspect, fall foul of their legal department  .
_________________
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 |
|
|
| Vitor |
| Posted: Mon Jul 01, 2019 5:30 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| emiranda wrote: |
| Most likely... so either they should let you know clearly in the documentation (let alone sales talk!) that the HA solution MUST be carefully monitored and enhanced if you care about the integrity of your messages, otherwise your queue manager might fail to do what a queue manager is (or was?) made for: guaranteed delivery of persistent messages once and once only! Otherwise, back to the drawing board! |
I'd agree the documentation could use some improvement.
I think that comment could be made for any piece of IBM documentation on any product.
I think a lot of this is coming from where the Appliance is positioned within the MQ pantheon. It's intended for MQ customers who want get a fast, easy MQ set up either because they're first time MQ customers with no existing infrastructure or because they want to scale an existing topology in a plug and play method.
The second use case is losing steam as MQ becomes more available in cloud topologies, which are more elastic in their scaling. We evaluated (but did not end up using the Appliance, so I'm not in the demographic you call out to) exactly because it didn't fit our DR strategy, which is built around Linux. We also didn't like the idea of persistent messages being assured (not guaranteed as my worthy associate correctly distinguishes) by a black box and if we'd used it, we'd have used it for non-persistent messages in the same use case we've now slotted Kafka into.
We've also found Kafka gives us more speed and reliability. If you head scratch your way through the configuration. A streaming platform with deliver it or not methodology & message persistence? Topology diagram by M.C. Escher.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| emiranda |
| Posted: Mon Jul 01, 2019 6:14 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| exerk wrote: |
| emiranda wrote: |
| ...a queue manager is (or was?) made for: guaranteed delivery of persistent messages once and once only!... |
To be somewhat pedantic, IBM uses the term assured delivery. The use of the word guarantee would, I suspect, fall foul of their legal department . |
I accept that!
| Vitor wrote: |
| I'd agree the documentation could use some improvement. |
Definitely... And what to say about the MQ Appliance itself?
| Vitor wrote: |
| I think a lot of this is coming from where the Appliance is positioned within the MQ pantheon. It's intended for MQ customers who want get a fast, easy MQ set up either because they're first time MQ customers with no existing infrastructure or because they want to scale an existing topology in a plug and play method. |
Or yet those deciding to make the appliance the "strategic platform for MQ" (not me, excuse me!), mainly because it promised a built-in HA solution ( ) and because it is supported by just one vendor (which might be really bad, as we're experiencing now, trying to get IBM to properly address the issue).
| Vitor wrote: |
| We evaluated (but did not end up using the Appliance, so I'm not in the demographic you call out to) exactly because it didn't fit our DR strategy, which is built around Linux. We also didn't like the idea of persistent messages being assured (not guaranteed as my worthy associate correctly distinguishes) by a black box and if we'd used it, we'd have used it for non-persistent messages in the same use case we've now slotted Kafka into. |
So I wonder how many organisations are using the appliance? IBM never gave us a clear answer due to "confidentiality", but it might be just the case nobody is really using them when you need reliability!
| Vitor wrote: |
| A streaming platform with deliver it or not methodology & message persistence? Topology diagram by M.C. Escher. |
I loved that! 
The truth is out there... If there's any other MQ Appliance users, they might make contact...
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
| emiranda |
| Posted: Fri Jul 05, 2019 6:42 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
| emiranda wrote: |
| Because MAYBE, just MAYBE, we all together could thicken the plot of integrity over availability, and ask for a fix, before I go down the uncertain road of RFEs. |
Yeah... clearly it didn't work.  which was a bit disappointing  
Well, we have to find a way to get around with it... so, in the meantime, if you can, please vote it here:
http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=134384
_________________
Warm Regards,
EM
Last edited by emiranda on Tue Jul 30, 2019 5:38 am; edited 1 time in total |
|
| Back to top |
|
|
| emiranda |
| Posted: Tue Jul 16, 2019 2:42 am Post subject: |
|
|
Disciple
Joined: 21 Nov 2002
Posts: 196
Location: Dublin, Ireland
|
For the sake of other MQ Applliance users, the discussion continues here.
_________________
Warm Regards,
EM |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
