1、A10 负载均衡和会话保持在大多数的企业级应用中，客户端与服务器经常需要通过多次的交互才能完成一次事务处理或一笔交易。由于这些交互与用户的身份是紧密相关的，因此，与这个客户端相关的应用请求，往往需要转发至一台服务器完成，而不能被负载均衡器转发至不同的服务器上进行处理。为了实现这一机制，我们需要在负载均衡上配置会话保持（Session Persistence）机制，以确保客户端与应用系统之间的交互不会因为部署了负载均衡而发生问题。实际上，会话保持机制与负载均衡的基本功能是完全矛盾的。负载均衡希望将来自客户端的连接、请求均衡的转发至后端的多台服务器，以避免单台服务器负载过高；而会话保持机制却要求将
2、某些请求转发至同一台服务器进行处理。因此，在实际的部署环境中，我们要根据应用环境的特点，选择适当的会话保持机制。连接和会话的区别在介绍会话保持技术之前，我们必须先花点时间弄清楚一些概念：什么是连接（Connection）、什么是会话（Session），以及这二者之间的区别。需要特别强调的是，如果我们仅仅是谈论负载均衡，会话和连接往往具有相同的含义。但是，如果我们和开发人员沟通这些术语时，这两个术语却具有截然不同的含义。希望广大读者能够注意这其中的区别。在本文中，我想着重说明的是开发人员眼中的连接及会话的含义。通常，在普通的客户端或服务器上，我们把具有相同源地址：端口，和相同目的地址：端口的数据
3、包定义为一个连接。下表是 Windows 系统中用命令 netstat an 输出的部分系统连接状态。1. C:netstat -an 2. 3. 活动连接 4. 5. 协议 本地地址 外部地址 状态 6. 7. 8. TCP 172.31.20.53:47669 122.225.67.240:80 ESTABLISHED 9. TCP 172.31.20.53:47670 122.225.67.240:80 ESTABLISHED 10. TCP 172.31.20.53:47671 122.228.243.240:80 ESTABLISHED 11. TCP 172.31.20.53:47
4、672 110.75.34.138:80 TIME_WAIT 12. TCP 172.31.20.53:47673 110.75.34.138:80 TIME_WAIT 13. TCP 172.31.20.53:47674 110.75.34.138:80 TIME_WAIT 14. TCP 172.31.20.53:47675 122.225.67.240:80 ESTABLISHED 15. TCP 172.31.20.53:47676 122.225.67.240:80 ESTABLISHED 16. TCP 172.31.20.53:47677 122.228.243.240:80 E
5、STABLISHED 17. TCP 172.31.20.53:47679 110.75.24.105:80 ESTABLISHED 18. TCP 172.31.20.53:47681 122.225.67.240:80 ESTABLISHED 19. TCP 172.31.20.53:47682 122.225.67.240:80 ESTABLISHED 20. TCP 172.31.20.53:47683 60.191.143.240:80 ESTABLISHED 21. TCP 172.31.20.53:47684 60.191.143.240:80 ESTABLISHED 22. T
6、CP 192.168.1.4:18231 203.208.46.29:443 CLOSE_WAIT 23. 对于负载均衡来说，情况则稍微发生了一些变化。负载均衡会将来自相同源 IP：端口，发送到相同目的 IP：端口的数据包，通过 NAT 技术做一些转换后，转发至后端的某台固定的服务器。如下表所示，虽然两个 TCP 连接具有相同的源地址，但源端口不同，AX 负载均衡仍然将其识别为两个不同的连接，并且转发至两台不同的服务器进行处理。1. AX#show session 2. 3. 4. Prot Forward Source Forward Dest Reverse Source Reverse
7、Dest Age Hash 5. - 6. Tcp 103.104.157.122:1619 61.22.215.151:80 172.30.2.83:80 103.104.157.122:1619 60 1 7. 8. Tcp 103.104.157.122:1621 61.22.215.151:80 172.30.2.84:80 103.104.157.122:1621 120 3 9. 10. 对于同一个连接中的数据包，负载均衡会将其进行 NAT 转换后，转发至后端固定的服务器进行处理，这是负载均衡最基本、最原始的功能。负载均衡系统内部会专门有一张表来记录这些连接的状况，包括：源 IP：
8、端口、目的 IP：端口、服务器 IP：端口、空闲超时时间（Idle Timeout）等等。这里需要特别说明一下超时时间的意义和定义。由于负载均衡内部记录连接状态的这张表需要消耗系统的内存资源，因此，这张表不可能无限大，所有厂家都会有一定的限制。这张表的大小一般称之为最大并发连接数，也就是系统同时能够容纳的连接数量。考虑到建立这些连接的客户端或服务器会发生一些异常状况，导致这些连接不能被正常终结掉，因此，负载均衡的当前连接状态表项中，设计了一个空闲超时时间的参数。这个参数定义为，当该连接在一定时间内无流量通过时，负载均衡会自动删除该连接条目，释放系统资源。在 AX 中，这个空闲超时时间一般设置为
9、 120 秒。也就是说，如果在 120 秒内，对于某个连接，AX 没有收到任何来自客户端或服务器端的数据包，AX 会主动删除该连接，以释放系统资源。之所以在这里强调这个参数，是为了和后面介绍会话保持机制时提到的会话保持时间有所区别。理解了连接的概念，那么对于会话的概念就会比较容易理解一些。在开发人员眼中，会话一般是指从用户登录应用系统，进行事务处理，直至退出应用系统的整个过程。因此，对于相同的会话，客户端可能会建立多个连接进行处理。如果在客户端和服务器之间部署了负载均衡设备，很有可能，这多个连接会被转发至不同的服务器进行处理。如果服务器之间没有会话信息的同步机制，会导致其他服务器无法识别用户身
10、份，造成用户在和应用系统发生交互时出现异常。常见的异常场景包括：客户端输入了正确的用户名和口令，但却反复跳到登录页面，要求用户进行登录，客户端放入购物篮的物品丢失。因此，会话保持机制的意义就在于，确保将来自相同客户端的请求，转发至后端相同的服务器进行处理。换句话说，就是将客户端与服务器之间建立的多个连接，都发送到相同的服务器进行处理。常见的会话保持机制介绍源地址会话保持源地址会话保持利用客户端的源地址信息，负载均衡会将所有来源于相同源 IP 的连接认为是相同的客户端，并将这些连接转发至相同的服务器进行处理。当我们启用了源地址会话保持机制后，AX 负载均衡在收到新的连接请求时，会首先查询系统的源
11、地址会话保持表，如果查询到该 IP 地址对应的服务器表项，则根据当前表项对应的服务器建立连接，如果没有查询到该源 IP 对应的服务器，则根据当前配置的算法选择服务器。同时，会将当前连接对应的服务器记入源地址会话保持表。这样，当该源 IP 有新的连接请求时，就会根据该表项选择后端的服务器资源。源地址会话保持机制是一种非常简单但又十分高效的会话保持机制。但是，正是这种简单，又造成负载均衡无法很准确的识别客户端，造成后端服务器负载分配不均匀。尤其是当大量的客户端共享同一个 NAT 地址访问服务器资源时，会造成某台服务器的负载分配过高。同时，由于负载均衡系统内部保存会话保持表也会占用一定的资源，因此，
12、当客户端数量巨大的时候，可能会造成会话保持表被耗尽的问题。Cookie 会话保持Cookie 会话保持是利用 HTTP 协议中的 cookie 功能来实现会话保持功能。当客户端的请求中带有负载均衡设置的 cookie 信息，则负载均衡根据 cookie 中的信息来选择服务器；当客户端的请求中没有 cookie 信息，则负载均衡按照算法选择服务器，同时，在服务器响应的 response 头部中，插入 cookie 信息。这样，当该客户端再次访问服务器时，可以确保该客户端的请求会被转发到相同的服务器进行处理。相较于源地址会话保持机制来说，cookie 会话保持能够更加精准的识别客户端，避免了大量客
13、户端共享同一个 NAT 地址访问服务器资源时，源地址会话保持造成的单台服务器负载过高的问题。此外，负载均衡通过分析客户端请求中的 cookie 信息来决定服务器选择，因此，负载均衡无需在系统中维护会话表项，因此，没有会话表项数量的限制。但是，cookie 会话保持机制却比源地址会话保持存在更多的限制。首先，cookie 会话保持只能够在 B/S 架构的应用中使用，也就是说，cookie 会话保持只能够工作在 HTTP 协议下。道理很简单非 HTTP 协议并不支持 cookie 插入。其次，如果浏览器不支持 cookie，即便配置了 cookie 会话保持机制，cookie 会话保持机制也不会起
14、到应有的效果。第三，由于 cookie 会话保持机制中，需要根据负载均衡当前的系统时间来计算一个过期时间，并把该时间设置为 cookie 失效的时间，因此，负载均衡的系统时间不能有太大误差，否则，会话保持机制有可能会失效。对于第三个问题，我们考虑一种场景，当负载均衡的系统时间比正常的时钟慢 20 分钟，而会话保持的超时时间设置为 15 分钟，则客户端在收到负载均衡插入的 cookie 后，会认为该 cookie 已经失效，则在后续的 http 请求中，不会带有负载均衡插入的用于会话保持的cookie。注意：这里的 cookie 是 A10 插入的，不是应用服务器返回 HTTP 响应时插入的！在
15、用 loadrunner 测试 A10 负载均衡功能和性能时，需要增加 A10 插入的的 cookie。在录制 LR 脚本时，可以先打开应用页面，然后在页面上进行几次其他操作，然后录制好的脚本里会自动加上 cookie，包括应用返回的和 A10 插入的：web_add_cookie(“sto-id-10531=EOMKJDAKCJCD; DOMAIN=120.210.236.238“);web_add_cookie(“PHPSESSID=7d52ff757b92; DOMAIN=120.210.236.238“);测试时保留 A10 插入的 cookie（sto-id-10531）就可以进行负
16、载均衡测试。由于 A10 上插入 cookie 后，会有时效性，因此在 A10 上把过期时间改大并且要尽快测试；另外，A10 插入的 cookie 中“sto-id-10531=EOMKJDAKCJCD“的值不是会话级的（不是每个会话对应一个值，而是可以看成服务器主机的标识），每个主机对应一个 sto-id-10531 的值。首次访问请求到达 A10 时，A10 会根据一系列负载均衡策略选择服务器主机，并且在响应时插入 cookie（即插入主机标识），后续该客户端再发送请求时，会带上这个cookie（主机标识），A10 收到后直接按照这个标识进行转发。简单总结一下这两种常见的会话保持机制的优缺点：方法 优点 缺点 适用场景源地址会话保持 适用范围广泛无需负载均衡保持精准时钟需要维护会话表客户端识别仅依靠源地址信息，不够精准各种 B/S、C/S 应用需要会话保持时间较短的应用不需要修改客户端请求或响应需要高性能的场景cookie 会话保持 客户端识别精准 仅支持 B/S 架构应用需要客户端支持 cookie需要负载均衡维持精准的系统时钟B/S 架构应用需要会话保持时间较长的应用在下一篇文章中，我们仍然以 A10 的 AX 负载均衡为例，向大家介绍在具体的场景中，如何配置会话保持机制，在实现会话保持的基础上，又能更加均衡的负载客户端请求。
