| Author |
Message
|
| hooman24 |
 Posted: Thu Jun 15, 2017 4:20 am Post subject: Deploying Bar File with preserving High-Availability |
 |
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Hi There
We are going to use Broker for a high volume transaction environment( bank's card system with millions of transactions per day). Previously we have been deployed bar files online for other low volume transactions and could tolerate any possible outage.
My question is: From your experience What is the best way to deploy bar files online without any outage? |
|
| Back to top |
|
 |
| zpat |
| Posted: Thu Jun 15, 2017 4:32 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
IBM uses a "hot" deploy approach so the flow is only stopped at the end of a transaction and restarted after the deploy.
However unless every flow is independent of the others, you would normally want to stop all related flows, deploy all the new ones and then restart all related flows - probably testing before committing to production.
During this time you would redirect transactions away from the affected broker or EGs, using MQ clustering or http load-balancing technology. It would be fairly risky to deploy to a broker which is in full flow.
Most sites would choose a quieter time of day to deploy and to give time to backout if there are any problems.
_________________
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 |
|
|
| hooman24 |
| Posted: Thu Jun 15, 2017 4:56 am Post subject: |
|
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Thank you zpat for your prompt reply.
By saying "hot deploy" it means that you can deploy online without any impact? if I understand correctly broker itself will find the best time to replace previous flows with new ones. And when there are high volume messages coming maybe it will take a lot of time to find the best moment for starting the process for deployment?
For the time being, we only have one Websphere Broker on z/OS. Is it a good idea to replicate flows(deploy bar files) on several EGs and then for the future start deploying new bar files one by one separately online in quieter time? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 15, 2017 5:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Hot deploy simply means you can re-deploy a running flow. The broker will wait until the current in-flight transactions (if any) for this flow complete and then perform the deploy. It won't choose a specially quiet time.
For a high-volume, high-availability solution, you should have multiple hosts, multiple brokers, multiple EGs and some form of load-balancing.
Therefore you can use this topology to avoid the need to deploy to a running flow. I would be somewhat concerned if a bank redeployed a running flow without taking it out of service and testing it before reintroducing live traffic.
The last thing you need is a single point of failure combined with deployment whilst running a production workload (unless you wish your IT career to come to an end).
An emergency change might be made to a running flow if there was no alternative.
_________________
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 |
|
|
| hooman24 |
| Posted: Thu Jun 15, 2017 6:09 am Post subject: |
|
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
Thanks for your clarification.
"The last thing you need is a single point of failure combined with deployment whilst running a production workload (unless you wish your IT career to come to an end). "   That is a good advice.
So do you happen to know any good documentation about implementing multiple brokers and load balancer on z/OS system? |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 15, 2017 6:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Are you really running broker on z/OS? If so then money is no object 
HA is not a simple subject. With z/OS there can be a sysplex option as well allowing shared queues over LPARS.
It depends where the workload comes from, and on which protocol.
With the superior protocol (MQ) you would typically use MQ clustering to distribute the workload to different QMs (feeding different brokers).
With http traffic, you would typically use a F5 load balancer to send requests to different brokers or EGs. Coping with peak loads can be challenging as http has a habit of failing under stress.
Happy to offer consultancy at my usual rate... 
_________________
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 |
|
|
| hooman24 |
| Posted: Thu Jun 15, 2017 10:17 am Post subject: |
|
|
Apprentice
Joined: 09 Aug 2014
Posts: 25
|
| Thanks for your help and support |
|
| Back to top |
|
|
|
|
