The key is to use the eapbalance handler with farmsize and then proxy to individual "backend" processes that handle the eap details / authentication.
This is outlined in goodies/eapbalance.cfg. Barry On Fri, Sep 25, 2015 at 8:22 AM, Garry Shtern <garry.sht...@twosigma.com> wrote: > So what happens to the EAP/PEAP requests if one enables FarmSize? Do they > simply get processed by the parent, or do they break completely? > > > > *From:* radiator-boun...@open.com.au [mailto:radiator-boun...@open.com.au] > *On Behalf Of *Amândio Antunes Gomes Silva > *Sent:* Thursday, September 24, 2015 4:43 AM > *To:* António Mendes <antonio.men...@wit-software.com>; > radiator@open.com.au > *Subject:* Re: [RADIATOR] Use FarmSize parameter > > > > Hi António (and the rest)! > > > > From the Radiator 4.15 Reference Manual (Section 5) > > 5.7.43FarmSize > > This optional parameter allows you to specify how many server instances to > create in a server farm. A server farm is a set of identical Radiator > servers, all monitoring the same RADIUS sockets. Incoming RADIUS requests > are distributed among the child servers in the server farm. The main server > acts as a supervisor, and restarts children that die or are terminated. > Unix only. Defaults to 0, which means no server farm, and only a single > instance of Radiator is run. > > Hint: this parameter can be used to improve performance in some cases on > platforms that support multiple cores and fork(). > > Caution: This parameter, and the use of server farms is not compatible > with many EAP protocols, such as TLS, TTLS, PEAP etc. This is because such > protocols rely in authentication state being held within each server > process, and it is necessary for all the requests for such protocols to go > to the same Radiator instance. > > > > So you have to make sure that the platform where you have Radiator running > on supports what’s mentioned in *Hint*. > > > > Regards, > > > > Cumprimentos, > > *Amândio Antunes Gomes da Silva* > > > ----------------------------------------------------------------------------------------------------------------------------------- > > Serviços de Comunicações da Universidade do Minho > > Campus de Gualtar, 4710-057 Braga - Portugal > > Tel.: + 351 253 60 40 20, Fax: +351 253 60 40 21 > > email: aman...@scom.uminho.pt | http://www.scom.uminho.pt > > > ----------------------------------------------------------------------------------------------------------------------------------- > > This email is confidential. If you are not the intended recipient, > > you must not disclose or use the information contained in it. > > If you have received this mail in error, please tell us immediately > > by return email and delete the document. > > -- > > Este email é confidêncial. Se não é o destinatário do mesmo, > > não deve nem revelar, nem usar o seu conteúdo. > > Se recebeu esta mensagem por engano, por favor informe-nos > > Imediatamente, devolvendo e apagando este email. > > > > > > > > > > > > *De:* António Mendes [mailto:antonio.men...@wit-software.com > <antonio.men...@wit-software.com>] > *Enviada:* quarta-feira, 23 de setembro de 2015 15:40 > *Para:* radiator@open.com.au > *Assunto:* [RADIATOR] Use FarmSize parameter > > > > Hello all, > > We are running a scenario with an instance acting as a father and > forwarding the traffic for children processes according to some parameters > in request. We done that changing the init script and starting several > instances of radiator(each one in a different port). > > We are noticing that the father process are consuming too much processing > resources and is only using one core, we would like to change this > configuration to allow the distribution of load for all CPU cores available > in the server and to do that we are thinking to use "FarmSize" and create > several instances of father process. > > Do you see any problem with this new approach(I'm a little bit worried > about the write concurrency of log files)? Do you have any concern or > recommendations? > > > Thanks > > -- > > António Mendes > > WIT Software | Software Engineer > > This email was sent under WIT Software's Confidentiality Policy > <https://www.wit-software.com/confidentiality-policy/> > > _______________________________________________ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator > -- Barry Ard barry....@ualberta.ca IST University of Alberta Edmonton, Alberta Canada
_______________________________________________ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
