메시지 큐잉을 위한 MSMQ 클러스터 그룹이 있는 3노드 장애 조치 클러스터에서 우리 응용 프로그램이 실행되는 사이트에서 디버깅 중입니다. 우리는 시스템이 일부 노드 조합에서 작동하지만 전부는 아니므로 장애 복구 보안이 의도한 것만큼 좋지 않다는 것을 확인했습니다.
문제는 클러스터된 대기열에서 메시지를 수신하는 데 있습니다.
응용 프로그램이 클러스터 노드 B 또는 C에서 실행될 때 MSMQ가 실행 중인 노드에 관계없이 작동합니다(작동 = 응용 프로그램이 메시지를 수신함). 우리 응용 프로그램이 노드 A에서 실행되면 MSMQ가 실행되는 위치에 관계없이 메시지 대기열 서비스를 사용할 수 없기 때문에 실패합니다.
더 혼란스럽게 만들기 위해 GUI 클라이언트를 사용하여 작은 WCF-MQ-프록시 서비스를 만들었습니다. 이를 통해 서비스에 명령을 보낼 수 있습니다. 그러면 클라이언트가 지정한 대로 메시지 대기열과 주고받을 수 있습니다. 그 과정에서 최대한 많은 피드백을 주세요. MSMQ가 실행되는 위치에 관계없이 실패한 노드가 노드 C라는 점을 제외하면 패턴은 이 앱과 동일합니다.
제가 확인한 사항은 다음과 같습니다.
- 서비스(우리 앱)는 3개 노드 모두에서 동일한 도메인 사용자 계정으로 실행됩니다.
- 앱 구성 파일에는 메시지 대기열에 대한 동일한 경로가 포함되어 있습니다.
- 대기열 액세스 권한: 모든 사람이 모든 권한을 갖습니다.
- 로컬 MSMQ 서비스는 모든 노드에서 실행되고 있으며 로컬 큐의 이름이 클러스터된 큐와 동일하지 않은지 확인했습니다.
- 모든 노드에서 방화벽이 비활성화되어 있습니다.
- 노드 A는 클러스터 네트워크와 동일한 서브넷에 추가 네트워크 연결이 있다는 점에서 B 및 C와 다릅니다. 따라서 노드 B에서 ping을 실행하면 "잘못된" 인터페이스에서 응답합니다. 중요한지는 확실하지 않지만 조금 이상합니다.
- "시스템 이름에 네트워크 이름 사용" 서비스 옵션은 아무 것도 변경되지 않는 것 같습니다. 내 프록시 서비스는 인식된 컴퓨터 이름을 보고하고 노드 A의 경우 항상 클러스터 그룹 이름을 반환하고 노드 B와 C에서는 항상 노드 이름을 반환합니다.
- MSMQ 클러스터 그룹은 저장을 위해 공유 iscsi 드라이브를 사용합니다.
저는 Microsoft 인프라 전문가가 아닌 개발자일 뿐입니다. 따라서 이와 같은 클러스터형 MSMQ 설정을 디버깅할 때 취해야 할 권장 단계는 무엇입니까?
답변1
좋습니다. 몇 주 동안 혼자서 그리고 Microsoft의 Message Queue 지원 팀과 함께 이 문제를 디버깅한 후에 해결책을 찾았습니다.
TLDR; 해결책은 레지스트리 키를 제거하거나 이름을 바꾸는 것입니다
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\<SERVICENAME>\Environment
오류가 발생하는 이유는 MQ 클라이언트가 로컬 시스템에서 MQ 서비스를 찾을 수 없기 때문입니다. 이는 원격 MQ와 통신하는 데 필요하며 이메일을 원격 시스템에 전달하는 로컬 SMTP 서비스와 비슷합니다. 그러나 이 경우 로컬 시스템은 클러스터 노드가 아니라 "클러스터 그룹"이며 클러스터 그룹에서 실행되는 MQ 서비스가 없습니다(실제 시스템이 아니고 별칭일 뿐이므로). MQ 클라이언트가 클러스터 그룹에서 서비스를 찾는 이유는 클러스터 서비스 설정에서 "컴퓨터 이름에 네트워크 이름 사용" 확인란이 선택되어 있기 때문입니다. 그러면 클러스터 노드의 레지스트리에 새 값이 추가되어 서비스 환경이 설정됩니다. 그리고 실제 문제는 이 확인란을 선택 해제하면 레지스트리에서 값이 제거되지 않아 설정이 설정된 후 (GUI에서) 제대로 설정을 지울 수 없게 된다는 것입니다. 따라서 해결 방법은 regedit 또는 regedt를 사용하여 수동으로 값을 삭제하는 것입니다.