我过去几年一直在提交之类的专栏文章，IBM® WebSphere 开发者技术期刊的编辑问我，是否考虑按照这种风格开设一个定期专栏。一念之差，我答道“可以。”回顾我经常不得不提供的建议类型之后，我将这个专栏命名为 WebSphere 反向投资者。 对“contrarian”（反向投资者）一词的定义如下：

我在这里不是要提供股票市场投资建议。如果您读过我的任意一篇“评论专栏”文章，就可能认识到，在回答与 WebSphere 相关的问题时，我的确经常从相反的角度看待问题。因为这个原因，几乎在回答关于任何事项的问题时，我都会从相反的角度进行讨论。（我就是这样一个让人头疼的人。）虽然有些人可能会将我视为怀疑论者，但我所经历的墨菲定律效应迫使我不得不怀疑是否有任何事情真的非常确定或极为简单，从而形成了我的怀疑论或反向投资者观点！

下面让我们转入正题……

我在发表关于高可用性（High Availability，HA）主题的演讲时，所用幻灯片中经常会包含“分层 HA”，在其中讨论 J2EE™ 应用程序部署中的大部分典型组件的各种 HA 替代方案。图 2 中显示了此幻灯片的部分内容，其中包括了我在这里要讨论的主题。

这里我们感兴趣的是注解不建议——插件和 Web 容器间的 IP Sprayer (NOT Recommended – IP Sprayer between plug-in and Web container)。经常有人问我，为什么不建议采取此类配置。除了我经常采取反向投资者的视角看待问题（我个人习惯的方式）外，我的理由如下：

• 如果有任何应用程序状态（例如，HTTP 会话），则我的标准建议是，不要在 HTTP 服务器插件和 WebSphere Application Server Web 容器之间放置 IP Sprayer 或负载平衡器。中的 ClusterAddress 参数可以用于此目的，此参数在 WebSphere Application Server on z/OS® 引入，因此可以使用 z/OS 工作流管理。有一点您或许知道，z/OS 工作负载管理非常复杂，使用应用程序状态、服务器响应能力、负载等等来进行路由（和故障转移）决策，而 IP Sprayer 或网络交换机仅提供此信息的某些部分的内容。

• 另一个问题（这个问题可能更大）是，配置 IP Sprayer 正确地维护应用程序状态。大部分 IP Sprayer 依赖于 IP 第 3 层或 IP 第 4 层信息来维护应用程序状态或“粘性”(stickiness)，依赖于用户名、客户端 IP 地址或随机分配来将请求分配到特定服务器。不过，DHCP、网络地址转换和 Web 代理可能会导致客户端的 IP 地址在多个请求间发生变化。因此，这些技术并不能提供与 WebSphere Application Server Network Deployment HTTP 服务器插件相当的关联。这意味着 IP Sprayer 必须配置为能识别 HTTP Cookie 或 WebSphere Application Server 所使用的 URL 信息；而且，除非 IP Sprayer 部署了 IP 第 7 层内容路由，否则将不会正确维护应用程序状态。

• 即使您拥有提供 IP 第 7 层内容路由的 IP Sprayer 或网络交换机，仍然存在问题，即在 WebSphere Application Server 中的应用程序或服务器配置发生更改时，需要随时维护 IP Sprayer 中的路由信息。即使可以通过从 plugin-cfg.xml 文件提取正确的信息并更新 IP Sprayer 来保持 IP Sprayer 与 WebSphere Application Server 的同步，从而实现此过程的自动化，但这仍然可能需要一定的手动操作。由于目前人员成本是 IT 中最高的成本，因此我不认为这是一个经济高效的解决方案。

• 即使没有应用程序状态，我也不会太支持在 HTTP 服务器插件和 WebSphere Application Server 之间放置 IP Sprayer，因为这样增加了体系结构的复杂性和所需的管理工作，而且还增加了硬件成本。

• 最后（这一点对于需要和不需要状态的应用程序都适用），要在 HTTP 服务器插件和 Web 容器间放置 IP Sprayer，需要 IP Sprayer 具有确定不对应的应用服务器 Web 容器的机制，以便将请求重定向到其他应用服务器。虽然通常可以配置 IP Sprayer 来执行某种类型的“应用服务器运行状况检查”，但这也会增加复杂性——而且如果配置不正确，在 HTTP 服务器插件可以辨别停机故障的情况下，IP Sprayer 将继续把请求发送到不可用的应用服务器（在尝试采用这种方式的客户中的确发生了类似的情况）。

既然我已经给出了反对观点，接下来让我们讨论建议的方案。

• 首先，我建议对 中的参数进行一行调整。可能最有用的参数有 ServerIOTimeout、ConnectTimeout 和 MaxConnections 参数。通常，对于 ServerIOTimeout 和 ConnectTimeOut，可以将其缺省值（分别为 5 分钟和操作系统 TCP/IP 超时）向下调整到很小的数字，如 ServerIOTimeout 可以设置为 30-60 秒，而 ConnectTimeOut 可以设置为 5-10 秒。通过这样，可以大幅度提高（相对于使用缺省设置的情况）插件将请求重定向到其他应用服务器的速度，并提高应用程序的响应能力。

• 更改 MaxConnections 还可以帮助防止服务器过载。通常，这所增加的大小不应超过 中线程池大小的 20 – 25%。否则，当某个应用服务器失败时，请求就可能导致剩下的应用服务器实例过载。我还建议减少 的最大开放连接数（虽然 WebSphere Application Server 信息中心建议采用缺省值 20,000）。我之所以建议这样，其理由仍然是为了避免请求导致服务器过载，特别是在服务器处理请求的速度较慢的情况下。虽然用于管理 WebSphere Application Server Web 容器的连接请求的线程极为高效，但您肯定仍然最不希望在服务器变慢的情况下让等待其处理的其他工作开始排队。

那么，如果您尝试按照上面所建议的进行调整，仍然无法获得所需的响应能力和服务质量，又该如何呢？

如果出现这种情况，我建议您阅读 IBM WebSphere Extended Deployment 操作优化，其中包括，设计将其放置在 HTTP 服务器和 WebSphere Application Server Web 容器之间，以提供“识别”应用程序状态的工作负载管理（以及识别应用程序版本的工作负载管理）。而且，ODR 还将服务器响应、负载等包含到了负载管理算法中（和 z/OS 工作负载管理一样）。ODR 还与 WebSphere Application Server 管理基础设施实现了集成，因此不需要开发额外的手动或自动机制来同步 WebSphere Application Server 计算单元配置和 IP Sprayer 间的配置。此外，WebSphere Extended Deployment 与购买额外的网络交换机一样经济高效（如果不是更好的话），不过与网络交换机不同，ODR 不支持部署在 DMZ 中。

WebSphere 反向投资者 的第一篇文章到此结束。我将在几个月后恭候您再次关注本专栏，阅读我的下一篇文章！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-410070/，如需转载，请注明出处，否则将追究法律责任。