ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Clusters with 3 FR or more - Final

Post new topic  Reply to topic Goto page 1, 2  Next
 Clusters with 3 FR or more - Final « View previous topic :: View next topic » 
Author Message
jhidalgo
PostPosted: Fri May 02, 2008 8:55 am    Post subject: Clusters with 3 FR or more - Final Reply with quote

Disciple

Joined: 26 Mar 2008
Posts: 161

FYI

After contacting Ian Vanstone and some other experts from IBM we got to this conclusion:

The clusters use the publish/subscribe model for internal messaging, having ALL your FRs connected to each other with Manually defined CLUSSDRs channels makes all the events or changes replicate correctly to every FR in the cluster, and the cluster will work correctly regardless of the number of FRs in the cluster.

It is very important to have ALL your FRs connected to each other, also, you can have CLUSSDR channels from your PRs to any number of FRs.

Code:

That may be why the wizard in v6 creates manually define CLUSSDRs between your FRs.

Also, I am sure this applies to > v6, because in 5.x it never worked for me but now it does in v6


Regards
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Tue May 06, 2008 10:43 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

So I contacted some IBM folks, including Ian, and got clarification on this.

#1 Regardless of how many FRs you have, each FR should have a manual CLUSSNDR defined to every other FR.

#2 If every FR has a CLUSSNDR to every other FR, each FR will know about every cluster attribute on every QM in the cluster.

#3 A PR will only ever publish info to 2 FRs. A PR will only ever subscribe to 2 FRs. Period. It doesn't matter how many manual CLUSSNDRs you define on that PR. A PR will only ever send its info (publish) to 2 FRs and will only get updates (subscribe) from 2 FRs.

#4 You should only define one CLUSSNDR to one FR from a PR.

#5 If 2 FRs go down in your cluster, your cluster will be able to send messages just fine. But any changes to cluster definitions become a problem. Any PRs that used both of these down FRs will still function for messaging, but they will not be made aware of any changes in the cluster because both of it's FRs are N/A.

#6 If two of your FRs are down, and you still have other FRs, you could go to your PRs and delete the CLUSSNDR to the down FR, define a CLUSSNDR to an available FR and issue REFRESH CLUSTER(*) REPOS(YES). This would cause your PR to register with an available FR and thus pick up cluster changes.

#7 In a properly designed system the liklihood of 2 FRs being down is next to zero, so the need for more than 2 FRs is next to zero. And even if both FRs are down it doesn't mean your cluster will come to a screeching halt.

Just use 2 FRs.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
jhidalgo
PostPosted: Wed May 07, 2008 11:00 am    Post subject: Reply with quote

Disciple

Joined: 26 Mar 2008
Posts: 161

PeterPotkay wrote:

Just use 2 FRs.


True !

it is just that not even IBM's guys were clear on this
Back to top
View user's profile Send private message
LMD
PostPosted: Wed May 07, 2008 1:55 pm    Post subject: Reply with quote

Acolyte

Joined: 30 Oct 2002
Posts: 56
Location: Paris - France

PeterPotkay wrote:
.../...

Just use 2 FRs.


ok Peter, but ....
I still think that in some special configuration, we can (must ?) have more than 2 FR.

Imagine ... (no, it's a real configuration), imagine a customer with a some remote Qmgrs (say 20) connected to a central location. This central location host 4 or 5 big and critical Qmgrs. These Qmgrs act as application gateways.

On this central location ("nominal site") there is 2 Qmgrs that play FR role. The FR are distinct from application Qmgrs to allow shutdown of an application Qmgr without loosing a FR.

As a financial institution, this customer have also a backup site, with the same hardware than the nominal site. So if we loose the nominal site, production can continue on backup site.

To allow a smooth switching beetween sites, the nominal site Qmgrs, the backup site Qmgrs, the remote Qmgrs all belongs to the same MQ cluster.

So we need also FR on the backup site. But more than one FR on each, so 2 FR on nominal, and 2 FR on backup site.

All FR are manually interconnected, and each PR is connected to 1 FR an nominal and 1 FR on backup site.

All 4 FR are up all the time, in case of failure of one or all serveurs on nominal site, MQ activity can switch easily to backup site, without changes on the 20 remote qmgrs (using CLWLPRTY attribute)

Any comments ?
_________________
lmd_at_demey-consulting.fr - http://demey-consulting.fr - Paris, France.
WMQ, WAS & IIB Certified.
#IBMChampion
Back to top
View user's profile Send private message Visit poster's website
PeterPotkay
PostPosted: Wed May 07, 2008 5:36 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

Put one FR in each data canter. When things are fine your cluster runs with only 2 FRs as it should. When disaster strikes, and you know one of those FRs will never be coming back, you create a new FR in the remaining data center. Since the cluster can run fine indefinitely with only 1 remaining FR you have the time to get a 2nd new FR up and running post-disaster.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
jhidalgo
PostPosted: Fri May 09, 2008 4:04 pm    Post subject: IT WORKS !!!! Reply with quote

Disciple

Joined: 26 Mar 2008
Posts: 161

Well well well.....

Seems like you CAN have N FRs in your cluster, it all works IF you update the cluster information in the PR you do changes....

When you change something in one PR it will publish the change to TWO FR, that's true, you can see those msgs in the SYSTEM.CLUSTER.TRANSMIT.QUEUE, so it doesn't matter if you have more FRs in your cluster, those others will not see the change, UNLESS you go to your PR and issue the REQUEST CLUSTER INFO, in which case the PR will publish this information to ALL your FR in the cluster and it all works just fine....

So, it is not a problem to have more than 2, but you have to consider:
1. Each PR should have CLUSSDR to your FRs
2. You have to issue the "request cluster info" in your PRs and it will update the FRs it has connection to

PD: when you add a PR to your cluster the wizard has a bug, do not use the "Select ALL" option when you are creating your channels to the FRs, select them manually and it will present them in the next window.
Back to top
View user's profile Send private message
jhidalgo
PostPosted: Sat May 10, 2008 5:28 pm    Post subject: Reply with quote

Disciple

Joined: 26 Mar 2008
Posts: 161

Quote:
1. Each PR should have CLUSSDR to your FRs
2. You have to issue the "request cluster info" in your PRs and it will update the FRs it has connection to


Err, it is not request cluster info, it is refresh cluster info, sorry
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun May 11, 2008 6:13 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

I believe the point Peter was trying to make is that in normal operations(2 FR only) you do not have any manual steps.
It really would bug me if after every change affecting a clustered object (or a list of clustered objects) I would have to emit the refresh cluster command.

I use refresh cluster, when, no matter what, the other FR does not seem to be getting the change and I run out of patience.
And I issue the command on the FR that has not yet processed the change. This way the repository syncs up and no matter to which FR I connect I have up to date info. This is an exceptional procedure. Usually there is no need for that and both FR's show the update within a second or less.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
jcv
PostPosted: Sun May 11, 2008 6:24 am    Post subject: Re: Clusters with 3 FR or more - Final Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

I have manually defined (exactly) one clussdr from one of PR's to the one FR, and got auto defined clussdr to the other FR. Both chls were running when I decided to define manually clussdr to the other FR. After issuing define chl with the same chl name as that of the auto defined chl, nothing really happened regarding current status of that channel. I have restarted the new(old) channel, and everything worked O.K. from then on. Considering #4 which seems to be in contradiction with jhidalgo statements, what am I supposed to do now? Do I have to expect some problems with that channel, I mean should I delete it?
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Sun May 11, 2008 7:39 pm    Post subject: Re: Clusters with 3 FR or more - Final Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY

jcv wrote:
I have manually defined (exactly) one clussdr from one of PR's to the one FR, and got auto defined clussdr to the other FR. Both chls were running when I decided to define manually clussdr to the other FR. After issuing define chl with the same chl name as that of the auto defined chl, nothing really happened regarding current status of that channel. I have restarted the new(old) channel, and everything worked O.K. from then on. Considering #4 which seems to be in contradiction with jhidalgo statements, what am I supposed to do now? Do I have to expect some problems with that channel, I mean should I delete it?

jhidalgo's point was about defining a manual cluster sender between all FRs. He said nothing about defining multiple cluster senders from PR to FR's.

Usual policy is you define the cluster receiver and the cluster sender manually to the nearest FR from the PR and let the cluster do all the rest.

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
jcv
PostPosted: Sun May 11, 2008 11:19 pm    Post subject: Reply with quote

Chevalier

Joined: 07 May 2007
Posts: 411
Location: Zagreb

Well, if #4 is just usual policy and not the strict rule, than I have nothing to worry about. I've noticed what's the main subject here, sorry for the digression and missinterpretation.
Back to top
View user's profile Send private message Visit poster's website
jhidalgo
PostPosted: Mon May 12, 2008 5:53 am    Post subject: Reply with quote

Disciple

Joined: 26 Mar 2008
Posts: 161

I don't see why should I follow #4, if you have multiple CLUSSDRs to your FRs it will help when you do the "Refresh Cluster Info" since your PR will send multiple update requests, so those FRs that get the message will replicate it with the publish-subscribe thru all your cluster. You "can" have only one, but it is better to have more so you make sure your updates get to the cluster.

The point here is that if you have +2 FRs then you may need to use "Refresh Cluster Info"(to speed up the process) after changing objects and you need to have all your FRs interconnected. Having CLUSSDRs from your PRs to all your FRs is optional, but aside from that, having +2 FRs may be a very good thing to consider.

What I do now is to monitor SYSTEM.CLUSTER.TRANSMITION.QUEUE to make sure things are doing fine.

The only consideration you may have with this schema is bandwidth usage which I don't think is so important.
Back to top
View user's profile Send private message
jhidalgo
PostPosted: Mon May 12, 2008 3:10 pm    Post subject: Reply with quote

Disciple

Joined: 26 Mar 2008
Posts: 161

All this in v6:

I made a simple test, having a cluster with 6 FRs and 6 PRs.
All the FRs connected to each other with CLUSSDRs.
Having all the PRs connected to the FRs with CLUSSDRs.

Shutting down all the FRs, then creating shared queues in your PRs, you will see 4 messages in the SYSTEM.CLUSTER.TRANSMISION.QUEUE (usually to 3 or 4 different FRs).
If you right click the PR you changed and the Refresh the cluster info it will create a lot of messages with updates to your FRs at that moment almost any FR will know about the changes. I am not sure about how the PR chooses the FRs to publish to but by refreshing the cluster info at the PR will make it queue messages to a lot of FRs. What will be nice will be to have a way to determine which FRs is using each PR to publish to when Refreshing the info.

We get to a dead end if the documentation is not specific on this, but I have been testing the different scenarios and it just works, I will like to base the argument on examples, in fact I have been thinking on recording a video, it will be a nice proof.

The cluster will not work until you refresh the info at the PRs but once you do that it seems to work just fine, we need an example with the opposite argument
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon May 12, 2008 3:18 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

We will have to agree to disagree. I reviewed my emails with the IBM cluster experts, reviewed the manuals and thought about it some more. I stand by what I listed above as being correct.

jhidalgo wrote:
I don't see why should I follow #4,

Because its the documented way?


jhidalgo wrote:
if you have multiple CLUSSDRs to your FRs it will help when you do the "Refresh Cluster Info" since your PR will send multiple update requests, so those FRs that get the message will replicate it with the publish-subscribe thru all your cluster. You "can" have only one, but it is better to have more so you make sure your updates get to the cluster.

A PR will only ever publish to two FRs. You only need to define one CLUSSDR to one FR. MQ will determine what the second FR is to be used. Additional FRs will not get updates directly from that PR. But all FRs updated each other if the FRs are fully interconnected with manual CLUSSDRs as they should be.

jhidalgo wrote:

The point here is that if you have +2 FRs then you may need to use "Refresh Cluster Info"(to speed up the process) after changing objects and you need to have all your FRs interconnected.

There is no need to issue RERESH CLUSTER here. If you make a change on the PR it will publish the change to 2 FRs. If there happen to be additional FRs the FRs will update them.

jhidalgo wrote:

Having CLUSSDRs from your PRs to all your FRs is optional, but aside from that, having +2 FRs may be a very good thing to consider.

I disagree.
A. You are making more work for yourself than needed.
B. You will be giving yourself a false sense of security when 2 of your FRs are down.

The effort should be spent on insuring that one of your FRs are always up. You handle this through thoughtful design and proper procedures.

The only situation I can think of where you would want more than 2 FRs is if you have 100 QMs, all located in curbside banana huts across the South Pacific. You want a cluster. Every banana hut is just as likely to have a power outage as another. You don't feel any 2 will be up more than others, so you up your odds that a FR will always be up by making 3 or more of the banana hut QMs a FR. But you still run the risk of not all PRs knowing about all changes as soon as 2 or more FRs are down.

I don't have access to the MQ cluster internal code, so all of the above is based on info provided in the Cluster Manual, talking to IBM MQ Cluster architects and years of experience. I think its the right way. If you can find documentation that says otherwise or if you have a specific test case that proves otherwise please let me know. I like MQ clustering and am eager to learn all there is about it.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon May 12, 2008 5:02 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7717

jhidalgo, you posted your test case as I was typing. I will define a test cluster with 3 FRs when I get a chance and play around with it myself and see what happens.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » Clusters with 3 FR or more - Final
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.