Synology VDSM: Flytning af Docker med AI og ændring af størrelsen på en virtuel disk (2026)

En virtuel NAS er en af de funktioner, folk installerer én gang, roder i den en eftermiddag og så glemmer, at de ejer. Det er en skam, for Synology VDSM — Virtual DSM, kører inde i Virtual Machine Manager — løser stille og roligt to af de mest irriterende problemer i lille selvhosting. Det første er, at det normalt koster en aften med besværligt arbejde at flytte en Docker-stak mellem maskiner. Det andet er, at når en virtuel disk løber tør for plads, antager de fleste, at de skal genopbygge det hele. Ingen af delene gælder for VDSM. Denne guide gennemgår en rigtig migrering, vi kørte på omkring 35 minutter: en intern Redmine-problemtracker med fem plugins, løftet ud af en VDSM-gæst og placeret i en anden, med en AI-assistent, der drev skallen. Undervejs løb destinationen tør for disk, så vi udvidede dens virtuelle disk fra 10 GB til 20 GB og fortsatte. Alt nedenfor er, hvad der rent faktisk skete, inklusive den ene fælde, der lydløst ville have ødelagt applikationen.

SynoPower Club-punkt:Jeg har set mange mennesker tale sig selv fra virtualisering på en NAS, fordi de antager, at det er til laboratoriebrug og ikke til rigtigt arbejde. Migreringen i denne artikel var rigtigt arbejde - et ticketsystem, som tre kolleger bruger hver dag - og den del, der overraskede mig, var ikke AI'en. Det var, hvor lidt ceremoniel VDSM behøver. Ingen hypervisor at licensere, ingen separat administrationsserver, ingen eksport-import-dans mellem inkompatible formater. Gæstefunktionen løb tør for disk midt i et job, og jeg løste det ved at skrive et større tal i et tekstfelt, mens det stadig kørte. Hele jobbet tog 35 minutter, og den eneste afbrydelse, nogen bemærkede, var 90 sekunder på et urelateret websted. Hvis du allerede ejer en Synology med ekstra hukommelse, er du én pakkeinstallation væk fra dette.

Hvad er Synology VDSM?

VDSM er Synology's Virtual DSM: en komplet kopi af DiskStation Manager, der kører som et gæsteoperativsystem inde i Virtual Machine Manager på en fysisk NAS. Den opfører sig som en separat NAS. Dens egen IP-adresse, sit eget DSM-login, sine egne pakker, sin egen Container Manager. Fra netværkets synspunkt er der blot en anden Synology på LAN'et. Fra hardwarens synspunkt er det endnu en proces på en boks, du allerede har betalt for.

Den praktiske fordel er isolation. Kør alle tjenester direkte på værten, og én dårligt opført container kan udsulte den filserver, som hele kontoret er afhængig af. Opdeling af arbejdsbelastninger på tværs af VDSM-gæster giver hver enkelt et hukommelsesloft, en CPU-allokering og en disk, og du kan genstarte en uden at røre de andre.

Hver NAS, der understøtter Virtual Machine Manager, inkluderer én VDSM-licens uden omkostninger. Kørsel af en anden og efterfølgende gæstelicens kræver en betalt Virtual DSM-licens hver. Den ene gratis instans er nok til at følge alt i denne artikel, og det er derfor, så mange mennesker allerede ejer funktionen og aldrig har aktiveret den. Hvis du har brug for at tilføje, tilknytte eller fjerne tilknytningen af en licens senere, har vi en gennemgang af administration af VDSM-licenser.

VDSM og Virtual DSM er to navne for det samme. Synologys egen dokumentation bruger den lange form, og de fleste ejere bruger den korte. Forkortelsen deles også med en uafhængig komponent af oVirt-virtualiseringsprojektet, så på en Synology NAS betyder det altid Virtual DSM.

En betalt licens fungerer anderledes, end de fleste forventer. Hver licens tilføjer en gæst mere og inkluderer tre års Virtual DSM-softwareopgraderinger. Den virtuelle maskine udløber aldrig. Efter de tre år kører den videre uden nye opdateringer. Aktivering af en ny nøgle starter yderligere tre års opdateringer. En nøgle er aktiv på én Synology NAS ad gangen, og NAS'en skal være online, når du tilføjer den.

Kravene til en VDSM-gæst er beskedne, og Synology angiver dem i sin Virtual Machine Manager specifikationer:

• Den virtuelle disk skal være placeret på et Btrfs-volumen. Virtual Machine Manager gemmer ikke gæster på ext4.
• Selve NAS'en skal bruge mere end 2 GB hukommelse, før den kan køre en virtuel maskine.
• Hver gæst har brug for mindst 1 GB hukommelse, og reelle arbejdsbelastninger kræver mere.
• Hvor mange gæster en model komfortabelt kan køre, afhænger af dens CPU og installerede hukommelse.

En gæst er ikke identisk med DSM på bare metal. Tre ting mangler, som alle er knyttet til fysisk hardware:

• USB-passthrough er ikke tilgængelig, så en enhed, der er tilsluttet en USB-port på NAS'en, kan ikke gives til gæsten.
• Siderne Eksterne enheder og Hardware og strøm i kontrolpanelet er ikke der.
• Trådløse dongler, MTU-indstillinger og linkaggregation (LACP) understøttes ikke i gæstesystemet. Værten håndterer det fysiske netværk.

Intet af det påvirker de sædvanlige grunde til at køre en. Filtjenester, Docker, en mailserver eller en staging-kopi af et produktionssystem opfører sig alle som på en separat NAS.

Synology VDSM vs. en anden fysisk NAS: Hvilken har du brug for?

Den ærlige sammenligning er ikke, at virtuel er bedre. Det er en byttehandel mellem robusthed og fleksibilitet. En anden fysisk boks overlever den førstes fejl; det gør en VDSM-gæst ikke. Det, en gæst køber dig i stedet, er muligheden for at oprette, ændre størrelse, tage snapshots af og flytte en hel server på få minutter i stedet for dage.

	VDSM-gæst	Anden fysisk NAS
Prisen for at tilføje en	Gratis for den første gæst, licens derefter	En hel NAS plus drev
Tid til levering	Minutter	Dage, når forsendelsen er talt med
Ændre størrelse på CPU, RAM eller disk	Rediger et felt, genstart gæsten	Køb nyt hardware
Overlever hardwarefejl på værten	Ingen	Ja
Snapshot og klon	Indbygget i Virtual Machine Manager	Ikke relevant
Flyt til en anden NAS	Migrer eller repliker gæsten	Flyt det fysisk
Bedst til	Isolering af tjenester, staging, konsolidering af små servere	Backupmål og reel redundans

Til dette job var valget oplagt. Vi konsoliderede en let brugt problemsporing, der havde fået sin egen komplette VDSM-gæst, til en gæst, der allerede kørte et websted med ekstra kapacitet. Intet ved det kræver ny hardware. Det kræver ti minutter og lidt pleje.

Hvad du behøver, før du starter

Giv først assistenten sit eget login i stedet for at give dit. Åbn Kontrolpanel i DSM, gå til Bruger og gruppe, og klik på Opret. Navngiv det noget umiskendeligt – vi brugte Claude med beskrivelsen AI-kontrol — og lad DSM generere en stærk, tilfældig adgangskode.

På den næste skærm skal du markere administratorer. Dette er ikke valgfrit: DSM tillader kun medlemmer af administratorgruppen at logge ind via SSH, så en konto uden for denne gruppe kan slet ikke nå shell'en. Gør det samme på begge VDSM-gæster, og sørg derefter for, at SSH er aktiveret under Kontrolpanel, Terminal og SNMP.

Når arbejdet er færdigt, skal du deaktivere kontoen. Det er hele pointen med at oprette en separat. Rediger brugeren i Kontrolpanel og sluk den, eller slet den helt; adgangen tilbagekaldes med et enkelt klik uden at røre dine egne legitimationsoplysninger, og alt hvad assistenten gjorde, forbliver tilskrives et login, der findes til præcis det formål. At lade en permanent aktiveret administratorkonto ligge rundt, fordi det var praktisk engang, er sådan små ejendomme akkumulerer adgang, som ingen husker at have givet.

To VDSM-gæster, SSH aktiveret på begge, og Container Manager installeret på destinationen. Du skal også vide én ting, der fanger næsten alle første gang: Docker-binærfilen er ikke på standardstien i DSM. Pakkebinærfiler findes under pakkemappen, så hver kommando skal bruge den fulde sti eller et shell-alias.

Tjek, at der er plads på destinationen, inden du starter, i stedet for halvvejs gennem en transfer. Kommandoerne nedenfor er hele kontrollen før flyvningen, og de er identiske for alle VDSM-gæster.

En ting mere før alt det her: tag et snapshot af begge gæster i Virtual Machine Manager. Snapshots findes i gratisudgaven af Virtual Machine Manager, ikke kun Pro, og den gemmer op til 32 af dem pr. gæst. Et VDSM-snapshot optager hele maskinen, så hvis en import går galt, eller en kommando gør noget, du ikke havde til hensigt, ruller du gæsten tilbage i stedet for at genopbygge den. Det koster sekunder, og det er den billigste forsikring i hele denne proces. Tag en på både kilden og destinationen, fordi kilden er din reserve.

# Docker er ikke på PATH i DSM - brug den fulde sti D=/volume1/@appstore/ContainerManager/usr/bin/docker # Hvad kører, og hvad er det bygget af? sudo $D ps -a sudo $D images # Hvor meget plads er der tilbage på destinationsvolumen? df -h /volume1 # Hvor meget hukommelse har destinationsgæsten faktisk ledig? free -m

VDSM Docker-migrering i 4 trin

Dette er de fire trin, vi kørte, og de fungerer for enhver containerstak, du skal løfte mellem VDSM-gæster. Rækkefølgen er vigtig: applikationscontaineren stoppes først, så intet skriver til databasen midt i dumpingen, og databasecontaineren forbliver oppe, så den kan dumpes uden problemer.

Hvorfor Compose-filen ikke er hele containeren

Her er fælden, og den er i sig selv prisen værd. Compose-filen til vores Redmine-stak deklarerede to bind-mounts: en til uploadede filer og en til databasen. Læs den fil, og du ville med rimelighed konkludere, at genskabelse af stakken på den nye gæst betød at kopiere to mapper og køre docker compose.

Det gjorde det ikke. Fem plugins, Ruby-perlerne, som disse plugins hentede, mailkonfigurationen og adskillige redigerede initialiseringsfiler var alle blevet installeret direkte i den kørende container gennem årene. Intet af det var på en volumen. Én kommando fortalte os, hvor slemt det var.

# Hvor mange filer er forskellige mellem containeren og det billede, den kommer fra? sudo $D diff Redmine | wc -l 6764 # Plugins, der findes inde i containeren, men ikke er bakket op af noget volumen overhovedet sudo $D exec Redmine ls /usr/src/redmine/plugins

Hvis man trækker et nyt officielt image, ville det have produceret en container uden disse plugins, peget på en database, der stadig indeholdt de 144 tabeller, der blev oprettet af deres migreringer. Applikationen ville ikke have fejlet voldsomt. Den ville have startet, set næsten korrekt ud og derefter brudt sammen på måder, der er elendige at diagnosticere. At committe den kørende container til et image omgår problemet fuldstændigt, på bekostning af en større overførsel. På et LAN mellem to VDSM-gæster koster det omkring et minut, så byt hver gang.

Hvordan et lille team bruger VDSM til at konsolidere servere

Det mønster, som denne migration følger, er et, som de fleste små teams i sidste ende får brug for. Over et par år akkumulerer I gæster med ét formål: én til wikien, én til tickettrackeren, én til et overvågningsdashboard (den form, der er beskrevet i vores gennemgang af hjemmedatacenter). Hver af dem var dimensioneret generøst den dag, de blev bygget, og hver især kører nu på tomgang til en brøkdel af, hvad de fik, mens værten er overdedikeret, og alt føles lidt langsomt.

Konsolidering med VDSM betyder at folde de stille arbejdsbyrder ind i en gæst, der allerede er aktiv. Vores ticket tracker havde en hel gæst med sin egen CPU-allokering og 1 GB hukommelse, for en tjeneste, som tre personer berører et par gange om dagen. At flytte den ved siden af en eksisterende webstak frigav denne allokering fuldstændigt og kostede destinationen omkring 480 MB resident hukommelse på tværs af to containere.

Disciplinen, der gør dette sikkert, er at trække kildekoden korrekt tilbage i stedet for at lade den køre. Vi satte de gamle containere til en genstartspolitik på nej, stoppede dem, efterlod en tekstfil i mappen, der forklarede, hvor tjenesten nu befinder sig, og lukkede gæsteserveren ned med automatisk start deaktiveret. Den forbliver et komplet rollback-punkt, og den kan ikke stille og roligt komme tilbage til live efter en genstart af værten og begynde at acceptere skrivninger, som den nye instans aldrig vil se. Divergerende dubletter er den klassiske måde, hvorpå en ryddelig migrering bliver til en datatabshændelse en måned senere.

Ændring af størrelsen på en virtuel disk, der har løbet tør for plads

Halvvejs løb destinationen tør for plads. Dens volumen var 9,6 GB med 1,5 GB ledig plads, og vi var ved at tilføje et 816 MB image plus 123 MB programdata. På en fysisk NAS stopper historien her, indtil nye drev ankommer. På VDSM er det et tekstfelt.

Åbn gæstens indstillinger i Virtual Machine Manager, gå til fanen Lagerplads, indtast den nye størrelse, og klik på OK. Gæsten behøver ikke at blive lukket ned for dette. Disken vokser, mens maskinen kører, hvilket er grunden til, at dette er en fundamentalt anderledes oplevelse end at tilføje kapacitet til bare hardware. Den eneste regel, der er værd at kende, er, at en virtuel disk kun kan vokse, aldrig krympe, så der er ingen mulighed for at fortryde og ingen grund til at være genert med antallet.

Det, der gør det virkelig smertefrit, er det, der sker inde i gæstefunktionen. DSM udvider partitionen og filsystemet for at udfylde den nye plads alene. Der er ingen Storage Manager-guide at køre, ingen partitionstabel at redigere, ingen diskenhed at genopbygge og ingen data at migrere. Vores diskenhed gik fra 9,6 GB med 1,5 GB ledig plads til 20 GB med 13 GB ledig plads, og containerne fortsatte. Dette er det stærkeste argument for at placere en tjeneste på VDSM i stedet for på bare hardware: forkert størrelsesjustering er billig at rette senere.

Hvad AI-assistenten rent faktisk gjorde

Det er værd at være præcis her, fordi "AI flyttede min server" inviterer til både for meget og for lidt godtroenhed. Assistenten havde ingen magisk indsigt. Den havde en skal på begge VDSM-gæster, og den var systematisk på en måde, som et træt menneske normalt ikke er ved slutningen af en arbejdsdag.

Den absolut mest værdifulde ting, den gjorde, var at køre docker diff, før den rørte ved noget, bemærke 6.764 ændrede filer og afvise den åbenlyse plan. Enhver, der fulgte compose-filen, ville ikke have haft nogen grund til at køre den kommando. Den næstmest værdifulde ting var verifikation: efter importen talte den tabeller, problemer, projekter, journalposter og vedhæftede filer på begge sider, kontrollerede, at alle vedhæftede filer fandtes på disken, listede de plugin-versioner, som applikationen havde registreret, og bekræftede, at der ikke var nogen ventende databasemigreringer. Det er en kedelig tjekliste, og kedelige tjeklister er præcis det, der springes over klokken fem om eftermiddagen.

Det, der stadig manglede fra et menneske, var en vurdering af konsekvenserne. At genstarte en VDSM-gæst for at tilføje hukommelse betød at tage et livewebsted ned, og det er en beslutning, man skal spørge om snarere end at antage. Det samme gælder for sletning af hvad som helst. Behandl assistenten som et meget hurtigt, meget bogstaveligt par hænder, der aldrig bliver trætte af at tjekke, og behold de irreversible opkald for dig selv.

Hvor finder man flere officielle ressourcer

Virtual Machine Manager, pakken der hoster alle VDSM-gæster, har været i DSM i årevis og er godt dækket. Disse tre gennemgange dækker installation af pakken, oprettelse af en gæst og den generelle form af den brugerflade, du vil arbejde i.

Begrænsninger du skal kende, før du stoler på VDSM med produktion

For det første er hukommelsen den bindingsmæssige begrænsning langt oftere end CPU'en. Vores destinationsgæst havde 2 GB og var allerede i gang med swap, før vi tilføjede noget. En anden applikation plus en anden database krævede yderligere cirka 480 MB, så vi hævede det til 4 GB. Tjek den ledige hukommelse på destinationen, før du planlægger flytningen, ikke bagefter.

For det andet vokser en virtuel VDSM-disk, men krymper aldrig. Overprovisionering, og du kan ikke genvinde pladsen ved at redigere feltet ned igen; den eneste vej til en mindre disk er at oprette en ny gæst og migrere til den. Vælg et antal, du stadig vil være tilfreds med om to år.

For det tredje, licensering. Én gæst er inkluderet i NAS'en; hver yderligere gæst skal have sin egen Virtual DSM licens. Klyngedannelse på tværs af flere NAS-enheder, live-migrering og den større snapshot-retention er VMM Pro funktioner i stedet for standardfunktioner. Hvis din konsolideringsplan involverer at opdele én travl gæst i fire pæne, så prissæt det, før du designer det.

Det er sin egen opgave at vurdere en gæst korrekt: Sådan justerer du størrelsen på en produktions-VM med VMM Pro.

For det fjerde, scenarier, der skal undgås. Placer ikke en gæsts virtuell disk på den samme fysiske enhed, som du sikkerhedskopierer til, og kald det en sikkerhedskopi. Kør ikke en database med mange vedvarende skrivninger på en gæst, der deler roterende diske med en travl filserver. Behandl ikke VDSM som en erstatning for en anden maskine, for hvis værten dør, dør alle gæster på den på samme tid. Og migrer ikke en container, du aldrig har inspiceret, af årsagerne i afsnittet om at oprette fil ovenfor.

For det femte, legitimationsoplysninger. En migrering berører databaseadgangskoder, miljøvariabler og konfigurationsfiler. Vores flyttede en compose-fil, der indeholdt almindelige databaselegitimationsoplysninger, så den blev bevidst placeret uden for webserverens dokumentrod. En compose-fil, der efterlades i en dokumentrod, kan downloades af alle, der gætter filnavnet, og det er en deprimerende almindelig måde, legitimationsoplysninger lækker på. Hvis du lader en assistent scripte en migrering, skal du læse, hvor den skriver filer. Og når jobbet er færdigt, skal du deaktivere den konto, du oprettede til assistenten, i stedet for at efterlade et live administratorlogin.

For det sjette, et snapshot, før du rører ved noget. Et VDSM-snapshot i Virtual Machine Manager tager få sekunder, er tilgængeligt uden Pro-licensen og forvandler næsten alle fejl i denne artikel til en to-minutters rollback. Det er det ene trin, der er værd at tilføje til enhver migrerings-runbook, uanset om et menneske eller en assistent skriver.

Endelig, verificér snarere end antag. Alle påstande i denne artikel blev kontrolleret mod det kørende system: tabelantal på begge sider, vedhæftede filer på disken, plugin-versioner registreret af applikationen, ingen ventende migreringer og en fuld genstart af stakken for at bevise, at den kommer tilbage af sig selv. En migrering er ikke afsluttet, når tjenesten svarer. Den er afsluttet, når du har bevist, at den overlever en genstart af VDSM-gæsten, og når den gamle kopi ikke længere kan acceptere skrivninger.

En bemærkning om hvor man kan få disse licenser, da det er det, vi gør: SynoPower Club sælger Synology-licenser med øjeblikkelig nøglelevering døgnet rundt. De to, der betyder noget her, er Virtual DSM licens, som du skal bruge for hver gæst ud over den gratis gæst, og VMM Pro licens hvis du ønsker klyngedannelse, livemigrering eller 255 snapshots pr. gæst i stedet for 32. Den fuldt licenskatalog dækker også Surveillance Station og MailPlus.

Referencer

• SynoPower Club, vores Synology NAS-guider og kameraanmeldelser
• Synology — Virtual Machine Manager, den officielle oversigt over pakken, der kører VDSM
• Synology Videnscenter — Virtual Machine Manager hjælp, gæsteoprettelse og indstillinger
• Docker — docker container commit, kommandoen bag trin et
• Docker — gem docker-billede, bruges til at streame billedet mellem gæster

Ofte stillede spørgsmål