| Author |
Message
|
| Blomman |
 Posted: Thu Sep 18, 2008 9:33 am Post subject: |
 |
|
Master
Joined: 31 Oct 2006
Posts: 230
|
Hi!
Nice input on this topic....
The load balancing im not gonna use a "gateway" qmanager or round-robin with channel table etc, i gonna use a hardware LB.
In my new WMB setup it is gonna act as an ESB, aswell its gonna handle plain messaging and even alot of file transporting and the requirement is 99.9999....% uptime(Maximum 30sec down time totaly).
My picture in my head is something like this:
(Maybe im totally lost here, need some smart answers from u experts).
Its gonna be an active/warm standby solution.
2 * WMB6.1 (One qmanager each) running on 2 * HP BladeServers with SLES10 SP2 and ServiceGuard HA.
In ServiceGuard you build your packages, im gonna have 3.
1 package including WMB1/QM1 on san discs
1 package including WMB2/QM2 on san discs
1 package including QM for configuration manager and maybe a gateway QM for some client connections that i cant consolidate now.
So even if one server goes down and the standby broker is taking over, i can start up the broker from the server that failed on the same server as standby broker that now are active.
This means that even if one server is down for repair i still can have an active/warm standby solution running(if the broker or the brokerQM goes bezerk), but just on one server.
Some questions...
How to replicate the flows? The have to be deployed on the warm standby aswell...Ok i can fix this with a script.
But more interesting, how to replicate the messages between the broker/QMs, if i cant use a MQ cluster for this...?
//Michael |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Sep 18, 2008 10:08 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can not put Network Load Balancers in between any MQ channels other than SVRCONN/CLNTCONN pairs.
It will not function. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 18, 2008 10:20 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Blomman wrote: |
But more interesting, how to replicate the messages between the broker/QMs, if i cant use a MQ cluster for this...?
//Michael |
There is no need to replicate the messages between both brokers. Why would you want to duplicate messages? Put both QMs in an MQ cluster and let MQ clustering load balance the work between both brokers.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Blomman |
| Posted: Thu Sep 18, 2008 11:18 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| mqjeff wrote: |
You can not put Network Load Balancers in between any MQ channels other than SVRCONN/CLNTCONN pairs.
It will not function. |
Im not gonna put any load balancing between im gona use it to put load on one broker at time.
//Michael |
|
| Back to top |
|
|
| Blomman |
| Posted: Thu Sep 18, 2008 11:19 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| PeterPotkay wrote: |
| Blomman wrote: |
But more interesting, how to replicate the messages between the broker/QMs, if i cant use a MQ cluster for this...?
//Michael |
There is no need to replicate the messages between both brokers. Why would you want to duplicate messages? Put both QMs in an MQ cluster and let MQ clustering load balance the work between both brokers. |
Still just want to put load on 1 broker.....Not load balance over 2 brokers.
//Michael |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Sep 18, 2008 4:15 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
So create 1 QM only with with 1 broker only, put it into the hardware cluster and use the VIP to get to it. If the cluster group fails over from Node 1 to Node 2, external apps won't care because they are accessing it via the VIP.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Blomman |
| Posted: Fri Sep 19, 2008 3:53 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| PeterPotkay wrote: |
| So create 1 QM only with with 1 broker only, put it into the hardware cluster and use the VIP to get to it. If the cluster group fails over from Node 1 to Node 2, external apps won't care because they are accessing it via the VIP. |
Ok but if i have some messages(Maybe it takes some time for them to be proccesed or something) on the broker that sever/broker that fails, what will happen with them?
Ok the will still be persistent on disc, but i want the "new" active broker to handle them so they have to be replicated somehow..
//Michael |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 19, 2008 4:43 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Please read this doc a couple more times. You did read it, right? You are failing to understand basic H.A. clustering concepts, casuing you to ask the same type of question over and over.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Blomman |
| Posted: Mon Sep 22, 2008 1:42 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| PeterPotkay wrote: |
Please read this doc a couple more times. You did read it, right? You are failing to understand basic H.A. clustering concepts, casuing you to ask the same type of question over and over. |
Yes i understand the concepts of HA...Dont understand how that should help me here.
The solution u describe with 1Broker/1QM in HA solution is to slow in case of takeover...
Im just wanna "point" the load to a new (replicated)broker/QM instantly.
//Michael |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Sep 22, 2008 5:06 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
If you want something "instantly", the closest you will get is to have 2 seperate QMs/ Brokers, each named differently, with the same queues and flows deployed (by you) in an MQ cluster. When one QM (not broker!) goes down MQ clustering will send all work to the other one "instantly".
If you have client apps connecting directly to these QM /brokers, use channel tables to make their RE-connections find the remaining QM / Broker. If you are using QM to QM channels to get to these 2 (or more) QM / Brokers, front them with a H.A. Gateway QM. But if that fails it will take a minute or 2 for IT to fail over.
You are at risk for marooned messages on either one of these QM / Brokers, which is why even if they are in an MQ cluster you should consider making them each individually hardware clustered as well. But in this design if one of the brokers goes down, the front end (hardly) notices, all new work is uninterrupted and you do not lose any committed persistent messages. Only the gateway going down will knock you out for a minute. But if all your QMs are in the same MQ cluster, you don't need a gateway QM.
Do not go down the path of trying to come up with one QM / Broker on Server 1 and somehow replicating the data to the other server and somehow instantly failing over all the connnections to the other QM / Broker and somejhow having the QM / Broker name the same after all that. You are trying to reinvent H.A. Others much smarter than you are I have already worked this problem.
If this is not fast enough, you don't want H.A. you want Fault Tolerance. (Hello mainframe?) And even there it won't help you if the data center goes down. But don't confuse DR with H.A. with Fault Tolerance. Real DR over a distance great enough to isolate against regional disasters means a period of downtime and some lost data due to asynchronous replication.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Blomman |
| Posted: Mon Sep 22, 2008 8:43 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| PeterPotkay wrote: |
If you want something "instantly", the closest you will get is to have 2 seperate QMs/ Brokers, each named differently, with the same queues and flows deployed (by you) in an MQ cluster. When one QM (not broker!) goes down MQ clustering will send all work to the other one "instantly".
If you have client apps connecting directly to these QM /brokers, use channel tables to make their RE-connections find the remaining QM / Broker. If you are using QM to QM channels to get to these 2 (or more) QM / Brokers, front them with a H.A. Gateway QM. But if that fails it will take a minute or 2 for IT to fail over.
You are at risk for marooned messages on either one of these QM / Brokers, which is why even if they are in an MQ cluster you should consider making them each individually hardware clustered as well. But in this design if one of the brokers goes down, the front end (hardly) notices, all new work is uninterrupted and you do not lose any committed persistent messages. Only the gateway going down will knock you out for a minute. But if all your QMs are in the same MQ cluster, you don't need a gateway QM.
Do not go down the path of trying to come up with one QM / Broker on Server 1 and somehow replicating the data to the other server and somehow instantly failing over all the connnections to the other QM / Broker and somejhow having the QM / Broker name the same after all that. You are trying to reinvent H.A. Others much smarter than you are I have already worked this problem.
If this is not fast enough, you don't want H.A. you want Fault Tolerance. (Hello mainframe?) And even there it won't help you if the data center goes down. But don't confuse DR with H.A. with Fault Tolerance. Real DR over a distance great enough to isolate against regional disasters means a period of downtime and some lost data due to asynchronous replication. |
Yes finally we understand each other...The mismatch in communication is probably most my fault, im not an expert on WMQ,WMB...Not yet..
Ok now we are on the "same track" and i have one question..
Is the only purpose of MQcluster loadbalancing?
If so i dont really need an MQcluster cause my HW loadbalancer will handle witch QM and broker "package" has the working role.
Have done some reading on MQcluster and cant really find any other purpose, maybe i have to read it one more time?
//Michael |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Sep 22, 2008 9:21 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| Blomman wrote: |
Is the only purpose of MQcluster loadbalancing?
Have done some reading on MQcluster and cant really find any other purpose, maybe i have to read it one more time?
|
Read it again regardless. One of the other main benefits is reduced administration - you don't have to define tons of channels and remote q defs between QMs.
| Blomman wrote: |
If so i dont really need an MQcluster cause my HW loadbalancer will handle witch QM and broker "package" has the working role.
|
The ONLY thing you can use a load balancer for as it relates to MQ is for new incoming MQ CLIENT connections to 2 or more QMs that are completely separate and named differently.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Blomman |
| Posted: Mon Sep 22, 2008 11:18 am Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
| PeterPotkay wrote: |
| Blomman wrote: |
Is the only purpose of MQcluster loadbalancing?
Have done some reading on MQcluster and cant really find any other purpose, maybe i have to read it one more time?
|
Read it again regardless. One of the other main benefits is reduced administration - you don't have to define tons of channels and remote q defs between QMs.
| Blomman wrote: |
If so i dont really need an MQcluster cause my HW loadbalancer will handle witch QM and broker "package" has the working role.
|
The ONLY thing you can use a load balancer for as it relates to MQ is for new incoming MQ CLIENT connections to 2 or more QMs that are completely separate and named differently. |
Ok ok i read it again...*pust*
But if a define an object(Q, Chl, etc..) on one QM in the MQcluster it will not be defined on the other? Dont really understand the benefits in administration.
//Michael |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Sep 22, 2008 11:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The benefits to administration are this.
If I want to add a queue manager to a cluster with 1,000 other queue managers in it, I only have to define *two* objects to create channels to all of those other queue managers - the clusrcvr and a clussdr to an FR. |
|
| Back to top |
|
|
| Blomman |
| Posted: Mon Sep 22, 2008 11:44 pm Post subject: |
|
|
Master
Joined: 31 Oct 2006
Posts: 230
|
What about queue-sharing groups?
Only supported for WMQ on z/OS?
This i think would be a real benefit of MQcluster.
//Michael |
|
| Back to top |
|
|
|
|
