Synology VDSM: AI를 활용한 Docker 마이그레이션 및 가상 디스크 크기 조정(2026)

가상 NAS는 사람들이 한 번 설치하고 오후 시간 정도 만져보다가 잊어버리는 기능 중 하나입니다. 하지만 Synology VDSM(Virtual Machine Manager 내에서 실행되는 Virtual DSM)은 소규모 셀프 호스팅에서 가장 성가신 두 가지 문제를 조용히 해결해 줍니다. 첫 번째는 Docker 스택을 머신 간에 이동하는 데 보통 저녁 시간까지 걸리는 번거로운 작업입니다. 두 번째는 가상 디스크 공간이 부족해지면 대부분 전체를 재구축해야 한다고 생각한다는 점입니다. VDSM에서는 둘 다 해당되지 않습니다. 이 가이드에서는 약 35분 만에 완료한 실제 마이그레이션 과정을 설명합니다. AI 어시스턴트가 셸을 제어하는 Redmine 내부 이슈 트래커(플러그인 5개 포함)를 한 VDSM 게스트에서 다른 VDSM 게스트로 옮기는 작업입니다. 도중에 대상 시스템의 디스크 공간이 부족해지자 가상 디스크를 10GB에서 20GB로 확장하고 마이그레이션을 계속 진행했습니다. 아래 내용은 실제로 발생한 모든 상황이며, 애플리케이션을 조용히 파괴할 뻔했던 함정까지 포함합니다.

SynoPower Club 포인트:많은 사람들이 NAS 가상화를 연구실용이 아닌 실제 업무용으로 생각하지 않아 포기하는 것을 보아왔습니다. 이 글에서 소개하는 마이그레이션은 실제 업무, 즉 세 명의 동료가 매일 사용하는 티켓 시스템에 적용한 것이었습니다. 저를 놀라게 한 것은 AI가 아니라 VDSM이 얼마나 간단하게 작업을 완료할 수 있는지였습니다. 하이퍼바이저 라이선스도 필요 없고, 별도의 관리 서버도 필요 없으며, 호환되지 않는 포맷 간의 내보내기/가져오기 과정도 필요 없었습니다. 작업 도중 게스트 OS 디스크 용량이 부족해졌지만, 실행 중인 상태에서 텍스트 필드에 더 큰 값을 입력하는 것만으로 해결했습니다. 전체 작업은 35분밖에 걸리지 않았고, 아무도 알아차리지 못한 것은 관련 없는 웹사이트에서 90초 정도 접속이 끊긴 것뿐이었습니다. 만약 이미 여유 메모리가 있는 Synology NAS를 보유하고 있다면, 패키지 하나만 설치하면 이 작업을 바로 시작할 수 있습니다.

Synology VDSM이란 무엇인가요?

VDSM은 Synology의 Virtual DSM와 같은 역할을 합니다. 물리적 NAS의 Virtual Machine Manager 내부에 게스트 운영 체제로 실행되는 DiskStation Manager의 완벽한 복제본입니다. 마치 별도의 NAS처럼 작동하며, 자체 IP 주소, DSM 로그인, 패키지, 컨테이너 관리자를 갖습니다. 네트워크 관점에서 보면 LAN에 또 다른 Synology가 연결된 것일 뿐이며, 하드웨어 관점에서는 이미 비용을 지불한 NAS에서 실행되는 추가 프로세스일 뿐입니다.

실질적인 이점은 격리에 있습니다. 모든 서비스를 호스트에서 직접 실행하면 컨테이너 하나라도 제대로 작동하지 않아 사무실 전체가 의존하는 파일 서버에 장애가 발생할 수 있습니다. VDSM 게스트에 워크로드를 분산하면 각 게스트에 메모리 용량, CPU 할당량, 디스크 공간을 할당할 수 있으며, 다른 게스트에 영향을 주지 않고 특정 게스트를 재부팅할 수 있습니다.

Virtual Machine Manager를 지원하는 모든 NAS에는 VDSM 라이선스가 하나 무료로 포함되어 있습니다. 두 번째 및 그 이후의 게스트 운영 체제를 실행하려면 추가 라이선스가 필요합니다. 유료 Virtual DSM 라이선스 각각. 단 하나의 무료 인스턴스만으로도 이 문서의 모든 내용을 따라할 수 있으며, 이것이 바로 많은 사람들이 이미 해당 기능을 보유하고 있으면서도 활성화하지 않은 이유입니다. 나중에 라이선스를 추가, 매핑 또는 매핑 해제해야 하는 경우, 관련 안내를 참조하세요. VDSM 라이선스 관리.

VDSM과 Virtual DSM는 같은 것을 가리키는 두 가지 이름입니다. Synology 자체 문서에서는 긴 명칭을 사용하지만, 대부분의 사용자는 짧은 명칭을 사용합니다. 이 약어는 oVirt 가상화 프로젝트의 관련 없는 다른 구성 요소와도 공유되므로, Synology NAS에서는 항상 Virtual DSM를 의미합니다.

유료 라이선스는 대부분의 사용자가 예상하는 방식과 다르게 작동합니다. 각 라이선스는 게스트 OS를 하나 추가하며 3년간의 Virtual DSM 소프트웨어 업그레이드를 포함합니다. 가상 머신은 만료되지 않으며, 3년 후에도 업데이트 없이 계속 실행됩니다. 새 라이선스 키를 활성화하면 3년간의 업데이트가 다시 시작됩니다. 라이선스 키는 한 번에 하나의 Synology NAS에서만 사용할 수 있으며, 라이선스 키를 추가할 때는 NAS가 온라인 상태여야 합니다.

VDSM 게스트에 대한 요구 사항은 간단하며, Synology는 해당 요구 사항을 안내문에 명시하고 있습니다. Virtual Machine Manager 사양:

• 가상 디스크는 Btrfs 볼륨에 있어야 합니다. Virtual Machine Manager는 게스트를 ext4에 저장하지 않습니다.
• NAS 자체에서 가상 머신을 실행하려면 2GB 이상의 메모리가 필요합니다.
• 각 게스트 운영체제는 최소 1GB의 메모리가 필요하며, 실제 작업 부하에는 그 이상의 메모리가 필요합니다.
• 모델이 원활하게 실행할 수 있는 게스트 수는 CPU와 설치된 메모리에 따라 다릅니다.

게스트 환경은 베어메탈에서 실행되는 DSM과 완전히 동일하지 않습니다. 세 가지 요소가 빠져 있는데, 이 모든 요소는 물리적 하드웨어와 관련이 있습니다.

• USB 패스스루 기능이 지원되지 않으므로 NAS의 USB 포트에 연결된 장치를 게스트 운영 체제로 전달할 수 없습니다.
• 제어판의 외부 장치 및 하드웨어/전원 페이지가 없습니다.
• 게스트 OS 내부에서는 무선 동글, MTU 설정 및 링크 어그리게이션(LACP)이 지원되지 않습니다. 호스트 OS가 물리적 네트워크를 관리합니다.

이러한 점들은 NAS를 실행하는 일반적인 이유에 영향을 미치지 않습니다. 파일 서비스, Docker, 메일 서버 또는 프로덕션 시스템의 스테이징 복사본은 모두 별도의 NAS에서 실행되는 것과 동일하게 작동합니다.

Synology VDSM과 두 번째 물리적 NAS: 어느 것이 필요할까요?

솔직히 말해서 가상 서버가 더 좋다는 비교는 아닙니다. 이는 복원력과 유연성 사이의 절충점입니다. 두 번째 물리적 서버는 첫 번째 서버에 장애가 발생해도 살아남지만, VDSM 게스트는 그렇지 않습니다. 하지만 게스트 서버를 사용하면 전체 서버를 며칠이 아닌 몇 분 만에 생성, 크기 조정, 스냅샷 생성 및 이동할 수 있습니다.

	VDSM 게스트	두 번째 물리적 NAS
하나 추가하는 비용	첫 번째 투숙객은 무료이며, 이후에는 라이선스가 필요합니다.	NAS 전체와 드라이브
준비 시간	분	배송일을 포함하면 일수는 다음과 같습니다.
CPU, RAM 또는 디스크 크기 조정	필드를 수정하고 게스트를 다시 시작하세요.	새 하드웨어를 구입하세요
호스트 하드웨어 장애에서도 생존합니다.	아니요	예
스냅샷 및 복제	Virtual Machine Manager에 내장됨	해당 사항 없음
다른 NAS로 이동	게스트를 마이그레이션하거나 복제합니다.	물리적으로 옮기세요
~에 가장 적합함	서비스 격리, 스테이징, 소규모 서버 통합	백업 대상 및 진정한 이중화

이 작업에는 선택이 명확했습니다. 기존에 VDSM 게스트 OS에 별도로 배포되어 있던, 사용 빈도가 낮은 이슈 트래커를 여유 용량이 있는 기존 웹사이트 게스트 OS로 통합하는 작업이었기 때문입니다. 이 작업에는 새로운 하드웨어가 전혀 필요하지 않았습니다. 10분 정도의 시간과 약간의 조정만 있으면 충분했습니다.

시작하기 전에 필요한 것

무엇보다 먼저, 본인의 로그인 정보를 제공하는 대신 어시스턴트에게 고유한 로그인 정보를 부여하세요. DSM에서 제어판을 열고 사용자 및 그룹으로 이동한 다음 만들기를 클릭합니다. 쉽게 알아볼 수 있는 이름으로 지정하세요. 저희는 다음과 같이 지정했습니다. 클로드 설명과 함께 AI 제어 — 그리고 DSM이 강력한 무작위 암호를 생성하도록 하세요.

다음 화면에서 체크 표시를 하세요. 관리자. 이는 선택 사항이 아닙니다. DSM은 관리자 그룹 구성원만 SSH를 통해 로그인할 수 있도록 허용하므로 해당 그룹에 속하지 않은 계정은 셸에 전혀 접근할 수 없습니다. 두 VDSM 게스트 모두에서 동일하게 설정한 다음 제어판 > 터미널 및 SNMP에서 SSH가 켜져 있는지 확인하십시오.

작업이 완료되면 계정을 비활성화하세요. 별도의 관리자 계정을 만드는 이유가 바로 그것입니다. 제어판에서 해당 사용자를 편집하고 권한을 끄거나 완전히 삭제하세요. 이렇게 하면 본인의 계정 정보는 건드리지 않고도 한 번의 클릭으로 접근 권한을 취소할 수 있으며, 관리자 계정이 수행한 모든 작업은 해당 목적으로만 존재하는 로그인 계정에 기록됩니다. 한때 편리했다는 이유로 관리자 계정을 영구적으로 활성화해 두는 것은 소규모 부동산 관리 업체들이 누가 권한을 부여했는지 기억하지 못하는 접근 권한을 축적하는 원인이 됩니다.

두 개의 VDSM 게스트가 있고, 두 게스트 모두 SSH가 활성화되어 있으며, 대상 서버에 Container Manager가 설치되어 있어야 합니다. 또한 처음에는 거의 모든 사람이 놓치는 한 가지 중요한 점을 알아야 합니다. Docker 바이너리는 DSM의 기본 PATH에 포함되어 있지 않습니다. 패키지 바이너리는 패키지 디렉터리 아래에 있으므로 모든 명령에는 전체 경로 또는 셸 별칭이 필요합니다.

환승 도중이 아니라 출발 전에 목적지에 좌석이 있는지 확인하세요. 아래 명령어는 전체 출발 전 점검 절차이며, 모든 VDSM 고객에게 동일하게 적용됩니다.

그 전에 한 가지 더 말씀드릴 게 있습니다. Virtual Machine Manager에서 두 손님의 사진을 찍으세요. 스냅샷 기능은 Virtual Machine Manager 무료 버전에서도 제공되며, Pro 버전뿐만 아니라 무료 버전에서도 사용 가능합니다. 게스트 OS당 최대 32개의 스냅샷을 저장할 수 있습니다. VDSM 스냅샷은 전체 시스템을 캡처하므로, 가져오기 과정에서 오류가 발생하거나 의도치 않은 명령 실행 시 게스트 OS를 재구축하는 대신 롤백할 수 있습니다. 롤백에는 몇 초밖에 걸리지 않으며, 전체 과정에서 가장 저렴한 보험과 같습니다. 소스 시스템뿐만 아니라 대상 시스템에도 스냅샷을 생성하세요. 소스 시스템은 백업 역할을 합니다.

# Docker가 DSM의 PATH에 없습니다. 전체 경로 D=/volume1/@appstore/ContainerManager/usr/bin/docker를 사용하십시오. # 현재 실행 중인 항목과 해당 항목의 원본은 무엇입니까? sudo $D ps -a sudo $D images # 대상 볼륨에 남은 공간은 얼마나 됩니까? df -h /volume1 # 대상 게스트에 실제로 사용 가능한 메모리는 얼마나 됩니까? free -m

VDSM Docker 마이그레이션 4단계

다음은 저희가 실행한 네 가지 단계이며, VDSM 게스트 간에 마이그레이션해야 하는 모든 컨테이너 스택에 적용할 수 있습니다. 순서가 중요합니다. 먼저 애플리케이션 컨테이너를 중지하여 덤프 도중에 데이터베이스에 아무것도 기록되지 않도록 하고, 데이터베이스 컨테이너는 실행 상태를 유지하여 깔끔하게 덤프할 수 있도록 합니다.

Compose 파일이 전체 컨테이너가 아닌 이유는 무엇일까요?

바로 여기에 함정이 있는데, 이것만으로도 충분히 흥미로울 겁니다. 저희 Redmine 스택의 compose 파일에는 두 개의 바인드 마운트가 선언되어 있습니다. 하나는 업로드된 파일용이고, 다른 하나는 데이터베이스용입니다. 이 파일을 읽어보면 새 게스트에 스택을 다시 생성하려면 두 개의 디렉토리를 복사하고 docker compose up 명령을 실행하기만 하면 된다고 생각하기 쉽습니다.

그렇지 않았습니다. 다섯 개의 플러그인, 해당 플러그인들이 불러오는 루비 젬, 메일 설정, 그리고 몇 가지 수정된 초기화 파일들이 모두 수년에 걸쳐 실행 중인 컨테이너에 직접 설치되어 있었습니다. 그 어떤 것도 볼륨에 저장되어 있지 않았습니다. 단 하나의 명령어로 상황이 얼마나 심각한지 알 수 있었습니다.

# 컨테이너와 해당 컨테이너가 생성된 이미지 간에 파일 차이가 몇 개입니까? sudo $D diff Redmine | wc -l 6764 # 컨테이너 내부에 있는 플러그인은 볼륨에 전혀 의존하지 않습니다. sudo $D exec Redmine ls /usr/src/redmine/plugins

최신 공식 이미지를 가져오면 해당 플러그인이 전혀 설치되지 않은 컨테이너가 생성되고, 마이그레이션으로 생성된 144개의 테이블이 그대로 남아 있는 데이터베이스를 가리키게 됩니다. 애플리케이션은 큰 오류 메시지를 표시하지는 않겠지만, 시작되어 거의 정상적으로 작동하는 것처럼 보이다가 결국 진단하기 어려운 방식으로 오류가 발생하게 됩니다. 실행 중인 컨테이너를 이미지에 포함시키면 이 문제를 완전히 해결할 수 있지만, 데이터 전송량이 증가합니다. 두 VDSM 게스트 간의 LAN 환경에서는 약 1분 정도 소요되므로, 이러한 단점을 감수할 만한 가치가 있습니다.

소규모 팀이 VDSM을 사용하여 서버를 통합하는 방법

이러한 마이그레이션 패턴은 대부분의 소규모 팀이 결국 필요로 하는 방식입니다. 몇 년에 걸쳐 위키용, 티켓 추적용, 모니터링 대시보드용 등 용도별로 게스트 운영체제를 하나씩 구축하게 됩니다(저희가 설명한 형태와 유사합니다). 홈 데이터 센터 둘러보기각각은 건설 당시에는 넉넉한 크기로 설계되었지만, 지금은 그 크기에 비해 극히 일부만 사용되고 있으며, 호스트는 과부하 상태에 빠져 모든 것이 약간 느리게 느껴집니다.

VDSM을 사용하여 통합한다는 것은 이미 활성화된 게스트 OS에 작업 부하를 통합하는 것을 의미합니다. 저희 티켓 추적 서비스는 하루에 몇 번, 세 명 정도의 사용자만 이용하는 서비스임에도 불구하고 자체 CPU 할당과 1GB의 메모리를 사용하는 게스트 OS 전체를 차지하고 있었습니다. 이를 기존 웹 스택 옆으로 옮기자 해당 할당이 완전히 해제되었고, 대상 컨테이너 두 개에서 약 480MB의 상주 메모리만 절약할 수 있었습니다.

이 방식을 안전하게 만드는 핵심은 소스를 계속 실행 상태로 두는 대신 적절하게 폐기하는 것입니다. 기존 컨테이너의 재시작 정책을 '아니오'로 설정하고, 컨테이너를 중지한 다음, 서비스가 이제 어디에 있는지 설명하는 텍스트 파일을 해당 디렉터리에 남겨두고, 자동 시작을 비활성화한 상태로 게스트 운영 체제를 종료했습니다. 이렇게 하면 완벽한 롤백 지점이 유지되며, 호스트 재부팅 후에도 조용히 다시 실행되어 새 인스턴스가 전혀 볼 수 없는 쓰기 작업을 수락하는 것을 방지할 수 있습니다. 중복된 데이터는 깔끔한 마이그레이션이 한 달 후 데이터 손실 사고로 이어지는 전형적인 원인입니다.

공간이 부족한 가상 디스크 크기 조정하기

작업 도중에 대상 영역의 공간이 부족해졌습니다. 해당 영역의 용량은 9.6GB였고, 남은 공간은 1.5GB에 불과했는데, 816MB 이미지 파일과 123MB의 애플리케이션 데이터를 추가하려는 상황이었습니다. 물리적 NAS에서는 새 드라이브가 도착할 때까지 이 시점에서 작업이 중단되지만, VDSM에서는 텍스트 필드에 해당 내용이 표시됩니다.

Virtual Machine Manager에서 게스트 설정을 열고, 저장 공간 탭으로 이동하여 새 크기를 입력하고 확인을 클릭합니다. 이를 위해 게스트를 종료할 필요는 없습니다. 가상 디스크는 시스템이 계속 실행되는 동안 크기가 커지기 때문에 하드웨어에 직접 용량을 추가하는 것과는 근본적으로 다른 경험을 제공합니다. 알아두어야 할 중요한 규칙은 가상 디스크는 크기만 커질 뿐 줄어들지 않는다는 것입니다. 따라서 되돌릴 수 없으며, 디스크 크기를 아끼지 않아도 됩니다.

진정으로 간편한 이유는 게스트 OS 내부에서 일어나는 일 때문입니다. DSM은 파티션과 파일 시스템을 자동으로 확장하여 새로운 공간을 채웁니다. 스토리지 관리자 마법사를 실행할 필요도 없고, 파티션 테이블을 편집할 필요도 없고, 볼륨을 재구축할 필요도 없고, 데이터를 마이그레이션할 필요도 없습니다. 저희 볼륨은 9.6GB(여유 공간 1.5GB)에서 20GB(여유 공간 13GB)로 확장되었고, 컨테이너는 계속 작동했습니다. 이것이 바로 서비스를 베어 하드웨어가 아닌 VDSM에 배포해야 하는 가장 강력한 이유입니다. 볼륨 크기를 잘못 설정하더라도 나중에 수정하는 비용이 저렴하기 때문입니다.

AI 비서가 실제로 한 일

여기서 정확한 설명을 덧붙일 필요가 있습니다. "AI가 서버를 옮겼다"는 말은 너무 쉽게 믿어질 수도 있고, 반대로 너무 믿지 않을 수도 있기 때문입니다. AI가 마법 같은 통찰력을 발휘한 것은 아닙니다. AI는 VDSM 게스트 두 대 모두에 접근 권한을 가지고 있었고, 하루 일과를 마친 피곤한 사람이 보통 하지 못하는 방식으로 체계적으로 작업을 수행했을 뿐입니다.

가장 가치 있는 기능은 아무것도 건드리기 전에 `docker diff` 명령어를 실행하여 6,764개의 변경된 파일을 발견하고, 명백한 변경 계획을 거부한 것입니다. `compose` 파일을 따르는 사람이라면 이 명령어를 실행할 이유가 전혀 없었을 것입니다. 두 번째로 가치 있는 기능은 검증이었습니다. 가져오기 후 양쪽 시스템의 테이블, 이슈, 프로젝트, 저널 항목 및 첨부 파일 수를 확인하고, 모든 첨부 파일이 디스크에 존재하는지 확인하고, 애플리케이션에 등록된 플러그인 버전을 나열하고, 보류 중인 데이터베이스 마이그레이션이 없는지 확인했습니다. 이는 매우 꼼꼼한 체크리스트이며, 오후 5시에 사람들이 가장 건너뛰기 쉬운 부분이 바로 이런 꼼꼼한 체크리스트입니다.

인간에게 여전히 필요한 것은 결과에 대한 판단력이었습니다. VDSM 게스트를 재시작하여 메모리를 추가하는 것은 운영 중인 웹사이트를 다운시키는 것을 의미하며, 이는 추측이 아닌 사용자의 의견을 구해야 할 결정입니다. 무엇이든 삭제하는 경우에도 마찬가지입니다. 어시스턴트는 매우 빠르고 정확하게, 끊임없이 확인하는 손과 같다고 생각하고, 돌이킬 수 없는 결정은 직접 내리도록 하십시오.

더 많은 공식 자료를 찾을 수 있는 곳

모든 VDSM 게스트를 호스팅하는 패키지인 Virtual Machine Manager는 DSM에 오랫동안 포함되어 왔으며 관련 내용이 잘 정리되어 있습니다. 이 세 가지 안내서는 패키지 설치, 게스트 생성 및 작업하게 될 인터페이스의 일반적인 구성에 대해 설명합니다.

VDSM에 제작을 맡기기 전에 알아야 할 한계점

첫째, CPU보다 메모리가 제약 조건이 되는 경우가 훨씬 많습니다. 대상 게스트 OS는 2GB의 메모리를 가지고 있었는데, 아무것도 추가하기 전에 이미 스왑 영역을 사용하고 있었습니다. 두 번째 애플리케이션과 두 번째 데이터베이스를 추가하려면 약 480MB의 메모리가 더 필요했기 때문에 4GB로 늘렸습니다. 마이그레이션을 계획하기 전에 대상 시스템의 사용 가능한 메모리를 확인하세요. 계획 후에 확인하는 것은 바람직하지 않습니다.

둘째, VDSM 가상 디스크는 크기가 커지기만 하고 줄어들지는 않습니다. 디스크 용량을 과도하게 할당하면 필드를 수정하여 공간을 되돌릴 수 없습니다. 디스크 크기를 줄이는 유일한 방법은 새 게스트를 구축하고 해당 게스트로 마이그레이션하는 것입니다. 2년 후에도 만족할 수 있는 크기를 선택하십시오.

세 번째는 라이선스 문제입니다. NAS에는 게스트 하나가 포함되어 있으며, 추가 게스트마다 별도의 라이선스가 필요합니다. NAS에 게스트를 추가하려면 게스트를 별도로 등록해야 합니다. Virtual DSM 라이센스. 여러 NAS 장치에 걸친 클러스터링, 라이브 마이그레이션 및 더 긴 스냅샷 보존 기간은 다음과 같습니다. VMM Pro 표준적인 것보다는 특색 있는 기능을 고려하세요. 만약 고객 한 명을 네 명으로 나누는 통합 계획을 세운다면, 설계하기 전에 그에 따른 비용을 먼저 계산하세요.

손님의 사이즈를 제대로 측정하는 것은 그 자체로 하나의 과제입니다. VMM Pro를 사용하여 프로덕션 VM의 크기를 적절하게 조정하는 방법.

넷째, 피해야 할 시나리오입니다. 게스트의 가상 디스크를 백업에 사용하는 물리적 볼륨과 동일한 위치에 저장하고 이를 백업이라고 부르지 마십시오. 사용량이 많은 파일 서버와 회전식 디스크를 공유하는 게스트에서 지속적인 쓰기 작업이 많은 데이터베이스를 실행하지 마십시오. VDSM을 두 번째 머신의 대용으로 사용하지 마십시오. 호스트에 문제가 발생하면 해당 호스트의 모든 게스트가 동시에 종료되기 때문입니다. 또한 위의 파일 구성 섹션에서 설명한 이유로 인해 검사하지 않은 컨테이너를 마이그레이션하지 마십시오.

다섯째, 자격 증명입니다. 마이그레이션 과정에서 데이터베이스 암호, 환경 변수 및 구성 파일이 변경됩니다. 저희는 평문 데이터베이스 자격 증명이 담긴 compose 파일을 이동했기 때문에 웹 서버의 문서 루트 외부에 의도적으로 배치했습니다. 문서 루트 내부에 compose 파일이 남아 있으면 파일 이름을 추측하는 사람이라면 누구나 다운로드할 수 있으며, 이는 자격 증명 유출의 흔한 원인 중 하나입니다. 마이그레이션 스크립트를 사용하는 경우, 스크립트가 파일을 저장하는 위치를 반드시 확인하십시오. 그리고 작업이 완료되면 관리자 계정을 활성화 상태로 두지 말고, 마이그레이션 스크립트 실행을 위해 생성한 계정을 비활성화하십시오.

여섯째, 작업을 시작하기 전에 반드시 스냅샷을 생성하십시오. Virtual Machine Manager에서 VDSM 스냅샷을 생성하는 데는 몇 초밖에 걸리지 않으며, Pro 라이선스 없이도 사용할 수 있습니다. 이 스냅샷을 생성하면 이 문서에서 언급된 거의 모든 실수를 2분 만에 롤백할 수 있는 문제로 만들 수 있습니다. 사람이 직접 작성하든 보조자가 작성하든, 마이그레이션 실행 계획서에 반드시 추가해야 할 필수 단계입니다.

마지막으로, 추측하기보다는 검증하십시오. 이 문서의 모든 주장은 실행 중인 시스템을 기준으로 검증되었습니다. 양쪽의 테이블 개수, 디스크에 있는 첨부 파일, 애플리케이션에 등록된 플러그인 버전, 보류 중인 마이그레이션 없음, 그리고 스택을 완전히 재시작하여 시스템이 정상적으로 복구되는지 확인했습니다. 마이그레이션은 서비스가 응답한다고 해서 완료되는 것이 아닙니다. VDSM 게스트를 재부팅한 후에도 마이그레이션이 정상적으로 유지되고, 기존 복사본에 더 이상 쓰기 작업이 허용되지 않을 때 완료됩니다.

라이선스 구매처에 대한 안내입니다. 저희가 주로 하는 일이기 때문에 알려드립니다. SynoPower Club는 Synology 라이선스를 판매하며, 24시간 언제든 즉시 키를 받아보실 수 있습니다. 여기서 중요한 두 가지 라이선스는 다음과 같습니다. Virtual DSM 라이센스, 무료 손님을 제외한 모든 손님에게 필요한 것이며, VMM Pro 라이센스 클러스터링, 라이브 마이그레이션 또는 게스트당 32개가 아닌 255개의 스냅샷을 원하는 경우. 전체 라이선스 목록 Surveillance Station와 MailPlus도 포함됩니다.

참고문헌

• SynoPower Club, 저희 Synology NAS 가이드 및 카메라 리뷰도 확인해 보세요.
• Synology — Virtual Machine Manager, VDSM을 실행하는 패키지에 대한 공식 개요입니다.
• Synology 지식 센터 — Virtual Machine Manager 도움말, 게스트 생성 및 설정
• 도커 — 도커 컨테이너 커밋, 1단계의 명령
• Docker — Docker 이미지 저장, 손님 간에 이미지를 스트리밍하는 데 사용됩니다.

자주 묻는 질문