Re: Communication between Non-cluster Q-Managers and a Cluster
Ruud, Thanks again, I think you've told me all I need to know for now, you summed it up in your first paragraph about weighing the cost/effort against the risk. Unfortunately Iam in a support role and cannot influence the configuration to a great degree but I believe our conversation has exposed a reality gap in the expectations of the application development team and what is possible (Our organisation is new to MQ). Armed with this information I am about to drop a big oine on them and sit back and enjoy the fun. Tx again... Keep an eye on the forum if all I suspect is true, it will fall to me to sort out and that will generate more questions JB http://www.rac.co.uk http://www.racbusiness.co.uk http://www.bsm.co.uk Any opinions expressed in this e-mail are those of the individual and not necessarily the company. This e-mail and any attachments are confidential to RAC and/or BSM and are solely for use by the intended recipient. If you are not the intended recipient you must not disclose, copy or distribute its contents to any other person nor use its contents in any way. If you have received this e-mail in error please forward a copy of this e-mail to "[EMAIL PROTECTED]". RAC Motoring Services: Registered England 1424399 VAT Reg No. GB 238640945 British School of Motoring: Registered England 291902 VAT Reg No. GB 239505847 Registered Office(s): 1 Forest Road, Feltham, TW 13 7RR This e-mail and any attachments has been scanned for the presence of computer viruses. RAC/BSM accept no responsibility for computer viruses once this e-mail has been transmitted. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Communication between Non-cluster Q-Managers and a Cluster
Hi John - the goal of removing single points of failure is a good one, but in the end you have to weigh up the cost of setting up of such a solution, but also ask the question 'what is the likelyhood of the gateway qmgr becoming unavailable'. The use of COA/COD is 'controversial'. Some people use it all the time. I don't. The first point is 'trust MQSeries to deliver your messages'. The second is this : if you do request a confirmation, but don't get it, does that necessarily mean that the remote server is down? Not really, it could be a network problem. In your situation, you could be sending messages to gateway1 and not get a COA/COD - presumably your application will be sitting there for a 'short' (whatever that means) period of time waiting for the confirmations to arrive. If they don't, then you send your message to gateway2. There are then a number of situations to cover: 1. gateway2 responds and you happily use that route. In the meantime the network is fixed, and gateway1 responds. 2. gateway2 does not respond. The problem is knowing why a COA/COD was not forthcoming. A horrible situation could be that when gateway1 was used, it did deliver the message to one of the cluster queues and got processed. This could mean that a database was updated. - but for some reason the COA/COD did not arrive back. You then send the same message through gateway2, and duplicate the update. You will obviously need a method of recognising duplicates. All this seems to me to be rather tricky and a lot of extra effort. If some people have actually done it, then I'm sure we'll all look forward to their response to this email. Regarding overlapping clusters. You tend to use these to 'bridge' seperate clusters, and/or to 'hide' your cluster queues. After all, one of the strengths of clustering is that any queue manager in a cluster can send messages to any cluster queue in the cluster - but this is also its weakness. You may not want this. The point is that you don't need overlapping clusters to make use of cluster workload balancing. I'm trying to picture in my mind what exacly you're trying to achieve with your description of APP01, APP02, WMQI01, WMQI2, APPSERV01, APPSRV02. It's not your fault - but I tend to work better with pictures. Can you please let us have a picture - in, say, a Word document? Cheers ... Ruud -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of John Basevi Sent: 06 June 2002 10:25 To: [EMAIL PROTECTED] Subject: Re: Communication between Non-cluster Q-Managers and a Cluster Ruud, Many thanks - its as I suspected. Can I summarize and get you to confirm. A Cluster of 2 QMs will require a further 2 Gateway QMs in the cluster to accept messages from applications/other QMs and distribute them to shared cluster queues hosted by the main QMs. Applications putting to the Gateway QMs will need to handle there own failover situations. The only way to do this if it application working through an external QM is through COA/COD messages back to the application and then the App handling the failover. Is the best way to handle this a series of Overlapping clusters.? to give you a flavour of what we are trying to achieve, this is what we have. An Application running it own QMs(APP01, APP02) , a WMQI Hub comprising of 2 boxes/2 QMs (WMQI01, WMQI2) Clustered and Application Services Servers again 2 boxes/2 QMs (APPSERV01, APPSRV02) Clustered. (I believe from what you are saying, this gives us nothing in the way of WLM or failover security) Is the best way to define 2 overlapping clusters. CL_APP_01 comprising of APP01,APP02, WMQI1 and WMQI2 with outbound Q definitions hosted on WMQI1/2 shared with the cluster. A second Cluster CL_SERV_01 comprising of WMQI1, WMQI2, APPSERV01 and APPSERV02. outbound queues hosted on APPSERV01/02 and shared, return queues hosted by WMQI1/2 and shared with the cluster. The last leg is tricky and begs another question which I wont put here but I think the remot e Q defs for specific Queues will be required to return the response to the correct Queue manager APP01/02. This is already starting to get very complex - we have other application groups with their own QMs. The namelists on WMQI1/2 could get quite long - is this a viable approach in your opinion? Tx Again JB http://www.rac.co.uk http://www.racbusiness.co.uk http://www.bsm.co.uk Any opinions expressed in this e-mail are those of the individual and not necessarily the company. This e-mail and any attachments are confidential to RAC and/or BSM and are solely for use by the intended recipient. If you are not the intended recipient you must not disclose, copy or distribute its contents to any other person nor use its contents in any way. If you have received this e-mail in error please forward a copy of this e-mail to "[EMAIL PROTECTED]". RAC Motoring Serv
Re: Communication between Non-cluster Q-Managers and a Cluster
Ruud, Many thanks - its as I suspected. Can I summarize and get you to confirm. A Cluster of 2 QMs will require a further 2 Gateway QMs in the cluster to accept messages from applications/other QMs and distribute them to shared cluster queues hosted by the main QMs. Applications putting to the Gateway QMs will need to handle there own failover situations. The only way to do this if it application working through an external QM is through COA/COD messages back to the application and then the App handling the failover. Is the best way to handle this a series of Overlapping clusters.? to give you a flavour of what we are trying to achieve, this is what we have. An Application running it own QMs(APP01, APP02) , a WMQI Hub comprising of 2 boxes/2 QMs (WMQI01, WMQI2) Clustered and Application Services Servers again 2 boxes/2 QMs (APPSERV01, APPSRV02) Clustered. (I believe from what you are saying, this gives us nothing in the way of WLM or failover security) Is the best way to define 2 overlapping clusters. CL_APP_01 comprising of APP01,APP02, WMQI1 and WMQI2 with outbound Q definitions hosted on WMQI1/2 shared with the cluster. A second Cluster CL_SERV_01 comprising of WMQI1, WMQI2, APPSERV01 and APPSERV02. outbound queues hosted on APPSERV01/02 and shared, return queues hosted by WMQI1/2 and shared with the cluster. The last leg is tricky and begs another question which I wont put here but I think the remote Q defs for specific Queues will be required to return the response to the correct Queue manager APP01/02. This is already starting to get very complex - we have other application groups with their own QMs. The namelists on WMQI1/2 could get quite long - is this a viable approach in your opinion? Tx Again JB http://www.rac.co.uk http://www.racbusiness.co.uk http://www.bsm.co.uk Any opinions expressed in this e-mail are those of the individual and not necessarily the company. This e-mail and any attachments are confidential to RAC and/or BSM and are solely for use by the intended recipient. If you are not the intended recipient you must not disclose, copy or distribute its contents to any other person nor use its contents in any way. If you have received this e-mail in error please forward a copy of this e-mail to "[EMAIL PROTECTED]". RAC Motoring Services: Registered England 1424399 VAT Reg No. GB 238640945 British School of Motoring: Registered England 291902 VAT Reg No. GB 239505847 Registered Office(s): 1 Forest Road, Feltham, TW 13 7RR This e-mail and any attachments has been scanned for the presence of computer viruses. RAC/BSM accept no responsibility for computer viruses once this e-mail has been transmitted. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Re: Communication between Non-cluster Q-Managers and a Cluster
John - the fact that you've got a queue manager outside of the cluster immediately implies that you cannot make full use of its benefits. In fact, the same 'problem' exists when an application tries to connect to queue manager, say, QM1 whose WLM is then in charge of distributing the messages to cluster queues on queue managers QM2 and QM3. Here, QM1 is a single point of failure, and if it's down, then MQSeries clustering does not help at all - eventhough all 3 queue managers are in the cluster. The application might need to have some additional application logic to try another queue manager, say, QM1B. Similarly, one way to avoid a single point of failure in your scenario would be to have a second queue manager in the cluster to act as a possible gateway. The trouble is, how does the application know whether the MQPUT to the first gateway actually worked - remembering that this is an asynchronous link. You could use COD/COA but I personally don't like using these. So, once you've figured out that the first MQPUT didn't work, then you could send it to the second gateway. Once you've set up the second gateway, the return route to the 'outside' queue manager is automatically managed (provided you've got all the channels set up). In other words, an application connected to a clustered queue manager doing a put to a clustered object defined in both gateways should then be forwarded to the outside queue manager. Your other query regarding how to manage a local copy of a cluster queue: use clustered alias queues as described in Xephon's MQ Update magazine issue number 27, Sep 2001. (I did hear a rumour at the Clustering SIG that there may be a 'fix' to allow a local cluster queue to be WLM'ed. Best to ask IBM). HTH ... regards ... Ruud -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED]]On Behalf Of John Basevi Sent: 05 June 2002 14:39 To: [EMAIL PROTECTED] Subject: Communication between Non-cluster Q-Managers and a Cluster How do I configure a non-cluster Q-Manager to send messages to a cluster of queue managers in a fault tolerant manner aside from creating an overlapping cluster? The way I understand it the sender channel configured on the external Q-Manager explicitly references a particular machine in the cluster as a getway via its connection name. Isnt this a single point of failure? How can we get some fault tolerance into this. Also if the Gateway QM has a local copy of the Queue on it then all the messages will end up on this QM, how can we get the default WLM to assign these across the QMs in the rest of the cluster. Many Tx JB http://www.rac.co.uk http://www.racbusiness.co.uk http://www.bsm.co.uk Any opinions expressed in this e-mail are those of the individual and not necessarily the company. This e-mail and any attachments are confidential to RAC and/or BSM and are solely for use by the intended recipient. If you are not the intended recipient you must not disclose, copy or distribute its contents to any other person nor use its contents in any way. If you have received this e-mail in error please forward a copy of this e-mail to "[EMAIL PROTECTED]". RAC Motoring Services: Registered England 1424399 VAT Reg No. GB 238640945 British School of Motoring: Registered England 291902 VAT Reg No. GB 239505847 Registered Office(s): 1 Forest Road, Feltham, TW 13 7RR This e-mail and any attachments has been scanned for the presence of computer viruses. RAC/BSM accept no responsibility for computer viruses once this e-mail has been transmitted. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
Communication between Non-cluster Q-Managers and a Cluster
How do I configure a non-cluster Q-Manager to send messages to a cluster of queue managers in a fault tolerant manner aside from creating an overlapping cluster? The way I understand it the sender channel configured on the external Q-Manager explicitly references a particular machine in the cluster as a getway via its connection name. Isnt this a single point of failure? How can we get some fault tolerance into this. Also if the Gateway QM has a local copy of the Queue on it then all the messages will end up on this QM, how can we get the default WLM to assign these across the QMs in the rest of the cluster. Many Tx JB http://www.rac.co.uk http://www.racbusiness.co.uk http://www.bsm.co.uk Any opinions expressed in this e-mail are those of the individual and not necessarily the company. This e-mail and any attachments are confidential to RAC and/or BSM and are solely for use by the intended recipient. If you are not the intended recipient you must not disclose, copy or distribute its contents to any other person nor use its contents in any way. If you have received this e-mail in error please forward a copy of this e-mail to "[EMAIL PROTECTED]". RAC Motoring Services: Registered England 1424399 VAT Reg No. GB 238640945 British School of Motoring: Registered England 291902 VAT Reg No. GB 239505847 Registered Office(s): 1 Forest Road, Feltham, TW 13 7RR This e-mail and any attachments has been scanned for the presence of computer viruses. RAC/BSM accept no responsibility for computer viruses once this e-mail has been transmitted. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
