| Author |
Message
|
| LouML |
 Posted: Mon Oct 24, 2011 6:12 am Post subject: Anyone running Multi-Instance QM in Production yet? |
 |
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
To be more specific, is anyone running Multi-Instance QM with external channel connections to clients not running 7.0.1.3 or greater in Production yet?
We're preparing migration of Dev QM now (and Prod next year). Internal app testing is moving along. However, we have a few external channel connections to systems that are not running 7.0.1.3 or greater.
Of course, this means they cannot support multiple hostnames on the CONNAME of their Sender channel pointing to us. This causes logistical problems for failover. Not the end of the world in the Dev environment but obviously a showstopper in prod.
Some people have suggested we supply the external firms with a VIP or a DNS name so in the event of a QM failover, the could reconnect. However, this is not the same as the automatic failover provided with MIQM.
Any ideas or suggestions?
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Oct 24, 2011 6:22 am Post subject: Re: Anyone running Multi-Instance QM in Production yet? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| LouML wrote: |
| Some people have suggested we supply the external firms with a VIP or a DNS name so in the event of a QM failover, the could reconnect. However, this is not the same as the automatic failover provided with MIQM. |
No? Are you sure?
You don't get client automatic reconnect unless the client is at v7.0.1 minimum... Note that client automatic reconnect is not the same thing as failover.
A VIP that is moved by an MQ service that runs at qm startup should provide what you're looking for. But again, clients won't do automatic reconnect if they're not at v7.0.1 |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Oct 24, 2011 6:29 am Post subject: Re: Anyone running Multi-Instance QM in Production yet? |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
| LouML wrote: |
| Some people have suggested we supply the external firms with a VIP or a DNS name so in the event of a QM failover, the could reconnect. However, this is not the same as the automatic failover provided with MIQM. |
No? Are you sure?
You don't get client automatic reconnect unless the client is at v7.0.1 minimum... Note that client automatic reconnect is not the same thing as failover.
A VIP that is moved by an MQ service that runs at qm startup should provide what you're looking for. But again, clients won't do automatic reconnect if they're not at v7.0.1 |
It's my understanding that if the external company is running MQ Server 7.0.1.3 and their sender channel has both our hosts in the CONNAME, when our Queue Manager switches from server A to B, the channel would handle that automatically.
If they're pointing to a VIP or DNS name, and our Queue Manager switches from server A to B, we would have to make a change on our end (Network team would have to flip the VIP or change the DNS entry) to allow the sender channel to reconnect.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 24, 2011 7:10 am Post subject: Re: Anyone running Multi-Instance QM in Production yet? |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| LouML wrote: |
| It's my understanding that if the external company is running MQ Server 7.0.1.3 and their sender channel has both our hosts in the CONNAME, when our Queue Manager switches from server A to B, the channel would handle that automatically. |
Yes. MQ channels will reconnect.
| LouML wrote: |
| If they're pointing to a VIP or DNS name, and our Queue Manager switches from server A to B, we would have to make a change on our end (Network team would have to flip the VIP or change the DNS entry) to allow the sender channel to reconnect. |
Presumably the VIP would stay the same from the network point of view, but it would only be registered to the network adapter that exists on the host that currently has the active instance. Think of how a VIP works under HACMP/MSCS/etc. It's the same idea, except instead of having the HA coordinator move the VIP, it's an MQ service that runs a shell script that moves the VIP. |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Oct 24, 2011 7:22 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It would be great if IBM could write such a script (to update the IP address for a DNS name), as using the relevant DNS commands seems to be very complicated.
It might be easier to have two DNS names and just update a DNS alias between them. Either way - this script needs to know which way to move it and perform the update to the DNS.
Time for a support pac someone? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 24, 2011 7:30 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
It would be great if IBM could write such a script (to update the IP address for a DNS name), as using the relevant DNS commands seems to be very complicated.
It might be easier to have two DNS names and just update a DNS alias between them. Either way - this script needs to know which way to move it and perform the update to the DNS.
Time for a support pac someone? |
It should not be a change in DNS.
It should just be a call to ifconfig/ipconfig - essentially - to register the ip address at the new host. Again, in the same manner that the IP address is moved by HACMP/MSCS. |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Oct 24, 2011 8:06 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
| zpat wrote: |
It would be great if IBM could write such a script (to update the IP address for a DNS name), as using the relevant DNS commands seems to be very complicated.
It might be easier to have two DNS names and just update a DNS alias between them. Either way - this script needs to know which way to move it and perform the update to the DNS.
Time for a support pac someone? |
It should not be a change in DNS.
It should just be a call to ifconfig/ipconfig - essentially - to register the ip address at the new host. Again, in the same manner that the IP address is moved by HACMP/MSCS. |
Our current plan for MIQM is to move all of our Queue Managers to a pair of servers. 5 QM's on serverA and 5 on serverB. Setting up a VIP called serverC doesn't really help us. Barring any server issues, both IP's would be alive at the same time. Unless we set up a specific VIP for each Queue Manager.
It looks like it's going to get messy for us. I'm rethinking the VIP idea.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 24, 2011 9:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Can you centralize the external connections onto a single one of these qmgrs? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 24, 2011 10:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
For pre V7 connections you can also provide a channel table, that would fail over automatically. In the channel table you need 1 entry for the current instance and 1 entry for the failover instance. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| LouML |
| Posted: Mon Oct 24, 2011 10:05 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| mqjeff wrote: |
| Can you centralize the external connections onto a single one of these qmgrs? |
No, the Queue Managers are for different businesses.
We're removing MQ Server from each specific app server and centralizing them to save on licensing costs. Also, it gets me off of the applications servers and gets them off of my servers.
By the way, we do have some external systems that are running 7.0.1.3 and have made the change. One however, is running 7.0.1.6 but their policy does not allow more than one hostname on a sender channel def.
I am trying to get them to modify their policy, as I believe this is going to be a popular feature.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| LouML |
| Posted: Tue Oct 25, 2011 8:29 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| fjb_saper wrote: |
| For pre V7 connections you can also provide a channel table, that would fail over automatically. In the channel table you need 1 entry for the current instance and 1 entry for the failover instance. |
Would you elaborate? You're not talking about AMQCLCHL.TAB, correct?
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 25, 2011 9:39 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| LouML wrote: |
Would you elaborate? You're not talking about AMQCLCHL.TAB, correct? |
That's exactly what I am talking about...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| LouML |
| Posted: Tue Oct 25, 2011 11:21 am Post subject: |
|
|
Partisan
Joined: 10 Nov 2005
Posts: 305
Location: Jersey City, NJ / Bethpage, NY
|
| fjb_saper wrote: |
| LouML wrote: |
Would you elaborate? You're not talking about AMQCLCHL.TAB, correct? |
That's exactly what I am talking about... |
I think we're talking about two different things. I was talking about sender channels at external companies being unable to use multiple connames to connect to our MIQM.
Your suggestion is for pre V7 clients? Would putting two of the same channels with different hosts in a TAB file work? I thought once you add the same channel name to a TAB file, it becomes the new def for that channel, superceding the first entry.
_________________
Yeah, well, you know, that's just, like, your opinion, man. - The Dude |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Oct 25, 2011 12:16 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| LouML wrote: |
| fjb_saper wrote: |
| LouML wrote: |
Would you elaborate? You're not talking about AMQCLCHL.TAB, correct? |
That's exactly what I am talking about... |
I think we're talking about two different things. I was talking about sender channels at external companies being unable to use multiple connames to connect to our MIQM.
Your suggestion is for pre V7 clients? Would putting two of the same channels with different hosts in a TAB file work? I thought once you add the same channel name to a TAB file, it becomes the new def for that channel, superceding the first entry. |
Of course you'd have to have 2 different channels, one for each instance. But with the channel table the app would latch on to the running instance...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Oct 25, 2011 12:17 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| Of course you'd have to have 2 different channels, one for each instance. But with the channel table the app would latch on to the running instance... |
The only "app" in question here is another queue manager...
queue managers can't use CCDTs with SENDER channels. |
|
| Back to top |
|
|
|
|
