我有一个虚拟服务器。我已将 2 个 iRules（见下文）分配给它作为资源。
从服务器日志来看，规则正在运行，并且选择了正确的成员
在保持会话之后从池中获取数据（据我根据日志消息所知），但请求最终被定向到其他地方。
这两条规则的具体内容如下：
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>"
}
}
根据规则的日志消息，选择适当的平衡器成员。
注意：这两条规则不会发生冲突，它们在路径中寻找不同的东西。这两件事永远不会出现在同一条路径上。
关于服务器的注释：* 默认负载平衡方法是 RR。* 没有为虚拟服务器分配持久性配置文件。
我想知道这是否足以启用持久性，或者我是否必须结合这两条规则并为虚拟服务器创建一个持久性配置文件？
或者我还遗漏了什么？
编辑：事实证明，我错过了一些东西。保持连接会干扰规则，因此这支持案例建议，我稍微修改了规则：
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>"
}
}
答案1
所以，当你查看日志条目时，你会看到预期的信息，但流量仍然流向其他地方？它最终流向哪里？此外，为什么同一会话有两个持久性条目？这可能会让系统感到困惑。
您不需要为虚拟分配持久性配置文件，如果您在那里设置了持久性，iRule 无论如何都应该覆盖它。您的日志条目是什么样的？另外，您是否已经发布到 DevCentral 了？更多有 F5 经验的人可能会在那里看到它。-http://devcentral.f5.com
您是否尝试过更改变量的名称？在两种情况下，您都使用“sessionID”作为变量名称。iRules 中的变量基于会话，这意味着在您与系统进行会话期间，变量将保留在内存中。如果同时执行这两个 iRules，您将使用请求和响应的数据覆盖相同的变量名称，这可能会使您的逻辑检查（查看 sessionID 是否为空）变得毫无用处。这意味着，如果 sessionID 在请求时设置，但在响应时未设置，但响应运行代码检查它是否为空……它不会像您希望的那样失败。不同的变量名称是一件好事。
除此之外，您的语法是正确的，除非该问题引起了混淆，否则问题似乎不是出在 iRules 本身，而是出在持久性与请求交互的方式上。
科林
答案2
在这种情况下，在第一个 HTTP 请求中，您将永远不会根据上述 iRules 记录正确的持久性条目。原因是持久性稍后在另一个事件中设置，因为 F5 尚未决定将此请求负载平衡到哪个池成员。由于尚未做出此决定，因此无法创建持久性条目。这意味着在整个 HTTP_REQUEST 事件的生命周期中，您将永远无法检索持久性值。您只能在 HTTP_REQUEST 事件完成并触发下一个事件后执行此操作。这就是为什么它能正常工作，即使您没有看到预期的调试数据。相反，请尝试在 LB_SELECTED 中检查它。您将看到该条目已在该事件中创建。