강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)WSFC Disaster Recovery through Forced Quorum (SQL Server)

쿼럼 실패는 일반적으로 시스템 관련 재해나, 지속적인 통신 오류 또는 WSFC 클러스터의 여러 노드와 관련된 잘못된 구성으로 인해 발생합니다.Quorum failure is usually caused by a systemic disaster, or a persistent communications failure, or a misconfiguration involving several nodes in the WSFC cluster. 쿼럼 실패에서 복구하려면 수동 개입이 필요합니다.Manual intervention is required to recovery from a quorum failure.

시작하기 전에 Before You Start

필수 구성 요소 Prerequisites

강제 쿼럼 절차는 쿼럼 실패 전에 정상 상태의 쿼럼이 있었다고 가정합니다.The Forced Quorum Procedure assumes that a healthy quorum existed before the quorum failure.

경고

사용자는 Windows Server 장애 조치(Failover) 클러스터링, WSFC 쿼럼 모델, SQL ServerSQL Server및 환경의 특정 배포 구성에 대한 개념 및 상호 작용에 대해 잘 알고 있어야 합니다.The user should be well-informed on the concepts and interactions of Windows Server Failover Clustering, WSFC Quorum Models, SQL ServerSQL Server, and the environment's specific deployment configuration.

자세한 내용은 SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링), WSFC 쿼럼 모드 및 투표 구성(SQL Server)을 참조하세요.For more information, see: Windows Server Failover Clustering (WSFC) with SQL Server, WSFC Quorum Modes and Voting Configuration (SQL Server)

보안 Security

사용자는 WSFC 클러스터의 각 노드에 대한 로컬 Administrators 그룹의 멤버인 도메인 계정이어야 합니다.The user must be a domain account that is member of the local Administrators group on each node of the WSFC cluster.

강제 쿼럼 절차를 통해 WSFC 재해 복구 WSFC Disaster Recovery through the Forced Quorum Procedure

클러스터는 그 구성에 따라 노드 수준의 내결함성을 보장할 수 없기 때문에 쿼럼 실패가 발생하면 WSFC 클러스터의 클러스터형 서비스, SQL Server 인스턴스 및 Always On 가용성 그룹Always On availability groups이 모두 오프라인 상태로 설정됩니다.Remember that quorum failure will cause all clustered services, SQL Server instances, and Always On 가용성 그룹Always On availability groups, in the WSFC cluster to be set offline, because the cluster, as configured, cannot ensure node-level fault tolerance. 쿼럼 실패란 WSFC 클러스터의 정상적인 투표 노드가 더 이상 쿼럼 모델을 충족하지 않음을 의미합니다.A quorum failure means that healthy voting nodes in the WSFC cluster no longer satisfy the quorum model. 일부 노드는 완전히 실패했을 수 있고 나머지 일부 노드는 WSFC 서비스만 종료했으며 쿼럼과의 통신 기능이 손실되었다는 점을 제외하고는 정상일 수 있습니다.Some nodes may have failed completely, and some may have just shut down the WSFC service and are otherwise healthy, except for the loss of the ability to communicate with a quorum.

WSFC 클러스터를 다시 온라인 상태로 전환하려면 기존 구성에서 쿼럼 실패의 근본 원인을 해결하고 필요한 경우 영향을 받은 데이터베이스를 복구해야 하며 실패에서 살아남은 클러스터 토폴로지를 반영하도록 WSFC 클러스터의 나머지 노드를 다시 구성해야 합니다.To bring the WSFC cluster back online, you must correct the root cause of the quorum failure under the existing configuration, recover the affected databases as needed, and you may want to reconfigure the remaining nodes in the WSFC cluster to reflect the surviving cluster topology.

클러스터를 오프라인 상태로 전환한 보안 장치를 무시하기 위해 WSFC 클러스터 노드에서 강제 쿼럼 절차를 수행할 수 있습니다.You can use the forced quorum procedure on a WSFC cluster node to override the safety controls that took the cluster offline. 이 경우 클러스터에서 쿼럼 투표 검사가 일시 중지되어 클러스터의 모든 노드에서 WSFC 클러스터 리소스 및 SQL ServeR을 다시 온라인 상태로 전환할 수 있습니다.This effectively tells the cluster to suspend the quorum voting checks, and lets you bring the WSFC cluster resources and SQL Server back online on any of the nodes in the cluster.

이 유형의 재해 복구 프로세스에는 다음 단계가 포함됩니다.This type of disaster recovery process should include the following steps:

쿼럼 실패에서 복구하려면To Recover from Quorum Failure:

  1. 실패의 범위 확인.Determine the scope of the failure. 응답하지 않는 가용성 그룹 또는 SQL Server 인스턴스, 온라인 상태이며 재해 발생 후 사용이 가능한 클러스터 노드를 식별하고 Windows 이벤트 로그와 SQL Server 시스템 로그를 검토합니다.Identify which availability groups or SQL Server instances are non-responsive, which cluster nodes are online and available for post-disaster use, and examine the Windows event logs and the SQL Server system logs. 필요한 경우 향후 분석을 위해 조사한 데이터와 시스템 로그를 보존해야 합니다.Where practical, you should preserve forensic data and system logs for later analysis.

    SQL Server 2017SQL Server 2017의 응답 인스턴스에서는 [sys.dm_hadr_availability_group_states](../../../relational-databases/system-dynamic-management-views/sys-dm-hadr-availability-group-states-transact-sql.md) DMV(동적 관리 뷰)를 쿼리하여 로컬 서버 인스턴스에서 가용성 복제본을 처리하는 가용성 그룹의 상태 정보를 가져올 수 있습니다.On a responsive instance of SQL Server 2017SQL Server 2017, you can obtain information about the health of availability groups that possess an availability replica on the local server instance by querying the sys.dm_hadr_availability_group_states dynamic management view (DMV).

  2. 단일 노드에서 강제 쿼럼을 수행하여 WSFC 클러스터 시작.Start the WSFC cluster by using forced quorum on a single node. WSFC 클러스터 서비스가 종료된 노드 이외의 노드 중에서 구성 요소 오류 수가 가장 적은 노드를 파악합니다.Identify a node with a minimal number of component failures, other than that the WSFC cluster service was shut down. 이 노드가 대부분의 다른 노드와 통신할 수 있는지 확인합니다.Verify that this node can communicate with a majority of the other nodes.

    이 노드에서 강제 쿼럼 절차를 수행하여 수동으로 클러스터를 온라인 상태로 전환합니다.On this node, manually force the cluster to come online using the forced quorum procedure. 데이터 손실 위험을 최소화하려면 가용성 그룹 주 복제본을 마지막으로 호스팅한 노드를 선택합니다.To minimize potential data loss, select a node that was last hosting an availability group primary replica.

    자세한 내용은 쿼럼 없이 WSFC 클러스터 강제 시작을 참조하세요.For more information, see: Force a WSFC Cluster to Start Without a Quorum

    참고

    강제 쿼럼 설정은 클러스터 전반에 영향을 주어 논리적 WSFC 클러스터가 과반수의 투표를 확보하고 자동으로 정상 쿼럼 작업 모드로 전환될 때까지 쿼럼 검사를 차단합니다.The forced quorum setting has a cluster-wide affect to block quorum checks until the logical WSFC cluster achieves a majority of votes and automatically transitions to a regular quorum mode of operation.

  3. 각 정상 노드에서 한 번에 하나씩 WSFC 서비스 시작.Start the WSFC service normally on each otherwise healthy node, one at a time. 다른 노드에서 클러스터 서비스를 시작할 때는 강제 쿼럼 옵션을 지정할 필요가 없습니다.You do not have to specify the forced quorum option when you start the cluster service on the other nodes.

    각 노드에서 WSFC 서비스가 온라인 상태로 전환되면 서비스는 다른 정상 노드와 협상하여 새 클러스터 구성 상태를 동기화합니다.As the WSFC service on each node comes back online, it negotiates with the other healthy nodes to synchronize the new cluster configuration state. 이 작업은 마지막으로 알려진 클러스터 상태 해결과 관련된 경합 상태를 방지하기 위해 한 번에 한 노드에서 수행되어야 합니다.Remember to do this one node at a time to prevent potential race conditions in resolving the last known state of the cluster.

    경고

    시작하는 각 노드가 새로 온라인 상태로 전환된 다른 노드와 통신할 수 있는지 확인하세요.Ensure that each node that you start can communicate with the other newly online nodes. 다른 노드에서 WSFC 서비스를 비활성화하는 것이 좋습니다.Consider disabling the WSFC service on the other nodes. 그렇지 않으면 쿼럼 노드 집합이 둘 이상 만들어져 분리 장애(split-brain) 시나리오가 발생할 수 있습니다.Otherwise, you run the risk of creating more than one quorum node set; that is a split-brain scenario. 1단계에서 조사한 내용이 정확하면 이러한 일이 발생하지 않습니다.If your findings in step 1 were accurate, this should not occur.

  4. 새 쿼럼 모드 및 노드 투표 구성 적용.Apply new quorum mode and node vote configuration. 쿼럼을 강제로 실행하여 클러스터의 모든 노드를 성공적으로 다시 시작했으며 쿼럼 실패의 근본 원인을 해결한 경우 원래 쿼럼 모드 및 노드 투표 구성을 변경할 필요가 없습니다.If forcing quorum successfully restarted all the nodes in the cluster and the root cause of the quorum failure has been corrected, changes to the original quorum mode and node vote configuration are unnecessary.

    그렇지 않은 경우에는 새로 복구한 클러스터 노드와 가용성 복제본 토폴로지를 평가하여 각 노드의 쿼럼 모드 및 투표 수 할당을 적절히 변경해야 합니다.Otherwise, you should evaluate the newly recovered cluster node and availability replica topology, and change the quorum mode and vote assignments for each node as appropriate. 복구되지 않은 노드의 경우 오프라인으로 설정하거나 해당 노드의 투표 수를 0으로 설정해야 합니다.Un-recovered nodes should be set offline or have their node votes set to zero.

    이때 클러스터의 노드 및 SQL Server 인스턴스 수는 정상 작동할 때의 수로 복원된 것으로 나타나지만At this point, the nodes and SQL Server instances in the cluster may appear to be restored back to regular operation. 정상 상태의 쿼럼은 아직 없을 수도 있습니다.However, a healthy quorum may still not exist. 장애 조치(failover) 클러스터 관리자, SQL Server Management Studio의 Always On 대시보드 또는 적절한 DMV를 사용하여 쿼럼이 복원되었는지 확인하세요.Using the Failover Cluster Manager, or the Always On Dashboard within SQL Server Management Studio, or the appropriate DMVs, verify that a quorum has been restored.

  5. 필요한 경우 가용성 그룹 데이터베이스 복제본 복구.Recover availability group database replicas as needed. 가용성 그룹 데이터베이스 이외 데이터베이스는 일반 SQL Server 시작 프로세스의 일부로 자체적으로 복구되고 온라인 상태로 전환되어야 합니다.Non-availability group databases should recover and come back online on their own as part of the regular SQL Server startup process.

    주 복제본, 동기 보조 복제본, 비동기 보조 복제본의 순서로 가용성 그룹 복제본을 다시 온라인 상태로 전환하여 데이터 손실 위험 및 복구 시간을 최소화할 수 있습니다.You can minimize potential data loss and recovery time for the availability group replicas by bringing them back online in this sequence: primary replica, synchronous secondary replicas, asynchronous secondary replicas.

  6. 실패한 구성 요소 복구 또는 교체 후 클러스터에 대해 유효성 검사 다시 수행.Repair or replace failed components and re-validate cluster. 이제 초기 재해 및 쿼럼 실패에서 복구했으므로 실패한 노드를 복구 또는 교체하고 관련 WSFC 및 Always On 구성을 적절히 조정해야 합니다.Now that you have recovered from the initial disaster and quorum failure, you should repair or replace the failed nodes and adjust related WSFC and Always On configurations accordingly. 여기에는 가용성 그룹 복제본을 삭제하고, 노드를 클러스터에서 제거하고, 노드에서 소프트웨어를 정리하고 다시 설치하는 작업이 포함될 수 있습니다.This can include dropping availability group replicas, evicting nodes from the cluster, or flattening and re-installing software on a node.

    실패한 가용성 복제본을 모두 복구하거나 제거해야 합니다.You must repair or remove all failed availability replicas. SQL ServerSQL Server 는 가용성 복제본의 마지막으로 알려진 가장 오래된 시점 이후의 트랜잭션 로그를 자르지 않습니다. will not truncate the transaction log past the last known point of the farthest behind availability replica. 실패한 복제본을 복구하거나 가용성 그룹에서 제거하지 않으면 트랜잭션 로그 크기가 계속 증가하여 다른 복제본의 트랜잭션 로그 공간이 부족해질 수 있습니다.If a failed replica is not repaired or removed from the availability group, the transaction logs will grow and you will run the risk of running out of transaction log space on the other replicas.

    참고

    가용성 그룹 수신기가 WSFC 클러스터에 있을 때 WSFC 구성 유효성 검사 마법사를 실행하면 마법사가 다음과 같이 잘못된 경고 메시지를 생성합니다.If you run the WSFC Validate a Configuration Wizard when an availability group listener exists on the WSFC cluster, the wizard generates the following incorrect warning message:

    “네트워크 이름 'Name:<network_name>'의 RegisterAllProviderIP 속성이 1로 설정되어 있습니다. 현재 클러스터 구성에서는 이 값을 0으로 설정해야 합니다.”"The RegisterAllProviderIP property for network name 'Name:<network_name>' is set to 1 For the current cluster configuration this value should be set to 0."

    이 메시지는 무시하세요.Please ignore this message.

  7. 필요한 경우 4단계 반복.Repeat step 4 as needed. 이 작업의 목표는 정상적인 작동을 위해 적절한 수준의 내결함성 및 고가용성을 다시 설정하는 데 있습니다.The goal is to re-establish the appropriate level of fault tolerance and high availability for healthy operations.

  8. RPO/RTO 분석 실시.Conduct RPO/RTO analysis. SQL Server 시스템 로그, 데이터베이스 타임스탬프 및 Windows 이벤트 로그를 분석하여 실패의 근본 원인을 파악하고 실제 복구 지점 및 복구 시간 방법을 문서화해야 합니다.You should analyze SQL Server system logs, database timestamps, and Windows event logs to determine root cause of the failure, and to document actual recovery point and recovery time experiences.

참고 항목See Also

SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링)Windows Server Failover Clustering (WSFC) with SQL Server