테크 랩

중소기업 자체 클라우드 구축 – 03. Proxmox 3노드 클러스터 구성

2026.07.07

지난 글(02. Proxmox 네트워크 망분리 설계)에서 관리망·서비스망·Ceph망·Corosync 경로를 모두 확정했습니다. 밑그림이 완성됐으니 이번 글에서는 그 위에 3노드 클러스터를 실제로 묶습니다. 한 노드에서 클러스터를 만들고 나머지를 합류시키는 과정, 클러스터가 정상을 판단하는 기준인 쿼럼(quorum), 그리고 Corosync 이중화가 실제로 동작하는지 검증하는 데까지 다룹니다.

이번 글의 목표

이 편이 끝나면 다음 상태가 됩니다.

pve11/12/13 세 노드가 하나의 클러스터로 묶임
어느 노드의 웹 UI로 접속해도 세 노드가 모두 보임
쿼럼(Quorate) 상태가 정상으로 확인됨
Corosync Ring0(관리망) + Ring1(Ceph망) 이중화가 동작 확인됨

클러스터를 묶기 전에 02번에서 정리한 시간 동기화(NTP)가 반드시 끝나 있어야 합니다. 노드 간 시계가 어긋난 상태로 클러스터를 만들면 곧바로 쿼럼이 깨집니다. chronyc sources로 세 노드 모두 동기화됐는지 다시 한번 확인하고 시작하세요.

클러스터의 핵심 개념 — 쿼럼(Quorum)

명령을 치기 전에 쿼럼 개념을 먼저 잡고 가야 합니다. 이게 왜 3노드인지를 설명해주는 핵심입니다.

클러스터는 “지금 클러스터가 정상인가”를 과반수 투표로 판단합니다. 각 노드가 한 표씩 가지고, 살아 있는 노드의 표가 전체의 과반을 넘어야 클러스터가 정상(Quorate)으로 동작합니다. 과반에 못 미치면(Inquorate) 클러스터는 안전을 위해 스스로 기능을 멈춥니다.

3노드라면 전체 표가 3표, 과반은 2표입니다. 그래서 한 노드가 죽어도 남은 두 노드가 2표를 유지하므로 클러스터는 계속 정상으로 돌아갑니다. 반대로 2노드라면 한 대가 죽었을 때 남은 한 대는 1표뿐이라 과반(2표)에 못 미쳐, 멀쩡한 노드까지 멈춰버립니다. 이게 HA 클러스터의 최소 단위가 3노드인 이유입니다.

1. 첫 노드에서 클러스터 생성

클러스터는 한 노드에서만 생성하고, 나머지 노드는 거기에 합류(join)시킵니다. 순서가 정해져 있습니다. 여기서는 pve11에서 클러스터를 만듭니다.

02번에서 정한 대로 Corosync를 이중화하려면, 클러스터를 만들 때 두 개의 링크(Ring0/Ring1)를 함께 지정합니다. link0이 평소 경로(관리망), link1이 보조 경로(Ceph망)입니다.

pve11에서 실행합니다.

pvecm create dztw-prd-cls 
  --link0 10.0.92.11 
  --link1 10.10.10.11

dztw-prd-cls — 클러스터 이름 (원하는 이름으로. 운영 환경이라 prd를 붙였습니다)
--link0 — pve11의 관리망 IP (Corosync Ring0)
--link1 — pve11의 Ceph망 IP (Corosync Ring1, 이중화)

생성 직후 상태를 확인합니다.

pvecm status

아직 노드가 하나뿐이라 Nodes: 1로 나오는 게 정상입니다. 이제 나머지를 합류시킵니다.

2. 나머지 노드 합류

pve12와 pve13에서 각각 클러스터에 합류합니다. 합류는 합류할 노드에서 실행하며, 첫 노드(pve11)의 관리망 IP를 가리킵니다. 이때도 자신의 link0/link1 IP를 함께 지정합니다.

pve12에서 실행합니다.

pvecm add 10.0.92.11 
  --link0 10.0.92.12 
  --link1 10.10.10.12

pve13에서 실행합니다.

pvecm add 10.0.92.11 
  --link0 10.0.92.13 
  --link1 10.10.10.13

합류 과정에서 pve11의 root 비밀번호를 묻고, SSH 호스트 키 확인 메시지가 나옵니다. 정상적으로 진행되면 다음과 비슷한 로그가 흐릅니다.

Please enter superuser (root) password for '10.0.92.11': ****
Establishing API connection with host '10.0.92.11'
Login succeeded.
check cluster join API version
Request addition of this node
Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '...'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'pve13' to cluster.

waiting for quorum...OK와 successfully added node가 보이면 합류 성공입니다.

합류 중 뜨는 SSH known_hosts 경고는 무시해도 됩니다. 키 파일이 없어서 나는 경고이며 자동으로 생성됩니다.

3. 클러스터 검증

세 노드를 다 합류시켰으면, 클러스터가 제대로 묶였는지 확인합니다. 아무 노드에서나 실행하면 됩니다.

pvecm status

핵심적으로 봐야 할 부분은 다음과 같습니다.

Name:             dztw-prd-cls
Nodes:            3
Quorate:          Yes
Expected votes:   3
Total votes:      3
Quorum:           2

Membership information
    Nodeid      Votes Name
0x00000001          1 10.0.92.11
0x00000002          1 10.0.92.12
0x00000003          1 10.0.92.13 (local)

확인 포인트는 이렇습니다. Nodes: 3 — 세 노드가 모두 멤버로 들어왔습니다. Quorate: Yes — 클러스터가 정상 상태입니다. Quorum: 2 — 정상 유지에 필요한 최소 표가 2표라는 뜻으로, 한 노드가 죽어도(남은 2표) 클러스터가 살아남는다는 의미입니다. 멤버십 목록에 세 노드의 관리망 IP가 모두 보이면 완성입니다.

노드 목록만 간단히 보려면 다음 명령도 유용합니다.

pvecm nodes

4. Corosync 이중화 확인 (중요)

02번에서 Corosync를 Ring0(관리망) + Ring1(Ceph망)으로 이중화하기로 했는데, 이게 실제로 두 경로 모두 살아 있는지 반드시 확인해야 합니다. 한쪽만 연결돼 있으면 이중화의 의미가 없습니다.

corosync-cfgtool -s

정상이면 다음처럼 LINK ID 0과 1이 모두 나오고, 각 링크에서 다른 노드들이 connected로 표시됩니다.

LINK ID 0 udp
    addr    = 10.0.92.11
    status:
        nodeid: 1: localhost
        nodeid: 2: connected
        nodeid: 3: connected
LINK ID 1 udp
    addr    = 10.10.10.11
    status:
        nodeid: 1: localhost
        nodeid: 2: connected
        nodeid: 3: connected

LINK ID 0(관리망)과 LINK ID 1(Ceph망) 둘 다 모든 노드가 connected면 이중화가 정상 동작하는 것입니다. 이제 Ring0(관리망)이 끊겨도 Corosync는 자동으로 Ring1(Ceph망)로 전환해 클러스터를 유지합니다.

만약 LINK ID 1이 안 보이거나 일부 노드가 connected가 아니라면, 해당 노드의 Ceph망 IP·케이블·스위치 연결을 다시 확인해야 합니다. 클러스터 자체는 Ring0만으로도 동작하지만, 이중화가 빠진 상태로 운영하면 관리망 NIC 하나가 죽는 순간 쿼럼을 잃게 됩니다.

5. 웹 UI에서 확인

마지막으로 웹 UI로 눈으로 확인합니다. 어느 노드의 IP로 접속하든(https://10.0.92.11:8006이든 .12든 .13이든) 좌측 트리에 세 노드가 모두 보여야 합니다.

Datacenter (dztw-prd-cls)
 ├─ pve11
 ├─ pve12
 └─ pve13

이것이 클러스터의 핵심 가치입니다 — 세 대의 서버가 하나의 관리 화면으로 통합되어, 어디로 접속하든 전체를 관리할 수 있습니다. 세 노드가 모두 녹색(정상)으로 표시되면 클러스터 구성은 완료입니다.

아직 남은 것 — 공유 스토리지

여기까지 오면 클러스터는 묶였지만, 아직 HA(고가용성)는 동작하지 않습니다. HA가 되려면 어느 노드에서든 같은 VM 디스크에 접근할 수 있어야 하는데, 지금은 각 노드의 데이터 디스크 6개가 아직 비어 있는 상태이기 때문입니다.

다시 말해, 지금은 “관리가 통합된 3노드”일 뿐, “한 대가 죽어도 VM이 다른 노드에서 살아나는” 상태는 아닙니다. 그 마지막 조각이 공유 스토리지(Ceph)입니다. 비워둔 18개(노드당 6개)의 데이터 디스크를 Ceph로 묶어 3노드가 공유하는 분산 스토리지를 만들면, 비로소 HA의 토대가 완성됩니다.

마무리 & 다음 글

이번 글에서는 pve11에서 클러스터를 만들고 pve12/13을 합류시켜, 쿼럼 정상·Corosync 이중화 정상인 3노드 클러스터를 완성했습니다. 시리즈 제목이 약속한 “3노드 클러스터 구성”이 여기서 달성됐습니다.

다음 글(04. Ceph 분산 스토리지 구축)에서는 비워둔 18개의 디스크를 Ceph로 묶습니다. Ceph 설치부터 MON·MGR 배치, OSD 18개 생성, VM용 풀(pool) 구성까지 다루고, HDD 기반 Ceph의 성능 현실도 함께 짚습니다. 이 글이 끝나면 HA를 올릴 토대가 완성됩니다.

00. Proxmox란? 누구에게 어울리나
01. Proxmox 단일 노드 설치
02. Proxmox 네트워크 망분리 설계
03. Proxmox 3노드 클러스터 구성        ← 현재 글
04. Ceph 분산 스토리지 구축            ← 다음 글
05. PBS 백업 연동과 HA 구성
06. 라이브 마이그레이션과 장애 복구 검증

다른 글 보기

뉴스

프로젝트 문의 환영합니다

기획부터 개발, 운영까지 함께 만들어 드립니다.