| Author |
Message
|
| mq__quest |
 Posted: Mon Aug 21, 2017 7:40 pm Post subject: clustering across multiple data centers |
 |
|
Apprentice
Joined: 21 Aug 2017
Posts: 49
|
Is building a MQ cluster across 2 data centers a good idea?
could there be network and latency issues? |
|
| Back to top |
|
 |
| exerk |
| Posted: Tue Aug 22, 2017 12:42 am Post subject: Re: clustering across multiple data centers |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| 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 |
|
|
| Vitor |
| Posted: Tue Aug 22, 2017 5:18 am Post subject: Re: clustering across multiple data centers |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| mq__quest |
| Posted: Wed Feb 21, 2018 9:09 pm Post subject: |
|
|
Apprentice
Joined: 21 Aug 2017
Posts: 49
|
Thanks for your replies vitor and exerk.
Let’s say the DC’s 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 dc’s.
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 |
|
|
| exerk |
| Posted: Thu Feb 22, 2018 12:26 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| mq__quest wrote: |
| ...In this scenario , is it a good idea to have a cluster across the dc’s... |
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 |
|
|
| bruce2359 |
| Posted: Thu Feb 22, 2018 3:52 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mq__quest wrote: |
| Let’s say the DC’s 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 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 |
|
|
| Vitor |
| Posted: Thu Feb 22, 2018 6:19 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mq__quest wrote: |
| Let’s say the DC’s 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 dc’s. |
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 |
|
|
| bruce2359 |
| Posted: Thu Feb 22, 2018 7:19 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 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 |
|
|
| mq__quest |
| Posted: Thu Feb 22, 2018 8:11 am Post subject: |
|
|
Apprentice
Joined: 21 Aug 2017
Posts: 49
|
| 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 |
|
|
| Vitor |
| Posted: Thu Feb 22, 2018 8:27 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| mq__quest |
| Posted: Thu Feb 22, 2018 8:43 am Post subject: |
|
|
Apprentice
Joined: 21 Aug 2017
Posts: 49
|
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 |
|
|
| Vitor |
| Posted: Thu Feb 22, 2018 9:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| bruce2359 |
| Posted: Thu Feb 22, 2018 9:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 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 |
|
|
| Vitor |
| Posted: Thu Feb 22, 2018 10:32 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, 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 |
|
|
| bruce2359 |
| Posted: Thu Feb 22, 2018 3:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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 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 |
|
|
|
|
