| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| is it OK to have 2 qmgrs to be FR exclusively ? |
« View previous topic :: View next topic » |
| Author |
Message
|
| sebastia |
 Posted: Tue Sep 09, 2008 2:41 am Post subject: is it OK to have 2 qmgrs to be FR exclusively ? |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I have been told that it is very convenient
to have in our cluster
2 queue managers to be FR (full repositories) exclusively,
this is, without data queues, no channels to other managers,
no remote queues, no server connections.
They shall be ther just to be the cluster FR.
I would like to know the forum opinions.
Seb. |
|
| Back to top |
|
 |
| AkankshA |
| Posted: Tue Sep 09, 2008 2:52 am Post subject: Re: is it OK to have 2 qmgrs to be FR exclusively ? |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
| sebastia wrote: |
I have been told that it is very convenient
to have in our cluster
2 queue managers to be FR (full repositories) exclusively,
this is, without data queues, no channels to other managers,
no remote queues, no server connections.
They shall be ther just to be the cluster FR.
I would like to know the forum opinions.
Seb. |
is it really possible 
_________________
Cheers |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 09, 2008 2:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If I had a very, very big cluster, I would want my FRs on dedicated QMs on dedicated H.A. hardware since they could be very busy dealing with cluster changes.
But typically most clusters are not big enough and/or they don't have enough objects changing in them where it makes sense to spend the money on dedicated FR QMs and the associated hardware. Remember that QMs can handle incredibly large numbers of messages flowing thru them. On modern hardware the cluster admin related traffic is going to have a tough time making the QM to busy to do anything else. (Unless you have self proclaimed MQ Admins issuing REFRESH CLUSTER constantly!)
On paper it looks nice to have your FRs on dedicated QMs on seperate servers. When it comes time to pay for it, when it comes time to consider the extra servers you have to power and maintain, then dedicated FRs don't look so attractive. But theoritically its ideal.
In my clusters one of the FRs is always on the Gateway QM. The Gateway QM typically needs to know where every q in the cluster is, so why not make it a QM that knows all the facts all the time (i.e. a FR). Plus a Gateway QM, while very busy when you look at message volumes, its actually just passing all that traffic through via memory since there is no need for any message to actually stop on the QM.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Sep 09, 2008 2:56 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Maybe you could add any POSITIVE reasons you could see ..
I would say ...
(1) it is less prone to the FR to fail if they have no "data traffic" ...
(2) their names could be very indicative, as CLU1FR1 and CLU1FR2
etc
( ) |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Sep 09, 2008 3:26 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Peter - I agree on almost all that you said .... except ....
"FRs on dedicated QMs on separate servers"
I WAS NOT SAYING TO USE A SEPARATE SERVER !!!!
Seb. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 09, 2008 3:54 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
2 QMs on the same server often perform worse than a single QM doing both workloads, especially if one of the workloads is very light, like the cluster repository related work.
I would entertain the idea of dedicated FR QMs on dedicated hardware. I would strongly advise a customer against creating a second QM on an existing server just for a FR.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Sep 09, 2008 4:02 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Let's put it in a real environment : there are 10 qmgrs on this server.
Would you still say "11 qmgrs perform worse that 10" ?
I have a great advantage to separate the "data" qmgr from the "FR" qmgr :
if we need to stop the "data" qmgr (or it stops by its own ...)
then the cluster is LESS disturbed if there is another qmgr as FR
Am I right ?
Let's say we have to apply a Fix to the qmgr ...
( and we do not NEED to apply it to the FR qmgr ... )
Thanks for your opinions...
PD .- obviously, I agree the BEST is to have the "exclusive" FR
on a SEPARATE server ... but this is not always possible,
as you said. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 09, 2008 5:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
An airplane analogy: Is it better (safer, more efficient, more reliable) to have more engines? or less?
As it turns out, more engines means more (moving) parts, less reliability, and more opportunity for catastrophic failure. (The purpose of the 2nd engine on a twin-engine aircraft is to get you to the scene of the accident.)
The costs of having separate (non-application) qmgrs to be FRs doesn't seem to have an offset in benefits. What are the odds that a non-app qmgr is more or less likely to fail than a non-FR qmgr?
Clustering software doesn't impose all that much processor overhead on a qmgr. If you lose one FR, there is a brief spike in processor as the 2nd FR creates new SLUSSDR channels with the non-FRs.
If your server is nearing resource limits, it's time to upgrade the hardware whether FR or non-FR.
I'd be far more concerned with my applications and data. Why don't we just have one big server where all our apps run? (Mainframes can do this.) As a general rule, we create additional servers to offset the potential loss of all of our apps and data.
But there are good reasons why we usually don't go to the other extreme and create a server for each and every individual application. Cost. It's a balance between cost and benefit.
Paraphrasing your original question "Is it convenient?" Convenience is not a business case that I would be going to management with at budget time.
_________________
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 |
|
|
| sebastia |
| Posted: Tue Sep 09, 2008 8:09 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Bruce - your analogy drives me to the opposite conclusion,
indicating me that we both are manipulating the sample
for our own (previous) conclusions.
If I have a qmgr with 2 objectives ( moving data and being FR )
it is more probable it will fail
than if I have a qmgr dedicated to being a FR.
And I do NOT want my FR to fail. Sure.
I dont like the idea of having one big server for all apps,
and I have been working with VTAM and z/OS for few years.
I like the dynamic approaches, as Peter told before :
I understand the improvements to have a FR in the Gateway ...
and I know we have to stop a qmgr to install a FP,
and I know sometimes MQ abends ...
I like the idea of a qmgr doing almost nothing
and being a very important part of the cluster : the FR.
Again, the cost of implementing it on a specific Sever
is out of scope, at least in my customer's envir.
Thanks for your opnion(s). Seb. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 09, 2008 8:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Which is greater?
The workload saved moving the cluster responsabilities off of a QM?
-or-
The workload of adding a second QM to a server? Plus the extra monitoring required for another QM? Plus the added complexity?
I don't even want to consider your 10 to 11 QMs example! 
Again, this is another scenario where there is no 100% right or wrong answer. (Putting a second QM on an existing server just for a FR is only 99.9% wrong.  )
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Sep 09, 2008 8:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| it is more probable it will fail than if I have a qmgr dedicated to being a FR |
I don't agree with this premise.
Thre is little or nothing about being an FR that makes it more likely to fail. Recall that non-FRs are PRs, with all the same clustering software running. What's different is the slight difference in activity rate of an FR. That said, this difference will be small once PRs have discovered what they need from an FR.
| Quote: |
| I like the idea of a qmgr doing almost nothing and being a very important part of the cluster : the FR. |
The usual configuration (and IBMs recommendation) is to have two FRs that back each other up. If one fails, the other continues to provide FR services. So, I suppose, this might be the argument for non-app FR qmgrs. But we're back to the 'what are the odds?' question. Add to this: what is more likely to fail: applications, o/s, qmgr, network, other.?
| Quote: |
I dont like the idea of having one big server for all apps,
and I have been working with VTAM and z/OS for few years. |
I don't either. My point was that mainframes have dramatically higher reliability and way more horsepower (concurrency).
Further, LPARs (60 LPARs in the new z10) allow for multiple instances of z/OS (and other o/s's) in the same physical box, thus spreading the applications and data, and avoiding the single point of failure. But a single physical box becomes the single point of failure again. Two (or more) physical boxes increases cost - for many shops beyond the cost-benefit return on investment.
_________________
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 |
|
|
| sebastia |
| Posted: Tue Sep 09, 2008 9:17 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I like the point we are reaching to ... opposite ideas with a lot of arguments !
a) if I have a qmgr that has "data move" job PLUS "FR" job,
I see pretty clear it has more chances to fail that
a qmgr that has just "FR" functions ...
The problem is the data movement,
and the persistent messages going to the disk,
and the logs becoming full,
and strange RC's etc etc etc
b) where is the failure point ?
I would say first chance is network,
but it is common to "data" qmgr
and to "FR" qmgr.
Second chance to fail i'd point to OpSys and/or Qmgr,
which says "the better solution is to have 2 qmgrs",
Third I'd say "apps", in the form that makes the system fail down.
c) horsepower - I have been involved with a large MB project
based on Wintel platform
and we were surprised of the msg processing we achieved ....
and with the problems we had with a z/OS (linux)
to get similar results ...
The problem with LPARs and Z
is that you are sharing the machine with LOTS of other people
and there is no way to get 4GB of RAM - no way.
The resources at Z are so ... I dont have the english word for it...
Scarce ?
You have to "beg" for a larger CPU slice,
have to kill for some more RAM,
have to lie to increase your filesystem,
(well, nowadays the disk is quite cheap, I agree)
And it is VERY easy to get a Wintel machine
with 4GB RAM, 4 MHz CPU, 500GB Hard Disk ... just for you !
Of course, I agree, Z has a fantastic 24x7 working period,
and a "hot" plugin capability, etc etc etc
fantastic reliability,
that I cant discuss, but ...
Z is not flexible - in a single line and 1 sentence !
() |
|
| Back to top |
|
|
| sebastia |
| Posted: Tue Sep 09, 2008 9:25 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Peter :
| Quote: |
Which is greater?
The workload saved moving the cluster responsabilities off of a QM?
-or-
The workload of adding a second QM to a server? Plus the extra monitoring required for another QM? Plus the added complexity?
|
... I am old enough to be able to say
"I dont an answer to your question"
but I am able to change your question
into a more convenient (to me) :
Which is greater ?
The complexity added of having 2 qmgrs instead of one ?
or
The less cluster problems we could have when updating the qmgrs ?
I have a clear winner : 2 qmgrs is better.
I am having rude problems
with a 6 qmgr cluster
( 3 front ends thry SVRCONN and 3 qmgrs under MB flows )
when we had to go from MB 6 to 6.1,
meaning MQ 5.3 to 6.0 ...
AND I AM TRYING TO FIND A "deaf and dumb" SERVER
to be my FR .....
I know it is not cheap, but sometimes ... they can pay it !
()
PD .- I did like the discussion ... the opinion interchange,
the different point of views .. very "saludable" ... HEALTHY ! |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 09, 2008 11:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sebastia wrote: |
Peter :
| Quote: |
Which is greater?
The workload saved moving the cluster responsabilities off of a QM?
-or-
The workload of adding a second QM to a server? Plus the extra monitoring required for another QM? Plus the added complexity?
|
... I am old enough to be able to say
"I dont an answer to your question"
but I am able to change your question
into a more convenient (to me) :
Which is greater ?
The complexity added of having 2 qmgrs instead of one ?
or
The less cluster problems we could have when updating the qmgrs ?
I have a clear winner : 2 qmgrs is better.
I am having rude problems
with a 6 qmgr cluster
( 3 front ends thry SVRCONN and 3 qmgrs under MB flows )
when we had to go from MB 6 to 6.1,
meaning MQ 5.3 to 6.0 ...
AND I AM TRYING TO FIND A "deaf and dumb" SERVER
to be my FR .....
I know it is not cheap, but sometimes ... they can pay it !
()
PD .- I did like the discussion ... the opinion interchange,
the different point of views .. very "saludable" ... HEALTHY ! |
You are mistaken if you think just moving the FR to another new QM is going to help. Sorry to be so blunt. I only say this to save you the time of doing it only to find the same "rude problems".
The amount of resources required to be a FR is tiny. Really, it is. Look at the CPU and memory of the cluster repository process on a FR compared to a PR.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Sep 09, 2008 11:31 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sebastia wrote: |
I like the point we are reaching to ... opposite ideas with a lot of arguments !
a) if I have a qmgr that has "data move" job PLUS "FR" job,
I see pretty clear it has more chances to fail that
a qmgr that has just "FR" functions ...
The problem is the data movement,
and the persistent messages going to the disk,
and the logs becoming full,
and strange RC's etc etc etc
|
I see your point here. So that's why you have 2 FRs. And if that still does not provide enough protection, going to a dedicated FR QM on a seperate server makes sense. Seperate server because (using your logic above) 2 QMs on one server can take each other out, right?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
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
|
|
|
|
