참고: 이 글은 2017년에 구축한 VM 환경을 설명합니다.

2020년 버전은 “Building a Homelab VM Server (2020 Edition).”을 참고하세요.

개요

집에서 하는 개발 작업 대부분은 가상 머신(VM)에서 한다. 메인 데스크톱 PC는 Windows 10 머신이라 지금까지는 VirtualBox 안에서 VM을 실행해 왔다.

이 구성으로도 잘 동작했지만, 점점 불편한 점들이 눈에 띄기 시작했다. 검색하다가 Brian Moses가 전용 ‘홈랩’ 서버를 만들어 VM을 돌린다는 글을 발견했다. 아이디어가 정말 마음에 들어 나도 같은 방식으로 해보기로 했다.

왜 VM인가?

깔끔한 환경

내가 작성하는 모든 소프트웨어는 특정 소프트웨어 환경에 의존한다. 예를 들어 내 프로젝트인 ProsperBot 개발에는 Go 툴체인, nginx, Redis가 필요하다. 각 프로젝트의 의존성을 메인 데스크톱 PC에 계속 설치하다 보면 서로 다른 웹 서버, 데이터베이스 서버, 그리고 동일 라이브러리의 경쟁하는 버전들이 뒤엉켜 엉망이 된다.

보안: VM 격리

VM은 소프트웨어를 메인 시스템으로부터 격리해 보안 측면에서도 도움이 된다. 새로운 도구나 앱을 실험하는 걸 좋아하는데, 앱이 악성일 가능성은 늘 있다(개발자가 악성 앱을 만들었을 수도 있고, 정상적인 앱이라도 공격자가 악성코드를 유포하도록 변조했을 수도 있다). 앱을 Windows 머신에 직접 설치했는데 악성코드에 감염되면 그대로 끝이다. 머신에서 동작하는 아주 기초적인 악성코드만으로도 화면의 모든 내용을 기록하거나, Gmail, Facebook, GitHub을 장악하거나, 모든 파일을 인질로 잡을 수 있다.

VM 안에서 동작하는 악성코드가 일으킬 수 있는 피해는 훨씬 제한적이다. VM에 소프트웨어를 설치했는데 몰래 키로거가 설치되더라도, 메인 데스크톱 머신이 아니라 해당 VM 안에서 입력한 키스트로크만 기록할 수 있다. VM이 완전한 방어책은 아니다. 고도화된 악성코드는 VM을 탈출할 수도 있지만, 그럼에도 상당한 수준의 보호를 제공한다.

왜 별도의 VM 서버인가?

그동안 메인 Windows 데스크톱에서 VirtualBox로 가상 머신을 돌려 왔는데, 몇 가지 문제가 있었다:

• 메인 PC를 재시작할 때마다 실행 중인 모든 VM을 일일이 종료하거나 절전 모드로 전환한 뒤, 재부팅 후 다시 하나씩 켜야 했다.
• 메인 PC는 한 달에 한 번 정도 다운되는데, VirtualBox는 비정상 종료 후 복구에 매우 취약하다. 재부팅하면 VM 이미지 파일이 잠겨 있다고 인식해 파일 시스템을 일일이 만져 문제를 해결해야 했다.

전용 VM 서버가 있으면 최소한의 Linux 서버 OS만 올려둘 수 있다. 머신에서 실행되는 소프트웨어가 적을수록 재부팅이 필요한 빈도도 줄고 다운될 가능성도 낮아진다.

개인적으로 흥미롭게 보는 P2P 프로젝트들도 있다(예: OpenBazaar, BitSquare). 하지만 이런 프로젝트들은 서버를 항상 켜둬야 한다. VirtualBox로 시도해 본 적은 있지만, 앞서 언급한 번거로움 때문에 이런 VM을 계속 유지하려는 의욕이 금방 사라지곤 했다. VM을 한 번 띄워두고 그냥 계속 돌릴 수 있다면 이런 프로젝트를 실험하는 것이 훨씬 매력적으로 느껴질 것이다.

부품 선택

CPU

Brian의 블로그 글에서는 중고 Intel Xeon CPU의 저렴한 가격을 활용할 수 있다는 점에 들떠 있었다. 흥미로운 아이디어였지만, 중고 서버 하드웨어의 고장 위험이 걱정돼 신품 리테일 CPU를 선호했다.

메인 PC에서는 CPU를 오버클럭해서 쓰지만, 그 때문에 가끔 다운되기도 한다. VM 서버는 최대한 안정적으로 유지하고 싶었기 때문에 이번 시스템은 오버클럭하지 않기로 했다. 덕분에 부품 선택이 더 쉽고 저렴해졌다. 잠금 해제된 CPU나 오버클럭을 지원하는 메인보드, 고급 CPU 쿨러에 프리미엄을 지불할 필요가 없어졌기 때문이다.

결국 AMD Ryzen 7 1700을 선택했다. 8코어 16스레드라 여러 VM을 돌리기에 적합해 보였고, 요즘 좋은 평가를 많이 받고 있기도 했다.

메인보드

나는 맨해튼의 작은 원룸 아파트에 살고 있어 물리적 공간이 매우 부족하다. 내 요구사항 덕분에 디스크 드라이브, GPU, 고급 CPU 쿨러처럼 보통 PC에서 많은 공간을 차지하는 부품들이 필요 없어졌다.

이런 조건 때문에 MicroATX 메인보드를 알아보게 됐고, 최종적으로 ASRock AB350M-HDV를 선택했다. 과거에 ASRock 보드를 써 본 경험이 좋았고, 이 제품도 안정적인 선택처럼 보였다. 메모리 지원이 다소 망설여졌는데, RAM 슬롯이 두 개뿐이라 16GB 스틱 두 개를 끼우면 확장 여지가 없기 때문이었다. 그래도 나중에 RAM이 부족해지면 그때쯤엔 32GB 스틱 두 개가 나와 있을 테니 그냥 두 개 다 교체하면 되겠다고 생각했다.

돌이켜보면 내장 그래픽이 있는 메인보드를 살 걸 하는 아쉬움이 남는다(부품 평가 참고).

메모리

메인 PC는 RAM이 32GB이고, 일상적인 사용 중에는 Windows 10에 여러 VM을 띄운 상태에서도 15GB 정도를 쓴다. 16GB로도 충분할 것 같았지만, 앞으로 2~3년을 고려하면 32GB가 안전한 상한선이라고 판단했다. G.SKILL Flare X Series 32GB (2 x 16GB)를 선택한 이유는 내 메인보드와 호환성이 테스트된 RAM 중 가장 빠른 제품이었기 때문이다.

디스크

Brian과 마찬가지로 NAS에 충분한 공간이 있기 때문에, 로컬 저장소는 호스트/하이퍼바이저 OS를 담을 작은 디스크만 있으면 됐다. 250GB Samsung 850 EVO를 선택한 이유는 M.2 인터페이스가 매우 깔끔했기 때문이다. 메인보드에 나사로 고정하는 칩 하나면 끝이고, 브라켓이나 SATA 케이블을 다룰 필요가 없다. 250GB는 필요 이상으로 크지만, M.2 SSD에서는 그 정도가 사실상 진입 용량인 듯했다.

케이스

케이스는 무엇보다 아주 작은 것을 찾았다. 서버를 눈에 띄지 않는 곳에 숨겨둘 계획이라 예쁘거나 화려할 필요는 없었다. Rosewill Micro ATX SRM-01은 작고 저렴하면서 기능적으로도 충분했다.

그래픽

이 시스템은 대부분 헤드리스로 두고 SSH/Ansible로 관리할 계획이지만, 가끔은 디스플레이가 필요하다(예: 초기 설치 시나 네트워크 설정을 잘못 건드렸을 때). 처음에는 메인보드의 내장 그래픽을 쓸 수 있을 줄 알았는데, 그게 아니었다(부품 평가 참고).

GPU에 대한 요구사항이 유연했기 때문에, 그냥 저렴하면서 평가가 괜찮은 제품을 원했고 EVGA GeForce 8400 GS를 선택했다.

이 시스템을 위해 별도의 모니터를 사는 건 말이 안 됐다. 99.99%의 시간은 헤드리스로 관리할 텐데, 나머지 0.01%의 시간에는 그냥 책상 밑으로 기어들어가 메인 모니터의 HDMI 케이블을 주 데스크톱에서 VM 서버로 옮겨 끼우면 되기 때문이다.

네트워크 어댑터

네트워크가 1Gbps라 메인보드의 온보드 1Gbps NIC을 그대로 쓸 계획이었다. Ubuntu 16.04에서 별 문제 없이 동작하긴 했지만, 곧 속도가 10Mbps 정도로 제한되는 것을 알게 됐다. 조금 알아보니 Ubuntu 16.04에 올바른 드라이버가 포함되어 있지 않았고, 별도의 apt-get 저장소를 추가해 r8168-dkms 패키지를 설치해야 했다. 그렇게 설치는 했지만 재부팅하니 Ubuntu가 NIC을 아예 인식하지 못했다…

이쯤 되니 온보드 NIC을 붙잡고 씨름하는 데 지쳐, Ubuntu에서 바로 지원된다고 본 PCI NIC을 하나 샀다. Broadcom BCM5751 Netxtreme이다. 별다른 손댈 것 없이 바로 1Gbps 속도가 나왔고, 23달러에 이 정도면 온보드 NIC 문제를 계속 파고드는 것보다 낫다고 판단했다.

참고로 온보드 NIC은 ESXi 6.5와 호환되지 않았지만, Broadcom NIC은 호환됐다.

최종 부품 목록

조립

모든 부품을 갖추고 조립을 시작했다!

조립 전 모든 부품이다. 실제로 시스템을 구동해 보기 전까지는 필요하다는 걸 몰라서 NIC과 GPU는 이 사진에 빠져 있다.

모든 부품을 조립한 서버 모습이다. 부품 수가 많지 않아 볼품은 없다. 유일한 디스크가 메인보드에 직접 연결된 M.2 SSD라 전원이나 SATA 케이블을 다룰 필요가 없어 특히 편했다.

아파트 공간이 협소해 서버를 눈에 띄지 않게 숨기고 싶었다. 책상 서랍 뒤, 책상 옆 공간에 두기로 했다. 메인 데스크톱만큼 손이 닿는 곳에 있으면서도 대부분은 시야에서 가려진다:

호스트 OS 설치

VM 서버의 호스트 OS는 최대한 가벼워야 한다. 하이퍼바이저를 올리는 게 주 역할이고 그 외에는 별로 할 일이 없다. 호스트에 소프트웨어를 많이 추가할수록 안정적인 서버를 위해 계속 업데이트해야 할 패키지도 늘어나기 때문이다.

몇 가지 Linux 배포판을 시도해 봤지만, 내 하드웨어에서 바로 설치되는 것은 Ubuntu 서버뿐이었다(16.04와 17.04 모두 성공). Ryzen의 SMT 기능 때문에 다른 배포판의 설치가 실패하는 것 같다. BIOS에서 SMT를 끄고 다른 배포판을 설치한 뒤 커널을 4.10 이상으로 업그레이드하고 다시 SMT를 켜면 우회할 수 있을 것 같았지만, 어차피 가장 익숙한 배포판이기도 해서 그냥 Ubuntu 16.04 server를 쓰기로 했다.

가상 머신 실행

KVM

하이퍼바이저로는 KVM을 사용했다. 꽤 성숙한 제품이고 사용자층도 넓어, 문제가 생겼을 때 검색으로 해결책을 찾기 용이하다. 일부 엔터프라이즈용 하이퍼바이저는 소프트웨어 자체가 무료라도 라이선스 키가 필요하지만, KVM은 무료 오픈 소스라 그런 문제가 없다.

Kimchi

인프라를 웹 UI로 관리하는 걸 선호해서 KVM의 HTML5 기반 관리 UI인 Kimchi를 설치했다.

Kimchi에 대한 평가는 “무난하다” 정도다. 대시보드 중 일부는 꽤 멋지다:

브리지 네트워크 어댑터를 만드는 것처럼 커맨드 라인에서 다소 까다로운 작업도 잘 처리해 준다.

약점은 주로 UX에 있다. 간단한 작업을 하는 데도 클릭을 많이 해야 하고, 페이지가 업데이트되면(예: 게스트 VM 종료가 완료되면) 컨텍스트 메뉴가 사라져 흐름을 처음부터 다시 시작해야 하는 경우가 잦다. 약점이 아주 심한 편은 아니고, 쓰다 보니 이런 UX 버그를 피하도록 행동을 조정하게 됐다.

그 외 후보: ESXi 6.5

사실 이 프로젝트를 시작할 때는 VMware의 무료 하이퍼바이저인 VMware vSphere Hypervisor를 쓸 계획이었다. 훨씬 성숙한 제품이고 사용자층도 더 크니(아마 지원 정보를 찾기 더 쉬울 것이다) 그렇게 생각했다. 하지만 결국 내 메인보드 NIC과 Ryzen CPU 모두와 호환되지 않았다. Broadcom NIC을 설치하고 BIOS에서 CPU의 SMT를 끈 뒤에야 겨우 실행할 수 있었는데, 그때는 이미 Kimchi를 며칠 써 보고 익숙해진 뒤였다.

vSphere가 Kimchi보다 경험이 월등히 낫다는 느낌은 없었다. UI는 훨씬 세련됐지만, 역시 한 번 실수하면 전체 다단계 프로세스를 처음부터 다시 시작해야 하는 번거로운 흐름이 있었다. 또 셸에 접근해 커맨드 라인에서 원하는 작업을 바로 하는 방법도 명확하지 않았다(분명 가능하겠지만, 답을 찾을 때까지 오래 파고들진 않았다).

결정적인 이유는 로그인하자마자 vSphere가 VMware 등록 키를 입력하지 않으면 60일 후 소프트웨어가 동작을 멈춘다는 경고를 크게 띄운다는 점이었다. VMware는 무료로 라이선스 키를 제공하지만, Kimchi는 어떤 라이선스 확인에도 묶여 있지 않고 vSphere와 비슷한 경험을 제공하는데 굳이 등록 키를 다룰 필요가 없다고 판단했다.

서버 프로비저닝 자동화

나는 Ansible을 즐겨 쓰기 때문에 VM 서버를 자동으로 프로비저닝하는 Ansible 플레이북을 작성했다. 하는 일은 다음과 같다:

• Ryzen의 SMT 기능과 호환되는 버전으로 커널 업데이트
• KVM과 Kimchi 설치
• VM 이미지를 저장할 NFS 공유 마운트

아래 명령을 실행하면 같은 플레이북으로 서버를 프로비저닝할 수 있다. 먼저 Ansible을 설치한 뒤:

VM_SERVER=vmaster # Replace with your VM server's hostname
echo "${VM_SERVER}" > hosts
wget https://mtlynch.io/files/provision-vm-host.yml

# Replace the extra-vars with the values for your NFS share
ansible-playbook provision-vm-host.yml \
  --extra-vars "cifs_share=/nas-hostname/VMs" \
  --extra-vars "cifs_username=foo" \
  --extra-vars "cifs_password=bar"

선택 되돌아보기

평가: CPU

가장 고민되는 선택은 CPU다. 속도는 매우 빠르지만 다소 과했을 수도 있다. CPU 집약적인 작업을 여러 VM에서 동시에 돌려도 전체 CPU 사용률이 35%를 넘은 적이 없기 때문이다.

Ryzen의 단점은 지금 매우 최신 제품이라 호환성이 불안하다는 점이다. Fedora 25 server, Debian 8.7, Centos 7, ESXi 6.5를 설치해 봤지만 모두 Ryzen과 호환되지 않아 설치 도중 실패했다. BIOS에서 SMT(멀티스레딩)를 끄면 일부는 성공적으로 설치됐지만, 그러면 16스레드에서 8코어 CPU로 줄어드는 셈이라 아쉬웠다. 성공적으로 설치된 OS는 Ubuntu뿐이었다(16.04와 17.04 모두 성공).

Ryzen 때문에 살 수 있는 RAM 종류도 제한됐다. 메인보드는 DDR4 RAM을 최대 3200MHz까지 지원하지만, Corsair에는 이와 호환성이 테스트된 메모리가 하나도 없었다. G.SKILL에는 있다지만 DDR4 2400MHz보다 빠른 제품은 없었다.

평가: 메인보드

메인보드 선택에는 대체로 만족한다. 모든 부품을 위한 충분한 공간을 희생하지 않으면서도 작고 컴팩트하다.

유일한 후회는 온보드 비디오 지원을 꼼꼼히 읽지 않은 것이다. “Onboard Video Chipset” 항목의 사양에는 이렇게 적혀 있었다:

Integrated AMD Radeon R7/R5 Series Graphics in A-series APU Supports HDMI with max. resolution up to 4K x 2K (4096x2160) @ 24Hz / (3840x2160) @ 30Hz

그래서 “오, 자체 그래픽 카드가 있네. 설치할 부품 하나 줄었네”라고 생각했다. 그런데 이 문구가 의미하는 바는 “AMD A시리즈 APU가 있을 때만 그래픽을 지원한다”는 뜻이었다. APU는 AMD의 CPU/GPU 결합 칩이고 Ryzen은 이에 해당하지 않으므로, 내겐 온보드 그래픽이 없었다.

다시 한다면 온보드 GPU가 있는 것만으로도 단순해지는 GIGABYTE GA-AB350M-Gaming 3를 선택할 것이다.

평가: RAM

32GB는 처음엔 과해 보였지만, 여러 용도로 VM을 추가하다 보니 RAM 사용량이 18GB를 넘고 있어 16GB 대신 32GB를 선택하길 잘했다고 생각한다.

평가: 파워 서플라이

파워 서플라이는 시스템에 충분한 용량을 제공하고 비교적 조용하다. 30달러에 가격도 괜찮다.

한 가지 단점은 비모듈러 케이블을 쓴다는 점이다. 시스템 자체가 워낙 최소 구성이라 필요한 건 24핀 메인보드 케이블과 8핀 CPU 케이블뿐이다. 나머지는 모두 거추장스럽지만, 케이스의 5.25인치 광학 드라이브 베이(당연히 내 경우엔 비어 있다)에 깔끔하게 숨길 수 있었다.

다시 한다면 불필요한 케이블을 제거할 수 있도록 세미 모듈러나 풀 모듈러 PSU를 고려할 것이다.

결론

이 홈랩 VM 서버는 매우 잘 동작하고 있다. VM이 항상 실행 중이라는 걸 알 수 있어 VirtualBox에서 뭔가를 띄울 필요 없이 바로 SSH로 접속하거나 브라우저에서 확인할 수 있어 매우 편리하다.

예상치 못한 장점 중 하나는 더 이상 게스트 OS에 할당할 CPU/RAM 자원을 아껴 쓸 필요가 없다는 점이다. 메인 데스크톱은 8코어 i7에 RAM 32GB다. VM이 메인 OS의 자원을 고갈시키는 걸 원치 않아 보통 게스트 OS에 1 CPU + 1GB RAM만 할당하고, 자원 부족이 보일 때만 늘리곤 했다. 홈랩 VM 서버에서는 자원이 충분하니 모두가 넉넉하게 쓸 수 있다! 이제 표준 게스트 OS 템플릿은 4코어 4GB를 사용하고, 이는 대부분의 환경에 충분한 상한선이다. 덕분에 게스트 OS 자원을 수동으로 관리하는 데 들이던 시간을 아낄 수 있다.

다양한 개발 또는 스테이징 환경이 필요한 소프트웨어 프로젝트를 한다면, VM에서 작업하고 전용 VM 서버 머신을 사용하는 것을 적극 추천한다.