미니 Windows PC로 NAS+홈서버 구축하기 (feat. Hypervisor Types)

어릴적부터 홈서버를 구축하고픈 생각은 있었으나, 집에 얹혀살던 당시 환경으로는 전자기기를 24시간 켜는 것이 허락되지 않았기 때문에 그렇게 하지 못했다.

그리고 이제 독립을 하게 된 지금, 홈서버를 올릴 수 있는 절호의 기회가 왔으나, 여러 일들로 바쁘고 귀차니즘이 도져서 1년이나 지금 이제서야 작업을 진행하였다.

글이 짧지 않은 걸 보면 알겠지만 생각 이상의 삽질을 하였다. 그래도 그만큼 얻은 것도 많았고 배운 것도 많았다. 혹여나 비슷한 작업을 하려고 하는 분들이나, 여러 선택지 사이에서 고민하는 분에게도 이 글이 도움이 될 거 같다.

0. 목표

귀차니즘이 매우 심해진 지금의 내 상황을 감안하여 아래의 요구사항이 필수적으로 만족되어야 했다.

• 자동화: 전원 버튼만 넣었을 때 알아서 모든 서비스들이 작동 준비 상태까지 올라갈 수 있어야 함
• 원격에서 재부팅 가능해야 함 (혹시 모를 문제 발생 시 대처 위함)
• 보안 위협에서 안전해야 함
• 모바일(아이폰)의 자료가 쉽게 백업 가능해야 함.
• 가성비

풀 원격 서비스를 지원할 기능에서 뺀 것 또한 보안 측면을 고려해야 일부러 배제한 것이다.

부차적인 요구사항들은 …

• 전성비 (적은 전력 소모량)
• 조용할 것

정도.

1. 하드웨어 구축

나에게 아직 NAS 및 홈서버는 있으면 좋고 없어도 되는 계륵같은 존재라, 최대한 저예산에 합리적인 가성비를 맞출 수 있는 시스템으로 구성하기로 했다.

이에 따라 사용한 준비물은 아래와 같다.

• N150 미니 피시 (SOYO M4 PLUS N150) (12만원)
  • RAM 16GB, SSD 512GB, Win 11 탑재, 내부 Nvme 슬롯 지원 등 나름 홈서버로서 갖출 스펙은 다 갖춘 스펙 충만한 녀석이다.
  • Idle 시 10W 가량의 전력을 먹기 때문에 비누진세 기준 월 2000원만 부담하면 되는 아주 저렴한 유지비 및 전성비.
  • 가벼운 다용도 작업을 할 생각이었고 (서버 및 가끔 게임 등의 쌀먹 작업), 사양이 그렇게 나쁘지 않아 Windows를 가급적 그대로 유지하고, OS 위에 VM을 올리는 식(Type-2 Hyper)으로 작업하기로 함.
  • Nvme 슬롯이 있어서 본격적으로 굴릴 각오가 섰을 때도 SATA 슬롯 확장을 통해 충분히 확장을 고려해 볼 수 있음
  • 핫딜로 12만원 주고 구매함. 근데 사놓고 한달째 썩혔다 …
• 8TB 시게이트 Barracuda 하드 (16만원)
  • NAS 하드로는 좋지 않은 선택이다. 전용 모델인 Ironwolf가 제일 합리적인 선택이지만, 하드나 NAS를 많이 사용할 예정이 아니라서 전원 인가가 많이 되지 않을 거라는 가정 하에 일반 하드로 일단 시작해 보기로 함.
  • 사놓고 한달째 썩히고 있었다. 최근 일이 많이 바쁘기도 했지만 이 정도면 진짜 심각한 귀차니즘 중증이다 …
• SATA to USB + 전원단자
  • 3.5” 하드의 경우 추가 전원 없으면 하드 구동 안 되니 주의. 하드 돌만한 전력이 미니PC의 USB에서 안 나옴.
• DAS (42000원)
  • 열도 많이 나는데 팬 하나 없고, 진동에 취약한 하드를 너무 홀대하는 것 같아 DAS를 가성비로 구매.
  • 알리익스프레스에서 적당히 RAID 기능 있는 모델 온갖 할인 다 먹여서 싸게 샀다. 모델은 MAIWO
  • 팬 속도 조절도 있고 RAID 세팅도 있고 있을 거 다 있어서 만족.
• 다이소 원목 컴퓨터 모니터 받침대 (3000원)
  • 뜬금없지만, 아래에 미니PC와 하드디스크를 쑤셔 넣기 매우 좋게 생겼다. 그것이 채택의 이유.
  • 또한 미니PC를 기존 공유기 있던 자리에 놓을 예정이었는데, 공유기의 발열이 꽤 심했기에 분리할 공간이 필요했다. 실제로 공유기 바로 위에 미니PC를 얹었더니 공유기 발열로 인해 PC의 팬이 엄청나게 돈다.
• 기타
  • 랜선
  • 메인 컴터에 쓰던 키보드 및 마우스
  • 잠깐 모니터에 꽃을 HDMI 케이블

총합 예산 약 30만원. 풀 세팅 전 구성은 아래와 같다. 이제보니 공유기가 너무 더럽다…

하드의 충격과 소음을 , 그리고 혹시 모를 미끄럼을 억제하기 위해 아랫단에 폼 테이프를 살짝 붙였다. 나쁘지 않다. 보다 나은 외형과 관리를 위해 이후에 본가에 있는 별도 하드 베이 케이스를 씌워줄 예정.

 

 

아래로 다 쑤셔넣고 나면 아래와 같이 적당히 깔끔한 그림이 나온다.

 

… 그런데 외장 하드를 아무래도 그냥 설치하는 것은 너무 보기가 좀 그래서 이후에 저렴이 DAS를 하나 사서 끼워 주었다. 이쯤 되니 공간이 모자라서 이렇게 어거지로 설치하게 되었다. 나중에 공유기를 다른 곳으로 이동시켜야 할 듯 하다.

 

2. 가상화 솔루션 선정

여기까지 왔으면 이제 가상화 솔루션을 정해야 한다. 근데 그 기준이 다소 복잡하다. 선택지에 종류는 2가지가 있으며 벤더사는 대략 5가지가 있는 듯 하다.

개인적으로는 VMWare Workstation 혹은 Proxmox를 강력히 추천한다. 각각의 특성을 개략적으로 아래 써 두었다.

먼저 Type-2 Hyper

• VMWare Workstation (Type-2 Hyper)
  • Type-2 중에서는 최고의 성능을 자랑한다고 보여진다. 개인적으로는 거의 Type-1 과 가까운 성능이 아닌가 생각됨.
  • N150 기준 1Gbps 대역폭 전부 뽑아낼 수 있을 정도의 처리 가능.
  • 개인 사용자 한정이나 정황상 라이선스가 점차 유료화되는 것으로 보여져서, 거부감이 들 수 있다.
• Windows Hyper-V (Type-1 Hyper)
  • Type-1 이지만 윈도우 내장 기능이라 유효한 선택지.
  • 성능 자체는 최고급 — 다른 Type-1 Hypervisor 들과 비교해서 전혀 꿇리지 않는다고 알려짐.
  • Hyper-V 자체가 Host OS를 Type-1 Hypervisor로 만들어 버리기 때문에 발생하는 여러 문제들이 있다. 다른 가상화를 돌릴 시 (e.g. 앱플레이어) 호환 문제, 게임 성능 저하 문제 등등… 이것 또한 감내하기에는 약간의 고민이 될 수 있음.
  • 설정, 특히 하드드라이브 부분이, 까다로운 것으로 보여서 일단은 관망중이다. 설치가 어렵다고 보여지며, VMWare Workstation 만으로도 필요한 성능을 잘 뽑아내 주고 있어서 꼭 사서 고생할 필요는 없어보임.
• VirtualBox (Type-2 Hyper)
  • 오픈소스였지만… 현재 오라클에 인수된 상태라 앞으로 어떻게 될지 🙃
  • 성능 저하가 매우 심각하다. NAS 용으로는 절대 추천하지 않음. (성능 관련하여서는 이 글 맨 마지막 문단 참고 바람)

아래는 훌륭하지만 요구사항을 충족(Type-2 Hyper)하지 못하여 탈락. 혹자는 걍 VM 위에 윈도우 올려도 되지 않냐고 하지만, 여러 제약사항들 및 사용패턴과 잘 맞지 않는 경우가 있는 것으로 보여 (e.g. VM인걸 인지하고 막히는 경우, VM위에 VM을 돌리는 경우가 되는 경우 …) 배제하였다.

• Proxmox (Type-1 Hyper)
  • 오픈소스 KDE 기반으로 만들어진 근래 가장 유명한 Hyper-1 형태의 가상화 플랫폼
  • 성능 원탑, 유지보수도 원탑급
  • 윈도우가 요구사항이 아니었다면 이거 썼다
• VMWare ESXi (Type-1 Hyper)
  • 마찬가지로 원탑
  • 다만 VMWare 라 기능 제한이 다소 걸려있어서, 삽질하지 않도록 사전에 확인이 필요함
  • 원칙적으로는 유료
  • 성능도 Proxmox가 요즘 더 나은 바로 알려져 있어서 꼭 필요한 상황 아니라면 다소 선호도가 밀리는 듯

이러한 후보들 중 모든 조건을 만족하는 것이 VMWare Workstation 뿐이었기 때문에, 이를 기반으로 작업하였다.

 

3. 헤놀로지 시스템 구축

본래 굳이 불법의 길로 빠지고 싶지는 않았으나, 아이폰의 사진을 주기적으로 백업할 수 있는 수단을 제공하는 게 시놀로지 앱을 이용한 시스템밖에 없더라 (…) 어차피 제대로 NAS 쓸 상황이 오게 된다면 대역폭의 한계 등으로 나중에는 시놀로지로 옮겨야 하기 때문에 필연적으로 갈아타야 되기는 하다.

어찌됐든, 헤놀로지 구축이다. 위에서 말했듯이 시스템 성능이 충분하고 다용도로 사용할 계획이었으므로 VM을 이용하여 세팅한다. 나는 VirtualBox + Redpill(xpenology) 구성으로 설치했다. 설치 자체는 2 페이즈 방식인데, 첫 번째는 부트로더를 빌드하는 과정이고, 두 번째는 부트로더를 통해 시놀로지 자체를 설치하는 것이다. 첫 번째 과정은 포트 7681 통해서, 두 번째는 포트 5000을 통해서 진행하게 된다. 전반적으로 인스톨러가 웹 브라우저 기반으로 돌아가는 것이 꽤 참신했고, 설치는 10~20분 내로 금방 끝이 난다.

부트로더 설치하는 방법은 수많은 사이트에서 다루고 있으니 굳이 언급하지 않도록 하지만, 만약 인스톨러 구동 중 “디스크 포멧 실패”와 같은 문제가 뜬다면, 부트로더의 SataPortMap 과 DiskIdxMap 의 설정을 바꾸어 줘야 한다. 나 같은 경우는 각각 88, 0000 으로 맞춰두었지만, 상황과 시대에 따라 어떻게 바뀔 지 모르므로 여러 확인이 필요함.

자세한 내용은 해당 포스트 참조: https://blog.noriarchive.com/2024/08/10/xpenology-설치/ 참고로 메인 저장소의 SATA PORT는 0:1 이든 1:0 이든 상관 없다.

이제 외장으로 물린 HDD를 VM에 passthrough 시켜서 인식시켜준다. 여기서 USB는 최적의 속도를 위해 3.0을 선택해 놓았고, 실제 장치의 USB도 3.0에 꽃아야 한다. 이를 결코 가벼이 여기면 안 되는게, 안 그러면 USB 2.0 대역폭의 10MB/s의 끔찍한 속도가 나올 것이다

나는 이미 연결이 되어 있어서 “Disconnect”로 뜬다. 참고로 아래 단에 있는 아이콘으로도 쉽게 USB passthrough를 설정할 수 있음.

이제 헤놀로지에서 인식이 되나 확인해보자. 인식한다! 야호! 하지만 사용할 수 없는데, 하드디스크가 포멧되어 있지 않기 때문이다.

 

내가 연결하려고 하는 하드는 8TB의 용량이가 FAT32로는 감당할 수 없다. EXT4로 하자.

 

포멧이 생각보다 시간이 좀 걸린다. 그래도 수 분 이내로 끝나면 정상 상태가 되면서 사용 가능해진다.

 

이제 헤놀로지에서 외장 하드 절전모드 설정 또한 해줬다. 개인용도로 쓸 DAS이기에 전력을 아끼고 하드를 오래 사용하기 위해서는 가급적 사용하지 않을 때 하드를 끄는 기능은 필수불가결이다. 다만 DAS 자체에서 파워 절전 기능이 있으니 안해줘도 되지 않나 싶은 의문이 들었지만, 그래도 해주는 쪽이 더 나을 것이라 생각했다.

 

이제 접속 확인을 하자. 모바일 앱으로도 접속이 되는지 확인. IP주소로도 접속해보고 Synology Drive 앱으로도 접속했을 때 잘 되는 것을 확인.

이제 기본적인 보안 설정을 해주자.

IP Block 횟수를 5번으로 줄이고, DoS 공격 방지도 켰다.

Firewall 로 들어가서 접속 가능한 IP를 남한으로만 한정시킨다.

가끔 출장/여행갈시를 대비해서 USA 및 일본을 허용하는 config를 하나 더 두었다.

추가로 휴지통에 파일이 은근 쌓이는 관계로 7일 된 것들 영구삭제하도록 작업 스케쥴러에 하나 추가해줬다. 이 정도면 관리 자동화는 끝.

4. Ubuntu 서버 구축

큰 작업은 어려울지라도, 간단하게 굴러가는 SSH를 구성하는 것 또한 목표중에 하나였기 때문에 바로 진행하기로 함.

그런데 Windows 11에서 Linux SSH를 구축하는 방법은 2가지가 있다.

1. Linux VM 사용하기
2. WSL 사용하기

그런데 최근 WSL의 제약이 많이 줄어들면서, 실사용 목적으로 써도 꽤 괜찮다는 이야기가 나오고 있다. WSL이 주는 두 번째 장점은 가상화 레이어가 적기 때문에 가볍다는 것이다. 리소스가 다소 박한 미니 PC에게는 다소 솔깃한 메리트이다.

그래서 나는 서버를 WSL로 구축하기로 했… 는데, 일련의 삽질 후 Hyper-V를 활성화해야 하는 것을 깨달았다. 그런데 이건 VirtualBox와 충돌하기 때문에 같이 쓸 수가 없다!!

그래서 곱게 [2]로 우회하여, VirtualBox에 Ubuntu 24 Server 설치 후, -2-에서 했던 것처럼 OS 설치를 해 주었다.

마지막으로는 보안 설정. 아래와 같은 요구사항을 고려하여 …

• 동일 IP에서 5번 이상 로그인 시도시 밴 (및 기록 남기기)
• 로그인 시 실패 기록 확인하도록 보여주기
• 그 이외 공격 시도 방지 (DDoS 등)

아래 작업을 해 주었다.

• https://softwcgcg.tistory.com/18
• https://darkenergy.tistory.com/24

여기를 참고하여 sshd_config 및 설정을 해 주고, fail2ban 설치해 주었다. 그리고 내가 주로 다니는 나라 (KR, JP, US) 이외의 모든 접속 시도는 싹 다 원천 차단함. 마지막으로 간단한 auditing command 묶음(who, last, ps , htop…)을 zshrc에 정의해 두어서 모니터링 쉽게 할 수 있도록 해놨다. 이 정도면 기본적인 처리는 끝.

 

5. VM 자동 시작

이제 VM이 시스템이 켜질 때 자동 실행되도록 해보자. VMWare의 경우에는 자체적으로 AutoStart를 위한 솔루션을 제공하고 있다. 방법은 https://blog.naver.com/rohdokhaeng/223532872068 를 참조. 참고로 계정 권한은 Administrator Group이면 딱히 정하지 않아도 된다.

또한 윈도우 서비스 방식으로 구동할 생각이라면, 윈도우 로그인 없이도 VBox가 돌아가도록 하기 위해서는 사용자의 로그온 여부에 관계없이 실행 체크를 해야 한다.

어느 방법이던 재부팅 후 약간의 시간 후에, 로그인을 하지 않아도 헤놀로지에 접근할 수 있었다면 성공.

5-1. 자동 USB Passthrough

Virtualbox에서는 한 번 USB passthrough한 저장소의 경우에는 알아서 머신이 켜질 때 passthrough되는 반면, vmware의 경우에는 그렇지 못한 것 같다 (Workstation 17 Pro 기준). 하지만 이를 위한 옵션이 있다. 다만 공개되어 있지 않고 숨겨져 있다.

먼저 USB passthrough할 장치의 정보를 알아내야 하는데, vmware log 파일에 해당 정보가 보통 나와 있다. 참고로 로그 파일은 .vmx 파일이 위치한 곳과 동일 폴더에 위치해 있다.

이제 이걸 가지고 vmx 파일에 아래 정보를 입력한다.

usb_xhci.autoconnect.device0 = "vid:0000 pid:0000"

그러면 다음에 VM을 켤 때부터는 해당 장치가 자동으로 mount 되는 모습을 확인할 수 있다.

출처: Auto Connecting Devices to a VMware Workstation VM |

1. 다만 15 이하 버전에서는 다른 필드를 쓰는 것으로 보이니 이 점 유의하여 사용 바람.
2. 그런데 이걸 쓰면 Auto Start on boot 가 실패할 때가 있는 듯 하다. 아마 디스크가 온라인 상태라서 VM이 점유에 실패하기 때문으로 추정되는데, 이 때는 [디스크 관리] 들어가서 드라이브를 오프라인 상태로 놓으면 보통 해결된다. 다음 부팅때도 offline 상태가 유지되기 때문이다.

물론 이런 거 안하고 쉽게 가려면, 아래처럼 그냥 physical disk 로 통째로 달아버리면 편하다.

하지만 나는 만약의 경우를 고려하여, Synology 포멧에 모든 데이터가 종속되는 걸 바라지 않는다. 다른 OS에서 파일을 접근하기 어려워지기 때문이다. 그래서 외장형으로 넣고 관리할 생각이기 때문에, 이 방식을 선호하지 않는다.

 

5-2. 자동 VM 머신 부트 스크립트

5-1 을 해도 가끔 서버가 제대로 켜지지 않는 문제가 확실히 발견되었으므로, 이걸 해결하기 위해서는 별도의 서드파티 모니터링 툴이 필요하다. 하지만 어째서인지 vmware에서는 해당 기능을 내장하고 있지 않는 듯 하다. 나름 상용 툴 아니었어…? 무료 라이선스라 없나?

아무튼 없으면 만들면 된다. 간단하게 만드려면 쉘 스크립트면 충분하지만 조금 더 풍부한 기능을 쉽게 넣기 위해서는 파이썬이 보통 가성비가 괜찮기 때문에 파이썬으로 스크립트를 짰다.

코드는 아래와 같다. Gist #

# This script aims for starting Vmware VM machines automatically if not running
# plus monitoring via web.

import os
import subprocess
from datetime import datetime
import time
import threading
from http.server import SimpleHTTPRequestHandler, HTTPServer
import json

# Put the path where vmrun.exe exists
VM_INSTALL_PATH = 'C:\\\\Program Files (x86)\\\\VMware\\\\VMware Workstation'

# Lists of VM to be monitored.
# NOTE: The "name" should be same to the vmx file with lowercase.
VM_LISTS = {
    'ubuntu': 'C:\\\\VM\\\\Ubuntu\\\\Ubuntu.vmx',
    'xpnology': 'C:\\\\VM\\\\Xpnology\\\\xpnology.vmx',
    }

# VM status to be shown via HTTP server
vm_status = {}

# Put the interval how often the VM status is being checked.
VM_MONITOR_INTERVAL = 1800 # 30m

# Define the port you want the server to listen on
PORT = 8000

_running = True

def busy_sleep(seconds: int):
    global _running
    start_time = time.perf_counter()
    end_time = start_time + seconds
    while _running and time.perf_counter() < end_time:
        time.sleep(1)

def get_running_vm_list():
    args = [f'{VM_INSTALL_PATH}\\\\vmrun', 'list']
    print(args)
    result = subprocess.run(args, capture_output=True, text=True, check=True)
    vms = {}
    for line in result.stdout.split('\\n')[1:]:
        line = line.strip()
        if line == '':
            continue
        filename = line.split('\\\\')[-1]
        vmname = filename.removesuffix('.vmx').lower()
        vms[vmname] = line
    return vms

def run_vm(vm_path: str):
    print(f'!! try to run VM: {vm_path}')
    args = [f'{VM_INSTALL_PATH}\\\\vmrun', 'start', vm_path, 'nogui']
    result = subprocess.run(args, capture_output=True, text=True, check=True)

def get_now_str():
    return datetime.now().strftime("%Y-%m-%d %H:%M:%S")

def monitor_main():
    global _running
    global vm_status
    print('Initial wait until system is on... (30s)')
    busy_sleep(30)
    while _running:
        now = get_now_str()
        try:
            vms = get_running_vm_list()
            for vm_name in VM_LISTS:
                if vm_name not in vms:
                    print(f'[{now}] {vm_name} is not running!! start to try run it...')
                    run_vm(VM_LISTS[vm_name])
                    vm_status[vm_name] = 'OFF'
                else:
                    vm_status[vm_name] = 'ON'
        except Exception as e:
            print(f'[{now}] !! Something unexpected happened: {e}')
        busy_sleep(VM_MONITOR_INTERVAL)

class VMStatusHandler(SimpleHTTPRequestHandler):
    def do_GET(self):
        global vm_status
        self.send_response(200)
        self.send_header('Content-type', 'application/json')
        self.end_headers()
        vm_status_str = json.dumps(vm_status, indent=4)
        self.wfile.write(vm_status_str.encode('utf-8'))

def websrv_main():
    server_address = ('', PORT)
    httpd = HTTPServer(server_address, VMStatusHandler)
    print(f'Serving HTTP on port {PORT}...')
    httpd.serve_forever()

def main():
    try:
        thr = threading.Thread(target = monitor_main)
        thr.start()
        websrv_main()
    except KeyboardInterrupt:
        print('SIGINT detected')
    except Exception as e:
        print(f'Unknown error: {e}')
    finally:
        global _running
        _running = False
    thr.join()
    now = get_now_str()
    print(f'[{now}] Bye!')

main()

보면 알겠지만 단순 서버 재시작 기능을 넘어서 모니터링 기능까지 포괄하고 있다. 서버는 그래야 하는 것이 철학이니까… 아무튼 호스트 운영체제에서 포트 :8000 를 서버에 할애하여 언제든 쉽게 해당 주소에 접속하여 vm 상태를 확인할 수 있다.

이제 해당 스크립트를 컴퓨터 부트 시 자동 실행되도록 하면 완벽할 듯 하다. [작업 스케쥴러]에 들어가서 적당히 아래와 같이 시스템 시작 시 실행되도록 하면, 윈도우를 켜기만 해도 vm이 자동으로 무조건 돌아가게 될 것이다.

참고로 VM이 보통 시스템 관리자 권한을 요구하는 경우가 많으므로, 해당 스크립트를 관리자 권한으로 실행되도록 하는 것을 추천한다.

6. 원격 데스크톱 구축

이제 슬슬 미니PC를 켜기가 귀찮아지기 시작하고 있다. 그렇기 때문에, 이제는 메인 데스크톱에서 메인 데스크톱을 필요시 접속할 수 있도록 구성을 하려고 한다.

시작메뉴에서 “원격제어” 접속하여 나오는 설정 들어간 후…

체크하면 끝.

원격접속 시에는 내 메인 PC로 미니 PC의 내부 IP 입력해서 접속하면 끝이다. 참 쉽죠잉.

참고로 Proxmox 에서도 원격 관리 툴을 제공하는 것으로 보인다. Tailscale 참고.

7. 공유기 설정

일단 DHCP를 통해서 내부 IP가 고정이 되도록 해야 한다. 상황에 따라 MAC 주소만으로 DMZ가 가능하여 굳이 필요 없다고 할지도 모르겠지만, 그럼에도 불구하고 내부 IP는 종종 사용하게 되는 수단이기 때문에 설정해놔서 나쁠 것은 없다.

반드시!! 브릿지로 설정된 VM의 MAC 주소에 IP를 할당하도록 하자. 호스트 컴퓨터의 MAC 주소가 아니다.

할당 후 공유기를 재시작했을 때 아래와 같이 DHCP에 의해 IP 고정 할당이 된 녀석이 VM 머신의 MAC 주소로 뜬다면 성공.

이후 포트포워딩을 설정해준다. 나는 보안을 위해 Synology 서비스와 SSH, HTTP 서비스 2개만 포트를 열어 놓았고, 시놀로지와 HTTP 같은 경우는 조금이라도 덜 털려보고자 (…) 포트를 임의로 바꾸었다.

DMZ를 굳이 하지 않은 이유는, 특정 서버가 공유기의 모든 포트를 독점하는 것에 대한 거부감이 있는 것도 있지만, 포트를 많이 개방하는 만큼 외부 공격에 취약해지는 문제가 있어서이기도 했다.

가급적이면 쓰지 않는 문은 닫아두는 것이 안전하다.

 

8. 평가

이제 짧게는 하루, 길게는 한달여간 실생활 하면서 구축한 서버가 기준에 부합하는지 확인할 시간이다.

• [x] 미니PC 전원만 올리면 모든 기능이 자동으로 활성화 되는가?
• [x] 외부 IP로 시놀로지 및 SSH 서비스에 온전히 접근할 수 있는가?
• [x] 하루 이상 서버가 온전히 정상동작 하는가?
• [x] 속도가 정상적으로 나오는가? ⇒ 100MB/s 까지 잘 뽑힌다.
• [x] 붙어있는 외장 하드의 절전 모드가 정상적으로 작동하는가?

모두 성공이다! 미니 PC로 가벼운 수준의 헤놀로지 운영 못할 이유는 없어 보인다.

8-1. 외장 저장소로 연결 시 제약사항

현재 구성은 DAS를 Synology에서 USB 외장 저장소로 인식하고 있기 때문에 몇 가지 제약 사항들이 있는데, S.M.A.R.T 기능(베드섹터 탐지 등) 및 로컬 저장소에서만 지원되는 기능 (Synology Sharesync 라던가) 같은 것들이 되지 않는다. 이 점은 꼭 염두에 두어야 할 듯.

해결책이 있다. 이건 Host OS 에서 드라이브를 Offline 으로 만든 후, 해당 하드를 VM에 가상 드라이브로 통째로 attach 하면 된다. 참고로 VirtualBox 에서는 이는 미지원인 것으로 보임.

8-2. 미니 PC 모니터가 안 들어오는 경우

N150 미니피시에 올라간 윈도우 기준, 이 문제를 생각 이상으로 자주 겪어서 별개로 추가한다.

서버는 분명히 작동중인데 모니터가 안 돌아올 때는 CTRL + WIN + SHIFT + B 를 누르면 된다고 한다. 실제로 된다.

무슨 기능인가 찾아봤더니 그래픽 드라이버 재시작이라고 한다. 이런 기초적인 것이 원인일 것이라고 생각하지 않았는데… 미니PC 실사용은 아직 갈길이 멀어 보인다.

8-3. Ubuntu VM migration 이후 네트워크가 작동하지 않을 때

삽질 도중 Ubuntu ⇒ VMWare로 이미지를 migrate 했는데, 인터넷이 동작하지 않았다. 바로 ip addr 로 정보를 따 봤는데, 대충 ens160 이 디바이스가 브릿지 어댑터 정보를 물고 있는 것으로 보였으나 inet 필드로 아이피를 따오지 못하고 있었으며 무엇이 문제여서 인터넷이 안 되는지 알 길이 없었다.

혹시 디바이스명이 달라져서 무언가 세팅이 어긋난게 아닌가 해서 여러 정보를 찾다가 /etc/netplan/50-cloud-init.yaml 을 열었는데, 무언가 다른 디바이스명이 들어가 있어 바로 ens160 으로 고쳐주었다. (참고로 yaml 설정 파일명은 시스템마다 다를 수 있음)

이후 sudo netplan apply 하니까 잘 된다. 무언가 한 번도 본 적 없는 친구인데 네트워크의 전반적인 관리를 담당하는 녀석인 듯… 😅

 

9. 번외 — VirtualBox

VirtualBox 세팅은 아래와 같이 진행하였다. 사실 대부분의 설정을 크게 건드릴 필요가 없었기 때문에 딱히 쓸 내용이 많지는 않다.

외장으로 물린 HDD를 VBox에 passthrough 시켜서 인식시켜준다. 여기서 USB는 최적의 속도를 위해 3.0을 선택해 놓았다.

 

가상화된 네트워크 인터페이스가 CPU를 생각보다 많이 잡아먹기 때문에 대역폭에 중요한 영향을 끼치지만, 아쉽게도 그 중 가장 성능이 좋다는 VMXMET3은 VBox에서는 지원되지 않는 듯 하다. 그래도 그나마 성능이 가장 나은 virtio를 골라서 쓰자. 다만 내부 구현이 동일한지 다른 기본 Intel Adapter들과 별반 차이는 없는 듯 하다.

 

나머지 redpill을 이용하여 부트로더 빌드하고 시놀로지 설치하는 건 전부 동일하다. 오히려 virtualBox 의 경우 별도 커맨드 오버라이딩이 필요하지 않아 설치 자체는 더 편했음.

윈도우 부트 시 자동 실행은 서비스를 만들어서 쉽게 할 수 있다. 해당 포스트를 참고

https://cocatv.tistory.com/94

참고로 윈도우 로그인 없이도 VBox가 돌아가도록 하기 위해서는 사용자의 로그온 여부에 관계없이 실행 체크를 해야 한다. 재부팅 후 약간의 시간 후에, 로그인을 하지 않아도 헤놀로지에 접근할 수 있었다면 성공.

 

9-1. 하지만 속도가 …

다만 전송 속도 관련해서는 다소 미흡한 것으로 보인다. 웹으로 전송하든 SMB를 쓰든 속도가 30~35MB/s 가량 밖에 뜨질 않는데, 아무리 HDD라지만 보통 2배의 지속 전송 속도가 기대되는 바이기 때문에 어딘가에서 병목이 일어나는 것으로 추정된다. 아마 높은 확률로 네트워크 및 I/O 레이어에서 병목이 일어나지 않나 싶음. 역시 싼게 비지떡이라는 옛말 틀린 게 없다.

• 네이티브 디스크(SSD)에 쓸 때에는 70MB/s 가량의 속도가 나온다. 이것이 네트워크 상의 순수 속도 한계로 추정됨.
• SSD ⇒ HDD(외장)에 쓸 때에는 80MB/s 가량의 속도가 나온다. 이것이 HDD 및 USB 인터페이스의 순수 속도 한계로 추정됨.
• HDD에 쓸 때에는 35MB/s 가량의 속도가 나온다. 무엇인가 알 수 없는 병목요인이 있는 것으로 추정됨 … 캐싱이 비효율적인 것은 아닐까? 싶었으나, “지연 할당 활성화”를 켜도 딱히 속도의 변화는 없었다.
• 다운로드는 HDD와 SSD와 별반 차이가 없다. 똑같이 50~70MB/s 가량의 속도가 나옴.

못 쓸 수준은 아니지만, 대역폭의 절반도 못 뽑아내는 굉장히 아쉬운 수준이므로 반드시 염두에 둘 것!!

참고로 iperf로 네트워크 속도 측정도 해 봤는데 이 경우에는 초당 100MB 잘 뜨고 있어서 순수 Network 대역폭은 또 무난하다. 그럼에도 Host CPU를 거의 100% 쓰고 있는게 보여서, 여유로운 대역폭이 아니라는 것은 참고할 점.

또, 재미있는 벤치마크 결과를 발견하여 여기 적어둔다. https://xioustic.com/2019/06/07/windows-hypervisors-benchmarks/ 결과에 따르면 성능이 VMWare Workstation = Hyper-V >>> VBox >>> WSL 인데, 그만큼 VMWare Workstation이 호스트 운영체제에 잘 통합되었다고 볼 수 있는 근거일 듯.

특히 파일 복사 및 pipe 관련 작업에서 성능 차이가 두드러지는 모습이다.

9-2. VM이 안정적인가?

그렇다고 VM이 안정적인지는 확답하기가 다소 어렵다고 느껴진다. 생각보다 돌발적으로 시스템 폴트(BSOD…)가 발생하며 꺼지는 경우가 가끔가다 있었다. 고도로 Host OS(Windows)와 최적화되다 보니 성능을 챙겼으나 반대급부로 안정성 또한 약간 떨어지는 느낌이다.

여러 후기를 보았을 때 Proxmox가 이 모든 부분(성능 및 안정성 고려)에서 제일 나은 것으로 보여진다. 하지만 간혹 NAS를 굴리는 빈도라면, 이 정도도 쓸만은 하다.