HCI 클러스터에서 노드 한 대가 갑자기 응답하지 않는다면 어떻게 될까요? 실제 서버 장애일 수도 있고, 노드 간 네트워크 연결만 끊어진 상황일 수도 있습니다. 나머지 노드들은 장애가 발생한 서버의 상태를 정확히 알기 어렵습니다.

이런 상황에서 클러스터가 어떤 노드의 판단을 신뢰할지 결정하는 기준이 쿼럼(Quorum)입니다. 쿼럼이 제대로 유지되지 않으면 스플릿 브레인(Split-Brain)이라는 심각한 문제가 발생할 수 있습니다.

특히 2노드·3노드 HCI 구성과 고가용성(HA)을 검토하고 있다면 두 개념을 반드시 이해해야 합니다.

쿼럼이란? 클러스터 운영을 위한 과반수의 동의

쿼럼은 클러스터가 중요한 작업을 수행할 때 필요한 최소 투표 수를 의미합니다. 일반적인 다수결과 마찬가지로 전체 투표권의 과반수를 확보해야 합니다.

SmartECM의 기반 기술인 Proxmox VE는 Corosync를 사용해 노드 간 통신과 클러스터 멤버십을 관리합니다. 기본적으로 각 노드는 1개의 투표권을 갖습니다.

예를 들어 3노드 클러스터에서는 2표 이상을 확보해야 쿼럼이 성립합니다.

이처럼 홀수 개의 투표권을 사용하면 과반수를 판단하기 쉽고, 일부 노드가 장애를 일으켜도 나머지 노드가 클러스터 운영을 이어갈 수 있습니다.

스플릿 브레인은 왜 위험할까?

스플릿 브레인은 클러스터가 네트워크 장애 등으로 분리되어 서로 다른 그룹이 자신을 정상적인 운영 주체로 판단하는 상황을 말합니다.

예를 들어 노드 A와 B가 같은 VM의 디스크를 공유하고 있다고 가정해 보겠습니다. 두 노드 사이의 통신이 끊어졌을 때, 각각 상대방이 장애를 일으켰다고 판단해 동일한 VM을 동시에 실행한다면 문제가 발생합니다.

두 서버가 같은 데이터를 동시에 수정하면서 파일시스템 손상이나 데이터 불일치가 발생할 수 있기 때문입니다.

쿼럼은 이러한 상황을 방지하기 위한 핵심 장치입니다. 과반수를 확보하지 못한 쪽은 클러스터 상태를 변경하는 작업이 제한됩니다.

3노드 HCI에서 서버 한 대가 장애를 일으킨다면?

3노드 클러스터에서 A, B, C가 각각 1표를 갖고 있다고 가정하겠습니다.

정상 상태에서는 3표를 모두 확보합니다. 그런데 노드 C가 장애를 일으키거나 네트워크에서 분리되면 어떻게 될까요?

노드 A와 B는 2표를 확보했으므로 정상적인 클러스터 운영을 이어갈 수 있습니다. 반면 분리된 노드 C는 혼자서 과반수를 확보하지 못하므로 클러스터 설정 변경 등이 제한됩니다.

HA로 관리되는 VM이 노드 C에서 실행 중이었다면, HA 시스템은 원래 노드에서 해당 VM이 더 이상 실행되지 않도록 확인한 뒤 다른 노드에서 재시작하는 절차를 수행할 수 있습니다.

이때 중요한 것이 펜싱(Fencing)입니다. 펜싱은 장애가 발생하거나 고립된 노드가 기존 VM을 계속 실행하지 못하도록 차단하는 메커니즘입니다. Proxmox VE의 HA는 워치독을 활용한 자체 펜싱 방식을 사용합니다.

2노드 HCI에서는 왜 큐디바이스가 필요할까?

2노드 클러스터에서는 두 서버가 각각 1표씩 갖습니다. 전체 2표 중 과반수를 확보하려면 2표가 모두 필요합니다.

따라서 노드 한 대가 장애를 일으키면 남은 노드는 1표만 확보하게 됩니다. 쿼럼을 유지할 수 없으므로 정상적인 HA 운영에 제약이 생깁니다.

이를 보완하기 위해 사용하는 것이 큐디바이스(QDevice)입니다.

큐디바이스는 클러스터 외부의 별도 서버에서 투표에 참여하는 장치입니다. Proxmox VE에서는 Corosync의 corosync-qnetd를 활용해 구성할 수 있습니다.

노드 A에 장애가 발생하더라도 노드 B와 큐디바이스가 통신할 수 있다면 2표를 확보해 쿼럼을 유지할 수 있습니다.

두 노드 사이의 통신만 끊어졌을 때도 큐디바이스는 정해진 투표 알고리즘에 따라 한쪽에만 투표권을 부여하여 양쪽이 동시에 쿼럼을 확보하는 상황을 방지합니다.

큐디바이스를 추가하면 HA가 완성될까?

큐디바이스는 클러스터의 투표에 참여할 뿐, VM을 실행하거나 데이터를 저장하는 역할을 하지 않습니다.

따라서 큐디바이스를 추가했다고 해서 VM의 자동 복구나 데이터 이중화가 완성되는 것은 아닙니다.

실제 HA를 구현하려면 장애 이후에도 다른 노드가 VM 디스크에 접근할 수 있어야 하고, VM을 실행할 CPU·메모리 자원도 확보해야 합니다.

예를 들어 ZFS Replication을 사용하는 경우 다른 노드에 복제된 데이터를 활용해 VM을 복구할 수 있지만, 비동기 복제 특성상 마지막 동기화 이후의 데이터는 유실될 수 있습니다.

큐디바이스 서버 자체가 장애를 일으키거나 생존 노드와 통신할 수 없는 경우에도 쿼럼 유지에 영향을 받을 수 있습니다. 따라서 큐디바이스는 두 클러스터 노드의 장애와 독립적인 위치에 두고 네트워크 연결을 안정적으로 유지해야 합니다.

Ceph에도 별도의 쿼럼이 있습니다

Ceph 기반 HCI에서는 한 가지를 더 구분해야 합니다. 클러스터 관리용 쿼럼과 Ceph 스토리지 쿼럼은 별개입니다.

Corosync 쿼럼은 클러스터의 멤버십과 운영 권한을 판단하고, Ceph 쿼럼은 모니터(MON)들이 스토리지 상태 정보를 일관되게 관리하기 위해 사용합니다.

즉, 2노드와 큐디바이스로 Corosync 쿼럼을 확보하더라도 Ceph 스토리지의 가용성이 자동으로 보장되는 것은 아닙니다. Ceph는 모니터 쿼럼과 데이터 복제 정책, OSD 가용성을 별도로 충족해야 합니다.

실제 운영에서 확인해야 할 쿼럼 상태

SmartECM과 같은 Proxmox VE 기반 환경에서는 다음 명령어로 클러스터의 쿼럼 상태를 확인할 수 있습니다.

1. Corosync 쿼럼 상태 확인

pvecm status

전체 투표권, 현재 확보한 투표권, 필요한 쿼럼 수, 클러스터의 쿼럼 충족 여부를 확인할 수 있습니다. 큐디바이스를 사용하는 경우 관련 상태도 함께 표시됩니다.

2. 클러스터 노드 확인

pvecm nodes

현재 클러스터 멤버십에 포함된 노드 정보를 확인할 수 있습니다. 정상적으로 통신하지 못하는 노드가 있다면 네트워크 및 Corosync 로그를 추가로 점검해야 합니다.

3. Ceph 상태 확인

ceph -s
ceph quorum_status

Ceph를 사용하는 환경에서는 스토리지 상태와 모니터 쿼럼을 함께 확인합니다. 가상화 클러스터의 쿼럼이 정상이어도 Ceph에서 별도의 장애가 발생할 수 있기 때문입니다.

쿼럼을 잃은 상황에서 강제로 투표 기준을 변경하는 명령은 운영 중인 클러스터의 데이터 안전성에 영향을 줄 수 있습니다. 장애 원인을 확인하고 펜싱과 스토리지 상태를 검증하기 전에는 임의로 쿼럼 기준을 낮추지 않아야 합니다.

SmartECM에서 쿼럼이 중요한 이유

SmartECM은 KVM 기반 가상화와 클러스터 운영을 지원하는 프라이빗 클라우드 플랫폼입니다. 3노드 이상 HCI 클러스터뿐 아니라 운영 목적에 따라 2노드와 큐디바이스를 활용하는 구성도 검토할 수 있습니다.

이때 쿼럼은 단순히 노드가 몇 대 연결되어 있는지 확인하는 기능이 아닙니다. 장애 발생 시 어느 노드가 클러스터 운영을 지속할 수 있는지 판단하고, 서로 다른 노드가 동일한 VM을 잘못 제어하는 상황을 방지하는 중요한 기반입니다.

따라서 SmartECM 기반 HCI를 설계할 때도 노드 수와 투표권, Corosync 네트워크, HA, 스토리지의 가용성을 함께 검토해야 합니다.

안정적인 HCI 운영은 쿼럼 설계에서 시작됩니다

HCI 클러스터에서 서버를 여러 대 연결했다고 해서 장애 대응이 자동으로 완성되는 것은 아닙니다. 노드 간 통신이 끊어졌을 때 어느 쪽이 정상적인 운영 권한을 갖는지, 장애가 발생한 VM을 어디에서 다시 실행할 수 있는지 판단할 수 있어야 합니다.

쿼럼은 클러스터의 일관성을 유지하고 스플릿 브레인 위험을 줄이는 핵심 원리입니다. 3노드 구성에서는 과반수 투표로 장애에 대응하고, 2노드 환경에서는 큐디바이스를 통해 부족한 투표권을 보완할 수 있습니다.

안정적인 HA 운영을 위해서는 쿼럼뿐 아니라 펜싱, 스토리지 접근성, 자원 여유, 네트워크 이중화까지 함께 설계하고 실제 장애 테스트로 검증하는 것이 중요합니다.