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