RADIUS 服务器高可用性:主-主架构 vs 主-备架构
为评估 RADIUS 高可用性架构的 IT 经理和网络架构师提供的权威技术参考指南。它对比了主-主和主-备部署,详细说明了数据库复制要求,并解释了云 RADIUS 如何为企业场所缓解故障转移延迟。
Listen to this guide
View podcast transcript

执行摘要
对于企业网络而言,身份验证是二元的:要么完美运行,要么业务运营完全停止。RADIUS(远程认证拨号用户服务)是现代场所中 IEEE 802.1X、WPA3 企业版和 访客 WiFi 部署的关键守门人。与在负载下逐渐降级的应用服务不同,RADIUS 故障会立即阻止用户、销售点终端和运营设备访问网络。
本技术参考指南评估了部署高可用性 RADIUS 基础设施的架构模型。具体对比了传统的主-备配置与现代的主-主集群。对于管理高密度环境(如 零售 、 酒店业 和体育场馆)的 IT 经理、网络架构师和场馆运营主管来说,理解这些故障转移策略、负载均衡机制和数据库复制要求至关重要。
此外,本指南还探讨了云 RADIUS 平台如何抽象高可用性的复杂性,提供自动故障转移和弹性可扩展性,而无需承担维护冗余本地基础设施的运营负担。通过应用这些厂商中立的实践,工程团队可以设计消除单点故障并满足严格正常运行时间服务级别协议(SLA)的身份验证架构。
技术深入探讨:理解 RADIUS 架构
RADIUS 作为一种基于 UDP 的客户端-服务器协议运行,通常使用端口 1812 进行身份验证,端口 1813 进行计费,正如 RFC 2865 和 RFC 2866 所定义。UDP 身份验证请求的无状态特性为高可用性设计提供了结构优势。由于每个 Access-Request 数据包都包含所有必要的凭据和参数,集群中的任何 RADIUS 服务器都可以独立处理任何请求,而无需为身份验证阶段本身进行复杂的状态同步。
主-备架构
在主-备(或主-从)部署中,一个 RADIUS 服务器处理所有传入的身份验证和计费流量。另外一个服务器保持在线但处于空闲状态,接收数据库复制更新,但不主动响应网络接入设备(NAD),如无线接入点、交换机或 VPN 网关。
当主服务器发生故障时,NAD 检测到超时,并将后续请求重定向到备用服务器。故障转移检测时间完全取决于 NAD 的配置计时器。典型的 NAD 发送 RADIUS 请求,并等待默认的数据包超时(通常为两秒)。如果没有收到响应,它会重试。按照每服务器三次尝试的标准配置,NAD 可能需要等待长达六秒的时间才能宣布主服务器故障并切换到备用服务器。在配置了三台服务器的环境中,此故障转移时间可能延长至 18 秒。对于繁忙的 酒店业 场所或处理交易的 零售 环境来说,这种延迟意味着明显的服务中断。
主-主架构
相反,主-主架构将身份验证负载同时分布到多个运行中的 RADIUS 服务器上。流量通过 NAD 上的轮询配置或专用负载均衡器路由到集群。

该模型消除了主-备设置固有的故障转移检测延迟。如果某个节点发生故障,负载均衡器(或使用轮询的 NAD)会根据健康检查间隔,通常在一到两秒内停止将流量路由到无响应的服务器。其余的活动节点会立即吸收流量。此外,主-主集群可以水平扩展;只需向集群添加更多节点即可为高密度活动增加容量。
数据库复制挑战
虽然 RADIUS 身份验证是无状态的,但 RADIUS 计费本质上是有状态的。它跟踪会话启动(Start)、持续使用(Interim-Update)和终止(Stop)。对于使用 WiFi 分析 或计费系统的场所,这些计费数据必须在所有节点间保持一致。
为 RADIUS 集群配备复制数据库(例如与 FreeRADIUS 集成的 MySQL 或 MariaDB)对于实现强大的高可用性是必需的。对于主-主部署,需要同步多主复制——例如 Galera Cluster 或 MySQL NDB Cluster。同步复制可确保计费记录同时提交到所有节点,从而防止某个节点发生故障时数据丢失。传统的主-备设置中常使用的异步复制会引入复制延迟。如果主节点在备用节点收到更新之前发生故障,则活动会话数据将永久丢失,这可能会违反 PCI DSS 等合规框架。
实施指南:云 vs 本地部署
架构决策不仅涉及如何集群服务器,还涉及这些服务器的存放位置。对于多站点运营商来说,将身份验证流量回传到集中式本地数据中心会引入广域网延迟,并在广域网链路处造成单点故障。
云 RADIUS 平台
云 RADIUS 服务通过在全球多个可用区托管身份验证基础设施,解决了地理分布挑战。当用户从分支机构连接时,请求会被路由到最近的云边缘节点,最大限度地减少延迟。

云平台本质上采用主-主架构。可用区之间的故障转移由提供商内部的负载均衡自动处理,将复杂性完全抽象化,无需客户工程团队操心。该模式通常提供 99.99% 的正常运行时间 SLA,并消除了手动证书管理、操作系统补丁和数据库复制调优的需要。对于在分布式园区部署 寻路 或 传感器 的组织来说,云托管的身份验证确保了策略执行的一致性,而不依赖于本地硬件。
本地部署注意事项
在高度受监管的行业中运营的组织——例如特定的 医疗保健 或政府环境——可能因严格的数据主权要求而需要进行本地部署。在这些情况下,部署带有 Galera 同步复制的 FreeRADIUS 主-主集群可提供最高级别的弹性。
但是,工程团队必须考虑运维开销。跨多个节点管理 TLS 证书、确保配置一致性以及主动监控数据库复制健康状况都需要专门的管理资源。硬件负载均衡器必须专门配置以支持 UDP 流量并具有适当的 RADIUS 健康检查,因为许多标准负载均衡器仅针对 TCP HTTP/HTTPS 流量进行了优化。
RADIUS 高可用性最佳实践
- 分布而非复制:对于超过 500 个并发用户的部署,优先考虑主-主架构而非主-备设置,以最大化吞吐量并最小化故障转移延迟。
- 实现同步复制:通过使用同步多主数据库复制(例如 Galera Cluster)而非异步主从模型来保护有状态的计费数据。
- 标准化证书信任:在主-主集群中,确保所有节点提供相同的服务器证书或来自完全相同的证书颁发机构(CA)链的证书。任何差异都会导致节点切换时 EAP-TLS 和 PEAP 握手失败。
- 调整 NAD 计时器:优化网络接入设备上的 RADIUS 重试和超时计时器。两秒超时加两次重试可在快速故障转移检测与防止轻微网络拥塞期间过早故障转移之间取得平衡。
- 测试故障场景:将备用节点视为生产系统。定期模拟节点故障、数据库失步和广域网链路中断,以验证自动故障转移机制是否按设计运行。
故障排除与风险缓解
RADIUS 高可用性中最常见的故障模式是配置漂移。在主-备设置中,管理员经常更新主节点上的策略或更新证书,却忽略了备用节点。当发生故障转移时,备用节点会因凭据过期或策略过时而拒绝合法流量。
为了降低此风险,应实施配置管理工具(如 Ansible 或 Terraform),将所有更改对称地部署到所有节点。对于证书管理,应利用自动续期协议(如 ACME),将其配置为在整个集群中同时分发更新后的证书。
另一个重大风险是负载均衡器配置错误。如果负载均衡器未执行应用层健康检查(特别是验证 UDP 端口 1812 的响应能力),它可能会继续将流量路由到操作系统正在运行但 RADIUS 守护进程已崩溃的节点。确保健康检查明确验证 RADIUS 服务的可用性。
投资回报率与业务影响
稳健的 RADIUS 高可用性的投资回报率主要通过风险缓解和运营效率来衡量。身份验证中断会导致员工生产力立即下降,并对面向公众的场所造成严重的声誉损害。
通过从手动、单服务器部署过渡到自动化的主-主架构(尤其是通过云 RADIUS),组织可以收回大量先前用于日常维护的工程时间。这种运营效率使网络团队能够专注于战略计划,例如部署 现代企业的核心 SD-WAN 优势 或优化高密度覆盖,而不是忙于处理身份验证故障。最终,可靠的身份验证是所有后续网络服务所依赖的基础层。
Key Definitions
主-主架构
一种高可用性设计,其中多个 RADIUS 服务器同时处理认证请求,分配负载并提供即时故障转移,无需检测延迟。
对于高密度场所(体育场馆、大型零售商场)至关重要,单台服务器无法处理峰值认证激增。
主-备架构
一种冗余模型,其中主服务器处理所有流量,备用服务器保持空闲待机,直到主服务器发生故障。
适用于较小、对成本敏感的部署,但在网络接入设备检测到故障时会造成 6-18 秒的故障转移延迟。
同步复制
一种数据库复制方法,在事务被视为完成之前,数据会同时写入集群中的所有节点。
对于主-主 RADIUS 计费数据库(如 Galera Cluster)是强制性的,以防止数据丢失并确保合规性。
异步复制
一种数据库复制方式,主节点记录数据,然后将其复制到备用节点,引入轻微延迟(滞后)。
常用于主-备设置,但如果主节点突然故障,存在丢失最近计费记录的风险。
网络接入设备(NAD)
代表用户向 RADIUS 服务器请求认证的硬件组件(例如 WiFi 接入点、交换机或 VPN 网关)。
NAD 的内部重试和超时计时器决定了主-备故障转移发生的速度。
无状态协议
一种通信协议,将每个请求视为独立的事务,与之前的任何请求无关。
基于 UDP 的 RADIUS 认证是无状态的,允许负载均衡器将任何请求无缝路由到任何活动服务器。
配置漂移
备用或备份服务器在策略、更新或证书方面随着时间的推移与主服务器不同步的现象。
当备用节点被迫接管时,主-备 RADIUS 部署中故障的主要原因。
云 RADIUS
一种托管在全球分布式云基础设施上的认证服务,提供内置的主-主冗余和自动扩展。
取代了 IT 团队手动构建、修补和监控冗余本地 RADIUS 服务器的需要。
Worked Examples
一家欧洲酒店集团在六个国家管理着 45 家酒店。他们目前在每个酒店运行独立的 FreeRADIUS 虚拟机。最近,一个地点的 TLS 证书过期,导致在大型会议期间整个访客 WiFi 中断。他们应该如何重新设计其身份验证架构,以防止局部中断并减少维护开销?
酒店集团应从本地化的单节点 FreeRADIUS 实例迁移到采用主-主架构的集中式云 RADIUS 平台。通过利用具有地理分布式边缘节点的云提供商,来自每个酒店的认证请求被路由到最近的区域节点,从而最大程度地减少延迟。集中式策略管理允许 IT 团队一次性定义认证规则并将其全局应用。云提供商自动处理 TLS 证书轮换、操作系统补丁和数据库复制。
一个国家级体育场正在为一场 6 万人参加的活动做准备。他们目前的 RADIUS 设置是主-备配置。在负载测试期间,当闸门打开时,主服务器处理每分钟 8,000 次认证请求而达到饱和,导致严重的连接延迟,而备用服务器则完全空闲。他们如何优化此部署?
网络工程团队必须将部署从主-备转换为主-主。首先,他们应该重新配置体育场的网络接入设备(NAD),以在两者之间使用轮询负载均衡,从而将认证吞吐量立即翻倍。其次,他们应部署第三个 RADIUS 节点,为峰值激增提供必要的余量。最后,为了确保计费数据在所有三个活动节点间保持一致,他们必须实施同步多主数据库复制解决方案,例如 Galera Cluster。
Practice Questions
Q1. 您的企业零售客户要求为其销售点终端提供一个高可用的 RADIUS 解决方案。他们有严格的 PCI DSS 合规要求,规定在服务器故障转移期间绝对不能丢失任何计费会话数据。您必须为 RADIUS 后端实施哪种数据库复制策略?
Hint: 考虑数据同时写入与事后复制数据之间的区别。
View model answer
您必须实施同步复制(例如 Galera Cluster 或 MySQL NDB Cluster)。同步复制确保在确认事务之前,计费记录同时提交到所有节点。如果使用异步复制,节点故障可能导致尚未复制到备用数据库的近期事务丢失,从而违反严格的合规要求。
Q2. 一所大学校园网络使用主-备 RADIUS 设置。学生们抱怨当主服务器进行维护时,他们的笔记本电脑需要将近 20 秒才能连接到 WiFi。接入点配置了 3 秒的 RADIUS 超时和 5 次重试。如何在不改变服务器架构的情况下减少故障转移延迟?
Hint: 根据 NAD 计时器计算在尝试备用服务器之前的最大等待时间。
View model answer
您应该调整网络接入设备(接入点)上的计时器。目前,AP 等待 3 秒并重试 5 次,导致在故障转移到备用服务器之前有 18 秒的延迟(3 秒 × 6 次总尝试)。将配置减少为 2 秒超时和 2 次重试后,故障转移检测时间降至 6 秒,大大改善了维护期间的用户体验。
Q3. 您正在将一个多站点企业网络从主-备本地 RADIUS 服务器迁移到主-主云 RADIUS 平台。在试点阶段,设备成功对云节点 A 进行身份验证,但当负载均衡器将它们路由到云节点 B 时,EAP-TLS 握手失败。最可能的配置错误是什么?
Hint: 考虑客户端设备在与新服务器建立安全 EAP 隧道时验证什么。
View model answer
最可能的问题是证书信任不匹配。在主-主集群中,所有 RADIUS 节点都必须提供完全相同的服务器证书(或由完全相同的受信任 CA 链颁发的证书)。如果云节点 B 提供了客户端设备不信任的不同证书,则客户端将拒绝 EAP-TLS 握手,导致身份验证失败,尽管服务器运行正常。