简介： 在本文中，您将学习如何使用 WebSphere Application Server 中的 WebSphere Business Events 和 WebSphere MQ 部署一个高可用架构。
IBM WebSphere Business Events（以下称为 Business Events）帮助您基于可操作事件模式的发现来检测、评估和响应事件影响。它允许您定义和管理事件，使您能够及时采取行动。结果是凭借无代码实现减少了总体拥有成本。为了确保 Business Events 部署是高可用的，在您的实现过程中可以利用现有的 WebSphere Application Server Network Deployment（以下称为 Application Server ND）高可用性特性。
目前，利用 WebSphere Business Events 中的 Application Server 功能需要额外配置。在本文中，您将学习如何部署一个高可用架构，使用 Application Server ND 内部功能及 WebSphere Business Events 和 WebSphere MQ（以下称为 MQ） 中的特定应用程序设置，来提供高可用性。
“高可用性” 这一术语有很多定义，但是通常是指一个系统在绝大多数时间内是可用的，例如，一个系统有最小停机时间 —— 诸如升级或维修等必须的计划停机时间。可用性是以正常运行时间除以总时间的百分比来测量的。当数字大于 99. x 就是高可用性，其中 x 代表 1 到 3 位精度（例如，99.999% 可用性称为 “5 个 9 可用性”）。
术语可用性 和 高可用性 的含义有很大的不同，根据用户而定。这两个术语经常用来描述各种业务目标和技术需求，从纯硬件可用目标到任务关键型目标。
一个可用系统是由一组系统级共享资源组成的系统，共同合作提供重要服务。高可用性系统将软件和工业标准硬件相结合，在系统、组件或应用程序发生故障时快速恢复来使停机时间最小化。尽管不是即时的，但服务也是很快恢复的 —— 通常小于一分钟。
万一软件或硬件发生故障，一个高可用性解决方案保证系统自动恢复。实现高可用性的目的是减少计划停机时间和最小化非计划停机时间。通常，组织机构对高可用性目标有不恰当的预期，他们想要比他们实际愿意支付的更高级别的可用性。在了解实现的总成本之后，许多组织机构需要修改他们的需求。实现一个高可用性解决方案包括、但不限于以下成本：
- 硬件
- 软件
- 网络基础设施
- 培训
- 可服务性
- 操作
如果停机时间接近 0 ，那么高可用性接近 100%。停机时间包括计划内和计划外停机时间。
| 百分比 | 每周停机时间（小时） | 每周停机时间（分钟） | 每年平均停机时间 |
| 90.000% | 10 | 600 | 28080 分钟 |
| 99.000% | 1 | 60 | 3089 分钟 |
| 99.900% | 0.1 | 6 | 526 分钟 |
| 99.990% | 0.01 | 0.6 | 53 分钟 |
| 99.999% | 0 | 0.06 | 5 分钟 |
根据 Gartner Research Note, ID Number: AV-13-9472，停机的原因及其发生概率，列举如下：
| 停机原因 | 概率 |
| 软件故障（非计划的） | 40% |
| 硬件故障（非计划的） | 10% |
| 人为错误（非计划的） | 15% |
| 环境问题（非计划的） | 5% |
| 计划停机时间 | 30% |
从表 2 可以看出，停机原因有两类：计划停机和非计划停机。与环境相关的硬件故障发生的几率最小，而软件故障和计划停机占整个系统停机时间的70%。
基于上述表格以及期望的 99.99% 的高可用性，各个原因的可允许停机时间如表 3 所示：
| 停机原因 | 一年内的停机时间 |
| 软件故障（非计划的） | 21 分钟 |
| 硬件故障（非计划的） | 5 分钟 |
| 人为错误（非计划的） | 8 分钟 |
| 环境问题（非计划的） | 3 分钟 |
| 计划停机 | 16 分钟 |
您可以通过以下步骤最小化硬件故障恢复时间：
- 硬件冗余寻址：硬件冗余包括冗余路由器、服务器、磁盘和电源供应。冗余硬件不仅限于上面正在运行架构的物理设备，还有相关的基础设施，比如电源和冷却装置。
- 提供故障自动检测：为了提供真正的硬件恢复，您需要某种形式的故障自动检测。这通常可以由诸如高可用性 Cluster Multi-Processing (HACMP)、Application Server ND 以及其他高可用性解决方案等软件提供，具体取决于实现平台和解决方案的复杂程度。
- 使用热插拔硬件设备：硬件恢复时间可通过使用磁盘、网卡之类的热插拔硬件设备来达到最小化。
- 为系统物理位置提供一个稳定安全的环境：使用一个稳定安全的系统物理位置可以最小化环境相关问题。例如，服务器是在某人的桌子下发生故障的几率大于在一个安全的位置。
您可以通过以下操作最小化人为错误：
- 提供一个整洁的系统管理界面：对于高可用性的人为错误，一个最大的障碍是缺少整洁的系统管理界面。如果您的支持人员需要通过多个控制台来管理一个流程或检测一个错误条件，人为错误实例将会增多。
- 提供一个整洁的系统操作过程：因发生故障而导致额外停机时间的第二个问题就是缺少一个整洁的系统操作过程，这可能和企业级灾难一样复杂，也可以像为特定应用程序定义一个流程那样简单。无论哪种情况，您需要将这些计划存储在一个便于恢复的地方，这些文件也被称为操作过程文件，通过使用一个定义良好的、整洁的操作过程，您可以最小化计划和非计划停机时间。
提高可用性的其他的一些方法，包括：
- 软件冗余寻址
- 提供软件故障自动检测
- 提供软件服务自动恢复
- 提供特定软件配置
- 特定应用程序设计寻址
对于 Business Events V6.2 和 V7.0，相比最初版本，提供一个高可用性环境的能力已经有了极大的提高。对于 Business Events，IBM 通过开拓本地 Application Server ND 功能提供了一个完整的可审计且可用的解决方案。然而，技术连接器（technology connectors）不能利用这个功能，因此它们不得不依赖另一个方法提供高可用性。
Service Integration Bus（以下称为 SiBus）是一个逻辑实体，是在 WebSphere Application Server 安装之后，通过管理控制台或 wsadmin 脚本语言配置和创建的。您可以使用这两种模式在 Application Server 集群上配置 SiBus，具体取决于部署需求。由于 SiBus 是一个基于消息驱动 bean（message-driven bean，MDB）的物理实现的逻辑实体，所以没有固有的高可用性和工作负载功能。您需要在创建之前单独配置底层物理实现。
本文其余部分将向您展示一个使用 WebSphere MQ 作为外部消息传递总线的高可用 Business Events 基础设施。再一次记住，技术适配器从本质上来说是不能被构建成高可用的。然而它们以一种主动/被动模式运行来为 feeder 应用程序提供更高级别的可用性。Business Events 本质上是不持续的，通常在一段时间以后就是无效的。因此，默认情况下，所有事件本质上都是非持续的，那些经过了故障幸存的事件状态应该被设置为持续的，并在 Business Events 中定义为持久（durable）事件。
当一组应用程序服务器在一个单元中创建时，高可用性集群配置是默认创建的配置。当 SiBus 被创建之后，仅仅在集群服务器其中一个上有一个活动的消息传递引擎，集群成员的所有服务请求都通过这个惟一的消息传递引擎选择路径发送。因此，对于一个有 n 个服务器的集群，只有一个本地消息 put 操作可以使用活动消息传递引擎来指定路线发送服务请求 ，而其他服务器上的（n-1 个）远程消息 put 操作只能使用非活动消息传递引擎。
这种配置的优势是，当一个消息传递引擎发生故障时，另一个服务器变成活动的，所有远程 put 活动通过最新活动的消息传递引擎选择路线发送。也就是说，因为只有一个服务器可以指定路线发送消息到目标服务器，消息序列坚持通过总线。
这种配置的不足之处与性能有关，实际上集群配置中有一个消息传递瓶颈，就是所有服务请求（n-1）是远程 puts 到活动消息传递引擎的。
通过使用 MQ 附带的高可用性服务应用程序，例如 HACMP、Microsoft™ Cluster Service 或者 Veritas Cluster Server，您可以进一步增强馈送 Business Events 引擎 的 MQ 队列管理器以及技术连接器的可用性。
一个服务设置必须包含需要传递高可用服务的所有流程和资源，理想状况下应该是只包含这些流程和资源。推荐您使用队列管理器和 JMS 适配器作为 MQ 故障转移单元。因为 Application Server ND 将使用 Application Server 高可用性来处理应用程序故障转移。因此为了达到最优配置，您应该将每个队列管理器放在一个单独的包中，包括队列管理器使用的共享磁盘，它应该放在专为包预留的卷组中，IP 地址用来连接队列管理器（IP 地址包）和代表队列管理器的应用程序服务器。
用于高可用性集群的队列管理器在共享磁盘上应该有自己的日志和数据，以便在节点故障时可通过一个幸存节点对其进行访问。运行队列管理器的节点必须在内部磁盘上保持一定数量的文件。这些文件包括如 /var/mqm/mqs.ini 这类与所有队列管理器相关的文件以及用于生成内部控制信息的特定管理器文件。因此，与队列管理器相关的文件被分为内部的和共享磁盘的。使用一个共享磁盘即可恢复所有和队列管理器相关的数据（日志和数据）。
图 1 描述了一个典型的 active/passive 配置。在每个消息传递服务器上有一组应用程序代码，由 MQ server、Business Events 的 JMS 适配器和 Application Server 的客户端连接包组成。当出现一个高可用性事件时，这个资源组将故障转移到辅助计算机上，从停止的地方继续进行处理。
图 2 描述了高级业务事件解决方案，由一个 MQ 集群和一个 Business Events 集群组成。Business Events 集群通过利用 JMS 操作和事件点（event points）或者操作队列和事件队列与 MQ 集群通信。这些队列类型的定义都不相同，每个都有限制。图 2 展示了用于事件流的配置。
Business Events 服务器默认的配置是使用订阅点。这些配置有一个本质问题，同越过订阅者向复制事件主题使用订阅的解决方案一样。您可以用一个网关事件引擎来处理这个问题，但这将会导致单点故障或复杂的额外层，这在任何情况下都是不需要的。
连通的第二个方法是使用技术连接器，技术连接器使用在工具中为接触点定义的参数。 通过利用点对点队列，以及通过 MQ 使是事件流负荷从入站边保持平衡，可以确保没有复制事件被 Business Events 接受。
配置 Business Events 的第 3 个方法是使用一个静态队列，该方法的局限之处是在事件服务器上没有分离事件。所有事件都在这一个序列中处理，然后转入一个操作序列，这种配置需要一个外部代理来将操作路由到最终目的地。
此时，您应该意识到任何动态的（in-flight）、非持续的（non-persistent）且非持久的（non-durable ）事件在发生故障时将会丢失。至于上下文数据，应该被持久化到步骤表（steps table），在其失败时可用于 Business Events 节点。这个配置有一个众所周知的局限：就 JMS 技术连接器而言，不允许打开安全性。由于 Technology Connector Framework 中的限制，其他技术连接器在此时也不能提供高可用性。这个问题我们稍后解决。如果某种情况下，您需要使用其他技术连接器的高可用性。建议您使用其他形式的集成总线，例如 WebSphere Message Broker 或 WebSphere Process Server 代替相关的技术连接器。
MQ 集群将为所有入站事件提供负载平衡，JMS 适配器和队列管理器将故障成对转移到可用集群的被动节点。然而使用 MQ 集群将导致上下文事件在 Business Events 服务器集群中多次跳转，因为这些事件是与一个 Business Events 节点关联的。所以您需要预计这类对象的额外延迟。
当您需要一个更加健壮的高可用性环境时，您应该在每个 Application Server 实例中配置一个辅助的闲置容器来过渡故障。当事件被接入 Business Events 引擎时，将出现额外负载平衡，因为这是 Business Events 集群基本功能的一部分。建立步骤表来使用 ObjectGrid 进行复制；这个表应该由 DB2® 或 Oracle® 等数据库备份。对于这种配置，数据将复制到集群中的所有节点。当持久事件被用于失败事件时，上下文数据将被用来从故障点恢复。这些副本在集群中是处于非活动状态，直至事件的上下文相关的节点不再可用，此时，ObjectGrid 为事件分配一个新的上下文句柄，处理工作继续进行，在特定事件集群中任一时刻仅有一个上下文句柄是可用的，这就是导致前面提到的多次跳转的原因。
在您计划高可用性事件基础设施时，要记住只有持久事件在经过故障装转移后才能被保留下来。一旦事件耗尽队列资源时，这些事件将不能回滚。
以下配置为运行在 Application Server ND 集群之下的每个 Business Event 节点建立了一个实例，附带为集群的每个节点建立一对被动机（passive machine）。这种分离允许一个节点接受标准维护，而其他节点继续处理。此外，成对的故障转移节点允许节点和所有的资源（包括 MQ）作为一个单元转移到被动机上。用于传出和传入消息的 MQ 队列被存储在一个通用存储阵列网络中，标准高可用过程可用于故障转移。图 4 显示了一个常用的生产区域平台布局。
注意： 由于事件连接器不能用于此配置中，入站 JMS 流量仅限于一个持久或非持久事件队列。
注意： MQ 安全性不可用，因为技术连接器目前在某种程度上不支持提供高可用性，如果 MQ 和 技术连接器不能将存储在存储阵列网络启动器中的日志和队列成对转移，解决方案消息可能无法传递。下述图表展示了此架构是如何工作的。
以下配置为运行在 Application Server ND 集群之下的每个 Business Event 节点建立了一个实例，附带为集群的每个节点建立一对被动机。这种分离允许一个节点接受标准维护，而其他节点继续处理。当事件出现时，被动机将被启动，处理节点加入 MQ 集群，开始接受事件。这使额外处理过程被执行，根据需要开始或停止实例，允许它加入集群。
上述设计的另一个变体是将 MQ 和技术连接器放在一个高可用性服务器组中，让它们成对故障转移到被动盒（passive box）中。这需要技术连接器配置发布到一个 Business Events 主题上而不是在同一机器上，这也需要 MQ 将其队列和日志放到一个存储阵列网络中，很像产品中展示的首要解决方案。
注意： MQ 安全性不可用，因为目前技术连接器在某种程度上不支持提供高可用性，如果 MQ 和技术连接器不能将存储在存储阵列网络驱动器中的日志和队列成对转移，解决方案消息可能无法传递。
表 4. Business Events 的 WebSphere ND JMS 设置。
| 主题 | 名称 | 变成静态队列 |
| 操作主题 | jms/actionTopic | 可以转变成静态队列 |
| 持久操作主题 | jms/durableActionTopic | 可以转变成静态队列 |
| 持久事件主题 | jms/durableEventTopic | 可以转变成静态队列 |
| 事件主题 | jms/eventTopic | 可以转变成静态队列 |
在 Business Events 管理控制台 JMS 配置对话框中，您可以找到以下队列设置。如表 4 所示，所有这些 JMS 实体既可以是发布-订阅（pub-sub），也可以是静态队列。默认情况下是发布-订阅。如果技术连接器不可用，您将需要手动配置这些 JMS 实体来使用静态队列代替。也要注意，所有消息必须在 Business Events V6.2 模式中，如 WebSphere Business Events V6.2 Information Center 中所描述的。您还被局限于两个输入和两个输出队列，一个是持久的，一个不是持久的。如果想要直接使用这些队列，建议您将 WebSphere Message Broker 或 WebSphere Process Server 放入您的架构中，以便于处理传输和为事件从 Business Events 服务器中传出传入选择路线。
本文讲述了在一个高可用环境中如何通过使用 Application Server 内置的功能利用 Business Events，以及额外设置和配置选项来启动高可用企业事件基础设施。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-672123/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14789789/viewspace-672123/
207
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
