会话保持解决方案及NetScaler会话保持概述

 

一、为什么需要会话保持

如果我们将后端的Web服务器分为两组，一组是静态内容服务器，一组是动态内容服务器，那么我们再进行反向代理的时候，反向代理服务器通过判断资源文件的后缀名，决定将其调度至后端的那一组服务上。如果我们的后端服务器静态内容和动态内容都分别有多台，那么反向代理服务器还需要对其进行负载均衡，然后觉得资源调度到那一台服务器。那么对于静态内容的服务器，因为静态内容是不会处理会话的，所以在进行负载均衡时我们不用考虑其会话保持。做最简单的和最直接的轮询就好了，如果服务器的性能不一样的话，就做加权轮询即可。当然如果说后端静态服务器的资源大小区别也非常大，那么轮询的方式对负载均衡的方式来讲，效果不是特别明显，那可能需要使用最少连接数的负载均衡方式来处理这类资源情况，最少连接是可以考虑当前连接的服务器的负载情况，能保证结果公平。这是对于静态内容的服务器来说，那么对于动态内容的服务器，因为动态内容涉及到处理会话，我们就需要考虑负载均衡间服务器的会话保持了。会话保持是指在负载均衡器上有一种机制，在作负载均衡的同时，还保证同一用户相关连的访问请求会被分配到同一台服务器上。

举例来说，网络银行的服务门户网站。用户通过输入用户名和密码登录到应用系统中，一旦登录成功，用户可以做很多业务操作。例如检查帐户余额，在线转帐等。

 如果没有配置会话保持，那么可能出现这样的情况:用户登录的时候，系统选择了Server1进行认证，通过认证以后，用户接下来进行业务操作时(比如转帐)，此时系统又选择了Server2或Server3对用户进行服务，这时问题就出现了，因为Server2或Server3上没有用户交易状态的信息，所以Server2或Server3会认为用户没有通过认证，从而拒绝该用户的操作请求。

 如果配置了会话保持，那么用户登录以后后续的所有操作都会直接发送到在认证时选择的那台服务上。

 

二、会话保持的方法：

1、会话绑定：会话绑定是指使用一个算法或者是使用持久连接，将来自于同一个IP的请求始终定向至后端的同一个后端服务器。这种方法简单易用，但有如下问题：

当后端服务器宕机后，会话就会丢失；

来自同一IP的客户端会被转发到同一个后端服务器，可能导致负载失衡；

不适用于前段还有代理的情况。

 

2、会话复制：也叫会话集群，通过后端服务器自身的组件构建成类似会话高可用的集群，集群内部的动态服务器之间通过多播方式进行通信，在这些集群服务器中，每一台服务器都会将自己创建的会话通过多播的方式同步给集群的其他服务器。所以每一个服务器都维持着当前集群内的所有会话，因此用户的请求可以被调度至任意服务器上。因为我们的会话都是在集群服务器之间被同步的，不管用户连接那一台服务器，他的会话都是存在的。但是这样一种解决方法的问题在于：

由于服务器于服务器之间要进行会话复制，所以后端服务器之间的带宽被大量占用；

每台服务器都要维持整个集群中的所有会话，对服务器本身的资源占用和消耗非常大，使得服务器本身的并发承载能力有限。

但是好处在于我们的负载均衡调度可以任何进行，而且任何一个服务器故障都不会导致我们的会话丢失。

 

3、会话服务器：因为会话复制的弊端，我们可以找一台高性能的服务器，存储流式的数据，比如MemCached，这个是著名的用于会话缓存服务器，MemCache可以把web服务器中的内存组合起来，成为一个"内存池"，不管是哪个服务器产生的会话都可以放到这个"内存池"中，其他的服务器都可以使用。还有Redis（Key-value，kv store），键值服务器，键值存储，对于种存储来讲，他们可以帮我们在前端把我们的会话保存下来。但是这种方式也有弊端：

服务器有可能会成为性能瓶颈；

他们是单点故障之一，因此我们部署这种类似的服务器，还得做扩展和冗余。

 

4、其他会话保持技术

至于其他的用数据库做会话保持以及利用客户端的Cookie做会话保持的技术，直接就不用推荐，为什么？数据库本来就是瓶颈的地方，还用来进行会话保持，这不是加大数据库的负担吗？

利用客户端的Cookie做会话保持，需要客户端把Cookie开启，如果把Cookie禁掉了，也就玩不转了。而且利用客户端的Cookie，容易被攻击，毕竟Cookie安全性太低了，太容易被伪造。

 

三、NetScaler的会话保持

 

NetScaler支持多种会话保存技术类型。为了获得最佳的服务器，网络和NetScaler的运行效率，根据不同的部署场景(负载均衡、防火墙负载均衡等等)和流量类型选择合适的会话保持类型是非常重要的。一些会话保存类型(例如Source IP)需要占用NetScaler内存来存储会话保持的相关信息，而另一些会话保持类型(例如Cookie，URLPassive和Custom Server ID)则不需要占用NetScaler的内存，所有相关的持续性信息都来源于客户请求。

下表是常用的会话保持类型和支持的协议

下面简要描述下会话保持类型：

• 源IP：在该方法中，从相同的源IP连接被保存到相同的服务器。

• Cookie insert：在该方法中，每个客户端被赋予包含该IP地址和客户端访问的服务的端口的cookie。客户端使用cookie来维持相同的服务的持久连接。

• SSL session：该方法的利用在客户端的SSL会话标识持久性。

• Rule：该方法是基于定制的规则。

• URL passive：这种方法基于被动持续URL查询。

• Custom server ID：在该方法中，服务器给出一个定制服务器ID号，它可以在URL查询中使用。

• Destination IP：在这种方法中，连接到同一目的地的网络连接到同一个服务器。

• 源和目的IP地址：在这种方法中，从相同的源IP连接到相同的IP的会话保持。

• RTSP session ID：这种方法基于对RTSP会话ID的会话保持。

• SIP call ID：在这种方法是基于相同的SIP呼叫ID的会话保持。

在上表中，标记为“是”的部分，是该协议推荐的会话保存性类型和使用推荐的类型，可以使NetScaler获得最佳的CPU和内存使用率。举例来说，Cookie类型的会话保持非常适合HTTP&HTTPS协议，因为NetScaler不用浪费内存区存储会话保持的细节内容。所有会话保持的细节都被NetScaler编码以后存储在Cookie中了。再比如IP/TCP/UDP传输，Source IP会话保持则是最佳选择，它会使用一部分NetScaler内存来存储会话保持的信息。