负载均衡会话保持的理解及使用

一：什么是会话保持

在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中，一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成。由于这几次交互过程是密切相关的，服务器在进行这些交互过程的某一个交互步骤时，往往需要了解上一次交互过程的处理结果，或者上几步的交互过程结果，服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成，而不能被负载均衡器分散到不同的服务器上。

通俗点讲你打800处理一个问题，问题还没有处理完之前，你每次打电话进来，都让你找同一个人处理，避免转给其他人搞不清楚之前处理的情况。

会话保持是负载均衡里面的一个重要概念。

二：应用负载情况下的会话保持

我们现在只支持源地址会话保持，基于http cookie的会话保持。

1：源地址会话保持

简单会话保持也被称为基于源地址的会话保持，是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据。对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去。在设备上可以为“同一IP地址”通过网络掩码进行区分，比如可以通过对IP地址192.168.1.1进行255.255.255.0的网络掩码，这样只要是来自于192.168.1.0/24这个网段的流量负责均衡设备都可以认为他们是来自于同一个用户，这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上。

源地址会话保持里另外一个很重要的参数就是连接超时值，AD会为每一个进行会话保持的会话设定一个时间值，当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值，AD将会将新的连接进行会话保持，但如果这个间隔大于该超时值，AD将会将新来的连接认为是新的会话然后进行负载平衡。

基于原地址的会话保持实现起来简单，只需要根据数据包三、四层的信息就可以实现，效率也比较高。存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时，由于都分配到同一台服务器上，会导致服务器之间的负载严重失衡。另外一种情况上客户机数量很少，但每个客户机都会产生多个并发访问，对这些必发访问也要求通过负均均衡器分配到多个服器上，这时基于客户端源地址的会话保持方法也会导致负载均衡失效。

2：http cookie

我们现在的实现方式为插入cookie。同样有超时时间设置。

当服务器回复的http数据经过设备时，不论这个回复的数据自身带不带cookie，我们都会插入我们自己的cookie，之后通过这个cookie值来进行用户识别。

具体过程：

当客户进行第一次请求时，客户HTTP请求（不带cookie）进入AD， AD根据负载均衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（无论带不带cookie）被发回AD，然后AD插入cookie，将HTTP回复返回到客户端。当客户请求再次发生时，客户HTTP请求（带有上次的cookie）进入AD，然后AD读出自己插入的cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，恢复流量再次经过进入AD时，BIGIP再次写入更新后的会话保持cookie。

如果客户端禁止所有cookie，那么负载均衡会失效，会导致访问服务不成功。

其他还有许多方式可以用做会话保持，需要结合应用系统。例如https的session ID,http head,一些特定应用内部的会话特征等。会话保持的目的就是基于这些特征识别到用户，以便负载这些请求到同一台后端服务器上面去。

三：链路负载情况下的会话保持

原则：对于同一条连接的所有数据包，必须走同一条wan口线路；对于有关联的连接，也必须走同一条wan口线路。

1：代理上网

先走ip_conntrack进行关联连接识别，再添加到会话保持中。会话保持按照<wanIP,LANIP>来实现，意思是一个内网ip访问一个外网IP，将保持从一条链路出去，不再进行重新选路。

2：端口映射不存在会话保持，AD设备不进行干预，完全按照ip_conntrack 来实现。

出来混脸熟来了