I’ll add one more… decide now what you want to happen if after all the planning and design something does fail. Depending on the situation the business requirements surrounding failure differ. Some cases accounting is critical so services should stop if it fails in others its far more important that the services stay up and any potential issues get handled post incident. Alister Winfield From: Freeradius-Users <freeradius-users-bounces+alister.winfield=sky.uk@lists.freeradius.org> on behalf of Alan DeKok <aland@deployingradius.com> Date: Tuesday, 21 January 2025 at 15:06 To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: [EXTERNAL] Re: Recommendations for Ensuring Accounting Reliability On Jan 21, 2025, at 4:57 AM, Erdal Emlik via Freeradius-Users <freeradius-users@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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -------------------------------------------------------------------- This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by using the report message button in Outlook or sending them as an attachment to phishing@sky.uk. Thank you -------------------------------------------------------------------- Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD