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

Post new topic  Reply 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

Novice

Joined: 14 Aug 2012
Posts: 20

!

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

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.
_________________
chmod -R ugo-wx /
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

Novice

Joined: 14 Aug 2012
Posts: 20

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

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

Novice

Joined: 14 Aug 2012
Posts: 20

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

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

Novice

Joined: 14 Aug 2012
Posts: 20

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

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

Novice

Joined: 14 Aug 2012
Posts: 20

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
exerk
PostPosted: Mon May 29, 2017 2:17 am    Post subject: Re: Further Queries Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

praveenhegde wrote:
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...

And just how are you going to have two different servers in the same network, with the same host names and IP Addresses, at the same time?

praveenhegde wrote:
...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.

I was pointing out that if your business partners do not wish to make any changes to their end that you will have 'hybrid' channel names, i.e. 'old' queue manager names in the channel definitions for the 'new' queue manager.

praveenhegde wrote:
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?.

As I cannot see your set-up, and you have not exactly explained it, advice was given on the assumption that channels to/from your business partner were CLUSSDR/CLUSRCVR and all others were internal, which your previous posts at least hinted at. If you create a new queue manager then its name will be inserted into the message header. Unless your business partners are doing something with the message header, e.g. parsing it for a particular queue manager name they expect to see, then it's a non-issue.

praveenhegde wrote:
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).

Then it is NOT a valid test of a migration scenario as far as I am concerned.

praveenhegde wrote:
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...

Finally you make clear your channel set up!

praveenhegde wrote:
...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.

There is no reason to strip messages from a transmission queue - just stop the applications and wait for the queues to drain naturally. Stop applications putting messages, if necessary by PUT(DISABLED) on queues. The application owners must be aware that changes are taking place and that an outage is necessary. Stop the channels from your partners.

praveenhegde wrote:
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...

The use of a queue manager alias, one used to remap a queue manager name, has no effect within a CCDT.

praveenhegde wrote:
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?.

If you have a new queue manager you will need a new certificate for that queue manager. If you are going to 're-use' the existing queue manager name then you can just copy the key store files to the 'new' queue manager's appropriate directory, the one where you wish to hold the key store files. And what has the @ipcc directory to do with certificate files?

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

I cannot see your configuration. I cannot see your topology. I cannot see your site standards documentation. Therefore, I cannot offer any further advice, but if you wish to engage my services as a consultant I would be more than happy to charge you for the privilege
_________________
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 5:12 am    Post subject: You Gave it !Stating Will not Give Anything Further! Thanks Reply with quote

Novice

Joined: 14 Aug 2012
Posts: 20



1. You are right!! How can we have QM and QM1 that too having the same name at same time, indeed its not possible. What we plan to do then I got the following?

1. We build the New RHEL V7(System R7) and Create QM1 and also create Qmgr Alias QM--->QM1 and import all the Queue and Channel definition to QM1. Now the RHEL V7 system is ready. Or as an alternative You can have Qmgr Name as QM itself since anyhow it will not conflict as stated earlier since both cannot have same server name and IP. in that case no Qmgr Alias needed at all.

2.Now we have old RHEL V5 system (System R5). Here we have QM Qmgr. inform all the stake holders for the outage and not to send messages as you suggested. Need to make sure that all the applications stop sending messages and messages are drained out of Transmission Queue and Stop all the channels forcefully.

3.Need to ensure that all the Local Queue messages are exported from R5 to R7 QM1 OR QM(in case of not using Alias).If still messages are being put, Make PUT disabled on all the Queues.
Now Make sure that you assign a new IP and Server Name to the current system i.e R5 --->R5_old, and then change the New system name i.e R7 --->R5 and IP to old address. Now no messages would flow to Old RHEL V5 system since its server and IP have been changed to something else...
and All Messages will come to RHEL V7 (i.e now R5 after reassignment.)

4.Now Ideally the system is ready for use, No changes required for CCDT if we use Qmgr Alias @ipcc (sorry for @ipcc confusion it is for CCDT not for ARM file). Regarding SSL of New Qmgr i.e QM1(if QM alias created)/QM if no alias created. same kind of process followed for creation of certification and no changes in Certificate Configuration values in any way(unless IBM MQ 9 puts some internal changes). Or copy the old Key store files on new Qmgr appropriate Directory.

Suppose say we have cluster for load balancing then architecture is like below


RHEL V5 (A) QM <------------------->RHEL V5(B) QMX <====> SAP etc applications connecting to both the servers with load distributed.

Now we have RHEL V7(C) system where we create Qmgr QM(without creating any Qmgr alias) and import all the Queue Channel Definition and if really needed import SSL key files as well or create its own as no name change has been done.

Now the new setup is fully ready with everything needed. Now our main task is to replace RHEL V5(A) QM with RHEL V7(A) QM. Need to take all the necessary actions to inform the stakeholders to stop the messages and the outage. Now just stop the listener to ensure no new connections are established, no new messages are delivered. But No restrictions on Sender and SVR channels as messages needs to be drained out of Transmission Queue and Other Queues if any. Once all the XMITQ messages are drained out, Stop All the Channels forcefully so applications will be able to PUT the messages or Do PUT disable on All the Queues.

Now export all the remaining messages using Q and Qload or someother way possible. Since there is already another server in cluster. Any new messages would be processed from that server(RHEL V5(B) QMX).

Now change the old server Name and IP i.e RHELV5(A) to RHELV5_old
Now assign the same name and IP to RHEL V7 , i.e RHEL V7(A) and make sure that below setup is maintained i.e both are in cluster and need to enable clustering among them with load balancing.


RHEL V7 (A) QM <------------------->RHEL V5(B) QMX <====> SAP etc applications connecting to both the servers with load distributed.

Once it is done, then need to ensure that messages are processing without any issues on RHEL V7 (A) QM.

Now we have workload balancing between RHEL V7 and RHEL V5 (do not know whether this creates any issues need to see).

If you are ready with another system RHEL V7(D) with QM Qmgr , then simply remove RHEL V5(B) QMX from the cluster and stop listener so that no messages would come in and Once no messages are in XmitQ then Stop the channels as well. Import all the Q data from RHEL V5(B) to RHEL V7(D) if any.

Now the RHEL V7(D) is ready for further migration. we need to convert RHEL V7(D) to RHEL V7(B).

Now Assign some new name and IP to the RHEL V5(B) i.e RHEL V5(B)_old once it is done , assign the old name B to RHEL V7(D).

Now the new system is RHEL V7(B) QMX. Now need to include it in the cluster and ensure workload balancing as below.

RHEL V7 (A) QM <------------------->RHEL V7(B) QMX <====> SAP etc applications connecting to both the servers with load distributed.

Verify messages are distributed among the servers and Enjoy if it works...Burn it down if it does not work in case!!

Any Further Input is most welcome in case interested!!!




Thanks
Praveen
_________________
Thanks & Regards,
Praveen Hegde


Last edited by praveenhegde on Mon May 29, 2017 11:06 pm; edited 1 time in total
Back to top
View user's profile Send private message
exerk
PostPosted: Mon May 29, 2017 5:24 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

Even if you 'reassign' the server name and IP Address to another server, one on which you have created a queue manager of the same name, you may have issues because the QMID will be different.

Still better to remove the queues from the cluster, remove the queue manager from the cluster, then shut down the server and reassign the DNS name etc. Bring up the new server, start the queue manager, put it back in the cluster, and add the queues in the cluster. Better to do that for every queue manager in the cluster you wish to migrate.
_________________
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 topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » IBM 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.