| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Problem with WIN2k Clustering |
« View previous topic :: View next topic » |
| Author |
Message
|
| cvrachak |
 Posted: Sat Jul 06, 2002 3:26 pm Post subject: Problem with WIN2k Clustering |
 |
|
Novice
Joined: 06 Jul 2002
Posts: 17
|
Hi,
I have a problem while connecting a remote Queue to a Clustered Environment.
The configuration details are as follows
working on MQ series Version 5.2 on WIN2k Platform.
Cluster named QMC has two servers
Server1
QM1 Primary Repository
QM2 has a queue named QMQ (default Bind type is NOT FIXED)
Server2
QM3 Secondary Repository
QM4 has a queue named QMQ (default Bind type is NOT FIXED)
QMQ are shared as Clustered queues.
within the MQ Series explorer I am able to put messages to these queues from QM1 or QM3. It is even doing Load balancing too.
I am unable to submit a message from the the Remote Queue Manager QMR who has to submit some messages onto the Clustered environment.
QMR uses the Remote Queue, Transmission Queue, Sender and Reciever Channels to Server1/2 Server. In the Remote Queue, if I specify that the 'Remote Queue Name' as QMQ and 'Remote Queue Manager Name' as QM1, I am unable to post the message. But If I change the value of 'Remote Queue Manager Name' to QM2 or QM4 it cooly submits the message. Am I doing anything wrong here or missing anything???But why should the outside world know who is hosting the Queue?
But practically, I should be able to submit the message onto QMQ on QM1 and let Cluster do the load balanching.. why is it not hapenning.
I have set the default Bind of Remote and Transmission Queue on QMR to Not Fixed too. But still not of help.. can anyone help me ?
Thanks
Chandra Sekhar |
|
| Back to top |
|
 |
| nimconsult |
| Posted: Sun Jul 07, 2002 11:06 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Hi,
The solution is simple:
In your cluster queue manager, define an empty queue manager alias:
| Code: |
| define qremote(QMC) |
(you can replace QMC by any other name, I just used your cluster name for conveniance)
Outside the cluster (in your case queue manager QMR), define the remote queue with target queue manager QMC (the queue manager alias defined previously):
| Code: |
| define qremote(QMQ) rname(QMQ) rqmname(QMC) xmitq(XQ.QM1) |
The difference is:
- if you specify QM1 as target queue manager MQ Series will attempt to find a local queue, which does not exist (hence the message goes in dead-letter queue).
- if you specify a target queue manager alias, which itself resolves to an empty queue manager name, MQ Series will attempt to resolve the queue either locally or inside the cluster. This is the trick.
Tell me if this works. Regards,
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be
Last edited by nimconsult on Mon Jul 08, 2002 2:27 am; edited 2 times in total |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Mon Jul 08, 2002 12:22 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
|
| Back to top |
|
|
| cvrachak |
| Posted: Mon Jul 08, 2002 11:47 am Post subject: |
|
|
Novice
Joined: 06 Jul 2002
Posts: 17
|
Thanks for the information,
It worked for me.
I have another related question,
Now the remote queue manager alias is defined on the primary repository. The outside QMGR's sender channel is pointing to the IP address of primary repository. In this case, if pimary repository goes down, how to achieve failover? Can the secondary repository take over?
Thanks again for the information
Chandra Sekhar |
|
| Back to top |
|
|
| nimconsult |
| Posted: Mon Jul 08, 2002 10:19 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Chandra,
In case of failure of the repository:
- the second full repository takes over in term of keeping knowledge of the cluster topology;
- there is however no failover for the sender-receiver channels. They are by definition point-to-point connection. If one point fails, the connection fails.
There are different answers to your question on failover:
(1) In case of failure of the repository, the messages will not be lost but simply piled up in the transmission queue. The only requirement is to size the transmission queue correctly. If you can restart the queue manager within an acceptable service level for your application, then as soon as the queue manager restarts, the message will flow into the cluster and your server application will process the backlog of messages.
(2) If the first solution is not acceptable then you need to implement a solution to switch to an alternative route in case of failure. Possible implementations:
- post your messages into an alternate remote queue that uses a different route. This has an impact on your client application.
- define two different point-to-point channels on the same transmission queue and implement a flip-flop procedure. If the first cluster queue manager fails, the sender channels goes in the state "retrying". Stop the channel and start the alternative one.
(3) You can ask yourself the question of putting the queue manager QMR inside the cluster, which eliminates the need of defining point-to-point channels and implementing manual failover solutions.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Tue Jul 09, 2002 3:23 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Another fail toolerant solution is haveing 2 sets of channels..
One set to the primary qmgr, and one set to the secondary, configured in this way:
from outside cluster sharing XMITQ, without retry on the sender channel, and timeout=0, this means that the channel always runs. If it goes down your automations system could catch this failure and the try start the backup channel (this is possible because the primary sender is closed.
IT WORKS, but not pretty.
Another approach could be using two or more clusters: You have your QMC cluster. you can connect more clusters to this, so that each "normal qmgr" is a cluster, this gives you the failover posibillity, like shown below:
| Code: |
+----------------+ +----------------+ +----------------+
! QM7(QM7C) ! ! QM8(QM8C) ! ! QM9(QM9C) !
+----------------+ +----------------+ +----------------+
! ! !
+-------------------------------------+
! !
+----------------+ +----------------+
! QM1(QMC) ! ! QM3(QMC) !
+----------------+ +----------------+
! !
+----------------+ +----------------+
! QM2(QMC) ! ! QM4(QMC) !
+----------------+ +----------------+
|
Yes, you might say it's a bit overkilling, but it works; yes it requires a bit of administration on QM1 and QM3, because it requires that the QMC queues are published, on the gateway MQ's.
I my firm we're running a similar setup, and it works fine.
Just my $0.02 
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| cvrachak |
| Posted: Tue Jul 09, 2002 2:58 pm Post subject: |
|
|
Novice
Joined: 06 Jul 2002
Posts: 17
|
Thanks for the suggestions.
I think putting the remote Queue Manager as part of the cluster is a good solution,
I didn't understand how is the clustering done in the example below, can you please explain it more clearly.
QM7, QM8 and QM9 in thier own clusters and how is it talking to QMC??
Thanks In Advance
Chandra Sekhar |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Wed Jul 10, 2002 12:27 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
You could have the remote qmgr in it's own cluster, that was what I was trying to tell. 
QM7-QM9 have their own clusters (with only one qmgr each), that is what the illustration should tell.
In Queue Manager Clusters manual ch9 task 8, there are a description of how to do it (interconnected cluster).
I think it would be a good idea haveing all repositories on QM1/QM3 as today, using namelists as described in the doc instead of having them spread. Before any other wakes up, ther might be some security tasks to take a look on, there have been some discusions on that topic, or take a look in the Cluster manual ch. 8. (Keeping clusters secure).
I've got both configurations running, and it works fine.
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| nimconsult |
| Posted: Wed Jul 10, 2002 2:51 am Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
My interpretation of Jorgen's answer is that:
QM7C includes QM7, QM1, QM3
QM8C includes QM8, QM1, QM3
QM9C includes QM9, QM1, QM3
(the clusters do not include only one qmgr as mentionned, but 3 in fact)
QM1 & QM3 hold the repositories of QMC and QM7-9C.
The queues of the cluster QMC must be also advertised in the clusters QM7-9C, both in QM1 and QM3.
This solution requires more administration but has the advantage of offering automatic fail-over as proposed built-in by MQ Series.
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Fri Jul 12, 2002 2:15 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
Well Nicolas,
You've got a point saying:
| Quote: |
My interpretation of Jorgen's answer is that:
QM7C includes QM7, QM1, QM3
QM8C includes QM8, QM1, QM3
QM9C includes QM9, QM1, QM3
(the clusters do not include only one qmgr as mentionned, but 3 in fact) |
So on QM1 and QM3 create a NAMELIST:
DEFINE NAMELIST(BIGCLUSTER) DESCR('List of cluster names') +
NAMES(QMC, QM7C, QM8C, QM9C)
Then alter QMGR REPOS(' ') REPOSNL(BIGCLUSTER) on QM1 & QM3.
Then alter CLUSRCVR to use the CLUSNL(BIGCLUSTER) CLUSTER(' ') on QM1 and QM3
Then alter CLUSSDR to use the CLUSNL(BIGCLUSTER) CLUSTER(' ') on QM1 and QM3 as in the stanza example below
when this is done, QM1 and QM3 will now host the full repos for all 4 clusters.
Then define CLUSRCVR(TO.QM7) CLUSTER(QM7C) on QM7
Then define CLUSSDR(TO.QM1) CLUSTER(QM7C) on QM7
repeat this for QM8 and QM9 aswell, (remember to do it in this order!)
Now we should have 4 clusters....
Now it's time to make the queue defs:
Define QLOCAL: QMQ CLUSTER(QMC) on QM2 and QM4
Define QALIAS: QMQ.GLOBAL TARGQ(QMQ) CLUSNL(BIGCLUSTER) on QM1 and QM3
Now you should be able to see QMQ.GLOBAL on QM7-QM9 and offcause on QM1-QM4,
but all the other queues on QM1-QM4 are not exposed
In the example below it's also posible t osend msgs to QM7-9 from QM2 and MQ4,
the major trick to get it working, is DEFBIND(NOTFIXED) on the ALIAS queues.
I hope this will help Chandra aswell
| Code: |
**** QM1 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL('BIGCLUSTER') +
FORCE
DEFINE QALIAS ('QMQ.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ') +
CLUSTER(' ') +
CLUSNL('BIGCLUSTER') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE QALIAS ('QMQ7.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ7') +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE QALIAS ('QMQ8.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ8') +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE QALIAS ('QMQ9.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ9') +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
BATCHINT(0) +
BATCHSZ(50) +
CLUSTER(' ') +
CLUSNL('BIGCLUSTER') +
CONNAME('ip_addr(1441)') +
CONVERT(NO) +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
BATCHINT(0) +
BATCHSZ(50) +
CLUSTER(' ') +
CLUSNL('BIGCLUSTER') +
CONNAME('ip_addr(1443)') +
CONVERT(NO) +
DESCR(' ') +
REPLACE
DEFINE NAMELIST ('BIGCLUSTER') REPLACE +
NAMES('QMC ', +
'QM7C ', +
'QM8C ', +
'QM9C ')
**** QM2 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL(' ') +
FORCE
DEFINE QLOCAL ('QMQ') +
SCOPE(QMGR) +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QMC') +
CLUSNL(' ') +
CONNAME('ip_addr(1441)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM2') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER('QMC') +
CLUSNL(' ') +
CONNAME('ip_addr(1442)') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QMC') +
CLUSNL(' ') +
CONNAME('ip_addr(1443)') +
REPLACE
DEFINE NAMELIST ('BIGCLUSTER') REPLACE +
NAMES('QMC ', +
'QM7C ', +
'QM8C ', +
'QM9C ')
**** QM3 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL('BIGCLUSTER') +
FORCE
DEFINE QALIAS ('QMQ.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ') +
CLUSTER(' ') +
CLUSNL('BIGCLUSTER') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE QALIAS ('QMQ7.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ7') +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE QALIAS ('QMQ8.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ8') +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE QALIAS ('QMQ9.GLOBAL') +
SCOPE(QMGR) +
TARGQ('QMQ9') +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER(' ') +
CLUSNL('BIGCLUSTER') +
CONNAME('ip_addr(1441)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER(' ') +
CLUSNL('BIGCLUSTER') +
CONNAME('ip_addr(1443)') +
DESCR(' ') +
REPLACE
DEFINE NAMELIST ('BIGCLUSTER') REPLACE +
NAMES('QMC ', +
'QM7C ', +
'QM8C ', +
'QM9C ')
**** QM4 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL(' ') +
FORCE
DEFINE QLOCAL ('QMQ') +
DESCR(' ') +
SCOPE(QMGR) +
CLUSTER('QMC') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QMC') +
CLUSNL(' ') +
CONNAME('ip_addr(1441)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QMC') +
CLUSNL(' ') +
CONNAME('ip_addr(1443)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM4') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER('QMC') +
CLUSNL(' ') +
CONNAME('ip_addr(1444)') +
DESCR(' ') +
REPLACE
**** QM7 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL(' ') +
FORCE
DEFINE QLOCAL ('QMQ7') +
DESCR(' ') +
SCOPE(QMGR) +
CLUSTER('QM7C') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QM7C') +
CLUSNL(' ') +
CONNAME('ip_addr(1441)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QM7C') +
CLUSNL(' ') +
CONNAME('ip_addr(1443)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM7') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER('QM7C') +
CLUSNL(' ') +
CONNAME('ip_addr(1447)') +
DESCR(' ') +
REPLACE
**** QM8 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL(' ') +
FORCE
DEFINE QLOCAL ('QMQ8') +
DESCR(' ') +
CLUSTER('QM8C') +
CLUSNL(' ') +
DEFBIND(NOTFIXED) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QM8C') +
CLUSNL(' ') +
CONNAME('ip_addr(1441)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QM8C') +
CLUSNL(' ') +
CONNAME('ip_addr(1443)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM8') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER('QM8C') +
CLUSNL(' ') +
CONNAME('ip_addr(1448)') +
DESCR(' ') +
REPLACE
**** QM9 ****
ALTER QMGR +
REPOS(' ') +
REPOSNL(' ') +
FORCE
DEFINE QLOCAL ('QMQ9') +
DESCR(' ') +
SCOPE(QMGR) +
CLUSTER('QM9C') +
CLUSNL(' ') +
DEFBIND(OPEN) +
REPLACE
DEFINE CHANNEL ('TO.QM1') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QM9C') +
CLUSNL(' ') +
CONNAME('ip_addr(1441)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM3') CHLTYPE(CLUSSDR) +
TRPTYPE(TCP) +
CLUSTER('QM9C') +
CLUSNL(' ') +
CONNAME('ip_addr(1443)') +
DESCR(' ') +
REPLACE
DEFINE CHANNEL ('TO.QM9') CHLTYPE(CLUSRCVR) +
TRPTYPE(TCP) +
CLUSTER('QM9C') +
CLUSNL(' ') +
CONNAME('ip_addr(1449)') +
DESCR(' ') +
REPLACE |
If you want the full stanzas for experiments, send me a private message or email.
Just my $0.02
_________________
Regards, Jørgen
Home of BlockIP2, the last free MQ Security exit ver. 3.00
Cert. on WMQ, WBIMB, SWIFT. |
|
| Back to top |
|
|
| oz1ccg |
| Posted: Sun Jul 14, 2002 3:24 am Post subject: |
|
|
Yatiri
Joined: 10 Feb 2002
Posts: 628
Location: Denmark
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
