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

[Charles Goldsmith]

We've built them as individual pairs (Edge/Core) and then use DNS to
control which one goes where.  Without the cluster, we know that Edge1 will
always talk to Core1.

I get the feeling that clustering was always meant to be in the same DC,
and for redundancy purposes in the same DC.

If you have two DC's, either a cluster at each DC, or just a pair at each
DC, depending on the business needs.

On Tue, Jan 28, 2020 at 8:11 PM Lelio Fulgenzi <lelio at uoguelph.ca> wrote:

>
> How does no. 2 actually solve the problem of having to log back in?
>
> Is this a supported/suggested deployment method?
>
> It’s been a while since I first looked at things and don’t recall things
> mentioning using the cluster name in the SRV records.
>
> I’m intrigued. And interested!
>
>
> *-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 | @UofGCCS on Instagram, Twitter and Facebook
>
>
>
> [image: University of Guelph Cornerstone with Improve Life tagline]
>
> On Jan 28, 2020, at 9:03 PM, Ryan Huff <ryanhuff at outlook.com> wrote:
>
> 1.) It used to be in previous versions that all cluster nodes could
> technically be active at any time and SRV weights and priorities could
> influence the path selection but not guarantee it end-to-end when all
> cluster nodes are up and running.
>
> I believe this behavior has changed/improved and I think you are supposed
> to be able to control that now with SRV weights and priorities, but I could
> be wrong. I haven’t played with Expressway clustering in a bit.
>
> 2.) As far as the Jabber registration goes; what I’ve done before in the
> edge is have the collab-edge SRV point to the edge cluster FQDN as the
> target. Then I create round robin A records for the cluster FQDN (one
> resolving your each edge server). The for the edge certs, just make sure
> the edge cluster fqdn is in the SAN.
>
> This way if one of the edge server goes down, the Jabber client is
> ultimately still trying to resolve the same MRA FQDN via SRV lookup (this a
> key to Jabber client failover for MRA).
>
> Thanks,
>
> Ryan
>
> On Jan 28, 2020, at 20:50, 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.nether.net%2Fmailman%2Flistinfo%2Fcisco-voip&data=02%7C01%7C%7C2f536d8162984707853908d7a45d8e24%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637158594035084563&sdata=atRtIR8sWZ60Ja8akD6GjzBIgBNC8GSJjaOmu%2BTxmWw%3D&reserved=0
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20200128/9b774984/attachment.htm>