네이티브와 가상화를 고민하는 분들을 위해 끼적이는 글

자주 올라오는 질문은 아니지만, 심심치 않게 보이는 질문이기도 하고

제목은 상관없어 보이는데 읽어보면 비슷한 내용이기도 한

DSM 네이티브 VS 가상화에 대해서 처음 NAS(서버)를 꾸리거나 가상화 경험이 없어 망설이는 분들을 위해

간단하게 장단점, 특징을 정리해보려고 합니다.

네이티브와 가상화 가리지 않고 공통으로 적용되는 장단점은 제외합니다.
가상화는 Proxmox 기준으로 설명합니다. ESXi는 하드웨어를 좀 많이 타서..

두괄식을 좋아하고 서두가 긴 거 짱 싫어하니까 바로 본론으로 갑니다.

네이티브

장점

1. 설치한 이후엔 쳐다볼 일이 없다
   → 무슨 말이냐면, 성공적으로 DSM을 설치한 이후엔, DSM 안에서 이것저것 올려보고 돌려보고 할 뿐이지, 모델을 바꿔서 로더를 리빌드 하지 않는 이상, 하드웨어를 건드릴 일이 딱히 없습니다. 고로 자연스레 NAS를 방 한 구석에 쳐박아두고 잘 안 건드리게 되죠. 나중에 하드웨어를 건드릴 일이 생겨서 꺼냈을 때 먼지 덮인 채로 나온다는 것만 빼면 이건 꽤 장점입니다. 유지보수에 큰 신경 안 쓰고 편리함을 얻으니까요.
   USB를 안에 감출까요 밖에 꽃을까요 같은 질문이 올라오는 것도 같은 맥락입니다. 만들어 놓은 뒤엔 뭐 딱히 건들일이 없으니 이런 질문이 나오는 겁니다.
   
   
2. DSM이 하드디스크에 원시접근권한을 갖는다.
   → 여타 가상화 기반 OS에서 DSM을 가상화로 설치 후 하드디스크 단위로 장치를 넘겨줄 땐 필연적으로 DSM 이전의 가상화OS가 원시접근권한을 가져갑니다. 이런 형태로 넘겨준다고 크게 문제가 발생하는 것은 아니지만, 이후 하드디스크를 떼었다 붙였다 하면서 DSM을 재구성할 때 온라인 어셈블이 작동하지 않을 경우가 생깁니다(하드디스크를 다른 모델로 인식해서). 네이티브는 그럴 일은 별로 없습니다.
   
   
3. 저전력, 저소음을 추구할 수 있다.
   → 저는 DSM6버전대부터 헤놀로지를 쓰다가 결국 돌고돌고돌고돌아서 지금은 EPYC서버를 한 대 사용하고 있습니다. 성능은 올라갔으나 집 안에 서버를 둠으로써 발생하는 소음과 전기료는 무지막지합니다. 다달이 기본 10만원 이상은 찍고 있으니까요. 물론 가상화를 한다 하더라도 일반 데스크탑 사양으로 만들면 '소음'은 어떻게 잡을 수 있겠지만, 그 역시도 전기료는 어느정도 각오하긴 해야 합니다.
   그러나, DSM을 네이티브로, 이것만 사용한다 하면 사실 그 용도와 목적 등을 생각할 때, 괜찮은 저전력 씨퓨정도로도 대부분의 수요자를 커버할 수 있습니다. 특히 요즘 핫한 N100시리즈 메인보드에 HBA카드 하나 달아주면, 90%의 사용자의 니즈를 커버하면서 전기요금을 줄일 수 있을 거라고 생각합니다.

단점

1. NAS는 NAS일 뿐이다.
   → 당연한 얘기이긴 한데, 사실 대부분의 사용자는 DSM에 있는 기능만으로도 차고 넘칩니다. 그러나 사용하다보면 이것도 해보고 싶고 저것도 해보고 싶은 것들이 많을텐데, DSM이 트윅된OS이다보니 도커를 사용한다 해도 평범한 리눅스 사용자와 동일한 사용경험을 얻을 수가 없습니다. 이거 생각보다 꽤 짜증납니다.
   예시로 VPN+Torrent 조합을 사용하시는 분들 꽤 많을텐데, VPN터널링을 위한 접속기로 사용할만한 이미지가 그닥 많지 않습니다. 대체로 gluetun이 뛰어난 사용성을 보여줍니다. 제가 1년 전에 올려드린 compose 구문도 gluetun을 사용합니다. 근데 gluetun은 일정시간이 지나면 피어를 못 찾게 됩니다(원인 모름 -_-; 컨테이너 재시작으로 해결).
   외부에서 내 네트워크 접근을 위해 wg-easy같은, wireguard를 구축하는 경우도 있을텐데, DSM은 이것도 spk파일을 구해 패키지를 설치해야 그 위에서 돌릴 수 있습니다.
   
   
2. 자원의 낭비
   → DSM을 구성하는 장비의 하드웨어 사양이 쓰레빠, i9 등등이라 하더라도 DSM만을 사용할 땐 이 삐까뻔쩍한 하드웨어들의 능력을 체감하는 것은 어렵습니다. 뻥 좀 보태면 i3-6100같은 씨퓨와도 별 차이가 안 느껴져요.
   그리고 꼭 이런 사양이 아니어도 서버포럼 분들이 제작을 고려하는 하드웨어 선택지들은, 대체로 그 사용목적에 비해 사양이 남습니다. 정품 시놀로지의 사양이 그따구인 이유도, 대체로 그 정도로도 사용목적은 충당하고 남기 때문입니다(물론 피크로 사양할 땐 모자랄 테지만, 항상 피크로 돌지 않으니까요).
   그러다보니, 남는 가용자원활용 + DSM외적인 서비스 지원을 위해 Docker와 VM에 눈을 돌리게 되는데, DSM에서 안돌아가는 Docker Image가 꽤 있고, VM도 생각보다 성능이 잘 나오질 않습니다. SSD 2개를 Raid 0으로 묶어 사용하면 쓸만하다곤 하나, 남는 자원을 활용하기 위해 또 다른 자원을 투입하는 꼴입니다.
   또, 일반 컴퓨터 메인보드이다 보니, USB포트 등과 같이 남는 포트가 꽤 많은데 이게 DSM 원툴일 땐, 정말 쓸 데 없습니다. 오히려 먼지만 끼어가서 마개로 막아줘야 할 정도죠. 로더를 빌드할 때, config에서 usb포트를 죽이고 외장하드를 꽃아서 풀로 활용할 수도 있지만, 별로 좋은 방법은 아닙니다. USB스피커를 연결해서 Audio Station으로도 사용할 수 있지만, 스피커를 4개씩 꽃을 건 아니니까요.
   없는 것만도 못한 DSM 네트워크 프린터를 쓸 것도 아니고....
   
   
3. 서비스가 죽는 경우가 생긴다.
   → DSM이 아니더라도 다른 가상화도 서비스가 죽긴 죽습니다. 근데 왜 여기다 기재하는가..?
   패키지 형태의 서비스가 생각보다 자주 죽습니다. 헤놀이라서 그런건지는 모르곘습니다만... Plex조차도 자주 죽습니다. 아니, 정확히는 제3자가 제공하는(커뮤니티 패키지 포함) 서비스들이 유독 자주 죽습니다. 시놀로지 자체 패키지도 뻗는 경우가 왕왕 있습니다. 웹 UI를 외부에서 접속할 수 있다면 다시 접속해서 살리면 되지만, 패키지 삭제 후 재설치 전엔 살아나지 못하는 경우도 있습니다. 
   업그레이드, 마이그레이션 중 죽어버리는 서비스가 발생할 경우엔 아예 실행이 불가능해지는 경우도 있고, 그 해결방법이 SSH로 접속해서 직접 OS파일을 건드리거나 재설치하거나 방법 등 뿐이라서, 네이티브에서 유지보수하려면 짜증을 유발합니다. 
   
   
4. 최신 드라이버 지원이 아무래도 더딥니다.
   → 항상 지원여부를 따지는 트랜스코딩을 예로 들면, 12,13세대 씨퓨를 쓰면 내장 그래픽을 이용한 트랜스코딩을 할 수 없죠. 설치할 때부터 드라이버가 없으니까. 그런데 DSM원툴이다 보니 이 위에 아무리 Plex를 용쓰면서 설치해봐야 HW 트랜스코딩을 할 수 없습니다. 

가상화

장점

1. DSM 하드웨어 호환성 이슈가 줄어든다
   → ARPL로 하니까 안되고 TCRP로 하니까 되더라... 혹은 TCRP로 하니까 되고 ARPL은 에러를 뿜더라... 둘 다 안되고 뭐시기뭐시기 이럴 일이 없습니다. 그냥 VM하나 만들고 설치하면 끝납니다. 그리고 로더 리빌드할 때 USB를 하나 더 사서 하나는 백업용으로 남겨두고 저걸로 해보고 안되면 이걸로 돌리고..... 안해도 되고 그냥 로더이미지파일 하나 더 불러오면 됩니다. 실패하면? 원래 쓰던 이미지파일로 부팅하면 끝.
   
   
2. HW 트랜스코딩을 위해 용쓸 필요 없습니다.
   → 무적권 헤놀 내에 Video Station을 쓰겠다면 얘기가 조금 다르긴 하지만, 그게 아니라면 윈도우던, 리눅스던 VM하나 만들고 헤놀의 파일만 마운트해온 뒤 Plex구축해서 사용하면 됩니다. 훨씬 간편하고, 더 고성능의 트랜스코딩을 사용할 수 있습니다. 애시당초 시놀 내부의 plex는 버전도 바로바로 쫓아가지 못하고, 같은 퍼포먼스에 더 많은 자원을 소모합니다.
   
   
3. 서비스 확장이 쉽다.
   → 2와 비슷한 논리인데, 사용해보고 싶은 도커 이미지가 DSM환경과 좀 어긋나거나 아예 실행이 안된다? 그냥 리눅스VM하나 만들어서 거기서 돌리면 됩니다.
   예를 들어, 리버스 프록시를 손쉽게 사용하기 위해 npm을 시놀로지 위에서 도커로 사용할 경우, web station과의 충돌이 있어 바로 사용하기 어렵겠지만, 리눅스를 사용하면 별 다른 이슈 없이 리버스 프록시를 세팅할 수 있습니다. 단위를 세밀하게 쪼개 쓰고 싶다면 코어1개에 512mb램 준 LXC한개로 돌려도 됩니다.
   또한, Proxmox에 한해(ESXi는 모름) 가상의 내부 브릿지를 통해 별다른 투자 없이도 내부 VM간에 10기가비트 통신을 할 수 있습니다. 파일 이동 시 초당 1기가로 이동한다는 뜻이죠(원본 및 대상 저장소의 속도가 받쳐준다는 가정 하에).
   그래서, 오히려 파일서버를 꼭 DSM에 맡기지 않을 수도 있습니다. 저같은 경우 TrueNAS로 파일을 관리하고 해당 폴더를 NFS로 읽기 전용으로 DSM에서 마운트 한 뒤, DSM에서 계정 권한 설정을 통해 외부로 공유해 줍니다.
   또, 윈도우VM에 그래픽카드를 패스스루 해준 뒤, 그 위에 블루스택 등을 돌려 모바일 게임을 자동으로 굴리고 있고, 또 다른 윈도우VM엔 파이썬 공부 관련하는 것들을 몰아놓고 공부할 땐 그 VM을 사용합니다.
   이런 것들은 헤놀로지만으론 하기 어렵죠.
   
   
4. 콘솔 접근이 손쉽게 가능하다.
   → 네이티브와 다르게 가상화는 콘솔에 손쉽게 접근해 로그를 얻어낼 수 있습니다. 트러블슈팅엔 이만한 장점이 없습니다. 또한 마찬가지로 모니터가 없어도 개별 VM의 화면을 출력해 볼 수 있으므로, 사용 상의 편의도 무시못합니다.
   
   

단점

1. 저전력과는 거리가 멀다(많이)
   → 가상화 하이퍼바이져는 자원을 효율적으로 분배하는 데 초점이 맞춰져 있지, 자원을 절약하진 않습니다. 그럴 목적도 없구요. 그래서 키워드가 저전력, 가정용에 맞춰져있다면 잠시 멈추고 고민을 해봐야 하는 부분입니다.
   나는 진짜, 사진백업정도 하고 깨작거리는 몇 가지 파일만 그 때 그 때 외부에 뿌려주는 정도면 된다 싶으면 네이티브로 가는게 맞습니다. 근데 하다보면 이거저거 하면서 늘어나는게 함정..
   
   
2. DSM공부만이 아니라 가상화공부도 해야 합니다.
   → NAS기능이야 DSM안에서 돌아가는 거니 그 부분을 따라가면 되지만, 하다보면 결국 그 DSM를 돌려주는 가상화OS에 대한 기본적인 조작법도 알아야 합니다. 세팅해놓으면 좋지만, 그 세팅에 걸리기까지 익혀야 할 것들이 늘어납니다.
   
   
3. 하드디스크에 대한 원시접근권한을 주기 어렵다.
   → 하드디스크 패스스루가 가능하긴 합니다. QEMU HARDDISK라는 이름으로 넘어간다는 것만 빼면요. S.M.A.R.T정보를 못 불러오게 되고 이걸로 레이드라도 걸었다간 리빌딩해야되는 경우가 왔을 때 제거할 디스크가 어떤 디스크인지 쉽사리 알기도 어려울 뿐더러, 최악의 경우엔 어셈블도 못하구 깨집니다.
   그래서 Proxmox에서 하드디스크 패스스루시에는 PCI-E를 패스스루하는 게 더 간단합니다. 오히려 컨트롤러부터 하드디스크까지 세트로 붙였다 뗏다 하며 편리하게 마이그레이션을 할 수 있긴 하지만, IOMMU Group이 동일한 다른 PCI장치가 같이 넘어가버리기도 하고, 메인보드 자체 SATA포트를 활용 하여 나스를 구축하려고 구상할 경우엔 패스스루가 조금 애매한 감이 있습니다. 
   
   

쓸 내용이 막 많았던 것 같은데 월급루팡하면서 쓰다보니까 두서도 없고 막 까먹고 그러네요.

제가 막 잘 아는 것도 아니고, 개인 경험에 기반한 서술이다보니 틀린 부분도 많을 거에요.

태클 환영합니다.