| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| High Availability configuration - Instable network |
« View previous topic :: View next topic » |
| Author |
Message
|
| a.zhil |
 Posted: Fri Mar 31, 2017 4:04 am Post subject: High Availability configuration - Instable network |
 |
|
Newbie
Joined: 31 Mar 2017
Posts: 1
|
Hi,
My question concerns the highly available configuration of the MQ.
The customer has two data centers remote from each other and a requirement to provide a highly available, recoverable configuration.
Business scenarios are running on IBM Integration Bus 9 with MQ v8.
We decided to use multi-instance MQ queue manager with synchronization via GlasterFS (in terms of configuration requirements, the file system is similar to NFS4).
Since the network link between the data centers is unstable, we are faced with a following problem - if the network connection between active and passive instances is lost, the passive instance goes into the active mode. Before the connection is restored, two independent active instances continue to work.
If a certain number of messages have been accumulated for processing at the time of the loss of communication (this messages have already been synchronized between instances, but have not been processed and sent to the consumer (HTTP WS, etc) yet), this leads to a duplication of messages within the recipient.
The question is - do I understand correctly that any HA configuration with automatic launch of the active instance strongly depends on the reliability of the network between datacenters (at least, in terms of the consequences of independent work of active instances while the connection is broken)?
At the moment the only option I see (that doesn't involve the consumer) is a cold(turned off) standby passive instance with a manual launch by the operator when the failure of the active instance is confirmed.
Thanks in advance,
Aleksander. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Mar 31, 2017 4:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ideally, you would actually have two MI qmgrs... one in each DC.
MI depends on a file lock on the shared directory. If the communications between the two datacenters is broken - then what you have shown is that the file lock is dropped... (which is a bit odd)
If you are tr trying to create a DR scenario, then you shouldn't have the second DC in any kind of active mode.
If you're trying to create a load-balance scenario, then you do need two MI qmgrs, one in each DC. And separate network pipes into each DC.
THen you need to be able to process workload entirely within each DC separately - without relying on any service in another DC.
Or you could look at a cloud based solution for MQ - such that both DCs can talk to it the same cloud MQ.
Dependsd on what you are really trying to accomplish, and what kinds of data security you really need...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Mar 31, 2017 5:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Where and why is the network unreliable? Private network between DC's? Change network provider.
_________________
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: Fri Mar 31, 2017 1:43 pm Post subject: Re: High Availability configuration - Instable network |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| a.zhil wrote: |
The question is - do I understand correctly that any HA configuration with automatic launch of the active instance strongly depends on the reliability of the network between datacenters (at least, in terms of the consequences of independent work of active instances while the connection is broken)? |
Yes. And ideally not even over a single connection via the world's most stable network - multiple connections.
Look at the H.A. diagrams for the MQ Appliances. 2 redundant heartbeat cables connecting the pair of appliances, ideally dedicated physical cables with no routers or switches involved. This is above and beyond the 3rd connection that deals with replicating the data.
Have both sides of your H.A. solution think they are active (the dreaded split brain scenario) is to be avoided at all costs. Doing it over a flaky network is suicide. Look to do an Active / Active load balanced solution if that is the hand you are dealt, which is only H.A. for the next transaction post failure, but maybe good enough.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Apr 02, 2017 7:18 pm Post subject: Re: High Availability configuration - Instable network |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| a.zhil wrote: |
Hi,
My question concerns the highly available configuration of the MQ.
The customer has two data centers remote from each other and a requirement to provide a highly available, recoverable configuration.
Business scenarios are running on IBM Integration Bus 9 with MQ v8.
We decided to use multi-instance MQ queue manager with synchronization via GlasterFS (in terms of configuration requirements, the file system is similar to NFS4).
Since the network link between the data centers is unstable....
Thanks in advance,
Aleksander. |
What OS is being used?
If there are multiple resources that need to be HA, it should use an enterprise-strength HA solution that reliably works cross-datacentre. I'm not sure that MIQM fits into this category.
_________________
Glenn |
|
| Back to top |
|
|
| zpat |
| Posted: Sun Apr 02, 2017 11:08 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Multi-instance means that the active NFS mount point is used for the QM, this would be in one DC at a time, so that applications in the other DC would have to rely on the "unstable" network.
If your network really is unstable then you should provide an active QM in each DC to avoid reliance on this network.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| 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
|
|
|
|
