지난 글(01. Proxmox 단일 노드 설치)에서 노드 한 대를 세우고 PBS까지 설치했습니다. 이번 글은 클러스터를 묶기 전에 반드시 먼저 잡아야 하는 네트워크 설계를 다룹니다. 왜 트래픽을 종류별로 분리하는지, 어떤 망을 어떤 NIC에 배정하는지, 그리고 클러스터의 심장박동인 Corosync를 왜 따로 빼야 하는지를 실제 결정 과정과 함께 정리합니다.
왜 클러스터보다 네트워크를 먼저 설계하나
순서가 중요합니다. 클러스터를 먼저 묶고 네트워크를 나중에 바꾸려 하면, 관리 IP를 옮기는 작업 도중 노드와의 연결이 끊겨 복구가 까다로워집니다. 특히 Corosync(클러스터 통신)는 클러스터를 만드는 시점에 어느 네트워크를 쓸지 지정하기 때문에, 네트워크 그림을 먼저 확정해 두는 게 사고를 막는 길입니다.
그래서 이번 글에서는 케이블 배선과 IP 대역, NIC 역할 분담까지 다 정해놓고, 다음 글에서 그 위에 클러스터를 올립니다.
트래픽을 왜 분리하나
가상화 클러스터에는 성격이 전혀 다른 트래픽이 섞여 흐릅니다. 이걸 한 네트워크에 몰아넣으면 서로를 방해합니다. 종류별로 보면 이렇습니다.
서비스 트래픽 — VM이 실제로 주고받는 http/https, web↔api↔db 통신. 사용자에게 직접 보이는 트래픽입니다.
관리 트래픽 — Proxmox 웹 UI 접속, SSH. 양은 적지만 관리자가 항상 닿을 수 있어야 합니다.
스토리지 복제 트래픽(Ceph) — 노드 간 데이터를 3중 복제하는, 가장 무겁고 대역폭을 많이 먹는 트래픽입니다.
클러스터 통신(Corosync) — 노드들이 서로 “나 살아있다”를 주고받는 하트비트. 양은 매우 적지만 지연(latency)에 극도로 민감합니다.
이 넷을 섞으면 어떤 일이 생기냐면 — VM이 대용량 백업을 돌려 NIC가 포화되는 순간 Corosync 메시지가 지연되고, 클러스터가 “저 노드 죽었나?”로 오판해 멀쩡한 VM을 강제 재시작(fence)시킬 수 있습니다. 실제 운영에서 자주 나는 사고입니다. 그래서 각 트래픽을 가능한 한 별도 NIC로 격리하는 게 핵심입니다.
Corosync를 따로 빼는 이유
망분리에서 가장 자주 받는 질문이 “Corosync 전용망이 꼭 필요하냐”입니다. 결론부터 말하면, 반드시 물리적으로 전용일 필요는 없지만, 한가한 망에 두는 것이 중요합니다.
Corosync는 Proxmox 클러스터의 심장박동입니다. 노드들이 매초 서로에게 생존 신호를 보내고, 이 신호가 일정 시간(보통 수 초) 끊기면 해당 노드를 죽은 것으로 판단합니다. HA가 켜진 VM이라면 그 즉시 다른 노드에서 강제로 재시작됩니다. 즉, 네트워크가 잠깐 막힌 것만으로도 정상 VM이 재시작당할 수 있습니다.
Corosync의 특징은 “트래픽 양은 적은데(초당 수십 KB) 지연에 민감하다”는 점입니다. 그래서 대역폭이 큰 망보다, 다른 트래픽이 거의 없는 한가한 망에 두는 게 더 안전합니다.
여기서 한 가지 현실적인 판단이 들어갔습니다. 이 환경은 관리망에 접속하는 사람이 관리자 본인 한 명뿐이라, 관리망에는 사실상 트래픽이 없습니다. 그래서 “Corosync 전용 1G NIC를 따로 빼서 케이블을 추가로 연결”하는 대신, 한가한 관리망을 Corosync Ring0로 함께 사용하기로 했습니다. 관리망이 한가하니 지연 위험이 없고, 케이블 추가도 필요 없습니다.
만약 관리망에 여러 관리자가 붙거나 모니터링·백업 트래픽이 섞여 흐른다면, 이 판단은 위험해집니다. 그때는 Corosync 전용 NIC를 빼는 게 맞습니다. “우리 관리망이 실제로 한가한가”를 먼저 따져보고 결정해야 합니다.
Ring0 + Ring1 — 하트비트 이중화
Corosync는 통신 경로(Ring)를 두 개 둘 수 있습니다. Ring0가 평소 경로, Ring1이 보조 경로입니다. Ring0가 죽거나 케이블이 빠지면 자동으로 Ring1로 전환되어, 한 경로가 끊겨도 클러스터가 분열(split-brain)되지 않습니다.
이 구축에서는 Ring0는 관리망, Ring1은 Ceph용 10G망을 보조로 지정했습니다. Corosync 트래픽은 워낙 작아서 Ceph망에 얹어도 Ceph 성능에 거의 영향이 없고, 별도 케이블 없이 이중화를 확보할 수 있기 때문입니다.
최종 네트워크 설계
여러 안을 검토한 끝에 확정한 구성입니다. 이 환경의 NIC는 1G 포트 여러 개와 10G 포트 2개로 구성되어 있습니다.
| 트래픽 | 대역 | NIC | 속도 | 비고 |
|---|---|---|---|---|
| 관리망 + Corosync Ring0 | 10.0.92.0/24 | eno4 | 1G | 한가한 망, 클러스터 제어 |
| VM 서비스망 | 10.0.12.0/24 | eno1 (→ vmbr0) | 1G | VM의 http/https, web·api·db |
| Ceph + Corosync Ring1 | 10.10.10.0/24 | ens2f0 | 10G | 스토리지 복제 전용 폐쇄망 |
노드별 IP 끝자리는 노드 번호와 통일했습니다. pve11은 모든 대역에서 .11, pve12는 .12, pve13은 .13을 씁니다. 예를 들어 pve11의 관리 IP는 10.0.92.11, Ceph IP는 10.10.10.11입니다. “마지막 옥텟 = 노드 번호” 규칙을 모든 망에 적용하면 운영·디버깅 때 IP만 봐도 어느 노드인지 바로 알 수 있습니다.
설계 포인트 몇 가지
Ceph는 10G 폐쇄망에. 스토리지 복제는 가장 무거운 트래픽이라 10G에 단독으로 올렸습니다. 이 망은 외부로 라우팅하지 않는 폐쇄망(노드 간 + 전용 스위치 내부)으로 두어, 복제 트래픽이 서비스망을 방해하지도, 외부에 노출되지도 않게 했습니다.
Ceph Public/Cluster 분리는 하지 않았다. Ceph는 클라이언트 통신(Public)과 OSD 복제(Cluster)를 별도 망으로 나눌 수 있지만, 3노드 18 OSD 규모에서는 분리가 필수가 아닙니다. 10G 한 장에 통합해도 병목이 없습니다. Public/Cluster 분리는 OSD 200개가 넘는 대규모에서나 의미가 있습니다. 작은 클러스터에서 과하게 나누면 설정만 복잡해집니다.
VM 서비스망 브리지에는 호스트 IP를 두지 않는다. 서비스망(vmbr0)은 VM들이 외부와 통신하는 통로일 뿐, Proxmox 호스트 자신이 이 망에 IP를 가질 이유는 보통 없습니다. 호스트 관리는 관리망으로 하면 되므로, 서비스 브리지는 VM 전용으로 두는 게 깔끔합니다.
설정과 검증
브리지·IP는 웹 UI의 노드 → System → Network에서 설정합니다. CLI에 익숙하다면 /etc/network/interfaces를 직접 편집할 수도 있지만, 어느 쪽이든 변경 후 반드시 Apply Configuration(또는 ifreload -a)으로 적용해야 합니다.
관리 IP가 걸린 NIC를 바꾸는 작업은 위험합니다. 적용 도중 SSH·웹 UI 연결이 끊길 수 있으므로, IPMI/iLO나 물리 콘솔에 접근할 수 있는 상태에서 진행하세요. 콘솔 없이 원격으로만 작업하다 끊기면 복구가 매우 어려워집니다.
각 망을 설정한 뒤에는 노드 간 통신을 ping으로 확인합니다. 특히 Ceph 10G망은 속도까지 같이 점검할 수 있습니다.
# pve11에서 다른 노드의 Ceph망 IP로 ping
ping -c 3 10.10.10.12
ping -c 3 10.10.10.13이때 응답 지연(latency)을 보면 케이블이 제대로 10G 스위치에 물렸는지 알 수 있습니다. 실제 구축에서 측정했을 때 0.2~0.4ms가 나왔는데, 이게 10G 정상 동작 신호입니다. 만약 0.5~1ms 이상이 나오면 10G가 아니라 1G 경로로 흐르고 있을 가능성이 높으니, 케이블이 꽂힌 포트를 다시 확인해야 합니다.
# 인터페이스에 IP가 제대로 붙었는지 확인
ip -br addr show
# 기본 경로(게이트웨이) 확인
ip route3노드가 서로 모든 망에서 ping이 통하면 네트워크 준비는 끝입니다.
짚고 넘어갈 점 — DNS·NTP도 이 단계에서
네트워크를 정리하는 김에, 클러스터 구성 전에 두 가지를 꼭 맞춰두는 게 좋습니다.
DNS·게이트웨이. 01번 글에서 다뤘듯, 게이트웨이가 외부로 못 나가는 망에 잡혀 있으면 apt와 NTP가 모두 막힙니다. 기본 경로가 외부로 나갈 수 있는 관리망 게이트웨이로 잡혀 있는지 ip route로 확인하세요.
시간 동기화(NTP). 클러스터를 묶기 전에 모든 노드가 같은 NTP 소스로 동기화되어 있어야 합니다. 노드 간 시계가 어긋나면 Corosync가 곧바로 문제를 일으킵니다. chrony가 동기화 중인지 chronyc sources로 확인하고, Stratum이 0이거나 소스가 비어 있으면 NTP 서버(사내 NTP 또는 공용 NTP)를 제대로 가리키도록 고친 뒤 다음 단계로 넘어가야 합니다.
chronyc sources # 동기화 소스 확인
chronyc tracking | grep Stratum # Stratum이 1~2면 정상마무리 & 다음 글
이번 글에서는 서비스·관리·스토리지·클러스터 트래픽을 왜 분리해야 하는지, 그리고 이 환경에서 실제로 어떻게 배정했는지를 정리했습니다. 핵심은 세 가지입니다 — Ceph는 무거우니 10G 폐쇄망에 단독으로, Corosync는 한가한 관리망에 두되 Ring1로 이중화, VM 서비스망은 별도 1G로 격리.
이제 네트워크 밑그림이 완성됐으니, 다음 글(03. Proxmox 3노드 클러스터 구성)에서 이 위에 실제로 3노드 클러스터를 묶습니다. 한 노드에서 클러스터를 만들고 나머지를 합류시키는 과정, 쿼럼(quorum) 개념, 그리고 Corosync Ring0/Ring1 이중화가 실제로 동작하는지 검증하는 데까지 다룹니다.
00. Proxmox란? 누구에게 어울리나
01. Proxmox 단일 노드 설치
02. Proxmox 네트워크 망분리 설계 ← 현재 글
03. Proxmox 3노드 클러스터 구성 ← 다음 글
04. Ceph 분산 스토리지 구축
05. PBS 백업 연동과 HA 구성
06. 라이브 마이그레이션과 장애 복구 검증
