| Author |
Message
|
| chrisng |
 Posted: Sun May 26, 2002 8:48 pm Post subject: Do MQ Channel cache in IP address? |
 |
|
Newbie
Joined: 26 May 2002
Posts: 7
|
 If a MQ sender channel is defined using DNS name. When this channel is
attending to reconnect with the remote receiver during a Channel RETRY
or due to channel disconnect interval expire case, will the Qmgr go to the
OS system for the latest IP address or using the existing IP address stored in the MQ cache?
What is the behaviour of the channel in a Qmgr failover
scenario, that when there is a change of DNS definitions at the DNS
server with a new IP address from the OS (if the OS has a very short TimeToLive interval), will the sender channel reconnect to the
failover Qmgr using the new IP address from the OS. Or the sender will retry the connection with previous cached IP address stored somewhere in the Qmgr.
Cheers
Chris |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Mon May 27, 2002 4:50 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
My understanding would be you should be just fine using the DNS. And the reason for this is, MQ stores/uses only that information which was passed to it at the time of creating the channel. Which means that even though the underlying IP changes for a particular Domain name, channels should still be able to pick up/resolve the appropriate IP using this Domain name.
Would like to hear more from others in this forum on this one.
Cheers.
Kumar
_________________
IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue May 28, 2002 10:21 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Can't remember if a channel restart would re-resolve the DNS name, or you had to restart the entire queue manager... 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue May 28, 2002 11:13 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Every time stop/start the channel it will resolve the hostname at least that is what I have found, we have had dns issues.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| chrisng |
| Posted: Tue May 28, 2002 5:25 pm Post subject: |
|
|
Newbie
Joined: 26 May 2002
Posts: 7
|
For MQ V5.2 on MVS. If the sender chl is defined with DNS, the CHIN started task will cache in the actual IP address from MVS and stored in the CHIN address space. Therefore, if the DNS was changed to a different IP addr, the CHIN need to be restarted in order to cache the new IP addr.
Even a CHL start/stop operation cannot force the chl to cache in the new IP address. (possible the TCP/IP TimeToLive parameter in our MVS env is set to never expire.)
We are designing a failover environment with two identical Qgmrs on Solaris boxes, one primary and one hot-standby. In case the primary is out of service, the DNS server will have the hot-standby IP addr replace the primary box one. And what we hope that the remote sender channels that are connecting to the primary box receivers will first went into RETRY status (as the , then on the next connection retry, issue an re-connection network call and cache in the new IP addr reset by the DNS server and then auto reconnect to the hot-standby box which is now the primary box. |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed May 29, 2002 3:24 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
If you are using persistant messages you are going to have issues trying
to channels to restart due to the message sequence numbers.
The SDR/RCVR Channels keep track of the number of messages sent.
if the the sdr has sent 3000 messages and you fail over to the other qmgr the rcvr channel will not have the correct sequence number and the channel will go into retry also it will be indoubt, you will have to use the
resolve command and the reset command, to get the channels started.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Wed May 29, 2002 8:26 am Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
| chrisng wrote: |
| We are designing a failover environment with two identical Qgmrs on Solaris boxes, one primary and one hot-standby. In case the primary is out of service, the DNS server will have the hot-standby IP addr replace the primary box one. And what we hope that the remote sender channels that are connecting to the primary box receivers will first went into RETRY status (as the , then on the next connection retry, issue an re-connection network call and cache in the new IP addr reset by the DNS server and then auto reconnect to the hot-standby box which is now the primary box. |
If you are using the Solaris cluster support for this (is it Veritas?) then it should work, because you will only specify the cluster's virtual IP address, not the physical address of any of the machines in the Sun cluster in your MQ channel definitions.
If not, see Jeff's comments... 
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| mrlinux |
| Posted: Wed May 29, 2002 8:32 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
The only way to get the failover to successfully start the channels is if you
have some form of OS Clustering that will support failing over a shared disk subsystem.
Why dont you just use MQSeries Clustering
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| chrisng |
| Posted: Thu May 30, 2002 11:29 pm Post subject: |
|
|
Newbie
Joined: 26 May 2002
Posts: 7
|
MQ cluster is not an option as:
1. external company do not have a policy for MQ cluster.
2. MQ cluster is an workload balancing solution, message sequence can not be preserved without using the MQ connection fix function.
For OS clustering, it cost $$.
So we are looking for a simple DNS solution.
And for the sender sequence number concern, we have sender channel connect to receiver with different sequence number and able to resync the sequence number with the receiver. Both Qmgrs are on Solaris and are V5.2. |
|
| Back to top |
|
|
| skytorch |
| Posted: Thu Jun 13, 2002 5:51 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
[quote="mrlinux"]The only way to get the failover to successfully start the channels is if you
have some form of OS Clustering that will support failing over a shared disk subsystem.
Why dont you just use MQSeries Clustering[/quote]
Jeff,
Can you elaborate a bit about how mq clustering can benefit a active QM failover to a hot-standby QM scenario ? From my understand, clustering is mainly for simplying distributed queueing configuration cost and some work load balancing between active QMs. Thanks.
Sky |
|
| Back to top |
|
|
| chrisng |
| Posted: Thu Jun 13, 2002 9:22 pm Post subject: |
|
|
Newbie
Joined: 26 May 2002
Posts: 7
|
A answer for from IBM.
......After discussing this with the developer about the DNS.
everytime a channel RETRY's a GetHostbyName call will be issued.
so, they dont cache anything. as long as DNS resolves the name to IP,
the channel should also get the new IP.
so, every instance of the RETRY will start a new channel job....
every time a runmqchl is issued if the other end is not active,
then that particular job or thread dies and a new instance is started
everytime channel is retried.
That means if sdr channel is using DNS and OS is caching in the new IP address, after a few RETRYs, the channel should be able to re-establish the channel connection with the Qmgr with a different IP address. (provide the SDR channel is able to re-sync with the new receiver channel.) --- haven't tested it yet...
Chris |
|
| Back to top |
|
|
| mrlinux |
| Posted: Fri Jun 14, 2002 3:24 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well the resync of channels will more than likely at some point require
a resolve command if you are using persistant messages, because the
sequence numbers arent going to match
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| cvshiva |
| Posted: Thu Jun 20, 2002 6:15 am Post subject: |
|
|
Apprentice
Joined: 04 Mar 2002
Posts: 35
Location: Chennai
|
Guys,
We have done elaborate testing of the Primary and Hot-StanBy things for Queue Managers , as a part of Disaster Recovery & Business Continuity drills.
As far as MQ is concerned we are not bothered about message recovery, as applications can always sense a DR situation and reproduce the message. But we make sure the connectivity is re-established in 3 hrs time at the max.
We don't use MQ Cluster.. here.. We just use two identical Queue Managers (On all platforms we use like NT, Win 2K, Sun Solaris, AIX & HP-UX).
I am not sure about the network switching from Production to DR which is taken care by the Network team.. but certainly I know they have script which updates the host table of the OS with necessary IP changes for the DR to be connected ....
As an MQ-Admin .. all I do is once the DR NEtwork is connected I ensure that the Machines are pointing to DR Machines by cross checking the Host table..
Then verify the Channel Status ( mostly they will be retrying as there would be a difference in the Message Sequence numbers ).. Then just RESET Channels at Sender & Receiver ends with Sequence number zero.. if the channels are not INDOUBT, otherwise I RESOLVE the CHANNEL first with ACTION as BACKOUT to get back the messages in XMITQ and then RESET the Message Seq Number.. and start channels..
There are occassions during this testing the Channels auto-resolved and started automatically during one of the retries within the retry interval.
So , I believe MQ doesn't cache the IP address anywhere it just goes to OS for the IP address during every try/re-try to start the channel...!!!
This can be verified by swtiching on the MQ Trace in NT / Win 2K environments where u can see the GetHostByName (TCP/IP fns) called during every try / re-try to start the channel
Regards
_________________
Ramnath Shiva
IBM Certified SOA Specialist
IBM Certified MQSeries Specialist
Standard Scope International Pvt Ltd , Chennai |
|
| Back to top |
|
|
|
|
