13년차의 서버실

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

[태그:] 서버실

  • [HomeLabs] GMKtec 미니PC 6개월 사용기: 기대와 현실 사이

    [HomeLabs] GMKtec 미니PC 6개월 사용기: 기대와 현실 사이

    목차

    [미니PC 사용기] GMKtec 6개월 사용 후 느낀 점: 기대와 현실 사이

    안녕하세요, 13년차 서버실 지기입니다. 오늘은 제가 6개월간 홈랩에서 굴려본 GMKtec 미니PC 사용기를 풀어볼까 합니다. 작은 고추가 맵다고, 미니PC가 인프라 엔지니어의 로망을 얼마나 채워줄 수 있을까요? 특히 GMKtec 같은 가성비 좋은 제품들은 저 같은 홈랩 운영자들에게 큰 유혹이거든요. 처음엔 ‘이 작은 게 뭘 할 수 있겠어?’ 싶었는데, 막상 써보니 기대와 현실 사이에서 꽤 많은 걸 느끼게 되더라고요. 삽질의 연속이었지만, 솔직한 후기를 공유해 드릴게요. 여러분의 가성비 미니PC 선택에 도움이 되길 바랍니다.

    홈랩 환경에 설치된 GMKtec 미니PC의 전체 모습

    홈랩 환경에 설치된 GMKtec 미니PC의 전체적인 모습입니다. 작지만 강력한 잠재력을 가지고 있죠.

    GMKtec 미니PC, 과연 무엇을 기대했나?

    GMKtec은 요즘 가성비 좋은 미니PC 시장에서 두각을 나타내는 브랜드예요. 주로 인텔 N 시리즈 프로세서나 AMD 라이젠 저전력 모델을 탑재하고 나오죠. 이 작은 상자 하나가 데스크톱 PC의 기능을 거의 다 하면서도 전력 소모가 적고 공간도 적게 차지하니, 저 같은 인프라 엔지니어들에게는 홈랩 서버(Home Lab Server), 개발용 머신, 거실의 미디어 서버(HTPC)로도 정말 매력적인 선택지거든요.

    저는 이 GMKtec 미니PC를 다음과 같은 용도로 활용할 계획이었습니다:

    특히 GMKtec 미니PC 후기들을 찾아보니, 이 가격대에 이 정도 성능이면 ‘가성비 끝판왕’이라는 평이 많았어요. 기대감이 확 올라갔죠.

    실전 활용: GMKtec 미니PC에 Ubuntu Server와 Docker 올리기

    저는 GMKtec 미니PC를 홈랩의 핵심 서버 중 하나로 활용했습니다. 주로 Home Assistant를 돌리고, 그 외에 Docker 컨테이너들을 올려서 네트워크 서비스를 제공하는 용도였죠. 운영체제(OS)는 가벼우면서도 안정적인 Ubuntu Server (우분투 서버)를 선택했습니다. 처음엔 Proxmox VE (프록스목스)로 가상화 환경을 구성할까도 했는데, 미니PC는 자원이 한정적이라 최대한 오버헤드(Overhead)를 줄이는 게 낫겠더라고요.

    설치는 간단해요. USB에 우분투 서버 이미지를 구워서 부팅하고, 몇 가지 설정만 해주면 끝이죠. 저는 터미널(Terminal)에 익숙해서 CLI(Command Line Interface)로 빠르게 진행했습니다. Docker를 설치해서 컨테이너 기반으로 서비스를 올리는 게 요즘 대세잖아요? 저도 그렇게 구성했어요.

    # 시스템 업데이트 및 업그레이드
sudo apt update && sudo apt upgrade -y

# Docker 및 Docker Compose 설치
sudo apt install docker.io docker-compose -y

# 현재 사용자에게 docker 그룹 권한 추가 (재부팅 또는 재로그인 필요)
sudo usermod -aG docker $USER
newgrp docker # 현재 세션에 적용

    이렇게 설치하고 나면 docker run hello-world 같은 명령어로 잘 동작하는지 확인할 수 있어요. 간단하죠? ✅ 이제 원하는 서비스를 Docker 컨테이너로 올려서 사용하면 됩니다.

    GMKtec 미니PC에서 실행 중인 Docker 컨테이너와 서비스 대시보드

    GMKtec 미니PC에서 Docker 컨테이너로 Home Assistant와 Pi-hole이 잘 실행되고 있는 모습입니다.

    삽질 경험: 기대했던 GMKtec 성능과 현실 사이의 간극

    솔직히 GMKtec 미니PC를 처음 받았을 때는 ‘이 정도면 차고 넘치겠는데?’ 싶었어요. 근데 막상 이것저것 올리고 6개월 정도 굴려보니, 역시 기대와 현실 사이엔 간극이 있더라고요. 가장 크게 느낀 점은 지속적인 부하(Sustained Load)에서의 성능이었습니다.

    처음엔 Home Assistant나 Pi-hole 정도는 가볍게 돌렸어요. CPU 사용률도 낮고 전력 소모도 착했죠. 하지만 여기에 Grafana, Prometheus 같은 모니터링 툴까지 추가하고, 가끔 개발용으로 가상 머신(VM)을 몇 개 더 띄우거나 코드를 컴파일(Compile)하는 작업을 시키면 상황이 달라지더라고요. CPU 온도가 급격히 오르면서 스로틀링(Throttling)이 걸리는 경험을 했습니다. ‘아, 이건 정말 가볍게 쓰는 용도구나’ 싶었죠. 💡

    특히 팬 소음이 신경 쓸 정도더라고요. 평소에는 조용하지만, CPU 사용률이 50%를 넘어가면 ‘위이이잉’ 하는 팬 소리가 제법 들리거든요. 침실 옆에 두면 불편할 정도였습니다. 그리고 저장 공간(Storage) 확장성도 아쉬웠어요. 대부분 M.2 슬롯이 하나뿐이라, OS와 데이터를 같이 쓰다 보면 금방 꽉 차더라고요. 외장 USB SSD를 연결해서 쓰긴 했지만, 아무래도 내부 스토리지만큼 빠르지 않고 전원 문제도 신경 써야 했습니다.

    네트워크도 보통 1기가비트 이더넷(Gigabit Ethernet) 포트가 하나인데, 홈랩에서 여러 서비스를 돌리다 보면 2.5기가비트(2.5Gbps)나 그 이상이 필요할 때가 있거든요. GMKtec 미니PC의 성능을 제대로 활용하려면 이 부분이 아쉬웠죠. RAM도 보통 16GB나 32GB가 최대인데, 여러 Docker 컨테이너나 VM을 돌리기엔 살짝 부족하게 느껴질 때도 있었어요. 저도 그래서 램을 업그레이드할까 하다가, 그냥 다른 저전력 서버를 하나 더 들이는 방향으로 생각하게 되더라고요. 😅

    성능 모니터링과 문제 진단

    그래서 저는 미니PC의 상태를 실시간으로 모니터링하는 데 신경을 많이 썼습니다. 특히 CPU 사용률과 온도 같은 지표는 미니PC의 한계를 파악하는 데 아주 중요하거든요. 리눅스(Linux) 환경에서는 htop이나 lm-sensors 같은 툴을 사용하면 쉽게 확인할 수 있어요.

    # htop 및 lm-sensors 설치 (htop은 프로세스 모니터링, lm-sensors는 온도 센서 정보 제공)
sudo apt install htop lm-sensors -y

# htop으로 시스템 자원 사용량 확인
htop

# 센서 정보 확인 (CPU 온도 등)
sensors

    만약 sensors 명령어로 온도가 안 나온다면 sudo sensors-detect를 실행해서 센서를 잡아줘야 합니다. htop으로 CPU 사용률이 지속적으로 높거나, sensors로 온도가 80도 이상을 계속 찍는다면, ⚠️ 과부하(Overload) 상태예요. 그럼 서비스 수를 줄이거나 더 고사양의 장비를 고려해야 합니다. 미니PC의 GMKtec 성능 한계를 명확히 인지하고 활용하는 것이 정말 중요하죠.

    미니PC의 `htop` 시스템 자원 사용량과 `sensors` CPU 온도 모니터링 화면

    시스템 자원 사용량과 CPU 온도를 실시간으로 모니터링하여 과부하 여부를 판단하는 화면입니다.

    그래서, GMKtec 미니PC는 쓸만한가? 활용 목적별 정리

    그럼 6개월간의 삽질 끝에 내린 결론은 뭐냐고요? GMKtec 미니PC는 ‘어떤 용도로 쓰느냐’에 따라 충분히 쓸만하다는 겁니다. 만능은 아니지만, 특정 목적에는 가성비 최고의 선택지가 될 수 있어요.

    제가 경험한 바를 토대로 활용 목적에 따른 적합도를 표로 정리해 봤습니다.

    활용 목적 (Use Case) 적합도 (Suitability) 설명 (Description)
    홈 어시스턴트 (Home Assistant) ✅ 매우 적합 낮은 전력 소모로 24시간 안정적인 스마트 홈 허브 운영에 최적
    네트워크 서비스 (Pi-hole, Nginx Proxy Manager 등) ✅ 매우 적합 가볍고 리소스 소모가 적은 서비스 구동에 문제 없음
    미디어 서버 (Plex, Jellyfin) 💡 보통 가벼운 트랜스코딩(Transcoding)은 가능하나, 4K 고비트레이트 동시 스트리밍은 제한적
    개발용 머신 / 경량 VM ⚠️ 제한적 단일 개발 환경이나 아주 가벼운 VM 1~2개는 가능. 컴파일/빌드 작업은 느림
    데이터베이스 서버 (MySQL, PostgreSQL) ⚠️ 제한적 소규모 테스트용은 가능하나, 실제 서비스용 고성능 DB는 부적합 (I/O 한계)
    고사양 게임 서버 / 영상 편집 ❌ 부적합 그래픽 성능 및 CPU 파워 부족으로 거의 불가능

    보시다시피, 저전력으로 24시간 켜둬야 하는 서비스나 가벼운 작업용으로는 정말 훌륭해요. 하지만 무거운 작업을 기대하면 실망할 수 있습니다. 딱 그 가격대의 퍼포먼스를 보여주는 제품이라고 생각하시면 됩니다.

    GMKtec 미니PC 장단점 요약 비교 인포그래픽

    GMKtec 미니PC의 주요 장점과 단점을 한눈에 파악할 수 있는 요약입니다.

    마무리: 현명한 미니PC 선택을 위한 조언

    결론적으로, GMKtec 미니PC는 ‘가성비’라는 키워드에 충실한 제품이에요. 하지만 무조건 좋다고는 말할 수 없습니다. 여러분이 어떤 용도로 미니PC를 활용할지 명확하게 정의하는 것이 가장 중요해요.

    만약 저처럼 가벼운 홈랩 서비스나 24시간 저전력으로 돌아가는 시스템을 원하신다면, GMKtec 미니PC는 충분히 매력적인 선택지가 될 겁니다. 특히 미니PC 사용기를 찾아보며 저전력 구동에 초점을 맞추고 계신다면 좋은 대안이죠. 하지만 여러 개의 가상 머신을 돌리거나, 복잡한 개발 환경, 고성능 데이터베이스 등을 생각하신다면 조금 더 투자해서 중고 엔터프라이즈 서버(Enterprise Server)나 직접 조립하는 NUC(Next Unit of Computing) 계열의 고사양 미니PC를 고려해 보시는 게 좋겠습니다.

    저의 6개월 GMKtec 미니PC 사용기가 여러분의 현명한 선택에 도움이 되었으면 좋겠습니다. 다음번엔 제가 또 어떤 장비로 삽질했는지 들고 오겠습니다! 궁금한 점이 있다면 댓글로 남겨주세요! 🎉

  • [Game] 레노버 리전 고 BIOS 업데이트 문제 분석: 벽돌 현상 예방 및 대처법

    [Game] 레노버 리전 고 BIOS 업데이트 문제 분석: 벽돌 현상 예방 및 대처법

    목차

    [인프라 엔지니어의 경험] 레노버 리전 고 BIOS 업데이트, 벽돌 현상 예방과 대처법

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’입니다. 오늘은 많은 분들이 궁금해하시고 또 두려워하시는 주제, 바로 레노버 리전 고(Lenovo Legion Go) BIOS(바이오스) 업데이트 문제에 대한 이야기를 해볼까 합니다. 최근 휴대용 게임 PC들이 인기를 끌면서, 저도 홈랩에서 이것저것 만져보고 있는데요. 성능 향상이나 버그 수정을 위해 펌웨어 업데이트는 필수적이지만, BIOS 업데이트만큼은 늘 조심스럽게 접근하게 되더라고요. 혹시 업데이트하다가 기기가 벽돌(bricked)이 되어버릴까 봐 걱정하신 경험, 다들 있으실 겁니다.

    저도 예전에 서버 BIOS 업데이트하다가 식은땀 흘린 적이 한두 번이 아니거든요. 특히나 레노버 리전 고 같은 휴대용 기기는 일반 데스크톱 PC와는 또 다른 변수가 있어서 더 신경 써야 합니다. 오늘은 제 경험을 바탕으로 레노버 리전 고 BIOS 업데이트 시 발생할 수 있는 문제들을 분석하고, 벽돌 현상을 예방하고 대처하는 현실적인 방법들을 알려드릴게요. 같이 삽질의 흔적을 따라가 보시죠! 💡

    레노버 리전 고 BIOS 업데이트 화면을 불안하게 지켜보는 엔지니어의 모습입니다.

    BIOS(바이오스)는 대체 뭔가요?

    먼저, BIOS가 정확히 무엇인지 간단하게 짚고 넘어갈까요? BIOS(Basic Input/Output System, 기본 입출력 시스템)는 컴퓨터의 가장 기본적인 소프트웨어라고 생각하시면 편합니다. 운영체제가 부팅되기 전에 하드웨어 초기화와 점검을 담당하거든요. 쉽게 말해, 컴퓨터 전원을 켜면 가장 먼저 실행되어서 CPU, 메모리, 저장 장치 같은 핵심 부품들이 제대로 작동하는지 확인하고, 운영체제를 불러올 준비를 하는 친구입니다.

    레노버 리전 고 역시 이 BIOS가 있어야 제대로 부팅이 되고, 장치들이 인식됩니다. 이 BIOS가 손상되면 기기가 부팅되지 않는, 바로 그 ‘벽돌(bricking)’ 현상이 발생하는 거죠. ⚠️

    BIOS 업데이트를 해야 하는 이유: 장점과 위험성

    BIOS 업데이트는 분명 여러 장점이 있습니다. 최신 하드웨어 지원, 성능 최적화, 보안 취약점 패치, 그리고 가끔은 새로운 기능 추가까지! 예를 들어, 특정 게임에서 프레임 저하가 발생했는데, BIOS 업데이트로 안정성이 개선되는 경우도 있거든요. 제가 홈랩에서 돌리는 서버들도 새로운 CPU나 NVMe SSD를 지원하려면 BIOS 업데이트가 필수적인 경우가 많았습니다.

    하지만 장점만큼이나 위험성도 큽니다. 업데이트 과정에서 문제가 생기면 앞서 말했듯이 기기가 벽돌이 되어버릴 수 있죠. 마치 자동차 엔진의 핵심 제어 소프트웨어를 바꾸는 것과 같아서, 잘못하면 시동이 안 걸리는 상황이 올 수 있습니다.

    BIOS 업데이트 실패의 흔한 원인들

    BIOS 업데이트 실패의 원인은 크게 몇 가지로 볼 수 있습니다. 제가 실제로 겪었거나 주변에서 많이 봤던 케이스들이에요.

    1. 갑작스러운 전원 차단: 업데이트 중 정전이 되거나 배터리가 방전되면 치명적입니다. 가장 흔하고 무서운 원인이죠.
    2. 잘못된 펌웨어 파일: 다른 모델의 BIOS를 받거나, 파일이 손상된 경우입니다. 레노버 리전 고는 모델이 하나지만, 혹시 모를 변수(예: 특정 리비전 전용 업데이트)에 대비해야 합니다.
    3. 소프트웨어 충돌: 업데이트 유틸리티가 다른 프로그램과 충돌하거나, 운영체제가 불안정한 경우입니다.
    4. 하드웨어 문제: 드물지만, 업데이트를 진행하는 동안 메모리나 저장 장치에 문제가 생기는 경우도 있습니다.

    벽돌 현상을 예방하는 철저한 준비 과정

    자, 그럼 이런 끔찍한 상황을 막으려면 어떻게 해야 할까요? 제가 13년간 쌓아온 ‘삽질 방지 루틴’을 공유합니다! 🛠️

    1. 충분한 전원 확보: 가장 중요합니다. 레노버 리전 고를 전원 어댑터에 연결하고, 배터리 잔량도 80% 이상인지 확인하세요. 저는 업데이트 중 정전이 될까 봐 UPS(Uninterruptible Power Supply, 무정전 전원 장치)에 연결하고 진행합니다. 휴대용 기기라도 마찬가지입니다.

    2. 정확한 펌웨어 파일 다운로드: 레노버 공식 지원 웹사이트에서 반드시 레노버 리전 고 모델명에 맞는 최신 BIOS 파일을 다운로드해야 합니다. 다른 곳에서 받거나 구버전 파일을 받지 않도록 주의하세요. 파일의 무결성(integrity)을 확인하는 것도 좋습니다. 다운로드 후 제공되는 체크섬(checksum) 값과 비교해보세요. 저는 주로 SHA256 해시 값을 확인합니다.

      # Linux/macOS에서 파일 해시 확인
shasum -a 256 /path/to/your/bios_file.exe

# Windows PowerShell에서 파일 해시 확인
Get-FileHash -Path "C:\path\to\your\bios_file.exe" -Algorithm SHA256

      다운로드 페이지에 이 값이 나와있지 않다면, 최소한 파일 크기라도 한 번 더 확인해보세요.

    3. 실행 중인 모든 프로그램 종료: 백그라운드에서 실행되는 모든 애플리케이션을 닫으세요. 특히 바이러스 백신 프로그램이나 시스템 모니터링 툴은 잠시 비활성화하는 것이 좋습니다.

    4. 중요 데이터 백업: BIOS 업데이트 자체는 데이터에 영향을 주지 않지만, 만약의 사태에 대비해 중요한 파일들은 미리 외장 저장 장치나 클라우드에 백업해두는 것이 좋습니다. 이건 그냥 기본 중의 기본입니다! ✅

    5. 인터넷 연결 끊기: 무선 인터넷이 연결되어 있다면, 업데이트 중 예상치 못한 자동 업데이트나 네트워크 활동으로 인한 오류를 방지하기 위해 잠시 연결을 끊어두세요.

    BIOS 설정 화면은 제조사마다 조금씩 다르지만, 주요 메뉴 구성은 비슷합니다.

    BIOS 업데이트 실패 시 대처법: 벽돌을 살리는 방법

    아무리 조심해도 사고는 일어날 수 있습니다. 만약 레노버 리전 고가 BIOS 업데이트 중 벽돌이 되었다면, 패닉에 빠지지 말고 침착하게 다음 방법들을 시도해보세요. 저도 이런 상황에서 많이 당황했지만, 결국 해결했던 경험들이 있습니다.

    1. BIOS 복구 모드 (BIOS Recovery Mode): 많은 메인보드에는 BIOS 복구 기능이 내장되어 있습니다. 보통 전원을 켜면서 특정 키 조합(예: Fn + R, Ctrl + Esc 등)을 누르거나, USB 드라이브에 특정 이름으로 저장된 BIOS 파일을 넣어 부팅하면 자동으로 복구를 시도합니다. 레노버 리전 고의 경우, 제조사 매�얼이나 지원 페이지를 통해 정확한 복구 방법을 확인하는 것이 중요합니다. 보통은 전원이 꺼진 상태에서 볼륨 업(+) 버튼을 누른 채 전원 버튼을 누르는 등의 방법이 있을 수 있습니다.

    2. CMOS 클리어 (Clear CMOS): BIOS 설정이 꼬여서 부팅이 안 되는 경우, CMOS 설정을 초기화하는 방법이 있습니다. 데스크톱 PC는 메인보드 점퍼를 변경하거나 배터리를 분리하는 방식이지만, 리전 고 같은 휴대용 기기는 내부를 열어야 할 수도 있습니다. ⚠️ 주의: 기기를 분해해야 할 수도 있으므로, 숙련된 사용자만 시도하거나 전문가의 도움을 받는 것이 좋습니다. 보통은 작은 전용 버튼이 있거나, 배터리 옆의 점퍼를 잠시 쇼트시키는 방식입니다.

    3. 서비스 센터 문의: 위 방법들로 해결이 안 된다면, 주저 없이 레노버 서비스 센터에 문의하는 것이 가장 안전하고 확실한 방법입니다. 보증 기간 내라면 무상 수리도 가능할 수 있습니다.

    CMOS 클리어를 위해 레노버 리전 고와 유사한 휴대용 기기의 내부를 여는 모습

    CMOS 클리어를 위해 기기를 조심스럽게 분해하는 모습입니다.

    언제 BIOS 업데이트를 해야 할까요? 결정 가이드

    그럼 언제 BIOS 업데이트를 하는 것이 좋을까요? 무조건 최신 버전이 최고일까요? 제 경험상 항상 그렇지는 않더라고요. 저는 다음과 같은 기준으로 업데이트를 결정합니다.

    BIOS 업데이트 권장 상황 (YES ✅) BIOS 업데이트 보류 상황 (NO ❌)
    새로운 하드웨어(e.g., 고용량 SSD)를 설치했는데 인식 문제가 있을 때 현재 시스템이 안정적으로 잘 작동하고 있을 때
    특정 버그(e.g., 절전 모드 문제, 팬 소음)가 발생하고, BIOS 업데이트가 공식 해결책으로 제시될 때 업데이트 후 알려진 심각한 버그나 성능 저하 이슈가 있을 때
    보안 취약점 패치가 포함된 업데이트가 중요하게 권고될 때 업데이트의 이점이 미미하거나, 단순히 ‘최신’이라는 이유만으로
    성능 개선이 명확하게 명시되어 있고, 해당 개선이 사용자에게 필요할 때 업데이트 과정이 복잡하고, 실패 시 복구 방법이 불확실할 때

    결론적으로, 명확한 필요성이 있을 때만 업데이트를 진행하는 것이 좋습니다. 괜히 멀쩡한 시스템에 손댈 필요는 없다는 거죠. 하지만 BIOS 업데이트가 꼭 필요한 상황이라면, 앞서 말씀드린 예방 조치들을 철저히 지키면서 진행해야 합니다.

    마무리하며: 안전한 업데이트는 철저한 준비에서!

    오늘은 레노버 리전 고 BIOS 업데이트에 대한 제 경험과 노하우를 공유해드렸습니다. BIOS 업데이트는 항상 신중하게 접근해야 하는 작업이지만, 제대로 준비하면 충분히 안전하게 진행할 수 있습니다. 13년차 인프라 엔지니어로서 제가 드릴 수 있는 가장 중요한 조언은 바로 ‘사전 준비의 중요성’입니다. 충분한 전원, 정확한 파일, 그리고 만약의 사태에 대비한 백업과 복구 계획은 아무리 강조해도 지나치지 않습니다.

    여러분의 소중한 레노버 리전 고가 벽돌이 되지 않도록, 오늘 알려드린 팁들을 꼭 기억하시고 적용해보세요. 혹시 더 궁금한 점이나 다른 삽질 경험이 있으시다면 댓글로 공유해주세요. 다음번에는 홈랩에서 제가 겪었던 또 다른 흥미로운 기술 삽질(?) 이야기로 찾아오겠습니다! 안전한 IT 생활하세요! 🎉

    BIOS 업데이트 시 꼭 지켜야 할 사항과 피해야 할 사항을 한눈에 볼 수 있는 요약입니다.

  • [Proxmox] Proxmox ZFS 메모리 사용량 최적화: ARC 캐시 튜닝 전략

    [Proxmox] Proxmox ZFS 메모리 사용량 최적화: ARC 캐시 튜닝 전략

    목차

    Proxmox ZFS 메모리 사용량 최적화: ARC 캐시 튜닝 전략

    안녕하세요, 13년차의 서버실입니다. 오늘은 홈랩이나 작은 서버 환경에서 Proxmox VE와 ZFS를 함께 사용하시는 분들이라면 한 번쯤 겪어보셨을 법한, 바로 메모리 사용량 최적화에 대한 이야기를 해볼까 합니다. 특히 ZFS의 ARC 캐시(Adaptive Replacement Cache) 때문에 램이 부족하다고 느끼는 경우가 많으실 텐데요. 제가 직접 여러 번의 삽질 끝에 찾아낸 ZFS 성능 튜닝 전략을 솔직하게 공유해드리겠습니다. 혹시 Proxmox 서버의 램이 항상 꽉 차 있는 것 같아 답답하셨다면, 이 글이 좋은 해결책이 될 거예요!

    Proxmox VE와 ZFS가 메모리를 사용하는 일반적인 아키텍처 다이어그램

    Proxmox VE와 ZFS가 메모리를 사용하는 일반적인 아키텍처 다이어그램입니다. ARC 캐시가 시스템 메모리에 어떻게 자리 잡는지 보여줍니다.

    ZFS ARC 캐시, 너는 누구니?

    ZFS를 사용하면 스토리지 성능을 극대화하기 위해 ARC 캐시(Adaptive Replacement Cache)라는 똑똑한 녀석이 작동합니다. 쉽게 말해, 자주 접근하는 데이터를 메모리에 미리 올려두어 디스크 I/O를 줄이고 속도를 높여주는 역할을 하죠. 웹 서버의 프록시 캐시나 데이터베이스의 버퍼 캐시와 비슷하다고 생각하시면 됩니다.

    근데 여기서 문제가 발생해요. ZFS는 기본적으로 시스템 메모리의 절반까지 ARC 캐시로 사용하도록 설계되어 있거든요. 예를 들어, 32GB 램을 가진 서버라면 ZFS는 최대 16GB를 ARC 캐시로 끌어다 쓸 수 있다는 거죠. 문제는 Proxmox VE 위에 가상머신(VM)이나 컨테이너(LXC)를 여러 개 돌리다 보면, 이 녀석들도 각자 램을 필요로 한다는 겁니다. 결국 ZFS ARC가 너무 많은 램을 차지해서 VM들이 램 부족에 시달리거나, 스왑(Swap)이 발생해서 전체적인 성능 저하로 이어지는 경우가 허다하더라고요. 저도 처음엔 이게 뭔가 싶었는데, 알고 보니 ARC 캐시가 범인이었죠.

    ARC 캐시, 이제 너를 길들이자!

    그럼 이 똑똑하지만 탐욕스러운 ARC 캐시를 어떻게 길들일 수 있을까요? 핵심은 zfs_arc_max라는 커널 파라미터를 조절하는 거예요. 이 값을 통해 ARC 캐시가 사용할 수 있는 최대 메모리 양을 제한할 수 있습니다. 저도 이 값을 찾기 위해 꽤나 삽질을 했었는데, 몇 번의 시행착오 끝에 안정적인 방법을 찾았으니 너무 걱정 마세요!

    단계별로 차근차근 따라 해보시면 돼요. 중요한 건, 자신의 서버 환경과 워크로드를 고려해서 적절한 값을 찾아야 한다는 점이에요. 무작정 너무 낮게 설정하면 오히려 ZFS 성능이 떨어질 수 있으니 주의해야 합니다.

    1. ZFS 모듈 설정 파일 생성 및 수정:
      /etc/modprobe.d/zfs.conf 파일을 만들거나 수정해서 ARC 캐시의 최대 크기를 설정합니다. 저는 보통 최소 1GB, 최대 4GB 정도로 설정해서 사용하고 있어요. 램이 넉넉하다면 더 여유 있게 잡아도 좋고요. 값은 바이트 단위로 입력해야 합니다. 예를 들어 4GB는 4294967296입니다.

      # /etc/modprobe.d/zfs.conf 파일 생성 또는 편집
sudo nano /etc/modprobe.d/zfs.conf

      options zfs zfs_arc_min=1073741824  # 1GB
options zfs zfs_arc_max=4294967296  # 4GB

      위 예시는 ARC 캐시의 최소 크기를 1GB, 최대 크기를 4GB로 제한하는 설정입니다. zfs_arc_min은 ARC 캐시가 최소한으로 유지할 메모리 양을 지정하며, zfs_arc_max는 ARC 캐시가 최대로 사용할 수 있는 메모리 양을 지정해요.

    2. initramfs 업데이트:
      커널 모듈 설정을 시스템에 적용하려면 initramfs를 업데이트해야 합니다. 이 작업은 재부팅 시 ZFS 드라이버가 새로운 설정값을 가지고 로드되도록 해줍니다.

      sudo update-initramfs -u -k all

    3. 시스템 재부팅:
      모든 변경 사항을 적용하려면 시스템을 재부팅해야 합니다. 재부팅 후에 새로운 ARC 캐시 설정이 적용돼요.

      sudo reboot
    ZFS ARC 캐시 설정을 위해 zfs.conf 파일을 편집하는 터미널 화면

    터미널에서 zfs.conf 파일을 편집하는 모습입니다. 정확한 파라미터 설정을 확인하세요.

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

    제가 처음 이 설정을 만지면서 겪었던 가장 큰 삽질은 zfs_arc_max 값을 너무 낮게 설정한 거였어요. 제 홈랩 서버는 16GB 램을 사용하고 있었고, Proxmox 위에 VM 몇 개랑 Plex 서버까지 돌리느라 램이 항상 부족했거든요. 그래서 욕심이 과해서 ARC 캐시를 512MB(536870912 바이트)로 확 줄여버렸죠. 결과는요? VM들의 디스크 I/O 성능이 눈에 띄게 저하되고, 특히 ZFS 스토리지에 있는 파일들을 읽어올 때 버벅거림이 심해지더라고요. Plex 서버에서 영화를 재생하는데 계속 끊기는 현상까지 발생해서 멘붕이 왔었습니다. 😭

    이 경험을 통해 깨달은 것은 워크로드에 맞는 적절한 값을 찾는 것이 정말 중요하다는 거예요. 아무리 램이 부족해도, ZFS가 캐시로 쓸 최소한의 공간은 보장해줘야 해요. 저는 결국 1GB ~ 2GB 정도로 다시 설정하고 나서야 안정적인 성능을 되찾을 수 있었습니다.

    만약 설정 후 문제가 발생했다면, /etc/modprobe.d/zfs.conf 파일을 다시 편집해서 options zfs zfs_arc_min=... zfs_arc_max=... 줄을 주석 처리(#)하거나 삭제한 후, 다시 sudo update-initramfs -u -k all 명령을 실행하고 재부팅하면 기본값으로 되돌릴 수 있어요.

    검증 및 결과 확인: 드디어 됐다! 🎉

    설정을 변경하고 재부팅했다면, 이제 제대로 적용되었는지 확인해야겠죠? 다음 명령어를 통해 현재 시스템에 적용된 ARC 캐시의 최대 크기를 확인할 수 있습니다.

    cat /sys/module/zfs/parameters/zfs_arc_max
cat /sys/module/zfs/parameters/zfs_arc_min

    이 명령어로 출력되는 값이 여러분이 zfs.conf 파일에 설정한 바이트 단위의 값과 일치한다면 성공적으로 적용된 거예요! 그리고 실제 ARC 캐시의 동작을 더 자세히 보고 싶다면 arc_summary 도구를 사용해보세요. 이 도구는 ZFS ARC 캐시의 상세 통계를 보여줍니다. arc_summary는 zfsutils-linux 또는 zfs-initramfs 패키지에 포함되어 있는데, 설치되어 있지 않다면 다음 명령으로 설치할 수 있습니다.

    sudo apt install zfsutils-linux

    arc_summary

    arc_summary 출력에서 ARC Size와 Min Size, Max Size 항목을 보면 현재 ARC 캐시가 얼마나 사용되고 있고, 설정된 제한 범위는 얼마인지 한눈에 파악할 수 있어요. 💡 팁: arc_summary를 정기적으로 모니터링하면서, 실제 워크로드에 따라 Max Size에 가까워지는지, 아니면 여유가 있는지 확인해보세요. 만약 Max Size에 항상 도달해있는데도 시스템 성능이 만족스럽지 않다면, 조금 더 여유를 주는 방향으로 zfs_arc_max 값을 늘려볼 수도 있습니다.

    arc_summary 명령어를 통해 ZFS ARC 캐시 사용량과 설정된 최대값을 확인하는 화면

    arc_summary 명령어 실행 결과 화면입니다. ARC 캐시의 현재 사용량과 설정된 최대/최소값을 확인할 수 있습니다.

    ARC 캐시 튜닝 가이드라인

    어떤 값을 설정해야 할지 고민이신 분들을 위해, 제가 경험했던 상황별 가이드라인을 표로 정리해봤습니다. 물론 절대적인 기준은 아니지만, 시작점으로 삼기에는 충분할 거예요.

    서버 환경/용도 전체 시스템 RAM 권장 zfs_arc_max (예시) 추가 고려사항
    홈랩/NAS (가벼운 VM, 파일 공유) 8GB ~ 16GB 2GB ~ 4GB VM에 할당할 램을 우선 고려하고, 파일 I/O가 아주 빈번하지 않다면 낮게 설정.
    미디어 서버 (Plex, Jellyfin) 16GB ~ 32GB 4GB ~ 8GB 대용량 미디어 파일 스트리밍이 많으므로, 캐시를 충분히 확보하여 I/O 부하 감소.
    경량 개발/테스트 서버 (VM 다수) 32GB 이상 8GB ~ 16GB VM 개수와 각 VM의 램 할당량을 기준으로, 남는 램을 ARC에 배분.
    고성능 스토리지 서버 (DB, IOPS 중요) 64GB 이상 전체 램의 1/4 ~ 1/2 ZFS 본연의 성능을 최대로 활용하기 위해 충분한 ARC 할당. VM 램과 균형 중요.
    Proxmox ZFS ARC 캐시 튜닝의 이점과 모범 사례를 요약한 인포그래픽

    ZFS ARC 캐시 튜닝의 주요 이점과 모범 사례를 요약한 인포그래픽입니다.

    마무리하며: 나에게 맞는 최적의 값을 찾아서!

    Proxmox ZFS 환경에서 메모리 사용량 최적화는 단순히 램을 아끼는 것을 넘어, 전체 시스템의 안정성과 성능에 직접적인 영향을 미치는 중요한 작업입니다. zfs_arc_max 값을 튜닝함으로써 ZFS ARC 캐시가 과도하게 메모리를 점유하는 것을 막고, 가상머신이나 다른 서비스들이 충분한 리소스를 확보할 수 있도록 도울 수 있어요.

    제가 겪었던 삽질처럼 너무 극단적인 값으로 설정하기보다는, 위에서 제시된 가이드라인을 참고하여 자신의 워크로드와 서버 사양에 맞는 최적의 값을 찾아가는 과정이 필요합니다. 처음에는 조금 어렵게 느껴질 수 있지만, 몇 번의 시도와 모니터링을 통해 분명 만족스러운 결과를 얻으실 수 있을 거예요. 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 다음에는 ZFS 성능 모니터링 도구들에 대해 좀 더 자세히 다뤄볼까 합니다. 다음에 또 만나요! 👋

  • [Nas] TrueNAS CORE에서 Unraid로 마이그레이션: 1년 사용 후기 및 선택 기준

    [Nas] TrueNAS CORE에서 Unraid로 마이그레이션: 1년 사용 후기 및 선택 기준

    목차

    TrueNAS CORE에서 Unraid로 마이그레이션: 1년 사용 후기 및 결정 기준

    안녕하세요, 13년차 인프라 엔지니어 ‘서버실’입니다. 홈랩을 운영하면서 다양한 장비들을 써보고 또 바꿔보고 있는데요. 오늘은 제가 1년 전에 겪었던 큰 변화, 바로 TrueNAS CORE에서 Unraid로 NAS 운영체제(OS)를 마이그레이션한 경험에 대해 이야기해보려 합니다. 지금 TrueNAS와 Unraid 사이에서 고민하거나, NAS 환경에 변화를 주고 싶은 분들이라면 제 경험담이 참고가 될 거예요.

    솔직히 말씀드리면, TrueNAS CORE는 정말 훌륭한 NAS OS입니다. ZFS(Zettabyte File System)라는 강력한 파일 시스템을 기반으로 데이터 무결성과 안정성 면에서는 타의 추종을 불허하죠. 저도 오랫동안 TrueNAS CORE를 사용하면서 데이터 손실 걱정 없이 잘 지냈습니다. 하지만 홈랩 환경이라는 게 항상 똑같지 않잖아요? 이런저런 실험을 하다 보니, 좀 더 유연하고 다양한 컨테이너(Container) 환경을 쉽게 구축하고 싶다는 욕구가 생기더라고요. 특히 Docker나 가상 머신(Virtual Machine, VM)을 좀 더 자유롭게 쓰고 싶어졌습니다.

    처음엔 TrueNAS SCALE을 고려하기도 했지만, 당시에는 아직 안정화가 덜 됐다는 판단이 들어서 다른 대안을 찾아봤어요. 그러다 눈에 들어온 게 바로 Unraid였습니다. 근데 이게 FreeBSD 기반의 TrueNAS CORE와는 완전히 다른 Linux 기반이라, 마이그레이션 결정까지 꽤나 고민이 많았죠. 과연 이 결정이 옳았을까요? 지금부터 그 1년 간의 여정을 솔직하게 풀어보겠습니다.

    TrueNAS CORE와 Unraid의 아키텍처 및 주요 기능 차이 비교 다이어그램

    TrueNAS CORE와 Unraid의 핵심 아키텍처 및 기능 차이를 한눈에 볼 수 있는 다이어그램입니다. 각 시스템의 장단점이 명확히 드러나죠.

    TrueNAS CORE vs. Unraid: 핵심 개념 이해하기

    먼저, 두 NAS 운영체제의 핵심 개념부터 간단히 짚고 넘어갈게요. 마이그레이션을 고려한다면 반드시 알아야 할 차이점들입니다.

    • TrueNAS CORE (FreeBSD 기반, ZFS): TrueNAS CORE는 FreeBSD 운영체제 위에 ZFS(Zettabyte File System)를 핵심으로 사용합니다. ZFS는 RAID-Z1, RAID-Z2, RAID-Z3 등 다양한 방식의 RAID를 소프트웨어적으로 구현하며, 데이터 무결성(Data Integrity)과 스냅샷(Snapshot), 복제(Replication) 기능이 강력해요. 드라이브(Drive)를 추가할 때는 기존 VDEV(Virtual Device)에 새 드라이브를 추가하거나, 새로운 VDEV를 만들어 풀(Pool)에 통합하는 방식입니다. 한 번 구성된 풀은 드라이브를 유연하게 추가/교체하기가 쉽지 않다는 특징이 있어요.
    • Unraid (Linux 기반, Array/Cache Pool): Unraid는 경량 Linux 배포판을 기반으로 하며, 독자적인 패리티(Parity) 시스템을 사용합니다. TrueNAS처럼 전통적인 RAID 방식이 아니라, 개별 드라이브들을 묶어 하나의 큰 스토리지 배열(Array)을 만들고, 그 중 하나 또는 두 개를 패리티 드라이브(Parity Drive)로 지정해 데이터를 보호하는 방식이에요. 가장 큰 장점은 드라이브 용량에 관계없이 자유롭게 드라이브를 추가/제거할 수 있다는 점입니다. 또한, SSD를 이용한 캐시 풀(Cache Pool)을 별도로 구성하여 성능을 높이는 게 일반적입니다.

    쉽게 말해, TrueNAS는 ‘데이터 안정성’에 방점을 두고 탄탄하게 설계된 엔터프라이즈(Enterprise)급 스토리지 솔루션이고, Unraid는 ‘유연성과 확장성’에 초점을 맞춘 홈랩 친화적인 솔루션이라고 볼 수 있어요. 제가 Unraid로 눈을 돌린 것도 바로 이 유연성 때문이었습니다.

    Unraid로의 마이그레이션: 선택 기준 비교표

    어떤 NAS OS를 선택할지는 개인의 사용 목적과 환경에 따라 크게 달라집니다. 제가 TrueNAS CORE에서 Unraid로 넘어가기로 결정했던 주요 기준들을 정리해봤어요. 비슷한 고민을 하고 계신 분이라면 이 표가 참고가 될 거라고 생각합니다.

    고려 사항 TrueNAS CORE가 더 적합한 경우 Unraid가 더 적합한 경우 제가 Unraid를 선택한 이유
    데이터 무결성 & 안정성 최고 수준의 데이터 보호(ZFS), 기업용 환경, 미션 크리티컬(Mission-critical) 데이터 개별 드라이브 오류 보호(패리티), 일반적인 홈 미디어/파일 서버 홈랩 환경에서 극단적인 무결성보다 유연성이 더 필요하다고 판단
    드라이브 확장성 새 VDEV 구성 또는 풀 확장 시 복잡성, 유연성 부족, 동일 용량 드라이브 권장 용량 무관하게 자유로운 드라이브 추가/제거, 유휴 드라이브 활용 용이 다양한 용량의 드라이브를 보유하고 있어 유연한 확장이 절실
    Docker & 가상화 Jail/Plugin(컨테이너), bhyve(가상화) 지원하나 리소스 관리 및 생태계 제한적 Docker 및 KVM 기반 VM 지원이 강력, 플러그인 생태계 활발, GUI 친화적 Docker 컨테이너를 더 쉽게, 더 많이 활용하고 싶었음
    하드웨어 요구사항 ZFS 특성상 ECC RAM 필수 권장, CPU 성능 중요 ECC RAM 필수 아님(권장), 저전력 CPU로도 충분, USB 부팅 기존 하드웨어 재활용 시 ECC RAM 제약이 덜함
    운영 편의성 초기 설정 후 안정적, 학습 곡선(Learning Curve) 존재 직관적인 웹 UI, 플러그인으로 기능 확장 용이, 활발한 커뮤니티 더 빠르고 쉽게 새로운 서비스를 배포하고 싶었음

    실전 마이그레이션 준비 및 과정

    마이그레이션은 항상 신중해야 합니다. 특히 데이터가 걸려있는 작업이니까요. 제가 진행했던 과정을 간략하게 설명해 드릴게요. ⚠️ 가장 중요한 것은 데이터 백업입니다. 어떤 상황이 발생할지 모르니, 반드시 핵심 데이터는 별도의 공간에 백업해두세요. 저는 외부 USB 드라이브와 클라우드를 활용했습니다.

    1. 데이터 백업 및 TrueNAS 풀 내보내기

    기존 TrueNAS CORE 시스템에서 중요한 데이터를 백업했습니다. 그리고 기존 ZFS 풀을 안전하게 내보내는(Export) 작업을 진행했어요. 이건 필수 단계는 아니지만, 혹시 모를 상황에 대비하는 차원이었습니다.

    sudo zpool export my_data_pool

    my_data_pool은 본인의 ZFS 풀 이름으로 바꿔주시면 됩니다. 이 명령은 풀을 비활성화하고 시스템에서 분리해요.

    2. Unraid USB 부트 드라이브 생성

    Unraid는 USB 드라이브로 부팅하는 방식입니다. 공식 웹사이트에서 다운로드한 툴을 사용해 USB를 만들었어요. 💡 팁: 안정적인 부팅을 위해 가급적 검증된 USB 3.0 드라이브를 사용하는 게 좋습니다.

    3. 하드웨어 세팅 및 Unraid 초기 설정

    기존 TrueNAS 서버의 드라이브들을 물리적으로 Unraid 서버에 연결하고, Unraid USB로 부팅했습니다. Unraid 웹 UI에 접속해서 초기 설정을 진행했죠. 여기서 패리티 드라이브를 지정하고, 데이터 드라이브들을 배열(Array)에 추가합니다. 저는 기존의 모든 드라이브를 Unraid에 연결하고, 가장 큰 용량의 드라이브를 패리티 드라이브로 지정했어요.

    Unraid 웹 인터페이스 메인 대시보드 화면 및 드라이브 배열 구성

    Unraid의 깔끔한 웹 인터페이스입니다. 드라이브의 상태, 패리티 동기화 여부, 캐시 풀 등을 한눈에 확인할 수 있어요.

    4. 데이터 복사

    가장 시간이 오래 걸리는 작업입니다. 기존 TrueNAS에 있던 데이터 드라이브들을 Unraid 시스템에 임시로 연결하고, rsync 명령어를 이용해 데이터를 Unraid 배열로 복사했어요. 이 과정에서 여러 번의 삽질이 있었습니다.

    rsync -avh --progress /mnt/old_truenas_drive/MyData/ /mnt/user/data/MyData/

    -a (archive mode), -v (verbose), -h (human-readable), --progress (진행 상황 표시) 옵션은 대용량 파일 복사 시 정말 유용해요. 특히 TrueNAS의 ZFS 스냅샷 때문에 생긴 .zfs 폴더나 권한 문제 때문에 애를 먹기도 했습니다. Unraid의 사용자(User) 및 공유(Share) 권한 설정을 제대로 이해하는 게 중요하더라고요.

    삽질 경험 및 트러블슈팅

    마이그레이션이 늘 순탄하지만은 않죠. 저도 몇 가지 삽질을 경험했습니다.

    • ⚠️ ZFS 풀 마운트 문제: TrueNAS의 ZFS 풀을 Unraid(Linux)에서 직접 읽어오려고 시도했는데, 생각보다 쉽지 않더라고요. zfs-fuse 같은 도구를 써보려 했으나, 안정성과 성능 문제로 포기하고 결국 드라이브를 하나씩 연결해서 rsync로 복사하는 방식을 택했습니다. 이 과정에서 드라이브를 여러 번 뺐다 끼웠는데, 이게 물리적인 삽질이더라고요. 그냥 안전하게 네트워크로 데이터를 옮기거나, SATA 포트가 충분하다면 동시에 연결해서 옮기는 게 정신 건강에 이롭습니다.
    • 💡 Unraid 공유 권한 설정: Unraid는 공유 폴더(Share) 단위로 사용자 권한을 설정해요. 처음에는 TrueNAS의 복잡한 권한 체계에 익숙해져 있다 보니 Unraid의 비교적 단순한 권한 설정에서 헷갈렸습니다. 특히 Docker 컨테이너에서 접근할 볼륨(Volume) 권한을 제대로 설정하지 않아 컨테이너가 파일을 생성하지 못하는 문제가 발생했더라고요. Unraid의 Users 탭에서 사용자 생성 및 권한을, Shares 탭에서 각 공유 폴더의 접근 권한을 꼼꼼히 설정해야 합니다.
    • ✅ Docker 컨테이너 전환: TrueNAS의 Jail이나 플러그인으로 운영하던 서비스들을 Unraid의 Docker로 옮기는 과정은 생각보다 훨씬 수월했어요. Unraid의 Community Applications(CA) 플러그인 덕분인데, 이게 마치 앱스토어처럼 다양한 Docker 템플릿을 제공해서 클릭 몇 번으로 Plex, Nextcloud, Home Assistant 같은 서비스들을 쉽게 설치할 수 있더라고요. 처음엔 TrueNAS의 iocage 명령어나 플러그인 설정에 익숙했었는데, Unraid의 Docker 환경은 신세계였습니다.

    1년 사용 후기: 장점과 단점

    Unraid로 마이그레이션하고 1년이 지난 지금, 저는 매우 만족하고 있어요. 주요 장점과 단점을 정리해볼게요.

    장점

    • 경이로운 드라이브 확장성: 가장 큰 만족 부분이에요. 집에 굴러다니던 1TB, 2TB, 4TB 드라이브들을 모두 활용해서 큰 스토리지 풀을 만들 수 있었거든요. 용량 증설이 필요할 때마다 새 드라이브를 사서 꽂기만 하면 되니, 정말 편하더군요.
    • 압도적인 Docker 생태계: Community Applications 플러그인 덕분에 다양한 서비스를 매우 쉽게 설치하고 관리할 수 있어요. 웹 UI에서 Docker 컨테이너를 시작, 중지, 업데이트하는 게 직관적이고, 트러블슈팅도 로그 확인이 쉽습니다.
    • KVM 기반 가상화: 가상 머신 관리가 정말 편리해요. Windows Server나 Ubuntu Server 같은 VM을 몇 번의 클릭으로 설치하고, 웹 UI에서 자원 할당이나 콘솔 접속까지 가능합니다.
    • 저전력 운영: 모든 드라이브가 항상 스핀업(Spin up)되어 있지 않고, 필요할 때만 깨어나기 때문에 전기 요금 절감에도 도움이 돼요.

    단점 및 아쉬운 점

    • ZFS의 부재: 역시 ZFS 특유의 데이터 무결성 검증이나 스냅샷 기능이 아쉬울 때가 있어요. Unraid의 패리티 시스템도 훌륭하지만, ZFS만큼 강력하진 않다는 느낌을 받습니다. 중요한 데이터는 별도의 백업 전략을 더 철저히 세워야겠다고 느꼈어요.
    • 성능: 개별 드라이브에 직접 접근하는 방식이라, 단일 파일에 대한 순차 읽기/쓰기 성능은 RAID 시스템보다 떨어질 수 있어요. 하지만 캐시 풀을 적극적으로 활용하면 대부분의 홈랩 환경에서는 충분한 성능을 제공합니다.
    Unraid에서 실행 중인 Docker 컨테이너 및 리소스 모니터링 대시보드

    Unraid에서 다양한 Docker 컨테이너들이 안정적으로 동작하는 모습입니다. 각 컨테이너의 리소스 사용량도 한눈에 파악할 수 있어요.

    결론: 어떤 NAS OS를 선택해야 할까?

    1년 간의 Unraid 사용 경험을 바탕으로, 어떤 분들이 어떤 NAS OS를 선택해야 할지 명확하게 추천해 드릴게요.

    • 최고의 데이터 안정성과 무결성, 그리고 엔터프라이즈급 기능을 원한다면 TrueNAS CORE (또는 SCALE)를 선택하세요. 특히 중요한 업무용 데이터를 다루거나, ZFS의 강력한 기능을 적극 활용하고 싶다면 TrueNAS가 정답이에요. ECC RAM과 안정적인 하드웨어 투자가 필수적입니다.
    • 유연한 드라이브 확장성, 강력한 Docker 및 가상화 기능, 그리고 쉬운 홈랩 환경 구축을 원한다면 Unraid를 선택하세요. 다양한 용량의 드라이브를 활용하고 싶거나, 미디어 서버, 스마트 홈 허브 등 여러 서비스를 Docker로 쉽게 운영하고 싶다면 Unraid가 탁월한 선택이 될 거예요. 초보자도 비교적 쉽게 접근할 수 있어요.

    제 경우, 홈랩 환경에서는 유연성과 확장성, 그리고 Docker의 편리함이 데이터 무결성의 최우선 순위보다 더 중요했어요. 그래서 Unraid로의 마이그레이션은 저에게 아주 만족스러운 결정이었습니다. 물론 ZFS의 강력함은 여전히 인정하고 존경합니다만, 제 사용 패턴에는 Unraid가 더 잘 맞았던 거죠.

    어떤 선택이든 정답은 없습니다. 중요한 건 자신이 무엇을 가장 중요하게 생각하는지 명확히 파악하고 그에 맞는 도구를 선택하는 것이에요. 이 글이 여러분의 현명한 NAS OS 선택에 조금이나마 도움이 되었기를 바랍니다. 다음번에는 Unraid에서 Docker 컨테이너를 더 효율적으로 관리하는 실전 팁에 대해 다뤄보겠습니다. 그때까지 즐거운 홈랩 생활하세요! 🎉

    TrueNAS와 Unraid의 장단점 및 추천 사용 시나리오 요약 인포그래픽

    TrueNAS와 Unraid, 두 NAS 운영체제의 핵심 장단점과 각 OS에 적합한 사용 시나리오를 한눈에 비교할 수 있는 요약 인포그래픽입니다.

  • [Nas] Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드

    [Nas] Cloudflare NAS 원격 접속: Tunnel 연결 오류 디버깅 완벽 가이드

    목차

    안녕하세요, 13년차의 서버실입니다!

    오늘은 제 홈랩에서 개인 NAS(Network Attached Storage)를 원격으로 안전하게 접속하려고 Cloudflare Tunnel(클라우드플레어 터널)을 구축하다가 겪었던 ‘삽질 경험’과 그 해결 과정을 솔직하게 공유해보려고 합니다. 혹시 저처럼 Cloudflare Tunnel로 NAS 원격 접속을 시도하다가 연결 오류에 막혀본 적 있으신가요? 그렇다면 이 글이 많은 도움이 될 거라고 생각합니다.

    예전에는 VPN이나 포트 포워딩으로 NAS에 접속했었는데, 보안이나 설정의 복잡성 때문에 늘 고민이 많았거든요. 그러다 Cloudflare Tunnel이라는 아주 매력적인 솔루션을 알게 되었고, ‘이거다!’ 싶어서 바로 적용에 들어갔죠. Public IP(공인 IP) 없이도 안전하게 내부 서비스에 접근할 수 있다는 점이 정말 환상적이었어요. 그런데 막상 구축을 시작하니 생각지 못한 곳에서 오류가 터지면서 삽질 좀 했습니다. ㅎㅎ

    제가 어떤 문제에 부딪혔고, 어떻게 해결했는지 그 과정을 상세하게 풀어보겠습니다. 이 경험이 독자 여러분의 소중한 시간을 절약하는 데 기여했으면 좋겠습니다. 자, 그럼 시작해볼까요?

    Cloudflare Tunnel을 이용한 NAS 원격 접속 전체 아키텍처 개념도

    Cloudflare Tunnel과 Zero Trust, NAS 원격 접속의 조합

    먼저, 핵심 개념들을 간단하게 짚고 넘어가죠. 이 세 가지 기술이 어떻게 시너지를 내는지 이해하는 것이 중요합니다.

    • Cloudflare Tunnel (클라우드플레어 터널): 쉽게 말해, 외부에서 내부 네트워크로 안전하게 연결할 수 있는 ‘터널’을 만들어주는 서비스입니다. 우리 집 NAS나 서버가 공인 IP가 없어도, 심지어 방화벽 뒤에 있어도 Cloudflare의 엣지 네트워크를 통해 외부와 통신할 수 있게 해줘요. 내부에서 외부로 나가는 연결만 허용하면 되기 때문에 방화벽 설정도 훨씬 간단해집니다.
    • Zero Trust (제로 트러스트): ‘절대 아무것도 신뢰하지 않고, 항상 검증한다’는 보안 모델입니다. 전통적인 ‘경계 기반 보안’이 내부 네트워크는 안전하다고 가정했다면, Zero Trust는 내부 네트워크에 있더라도 모든 접근에 대해 사용자, 장치, 애플리케이션을 철저히 검증하죠. Cloudflare Zero Trust 플랫폼은 이 개념을 구현하는 강력한 도구거든요.
    • NAS (Network Attached Storage): 네트워크에 연결된 저장 장치입니다. 제 홈랩에서도 중요한 역할을 하는 녀석이죠. 사진, 동영상, 문서 등 개인 데이터를 저장하고, 미디어 서버나 백업 솔루션으로도 활용합니다.

    이 세 가지를 조합하면, Public IP 없이도 NAS에 안전하게 원격 접속할 수 있고, Zero Trust 모델을 통해 누가 언제 어디서 접속하는지까지 통제할 수 있게 됩니다. 기존의 VPN보다 훨씬 유연하고 강력한 보안 환경을 구축할 수 있다는 게 저의 오랜 경험상 가장 큰 장점이라고 생각합니다.

    Cloudflare Tunnel 설정부터 NAS 연결까지 차근차근

    이제 실제로 Cloudflare Tunnel을 설정하고 NAS에 연결하는 과정을 단계별로 설명해드릴게요. 제가 진행했던 순서 그대로입니다.

    1. Zero Trust 대시보드에서 Tunnel 생성

    1. Cloudflare Zero Trust 대시보드(one.dash.cloudflare.com)에 접속합니다.
    2. 좌측 메뉴에서 Access > Tunnels로 이동합니다.
    3. Create a tunnel 버튼을 클릭하고, Tunnel 이름을 지정합니다. 저는 my-nas-tunnel이라고 지었어요.
    4. 화면에 표시되는 설치 가이드를 따라 cloudflared를 설치할 운영체제를 선택합니다.

    만약 CLI(명령줄 인터페이스)로 Tunnel을 만들고 싶다면 다음과 같이 입력할 수 있습니다.

    # Cloudflare CLI 설치 (처음이라면) - OS에 따라 다름
# curl -L --output cloudflared-linux-amd64 https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64
# chmod +x cloudflared-linux-amd64
# sudo mv cloudflared-linux-amd64 /usr/local/bin/cloudflared

# Tunnel 생성 (CLI로)
cloudflare tunnel create my-nas-tunnel

    Tunnel을 생성하면 화면에 token이 표시되는데, 이 토큰을 잘 복사해두세요. NAS에 cloudflared를 설치할 때 필요합니다.

    2. NAS에 Cloudflared 설치 및 실행

    NAS의 운영체제에 따라 cloudflared 설치 방법이 조금 다를 수 있습니다. 저는 주로 Debian/Ubuntu 기반의 리눅스 서버나 Docker를 사용하기 때문에 해당 기준으로 설명해드릴게요.

    1. Linux (Debian/Ubuntu 기반):
      2. # cloudflared 패키지 다운로드 및 설치
curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb

# 시스템 서비스로 등록 및 실행 (위에서 복사한 토큰 사용)
sudo cloudflared service install 

# 서비스 시작
sudo systemctl start cloudflared

# 서비스 상태 확인
sudo systemctl status cloudflared
    2. Docker 사용 시:

      3. Docker Compose를 사용하는 것이 편리합니다. docker-compose.yml 파일을 다음과 같이 작성할 수 있습니다.

      version: '3.8'
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel run --token 
    network_mode: host # 중요: NAS의 다른 서비스에 접근하기 위해 host 네트워크 사용

      이후 docker-compose up -d 명령으로 실행합니다.

    정상적으로 실행되면 Cloudflare Zero Trust 대시보드에서 Tunnel의 상태가 ‘Healthy’로 표시될 겁니다. ✅

    Cloudflare Zero Trust 대시보드의 Tunnel 설정 화면 (Ingress 규칙)

    Cloudflare Zero Trust 대시보드의 Tunnel 설정 화면 (Ingress 규칙)

    3. Ingress(인그레스) 규칙 설정

    이제 가장 중요한 Ingress 규칙을 설정할 차례입니다. 이 규칙은 어떤 요청을 어느 내부 서비스로 보낼지 정의하는 역할을 합니다. NAS의 cloudflared가 실행되는 서버에 ~/.cloudflared/config.yaml 파일을 생성하거나 수정해야 합니다.

    # ~/.cloudflared/config.yaml

tunnel:  # Tunnel 생성 시 부여된 UUID
credentials-file: /root/.cloudflared/.json # 자격 증명 파일 경로

ingress:
  - hostname: nas.yourdomain.com # NAS에 접속할 도메인
    service: http://192.168.1.100:5000 # NAS의 내부 IP와 서비스 포트 (예: Synology DSM 기본 포트)
    originRequest:
      noTLSVerify: true # NAS가 HTTPS를 사용하지 않거나 자체 서명 인증서일 경우 필수!
  - service: http_status:404 # 모든 요청이 위 규칙에 해당하지 않으면 404 반환

    파일을 저장한 후, cloudflared 서비스를 재시작해야 변경 사항이 적용됩니다.

    sudo systemctl restart cloudflared # Linux 서비스의 경우
# docker-compose restart cloudflared # Docker Compose의 경우

    4. DNS 레코드 설정

    마지막으로, Cloudflare 대시보드에서 NAS에 연결할 도메인(nas.yourdomain.com)이 위에서 생성한 Tunnel로 트래픽을 라우팅하도록 DNS 레코드를 설정해야 합니다. Zero Trust 대시보드의 Tunnel 설정 화면에서 ‘Public Hostname’을 추가하거나, CLI로 설정할 수 있습니다.

    cloudflare tunnel route dns my-nas-tunnel nas.yourdomain.com

    이 명령을 실행하면 Cloudflare DNS에 CNAME 레코드가 자동으로 생성되어 해당 도메인으로 들어오는 트래픽이 Tunnel로 연결됩니다.

    ⚠️ 삽질 경험: 터널 설정 오류 디버깅 포인트!

    자, 이제 제가 가장 많이 헤매고 삽질했던 포인트들을 공유할 시간입니다. 아마 많은 분들이 여기서 비슷한 문제를 겪으셨을 거예요.

    1. noTLSVerify 옵션의 중요성 (그리고 제 실수)

    제가 가장 먼저 부딪힌 문제는 바로 이 noTLSVerify 옵션이었습니다. Ingress 규칙에 service: http://192.168.1.100:5000이라고 분명히 HTTP로 설정했는데도 계속 502 Bad Gateway 에러가 뜨는 거예요. ‘아니, NAS는 HTTPS 안 쓰는데 왜 이러지?’ 하고 한참을 헤맸습니다.

    알고 보니 Cloudflare Tunnel은 기본적으로 Origin(원본 서버, 즉 NAS)과의 통신을 HTTPS로 시도하려고 합니다. 그런데 제 NAS는 HTTPS를 사용하지 않거나, 자체 서명 인증서를 사용하고 있었던 거죠. 이럴 경우 Tunnel이 NAS의 인증서를 신뢰하지 못해서 연결에 실패하게 됩니다. 해결책은 originRequest 아래에 noTLSVerify: true를 추가하여 TLS(전송 계층 보안) 검증을 건너뛰도록 하는 것이었습니다. 이 옵션을 추가하니 거짓말처럼 연결이 되더라고요! 🎉

    💡 팁: 보안상 가능하면 NAS도 정식 HTTPS 인증서를 적용하고 noTLSVerify: false(또는 제거)로 설정하는 것이 좋습니다. 하지만 홈랩 환경에서는 편의상 이 옵션을 사용할 때가 많죠.

    2. 서비스 포트 불일치

    두 번째 삽질은 NAS의 실제 서비스 포트와 Ingress 규칙에 설정한 포트가 달라서 생긴 문제였습니다. 예를 들어 Synology NAS의 DSM(DiskStation Manager)은 기본적으로 5000번(HTTP) 또는 5001번(HTTPS) 포트를 사용하는데, 제가 다른 서비스 포트를 실수로 입력해놓은 적이 있었어요. 브라우저에서 NAS 내부 IP로 접속하면 잘 되는데, Cloudflare Tunnel을 통하면 접속이 안 되니 ‘Tunnel 문제인가?’ 하고 엉뚱한 곳을 파고 있었죠. 😅

    NAS의 관리 페이지나 다른 서비스(Plex, Photo Station 등)에 접근할 때는 반드시 해당 서비스가 사용하는 정확한 내부 포트를 Ingress 규칙의 service 필드에 명시해야 합니다. http://localhost:5000 대신 http://[NAS_내부_IP]:[포트]처럼 명시적으로 내부 IP를 사용하는 것이 더 안전하고 명확합니다.

    3. DNS 레코드 미설정 또는 오설정

    Tunnel과 Ingress 규칙을 완벽하게 설정했다고 생각했는데도 접속이 안 된다면, DNS 레코드 설정을 다시 확인해보세요. Cloudflare Tunnel은 도메인에 대한 트래픽을 Tunnel로 라우팅하기 위해 CNAME 레코드가 필요합니다. 만약 이 레코드가 없거나 잘못 설정되어 있다면, 브라우저가 NAS 도메인으로 접속하려 해도 트래픽이 Tunnel로 들어오지 못하게 됩니다. 위에서 언급한 cloudflare tunnel route dns 명령어를 사용하거나 Cloudflare 대시보드에서 직접 CNAME 레코드를 확인해보세요.

    4. cloudflared 서비스 로그 확인의 중요성

    문제가 발생했을 때 가장 먼저 해야 할 일은 cloudflared 서비스의 로그를 확인하는 것입니다. Linux 시스템에서는 sudo journalctl -u cloudflared -f 명령으로 실시간 로그를 볼 수 있고, Docker 컨테이너를 사용한다면 docker logs -f cloudflared 명령으로 확인할 수 있습니다. 저도 위에서 언급한 noTLSVerify 문제를 로그에서 Error: x509: certificate signed by unknown authority와 같은 메시지를 보고 나서야 해결 실마리를 찾을 수 있었습니다. 로그는 항상 진실을 말해주거든요!

    🎉 드디어 NAS 원격 접속 성공!

    수많은 삽질 끝에 드디어 제 NAS가 https://nas.yourdomain.com으로 외부에서 완벽하게 접속되는 순간, 그 쾌감이란…! 🎉 Zero Trust 대시보드에서 Tunnel의 상태가 Healthy로 초록불이 들어오고, 트래픽이 정상적으로 흐르는 것을 확인했을 때의 안도감은 인프라 엔지니어만이 아는 뿌듯함이죠. 이제 언제 어디서든 제 NAS에 안전하게 접속하여 파일을 관리하고, 미디어를 스트리밍할 수 있게 되었습니다.

    Cloudflare Zero Trust 대시보드에서 확인한 Tunnel의 정상 작동 상태

    Cloudflare Zero Trust 대시보드에서 확인한 Tunnel의 정상 작동 상태

    마치며: 안전한 홈랩을 위한 Cloudflare Tunnel

    오늘은 Cloudflare Tunnel을 이용해 NAS 원격 접속을 설정하고, 제가 겪었던 연결 오류들을 어떻게 디버깅했는지 상세하게 공유해드렸습니다. 13년차 인프라 엔지니어로서 많은 시스템을 만져봤지만, 이렇게 새로운 기술을 제 홈랩에 적용하며 겪는 삽질은 언제나 성장의 밑거름이 되는 것 같습니다. ‘삽질은 기술 발전의 어머니’라는 말을 다시 한번 실감했네요. 😊

    Cloudflare Tunnel은 Public IP 없이도 내부 서비스를 외부로 안전하게 노출할 수 있는 강력한 도구입니다. 특히 Zero Trust 모델과 결합하면 보안과 편의성을 동시에 잡을 수 있다는 점이 큰 매력이라고 생각합니다. 만약 여러분도 NAS 원격 접속이나 다른 홈랩 서비스를 외부에서 안전하게 접근하고 싶다면, Cloudflare Tunnel을 적극적으로 고려해보시길 강력히 추천합니다.

    다음 글에서는 Cloudflare Access를 이용해 Tunnel로 접속하는 서비스에 사용자 인증/인가를 추가하는 방법을 다뤄볼 예정입니다. 더 강력한 Zero Trust 환경을 구축하는 방법을 기대해주세요!

    Cloudflare Tunnel을 활용한 NAS 원격 접속의 주요 장점 요약

    Cloudflare Tunnel을 활용한 NAS 원격 접속의 주요 장점 요약

  • [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년차의 서버실은 언제나 여러분의 삽질을 응원합니다. 감사합니다!

  • [NAS] TrueNAS CORE에서 SCALE로: 안전한 데이터 마이그레이션 전략

    [NAS] TrueNAS CORE에서 SCALE로: 안전한 데이터 마이그레이션 전략

    목차

    TrueNAS CORE에서 SCALE로 넘어가는 여정은 많은 홈랩 사용자나 소규모 기업 NAS 관리자분들이 한 번쯤 고민해봤을 주제일 겁니다. 저도 13년차 인프라 엔지니어로서 그동안 TrueNAS CORE(이전 FreeNAS)를 정말 잘 써왔거든요. 안정적인 ZFS 파일 시스템과 FreeBSD의 견고함은 데이터를 보관하고 공유하는 데 정말 훌륭했어요.

    근데 말이죠, 요즘은 NAS 하나만으로 단순한 파일 서버 역할만 하기엔 아쉬움이 많잖아요? Docker 컨테이너나 가상 머신(VM)을 돌려서 다양한 서비스를 한 번에 운영하고 싶은 욕구가 스멀스멀 올라오더라고요. CORE의 Jail 기능도 훌륭하지만, 역시 리눅스 기반의 범용성과 확장성에는 한계가 있었습니다. 그래서 저도 작년에 TrueNAS CORE 마이그레이션을 결심하고 TrueNAS SCALE 전환을 시도했었죠. 이 과정에서 겪었던 삽질과 노하우를 오늘 탈탈 털어보려고 합니다. NAS 데이터 옮기기가 막막하셨던 분들께 좋은 가이드가 될 거예요!

    TrueNAS CORE에서 SCALE로 안전하게 마이그레이션하는 전체 로드맵

    ✅ CORE vs. SCALE: 무엇이 다른가요?

    마이그레이션 전략을 짜기 전에, 먼저 CORE와 SCALE의 근본적인 차이점을 이해하는 게 중요합니다. 쉽게 말해, 운영체제 자체가 완전히 다르거든요.

    • TrueNAS CORE: FreeBSD 기반으로, ZFS 파일 시스템의 강력함을 자랑합니다. 플러그인과 Jail(격리된 환경)을 통해 추가 기능을 제공하지만, Docker나 KVM 같은 현대적인 가상화 기술과는 거리가 있습니다. 안정성과 데이터 무결성에 강점이 있죠.
    • TrueNAS SCALE: Debian Linux 기반으로, CORE의 ZFS를 그대로 가져오면서 KVM(가상 머신)과 Docker/Kubernetes(앱) 지원을 추가했습니다. 한마디로 ‘리눅스 기반의 ZFS NAS + 컨테이너/VM 플랫폼’인 셈이죠. 확장성과 유연성이 뛰어나 홈랩 사용자들에게 특히 인기가 많습니다.

    제가 직접 써보니, CORE는 ‘데이터 금고’ 역할에 충실했다면, SCALE은 ‘데이터 금고에 스마트홈 기능까지 더한 만능 서버’ 느낌이더라고요. 그래서 FreeNAS TrueNAS 이전을 고민하는 분들이라면, 장기적인 관점에서 SCALE로의 전환을 진지하게 고려해볼 만합니다.

    💡 안전한 데이터 마이그레이션을 위한 사전 준비

    데이터 마이그레이션에서 가장 중요한 건 뭐니 뭐니 해도 데이터 안전성입니다. 아무리 좋은 기능이 추가된다고 해도 데이터가 날아가면 모든 게 의미 없잖아요? 제가 겪은 경험을 바탕으로 몇 가지 중요한 준비 사항을 알려드릴게요.

    1. 데이터 백업 (최중요!): 이건 두 번 강조해도 지나치지 않습니다. 중요한 데이터는 반드시 다른 저장장치에 백업해두세요. 저는 외장하드에 한 번, 클라우드에 한 번 더 백업했습니다. ⚠️ 만약의 사태에 대비하는 유일한 방법입니다.
    2. TrueNAS CORE 설정 백업: GUI에서 System → General → Save Config를 통해 현재 CORE의 설정 파일을 백업해둡니다. 사용자 계정, 네트워크 설정, 공유 폴더 설정 등이 포함되어 있습니다. 나중에 SCALE에서 참고하거나, 혹시 CORE로 롤백할 때 유용해요.
    3. 하드웨어 호환성 확인: TrueNAS SCALE은 CORE보다 요구 사양이 약간 더 높을 수 있습니다. 특히 메모리는 8GB 이상을 권장하며, Docker/KVM을 많이 쓸 예정이라면 더 높으면 좋죠. CPU도 가상화 기능(VT-x/AMD-V)을 지원하는지 확인하세요.
    4. 새로운 부트 드라이브 준비: CORE에서 사용하던 부트 드라이브(USB 또는 SSD)를 그대로 SCALE용으로 사용하는 것보다는, 새로운 드라이브에 SCALE을 설치하는 것을 강력히 권장합니다. 기존 CORE 부트 드라이브는 만일을 대비해 보관해두세요.

    🛠️ TrueNAS CORE에서 SCALE로: 단계별 마이그레이션

    이제 본격적으로 마이그레이션 과정을 시작해볼까요? 저는 기존 ZFS 풀은 그대로 유지하고, 운영체제만 CORE에서 SCALE로 바꾸는 전략을 사용했습니다. 이 방법이 가장 안전하고 효율적이더라고요.

    1. TrueNAS CORE에서 ZFS Pool Export

    가장 먼저 할 일은 CORE 시스템에서 현재 사용 중인 ZFS 풀을 안전하게 분리하는 겁니다. 이 과정은 데이터 삭제가 아니니 걱정하지 마세요.

    1. CORE 웹 GUI에 로그인합니다.
    2. Storage → Pools로 이동합니다.
    3. 마이그레이션할 ZFS 풀을 선택하고, 오른쪽 점 세 개 아이콘을 클릭한 후 Export/Disconnect를 선택합니다.
    4. 데이터는 유지하고 풀만 분리하는 옵션을 선택하고 진행합니다. ⚠️ 이 단계에서 ‘Destroy data’ 옵션을 절대 선택하지 마세요!

    풀이 성공적으로 Export 되면, 해당 풀에 연결된 디스크들이 시스템에서 해제됩니다. 이제 CORE 시스템은 종료해도 좋습니다.

    2. TrueNAS SCALE 설치

    CORE 시스템의 전원을 끄고, 기존 CORE 부트 드라이브를 제거한 뒤, 미리 준비해둔 새로운 부트 드라이브를 장착합니다. 그리고 TrueNAS SCALE 설치 미디어(USB)로 부팅하여 설치를 진행합니다.

    설치 과정은 일반적인 리눅스 설치와 유사합니다. 새로운 부트 드라이브에 SCALE을 설치하고, 네트워크 설정 등을 완료합니다. 설치가 끝나면 SCALE 웹 GUI에 접속할 수 있습니다.

    3. TrueNAS SCALE에서 ZFS Pool Import

    SCALE이 성공적으로 설치되고 웹 GUI에 접속했다면, 이제 기존 ZFS 풀을 가져올 차례입니다.

    1. SCALE 웹 GUI에 로그인합니다.
    2. Storage → Pools로 이동합니다.
    3. 오른쪽 상단의 Add 버튼을 클릭하고 Import an existing pool을 선택합니다.
    4. 시스템이 자동으로 연결된 디스크에서 ZFS 풀을 검색합니다. 검색된 풀 목록에서 이전에 CORE에서 사용하던 풀을 선택하고 Import를 진행합니다.

    성공적으로 임포트되었다면, Storage → Pools 화면에서 기존 풀과 데이터셋이 모두 정상적으로 표시될 겁니다. 드디어 데이터가 돌아온 거죠! 🎉

    TrueNAS SCALE 웹 GUI에서 ZFS 풀을 임포트하는 화면

    TrueNAS SCALE 웹 인터페이스에서 기존 ZFS 풀을 성공적으로 임포트하는 모습입니다. 이제 여러분의 소중한 데이터가 SCALE에서도 정상적으로 인식될 거예요.

    4. 서비스 재설정 (SMB/NFS 공유, 사용자, 앱 등)

    데이터는 돌아왔지만, 공유 설정이나 사용자 계정, 그리고 CORE에서 사용하던 Jail 기반 앱들은 다시 설정해줘야 합니다. 이건 어쩔 수 없는 부분이에요.

    • 사용자 및 그룹: CORE 설정 백업 파일을 참고하여 사용자 계정과 그룹을 다시 생성합니다. 기존의 UID/GID를 최대한 맞춰주는 것이 나중에 권한 문제로 삽질하는 걸 줄일 수 있습니다.
    • SMB/NFS 공유: Shares 메뉴에서 SMB(Windows 공유)나 NFS(Linux/macOS 공유)를 새로 생성하고, 기존 데이터셋에 연결합니다.
    • 앱 (Docker, VM): CORE의 Jail 앱들은 SCALE의 Docker 컨테이너나 KVM 가상 머신으로 새로 구성해야 합니다. 이게 SCALE로 마이그레이션하는 주된 이유 중 하나이니, 이참에 Docker Compose나 Kubernetes 앱들을 탐색해보는 것도 좋습니다.

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

    제가 직접 FreeNAS TrueNAS 이전을 하면서 겪었던 몇 가지 문제점과 해결책을 공유합니다. 저처럼 삽질하지 마시라고요! ㅎㅎ

    문제점 원인 해결 방법
    ZFS 풀 임포트 실패 아주 오래된 CORE 버전의 ZFS 풀이거나, 풀이 손상된 경우 먼저 CORE에서 zpool status로 풀 상태 확인. 손상되었다면 복구 시도. 버전 문제라면 CORE를 최신 버전으로 업데이트 후 다시 Export.
    네트워크 접속 불가 SCALE 설치 시 네트워크 설정 오류, 혹은 IP 주소 충돌 SCALE 콘솔에서 ip addr로 IP 확인, ping google.com으로 외부 연결 확인. 필요시 network 명령어로 재설정.
    SMB/NFS 공유 권한 문제 사용자/그룹 UID/GID 불일치, 또는 공유 설정 오류 CORE 백업 파일에서 UID/GID 확인 후 SCALE에서 동일하게 생성. 공유 설정 시 ACL 권한을 다시 설정하거나, Everyone read/write로 임시 테스트 후 세분화.
    CORE의 Jail 앱 대체 CORE의 Jail은 SCALE에서 직접 호환되지 않음 Docker Compose나 TrueNAS SCALE Apps(Kubernetes)를 활용하여 동일한 기능을 하는 컨테이너/앱으로 대체 설치.
    TrueNAS CORE와 SCALE의 핵심 기능 비교 인포그래픽

    TrueNAS CORE와 SCALE의 주요 기능 비교표입니다. CORE의 안정성과 SCALE의 현대적인 유연성을 한눈에 비교할 수 있습니다.

    ✅ 마이그레이션 결과 및 검증

    모든 설정이 끝나면, 이제 제대로 작동하는지 확인하는 단계입니다. 저의 경우, 다음 몇 가지를 중점적으로 확인했어요.

    1. 데이터 무결성 확인: 가장 중요한 부분이죠. 기존 데이터셋에 접근하여 파일들이 손상 없이 잘 있는지 확인합니다. 중요한 파일 몇 개를 열어보고, 해시값을 비교해보는 것도 좋습니다.
    2. SMB/NFS 공유 접근 테스트: Windows, Linux, macOS 클라이언트에서 각각 공유 폴더에 접속하여 파일 읽기/쓰기가 정상적으로 되는지 확인합니다.
    3. 네트워크 서비스 확인: 외부에서 NAS에 접속하는 서비스(SSH, 웹 GUI, Plex 등)가 정상적으로 작동하는지 확인합니다.
    4. 새로운 앱 동작 확인: Docker 컨테이너나 VM을 새로 구성했다면, 해당 앱들이 의도한 대로 잘 돌아가는지 확인합니다.

    모든 것이 정상적으로 작동하는 것을 확인했을 때의 그 쾌감이란! 드디어 TrueNAS CORE 마이그레이션이 성공적으로 마무리된 겁니다. 🎉

    TrueNAS SCALE 마이그레이션 후 정상 작동하는 대시보드 화면

    TrueNAS SCALE 시스템의 대시보드입니다. 모든 디스크와 풀이 정상적으로 인식되고, 시스템 리소스 사용률도 안정적인 것을 확인할 수 있습니다.

    🚀 마무리하며: SCALE의 새로운 시작

    이번 TrueNAS SCALE 전환은 저에게도 꽤나 큰 도전이었지만, 결과적으로는 아주 만족스러웠습니다. 이제 ZFS의 안정성 위에 Docker와 KVM의 유연함까지 더해져 홈랩 활용도가 훨씬 높아졌거든요. 기존 CORE 사용자로서 FreeNAS TrueNAS 이전을 고민하고 계시다면, 이 가이드가 여러분의 NAS 데이터 옮기기 여정에 큰 도움이 되었으면 좋겠습니다.

    물론 과정이 조금 복잡하게 느껴질 수도 있지만, 단계별로 차근차근 진행하고 백업만 확실히 해둔다면 충분히 혼자서도 성공적으로 마이그레이션할 수 있습니다. 여러분의 서버실도 SCALE과 함께 더욱 강력하고 유연한 환경으로 거듭나기를 바랍니다! 다음 글에서는 TrueNAS SCALE에 Docker Compose를 활용해 Plex와 다운로드 스테이션을 구축하는 방법을 다뤄볼게요. 기대해주세요!

    읽어주셔서 감사합니다. 삽질은 저 혼자 할게요, 여러분은 꽃길만 걸으세요! ㅎㅎ

  • [네트워크] 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 활용 팁, 그리고 트러블슈팅 가이드가 포함된 인포그래픽입니다. 깔끔하고 이해하기 쉬운 디자인으로 제작되었습니다.