[RADIATOR] Use FarmSize parameter

[Barry Ard]

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.Shtern at 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-bounces at open.com.au [mailto:radiator-bounces at open.com.au]
> *On Behalf Of *Amândio Antunes Gomes Silva
> *Sent:* Thursday, September 24, 2015 4:43 AM
> *To:* António Mendes <antonio.mendes at wit-software.com>;
> radiator at 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: amandio at 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.mendes at wit-software.com
> <antonio.mendes at wit-software.com>]
> *Enviada:* quarta-feira, 23 de setembro de 2015 15:40
> *Para:* radiator at 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 at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
>



-- 

Barry Ard                                   barry.ard at ualberta.ca
IST
University of Alberta
Edmonton, Alberta   Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open.com.au/pipermail/radiator/attachments/20150925/d3ede18c/attachment.html