| Author |
Message
|
| sealpup |
 Posted: Mon Jul 29, 2013 12:22 am Post subject: deploying flows with WMB v 8.0.0.2 - copying filesystem? |
 |
|
Apprentice
Joined: 21 Sep 2010
Posts: 26
|
We are currently on WMB v6.1.0.9, imminently moving to v8.0.0.2, running on RHL.
Our Production messageflow deploys currently take a long time and are on the critical path. We have a number of sneaky ways to speed this up which I don't need to bother you with.
I have deployed our full Prod barfiles to an empty execution group on v8.0.0.2 and it takes 36% of the v6 time. That's good.
However, given the 'no broker database/no config manager' setup with v8 we have an idea to deploy our Production messageflows to a staging machine the night before the Production release, then come deploy time for real in Production, simply copy/replace the filesystem from the staging machine to the Production machine. That would make our Production deploy time..... well, seconds.
Has anyone actually done this as a method of deployment?
If so, precisely what parts of the filesystem (RHL) did you copy over?
Any pitfalls? I wouldn't want to miss anything!
Alternatively, some of the clever IBM people who lurk around here might be able to give a nice definitive answer on the feasability of this....
Thank and regards,
pup |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Mon Jul 29, 2013 3:16 am Post subject: Re: deploying flows with WMB v 8.0.0.2 - copying filesystem? |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sealpup wrote: |
| we have an idea to deploy our Production messageflows to a staging machine the night before the Production release, then come deploy time for real in Production, simply copy/replace the filesystem from the staging machine to the Production machine. That would make our Production deploy time..... well, seconds. |
You are making the assumption that a bar deployment includes only files. This is not true. How do you plan to handle the registry?
| sealpup wrote: |
| Has anyone actually done this as a method of deployment? |
No, because most people follow the IBM prescribed procedures for deploying bars:
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Faf02070_.htm
| Quote: |
Incremental BAR file deployment
If you run an incremental deployment of a BAR file, the broker extracts the contents of the BAR file and sends the contents to the specified execution group. The following conditions are applied when a file is deployed to the BAR file.
If a file in the BAR file has the same name as an object that is already deployed to the execution group, the version that is already deployed is replaced by the version in the BAR file.
If a file in the BAR file is of zero length, and a file of that name has already been deployed to the execution group, the deployed file is removed from the execution group.
Use incremental BAR file deployment to deploy applications, libraries, message flows, message model schema files, or other deployable objects incrementally to an execution group.
To completely clear the contents of the execution group before the BAR file is deployed, use complete BAR file deployment instead. |
| sealpup wrote: |
| If so, precisely what parts of the filesystem (RHL) did you copy over? Any pitfalls? I wouldn't want to miss anything! Alternatively, some of the clever IBM people who lurk around here might be able to give a nice definitive answer on the feasability of this.... |
Pitfalls? I guess you'll discover them. There are no shortcuts to prosperity.
Have you ever considered running an active-active setup, where you only take down one side at a time for maintenance? Or active-passive, where you deploy the bars to the inactive cell, then switch over? Your deployments may run faster if you deploy locally instead of over-the-network. In other words, copy the bar to the local system then run mqsideploy on the local system.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jul 29, 2013 3:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| Our Production messageflow deploys currently take a long time and are on the critical path |
Do they contain any message models ( XML Schemas or message sets )?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Jul 29, 2013 3:52 am Post subject: Re: deploying flows with WMB v 8.0.0.2 - copying filesystem? |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| sealpup wrote: |
Our Production messageflow deploys currently take a long time and are on the critical path. We have a number of sneaky ways to speed this up which I don't need to bother you with.
|
How often are you really deploying to PROD? (100+ times a day or once a day)
How long is 'A long Time'?
Do you have more than one deployable object in the Bar file?
Are there any 'quiet' periods for your system?
_________________
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 |
|
|
| sealpup |
| Posted: Mon Jul 29, 2013 4:43 am Post subject: |
|
|
Apprentice
Joined: 21 Sep 2010
Posts: 26
|
Thanks for your assistance.
| Quote: |
| You are making the assumption that a bar deployment includes only files. This is not true. How do you plan to handle the registry? |
As I originally stated, I am running on RHL. I don't believe /var/mqsi/registry/<BROKER>/* is going to cause me any issues unless I add/change an XSL stylesheet, in which case I'll copy that data over too. I am happy for someone who actually knows to inform me otherwise.
| Quote: |
| Do they contain any message models ( XML Schemas or message sets )? |
Yes they do indeed....The relevance of that question as yet eludes me. Please enlighten. Thanks. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Jul 29, 2013 4:51 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| sealpup wrote: |
Thanks for your assistance.
| Quote: |
| You are making the assumption that a bar deployment includes only files. This is not true. How do you plan to handle the registry? |
As I originally stated, I am running on RHL. I don't believe /var/mqsi/registry/<BROKER>/* is going to cause me any issues unless I add/change an XSL stylesheet, in which case I'll copy that data over too. I am happy for someone who actually knows to inform me otherwise.
|
Your welcome. I find your attempt to reduce deployment time admirable.
What's the plan to update the UUIDs inside the registry to match your destination broker?
How will you duplicate the messages on the $SYS/Broker/broker_name/Configuration/ExecutionGroup/exec_grp_name topic?
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jul 29, 2013 5:09 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
There are known performance issues around the deployment of xsds in v8.0.0.x. The compilation of the xsds can take a lot of CPU.
What xsds are you deploying? How large? How many? For what purpose?
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| sealpup |
| Posted: Mon Jul 29, 2013 5:34 am Post subject: |
|
|
Apprentice
Joined: 21 Sep 2010
Posts: 26
|
We have about half a dozen xsds. Not very large.
Ideally they would be handled elsewhere, but we have the legacy to deal with. I'm not too concerned about them - the xsdzip's average about 15k.
I wonder if I can
1. deploy to the staging host
2. copy the contents of /var/mqsi/components/<Brokername>/<exegroup>/config to Prod box
3. copy the contents of /var/mqsi/components/<Brokername>/<exegroup>/repository to Prod box
And bingo, we have a freshly deployed broker.
I wonder even more deeply if anyone on here actually knows for sure. |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Jul 29, 2013 5:47 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
OK - I don't think the xsds are the issue, then.
I would not advise you to continue with your present strategy. If you find that deployment times are unacceptably long then you should feed that back to IBM. You should not attempt to treat WMB as if the deployment process is a simple file copy. It's not.
_________________
Before you criticize someone, walk a mile in their shoes. That way you're a mile away, and you have their shoes too. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 29, 2013 5:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
In v8, particularly with mqsipackagebar, the compilation of ESQL and the message flows (and the schemas) has been moved from occuring *in the toolkit* to occuring *during deploy*.
You can continue to rely on the deployment process to ensure that the old version of the flow continues to run until the deployment is complete.
So the production change doesn't occur until the deployment is complete, as has always been true. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 29, 2013 1:18 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sealpup wrote: |
| I am happy for someone who actually knows to inform me otherwise. |
| kimbert wrote: |
| I would not advise you to continue with your present strategy. |
There you go.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Jul 29, 2013 2:26 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| sealpup wrote: |
| I am happy for someone who actually knows to inform me otherwise. |
| kimbert wrote: |
| I would not advise you to continue with your present strategy. |
There you go. |
Well, actually, kimbert is probably not an expert on the internal deployment model.
The point remains that trying to avoid using the standard deployment methods is a horrible horrible idea and will lead only to pain and confusion and uncertainty.
The point remains that the time it takes to deploy is important, but not meaningful. I.e. it's better that it takes less time to deploy than taking longer, but the length of time the deployment takes doesn't *affect* anything, other than how long you sit around waiting to be able to say the deployment occurred successfully, or didn't. |
|
| Back to top |
|
|
| sealpup |
| Posted: Tue Jul 30, 2013 5:03 am Post subject: |
|
|
Apprentice
Joined: 21 Sep 2010
Posts: 26
|
Well, we had never actually embarked on this strategy as some of you seem to think.
I was merely sounding out the feasabiity of our idea.
Thank you all for your comments which I will take cognisance of.
As ever folks, there is no need to go on the attack like a pack of wild dogs.
No doubt your mother always told you to be nice to people. Remember her wise words.
Regards,
pup |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jul 30, 2013 6:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sealpup wrote: |
| No doubt your mother always told you to be nice to people. Remember her wise words. |
I do. She taught me everything I know about sarcasm, attack strategy and the importance of the pack.
Modestly, I think I've put a lot of work into the sarcasm myself over the later years.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jul 30, 2013 7:21 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sealpup wrote: |
| No doubt your mother always told you to be nice to people. |
I'm only mean to ideas, not to people. |
|
| Back to top |
|
|
|
|
