[Proxmox] Proxmox HA 클러스터 구축 실패 사례와 교훈: 3년차 엔지니어의 회고

[Proxmox] Proxmox HA 클러스터 구축 실패 사례와 교훈: 3년차 엔지니어의 회고

안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 제가 인프라 엔지니어 3년차 시절, Proxmox HA 클러스터를 구축하다가 제대로 삽질했던 아찔한 경험담을 공유해보려고 합니다. 😅 당시에는 멘붕의 연속이었지만, 지금 생각해보면 그때의 실패가 저를 더 단단하게 만들었더라고요. 혹시 여러분도 Proxmox HA 클러스터를 구축하려다 비슷한 어려움을 겪고 계시다면, 제 이야기가 작은 길잡이가 되기를 바랍니다.

2. Proxmox HA, 그거 왜 필요한 건가요? (개념 설명)

먼저, HA(High Availability, 고가용성)가 뭔지 간략하게 짚고 넘어갈까요? 쉽게 말해, 서비스가 죽지 않고 계속 살아있게 만드는 시스템이라고 생각하시면 돼요. 서버 한 대가 고장 나더라도 다른 서버가 그 역할을 대신해서 서비스 중단을 최소화하는 거죠. 우리 일상에서는 너무나 당연하게 느껴지지만, 이걸 직접 구현하는 건 또 다른 이야기더라고요.

Proxmox HA 클러스터는 이런 고가용성을 가상화 환경에 적용한 거예요. Proxmox VE(Virtual Environment)는 오픈소스 가상화 플랫폼인데, 이 Proxmox 서버 여러 대를 묶어 클러스터를 만들고, 그 위에 돌아가는 가상 머신(VM)이나 컨테이너(LXC)가 특정 노드에 문제가 생기면 다른 노드로 자동으로 마이그레이션(Migration)되어 서비스를 이어가게 해준다는 거죠.

이때 핵심적인 개념들이 몇 가지 있습니다:

• Corosync (코로싱크): 클러스터 노드들 간에 상태 정보를 주고받고, 서로 살아있는지 확인하는 통신 프로토콜이에요. 심장 박동(Heartbeat)처럼 지속적으로 신호를 주고받는다고 생각하시면 돼요.
• Quorum (쿼럼, 정족수): 클러스터가 정상적으로 동작하기 위해 필요한 최소한의 노드 수를 말해요. 쿼럼을 상실하면 클러스터는 자폭(Self-fencing)하거나 서비스를 멈춰서 데이터 일관성을 지키려고 해요. 이게 없으면 Split-brain (스플릿 브레인, 뇌 분열)이라는 무서운 상황이 발생할 수 있어요.
• Split-brain (스플릿 브레인): 클러스터 노드들이 서로 통신이 끊어졌을 때, 각 노드가 자신이 클러스터의 '진짜' 마스터라고 착각하고 독자적으로 동작하는 현상이에요. 이 경우 데이터가 꼬이거나 손상될 수 있어서 정말 위험해요.
• QDevice (쿼럼 디바이스): 주로 2노드 클러스터에서 쿼럼 문제를 해결하기 위해 사용하는 보조 장치예요. 2노드 클러스터는 한 노드만 다운돼도 쿼럼을 상실하는데, QDevice가 제3의 투표권을 행사해서 쿼럼을 유지할 수 있게 도와줄 수 있어요.

Proxmox HA 클러스터의 일반적인 구성 개요입니다. 여러 Proxmox 노드가 공유 스토리지와 Corosync 네트워크로 연결되어 고가용성을 제공하는 모습을 보여줍니다.

3. 야심 찬 Proxmox HA 클러스터 구축기 (실전 구현 - 실패의 시작)

제가 3년차였을 때, 회사에서 작은 프로젝트를 맡았습니다. 특정 서비스의 Proxmox 고가용성 실패를 막기 위해 HA 클러스터를 구축하는 일이었죠. 당시 저는 'Proxmox? HA? 뭐 별거 있겠어?' 하는 오만함에 빠져 있었거든요. 😅

구축 과정은 대략 이랬어요. 2대의 Proxmox 서버를 준비하고, NFS(Network File System) 기반의 공유 스토리지를 연결했었어요. 그리고 Proxmox 클러스터 기능을 이용해서 두 노드를 묶는 작업에 들어갔어요.

Step 1: 첫 번째 Proxmox 노드에 클러스터 생성

pvecm create my-ha-cluster # 'my-ha-cluster'는 클러스터 이름입니다.

Step 2: 두 번째 Proxmox 노드를 클러스터에 추가

pvecm add 192.168.1.10 # 192.168.1.10은 첫 번째 노드의 IP 주소입니다.

여기까지는 순조로웠어요. Proxmox GUI에서 클러스터가 잘 묶이는 것을 확인하고, '오, 성공인가?' 싶었죠. 공유 스토리지도 잘 마운트되고, VM을 만들어서 HA 설정을 켜는 것까지는 문제가 없었어요. VM이 공유 스토리지에 저장되니, 어느 노드에서든 접근할 수 있다는 생각에 흐뭇해했어요.

하지만 이때부터 제가 간과했던 중요한 포인트들이 하나둘씩 수면 위로 떠오르기 시작했어요. 이것이 바로 클러스터 장애 극복이라는 목표를 향한 저의 험난한 HA 운영 노하우 습득 과정의 시작이었습니다.

Proxmox 웹 인터페이스에서 클러스터 상태를 확인하고, 특정 VM에 대해 HA 설정을 활성화하는 화면입니다.

4. ⚠️ 삽질 대잔치! Proxmox HA 클러스터 실패 사례와 트러블슈팅

드디어 삽질의 본론입니다. 😅 제가 겪었던 주요 실패 사례와 당시의 멘붕 과정을 공유해볼게요.

문제 1: 불안정한 공유 스토리지(Shared Storage)

저는 당시 NAS 장비의 NFS 공유를 단순히 연결하기만 했었어요. 'VM 파일만 저장되면 되잖아?' 라고 생각했죠. 하지만 HA 환경에서 공유 스토리지는 단일 장애점(Single Point of Failure)이 되면 안 돼요. 제가 겪은 문제는 이랬어요.

• NFS 서버 단독 장애: NFS 서버 자체가 죽어버리니, 클러스터 노드들이 모두 스토리지에 접근할 수 없게 됐어요. VM은 마이그레이션할 엄두도 못 내고 그냥 멈춰버렸거든요. HA는 발동해야 하는데, VM이 그냥 멈춰버리는 거였어요.
• 네트워크 지연: NAS와 Proxmox 노드 간의 네트워크가 불안정하거나 지연이 발생하면, VM이 I/O 작업을 제대로 수행하지 못해 버벅이거나 멈춰버렸어요. HA가 아무리 좋아도 스토리지 접근이 안 되면 무용지물이더라고요.

💡 교훈: 공유 스토리지는 HA 클러스터의 심장과 같아요. 안정성과 성능을 최우선으로 고려해야 돼요. NFS도 좋지만, 분산 파일 시스템(Distributed File System)이나 블록 스토리지(Block Storage)를 고려했으면 좋았어요. (예: Ceph, iSCSI 기반 SAN)

문제 2: 네트워크 이중화 미흡

클러스터 통신(Corosync)은 네트워크에 매우 민감해요. 저는 단순히 노드 간에 네트워크 케이블 하나씩만 연결했었는데, 이게 큰 문제더라고요.

• Corosync 패킷 유실: 네트워크 케이블이나 스위치 포트에 문제가 생기자마자, Corosync 패킷 유실이 발생했어요.
• 클러스터 핑퐁 & Split-brain: 패킷 유실이 심해지자, 노드들이 서로 '상대방이 죽었나?' 라고 생각하기 시작했어요. 결국 양쪽 노드가 자신이 클러스터의 '진짜' 마스터라고 주장하는 Split-brain (스플릿 브레인)이라는 대참사가 벌어졌어요. VM이 양쪽에서 동시에 실행되려고 하면서 데이터가 완전히 꼬여버리는 경험을 했었어요. 끔찍하더라고요.

💡 교훈: 클러스터 통신용 네트워크는 반드시 이중화(Redundancy)해야 돼요. 네트워크 본딩(Bonding)이나 별도의 물리 스위치를 사용하는 게 필수더라고요.

문제 3: 쿼럼(Quorum) 문제와 펜싱(Fencing)의 부재

제가 구성했던 2노드 Proxmox 클러스터는 한 노드가 다운되자마자 남은 노드가 쿼럼(Quorum)을 상실하고 모든 서비스를 멈춰버렸어요. HA를 구성했는데도 서비스가 멈춰버리는 꼴을 봐야 했었어요.

• 2노드 쿼럼 상실: 2노드 클러스터는 노드 1개가 죽으면 쿼럼(과반수)을 채울 수 없어요. Proxmox는 데이터 일관성을 위해 쿼럼이 없으면 서비스를 중단시켜요. 저는 이 기본적인 메커니즘을 제대로 이해하지 못했었거든요.
• QDevice (쿼럼 디바이스) 미사용: 2노드 클러스터의 쿼럼 문제를 해결하기 위해 QDevice를 사용했으면 좋았는데, 당시에는 그 존재조차 몰랐었어요. QDevice가 제3의 투표권을 행사해서 한 노드가 죽어도 쿼럼을 유지시켜 줄 수 있었거든요.
• Fencing (펜싱) 부재: 펜싱은 문제가 생긴 노드가 클러스터 자원에 접근하지 못하도록 강제로 격리하는 메커니즘이에요. 예를 들어, 죽은 노드의 전원을 강제로 차단해서 Split-brain을 방지하는 역할을 해요. 저는 이런 펜싱 메커니즘을 전혀 고려하지 않고 있었어요.

💡 교훈: 2노드 클러스터라면 QDevice는 선택이 아닌 필수예요. 그리고 펜싱 메커니즘(예: IPMI, iLO, DRAC 등을 활용한 전원 제어)을 반드시 고려해야 돼요. 이게 없으면 클러스터가 제 역할을 못하거나 더 큰 문제를 야기할 수 있어요.

안정적으로 운영되는 Proxmox HA 클러스터의 대시보드 화면입니다. 모든 노드가 정상적으로 작동하며, VM의 HA 상태가 활성화되어 있음을 보여줍니다.

5. 실패를 통해 배운 교훈과 안정적인 Proxmox HA 운영 노하우

이러한 삽질들을 통해 제가 얻은 Proxmox HA 운영 노하우는 다음과 같아요.

1. 공유 스토리지의 중요성을 인지하라: 단순 NFS보다는 Ceph(세프)나 ZFS over iSCSI/NFS, 또는 전용 SAN(Storage Area Network) 스토리지를 고려해야 돼요. 특히 Ceph는 Proxmox와 통합이 잘 되어 있어 좋은 선택지예요. 저도 나중에는 Ceph를 홈랩에 구축해서 사용해봤는데, 정말 든든하더라고요.
2. 네트워크 이중화는 필수 중의 필수!: Corosync 통신용 네트워크는 반드시 본딩(Bonding)을 통해 이중화하고, 가능하다면 물리적으로 분리된 스위치를 사용해야 돼요. 클러스터 네트워크의 안정성이 HA의 성패를 좌우해요.
3. 쿼럼과 QDevice를 정확히 이해하라: 2노드 클러스터라면 QDevice는 꼭 설정해야 돼요. 3노드 이상이 이상적이지만, 2노드 구성 시 QDevice는 쿼럼 상실을 막는 핵심이에요.
4. 펜싱(Fencing) 메커니즘을 고려하라: IPMI, iLO, DRAC 같은 BMC(Baseboard Management Controller)를 활용하여 장애 노드의 전원을 강제로 차단하는 펜싱 메커니즘을 구성하는 게 Split-brain을 방지하는 가장 확실한 방법이에요.
5. 충분한 테스트는 생명이다: 클러스터 구축 후에는 반드시 장애 시나리오 테스트를 충분히 수행해야 돼요. 노드 강제 종료, 네트워크 케이블 뽑기 등 실제 장애 상황을 시뮬레이션하며 HA가 제대로 동작하는지 확인해야 돼요. 이 과정을 통해서 예상치 못한 문제점을 발견하고 해결할 수 있어요.

6. 마무리

3년차 시절의 Proxmox HA 클러스터 실패는 저에게 잊을 수 없는 경험으로 남아있어요. 당시에는 좌절도 하고 밤샘 삽질도 많이 했지만, 그 과정에서 고가용성 시스템의 복잡성과 중요성, 그리고 탄탄한 기본기 없이는 어떤 기술도 제대로 활용할 수 없다는 것을 뼈저리게 느꼈어요.

여러분은 저처럼 무작정 시도했다가 삽질하지 말고, 충분한 학습과 계획을 통해 안정적인 Proxmox HA 클러스터를 성공적으로 구축하시길 바라요. 이 글이 여러분의 클러스터 장애 극복 여정에 작은 도움이 되었으면 좋겠어요. 다음에 더 유익한 내용으로 찾아오겠습니다! 💡

Proxmox HA 클러스터 구축 시 반드시 고려해야 할 핵심 요소들을 요약한 인포그래픽입니다. 공유 스토리지, 네트워크 이중화, 쿼럼, 펜싱, 테스트의 중요성을 강조합니다.

📚 함께 읽으면 좋은 글

• Ansible로 Proxmox 자동화, 실패 없는 10가지 베스트 프랙티스
• Proxmox VE 보안 강화 체크리스트 10가지: 안전한 가상화 환경 구축
• Proxmox VE 8.2 심층 분석: 데이터센터 관리 기능과 주요 개선점
• ArgoCD로 멀티 클러스터 GitOps 배포 자동화 완벽 가이드
• ArgoCD 멀티 클러스터 배포 전략: GitOps로 K8s 여러 환경을 효과적으로 관리하기