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

核心提示： 与使用会话分发的决策相关的另一个决策是在 Network Deployment 单元之间共享会话，正如我在前面所讨论的，WebSphere 反向投资者: 返璞归真：会话故障转移(4)，我的建议是不要这样做，因为这样增加了 Network Deployment 单元（并延伸到数据中心）之间的相互依

与使用会话分发的决策相关的另一个决策是在 Network Deployment 单元之间共享会话。正如我在前面所讨论的，我的建议是不要这样做，因为这样增加了 Network Deployment 单元（并延伸到数据中心）之间的相互依赖性，而这是您在遭遇灾难性中断时希望避免的事情。虽然许多客户似乎接受这一点，但他们仍然坚持在数据中心的单元之间共享会话，因为他们无法正确地将某个用户与给定数据中心（或单元）中的某个应用程序服务器相关联。

幸运的是，存在对此问题的解决方案，只要您拥有适当的的基础结构和企业中所有受影响的操作实体之间的协作，您就可以在网络层应用此解决方案。如果您创建了多个独立的单元，如图 1 所示，您可以配置网络交换机（或通常所称的全局站点选择器）以正确地维护给定用户与特定单元的关联。

图 1. 具有多个独立单元的基础结构

如何实现这种配置呢？您会这样问到。当然，大多数此类设备都依赖 IP layer 2 或 IP layer 3 机制来维护从客户端到服务器的关联；这些机制的一些示例为 IP 地址散列、DNS 解析或此类性质的其他机制。如果在每个请求上一致地路由所有的传入流量，则这些类型的关联机制非常理想。但是如果通过代理服务器或其他中间设备路由流量，由于此类设备最终屏蔽了“实际”客户端 IP 地址，这些类型的关联机制将不足以确保一致地将客户端请求路由到相同的服务器（或单元）。

遗憾的是，这样的屏蔽或中转发生得太频繁了，有时跨多个请求发生在同一个给定的用户身上；一次他通过代理 A 路由，下一次通过代理 B 路由。其结果在于，网络交换机将这些请求视为不同的用户请求（即使事实并不是这样），因此，如果您没有在单元（或数据中心）之间分发会话对象，用户将丢失其应用程序状态。