13년차의 서버실

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

[카테고리:] proxmox

  • [Proxmox] Proxmox Backup Server 1년 후기: 홈랩 백업 전략 어떻게 달라졌나

    [Proxmox] Proxmox Backup Server 1년 후기: 홈랩 백업 전략 어떻게 달라졌나

    1년 전으로 돌아가 보겠습니다

    솔직히 말씀드리면, 저도 한동안 백업을 대충 해왔습니다. Proxmox VE(이하 PVE)에서 VM 스냅샷 찍어두는 게 전부였거든요. 홈랩이라 어차피 실서비스도 아니고, “뭐 날아가면 다시 만들지” 하는 마인드였어요. 근데 딱 한 번, NVMe SSD가 조용히 죽으면서 제 생각이 완전히 바뀌었습니다. 그날 이후로 Proxmox Backup Server를 알아보기 시작했고, 결국 1년 넘게 운영하면서 정말 많은 걸 배웠어요.

    이 글은 PBS를 처음 도입한 분들이나, 지금 홈랩 백업 전략을 고민 중인 분들께 제 1년 경험을 그대로 공유하는 글입니다. 완벽한 가이드라기보다는, 삽질하면서 쌓인 경험담이라고 봐주시면 좋겠어요.

    ▲ 현재 제 홈랩 PBS 아키텍처 구성도. PVE 노드 2대가 단일 PBS 서버로 백업되는 구조입니다.

    Proxmox Backup Server가 뭔가요? (PBS 개념 이해)

    PBS는 Proxmox에서 만든 전용 백업 솔루션이에요. PVE와 별도로 설치하는 독립 서버입니다. 쉽게 말해서, PVE가 “VM 돌리는 서버”라면 PBS는 “그 VM들을 안전하게 저장하는 창고” 역할이라고 보시면 됩니다.

    일반 파일 복사 백업이랑 다르게, PBS는 몇 가지 핵심 기술을 씁니다.

    • 청크 기반 중복 제거(Chunk-based Deduplication): 같은 데이터 블록은 한 번만 저장. VM 10개가 동일한 Ubuntu 베이스 이미지를 쓴다면, 그 베이스 부분은 1개만 저장
    • 증분 백업(Incremental Backup): 변경된 부분만 전송해서 네트워크 부하와 시간을 확 줄여줌
    • zstd 압축: 저장 공간을 효율적으로 활용
    • 클라이언트 사이드 암호화(Client-side Encryption): 데이터가 PBS에 도달하기 전에 암호화

    처음엔 이게 뭔가 복잡해 보였는데, 실제로 써보니까 그냥 “그냥 돌아가는” 느낌이더라고요. 설정 한 번만 잘 잡아두면 나머지는 자동으로 돌아갑니다.

    PBS 초기 설치 및 설정 방법

    PBS는 Proxmox 공식 사이트에서 ISO를 받아서 별도 머신에 설치합니다. 저는 오래된 인텔 NUC에 설치했어요. 설치 과정 자체는 PVE랑 거의 비슷해서 어렵지 않았습니다.

    데이터스토어(Datastore) 생성

    설치 후 첫 번째로 할 일은 백업이 저장될 데이터스토어(Datastore) 만들기입니다. PBS 웹 UI에서 몇 번 클릭으로 가능해요.

    # PBS 웹 UI 접속: https://PBS-IP:8007
    # 또는 CLI로 데이터스토어 생성
    proxmox-backup-manager datastore create backup-store /mnt/backup-disk

    PVE에서 PBS 연결하기

    PVE 웹 UI에서 Datacenter → Storage → Add → Proxmox Backup Server를 선택하면 됩니다. 여기서 PBS의 IP, 포트(기본 8007), 사용자 계정, 데이터스토어 이름을 넣으면 끝이에요. 핑거프린트(Fingerprint)는 PBS 웹 UI 대시보드에서 확인할 수 있습니다.

    # CLI로 PVE에 PBS 스토리지 추가하는 방법 (PVE 노드에서)
    pvesm add pbs pbs-backup \
      --server 192.168.1.100 \
      --datastore backup-store \
      --username backup-user@pbs \
      --password 'YourSecurePassword' \
      --fingerprint XX:XX:XX:... # PBS 대시보드에서 확인

    백업 작업(Backup Job) 스케줄 설정

    PVE에서 Datacenter → Backup → Add로 백업 작업을 만듭니다. 저는 이런 식으로 잡아뒀어요.

    • 중요 VM(서비스용): 매일 새벽 3시, 주 7회 보관
    • 테스트용 VM: 주 2회, 4주 보관
    • 개발 환경 CT(Container): 매일 새벽 4시, 2주 보관
    Proxmox Backup Server 웹 UI 데이터스토어 설정 및 백업 작업 스케줄 화면

    ▲ PBS 웹 UI에서 데이터스토어와 백업 작업을 관리하는 화면 예시. 직관적인 인터페이스가 장점입니다.

    1년 실제 운영하며 겪은 것들

    중복 제거 효과가 진짜로 체감됩니다

    처음 한 달쯤 됐을 때, PBS 데이터스토어 사용량을 보고 깜짝 놀랐어요. VM 원본 데이터 합산이 2TB 정도였는데, PBS에 저장된 실제 데이터는 400GB 수준이더라고요. 중복 제거와 압축이 이 정도로 효과가 있을 줄은 몰랐습니다.

    특히 비슷한 OS를 쓰는 VM이 많을수록 효과가 극대화되더라고요. Ubuntu 22.04 베이스로 만든 VM이 7~8개 있었는데, 그 공통 부분이 한 번만 저장되니까 공간 절약이 확실하게 됩니다.

    검증(Verify) 작업의 중요성

    PBS에는 검증 작업(Verify Job)이 있어요. 저장된 백업 데이터가 실제로 멀쩡한지 주기적으로 체크해주는 기능인데, 처음엔 그냥 넘겼다가 나중에야 필수로 켜게 됐습니다.

    💡 팁: 백업이 있다고 안심하지 마세요. 검증하지 않은 백업은 “있는 것 같은” 백업일 뿐입니다. Verify Job을 주 1회 정도 설정해두는 걸 강력 추천드려요.

    가비지 컬렉션(Garbage Collection)도 꼭 설정하세요

    프루닝(Pruning, 오래된 백업 제거) 후에 실제 디스크 공간이 안 줄어서 한참 헤맸습니다. PBS는 청크 기반 저장 방식이라, 프루닝만으로는 공간이 바로 반환되지 않아요. 가비지 컬렉션(Garbage Collection)을 별도로 돌려야 합니다. 저는 매주 일요일 새벽에 GC 작업을 스케줄로 걸어뒀어요.

    # CLI로 가비지 컬렉션 수동 실행
    proxmox-backup-manager garbage-collection start backup-store
    
    # 진행 상태 확인
    proxmox-backup-manager task list | grep garbage

    ⚠️ 삽질 모음: 이건 미리 알았으면 좋았을 텐데

    문제 1: 백업은 되는데 복구가 안 되는 공포

    초기에 암호화를 켜고 백업을 쌓았는데, 키 파일 관리를 제대로 안 했어요. 나중에 테스트 복구를 해보려니 키가 어디 있는지 헷갈리는 상황이 발생했습니다. 정말 식은땀 흘렸어요.

    해결책: 암호화 키는 반드시 별도 안전한 곳에 백업해두세요. USB, 클라우드 보관함, 비밀번호 매니저 등 최소 2곳 이상에.

    # 암호화 키 백업하는 방법 (클라이언트 측)
    proxmox-backup-client key create --kdf scrypt
    # 생성된 키 파일을 반드시 안전한 위치에 복사
    cp ~/.config/proxmox-backup/encryption-keys/default /path/to/safe/backup/

    문제 2: 네트워크 속도와 백업 시간

    처음엔 PBS를 기가비트 스위치에서 다른 VLAN에 뒀더니 실효 백업 속도가 너무 느렸어요. 큰 VM 하나 백업하는 데 몇 시간씩 걸리더라고요. 근데 여기서 중요한 포인트! 증분 백업이 자리를 잡으면 첫 백업 이후에는 훨씬 빠릅니다. 실제로 안정화된 이후에는 변경량이 적은 VM은 1~2분 안에 백업이 끝나더라고요.

    문제 3: 디스크 용량 계획

    중복 제거 효과를 너무 믿고 작은 디스크를 썼다가 6개월쯤에 용량 부족 경보가 떴습니다. 중복 제거 비율은 VM 구성에 따라 편차가 크거든요. 보수적으로 예상 데이터량의 1.5~2배 정도는 확보해두시길 추천드립니다.

    데이터 보호 전략이 어떻게 바뀌었나

    PBS 도입 전후로 제 홈랩 백업 전략이 확 달라졌어요. 비교해보면 이렇습니다.

    항목 PBS 도입 전 PBS 도입 후
    백업 방식 PVE 로컬 스냅샷 PBS 증분 백업 + 로컬 스냅샷 병행
    보관 정책 최신 1~2개 일간 7개, 주간 4개, 월간 3개
    복구 검증 안 함 (😅) 분기별 복구 테스트 + 주간 Verify Job
    저장 효율 용량 그대로 중복 제거로 실효 70~80% 절약
    암호화 없음 클라이언트 사이드 암호화 적용
    모니터링 수동 확인 이메일 알림 + 작업 로그 자동화

    가장 큰 변화는 “백업했다”에서 “백업이 됐는지 확인한다”로 마인드가 바뀐 것이에요. PBS의 Verify Job과 정기 복구 테스트가 이 습관을 만들어줬습니다. 이전엔 솔직히 복구 테스트 같은 건 귀찮아서 안 했거든요 ㅎㅎ.

    PBS 도입 전후 홈랩 데이터 보호 전략 비교 인포그래픽

    ▲ PBS 도입 전후 데이터 보호 전략 비교. 단순 스냅샷에서 체계적인 3-2-1 백업 전략으로 발전했습니다.

    ✅ 1년 후 실제 결과 및 검증

    가장 의미 있는 건 실제로 복구를 써봤다는 거예요. 테스트가 아니라 진짜로요. 개발 VM 하나에서 잘못된 설정 변경으로 서비스가 망가진 적이 있었는데, PBS에서 3일 전 백업으로 10분 만에 복구했습니다. 이때 진짜 PBS 도입한 보람을 느꼈어요.

    1년간 운영하면서 체감한 PBS 장점을 정리하면:

    • ✅ 중복 제거 + 압축으로 실제 저장 공간 대폭 절약 (환경마다 다르지만 체감 효과 있음)
    • ✅ 증분 백업 안정화 이후 백업 속도 매우 빠름
    • ✅ PVE 네이티브 연동으로 별도 에이전트 없이 바로 사용
    • ✅ 웹 UI가 직관적이어서 CLI 없이도 대부분 관리 가능
    • ✅ 3-2-1 백업 전략 구현에 딱 맞는 구조

    아쉬운 점도 있습니다:

    • ⚠️ Proxmox VE 환경에 최적화되어 있어서, 다른 하이퍼바이저 백업은 한계 있음
    • ⚠️ 별도 하드웨어(또는 VM)가 필요해서 소규모 홈랩엔 진입 장벽이 약간 있음
    • ⚠️ GC, Verify, Prune 등 개념을 어느 정도 이해해야 제대로 운영 가능
    PBS 백업 통계 대시보드 - 중복 제거 효율 및 저장 공간 절약 현황 시각화

    ▲ PBS 대시보드에서 확인할 수 있는 백업 현황 및 중복 제거 효율. 안정적인 백업 운영이 수치로 확인됩니다.

    자주 묻는 질문 (FAQ)

    PBS는 별도 서버가 꼭 필요한가요?

    공식적으로는 PVE와 분리된 환경을 권장합니다. 실제로 PVE VM 안에 PBS를 설치해서 쓰는 분들도 있긴 한데, PVE 호스트에 문제가 생기면 백업 서버도 같이 영향받을 수 있어서 별도 물리 장비나 독립 시스템 사용을 추천드려요.

    홈랩 규모에서 PBS가 과한 선택 아닌가요?

    저도 처음엔 그렇게 생각했어요. 근데 막상 써보니 홈랩 규모에서도 충분히 가치가 있더라고요. 특히 여러 VM/CT를 운영한다면 중복 제거 효과와 자동화 스케줄링이 큰 도움이 됩니다.

    오프사이트 백업은 어떻게 하시나요?

    현재는 PBS 원격 동기화(Remote Sync) 기능을 활용해서 별도 위치의 PBS로 복제하는 방식을 테스트 중입니다. 이 부분은 다음 글에서 자세히 다룰 예정이에요.

    마무리: 데이터는 잃고 나서 후회합니다

    1년간 Proxmox Backup Server를 운영하면서 배운 가장 큰 교훈은, 백업은 “있다”가 아니라 “복구된다”가 기준이라는 점이에요. PBS가 완벽한 솔루션은 아니지만, Proxmox 환경에서 홈랩 백업을 제대로 구축하고 싶다면 진지하게 고려할 만합니다.

    처음 도입이 어렵게 느껴지실 수 있는데, 기본 설정만 잡아두면 나머지는 정말 편하게 돌아가거든요. 혹시 이 글 읽고 PBS 도입을 고민 중이시라면, 제 경험이 조금이라도 도움이 됐으면 합니다.

    다음 글에서는 PBS의 원격 동기화(Remote Sync)와 테이프 백업 설정을 다뤄볼 예정이에요. 진정한 3-2-1 백업 전략을 홈랩에서 구현하는 방법, 기대해주세요. 이전 글에서 다룬 Proxmox VE 초기 설정도 참고하시면 전체 그림이 잡힐 거예요.

    궁금한 점이나 삽질 경험이 있으신 분들은 댓글로 공유해주세요. 같이 고민해봐요! 🎉

  • [Proxmox] Proxmox GPU 패스스루: Error 43·IOMMU 문제 완벽 해결 가이드

    [Proxmox] Proxmox GPU 패스스루: Error 43·IOMMU 문제 완벽 해결 가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 홈랩(Homelab)에서 Proxmox VE를 운영하면서 정말 많은 분들이 도전하고 그만큼 많은 삽질을 하는 주제, 바로 Proxmox GPU 패스스루(Passthrough)와 GPU 가상화에 대해 이야기해보려고 합니다. 저도 처음에는 ‘이거 뭐 별거 있겠어?’ 하고 덤볐다가, 밤새도록 머리 싸매고 고민했던 경험이 한두 번이 아니거든요. 특히 Error 43이나 IOMMU 관련 문제들은 정말이지… 멘탈을 흔들리게 하죠. 😅

    하지만 결국 해결하고 나면, 가상머신(Virtual Machine, VM)에서 직접 게임을 돌리거나, AI/ML(머신러닝) 작업을 하거나, 고화질 미디어 서버를 구축하는 등 무궁무진한 가능성이 열리게 됩니다. 제가 직접 부딪히고 해결했던 경험들을 바탕으로, 여러분들이 겪을 수 있는 흔한 문제들과 그 해결 전략을 자세히 알려드릴게요. 멘토처럼 든든하게 옆에서 알려드리는 마음으로 시작해볼까요?

    Proxmox GPU 패스스루의 전체적인 구조를 한눈에 볼 수 있는 다이어그램입니다. 호스트 서버의 물리 GPU가 가상머신으로 직접 연결되는 방식이죠.

    Proxmox GPU 패스스루, vGPU, 그리고 IOMMU 개념 이해하기

    본격적인 설정에 들어가기 전에, 몇 가지 핵심 개념을 확실히 짚고 넘어가야 합니다. 이게 헷갈리면 나중에 삽질의 깊이가 더 깊어지거든요. 제가 처음 그랬습니다. ㅎㅎ

    GPU 패스스루 (GPU Passthrough)

    • 무엇인가요? 쉽게 말해, Proxmox 호스트 서버에 꽂혀 있는 물리적인 GPU(그래픽 카드)를 특정 가상머신이 단독으로 사용할 수 있도록 넘겨주는 기술입니다. 마치 그 VM에 GPU가 직접 꽂혀 있는 것처럼 만들어주는 거죠.
    • 왜 필요한가요? 게임, 영상 편집, 딥러닝(Deep Learning) 학습 등 높은 그래픽 성능이나 GPU 병렬 연산 능력이 필요한 작업들을 가상머신 환경에서 효율적으로 처리하려면 필요해요. 일반적인 가상화 환경에서는 GPU 자원을 공유하기 때문에 제 성능을 내기 어렵거든요.

    vGPU (Virtual GPU)

    • 무엇인가요? GPU 패스스루가 하나의 GPU를 하나의 VM에 통째로 넘겨주는 방식이라면, vGPU는 하나의 물리 GPU를 여러 가상머신이 나눠서 사용할 수 있도록 하는 기술입니다.
    • 홈랩에선 어떤가요? 사실 vGPU는 NVIDIA GRID 같은 특정 엔터프라이즈용 GPU와 드라이버, 라이선스 정책이 필요해서 홈랩 환경에서 쉽게 구현하기는 어렵더라고요. 저도 여러 번 시도해봤지만, 비용과 복잡성 때문에 결국 패스스루에 집중하게 되었어요. 혹시 나중에 더 발전된 오픈소스 vGPU 솔루션이 나온다면 꼭 다뤄보고 싶네요!

    IOMMU (Input/Output Memory Management Unit)

    • 무엇인가요? IOMMU는 CPU와 PCIe 장치(GPU 포함) 사이의 메모리 접근을 관리하는 장치예요. 쉽게 말해, 가상머신이 물리 장치에 직접 접근할 수 있도록 메모리 주소를 매핑(Mapping)해주는 역할을 하죠.
    • 왜 중요한가요? GPU 패스스루를 위해서는 IOMMU가 필수적으로 활성화되어야 해요. 그래야 Proxmox 호스트가 GPU를 VM에 안전하고 효율적으로 넘겨줄 수 있거든요. 이게 비활성화되어 있으면 아무리 다른 설정을 잘해도 패스스루는 불가능합니다. 저도 처음에 BIOS에서 이걸 빼먹어서 몇 시간을 날렸던 기억이 생생하네요 😭.

    Error 43

    • 무엇인가요? Windows 가상머신에 NVIDIA 또는 AMD 그래픽 드라이버를 설치했을 때, 장치 관리자에서 ‘이 장치에 대한 드라이버를 로드할 수 없습니다. (코드 43)’이라는 메시지가 뜨는 현상이에요.
    • 왜 발생하나요? 대부분의 GPU 드라이버는 가상머신 환경에서 설치되는 것을 막기 위한 보호 장치를 가지고 있어요. VM 환경임을 감지하면 드라이버가 제대로 동작하지 않도록 하는 거죠. 이걸 우회하는 방법을 찾아야 합니다.

    Proxmox GPU 패스스루 실전 구현: 단계별 설정

    자, 이제 개념을 알았으니 직접 Proxmox에 GPU 패스스루를 설정해보겠습니다. 제가 겪었던 시행착오들을 줄여드리기 위해 핵심만 콕콕 짚어드릴게요.

    1. BIOS/UEFI 설정 변경

    가장 기본 중의 기본입니다. 메인보드 BIOS/UEFI 설정으로 들어가서 아래 항목들을 활성화해야 합니다.

    • Intel VT-d (Intel CPU 사용자) 또는 AMD-V (AMD CPU 사용자): 가상화 기술 및 IOMMU를 활성화하는 옵션이에요.
    • SR-IOV (Supported if available): PCIe 장치 가상화 기술인데, GPU 패스스루에 직접적인 필수 요소는 아니지만 활성화해두면 좋아요.
    • Above 4G Decoding: 일부 메인보드에서 GPU 메모리 주소 할당을 위해 필요합니다. GPU 패스스루 시 안정성을 높여줄 수 있어요.
    • CSM (Compatibility Support Module) 비활성화: UEFI 부팅 환경을 제대로 활용하기 위함입니다.

    설정을 변경한 후에는 반드시 저장하고 재부팅해주세요.

    2. Proxmox VE 호스트 설정

    이제 Proxmox 쉘에 접속하여 필요한 모듈을 로드하고 GRUB 설정을 변경해야 합니다.

    2.1. 필수 모듈 로드

    IOMMU와 VFIO(Virtual Function I/O) 관련 모듈을 로드해야 해요. /etc/modules 파일을 열어 아래 내용을 추가합니다.

    echo "vfio" >> /etc/modules
    echo "vfio_iommu_type1" >> /etc/modules
    echo "vfio_pci" >> /etc/modules
    echo "vfio_virqfd" >> /etc/modules
    
    # 변경사항 적용을 위해 모듈 로드 (재부팅해도 유지됨)
    update-initramfs -u -k all
    

    이후 reboot 명령으로 재부팅하는 것을 추천합니다.

    2.2. GRUB 설정 변경 (IOMMU 활성화 및 GPU 블랙리스트)

    GRUB 부트로더 설정을 통해 IOMMU를 활성화하고, Proxmox 호스트가 패스스루할 GPU를 사용하지 못하도록 블랙리스트에 추가해야 해요.

    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"

    여기에 GPU 블랙리스트 설정을 추가합니다. 먼저 패스스루할 GPU의 벤더 ID와 장치 ID를 확인해야 해요. 쉘에서 다음 명령어를 실행합니다.

    lspci -nn | grep -i vga
    

    출력 결과는 보통 이런 식일 겁니다:

    01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
    01:00.1 Audio device [0403]: NVIDIA Corporation GP107 High Definition Audio Controller [10de:0fb9] (rev a1)
    

    여기서 [10de:1c82]와 [10de:0fb9]가 각각 GPU 비디오 장치와 오디오 장치의 벤더 ID:장치 ID예요. 이 값들을 콤마(,)로 구분하여 GRUB 설정에 추가합니다.

    # Intel CPU 예시 (GTX 1050 Ti 기준)
    GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt video=efifb:off,vesafb:off disable_vga=1 vfio_pci.ids=10de:1c82,10de:0fb9"
    

    ⚠️ 중요: video=efifb:off,vesafb:off disable_vga=1 옵션은 Proxmox 호스트가 해당 GPU를 초기화하지 않도록 하여 패스스루 시 발생할 수 있는 충돌을 방지해요. 이 옵션 없이는 Error 43이 발생할 확률이 매우 높아집니다.

    GRUB 설정을 변경했으면, 반드시 업데이트하고 initramfs를 다시 생성해야 합니다.

    update-grub
    update-initramfs -u -k all
    reboot
    
    Proxmox VM 설정에서 PCIe 장치 추가 화면

    Proxmox 웹 UI에서 가상머신에 GPU 장치를 추가하는 모습입니다. 올바르게 설정되었다면 목록에 GPU가 보일 거예요.

    3. 가상머신 (VM) 설정

    Proxmox 호스트 설정이 끝났으니, 이제 GPU를 사용할 가상머신을 설정할 차례예요.

    3.1. VM 생성 시 주의사항

    • OS Type: Windows 사용 시 ‘Microsoft Windows’ 선택.
    • BIOS: ‘OVMF (UEFI)’를 선택해야 해요. 레거시 BIOS는 패스스루 시 문제가 많더라고요.
    • Machine: ‘q35’를 선택하는 게 좋아요. PCIe 장치 관리에 더 최적화되어 있거든요.
    • CPU: ‘Host’로 설정하여 호스트 CPU의 모든 기능을 VM에서 활용할 수 있도록 합니다.
    • Disk: SATA 또는 SCSI(VirtIO)를 사용하되, SCSI VirtIO를 추천합니다. 성능이 더 좋아요.

    3.2. GPU 장치 추가

    VM 생성 후, VM의 ‘Hardware’ 탭으로 이동하여 ‘Add’ -> ‘PCI Device’를 선택합니다.

    • PCIe Device: 패스스루할 GPU의 비디오 장치와 오디오 장치를 각각 추가해요.
    • All Functions: 활성화합니다.
    • Primary GPU: 패스스루할 GPU를 VM의 주 GPU로 설정하려면 활성화합니다.
    • ROM-Bar: 활성화하는 것을 추천해요. 특히 구형 GPU에서 문제가 생길 때 해결책이 될 수 있거든요.

    3.3. QEMU/KVM 추가 설정 (중요!)

    이제 Error 43을 피하기 위한 핵심 설정입니다. Proxmox 웹 UI에서는 설정할 수 없는 고급 옵션이므로, Proxmox 쉘에서 qm set 명령어를 사용해야 해요.

    # VM ID는 여러분의 VM ID로 변경해주세요 (예: 100)
    # 'kvm=off,hv_vendor_id=null' 옵션으로 VM 환경 감지 우회
    qm set <VM_ID> -args '-cpu host,kvm=off,hv_vendor_id=null'
    # VM ID 100번에 대한 예시
    qm set 100 -args '-cpu host,kvm=off,hv_vendor_id=null'
    

    또는 VM 설정 파일 (/etc/pve/qemu-server/<VM_ID>.conf)을 직접 수정하여 args: 라인을 추가할 수도 있어요.

    # /etc/pve/qemu-server/100.conf 예시
    args: -cpu host,kvm=off,hv_vendor_id=null
    

    이 설정은 QEMU/KVM이 가상화 환경임을 숨기도록 도와주며, NVIDIA나 AMD 드라이버가 VM 환경을 감지하지 못하게 해요. 저도 이 설정 하나로 몇 번의 Error 43을 해결했었습니다. 💡

    ⚠️ 흔한 문제와 해결 전략 (삽질 경험 공유)

    제가 Proxmox GPU 패스스루를 하면서 가장 많이 겪었던 문제들과 그 해결 전략을 솔직하게 공유합니다. 여러분은 저처럼 삽질하지 마세요!

    1. IOMMU 그룹 문제 (가장 흔하고 골치 아픈 문제)

    문제: IOMMU가 활성화되었는데도 GPU가 VM에 제대로 패스스루되지 않거나, VM이 부팅되지 않는 경우가 있어요. lspci -nnk 명령으로 보면 분명 VFIO 드라이버가 붙어있는데 말이죠.

    원인: 이는 대부분 IOMMU 그룹 문제 때문입니다. IOMMU는 장치들을 ‘그룹’으로 묶어서 관리하는데, 만약 GPU와 다른 중요 장치(예: USB 컨트롤러, PCIe 브리지)가 같은 그룹에 묶여 있다면, GPU만 개별적으로 패스스루하기 어렵더라고요. IOMMU는 그룹 단위로 장치를 격리하려 하기 때문이죠.

    확인 방법: 다음 명령어로 현재 시스템의 IOMMU 그룹을 확인해볼 수 있어요.

    for iommu_group in $(find /sys/kernel/iommu_groups/ -maxdepth 1 -mindepth 1 -type d); do echo "IOMMU Group $(basename "$iommu_group")"; for device in $(ls -v "$iommu_group"/devices/); do echo -n $'\t'; lspci -nns "$device"; done; done
    

    이 결과를 보고 GPU와 그에 딸린 오디오 장치만 하나의 그룹에 묶여 있고, 다른 장치들과는 분리되어 있는지 확인해야 해요. 만약 GPU와 다른 장치들이 같은 그룹에 묶여 있다면… 아, 골치 아파지는 거죠.

    해결 전략:

    • 다른 PCIe 슬롯 사용: 메인보드마다 PCIe 슬롯의 IOMMU 그룹 분리 방식이 달라요. GPU를 다른 PCIe 슬롯에 꽂아보세요. 의외로 간단하게 해결되는 경우가 많습니다.
    • BIOS/UEFI 설정 재확인: ‘Above 4G Decoding’이나 ‘PCIe ARI Support’ 같은 옵션들이 IOMMU 그룹화에 영향을 줄 수 있어요. 활성화/비활성화해보면서 테스트해볼 필요가 있습니다.
    • 듀얼 GPU 사용: 만약 내장 그래픽(iGPU)이 있거나 다른 저렴한 그래픽 카드가 있다면, 호스트 Proxmox는 그 GPU를 사용하고, 패스스루할 GPU는 완전히 VM에 전용으로 넘겨주는 방식이 가장 확실해요. 이렇게 하면 IOMMU 그룹 문제가 발생할 확률이 현저히 줄어들어요. 저도 결국 이렇게 구성해서 안정적으로 사용하고 있습니다.
    • (고급) ACS Override Patch: 일부 커뮤니티에서는 ACS(Access Control Services) Override 패치를 커널에 적용하여 IOMMU 그룹을 강제로 분리하는 방법도 사용하지만, 이는 커널 컴파일이 필요하고 시스템 안정성에 영향을 줄 수 있어서 초보자에게는 절대 추천하지 않습니다. 잘못하면 시스템이 벽돌이 될 수 있어요.

    2. Windows VM에서 Error 43 발생

    문제: 위에서 설명한 `qm set` 명령어를 통한 `kvm=off,hv_vendor_id=null` 설정에도 불구하고 여전히 Error 43이 발생하는 경우가 있어요.

    원인: NVIDIA나 AMD 드라이버가 VM 환경을 감지하는 방식이 점점 더 교묘해지고 있어요. 또는 BIOS/UEFI 설정이 제대로 안 되어 있을 수도 있습니다.

    해결 전략:

    • BIOS/UEFI 설정 재확인: ‘Above 4G Decoding’이 활성화되어 있는지, ‘CSM’이 비활성화되어 있는지 다시 한번 확인해주세요. 이 두 가지는 Error 43과 깊은 연관이 있어요.
    • 최신 드라이버 vs. 구형 드라이버: 때로는 최신 드라이버보다 약간 구형 드라이버가 VM 환경에서 더 잘 작동하는 경우가 있어요. 특히 NVIDIA 드라이버는 특정 버전에서 VM 감지 로직이 더 강화되기도 합니다. 몇 가지 드라이버 버전을 시도해보는 것도 방법이에요.
    • Windows 업데이트 확인: Windows 업데이트가 드라이버와 충돌을 일으키는 경우도 있어요. 드라이버 설치 전 Windows를 최신 상태로 업데이트하거나, 반대로 특정 업데이트를 제거해보는 것도 시도해볼 수 있습니다.

    3. VM 부팅 시 화면 출력 안 됨

    문제: VM은 시작되는데 모니터에 아무것도 출력되지 않거나, Proxmox 웹 UI의 콘솔 화면만 보이고 GPU 출력은 나오지 않는 경우가 있어요.

    원인: GPU 초기화 문제, 또는 VM의 메인 디스플레이 설정 문제입니다.

    해결 전략:

    • BIOS/UEFI의 Primary Graphics Adapter 설정: 메인보드 BIOS에서 Primary Graphics Adapter(주 그래픽 어댑터) 설정을 ‘PCIe’ 또는 ‘Discrete Graphics’로 변경해보세요.
    • Proxmox GRUB 설정 재확인: video=efifb:off,vesafb:off disable_vga=1 옵션이 제대로 적용되었는지 확인해요. 이 옵션이 없으면 Proxmox 호스트가 GPU를 먼저 잡아버려서 VM이 사용할 수 없게 되는 경우가 많더라고요.
    • VM에 가상 디스플레이 제거: VM의 ‘Hardware’ 탭에서 ‘Display’ 장치를 ‘none’으로 설정해보세요. GPU 패스스루 시에는 가상 디스플레이가 필요 없으며, 오히려 충돌을 일으킬 수 있거든요.

    ✅ 검증 및 결과 확인

    모든 설정을 마치고 VM을 부팅했다면, 이제 드디어 결과물을 확인할 차례예요! 이 순간이 제일 두근거리고, 성공하면 희열이 엄청나죠. 🎉

    1. Windows 장치 관리자 확인

    Windows VM에 접속하여 ‘장치 관리자(Device Manager)’를 열어보세요. ‘디스플레이 어댑터(Display Adapters)’ 항목 아래에 패스스루한 GPU가 정상적으로 인식되고, 경고 표시(느낌표) 없이 드라이버가 설치되어 있다면 성공이에요!

    만약 아직도 Error 43이 보인다면, 위에 제시된 트러블슈팅 방법을 다시 한번 꼼꼼히 확인하고 재부팅을 반복해보세요. 때로는 인내심이 필요해요. 끈기가 정답이더라고요.

    2. GPU-Z 또는 FurMark로 테스트

    GPU-Z 같은 유틸리티를 설치해서 GPU 정보가 정확하게 표시되는지 확인하고, FurMark 같은 벤치마크 툴로 간단한 스트레스 테스트를 진행해보세요. 이때 GPU 온도가 정상적으로 표시되고, 프레임이 잘 나온다면 완벽하게 패스스루가 된 거예요. 저는 이때마다 ‘드디어 됐다!’ 하고 외치곤 합니다. 😂

    Windows VM에서 GPU-Z를 통한 Proxmox GPU 패스스루 확인

    Windows VM 안에서 GPU-Z를 실행한 모습입니다. 물리 GPU 정보가 그대로 잘 보이죠? 이 화면을 보면 얼마나 뿌듯한지 몰라요!

    마무리하며: 삽질 끝의 뿌듯함, 그리고 다음 단계

    Proxmox GPU 패스스루, 결코 쉽지 않은 여정입니다. 특히 IOMMU 그룹 문제나 Error 43 같은 예상치 못한 복병들을 만나면 ‘이거 그냥 포기할까?’ 하는 생각도 들죠. 저도 수도 없이 그런 생각을 했었어요. 하지만 포기하지 않고 끈기 있게 해결해나가다 보면, 결국 원하는 결과를 얻게 되고 그 과정에서 정말 많은 것을 배우게 됩니다.

    이렇게 GPU 패스스루를 성공하고 나면, 여러분의 Proxmox 홈랩은 한 단계 더 강력해질 거예요. 고성능 게이밍 머신, AI 개발 환경, 또는 고화질 트랜스코딩이 가능한 미디어 서버 등 게임부터 AI 개발까지 뭐든 가능해지는 기반이 마련되는 거죠.

    다음번에는 이렇게 구축된 강력한 VM 환경을 활용하여 Docker 컨테이너 환경을 효율적으로 관리하는 방법이나, ZFS 또는 Ceph를 이용한 스토리지 구성에 대해 다뤄볼 수도 있겠네요. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요! 제 삽질 경험이 여러분의 시간을 아껴주기를 바라며, 오늘의 이야기는 여기서 마치겠습니다. 긴 글 읽어주셔서 감사합니다!

    Proxmox GPU 패스스루 성공과 실패 시나리오 비교 인포그래픽

    Proxmox GPU 패스스루의 성공과 실패 시나리오를 한눈에 비교해주는 인포그래픽입니다. 성공했을 때의 짜릿함과 실패했을 때의 좌절감이 느껴지시나요?

  • [Proxmox] Ansible로 Proxmox 환경 1년 자동화 회고: 효율과 함정

    [Proxmox] Ansible로 Proxmox 환경 1년 자동화 회고: 효율과 함정

    Ansible로 Proxmox 환경 1년 자동화 회고: 효율과 함정

    안녕하세요, 13년차 서버실 지킴이입니다. 인프라 엔지니어로 일하다 보면 반복적인 작업에 지칠 때가 많죠. 특히 홈랩(Homelab)을 운영하는 저 같은 경우는 작은 규모라도 손이 많이 가는 일들이 부지기수입니다. 새로운 가상 머신(Virtual Machine, VM)을 만들고, 네트워크를 설정하고, 백업을 돌리는 일들은 매번 마우스 클릭과 타이핑의 연속이었거든요. ‘이걸 좀 더 효율적으로 할 수 없을까?’ 하는 고민은 늘 저를 따라다녔습니다. 그러다 1년 전, 제 Proxmox(프록스목스) 환경에 Ansible(앤서블)을 도입하기로 결심했고, 지금까지 정말 많은 것을 배우고 경험했습니다.

    오늘은 제가 지난 1년간 Ansible Proxmox 자동화를 구축하고 운영하면서 느꼈던 효율성과, 예상치 못했던 함정들, 그리고 그 해결 과정까지 솔직하게 풀어보려고 합니다. 혹시 저처럼 수동 작업의 굴레에서 벗어나고 싶은 인프라 엔지니어 분들이 계시다면, 이 글이 작은 힌트가 되기를 바랍니다.

    Ansible과 Proxmox를 활용한 홈랩 자동화 아키텍처 다이어그램

    Proxmox와 Ansible이 어떻게 연동되어 홈랩 인프라를 자동화하는지 보여주는 추상적인 아키텍처 다이어그램입니다. Ansible 컨트롤러가 SSH를 통해 Proxmox 노드와 통신하며, Proxmox API를 활용하여 VM, LXC 컨테이너, 스토리지, 네트워크 등의 리소스를 관리하는 모습을 나타냅니다.

    Ansible과 Proxmox, 왜 찰떡궁합일까요?

    먼저, 두 기술의 핵심 개념을 짧게 짚고 넘어가죠.

    • Ansible (앤서블): 에이전트리스(Agentless) 방식의 IT 자동화 도구입니다. 관리 대상 서버에 별도의 에이전트(Agent)를 설치할 필요 없이 SSH(Secure Shell) 연결을 통해 명령을 실행하고 작업을 수행하더라고요. YAML(야믈) 기반의 플레이북(Playbook)으로 인프라의 상태를 코드화(Infrastructure as Code, IaC)할 수 있다는 게 가장 큰 장점입니다.
    • Proxmox VE (프록스목스 가상 환경): 오픈소스 기반의 강력한 가상화 플랫폼입니다. 리눅스 컨테이너(LXC)와 KVM(Kernel-based Virtual Machine) 기반의 가상 머신을 모두 지원하며, 웹 기반 UI를 통해 쉽게 관리할 수 있죠. 엔터프라이즈급 기능을 홈랩에서도 무료로 활용할 수 있다는 점에서 인기가 많습니다.

    Ansible은 Proxmox가 제공하는 풍부한 API(Application Programming Interface)를 활용해 VM 생성, 네트워크 설정, 스냅샷 관리 등 거의 모든 작업을 자동화할 수 있더라고요. Ansible Proxmox 모듈 덕분에 복잡한 API 호출 없이도 YAML 플레이북으로 직관적인 작업이 가능합니다. 말 그대로 인프라를 코드로 관리하는 거죠.

    1년 간의 Ansible Proxmox 자동화, 실전 구현 경험

    처음엔 저도 ‘이게 진짜 될까?’ 싶었거든요. 그런데 막상 해보니 생각보다 강력하더라고요. 기본적인 VM 생성부터 복잡한 네트워크 설정, 백업 관리까지 Ansible 플레이북 하나로 뚝딱 해결되는 걸 보고 감탄했습니다.

    기본적인 VM 생성 플레이북

    가장 많이 사용하는 작업이죠. 새로운 VM을 만들고, OS 이미지를 마운트하고, 기본적인 리소스(CPU, RAM, 디스크)를 할당하는 플레이북입니다. 저는 주로 community.general.proxmox 컬렉션의 모듈들을 활용했습니다.

    # vm_create.yml
    ---
    - name: Proxmox에 새로운 VM 생성 및 설정
      hosts: proxmox_host
      gather_facts: no
      vars:
        vm_id: 101
        vm_name: my-test-vm
        vm_memory: 2048 # MB
        vm_cores: 2
        vm_disk_size: 30 # GB
        vm_iso: local:iso/ubuntu-22.04-live-server-amd64.iso # Proxmox ISO 스토리지 경로
        vm_bridge: vmbr0
        vm_ip: 192.168.1.101/24
        vm_gw: 192.168.1.1
        vm_dns: 8.8.8.8
    
      tasks:
        - name: VM 생성
          community.general.proxmox_kvm:
            api_host: "{{ inventory_hostname }}"
            api_user: root@pam
            api_password: "{{ proxmox_root_password }}" # ansible vault로 관리
            vmid: "{{ vm_id }}"
            name: "{{ vm_name }}"
            memory: "{{ vm_memory }}"
            cores: "{{ vm_cores }}"
            scsihw: virtio-scsi-pci
            bootdisk: scsi0
            iso: "{{ vm_iso }}"
            net:
              - name: net0
                model: virtio
                bridge: "{{ vm_bridge }}"
            state: present
          register: create_vm_result
    
        - name: 디스크 추가 (VM 생성 시 디스크 옵션이 없는 경우)
          community.general.proxmox_disk:
            api_host: "{{ inventory_hostname }}"
            api_user: root@pam
            api_password: "{{ proxmox_root_password }}"
            vmid: "{{ vm_id }}"
            disk: scsi0
            size: "{{ vm_disk_size }}G"
            storage: local-lvm # Proxmox 스토리지 이름
            format: qcow2
            state: present
          when: create_vm_result.changed # VM이 새로 생성되었을 때만 디스크 추가
    
        - name: VM 부팅
          community.general.proxmox_kvm:
            api_host: "{{ inventory_hostname }}"
            api_user: root@pam
            api_password: "{{ proxmox_root_password }}"
            vmid: "{{ vm_id }}"
            state: started
          when: create_vm_result.changed

    위 플레이북은 특정 Proxmox 호스트(proxmox_host)에 새로운 VM을 만들고 시작하는 예시입니다. proxmox_root_password 같은 민감 정보는 나중에 설명할 Ansible Vault(볼트)로 암호화해서 관리하는 게 좋습니다. 그리고 VM 생성 시 디스크 옵션을 한 번에 주기 어려운 모듈 버전도 있어서, 저는 디스크 추가 태스크를 따로 분리하기도 했어요.

    네트워크 설정 자동화 (Bridge, VLAN)

    Proxmox 노드의 네트워크 인터페이스 설정도 Ansible로 자동화하더라고요. 특히 브릿지(Bridge)나 VLAN(Virtual Local Area Network) 태그를 적용할 때 정말 유용했습니다.

    # network_config.yml
    ---
    - name: Proxmox 노드 네트워크 설정
      hosts: proxmox_host
      become: yes
      tasks:
        - name: 네트워크 인터페이스 백업
          ansible.builtin.copy:
            src: /etc/network/interfaces
            dest: /etc/network/interfaces.bak_{{ ansible_date_time.iso8601_basic_short }}
            remote_src: yes
    
        - name: 새로운 네트워크 설정 적용
          ansible.builtin.template:
            src: interfaces.j2
            dest: /etc/network/interfaces
            owner: root
            group: root
            mode: '0644'
          notify: 네트워크 서비스 재시작
    
      handlers:
        - name: 네트워크 서비스 재시작
          ansible.builtin.systemd:
            name: networking
            state: restarted
    # templates/interfaces.j2
    # /etc/network/interfaces - Proxmox Host Network Configuration
    
    auto lo
    iface lo inet loopback
    
    auto vmbr0
    iface vmbr0 inet static
      address {{ vmbr0_ip }}
      netmask {{ vmbr0_netmask }}
      gateway {{ vmbr0_gateway }}
      bridge-ports {{ physical_nic }}
      bridge-stp off
      bridge-fd 0
    
    # VLAN 10 for Management
    auto vmbr0.10
    iface vmbr0.10 inet static
      address {{ vmbr0_10_ip }}
      netmask {{ vmbr0_10_netmask }}
      vlan-raw-device vmbr0

    template 모듈을 사용해서 Jinja2 템플릿 파일(interfaces.j2)로 Proxmox 호스트의 /etc/network/interfaces 파일을 관리했습니다. 이렇게 하면 네트워크 구성이 코드화되어 버전 관리도 쉽고, 여러 노드에 동일한 설정을 적용하기도 편리하죠. notify 핸들러를 사용해서 변경 사항 적용 후 네트워크 서비스를 자동으로 재시작하도록 했습니다.

    백업 및 스냅샷 관리

    데이터는 소중하니까요. 자동화된 백업과 스냅샷 관리는 필수입니다. 특히 홈랩에서는 실수로 날려버리는 경우가 많아서 꼭 필요하더라고요.

    # backup_snapshot.yml
    ---
    - name: Proxmox VM 백업 및 스냅샷 관리
      hosts: proxmox_host
      gather_facts: no
      vars:
        vmid_to_manage: 101
        backup_storage: backup_pool # Proxmox 백업 스토리지 이름
    
      tasks:
        - name: VM 스냅샷 생성
          community.general.proxmox_snap:
            api_host: "{{ inventory_hostname }}"
            api_user: root@pam
            api_password: "{{ proxmox_root_password }}"
            vmid: "{{ vmid_to_manage }}"
            snapname: "daily-snapshot-{{ ansible_date_time.iso8601_basic_short }}"
            description: "Daily snapshot by Ansible"
            state: present
    
        - name: VM 백업 실행 (shell 명령 사용)
          ansible.builtin.shell: |
            vzdump {{ vmid_to_manage }} \
              --storage {{ backup_storage }} \
              --compress zstd \
              --mode stop
          register: backup_result
          async: 3600
          poll: 60

    proxmox_snap 모듈로 특정 VM의 스냅샷을 생성했습니다. 백업의 경우, Proxmox 환경에 따라 직접 vzdump 유틸리티를 호출하는 방식도 많이 사용합니다. 이렇게 하면 더 세밀한 제어가 가능하더라고요. async: 3600과 poll: 60을 사용해서 백업이 완료될 때까지 Ansible이 기다려줍니다.

    Ansible 플레이북 실행 성공 결과 터미널 화면

    Ansible 플레이북이 성공적으로 실행되어 Proxmox 환경에 VM이 생성되고 네트워크 설정이 적용되는 과정을 보여주는 터미널 화면입니다. 각 태스크의 성공 여부와 변경 사항이 녹색으로 표시되어 자동화가 잘 작동하고 있음을 나타냅니다.

    ⚠️ 삽질 대잔치! Proxmox Ansible 자동화의 함정과 해결책

    자동화가 늘 쉬웠던 건 아닙니다. 저도 꽤 많은 삽질을 했거든요. 특히 Proxmox는 업데이트 주기가 빠르고, Ansible 모듈도 계속 발전하다 보니 버전 호환성이나 예상치 못한 동작으로 골머리를 앓기도 했습니다.

    모듈 버전 호환성 문제

    초기에는 community.general 컬렉션의 proxmox 모듈이 자주 업데이트되면서, 특정 옵션이 사라지거나 이름이 바뀌는 경우가 많았습니다. 제가 작성했던 플레이북이 갑자기 에러를 뿜어낼 때마다 당황했죠.

    • 해결책: `ansible-galaxy collection install community.general:==X.Y.Z` 명령으로 특정 버전의 컬렉션을 설치하고 고정했습니다. 프로덕션 환경이라면 더더욱 버전을 명확히 관리하는 것이 중요하더라고요.

    인증 방식의 복잡함

    Proxmox API에 접근하려면 인증이 필요합니다. 처음엔 root 계정의 비밀번호를 직접 플레이북에 넣었는데, 보안상 너무 위험하다는 걸 깨달았죠.

    • 해결책: Proxmox의 API 토큰(API Token) 기능을 활용했습니다. 특정 사용자에게만 권한을 부여한 API 토큰을 발급받아 사용하고, 이 토큰 정보는 Ansible Vault (앤서블 볼트)로 암호화해서 관리했습니다. ansible-vault encrypt_string 'MY_PROXMOX_API_TOKEN' --name 'proxmox_api_token' 같은 명령어로 쉽게 암호화할 수 있습니다.

    네트워크 인터페이스 이름 충돌

    VM을 생성할 때 네트워크 인터페이스를 여러 개 추가하다 보면, Proxmox 내부적으로 할당되는 인터페이스 이름(예: net0, net1) 때문에 예상치 못한 문제가 발생하기도 했습니다. 특히 net 배열 인덱스를 잘못 지정하면 원하는 브릿지에 연결이 안 되는 경우가 있었어요.

    • 해결책: 플레이북 내에서 net 옵션을 사용할 때 인덱스 순서를 명확히 하고, Proxmox 웹 UI에서 VM 생성 후 실제 할당된 인터페이스 이름과 비교하며 디버깅했습니다. 그리고 네트워크 설정 변경 후 Proxmox 호스트 재부팅이 필요한 경우도 있어서, reboot 모듈을 활용하기도 했습니다.

    비동기 작업 처리

    VM 생성이나 백업 같은 작업은 시간이 오래 걸릴 수 있습니다. Ansible은 기본적으로 동기(Synchronous) 방식으로 동작하기 때문에, Proxmox에서 작업이 완료되기 전에 Ansible 태스크가 타임아웃(Timeout)되거나 다음 태스크로 넘어가 버리는 문제가 있었습니다.

    • 해결책: async와 poll 옵션을 활용했습니다. 예를 들어, async: 300은 해당 태스크를 백그라운드에서 최대 300초(5분) 동안 실행하고, poll: 10은 10초마다 작업 완료 여부를 확인하는 방식입니다. 이렇게 하면 Ansible이 Proxmox의 비동기 작업을 기다려줍니다.
    Proxmox 웹 UI에서 Ansible로 자동화된 VM 리스트 확인

    Ansible 자동화로 생성 및 설정된 Proxmox VM들의 리스트를 Proxmox 웹 UI에서 보여주는 화면입니다. 플레이북으로 지정된 이름과 ID, 그리고 현재 상태(Running)가 명확하게 표시되어 자동화가 잘 작동하고 있음을 나타냅니다.

    🎉 1년 간의 성과와 얻은 교훈 (검증 및 결과)

    지난 1년간 Ansible과 Proxmox를 함께 사용하면서 얻은 가장 큰 성과는 역시 효율성입니다. 이제는 새로운 서버를 구축하거나 기존 서버 환경을 재구성할 때 클릭 몇 번이 아니라, 플레이북 실행 한 번으로 모든 것이 해결됩니다. 삽질도 많이 했지만, 그만큼 얻은 것도 많아요.

    압도적인 효율성 증가

    예전에는 새 VM 하나 만드는데 10분 이상 걸렸지만, 이제는 플레이북 실행부터 VM 부팅까지 2~3분이면 충분합니다. 특히 여러 대의 VM을 동시에 배포할 때는 그 효과가 정말 크더라고요. 재현 가능한(Idempotent) 인프라를 구축했다는 점도 중요합니다. 언제든 동일한 상태로 인프라를 복원하거나 재구축할 수 있거든요.

    인프라 문서화 효과

    플레이북 자체가 인프라의 현재 상태를 설명하는 가장 정확한 문서가 됩니다. 누가 봐도 이 플레이북이 어떤 VM을 어떤 설정으로 만들고 있는지 한눈에 들어오더라고요. 팀원들과의 협업이나 나중에 인프라를 다시 파악할 때 정말 큰 도움이 됩니다.

    홈랩 운영의 즐거움

    무엇보다 홈랩 운영이 훨씬 즐거워졌습니다. 새로운 기술을 실험하고 싶을 때, 클릭 몇 번으로 환경을 만들고 망가뜨려도 부담이 없거든요. 실패해도 플레이북만 다시 돌리면 그만이니까요. 이게 진짜 홈랩 자동화 경험의 핵심 아닐까요?

    Ansible Proxmox 자동화의 장점과 단점을 비교하는 표

    Ansible을 활용한 Proxmox 자동화의 주요 장점과 고려해야 할 단점을 비교하여 보여주는 표입니다. 효율성, 재현성, 문서화 등의 장점과 함께 학습 곡선, 복잡성 관리 등의 단점을 요약합니다.

    마무리하며: 다음 단계와 독자에게 전하는 말

    Ansible과 Proxmox의 조합은 저의 인프라 관리 방식을 완전히 바꿔놓았습니다. 물론 완벽하지는 않았지만, 수동 작업으로 인한 피로감을 줄이고, 더 본질적인 문제 해결에 집중할 수 있게 해주었죠. Ansible 플레이북과 Proxmox 인프라 관리에 대한 경험은 저에게 큰 자산이 되었습니다.

    혹시 아직 자동화를 시작하지 않으셨다면, 작은 부분부터라도 꼭 도전해보시길 권합니다. 처음엔 어렵게 느껴질 수 있지만, 한 번 손에 익으면 인프라 관리의 새로운 지평이 열릴 겁니다. Ansible 외에도 Terraform(테라폼) 같은 다른 IaC 도구들도 많으니, 여러분의 환경과 필요에 맞는 도구를 찾아보는 것도 좋은 방법입니다. 저는 다음 단계로 Proxmox 클러스터 관리나 더 복잡한 스토리지 연동 자동화에 도전해볼 생각입니다. 여러분의 자동화 여정도 응원할게요! 궁금한 점이나 공유하고 싶은 경험이 있다면 언제든 댓글로 남겨주세요.

  • [Proxmox] Proxmox HAOS 마이그레이션: VMware ESXi에서 안전하게 이전하기

    [Proxmox] Proxmox HAOS 마이그레이션: VMware ESXi에서 안전하게 이전하기

    홈랩 서버실 | Proxmox HAOS 마이그레이션: VMware ESXi에서 안전하게 이전하기

    안녕하세요, 13년차의 서버실입니다. 홈랩을 운영하면서 여러 하이퍼바이저(Hypervisor)를 오가다 보면, 언젠가 한 번쯤은 겪게 되는 고민이 있어요. 바로 기존 가상머신(Virtual Machine, VM)을 새로운 플랫폼으로 옮기는 마이그레이션(Migration)입니다. 특히 스마트 홈의 핵심인 Home Assistant OS(HAOS) 같은 친구들은 안정성이 중요해서 마이그레이션할 때 더욱 신중해지죠. 저도 최근에 오랫동안 잘 써오던 VMware ESXi 환경에서 Proxmox VE로 HAOS를 안전하게 이전하면서 꽤 삽질을 했거든요. 오늘은 그 경험을 바탕으로 여러분께 자세히 알려드리려고 합니다.

    혹시 여러분도 ESXi의 라이선스 정책 변화나, Proxmox VE의 유연한 기능들, 혹은 단순히 새로운 환경에 대한 호기심 때문에 마이그레이션을 고민하고 계신가요? 그렇다면 이 글이 큰 도움이 될 겁니다. 제가 직접 겪었던 시행착오와 해결 과정을 솔직하게 공유하면서, 여러분의 Proxmox HAOS 마이그레이션 여정을 조금 더 부드럽게 만들어 드릴게요. 자, 그럼 시작해 볼까요?

    VMware ESXi에서 Proxmox VE로 Home Assistant OS 마이그레이션 전체 개요

    VMware ESXi에서 Proxmox VE로 Home Assistant OS 마이그레이션 전체 개요 다이어그램입니다.

    1. 왜 VMware ESXi에서 Proxmox VE로 옮겨야 할까요?

    사실 VMware ESXi는 오랫동안 안정적인 가상화 플랫폼의 대명사였어요. 특히 엔터프라이즈 환경에서는 거의 표준이라고 할 수 있었죠. 저도 덕분에 많은 프로젝트를 ESXi 위에서 진행했었고요. 하지만 홈랩(Home Lab) 환경에서는 몇 가지 고민이 생기더라고요.

    • 라이선스 정책 변화: ESXi 무료 버전의 기능 제한이 점점 심해지고 있습니다. 특히 vSphere API 접근 제한은 백업이나 관리 자동화에 큰 걸림돌이 되죠.
    • 오픈소스의 유연성: Proxmox VE(Virtual Environment)는 완벽한 오픈소스 가상화 플랫폼입니다. KVM(Kernel-based Virtual Machine)과 LXC(Linux Containers)를 모두 지원해서 VM과 컨테이너를 한 곳에서 관리할 수 있다는 점이 정말 매력적이더라고요.
    • 커뮤니티와 학습: Proxmox는 활발한 커뮤니티와 방대한 자료 덕분에 새로운 기술을 익히고 실험하기에 좋은 환경을 제공합니다. 저처럼 이것저것 만져보는 걸 좋아하는 사람에게는 최고의 놀이터죠.

    이런 이유들로 저는 Proxmox VE로의 전환을 결심했고, 그 첫 타자로 홈랩의 심장인 Home Assistant OS를 옮겨보기로 했습니다.

    2. 개념 설명: Proxmox VE와 Home Assistant OS 간략히

    마이그레이션에 앞서, 핵심 개념들을 간단히 짚고 넘어갈까요?

    • Proxmox VE (Virtual Environment): 쉽게 말해, 서버 한 대에서 여러 개의 가상 서버를 돌릴 수 있게 해주는 운영체제라고 생각하시면 됩니다. VMware ESXi와 비슷한 역할을 하지만, 오픈소스라는 점이 가장 큰 차이점이에요. 웹 기반 인터페이스를 제공해서 관리도 편리하고요.
    • Home Assistant OS (HAOS): 스마트 홈 기기들을 한곳에 모아 관리하고 자동화할 수 있게 해주는 오픈소스 플랫폼입니다. 전용 OS 형태로 제공되어 가상머신 위에 설치하는 경우가 많죠. 저도 Z-Wave, Zigbee 동글(dongle)을 연결해서 사용하고 있습니다.
    • 마이그레이션 (Migration): 기존에 잘 돌아가던 가상머신을 다른 가상화 환경으로 옮기는 과정입니다. 단순히 파일을 복사하는 것 이상으로, 새로운 환경에 맞게 설정들을 조정해줘야 하죠.

    3. 실전 구현: VMware ESXi에서 HAOS VM 내보내기

    자, 이제 본론입니다. 제가 직접 해보니 몇 가지 포인트만 잘 지키면 생각보다 어렵지 않더라고요.

    3.1. Home Assistant OS VM 백업 및 종료

    가장 먼저 할 일은 HAOS VM을 백업하는 것입니다. 혹시 모를 상황에 대비해서 꼭 스냅샷(Snapshot)을 찍어두거나, Home Assistant 자체의 백업 기능을 활용해서 전체 백업 파일을 받아두세요. 그리고 VM을 정상적으로 종료(Shut Down)해야 합니다. 전원 끄기(Power Off) 말고, 반드시 OS 내부에서 종료 명령을 내려주세요. 데이터 무결성(Data Integrity)을 위해 아주 중요하거든요.

    3.2. OVF/OVA 형식으로 내보내기

    VMware ESXi에서 가상머신을 다른 환경으로 옮길 때 가장 일반적인 방법은 OVF(Open Virtualization Format) 또는 OVA(Open Virtual Appliance) 형식으로 내보내는 것입니다. OVA는 OVF 파일과 관련 디스크 이미지를 하나의 파일로 묶어둔 아카이브(Archive) 형태라고 보시면 돼요. 저는 OVA로 내보냈습니다.

    1. vSphere Client 또는 ESXi 웹 UI에 접속합니다.
    2. 내보낼 Home Assistant OS VM을 선택하고 마우스 오른쪽 버튼을 클릭합니다.
    3. ‘템플릿(Template)’ > ‘OVF 템플릿 내보내기(Export OVF Template…)’를 선택합니다.
    4. 저장할 위치와 파일명을 지정하고 ‘확인’을 누르면 내보내기가 시작됩니다. 시간이 좀 걸릴 수 있어요.
    VMware ESXi에서 Home Assistant OS 가상 머신을 OVF/OVA 형식으로 내보내는 과정

    VMware ESXi 웹 UI에서 Home Assistant OS 가상 머신을 OVF/OVA 형식으로 내보내는 화면입니다.

    3.3. 디스크 이미지 변환 (VMDK → QCOW2)

    Proxmox VE는 일반적으로 QCOW2나 RAW 형식의 디스크 이미지를 사용합니다. ESXi에서 내보낸 OVA 파일 안에는 VMDK 형식의 디스크 이미지가 들어있죠. 이걸 Proxmox에서 사용할 수 있는 형식으로 변환해야 합니다. 저는 Proxmox 서버에서 직접 변환하는 방법을 선택했어요. 이게 가장 빠르고 편하더라고요.

    1. 내보낸 OVA 파일을 Proxmox VE 서버의 특정 디렉토리(예: /var/lib/vz/template/iso/)로 옮깁니다. scp 명령어를 사용하면 편리합니다.
    2. Proxmox VE 서버에 SSH로 접속합니다.
    3. OVA 파일 압축을 해제합니다. OVA는 사실 .tar 아카이브 파일이에요.
    cd /var/lib/vz/template/iso/
    tar -xvf homeassistant.ova
    

    압축을 풀면 .ovf 파일과 .vmdk 파일이 보일 겁니다.

    1. qemu-img 도구를 사용하여 VMDK 파일을 QCOW2로 변환합니다.
    qemu-img convert -f vmdk homeassistant-disk1.vmdk -O qcow2 homeassistant-disk1.qcow2
    

    이 명령어가 성공적으로 실행되면, homeassistant-disk1.qcow2 파일이 생성됩니다. 이 파일이 Proxmox VE에서 사용할 디스크 이미지예요.

    4. 실전 구현: Proxmox VE로 HAOS VM 가져오기

    이제 변환된 디스크 이미지를 Proxmox VE에 VM으로 등록할 차례입니다.

    4.1. 새 가상머신 생성 (디스크 없이)

    Proxmox VE 웹 UI에서 새로운 VM을 생성합니다. 이때 ‘하드 디스크(Hard Disk)’ 단계에서는 디스크를 추가하지 않고 넘어가는 것이 중요해요. 나중에 변환한 디스크를 직접 연결할 거거든요.

    1. Proxmox VE 웹 UI에 접속합니다.
    2. 우측 상단 ‘VM 생성(Create VM)’ 버튼을 클릭합니다.
    3. ‘일반(General)’ 탭에서 이름과 VM ID를 지정합니다. (예: homeassistant-new, ID 100)
    4. ‘OS’ 탭에서 ‘미디어 사용 안 함(Do not use any media)’을 선택합니다.
    5. ‘시스템(System)’ 탭에서 기본값으로 두거나 필요한 경우 수정합니다. (저는 VMWare에서 사용하던 BIOS 대신 UEFI를 선택했어요.)
    6. ‘디스크(Disks)’ 탭에서 ‘디스크를 추가하지 않음(Do not add a disk)’을 선택하고 다음으로 넘어갑니다.
    7. ‘CPU’ 및 ‘메모리(Memory)’를 적절히 설정합니다. HAOS는 2코어, 4GB RAM 정도면 충분해요.
    8. ‘네트워크(Network)’ 탭에서 원하는 브리지(Bridge)를 선택합니다. (일반적으로 vmbr0)
    9. 마지막 ‘확인(Confirm)’ 단계에서 설정을 다시 확인하고 ‘완료(Finish)’를 클릭합니다.

    4.2. 변환된 디스크 이미지 임포트

    생성된 VM에 아까 변환했던 .qcow2 디스크 이미지를 연결합니다.

    1. Proxmox VE 서버에 SSH로 접속합니다.
    2. 다음 명령어를 사용하여 디스크 이미지를 생성한 VM (예: ID 100)으로 임포트합니다. local-lvm은 디스크 이미지를 저장할 스토리지 풀 이름입니다. 여러분의 환경에 맞게 변경해주세요.
    qm importdisk 100 /var/lib/vz/template/iso/homeassistant-disk1.qcow2 local-lvm
    

    이 명령어가 완료되면, Proxmox VE 웹 UI의 VM 하드웨어 설정에 ‘사용하지 않는 디스크(Unused Disk)’로 추가된 것을 볼 수 있어요.

    4.3. 임포트된 디스크 연결 및 부팅 순서 설정

    1. Proxmox VE 웹 UI에서 생성한 VM (ID 100)을 선택하고 ‘하드웨어(Hardware)’ 탭으로 이동합니다.
    2. ‘사용하지 않는 디스크(Unused Disk)’를 더블클릭하거나 선택 후 ‘편집(Edit)’ 버튼을 눌러 디스크를 VM에 연결합니다. ‘버스/장치(Bus/Device)’는 ‘SATA’나 ‘VirtIO Block’ 중 선택하는데, 저는 일반적으로 성능이 좋은 VirtIO Block을 선호해요. ‘캐시(Cache)’ 설정도 필요에 따라 조정해주세요.
    3. ‘옵션(Options)’ 탭으로 이동하여 ‘부팅 순서(Boot Order)’를 편집합니다. 방금 연결한 디스크를 첫 번째 부팅 장치로 설정하고 ‘확인(OK)’을 클릭합니다.
    Proxmox VE에서 새로운 가상 머신 생성 후 Home Assistant OS 디스크 이미지를 임포트하는 과정

    Proxmox VE 웹 UI에서 새로운 VM을 생성하고, SSH 터미널에서 qm importdisk 명령어를 통해 Home Assistant OS 디스크 이미지를 임포트하는 과정입니다.

    5. 주의사항 및 트러블슈팅 ⚠️ (삽질 경험 공유)

    제가 이 과정에서 겪었던 몇 가지 ‘삽질’과 그 해결 방법을 공유합니다. 여러분은 저 같은 실수를 하지 않으시길 바랍니다! ㅎㅎ

    • 네트워크 인터페이스 문제: 마이그레이션 후 HAOS가 네트워크를 잡지 못하는 경우가 있어요. ESXi와 Proxmox는 가상 네트워크 카드 드라이버가 다를 수 있거든요. HAOS는 보통 eth0을 사용하지만, Proxmox에서 VirtIO 네트워크 카드를 사용하면 이름이 바뀌거나 설정이 꼬일 수 있습니다.

      • 해결책: Proxmox VM 설정에서 네트워크 카드를 VirtIO 대신 E1000으로 변경해보세요. 또는 HAOS 콘솔에 접속해서 네트워크 설정을 수동으로 확인하고 network update 명령어를 통해 DHCP를 다시 시도해볼 수 있습니다.
    • VMware Tools 잔재: ESXi에서 설치했던 VMware Tools는 Proxmox에서는 필요 없어요. 이게 남아있으면 불필요한 리소스를 잡아먹거나 충돌을 일으킬 수도 있습니다. 사실 HAOS는 자체적으로 VM Tools 같은 걸 설치하지 않아서 크게 문제가 되지는 않지만, 다른 Linux VM을 마이그레이션할 때는 꼭 확인해주세요.

      • 해결책: 마이그레이션 전 ESXi에서 VM Tools를 제거하거나, Proxmox로 옮긴 후 해당 VM에 접속해서 제거하는 것이 좋습니다.
    • USB 패스스루(USB Passthrough): Zigbee나 Z-Wave 동글을 사용하신다면, Proxmox에서 USB 패스스루 설정을 새로 해줘야 합니다. ESXi에서 사용하던 설정이 그대로 넘어오지 않거든요.

      • 해결책: Proxmox 웹 UI에서 VM 하드웨어 설정에 들어가 ‘추가(Add)’ > ‘USB 장치(USB Device)’를 선택하고, ‘벤더/제품 ID 사용(Use vendor/product ID)’ 또는 ‘USB 포트 사용(Use USB Port)’을 통해 해당 동글을 연결해줍니다.
    • 디스크 용량 문제: HAOS VMDK 파일이 크면 변환 및 임포트 과정에서 시간이 오래 걸리고, 스토리지 용량을 충분히 확보해야 합니다. 저도 한 번은 Proxmox 서버의 /tmp 디렉토리 용량이 부족해서 변환이 실패한 적이 있었어요. 😅

      • 해결책: 변환 파일을 저장할 디렉토리에 충분한 여유 공간이 있는지 미리 확인하세요.

    6. 검증 및 결과 🎉 (드디어 새로운 둥지에서 HAOS 가 움직인다!)

    모든 설정이 끝나고 VM을 부팅하면, 이제 HAOS가 Proxmox VE 위에서 새로운 시작을 알릴 겁니다. 저는 부팅 후 다음 사항들을 꼼꼼히 확인했어요.

    1. HAOS 웹 인터페이스 접속: 가장 먼저 HAOS의 웹 UI에 접속해서 대시보드가 정상적으로 로드되는지 확인합니다.
    2. 네트워크 연결 상태: ‘설정(Settings)’ > ‘시스템(System)’ > ‘네트워크(Network)’에서 IP 주소와 게이트웨이(Gateway) 설정이 올바른지 확인합니다.
    3. 통합(Integrations) 작동 여부: 스마트 기기 연동(예: Philips Hue, SmartThings, Zigbee/Z-Wave 동글)이 제대로 작동하는지 하나씩 테스트해봅니다.
    4. 애드온(Add-ons) 상태: 설치했던 애드온들이 모두 정상적으로 실행되는지 확인해요.
    5. 리소스 사용량: Proxmox VE 웹 UI에서 VM의 CPU, 메모리, 디스크 I/O 사용량을 모니터링하여 ESXi 때와 비교해봅니다. 보통 Proxmox가 더 효율적인 경우가 많더라고요.

    이 모든 과정이 끝나고 HAOS 대시보드가 완벽하게 작동하는 것을 보니, 그동안의 삽질이 싹 잊히는 기분이었어요. 드디어 성공했구나! 하는 성취감이 밀려오더라고요. 🥳

    Proxmox VE에서 성공적으로 마이그레이션되어 작동 중인 Home Assistant OS 대시보드

    Proxmox VE 위에서 성공적으로 마이그레이션되어 작동 중인 Home Assistant OS 대시보드 화면입니다.

    7. 마무리: 배운 점과 다음 단계

    VMware ESXi에서 Proxmox VE로 Home Assistant OS를 마이그레이션하는 과정은 단순히 파일을 옮기는 것을 넘어, 새로운 가상화 환경에 대한 이해와 트러블슈팅 능력을 길러주는 좋은 경험이었습니다. 제가 얻은 몇 가지 교훈은 이렇습니다.

    • 사전 백업의 중요성: 아무리 강조해도 지나치지 않아요.
    • 문서화의 습관화: 제가 어떤 설정을 했는지, 어떤 삽질을 했는지 기록해두면 다음번에 훨씬 수월합니다.
    • 오픈소스 커뮤니티의 힘: 막히는 부분이 있을 때 Proxmox 포럼이나 Home Assistant 커뮤니티에서 많은 도움을 받을 수 있었어요.

    이제 여러분의 Home Assistant OS는 Proxmox VE라는 새로운 환경에서 더욱 안정적이고 유연하게 동작할 겁니다. 다음 단계로는 Proxmox VE의 강력한 백업 기능(Proxmox Backup Server와 연동)을 활용하여 HAOS 백업 전략을 수립하거나, VM에 GPU 패스스루를 설정하여 미디어 서버 등 다른 서비스를 구축하는 것도 좋은 아이디어가 될 수 있겠죠. 물론 이 부분은 다음 글에서 자세히 다룰 예정입니다. 😉

    오늘도 제 글이 여러분의 홈랩 운영에 작은 도움이 되었기를 바라며, 궁금한 점은 언제든 댓글로 남겨주세요! 13년차의 서버실은 언제나 여러분의 삽질을 응원합니다. 감사합니다!

  • [Proxmox] Proxmox 클러스터 1년 사용 후기: 안정성, 성능, 그리고 예상치 못한 문제들

    [Proxmox] Proxmox 클러스터 1년 사용 후기: 안정성, 성능, 그리고 예상치 못한 문제들

    Proxmox 클러스터 1년 사용 후기: 안정성, 성능, 그리고 예상치 못한 문제들

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’ 블로그 운영자입니다. 홈랩을 운영하며 쌓아온 경험을 바탕으로 오늘은 많은 분들이 관심을 가지시는 Proxmox 클러스터에 대한 솔직한 Proxmox 후기를 들려드리려고 합니다. 특히 1년이라는 시간 동안 Proxmox VE(Virtual Environment) 클러스터 환경을 직접 운영해보면서 느꼈던 점, 좋았던 점, 그리고 예상치 못했던 문제점까지 가감 없이 공유해 드릴게요. 가상화 환경 구축을 고민 중이시거나, 이미 Proxmox를 사용하고 계신 분들께 조금이나마 도움이 되기를 바랍니다.

    Proxmox 클러스터 아키텍처 개요 다이어그램

    이 가상화 클러스터는 여러 대의 Proxmox VE 서버를 하나의 논리적인 단위로 묶어 관리할 수 있게 해주는 강력한 기능입니다. 이를 통해 고가용성(High Availability)과 효율적인 자원 분배를 구현하여 서비스의 안정성과 성능을 크게 향상시킬 수 있죠. 마치 여러 대의 컴퓨터가 힘을 합쳐 하나의 거대한 컴퓨터처럼 작동하는 것과 같다고 생각하시면 이해하기 쉬우실 거예요.

    Proxmox 클러스터, 왜 선택했을까?

    제가 이 가상화 클러스터를 구축하게 된 가장 큰 이유는 바로 고가용성(High Availability, HA) 때문이었습니다. 홈랩 환경에서도 중요한 서비스들은 단일 서버 장애로 인해 중단되는 것을 원치 않았거든요. Proxmox 클러스터를 사용하면, 노드(Node, 개별 Proxmox 서버) 하나에 장애가 발생하더라도 해당 노드에서 실행 중이던 가상머신(Virtual Machine, VM)이나 컨테이너(Container, LXC)를 다른 정상 노드로 자동으로 이전(Migrate)시켜 서비스 중단을 최소화할 수 있습니다. 13년차 인프라 엔지니어로서 이런 HA 기능은 제게 있어선 선택이 아닌 필수였죠.

    또한, 여러 노드에 분산된 자원(CPU, RAM, 스토리지)을 중앙에서 통합 관리할 수 있다는 점도 매력적이었습니다. 덕분에 개별 서버의 자원 현황을 파악하고, VM을 효율적으로 배치하여 전체적인 성능을 최적화하는 데 유리했죠. 처음엔 단순히 여러 대의 서버를 묶는다고 생각했는데, 막상 사용해보니 운영의 편리성 측면에서도 큰 이점을 느낄 수 있었습니다.

    Proxmox 클러스터 구축 과정: 삽질과 극복의 기록

    Proxmox 클러스터 구축 자체는 Proxmox VE의 웹 인터페이스를 통해 비교적 쉽게 진행할 수 있었어요. 하지만 제 경험상, 완벽하게 매끄럽게만 흘러가지는 않았습니다. 특히 네트워크 설정과 스토리지 공유 설정에서 몇 가지 난관에 부딪혔었죠.

    1단계: Proxmox VE 설치 및 기본 설정

    먼저, 클러스터에 참여할 모든 서버에 Proxmox VE를 설치합니다. 저는 주로 Debian 기반으로 설치했는데, Proxmox VE ISO 이미지를 사용하면 훨씬 간편하게 설치할 수 있습니다. 설치 후에는 IP 주소, 호스트 이름(Hostname), DNS 설정 등을 기본적으로 완료해야 합니다.

    2단계: 클러스터 생성 및 노드 참여

    클러스터를 처음 생성할 노드에서 웹 인터페이스에 접속하여 Datacenter -> Cluster 메뉴로 이동합니다. 여기서 ‘Create Cluster’ 버튼을 눌러 클러스터 이름을 지정하고 생성합니다. 이후 다른 노드들을 이 클러스터에 참여시켜야 합니다. 참여시킬 노드에서 마찬가지로 웹 인터페이스에 접속하여 Datacenter -> Cluster 메뉴로 간 후, ‘Join Cluster’ 버튼을 누르고 기존 클러스터의 IP 주소와 관리자 계정 정보를 입력하면 됩니다.

    # 클러스터 생성 (첫 번째 노드에서 실행)
    pvecm create <ClusterName>
    
    # 클러스터 참여 (다른 노드에서 실행)
    pvecm add <ClusterIP>
    

    3단계: 공유 스토리지 설정 (중요!)

    고가용성(HA) 기능을 제대로 활용하기 위해서는 VM이나 컨테이너의 디스크 이미지가 모든 노드에서 접근 가능해야 합니다. 이를 위해 공유 스토리지(Shared Storage) 설정이 필수적이죠. 저는 NFS(Network File System)를 이용하여 공유 스토리지를 구성했는데요. 각 노드에서 NFS 클라이언트를 설정하고, NFS 서버에 마운트하는 방식으로 진행했습니다. 처음엔 로컬 스토리지로 VM을 생성했다가, HA 마이그레이션이 불가능하다는 것을 깨닫고 공유 스토리지 구성에 다시 시간을 투자했던 기억이 나네요. 😅

    Proxmox VE 웹 인터페이스에서 Datacenter -> Storage 메뉴로 이동하여 NFS 스토리지 설정을 추가할 수 있습니다. 여기서 NFS 서버의 IP 주소와 마운트 경로, 그리고 ‘Nodes’ 필드에 클러스터 내 모든 노드를 선택하는 것이 중요합니다. 이렇게 해야 해당 스토리지가 모든 노드에서 인식되어 VM 디스크를 저장할 수 있게 됩니다.

    4단계: HA 설정 및 VM 구성

    클러스터와 공유 스토리지 설정이 완료되었다면, 이제 HA 설정을 진행할 차례입니다. Datacenter -> HA 메뉴에서 HA 그룹을 생성하고, 해당 그룹에 속할 노드들과 VM들을 지정합니다. HA 그룹에 속한 VM은 지정된 노드 중 하나에 장애가 발생하면 자동으로 다른 노드에서 재시작(Restart)되거나 이전(Migrate)됩니다. VM 생성 시 ‘High Availability’ 옵션을 활성화하는 것을 잊지 마세요.

    💡 팁: HA 설정을 할 때, VM의 우선순위(Priority)를 설정하여 어떤 VM을 먼저 HA 대상으로 할지 결정할 수 있습니다. 중요한 서비스 VM에는 높은 우선순위를 부여하는 것이 좋습니다.

    1년간 Proxmox 클러스터를 사용하며 느낀 장점

    1년 동안 Proxmox 클러스터를 운영하면서 여러 가지 장점을 체감했죠. 역시 가장 큰 장점은 앞서 언급한 고가용성(HA)과 중앙 집중식 관리입니다.

    • ✅ 안정적인 서비스 운영: 노드 장애 발생 시에도 서비스 중단을 최소화할 수 있어 안심하고 운영할 수 있었어요. 실제로 한 번 노드에 문제가 발생했을 때, HA 기능 덕분에 다른 노드에서 VM이 자동으로 재시작되어 서비스 영향이 거의 없었고요.
    • ✅ 효율적인 자원 관리: 여러 노드의 CPU, RAM, 스토리지 자원을 한눈에 파악하고 관리할 수 있어 효율적인 자원 배분이 가능했습니다.
    • ✅ 간편한 마이그레이션: 유지보수나 업그레이드를 위해 특정 노드의 VM을 다른 노드로 이전(Live Migration)하는 작업이 매우 간편했습니다. 서비스 중단 없이 VM을 안전하게 이동시킬 수 있다는 점이 인상 깊었습니다.
    • ✅ 강력한 기능과 유연성: Proxmox VE 자체의 강력한 기능(스냅샷, 백업, 복제 등)과 클러스터링 기능이 결합되어 매우 유연하고 강력한 가상화 환경을 구축할 수 있었습니다.

    예상치 못한 문제들과 트러블슈팅 경험

    모든 기술이 그렇듯, 이 클러스터 환경 역시 완벽하지만은 않더라고요. 1년이라는 시간 동안 몇 가지 예상치 못한 문제들과 마주했고, 이를 해결하는 과정에서 많은 것을 배울 수 있었죠.

    ⚠️ 문제 1: 네트워크 분리 (Network Partition)

    가장 골치 아팠던 문제 중 하나는 바로 네트워크 분리(Network Partition)였습니다. 특정 노드와 클러스터 코어(Corosync) 통신이 원활하지 않을 때 발생하는데요. 이 경우, 해당 노드는 자신을 클러스터의 일부로 인식하지만, 다른 노드들은 이 노드를 정상으로 인식하지 못하게 됩니다. 최악의 경우, 분리된 노드에서 VM이 중복 실행되는Split-Brain 상황까지 발생할 수 있습니다.

    해결 과정:

    1. 네트워크 연결 상태 점검: 각 노드 간의 ping 테스트, traceroute 등을 통해 네트워크 경로 및 지연 시간을 확인했습니다.
    2. Corosync 설정 확인: /etc/pve/corosync.conf 파일을 주의 깊게 검토하여 네트워크 설정, 노드 목록, 그리고 쿼럼(Quorum) 관련 설정을 재확인했습니다. 특히 2노드 클러스터의 경우 two_node: 1 설정을 통해 스플릿 브레인 방지를 고려하는 것이 중요하죠.
    3. 방화벽 규칙 점검: 각 노드 및 네트워크 장비의 방화벽에서 Corosync 통신 포트(주로 UDP 5404, 5405)가 열려 있는지 확인했습니다.

    ⚠️ 문제 2: 공유 스토리지 접근 불가

    앞서 강조했던 공유 스토리지 설정이 잘못되거나, NFS 서버에 문제가 발생하면 클러스터 전체의 VM 운영에 심각한 영향을 미칩니다. VM 생성이나 시작이 불가능해지는 것은 물론, HA 마이그레이션도 정상적으로 작동하지 않죠.

    해결 과정:

    1. NFS 서버 상태 확인: NFS 서버가 정상적으로 구동 중인지, 해당 디렉토리가 제대로 공유되고 있는지 확인했습니다.
    2. 클라이언트 노드 마운트 확인: 각 Proxmox VE 노드에서 NFS 공유가 정상적으로 마운트되었는지 mount 명령어로 확인하고, 필요시 재마운트했습니다.
    3. 권한 문제 확인: NFS 서버의 내보내기(Export) 설정에서 Proxmox VE 노드들의 IP 주소 또는 서브넷에 대한 접근 권한이 제대로 부여되었는지 확인했습니다.
    Proxmox 클러스터 로그 분석 화면

    이런 문제 발생 시, /var/log/syslog, /var/log/daemon.log, /var/log/pve/ 등 Proxmox VE 관련 로그 파일을 꼼꼼히 확인하는 것이 문제 해결의 첫걸음입니다. 때로는 Corosync의 상태를 확인하기 위해 systemctl status corosync 명령어를 사용하기도 했고요.

    💡 팁: 정기적인 백업과 스냅샷은 필수!

    아무리 안정적인 환경이라도 예기치 못한 상황은 언제든 발생할 수 있습니다. 따라서 중요한 VM은 정기적으로 백업하고, 변경 사항 적용 전에는 스냅샷을 생성하는 습관을 들이는 것이 좋습니다. Proxmox VE는 이러한 백업 및 스냅샷 기능을 매우 편리하게 제공하므로 적극 활용하시길 바랍니다.

    결론: 13년차 엔지니어의 Proxmox 클러스터 최종 평가

    1년 동안 이 Proxmox 클러스터를 사용해보면서, 이 솔루션이 제공하는 안정성, 성능, 그리고 관리 편의성은 홈랩 환경뿐만 아니라 중소규모의 프로덕션 환경에서도 충분히 매력적인 선택지가 될 수 있다고 확신하게 되었어요. 특히 오픈소스 기반으로 강력한 기능을 제공하면서도 라이선스 비용 부담이 적다는 점은 큰 장점이죠.

    물론, 저처럼 처음 클러스터 환경을 구축하거나 운영하는 경우, 네트워크 분리나 공유 스토리지 설정 등에서 다소의 학습 곡선과 삽질(?)이 필요할 수 있습니다. 하지만 Proxmox 커뮤니티의 활성화와 풍부한 온라인 자료 덕분에 대부분의 문제는 해결할 수 있었죠.

    핵심 요약:

    • 장점: 높은 안정성 (HA), 효율적인 자원 관리, 간편한 마이그레이션, 강력한 기능, 비용 효율성
    • 고려사항: 초기 설정의 복잡성 (네트워크, 스토리지), 문제 발생 시 깊이 있는 이해 필요
    Proxmox 클러스터 사용 경험 비교 테이블

    Proxmox 클러스터의 장단점을 한눈에 비교하면 다음과 같습니다.

    구분 장점 고려사항 (단점)
    안정성 고가용성(HA)으로 서비스 중단 최소화 네트워크 분리, 쿼럼 문제 발생 가능성
    성능/관리 중앙 집중식 자원 관리, 간편한 마이그레이션 초기 설정의 복잡성 (네트워크, 스토리지)
    비용 오픈소스 기반, 라이선스 비용 부담 적음 하드웨어 투자 비용 필요

    결론적으로, Proxmox 클러스터는 안정적이고 확장 가능한 가상화 환경을 구축하고자 하는 분들에게 강력 추천할 만한 솔루션입니다. 앞으로도 Proxmox VE의 새로운 기능이나 클러스터 운영 팁에 대해 꾸준히 포스팅할 예정이니, ’13년차의 서버실’ 블로그의 다른 Proxmox 관련 글들도 참고해 주세요! 혹시 Proxmox 클러스터 운영 중 겪었던 재미있는 에피소드나 꿀팁이 있다면 댓글로 공유해주세요. 함께 배우고 성장하는 ’13년차의 서버실’이 되겠습니다. 감사합니다!

  • [Proxmox] Proxmox API 자동화: 홈랩 운영 비용 절감 및 효율 극대화 전략

    [Proxmox] Proxmox API 자동화: 홈랩 운영 비용 절감 및 효율 극대화 전략

    안녕하세요! 13년차 인프라 엔지니어 “13년차의 서버실”입니다. 홈랩을 운영하면서 가장 많이 듣는 이야기가 뭘까요? 아마 “전기세”와 “잦은 관리”일 겁니다. 저도 처음엔 멋모르고 이것저것 돌리다가 깜짝 놀랄 만한 전기요금 고지서를 받아보고 식은땀을 흘린 적이 한두 번이 아니거든요. 😅

    그래서 오늘은 이런 고민을 한방에 날려줄 수 있는 아주 유용한 방법을 소개해 드리려고 합니다. 바로 Proxmox API 자동화인데요. 이 녀석 덕분에 제 홈랩 운영 비용은 확 줄고, 관리 효율은 엄청나게 극대화되었더라고요. 제가 직접 삽질해가며 깨달은 노하우들을 아낌없이 풀어볼게요!

    혹시 여러분도 밤늦게까지 돌아가는 서버들 때문에 전기요금 걱정하고 계신가요? 아니면 매일매일 반복되는 가상 머신(VM, Virtual Machine)이나 컨테이너(CT, Container)의 켜고 끄는 작업을 자동화하고 싶진 않으신가요? 그렇다면 이 글이 큰 도움이 될 겁니다. 💡

    Proxmox API를 활용한 홈랩 자동화의 전체적인 아키텍처 개요 다이어그램

    그림 1: Proxmox API를 활용한 홈랩 자동화 전체 아키텍처 개요

    Proxmox API, 그게 뭔데요? (개념 설명)

    Proxmox VE(Virtual Environment)는 많은 분들이 홈랩에서 즐겨 사용하는 오픈소스 가상화 플랫폼이죠. 이 Proxmox는 단순히 웹 UI(User Interface)를 통해서만 관리할 수 있는 게 아니에요. API(Application Programming Interface, 애플리케이션 프로그래밍 인터페이스)라는 강력한 도구를 제공합니다. 쉽게 말해, 우리가 웹 UI에서 마우스 클릭으로 하던 모든 작업을 프로그래밍 코드(스크립트)로 대신 처리할 수 있도록 만들어주는 “통신 창구” 같은 거거든요.

    Proxmox API는 RESTful API(Representational State Transfer, REST 기반) 형태로 제공돼요. HTTP(Hypertext Transfer Protocol) 요청을 통해 Proxmox 서버와 데이터를 주고받고, 가상 머신 생성/삭제/시작/중지, 네트워크 설정 변경 등 거의 모든 관리 작업을 자동화할 수 있더라고요. 제가 처음 이 API를 접했을 때, “이거 진짜 물건이네!” 싶었거든요. 반복적인 작업을 스크립트 하나로 해결할 수 있다는 게 정말 매력적이었습니다.

    특히 홈랩 자동화에서는 이 Proxmox API가 빛을 발합니다. 예를 들어, 특정 시간에만 필요한 서버는 자동으로 켜지고 꺼지게 하거나, 자원 사용량이 많아지면 새로운 컨테이너를 자동으로 배포하는 등의 시나리오를 구현할 수 있죠. 운영 비용 절감과 효율성 극대화의 핵심 열쇠라고 할 수 있습니다. 🔑

    실전 구현: Proxmox API 토큰 발급 및 파이썬 스크립트 작성

    자, 이제 실전으로 들어가 볼까요? Proxmox API를 사용하려면 먼저 API 토큰(API Token)을 발급받아야 합니다. 이 토큰은 마치 비밀번호처럼, 스크립트가 Proxmox에 접근할 수 있는 권한을 부여하는 역할을 해요. 보안상 매우 중요하니 잘 관리해야 합니다!

    1단계: Proxmox API 토큰 발급

    Proxmox 웹 UI에 접속해서 Datacenter > Permissions > API Tokens 메뉴로 이동합니다. 여기서 “Add” 버튼을 눌러 새로운 API 토큰을 생성할 수 있어요. 사용자(User)는 보통 root@pam을 많이 쓰지만, 특정 권한만 필요한 경우 새로운 사용자를 만들어서 제한된 권한을 부여하는 것이 좋습니다. 저는 홈랩이라 root@pam으로 진행했거든요.

    1. 사용자 선택: root@pam 또는 적절한 사용자 선택.
    2. 토큰 ID 입력: 예: homelab-automation
    3. 권한 설정: 필요한 최소한의 권한만 부여하는 것이 보안에 좋습니다. VM/CT 제어가 목적이라면 VM.PowerMgmt, VM.Audit 정도면 충분해요. 저는 테스트를 위해 Administrator 권한을 부여했습니다만, 실제 운영에서는 절대 권장하지 않습니다!
    4. 생성: 토큰을 생성하면 Secret 값이 한 번만 표시됩니다. 이 값을 꼭 안전한 곳에 복사해 두세요. 나중에 다시 볼 수 없거든요! ⚠️
    Proxmox 웹 UI에서 API 토큰을 생성하는 과정과 설정 화면

    그림 2: Proxmox 웹 UI에서 API 토큰을 생성하는 화면

    2단계: 파이썬(Python) 환경 설정 및 라이브러리 설치

    저는 파이썬을 이용한 스크립트 작성을 선호합니다. 직관적이고 강력한 라이브러리가 많거든요. requests 라이브러리를 사용해서 HTTP 요청을 보낼 건데, 아직 설치 안 되어 있다면 다음 명령어로 설치해 주세요.

    pip install requests
    

    3단계: Proxmox API를 이용한 VM/CT 제어 스크립트 작성

    이제 본격적으로 스크립트를 작성해 봅시다. 이 스크립트는 Proxmox에 있는 특정 VM이나 CT를 시작하거나 종료하는 기능을 수행할 거예요. 저는 밤에는 미디어 서버 외에는 대부분 꺼두고, 낮에만 필요한 개발 환경 VM들을 켜두는 식으로 운영 비용을 절감하고 있거든요.

    import requests
    import json
    import os
    
    # Proxmox 설정 (환경 변수에서 불러오는 것을 권장합니다!)
    # PVE_HOST = os.getenv('PVE_HOST', 'your_proxmox_ip_or_hostname')
    # PVE_USER = os.getenv('PVE_USER', 'root@pam')
    # PVE_TOKEN_ID = os.getenv('PVE_TOKEN_ID', 'homelab-automation') # Proxmox API Token ID
    # PVE_TOKEN_SECRET = os.getenv('PVE_TOKEN_SECRET', 'YOUR_API_TOKEN_SECRET') # Proxmox API Token Secret
    
    # 보안을 위해 실제 환경에서는 환경 변수를 사용하세요.
    # 예: export PVE_HOST='192.168.1.100'
    # 예: export PVE_USER='root@pam'
    # 예: export PVE_TOKEN_ID='homelab-automation'
    # 예: export PVE_TOKEN_SECRET='YOUR_API_TOKEN_SECRET'
    
    PVE_HOST = '192.168.1.100' # 여러분의 Proxmox IP 또는 호스트 이름
    PVE_USER = 'root@pam'
    PVE_TOKEN_ID = 'homelab-automation' # 발급받은 API 토큰 ID
    PVE_TOKEN_SECRET = 'YOUR_API_TOKEN_SECRET' # 발급받은 API 토큰 Secret
    
    # SSL 인증서 검증 비활성화 (개발/테스트 용도로만 사용하세요! 실제 운영 환경에서는 CA 인증서 설정 권장)
    VERIFY_SSL = False 
    
    def proxmox_api_call(method, path, data=None):
        url = f"https://{PVE_HOST}:8006/api2/json/{path}"
        headers = {
            "Authorization": f"PVEAPIToken={PVE_USER}!{PVE_TOKEN_ID}={PVE_TOKEN_SECRET}"
        }
        
        try:
            if method == 'GET':
                response = requests.get(url, headers=headers, verify=VERIFY_SSL)
            elif method == 'POST':
                response = requests.post(url, headers=headers, json=data, verify=VERIFY_SSL)
            elif method == 'PUT':
                response = requests.put(url, headers=headers, json=data, verify=VERIFY_SSL)
            elif method == 'DELETE':
                response = requests.delete(url, headers=headers, verify=VERIFY_SSL)
            else:
                raise ValueError(f"Unsupported HTTP method: {method}")
    
            response.raise_for_status() # HTTP 오류 발생 시 예외 발생
            return response.json()
        except requests.exceptions.RequestException as e:
            print(f"API 호출 중 오류 발생: {e}")
            if hasattr(e, 'response') and e.response is not None:
                print(f"응답 본문: {e.response.text}")
            return None
    
    def get_vm_status(node, vmid):
        path = f"nodes/{node}/qemu/{vmid}/status/current"
        result = proxmox_api_call('GET', path)
        if result and 'data' in result:
            return result['data']['status']
        return "unknown"
    
    def start_vm(node, vmid):
        path = f"nodes/{node}/qemu/{vmid}/status/start"
        print(f"VM {vmid} 시작 중...")
        return proxmox_api_call('POST', path)
    
    def stop_vm(node, vmid):
        path = f"nodes/{node}/qemu/{vmid}/status/stop"
        print(f"VM {vmid} 종료 중...")
        return proxmox_api_call('POST', path)
    
    def get_lxc_status(node, ctid):
        path = f"nodes/{node}/lxc/{ctid}/status/current"
        result = proxmox_api_call('GET', path)
        if result and 'data' in result:
            return result['data']['status']
        return "unknown"
    
    def start_lxc(node, ctid):
        path = f"nodes/{node}/lxc/{ctid}/status/start"
        print(f"CT {ctid} 시작 중...")
        return proxmox_api_call('POST', path)
    
    def stop_lxc(node, ctid):
        path = f"nodes/{node}/lxc/{ctid}/status/stop"
        print(f"CT {ctid} 종료 중...")
        return proxmox_api_call('POST', path)
    
    if __name__ == "__main__":
        node_name = 'pve' # Proxmox 노드 이름 (예: pve, server01 등)
    
        # VM 제어 예시
        my_vm_id = 100 # 제어할 VM의 ID
        print(f"VM {my_vm_id} 현재 상태: {get_vm_status(node_name, my_vm_id)}")
        
        # VM 시작
        # if get_vm_status(node_name, my_vm_id) == 'stopped':
        #     start_vm(node_name, my_vm_id)
        # else:
        #     print(f"VM {my_vm_id}는 이미 실행 중입니다.")
    
        # VM 종료 (주의: 강제 종료될 수 있으니 신중하게 사용하세요!)
        # if get_vm_status(node_name, my_vm_id) == 'running':
        #     stop_vm(node_name, my_vm_id)
        # else:
        #     print(f"VM {my_vm_id}는 이미 종료되어 있습니다.")
    
        # CT 제어 예시
        my_ct_id = 101 # 제어할 CT의 ID
        print(f"CT {my_ct_id} 현재 상태: {get_lxc_status(node_name, my_ct_id)}")
    
        # CT 시작
        # if get_lxc_status(node_name, my_ct_id) == 'stopped':
        #     start_lxc(node_name, my_ct_id)
        # else:
        #     print(f"CT {my_ct_id}는 이미 실행 중입니다.")
    
        # CT 종료
        # if get_lxc_status(node_name, my_ct_id) == 'running':
        #     stop_lxc(node_name, my_ct_id)
        # else:
        #     print(f"CT {my_ct_id}는 이미 종료되어 있습니다.")
    

    위 스크립트에서 PVE_HOST, PVE_TOKEN_ID, PVE_TOKEN_SECRET 부분은 여러분의 환경에 맞게 수정해야 합니다. 특히 PVE_TOKEN_SECRET는 절대로 외부에 노출되지 않도록 주의하세요! 저는 테스트를 위해 코드에 직접 넣었지만, 실제 운영에서는 환경 변수(Environment Variables)를 사용하거나 별도의 설정 파일에 저장해서 사용하는 것이 보안상 훨씬 안전합니다. ⚠️

    그리고 VERIFY_SSL = False 부분은 개발 및 테스트 편의를 위한 것이며, 실제 운영 환경에서는 Proxmox 서버의 CA(Certificate Authority) 인증서를 신뢰하도록 설정하여 True로 사용하는 것을 강력히 권장합니다. 보안은 언제나 최우선이거든요!

    주의사항 및 트러블슈팅: 삽질 경험 공유 ⚠️

    제가 이 Proxmox API 자동화를 처음 시도하면서 겪었던 몇 가지 삽질 경험과 주의사항을 공유해 드릴게요. 여러분은 저처럼 헤매지 마시라고요! ㅎㅎ

    • 권한 문제 (Permission Denied): API 토큰을 만들 때 권한 설정을 너무 제한적으로 하면 원하는 작업이 안 될 수 있어요. 예를 들어, VM을 시작해야 하는데 VM.PowerMgmt 권한이 없다면 당연히 에러가 나더라고요. 에러 메시지에 Permission denied가 보인다면, API 토큰의 권한 설정을 다시 확인해 보세요. 저는 초반에 이걸 제대로 안 봐서 한참을 헤맸었습니다.
    • SSL 인증서 문제 (SSL Certificate Verification Failed): 위 스크립트에서 VERIFY_SSL = False로 설정했지만, 실제 운영 환경에서는 이렇게 하면 보안에 취약해집니다. Proxmox 서버가 자체 서명(Self-Signed) 인증서를 사용하는 경우가 많은데, 이럴 때는 해당 인증서를 파이썬 스크립트가 실행되는 시스템에 신뢰하도록 추가하거나, requests 라이브러리에서 인증서 경로를 명시해 줘야 합니다. 이게 귀찮다고 그냥 끄면 중간자 공격(Man-in-the-Middle Attack)에 노출될 위험이 있어요!
    • 네트워크 연결 문제: Proxmox 호스트와 스크립트가 실행되는 서버 간의 네트워크 연결이 불안정하거나 방화벽(Firewall)에서 8006 포트가 막혀있으면 API 호출이 실패합니다. telnet your_proxmox_ip 8006 명령어로 연결 테스트를 해보는 것이 좋습니다.
    • POST/GET 메서드 혼동: API는 작업의 종류에 따라 HTTP 메서드(Method)가 다릅니다. 정보 조회는 GET, 상태 변경이나 생성은 POST/PUT, 삭제는 DELETE를 사용하죠. 이걸 잘못 쓰면 엉뚱한 에러가 발생합니다. Proxmox API 문서(Proxmox API Documentation)를 꼼꼼히 확인하는 게 중요합니다.

    이런 문제들을 해결하면서 Proxmox API 자동화에 대한 이해도가 훨씬 깊어졌어요. 역시 삽질은 최고의 스승이더라고요! 😂

    검증 및 결과: 효율적인 홈랩 운영의 시작 🎉

    스크립트가 잘 작동하는지 확인하는 건 필수겠죠? 저는 보통 crontab(크론탭) 같은 스케줄러에 스크립트를 등록해서 특정 시간에 자동으로 실행되도록 합니다. 예를 들어, 평일 업무 시간(오전 9시 ~ 오후 6시)에만 개발 VM을 켜두고, 그 외 시간에는 자동으로 꺼지게 하는 거죠.

    # 매일 오전 9시에 VM 100번과 CT 101번 시작
    0 9 * * 1-5 python3 /path/to/your_script.py start_work_vms
    
    # 매일 오후 6시에 VM 100번과 CT 101번 종료
    0 18 * * 1-5 python3 /path/to/your_script.py stop_work_vms
    

    이렇게 설정해두면, 제가 일일이 신경 쓸 필요 없이 Proxmox가 알아서 척척 움직입니다. 덕분에 전기세도 확실히 줄어들고요, 불필요하게 자원을 낭비하는 일도 없어졌습니다. 홈랩 운영 비용이 절감되는 걸 눈으로 직접 확인하니 정말 뿌듯하더라고요!

    Proxmox 웹 UI의 Tasks 로그를 통해서도 스크립트가 성공적으로 실행되었는지 확인할 수 있습니다. start VM 100, stop CT 101 같은 메시지가 보인다면 성공입니다. ✅

    Proxmox의 작업 로그와 자동화 후 전력 사용량 변화를 보여주는 모니터링 대시보드

    그림 3: Proxmox의 Task 로그와 전력 사용량 모니터링 대시보드 예시

    마무리: Proxmox API 자동화, 선택이 아닌 필수!

    오늘은 Proxmox API 자동화를 통해 홈랩 운영 비용을 절감하고 관리 효율을 극대화하는 전략에 대해 이야기해 봤습니다. 13년차 인프라 엔지니어로서, 이런 자동화는 이제 선택이 아닌 필수가 되었다고 생각합니다. 특히나 저처럼 홈랩을 운영하면서 다양한 실험을 하는 분들에게는 더더욱 그렇죠.

    Proxmox API는 단순히 VM/CT를 켜고 끄는 것을 넘어, 스냅샷(Snapshot) 관리, 백업(Backup) 자동화, 네트워크 설정 변경 등 무궁무진한 가능성을 제공합니다. 여러분의 창의적인 아이디어를 더하면 훨씬 더 강력한 홈랩 자동화 시스템을 구축할 수 있을 거예요.

    물론 처음에는 API 문서 찾아보고, 스크립트 짜고, 에러 잡아가면서 좀 힘들 수도 있습니다. 저도 그랬거든요! 하지만 한 번 구축해두면 그 편리함과 효율성은 정말 상상 이상이더라고요. 운영 비용 절감 효과는 덤이고요. 😉

    이 글이 여러분의 Proxmox API 자동화 여정에 작은 등불이 되었으면 좋겠습니다. 다음번에는 Proxmox API를 활용한 동적 자원 할당이나 모니터링 연동에 대해 다뤄볼까 합니다. 기대해 주세요! 👋

    수동 홈랩 관리와 Proxmox API 자동화의 장단점을 비교하는 요약 인포그래픽

    그림 4: 수동 관리와 Proxmox API 자동화 비교 요약 인포그래픽

  • [Proxmox] Proxmox Backup Server vs Veeam Agent: 홈랩 VM 백업 솔루션 성능 벤치마크

    [Proxmox] Proxmox Backup Server vs Veeam Agent: 홈랩 VM 백업 솔루션 성능 벤치마크

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘도 제 홈랩에서 겪었던 삽질과 그 결과물을 공유해드리려고 합니다. 홈랩을 운영하다 보면 가장 중요하면서도 소홀하기 쉬운 부분이 바로 ‘백업’이더라고요. 소중한 설정 파일, 직접 구축한 서비스 데이터, 자식 같은 VM들… 한순간에 날아갈 수도 있다는 생각에 늘 불안하죠. 그래서 오늘은 제가 직접 Proxmox Backup Server (PBS)와 Veeam Agent for Linux 두 가지 백업 솔루션을 비교하고 성능을 벤치마크해본 경험을 이야기해보려고 합니다. 홈랩 VM 백업 솔루션 선택에 고민이 많으셨다면, 이 글이 좋은 가이드가 될 거예요.

    Proxmox Backup Server와 Veeam Agent를 활용한 홈랩 VM 백업 아키텍처 다이어그램

    홈랩 환경에서 Proxmox VE 호스트, Proxmox Backup Server VM, NAS 스토리지, 그리고 Veeam Agent가 설치된 게스트 VM들이 서로 연결되어 백업이 진행되는 전체 아키텍처 다이어그램입니다.

    1. Proxmox Backup Server와 Veeam Agent, 뭐가 다른가요?

    먼저 오늘 비교할 두 주인공에 대해 간단히 알아볼까요? 제가 직접 써보니 각각의 특징이 아주 명확하더라고요.

    1.1. Proxmox Backup Server (PBS)

    Proxmox Backup Server (PBS)는 이름에서 알 수 있듯이 Proxmox VE(Virtual Environment) 생태계에 최적화된 백업 솔루션입니다. Proxmox VE를 사용하신다면 마치 한 몸처럼 연동되는 걸 느낄 수 있을 거예요. 주요 특징은 다음과 같습니다.

    • 블록 수준 중복 제거 (Block-level Deduplication): 백업 데이터에서 중복되는 블록을 찾아 제거해서 스토리지 공간을 엄청나게 절약해줍니다. 제가 써보니 이 기능이 정말 압권이더라고요!
    • 증분 백업 (Incremental Backup): 변경된 데이터만 백업해서 백업 시간을 줄여줍니다.
    • 압축 (Compression): 백업 데이터를 압축하여 스토리지 효율을 높여줍니다.
    • 웹 기반 GUI: Proxmox VE와 유사하게 직관적인 웹 인터페이스를 제공해서 관리하기 정말 편합니다.
    • 통합 백업 스케줄링: Proxmox VE에서 직접 PBS로 VM 백업 스케줄을 설정할 수 있어요.

    1.2. Veeam Agent for Linux

    Veeam Agent for Linux는 Veeam에서 제공하는 리눅스용 백업 에이전트입니다. Proxmox VE 환경뿐만 아니라, 일반 물리 서버나 다른 하이퍼바이저의 게스트 OS 등 다양한 리눅스 환경에서 유연하게 사용할 수 있다는 장점이 있어요. 특히 Free (무료) 버전도 기본적인 백업/복구 기능이 강력해서 홈랩 백업 솔루션으로 많이들 사용하시더라고요.

    • 에이전트 기반 (Agent-based): 백업 대상 리눅스 VM 내부에 직접 에이전트를 설치해서 동작합니다.
    • 다양한 백업 대상: 전체 시스템 (Entire System), 볼륨 (Volume), 파일 수준 (File-level) 백업을 지원합니다.
    • 유연한 복구 옵션: 베어 메탈 복구 (Bare-metal Recovery), 파일 복구 등을 지원합니다.
    • Free 버전의 강력함: 무료 버전으로도 훌륭한 백업 기능을 제공해서 저 같은 홈랩 유저들에게 인기가 많죠.

    2. 제 홈랩에서 직접 구현해 본 과정

    이론은 여기까지 하고, 이제 제가 직접 어떻게 구성했는지 설명해 드릴게요. 제 홈랩은 Proxmox VE 호스트 한 대와 NAS (Network Attached Storage)로 구성되어 있습니다. 백업 대상은 Proxmox VE 위에 올라간 데비안(Debian) 기반의 리눅스 VM이었어요.

    2.1. Proxmox Backup Server (PBS) 설치 및 구성

    저는 별도의 VM에 PBS를 설치했습니다. 물론 물리 서버에 설치해도 되지만, 홈랩에서는 VM도 충분하거든요.

    1. PBS VM 생성: Proxmox VE에서 새로운 VM을 만들고, PBS ISO 파일을 마운트해서 설치했습니다. 설치 과정은 Proxmox VE와 비슷해서 어렵지 않더라고요. 최소 4GB RAM과 2코어 CPU, 그리고 백업 데이터를 저장할 디스크를 할당해줬습니다.
    2. 저장소 설정: PBS 웹 GUI에 접속해서 백업 데이터를 저장할 디스크를 Datastore(데이터스토어)로 설정했습니다. 저는 NAS의 NFS 마운트 경로를 여기에 연결했어요.
    3. Proxmox VE에 PBS 추가: Proxmox VE 웹 GUI에서 Datacenter > Storage > Add > Proxmox Backup Server를 선택하고, PBS의 IP 주소와 Datastore 이름, 사용자 인증 정보를 입력했습니다.
    4. 백업 작업 생성: 이제 Proxmox VE에서 백업할 VM을 선택하고 ‘Backup’ 버튼을 누르면, 스토리지 옵션에 PBS 서버가 뜨는 것을 확인할 수 있습니다. 스케줄링과 리텐션(Retention, 보존 정책)까지 설정해주면 끝! 정말 편하더라고요.
    Proxmox Backup Server 웹 GUI의 백업 성공 및 스토리지 중복 제거율 화면

    Proxmox Backup Server의 웹 인터페이스에서 백업 작업이 성공적으로 완료된 목록과 데이터스토어의 중복 제거율 및 압축률을 보여주는 화면입니다.

    2.2. Veeam Agent for Linux 설치 및 구성

    이제 백업 대상 리눅스 VM에 Veeam Agent를 설치할 차례입니다. 저는 데비안 기반 VM에 설치했어요.

    1. Veeam Repository 추가: 먼저 Veeam 리포지토리를 추가해야 합니다.
    2. wget -qO - https://download.veeam.com/veeam-release-key.gpg | sudo apt-key add -
      echo "deb https://download.veeam.com/linux-repository-x64 stable" | sudo tee /etc/apt/sources.list.d/veeam.list
      sudo apt update
    3. Veeam Agent 설치: 리포지토리를 추가했으니, 이제 에이전트를 설치합니다.
    4. sudo apt install veeam
    5. 설정 및 백업 저장소 마운트: Veeam Agent는 백업 데이터를 저장할 위치가 필요합니다. 저는 NAS의 SMB 공유 폴더를 VM 내부에 마운트해서 사용했어요.
    6. # /etc/fstab 에 추가
      //NAS_IP/share /mnt/veeam_backup cifs credentials=/root/.smbcredentials,uid=1000,gid=1000 0 0
      # .smbcredentials 파일 내용: username=myuser,password=mypass
      
      sudo mount -a
    7. 백업 작업 생성: Veeam Agent는 CLI (Command Line Interface)로 백업 작업을 생성하고 관리합니다.
    8. sudo veeamconfig job create --name "My_VM_Backup" --type "volume" --volumes "/" --repository "/mnt/veeam_backup" --schedule "daily" --retention "7" --full-backup-period "weekly"

      위 명령어는 ‘/’ 볼륨 전체를 매일 백업하고 7일간 보존하며, 매주 전체 백업을 수행하는 작업을 생성하는 예시입니다.

    Veeam Agent for Linux의 CLI 명령어를 사용하여 백업 작업 생성 및 상태를 확인하는 리눅스 터미널 화면

    백업 대상 리눅스 VM의 터미널에서 `veeamconfig` 명령어를 사용하여 백업 작업을 생성하거나 상태를 확인하는 CLI 실행 화면입니다.

    3. 삽질 경험: 주의사항과 트러블슈팅

    홈랩에서 새로운 기술을 도입하면 늘 예상치 못한 삽질의 연속이죠. 저도 예외는 아니었습니다. 😅

    3.1. Proxmox Backup Server (PBS)에서 겪은 문제

    • 초기 백업 시간: 처음 전체 백업을 할 때, Dedup 인덱싱 때문에 생각보다 시간이 좀 걸리더라고요. 특히 데이터 양이 많을수록 초기 부담이 있었습니다. 물론 그 이후의 증분 백업은 매우 빨라졌지만요. 💡 팁: 처음부터 충분한 리소스 (RAM, CPU)를 할당해주면 좋습니다.
    • 스토리지 공간 관리: Dedup이 강력해서 공간 절약은 좋지만, 오래된 백업을 제대로 프루닝(Pruning, 정리)하지 않으면 나중에 공간이 부족해질 수 있습니다. 리텐션 정책을 꼼꼼히 설정하고 주기적으로 확인하는 게 중요합니다.

    3.2. Veeam Agent for Linux에서 겪은 문제

    • 커널 업데이트와 DKMS: 리눅스 커널이 업데이트될 때마다 Veeam Agent의 커널 모듈이 재컴파일되어야 합니다. DKMS (Dynamic Kernel Module Support)가 잘 작동하면 문제가 없지만, 가끔 수동으로 개입해야 할 때가 있더라고요. ⚠️ 커널 업데이트 후 백업이 실패한다면 이 부분을 먼저 확인해보세요.
    • NFS/SMB 마운트 권한: 백업 저장소로 NAS를 사용하면서 마운트 권한 문제로 한참을 씨름했습니다. `uid`, `gid` 옵션과 `.smbcredentials` 파일 설정을 잘못해서 백업 파일을 쓸 수 없었던 거죠. 결국 `veeamconfig`를 실행하는 유저의 권한과 마운트 옵션을 정확히 맞춰주니 해결되더라고요.
    • 파일 시스템 스냅샷: Veeam Agent는 백업 시 파일 시스템 스냅샷을 활용하는데, 특정 파일 시스템에서는 문제가 될 수 있습니다. LVM (Logical Volume Manager)을 사용하면 안정적인 스냅샷을 생성할 수 있어서 백업 신뢰도가 높아집니다. 저는 처음엔 LVM 없이 하다가 나중에 LVM으로 전환했네요.

    4. 드디어 결과: 홈랩 VM 백업 솔루션 성능 벤치마크

    여러 번의 테스트와 삽질 끝에 드디어 두 솔루션의 성능을 비교해볼 수 있었습니다. 제가 직접 동일한 VM과 데이터 세트를 가지고 테스트해본 결과는 다음과 같습니다. (정확한 수치보다는 제가 체감한 경향성을 위주로 말씀드릴게요.)

    항목 Proxmox Backup Server (PBS) Veeam Agent for Linux
    백업 속도 (초기 전체) 매우 빠름 (VM 스냅샷 기반, 블록 직접 접근) 보통 (VM 내부에서 파일 시스템 스캔)
    백업 속도 (증분) 압도적으로 빠름 (변경 블록만 백업) 빠름 (변경된 파일/블록 스캔)
    스토리지 효율성 최상 (블록 수준 Dedup + 압축, 중복 제거율 매우 높음) 보통 (일반적인 파일 압축, Dedup 없음)
    복구 속도 및 편의성 매우 편리 (전체 VM 복구, 파일 단위 복구도 가능) 편리 (전체 시스템/볼륨/파일 단위 복구)
    관리 편의성 최상 (Proxmox VE와 통합된 중앙 집중식 GUI) 보통 (각 VM에 에이전트 설치 및 CLI 관리)
    지원 환경 Proxmox VE 환경에 특화 다양한 리눅스 환경 (물리/가상/클라우드)
    Proxmox Backup Server와 Veeam Agent for Linux의 백업 성능 및 기능 비교 인포그래픽

    Proxmox Backup Server와 Veeam Agent for Linux의 백업 속도, 스토리지 효율성, 관리 편의성 등을 시각적으로 비교한 인포그래픽입니다.

    제가 직접 써보니 PBS의 블록 수준 중복 제거는 정말 엄청난 기능이더라고요. 여러 VM을 백업해도 중복되는 OS 파일이나 라이브러리 같은 것들은 한 번만 저장되니, 스토리지 공간이 기하급수적으로 절약됩니다. 백업 시간도 Proxmox VE와 긴밀하게 연동되어 VM 스냅샷 기반으로 동작하기 때문에 훨씬 빨랐습니다. Veeam Agent도 훌륭한 솔루션이지만, VM 내부에서 동작하는 특성상 PBS만큼의 통합된 성능과 효율을 보여주지는 못했어요.

    5. 마무리: 어떤 솔루션이 당신의 홈랩에 적합할까요?

    결론적으로 제 홈랩 백업 환경에서는 Proxmox Backup Server가 압도적인 우위를 보였습니다. Proxmox VE를 메인 하이퍼바이저로 사용하고 있다면, PBS는 선택이 아닌 필수라고 해도 과언이 아닐 정도예요. 정말 이거 진짜 편하더라고요! 🎉

    하지만 만약 여러분의 홈랩이나 실제 운영 환경이 Proxmox VE 외에 다른 하이퍼바이저 (예: VMware, Hyper-V)나 물리 서버, 혹은 클라우드 VM이 섞여 있다면, Veeam Agent for Linux는 여전히 매우 강력한 선택지가 될 수 있습니다. 다양한 환경을 아우르는 범용성과 강력한 복구 기능은 무시할 수 없거든요. 특히 무료 버전도 워낙 훌륭해서 예산 제약이 있는 홈랩에서는 충분히 고려해볼 만합니다.

    어떤 솔루션을 선택하든, 가장 중요한 건 정기적인 백업과 복구 테스트입니다. 백업은 했는데 복구가 안 되면 아무 소용 없잖아요? 제가 겪었던 삽질 경험을 바탕으로 여러분은 좀 더 수월하게 백업 환경을 구축하시길 바랍니다. 혹시 더 궁금한 점이나 다른 백업 솔루션에 대한 경험이 있으시다면 댓글로 공유해주세요! 다음 글에서는 Proxmox Backup Server의 고급 설정이나 복구 시뮬레이션에 대해 좀 더 깊이 다뤄볼까 합니다. 기대해주세요!

  • [Proxmox] Ceph 스토리지 성능 벤치마크: HDD vs SSD, 홈랩에서 직접 해보니

    [Proxmox] Ceph 스토리지 성능 벤치마크: HDD vs SSD, 홈랩에서 직접 해보니

    [Proxmox] Ceph 스토리지 성능 벤치마크: HDD vs SSD, 홈랩에서 직접 해보니

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 제가 홈랩에서 직접 겪고 실험해 본 Proxmox Ceph 스토리지 성능 벤치마크 이야기를 풀어볼까 합니다. 특히 많은 분이 궁금해하시는 HDD와 SSD OSD의 성능 차이에 대해 집중적으로 다뤄볼 거예요.

    분산 스토리지(Distributed Storage)하면 역시 Ceph가 떠오르죠? 고가용성(High Availability)과 확장성(Scalability) 덕분에 엔터프라이즈 환경은 물론, 저처럼 홈랩을 운영하는 인프라 엔지니어들에게도 매력적인 솔루션입니다. 그런데 Ceph를 막상 구축하고 나면 이런 고민에 빠지게 됩니다. ‘과연 어떤 디스크를 써야 최적의 성능을 낼 수 있을까?’ 특히 가상 머신(VM)이나 데이터베이스(DB)처럼 랜덤 I/O가 많은 워크로드에서는 스토리지 성능이 정말 중요하거든요.

    그래서 제가 직접 Proxmox Ceph 환경에서 HDD와 SSD OSD의 성능을 비교 벤치마크 해봤습니다. 여러분의 Ceph 스토리지 구축에 도움이 되셨으면 좋겠네요! 💡

    Proxmox Ceph 클러스터 아키텍처 다이어그램: 3개 노드와 Ceph OSD 구성

    Proxmox Ceph 클러스터 아키텍처 다이어그램: 3개의 Proxmox 노드가 Ceph OSD를 구성하고 VM에 스토리지를 제공하는 모습입니다.

    Ceph 스토리지, 그리고 OSD의 역할

    먼저, Ceph와 OSD(Object Storage Daemon)가 무엇인지 간단하게 짚고 넘어갈게요. Proxmox VE (Virtual Environment)는 오픈소스 가상화 플랫폼이고, 이 Proxmox 환경 위에서 Ceph는 강력한 분산 스토리지 시스템으로 동작합니다. Ceph의 핵심은 바로 OSD인데요, 쉽게 말해 Ceph 클러스터의 ‘일꾼’이라고 보시면 됩니다. 실제 데이터를 저장하고 관리하는 디스크 하나하나가 OSD가 되는 거죠. OSD 하나의 성능이 전체 클러스터의 성능을 결정합니다.

    특히 Ceph의 최신 스토리지 엔진인 BlueStore를 사용하면, 데이터와 별도로 메타데이터(Metadata)와 쓰기-선행 로그(Write-Ahead Log, WAL), RocksDB 같은 내부 DB를 관리하는데요. 이들을 고성능 디스크로 분리해주면 OSD 성능이 크게 올라갑니다. 이번 벤치마크에서는 OSD 전체를 HDD 또는 SSD로 구성해서 비교해봤습니다.

    홈랩 Ceph 클러스터 실전 구현

    제 홈랩 환경은 Proxmox 노드 3개로 구성되어 있습니다. 이 3개의 노드에 각각 Ceph OSD를 하나씩 생성해서 클러스터를 구성했어요. Proxmox VE의 웹 UI(User Interface)는 Ceph 설치와 OSD 생성을 정말 쉽고 직관적으로 할 수 있게 해줍니다. 처음엔 이게 뭔가 싶었는데, 클릭 몇 번으로 클러스터 구성이 끝나더라고요. 정말 편합니다!

    1. Ceph OSD 생성

    • HDD OSD 구성: 각 노드에 장착된 일반 3.5인치 HDD를 Ceph OSD로 추가했습니다.
    • SSD OSD 구성: 그리고 테스트를 위해 SATA SSD를 각 노드에 추가하여 Ceph OSD로 구성했습니다. BlueStore도 당연히 사용했고요.

    OSD가 제대로 생성되었는지 확인하는 명령어는 다음과 같습니다.

    
    ceph status
    ceph osd tree
    

    Proxmox VE 웹 UI에서 Ceph OSD를 생성하는 화면입니다. 디스크 선택, BlueStore 엔진 사용 여부 등을 설정할 수 있습니다.

    2. 벤치마크 VM 준비

    성능 벤치마크는 FIO (Flexible I/O Tester) 도구를 썼습니다. FIO는 다양한 I/O 패턴(Random Read/Write, Sequential Read/Write 등)과 블록 사이즈(Block Size), 큐 깊이(Queue Depth)를 조절하여 실제 워크로드와 유사한 환경을 만들 수 있어서 아주 유용하거든요. Proxmox에서 VM을 하나 만들고, Ceph RBD(RADOS Block Device) 스토리지를 붙여준 다음 그 VM 안에서 FIO를 실행했어요.

    간단한 FIO 명령어 예시입니다.

    
    fio --name=randwrite --ioengine=libaio --iodepth=64 --rw=randwrite --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting
    

    ⚠️ 삽질 경험담: 주의사항 및 트러블슈팅

    이런 벤치마크를 진행하다 보면 꼭 삽질을 하게 되죠. 저도 예외는 아니었습니다. ㅎㅎ

    • 네트워크 대역폭의 중요성: Ceph는 분산 스토리지 시스템인 만큼, 노드 간 통신이 매우 중요합니다. 처음엔 1GbE(기가비트 이더넷)로 테스트했는데, 아무리 SSD OSD를 써도 성능이 기대 이하였습니다. Ceph 성능의 병목(Bottleneck)이 바로 네트워크였던 거죠. 결국 10GbE 환경으로 바꾸고 나서야 제대로 된 성능을 뽑아낼 수 있었습니다. 혹시 Ceph 성능이 안 나온다면, 제일 먼저 네트워크 대역폭을 의심해보세요!

    • 디스크 속도 편차: Ceph 클러스터는 가장 느린 OSD의 속도에 맞춰지는 경향이 있습니다. 모든 OSD 디스크의 성능이 균일해야 클러스터 전체의 성능을 최대로 끌어올릴 수 있습니다. 이 점도 꼭 기억해주세요.

    • FIO 설정의 중요성: FIO 옵션을 어떻게 주느냐에 따라 결과가 천차만별입니다. 실제 사용하려는 워크로드가 랜덤 I/O인지 순차(Sequential) I/O인지, 블록 사이즈는 어떤지, 큐 깊이는 어느 정도인지 등을 잘 고려해서 설정해야 의미 있는 벤치마크 결과를 얻을 수 있습니다. 무작정 높은 수치만 쫓기보다는, ‘우리 환경에 맞는’ 벤치마크를 하는 게 중요하거든요.

    Ceph 스토리지 성능 벤치마크 결과: HDD vs SSD

    자, 이제 가장 궁금해하실 벤치마크 결과입니다. 제가 설정한 FIO 시나리오(블록 사이즈 4k, 큐 깊이 64)에서 HDD OSD와 SSD OSD의 IOPS (Input/Output Operations Per Second), Throughput (처리량), Latency (지연 시간)를 측정했습니다.

    HDD OSD 성능 결과

    • 랜덤 읽기/쓰기 IOPS: 500 ~ 1,000 IOPS 수준
    • 순차 읽기/쓰기 Throughput: 80 ~ 150 MB/s 수준
    • 평균 Latency: 10 ~ 30 ms (밀리초)

    역시 HDD는 랜덤 I/O 성능이 많이 떨어지는 것을 볼 수 있습니다. 순차 I/O는 그나마 괜찮은 편이지만, 현대적인 가상화 환경에서는 부족함이 많죠.

    SSD OSD 성능 결과

    • 랜덤 읽기/쓰기 IOPS: 10,000 ~ 20,000 IOPS 수준 (HDD 대비 10배 이상!)
    • 순차 읽기/쓰기 Throughput: 400 ~ 500 MB/s 수준
    • 평균 Latency: 0.5 ~ 1 ms (밀리초)

    결과는 압도적이었습니다. 특히 랜덤 I/O 성능에서는 HDD와 비교할 수 없는 수준을 보여줬습니다. Latency 또한 매우 낮아서, 가상 머신이나 데이터베이스처럼 지연 시간에 민감한 워크로드에 SSD OSD가 얼마나 중요한지 다시 한번 깨달았네요.

    Proxmox Ceph 스토리지 HDD vs SSD 성능 벤치마크 결과 그래프 (IOPS, Throughput, Latency 비교)

    FIO 벤치마크를 통해 얻은 HDD OSD와 SSD OSD의 IOPS, Throughput, Latency 비교 그래프입니다.

    지표 HDD OSD (대략적) SSD OSD (대략적) 비고
    랜덤 I/O IOPS 500 ~ 1,000 10,000 ~ 20,000 SSD가 약 10~20배 우위
    순차 I/O Throughput 80 ~ 150 MB/s 400 ~ 500 MB/s SSD가 약 3~5배 우위
    평균 Latency 10 ~ 30 ms 0.5 ~ 1 ms SSD가 훨씬 낮은 지연 시간

    마무리하며: Ceph 스토리지, 현명한 선택을 위한 가이드

    이번 벤치마크로 HDD와 SSD의 성능 차이가 정말 큰 걸 다시 한번 느꼈습니다. 특히 가상화 환경에서 VM을 운영하거나, 데이터베이스, 웹 서비스 등 랜덤 I/O가 많고 지연 시간에 민감한 서비스에는 SSD OSD가 필수라는 결론을 내릴 수 있어요.

    물론 HDD OSD도 장점이 있습니다. 단위 용량당 가격이 저렴해서 대용량 아카이빙(Archiving) 스토리지, 백업(Backup) 스토리지, 또는 순차 I/O 위주의 워크로드에는 여전히 좋은 선택이 될 수 있거든요. 하지만 고성능을 요구하는 메인 스토리지로는 이제 SSD를 대체하기 어렵습니다. 예산과 서비스의 목적에 맞춰서 현명하게 디스크를 선택하는 것이 중요하겠죠.

    저도 이번 벤치마크를 진행하면서 많은 걸 배웠습니다. 특히 네트워크의 중요성이나 FIO 설정의 디테일까지 다시 한번 되새기게 되었네요. 다음번에는 NVMe SSD로 OSD를 구성해서 성능이 얼마나 나올지, 그리고 WAL/DB를 분리했을 때의 효과는 어떨지 한번 파헤쳐 볼까 합니다. 기대해주세요! 🎉

    Ceph 스토리지 HDD vs SSD OSD 장단점 및 활용 시나리오 요약 인포그래픽

    Ceph 스토리지에서 HDD와 SSD OSD의 장단점 및 각각의 활용 시나리오를 요약한 인포그래픽입니다.

  • [Proxmox] Proxmox LXC 컨테이너 보안 강화 체크리스트: 프로덕션 필수 설정

    [Proxmox] Proxmox LXC 컨테이너 보안 강화 체크리스트: 프로덕션 필수 설정

    Proxmox LXC 컨테이너 보안 강화 체크리스트: 프로덕션 필수 설정

    안녕하세요, 13년차의 서버실 주인장입니다. 오늘은 제가 홈랩에서, 그리고 실제 프로덕션 환경에서 Proxmox LXC 컨테이너를 운영하면서 뼈저리게 느꼈던 보안 강화에 대한 이야기를 해보려고 합니다. Proxmox LXC는 가볍고 빠르며 효율적이라서 저도 정말 애용하는 기술 스택인데요. 근데 이 편리함 뒤에는 간과하기 쉬운 보안 위협이 숨어있다는 사실, 혹시 알고 계셨나요? ⚠️

    처음에는 LXC가 워낙 가볍고 VM(Virtual Machine)만큼 복잡하지 않으니까, ‘이 정도면 괜찮겠지?’ 하고 안일하게 생각했던 적도 있습니다. 하지만 몇 번의 삽질과 실제 보안 사고(아찔한 순간이었죠… 휴)를 겪으면서, 컨테이너 환경도 강력한 보안 대책이 필수적이라는 것을 깨달았죠. 특히 프로덕션 환경에서는 더더욱 그렇습니다.

    오늘은 제가 직접 해보고 효과를 본 Proxmox LXC 컨테이너 보안 강화 체크리스트와 베스트 프랙티스를 여러분께 멘토처럼 알려드릴게요. 저처럼 삽질하지 마시라고, 제가 겪었던 시행착오와 해결 과정까지 솔직하게 공유해드리겠습니다! 자, 그럼 시작해볼까요? 🎉

    Proxmox LXC 컨테이너 보안 강화를 위한 주요 구성 요소를 보여주는 개요 다이어그램

    Proxmox LXC 컨테이너 환경에서 보안 강화를 위한 주요 구성 요소와 상호작용을 보여주는 다이어그램입니다.

    1. LXC 컨테이너, 왜 보안이 중요할까요? (개념 설명)

    Proxmox VE (Virtual Environment)에서 LXC (Linux Containers)는 도커(Docker) 컨테이너와 VM의 중간 지점에 있다고 생각하시면 편합니다. VM처럼 완벽한 격리는 아니지만, 도커보다는 더 OS에 가까운 환경을 제공하죠. 호스트 OS의 커널을 공유하기 때문에 가상화 오버헤드가 적고 성능이 좋습니다. 하지만 바로 이 커널 공유 때문에 보안에 취약점이 생길 수 있습니다.

    만약 하나의 LXC 컨테이너가 해킹당하면, 공격자가 호스트 OS의 커널에 접근할 수 있는 경로를 확보하게 될 수도 있습니다. 이는 곧 다른 컨테이너나 심지어 호스트 시스템 전체까지 위험에 빠뜨릴 수 있다는 뜻이거든요. 그래서 LXC 컨테이너는 VM만큼은 아니더라도, 최소한의 보안 장치들을 꼭 마련해두는 것이 좋습니다. 제가 처음 이걸 알았을 때, 등골이 오싹했더랬죠.

    2. 실전 구현: Proxmox LXC 보안 강화 체크리스트

    자, 이제 실질적으로 어떤 작업을 해야 하는지 단계별로 살펴보겠습니다. 제가 직접 구축하면서 가장 효과적이라고 느꼈던 방법들 위주로 구성했어요.

    2.1. ✅ Unprivileged 컨테이너 사용 (권한 분리)

    가장 기본 중의 기본입니다. Unprivileged container (비특권 컨테이너)는 컨테이너 내부의 root 사용자가 호스트 시스템의 root 권한을 가지지 못하도록 격리하는 방식입니다. 이게 핵심이에요. 만약 컨테이너가 Compromise (침해)되더라도, 공격자가 호스트 시스템에 직접적인 root 권한을 행사하기 어렵게 만드는 거죠.

    새 LXC 컨테이너를 생성할 때 Proxmox UI에서 ‘Unprivileged container’ 옵션을 체크하거나, CLI에서는 --unprivileged 1 옵션을 추가하면 됩니다. 저는 주로 CLI로 작업하기 때문에 다음과 같이 명령어를 사용합니다.

    pct create 101 local:vztmpl/debian-11-standard_11.0-1_amd64.tar.zst \
      --hostname my-secure-lxc \
      --password mysecretpassword \
      --memory 512 --swap 512 \
      --rootfs local-lvm:8 \
      --unprivileged 1 # 여기가 중요!

    이렇게 컨테이너를 생성하면 Proxmox가 자동으로 UID/GID 매핑 설정을 해줍니다. /etc/subuid와 /etc/subgid 파일에 호스트 시스템의 사용자 ID와 그룹 ID를 컨테이너 내부의 ID에 매핑하는 규칙이 추가되죠. 처음엔 이게 뭔가 싶었는데, 결국 호스트와 컨테이너 간의 권한 분리 장치더라고요.

    2.2. ✅ AppArmor 프로파일 적용 (강제적 접근 제어)

    AppArmor (앱아머)는 Linux 커널의 MAC (Mandatory Access Control, 강제적 접근 제어) 보안 시스템 중 하나입니다. 특정 프로그램이 접근할 수 있는 파일, 네트워크 리소스 등을 미리 정의된 프로파일에 따라 제한합니다. 쉽게 말해, ‘이 프로그램은 딱 이것만 할 수 있어!’라고 미리 정해주는 거죠.

    Proxmox는 기본적으로 LXC 컨테이너에 AppArmor 프로파일을 적용하지만, 더 세밀하게 제어하고 싶을 때가 있습니다. 예를 들어, 웹 서버 컨테이너가 불필요한 시스템 파일에 접근하는 것을 막는 것이죠.

    현재 AppArmor 상태는 다음 명령어로 확인할 수 있습니다.

    sudo aa-status

    특정 컨테이너나 서비스에 대한 커스텀 AppArmor 프로파일을 작성하여 /etc/apparmor.d/ 디렉토리에 넣고, sudo apparmor_parser -r /etc/apparmor.d/my-lxc-profile 명령어로 로드하면 됩니다. 제가 예전에 특정 서비스가 계속 죽어서 살펴보니, AppArmor 프로파일 때문에 필요한 파일에 접근을 못 하고 있더라고요. aa-complain 모드로 변경해서 로그를 보면서 디버깅했던 기억이 납니다.

    2.3. ✅ UFW를 이용한 네트워크 방화벽 설정

    컨테이너 내부에서도 방화벽을 설정하는 것은 정말 중요합니다. UFW (Uncomplicated Firewall)는 iptables의 복잡한 규칙들을 좀 더 쉽게 관리할 수 있게 해주는 도구입니다. LXC 컨테이너 내부에서 UFW를 설치하고 활성화하여, 필요한 포트만 외부에 노출하도록 설정할 수 있습니다.

    # 컨테이너 내부에서 실행
    sudo apt update
    sudo apt install ufw -y
    sudo ufw enable
    sudo ufw default deny incoming # 기본적으로 모든 외부 접근 차단
    sudo ufw allow ssh # SSH (22번 포트) 허용
    sudo ufw allow http # HTTP (80번 포트) 허용
    sudo ufw allow https # HTTPS (443번 포트) 허용
    sudo ufw status verbose

    이렇게 설정하면 컨테이너 내부에서 불필요한 포트가 열려 외부 공격에 노출되는 것을 방지할 수 있습니다. 혹시 LXC 안에서 서비스가 안 열려서 헤매신 적 있나요? 거의 십중팔구 UFW나 iptables 때문일 겁니다. 💡

    LXC 컨테이너 내부에서 UFW 명령어를 사용하여 네트워크 방화벽 규칙을 설정하고 확인하는 CLI 화면

    LXC 컨테이너 내부에서 UFW 명령어를 사용하여 네트워크 방화벽 규칙을 설정하고 확인하는 CLI 화면입니다.

    2.4. ✅ 정기적인 시스템 업데이트 및 패치

    너무 당연한 이야기 같지만, 잊지 않고 꾸준히 해야 할 가장 기본적인 보안 수칙입니다. OS와 설치된 모든 패키지를 최신 상태로 유지하여 알려진 취약점을 제거해야 합니다. 저는 unattended-upgrades를 설정해서 자동으로 업데이트되도록 해두는 편입니다. 물론 중요한 서비스는 수동으로 확인하고 적용하지만요.

    # 컨테이너 내부에서 실행
    sudo apt update && sudo apt upgrade -y
    
    # 자동 업데이트 설정 (옵션)
    sudo apt install unattended-upgrades -y
    sudo dpkg-reconfigure --priority=low unattended-upgrades

    2.5. ✅ SSH 보안 강화

    컨테이너에 접근하는 주요 방법 중 하나가 SSH입니다. SSH 보안을 강화하는 것은 컨테이너 전체의 보안을 높이는 데 큰 역할을 합니다.

    • 비밀번호 대신 키 기반 인증 사용: 가장 강력한 방법입니다.
    • 기본 SSH 포트 변경 (22번 외 다른 포트): 기본적인 스캐닝 공격을 회피할 수 있습니다.
    • Root 로그인 비활성화: PermitRootLogin no 설정.
    • 강력한 비밀번호 정책: (비밀번호 인증을 사용해야 할 경우)

    /etc/ssh/sshd_config 파일을 수정하여 위 항목들을 적용할 수 있습니다. 변경 후에는 꼭 sudo systemctl restart sshd 명령어로 SSH 서비스를 재시작해주세요.

    2.6. ✅ 로깅 및 모니터링

    아무리 보안을 강화해도 100% 완벽할 수는 없습니다. 중요한 것은 이상이 발생했을 때 얼마나 빨리 알아차리고 대응하느냐입니다. 컨테이너 내부의 로그를 중앙 집중식으로 관리하고, 주요 지표들을 모니터링하는 시스템을 구축하는 것이 좋습니다.

    • syslog-ng 또는 rsyslog 설정: 호스트 또는 별도의 로깅 서버로 로그를 전송.
    • Prometheus + Grafana: CPU, 메모리, 네트워크 트래픽 등 리소스 사용량과 서비스 상태 모니터링.
    • Fail2ban: SSH 무차별 대입 공격(Brute-force attack)과 같은 침입 시도를 자동으로 차단.

    물론 이 모든 걸 한 번에 다 하기는 어렵겠지만, 중요한 서비스부터 차근차근 적용해보는 것이 좋습니다. 제가 처음 홈랩을 구성할 때 로깅과 모니터링을 소홀히 했다가, 나중에 문제 터지고 나서야 뒤늦게 붙잡고 후회했던 적이 많거든요. 😅

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

    위에서 말씀드린 내용을 적용하다 보면 분명히 문제가 발생할 수 있습니다. 저도 그랬거든요. 몇 가지 흔한 문제와 해결 방법을 공유해 드릴게요.

    • UID/GID 매핑 오류로 인한 컨테이너 시작 실패:

      • 증상: 컨테이너가 시작되지 않거나, 내부에서 파일 권한 문제로 서비스가 실행되지 않습니다. lxc-start 로그를 보면 Operation not permitted 같은 에러가 보입니다.
      • 해결: /etc/subuid와 /etc/subgid 파일에 올바른 매핑이 설정되어 있는지 확인합니다. pct create 시 --unprivileged 1 옵션을 제대로 사용했는지도 중요하고요. 이미 생성된 컨테이너라면 /etc/pve/lxc/VMID.conf 파일의 lxc.idmap 설정을 확인해야 합니다. 제가 이걸로 반나절을 날린 적이 있습니다.
    • AppArmor 프로파일로 인한 서비스 장애:

      • 증상: 특정 서비스가 AppArmor 정책 때문에 필요한 파일에 접근하지 못해 실행되지 않거나 비정상적으로 종료됩니다.
      • 해결: sudo aa-status로 AppArmor 상태를 확인하고, 문제가 되는 프로파일을 sudo aa-complain /etc/apparmor.d/my-lxc-profile 명령어로 complain 모드로 변경합니다. 이 모드에서는 정책 위반 시 로그만 남기고 차단하지 않으므로, 로그를 확인하여 필요한 접근 권한을 프로파일에 추가한 후 다시 sudo aa-enforce로 enforce 모드로 전환합니다.
    • UFW 포트 블로킹으로 인한 서비스 접근 불가:

      • 증상: 분명히 서비스는 실행 중인데 외부에서 접근이 안 됩니다.
      • 해결: 컨테이너 내부에서 sudo ufw status verbose 명령어로 현재 UFW 규칙을 확인합니다. 필요한 포트가 ALLOW 되어 있는지 확인하고, 만약 막혀있다면 sudo ufw allow [PORT] 명령어로 허용해줍니다.

    4. 검증 및 결과 확인

    보안 설정을 마쳤다면, 제대로 적용되었는지 확인하는 과정이 필수입니다.

    1. 컨테이너 권한 확인:

      # 호스트에서 실행
      lxc-info -n VMID -p

      lxc.idmap 설정이 올바르게 되어 있고, unprivileged 컨테이너로 생성되었는지 확인합니다.

    2. AppArmor 상태 확인:

      # 호스트에서 실행
      sudo aa-status

      적용된 프로파일이 enforce 모드로 잘 동작하는지 확인합니다.

    3. UFW 방화벽 규칙 확인:

      # 컨테이너 내부에서 실행
      sudo ufw status verbose

      필요한 포트만 열려 있고, 나머지는 잘 차단되어 있는지 확인합니다.

    4. 외부 포트 스캔:

      # 외부 시스템에서 실행 (예: 공격자 시점)
      nmap -sV -p- [LXC_컨테이너_IP]

      실제 외부에서 접근했을 때 불필요한 포트가 열려있지 않은지 nmap 같은 도구로 스캔해보는 것도 좋은 방법입니다. 저는 이 과정을 통해 ‘드디어 됐다!’ 하는 뿌듯함을 느꼈습니다. 😄

    LXC 컨테이너 보안 설정 완료 후 nmap 스캔 결과 및 AppArmor 상태를 보여주는 대시보드

    LXC 컨테이너 보안 설정이 완료된 후, nmap 스캔을 통해 열린 포트를 확인하고 AppArmor 상태를 점검하는 결과 화면입니다.

    5. 마무리하며: 지속적인 관심이 중요합니다

    오늘은 Proxmox LXC 컨테이너의 보안을 강화하기 위한 핵심 체크리스트를 저의 경험을 녹여가며 알려드렸습니다. Unprivileged 컨테이너, AppArmor, UFW, 정기 업데이트, SSH 보안 강화, 로깅 및 모니터링까지, 이 여섯 가지만 잘 지켜도 여러분의 LXC 컨테이너는 훨씬 더 안전해질 겁니다. 🛡️

    사실 보안은 한 번 설정하고 끝나는 것이 아니라, 지속적인 관심과 관리가 필요한 영역입니다. 새로운 취약점은 계속해서 발견되고, 공격 기술도 진화하거든요. 그러니 늘 최신 보안 동향에 귀 기울이고, 여러분의 시스템을 꾸준히 점검해주시길 바랍니다.

    다음 글에서는 LXC 컨테이너 환경에서 SELinux (Security-Enhanced Linux) 적용 방안이나, IDS/IPS (침입 탐지/방지 시스템)를 구축하는 방법에 대해 좀 더 깊이 있게 다뤄볼까 합니다. 혹시 궁금한 점이나 ‘이런 내용도 다뤄줬으면 좋겠다!’ 하는 아이디어가 있다면 언제든지 댓글로 남겨주세요! 여러분의 안전하고 튼튼한 서버실을 응원합니다. 💪

    Proxmox LXC 컨테이너 보안 강화를 위한 주요 체크리스트 항목들을 시각적으로 요약한 인포그래픽입니다.

  • [Proxmox] Proxmox 보안 강화: 1년 운영 후 발견한 취약점과 대응책

    [Proxmox] Proxmox 보안 강화: 1년 운영 후 발견한 취약점과 대응책

    Proxmox 보안 강화: 1년 운영 후 발견한 취약점과 대응책

    안녕하세요! 13년차 인프라 엔지니어, ’13년차의 서버실’입니다. 홈랩을 운영하면서 가장 신경 쓰는 부분이 보안인데요. Proxmox VE(Virtual Environment)를 1년 넘게 운영하다 보니, 예상치 못한 보안 취약점들을 발견하고 대응했던 경험들을 공유해드릴까 합니다. 여러분의 소중한 홈랩 환경을 더 안전하게 지키는 데 도움이 되길 바랍니다! 🚀

    Proxmox VE는 정말 강력한 오픈소스 가상화 플랫폼이지만, 인터넷에 직접 노출되거나 설정을 잘못하면 보안에 취약해질 수 있거든요. 저도 처음에는 기능에만 집중하다가, 운영 중에 몇 가지 아찔한 순간들을 겪었어요. 그래서 오늘은 제가 Proxmox를 1년 운영하면서 겪었던 실제 보안 이슈들과, 이를 해결하기 위해 적용했던 구체적인 대응책들을 말이에요, 멘토처럼 차근차근 알려드릴게요.

    Proxmox VE, 왜 보안이 중요할까요?

    Proxmox VE는 단순히 가상 머신(VM)이나 컨테이너(LXC)를 운영하는 것을 넘어, 네트워크, 스토리지, 고가용성(High Availability) 등 다양한 인프라 기능을 제공합니다. 이렇게 강력한 기능을 가진 만큼, **잘못 관리하면 외부 공격자에게 시스템 전체를 장악당할 위험**이 있습니다. 특히 홈랩 환경은 비용 절감을 위해 상용 보안 솔루션보다는 오픈소스 솔루션을 활용하는 경우가 많은데, 이럴수록 기본적인 보안 설정이 더 중요해지더라고요. 집 현관문에 튼튼한 자물쇠를 다는 것처럼 말이에요! 💡

    1. SSH 접근 보안: 무차별 대입 공격(Brute-force Attack) 방어

    가장 먼저 마주칠 수 있는 보안 위협은 SSH(Secure Shell)를 통한 무차별 대입 공격입니다. Proxmox VE의 관리 인터페이스(Web UI)는 기본적으로 SSH 접속을 허용하고 있는데요. 외부에서 IP 주소를 알게 되면, 공격자는 ID와 비밀번호를 무작위로 대입하여 침투를 시도할 수 있습니다. 저도 처음에는 별다른 설정 없이 사용하다가, 비정상적인 로그인 시도 로그를 발견하고 깜짝 놀랐어요. 😨

    대응책: Fail2ban 설정으로 자동 차단

    이 문제를 해결하기 위해 Fail2ban이라는 정말 유용한 도구를 설정했습니다. Fail2ban은 로그 파일을 모니터링하다가, 특정 횟수 이상 로그인 실패 같은 비정상적인 활동이 감지되면 해당 IP 주소를 자동으로 차단해주거든요. Proxmox VE에 Fail2ban을 설정하는 것도 어렵지 않아요.

    1. SSH 서비스 설정 확인: Proxmox VE의 SSH 서비스가 활성화되어 있는지 확인합니다. 보통 기본적으로 활성화되어 있어요.
    2. Fail2ban 설치: Proxmox VE 노드에 SSH로 접속하여 Fail2ban을 설치합니다.
    apt update && apt install fail2ban -y
    1. Fail2ban 설정 파일 복사 및 수정: 기본 설정 파일(jail.conf)을 복사하여 사용자 설정 파일(jail.local)을 만듭니다.
    cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
    vi /etc/fail2ban/jail.local

    jail.local 파일에서 [sshd] 섹션을 찾아 enabled = true로 설정하고, bantime, findtime, maxretry 등의 값을 조정해서 공격 시도를 얼마나 오랫동안, 몇 번까지 허용할지 결정해요. 저는 보안을 강화하기 위해 maxretry를 낮게 설정하고, bantime을 길게 설정했어요. 예를 들어, 5번 실패하면 1시간 동안 차단하는 식이죠.

    Fail2ban 설정 파일: Proxmox SSH 보안 강화를 위한 SSHD 섹션

    설정 후에는 Fail2ban 서비스를 재시작해야 적용돼요. systemctl restart fail2ban 명령어를 사용하면 됩니다. 이후에는 비정상적인 로그인 시도가 확 줄어든 것을 로그를 통해 확인할 수 있었어요. 정말 든든하더라고요! ✅

    2. Web UI 접근 보안: HTTPS 필수 적용 및 인증서 관리

    Proxmox VE의 웹 인터페이스는 매우 편리하지만, HTTP(Hypertext Transfer Protocol)로 접속하면 모든 통신 내용이 암호화되지 않아 중간자 공격(Man-in-the-Middle Attack)에 취약해져요. 계정 정보나 중요한 설정들이 평문으로 오갈 수 있다는 뜻이죠. 😱

    대응책: Let’s Encrypt를 이용한 자동 HTTPS 설정

    이 문제를 해결하기 위해 **HTTPS(Hypertext Transfer Protocol Secure)**를 적용하는 것은 필수입니다. 다행히 Proxmox VE는 Let’s Encrypt 같은 무료 SSL/TLS 인증서를 쉽게 적용할 수 있도록 지원하거든요. 저도 홈랩 환경에서 Let’s Encrypt를 사용하여 Proxmox 웹 UI에 HTTPS를 적용했는데, 정말 간단했어요.

    1. DNS 설정: Proxmox VE 서버의 FQDN(Fully Qualified Domain Name)이 외부에서 접근 가능한 DNS 레코드를 가지고 있어야 해요. 예를 들어, pve.mydomain.com처럼요.
    2. Proxmox VE 인증서 설정: Proxmox VE의 관리자 페이지에서 ‘Datacenter’ > ‘ACME’ 메뉴로 이동합니다.
    3. ACME 설정: ‘Enable ACME’를 체크하고, ‘DNS API Plugin’을 선택합니다. 어떤 DNS API 플러그인을 사용할지는 여러분의 도메인 등록 업체에 따라 선택하면 돼요. (예: Cloudflare, GoDaddy 등)
    4. API 키 입력: 선택한 DNS API 플러그인에 필요한 API 키를 입력합니다.
    5. 인증서 발급 및 적용: ‘Register and Renew’ 버튼을 클릭하면 Let’s Encrypt에서 인증서를 발급받아 자동으로 적용해줘요.
    Proxmox VE ACME 설정: Let's Encrypt를 이용한 자동 HTTPS 구성 화면

    이렇게 설정하면 Proxmox 웹 UI에 접속할 때 자동으로 HTTPS가 적용되어 브라우저 주소창에 자물쇠 아이콘이 표시돼요. 🔒 이제 안심하고 관리할 수 있게 되었죠. 주기적으로 인증서가 갱신되니까 수동 관리 부담도 없어요. 🎉

    3. 방화벽(Firewall) 설정: 불필요한 포트 차단

    Proxmox VE는 자체적으로 강력한 방화벽 기능을 제공합니다. 하지만 이 기능을 제대로 활용하지 않으면, 외부에서 시스템의 모든 포트에 접근할 수 있게 되어 보안에 매우 취약해져요. 마치 집 문을 열어두고 사는 것과 마찬가지죠. 😅

    대응책: 노드 및 VM/LXC별 방화벽 규칙 설정

    저는 Proxmox VE의 **내장 방화벽**을 적극적으로 활용합니다. **노드(Node)** 자체에 대한 방화벽 규칙과, 각 **가상 머신(VM) 및 컨테이너(LXC)**에 대한 방화벽 규칙을 별도로 설정할 수 있다는 점이 정말 유용해요.

    • 노드 방화벽: Proxmox VE 노드 자체에 대한 접근을 제어합니다. 예를 들어, SSH(22번 포트)나 웹 UI(8006번 포트)는 신뢰할 수 있는 IP 대역에서만 접속하도록 설정할 수 있어요.
    • VM/LXC 방화벽: 각 가상 환경별로 필요한 포트만 열어줍니다. 웹 서버 VM이라면 80번(HTTP)과 443번(HTTPS) 포트만 외부에서 접근 가능하도록 허용하고, 나머지 포트는 모두 차단하는 식이죠.

    방화벽 규칙은 Proxmox VE 웹 UI에서 ‘Datacenter’ > ‘Firewall’ 메뉴나, 각 노드, VM/LXC 개별 설정에서 쉽게 관리할 수 있어요. ‘Add’ 버튼을 눌러 Source, Destination, Protocol, Port 등을 지정하여 규칙을 추가하면 됩니다. **’Default policy’를 ‘DROP’으로 설정하고 필요한 포트만 ‘ACCEPT’하는 것이 가장 안전한 방법**입니다. 처음에는 조금 복잡하게 느껴질 수 있지만, 한번 설정해두면 보안 수준이 정말 달라져요. 💯

    Proxmox VE 방화벽 규칙 설정: 특정 포트 허용 및 차단 예시

    간혹 방화벽 설정 때문에 VM 내부의 서비스에 접속이 안 되는 경우가 생기는데요. 이때는 해당 VM/LXC의 방화벽 설정에서 필요한 포트가 제대로 열려 있는지, 그리고 Proxmox 노드의 방화벽 정책과 충돌하는 부분은 없는지 꼼꼼히 확인해야 해요. 정말 ‘삽질’ 좀 했습니다 ㅎㅎ 😅

    4. Proxmox VE 업데이트 및 패치 관리

    아무리 훌륭한 보안 설정이라도, 소프트웨어 자체에 알려진 취약점이 있으면 무용지물이 될 수 있어요. Proxmox VE는 오픈소스인 만큼 커뮤니티를 통해 빠르게 보안 취약점이 발견되고 패치가 이루어지는 편이지만, 사용자가 직접 업데이트를 적용해야 합니다.

    대응책: 정기적인 업데이트 및 패치 적용

    저는 **최소한 한 달에 한 번은 Proxmox VE의 업데이트를 확인하고 적용**하려고 노력해요. 업데이트는 Proxmox VE 웹 UI의 ‘Updates’ 메뉴에서 쉽게 확인할 수 있으며, ‘Upgrade’ 버튼을 눌러 진행하면 됩니다.

    # 또는 CLI에서 업데이트 확인 및 적용
    apt update
    apt dist-upgrade -y

    업데이트 전에 **중요한 VM이나 컨테이너는 백업**해두는 것이 좋아요. 만일의 사태에 대비하려고요. 저도 몇 번 업데이트 과정에서 문제가 발생했던 경험이 있어서, 이제는 업데이트 전 백업을 무조건 합니다.

    Proxmox VE 업데이트는 단순히 기능 개선뿐만 아니라, **보안 패치**를 포함하는 경우가 많거든요. 꾸준히 적용하는 것이 정말 중요합니다. 최신 보안 상태를 유지하는 가장 확실한 방법이니까요. ✅

    마무리하며: 보안은 지속적인 관심이 중요합니다

    지금까지 Proxmox VE를 1년 운영하면서 발견했던 보안 취약점들과 그 대응책에 대해 이야기해 봤습니다. SSH 보안 강화, HTTPS 적용, 방화벽 설정, 그리고 꾸준한 업데이트까지. 이 네 가지는 Proxmox VE 환경의 보안을 튼튼하게 만드는 데 정말 핵심적인 역할을 합니다.

    홈랩은 취미로 시작했지만, 소중한 데이터가 오가는 공간이 될 수도 있고, 때로는 외부와 연결되는 중요한 역할을 하기도 해요. 따라서 **보안은 한 번 설정하고 끝나는 것이 아니라, 지속적으로 관심을 가지고 관리해야 하는 영역**이라는 점을 꼭 기억해주셨으면 합니다.

    오늘 공유해 드린 내용들이 여러분의 Proxmox VE 환경을 더욱 안전하게 만드는 데 도움이 되었으면 좋겠어요. 다음 글에서는 더욱 흥미로운 홈랩 구축 이야기나, 새로운 기술 트러블슈팅 경험으로 찾아뵙겠습니다. 감사합니다! 😊