Always On 클러스터에서 쿼럼이 손실되면 어떻게해야합니까?

회사 DR 절차를 검토하고 있었고 온라인에서 쿼럼을 잃는 Always On Cluster에 대한 솔루션을 찾을 때 비교했습니다. 나는 쿼럼이 손실되는 주제에 가볍게 닿는 주제 클러스터링 vs. 트랜잭션 복제 대 가용성 그룹 에 대한 첫 번째 SE 게시물을 찾기 전에 Google 검색 결과로 3 페이지를 보냈 습니다.

모든 사람이 쿼럼을 잃는 것은 나쁘다는 데 동의하지만 잠재력을 낮추기위한 몇 가지 제안이 있지만 여전히 발생할 수 있습니다. 쿼럼의 Always On 클러스터 손실에서 복구하는 가장 좋은 방법에 대한 좋은 동료 검토 답변을 찾고 있습니다.

AG는 Windows 클러스터링을 기반으로합니다. 쿼럼 손실에 대한 WSFC 절차가 적용됩니다.

• 강제 쿼럼을 통한 WSFC 재해 복구
• 쿼럼없이 WSFC 클러스터를 강제로 시작

WSFC가 실행되면 필요한 경우 AG를 강제 실행할 수 있습니다. 가용성 그룹의 강제 수동 장애 조치 수행 :

WSFC 클러스터에서 강제 쿼럼 (강제 쿼럼)을 수행 한 후 각 가용성 그룹 (데이터 손실 가능)을 강제로 장애 조치해야합니다. WSFC 클러스터 값의 실제 상태가 유실되었을 수 있으므로 강제 장애 조치가 필요합니다. 그러나 쿼럼을 강제하기 전에 기본 복제본이었던 복제본을 호스팅하던 서버 인스턴스 또는 쿼럼을 강제하기 전에 동기화 된 보조 복제본에서 장애 조치를 강제 할 수있는 경우 데이터 손실을 피할 수 있습니다. 자세한 내용 은 쿼럼이 강제 실행 된 후 데이터 손실을 방지하는 잠재적 방법을 참조하십시오 .

AlwaysOn 클러스터에서 쿼럼이 손실되면 어떻게해야합니까?

여러 국가 (NY-LD-HK)에 걸친 다중 서브넷 클러스터링에서 특히 이러한 상황에 처했습니다.

다중 서브넷 클러스터에서 쿼럼 손실을 방지하는 방법은 무엇입니까?

• 클러스터 기본 설정을보다 완화 된 모니터링 상태, 특히이 핫픽스의 사용 또는 속성을 사용하여 클러스터 하트 비트 설정으로 변경 하십시오 .CrossSubnetDelayCrossSubnetThreshold
• AG는 WSFC를 사용하여 클러스터 상태를 결정하기 위해 쿼럼 기반 접근 방식을 사용합니다. 쿼럼 을 올바르게 선택하고 구성하십시오 . 이 블로그 게시물 은 AlwaysON의 쿼럼 투표 구성에 대해 자세히 설명합니다.

• 사이트 인식 클러스터 및 클라우드 감시 기능 이 도입되면서 Windows Server 2016의 상황이 변경되었습니다 .

  확장 된 클러스터의 노드는 이제 물리적 위치 (사이트)를 기준으로 그룹화 할 수 있습니다. 클러스터 사이트 인식은 장애 조치 동작, 배치 정책, 노드 간 하트 비트 및 쿼럼 동작과 같은 클러스터 수명주기 동안 주요 작업을 향상시킵니다.

  Cloud Witness 는 Microsoft Azure를 중재 지점으로 활용 하는 새로운 유형의 장애 조치 클러스터 쿼럼 감시 입니다. Microsoft Azure Blob Storage를 사용하여 Blob 파일을 읽고 쓸 수 있으며 분할 파일 분석의 경우 중재 지점으로 사용됩니다.

쿼럼이 손실되면 어떻게해야합니까?

• 계획되지 않은 정전 / 재해로 인해 클러스터가 다운되면 수동 개입이 필요합니다. Windows 관리자 또는 클러스터 관리자는 수동으로 쿼럼을 강제 실행하고 (이 시점에서 @Remus의 답변으로 다시 연결) 생존 노드를 온라인 상태로 만들어야합니다.

항상 그렇듯이 RCA (루트 원인 분석)를 수행하려면 AlwaysON RCA 용 SQL Server 장애 조치 (Failover) 클러스터 진단 로그에 대해 Windows 클러스터 로그를 수집하십시오 . SQL Server 로그 디렉토리에있는 이러한 파일의 형식은 다음과 같습니다 <HOSTNAME>_<INSTANCENAME>_SQLDIAG_X_XXXXXXXXX.xel..

미러링 된 서버의 연결이 끊어진 중단에 관여 한 후 걱정할 사항 중 하나는 애플리케이션이 단일 인스턴스를 가리 키도록하는 것입니다. 네트워크 중단시 Always On 클러스터의 모든 노드가 작동하지만 서로 통신 할 수는 없습니다. 보조 노드로 장애 조치를 강제 한 다음 중단이 발생하는 한 원래 기본 노드는 강제 장애 조치에 대해 알지 못하므로 두 개의 기본 노드를 가질 수 있습니다.

애플리케이션 서버의 위치, 구성 및 SQL 서버에 도달하는 기능에 따라 이론적으로 두 개의 노드가 기본 노드라고 믿고 동시에 데이터가 변경된다고 생각할 수 있습니다. 네트워크 문제를 해결하고 노드가 연결을 다시 시작하면 원래 기본 노드에서 변경된 모든 데이터가 장애 조치를 수행 한 노드에서 덮어 씁니다. 중요한 데이터가 손실 될 수 있습니다.

SQL 2005와 미러링으로이 상황을 한 번 보았습니다. 또한 장애 조치를 강요하지 않고 도달 할 수 없게하기로 결정했습니다. 최악의 경우 미러링을 다시 시작하기 위해 백업 및 복원해야한다면 트랜잭션 로그가 가득 차서 앉아 있던 디스크를 확장 할 수없는 위험이있는 2 일 프로세스가 될 것입니다.