我将为Websphere MQ生产环境准备一个部署规范。与往常一样，我讨厌重新发明轮子，因此提出了一个问题：
在部署和维护Webshpere MQ生产环境时，是否有一篇文章介绍了最佳实践？
这是我的更具体的疑问：
配置版本控制（MQSC，dmpmqcfg等）。
部署新对象（MQSC还是手册说明？）
部署自动化（可能基于dmpmqcfg的差异？）。
部署和版本控制配置变更。
目前，我只是手动创建MQ对象，并对dmpmqcfg的输出进行版本控制。但是，一段时间后会有如此之多的部署无法处理。
最佳答案
这是一个非常广泛的问题，因此我将尝试在主持人删除它之前进行响应。 :-)
答案取决于很多事情，例如是否正在使用MQ集群，实现高可用性和灾难恢复的方法，安全性要求，是否将QMgr配置为专用或共享基础结构等。但是，我有一些模式在几乎所有情况下（包括非生产）都应遵循。这是因为，如果未在Dev中进行测试，并且在Prod中无法正常工作，则监视和安全性之类的东西往往会在部署时被丢弃。
我使用脚本在生产环境中创建我的QMgrs，以确保诸如X.509证书（或CSR）生成之类的基础知识始终根据标准进行，确保存在任何出口或出口Parm文件，以及某些SupportPac可执行文件（例如）出现在q，circular queues等中。它还会检查是否未安装GSKit等负面因素。
我有一个针对所有QMgr运行的基准脚本。该脚本设置DLQ，用于监视代理程序的任何队列，启用所需的事件，设置系统服务，触发监视器，侦听器等。B2B网关QMgr例外，它们完全在一个类中处理并且具有非常特定的配置不在内部网络上使用。
簇。
我有几类具有特定配置要求的QMgr。这些包括群集存储库（其中主存储库和辅助存储库是不同的子类型），服务提供者QMgr和服务使用者QMgr。这些都针对它们运行辅助脚本。
在使用集群的情况下，每个集群都有脚本来加入或挂起QMgr（对我而言，自v7.1以来，这几乎是100％）。
这些建立了QMgr的基础结构。然后，我维护每个应用程序的脚本。因此，例如，如果有一个薪资应用程序，我将拥有名称可能包含/opt/mqm/bin节点（例如PAY）的队列和主题。与此相对应的是，所有PAY.EMPLOYEE.UPDT.REQ.V032.PRD队列的单个脚本。过去也曾经是PAY.**命令的一个，但是现在与对象在同一脚本中。我只有一个版本的脚本，并且保留脚本更改的历史记录。这样，当我需要重新创建QMgr时，我只需为其运行所有脚本。同样，如果需要在另一个QMgr上部署setmqaut对象，只需将脚本复制到该服务器。
在为集群定义对象时，我总是做一个PAY，其中包含所有运行时属性，例如是否在集群中启用了队列。队列在群集中始终被定义为已禁用并用于触发，但是由于我使用DEFINE NOREPLACE重新运行，所以脚本不会更改它在一个月内的任何状态。那些配置而不是运行时的内容（例如描述）将在NOREPLACE之后立即在ALTER中进行处理，并且每次运行脚本时都会对其进行更新。 here上有一篇文章。
最后，我使用的脚本具有自我执行，自我记录的功能。例如，许多人将所有MQSC命令放入脚本中，然后执行以下操作：
runmqsc < payroll.mqsc > payroll.out
这里有很多问题。最主要的是它依赖于操作员知道很多知识并始终正确地执行脚本。例如，假设他忘记捕获输出了？还是覆盖先前的输出？还是没有得到
DEFINE，因为他需要在最后执行STDERR并且不知道重定向那么好？因此，我的脚本都是用
2>&1编写的，可以处理所有输出捕获，并带有时间和日期戳以及ksh，可以将MQSC与OS命令自由混合，等等。所有您需要做的是转到该QMgr的脚本目录和STDERR来构建/重建QMgr。我当然也进行常规配置转储，但是这些转储更多用于运行查询和报告，例如“已定义此通道的QMgr数量以及它们在哪里？”之类的事情。
另外，进行备份时，几乎没有理由在某个时间点备份QMgr。但是，如果需要，请确保先停止QMgr。另外，请认真考虑如何在备份中捕获证书。许多人都擅长锁定证书目录，因此只有
. ./*ksh可以读取它，但是备份通常不受保护。只要您不尝试在Production上还原，许多商店都可以将Production mqm文件还原到您自己的沙箱中。如果包括了QMgr的KDB文件，那么您就丢失了它们。一种替代方法是将证书放在/var/mqm/*或受保护但未使用QMgr的目录备份的其他目录中。关于deployment - Websphere MQ生产部署的良好实践，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14173071/