Re: Cluster question;

Re: Cluster question;

Re: Help!

Re: MQ v6 z/os remote administration of MQ v5.3 distributed

Re: Cluster size

Bridgette
Thank you so much - will monitor for that as well.

Francois van der Merwe
Senior IT specialist, WMQ certified
IBM, Cape Town, South Africa
+27(0)21 402 5597 or +27(0)82 556 9467
Be an oceans Defender - oceans.greenpeace.org

                                                                           
             "Beardsley,                                                   
             Bridgette"                                                    
             <Bridgette.Beards                                          To 
             ley@...>              
MQSERIES@...  
             Sent by: MQSeries                                          cc 
             List                                                          
             <MQSERIES <at> LISTSER                                     Subject 
             V.MEDUNIWIEN.AC.A         Re: Cluster size                    
             T>                                                            

                                                                           
             31/10/2006 20:01                                              

                                                                           
             Please respond to                                             
               MQSeries List                                               
             <MQSERIES <at> LISTSER                                             
             V.MEDUNIWIEN.AC.A                                             
                    T>                                                     

Francois,

I've had 1200+ queue managers in a cluster, and it had it's +'s and -'s.
Overall it was good architecture that served its purpose.  We used two
separate servers for the full repositories, configured for failover.
Although we never had a production issue which forced a failover, we did
find that the full repositories were not in synch, in other words,
clustered queue managers and objects were in one full repos and not
another.  Cluster refreshes did not correct the issue and in an
environment that large, the refreshes were lengthy and heavily loaded
the cluster.  The issue turned out to be the cluster repository process,
amqrrmfa, had died on partial repository queue managers, disallowing a
response to the refresh cluster command.  So, my advise would be to stay
close to the latest patch (issue was at MQ 5.3), and proactively monitor
your environment.

2nd question.  Just try to plan for average and peak volumes, and
connection frequencies.  You'll probably find that you have to tune
these as you add in queue managers.

-Bridgette Beardsley

-----Original Message-----
From: MQSeries List
[mailto:MQSERIES@...] On
Behalf Of Francois Van der Merwe1
Sent: Tuesday, October 24, 2006 2:34 AM
To: MQSERIES@...
Subject: Cluster size

I plan to add 650 MQ servers to the same MQ cluster ..... is this good
or
not?

Anybody with some experience in big clusters?

Also, how do I calculate resources needed on the two PR queue managers.

Thanks

Francois van der Merwe
Senior IT specialist, WMQ certified
IBM, Cape Town, South Africa
+27(0)21 402 5597 or +27(0)82 556 9467
Be an oceans Defender - oceans.greenpeace.org

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Re: CF Recovery in a QSG Environment

Re: Cluster question;

Neil,

First let me state that I always recommend no more then two full 
repositories unless there is a good business reason to have more such as 
having one or two on each of three continents.  So I agree with most of 
what you said below.  However I've worked with many clusters in which 
we've had more than one FR down and the cluster remained healthy.  The key 
is in defining one and only one explicit CLUSSDR channel to a repository 
and making sure the FRs are set up to properly distribute that 
information.

If the PR cluster members have only one explicit CLUSSDR they will attempt 
to publish cluster activity on that channel as you say.  Publications to 
the secondary FRs are based on cluster workload balancing so if you have 
more than one possible destination the routing is resolved dynamically. If 
two of three FRs are down, the third one should get the publication.  The 
most frequent problem I see in this regard is that there is more than one 
explicit CLUSSDR defined.  If there are three explicit CLUSSDR channels in 
the example above, the QMgr would publish on only two regardless of which 
FRs were available.  Not sure how it determines which two but for the sake 
of this example let's assume they are the two with the earliest definition 
date and time.  If the latest FR is available and the earliest two are 
not, the publications will queue up for the two downed FRs, assuming all 
have an explicit CLUSSDR.

The next step is to make sure that your repositories ALSO will publish 
successfully to one another.  Repository publications also prefer explicit 
CLUSSDR channels and also will send a duplicate publication.  The trick is 
to design a publication topology that insures all repositories are updated 
and again the most common mistake is to define too many explicit CLUSSDR 
channels.  Frequently I see  where a client has defined an explicit 
channel pair between every possible repository.  This locks each FR into a 
specific two publication destinations and if both are down the 
publications are queued up.  The preferred solution is to define only one 
explicit CLUSSDR on a FR to another FR and to join groups of three or more 
in a specific topology that routes messages around the cluster.  For 
example, a topology that works well with three FRs is to arrange them in a 
triangle with an explicit channel on each leg.  So FR1 points to FR2 
points to FR3 points to FR1.  In the example with two FRs on each 
continent, each FR points to its mate on that continent to insure 
publications prefer a local destination first and then look to publish to 
a remote destination second.

If the explicit CLUSSDRs are defined with care, I have had no problems 
with topologies supporting more than two FRs.  But again, I don't 
recommend it without a valid reason.

One final note - ALWAYS host your FR on a dedicated QMgr which does not 
also host application queues.  There are a couple of reasons for this:

1) You want to be able to take the FR down and apply maintenance to it 
without having to get on some application's release schedule.  If there is 
a problem with clustering that IBM releases a fix for, in theory you 
should be able to apply it during the day with no downtime by taking down 
one FR at a time.  You are limited here only by your change control 
procedures IF there is no application on the same QMgr.

2) If you are troubleshooting a cluster problem on an application node, 
you may need to issue a REFRESH CLUSTER command to pick up a new or 
missing queue definition.  If you are troubleshooting on a FR you might 
want to issue a RESET CLUSTER command to drop and rejoin a PR.  These 
commands are, in practice, mutually exclusive.  If you issue the REFRESH 
on a FR, you may generate a LOT of cluster traffic and find this 
disruptive to the cluster but if you host an app on an FR you may have no 
choice.  If you are trying to synch up a couple of repositories and issue 
a RESET, your app hosted on the same FR QMgr may lose visibility to 
cluster queues.

-- T.Rob

T.Robert Wyatt, Consulting IT Specialist 
IBM Software Services for Websphere
email: t.rob.wyatt@...
704-719-2107 Access Line

MQSeries List <MQSERIES@...> wrote on
10/31/2006 
04:05:16 PM:

> 
> Hi Douglas, 
> 
> I would recommend that the new machines are defined as partial 
repositories. 
> 
> The manuals show that more than 2 full repositories are supported, 
> and it always sounds like a good idea. However, in my experience the
> actual implementation of repository update strategies by the MQ 
> software means that having more than 2 full repositories doesn't 
> really help, and can make MQ behave in unexpected ways. 
> 
> The core of the issue is that when a queue manager sends a 
> repository update or inquiry, it sends it to exactly 2 full 
> repositories. It will always send it to the FR for which there is a 
> static sender channel defined, and it will send to 1 other, 
> determined in some way by the software. 
> 
> The problem comes when FRs are down (either planned or unplanned). 
> One might expect (I certainly did) that as long as at least 1 FR is 
> up, your cluster should be healthy. Unfortunately, the repos update 
> strategy means that if you have say 3 FRs, and the 2 which your PR 
> sends updates to are down, then no updates or requests from that PR 
> can be handled. This leads to things like issuing a suspend command,
> which gets processed, but the FR and the rest of the cluster don't 
> get to see it unless one of the 2 update FRs are up. Messages keep 
> arriving at the 'suspended' queue manager. 
> 
> So, the bottom line is that no matter how many FRs are in your 
> cluster, the cluster is not healthy unless a maximum of 1 FR is 
> unavailable. Statistical analysis shows that the more FRs there are,
> the more likely it is that more than one will be unavailable, and 
> therefore the more likely it is that your cluster could have a problem. 
> 
> So my belief is that 2 FRs is a special number which is always the 
> right number to use. 
> 
> FRs and PR which host application queues participate equally in load
> balancing, although messages will not leave a queue manager which 
> hosts a target queue unless you are running version 6, where there 
> is an option available to load balance away from the current 
> machine. At v5, if one of the target queues in the cluster is on the
> current queue manager, the messages will always go there. 
> 
> My last piece of advice on clusters is that if you have a 
> requirement for timely performance in a request/response model, with
> messages flowing via a cluster, don't put the FRs on a queue manager
> which has application queues. Use dedicated queue managers (even if 
> you run them on the same machines). I am chasing some performance 
> issues at my site where messages get delayed when the FR amqrrmfa 
> process gets busy managing  cluster stuff, and it stops responding 
> to application requests in a timely manner.
> 
> Regards, 
> 
> Neil Casey 
> Lead Technical Specialist, Middleware MQ Support 
> Technology Operations 
> National Australia Bank 
> 
> Level 1, 122 Lewis Rd  (Tue Thu) 
> Tel: +61 (0) 3 9886 2375  |  Fax: +61 (0) 3 9886 2700  |  Mob: +61 
> (0) 408 356 208 
> Pier 4, Level 8, 800 Bourke St  (Mon Wed Fri) 
> Tel: +61 (0) 3 8634 2205  |  Fax: +61 (0) 3 8634 3788  |  Mob: +61 
> (0) 408 356 208 
> Email: Neil.Casey@...
> 
> 
> 
> 

> 
> "Clark, Douglas" <dclark@...> 
> Sent by: MQSeries List
<MQSERIES@...> 
> 01/11/2006 07:08 
> 
> Please respond to
> MQSeries List <MQSERIES@...>
> 
> To
> 
> MQSERIES@... 
> 
> cc
> 
> Subject
> 
> Re: Cluster question;
> 
> 
> 
> 
> Due to significant increase in the number of messages we will process
> for Christmas I have to prepare for the addition of machines to my
> current environment.
> 
> Currently, I have four client machines and four queue managers (WC1,
> WC2, WC3, WC4) sending data to a clustered queue (PROD_Q1) defined on
> two server machines with queue managers WS1 and WS2 each hosting a full
> repositories.
> 
> I am planning to add four more client machines and queue managers (WC5,
> WC6, WC7, WC8) as well as two more server machines and queue managers
> (WS3 and WS4).
> 
> The queue managers WS3 and WS4 will also have defined the same clustered
> queue (PROD_Q1) and must be able to receive data from all eight client
> machines (the original 4 and the 4 new servers recently added).
> 
> Should I make queue managers WS3 and WS4 full repositories or just
> partial repositories.  Will the PROD_Q1 on the two new server machines
> participate equally in the load balancing done for WS1 and WS2.
> 
> To unsubscribe, write to
LISTSERV@... and,
> in the message body (not the subject), write: SIGNOFF MQSERIES
> Instructions for managing your mailing list subscription are provided in
> the Listserv General Users Guide available at http://www.lsoft.com
> Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

> 
> National Australia Bank Ltd - ABN 12 004 044 937
> This email may contain confidential information. If you are not the 
> intended recipient, please immediately notify us at postmaster <at> nab.
> com.au or by replying to the sender, and then destroy all copies of 
> this email. Except where this email indicates otherwise, views 
> expressed in this email are those of the sender and not of National 
> Australia Bank Ltd. Advice in this email does not take account of 
> your objectives, financial situation, or needs. It is important for 
> you to consider these matters and, if the e-mail refers to a 
> product(s), you should read the relevant Product Disclosure 
> Statement(s)/other disclosure document(s) before making any 
> decisions. If you do not want email marketing from us in future, 
> forward this email with "unsubscribe" in the subject line to 
> Unsubscriptions@... in order to stop marketing emails from 
> this sender. National Australia Bank Ltd does not represent that 
> this email is free of errors, viruses or interference.
> 
> 

> List Archive - Manage Your List Settings - Unsubscribe 
> Instructions for managing your mailing list subscription are 
> provided in the Listserv General Users Guide available at 
http://www.lsoft.com

To unsubscribe, write to LISTSERV@... and,
in the message body (not the subject), write: SIGNOFF MQSERIES

Re: MQ v6 z/os remote administration of MQ v5.3 distributed

Re: CF Recovery in a QSG Environment

CF recovery in a QSG environment