| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Pros and Cons of adding a Multi-Instance QM to a Cluster |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu Nov 26, 2009 9:49 am Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
I'd suspect that 7.0.1 has contemplated the race among the MI software and NFS file locks.
_________________
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 |
|
 |
| mvic |
| Posted: Thu Nov 26, 2009 2:07 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| bruce2359 wrote: |
| I'd suspect that 7.0.1 has contemplated the race among the MI software and NFS file locks. |
The race I was talking about was between NFS file locks being released (thus allowing the standby qmgr to start) and the completion of a switchover of virtual IP addresses. If the file locks are released first, it is possible for the queue manager and its outbound channels and listeners to start, binding to an adapter that is about to be altered.
Whether this could ever be a seamless process I doubt. But I admit I do not know for sure.
This subject arose in the context of trying to make switchover transparent in MQ clusters.
If implementing a pure-7.0.1 solution you can use CONNAME lists to make the switchover "transparent" and so there is less need (no need?) for switching a virtual IP address. But if (as will be common) you build a system/network composed of 7.0.1 and 6.0 code levels, you can't do that, and have to think about how to work around the fact that the switched-over queue manager is now on another machine. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Nov 27, 2009 4:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| I'm not nearly as up on this as I'd like to be, but doesn't the standby qmgr still start services during it's startup? So couldn't one of those be the thing to initiate the IP failover? |
|
| Back to top |
|
|
| leiversag |
| Posted: Wed Feb 23, 2011 6:30 am Post subject: MQ multi-instance clustering |
|
|
Novice
Joined: 18 Dec 2009
Posts: 15
|
I've just run into this issue.
We are building iSeries LPARS with iASP. The MQ version, on these, will be 7.0.1.4. I'm ok with the build now, but I'm not sure about the clustering.
We can't use the default port (security policy). The full repository is both mainframe, & version 6 of MQ.
I've been testing connectivity on a development box, without success (except with a port 1414 listener).
Would anyone please be able to answer...
a) is there a way to use blank CONNAME, but specify a port?
b) if I use comma delimited CONNAME on the v7 qm, will the v6 full repos work?
Thanks
Andy |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Feb 23, 2011 6:35 am Post subject: Re: MQ multi-instance clustering |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| leiversag wrote: |
I've just run into this issue.
We are building iSeries LPARS with iASP. The MQ version, on these, will be 7.0.1.4. I'm ok with the build now, but I'm not sure about the clustering.
We can't use the default port (security policy). The full repository is both mainframe, & version 6 of MQ.
I've been testing connectivity on a development box, without success (except with a port 1414 listener).
Would anyone please be able to answer...
a) is there a way to use blank CONNAME, but specify a port?
b) if I use comma delimited CONNAME on the v7 qm, will the v6 full repos work?
Thanks
Andy |
You can only use a multi-instance qmgr if all your connections to it are V7.
So you cannot use it in a cluster where the full repos is V6.
You cannot use it if there are V6 clients trying to connect to it.
The reason being that the IP does not fail over.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 23, 2011 6:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| We can't use the default port (security policy). |
You cant't use port 1414 because of a security policy, but 1415 is ok?
_________________
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 |
|
|
| leiversag |
| Posted: Wed Feb 23, 2011 7:08 am Post subject: |
|
|
Novice
Joined: 18 Dec 2009
Posts: 15
|
| bruce2359 wrote: |
| Quote: |
| We can't use the default port (security policy). |
You cant't use port 1414 because of a security policy, but 1415 is ok? |
we don't ue 1415 either, i don't think there's a particular reason, just that we have a specific range (i assume that numbers in this range are not used, by default, for any product, or some such reason) |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Feb 23, 2011 7:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
There are 65k port numbers available. Port 80 is most often used for http/html traffic; but in the early days of Mr. Internet, some shops had used port 80 for something else. 443 is for SSL. Your site can use any of these ports for any application they desire.
I suspect that your shop, like many others, has blocked unused port numbers. New application making use of new (previously unused) port numbers will require that the port be unblocked.
_________________
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 |
|
|
|
|
|
|
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
|
|
|
|
