Ich debugge auf einer Site, auf der unsere Anwendung auf einem 3-Knoten-Failovercluster mit einer MSMQ-Clustergruppe für die Nachrichtenwarteschlange ausgeführt wird. Wir sehen, dass das System auf einigen Knotenkombinationen funktioniert, aber nicht auf allen. Daher ist die Failover-Sicherheit nicht so gut wie beabsichtigt.
Das Problem liegt beim Empfangen von Nachrichten aus der Clusterwarteschlange.
Wenn unsere Anwendung auf Clusterknoten B oder C ausgeführt wird, funktioniert sie unabhängig davon, auf welchem Knoten MSMQ ausgeführt wird (funktioniert = unsere Anwendung empfängt Nachrichten). Wenn unsere Anwendung auf Knoten A ausgeführt wird, schlägt sie fehl, da der Nachrichtenwarteschlangendienst nicht verfügbar ist, unabhängig davon, wo MSMQ ausgeführt wird.
Um die Sache noch verwirrender zu machen, habe ich einen kleinen WCF-MQ-Proxy-Dienst mit einem GUI-Client erstellt, der es mir ermöglicht, einen Befehl an den Dienst zu senden, der dann je nach Angabe des Clients Nachrichten an eine Nachrichtenwarteschlange sendet oder von dieser empfängt – und dabei so viel Feedback wie möglich gibt. Das Muster ist bei dieser App dasselbe, außer dass der Knoten, bei dem es fehlschlägt, Knoten C ist – unabhängig davon, wo MSMQ ausgeführt wird.
Hier sind einige der Dinge, die ich überprüft habe:
- Der Dienst (unsere App) läuft auf allen 3 Knoten unter denselben Domänenbenutzerkonten.
- Die App-Konfigurationsdatei enthält denselben Pfad zur Nachrichtenwarteschlange.
- Die Zugriffsrechte für die Warteschlange: Jeder hat die volle Kontrolle.
- Der lokale MSMQ-Dienst wird auf allen Knoten ausgeführt und ich habe sichergestellt, dass die lokalen Warteschlangen nicht dieselben Namen haben wie die gruppierten.
- Die Firewall ist auf allen Knoten deaktiviert.
- Knoten A unterscheidet sich von B und C dadurch, dass er eine zusätzliche Netzwerkverbindung im selben Subnetz wie das Clusternetzwerk hat. Wenn ich ihn also von Knoten B aus anpinge, antwortet er über die „falsche“ Schnittstelle. Ich bin nicht sicher, ob das wichtig ist, aber es ist ein bisschen seltsam.
- Die Serviceoption „Netzwerknamen als Computernamen verwenden“ scheint nichts zu ändern. Mein Proxy-Dienst meldet seinen wahrgenommenen Computernamen und gibt für Knoten A immer den Clustergruppennamen zurück, auf Knoten B und C immer den Knotennamen.
- Die MSMQ-Clustergruppe verwendet zur Speicherung ein gemeinsam genutztes iscsi-Laufwerk.
Da ich nur ein Entwickler und keineswegs ein Experte für Microsoft-Infrastrukturen bin, möchte ich fragen: Welche Schritte werden beim Debuggen einer geclusterten MSMQ-Konfiguration wie dieser empfohlen?
Antwort1
Ok, nachdem ich dies mehrere Wochen lang alleine und zusammen mit dem Message Queue-Supportteam von Microsoft behoben habe, wurde eine Lösung gefunden.
TLDR; die Lösung besteht darin, den Registrierungsschlüssel zu entfernen oder umzubenennen
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\<SERVICENAME>\Environment
Der Grund für den Fehler ist, dass der MQ-Client keinen MQ-Dienst auf dem lokalen System finden kann – und dieser ist für die Kommunikation mit einem Remote-MQ erforderlich – ähnlich wie ein lokaler SMTP-Dienst, der Ihre E-Mails an Remote-Systeme weiterleitet. Das lokale System ist in diesem Fall jedoch nicht der Clusterknoten, sondern die „Clustergruppe“, und auf der Clustergruppe läuft kein MQ-Dienst (da es sich nicht um ein echtes System, sondern nur um einen Alias handelt). Der Grund, warum der MQ-Client nach einem Dienst auf der Clustergruppe sucht, ist, dass das Kontrollkästchen „Netzwerknamen als Computernamen verwenden“ in den Clusterdiensteinstellungen aktiviert wurde. Dadurch wird ein neuer Wert in der Registrierung der Clusterknoten hinzugefügt, der die Umgebung für den Dienst festlegt. Und das eigentliche Problem ist, dass, wenn dieses Kontrollkästchen deaktiviert ist, der Wert nicht aus der Registrierung entfernt wird, wodurch es praktisch unmöglich wird, die Einstellung ordnungsgemäß (über die GUI) zu löschen, nachdem sie einmal festgelegt wurde. Die Lösung besteht also darin, den Wert manuell mit regedit oder regedt zu löschen.