专家提示

Tom Alcott 解答:欲言又止的 WebSphere Application Server 的相关问题 — 第 2 部分

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 专家提示

敬请期待该系列的后续内容。

此内容是该系列的一部分:专家提示

敬请期待该系列的后续内容。

摘自 IBM WebSphere 开发者技术期刊

这个东西更好?视情况而定

去年夏天,我在专家提示撰写过相同标题的文章(没有“第 2 部分”),得到的反馈促使我再写这篇文章。这表明我勇敢还是鲁莽有待定论。和以前一样,有关 WebSphere Application Server 您不敢问的问题都没有讨论过,而只是提一些我反复被问到的问题。虽然我最常使用的回复视情况而定 已准备脱口而出,但我确实试图提供一些指南来帮助您确定特定情况的最佳答案,以及为若干常见问题提供一些明确的回答。

问:EJB 客户机工作负载管理 (WLM) 是如何工作的?

答:我准备以最近被问到的另一个问题来开始我的回答,它提出了几个经常被误解的观点。

我有一个客户,他试图设计一个 EJB 客户机工作负载分发解决方案,这些客户机调用位于同一集群中的 EJB。EJB 的工作负载是很大的,所以他想确保它们不会只占用集群中的一个服务器。我们担心进程关联会阻止任何工作负载共享;也就是说,被调用的 EJB 始终位于调用 EJB 的服务器上。我们可以关闭本地关联,但进程关联只会出现在性能红皮书的文档中,其他任何地方都没有。对于 WebSphere Application Server V5.1x,是否有关于 EJB WLM 的任何指导原则,以及如何克服进程关联呢?

让我设法澄清对 EJB WLM 的一个常见误解以及“首选本地”和“进程关联”术语之间存在的混淆,它们经常被作为同义词使用,但事实上是两个不同的概念:

  • 进程关联(对于上述问题)指的是 WebSphere Application Server 不会进行从 EJB 客户机到 EJB 的进程外调用这一事实。因此,当一个 Web 应用程序组件是 EJB 客户机,而该 EJB 部署到相同的 WebSphere Application Server EJB 中时,WLM 就不起作用。WebSphere Application Server 会始终调用驻留在本地应用服务器中的 EJB,而不会跨运行同一应用程序(也因此是同一 EJB)的 WebSphere Application Server 集群中的其他应用服务器分发应用程序客户机请求。EJB WLM(或者更准确地说是请求分发)只有在 EJB 客户机和 EJB 运行在独立进程中,而该客户机是独立的 Java 客户机或者运行在远程(相对于 EJB)应用服务器上的 Web 应用程序中的同一组件时,才能起作用。

  • 本地关联在上述问题中指的是您可以为 WebSphere Application Server 集群配置的“首选本地”选项。该选项只适用于 EJB WLM,而不适用于 HTTP 服务器插件 WLM。当该选项启用并且 EJB 客户机运行在应用服务器的远程进程中时,WebSphere Application Server 会“首选”位于与 EJB 客户机相同的机器上的应用服务器,因此术语为“首选本地”。如果在与 EJB 客户机相同的机器上没有正在运行的应用服务器,并且启用了“首选本地”,则 WebSphere Application Server 会将 EJB 客户机请求分发到远程机器,也只有这种情况它才这样做。从实际角度来看,这意味着只有当您选择跨多个应用服务器部署来自单个应用程序(J2EE EAR 文件)的组件时,“首选本地”才会起作用。通常,这意味着 Web 组件部署在一个应用服务器(或服务器集群)上,而 EJB 组件部署在另一个应用服务器(或服务器集群)上。人们一般认为可以将 EJB 视作“共享服务”,所以当其试图更大程度地提高业务对象的重用性时,通常会出现这种情况。虽然所付出的努力令人欣慰,但这在许多场合可能是不实用的。这样做意味着一些折衷,性能会因进程外调用而下降 20% 到 30%,而且应用程序的维护会更加复杂(请参阅 Deploying multiple applications in J2EE 1.2)。

让我们继续讨论被问到的或者隐含在这一问题中的其他一些观点。首先关心的是如何分发请求以避免服务器超载。正如前面提到的,请求分发只出现在客户机和 EJB 位于独立的进程时,所以在许多情况下不存在分发;事实上,此问题正是这种情况,因为 EJB 客户机和 EJB 位于同一进程。这导致进行了一些不十分明显的 WLM 行为,以确保工作负载均匀地分布在整个 WebSphere Application Server 集群中。

  1. 对于远程 EJB 客户机,InitialContext 请求经过了 Object Request Broker (ORB) 和一个 JNDI 上下文对象。而对该上下文的查找则返回 Bean 的一个 Home 对象。这是一个间接的 Interoperable Object Reference (IOR),它实际上指向本地 Node Agent 上的 Location Service Daemon (LSD)。因此,第一个请求转到 LSD,LSD 通过使用其中的 WLM 插件随机选择一个集群成员;然后 LSD 将直接的 IOR 返回给特定的集群成员。集群成员的随机选择是确保请求均匀分布所使用的第一个机制。

  2. 接下来,由该服务器处理第一个请求。然后使用 WLM 分发以后的请求(请参阅参考资料)。WebSphere Application Server V5.0x(以及更高版本)中的 EJB WLM 也使用未完成的请求来确定将请求发向哪里。它一开始使用标准的 Weighted Round Robin(逐步减少权重),但一旦有几个未完成的请求分发到多个集群成员,则使用未完成请求加权算法。该算法将每个集群成员的权重与已发送到该集群成员的未完成请求数目进行比较,以确保其具有正确的比例(相对于其权重和其他集群成员的权重)。例如,如果权重是 2 和 2,而第一个服务器的未完成请求数目大于第二个服务器,则接下来的请求会转到第二个服务器,即使它轮到第一个服务器(根据 Weighted Round Robin)。这一附加步骤有助于确保服务器基于其权重实现负载平衡。

    (在 WebSphere Application Server V6.0 中有其他一些增强功能;权重得以规范化,WLM 算法将对请求进行扩展。例如,对于权重 2(服务器“a”)和 7(服务器“b”),得到的 WebSphere Application Server V6 请求分布是 a-bbbb-a-bbb,而在 WebSphere Application Server V5.x 中请求分布是 a-b-a-bbbbbb。这有助于进一步消除给定服务器的超载情况。)

(以上讨论假设您已经熟悉 WebSphere Scalability 第 6 章或 IBM WebSphere 中的第 21 章:部署和高级配置;请参阅参考资料。如果您对此内容不熟悉,请首先查阅相关内容,然后再回到本讨论。)

问:我可以在多个数据中心上运行 WebSphere Application Server 单元吗?

答:是的。但也许这样做是不明智的。

首先,让我们看一下最明显的问题:数据中心之间的网速和可靠性。在许多情况下,WAN 的性能和可靠性不如 LAN,虽然有些环境下 WAN 非常可靠而且能提供 LAN 带宽;在这种情况下,对于应用程序(例如 WebSphere Application Server)来说,WAN 与 LAN 是一样的。所以简单的回答是:当然,请继续这样做,如果您有一个又快又可靠的 WAN。然而,一个更重要的问题被忽视了:为什么有多个数据中心呢?通常,您这样做是为了提高可靠性,因此如果一个数据中心全部失败或丢失(换句话说,一个真正的“灾难”),则您想让其余的数据中心能处理工作而不会有很大问题。考虑到这一点,人们需要为时间不短的数据中心停机作好计划,因此,这种状态下的可靠性将会变得非常重要。另外,这种情况下的故障转移要正确测试可能非常困难,因为这是在“正常的”WebSphere Application Server 故障转移(处于组件级(服务器、Web、EJB 等),而非数据中心级)范围外。

  • 在这种情况下,特别是当客户机位于一个数据中心而服务器位于另一个数据中心时,WLM 端点会发生什么情况呢?EJB WLM 或 HTTP 服务器插件 WLM 都会出现这种情况,这取决于部署和网络体系结构,虽然这两种 WLM 实现都会还原(通过超时),但这是需要考虑(和可能避免)的另一种情况。

  • WebSphere Application Server Network Deployment 部署管理器是一个单点失败。因此,如果您失去运行部署管理器的数据中心,也就失去了管理单元的能力,直到仍然存在的数据中心启动备份部署管理器为止。虽然这种问题能够解决,但它仍然是在故障中需要处理的另一个问题。

  • 如果您选择分发 HTTP 会话对象,而且您使用数据库来实现此目的,则如果该数据库位于现在没有运行的数据中心,会话信息会出现什么情况呢?

虽然的确可以构建(和测试)交叉中央集群解决方案(如果您非常谨慎地运用),但也始终存在丢失某些东西的风险,这在真正面临灾难时会出现。这是因为还存在一些我在这里没提到(和我没有考虑过)的问题,它们致使我再次建议跨多个数据中心运行 WebSphere Application Server 单元。正如我经常提到的,灾难不是您在工作中想要经历的事情。

问:我可以跨 WebSphere Application Server 单元共享会话吗?

答:是的。但再次说明,明智的选择可能是别这样做。

一个原因在上述跨数据中心运行 WebSphere Application Server 单元的情况下已经提到。另外,如果您跨单元共享会话,则意味着您依赖于单个数据库服务器(或数据库服务器和故障转移服务器)。因此,维护任何类型的数据库服务器都会导致跨两个单元停机(或者避免停机的步骤)。这就增加了复杂性。

类似地,更新应用服务器运行时也会使计划和执行停机变得十分困难,因为软件更新(例如,对 WebSphere Application Server 的更新)会导致现有的数据库服务器版本不再受支持。另一方面,如果每个单元都是独立的(包括数据库服务器),则可以根据逐单元(即 WebSphere Application Server 单元及其相关的基础设施)方式维护和更新,一个单元停机不会影响另一个单元,它可以继续运行和为请求服务。

结束语

因为时间有限,这一不着边际的部分就到此结束。我希望在对一些常见的 WebSphere Application Server 问题无法直接回答的情况下,这些信息能让您了解如何确定适合您的环境的最佳解决方案。

致谢

感谢 Keys Botzum 和 Bill Hines 的审阅和意见。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=163398
ArticleTitle=专家提示: Tom Alcott 解答:欲言又止的 WebSphere Application Server 的相关问题 — 第 2 部分
publish-date=02132006