Спустя год кажется, что наша проблема решена.Основные выводы выглядят следующим образом:
- Убедитесь, что у вас есть надежная система DNS, поэтому, когда MSMQ необходимо разрешить хост, он может.
- Создать только один кластеризованный экземпляр MSMQ вотказоустойчивый кластер Windows.
Когда мы настраивали отказоустойчивый кластер Windows, мы предполагали, что было бы плохо «тратить» ресурсы на неактивном узле, и, таким образом, имея два квази-связанныхКластеры NServiceBus в то время, мы создали кластеризованный экземпляр MSMQ для Project1 и еще один кластеризованный экземпляр MSMQ для Project2.Мы полагали, что большую часть времени мы будем запускать их на отдельных узлах, а во время обслуживания окна будут располагаться на одном узле.В конце концов, это была установка, которую мы создали для наших первичных и разработанных экземпляров SQL Server 2008, и это работало довольно хорошо.
В какой-то момент я начал сомневаться в этом подходе, особенно после перехода на другой ресурс.каждый экземпляр MSMQ один или два раза, казалось, всегда заставлял сообщения двигаться снова.
Я спросил Уди Дахана (автор NServiceBus) об этой стратегии кластерного хостинга, и он дал мне озадаченное выражение и спросил"Почему вы хотите сделать что-то подобное?"На самом деле, Дистрибьютор очень легкий, поэтому нет особой причины равномерно распределять их среди доступных узлов.
После этого мы решили взять все, что узнали, и воссоздать новыйОтказоустойчивый кластер только с одним экземпляром MSMQ .Мы не видели проблему с тех пор.Конечно, убедиться, что эта проблема решена, было бы отрицательно и, следовательно, невозможно.Это не было проблемой в течение по крайней мере 6 месяцев, но кто знает, я полагаю, что это может закончиться завтра!Будем надеяться, что нет.