Synology VDSM: Przenoszenie Dockera za pomocą sztucznej inteligencji i zmiana rozmiaru dysku wirtualnego (2026)

Wirtualny NAS to jedna z tych funkcji, które ludzie instalują raz, bawią się nimi przez popołudnie, a potem zapominają, że je posiadają. Szkoda, bo Synology VDSM — Virtual DSM, działający w Virtual Machine Manager — dyskretnie rozwiązuje dwa najbardziej irytujące problemy w samodzielnym hostingu na małą skalę. Pierwszy to taki, że przenoszenie stosu Dockera między maszynami zazwyczaj kosztuje wieczór żmudnej pracy. Drugi to taki, że gdy na dysku wirtualnym kończy się miejsce, większość ludzi zakłada, że musi go odbudować. Żaden z tych problemów nie jest prawdziwy w przypadku VDSM. Ten przewodnik przedstawia prawdziwą migrację, którą przeprowadziliśmy w około trzydzieści pięć minut: wewnętrzny system śledzenia problemów Redmine z pięcioma wtyczkami, przeniesiony z jednego gościa VDSM i przeniesiony do innego, z asystentem AI zarządzającym powłoką. Po drodze w miejscu docelowym skończył się dysk, więc zwiększyliśmy jego dysk wirtualny z 10 GB do 20 GB i kontynuowaliśmy. Wszystko poniżej przedstawia, co faktycznie się wydarzyło, w tym jedną pułapkę, która po cichu zniszczyłaby aplikację.

Punkt SynoPower Club:Widziałem wielu ludzi, którzy odradzali wirtualizację na serwerze NAS, ponieważ zakładali, że jest on przeznaczony do laboratoriów, a nie do prawdziwej pracy. Migracja opisana w tym artykule była prawdziwą pracą – systemem zgłoszeń, z którego trzech współpracowników korzysta codziennie – i tym, co mnie zaskoczyło, nie była sztuczna inteligencja. Chodziło o to, jak mało formalności wymaga VDSM. Brak hypervisora do licencjonowania, brak oddzielnego serwera zarządzania, brak konieczności eksportowania i importowania niekompatybilnych formatów. W trakcie zadania zabrakło miejsca na dysku, a ja naprawiłem to, wpisując większą liczbę w polu tekstowym, gdy serwer był jeszcze uruchomiony. Cała praca zajęła trzydzieści pięć minut, a jedyna zauważona przerwa to dziewięćdziesiąt sekund na niezwiązanej z nią stronie internetowej. Jeśli posiadasz już serwer Synology z zapasową pamięcią, jesteś o jedną instalację pakietu od tego problemu.

Czym jest Synology VDSM?

VDSM to Virtual DSM z Synology: kompletna kopia DiskStation Manager działająca jako system operacyjny gościa w Virtual Machine Manager na fizycznym serwerze NAS. Zachowuje się jak osobny serwer NAS. Ma własny adres IP, własne logowanie do DSM, własne pakiety i własnego Menedżera Kontenerów. Z punktu widzenia sieci to po prostu kolejny Synology w sieci LAN. Z punktu widzenia sprzętu to kolejny proces na komputerze, za który już zapłaciłeś.

Praktycznym atutem jest izolacja. Uruchom każdą usługę bezpośrednio na hoście, a jeden źle działający kontener może zablokować serwer plików, od którego zależy całe biuro. Podzielenie obciążeń między gości VDSM daje każdemu z nich limit pamięci, przydział procesora i własny dysk, a także pozwala na restart jednego z nich bez ingerencji w pozostałe.

Każdy serwer NAS obsługujący Virtual Machine Manager zawiera jedną bezpłatną licencję VDSM. Uruchomienie drugiego i kolejnego serwera gościnnego wymaga opłacona licencja Virtual DSM Każdy. Ta jedna darmowa instancja wystarczy, aby wykonać wszystkie czynności opisane w tym artykule, i dlatego tak wiele osób posiada już tę funkcję i nigdy jej nie włączyło. Jeśli później będziesz potrzebować dodać, zmapować lub usunąć zmapowanie licencji, mamy instrukcję. zarządzanie licencjami VDSM.

VDSM i Virtual DSM to dwie nazwy tego samego urządzenia. W dokumentacji Synology używana jest długa forma, a większość użytkowników używa skróconej. Skrót ten jest również współdzielony z niezwiązanym z nim komponentem projektu wirtualizacji oVirt, więc w systemie NAS Synology zawsze oznacza Virtual DSM.

Płatna licencja działa inaczej, niż większość osób się spodziewa. Każda licencja dodaje jednego gościa i obejmuje trzy lata aktualizacji oprogramowania Virtual DSM. Maszyna wirtualna nigdy nie wygasa. Po trzech latach działa bez nowych aktualizacji. Aktywacja nowego klucza rozpoczyna kolejne trzy lata aktualizacji. Klucz jest aktywny na jednym serwerze NAS Synology na raz, a serwer NAS musi być online w momencie jego dodania.

Wymagania dla gościa VDSM są skromne i Synology wymienia je w swoim Specyfikacje Virtual Machine Manager:

• Dysk wirtualny musi znajdować się na woluminie Btrfs. Virtual Machine Manager nie przechowuje gości na ext4.
• Sam serwer NAS potrzebuje ponad 2 GB pamięci, zanim będzie mógł uruchomić jakąkolwiek maszynę wirtualną.
• Każdy gość potrzebuje co najmniej 1 GB pamięci, a rzeczywiste obciążenia wymagają więcej.
• Liczba gości, jaką model może komfortowo obsłużyć, zależy od jego procesora i zainstalowanej pamięci.

Gość nie jest identyczny z DSM na gołym komputerze. Brakuje trzech rzeczy, wszystkie powiązane ze sprzętem fizycznym:

• Przepustowość USB nie jest dostępna, więc urządzenia podłączonego do portu USB serwera NAS nie można przekazać gościowi.
• Strony Urządzenia zewnętrzne oraz Sprzęt i zasilanie w Panelu sterowania nie są dostępne.
• Klucze sprzętowe sieci bezprzewodowej, ustawienia MTU i agregacja łączy (LACP) nie są obsługiwane w środowisku gościa. Za sieć fizyczną odpowiada host.

Nic z tego nie wpływa na typowe powody uruchomienia takiego serwera. Usługi plików, Docker, serwer poczty czy kopia tymczasowa systemu produkcyjnego – wszystkie zachowują się tak, jakby działały na oddzielnym serwerze NAS.

Synology VDSM kontra drugi fizyczny serwer NAS: który jest Ci potrzebny?

Uczciwe porównanie nie polega na tym, że wirtualny serwer jest lepszy. To wymiana odporności na elastyczność. Drugi fizyczny serwer przetrwa awarię pierwszego; gość VDSM nie. Zamiast tego gość zyskuje możliwość tworzenia, zmiany rozmiaru, tworzenia migawek i przenoszenia całego serwera w ciągu kilku minut, a nie dni.

	Gość VDSM	Drugi fizyczny serwer NAS
Koszt dodania jednego	Bezpłatnie dla pierwszego gościa, licencja dla kolejnych	Cały NAS plus dyski
Czas na zaopatrzenie	Protokół	Dni, po uwzględnieniu kosztów wysyłki
Zmień rozmiar procesora, pamięci RAM lub dysku	Edytuj pole, uruchom ponownie gościa	Kup nowy sprzęt
Przetrwa awarię sprzętu hosta	NIE	Tak
Migawka i klon	Wbudowany w Virtual Machine Manager	Nie dotyczy
Przenieś do innego NAS-a	Migracja lub replikacja gościa	Przenieś to fizycznie
Najlepszy dla	Izolowanie usług, przygotowywanie, konsolidacja małych serwerów	Cele kopii zapasowych i rzeczywista redundancja

W tym przypadku wybór był oczywisty. Konsolidowaliśmy lekko używany system śledzenia błędów, który otrzymał własny, cały serwer VDSM, na serwerze gościa, który już obsługiwał witrynę z wolną przepustowością. Nic w tym nie wymagało nowego sprzętu. Wymagało to dziesięciu minut i odrobiny uwagi.

Czego potrzebujesz przed rozpoczęciem

Przede wszystkim, zamiast podawać swoje dane, podaj asystentowi własny login. W DSM otwórz Panel sterowania, przejdź do sekcji Użytkownicy i grupy i kliknij Utwórz. Nazwij go w sposób, który będzie jednoznaczny — my użyliśmy… Klaudiusz z opisem Kontrola AI — i pozwól DSM wygenerować silne losowe hasło.

Na następnym ekranie zaznacz administratorzy. To nie jest opcjonalne: DSM zezwala na logowanie się przez SSH tylko członkom grupy administratorów, więc konto spoza tej grupy nie ma w ogóle dostępu do powłoki. Zrób to samo na obu gościach VDSM, a następnie upewnij się, że SSH jest włączone w Panelu sterowania, Terminalu i SNMP.

Po zakończeniu pracy wyłącz konto. Właśnie o to chodzi w tworzeniu osobnego konta. Edytuj użytkownika w Panelu sterowania i wyłącz go lub usuń całkowicie; dostęp zostanie cofnięty jednym kliknięciem bez ingerencji w Twoje dane logowania, a wszystko, co zrobił asystent, pozostanie przypisane do loginu stworzonego właśnie w tym celu. Pozostawienie trwale włączonego konta administratora, bo kiedyś było wygodne, to sposób, w jaki małe posiadłości gromadzą dostępy, których nikt nie pamięta o udzieleniu.

Dwóch gości VDSM, SSH włączone na obu i Menedżer Kontenerów zainstalowany w miejscu docelowym. Trzeba też wiedzieć, co prawie każdy zauważa za pierwszym razem: plik binarny Dockera nie znajduje się w domyślnej ścieżce PATH w DSM. Pliki binarne pakietów znajdują się w katalogu pakietów, więc każde polecenie wymaga podania pełnej ścieżki lub aliasu powłoki.

Sprawdź, czy w miejscu docelowym jest miejsce przed rozpoczęciem transferu, a nie w jego połowie. Poniższe polecenia stanowią całość kontroli przed lotem i są identyczne dla każdego gościa VDSM.

Jeszcze jedno, zanim cokolwiek powiem: zrób zdjęcie obu gości w Virtual Machine Manager. Migawki są dostępne w darmowej wersji Virtual Machine Manager, nie tylko w wersji Pro, i przechowują do 32 migawek na gościa. Migawka VDSM przechwytuje całą maszynę, więc jeśli import się nie powiedzie lub polecenie wykona działanie, którego nie chciałeś, możesz przywrócić gościa zamiast go odbudowywać. Zajmuje to sekundy i jest najtańszym ubezpieczeniem w całym procesie. Zabezpiecz zarówno źródło, jak i miejsce docelowe, ponieważ źródło jest Twoim zabezpieczeniem awaryjnym.

# Docker nie znajduje się w zmiennej PATH w DSM — użyj pełnej ścieżki D=/volume1/@appstore/ContainerManager/usr/bin/docker # Co jest uruchomione i z czego jest zbudowane? sudo $D ps -a sudo $D images # Ile miejsca pozostało na woluminie docelowym? df -h /volume1 # Ile pamięci ma faktycznie wolny komputer gościnny docelowy? free -m

Migracja VDSM Docker w 4 krokach

Oto cztery kroki, które wykonaliśmy i które działają dla każdego stosu kontenerów, który trzeba przenieść między gośćmi VDSM. Kolejność ma znaczenie: kontener aplikacji jest zatrzymywany jako pierwszy, aby nic nie zapisywało danych do bazy danych w trakcie zrzutu, a kontener bazy danych pozostaje aktywny, aby można go było zrzucić bez błędów.

Dlaczego plik „Compose” nie jest całym kontenerem

Oto pułapka, która sama w sobie jest warta swojej ceny. Plik compose dla naszego stosu Redmine deklaruje dwa montowania bind: jedno dla przesłanych plików, drugie dla bazy danych. Po przeczytaniu tego pliku można rozsądnie dojść do wniosku, że ponowne utworzenie stosu na nowym gościu oznacza skopiowanie dwóch katalogów i uruchomienie polecenia docker compose up.

Nie zadziałało. Pięć wtyczek, pobrane przez nie gemy Ruby, konfiguracja poczty i kilka edytowanych plików inicjujących – wszystko to zostało zainstalowane bezpośrednio w działającym kontenerze przez lata. Nic z tego nie znajdowało się w woluminie. Jedno polecenie pokazało nam, jak bardzo to było złe.

# Ile plików różni się między kontenerem a obrazem, z którego pochodzi? sudo $D diff Redmine | wc -l 6764 # Wtyczki znajdujące się wewnątrz kontenera, nieobsługiwane przez żaden wolumin sudo $D exec Redmine ls /usr/src/redmine/plugins

Pobranie nowego, oficjalnego obrazu spowodowałoby utworzenie kontenera bez żadnej z tych wtyczek, wskazującego na bazę danych, która nadal zawierała 144 tabele utworzone w wyniku migracji. Aplikacja nie uległaby awarii. Uruchomiłaby się, wyglądałaby prawie poprawnie, a następnie uległaby awarii w sposób trudny do zdiagnozowania. Zatwierdzenie działającego kontenera do obrazu całkowicie omija problem, kosztem większego transferu. W sieci LAN między dwoma gośćmi VDSM ten koszt wynosi około minuty, więc za każdym razem należy skorzystać z tej opcji.

Jak mały zespół wykorzystuje VDSM do konsolidacji serwerów

Schemat, według którego przebiega ta migracja, jest taki, jakiego w końcu potrzebuje większość małych zespołów. W ciągu kilku lat gromadzisz gości o jednym przeznaczeniu: jednego do wiki, jednego do śledzenia zgłoszeń, jednego do panelu monitorowania (kształt opisany w naszym przewodnik po domowym centrum danych). Każdy z nich został hojnie przeskalowany w dniu, w którym został zbudowany, a teraz każdy z nich pracuje na ułamku tego, co pierwotnie miał, podczas gdy gospodarz jest przeciążony i wszystko wydaje się nieco powolne.

Konsolidacja z VDSM oznacza przeniesienie cichych obciążeń do gościa, który już działa. Nasz system śledzenia zgłoszeń miał całego gościa z własnym przydziałem procesora i 1 GB pamięci dla siebie, dla usługi, z której trzy osoby korzystają kilka razy dziennie. Przeniesienie go do istniejącego stosu webowego całkowicie uwolniło ten przydział i kosztowało miejsce docelowe około 480 MB pamięci rezydentnej w dwóch kontenerach.

Dyscyplina, która zapewnia bezpieczeństwo, polega na odpowiednim wycofaniu źródła zamiast pozostawienia go uruchomionego. Ustawiliśmy stare kontenery na politykę restartu „nie”, zatrzymaliśmy je, pozostawiliśmy plik tekstowy w katalogu wyjaśniający, gdzie teraz znajduje się usługa, i wyłączyliśmy gościa z wyłączonym automatycznym uruchamianiem. Pozostaje on punktem całkowitego wycofania i nie może po cichu powrócić do działania po restarcie hosta i zacząć akceptować zapisów, których nowa instancja nigdy nie zobaczy. Rozbieżne duplikaty to klasyczny sposób, w jaki uporządkowana migracja staje się incydentem utraty danych miesiąc później.

Zmiana rozmiaru dysku wirtualnego, na którym zabrakło miejsca

W połowie drogi zabrakło miejsca w miejscu docelowym. Jego pojemność wynosiła 9,6 GB, z czego 1,5 GB było wolne, a my mieliśmy dodać obraz o rozmiarze 816 MB i 123 MB danych aplikacji. Na fizycznym serwerze NAS to koniec historii, dopóki nie pojawią się nowe dyski. W VDSM jest to pole tekstowe.

Otwórz ustawienia gościa w Virtual Machine Manager, przejdź do zakładki Pamięć, wpisz nowy rozmiar i kliknij OK. Nie ma potrzeby wyłączania gościa w tym celu. Dysk rośnie, podczas gdy maszyna działa, dlatego jest to zasadniczo inne doświadczenie niż zwiększanie pojemności na samym sprzęcie. Warto pamiętać, że dysk wirtualny może się tylko powiększać, nigdy się nie kurczyć, więc nie ma cofnięcia i nie ma powodu, by niepokoić się liczbą.

To, co sprawia, że jest to naprawdę bezproblemowe, to to, co dzieje się wewnątrz gościa. DSM sam rozszerza partycję i system plików, aby wypełnić nową przestrzeń. Nie ma kreatora Menedżera pamięci masowej do uruchomienia, tablicy partycji do edycji, woluminu do odbudowania ani danych do migracji. Nasz wolumin zwiększył się z 9,6 GB z 1,5 GB wolnego miejsca do 20 GB z 13 GB wolnego miejsca, a kontenery działały dalej. To jest najmocniejszy argument za umieszczeniem usługi na VDSM, a nie na samym sprzęcie: późniejsze poprawienie błędnego rozmiaru jest tanie.

Co właściwie zrobił asystent AI

Warto być precyzyjnym, ponieważ stwierdzenie “AI przeniosła mój serwer” jest zarówno zbyt naiwne, jak i zbyt mało wiarygodne. Asystent nie miał magicznej intuicji. Miał powłokę na obu gościach VDSM i był systematyczny w sposób, w jaki zmęczony człowiek pod koniec dnia pracy zazwyczaj nie jest.

Najcenniejszą rzeczą, jaką zrobił, było uruchomienie polecenia docker diff przed wprowadzeniem jakichkolwiek zmian, odnotowanie 6764 zmienionych plików i odrzucenie oczywistego planu. Osoba, która wykonywała polecenia zgodnie z plikiem compose, nie miałaby powodu, aby je uruchamiać. Drugą najcenniejszą rzeczą była weryfikacja: po imporcie program zliczał tabele, zgłoszenia, projekty, wpisy do dziennika i załączniki po obu stronach, sprawdzał, czy każdy plik załącznika istnieje na dysku, wyświetlał listę wersji wtyczek zarejestrowanych przez aplikację i potwierdzał, że nie ma żadnych oczekujących migracji baz danych. To żmudna lista kontrolna, a żmudne listy kontrolne to właśnie to, co pomija się o piątej po południu.

Od człowieka nadal oczekiwano oceny konsekwencji. Ponowne uruchomienie gościa VDSM w celu dodania pamięci oznaczało wyłączenie działającej strony internetowej, a to decyzja, o którą należy pytać, a nie zakładać. To samo dotyczy usuwania czegokolwiek. Potraktuj asystenta jak bardzo szybką, bardzo dosłowną parę rąk, która nigdy się nie nudzi sprawdzaniem, a nieodwracalne połączenia zachowaj dla siebie.

Gdzie znaleźć więcej oficjalnych zasobów

Pakiet Virtual Machine Manager, który obsługuje każdego gościa VDSM, jest obecny w DSM od lat i jest dobrze opisany. Te trzy przewodniki obejmują instalację pakietu, tworzenie gościa oraz ogólny wygląd interfejsu, w którym będziesz pracować.

Ograniczenia, które należy znać przed zaufaniem firmie VDSM w zakresie produkcji

Po pierwsze, pamięć jest ograniczeniem znacznie częściej niż procesor. Nasz docelowy komputer gościnny miał 2 GB i był już włączony do pamięci wymiany, zanim cokolwiek dodaliśmy. Druga aplikacja i druga baza danych potrzebowały około 480 MB, więc zwiększyliśmy tę ilość do 4 GB. Sprawdź ilość wolnej pamięci w miejscu docelowym przed planowaniem migracji, a nie po niej.

Po drugie, wirtualny dysk VDSM rośnie, ale nigdy się nie kurczy. W przypadku nadmiernego przydzielania przestrzeni nie można jej odzyskać, edytując pole; jedynym sposobem na zmniejszenie rozmiaru dysku jest utworzenie nowego dysku gościnnego i migracja na niego. Wybierz liczbę, która będzie Cię satysfakcjonować po dwóch latach.

Po trzecie, licencjonowanie. Jeden gość jest dołączony do NAS-a; każdy kolejny gość potrzebuje własnego Licencja Virtual DSM. Klastrowanie w kilku jednostkach NAS, migracja na żywo i większy obszar przechowywania migawek to VMM Pro funkcje, a nie standardowe. Jeśli Twój plan konsolidacji zakłada podzielenie jednego zajętego gościa na cztery, wyceń to przed jego zaprojektowaniem.

Odpowiednie określenie rozmiaru gościa to osobne zadanie: jak prawidłowo dopasować rozmiar maszyny wirtualnej produkcyjnej z VMM Pro.

Po czwarte, scenariusze, których należy unikać. Nie umieszczaj wirtualnego dysku gościa na tym samym woluminie fizycznym, na którym tworzysz kopię zapasową, i nie nazywaj tego kopią zapasową. Nie uruchamiaj bazy danych z dużą liczbą ciągłych zapisów na gościu współdzielącym dyski obrotowe z obciążonym serwerem plików. Nie traktuj VDSM jako substytutu drugiej maszyny, ponieważ jeśli host przestanie działać, wszystkie hosty na nim przestaną działać w tym samym momencie. Nie migruj również kontenera, którego nigdy nie sprawdzałeś, z powodów opisanych powyżej w sekcji „Compose-file”.

Po piąte, dane uwierzytelniające. Migracja dotyczy haseł do bazy danych, zmiennych środowiskowych i plików konfiguracyjnych. Nasz plik do tworzenia dokumentów zawierał dane uwierzytelniające do bazy danych w postaci zwykłego tekstu, więc został on celowo umieszczony poza katalogiem głównym dokumentów serwera WWW. Plik do tworzenia dokumentów pozostawiony w katalogu głównym dokumentów jest dostępny do pobrania przez każdego, kto odgadnie jego nazwę, a to przygnębiająco częsty sposób wycieku danych uwierzytelniających. Jeśli pozwolisz asystentowi na wykonanie skryptu migracji, przeczytaj, gdzie zapisuje pliki. A po zakończeniu pracy wyłącz konto utworzone dla asystenta, zamiast pozostawiać aktywne dane logowania administratora.

Po szóste, zrób migawkę, zanim cokolwiek zrobisz. Migawka VDSM w Virtual Machine Manager zajmuje sekundy, jest dostępna bez licencji Pro i zamienia niemal każdy błąd w tym artykule w dwuminutowe wycofanie. To jedyny krok, który warto dodać do każdego podręcznika migracji, niezależnie od tego, czy pisze człowiek, czy asystent.

Na koniec, weryfikuj, a nie zakładaj. Każde stwierdzenie w tym artykule zostało sprawdzone w działającym systemie: liczba tabel po obu stronach, obecność plików załączników na dysku, wersje wtyczek zarejestrowane przez aplikację, brak oczekujących migracji oraz pełny restart stosu w celu potwierdzenia, że system powraca do działania samoczynnie. Migracja nie kończy się, gdy usługa odpowiada. Kończy się, gdy udowodnisz, że przetrwała restart gościa VDSM i gdy stara kopia nie może już akceptować zapisów.

Uwaga, gdzie zdobyć te licencje, bo tym się zajmujemy: SynoPower Club sprzedaje licencje Synology z całodobową, natychmiastową dostawą kluczy. Dwie rzeczy, które mają tu znaczenie, to: Licencja Virtual DSM, którego potrzebujesz dla każdego gościa po tym darmowym i Licencja VMM Pro jeśli chcesz klastrować, migrować na żywo lub 255 migawek na gościa zamiast 32. pełny katalog licencji obejmuje również Surveillance Station i MailPlus.

Odniesienia

• SynoPower Club, nasze przewodniki po NAS-ach Synology i recenzje kamer
• Synology — Virtual Machine Manager, oficjalny przegląd pakietu, który uruchamia VDSM
• Centrum wiedzy Synology — pomoc Virtual Machine Manager, tworzenie gości i ustawienia
• Docker — zatwierdzenie kontenera Docker, polecenie za krokiem pierwszym
• Docker — zapisywanie obrazu Dockera, służy do przesyłania strumieniowego obrazu między gośćmi

Często zadawane pytania