(RADIATOR) Database support fault tolerance

[Dan Melomedman]

Our users are getting sick and tired due to RADIUS service
unavailability every time something happens to the network where the
database server sits, or the database server itself. To remind, we use
LDAP for authentication, and SQL Server for sessions/logging. LDAP has
been great, where database connectivity has been problematic, and a
major pain in the arse in general. In some cases, Radiator would hang if
there are database connection failures. A failure with the unixODBC client
translates into Radiator process failure.

Right now Radiator's availability is directly dependent on the quality
of the Perl libraries, including the database libraries/clients.
Our service could be much more available if SQL was handled by an outside
process with a queue in the middle. If something happens to this SQL
helper process, the network, or the database server, then the queue simply
grows in size, and Radiator continues running happily, authenticating users.
When the problems are fixed, the queue is relayed to the SQL server, and
no logging records are lost. If we want to be fancy, this extra process
may even be temporarily handling sessions in place of RADONLINE (instead of
simply ignoring them returning OK back to Radiator), and notifying
system administrators when it can't talk to the SQL database. This
system is not only a more resilient design, but more scalable too since
Radiator will return as soon as it writes to the queue, not waiting for
the database server.

Please let me know your thoughts; let's discuss this idea further. Thanks.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.