Les messages MSMQ liés à l'instance MSMQ en cluster sont bloqués dans les files d'attente sortantes

Question

Nous avons mis en cluster MSMQ pour un ensemble de services NServiceBus et tout fonctionne parfaitement jusqu'à ce que ce ne soit pas le cas. Les files d'attente sortantes sur un serveur commencent à se remplir, et bientôt tout le système est bloqué.

Plus de détails:

Nous avons un MSMQ en cluster entre les serveurs N1 et N2. Les autres ressources en cluster sont uniquement des services qui fonctionnent directement sur les files d'attente en cluster en tant que distributeurs locaux, c'est-à-dire NServiceBus.

Tous les processus de travail se déroulent sur des serveurs distincts, Services3 et Services4.

Pour ceux qui ne connaissent pas NServiceBus, le travail est effectué dans une file d'attente de travail en cluster gérée par le distributeur. Les applications de travail sur Service3 et Services4 envoient des messages «Je suis prêt pour le travail» à une file d'attente de contrôle en cluster gérée par le même distributeur et le distributeur répond en envoyant une unité de travail à la file d'attente du processus de travail.

À un certain point, ce processus peut être complètement bloqué. Voici une image des files d'attente sortantes sur l'instance MSMQ cluster lorsque le système est bloqué:

Si je ne sur le cluster à l'autre nœud, il est comme tout le système obtient un coup de pied dans le pantalon . Voici une image de la même instance en cluster MSMQ peu de temps après un basculement:

Quelqu'un peut-il expliquer ce comportement, et ce que je peux faire pour l'éviter, pour maintenir le système fonctionne bien?

Answer 1

Au cours d'une année, il semble plus tard que notre problème a été résolu. Les principaux points à retenir semblent être:

• Assurez-vous d'avoir un système DNS solide, alors lorsque MSMQ doit résoudre un hôte, il le peut.
• Créez uniquement une instance cluster de MSMQ sur un cluster de basculement Windows.

Lorsque nous avons créé notre cluster de basculement Windows, nous avons fait l'hypothèse que ce serait mauvais aux ressources « déchets » sur le nœud inactif, et donc, ayant deux groupes NServiceBus quasi liés à l'époque, nous avons fait une instance MSMQ en cluster pour Project1 et une autre instance MSMQ en cluster pour Project2. La plupart du temps, nous avons pensé, nous les exécuterions sur des nœuds séparés, et pendant les fenêtres de maintenance, ils seraient co-localiser sur le même nœud. Après tout, c'était la configuration que nous avons pour nos instances principales et de développement de SQL Server 2008, et cela a fonctionné très bien.

À un certain moment, j'ai commencé à se développer des doutes sur cette approche, d'autant plus que failover chaque instance MSMQ une ou deux fois pour obtenir semblait toujours le déplacement des messages à nouveau.

J'ai demandé à Udi Dahan (auteur de NServiceBus) à propos de cette stratégie d'hébergement en cluster, et il m'a donné une expression perplexe et m'a demandé "Pourquoi voudriez-vous faire quelque chose comme ça?" En réalité, le Distributeur est très léger, il n'y a donc pas vraiment de raison de les répartir équitablement entre les nœuds disponibles.

Après cela, nous avons décidé de prendre tout ce que nous avions appris et recreate a new Failover Cluster with only one MSMQ instance. Nous n'avons pas vu le problème depuis. Bien sûr, faire en sorte que ce problème soit résolu serait négatif et donc impossible. Ça n'a pas été un problème depuis au moins 6 mois, mais qui sait, je suppose que ça pourrait échouer demain! Espérons que non.

Answer 2

Comment vos terminaux sont-ils configurés pour conserver leurs abonnements?

Que se passe-t-il si un (ou plusieurs) de votre service rencontre une erreur et est redémarré par le gestionnaire Failovercluster? Dans ce cas, ce service ne recevra plus jamais le message "Je suis prêt pour le travail" des autres services.

Lorsque vous basculez vers l'autre nœud, je suppose que tous vos services envoient à nouveau ces messages et, par conséquent, tout fonctionne de nouveau.

Pour tester ce comportement, procédez comme suit. Arrêtez et redémarrez tous vos services.

2. Arrête uniquement l'un des services.
3. Redémarrez le service arrêté.
4. Si votre système ne se bloque pas, répétez l'opération avec chaque service.

Si votre système se bloque à nouveau, vérifiez vos configurations. Dans ce scénario, au moins un de vos services, sinon tous, perd les abonnements entre les redémarrages. Si vous ne l'avez pas déjà fait, maintenez l'abonnement dans une base de données.

Answer 3

Peut-être que vos serveurs ont été clonés et partagent donc le même ID de gestionnaire de files d'attente (QMId).

MSMQ utilise le QMId comme un hachage pour mettre en cache l'adresse des machines distantes.Si plus d'une machine a le même QMId sur votre réseau, vous risquez de recevoir des messages bloqués ou manquants.

Découvrez l'explication et la solution dans ce blog: http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx