我们的网络设置由分布在全球 5 个不同位置的 5 个网络接入服务器组成，预计在未来几天内将扩展到 15 个网络接入服务器，未来还会扩展到更多。目前我们使用脚本进行身份验证，但我们计划使用基于 freeradius 的 AAA 对这些 NAS 服务器进行身份验证和记账，因为利用记账数据可以带来很多好处。预计未来几天用户负载将增长到数十万用户。我的问题是从可扩展性的角度向具有此类架构实践经验的专家提出的。在这样的设置中使用哪种 freeradius 拓扑最好？
由多个半径节点组成的集中式半径 AAA 服务是否比分布式半径 AAA 服务（即每个 NAS 一个半径）更好，为什么？我们希望在授权期间利用会计数据，因此分布式半径服务将需要几乎实时同步会计数据以及用户身份验证数据。但是，由于存在 10 个不同的位置，因此很难实现实时数据同步。我读过有关将半径查询转发到中央半径服务器的半径代理服务器的文章，但是，我不明白它与直接从 NAS 使用集中式半径服务相比有什么好处。即所有 NAS 都指向相同的半径服务。
如果考虑分布式半径服务，radrelays 可能是一种可行的方法，但 rad 中继似乎对于主到备用类型的设置很有用，其中半径节点的数量大多为两个，而且我不确定如果它们必须在这么多不同的半径服务器之间同步数据，它们是否会很好用。
如果有人能给我指明正确的方向，我将不胜感激。
答案1
如果您关注的是可靠性
分布式架构具有本地复制数据副本的优点，其优点是冗余，并减少延迟。
同步并不难实现，OpenLDAP 的 syncrepl 协议在中心辐射型甚至网状拓扑中表现良好。它将根据需要执行部分和全部数据重新同步。新实例在首次启动时应与主实例同步。
但是，您必须管理每个实例（使用 ansible 或 salt），并在出现问题时纠正故障。
如果可能的话，将服务器以“共享命运”的配置放置在每个 NAS 旁边会增加硬件成本。
您实际上没有提供足够的有关 NAS 的信息来判断这是否合适。客户端会在 NAS 之间发生故障吗？
如果你注重的是管理的便捷性
在冗余负载均衡器（提示）后面拥有单个（集群） RADIUS 服务器的优点是简化了管理。
一对服务器可能足以处理多达一百万用户的负载。每个 FreeRADIUS 实例应该能够在中等硬件上处理大约 20,000-30,000 次身份验证，而运行 MDB 的 OpenLDAP 实例则无法处理。
使用更少的实例，升级、监控和修复数据库问题变得更加简单。
此配置中的服务器代表单点故障。
如果 NAS 开始出现错误并且用流量淹没身份验证服务器，则系统崩溃的可能性会更大。
如果 NAS 和中央服务器之间的网络链接中断，NAS 将无法验证用户。
代理服务器
它们有时可用作聚合器或在联合体中发挥作用，但它们本身在直通配置中实际上并没有起到什么作用。
缓存代理服务器很有用，因为它们可以减轻身份验证服务器的部分负载。
在 ISP 环境中，很大一部分流量都是由拒绝组成的，因为客户端将不断重新进行身份验证。
如果缓存代理服务器先前见过拒绝，或者中央服务器处于离线状态并且先前见过接受，则缓存代理服务器可以代表中央服务器做出响应。