SQL Server IaaS - 장애 조치(failover) 클러스터 네트워크 임계값 조정

이 문서에서는 장애 조치(failover) 클러스터 네트워크의 임계값을 조정하기 위한 솔루션을 소개합니다.

증상

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

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

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

클러스터 노드 노드 1이 활성 장애 조치(failover) 클러스터 멤버 자격에서 제거되었습니다. 이 노드의 클러스터 서비스가 중지되었을 수 있습니다. 장애 조치(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 2016 SameSubnetThreshold를 10으로 설정하고 SameSubnetDelay를 1000ms로 설정합니다. 예를 들어 연결 모니터링이 10초 동안 실패하면 장애 조치 임계값에 도달하여 클러스터 멤버 자격에서 노드에 연결할 수 없게 됩니다. 이렇게 하면 리소스가 클러스터에서 사용 가능한 다른 노드로 이동됩니다. 클러스터 오류 1135(위)를 포함하여 클러스터 오류가 보고됩니다.

해결 방법

이 문제를 resolve 클러스터 네트워크 구성 설정을 완화합니다. 하트비트 및 임계값을 참조하세요.

참조

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

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