|
会话保持概述
-
会话保持是负载均衡最常见的问题之一，也是一个相对比较复杂的问题。会话保持有时候又叫做粘滞会话(Sticky Sessions)
在介绍会话保持技术之前，我们必须先花点时间弄清楚一些概念：什么是连接（Connection）、什么是会话（Session），以及这二者之间的区别。需要特别强调的是，如果我们仅仅是谈论负载均衡，会话和连接往往具有相同的含义
从简单的角度来看，如果用户需要登录，那么就可以简单的理解为会话；如果不需要登录，那么就是连接。
实际上，会话保持机制与负载均衡的基本功能是完全矛盾的。负载均衡希望将来自客户端的连接、请求均衡的转发至后端的多台服务器，以避免单台服务器负载过高；而会话保持机制却要求将某些请求转发至同一台服务器进行处理。因此，在实际的部署环境中，我们要根据应用环境的特点，选择适当的会话保持机制
原始负载均衡的基本原理
-
对于同一个连接中的数据包，负载均衡会将其进行NAT转换后，转发至后端固定的服务器进行处理，这是负载均衡最基本、最原始的功能。负载均衡系统内部会专门有一张表来记录这些连接的状况，包括：[源IP：端口]、[目的IP：端口]、[服务器IP：端口]、空闲超时时间（Idle Timeout）等等
由于负载均衡内部记录连接状态的这张表需要消耗系统的内存资源，因此这张表不可能无限大，所有传统厂商都会有一定的限制。这张表的大小一般称之为最大并发连接数，也就是系统同时能够容纳的连接数量。考虑到建立这些连接的客户端或服务器会发生一些异常状况，导致这些连接不能被正常终结掉，因此，负载均衡的当前连接状态表项中，设计了一个空闲超时时间的参数。这个参数定义为，当该连接在一定时间内无流量通过时，负载均衡会自动删除该连接条目，释放系统资源
有了会话之后，使用原始的负载均衡就会有问题，常见的异常场景包括：
因此，会话保持机制的意义就在于，确保将来自相同客户端的请求，转发至后端相同的服务器进行处理。换句话说，就是将客户端与服务器之间建立的多个连接，都发送到相同的服务器进行处理。如果在客户端和服务器之间部署了负载均衡设备，很有可能，这多个连接会被转发至不同的服务器进行处理。如果服务器之间没有会话信息的同步机制，会导致其他服务器无法识别用户身份，造成用户在和应用系统发生交互时出现异常。
在大多数电子商务的应用系统或者需要进行用户身份认证的在线系统中,一个客户与服务器经常经过好几次的交互过程才能完成一笔交易或者是一个请求的完成由于这几次交互过程是密切相关的,服务器在进行这些交互过程的某一个交互步骤时,往往需要了解上一次交互过程的处理结果,或者上几步的交互过程结果,服务器进行下一步操作时需要这就要求所有这些相关的交互过程都由一台服务器完成,而不能被负载均衡器分散到不同的服务器上
而这一系列的相关的交互过程可能是由客户到服务器的一个连接的多次会话完成,也可能是在客户与服务器之间的多个不同连接里的多次会话完成不同连接的多次会话,最典型的例子就是基于http的访问,一个客户完成一笔交易可能需多次点击,而一个新的点击产生的请求,可能会重用上一次点击建立起来的连接,也可能是一个新建的连接
会话保持就是指在负载均衡器上有这么一种机制,可以识别做客户与服务器之间交互过程的关连性,在作负载均衡的同时,还保证一系列相关连的访问请求会保持分配到一台服务器上
一、简单会话保持-基于ip
-
简单会话保持也被称为基于源地址的会话保持，也叫基于IP的会话保持,是指负载均衡器在作负载均衡时是根据访问请求的源地址作为判断关连会话的依据对来自同一IP地址的所有访问请求在作负载均时都会被保持到一台服务器上去负载均衡器可以为“同一IP地址”通过网络掩码进行区分,比如可以通过对IP地址 192.168.1.1进行255.255.255.0的网络掩码,这样只要是来自于192.168.1.0/24这个网段的流量BIGIP都可以认为他们是来自于同一个用户,这样就将把来自于192.168.1.0/24网段的流量会话保持到特定的一台服务器上
简单会话保持里另外一个很重要的参数就是连接超时值,负载均衡器会为每一个进行会话保持的会话设定一个时间值,当一个会话上一次完成到这个会话下次再来之前的间隔如果小于这个超时值,负载均衡器将会将新的连接进行会话保持,但如果这个间隔大于该超时值,负载均衡器将会将新来的连接认为是新的会话然后进行负载平衡简单会话保持实现起来简单,只需要根据数据包三四层的信息就可以实现,效率也比较高
简单会话保持存在的问题就在于当多个客户是通过代理或地址转换的方式来访问服务器时,由于都分配到同一台服务器上,会导致服务器之间的负载严重失衡另外一种情况上客户机数量很少,但每个客户机都会产生多个并发访问,对这些必发访问也要求通过负载均衡器分配到多个服器上,这时基于客户端源地址的会话保持方法也会导致负载均衡失效这个时候，就必须要考虑使用其他的会话保持方式，比如session等
F5 BigIP支持多种的会话保持方法,其中包括:简单会话保持(源地址会话保持)HTTP Header的会话保持,基于SSL Session ID的会话保持,I-Rules会话保持以及基于 HTTP Cookie的会话保持,此外还有基于SIP ID以及Cache设备的会话保持等,但常用的是简单会话保持,HTTP Header的会话保持以及 HTTP Cookie会话保持以及基于I-Rules的会话保持
NginX对简单会话保持的支持
ip_hash
每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session 的问题。
例如：
upstream **nd {
ip_hash;
server 192.168.0.14:88;
server 192.168.0.15:80;
}
二、存session的会话保持方式
-
1、使用数据库存放session，Session信息存储到数据库表，这样实现不同应用服务器间Session信息的共享
适合数据库访问量不大的网站。优点：实现简单； 缺点：由于数据库服务器相对于应用服务器更难扩展且资源更为宝贵，在高并发的Web应用中，最大的性能瓶颈通常在于数据库服务器。因此如果将 Session存储到数据库表，频繁的数据库操作会影响业务。
2、使用文件系统存放session
通过文件系统（比如NFS方式）来实现各台服务器间的Session共享，各台服务器只需要mount共享服务器的存储Session的磁盘即可，实现较为简单。但NFS 对高并发读写的性能并不高，在硬盘I/O性能和网络带宽上存在较大瓶颈，尤其是对于Session这样的小文件的频繁读写操作，适合并发量不大的网站
3、基于Memcached 存储Session
利用Memcached来保存Session数据，直接通过内存的方式，效率自然能够提高不少。 在读写速度上会比 files 时快很多，而且在多个服务器需要共用 session 时会比较方便，将这些服务器都配置成使用同一组 memcached 服务器就可以，减少了额外的工作量。缺点： session 数据都保存在 memory 中，一旦宕机，数据将会丢失。但对 session 数据来说并不是严重的问题。如果网站访问量太大，session太多的时候，memcached会将不常用的部分删除，但是如果用户隔离了一段时间之后继续使用，已经全部乱套了。
三、基于Cookie的会话保持
-
在Cookie插入模式下，CLB将负责插入cookie，后端服务器无需作出任何修改.当客户进行第一次请求时，客户HTTP请求（不带cookie）进入CLB， CLB根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行HTTP回复（不带cookie）被发回CLB，然后CLB插入cookie，将HTTP回复返回到客户端。
当客户请求再次发生时，客户HTTP请求（带有上次CLB插入的cookie）进入CLB，然后CLB读出cookie里的会话保持数值，将HTTP请求（带有与上面同样的cookie）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入cookie，HTTP回复将不带有cookie，恢复流量再次经过进入CLB时，CLB再次写入更新后的会话保持cookie。
|
本文出自 “火星男-神自不凡” 博客，请务必保留此出处http://marsman.blog.51cto.com/6410055/1912040
