I messaggi MSMQ associati all'istanza MSMQ cluster si bloccano nelle code in uscita

Question

Abbiamo MSMQ in cluster per un set di servizi NServiceBus e tutto funziona alla perfezione finché non lo è. Le code in uscita su un server iniziano a riempirsi e molto presto l'intero sistema è bloccato.

Maggiori dettagli:

Abbiamo un MSMQ cluster tra i server N1 e N2. Altre risorse in cluster sono solo servizi che operano direttamente sulle code in cluster come distributori locali, cioè NServiceBus.

Tutti i processi di lavoro vivono su server separati, Services3 e Services4.

Per coloro che non hanno familiarità con NServiceBus, il lavoro viene inserito in una coda di lavoro in cluster gestita dal distributore. Le app Worker su Service3 e Services4 inviano messaggi "I'm Ready for Work" a una coda di controllo cluster gestita dallo stesso distributore e il distributore risponde inviando un'unità di lavoro alla coda di input del processo worker.

A un certo punto, questo processo può essere completamente bloccato. Ecco una foto delle code in uscita nell'istanza MSMQ cluster quando il sistema è bloccato:

Se fallisco sopra il cluster all'altro nodo, è come tutto il sistema ottiene un calcio nel sedere . Ecco una foto della stessa istanza cluster MSMQ poco dopo un failover:

qualcuno può spiegare questo comportamento, e che cosa posso fare per evitarlo, per mantenere il sistema in esecuzione senza problemi?

Answer 1

Più di un anno dopo, sembra che il nostro problema è stato risolto. I takeaway chiave sembrano essere:

• Assicurarsi di disporre di un sistema DNS solido in modo che quando MSMQ deve risolvere un host, è possibile.
• Creare solo un'istanza cluster di MSMQ su un cluster di failover di Windows.

Quando abbiamo fondato la nostra cluster di failover di Windows, abbiamo fatto l'ipotesi che sarebbe stato male alle risorse "rifiuto" sul nodo inattivo, e così, avendo due cluster quasi legati NServiceBus, al momento, abbiamo fatto un'istanza MSMQ in cluster per Project1 e un'altra istanza MSMQ in cluster per Project2. Il più delle volte, pensavamo, li avremmo eseguiti su nodi separati, e durante la manutenzione windows avrebbero co-localizzato sullo stesso nodo. Dopotutto, questa era la configurazione che abbiamo per le nostre istanze primarie e dev di SQL Server 2008, e che ha funzionato abbastanza bene.

A un certo punto ho iniziato a dubitare di questo approccio, soprattutto perché il failover su ciascuna istanza MSMQ una volta o due sembrava avere sempre i messaggi in movimento di nuovo.

Ho chiesto a Udi Dahan (autore di NServiceBus) di questa strategia di hosting in cluster, e mi ha dato un'espressione perplessa e ha chiesto "Perché vorresti fare qualcosa del genere?" In realtà, il Distributore è molto leggero, quindi non c'è davvero molto motivo per distribuirli equamente tra i nodi disponibili.

Successivamente, abbiamo deciso di prendere tutto ciò che avevamo appreso e recreate a new Failover Cluster with only one MSMQ instance. Da allora non abbiamo visto il problema. Naturalmente, accertarsi che questo problema sia risolto si dimostrerebbe negativo e quindi impossibile. Non è stato un problema per almeno 6 mesi, ma chissà, suppongo che potrebbe fallire domani! Speriamo di no.

Answer 2

Come sono stati configurati gli endpoint per mantenere le proprie sottoscrizioni?

Cosa succede se uno (o più) del servizio riscontra un errore e viene riavviato dal Failoverclustermanager? In questo caso, questo servizio non riceverebbe mai più il messaggio "I'm Ready for Work" dagli altri servizi.

Quando si esegue il failover sull'altro nodo, suppongo che tutti i servizi inviino nuovamente questi messaggi e, di conseguenza, tutto funzioni nuovamente.

Per verificare questo comportamento, attenersi alla seguente procedura.

1. Arrestare e riavviare tutti i servizi.
2. Interrompere solo uno dei servizi.
3. Riavviare il servizio arrestato.
4. Se il sistema non si blocca, ripetere questo con ogni singolo servizio.

Se il sistema si blocca nuovamente, controllare le configurazioni. In questo scenario, almeno uno, se non tutti, i servizi perdono le sottoscrizioni tra riavvii. Se non lo hai già fatto, continua l'iscrizione in un database.

Answer 3

Forse i server sono stati clonati e quindi condividono lo stesso ID gestore code (QMId).

MSMQ utilizza il QMId come hash per memorizzare nella cache l'indirizzo di macchine remote.Se più di una macchina ha lo stesso QMId nella tua rete potresti finire con messaggi bloccati o mancanti.

Partenza la spiegazione e la soluzione in questo post del blog: http://blogs.msdn.com/b/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx