Hi Tim, Thank you for your response. I hadn't thought about it that way, but it sounds very reasonable. Guess I need some more education on MQ design :-)
Frank Laurijssens > -----Oorspronkelijk bericht----- > Van: Tim Armstrong [mailto:[EMAIL PROTECTED] > Verzonden: donderdag 27 maart 2003 0:11 > Aan: [EMAIL PROTECTED] > Onderwerp: Re: [MQSERIES] A couple of clustering questions > > > Hi Frank, > > Don't know whether the following is what you are after, but > it or a variation of it could give you higher availability > you are seeking. It uses a mix of client connection tables > and MQ clustering. > > You have two gateway machines with one queue manager each > that act as the full repositories for your cluster. By > gateway machine I mean the client applications connect to the > queue managers on them but the server apps do not run on them > so they exist to distribute the workload to the cluster > queues on the back end servers. > > Your server apps for A, B, C, and D and their associated > cluster queues run on four backend machines BE1, BE2, BE3 and > BE4 as follows. > BE1: Apps A & B > BE2: Apps B & C > BE3: Apps C & D > BE4: Apps D & A > > The client connection tables are then used to define > connections to both the gateway machines G1 & G2 such that if > one gateway machine or queue manager is unavailable then the > other is used . Client A: G1 then G2 Client B: G2 then G1 > Client C: G1 then G2 Client D: G2 then G1 > > In normal usage what happens is: > Client A connects to G1 which distributes work to the backend > machines BE1 and BE4 on a round robin basis. Client B > connects to G2 which distributes work to the backend machines > BE2 and BE1 on a round robin basis. Client C connects to G1 > which distributes work to the backend machines BE3 and BE2 on > a round robin basis. Client D connects to G2 which > distributes work to the backend machines BE4 and BE1 on a > round robin basis. > > Regards > Tim A > > > > > Frank Laurijssens > <[EMAIL PROTECTED] To: > [EMAIL PROTECTED] > TERPAY.NL> cc: > Sent by: MQSeries Subject: Re: > A couple of clustering questions > List > <[EMAIL PROTECTED] > N.AC.AT> > > > 26/03/2003 21:31 > Please respond to > MQSeries List > > > > > > Hi Stefan, > > How about our scenario: > > Client application A uses w2k MQ server A which connects to a > VMS system. Client application B uses w2k MQ server B which > connects to the same VMS system. Client application C uses > w2k MQ server C which connects to yet again the same VMS system. > > All MQ servers run a similar message broker. This situation > has 'grown' over time, and for performance reasons the three > MQ servers cannot be combined on one machine. > > Next, we implement a new application, D. We will be buying > new hardware but it seems unlikely that the new hardware can > accomodate all queue managers on one machine. We want higher > availability (not High Availability). Windows clustering > cannot handle clusters larger than 2 nodes unless you buy > Datacenter server, which is currently out of the question. > > MQ Clustering sounds like a good solution to me in this > scenario. This raises the same questions as Glen had :-) > > Regards, > Frank Laurijssens > > > > -----Oorspronkelijk bericht----- > > Van: Stefan Sievert [mailto:[EMAIL PROTECTED] > > Verzonden: dinsdag 25 maart 2003 23:14 > > Aan: [EMAIL PROTECTED] > > Onderwerp: Re: [MQSERIES] A couple of clustering questions > > > > > > Hi Glen, > > I know I won't really be answering your concrete questions > below, but > > from what you describe I get the feeling that your > requirements might > > be better addressed by thinking about clustering your > Windows servers, > > not necessarily your queue managers. MQ clustering doesn't > really give > > you high availability, especially not if you have inherent > > request-reply affinities. Clustering the Windows boxes will > > give you HA functions, plus it has the least impact on your > > application design, since the only thing you have to do is to > > implement some sort of re-connection logic for your clients > > to respond to a 2009 (connection broken) reason code during a > > cluster node takeover event. I believe there is a support > > pack to talk about MQ support for MS Cluster Services pre > > MQV5.3 and I also believe that that support is shipped with > > V5.3. Sorry for navigating around your real questions, but I > > hope this is helpful, too. Cheers, Stefan > > > > > > >From: Glen Larson <[EMAIL PROTECTED]> > > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > > >To: [EMAIL PROTECTED] > > >Subject: A couple of clustering questions > > >Date: Tue, 25 Mar 2003 11:19:18 -0600 > > > > > >We are starting to look at clusters in order to provide some > > close to > > >24x365, on our W2K nodes. > > > > > >These Queue Managers (5.3) on W2K service other NT/W2K > servers with > > >MQClient installed (5.2, csd04). The MQServers, have an > > application to > > >service the requests, and that also request info from Legacy > > >applications on MVS (CICS, Batch & DB2 via MQ. > > > > > >1) On the front end side the programs are written in > > ActiveX. They put > > >requests on the queue, and come back later to look for a > > response. Not > > >a problem now since only one queue manager to connect to. With > > >Clustering they need to insure they go back to the correct queue > > >manager to retrieve their data. What field is available to > > the ActiveX > > >application, that has the true name of the Queue manager. > > So far the > > >ones that they have tried, have given the generic cluster > > qmgr name. > > >If this was the standard API, they would be told to use the > > info in the > > >object descriptor after the connection, or the MSG header > after the > > >put. > > > > > >2) On the MVS back-end, similar problem when to send the > > reply. For > > >CICS not a problem, using PUT1. For long running batch > > where requests > > >will come from multiple requesters, PUT1 would incur to much > > overhead. > > >So, we wish to use the MQOO_BIND_NOT_FIXED option, and route > > the reply > > >based on the name in the REPLY-TO-QMGR field for each reply > > message. > > >We have search the doc, and have not found an example of > how this is > > >specified on the PUT. We attempted to use the > > MQOD_OBJECTQMGRNAME, but > > >that did not work. > > > > > >thanks > > >Glen Larson > > >Zurich North America > > > > > > > > > > > >******************* PLEASE NOTE ******************* > > >This E-Mail/telefax message and any documents accompanying this > > >transmission may contain privileged and/or confidential > > information and > > >is intended solely for the addressee(s) named above. If > you are not > > >the intended addressee/recipient, you are hereby notified > > that any use > > >of, disclosure, copying, distribution, or reliance on the > > contents of > > >this E-Mail/telefax information is strictly prohibited and > > may result > > >in legal action against you. Please reply to the sender > > advising of the > > >error in transmission and immediately delete/destroy the > message and > > >any accompanying documents. Thank you. > > > > > >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 > > > _________________________________________________________________ > The new MSN 8: advanced junk mail protection and 2 months > FREE* http://join.msn.com/?page=features/junkmail > > 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 ---------------------------------------------------------------------------- -------------------- Disclaimer: ' Aan de inhoud van dit bericht kunnen alleen rechten ten opzichte van Interpay Nederland B.V. of aan haar gelieerde ondernemingen worden ontleend, indien zij door rechtsgeldig ondertekende stukken worden ondersteund. De informatie in dit e-mailbericht is van vertrouwelijke aard en alleen bedoeld voor gebruik door de geadresseerde. Als u een bericht onbedoeld heeft ontvangen, wordt u verzocht de verzender hiervan in kennis te stellen en het bericht te vernietigen zonder van de inhoud kennis te nemen, deze te vermenigvuldigen of andersoortig te gebruiken.' An English version of this disclaimer is available on http://www.interpay.nl/disclaimerenglish ---------------------------------------------------------------------------- -------------------- 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 ------------------------------------------------------------------------------------------------ Disclaimer: ' Aan de inhoud van dit bericht kunnen alleen rechten ten opzichte van Interpay Nederland B.V. of aan haar gelieerde ondernemingen worden ontleend, indien zij door rechtsgeldig ondertekende stukken worden ondersteund. De informatie in dit e-mailbericht is van vertrouwelijke aard en alleen bedoeld voor gebruik door de geadresseerde. Als u een bericht onbedoeld heeft ontvangen, wordt u verzocht de verzender hiervan in kennis te stellen en het bericht te vernietigen zonder van de inhoud kennis te nemen, deze te vermenigvuldigen of andersoortig te gebruiken.' An English version of this disclaimer is available on http://www.interpay.nl/disclaimerenglish ------------------------------------------------------------------------------------------------ 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
