Synology VMM Pro: Korrekt størrelsesjustering af en produktions-VM med AI (2026)

Den virtuelle maskine, der driver denne butik, brugte måneder på at bære dobbelt så meget hardware, den havde brug for. Otte virtuelle CPU'er, seksten gigabyte hukommelse og en reel arbejdsbyrde, der aldrig rørte mere end en fjerdedel af nogen af delene. Det er ikke usædvanligt. Du dimensionerer en gæst generøst på dag ét, fordi du ikke aner, hvad den skal bruge, siden fungerer, og ingen går nogensinde tilbage. Denne artikel er loggen over at gå tilbage. Vi reducerede den gæst til fire vCPU'er og otte gigabyte ved hjælp af Synology. VMM Pro, med en AI-assistent, der styrer skallen, og butikken var utilgængelig i to minutter og syv sekunder. Selve størrelsesændringen er den kedelige del - det er to felter i en dialog. De interessante dele er målingen, der beviste, at otte gigabyte var nok, rækkefølgen af operationer, der forhindrer gæsten i at løbe tør for hukommelse ved første opstart, og det snapshot, der gjorde det hele reversibelt. VMM Pro gør hver af dem billige, og det er det ærlige argument for det.

SynoPower Club-punkt:Den rigtige størrelse er det mindst glamourøse job inden for selvhosting og det med det bedste afkast. Ingen skriver et blogindlæg om de otte gigabyte, de gav tilbage. Men hukommelsen, der sidder inaktiv i en overdimensioneret gæst, sparer dig ikke noget - på en Synology er den fastlåst, så den kan ikke bruges af noget andet på boksen. Vi fik otte gigabyte tilbage på en vært, der begyndte at føles fuld, hvilket er to gæster mere, vi ikke længere behøver at købe hardware til. Det, der gjorde det sikkert snarere end skræmmende, var VMM Pro nedenunder: et låst snapshot før den første kommando, og en maskine, jeg kunne sætte tilbage til sin oprindelige position på halvfems sekunder, hvis noget af dette gik galt. Det gik ikke galt. Men jeg ville ikke være startet uden den.

Hvad er Synology VMM Pro?

Virtual Machine Manager er Synologys hypervisorpakke. Den installeres fra Pakkecenter, er gratis, og på en enkelt NAS kan den uden problemer køre Linux, Windows og Virtual DSM-gæster med lokale snapshots. VMM Pro er den betalte opgradering, der forvandler den enkeltstående hypervisor til en lille klynge: flere NAS-enheder administreret som én pool, gæster, der kan bevæge sig mellem dem, høj tilgængelighed og snapshot-replikering fra én vært til en anden.

Sondringen er vigtig for denne artikel, fordi korrekt størrelsesvalg er en kapacitetsbeslutning, og kapacitet bliver først interessant, når du har mere end én maskine i puljen. På en enkelt NAS er den hukommelse, du frigør, hukommelse, der står ubrugt på den NAS. I en VMM Pro-klynge er det hukommelse, som en anden vært kan låne under en failover, eller som en ny gæst kan bygges ind i uden at købe noget.

A Virtual DSM gæst — en fuld DSM-installation, der kører som en virtuel maskine — er den arbejdsbelastning, vi har ændret størrelse på her. Den kører Container Manager, som kører de to Docker-containere bag dette lager. Denne lagdeling er bevidst, og det er det, der gjorde jobbet sikkert. Vi dækkede flytning af en Docker-stak mellem gæster i vores gennemgang af VDSM Docker-migrering; denne artikel handler om at lave gæsten under den i den rigtige størrelse.

VMM Pro vs. gratisudgaven: Hvad opgraderingen rent faktisk giver

Gratisudgaven er ikke en hæmmet demo. Den kører produktionsgæster, tager snapshots, og for en enkelt NAS er det virkelig alt, hvad de fleste har brug for. Hvad du køber med VMM Pro er ikke funktioner på en gæst, det er funktioner på tværs af værter.

Evne	Gratis udgave	VMM Pro
Kør gæster på én NAS	Ja	Ja
Lokale øjebliksbilleder	Ja	Ja
Flere NAS-enheder som én klynge	Ingen	Ja
Flyt en gæst mellem værter	Ingen	Ja
Failover med høj tilgængelighed	Ingen	Ja
Replikér snapshots til en anden vært	Ingen	Ja

Tjek den officielle funktionsside, der er linket til i referencerne, før du køber, fordi Synology reviderer udgavefordelingen mellem DSM-udgivelser. Den praktiske test er enklere end tabellen: hvis du ejer én NAS, og du er tilfreds med at gendanne fra et snapshot i hånden, er gratisudgaven fin. I det øjeblik du ejer en anden NAS, og du vil have, at den førstes gæster skal overleve dens død, vil du have en VMM Pro licens.

Vores klynge består af tre noder, og kun to af dem er tændt det meste af tiden. Den tredje er en kold standby-tilstand, der vågner efter en tidsplan for at modtage replikerede snapshots og går tilbage i dvale. Dette mønster - betal kun for strøm, når du har brug for redundansen - er et VMM Pro-mønster, og det er grunden til, at konsollen viser en permanent advarsel om en vært, den ikke kan nå. Advarslen skyldes designet, der fungerer, ikke en fejl.

Hvordan en produktionsgæst ender med at være dobbelt så stor som den har brug for

Tre ting skubber gæster opad, og intet skubber dem ned igen. Den første er, at den oprindelige størrelse er et gæt, og et generøst gæt koster ingenting på dag ét. Den anden er, at hver hændelse ender med, at nogen hæver en grænse. Vores havde to hukommelseshændelser på én uge; begge blev rettet ved at give noget mere plads, og ingen af dem blev nogensinde genovervejet. Den tredje er, at et dashboard, der viser 80 procents hukommelsesforbrug, ser alarmerende ud, så ingen melder sig frivilligt til at tage hukommelsen væk. Intet af det er et VMM Pro problem. Det er et menneskeligt problem, og det er derfor, at overdimensionerede gæster er normen.

Den sidste er fælden, og det er værd at sige det ligeud: det tal, de fleste bruger for at afgøre, om en container har plads, er det forkerte tal. Vores tal viste, at databasecontaineren var nået 81 procent af sin grænse. Det var den ikke. Afsnit fem handler udelukkende om hvorfor, og om den måling, der gjorde størrelsesændringen på VMM Pro til en sikker beslutning snarere end en håbefuld.

Den rigtige størrelse på en live gæst med VMM Pro i 4 trin

Hele jobbet er fire trin, og kun det tredje tager webstedet offline. Den samlede nedetid for os var to minutter og syv sekunder, målt fra det øjeblik containerne stoppede til den første HTTP 200 efter gæsten kom tilbage. VMM Pro er involveret i trin et og tre; det midterste trin sker inde i gæsten.

Hvorfor docker-statistik vil tale dig fra det rigtige svar

Før størrelsesændringen lignede containerens dashboard en maskine uden plads til:

docker statistik WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- ser næsten fuld ud

Læs det, og du konkluderer, at databasen har brug for sine fire gigabyte, og at gæsten ikke kan komme under tolv. Begge konklusioner er forkerte, fordi hukommelsesforbruget, som disse værktøjer rapporterer, inkluderer sidecache, og sidecache genvindes automatisk i det øjeblik, noget andet har brug for hukommelsen. Det tal, der afgør, om du får en out-of-memory kill, er anonym hukommelse. Læs det direkte:

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

Nu vender billedet om. Applikationscontaineren bruger reelt 1,3 GB, ikke 2,5 GB. Og af de 1,3 GB er 768 MB en enkelt delt opcode-cache, som hver arbejdsproces mapper i stedet for at kopiere - så tyve arbejdsprocesser kostede cirka 27 megabyte hver, ikke de 250 megabyte, som en naiv sum proceshukommelse antyder. Databasens 2,5 GB var næsten udelukkende en bufferpulje på tre gigabyte til en database på 663 MB.

Endnu en fælde i samme familie: den historiske peak-tæller viser med glæde en container, der har rørt ved loftet, fordi den tæller også indeholder sidecache. Det havde begge vores. Ingen af dem var nogensinde blevet afbrudt på grund af manglende hukommelse. Tjek tælleren for manglende hukommelse, ikke high water mark.

Med disse to fakta i hånden, holdt otte gigabyte op med at være et risikabelt tal. At reducere bufferpuljen til én gigabyte – stadig komfortabelt større end hele databasen – frigjorde mere reel hukommelse end den nødvendige størrelsesændring. Det tal, vi til sidst indtastede i VMM Pro, var allerede bevist, før gæstefunktionen blev lukket ned.

Hvordan et lille team bruger VMM Pro til at generobre en hel server

Hukommelsen i en Synology-gæst er fastlåst. Hypervisoren låser og forudallokerer den, hvilket betyder, at du ikke kan overabonnere den på samme måde som på nogle andre platforme. Seksten gigabyte tildelt en gæst er seksten gigabyte, som ingen anden gæst kan have, uanset om gæsten er optaget eller inaktiv. Det er denne begrænsning, der gør det værd at foretage korrekt størrelsesjustering. VMM Pro specifikt: frigørelse af hukommelse er den eneste måde at skabe kapacitet på, udover at købe en NAS.

Otte gigabyte kom tilbage på en vært med i alt 46,83 GB. Den tilgængelige hukommelse steg fra cirka 22 gigabyte til 30,29 GB. I praksis er det to gæster mere af den størrelse, vi rent faktisk kører, skabt udelukkende ud fra målinger. På en klynge med tre noder betyder det også, at de overlevende værter har mere plads til at absorbere gæsterne fra en node, der fejler, hvilket er hele pointen med at betale for VMM Pro i første omgang.

CPU-siden fortalte den samme historie mere direkte. Gæsten havde otte virtuelle CPU'er og brugte omkring en sjettedel af én kerne i hvile. Fire var ikke et kompromis; fire er stadig generøst, og VMM Pro anvendte det i et enkelt felt. Siden størrelsesændringen ligger gæsten på en gennemsnitlig belastning på 1,36 mod fire vCPU'er, hvilket er omtrent en tredjedel, der bruges på den travleste del af dagen.

Rækkefølgen af operationer, der forhindrer en opstartsløkke med manglende hukommelse

Det er den del, der er let at lave forkert, og dyr at lave forkert. Containerhukommelsesgrænser og gæstehukommelsen, du sætter i VMM Pro, er to separate lofter, og hvis summen af containergrænserne overstiger gæstens hukommelse, har du fortalt containerne, at de må bruge mere, end maskinen har. Under belastning løser kernen denne uenighed ved at dræbe noget.

Vores grænser før ændringen var syv gigabyte for applikationscontaineren og fire for databasen — elleve gigabyte på en gæst på seksten gigabyte, hvilket var fint. På en gæst på otte gigabyte ville det have været en hændelse, der ventede på sin første trafikstigning. Så containerne skulle først ned:

Indstilling	Før	Efter
Gæst	8 vCPU'er / 16 GB	4 vCPU'er / 8 GB
Grænse for applikationscontainere	7168 MB	4096 MB
Grænse for databasecontainere	4096 MB	2048 MB
Databasebufferpulje	3 GB	1 GB
Maksimalt antal forbindelser til databasen	300	100
Apache-arbejderloft	50	35

Der gemmer sig en andenordensregel i den tabel. Du kan ikke sænke en containers hukommelsesgrænse til under det, den bruger i øjeblikket, og forvente, at kernen er høflig omkring det. Applikationscontaineren brugte mindre end sin nye grænse, så den blev begrænset live uden genstart og uden nedetid. Databasecontaineren brugte mere, så dens bufferpulje skulle omkonfigureres, og containeren skulle genstartes først; først derefter kunne den nedre grænse anvendes. Ingen af disse trin sker i VMM Pro - begge skal være afsluttet, før du åbner dialogboksen til ændring af størrelse.

Loftet over antallet af arbejdere er den eneste reelle omkostning ved hele øvelsen, og den fortjener at blive nævnt snarere end at blive begravet. At reducere applikationscontaineren fra syv gigabyte til fire betyder, at færre samtidige anmodninger kan være i gang: halvtreds ned til femogtredive, en reduktion på tredive procent i peak samtidighed. Dag til dag har webstedet elleve arbejdere, så intet ændrede sig. Under en reklameudbrud kunne det ske. Det er en byttehandel, vi har foretaget bevidst, og den er skrevet ned, så den næste person ikke genopdager den under et nedbrud.

Hvad AI-assistenten rent faktisk gjorde, og hvor det var forkert

Assistenten udførte de dele, der belønner tålmodighed: den tog et VMM Pro-snapshot, før den rørte ved noget, læste cgroup-statistikkerne i stedet for at stole på dashboardet, beregnede ordrebegrænsningen på containergrænserne og verificerede resultatet ved at hente rigtige sider og kontrollere, at priserne stadig blev vist i den rigtige valuta. Det er måske fyrre minutters omhyggeligt arbejde komprimeret til et par minutter, og det er virkelig nyttigt.

Det gik også forkert tre gange i én session, hvilket er den mere nyttige halvdel af historien.

• Den anbefalede ti gigabyte, da ejeren bad om otte. Ejeren havde ret – men kun fordi den overdimensionerede bufferpool blev rettet samtidig. Assistenten havde målingen foran sig og holdt sig stadig til det sikrere tal.
• Den omdøbte gæsten, læs succes: sandt fra API'en og rapporterede omdøbningen som udført. Den var ikke blevet omdøbt. Det omdøbningsfelt, den brugte, var det, der identificerer gæsten, ikke det, der ændrer dens navn, og API'en returnerer succes under alle omstændigheder.
• Den så en VMM Pro-klynge, der advarer om en utilgængelig vært, og markerede den som en degraderet failover-sti. Værten var en kold standby, der bevidst er slukket. Advarslen havde været der i flere måneder af designmæssige årsager.

Mønsteret i alle tre er det samme: sikkert output fra en plausibel kontrol. De begrænsninger, der rent faktisk betyder noget, er derfor uglamourøse. Tag et snapshot først, hver gang, før den første kommando i stedet for før den risikable. Accepter aldrig en returværdi som bevis - læs tilstanden tilbage og se på det felt, du ville ændre. Og verificer adfærd, ikke indstillinger: en side, der indlæses, og en korrekt pris slår et hvilket som helst antal bekræftelser på, at en kommando afsluttede nul.

Intet af det er specifikt for AI. Det er den samme disciplin, man ville ønske sig af en ny kollega med root-adgang, som er hurtig, utrættelig og af og til sikker på noget, der ikke er sandt.

Hvor finder man flere officielle ressourcer

Tre videoer, der er værd at bruge tiden på, før du ændrer størrelsen på noget med VMM Pro. Den første er det bedste overblik over selve pakken; de to andre dækker oprettelse og licensering af gæster, hvilket er der, hvor de fleste går i stå i første forsøg.

Begrænsninger, du skal kende, før du stoler på VMM Pro med produktionen

Hukommelse kan ikke overabonneres. Hver gigabyte, du tildeler, er låst væk fra alt andet på NAS'en, uanset om den er optaget eller ej. Det er denne begrænsning, der gør korrekt størrelsesbestemmelse værdifuld, og det er også grunden til, at et generøst gæt på dag ét er dyrere her end på platforme, der tillader overcommitment.

Reduceret hukommelse kræver en genstart, fordi VMM Pro ikke fjerner hukommelse fra en kørende gæst. Udvidelse af en virtuel disk sker live, og det samme gælder udviddelse af nogle ressourcer, men fjernelse af hukommelse betyder at lukke gæsten ned. Budgetter et kort nedbrud og planlæg det; to minutter er opnåeligt, men det er ikke nul.

Virtuelle diske vokser og krymper aldrig. Hvis du overallokerer lagerplads i stedet for hukommelse, VMM Pro vil ikke give den tilbage. Den eneste vej er at opbygge en ny gæst og migrere ind i den, hvilket er en meget længere eftermiddag end denne var.

CPU-grænser i containere fungerer muligvis slet ikke. På denne gæstekommando har kernen ingen CFS-båndbreddekontrol, så container-CPU-kvoter afvises direkte – og værre endnu, forsøg på at indstille en i den samme kommando som en hukommelsesgrænse får hele kommandoen til at mislykkes lydløst. Hukommelsesgrænser og applikationens eget worker-loft er den eneste tilgængelige CPU-beskyttelse.

Et snapshot er ikke en backup. Det ligger på den samme vært og i den samme storagepool som den gæst, det beskytter. VMM Pro kan replikere snapshots til en anden vært, som er tættere på, men det, der overlever en bygningsbrand, er stadig en ekstern backup af selve dataene.

Se endelig, hvad konsollen viser. Containerdetaljesider viser miljøvariabler i almindelig tekst, inklusive databaseadgangskoder. Det er ærlig Docker snarere end en fejl i pakken, men det betyder, at et enkelt skærmbillede af den forkerte side offentliggør en legitimationsoplysninger. Hvis det generer dig – burde det – så flyt hemmeligheder til en fil, som containeren læser, i stedet for at sende dem som variabler.

Referencer

• SynoPower Club, vores Synology NAS-guider og kameraanmeldelser
• Synology — Virtual Machine Manager, den officielle sammenligning af funktioner og udgaver
• Synology Videnscenter — Virtual Machine Manager hjælp, gæsteindstillinger og klyngeopsætning
• Docker — opdatering af docker-containere, ændring af en kørende containers hukommelsesgrænse
• Apache — MaxRequestWorkers, arbejdstagerloftet, der er omtalt i afsnit syv

Ofte stillede spørgsmål