| Author |
Message
|
| offshore |
 Posted: Tue Aug 26, 2003 9:01 am Post subject: Channel Definitions |
 |
|
Master
Joined: 20 Jun 2002
Posts: 222
|
All,
Would this work?
Currently we have a MQ 5.3 cluster in Win2k sending to MQ 5.3 on z/OS. The z/OS system is sysplex friendly, but currently no plans to implement Queue-Sharing groups due to the message size restriction of 64K.
Lets say we have the following scenerio:
DNS
MQ1 - 10.10.10.30
MQ1 - 10.10.10.40
In the channel definition of MQ on the Win2k side put MQ1 (as opposed to the IP address) in the Connection Name property of the channel.
Now, on the z/OS side we have a QM1 running on z/OS image "A" with ip of 10.10.10.30, and also a QM1 running on z/OS image "B" with an ip of 10.10.10.40.
If QM1 on image A goes away will the channel try to send to the alternate 10.10.10.40 address or not?
I realize this is a lot of info and maybe not too clear. Any thoughts would be appreciated. |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Tue Aug 26, 2003 11:36 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
No
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| offshore |
| Posted: Tue Aug 26, 2003 11:57 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
OK...why not?
Does it keep the Connection name in memory? |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Aug 26, 2003 11:57 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Just kidding about the short answer.
When MQSeries Channels go into retry they dont do a DNS lookup of the
conname, and even if they did your DNS server will still return the bad IP
address.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 26, 2003 2:28 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We are about to implement a solution that solves this problem.
Basically, you first define a virtual IP address (VIP). Lets call that VIP 10.10.10.99. This VIP is primarily mapped to IP address 10.10.10.30. Its secondary mapping is to IP address 10.10.10.40.
In your channel def on the sender side, you specify a connname of 10.10.10.99 (or more likely, the DNS name that points to it). Same goes for any client applications that code the HostName parameter.
At the network level, the router knows that anything going to 10.10.10.99 really wants to go to 10.10.10.30, and so it sends it there. BUT, if 10.10.10.30 is unavailable, the router at the network level automatically starts sending it to 10.10.10.40. No changes needed in our MQ channel definitions. They will automatically start sending to 10.10.10.40 under the covers.
Now, I haven't actually tried this yet, but the concept was recomended by a highly respected consultant who has seen the design implemented in production environments. I will be trying this out in the next month or so in our LAB environment.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Aug 26, 2003 6:08 pm Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well this may not work either, if you are using persistent messages the sequence number willl not match the new receiver channel sequnce number, you will to provide some
software to detect this and resolve with backout on the channel
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Aug 26, 2003 6:18 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You are right. During the discussion they mentioned this. This concept was primarily for use with clients connnecting in via the SVRCONN channels, where sequence #s are not an issue.
To handle regular channels, you also put both of these queue managers into an MQ cluster, and have the gateway QM handle putting messages round robin style to both. If one goes down, MQ will take care of not sending any more messages there.
True, this is not a full solution to the original problem. Due to those Sequence numbers, this is probably the best you can get.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Wed Aug 27, 2003 8:40 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
I just helped setup WMQ v5.3 on Solaris doing what is described above using Veritas to control the hot swap (we are using Active / Passive QMgrs).
The sequence number is not issue. Go get SupportPac MC6A and it explains how to create / run queue managers with Veritas (and channels too).
Doing our failover testing, I was very surprised at how seamlessly the VIP, queue manager and channels all moved from one box to the next and communication only paused for about 2-3 seconds. I did not have to touch any channels or reconfigure anything. We had both active sender / receiver channels and active SVRCONN channels going during the test. Nothing was dropped / nothing was lost.
Our only problem right now is that one of the external client uses a channel exit to valid the incoming IP and queue manager. For some strange reason, our sender MCA is using the wrong VIP (Virtual IP) when sending the outbound messages (hence the exit does not allow the connection). Veritas seems to be giving the MCA the console VIP rather than non-console VIP.
My suggestion is to not use DNS entries but rather a VIP. Have the clustering software (i.e. Veritas) flow the VIP from box to box as you do failover. Therefore, you can give out the VIP to all partner sender channels and for clients using SVRCONN channels.
later
Roger...
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Aug 28, 2003 4:10 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Roger we do this as well for our HUB and MQSI queue managers. We use Veritas hardware clustering to manage failing over the QM from the primary box to the secondary. And yup, it fails it over with no problems and the sequence #s are never an issue with any of the channels.
BUT, Veritas Hardware clustering is not cheap. If one can't shell out the bucks for it, you gotta come up with another solution. I think the MQ Queue manager clustering for messages coming in and out over regular channels combined with VIP addresses for CLNTCONN channels to use is the best (short of shelling out buck$ for Veritas)????
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Aug 28, 2003 5:19 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Also Roger I dont think this option is there for Mainframes or am I wrong.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| vennela |
| Posted: Thu Aug 28, 2003 7:35 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| I think Mainframe High Availability can be achieved by Queue Sharing Groups |
|
| Back to top |
|
|
| mrlinux |
| Posted: Thu Aug 28, 2003 7:41 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
not with messages > 64k unless they have broken that barrier
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
|
|
