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 <le...@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> | le...@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 <ryanh...@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 <jonv...@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@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip