Hi,
I have managed 2000 endpoints with 2 Relay in my environment, also all the clients configured automatic relay selection method process,
for any method to find RELAY 1 handle only 1000 endpoints and RELAY 2 handle 1000 endpoints, even more then 1000 endpoints reporting to RELAY 1 mean how to load balance rest of the machine (for example 1600 endpoints reporting to RELAY 1 mean how we restrict 600 endpoints need to communicate RELAY 2 in “RELAY Auto selection method”)
I’m having trouble following what you want.
Are you saying you want to have exactly 1000 endpoints report in for each relay so that they are evenly divided?
You could set settings to restrict how many endpoints each relay will work with, but I wouldn’t recommend this because if one of the relays fails or goes offline, then you WOULD want all of the clients to talk to the remaining relay.
Also, there is nothing wrong with having 2000+ endpoints talk to 1 relay as long as that relay has the network and storage IO performance to handle it. It really depends on what you are using for relays.
Are you having some sort of problem due to the imbalance? or are you just worried about it?
If you really only have 2 relays, then the easiest solution should be to set all clients to manual relay selection with 1/2 of them using relay1 as the primary and 1/2 of them using relay1 as the secondary.
Unless you think you are having problems, I would either do nothing, or just add a 3rd relay.
For example if the Relay 1 manage only 800 endpoints, more then endpoints request to register on RELAY 1 mean it won’t allow to register , for this scenario can I set the below “client setting” on “RELAY machines” mean, RELAY won’t allow to register endpoints more than 800 endpoints right?
_Enterprise Server_ClientRegister_MaxChildRelayCount " Value Range: 800",
Could you please confirm the above setting status ?
That is not the correct setting, this is the setting you should use to limit the number of clients connected to a relay: _Enterprise Server_ClientRegister_MaxChildCount
I would recommend having a failover relay or something that does not have a limit because if the number of clients suddenly grow and you have these limits set too low on your relays, then you could suddenly have clients that drop off and can’t communicate at all because they can NEVER register with a relay.
You should also set the Root server to NOT be selectable with automatic relay selection, which will cause it to not end up being selected unless autoselection fails.
Clients will tend to prefer old relays over new ones, so it makes sense to set a limit on the old relay until more clients join the new relay.
I believe it is also possible to set how much a relay should be preferred over another which might also be useful to achieve balance. Tell the one that has less clients to be more preferred until it balances out.
It can be useful to use this tool to get a better idea of what is going on: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Relays.dat%20Parser
Thank you for your updates,
Last I read, you can not set the root to not be selectable, I tried it. It’s documented somewhere that you can’t set _BESRelay_Selection_AutoSelectableRelay = 0 on the root. That value is ignored.
But what you CAN do, is set _BESRelay_Register_Affiliation_AdvertisementList = “NeverEverMe” and make sure you selection clients seek list with a value. If the client or servers list is blank, it could go anywhere.
That is interesting that it is ignored. I can’t say I have played with that enough to know one way or the other, but that seems believable.
I generally use both methods, but it is more complicated to explain, but it sounds like it is needed.
Basically, just set the root server’s affiliation list to any random gibberish. The important part is that nothing else use that affiliation list… Though it also sounds like in a very basic setup you would want all other relays and clients to have an affiliation list entry that matches, like ANY unless you want to do more interesting affiliation lists.
The documentation on this is pretty sparse, but apparently you can also use: _BESRelay_Selection_RelayPriority to change the priority of the root server over other relays.
The default value is 0 and the lowest value is selected first.
There is also _BESRelay_Selection_RelayWeight with a default of 100.
I wouldn’t suggest changing around a bunch of these relay properties often because I believe they get propagated with the actionsite and the Relays.dat file, but they are definitely useful.