基于LVS的AAA负载均衡架构实践

  一、背景

  项目背景是某企业的AAA管理系统, AAA 即 Authentication(认证)、Authorization(授权)、Accounting(记账),是网络设备的一种集中化管理机制,可以在不同设备上为用户设置不同的权限,对网络安全起到监视作用。

  AAA服务是基于TACACS+协议(Terminal Access Controller Access Control System Plus),TACACS+是在 TACACS 协议的基础上进行了功能增强的安全协议,最早由Cicso提出并开放标准。该协议与 RADIUS 协议的功能类似,采用客户端/服务器模式实现 网元与 TACACS+ 服务器之间的通信,使用TCP 49端口。

  每次TACACS+ 交互主要实现: 认证 (Authentication): 确认访问网络的用户身份,判断访问者是否合法 授权( Authorization ): 对通过认证的用户,授权其可以使用哪些服务 记账( Accounting ):记录用户的操作行为、发生时间

  1.问题描述

  系统架构如下图所示,服务器采用一主一备模式,一般情况下由Master服务器处理请求,如果它故障或者负荷过高、无法快速响应请求,网元会将请求发送到BackUP服务器处理。AAA Server上运行守护进程处理请求,记为TACACSD。

物联网

  容量计算>服务端资源需求T= 认证请求规模g(n) / TACACSD运算能力 f(n)

  在很长一段时间内,原有架构可以满足应用需求,但是随着集中化的深入推进,资源不足的问题日益严重:Master负荷早已爆满,BackUP的负荷也几乎与Master相当,而且请求从Master切换到BackUP的时候,非常容易引起失败。 主要有三个关键因子的变化: 1、管理设备数量增长10倍,而且还要继续增长 2、网络配置自动化,单一网元的巡检、配置操作有数量级的提升

  3、TACACSD程序本身存在性能瓶颈,CPU消耗随着设备数量增长而增长

  前两个因素属于业务需求,不能调整,程序性能问题涉及开发周期问题(这块以后再单独分析),迫于业务压力,我们必须快速寻找一种变通方案。

  2.选型要求

  在选择适用方案之前,我们必须考虑以下几个要求:

  可伸缩性(Scalability)当服务规模(设备数量、自动化操作次数)的负载增长时,系统能被扩展来满足需求(弹性扩展服务能力),且不降低服务质量。

  高可用性(Availability)尽管部分硬件和软件会发生故障,整个系统的服务必须是每天24小时每星期7天可用的。(必须去除原来过于依赖单一服务器的瓶颈)

  可管理性(Manageability)整个实现应该易于管理,提供灵活的负载均衡策略支持。

  价格有效性(Cost-effectiveness)整个实现是经济的。这个怎么说呢,比如这个问题吧,有人说:买四层交换机啊? 没钱!宇宙上最好服务器来一台? 没钱!! 于是我们的主要探索方向放在了开源软件,感谢开源社区解救穷人。

  二、前戏

  我们首先想到的是HAProxy,一款经典的负载均衡开源软件。 特别是具备以下几个特点:配置维护简单,支持热备,支持后端服务器的状态检测,可以自动摘除故障服务器;支持TCP 代理;支持Session的保持。

  tcp

  The instance will work in pure TCP mode. A full-duplex connection will be established between clients and servers, and no layer 7 examination will be performed. This is the default mode. It should be used for SSL, SSH, SMTP, ...

  vi haproxy.cfg

  listen AAA-Cluster

  mode tcp

  bind 49

  option tcplog

  source 0.0.0.0 usesrc clientip

  server AAA-Server-210 192.168.3.10:49

  server AAA-Server-211 192.168.3.11:49

  1.HAProxy+TProxy

  当我们满怀希望地推进之时,一个要命的问题摆在面前:后端的AAA服务器上看到的连接的Source IP都不再是用户原始的IP,而是前端的HAProxy服务器的IP,

物联网

  官方文档对于source调度算法的描述:

  source

  The source IP address is hashed and divided by the total weight of the > running servers to designate which server will receive the request. This ensures that the same client IP address will always reach the same server as long as no server goes down or up. If the hash result changes due to the number of running servers changing, many clients will be directed to a different server.