| Author |
Message
|
| ruimadaleno |
 Posted: Mon Nov 07, 2016 2:17 am Post subject: Migration from Broker v8 to IIB v10 |
 |
|
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 |
|
 |
| zpat |
| Posted: Mon Nov 07, 2016 2:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| ruimadaleno |
| Posted: Mon Nov 07, 2016 8:12 am Post subject: |
|
|
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 |
|
|
| zpat |
| Posted: Mon Nov 07, 2016 8:46 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
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 |
|
|
| ruimadaleno |
| Posted: Tue Nov 08, 2016 2:08 am Post subject: |
|
|
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 |
|
|
| smdavies99 |
| Posted: Tue Nov 08, 2016 3:05 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
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 |
|
|
| mqjeff |
| Posted: Tue Nov 08, 2016 5:33 am Post subject: |
|
|
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 |
|
|
| Craig B |
| Posted: Thu Nov 10, 2016 2:51 am Post subject: |
|
|
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 |
|
|
| ruimadaleno |
| Posted: Thu Nov 10, 2016 8:13 am Post subject: |
|
|
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 |
|
|
| ruimadaleno |
| Posted: Thu Nov 10, 2016 8:32 am Post subject: |
|
|
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 |
|
|
| Craig B |
| Posted: Thu Nov 10, 2016 8:53 am Post subject: |
|
|
Partisan
Joined: 18 Jun 2003
Posts: 316
Location: UK
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Nov 10, 2016 11:13 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
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 |
|
|
| ruimadaleno |
| Posted: Fri Nov 11, 2016 7:57 am Post subject: |
|
|
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 |
|
|
|
|
