13년차의 서버실

서버, 인프라, 홈랩 기술 블로그

[태그:] Proxmox HA 클러스터

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

    [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 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 설정하는 화면

    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 클러스터의 대시보드 화면

    안정적으로 운영되는 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 클러스터 구축 시 반드시 고려해야 할 핵심 요소 요약 인포그래픽

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

  • [Proxmox] Proxmox VE 클러스터 고가용성(HA) 구축: 실패 사례 분석 및 교훈

    [Proxmox] Proxmox VE 클러스터 고가용성(HA) 구축: 실패 사례 분석 및 교훈

    목차

    [Proxmox VE] 클러스터 HA 구축 실패 사례 분석 및 교훈

    안녕하세요, 13년차의 서버실입니다. 오늘은 제가 홈랩에서 Proxmox VE(Virtual Environment) 클러스터로 고가용성(High Availability, HA) 환경을 구축하다가 겪었던 삽질 경험을 솔직하게 풀어보려고 합니다. 사실 처음엔 ‘Proxmox HA 클러스터? 별거 아니겠지!’ 하고 덤볐다가 제대로 혼쭐이 났거든요. 여러분은 저처럼 뼈아픈 실패를 겪지 않으시길 바라는 마음에서, 저의 삽질 과정과 해결책을 공유해 드립니다.

    Proxmox VE HA 클러스터의 이상적인 구성 다이어그램입니다. 이렇게만 되면 얼마나 좋을까요? 😅

    Proxmox HA 클러스터, 왜 필요할까요?

    Proxmox VE 클러스터는 여러 Proxmox 노드를 하나로 묶어서 관리하고, 특히 HA 기능을 활용하면 특정 노드에 장애가 발생했을 때 그 노드에서 실행 중이던 가상 머신(Virtual Machine, VM)이나 컨테이너(Container, LXC)가 자동으로 다른 정상 노드로 옮겨가서 서비스 연속성을 유지해 줍니다. 쉽게 말해, 서버 한 대가 고장 나도 서비스는 계속 돌아가게 해주는 아주 고마운 기능이죠. 이 HA를 가능하게 하는 핵심 기술 중 하나가 바로 Corosync(코로싱크)라는 분산 합의 프로토콜입니다. Corosync는 클러스터 내의 모든 노드가 서로의 상태를 감시하고, 클러스터의 ‘상태’에 대해 합의를 이룰 수 있도록 돕는 역할을 해요. 모든 노드가 같은 정보를 보고 있다는 확신이 있어야만, 안전하게 HA 결정을 내릴 수 있거든요.

    홈랩에 Proxmox 클러스터 구축하기 (feat. 2노드의 함정)

    처음에는 Proxmox 클러스터 구성 자체는 어렵지 않았어요. 각 노드에 Proxmox VE를 설치하고, 터미널에서 pvecm create 명령으로 클러스터를 만들고, 다른 노드에서 pvecm add 명령으로 합류시키면 끝! 정말 간단하더라고요. 홈랩이니 일단 물리 서버 두 대로 시작했습니다. (나중에 이게 문제의 씨앗이 될 줄은 몰랐죠 😂)

    # 첫 번째 노드에서 클러스터 생성
pvecm create my-ha-cluster

# 두 번째 노드에서 클러스터 합류 (첫 번째 노드의 IP 입력)
pvecm add 192.168.1.10 --ring0_addr 192.168.1.11 # 192.168.1.10은 첫 번째 노드, 192.168.1.11은 두 번째 노드의 Corosync 통신용 IP

    이렇게 두 노드를 클러스터로 묶고, 공유 스토리지를 NFS(Network File System)로 연결했어요. VM 디스크를 이 NFS에 저장하고, 몇몇 VM에 HA 설정을 활성화했습니다. ‘이제 한 대 꺼져도 문제없겠지?’ 하는 생각에 뿌듯했죠. 그러나 현실은… 달랐습니다.

    Proxmox VE 웹 UI의 HA 설정 화면

    Proxmox VE 웹 UI에서 HA 설정을 활성화하는 화면입니다. 저도 처음엔 이 옵션만 믿었죠.

    ⚠️ 스플릿 브레인(Split-Brain) 발생과 삽질 해결 과정

    문제는 바로 여기서 발생했습니다. 제가 한 노드의 전원을 강제로 내려봤어요. HA가 잘 작동하는지 보려고요. 그런데 VM이 다른 노드로 넘어가지 않는 겁니다! 😱 아니, 이게 무슨 일인가 싶어서 Proxmox 웹 UI를 확인해보니, 꺼진 노드는 ‘offline’ 상태인데, VM은 여전히 ‘stopped’ 상태로 남아있는 거예요. 심지어 나중에 다시 켜보니, 양쪽 노드에서 같은 VM이 켜져 있는 기괴한 상황까지 벌어졌습니다. 네, 바로 Split-Brain(스플릿 브레인) 현상이었죠.

    Split-Brain(스플릿 브레인)은 분산 시스템에서 클러스터 노드들이 서로 통신하지 못하게 되어, 각 노드가 클러스터의 ‘일부’가 마치 전체 클러스터인 것처럼 독자적인 결정을 내리는 상황을 말합니다. 이 경우, 두 노드가 같은 자원(예: 같은 VM)을 동시에 점유하려 들면서 데이터 손상이나 서비스 중단 같은 심각한 문제가 발생할 수 있어요. Proxmox 클러스터에서는 Corosync가 노드 간의 합의를 담당하는데, 통신 장애가 생기면 이 합의가 깨지면서 스플릿 브레인이 발생할 수 있는 거죠.

    원인을 찾아보니, 제 클러스터는 노드가 2개였습니다. Corosync는 클러스터의 ‘쿼럼(Quorum)’이라는 개념을 사용해서 합의를 이룹니다. 쿼럼(Quorum)은 클러스터가 정상적으로 작동하기 위해 필요한 최소한의 투표 수(votes)를 의미해요. 보통 클러스터 노드 수의 과반수(N/2 + 1)를 요구합니다. 2개 노드 클러스터에서는 쿼럼이 2가 됩니다. 즉, 두 노드가 모두 살아있어야만 쿼럼이 충족되는 거죠. 한 노드가 죽으면 쿼럼이 깨지면서 클러스터 전체가 멈춰버리는 겁니다. HA가 작동할 리가 없죠.

    이게 바로 ‘2노드 클러스터의 딜레마’였습니다. 그래서 Proxmox 문서나 여러 커뮤니티를 찾아보니, 최소 3개 노드를 권장하더라고요. 3개 노드 클러스터라면 쿼럼은 2가 됩니다. 한 노드가 죽어도 나머지 두 노드가 살아있으면 쿼럼이 유지되므로 HA 기능을 정상적으로 사용할 수 있습니다. ‘아, 그래서 다들 3노드, 5노드 하는구나!’ 하고 무릎을 탁 쳤습니다. 홈랩에 놀고 있는 미니 PC 한 대를 추가해서 3노드 클러스터로 재구성하기로 결정했어요.

    # (예시) 기존 2노드 클러스터에서 한 노드를 제거하고 3노드 클러스터로 재구성하는 과정
# 1. HA 서비스 비활성화 (모든 VM/LXC)
# 2. 클러스터 노드에서 VM/LXC 모두 다른 노드로 마이그레이션 또는 종료
# 3. 제거할 노드에서 클러스터 탈퇴 (pvecm delnode [노드이름])
# 4. 새로 추가할 노드에 Proxmox 설치 후 pvecm add [기존 노드 IP]
# 5. HA 설정 재활성화 및 테스트

    실제로 이렇게 3노드 클러스터로 재구성하고 다시 테스트해보니, 드디어 HA가 제대로 작동하더라고요! 한 노드의 전원을 강제로 내려도, 다른 노드에서 VM이 정상적으로 기동되는 것을 확인했습니다. 🎉

    3노드 Proxmox VE 클러스터 대시보드와 HA 작동 결과

    드디어 3노드 클러스터에서 HA가 정상 작동하는 모습입니다. 노드 중 하나가 오프라인이 되어도 VM이 다른 노드에서 잘 살아났어요!

    검증 및 결과: 이제야 안심이 되네요

    3노드 클러스터로 재구성한 후, 여러 시나리오로 HA 기능을 검증해봤습니다.

    • 노드 강제 종료: 특정 노드의 전원을 뽑아보니, 약 1~2분 내에 해당 노드에 할당된 HA VM들이 다른 정상 노드에서 자동으로 시작되었습니다.
    • 네트워크 단절: Corosync 네트워크 케이블을 뽑아보니, 역시 쿼럼이 깨지지 않는 상황에서는 HA가 정상적으로 작동했습니다. (물론 모든 네트워크가 단절되면 답이 없지만요 😅)
    • 스토리지 장애 시나리오: 공유 NFS 스토리지가 끊겼을 때는 HA가 작동하지 않았습니다. 이건 당연한 결과죠. VM 디스크를 읽을 수 없으니 다른 노드로 넘어가도 소용이 없거든요. 그래서 공유 스토리지의 고가용성도 중요합니다. (다음 글에서 다룰 예정입니다!)

    이렇게 직접 테스트하고 나서야 비로소 ‘아, 이게 진짜 고가용성이구나!’ 하고 안심할 수 있었죠. 단순히 설정 몇 개 한다고 되는 게 아니더라고요.

    Proxmox HA 2노드 vs 3노드 클러스터 비교 인포그래픽

    2노드와 3노드 Proxmox HA 클러스터의 쿼럼 및 장애 허용 개수 비교입니다. 숫자의 중요성을 다시 한번 깨닫습니다.

    마무리하며 얻은 교훈

    이번 Proxmox HA 클러스터 구축 삽질을 통해 저는 중요한 교훈을 얻었습니다.

    1. 쿼럼의 중요성: 분산 시스템, 특히 HA 클러스터에서는 쿼럼(Quorum)이라는 개념을 반드시 이해하고 있어야 합니다. 노드 수에 따라 쿼럼이 어떻게 변하는지, 그리고 쿼럼이 깨졌을 때 어떤 문제가 발생하는지 정확히 알아야 해요.
    2. 최소 3개 노드: Proxmox VE HA 클러스터를 구성할 때는 스플릿 브레인을 방지하고 안정적인 HA를 위해 최소 3개 이상의 노드로 시작하는 것이 좋습니다. 2노드 클러스터는 한 노드 장애 시 쿼럼 손실로 클러스터 전체가 멈출 가능성이 매우 높습니다.
    3. 실제 테스트의 중요성: ‘말로는 쉽지’라는 말을 많이 하지만, 실제로 직접 장애 상황을 만들어서 테스트해보지 않으면 예상치 못한 문제에 직면할 수 있습니다. 저처럼요. 😅

    물론 2노드 클러스터에서도 쿼럼 디바이스(QDevice) 같은 것을 활용하여 쿼럼을 유지하는 방법이 있긴 합니다만, 복잡도가 올라가고 추가적인 리소스가 필요해서 홈랩에서는 3개 노드가 가장 심플하고 안정적인 구성이라고 생각합니다.

    여러분도 혹시 Proxmox HA 클러스터를 구축할 계획이 있으시다면, 저의 삽질 경험을 참고하셔서 안정적인 환경을 만드시길 바랍니다. 다음 글에서는 Proxmox 클러스터와 함께 사용할 수 있는 고가용성 공유 스토리지 구성에 대해 다뤄보겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 😊

  • [Proxmox VE] Proxmox HA 클러스터 구축: 무중단 서비스 운영 가이드

    [Proxmox VE] Proxmox HA 클러스터 구축: 무중단 서비스 운영 가이드

    목차

    [Proxmox VE] Proxmox HA 클러스터 구축: 무중단 서비스 운영 가이드

    안녕하세요, 13년차 인프라 엔지니어 “13년차의 서버실”입니다. 오늘도 제 홈랩에서 밤새워가며 삽질했던 경험들을 솔직하게 풀어보려고 합니다. 오늘은 많은 분들이 궁금해하실 법한 주제, 바로 Proxmox VE 고가용성(HA) 클러스터 구축에 대한 이야기입니다.

    혹시 이런 경험 있으신가요? 열심히 구축해놓은 서비스가 한밤중에 서버 한 대의 문제로 뚝 끊겨버린 경험 말이죠. 저는 그런 경험이 너무 많아서 멘탈이 나갔던 적이 한두 번이 아니었습니다. 특히 홈랩처럼 혼자서 모든 걸 책임져야 하는 환경에서는 더욱 그렇죠. 그래서 저는 언젠가부터 “무중단 서비스 운영”에 대한 집착(?)이 생겼고, 그 과정에서 Proxmox HA 클러스터를 만나게 되었습니다.

    이번 글에서는 Proxmox HA 클러스터가 무엇인지부터, 실제로 어떻게 구축하고 설정하는지, 그리고 제가 겪었던 삽질과 해결 과정까지 상세하게 알려드릴게요. 저처럼 안정적인 홈랩 환경을 꿈꾸시는 분들에게 이 글이 작은 등불이 되었으면 좋겠습니다. 자, 그럼 시작해볼까요?

    Proxmox HA 클러스터의 전체 아키텍처 다이어그램

    Proxmox HA 클러스터는 여러 노드가 함께 작동하여 서비스의 무중단성을 보장하는 구조를 가집니다.

    1. Proxmox HA 클러스터, 왜 필요할까요? (개념 설명)

    Proxmox HA 클러스터(High Availability Cluster)는 쉽게 말해 여러 대의 Proxmox 서버(노드, Node)들을 하나로 묶어, 그 중 한 대에 문제가 생겨도 서비스가 멈추지 않고 다른 서버에서 자동으로 다시 시작되도록 하는 시스템입니다. 마치 백업 선수가 항상 대기하고 있다가 주전 선수가 다치면 바로 투입되는 것과 비슷하다고 생각하시면 돼요.

    • 고가용성 (High Availability, HA): 시스템이 장애 없이 지속적으로 운영될 수 있는 능력을 의미합니다. Proxmox HA는 물리 서버 한 대가 다운되더라도, 그 서버에서 실행 중이던 가상 머신(Virtual Machine, VM)이나 컨테이너(Container, CT)를 자동으로 다른 정상 노드로 옮겨 재시작함으로써 서비스 중단을 최소화합니다.
    • 클러스터링 (Clustering): 여러 대의 컴퓨터를 묶어 하나의 시스템처럼 작동하게 하는 기술입니다. Proxmox에서는 Corosync(코로싱크)라는 분산 합의 프로토콜을 사용해서 노드 간의 상태를 동기화하고, 누가 살아있는지 죽었는지를 판단합니다.
    • 쿼럼 (Quorum): 클러스터 내에서 결정을 내리기 위한 최소한의 동의 노드 수를 의미합니다. 보통 클러스터 노드 수의 과반수(N/2 + 1)를 요구하는데, 이는 네트워크 분할(Split-Brain) 상황에서 데이터 일관성을 유지하고 잘못된 결정을 내리는 것을 방지하기 위함입니다. 그래서 Proxmox 클러스터는 보통 홀수 개의 노드로 구성하는 것이 안정적이라고 알려져 있습니다.
    • 공유 스토리지 (Shared Storage): HA 클러스터를 구성하려면 모든 노드가 접근할 수 있는 공유 스토리지가 필수입니다. VM이나 CT의 디스크 이미지가 공유 스토리지에 있어야, 한 노드가 다운되었을 때 다른 노드가 그 디스크 이미지를 가져와서 VM을 재시작할 수 있거든요. 저는 보통 NFS(Network File System)나 iSCSI를 많이 활용합니다.

    이런 개념들이 처음엔 좀 어렵게 느껴질 수 있지만, 실제로 구축해보면 “아하!” 하고 무릎을 탁 치게 될 겁니다. 저도 그랬거든요.

    2. Proxmox HA 클러스터 구축 실전 가이드

    이제 본격적으로 Proxmox HA 클러스터를 구축하는 방법을 단계별로 살펴보겠습니다. 제 홈랩 기준으로 최소 2대 이상의 Proxmox VE가 설치된 서버와 공유 스토리지가 준비되어 있다고 가정할게요. (물론 안정적인 쿼럼을 위해 3대 이상을 권장합니다!)

    2.1 Proxmox VE 설치 및 네트워크 설정

    1. 각 노드에 Proxmox VE 설치: 최소 2대 이상의 물리 서버에 Proxmox VE를 설치합니다. 버전은 최신 안정 버전을 사용하는 것이 좋습니다.
    2. 네트워크 설정: 각 노드에 최소 두 개의 네트워크 인터페이스(NIC)를 준비하는 것을 권장합니다. 하나는 관리 및 일반 서비스용, 다른 하나는 클러스터 통신(Corosync) 전용으로 사용하면 더 안정적입니다.
    # 예시: /etc/network/interfaces
auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10/24
    gateway 192.168.1.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0

auto vmbr1 # Corosync 전용 네트워크
iface vmbr1 inet static
    address 10.10.10.10/24
    bridge-ports eno2
    bridge-stp off
    bridge-fd 0

    저는 항상 클러스터 통신은 별도의 네트워크로 분리하는 편입니다. 그래야 클러스터의 안정성이 높아지더라고요.

    2.2 Proxmox 클러스터 생성 및 노드 추가

    이제 Proxmox 웹 인터페이스 또는 SSH로 접속하여 클러스터를 구성해볼 시간입니다. 첫 번째 노드(예: `pve-node01`)에서 클러스터를 생성하고, 다른 노드들(`pve-node02`, `pve-node03` 등)을 추가하는 방식입니다.

    1. 첫 번째 노드에서 클러스터 생성: Proxmox 웹 UI에 로그인하여 데이터센터 > 클러스터 > 클러스터 생성으로 이동하거나, SSH로 접속하여 다음 명령어를 실행합니다. 저는 보통 SSH로 작업하는 걸 선호해요.

      pvecm create  --ring0_addr

      예시:

      pvecm create my-ha-cluster --ring0_addr 10.10.10.10

      여기서 <NODE_IP_FOR_COROSYNC_NETWORK>는 Corosync 전용으로 설정한 IP 주소를 입력해야 합니다. 이게 중요합니다! 잘못 입력하면 나중에 클러스터 통신이 안 될 수 있거든요.

    2. 두 번째 노드에서 클러스터에 참여: 두 번째 노드(예: `pve-node02`)에서 SSH로 접속하여 다음 명령어를 실행합니다.

      pvecm add  --ring0_addr

      예시:

      pvecm add 10.10.10.10 --ring0_addr 10.10.10.11

      이때 첫 번째 노드의 루트 비밀번호를 요구할 수 있습니다. 정확히 입력해주세요.

    3. 클러스터 상태 확인: 모든 노드에서 다음 명령어로 클러스터 상태를 확인할 수 있습니다. 모든 노드가 `online` 상태여야 합니다.

      pvecm status

      결과에 `Quorum: 1`이 뜨면 성공입니다! 🎉

    Proxmox 웹 인터페이스의 클러스터 상태 화면

    웹 인터페이스에서 모든 노드가 클러스터에 성공적으로 추가되고 ‘온라인’ 상태임을 확인할 수 있습니다.

    2.3 공유 스토리지 설정

    Proxmox HA의 핵심은 공유 스토리지입니다. 저는 제 홈랩에서 Synology NAS를 활용해 NFS 공유 스토리지를 구성했습니다. 여러분도 NAS나 다른 서버를 이용해서 NFS 또는 iSCSI를 구성하시면 됩니다.

    1. 공유 스토리지(NFS) 추가: Proxmox 웹 UI에 로그인하여 데이터센터 > 스토리지 > 추가 > NFS를 선택합니다. 그리고 다음 정보를 입력합니다.

      • ID: `nfs-share` (원하는 이름)
      • 서버: `192.168.1.200` (NAS의 IP 주소)
      • 내보내기: `/volume1/proxmox-ha` (NAS에서 공유한 경로)
      • 콘텐츠: `디스크 이미지, 컨테이너 템플릿, ISO 이미지` (모두 선택)

      이렇게 설정하면 모든 Proxmox 노드가 이 공유 스토리지에 접근할 수 있게 됩니다.

    2. VM/CT 디스크 이동: HA 기능을 사용하려면 VM이나 CT의 디스크가 공유 스토리지에 있어야 합니다. 기존 VM이 로컬 스토리지에 있다면, 해당 VM을 종료(Stop)한 후 하드웨어 > 하드 디스크 > 디스크 동작 > 디스크 이동(Move Disk)을 통해 공유 스토리지로 옮겨주세요. 이 과정이 은근히 시간이 걸리더라고요. 인내심이 필요합니다 ㅎㅎ.

    2.4 HA (고가용성) 설정

    이제 클러스터와 공유 스토리지까지 준비되었으니, 특정 VM에 HA 정책을 적용해볼 차례입니다. Proxmox의 ha-manager를 사용합니다.

    1. HA 그룹 생성 (선택 사항): 특정 노드 그룹에만 HA를 적용하고 싶다면 HA 그룹을 생성할 수 있습니다. 저는 보통 모든 노드를 포함하는 기본 그룹을 사용합니다.

      ha-manager group add  --nodes , --restricted 0

    2. VM/CT에 HA 정책 적용: 웹 UI에서 특정 VM을 선택한 후 HA 탭으로 이동하여 추가(Add) 버튼을 누르거나, SSH로 다음 명령어를 실행합니다.

      ha-manager add vm: --group  --state started

      예시:

      ha-manager add vm:100 --group my-ha-group --state started

      --state started는 노드 장애 시 VM을 자동으로 재시작하라는 의미입니다. stopped, frozen 등의 상태도 있습니다. 저는 보통 `started`를 사용해서 무조건 살려내도록 합니다.

    3. HA 상태 확인: 웹 UI의 데이터센터 > HA 탭에서 현재 HA에 등록된 VM들의 상태와 소유 노드를 확인할 수 있습니다. 또는 SSH에서 다음 명령어를 실행합니다.

      ha-manager status

      여기서 모든 리소스가 정상적으로 `started` 상태인지 확인하는 것이 중요합니다. ✅

    Proxmox HA 정책 설정 및 리소스 할당 다이어그램

    HA 정책을 설정하는 화면에서는 각 VM/CT에 대한 고가용성 규칙과 상태를 명확히 지정할 수 있습니다.

    3. 삽질 경험과 트러블슈팅 ⚠️

    제가 Proxmox HA를 구축하면서 겪었던 몇 가지 삽질과 그 해결책을 공유합니다. 저도 처음엔 이게 뭔가 싶었는데, 결국엔 다 해결되더라고요!

    • 쿼럼(Quorum) 문제: 가장 흔한 문제입니다. 짝수 개의 노드로 클러스터를 구성하거나, 한 노드가 다운되면서 쿼럼이 깨지는 경우가 정말 많더라고요. 저는 처음에 2노드 클러스터로 시작했다가 한 노드만 죽어도 모든 게 멈춰버려서 당황했었죠. 쿼럼이 깨지면 클러스터는 더 이상 작동하지 않습니다. 그래서 3대 이상의 홀수 노드 구성이 중요합니다. 만약 2노드 클러스터밖에 안 된다면, pvecm expected 명령어로 쿼럼 투표 수를 강제로 조정할 수도 있지만, 이는 권장하지 않습니다. 정말 비상시에만 사용하세요.

      # 쿼럼이 깨졌을 때, 남아있는 노드에서 강제로 쿼럼을 설정 (비상용)
pvecm expected 1

    • Corosync 네트워크 문제: 클러스터 통신이 원활하지 않으면 노드 간의 상태 동기화가 안 돼서 HA가 제대로 작동하지 않습니다. 저는 방화벽(Firewall)에서 Corosync 포트(UDP 5405-5407)를 열어주지 않아서 한참을 헤맸습니다. ping 테스트와 함께 netcat 등으로 포트 연결을 확인해보세요. 전용 네트워크 인터페이스를 사용하는 것이 훨씬 안정적입니다.

    • 공유 스토리지 연결 실패: NFS나 iSCSI 스토리지가 제대로 마운트되지 않거나, 네트워크 문제로 접근이 안 되는 경우입니다. 이 경우 HA에 등록된 VM이 다른 노드에서 재시작되려 해도 디스크를 찾지 못해 실패합니다. showmount -e 명령어로 NFS 공유를 확인하고, 각 노드에서 스토리지가 정상적으로 마운트되어 있는지 df -h 등으로 확인해야 합니다.

    • Split-Brain (스플릿-브레인): 클러스터가 네트워크 문제로 두 개 이상의 작은 클러스터로 분리되어 각자 독립적으로 작동하려 하는 상황입니다. Proxmox는 쿼럼 개념과 STONITH (Shoot The Other Node In The Head)라는 메커니즘으로 이를 방지하려고 노력합니다. STONITH는 장애가 발생한 노드를 강제로 전원 차단하여 데이터 무결성을 지키는 방법입니다. IPMI나 PDU를 이용한 STONITH 설정을 고려해볼 수 있습니다.

    4. 결과 확인 및 검증 🎉

    모든 설정이 완료되었다면, 이제 HA가 제대로 작동하는지 확인해볼 차례입니다. 이게 제일 신나는 순간이죠!

    1. HA 등록 VM 확인: Proxmox 웹 UI에서 데이터센터 > HA 탭으로 가서 HA에 등록된 VM이 `started` 상태이고, 원하는 노드에서 실행 중인지 확인합니다.

    2. 강제 노드 다운 테스트: HA가 작동하는지 가장 확실하게 확인하는 방법은 의도적으로 한 노드를 다운시키는 겁니다. HA에 등록된 VM이 실행 중인 노드를 선택하여 전원 버튼을 꾹 눌러 강제 종료하거나, SSH에서 reboot -f 명령어를 실행해보세요. (물론 중요한 운영 환경에서는 미리 충분히 테스트해야겠죠!)

      노드가 다운되면 잠시 후 웹 UI의 데이터센터 > HA 탭에서 해당 VM이 다른 정상 노드로 옮겨져 자동으로 다시 시작되는 것을 볼 수 있을 겁니다. 저도 처음 성공했을 때 “드디어 됐다!” 하고 외쳤던 기억이 나네요. 정말 편하더라고요.

    HA 클러스터가 정상 작동할 경우, 노드 장애 시 VM이 자동으로 다른 노드에서 재시작되는 모습을 확인할 수 있습니다.

    5. 마무리하며: 무중단 서비스, 더 이상 꿈이 아닙니다!

    오늘은 Proxmox VE 고가용성(HA) 클러스터 구축에 대해 저의 경험을 바탕으로 이야기해봤습니다. 처음엔 복잡해 보일 수 있지만, 단계별로 차근차근 따라 하다 보면 충분히 구축할 수 있는 시스템입니다. 제가 직접 해보니, 한 번 구축해두면 밤에 발 뻗고 잘 수 있다는 점이 가장 큰 장점이었습니다. 혹시 여러분도 무중단 서비스 운영에 대한 갈증이 있었다면, Proxmox HA 클러스터가 아주 좋은 해결책이 될 거라고 확신합니다.

    물론 HA 클러스터가 모든 장애를 막아주는 만능 해결책은 아닙니다. 공유 스토리지 자체의 장애나 네트워크 전체 장애 같은 경우도 또 다른 고려가 필요하죠. 하지만 대부분의 단일 노드 장애 상황에서는 정말 든든한 보험 같은 역할을 해줍니다.

    이 글이 여러분의 Proxmox 홈랩 구축에 도움이 되었기를 바랍니다. 다음번에는 Proxmox 백업 전략이나 Ceph 분산 스토리지 구축 같은 더 심화된 주제로 찾아오겠습니다. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요!

    Proxmox HA 클러스터의 장점과 고려사항 요약 인포그래픽

    Proxmox HA 클러스터는 안정적인 서비스 운영을 위한 강력한 도구이지만, 그만큼 고려해야 할 점들도 많습니다.