Radiator Server Documentation — v10.33.1
Table of Contents
server-selection
This attribute determines how Radiator selects an LDAP server when multiple server blocks are configured. Possible values are:
fallback: Servers are tried in priority order. The highest-priority available server receives every request. Lower-priority servers are used only when higher-priority servers are unavailable or degraded.round-robin: Requests are distributed across all available servers in rotation. If a server fails, the next available server in the rotation is used.no-fallback: Only the highest-priority available server is tried for each request. If the operation fails on that server, the request fails without retrying on other servers.least-connections: Each request is routed to the available server with the fewest in-use connections. If that server also fails, the next least-loaded server is tried. When servers are tied, servers with a lowerpriorityvalue are preferred; within the same priority, alphabetical name order is used as a tiebreaker — the same asfallback. Because saturated pools are skipped immediately for LDAP, this strategy is useful for balancing load under high concurrency.
Default: fallback
Example configuration:
ldap "LDAP_HA" {
server-selection least-connections;
server "LDAP1" {
url "ldap://ldap1.example.com:389/";
timeout 3s;
shared-connections 10;
exclusive-connections 10;
authentication {
dn "cn=radiator,dc=example,dc=com";
password "secret";
}
}
server "LDAP2" {
url "ldap://ldap2.example.com:389/";
timeout 3s;
shared-connections 10;
exclusive-connections 10;
authentication {
dn "cn=radiator,dc=example,dc=com";
password "secret";
}
}
search "FIND_USER" {
base "dc=example,dc=com";
scope sub;
filter "(&(uid=%{aaa.identity})(objectClass=inetOrgPerson))";
mapping {
user.username = uid;
vars.dn = entry::dn;
}
}
}
See Backend Load Balancing for more details and examples.
Table of Contents
Navigation