Hi again, thanks for the comments
We have been making a significant effort to improve the concepts and
internals documentation for clustering, hopefully you will find some of
what you are looking for in the recent 'Best Practices' section on
clustering for example. However this will be an ongoing effort - please
do continue to point out areas with issues. One (probably the best)
option is to use the 'feedback' link you will find on every page in the
Infocenter for this purpose.
The first two specific points you make have definitely been identified as
needing improvement and a new version of the relevant pages(s) should be
available soon in a future refresh (hint: much of the content may look
similar to the devworks article).
On amqrfdm specifically - I appreciate that some knowledge of how to use
this is 'out in the wild', but it is and always has been an undocumented
tool intended for use only under the supervision of IBM support teams. As
such, usage, parameters, options, output formats etc. may change without
notice, (or it could disappear completely) and it really isn't ideal to be
making it an important part of your administration toolkit. If you
believe there are features of amqrfdm which are required as a user or
administrator of WMQ clusters, I'd strongly urge you to raise an RFE
detailing what information you need out of the product and why, so that it
can be properly externalised if appropriate (e.g. in MQSC).
Regards
Anthony Beardsmore
IBM UK - Software Engineer
WebSphere MQ
From: "LM Demey (MQ)" <***@DEMEY.NET>
To: ***@listserv.meduniwien.ac.at,
Date: 19/09/2013 21:51
Subject: Re: Moving MQ Cluster FR to new V7 qmgr
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
Hi Anthony,
I totally agree with this sentence:
This is another reason the behavior isn't explicitly defined/documented as
you are describing and shouldn't be relied on. We are aware that the
documentation in the Infocenter for this whole subject isn't the clearest,
and it will be being updated in the near future.
There is too little information available on MQ cluster internals, and
some basics concepts of clustering are undocumented (or not documented in
the right place, who is the same).
When some information leak via (un)official channels, it is often
contradictory:
- why only 2 FR ?
- from a PR, 1 or 2 explicit channels to FR and why ?
- how to use the undocumented program to dump the content of
system.cluster.repository.queue
- ...
For several versions, the MQ Infocenter part about MQ clusters is very
"light". Even the official IBM education material (Course code WM250 for
example) is far behind what is needed.
I also hope that this will improve significantly in the near future.
HTH, LMD.
Le 19/09/2013 12:11, Anthony Beardsmore2 a écrit :
Hi T.Rob / Luc-Michele
Thanks for the article plug :)
Some of the detail you are describing was left out of that post
deliberately as it can over complicate things and lead to designs which go
against best practice. The intended use of manually defined cluster
channels is to bootstrap the cluster, rather than to explicitly control
flow of definition publications or subscriptions between queue managers,
and experience shows that trying to be completely prescriptive about this
causes more problems than it solves (often way down the line when it comes
to trying to move a full repository as in Jacky's original question). For
this reason I would suggest that a single manual clussdr to the most
'local' FR available is usually best, and let auto-definition and workload
balancing sort out connections to other FRs as required.
It's also worth noting there are 'edge cases' dependant on the order of
channel definitions etc. where the 'it will always use the 2 manual ones'
won't work. This is another reason the behavior isn't explicitly
defined/documented as you are describing and shouldn't be relied on. We
are aware that the documentation in the Infocenter for this whole subject
isn't the clearest, and it will be being updated in the near future.
The second half of T.Rob's explanation is spot on. Here I was discussing
why relying on more than 2 for 'HA' isn't a good idea. In a controlled
removal, where the repository which is going has had time to tell the
cluster it is no longer to be used, both publications and subscriptions
will be moved over to one of the other FRs where available.
I'd respectfully disagree with the recommendation to always do the
REFRESH, but this may be a matter of taste :). If anyone still thinks the
old FR is to be treated as a full, this should be apparent fairly quickly
from a look at logs (for example you'd be seeing a lot of 'unexpected
publication received' messages at the old FR). In particular in
production environments with large clusters or on queue managers where you
have a lot of object definitions, 'unnecessary' cluster refreshes are
generally best avoided if only for the extra load on the repository tasks
which they generate.
Regards
Anthony Beardsmore
IBM UK - Software Engineer
WebSphere MQ
From: "T.Rob" <***@IOPTCONSULTING.COM>
To: ***@listserv.meduniwien.ac.at,
Date: 18/09/2013 20:56
Subject: Re: Moving MQ Cluster FR to new V7 qmgr
Sent by: MQSeries List <***@listserv.meduniwien.ac.at>
Hi Luc-Michele,
Ant's article is good but I didn't think it went far enough in describing
all the details. For example, he doesn't mention that the PR will *always
* send two updates and that these flow down the explicitly defined CLUSSDR
channels first. If you have two explicit CLUSSDR on a PR the updates will
always be, and only be, transmitted on those two. If you have more than
two explicit CLUSSDR it will be two but which two depends on the order in
which they were defined and how many were defined during the last REFRESH
CLUSTER REPOS(YES) command.
But if there is one and only one explicit CLUSSDR then it will get one of
the two updates and the FR that gets the other is decided by normal
workload balancing. Subscriptions are normally registered with the same
two FRs that get the publications. (Ant contradicts this and says that
normal workload balancing determines the distribution but unless IBM
changed this since Linda Barton & worked together, we can attest to the
fact that explicit CLUSSDR channels are *always* preferred which became
painfully obvious during the engagement.)
Still with me? Good.
Note that Ant asks "what happens now if we have three or four FRs and two
of them become unavailable? " The key here is the phrase "become
unavailable" which in this context means in an unplanned way. In the
scenario you describe, the FR is intentionally moved and that â hopefully
â means a planned change where it is suspended, demoted, etc. The
intention is that the PRs subscribing to that FR will see it become
unavailable and then re-resolve their two FRs on which they make
subscriptions and publish updates. But based on the previous discussion
above, we know that cannot happen if the PR retains an explicit CLUSSDR to
the former FR.
SoâŠ
· Add the new FR and make sure both old FRS are connected to it and
vice-versa.
· On the PRs, move any explicit CLUSSDR pointing to the deprecated
FR to the new FR. (Define new, remove old from cluster an delete.)
· Suspend, demote and remove the old FR.
· If you are paranoid (and I am) run REFRESH CLUSTER REPOS(YES) on
the PRs to force them to resolve the new FR pair.
That last step is supposedly not required but if I don't do it I'm not
sure the cluster is healthy without a lot of DIS CLUSQMGR and
DISQCLUSTER. However if I do execute that step I *am* sure the cluster is
healthy and know that immediately when the channels resolve to
auto-explicit..
Does that help?
-- T.Rob
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of LM Demey (MQ)
Sent: Wednesday, September 18, 2013 13:38 PM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Re: Moving MQ Cluster FR to new V7 qmgr
Hi all, I would like to comment on this with a very interesting article
from Anthony Beardsmore (WMQ Clusters: Why only two Full Repositories? -
https://www.ibm.com/developerworks/community/blogs/messaging/entry/wmq_clusters_why_only_two_full_repositories?lang=en
)
In this paper, there is an information about problems that can appens if
you have more than 2 FR :
When we request information about an object, the FRs which we contacted
remember that we asked for that information (this is sometimes referred to
as a âcluster subscriptionâ â not to be confused with publish/subscribe
application subscriptions.) These subscriptions mean that if the object
changes, is deleted, or another instance is defined somewhere (for
instance a secondary queue for workload balancing), the partial repository
gets notified. These subscriptions only exist on the FRs we originally
contacted with our request.
I have problem to understand the last point : "These subscriptions only
exist on the FRs we originally contacted with our request".
Does it mean that we will have trouble if a FR is moved to an other QM ?
The subscriptions will be lost ?
Comments appreciated.
Le 17/09/2013 14:20, Potkay, Peter M (CTO Architecture + Engineering) a
écrit :
Jacky,
Here is the link to the InfoCenter article on moving Full Repository
duties from one QM to another.
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.con.doc/q017470_.htm
In this article, they make the new QM a Full Repository before demoting
the previous Full Respository â in other words, the cluster runs briefly
with 3 Fulls. There is no mention of suspending and resuming any PRs.
Peter Potkay
From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf
Of Jacky Bright
Sent: Tuesday, September 17, 2013 6:19 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT
Subject: Moving MQ Cluster FR to new V7 qmgr
Hi,
We have a Cluster with 2 FR and 10 PRs. Application workload getting load
balanced acrosst those 10 PRs. Now We are planning to move these 2 FR's
to new V7 QMGRs.
Once the new V7 QMGR becomes FR and going to connect existing PR's to new
FR To do this without any outage for connected application planning to do
:
1) SUSPEND 5 PR QMGR's connected to Old repos 1 so that new workload will
be failover to other 5 qmgrs connected to Old repos 2.
2) Define new Cluster Sender Channel to new Repos
3) Amend Old Cluster Sender Channel with blank cluster name
4) Stop the Old Cluster Sender channel
5) Delete the Old Cluster Sender Channel
6) Resume the QMGR in Cluster.
Did anyone try this and face any issues ?
Regards,
JAcky
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
************************************************************
This communication, including attachments, is for the exclusive use of
addressee and may contain proprietary, confidential and/or privileged
information. If you are not the intended recipient, any use, copying,
disclosure, dissemination or distribution is strictly prohibited. If you
are not the intended recipient, please notify the sender immediately by
return e-mail, delete this communication and destroy all copies.
************************************************************
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
--
Luc-Michel Demey - Freelance WAS & WMQ Expert
http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Luc-Michel Demey - Freelance WAS & WMQ Expert
http://www.demey-consulting.fr/ - lmd at demey-consulting dot fr
List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU