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: 6

!

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: 17094

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: 6

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: 5604

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: 6

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: 5604

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: 6

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: 5604

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
praveenhegde
PostPosted: Mon May 29, 2017 1:16 am Post subject: Further Queries Reply with quote

Newbie

Joined: 14 Aug 2012
Posts: 6

1. As you suggested , We need to take appropriate actions for CCDT Files, New Conname only if : 1. If we are installing New MQ Qmgr(QM1) on RHEL V7 with different Server Name and IP Address(Correct if I am wrong). But in our case we are ensuring that Same IP and Server Name is kept since new server is also in same VLAN. Still do we need to do any changes if "We are Creating New Qmgr QM1 on RHEL V7 and Qmgr Alias(RMQ) QM--->QM1 on RHEL V7 itself and keeping the same Old Channel Names?" Does it require any configuration level change?Plz suggest.

2. Thanks for clarifying CLUSRCVR confusion.

3. You mentioned that Qmgr Alias is needed for anything coming in over RCVR to RHEL V7 Qmgr from Other Business Partners, But what about the SDR, SVR channels which would be using the new Qmgr QM1 to Send it? Each Messages sent by QM1(RHEL V7 Qmgr) might have the header data of QM1 but not QM(RHEL V5 Qmgr). Hence does it get accepted at Our Business Partners RCVR which could be expecting data from QM(RHEL V5 Qmgr)? How to address any issues related to it?.

4.Regarding the Sandbox Qmgr , it was stand alone. It was tested with previous method mentioned without considering any applications or business partners connecting to it. SAP and other applications may be using the Qmgr Name(I am not 100% sure of theirs applications code but in some cases I have felt they are using it).

5.Thanks for giving a clear picture of Option of Changing the Object Definitions or Creating the Qmgr Alias.

Suppose say we are considering the Creating Qmgr Alias and Retaining the old Channel Name. Then,
As I had mentioned earlier. Since we have Cluster Qmgrs as well as Business Partners out of Cluster as well. Suspending the Qmgr out of cluster would only address for Clustered Partners, its not feasible solution for Non-Clustered Partners. Please give your input how both can be handled? is it 1.Making QM Out of Cluster to ensure no Cluster Messages would come, 2. Stopping the Listener to Ensure no New Connections are established, 3.Forcefully Stopping the SVR/ Other Channels except SVRCONN channels since they might be putting or getting the messages from queue or STOP SVRCONN as well 4.Extract the messages from All Local Queues and Transmission Queues of RHEL V5 --QM (Have doubt whether porting Transmission Messages will work or not since the Header is of old QM). and port it to RHEL V7 QM1. 5.Once all the messages are ported , create Qmgr Alias on RHEL V7 QM-->QM1, and Shutdown the old QM of RHEL V7. Now the Old messages imported from RHEL V5 and new incoming messages would ideally work!. Please correct and suggest.

I have comeup with another issues related to
1. Do we need to make any changes to CCDT of Remote Servers if we are using Qmgr Alias concept? I feel its not required , please clarify.
2.What kind of SSL changes are needed if we go by this? because Though the Server Name and IP is same as old for RHEL V7, the Qmgr Name has been changed! I am not sure does the Certificate / new arm files at @ipcc needs to be exchanged?.

Please do let me know what other configuration changes are necessary to ensure successfull migration and working environment?


Sorry for Delayed Response and information ... was on leave!

Thanks
Praveen Hegde
_________________
Thanks & Regards,
Praveen Hegde
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.