장애 조치(failover) 클러스터에서 쿼럼 감시는 쿼럼 투표 프로세스에 참여하여 클러스터의 고가용성을 유지하는 데 도움이 되는 구성 요소입니다. 쿼럼은 클러스터가 계속 작동하면서 유지할 수 있는 오류 수를 결정하는 데 사용되는 개념입니다.
클러스터에서 각 노드는 투표를 받고 쿼럼 감시는 투표를 할 수도 있습니다. 총 투표 수에 따라 쿼럼이 결정됩니다. 클러스터가 작동하려면 투표의 절반 이상이 활성 상태여야 합니다. 투표 수가 이 임계값 아래로 떨어지면 클러스터의 두 부분이 활성 부분이라고 생각하여 데이터가 손상되는 분할 브레인 시나리오를 방지하기 위해 클러스터 실행이 중지됩니다.
쿼럼 감시의 역할은 노드 수가 짝수이거나 특정 노드가 실패하는 경우 과반수를 달성하거나 유지하기 위한 추가 투표를 제공하는 것입니다. 활성 투표 수가 필요한 과반수 아래로 떨어지면 클러스터는 '스플릿 브레인' 조건을 방지하기 위한 작업을 중단합니다. 분할 브레인은 클러스터의 개별 섹션이 각각 독립적으로 작동하고 있다고 생각하여 데이터 불일치 또는 손상을 초래할 수 있는 시나리오입니다.
쿼럼 감시자 유형
고가용성을 유지하고 스플릿 브레인 상태를 방지하기 위해 구성할 수 있는 세 가지 유형의 쿼럼 감시자가 있습니다. 각 투표는 클러스터의 쿼럼 상태를 공정하게 평가하는 역할을 합니다.
- Cloud witness - A cloud-based service like Azure Blob Storage
- Disk witness - A shared disk accessible by all nodes
- 파일 공유 감시 - 모든 노드에서 액세스할 수 있는 공유 폴더
연속 작업 및 데이터 무결성을 보장하기 위해 이러한 쿼럼 감시는 각각 클러스터 작업에 대한 과반수 투표를 달성하는 고유한 방법을 제공합니다. 가장 좋은 방법은 쿼럼에 홀수의 투표 요소가 있도록 구성하는 것입니다. 클러스터에 짝수의 투표 노드가 있는 경우 디스크 감시 또는 파일 공유 감시를 추가합니다. 이 구성을 사용하면 클러스터에서 하나의 추가 노드 오류를 허용할 수 있습니다. 또한 증인 투표를 추가하면 클러스터 노드의 절반이 동시에 장애가 발생하거나 연결을 잃어도 클러스터가 계속 운영될 수 있습니다. 선택한 쿼럼 구성에 따라 클러스터는 다음 쿼럼 모드 중 하나로 구성됩니다.
| Mode | Description |
|---|---|
| 노드 과반수(중재자 없음) | 노드에만 응답이 있으며, 쿼럼 감시는 구성되지 않습니다. 클러스터 쿼럼은 활성 클러스터 노드의 과반수 투표에 따라 달라집니다. |
| 감시 있는 노드 과반수(디스크 또는 파일 공유) | 노드에 투표가 있습니다. 또한, 쿼럼 증인은 투표권을 가집니다. 클러스터 쿼럼은 감시 투표를 포함하여 활성 클러스터 노드의 과반수 투표에 의존합니다. 쿼럼 목격자는 지정된 디스크 목격자 또는 지정된 파일 공유 지점 목격자일 수 있습니다. |
| 과반수 없음(디스크 증인만 해당) | 노드에는 투표가 없습니다. 디스크 증인만 투표권이 있습니다. 클러스터 쿼럼은 디스크 목격자의 상태에 의존합니다. 일반적으로 이 모드는 권장되지 않으며 클러스터에 대해 단일 실패 지점을 만들기 때문에 선택해서는 안 됩니다. |
Note
파일 공유 감시 또는 클라우드 감시를 사용하는 경우 유지 관리를 위해 모든 클러스터 노드를 종료하기 전에 마지막 활성 노드에서 클러스터 서비스를 다시 시작해야 합니다. 이렇게 하면 클러스터가 다시 온라인 상태가 되면 작업을 원활하게 다시 시작할 수 있습니다. 이와 같은 감시 유형은 최신 클러스터 데이터베이스를 저장하지 않으므로 디바이스를 시작하는 동안 오류가 발생할 수 있습니다. To learn more, see Event 1561.
Tip
You can verify the dynamic vote assigned to a node by checking the DynamicWeight property of the cluster node using the Get-ClusterNode cmdlet. A DynamicWeight value of 0 means the node doesn't have a quorum vote, while a value of 1 indicates that the node has a quorum vote.
Cloud witness
클라우드 감시는 물리적 데이터 센터 대신 클라우드의 Azure VM(Virtual Machine)을 쿼럼 감시로 사용하기 때문에 기존 클러스터 쿼럼 감시 구성과 다릅니다. 클라우드 목격자는 Azure Blob Storage를 사용하여 시스템에서 쿼럼을 달성하기 위한 결정적인 투표로 사용되는 Blob 파일을 읽고 씁니다. 다음 다이어그램에서는 클라우드 감시를 사용하는 예제 구성을 보여 줍니다.
클라우드 감시 구성에는 세 번째 별도의 데이터 센터가 필요하지 않으며 다른 데이터 센터 중 하나가 꺼질 경우 총 종료를 방지하기 위해 추가 투표를 받습니다. 쿼럼 감시를 저장하기 위한 추가 사이트가 필요하지 않으며 현장 데이터 센터에 필요한 정기적인 물리적 유지 관리도 필요하지 않습니다.
중복성과 함께 클라우드 감시 기능을 사용하는 다른 이점이 있습니다.
Azure Blob Storage를 사용하면 일반적으로 퍼블릭 클라우드에서 VM을 호스팅할 때 발생하는 추가 유지 관리 부담을 줄일 수 있습니다.
여러 클러스터에 대해 동일한 Azure Storage 계정을 사용할 수 있습니다. 유일한 요구 사항은 클러스터당 하나의 블롭만 사용하고, 블롭 파일 이름을 클러스터의 고유 ID로 지정하는 것입니다.
블롭 파일은 많은 데이터를 필요로 하지 않으며 클러스터 노드 상태가 변경될 때만 업데이트되므로, 저장소 계정의 유지 비용이 낮습니다.
Azure에는 내장된 클라우드 감시 리소스 유형이 있습니다.
클라우드 감시는 클러스터 데이터베이스의 복사본을 저장하지 않습니다.
Disk witness
디스크 감시는 클러스터의 고가용성을 유지하기 위해 장애 조치(failover) 클러스터에서 사용되는 쿼럼 감시 유형입니다. 디스크 감시는 클러스터의 모든 노드가 액세스할 수 있는 공유 디스크입니다. 디스크 감시에는 클러스터 구성 데이터베이스를 저장하는 데 사용되는 적은 양의 스토리지 공간이 포함되어 있습니다. 이 스토리지 공간에는 각 노드의 상태 및 클러스터 리소스의 소유권과 같은 클러스터에 대한 중요한 정보가 포함됩니다. 작동 방법은 다음과 같습니다.
디스크 감시는 모든 노드가 액세스할 수 있는 공유 스토리지로 구성되지만 지정된 시간에 하나의 노드만 기록합니다.
클러스터 서비스가 시작되면 각 노드는 디스크 감시와 통신하여 최신 클러스터 구성을 읽습니다.
디스크 감시는 쿼럼 투표 프로세스에 참여합니다. 노드가 장애가 발생하면 디스크 증인은 추가 투표를 제공하여 분할 브레인 상태를 방지하는 데 도움이 됩니다.
네트워크 파티션이 있는 경우 응답이 가장 많은 디스크 감시에 액세스할 수 있는 파티션의 측면이 계속 실행되어 클러스터의 무결성을 유지합니다.
디스크 감시는 노드 수가 짝수인 클러스터에서 유용하며, 이 클러스터는 항상 과반수 투표를 보장하기 위해 타이브레이커 역할을 할 수 있습니다. 디스크 감시가 쿼럼을 유지하는 데 도움이 될 수 있으므로 여러 노드가 동시에 실패하는 시나리오에서도 유용합니다.
디스크 감시를 사용할 때의 주요 이점은 모든 노드가 클러스터의 현재 상태에 동의할 수 있도록 일관되고 신뢰할 수 있는 방법을 제공한다는 것입니다. 일관성은 장애 조치(failover) 클러스터의 적절한 작동을 보장하는 데 중요합니다. 디스크 감시는 사용자 또는 애플리케이션 데이터를 저장하지 않으며, 클러스터 구성 데이터베이스 및 쿼럼 투표만을 위한 것입니다.
파일 공유 증인
클러스터에 짝수의 투표 노드가 포함되어 있으면 감시 노드를 구성해야 합니다. 감시 응답을 추가하면 클러스터 노드 절반이 작동 중지되거나 연결이 끊어진 경우 클러스터가 계속 실행될 수 있습니다. 파일 공유 감시는 SMB(서버 메시지 블록) 파일 공유를 사용하여 로그 파일에서 클러스터 정보를 유지 관리하는 쿼럼 감시 유형입니다. 이 파일 공유는 서버, USB 스토리지 또는 NAS(네트워크 연결 스토리지)에서 호스트할 수 있습니다.
파일 공유 감시는 복제된 스토리지가 있는 멀티 사이트 클러스터에도 유용합니다. 다음과 같은 경우 파일 공유 감시를 사용할 수 있습니다.
클러스터 노드에 안정적인 인터넷 연결 또는 인터넷 연결이 없으므로 클라우드 감시를 사용할 수 없습니다.
디스크 감시에 사용할 공유 드라이브가 없으므로 디스크 감시를 사용할 수 없습니다. 예를 들어 Storage Spaces Direct 클러스터, SQL Server Always On 가용성 그룹(AG), 또는 Exchange 데이터베이스 가용성 그룹(DAG)입니다. 이러한 유형의 클러스터는 공유 디스크를 사용하지 않습니다.
이 예제는 두 개의 현장(on-site) 데이터 센터에 두 개의 노드가 있는 단순화된 구성을 보여줍니다. 일반적인 클러스터에서 각 노드는 하나의 투표권을 가지고 있으며, 파일 공유 감시자는쿼럼 감시자에게 추가 투표권을 제공합니다. 이 추가적인 한 표 덕분에 데이터 센터 중 하나가 꺼지더라도 클러스터가 계속 운영될 수 있습니다. 예제에서 클러스터 쿼럼은 총 다섯 표를 가질 수 있으며, 세 표만 있으면 계속 운영될 수 있습니다.
그러나 두 데이터 센터 외에도 파일 공유 감시역할을 하는 세 번째 데이터 센터가 있음을 알 수 있습니다. 이 데이터 센터는 다른 두 사이트와 분리되어 있으며, 시스템 파일 공유를 백업하는 파일 서버를 호스팅합니다. 파일 공유 위트니스는 이 클러스터 쿼럼 구성에서 쿼럼 위트니스 역할을 하며, 데이터 센터 중 하나가 예기치 않게 종료되더라도 시스템이 계속 운영될 수 있도록 보장합니다.
파일 공유 위트니스를 사용하면 파일 서버를 고가용성 상태로 유지하기에 충분한 중복성을 확보할 수 있습니다. 하지만 파일 공유 위트니스를 별도의 사이트에 있는 다른 서버에 호스팅할 경우, 설정, 정기적인 유지 관리, 그리고 다른 사이트와의 독립적인 연결이 필요하다는 점을 기억해야 합니다.
Witness configuration
가장 좋은 방법은 쿼럼에 홀수의 투표 요소가 있도록 구성하는 것입니다. 클러스터에 짝수의 투표 노드가 있는 경우 디스크 감시 또는 파일 공유 감시를 추가하여 고가용성을 보장합니다. 이 구성을 사용하면 클러스터가 하나의 추가 노드의 실패를 허용할 수 있습니다. 또한 증인 투표를 추가하면 클러스터 노드의 절반이 연속적으로 장애가 발생하거나 연결이 끊어지더라도 클러스터가 계속해서 운영될 수 있습니다.
일반적으로 모든 클러스터 노드에서 공유 디스크에 액세스할 수 있는 경우 디스크 감시를 사용하는 것이 좋습니다. 반면에 파일 공유 감시는 복제된 스토리지와 관련된 다중 사이트 재해 복구 시나리오에 선호됩니다. 복제된 스토리지를 사용하여 디스크 감시를 구성하는 것은 스토리지 솔루션이 모든 사이트에서 복제된 스토리지로의 읽기-쓰기 액세스를 지원하는 경우에만 가능합니다. 감시 구성 유형에 대한 자세한 내용은 쿼럼 감시 배포를 참조하세요.
노드 투표 할당
고급 쿼럼 구성에서는 개별 노드에 대한 쿼럼 투표를 할당하거나 제거할 수 있습니다. 기본적으로 클러스터의 모든 노드에는 투표가 할당됩니다. 그러나 노드의 투표가 제거되더라도 여전히 클러스터에 참여하고 클러스터 데이터베이스에 대한 업데이트를 수신하며 애플리케이션을 호스팅할 수 있습니다.
특정 재해 복구 시나리오에서는 특정 노드에서 투표를 제거하는 것이 좋습니다. 예를 들어 다중 사이트 클러스터에서 백업 사이트에 있는 노드에서 투표를 제거하여 쿼럼 계산에 영향을 미치지 않도록 할 수 있습니다. 이 방법은 일반적으로 사이트 간 수동 장애 조치(failover)를 계획할 때만 권장됩니다. 노드 투표 할당은 홀수의 투표 노드를 적용하는 데 권장되지 않습니다. 대신 디스크 감시 또는 파일 공유 감시를 구성해야 합니다.
동적 쿼럼 관리
동적 쿼럼 관리는 클러스터가 쿼럼 과반수 요구 사항을 동적으로 조정할 수 있는 고급 구성 옵션입니다. 이 기능을 사용하면 노드가 순차적으로 종료되는 경우에도 클러스터가 작동 상태를 유지할 수 있으므로 클러스터가 마지막으로 남아 있는 노드에서 실행되도록 할 수 있습니다.
동적 쿼럼 관리는 장애 조치(failover) 클러스터에 대해 향상된 유연성과 복원력을 제공하므로 동적 환경에서 고가용성을 유지하는 데 유용한 기능입니다. 동적 쿼럼 관리를 사용하도록 설정하면 클러스터는 현재 클러스터 상태에 따라 노드에 할당된 투표를 자동으로 조정하여 클러스터가 쿼럼을 유지하면서 노드 오류 또는 계획된 종료를 유지할 수 있도록 할 수 있습니다. 동적 쿼럼 관리를 사용하는 경우 노드 응답이 할당되도록 구성된 노드에서만 동적으로 응답을 할당하거나 제거할 수 있습니다.
Key considerations:
- 동적 쿼럼 관리를 사용하면 클러스터가 대부분의 투표 멤버의 동시 실패에서 살아남을 수 없습니다. 노드가 실패하거나 종료되는 시점에 계속 실행하려면 클러스터에 쿼럼 과반수가 있어야 합니다.
- 노드의 투표가 명시적으로 제거된 경우 클러스터는 해당 투표를 동적으로 추가하거나 제거할 수 없습니다.
- 스토리지 공간 다이렉트가 사용하도록 설정된 클러스터에서 클러스터는 최대 두 개의 노드 오류만 허용할 수 있습니다.
쿼럼 구성에 대한 일반 권장 사항
클러스터 소프트웨어는 노드 수 및 공유 스토리지의 가용성에 따라 새 클러스터에 대한 쿼럼 구성을 자동으로 결정합니다. 이 기본 구성은 일반적으로 클러스터에 가장 적합합니다. 클러스터를 만든 후 프로덕션 환경에 배포하기 전에 쿼럼 설정을 검토하는 것이 좋습니다.
자세한 쿼럼 구성을 검사하려면 구성 유효성 검사 마법사 또는 테스트 클러스터 cmdlet을 사용하여 쿼럼 구성 유효성 검사 테스트를 실행할 수 있습니다. 장애 조치(failover) 클러스터 관리자에서 기본 쿼럼 구성은 선택한 클러스터에 대한 요약 섹션에 표시됩니다. Alternatively, you can retrieve detailed information about quorum resources by running the Get-ClusterQuorum cmdlet.
언제든지 쿼럼 구성 유효성 검사 테스트를 실행하여 쿼럼 설정이 클러스터에 최적인지 확인할 수 있습니다. 테스트 결과는 구성 변경이 권장되는지 여부를 나타내며 최적의 설정을 제공합니다. 조정이 필요한 경우 클러스터 쿼럼 구성 마법사를 사용하여 권장되는 변경 내용을 적용할 수 있습니다. 클러스터가 프로덕션 상태이면 클러스터의 특정 요구 사항에 변경이 필요한지 철저히 평가하고 확인하지 않는 한 쿼럼 구성을 수정하지 마세요. 다음과 같은 경우에 쿼럼 구성 변경을 고려할 수 있습니다.
- 노드 추가 또는 제거
- 스토리지 추가 또는 제거
- 장기적 노드 또는 감시 실패
- 다중 사이트 재해 복구 시나리오에서 클러스터 복구
See also
Azure Local에서 클러스터 감시 설정