☰

하트비트 경로 삭제로 인해 WSFC 클러스터의 Windows Server 2016 게스트가 무작위로 격리됨

tag-icon • tag-icon windows-server-2016 windows-cluster
하트비트 경로 삭제로 인해 WSFC 클러스터의 Windows Server 2016 게스트가 무작위로 격리됨

Hyper-V Server 2016에서 호스팅하는 2개의 게스트 Windows Server 2016 OS가 있습니다. 게스트 OS 클러스터는 매우 불안정하며 노드 중 하나가 지속적으로 격리됩니다(하루에 여러 번).

Windows Server 2012R2 클러스터도 있습니다. 이는 동일한 Hyper-V 호스트에서 호스팅되며 아무런 문제가 없습니다. 이는 2012R2와 2016 사이에 동일한 네트워킹 및 Hyper-V 인프라를 보유하고 있음을 의미합니다.

2016 호스트에 대한 추가 구성:

  1. 네트워크 연결에서 모든 어댑터에 대해 TCP/IPv6이 선택 취소되어 있습니다.이것이 실제로 클러스터에 대해 IPv6을 비활성화하지 않는다는 것을 알고 있습니다.NetFT의 숨겨진 네트워크 어댑터를 사용하고 하트비트를 위해 IPv4에 IPv6을 캡슐화합니다. 좋은 2012R2 호스트에서도 동일한 구성을 사용합니다.
  2. 2012R2 클러스터는 Witness 없이 원하는 대로 작동했지만 처음에는 2016도 동일하게 구성했습니다. 이러한 문제를 해결하기 위해 2016 클러스터에 파일 공유 감시를 추가했습니다. 변경 사항은 없습니다.
  3. 네트워크 검증 보고서가 성공적으로 완료되었습니다.

알아요무엇그런 일이 일어나는데, 모르겠어왜. 그만큼무엇:

  1. 클러스터는 포트 3343의 두 노드 사이의 여러 인터페이스를 통해 하트비트 UDP 패킷으로 탁구를 재생합니다. 매초.
  2. 갑자기 노드 1개가 탁구 게임을 멈추고 응답하지 않습니다. 한 노드는 여전히 하트비트 전달을 시도합니다.
  3. 글쎄, 노드가 라우팅 정보 지식을 제거했음을 확인하기 위해 클러스터 로그 파일을 읽었습니다.
000026d0.000028b0::2019/06/20-10:58:06.832 ERR   [CHANNEL fe80::7902:e234:93bd:db76%6:~3343~]/recv: Failed to retrieve the results of overlapped I/O: 10060
000026d0.000028b0::2019/06/20-10:58:06.909 ERR   [NODE] Node 1: Connection to Node 2 is broken. Reason (10060)' because of 'channel to remote endpoint fe80::7902:e234:93bd:db76%6:~3343~ has failed with status 10060'
...
000026d0.000028b0::2019/06/20-10:58:06.909 WARN  [NODE] Node 1: Initiating reconnect with n2.
000026d0.000028b0::2019/06/20-10:58:06.909 INFO  [MQ-...SQL2] Pausing
000026d0.000028b0::2019/06/20-10:58:06.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 00.000 so far.
000026d0.00000900::2019/06/20-10:58:08.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 02.000 so far.
000026d0.00002210::2019/06/20-10:58:10.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 04.000 so far.
000026d0.00002fc0::2019/06/20-10:58:12.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 06.000 so far.
...
000026d0.00001c54::2019/06/20-10:59:06.911 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 1:00.000 so far.
000026d0.00001c54::2019/06/20-10:59:06.911 WARN  [Reconnector-...SQL2] Timed out, issuing failure report.
...
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO  [RouteDb] Cleaning all routes for route (virtual) local fe80::e087:77ce:57b4:e56c:~0~ to remote fe80::7902:e234:93bd:db76:~0~
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <realLocal>10.250.2.10:~3343~</realLocal>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <realRemote>10.250.2.11:~3343~</realRemote>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <virtualLocal>fe80::e087:77ce:57b4:e56c:~0~</virtualLocal>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <virtualRemote>fe80::7902:e234:93bd:db76:~0~</virtualRemote>

이제 WHY 부분은... 왜 그렇게 하는 걸까요? 모르겠습니다. 1분 일찍 다음과 같이 불평합니다 Failed to retrieve the results of overlapped I/O. 하지만 여전히 UDP 패킷이 전송/수신되는 것을 볼 수 있습니다.

와이어샤크

경로가 10:59:06에 제거되고 노드 핑이 1개만 있을 때까지 퐁은 없습니다. Wireshark에서 볼 수 있듯이 소스 열에는 IP 10.0.0.19 및 10.250.2.10이 없습니다.

와이어샤크 2

약 35초 후에 경로가 다시 추가되지만 이는 도움이 되지 않습니다. 노드는 이미 3시간 동안 격리되었습니다.

내가 여기서 무엇을 놓치고 있는 걸까요?

답변1

Windows Server 2019 장애 조치 클러스터(Hyper-V 2019용)에서도 동일한 문제가 발생했습니다. 나는 일반적으로 내 서버에서 IPv6도 비활성화하는데 이로 인해 문제가 발생합니다. 클러스터는 많은 심각한 오류를 발생시켰고 파일 공유 감시 기능도 설치되어 작동 중임에도 불구하고 때때로 하드 장애 조치를 수행했습니다(?!).

이벤트 로그에서 관찰한 오류 및 경고는 다음과 같습니다.

장애 조치 클러스터링 이벤트 ID:

  • 1135(클러스터 노드 '....'가 활성 장애 조치 클러스터 구성원에서 제거되었습니다.)
  • 1146(클러스터 RHS(Resource Hosting Subsystem) 프로세스가 종료되었으며 다시 시작됩니다.)
  • 1673(클러스터 노드 '....'이(가) 격리 상태에 들어갔습니다.)
  • 1681('...' 노드의 가상 컴퓨터가 모니터링되지 않는 상태로 들어갔습니다.)

서비스 제어 관리자 이벤트 ID:

  • 7024(클러스터를 형성하기 위한 클러스터 노드의 쿼럼이 존재하지 않습니다.)
  • 7031(클러스터 서비스 서비스가 예기치 않게 종료되었습니다.)

장애 조치 클러스터링-클라이언트

  • 81 (확장 RPC 오류 정보)

귀하의 연구 덕분에 중요한 단서를 얻었습니다. 숨겨진 어댑터는 여전히 IPv6를 사용합니다. 당신이 링크한 기사에서는 숨겨진 어댑터에서 IPv6을 비활성화하는 것이 권장되지 않거나 주류가 아니라고 말했지만 다른 모든 어댑터에서는 비활성화하는 것이 지원되고 테스트되었기 때문에 그가 작동하지 않는 이유가 무엇인지 궁금합니다.

다음 명령을 사용하여 클러스터 로그를 가져왔습니다(힌트를 알려주셔서 감사합니다! 이 유용한 명령을 몰랐습니다).

# -Destination (Folder) in my case changed to be not on the "C:\" SATADOM (this thing is slow and has few write cycles)
# -TimeSpan (in minutes) limited to one of the Failovers because these logs get HUGE otherwise.
Get-ClusterLog -Destination "E:\" -TimeSpan 5

불행하게도 귀하가 이미 게시한 것과 동일한 로그 항목이 있었습니다.

모든 어댑터에서 IPv6를 다시 활성화하고 다음을 사용하여 터널 관련 어댑터/구성을 되돌렸습니다.

Set-Net6to4Configuration -State Default
Set-NetTeredoConfiguration -Type Default
Set-NetIsatapConfiguration -State Default

그것은 트릭을 수행하지 못했습니다... 더 자세히 살펴보면 "필요하지 않은" IPv6 관련 방화벽 규칙도 항상 비활성화한다는 것을 알았습니다... 그리고 이것이 실제로 중요한 변경인 것 같습니다! 이러한 규칙은 보이지 않는 어댑터에도 영향을 미치는 것 같습니다.

문제는 다음과 같습니다. IPv6은 통신 파트너의 MAC 주소를 찾는 데 ARP를 사용하지 않습니다. Neighbor Discovery Protocol을 사용합니다. 그리고 관련 방화벽 규칙을 비활성화하면 이 프로토콜이 작동하지 않습니다. 다음을 사용하여 IPv4 ARP 항목을 확인할 수 있습니다.

arp -a

IPv6 주소의 MAC 주소는 표시되지 않습니다. 다음을 사용할 수 있습니다.

netsh interface ipv6 show neighbors level=verbose

원하는 경우 다음과 같이 출력을 IPv6 어댑터 주소로 필터링할 수 있습니다.

netsh interface ipv6 show neighbors level=verbose | sls ".*fe80::1337:1337:1234:4321.*" -Context 4 |%{$_.Line,$_.Context.PostContext,""}

그렇게 하면서 나는 그 항목들의 수명이 매우 짧은 것 같다는 것을 알게 되었습니다. 클러스터 파트너의 Microsoft "장애 조치 클러스터 가상 어댑터" 링크 로컬 주소에 대한 항목 상태는 항상 "접근 가능"과 "프로브" 사이에서 전환되었습니다. 하지만 "도달할 수 없음"이 발생한 순간은 얻지 못했지만 IPv6 규칙을 다시 활성화한 후 문제가 사라졌습니다.

Get-NetFirewallRule -ID "CoreNet-ICMP6-*" | Enable-NetFirewallRule

어떻게든 이 MAC 주소는 클러스터 파트너 간에 다른 방식으로 교환되는 것 같습니다(아마 실제 주소가 아니라 "가상 원격" 주소이기 때문일까요?). 따라서 계속해서 다시 나타나서 야생 장애 조치/격리/격리 상태로 이어집니다.

아마도 보이지 않는 어댑터에서 IPv6을 비활성화하는 것도 도움이 되었을 것입니다. 그러나 이는 권장되지 않으므로 이제 IPv6 관련 기능을 모두 비활성화하는 것을 중단하기로 결정했습니다. 어쨌든 미래입니다 :-)

이것이 다른 IPv6 비활성화자에게 도움이 되기를 바랍니다!

관련 정보