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 IndexGeneral IBM MQ SupportIBM MQ/IIB9 Migration from RHEL V5 to RHEL V7: Plan Issue

Post new topicReply to topic
IBM MQ/IIB9 Migration from RHEL V5 to RHEL V7: Plan Issue View previous topic :: View next topic
Author Message
praveenhegde
PostPosted: Fri May 19, 2017 3:35 am Post subject: IBM MQ/IIB9 Migration from RHEL V5 to RHEL V7: Plan Issue Reply with quote

Newbie

Joined: 14 Aug 2012
Posts: 5

!

Hi All, We are migrating IBM MQ/IIB9 from RHEL V5(A) --->RHEL V7(B). We had a plan of
1.Stop IIB9/IBM MQ on RHEL V5(A).
2.Install Fresh IBM MQ/IIB9 on RHEL V7(B).
3.Export File System Data and Configuration to New RHEL V7(B) (So that no data in processing stage gets lost).
4.Change the RHELV5 system Name/IP(so that Name Resolution Conflict Does not occur). RHEL V5_Old(C).
5. Start IBM MQ/IIB9 on RHEL V7 and Change the Name of RHEL V7 to Old Name(A) so that all Application will connect to the same server and no changes needed at their side.
We had successfully done it on SandBox, but!

Since Our Service Owner observed too many teams involved for action(MQ/MB,UNIX,VMWARE,BACKUP,MONITORING etc) and total time taken for outage(which is restricted to 1:30 hour max).

Now the plan is to

1. Install Latest IIB and IBM MQ9 on the new RHEL V7(B) system and all other required components.
2. Exporting IBM MQ and IIB9 Configuration from RHEL V5(A) to RHEL V7(B). But Changing the Qmgr Name to QM1 which was QM on RHEL V5(A). Importing all the Queue configuration and Broker from RHEL V5 system.
3.Including the New RHEL V7 system in the Cluster(But the problem is Since the Queue Names are same on both the system in the cluster messages will get distributed ! but No messages from RHEL V7(B) will get processes since no SAP/other applications are connected , they are only connected to RHEL V5).
4.Then Further Plan is unclear, though we are simply thinking of Stopping the Channels on RHELV5, and Making PUT Disabled on Queues,not the GET because messages needs to get processed.
5.Once we ensure No messages on RHEL V5, then change the name of RHEL V5 to A_Old and Rename RHEL V7 to A. Then all the SAP/Other applications are able to connect and Pending Messages on RHEL V7(now A) will get processed.

or Is it good , to make PUT Disabled on RHEL V7 when it is brought to cluster and also make PUT Disabled on RHEL V5 at same time and then make the changes(Changing Name/IP) once all the messages from RHEL V5 are processed?.

Another issue is , since these Qmgrs are accessed by Remote Site(where they have also defined RQs, Channels directing to our Old Qmgr Name i.e QM. Changing the QMgr Name to QM1 would have an effect to change definition on all remote sides(with access and without access). Hence is it Good Idea to go with Qmgr Alias? does it have any intern effect...

Sorry for Long Description .. If anybody can give better idea that would be great!!

[/b]
_________________
Thanks & Regards,
Praveen Hegde
Back to top
View user's profile Send private message
mqjeff
PostPosted: Fri May 19, 2017 3:57 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17092

You can probably avoid having the cluster get messy by making sure the listener doesn't start... set the listener service to start manually, and then don't start it.

Once the new queue manager is up and running and the old one is shut down, then you can probably stop the listener on the *old* machine and stop the old queue manager entirely. Then start the listener on the new machine.

Mind you, that's *probably*.

You still need to stop and start any applications that don't restart MQ connections when there's a failure. But you would have to do that no matter what.

One very significant warning. Putting more than one queue manager with the same name in a cluster at the same time is *bad*, and will lead to a corrupted cluster.

So *don't* do that.
_________________
Read, Think, Try, Repeat
Back to top
View user's profile Send private message
praveenhegde
PostPosted: Mon May 22, 2017 4:34 am Post subject: IBM MQ/IIB9 Migration from RHEL V5 to RHEL V7: Plan Issue Reply with quote

Newbie

Joined: 14 Aug 2012
Posts: 5

Dear MqJeff, Thanks a lot for the reply. Some clarification on your assumption.

1. We are not including New Qmgr with same name , we are doing QM(RHELV5)--->QM1(RHEL V7).
2. We are importing all the Queue Configuration from QM(RHEL V5) to QM1(RHEL V7). Hence same name of Queues/Channels will be kept.
3. I would like to know how to address this Qmgr Name Change issues? like new Qmgr Name is QM1. Hence on Remote Sites channels/Remote Queues connecting will have the Old Definition (which we dont want to change , since thousands of such instances). Does Qmgr Alias on RHEL V7 preferable?.
4. You have suggested to stop Qmgr entirely, but How to address the issue of Message Processing i.e Large Number of Messages in the Queue which needs to be processed?. How to ensure that only GET applications able to get messages but no application should be able to PUT the messages to the queue?. Is it through PUT Disable on All the Queues? it is messy if SDLQ(Dead Letter Queue is defined since again messages go to DLQ!). We are using DLQ. If we stop listener on old, we cant even export Q data using Q and Qload utility!.
5. Completely agree that remote application must restart if there is a failure!
_________________
Thanks & Regards,
Praveen Hegde
Back to top
View user's profile Send private message
exerk
PostPosted: Mon May 22, 2017 5:11 am Post subject: Re: IBM MQ/IIB9 Migration from RHEL V5 to RHEL V7: Plan Issu Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5603

Some thoughts...

praveenhegde wrote:
1. We are not including New Qmgr with same name , we are doing QM(RHELV5)--->QM1(RHEL V7).
2. We are importing all the Queue Configuration from QM(RHEL V5) to QM1(RHEL V7). Hence same name of Queues/Channels will be kept.

So, you'll import the existing CLUSTER channels into your new queue managers. Have you thought that doing so will give a mismatch? For example, QM_NEW will have channels named QM_OLD, which may lead to confusion during the migration, and thereafter.

praveenhegde wrote:
3. I would like to know how to address this Qmgr Name Change issues? like new Qmgr Name is QM1. Hence on Remote Sites channels/Remote Queues connecting will have the Old Definition (which we dont want to change , since thousands of such instances). Does Qmgr Alias on RHEL V7 preferable?.

If you have SDR/RCVR channels from partners you should have used generic names for the queue manager and channels at the time of configuration, for example told your partners that the queue manager name to send to was QM000, and used a queue manager alias to remap the queue manager name. It would also mean that you could 'reuse' the channel names anywhere you migrated a queue manager. If you have CLUSSDR/CLUSRCVR channels internally, then the 'problem' of changing queue manager names does not arise.

praveenhegde wrote:
4. You have suggested to stop Qmgr entirely, but How to address the issue of Message Processing i.e Large Number of Messages in the Queue which needs to be processed?...

Stop all sending applications if you can but if not put your new queue managers in the cluster, with their queues available, and suspend the old queue managers. So long as their queues are not the last available target, no further messages will go to them. Stop the queue managers when there are no more messages to process, but after you have dropped them from the cluster.

praveenhegde wrote:
...How to ensure that only GET applications able to get messages but no application should be able to PUT the messages to the queue?. Is it through PUT Disable on All the Queues? it is messy if SDLQ(Dead Letter Queue is defined since again messages go to DLQ!). We are using DLQ...

See above.

praveenhegde wrote:
...If we stop listener on old, we cant even export Q data using Q and Qload utility!.

Why not? Why can't you unload to file, copy/move the file, and reload the messages in the new queue instance?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
praveenhegde
PostPosted: Wed May 24, 2017 2:45 am Post subject: Thanks to exerk for Enlightning on Q and Qload :) Reply with quote

Newbie

Joined: 14 Aug 2012
Posts: 5

Dear exerk! thanks a lot for giving further clarification. Due to your reply I had to stop listener and practically check whether Q and Qload utility works or not. I was in a mode of think utility will not work(but surely I know runmqsc works!! ha ha ) if we stop listener.

Need your expert input on following.

1. Do I need to stop listener on RHEL V7(QM1) while including it in the cluster then? so that messages wont flow to new Clustered Qmgr till the old one is down?.

2.When I suspend the Qmgr(i.e RHEL V5 QM) from the cluster, does it mean that all the Applications connecting using Remote Queue will not have access along with Clustered Applications? is it better also stop Listener Along with it so that nobody will be able to communicate? Does Suspend of Qmgr means nobody will be able to communicate and do transaction or its just suspending it only from Cluster?.

3. Or is it better to when we dont change the Qmgr Name ? like i)Save Qmgr of Old QM , 2)then import and install it on New QM iii)Bring the new system to cluster iv)Now Stop the Listener or Suspend Qmgr(this suspend will be only if retained messages in MQ are exported to New system since Applications will not be able to access Qmgr once it is out of cluster if i am correct) so that no further messages will come 3) bring New QM1 into cluster(we also need to ensure Listener ports are same on New since many applications have defined at remote side) Since now we have Same Qmgrs on Different systems i.e RHEL V5 and RHEL V7 in same cluster. Does it create any issues in that case?
or Following is much more better?

i)SaveQmgr on RHEL V5 ii)Stop the listener Old QM on RHEL V5 so no further messages will come iii) Export all the data on the Queue using q/qload utility(since it works just now verified after your suggestion) iv)Stop the Old QM on RHEL V5 iv)Include the new QM of RHEL V7 in cluster and import all messages using q/qload utility on IBM MQ9 (RHEL V7).

4. If suppose we are changin the Qmgr name to QM1 on RHEL V7,Can you suggest any solution for the same Because we also need to keep it in mind that Remote Application will not change any script !

Need to Also do Server Name/IP Change i.e RHEL V5 name should be assigned to RHEL V7 system(Name and IP should be the same as old on new server).

5.May I know When Does Qmgr Alias will come into Picture? Can we create Qmgr Alias for QM1 as QM(i.e Old Name) on RHEL V7 itself So that After Messages Reach to RHEL V7 system through channels , name QM should get resolved to QM1, in that scenario all the issues should get resolved. Please suggest and Correct and Help ...I may be wrong in logic!!
_________________
Thanks & Regards,
Praveen Hegde
Back to top
View user's profile Send private message
exerk
PostPosted: Wed May 24, 2017 4:10 am Post subject: Re: Thanks to exerk for Enlightning on Q and Qload :) Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5603

praveenhegde wrote:
1. Do I need to stop listener on RHEL V7(QM1) while including it in the cluster then? so that messages wont flow to new Clustered Qmgr till the old one is down?.

To put your new queue manager in the cluster you will need to have its Listener running, but you do not have to put the queues into the cluster until you are ready.

praveenhegde wrote:
2.When I suspend the Qmgr(i.e RHEL V5 QM) from the cluster, does it mean that all the Applications connecting using Remote Queue will not have access along with Clustered Applications?...

It means that any cluster queues in the suspended queue manager will not get messages UNLESS there is no other available instance of the queue elsewhere. Applications connecting to that queue manager, whether in bindings mode or client mode, will still be able to put/get messages.

praveenhegde wrote:
...is it better also stop Listener Along with it so that nobody will be able to communicate?...

You could stop the Listener but that will not affect running channels, but will prevent new channel instances starting. It will also affect any applications that try to connect via client mode.

praveenhegde wrote:
...Does Suspend of Qmgr means nobody will be able to communicate and do transaction or its just suspending it only from Cluster?.

See above.

praveenhegde wrote:
3. Or is it better to when we dont change the Qmgr Name ? like i)Save Qmgr of Old QM , 2)then import and install it on New QM 3) bring it cluster ? Since now we have Same Qmgrs on Different systems i.e RHEL V5 and RHEL V7 in same cluster. Does it create any issues in that case?

You cannot have two separate queue managers of the same name in a cluster, not unless you want a whole world of hurt. Don't ever, EVER do it.

praveenhegde wrote:
...or Following is much more better?

i)SaveQmgr on RHEL V5 ii)Stop the listener Old QM on RHEL V5 so no further messages will come iii) Export all the data on the Queue using q/qload utility(since it works just now verified after your suggestion) iv)Stop the Old QM on RHEL V5 iv)Include the new QM of RHEL V7 in cluster and import all messages using q/qload utility on IBM MQ9 (RHEL V7).

The ideal would be to stop anything from sending messages, or if that is not possible, suspend the old queue manager and stop its CLUSRCVR instances, move the messages to the new queue manager and cluster the new queue instances, then restart the old queue manager's CLUSRCVR. You will find that any in-flight messages to the old queue manager will land in its queues but you can deal with them the same way as before.

praveenhegde wrote:
4. If suppose we are changin the Qmgr name to QM1 on RHEL V7,Can you suggest any solution for the same Because we also need to keep it in mind that Remote Application will not change any script !

A queue manager alias should take care of this but again, you have not provided information as to how your business partner is sending messages, i.e. over SDR/RCVR channels or CLUSSDR/CLUSRCVR channels.

praveenhegde wrote:
Need to Also do Server Name/IP Change i.e RHEL V5 name should be assigned to RHEL V7 system(Name and IP should be the same as old on new server).

The new server will have a different name, the IP Address will be different. Or if you are using a DNS name for your queue manager, if that DNS name contains the queue manager name, e.g. qmgr_old.my.company.com, transferring that DNS name could lead to confusion in the future. But you should not be clustering your queue managers with that of external business partners.

praveenhegde wrote:
5.May I know When Does Qmgr Alias will come into Picture? Can we create Qmgr Alias for QM1 as QM(i.e Old Name) on RHEL V7 itself So that After Messages Reach to RHEL V7 system through channels , name QM should get resolved to QM1, in that scenario all the issues should get resolved. Please suggest and Correct and Help ...I may be wrong in logic!!

A queue manager alias is generally used to remap one queue manager name to that of another, so you would create the alias in your new queue manager.


You have not made it at all clear whether your business partner uses SDR/RCVR channels to send message to you, or that your queue manager and your business partner's queue manager are in the same queue manager cluster (very bad practice!).


So, to my advice: please tell us how your business partner connects as that knowledge will affect any further advice.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
praveenhegde
PostPosted: Wed May 24, 2017 6:05 am Post subject: Channels for the Issue Reply with quote

Newbie

Joined: 14 Aug 2012
Posts: 5

Dear Exerk,

Thanks for the quick reply. Below are information that you needed.

1. Regarding the channels being used(verified the server, found SVR, CLUSRCVR,SVRCONN,SDR,RQSTR,RCVR,CLNTCONN channels being used).

2. You have mentioned that, remove Old Qm from Cluster, move messages to new instances. Then you mentioned "Restart of CLUSRCVR" to ensure inflight messages are put to queues and repeat , But My limited knowledge about CLUSRCVR says it can be only created, but it will come to running state when Other Remote CLUSSDR connects to it and creates the instance! How can I restart CLUSRCVR? bit confused! Plz suggest.

3. For Qmgr Alias clarification, as suggested the channels are mix of all in architecture.

4.Regarding the Name Change: Clarification. RHEL V5(A) is the system to which All SAP and Other applications are connected and configured respectively. Hence we want to ensure that , same Server Name i.e A is assigned to RHEL V7. Our UNIX Team will ensure to make required changes in /etc/host and other Files. We are ensuring that RHEL V5 is changed to Name A_old and IP is also Changed so that these can be allocated to new server. We had tested it successfully first time using the FIRST METHOD in the FIRST POST of mine.

5.Our Business partners are not in the same cluster, But only trusted inside business Qmgrs are in Cluster Mode for your clarification. As stated we are using all type of Channels.
_________________
Thanks & Regards,
Praveen Hegde
Back to top
View user's profile Send private message
exerk
PostPosted: Wed May 24, 2017 7:01 am Post subject: Re: Channels for the Issue Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5603

praveenhegde wrote:
1. Regarding the channels being used(verified the server, found SVR, CLUSRCVR,SVRCONN,SDR,RQSTR,RCVR,CLNTCONN channels being used).

Internally to your business you are going to have to take the appropriate actions for those channel types other than CLUSRCVR, e.g. new CCDT files, new CONNAME values etc.

praveenhegde wrote:
2. You have mentioned that, remove Old Qm from Cluster, move messages to new instances. Then you mentioned "Restart of CLUSRCVR" to ensure inflight messages are put to queues and repeat , But My limited knowledge about CLUSRCVR says it can be only created, but it will come to running state when Other Remote CLUSSDR connects to it and creates the instance! How can I restart CLUSRCVR? bit confused! Plz suggest.

A CLUSRCVR, like any other channel can be stopped, but it can take some time to take effect.

praveenhegde wrote:
3. For Qmgr Alias clarification, as suggested the channels are mix of all in architecture.

You will most certainly need a queue manager alias for anything coming in over RCVR channels if those channels are used by your business partners. As for the other channel types, see my first paragraph.

praveenhegde wrote:
4.Regarding the Name Change: Clarification. RHEL V5(A) is the system to which All SAP and Other applications are connected and configured respectively. Hence we want to ensure that , same Server Name i.e A is assigned to RHEL V7. Our UNIX Team will ensure to make required changes in /etc/host and other Files. We are ensuring that RHEL V5 is changed to Name A_old and IP is also Changed so that these can be allocated to new server. We had tested it successfully first time using the FIRST METHOD in the FIRST POST of mine.

So you have already proved a viable (for you) solution, assuming that the SAP and other applications are not dependent on retaining the same queue manager name. Was your sandbox queue manager stand-alone, or in a cluster? Consider that.

praveenhegde wrote:
5.Our Business partners are not in the same cluster, But only trusted inside business Qmgrs are in Cluster Mode for your clarification. As stated we are using all type of Channels.

You will still have the issue that your business partners will either have to create new channel definitions and alter any QREMOTE objects, or you will have to suffer using old channel names in your new queue manager, and a queue manager alias.


If you have such connections it is always a good idea to use generic channel names, for example BP0001.EGW000, and generic queue manager names (not the name of the real queue manager, so you's still need a queue manager alias), so that any internal moves can be easily achieved without too many issues. Ideally you should configure things such that once implemented at the business partner end, the business partner will not have to make any changes in the future.

Talk to your business partners, see if they are amenable to creating new channel objects using generic names, and altering queue objects now to use a generic queue manager name. Stress the future-proofing aspect and you may find them receptive.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportIBM MQ/IIB9 Migration from RHEL V5 to RHEL V7: Plan Issue
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.