Estoy depurando en un sitio donde nuestra aplicación se ejecuta en un clúster de conmutación por error de 3 nodos con un grupo de clúster MSMQ para cola de mensajes. Estamos viendo que el sistema funciona en algunas combinaciones de nodos, pero no en todos, por lo que la seguridad de conmutación por error no es tan buena como se esperaba.
El problema está en la recepción de mensajes de la cola agrupada.
Cuando nuestra aplicación se ejecuta en el nodo B o C del clúster, funciona independientemente del nodo en el que se esté ejecutando MSMQ (funciona = nuestra aplicación recibe mensajes). Cuando nuestra aplicación se ejecuta en el nodo A, falla debido a que el servicio de cola de mensajes no está disponible, independientemente de dónde se esté ejecutando MSMQ.
Para confundir aún más las cosas, creé un pequeño servicio proxy WCF-MQ con un cliente GUI, que me permite enviar un comando al servicio, que luego enviará o recibirá desde una cola de mensajes según lo especificado por el cliente, y dar tanta retroalimentación como sea posible en el proceso. El patrón es el mismo con esta aplicación, excepto que el nodo donde falla es el nodo C, independientemente de dónde se esté ejecutando MSMQ.
Estas son algunas de las cosas que he comprobado:
- El servicio (nuestra aplicación) se ejecuta bajo las mismas cuentas de usuario de dominio en los 3 nodos.
- El archivo de configuración de la aplicación contiene la misma ruta a la cola de mensajes.
- Los derechos de acceso a la cola: todos tienen control total.
- El servicio MSMQ local se ejecuta en todos los nodos y me aseguré de que las colas locales no tengan el mismo nombre que las agrupadas.
- El firewall está deshabilitado en todos los nodos.
- El nodo A se diferencia de B y C en que tiene una conexión de red adicional en la misma subred que la red del clúster. Entonces, cuando hago ping desde el nodo B, responde en la interfaz "incorrecta". No estoy seguro si importa, pero es un poco extraño.
- La opción de servicio "Usar nombre de red para nombre de máquina" no parece cambiar nada. Mi servicio de proxy informa el nombre de la máquina percibido y, para el nodo A, siempre devuelve el nombre del grupo del clúster; en los nodos B y C, siempre devuelve el nombre del nodo.
- El grupo de clústeres MSMQ utiliza una unidad iscsi compartida para almacenamiento.
Solo soy un desarrollador, no un experto en infraestructura de Microsoft de ninguna manera, por lo que me gustaría preguntar: ¿cuáles son los pasos recomendados a seguir al depurar una configuración de MSMQ en clúster como esta?
Respuesta1
Bien, después de varias semanas de depurar esto por mi cuenta y junto con el equipo de soporte de Message Queue de Microsoft, se encontró una solución.
TLDR; la solución es eliminar o cambiar el nombre de la clave de registro
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\<SERVICENAME>\Environment
El motivo del error es que el cliente MQ no puede encontrar un servicio MQ en el sistema local, y eso es necesario para comunicarse con un MQ remoto, algo así como un servicio SMTP local que reenvía sus correos electrónicos a sistemas remotos. Sin embargo, el sistema local no es el nodo del clúster en este caso, sino el "grupo de clústeres" y no hay ningún servicio MQ ejecutándose en el grupo de clústeres (porque no es un sistema real, solo un alias). La razón por la que el cliente MQ busca un servicio en el grupo de clústeres es que la casilla de verificación "Usar nombre de red para el nombre de la computadora" estaba marcada en la configuración del servicio de clúster. Esto agrega un nuevo valor en el registro de los nodos del clúster, configurando el entorno para el servicio. Y el verdadero problema es que cuando esta casilla de verificación no está marcada, no elimina el valor del registro, lo que efectivamente hace imposible borrar la configuración correctamente (desde la GUI) una vez que se ha configurado. Entonces la solución es eliminar el valor manualmente con regedit o regedt.