| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Migrating MQ 5.3 Cluster on HP to MQ 6.x on AIX |
« View previous topic :: View next topic » |
| Author |
Message
|
| mdncan |
 Posted: Wed Mar 28, 2007 6:12 am Post subject: Migrating MQ 5.3 Cluster on HP to MQ 6.x on AIX |
 |
|
Acolyte
Joined: 11 May 2005
Posts: 59
Location: US
|
Customer I am working with is planning to Migrate WebSphere MQ Queue Manager Cluster from HP to AIX. The current MQ version is 5.3 on HP UX and the idea is to Migrate clustered queue managers to AIX MQSeries V6.x.
Is anyone in this forum participated in WebSphere MQSeries 5.3 migration from HP UX to WebSphere MQSeries 6.x on AIX? What type of Migration strategies to be followed in this type Migration situation.
Any suggestions/recommendations are really appreciable.
Regards,
-M |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Mar 28, 2007 6:18 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Well, if you're moving OSes and moving hardware, then you aren't exactly "migrating" the queue managers. You're replacing them with newer ones.
Since the new qmgr will have a different QMID, you should remove each qmgr you wish to migrate from the cluster entirely - first unshare queues, then take the qmgr out of the cluster, then stop and delete cluster channels.
Then add the new qmgr to the cluster.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mdncan |
| Posted: Wed Mar 28, 2007 6:40 am Post subject: |
|
|
Acolyte
Joined: 11 May 2005
Posts: 59
Location: US
|
Jeff,
Thanks for your reply.
Couple things here: 1) Should we Migrate Full Repository QM’s first and then the partial repos QM’s?
2) Customer also has Persistence messages, any special consideration on this?
Are there any redbooks or guided information on this type of Migration scenarios?
Thanks,
-M |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 28, 2007 7:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In my opinion, it's safer to migrate FRs first, as you ensure that the repository data structures are capable of handling any new fields or etc.
Various people who know better than I do have said this isn't strictly necessary.
There's probably a section on migrating clusters in one of the migration guides or redbooks, or in the clusters manual.
If you have persistent messages sitting on a queue, you will have to do something to move them from the old qmgr to the new qmgr - this would be true even if you weren't changing versions.
I suppose another option is to backup the v5.3 qmgrs, install v5.3 on AIX, restore the qmgrs there, and then upgrade to v6 on AIX. That would keep the QMID, keep the messages, and give you some options for "backout", in that you could always just turn on the old qmgr again.
If you've got a lot of messages sitting around, that's probably a better option than the first one I gave. But it leaves you more vulnerable to putting up two queue managers with the same name on the same network in the same cluster at the same time... which is not pretty by a long shot.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mdncan |
| Posted: Wed Mar 28, 2007 7:27 am Post subject: |
|
|
Acolyte
Joined: 11 May 2005
Posts: 59
Location: US
|
Jeff, Thanks for the suggestions.
The option to install v5.3 on AIX, restore the qmgrs there and then upgrade to v6.x on AIX was on the table, at the same time we are concerned of putting two QM’s with the same name on the network in the same cluster. This is a complex and risky thing.
Any further suggestions on this are welcome. Please share your ideas.
Regards,
-M |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 28, 2007 8:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mdncan wrote: |
| This is a complex and risky thing. |
Only if you try and use both simultaniously. 
You should not, strictly speaking, hold messages in a queue for any length of time. Could you suspend one queue manager, process the queue until empty then migrate it?
Failing that, I'd use a support pack or similar utility to unload / reload the queue.
Other opinions and strategies equally worthy of your consideration. 
_________________
Honesty is the best policy.
Insanity is the best defence.
Last edited by Vitor on Mon Apr 16, 2007 11:06 pm; edited 1 time in total |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Mar 29, 2007 2:05 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| jefflowrey wrote: |
Well, if you're moving OSes and moving hardware, then you aren't exactly "migrating" the queue managers. You're replacing them with newer ones.
Since the new qmgr will have a different QMID, you should remove each qmgr you wish to migrate from the cluster entirely - first unshare queues, then take the qmgr out of the cluster, then stop and delete cluster channels.
Then add the new qmgr to the cluster. |
That's right, but is should be possible, to preserve the QMgr by backing up the directory /var/mqm and restore it on the other system.
It is definitely possible, when you do not change the OS, but I did not test it between HP-UX and AIX, but I guess, it would work, because the format of the files is handled by MQ itself.
mdncan,
maybe, you should install MQ 5.3 on AIX first, to migrate from HP-UX to AIX and the install MQ 6, to migrate from 5.3 to 6.0.2.
But I am quite sure, there are test environments  .
_________________
Regards
Hubert
Last edited by HubertKleinmanns on Thu Mar 29, 2007 2:48 am; edited 1 time in total |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Mar 29, 2007 2:42 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I would really be surprised if "moving" /var/mqm from HP-UX to AIX would work, but would love to be proven wrong...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 29, 2007 3:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| HubertKleinmanns wrote: |
| That's right, but is should be possible, to preserve the QMgr by backing up the directory /var/mqm and restore it on the other system. |
I guess I said "Back up the qmgrs", implying "follow the existing procedures in the System Administration Guide for backup and recovery".
I'm less skeptical that tarring up /var/mqm and restoring it on a different platform will work than Michael is... but I'm still a little skeptical. I guess if I'd read the System Administration Guide procedures in the last six months, I might not be so skeptical.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| HubertKleinmanns |
| Posted: Thu Mar 29, 2007 5:19 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004
Posts: 732
Location: Germany
|
| jefflowrey wrote: |
...I guess I said "Back up the qmgrs", implying "follow the existing procedures in the System Administration
Guide for backup and recovery"... |
jefflowrey,
I only found a chapter Backing up and restoring WebSphere MQ, and this chapter essentially describes a mechanism, to tar and untar the qmgrs and log paths - this is mainly the same, as I described before .
Or do you have another document  ?
In a MQ cluster environment I would even suggest not to reuse the name of a QMgr (except by copying the files via tar to the new system - if it works for different plattforms).
The reason therefor is, that MQ somewhere stores informations about cluster attributes and also knows about queues, which phyically have been deleted. I am really not sure, if these informations will be cleared by using commands as RESET CLUSTER or REFRESH CLUSTER or after the 90 days expiry interval of MQ cluster objects (see the tool amqrfdm).
So first I would try to copy the files in /var/mqm from HP-UX to AIX and try to start the QMgr. If this does not work,
- I would create another QMgr with a new - till now unused - name,
- store the objects from the old QMgr via saveqmgr (SupportPac MS03),
- edit the output of saveqmgr (channels, QMgr-Names, SSL-Repository...),
- store the permissions of the old QMgr via amqoamd -s and redirect the output to a file,
- edit the output file and exchange the name of the QMgr,
- recreate the objects by reading the modified saveqmgr output into the new QMgr with runmqsc,
- and recreate the permissions by executing the output file of amqoamd .
This should work properly.
_________________
Regards
Hubert |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Mar 29, 2007 3:47 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| HubertKleinmanns wrote: |
jefflowrey,
I only found a chapter Backing up and restoring WebSphere MQ, and this chapter essentially describes a mechanism, to tar and untar the qmgrs and log paths - this is mainly the same, as I described before . |
Then I'll take your word for it. Like I said, I haven't looked at that section of the documentation in several months.
| HubertKleinmanns wrote: |
| Or do you have another document ? |
No, I wouldn't bother commenting about documents that were not publicly accessible...
| HubertKleinmanns wrote: |
| In a MQ cluster environment I would even suggest not to reuse the name of a QMgr (except by copying the files via tar to the new system - if it works for different plattforms). |
I'd agree with that. I tend to think that the only names applications should concern themselves with are queue names - qmgr names should be entirely decided by the MQ Administrators, and be only meaningful to the MQ administrators. So I find it perfectly reasonable when people want to name qmgrs after the server that hosts it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mdncan |
| Posted: Mon Apr 16, 2007 1:03 pm Post subject: |
|
|
Acolyte
Joined: 11 May 2005
Posts: 59
Location: US
|
Thanks Guys. Really appreciate your comments and suggestions. I will post here of the outcome of migration.
Regards,
mdncan |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
