[cisco-voip] Expressway Cluster failover for MRA...

[Jonathan Charles]

So I changed the SRV records to be equal priority and weight... and
everything works fine.

If I put a C & E pair at a site in maintenance mode, we do NOT see
automatic reregistration of phone services to the other C/E pair at the
other site.

If you log out and back in, it does automatically reregister.

If we put one of the 4 Expressways in maintenance mode, it fails over
automatically.

How do we achieve automatic failover for MRA?


Jonathan


On Wed, Jan 29, 2020 at 3:17 PM Jonathan Charles <jonvoip at gmail.com> wrote:

> I mean an outbound flow... offnet Jabber calls PSTN... I need it to go to
> primary DC... the only way I can force that is by lowering priority of the
> collab-edge SRV record.
>
> To force a failover, I put the primary in maintenance mode, then Jabber
> times out and dies... log out, log back in and it connects to the DR.
>
> If I set the SRVs to the same priority, it seems to connect thru the DR
> site (out of spite).
>
>
> Jonathan
>
> On Wed, Jan 29, 2020 at 2:59 PM Ryan Huff <ryanhuff at outlook.com> wrote:
>
>> That seems correct. It seems like you’re speaking about an outbound flow
>> and Lelio is speaking about an inbound flow.
>>
>> The traversal client cluster (the CS) should know about all the peers in
>> the traversal server cluster (the Es).
>>
>> Sent from my iPhone
>>
>> On Jan 29, 2020, at 15:21, Jonathan Charles <jonvoip at gmail.com> wrote:
>>
>> 
>> OK, maybe I am misunderstanding... I have th E's paired together as a
>> cluster and the C's paired together as a cluster... I have the C's
>> initiating a UCM traversal client to both E's... is this not correct?
>>
>>
>> Jonathan
>>
>> On Tue, Jan 28, 2020 at 7:59 PM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:
>>
>>> I could be wrong here, but from what was explained to me...
>>>
>>> You may be able to control the initial connection from off-prem device
>>> to the E of your choosing, but you cannot control which C that E talks to.
>>> And vice-versa.
>>>
>>> So, you could point people to Ea, but they could easily be sent to Cs.
>>> And that traffic back from Cs could easily be sent to Es.
>>>
>>> I was told at one time, the only option would be to put hosts in
>>> maintenance mode or something like that. But it wasn’t advised.
>>>
>>> I’d love to hear other suggestions.
>>>
>>> *-sent from mobile device-*
>>>
>>>
>>> *Lelio Fulgenzi, B.A.* | Senior Analyst
>>>
>>> Computing and Communications Services | University of Guelph
>>>
>>> Room 037 Animal Science & Nutrition Bldg | 50 Stone Rd E | Guelph, ON |
>>> N1G 2W1
>>>
>>> 519-824-4120 Ext. 56354 <519-824-4120;56354> | lelio at uoguelph.ca
>>>
>>>
>>>
>>> www.uoguelph.ca/ccs
>>> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uoguelph.ca%2Fccs&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=N%2F%2FyzmALTugonxBWql9Ed1RU91GlfciMVacel%2FTm6nU%3D&reserved=0> |
>>> @UofGCCS on Instagram, Twitter and Facebook
>>>
>>>
>>>
>>> [image: University of Guelph Cornerstone with Improve Life tagline]
>>>
>>> On Jan 28, 2020, at 8:49 PM, Jonathan Charles <jonvoip at gmail.com> wrote:
>>>
>>> We have two pairs of Expressway clusters (C/E) at two different
>>> locations (primary and DR)...
>>>
>>> The cluster is up, however, we want to make sure that we are in
>>> Active/Standby.
>>>
>>> Currently, we have one of our SRV records for collab-edge set at 5 (the
>>> backup is at 10) with the same weight.
>>>
>>> The clustering guide says we should set the priority and weight on both
>>> SRV records the same, which will cause half of the registrations to go to
>>> the DR site. It is far away and has less capability.
>>>
>>> How do we:
>>>
>>> 1 - Make sure the primary site handles all MRA registrations and the DR
>>> site is only used when the primary is down.
>>> 2 = Make sure failover occurs automatically... currently Jabber users
>>> have to log out and back in to connect to the DR site.
>>>
>>>
>>> Thanks!
>>>
>>>
>>> Jonathan
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995053342&sdata=Uc0yDIk78tTL3s3jGUD8YOn1BTAz8BQfsQn1IcmFsoY%3D&reserved=0>
>>>
>>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C990b53ac7bf74dc9f6d908d7a4f8d85e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637159260995073329&sdata=FiPM638B7JKc3x9OhTq2s9Tf1hqWUQ9chaJfw13bxkk%3D&reserved=0
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200207/af4c7785/attachment.htm>