적용 대상: Azure Stack HCI, 버전 22H2 및 21H2; 윈도우 서버 2022, 윈도우 서버
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개인 경우 witness를 사용하는 것이 좋습니다.
- 노드가 5개 이상인 경우 미러링 모니터가 필요하지 않으며 추가 복원력을 제공하지 않습니다.
- 인터넷에 액세스할 수 있는 경우 클라우드 감시를 사용합니다.
- 다른 컴퓨터 및 파일 공유가 있는 IT 환경에 있는 경우 파일 공유 감시를 사용합니다.
클러스터 쿼럼의 작동 방식
노드에 장애가 발생하거나 노드의 일부 하위 집합이 다른 하위 집합과의 연결이 끊어지면 살아남은 노드는 온라인 상태를 유지하기 위해 클러스터의 대부분 을 구성하는지 확인해야 합니다. 확인할 수 없는 경우 오프라인 상태가 됩니다.
그러나 다수결 의 개념은 클러스터의 총 노드 수가 홀수인 경우(예: 5노드 클러스터의 3개 노드)에만 명확하게 작동합니다. 그렇다면, 짝수 개의 노드가 있는 클러스터(예: 4개의 노드 클러스터)는 어떨까요?
클러스터가 총 투표 수를 홀수로 만들 수 있는 두 가지 방법이 있습니다.
- 첫째, 추가 투표와 함께 증인을 추가하여 한 표 올라갈 수 있습니다. 이를 위해서는 사용자 설정이 필요합니다.
- 또는 하나의 불운한 노드의 투표를 0으로 만들어 1 다운 될 수 있습니다(필요에 따라 자동으로 발생).
살아남은 노드가 다수임을 성공적으로 확인할 때마다 다수 결의 정의는 살아남은 노드만 포함하도록 업데이트됩니다. 이렇게 하면 클러스터가 한 노드, 다른 노드, 다른 노드 등을 잃을 수 있습니다. 연속적인 실패 후에 조정되는 총 투표 수에 대한 이러한 개념을 동적 쿼럼이라고 합니다.
동적 증인
동적 증인은 증인의 투표를 전환하여 총 투표 수가 홀수인지 확인합니다. 표가 홀수인 경우 증인은 투표권을 갖지 못합니다. 표가 짝수이면 증인이 투표권을 갖습니다. 동적 감시는 감시 실패로 인해 클러스터가 다운될 위험을 크게 줄입니다. 클러스터는 클러스터에서 사용할 수 있는 투표 노드의 수에 따라 감시 투표를 사용할지 여부를 결정합니다.
동적 쿼럼은 아래에 설명된 방식으로 동적 증인과 함께 작동합니다.
동적 쿼럼 동작
- 짝수 개의 노드가 있고 감시 서버가 없는 경우 한 노드의 투표가 0이 됩니다. 예를 들어, 4개의 노드 중 3개만 표를 얻었으므로 총 투표 수는 3표가 되고 표를 가진 2명의 생존자가 과반수로 간주됩니다.
- 홀수 개의 노드가 있고 증인이 없는 경우 모두 투표를 받습니다.
- 짝수 개의 노드와 증인이 있는 경우 증인이 투표하므로 합계는 홀수입니다.
- 홀수 개의 노드와 증인이 있는 경우 증인은 투표하지 않습니다.
동적 쿼럼을 사용하면 노드에 투표를 동적으로 할당하여 과반수 투표를 잃지 않고 클러스터가 하나의 노드(last-man standing이라고 함)로 실행될 수 있습니다. 4노드 클러스터를 예로 들어 보겠습니다. 쿼럼에 3표가 필요하다고 가정합니다.
이 경우 두 개의 노드가 손실되면 클러스터가 다운되었을 것입니다.
그러나 동적 쿼럼은 이러한 일이 발생하지 않도록 합니다. 쿼럼에 필요한 총 투표 수는 이제 사용 가능한 노드 수에 따라 결정됩니다. 따라서 동적 쿼럼을 사용하면 세 개의 노드가 손실되더라도 클러스터가 계속 유지됩니다.
위의 시나리오는 저장소 공간 다이렉트 사용하도록 설정되지 않은 일반 클러스터에 적용됩니다. 그러나 저장소 공간 다이렉트 사용하도록 설정하면 클러스터는 두 개의 노드 오류만 지원할 수 있습니다. 이에 대해서는 풀 쿼럼 섹션에 자세히 설명되어 있습니다.
예시
미러링 모니터 서버가 없는 두 개의 노드
한 노드의 표는 0이 되므로 총 1표 중에서 과반수 득표가 결정됩니다. 투표하지 않는 노드가 예기치 않게 다운되면 생존자는 1/1을 갖고 클러스터는 살아남습니다. 투표 노드가 예기치 않게 다운되면 생존자는 0/1을 가지며 클러스터는 다운됩니다. 투표 노드의 전원이 정상적으로 꺼지면 투표가 다른 노드로 전송되고 클러스터는 유지됩니다. 따라서 미러링 모니터 서버를 구성하는 것이 중요합니다.
- 한 번의 서버 장애에서 살아남을 수 있습니다 : 50 % 확률.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애를 견딜 수 있음: 아니요.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 아니요.
미러링 모니터 서버가 있는 두 개의 노드
두 노드 모두 투표하고 증인 투표가 진행되므로 총 3표 중에서 과반수가 결정됩니다. 노드 중 하나라도 다운되면 생존자는 2/3를 가지며 클러스터는 살아남습니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애를 견딜 수 있음: 아니요.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 아니요.
미러링 모니터 서버가 없는 3개의 노드
모든 노드가 투표하므로 총 3표 중 과반수가 결정됩니다. 노드가 다운되면 생존자는 2/3가 되고 클러스터는 살아남습니다. 클러스터는 미러링 모니터 서버가 없는 두 개의 노드가 되며, 이 시점에서 시나리오 1에 있습니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 실패에서 살아남을 수 있고, 또 다른 서버 실패에서 살아남을 수 있습니다 : 50 % 확률.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 아니요.
미러링 모니터 서버가 있는 3개의 노드
모든 노드가 투표하므로 증인이 처음에 투표하지 않습니다. 총 3표 중에서 과반수가 결정됩니다. 한 번의 실패 후 클러스터에는 미러링 모니터 서버가 있는 두 개의 노드가 있으며, 이는 시나리오 2로 돌아갑니다. 이제 두 노드와 증인 투표가 진행됩니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애에서도 살아남을 수 있습니다 : 예.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 아니요.
미러링 모니터 서버가 없는 노드 4개
한 노드의 표는 0이므로 총 3표 중에서 과반수가 결정됩니다. 한 번의 실패 후 클러스터는 3개의 노드가 되고 시나리오 3에 있습니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애에서도 살아남을 수 있습니다 : 예.
- 한 번에 두 개의 서버 장애에서 살아남을 수 있음: 50% 확률.
미러링 모니터 서버가 있는 4개의 노드
모든 노드가 투표하고 증인이 투표하므로 총 5표 중 과반수가 결정됩니다. 한 번의 실패 후에는 시나리오 4에 있습니다. 두 번의 동시 오류가 발생하면 시나리오 2로 건너뜁니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애에서도 살아남을 수 있습니다 : 예.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 예.
5개 노드 이상
모든 노드 투표 또는 한 표를 제외한 모든 투표, 총계를 홀수로 만드는 것이 무엇이든 상관없습니다. 저장소 공간 다이렉트 어쨌든 두 개 이상의 노드를 처리할 수 없으므로 이 시점에서는 증인이 필요하거나 유용하지 않습니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애에서도 살아남을 수 있습니다 : 예.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 예.
이제 쿼럼의 작동 방식을 이해했으므로 쿼럼 증인의 유형을 살펴보겠습니다.
쿼럼 감시자 유형
장애 조치(failover) 클러스터링은 세 가지 유형의 쿼럼 증인을 지원합니다.
- Cloud Witness - 클러스터의 모든 노드에서 액세스할 수 있는 Azure의 Blob Storage입니다. 이는 witness.log 파일에 클러스터링 정보를 유지하지만 클러스터 데이터베이스의 복사본은 저장하지 않습니다.
- 파일 공유 감시 – Windows Server를 실행하는 파일 서버에 구성된 SMB 파일 공유입니다. 이는 witness.log 파일에 클러스터링 정보를 유지하지만 클러스터 데이터베이스의 복사본은 저장하지 않습니다.
- 디스크 감시 - 사용 가능한 클러스터 스토리지 그룹에 있는 작은 클러스터된 디스크입니다. 이 디스크는 가용성이 높으며 노드 간에 장애 조치(failover)할 수 있습니다. 여기에는 클러스터 데이터베이스의 복사본이 포함되어 있습니다. 디스크 감시는 스토리지 공간 다이렉트에서 지원되지 않습니다.
풀 쿼럼 개요
방금 클러스터 수준에서 작동하는 클러스터 쿼럼에 대해 이야기했습니다. 이제 풀 수준에서 작동하는 풀 쿼럼에 대해 알아보겠습니다(즉, 노드와 드라이브를 잃고 풀을 계속 유지할 수 있음). 스토리지 풀은 클러스터된 시나리오와 클러스터되지 않은 시나리오 모두에서 사용하도록 설계되었기 때문에 쿼럼 메커니즘이 다릅니다.
아래 표는 시나리오별 풀 쿼럼 결과에 대한 개요를 제공합니다.
| 서버 노드 | 한 번의 서버 노드 오류에서 살아남을 수 있음 | 서버 노드 오류 한 번, 다른 서버 노드 오류 한 번에서 살아남을 수 있음 | 두 번의 동시 서버 노드 오류에서 살아남을 수 있음 |
|---|---|---|---|
| 2 | 예 | 아니오 | 아니오 |
| 2 + 증인 | 예 | 아니오 | 아니오 |
| 3 | 예 | 아니오 | 아니오 |
| 3 + 증인 | 예 | 아니오 | 아니오 |
| 4 | 예 | 아니오 | 아니오 |
| 4 + 증인 | 예 | 예 | 예 |
| 5 이상 | 예 | 예 | 예 |
풀 쿼럼의 작동 방식
드라이브에 오류가 발생하거나 드라이브의 일부 하위 집합이 다른 하위 집합과의 연결이 끊어지면 메타데이터를 호스팅하는 남아 있는 드라이브는 온라인 상태로 유지될 풀의 대부분 을 구성하는지 확인해야 합니다. 확인할 수 없는 경우 오프라인 상태가 됩니다. 풀은 쿼럼에 충분한 디스크가 있는지 여부에 따라 오프라인 상태가 되거나 온라인 상태로 유지되는 엔터티입니다(50% + 1). 클러스터 데이터베이스는 클러스터 자체가 quorate인 한 +1이 될 수 있습니다.
그러나 풀 쿼럼은 다음과 같은 방식으로 클러스터 쿼럼과 다르게 작동합니다.
- 풀은 메타데이터를 호스팅할 노드당 드라이브의 하위 집합을 선택합니다
- 풀은 클러스터 데이터베이스를 사용하여 연결을 끊습니다
- 풀에 동적 쿼럼이 없습니다.
- 풀은 투표를 제거하는 자체 버전을 구현하지 않습니다
예시
대칭 레이아웃이 있는 4개의 노드
16개의 드라이브 각각에는 1표가 있고 노드 2에는 1표가 있습니다(풀 리소스 소유자이기 때문에). 총 16표 중에서 과반수가 결정됩니다. 노드 3과 4가 다운되면 남아 있는 하위 집합에는 8개의 드라이브와 풀 리소스 소유자(9/16 투표)가 있습니다. 그래서 수영장은 살아남습니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애에서도 살아남을 수 있습니다 : 예.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 예.
대칭 레이아웃과 드라이브 장애가 있는 4개의 노드
16개의 드라이브 각각에는 하나의 투표권이 있고 노드 2에도 하나의 투표권이 있습니다(풀 리소스 소유자이기 때문에). 총 16표 중에서 과반수가 결정됩니다. 먼저 드라이브 7이 내려갑니다. 노드 3과 4가 다운되면 남아 있는 하위 집합에는 7개의 드라이브와 풀 리소스 소유자(8/16 투표)가 있습니다. 따라서 풀은 과반수를 갖지 못하고 내려갑니다.
- 한 번의 서버 장애에서 살아남을 수 있음: 예.
- 한 번의 서버 장애에서 살아남을 수 있고 다른 서버 장애를 견딜 수 있음: 아니요.
- 한 번에 두 개의 서버 장애를 견딜 수 있음: 아니요.
풀 쿼럼 권장 사항
- 클러스터의 각 노드가 대칭인지 확인합니다(각 노드에 동일한 수의 드라이브가 있음).
- 3방향 미러 또는 이중 패리티를 활성화하여 두 개의 노드 장애를 허용하고 가상 디스크를 온라인 상태로 유지할 수 있습니다.
- 세 개 이상의 노드가 다운되거나 두 개의 노드와 다른 노드의 디스크가 다운된 경우 볼륨은 세 개의 데이터 복사본 모두에 액세스하지 못할 수 있으므로 오프라인 상태가 되어 사용할 수 없게 됩니다. 볼륨의 모든 데이터에 대한 복원력을 극대화하기 위해 서버를 다시 가져오거나 디스크를 신속하게 교체하는 것이 좋습니다.