WebSphere 反向投资者: 返璞归真：会话故障转移

核心提示： 解决方案依赖于在网络交换机上采用基于内容的路由，这是一种 IP layer 7 技术，WebSphere 反向投资者: 返璞归真：会话故障转移(5)，此方法的关键是从 HTTP 插件使用的 plugin-cfg.xml 文件中提取每个服务器的 Server CloneID（参见下面），然后使用该

解决方案依赖于在网络交换机上采用基于内容的路由，这是一种 IP layer 7 技术。此方法的关键是从 HTTP 插件使用的 plugin-cfg.xml 文件中提取每个服务器的 Server CloneID（参见下面），然后使用该 ID 为每个单元构造关联规则。然后网络交换机可以检查传入 HTTP 请求的标头，并确定应该将请求路由到哪一个单元。在下面的示例中，将构造一个规则来检查“13j9n75hm”的 HTTP 请求标头。

<Server CloneID="13j9n75hm" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1"

对每个单元中的 plugin-cfg.xml 文件中的每个 CloneID 这样做，并通过路由规则将 CloneID 与某个单元相关联，可以消除在单元之间共享会话的需要——至少从这个理由上可以这样讲。

重复的克隆？

虽然 Server CloneID 在单元之间应该是唯一的，但是 Network Deployment 没有办法保证这种情况的真实性。因此，您需要确保单元之间不存在重复。如果存在任何重复，只需删除并重新创建服务器即可消除重复。Server CloneID 只是应用程序服务器创建时间的散列（精确到毫秒），因此，除非您凑巧在确切的相同时间在不同的单元中创建了两个应用程序服务器，否则不应该会遇到任何重复。话虽如此，但是您始终应该核实确切，如果确实在两个不同单元中遇到了重复的 CloneID，您可能希望考虑购买彩票！

当然，有人会争论说，就网络交换机开销（以及延迟）而言，实现基于内容的路由“代价太高”了。我不反对代价太高的说法，但是如果您不在前端为传入请求处理好路由，您最终将会“付出更高的代价”，不得不通过在后端添加网络容量来复制 HttpSession 数据，并且您将创建数据中心之间的依赖性，从而以其他方式损害可靠性。

如果您遇到计划外的中断，使用这里讨论的关联方法最多只会让您丢失一个会话。这是因为对于计划外的中断，您可以使用有关保持持续可用性的文章中讨论的技术“排空”一个单元，以便现有的用户保持在初始单元中，而新用户则定向到新激活的单元。从实用的角度看，如果您遇到大量的计划外中断，那么您有某些根本问题亟需解决；首先，计划外中断的根源是什么？至少，这是我将首先调查的问题。正如在可靠性工程中所述，由于在单元之间共享会话的附加复杂性，这种情况很可能会导致附加的故障，从而导致中断，这是您要在第一时间尽量避免的事情！