内容


操作 WebSphere Process Server 环境,第 1 部分

概述

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 操作 WebSphere Process Server 环境,第 1 部分

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

此内容是该系列的一部分:操作 WebSphere Process Server 环境,第 1 部分

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

简介

每个 IT 部门都力求为系统维护一个健康的生产环境。集群式 WebSphere Process Server(后面简称为 Process Server)环境要与大量后端和前端系统以及服务进行交互,维护这样的环境变得很困难。

本系列的第 1 部分介绍 WebSphere Process Server 生产环境的系统管理和操作方面的基本任务。本文讨论维护健康的生产环境的各种方式和工具。本系列中的后续文章将详细讨论这里概述的重要主题。

WebSphere Process Server

IBM® WebSphere Process Server 可以用来在面向服务体系结构 (SOA) 中运行业务集成应用程序。它提供高级的业务过程管理系统,可以执行业务过程,能够与消息传递设施、Web 服务和各种后端系统集成。

体系结构概述

图 1 显示 WebSphere Process Server 的主要组件。

图 1. WebSphere Process Server 组件
WebSphere Process Server 组件
WebSphere Process Server 组件

图 1 的底部显示 WebSphere Process Server 的基础设施 —— WebSphere Application Server。位于基础设施层之上的是 SOA 核心层,其中包含 Service Component Architecture (SCA)、业务对象 (BO) 和通用基础事件(CEI)。

SOA 核心层的上面是支持服务。这包括来自 Enterprise Service Bus (ESB) 的仲裁流以及各种映射组件、选择器和业务日历。最上面一层包含用于编排业务过程的各种元素:业务过程和业务状态机、人工任务和业务规则。

WebSphere Process Server 使用多个数据库或数据库表存储运行时数据。这些数据库用来存储以下方面的信息:

  • 业务过程、人工任务和业务状态机:这些信息存储在 Business Process Choreographer 数据库 (BPEDB) 中。每个 Business Process Choreographer 部署目标有一个数据库。
  • 由 Business Process Choreographer Explorer 报告功能使用的来自业务过程事件的数据:这些信息存储在 Observer 数据库 (OBSRVDB) 中。每个 Business Process Choreographer 报告功能部署目标使用一个数据库。
  • 关于业务规则、选择器、仲裁、Business Space 和失败事件的信息:这些信息存储在公共数据库 (WPRCSDB) 中。每个单元使用一个数据库。
  • Enterprise Service Bus 日志:这些信息存储在 ESB Log Mediation 数据库 (EsbLogMedDB) 中。
  • 消息传递信息和 Service Integration Bus (SIB) 消息:它们存储在由 WebSphere Process Server 使用的总线的 SIB 数据库表 (MEDB) 中。每个消息传递引擎有自己的一组表。
  • 公共事件:这些数据存储在公共事件数据库 (EVENT) 中。每个 CEI 部署目标有一个数据库。

运行时拓扑

根据业务需要或可用的基础设施,WebSphere Process Server 可以使用多种拓扑。图 2 给出许多客户环境中常用的三种主要拓扑。可以使用管理控制台提供的模式和向导安装和配置这些拓扑。

图 2. 运行时拓扑
运行时拓扑
运行时拓扑

除了集群式拓扑之外,WebSphere Process Server 还可以在单独的服务器环境中运行。但是,这种设置更适合开发环境,典型的生产环境最好使用集群式拓扑。因此,本系列主要关注集群式环境和其中适用的拓扑。

关于 WebSphere Process Server 拓扑的更多信息,请参见 IBM Redbook WebSphere Business Process Management V6.2 Production Topologies

WebSphere Process Server 环境通常是集群或单独服务器实例的组合,它们运行服务器代码、数据库、用户注册表以及后端和前端系统。管理员主要负责维护 WebSphere Process Server 环境。这包括运行时服务器本身,以及用来存储 WebSphere Process Server 运行时数据的数据库。尽管常常由不同的管理员分别负责这些资源,但是我们认为应该对保持 WebSphere Process Server 环境顺畅运行所需的整个设置有一个总体了解。

保持环境正常运行的一般实践

因为 WebSphere Process Server 基于 WebSphere Application Server,所以 WebSphere 管理和操作的一般原则也适用于 WebSphere Process Server。在 IBM Redbook WebSphere Application Server V6.1: System Management and Configuration 中可以找到关于如何管理 WebSphere Application Server 系统的详细信息。

在操作 WebSphere Process Server 环境时,还要考虑其他一些因素。本文和本系列中的后续文章将讨论这些主题。

创建和维护操作手册

强烈建议为您的 WebSphere Process Server 环境创建操作手册。这个手册包含操作 WebSphere Process Server 环境所需的所有过程。首先是整体设置的概况,包括涉及的机器、安装的产品版本和二进制代码在驱动器上的位置。手册包含启动/停止和暂停过程、所有配置的完整配置数据、配置和应用程序更改过程以及产品维护过程。

另外,操作手册包含初始问题判断的最佳实践和向 IBM 支持人员报告问题的过程。手册规定在判断问题时记录观察结果的格式,从而确保向 IBM 支持人员提供一致的信息。

操作手册还包含一个历史记录部分,其中记录对系统做过的操作和更改。当发生重大问题,需要紧急更改时,操作手册可以提供帮助。通过记录以前更改的历史和系统本身的相关信息,每个管理员都可以更改系统。

引入更改控制管理

更改控制管理是必不可少的操作部分。如果对更改历史的控制不充分,就会导致各种问题,比如当需要回滚 “不适当的” 更改时,就不能确定应该恢复到哪种状态。另外,书面的更改历史记录对问题判断会有帮助。更改控制管理可以提供灵活性,同时有助于实现严谨的工程原则。它包括对环境配置、应用程序和基础设施的更改控制。

更改控制管理还有助于在操作团队和开发团队之间实现良好、持续的交流。在生产环境中实际应用更改之前,应该在与生产环境尽可能相似的环境中,对应用程序、配置以及产品维护的更改进行跟踪和测试。至少测试环境和生产环境的基本拓扑应该是相同的。例如,在单独服务器环境中测试成功并不能够保证在集群式环境中一切正常。

最好有一个具有以下特征的预生产环境:

  • 包含与生产环境相同的应用程序和应用程序版本。
  • 配置为相同的拓扑。
  • 从操作系统层开始,包含相同的软件组合。
  • 在与生产环境相似的硬件上运行。

可以使用这样的预生产环境测试和检验要应用的所有更改,比如系统升级、应用程序和配置更改或安装补丁,而不会影响到生产环境。还可以使用它进行负载和性能测试,最后可以使用它进行迁移测试。

引入可重复的管理任务

脚本化的构建、部署和其他程序性措施对于提高操作效率非常有帮助。

我们建议尽可能创建和使用脚本和日志记录来提高任务(比如在 WebSphere Process Server 环境中安装和卸载应用程序)的自动化程度、可审计性和可重复性。对于反复出现的配置更改、启动和停止环境以及监视队列深度和失败的事件,都可以使用脚本。

对系统健康状态的监视和恢复

生产环境需要连续地监视。因为 WebSphere Process Server 基于 WebSphere Application Server,所以 Application Server 管理实践也适用于 WebSphere Process Server。另外,有专门针对 WebSphere Process Server 的系统监视工具和实践。

WebSphere Application Server 提供大量工具,可以从应用服务器的角度管理系统。详细信息参见 IBM Redbook WebSphere Application Server V6.1: System Management and Configuration

WebSphere Process Server 为 Application Server 管理控制台提供更多功能,比如管理失败的事件和浏览公共事件。下面几小节将解释需要监视的内容。

需要设置监视工具,从而在发生系统事件时通知系统管理员。例如,某个队列超过了为它定义的阈值。另外,这些工具提供从系统收集的信息,从而修复或响应这些事件。至少应该通过自动化脚本收集操作支持所需的所有数据。

WebSphere 的 MBean API 与 Java™ Management Extension 兼容,它们提供许多可监视的项目,可以以程序方式管理系统中的更改。可以使用这些 API 方便地编写定制的监视应用程序。关于这个主题的更多信息,请参见以下信息中心主题:关于这个主题的更多信息,请参见以下信息中心主题:

除此之外,还可以实现复合应用程序监视工具。可以使用这些工具提供 WebSphere Process Server 环境中部署的复合服务的可用性和响应时间报告。

实现这种工具的方法是,让定制的服务定期调用涉及的子系统上的 “心跳” 应用程序,或者通过现有的监视、警报和报告基础设施中集成的 Tivoli® ITCAM 等解决方案实现。

检查日志文件

提示:应该定期检查日志中的错误消息。

WebSphere Process Server 环境中的 JVM 会在日志文件中写入信息,如果启用了跟踪,还会将信息写入跟踪文件。这些日志文件能够很好地反映系统的总体健康状态。另外,如果在运行时处理期间发生意外问题,就会生成 First Failure Data Capture (FFDC) 文件。

在典型的 WebSphere Process Server 集群环境中有多个 JVM。每个 JVM 根据自己的需要记录信息和错误(见表 1)。

表 1. JVM 在 WebSphere Process Server 环境中的典型用途
JVM用途要寻找的信息
Deployment Manager 中心配置点。 Deployment Manager 的日志文件对于判断配置问题很重要。
Node Agent 通信和配置更新。 Node Agent 的 JVM 日志对于判断通信问题通常很重要。
ME 集群成员 驻留消息引擎。 JVM 日志显示处于 “Started” 或 “Joined” 状态的消息引擎,或者是否有失败。
应用程序集群成员 通常驻留 Business Process Choreographer。 JVM 日志显示执行业务过程和人工任务的相关信息。
支持集群成员 通常驻留 Common Event Infrastructure 和 Business Space。 JVM 日志显示执行 Business Space 和处理 CEI 事件的相关信息。

关于可用的日志记录选项和如何指定它们的概述,请参见 IBM Redbook WebSphere Application Server V6.1: System Management and Configuration。它概述可以使用的所有日志记录选项。

需要定期检查日志文件以便快速发现问题。另外,应该定期监视 FFDC 目录。从 WebSphere Process Server 6.1 开始,JVM 的 SystemOut.log 文件中的条目会表示出 FFDC 的创建以及它们在系统上的位置。

一般情况下,生产环境中的跟踪应该被设置为最低级别。如果没有特殊的需要(例如为了判断问题),不要 启用详细级别高于 INFO 的跟踪。

应该保留那些记录各个组件在启动服务器之后进行初始化的日志文件,因为它们包含重要的信息,比如组件的构建级别可能与 WebSphere Process Server 的总体构建级别不同。例如,如果在安装一个临时补丁之后没有调用 bpeupgrade.jacl,BPC Explorer 就会处于与 WebSphere Process Server 系统总体级别不同的级别。

我们还建议启用详细的垃圾收集跟踪。它对性能的影响非常小,可以连续地监视与堆使用情况相关的系统行为。关于如何启用这个特性及记录数据的位置的更多信息,请参见 Enabling verbose garbage collection (verboseGC) in WebSphere Application Server

应该确保文件系统中的磁盘空间和访问权限支持 WebSphere Process Server 日志记录。

除了 WebSphere Application Server 日志记录和跟踪特性之外,WebSphere Process Server 还提供 跨组件跟踪。这种跟踪显示 SCA 组件交互方面的详细信息。

监视和管理业务过程和人工任务实例

在 WebSphere Process Server 解决方案中广泛使用了业务过程实例,包括业务状态机和人工任务实例。它们存储在 Business Process Choreographer 数据库 (BPEDB) 中。为了保证系统的健康状态,数据库的规模不应该无限制地增长。

管理已完成的业务过程实例和人工任务

提示:应该尽可能减少实例的总数。

业务过程和人工任务实例完成之后,实例可能留在数据库中,也可能自动地删除。对于在完成之后没有自动删除的实例,WebSphere Process Server 系统管理员需要特别注意。

您需要与拥有实例的相关人员一起决定已完成的实例必须保留多长时间。需要根据这个决定实现一个管理操作,删除不再需要的实例。本系列的 第 2 部分 详细讨论从 Business Process Choreographer 数据库中清除已完成实例的各种方法。

在大多数情况下,把实例保留在数据库中是为了以后检查它们的相关信息。但是,一定要明白一点:运行时数据库只保存快照而不是完整的历史。本系列中后续的一篇文章将讨论适当的存档方法。

修复业务过程实例

提示:检查和修复正在等待的过程实例。

长时间运行的业务过程的寿命可能长达几年,但是 WebSphere Process Server 环境中运行的业务过程的业务功能所有者常常会定义最大时间。建议定期检查那些已经超过最大持续时间的过程实例。另外,需要定期检查在执行业务过程期间是否发生了错误,导致某些活动进入 STOPPED 状态。这些活动需要人工干预,过程实例才能继续执行。

在 BPC Explorer 中,可以使用预定义的 “Critical processes” 视图,还可以定义定制的视图,根据指定的筛选条件只获取有问题的实例。我们建议为您的业务过程实例定义这种视图并定期监视它们。需要结合业务功能分析显示的所有实例,决定是需要增加持续时间,还是需要人工干预(比如重新启动活动或终止这个实例)。

本系列中后续的一篇文章将提供详细信息。

监视和管理失败的事件

提示:尽可能消除失败的事件。

如果在 SCA 组件之间异步地处理请求时发生技术故障,就会产生失败的事件。可以在管理控制台中使用失败事件管理器用户界面检查这些事件,然后重新提交或删除它们。可以通过管理控制台或 MBean 接口访问失败事件管理器。您需要与应用程序所有者一起制定处理失败事件的管理战略。关于失败事件管理器的更多信息,请参见 WebSphere Process Server 信息中心主题 Failed event manager

可以实现自动处理已知的失败事件的过程,还可以实现自动监视失败事件管理器中的新事件的过程。我们建议这么做。可以使用 MBean 接口编写自己的监视应用程序。关于失败事件管理器接口的更多信息,请参见 FailedEventManager interface

本系列中后续的一篇文章将提供关于失败事件处理的更多信息。

监视和管理 CEI 事件存储的大小

提示:如果可能的话,根本不要使用 CEI 事件存储。

可以把 WebSphere Process Server 中的组件发出的公共事件存储在公共事件数据存储(EVENTS 数据库)中,而不是发布在 CEI 总线中。可以启用或禁用事件的发送和存储。如果您的系统支持将这些事件存储在事件数据库中,那么需要使用管理控制台中的 CBE Browser 监视并主动地管理它的大小。

信息中心的以下主题讨论如何使用公共事件:

监视和管理服务集成总线目的地中的消息

WebSphere Process Server 允许通过消息传递集成后端系统。它还在服务集成总线上使用消息传递进行内部处理。因此,监视和管理系统中的消息是很重要的。除了关注生成的 SCA 模块队列和 JMS 导出和导入使用的定制队列之外,还需要特别关注以下队列。

监视和重放 Business Flow Manager 和 Human Task Manager 持有队列

提示:保持持有队列为空。

必须监视 Business Flow Manager (BFM) 持有队列和 Human Task Manager (HTM) 持有队列。持有队列中的消息常常用于导航长时间运行的业务过程实例。在 BFM 持有队列中出现消息的原因可能是系统的临时负载过高,这种情况可能导致事务超时并回滚。为了在这种情况下不丢失消息,系统把消息放在持有队列中。这些队列中的消息数量应该是零,因此如果其中出现消息,就需要管理员人工干预。

从 WebSphere Process Server V6.2 开始,可以通过失败事件管理器访问这些消息,还可以重放它们。本系列中后续的一篇文章将解释管理这些消息的各种方法。

监视系统异常目的地

提示:保持系统异常目的地为空。

WebSphere Process Server 使用几个服务集成总线进行消息传递。每个总线有一个系统异常目的地。服务集成总线无法处理的消息存储在这里。无法处理消息的原因可能是:

  • 系统负载过重,这导致事务超时并回滚。
  • 消息的内容损坏或消费应用程序无法读取它。
  • 应用程序错误。

应该监视系统异常目的地的队列深度。目标是保持这些队列为空。可以使用定制的管理脚本监视队列,还可以使用 Service Integration Bus ExplorerService Integration Bus Destination Handler 等工具。从 WebSphere Process Server V6.2 开始,还可以在管理控制台中使用 Service Integration Bus Browser。本系列中后续的一篇文章将详细解释如何处理这些队列中的消息。

监视 WebSphere MQ 监听器端口的状态

提示:确保监听器端口正常运行。

在从 WebSphere MQ 队列获取消息时,Process Server 要使用监听器端口。需要不断监视这些端口,确保它们已经启动,让 Process Server 可以从 WebSphere MQ 获取消息。

可以使用管理控制台或 ListenerPort MBean 监视系统中的监听器端口的状态。我们建议使用 ListenerPort MBean 实现一个监视应用程序,用它定期检查端口状态并根据需要重新启动端口。

监视事件序列锁

提示:确保释放锁。

事件序列可以确保 WebSphere Process Server 组件按事件的交付次序处理它们。在整个业务集成场景中维护事件次序以保证异步调用正常运行。

事件序列服务通过在 WebSphere Process Server 的后端数据库上存储锁来确保这个功能正常运行。

有时候无法释放这些锁,就需要使用 esAdmin 命令人工释放锁。更多信息参见以下 WebSphere Process Server 信息中心主题:

监视系统中使用的适配器的事件存储

提示:确保到达的工作不会堆积起来。

WebSphere 有许多适配器,可以在模块的输入端和输出端使用它们。在输入端使用适配器时,建议使用事件存储保存从数据库、文件系统或 EIS 读取的事件,从而避免在交付过程中丢失事件。在这种情况下,应该定期监视事件存储,避免事件堆积起来。

到达的工作(比如平面文件适配器的文件系统中的文件或 JDBC 适配器的数据库表中的数据)不应该以超常的速度增长。

关于适配器的更多信息请参见 Configuring and using adapters

不断监视和维护数据库

提示:定期更新数据库统计数据。

要想维护健康的生产环境,必须管理它的后端数据库。第 3 部分 讨论一般的最佳实践。

不断监视和维护操作系统和磁盘空间

提示:不断监视操作系统资源。

为了确保系统健康,不但需要维护 WebSphere Process Server,还需要定期监视操作系统级别的情况。应该监视 CPU 和内存使用量、网络和 I/O 利用率以及空闲磁盘空间的数量。

为了给临时性的高峰负载留出足够的容量,平均资源使用量不应该接近基础设施的限制。

维护 wstemp 目录的大小

提示:在维护时删除它。

当管理单元中的 JVM 停止并且没有活跃的配置会话时,需要定期清除这个目录的内容。这对安装应用程序等配置操作的性能有积极影响。

应该在部署过程中包含清除 wstemp 目录内容的步骤。在这个过程中,一定不要 删除 wstemp\events 子目录及其内容。关于 wstemp 目录的详细信息参见 Content and maintenance of the wstemp directory for WebSphere Process Server V6

对系统应用修改

需要定期修改 Process Server 系统,包括引入新的应用程序、更新应用程序、更改配置和应用最新的服务包。这些修改都需要仔细地管理。

在对生产环境做任何修改之前,必须在与生产环境相似的测试环境中进行充分的测试。在生产环境中不加控制地引入修改会破坏系统。例如,在现有系统中添加新的应用程序可能会影响现有应用程序的服务水平,因为系统资源现在由更多应用程序分享。应该用更改日志记录修改的内容、修改的时间和应用修改的人。

在引入修改(比如产品维护或应用程序更新)之前,还应该建立系统的备份。全面可靠的备份战略是每个 WebSphere Process Server 环境都必须包含的部分。

应用程序管理

除了 WebSphere Application Server 应用程序管理实践(比如安装、卸载和更新应用程序)之外,还有 WebSphere Process Server 特有的应用程序管理主题和最佳实践。

与一般的 Application Server 应用程序不同,WebSphere Process Server 应用程序的组件可能有长时间运行的实例。例如,系统中的业务过程实例可能会运行好几周。卸载相应的应用程序会破坏业务操作。

Process Server 应用程序基于 SCA 模块。可以通过 Process Server 管理控制台检查这些模块。在应用程序管理期间,需要特别关注一些 Process Server SCA 组件实现(比如业务过程)。例如,在卸载或更新包含业务过程或人工任务的应用程序时,需要额外的操作。另外,还可以停止过程和任务模板,这会禁止创建新的实例,但是仍然允许现有的实例继续执行。

WebSphere Process Server 应用程序管理的一个重要方面是 SCA 模块、业务过程和人工任务的版本化。Process Server 的版本化概念在引入新的应用程序版本的同时,允许老版本仍然存在并完成正在处理的长时间工作。关于业务过程和人工任务版本化的更多信息参见 Versioning business processes and human tasks in WebSphere Process Server

本系列中后续的一篇文章将提供关于应用程序管理的详细信息。

应用产品维护

有计划的维护活动有助于避免那些 IBM 已经发现并为其提供了解决方案的系统异常行为。应该制定维护计划,从而及时地应用 Application Server 和 Process Server 补丁,避免不必要的生产系统停机。

可以通过以下任务应用维护:

  • 预订 My Notifications 支持内容更新,定期检查可用的补丁,判断它们对自己的生产环境的影响。
  • 根据生产战略的需要,在下一个发布计划中包含应用相关补丁的步骤。

另外,需要通过有效的通知过程及时了解环境中连接的系统的所有计划内或计划外维护窗口,从而在 WebSphere Process Server 环境中采取相应的必要措施。

结束语

在本文中,您了解了操作 WebSphere Process Server 环境的基本概念。本文只是一个起点,本系列中后续的文章将详细讨论这里提到的各个主题。

第 2 部分 介绍清理已完成的过程和任务实例以保持最佳 BPEDB 大小的方法。第 3 部分 讨论 BPEDB 的数据库级维护。本系列中的后续文章将讨论应用程序管理、监视和修复或存档方法等主题。

致谢

作者要感谢 Mark Allman、Karri Carlson-Neumann、Erich Fussi、Heinz Luedemann、Jose Martinez Rodriguez、Leon Matthews、Richard Metzger、Elke Painke、Ruth Schilling、Ralf Schmauder、Marc Schwind 和 Vishnuvardhanaraj Selveraj 审阅本文并提供宝贵意见。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=477604
ArticleTitle=操作 WebSphere Process Server 环境,第 1 部分: 概述
publish-date=03252010