| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Full Repository Placement |
« View previous topic :: View next topic » |
| Author |
Message
|
| Paul Mark |
 Posted: Fri Dec 23, 2005 4:20 am Post subject: Full Repository Placement |
 |
|
Newbie
Joined: 23 Dec 2005
Posts: 5
|
Is it a best practice to have two dedicated servers (machines) to host our 2 full repository queue managers? In other words, in a large MQ configuration, should we have dedicated servers for the full cluster repository queue managers with no messages passing through those QMs other than repository sync messages?
How much load does a full repository create on a server machine? What factors impact the load created by the full repositories. What are the impacts if the full repository server machines get overloaded?
Sorry for the nested questions but they are all about the same theme.
It would be appriciated if someone can point out to an article on this subject.
We expect to add 10-20 QM every year over the next 5 years. We are starting with about 8 QMs.
Thanks |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Dec 23, 2005 4:23 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There's no reason, for the most part, to create a dedicated repository queue manager - much less two.
The work of being a FR is not a significant impact on the performance of the qm for other purposes.
You should focus on making your FR's "highly available". This doesn't necessarily mean failover - it just means that they shouldn't be down for too long and they should be easily accessible from any qm in the cluster.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Paul Mark |
| Posted: Fri Dec 23, 2005 6:03 am Post subject: |
|
|
Newbie
Joined: 23 Dec 2005
Posts: 5
|
What about the case when we could have hundreds (say 800) of Queue Managers and if we have extensive load on the servers where the full repositories exist? (Extensive load means 85% utilization).
How much additional load will a full repository have on a server? We maybe running the WSBI Broker on those servers, would that cause a problem due to heavy load?
I am just trying to validate conflicting views on this matter.
Thanks a lot. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 23, 2005 6:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I seem to remember some extensive discussion of this previously - a search might be helpful.
FRs really only do work when a) the cluster changes, and b) a queue is opened on a PR that the PR does not have cached - and maybe a couple of other cases, but it's not extensive.
There should also be some discussion in the Clusters manual.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Paul Mark |
| Posted: Fri Dec 23, 2005 6:19 am Post subject: |
|
|
Newbie
Joined: 23 Dec 2005
Posts: 5
|
What if we start without a dedicated server for the FR, would it be a relatively simple task to move the full repositories to a QMs on a dedicated machines, if this ever because an issue for some reason?
(can you point to the dicussion thread on this subject (other than this one:) - I searched all day Yesterday but could not find it) |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Fri Dec 23, 2005 6:46 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
so after 5 years you will end up with 50 to 100 queuemanagers in the cluster, now what are you trying to archive? save 2 of them, but end up with sleepless nights?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Dec 23, 2005 6:49 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| Paul Mark |
| Posted: Fri Dec 23, 2005 7:32 am Post subject: |
|
|
Newbie
Joined: 23 Dec 2005
Posts: 5
|
| Mr Butcher wrote: |
| so after 5 years you will end up with 50 to 100 queuemanagers in the cluster, now what are you trying to archive? save 2 of them, but end up with sleepless nights? |
We could end up with much higher count (say 800+). Would you under any circumstances put the full cluster repository QMs on dedicated servers without routing application messages through them? That is really the question. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Dec 23, 2005 11:52 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Paul,
The question of dedicated FR QMs has been discussed at previous MQ Tech Conferances.
One good point brought up for having dedicated QMs for FRs is related to the subject of Max Channels. Assume for a moment that your FR QM also handles applicatio queues as well, and perhaps has direct client connections on top of that. It is possible that your SVRCONN channels in combinatio of your CLUSRCVRs and CLUSSNDRs may have you max out on channels, at the exact point that the FR needs a channel to start up to publish some info to a QM in the cluster. Clearly not good.
Having said that, what are the odds that your QM that is your FR will hit max channels? If it is slim to none, than this is not reeeeally a worry.
As to the question of overhead of being a FR, I say don't worry about it. The only time a FR is going to doi any work of consequence is when a new QM joins the cluster, or you issue REFRESH CLUSTER somewhere in the cluster. In my shop, we don't do those things unless its off hours or an emergency. Go look at the Repository Manager exe on an established FR, and you will see it is doing almost nothing as far as consuming resources are concerned.
I think it is much more important that you place your FRs on servers that are going to be the most highly available, regardless of whether they have other work going on or not (the max channels issue being respected however).
In my cluster, I have the gateway QM a FR, and one of my WB-IMB Brokers a FR, and things are hunky-dory for the past few years.
800 QMs in a cluster is not that huge of a cluster. There is a support pack out there that is specifically on tuning large clusters, check it out, good reading. In IBM's tests, they had to cap the cluster at a certain # of QMs not because of clustering limitations, but good ol' Max Channels. The FRs just couldn't maintain thousands and thousands of concurrent channels to and from all the cluster members.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Paul Mark |
| Posted: Sat Dec 24, 2005 3:38 am Post subject: |
|
|
Newbie
Joined: 23 Dec 2005
Posts: 5
|
PeterPotkay,
Great info. Notice that I was proposing not only having two dedicated FR QMs, I was also proposing putting them on their own two dedicated hardware. Would the channel limitation, although rare to reach, be resolved by simply creating dedicated Queue Managers as FRs (on two deparate but NOT dedicated machines)? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Dec 26, 2005 11:52 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Paul Mark wrote: |
| Would the channel limitation, although rare to reach, be resolved by simply creating dedicated Queue Managers as FRs (on two deparate but NOT dedicated machines)? |
Well, yes. If you have a pair of servers that together constitue a hardware cluster, and you have QM1 as a resource on this hardware cluster, QM1 is extremely available. It is thus a good candidate for being a FR.
But if QM1 might possibly have thousand of clients connected to it, then I would worry about it being able to perform its FR tasks 100% of the time. In this scenario, it would be prudent to create QM2 on this hardware cluster, make sure QM2 is highly available as well, and do not let any clients (of any substantial # any way) connect to it. But, now yopu got 2 QMs running on the same server, and competing for the same CPU and I/O. I suppose you could alleviate this by running the hardware cluster as Active/Active, where QM1 runs on Node1, and QM2 runs on Node2. Just know that performance may be compromised when you have a failover scenario and both QMs are on the same node.
But if QM1 does not have lots of clients sucking up valuable Active Channel instances, then don't worry about QM1 being a FR, even if QM1 happens to host lots of application queues. There just isn't enough overhead while an FR does its FR things to justify the cost and added complexity of another QM dedicated solely to being an FR.
Perhaps with a blank check and the need to design a system that performs at its absolute peak all the time, maybe I might give a FR its own QM. But in the real world, its most important that you have 2 FRs, both highly available, both not vulnerable to Max Channels being reached, and be done with it. There are more important things to worry about I'm sure....
Note that I specifically choose my Gateway QM to be a FR, even though (and specifically because!) it handles every message in the cluster. In my shop, no work originates in the cluster. All transactions start and end outside the cluster, so all app messages pass thru that 1 GW QM. As we are adding new queues in the cluster for new services, I did not want the GW QM to have to pause and query the remote FRs for info on new clustered queues as they became available. Rather, I have the GW QM be a FR itself, that way it instantly knows about all queues all the time.
Back when I had the GW QM be a PR, we would occasionally get messages tossed in the GW's DLQ with a 2189 MQRC. Replaying the message always worked. It seemed that the GW sometimes would not get a response fast enough from the FRs, and would DLQ the message. By the time I came around to replay the message, the subscription info had arrived, and replaying the message from the DLQ worked. Since making the GW a FR, this problem has never shown itself again.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| 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
|
|
|
|
