| Author |
Message
|
| Shafikz |
 Posted: Thu Oct 04, 2012 10:18 am Post subject: High Availability issue |
 |
|
Apprentice
Joined: 12 Apr 2012
Posts: 29
|
Hi Friends,
I am using Message Broker v8, MQ v7.0 and windows server 2003. currently, I am trying to implement high availability scenario. I am following this link as guideline.
http://www.ibm.com/developerworks/websphere/library/techarticles/1109_gabhane/1109_gabhane.html
after completing all the steps.
when I stop Active Queue Manager its corresponding broker instance are not stopped but on the secondary machine, stand by instance queue manager starts successfully and broker remains stopped.
can anyone please help  on this issue.
thanks in advance |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Oct 04, 2012 10:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The failover of the queue manager will only cause the failover of the broker if the broker is configured as an MQ service.
the failure of the Broker to access it's queue manager is not a sufficient failure to cause it to initiate a failover of the broker, to allow you the option of restarting the queue manager without needing to restart the broker. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 04, 2012 11:05 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
To achieve high availability, there are two directions one can take. One is Active-Passive, the way your article talks about.
The other is Active-Active where there is no requirement to start another instance since it is already started.
Active-Passive setups have a startup delay; active-active setups have no startup delay since both/all three/four/ten are always running anyway.
There are pros and cons to both scenarios. For use cases where the revenue is tied to up-time, I cannot see anyone opting for Active-Passive.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 04, 2012 11:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
To achieve high availability, there are two directions one can take. One is Active-Passive, the way your article talks about.
The other is Active-Active where there is no requirement to start another instance since it is already started.
Active-Passive setups have a startup delay; active-active setups have no startup delay since both/all three/four/ten are always running anyway.
There are pros and cons to both scenarios. For use cases where the revenue is tied to up-time, I cannot see anyone opting for Active-Passive. |
Broker and MQ can not be configured in an Active-Active scenario.
They can only be configured in an overlapping Active-Passive Scenario, where each Active Node hosts a unique Broker/Qmgr and these fail over to the other Active Node.
You can not configure the *same* queue manager to *actively* process work on *two* machines, likewise with Broker. So it's *not* active-active. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 04, 2012 11:11 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
To achieve high availability, there are two directions one can take. One is Active-Passive, the way your article talks about.
The other is Active-Active where there is no requirement to start another instance since it is already started.
Active-Passive setups have a startup delay; active-active setups have no startup delay since both/all three/four/ten are always running anyway.
There are pros and cons to both scenarios. For use cases where the revenue is tied to up-time, I cannot see anyone opting for Active-Passive. |
Broker and MQ can not be configured in an Active-Active scenario.
They can only be configured in an overlapping Active-Passive Scenario, where each Active Node hosts a unique Broker/Qmgr and these fail over to the other Active Node.
You can not configure the *same* queue manager to *actively* process work on *two* machines, likewise with Broker. So it's *not* active-active. |
Please explain this statement: Broker and MQ can not be configured in an Active-Active scenario.
BRK1 - MQ1 ;; BRK2 - MQ2
Why could I not use the above active-active setup?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 04, 2012 11:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
Please explain this statement: Broker and MQ can not be configured in an Active-Active scenario.
BRK1 - MQ1 ;; BRK2 - MQ2
Why could I not use the above active-active setup? |
As I said, that's not an Active-Active. That's an Overlapped Active-Passive.
You can't configure BRK1 to process work on both nodes simultaneously, so BRK1 is an Active-Passive configuration. Likewise, BRK2 is an Active-Passive configuration.
The services and applications you host in those brokers can indeed be Active-Active, since you can deploy the same flow to both brokers and load-balance work between them.
But neither the broker nor the queue manager are Active-Active. |
|
| Back to top |
|
|
| McueMart |
| Posted: Thu Oct 04, 2012 11:17 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| That's interesting that you make that differentiation because what you describe as the overlapped active-passive is what I have always heard termed active-active. Good food for thought though! |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 04, 2012 11:19 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| mqjeff wrote: |
| lancelotlinc wrote: |
Please explain this statement: Broker and MQ can not be configured in an Active-Active scenario.
BRK1 - MQ1 ;; BRK2 - MQ2
Why could I not use the above active-active setup? |
As I said, that's not an Active-Active. That's an Overlapped Active-Passive.
You can't configure BRK1 to process work on both nodes simultaneously, so BRK1 is an Active-Passive configuration. Likewise, BRK2 is an Active-Passive configuration.
The services and applications you host in those brokers can indeed be Active-Active, since you can deploy the same flow to both brokers and load-balance work between them.
But neither the broker nor the queue manager are Active-Active. |
Ok, : r f e : I think a good white paper on High Availability choices would be in order.
If BRK1 and BRK2 have an MQInput that listens to the same queue as clustered by the MQ1 and MQ2, would that be active-active?
I see your point, mqjeff, and I am asking for discussion purposes. I would like to better understand the point you are making and see validity in your opinion.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 04, 2012 11:24 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
My opinion has historically been shaped through the use of NETPRTY and CLWLPRTY at large banking clients.
http://www-01.ibm.com/support/docview.wss?uid=swg21234112
| Quote: |
Question
What is the difference between CLWLPRTY and NETPRTY?
You reviewed "The cluster workload management algorithm" in the WebSphere MQ V6.0 Queue Manager Clusters manual. The documentation states that CLWLPRTY is considered directly after NETPRTY in the workload algorithm and can be used to perform the same function in the majority of circumstances. However, the documentation does not show the differences between these attributes.
Answer
CLWLPRTY (introduced at MQ v6.0) has the extended capability over the existing NETPRTY (available in MQ V5.3), in that it can be set on a QREMOTE definition that forms a queue manager alias. CLWLPRTY can also be used at a queue level, rather than the queue manager level, hence providing extra flexibility.
The NETPRTY and CLWLPRTY effectively achieve the same thing, but allow a conceptual separation that may be useful in practice.
An analogy to clarify this issue:
Suppose you have a (comprehensive) railway network and a road network. Both can get you where you want to go. You prefer to use the railway because it is cheaper. So, you give the railway a NETPRTY of 7 and the roads a NETPRTY of 3.
Now, for some of your operation you send to town (queue manager) "Charlotte". But you have a standby in "Greensboro". So, you give Charlotte a CLWLPRTY of 8 and Greensboro a CLWLPRTY of 2.
Your system runs. Everything goes to Charlotte by rail. The rail system breaks down and everything now goes to Greensboro by road. The rail system is fixed, so everything goes back to using rail.
Implementing this in MQ terminology, you define four channels using both attributes NETPRTY and CLWLPRTY:
TO.CHARLOTTE_BY_RAIL................. 7 8
TO.GREENSBORO_BY_RAIL ............. 7 2
TO.CHARLOTTE_BY_ROAD .............. 3 8
TO.GREENSBORO_BY_ROAD ........... 3 2
The "rail" and "road" networks are simply different tcp/ip routings to the same destinations. This is the recommended implementation.
You could instead have chosen to implement this using just one of the attributes, NETPRTY:
TO.CHARLOTTE_BY_RAIL............... 9
TO.GREENSBORO_BY_RAIL ............8
TO.CHARLOTTE_BY_ROAD ............ 7
TO.GREENSBORO_BY_ROAD...........6
However, this alternative does not convey the conceptual separation of ideas that using the two attributes achieves, and it would also require renumbering in the event that a third network was added. Note that in the recommended implementation, consistent values of NETPRTY and CLWLPRTY are used across the channels involved. There are a great many other sets of values that could be used to achieve the same result. However, assigning the same priority numbers to each channel is useful in understanding what the numbers mean (for example,. NETPRTY=7 means the rail network).
For reference, here are the best descriptions of these two attributes:
CLWLPRTY channel attribute
-------------------------------------------
To apply a priority factor to a channel for the purposes of cluster workload distribution use the CLWLPRTY attribute. The value must be in the range zero through 9 where zero is the lowest priority and 9 is the highest. This parameter is valid only for channels with a channel type (CHLTYPE) of CLUSSDR or CLUSRCVR.
Use this attribute to ensure that WebSphere MQ selects some destination queue managers in preference to others with a lower priority. WebSphere MQ selects the destinations with the highest priority before selecting destinations with the lowest cluster destination sequence number (or the most recently used one). Where there are two possible destinations, you can use this attribute to allow one queue manager to act as a failover, if the other queue manager becomes unavailable. In this situation, messages go to the highest priority queue manager until it becomes unavailable, they then go to the next priority queue manager. WebSphere MQ obtains the priority of queue managers after checking channel status. This means that only accessible queue managers are available for selection, and it allows WebSphere MQ to prioritize, where multiple destinations are available.
NETPRTY channel attribute
-----------------------------------------
To apply a network priority to a channel for workload management purposes use the NETPRTY attribute. This attribute specifies the priority for the network connection. Use this attribute to make one network the primary network, and another network the backup network that can be used when there is a problem with the primary network. Clustering chooses the path with the highest priority if there are multiple paths available. The value must be in the range zero through 9; zero is the lowest priority. |
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 04, 2012 11:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| If BRK1 and BRK2 have an MQInput that listens to the same queue as clustered by the MQ1 and MQ2, would that be active-active? |
That's what I mean by "the services and applications you host in those brokers can be active-active".
| lancelotlinc wrote: |
| I see your point, mqjeff, and I am asking for discussion purposes. I would like to better understand the point you are making and see validity in your opinion. |
To some extent, I'm making a technical point, not a point of discussion. There are strict technical meanings to things Active-Active and those meanings should be kept in mind. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 04, 2012 11:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
| My opinion has historically been shaped through the use of NETPRTY and CLWLPRTY at large banking clients. |
again, that's pointing to MQ destinations (i.e. essentially to clustered queues) and not to specific individual queue managers.
It's valid to say that an MQ cluster represents an n-Active setup for the queues that are shared in the cluster.
It's invalid to say that any queue manager in that cluster is itself in an Active-Active or n-Active configuration. There's only ever *one* of the queue manager running at a given time. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Thu Oct 04, 2012 11:51 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
The other problem I have had in the past (which may not be the same with today's version of MQ) is that when I have configured Active-Passive, I get the same result as the OP: the failover rarely works as intended.
9 times out of 10, the passive configuration does not start cleanly if at all when the active configuration goes down.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Oct 04, 2012 11:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| lancelotlinc wrote: |
The other problem I have had in the past (which may not be the same with today's version of MQ) is that when I have configured Active-Passive, I get the same result as the OP: the failover rarely works as intended.
9 times out of 10, the passive configuration does not start cleanly if at all when the active configuration goes down. |
Right, well, that's somewhat an artifact of failing to test failover properly in server build-out.
EDIT: To be fair, it can also be a result of a crash that is not recoverable by a normal restart.
And, again, the 'work around' is to use overlapped active-passive, where the same services/applications/flows are running in a true active-active. You then rely on the active-passive failover to ensure you keep up with your performance goals, and the downside of one of the nodes not failing over properly is a reduction in processing capacity, not an outage (unless that reduction reaches the point where it actually represents a failure to meet performance requirements and thus an 'outage')... |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Oct 04, 2012 12:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| 9 times out of 10, the passive configuration does not start cleanly if at all when the active configuration goes down. |
Even with old versions of WMQ, active/passive works fine if it's built and tested properly. I'll accept that for a fair proportion of such set-ups, the first test fails due to an oversight somewhere but that's why we test.
I've not encountered a situation where a built out server in an active/passive failed to start except where someone had seen fit to alter the configuration without retesting, where an overlapping active/passive was not in use to mitigate the time taken to fail over and the additional costs of active/active were seen as "unjustifiable" by management.
This includes large banks and financial institutions with no money worries per se.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
