다음을 통해 공유


클러스터 및 풀 쿼럼의 이해

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

Important

Azure Stack HCI는 이제 Azure Local의 일부입니다. 제품 설명서 이름 바꾸기가 진행 중입니다. 그러나 이전 버전의 Azure Stack HCI(예: 22H2)는 Azure Stack HCI를 계속 참조하며 이름 변경 내용이 반영되지 않습니다. 자세히 알아보기.

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

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

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

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

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

클러스터 쿼럼 개요

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

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

클러스터 쿼럼 권장 사항

  • 두 개의 노드가 있는 경우 감시가 필요합니다.
  • 노드가 3개 또는 4개인 경우 감시를 사용하는 것이 좋습니다.
  • 5개 이상의 노드가 있는 경우 감시가 필요하지 않으며 추가 복원력을 제공하지 않습니다.
  • 인터넷에 액세스할 수 있는 경우 클라우드 감시사용합니다.
  • 다른 컴퓨터 및 파일 공유가 있는 IT 환경에 있는 경우 파일 공유 감시를 사용합니다.

클러스터 쿼럼 작동 방식

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

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

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

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

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

동적 감시

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

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

동적 쿼럼 동작

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

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

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

각각 투표를 받는 4개의 클러스터 노드를 보여 주는 다이어그램.

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

노드가 한 번에 하나씩 실패하고 각 실패 후 필요한 투표 수가 조정되는 4개의 클러스터 노드를 보여 주는 다이어그램.

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

예제

미러된 모니터 서버가 없는 두 노드

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

쿼럼은 감시 없이 두 개의 노드가 있는 경우 설명합니다.

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

미러된 모니터 서버가 있는 두 노드

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

쿼럼은 감시가 있는 두 개의 노드가 있는 경우 설명합니다.

  • 한 번의 서버 오류 에서 살아남을 수 있습니다. 예.
  • 한 서버 오류에서 살아남을 수 있고 다른 서버 오류는 살아남을 수 있습니다. 아니요.
  • 두 개의 서버 오류를 한 번에 살아남을 수 있습니다. 아니요.

미러된 모니터 서버가 없는 3개 노드

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

쿼럼은 감시 없이 3개의 노드가 있는 경우 설명합니다.

  • 한 번의 서버 오류 에서 살아남을 수 있습니다. 예.
  • 한 서버 오류에서 살아남을 수 있고, 그 다음에는 50%의 확률로 살아남을 수 있습니다.
  • 두 개의 서버 오류를 한 번에 살아남을 수 있습니다. 아니요.

미러된 모니터 서버가 있는 3개 노드

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

쿼럼은 감시가 있는 3개의 노드가 있는 경우 설명합니다.

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

미러된 모니터 서버가 없는 4개 노드

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

쿼럼은 감시 없이 4개의 노드가 있는 경우 설명합니다.

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

감시가 있는 4개의 노드

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

쿼럼은 감시가 있는 4개의 노드가 있는 경우 설명합니다.

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

5개 노드 이상

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

쿼럼은 5개 이상의 노드가 있는 경우 설명합니다.

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

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

쿼럼 감시 유형

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

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

풀 쿼럼 개요

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

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

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

풀 쿼럼 작동 방식

드라이브가 실패하거나 드라이브의 일부 하위 집합이 다른 하위 집합과 접촉하지 못하는 경우 메타데이터를 호스팅하는 지속형 드라이브는 대부분의 풀이 온라인 상태를 유지하는지 확인해야 합니다. 확인할 수 없는 경우 오프라인으로 전환됩니다. 풀은 오프라인 상태가 되거나 쿼럼에 충분한 디스크가 있는지 여부에 따라 온라인 상태로 유지되는 엔터티입니다(50% + 1). 클러스터 데이터베이스는 클러스터 자체가 쿼레이트인 한 +1일 수 있습니다.

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

  • 풀이 메타데이터를 호스트할 노드당 드라이브의 하위 집합을 선택합니다.
  • 풀은 클러스터 데이터베이스를 사용하여 관계를 끊습니다.
  • 풀에 동적 쿼럼이 없습니다.
  • 풀은 투표를 제거하는 자체 버전을 구현하지 않습니다.

예제

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

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

풀 쿼럼 1.

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

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

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

풀 쿼럼 2.

  • 한 번의 서버 오류 에서 살아남을 수 있습니다. 예.
  • 한 서버 오류에서 살아남을 수 있고 다른 서버 오류는 살아남을 수 있습니다. 아니요.
  • 두 개의 서버 오류를 한 번에 살아남을 수 있습니다. 아니요.

풀 쿼럼 권장 사항

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

다음 단계