(RADIATOR) Database support fault tolerance

[Bret Jordan]

Why not just use a redundant authenticator, most DBs including LDAP 
engines can sync between multiple servers, then just point radiator at 
each one and if it can not talk to the first it will fail over to the 
next...  Or better yet, just use a Foundry Server Iron (Layer 7 switch) 
to sit between Radiator and the Database Farm.   Then all the 
connections to the database servers are VIPs (virtual IPs) and the 
switch will handle all the fail over and load balancing for you.

Bret

Dan Melomedman wrote:

>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.
>  
>

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Bret Jordan                       Dean's Office
Computer Administrator   College of Engineering
801.585.3765                 University of Utah
            jordan at coe.utah.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



===
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.