ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Clustering and distributed queueing

Post new topic  Reply to topic
 Clustering and distributed queueing « View previous topic :: View next topic » 
Author Message
HenriqueS
PostPosted: Wed Jul 08, 2009 8:57 pm    Post subject: Clustering and distributed queueing Reply with quote

Master

Joined: 22 Sep 2006
Posts: 235

Hello,

We have a new app here that will run under two J2EE servers and for the users it will look as a single application (I am not really the guy on this subject). Each server may have it´s own queue manager. Let´s call them respectively as ServerA-QM1 and ServerB-QM2.

Well, I have to provide the MQ infrastructure for the application. The app needs to write to a remote def queue to reach another server (this server is a single instance). In this server there is an app consuming the messages from a local receiver queue and providing answers for them. This server also generate new messages that are not replies. Lets call the queue manager laying here as ServerC-QM3.

We already have a simple setup working on the development/test environment but in this case it is a one-to-one topology. Since now we are putting this live, I wanted to consider using the clustering technique. But I have a few questions:

1) For the cluster:
1.1) All queue managers need to be under my administration? What about if ServerC-QM3 is from a business partner that is located somewhere in a WAN? It needs to be brought into the cluster?

1.2) Can I have ServerA-QM1 and ServerB-QM2 clustered, tell both application instances to look on a client channel table def to use the first available QM and from QM1 and QM2 configure regular sender and receiver channel to QM3? (I guess this is a weird setup, but I wanted to avoid QM3 on the cluster and still be able to send to QM3 from QM1/QM2 - mixing clustering and DQM - AFAIK this is not possible).

2) I also considered, on a first stage, point both J2EE servers to talk only to one QM (QM1 or QM2), but then I will loose resiliency here. If Server-A comes down, QM1 will be unavailable and if it is the configured one to be used, the application instance laying on Server-B will not be able to put messages to the remote queue def that exists on Server-A.

2.1) Could I let both QM1 and QM2 running, having each app instance talk to its respective queue mgr/remote queue def and communicate with QM3 in a way that I end up writing in a single queue located on ServerC? And when ServerC writes back a reply or a new message, it should be routed specifically to particular queue manager (QM1 or QM2)? Is this sort of 'Y' topology possible to setup with DQM ?

Any ideas?
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Jul 08, 2009 10:34 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Quote:
1) For the cluster:
1.1) All queue managers need to be under my administration? What about if ServerC-QM3 is from a business partner that is located somewhere in a WAN? It needs to be brought into the cluster?

It would be preferable but you can have a non clustered qmgr connect p2p into the cluster. Look it up in the cluster manual.
Quote:
1.2) Can I have ServerA-QM1 and ServerB-QM2 clustered, tell both application instances to look on a client channel table def to use the first available QM and from QM1 and QM2 configure regular sender and receiver channel to QM3? (I guess this is a weird setup, but I wanted to avoid QM3 on the cluster and still be able to send to QM3 from QM1/QM2 - mixing clustering and DQM - AFAIK this is not possible).
So possible. Look up my response to 1.1)... have fun the cluster manual.
Quote:
2) I also considered, on a first stage, point both J2EE servers to talk only to one QM (QM1 or QM2), but then I will loose resiliency here. If Server-A comes down, QM1 will be unavailable and if it is the configured one to be used, the application instance laying on Server-B will not be able to put messages to the remote queue def that exists on Server-A.
Not a good fit. You have demonstrated more brilliant ideas, keep with them.
Quote:
2.1) Could I let both QM1 and QM2 running, having each app instance talk to its respective queue mgr/remote queue def and communicate with QM3 in a way that I end up writing in a single queue located on ServerC? And when ServerC writes back a reply or a new message, it should be routed specifically to particular queue manager (QM1 or QM2)? Is this sort of 'Y' topology possible to setup with DQM ?
It's called a request response pattern and is described in the manuals (programing manual )

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Wed Jul 08, 2009 11:52 pm    Post subject: Re: Clustering and distributed queueing Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

HenriqueS wrote:
1.1) All queue managers need to be under my administration? What about if ServerC-QM3 is from a business partner that is located somewhere in a WAN? It needs to be brought into the cluster?


Having all the queue managers under your administration is desirable from a problem solving perspective, but isn't necessary. All you need to ensure is that the cluster is configured such that all the required queue managers are allowed to join it. Odds are the cluster is currently unsecured so any queue manager can join, securing the cluster is described in the cluster manaual.

HenriqueS wrote:
1.2) Can I have ServerA-QM1 and ServerB-QM2 clustered, tell both application instances to look on a client channel table def to use the first available QM and from QM1 and QM2 configure regular sender and receiver channel to QM3? (I guess this is a weird setup, but I wanted to avoid QM3 on the cluster and still be able to send to QM3 from QM1/QM2 - mixing clustering and DQM - AFAIK this is not possible).


Possible and occassionally desirable. Do not make the common mistake of mixing client connections and clustering; these are 2 separate things. First configure a CCDT to select the first available qmgr as you describe, then decide how the messages being put get where they're going. In the situation you describe, if QM1 & QM2 are in a cluster with QM3 (where the target cluster queue is hosted) it will all sort itself out. Remember clusters don't use remote queue definitions, only p2p setups do.

HenriqueS wrote:
2) I also considered, on a first stage, point both J2EE servers to talk only to one QM (QM1 or QM2), but then I will loose resiliency here. If Server-A comes down, QM1 will be unavailable and if it is the configured one to be used, the application instance laying on Server-B will not be able to put messages to the remote queue def that exists on Server-A.


Bad idea. Also see above regarding "no remote queue defs in clusters"

HenriqueS wrote:
2.1) Could I let both QM1 and QM2 running, having each app instance talk to its respective queue mgr/remote queue def and communicate with QM3 in a way that I end up writing in a single queue located on ServerC?


This is exactly what clusters do - spend more time with the clusters manual. Don't stop reading until you understand why there are no remote queue definitions in a cluster.

[quote="HenriqueS"] And when ServerC writes back a reply or a new message, it should be routed specifically to particular queue manager (QM1 or QM2)? Is this sort of 'Y' topology possible to setup with DQM ?/quote]

You don't need DQM for this, providing the reply message is properly addressed by the replying application. The cluster will sort it out for you.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
HenriqueS
PostPosted: Thu Jul 09, 2009 3:06 pm    Post subject: My tests so far... Reply with quote

Master

Joined: 22 Sep 2006
Posts: 235

Folks,

Thanks for the feedback.

First of all, I want to say that I mixed a bit my wishes here.

Right now I have 2 needs, but only one is for short-term implementation. The another one I can research for the next months with no hurry. So I am sorry for confusing.

1st need) Provide some failover for a 'Y' setup, where 2 J2ee servers (application 'X') running along with a queue manager will comunicate within a single server (application 'Z') that has MQ and an application that receives and sends messages to these 2 J2ee servers.

2nd need) Research the possibility of switching from a DQM topology to clustering, in which my company in the central hub, with more than 100 partners, in a context that they only may have access to particular queues.

Só let´s talk about the 1st need
--------------------------------

I´ve been reading and playing with the 'Queue Managers Clusters' book. I´ve got so far around the Chapter 4 ('How queue manager clusters work').

I´ve tried the following setup and it seemed to work reasonably well, but I am writing it here so you guys may point some weakness on it.

1) Setup 2 full repositories on each queue manager coupled with the J2ee servers.

1.1) On each full repo qmgr, create a QLocal called 'Z.to.X', persistent. I created the same qlocal cluster queue on each full repo so I could GET messages from whoever is available, the book does not mention it, but I found strange to have 2 full repos and if one of them gets unavailable and it is the one which had the qlocal defined, I would not be able to pull anything else from the other one. Is this approach right?

2) Setup 1 partial repository on the on the single server

2.1) On this partial repo qmgr, create a Qlocal called 'X.to.Z', persistent.

3) Create the proper explicit Cluster-Sender and Cluster-Receiver channels between Server1 (J2ee), Server2 (J2ee). Create an explicit Cluster-Sender/Receiver between Server2 (J2ee) and the 'Single Server'. There is no need to create cluster channels between 'Single-Server' and Server1 (J2ee) since this is one of the MQ clustering features.

4) I did some amqsput/get tests and:

4.1) I can put on any qmgr in any of the 'published' cluster queues.

4.2) I cannot get on get qmgr servers that are not the ones I originally created the cluster queue.

5) When I stop one of the Server1/Server2 queue managers, My application 'X' can still point to the other one (CDDT will help to make this automatic) and the PUTted messages will reach the Single Server and consequently its 'Z' Application. OK.

5.1) Still, with one of Server1/Server2 queue managers down, my 'Z' application can send messages without problem to the 'X' application, since the available queue manager (Server1 or Server2 qmgr) will receive messages from the 'Z.to.X' queue.

5.2) I noticed that all messages PUTted on Z.to.X (Single Server to Server1/Server2) are nicely spread in some round-robin manner on the destination, no duplicates were found on the two cluster queues sitting on Server1 and Server2 qmgrs. We have message retention if a specific qmgr goes down, but as soon the qmgr goes back to normal the messages will be there for retrieval.

6) Weakness found: surely, the 'Single Server', which runs Application 'Z' is a single point of failure, but for this we will be dealing with an active-passive setup in the next months. No big deal right now.

Any comment?
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Jul 09, 2009 11:08 pm    Post subject: Re: My tests so far... Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

HenriqueS wrote:
I found strange to have 2 full repos and if one of them gets unavailable and it is the one which had the qlocal defined, I would not be able to pull anything else from the other one. Is this approach right?


If you look at a recent discussion (yesterday I think) in this section, you'll see a detailed discussion of this "stranded message" problem. It's the key reason WMQ clusters are unsuitible for HA solutions as the messages on the downed queue manager are inaccessable.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Jul 10, 2009 11:44 am    Post subject: Re: My tests so far... Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Vitor wrote:
If you look at a recent discussion (yesterday I think) in this section, you'll see a detailed discussion of this "stranded message" problem. It's the key reason WMQ clusters are unsuitible for HA solutions as the messages on the downed queue manager are inaccessable.


Just to clarify...MQ Clustering is very suitable with H.A. solutions. MQ Clustering is not a H.A. solution by itself.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Vitor
PostPosted: Fri Jul 10, 2009 11:57 am    Post subject: Re: My tests so far... Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA

PeterPotkay wrote:
Vitor wrote:
If you look at a recent discussion (yesterday I think) in this section, you'll see a detailed discussion of this "stranded message" problem. It's the key reason WMQ clusters are unsuitible for HA solutions as the messages on the downed queue manager are inaccessable.


Just to clarify...MQ Clustering is very suitable with H.A. solutions. MQ Clustering is not a H.A. solution by itself.




I should perhaps have said "WMQ clusters are unsuitible as HA solutions"
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jul 10, 2009 1:43 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

Quote:
HenriqueS wrote:
I found strange to have 2 full repos and if one of them gets unavailable and it is the one which had the qlocal defined, I would not be able to pull anything else from the other one. Is this approach right?

First, if a qmgr is unavailable (like shut down), then all of its objects are likewise unavailable; and messages in these queues are stranded until the qmgr is restarted. This has nothing to do with clustering.

Clustering is not replication or queue-sharing. Clustering offers multiple queues with the same name hosted by different qmgrs - all of which are capable of processing the application messages.

The decision as to which of the cluster queues to open and put the message takes place at MQOPEN or MQPUT1.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
HenriqueS
PostPosted: Fri Jul 10, 2009 2:27 pm    Post subject: Reply with quote

Master

Joined: 22 Sep 2006
Posts: 235

Thnaks for the excelent feedback folks,

I noticed some clustering benefits and some of its odds (which are quite predictable), but for me its looks a nice solution for intra-business integration, inside my own organization. Is this concept right?

Try to use clustering instead of DMQ to integrate different business partners seems to arise several security and administration issues, what demands using Exits and customizing the OAM, is this right?

Like, how to controle a business partner to put to a file where it is not allowed to? With DQM you can pre-define this using remote queue definitions by example...on a cluster things seem to be 'for anyone'.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jul 10, 2009 2:39 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

DQM and mq clustering both use point-to-point channels; so there are security issues with channels with both.

In chapter one of the WMQ Clusters manual there is a short narrative of the benefits of clustering. For sysadmins, the benefit is reduced admin; for applications, the benefit is workload distribution - same queue name on multiple qmgrs. Please read this manual to get a better understanding of what clusters can do for you.

A qmgr can be both a member of a cluster (FR or PR), and have DQM (private) point-to-point channels.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
HenriqueS
PostPosted: Fri Jul 10, 2009 3:18 pm    Post subject: Reply with quote

Master

Joined: 22 Sep 2006
Posts: 235

bruce2359 wrote:
DQM and mq clustering both use point-to-point channels; so there are security issues with channels with both.


I got your other points. But specifically about the sentence above...

If a partner connects to me using an specific sender/receiver channel pair (DQM), it won´t be able to do all sorts of MQ calls to me, right? Mainly because a sender channel is just a transport agent, way different than connecting directly to my queue manager through a client or server connection. Also, he will have access only to the queues I has remote queue definitions created and using OAM I can force this situation, pushing the right authorizations to the MCA user defined in the receiver channel that I have within him.

Otherwise, in a cluster environment he is going to have access to the whole set of MQI calls to all queues 'published' in the cluster. It´s almost like him having full access to all queues I did publish on the cluster, except GETing from these queues that I published.

Now think about a 2nd partner that just entered on the cluster, how I will avoid him to put messages on the queue I designated only my 1st partner to put? Again I need to deal with OAM/MCAUSER on the cluster-receiver channels that I have established with this guys.

So, since I establish only ONE cluster-receiver channel (the whole idea of simplifying using cluster), I need to figure out how to set INDIVIDUALLY these user/queue authorizations. I´ve read a bit about the PUTAUT attribute, so I will investigate it further.


Last edited by HenriqueS on Fri Jul 10, 2009 3:36 pm; edited 1 time in total
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jul 10, 2009 3:28 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

Quote:
If a partner connects to me using an specific sender/receiver channel pair (DQM), it won´t be able to do all sorts of MQ calls to me, right? Mainly because a sender channel is just a transport agent, way different than connecting directly to my queue manager through a client or server connection.

By partner, do you mean qmgr partner? Qmgrs connect to each other with sender/receiver channels. Client-bindings applications MQCONNect to qmgrs via SVRCONN channels. Server-bindings (cross-memory) applications MQCONNect to a qmgr in the same o/s instance as the qmgr.

Quote:
Otherwise, in a cluster environment he is gong to have access to the whole set of MQI calls to all queues 'published' in the cluster. It´s almost like him having right to all queues I did publish on the cluster, except GETing from these queues that I published.

Once MQCONNected to a qmgr (client- or server-bindings), the app has access to all MQ calls - authorized by OAM rules.

Quote:
Now think about a 2nd partner, how I will avoid him to put messages on the queue I designated only my 1st partner to put? I far I read on the WMQ cluster manual, you have to deal with OAM and Exits to workaround this sort of situation...

Security is local to the qmgr. A message that flows from one qmgr to another will have authority based on RCVR channel attributes such as MCAUSER.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
HenriqueS
PostPosted: Fri Jul 10, 2009 3:51 pm    Post subject: Reply with quote

Master

Joined: 22 Sep 2006
Posts: 235

bruce2359 wrote:
Quote:
If a partner connects to me using an specific sender/receiver channel pair (DQM), it won´t be able to do all sorts of MQ calls to me, right? Mainly because a sender channel is just a transport agent, way different than connecting directly to my queue manager through a client or server connection.

By partner, do you mean qmgr partner? Qmgrs connect to each other with sender/receiver channels. Client-bindings applications MQCONNect to qmgrs via SVRCONN channels. Server-bindings (cross-memory) applications MQCONNect to a qmgr in the same o/s instance as the qmgr.


Yes. I mean a partner running another qmgr. Agreed.

Quote:

Quote:
Otherwise, in a cluster environment he is gong to have access to the whole set of MQI calls to all queues 'published' in the cluster. It´s almost like him having right to all queues I did publish on the cluster, except GETing from these queues that I published.

Once MQCONNected to a qmgr (client- or server-bindings), the app has access to all MQ calls - authorized by OAM rules.


Agreed. The issue with a cluster is that all qmgrs that make part of it look like one logical entity. So a partner connecting to his clustered qmgr is like issuing an MQCONN against my clustered qmgr. That´s were my safety worries show up.

Quote:

Quote:
Now think about a 2nd partner, how I will avoid him to put messages on the queue I designated only my 1st partner to put? I far I read on the WMQ cluster manual, you have to deal with OAM and Exits to workaround this sort of situation...

Security is local to the qmgr. A message that flows from one qmgr to another will have authority based on RCVR channel attributes such as MCAUSER.


Agreed. But since we are dealing with an unique cluster-receiver channel, I did read that I must go after this PUTAUT attribute to see how to customize cluster-queue authorizations and be able to give different authorizations to different partners.

Funny, I think I was re-editing my message and you got it 'in the air', I was trying to make it look clear.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Jul 10, 2009 4:43 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.

Quote:
The issue with a cluster is that all qmgrs that make part of it look like one logical entity. So a partner connecting to his clustered qmgr is like issuing an MQCONN against my clustered qmgr. That´s were my safety worries show up.

No. When an app MQCONNects, it connects ot one qmgr. Security rules (OAM or whatever) dictate what objects that app can access - be they clustered objects or not. Again, security is local to the qmgr that the app connects to, NOT other qmgrs across the network.
Quote:
But since we are dealing with an unique cluster-receiver channel, I did read that I must go after this PUTAUT attribute to see how to customize cluster-queue authorizations and be able to give different authorizations to different partners.

Messages flow on channels. Messages do not take on the identity of a partner qmgr. Usually, but not always, the message takes on the identity of the logged on user that ran the application that created the message. Security at the receiver end dictates under what authority the receiving end MCA MQOPENs and MQPUTs the inbound message to the destination queue (or DLQ).

Quote:
I did read that I must go after this PUTAUT attribute ...

When you quote from a reference, provide the URL or document number.

I'd suggest that you read the appropriate portions of the WMQ Intercommunications manual that describes channel attributes and what they do.

Some of your assumptions about WMQ illustrate that you need to start with some fundamentals, as provided in: WebSphere MQ v6 Fundamentals http://www.redbooks.ibm.com/abstracts/sg247128.html
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Sat Jul 11, 2009 5:05 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

Mixing clusters between companies makes security challenging. If the other guy is not using Q Aliases and allowing his apps only to put to those, he is allowing all his apps full access to his SYSTEM.CLUSTER.TRANSMIT.QUEUE, and thus full access to your entire cluster. You can/should mitigate this by running your CLUSRCVR channels with a MCAUSER filled in, and at the very least take away the ability of that MCAUSER from being able to put to the SYSTEM.ADMIN.COMMAND.QUEUE and any INIT queues, unless you like people administrating your QMs remotely or telling your trigger monitors to do crazy things.

PUTAUT - waste of time on non z/OS systems, and maybe there too. It assumes you trust every possible user in your MQ system to be honest, always use their real ID, and never ever try to impersonate another ID, like, say, mqm. Meanwhile you waste an incredible amount of time trying to keep all the legitimate IDs properly authorized.

Ideally, you let the other company's cluster talk to your cluster with regular point to point channels. The QM you allow them to connect to, the "Gateway" should be made highly available with hardware clustering. It can then load balance the messages into your cluster, and catch the replies to forward back to their cluster. This is much easier to secure properly. Its is much easier to admin versus overlapping clusters spanning 2 or more different networks, or even 1 cluster spanning the networks.
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » Clustering » Clustering and distributed queueing
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.