Recommendations for Ensuring Accounting Reliability

[Erdal Emlik]

Really thank you so much Alan.
iPhone’umdan gönderildi

> Alan DeKok <aland at deployingradius.com> şunları yazdı (21 Oca 2025 18:06):
> 
> On Jan 21, 2025, at 4:57 AM, Erdal Emlik via Freeradius-Users <freeradius-users at lists.freeradius.org> wrote:
>> I am currently working with a RADIUS ecosystem that includes proxies and backend servers, where the proxies forward incoming Accounting-Request packets from NAS devices directly to the backend. In case of issues with the backend servers or their dependent SQL systems, I am exploring ways to prevent the loss of accounting records and ensure reliable processing.
> 
>  The sad answer is that there UDP packets can get lost, and there isn't much you can do about that.
> 
>  The more practical answer here is "make sure that critical systems stay up".  If systems go down, then no amount of queueing will help.  :(
> 
>> I have reviewed the proxy-robust-accounting <https://freeradius.org/> documentation and am considering a couple of approaches:
>> 1. Using the detail module in FreeRADIUS to temporarily store accounting requests locally when the SQL module fails and retry processing them later. However, I am concerned about the potential impact on disk space, especially in high-traffic scenarios or during prolonged outages.
> 
>   What costs more, losing data, or buying more disk space?
> 
>> 2. Forwarding accounting requests from the proxy to an external queue, such as Elasticsearch or Kafka, as an alternative to directly relying on the backend SQL servers during failure scenarios.
> 
>  Where do those queues store the data?  Changing one queue for another doesn't necessarily solve anything.
> 
>  The main benefit of elastic search / kafka is that they are have much more modern designs than RADIUS.  RADIUS goes back to 1991, and there is very little you can do about changing how RADIUS works.
> 
>  The main benefit of kafka is to distribute RADIUS traffic.  i.e. Instead of having the front-end servers RADIUS proxying to back-ends, have the front-end send the packets to kafka.  The kafka back-ends can then write the packets to SQL.
> 
>  That may get you better distribution and higher availability.  However, it wont' solve the problem of "the back end is down".  And the back-end systems won't understand RADIUS, and therefore won't be able to do the merge the RADIUS accounting data correctly.
> 
>> I would like to hear your thoughts on the feasibility of these approaches, as well as any recommendations or best practices for safeguarding accounting records in a setup involving proxies and backends.
> 
> 1) design the networks *assuming* that things will go wrong.
> 
> 2) don't let critical systems go down for extended periods of time
> 
> 3) ensure that there are enough resources available to deal with outages.
> 
>  Alan DeKok.
>