IBM Websphere MQ 6 基础培训入门教程
| WebSphere MQ V6 |
|
| 概述 |
|
|
| WebSphere MQ V6 |
|
| 主题 |
|
“IBM 计划......在 2005 年上半年......发布新版 WMQ。这些发布将使 ESB 创建和扩充变得更容易......”
由于计划推出新版 WMQ，我们尝试把要进行的各项工作分成几个主题。这些是该版本要优先实施的功能，而一个功能应当在实施之前归入一个或多个主题。（记住候选功能太多，总是超过我们在可接受的时间里或用接受的代码可以开发的功能数量。一个版本不能集成的功能可能会集成在下一个版本里。） 我们这次想研究的两个领域是：
我们一直在开展 z/OS 特定的某些活动，完成共享队列工作最后阶段的开发 同时使许多增强功能反映更广泛的行业活动。 后面的幻灯片将详细说明其中的许多项目 |
| WebSphere MQ V6 |
|
| 时间表 |
|
|
| WebSphere MQ V6 |
|
| 初期支持的平台 |
|
虽然某些操作系统的基本要求提高了，但 WMQ V6 支持的平台与 V5.3 基本相同。如要了解每种已测试/支持的操作系统的基本要求详情，浏览
“支持软件”网页定期在新环境通过测试后更新，是发布 WMQ 支持的软件的官方网站。 对于 Linux，你会发现支持环境是特定的分发版本（Red Hat 和 SUSE），而不像 V5.3 那样列出前提条件。这与 IBM SWG 的政策是一致的，使得很容易比较不同的产品，以确保它们均有相同的必需软件。对于 Linux/zSeries，虽然在此平台上 WMQ 是 32 位产品，但我们将只测试 64 位 distros。 在这一系列平台里，不包括对基于 Itanium 的任何操作系统的支持。 |
| WebSphere MQ V6 |
|
| 支持状态 |
|
了解这些日期非常重要！所有客户现在应该使用 V5.3（或 5.3.1 on z/OS）。如使用早期版本（有淘汰产品），他们将得不到支持。我们最终停止销售并支持没有升级到 V5 的某些旧平台版本。 分布式平台的规则变化好一些。 旨在更容易把一组产品集成在一起，使其有合理的使用寿命。 许多较旧的 SupportPacs（cat2 和 cat3）被删除或半隐藏了。所以很容易找到仍然与当前产品相关的支持或“有用”资料。 V5.3 for z/OS 没有支持结束日期；所有客户应该改用 V 5.3.1 。 尚未就 V5.3 的支持结束日期发表声明；结束日期将考虑到客户适当移植到 V6 所需的时间。即使到了正常的支持结束日期，通常还可以购买最多两年的附加支持。 |
| WebSphere MQ V6 |
|
| WMQ 简介 |
|
| 对于使用 Windows 和 Linux 系统的 WMQ 新用户，有两种选择：
这是 WMQ Express V5.3 提供的最新版本 |
| WebSphere MQ V6 |
|
| 文件传输 |
|
|
| WebSphere MQ V6 |
|
| 使 WMQ 更容易配置 |
|
| 基于 Eclipse 的新图形配置工具
代替 WMQ V5.3 for Windows 上的 MMC 管理单元 可以连接并配置所有平台上的 WMQ
可扩展
允许使用 Documented 接口
|
| WebSphere MQ V6 |
|
| 配置工具 |
|
| 我们用类似的工具取代现有的基于 MMC 的图形工具，但建立在 Eclipse (IBM Workbench) 软件包之上。这提高了可移植性，即使初期只有 Windows 和 Linux 支持它，其它平台稍后也可以支持它。 与 MMC 管理单元相比，有许多增强功能，包括：
V6 的所有新功能均可在图形用户界面上使用，还可以管理 V5.3（和较旧的）分布式平台。 由于 Eclipse 插件具有部件化特性，所以 IBM 很容易在不中断其它功能的情况下，通过服务更新给 WMQ 增加新功能。 我们提供在默认情况下定制运行 WMQ 插件的 Workbench，但这些插件可以添加到在同一层面的其它 Workbench。例如当 Message Broker 工具使用 Eclipse 的同一层面时，可以显示一个包含消息流开发屏面的屏面，以及消息流要访问的队列的列表。WMQ 将建立在 Eclipse V3.01 之上。 下一组幻灯片是截屏，说明基本界面与 MMC 视图有多大程度的相似，但它很适合 Eclipse 的外观。一个截屏上突出显示的区域（“过滤器”）提供对稍后详细讨论的功能的访问。但是，它允许在屏面上进行简单选择 — IE 只显示深度大于 10 的队列。这更容易查看正在发生的事情，例如问题确定。 有许多选项，例如可以定制显示栏的顺序，以及保存模式。
|
| WebSphere MQ V6 |
|
| 谁在使用队列管理器？ |
|
V5.2 和 V5.3 增加了显示谁在访问队列的命令。V6 增加了一个可显示谁在访问队列管理器的新命令。它显示与 QSTATUS 类似的信息，以便确定用户 — 通道名称、pid（进程 ID）、tid（线程 ID）、程序名称等。但它还显示如何建立连接，以及正在处理的任何事务的详细信息。可以用 UOW 信息查看哪些应用程序可能有长期运行的 UOW，以及哪些应用程序可能会使日志文件满了。它还显示事务是内部事务还是外部事务，它是否是全局事务的参与者等。 本页的第二个例子说明应用程序打开的队列的列表，以及 MQOPEN 使用了哪些选项。 在分布式平台上，CONN 标记可用于中断与 qmgr 的连接。WMQ 管理员可能没有操作系统权限删除错误应用程序，但可以删除它对 WMQ 的访问。不删除该程序，但停止正在进行的任何访问，来自该程序的任何 API 调用均将获得 CONNECTION_BROKEN。终端连接便于恢复日志文件继续记录事件，并可以正常停止队列管理器。出于技术原因，z/OS 在此阶段可能不实施此项服务，但该平台的其它增强功能（日志分流）可减少长期运行的 UoW 引起的问题。 |
| WebSphere MQ V6 |
|
| 更容易连接应用程序和队列管理器 |
|
| 我们在前面看到了如何显示连接队列管理器的应用程序。此新屏面使你更容易指定自动与队列管理器一起启动（和停止）的应用程序。服务定义便于我们定义程序，并使它们与队列管理器一起启动。它取代 Windows 的“定制服务”屏面。有一些人所共知的服务有特殊定义，例如 listeners 和 command server，但还可以定义其它程序，例如代理 (broker) 或触发 (trigger) 监视器。有属性便于把 stdout/stderr 重定向到文件。 此功能只有分布式平台可用；z/OS 已经在操作系统里集成了此类功能。 |
| WebSphere MQ V6 |
|
| 管理 z/OS — 增加 PCF 命令 |
|
z/OS 增加了 PCF 命令消息支持。因此，很容易编写一个可与分布式和 z/OS 队列管理器协同工作的管理应用程序。这可以缩短产品上市时间，以便支持新功能；并缩短编写内部管理工具所需的时间。创建一个 QALIAS 定义，所以你甚至不需要知道 z/OS 和分布式平台上的命令输入队列名称传统上是不一样的。 PCF 消息扩展了“语言”。z/OS 控制要求新格式。PCF 定义有许多其它扩展，现在允许任意“名称/值”对。 如你愿意，可以继续使用 MQSC 格式进行管理 — 命令服务器将处理两种格式。 在管理 WMQ for z/OS 时，通过新的基于 Eclipse 的 MQ Explorer 使用 PCF 界面。 共享队列可以提高可用性，因为当一个队列管理器或 LPAR 发生故障时，应用程序可以继续处理消息 功能已在 WMQ 的几个版本里分阶段发布了
现在支持大于 63KB 的消息
大于 63KB 的消息正文部分存储在 DB2 里
管理结构容错 此版本完善了 WMQ 的共享队列支持功能。共享队列现在可以用与专用队列相同的方法使用。持续性消息和非持续性消息最大可达 100MB。 队列管理器使用的耦合器 (Coupling Facility) 资源保持不变，即使是大消息，也不把大于 63KB 的消息有效负荷直接存储在 CF 里。相反，我们把“指针”放入 CF，把消息正文存储在 DB2 表里，该表随后供队列管理器共享。 把数据存储在 DB2 里比直接存储在 WMQ 里速度慢，我们发现与专用队列存储器相比，这些大消息的存储速度降低了。对于所有消息都很大的系统设计，建议不要采用这种方法。对于许多只有少量大消息的应用程序，偶尔降低消息存储速度并不重要，尤其是在你可以通过共享队列获得更高可用性（和更好的总体系统设计）的情况下。小消息的处理速度与 V5.3 相同。我们发现与把相同的消息存储在专用队列里相比，大持续性消息的存储速度至少降低 3/4。 系统管理员必须启用大消息
在 WMQ for z/OS 5.3.1 里，队列共享组管理 CF 结构发生故障将导致队列共享组 (QSG) 里所有队列管理器异常中止。因此，我们建议你的 CF 结构采用 CF 双工技术，降低 CF 结构发生故障的可能性。但这会导致有关的性能开销。在 V6 里，我们启用 QSG 里的队列管理器，实现 QSG 管理 CF 结构容错。在检测到此类故障时，每个队列管理器将根据内存里的数据重构自己的管理结构部分。同名队列管理器恢复将被暂停，直到队列管理器重构其管理结构部分，这意味着当发生故障的队列管理器重新启动时，故障队列管理器正在处理的 MQGET 消息和约定处理的 MQPUT 消息可由其它队列管理器处理。其它所有应用程序，包括共享队列应用程序，可以在管理结构部可用的情况下继续处理。
有一组新便于你更动态地调节 z/OS 队列管理器。在某些情况下自动管理资源，即抢先扩展，其中有的资源允许管理员采取措施。在所有情况下，其目的是不需要关闭/重新启动队列管理器。 在 V5.3 里，我们允许分布式平台上的队列增大到 2GB 以上。此时我们正在 z/OS 上进行类型的工作，把页面集增大到 64GB。这将使更多的消息（或更大的消息）可以保存在队列里。 “日志分流”是一种技术，允许把长期运行的工作单元的控制信息复制到日至结尾，使队列管理器在重新启动过程中不需要处理大量日志。这受检查点间隔的控制。长 UoW 可能最终仍然会被取消掉，但这应该可以降低影响。 来自 CSQXPARM 的通道启动程序参数现在可以用 ALTER QMGR 命令控制。因此，在更改值时，不需要重新启动 CHIN。 |
| WebSphere MQ V6 |
|
| 提高分布式平台的可用性 |
|
WMQ 日志文件管理提出了许多要求。尤其是我们想使恢复解决方案设计更容易，特别是灾难恢复解决方案。 因此，可以生成报告，说明需要哪些日志的信息。这始终可以从其它途径获得（在错误日志里输入的命令响应），但现在可以把这些信息从队列管理器“推到”管理工具里。有一个新命令将强制日志提高到一个新水平；这便于你把较早时候的所有日志文件复制到备份（灾难恢复）位置，在那里可以了解 qmgr 的状态。 在不全面启动队列管理器的情况下，如可在主站点访问日志文件，可以把灾难恢复站点配置为动态播放日志文件的原位置的副本。这意味着如果需要全面重新启动，只需要播放“最近的”日志文件。 还有一项要求允许较大和/或较多的日志文件 — 在此版本里，Unix 平台活动日志大小从 4GB 提高到 128GB，Windows 平台提高到 64GB。 |
| WebSphere MQ V6 |
|
| 更多状态 |
|
分布式队列管理器和 z/OS 队列管理器均有此新功能。它扩充了队列和通道的状态信息。 对于队列而言，你现在可以查看队列里哪些消息是最旧的。你还可以查看消息通过队列的平均速度。如平均速度很低，最旧的消息很旧，可能表示一个应用程序在通过 msgid/correlid 执行 get 操作，消息的格式不好，或者消息没有正确标识符。如所有消息在队列里停留的时间均很长，可能表示正在服务的应用程序负荷过重，或者需要多台服务器处理输入信息。 通道也有类似的信息，群集通道可以报告有关的传输队列或子队列。此外还有更详细的状态，不仅限于 RUNNING 和 RETRY 等，可以准确显示通道正在做什么。例如此时正在执行用户退出，还是调用 TCP/IP 名称服务器。 此订单详情的一个重要目的是使收集信息的（性能）开销保持在很低的水平上。例如可能通常不接受涉及到队列扫描的任何东西。所有这些信息均在队列管理器内部使用，也很容易派生出来。 |
| WebSphere MQ V6 |
|
| 命令显示过滤 |
|
MQSC 增加了一个简单 WHERE 子句，限制 DISPLAY 命令返回的数据的数量。只能添加一个属性，但对于问题确定和状态查询而言，这已经足够了。不允许使用 AND/OR 组合。 PCF 命令也可以使用相同的查询，z/OS 现在当然支持此查询。 正如我们在早期版本里看到的那样，图形用户界面上的过滤器选项是通过把它传递到命令服务器实现的。 队列管理器过滤是对资源的有效利用，一个消息返回一个响应，并非所有管理工具都进行过滤。就系统管理而言，这可以减少传输的消息数。 很容易编写可发出这些命令的脚本，它可以反映客户用户里的典型问题，并利用响应执行某些操作，例如强制应用程序与队列管理器断开，重新启动服务器应用程序，或者给网络运营中心生成通知
|
| WebSphere MQ V6 |
|
| 提高 WMQ Clusters 的灵活性 |
|
许多可控制 WMQ Clusters 工作负荷平衡功能的选项。 所有这些选项均源于客户体验和要求，有的客户已经建立了超大型群集。 没有自动负荷动态通知功能，我们不检查机器的工作负荷有多大，但这可以采用定制代码添加。这样做的原因之一是很难一概而论地确定机器是否繁忙。 新增队列属性、队列管理器属性和群集通道属性 在确定循环消息分发的优先级并分配工作负荷时具有更大的灵活性 默认性能不变 更容易建立备用/待机网络，在所有正常队列管理器不可用时只使用这些队列管理器 更容易限制活动出站通道的数量 更容易分配工作负荷，使大服务器获得更多工作负荷 |
| WebSphere MQ V6 |
|
| 新增 Cluster 选项 |
|
|
| WebSphere MQ V6 |
|
| 系统统计 |
|
| 统计信息可用于检查应用程序和队列管理器正在做什么。统计信息可用于记账或容量规划。 此版本通过“PCF 事件消息”给分布式管理员提供 SMF 风格的信息
在此版本里，“事件消息”里有更多可用信息。PCF 语言扩充了，不仅限于 z/OS，同时允许增加更多复杂功能。例如可以把元素组合成子结构，允许 PCF 消息有任意名称/值内存。还有 64 位整数数据类型。 这些新结构是支持几个功能所必需的，包括这一个：与队列管理器和连接应用程序内部活动 SMF 报告相当的功能。正如 SMF 报告一样，你可以查看 qmgr 的统计信息，以及给每个应用程序生成的记账信息。 队列管理器（在移植过程中，如有）自动创建两个新事件队列存储事件消息。 这些信息类似 SMF 生成的信息；我们利用在 z/OS 上获得经验决定哪些准确元素有用。 在应用程序结束时 (MQDISC)，按可配置间隔生成信息。RESET QMGR 命令还有一个选项强制立刻发送统计信息。 示例程序 amqsmon 可用于格式化事件消息，是生成此图表输出的程序。包括源代码。 正如在 z/OS 上一样，一旦生成消息，WMQ 不做与该数据有关的任何事情。假定收集此信息的任何人将购买或编写一个工具收集事件消息，并以某种方式处理这些消息。 |
| WebSphere MQ V6 |
|
| 网络配置检查器 — WMQ 跟踪路径 |
|
|
此功能便于调试 WMQ 网络 对于已经发送的现有消息，它不回答查找问题。但它便于你确定消息可能发到哪里去了。“跟踪程序”消息被发送到网络里，并被放入一个队列里，并在到达最终目的地之前把它经过的所有通道和传输队列报告回去，它在到达最终目的地之后可能会被自动丢弃。 报告生成受 MQMD 里的标志的控制。从理论上讲，任何应用程序都可以打开这些标志，你可以获得网络传输的每个消息的报告，但这样做显然会使系统不堪重负。这主要用于验证配置。 分布式平台提供一个命令 (dspmqrte) 生成消息，它有许多报告配置选项 — 在远端整理在每个中继段生成的独立报告等。由于 dspmqrte 可以作为客户机连接，所以可用它调试源自 z/OS 队列管理器的消息流。 消息格式和报告添加或生成方式可以实现文档化。潜在用途之一是让应用程序把自己的活动信息添加到他们处理的消息里。该体系结构是专门为这一目的而设计的。 |
| WebSphere MQ V6 |
|
| 典型输出 |
|
dspmqrte 命令选项显示生成的输出类型。你可以看到真实设置生成的报告开头，例如前面的图表上的图形。你可以看到消息被放入 QMA 上的远程队列 RQMC 里，它被解析为传输队列 (QMB)。最终阶段表示 MCA 如何接受消息，以及在它到达目标队列之后被如何丢弃掉。 完整报告有更详细的信息，包括正在传输的消息的 MQMD。但此选项显示其中一些要点。 |
| WebSphere MQ V6 |
|
| 标准 — JMS 1.1 和 J2EE |
|
WMQ V5.3 FP06 包括更新版 JMS 类，与当前的 JMS 标准版相匹配。它是希望支持 J2EE 1.4 标准的任何应用服务器必需的工具，但它确实是很有用的东西。 与 JMS 1.02 最大的区别是简化类结构，并统一发布/订阅操作和点对点操作。现在不调用 CreateQueueConnection，你只能执行 CreateConnection 操作。它允许一个事务跨越发布/订阅操作和点对点操作，假定二者都要经过相同对话（用 WMQ 术语来说是通过同一个 hConn），不需要两阶段提交协调器。 在保持较旧的 API 时，现有 JMS 程序的工作保持不变。 WAS6 集成了新的嵌入式消息传递代理，即 WebSphere Platform Messaging，取代了（作为WAS5 一部分的）WMQ V5.3 使用的蹩脚代理。这种新代理（不同于旧代理）可用于连接外部 WMQ 网络。你仍然可以直接把 WMQ JMS 用作替代代理。 WAS 并非 WMQ 正式支持的唯一应用服务器。WebLogic 也在一些平台上测试过，可以支持。 MA 0C Publish/Subscribe SupportPac 现在是基础产品的一部分。这使人们更容易获得代码，尤其是在 V6 的 64 位变革需要另一个 SupportPac 版本的时候。 |
| WebSphere MQ V6 |
|
| 标准 — 基于 WMQ 的 Web 服务 |
|
|
|
| WebSphere MQ V6 |
|
| 标准 — IPv6 |
|
优点太多了，不胜枚举! WMQ 本身需要一点外部更改；主要是确保操作系统正确配置，特别是双协议堆（IPv4 和 IPv6）配置。新的 qmgr 属性定义在两个协议堆都可用的情况下，优先使用哪个协议堆。 注意 Windows 2000 不支持 IPv6 协议堆，如你运行 Windows，必须使用支持 IPv6 的 Windows XP SP1 或 Windows 2003 |
| WebSphere MQ V6 |
|
| SSL 增强 |
|
SSL 处理有少许变化 主要是移植到 Windows 之后，使用 gskit 工具箱，而不是 Microsoft 的 SSL 代理。这样做有许多优点，包括多个平台使用通用管理模式。提供一个工具把证书从 Microsoft 仓库里取出来放入类似的 gskit 仓库。 提供 REFRESH 命令，当证书链发生变化时，例如取代过期证书，不需要重新启动通道程序。下次启动一个通道时，自动重读修改后的仓库。它还刷新用于访问 CRL 的任何高速缓存 LDAP 服务器连接信息。CRL 本身不高速缓存，只高速缓存保存 CRL 的服务器位置。 |
| WebSphere MQ V6 |
|
| 伸缩性和性能 |
|
在此版本里，我们只支持 64 位 AIX、HP-UX (PA-RISC)、Solaris 和 Linux/pSeries 系统。这是因为如使用 64 位内存地址范围，就可以大大缓解队列管理器的限制。最近几年销售的大多数 Unix 机器都能运行 64 位程序。队列管理器有一些内部变化，例如 correlid 索引功能更好，现在可以使用扩充内存了。 现有应用程序的运行保持不变，我们将推出 32 位版本的 libmqm。但出口等某些系统级部件 — 可在 64 位进程里运行的任何东西 — 需要重新编译。这包括 API 出口、通道出口和数据转换出口。与队列管理器的其它程序一样，通道程序将是 64 位进程。 新应用程序可以选择使用 32 位还是 64 位绑定到队列管理器。此类选择很可能要根据 WMQ 范围之外的因素来确定；无论作出何种选择，不大可能影响 WMQ 的性能。在大多数情况下，重新编译的代码不会立刻把性能优势表现出来；如要充分利用大内存，通常需要重新设计应用程序。 |
| WebSphere MQ V6 |
|
| WMQ V6 性能 |
|
提高性能示例 |
| WebSphere MQ V6 |
|
| 移植 — 从 V5.3 删除的功能 |
|
此版本删除了这些功能，右边显示建议的替代产品（如有） |
| WebSphere MQ V6 |
|
| 其它 — z/OS |
|
在 z/OS 上，MQSC 和 PCF 命令可以被报告到事件队列。这便于审计跟踪谁发出了哪个命令。它使用 V5.3 提供的配置更改事件，向队列管理器描述操作更改详情。 内部变化可以更有效地在不同映像上有多个 CICS 区，便于从同一个共享内存读取数据。 SUSPEND/RESUME 支持允许 IMS Bridge 暂停下来发出新请求，并允许返回应答。这适用于共享内存和非共享内存，并提供“节流”机制。 passticket 允许在与一个队列相关的 STGCLASS 定义里指定应用程序名称 — 用于 RACF passticket 检查 ）— 从而提高更大的安全检查粒度 |
| WebSphere MQ V6 |
|
| 其它 — 分布式平台 |
|
分布式平台上的 auth 命令现在可以通过 PCF 命令远程发出。这便于集中管理工具管理 ACL。 OAM 接口扩展同时允许修改定制编写的模块，用户 ID 用于本地绑定应用程序。MQCONNX 增加了用户 ID/口令字段；这些字段被传递到 OAM。注意配备 WMQ 的 OAM 不进行任何验证。但应该有一个例子说明很容易增加验证（OAM 的链接工具便于编写仅验证模块，并保持标准 OAM 用于其它任何地方）。 错误日志过滤便于更容易地在错误日志里查看重大事件：当发生多个类似的事件时，它们将被一个消息所取代，提供类似“上一个消息在 30 秒之内重复出现了 10 次”的说明。尤其是某些启动/停止消息要被过滤掉；在系统发生故障后重新启动队列管理器时，尝试同时重新连接数百个通道，过滤很有用。某些消息可以整个进行压缩处理。 新对象类型 SERVICE 使所有分布式平台可以在队列管理器启动时自动启动应用程序。这取代了 Windows MMC 图形用户界面上的定制服务。z/OS 操作系统有合适的机制可用，不需要此功能。 分布式平台上的通道现在可以把安全控制应用于它们，所以有的人可以启动/停止通道，但不能修改定义。 Java 类更新使管理员更容易设置监视器，不必理会正在使用的客户机。你再也不必了解客户机程序是否是用 Java 编写的。 V6 还具备 FP08 for V5.3 提供的 MA 0C 发布/订阅代理。这意味着你不必下载 V6 64 位平台可能需要的新代码 |
| WebSphere MQ V6 |
|
| 总结 |
|
本演示涵盖的内容不到 WMQ V6 正在实施的约 200 项技术的一半。我挑选了一些最重要的项目。（未提及的某些项目照常提供，或者是在此提及的较大项目的前提条件，但没有其它实际功能。 |