| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Brokers Collectives vs. Clones or both |
« View previous topic :: View next topic » |
| Author |
Message
|
| smeunier |
 Posted: Thu Jul 13, 2006 6:40 am Post subject: Brokers Collectives vs. Clones or both |
 |
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Howdy,
I'm trying to determine the right configuration I should implement and wether a collective is even needed.
Environment: 2 physical servers running WBIMB V6 in a HACMP environment with dual LPARS on each server. Each server will have an LPAR that is the fail over node for the other server. Essentially a X type failover configuration
Objective: Provide transparent failover to Publisher/Subscriber
Originally, I was thinking the configuration would be a single collective of 2 brokers with publications and subscriber potentially being on different systems. Therefor subscriptions would need to be cloned between brokers. However, as I read the documentation, it appears that cloned brokers in a collective will may produce duplicate messages to subscribers.
So my question is, if I want to have a fail safe Pub/Sub environment and not produce duplicate messages, would the configuration be to have two seperate brokers which are clones of each other and leave them out of a collective? Or perhaps the form a non cloned collective!?
In a fail over situation, it is anticipated that the client would reconnect/resubscribe to the alternate broker. This appears to be simple and straight forward, but in thinking about durable subscribers, it would seem that the brokers would need to be clones in order to retain and share the subscriber id needed for durable subscribers to reconnect.
Thoughts on direction??????? |
|
| Back to top |
|
 |
| markhiscock |
| Posted: Fri Jul 14, 2006 12:22 am Post subject: |
|
|
Novice
Joined: 16 May 2005
Posts: 22
Location: IBM Hursley, UK
|
Hi,
You're correct. Cloned brokers should be used to achieve a High Availability pub/sub broker environment.
If you are using the MQ transport then you you can also use MQ clustering so that publishers can put messages to a clustered input queue which either broker can get messages from and publish.
The issue with Cloned brokers is how you make your subscriber's queues highly available. In the subscription the subscriber will say where it's messages should go. Making this queue available to the subscriber can be the tricky bit. An HACMP style solution here is often the way to go.
FYI Collectives should be used for performance reasons as they employ proxy subscriptions to minimise the amount of pub/sub traffic being sent between brokers.
Hope this helps, please post again or get in touch if you have more questions.
Mark |
|
| Back to top |
|
|
| smeunier |
| Posted: Fri Jul 14, 2006 4:27 am Post subject: |
|
|
Partisan
Joined: 19 Aug 2002
Posts: 305
Location: Green Mountains of Vermont
|
Mark,
Thanks for your reply.
The dilemma I face, is that both are important(performance/availability). This will be for a 24x7 manufacturing environment, which typically tolerates zero down time. This is why we have gone with the dual servers with multiple LPARs in a HACMP configuration. We are shooting for that 99.999% availability. We have also added clustering to handle loadbalancing with 2 other MQ Servers on the backend.
It seems that the weak link here and what I have been finding throughout, is that the clients(subscribers), become the problem. HACMP and clustering will take care of the availability in my mind. With that in mind, collectives seems to be an added boast with performance.
No if I add durable subscribers to the picture, it seems that clones, is the only way to go. As the subscription is ID based. So the only way to allow a subscriber, to switch to a different broker, is to clone the subscriptions, where that subscription is is know on bith brokers. Is this a correct assumption?
As far as I know, there is no "magic" way to keep subscribers connected throughout a broker interruption, although the literature on cloning would have you you think so.
So I think with the confuguration I have, I have achieved high availabilty, without the cloning. Subscribers will need to reconnect. I see no way around that, regardless of the implementation.
The only thing I see cloning buying me at this time, is for durable subscribers. Would cloning solve this?
Appreciate the level setting on this. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 14, 2006 4:32 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Mark: Is the following a viable scenario. We are talking about durable subscriptions only here, and the brokers are in an MQcluster.
Make all your subscriptions for local publications only. Put the client's subscription into a publication flow. The publication goes to the collective.
On each broker there is a subscription for this publication that strips the pub RFH2 from the message and sends it to the SYSTEM.BROKER.CONTROL.QUEUE with the registration RFH2 only.
The only downside I see is that if there is a broker that is not up it might be missing a subscription registration and if a publication gets subsequently sent to this broker the subscriber might not get it as it specified local publications only?
Is my analysis correct or am I missing something. I thought of this as way to have a local subscription on every broker without having to actively subscribe on each broker. The problem with the availability of the queue to receive the subscription still remains...
Thanks for some enlightened help here.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 14, 2006 1:54 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You only want active subscriptions on queues you are going to actually read from in the near future.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| markhiscock |
| Posted: Mon Jul 17, 2006 12:50 am Post subject: |
|
|
Novice
Joined: 16 May 2005
Posts: 22
Location: IBM Hursley, UK
|
Hi All,
Apologies for the delay in replying.
fjb_saper, implementing your own version of cloning is a solution to the problem but as you and jeff point out, if a broker's down then you'll get backed up messages and also potentially missed publications.
One solution to this problem is that a client could be coded to make two subscriptions (one to the first broker and one to the second). The brokers are in a collective so when a publication happens the client will receive both. If a broker goes down, then it will receive only one. However, to be able to do this the client code needs to take care of duplicate publications which places more burden on the programmer.
This solution also keeps subscribers connected through a failure and blends performance (collectives) and HA (dual subscriptions). The only small performance degredation is that you're delivering two publications to each subscriber. This isn't so bad though as broker collectives are streamlining the network traffic for us.
We still have the problem of making the subscriber's queue highly available.
Mark |
|
| 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
|
|
|
|
