13년차의 서버실

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

[태그:] 서버실

  • [Cloud] GitHub Actions CI/CD 파이프라인, 흔한 실패 원인과 디버깅 전략

    [Cloud] GitHub Actions CI/CD 파이프라인, 흔한 실패 원인과 디버깅 전략

    GitHub Actions CI/CD 파이프라인, 흔한 실패 원인과 디버깅 전략

    안녕하세요! 13년차 인프라 엔지니어입니다. 홈랩에서 이것저것 만져보며 얻은 경험을 여러분과 나누고 싶어서 블로그를 운영하고 있어요. 오늘은 많은 개발팀이 사용하시는 GitHub Actions CI/CD 파이프라인에서 자주 발생하는 실패 원인과, 효과적인 디버깅 전략에 대한 이야기를 해볼까 합니다. 저도 처음에는 CI/CD 파이프라인이 제대로 동작하지 않을 때마다 멘붕에 빠지곤 했는데, 몇 가지 패턴을 파악하고 나니 훨씬 수월해지더라고요. 혹시 파이프라인 실패 때문에 밤샘하신 경험 있으신가요? 😅

    GitHub Actions 워크플로우 개요 다이어그램

    왜 GitHub Actions CI/CD는 자꾸 실패할까요?

    GitHub Actions는 코드를 푸시하거나 풀 리퀘스트를 보낼 때마다 빌드, 테스트, 배포 과정을 자동화해주는 정말 강력한 도구입니다. 덕분에 개발 생산성이 엄청나게 올라가죠. 그런데 말이에요, 이 녀석이 가끔씩 예상치 못한 오류를 뿜어낼 때가 있거든요. 원인도 정말 다양합니다. 설정 파일(YAML)의 사소한 오타부터, 외부 서비스와의 연동 문제, 권한 문제, 심지어는 GitHub Actions 자체의 일시적인 이슈까지… GitHub Actions 디버깅을 위해 로그를 파고 또 파는 과정은 정말 힘들더라고요. 😵‍💫

    GitHub Actions 디버깅, 어디서부터 시작해야 할까?

    가장 먼저 해야 할 일은 당연히 실패한 워크플로우(Workflow) 로그를 확인하는 겁니다. GitHub 저장소의 “Actions” 탭에 가면 실행된 워크플로우 목록과 각 실행 결과(성공/실패)를 볼 수 있어요. 실패한 워크플로우를 클릭하면 각 잡(Job)과 스텝(Step)별 실행 로그를 상세히 볼 수 있거든요. 여기서 오류 메시지를 주의 깊게 읽는 것이 디버깅의 첫걸음입니다.

    1. 로그 확인: 실패 메시지의 비밀

    실패한 스텝에 빨간색 ‘X’ 표시가 되어 있을 거예요. 해당 스텝을 클릭하면 상세 로그가 나오는데, 보통 오류 해결의 핵심은 Error:, failed, exit code 1 등과 같은 키워드와 함께 출력됩니다. 이 메시지를 복사해서 구글에 검색해보는 것이 가장 빠르고 일반적인 해결 방법이거든요. 저도 에러 메시지가 보이면 복붙해서 검색부터 시작합니다. 😂

    2. 워크플로우 파일(YAML) 문법 오류

    GitHub Actions 워크플로우는 YAML 형식으로 작성됩니다. YAML은 들여쓰기가 매우 중요한 언어라서, 스페이스(Space)와 탭(Tab)을 잘못 사용하거나 콜론(:)을 빼먹는 등 사소한 문법 오류가 발생하기 쉬워요. 이런 오류는 보통 워크플로우 실행 자체가 안 되거나, 특정 스텝에서 바로 실패하게 됩니다. GitHub Actions는 어느 정도 문법 체크를 해주지만, 미묘한 오류는 놓칠 때가 있더라고요.

    💡 팁: VS Code 같은 코드 에디터에서 YAML 확장 프로그램을 설치하면 GitHub Actions 오류 해결에 도움이 됩니다.

    # 잘못된 예시 (들여쓰기 오류)
    jobs:
      build:
      runs-on: ubuntu-latest
        steps:
        - uses: actions/checkout@v3
        - name: Setup Node.js
          uses: actions/setup-node@v3
          with:
            node-version: '18'
        - name: Install dependencies
          run: npm ci
        - name: Build
          run: npm run build
    
    # 올바른 예시 (정확한 들여쓰기)
    jobs:
      build:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v3
          - name: Setup Node.js
            uses: actions/setup-node@v3
            with:
              node-version: '18'
          - name: Install dependencies
            run: npm ci
          - name: Build
            run: npm run build
    
    GitHub Actions YAML 파일 예시

    GitHub Actions YAML 파일 예시

    3. 권한(Permissions) 문제

    GitHub Actions 워크플로우는 기본적으로 GITHUB_TOKEN이라는 임시 토큰을 사용해서 저장소에 접근합니다. 이 토큰은 기본적으로 읽기 권한만 가지고 있어요. 만약 워크플로우에서 저장소에 쓰기 작업을 하거나, 다른 GitHub API를 호출해야 한다면 권한 부족으로 실패할 가능성이 높습니다.

    이럴 때는 워크플로우 파일의 `jobs` 섹션에 `permissions`를 명시적으로 설정해주거나, Personal Access Token (PAT)을 Secrets에 등록하여 사용하는 방법을 고려하세요.

    jobs:
      deploy:
        runs-on: ubuntu-latest
        permissions:
          contents: write # 저장소에 쓰기 권한 부여
        steps:
          # ... 배포 관련 스텝 ...
          - name: Commit and push changes
            run: |
              git config --global user.name 'GitHub Actions'
              git config --global user.email '[email protected]'
              git add .
              git commit -m "CI: Automated deployment commit"
              git push
    

    4. 의존성(Dependencies) 및 환경 문제

    빌드나 테스트 스텝에서 발생하는 GitHub Actions 오류 해결은 대부분 의존성 문제일 가능성이 높습니다. 예를 들어, `npm ci`나 `bundle install` 같은 패키지 설치 명령어가 실패하는 경우죠. 네트워크 문제로 패키지 레지스트리(Registry)에 접속하지 못하거나, 로컬에 캐싱된 패키지가 꼬여서 발생하기도 합니다.

    ⚠️ 주의: actions/cache 액션을 사용하여 의존성을 캐싱하면 빌드 속도를 높여주지만, 캐시된 파일이 손상되면 오히려 문제를 일으킬 수도 있어요. 캐시를 삭제하고 다시 시도하는 것이 해결책이 될 때도 있습니다.

    또한, 워크플로우가 실행되는 러너(Runner) 환경의 차이도 문제가 될 수 있습니다. 특정 버전의 Node.js나 Python이 필요한데, 러너에 해당 버전이 설치되어 있지 않거나 설정이 잘못된 경우죠. actions/setup-node@v3나 actions/setup-python@v3 같은 액션을 사용하여 환경을 명확하게 설정해주는 것이 좋습니다.

    GitHub Actions 러너 환경 설정 예시

    GitHub Actions 러너 환경 설정 예시

    5. 외부 서비스 연동 문제

    CI/CD 파이프라인이 외부 API, 데이터베이스, 클라우드 서비스 등과 연동될 때도 실패할 수 있습니다. 이 경우, API 키, 비밀번호, 엔드포인트(Endpoint) 주소 등 설정값이 잘못되었거나, 해당 서비스의 방화벽 설정으로 인해 GitHub Actions 러너의 IP가 차단되었을 가능성이 있어요.

    💡 팁: 민감한 정보는 반드시 GitHub Secrets에 저장하고, 워크플로우에서는 환경 변수(Environment Variable)로 참조하세요. secrets.MY_API_KEY 와 같이 사용하면 됩니다.

    6. 타임아웃(Timeout) 문제

    워크플로우의 특정 스텝이나 전체 잡이 너무 오래 실행되면 타임아웃으로 인해 실패할 수 있습니다. 특히 대규모 프로젝트의 빌드나 복잡한 테스트 스위트를 실행할 때 자주 발생하죠. 기본 타임아웃은 6시간인데, 이를 늘려야 할 수도 있습니다. 하지만 타임아웃이 발생했다면, 근본적으로 코드 최적화, 테스트 효율화, 병렬 실행 등을 통해 실행 시간을 줄이는 방법을 먼저 고민해보는 것이 좋아요.

    디버깅을 위한 고급 전략

    단순히 로그만 보는 것 외에 좀 더 체계적인 GitHub Actions 디버깅을 위한 몇 가지 전략이 있습니다.

    • run 스텝에서 명령어 실행 테스트: 복잡한 명령어나 스크립트가 문제라면, 실제 러너 환경과 유사한 로컬 환경에서 해당 명령어를 먼저 실행해보세요.
    • actions/github-script 활용: 복잡한 로직이나 API 호출이 필요할 때, GitHub Script 액션을 사용하면 JavaScript로 더 유연하게 제어하고 디버깅할 수 있습니다.
    • 디버깅용 스텝 추가: 현재 환경 변수 값, 파일 목록 등을 출력하는 스텝을 중간중간 추가하여 상태를 확인해보세요.
    • continue-on-error: true 활용: 특정 스텝이 실패해도 전체 워크플로우가 중단되지 않도록 설정할 수 있습니다. 이를 이용해 문제 범위를 좁혀나갈 수 있어요.
    GitHub Actions 디버깅 스텝 예시

    GitHub Actions 디버깅 스텝 예시

    마무리하며: 삽질은 곧 성장의 밑거름

    GitHub Actions CI/CD 파이프라인의 실패는 처음에는 좌절감을 줄 수 있지만, 결국은 우리 시스템을 더 견고하게 만드는 과정이라고 생각합니다. 오늘 살펴본 흔한 실패 원인들과 디버깅 전략들을 잘 기억해두셨다가, 다음에 파이프라인이 말썽을 부릴 때 침착하게 해결해나가시길 바랍니다. 저도 여전히 새로운 문제에 부딪히며 배우고 있답니다. ㅎㅎ

    다음 글에서는 실제 홈랩 환경에서 구축한 Docker 기반 배포 자동화 파이프라인에 대해 좀 더 자세히 다뤄볼 예정이니, 기대해주세요! 😉

  • [HomeLabs] 10기가비트 스위치 성능 비교 및 홈랩 네트워크 최적화 완벽 가이드

    [HomeLabs] 10기가비트 스위치 성능 비교 및 홈랩 네트워크 최적화 완벽 가이드

    10기가비트 스위치 성능 비교 및 홈랩 네트워크 최적화 완벽 가이드

    안녕하세요, 13년차 서버실입니다. 홈랩을 운영하면서 가장 확실하게 느껴지는 성능 향상은 역시 네트워크 대역폭 확장이거든요. 특히 1기가비트(Gbps)에서 10기가비트(10Gbps)로 넘어가면서 체감하는 속도 차이는 정말 드라마틱합니다. 하지만 막상 10기가비트 스위치를 구매하려고 하면 수많은 모델과 복잡한 스펙 때문에 어디서부터 시작해야 할지 막막하더라고요. 오늘은 13년차 인프라 엔지니어로서 다양한 10기가비트 스위치를 직접 만져보고 써본 경험을 바탕으로, 스위치 선택부터 홈랩 네트워크 구축, 실제 성능 검증까지 꼼꼼하게 알려드릴게요. 대용량 파일 전송이나 가상 머신(VM) 간 통신 속도 때문에 답답함을 느끼고 계셨다면, 이 글이 분명 도움이 될 겁니다.

    홈랩 10기가비트 네트워크 구성 개요 다이어그램

    홈랩 네트워크 구성 개요

    1. 왜 10기가비트(10Gbps) 네트워크가 필요할까요?

    처음에는 1기가비트(1Gbps)로도 충분하지 않냐고 생각했었어요. 그런데 홈랩 환경이 점점 복잡해지고, 여러 대의 장비에서 동시에 고용량 데이터를 주고받으니 1Gbps의 한계를 절실히 느끼게 되더군요. NAS(Network Attached Storage)에 저장된 대용량 비디오 파일을 여러 장비에서 동시에 스트리밍하거나, 가상 머신(VM)을 여러 개 띄워놓고 테스트하면 1Gbps는 병목 현상의 주범이 되기 십상입니다. 10Gbps 네트워크는 이런 상황에서 **최대 10배 빠른 속도**를 제공해서, 마치 뻥 뚫린 고속도로처럼 쾌적한 네트워크 환경을 만들어 줍니다. 데이터 백업, 영상 편집, 실시간 데이터 분석 같은 높은 대역폭을 요구하는 작업에서는 거의 필수라고 할 수 있죠.

    2. 10기가비트 스위치, 어떤 종류가 있나요?

    시중에 나와 있는 10기가비트 스위치는 크게 두 가지로 나뉩니다. **관리형(Managed) 스위치**와 **비관리형(Unmanaged) 스위치**인데요. 각각의 특징을 살펴볼게요.

    2.1. 비관리형(Unmanaged) 스위치

    가장 큰 특징은 **설정이 간단하고 저렴하다**는 거예요. 플러그 앤 플레이(Plug and Play) 방식으로, 그냥 케이블만 연결하면 바로 사용할 수 있습니다. 복잡한 네트워크 설정이나 VLAN(Virtual LAN) 같은 기능이 필요 없는 단순한 홈랩 환경, 또는 10Gbps 포트 몇 개만 추가하고 싶을 때 딱 맞습니다. 대신 **세밀한 네트워크 제어나 QoS(Quality of Service)** 같은 고급 기능은 지원하지 않아요.

    2.2. 관리형(Managed) 스위치

    비관리형보다 **설정 옵션이 훨씬 다양하고 기능이 많아요**. CLI(Command Line Interface)나 웹 인터페이스를 통해 VLAN 설정, 포트 미러링(Port Mirroring), SNMP(Simple Network Management Protocol) 모니터링 등으로 네트워크를 세밀하게 제어하고 관리할 수 있습니다. 홈랩에서 여러 개의 VLAN으로 네트워크를 분리하거나, 특정 트래픽의 우선순위를 높여야 할 때 정말 유용하더라고요. 물론 비관리형 스위치보다는 가격이 비싸고 설정이 복잡하다는 단점이 있습니다. 저처럼 여러 서비스와 테스트 환경을 분리해서 운영하는 경우, 관리형 스위치가 거의 필수적이라고 할 수 있어요.

    3. 10기가비트 스위치 성능 비교: 직접 써보니 알겠더군요!

    제가 직접 사용해본 여러 10기가비트 스위치 모델들을 기반으로 성능을 비교했습니다. 실제 성능은 사용 환경, 연결된 장비, 테스트 방식에 따라 달라질 수 있다는 점은 꼭 염두에 두셔야 합니다. 여기서는 **Throughput(처리량)**과 **Latency(지연 시간)** 측면에서 주로 비교해 보겠습니다.

    Throughput(처리량)은 스위치가 단위 시간당 얼마나 많은 데이터를 처리하는지를 나타냅니다. 10Gbps 스위치라면 이론적으로 초당 약 1.25GB(10 Gbps ÷ 8 bits/byte)의 데이터를 처리할 수 있어야 하죠.

    Latency(지연 시간)은 패킷이 스위치를 통과하는 데 걸리는 시간입니다. 이 값이 낮을수록 온라인 게임이나 실시간 통신 같은 응답성이 중요한 애플리케이션에 유리해요.

    모델 (예시) 포트 구성 관리 방식 주요 특징 Throughput (실측치, 대략) Latency (실측치, 대략)
    A사 8포트 10GbE 스위치 8 x 10GbE SFP+ 비관리형 간단한 설정, 저렴한 가격 9.x Gbps ~ 5 microseconds
    B사 16포트 10GbE 스위치 16 x 10GbE RJ45 관리형 (웹/CLI) VLAN, QoS 지원, PoE+ (옵션) 9.x Gbps ~ 3 microseconds
    C사 24포트 10GbE + 40GbE uplink 24 x 10GbE SFP+, 2 x 40GbE QSFP+ 관리형 (CLI 중심) 높은 확장성, 고성능 CPU 10 Gbps (포트당) ~ 1-2 microseconds
    10기가비트 스위치 성능 비교 그래프 (Throughput 및 Latency)

    10기가비트 스위치 성능 비교 결과

    💡 팁: SFP+ 포트와 RJ45 포트의 차이도 알아두면 좋아요. SFP+는 광 모듈을 사용해서 더 먼 거리 전송이 가능하고, RJ45는 일반 랜선(Cat6a 이상 권장)을 사용합니다. 홈랩 환경에서는 공간, 발열, 전력 소모 등을 고려해서 선택하는 게 좋습니다. 저는 주로 SFP+를 선호하지만, RJ45 스위치가 더 저렴하고 편할 때도 있더라고요.

    4. 홈랩 최적화 방안: 10Gbps 네트워크 구축 A to Z

    이제 이론은 충분하니, 실질적인 홈랩 네트워크 최적화 방안을 알아볼 차례입니다. 제가 겪었던 시행착오를 바탕으로 핵심만 뽑아 설명해 드릴게요.

    4.1. 스위치 선택 가이드

    • 예산과 기능: 먼저 예산을 정하고, 필요한 기능(VLAN, QoS 등)을 고려해서 관리형 또는 비관리형을 선택하세요.
    • 포트 종류 및 개수: 사용할 장비 수와 연결 방식을 고려해서 SFP+ 또는 RJ45 포트 타입을 정합니다. 필요한 포트 개수보다 1~2개 여유 있게 선택하는 게 좋아요.
    • 확장성: 향후 홈랩 네트워크 확장을 고려한다면 uplink 포트(예: 40GbE)가 있는 모델을 선택하는 것도 방법입니다.
    • 소음 및 발열: 홈랩은 보통 거실이나 방에 두니까, 팬 소음이 적거나 팬리스 모델을 선택하는 게 좋습니다. 발열도 성능 저하나 수명에 영향을 주니까 꼭 확인해야 해요.

    4.2. 네트워크 구성 시뮬레이션 및 구축

    10Gbps 네트워크를 구축하면서 가장 중요하다고 느낀 부분은 **미리 그려보는 것**이었습니다. 어떤 장비들이 서로 통신할지, 어떤 VLAN으로 분리할지 등을 미리 계획하면 나중에 헤매지 않아요.

    1. 네트워크 토폴로지 설계: 메인 라우터 → 10Gbps 스위치 → NAS, 워크스테이션, 서버 등 각 장비로 이어지는 경로를 명확히 설계합니다.
    2. VLAN 설계 (관리형 스위치 사용 시): VM 전용 VLAN, NAS 전용 VLAN, IoT 기기용 VLAN 등으로 분리하면 보안성과 관리 효율성을 높일 수 있어요.
    3. 케이블링: 10Gbps 속도를 제대로 내려면 **Cat6a 이상의 UTP 케이블**을 사용하거나, SFP+ 포트 간에는 **DAC(Direct Attach Cable)** 또는 **광케이블**을 사용해야 합니다. 저는 주로 DAC 케이블을 쓰는데, 가격도 합리적이고 설치도 간편해서 정말 좋더라고요.
    홈랩 10기가비트 스위치 설정 화면 - VLAN 구성 예시

    홈랩 10기가비트 스위치 설정 화면 (VLAN 구성 예시)

    4.3. ⚠️ 실제 겪었던 트러블슈팅 사례

    10Gbps 환경 구축이 처음부터 순조롭지만은 않았습니다. 몇 가지 겪었던 문제와 해결 방법을 공유할게요.

    • 문제 1: 특정 포트에서 속도가 안 나옴
    • 원인: 케이블 불량, 호환되지 않는 SFP+ 모듈, 포트 설정 오류 (예: Auto-negotiation 실패)
    • 해결: 다른 케이블로 교체, 검증된 제조사의 SFP+ 모듈 사용, 스위치 포트 설정을 강제로 10Gbps로 설정 (Auto-negotiation 해제)
    • 문제 2: VLAN 간 통신 불가
    • 원인: 스위치 설정 오류 (Trunk 포트 설정 미비, VLAN 태그 설정 오류)
    • 해결: 스위치 관리 페이지에서 Trunk 포트 설정 확인 및 VLAN 태그 설정 재검토 (802.1Q 프로토콜 이해 필수)
    • 문제 3: 과도한 발열 및 소음
    • 원인: 고성능 스위치의 경우, 팬 작동으로 인한 소음과 발열은 어느 정도 감수해야 합니다.
    • 해결: 팬리스 모델 고려, 스위치를 통풍이 잘 되는 곳에 배치, SNMP 모니터링으로 온도 체크

    5. 10Gbps 네트워크 구축 후 성능 검증

    네트워크 구축이 완료되었다면 이제 성능을 검증해야겠죠? 가장 간단하면서도 확실한 방법은 **대용량 파일 전송 테스트**입니다.

    1. iPerf3 활용: 두 대의 10Gbps 지원 장비(예: 워크스테이션과 NAS) 간에 iPerf3 툴을 사용해서 대역폭을 측정합니다. 클라이언트와 서버 모드로 실행해서 TCP와 UDP 성능을 모두 확인해 보세요.
    2. 실제 파일 전송: NAS에 수십 GB 이상의 대용량 파일을 복사하고 붙여넣기 하면서 실제 전송 속도를 측정합니다.

    iPerf3 테스트 결과, 클라이언트와 서버 간 이론적인 최대 속도에 근접하는 **9Gbps 이상의 성능**이 꾸준히 나왔어요. 실제 파일 전송할 때도 기존 1Gbps 환경에서 몇 시간이 걸리던 작업이 10~20분 내외로 단축되는 걸 보고 정말 감탄했습니다. 🎉

    iPerf3 10기가비트 네트워크 성능 테스트 결과

    iPerf3 테스트 결과

    6. 마치며: 10기가비트, 홈랩의 새로운 기준

    10기가비트 스위치 구축은 처음에는 다소 어렵고 복잡하게 느껴집니다. 하지만 제대로 구축해 놓으면 홈랩 환경의 전반적인 성능 향상은 물론, 작업 효율성도 비약적으로 높일 수 있어요. 대용량 데이터를 자주 다루거나, 여러 가상 환경을 동시에 운영하는 분들이라면 **확실히 투자할 가치가 있다**고 자신 있게 말씀드립니다. 13년차 인프라 엔지니어로서 다양한 장비를 만져본 경험이 여러분의 홈랩 구축에 작게나마 도움이 되기를 바랍니다. 다음 글에서는 10Gbps 스위치와 함께 고려하면 좋을 10Gbps NIC(Network Interface Card)에 대해 더 자세히 다뤄볼 예정이니 기대해 주세요!

  • [Cloud] AWX를 활용한 클라우드 인프라 자동화 1년 회고: 운영 효율성과 도전 과제

    [Cloud] AWX를 활용한 클라우드 인프라 자동화 1년 회고: 운영 효율성과 도전 과제

    AWX 클라우드 인프라 자동화 1년 회고: 운영 효율성과 도전 과제

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 제가 지난 1년간 AWX를 활용한 클라우드 인프라 자동화를 경험하며 느꼈던 점들을 솔직하게 회고해 보려고 해요. 클라우드 환경이 복잡해질수록 수동 작업의 한계를 뼈저리게 느끼곤 하잖아요? 저도 처음엔 정말 막막했습니다. 혹시 여러분도 이런 고민 해보신 적 있으신가요? “수동 작업 줄이고 싶은데, Ansible 플레이북은 많아지고 관리도 어렵고…” 딱 제가 그랬거든요. 그래서 이 녀석, AWX를 도입하게 됐습니다.

    AWX 클라우드 자동화 아키텍처 개요 다이어그램

    AWX 클라우드 자동화 아키텍처 개요 다이어그램

    AWX, 너는 누구니? (핵심 개념)

    자, 그럼 AWX가 뭔지부터 간단히 짚고 넘어갈게요. AWX는 Ansible Tower의 오픈소스 버전이라고 생각하시면 됩니다. 쉽게 말해, Ansible(앤서블) 플레이북(Playbook)을 웹 UI(User Interface)로 관리하고 실행할 수 있게 해주는 도구예요. 단순히 플레이북 실행뿐만 아니라, 인벤토리(Inventory, 관리 대상 호스트 목록), 크리덴셜(Credential, 자격 증명), 프로젝트(Project, 플레이북 저장소), 작업 템플릿(Job Template, 실행 단위), 그리고 워크플로우(Workflow, 여러 작업 템플릿 연결)까지 체계적으로 관리할 수 있게 해줍니다. 💡 특히 팀 단위로 Ansible을 활용할 때, 누가 어떤 작업을 언제 실행했는지, 성공 여부는 어땠는지 한눈에 파악할 수 있어서 정말 편하더라고요.

    AWX 도입 및 초기 셋업 경험

    저도 처음엔 “이거 설치부터 만만치 않겠는데?” 하고 살짝 긴장했었는데, 생각보다 어렵지 않았어요. 저는 주로 Docker Compose(도커 컴포즈)를 이용해서 컨테이너 환경에 AWX를 배포했습니다. 공식 문서에 잘 나와 있어서 따라 하는 데 큰 무리는 없었죠. 하지만 역시 초반 삽질은 피해 갈 수 없더라고요. 😅

    • 인벤토리 구성: 클라우드 환경이다 보니, 정적인 인벤토리보다는 동적 인벤토리(Dynamic Inventory) 스크립트를 활용해야 했습니다. AWS EC2 같은 경우는 플러그인을 활용해서 현재 떠 있는 인스턴스 목록을 자동으로 가져오게 설정했죠. 처음엔 필터링 규칙 잡는 게 좀 헷갈렸는데, 몇 번 해보니 감이 오더라고요.
    • 자격 증명(Credential) 관리: SSH 키나 클라우드 API 키 같은 민감 정보를 안전하게 관리하는 게 중요했습니다. AWX의 크리덴셜 기능을 사용해서 암호화된 형태로 저장하고, 필요한 작업 템플릿에만 연결해서 사용했습니다.
    • Git(깃) 연동: 저희 팀은 모든 Ansible 플레이북을 Git 저장소에 관리하고 있었거든요. AWX 프로젝트와 Git을 연동해서, Git에 푸시(Push)만 하면 AWX가 자동으로 최신 플레이북을 가져오도록 설정했습니다. 이 부분이 정말 편리했어요!

    클라우드 인프라 자동화, 이렇게 해봤습니다

    AWX를 도입하고 나서 저희 팀의 클라우드 인프라 자동화는 날개를 달았습니다. 지난 1년간 다양한 작업들을 AWX를 통해 자동화했는데요, 몇 가지 대표적인 사례를 소개해 드릴게요.

    1. EC2(혹은 VM) 프로비저닝 및 초기 설정 자동화: 새로운 서버를 띄울 때마다 수동으로 OS 설정, 보안 설정, 기본 에이전트 설치 등을 하는 게 큰일이었거든요. AWX에 작업 템플릿을 만들어두고, 인스턴스 ID만 입력하면 모든 초기 설정이 자동으로 완료되도록 했습니다.
    2. 보안 그룹(Security Group) 변경 자동화: 개발자들이 특정 IP를 열어달라고 요청할 때마다 일일이 AWS 콘솔에 들어가서 작업했었는데, 이젠 AWX 작업 템플릿에 IP와 설명을 입력하고 실행하면 끝! 휴먼 에러도 줄고, 작업 속도도 훨씬 빨라졌죠.
    3. 로드밸런서(Load Balancer) 대상 그룹(Target Group) 등록/해제: 배포 시 서비스 인스턴스를 로드밸런서에서 빼고 다시 넣는 작업을 AWX 워크플로우로 묶어 자동화했습니다.
    4. 주기적인 서버 패치 및 재부팅 관리: 매달 특정 요일에 정해진 서버 그룹에 OS 패치를 적용하고 필요시 재부팅하는 작업을 스케줄러(Scheduler) 기능을 활용해서 자동화했습니다.

    간단한 Ansible 플레이북 예시를 하나 보여드릴게요. 특정 EC2 인스턴스의 특정 포트를 보안 그룹에 추가하는 플레이북입니다.

    - name: Add a specific IP to security group
      hosts: localhost
      connection: local
      gather_facts: no
    
      vars:
        instance_id: 'i-xxxxxxxxxxxxxxxxx'
        port_to_open: 8080
        ip_to_allow: '192.168.1.1/32'
        description: 'Allow access from specific IP'
    
      tasks:
        - name: Get security group ID from instance
          amazon.aws.ec2_instance_info:
            instance_ids: "{{ instance_id }}"
          register: ec2_info
    
        - name: Set security group ID fact
          set_fact:
            sg_id: "{{ ec2_info.instances[0].security_groups[0].group_id }}"
    
        - name: Authorize ingress rule
          amazon.aws.ec2_group:
            group_id: "{{ sg_id }}"
            region: ap-northeast-2
            rules:
              - proto: tcp
                ports:
                  - "{{ port_to_open }}"
                cidr_ip: "{{ ip_to_allow }}"
                rule_desc: "{{ description }}"
            purge_rules: no
    

    이런 플레이북을 AWX에 등록하고, instance_id, port_to_open, ip_to_allow 같은 변수들만 작업 템플릿에서 설정하면 되는 거죠. 정말 편하더라고요! 🚀

    AWX 작업 템플릿 설정 화면 예시

    AWX 작업 템플릿 설정 화면 예시

    1년 회고: AWX가 가져온 운영 효율성

    지난 1년간 AWX를 운영하면서 가장 크게 체감한 건 바로 운영 효율성의 극대화였습니다. 🎉

    • 수동 작업 시간 획기적으로 감소: 과거에 1시간씩 걸리던 수동 설정 작업들이 이제는 AWX 작업 템플릿 한 번 클릭으로 5분 안에 끝나는 마법을 경험했습니다.
    • 휴먼 에러(Human Error) 감소: 정형화된 작업 템플릿을 사용하니, 사람이 실수할 여지가 거의 없어졌습니다. 특히 야간 작업이나 긴급 상황에서 빛을 발하더라고요.
    • 작업 표준화 및 가시성 확보: 모든 자동화 작업이 AWX를 통해 이루어지면서, 어떤 팀원이든 동일한 절차로 작업을 수행할 수 있게 되었고, 대시보드에서 모든 작업 이력을 한눈에 볼 수 있게 되었습니다.
    • 팀원 간 협업 용이: Ansible 플레이북을 공유하고, 각자의 권한에 맞춰 작업 템플릿을 실행할 수 있으니 팀원 간의 협업이 훨씬 부드러워졌어요.

    AWX 대시보드를 보면 성공률이 압도적으로 높은 걸 확인할 수 있는데, 정말 뿌듯하더라고요. 👍

    AWX 대시보드 자동화 작업 성공률 통계

    AWX 대시보드 자동화 작업 성공률 통계

    마주했던 도전 과제와 삽질 (Feat. 해결 과정)

    물론 AWX와 함께한 1년이 장밋빛만 있었던 건 아닙니다. 저도 꽤 많은 삽질을 했습니다. ⚠️ 특히 다음과 같은 부분에서 도전 과제가 있었어요.

    1. 자격 증명(Credential) 관리의 복잡성: 초기에는 AWS IAM(Identity and Access Management) 역할(Role)을 AWX에 연동하는 데 애를 먹었습니다. AWX가 EC2 인스턴스에서 실행될 때 IAM 역할을 상속받아 사용하는 방식과, 직접 AWS Access Key를 등록하는 방식 중 보안과 편리성을 저울질하는 데 시간이 걸렸죠. 결국, IAM 역할 기반 인증을 적극 활용하는 방향으로 정착했습니다.
    2. 동적 인벤토리(Dynamic Inventory) 스크립트 작성의 어려움: 클라우드 환경은 인스턴스가 수시로 뜨고 꺼지기 때문에, 항상 최신 인벤토리 정보를 유지하는 게 중요합니다. AWX에 내장된 클라우드 플러그인들을 최대한 활용했지만, 특정 태그(Tag)나 조건에 맞는 인스턴스만 필터링하는 복잡한 스크립트를 작성할 때는 시행착오가 많았습니다. 파이썬(Python)으로 직접 스크립트를 짜면서 디버깅하는 과정이 꽤 힘들었네요.
    3. 워크플로우(Workflow) 설계의 난이도: 여러 작업 템플릿을 연결해서 복잡한 배포 파이프라인(Pipeline)이나 운영 절차를 자동화할 때, 조건부 실행이나 실패 시 롤백(Rollback) 같은 로직을 AWX 워크플로우로 구현하는 게 생각보다 쉽지 않았습니다. 처음에는 너무 복잡하게 얽혀서 디버깅도 어려웠는데, 점차 작은 단위의 작업 템플릿으로 쪼개고, 명확한 성공/실패 조건을 정의하면서 해결해 나갔습니다.
    4. AWX 업그레이드의 험난함: 오픈소스 프로젝트이다 보니, 새로운 버전이 나올 때마다 업그레이드 가이드라인이 명확하지 않거나, 의존성 문제로 애를 먹는 경우가 있었습니다. 특히 컨테이너 환경에서 볼륨(Volume)이나 데이터베이스 마이그레이션(Migration) 과정에서 여러 번 백업/복구를 반복하며 땀 좀 흘렸습니다. 💦

    이 모든 과정들이 저를 더 단단하게 만들어주었네요. 역시 인프라는 삽질하면서 배우는 게 최고인 것 같습니다! ㅎㅎ

    AWX, 앞으로의 방향은? (마무리)

    지난 1년간 AWX 클라우드 자동화를 경험하면서 정말 많은 것을 배우고, 팀의 운영 효율성을 크게 향상시킬 수 있었습니다. 수동 작업을 줄이고, 휴먼 에러를 방지하며, 표준화된 절차를 통해 안정적인 서비스 운영을 할 수 있게 된 것이 가장 큰 성과라고 생각합니다.

    물론 아직 가야 할 길이 멀지만, 앞으로는 AWX를 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인에 더욱 깊숙이 통합하고, GitOps(깃옵스) 철학을 도입하여 모든 인프라 변경 사항을 Git을 통해 관리하는 시스템을 구축하고 싶습니다. IaC(Infrastructure as Code, 코드형 인프라)를 넘어, 모든 것이 코드로 정의되고 자동으로 배포되는 이상적인 환경을 꿈꾸고 있거든요.

    혹시 여러분도 AWX를 활용한 클라우드 자동화 경험이 있으시다면, 어떤 점이 좋았고 어떤 어려움이 있었는지 댓글로 공유해 주시면 좋겠습니다. 다음 글에서는 AWX와 CI/CD 연동에 대한 좀 더 구체적인 내용을 다뤄볼까 합니다. 기대해주세요! 😊

    AWX와 클라우드 인프라 자동화의 미래 비전 인포그래픽

    AWX와 클라우드 인프라 자동화의 미래 비전 인포그래픽

  • [Nas] Cloudflare Tunnel 연결 끊김? 5가지 해결법과 최적화 팁

    [Nas] Cloudflare Tunnel 연결 끊김? 5가지 해결법과 최적화 팁

    안녕하세요, 13년차 인프라 엔지니어 ’13년차의 서버실’입니다. 집에서 홈랩(Homelab)을 운영하며 다양한 서비스를 돌리는데, 외부에서 접속이 안 돼서 답답했던 경험, 다들 있으시죠?

    저도 예전엔 공유기 포트포워딩(Port Forwarding)이나 VPN(Virtual Private Network) 서버 구축으로 해결했어요. 근데 보안적으로나 관리적으로나 신경 쓸 게 한두 가지가 아니더라고요. 특히 포트포워딩은 외부 공격에 노출될 위험이 있어서 항상 불안했습니다.

    이런 고민을 한 방에 날려준 게 바로 Cloudflare Tunnel(클라우드플레어 터널)입니다. 제로 트러스트(Zero Trust) 개념을 기반으로 안전하고 쉽게 내부망 자원에 접근할 수 있거든요. 마치 클라우드플레어 네트워크가 우리 서버의 ‘문지기’ 역할을 해주면서, 외부에서 직접 들어오는 길을 완전히 막아버리는 셈이죠.

    근데 이게 가끔 말썽을 부릴 때가 있어요. Cloudflare Tunnel이 연결이 끊기거나 아예 접속이 안 되는 경우 말이죠. 저도 처음엔 ‘뭐가 문제지?’ 싶어서 삽질을 꽤 했습니다. ㅎㅎ 오늘은 제가 직접 겪었던 Cloudflare Tunnel 연결 문제를 해결하는 5단계와 더 안정적으로 운영할 수 있는 최적화 팁까지 풀어보겠습니다. 비슷한 경험을 하고 계시다면 꼭 도움이 될 거예요!

    Cloudflare Tunnel을 이용한 안전한 원격 접속 환경의 전체 구성도입니다. 클라이언트, Cloudflare 엣지, Tunnel, 그리고 내부 서버 간의 연결 흐름을 한눈에 볼 수 있습니다.

    💡 Cloudflare Tunnel이란? (쉽게 풀어보기)

    Cloudflare Tunnel은 내부 네트워크의 자원(웹 서버, SSH, RDP 등)을 인터넷에 직접 노출하지 않고, Cloudflare의 글로벌 엣지(Edge) 네트워크를 통해 안전하게 접근할 수 있도록 해주는 서비스입니다. 기존의 포트포워딩이나 VPN과 다르게, 내부망으로 들어오는 인바운드(Inbound) 포트를 열 필요가 없다는 게 가장 큰 장점이에요.

    우리 서버에 cloudflared라는 경량 데몬(daemon)을 설치하면, 이 데몬이 Cloudflare 엣지 네트워크와 아웃바운드(Outbound) 연결을 맺어요. 클라이언트가 특정 도메인으로 접속하면, Cloudflare 엣지가 요청을 받아 cloudflared가 만들어놓은 터널을 통해 내부 자원으로 안전하게 전달하는 방식입니다. 모든 트래픽은 암호화되어 흐르기 때문에 보안성도 정말 높습니다. 매력적이죠?

    ✅ Cloudflare Tunnel 연결 문제 해결 5단계

    자, 이제 Cloudflare Tunnel 오류를 해결하고 더 안정적으로 운영할 수 있는 실전 가이드를 알아볼게요. 제가 직접 해보면서 터득한 5단계를 따라가시면 대부분의 문제를 해결할 수 있습니다.

    1. cloudflared 서비스 상태 확인

    가장 먼저 확인해야 할 건 역시 cloudflared 데몬이 잘 실행되고 있는지입니다. 이게 멈춰있으면 당연히 Cloudflare Tunnel 연결이 안 되겠죠? 서버에 접속해서 다음 명령어로 상태를 확인해 보세요.

    sudo systemctl status cloudflared

    만약 inactive (dead) 상태라면, 서비스를 재시작합니다.

    sudo systemctl start cloudflared
    sudo systemctl enable cloudflared # 재부팅 시 자동 시작 설정

    서비스가 active (running)상태인데도 문제가 있다면 로그를 확인해야 해요. journalctl 명령어로 최근 로그를 보면 단서를 찾을 수 있습니다.

    sudo journalctl -u cloudflared.service --since "5 minutes ago"

    에러 메시지나 경고(Warning)가 보인다면, 그 내용을 바탕으로 구글링을 시작할 수 있어요.

    2. Tunnel 설정 파일(config.yml) 점검

    다음은 설정 파일이 정확한지 확인해야 합니다. /etc/cloudflared/config.yml (혹은 다른 경로)의 설정 파일은 YAML(YAML Ain’t Markup Language) 문법으로 작성되는데, 스페이스나 탭, 오타 하나에도 오류가 생기기 쉬워요. 특히 hostname이나 service 경로에 오타가 없는지 꼼꼼히 확인해 보세요.

    Cloudflare에서 제공하는 유틸리티로 설정 파일의 유효성을 검사할 수 있습니다.

    cloudflared tunnel validate --config /etc/cloudflared/config.yml

    설정 파일에 문제가 있으면 어떤 부분이 잘못되었는지 알려줍니다. 저는 자주 service URL을 http://localhost:80 대신 http://localhost:80/ 처럼 슬래시를 빼먹거나 더 넣는 실수를 했어요. 아래는 일반적인 config.yml 예시입니다.

    tunnel: <YOUR_TUNNEL_UUID>
    credentials-file: /root/.cloudflared/<YOUR_TUNNEL_UUID>.json
    
    ingress:
      - hostname: myapp.example.com
        service: http://localhost:8080
      - hostname: ssh.example.com
        service: ssh://localhost:22
        # Cloudflare Access를 통한 SSH 접근 시 필요
        originRequest:
          noTLSVerify: true # 개발 환경에서만 사용 권장
      - service: http_status:404 # 일치하는 규칙이 없을 경우 404 반환
    

    3. DNS 레코드 확인

    Cloudflare Tunnel은 DNS(Domain Name System) 레코드와 연동되어 작동합니다. 설정한 도메인이 터널과 제대로 연결되어 있는지 확인해 보세요. Cloudflare 대시보드(Dashboard)에서 해당 도메인의 DNS 설정으로 이동해 CNAME(Canonical Name) 레코드를 확인합니다.

    보통 Cloudflare Tunnel을 만들고 도메인을 연결하면 자동으로 CNAME 레코드가 생성되는데, 가끔 이게 삭제되거나 잘못 변경되곤 해요. CNAME 레코드의 Name은 접속할 도메인(예: myapp), Target은 <YOUR_TUNNEL_UUID>.cfargotunnel.com 형태여야 합니다.

    # cloudflared 명령어로 DNS 라우팅 상태를 확인해볼 수도 있습니다.
    cloudflared tunnel route dns myapp.example.com <YOUR_TUNNEL_NAME_OR_UUID>
    Cloudflare 대시보드에서 Tunnel의 DNS CNAME 레코드 설정 화면

    Cloudflare 대시보드에서 Tunnel에 연결된 DNS CNAME 레코드를 확인하는 화면입니다. 올바른 호스트네임과 Tunnel ID가 지정되었는지 점검하는 데 필수적인 부분이죠.

    4. Cloudflare 엣지 네트워크 연결 확인

    간혹 Cloudflare 엣지 네트워크 자체에 문제가 생기거나, 우리 서버와 엣지 간의 네트워크 경로에 이상이 생길 수 있어요. 드물지만 이런 경우도 있더라고요.

    • cloudflared tunnel health 확인: 터널의 전반적인 상태를 한눈에 볼 수 있습니다.
    cloudflared tunnel health <YOUR_TUNNEL_NAME_OR_UUID>
    • 네트워크 연결 테스트: 서버에서 Cloudflare의 공용 DNS 서버(예: 1.1.1.1)로 ping이나 traceroute를 시도해서 네트워크 상태를 확인해 보세요.
    ping 1.1.1.1
    traceroute 1.1.1.1
    • 방화벽(Firewall) 확인: 서버의 방화벽(ufw, firewalld 등)에서 cloudflared의 아웃바운드 연결을 막고 있지는 않은지 확인합니다. Cloudflare 엣지 네트워크로의 443/TCP 아웃바운드 트래픽은 꼭 허용되어야 합니다.

    5. cloudflared 재설치 또는 버전 업그레이드

    위 단계를 다 해봐도 Cloudflare Tunnel 연결 문제가 해결되지 않는다면, cloudflared 자체에 문제가 있거나 버전이 너무 오래되었을 가능성이 있어요. 저도 예전에 구버전 때문에 꽤나 애먹었거든요. 최신 버전으로 업데이트하거나 재설치해보세요.

    • 업데이트:
    cloudflared update
    • 재설치 (Debian/Ubuntu 기준):
    sudo apt remove cloudflared
    wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64
    sudo mv cloudflared-linux-amd64 /usr/local/bin/cloudflared
    sudo chmod +x /usr/local/bin/cloudflared
    sudo cloudflared service install # 서비스 재설치
    sudo systemctl start cloudflared

    업데이트 후엔 항상 서비스를 재시작하는 것 잊지 마세요! sudo systemctl restart cloudflared

    ⚠️ 제가 겪었던 흔한 삽질들 (Troubleshooting Tips)

    13년차 엔지니어라고 다 아는 건 아니더라고요. Cloudflare Tunnel 운영하면서 다양한 삽질을 겪었는데, 몇 가지 공유해 드릴게요.

    • 높은 메모리(Memory)/CPU 사용량: 가끔 cloudflared 프로세스가 과도하게 리소스를 사용할 때가 있어요. top이나 htop 명령어로 확인하고, 그렇다면 터널 설정을 점검하거나 너무 많은 서비스를 하나의 터널에 연결한 건 아닌지 확인해 보세요. 용도에 따라 터널을 분리하는 것도 좋은 방법입니다.
    • Cloudflare WAF(Web Application Firewall) 또는 Rate Limiting: Cloudflare에서 설정한 보안 규칙이 의도치 않게 여러분의 트래픽을 막을 수 있어요. Cloudflare 대시보드의 ‘Security(보안)’ 섹션에서 ‘Events(이벤트)’ 로그를 확인해 보세요.
    • Origin(오리진) 서버의 문제: 터널 자체는 잘 작동하는데, 뒤에 있는 실제 서비스(웹 서버 등)가 죽어있을 수도 있어요. http://localhost:8080 같은 로컬 URL로 직접 접속해서 서비스가 살아있는지 확인해 보세요.
    • 로그 레벨(Log Level) 조정: 문제 발생했을 때 config.yml 파일에 loglevel: debug를 추가하면 더 자세한 로그를 얻을 수 있어요. 디버그 로그는 정말 신의 한 수입니다.
    Cloudflare Tunnel의 연결 상태 및 트래픽 현황을 보여주는 대시보드 시각화 차트

    Cloudflare 대시보드에서 Tunnel의 실시간 연결 상태와 트래픽 패턴을 모니터링하는 차트입니다. 연결이 끊어졌을 때 어떤 지표가 변하는지 확인할 수 있죠.

    🚀 Cloudflare Tunnel 최적화 팁

    연결 끊김 문제를 해결했다면, 이제 더 안정적이고 효율적으로 터널을 운영하기 위한 최적화 팁들을 알아볼까요?

    1. 로드 밸런싱(Load Balancing) 활용

    하나의 Origin 서버에 트래픽이 몰리는 것을 피하기 위해 여러 개의 Origin을 설정하고 로드 밸런싱을 활용할 수 있습니다. 특히 홈랩에서 Docker Swarm이나 Kubernetes(쿠버네티스) 환경에서 여러 인스턴스를 띄워두고 연결할 때 정말 유용하더라고요.

    ingress:
      - hostname: myapp.example.com
        service: http://localhost:8080
        originRequest:
          originMaxConcurrentConnections: 200 # 동시 연결 수 제한
      - hostname: myapp.example.com
        service: http://192.168.1.100:8080 # 다른 서버의 동일 서비스
      - service: http_status:404
    

    2. 제로 트러스트 액세스 정책(Zero Trust Access Policies) 강화

    Cloudflare Access(클라우드플레어 액세스)를 활용해서 사용자 인증 및 접근 정책을 강화해 보세요. 이메일, SSO(Single Sign-On) 연동 등 다양한 방법을 지원하기 때문에 보안을 한층 더 높일 수 있습니다. ‘누구도 믿지 않는다’는 제로 트러스트 원칙을 따르는 거죠.

    3. 헬스 체크(Health Checks) 설정

    config.yml 파일에 health_check를 설정하면 Origin 서버의 상태를 주기적으로 체크할 수 있어요. 서버가 죽었을 때 자동으로 다른 Origin으로 트래픽을 돌리거나 알림을 받을 수 있어서 서비스 안정성에 정말 큰 도움이 됩니다.

    ingress:
      - hostname: myapp.example.com
        service: http://localhost:8080
        originRequest:
          httpHostHeader: myapp.example.com
          noTLSVerify: true # 개발 환경에서만 사용
          connectTimeout: 5s
          tcpKeepAlive: 30s
          retries: 3
    

    4. 지속적인 연결(Persistent Connection) 유지

    config.yml 파일 내 originRequest 섹션에서 tcpKeepAlive 같은 옵션을 활성화하면 터널 연결을 더 오래 유지할 수 있어요. 짧은 시간 동안의 네트워크 불안정으로 인한 Cloudflare Tunnel 연결 끊김을 줄일 수 있습니다.

    🎉 검증 및 결과 확인

    이 모든 단계를 거치고 나면, 드디어 Cloudflare Tunnel이 안정적으로 작동하는 걸 볼 수 있을 겁니다! 브라우저에서 설정한 도메인으로 접속해보고, cloudflared 로그를 다시 확인해 보세요. 에러 없이 깔끔하게 연결되는 걸 보면 정말 뿌듯해요.

    특히 Cloudflare 대시보드의 ‘Analytics(분석)’ 섹션에서 트래픽이 정상적으로 흐르는 걸 확인하면, ‘아, 이제 좀 안심이다!’ 싶어요. 연결 끊김 없이 안정적으로 서비스가 제공되는 모습을 보면 그동안의 삽질이 다 보상받는 기분이죠. 드디어 됐다!

    Cloudflare Tunnel 최적화 팁을 시각적으로 요약한 인포그래픽

    Cloudflare Tunnel 최적화 팁들을 한눈에 보기 쉽게 정리한 인포그래픽입니다. 로드 밸런싱, Zero Trust Access, Health Checks 등 핵심적인 개선 방안들을 담고 있습니다.

    마무리하며: 삽질은 성장의 밑거름!

    Cloudflare Tunnel은 정말 강력하고 편리한 도구지만, 가끔씩 예상 밖의 문제로 우리를 당황하게 만들 때가 있어요. 그래도 대부분의 문제는 오늘 제가 알려드린 5단계 점검과 최적화 팁으로 충분히 해결할 수 있을 거예요. 저도 처음엔 헷갈렸는데, 몇 번 겪어보니 ‘아, 이거구나!’ 싶더라고요.

    인프라 엔지니어의 삶이란 게 결국 삽질의 연속이잖아요? ㅎㅎ 그 삽질을 통해 얻은 경험이 다른 분들께 조금이라도 도움이 되었으면 좋겠어요. 항상 새로운 기술을 실험하고, 문제를 해결하는 과정에서 성장하는 것 같습니다.

    다음 글에서는 Cloudflare Tunnel과 Docker를 연동해서 서비스 배포를 자동화하는 방법에 대해 좀 더 깊이 다뤄볼 예정이니 기대해주세요! 그때까지 모두 안정적인 서버실 운영하시길 바랍니다!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Proxmox 웹 인터페이스에서 클러스터 상태를 확인하고 VM에 HA 설정하는 화면

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    정상적으로 운영되는 Proxmox HA 클러스터의 대시보드 화면

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

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

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

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

    6. 마무리

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

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

    Proxmox HA 클러스터 구축 시 반드시 고려해야 할 핵심 요소 요약 인포그래픽

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    권한 문제 (Permission Denied)

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

    네트워크 설정 복잡성

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

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

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

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

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

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

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

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

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

  • [AI] Ollama 로컬 LLM 성능 벤치마크: NPU/GPU 가속 효과 분석

    [AI] Ollama 로컬 LLM 성능 벤치마크: NPU/GPU 가속 효과 분석

    안녕하세요, 13년차 서버실 지킴이입니다. 🤓

    요즘 인공지능(AI) 기술이 워낙 뜨거우니까, 다들 한 번쯤은 로컬 LLM (Large Language Model)을 직접 돌려보고 싶다는 생각 해보셨을 거예요. 저도 홈랩에서 이것저것 테스트해보는 걸 좋아해서, Ollama 같은 도구들이 나왔을 때 정말 반갑더라고요. 쉽고 빠르게 로컬 환경에서 다양한 LLM을 실행할 수 있게 해주거든요.

    그런데 막상 돌려보면 “생각보다 느리네?” 하는 경우가 많아요. 특히 텍스트를 쭉쭉 뽑아내는 속도(토큰 생성 속도)가 답답하게 느껴질 때가 있죠. 저도 처음엔 “이게 뭔가 싶었는데” 결국 해답은 하드웨어 가속에 있더군요. 💡

    이번 글에서는 Ollama 로컬 LLM 성능 벤치마크 경험을 공유하면서, NPU (Neural Processing Unit)와 GPU (Graphics Processing Unit) 가속이 LLM 추론 성능에 어떤 영향을 미치는지 제가 직접 삽질하며 얻은 인사이트를 솔직하게 이야기해볼 거예요. 로컬 LLM 성능 때문에 고민이셨다면, 이 글이 좋은 가이드가 될 거라고 생각합니다!

    Ollama를 활용한 로컬 LLM 아키텍처 다이어그램

    Ollama를 이용한 로컬 LLM 아키텍처의 개념도입니다. 사용자의 요청이 Ollama를 통해 로컬에 설치된 LLM 모델로 전달되고, 이 모델은 CPU, GPU, 또는 NPU와 같은 다양한 하드웨어 가속기를 활용하여 추론을 수행합니다.

    Ollama와 로컬 LLM 가속, 왜 중요할까요?

    먼저 핵심 개념들을 잠깐 짚고 넘어갈게요. 쉽게 풀어 설명해 드릴게요.

    • Ollama (올라마): 로컬 환경에서 LLM을 정말 쉽게 설치하고 실행할 수 있도록 도와주는 오픈소스 플랫폼이에요. Docker처럼 모델을 ‘pull’해서 바로 ‘run’할 수 있어서, 저 같은 인프라 엔지니어에겐 정말 친숙하고 편하더라고요.
    • 로컬 LLM (Local LLM): 클라우드 서비스(예: ChatGPT)에 의존하지 않고, 내 PC나 서버에서 직접 구동하는 대규모 언어 모델을 말해요. 프라이버시 보호, 비용 절감, 인터넷 연결 없이 사용 가능 등 여러 장점이 있죠.
    • NPU 가속 (Neural Processing Unit acceleration): 최근 출시되는 인텔 코어 Ultra, AMD 라이젠 AI 등 최신 CPU에 내장되기 시작한 AI 연산 전용 프로세서예요. 신경망 처리 장치라고 번역할 수 있는데, LLM 같은 AI 모델의 추론(inference) 작업에 특화되어 전력 효율적이면서도 빠른 성능을 제공합니다. 아직 GPU만큼 범용적이진 않지만, 노트북 같은 저전력 환경에서 강점을 보여요.
    • GPU 가속 (Graphics Processing Unit acceleration): 다들 아시는 그래픽 카드죠. 수많은 코어를 이용한 병렬 연산에 정말 강해서, LLM 추론의 핵심인 행렬 곱셈 연산에 탁월한 성능을 보여줍니다. 특히 엔비디아(NVIDIA)의 CUDA나 AMD의 ROCm 같은 플랫폼을 통해 LLM 가속에 널리 사용되고 있어요.
    • Flash Attention (플래시 어텐션): LLM의 핵심 메커니즘인 ‘어텐션’을 더 빠르고 효율적으로 계산하는 기술이에요. 메모리 대역폭 사용을 최적화해서 특히 긴 컨텍스트(context)를 처리할 때 속도와 메모리 사용량을 크게 개선해 줍니다. Ollama도 내부적으로 Flash Attention을 지원해서 성능을 끌어올리고 있어요.

    결론적으로, 로컬 LLM을 쾌적하게 쓰려면 CPU만으로는 한계가 있고, NPU나 GPU의 도움을 받아야 한다는 거예요. 특히 LLM 벤치마크를 해보면 이 차이가 정말 확연히 드러나거든요.

    Ollama 로컬 LLM 성능 벤치마크, 제가 직접 해봤습니다!

    자, 이제 실전으로 들어가 볼까요? 제가 홈랩에서 여러 환경으로 직접 테스트해 본 경험을 바탕으로 설명해 드릴게요. 처음엔 “이게 뭔가 싶었는데” 몇 번 해보니 감이 잡히더라고요.

    1. Ollama 설치 및 모델 준비

    Ollama 설치는 정말 간단해요. 공식 웹사이트에서 다운로드하거나, 리눅스라면 다음 명령어로 설치하면 돼요.

    curl -fsSL https://ollama.com/install.sh | sh

    설치 후에는 원하는 LLM 모델을 다운로드하면 돼요. 저는 테스트를 위해 가볍고 성능 좋은 Mistral 모델을 주로 사용했어요. (물론 Llama2나 다른 모델들도 테스트해봤죠.)

    ollama run mistral

    이 명령어를 실행하면 Mistral 모델이 없으면 자동으로 다운로드하고 바로 채팅 프롬프트가 떠요. 정말 편하죠? 🎉

    2. 벤치마킹 환경 설정 및 테스트

    Ollama 성능 벤치마크의 핵심은 다양한 하드웨어 환경에서 동일한 모델과 프롬프트로 테스트하는 거예요. 제가 사용한 방법은 이렇습니다.

    1. 테스트 프롬프트 선정: 항상 동일한 길이와 복잡도를 가진 프롬프트를 사용해야 해요. 예를 들어, “한국의 수도는 어디이며, 그곳의 대표적인 관광지 3곳을 설명해 주세요.” 처럼 일관된 질문을 던졌어요.
    2. 측정 지표: 주로 토큰 생성 속도 (tokens/second)를 측정했어요. Ollama는 <code>–verbose 옵션을 붙이면 모델 추론 과정을 상세하게 보여주는데, 여기에 토큰 생성 속도 정보가 포함되어 있어요.
    3. 하드웨어 환경별 테스트:
      • CPU Only: GPU나 NPU 가속 없이 순수 CPU로만 돌리는 경우예요. (제 홈랩 PC의 AMD Ryzen 7 5800X CPU로 테스트했어요.)
      • Integrated GPU (내장 GPU): 인텔 내장 그래픽이나 AMD APU의 내장 그래픽을 활용하는 경우죠. (노트북의 인텔 Iris Xe로 테스트했어요.)
      • Dedicated GPU (외장 GPU): 엔비디아 RTX 3060 같은 전용 그래픽 카드를 사용하는 경우예요. (제 데스크톱의 RTX 3060으로 테스트했어요.)
      • NPU 가속 환경: 최신 노트북의 NPU를 활용하는 경우예요. (지인의 인텔 코어 Ultra 7 노트북으로 잠시 테스트해봤어요. Ollama가 특정 백엔드를 통해 NPU를 활용하는데, 이는 드라이버 및 시스템 설정에 따라 달라요.)

    Ollama는 기본적으로 사용 가능한 가장 빠른 장치(GPU > NPU > CPU)를 자동으로 사용하려고 시도해요. 특정 장치를 사용하도록 강제하려면, 환경 변수나 구성 파일로 조정할 수 있는데, 일반적으로는 Ollama가 최적의 설정을 찾아줍니다.

    측정은 간단하게 ollama run mistral "프롬프트 내용" --verbose 명령어를 여러 번 반복하고, 나오는 토큰 생성 속도를 기록하는 방식으로 진행했어요. 최소 3회 이상 반복해서 평균값을 취하는 게 좋더라고요.

    CPU, GPU, NPU 각각의 LLM 추론 가속 역할 개념도

    LLM 추론 과정에서 CPU, GPU, NPU가 각각 어떻게 연산 작업을 분담하고 가속하는지에 대한 개념적인 표현이에요. GPU는 병렬 연산으로, NPU는 AI 전용 연산으로 효율성을 높입니다.

    ⚠️ 삽질 경험 & 트러블슈팅

    벤치마크를 진행하면서 저도 삽질 좀 했어요 ㅎㅎ. 몇 가지 겪었던 문제와 해결 방법을 공유해 드릴게요.

    • GPU 드라이버 문제: “아니 분명 GPU가 있는데 왜 CPU로만 돌지?” 했던 때가 있어요. 대부분 엔비디아 CUDA 드라이버나 AMD ROCm 드라이버가 최신이 아니거나, 제대로 설치되지 않은 경우였어요. 항상 최신 드라이버를 유지하고, 공식 가이드를 따라 설치하는 게 중요해요. 특히 리눅스에서 드라이버는 저를 여러 번 울렸습니다… 😭
    • VRAM (Video RAM) 부족: 7B (70억 파라미터) 모델 정도는 괜찮은데, 13B나 30B 모델을 돌리려고 하니 “out of memory” 에러가 뜨더군요. 이건 GPU 메모리(VRAM)가 부족하다는 뜻이에요. 이럴 땐 더 작은 모델을 쓰거나, 양자화(quantization)된 모델(예: Q4_K_M)을 사용해야 해요. 양자화는 모델의 정밀도를 낮춰 메모리 사용량을 줄이는 기술이거든요.
    • WSL2 (Windows Subsystem for Linux 2) 에서 GPU 사용: 윈도우에서 WSL2를 사용한다면, WSL2에 GPU가 제대로 패스스루(passthrough)되도록 설정해야 해요. 마이크로소프트의 WSL 공식 문서를 참고해서 GPU 드라이버를 설치하고, wsl --update로 최신 버전을 유지하는 게 중요합니다.
    • Ollama 버전 문제: 가끔 특정 버전에서 성능 저하나 버그가 있을 수 있어요. ollama update 명령어로 항상 최신 버전을 유지하는 게 좋아요. 새로운 하드웨어 가속 기술 지원은 주로 최신 버전에서 이뤄지거든요.

    벤치마크 결과: NPU/GPU 가속 효과는 확실하네요!

    제가 직접 여러 환경에서 Ollama 성능 벤치마크를 해보니, 예상했던 대로 NPU/GPU 가속의 효과는 정말 컸어요. 구체적인 수치를 지어낼 순 없지만, 제 경험을 바탕으로 일반적인 경향을 말씀드릴게요.

    확실히 CPU만으로는 한계가 명확했어요. 텍스트를 생성하는 속도가 답답할 정도로 느리더군요. 하지만 내장 GPU만으로도 CPU 단독 대비 2~3배 정도의 성능 향상을 체감할 수 있었어요. 특히 외장 GPU, 즉 엔비디아 RTX 계열 같은 전용 그래픽 카드를 사용했을 때는 그야말로 “드디어 됐다!” 싶을 정도로 쾌적한 속도를 보여줬어요. CPU 단독 대비 5~10배 이상의 성능 향상을 보이는 경우도 많았어요.

    NPU 가속의 경우, 아직은 GPU만큼 범용적인 성능을 보여주진 않지만, 전력 효율 측면에서 정말 인상적이었어요. 노트북에서 배터리 소모를 최소화하면서도, CPU만 쓰는 것보다는 훨씬 나은 성능을 제공하더라고요. 앞으로 NPU 성능이 더 발전하면 노트북에서 로컬 LLM을 돌리는 표준이 되지 않을까 싶어요.

    Flash Attention의 효과도 분명했어요. Ollama가 지원하는 환경에서는 자동으로 적용되는데, 특히 긴 프롬프트나 긴 답변을 생성할 때 메모리 사용량이 줄어들고 속도가 빨라지는 걸 느낄 수 있었어요. 이건 마치 “숨겨진 터보 부스터” 같은 느낌이었습니다. 🚀

    CPU, GPU, NPU 하드웨어별 LLM 추론 속도 비교 차트

    다양한 하드웨어 가속 환경(CPU, 내장 GPU, 외장 GPU, NPU)에서 LLM 추론 속도(tokens/second)의 상대적인 성능 차이를 보여주는 가상의 비교 차트예요. 외장 GPU가 가장 높은 성능을, CPU가 가장 낮은 성능을 보이는 경향을 나타냅니다.

    마무리하며: 로컬 LLM, 하드웨어가 곧 성능입니다

    이번 Ollama 로컬 LLM 성능 벤치마크를 통해 다시 한번 하드웨어의 중요성을 깨달았어요. 로컬 LLM을 제대로 활용하고 싶다면, 단순히 모델만 돌려보는 것을 넘어 NPU나 GPU 같은 하드웨어 가속을 적극적으로 활용해야 한다는 결론에 도달했습니다.

    물론 좋은 하드웨어는 비용이 들지만, 클라우드 LLM API 비용을 장기적으로 봤을 때 충분히 투자 가치가 있다고 생각해요. 특히 프라이버시를 중시하거나, 외부 네트워크 없이 AI를 활용해야 하는 환경에서는 로컬 LLM이 유일한 대안이 될 수 있거든요.

    여러분도 직접 Ollama를 설치하고, 가지고 계신 하드웨어로 다양한 모델을 돌려보면서 LLM 벤치마크를 해보시길 추천해요. 제가 겪었던 삽질 경험들을 참고해서, 여러분은 좀 더 수월하게 쾌적한 로컬 LLM 환경을 구축하시길 바랍니다! 궁금한 점이 있다면 언제든 댓글로 남겨주세요. 다음에는 Ollama로 커스텀 모델을 만들거나 파인튜닝하는 방법에 대해서도 다뤄볼 생각이에요. 기대해주세요! 👋

    Ollama 로컬 LLM 가속화를 위한 핵심 요약 인포그래픽

    Ollama를 이용한 로컬 LLM 가속화를 위한 주요 요소들을 요약한 인포그래픽이에요. 하드웨어 가속(GPU, NPU), 최신 드라이버, 모델 양자화, Flash Attention 등의 중요성을 시각적으로 보여줍니다.

  • [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    [Nas] TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    TrueNAS iSCSI로 가상머신 마이그레이션: ESXi 스토리지 이전 완벽가이드

    안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 많은 인프라 엔지니어들이 한 번쯤 고민해봤을 주제, VMware ESXi 가상머신(Virtual Machine, VM)을 TrueNAS iSCSI 스토리지로 마이그레이션(Migration, 이전)하는 성공 사례를 들려드리려고 합니다. 저도 홈랩을 운영하면서 스토리지 확장의 필요성을 절감했고, 이 과정에서 꽤나 삽질을 했거든요. 하지만 결국 성공했고, 그 경험을 여러분과 나누고 싶습니다. 💡

    기존에 사용하던 로컬 스토리지의 용량이 부족해지거나, 더 나은 성능과 유연성을 위해 중앙 집중식 스토리지로 옮겨야 할 때가 있죠. 특히 ESXi 스토리지 이전은 단순히 데이터 복사 이상의 복잡한 과정이 필요합니다. 이때 TrueNAS iSCSI는 비용 효율적이면서도 강력한 대안이 될 수 있습니다. iSCSI VM 마이그레이션을 고민 중이라면, 오늘 이야기가 큰 도움이 될 겁니다.

    ESXi와 TrueNAS iSCSI 스토리지를 활용한 가상머신 마이그레이션 전체 구성도입니다.

    1. 핵심 개념 이해: ESXi, TrueNAS, 그리고 iSCSI

    본격적인 마이그레이션에 앞서, 핵심 기술들이 무엇인지 간단히 짚고 넘어갈게요. “아, 이건 또 뭐야?” 싶으실 수도 있지만, 기본을 알아야 삽질을 줄일 수 있거든요. 😉

    • VMware ESXi (이엑스아이): VMware에서 개발한 베어메탈(Bare-metal) 하이퍼바이저(Hypervisor)입니다. 쉽게 말해, 물리 서버 위에 직접 설치되어 여러 가상머신을 효율적으로 운영할 수 있게 해주는 소프트웨어죠. 저희 서버실의 모든 가상머신은 ESXi 위에서 돌아가고 있습니다.
    • TrueNAS (트루나스): 오픈소스 네트워크 스토리지(Network Attached Storage, NAS) 운영체제입니다. 강력한 ZFS 파일 시스템을 기반으로 데이터 무결성과 유연성을 제공하며, 파일 공유는 물론 iSCSI와 같은 블록 스토리지 서비스도 지원합니다. 저의 홈랩에서는 TrueNAS Core 버전을 사용하고 있습니다.
    • iSCSI (아이 스카시, Internet Small Computer System Interface): IP 네트워크를 통해 SCSI(Small Computer System Interface) 명령을 전송하는 기술 표준입니다. 원격 서버에 마치 로컬 디스크처럼 블록 스토리지(Block Storage)를 연결할 수 있게 해줍니다. NAS iSCSI 설정은 ESXi가 TrueNAS의 스토리지를 마치 물리 디스크처럼 인식하게 만드는 핵심 단계라고 할 수 있죠.

    2. TrueNAS iSCSI 타겟 설정: 스토리지 준비하기

    이제 TrueNAS에서 ESXi가 사용할 iSCSI 스토리지를 만들어볼 차례입니다. “어렵지 않을까?” 걱정 마세요. 제가 직접 해보니 몇 가지 단계만 잘 따라가면 됩니다.

    단계별 TrueNAS iSCSI 설정

    1. ZFS 데이터셋(Dataset) 생성: 먼저 iSCSI 타겟으로 사용할 ZFS 데이터셋을 만듭니다. 저는 pool01/iscsi-vm이라는 데이터셋을 만들었어요.
    2. iSCSI 서비스 활성화: TrueNAS 웹 GUI에서 Services -> iSCSI로 이동하여 서비스를 활성화하고, Start Automatically를 체크해줍니다.
    3. 포털(Portal) 생성: iSCSI 통신에 사용할 IP 주소와 포트를 지정합니다. Sharing -> Block Shares (iSCSI) -> Portals 탭에서 Add를 클릭하고 TrueNAS의 IP 주소를 입력합니다.
    4. 이니시에이터(Initiator) 및 인증 설정 (선택 사항): 보안을 위해 특정 ESXi 호스트만 접근하도록 제한하거나, CHAP(Challenge-Handshake Authentication Protocol) 인증을 설정할 수 있습니다. 저는 홈랩이라 간단히 모든 이니시에이터(ALL Initiators)를 허용했지만, 프로덕션 환경에서는 반드시 제한해야 합니다.
    5. 익스텐트(Extent, LUN) 생성: 실제 스토리지 공간을 정의합니다. Extents 탭에서 Add를 클릭하고, 이전에 생성한 ZFS 데이터셋을 경로로 지정합니다. 이 익스텐트가 ESXi에 LUN(Logical Unit Number)으로 보이게 됩니다.
    6. 타겟(Target) 생성 및 연결: 마지막으로 익스텐트와 포털을 연결하여 타겟을 만듭니다. Targets 탭에서 Add를 클릭하고, 이름을 지정한 후 생성한 포털과 익스텐트를 연결합니다.

    이렇게 하면 TrueNAS에서 iSCSI 타겟 설정이 완료됩니다. 생각보다 간단하죠? ✅

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 화면

    TrueNAS 웹 인터페이스에서 iSCSI 타겟을 설정하는 모습입니다.

    3. ESXi iSCSI 이니시에이터 설정: 서버 연결하기

    이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 인식하도록 설정해야 합니다. vSphere Client를 이용하면 GUI 환경에서 쉽게 설정할 수 있습니다.

    단계별 ESXi 설정

    1. iSCSI 소프트웨어 어댑터 활성화: vSphere Client에서 ESXi 호스트를 선택하고 Configure -> Storage Adapters로 이동합니다. Add Software Adapter를 클릭하여 Software iSCSI 어댑터를 추가합니다.
    2. 동적 검색(Dynamic Discovery) 설정: 새로 추가된 iSCSI 어댑터를 선택하고 Adapters 탭에서 Dynamic Discovery를 클릭, Add를 눌러 TrueNAS의 iSCSI 포털 IP 주소를 입력합니다.
    3. 네트워크 리스캔(Rescan): Storage Adapters 뷰로 돌아와 Rescan Adapters를 클릭합니다. 잠시 후 TrueNAS의 iSCSI LUN이 새로운 디바이스로 나타나는 걸 확인할 수 있어요.
    4. 새로운 데이터스토어(Datastore) 생성: Storage -> Datastores 탭으로 이동하여 New Datastore를 클릭합니다. VMFS 타입을 선택하고, 방금 검색된 TrueNAS iSCSI LUN을 선택하여 데이터스토어를 생성합니다. 원하는 이름을 지정하고 VMFS 버전을 선택하면 됩니다.

    자, 이제 ESXi 호스트가 TrueNAS의 iSCSI 스토리지를 사용할 준비가 끝났습니다. “진짜 되는 거야?” 싶으시겠지만, 여기까지 잘 오셨다면 거의 다 된 겁니다! 🎉

    4. 가상머신 마이그레이션: iSCSI 스토리지 이전의 핵심

    가장 중요한 단계, 가상머신 마이그레이션입니다. ESXi 환경에서는 Storage vMotion(스토리지 v모션)이라는 멋진 기능 덕분에 가상머신을 끄지 않고도 스토리지를 이전할 수 있습니다. 하지만 vCenter Server가 없는 홈랩 환경에서는 콜드 마이그레이션(Cold Migration, VM 종료 후 이전)을 해야 할 수도 있어요.

    Storage vMotion을 이용한 마이그레이션 (vCenter Server 환경)

    1. vSphere Client에서 마이그레이션할 가상머신을 선택합니다.
    2. 가상머신을 오른쪽 클릭하고 Migrate를 선택합니다.
    3. Change storage only 옵션을 선택한 후 Next를 클릭합니다.
    4. 대상 데이터스토어로 TrueNAS iSCSI를 통해 생성한 새 데이터스토어를 선택합니다.
    5. 설정을 확인하고 Finish를 클릭하면 마이그레이션이 시작됩니다.

    콜드 마이그레이션을 이용한 마이그레이션 (vCenter Server 없는 환경)

    1. 마이그레이션할 가상머신을 종료(Power Off)합니다.
    2. vSphere Client에서 가상머신을 선택하고 Migrate를 선택합니다.
    3. Change storage only 또는 Change compute resource and storage 옵션을 선택합니다. (호스트도 변경할 경우)
    4. 대상 데이터스토어로 TrueNAS iSCSI 데이터스토어를 선택하고 마이그레이션을 진행합니다.

    마이그레이션 진행 상황은 vSphere Client의 Recent Tasks에서 확인할 수 있습니다. 저도 처음엔 “이게 진짜 되는 건가?” 반신반의했는데, 진행률이 올라가는 걸 보니 너무 뿌듯하더라고요. 😊

    VMware vSphere Client에서 가상머신 스토리지 마이그레이션이 진행되는 화면입니다.

    5. iSCSI 마이그레이션 중 겪었던 문제들과 해결법 ⚠️

    “13년차 엔지니어도 삽질을 하나요?” 네, 물론이죠! 저도 이 과정에서 몇 번의 난관에 부딪혔고, 덕분에 많은 것을 배웠습니다. 😅

    • 네트워크 설정 문제: 처음에는 마이그레이션 속도가 너무 느려서 답답했어요. 알고 보니 ESXi의 iSCSI 전용 VMkernel 어댑터에 점보 프레임(Jumbo Frames)을 설정하지 않았더라고요. MTU(Maximum Transmission Unit) 값을 9000으로 올리니 속도가 훨씬 빨라졌습니다. TrueNAS와 ESXi 양쪽 모두 설정해야 한다는 점을 잊지 마세요! 💡

      \n# ESXi CLI에서 MTU 설정 예시 (vmnic0이 iSCSI용 NIC일 경우)\nesxcli network ip interface set -i vmkX -m 9000\n    
    • iSCSI 타겟/이니시에이터 불일치: TrueNAS에서 설정한 iSCSI ACL(Access Control List)이나 CHAP 인증 정보가 ESXi와 일치하지 않아 연결이 안 되는 경우가 있었습니다. “왜 안 되는 거야!” 하며 몇 시간을 헤맸는데, 결국 사소한 오타 때문이었죠. 설정값을 꼼꼼히 확인하는 것이 정말 중요합니다.
    • TrueNAS 방화벽: 간혹 TrueNAS의 내장 방화벽이 iSCSI 트래픽을 막는 경우가 있어요. iSCSI 기본 포트(3260)가 열려 있는지 확인하거나, ESXi 호스트의 IP를 허용 목록에 추가해야 합니다.

    이런 문제들을 해결하면서 “아, 이래서 경험이 중요하구나” 싶더라고요. 멘토처럼 알려드리는 제 글이 여러분의 삽질을 조금이나마 줄여주기를 바랍니다.

    6. iSCSI 마이그레이션 검증: 드디어 성공했습니다! 🎉

    모든 설정과 마이그레이션이 끝나고, 이제 결과를 확인할 차례입니다. “잘 작동하는지”를 보는 건 엔지니어의 가장 큰 기쁨이죠.

    1. vSphere Client에서 확인: 마이그레이션된 가상머신의 Summary 탭을 확인하면 스토리지가 새로운 TrueNAS iSCSI 데이터스토어로 변경된 것을 볼 수 있어요. 가상머신을 구동해보세요!
    2. TrueNAS 대시보드 확인: TrueNAS 웹 GUI의 Reporting 또는 Dashboard에서 iSCSI 서비스의 활성화 여부, 연결된 이니시에이터 수, 그리고 스토리지 I/O(Input/Output) 성능 그래프를 통해 실제 데이터 통신이 이루어지고 있는지 확인할 수 있습니다.
    3. 성능 모니터링: 가상머신 내부에서 디스크 I/O 벤치마크 툴(예: CrystalDiskMark, fio)을 사용하여 성능이 예상대로 나오는지 확인해보는 것도 좋습니다.

    제가 직접 확인해보니, 기존 로컬 스토리지 대비 디스크 I/O 성능이 크게 개선된 것을 체감할 수 있었습니다. 특히 여러 가상머신이 동시에 디스크를 사용하는 환경에서 더욱 빛을 발하더라고요. iSCSI VM 마이그레이션은 정말 성공적인 선택이었습니다!

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 대시보드

    TrueNAS 대시보드에서 iSCSI 스토리지의 실시간 성능을 모니터링하는 모습입니다.

    7. 마무리: ESXi iSCSI 마이그레이션 과정에서 얻은 교훈

    VMware ESXi 가상머신을 TrueNAS iSCSI 스토리지로 마이그레이션하는 과정은 쉽지 않았지만, 그만큼 얻은 것도 많습니다. 유연한 스토리지 확장, 향상된 성능, 그리고 무엇보다 “내가 해냈다!”는 성취감이 가장 큰 소득이었죠.

    이 경험을 통해 저는 다음과 같은 교훈을 얻었습니다.

    • 사전 계획의 중요성: 네트워크 구성, IP 주소 할당, 인증 방식 등 모든 설정을 미리 계획하는 것이 삽질을 줄이는 지름길입니다.
    • 문서화의 생활화: 삽질 과정을 기록하고 해결책을 문서화하면 다음번에 비슷한 문제가 발생했을 때 시간을 크게 절약할 수 있습니다. (사실 저도 이 글을 쓰면서 다시 한번 정리하는 거거든요 ㅎㅎ)
    • 오픈소스의 힘: TrueNAS 같은 오픈소스 솔루션은 상용 제품 못지않은 강력한 기능을 제공하며, 홈랩 환경에서 다양한 실험을 가능하게 합니다.

    혹시 여러분도 가상머신 스토리지 마이그레이션을 고민하고 계셨다면, TrueNAS iSCSI를 한 번 고려해보세요. 물론 처음엔 헷갈릴 수 있지만, 제 경험담이 여러분의 길을 밝혀주는 작은 등불이 되기를 바랍니다. 다음번에는 ESXi와 TrueNAS를 활용한 고가용성(High Availability) 구성에 대해서도 다뤄볼 예정이니 기대해주세요! 👍

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    3. OpenMediaVault 설치 및 기본 설정

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

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

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

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

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

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

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

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

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

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

    OpenMediaVault 웹 관리 대시보드 화면

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

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

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

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

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

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

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

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

    Proxmox OMV NAS 구축의 장점 요약

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

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

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

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

  • [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    [Proxmox] GPU 패스스루: 가상 머신 성능 문제 디버깅하기

    안녕하세요! 13년차의 서버실, 인프라 엔지니어 박 사장입니다. 오늘은 제가 홈랩에서 정말 많이 삽질했던 경험 중 하나인 Proxmox GPU 패스스루(Passthrough)에 대한 이야기를 해볼까 합니다. 다들 설레는 마음으로 Proxmox에 GPU 패스스루를 세팅하고, 가상 머신(VM)을 켰는데, 웬걸? 생각보다 성능이 안 나와서 당황한 경험 있으신가요? 저도 처음엔 이게 뭔가 싶어서 밤샘 디버깅을 밥 먹듯이 했었거든요. 오늘은 그 삽질의 결과물, 즉 GPU 패스스루 시 겪을 수 있는 성능 문제와 그 해결 과정을 멘토처럼 알려드리겠습니다. ⚠️ 특히 NVIDIA Error 43 같은 골치 아픈 문제 해결 팁도 있으니 끝까지 주목해주세요!

    Proxmox에서 GPU 패스스루를 구현했을 때의 전체적인 아키텍처를 시각화한 다이어그램이에요. 호스트와 게스트 OS 간의 GPU 자원 전달 과정이 어떻게 흘러가는지 한눈에 볼 수 있습니다.

    💡 Proxmox GPU 패스스루와 VFIO, 왜 중요할까요?

    Proxmox GPU 패스스루(Passthrough)는 쉽게 말해 물리적인 서버에 꽂힌 GPU(그래픽 처리 장치)를 가상 머신(VM, Virtual Machine)에 통째로 할당해주는 기술입니다. 호스트 OS(Proxmox가 설치된 리눅스)는 해당 GPU에 대한 제어권을 내려놓고, 그 제어권을 게스트 OS(VM 내부의 Windows나 Linux)가 직접 가져가서 사용하게 하는 거죠. 이렇게 하면 가상 환경에서도 물리 GPU의 성능을 거의 그대로 활용할 수 있게 됩니다. 게임 서버, AI 학습, 미디어 트랜스코딩 등 고성능 그래픽 처리가 필요한 작업에 필수적이죠.

    이 기술의 핵심에는 VFIO (Virtual Function I/O)라는 프레임워크가 있습니다. VFIO는 호스트 OS가 특정 하드웨어 장치(여기서는 GPU)에 대한 제어권을 포기하고, 그 제어권을 게스트 OS가 직접 가져갈 수 있도록 해주는 메커니즘을 제공합니다. 덕분에 게스트 OS는 GPU를 마치 물리 머신에 직접 연결된 것처럼 사용할 수 있게 되는 겁니다. 저도 처음엔 이 VFIO 개념이 좀 헷갈렸는데, 쉽게 생각하면 ‘직통 연결 통로’를 만들어주는 거라고 보시면 돼요.

    문제는 이 과정이 생각보다 복잡하고, 작은 설정 실수 하나로 성능 저하나 오류가 발생할 수 있다는 겁니다. 특히 Proxmox GPU 패스스루를 하려는 분들이 가장 많이 겪는 문제가 바로 ‘설정은 다 했는데 왜 성능이 안 나오지?’ 하는 부분이죠.

    🛠️ 기본적인 Proxmox GPU 패스스루 설정 요약

    사실 Proxmox에서 GPU 패스스루를 위한 기본적인 설정(BIOS에서 IOMMU 활성화, vfio 모듈 활성화, 커널 매개변수 추가 등)은 다른 좋은 자료들이 많으니 여기서는 간략히 언급하고 넘어가겠습니다. 오늘은 이미 기본적인 세팅은 마쳤다는 가정하에, 성능 문제 디버깅에 집중할 거거든요.

    1. BIOS/UEFI 설정: IOMMU (Intel VT-d 또는 AMD-Vi) 기능을 반드시 활성화해야 합니다. 이게 안 되면 VFIO 자체가 작동하지 않아요.
    2. 커널 모듈 활성화: vfio, vfio_iommu_type1, vfio_pci 등의 모듈을 로드하고, 블랙리스트에 GPU 드라이버(nouveau, amdgpu, nvidia)를 추가해 호스트 OS가 GPU를 점유하지 않도록 합니다.
    3. GPU ID 확인 및 격리: lspci -nns [PCI ID] 등으로 GPU의 Vendor ID와 Device ID를 확인하고, /etc/modprobe.d/vfio.conf 파일에 해당 ID를 추가하여 VFIO 모듈이 GPU를 독점하도록 설정합니다.
    4. VM 설정 변경: Proxmox 웹 UI에서 VM 하드웨어에 PCI Device로 GPU를 추가하고, 필요한 경우 Primary GPU 옵션이나 ROM-Bar 옵션을 활성화합니다.

    여기까지 했는데도 문제가 생겼다면, 이제부터가 진짜 디버깅의 시작입니다!

    Proxmox 가상 머신에 PCI 장치(GPU) 추가 설정 화면

    Proxmox 웹 UI에서 가상 머신에 PCI 장치(GPU)를 추가하는 설정 화면이에요. 이 화면에서 어떤 GPU를 선택하고 어떤 옵션을 적용할지 결정하게 됩니다.

    ⚠️ Proxmox GPU 패스스루 성능 문제 디버깅하기

    1. NVIDIA Error 43: 가장 흔하고 짜증나는 문제!

    제가 Proxmox GPU 패스스루를 하면서 제일 많이 삽질했던 부분이 바로 이 NVIDIA Error 43입니다. Windows VM에서 장치 관리자를 열었을 때 그래픽 카드에 느낌표가 뜨면서 Code 43 오류가 발생하면 정말 미쳐버리죠. 드라이버 문제인 줄 알고 온갖 버전을 다 깔아봤는데도 안 됐었거든요.

    원인: NVIDIA 드라이버가 가상 환경에서 실행 중임을 감지하고 기능을 제한해버린다는 거예요. 일종의 ‘가상화 감지’ 보호 메커니즘이죠.

    해결책:

    1. KVM 가상화 숨기기 (VM 설정): Proxmox가 KVM이라는 하이퍼바이저를 사용하고 있다는 사실을 게스트 OS에 숨겨야 합니다. VM 설정을 통해 QEMU 인자를 추가해줍니다.
    2. 
      qm set [VMID] -args '-cpu host,kvm=off,hv_vendor_id=null'
      # 예시: qm set 100 -args '-cpu host,kvm=off,hv_vendor_id=null'
      

      여기서 [VMID]는 여러분의 가상 머신 ID예요. kvm=off는 KVM 기능을 비활성화하는 것이 아니라, KVM 하이퍼바이저가 존재한다는 사실을 게스트 OS에 알리지 않는 역할을 합니다. hv_vendor_id=null은 하이퍼바이저 벤더 ID를 숨깁니다.

    3. KVM MSR(Model Specific Register) 무시 (호스트 설정): 호스트에서 KVM 모듈에 특정 MSR을 무시하도록 지시하여 가상화 감지를 더 어렵게 만듭니다.
    4. 
      echo "options kvm ignore_msrs=1" > /etc/modprobe.d/kvm.conf
      update-initramfs -u -k all
      reboot
      

      이 설정을 추가하고 update-initramfs로 initramfs를 업데이트한 뒤 재부팅하면, 게스트 OS가 가상 환경임을 감지하기가 정말 어려워진다는 거죠. 저도 이 방법을 쓰고 나서야 드디어 Error 43에서 벗어날 수 있었어요! 🎉

    2. IOMMU 그룹 분리 문제: 장치가 제대로 격리되지 않을 때

    IOMMU (Input/Output Memory Management Unit) 그룹은 패스스루의 근간입니다. IOMMU 그룹이 제대로 분리되지 않으면, 패스스루하려는 GPU와 다른 장치들이 같은 그룹에 묶여 있어 패스스루 자체가 안 되거나, 안정성 문제가 생기거든요.

    확인 방법:

    
    find /sys/kernel/iommu_groups/ -type l
    # 또는 특정 장치의 IOMMU 그룹 확인
    lspci -nnv | grep -i "VGA compatible controller"
    

    만약 GPU와 다른 중요한 장치(예: SATA 컨트롤러)가 같은 그룹에 묶여 있다면 문제가 됩니다.

    해결책:

    • PCIe 슬롯 변경: 물리적으로 GPU를 다른 PCIe 슬롯에 꽂아보세요. 간혹 슬롯에 따라 IOMMU 그룹이 달라지는 경우가 있습니다.
    • PCIe ACS Override 패치: Proxmox 호스트의 커널에 PCIe ACS Override 패치를 적용하는 방법이 있습니다. 이 패치는 IOMMU 그룹을 강제로 분리시키는 역할을 하지만, 시스템의 안정성을 해칠 수 있으므로 ⚠️ 주의해서 사용해야 합니다. 저도 정말 최후의 수단으로 사용했던 기억이 있네요.

    3. 성능 저하 (병목 현상): 할당 리소스 점검

    Error 43은 해결했지만 막상 게임이나 AI 학습을 돌려보니 성능이 기대에 못 미친다면, 리소스 할당이나 설정 최적화를 의심해봐야 합니다.

    • PCIe 슬롯 대역폭: 혹시 GPU를 낮은 대역폭의 PCIe 슬롯(예: x16 대신 x8, x4)에 꽂은 건 아닌지 확인해보세요. 대역폭이 충분하지 않으면 GPU 성능을 100% 활용하기 어렵습니다. 메인보드 매뉴얼을 확인하는 게 가장 정확합니다.
    • CPU 코어/스레드 할당: VM에 충분한 CPU 코어와 스레드를 할당했는지 확인해야 합니다. VM에 CPU 코어를 너무 적게 주면 GPU가 아무리 좋아도 병목이 생겨요. 보통 물리 코어 수의 절반 이상을 할당하는 것이 좋습니다.
    • RAM 할당: VRAM(GPU 자체 메모리) 외에 VM에 할당된 시스템 RAM도 중요합니다. 특히 고사양 게임이나 AI 학습 시에는 충분한 RAM이 필수적입니다.
    • QEMU/KVM 최적화 옵션: VM 설정에서 QEMU 인자를 추가하여 성능을 최적화할 수 있습니다.
    • 
      qm set [VMID] -args '-cpu host,hv_time,hv_vapic,hv_spinlocks=0x1fff,hv_relaxed,hv_reset,hv_vpindex,hv_runtime,hv_synic,hv_stimer,hv_ipi,hv_eoi,pv_unhalt,kvm=off,l3-cache=on'
      

      이 옵션들은 KVM의 하이퍼바이저 기능을 최적화하여 게스트 OS의 성능을 향상시키는 데 도움을 줍니다. l3-cache=on은 L3 캐시를 활성화하여 CPU 성능에 긍정적인 영향을 줍니다.

    • Display Output (VMware/SPICE) 비활성화: Proxmox GPU 패스스루를 사용하는 경우, VM의 디스플레이 장치로 VMware나 SPICE 같은 가상 디스플레이를 켜두면 충돌하거나 불필요한 오버헤드가 생길 수 있습니다. 패스스루한 GPU를 유일한 디스플레이 장치로 설정하고, 다른 가상 디스플레이는 모두 끄는 것이 좋습니다.

    4. 사운드 장치 패스스루: HDMI 오디오도 잊지 마세요!

    대부분의 최신 그래픽 카드에는 HDMI나 DisplayPort를 통한 오디오 출력 기능이 내장되어 있습니다. Proxmox GPU 패스스루를 할 때 이 오디오 장치를 함께 패스스루하지 않으면, VM에서 소리가 안 나오거나 문제가 발생할 수 있습니다.

    확인 및 해결:

    1. lspci -nnv | grep -i audio 명령어로 GPU에 연결된 오디오 장치의 ID를 확인합니다.
    2. GPU의 비디오 장치와 오디오 장치가 같은 IOMMU 그룹에 속해 있는지 확인합니다. 대부분은 같은 그룹에 있습니다.
    3. VM 설정에서 GPU의 비디오 장치와 함께 오디오 장치도 PCI Device로 추가해줍니다. 이 두 장치를 모두 한 VM에 할당해야 정상적으로 소리가 나옵니다.

    ✅ 검증 및 결과 확인

    모든 설정을 마치고 디버깅까지 끝냈다면, 이제 Proxmox GPU 패스스루가 제대로 작동하는지 확인해볼 차례입니다. 게스트 OS에 접속해서 다음을 확인해보세요.

    • 장치 관리자 (Windows) / nvidia-smi (Linux): GPU가 정상적으로 인식되고 드라이버가 잘 설치되었는지 확인합니다. 더 이상 느낌표나 오류 코드가 없어야 합니다.
    • 벤치마크 툴: 3DMark, FurMark, Unigine Heaven/Superposition 같은 벤치마크 툴을 실행하여 GPU의 실제 성능을 측정해봅니다. 예상했던 성능 수치가 나오는지 확인하는 것이 중요합니다.
    • 실제 사용: 게임을 돌려보거나, AI 학습 스크립트를 실행해 보면서 체감 성능을 확인합니다.

    드디어 제대로 된 성능이 나오는 걸 보면 그렇게 뿌듯할 수가 없어요! 🎉 그동안의 삽질이 보상받는 느낌이랄까요? 저도 처음엔 수많은 시행착오를 겪었지만, 하나씩 문제를 해결해나가는 과정이 결국 저의 경험치를 올려주더라고요.

    Proxmox GPU 패스스루 후 게스트 OS 벤치마크 결과

    가상 머신 내부에서 실행된 벤치마크 프로그램의 결과 화면이에요. 패스스루된 GPU가 정상적으로 작동하면서 기대하던 성능을 제대로 내고 있는 모습을 볼 수 있습니다.

    마무리하며: 삽질은 경험치를 올려주는 최고의 자산!

    오늘은 Proxmox GPU 패스스루 설정 후 가상 머신에서 발생할 수 있는 성능 문제들을 디버깅하는 저의 경험을 공유해드렸습니다. 특히 NVIDIA Error 43과 같은 고질적인 문제부터 IOMMU 그룹 분리, 그리고 리소스 할당 최적화까지 다양한 관점에서 살펴봤는데요. 사실 이 모든 과정이 결코 쉽지는 않았습니다. 저도 수많은 밤을 새워가며 구글링하고, 포럼을 뒤적이며 해결책을 찾아다녔으니까요. 😅

    하지만 결국 이런 ‘삽질’들이 쌓여서 지금의 제가 될 수 있었다고 생각합니다. 단순히 기술을 적용하는 것을 넘어, 문제가 생겼을 때 스스로 해결할 수 있는 능력이 인프라 엔지니어에게는 가장 중요한 자산이거든요. 혹시 여러분도 Proxmox VFIO-PCI 설정에 어려움을 겪고 있다면, 오늘 제가 알려드린 팁들이 도움이 되었으면 좋겠습니다.

    다음번엔 오늘 다룬 Proxmox 그래픽 카드 패스스루를 활용해서 홈랩에 AI/머신러닝 작업 환경을 구축하는 방법에 대해 이야기해볼까 합니다. 그때까지 여러분의 서버실에 평화가 가득하기를 바랍니다! 궁금한 점이 있다면 언제든지 댓글로 남겨주세요. 제가 아는 선에서 최대한 도와드리겠습니다.

    Proxmox GPU 패스스루 문제 해결을 위한 디버깅 흐름도

    Proxmox GPU 패스스루 설정 시 발생할 수 있는 주요 문제점과 그 해결책을 시각적으로 정리한 흐름도예요. 디버깅 과정에서 어떤 순서로 체크해야 할지 한눈에 알 수 있게 정리했습니다.