| Author |
Message
|
| sebastia |
 Posted: Wed Apr 24, 2013 7:12 am Post subject: replace FR's best practices |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Hi - we have to migrate from MQ v6 to MQ v7.
And we have a cluster with 2 FR's and 4 PR's.
As it is production, we have to do it on the flight.
We are reading "Task 10: Removing a queue manager from a cluster" ...
>>> publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=/com.ibm.mq.csqzah.doc/qc12130_.htm
... where "TORONTO" qmgr is removed from "INVENTORY" cluster
Guess the step list to update a cluster may be :
a) remove FR2 from cluster
b) add new FR2 into cluster
c) remove FR1 from cluster
d) add new FR1 into cluster
e) remove PR1 from cluster
f) add new PR1 into cluster
g) repeat (e) and (f) for the rest of PR's
Does anybody have any list of best practices about this procedure ?
By example, in the PR's we have a multi-instance queue,
(the same queue is defined in multiple QMgrs, so workload balancing occurs)
so I would like to know the best way to remove this shared object from the cluster before removing its queue manager from the cluster, just to make sure no message gets lost.
Maybe it is better to stop de cluster channel for this PR ?
Maybe it is better to PUT(disable) this queue ?
Or maybe "SUSPEND QMGR" is enough ?
What is the best mechanism to remove an object from the cluster ?
Thanks. Sebastian.
PD.- I want to share a nice "best practices" document I've found :
>>> http://www.mqug.org.uk/downloads/201006/WMQClusterBestPractices.pdf |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Apr 24, 2013 8:19 pm Post subject: Re: replace FR's best practices |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Thanks for sharing. You will have however to review the cluster manual as the procedure to remove an object or a qmgr from the cluster is described there in details. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Apr 25, 2013 6:25 am Post subject: Re: replace FR's best practices |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| sebastia wrote: |
By example, in the PR's we have a multi-instance queue,
(the same queue is defined in multiple QMgrs, so workload balancing occurs)
so I would like to know the best way to remove this shared object from the cluster before removing its queue manager from the cluster, just to make sure no message gets lost.
Maybe it is better to stop de cluster channel for this PR ?
Maybe it is better to PUT(disable) this queue ?
Or maybe "SUSPEND QMGR" is enough ?
What is the best mechanism to remove an object from the cluster ?
|
i would use SUSPEND QMGR, no more new messages would flow to the FR, applications can then empty their queues, when the applications are done and queues are empty, take down the qmgr, take backup, migrate, bring up and RESUME QMGR...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Apr 25, 2013 6:25 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, the "straight" procedure (the "theoretical") is there,
but not the "real" procedure, ( )
Maybe I am asking something strange,
but, on a given cluster, I would like to
a) see/view/display .. all "shared" objects, given the cluster name
b) know how many instances of the object do exist right now
c) know/display who is the owner of every instance
Then I would "remove" my object and monitor it is not "visible" anymore.
Then I would insert the new q manager and the new object, and again verify it comes up as available ...
One of my problems is that the qmgrs we are replacing have to keep the same IP, as they are accessed from lots of remote clients, using CCDT's
Thanks. Sebastian. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Apr 25, 2013 6:36 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| sebastia wrote: |
One of my problems is that the qmgrs we are replacing have to keep the same IP, as they are accessed from lots of remote clients, using CCDT's
|
ah!!! you are not migrating/upgrading existing qmgrs!
you are replacing them!
maybe even with same qmgr name. but QMID (includes CRDATE and CRTIME) will certainly be different...
on the local qmgr I would use DISPLAY Q(*) WHERE (CLUSTER NE ' ') to see which queues are shared in the cluster...
stop sharing them by setting CLUSTER(' '). make sure all queues are empty (as probably this qmgr will not come back ever...), remove qmgr from cluster, take down qmgr...
add new qmgr (with same name) to cluster, set CLUSTER on objects that need to be shared
it's obviously more work!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sebastia |
| Posted: Thu Apr 25, 2013 7:21 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, the right word is "replace".
I can change qmgr names, as there is no DNS involved, but have to keep IP's.
The qmgr ID's will be diferent, yes, I understand that.
And the queues shall be empty, even in production cluster that is quite dificult ...
Your sequence looks good to me, Michael.
Thanks a lot.
It's a pity those germans have such a powerful team !
They crunched us tuesday ... lots of years I don't remember such a difference between teams in semi-fnals ...
snif |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Apr 25, 2013 7:26 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| sebastia wrote: |
It's a pity those germans have such a powerful team !
They crunched us tuesday ... lots of years I don't remember such a difference between teams in semi-fnals ...
snif |
i feel your pain, could not belief the score when I got off the plane ... fortunatly the other team got a beating too last night 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sebastia |
| Posted: Wed May 08, 2013 6:31 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed May 08, 2013 6:39 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
you are talking about REPLACING QueueManagers with the SAME NAME but on NEW machines,
that is a different process then UPGRADING existing QueueManagers on EXISTING machines
QMID's will be different and so SUSPEND / RESUME will not work.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| sebastia |
| Posted: Wed May 08, 2013 6:43 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Absolutely agree.
We shall SUSPEND just to make things smooth to the cluter.
The, qmgr is removed, and never gonna use RESUME.
But we are still worried about some "on the flight" message. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Wed May 08, 2013 6:55 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| sebastia wrote: |
Absolutely agree.
We shall SUSPEND just to make things smooth to the cluter.
The, qmgr is removed, and never gonna use RESUME.
But we are still worried about some "on the flight" message. |
SUSPEND is meant for QueueManagers to come back!
if you are only upgrading hardware (but stay on the same platform, ie no windows to linux or solaris to aix migration) you could do a BACKUP / RESTORE of the QueueManager and all of it's data...
obviously try it first in a test environment 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
|
|
