会话保持
会话保持-客户端源IP会话保持
源IP地址会话保持就是将同一个源IP地址的连接或者请求认为是同一个用户，根据会话保持策略，在会话保持有效期内，将这些发自同一个源IP地址的连接/请求都转发到同一台服务器。
会话保持-Cookie会话保持
当采用基于源地址的会话保持无法做到负载均分时，例如客户端发起连接请求的源IP地址相对固定，发生此类问题通常可采用基于应用层的会话保持方式，Cookie通常是存在于HTTP头中，现如今基于HTTP的应用被广泛使用，因此基于Cookie的会话保持越来越多的出现在服务器负载均衡解决方案中。
局限性：
对于非HTTP协议，或者客户端禁用Cookie，无效。
会话保持-URL哈希（Hash）会话保持
哈希会话保持的一个基本概念就是按照某个Hash因子，根据此因子以及后台存在多少台服务器计算得到的结果来选择将请求分配到那台服务器。哈希会话保持的特点是在后台服务器的健康状态不发生改变的时候，每个特定的Hash因子被分配到的服务器是固定的。其最大的优势是哈希会话保持可以没有会话保持表，而仅仅是根据计算的结果来确定被分配到那台服务器，尤其在一些会话保持表查询的开销已经远远大于Hash计算开销的情况下，采用Hash会话保持可以提高系统的处理能力和响应速度。
URL哈希会话保持通常针对后台采用Cache服务器的应用场景，针对URL进行Hash计算，将同一个URL的请求分配到同一台Cache服务器，这样，对后台的Cache服务器群来说，每台Cache服务器上存放的内容都是不一样的，提高Cache服务器的利用率。
故障案例分析
Q&A案例分析（1）-循环跳转
故障现象：
Web服务端对用户访问的URL进行判断，对于非https的请求，重定向到http站点，结果导致用户一直302跳转。
原因分析：
采用了负载均衡SSL加速功能，在服务端看到所有的用户请求都来自于http。
解决方案：
全站启用SSL加速。
Q&A案例分析（2）-用户Session丢失
故障现象：
用户在http站点上提交数据到同域名的https站点，web程序抛出session丢失的异常，用户提交数据失败。
原因分析：
http和https在负载均衡设备上被认为是2个独立的服务，产生2个独立的TCP链接，会命中不同的真实服务器，导致session丢失。
解决方案：
在负载均衡设备上启用基于真实服务器的会话保持。
Q&A案例分析（3）-客户端源IP取不到
故障现象：
服务端获取不到用户外网的IP地址，看到的都是大量来自于内网特定网段的IP地址。
原因分析：
负载均衡设备启用了用户源地址转换（SNAT）模式，修改了TCP报文中的用户源IP。
解决方案：
负载均衡设备会用用户的外网IP改写x-forwarded-for值，服务端通过获取http协议中request header头的x-forwarded-for值作为用户源IP。IIS日志通过安装插件形式显示用户源IP。
服务器负载均衡设备选型
1.价格因素
硬件设备：F5、 Citrix 、Redware 、A10
软件：LVS、Nginx、Haproxy、zen loadbalance
2.性能
4/7层吞吐量(单位bps)
4/7层新建连接数（单位CPS）
并发连接数
功能模块性能指标（ssl加速、 HTTP压缩、内存Cache）
3.满足真实和未来需求
1）如果确认负载均衡设备对所有应用的处理都是最简单的4层处理，那么理论上选择的负载均衡设备的4层性能稍高于实际性能需求即可。
2）如果确认负载均衡设备对所有应用的处理都是简单的7层处理，那么理论上选择的负载均衡设备的7层性能稍高于实际性能需求即可。
3）如果负载均衡设备处理的应用既有4层的也有7层的，建议按照7层应用的性能来考虑负载均衡设备。
4）如果确认自己的应用经过负载均衡处理时，需要复杂的4层或者7层处理，例如需要根据客户端的地址做策略性分发，需要根据tcp的内容做处理，需要根据HTTP头或者HTTP报文做处理，那么建议选择的负载均衡设备4/7层性能为真实性能需求的两倍。
5）如果负载均衡设备有混合的复杂流量处理并且还开启了一些功能模块，那么建议选择的负载均衡设备4/7层性能为真实性能需求的3倍。
6）考虑到设备需要轻载运行才能更加稳定，所以有可能的话在以上基础上再增加30%的性能。
7）如果还要满足未来几年的发展需求，在以上基础上还要留出未来发展所需要增加的性能。
8）不同负载均衡设备厂家由于不同的架构，使得某些设备在复杂环境下可能也表现的比较优秀，这个客户可以对比判断，但总体来说，以上建议适合于所有厂家的设备。
原文链接：http://www.cnblogs.com/and/p/3366400.html
联系客服
