Websphere MQ产品部署的良好实践

Question

我即将为Websphere MQ生产环境准备一个部署规范。和往常一样，我讨厌重新发明轮子，因此出现了一个问题:在部署和维护Webshpere生产环境时，是否有一篇文章专门介绍了最佳实践？

以下是我的一些更具体的疑问：

• 配置版本控制(MQSC、dmpmqcfg等)。
• 部署新对象(MQSC或手动指令？)
• 部署自动化(可能基于dmpmqcfg?)的差异。
• 部署和版本控制配置更改。

目前，我只是手动创建MQ对象，并对dmpmqcfg的输出进行版本控制。但是，在一段时间内，会有太多的部署来处理这个问题。

Answer 1

这是一个非常宽泛的问题，所以在版主删除之前，我会试着回答。:-)

答案取决于许多因素，如MQ集群是否正在使用、高可用性和灾难恢复的方法、安全性需求、QMgrs是否配置为专用或共享基础设施等。然而，在几乎所有的情况下，包括非生产，我都遵循一些模式。这是因为，如果没有在Dev中进行测试，监视和安全之类的事情往往会在部署时被丢弃，而在Prod中则不会像预期的那样工作。

• 我使用脚本在生产中创建QMgrs，以确保生成X.509证书(或CSR)之类的基本操作始终按照标准进行，确保存在任何退出或退出parm文件，确保/opt/mqm/bin、循环队列等中存在某些SupportPac可执行文件(如q)。它还检查没有安装GSKit等负面因素。
• 我有一个对所有QMgrs运行的基线脚本。这个脚本设置DLQ，用于监视代理的任何队列，根据需要启用事件，设置系统服务，触发监视器，侦听器等。B2B网关QMgrs是一个例外，它是在一个类中自己处理的，并且内部网络上没有使用非常具体的配置。集群。
• 我有几个具有特定配置要求的QMgr类。其中包括集群存储库(主存储库和辅助存储库是不同的子类型)、服务提供者QMgrs和服务使用者QMgrs。它们都有针对它们运行的辅助脚本。
• 在使用集群的情况下，每个集群都有加入或挂起QMgr的脚本(对于我来说，从v7.1开始几乎是100% )。

它们建立了QMgr的基础设施。然后，我为每个应用程序维护脚本。因此，例如，如果有一个工资应用程序，我将有队列，可能还有包含PAY节点(如PAY.EMPLOYEE.UPDT.REQ.V032.PRD )的名称的主题。与此相对应的是所有PAY.**队列的一个脚本。过去也是用于setmqaut命令的命令，但现在这些命令与对象在同一个脚本中。我只有一个版本的脚本，并在脚本中保存了更改的历史。这样，当我需要重新创建一个QMgr时，我只需运行它的所有脚本。类似地，如果我需要将PAY对象部署到另一个QMgr上，我只需将脚本复制到该服务器。

在为集群定义对象时，我总是执行一个包含所有运行时属性的DEFINE NOREPLACE，例如是否在集群中启用了队列。队列在集群中总是被定义为禁用并用于触发，但是由于我使用NOREPLACE，重新运行脚本不会改变它在一个月内所处的状态。那些是配置而不是运行时的事情，如描述，在ALTER中立即在DEFINE之后处理，并且每次运行脚本时都会更新这些内容。这个这里上有一篇文章。

最后，我使用的脚本是自动执行的、自记录的各种脚本。例如，许多人将所有MQSC命令放入脚本中，然后执行如下操作：

runmqsc < payroll.mqsc > payroll.out

这里有很多问题。主要的一点是，它依赖于操作符知道很多信息，并始终正确地执行脚本。例如，假设他忘记捕获输出？还是覆盖以前的输出？或者没有得到STDERR，因为他需要在最后做2>&1，而不知道重定向吗？

因此，我的脚本都是用ksh编写的，处理所有的输出捕获，完成时间和日期的加盖和STDERR，可以自由地将MQSC与OS命令混合，等等。您所做的只是转到脚本目录，以便该QMgr和. ./*ksh构建/重建一个QMgr。

当然，我也会使用常规的配置转储，但是更多的是用于运行查询和报告，比如“有多少QMgrs定义了这个通道，它们在哪里？”就像一件事。

而且，当进行备份时，几乎从来没有一个好的理由在某个时间点备份QMgr。但是，如果需要，请确保首先停止QMgr。另外，要考虑在备份中捕获证书的问题。许多人对锁定证书目录很在行，所以只有mqm才能读取它，但是备份通常是不受保护的。只要您不尝试在生产之上进行恢复，许多商店就允许您将生产/var/mqm/*文件还原到您自己的沙箱中。如果QMgr的KDB文件包括在内，您就会丢失它们。另一种方法是将证书放在/etc或其他受保护但不被QMgr目录备份的目录中。