Recommendations for Ensuring Accounting Reliability

[Alan DeKok]

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.