Synology VMM Pro: Rätt storleksanpassa en produktions-VM med AI (2026)

Den virtuella maskinen som driver den här butiken har tillbringat månader med dubbelt så mycket hårdvara som den behövde. Åtta virtuella processorer, sexton gigabyte minne och en verklig arbetsbelastning som aldrig rörde mer än en fjärdedel av någon av dem. Det är inte ovanligt. Du dimensionerar en gäst generöst på dag ett eftersom du inte har någon aning om vad den kommer att behöva, webbplatsen fungerar och ingen går någonsin tillbaka. Den här artikeln är loggboken över att gå tillbaka. Vi klippte ner den gästen till fyra virtuella processorer och åtta gigabyte med hjälp av Synology. VMM Pro, med en AI-assistent som styr skalet, och arkivet var oåtkomligt i två minuter och sju sekunder. Själva storleksändringen är den tråkiga delen – det är två fält i en dialogruta. De intressanta delarna är mätningen som bevisade att åtta gigabyte räckte, operationsordningen som hindrar gästen från att få slut på minne vid första uppstarten, och ögonblicksbilden som gjorde allt reversibelt. VMM Pro gör var och en av dessa billiga, och det är det ärliga argumentet för det.

SynoPower Club-punkt:Att anpassa storleken är det minst glamorösa jobbet inom självhosting och det som ger bäst avkastning. Ingen skriver ett blogginlägg om de åtta gigabyte de gav tillbaka. Men minnet som ligger inaktivt inuti en överdimensionerad gäst sparar dig ingenting – på en Synology är det fäst, så det kan inte användas av något annat på lådan. Vi fick tillbaka åtta gigabyte på en värd som började kännas full, vilket är ytterligare två gäster som vi inte längre behöver köpa hårdvara till. Det som gjorde det säkert snarare än skrämmande var VMM Pro under: en låst ögonblicksbild före det första kommandot, och en maskin som jag kunde återställa till hur den var på nittio sekunder om något av detta gick fel. Det gick inte fel. Men jag skulle inte ha börjat utan det.

Vad är Synology, VMM Pro?

Virtual Machine Manager är Synology:s hypervisorpaket. Det installeras från Paketcenter, är gratis och på en enda NAS kör det gärna Linux, Windows och Virtual DSM-gäster med lokala ögonblicksbilder. VMM Pro är den betalda uppgraderingen som förvandlar den där hypervisorn med en enda box till ett litet kluster: flera NAS-enheter hanteras som en pool, gäster som kan flytta mellan dem, hög tillgänglighet och snapshot-replikering från en värd till en annan.

Skillnaden är viktig för den här artikeln eftersom rätt storlek är ett kapacitetsbeslut, och kapacitet blir bara intressant när du har mer än en maskin i potten. På en enda NAS är minnet du frigör minne som ligger oanvänt på den NAS:en. I ett VMM Pro-kluster är det minne som en annan värd kan låna under en redundansväxling, eller som en ny gäst kan byggas in i utan att köpa något.

A Virtual DSM gäst — en fullständig DSM-installation som körs som en virtuell maskin — är arbetsbelastningen vi har ändrat storlek på här. Den kör Container Manager, som kör de två Docker-containrarna bakom den här lagringsplatsen. Den lagerstrukturen är avsiktlig och det är det som gjorde jobbet säkert. Vi behandlade hur man flyttar en Docker-stack mellan gäster i vår genomgång av VDSM Docker-migrering; den här artikeln handlar om att göra gästen under den i rätt storlek.

VMM Pro vs gratisutgåvan: Vad uppgraderingen faktiskt ger

Gratisversionen är inte en otillräcklig demo. Den kör produktionsgäster, tar ögonblicksbilder och för en enda NAS är det verkligen allt de flesta behöver. Vad du köper med VMM Pro är inte funktioner hos en gäst, det är funktioner hos värdar.

Förmåga	Gratisutgåva	VMM Pro
Kör gäster på en NAS	Ja	Ja
Lokala ögonblicksbilder	Ja	Ja
Flera NAS-enheter som ett kluster	Inga	Ja
Flytta en gäst mellan värdar	Inga	Ja
Redundansväxling med hög tillgänglighet	Inga	Ja
Replikera ögonblicksbilder till en annan värd	Inga	Ja

Kolla den officiella funktionssidan som länkas i referenserna innan du köper, eftersom Synology reviderar upplagsfördelningen mellan DSM-utgåvor. Det praktiska testet är enklare än tabellen: om du äger en NAS och du är nöjd med att återställa från en ögonblicksbild för hand, är gratisutgåvan okej. I det ögonblick du äger en andra NAS och du vill att den förstas gäster ska överleva när den dör, vill du ha en VMM Pro-licens.

Vårt kluster består av tre noder, och endast två av dem är påslagna för det mesta. Den tredje är ett kallt standby-läge som vaknar enligt ett schema för att ta emot replikerade ögonblicksbilder och går sedan tillbaka till viloläge. Det mönstret – betala för el bara när du behöver redundansen – är ett VMM Pro-mönster, och det är anledningen till att konsolen visar en permanent varning om en värd den inte kan nå. Varningen är att designen fungerar, inte ett fel.

Hur en produktionsgäst blir dubbelt så stor som den behöver

Tre saker driver gäster uppåt och ingenting driver dem ner igen. Det första är att den ursprungliga storleken är en gissning, och en generös gissning kostar ingenting på dag ett. Det andra är att varje incident slutar med att någon höjer en gräns. Vår hade två minnesincidenter på en vecka; båda åtgärdades genom att ge något mer utrymme, och ingen av dem besöktes någonsin igen. Det tredje är att en instrumentpanel som visar åttio procents minnesanvändning ser alarmerande ut, så ingen anmäler sig frivilligt att ta bort minnet. Inget av det är ett VMM Pro-problem. Det är ett mänskligt problem, och det är därför alltför stora gäster är normen.

Det sista är fällan, och det är värt att säga det tydligt: det tal som de flesta tittar på för att avgöra om en container har plats är fel tal. Vårt tal sa att databascontainern var vid åttioen procent av sin gräns. Det var den inte. Avsnitt fem handlar helt om varför, och om mätningen som gjorde storleksändringen på VMM Pro till ett säkert beslut snarare än ett hoppfullt.

Rätt storlek på en livegäst med VMM Pro i 4 steg

Hela jobbet är fyra steg, och bara det tredje tar webbplatsen offline. Den totala driftstoppstiden för oss var två minuter och sju sekunder, mätt från det ögonblick då containrarna stoppades till den första HTTP 200 efter att gästen kom tillbaka. VMM Pro är involverad i steg ett och tre; det mellersta steget sker inuti gästen.

Varför dockerstatistik kommer att övertala dig att inte svara rätt

Innan storleksändringen såg containerns instrumentpanel ut som en maskin utan utrymme att ge:

dockerstatistik WordPress 2.51 GiB / 7 GiB (35.9%) WordPress-DB 3.25 GiB / 4 GiB (81.1%) <-- ser nästan full ut

Läs det och du drar slutsatsen att databasen behöver sina fyra gigabyte och att gästen inte kan gå under tolv. Båda slutsatserna är felaktiga, eftersom minnesanvändningen som dessa verktyg rapporterar inkluderar sidcache, och sidcache återvinns automatiskt i det ögonblick något annat behöver minnet. Siffran som avgör om du får en minnesförlust är anonymt minne. Läs det direkt:

dockerchef 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 inverteras bilden. Applikationsbehållaren använder faktiskt 1,3 GB, inte 2,5 GB. Och av dessa 1,3 GB är 768 MB en enda delad opcode-cache som varje arbetsprocess mappar snarare än kopierar – så tjugo arbetsprocesser kostade ungefär tjugosju megabyte vardera, inte de tvåhundrafemtio megabyte som en naiv summa processminne antyder. Databasens 2,5 GB var nästan uteslutande en buffertpool på tre gigabyte för en databas på 663 MB.

Ännu en fälla i samma familj: räknaren för historiska toppar visar gärna en behållare som nuddat taket, eftersom den räknaren också inkluderar sidcache. Båda våra hade det. Ingen av dem hade någonsin avslutats på grund av slut på minne. Kontrollera räknaren för slut på minne, inte toppmärket.

Med dessa två fakta i handen slutade åtta gigabyte att vara ett riskabelt tal. Att minska buffertpoolen till en gigabyte – fortfarande bekvämt större än hela databasen – frigjorde mer verkligt minne än vad storleksändringen behövde. Talet vi slutligen skrev in i VMM Pro var redan bevisat innan gästfunktionen stängdes av.

Hur ett litet team använder VMM Pro för att återta en hel server

Minnet i en Synology-gäst är låst. Hypervisorn låser och förallokerar det, vilket innebär att du inte kan överprenumerera det på samma sätt som på vissa andra plattformar. Sexton gigabyte tilldelade till en gäst är sexton gigabyte som ingen annan gäst kan ha, oavsett om gästen är upptagen eller inaktiv. Det är den begränsningen som gör det värt att göra rätt storleksanpassning på VMM Pro specifikt: att frigöra minne är det enda sättet att skapa kapacitet förutom att köpa en NAS.

Åtta gigabyte kom tillbaka på en värd med totalt 46,83 GB. Tillgängligt minne ökade från ungefär tjugotvå gigabyte till 30,29 GB. I praktiken är det två gäster till av den storlek vi faktiskt kör, skapade av ingenting annat än mätningar. På ett kluster med tre noder betyder det också att de överlevande värdarna har mer utrymme för att absorbera gästerna från en nod som slutar fungera, vilket är hela poängen med att betala för VMM Pro från första början.

CPU-sidan berättade samma historia mer rakt på sak. Gästprocessorn hade åtta virtuella processorer och använde ungefär en sjättedel av en kärna i vila. Fyra var inte en kompromiss; fyra är fortfarande generöst, och VMM Pro tillämpade det i ett enda fält. Sedan storleksändringen ligger gästprocessorn på en genomsnittlig belastning på 1,36 mot fyra virtuella processorer, vilket är ungefär en tredjedel som används under den mest hektiska delen av dagen.

Den ordningsföljd som förhindrar en loop med slut på minne vid uppstart

Det här är den delen som är lätt att göra fel och dyr att göra fel. Minnesgränserna för containern och gästminnet du ställer in i VMM Pro är två separata tak, och om summan av containergränserna överstiger gästminnet har du angett att containrarna får använda mer än vad maskinen har. Under belastning löser kärnan den oenigheten genom att döda något.

Våra gränser före ändringen var sju gigabyte för applikationscontainern och fyra för databasen – elva gigabyte på en gäst på sexton gigabyte, vilket var okej. På en gäst på åtta gigabyte skulle det ha varit en incident som väntade på sin första trafiktopp. Så containrarna var tvungna att tas ner först:

Miljö	Före	Efter
Gäst	8 vCPU / 16 GB	4 vCPU / 8 GB
Gräns för applikationsbehållare	7168 MB	4096 MB
Gräns för databasbehållare	4096 MB	2048 MB
Databasbuffertpool	3 GB	1 GB
Maximalt antal anslutningar till databasen	300	100
Apache-arbetartak	50	35

Det finns en andra ordningens regel gömd i den tabellen. Du kan inte sänka en containers minnesgräns under vad den för närvarande använder och förvänta dig att kärnan ska vara artig mot det. Applikationsbehållaren använde mindre än sin nya gräns, så den begränsades live utan omstart och ingen driftstopp. Databasbehållaren använde mer, så dess buffertpool var tvungen att konfigureras om och containern startas om först; först då kunde den lägre gränsen tillämpas. Inget av dessa steg sker i VMM Pro – båda måste slutföras innan du öppnar dialogrutan för storleksändring.

Arbetartaket är den enda verkliga kostnaden för hela övningen, och det förtjänar att nämnas snarare än att begravas. Att minska applikationscontainern från sju gigabyte till fyra innebär att färre samtidiga förfrågningar kan vara igång: femtio ner till trettiofem, en trettioprocentig minskning av maximal samtidighet. Dag efter dag kör webbplatsen elva arbetare, så ingenting förändrades. Under en annonsutbrott kanske det. Det är en byteshandel vi gjorde medvetet, och den är nedskriven så att nästa person inte återupptäcker den under ett avbrott.

Vad AI-assistenten faktiskt gjorde, och var det var fel

Assistenten gjorde de delar som belönar tålamod: den tog en ögonblicksbild av VMM Pro innan den rörde något, läste cgroup-statistiken istället för att lita på instrumentpanelen, räknade ut beställningsbegränsningen för containergränserna och verifierade resultatet genom att hämta riktiga sidor och kontrollera att priserna fortfarande återges i rätt valuta. Det är kanske fyrtio minuters noggrant arbete komprimerat till några minuter, och det är verkligen användbart.

Det var också fel tre gånger under en och samma session, vilket är den mer användbara halvan av historien.

• Den rekommenderade tio gigabyte när ägaren bad om åtta. Ägaren hade rätt – men bara för att den överdimensionerade buffertpoolen åtgärdades samtidigt. Assistenten hade måttet framför sig och förankrade sig fortfarande på det säkrare numret.
• Den döpte om gästen, läs framgång: sant från API:et och rapporterade bytet som klart. Det hade inte bytt namn. Byte av namn-fältet som användes var det som identifierar gästen, inte det som ändrar dess namn, och API:et returnerar framgång oavsett vilket.
• Den såg ett VMM Pro-kluster som varnade om en oåtkomlig värd och flaggade det som en degraderad redundansväxlingssökväg. Värden var en kall standby-funktion som avsiktligt var avstängd. Aviseringen hade funnits där i månader avsiktligt.

Mönstret i alla tre är detsamma: säker utdata från en rimlig kontroll. De skyddsräcken som faktiskt spelar roll är därför oglamorösa. Ta ögonblicksbilden först, varje gång, före det första kommandot snarare än före det riskabla. Acceptera aldrig ett returvärde som bevis – läs tillbaka tillståndet och titta på fältet du tänkte ändra. Och verifiera beteendet, inte inställningarna: en sida som laddas och ett korrekt pris slår valfritt antal bekräftelser på att ett kommando avslutade noll.

Inget av det är specifikt för AI. Det är samma disciplin som man skulle vilja ha från en ny kollega med root-åtkomst som är snabb, outtröttlig och ibland säker på något som inte är sant.

Var man hittar fler officiella resurser

Tre videor som är värda att lägga ner tid på innan du ändrar storlek på något med VMM Pro. Den första är den bästa översikten över själva paketet; de andra två handlar om att skapa och licensiera gäster, vilket är där de flesta kör fast vid första försöket.

Begränsningar att känna till innan du anförtror VMM Pro produktionen

Minne kan inte överbelastas. Varje gigabyte du tilldelar är låst från allt annat på NAS-enheten, upptagen eller inte. Det är denna begränsning som gör rätt storlek värdefull, och det är också anledningen till att en generös gissning på dag ett är dyrare här än på plattformar som tillåter överbelastade minnesnivåer.

Att krympa minnet kräver en omstart, eftersom VMM Pro inte tar minne från en aktiv gäst. Att utöka en virtuell disk sker live, och det gör även utökning av vissa resurser, men att ta bort minne innebär att stänga av gästen. Budgetera ett kort avbrott och schemalägg det; två minuter är möjligt men det är inte noll.

Virtuella diskar växer och krymper aldrig. Om du överallokerar lagring snarare än minne, VMM Pro kommer inte att ge tillbaka den. Den enda vägen är att bygga en ny gäst och migrera in i den, vilket är en mycket längre eftermiddag än den här var.

CPU-gränser inuti containrar kanske inte fungerar alls. På den här gästfunktionen har kärnan ingen CFS-bandbreddskontroll, så containrarens CPU-kvoter avvisas direkt – och värre, om man försöker ställa in en i samma kommando som en minnesgräns får hela kommandot att misslyckas tyst. Minnesgränser och programmets eget arbetstak är det enda CPU-skydd som finns tillgängligt.

En ögonblicksbild är inte en säkerhetskopia. Den finns på samma värd och i samma lagringspool som gästen den skyddar. VMM Pro kan replikera ögonblicksbilder till en annan värd, som är närmare, men det som överlever en byggnadsbrand är fortfarande en extern säkerhetskopia av själva data.

Slutligen, titta på vad konsolen visar. Containerdetaljsidor visar miljövariabler i klartext, inklusive databaslösenord. Det är Docker som är ärlig snarare än en brist i paketet, men det betyder att en enda skärmdump av fel sida publicerar en autentiseringsuppgifter. Om det stör dig – borde det – flytta hemligheter till en fil som containern läser istället för att skicka dem som variabler.

Referenser

• SynoPower Club, våra Synology NAS-guider och kamerarecensioner
• Synology — Virtual Machine Manager, den officiella jämförelsen av funktioner och utgåvor
• Synology Kunskapscenter — Virtual Machine Manager hjälp, gästinställningar och klusterkonfiguration
• Docker — uppdatering av docker-containrar, ändra minnesgränsen för en körande container
• Apache — MaxRequestWorkers, arbetstagartaket som diskuteras i avsnitt sju

Vanliga frågor