我有一个虚拟服务器。 我有2个iRules（见下文）作为资源分配给它。
从服务器日志看来，规则正在运行，并select正确的成员
从会话池中继续会话（根据我的日志消息我可以判断出来），但请求最终会被导向到别的地方。
以下是这两个规则的样子：
when HTTP_RESPONSE { set sessionId [HTTP::header X-SessionId] if {$sessionId ne ""} { persist add uie $sessionId 3600 log local0.debug "Session persisted: <$sessionId> to <[persist lookup uie $sessionId]>" } } when HTTP_REQUEST { set sessionId [findstr [HTTP::path] "/session/" 9 /] if {$sessionId ne ""} { persist uie $sessionId set persistValue [persist lookup uie $sessionId] log local0.debug "Found persistence key <$sessionId> : <$persistValue>" } } 根据规则中的日志消息，select合适的平衡器成员。
注意：这两个规则不能冲突，他们在path中寻找不同的东西。 这两件事情永远不会出现在同一条path上。
有关服务器的注意事项：*默认的负载均衡方法是RR。 *没有为虚拟服务器分配持久性configuration文件。
我想知道如果这应该足以使持久性，或者，我必须结合2规则，并创build一个持续性configuration文件与他们的虚拟服务器？
还是还有别的东西我错过了？
编辑：事实certificate，我错过了一些东西。 保持活跃的连接会干扰规则，所以就这个支持案例而言，我已经修改了一些规则：
when HTTP_REQUEST { set sessionId [findstr [HTTP::path] "/session/" 9 /] if {$sessionId ne ""} { # added this line: LB::detach persist uie $sessionId set persistValue [persist lookup uie $sessionId] log local0.debug "Found persistence key <$sessionId> : <$persistValue>" } }
所以当你在查看日志条目时，你会看到预期的信息，但是stream量还在其他地方结束了吗？ 它在哪里结束？ 另外，为什么两个持久性条目为同一个会话？ 这可能会混淆这个系统。
你不应该需要一个分配给虚拟的持久性configuration文件，如果你在那里设置了持久性，那么iRule应该覆盖这个configuration文件。 你的日志条目是什么样的？ 另外，你有没有发布到DevCentral？ 有更多的F5经验的人可能会在那里看到它。 – http://devcentral.f5.com
你有没有尝试改变variables的名字？ 在这两种情况下，您都使用“sessionID”作为variables名称。 iRules中的variables是基于会话的，也就是说，在与系统进行会话期间，variables保持固定在内存中。 如果你同时执行了这两个iRules，那么你将会为请求和响应覆盖同一个variables名和数据，这可能会让你的逻辑检查sessionID是否是空的。 意思是说，如果sessionID是根据请求设置的，但是没有响应，但是响应运行代码检查以查看它是否是空的……它不会以你想要的方式失败。 不同的variables名称是一件好事。
除此之外，你的语法是正确的，除非这个问题引起了混淆，看起来问题不在于iRules本身，而在于持久性与请求交互的方式。
科林
在这种情况下，在第一个HTTP请求上，您将永远不会根据上述iRuleslogging正确的持久性条目。 之所以这样做，是因为F5还没有决定这个请求将被负载平衡到哪个池成员，所以稍后会在另一个事件中设置持久性。 由于没有做出这个决定，所以不可能创build持久性条目。 这意味着在整个HTTP_REQUEST事件的生命周期中，您将永远无法检索持久性值。 您只能在HTTP_REQUEST事件完成后触发下一个事件。 这就是为什么它工作，即使你没有看到预期的debugging数据。 相反，请尝试在LB_SELECTED中检查它。 您将看到在该事件中创build的条目。