内容


将 WebSphere MQ 队列管理器集群从 WebSphere MQ V6 迁移到 V7

Comments

简介

IBM® WebSphere® V7 引入了许多新特性,其中包括对 WebSphere MQ 队列管理器集群的改进,最引人注目的改进是通过使用集群主题对象支持集群内的发布/订阅。WebSphere MQ 文档解释了如何将单独的队列管理器迁移到 WebSphere MQ V7,但使用集群的系统管理员和架构师需要理解与整体迁移一个集群相关的问题,包括:

  • 减少应用程序中断
  • 衡量和验证迁移成功,并在发生迁移问题时制定向后迁移计划
  • 利用 WebSphere MQ 新特性
  • 在更广泛的 WebSphere MQ 网络和总体系统架构中管理集群迁移

本文展示如何将一个对象管理器集群从 WebSphere MQ V6.0 迁移到 WebSphere MQ V7.0 或 V7.0.1,但相关信息可以应用于任何 WebSphere MQ 版本。本文是文章 将 WebSphere MQ 队列管理器迁移到 WebSphere MQ V6 的更新,后者是寻求从 WebSphere MQ V5.3 迁移到 V6 的建议的好地方。

迁移队列管理器通常是一个非常简单的过程,因为 WebSphere MQ 被设计为自动迁移对象和消息,并支持混合版本集群。但当您计划迁移一个集群时,您需要考虑以下几个问题:

向前迁移

向前迁移指的是将现有队列管理器更新到更新的版本(比如从 WebSphere MQ V6.0 到 WebSphere MQ V7.0),所有平台都支持向前迁移。向前迁移的原因也许是为了利用新特性,或者由于旧版本的服务期限即将到期。

表示集群对象的控制块能够从 WebSphere MQ 的一个版本更改为另一个版本,因此当队列管理器第一次使用新版本启动时,SYSTEM.CLUSTER.REPOSITORY.QUEUE 上的对象通过存储库管理器流程转换。对于 z/OS,这个流程是通道启动器地址空间的一部分,因此,这个转换过程在与队列管理器关联的通道启动器启动时发生。队列管理器向前迁移后,该队列管理器拥有的所有对象和持久消息仍然可用,现有应用程序应该无需重建就可以继续运行。与新版本中的特性相关的对象和属性将设置为默认值,这些默认值能够保证最小的行为变化。

向后迁移

向后迁移是降低现有队列管理器使用的 WebSphere MQ 版本的过程。如果完成向前迁移后遇到问题,就有可能需要执行向后迁移。在非 z/OS 平台上返回低版本的队列管理器时,必须恢复一个备份(当队列管理器在低版本上运行时执行的备份),因此只有存储在该备份中的对象和消息可用。用这种方法返回一个备份后,记得在恢复后的队列管理器上发出一个 REFRESH CLUSTER 命令,以确保队列管理器拥有关于该集群的最新信息。

在 z/OS 上,借助适当的维护,WebSphere MQ 被设计为可以向后迁移对象,因此不需要任何备份(但进行备份仍然是良好的实践)。当 z/OS 通道启动器第一次在低版本(应用了向后迁移 PTF)上启动时,存储库管理器将转换 SYSTEM.CLUSTER.REPOSITORY.QUEUE 上的对象。z/OS 队列管理器向后迁移后,低版本支持的所有对象和属性以及持久消息都将可用。与新版本相关的对象和属性在向后迁移后将丢失,因此在运行新版本较长一段时间后最好不要进行向后迁移。

测试

进行系统更改时,在将更改应用于生产之前,在一个测试或 QA 环境中测试这些更改很重要,特别是在将软件从一个版本迁移到另一个版本的时候。理想情况下,测试环境中使用的迁移计划应该与生产环境中使用的迁移计划一样,以便在测试中最大限度地发现潜在的问题,而不是将那些潜在问题留在生产环境中。但是,在实践中,测试环境和生产环境的架构、配置和工作负载不太可能一致,因此,测试迁移步骤与生产迁移步骤也不太可能完全一致。无论测试和生产的计划和环境是否一致,总是会在迁移生产集群队列管理器时发现问题。下面介绍在迁移场景中减少计划内和计划外中断的技巧。

迁移和回撤计划

制定迁移计划时,需要考虑常见队列管理器迁移问题、集群细节、更广泛的系统架构和更改控制策略。在迁移生产队列管理器之前要测试计划并创建文档。请参见 WebSphere MQ V7 信息中心中的 迁移一个集群队列管理器 以获取一个详细示例。

对迁移过程充满信心的管理员也许希望通过省略挂起和恢复队列管理器的步骤来简化迁移过程。反之,对迁移过程缺乏信心的管理员也许希望在迁移之前将队列管理器从集群中移除。

回撤计划应该在迁移之前制定,它应该包含关于构成成功迁移的因素、触发回撤流程的条件和回撤计划本身的详细信息。回撤流程可能包括从集群移除或挂起队列管理器、向后迁移和在外部问题得到解决之前保持队列管理器离线。

备用目标

应用程序能够利用集群的工作负载平衡特性来减少由队列管理器宕机引起的中断风险。中断可分为计划内(如迁移队列管理器)和计划外(如磁盘故障)两种类型。如果一个队列管理器是一个特定集群队列的惟一宿主,那么停止该队列管理器显然会导致应用程序中断。要避免这种中断,可以在该集群内的另一个队列管理器上定义该队列,这样,当您迁移一个队列管理器时,应用程序就可以使用备用队列。但是如果应用程序与某个特定队列具有亲和性,那么以这种方式使用多个队列也没有用。这种应用程序亲和性有两个常见原因:一是队列以开放绑定方式打开,二是队列管理器名已经在 MQOPEN 调用中指定。当队列管理器发生长时间宕机的风险增加时,不仅需要在常规操作中注意应用程序亲和性问题,在迁移过程中更要注意这个问题。

同步迁移和应用程序宕机

如果没有备用目标可用,则可以通过同步队列管理器迁移和应用程序宕机来减少宕机时间。理想情况下,集群队列管理器在使应用程序重新上线前也将被测试。在一个集群中,可能很难探测远程应用程序是否正在使用本地集群队列,因此可能需要仔细监控队列和通道。

分步迁移

迁移一个集群时,最好进行分步迁移,即每次只迁移一个队列管理器。在迁移集群中的各个队列管理器之间最好间隔几天,以便在所有队列管理器完全在新版本下运行之前测试应用程序。

集群队列管理器的目的是将运行不同版本的队列管理器加入到集群中,这也是分步迁移之所以成为可能的原因。建议首先迁移完整存储库,但这不是必须的。如果所有完整存储库在局部存储库之前迁移,那么所有新版本队列管理器都能利用新特性。低版本队列管理器不能使用新特性,并将出现在新版本队列管理器的存储库中,任何新版本属性均使用默认值。

如果完整存储库没有在局部存储库之前迁移,那么尽管集群可以继续工作,但并不是所有队列管理器都能通过完整存储库使用新特性,其原因在于集群对象在集群中发布的方式(如以下示例所示):

表 1
队列管理器名完整(局部)存储库 集群队列
QM1完整
QM2完整
QM3局部Q1
QM4局部Q1
QM5局部

表 1 显示带有 5 个队列管理器的集群,所有队列管理器都运行在 WebSphere V6.0 上,下面要将 3 个局部存储库(QM3、QM4 和 QM5)迁移到 WebSphere MQ V7。迁移的原因之一是要使用一个称为异步放置(asynchronous put) 的 WebSphere MQ V7.0 新特性,该特性将一个新属性 Default Put Response (DEFPRESP) 添加到队列。要修改上述集群队列上的这个值,在 QM3 和 QM4 上发出以下命令:ALTER QL(Q1) DEFPRESP(ASYNC)。执行这个命令将进行以下更新:

  • QM3 和 QM4 更新完整存储库上的对象描述。
  • 每个完整存储库更新其本地存储库,并将来自 QM3 和 QM4 的原始更新发送到在 Q1 中注册了的队列管理器。
  • QM5 在 Q1 中进行了注册,因为连接到 QM5 的应用程序此前已将消息放置到 Q1 中。

此时,完整存储库持有 QM3 的更改后的集群队列记录,但由于完整存储库运行在 V6 上,该记录是一个 V6 记录,因此不包含 DEFPRESP 属性。

QM5 持有 QM3 的更改后的集群队列记录,由于 QM5 运行在 V7 上,所以该记录包含 DEFPRESP 属性。尽管 QM5 通过低版本完整存储库接收更新后的数据,它还是接收了 V7.0 属性数据。完整存储库能够转发对象更新,因此它们能传播带有它们自身不支持的属性的记录。在 QM5 上执行 DIS QCLUSTER(Q1) DEFPRESP CLUSQMGR 将返回:

QM1 CLWLPRTY(0)
QUEUE(Q1)  TYPE(QCLUSTER) CLUSQMGR(QM3) DEFPRESP(ASYNC)
QUEUE(Q1)  TYPE(QCLUSTER) CLUSQMGR(QM4) DEFPRESP(ASYNC)

这个响应意味着所有局部存储库都能在完整存储库之前更新,并且仍旧能够利用新功能。下面的小节展示为什么应该尽可能先更新完整存储库。假设您添加一个新的 V7.0 队列管理器(QM6)到该集群且一个应用程序连接到它并打开 Q1。此时:

  • QM6 需要询问完整存储库关于 Q1 及其托管位置的信息。
  • 完整存储库将其持有的关于 Q1 的信息以及托管 Q1 的队列管理器(QM3 和 QM4)传递到 QM6。
  • 由于完整存储库只持有 V6.0 记录,因此它们发送给 QM6 的记录不包含 DEFPRESP 属性。这些未知的属性将被 QM6 上的默认值替代。

在 QM6 上执行 DIS QCLUSTER(*) DEFPRESP 现在将返回:

QM1 CLWLPRTY(0)
QUEUE(Q1)  TYPE(QCLUSTER) CLUSQMGR(QM3) DEFPRESP(SYNC)
QUEUE(Q1)  TYPE(QCLUSTER) CLUSQMGR(QM4) DEFPRESP(SYNC)

QM3 的 DEFPRESP 与实际 Q1 对象上的值(5)不匹配。这种不匹配将在 QM3 下一次发布其集群接收器时得以解决,因为那时完整存储库将把对象更新(包括 V7.0 属性数据)从 QM3 直接转发到 QM6 上。由低版本完整存储库(从它们的存储库直接发布)导致的这类不匹配也可能在第一次打开一个队列或在一个局部存储库上发出 REFRESH CLUSTER 命令时发生。

使用 WebSphere MQ V7 新特性

迁移队列管理器后,应该验证现有功能和应用程序。经过这种验证后,您才可以测试新特性,然后在生产环境中使用它们。

WebSphere MQ V7 引入了一种新方法来利用集群发布/订阅消息。当您定义主题对象(在其属性中指定集群名称)时,一个 MQ 集群被指定为一个 “发布/订阅” 集群。在集群中任意位置的给定主题字符串的发布随后流向含有该主题的订阅者的任意其他队列管理器,以便本地交付给应用程序。

如前面的小节 “分步迁移” 所述,使用任何新特性时,最好至少将所有完整存储库升级到 V7。对于发布/订阅,升级将使存储库能够理解和保留某些关于主题对象的信息,否则它们将对这些信息视而不见。显然,任何低版本的局部存储库都不能参与集群发布/订阅。

与常规点对点(队列)集群相比,发布/订阅集群拥有不同的性能和缩放特性。特别是,为了共享订阅信息,所有队列管理器可能需要不时地与发布/订阅集群中的所有其他队列管理器通信(意味着大量活动通道)。因此,重要的是要考虑这些额外的通道可能对您的系统造成的影响,并对您的拓扑结构进行测试,然后才能在一个现有的生产集群中定义主题:

引入集群主题之前的示例集群(箭头表示某些通道是活动的)
发布/订阅集群伸缩性:之前
发布/订阅集群伸缩性:之前
在 QMgr A 上执行 DEFINE TOPIC(SPORTS) TOPICSTR(/sport) CLUSTER(DEMO) 后的同一个集群(所有通道对在一段时间内保持活动状态)
发布/订阅集群伸缩性:之后
发布/订阅集群伸缩性:之后

除 z/OS 之外的其他平台上的 WMQ V6 应用程序可能能够通过队列接口使用发布/订阅(手动构造 RFH1 或 PCF 订阅请求和发布)。这些应用程序在 V7.0 上将继续按照预期的那样运行,并且现在也可以用于 z/OS 队列管理器中。(创建这些较老的应用程序使用的流和主题可能需要一些管理设置。由于这不是一个特定于集群的问题,请您参见信息中心了解更多信息。)如果您希望这些应用程序参与发布/订阅集群,那么其主题可能需要按前面介绍的方式集群化。无论发布/订阅引擎使用的是什么接口,集群中的任意订阅和发布应用程序都可以互操作。

完整存储库可用性

通常,完整存储库队列管理器的可用性很重要,因为所有对象发布(由定义更改或常见的 27 天重新发布周期引起)都通过完整存储库发送。如果没有可用的完整存储库,发布则不能在集群内传播。局部存储库之间的现有集群通道上的流量不受到完整存储库可用性的影响。如果在一次中断期间发生的定义更改很少甚至没有,那么所有完整存储库都不可用也是可以接受的。

在迁移期间,当队列管理器以新版本启动时,它的本地集群对象将被更改,因为它们现在已拥有新特性。这个定义更改导致队列管理器将更改发布到完整存储器。如果完整存储器可用,它们将把那些记录发布到订阅了已更改对象的局部存储器。如果完整存储库不可用,那么其他局部存储库将不会得知对象更改,但是它们仍然拥有已更改对象的现有记录,因此仍可以继续运行。

本文讲解了如何解决在迁移集群队列管理器过程中涉及的一些主要问题。要将这些问题的影响降至最小,重要的是要事前计划和事后测试。对于想要迁移到下一版 WebSphere MQ 的公司来说,WebSphere MQ 对混合版本集群的支持(允许分步迁移)是一个强大的优势。

致谢

笔者谨向 本文上一版 的作者 Ian Vanstone 致谢,感谢 Ian 及其同事 Andrew Banks 和 Jason Edmeades 对本文进行审阅。


相关主题


评论

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=464046
ArticleTitle=将 WebSphere MQ 队列管理器集群从 WebSphere MQ V6 迁移到 V7
publish-date=01252010