[RADIATOR] MongoDB \ Accounting

[Hugh Irvine]

Hello Joe -

I would be inclined to use method d) so you get a copy of the accounting requests in a separate process where you can do whatever you need to without impacting your main process.

You would do something like this (assuming you are using Handlers):


…..

<Handler Request-Type = Accounting-Request>

	AuthByPolicy ContinueAlways

	<AuthBy RADIUS>

		# forward a copy to a separate process

		……

		IgnoreAccountingResponse

	</AuthBy>

	<AuthBy SQL>

		# do normal accounting

		…..

	</AuthBy>

</Handler>


Its also a good idea to have separate Radiator processes for authentication and accounting in any case.

regards

Hugh



On 28 Jul 2013, at 18:21, Joe Hughes <joeyconcrete at gmail.com> wrote:

> Hi
> 
> Simple question really.
> 
> I want to introduce MongoDB as a "test" server for storing accounting and session data.
> 
> We currently use MSSQL, it works well, but the large amount of data (and related joins into other data islands) can become unwieldy over time - especially for historic reporting. I have done some work with MongoDB and other systems (with relatively straight forward schemas), and storing accounting\session seems well suited for this.  Don't get me wrong, its not that MSSQL\MySQL aren't up to the task, I just think this is well suited for NoSQL and I am keen to satisfy my technical curiosity..
> 
> I am considering the best ways of getting the accounting data from our RADIUS servers \ SQL databases into MongoDB.
> 
> Looking for some feedback\comments.
> 
> Some options;
> 
> a) Write a accounting hook to break apart the accounting message, construct a JSON request and send it off to a remote application server. * Downside is the risk of blocking\disrupting the main process.
> 
> b) Spool the messages to disk, have an out-of-process script parse the files, construct a JSON (or MongoDB request) , send it to a remote server and delete the file. Downside is some disk\write IO, nothing too taxing. * Out of process = good.
> 
> c) At the DB level, clone the accounting messages into another table. Script reads the rows, processes as above, then deletes the rows. * Some extra DB load.
> 
> d) Possibly silently forwarding (or replicating) the accounting message to another server and doing one of the above
> 
> Anything I have missed. I am leaning towards b) or c)
> 
> Is anybody else using NoSQL for this type of application? Any feedback?
> 
> Regards
> 
> Joe
> 
> 
> 
> 
> 
> 
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator


--

Hugh Irvine
hugh at open.com.au

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. 
Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.