<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Alan DeKok a écrit :
<blockquote cite="mid:48DD419E.80709@deployingradius.com" type="cite">
<pre wrap="">Alexandre Chapellon wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Each radius have a local mysql database to locally store accounting data.
</pre>
</blockquote>
<pre wrap=""><!---->
If nothing will be querying those databases, I suggest *not* using
SQL. It's just not needed.
</pre>
</blockquote>
Right, nothing will query the database directly on radius servers. But
i really need to have one central database that will be queried by
webapps to let users know about thier quota left, time of connection
etc...<br>
<blockquote cite="mid:48DD419E.80709@deployingradius.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">Each local database is replicated to a central database which couls be
used too as a redundancy for accounting if the local one fail (more over
centralized accounting database used to process customers request and/or
complaints).
</pre>
</blockquote>
<pre wrap=""><!---->
RADIUS packets can be replicated to the central server and logged
there. Database replication will work, but will be a lot of load on the
various systems.
</pre>
</blockquote>
<br>
Does this central radius server can log all queries proxied to him to
an sql database (i know i'm boring with SQL accounting database! :))<br>
If i read you well... it 's not! Am i asking too much from SQL? how
else can we achieve it?<br>
<br>
<blockquote cite="mid:48DD419E.80709@deployingradius.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">One centralized mysql database (on another mysql server maybe) to handle
IP allocation using rlm_sqlippool.
</pre>
</blockquote>
<pre wrap=""><!---->
Again, using *one* database for *many* RADIUS servers is very likely
wrong. i.e. it will be slow, fragile, and is likely to not meet your
needs of high availability.
</pre>
</blockquote>
<blockquote cite="mid:48DD419E.80709@deployingradius.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">I have aproximatively 15000 users connected concurently. Does it seems
to you a too weak or inefficient setup?
</pre>
</blockquote>
<pre wrap=""><!---->
Do the math. 15K users, with one accounting packet every 10 minutes.
That's 25 packets/s. It's a nice number, but not too high.
</pre>
<blockquote type="cite">
<pre wrap="">While my priority is high-availability
</pre>
</blockquote>
<pre wrap=""><!---->
Some parts seem too complex, and others too simple.
The IP pool allocation needs to be more robust,</pre>
</blockquote>
you mean splitting pool by NASes and radius server?... then sqlippool
is not really needed anymore?<br>
<blockquote cite="mid:48DD419E.80709@deployingradius.com" type="cite">
<pre wrap=""> and the accounting
replication doesn't need as many pieces.
</pre>
</blockquote>
OK, i trust you but I don't see any chance of having no SQL enabled
accounting. It's almost a requirement for me.<br>
<blockquote cite="mid:48DD419E.80709@deployingradius.com" type="cite">
<pre wrap="">
Alan DeKok.
-
List info/subscribe/unsubscribe? See <a class="moz-txt-link-freetext" href="http://www.freeradius.org/list/users.html">http://www.freeradius.org/list/users.html</a>
</pre>
</blockquote>
</body>
</html>