ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » replace FR's best practices

Post new topic  Reply to topic
 replace FR's best practices « View previous topic :: View next topic » 
Author Message
sebastia
PostPosted: Wed Apr 24, 2013 7:12 am    Post subject: replace FR's best practices Reply with quote

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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Wed Apr 24, 2013 8:19 pm    Post subject: Re: replace FR's best practices Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

sebastia wrote:

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


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
View user's profile Send private message Send e-mail
Michael Dag
PostPosted: Thu Apr 25, 2013 6:25 am    Post subject: Re: replace FR's best practices Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
sebastia
PostPosted: Thu Apr 25, 2013 6:25 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Michael Dag
PostPosted: Thu Apr 25, 2013 6:36 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
sebastia
PostPosted: Thu Apr 25, 2013 7:21 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Michael Dag
PostPosted: Thu Apr 25, 2013 7:26 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
sebastia
PostPosted: Wed May 08, 2013 6:31 am    Post subject: Reply with quote

Grand Master

Joined: 07 Oct 2004
Posts: 1003

Hi, Michael - I am looking for "best practices" as in

>>> http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0m0/index.jsp?topic=%2Fcom.ibm.mq.csqzaj.doc%2Fsc12680_.htm

.. where it says

Quote:
It is strongly recommended that all cluster sender channels for the cluster are stopped before the REFRESH CLUSTER command is issued


But I guess we have to pray that "SUSPEND" and "RESUME" works fine and we don NOT have to use "big guns" as RESET and REFRESH ...

Best luck.
Back to top
View user's profile Send private message Visit poster's website
Michael Dag
PostPosted: Wed May 08, 2013 6:39 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
Location: The Netherlands (Amsterdam)

sebastia wrote:
Hi, Michael - I am looking for "best practices" as in

>>> http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0m0/index.jsp?topic=%2Fcom.ibm.mq.csqzaj.doc%2Fsc12680_.htm

.. where it says

Quote:
It is strongly recommended that all cluster sender channels for the cluster are stopped before the REFRESH CLUSTER command is issued


But I guess we have to pray that "SUSPEND" and "RESUME" works fine and we don NOT have to use "big guns" as RESET and REFRESH ...

Best luck.

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
View user's profile Send private message Visit poster's website MSN Messenger
sebastia
PostPosted: Wed May 08, 2013 6:43 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Michael Dag
PostPosted: Wed May 08, 2013 6:55 am    Post subject: Reply with quote

Jedi Knight

Joined: 13 Jun 2002
Posts: 2602
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
View user's profile Send private message Visit poster's website MSN Messenger
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » replace FR's best practices
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.