在 WebSphere Process Server V7 中实现连续可用性

在应用程序更新和修复程序包安装期间保持可用性

本文提供了在需要连续可用性的 WebSphere® Process Server V7.0 环境中安装应用程序更新和产品修复程序包的背景知识、见解和一些实用技术。 本文来自于 IBM Business Process Management Journal 中文版

Jacob (Jake) Stoeffler, 实习软件工程师, IBM

Jacob Stoeffler 是 University of Wisconsin-Madison 的一名学习计算机科学的学生。他于 2012 年在美国明尼苏达州罗契斯特市的 IBM 分公司实习过一段时间,效力于 BPM 和 ODM CTO 办公室。



Eric Herness, 杰出工程师, IBM

Eric Herness 是一位 IBM 杰出工程师,在 IBM Sofware Group 的 AIM 部门担任 Business Process Management (BPM) 产品的首席架构师。他领导着定义 BPM 产品体系结构和方向的架构师团队。

Eric 是 WebSphere Foundation Architecture Board 的高级成员,同时也是 Software Group Architecture Board 的成员。



2013 年 8 月 21 日

简介

随着组织开始了解如何最佳地利用流程来帮助运行和改善其业务,业务流程管理应用程序不断变得越来越任务关键型。这意味着这些应用程序的可用性需求常常会达到 24/7。BPM 还鼓励持续流程改进,这意味着对应用程序的更改会更快地以各种不同的形式完成。需要采用一些机制和技术来最大程度地减少宕机时间,从而实现连续可用性。这些技术需要尽可能自动化,以便提高一致性和速度,并减少指纹检查或人为错误。

本文提供了在 WebSphere Process Server V7.0 中实现连续可用性的背景知识、见解和一些实用技术。

首先让我们来回顾一下 WebSphere Process Server 的拓扑结构。本文将重点详细介绍准备和设置本文所建议方法的应用阶段的特殊考虑因素。因为在 WebSphere Process Server 上运行的 IBM BPM 解决方案中涉及到许多不同类型的工件,所以需要使用不同的技术来实现想要的结果。还需要在解决方案和应用程序级别上执行一些限制和特殊设置。每个场景都提供了详细的解释,包括执行这些场景所涉及的步骤。本文将对所执行的场景和应用的基本技术进行重点描述,并以此为基准探索与 store-and-forward 和替代的拓扑结构配置相关的变化。本文还将枚举对所执行场景和一些影响的更多见解。最后,将会总结如何对产品修复程序包应用某种类似方法。

在生产环境中尝试这里列出的任何过程之前,强烈建议您先全面测试它们。除了拓扑结构之外,应用程序必须以有助于实现连续可用性的方式来创建。本文提供了一些具体的信息,但假设应用程序会适当地处理界面变化、数据库中需要的表和其他资源需求。换一种说法,要认识到一些应用程序更改可能破坏兼容性,进而导致宕机。本文关注的重点是兼容的更改。例如,我们会执行添加操作,而不是删除或更改操作。特定于应用程序的数据库不会发射更改。删除操作和更改数据库等操作不属于本文的讨论范围。


Process Server 拓扑结构的背景

图 1 给出了一个典型的 WebSphere Process Server 配置的可能形式。为了简单起见,本文通篇都会假设采用了一种与此类似的单细胞拓扑结构。我们不可能介绍每一个配置场景,但我们希望提供一些可应用于绝大多数配置的通用实践。

图 1. 一个包含 IBM HTTP Server 的由两节点和 4 个集群组成的拓扑结构
一个包含 IBM HTTP Server 的由两节点和 4 个集群组成的拓扑结构

所有 WebSphere Process Server 拓扑结构都会利用 4 个关键功能:应用程序部署目标、消息基础架构、支持基础架构和 Web 基础架构。集群 是一组执行这 4 个功能中的一个或多个功能的服务器。可以让一个集群执行所有 4 个关键功能。但是,如果将这些功能分散在多个集群上来提高恢复能力,则有机会获得更高的连续可用性。

在图 1 中所示的拓扑结构中,4 个功能中的每一个功能都有一个专门的集群。应用程序部署目标集群 (AppTarget) 由安装了您的应用程序的服务器组成。这些应用程序可能包括业务流程、服务、人工任务和中介。远程消息集群 (Messaging) 为您应用程序的异步消息和内部 Process Server 组件的需求提供支持。支持基础架构集群 (Support) 提供的功能为部署目标提供补充,作为一个独立集群,它实现了隔离,并从部署目标解除了一些特定的工作负载。最后,Web 组件集群 (WebApp) 托管了基于 Web 的客户端应用程序,比如 Business Space、Business Process Choreographer 工具和 REST API 服务。

此拓扑结构包含一个部署管理器和 2 个 Process Server 节点。部署管理器 的职责是管理该单元,提供一个界面来配置该单元中的各种组件。部署管理器还负责安装和更新应用程序,因此它对我们实现连续可用性至关重要。

一个节点 托管着一个或多个应用服务器;在此拓扑结构中,每个节点托管了每个集群的一个成员。每个节点由部署管理器通过节点代理 远程管理。部署管理器与一个节点的节点代理进行通信,该节点代理进而与该节点的应用服务器进行通信。

在 WebSphere Process Server 中,应用程序通过部署管理器使用 Integrated Solutions Console 或 wsadmin 命令行脚本工具来安装。在安装或更新一个应用程序时,新应用程序的工件首先被存储在该单元主存储库 中。然后部署管理器将新应用程序的工件传递到每个节点的节点代理。随后,每个节点代理更新该节点的应用服务器上的应用程序。

IBM HTTP Server 通常用于处理 IBM BPM 环境中的 HTTP 流量。IBM HTTP Server 支持使用一个名为 plugin-cfg.xml 的文件配置路由到应用服务器的流量。一个客户端连接到 HTTP 服务器,并依据每个应用服务器配置来处理的负载,这个 HTTP 服务器将客户端的请求路由到该单元的应用服务器。在讨论更新异步应用程序时,我们将更详细地介绍 IBM HTTP Server 配置。

在对 WebSphere Process Server 拓扑结构的基本概述中,我们大体介绍了理解和成功使用后面介绍的过程所需的知识。关于 Process Server 拓扑结构的深入介绍,包括安装和配置步骤,请参阅 IBM 红皮书 WebSphere Business Process Management V7 生产拓扑结构

连续可用性场景中的拓扑结构角色

在 WebSphere Process Server 中实现连续可用性的关键是最大程度地减少应用程序更新期间的宕机时间。我们的目标是在更新应用程序时,让客户端不会体验到任何宕机时间,最好完全注意不到任何变化。对于某些类型的应用程序,这很简单,无需特殊的准备。但对于大多数 Process Server 应用程序,一次零宕机时间的更新需要精心规划,还需要采用一个涉及到在各个节点间路由传入应用程序流量的特殊过程。稍后我们会详细介绍此过程,但我们首先会概述使此目标变为可能的 Process Server 拓扑结构。

实现连续可用性的一个前提条件是我们实现所谓的 “高可用性”。要实现连续可用性,建议采用某种与图 1 类似的拓扑结构:由一个 2 节点和 4 个集群组成的拓扑结构,每个节点上拥有每个集群的一个节点。在最低限度下,您必须有一个与消息集群分开的应用程序目标集群。这可以确保消息引擎可与应用程序目标服务器独立地进行故障转移。还必须有至少两个独立的节点,用于托管应用程序目标和消息集群的成员。这使您能够停止一个节点上的服务器并更新一个应用程序,同时让另一个节点处理所有应用程序流量。这些建议不仅为实现连续可用性提供了基础,还为高可用性奠定了牢固的基础。


Process Server 应用程序的背景

WebSphere Process Server v7.0 应用程序通常被组织为模块单元,这些单元以服务组件架构 (SCA) 模块的形式进行开发和部署。一个模块可包含各种不同的 SCA 组件,以及封装业务逻辑的基本构建块,这些构建块通过一个接口向其他组件公开。WebSphere Process Server 中的常用组件类型包括业务流程执行语言 (BPEL) 流程、中介流组件 (MFC) 和服务组件。

WebSphere Process Server 应用程序模块通常在 WebSphere Integration Developer 中开发。开发一个模块后,会将它导出为一个企业归档 (EAR) 文件。该 EAR 通常首先部署到 WebSphere Process Server 测试环境,在该环境中,在进行隔离测试以及与应用程序一起的整体测试。在通过全面测试后,就会将该模块部署到生产环境。尽管本文关注的重点是这个部署阶段,但必须理解一些应用程序开发级别上的概念,才能成功实现连续可用性。

SCA 调用风格

SCA 组件可同步或异步调用。同步调用意味着,在从被调用的组件收到响应之前,调用方会被阻塞。因为服务请求方和服务提供方在同一个线程中运行,所以在从提供方收到响应之前,请求方的所有处理都会暂停。

图 2. 同步 SCA 调用
同步 SCA 调用

如果只在从提供方收到响应后请求方才会继续进行相应的处理,那么同步 SCA 调用将会很有用。

在异步调用中,调用方无需等待立即生成响应就可以调用服务。服务请求方和服务提供方在不同的线程中运行,所以在提供方准备响应期间,请求方可继续处理。

图 3. 图 3. 异步 SCA 调用
图 3. 异步 SCA 调用

如果 (1) 提供方可能花很长时间才能响应(几分钟、几小时或几天)或 (2) 请求方可执行不依赖于提供方返回的信息的进一步处理工作,异步调用会很有用。WebSphere Process Server 应用程序中可使用 3 种形式的 CSA 异步调用:单向调用、回调调用和延迟响应调用。要了解这些异步调用风格以及它们如何应用于 WebSphere Process Server,请参阅 developerWorks 文章 WebSphere Process Server 中的异步处理

BPEL 流程调用中的早期绑定和延迟绑定

讨论调用时要考虑的一种特殊情况是调用 BPEL 业务流程。BPEL 流程的客户端(调用方)可配置为对调用使用早期绑定或延迟绑定。早期绑定 意味着客户端被硬连接到流程的某个特定版本,而且它将仅调用该版本。更新一个通过早期绑定调用的流程时,还必须将客户端更新为使用新的流程版本。在延迟绑定 中,客户端将始终调用最新的流程版本。在运行时动态地决定客户端调用哪个流程版本。

根据客户端调用 BPEL 流程的方式,早期绑定和延迟绑定可通过多种方式进行配置。调用 BPEL 流程的一种方法是使用 Business Process Choreographer API。在这种情况下,控制调用绑定的类型非常简单,只需调用合适的调用方法即可。在 Business Process Choreographer API 中,调用方法一般有两个具有不同签名的版本:一个接受流程模板名称,另一个接受模板 ID。接受模板名称作为参数的方法使用了延迟绑定,而接受模板 ID 的方法使用了早期绑定。

BPEL 流程也可通过 SCA 连接从某个调用组件调用到流程组件。在默认情况下,从 SCA 组件对 BPEL 流程的调用是早期绑定的,因为 SCA 连接捆绑到了流程组件的某个特定版本。可以通过 SCA 使用一个 “代理流程” 来调用延迟绑定。此技术的详细信息可在 WebSphere Integration Developer 信息中心中的 创建要用于 SCA 组件和导出的流程版本 中找到。一般不建议这么做,因为它会创建可能影响性能的不必要的流程实例。

第三种情况是从一个 BPEL 流程调用另一个 BPEL 流程。这通过添加一个调用活动作为调用流程的一部分来完成。要将调用设置为早期版定形式,可使用一个 SCA 连接来连接两个流程组件。要使用延迟绑定,则不要使用静态 SCA 连接;应指定目标流程的模板名称作为调用活动的引用伙伴属性的一部分。有关的更多信息,请参阅 WebSphere Integration Developer 信息中心中的 使用一个伙伴链接扩展的延迟绑定


更新一个 BPEL 业务流程

如果仅需要更新一个 Process Server 应用程序中的一个 BPEL 业务流程,那么您应该阅读本小节。如果需要更改 SCA 模块中其他类型的组件,请参阅后面介绍 SCA 模块更新的两节内容。

得益于 BPEL 版本控制,更新一个 BPEL 流程并维护应用程序的连续可用性非常简单。惟一的需求是,(1) 流程的调用方被配置为使用延迟绑定,(2) 流程的旧和新版本拥有匹配的组件名称和目标命名空间。这些需求是正常的,也是最佳实践,所以这里没有重大的限制或不便。如果这些需求得到了满足,只要新流程版本被设置为有效的,就会无缝地拾取该版本。

在更新一个 BPEL 流程时,您还需要考虑已运行的流程实例是否应该迁移到新流程版本中。尽管这通常不会影响可用性,但我们仍然建议以增量方式执行实例迁移,避免您的系统过载。

如果决定迁移正在运行的实例,可参照指南 创建流程的新版本 - 迁移正在运行的实例 创建新的流程版本。否则,可执行 创建流程的新版本 - 正在运行的实例使用旧版本 中的步骤。我们建议设置 “valid-from” 时间,以便在生效前安装新流程版本。

创建新流程版本后,可像其他任何模块一样部署惟一命名的 SCA 模块,使用 Integrated Solutions Console 或 wsadmin 脚本。一定要将新流程模块安装为一个新应用程序,而不是将它安装为对现有应用程序的更新。如果执行这些步骤,新流程版本在变得有效时会顺利地被拾取。如果您确定因为没有其他客户端被早期绑定到该流程版本,所以没有正在运行的实例,也没有遗忘的旧的失败事件或消息,那么您可以安全地删除旧流程模块。


在同步 Process Server 应用程序中更新一个 SCA 模块

在一个严格同步的应用程序中更新一个 SCA 模块,同时保持连续可用性,这也非常简单。谈到 “严格同步”,我们的意思是应用程序中的所有调用都保持同步。大多数 Process Server 应用程序都不属于这个类别。对于包含任何异步调用的应用程序,我们建议使用本文下一节中介绍的过程。

我们对同步应用程序更新的测试表明,连续可用性可在就地更新期间实现,无需使用任何复杂的过程或特殊配置。但是我们强烈建议您在自己的测试环境中使用您自己的应用程序进行测试,然后尝试在生产环境中使用它。

这种就地模块更新的步骤与其他任何 Process Server 应用程序更新大体相同。首先,像平常一样对 SCA 模块进行修改。然后使用 Integrated Solutions Console 或 wsadmin 脚本部署更新的模块。

您可能习惯性地在应用更新之前停止应用程序或服务器,但在这里不用这么做。要部署更新的模块,只需使用 WebSphere 的 Update 特性,然后保存并在节点之间同步更改。这会将更新的模块同时安装到您服务器上,不会导致任何宕机时间。在本例中,我们不建议使用 Rollout Update 特性。Rollout Update 会自动暂停或停止每个应用服务器,以便按顺序地应用更新,但在本例中,我们不希望暂停或停止任何服务器,因为这会产生一个不可用阶段。

只要您应用程序中的所有调用都是同步的,那么使用此方法的失败风险就非常低。如果在测试过程中遇到困难,请参阅下一节,了解一种可以安全地用于所有应用程序类型的技术。


更新一个使用异步或混合调用风格的 Process Server 应用程序中的 SCA 模块

在需要更新一个使用异步调用的应用程序中的 SCA 模块时,实现连续可用性会稍微复杂一些。本节将讨论的过程适合所有包含异步调用或同时包含同步和异步调用的 Process Server 应用程序。这包括使用本文之前提及的 3 种异步调用的任一种的应用程序。

在这种情况下,实现连续可用性更复杂的原因在于,异步调用需要消息支持。任何异步模型天生包含多个事务。队列也是该模型的一部分。这些架构元素相结合,使得该场景成为了比直观的同步调用更复杂的场景。在更新期间,异步调用的 SCA 模块的目标队列可能被标记为用于删除,这些队列中包含的任何消息都可能会丢失。这意味着如果应用程序在繁忙地处理工作,直接就地更新可能存在风险。因此,对于这种类型的更新,我们必须能够控制流量流,仅在工作结束后才更新某个特定节点上的应用程序。我们的方法将是,一次在一个节点上执行应用程序更新,以始终保持可用性。

首先,我们将提供各种专门适用于此更新过程的 WebSphere 和 WebSphere Process Server 概念的一些背景。在尝试该过程之前,请确保您完全理解这些概念。因为自动化该过程有助于避免不一致性,并最大限度地减少所需的时间,所以我们将提供一些示例脚本。本节末尾将会详细介绍更新过程本身。

节点同步

我们可通过禁用或启用节点同步,控制一个节点何时将收到一个应用程序的新版本。如果禁用一个节点上的节点同步,该节点将无法知道应用程序工件主存储库中的变化,因此该节点上的任何应用程序都不会更新。希望执行一次应用程序更新时,我们重新启用节点同步,当触发同步后,新工件会拉入到节点的服务器中。

我们发现在禁用或启用节点同步后,有必要重新启动节点代理,这样才会让更改生效;因此,本文的 下载 部分中还提供了禁用、启用和重新启动一个节点的示例代码。

路由传入的 HTTP 流量

传入 WebSphere Process Server 的流量可能具有不同的形式,比如 HTTP、JMS 和 MQ 流量。在本节中,我们将讨论 HTTP 流量。我们需要能够将传入的 HTTP 流量路由到某些节点上的服务器,临时阻止流量到达其他节点上的服务器。我们将演示如何使用该 IBM HTTP Server 实现此操作,因为 IBM HTTP Server 不但简单,而且在 BPM 环境中得到了广泛应用。

IBM HTTP Server 依据它的 HTTP 插件配置文件 plugin-cfg.xml 在应用服务器中散播 Web 请求。有关这一工作原理的详细解释,请参阅技术说明 理解集群环境中的 IBM HTTP Server 插件负载平衡

对我们而言,重要的是 <Server> 元素的 LoadBalanceWeight 属性。通过将服务器的 LoadBalanceWeight 设置为 0,服务器不会再从新会话接收请求。来自现有会话的有关联的请求可继续路由到该服务器,只要未配置会话复制。但是,来自新会话的所有请求将路由到 LoadBalanceWeight 大于 0 的服务器。

实现此目标的一种方法是在 IBM HTTP Server 上提供多个 plugin-cfg.xml 文件,并在必要时将它们换出。例如,假设我们有两个应用服务器请求在正常情况下会路由到:A.App 和 B.App。在这种情况下,我们需要使用 3 个 XML 配置文件:一个文件允许发出针对两个服务器的请求 (both.xml),一个文件仅将请求路由到 A.App (a.xml),另一个文件仅将请求路由到 B.App (b.xml)。

在正常操作模式中,IBM HTTP Server plugin-cfg.xml 将包含 both.xml 的内容。当在一个服务器上执行应用程序更新时,我们会简单地将 plugin-cfg.xml 的内容换为其他的配置文件。例如,如果希望所有请求都路由到 A.App,则应将 plugin-cfg.xml 替换为 a.xml。IBM HTTP Server 无缝地挑选配置更改,并停止将请求路由到 B.App。正常情况下,在 IHS 检测到配置更改之前会有一个延迟,但我们可使用以下命令适当地立即重新加载该配置:
IBM/HTTPServer/bin/apachectl -k graceful
(请参阅 下载 部分中提供的 ihs_route_to_node_a.sh。)

路由其他流量

重新路由传入的 HTTP 流量后,集群成员仍然可以通过 JMS 或 MQ 流量收到新工作。集群成员只有在完成处理工作之后才能关闭;因此我们还需要一种方式来组织新的 JMS 和 MQ 流量流入。为此,我们取消激活一个集群成员的 J2CMessageEndpoints。我们会在 下载 部分提供的 quiesce_traffic_jms_mq.jacl 脚本中演示此过程。

如果 BPEL 流程已安装并运行,我们还需要阻止 BPEL 调度程序生成的流量。这可以通过阻止 BPEScheduler 来实现,如 下载 部分中提供的 quiesce_traffic_bpel.jacl 脚本所示。

如果创建了其他任何调度程序,那么应该停止它们。您可以通过脚本完成此过程,如上面的 BPEScheduler 脚本所示。

适当地停止和启动服务器

所有传入流量都阻止后,就可以安全地停止一个节点上的集群成员。我们建议按以下顺序停止节点的集群成员:应用程序目标集群,Web 集群,支持集群,然后是消息集群。这可以通过 wsadmin 编写脚本来完成,也可以通过 Integrated Solutions Console 来完成,但我们同样推荐尽可能多地编写脚本,以实现更高的一致性。可以使用 下载 部分中提供的 stop_cluster_members.jacl 脚本。

更新一个节点上的应用程序之后,需要再次启动它的集群成员。我们建议按与停止顺序相反的顺序启动集群成员;也就是启动消息集群、支持集群、Web 集群和应用程序目标集群。重新启动一个集群成员后,无需重新激活 J2CMessageEndpoints 或重新启动 BPEScheduler,因为这将在服务器启动时自动完成。(参见 下载 部分中提供的 start_cluster_members.jacl。)

失败事件

在 WebSphere Process Server V7.0.0.3 中测试此过程期间,偶尔也会看到在消息引擎故障转移期间会发生 SCA 失败事件。但是,根据我们的经验,失败事件可在更新完成后重新提交。失败事件管理器可在 Integrated Solutions Console 中进行访问,也可以使用 wsadmin 脚本重新提交失败事件。(参见 下载 部分中提供的 resubmit_failed_events.jython。)

store-and-forward

如果希望最大限度地减少生成的失败事件,可以使用 WebSphere Process Server V7.0 中新增的 store-and-forward 特性。如果使用此特性,在出现运行时错误时,只会生成一个失败事件。发生一个运行时错误后,将触发一个存储 操作,一个服务的所有后续请求都会存储在一个队列中,而不是被提交。您随后可使用 Business Space 中的 Store and Forward 小部件将这些请求转发到它们的目的地。目前还没有公开的 store-and-forward API 支持更改存储/转发状态,所以我们不建议通过脚本完成此步骤,但我们已验证可以这么做。有关如何使用 store-and-forward 特性的更多细节,请参阅 developerWorks 教程 使用 WebSphere Process Server v7.0 中的 store-and-forward 特性

应用程序级设置

在 WebSphere Process Server V7.0.0.3 中测试此过程期间,我们发现了一些最适合具有某些属性的异步应用程序的应用程序级设置。我们遇到的大多数故障都发生在消息引擎在集群成员之间执行故障转移期间。要使更新过程获得成功,让您的应用程序适当地处理消息引擎故障转移就很重要。遵循我们这里提供的建议会是一个不错的开始,但考虑到 IBM BPM 应用程序和环境的易变性,可能您的场景需要采用稍微不同的设置。因此,我们明确建议在消息引擎故障转移期间在负载下测试您的应用程序,以确保它得到适当的处理并且没有丢失重要消息。

首先,如果您的模块包含任何中介流组件,请确保失败的终端被连接到某个失败错误处理组件。这可以确保失败事件会被保存,失败的事务会在必要时回滚。如果您的模块使用 store-and-forward,那么我们建议您设置 store-and-forward 限定符,以便捕获所有 ServiceRuntimeExceptions。在更新过程中,可能发生许多类型的运行时异常,您需要确保捕获了所有这些异常。如果您的模块包含任何单向异步调用,那么我们建议将引用的异步调用限定符设置为 call,而不是将它设置为 commitcall 是默认设置)。最后,对于任何类型的异步调用,我们建议将引用的异步可靠性限定符设置为 assured (persistent)。最后两条建议有助于确保在更新过程期间发生故障时不会丢失任何消息。

如果您的异步模块拥有上面描述的任何属性,我们极力建议使用这些设置。再次申明,我们强烈要求您进行全面测试,因为一个应用程序和环境的需求可能与另一个应用程序和环境不同。

异步应用程序中的 SCA 模块的更新过程

我们已单独讨论了更新过程的重要元素,下面将详细介绍该过程本身。在对包含异步调用或混合风格调用的应用程序执行模块更新期间,可按照以下步骤来实现连续可用性。每一步之后是一张图,反映了完成该步骤后该单元的组件状态。

  1. 在开始更新之前,Process Server 调用出于其正常操作状态

    所有 JVM 都在运行,包括部署管理器、所有集群成员和所有节点代理。为两个节点都启用了自动节点同步,这用节点代理与部署管理器之间的蓝线表示。节点 A 的消息集群成员上的消息引擎 (ME) 是活动的。HTTP 流量路由到 AppTarget 集群的所有成员,如橙色的虚线所示。BPEScheduler 调度程序正在运行。appX 的 v1 版目前部署到两个节点的应用程序目标,也可在主存储库中看到。我们将把 appX 的 v2 版部署到应用程序目标集群,一次部署一个节点。Support 和 WebApp 集群未在这里显示,因为我们假设应用程序仅安装在 AppTarget 集群上。在逐步执行的过程中,我们将用红色突出显示更改。

    图 4. 开始状态
    开始状态
  2. 在安装该应用程序的所有节点上禁用节点同步并重新启动节点代理。

    我们禁用了节点同步,以便在使用部署管理器更新应用程序后,节点不会立即收到应用程序的新版本。我们仅在每个节点的集群成员适当地关闭之后,才更新该节点上的应用程序。

    这在图 5 中表示为没有蓝线连接节点代理和部署管理器。

    图 5. 对所有节点禁用节点同步
    >对所有节点禁用节点同步
  3. 使用部署管理器更新应用程序模块不要在节点之间同步更改。

    使用 wsadmin 脚本或 Integrated Solutions Console 安装更新。使用 Update 特性更新现有模块,而不是将更新安装为新模块。将更改保存到主存储库,但不要与节点同步更改。

    执行这一步之后,模块的 v2 版将位于主存储库中,但不在每个节点的本地配置中。在这里,我们只演示了如何更新一个模块,但您也可以一次更新多个模块,只要更改是向后兼容的(参见第 3d 步)。

    图 6. 将更新安装到主存储库
    将更新安装到主存储库
  4. 对于安装了该应用程序的每个节点,执行以下步骤,一次处理一个节点。我们仅演示对节点 A 的处理,但可以在节点 B 上重复这些步骤来完成更新。
    1. 停止所有传入到节点上的集群成员的流量。这包括 HTTP、JMS、MQ 和 BPEL 流量。除非配置了会话复制,否则仍有活动的 HTTP 会话被绑定到集群成员,而且它们可能包含任何关键数据,您应该等待它们关闭。

      我们阻止了传到节点上的集群成员的流量,因为我们需要在下一步中适当地停止集群成员。在完成所有工作之前,集群成员将不会关闭;因此假设存在持续的传入流量,我们必须重定向该流量,以便为服务器留出充足的关闭空间。本节前面已经介绍了如何对 HTTP、JMS、MQ 和 BPEL 流量这样做。

      这一步将在下面通过 plugin-cfg.xml 中的更改来演示。完成更改之后,所有 HTTP 请求都会路由到节点 B 上的集群成员。

      图 7. 阻止传入到节点上的集群成员的流量
      阻止传入到节点上的集群成员的流量
    2. 停止该节点上被应用程序利用的集群成员

      一定要按本节前面给定的顺序停止集群成员:应用程序目标、Web、支持和消息。例如,如果应用程序被部署到应用程序目标集群,那么首先应该停止应用程序目标集群成员,然后,因为这是一个使用异步调用的应用程序,所以应该停止消息集群成员。如果消息引擎目前在节点上的一个集群成员上是活动的,那么会将故障转移到不同的集群成员。这可能会花费几秒或几分钟的时间,具体时间取决于您的环境,但您需要在故障转移完成之后才能继续操作。

      我们停止了集群成员,因为我们不希望在节点上的模块更新期间执行工作。

      图 8 中的黑框显示了已停止的集群成员。请注意,消息引擎目前在节点 B 的消息集群成员上是活动的。

      图 8. 停止节点上的集群成员
      停止节点上的集群成员
    3. 启用节点同步并重新启动节点代理。如果节点未配置为在启动时同步,则触发同步。等待节点同步完成,然后再进入下一步。

      由于执行了节点同步,所以节点代理会收到来自主配置的更改并更新节点的本地配置。

      这一步如图 9 中将节点代理连接到部署管理器的红线所示。模块的 v2 版现在位于节点的应用程序目标集群成员之上。

      图 9. 对节点启用节点同步
      对节点启用节点同步
    4. 启动您在第 3b 步中停止的所有集群成员

      现在节点已包含更新的应用程序,我们可启动它的集群成员了。请记住,按照正确的顺序进行启动:消息、支持、Web 和应用程序目标。

      当集群成员启动时,MDB 和调度程序会自动启动。因为我们将在下一步中重新启用 HTTP 流量,所以除了集群成员本身之外,现在无需手动重新启动任何东西。

      如图 10 所示,可能在较短的时间内节点会同时运行应用程序的两个不同版本。在本例中,Module_4 的 v1 和 v2 会同时向 Module_5 的目标队列中放入消息。如前面所述,只要更改是兼容的,就不会出现问题。例如,如果 Module_5 需要按与 Module_4 v2 兼容的顺序更新,那么它的新版本也必须与 Module_4 v1 兼容。

      图 10. 过渡期间的混合模块版本
      过渡期间的混合模块版本

      要让这个时间段尽可能短,您应该在此节点的集群成员启动后,立即停止下一个节点上的集群成员。如果通过编写脚本来完成此任务,过渡可在几秒的时间内完成,前提是您只有 2 个节点。如果应用程序需要在超过 2 个节点上进行更新,那么您可选择在等待启动运行性版本的节点之后,所有运行旧版本的节点才会停止。在任何情况下,都应在尝试这么做之前测试同时运行的不同版本。如果发现任何兼容性问题,则不应使用此更新过程。

      这一步在图 11 中通过绿色集群成员来表示,这表明它们现在已经再次运行。请注意,消息引擎仍在节点 B 的消息集群成员上运行。如果节点 A 上的集群成员被配置为首选服务器,那么消息引擎现在将变为在节点 A 上运行。

      图 11. 启动节点上的集群成员
      启动节点上的集群成员
    5. 如果在第 3a 步中禁用了传入 HTTP 流量,则启用向节点上的集群成员的传入 HTTP 流量

      如果有另一个节点需要更新,可通过恰当编写 plugin-cfg.xml,将这一步与下一个节点的第 3a 步相结合。这样做有助于最大限度地缩短模块的不同版本同时运行的时间段。

      图 12. 启用传入的 HTTP 流量
      启用传入的 HTTP 流量
    6. 对尚未更新该应用程序的所有剩余节点重复步骤 a 到 e。
  5. 重新提交在该过程中发生的任何失败事件。如果您的应用程序利用了 store-and-forward,则转发可能尚未存储的所有事件。
  6. 更新完成!
    图 13. 最终状态
    最终状态

变体:Process Server 修复程序包安装

通过扩展上一节中描述的应用程序更新过程,我们可以在 WebSphere Process Server 修复程序包安装期间实现连续可用性。一般方法仍然相同:一次对一个节点应用更新,在安装修复程序包期间将流量路由到该节点以外。

请注意,在升级期间,整个单元的健康状况都存在风险,而不只是一个应用程序的健康状况存在风险。因此,在这种情况下,强烈建议在类似的测试环境中对此过程进行全面测试之前,不要在生产环境中尝试它。

另请注意,我们仅测试了从 V7.0.0.4 升级到 V7.0.0.5 的过程,无法保证相同的方法会在其他情况下奏效。我们的一个假设是,修复程序包不需要任何数据库更新。这是因为我们在此过程的某个时刻将有一个 “混合单元”;也就是说,集群将拥有同时运行不同 Process Server 版本的成员。如果存在数据库不兼容性,这可能导致严重问题。

我们将概述在从 V7.0.0.4 升级到 V7.0.0.5 期间,我们用于实现连续可用性的过程。首先请阅读 WebSphere Process Server 和 WebSphere Enterprise Service Bus V7.0.0 Fix Pack 5 (V7.0.0.5) 特殊说明,了解以最少宕机时间执行更新的官方说明。我们这里提供的方法对这些说明进行了修改,大致实现了相同的最终结果(一个升级的单元),但在某种程度上实现了近连续的可用性。对于每一步骤,请参阅官方说明中的相应步骤,以了解有关的更多信息。

Process Server 修复程序包安装过程

  1. 在开始升级之前,Process Server 单元处于正常操作状态。

    为了演示此过程,我们将使用图 14 中所示的部署环境,其中包含一个部署管理器和 2 个自定义节点,二者都运行了 WebSphere Process Server V7.0.0.4。因为这些节点托管在不同的机器上,所以每个节点可单独升级。此刻,所有 JVM 都在运行,包括部署管理器、所有集群节点和所有节点代理。对两个节点都启用了自动节点同步,这用节点代理与部署管理器之间的蓝线表示。消息引擎 (ME) 在节点 A 的消息集群节点上运行。HTTP 流量路由到 AppTarget 集群的所有成员,如橙色的虚线所示。为了简单起见,我们仅显示了应用程序目标和消息集群,事实上可能有更多的集群。我们将在执行该过程期间定期显示此图,以红色突出显示更改。

    图 14. 开始状态
    开始状态
  2. 禁用节点同步并重新启动所有节点的节点代理。
  3. 停止部署管理器。
  4. 将修复程序包安装到部署管理器的安装根目录。
  5. 启动部署管理器。
    图 15. 安装到部署管理器的修复程序包
    安装到部署管理器的修复程序包
  6. 对于您希望升级的每个节点,完成以下步骤,一次处理一个节点:
    1. 阻止所有传入到节点上的集群成员的流量,包括 HTTP、JMS、MQ 和 BPEL 流量。如果仍然有活动的 HTTP 会话被绑定到集群成员,请等待它们关闭。
    2. 停止节点上的所有集群成员。
    3. 停止节点的节点代理。
      图 16. 节点上已停止的集群成员和节点代理
      节点上已停止的集群成员和节点代理
    4. 将修复程序包安装到节点的安装根目录中。
      图 17. 安装到节点的修复程序包
      安装到节点的修复程序包
    5. 从部署管理器,对其成员包含在此节点中的每个节点运行配置文件升级脚本。此脚本只应对每个单元的每个集群运行一次,所以如果所有集群已升级,请跳过此步骤。
    6. 如果配置了 Business Space 且模板/空间托管在此节点上的一个集群成员上,则执行 安装或更新小部件之后更新 Business Space 模板和空间 中的第 1a 和 1b 步。这篇文章还有助于确定这些模板和空间托管在哪个集群成员上。我们建议首先升级托管模板和空间的节点。
    7. 启用节点同步并重新启动节点代理。如果节点未配置为在启动时同步,则会触发同步。等待节点同步完成,然后再进入下一步。
    8. 启动您在第 5b 步中停止的所有集群成员
    9. 如果在第 5a 步中禁用了传入的 HTTP 流量,则启用传入到节点上的集群成员的 HTTP 流量
      图 18. 启动集群成员,对节点启用节点同步
      启动集群成员,对节点启用节点同步
    10. 对尚未应用修复程序包的剩余所有节点重复步骤 a 到 i。
  7. 重新提交在该过程中发生的任何失败事件。如果您的模块利用了 store-and-forward,则转发所有可能已存储的事件。
  8. 修复程序包安装已完成!
图 19. 最终状态
最终状态

结束语

通过仔细规划拓扑结构和恰当地编写更新业务流程解决方案组件的脚本,可显著改善可用性。这使得您能够在需要近连续的可用性的环境中利用 BPM 应用程序。除了拓扑结构之外,我们还概述了一组应用程序设计准则,提供了更新 Process Server 应用程序的各个组件的过程。尽管应用于实现连续可用性的技术需要修改之后才适合特定组织中的具体安装和配置,但总体思路应该是简单明了的。

在未来,我们预计会提供如何使用 IBM BPM V8 或其更高版本实现类似可用性水平的更多信息。在基于 EAR 的 “仅 Process Server” 模式中使用 IBM BPM V8 时,本文中提供的方法和细节应该同样适用。但在该环境中,由于存在 Process Center,而且在流程应用程序和工具包中增加了所创作的不同类型的工件,所以您将面临着新的挑战和机遇。


致谢

感谢 Karri Carlson-Neumann 审阅本文并提供建议。


下载

描述名字大小
本文中使用的脚本scripts.zip4KB

参考资料

学习

获得产品和技术

讨论

条评论

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=941682
ArticleTitle=在 WebSphere Process Server V7 中实现连续可用性
publish-date=08212013