13년차의 서버실

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

[카테고리:] proxmox

  • [네트워크] Proxmox 방화벽 규칙: 복잡한 홈랩 네트워크 보안 최적화

    [네트워크] Proxmox 방화벽 규칙: 복잡한 홈랩 네트워크 보안 최적화

    [네트워크] Proxmox 방화벽 규칙: 복잡한 홈랩 네트워크 보안 최적화

    안녕하세요, 13년차의 서버실입니다. 홈랩을 운영하다 보면 네트워크 환경이 점점 복잡해지는 거, 저만 그런 거 아니죠? 처음엔 단출하게 시작했다가, VM(Virtual Machine)도 늘어나고, LXC(Linux Container)도 추가하고, 심지어는 IoT 기기들까지 연결하면서 보안은 뒷전이 되기 쉬운데요. 특히 Proxmox VE 위에서 다양한 서비스를 돌리다 보면, 각 VM이나 컨테이너 간의 트래픽을 어떻게 제어하고 보호할지가 큰 숙제가 됩니다.

    오늘은 제가 직접 경험했던 복잡한 홈랩 환경에서 Proxmox 방화벽 규칙을 활용해서 네트워크 보안을 강화하고 트래픽을 최적화했던 실전 사례를 공유해볼까 합니다. 삽질 좀 하면서 배웠던 내용들을 솔직하게 풀어낼 테니, 혹시 비슷한 고민을 하고 계신다면 이 글이 조금이나마 도움이 되셨으면 좋겠습니다!

    Proxmox 방화벽 규칙이 적용된 복잡한 홈랩 네트워크 아키텍처 다이어그램

    홈랩 환경에서 Proxmox VE 호스트를 중심으로 VM, LXC, 라우터, 그리고 외부 인터넷까지 연결된 복잡한 네트워크 아키텍처를 보여주는 다이어그램입니다. 방화벽 아이콘이 중요하게 배치되어 있습니다.

    Proxmox 방화벽 규칙 개념 파고들기: 쉽게 말해, 네트워크의 문지기

    Proxmox 방화벽은 단순히 호스트(Host) 레벨에서만 작동하는 게 아니라, 개별 VM이나 LXC(컨테이너) 레벨에서도 세밀하게 제어할 수 있다는 게 큰 장점입니다. 쉽게 말해, 네트워크 트래픽의 문지기 역할을 하는 거죠.

    • 호스트(Host) 레벨 방화벽: Proxmox VE 서버 자체에 적용되는 방화벽입니다. 모든 VM/LXC 트래픽이 이 방화벽을 통과하거든요. 가장 바깥쪽에서 전체적인 보안 정책을 설정할 때 유용해요.
    • VM/LXC(Guest) 레벨 방화벽: 개별 가상 머신이나 컨테이너에 적용되는 방화벽입니다. 특정 서비스나 애플리케이션에 대한 접근을 세밀하게 제어할 때 쓰더라고요.

    그리고 Proxmox 방화벽 규칙을 이야기할 때 빼놓을 수 없는 개념이 바로 Ingress(인그레스, 외부에서 내부로 들어오는 트래픽)와 Egress(이그레스, 내부에서 외부로 나가는 트래픽)입니다. 인그레스는 외부 공격으로부터 내부를 보호하는 데 중요하고, 이그레스는 내부 시스템이 불필요하거나 악의적인 외부 통신을 하는 것을 막는 데 필요하죠.

    Proxmox 방화벽은 기본적으로 `iptables` 기반으로 동작합니다. 우리가 GUI나 CLI로 설정하는 내용들이 결국은 호스트의 `iptables` 규칙으로 변환되어 적용되는 방식이거든요. 이걸 직접 `iptables` 명령어로 관리할 수도 있지만, Proxmox의 통합된 관리 기능 덕분에 훨씬 편하게 관리할 수 있어요.

    실전 구현: 복잡한 홈랩 서비스 보안 강화 사례

    저희 홈랩에는 다음과 같은 서비스들이 운영되고 있었어요.

    • Web Server VM: Nginx 프록시 서버로, 외부에서 80/443 포트로 접근 가능해야 합니다.
    • Database Server LXC: PostgreSQL이 동작하며, Web Server VM과 일부 내부 관리 VM에서만 5432 포트로 접근 가능해야 합니다. 외부 접근은 절대 금지!
    • Management VM: 내부에서만 SSH(22번 포트)로 접근 가능하며, 다른 내부 VM들과 제한적인 통신이 필요합니다.
    • Monitoring LXC: Prometheus, Grafana가 동작하며, 내부 관리 VM에서 3000번 포트로 Grafana 접근이 가능해야 합니다.

    이런 환경에서 제가 Proxmox 방화벽 규칙을 어떻게 적용했는지 단계별로 보여드릴게요.

    1. 호스트 레벨 기본 정책 설정

    가장 먼저 Proxmox VE 호스트의 방화벽을 활성화하고, 기본 정책을 설정합니다. 저는 Implicit Deny(암묵적 거부) 원칙을 좋아해서, 모든 트래픽을 기본적으로 차단하고 필요한 것만 허용하는 방식으로 설정했어요.

    # 호스트 방화벽 활성화
    pve-firewall start
    
    # 기본 인그레스(Ingress) 정책: 모두 거부 (Drop)
    pve-firewall set --input DROP
    
    # 기본 이그레스(Egress) 정책: 모두 허용 (Accept) - 내부에서 외부로 나가는 트래픽은 일단 허용
    pve-firewall set --output ACCEPT
    
    # Proxmox GUI/SSH 접근을 위한 규칙 추가 (예시: 8006은 GUI, 22는 SSH)
    pve-firewall rule add --action ACCEPT --proto tcp --dport 8006 --source 192.168.1.0/24
    pve-firewall rule add --action ACCEPT --proto tcp --dport 22 --source 192.168.1.0/24
    

    --source 192.168.1.0/24는 특정 내부 네트워크 대역에서만 접근을 허용한다는 의미입니다. 이렇게 하면 외부에서 Proxmox GUI나 SSH로 직접 접근하는 것을 막을 수 있거든요.

    2. IPSet을 활용한 그룹 관리

    여러 VM이나 LXC에서 공통적으로 접근해야 하는 IP 그룹이 있을 때, IPSet(아이피셋)을 사용하면 관리하기가 정말 편하더라고요. 저는 내부 관리용 IP 그룹을 만들어서 사용했어요.

    # 'management-ips'라는 IPSet 생성
    pve-firewall ipset add management-ips
    
    # IPSet에 내부 관리용 IP 추가 (예시)
    pve-firewall ipset add management-ips --cidr 192.168.1.100
    pve-firewall ipset add management-ips --cidr 192.168.1.101
    

    이렇게 설정하면 나중에 Proxmox 방화벽 규칙에서 --source +management-ips 처럼 깔끔하게 사용할 수 있어서 설정이 훨씬 간편해집니다.

    3. 개별 VM/CT 방화벽 규칙 설정

    이제 각 VM/LXC에 맞는 세부 규칙을 설정할 차례입니다.

    Web Server VM (ID: 101)

    • 외부에서 80/443 포트 허용
    • 내부 DB Server LXC(ID: 102)로 5432 포트 Egress 허용
    # VM 101의 방화벽 활성화
    pve-firewall set --vmid 101 --enable 1
    
    # 외부에서 80 (HTTP) 포트 인그레스(Ingress) 허용
    pve-firewall rule add --vmid 101 --action ACCEPT --proto tcp --dport 80 --comment "Allow HTTP from external"
    
    # 외부에서 443 (HTTPS) 포트 인그레스(Ingress) 허용
    pve-firewall rule add --vmid 101 --action ACCEPT --proto tcp --dport 443 --comment "Allow HTTPS from external"
    
    # DB Server LXC (ID 102)로 5432 포트 이그레스(Egress) 허용
    pve-firewall rule add --vmid 101 --action ACCEPT --proto tcp --dport 5432 --dest 192.168.1.102 --direction out --comment "Allow DB access to DB Server"
    

    Database Server LXC (ID: 102)

    • Web Server VM(ID: 101)과 내부 관리 IPSet에서만 5432 포트 인그레스 허용
    • 기타 모든 인그레스 트래픽 거부
    # LXC 102의 방화벽 활성화
    pve-firewall set --vmid 102 --enable 1
    
    # Web Server VM (ID 101)으로부터 5432 포트 인그레스(Ingress) 허용
    pve-firewall rule add --vmid 102 --action ACCEPT --proto tcp --dport 5432 --source 192.168.1.101 --comment "Allow DB access from Web Server"
    
    # 내부 관리 IPSet으로부터 5432 포트 인그레스(Ingress) 허용
    pve-firewall rule add --vmid 102 --action ACCEPT --proto tcp --dport 5432 --source +management-ips --comment "Allow DB access from Management IPs"
    
    # 기본 인그레스(Ingress) 정책을 명시적으로 Drop으로 설정 (이게 중요!)
    pve-firewall set --vmid 102 --input DROP
    

    여기서 --input DROP을 명시적으로 설정해주는 게 정말 중요합니다. 이 규칙이 없으면 호스트 레벨의 기본 정책을 따르게 되는데, 만약 호스트 레벨이 ACCEPT라면 의도치 않게 DB가 외부에 노출될 수 있거든요. 저는 이 부분에서 삽질 좀 했습니다 ㅎㅎ.

    Proxmox VE 웹 인터페이스에서 방화벽 규칙을 설정하는 화면

    Proxmox VE 웹 인터페이스에서 특정 VM의 방화벽 규칙 설정 화면을 보여주는 스크린샷입니다. 인그레스/이그레스 규칙, 액션 (ACCEPT/DROP) 유형 등이 명확하게 표시되어 있습니다.

    ⚠️ 주의사항 & 트러블슈팅: 삽질하며 배운 것들

    Proxmox 방화벽 규칙을 설정하면서 제가 겪었던 주요 삽질 경험과 해결책을 공유합니다. 혹시 비슷한 문제에 봉착하셨다면 참고해주세요!

    1. 규칙 순서의 중요성: Proxmox 방화벽 규칙은 위에서 아래로 순서대로 적용됩니다. 특정 트래픽을 DROP하는 규칙이 먼저 있다면, 그 뒤에 ACCEPT 규칙이 아무리 있어도 해당 트래픽은 이미 차단된 후라 소용이 없어요. 저는 특정 포트를 열었는데도 통신이 안 되길래 한참 헤맸습니다. 항상 넓은 범위의 DROP 규칙보다 좁은 범위의 ACCEPT 규칙이 먼저 오도록 배치해야 한다는 걸 배웠거든요. Proxmox GUI에서 규칙 순서를 쉽게 조정할 수 있으니 참고하세요.

    2. 로그 확인은 필수: 방화벽 규칙이 제대로 동작하는지, 어떤 트래픽이 차단되는지 확인하는 가장 좋은 방법은 로그를 보는 거예요. pve-firewall log 명령어를 사용하면 방화벽에 의해 처리된 트래픽 로그를 실시간으로 확인할 수 있습니다.

      # Proxmox 호스트에서 방화벽 로그 확인
      pve-firewall log
      
      # 특정 VM의 로그만 보고 싶다면
      pve-firewall log --vmid 101
      

      이 로그를 통해 어떤 규칙에 의해 트래픽이 `DROP`되었는지, `ACCEPT`되었는지 알 수 있어서 트러블슈팅에 정말 도움이 됩니다.

    3. `INPUT`/`OUTPUT` vs `IN`/`OUT`: Proxmox GUI나 CLI에서 direction 옵션으로 in(인그레스) 또는 out(이그레스)을 설정합니다. 하지만 pve-firewall set --input DROP 처럼 전체 정책을 설정할 때는 input과 output을 사용하죠. 이게 처음엔 좀 헷갈리더라고요. Proxmox 방화벽 규칙 설정할 때 헷갈리지 않게 잘 구분해서 사용해야 합니다.

    4. Security Group 활용: 만약 여러 VM이나 LXC에 동일한 Proxmox 방화벽 규칙 세트를 적용하고 싶다면 Security Group(보안 그룹) 기능을 활용하면 정말 효율적입니다. 한 번 만들어두면 여러 게스트에 재사용할 수 있거든요. 다음 번에 기회가 된다면 Security Group을 깊이 다뤄볼게요.

    검증 & 결과: 드디어 성공적인 네트워크 보안 구축!

    Proxmox 방화벽 규칙을 적용한 뒤에는 반드시 제대로 동작하는지 검증해야 합니다. 저는 주로 다음과 같은 방법으로 확인합니다.

    1. Proxmox GUI 확인: 가장 직관적인 방법이죠. 각 VM/LXC의 방화벽 탭에서 규칙들이 제대로 등록되었는지 확인해요.

    2. pve-firewall status 명령어로 전체 상태 확인:

      # Proxmox 호스트 방화벽 상태 확인
      pve-firewall status
      
      # 특정 VM의 방화벽 상태 확인
      pve-firewall status --vmid 101
      
    3. iptables -L -n -v 명령어로 실제 적용된 규칙 확인: Proxmox 호스트에 SSH로 접속해서 실제 `iptables` 규칙이 어떻게 적용되었는지 확인하는 건 매우 중요합니다. Proxmox 방화벽이 내부적으로 `iptables`를 사용하기 때문에, 이 명령어를 통해 최종적으로 적용된 규칙의 세부 사항을 볼 수 있거든요.

      # Proxmox 호스트에서 iptables 규칙 확인
      iptables -L -n -v
      

      이 명령어를 보면 Proxmox가 생성한 `PVEFW-*` 체인들을 볼 수 있어요. 이 체인들이 우리가 설정한 Proxmox 방화벽 규칙을 담고 있는 거죠.

    4. 외부/내부에서 nmap 스캔: 가장 확실한 검증 방법입니다. 의도적으로 차단되어야 할 포트가 열려있는지, 허용되어야 할 포트가 닫혀있는지 nmap으로 스캔해보는 거거든요.

      # 외부에서 Web Server VM (192.168.1.101)의 80, 443, 22, 5432 포트 스캔
      nmap -p 80,443,22,5432 192.168.1.101
      
      # Web Server VM (192.168.1.101)에서 DB Server LXC (192.168.1.102)의 5432 포트 스캔
      nmap -p 5432 192.168.1.102
      

      이 검증을 통해 제가 의도했던 대로 Web Server VM의 80, 443 포트만 외부에서 접근 가능하고, DB Server LXC의 5432 포트는 Web Server VM과 관리용 IP에서만 접근 가능하도록 설정되었음을 확인했습니다. 드디어 됐다! 🎉

    Proxmox 방화벽 규칙 적용 후 네트워크 트래픽 흐름 및 방화벽 로그 시각화

    방화벽 규칙 적용 후, Proxmox VE 호스트와 VM/LXC 간의 네트워크 트래픽 흐름을 시각적으로 보여주는 다이어그램입니다. 로그 스니펫이 함께 표시되어 방화벽이 성공적으로 작동하고 있음을 나타냅니다.

    마무리하며: 더 안전하고 효율적인 홈랩을 위해

    오늘은 Proxmox 방화벽 규칙을 활용해서 복잡한 홈랩 환경의 네트워크를 최적화하고 보안을 강화했던 제 경험을 공유해드렸습니다. 처음엔 Proxmox 방화벽이 낯설고 `iptables`와의 관계도 헷갈려서 삽질 좀 했지만, 한번 제대로 설정해두니 든든하더라고요. 홈랩이 점점 커지면서 보안에 대한 고민이 많았는데, Proxmox 방화벽 덕분에 한시름 놓았습니다.

    Proxmox 방화벽 규칙을 활용한 보안의 핵심은 Implicit Deny(암묵적 거부) 원칙을 가지고 필요한 트래픽만 명시적으로 허용하는 것이에요. 그리고 IPSet이나 Security Group 같은 기능을 활용해서 관리 효율을 높이는 것도 중요하죠. 무엇보다 중요한 건, 규칙을 설정한 뒤에는 반드시 로그를 확인하고 다양한 방법으로 검증하는 것입니다!

    이 글이 여러분의 Proxmox 홈랩 보안 강화에 작은 도움이 되었기를 바랍니다. 다음 글에서는 Proxmox와 VPN을 연동해서 원격에서도 안전하게 홈랩에 접근하는 방법에 대해 다뤄볼까 합니다. 기대해주세요!

    Proxmox 방화벽 규칙 설정 핵심 요약 및 유용한 팁 인포그래픽

    Proxmox 방화벽 규칙 설정의 핵심 요약, IPSet 및 Security Group 활용 팁, 그리고 트러블슈팅 가이드가 포함된 인포그래픽입니다. 깔끔하고 이해하기 쉬운 디자인으로 제작되었습니다.

  • [Proxmox] Proxmox VE & Ceph 분산 스토리지 1년 회고: 안정성, 성능, 교훈

    [Proxmox] Proxmox VE & Ceph 분산 스토리지 1년 회고: 안정성, 성능, 교훈

    Proxmox VE & Ceph 분산 스토리지 1년 회고: 안정성, 성능, 교훈

    안녕하세요, 13년차의 서버실 주인장입니다. 오랜만에 홈랩(HomeLab) 이야기를 들고 왔네요. 오늘은 제가 지난 1년간 Proxmox VE와 Ceph를 조합해서 분산 스토리지를 구축하고 운영했던 경험을 회고해보려고 합니다. Proxmox Ceph 조합은 홈랩에서 강력한 스토리지 솔루션을 구축하려는 분들께 정말 매력적인 선택지인데요, 저 역시 안정성과 성능 두 마리 토끼를 잡고 싶어서 이 조합에 도전했었죠. 결과는 어땠을까요? 기대했던 만큼의 성과를 얻었을까요, 아니면 삽질의 연속이었을까요? 솔직한 제 경험담을 지금부터 풀어보겠습니다.

    혹시 여러분도 저처럼 늘어나는 가상 머신(VM, Virtual Machine)과 컨테이너(Container) 때문에 스토리지 확장에 대한 고민이 많으셨나요? 단일 서버의 저장 공간으로는 한계가 있고, 그렇다고 비싼 네트워크 스토리지(NAS, Network Attached Storage)를 여러 대 들이자니 배보다 배꼽이 더 커지는 상황. 저도 그랬습니다. 그래서 저렴한 하드웨어로 고가용성(High Availability)과 확장성(Scalability)을 동시에 잡을 수 있는 방법을 찾다가 분산 스토리지(Distributed Storage) 솔루션인 Ceph를 Proxmox VE 클러스터 위에 얹어보기로 마음먹었죠.

    왜 Proxmox VE와 Ceph를 선택했을까요? (컨셉 설명)

    제가 Proxmox VE와 Ceph 조합에 끌렸던 가장 큰 이유는 바로 시너지 효과 때문입니다. 쉽게 말해, Proxmox VE는 강력한 가상화 플랫폼이고, Ceph는 데이터를 여러 서버에 나눠 저장하면서 안정성과 성능을 높이는 시스템이거든요. 이 둘이 만나면 어떤 일이 벌어질까요?

    • Proxmox VE (프록스목스 VE): 리눅스 기반의 오픈소스 가상화 플랫폼입니다. VM과 컨테이너를 쉽게 관리할 수 있고, 여러 Proxmox 서버를 묶어 클러스터(Cluster)를 구성하면 VM을 서버 간에 자유롭게 이동시키거나(Live Migration, 라이브 마이그레이션), 한 서버에 문제가 생겨도 다른 서버에서 자동으로 VM을 재시작하는 고가용성 기능을 구현할 수 있습니다.
    • Ceph (쎄프): 역시 오픈소스 분산 스토리지 시스템입니다. 데이터를 여러 노드에 분산해서 저장하기 때문에 한두 개의 저장 장치에 문제가 생겨도 데이터가 손실될 염려가 적고, 여러 노드의 자원을 활용해서 높은 입출력 성능(IOPS, Input/Output Operations Per Second)을 낼 수 있습니다. 오브젝트 스토리지(Object Storage), 블록 스토리지(Block Storage), 파일 시스템(File System)까지 다양한 인터페이스를 제공하죠.

    이 둘을 함께 사용하면 Proxmox VE 클러스터를 구성하는 서버들의 로컬 디스크를 묶어서 하나의 거대한 Ceph 스토리지 풀(Storage Pool)로 만들 수 있습니다. 그렇게 되면 VM 디스크 이미지를 이 Ceph 스토리지에 저장하고, 어떤 Proxmox 서버에서든 해당 VM을 실행할 수 있게 되는 거죠. 한 서버에 문제가 생겨도 다른 서버가 Ceph 스토리지에 접근해서 VM을 바로 가져다 쓸 수 있으니, 고가용성(High Availability) 측면에서 정말 매력적이었어요.

    Proxmox VE와 Ceph 분산 스토리지 클러스터의 전체 아키텍처 다이어그램

    Proxmox VE 서버 3대와 Ceph 클러스터가 통합된 홈랩 아키텍처 다이어그램입니다. 각 Proxmox 노드가 Ceph OSD를 호스팅하며, VM들이 이 분산 스토리지 위에 위치합니다.

    제 홈랩에 Ceph 클러스터 구축하기: 삽질의 시작과 과정

    솔직히 처음엔 “오픈소스니까 뭐, 설치하면 되겠지!” 하는 안일한 생각도 좀 있었습니다. 13년차 엔지니어라도 새로운 기술 앞에서는 겸손해야 한다는 걸 다시 한번 깨달았죠. 😅

    하드웨어 구성: 어떤 장비로 시작했을까?

    저는 최소 3개의 노드(Node)로 구성된 클러스터를 목표로 했습니다. Ceph는 복제(Replication)를 통해 데이터 안정성을 확보하는데, 보통 3-복제(3-replication)를 많이 쓰거든요. 그래서 3대의 미니 PC를 준비했습니다. 각 PC는 인텔 NUC 같은 저전력 모델에 16GB RAM, 그리고 데이터를 저장할 SSD를 여러 개 장착했어요. 처음에는 1GbE(기가비트 이더넷) 네트워크로 시작했지만, 나중에는 10GbE(텐 기가비트 이더넷)로 업그레이드했습니다. Ceph는 네트워크 대역폭을 정말 많이 쓰는 친구거든요!

    Proxmox VE 설치 및 클러스터 구성

    Proxmox VE 설치는 생각보다 간단합니다. ISO 이미지를 USB에 구워서 각 노드에 설치하고, 웹 UI에 접속해서 몇 번의 클릭만으로 Proxmox 클러스터를 구성할 수 있죠. 이때 쿼럼(Quorum) 유지를 위해 최소 3개 이상의 노드가 안정적이라는 점을 꼭 기억해야 합니다. (홀수 노드가 좋습니다.)

    # 첫 번째 노드에서 클러스터 생성
    pvecm create home-ceph-cluster
    
    # 다른 노드에서 클러스터에 조인 (첫 번째 노드 IP와 패스워드 필요)
    pvecm add 192.168.1.10 --token <토큰_값>
    

    이 과정 자체는 매끄러웠습니다. Proxmox의 클러스터 관리 기능은 정말 잘 되어 있더라고요.

    Ceph 설치 및 OSD 추가: Proxmox Ceph 통합의 시작!

    이제 대망의 Ceph 차례입니다. Proxmox VE는 Ceph 통합 기능이 워낙 잘 되어 있어서 CLI(Command Line Interface)나 웹 UI에서 몇 번의 명령으로 Ceph를 설치하고 OSD(Object Storage Device)를 추가할 수 있습니다.

    # 각 Proxmox 노드에서 Ceph 설치
    pveceph install
    
    # Ceph Monitor(모니터) 설치 (클러스터 노드 중 최소 3개에 설치 권장)
    pveceph createmon
    
    # OSD 추가 (각 노드의 사용 가능한 디스크를 OSD로 지정)
    # 예: /dev/sdb 디스크를 OSD로 추가하고, NVMe SSD를 DB/WAL로 사용
    pveceph createosd /dev/sdb --db-device /dev/nvme0n1 --wal-device /dev/nvme0n1
    

    처음에는 단순히 `pveceph createosd /dev/sdb` 이런 식으로 HDD를 OSD로 추가했는데, 성능이 영 시원찮았습니다. Ceph의 BlueStore(블루스토어) 백엔드는 메타데이터를 빠르게 처리하는 것이 중요한데, HDD만으로는 한계가 명확하더라고요. 그래서 나중에는 NVMe SSD를 DB/WAL(데이터베이스/쓰기Ahead로그) 용도로 할당해서 성능을 끌어올렸습니다. 이 부분이 Ceph 성능 튜닝의 핵심 중 하나라는 걸 몸소 깨달았죠. 💡

    Proxmox VE 웹 UI에서 활성화된 Ceph OSD 목록을 보여주는 화면

    Proxmox VE 웹 UI의 Ceph 섹션입니다. 각 노드의 OSD 목록과 상태(UP/IN)를 한눈에 확인할 수 있습니다. 저 많은 OSD들이 제 소중한 데이터를 분산해서 저장하고 있죠.

    1년간 Proxmox Ceph를 운영하며 겪은 안정성 및 성능 이야기

    1년이라는 시간은 Ceph 클러스터의 진정한 가치를 시험하기에 충분했습니다. 정말 많은 것을 배우고 느꼈네요.

    안정성 (Stability) 회고: 역시 분산 스토리지!

    Ceph의 가장 큰 장점 중 하나는 데이터 안정성(Data Durability)입니다. 저도 OSD 하나가 갑자기 죽는 경험을 몇 번 했습니다. 그때마다 심장이 덜컥 내려앉았지만, Ceph는 3-복제 덕분에 자동으로 데이터 복구(Self-healing)를 시작하더라고요. 물론 복구 시간 동안 클러스터 성능이 저하되긴 했지만, 데이터 손실 없이 무사히 복구를 완료하는 모습을 보면서 “이래서 Proxmox Ceph 조합을 쓰는구나!” 하고 감탄했습니다. 👏

    Proxmox VE의 HA (High Availability, 고가용성) 기능도 빛을 발했습니다. 특정 Proxmox 노드가 재부팅되거나 문제가 생겼을 때, 해당 노드에서 실행 중이던 VM들이 다른 노드에서 자동으로 재시작되는 것을 여러 번 확인했습니다. Ceph 스토리지 덕분에 VM 디스크에 대한 접근성이 보장되었기 때문에 가능한 일이었죠. 물론 순간적인 서비스 중단은 있었지만, 시스템 전체의 가용성을 크게 높여주었습니다.

    성능 (Performance) 회고: 기대와 현실 사이

    초기에는 HDD OSD만으로 Ceph를 구성했더니, VM의 디스크 I/O가 심하게 느려지는 문제가 있었습니다. 특히 여러 VM이 동시에 디스크 작업을 할 때는 확연히 체감될 정도였죠. 웹 서버나 데이터베이스 서버를 돌리는데 응답 속도가 느려지니 답답하더라고요.

    이 문제를 해결하기 위해 NVMe SSD를 DB/WAL 디바이스로 추가하는 튜닝을 진행했습니다. 결과는 드라마틱한 성능 향상이었습니다! 특히 작은 파일 I/O나 랜덤 읽기/쓰기 성능이 눈에 띄게 좋아졌습니다. 💡 또한, 클러스터 내부 통신(Ceph Private Network)을 10GbE 스위치로 분리하고 업그레이드하면서 네트워크 병목 현상도 크게 줄였습니다. Ceph는 데이터를 복제하고 노드 간에 통신해야 하므로, 빠른 네트워크는 필수라는 걸 다시 한번 깨달았죠.

    Ceph 클러스터의 1년 간 성능(IOPS, 처리량, 지연 시간) 및 스토리지 사용량을 보여주는 Grafana 대시보드

    지난 1년간 Ceph 클러스터의 주요 성능 지표(IOPS, 처리량, 지연 시간)와 스토리지 사용량을 보여주는 Grafana 대시보드입니다. NVMe 캐시 추가 이후 I/O 성능이 크게 개선된 것을 볼 수 있습니다.

    제가 배운 교훈과 놓치지 말아야 할 포인트들 (주의사항 및 트러블슈팅)

    1년간의 여정은 순탄치만은 않았습니다. 수많은 삽질과 시행착오를 겪으며 얻은 교훈들을 공유합니다.

    1. 네트워크의 중요성 ⚠️: Ceph는 엄청난 양의 데이터를 노드 간에 주고받습니다. 특히 데이터 복제(Replication)와 리밸런싱(Rebalancing) 시에는 네트워크 대역폭을 거의 다 써버리기도 해요. 저는 1GbE로 시작했다가 병목 현상에 시달렸고, 결국 10GbE Private Network(프라이빗 네트워크)를 구성하면서 안정적인 성능을 확보했습니다. 반드시 Ceph 전용 네트워크를 분리하고, 가능한 한 빠른 대역폭을 확보하는 것이 좋습니다.
    2. OSD 디스크 선택 및 구성: HDD만으로 OSD를 구성하면 성능 한계가 명확합니다. 가능하다면 SSD나 NVMe SSD를 DB/WAL 디바이스로 활용하여 BlueStore의 메타데이터 처리 속도를 높이세요. 저는 OSD 구성 시 디스크 성능과 용량을 신중하게 고려하지 않아서 나중에 재구성하는 삽질을 좀 했습니다.
    3. 모니터링의 생활화: Ceph 클러스터는 생각보다 복잡합니다. `ceph -s` 명령으로 클러스터 상태를 주기적으로 확인하고, Proxmox VE 자체 모니터링 외에 Prometheus와 Grafana를 연동하여 세밀한 모니터링 대시보드를 구축하는 것이 좋습니다. OSD의 상태, 네트워크 트래픽, 스토리지 사용량 등을 실시간으로 확인해야 문제 발생 시 빠르게 대응할 수 있습니다.
    4. CRUSH Map (크러시 맵) 이해: Ceph는 CRUSH Map이라는 알고리즘을 사용해서 데이터를 어디에 저장하고 어떻게 복제할지 결정합니다. 이 CRUSH Map을 이해하면 데이터가 어떻게 분산되는지, 장애 시 복구가 어떻게 이루어지는지 파악하는 데 큰 도움이 됩니다. 홈랩에서는 기본 설정으로도 충분하지만, 좀 더 최적화된 구성을 원한다면 깊이 파고들어 볼 가치가 있습니다.
    5. 업그레이드 및 패치: Proxmox VE와 Ceph는 꾸준히 업데이트됩니다. 새로운 기능과 버그 수정이 포함된 업데이트는 중요하지만, 항상 사전에 충분히 테스트하고 백업 전략을 세운 후 진행해야 합니다. 저는 한 번 업데이트 후에 특정 OSD가 Unhealthy 상태가 되어 클러스터 재시작 후 복구하는 경험도 있었습니다.
    # Ceph 클러스터 상태 확인 (가장 기본적인 명령)
    ceph -s
    
    # OSD 디스크 트리 확인 (어떤 디스크가 OSD로 사용되는지, 상태는 어떤지)
    ceph osd tree
    
    # Ceph 로그 확인
    tail -f /var/log/ceph/ceph.log
    

    이런 명령들을 꾸준히 사용하며 클러스터의 “건강”을 체크하는 것이 중요합니다.

    결론 및 다음 단계

    Proxmox VE와 Ceph를 활용한 분산 스토리지 구축은 제 홈랩에 강력한 고가용성 스토리지를 선물해주었습니다. 물론 초기 설정의 복잡성, 그리고 10GbE 네트워크나 NVMe SSD 같은 추가적인 하드웨어 투자 비용은 무시할 수 없었지만, 그만큼 안정성과 성능이라는 큰 보상을 얻을 수 있었습니다. 특히 OSD 하나가 죽어도 데이터가 안전하고, VM이 자동으로 다른 노드에서 재시작되는 경험은 정말 든든하더라고요. 홈랩에서 중요한 서비스를 운영하거나, 미래의 스케일업(Scale-up)을 염두에 두고 있다면 Proxmox Ceph 조합은 충분히 고려해볼 만한 가치가 있습니다.

    물론 Ceph가 모든 상황에 완벽한 솔루션은 아닙니다. 작은 규모에서는 오히려 오버헤드가 더 클 수도 있고, 특정 워크로드(예: 매우 높은 단일 VM IOPS)에서는 최적화가 필요할 때도 있습니다. 하지만 저렴한 비용으로 엔터프라이즈급 스토리지의 맛을 볼 수 있다는 점은 홈랩 엔지니어에게는 정말 큰 매력이라고 생각합니다.

    다음 단계로는 현재 운영 중인 Ceph 클러스터의 성능을 좀 더 면밀히 분석하고, 특정 VM에 대한 스토리지 I/O 최적화 방안을 모색해보려고 합니다. 또한, CephFS(쎄프 파일 시스템)를 활용하여 파일 공유 시스템을 구축해보는 것도 재미있는 도전이 될 것 같네요. 혹시 여러분도 Proxmox Ceph에 대한 궁금한 점이나 공유하고 싶은 경험이 있다면 언제든지 댓글로 남겨주세요!

    Proxmox VE와 Ceph 분산 스토리지의 장점과 단점을 비교하는 인포그래픽

    Proxmox VE와 Ceph 분산 스토리지 조합의 주요 장점과 고려해야 할 단점을 요약한 인포그래픽입니다. 홈랩 환경에서의 활용 가치를 한눈에 파악할 수 있습니다.

    다음에 더 유익한 정보로 찾아뵙겠습니다. 13년차의 서버실이었습니다!

  • [Proxmox] VMware 마이그레이션, Proxmox로 전환 시 고려사항 및 성공 전략

    [Proxmox] VMware 마이그레이션, Proxmox로 전환 시 고려사항 및 성공 전략

    [Proxmox] VMware 마이그레이션, Proxmox로 전환 시 고려사항 및 성공 전략

    안녕하세요, 13년차의 서버실입니다. 제가 13년 동안 서버실을 지키면서 참 많은 가상화 솔루션을 만나보고 또 직접 구축하고 운영해봤는데요. 그중에서도 VMware ESXi는 오랫동안 업계 표준처럼 여겨져 왔죠. 저도 수많은 프로젝트에서 VMware를 사용해왔습니다. 근데 최근 들어 이런저런 이유로 VMware ESXi를 대체할 솔루션을 고민하시는 분들이 부쩍 늘었더라고요. 특히 홈랩을 운영하는 분들이나 중소기업 환경에서는 비용 부담 때문에 오픈소스 솔루션으로 눈을 돌리는 경우가 많더라고요.

    저도 최근에 홈랩의 일부 워크로드를 VMware ESXi에서 Proxmox VE로 마이그레이션(Migration)하는 삽질을 좀 했습니다. 처음엔 이거 뭐 그냥 옮기면 되는 거 아니야? 싶었는데, 막상 해보니 생각보다 고려해야 할 점들이 많더군요. 특히 기존 VMware 가상머신(Virtual Machine, VM)을 Proxmox 환경으로 가져올 때 포맷 변환부터 드라이버 문제까지, 하나하나 짚어가면서 해결해야 할 숙제들이 있었습니다. 오늘은 제가 직접 겪었던 경험을 바탕으로 VMware 마이그레이션을 Proxmox로 전환할 때 어떤 점들을 고려해야 하고, 어떻게 하면 성공적으로 마이그레이션할 수 있는지 그 전략들을 함께 알아보는 시간을 가지려고 합니다. 저처럼 삽질하실 분들을 위해 핵심만 콕콕 짚어드릴게요!

    VMware ESXi에서 Proxmox VE로의 가상머신 마이그레이션 전체 흐름을 보여주는 다이어그램

    VMware ESXi에서 Proxmox VE로의 가상머신 마이그레이션 전체 흐름을 보여주는 다이어그램입니다. 각 단계별로 어떤 작업이 필요한지 한눈에 파악할 수 있어요.

    Proxmox VE, 과연 VMware의 좋은 대안일까요?

    먼저, Proxmox VE (Virtual Environment)가 뭔지 간단하게 짚고 넘어갈게요. Proxmox VE는 오픈소스 기반의 완전한 가상화 관리 플랫폼이에요. 쉽게 말해, VMware ESXi처럼 서버 한 대에 여러 개의 가상머신을 돌릴 수 있게 해주는 하이퍼바이저(Hypervisor)인 셈이죠. 근데 Proxmox는 단순히 가상머신(KVM)만 지원하는 게 아니라, 컨테이너(LXC)까지 통합해서 관리할 수 있다는 점이 정말 좋더라고요. 게다가 웹 기반의 깔끔한 관리 인터페이스를 제공해서 초보자도 쉽게 접근할 수 있고요. Ceph (분산 스토리지)나 HA (High Availability, 고가용성) 클러스터링 기능까지 기본으로 제공하니, 엔터프라이즈급 기능들을 오픈소스로 무료로 사용할 수 있다는 게 정말 신선했어요.

    제가 Proxmox를 홈랩에 도입해보고 느낀 건, “이거 진짜 물건이네?” 였습니다. 특히 기존 VMware ESXi 환경에서 익숙했던 기능들이 Proxmox에도 대부분 존재하고, 오히려 더 유연하게 설정할 수 있는 부분들도 많더라고요. 물론 상용 솔루션만큼의 완벽한 기능이나 기술 지원을 기대하긴 어렵지만, 커뮤니티가 활성화되어 있어서 웬만한 문제는 검색만으로도 해결할 수 있었습니다.

    VMware에서 Proxmox로 가상머신 마이그레이션 실전 전략

    자, 그럼 이제 본격적으로 VMware ESXi에 있던 가상머신을 Proxmox VE로 옮기는 방법을 알아볼까요? 제가 직접 해보니 몇 가지 핵심 단계가 있더라고요.

    1. VMware VM 내보내기 (Exporting VMware Virtual Machines)

    가장 먼저 할 일은 VMware ESXi에 있는 가상머신을 내보내는 겁니다. 보통 OVF (Open Virtualization Format)나 OVA (Open Virtual Appliance) 파일 형식으로 내보내게 되죠. vSphere Client나 OVF Tool을 사용해서 쉽게 내보낼 수 있어요. 저는 주로 vSphere Client를 사용했는데요, 간단히 VM을 우클릭해서 ‘템플릿’ → ‘OVF 템플릿 내보내기’를 선택하면 됩니다. 이때 모든 디스크를 하나로 묶을지, 아니면 개별로 분리할지 선택할 수 있어요. 나중에 Proxmox에서 작업하기 훨씬 편하니까, 개별 파일로 내보내는 걸 추천해요.

    # OVF Tool을 사용하여 VM 내보내기 (예시)
    # OVF Tool은 VMware에서 제공하는 CLI 도구입니다.
    # 'vi://:@/' 형식으로 원본 VM을 지정합니다.
    # --targetDiskFormat: thin, thick, monolithicSparse, monolithicFlat 등
    # --noImageFiles: 디스크 이미지를 제외하고 OVF 파일만 내보낼 때 사용
    
    # 예시: vSphere ESXi 호스트에서 'MyVM'이라는 가상머신을 로컬 디렉토리로 내보내기
    # ovftool "vi://root:[email protected]/MyVM" "/path/to/save/MyVM.ovf"
    
    # 주의: OVF Tool은 설치와 사용법이 다소 복잡할 수 있어, vSphere Client GUI가 더 편리할 수 있습니다.
    

    2. 가상 디스크 포맷 변환 (Converting Virtual Disk Format)

    VMware에서 내보낸 가상 디스크 파일은 주로 VMDK (.vmdk) 포맷입니다. 그런데 Proxmox VE는 KVM 기반이라 QCOW2 (.qcow2) 포맷이 더 일반적이고 성능도 좋거든요. 그래서 이 VMDK 파일을 QCOW2로 변환해줘야 하는데요. 이때 사용하는 강력한 도구가 바로 qemu-img입니다. Proxmox 서버나 별도의 Linux 서버에서 이 작업을 할 수 있어요.

    제가 가장 많이 삽질했던 부분 중 하나가 바로 이 포맷 변환이었습니다. 변환 옵션을 잘못 주거나, 원본 파일이 손상되어 있으면 부팅이 안 되는 불상사가 발생하더라고요. 원본 VMDK 파일은 꼭 백업해두고 작업하세요!

    # Proxmox 서버나 Linux 터미널에서 실행
    # VMDK 파일을 QCOW2 포맷으로 변환
    # -f: 원본 파일 형식 (from format)
    # -O: 대상 파일 형식 (to format)
    
    qemu-img convert -f vmdk -O qcow2 /path/to/your/vmware_vm.vmdk /path/to/your/proxmox_vm.qcow2
    
    # 만약 변환 중 문제가 발생한다면, 원본 VMDK 파일의 무결성을 확인하거나
    # 다른 변환 옵션 (예: -o cluster_size=2M)을 시도해볼 수 있어요.
    # 스냅샷이 포함된 VMDK 파일은 더 복잡할 수 있습니다.
    
    VMDK 파일을 QCOW2 포맷으로 변환하는 qemu-img convert 명령어 실행 화면

    qemu-img convert 명령어를 통해 VMDK 파일을 QCOW2 포맷으로 변환하는 과정을 터미널에서 보여주는 화면입니다. 이 과정은 마이그레이션의 핵심 단계 중 하나입니다.

    3. Proxmox VE로 가져오기 및 VM 생성 (Importing to Proxmox VE and Creating VM)

    변환된 QCOW2 파일을 Proxmox VE 서버의 적절한 스토리지 경로로 옮긴 다음, 새로운 가상머신을 생성하고 이 디스크를 연결해줘야 합니다.

    1. QCOW2 파일 업로드/이동: Proxmox 서버의 `/var/lib/vz/images/` 경로 아래에 새 VM ID 폴더를 만들고 그 안에 QCOW2 파일을 복사해요. 또는 Proxmox 웹 UI의 ‘스토리지’에서 ‘콘텐츠’ 업로드 기능을 사용할 수도 있어요.
    2. 새 가상머신 생성: Proxmox 웹 UI에서 ‘VM 생성’ 버튼을 누르고, 운영체제는 ‘미디어 사용 안 함’을 선택해요. CPU, 메모리, 네트워크 등은 기존 VMware VM과 비슷하게 설정하면 됩니다.
    3. 기본 디스크 분리: 새로 생성된 VM에는 기본적으로 작은 디스크가 하나 붙어있을 겁니다. 이 디스크는 ‘하드웨어’ 탭에서 선택 후 ‘분리’하면 됩니다.
    4. 변환된 디스크 연결: ‘하드웨어’ 탭에서 ‘추가’ → ‘하드 디스크’를 선택해요. ‘저장소’는 QCOW2 파일이 있는 스토리지를 선택하고, ‘디스크 이미지’는 앞서 복사해둔 QCOW2 파일을 선택합니다. 버스/장치는 SCSI 또는 VirtIO Block을 선택하는 게 성능상 유리해요. 컨트롤러는 VirtIO SCSI Single을 추천합니다.
    5. 부팅 순서 설정: ‘옵션’ 탭에서 ‘부팅 순서’를 변경하여 새로 연결한 디스크로 부팅하도록 설정합니다.

    4. 게스트 에이전트 설치 및 네트워크 설정 (Installing Guest Agent and Network Configuration)

    여기서 또 한 번의 삽질이 기다리고 있을 수 있어요. VM이 성공적으로 부팅되었다고 끝이 아니거든요! 성능 최적화와 안정적인 관리를 위해 몇 가지 추가 작업이 필요합니다.

    • QEMU Guest Agent 설치: VMware Tools처럼, Proxmox 환경에서는 QEMU Guest Agent를 설치해야 해요. 이걸 설치해야 Proxmox 웹 UI에서 VM의 IP 주소나 게스트 OS 상태를 정확하게 확인할 수 있고, 깔끔한 종료(shutdown)나 재부팅(reboot) 명령도 정상적으로 동작합니다.
    # Debian/Ubuntu 기반 게스트 OS에서 QEMU Guest Agent 설치
    sudo apt update
    sudo apt install qemu-guest-agent
    sudo systemctl start qemu-guest-agent
    sudo systemctl enable qemu-guest-agent
    
    # CentOS/RHEL 기반 게스트 OS에서 QEMU Guest Agent 설치
    sudo yum install qemu-guest-agent
    sudo systemctl start qemu-guest-agent
    sudo systemctl enable qemu-guest-agent
    
    • 네트워크 드라이버 설정: VMware에서 사용하던 E1000이나 VMXNET3 드라이버가 Proxmox 환경에서는 제대로 작동하지 않을 수 있습니다. Proxmox에서는 VirtIO (Virtio network device) 드라이버를 사용하는 게 성능상 훨씬 유리해요. VM 설정에서 네트워크 장치를 VirtIO로 변경하고, 게스트 OS 내부에서 네트워크 설정을 다시 해줘야 할 수 있습니다.

    ⚠️ 마이그레이션 중 겪었던 주의사항 및 트러블슈팅

    저도 마이그레이션을 하면서 몇 번의 좌절을 겪었습니다. 특히 이런 문제들이 자주 발생하더라고요.

    • 부팅 문제 (Boot Issues): VMDK를 QCOW2로 변환 후 부팅이 안 되는 경우가 있어요. 대부분 디스크 컨트롤러 타입 문제인데요. Proxmox VM 생성 시 디스크 컨트롤러를 VirtIO SCSI로 설정하고, 게스트 OS에 VirtIO 드라이버가 없으면 부팅이 안 될 수 있습니다. Windows OS의 경우 VirtIO 드라이버 ISO를 연결하여 드라이버를 수동으로 설치해야 할 수도 있어요.
    • 네트워크 연결 불가: 위에서 언급했듯이, 네트워크 장치를 VirtIO로 변경하면 기존 드라이버가 없어서 네트워크가 안 잡힐 수 있습니다. 게스트 OS에 접속해서 네트워크 인터페이스 설정 파일(예: Linux의 /etc/network/interfaces나 /etc/sysconfig/network-scripts/)을 수정하거나, Windows의 경우 장치 관리자에서 드라이버를 업데이트해야 합니다.
    • 스냅샷 문제: VMware VM에 스냅샷이 많다면 마이그레이션이 복잡해질 수 있어요. 가급적 스냅샷을 모두 제거하고 베이스 디스크만 내보내는 것을 권장합니다.
    • 성능 저하: 마이그레이션 후 VM 성능이 기대 이하라면, 디스크와 네트워크 장치를 모두 VirtIO로 설정했는지, QEMU Guest Agent가 설치되어 잘 작동하는지 꼭 확인해봐요. CPU 타입도 ‘host’로 설정하는 게 최적의 성능을 낼 수 있습니다.

    🎉 마이그레이션 결과 확인 및 검증

    모든 과정을 거쳐 VM이 정상적으로 부팅되고 작동한다면, 이제 마이그레이션이 성공적으로 완료된 거예요. Proxmox 웹 UI에서 VM의 상태를 확인하고, 게스트 OS 내부에서 네트워크 연결, 서비스 동작 여부 등을 꼼꼼히 검증해야 합니다.

    • Proxmox 웹 UI 확인: VM의 CPU, 메모리 사용량, 네트워크 트래픽 등이 정상적으로 표시되는지 확인해요. QEMU Guest Agent가 활성화되어 있다면, IP 주소도 보일 겁니다.
    • 게스트 OS 내부 확인: SSH나 콘솔로 접속하여 주요 서비스(웹 서버, DB 등)가 제대로 시작되었는지, 파일 시스템은 정상인지, 네트워크 연결은 원활한지 테스트해요. ping, ifconfig (또는 ip a), df -h 등의 명령어를 활용하면 좋겠죠.

    Proxmox VE 웹 인터페이스에서 성공적으로 마이그레이션된 가상머신의 개요 대시보드 화면입니다. VM의 상태, 리소스 사용량, 네트워크 정보 등을 한눈에 확인할 수 있습니다.

    마무리하며: Proxmox, 새로운 시작을 위한 현명한 선택

    솔직히 처음엔 VMware ESXi에 너무 익숙해서 Proxmox VE로 넘어가는 게 번거롭지 않을까 걱정했었습니다. 하지만 직접 마이그레이션을 해보고 몇 주간 운영해보니, Proxmox VE는 충분히 강력하고 유연한 대안이라는 걸 깨달았어요. 물론 중간중간 삽질도 좀 했지만, 그 과정에서 얻은 경험은 정말 값지다고 생각합니다.

    특히 비용 문제로 고민이 많으셨던 분들이나, 홈랩에서 다양한 기술을 자유롭게 실험해보고 싶으신 분들에게 Proxmox VE는 아주 좋은 선택이 될 거예요. 이번 글이 VMware 마이그레이션을 Proxmox로 전환하려는 분들에게 조금이나마 도움이 되었으면 좋겠네요. 다음번에는 Proxmox VE 클러스터링이나 Ceph 스토리지 구성에 대한 저의 삽질 경험을 공유해드릴게요!

    VMware ESXi와 Proxmox VE의 핵심 기능을 비교하는 인포그래픽 표

    VMware ESXi와 Proxmox VE의 주요 특징들을 비교하여 보여주는 인포그래픽 표입니다. 각 솔루션의 장단점을 파악하는 데 도움이 될 것입니다.

  • [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] Ansible로 Proxmox 자동화, 실패 없는 10가지 베스트 프랙티스

    [Proxmox] Ansible로 Proxmox 자동화, 실패 없는 10가지 베스트 프랙티스

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 운영자입니다. 오늘은 제가 홈랩과 실무 환경에서 늘 고민하고 적용해왔던 주제, 바로 Ansible로 Proxmox 자동화에 대해 이야기해보려고 합니다. 많은 분들이 Proxmox VE(Virtual Environment)를 사용하시면서 가상 머신(VM)이나 컨테이너(LXC)를 수동으로 생성하고 설정하는 데 시간을 많이 쏟으셨을 거예요. 저도 처음엔 그랬습니다. 매번 클릭하고 타이핑하고… 그러다 어느 순간 ‘이거 자동화할 수 없을까?’ 하는 생각이 머리를 스치더군요. 그래서 Ansible을 들고 Proxmox에 뛰어들었고, 수많은 삽질 끝에 얻은 귀한 경험들을 여러분과 나누고자 합니다.

    오늘 제가 준비한 내용은 ‘실패 없는 Proxmox 자동화를 위한 10가지 베스트 프랙티스’입니다. 단순한 기능 소개를 넘어, 제가 직접 부딪히고 해결했던 문제들과 그 과정에서 배운 노하우를 멘토처럼 알려드릴게요. 이 글을 읽고 나면 여러분의 홈랩 자동화는 물론, 실제 인프라 관리 효율도 한층 더 높아질 거라고 확신합니다. 자, 그럼 시작해볼까요? 🎉

    Ansible과 Proxmox 연동 아키텍처 다이어그램

    Ansible 컨트롤러가 Proxmox 호스트들을 관리하며 VM, LXC, 스토리지, 네트워크 등을 자동화하는 아키텍처 다이어그램입니다.

    Proxmox와 Ansible, 왜 함께해야 할까요? (개념 설명)

    Proxmox VE(프로모스 VE)는 강력한 오픈소스 가상화 플랫폼입니다. KVM(Kernel-based Virtual Machine) 기반의 가상 머신과 LXC(Linux Container) 컨테이너를 지원하며, 웹 기반 GUI로 손쉽게 관리할 수 있죠. 하지만 아무리 GUI가 편해도 수십, 수백 대의 VM을 일일이 설정하는 건 비효율적이거든요. 여기서 Ansible(앤서블)이 등장합니다. Ansible은 IT 자동화를 위한 오픈소스 도구로, SSH 기반의 Agentless(에이전트리스) 방식이라 별도의 에이전트 설치 없이도 원격 서버를 제어할 수 있더라고요. YAML(야믈) 기반의 플레이북(Playbook)으로 인프라의 ‘상태’를 정의하면, Ansible이 그 상태를 맞춰주죠.

    쉽게 말해, Proxmox가 튼튼한 서버실이라면 Ansible은 이 서버실을 알아서 척척 관리해주는 유능한 비서인 셈입니다. VM 생성, 네트워크 설정, 스토리지 연결 등 반복적이고 오류 발생 가능성이 높은 작업들을 Ansible로 자동화하면, 시간을 절약하고 휴먼 에러(human error)를 크게 줄일 수 있거든요. 특히 저처럼 홈랩 자동화에 관심이 많은 분들에게는 정말 최고의 조합이라고 할 수 있습니다.

    실패 없는 Proxmox 자동화를 위한 10가지 베스트 프랙티스 (실전 구현)

    제가 13년 동안 쌓아온 경험과 숱한 삽질 끝에 얻은 Proxmox 자동화 팁들을 공유합니다. 이 원칙들을 지키면 여러분의 Ansible Proxmox 자동화 여정이 훨씬 수월할 거예요.

    1. 동적 인벤토리(Dynamic Inventory) 활용하기

    가장 먼저 강조하고 싶은 건 바로 동적 인벤토리입니다. VM이 수시로 생성되고 삭제되는 환경에서는 정적 인벤토리(Static Inventory) 파일을 매번 수정하기가 어렵거든요. Proxmox의 API를 활용해서 현재 떠 있는 VM 목록을 동적으로 가져오는 스크립트를 사용하면 정말 편합니다. community.general 컬렉션에 Proxmox 동적 인벤토리 플러그인이 있으니 활용해보세요. 저는 주로 Python 스크립트를 직접 짜서 사용했는데, 이게 훨씬 유연하더라고요.

    # ansible.cfg 예시
    [inventory]
    enable_plugins = proxmox
    
    # inventory/proxmox.yml
    plugin: community.proxmox.proxmox
    base_url: https://your-proxmox-host:8006/api2/json
    api_user: root@pam
    api_password: your_password_or_token
    validate_certs: False # 실제 환경에서는 True 권장
    

    이렇게 설정하면 ansible-inventory -i inventory/proxmox.yml --list 명령으로 현재 Proxmox에 있는 VM들을 Ansible 인벤토리로 불러올 수 있습니다. 💡 팁: 보안을 위해 API 토큰을 사용하는 것을 강력히 추천합니다.

    2. 항상 멱등성(Idempotency)을 지키세요

    Ansible의 핵심 철학은 멱등성입니다. 즉, 플레이북을 여러 번 실행해도 항상 동일한 결과를 내고, 이미 목표 상태에 도달했다면 아무 작업도 하지 않아야 한다는 뜻이거든요. Proxmox VM 생성/수정 시 이 멱등성을 지키는 것이 매우 중요합니다. 예를 들어, VM이 이미 존재하면 생성하지 않거나, 설정이 동일하면 변경하지 않도록 플레이북을 작성해야 하더라고요. Proxmox 모듈들은 대부분 멱등성을 지원하지만, 스크립트나 커맨드를 직접 사용할 때는 주의가 필요합니다. 저도 초기에 이 부분을 간과해서 이미 생성된 VM에 또 생성 명령이 들어가 오류가 나던 경험이 많았거든요.

    3. 변수 관리, 이렇게 해야 깔끔합니다

    플레이북 내에 하드코딩된 값은 피하고, 변수(Variables)를 적극적으로 활용하세요. 특히 group_vars와 host_vars 디렉토리를 사용하면 VM의 종류나 호스트별로 유연하게 설정을 관리할 수 있더라고요. 민감한 정보(API 키, 비밀번호 등)는 Ansible Vault(앤서블 볼트)를 사용해서 암호화하세요. 보안은 아무리 강조해도 지나치지 않습니다. 저도 한때 vars 파일에 비밀번호를 그냥 넣었다가 식겁한 적이 있습니다. 😅

    # group_vars/all.yml
    pve_api_user: 'root@pam'
    pve_api_token_id: 'ansible-token'
    pve_api_token_secret: '{{ vault_pve_api_token_secret }}' # vault로 관리
    
    # host_vars/my-vm.yml
    vm_id: 101
    vm_name: 'web-server-01'
    vm_memory: 2048
    vm_cores: 2
    vm_net_bridge: 'vmbr0'
    vm_ip: '192.168.1.101'
    

    4. Proxmox 전용 모듈, 똑똑하게 쓰기

    Ansible은 community.proxmox 컬렉션을 통해 Proxmox를 위한 다양한 모듈을 제공합니다. proxmox_kvm, proxmox_lxc, proxmox_storage 등 목적에 맞는 모듈을 사용하세요. 이 모듈들은 Proxmox API를 활용하여 안정적이고 멱등성 있는 작업을 수행할 수 있도록 설계되었더라고요. 셸 스크립트(shell script)로 API를 직접 호출하는 것보다 훨씬 안전하고 관리하기 편합니다. 예전에는 uri 모듈로 직접 HTTP 요청을 날리기도 했는데, 전용 모듈이 훨씬 편리하더라고요.

    - name: Create a new KVM virtual machine
      community.proxmox.proxmox_kvm:
        api_host: "{{ pve_api_host }}"
        api_user: "{{ pve_api_user }}"
        api_token_id: "{{ pve_api_token_id }}"
        api_token_secret: "{{ pve_api_token_secret }}"
        vmid: "{{ vm_id }}"
        name: "{{ vm_name }}"
        memory: "{{ vm_memory }}"
        cores: "{{ vm_cores }}"
        net:
          net0: 'model=virtio,bridge={{ vm_net_bridge }}'
        state: present
      delegate_to: localhost
    

    5. 오류 핸들링(Error Handling), 미리미리 대비하기

    자동화 작업은 예상치 못한 문제로 실패할 수 있습니다. 네트워크 문제, Proxmox API 응답 지연, 잘못된 변수 값 등 다양한 원인이 있죠. failed_when, ignore_errors, block/rescue를 활용하여 견고한 플레이북을 만드세요. 특히 중요한 작업은 block으로 묶고, 실패 시 rescue 블록에서 정리 작업을 하도록 구성하면 정말 안전하더라고요. 저도 처음에 에러가 나면 그냥 멈추게 만들었는데, 나중에는 중단된 상태를 수동으로 정리하는 게 더 힘들더라고요. ⚠️

    - name: Critical VM creation block
      block:
        - name: Create VM
          community.proxmox.proxmox_kvm:
            # ... VM 생성 설정 ...
            state: present
          delegate_to: localhost
        - name: Configure VM network
          ansible.builtin.shell: 'some_network_config_command {{ vm_ip }}'
      rescue:
        - name: Clean up VM if creation failed
          community.proxmox.proxmox_kvm:
            api_host: "{{ pve_api_host }}"
            api_user: "{{ pve_api_user }}"
            api_token_id: "{{ pve_api_token_id }}"
            api_token_secret: "{{ pve_api_token_secret }}"
            vmid: "{{ vm_id }}"
            state: absent
          delegate_to: localhost
    

    6. 태그(Tags)로 원하는 작업만 골라 실행하기

    플레이북이 점점 커지면 특정 작업만 실행하거나 건너뛰고 싶을 때가 많습니다. 이때 태그(Tags)를 사용하면 정말 유용하더라고요. 각 태스크(task)에 의미 있는 태그를 부여하고, --tags 또는 --skip-tags 옵션으로 플레이북 실행을 제어할 수 있습니다. 예를 들어, ‘network’ 태그를 부여한 태스크만 실행하거나, ‘cleanup’ 태그가 붙은 태스크는 건너뛰는 식이죠. 저도 처음엔 플레이북 전체를 매번 돌렸는데, 태그를 사용하니 개발 및 테스트 시간이 엄청 단축되더라고요. ✅

    # 'create_vm' 태그가 붙은 작업만 실행
    ansible-playbook -i inventory/proxmox.yml playbook.yml --tags create_vm
    
    # 'cleanup' 태그가 붙은 작업만 건너뛰고 실행
    ansible-playbook -i inventory/proxmox.yml playbook.yml --skip-tags cleanup
    

    7. 역할(Roles) 기반으로 플레이북 구조화하기

    복잡한 Proxmox 스크립트와 플레이북은 역할(Roles) 기반으로 구조화하는 것이 좋습니다. 역할은 변수, 태스크, 핸들러(handler), 파일, 템플릿(template) 등을 논리적으로 묶어 재사용성을 높여주거든요. 예를 들어, ‘proxmox-vm-create’ 역할, ‘proxmox-net-config’ 역할 등으로 나누어 관리하면 가독성이 높아지고 유지보수가 훨씬 쉬워집니다. 저의 홈랩에서도 VM 생성, 네트워크 설정, 특정 애플리케이션 설치 등을 각각의 역할로 만들어서 사용하고 있습니다.

    # roles/proxmox-vm-create/tasks/main.yml
    - name: Create VM
      community.proxmox.proxmox_kvm:
        # ... VM 생성 설정 ...
    
    # playbook.yml
    - name: Deploy web server VM on Proxmox
      hosts: localhost
      connection: local
      roles:
        - role: proxmox-vm-create
          vars:
            vm_name: 'web-server-02'
            vm_id: 102
            # ... 기타 변수 ...
        - role: proxmox-net-config
          vars:
            vm_ip: '192.168.1.102'
    

    8. 플레이북 실행 전 반드시 테스트하기 (–check –diff)

    실제 변경 사항을 적용하기 전에 --check (dry run, 드라이 런) 모드로 플레이북을 실행하여 어떤 변경이 일어날지 미리 확인하세요. --diff 옵션을 함께 사용하면 변경될 내용을 자세히 볼 수 있더라고요. 이 두 옵션은 실제 환경에 적용하기 전에 발생할 수 있는 잠재적인 문제를 미리 발견하는 데 정말 중요한 역할을 합니다. 저의 수많은 ‘대형 사고’를 막아준 고마운 기능입니다. 😅

    # 실제로 변경하지 않고, 어떤 변경이 일어날지 미리 확인
    ansible-playbook -i inventory/proxmox.yml playbook.yml --check --diff
    

    9. 버전 관리 시스템(Git)은 필수입니다

    모든 플레이북, 인벤토리, 역할 파일은 Git과 같은 버전 관리 시스템에 저장해야 합니다. 변경 이력을 추적하고, 여러 사람이 협업하며, 필요할 경우 이전 버전으로 되돌릴 수 있게 해주거든요. Ansible Proxmox 자동화 스크립트는 인프라의 ‘코드’와 같으므로, 코드 관리의 모범 사례를 따르는 것이 중요합니다. 저도 처음엔 그냥 로컬 폴더에 저장해두고 관리했는데, 실수로 파일을 날리거나 변경 이력을 잃어버려서 다시 처음부터 작성했던 뼈아픈 경험이 있습니다.

    10. AWX/Tower(자동화 컨트롤러)로 더 강력하게

    Ansible 자동화가 복잡해지고 규모가 커지면, AWX(앤서블 워크스)나 Ansible Tower(앤서블 타워)와 같은 자동화 컨트롤러의 도입을 고려해보세요. 웹 기반 UI를 통해 플레이북 실행, 인벤토리 관리, 사용자 권한 제어, 스케줄링, 로깅 등 모든 자동화 작업을 중앙에서 관리할 수 있거든요. AWX Proxmox 연동은 특히 강력합니다. 저는 홈랩에서 AWX를 구축해서 복잡한 VM 배포 파이프라인을 만들었는데, 이젠 버튼 하나로 모든 게 되니 정말 편하더라고요. 이젠 홈랩 자동화의 끝판왕이라고 부르고 싶을 정도입니다.

    AWX 대시보드에서 성공적으로 실행된 Proxmox 자동화 작업 목록

    AWX 대시보드에서 Proxmox 관련 자동화 작업이 성공적으로 실행된 모습을 보여주는 스크린샷입니다.

    ⚠️ 삽질 경험담: 제가 겪었던 문제들 (주의사항/트러블슈팅)

    제가 Ansible Proxmox 자동화를 하면서 가장 많이 겪었던 문제들을 몇 가지 공유해 드릴게요. 여러분은 저처럼 삽질하지 마시라고요! ㅎㅎ

    권한 문제 (Permission Denied)

    Proxmox API를 사용할 때 가장 많이 만나는 에러 중 하나가 바로 권한 문제입니다. root@pam 계정을 직접 사용하는 것은 보안상 좋지 않고, 특정 권한만 가진 API 토큰을 생성해서 사용하는 것이 모범 사례거든요. Proxmox의 ‘Datacenter -> Permissions -> API Tokens’에서 필요한 권한(예: VM.Audit, VM.PowerMgmt, VM.Allocate)만 부여된 토큰을 만들고, 이 토큰 ID와 시크릿(secret)을 Ansible Vault로 안전하게 관리해야 합니다. 처음엔 root 권한으로 대충 했는데, 나중에 보안 감사 때 혼쭐이 날 뻔했습니다. 😱

    네트워크 설정 복잡성

    Proxmox의 네트워크 설정은 처음엔 좀 복잡하게 느껴질 수 있습니다. 특히 브리지(bridge) 설정이나 VLAN(Virtual Local Area Network) 태깅 같은 부분이요. Ansible로 VM을 생성하고 네트워크를 붙일 때, Proxmox 호스트의 네트워크 설정(/etc/network/interfaces)과 정확히 일치하는지 확인해야 합니다. 잘못된 브리지 이름을 사용하거나, VLAN ID를 놓치면 VM이 네트워크에 연결되지 않아 한참을 헤맸던 적이 많습니다. 네트워크 자동화는 항상 신중하게 테스트하는 게 정말 중요해요.

    이 외에도 Proxmox API 응답 지연, 모듈 인자(argument) 오류, 템플릿(Template) 이미지 경로 문제 등 다양한 변수들이 있었습니다. 중요한 건 에러 메시지를 꼼꼼히 읽고, Proxmox 공식 문서와 Ansible 모듈 문서를 참고하며 차분하게 해결해나가는 인내심입니다. 저도 처음엔 ‘이게 왜 안 돼!’ 하면서 키보드를 던질 뻔한 적이 한두 번이 아니었거든요. 하지만 포기하지 않고 해결했을 때의 쾌감은 정말 짜릿합니다! ✨

    Ansible로 자동화된 Proxmox 가상 머신 및 컨테이너 목록

    Ansible로 자동 생성 및 설정된 Proxmox 가상 머신(VM) 및 컨테이너(LXC) 목록을 보여주는 Proxmox 웹 인터페이스 화면입니다.

    마치며: 자동화, 결국 시간을 벌어주는 일 (마무리)

    오늘은 13년차 인프라 엔지니어의 시선으로 Ansible Proxmox 자동화의 베스트 프랙티스 10가지를 자세히 소개해 드렸습니다. 동적 인벤토리, 멱등성, 변수 관리, Proxmox 모듈 활용, 오류 핸들링, 태그, 역할, 테스트, 버전 관리, 그리고 AWX/Tower까지, 이 모든 것이 여러분의 홈랩 자동화와 실무 인프라 관리에 큰 도움이 될 거라고 생각합니다.

    처음에는 복잡해 보일 수 있지만, 한 번 구축해두면 반복적인 작업에서 정말 완전히 해방될 수 있습니다. Proxmox 스크립트를 일일이 작성하고 실행하는 시간 대신, 더 중요하고 창의적인 일에 집중할 수 있게 되는 거죠. 자동화는 결국 우리에게 ‘시간’이라는 가장 소중한 자원을 벌어다 줍니다. 여러분도 오늘 배운 내용을 바탕으로 자신만의 Ansible Proxmox 자동화 시스템을 구축해보시고, 그 편리함을 직접 경험해보시길 바랍니다. 다음 글에서는 AWX를 활용한 Proxmox VM 배포 파이프라인 구축에 대해 더 자세히 다뤄볼 예정이니 기대해주세요! 😉

    Ansible과 Proxmox 연동의 이점을 요약한 인포그래픽

    Ansible과 Proxmox 로고를 중심으로 자동화, 효율성, 확장성, 홈랩, 인프라 관리 등 주요 이점을 시각적으로 요약한 인포그래픽입니다.

  • [Proxmox] Proxmox VE 보안 강화 체크리스트 10가지: 안전한 가상화 환경 구축

    [Proxmox] Proxmox VE 보안 강화 체크리스트 10가지: 안전한 가상화 환경 구축

    안녕하세요! 13년차 인프라 엔지니어, 13년차의 서버실 운영자입니다. 오늘은 제가 홈랩(Homelab)에서 Proxmox VE를 운영하면서 겪었던 일들과 함께, 여러분의 소중한 가상화 환경을 더욱 안전하게 보호할 수 있는 Proxmox 보안 강화 체크리스트 10가지를 공유해볼까 합니다. 사실 처음엔 저도 ‘내 개인 서버인데 뭐 그렇게까지 해야 하나?’ 싶었거든요. 근데 한번 호되게 당하고 나서는 생각이 싹 바뀌었습니다. 인터넷에 연결된 모든 시스템은 잠재적인 공격 대상이 될 수 있다는 걸 뼈저리게 느꼈죠. 이 글을 통해 여러분은 저처럼 삽질하지 마시고, 처음부터 튼튼한 Proxmox VE 환경을 구축하시길 바랍니다. 이 체크리스트만 따라 해도 웬만한 위협에서는 훨씬 안전해질 거예요! 자, 그럼 시작해볼까요? 🎉

    Proxmox VE의 구성 요소와 각 영역에 적용될 보안 조치들을 시각적으로 보여주는 다이어그램입니다.

    1. 강력한 관리자 비밀번호와 SSH 키 인증 ✅

    보안의 가장 기본은 뭐니 뭐니 해도 비밀번호거든요. Proxmox VE 설치 시 설정하는 root 계정 비밀번호는 물론, 추가로 생성하는 모든 사용자 계정 비밀번호는 길고 복잡하게 만들어야 합니다. 숫자, 특수문자, 대소문자를 섞어서 최소 12자리 이상이죠. 저는 보통 16자리 이상으로 만듭니다.

    그리고 SSH(Secure Shell) 접속 시에는 비밀번호 인증 대신 SSH 키 인증(SSH Key Authentication)을 사용하는 게 훨씬 안전해요. 비밀번호는 무작위 대입 공격(Brute-force attack)에 취약하거든요. 제가 직접 해보니 키 인증 한 번 설정해두면 훨씬 편하고 안전하더라고요. 처음엔 좀 번거롭지만, 한 번 해두면 두고두고 안심입니다.

    # 1. SSH 키 생성 (클라이언트 PC에서 실행)
    ssh-keygen -t rsa -b 4096 -C "[email protected]"
    
    # 2. Proxmox VE 서버로 공개 키 복사
    ssh-copy-id -i ~/.ssh/id_rsa.pub root@your_proxmox_ip
    
    # 3. 비밀번호 없이 SSH 접속 확인
    ssh root@your_proxmox_ip

    이렇게 하면 다음부터는 비밀번호 입력 없이 SSH에 접속할 수 있습니다. 💡 팁: ssh-agent를 활용하면 키 비밀번호(passphrase)도 한 번만 입력해도 되더라고요.

    2. Proxmox VE 웹 UI 2단계 인증 (2FA) 🛡️

    Proxmox VE의 웹 관리 UI는 모든 설정의 핵심이거든요. 이곳이 뚫리면 모든 게 끝장입니다. 그래서 2단계 인증(Two-Factor Authentication, 2FA)은 선택이 아닌 필수죠. 구글 OTP(Google Authenticator) 같은 TOTP(Time-based One-Time Password) 앱을 연동해서 로그인할 때마다 일회용 코드를 입력하게 하는 거예요.

    제가 직접 설정해보니 생각보다 간단하더라고요. Proxmox VE 웹 UI에 로그인해서 [Datacenter] > [Permissions] > [Users]로 가서 여러분의 사용자 계정을 선택한 다음, [TFA] 탭에서 [Add] > [TOTP Factor]를 선택하면 됩니다. 그러면 QR 코드가 나오는데, 이걸 OTP 앱으로 스캔하면 끝! 로그인할 때 아이디/비밀번호 입력 후 OTP 코드를 한 번 더 입력하게 됩니다.

    Proxmox VE 웹 UI 2단계 인증 (TOTP) 설정 화면

    Proxmox VE 웹 인터페이스에서 TOTP(Time-based One-Time Password) 2단계 인증을 활성화하는 과정을 보여주는 스크린샷입니다.

    3. SSH 기본 설정 강화 🔒

    앞서 SSH 키 인증을 설정했다면, 이제 sshd 설정을 강화할 차례예요. 기본 설정을 그대로 두면 보안에 취약할 수 있거든요. 특히 root 계정으로 바로 로그인하는 것을 막고, 비밀번호 인증도 비활성화하는 것이 좋습니다. 저는 이 설정을 안 했다가 한동안 SSH 무작위 대입 공격 시도 로그를 보면서 식겁했던 경험이 있습니다. ㅎㅎ

    # Proxmox VE 서버에서 실행
    
    # 1. SSH 설정 파일 백업 (중요!)
    cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
    
    # 2. 설정 파일 수정
    nano /etc/ssh/sshd_config
    
    # 다음 라인들을 찾아서 수정하거나 추가합니다.
    # PermitRootLogin no             # root 계정 직접 로그인 금지
    # PasswordAuthentication no      # 비밀번호 인증 비활성화 (키 인증 필수)
    # Port 2222                      # SSH 기본 포트 22번 대신 다른 포트 사용 (예: 2222)
    
    # 3. SSH 서비스 재시작
    systemctl restart sshd

    ⚠️ 주의사항: PermitRootLogin no와 PasswordAuthentication no를 설정하기 전에, 반드시 일반 사용자 계정을 만들고 SSH 키 인증으로 로그인 가능한지 확인해야 합니다. 안 그러면 서버에 접속하지 못하는 불상사가 발생할 수 있거든요! 저도 한 번 실수로 root 계정으로만 접속 가능한 상태에서 이 설정을 했다가 콘솔에 매달려야 했던 적이 있습니다… 😅

    4. Proxmox VE 내장 방화벽 활용 🔥

    Proxmox VE는 자체적으로 방화벽(Firewall) 기능을 제공하는데, 정말 강력해요. 호스트 레벨과 VM(Virtual Machine)/컨테이너(Container) 레벨 모두에서 네트워크 보안(Network Security)을 구현할 수 있거든요. Ingress(인그레스, 외부에서 내부로 들어오는 트래픽)와 Egress(이그레스, 내부에서 외부로 나가는 트래픽) 규칙을 세밀하게 제어할 수 있습니다.

    제가 홈랩에서 가장 먼저 하는 일 중 하나가 바로 이 방화벽 설정입니다. 불필요한 포트는 모두 막아두고, 필요한 포트(예: Proxmox 웹 UI 8006, SSH 변경 포트)만 열어두는 거죠. VM마다 다른 보안 정책을 적용할 수 있어서 정말 유용하더라고요.

    # Proxmox VE 호스트 레벨 방화벽 활성화
    pve-firewall start
    pve-firewall enable
    
    # 방화벽 규칙 설정은 Web UI를 권장합니다:
    # [Datacenter] > [Firewall] 또는 [Node] > [Firewall]
    # [VM/Container] > [Firewall]

    이건 Proxmox VE의 꽃 같은 기능이라고 생각합니다. 네트워크 세그멘테이션과 함께 사용하면 시너지가 정말 엄청나거든요!

    5. 네트워크 세그멘테이션 🌐

    네트워크 세그멘테이션(Network Segmentation)은 물리적 또는 가상적으로 네트워크를 여러 개의 작은 구역으로 나누는 것을 의미해요. 예를 들어, Proxmox VE 관리용 네트워크, VM 서비스용 네트워크, 스토리지용 네트워크 등을 분리하는 거죠. 이렇게 하면 한 구역이 뚫려도 다른 구역으로의 확산을 막을 수 있습니다.

    저는 보통 물리적 네트워크 인터페이스 카드(NIC)를 여러 개 사용하거나, VLAN(Virtual Local Area Network)을 활용해서 네트워크를 나눕니다. 관리 네트워크는 외부 인터넷과 직접 연결되지 않도록 하고, VM 서비스 네트워크만 필요한 포트만 열어두죠. 처음엔 귀찮아서 한데 뭉쳐놨었는데, 나중에 문제가 생겼을 때 트러블슈팅도 훨씬 어렵고, 보안적으로도 너무 취약하더라고요. 그래서 지금은 무조건 나누는 걸 원칙으로 합니다.

    Proxmox VE에서는 vmbr0, vmbr1 등 리눅스 브릿지(Linux Bridge)를 활용해서 가상 네트워크를 구성해요. 물리 NIC와 연결하거나, VLAN 태그를 지정할 수 있죠.

    6. Proxmox VE 시스템 최신 유지 🔄

    소프트웨어는 항상 최신 상태로 유지하는 게 중요합니다. Proxmox VE도 마찬가지거든요. 개발팀은 지속적으로 보안 취약점을 패치하고 새로운 기능을 추가하니까요. 오래된 버전은 알려진 취약점에 노출될 위험이 크거든요.

    저는 정기적으로 업데이트를 확인하고 적용하는 루틴을 가지고 있습니다. 한 달에 한 번 정도는 꼭 확인해서 업데이트를 진행하죠. 물론 업데이트 전에 백업은 필수예요! 업데이트하다가 예기치 않은 문제가 생길 수도 있거든요. 이 부분은 제가 나중에 백업 관련 글로 자세히 다룰 예정입니다.

    # Proxmox VE 업데이트
    apt update
    apt dist-upgrade
    
    # 재부팅이 필요한 경우 (커널 업데이트 등)
    reboot

    apt dist-upgrade는 새로운 커널이나 주요 패키지 업데이트를 포함하므로, 항상 변경 내용을 확인하고 신중하게 진행해야 합니다. 특히 프로덕션 환경이라면 더더욱 그렇고요!

    7. 백업 및 복구 전략 보안 💾

    아무리 보안을 잘해도 사고는 언제든 일어날 수 있어요. 랜섬웨어 공격, 하드웨어 고장, 실수로 인한 데이터 손실 등 다양한 위협으로부터 데이터를 보호하기 위해 백업은 필수입니다. 그리고 이 백업 데이터 자체도 안전하게 관리해야 합니다.

    저는 Proxmox Backup Server (PBS)를 활용해서 백업을 하더라고요. PBS는 효율적인 증분 백업(Incremental Backup)과 중복 제거(Deduplication)는 물론, 백업 암호화(Backup Encryption) 기능까지 제공해서 데이터를 안전하게 보관할 수 있게 해줍니다. 백업 데이터를 외부(Off-site) 스토리지에 보관하는 것도 중요해요. 물리적으로 다른 위치에 두는 거죠.

    그리고 백업이 잘 되는지 주기적으로 복구 테스트를 해보는 것도 정말 중요합니다. 백업만 있고 복구가 안 되면 아무 소용 없잖아요? 제가 예전에 백업은 잘 했는데, 복구 테스트를 안 했다가 막상 필요할 때 복구가 안 돼서 식은땀 흘렸던 적이 있어요… 😅

    Proxmox VE 보안 강화 체크리스트 10가지 요약 인포그래픽

    Proxmox VE 보안 강화의 핵심 10가지 항목을 요약하고 시각적으로 강조한 인포그래픽입니다.

    8. 사용자 및 권한 관리 (RBAC) 👥

    Proxmox VE는 역할 기반 접근 제어(Role-Based Access Control, RBAC)를 지원해요. 관리자 계정 하나로 모든 걸 다 하는 것보다는, 필요한 최소한의 권한만 부여하는 최소 권한 원칙(Principle of Least Privilege)을 지키는 게 중요합니다. 예를 들어, VM만 관리하는 사용자에게는 스토리지나 네트워크 설정 권한을 주지 않는 거죠.

    Proxmox VE 웹 UI에서 [Datacenter] > [Permissions]로 들어가면 사용자(Users), 그룹(Groups), 역할(Roles)을 정의할 수 있습니다. 처음엔 좀 복잡하게 느껴질 수도 있지만, 익숙해지면 훨씬 체계적으로 관리할 수 있더라고요.

    저도 처음엔 그냥 root 계정 하나로 모든 걸 했다가, 실수로 중요한 설정을 건드릴 뻔한 적이 여러 번 있습니다. 그때마다 ‘아, 이러면 안 되겠구나’ 싶어서 권한을 쪼개기 시작했죠. 특히 여러 사람이 함께 Proxmox VE를 관리하는 환경이라면 이 기능은 정말 필수예요.

    9. 불필요한 서비스 비활성화 🛑

    운영체제에는 기본적으로 다양한 서비스(Daemon)들이 설치되어 있어요. 이 중에는 Proxmox VE 운영에 반드시 필요하지 않거나, 사용하지 않는 서비스들도 있을 수 있습니다. 불필요한 서비스를 비활성화하면 공격 표면(Attack Surface)을 줄이고 시스템 자원을 절약할 수 있거든요.

    예를 들어, Proxmox VE를 설치하면 apt-cacher-ng 서비스가 자동으로 설치되는 경우가 있는데, 만약 여러 대의 Proxmox 서버를 운영하는 환경이 아니라면 굳이 필요 없을 수 있습니다. 이런 서비스들을 확인하고 비활성화하는 것이 좋아요.

    # 현재 실행 중인 서비스 목록 확인
    systemctl list-units --type=service --state=running
    
    # 특정 서비스 비활성화 (예시: apt-cacher-ng)
    systemctl stop apt-cacher-ng
    systemctl disable apt-cacher-ng

    ⚠️ 경고: 어떤 서비스가 시스템에 필요한지 확실히 모른다면 섣불리 비활성화하지 마세요. 잘못하면 시스템이 부팅되지 않거나 정상적으로 작동하지 않을 수 있거든요. Proxmox 관련 핵심 서비스는 절대 건드리면 안 됩니다!

    10. 정기적인 보안 감사 및 모니터링 🔍

    마지막으로, 모든 보안 설정이 잘 작동하는지 정기적으로 확인하고 모니터링하는 게 정말 중요합니다. 시스템 로그를 확인하고, 이상 징후는 없는지 살펴보는 거죠. fail2ban 같은 도구를 사용하면 SSH 무작위 대입 공격 시도를 자동으로 차단하는 데 큰 도움이 됩니다.

    저는 journalctl 명령어를 자주 사용해서 로그를 살펴봐요. 특히 SSH 접속 시도 로그나 방화벽 차단 로그 같은 것들이죠. 처음엔 그냥 지나쳤는데, 자세히 보니 수상한 IP에서 계속 접속 시도가 있더라고요. 그때부터 fail2ban을 설치해서 사용하기 시작했습니다. 이거 진짜 편하더라고요!

    # 최근 로그 확인
    journalctl -f
    
    # fail2ban 설치 및 설정
    apt install fail2ban
    cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
    nano /etc/fail2ban/jail.local
    # [sshd] 섹션에서 enabled = true 로 변경하거나 원하는 설정 적용
    systemctl enable fail2ban
    systemctl start fail2ban

    ⚠️ 삽질 경험과 해결 과정

    솔직히 이 모든 과정을 한 번에 완벽하게 해내기란 쉽지 않습니다. 저도 여러 번 삽질 좀 했거든요. 특히 SSH 설정을 강화하다가 제 발등을 찍었던 적이 많아요. PermitRootLogin no와 PasswordAuthentication no를 설정하고 sshd를 재시작했는데, 그만 SSH 키 인증이 제대로 안 되어 있어서 서버에 접속하지 못했던 거죠. 다행히 Proxmox VE는 콘솔 접속(Keyboard & Monitor)이 가능해서 직접 가서 복구했습니다만… 원격으로만 관리하는 서버였다면 정말 큰일 날 뻔했어요.

    이런 경험을 통해 배운 건, ‘변경 전에 항상 백업하고, 변경 후에는 반드시 검증하라’는 거예요. 특히 원격 접속 설정은 더더욱 신중해야 합니다. 콘솔 접속이 불가능한 환경이라면 ‘Rollback Plan(롤백 계획)’을 미리 세워두는 것이 좋아요.

    🎉 안전한 Proxmox 환경, 직접 확인해보니

    위에 언급된 체크리스트를 하나씩 적용하고 나면, 여러분의 Proxmox VE 환경은 훨씬 견고해질 겁니다. SSH 포트가 바뀌고, 키 인증으로만 접속되며, 웹 UI는 2단계 인증을 거쳐야만 들어갈 수 있게 되죠. 방화벽 덕분에 불필요한 트래픽은 차단되고, 시스템은 항상 최신 상태를 유지하게 됩니다. 이런 변화들을 직접 체감하면 정말 뿌듯하더라고요!

    각 설정이 제대로 적용되었는지 확인하는 것도 중요합니다. 예를 들어, SSH 포트 변경은 netstat -tuln | grep <새로운 포트> 명령어로 확인할 수 있고, 방화벽 규칙은 Proxmox VE 웹 UI의 [Datacenter] > [Firewall] 섹션에서 확인할 수 있어요.

    보안 강화 설정이 완료된 Proxmox VE 환경 대시보드

    Proxmox VE의 보안 설정이 강화된 후의 상태를 보여주는 대시보드 또는 주요 보안 설정 활성화 여부를 시각적으로 나타낸 이미지입니다.

    💡 마무리하며: 13년차 서버실의 다음 이야기

    오늘은 Proxmox VE 보안 강화 체크리스트 10가지를 통해 안전한 가상화 환경을 구축하는 방법을 알아봤습니다. 기본적인 비밀번호부터 시작해서 SSH 보안, 2FA Proxmox, Proxmox 방화벽 설정, 네트워크 세그멘테이션까지, 이 모든 과정이 처음엔 어렵게 느껴질 수 있지만, 하나씩 따라 하다 보면 어느새 튼튼한 서버실을 만들고 있는 자신을 발견할 수 있을 거예요. 이 경험들이 여러분의 인프라 엔지니어링 여정에 큰 도움이 되기를 바랍니다. 다음번에는 Proxmox VE의 백업 전략에 대해 좀 더 깊이 있는 이야기를 나눠볼까 합니다. 그때까지 여러분의 서버실이 안전하길 바랍니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 저도 함께 고민해드릴게요! 😊

  • [Proxmox] Proxmox VE 8.2 심층 분석: 데이터센터 관리 기능과 주요 개선점

    [Proxmox] Proxmox VE 8.2 심층 분석: 데이터센터 관리 기능과 주요 개선점

    도입부: 왜 Proxmox VE 8.2에 주목해야 할까요?

    안녕하세요, 13년차 서버실 지킴이입니다. 요즘 인프라 환경이 정말 빠르게 변하고 있죠? 특히 가상화 솔루션은 기술 스택의 핵심 중 하나라고 해도 과언이 아닙니다. 많은 분들이 VMware의 라이선스 정책 변화 때문에 오픈소스 대안을 찾고 계실 텐데요. 저도 홈랩을 운영하면서 이 문제에 대해 늘 고민하고 있거든요. 그러던 와중에 Proxmox VE (Virtual Environment) 8.2가 드디어 출시되었다는 소식을 들었습니다!

    Proxmox VE는 KVM 기반의 가상화와 LXC 컨테이너를 통합하여 단일 플랫폼에서 관리할 수 있는 강력한 오픈소스 솔루션입니다. 저처럼 작은 규모의 서버실이나 홈랩을 운영하는 입장에서는 비용 효율적이면서도 엔터프라이즈급 기능을 제공하는 Proxmox VE가 정말 매력적일 수밖에 없는데요. 이번 8.2 버전에서는 데이터센터 관리 기능이 한층 더 강화되고 다양한 개선점이 추가되었다고 해서, 제가 직접 한번 파헤쳐 봤습니다. 혹시 여러분도 VMware에서 Proxmox VE로의 마이그레이션을 고민하고 계시다면, 이 글이 좋은 가이드가 될 거라고 생각해요!

    Proxmox VE 클러스터의 전체적인 구성도를 보면, 왜 이 솔루션이 데이터센터 관리에 효율적인지 한눈에 이해할 수 있습니다.

    Proxmox VE 8.2, 무엇이 달라졌나? (핵심 개념 설명)

    Proxmox VE는 기본적으로 Debian Linux 위에 KVM(Kernel-based Virtual Machine)과 LXC(Linux Containers)를 통합하여 제공합니다. 쉽게 말해, KVM으로 Windows나 다른 Linux 같은 다양한 운영체제의 가상 머신(Virtual Machine, VM)을 만들 수 있고, LXC로는 가벼운 리눅스 컨테이너를 만들어서 애플리케이션을 격리된 환경에서 실행할 수 있다는 뜻이죠. 이걸 하나의 웹 인터페이스에서 모두 관리할 수 있다는 게 Proxmox VE의 가장 큰 장점입니다.

    KVM 기반 가상화와 LXC 컨테이너의 조화

    • KVM (Kernel-based Virtual Machine): 하드웨어 가상화 기술을 활용하여 OS 커널 레벨에서 완전한 가상 머신을 생성합니다. 높은 성능과 격리성을 제공하며, 다양한 게스트 OS를 지원하죠.
    • LXC (Linux Containers): OS 레벨 가상화로, 호스트 OS의 커널을 공유하며 격리된 사용자 공간을 제공합니다. VM보다 훨씬 가볍고 빠르며, 리소스 오버헤드가 적습니다.

    이번 Proxmox VE 8.2에서는 이런 기본적인 강점에 더해, 사용자 경험을 개선하고 인프라 관리의 복잡성을 줄여주는 여러 기능들이 추가되었더라고요. 특히 데이터센터 규모에서 효율성을 높일 수 있는 기능들이 눈에 띄었습니다.

    주요 개선점 심층 분석: 데이터센터 관리 기능 강화

    이번 8.2 버전에서 가장 인상 깊었던 점은 역시 데이터센터 관리와 스토리지 효율성에 대한 부분이었습니다. 저처럼 스토리지 구성에 늘 목마른 사람에게는 정말 반가운 소식이었죠.

    ZFS dRAID 지원 (Data Redundancy over Arrays of Independent Disks)

    드디어 ZFS dRAID가 정식으로 지원됩니다! ZFS는 강력한 파일 시스템이자 볼륨 관리자로, 데이터 무결성과 스냅샷 기능으로 유명하죠. 기존 RAIDZ2 등도 훌륭했지만, dRAID는 좀 더 유연한 확장성과 빠른 리빌드(Rebuild) 속도를 제공합니다. 대규모 스토리지 환경에서 디스크 장애 시 복구 시간을 단축할 수 있다는 건 정말 큰 장점이에요. 제가 직접 홈랩에서 ZFS 풀을 구성하고 재구성할 때마다 시간이 오래 걸려서 답답했었는데, dRAID는 이런 고충을 덜어줄 것 같더라고요.

    Ceph Quincy → Reef 업그레이드 (분산 스토리지)

    분산 스토리지 솔루션인 Ceph도 Quincy에서 Reef로 업그레이드되었습니다. Ceph Reef는 성능 개선과 함께 관리 기능이 더 편리해졌습니다. 특히 소규모 클러스터에서도 효율적으로 운영할 수 있도록 최적화된 부분들이 있어서, 저처럼 제한된 리소스로 여러 노드를 운영하는 환경에 아주 적합하다고 생각합니다. Ceph를 Proxmox VE와 함께 사용하면 VM 디스크 이미지를 여러 노드에 분산 저장하여 고가용성(High Availability, HA)을 확보할 수 있거든요.

    # Ceph 상태 확인 (Proxmox VE 8.2에서)
    ceph -s
    
    # Ceph OSD 트리 확인
    ceph osd tree
    

    스냅샷 기반 백업 최적화

    이번 버전에서는 스냅샷 기반 백업 최적화 기능이 한층 더 강화되었습니다. VM 백업 시 생성되는 스냅샷의 I/O 부하를 더 효율적으로 관리할 수 있게 개선됐거든요. 특히 스토리지 성능이 제한적이거나, 동시에 여러 VM을 백업해야 할 때 정말 유용합니다. 백업 중에도 VM의 성능 저하를 최소화할 수 있어서, 서비스 중단 없이 안정적인 백업 운영이 가능해졌다는 게 핵심입니다. 제가 예전에 백업 돌리다가 VM이 버벅거려서 사용자들한테 컴플레인 들었던 적이 한두 번이 아니었거든요. 이 개선점이 있다면 그런 걱정을 덜 수 있겠네요!

    Proxmox VE 8.2 Ceph Reef 클러스터 관리 대시보드

    Proxmox VE 웹 UI에서 Ceph Reef 클러스터의 상태를 한눈에 모니터링하는 모습입니다.

    실전 적용: Proxmox VE 8.2 설치 및 초기 설정 팁

    Proxmox VE 8.2 설치 과정은 기존 버전과 크게 다르지 않습니다. 하지만 몇 가지 팁을 드리자면, 설치 시 파일 시스템 선택이 중요해요. 특히 ZFS를 사용하실 계획이라면, 설치 단계에서 미리 구성해두는 것이 편리합니다. 저 같은 경우에는 ZFS Root on RAID1으로 OS를 설치하고, 데이터용으로 별도의 ZFS dRAID 풀을 구성하는 방식을 선호합니다.

    설치 후에는 항상 시스템을 최신 상태로 유지하는 것이 중요합니다. 터미널에서 다음 명령어를 실행해주세요.

    sudo apt update
    sudo apt dist-upgrade -y
    sudo reboot
    

    그리고 Proxmox Backup Server (PBS)를 연동하는 것도 잊지 마세요. Proxmox VE의 백업 기능을 100% 활용하려면 PBS가 필수거든요. PBS는 증분 백업(Incremental Backup)과 중복 제거(Deduplication) 기능을 제공해서 스토리지 사용량을 획기적으로 줄여줍니다. 제가 직접 써보니까, 백업 용량이 정말 드라마틱하게 줄어들더라고요!

    VMware 마이그레이션 관점에서 본 Proxmox VE 8.2

    VMware에서 Proxmox VE로 넘어오는 분들이 많으실 텐데요, Proxmox VE 8.2는 이런 마이그레이션 시나리오를 더욱 강력하게 지원합니다. 기본적으로 qemu-img 툴을 사용하여 VMDK 파일을 QCOW2나 RAW 포맷으로 변환할 수 있습니다. 예를 들어:

    # VMDK 파일을 QCOW2로 변환
    qemu-img convert -f vmdk /path/to/your/vmware.vmdk -O qcow2 /path/to/your/new_proxmox_vm.qcow2
    

    변환된 이미지를 Proxmox VE 스토리지로 옮기고, 새로운 VM을 생성할 때 해당 디스크 이미지를 연결해주면 됩니다. 이 과정에서 네트워크 드라이버나 가상 하드웨어 설정을 Proxmox VE 환경에 맞게 조정해야 하는 경우가 많으니, 꼭 충분한 테스트를 거치셔야 해요. 특히 VMware Tools에 해당하는 QEMU Guest Agent를 VM에 설치하는 것은 성능 향상과 스냅샷 일관성을 위해 필수적입니다.

    Proxmox VE의 웹 UI를 통해 VM을 생성하고, 변환된 디스크를 추가하는 과정은 직관적이라 어렵지 않을 겁니다. 사실 제가 처음 VMware에서 Proxmox VE로 마이그레이션할 때 가장 걱정했던 부분인데, 막상 해보니 생각보다 쉬웠습니다. 물론 삽질이 없었던 건 아니지만요! 😉

    Proxmox VE에서 VMware VMDK 가져와 VM 생성하는 과정

    VMware 환경에서 사용하던 VMDK 파일을 Proxmox VE로 가져와 새로운 가상 머신을 만드는 과정입니다.

    ⚠️ 삽질 경험: 백업 설정 시 주의할 점

    이번 Proxmox VE 8.2의 백업 기능, 정말 좋다고 말씀드렸잖아요? 그런데 제가 이걸 설정하다가 한 번 크게 삽질했습니다. 분명 설정은 다 했는데, 백업 로그를 보니 뭔가 제대로 동작하지 않는 거예요. 처음엔 ‘이게 뭔가 싶었는데’ 알고 보니 Proxmox Backup Server (PBS)와 Proxmox VE 클러스터 간의 네트워크 지연 시간(Latency)이 너무 높아서 제대로 협업이 안 되고 있었던 거였죠.

    백업 성능의 핵심은 Proxmox VE 호스트와 PBS 간의 긴밀한 통신입니다. 만약 네트워크 환경이 좋지 않다면, 최적의 성능을 기대하기 어려울 수 있습니다. 그래서 제가 드리는 팁은:

    1. 네트워크 대역폭과 Latency 확인: 백업 트래픽이 몰리는 시간대에 네트워크 모니터링을 꼭 해보세요.
    2. 전용 백업 네트워크 구성: 가능하다면 Proxmox VE 클러스터와 PBS 사이에 전용 백업 네트워크를 구성하는 것이 가장 좋습니다.
    3. QEMU Guest Agent 설치 확인: 백업 대상 VM에 QEMU Guest Agent가 제대로 설치되어 실행 중인지 다시 한번 확인하세요. 이 Agent가 없으면 스냅샷 일관성을 보장할 수 없어요.

    이 세 가지를 점검하고 나서야 백업이 의도한 대로 동작하는 걸 확인할 수 있었어요. 역시 인프라는 눈으로 보이는 게 다가 아니라니까요! 😅

    마무리: Proxmox VE 8.2, 앞으로의 기대

    Proxmox VE 8.2는 데이터센터 관리의 효율성을 높이고, VMware 마이그레이션을 고민하는 분들에게 더욱 강력한 대안을 제시하는 버전이라고 생각합니다. 특히 ZFS dRAID와 Ceph Reef 업그레이드, 그리고 스냅샷 최적화 같은 기능들은 실제 운영 환경에서 체감할 수 있는 큰 개선점들이에요. 오픈소스의 유연성과 강력한 커뮤니티 지원까지 더해져, 앞으로 Proxmox VE의 성장이 더욱 기대됩니다.

    저도 홈랩에서 Proxmox VE 8.2를 계속 사용하면서 새로운 기능들을 더 깊이 파고들어 볼 생각입니다. 혹시 여러분도 Proxmox VE를 사용하면서 궁금한 점이나 팁이 있다면 댓글로 공유해주세요. 서로의 경험을 나누면서 더 좋은 인프라를 만들어나갈 수 있으니까요!

    Proxmox VE 8.2의 핵심 개선점들을 한눈에 파악할 수 있는 요약 정보입니다.

    다음 단계 제안

    이번 글에서는 Proxmox VE 8.2의 주요 기능들을 살펴봤는데요, 다음번에는 Proxmox Backup Server (PBS)를 활용한 백업 전략과 재해 복구(Disaster Recovery, DR) 구성에 대해 좀 더 자세히 다뤄볼까 합니다. PBS는 Proxmox VE 생태계에서 정말 중요한 부분이니, 놓치지 마세요!

  • [Proxmox] Proxmox Ceph 스토리지 1년 실사용 후기: 장점, 단점, 비용 분석

    [Proxmox] Proxmox Ceph 스토리지 1년 실사용 후기: 장점, 단점, 비용 분석

    Proxmox Ceph 스토리지 1년 실사용 후기: 장점, 단점, 비용 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 13년차 인프라 엔지니어로 홈랩을 운영하면서 가장 크게 느꼈던 부분 중 하나가 바로 스토리지거든요. 처음엔 NAS(Network Attached Storage) 하나로 버텨봤는데, VM(Virtual Machine)도 늘어나고 데이터도 중요해지면서 단일 스토리지의 한계에 부딪히더라고요.

    Proxmox VE(Virtual Environment)를 쓰면서 여러 노드를 묶는 건 좋았는데, 각 노드에 붙은 로컬 스토리지(Local Storage)만으로는 VM 마이그레이션(Live Migration)이나 고가용성(High Availability, HA)을 구현하기가 애매했어요. 그래서 결국 분산 스토리지(Distributed Storage), 그중에서도 Ceph를 선택하게 됐고, Proxmox와 Ceph의 조합이 꽤 괜찮다는 이야기를 듣고 직접 구축해서 1년 넘게 써봤습니다. 그 솔직한 후기를 여러분께 공유해볼까 합니다. 저의 삽질 경험과 해결 과정이 여러분의 홈랩 구축에 도움이 되기를 바랍니다!

    Proxmox와 Ceph를 활용한 홈랩 분산 스토리지의 일반적인 아키텍처 다이어그램입니다. 여러 노드가 Ceph 클러스터를 구성하고 Proxmox가 이를 스토리지로 활용하는 구조를 보여줍니다.

    개념 설명: Proxmox Ceph, 도대체 뭘까요?

    Ceph(세프)는 오픈소스 기반의 분산 스토리지 시스템(Distributed Storage System)이거든요. 쉽게 말해, 여러 대의 서버에 있는 하드디스크나 SSD(Solid State Drive)를 마치 하나의 거대한 저장 공간처럼 묶어서 쓸 수 있게 해주는 기술입니다. 이게 단순히 파일 공유를 넘어, 블록 스토리지(Block Storage)나 객체 스토리지(Object Storage)까지 다양한 인터페이스를 제공해서 VM 디스크나 컨테이너 볼륨으로 쓰기에 아주 적합하더라고요.

    Proxmox VE는 가상화 플랫폼인데, Ceph 클러스터를 직접 구성하고 관리할 수 있는 기능이 내장돼 있어요. 덕분에 별도의 스토리지 서버를 구축하지 않고도 기존 Proxmox 노드를 활용해서 분산 스토리지를 만들 수 있죠. 이게 바로 제가 Ceph를 선택한 결정적인 이유 중 하나입니다. 고가용성(High Availability)이나 실시간 마이그레이션(Live Migration) 같은 기능들을 Ceph 스토리지와 함께 쓰면 더욱 강력해지는 걸 경험할 수 있거든요.

    1년 실사용 후기: 장점은 확실하네요!

    제가 1년 동안 Proxmox Ceph를 쓰면서 가장 만족스러웠던 점들을 꼽아보자면 이렇습니다.

    • ✅ 데이터 안전성 및 고가용성(HA): Ceph는 데이터를 여러 노드에 복제(replication)해서 저장하거든요. 예를 들어, 제가 3개의 노드에 Ceph를 구성하고 복제본 3개(replica 3)로 설정했었는데, 어느 날 노드 하나가 갑자기 다운되어도 VM들은 아무 문제 없이 잘 돌아가는 걸 보고 감탄했습니다. 이게 바로 HA의 위력이죠. 데이터 손실 걱정 없이 안정적으로 서비스를 운영할 수 있다는 점이 가장 든든했어요.

    • ✅ 쉬운 확장성(Scalability): 스토리지 용량이 부족하면 그냥 새로운 노드를 추가하거나, 기존 노드에 디스크를 더 달아서 Ceph OSD(Object Storage Daemon)로 추가하면 돼요. Proxmox 웹 UI(User Interface)에서 몇 번 클릭만 해주면 Ceph 클러스터가 자동으로 재조정되면서 용량이 늘어나더군요. 이 확장성 덕분에 홈랩을 운영하면서 스토리지 용량 걱정을 덜었습니다. SSD 몇 개 더 달아서 Ceph OSD로 추가하면 끝! 정말 편하더라고요.

    • ✅ 준수한 성능(Performance): 제 홈랩에서는 SATA SSD와 HDD를 섞어 썼는데, SSD로 구성된 OSD에서는 VM 성능이 꽤 만족스러웠어요. 여러 OSD에 데이터가 분산되어 저장되니 병렬 처리 효과도 있어서 단일 디스크보다 빠릿한 느낌이었습니다. 물론 엔터프라이즈급 장비만큼은 아니지만, 홈랩에서는 차고 넘치는 성능이었어요.

    • ✅ Proxmox와의 긴밀한 통합 관리: Proxmox 웹 인터페이스에서 Ceph 클러스터의 상태를 한눈에 볼 수 있고, OSD 추가/삭제, 풀(Pool) 관리까지 대부분의 작업을 처리할 수 있어서 관리 편의성이 정말 좋았습니다. 처음엔 Ceph 명령어를 일일이 쳐야 하나 걱정했는데, 통합 관리(Integrated Management) 덕분에 삽질을 많이 줄일 수 있었죠. 이거 진짜 편하더라고요.

    Proxmox 웹 UI Ceph 클러스터 상태 대시보드 화면

    Proxmox 웹 UI에서 Ceph 클러스터의 전반적인 상태를 보여주는 대시보드 화면입니다. OSD 상태, Health, 용량 정보 등을 한눈에 확인할 수 있습니다.

    아쉬웠던 점: 단점과 삽질 경험

    물론 장점만 있었겠습니까? 1년 동안 쓰면서 아쉬웠던 점이나 삽질했던 경험들도 꽤 됩니다. 처음엔 이게 뭔가 싶었는데, 해결하고 나니 다 피가 되고 살이 되더군요. ㅎㅎ

    • ⚠️ 초기 설정 및 트러블슈팅의 복잡성: Proxmox UI가 많이 도와주긴 하지만, Ceph 클러스터의 기본적인 아키텍처(Mon, OSD, Mgr 등)를 이해하지 못하면 문제 발생 시 해결하기가 쉽지 않더라고요. 저는 처음에 Ceph Monitor(모니터)를 3개로 구성해야 안정적이라는 걸 모르고 1개로 시작했다가, 노드 하나가 다운되니 클러스터 헬스가 엉망이 되는 경험을 했습니다. 이럴 때 ceph status 명령어로 클러스터 상태를 확인해볼 수 있어요.

      ceph status

      이 명령어를 통해 Mon(모니터), OSD(오브젝트 스토리지 데몬) 등의 상태를 확인하고 문제점을 파악할 수 있었죠. 결국 Mon을 추가하고 안정화시키는 데 삽질 좀 했습니다.

    • ⚠️ 생각보다 높은 자원 소모: Ceph는 분산 스토리지다 보니 각 노드에서 OSD 프로세스가 계속 돌아갑니다. 특히 디스크 I/O가 많아지면 CPU 사용량도 꽤 올라가고, RAM도 OSD 하나당 최소 2~4GB 정도는 필요하다고 느껴졌어요. 홈랩에서 저사양 장비로 구성하려다 보니, VM 몇 개 돌리기도 전에 Ceph 자체가 자원을 너무 많이 먹어서 VM 성능이 저하되는 경험도 했었네요. 자원 계획(Resource Planning)이 정말 중요합니다. 이거 진짜 간과하기 쉬운 포인트예요!

    • ⚠️ 네트워크 대역폭의 중요성: Ceph는 노드 간에 데이터를 주고받는 통신이 매우 활발합니다. 처음엔 1GbE(기가비트 이더넷) 네트워크로 구성했다가 VM 성능이 영 시원찮아서 고생했어요. 데이터를 복제하고 재배치하는 과정에서 네트워크가 병목(bottleneck)이 되더군요. 결국 10GbE(텐 기가비트 이더넷) NIC(Network Interface Card)를 추가하고 스위치도 바꾸면서 해결했는데, 이 비용도 만만치 않았습니다. Ceph를 제대로 쓰려면 최소 10GbE 네트워크는 필수라고 생각해요.

    • ⚠️ 성능 튜닝의 어려움: Ceph의 성능을 최적화하려면 OSD 디스크의 종류(SSD vs HDD), 저널링(Journaling) 방식, 네트워크 구성, 풀(Pool) 설정 등 고려할 요소가 너무 많아요. 저도 여러 자료를 찾아보면서 이것저것 튜닝해봤지만, ‘이게 최적이다!’라고 딱 말하기가 어렵더라고요. 이 부분은 여전히 저에게 숙제로 남아있습니다.

    비용 분석: 홈랩에서 Ceph, 합리적일까요?

    그럼 이제 가장 궁금해하실 부분 중 하나, 비용 분석을 해볼 차례입니다. 홈랩에서 Proxmox Ceph를 구축하는 게 과연 합리적일까요? 저의 경우를 예로 들어볼게요. (대략적인 비용이며, 실제 제품명/가격은 언급하지 않습니다.)

    • 서버: 저는 기존에 가지고 있던 미니 PC 3대를 활용했습니다. (약 30만원 x 3대 = 90만원 상당)

    • 디스크: Ceph OSD용으로 SATA SSD 2TB 3개, HDD 4TB 3개를 추가 구매했습니다. (SSD 약 15만원 x 3개 = 45만원, HDD 약 10만원 x 3개 = 30만원)

    • 네트워크 장비: 10GbE NIC 3개와 10GbE 지원 스위치 1대를 구매했습니다. (NIC 약 8만원 x 3개 = 24만원, 스위치 약 20만원 = 20만원)

    • 전기 요금: 3대의 서버가 24시간 돌아가니 한 달에 대략 3~5만원 정도 추가 요금이 발생하더군요. (연간 36~60만원)

    초기 하드웨어 투자 비용만 대략 200만원 정도 들었습니다. 여기에 전기 요금까지 고려하면 꽤 부담될 수 있는 금액이죠. 하지만 이 비용으로 얻는 데이터 안전성, 고가용성, 확장성을 생각하면 충분히 가치 있는 투자라고 생각해요. 특히 소프트웨어 라이선스 비용이 없다는 점은 큰 장점입니다. 엔터프라이즈급 SDS(Software Defined Storage) 솔루션에 비하면 훨씬 저렴하게 동일한 수준의 분산 스토리지를 구축할 수 있거든요.

    하지만 삽질 비용(시간과 노력)은 계산하기 어렵습니다. 저처럼 직접 구성하고 문제를 해결하는 과정을 즐기는 분들에게는 더없이 좋은 경험이 되겠지만, 단순히 ‘편리한 스토리지’만을 원한다면 초기 진입 장벽이 높다고 느낄 수도 있어요. 이 부분은 스스로에게 질문을 던져봐야 합니다!

    Proxmox Ceph 스토리지 구축 및 운영 비용 분석 차트

    Proxmox Ceph 스토리지 구축 및 운영에 필요한 주요 비용 요소를 시각적으로 보여주는 원형 차트입니다. 하드웨어, 전기 요금, 소프트웨어(오픈소스), 그리고 시간/노력의 비율을 나타냅니다.

    결론: Proxmox Ceph, 당신에게 어울릴까요?

    자, 이제 1년 동안 Proxmox Ceph를 써본 저의 최종 결론을 말씀드릴 시간입니다.

    Proxmox Ceph 스토리지, 이런 분들께 강력 추천합니다!

    • 💡 고가용성(HA)과 데이터 안전성을 중요하게 생각하는 홈랩 사용자: 중요한 VM 데이터가 있다면 Ceph의 복제 기능은 정말 든든한 보험입니다.

    • 💡 분산 스토리지 기술을 깊이 있게 경험하고 싶은 인프라 엔지니어: 실제 환경에서 Ceph를 구축하고 운영해보는 것만큼 좋은 학습은 없어요. 저도 이 과정을 통해 많은 것을 배웠습니다.

    • 💡 확장성 있는 스토리지가 필요한 분: 나중에 용량이 부족해질까 걱정 없이, 필요할 때마다 노드나 디스크를 추가하여 유연하게 확장하고 싶은 분들께 아주 좋습니다.

    하지만 이런 분들께는 좀 더 고민해보시라고 말씀드리고 싶어요.

    • ❌ 단순히 저렴하고 빠른 스토리지만을 원하는 분: 초기 설정의 복잡성이나 자원 소모를 감당하기 어려울 수 있어요. 이 경우엔 그냥 단일 NAS나 로컬 SSD를 쓰는 게 더 나을 수도 있습니다.

    • ❌ 기술적인 삽질(?)을 즐기지 않는 분: 안정적인 운영을 위해서는 Ceph에 대한 기본적인 이해와 트러블슈팅 능력이 필요합니다. 그냥 설치만 하면 끝나는 게 아니거든요!

    Proxmox Ceph 스토리지 장점, 단점 및 추천 대상 요약 인포그래픽

    Proxmox Ceph 스토리지의 주요 장점과 단점을 요약하고, 어떤 사용자에게 적합한지 추천 대상을 시각적으로 정리한 인포그래픽입니다.

    마무리: 다음 여정은?

    1년 동안 Proxmox Ceph와 함께 하면서 정말 많은 것을 느끼고 배웠어요. 초반에는 삽질의 연속이었지만, 결국 안정적인 분산 스토리지를 구축하고 운영하게 되면서 인프라 엔지니어로서 한 단계 더 성장한 것 같습니다. 드디어 됐다! 하는 성취감도 있었고요.

    다음번에는 CephFS(Ceph File System)를 활용해서 여러 VM에서 공유 스토리지를 쓰는 방법에 대해서도 다뤄볼까 합니다. 아니면 Ceph 오브젝트 스토리지(Object Storage)를 연동해서 S3 호환 스토리지를 구축하는 이야기도 재미있겠네요. 이전 글에서 다뤘던 Proxmox 초기 설정 관련 내용도 함께 참고하시면 좋을 것 같아요.

    혹시 여러분도 Proxmox Ceph를 사용 중이시거나, 구축을 고민하고 계시다면 어떤 점이 가장 궁금하신가요? 댓글로 자유롭게 의견 남겨주세요! 저의 경험이 여러분의 홈랩 구축에 조금이나마 도움이 되었기를 바랍니다. 🎉

  • [홈랩] Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석

    [홈랩] Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석

    [홈랩] Proxmox OMV 연동: NAS 구축을 위한 최적의 조합 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 홈랩을 운영하면서 정말 많은 분들이 고민하고 또 구축하려는 주제, 바로 NAS(Network Attached Storage)에 대해 이야기해보려 합니다. 특히 Proxmox(프록스목스) VE 환경에서 OpenMediaVault(OMV, 오픈미디어볼트)를 어떻게 연동해서 안정적이고 효율적인 NAS를 구축할 수 있을지에 대한 저의 경험과 삽질기를 솔직하게 공유해 드릴게요.

    혹시 여러분도 집에서 미디어 서버나 개인 파일 서버가 필요해서 NAS를 알아보고 계신가요? 시중에 완제품 NAS도 많지만, 직접 구축했을 때의 자유로움과 성능, 그리고 무엇보다 ‘내가 만들었다’는 뿌듯함은 비할 바가 못 되죠. 저도 처음엔 시놀로지나 헤놀로지 같은 걸 써볼까 하다가, 결국은 제가 가장 익숙한 Proxmox 위에 OMV를 올려서 사용하고 있습니다. 이게 진짜 편하더라고요!

    Proxmox VE 위 OMV NAS 구축 아키텍처 개요도

    1. 왜 Proxmox VE와 OpenMediaVault 조합인가요?

    제가 이 조합을 강력하게 추천하는 이유가 몇 가지 있습니다. 사실 처음에는 단순하게 생각했어요. 그냥 Proxmox VE(Virtual Environment)에 리눅스 깔고 Samba(삼바)나 NFS(네트워크 파일 시스템) 올리면 되는 거 아니야? 했었죠. 근데 막상 해보니 설정도 복잡하고, GUI(Graphical User Interface) 관리도 안 되고, Raid(레이드) 구성이나 사용자 권한 관리 같은 게 쉽지 않더라고요. 그래서 OpenMediaVault를 만나게 됐습니다.

    • Proxmox VE의 강력한 가상화 기능: Proxmox는 하이퍼바이저(Hypervisor)입니다. 즉, 하나의 물리 서버 위에 여러 개의 가상 머신(Virtual Machine, VM)이나 컨테이너(Container, LXC)를 동시에 돌릴 수 있게 해줘요. NAS 하나만 돌리기엔 아까운 고성능 서버를 다른 용도로도 활용할 수 있다는 거죠. 예를 들어, 저는 OMV 옆에 Plex 미디어 서버나 Docker 컨테이너들을 띄워서 쓰고 있거든요.
    • OpenMediaVault의 편리한 NAS 관리: OMV는 Debian(데비안) 기반의 무료 NAS 운영체제입니다. 웹 기반 GUI를 통해 파일 공유(SMB/CIFS, NFS, FTP), RAID 관리, 사용자/그룹 관리, 플러그인 확장(Docker, S.M.A.R.T. 등)을 아주 쉽게 할 수 있어요. 리눅스 명령어를 잘 몰라도 직관적으로 NAS를 운영할 수 있다는 게 큰 장점입니다. 제가 삽질 좀 해봤는데, OMV만큼 직관적인 NAS OS도 드물더라고요.
    • 분리된 환경으로 안정성 확보: OMV를 Proxmox VE의 VM으로 돌리면, NAS 시스템과 다른 서비스들이 서로 영향을 주지 않습니다. 혹시 OMV에 문제가 생겨도 Proxmox 호스트나 다른 VM에는 지장을 주지 않아요. 스냅샷(Snapshot)이나 백업(Backup) 관리도 훨씬 용이해지고요.

    2. Proxmox VE에서 OpenMediaVault VM 생성 및 디스크 패스쓰루

    자, 그럼 이제 본격적으로 Proxmox VE에 OMV VM을 만들고, 물리 디스크를 OMV VM으로 패스쓰루(PCI Passthrough)하는 방법을 알아볼게요. 이게 핵심이거든요! 그래야 OMV가 물리 디스크를 직접 인식하고 관리할 수 있습니다. 저는 이 과정에서 좀 헤맸는데, 여러분은 그러지 마시라고 자세히 알려드릴게요.

    2.1. OMV ISO 이미지 다운로드 및 Proxmox에 업로드

    먼저 OpenMediaVault 공식 웹사이트에서 최신 ISO 이미지를 다운로드합니다. 보통 .iso 파일 형태일 거예요. 저는 OMV 6 버전을 사용하고 있습니다.

    
    # Proxmox VE 웹 GUI 접속 후 '로컬 (pve)' -> 'ISO 이미지' -> '업로드' 버튼 클릭
    # 다운로드한 OMV ISO 파일을 선택하여 업로드
    

    이건 간단하니까 다들 아실 거라고 생각합니다. 웹 인터페이스가 진짜 편리하더라고요.

    2.2. OpenMediaVault 가상 머신(VM) 생성

    Proxmox VE 웹 GUI에서 우측 상단의 ‘VM 생성’ 버튼을 클릭하여 OMV VM을 만듭니다.

    1. General(일반): Name(이름)을 openmediavault 등으로 지정합니다.
    2. OS(운영체제): ‘ISO 이미지 사용’을 선택하고, 방금 업로드한 OMV ISO 파일을 선택합니다. Guest OS(게스트 OS)는 ‘Linux’ -> ‘5.x – 2.6 Kernel’로 설정하면 됩니다.
    3. System(시스템): 기본값으로 두거나, Qemu Agent(큐무 에이전트)를 설치할 예정이라면 ‘Qemu Agent’를 체크합니다.
    4. Disks(디스크): OMV OS가 설치될 가상 디스크를 생성합니다. 최소 10GB 이상으로 설정하는 것을 권장합니다. (Storage는 local-lvm 등 VM 디스크용 스토리지를 선택)
    5. CPU(프로세서): 코어 2개 이상, 소켓 1개 정도로 설정합니다.
    6. Memory(메모리): 최소 2GB 이상을 할당합니다. OMV가 생각보다 메모리를 좀 쓰는 편입니다.
    7. Network(네트워크): 기본값인 ‘Bridged Mode(브릿지 모드)’로 설정하여 OMV가 물리 네트워크에 직접 연결되도록 합니다.
    8. Confirm(확인): 설정을 확인하고 VM을 생성합니다. ‘Start after creation’은 체크 해제해 주세요. 바로 시작하지 않을 겁니다.

    2.3. 물리 디스크(HDD/SSD) 패스쓰루 설정 (매우 중요!)

    이제 OMV가 데이터 저장용으로 사용할 물리 디스크를 VM에 직접 연결해 줄 차례입니다. 이게 바로 Proxmox와 OMV 조합의 묘미라고 할 수 있죠. 저는 처음엔 가상 디스크로 만들어서 연결했었는데, 성능도 안 나오고 OMV에서 S.M.A.R.T. 정보도 제대로 못 읽는 문제가 발생했었어요. Host PCI Passthrough 대신 Host Disk Passthrough를 이용하는 방법을 추천합니다. 더 간단하고 안정적이거든요.

    1. VM 선택 및 ‘하드웨어’ 탭 이동: 생성한 openmediavault VM을 선택하고, 좌측 메뉴에서 ‘하드웨어’ 탭으로 이동합니다.
    2. ‘추가’ -> ‘하드 디스크’ 선택: ‘추가’ 버튼을 클릭하고 ‘하드 디스크’를 선택합니다.
    3. ‘물리적 디스크’ 선택: ‘스토리지’ 드롭다운 메뉴에서 (물리적 디스크)를 선택합니다. 그러면 Proxmox 호스트에 연결된 물리 디스크 목록이 나타납니다.
    4. 데이터 디스크 추가: OMV에서 사용할 데이터 저장용 디스크(예: /dev/sdb, /dev/sdc 등)를 선택하고 ‘추가’ 버튼을 클릭합니다. 주의할 점은 OMV OS가 설치될 디스크가 아닌, 데이터 저장용 디스크만 추가해야 합니다. 실수로 OS 디스크를 패스쓰루하면 큰일 납니다!
    5. 여러 디스크 추가: 필요한 만큼 이 과정을 반복하여 모든 데이터 디스크를 OMV VM에 추가합니다.

    이렇게 하면 OMV VM 내부에서는 마치 물리 서버에 직접 디스크가 연결된 것처럼 인식하게 됩니다. 드디어 됐다! 이 과정을 제대로 이해하고 나니 속이 다 시원하더라고요.

    Proxmox VE에서 물리 디스크를 VM에 패스쓰루하는 웹 GUI 화면

    Proxmox VE에서 물리 디스크를 VM에 패스쓰루하는 과정

    3. OpenMediaVault 설치 및 기본 설정

    이제 OMV VM을 시작하고 OMV를 설치할 차례입니다.

    1. VM 시작: 생성한 openmediavault VM을 선택하고 ‘시작’ 버튼을 클릭합니다.
    2. 콘솔 접속: ‘콘솔’ 탭으로 이동하여 OMV 설치 과정을 진행합니다. Debian 설치와 거의 동일합니다.
    3. 설치 언어, 키보드, 네트워크 설정: 한국어, 대한민국 등으로 설정하고, DHCP(동적 호스트 설정 규약)로 네트워크 설정을 진행합니다.
    4. 관리자 비밀번호 설정: root 계정의 비밀번호와 웹 관리자(admin) 계정의 비밀번호를 설정합니다. 이 비밀번호는 꼭 기억해두세요!
    5. OS 디스크 선택: 여기서 중요합니다! 아까 VM 생성 시 할당했던 10GB 이상의 가상 디스크(예: /dev/sda)를 선택하여 OMV OS를 설치합니다. 절대 패스쓰루한 데이터 디스크를 선택하면 안 됩니다!
    6. 설치 완료 및 재부팅: 설치가 완료되면 ISO 이미지를 VM에서 제거하고 재부팅합니다.

    3.1. OpenMediaVault 웹 GUI 접속 및 초기 설정

    재부팅 후 OMV VM의 IP 주소를 확인하여 웹 브라우저로 접속합니다. Proxmox 콘솔에 접속해서 ip a 명령어로 IP를 확인할 수 있습니다.

    
    # OMV 콘솔에서 IP 주소 확인
    ip a
    

    웹 브라우저에서 http://[OMV_VM_IP_주소]로 접속하여 admin 계정과 설정했던 비밀번호로 로그인합니다.

    로그인 후에는 다음 단계를 진행합니다.

    1. 파일 시스템 생성: ‘저장소’ -> ‘파일 시스템’ 메뉴로 이동합니다. 패스쓰루한 물리 디스크들이 보일 거예요. 각 디스크를 선택하여 ‘생성’ 버튼을 누르고, 원하는 파일 시스템(예: ext4)으로 포맷하고 마운트(Mount)합니다. 데이터가 있는 디스크라면 절대 포맷하면 안 됩니다! (저는 빈 디스크로 시작하는 걸 추천합니다.)
    2. RAID 관리 (선택 사항): 여러 디스크를 RAID로 묶고 싶다면 ‘저장소’ -> ‘RAID 관리’에서 설정할 수 있습니다. 저는 안정성을 위해 RAID 5를 선호합니다.
    3. 공유 폴더 생성: ‘접근 권한 관리’ -> ‘공유 폴더’에서 공유할 폴더를 생성하고, 파일 시스템과 경로를 지정합니다.
    4. 서비스 활성화: ‘서비스’ 메뉴에서 SMB/CIFS (Windows 파일 공유)나 NFS (Linux/macOS 파일 공유)를 활성화하고, 공유 폴더를 추가합니다.
    5. 사용자 및 그룹 관리: ‘접근 권한 관리’ -> ‘사용자’ 및 ‘그룹’에서 NAS에 접속할 사용자 계정을 생성하고 권한을 부여합니다.

    이 정도만 해도 기본적인 NAS 기능은 충분히 사용할 수 있어요. 처음엔 메뉴가 좀 많아 보이지만, 한 번 해보면 금방 익숙해질 거예요.

    OpenMediaVault 웹 관리 대시보드 스크린샷

    OpenMediaVault 웹 관리 대시보드 화면

    4. 주의사항 및 트러블슈팅: 제가 겪었던 삽질들 ⚠️

    홈랩 운영하면서 삽질은 필수라고 생각합니다. 저도 이 조합을 구축하면서 몇 가지 난관에 부딪혔었죠. 여러분은 이런 실수를 하지 마시라고 몇 가지 팁을 드립니다.

    • 디스크 패스쓰루 오류: 가끔 Proxmox에서 디스크를 패스쓰루했는데 OMV VM에서 인식이 안 되는 경우가 있었습니다. 이럴 때는 Proxmox 호스트에서 lsblk 명령어로 디스크가 제대로 인식되는지 확인하고, VM 설정에서 디스크 컨트롤러(예: SATA, VirtIO SCSI)를 바꿔보거나, Proxmox를 재부팅하면 해결되는 경우가 많더라고요. VirtIO SCSI가 성능상 더 좋지만, 가끔 특정 환경에서 문제가 생기기도 합니다.
    • OMV 업데이트 문제: OMV는 Debian 기반이라 apt update && apt upgrade 명령으로 업데이트합니다. 그런데 가끔 업데이트 중에 문제가 발생해서 부팅이 안 되거나 웹 GUI에 접속이 안 되는 경우가 있었어요. 이럴 땐 Proxmox의 스냅샷 기능이 빛을 발합니다. 업데이트 전에 VM 스냅샷을 하나 찍어두면, 문제가 생겨도 손쉽게 이전 상태로 되돌릴 수 있습니다. 💡 팁: 중요한 업데이트 전에는 꼭 스냅샷을 찍어두세요!
    • 네트워크 설정 문제: OMV VM의 IP 주소가 바뀌어서 접속이 안 되는 경우가 있습니다. Proxmox 콘솔이나 OMV 콘솔에서 ip a 명령으로 현재 IP 주소를 다시 확인하거나, OMV 설치 후 고정 IP(Static IP)로 설정하는 것을 권장합니다. 홈랩에서는 고정 IP가 훨씬 관리하기 편하거든요.
    • 성능 저하: VM에 할당된 CPU나 메모리가 너무 적으면 NAS 성능이 저하될 수 있습니다. 특히 여러 사용자가 동시에 접속하거나, 미디어 트랜스코딩(Transcoding) 같은 작업을 할 때는 충분한 리소스를 할당해 주는 것이 중요합니다.

    5. 검증 및 결과: 우리 집의 든든한 스토리지! 🎉

    모든 설정을 마치고 나면, 이제 여러분의 홈랩에 든든한 NAS가 완성됩니다! 저는 이렇게 구축한 OMV NAS를 다양하게 활용하고 있습니다.

    • 가족 사진/영상 백업: 스마트폰 사진을 자동으로 백업하도록 설정해서, 소중한 추억들을 안전하게 보관하고 있습니다.
    • 미디어 서버용 스토리지: Plex Media Server나 Jellyfin 같은 미디어 서버의 콘텐츠 저장소로 활용합니다. 대용량 영화 파일도 끊김 없이 스트리밍이 가능하더라고요.
    • 홈 자동화 데이터 저장: Home Assistant(홈 어시스턴트) 같은 홈 자동화 시스템의 로그나 백업 데이터를 저장하는 용도로도 사용합니다.
    • 개발 환경 공유 폴더: 제가 작업하는 개발 프로젝트 파일들을 공유 폴더에 넣어두고, 다른 VM이나 물리 PC에서 접근해서 사용하기도 합니다.

    실제로 써보니까 Proxmox VE와 OpenMediaVault의 조합은 유연성, 안정성, 그리고 관리 편의성까지 모두 잡을 수 있는 최적의 솔루션이라는 생각이 들었습니다. 특히 디스크 패스쓰루를 통해 물리 디스크를 직접 제어할 수 있다는 점이 가장 만족스러웠어요.

    Proxmox OMV NAS 구축의 장점들을 요약한 인포그래픽

    Proxmox OMV NAS 구축의 장점 요약

    6. 마무리하며: 다음 단계는 무엇일까요?

    오늘은 Proxmox VE 위에서 OpenMediaVault를 이용해 NAS를 구축하는 방법에 대해 자세히 알아봤습니다. 제가 직접 경험하며 얻은 노하우와 삽질기를 바탕으로 설명해 드렸는데, 도움이 되셨으면 좋겠네요. 처음엔 좀 복잡하게 느껴질 수도 있지만, 한 단계씩 따라오다 보면 분명 멋진 결과물을 얻으실 수 있을 거예요.

    이 조합은 단순히 NAS 기능만 제공하는 것을 넘어, 여러분의 홈랩을 한층 더 강력하게 만들어 줄 수 있는 기반이 될 겁니다. 다음 글에서는 이렇게 구축한 NAS를 활용하여 Docker(도커) 환경에서 Plex Media Server를 설치하거나, Tailscale(테일스케일)을 이용해 외부에서도 안전하게 NAS에 접속하는 방법에 대해 다뤄볼 예정입니다. 기대해주세요!

    궁금한 점이나 추가로 다루었으면 하는 내용이 있다면 언제든지 댓글로 남겨주세요. 저도 여러분의 경험을 공유받으며 배우고 싶습니다. 여기까지 읽어주셔서 감사합니다!

  • [Proxmox] PCIe 패스스루 오류: vGPU 가상화 실패 디버깅 사례

    [Proxmox] PCIe 패스스루 오류: vGPU 가상화 실패 디버깅 사례

    [Proxmox] PCIe 패스스루 오류: vGPU 가상화 실패 디버깅 사례

    안녕하세요, 13년차 서버실 지킴이, ’13년차의 서버실’입니다. 홈랩에서 다양한 장비들을 만져보며 삽질을 즐기는 저에게, 가장 큰 도전 중 하나는 역시 Proxmox PCIe 패스스루(Passthrough)더라고요. 특히 고성능 GPU를 가상 머신(Virtual Machine, VM)에 넘겨줘서 게임이나 AI 연산, 아니면 고사양 CAD 작업을 해보겠다고 마음먹었을 때의 그 설렘, 다들 경험해보셨죠?

    근데 이게 말처럼 쉽지가 않더라고요. 분명히 공식 문서와 수많은 가이드를 따라했는데도, VM에서는 GPU를 제대로 인식 못 하거나, 인식하더라도 알 수 없는 오류 코드(Error Code)를 뿜어내며 vGPU 가상화 실패를 알리는 경우가 많았습니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 삽질 끝에 해결했던 경험을 여러분과 공유하려고 합니다. 혹시 저와 비슷한 문제로 골머리를 앓고 계시다면, 이 글이 작은 도움이 되기를 바랍니다.

    그림 1: Proxmox와 PCIe 패스스루의 개념적 아키텍처. 호스트의 물리 GPU가 VM에 직접 연결되는 모습을 보여줍니다.

    PCIe 패스스루와 vGPU, 그리고 VFIO: 왜 이렇게 복잡할까?

    먼저, 우리가 이야기할 핵심 개념들을 간단히 짚어볼게요. 저도 처음엔 용어 때문에 많이 헤맸거든요.

    • PCIe Passthrough (PCIe 패스스루): 쉽게 말해, Proxmox 호스트 서버에 꽂혀 있는 물리적인 PCIe 장치(예: 그래픽 카드, NVMe SSD, 네트워크 카드)를 가상 머신(VM)이 마치 자기 것처럼 직접 사용할 수 있도록 ‘직통’으로 연결해주는 기술이에요. 호스트의 간섭 없이 장치의 모든 성능을 VM이 온전히 활용할 수 있게 해줍니다.
    • vGPU (Virtual GPU): 하나의 물리적인 GPU를 여러 가상 머신이 나눠 쓸 수 있도록 해주는 기술예요. NVIDIA GRID나 AMD MxGPU 같은 솔루션들이 대표적이죠. 하지만 우리가 보통 홈랩에서 시도하는 건, 하나의 물리 GPU를 하나의 VM에 통째로 넘겨주는 싱글 GPU 패스스루(Single GPU Passthrough)가 대부분입니다.
    • IOMMU (Input/Output Memory Management Unit): CPU가 메모리를 관리하는 MMU(Memory Management Unit)처럼, IOMMU는 입출력(I/O) 장치들이 메모리에 직접 접근하는 방식(DMA, Direct Memory Access)을 관리하고 격리시켜줘요. 이 기능이 활성화되어야만 PCIe 장치를 안전하게 VM에 넘겨줄 수 있습니다. BIOS/UEFI에서 VT-d (Intel) 또는 AMD-Vi (AMD)라는 이름으로 찾아볼 수 있어요.
    • VFIO (Virtual Function I/O): Linux 커널이 제공하는 표준 인터페이스로, 안전하게 PCIe 장치를 사용자 공간(user-space) 애플리케이션(여기서는 QEMU/KVM)에 전달하는 역할을 합니다. Proxmox에서 PCIe 패스스루를 구현할 때 vfio-pci라는 커널 모듈이 핵심적인 역할을 하죠.

    결국, 이 모든 기술들이 잘 맞물려야 비로소 VM에서 GPU를 사용할 수 있게 되는 거더라고요. 어느 하나라도 삐끗하면 가상화 오류가 발생하는 겁니다.

    실전 구현: 기본 패스스루 설정 과정

    제가 Proxmox에서 NVIDIA RTX 3060 그래픽 카드를 Windows VM에 패스스루 하려고 시도했던 과정을 예시로 들어볼게요. 기본적인 설정은 다음과 같습니다.

    1. BIOS/UEFI 설정 확인: 메인보드 BIOS/UEFI 설정에서 IOMMU, VT-d (Intel) 또는 AMD-Vi (AMD) 기능을 ‘Enabled’로 활성화해야 합니다. 이 단계를 빼먹으면 모든 것이 시작도 안 돼요! ⚠️
    2. GRUB 설정 수정: Proxmox 호스트의 GRUB 부트로더 설정에 IOMMU를 활성화하는 파라미터를 추가합니다.

      # /etc/default/grub 파일 편집
      sudo nano /etc/default/grub
      
      # GRUB_CMDLINE_LINUX_DEFAULT 값에 다음 추가 (Intel CPU)
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt"
      
      # 또는 AMD CPU의 경우
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet amd_iommu=on iommu=pt"
      
      # 변경사항 적용
      sudo update-grub
      sudo reboot
    3. VFIO 모듈 로드 및 블랙리스트 설정: Proxmox가 GPU 드라이버를 로드하지 않고, VFIO 모듈이 GPU를 점유하도록 설정합니다.

      # /etc/modules 파일에 다음 추가
      sudo nano /etc/modules
      
      # vfio_pci
      # vfio_iommu_type1
      # vfio
      # vfio_virqfd
      
      # 호스트 OS에서 GPU 드라이버 블랙리스트 처리
      sudo nano /etc/modprobe.d/blacklist.conf
      
      # blacklist nouveau
      # blacklist amdgpu
      # blacklist radeon
      # blacklist nvidiafb
      # blacklist snd_hda_intel # HDMI 오디오도 같이 넘길 경우
      
      # VFIO가 GPU ID를 잡도록 설정 (Vendor ID:Device ID)
      # GPU ID는 'lspci -nnk' 명령어로 확인합니다.
      # 예시: NVIDIA RTX 3060 (10de:2503) / HDMI Audio (10de:228e)
      sudo nano /etc/modprobe.d/vfio.conf
      
      # options vfio-pci ids=10de:2503,10de:228e disable_vga=1
      
      # 변경사항 적용 및 램디스크 업데이트
      sudo update-initramfs -u -k all
      sudo reboot
    4. IOMMU 그룹 확인: 재부팅 후, GPU가 제대로 VFIO 그룹에 할당되었는지 확인합니다.

      # IOMMU 그룹 확인 스크립트 (예시)
      # /usr/src/pve/iommu.sh 같은 이름으로 저장 후 실행
      #!/bin/bash
      for d in $(find /sys/kernel/iommu_groups/*/devices -type l | sort -V); do
          n=${d#*/iommu_groups/*}
          printf 'IOMMU Group %s ' "${n%%/*}"
          lspci -nns "${d##*/}"
      done

      여기서 GPU와 HDMI 오디오가 같은 IOMMU 그룹에 속해 있고, 다른 불필요한 장치들과 섞여 있지 않아야 해요. 만약 다른 장치와 섞여 있다면, 다음 섹션의 IOMMU Grouping 문제를 의심해봐야 합니다.

    5. Proxmox VM에 PCIe 장치 추가: Proxmox 웹 UI에서 VM 하드웨어 설정으로 들어가 ‘PCI 장치’를 추가하거나, qm set 명령어를 사용합니다. 중요한 것은 ‘모든 PCI 익스프레스 포트’를 활성화하고, ‘고급’ 옵션에서 ‘ROM-Bar’를 체크해주는 거예요.
    Proxmox VM 하드웨어 설정 PCI Device 추가 화면

    그림 2: Proxmox VM 설정 화면. PCI Device를 추가하고 ‘ROM-Bar’ 옵션을 활성화하는 모습입니다.

    ⚠️ 삽질의 시작: Proxmox vGPU 가상화 실패 디버깅 사례

    자, 여기까지는 일반적인 가이드에 나오는 내용입니다. 그런데 저의 삽질은 바로 여기서부터 시작됐더라고요. VM을 부팅하고 Windows 장치 관리자를 열어보니, 여지없이 ‘오류 코드 43’이 뜨더라고요. 드라이버를 아무리 다시 깔아도 마찬가지였습니다. 아, 이거 진짜 미치겠더라고요! 🤬

    제가 겪었던 주요 가상화 오류와 해결 과정은 다음과 같습니다.

    1. IOMMU Grouping 문제

    가장 흔한 문제더라고요. lspci -nns 명령어로 확인했을 때, GPU가 다른 불필요한 장치(예: USB 컨트롤러, SATA 컨트롤러)와 같은 IOMMU 그룹에 묶여 있는 경우가 있어요. IOMMU는 그룹 단위로만 패스스루를 허용하기 때문에, 이 경우 원하는 장치만 넘길 수가 없습니다.

    • 증상: VM에 GPU를 추가하려 할 때 Proxmox에서 ‘Device is in use’ 같은 에러가 발생하거나, 추가되더라도 VM에서 제대로 인식하지 못해요.
    • 해결책 (ACS Override 패치): GRUB 설정에 pcie_acs_override=downstream,multifunction 파라미터를 추가하여 IOMMU 그룹을 강제로 분리시키는 방법입니다. 저도 이 방법으로 많은 문제를 해결했어요.

      # /etc/default/grub 파일 수정
      sudo nano /etc/default/grub
      
      # GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"
      
      # 변경사항 적용
      sudo update-grub
      sudo reboot

      ⚠️ 주의: 이 방법은 IOMMU의 보안 기능을 약화시킬 수 있으니까, 보안에 민감한 환경에서는 신중하게 사용하셔야 해요. 홈랩 환경에서는 보통 큰 문제가 되지 않습니다.

    2. ROM BAR 또는 VBIOS 문제 (특히 NVIDIA 카드)

    NVIDIA 그래픽 카드에서 ‘오류 코드 43’이 뜨는 가장 큰 원인 중 하나였더라고요. NVIDIA 드라이버가 가상 환경에서 실행되는 것을 감지하고 스스로 기능을 제한하는 경우가 많거든요. 또, Proxmox가 GPU의 VBIOS(Video BIOS)를 제대로 로드하지 못해서 생기는 문제도 있어요.

    • 증상: Windows VM에서 장치 관리자에 ‘오류 코드 43’이 뜨거나, 화면이 나오지 않아요.
    • 해결책 (VBIOS 덤프 및 직접 로드): 호스트에서 GPU의 VBIOS 롬 파일을 직접 추출(덤프)해서 VM 설정에 지정해주는 방법입니다. 저는 이 방법으로 RTX 3060의 ‘오류 코드 43’을 해결했어요! 🎉

      1. VBIOS 덤프: 리눅스 환경에서 GPU의 VBIOS를 추출합니다. 다른 PC에 GPU를 연결해서 GPU-Z 같은 툴로 덤프하는 방법도 있어요.
        # VFIO에 바인딩되기 전의 GPU를 찾아서 롬 파일 덤프
        # 예시: GPU가 /sys/bus/pci/devices/0000:01:00.0 에 있을 경우
        sudo su
        echo 1 > /sys/bus/pci/devices/0000:01:00.0/rom
        cat /sys/bus/pci/devices/0000:01:00.0/rom > /var/lib/vz/snippets/vbios.rom
        echo 0 > /sys/bus/pci/devices/0000:01:00.0/rom
        exit
      2. VM 설정에 VBIOS 파일 지정: 덤프한 vbios.rom 파일을 Proxmox의 스니펫(Snippet) 경로(예: /var/lib/vz/snippets/)에 넣고, VM 설정에 추가합니다.
        # VM ID가 100번일 경우
        qm set 100 -args '-device vfio-pci,host=01:00.0,x-vga=on,romfile=/var/lib/vz/snippets/vbios.rom'
        # 또는 VM 설정 파일 직접 수정: /etc/pve/qemu-server/100.conf
        # args: -device vfio-pci,host=01:00.0,x-vga=on,romfile=/var/lib/vz/snippets/vbios.rom

        Proxmox 웹 UI에서 PCI 장치 추가 시 ‘ROM-Bar’ 옵션을 체크하는 것으로도 해결될 때가 있긴 하지만, 직접 롬 파일을 지정하는 것이 더 확실한 경우가 많았어요.

    IOMMU 그룹과 ACS Override 개념 다이어그램

    그림 3: IOMMU 그룹 문제와 해결책. ACS Override가 어떻게 장치 격리를 돕는지 보여줍니다.

    3. `vfio-pci` 드라이버 바인딩 실패

    가끔 Proxmox 호스트가 부팅될 때 GPU가 vfio-pci 드라이버에 제대로 바인딩(Binding)되지 않고, 다른 드라이버(예: nouveau, nvidia)에 먼저 잡히는 경우가 있어요. 이렇게 되면 VM에서 GPU를 사용할 수 없게 되죠.

    • 증상: lspci -nnk 명령어로 확인했을 때, GPU 장치 아래에 ‘Kernel driver in use: vfio-pci’ 대신 다른 드라이버가 표시돼요.
    • 해결책 (강제 바인딩): 부팅 시점에 스크립트를 통해 강제로 vfio-pci에 바인딩하도록 만들 수 있습니다. 보통은 /etc/modprobe.d/vfio.conf 설정으로 충분하지만, 간혹 필요한 경우도 있어요.

      # 부팅 스크립트 (예: /etc/rc.local 또는 systemd 서비스)
      # PCI 장치 ID 확인 (lspci -nnk)
      PCI_ID="0000:01:00.0" # 예시 GPU 장치 ID
      VENDOR_ID="10de"      # 예시 NVIDIA Vendor ID
      DEVICE_ID="2503"      # 예시 RTX 3060 Device ID
      
      if [ -e /sys/bus/pci/drivers/nvidia ]; then
        echo "$PCI_ID" > /sys/bus/pci/drivers/nvidia/unbind
      fi
      if [ -e /sys/bus/pci/drivers/nouveau ]; then
        echo "$PCI_ID" > /sys/bus/pci/drivers/nouveau/unbind
      fi
      
      echo "$VENDOR_ID $DEVICE_ID" > /sys/bus/pci/drivers/vfio-pci/new_id

    4. Proxmox 커널 버전 문제

    간혹 특정 Proxmox 커널 버전에서 PCIe 패스스루 관련 버그가 발생하기도 해요. 특히 최신 커널로 업데이트한 후에 문제가 생겼다면 의심해볼 만합니다.

    • 증상: 이전에는 잘 되던 패스스루가 특정 커널 업데이트 후 작동하지 않거나, 예상치 못한 오류가 발생해요.
    • 해결책: Proxmox의 이전 커널 버전으로 부팅하거나, 커널을 업데이트 또는 다운그레이드하는 것을 고려해봐야 합니다. Proxmox는 여러 커널을 설치하고 선택적으로 부팅할 수 있게 지원하거든요.

    검증과 결과: 드디어 성공!

    앞서 언급한 삽질을 거쳐 모든 설정을 마치고 VM을 부팅했을 때의 쾌감이란! 🥳 Windows VM의 장치 관리자를 열었을 때, 더 이상 ‘오류 코드 43’이 뜨지 않고 NVIDIA GeForce RTX 3060이 정상적으로 인식되는 것을 확인했어요. GPU-Z 같은 툴로도 모든 정보가 정확하게 표시되는 것을 보니 정말 뿌듯하더라고요.

    그리고 가장 중요한 것은, 실제 벤치마크 프로그램이나 게임을 돌렸을 때 물리 머신에 준하는 성능이 나오는 것을 확인했을 때예요. 이 순간을 위해 그렇게 많은 밤을 새워가며 디버깅했던 거겠죠.

    호스트에서도 lspci -nnk 명령어를 다시 실행하여 GPU가 여전히 vfio-pci에 바인딩되어 있는지 확인하는 것도 중요해요. ✅

    Windows VM에서 정상 인식된 NVIDIA GPU와 GPU-Z 화면

    그림 4: Windows VM에서 NVIDIA GPU가 정상 인식되고 GPU-Z로 상세 정보가 확인되는 모습입니다.

    마무리하며: 삽질은 경험이 됩니다

    Proxmox PCIe 패스스루는 인프라 엔지니어에게 정말 까다로운 도전 과제 중 하나예요. 수많은 변수와 시스템 환경에 따라 다른 문제를 일으키기 때문에, 정답이 하나로 정해져 있지 않거든요. 저도 수많은 가상화 오류를 겪었고, 그때마다 로그를 뒤지고 포럼을 찾아보며 디버깅했어요. 이 과정 자체가 저에게는 소중한 경험과 지식으로 남더라고요.

    핵심은 문제 발생 시 당황하지 않고, dmesg, journalctl -xe 같은 시스템 로그를 꼼꼼히 확인하고, IOMMU 그룹핑이나 VBIOS 문제 등 알려진 원인들을 하나씩 점검해나가는 끈기인 것 같아요. 그리고 가장 중요한 것은, 다양한 커뮤니티와 포럼에서 얻을 수 있는 정보들이에요. 비슷한 문제를 겪은 사람들의 경험담은 정말 큰 도움이 되거든요.

    이 글이 Proxmox PCIe 패스스루와 vGPU 가상화 실패로 고생하는 분들께 작은 등불이 되기를 바랍니다. 다음번에는 vGPU Manager를 활용해서 하나의 GPU를 여러 VM이 나눠 쓰는 방법을 다뤄볼까 합니다. 그때까지 다들 즐거운 삽질(?) 되세요! 😊