활성 장애 조치(failover) 클러스터 멤버 자격에서 노드가 제거되는 데 문제가 있음

이 문서에서는 노드가 활성 장애 조치(failover) 클러스터 멤버 자격에서 임의로 제거되는 문제를 resolve 방법을 소개합니다.

증상

문제가 발생하면 시스템 이벤트 로그에 기록된 이 이벤트와 같은 이벤트가 표시됩니다.

이 이벤트는 제거된 노드를 제외한 클러스터의 모든 노드에 기록됩니다. 이 이벤트의 이유는 클러스터의 노드 중 하나가 해당 노드를 아래로 표시했기 때문입니다. 그런 다음 이벤트의 다른 모든 노드에 알 줍니다. 노드에 알림이 표시되면 중단된 노드에 대한 하트비트 연결을 중단하고 중단합니다.

노드가 아래로 표시된 원인

Windows 2008 또는 2008 R2 장애 조치(failover) 클러스터의 모든 노드는 이 네트워크에서 클러스터 네트워크 통신을 허용하도록 설정된 네트워크를 통해 서로 통신합니다. 노드는 이러한 네트워크를 통해 하트비트 패킷을 다른 모든 노드로 보냅니다. 이러한 패킷은 다른 노드에서 수신한 다음 응답이 다시 전송됩니다. 클러스터의 각 노드에는 네트워크가 작동 중이고 다른 노드가 작동하도록 모니터링할 자체 하트비트가 있습니다. 다음 예제는 이 동작을 명확히 하는 데 도움이 됩니다.

이러한 패킷 중 하나가 반환되지 않으면 특정 하트비트가 실패한 것으로 간주됩니다. 예를 들어 W2K8-R2-NODE2는 요청을 보내고 W2K8-R2-NODE1에서 하트비트 패킷으로 응답을 수신하여 네트워크를 결정하고 노드가 작동합니다. W2K8-R2-NODE1이 W2K8-R2-NODE2에 요청을 보내고 W2K8-R2-NODE1이 응답을 받지 못하면 손실된 하트비트로 간주되고 W2K8-R2-NODE1은 이를 추적합니다. 이 누락된 응답은 W2K8-R2-NODE1이 다른 하트비트 요청을 받을 때까지 네트워크를 다운으로 표시할 수 있습니다.

기본적으로 클러스터 노드는 연결이 다운되기 전에 5초 동안 5번의 실패로 제한됩니다. 따라서 W2K8-R2-NODE1이 해당 기간에 5번 응답을 받지 못하면 W2K8-R2-NODE2로의 특정 경로가 다운된 것으로 간주합니다. 다른 경로가 여전히 최대로 간주되는 경우 W2K8-R2-NODE2는 활성 멤버로 유지됩니다.

W2K8-R2-NODE2에 대해 모든 경로가 다운된 경우 활성 장애 조치(failover) 클러스터 멤버 자격에서 제거되고 첫 번째 섹션에 표시되는 이벤트 1135가 기록됩니다. W2K8-R2-NODE2에서 클러스터 서비스가 종료된 후 다시 시작되므로 클러스터에 다시 참가할 수 있습니다.

3개 이상의 노드로 중단되는 특정 경로를 처리하는 방법에 대한 자세한 내용은 Jeff Hughes가 작성한 "분할된" 클러스터 네트워크 블로그를 참조하세요.

하트비트 프로세스가 작동하는 방식을 알았으므로 프로세스가 실패하는 알려진 원인 중 일부는 무엇인가요?

1. 실제 네트워크 하드웨어 오류. 노드 사이의 어딘가에 있는 와이어에서 패킷이 손실되면 하트비트가 실패합니다. 관련된 두 노드의 네트워크 추적이 이를 표시합니다.

2. 네트워크 연결에 대한 프로필이 도메인에서 공용으로, 도메인으로 다시 반송될 수 있습니다. 이러한 변경 내용을 전환하는 동안 네트워크 I/O를 차단할 수 있습니다. 검사 네트워크 프로필 작동 로그를 확인하여 이 경우인지 확인할 수 있습니다. 이벤트 뷰어 열고 애플리케이션 및 서비스 로그\Microsoft\Windows\NetworkProfile\Operational로 이동하여 이 로그를 찾을 수 있습니다. 이벤트 ID 1135에 언급된 노드에서 이 로그의 이벤트를 살펴보고 현재 프로필이 변경되었는지 확인합니다. 그렇다면 Windows 7 또는 Windows Server 2008 R2에서 네트워크 위치 프로필이 "도메인"에서 "공용"으로 변경됩니다.

3. 서버에서 IPv6을 사용하도록 설정했지만 Windows 방화벽에서 인바운드 및 아웃바운드에 대해 다음 두 가지 규칙을 사용하지 않도록 설정했습니다.

   • 핵심 네트워킹 - 인접 검색 광고
   • 핵심 네트워킹 - 인접 검색 요청

4. 바이러스 백신 소프트웨어도 이 프로세스를 방해할 수 있습니다. 이 것으로 의심되는 경우 소프트웨어를 사용하지 않도록 설정하거나 제거하여 테스트합니다. 이 시점에서 바이러스로부터 보호되지 않기 때문에 자신의 위험에 이 작업을 수행합니다.

5. 네트워크의 대기 시간으로 인해 이 문제가 발생할 수도 있습니다. 패킷은 노드 간에 손실되지 않을 수 있지만 시간 제한 기간이 만료되기 전에 노드에 충분히 빨리 도착하지 못할 수 있습니다.

6. IPv6은 장애 조치(failover) 클러스터링이 하트비트에 사용할 기본 프로토콜입니다. 하트비트 자체는 포트 3343을 통해 통신하는 UDP 유니캐스트 네트워크 패킷입니다. 이 트래픽을 허용하도록 올바르게 구성되지 않은 스위치, 방화벽 또는 라우터가 있는 경우 이와 같은 문제가 발생할 수 있습니다.

7. IPsec 보안 정책 새로 고침으로 인해 이 문제가 발생할 수도 있습니다. 특정 문제는 IPSec 그룹 정책 업데이트 중에 모든 IPsec SA(보안 연결)가 WFAS(Advanced Security)를 사용하는 Windows 방화벽에 의해 중단된다는 것입니다. 이 경우 모든 네트워크 연결이 차단됩니다. Active Directory로 인증 수행이 지연되는 경우 보안 연결을 재협상할 때 이러한 지연(모든 네트워크 통신이 차단됨)은 클러스터 하트비트의 통과를 차단하고 클러스터 상태 모니터링이 5초 임계값 내에서 응답하지 않는 경우 노드를 감지하도록 합니다.

8. 드라이버 및/또는 펌웨어를 카드 이전 또는 오래된 네트워크입니다. 때때로 네트워크 카드 또는 스위치를 잘못 구성하면 하트비트가 손실될 수도 있습니다.

9. 최신 네트워크 카드 및 가상 네트워크 카드에 패킷 손실이 발생할 수 있습니다. 성능 모니터 열고 카운터 "네트워크 인터페이스\패킷이 삭제됨"을 추가하여 추적할 수 있습니다. 이 카운터는 누적되며 서버가 다시 부팅될 때까지만 증가합니다. 여기에 삭제된 많은 수의 패킷이 표시되면 네트워크 카드 수신 버퍼가 너무 낮게 설정되거나 서버가 느리게 수행되고 인바운드 트래픽을 처리할 수 없다는 신호일 수 있습니다. 각 네트워크 카드 제조업체는 네트워크 카드 속성에 이러한 설정을 노출할지 여부를 선택하므로 이러한 값을 늘리는 방법을 알아보려면 제조업체의 웹 사이트를 참조해야 하며 권장 값을 사용해야 합니다. VMware에서 실행하는 경우 다음 블로그에서는 이 문제를 알리는 방법뿐만 아니라 변경할 설정에 대한 VMware 문서를 가리키는 방법을 포함하여 이에 대해 좀 더 자세히 설명합니다.

   VMware ESX의 장애 조치(Failover) 클러스터 멤버 자격에서 제거되는 노드

이러한 이벤트가 기록되는 가장 일반적인 이유이지만 다른 이유도 있을 수 있습니다. 이 블로그의 요점은 프로세스에 대한 인사이트를 제공하고 찾을 항목에 대한 아이디어를 제공하는 것이었습니다. 일부는 이 문제를 중지하기 위해 다음 값을 최대값으로 올립니다.

매개 변수	기본	범위
SameSubnetDelay	1000밀리초	250-2000밀리초
CrossSubnetDelay	1000밀리초	250-4000밀리초
SameSubnetThreshold	5	3-10
CrossSubnetThreshold	5	3-10

이러한 값을 최대값으로 늘리면 이벤트 및 노드 제거가 사라질 수 있으며 문제를 마스킹하기만 하면 됩니다. 그것은 아무것도 수정하지 않습니다. 가장 좋은 방법은 하트비트 실패의 근본 원인을 파악하고 수정하는 것입니다. 이러한 값을 늘려야 하는 유일한 필요성은 노드가 서로 다른 위치에 있고 네트워크 대기 시간을 극복할 수 없는 다중 사이트 시나리오에 있습니다.