3343을 통해 통신하지 못하는 장애 조치 클러스터에 노드 추가

3343을 통해 통신하지 못하는 장애 조치 클러스터에 노드 추가

파일 감시 기능이 있는 기존 Windows 2012 2 노드 클러스터가 있지만 이를 2019 서버로 교체하고 있습니다. 따라서 기존 클러스터 개체를 재사용할 수 있습니다. 클러스터에 2019 서버를 추가한 다음 클러스터 데이터베이스가 동기화되면 2012 서버를 삭제합니다. 유효성 검사 테스트에서는 네트워크 통신 유효성 검사의 "단 하나의 네트워크 인터페이스 쌍" 경고, CSV 설정 유효성 검사의 "비밀번호가 비밀번호 정책 요구 사항을 충족하지 않습니다" 경고, 새 서버가 동일한 OU에 없음을 포함하여 몇 가지 경고만 표시합니다. 이전 서버(서버 OS 버전 2012와 2019로 그룹화됨)와 같이 "클러스터 속성 "ClusterLogSize"는 기본값인 1536보다 작은 값으로 설정되어 있습니다." 그리고 "다르지만 호환 가능하며 작동하는 시스템 버전' 경고. 따라서 클러스터에 노드를 추가하는 데 방해가 되는 것은 없습니다.

"노드가 클러스터의 모든 기능을 갖춘 구성원이라는 알림을 기다리는 중" 단계에서 노드 추가 프로세스가 실패합니다. 시스템 이벤트 로그에는 통신 문제를 가리키는 오류 1653 및 5398이 표시됩니다. 클러스터링 서비스는 3343을 통해 통신하므로 문제 해결은 이에 중점을 두었습니다. 방화벽과 AV를 완전히 꺼도 문제가 계속 발생합니다.

새 서버와 이전 서버 사이에서 유일하게 다른 점은 노드 추가 마법사 중에 클러스터 서비스가 새 서버에서 활성화될 때 서버가 UDP 3343을 수신하지 않는다는 것입니다. TCPView를 실행하여 이를 확인했습니다. 현재 클러스터에 있는 2012 서버와 클러스터에 추가하려는 2019 서버를 모두 포함합니다. 2012 서버는 TCP 및 UDP에서 3343을 통한 수신 대기를 표시하지만 2019 서버는 TCP 3343을 통한 수신 및 전송 정보만 표시합니다. TCP 3343을 통해 두 개의 2012 서버에 대한 4개의 시간 대기 통신이 있지만 결국 시간 초과됩니다. 시간 초과 오류로 인해 노드 추가 프로세스가 실패하게 됩니다. 프로세스의 이 시점에서 UDP 3343을 수신하지 않는 것이 노드가 완전히 추가되기 전의 정상적인 동작인지 아니면 서비스가 새 서버의 TCP 및 UDP 3343 모두에서 올바르게 수신하지 않는다는 것을 나타내는지 확실하지 않습니다.

통신을 적극적으로 차단하는 것은 아무것도 없는 것 같습니다. 새 서버가 다른 노드의 통신을 제대로 수신하지 못하는 것 같습니다. 아니면 내가 잘못된 나무를 짖고 있는 걸까요?

답변1

검증 보고서에서는 이에 대해 언급하지 않았지만 2012년 클러스터에 2019년 노드를 추가하는 것은 물리적으로 불가능합니다.

관련 정보