绑定到群集MSMQ实例的MSMQ消息卡在传出队列中

Question

我们已经为一组NServiceBus服务聚集了MSMQ,一切都运行良好,直到它没有.一台服务器上的传出队列开始填满,很快整个系统都挂起了.

更多细节:

我们在服务器N1和N2之间有一个集群MSMQ.其他群集资源只是作为本地(即NServiceBus分发服务器)直接在群集队列上运行的服务.

所有工作进程都位于不同的服务器上,即Services3和Services4.

对于那些不熟悉NServiceBus的人来说,工作会进入由经销商管理的集群工作队列.Service3和Services4上的工作程序应用程序将"我准备工作"消息发送到由同一分发服务器管理的集群控制队列,并且分发服务器通过将一个工作单元发送到工作进程的输入队列来响应.

在某些时候,这个过程可以完全挂起.下面是系统挂起时集群MSMQ实例上的传出队列的图片:

如果我将群集故障转移到另一个节点,就像整个系统在裤子中得到了一些好处.以下是故障转移后不久的同一群集MSMQ实例的图片:

任何人都可以解释这种行为,以及我可以做些什么来避免它,以保持系统平稳运行？

Answer 1

一年多过去了，我们的问题似乎已经解决了。关键要点似乎是：

• 确保您拥有可靠的 DNS 系统，以便当 MSMQ 需要解析主机时它可以。
• 仅在 Windows 故障转移群集上创建一个 MSMQ 群集实例。

当我们设置Windows故障转移集群时，我们假设在非活动节点上“浪费”资源是不好的，因此，当时有两个准相关的NServiceBus集群，我们为Project1创建了一个集群MSMQ实例，以及 Project2 的另一个群集 MSMQ 实例。我们认为，大多数时候，我们会在单独的节点上运行它们，并且在维护时段期间它们会共同位于同一节点上。毕竟，这是我们为 SQL Server 2008 的主实例和开发实例所采用的设置，而且一直运行良好。

在某些时候，我开始对这种方法产生怀疑，特别是因为对每个 MSMQ 实例进行一次或两次故障似乎总是能让消息再次移动。

我向Udi Dahan（NServiceBus 的作者）询问这种集群托管策略，他一脸困惑地问我：“你为什么要做这样的事情？” 实际上，分发器非常轻量，因此实际上没有太多理由将它们均匀地分布在可用节点之间。

之后，我们决定利用我们所学到的一切，重新创建一个仅包含一个 MSMQ 实例的新故障转移集群。从那以后我们就没有看到这个问题了。当然，确保这个问题得到解决将被证明是消极的，因此是不可能的。至少 6 个月以来，这都不是问题，但谁知道呢，我想明天可能就会失败！我们希望不会。