Synology VMM Pro: Riktig størrelse på en produksjons-VM med AI (2026)

Den virtuelle maskinen som driver denne butikken brukte måneder på å bære dobbelt så mye maskinvare den trengte. Åtte virtuelle CPU-er, seksten gigabyte minne og en reell arbeidsmengde som aldri nådde mer enn en fjerdedel av noen av delene. Det er ikke uvanlig. Du dimensjonerer en gjest generøst på dag én fordi du ikke aner hva den vil trenge, nettstedet fungerer, og ingen går noen gang tilbake. Denne artikkelen er loggen over å gå tilbake. Vi kuttet den gjesten til fire vCPU-er og åtte gigabyte ved hjelp av Synology. VMM Pro, med en AI-assistent som kjørte skallet, og butikken var utilgjengelig i to minutter og syv sekunder. Selve størrelsesendringen er den kjedelige delen – det er to felt i en dialog. De interessante delene er målingen som beviste at åtte gigabyte var nok, rekkefølgen på operasjonene som hindrer gjesten i å gå tom for minne ved første oppstart, og øyeblikksbildet som gjorde alt reversibelt. VMM Pro gjør hver av disse billige, og det er det ærlige argumentet for det.

SynoPower Club-punkt:Riktig størrelsesregulering er den minst glamorøse jobben innen selvhosting, og den som gir best avkastning. Ingen skriver et blogginnlegg om de åtte gigabytene de ga tilbake. Men minnet som sitter inaktivt i en overdimensjonert gjest sparer deg ikke for noe – på en Synology er det låst, så det kan ikke brukes av noe annet på boksen. Vi fikk åtte gigabyte tilbake på en vert som begynte å føles full, som er to gjester til vi ikke lenger trenger å kjøpe maskinvare til. Det som gjorde det trygt snarere enn skremmende var VMM Pro under: et låst øyeblikksbilde før den første kommandoen, og en maskin jeg kunne sette tilbake slik den var på nitti sekunder hvis noe av dette gikk galt. Det gikk ikke galt. Men jeg ville ikke ha startet uten den.

Hva er Synology VMM Pro?

Virtual Machine Manager er Synologys hypervisorpakke. Den installeres fra Pakkesenteret, er gratis, og på en enkelt NAS vil den kjøre Linux-, Windows- og Virtual DSM-gjester med lokale snapshots uten problemer. VMM Pro er den betalte oppgraderingen som gjør den enkeltboks-hypervisoren om til en liten klynge: flere NAS-enheter administrert som ett basseng, gjester som kan bevege seg mellom dem, høy tilgjengelighet og replikering av øyeblikksbilder fra én vert til en annen.

Skillet er viktig for denne artikkelen fordi riktig størrelse er en kapasitetsbeslutning, og kapasitet blir bare interessant når du har mer enn én maskin i potten. På en enkelt NAS er minnet du frigjør minne som står ubrukt på den NAS-en. I en VMM Pro-klynge er det minne som en annen vert kan låne under en failover, eller som en ny gjest kan bygges inn i uten å kjøpe noe.

A Virtual DSM gjest – en full DSM-installasjon som kjører som en virtuell maskin – er arbeidsmengden vi endret størrelse på her. Den kjører Container Manager, som kjører de to Docker-containerne bak denne butikken. Denne lagdelingen er bevisst, og det er det som gjorde jobben sikker. Vi dekket flytting av en Docker-stack mellom gjester i vår gjennomgang av VDSM Docker-migrering; denne artikkelen handler om å lage gjesten under den i riktig størrelse.

VMM Pro vs. gratisutgaven: Hva oppgraderingen faktisk gir

Gratisutgaven er ikke en demo med dårlig kvalitet. Den kjører produksjonsgjester, tar øyeblikksbilder, og for en enkelt NAS er det egentlig alt folk flest trenger. Det du kjøper med VMM Pro er ikke funksjoner på en gjest, det er funksjoner på tvers av verter.

Evne	Gratis utgave	VMM Pro
Kjør gjester på én NAS	Ja	Ja
Lokale øyeblikksbilder	Ja	Ja
Flere NAS-enheter som én klynge	Ingen	Ja
Flytte en gjest mellom verter	Ingen	Ja
Failover med høy tilgjengelighet	Ingen	Ja
Repliker øyeblikksbilder til en annen vert	Ingen	Ja

Sjekk den offisielle funksjonssiden som er lenket i referansene før du kjøper, fordi Synology reviderer utgavefordelingen mellom DSM-utgivelser. Den praktiske testen er enklere enn tabellen: hvis du eier én NAS og er fornøyd med å gjenopprette fra et øyeblikksbilde for hånd, er gratisutgaven grei. I det øyeblikket du eier en andre NAS og du vil at gjestene på den første skal overleve at den dør, vil du ha en VMM Pro-lisens.

Klyngen vår består av tre noder, og bare to av dem er påslått mesteparten av tiden. Den tredje er en kald standby-modus som våkner etter en planlagt tidsplan for å motta replikerte øyeblikksbilder og går tilbake til dvale. Dette mønsteret – betal for strøm bare når du trenger redundansen – er et VMM Pro-mønster, og det er grunnen til at konsollen viser en permanent advarsel om en vert den ikke kan nå. Advarselen er at designet fungerer, ikke en feil.

Hvordan en produksjonsgjest ender opp med å bli dobbelt så stor som den trenger

Tre ting presser gjester oppover, og ingenting presser dem ned igjen. Den første er at den opprinnelige størrelsen er en gjetning, og en generøs gjetning koster ingenting på dag én. Den andre er at hver hendelse ender med at noen hever en grense. Vår hadde to minnehendelser i løpet av én uke; begge ble fikset ved å gi noe mer plass, og ingen av dem ble noen gang besøkt på nytt. Den tredje er at et dashbord som viser åtti prosent minnebruk ser alarmerende ut, så ingen melder seg frivillig til å ta minnet fra dem. Ingenting av dette er et VMM Pro-problem. Det er et menneskelig problem, og det er derfor store gjester er normen.

Det siste er fellen, og det er verdt å si rett ut: tallet folk flest ser på for å avgjøre om en container har plass er feil tall. Vårt tall sa at databasecontaineren var på åttien prosent av grensen. Det var den ikke. Del fem handler utelukkende om hvorfor, og om målingen som gjorde størrelsesendringen på VMM Pro til en trygg avgjørelse snarere enn en håpefull en.

Riktig størrelse på en levende gjest med VMM Pro i 4 trinn

Hele jobben er fire trinn, og bare det tredje trinnet tar nettstedet offline. Total nedetid for oss var to minutter og syv sekunder, målt fra det øyeblikket containerne stoppet til den første HTTP 200 etter at gjesten kom tilbake. VMM Pro er involvert i trinn én og tre; det midterste trinnet skjer inne i gjesten.

Hvorfor dockerstatistikk vil overtale deg til å ikke svare riktig

Før størrelsesendringen så containerdashbordet ut som en maskin uten plass til å gi:

docker-statistikk WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- ser nesten full ut

Les det, og du konkluderer med at databasen trenger sine fire gigabyte, og gjesten kan ikke gå under tolv. Begge konklusjonene er feil, fordi minnebruken disse verktøyene rapporterer inkluderer sidebuffer, og sidebufferen gjenvinnes automatisk i det øyeblikket noe annet trenger minnet. Tallet som avgjør om du får en minneavbrudd er anonymt minne. Les det direkte:

docker-sjef sh -c 'awk "/^(cache|rss) /{printf "%-8s %8.0f MBn", $1, $2/1048576}" /sys/fs/cgroup/memory/memory.stat' WordPress rss 1305 MB hurtigbuffer 1609 MB WordPress-DB rss 2553 MB hurtigbuffer 1543 MB

Nå inverteres bildet. Applikasjonscontaineren bruker faktisk 1,3 GB, ikke 2,5 GB. Og av disse 1,3 GB er 768 MB en enkelt delt opcode-cache som hver arbeidsprosess kartlegger i stedet for å kopiere – så tjue arbeidsprosesser kostet omtrent tjuesju megabyte hver, ikke de to hundre og femti megabytene som en naiv sum prosessminne antyder. Databasens 2,5 GB var nesten utelukkende et bufferbasseng på tre gigabyte for en database på 663 MB.

Enda en felle i samme familie: den historiske topptelleren viser gjerne en beholder som har berørt taket, fordi den telleren også inkluderer sidebuffer. Begge våre hadde det. Ingen av dem hadde noen gang blitt drept på grunn av tomt minne. Sjekk telleren for tomt minne, ikke toppmerket.

Med disse to faktaene i hånden, sluttet åtte gigabyte å være et risikabelt tall. Å redusere bufferbassenget til én gigabyte – fortsatt komfortabelt større enn hele databasen – frigjorde mer reelt minne enn størrelsesendringen trengte. Tallet vi til slutt skrev inn i VMM Pro var allerede bevist før gjesten ble stengt ned.

Hvordan et lite team bruker VMM Pro for å gjenerobre en hel server

Minne i en Synology-gjest er låst. Hypervisoren låser og forhåndsallokerer det, noe som betyr at du ikke kan overabonnere det slik du kan på noen andre plattformer. Seksten gigabyte tildelt en gjest er seksten gigabyte som ingen annen gjest kan ha, enten gjesten er opptatt eller inaktiv. Denne begrensningen er det som gjør riktig størrelsesvalg verdt å gjøre på VMM Pro spesifikt: å frigjøre minne er den eneste måten å skape kapasitet på, uten å kjøpe en NAS.

Åtte gigabyte kom tilbake på en vert med totalt 46,83 GB. Tilgjengelig minne gikk fra omtrent tjueto gigabyte til 30,29 GB. I praksis er det to gjester mer av den størrelsen vi faktisk kjører, laget av ingenting annet enn målinger. På en klynge med tre noder betyr det også at de overlevende vertene har mer kapasitet til å absorbere gjestene til en node som feiler, som er hele poenget med å betale for VMM Pro i utgangspunktet.

CPU-siden fortalte den samme historien mer direkte. Gjesten hadde åtte virtuelle CPU-er og brukte omtrent en sjettedel av én kjerne i ro. Fire var ikke et kompromiss; fire er fortsatt generøst, og VMM Pro brukte det i et enkelt felt. Siden størrelsesendringen har gjesten en gjennomsnittlig belastning på 1,36 mot fire vCPU-er, som er omtrent en tredjedel som brukes på den travleste delen av dagen.

Rekkefølgen på operasjoner som forhindrer en oppstartsløkke med tomt minne

Dette er den delen som er lett å gjøre feil og dyr å gjøre feil. Grensene for containerminne og gjesteminnet du setter i VMM Pro er to separate tak, og hvis summen av containergrensene overstiger gjesteminnet, har du fortalt containerne at de kan bruke mer enn maskinen har. Under belastning løser kjernen denne uenigheten ved å drepe noe.

Grensene våre før endringen var sju gigabyte for applikasjonscontaineren og fire for databasen – elleve gigabyte på en seksten gigabyte gjest, noe som var greit. På en åtte gigabyte gjest ville det ha vært en hendelse som ventet på sin første trafikkøkning. Så containerne måtte tas ned først:

Innstilling	Før	Etter
Gjest	8 vCPU / 16 GB	4 vCPU / 8 GB
Grense for applikasjonsbeholdere	7168 MB	4096 MB
Grense for databasebeholder	4096 MB	2048 MB
Databasebufferpool	3 GB	1 GB
Maksimalt antall tilkoblinger i databasen	300	100
Apache-arbeiderens tak	50	35

Det er en andreordens regel gjemt i den tabellen. Du kan ikke senke en containers minnegrense til under det den bruker for øyeblikket og forvente at kjernen skal være høflig overfor det. Applikasjonscontaineren brukte mindre enn den nye grensen, så den ble satt til live uten omstart og uten nedetid. Databasecontaineren brukte mer, så bufferpoolen måtte konfigureres på nytt og containeren startes på nytt først; først da kunne den nedre grensen brukes. Ingen av disse trinnene skjer i VMM Pro – begge må fullføres før du åpner dialogboksen for endring av størrelse.

Arbeidertaket er den ene reelle kostnaden ved hele øvelsen, og den fortjener å bli nevnt heller enn å bli begravd. Å kutte applikasjonscontaineren fra syv gigabyte til fire betyr at færre samtidige forespørsler kan være i gang: femti ned til trettifem, en tretti prosent reduksjon i maksimal samtidighet. Dag til dag kjører nettstedet elleve arbeidere, så ingenting endret seg. Under en reklameutbrudd kan det hende det. Det er en byttehandel vi har gjort bevisst, og den er skrevet ned slik at den neste personen ikke oppdager den igjen under et strømbrudd.

Hva AI-assistenten faktisk gjorde, og hvor det var galt

Assistenten gjorde de delene som belønner tålmodighet: den tok VMM Pro-øyeblikksbildet før den rørte noe, leste cgroup-statistikken i stedet for å stole på dashbordet, beregnet bestillingsbegrensningen på containergrensene og bekreftet resultatet ved å hente ekte sider og sjekke at prisene fortsatt gjengis i riktig valuta. Det er kanskje førti minutter med nøye arbeid komprimert til noen få minutter, og det er virkelig nyttig.

Det var også feil tre ganger i én økt, som er den mer nyttige halvdelen av historien.

• Den anbefalte ti gigabyte da eieren ba om åtte. Eieren hadde rett – men bare fordi det store bufferbassenget ble fikset samtidig. Assistenten hadde målingen foran seg og forankret seg fortsatt på det sikrere tallet.
• Den ga nytt navn til gjesten, les suksess: sant fra API-et, og rapporterte omdøpingen som fullført. Den hadde ikke fått nytt navn. Omdøpningsfeltet den brukte var det som identifiserer gjesten, ikke det som endrer navnet, og API-et returnerer suksess uansett.
• Den så en VMM Pro-klynge som advarer om en utilgjengelig vert og flagget den som en degradert failover-bane. Verten var en kald standby som bevisst er slått av. Varselet hadde vært der i flere måneder av tilsiktet grunn.

Mønsteret i alle tre er det samme: sikkert resultat fra en plausibel sjekk. De sikkerhetshensynene som faktisk betyr noe er derfor lite glamorøse. Ta øyeblikksbildet først, hver gang, før den første kommandoen, i stedet for før den risikable. Godta aldri en returverdi som bevis – les tilstanden tilbake og se på feltet du mente å endre. Og bekreft atferd, ikke innstillinger: en side som lastes inn og en korrekt pris slår et hvilket som helst antall bekreftelser på at en kommando avsluttet null.

Ingenting av dette er spesifikt for AI. Det er den samme disiplinen du ville ønske fra en ny kollega med root-tilgang som er rask, utrettelig og av og til sikker på noe som ikke er sant.

Hvor du finner flere offisielle ressurser

Tre videoer som er verdt å bruke tiden på før du endrer størrelse på noe med VMM Pro. Den første gir den beste oversikten over selve pakken; de to andre dekker oppretting og lisensiering av gjester, som er der folk flest står fast på første forsøk.

Grenser du bør vite før du stoler på VMM Pro med produksjon

Minne kan ikke overabonneres. Hver gigabyte du tildeler er låst bort fra alt annet på NAS-en, enten den er opptatt eller ikke. Dette er begrensningen som gjør riktig størrelsesvalg verdifullt, og det er også grunnen til at en generøs gjetning på dag én er dyrere her enn på plattformer som tillater overtildeling.

Krymping av minne krever en omstart, fordi VMM Pro ikke vil ta minne fra en kjørende gjest. Utvidelse av en virtuell disk skjer live, og det samme gjør utvidelse av noen ressurser, men å ta minne betyr å slå av gjesten. Budsjetter et kort driftsavbrudd og planlegg det; to minutter er oppnåelig, men det er ikke null.

Virtuelle disker vokser og krymper aldri. Hvis du overallokerer lagringsplass i stedet for minne, VMM Pro vil ikke gi den tilbake. Den eneste veien er å bygge en ny gjest og migrere inn i den, noe som er en mye lengre ettermiddag enn denne var.

CPU-grenser inne i containere fungerer kanskje ikke i det hele tatt. På denne gjesten har kjernen ingen CFS-båndbreddekontroll, så container-CPU-kvoter blir avvist direkte – og enda verre, forsøk på å sette en i samme kommando som en minnegrense fører til at hele kommandoen feiler stille. Minnegrenser og applikasjonens eget arbeidertak er den eneste CPU-beskyttelsen som er tilgjengelig.

Et øyeblikksbilde er ikke en sikkerhetskopi. Det ligger på samme vert og i samme lagringsbasseng som gjesten det beskytter. VMM Pro kan kopiere øyeblikksbilder til en annen vert, som er nærmere, men det som overlever en bygningsbrann er fortsatt en ekstern sikkerhetskopi av selve dataene.

Til slutt, se hva konsollen viser. Containerdetalj-sider viser miljøvariabler i ren tekst, inkludert databasepassord. Det er ærlig Docker snarere enn en feil i pakken, men det betyr at et enkelt skjermbilde av feil side publiserer en legitimasjon. Hvis det plager deg – burde det – flytt hemmeligheter til en fil som containeren leser i stedet for å sende dem som variabler.

Referanser

• SynoPower Club, våre Synology NAS-guider og kameraanmeldelser
• Synology — Virtual Machine Manager, den offisielle sammenligningen av funksjoner og utgaver
• Synology Kunnskapssenter — Virtual Machine Manager hjelp, gjesteinnstillinger og klyngeoppsett
• Docker – oppdatering av docker-containere, endre minnegrensen til en kjørende container
• Apache — MaxRequestWorkers, arbeidstakertaket som er omtalt i avsnitt syv

Ofte stilte spørsmål