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 IndexWebSphere Message Broker SupportMigration from Broker v8 to IIB v10

Post new topicReply to topic
Migration from Broker v8 to IIB v10 View previous topic :: View next topic
Author Message
ruimadaleno
PostPosted: Mon Nov 07, 2016 2:17 am Post subject: Migration from Broker v8 to IIB v10 Reply with quote

Master

Joined: 08 May 2014
Posts: 274

Hi all,

we are planning to migrate our broker 8.0.0.7 environments to the latest IIB (10.0.0.6)

The first decision to make is to choose the migration path, where, as far as i know, there are two options:

a) upgrade broker v8 home and migrate
b) install iib v10 in a distinct home and redo all configs/deploys

Of course we are talking with IBM to help us in this migrations but, i'd like to ear from your experiences on this "adventures"


What are the pro/cons you see in these two options ?

What others points/pitfalls should we take care on migration planning ?

Additional Info:

Broker environment running on windows 2008 r2 enterprise servers
using IBM MQ 8.0.0.3
_________________
Best regards

Rui Madaleno
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Nov 07, 2016 2:46 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5758
Location: UK

Fairly obvious ones really

Option 1- no config changes needed to other applications/firewalls etc - but the backout may take longer. Everything in broker migrates or backs out at same time.

Option 2- config changes needed to other applications, but easy backout and staggered migration is possible. Parallel running possible.

If you migrate in place you need to test the effect of fresh deploys otherwise you will only find out later if they have issues.

If the broker is heavily shared, multiple applications then option 2 is easier. If it has a single purpose and application owner, then option 1 is possible.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
ruimadaleno
PostPosted: Mon Nov 07, 2016 8:12 am Post subject: Reply with quote

Master

Joined: 08 May 2014
Posts: 274

[quote="zpat"]
If you migrate in place you need to test the effect of fresh deploys otherwise you will only find out later if they have issues.
Quote:



Hi zpat, thank you for your answer.

can you elaborate further in the above statement ? as far as i know both options must be tested with fresh deploys. Is there any way the "migrate in place" more dangerous to fresh deploys ?

_________________
Best regards

Rui Madaleno
Back to top
View user's profile Send private message
zpat
PostPosted: Mon Nov 07, 2016 8:46 am Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5758
Location: UK

You could upgrade in place and not re-deploy anything.

But then you would not be testing what happens when you deploy to the new version.

There is also the matter of when to deploy v8 built bar files (to v10 brokers) or start using v10 built bar files.

Bear in mind that if you start using v10 built bar files, you can only promote the code to migrated brokers.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error.
Back to top
View user's profile Send private message
ruimadaleno
PostPosted: Tue Nov 08, 2016 2:08 am Post subject: Reply with quote

Master

Joined: 08 May 2014
Posts: 274

zpat wrote:
You could upgrade in place and not re-deploy anything.

But then you would not be testing what happens when you deploy to the new version.

There is also the matter of when to deploy v8 built bar files (to v10 brokers) or start using v10 built bar files.

Bear in mind that if you start using v10 built bar files, you can only promote the code to migrated brokers.


Good point !

what about the code generated in toolkit v8 ? sure it can be opened and modified in toolkit v10, but once the project has been opened in toolkit v10, it can not be used in v8 ? All developers must start using toolkit v10 and slowly (in parallel , as the projects need or other strategy)

Another question: in case of option 2) all configs must be redo in the new iib v10 instalation. The point here is, we have a record of settings/configurations but this is not highly governed, so , as murphy law says, there must be a set of "forgotten" properties/settings/configurations. Can the output of mqsibackupbroker help me on this ?
_________________
Best regards

Rui Madaleno
Back to top
View user's profile Send private message
smdavies99
PostPosted: Tue Nov 08, 2016 3:05 am Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6077
Location: Somewhere over the Rainbow this side of Never-never land.

ruimadaleno wrote:
The point here is, we have a record of settings/configurations but this is not highly governed, so , as murphy law says, there must be a set of "forgotten" properties/settings/configurations. Can the output of mqsibackupbroker help me on this ?


Do you not think that now is a good time to rectify that?
Build some scripts that build and condifure the IIB 10 Broker from first principles. Then enforce change control. This will save you a lot of grief in the future.

As for moving TK's, I'd again use Source control and keep the V8 branch going as long as needed but I'd fork it at a suitable point and create a V10 branch. Import it into V10 and build the bar files without making any code changes. Check it all back and you should be good to go.
Your developers will know where they stand. Running V8 (for maintenance) then go to the V8 branch. etc etc.

Obviously, you will need to modify this scenario for your environment but here is a great opportunity to stop 'murphy' in his tracks.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Nov 08, 2016 5:33 am Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

How do you upgrade any other piece of software?

Use the same general procedures, except with IIB.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
Craig B
PostPosted: Thu Nov 10, 2016 2:51 am Post subject: Reply with quote

Partisan

Joined: 18 Jun 2003
Posts: 316
Location: UK

If you are going to use mqsimigratecomponents to migrate your existing V8 run-times to V10 then I would consider getting two APAR fixes to make sure that this migration does not encounter any issues.

APAR IT17745 resolves an issue whereby after migration execution groups that should have been in stopped state are actually running but the administration thinks they are in stopped state.

APAR IT16718 resolves an issue where a flow that references deployable subflows loses its flow level attributes on migration such as additional instances, commitCount, deploy information, monitoring profile etc.

Both of these will be resolved in 10.0.0.7 so you might want to wait for this fixpack to be released and migrate to this level.

It should also be noted that back migration (reverting to the previous versions) is a little more strict in V10. If you do any of the following at V10 then you cannot use mqsimigratecomponents with a lower -t target version:

1) Created a new integration server at V10.
2) Deployed a shared library to an integration server
3) Removed the default queue manager from the broker
4) If you set/change the broker to use file based administration security.
_________________
Regards
Craig
Back to top
View user's profile Send private message
ruimadaleno
PostPosted: Thu Nov 10, 2016 8:13 am Post subject: Reply with quote

Master

Joined: 08 May 2014
Posts: 274

Quote:

Do you not think that now is a good time to rectify that?


Yes ! definitely i'll try to enforce a better change control

Quote:

Build some scripts that build and condifure the IIB 10 Broker from first principles. Then enforce change control. This will save you a lot of grief in the future.


can you provide more info on how you manage change ? do you keep you scripts in source control ? do you have somekind of "master file" with all broker configs on it ?

Quote:

As for moving TK's, I'd again use Source control and keep the V8 branch going as long as needed but I'd fork it at a suitable point and create a V10 branch. Import it into V10 and build the bar files without making any code changes. Check it all back and you should be good to go.
Your developers will know where they stand. Running V8 (for maintenance) then go to the V8 branch. etc etc.


Very useful information ! we will create a branch for iibV10, copy the code there.
_________________
Best regards

Rui Madaleno
Back to top
View user's profile Send private message
ruimadaleno
PostPosted: Thu Nov 10, 2016 8:32 am Post subject: Reply with quote

Master

Joined: 08 May 2014
Posts: 274

Craig B wrote:
If you are going to use mqsimigratecomponents to migrate your existing V8 run-times to V10 then I would consider getting two APAR fixes to make sure that this migration does not encounter any issues.

APAR IT17745 resolves an issue whereby after migration execution groups that should have been in stopped state are actually running but the administration thinks they are in stopped state.

APAR IT16718 resolves an issue where a flow that references deployable subflows loses its flow level attributes on migration such as additional instances, commitCount, deploy information, monitoring profile etc.

Both of these will be resolved in 10.0.0.7 so you might want to wait for this fixpack to be released and migrate to this level.

It should also be noted that back migration (reverting to the previous versions) is a little more strict in V10. If you do any of the following at V10 then you cannot use mqsimigratecomponents with a lower -t target version:

1) Created a new integration server at V10.
2) Deployed a shared library to an integration server
3) Removed the default queue manager from the broker
4) If you set/change the broker to use file based administration security.


Hi CraigB, can you tell me the date for 10.0.0.7 release ? (been searching on ibm support site but no luck to find it)
_________________
Best regards

Rui Madaleno
Back to top
View user's profile Send private message
Craig B
PostPosted: Thu Nov 10, 2016 8:53 am Post subject: Reply with quote

Partisan

Joined: 18 Jun 2003
Posts: 316
Location: UK

As documented on the following:

http://www-01.ibm.com/support/docview.wss?uid=swg27006308

It is down for 4th quarter this year. No specific date has been given yet.
_________________
Regards
Craig
Back to top
View user's profile Send private message
smdavies99
PostPosted: Thu Nov 10, 2016 11:13 pm Post subject: Reply with quote

Jedi Council

Joined: 10 Feb 2003
Posts: 6077
Location: Somewhere over the Rainbow this side of Never-never land.

ruimadaleno wrote:


can you provide more info on how you manage change ? do you keep you scripts in source control ? do you have somekind of "master file" with all broker configs on it ?



This is my approach to it. Others may well have different ways of getting to the same point.

The scripts to create and populate MQ and Broker are indeed held in source control.
When I do a release build, the scripts are checked out, updated as required and commited back into Source Control (Git).
The scripts are applied and a QMGR or Broker (or Both) is built.
As the scripts also contain operations to extract data from the created thing so that the commands can be verified as succeding the whole thing, scripts and validation output is collected up and put into source control as a .zip file.
That gives me a complete record of what was used to create what and when plus the validation output at the time of creation.

By validation I mean
- For MQ the output of a dmpmqcfg command(s)
- for broker the output from mqsireportproperties, mqsicvp etc
All the commands used are also echoed to a log file that also captures the output from say runmqsc etc.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995

Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions.
Back to top
View user's profile Send private message
ruimadaleno
PostPosted: Fri Nov 11, 2016 7:57 am Post subject: Reply with quote

Master

Joined: 08 May 2014
Posts: 274

smdavies99 wrote:


This is my approach to it. Others may well have different ways of getting to the same point.

The scripts to create and populate MQ and Broker are indeed held in source control.
When I do a release build, the scripts are checked out, updated as required and commited back into Source Control (Git).
The scripts are applied and a QMGR or Broker (or Both) is built.
As the scripts also contain operations to extract data from the created thing so that the commands can be verified as succeding the whole thing, scripts and validation output is collected up and put into source control as a .zip file.
That gives me a complete record of what was used to create what and when plus the validation output at the time of creation.

By validation I mean
- For MQ the output of a dmpmqcfg command(s)
- for broker the output from mqsireportproperties, mqsicvp etc
All the commands used are also echoed to a log file that also captures the output from say runmqsc etc.


Thank you for you input, i will use it as inpiration for improving our governance.
_________________
Best regards

Rui Madaleno
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 IndexWebSphere Message Broker SupportMigration from Broker v8 to IIB v10
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.