You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by "Basmajian, Raffi" <rb...@ofiglobal.com> on 2015/09/24 23:31:23 UTC
Datacenter failover and randomizing connections
Hello,
We're trying to determine the correct client failover URL for this scenario:
2 brokers in New York (master/slave)
2 brokers in Chicago (master/slave)
Client connections from NY are prioritized (and randomized) to NY; failover to Chicago if no local brokers available.
Client connections from Chicago are prioritized (and randomized) to Chicago; failover to NY if no local brokers available.
Topology is full graph/NoB; one network hop separates any two brokers.
What we've tried so far (assumes clients located in NY)
Randomizes connections across local and remote brokers (not good)
failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
Always picks first local broker (not good)
failover:(tcp://ny1:61600,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false
No different than previous; always selects first broker
failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false&priorityBackup=true
We haven't tried this yet, but is it possible to nest failover transports? If so, technically this should select the first group, NY brokers, randomizing connections automatically within that cluster, then moving to Chicago and doing the same if no brokers in NY are available.
failover:( failover:(tcp://ny1,tcp://ny2), failover:(tcp://chi1,tcp://chi2))?randomize=false&priorityBackup=true
We're exploring DNS and F5 options as well, but we want to leverage the software as much as possible before configuring infrastructure.
Thank you
Raffi
This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
RE: Datacenter failover and randomizing connections
Posted by "Basmajian, Raffi" <rb...@ofiglobal.com>.
OK,
So with the following URL, initial connections are randomized amongst "tcp://ny1,tcp://ny2", if neither available, remaining brokers in list are tried. If priority brokers become available again, switch back to those brokers, but randomize the selection when switching back.
failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
randomize=true
priorityBackup=true
priorityURIs=tcp://ny1,tcp://ny2
Thanks, Tim, very helpful!
Best,
Raffi
-----Original Message-----
From: Timothy Bish [mailto:tabish121@gmail.com]
Sent: Thursday, September 24, 2015 5:57 PM
To: users@activemq.apache.org
Subject: Re: Datacenter failover and randomizing connections [ EXTERNAL ]
Importance: High
On 09/24/2015 05:53 PM, Basmajian, Raffi wrote:
> Tim,
>
> We missed that one! Looks promising, though the only gripe I have with that approach is duplication of data, creating maintenance overhead and higher likelihood of misconfigurations.
>
> I assume the nested option I suggested is not supported?
Nope
>
> Raffi
>
> -----Original Message-----
> From: Timothy Bish [mailto:tabish121@gmail.com]
> Sent: Thursday, September 24, 2015 5:46 PM
> To: users@activemq.apache.org
> Subject: Re: Datacenter failover and randomizing connections [
> EXTERNAL ]
> Importance: High
>
> On 09/24/2015 05:31 PM, Basmajian, Raffi wrote:
>> Hello,
>>
>> We're trying to determine the correct client failover URL for this scenario:
>>
>> 2 brokers in New York (master/slave)
>> 2 brokers in Chicago (master/slave)
>>
>> Client connections from NY are prioritized (and randomized) to NY; failover to Chicago if no local brokers available.
>> Client connections from Chicago are prioritized (and randomized) to Chicago; failover to NY if no local brokers available.
>> Topology is full graph/NoB; one network hop separates any two brokers.
>>
>> What we've tried so far (assumes clients located in NY)
>>
>> Randomizes connections across local and remote brokers (not good)
>> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
>>
>> Always picks first local broker (not good)
>> failover:(tcp://ny1:61600,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=
>> f
>> alse
>>
>> No different than previous; always selects first broker
>> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false&
>> p
>> riorityBackup=true
>>
>> We haven't tried this yet, but is it possible to nest failover transports? If so, technically this should select the first group, NY brokers, randomizing connections automatically within that cluster, then moving to Chicago and doing the same if no brokers in NY are available.
>> failover:( failover:(tcp://ny1,tcp://ny2),
>> failover:(tcp://chi1,tcp://chi2))?randomize=false&priorityBackup=true
>>
>> We're exploring DNS and F5 options as well, but we want to leverage the software as much as possible before configuring infrastructure.
>>
>> Thank you
>> Raffi
>>
>>
>>
>>
>> This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
>>
> One option that you haven't yet tried given the above examples is
> priorityURIs
>
> Refer to the failover transport page:
> http://activemq.apache.org/failover-transport-reference.html
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: Datacenter failover and randomizing connections
Posted by Timothy Bish <ta...@gmail.com>.
On 09/24/2015 05:53 PM, Basmajian, Raffi wrote:
> Tim,
>
> We missed that one! Looks promising, though the only gripe I have with that approach is duplication of data, creating maintenance overhead and higher likelihood of misconfigurations.
>
> I assume the nested option I suggested is not supported?
Nope
>
> Raffi
>
> -----Original Message-----
> From: Timothy Bish [mailto:tabish121@gmail.com]
> Sent: Thursday, September 24, 2015 5:46 PM
> To: users@activemq.apache.org
> Subject: Re: Datacenter failover and randomizing connections [ EXTERNAL ]
> Importance: High
>
> On 09/24/2015 05:31 PM, Basmajian, Raffi wrote:
>> Hello,
>>
>> We're trying to determine the correct client failover URL for this scenario:
>>
>> 2 brokers in New York (master/slave)
>> 2 brokers in Chicago (master/slave)
>>
>> Client connections from NY are prioritized (and randomized) to NY; failover to Chicago if no local brokers available.
>> Client connections from Chicago are prioritized (and randomized) to Chicago; failover to NY if no local brokers available.
>> Topology is full graph/NoB; one network hop separates any two brokers.
>>
>> What we've tried so far (assumes clients located in NY)
>>
>> Randomizes connections across local and remote brokers (not good)
>> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
>>
>> Always picks first local broker (not good)
>> failover:(tcp://ny1:61600,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=f
>> alse
>>
>> No different than previous; always selects first broker
>> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false&p
>> riorityBackup=true
>>
>> We haven't tried this yet, but is it possible to nest failover transports? If so, technically this should select the first group, NY brokers, randomizing connections automatically within that cluster, then moving to Chicago and doing the same if no brokers in NY are available.
>> failover:( failover:(tcp://ny1,tcp://ny2),
>> failover:(tcp://chi1,tcp://chi2))?randomize=false&priorityBackup=true
>>
>> We're exploring DNS and F5 options as well, but we want to leverage the software as much as possible before configuring infrastructure.
>>
>> Thank you
>> Raffi
>>
>>
>>
>>
>> This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
>>
> One option that you haven't yet tried given the above examples is priorityURIs
>
> Refer to the failover transport page:
> http://activemq.apache.org/failover-transport-reference.html
>
> --
> Tim Bish
> Sr Software Engineer | RedHat Inc.
> tim.bish@redhat.com | www.redhat.com
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/
RE: Datacenter failover and randomizing connections
Posted by "Basmajian, Raffi" <rb...@ofiglobal.com>.
Tim,
We missed that one! Looks promising, though the only gripe I have with that approach is duplication of data, creating maintenance overhead and higher likelihood of misconfigurations.
I assume the nested option I suggested is not supported?
Raffi
-----Original Message-----
From: Timothy Bish [mailto:tabish121@gmail.com]
Sent: Thursday, September 24, 2015 5:46 PM
To: users@activemq.apache.org
Subject: Re: Datacenter failover and randomizing connections [ EXTERNAL ]
Importance: High
On 09/24/2015 05:31 PM, Basmajian, Raffi wrote:
> Hello,
>
> We're trying to determine the correct client failover URL for this scenario:
>
> 2 brokers in New York (master/slave)
> 2 brokers in Chicago (master/slave)
>
> Client connections from NY are prioritized (and randomized) to NY; failover to Chicago if no local brokers available.
> Client connections from Chicago are prioritized (and randomized) to Chicago; failover to NY if no local brokers available.
> Topology is full graph/NoB; one network hop separates any two brokers.
>
> What we've tried so far (assumes clients located in NY)
>
> Randomizes connections across local and remote brokers (not good)
> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
>
> Always picks first local broker (not good)
> failover:(tcp://ny1:61600,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=f
> alse
>
> No different than previous; always selects first broker
> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false&p
> riorityBackup=true
>
> We haven't tried this yet, but is it possible to nest failover transports? If so, technically this should select the first group, NY brokers, randomizing connections automatically within that cluster, then moving to Chicago and doing the same if no brokers in NY are available.
> failover:( failover:(tcp://ny1,tcp://ny2),
> failover:(tcp://chi1,tcp://chi2))?randomize=false&priorityBackup=true
>
> We're exploring DNS and F5 options as well, but we want to leverage the software as much as possible before configuring infrastructure.
>
> Thank you
> Raffi
>
>
>
>
> This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
>
One option that you haven't yet tried given the above examples is priorityURIs
Refer to the failover transport page:
http://activemq.apache.org/failover-transport-reference.html
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/
Re: Datacenter failover and randomizing connections
Posted by Timothy Bish <ta...@gmail.com>.
On 09/24/2015 05:31 PM, Basmajian, Raffi wrote:
> Hello,
>
> We're trying to determine the correct client failover URL for this scenario:
>
> 2 brokers in New York (master/slave)
> 2 brokers in Chicago (master/slave)
>
> Client connections from NY are prioritized (and randomized) to NY; failover to Chicago if no local brokers available.
> Client connections from Chicago are prioritized (and randomized) to Chicago; failover to NY if no local brokers available.
> Topology is full graph/NoB; one network hop separates any two brokers.
>
> What we've tried so far (assumes clients located in NY)
>
> Randomizes connections across local and remote brokers (not good)
> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)
>
> Always picks first local broker (not good)
> failover:(tcp://ny1:61600,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false
>
> No different than previous; always selects first broker
> failover:(tcp://ny1,tcp://ny2,tcp://chi1,tcp://chi2)?randomize=false&priorityBackup=true
>
> We haven't tried this yet, but is it possible to nest failover transports? If so, technically this should select the first group, NY brokers, randomizing connections automatically within that cluster, then moving to Chicago and doing the same if no brokers in NY are available.
> failover:( failover:(tcp://ny1,tcp://ny2), failover:(tcp://chi1,tcp://chi2))?randomize=false&priorityBackup=true
>
> We're exploring DNS and F5 options as well, but we want to leverage the software as much as possible before configuring infrastructure.
>
> Thank you
> Raffi
>
>
>
>
> This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
>
One option that you haven't yet tried given the above examples is
priorityURIs
Refer to the failover transport page:
http://activemq.apache.org/failover-transport-reference.html
--
Tim Bish
Sr Software Engineer | RedHat Inc.
tim.bish@redhat.com | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/