| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Maintaining a QA / Test environment Clustered QMGRs |
« View previous topic :: View next topic » |
| Author |
Message
|
| Boomn4x4 |
 Posted: Mon Feb 11, 2013 5:34 am Post subject: Maintaining a QA / Test environment Clustered QMGRs |
 |
|
Disciple
Joined: 28 Nov 2011
Posts: 172
|
I'm looking for some advice as to how to setup a QA / Test environment with multiple queue managers in a clustered environment.
That primary challenge I am running into is that these systems are often pumped from a gold drive. Currently the procedure is to pump a system with a generic image, then run a script to configure each individual system. The problem, however, is that in doing so, dead qmgrs are being left as members of the cluster which causes. This wouldn't be so much of a problem if the same team that owned the test systems also owned MQ, but they don't. This presents a challenge that any time a system needs to be pumped, it needs to be coordinated with the MQ admins to properly remove the qmgr from the cluster before pumping it. Or, at the very least, they need to watch the test cluster and manually forceremove everytime this is done.
It wouldn't be unheard of to pump a system close to a dozen times in a week, and there are 16 test systems. As you can see, this can lead to a maintenance nightmare.
Has anyone found and good ways to go about achieving this?
Does anyone have any advice as to a good way |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Feb 11, 2013 6:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Pumped? Gold drive?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 11, 2013 6:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Pumped? Gold drive? |
I would imagine the OP means they have a gold build, a "gold standard" from which all of the queue managers are built (or pumped) to ensure consistency.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 11, 2013 6:33 am Post subject: Re: Maintaining a QA / Test environment Clustered QMGRs |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Boomn4x4 wrote: |
Has anyone found and good ways to go about achieving this?
Does anyone have any advice as to a good way |
Yes to both, and it involves proper control and coordination. The gold build script needs to properly handle the situation and not leave dead queue managers. There are a number of ways to handle this depending on where you want to put the effort, and which challenges you want to overcome.
There's no silver bullet for this, but the principle you're describing works well once you've got it working.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 11, 2013 8:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have the gold drive contain empty qmgrs and the scripts to populate them. This way you rebuild the cluster from scratch every time you "pump" the environment... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Tue Feb 12, 2013 6:38 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
What is the goal of your QA environment? Are you regression testing your application or regression testing the QMGR product or regression testing your configuration scripts?
Most QA environments, except performance testing environments, do not typically have all the things the prod environment does. Therefore, one could question the need to cluster things together. A put is a put is a put whether that put writes a message to a queue on a local qmgr or a cluster. Either the put is successful or it is not. Having a clustered configuration in a QA environment may not be needful if your interest is testing strictly the application.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 12, 2013 6:50 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Testing in PROD is a no-no.
I believe that the objective of QA is to validate any and all changes planned for PROD before they made to PROD.
So, if QA is pre-PROD, QA needs to be PROD minus production data. This encompasses apps, qmgrs, databases, security, backup/recovery - whatever is bound for PROD.
So, if there's a cluster in PROD, it should also be present in QA.
Yep, all this takes planning, work, coordination, testing. In the long-run, it is best-practice.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Feb 12, 2013 7:14 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| lancelotlinc wrote: |
| What is the goal of your QA environment? Are you regression testing your application or regression testing the QMGR product or regression testing your configuration scripts? |
Typically all 3. Testing all 3 at the same time less typically and linked to the maturity of your testing processes (CI).
| lancelotlinc wrote: |
| Most QA environments, except performance testing environments, do not typically have all the things the prod environment does. |
My experience is that the configuration is identical (see above re: testing configuration scripts) but are lighter on resource.
| lancelotlinc wrote: |
| Therefore, one could question the need to cluster things together. A put is a put is a put whether that put writes a message to a queue on a local qmgr or a cluster. Either the put is successful or it is not. Having a clustered configuration in a QA environment may not be needful if your interest is testing strictly the application. |
A put is a put is a put. A put as part of a request / reply is different to when the put and it's corresponding reply has to traverse a cluster. One of those instances where testing the application (which is simply doing a put & doesn't care after than provided the matching get wokrs) is bound up with testing the configuration (which will hose up the application if not set).
Of course if the application is using an existing cluster down to the point where the queues are already in use for other purposes, this descreases the testing dependency. It could also be argued that if the cluster exists & works, just adding new queues doesn't need to be tested if you're confident from a desk check the cluster attributes are set.
You pay your money, you take your choice and if the whole of QA rebuilds itself cluster and all, builds the production software and application stack then runs a series of regression tests through JUnit at the push of a single button then you test everything everytime. If it's 3 man days of effort just to stand the environment up, less so.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Feb 12, 2013 7:38 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
When a change to PROD takes place, and the change fails for whatever reason, the first thing out of the mouths of everyone should be: "did this pass QA?"
Any answer other than 'yes' indicates that we failed in our primary mission - change control.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| exerk |
| Posted: Tue Feb 12, 2013 8:20 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
When a change to PROD takes place, and the change fails for whatever reason, the first thing out of the mouths of everyone should be: "did this pass QA?"
Any answer other than 'yes' indicates that we failed in our primary mission - change control. |
What about those times it works in QA but doesn't in PROD? 
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Feb 12, 2013 8:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| exerk wrote: |
| What about those times it works in QA but doesn't in PROD? |
That's the fun part of this career, and why we get paid the big bucks.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
