Radius服务器负载均衡解决方案

Radius协议概述

Raidus（Remote Authentication Dial In User Service）是对远端拨号接入用户的认证服务，Radius服务分客户端和服务器端，典型示意图如下。

通常对Radius协议的服务端口号是1645（认证）、1646（计费）或1812（认证）、1813（计费）。

Radius通信是用UDP协议以“请求 - 响应”方式进行的，即：客户发送一个请求包，服务器收到包后给予响应，其数据包格式如下：

主要字段解释如下：

• Code：包类型；1字节；指示RADIUS包的类型。常用包类型定义如下：

1 Access-Request——请求认证过程

2 Access-Accept——认证响应过程

3 Access-Reject——认证拒绝过程

4 Accounting-Request——请求计费过程

5 Accounting-Response——计费响应过程

• Identifier：包标识；1字节；用于匹配请求包和响应包，同一组请求包和响应包的Identifier应相同。该字段的取值范围为0～255；协议规定：
  1. 在任何时间，发给同一个RADIUS服务器的不同包的Identifier域不能相同，如果出现相同的情况，RADIUS将认为后一个包是前一个包的拷贝而不对其进行处理。
  2. Radius针对某个请求包的响应包应与该请求包在Identifier上相匹配（相同）。
• Length：包长度；2字节；整个包的长度。
• Authenticator：验证字；16字节；用于对包进行签名。
• Attributes：属性 ，如用户名，格式如下：

Radius服务器负载均衡

当单台Radius服务器性能不足以满足用户认证需求或者为了提高认证服务器可用性时，引入负载均衡器成为理所当然。下图为典型Radius服务器负载均衡示意图。

由于Radius协议的特殊性，负载均衡设备需要以下功能以实现可运营的Radius服务器负载均衡：

• 基于应用的健康检查。需要发出认证请求，认证通过才标识该服务器为“up”，有些情况下还需要在请求中附带一些Radius属性。
• 基于Radius消息的负载均衡。典型应用中，Radius 客户端数量通常不多，如城域网中的BRAS（宽带接入服务器），但每个客户端会发送大量的Radius认证计费数据包，而且往往是使用相同源端口发出的。如果基于简单的4层UDP处理，1个Radius客户端的所有请求可能全部到达一台服务器上，导致服务器负载不均匀，甚至个别服务器由于过载而瘫痪。因此，负载均衡设备必须可以将来自同一IP地址同一源UDP端口的请求均匀分配到多台服务器上。前面提到的Radius ID字段可以帮助解决这个问题，负载均衡设备可以基于Radius客户端IP+源端口+Radius ID进行负载均衡。
• 基于Radius属性的服务器保持。实际应用中，Radius服务器要求基于特定radius属性实现服务器保持，如基于用户名保持，来自同一用户的所有请求在一定时间内必须由同一台服务器处理，否则会导致计费问题。这就要求负载均衡设备必须解析所有属性字段，找到相应的属性，并建立一张该属性与所分配服务器的对应表。基于源IP地址的保持会导致单台客户端请求全部分配到同一服务器，因此不适用于Radius负载均衡。
• 认证与计费请求保持到相同服务器。Radius认证与计费采用了不同UDP端口（如1812和1813），服务器要求来自同一用户的认证与计费信息到达同一服务器的1812和1813端口。
• 速率限制。限制单台服务器的请求速率以保护Radius服务器。
• 负载均衡设备本身的CPU均衡。由于Radius客户端使用相同源IP和源端口，通常的CPU分配方式会导致负载均衡设备本身CPU严重不均衡，甚至只有一个CPU在工作。因此，Radius服务器负载均衡要求负载均衡设备可以基于Radius ID分配CPU，以实现更高的性能。

以上功能任何一项不满足，都有可能导致业务不可用或者负载不均衡乃至服务器瘫痪。而不同用户的应用需求又要求负载均衡设备可以灵活地基于各种Radius属性进行服务器选择和保持，对于没有自定义脚本功能的设备很难满足这些需求。后续会将A10的AX产品如何在Radius服务器负载均衡中部署做单独介绍。

(R.S.)

本文转自 virtualadc 51CTO博客，原文链接:

http://blog.51cto.com/virtualadc/963350