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 » CLUSSDRA status ?

Post new topic  Reply to topic Goto page 1, 2  Next
 CLUSSDRA status ? « View previous topic :: View next topic » 
Author Message
KIT_INC
PostPosted: Tue Nov 08, 2016 7:40 am    Post subject: CLUSSDRA status ? Reply with quote

Knight

Joined: 25 Aug 2006
Posts: 589

We are running MQ 75 and going to V8 soon.

We want to set up a cluster with some firewall restrictions. Here is the scenario

RQM1, RQM2 are full repos (FR) Qmgrs
CQM1,CQM2,CQM3......CQMx are partial repos (PR) Qmgrs

There is no firewall blocking between RQM1,RQM2 and all CQMx partial repos Qmgrs. This allows all PR Qmgrs to FR qmgrs and FR Qmgrs to PR Qmgrs

But we want to limit some side way communication (MQ traffic) between PR Qmgrs. For example there is a firewall rule to block communication between CQM1 and CQM2.

If I understand it correctly, MQ clustering will auto define a channel between CQM1 and CQM2 (CLUSSDRA) and also a CLUSSDRA between CQM2 and CQM1. These channel wil go into retry status until the long retry count is exhausted. Is that right ? and the retry will start again when ever CQM1 OR CQM2 is restarted. Is that the case. I know that this kind of blocking is probably not recommended. But it is being put in as a requirement. Just wondering if we should strongly oppose that or that should be OK ? I am just using CQM1 and CQM2 as the example here. Once we accepted that requirement, the firewall rule can be out between many Qmgrs.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Nov 08, 2016 8:22 am    Post subject: Re: CLUSSDRA status ? Reply with quote

Poobah

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

KIT_INC wrote:

But we want to limit some side way communication (MQ traffic) between PR Qmgrs. For example there is a firewall rule to block communication between CQM1 and CQM2.

Why do you want to limit MQ traffic? By 'limit' you mean 'prevent?' 'Limit' implies some threshold not to be exceeded.
_________________
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
exerk
PostPosted: Tue Nov 08, 2016 8:26 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

KIT_INC wrote:
But we want to limit some side way communication (MQ traffic) between PR Qmgrs. For example there is a firewall rule to block communication between CQM1 and CQM2...

Why would you want to do this? Isn't one of the points of a cluster to allow queue managers to dynamically connect to each other? Surely if you don't want one queue manager to connect to another you do not include them in the cluster? Sorry, but I cannot see any practical reason for wanting to do this.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Tue Nov 08, 2016 8:33 am    Post subject: Reply with quote

Poobah

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


_________________
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: Tue Nov 08, 2016 8:48 am    Post subject: Reply with quote

Grand High Poobah

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




What exactly is the requirement here? What is driving this requirement?

There may be other ways to meet the need.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mqjeff
PostPosted: Tue Nov 08, 2016 8:54 am    Post subject: Reply with quote

Grand Master

Joined: 25 Jun 2008
Posts: 17447

MQ Clusters form fully connected networks.

If you need to segment networks, then you need more than one cluster.

If you need to bridge between two clusters, you can either use an overlapping cluster, or a normal sender/receiver set of channels.
_________________
chmod -R ugo-wx /
Back to top
View user's profile Send private message
KIT_INC
PostPosted: Tue Nov 08, 2016 10:17 am    Post subject: Reply with quote

Knight

Joined: 25 Aug 2006
Posts: 589

I do not have all the details behind the reason for the requirement. The drive is coming mostly from the network side. Some of the Qmgrs in the clusters are in remote locations which has very limited bandwidth or very expensive network cost. We have 70% of Qmgrs such as the FR Qmgrs in locations that have no bandwidth or cost issue. 30% are in location that has bandwidth or cost issue. For those 30% money will be spending on connections to the FR qmgrs and to these 70%. and not on any connections between these 30% (that what I refer to as side way traffic). The proposed plan is to use firewall to block the traffic. From the surface, this sound like a reasonable request. I need to understand what's the impact to the MQ cluster if this requirement is accepted.
Back to top
View user's profile Send private message
Vitor
PostPosted: Tue Nov 08, 2016 10:49 am    Post subject: Reply with quote

Grand High Poobah

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

KIT_INC wrote:
From the surface, this sound like a reasonable request. I need to understand what's the impact to the MQ cluster if this requirement is accepted.


All the FR queue managers will periodically attempt to exchange data. Each PR will require a connection to at least one FR, and may need connection to the other if the cluster is to be resilient. If a PR needs to send a message to a queue hosted on another PR, it will spin up the needed channel. This channel will continue to exist until 90 days (27 days? Some long period of time) after the last message has flowed but like any triggered channel will start when a message needs to be sent and stop once the disconnect interval has expired.

If we assume that these "distant" queue managers don't get a lot of messages, set the disconnect interval appropriately. If you don't want them to get any messages, don't define them to the cluster.

I don't see why you'd use a firewall for this.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Nov 08, 2016 10:52 am    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

KIT_INC wrote:
...I need to understand what's the impact to the MQ cluster if this requirement is accepted.

The impact is that you won't have a fully functioning, fully interconnected cluster. IMHO, either your client needs to buy more bandwidth, or a different solution.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Tue Nov 08, 2016 2:07 pm    Post subject: Reply with quote

Grand High Poobah

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

Looks to me like you have a very hybrid environment
  1. A cluster with highly connected queue managers
  2. A hub and spoke design where you should define the HUB as a highly available cluster member and the spokes are the qmgrs with limited bandwidth availability


Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
gbaddeley
PostPosted: Tue Nov 08, 2016 2:51 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2492
Location: Melbourne, Australia

It is plausible to have a MQ cluster where n/w connectivity does not exist between all qmgrs (ie. they can't all resolve each others host name or have a path through firewalls). As already mentioned, there is a requirement all PR qmgrs have connectivity to/from the FR qmgrs. PRs will need to have connectivity to each other based on cluster queue messaging requirements.

However, this is not recommended. It is better to have multiple overlapping MQ clusters that each have full connectivity between all the member queue managers in each cluster. It is relatively easy to bridge MQ messaging interfaces between MQ clusters.
_________________
Glenn
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Nov 09, 2016 5:57 am    Post subject: Reply with quote

Grand High Poobah

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

I still think this is a hybrid scenario rather than overlapping clusters.
Picture this.

The cluster holds only the qmgrs on the "good" network. It also hosts the Hub queue manager. The Hub qmgr has an ALIAS for the cluster.

The spokes are not part of the cluster. They have a default transmit queue pointing to the HUB.

As such all spokes are able to talk to each other (through the HUB, or talk to the cluster PRs through the HUB). Now if the Hub uses clustered qmgr name resolution, all PR should also be able to talk to any of the spokes routing through the HUB.

Make the HUB a highly available queue manager (Multi-Instance or HA) and you have some resiliency built into the model...

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
KIT_INC
PostPosted: Wed Nov 09, 2016 10:38 am    Post subject: Reply with quote

Knight

Joined: 25 Aug 2006
Posts: 589

I think the hybrid solution is will fit us better. We bring that up in the next planning session. Let me confirm that I understand the hybrid solution suggested. The 70% Qmgrs with good n/w resource will be in a cluster. We will select a couple of Qmgrs from the 70% to act as hub and the rest of the 30% that has limited n/w resource will be spoke Qmgrs (i.e. using sdr/rcvr channels to the hub.
The original proposal with all Qmgrs in cluster to to take the advantage of reduce administration. With the hybrid, we will need to do additional work such as defining remote Qs.

Quote:
If a PR needs to send a message to a queue hosted on another PR, it will spin up the needed channel. This channel will continue to exist until 90 days (27 days? Some long period of time) after the last message has flowed but like any triggered channel will start when a message needs to be sent and stop once the disconnect interval has expired.



Going back to the original proposal of all Qmgrs in the cluster. I mentioned that money will be spent on connectivity to the FRs. So there will be no problem for the 30% Qmgrs communicating with the FR. We just do not want to spend the money on allowing this 30% Qmgrs to send message to each other (what I refer to as side way communication).
According to what is quoted. If we never initiate any message traffice between these 30% PR Qmgrs, the channel will not be spin up. Then it will not even get into retry mode.

So I think we are still OK to use this solution if no one likes the hybrid solution.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Wed Nov 09, 2016 11:26 am    Post subject: Reply with quote

Poobah

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

Seems a simpler solution:

On the PR, alter the cluster queue priority attributes so that the PR's instance of the application queue will be chosen only as a last-resort. This will result in fewer inbound messages going to that PR, and thus fewer replies outbound from the PR.
_________________
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
exerk
PostPosted: Wed Nov 09, 2016 12:04 pm    Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

KIT_INC wrote:
...We just do not want to spend the money on allowing this 30% Qmgrs to send message to each other (what I refer to as side way communication)...

Then what is the point of having them in the cluster?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » Clustering » CLUSSDRA status ?
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.