专家评论: Tom Alcott:欲言又止的 WebSphere Application Server 的相关问题——第 3 部分

解答了许多关于 IBM® WebSphere® Application Server 的常见问题,包括如何在多个数据中心进行运行,需要使用什么版本的 JDK 和为何(以及何时)应该迁移到版本 V6.1。

Tom Alcott, IT 咨询专家, IBM Software Group, Worldwide Sales

Tom AlcottTom Alcott 是 IBM 美国的一位 IT 咨询专家。自 1998 年 Worldwide WebSphere Technical Sales Support 团队成立以来,他就一直是该团队的成员。在此期间,他花费了大多数时间来编写用户手册。在开始研究 WebSphere 之前,他是 IBM 的 Transarc 实验室的一名系统工程师,负责支持 TXSeries。他有 20 多年从事基于大型机和分布式系统的应用程序设计与开发工作的背景。他撰写并发表了大量关于 WebSphere 运行时问题的文章。



2006 年 9 月 19 日

摘自 IBM WebSphere 开发者技术期刊

第三次精彩的解答

前两次,我尝试利用此论坛提供关于 WebSphere Application Server 的常见问题的解答,每次都受到了读者广泛的肯定。这一次,当您读完本专栏的最后一篇文章时,我将可能已经最终解答了所有的问题。但是也可能没有。然而,与以前一样,这将不是对您欲言又止的关于 WebSphere Application Server 的问题的讨论,而只是解答一些我被反复问到的问题。同样,与以前一样,我可能需要依赖于我最常用的回答,这取决于,在许多情况下,这确实是最合适的回答。(也就是说,如果您提出相同的问题,我有理由使用相同的回答,不是吗?)尽管确定性的回答(我会尽可能地提供这样的回答)并非总是可能的,但我还是会进行各种尝试,至少为您需要考虑的问题提供某种指导,从而针对您的特定情形确定最佳回答。

问:WebSphere Application Server V6.1 中的新增功能是什么?

答:最近很多人提出这个问题,这不足为奇。简略的回答是“许多”,但我不能确定您是否需要更加详细的信息,因此我将尝试扼要介绍一些重要功能。

WebSphere Application Server V6.1 进一步扩展了 WebSphere Application Server V6.0 中提供的功能,在多个关键领域增加了许多旨在提高可用性的功能:

  • 系统管理:

    • 在管理控制台(现在使用 Portlet 实现)和 wsadmin 脚本语言中,都有许多管理方面的改进。

    • 控制台已重新设计,导航更加方便,并且添加了许多指导任务和快速路径对话框,可以更加快捷地配置和管理通用操作。

    • 还可以在控制台、日志中或者通过 JMX 通知使用命令帮助,该帮助详细解释了刚刚在控制台上执行的管理操作的 Jython wsadmin 命令(并非所有命令都可使用此帮助,但这种情况会随时间逐步改善)。这使得创建管理脚本比以前任何时候都更加方便。

  • 安全性:

    • 缺省情况下,现在使用基于文件的注册中心启用安全性。此外,还可以将多个独立的注册中心映射为单个联合注册中心,称为 Virtual Member Manager。可以使用这些注册中心替换基于文件的注册中心或者将其添加到基于文件的注册中心。

    • 密钥管理现在已集成到 WebSphere Application Server 管理(控制台和 wsadmin)中并与其关联。DummyKeyRing 不再随产品一起提供,而是在创建概要期间生成唯一密钥(即使不启用安全性也是如此)。

    • 现在,基于实例的管理可用于计算单元、节点、服务器和应用程序,从而支持将所有这些范围的命令行管理限制于某个特定角色或组(在控制台中还没有实现基于实例的管理)。

    • 对于需要 Windows® 单点登录 (SSO) 解决方案的情况,现在有基于 SPENGO 的 TAI,它允许基于 Windows 的 Web 客户端使用 Windows 登录,当其访问 WebSphere Application Server 中运行的应用程序时无需再次登录。

  • Portlet 容器:

    • 除了可以将 Portlet 用于管理控制台实现之外,JSR-168 兼容的 Portlet 容器现在已是 WebSphere Application Server V6.1 的一部分。(Portlet 容器只是门户服务器提供的一小部分,因此,如果将 Portlet 容器用于门户服务器实现,则不应考虑将其迁移到 WebSphere Application Server V6.1)。

    • 现在,不仅 Portlet 是受支持的编程选项,会话启动协议(Session Initiation Protocol,SIP)Servlet 也同样受支持——此外还有熟悉的 HTTP Servlet。所有这三个 API 都已在聚合的容器中实现,从而允许给定应用程序中的这些 API 之间共享应用程序状态。

    • Java™ 2 Standard Edition 5(J2SE 5 或 JDK 5)支持对编程模型的另一项重要增强,它不仅提供了附加的 Java 语言 API(如 Generic、Annotation、Enumeration 和 AutoBoxing),而且大大提高了 J2SE 5 上的 WebSphere Application Server 运行时实现的性能(我撰写此文时最终测试正在进行之中,因此我无法提供具体情况)。

    • 同时还增加了许多 Web 服务增强功能。

有关 WebSphere Application Server V6.1 的更多信息可以在参考资料部分中找到,但是我还想请您与本地 IBM 代表联系以获取更多详细信息,或者考虑参加本地 IBM 办事处的二日(免费)亲自动手进行 WebSphere Application Server V6.1 技术验证活动(本地 IBM 代表可提供具体地点和日期)。

一个问题往往导致另一个问题,当有人问我某个版本的 WebSphere Application Server 的特性和功能时,通常另一个问题是:

问:我是否应该迁移到“x”版本的 WebSphere Application Server?

答:此问题通常与特定版本(如 V5.1、V6.02、V6.1 等)有关,尽管我的回答可能会随着特定版本的不同而有所变化,但我的回答的主要部分到现在已多年保持不变。

如果问何时针对特定软件版本进行生产部署,则最重要的因素应该是该版本的成熟和稳定。结果,经验告诉我(加入 IBM 前的工作实践也是如此),大多数客户不在“.0”版本上部署任何软件,因为它是 WebSphere Application Server 或 Windows 或其他软件产品的新版本。因此,您需要根据维护版本考虑所选用的软件版本。本月初刚发布的 WebSphere Application Server V6.1 就是一个“.0”(6.1.0) 软件版本,将在今后的几个月中进行维护。如果您将在六、七个月后部署,那么我敢说使用它是安全的,当然,在生产部署前要进行适当的测试。在这段时间内,维护团队将针对预发布测试中可能遗漏的问题提供更新版本和修复程序。

如果您的时间表早于这个时间,则用途、关键程度和部署大小都是要考虑的次重要因素。决定何时进行迁移时必须考虑的另一个事项是,硬件、操作系统和第三方应用程序的生产更换或转换周期的时间。有些客户可能选择立即升级或更新其整个基础结构,而有些可能选择交错升级。无论采用哪一种方式,您对这一方面的策略和计划也应当有所考虑。

在此论坛中,我难以提供普遍适用的通用建议,因为各种部署的具体情况千差万别,这将决定立即迁移和稍后迁移哪一种方式更好——也可能两种方式都可取。

同样,经常有人问我关于成熟版本上的新部署和其他部署的问题。让我们再次以 WebSphere Application Server 为例,这一次使用版本 5.1。鉴于 WebSphere Application Server V6.02(及 WebSphere Application Server V6.1)的成熟和 WebSphere Application Server V5.1 的终止服务 (EOS) 日期,我此时对于建议在 WebSphere Application Server V5.1 上进行任何部署都感到犹豫不决。这并不是说 WebSphere Application Server V5.1 不稳定,没有经过生产验证,而是因为从现在起其 EOS 少于 18 个月(请参见参考资料以获取支持生命周期的信息),因此版本 5.1 上的任何部署都必须在相当短的时间内迁移。另一方面,在撰写本文时迁移到最近经过验证的稳定版本 V6.02(请回顾前面的段落)可以最大程度地延长 WebSphere Application Server 版本在生产环境中的服务生命周期,同时最大程度地减少迁移工作量。

最后,对于迁移主题,我知道很多客户害怕提到迁移,他们之所以对迁移感到恐惧,主要是因为在从 WebSphere Application Server V3.0 或 V3.5 迁移到 WebSphere Application Server V4.x 或 V5.x 的过程中他们有过痛苦的经历。这其实是进行应用程序更正,需要将应用程序代码从“pre-J2EE”升级到到 J2EE。最近更多的经验(这对于我曾经接触的那些客户无疑是天方夜谭)则表明,大多数客户可以在 WebSphere Application Server V6.x 上重新部署 J2EE 1.2 或 J2EE 1.3 应用程序,而无需进行任何应用程序更改。不过,值得一提的是,J2EE 1.4 规范声明能够在不进行更改的情况下运行 1.2 和 1.3 版本的应用程序。这可能多少有一点言过其实,因为事实上,这意味着它们肯定可以“按原样”运行——并不意味着它们必然可以按照“完全相同”的方式运行,因此,在新环境中测试任何应用程序都至关重要

现在接着谈应用程序确实需要进行更改的一些情况,此类更改是由于 J2EE 或者使用已弃用的 API 造成的。就这一点而言,在我讨论过的数以百计的客户应用程序中,只有其中的百分之一到百分之二需要更改。对于任何技术,这个比例都相当小,而与我过去使用 z/OS®(当时称为 S370)和 COBOL 的经验相比,这个结果非常理想,z/OS 和 COBOL 升级后也可提供类似结果。

问:为什么 WebSphere Application Server 要求使用 IBM JDK?

答:首先,要直接设置记录,需要使用“WebSphere 提供的 JDK”来支持,在 Sun ™Solaris™ 和 HP-UX 平台上,WebSphere 提供的 JDK 分别来自 Sun 和 HP,不过,IBM ORB 和 IBM 安全实现将替换来自 Sun 和 HP 的。EJB WLM 需要 IBM ORB,IBM 安全实现遵循 FIPS,而 Sun 和 HP JDK 则不遵循 FIPS。对于所有其他平台,WebSphere 提供的 JDK 是IBM JDK。

至于“为什么 WebSphere 提供 JDK?”,这需要回顾我们对 WebSphere Application Server V2.x 和 WebSphere Application Server V3.x 的支持体验。对于这些版本,我们列出了支持的 JDK(客户可以从中下载)并提供了相关说明,以帮助客户安装 JDK 和配置 WebSphere Application Server 来使用 JDK。这种方法导致了许多问题,而客户也常常由于这些问题而打来电话寻求支持:

  • 不正确安装 JDK。
  • 不正确安装 WebSphere Application Server(或配置它来使用 JDK)。
  • 客户未能获取所需 JDK 版本而在其位置安装另一个不等效的版本。
  • “较新”的 JDK 中的功能退化或缺陷。

在 WebSphere Application Server 中,通过支持 JDK 和提供特定(并经过测试)的 JDK,我们避免了所有这些问题(以及其他许多问题),从而改进了 WebSphere Application Server 的安装体验、可用性和可靠性,这是我们和我们的客户都希望看到的结果。此外,我们提供的 IBM JDK 不仅比 Sun(和 HP)提供的 JDK 更加安全,而且还更加快捷!有关详细信息,请参见参考资料中的 SPECJBB 基准站点。

当然,在使用 WebSphere 提供的 JDK 时必须注意一个例外,即,在 Windows 上,特定版本的 Sun JDK 可以与可插入客户端一起使用。(请参见参考资料。)

问:我是否可以在多个数据中心运行 WebSphere Application Server 计算单元?

答:您刚才是不是说:“等等,难道他以前没有写过这方面的东西吗?”啊,答案是:“是的,我写过,但这还有下文,因此,我打算借此机会扩充一下我在第 2 部分中所写的内容。您不需要费力地在这两篇文章之间来回地翻看;我已经通过下面这些附加信息扩充了我以前的答案,这些信息再次强调了不要这样做(请放心,我不会为告诉了您这一点收取费用!)。

首先让我们看一下最明显的问题:数据中心之间的网速和可靠性。在许多情况下,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 Network Deployment 或 WebSphere Extended Deployment。原理并未改变,主要问题在于任何事情的单一实现都是单点故障这一事实,而如果需要高可用性,则必须消除单点故障。如果有人构建了两个数据中心,则高可用性几乎总是主要驱动因素;构建两个数据中心实际上没有其他任何目的。如果您所需要的是可伸缩性,则只需向单个数据中心增加更多的计算机和网络带宽等即可。

与此相关,还有人问过我有关跨数据中心运行 WebSphere Application Server Network Deployment(或 WebSphere Extended Deployment)群集的问题。从令人讨厌的风险角度来看,跨数据中心部署单个计算单元这一观点非常不妥,而跨两个数据中心运行一个群集不仅无法最大程度地降低风险(您最好忘记这一点,因为群集无法跨计算单元),而且还会随着多种因素进一步增加风险。

首先,让我们看一下 Web 服务器插件上会发生什么。丢失一个数据中心就意味着有一半的应用服务器端点不再可用。因而,与有故障的数据中心中的服务器关联的请求(以及将工作负载管理器分发到故障服务器的请求)要等到 ConnectTimeout 结束才能将该服务器标记为不可用(最好为此指定一个值,通常为 5-10 秒(而不要使用缺省时间),这是操作系统的 TCP/IP 连接超时!)。该插件然后将请求重定向到另一个服务器,如果工作负载管理器将请求定向到正常运行的数据中心中的服务器,则一切正常——但是,如果请求被定向到未正常运行的数据中心中的另一个服务器,情况又如何呢?如果出现这种情况,请求将再次等待 ConnectTimeout,直到该插件将请求重定向到另一个服务器为止。最终,在某些点上,每个插入过程都将确定所有不可用的服务器,但是,在完成所有这些操作之前,对于定向或者重定向到未正常运行的数据中心中的服务器的请求,响应时间将会非常长。而且,您为 RetryInterval 指定的值(缺省值为 60 秒)将控制在插件尝试将另一个请求发送给标记为不可用的服务器之前,需要等待多长时间。因而,最初丢失数据中心时经历的性能和响应时间降级将对每个 RetryInterval 重复一次。

其次,由于您要保持核心组(WebSphere Application Server V6.x 中的“HA 域”)上的群集的一致性,所以,如果您遇到两个数据中心之间的网络故障,则可能会遭受应用程序或数据冲突的风险。其原因在于:核心组不需要仲裁,所以双方都可以继续运行。WebSphere Application Server 假定一致性/锁定通过其他方式(如数据库锁定、文件系统等)进行管理。因此,系统要么变得不一致,要么完全停止,直到对某些共享资源进行了故障转移(仅转移到一个数据中心)。当然,具体情况视环境而定,下面我们讨论一个示例。

假定基于故障转移的目的将同一群集中的多个服务器配置为共享事务型日志。从实践的角度来看,这些日志存储在一个数据中心中(可以自动复制到第二个数据中心)。如果包含这些日志的数据中心性能下降,则由于不能访问这些日志,所以其他的数据中心无法继续运行。对它们进行故障转移后,一个数据中心即可继续运行。现在,请考虑一种更加危险的故障情况。假定两个数据中心之间的网络连接出现了故障。那么现在会发生什么呢?包含日志的数据中心可能会像原来那样正常运行。其他数据中心仍在运行,但是它无法获取日志——或者我们希望它无法获取。如果您能够进行自动故障转移,请设想一下,如果另一个数据中心使用日志的副本启动,会怎么样呢。现在,这两个数据中心将转到不一致的事务状态。哎哟!请设想一下像数据库之类更加复杂的东西,情况会怎么样呢。您能让它正常运行吗?也许可以。但您值得冒此风险吗?我认为不值得。

另外一个相关问题是,实验室测试已确定核心组应该包括不超过 30 到 50 个进程,以便优化故障转移和将恢复时间减到最少,因此,即便您选择跨两个数据中心运行单个群集(在单个计算单元中),核心组的大小仍将限制您的群集的大小,并且可能需要某些附加管理工作,而这些工作正是您希望通过拥有单个计算单元来避免的。

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

但愿我已经让您相信跨两个数据中心部署单个计算单元不是一个好办法。在结束这一特定主题之时,我要感谢 Jason McGee、Billy Newport 和 Keys Botzum,感谢他们在构思本文方面给予的帮助。


结束语

又该结束这次漫谈了。现在,我认为,至少我已经为那些未提供确定性答案的问题提供了一些思路,为其他问题提供了一些合乎情理的确定性答案。


致谢

我还要感谢 Bill Hines,感谢他对本文的审阅和所提出的宝贵意见。


本系列的其他文章

参考资料

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=160871
ArticleTitle=专家评论: Tom Alcott:欲言又止的 WebSphere Application Server 的相关问题——第 3 部分
publish-date=09192006