| Author |
Message
|
| jefflowrey |
 Posted: Fri Jul 29, 2005 10:01 am Post subject: |
 |
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If it's removed from the cluster, then it shouldn't be showing up on any of the FRs.
The definition on WEBSERVER01 is the correct definition for APPSERVER01? The UIDs match?
If so, then verify the channels from both Appserver01 to Webserver02 and between the FRs (both webservers).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
 |
| sysera |
| Posted: Fri Jul 29, 2005 10:18 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| jefflowrey wrote: |
If it's removed from the cluster, then it shouldn't be showing up on any of the FRs.
The definition on WEBSERVER01 is the correct definition for APPSERVER01? The UIDs match?
If so, then verify the channels from both Appserver01 to Webserver02 and between the FRs (both webservers). |
Yes, the definitions match, including the QMID's, so that's good.
I'm checking out the channel back to WEBSERVER02 out now, and comparing it to the channel on APPSERVER02 (which works correctly)
I'm noticing that on APPSERVER01 it seems normal, aside from the value of SSLCAUTH(REQUIRED) is set, where as on APPSERVER02 the setting for SSLCAUTH isn't even there, much less set to required. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 29, 2005 10:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
SSLCAUTH is only used if SSLCIPH is set. If SSLCIPH is blank, then SSLCAUTH is ignored.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sysera |
| Posted: Fri Jul 29, 2005 12:07 pm Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| jefflowrey wrote: |
| SSLCAUTH is only used if SSLCIPH is set. If SSLCIPH is blank, then SSLCAUTH is ignored. |
Gotcha. |
|
| Back to top |
|
|
| sysera |
| Posted: Mon Aug 01, 2005 6:21 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
So far I've been unable to resolve this alias queue issue. Over the weekend I wrote a new set of cluster definitions from the originals to build an APPLICATIONB cluster in order to do some further testing and to see if re-creating it from scratch would resolve the issue. I still get the unknown alias base q error when I try an amqsput to the alias queues on the application boxes.
Below are the definitions used to build the cluster, however, the hosts MUPRPAPP01 and MUPRPAPP02 are still unable to put messages to the queue alias of MYAPPLICATION.OUT which is local to MUPRPWEB01 and MUPRPWEB02.
So below I create an APP01 and an APP02, then I create WEB01 and WEB02 which are the cluster's full repositories.
If anyone could offer any suggestions that would be great. Maybe there is something here I am missing, I'm just not sure. Thanks.
(Note: APPLICATION is not the actual application name. It's just what I've changed it to for the purposes of making it public online and for testing.)
Application Servers
*** Create queue managers
/// On MUPRPAPP01
crtmqm DEGROUP1B
strmqm DEGROUP1B
runmqlsr -p 1515 -t tcp -m DEGROUP1B &
/// On MUPRPAPP02
crtmqm DEGROUP2B
strmqm DEGROUP2B
runmqlsr -p 1515 -t tcp -m DEGROUP2B &
runmqsc DEGROUP1B or DEGROUP2B
*** Define Dead Letter Queues ***
/// Dead letter queue for MUPRPAPP01
DEF QL (DL.MUPRPAPP01)
ALTER QMGR DEADQ (DL.MUPRPAPP01)
/// Dead letter queue for MUPRPAPP02
DEF QL (DL.MUPRPAPP02)
ALTER QMGR DEADQ (DL.MUPRPAPP02)
*** Define Local Queue ***
DEFINE QLOCAL (QL.MUPRPAPP.IN) DEFPSIST (YES) CLUSTER (APPLICATIONB) DESCR ('LOCAL QUEUE DECISION ENGINE IN')
*** Define Queue Alias ***
DEF QALIAS(MYAPPLICATION.OUT) TARGQ(QL.MUPRPWEB.OUT) CLUSTER(APPLICATIONB)
*** Define cluster communication channels
/// Define cluster communication channels for MUPRPAPP01
define channel(TO.APPLICATION2) chltype(CLUSRCVR) TRPTYPE(TCP) CONNAME('muprpweb02(1515)') CLUSTER(APPLICATIONB)
define channel(TO.APPLICATION1) chltype(CLUSSDR) TRPTYPE(TCP) CONNAME('muprpweb01(1515)') CLUSTER(APPLICATIONB)
/// Define cluster communication channels for MUPRPAPP02
define channel(TO.APPLICATION1) chltype(CLUSRCVR) TRPTYPE(TCP) CONNAME('muprpweb01(1515)') CLUSTER(APPLICATIONB)
define channel(TO.APPLICATION2) chltype(CLUSSDR) TRPTYPE(TCP) CONNAME('muprpweb02(1515)') CLUSTER(APPLICATIONB)
**** Name of the channel has changed from SYSTEM.ADMIN.DEQA to SYSTEM.ADMIN.DEPRP
*** Define communication channel Server ***
DEF CHANNEL(SYSTEM.ADMIN.DEPRP) +
CHLTYPE(SVRCONN)
end
*** Set permissions to queues and connection ***
/// Set permissions to queues and connection for MUPRPAPP01 ***
setmqaut -m DEGROUP1B -t queue -n MYAPPLICATION.OUT -p APPLICATION +put
setmqaut –m DEGROUP1B –t queue –n QL.MUPRPAPP.IN –p APPLICATION +get
setmqaut -m DEGROUP1B –t qmgr –p APPLICATION +connect
/// Set permissions to queues and connection for MUPRPAPP02 ***
setmqaut -m DEGROUP2B -t queue -n MYAPPLICATION.OUT -p APPLICATION +put
setmqaut –m DEGROUP2B –t queue –n QL.MUPRPAPP.IN –p APPLICATION +get
setmqaut -m DEGROUP2B –t qmgr –p APPLICATION +connect
Web Servers
*** Create queue managers
/// On MUPRPWEB01
crtmqm APPLICATION1B
strmqm APPLICATION1B
runmqlsr -p 1515 -t tcp -m APPLICATION1B &
/// On MUPRPWEB02
crtmqm APPLICATION2B
strmqm APPLICATION2B
runmqlsr -p 1515 -t tcp -m APPLICATION2B &
runmqsc APPLICATION1B or APPLICATION2B
*** Define Dead Letter Queues ***
/// Dead letter queue for MUPRPWEB01
DEF QL (DL.MUPRPWEB01)
ALTER QMGR DEADQ (DL.MUPRPWEB01)
/// Dead letter queue for MUPRPWEB02
DEF QL (DL.MUPRPWEB02)
ALTER QMGR DEADQ (DL.MUPRPWEB02)
*** Define Local Queue ***
DEFINE QLOCAL (QL.MUPRPWEB.OUT) DEFPSIST (YES) CLUSTER (APPLICATIONB) DESCR ('LOCAL QUEUE WEBSERVER OUT')
*** Define Queue Alias ***
DEF QALIAS(MYAPPLICATION.OUT) TARGQ(QL.MUPRPWEB.OUT) CLUSTER(APPLICATIONB)
*** Make this a full cluster repository
alter qmgr repos(APPLICATIONB)
*** Define cluster communication channels
/// Define cluster communication channels for MUPRPAPP01
define channel(TO.APPLICATION1) chltype(CLUSRCVR) TRPTYPE(TCP) CONNAME('muprpweb01(1515)') CLUSTER(APPLICATIONB)
define channel(TO.APPLICATION2) chltype(CLUSSDR) TRPTYPE(TCP) CONNAME('muprpweb02(1515)') CLUSTER(APPLICATIONB)
/// Define cluster communication channels for MUPRPAPP02
define channel(TO.APPLICATION2) chltype(CLUSRCVR) TRPTYPE(TCP) CONNAME('muprpweb02(1515)') CLUSTER(APPLICATIONB)
define channel(TO.APPLICATION1) chltype(CLUSSDR) TRPTYPE(TCP) CONNAME('muprpweb01(1515)') CLUSTER(APPLICATIONB)
**** Name of the channel has changed from SYSTEm.ADMIN.DEQA to SYSTEM.ADMIN.DEPRP
*** Define communication channel Server ***
DEF CHANNEL(SYSTEM.ADMIN.MPP) +
CHLTYPE(SVRCONN)
end
*** Set permissions to queues and connection ***
/// Set permissions to queues and connection for MUPRPWEB01 ***
setmqaut -m APPLICATION1B -t queue -n MYAPPLICATION.OUT -p APPLICATION +put +get
setmqaut -m APPLICATION1B -t queue -n QL.MUPRPWEB.OUT -p APPLICATION +put +get
setmqaut -m APPLICATION1B –t qmgr –p APPLICATION +connect
/// Set permissions to queues and connection for MUPRPWEB02 ***
setmqaut -m APPLICATION2B -t queue -n MYAPPLICATION.OUT -p APPLICATION +put +get
setmqaut -m APPLICATION2B -t queue -n QL.MUPRPWEB.OUT -p APPLICATION +put +get
setmqaut -m APPLICATION2B –t qmgr –p APPLICATION +connect |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Aug 01, 2005 6:41 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
i think your channels are wrong.
on the web servers define
on web1
clusrcvr to.web1 conname web1
clussdr to.web2 conname web2
on web2
clusrcvr to.web2 conname web2
clussdr to.web1 conname web1
on the application servers define
on app01
clusrcvr to.app01 conname app01
clussdr to.web1 conname web1
on app02
clusrcvr to.app02 conname app02
clussdr to.web1 conname web1
of course all channels need the cluster name. you should re-read this section in the manual.
fullrepositories should be connected "full", each to each.
partial repositories just need a cluster receiver pointing to themselves and a cluster sender pointing to one of the full repositores.
in your example, your cluster receivers on the app servers hold the conname of the full repositories, thats wrong.
i am in a little hurry right now, hope thats helps, if not others may explain in more detail or i will do tomnorrow.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| sysera |
| Posted: Mon Aug 01, 2005 7:26 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| Mr Butcher wrote: |
i think your channels are wrong.
on the web servers define
on web1
clusrcvr to.web1 conname web1
clussdr to.web2 conname web2
on web2
clusrcvr to.web2 conname web2
clussdr to.web1 conname web1
on the application servers define
on app01
clusrcvr to.app01 conname app01
clussdr to.web1 conname web1
on app02
clusrcvr to.app02 conname app02
clussdr to.web1 conname web1
of course all channels need the cluster name. you should re-read this section in the manual.
fullrepositories should be connected "full", each to each.
partial repositories just need a cluster receiver pointing to themselves and a cluster sender pointing to one of the full repositores.
in your example, your cluster receivers on the app servers hold the conname of the full repositories, thats wrong.
i am in a little hurry right now, hope thats helps, if not others may explain in more detail or i will do tomnorrow. |
That might be an issue with the channels. I'll go ahead and modify those and see if it fixes the issue. The script I'm using is not entirely mine, it was developed by someone else originally so I'm not 100% on it. Thanks. |
|
| Back to top |
|
|
| sysera |
| Posted: Mon Aug 01, 2005 7:40 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
The channel modifications seem to have done the trick on the new duplicate ClusterB.
Thanks a lot for the second set of eyes. This can be quite the task for one person who is new to it all.
Now let's see if I can get the production cluster into shape with the new knowledge.  |
|
| Back to top |
|
|
| sysera |
| Posted: Mon Aug 01, 2005 11:16 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| sysera wrote: |
The channel modifications seem to have done the trick on the new duplicate ClusterB.
Thanks a lot for the second set of eyes. This can be quite the task for one person who is new to it all.
Now let's see if I can get the production cluster into shape with the new knowledge. |
My Production cluster is back in business. Thanks to everyone for their help. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 01, 2005 11:29 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Shouldn't you define the qalias on the cluster from the same qmanager where you did the definition of the base queue to the cluster?
Don't you need to define the alias from each qmgr that carries an instance of the base in order to get round robin?
The other thing it might not like is definition order. I would make sure to define the base queue before defining the alias....
Enjoy  |
|
| Back to top |
|
|
| sysera |
| Posted: Mon Aug 01, 2005 2:15 pm Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| fjb_saper wrote: |
Shouldn't you define the qalias on the cluster from the same qmanager where you did the definition of the base queue to the cluster?
Don't you need to define the alias from each qmgr that carries an instance of the base in order to get round robin?
The other thing it might not like is definition order. I would make sure to define the base queue before defining the alias....
Enjoy |
If I understand you correctly, I defined the QL for the alias, then the alias on each repository. I then defined the queue alias to the queue alias on each repository on the application servers.
I did an amqsput to the queue alias on app01:
1
2
3
4
5
then on app02
6
7
8
9
10
Then a browse, and the first five ended up on the local queue on web01, and the second five on web02.
So it looks like things are happy right now. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Mon Aug 01, 2005 11:36 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
okay. we got the channels working, now lets work on the queues.
from your post you defined:
on app01 and app02
*** Define Queue Alias ***
DEF QALIAS(MYAPPLICATION.OUT) TARGQ(QL.MUPRPWEB.OUT) CLUSTER(APPLICATIONB)
on web01 and web02
*** Define Local Queue ***
DEFINE QLOCAL (QL.MUPRPWEB.OUT) DEFPSIST (YES) CLUSTER (APPLICATIONB) DESCR ('LOCAL QUEUE WEBSERVER OUT')
*** Define Queue Alias ***
DEF QALIAS(MYAPPLICATION.OUT) TARGQ(QL.MUPRPWEB.OUT) CLUSTER(APPLICATIONB)
this is somehow redundant. one of the benefits of a cluster is, that there is no need for a local defined queue to put at.
without cluster, at mqopen, the local queuemanager is checked for the queuename (or qmgrname) of the target queue, depending on open options. if neither is found a 2085 is returned. now, with clustering, there is an additional step in the naming resolution: the repository is asked if it knows the queue that is to be opened.
in your case, you do not need the MYAPPLICATION.OUT queues on the APP01 Servers, because it is known in the cluster. in your case, the queue is known 4 times in the cluster, 1 alias on every queuemanager. this is too much. get rid of the alias queues on the app servers. now, if you open the queue on app01, app01 ask one of the repositories and gets the information about the queue and will add this information to its partial repository. voila, and the queue can be used. thats the trick.
you may keep the alias if you like (e.g. for security checking), but it should not be in the cluster. you should then decide which queue on the web servers should be in the cluster (either the local or the alias), this is somehow a mix of alias and local queues on app and web with some/all in the cluster. its better to chose onle the alias and put that one into the cluster (on the target machine) and not on the putting machine(s)
putting the lokal queue (on the web servers) into the cluster too is also not required (if you use the alias to put)
you should also read about the DEFBIND parameter. there is some kine of a "default workload balancing" within the cluster (round robin), and the deefbind parameter controls whether a new target queue is selected on every put or on every open.
who is putting to QL.MUPRPAPP.IN that is on the app servers?
_________________
Regards, Butcher |
|
| Back to top |
|
|
| sysera |
| Posted: Tue Aug 02, 2005 4:22 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
I see what you mean about the alias overkill. This cluster was designed by someone else and I'm just kind of running with it. I just only had my first IBM MQ training last month so as you can imagine it's been a lot to catch up on.
So you're saying the alias being stored on Web01 and Web02 (and shared in the cluster) is enough for the other two app servers to find the alias queue name from the repositories and be able to put to it, without the need for the additional aliases on the app servers themselves? That seems reasonable.
I believe the webservers will be putting messages into the QL.MUPRPAPP.IN queues that are on each app server. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Tue Aug 02, 2005 4:29 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
| Quote: |
| So you're saying the alias being stored on Web01 and Web02 (and shared in the cluster) is enough for the other two app servers to find the alias queue name from the repositories and be able to put to it, without the need for the additional aliases on the app servers themselves? |
you got it!
| Quote: |
| I believe the webservers will be putting messages into the QL.MUPRPAPP.IN queues that are on each app server |
well, this works the same way without the need of additional alias queues on the web servers. they will know from their repositories.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| sysera |
| Posted: Tue Aug 02, 2005 4:34 am Post subject: |
|
|
Acolyte
Joined: 20 May 2005
Posts: 53
|
| Mr Butcher wrote: |
| Quote: |
| So you're saying the alias being stored on Web01 and Web02 (and shared in the cluster) is enough for the other two app servers to find the alias queue name from the repositories and be able to put to it, without the need for the additional aliases on the app servers themselves? |
you got it!
| Quote: |
| I believe the webservers will be putting messages into the QL.MUPRPAPP.IN queues that are on each app server |
well, this works the same way without the need of additional alias queues on the web servers. they will know from their repositories. |
Excellent information Mr B. I'm going to continue to work on refining this system a little bit. Better now than when it's in production.
Do you know if I were to continue to use the redundant aliases in my definitions if it would cause any negative impact? Performance, etc. Aside from just being redundant and goofy?  |
|
| Back to top |
|
|
|
|
