跟我一起学Load Balance(4)

作者：[e-mail]
博客：blog.focus-linux.net   linuxfocus.blog.chinaunix.net 

微博：weibo.com/glinuxer

QQ技术群：4367710

 

本文的copyleft归[e-mail]所有，使用GPL发布，可以自由拷贝，转载。但转载请保持文档的完整性，注明原作者及原链接，严禁用于任何商业用途。

=========================================================

本系列文章均来源于书籍《Load Balancing Servers, Firewalls, and Caches》，均为书中的知识点，稍稍加上作者从事这行业的一些经验——应该是不涉及公司机密呵。。。

今天的主题是Session Persistence。前面的应用中，LD设备在分发session的时候，都是基于当前session进行分发。而在HTTP的应用中，一个HTTP的transaction经常会涉及多个TCP连接。这时候，就需要这多条TCP连接都要分发到后端的同一个HTTP server上。而在前面的LD的负载选择算法中，是没有历史信息和状态的。怎么办？Session Persistence就是针对这个问题，而应运而生的。

Session Persistence，就是在一段时间内，对于某一应用的特定用户的所有session，都会被分发到同一个server。为了实现session persistence，LD设备必须能够识别来自同一用户的流量，以及应用的transaction过程。

以TCP连接为例，当LD设备收到第一个syn包时，LD设备要么进行一半的load balance动作，根据server的健康状态和策略，选择一个server，要么根据syn包的内容，判断出该session的用户是否已经在之前选择了某个server，并且需要session persistence。LD设备从syn包中，只能够获得源地址，目的地址，源端口和目的端口，这样就只能通过这四个信息来进行session persistence。回忆一下以前的内容，LD设备可以作为一个TCP proxy，这样LD设备可以将选择server的动作推迟到收到一个完整的应用请求时。这样的话，可以让LD设备就可以根据应用请求来进行session persistence。因此，session persistence就分为2类：1. 根据4层信息；2. 根据7层应用信息。

根据4层信息进行session persistence比较简单。

1） 根据source IP，VIP和port：即发往VIP的同一个port，源自同一个source IP的session被视为一个用户；

2） 根据source IP和VIP：去掉了port。比如在web应用中HTTP的port是80，而HTTPS的port是443。而HTTP和HTTPS属于一个transaction；

3） Port Grouping：将关联的不同的port归为一组。发往同一VIP，且同一个port group中的session将做session persistence处理；

这样的处理，确实简单，但是在某些应用下，却会带来问题。当实际的用户与LD设备中间有proxy设备存在的时候，即实际用户需要通过proxy来访问LD设备，会使session persistence或者SLB不能正常工作。

1）当实际用户在一个transaction中，经过了不同的proxy访问LD设备。从LD设备角度看，不同的proxy具有不同的IP，因此会将其视为不同的用户。从而session persistence无法正常工作；

2）当大量的实际用户都根据同一个proxy访问LD设备时，LD设备将其视为一个用户——因为IP相同，结果session persistence导致所有的请求都分发到了后端同一个设备。无法到达server load balance的预期。

为了实现更好的session persistence，就必须使用第二种方法，根据7层的信息，来进行session persistence。（明天继续）