内容


IBM WebSphere 开发者技术期刊

WebSphere Application Server V6 的系统管理 —— 第 2 部分

增量单元升级

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: IBM WebSphere 开发者技术期刊

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

此内容是该系列的一部分:IBM WebSphere 开发者技术期刊

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

引言

IBM WebSphere Application Server V6 在系统管理特性方面较上一个版本 5 有较大的增强。 本系列文章探究了本领域内产品的发展,每篇文章都集中在具体特性的细节上。本系列文章包括:

以及随后即将发表的部分。

什么是增量单元升级?

在 IBM WebSphere Application Server (以后称为 Application Server) 版本 5.1 之前,将早期版本的单元升级到更新版本的单元是一次可能会破坏现有环境的费时的过程。比如,在升级过程中,整个单元可能会停止运转。换句话说,如果进行联机升级,那么一个新生成的新版本 Application Server 的并行单元将对现有单元进行镜像,并且在新单元开始工作之后,断开旧的单元。

WebSphere Application Server V5.1 部署管理器能够对版本 5.0.x 和版本 5.1 的节点进行管理,并使单元每次都能升级到新版本节点 —— 同时对单元内的应用程序影响最小。而且消除了在将老版本 Application Server 升级到新版本的 Application Server 时产生的不便。

版本 6.0 加入了许多增强内容。如果没有采取特定的方法来确保相容性的话,一些增强部分,如对 JMX 1.2 的采用或对新的消息传递实现的引入会使版本 5 和版本 6 不兼容。版本 6 中的附加功能(如显示控制台上节点或服务器的版本,调整控制台使其只显示出对特定版本节点或服务器有效的信息,以及通过脚本或 JMX API 在不同版本服务器或节点上修改配置时增强验证)大大扩展了原有的管理特性。

版本 6 的着重点是通过为管理员提供单个节点滚动升级的功能,通过及时的方式简化整个单元的升级。管理员还可以选择不为某些节点进行升级,但版本 6 中作出了一些限制(在本文后继部分进行描述),是关于在长期运行此混合环境的过程中所实现的内容的。建议管理员评估一下对这种受到限制的环境的使用计划。(可以预料的是,在 Application Server 的未来版本或维护版本中,将消除这些限制。)

图 1 图示了最中间的单元从版本 5 升级到版本 6。可以通过本图了解该环境的特性和复杂性。

图 1. WebSphere Application Server V6 中混合版本的单元
图 1. WebSphere Application Server V6 中混合版本的单元
图 1. WebSphere Application Server V6 中混合版本的单元

升级单元

增量升级过程从您的版本 5 的部署管理器向版本 6 移植开始。部署管理器必须一直是移植到新版本的单元的第一个部分,并且必须始终是最高的版本,每个单元内的节点应该是固定的版本,这样就使它能够管理单元中所有的节点,而不用管它们单个的版本。

升级部署管理器:

  1. 对您的 Application Server V5 的配置进行备份。
  2. 在您版本 5 的部署管理器所在的同一台机器上安装 Application Server V6。
  3. 新建版本 6 的部署管理器概要文件。确保单元的名称和部署管理器节点的名称都与现有单元匹配。
  4. 关闭版本 5 的部署管理器。由于现在不需要用部署管理器来维持应用程序服务器的运行,所以关闭操作不会影响到您的应用程序。
  5. 在版本 6 的部署管理器概要文件的 bin 目录下运行 WASPreUpgrade 工具。例如,如果您使用的是 Microsoft® Windows® 系统的计算机,就运行:

    .\WASPreUpgrade.bat <backupdir> <location_v5>

    <backupdir> 是您所选择的临时目录,

    <location_v5> 是版本 5 部署管理器的安装位置。

    WASPreUpgrade 工具检查版本 5 的安装,并将用于重新创建版本 5 环境的文件拷贝到 <backupdir> 下。

  6. 在版本 6 的部署管理器概要文件的 bin 目录下运行 WASPostUpgrade 工具。对于 Windows 系统的计算机,命令是:

    .\WASPostUpgrade.bat <backupdir> -profileName <dmgrProfile>

    WASPostUpgrade 工具利用由 WASPreUpgrade 工具创建的 <backupdir> 下的内容填充部署管理器概要文件(概要文件为 <dmgrProfile>),由此版本 6 的部署管理器配置就能和版本 5 的部署管理器保持一致。
  7. 启动版本 6 的部署管理器。

    在完成以上的步骤之后,您就新建了一个版本 6 的单元,该单元的部署管理器管理着所有先前存在的版本 5 的节点。在单元中的所有版本 5 的节点没有发生改变并且未察觉到是在新的部署管理器的管理之下。WASPostUpgrade 工具还禁止了旧的版本 5 的部署管理器。该操作是为了防止启动两个同时管理同一单元的部署管理器。

    如果因为一些原因您要立即取消升级:

    1. 停止版本 6 的部署管理器。
    2. 恢复备份的版本 5 的部署管理器配置。
    3. 重新启动版本 5 的部署管理器。
    4. 删除版本 6 的部署管理器概要文件。这也是防止同时启动版本 5 和版本 6 的部署管理器。

    在您已经对新的部署管理器的配置完成变更后,建议不要取消升级。这些变更已经在新的部署管理器中更新,新的部署管理器是独立的,并和旧的版本 5 的部署管理器截然不同,且很难简单地重新整合到版本 5 的单元上。

    在将部署管理器升级到版本 6 之后,就可以对单个的节点进行升级了。升级节点要:

  8. 对部署管理器配置进行备份。
  9. 对版本 5 节点的配置进行备份。
  10. 在节点所在的计算机上安装 Application Server V6。
  11. 创建一个非预先联合的客户概要文件。该概要文件带有不包含任何服务器的最小配置。确保节点的名称和要升级的节点名称相同。
  12. 确保新的版本 6 的部署管理器正在运行,并能够与正在升级的版本 5 的节点进行通信。
  13. 停止版本 5 的节点及其所有的服务器。只要节点上的任一服务器还是和其他机器一起组成的集群的一个成员,您的应用程序就应当继续运行。
  14. 在新的版本 6 的节点概要文件的 bin 目录下运行 WASPreUpgrade 工具。对于 Windows 系统的计算机:

    .\WASPreUpgrade.bat <backupdir> <version5_node>

    <backupdir>WASPreUpgrade 用来存储有关版本 5 的节点信息的临时目录。

    <version5_node> 是版本 5 的节点所安装的位置。

    WASPreUpgrade 检查版本 5 的节点,并把在将节点升级到版本 6 时所需的信息拷贝到 <backupdir> 下。

  15. 再次在 bin 目录下运行 WASPostUpgrade 工具。对于 Windows 系统的计算机:

    .\WASPostUpgrade.bat <backupdir> -profileName <nodeProfile>

    <backupdir> 是用于 WASPreUpgrade 时的同一目录,

    <nodeProfile> 是用于创建节点的概要文件名称。

  16. 启动版本 6 的节点和应用程序服务器。

WASPostUpgrade 连接到版本 6 的部署管理器上,将主配置存储库中的节点升级到版本 6。在将部署管理器上的配置升级之后,本地的节点存储库就会与部署管理器上的原版拷贝同步。WASPostUpgrade 也禁用了旧的节点,以防将新旧节点同时启动。

如果出于一些原因您需要立即取消升级:

  1. 停止版本 6 的节点和应用程序服务器。
  2. 恢复您在步骤 8 中备份的部署管理器配置。
  3. 恢复您在步骤 9 中备份的节点配置。
  4. 重新启动版本 6 的部署管理器,及版本 5 的节点和服务器。
  5. 将版本 6 的节点概要文件删除,以防将版本 5 和版本 6 的节点同时启动。

配置文件

随着对每个节点进行增量升级,单元的中央配置存储库将包含进版本 5 和版本 6 节点的文档。配置同步将确保从版本 5 的节点复制来的配置文档由版本 5 的运行时进行处理,即使文档是以版本 6 的格式存储在部署管理器存储库中。

回过来参看图 1,部署管理器的主存储库存储着所有版本 6 标准的配置文件,还设计成能够适应版本 5 的配置信息。在将部署管理器和版本 5 的节点之间的配置文件同步化时,将变换设置成版本 6 的格式以便与版本 5 兼容。这些变换包括在 XML 文件中改变命名空间、删除版本 6 中新的配置属性并去掉版本 5 的运行时所不能理解的资源。

JMX 互操作性

WebSphere Application Server V5 支持 JMX 1.1,而版本 6 支持 JMX 1.2。由于 JMX 规范的发展,在 Application Server V5 和 V6 间,由 JMX 规范定义的串行化格式(如 javax.management.ObjectName)也不兼容了。为了让版本 6 的部署管理器能够管理版本 5 的节点,Application Server V6 还增强了 SOAP 连接器,使其可以知道 JMX 的版本。由于没有增强 RMI 连接器,因此只将版本 5 和版本 6 的运行时之间的 JMX 功能限定到 SOAP 连接器上。

当向版本 5 的节点发送由 JMX 定义的串行化内容时,SOAP 连接器运行时会对 JMX 1.2 可串行化类应用适当的变换,以便 Application Server V5 运行时能够接收到 JMX 1.1 的可串行化内容。同样地,当从版本 5 的运行时接收到 JMX 1.1 的可串行化类时,所接受的内容就变换成 JMX 1.2 的格式,以便可以被版本 6 的运行时理解。

SOAP 连接器使用的变换框架利用特殊的类加载程序来执行变换。所有由 JMX 规范定义的类都可以进行变换。然而,引用 JMX 定义的类的用户定义类不能正确地进行变换,且不支持在版本 5 和版本 6 的运行时之间传送。

例如,假定您实现了一个 JMX MBean,并想将您所创建的一个类作为 MBean 方法的参数进行传送。只要此用户定义类不引用由 JMX 定义的可串行化类,例如 ObjectName,该类就可以正确传送。注意到传送 ObjectName 本身是可以的,但传送某个引用 ObjectName 的类 “A” 就不行了。

期望越少(如果有的话)的用户定义类落入此种境地。如果您需要定义能够在版本 5 和版本 6 下都能执行的 MBean 方法,那么就把属于 javax.management 包的类作为独立参数进行传送。

大多数 Application Server V6 中的引用了 javax.management 包的且用作 MBean 方法参数的内部类都能够进行变换,以便在混合版本环境中执行。唯一的例外是与 PMI 相关的类。在可以从版本 5 的节点正确地将 PMI 数据接收到版本 6 的环境中之前,PMI 用户必须等待 Application Server V6 的维护版本的出现。

JMX 1.2 规范还禁止将 “:” 作为 ObjectName 中有效的属性值来使用。在用来存储配置 ID 时,版本 5 的 ObjectName 中包含 “:”,但在版本 6 中改为 “|” 了。SOAP 连接器会自动地在这两个字符间进行变换,使得在两个运行时版本中对配置 ID 的使用是透明的。

当从 Application Server V5 内部利用 JMX 调入到版本 6 中时,在版本 6 中新定义的类不能够在版本 5 中进行串并转换,因为这些类在版本 5 运行时的 CLASSPATH 中不存在。该情况很少发生。但当发生此情况时,通常会在版本 6 中引发一个新的异常。

Adapt-A-View 管理

Application Server V6 部署管理器能够得到它所管理的节点信息,包括 Application Server 产品版本、操作系统和其他产品特性。随着节点升级到新的版本,或产品特性的增加,节点信息也在更新。部署管理器利用节点信息来确定对于特定节点,那些管理功能是真正有效的。例如,对于版本 5 的节点,版本 6 的新特性不能显示在控制台上,因为对于版本 5 来说这些新特性是无效的。在显示节点或服务器的同时还会显示出包含节点信息的列。这种能够适应不同节点信息的功能称为 Adapt-A-View。

对于脚本用户,脚本运行时也增加了 Adapt-A-View 功能。与控制台(可以选择要呈现给用户的信息)不同的是,脚本运行时实现了配置验证。例如,如果用户试图通过新建配置类型的实例或设置新的版本 6 的配置属性来配置版本 5 的节点时,会出现异常。如果用户试图访问不允许的类型或属性时,会出现警告,但操作可以继续进行。

有一个异常是关于先前存在的 AdminConfig attributes <type> 命令的。由于该命令本身不带有版本参数,因此将不分版本地罗列出对于 <type> 有效的所有属性。

对于那些想要自己编写 Adapt-A-View 代码的人来说,可以通过一组新的 Java API(WebSphere Application Server Information Center 中进行了描述)和新的 wsadmin 任务来访问节点信息。此处是一些任务举例:

  • $AdminTask getNodeBaseProductVersion { -nodeName <nodeName> }
    返回 WebSphere 基础产品的版本,如 “6.0.0.0”
  • $AdminTask getNodeMajorVersion { -nodeName <nodeName> }
    返回 WebSphere 基础产品的主版本,如 “6”
  • $AdminTask getNodeMinorVersion { -nodeName <nodeName> }
    返回 WebSphere 基础产品的次版本,如 “0”
  • $AdminTask getNodePlatformOS { -nodeName <nodeName>}
    返回节点的操作系统,如 “windows”

运行时互操作

除了 JMX 的互操作性以外,为确保能够在混合环境下工作,Application Server 运行时的其他部分也得到了增强。如果您拥有包含新旧版本节点的混合集群,那么负载管理运行时仍旧会向所有集群成员发送请求。然而,为了使该混合环境有效,将默认关闭某些版本 6 的性能增强。在所有成员都升级到版本 6 之后,建议用户设置 com.ibm.websphere.ObjectIDVersionCompatibility ORB 属性,以启动这些性能增强。

如果您在使用 JMS,那么新旧运行时之间的互操作性也是受保护的。您需要在移植节点之前将主题连接工厂端口设置由 DIRECT 改为 QUEUED。在移植过程中,版本 5 的 jms 服务器转变成了常规的应用程序服务器,并做出了适当的消息引擎设置,以执行原始 JMS 服务器的方法。这是因为 Application Server V6 包含了崭新的利用消息引擎的 JMS 实现。同样地,V5 WebSphere Default Messaging Provider 改名为 V5 Default Provider,为基于默认 provider 的消息引擎腾地。

如果您使用数据复制服务(Data Replication Service,DRS),那么必须让现有的配置继续有效。在移植完所有节点之后,建议用户移到新的 DataReplication 域中,即 Application Server V6 中的新实现。

利用资源

Application Server V5 中定义的资源还能在移植到版本 6 之后继续有效,包括:

  • JDBC provider
  • Generic JMS provider
  • WebSphere MQ JMS provider
  • Mail provider
  • Resource environment provider
  • URL providers
  • JCA 1.0 resource adapters JDBC provider.

当然,任何版本 6 中的新资源都不能在版本 5 的节点或服务器上生成。这些包括:

  • WebSphere default messaging provider
  • JCA 1.5 resource adapters.

处理应用程序

在 Application Server V6 中,所有的应用程序分为与版本 5 或版本 6 兼容两种,基于他们所使用的 Application Server 特性:

  • 与版本 5 兼容的应用程序是在版本 5 的环境中部署并运行的。这些应用程序包括 J2EE 1.3 应用程序和 JCA 1.0 适配器,且不调用任何版本 6 的新增 API。
  • 与版本 6 兼容的应用程序是只在版本 6 的环境中运行的应用程序,包括 J2EE 1.4 应用程序、JCA 1.5 适配器和任何调用版本 6 中新增的 API 的应用程序。

与版本 5 兼容的应用程序可以安装在任意版本 5 或版本 6 的服务器上,或者任意包含版本 5 或版本 6 服务器的集群上。当对应用程序进行更新,以用于重新安装、编辑或重新将模块映射到新目标时,与版本 5 兼容的应用程序的目标不受限制。相反,与版本 6 兼容的应用程序的目标只能是版本 6 的服务器,或只包含版本 6 成员的集群。

Application Server 对基于 J2EE 或 JCA 版本的应用程序的版本兼容性进行核对,它不对任何应用程序所使用的 API 进行核对。这意味着,Application Server 将允许调用了新的版本 6 API 的 J2EE 1.3 应用程序 —— 尽管这对版本 5 是不兼容的 —— 部署到版本 5 的服务器或集群上。对于这种很少发生的情况,强行进行低级核对会在应用程序安装或更新过程中付出高额代价。

在将与版本 5 兼容的应用程序安装到版本 5 的目标上时,不支持 deployejbdeploywsprecompileJSP 选项。当前版本 6 中的部署工具不能察觉应用程序所部署到的目标环境,因此需要在安装之前将这些应用程序预先部署。在安装版本 5 的目标时,也不支持 useMetadataFromBinary 选项。由于该选项很少使用,所以默认关闭了。此限制的原因是,应用程序二进制的元数据在版本 6 中得到增强,部署的应用程序版本是适应于版本 6 的运行时的,不能由版本 5 的运行时进行处理。

建议管理员在版本 6 的环境中部署、编辑或更新应用程序。如果在版本 5 的环境中开始(例如,在版本 5 的节点上启动指向版本 6 的部署管理器的 wsadmin),那么只有那些在版本 5 中可执行的任务能够得到支持。例如,以下版本 6 的应用程序部署任务就得不到支持:

  • 将消息目的参照映射到 EJB
  • 约定 J2CObject 为 JNDI 的名称
  • 约定 J2CActivation 为目的 JNDI 的名称

容量规划:处理节点、服务器和集群

现存在着关于版本 5 的节点所能进行工作的限制。这些限制是关于不能通过增加额外节点、服务器或集群成员来扩充混合版本单元的容量。这些限制将在适当的条件下从版本 5 或版本 6 的维护版本中去掉。同时,在将单元从版本 5 升级到版本 6 之前,工作区将通过创建额外的节点和服务器来规划发送移植的容量。可以在需要时再启动这些额外的节点和服务器。

解决其他具体情况的工作区如下所示:

  • 版本 5 的节点不能添加到版本 6 的单元内。
    工作区首先将节点升级到版本 6,然后将节点添加到版本 6 的单元中。
  • 不能从版本 6 的单元中将版本 5 的节点删除
    有两个工作区。第一,您可以卸载版本 5 的节点,然后运行 cleanupNode 命令将节点从版本 6 的部署管理器中删除。第二,您可以将版本 5 的节点升级,然后运行 removeNode 命令。
  • 在将部署管理器升级到版本 6 之后,不能新建版本 5 的服务器
    Application Server 的后继版本将通过提供所需的版本 5 的模板和运行时变更来开启该功能。
  • 版本 5 的服务器不能转变成集群,且新建的版本 5 的服务器也不能加入到集群中
    在转换或扩展之前,工作区首先将节点升级到版本 6。一旦集群中包含了版本 6 的成员,它就成为了混合集群。向混合集群中加入新的版本 6 的成员是得到支持的。

脚本兼容性

在 Application Server V6 中,对一些配置进行了变更,致使它们不能与版本 5 兼容。虽然已经努力维持严格的兼容性,但在一些领域,为使将来的配置任务更加容易,还是最好尽早做出彻底的改变。当版本 6 中存在不兼容时,运行时仍然可以在 “兼容性” 模式下运行,这意味着版本 6 的运行时可以允许新旧配置设置。在版本 5 中开发的脚本也能够用于配置版本 5 和版本 6 的节点或服务器。从版本 5 移植过来的版本 6 的节点和服务器由移植工具默认设为兼容性模式。

当所有的单元成员都是源于版本 5 时,兼容性模式对最初的单元移植是有利的。兼容性模式不适用于新加入到单元的版本 6 的节点,因为这些崭新的节点和服务器是根据新配置生成的。因此,建议:

  • 如果在部署管理器移植完之后不会有新的版本 6 的节点加入到单元中,那么可以让整个单元运行在兼容性模式下。
  • 如果要在任何新的版本 6 的节点加入之前升级整个单元,那么就在移植后尽快修改现有脚本以使用新的配置。脚本修改完后,运行 convertScriptCompatibility 工具以将旧配置移到新配置上。另一个途径是在移植之前修改现有脚本,并在兼容性模式关闭的情况下运行移植工具。
  • 如果需要包含了来自版本 5 单元的混合版本节点和新的版本 6 的节点的混合环境,那么必须将现有脚本对版本可见(参看有关节点信息 API 的 Adapt-A-View 部分):
    • 在版本 5 的节点上操作时使用旧的格式。
    • 在版本 6 的节点上操作时使用新的格式。

可以在关闭兼容性模式的情况下将节点从版本 5 移植到版本 6。换句话说,如果在打开兼容性模式的情况下移植节点,那么 convertScriptCompatibility 将用于移到新的配置。

版本间的一种不能兼容的变更出现在 HTTPTransport (用于指定 Web 容器端口)中。在版本 6 中,基于配置的通道框架将其取而代之,且是一种能够支持传送端点输入输出的更加灵活的机制。然而,迁移为通道框架要求用于 Web 容器的主机和端口设置必须符合通道定义。

第二个不兼容的变更是利用 processDefinitions 而不是 processDefinition。这些由于与 WebSphere Application Server for z/OS® 进行了整合,以支持包含工作站和 Z 节点的单个单元。在工作站上,每个服务器上只有一个 processDefinition,在 Z 节点上,可以有多个。因此,processDefinitions 可以用于以上二者。

另一个不兼容的变更是关于事务日值的位置。在 Application Server V5 中,是通过 TransactionService 进行指定。在 Application Server V6 中,是作为 ServerEntry 的属性进行指定的。该变更的引入可以使得寄存事务日志的机器崩溃时,能够利用事务日志的同等恢复来完善不确定的事务。

不能总是严格地保证兼容性的一个原因是当前终端用户可用的配置模式指定为非常低的等级,继而在实现中引发变更。在未来的 Application Server 版本中,将引入更高级的 wsadmin 任务,使管理员能够利用更高级的概念模型(这些模型与手头的任务更相关,且在底层实现上不容易出现变更)。WebSphere Application Server 即将发布的版本中将在可用性方面继续增强。

结束语

本文描述了增量单元升级过程,以及其细微差别、复杂性、限制和对管理员的提示。那些想要快速升级整个单元的管理员会发现比起关闭整个单元,或创建并行单元来所,每次升级一个节点来升级单元是重大的改进。那些需要在混合单元环境下运行版本 5 的节点,以延长使用时间的管理员必须要处理特定的限制,最严重的是容量规划问题。这些临时的限制将在 WebSphere Application Server 的未来版本或维护版本中去处掉。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=82740
ArticleTitle=IBM WebSphere 开发者技术期刊: WebSphere Application Server V6 的系统管理 —— 第 2 部分
publish-date=04012005