In each of our sites we have a relay (shocker I know). That relay along with it’s real name, has an alias to it under the local sites dhcp domain. We are in the process of rolling out automatic relay affiliation and it’s working wonderfully. That said, I have put in the alias (call it LRELAY) in the fail over list and have found it comes in handy sometimes. Sort of a good catch when things hiccup.
We also have our bank of fail over relays to protect the root. I have assigned them with “FailOver” in there seek list affiliation. I was thinking about adding another “LRELAY” server and not putting it under our main DNS domain. Hoping that it would show up in the relays.dat with the affiliation of “FailOver” with just the short name of “LRELAY”. Think that would work?
I’m not currently appending FailOver (but I want to) in the _BESClient_Register_Affiliation_SeekList property because I want it to try the common short name under the sites dhcp domain. If I added FailOver to it, it would never get to the short name check I added in the _BESClient_RelaySelect_FailoverRelayList property.
You lost me a little bit at the end, what problem are you running into?, or what question did you have?, or what do you need to know how to do or what are you asking is possible?; and I’ll see if I can answer.
My goal is to have one last ditch attempt at trying the local dns short name of the relay before truly failing up, AND making sure we evenly spread the fail overs to what is ultimately in the _BESClient_RelaySelect_FailoverRelayList. I may be overthinking this, but here’s my direction…
Let’s say my current setup looks like this, but failover1 & 2 have a FailOver in there _BESRelay_Register_Affiliation_AdvertisementList :
And I want “LRELAY” (only a local dns name short name inder it’s dhcp domain) to show up in “FailOver” list. As would be outputted by ParseRelaysDotDat.exe:
That way as it’s going through it the relay list, it has the possibility to hit that short name. If I’m nuts, I’ll just delete this post. Was sort of a pipe dread on how to deal with fail over situations.
I have that now, I just wanted to see if there was a way to not put in an order to the fail over list. That way no one server gets over loaded more than the others.
Before the introduction of the “_BESClient_RelaySelect_FailoverRelayList” setting in v9.0, and lacking a true “Randomize” function to spread systems across my DMZ Relays, I used the Modulus function to ensure that systems were spread as evenly as possible …
setting "_BESClient_RelaySelect_FailoverRelay"=”{item 1 of item 1 of (computer id mod 2, (0,"http://dmz01.domain:52311/bfmirror/downloads/"; 1,"http://dmz02.domain:52311/bfmirror/downloads/")) whose (item 0 of it = item 0 of item 1 of it)}” on "{now}" for client
You could do this with a load balancer, or you could randomize the list like @TimRice suggests.
I like this idea, but if all sites have a relay with the same short name, then you could probably just use that in the primary relay selection list instead of the failover, except in sites with multiple relays.
You could actually give a single relay as many CNAMES as you want. You could have a client select between many relays, but it actually only resolve to a single one. You could also have those CNAMES resolve to different relays later on. You wouldn’t want this to change all the time, but occasionally it would be fine as long as a particular client tends to get a particular relay except when a major shift happens in the number of total relays.
Are you saying that the new “List” option will randomize in and of itself? For example, if three FQDN’s are listed, one will be picked by random or will it try them sequentially do you know?
I was referring to BESClientRelaySelect_FailoverRelayList and how that handles multiple relay entries.
Unfortunately, relays are selected in the order listed; which is almost pointless. It would be best if the relays listed were evaluated and the one with the lowest hop count was chosen.
No, it’s not really Random. It’s “evenly distributed”. A given computer (ComputerID really) will always point to the same Relay using that Relevance. No matter how many times the Relevance is evaluated, the result will always be the same.
What I did was rely on the fact that the ComputerID property is “evenly distributed” so that when I use the MOD command to get the “remainder of the division”, in this case, by 2, I should get a fairly even distribution of my Endpoints between the two specified Relays.
When I originally created this Relevance (based in part on an example given by John Talbert in a Relevance class I once attended), there was no RANDOM function in Relevance. There now appears to be (as of v9.5.3).