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 IndexClusteringclustering across multiple data centers

Post new topicReply to topic Goto page 1, 2  Next
clustering across multiple data centers View previous topic :: View next topic
Author Message
mq__quest
PostPosted: Mon Aug 21, 2017 7:40 pm Post subject: clustering across multiple data centers Reply with quote

Novice

Joined: 21 Aug 2017
Posts: 14

Is building a MQ cluster across 2 data centers a good idea?
could there be network and latency issues?
Back to top
View user's profile Send private message
exerk
PostPosted: Tue Aug 22, 2017 12:42 am Post subject: Re: clustering across multiple data centers Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5778

mq__quest wrote:
Is building a MQ cluster across 2 data centers a good idea?

It depends on your requirements and the geographical separation...

mq__quest wrote:
could there be network and latency issues?

...and this is a question for your networks people.
_________________
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
Vitor
PostPosted: Tue Aug 22, 2017 5:18 am Post subject: Re: clustering across multiple data centers Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24775
Location: Ohio, USA

mq__quest wrote:
Is building a MQ cluster across 2 data centers a good idea?


Only if you need to balance messages across the 2 data centers or want to use centralized administration; i.e. the reasons you use an MQ cluster.

mq__quest wrote:
could there be network and latency issues?


No, networks are magic and the electrons/photons moving down them are not subject to the laws of physics.

Of course there's going to be network and latency issues unless your company has done something really odd like putting them next to each other. If they're positioned for DR resiliency they're possibly a good distance apart, if they're positioned to service 2 different geographic regions they could be on other sides of the planet.

As my worthy associate correctly points out, speak to your network people. Even if the data centers are geographically close, they may not want MQ chatting over the link synchronizing full repositories if (for example) they're using the link to perform near real time bidirectional database replication between the 2 sites.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mq__quest
PostPosted: Wed Feb 21, 2018 9:09 pm Post subject: Reply with quote

Novice

Joined: 21 Aug 2017
Posts: 14

Thanks for your replies vitor and exerk.
Lets say the DCs are about 100 miles apart and the network guys are ok with it.
In this scenario , is it a good idea to have a cluster across the dcs.
And is it a good idea to have an app in one dc connect (client bidings) to the qmgr in the other dc?
Back to top
View user's profile Send private message
exerk
PostPosted: Thu Feb 22, 2018 12:26 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 5778

mq__quest wrote:
...In this scenario , is it a good idea to have a cluster across the dcs...

As stated by my most worthy associate, at least two good reasons are listed above...

mq__quest wrote:
...And is it a good idea to have an app in one dc connect (client bindings) to the qmgr in the other dc?

Again, if there are no latency problems it should not be an issue.
_________________
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: Thu Feb 22, 2018 3:52 am Post subject: Reply with quote

Poobah

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

mq__quest wrote:
Lets say the DCs are about 100 miles apart and the network guys are ok with it.

It depends. It's complicated. Everything we do imposes delays. MQ is just one item to consider.

What are your SLAs? Local? Remote?

What hardware/software platforms are your DCs? How well provisioned (RAM, CPU)? What network type? Copper? Fiber?

Does your SLA include delays from other activity, like database access? Or, are you only interested in delays imposed by mq in moving your messages between DCs?

The speed of light is 186,000 miles/second in a vacuum. Reduce that by approximately 30% when the medium is glass fiber, the approximate speed of light is approx 128,340 miles/second. A, a one-way trip from one DC to another DC is pretty quick.

Again, it's complicated.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 22, 2018 6:19 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24775
Location: Ohio, USA

mq__quest wrote:
Lets say the DCs are about 100 miles apart and the network guys are ok with it.


Of course the network guys are ok with it; they can ping one end from the other.

mq__quest wrote:
In this scenario , is it a good idea to have a cluster across the dcs.


Clusters are a good reason for the reasons I gave. As my worthy associate points out, a key question is how much is going over the link that isn't MQ? If you're (for example) doing bidirectional database replication to keep business databases in sync across the DCs, then that's going to soak a lot of bandwidth. What will be the result if MQ cluster traffic slows down other traffic (like database replication)?

mq__quest wrote:
And is it a good idea to have an app in one dc connect (client bidings) to the qmgr in the other dc?


See above re: the amount of bandwidth you're using in the link. I would put it to you that an application (especially a customer facing one) has an SLA so short you shouldn't risk network latency or failure by creating a synchronous client connection to a geographically distant queue manager.

Also remember it's not "an app". It's all the instances of that app so you rapidly get hundreds of connections. Multiply that by the number of apps that will use the same architecture and you quickly get thousands of synchronous connections flowing across the cross-DC link. As well as all the other traffic.

I assert that at this point, the network guys will be less OK with it.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 22, 2018 7:19 am Post subject: Reply with quote

Poobah

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

mq__quest wrote:
.... and the network guys are ok with it.

Are the network guys ok with it 'in concept?' Or, have they measured current bandwidth, projected network bandwidth based on growth estimates?

What percentage of your network bandwidth is available (unused) today? 10%? 25%? 50%? 75%? Or, is it unknown?
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
mq__quest
PostPosted: Thu Feb 22, 2018 8:11 am Post subject: Reply with quote

Novice

Joined: 21 Aug 2017
Posts: 14

bruce2359 wrote:
mq__quest wrote:
.... and the network guys are ok with it.

Are the network guys ok with it 'in concept?' Or, have they measured current bandwidth, projected network bandwidth based on growth estimates?

What percentage of your network bandwidth is available (unused) today? 10%? 25%? 50%? 75%? Or, is it unknown?


The numbers are unknown currently.
In general, how can MQ high availability and DR be provided between active/active data centers. Apps are located in both the dc's.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 22, 2018 8:27 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24775
Location: Ohio, USA

mq__quest wrote:
In general, how can MQ high availability and DR be provided between active/active data centers. Apps are located in both the dc's.


HA is provided by having multiple MQ targets within each of the DCs that an application can use.

DR is provided by having the same topology in both DCs.

Inbound traffic (the start of a workflow) is passed to an application instance in one or other DC by load balancing (at a network level) across the DCs. Once inside a DC you get much better control / response by keeping the network traffic for a workflow in the same DC. The state at the end of the workflow you store in a persistent store, which you typically replicate in both DCs.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
mq__quest
PostPosted: Thu Feb 22, 2018 8:43 am Post subject: Reply with quote

Novice

Joined: 21 Aug 2017
Posts: 14

Thanks for the details, Vitor.

Vitor wrote:


HA is provided by having multiple MQ targets within each of the DCs that an application can use.

so, this can be achieved by having a cluster with at least two qmgrs with the app target queues.

Vitor wrote:
DR is provided by having the same topology in both DCs.

This can be achieved by having the exact same cluster on the both DCs with different qmgr names.

Vitor wrote:
The state at the end of the workflow you store in a persistent store, which you typically replicate in both DCs.

Ok, I didn't get this last part. Could you explain a little please. Aprreciate your time.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 22, 2018 9:44 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24775
Location: Ohio, USA

mq__quest wrote:
Vitor wrote:
The state at the end of the workflow you store in a persistent store, which you typically replicate in both DCs.

Ok, I didn't get this last part. Could you explain a little please. Aprreciate your time.


Let's assume a customer (internal or external) is ordering something; the classic scenario of IT textbooks everywhere. The process consists of a number of workflows:
- Submission & validation
- Verification
- Invoicing
- Fulfillment

In the event of a failure in any of these, you'd want to restart the entire workflow (comprising 1 - n applications) so the state at the start of the workflow needs to be recorded. You also want the ability to run any workflow for any order in either of the active DCs for load balancing reasons. So you store the state persistently (as a file or a DB row) and replicate it to the other DC (using disc or DB replication). Any workflow instance in either DC can then pick up any item that's flagged as ready for processing. So an order is verified by a workflow in one DC but invoiced in the other.

What you don't want is the verification workflow (for example) bouncing back and forth between the DCs. Nor do you want the entire process running as a single workflow in case you have a failure and have to piece together where you are in the other DC.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 22, 2018 9:56 am Post subject: Reply with quote

Poobah

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

I'm thinking that the OP should do a bit of research on what back-up site architectures are available:
- hot-site
- warm-site
- cold-site
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Vitor
PostPosted: Thu Feb 22, 2018 10:32 am Post subject: Reply with quote

Grand High Poobah

Joined: 11 Nov 2005
Posts: 24775
Location: Ohio, USA

bruce2359 wrote:
I'm thinking that the OP should do a bit of research on what back-up site architectures are available:
- hot-site
- warm-site
- cold-site


The OP said active/active so my comments assumed 2 hot sites.

If this assumption is incorrect, I reserve the right to review my comments.
_________________
Honesty is the best policy.
Insanity is the best defence.
Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Feb 22, 2018 3:44 pm Post subject: Reply with quote

Poobah

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

Replicated (mirrored) hot-site - one transaction, one cluster, is another possibility. I sense that the OP is uncertain here.
_________________
I would tell you a UDP joke, but you might not get it.
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexClusteringclustering across multiple data centers
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.