MQ clusters and distributed Queue concepts. AKA oil and water don't mix too well.

[Costa, D. (Damian)]

Hi all,
I was wondering if there is a way to mix MQ clusters and distributed qmgrs ( not in any clusters)
In other words is there a way to move data traffic from cluster queues into non cluster queues?

To my mind the issue here is the point to point nature of an MQ channel would mean the non cluster qmgr would only ever connect into a single entry point server in the MQ cluster. In this scenario the advantage of HA is lost if that specific node in the cluster is lost. The non cluster qmgr can no longer connect into the cluster as it has lost it's one and only link . Or does a sender channel have the ability to use a list of connection points to try in the event of a failure? Or is that built into the MQ clustering capabilities?

I'm asking because I see in my future questions of this nature becoming more important as high availability and scalability become critical factors for success of new projects.

Our entire MQ footprint does not contain clusters at all. I am therefore not entirely sure how one would go about phasing in the MQ clusters into an MQ network where all the apps are designed using local /client qmgrs only ie no clusters.

Also the question would apply to this scenario as well: We are currently trying to setup a gateway qmgr that would interface with the WWW (whole wide world.) the word cluster has not been mentioned yet but I suspect it will be. so if I have cluster queues being used to service external requests how would I transport those request to internal non clustered qmgrs/queues?


I hope I've described my scenario well enough for someone to offer (condolences, just kidding) some insight into what we're getting ourselves involved in .

Thanks.

********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Neil Casey]

Hi Damian,

this has been part of the cluster design capability from day 1.

The manuals have gradually gotten better about laying out the config needed for this capability, and the v7.5 manuals have some really nice info.

Have a look at
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.con.doc/q017600_.htm

Regards,

Neil Casey.

Post by Costa, D. (Damian)
Hi all,
I was wondering if there is a way to mix MQ clusters and distributed qmgrs ( not in any clusters)
In other words is there a way to move data traffic from cluster queues into non cluster queues?
To my mind the issue here is the point to point nature of an MQ channel would mean the non cluster qmgr would only ever connect into a single entry point server in the MQ cluster. In this scenario the advantage of HA is lost if that specific node in the cluster is lost. The non cluster qmgr can no longer connect into the cluster as it has lost it's one and only link . Or does a sender channel have the ability to use a list of connection points to try in the event of a failure? Or is that built into the MQ clustering capabilities?
I'm asking because I see in my future questions of this nature becoming more important as high availability and scalability become critical factors for success of new projects.
Our entire MQ footprint does not contain clusters at all. I am therefore not entirely sure how one would go about phasing in the MQ clusters into an MQ network where all the apps are designed using local /client qmgrs only ie no clusters.
Also the question would apply to this scenario as well: We are currently trying to setup a gateway qmgr that would interface with the WWW (whole wide world.) the word cluster has not been mentioned yet but I suspect it will be. so if I have cluster queues being used to service external requests how would I transport those request to internal non clustered qmgrs/queues?
I hope I've described my scenario well enough for someone to offer (condolences, just kidding) some insight into what we're getting ourselves involved in .
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays
the names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ]
This email is confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Bruce Lerner]

Cluster channels, like the non-clustered channels, are point-to-point. An
advantage of cluster-channels is that they will be created automatically as
needed between qmgrs that are part of the cluster.

WMQ clusters do not provide high availability (HA). Rather, clusters offer
reduced administration, along with workload balancing.

And, yes, you can connect cluster qmgrs to non-cluster qmgrs to provide a
gateway between them.

All of this is well documented.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[T.Rob]

I'd tweak that response just a bit. The High Availability presentation from
IBM at the conference for the last few years has included an awesome slide
showing how the combinations of various technologies contribute to WMQ HA.
The deck approaches HA from two different but related aspects:

1: Availability of the service to process new messages.
2: Availability of existing messages orphaned in an outage.

WMQ clusters do not address the orphaned message problem but definitely *do*
address the ability to keep the service active. For example, if a service
uses request messages that time out in a few seconds, having multiple
request queues in a cluster can make that service highly available. On the
other hand, traditional hardware clustering will not contribute to making
that service highly available since any in-flight messages will expire
before the failover can occur. Similarly, a service with multiple request
queues in the cluster can take a rolling outage to apply Fix Pacs without
ever becoming unavailable. This is definitely NOT disaster recovery. So if
it is not HA, then what is it? I think the answer is that WMQ clusters
definitely *are* part of the HA capabilities of the product, but it's
necessary to scope HA to include availability of the service instead of
merely availability of the messages in order to get to that answer.

-- T.Rob

-----Original Message-----
Behalf Of Bruce Lerner
Sent: Wednesday, October 02, 2013 10:49 AM
Subject: Re: MQ clusters and distributed Queue concepts. AKA oil and water
don't mix too well.
Cluster channels, like the non-clustered channels, are point-to-point. An
advantage of cluster-channels is that they will be created automatically as
needed between qmgrs that are part of the cluster.
WMQ clusters do not provide high availability (HA). Rather, clusters offer
reduced administration, along with workload balancing.
And, yes, you can connect cluster qmgrs to non-cluster qmgrs to provide a
gateway between them.
All of this is well documented.
the message body (not the subject), write: SIGNOFF MQSERIES Instructions
for managing your mailing list subscription are provided in the Listserv
General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Neil Casey]

Yep,

agree completely T.Rob. At my previous site, we considered the distinction so important that we named them separately.

High Availability referred to the individual messages… so hardware clusters, failover, MIQM type systems. (your point 2)

We used the term "Continuous Availability" to refer to the capability provided by an MQ cluster with multiple queue instances providing the same service. If one instance failed, then the cluster workload balancing would direct future requests to a different instance, so there was minimal disruption to ongoing service requests. (your point 1)

Regards,

Neil Casey

Post by T.Rob
I'd tweak that response just a bit. The High Availability presentation from
IBM at the conference for the last few years has included an awesome slide
showing how the combinations of various technologies contribute to WMQ HA.
1: Availability of the service to process new messages.
2: Availability of existing messages orphaned in an outage.
WMQ clusters do not address the orphaned message problem but definitely *do*
address the ability to keep the service active. For example, if a service
uses request messages that time out in a few seconds, having multiple
request queues in a cluster can make that service highly available. On the
other hand, traditional hardware clustering will not contribute to making
that service highly available since any in-flight messages will expire
before the failover can occur. Similarly, a service with multiple request
queues in the cluster can take a rolling outage to apply Fix Pacs without
ever becoming unavailable. This is definitely NOT disaster recovery. So if
it is not HA, then what is it? I think the answer is that WMQ clusters
definitely *are* part of the HA capabilities of the product, but it's
necessary to scope HA to include availability of the service instead of
merely availability of the messages in order to get to that answer.
-- T.Rob

-----Original Message-----
Behalf Of Bruce Lerner
Sent: Wednesday, October 02, 2013 10:49 AM
Subject: Re: MQ clusters and distributed Queue concepts. AKA oil and water
don't mix too well.
Cluster channels, like the non-clustered channels, are point-to-point. An
advantage of cluster-channels is that they will be created automatically

as

needed between qmgrs that are part of the cluster.
WMQ clusters do not provide high availability (HA). Rather, clusters

offer

reduced administration, along with workload balancing.
And, yes, you can connect cluster qmgrs to non-cluster qmgrs to provide a
gateway between them.
All of this is well documented.
the message body (not the subject), write: SIGNOFF MQSERIES Instructions
for managing your mailing list subscription are provided in the Listserv
General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

[Jack Arnold]

Should i be receiving these emails?

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,

[T.Rob]

Perhaps the bigger question is why have a QMgr that is *not* part of the
cluster?

The one use case that I can think of off the top of my head is that the QMgr
in question belongs to a 3rd party. Nearly all such interfaces that I've
seen use some kind of hardware cluster at that point to make those SDR/RQSTR
pairs highly available. The next most common design I've seen is to use two
stand-alone QMgrs there. Internally, they are part of the cluster.
Externally, they use SDR/RQSTR pairs. Since those QMgrs *never* host
application queues, they can both route messages to the other side. It's
even possible with a bit of instrumentation to cause those two to
dynamically point their channels at different IP addresses or QMgrs.

The transition from P2P channels to clustered channels is seamless. You can
create in a cluster all the same topologies that you can create with P2P
channels. The reverse is not true but that's not a problem when migrating
*to* clusters. Take any P2P network, cluster all its nodes together and
blank out the XMitQ attribute of any QRemotes. You are nor 99% done. You
may need to redefine the odd QMgr alias but that's it.

On the QMgr open to the Whole Wide World, I'd be *very* interested to see
that setup. Clients? Remote QMgrs? Authenticated or anonymous?

-- T.Rob

-----Original Message-----
Behalf Of Costa, D. (Damian)
Sent: Wednesday, October 02, 2013 8:43 AM
Subject: MQ clusters and distributed Queue concepts. AKA oil and water
don't mix too well.
Hi all,
I was wondering if there is a way to mix MQ clusters and distributed

qmgrs

( not in any clusters) In other words is there a way to move data traffic

from

cluster queues into non cluster queues?
To my mind the issue here is the point to point nature of an MQ channel
would mean the non cluster qmgr would only ever connect into a single
entry point server in the MQ cluster. In this scenario the advantage of

HA

is lost if that specific node in the cluster is lost. The non cluster qmgr

can no

longer connect into the cluster as it has lost it's one and only link . Or

does

a sender channel have the ability to use a list of connection points to

try in

the event of a failure? Or is that built into the MQ clustering

capabilities?

I'm asking because I see in my future questions of this nature becoming
more important as high availability and scalability become critical

factors

for success of new projects.
Our entire MQ footprint does not contain clusters at all. I am therefore

not

entirely sure how one would go about phasing in the MQ clusters into an
MQ network where all the apps are designed using local /client qmgrs only
ie no clusters.
Also the question would apply to this scenario as well: We are currently
trying to setup a gateway qmgr that would interface with the WWW (whole
wide world.) the word cluster has not been mentioned yet but I suspect

it

will be. so if I have cluster queues being used to service external

requests

how would I transport those request to internal non clustered
qmgrs/queues?
I hope I've described my scenario well enough for someone to offer
(condolences, just kidding) some insight into what we're getting ourselves
involved in .
Thanks.
********************
Nedbank Limited Reg No 1951/000009/06. The following link displays the
names of the Nedbank Board of Directors and Company Secretary.
[ http://www.nedbank.co.za/terms/DirectorsNedbank.htm ] This email is
confidential and is intended for the addressee only.
The following link will take you to Nedbank's legal notice.
[ http://www.nedbank.co.za/terms/EmailDisclaimer.htm ]
********************
the message body (not the subject), write: SIGNOFF MQSERIES Instructions
for managing your mailing list subscription are provided in the Listserv
General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES