클러스터 및 풀 쿼럼의 이해

적용 대상: Azure Stack HCI, 버전 21H2 및 20H2; Windows Server 2022, Windows Server 2019

Windows 서버 장애 조치(failover) 클러스터링에서는 Azure Stack HCI 및 Windows Server 클러스터에서 실행되는 워크로드에 대한 고가용성을 제공합니다. 이러한 리소스는 리소스를 호스트하는 노드가 있는 경우 고가용성으로 간주됩니다. 그러나 클러스터는 일반적으로 노드의 절반 이상을 실행해야 하며, 이를 쿼럼이 있다고 합니다.

쿼럼은 네트워크에 파티션이 있고 노드의 하위 집합이 서로 통신할 수 없을 때 발생할 수 있는 분할 브레인 시나리오를 방지하도록 설계되었습니다. 이로 인해 노드의 하위 집합이 모두 워크로드를 소유하고 동일한 디스크에 쓰려고 시도하여 많은 문제가 발생할 수 있습니다. 그러나 장애 조치(failover) 클러스터링의 쿼럼 개념으로 인해 이러한 노드 그룹 중 하나만 계속 실행되도록 하므로 이러한 그룹 중 하나만 온라인 상태로 유지됩니다.

쿼럼은 클러스터가 온라인 상태로 남아 있는 동안 지속할 수 있는 오류 수를 결정합니다. 쿼럼은 여러 서버가 동시에 리소스 그룹을 호스트하고 동일한 디스크에 쓰기를 시도하지 않도록 클러스터 노드의 하위 집합 간의 통신에 문제가 있는 경우 시나리오를 처리하도록 설계되었습니다. 이러한 쿼럼 개념을 사용하면 클러스터는 특정 리소스 그룹의 실제 소유자가 하나만 있는지 확인하기 위해 노드의 하위 집합 중 하나에서 클러스터 서비스를 강제로 중지합니다. 중지된 노드가 다시 한 번 주 노드 그룹과 통신할 수 있으면 클러스터에 자동으로 다시 가입하고 클러스터 서비스를 시작합니다.

Azure Stack HCI 및 Windows Server 2019에는 고유한 쿼럼 메커니즘이 있는 시스템의 두 가지 구성 요소가 있습니다.

  • 클러스터 쿼럼: 클러스터 수준에서 작동합니다(즉, 노드가 손실되고 클러스터가 계속 작동할 수 있습니다.)
  • 풀 쿼럼: 풀 수준에서 작동합니다(즉, 노드와 드라이브를 잃고 풀을 유지할 수 있습니다). Storage 풀은 클러스터형 및 비클러스터형 시나리오 모두에서 사용하도록 설계되었으므로 다른 쿼럼 메커니즘이 있습니다.

클러스터 쿼럼 개요

아래 표에서는 시나리오당 클러스터 쿼럼 결과에 대한 개요를 제공합니다.

서버 노드 한 번의 서버 노드 오류에서 살아남을 수 있음 서버 노드 오류 한 번, 다른 서버 노드 오류 한 번에서 살아남을 수 있음 두 번의 동시 서버 노드 오류에서 살아남을 수 있음
2 50/50 아니요
2 + 감시 Yes
3 50/50 No
3 + 감시
4 50/50
4 + 감시
5 이상

클러스터 쿼럼 권장 사항

  • 노드가 두 개 있는 경우 감시가 필요합니다.
  • 노드가 3~4개인 경우 미러넷을 사용하는 것이 좋습니다.
  • 인터넷에 액세스할 수 있는 경우 클라우드 감시를 사용합니다.
  • 다른 컴퓨터 및 파일 공유가 있는 IT 환경에 있는 경우 파일 공유 감시를 사용합니다.

클러스터 쿼럼 작동 방식

노드가 실패하거나 일부 노드 하위 집합이 다른 하위 집합과의 접촉을 잃으면 생존 노드는 온라인 상태를 유지하기 위해 클러스터의 대부분을 구성하는지 확인해야 합니다. 확인할 수 없는 경우 오프라인 상태가 됩니다.

그러나 대부분의 개념은 클러스터의 총 노드 수가 홀수인 경우에만 완전히 작동합니다(예: 5개 노드 클러스터의 노드 3개). 그렇다면 노드 수가 짝수인 클러스터(예: 4개 노드 클러스터)는 어떨까요?

클러스터에서 총 투표 수를 홀수 로 만들 수 있는 두 가지 방법이 있습니다.

  1. 첫째, 추가 투표와 증인을 추가하여 하나를 올라갈 수 있습니다. 이를 위해서는 사용자 설정이 필요합니다.
  2. 또는 하나의 불운 노드 투표를 0으로 설정하여 하나 아래로 내려갈 수 있습니다(필요에 따라 자동으로 발생).

생존 노드가 대다수임을 성공적으로 확인할 때마다 대다수 의 정의는 생존자 중 한 명으로 업데이트됩니다. 이렇게 하면 클러스터가 한 노드, 다른 노드, 다른 노드 등을 잃을 수 있습니다. 연속 실패 후 조정되는 총 투표 수 에 대한 이 개념을 동적 쿼럼이라고 합니다.

동적 감시

동적 감시는 총 투표 수가 홀수인지 확인하기 위해 증인의 투표를 전환합니다. 홀수의 투표가 있는 경우 증인은 투표를 하지 않습니다. 짝수의 표가 있는 경우 증인은 투표를 합니다. 동적 감시는 감시 실패로 인해 클러스터가 다운될 위험을 크게 줄입니다. 클러스터는 클러스터에서 사용할 수 있는 투표 노드 수에 따라 미러링 모니터 서버를 사용할지 여부를 결정합니다.

동적 쿼럼은 아래 설명된 방식으로 동적 감시와 함께 작동합니다.

동적 쿼럼 동작

  • 노드 수가 짝수 이고 미러니스가 없는 경우 한 노드가 투표 0을 얻습니다. 예를 들어 4개 노드 중 3개만 표를 얻으므로 총 투표 수는 3표이고, 2명의 생존자는 과반수로 간주됩니다.
  • 수의 노드가 있고 감시가 없으면 모두 표를 얻습니다.
  • 수 개수의 노드와 감시가 있는 경우 감시자가 투표하므로 합계가 홀수입니다.
  • 수의 노드와 감시가 있는 경우 감시는 투표하지 않습니다.

동적 쿼럼을 사용하면 노드에 표를 동적으로 할당하여 과반수의 표를 잃지 않도록 하고 클러스터가 하나의 노드(마지막 사람 대기라고 함)로 실행되도록 할 수 있습니다. 4노드 클러스터를 예로 들어 보겠습니다. 쿼럼에 3표가 필요하다고 가정합니다.

이 경우 두 개의 노드를 분실한 경우 클러스터가 다운되었을 것입니다.

Diagram showing four cluster nodes, each of which gets a vote

그러나 동적 쿼럼은 이러한 상황이 발생하지 않도록 방지합니다. 이제 쿼럼에 필요한 총 투표 수는 사용 가능한 노드 수에 따라 결정됩니다. 따라서 동적 쿼럼을 사용하면 3개의 노드가 손실되더라도 클러스터가 계속 유지됩니다.

Diagram showing four cluster nodes, with nodes failing one at a time, and the number of required votes adjusting after each failure.

위의 시나리오는 저장소 공간 다이렉트 사용하도록 설정되지 않은 일반 클러스터에 적용됩니다. 그러나 저장소 공간 다이렉트 사용하도록 설정된 경우 클러스터는 두 개의 노드 오류만 지원할 수 있습니다. 이 내용은 풀 쿼럼 섹션에서 자세히 설명합니다.

예제

감시가 없는 두 노드

한 노드의 투표는 0이므로 과반수 투표는 총 1표 중에서 결정됩니다. 투표하지 않는 노드가 예기치 않게 다운되면 생존자는 1/1이 되며 클러스터는 유지됩니다. 투표 노드가 예기치 않게 다운되면 생존자는 0/1이 되며 클러스터가 다운됩니다. 투표 노드의 전원이 정상적으로 끊어지면 투표는 다른 노드로 전송되고 클러스터는 유지됩니다. 이것이 감시를 구성하는 것이 중요한 이유입니다.

Quorum explained in the case with two nodes without a witness

  • 하나의 서버 오류에서 살아남을 수 있습니다. 50% 확률.
  • 한 서버 오류에서 살아남을 수 있고 다른 서버 오류는 살아남을 수 있습니다. 아니요.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. 아니요.

감시가 있는 두 개의 노드

두 노드 모두 투표와 증인 투표를 합하여 과반수 가 총 3표 중에서 결정됩니다. 두 노드 중 하나가 다운되면 생존자는 2/3이고 클러스터는 유지됩니다.

Quorum explained in the case with two nodes with a witness

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있고 다른 서버 오류는 살아남을 수 있습니다. 아니요.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. 아니요.

감시가 없는 3개의 노드

모든 노드가 투표하므로 과반수 는 총 3표 중에서 결정됩니다. 노드가 다운되면 생존자는 2/3이고 클러스터는 유지됩니다. 클러스터는 감시 없이 두 개의 노드가 됩니다. 이 시점에서 시나리오 1에 있습니다.

Quorum explained in the case with three nodes without a witness

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 그런 다음, 50%의 확률로 살아남을 수 있습니다.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. 아니요.

감시가 있는 3개의 노드

모든 노드가 투표하므로 미러는 처음에 투표하지 않습니다. 과반수는 총 3표 중 3표로 결정된다. 한 번의 실패 후 클러스터에는 미러니스가 있는 두 개의 노드가 있으며, 이 노드는 시나리오 2로 돌아갑니다. 이제 두 노드와 감시자가 투표합니다.

Quorum explained in the case with three nodes with a witness

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 그런 다음 다른 서버 오류를 살아남을 수 있습니다. 예.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. 아니요.

감시가 없는 4개의 노드

한 노드의 투표는 0이므로 과반수 는 총 3표 중에서 결정됩니다. 한 번의 실패 후 클러스터는 3개의 노드가 되고 시나리오 3에 있습니다.

Quorum explained in the case with four nodes without a witness

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 그런 다음 다른 서버 오류를 살아남을 수 있습니다. 예.
  • 한 번에 두 개의 서버 오류인 50%의 확률로 살아남을 수 있습니다.

감시가 있는 4개의 노드

모든 노드가 투표하고 증인 투표를 하므로 과반수 는 총 5표 중에서 결정됩니다. 한 번의 실패 후 시나리오 4에 있습니다. 두 번의 동시 오류가 발생한 후 시나리오 2로 건너뜁니다.

Quorum explained in the case with four nodes with a witness

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 그런 다음 다른 서버 오류를 살아남을 수 있습니다. 예.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. .

5개 노드 이상

모든 노드가 투표하거나 한 표를 제외한 모든 노드가 총 투표를 이상하게 만듭니다. 저장소 공간 다이렉트 두 개 이상의 노드를 처리할 수 없으므로 이 시점에서 감시가 필요하거나 유용하지 않습니다.

Quorum explained in the case with five nodes and beyond

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 그런 다음 다른 서버 오류를 살아남을 수 있습니다. 예.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. .

이제 쿼럼의 작동 방식을 이해했으므로 쿼럼 감시 유형을 살펴보겠습니다.

쿼럼 감시 형식

장애 조치(failover) 클러스터링에서는 다음 세 가지 유형의 쿼럼 감시를 지원합니다.

  • Cloud Witness - 클러스터의 모든 노드에서 액세스할 수 있는 Azure의 Blob Storage입니다. 이는 witness.log 파일에 클러스터링 정보를 유지하지만 클러스터 데이터베이스의 복사본은 저장하지 않습니다.
  • 파일 공유 감시 – Windows Server를 실행하는 파일 서버에 구성된 SMB 파일 공유입니다. 이는 witness.log 파일에 클러스터링 정보를 유지하지만 클러스터 데이터베이스의 복사본은 저장하지 않습니다.
  • 디스크 감시 - 클러스터 사용 가능한 Storage 그룹에 있는 작은 클러스터형 디스크입니다. 이 디스크는 고가용성이며 노드 간에 장애 조치(failover)할 수 있습니다. 클러스터 데이터베이스의 복사본을 포함합니다. 디스크 감시는 저장소 공간 다이렉트 지원되지 않습니다.

풀 쿼럼 개요

클러스터 수준에서 작동하는 클러스터 쿼럼에 대해 설명했습니다. 이제 풀 수준에서 작동하는 풀 쿼럼(예: 노드와 드라이브를 잃고 풀이 유지되도록 할 수 있습니다)을 살펴보겠습니다. Storage 풀은 클러스터형 및 비클러스터형 시나리오 모두에서 사용하도록 설계되었으므로 다른 쿼럼 메커니즘이 있습니다.

아래 표에서는 시나리오당 풀 쿼럼 결과에 대한 개요를 제공합니다.

서버 노드 한 번의 서버 노드 오류에서 살아남을 수 있음 서버 노드 오류 한 번, 다른 서버 노드 오류 한 번에서 살아남을 수 있음 두 번의 동시 서버 노드 오류에서 살아남을 수 있음
2 아니요 아니요
2 + 감시 Yes
3
3 + 감시
4
4 + 감시
5 이상

풀 쿼럼 작동 방식

드라이브가 실패하거나 드라이브의 일부 하위 집합이 다른 하위 집합과의 접촉을 잃으면 생존 드라이브가 온라인 상태를 유지하기 위해 풀의 대부분을 구성하는지 확인해야 합니다. 확인할 수 없는 경우 오프라인 상태가 됩니다. 풀은 오프라인 상태가 되거나 쿼럼에 충분한 디스크가 있는지 여부에 따라 온라인 상태로 유지되는 엔터티입니다(50% + 1). 풀 리소스 소유자(활성 클러스터 노드)는 +1일 수 있습니다.

그러나 풀 쿼럼은 다음과 같은 방법으로 클러스터 쿼럼과 다르게 작동합니다.

  • 풀은 클러스터의 한 노드를 연결 차단기로 감시로 사용하여 드라이브의 절반(풀 리소스 소유자인 이 노드)을 유지합니다.
  • 풀에 동적 쿼럼이 없습니다.
  • 풀은 투표를 제거하는 자체 버전을 구현하지 않습니다.

예제

대칭 레이아웃이 있는 4개의 노드

각 16개 드라이브에는 하나의 투표가 있고 노드 2에는 하나의 투표도 있습니다(풀 리소스 소유자이기 때문에). 과반수는 총 16표 중에서 결정된다. 노드 3과 4가 다운되면 생존 하위 집합에는 8개의 드라이브와 9/16 투표인 풀 리소스 소유자가 있습니다. 그래서, 수영장은 살아남는다.

Pool Quorum 1

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 그런 다음 다른 서버 오류를 살아남을 수 있습니다. 예.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. .

대칭 레이아웃 및 드라이브 오류가 있는 4개의 노드

각 16개 드라이브에는 하나의 투표가 있고 노드 2에는 하나의 투표도 있습니다(풀 리소스 소유자이기 때문에). 과반수는 총 16표 중에서 결정된다. 첫째, 드라이브 7이 다운됩니다. 노드 3과 4가 다운되면 생존 하위 집합에는 드라이브 7개와 풀 리소스 소유자(8/16 투표)가 있습니다. 따라서 수영장은 과반수를 차지하지 않고 아래로 내려갑니다.

Pool Quorum 2

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있고 다른 서버 오류는 살아남을 수 있습니다. 아니요.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. 아니요.

비대칭 레이아웃이 있는 4개의 노드

각 24개 드라이브에는 하나의 투표가 있고 노드 2에는 하나의 투표도 있습니다(풀 리소스 소유자이기 때문에). 과반수는 총 24표 중에서 결정된다. 노드 3과 4가 다운되면 생존 하위 집합에는 8개의 드라이브와 9/24 표의 풀 리소스 소유자가 있습니다. 따라서 수영장은 과반수를 차지하지 않고 아래로 내려갑니다.

Pool Quorum 3

  • 하나의 서버 오류에서 살아남을 수 있습니다. .
  • 한 서버 오류에서 살아남을 수 있습니다. 다른 서버 오류: 종속성 (노드 3과 4가 모두 다운된 경우 살아남을 수 없지만 다른 모든 시나리오에서 살아남을 수 있습니다.
  • 두 서버 오류를 한 번에 확인할 수 있습니다. 종속성 (노드 3과 4가 모두 다운된 경우 살아남을 수 없지만 다른 모든 시나리오에서 살아남을 수 있습니다.

풀 쿼럼 권장 사항

  • 클러스터의 각 노드가 대칭인지 확인합니다(각 노드의 드라이브 수는 동일).
  • 노드 오류를 허용하고 가상 디스크를 온라인 상태로 유지할 수 있도록 3방향 미러 또는 이중 패리티를 사용하도록 설정합니다.
  • 두 개 이상의 노드가 다운되거나 두 개 이상의 노드와 다른 노드의 디스크가 다운된 경우 볼륨은 데이터의 세 복사본 모두에 액세스할 수 없으므로 오프라인으로 전환되어 사용할 수 없습니다. 볼륨의 모든 데이터에 대한 복원력을 극대화하려면 서버를 다시 가져오거나 디스크를 신속하게 교체하는 것이 좋습니다.

다음 단계

자세한 내용은