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 » On MQ Clustering Design

Post new topic  Reply to topic Goto page 1, 2  Next
 On MQ Clustering Design « View previous topic :: View next topic » 
Author Message
mchan
PostPosted: Fri Sep 09, 2011 2:33 am    Post subject: On MQ Clustering Design Reply with quote

Apprentice

Joined: 09 Sep 2011
Posts: 29

Any hints or good references on how to design MQ with clustering? Or is there any sample of MQ cluster model or architecture to make reference?

We are building system which uses MQ to communicate between Java thick clients and application servers.

Some high-level requirement of the system are:
- scalable. Server side processing can be scaled up easily by adding machines, MQM, server application, ...
- fail-safe. Service can still be provided upon failure of single component, e.g. machine, MQM, application
- Java based (ie. JMS is used to interface with MQ)
- the queue file/data can be resided on SAN disk to share across different machine

I am thinking of setting up a number of MQMs across different machines in a cluster. Ideally, client and server applications, which will communicate via Request-Reply queue or Pub-sub would see the cluster as if there is only 1 MQM - 1 Queue/Topic. For the client/server, their only concern is the queue/topic to communicate, not which queue manager to connect. Is this possible?

For this point, from my initial thought, it looks fine for sender to see the cluster as 1 MQM as they only need to connect to one QM and the message will be sent to any one of the QM with the given queue.
However, as receiver can only get from the queue local to the QM they connect, they will need to connect to a specific QM in order to receive message. Thus, they don't see the cluster as one QM. How can this be solved / designed?

As well, Is Pub-Sub model feasible in MQ cluster architecture?

Thanks...
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Sep 09, 2011 2:44 am    Post subject: Reply with quote

Poobah

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

The WebSphere MQ Queue Manager Clusters manual would be an excellent place to start.

Pub/sub and clusters integrate nicely.

Quote:
However, as receiver can only get from the queue local to the QM they connect, they will need to connect to a specific QM in order to receive message. Thus, they don't see the cluster as one QM. How can this be solved / designed?

Clusters allow for continuous operation (not high-availability) by allowing for multiple consuming apps consuming messages from instances of the same queue name. This is working as designed and documented.

Clusters are used to move a message to a single instance of a queue known to the cluster. Pub/sub can move a message to many subscriber queues.

Applications connect to a specific qmgr, and have no knowledge of the cluster.
_________________
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
Vitor
PostPosted: Fri Sep 09, 2011 4:08 am    Post subject: Re: On MQ Clustering Design Reply with quote

Grand High Poobah

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

mchan wrote:
- the queue file/data can be resided on SAN disk to share across different machine


Don't confuse a WMQ cluster with any kind of high availability cluster. Any number of discussions in here about this; 2 separate queue managers in a WMQ cluster cannot use each other's file/data even via a SAN. But a queue manager which participates in a cluster can be protected from failure using HA software & SAN disk in the configuration of your choice.

mchan wrote:
Thus, they don't see the cluster as one QM.How can this be solved / designed?


What you need is a CCDT so that the connecting application makes a connection to a single "alias" and the 1st available queue manager in the CCDT responds. I understand this is now available for JMS under WMQv7; I'll wait for someone who knows Java to confirm or refute this understanding & comment on this or a better solution.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Sep 09, 2011 11:54 am    Post subject: Re: On MQ Clustering Design Reply with quote

Grand High Poobah

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

Vitor wrote:

What you need is a CCDT so that the connecting application makes a connection to a single "alias" and the 1st available queue manager in the CCDT responds. I understand this is now available for JMS under WMQv7; I'll wait for someone who knows Java to confirm or refute this understanding & comment on this or a better solution.

It has been available for JMS since MQ V6! V7 introduced weights on the connection algorithm (i.e. no longer the first available)
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Vitor
PostPosted: Fri Sep 09, 2011 12:00 pm    Post subject: Re: On MQ Clustering Design Reply with quote

Grand High Poobah

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

fjb_saper wrote:
Vitor wrote:

What you need is a CCDT so that the connecting application makes a connection to a single "alias" and the 1st available queue manager in the CCDT responds. I understand this is now available for JMS under WMQv7; I'll wait for someone who knows Java to confirm or refute this understanding & comment on this or a better solution.

It has been available for JMS since MQ V6! V7 introduced weights on the connection algorithm (i.e. no longer the first available)


This is why I'm never specific on Java questions. Especially on Fridays.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mchan
PostPosted: Sun Sep 11, 2011 5:53 pm    Post subject: Reply with quote

Apprentice

Joined: 09 Sep 2011
Posts: 29

Thanks a lot for your replies!

Just want to clarify my understanding a bit further before I drill down into details by reading the cluster manual, etc...

1) Using CCDT would faciliate receivers to see QM cluster as if it is one single MQM? Is it common for both sender and receiver app to connect to QM cluster via CCDT? Any performance impact?
In other words, will the sender/receiver app connect via CCDT to the cluster and do not need to care which MQM within the cluster they are connected to; and when one of the MQM fails, the sender/receiver app can still connect (to other MQM within the cluster) transparently without interruption?

2) "Clusters allow for continuous operation (not high-availability)" would mean using WMQ cluster the service level is far better that HA, right? i.e. as long as there is still QM up in the clusters, there should be no interruption of services?
Fyi, previous we are designing in a way (I don't know if it can be claimed as HA or not) where WMQ cluster is not used. We just have multiple MQMs, each sit on different machines. Normally, all MQMs are in used as program routes to the MQMs on different machines by routing logics. When one of MQM has problem, the MQM will be failed over/restarted in other machine (which hosts other MQM) and MQ app will switch to the new MQM on another machine for processing.

Thanks again!
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sun Sep 11, 2011 9:03 pm    Post subject: Reply with quote

Grand High Poobah

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

mchan wrote:
Thanks a lot for your replies!

Just want to clarify my understanding a bit further before I drill down into details by reading the cluster manual, etc...

1) Using CCDT would facilitate receivers to see QM cluster as if it is one single MQM? Is it common for both sender and receiver app to connect to QM cluster via CCDT? Any performance impact?
In other words, will the sender/receiver app connect via CCDT to the cluster and do not need to care which MQM within the cluster they are connected to; and when one of the MQM fails, the sender/receiver app can still connect (to other MQM within the cluster) transparently without interruption?

Not quite. It would certainly look seamless to a sender, however a receiver still can only receive messages from a queue that is local to the qmgr it is connected to. If you do request reply this may look completely seamless. If you receive stuff from different applications you would be impacted.

mchan wrote:
2) "Clusters allow for continuous operation (not high-availability)" would mean using WMQ cluster the service level is far better that HA, right? i.e. as long as there is still QM up in the clusters, there should be no interruption of services?
Fyi, previous we are designing in a way (I don't know if it can be claimed as HA or not) where WMQ cluster is not used. We just have multiple MQMs, each sit on different machines. Normally, all MQMs are in used as program routes to the MQMs on different machines by routing logics.

Thanks again!

No clusters do not allow for continuous operation. They allow for load balancing! This may look like allowing for continuous operations but the messages sent to a destination that is not "up" will not get processed like in HA.

mchan wrote:
When one of MQM has problem, the MQM will be failed over/restarted in other machine (which hosts other MQM) and MQ app will switch to the new MQM on another machine for processing.

This is the definition for a hardware cluster (HA) and has nothing to do with the MQ cluster. This guarantees uninterrupted processing... The failover should only introduce a delay for up to a few minutes max (1 to 2) and a lot less in financial sensitive environments...

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
mchan
PostPosted: Sun Sep 11, 2011 10:07 pm    Post subject: Reply with quote

Apprentice

Joined: 09 Sep 2011
Posts: 29

I am confused....

1) could you elaborate "If you do request reply this may look completely seamless."? Is it not practical of having receiver/server app both to see the MQM transparently as if it is a single MQM? And actually, what is the trend or the standard approach, e.g. for PTP request reply or pub-sub?

e.g. what I can think of for PTP request reply is:
a. client sending request message seamlessly to any of the MQM in the cluster, via the request queue
b. for each MQM with local queue instance for the given request queue, there are server application attached to receive request message. so, there request may arrive to any one of the server application, depending on load balancing
c. for server sending reply to client, how? server sends back the reply message via the same queue manager that it receives message from? but how can the client receive the reply message? does it need to specific the replyToQM (and replyToQ)? If client do this, it would have already chose the MQM (to send the request message) in the first place....

2) how does CCDT fit in the above picture?

3) what's the suggested MQ model / architecture that would provide both load balancing and high availability? combining WMQ cluster and HA?
Back to top
View user's profile Send private message
Vitor
PostPosted: Mon Sep 12, 2011 4:18 am    Post subject: Reply with quote

Grand High Poobah

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

mchan wrote:
Is it not practical of having receiver/server app both to see the MQM transparently as if it is a single MQM?


It's practicable given the restriction that if a receiver treats it's connection as a single queue manager, it must deal with the fact that replies it requested prior to fail & reconnect will never arrive (because they're physically on a different queue manager). For the same reason, your design must allow for this difference; either by accepting that some messges are "stuck" on a physical queue manager that has no connections or using HA to ensure no queue manager is ever down.

mchan wrote:
And actually, what is the trend or the standard approach, e.g. for PTP request reply or pub-sub?


There's no standard approach, nor are those 2 methods mutually exclusive.

mchan wrote:
does it need to specific the replyToQM (and replyToQ)? If client do this, it would have already chose the MQM (to send the request message) in the first place....


No it wouldn't. Any server application can service the request (as you correctly say) and would reply to the specific replyToQM & replyToQ included in the request. See my comment above about tolerating lost repsonses because the connected queue manager has changed.

mchan wrote:
2) how does CCDT fit in the above picture?


It's how all the applications obtain connections. Note there's no good reason why you can't use multiple CCDT in a single design or organisation to support different requirements.

mchan wrote:
combining WMQ cluster and HA?


Yes. WMQ clustering provides load balancing but no HA. HA software provides HA but no load balancing.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mchan
PostPosted: Thu Sep 22, 2011 1:20 am    Post subject: Reply with quote

Apprentice

Joined: 09 Sep 2011
Posts: 29

I further study the options from MQ V7 and notice there is feature called Queue Manager Group, for CCDT.
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzaf.doc%2Fcs12700_.htm

> Recapping my requirement with some revision as follow:

1. Scalable. Server side processing can be scaled up easily by adding machines, QM, server application, ...
2. Fail-safe. Service can still be provided upon failure of single component, e.g. machine, QM, application
3. Java based (ie. JMS is used to interface with MQ)
4. Assume MQ v7 is used for the whole architecture (no more v6)
5. The queue file/data can be resided on SAN disk to share across different machine
6. Client application are segregated into basic client and privileged client. Both types of client application have the same function but privileged client can enjoy better/faster response from server
7. There are also remote clients (e.g. client from different office, remote location). The performance of these clients should not be very sloe as compared with local client
8. Client session is sticky, they can login any server; however, after login, they need to talk to the same server as the states are kept there
9. In case the existing client connection with QM is broken, client will automatically connect with other QM (transparently) to re-establish a new session with new server

> I rethink about my MQ design/architecture and come up with the following design:

1. Multiple server machines are allocated for scalability and HA purpose
2. On each server, there will be one or more QM serving messaging request (e.g. Q1a, Q1b, Q2a, Q2b, … Qna, Qnb, assuming n machines, each with 2 QMs)
3. Corresponding to each QM, there is one associated server process to handle request from client via request and reply queues
4. The QM, the associated Qs (request & reply), and the server process are identical, in the sense that they do the same function. There are multiple of them within and across each servers for scalability purpose
5. All client will connect to the MQ via CCDT
6. Different Queue Manager Group will be defined in CCDT to group the QM within and across different server, depending on the requirement of client. E.g. for privileged client, they will connect to a QM group with more resources, e.g. more dedicated QMs that basic client, or higher CLNTWGHT parameter to higher performance server, etc.
7. Load balancing and availability is achieved via the CCDT and QM group
a. The client does not concern which specific QM to connect to
b. The traffic of the client is load balanced
c. Appropriate privilege can be provided to privilege client
d. In case one of the QM within the group is down, the client can use other QM by reconnection. This is also transparent to the client
8. As the client needed to be served by the same server that it logs on
a. The client session needed to be sticky – that means the client need to connect to the same QM and to the same server for subsequent message. This will be achieved by AFFINITY(PREFERRED) option in the CCDT?
b. Therefore, the load balancing applies only on session level (or upon first delivery of message), it is not per message basis
9. So, the expected flow will be
a. Client first connects to one of the QM in its QM group via CCDT (load balancing). E.g. QM2b. It will be one of the QM on one of the server machines
b. Client put request message on the request Q of QM2b
c. Server attached to the QM2b picks up the request message from local request Q of QM2b
d. After the server processes the request, the server put the reply message into the local reply Q of QM2b
e. <***QUESTION***> how does client get the reply message from local reply Q of QM2b, will stickness via the AFFINITY(PREFERRED) make sure the client also GET message from the same QM assign by QM group via CCDT (load balancing)? What if not? Any suggestion?
10. HA will be achieved by using HACMP with resource group including the QM, server process, and having the physical queue to shared disk

> Besides the <QUESTION> above, appreciate your help
1. Before I actually put resource to test it out, can you offer some comments? Will it work as I expected? Do you see any shortcoming or flaw?
2. Seems there is no longer a need for MQ cluster, as the load balancing is achieved via QM group in CCDT? If not, what is the value added of having MQ cluster? Can and how CCDT with QM group works with cluster? Or, any specific point to choose cluster over QM group in CCDT?
3. Is the approach ok to Java based implementation using JMS?
4. I can also think of other options for load balancing, e.g. assign multiple set of request-reply Qs and perform round-robin load balancing in application level. E.g. Client and server will communicate via one set of request-reply Q based on the routing logic (e.g. N set of QM and Qs for all clients. Request & reply message of client with User ID MOD N = 0 goes to QM0, =1 goes to QM1, etc). How does that compare with my design above?
5. Let’s say the above design is ok, how can I deal with remote client. Initially, I think about the HUB and SPOKEN approach, where there is a QM in the remote client site. Client application in remote client site will connect to its local QM via MQI call, and the message will be routed to the remote Q at our site via MQ-MQ communication. Can this work with the QM group of CCDT for load balancing? How?

Thanks a lot in advance!!!
Back to top
View user's profile Send private message
mqjeff
PostPosted: Thu Sep 22, 2011 1:31 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

QM Groups in the CCDT provide connection-time load-balancing. They are only used when you connect to the qmgr, which your app presumably only does once during it's lifetime - with caveats about failover conditions.

They do not provide message-level load balancing.

No form of load-balancing protects you from stuck messages. Using a QMgr group, if the reply message is on a queue and that queue mgr goes down, you will not have access to that reply message. likewise with a request message.

Your app needs to handle this case regardless of what you do with the qmgr infrastructure.

You should hire a consultant to spend a few days with you going through these various architectures and your actual requirements to ensure that you end up with the best solution.
Back to top
View user's profile Send private message
mchan
PostPosted: Sun Dec 18, 2011 10:41 pm    Post subject: Follow-up Help on CCDT v7 using JMS Reply with quote

Apprentice

Joined: 09 Sep 2011
Posts: 29

Using JMS and MQ7, once connection is routed by CCDT, if we created multiple JMS sessions from the JMS connection, is there any way to guarantee that the JMS sessions all connected to the same QM originally dispatched by the CCDT?
We tested this but found that the JMS session created from the JMS connection (connected via CCDT) actually connects to different QMs in the QM group....this is not our desired behavior. We only want the CCDT to decide the first QM via the JMS connection object. Any JMS session object spawn from the JMS connection should point to the same QM.

Appreciate your help!!!
(reposted to the JMS forum)
Back to top
View user's profile Send private message
vmcgloin
PostPosted: Mon Dec 19, 2011 1:27 am    Post subject: Reply with quote

Knight

Joined: 04 Apr 2002
Posts: 560
Location: Scotland

That should only be happening if the conenction is unsuccessful (I think). Is it possible that the connection is not changing but that you are putting to a clustered queue and your workload balancing is such that it does not stay local? By the way, there is no way that you can guarantee the same connection with the AFFINITY property - just the preferred qmgr to try first.
Back to top
View user's profile Send private message
mchan
PostPosted: Mon Dec 19, 2011 1:35 am    Post subject: Reply with quote

Apprentice

Joined: 09 Sep 2011
Posts: 29

Thanks for your reply.
- The connection to other QM on new session did happen if the connection is SUCCESSFUL
- we are not using any clustered queue
- we have tried preferred for the AFFINITY option. However, we find that even for different JVM within the same machine, it also connected to the same QM out of a number of available QMs within the QM group (i.e. it seems not load balancing by CCDT at all and stick to the same QM per JVMs on the same client machnine. I am actually expecting PREFER affinity option to stick on the same connection for sessions within same JVM process, not within same machine).[/quote]
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Mon Dec 19, 2011 6:01 am    Post subject: Reply with quote

Grand High Poobah

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

mchan wrote:
Thanks for your reply.
- The connection to other QM on new session did happen if the connection is SUCCESSFUL
- we are not using any clustered queue
- we have tried preferred for the AFFINITY option. However, we find that even for different JVM within the same machine, it also connected to the same QM out of a number of available QMs within the QM group (i.e. it seems not load balancing by CCDT at all and stick to the same QM per JVMs on the same client machnine. I am actually expecting PREFER affinity option to stick on the same connection for sessions within same JVM process, not within same machine).


I believe there is also a big difference in understanding here.
When you talk about a new session, are you talking about MDB session as in the max session attribute of the MDB(see MDB listener or Activation Spec) (i.e. MQ Connection) or a JMSSession derived from the same JMSConnection?
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » On MQ Clustering Design
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.