| Author |
Message
|
| mqjava |
 Posted: Wed Jul 21, 2010 6:48 am Post subject: moving brokers |
 |
|
Voyager
Joined: 25 May 2009
Posts: 80
Location: New Jersey
|
Hi All,
I have some doubts regrading moving the Broker from one server to another server.
Here is the situation:
Currently we have broker BRKR1 and QMGR BRKR1 and DB2 DB BRKR1 running on SERVERA in DATACENTERA, we are planning to move this broker BRKR1 to different datacenter DATACENTERB.
In DATACENTERB we got new server SERVERB, and we installed MB, MQ, DB2 and created the broker BRKR1 and QMGR BRKR1 and DB2 DB BRKR1 in SERVERB.
Note: SERVERB in DATACENTERB will have different hostname and IP from SERVERA in DATACENTERA.
Our goal is to move the BRKR1 in SERVERA to SERVERB, broker name will be same but server and datacenter will be different.
Here is my question:
To move the broker BRKR1 from SERVERA to SERVERB, first i need to remove the BRKR1 on SERVERA from config manager, then suspend the queue manager BRKR1 on SERVERA from cluster and remove the queue manager from cluster. Now BRKR1 on SERVERA is completly out of service and i can shut it down?
On SERVERB, first add the BRKR1 broker to config manager, but i think here i will have a problem, because already a broker named BRKR1 was associated with the config manager and it wont allow the SERVERB's broker BRKR1 to join the config manager, what steps i need to take to add the BRKR1 in SERVERB to config manager, and will i have any problems while adding the queue manager BRKR1 in SERVERB to cluster, the reason i am asking is on SERVERA and SERVERB the queue manager names are same, what i need to do to ensure clean removal of queue manager out of cluster and add the queue manager with same but different server to cluster?
Your help will be greatly appreciated.
Thanks in Advance. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Jul 21, 2010 6:59 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I don't think the ConfigMgr stores any IP information.
it just uses MQ to talk to Broker.
So as long as you keep the same qmgr name, you should be fine.
But you should follow the actual procedures to back up and restore a broker, rather than making guesses. |
|
| Back to top |
|
|
| mqjava |
| Posted: Wed Jul 21, 2010 9:40 am Post subject: |
|
|
Voyager
Joined: 25 May 2009
Posts: 80
Location: New Jersey
|
mqjeff,
I am not backing up and restoring the broker, i have already created the broker BRKR1 in SERVERB same as SERVERA.
When i remove the BRKR1 of SERVERA from config manager and add the BRKR1 of SERVERB to config manager, i think config manager wont allow me to add the new broker BRKR1 in SERVERB, because already a broker named BRKR1 was associated with config manager, it will ask to remove the previous reference. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 21, 2010 9:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mqjava wrote: |
| I am not backing up and restoring the broker, |
Why not?
| mqjava wrote: |
| When i remove the BRKR1 of SERVERA from config manager and add the BRKR1 of SERVERB to config manager, i think config manager wont allow me to add the new broker BRKR1 in SERVERB, because already a broker named BRKR1 was associated with config manager, it will ask to remove the previous reference. |
Yes. This is strictly because you are NOT backing up and restoring the Broker.
You said
| mqjava wrote: |
| Our goal is to move the BRKR1 in SERVERA to SERVERB, broker name will be same but server and datacenter will be different. |
This is *properly* achieved by BACKING UP AND RESTORING THE BROKER.
If you want to play games instead of following the correct procedure, then, yes, you will have issues that will make your life complicated. |
|
| Back to top |
|
|
| mqjava |
| Posted: Wed Jul 21, 2010 11:13 am Post subject: |
|
|
Voyager
Joined: 25 May 2009
Posts: 80
Location: New Jersey
|
ok, thanks alot, i will try to follow the broker backup procedure, can you please let me know the procedure to backup and restore the broker or any documentation would be fine.
And also i had one more question, when we move a qmgr QMGRA from SERVERA to SERVERB whats the procedure?
note: QMGRA is in cluster, and SERVERA and SERVERB will have different hostnames and IP. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 21, 2010 11:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you're moving the qmgr, and changing it's hostname and IP port, and more more importantly, changing it's QMID, the *best* procedure is to remove it from the cluster entirely before doing anything else.
This means unshare all queues, wait for changes to propagate, delete clussdrs, wait for changes to propagate and wait for clusrcvrs to quiesce, and then delete clusrcvrs. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 21, 2010 11:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| If you're moving the qmgr, and changing it's hostname and IP port, and more more importantly, changing it's QMID, the *best* procedure is to remove it from the cluster entirely before doing anything else. |
Especially with the QMID issue. The queue manager on the new server will have a different one and the cluster won't like that. In the "won't work" sense of won't like.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjava |
| Posted: Wed Jul 21, 2010 12:48 pm Post subject: |
|
|
Voyager
Joined: 25 May 2009
Posts: 80
Location: New Jersey
|
Thanks alot guys. But i have a quick question regarding the steps to remove the qm out of cluster:
| Quote: |
| This means unshare all queues, wait for changes to propagate, delete clussdrs, wait for changes to propagate and wait for clusrcvrs to quiesce, and then delete clusrcvrs. |
first remove the queues out of cluster, then immediately delete cluster senders or i have to remove the cluster name in the channel paremeter?
And also one more question, referring the Infocenter for removing QM out of cluster shows the below steps:
3. Suspend queue manager TORONTO
4. Check that queue manager TORONTO has been suspended
5. Remove the CLUSRCVR channel definition
6. Stop the CLUSRCVR channel at TORONTO
7. Delete the CLUSSDR channel definition
8. Issue the REFRESH CLUSTER
link for the above steps:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzah.doc/qc12130_.htm
may i know why IBM is dealing with CLUSRCVR channels first then CLUSSDR channels.
Thanks in advance. |
|
| Back to top |
|
|
| Amitha |
| Posted: Wed Jul 21, 2010 12:50 pm Post subject: |
|
|
Voyager
Joined: 20 Nov 2009
Posts: 80
Location: Newyork
|
| Quote: |
| Yes. This is strictly because you are NOT backing up and restoring the Broker. |
Hi mqjeff,
I am curious. Isn't it easy to just remove the old broker reference and add the new broker reference to the config manager, rather than backing up and and restoring it. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jul 21, 2010 1:30 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Amitha wrote: |
| Quote: |
| Yes. This is strictly because you are NOT backing up and restoring the Broker. |
Hi mqjeff,
I am curious. Isn't it easy to just remove the old broker reference and add the new broker reference to the config manager, rather than backing up and and restoring it. |
Uh, it depends.
I'd personally create a new broker with a *new* name - exactly why is it important to keep the same name, anyway?
Then I wouldn't bother with backup/restore. I'd just bring the new broker up, register it to the configmgr simultaneous to the old one, deploy, change which qmgr has the input queues shared in the cluster... And then properly delete the old broker and old qmgr.
But mqjava was quite sure they needed to keep the same broker name. Consequently, I'd much rather backup & restore the broker than go do anything that resembled mucking about in the configmgr repository. (and I count using the CMP API Exerciser as mucking about). |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jul 22, 2010 4:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjava wrote: |
| may i know why IBM is dealing with CLUSRCVR channels first then CLUSSDR channels. |
Because that's how they designed it to worK? 
Think about what the channels are used for and why it might be important for the FR to lose communication with a PR in a given sequence.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
