| |
|
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
|
| fjb_saper |
 Posted: Tue Sep 09, 2008 7:39 pm Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
| PeterPotkay wrote: |
| 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?  |
Let's be VERY clear. He is not talking about 2 qmgrs under zOS but under zLinux on a system that is potentially already strapped for resources. And comparing to 2 machines under windows @ $4 to 10K budget per machine ?? I would say forget windows and run Linux on your Windows machines and run the FR qmgrs there....
Of course you loose the advantage of VERY VERY fast in memory TCP (Hypersockets) but this might no longer matter if your zLinux env is already strapped for resources...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| sebastia |
| Posted: Tue Sep 09, 2008 11:05 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Saper - very interesting lines you have written !
mr Peter - yes, I want a very quiet life to my FR, and I am ready to spent
some time on it ... I realy dont like problems with the cluster ...
( )
Thanks a lot. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 10, 2008 5:49 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Let's be VERY clear. He is not talking about 2 qmgrs under zOS but under zLinux on a system that is potentially already strapped for resources. |
Did I miss this point in the post?
Mainframes are the platform of choice when the business requirement is extremely high reliability, scalability, concurrency, etc..
Moving a qmgr and/or applications off the m/f to conserve limited m/f resources doesn't make business sense. There's a reason midrange servers are inexpensive.
| Quote: |
| 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 |
Data moves, persistent messages go to disk (if not immediately consumed), logs become full. These are expected behaviors on all MQ platforms - these are not problems. Sysadmins need to manage these.
Strange RCs? This might be qmgrs or o/s in need of software upgrade, or applications poorly written. I don't imagine these will disappear by changing platforms.
In any case, these sound to me like vague complaints, looking for some justification for changing platforms or adding server hardware without any real analysis and business plan in place.
If your objective is to harden (make more reliable) you environment, adding two more servers, two more network connections, two more o/s's, will only be a marginal (very small) improvement - if any.
If your objective is to improve qmgr or server performance/throughput by separating FRs from other activity, upgrade the server hardware (more cpus, RAM, faster disk).
If your objective is to separate your applications from MQ clustering software, don't use MQ clusters. In most cases, the benefit of clustering outweighs the so-called cost (overhead).
In my role as tech manager, I required sys admins to present a business case for changing whatever he/she wanted to change. The business case had to include:
. the problem (perceived or real)
. what you have done so far to correct/improve the problem (perceived or real)
. what you propose to do to correct/improve the problem ...
. what are the risks of not changing
. what are the benefits of changing
. what are the costs (hardware, software, outages)
. what is the fall-back plan (if it doesn't work)
. what is the fall-forward plan (to implement the change)
. what will you measure to prove that the costs were justified, that the benefits were achieved
_________________
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: Wed Sep 10, 2008 8:43 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Yes, Bruce - those are reasons to choose mainframes.
But we also know MQ under z/OS is VERY expensive
and MQ under zLinux is not so expensive.
Do we agree until here ?
And we also know that when you ask for a new LPAR at Z
you will be given a fraction of the CPU you required
and a fraction of the RAM you requested
because the customer has "other" requirements
and the availability is ... what it is.
Lately I find disk/filesystem is not a problem anymore ...
Now, going to zLinux,
customer bought some "Linux" specific CPU hardware,
I bet you know the name of it ...
But there are "only" 3 of those CPU's,
and we need 5 LPAR's,
so negotiation is always to get less that you need / requested ...
Our objective is to harden the cluster.
mr Bruce - you dont have this item in your (nice) list.
There has to be a cluster. No question. Full stop.
If a "data" qmgrs makes the FR qmgr to stop working,
I shall try to fix that. How ?
Moving the FR to another server.
Too expensive ?
What is the price of a weekend with (heavy) cluster problems ?
Enjoy. Seb. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 10, 2008 9:14 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| If a "data" qmgrs makes the FR qmgr to stop working, I shall try to fix that. How ? |
Problem determination is substantially the same on all MQ platforms, and problems have symptoms:
. what symptom(s) do you see? "stopped working" is too vague for anyone to help you.
. what error messages appear in the error logs? Look the error messages up in the WMQ Messages manual. What do the error messages tell you to do? Did you do what the messages say to do?
. are you at a current WMQ service level?
. have you researched the ibm support website? What did you find?
. did you open a PMR with IBM? What did they say?
Yes, z/OS and WMQ for z/OS cost more. zLinux is an option - a choice.
IFLs are assist processors, and not mandatory. If an IFL is not available, a regular cp will be used. IFLs are managed by PR/SM in logical partition with dedicated or shared processors CPs. So, it seems that your shop doesn't need 5 IFLs to run 5 zLinux LPARs.
Other z/ assist processors for DB2 and Java workloads dramatically reduce the cost of processing.)
The amount of virtual storage (RAM isn't a mainframe term) allocated to an LPAR is not real - it's virtual. Insufficient virtual storage will result in increased paging rates - and perhaps reduced throughput.
Your lament about not being given sufficient resources in an LPAR is a political issue, not a technical one. You should address this to your management.
_________________
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: Wed Sep 10, 2008 9:34 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
mr Bruce - "the same on all platforms" I can't agree.
There are "cluster" views you have in z/OS you do not have
on distributed platforms ...
Have you tried to use MQ Explorer is a medium size cluster
with FR problems ?
There is NO WAY to answer any of your questions ...
"stopped working" means you want to remove a qmgr from the cluster,
issued a "SUSPEND CLUSTER" but it is still visible to FR.
You try to stop the cluster channels, but they do not stop.
You look in the amqerr01.log and there is NOTHING there ...
You REFRESH all you can, but still channels are running.
Service level ? You have to be desperate to ask this if you are 6.0.2.3
PMR ? you gotta be joking
"political" or "technical" issue ? It says no difference to me.
It is an ISSUE, without adjectives.
They provide me a machine
(virtual storage or RAM doesn't make any difference)
and the cluster is driving me crazy.
No chances for a bussiness case : that is the customer's engineer job.
I am the one they call. I have to provide a solution.
Thanks for you time and patience. Seb. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 10, 2008 10:09 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sebastia wrote: |
Have you tried to use MQ Explorer is a medium size cluster
with FR problems ?
|
Yes, and I never did again!!!
Use runmqsc and/or MO71 for any and all cluster work.
Unless the o/s is so unstable that it is taking out both of your FR QMs at the same time, moving the FR QM to another o/s will solve nothing. But that's the 1st rule in planning a cluster - out your FRs on the most stable platforms you have. A desktop PC can be more stable than a z/OS box admined by clueless people.
I think Bruce will agree with me here: You are trying to solve the symptom instead of going after the root cause. I sympathize - if the O/S you have for the FR is flaking out and you can't do anything about it, get off it. However, I suspect, when you finally find the root cause, your cluster problems are not caused by the FR sharing the same QM as a "data QM".
And yes, sharing a QM for multipel things does introduce risk. Nothing is 100% isolated. But do you go and put one app and one queue on one QM on one server? Nope, we all decide how shared we want the environment to be and accept the low risk of a problem in the interst of saving soft and hard costs. To that end, it is a very very very low risk to have your FR share the same QM as an app. If you have a blank check book and lots of support people and unlimited rack space and power in your datacenter more power to you. Like I said, theoretically if you want to be ultra safe (paranoid?) keep the FRs on seperate QMs on seperate servers. Its not worth it usually.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Sep 10, 2008 10:40 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
I'll restate:
Problem determination is substantially the same on all platforms:
Observe. Document. Analyze. Plan. Do. Repeat.
The tools available may be different. Different o/s's have different commands. You may or may not have Omegamon or some similar tool on all platforms. MQSC is available on all platforms.
The z/platform, z/OS and zLinux, z/VM, are robust and stable. I doubt your grief is from these. I'm not sure what quality of support you get from your systems programmers. Poor, I'd guess.
WMQ clusters have a reputation for working wonderfully OR failing miserably. Most failures, in my experience, come from failure of sysadmins to understand how clusters and cluster commands work. The WMQ Clusters manual is a great resource. The section on advanced tasks itemizes the steps required to remove a qmgr from a cluster. It works.
Like most sysadmins, I gather that you are impatient, that you want things to work perfectly right now. This is an unrealistic expectation. Things go wrong. You will need to do problem determination to resolve problems. You will need to make use of the three primary sources of help:
1. read manuals.
2. ask someone who knows more than you (like mqseries.net)
3. contact the vendor.
If you haven't done so, take a WMQ System Admin course. IBM offers 3-day hands-on for WMQ on Windows (WM151) and AIX (WM152) and SUN (WM155). WM152 would be good for Linux sysadmins. IBM also has a 4-day for WMQ for z/OS. There are advanced system admin courses, as well. These include more problem determination exercises.
IBM has a 3-day Architecting WMQ Clusters class (MQ250).
In summary, we can't help you if you won't help yourself.
_________________
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: Wed Sep 10, 2008 1:59 pm Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
Ok, Peter; Ok Bruce.
I have taken a deep breath,
I have read your notes not two times but three,
and I admit I have no more arguments to put on the table.
Even I have to say I do not agree you have the same tools
when working with a cluster that when working distributed ...
Even I have to say I dont agree I did not help myself ...
Even I have to say I am not chasing a symptom ...
I know the root cause of my problems :
a brand new Solaris has been incorporated into our cluster.
But I cant proove it's its falut. No way I can do that.
RUNMQSC is ok, the one and only.
I have never never seen any use out of Omegamon,
maybe I have to search for a guru. Completely useless tool.
Never used MO71 - instaled on my PC, saw it run,
but no special commands out of it.
Instead, I have been shown MQ at z/OS has special (unique)
output of a "DISPLAY CLUSQMGR" command -
you can see some qmgr marked as "suspended",
gone temporarily out of the cluster,
without its manager knowing it !
Channel problem, TCP/IP problem. Easy now.
Thas is the tool I need instead of MQ Explorer !
I just cant agree reading more manuals will help me in my job.
I better shut up my mouth now.
Thanks you both for you time and patience.
Really appreciated it.
Even sometimes I have some problems with your/my english ()
Seb. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Sep 10, 2008 6:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
MO71 is a lot more powerful than you realize. Install it, play with it, read the manual cover to cover. Yes, take an hour, shut off email and read that manual cover to cover and it will save you dozens and dozens of hours every year as an MQAdmin. Trust me.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 10, 2008 9:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20757
Location: LI,NY
|
And as a companion to MO71 use MO72 (the client form of mqsc).
And like Peter said, to work with clusters, I only use runmqsc, mo71 and mo72. The responses given by most other tools (MQExplorer) need you to have a very solid understanding of the cluster and the problem to be able to interpret them correctly and link them back to the cause. I find it distracting and counter productive, compared to the use of runmqsc or mo72 when dealing with cluster problems....
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 11, 2008 6:13 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I just cant agree reading more manuals will help me in my job. |
If you won't read manuals and you don't want (refuse) to do research or problem determination, how do you expect to become proficient?
Are you one of those techies that only does trial-and-error - playing, guessing, complaining, and hoping that somehow, magically, all will get better?
_________________
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 |
|
|
| sami.stormrage |
| Posted: Sun Sep 14, 2008 11:01 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
| Quote: |
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. |
Well thats what u have to have, if you are developing a clustered network for a Bank. Except for one phrase "no channels" rest of it is true. I have worked in a similar setup.
_________________
*forgetting everything  * |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Sep 15, 2008 12:31 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sami.stormrage wrote: |
| ...Well thats what u have to have, if you are developing a clustered network for a Bank... |
Why? I've worked in a couple and not seen that documented as an architectural requirement.
The only place I've been in where it would have made sense was a big telco that insisted on using clustering to isolate applications, due to which it was not unusual to find any given queue manager in 10+ clusters, as an FR for some and PR in others, with just about everything namelisted, then find in that confusion that people had defined explicit CLUSSDR's from FR's to PR's with the consequences thereof (don't even think to ask about how it was documented!). Having separate FR's would have removed that misconfiguration issue, but would have been the only benefit in my point of view.
_________________
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 |
|
|
| sami.stormrage |
| Posted: Mon Sep 15, 2008 7:33 am Post subject: |
|
|
Disciple
Joined: 25 Jun 2008
Posts: 186
Location: Bangalore/Singapore
|
| Quote: |
| due to which it was not unusual to find any given queue manager in 10+ clusters |
Yes, with such huge nuber of clusters and coupled with large number of Qmgrs do create a issue when ever there is a cluster refresh. Thats why people had foreseen this issue and separated everything at the first place. Exception being that, some new comers would create a Q on the FR, eventhough clustering manual clearly says that, u only need to have a sender and receiver to the FR and the Qmgrs would be able to communicate freely.
I din't get ur point, actually, you are contradicting and supporting my previous statement both at the same time. 
_________________
*forgetting everything * |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
