지난 글(03. Proxmox 3노드 클러스터 구성)에서 세 노드를 하나의 클러스터로 묶었습니다. 하지만 그 글 끝에서 말했듯, 아직 HA는 동작하지 않습니다 — 노드들이 공유하는 스토리지가 없기 때문입니다. 이번 글에서는 비워둔 18개(노드당 6개)의 데이터 디스크를 Ceph 분산 스토리지로 묶어, 세 노드가 함께 쓰는 공유 스토리지를 만듭니다. 이 글이 끝나면 비로소 HA를 올릴 토대가 완성됩니다.
Ceph란, 그리고 왜 쓰나
Ceph는 여러 노드의 디스크를 하나의 거대한 저장소처럼 묶어주는 분산 스토리지입니다. Proxmox에 내장돼 있어 웹 UI에서 바로 구성할 수 있습니다.
핵심 가치는 복제입니다. 데이터를 여러 노드에 3벌씩 복제해 보관하므로, 노드 한 대가 통째로 죽어도 데이터는 다른 노드에 살아 있습니다. 그리고 모든 노드가 같은 스토리지에 접근할 수 있어서, 어느 노드에서 VM을 켜든 같은 디스크를 본다 — 이것이 HA와 라이브 마이그레이션이 가능해지는 전제입니다.
클러스터를 묶었어도 각 노드가 자기 로컬 디스크만 본다면, VM이 떠 있던 노드가 죽었을 때 다른 노드는 그 VM의 디스크에 접근할 수 없습니다. 그래서 HA에는 “모든 노드가 공유하는 스토리지”가 반드시 필요하고, 그 역할을 Ceph가 맡습니다.
시작 전 — HDD Ceph의 성능 현실 체크
본격적으로 들어가기 전에 솔직하게 짚을 점이 있습니다. Ceph는 하드웨어에 솔직한 시스템입니다. 스펙이 안 받쳐주면 “느려서 못 쓰겠다”는 소리가 나옵니다. 이 구축의 디스크는 SAS 2TB HDD입니다(노드당 6개). HDD로도 Ceph는 잘 동작하지만, 성능 기대치는 명확히 잡아야 합니다.
- HDD OSD의 IOPS는 낮습니다. 디스크당 약 100~150 IOPS, 노드당 6개를 합쳐도 600~900 IOPS 수준입니다. 랜덤 I/O가 많은 워크로드(활성 DB, 트래픽 높은 웹서버)에는 답답할 수 있습니다. 반면 파일 서버, 백업 대상, 아카이브, 가벼운 LXC에는 충분합니다.
- 네트워크가 가장 큰 변수입니다. 그래서 02번에서 Ceph를 10G 폐쇄망에 단독으로 올렸습니다. 1G로 Ceph를 돌리면 노드 한 대가 죽은 뒤 복구(리커버리)에 며칠이 걸릴 수도 있습니다. 10G 이상은 사실상 필수입니다.
- 메모리도 꽤 먹습니다. OSD당 약 4~5 GiB를 쓰므로, 노드당 OSD 6개면 Ceph 전용으로만 24~30 GiB가 빠집니다. VM에 줄 메모리를 따로 계산해둬야 합니다(00번 글의 수용량 추산에서 이미 반영했습니다).
- 성능을 더 끌어올리려면 노드당 NVMe/SSD를 DB/WAL 디바이스로 추가해 메타데이터를 SSD로 분리하는 방법이 있습니다. 이 구축은 HDD only로 진행했지만, 랜덤 I/O가 중요한 환경이라면 강력히 권장됩니다.
정리하면, 이 구성은 “HDD 기반이라 초고성능은 아니지만, 10G 폐쇄망과 18 OSD로 안정적인 가용성을 확보한” 균형점입니다.
0. 디스크 확인 (가장 중요)
Ceph OSD를 만들기 전에 어떤 디스크가 OS용이고 어떤 디스크가 데이터용인지 반드시 정확히 식별해야 합니다. 잘못된 디스크를 잡으면 OS가 날아갑니다.
# 모든 디스크 + 마운트 상태 + 모델/시리얼
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
# OS 풀(rpool) 확인 — 어떤 디스크가 OS용인지 명확히
zpool status
# by-id 경로 (식별용)
ls -l /dev/disk/by-id/ | grep -v partOS용 300GB × 2(ZFS RAID1)는 절대 건드리면 안 됩니다. 데이터용 2TB × 6만 OSD로 내줍니다. 디스크에 과거 데이터나 시그니처가 남아 있다면 깨끗이 비웁니다.
# 데이터 디스크에 대해서만 (예시 — 실제 디바이스로 교체)
for d in sdc sdd sde sdf sdg sdh; do
wipefs -a /dev/$d
ceph-volume lvm zap /dev/$d --destroy 2>/dev/null
doneSAS 컨트롤러가 RAID 모드가 아니라 IT mode(HBA/JBOD)여야 합니다. RAID 모드면 Ceph가 디스크를 직접 보지 못합니다.
lsblk로 디스크 6개가 각각 개별로 보이면 정상입니다.
1. Ceph 설치
세 노드 모두에 Ceph 패키지를 설치합니다. 각 노드에서 실행합니다.
pveceph install --repository no-subscriptionPVE 8.4 기준으로 Ceph Squid(19.x)가 설치됩니다. 설치 후 버전을 확인합니다.
ceph --version
# ceph version 19.2.3 ... squid (stable) 형태면 정상설치 마지막에 “installed Ceph 17.2 Quincy successfully!” 같은 메시지가 떠도 당황하지 마세요. 이건 Proxmox 설치 스크립트의 메시지 표기 버그로, 실제 설치된 버전은
ceph --version이 보여주는 Squid 19.2.3이 맞습니다.
2. 초기화 (한 노드에서만)
Ceph가 사용할 네트워크를 등록합니다. 이건 한 노드(pve11)에서만 실행하면 클러스터 전체에 동기화됩니다. 02번에서 정한 Ceph 10G 폐쇄망 대역을 지정합니다.
pveceph init --network 10.10.10.0/24Ceph는 Public network(클라이언트↔Ceph)와 Cluster network(OSD 간 복제)를 분리할 수 있지만, 3노드 18 OSD 규모에서는 분리가 필수가 아닙니다. 10G 한 망에 통합해도 병목이 없습니다. 그래서 여기서는 단일 네트워크로 초기화했습니다.
3. MON / MGR 배치
Ceph의 컨트롤 플레인을 구성합니다. MON(Monitor)은 클러스터 상태와 맵을 관리하고, MGR(Manager)은 메트릭·대시보드를 담당합니다.
웹 UI에서 노드 → Ceph → Monitor, 노드 → Ceph → Manager로 추가하거나, CLI로 각 노드에서 생성합니다.
# 각 노드에서 (또는 pve11에서 노드 지정하여)
pveceph mon create
pveceph mgr createMON은 3개(노드당 1개)를 둡니다. 쿼럼과 같은 이유로, MON도 홀수 개여야 과반 판단이 가능합니다. MGR은 active 1개 + standby로 이중화합니다. 결과적으로 MON 3 + MGR 3(1 active + 2 standby) 구성이 됩니다.
4. OSD 18개 생성
이제 데이터 디스크를 OSD(Object Storage Daemon)로 만듭니다. OSD 하나 = 디스크 하나입니다. 세 노드에서 각각 6개씩, 총 18개를 만듭니다.
각 노드에서 실행합니다.
pveceph osd create /dev/sdc
pveceph osd create /dev/sdd
pveceph osd create /dev/sde
pveceph osd create /dev/sdf
pveceph osd create /dev/sdg
pveceph osd create /dev/sdh웹 UI라면 노드 → Ceph → OSD → Create OSD에서 디스크를 선택해 6번 반복하면 됩니다. 세 노드 모두 끝내면 OSD 18개가 됩니다. 검증합니다.
ceph osd tree
ceph -s정상이면 OSD가 host(노드)별로 정확히 6개씩 분산되고, 모두 up/in 상태로 나옵니다.
osd: 18 osds: 18 up, 18 in
usage: ... 33 TiB / 33 TiB avail
health: HEALTH_OK여기서 중요한 점은 host별 6개씩 균등 분산입니다. Ceph의 기본 CRUSH 규칙이 host 단위로 데이터를 분산하기 때문에, 복제본이 서로 다른 노드에 흩어집니다. 그래서 노드 한 대가 통째로 죽어도 데이터가 살아남는 것입니다.
용량 정리
| 항목 | 용량 |
|---|---|
| Raw 용량 | 32.75 TiB (1.82 TiB × 18) |
| 가용 용량 (replica 3) | 약 11.1 TiB |
| 권장 사용 한계 (70%) | 약 7.6 TiB |
Raw 32.75 TiB가 가용 11.1 TiB로 줄어드는 건 3중 복제 때문입니다. 용량의 2/3를 안전을 위해 내주는 셈입니다. 그리고 Ceph는 가득 채우면 성능이 급락하고 위험하므로, 실사용은 70%(약 7.6 TiB) 선에서 관리하는 게 좋습니다.
5. VM용 풀(Pool) 생성
OSD를 다 만들었으면, VM 디스크 이미지를 저장할 RBD 풀을 만들고 PVE 스토리지로 등록합니다.
웹 UI에서 노드 → Ceph → Pools → Create로 만드는 게 간단합니다.
| 항목 | 값 | 의미 |
|---|---|---|
| Name | vm-pool | 풀 이름 |
| Size | 3 | 복제본 수 (3벌 보관) |
| Min Size | 2 | 최소 복제본. 이 밑으로 떨어지면 read-only |
| PG Autoscale Mode | on | PG 수 자동 조정 |
| Add as Storage | ✓ | PVE 스토리지로 자동 등록 (반드시 체크) |
CLI로는 한 줄입니다.
pveceph pool create vm-pool
--size 3 --min_size 2
--pg_autoscale_mode on
--add_storages 1--add_storages 1 옵션이 PVE 스토리지 등록까지 처리합니다.
size=3 / min_size=2의 의미. 평소엔 데이터를 3벌 보관하되, 노드 장애로 복제본이 2벌까지 줄어드는 동안에는 계속 읽고 쓸 수 있게 합니다. 1벌까지 떨어지면 데이터 보호를 위해 쓰기를 막습니다(read-only). 이 설정이 “노드 한 대 죽어도 서비스 유지”의 핵심입니다.
PG가 뭔가 — 잠깐 짚기
생성 시 PG(Placement Group) 수를 묻습니다. PG는 Ceph가 데이터를 분배하는 단위인데, 초기값(예: 128)으로 두면 됩니다. Autoscaler가 on이라, 데이터가 쌓이면 적정 수로 자동 조정합니다. 실제로 생성 직후 보면 PG 수가 한동안 늘었다 줄었다 하는데, 이건 Autoscaler가 현재 데이터 양에 맞춰 조정하는 정상 동작입니다.
6. 검증
풀까지 만들었으면 전체가 제대로 붙었는지 확인합니다.
ceph osd pool ls # vm-pool 보이는지
ceph -s # HEALTH_OK, pools 2개(.mgr + vm-pool)
pvesm status # PVE 스토리지에 vm-pool 등록됐는지정상이면 pvesm status에 vm-pool이 약 11.1 TiB 가용으로 잡히고, Ceph 상태는 HEALTH_OK, OSD 18개 모두 up/in입니다. 이제 VM을 만들 때 디스크를 vm-pool에 둘 수 있고, 그 디스크는 세 노드가 공유합니다.
마무리 & 다음 글
이번 글에서는 비워둔 18개의 디스크를 Ceph로 묶어, 세 노드가 공유하는 분산 스토리지(약 11.1 TiB 가용)를 완성했습니다. Ceph 설치 → 초기화 → MON/MGR → OSD 18개 → vm-pool 순으로 진행했고, HDD Ceph의 성능 현실과 size=3/min_size=2의 의미도 짚었습니다. 이제 “노드 한 대가 죽어도 데이터가 살아남고, 어느 노드에서든 같은 디스크를 보는” 상태가 됐습니다.
다음 글(05. PBS 백업 연동과 HA 구성)에서는 두 가지를 마무리합니다. 먼저 01번에서 설치해둔 PBS를 클러스터와 연동해 자동 백업 체계를 만들고, 그다음 드디어 HA 그룹을 구성해 “노드가 죽으면 VM이 다른 노드에서 자동으로 살아나는” 상태를 완성합니다.
00. Proxmox란? 누구에게 어울리나
01. Proxmox 단일 노드 설치
02. Proxmox 네트워크 망분리 설계
03. Proxmox 3노드 클러스터 구성
04. Ceph 분산 스토리지 구축 ← 현재 글
05. PBS 백업 연동과 HA 구성 ← 다음 글
06. 라이브 마이그레이션과 장애 복구 검증
