Synology VDSM: Docker áthelyezése mesterséges intelligenciával és virtuális lemez átméretezése (2026)

Egy virtuális NAS egyike azoknak a funkcióknak, amiket az emberek egyszer telepítenek, egy délutánon át böngészgetik, aztán elfelejtik, hogy az övéi. Ez kár, mert az Synology VDSM – Virtual DSM, az Virtual Machine Manager-n belül fut – csendben megoldja a kis léptékű önkiszolgáló tárhelyszolgáltatások két legbosszantóbb problémáját. Az első az, hogy egy Docker-verem gépek közötti mozgatása általában egy estenyi aprólékos munkába kerül. A második az, hogy amikor egy virtuális lemezen elfogy a hely, a legtöbb ember azt feltételezi, hogy újra kell építenie az egészet. A VDSM esetében egyik sem igaz. Ez az útmutató egy valós migrációt mutat be, amit körülbelül harmincöt perc alatt futtattunk le: egy belső Redmine hibakövető öt bővítménnyel, amelyet kiemeltünk az egyik VDSM vendéggépből és áthelyeztünk egy másikba, egy mesterséges intelligencia asszisztens vezette a shellt. Útközben a célállomásnak elfogyott a lemeze, ezért a virtuális lemezét 10 GB-ról 20 GB-ra növeltük, és folytattuk. Az alábbiakban minden a ténylegesen történteket mutatja be, beleértve azt az egyetlen csapdát is, amely csendben elpusztította volna az alkalmazást.

SynoPower Club pont：Sok embert láttam már lebeszélni a NAS virtualizációjáról, mert azt feltételezik, hogy az laborcélokra való, és nem valódi munkára. A cikkben szereplő migráció valódi munka volt – egy jegyrendszer, amit három kollégám használ nap mint nap –, és ami meglepett, az nem a mesterséges intelligencia volt. Hanem az, hogy milyen kevés ceremóniára van szüksége a VDSM-nek. Nincs licencelendő hipervizor, nincs külön felügyeleti szerver, nincs export-import tánc az inkompatibilis formátumok között. A vendéggépnek elfogyott a lemeze munka közben, és én úgy javítottam ki, hogy egy nagyobb számot írtam be egy szövegmezőbe, miközben még futott. Az egész munka harmincöt percig tartott, és az egyetlen kiesés, amit bárki észrevett, kilencven másodperc volt egy független weboldalon. Ha már van egy Synology-d tartalék memóriával, akkor egy csomagtelepítésre vagy ettől.

Mi az Synology VDSM?

A VDSM az Synology Virtual DSM-je: a DiskStation Manager egy teljes példánya, amely vendég operációs rendszerként fut az Virtual Machine Manager-n belül egy fizikai NAS-on. Úgy viselkedik, mint egy különálló NAS. Saját IP-címe, saját DSM bejelentkezése, saját csomagjai, saját Container Managere. A hálózat szempontjából egyszerűen egy másik Synology van a helyi hálózaton. A hardver szempontjából ez egy újabb folyamat egy olyan gépen, amiért már fizettél.

A gyakorlati vonzereje az elszigeteltségben rejlik. Ha minden szolgáltatást közvetlenül a gazdagépen futtatunk, egyetlen rosszul viselkedő konténer is kiéheztetheti azt a fájlszervert, amelytől az egész iroda függ. A munkaterhelések VDSM vendéggépek közötti felosztása mindegyikhez memóriakorlátot, CPU-lefoglalást és saját lemezt biztosít, és lehetővé teszi, hogy az egyiket a többi érintése nélkül újraindítsuk.

Minden Virtual Machine Manager-t támogató NAS tartalmaz egy ingyenes VDSM licencet. Egy második és további vendég szerver futtatásához egy fizetős Virtual DSM licenc mindegyik. Ez az egyetlen ingyenes példány elegendő a cikkben leírtak követéséhez, és ezért van az, hogy oly sokan rendelkeznek már ezzel a funkcióval, és soha nem kapcsolták be. Ha később hozzá kell adnia, le kell rendelnie vagy meg kell szüntetnie egy licenc leválasztását, van egy útmutatónk a következő oldalon: VDSM licencek kezelése.

A VDSM és az Virtual DSM ugyannak a dolognak a két neve. Az Synology saját dokumentációja a hosszú formát használja, míg a legtöbb tulajdonos a rövidítettet. A rövidítést az oVirt virtualizációs projekt egy független komponense is használja, így egy Synology NAS-on mindig Virtual DSM-t jelent.

A fizetős licenc másképp működik, mint amire a legtöbb ember számít. Mindegyik licenc egy vendéggépet ad hozzá, és három évnyi Virtual DSM szoftverfrissítést tartalmaz. A virtuális gép soha nem jár le. A három év elteltével új frissítések nélkül tovább fut. Egy új kulcs aktiválása újabb három évnyi frissítést indít el. Egy kulcs egyszerre egy Synology NAS-on aktív, és a NAS-nak online kell lennie a hozzáadáskor.

Egy VDSM vendég követelményei szerények, és az Synology felsorolja őket a ... Virtual Machine Manager specifikációk:

• A virtuális lemeznek egy Btrfs köteten kell lennie. Az Virtual Machine Manager nem tárol vendégtárolókat az ext4 köteten.
• Magának a NAS-nak több mint 2 GB memóriára van szüksége ahhoz, hogy bármilyen virtuális gépet futtathasson.
• Minden vendégnek legalább 1 GB memóriára van szüksége, a valós munkaterhelésekhez pedig többre.
• Az, hogy egy modell hány vendéget tud kényelmesen futtatni, a processzorától és a telepített memóriától függ.

Egy vendég nem azonos a DSM-mel a csupasz fémen. Három dolog hiányzik, amelyek mindegyike fizikai hardverhez kapcsolódik:

• Az USB áteresztés nem érhető el, így a NAS USB-portjába csatlakoztatott eszközt nem lehet átadni a vendégnek.
• A Vezérlőpult Külső eszközök és Hardver és tápellátás oldalai nincsenek ott.
• A vezeték nélküli adapterek, az MTU-beállítások és a linkaggregáció (LACP) nem támogatottak a vendéggépen belül. A fizikai hálózatot a gazdagép kezeli.

Mindez nem befolyásolja a futtatás szokásos okait. A fájlszolgáltatások, a Docker, egy levelezőszerver vagy egy éles rendszer egy átmeneti példánya mind úgy viselkednek, mint egy különálló NAS-on.

Synology VDSM vs. egy második fizikai NAS: Melyikre van szükséged?

Az őszinte összehasonlítás nem az, hogy a virtuális jobb. Ez a rugalmasságért cserébe a rugalmasságért felelős a rugalmasság. Egy második fizikai doboz túléli az első meghibásodását; egy VDSM vendéggép nem. Amit egy vendéggéppel kapsz, az a képesség, hogy egy egész szervert percek, és nem napok alatt létrehozz, átméretezz, pillanatképet készíts és áthelyezz.

	VDSM vendég	Második fizikai NAS
Egy hozzáadásának költsége	Az első vendégnek ingyenes, utána engedély jár.	Egy teljes NAS plusz meghajtók
Ellátási idő	Jegyzőkönyv	Napok, miután a szállítást megszámolták
CPU, RAM vagy lemez átméretezése	Mező szerkesztése, vendég újraindítása	Új hardver vásárlása
Túléli a gazdagép hardverhibáját	Nem	Igen
Pillanatkép és klón	Beépítve az Virtual Machine Manager-be	Nem alkalmazható
Áthelyezés egy másik NAS-ra	A vendég migrálása vagy replikálása	Fizikailag helyezze át
Legjobb	Szolgáltatások elkülönítése, előkészítése, kis szerverek konszolidálása	Biztonsági mentési célok és valódi redundancia

Ennél a munkánál a választás kézenfekvő volt. Egy alig használt, korábban saját VDSM vendéggéppel ellátott hibakövetőt vontunk össze egy már meglévő, szabad kapacitással rendelkező weboldallal rendelkező vendéggéppel. Ehhez semmi új hardverre nincs szükség. Tíz percre és egy kis gondozásra.

Amire szükséged van a kezdés előtt

Mindenekelőtt adj a segédnek saját bejelentkezési nevet a sajátod helyett. A DSM-ben nyisd meg a Vezérlőpultot, menj a Felhasználó és csoport menüpontra, és kattints a Létrehozás gombra. Nevezd el valami félreérthetetlennel – mi a következőt használtuk: Claude a leírással AI-vezérlés — és hagyd, hogy a DSM generáljon egy erős, véletlenszerű jelszót.

A következő képernyőn jelölje be a adminisztrátorok. Ez nem opcionális: a DSM csak az administrators csoport tagjai számára engedélyezi az SSH-n keresztüli bejelentkezést, így a csoporton kívüli fiókok egyáltalán nem érhetik el a shellt. Ugyanezt tegye mindkét VDSM vendéggépen, majd győződjön meg arról, hogy az SSH be van kapcsolva a Vezérlőpult, Terminál és SNMP menüpontban.

Amikor a munka befejeződött, tiltsa le a fiókot. Ez a lényege egy külön fiók létrehozásának. Szerkeszd a felhasználót a Vezérlőpulton, és kapcsold ki, vagy töröld teljesen; a hozzáférés egyetlen kattintással visszavonható anélkül, hogy a saját hitelesítő adataidhoz kellene nyúlnod, és minden, amit az asszisztens tett, továbbra is egy olyan bejelentkezéshez kapcsolódik, amely pontosan erre a célra létezik. Ha egy állandóan engedélyezett rendszergazdai fiókot hagysz magadnál, mert régen kényelmes volt, akkor halmozódnak fel a kis birtokok olyan hozzáférési jogosultságok, amelyekre senki sem emlékszik, hogy megadták volna.

Két VDSM vendéggép, mindkettőn engedélyezve az SSH, és a célállomáson telepítve a Container Manager. Azt is tudnod kell, ami szinte mindenkinek elsőre feltűnik: a Docker bináris fájl nincs az alapértelmezett PATH-on a DSM-en belül. A csomag bináris fájljai a csomag könyvtár alatt találhatók, így minden parancshoz meg kell adni a teljes elérési utat vagy egy shell aliast.

Ellenőrizd, hogy a célállomáson van-e elég hely, mielőtt elindulsz, ne csak az átszállás felénél. Az alábbi parancsok a teljes repülés előtti ellenőrzést tartalmazzák, és minden VDSM vendéggépen azonosak.

Még valami, mielőtt bármit is mondanál: készítsen pillanatképet mindkét vendégről az Virtual Machine Manager-ben. A pillanatképek az Virtual Machine Manager ingyenes kiadásában is megtalálhatók, nem csak a Pro verzióban, és vendégenként akár 32 pillanatképet is tárol. A VDSM pillanatkép az egész gépet rögzíti, így ha egy importálás rosszul sül el, vagy egy parancs olyasmit tesz, amit nem szándékosan, akkor a vendéggépet vissza kell görgetni ahelyett, hogy újra kellene építeni. Másodpercekbe kerül, és ez a legolcsóbb biztosítás ebben az egész folyamatban. Csinálj egyet a forrásgépen és a célgépen is, mert a forrásgép a tartalékod.

# A Docker nincs a PATH elérési úton a DSM-ben - használja a teljes elérési utat: D=/volume1/@appstore/ContainerManager/usr/bin/docker # Mi fut, és miből épül fel? sudo $D ps -a sudo $D images # Mennyi hely van még a célköteten? df -h /volume1 # Mennyi szabad memóriája van valójában a célvendégnek? free -m

VDSM Docker migráció 4 lépésben

Ezt a négy lépést futtattuk le, és ezek bármilyen konténerveremre működnek, amelyet a VDSM vendégek között kell felemelni. A sorrend számít: az alkalmazáskonténer áll le először, így a memóriakép közben semmi sem ír az adatbázisba, az adatbáziskonténer pedig életben marad, így tisztán kiírható.

Miért nem a Composite fájl a teljes konténer?

Íme a csapda, és önmagában is megéri a beismerést. A Redmine stackünk compose fájlja két bind mountot deklarált: egyet a feltöltött fájloknak, egyet az adatbázisnak. A fájl elolvasása után joggal arra a következtetésre juthatnánk, hogy a stack újbóli létrehozása az új vendéggépen két könyvtár másolását és a docker compose futtatását jelenti.

Nem így történt. Öt bővítmény, a beépült Ruby-gyöngyszemek, a levelezőkonfiguráció és számos szerkesztett inicializáló fájl mind közvetlenül a futó konténerbe lett telepítve az évek során. Egyik sem volt kötetben. Egyetlen parancs árulta el, mennyire rossz a rendszer.

# Hány fájl különbözik a konténer és a kép között, amelyből származik? sudo $D diff Redmine | wc -l 6764 # A konténeren belül található bővítmények, kötet nélkül sudo $D exec Redmine ls /usr/src/redmine/plugins

Egy friss hivatalos rendszerkép letöltése egy olyan konténert eredményezett volna, amelyikben ezek a bővítmények nem voltak, és egy olyan adatbázisra mutatott volna, amely még mindig tartalmazta a migrációik által létrehozott 144 táblát. Az alkalmazás nem hibásodott volna meg hangosan. Elindult volna, majdnem jól nézett volna ki, majd olyan módon hibásodott volna meg, amit nehéz lenne diagnosztizálni. A futó konténer rendszerképbe való véglegesítése teljesen megkerüli a problémát, de nagyobb átvitel árán. Két VDSM vendég közötti LAN-on ez körülbelül egy percbe kerül, ezért minden alkalommal érdemes áttérni a cserére.

Hogyan használja egy kis csapat a VDSM-et a szerverek konszolidálására?

A migráció során követett minta a legtöbb kisebb csapatnak végül szüksége van rá. Néhány év alatt egyetlen célra létrehozott vendégeket gyűjtesz össze: egyet a wikihez, egyet a jegykövetőhöz, egyet pedig egy monitorozó irányítópulthoz (a leírásunkban leírt alakzat szerint). otthoni adatközpont áttekintése). Mindegyiket nagylelkűen méretezték a megépítése napján, és most mindegyik a kapott teljesítmény töredékével működik, miközben a hoszt túl van terhelve, és minden kissé lassúnak érződik.

A VDSM-mel való konszolidáció azt jelenti, hogy a csendes munkafolyamatokat egy már ébren lévő vendégkörnyezetbe hajtjuk át. A jegykövetőnk egy teljes vendégkörnyezetet tartalmazott saját CPU-foglalással és 1 GB memóriával egy olyan szolgáltatáshoz, amelyet három ember naponta néhányszor használ. Ha egy meglévő webes verem mellé helyeztük, akkor ez a foglalás teljesen felszabadult, és a célkör körülbelül 480 MB rezidens memóriát veszített két konténerben.

Az a fegyelem, ami ezt biztonságossá teszi, a forráskód megfelelő leselejtezése ahelyett, hogy hagynánk futni. A régi konténereket „nem” újraindítási házirendre állítottuk be, leállítottuk őket, egy szövegfájlt hagytunk a könyvtárban, amely elmagyarázza, hol található most a szolgáltatás, és kikapcsoltuk a vendégkiszolgálót az automatikus indítás letiltásával. Ez egy teljes visszaállítási pont marad, és nem tud csendben újraéledni egy gazdagép újraindítása után, és nem kezdheti el fogadni az írási műveleteket, amelyeket az új példány soha nem fog látni. Az eltérő duplikátumok a klasszikus módja annak, hogy egy rendezett migráció egy hónappal később adatvesztési incidenssé váljon.

Virtuális lemez átméretezése, ha elfogyott a hely

A felénél elfogyott a tárhely a célhelyen. A mérete 9,6 GB volt, amiből 1,5 GB szabad volt, és éppen egy 816 MB-os képfájlt, valamint 123 MB alkalmazásadatot készültünk hozzáadni. Egy fizikai NAS-on itt megáll a történet, amíg meg nem érkeznek az új meghajtók. VDSM-en ez egy szövegmező.

Nyisd meg a vendég beállításait az Virtual Machine Manager-ben, menj a Tárhely fülre, írd be az új méretet, majd kattints az OK gombra. A vendéget ehhez nem kell leállítani. A lemez a gép futása közben növekszik, ezért ez alapvetően más élmény, mint a csupasz hardver kapacitásának növelése. Az egyetlen szabály, amit érdemes tudni, hogy egy virtuális lemez csak növekedhet, soha nem zsugorodhat, így nincs visszavonási lehetőség, és nincs ok a számmal kapcsolatos szégyenkezésre.

Ami igazán fájdalommentessé teszi az egészet, az a vendéggépen belül történik. A DSM kibővíti a partíciót és a fájlrendszert, hogy magától kitöltse az új területet. Nincs Storage Manager varázsló, amit futtatni kellene, nincs partíciós tábla, amit szerkeszteni kellene, nincs kötet, amit újra kellene építeni, és nincsenek adatok, amiket migrálni kellene. A kötetünk mérete 9,6 GB-ról 1,5 GB szabad tárhellyel 20 GB-ra nőtt 13 GB szabad tárhellyel, a konténerek pedig megmaradtak. Ez a legerősebb érv amellett, hogy egy szolgáltatást VDSM-re helyezzünk, és ne a csupasz hardverre: a rossz méretezést később olcsón meg lehet javítani.

Mit csinált valójában az AI asszisztens?

Érdemes itt pontosnak lenni, mert a “MI áthelyezte a szerveremet” kifejezés egyszerre túl sok és túl kevés hiszékenységet vált ki. Az asszisztensnek nem volt mágikus rálátása. Mindkét VDSM vendégre volt rálátása, és olyan szisztematikus volt, amire egy fáradt ember a munkanap végén általában nem.

A legértékesebb dolog, amit tett, az volt, hogy mielőtt bármihez is hozzáért volna, lefuttatta a docker diff parancsot, észrevett 6764 módosított fájlt, és elutasította a nyilvánvaló tervet. A compose fájlt követő személynek semmi oka nem lett volna lefuttatnia ezt a parancsot. A második legértékesebb dolog az ellenőrzés volt: az importálás után mindkét oldalon megszámolta a táblákat, problémákat, projekteket, naplóbejegyzéseket és mellékleteket, ellenőrizte, hogy minden mellékletfájl létezik-e a lemezen, felsorolta az alkalmazás által regisztrált bővítmények verzióit, és megerősítette, hogy nincsenek függőben lévő adatbázis-migrációk. Ez egy unalmas ellenőrzőlista, és az unalmas ellenőrzőlisták pontosan azok, amiket délután ötkor kihagynak.

Amire még mindig szükség volt egy ember részéről, az a következmények megítélése volt. Egy VDSM vendég újraindítása a memória bővítése érdekében egy élő weboldal leállítását jelentette, és ez egy olyan döntés, amit inkább meg kell kérdezni, mint feltételezni. Ugyanez vonatkozik bármi törlésére is. Tekints az asszisztensre úgy, mint egy nagyon gyors, szó szerint értő kézre, amely soha nem unja meg az ellenőrzést, és tartsd meg magadnak a visszafordíthatatlan hívásokat.

Hol találhat további hivatalos forrásokat?

Az Virtual Machine Manager csomag, amely minden VDSM vendéggépet üzemeltet, már évek óta része a DSM-nek, és jól le van fedve. Ez a három útmutató a csomag telepítését, a vendéggép létrehozását és a használni kívánt felület általános kinézetét tárgyalja.

Korlátok, amiket tudnod kell, mielőtt a VDSM-re bízod a gyártást

Először is, a memória sokkal gyakrabban korlátozó tényező, mint a CPU. A cél vendéggépünk 2 GB-tal rendelkezett, és már swap módban volt, mielőtt bármit is hozzáadtunk volna. Egy második alkalmazásnak és egy második adatbázisnak nagyjából további 480 MB-ra volt szüksége, ezért ezt 4 GB-ra emeltük. A célgépen a szabad memóriát a költöztetés megtervezése előtt ellenőrizd, ne utána.

Másodszor, egy VDSM virtuális lemez növekszik, de soha nem zsugorodik. Túlzott kiépítés esetén nem lehet visszanyerni a területet a mező visszaállításával; az egyetlen módja egy kisebb lemez elérésének egy új vendéggép létrehozása és oda migrálás. Válassz olyan számot, amellyel két év múlva is elégedett leszel.

Harmadszor, a licencelés. Egy vendég jár a NAS-hoz; minden további vendégnek saját Virtual DSM licenc. Több NAS egység klaszterezése, az élő migráció és a nagyobb pillanatkép-megőrzés VMM Pro funkciók helyett standardokat. Ha az összevonási terved egy elfoglalt vendég négy rendezett vendégre való felosztását tartalmazza, akkor ezt árazd meg a tervezés előtt.

A vendég megfelelő méretének meghatározása már önmagában is feladat: Hogyan méretezzünk megfelelő méretű éles virtuális gépet VMM Pro-vel?.

Negyedszer, a kerülendő forgatókönyvek. Ne helyezd a vendéggép virtuális lemezét ugyanarra a fizikai kötetre, amelyre a biztonsági mentést készíted, és ne nevezd azt biztonsági mentésnek. Ne futtass olyan adatbázist, amely nagy mennyiségű folyamatos írást végez egy vendéggépen, amely forgó lemezeket oszt meg egy forgalmas fájlszerverrel. Ne kezeld a VDSM-et egy második gép helyettesítőjeként, mert ha a gazdagép megsemmisül, akkor az összes rajta lévő vendéggép is egyszerre megsemmisül. És ne migrálj olyan konténert, amelyet még soha nem vizsgáltál meg, a fenti, fájlszerkesztéssel kapcsolatos szakaszban ismertetett okok miatt.

Ötödször, a hitelesítő adatok. A migráció adatbázisjelszavakat, környezeti változókat és konfigurációs fájlokat érint. A miénk egy egyszerű szöveges adatbázis-hitelesítő adatokat tartalmazó írásfájlt helyezett át, így azt szándékosan a webkiszolgáló dokumentumgyökérén kívülre helyeztük. A dokumentumgyökérben hagyott írásfájlt bárki letöltheti, aki kitalálja a fájlnevét, és ez egy elkeserítően gyakori módja a hitelesítő adatok kiszivárgásának. Ha hagyod, hogy egy asszisztens migrációt írjon, olvasd el, hová írja a fájlokat. És amikor a munka elkészült, tiltsd le az asszisztens számára létrehozott fiókot, ahelyett, hogy élő rendszergazdai bejelentkezést hagynál hátra.

Hatodszor, készítsen pillanatképet, mielőtt bármihez is hozzányúlna. Egy VDSM pillanatkép az Virtual Machine Manager-ben másodpercek alatt elkészül, Pro licenc nélkül is elérhető, és a cikkben szereplő szinte minden hibát kétperces visszagörgetéssé alakít. Ez az egyetlen lépés, amit érdemes hozzáadni bármely migrációs runbookhoz, akár ember, akár asszisztens gépel.

Végül, a feltételezés helyett ellenőrizzünk. A cikkben szereplő összes állítást a futó rendszerrel szemben ellenőriztük: mindkét oldalon a táblák számát, a lemezen található mellékletfájlokat, az alkalmazás által regisztrált bővítmények verzióit, a függőben lévő migrációk hiányát, valamint a verem teljes újraindítását annak bizonyítására, hogy magától visszaáll. A migráció nem fejeződik be, amikor a szolgáltatás válaszol. Akkor fejeződik be, amikor bebizonyosodott, hogy túléli a VDSM vendég újraindítását, és amikor a régi példány már nem fogad írásokat.

Egy megjegyzés arról, hogy hol lehet beszerezni ezeket a licenceket, mivel ez a mi tevékenységünk: Az SynoPower Club Synology licenceket árul a nap 24 órájában, azonnali kulcskiszállítással. A két dolog számít itt: Virtual DSM licenc, amelyre az ingyenes vendégen túl minden vendégnek szüksége van, és a VMM Pro licenc ha klaszterezést, élő migrációt vagy vendégenként 255 pillanatképet szeretne 32 helyett. A teljes licenckatalógus Az Surveillance Station és az MailPlus típusokat is lefedi.

Hivatkozások

• SynoPower Club, az Synology NAS útmutatóink és kameráink ismertetői
• Synology — Virtual Machine Manager, a VDSM-et futtató csomag hivatalos áttekintése
• Synology Tudásközpont — Virtual Machine Manager súgó, vendég létrehozása és beállításai
• Docker — docker konténer véglegesítése, az első lépés mögötti parancs
• Docker — docker kép mentése, a képek vendégek közötti streamelésére szolgál

Gyakran Ismételt Kérdések