On 03/06/2013 12:16 PM, Vicaretti Vincenzo (Guest) wrote: > Stress-test performed has saturated the server’s CPU > > I have Enabling the multi-thread through the parameter FarmSize, the CPU > usage goes down a lot, so we are considering the integration of support > for multi-threading in our configuration.
Hello Vincenzo, the other load balancing methods have similar behaviour: when they are used to proxy requests directly to IAS, IAS will see them arriving from different UDP ports (different port for each farm worker) and this breaks duplicate detection. With e.g., PEAP, the duplicates will cause problems for the TLS layer leading to authentication failures. If there are no duplicates, this should not be a problem. However, as mentioned in the reference manual, when there are duplicates they may go undetected. > In your documentation shows that I can use the parameter FarmSize with > both AuthBy RADIUS with each its sub-balancing methods. Instead of using one UDP port with multiple farm workers, would multiple listen ports with single radiusd instance per port be possible? For example: you would have authentication ports 18121, 18123, 18125 and have one instance for each port. If you specify the listen ports on radiusd command line you could use even the same configuration file for all instances. This would require that the clients that are currently proxying to Radiator could be reconfigured so that they use the new listen ports. Thanks, Heikki > My back-end (Microsoft IAS) do not support the algorithm > "UseContentsForDuplicateDetection." This, however, is essential to > enable the FarmSize on frontend (Radiator) in combination with the > EAPBALANCE balancing algorithm: > > > > /"It is essential That this parameter be defined in the Client clauses > of back-end servers of an EAPBALANCE Server Farm architecture, Otherwise > duplicate detection will not be performed Correctly."/ > > > > I can not use the method EAPBALANCE with backend like Microsoft IAS, as > I wrote in this Vatiainen Heikki mail: > > http://www.open.com.au/pipermail/radiator/2013-February/018893.html > > > > I read in your documentation: > > > > /"<AuthBy EAPBALANCE> [...] Is Intended To ensure that all EAP requests > Relating to a single session always go to the same target RADIUS server"/ > > > > - To balance the EAP-SIM, EAP-TLS and PEAP I am obliged to use the > EAPBALANCE algorithm? > > _ _ > > -_Alternative balancing algorithms (ROUNDROBIN, VOLUMEBALANCE or > LODABALANCE) maintain session persistence?_ > > > > - To enable multi-threaded through the FarmSize (ServerFarm) with IAS > back-end, can I use a balancing algorithm alternative? There are any > contraindications? > > > > > > _______________________________________________ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator > -- Heikki Vatiainen <[email protected]> Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
