Deployment Websphere MQ生产部署的良好实践

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

以下是我更具体的疑问：

• 配置版本控制（MQSC、dmpmqcfg等）
• 部署新对象（MQSC或手动说明？）
• 部署自动化（可能基于dmpmqcfg的差异？）
• 部署和版本控制配置更改

---

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

这是一个非常广泛的问题，所以我将尝试在主持人删除它之前作出回应。：-）

答案取决于许多因素，如MQ群集是否在使用、高可用性和灾难恢复的方法、安全要求、QMGR是配置为专用基础架构还是共享基础架构等。然而，我在几乎所有情况下都遵循一些模式，包括非生产性。这是因为，如果没有在Dev中进行测试，并且在Prod中无法按预期工作，那么监控和安全性之类的东西往往会在部署时被删除

• 我使用脚本在生产中创建QMGR，以确保生成X.509证书（或CSR）等基本操作始终按照标准进行，存在任何出口或出口parm文件，某些SupportPac可执行文件（如

  q

  ）存在于

  /opt/mqm/bin

  中，它还检查消极因素，如GSKit未安装
• 我有一个针对所有QMGR运行的基线脚本。此脚本设置DLQ、监控代理的任何队列、根据需要启用事件、设置系统服务、触发监控器、侦听器等。例外情况是B2B网关QMGR，它们在一个类中处理，并且具有内部网络上未使用的非常特定的配置。 集群
• 我有几个具有特定配置要求的QMgr类。这些包括集群存储库（其中主存储库和次存储库是不同的子类型）、服务提供者QMGR和服务使用者QMGR。这些都有针对它们运行的辅助脚本
• 在使用集群的情况下，我有每个集群的脚本来加入或挂起QMgr（从v7.1开始，这几乎是100%）

这些设置了QMgr的基础结构。然后我为每个应用程序维护脚本。因此，例如，如果有一个工资单应用程序，我将有队列和可能的主题，其名称包含

PAY

节点，例如

PAY.EMPLOYEE.UPDT.REQ.V032.PRD

。与此对应的是一个脚本，用于所有

PAY.*

队列。以前也是用于

setmqaut

命令的，但现在它们与对象位于同一脚本中。我只有一个版本的脚本，并保留脚本更改的历史记录。这样，当我需要重新创建QMgr时，我只需运行它的所有脚本。类似地，如果我需要在另一个QMgr上部署

PAY

对象，我只需将脚本复制到该服务器

为集群定义对象时，我总是执行

DEFINE NOREPLACE

，其中包含所有运行时属性，例如集群中是否启用队列。队列在集群中总是被定义为禁用并用于触发，但因为我使用了

NOREPLACE

重新运行脚本不会改变它在（比如）一个月内的任何状态。在

DEFINE

之后，将立即在

ALTER

中处理那些属于配置而非运行时的内容，例如描述，并在每次运行脚本时更新这些内容。有一篇关于这个的文章

最后，我使用的脚本是自执行、自文档化的。例如，许多人将所有MQSC命令放入脚本中，然后执行以下操作：

runmqsc < payroll.mqsc > payroll.out

runmqscpayroll.out

这里有很多问题。最主要的一点是，它依赖于操作员了解很多，并始终正确地执行脚本。例如，假设他忘记捕获输出？还是覆盖以前的输出？或者因为他需要在最后做

2>&1

而不知道重定向，所以没有得到

STDERR

因此，我的脚本都是用

ksh

编写的，处理所有输出捕获，包括时间和日期戳和

STDERR

，可以自由地将MQSC与OS命令混合使用，等等。您所做的就是转到该QMgr和

的脚本目录/*ksh

以生成/重建QMgr

当然，我也会定期进行配置转储，但这些转储更多用于运行查询和报告，比如“定义了多少QMGR，它们在哪里？”之类的内容

---

此外，在进行备份时，几乎没有任何理由在某个时间点备份QMgr。但是，如果需要，请确保首先停止QMgr。另外，在备份中捕获证书时要仔细考虑。许多人擅长锁定证书目录，因此只有

mqm

可以读取它，但备份通常不受保护。只要您不想在生产上进行恢复，许多商店都允许您将生产文件恢复到自己的沙箱中。如果包含QMgr的KDB文件，那么您就丢失了它们。另一种方法是将证书放在

/etc

或其他受保护但未与QMgr目录备份的目录中。

您的生产环境是什么？您将部署什么（您将创建哪些MQ对象）？