[RADIATOR] A few tips on performance and high availabilty

[Alexander Hartmaier]

Thanks for sharing those best-practises with the list!

On 2012-12-03 17:17, Anders Bandholm wrote:
> Hi list!
>
> We have been running Radiator for several purposes for around 5 years,
> and I would like to share a few tricks that we have learned...
>
>
> Memcached
> ---------
>
> Memcached is distributed cache, with a simple Perl-api. We run an instance
> of memcached on each Radius-server. We use it for several things:
>
>   * We use it in a PostAuthHook for rejecting users with too many login
>     failures (to prevent brute-force password guessing)
>
>   * We cache certain SOAP-calls. Since Radiator is single-threaded, fast
>     answers from backends is imperative as you probably know. We use
>     memcached in a "defensive" way: We always make the SOAP-call first,
>     but with a low timeout (0.1 sec) If the call times out, we use the
>     cache - if not we save the result to the cache.
>
>   * we have started a service for our customers (Danish schools) where
>     they get alerts by email when user up- or download exceeds certain
>     thresholds. This is handled by summing up bytes from accounting
>     records in a PostProcessingHook. The counters for each user is kept
>     in memcached.
>
> It seems to me that memcached is a perfect companion for Radiator!
>
> Memcached is of course not a database, and if you shut down one of
> the memcached instances you will lose part of your cache. But for the
> purposes above it works very well.
>
> The Perl module is Cache::Memcached.
>
> If you run Linux memcached is probably packaged for you - on Debian/Ubuntu
> you need packages like these:
>
>     memcached
>     libcache-memcached-perl
>     libmemcached-tools
>
>
> Two other tricks
> ----------------
>
>  1) We have started using Gearman to make it possible for the main radii
>     to offload certain slow things to other servers. As explained above
>     our radii keep track of user up/downloads through acct-records, and
>     when a certain limit is reached we send email alerts to the relevant
>     admin. But we don't want Radiator itself to send the email - we submit
>     a job through Gearman (Perl: Gearman::Client and Gearman::Worker)
>     This is a very promising technology and I expect we will use it more
>     in the future.
I'd use a local MTA for queuing the mails to simplify things.
>
>  2) Simple trick - probably used by many of you: We have the client list
>     in an Oracle database, but since the database is sometimes down
>     for maintenance, we generate static file-based client-lists every
>     10 minutes instead, and reload Radiator when they change. If Oracle
>     is down, Radiator does not suffer. (The 10 minutes interval is
>     overkill for most installations ;-)
The client list is fine from the Oracle database directly because it
isn't updated if the db query fails.

But for users (AuthBy SQL) we use a local SQLite database which is
created from the Oracle database via a Perl script every hour or manually.
That has the advantage of being able to switch between it and the Oracle
database without reconfiguring Radiator much, just the dsn.
Also reloading Radiator isn't required with SQLite.
>
>
> Cheers,
> Anders

--
Best regards, Alex



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*