F5 会话保持模式

类型，会话保持类型（cookies ,源地址，目标地址，sip,hash,ssl等）是F5用来决定怎么判断连接是否是同一连接的。

1.cookie:

insert方式，在http response经过F5时候，F5在http 头部的cookie中增加一个BIGipServer :realserver&port

rewrite方式，截取response里名叫BIGipCookie的cookie名，然后改写成BIGipServer :realserver&port。这种方式要求服务器在响应中一定要预先这只好一个空cookie，即BIGipCookie.

passive方式，在服务器上预先设好COOKIE，很不推荐这种方式

cookie hash方式，F5维持一个cookie值与node对应的HASH，但F5自己不产生COOKIE，因此一定要求服务器能自动产生COOKIE，如果没有COOKIE这个方式就每意义了

2.基于目标地址

这种方式将导致不管客户端是谁，只要目标地址相同，就被定向到同一SERVER上，这种方式适合缓存服务器环境下，将所有连接都定向到一台缓存服务器，提高利用率。

3.MSRDP

F5特别为微软远程桌面设计的，利用msrdp persistence 以及windows的会话目录提供终端服务的负载均衡以及会话保持，可以确保用户在需要的时候都能连接到上衣终端服务器，有了msrdp persistence，当连接到错误的终端服务器时，根据会话目录，可以让客户端重新连接到VS上再连接到正确服务器上，或者重新直接定向到正确服务器上。主要分为客户端可看见服务器和客户端看不见服务器模式。详细实践可以参考

4.ssl persistence

只适合F5不充当验证SSL验证、响应时候才适合，即只适合简单传输SSL数据时，这个时候是利用记录ssl 会话ID来保持的。

如果F5充当了SSL验证、加解密的时候，需要使用irules来进行会话保持。

5.Universal persistence
Included in the BIG-IP system’s Universal Inspection Engine (UIE) is a set
of functions that you can specify within BIG-IP system iRules to direct
traffic in more granular ways. Using these iRule functions, you can write
expressions that direct traffic based on content data, or direct traffic to a
specific member of a pool.
Universal persistence takes this iRules feature one step further, by allowing
you to implement persistence for sessions based on content data, or based on
connections to a specific member of a pool. Universal persistence does this
by defining some sequence of bytes to use as a session identifier.
To use iRule expressions for persistence, a universal persistence profile
includes a setting that specifies the name of the iRule containing the
expression.
Once you have created an iRule and specified the iRule name within a
universal profile, you must assign both the iRule and the profile to the
appropriate virtual server as resources

标准，标准是F5决定会话保持行为的：

1.match across Services setting

多个VS拥有相同的VIP（端口不同），此时，启用这个标准将产生如下行为：只要连接的VS的VIP相同，对于同一个原地址的请求，都以第一个会话保持信息为准，后续的连接不管是访问哪个VS，都会被定向到同一个pool member（也就是说，同一个客户端访问不同的VIP则使用相同的会话保持信息记录），不考虑会话时间限制。因此这种情况下各个VS关联的POOL应该拥有相同的成员。

这种情况非常适合，在实际服务器部署了多个服务（对外发布了多个相同VIP的VS,端口不一样）,但是彼此服务之间要求关联，比如第一次在A服务器上的80端口，要求该客户后续的对其他端口的请求也都在这个A服务器上，则启用这个功能。

2.match across Virtual Servers setting

不管各个VS的VIP是否相同，也不管后续连接是请求到了哪个VS，只要是同一客户端发来的，都按照第一个初始连接的保持信息执行（也就是说只要是同一个客户端的都被定向到同一个pool member）。因此不同的VS应该关联相同的pool成员

3.Match Across Pools setting
When you enable the Match Across Pools setting, the BIG-IP system can
use any pool that contains a given persistence record. The default is disabled(cleared).

管理员说外网无法访问XA虚拟应用了(后来发现内网也无法访问),用WEB方式登录时,有时可以登录进去,但点击应用图标,很快就出现以下错误:

 

要么就是一个Session Error的提示,无法再次进行登录.既然是WEB问题,我又搬出了Fidder, 抓了好些包,观察了1天, 终于发现有个叫BIGipServerpool_iis2的Set-Cookie动作非常可疑, 因为在一次登录中,会出现2个值不同的Cookie, 这应当是导致会话不一致的原因. 而BIGip这个名字提醒了我, 它是F5设备产生的.

 

 

我查到了以下support.f5.com 原厂内容,



原来这个COOKIE值第一个.点号前边的部分代表IP地址, 而第2个点号前边的部分代表着是端口号, 这表明由F5发过来的2个COOKIE分别来自后端的2个WI服务器, 这便会导致客户端响应发送到错误的WI服务器端,由于COOKIE的不匹配, 而无法正常访问.

为了进一步推断是由F5产生的问题,我做了以下2个实验:

1.绕开F5, 分别直接访问后端2台WI服务器中的任意1台, 结果是OK的
2.禁用其中1个WI服务器的网卡, 使F5仅对应1台后端的WI服务器,然后跟往常一样访问F5的地址, 结果也是OK的.

这样就基本可以断定是F5的问题.我打电话问了Alan兄和F5管理员的意见, 都建议不使用Cookie会话保持模式,而改为源地址会话保持模式.

在将以下COOKIE会话保持模式 (有意思的是, 如果按Set-Cookie显示样式的说明, 上述KB表明系统应当设置的是COOKIE Passive模式, 但实际系统设置的却是默认的COOKIE Insert模式, )

 


改为源地址会话保持(保持20分钟)的模式设置后, 系统运行正常. (而HTTP Cookie的Insert,rewrite,passive模式经测试都失败了)

 


F5管理员问我: F5配置都没动过, 那以前为什么一直OK呢 ?  这真是个很难回答的问题的. 也许跟交换机CPU >90%那个例子一样, 当主机数量多起来的时候, 问题从量变到质变, 就显现了出来!

一个完整的IT系统, 尤如人体一样, 是处在一个动态平衡的过程当中.