장애 조치(failover) 클러스터 네트워크 임계값 튜닝

이 문서에서는 장애 조치(failover) 클러스터 네트워크 설정의 임계값을 조정하는 솔루션을 소개합니다. 이러한 설정의 값을 늘리면 일시적인 네트워크 문제에 대한 클러스터의 민감도를 줄이는 데 도움이 될 수 있습니다.

증상

Windows 장애 조치(failover) 클러스터 노드를 실행하는 경우 클러스터 설정을 보다 완화된 모니터링 상태로 변경하는 것이 좋습니다. 기본 제공 클러스터 설정은 제한적이므로 불필요한 중단이 발생할 수 있습니다. 기본 설정은 고도로 조정된 온-프레미스 네트워크를 위해 설계되었으며, Microsoft Azure(IaaS)와 같은 다중 테넌트 환경으로 인한 대기 시간이 발생할 가능성을 고려하지 않습니다.

Windows Server 장애 조치 클러스터링에서는 Windows 클러스터에서 노드의 네트워크 연결 및 상태를 지속적으로 모니터링합니다. 네트워크를 통해 노드에 연결할 수 없는 경우, 복구 작업을 수행하여 클러스터의 다른 노드에서 애플리케이션과 서비스를 가져와 온라인 상태로 만듭니다. 클러스터 노드 간 통신 대기 시간으로 인해 다음 오류가 발생할 수 있습니다.

오류 1135(시스템 이벤트 로그)

클러스터 노드 노드 1이 활성 장애 조치(failover) 클러스터 멤버 자격에서 제거되었습니다. 이 노드의 클러스터 서비스가 중지되었을 수 있습니다. 이는 장애 조치 클러스터의 다른 활성 노드와 통신이 끊긴 노드 때문일 가능성도 있습니다. 구성 유효성 검사 마법사를 실행해 네트워크 구성을 확인합니다. 해당 조건이 계속될 경우 이 노드의 네트워크 어댑터와 관련된 하드웨어 또는 소프트웨어 오류가 있는지 확인합니다. 또한 허브, 스위치 또는 브릿지와 같이 노드가 연결된 다른 네트워크 구성 요소에서 오류가 있는지 확인합니다.

Cluster.log 예제:

0000ab34.00004e64::2014/06/10-07:54:34.099 DBG   [NETFTAPI] Signaled NetftRemoteUnreachable event, local address 10.xx.x.xxx:3343 remote address 10.x.xx.xx:3343
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] got event: Remote endpoint 10.xx.xx.xxx:~3343~ unreachable from 10.xx.x.xx:~3343~
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Marking Route from 10.xxx.xxx.xxxx:~3343~ to 10.xxx.xx.xxxx:~3343~ as down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] Checking to see if all routes for route (virtual) local fexx::xxx:5dxx:xxxx:3xxx:~0~ to remote xxx::cxxx:xxxd:xxx:dxxx:~0~ are down
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [NDP] All routes for route (virtual) local fxxx::xxxx:5xxx:xxxx:3xxx:~0~ to remote fexx::xxxx:xxxx:xxxx:xxxx:~0~ are down
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [CORE] Node 8: executing node 12 failed handlers on a dedicated thread
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: Cleaning up connections for n12.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [Nodename] Clearing 0 unsent and 15 unacknowledged messages.
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: n12 node object is closing its connections
0000ab34.00008b68::2014/06/10-07:54:34.099 INFO  [DCM] HandleNetftRemoteRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 1: Old: 05.936, Message: Response, Route sequence: 150415, Received sequence: 150415, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:28.000, Ticks since last sending: 4
0000ab34.00007328::2014/06/10-07:54:34.099 INFO  [NODE] Node 8: closing n12 node object channels
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 2: Old: 06.434, Message: Request, Route sequence: 150414, Received sequence: 150402, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.665, Ticks since last sending: 36
0000ab34.0000a8ac::2014/06/10-07:54:34.099 INFO  [DCM] HandleRequest: dcm/netftRouteChange
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 3: Old: 06.934, Message: Response, Route sequence: 150414, Received sequence: 150414, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:27.165, Ticks since last sending: 4
0000ab34.00004b38::2014/06/10-07:54:34.099 INFO  [IM] Route history 4: Old: 07.434, Message: Request, Route sequence: 150413, Received sequence: 150401, Heartbeats counter/threshold: 5/5, Error: Success, NtStatus: 0 Timestamp: 2014/06/10-07:54:26.664, Ticks since last sending: 36

0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realLocal>10.xxx.xx.xxx:~3343~</realLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <realRemote>10.xxx.xx.xxx:~3343~</realRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualLocal>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualLocal>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <virtualRemote>fexx::xxxx:xxxx:xxxx:xxxx:~0~</virtualRemote>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Delay>1000</Delay>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Threshold>5</Threshold>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Priority>140481</Priority>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO    <Attributes>2147483649</Attributes>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO  </struct mscs::FaultTolerantRoute>
0000ab34.00007328::2014/06/10-07:54:34.100 INFO   removed

0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: Lost quorum (3 4 5 6 7 8)
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   [QUORUM] Node 8: goingAway: 0, core.IsServiceShutdown: 0
0000ab34.0000a7c0::2014/06/10-07:54:38.433 ERR   lost quorum (status = 5925)

원인

클러스터의 연결 상태 구성에 사용되는 두 가지 설정이 있습니다.

지연 - 노드 간에 클러스터 하트비트가 전송되는 빈도를 정의합니다. 연기는 다음 하트비트가 전송되기 전의 시간(초)입니다. 같은 클러스터 내에서 같은 서브넷의 노드 간 및 서로 다른 서브넷에 있는 노드 간 지연이 서로 다를 수 있습니다.

임계값 - 클러스터가 복구 작업을 수행하기 전에 누락된 하트비트 수를 정의합니다. 임계값은 여러 하트비트입니다. 같은 클러스터 내에서 같은 서브넷의 노드 간 및 서로 다른 서브넷에 있는 노드 간 임계값이 서로 다를 수 있습니다.

기본적으로 Windows Server는 SameSubnetThreshold를 10으로, SameSubnetDelay를 1000ms로 설정합니다. 예를 들어, 연결 모니터링이 10초간 실패하면 장애 조치 임계값에 도달하여 클러스터 멤버 자격에서 노드를 제거할 수 없게 됩니다. 이로 인해 리소스가 클러스터에서 사용 가능한 다른 노드로 이동합니다. 클러스터 오류 1135(위)를 포함한 클러스터 오류가 보고됩니다.

해결

이 문제를 해결하려면 클러스터 네트워크 구성 설정을 완화하세요. 하트비트와 임계값을 참조하세요.

참조

Windows 클러스터 네트워크 구성 설정 튜닝에 대한 자세한 내용은 장애 조치 클러스터 네트워크 임계값 튜닝을 참조하세요.

cluster.exe 사용하여 Windows 클러스터 네트워크 구성 설정을 조정하는 방법에 대한 자세한 내용은 장애 조치(failover) 클러스터에 대한 클러스터 네트워크를 구성하는 방법을 참조하세요.